DDSE_U3_Contenido

Vista previa del material en texto

Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
0 Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 
 
 
 
 
 
 
Programa de la asignatura: 
Desarrollo de software en equipo TSP 
 
6º Semestre 
 
 
 
 
Unidad 3. Gestión en TSP 
 
 
 
Clave: 
150930934 
 
Ciudad de México, enero del 2023 
 
Universidad Abierta y a Distancia de México 
UnADM 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
1 
 
Índice 
 
Unidad 3. Gestión en TSP ...................................................................................................... 2 
Presentación de la unidad ...................................................................................................... 2 
Logros ..................................................................................................................................... 2 
Competencia específica ......................................................................................................... 2 
3.1. Monitoreo y control del proyecto ..................................................................................... 3 
3.1.1. Ejecutar la revisión de la administración del proyecto ................................................ 3 
3.1.2. Elaborar el reporte administrativo del estatus del proyecto ........................................ 6 
3.2. Análisis post mortem ..................................................................................................... 13 
3.2.1. Diagnóstico: métricas de calidad versus trabajo realizado ....................................... 13 
3.2.2. Elaborar el análisis del desempeño del equipo ......................................................... 18 
Cierre de la unidad ............................................................................................................... 34 
Para saber más .................................................................................................................... 35 
Fuentes de consulta ............................................................................................................. 35 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
2 
 
Unidad 3. Gestión en TSP 
 
Presentación de la unidad 
 
Bienvenido(a) a la Unidad 3. Gestión en TSP, aquí se abordarán conceptos 
relacionados con la administración de un proyecto de desarrollo de software utilizando 
la metodología TSP. 
 
En la unidad 1 aprendiste conceptos básicos sobre la metodología TSP, ciclo de vida 
de un proyecto de desarrollo de software y las fases de esta metodología. En la unidad 
2 aprendiste a llevar a cabo la fase de lanzamiento del proyecto, según la metodología 
TSP, y a ejecutar la fase de implementación mediante el plan de riesgos, plan de 
calidad y plan de proyecto. 
 
En esta unidad aprenderás a realizar las plantillas correspondientes a la fase post 
mortem, así como el monitoreo y control del proyecto necesarios para que la parte 
administrativa del proyecto lo revise, y así sea posible contar con una medida exacta 
del avance que se tiene del mismo. 
 
También aprenderás a implementar la fase post mortem, la cual tiene dos 
componentes que son: diagnóstico de métricas de calidad versus trabajo realizado, y 
la elaboración del análisis del desempeño del equipo. Esto será una parte muy 
importante en el proyecto de desarrollo de software que se esté desarrollando, porque 
se podrá contar con una retroalimentación de los errores y de las cosas que se 
hicieron bien en el proyecto, y así poder considerarlo para futuros proyectos. 
Logros 
 
Al término de esta unidad lograrás: 
 
• Determinar la función de gestión a partir de la metodología Team Software Process 
(TSP), con el fin de evaluar el avance que va teniendo el desarrollo del proyecto. 
• Identificar el estatus del proyecto a partir de un reporte para saber su estado 
actual. 
• Analizar los problemas de calidad del equipo de trabajo que estén a cargo del 
desarrollo del proyecto, mediante reportes. 
Competencia específica 
 
• Aplicar la mecánica de gestión de la metodología Team Software Process 
(TSP) para tomar decisiones gerenciales del proyecto a partir de los reportes. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
3 
 
3.1. Monitoreo y control del proyecto 
 
El monitoreo y control del proyecto es un conjunto de actividades de gestión que 
permiten verificar si el proyecto marcha según lo planificado (Humphrey, 1999). Para 
lograr la calidad deseada en todos los proyectos de desarrollo de software, es 
necesario supervisar el que las actividades y tareas se realicen en forma adecuada, 
así como el seguimiento del presupuesto asignado y los recursos humanos 
involucrados. 
 
Para la supervisión y seguimiento del proyecto, es necesario realizar acciones de 
monitoreo y control utilizando la metodología TSP; esto reviste esencial importancia 
porque permite medir, de una manera correcta, la situación del proyecto. Se puede 
decir que el monitoreo y control son acciones necesarias para que se cumplan los 
objetivos de una manera exitosa. 
 
En los siguientes capítulos aprenderás a realizar las plantillas que TSP proporciona 
como una mecánica para la gestión del proyecto, con el fin de que comprendas cómo 
influyen estos reportes en la toma de las decisiones gerenciales al implementar esta 
metodología. 
 
 
3.1.1. Ejecutar la revisión de la administración del proyecto 
 
En la Unidad 2. Implementación de TSP aprendiste cómo realizar el plan de calidad, 
de riesgos y de proyecto. Cuando se ejecuta el plan de calidad se hacen las revisiones 
de código correspondientes al diseño y al desarrollo del proyecto. En este capítulo 
aprenderás a realizar la revisión de todo lo ya realizado, incluyendo desarrollo y 
pruebas del sistema. 
La revisión de la administración es importante antes de arrancar la fase post mortem. 
Recuerda que un proyecto, de acuerdo a su tamaño, se puede dividir en módulos. 
Para que se entienda mejor se expone el siguiente ejemplo. 
Se desarrolla un software para llevar el control de una empresa que se dedica a la 
venta y fabricación de textiles, al momento de levantar los requerimientos con el 
cliente por parte del administrador de proyectos, se encontró que el sistema será muy 
amplio, ya que tendrá que dar de alta los materiales para hacer los textiles, y además 
se desarrollará la parte del software donde se realizarán las ventas de los productos. 
Aquí el software se dividirá en dos módulos, uno se encargará de lo relativo a la 
fabricación y el otro a la venta de los productos. Al momento de realizar las pruebas 
del sistema se encontró que el módulo de ventas ya fue revisado y no se encontraron 
errores, por lo tanto fue liberado correctamente. El segundo módulo lo revisó el equipo 
de calidad, y encontró que más de la mitad tiene errores. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
4 
 
Siguiendo el ejemplo anterior, el equipo de desarrollo y diseño primero entregará el 
módulo correspondiente a la fabricación de los productos, y después el que se refiere 
a la venta. El equipo de calidad y los administradores del proyecto evaluarán, 
revisarán y aprobarán cada módulo; conforme se termine de revisar, si el sistema tiene 
aún errores se regresará al equipo de desarrollo, para que realice las modificaciones 
correspondientes. 
Para hacer el seguimiento de la administración del proyecto de acuerdo a las pruebas 
realizadas, TSP proporciona la plantilla que se observa a continuación. 
Nombre del 
módulo 
Nombre del 
encargado de la 
revisión 
Nombre del 
rol 
Porcentaje 
completado 
Observaciones 
Ventas 
Fabricación de 
productos 
 
 
 
 
 
Plantilla de revisión de la administración del proyecto. Tomado de Humphrey, 2006. 
Recuerda que esta plantilla puede iren un documento de Word con un control de 
cambios, tal como se menciona en la unidad 2, en el subtema 2.1.1 Documentar 
propósitos, objetivos y roles del equipo. 
A continuación se explicará qué es lo que se tiene que integrar en cada columna de la 
plantilla: 
Nombre del módulo: como el título lo indica, en esta columna se integrará el nombre 
del módulo. En el ejemplo anterior se mencionan dos módulos: ventas y fabricación de 
productos. Estos nombres se definen al inicio del proyecto. Si el proyecto se integrara 
de más de dos módulos, se deberán insertar las filas que sean necesarias. 
Nombre del encargado de la revisión: aquí se integrará el nombre de la persona que 
llevó a cabo las pruebas del módulo correspondiente. 
Nombre del rol: en esta columna se escribirá el rol del encargado de las pruebas del 
módulo, según la metodología TSP y el equipo en el que se encuentre. 
Porcentaje completado: se integra en una columna identificada con colores según el 
porcentaje concluido del módulo correspondiente, tal como se muestra a continuación. 
0 a 40% 
41 a 80% 
81 a 100% 
Porcentaje completado 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
5 
 
Observaciones: en esta columna el encargado de hacer la plantilla, que será el 
administrador de calidad, integrará sus observaciones sobre la revisión del módulo. 
Con base en el ejemplo anterior, se expone el siguiente ejemplo: 
Nombre del 
módulo 
Nombre del 
encargado de la 
revisión 
Nombre del 
rol 
Porcentaje 
completado 
Observaciones 
Ventas Juan Pérez Administrador 
de calidad 
100% Esto módulo fue 
revisado y 
aprobado para su 
liberación por parte 
del equipo de 
calidad. 
Fabricación 
de 
productos 
Juan Pérez Administrador 
de calidad 
40% En este módulo se 
encontraron aún 
muchos errores, 
por lo que se 
regresó al equipo 
de desarrollo para 
que realice las 
modificaciones 
correspondientes. 
Plantilla de revisión de la administración del proyecto. 
Es importante mencionar que el porcentaje completado se define en las juntas que se 
hacen en la fase de lanzamiento de TSP. Esto lo realiza el administrador de calidad 
junto con su equipo de pruebas. 
En conclusión, se puede decir que esta plantilla es importante porque proporciona una 
idea clara del estado del proyecto una vez ejecutadas las pruebas del software. Al 
contar con esta plantilla se tiene una medida bien definida del estado del proyecto. El 
monitoreo y control se divide en dos partes, la revisión de la administración del 
proyecto y el reporte administrativo del estatus del proyecto, este último se abordará 
en el siguiente capítulo. 
 
 
 
 
 
 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
6 
 
3.1.2. Elaborar el reporte administrativo del estatus del proyecto 
 
Un reporte de estatus del proyecto es un documento que informa el estado actual del 
proyecto. Su principal propósito es comunicar si se va desarrollando según lo 
planeado y por qué, o si no se va desarrollando según lo planeado, también el por qué 
(Esterkin, 2008). Los elementos que conforman este reporte son los siguientes: 
• Estatus general del proyecto: muestra el estado del proyecto al momento de 
hacer la plantilla. 
• Estatus del proyecto a nivel entregable: como ya se mencionó, un proyecto 
puede dividirse en módulos, los cuales no se entregaran todos juntos sino uno 
por uno, a eso se refiere este punto. 
• Actividades relevantes del periodo: se describen actividades importantes 
durante el periodo en que se realiza la plantilla. 
• Riesgos: se describen los riesgos que surgen durante el periodo de inicio del 
proyecto hasta que se elabora la plantilla. 
• Problemas: se describen problemas referentes al software realizado durante el 
periodo de inicio del proyecto hasta que se elabora la plantilla. 
Como se mencionó, en este reporte quedará plasmada la situación actual del 
proyecto. El propósito es comunicar si el proyecto se va desarrollando de acuerdo a lo 
planeado en un inicio, y en caso de que no sea así saber por qué no se está 
cumpliendo con los objetivos. Es importante remarcar que este reporte no se utiliza 
para registrar el trabajo que realizó el equipo del proyecto (para esto TSP proporciona 
los planes vistos en la Unidad 2. Implementación de TSP), su función principal es dar 
cuenta de los desvíos del plan realizado al inicio del proyecto, y así buscar y plantear 
una solución adecuada. En este reporte TSP indica qué debe contener un resumen 
que mencione si el proyecto se está desarrollando según lo planeado, si se cumplen 
con las fechas estimadas de entregas, si surgieron riesgos nuevos o aumentó la 
probabilidad o el impacto de riesgos conocidos elaborados en el plan de riesgos. 
También debe contener una breve descripción de aquellas cosas del proyecto que no 
se desarrollan según lo planeado, las medidas o acciones que se tomaron para 
corregir este problema, el porcentaje de avance en los entregables, y el costo actual 
del proyecto. 
La plantilla para elaborar este reporte es la siguiente: 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
7 
 
Proyecto Nombre del proyecto 
Id Código del identificador (depende totalmente de la empresa que 
esté desarrollando el software, se refiere al código que se asignó 
al proyecto). 
Líder de proyecto Nombre del líder 
Periodo dd/mm/aa – dd/mm/aa (periodo del inicio del proyecto hasta la 
fecha en que se realiza la plantilla). 
 
Acuerdos anteriores 
 
Acuerdo Estado Fecha 
compromiso 
Responsable/rol Observacione
s 
Descripción del 
acuerdo (descripción 
del número de 
acuerdo al momento 
de realizar la plantilla). 
Indica si el 
acuerdo está 
abierto 
(cuando no se 
logró el avance 
planeado) o 
cerrado. 
Fecha límite 
en la que 
debe 
cumplirse el 
acuerdo. 
Nombre o rol del 
encargado de 
cumplir el 
acuerdo. 
Comentarios 
relacionados al 
acuerdo. 
 
 
 
Estatus general del proyecto 
 
Avance % 
Avance planeado % 
Avance real % 
Desviación % de avance 
planeado menos 
avance real 
 
Situación general del proyecto 
Descripción de las razones que originan el estatus del proyecto (motivos por los cuales hay un 
desvío entre lo planeado y el avance real, o si el proyecto avanza conforme a lo planeado) 
 
Estatus del proyecto a nivel entregable/fase 
 
Entregable/fas
e 
Estatus Presupuesto Costo Avance Observacione
s 
Nombre del 
entregable o 
fase. 
Indicar el 
estatus del 
entregable 
o fase 
Cantidad 
asignada al 
entregable o 
fase del 
Costo 
actual del 
entregable 
o fase (es 
Porcentaje 
del avance 
del 
entregable 
Observaciones 
relacionadas al 
entregable o 
fase. 
Estatus 
0-40% 
41-80% 
81-100% 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
8 
 
(verde, 
amarillo o 
rojo). 
proyecto (este 
presupuesto 
se da en la 
fase de 
lanzamiento 
de TSP). 
el costo del 
proyecto al 
momento 
de realizar 
la plantilla). 
o fase. 
 
 
 
Actividades relevantes del periodo 
 
# Actividad 
 Breve descripción de la actividad realizada en el periodo. 
 
 
 
 
Problemas 
 
# Problemas Respuesta Responsable/rol Fecha 
Compromiso 
 Descripción del 
problema. 
Plan de acción 
para gestionar el 
problema 
(describir la 
solución que se le 
va a dar al 
problema). 
Nombre o rol del 
encargado de 
gestionar el plan 
de respuesta. 
Fecha límite para 
solucionar el 
problema (proponer 
una fecha para 
darle solución al 
problema). 
 
 
Riesgos 
 
ID Riesgo Probabilida
d 
Impact
o 
Priorida
d 
Respuest
a 
Responsabl
e 
Número de la 
revisión 
correspondient
e (uno, dos, 
tres, etcétera). 
Descripció
n del 
riesgo. 
Indica 
probabilidad 
de 
ocurrencia 
(alta, media 
o baja). 
Indica 
si el 
impacto 
es alto 
medio o 
bajo. 
Indica la 
urgencia 
con la 
que 
debe 
tratarse 
el 
cambio, 
se debe 
analizar 
el 
impacto 
Plan de 
acción 
para hacerfrente al 
riesgo. 
Nombre o rol 
del 
encargado 
de ejecutar el 
plan de 
respuesta. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
9 
 
que 
tendrá 
en el 
proyecto 
(alto 
medio, 
bajo). 
Se integran 
tantas filas 
como se 
requiera, de 
acuerdo con el 
número de 
revisiones. 
 
Plantilla de reporte administrativo del estatus del proyecto. Tomado de Siles, 2012. 
Esta plantilla la realizará el administrador de proyectos, por lo tanto, él realizará las 
observaciones correspondientes. Más adelante, mediante un ejemplo se ahondará en 
este punto. 
Otro punto a remarcar es que todos los estatus se considerarán de acuerdo al avance 
del proyecto y se les asignará un color, tal como se muestra a continuación: 
0 a 40% 
41 a 80% 
81 a 100% 
Porcentaje completado 
A continuación se expone un ejemplo mediante el cual se ilustra la forma de llenar la 
plantilla anterior: 
Se realiza un proyecto de software dirigido al apoyo de servicios escolares y 
administración escolar de una institución educativa. El proyecto tiene por nombre 
Sistema de administración escolar EscolaRis; se requiere que el sistema permita: 
• A los profesores, capturar las calificaciones de los alumnos 
• Al área de servicios escolares, contar con los datos completos de los alumnos 
y el historial académico, así como realizar: altas, bajas, registro de exámenes 
extraordinarios, etcétera 
• Al área de administración escolar, contar con un registro de los alumnos 
inscritos en la escuela y también de egresados 
• A los padres de los alumnos, contar con un módulo vía Web para conocer sus 
calificaciones, así como las observaciones de los profesores sobre el estatus 
académico de cada uno de sus alumnos 
Para el desarrollo del software se asignó un presupuesto de $ 800,000. 
El sistema ya pasó la primera revisión de pruebas, en las juntas que se tuvieron en la 
fase de lanzamiento del proyecto se acordó que para esta revisión el avance tenía que 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
10 
 
ser de 40% del total del proyecto; al realizar esta tarea se encontraron errores de 
codificación y diseño, por lo cual sólo se logró el 35% de avance; el costo actual del 
proyecto es de$ 200,000. Algo que preocupa a la empresa que desarrolla este 
software es que el cliente solicita más requerimientos de los que se plantearon al inicio 
del proyecto, y es difícil implementarlos porque ya se concluyó la fase de pruebas del 
desarrollo del proyecto. Cabe señalar que el proyecto se encuentra en la fase de 
integración y pruebas del sistema, de acuerdo al ciclo de vida de desarrollo de 
software. 
Con los datos proporcionados anteriormente se procede al llenado de la plantilla de 
reporte administrativo del estatus del proyecto, que se presenta a continuación. 
Proyecto Sistema de administración escolar EscolaRis 
Id AE1 
Líder de proyecto Rubén Hernández 
Periodo 05/01/2012- 25/04/2012 
 
Acuerdos anteriores 
 
Acuerdo Estado Fecha 
Compromiso 
Responsable/rol Observaciones 
Este es el 
primer 
acuerdo del 
proyecto. 
Abierto 22-Abril-
2012 
Administrador 
de proyectos 
El acuerdo se encuentra 
abierto ya que es la 
primera revisión. 
 
 
 
Estatus General del proyecto 
 
Avance % 
Avance planeado 40 
Avance real 35 
Desviación 5 
 
 
Situación general del proyecto 
El proyecto está bien, pero tiene una desviación de 5% porque se regresó al área de 
desarrollo para hacer las correcciones derivadas de las observaciones hechas por el 
equipo de calidad. 
 
Estatus del proyecto a nivel entregable/fase 
Estatus 
35% 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
11 
 
 
Entregable/fase Estatus Presupuesto Costo Avance Observaciones 
Entregable 1 35% $800,000 $200,000 35% El proyecto se 
encuentra bien en 
relación 
presupuesto/costo 
aunque tenga una 
desviación del 5%. 
 
 
 
 
Actividades relevantes del periodo 
 
# Actividad 
1 Se realizaron los módulos correspondientes a los catálogos de 
maestros y alumnos. 
2 Se realizó la parte de la calificación de alumnos por parte de los 
profesores, y se tuvo un adelanto en el módulo de inscripciones, aun 
no revisado por el equipo de calidad. 
 
 
 
Problemas 
 
# Problemas Respuesta Responsable/rol Fecha 
Compromiso 
1 Requerimientos 
nuevos que está 
pidiendo el cliente. 
Se platicará con 
él para realizar 
estos cambios 
una vez que se 
entregue lo 
acordado al 
principio del 
proyecto. 
Líder de 
proyecto 
03-Mayo-2012 
 
 
 
 
 
Riesgos 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
12 
 
ID Riesgo Probabilidad Impacto Prioridad Respuesta Responsable 
1 Nuevos 
errores 
una vez 
que se 
realice la 
segunda 
revisión 
del 
proyecto. 
Alta Alto Alta Hacer 
pruebas 
por parte 
del líder 
de 
desarrollo 
antes de 
enviarlo al 
equipo de 
pruebas. 
Líder de 
desarrollo 
 
 
 
 
Plantilla de reporte administrativo del estatus del proyecto 
Un punto a considerarse es que si surgen riesgos y problemas que impacten 
directamente en el presupuesto, tales como el cambio de algún integrante del equipo o 
cuestiones que pongan en riesgo los objetivos que se planearon al inicio del desarrollo 
del software, la alta gerencia tomará decisiones sobre la forma de solucionarlos. 
Aquí se observó la forma de realizar la plantilla de reporte administrativo del estatus 
del proyecto. Esta plantilla ofrece un amplio panorama sobre el avance real de todo el 
desarrollo del proyecto. En el siguiente tema se abordará la elaboración de las 
plantillas en la fase post mortem. 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
13 
 
3.2. Análisis post mortem 
 
Aquí se explicarán las actividades que se llevan a cabo en el último proceso del TSP, 
la fase post mortem, que es un medio de aprendizaje estructurado para el equipo de 
desarrollo, ya que proporciona información sobre la eficacia del líder de proyecto y 
cada uno de los miembros del equipo, así como el rendimiento de cada uno de ellos 
(Humphrey, 2006). 
Dentro del proceso de post mortem también aprenderás a realizar un diagnóstico 
sobre las métricas de calidad aplicadas al trabajo realizado durante el desarrollo del 
software. 
El post mortem sirve de retroalimentación para todos los integrantes del equipo porque 
se estudia la manera en que se trabajó durante el desarrollo del proyecto, se analiza la 
forma de realizar las actividades, detecta en qué se falló y en qué se obtuvieron 
resultados positivos. Todo esto con la finalidad de que los equipos y líderes de 
proyecto sean más eficaces, consideren los errores así como las acciones positivas 
con el fin de mejorar en los siguientes proyectos (Humphrey, 2006). 
Cuando se llega al final de cada ciclo de un proyecto se entra a la fase post mortem, 
donde los equipos de TSP cuentan con una gran cantidad de información, la cual 
contiene, entre otros, los siguientes elementos: 
• Calidad de los productos 
• Estimaciones. 
La información debe estar debidamente recolectada y organizada, de no ser así se 
presentarán problemas para poder reconstruir el trabajo realizado. Es por eso que TSP 
propone realizar el post mortem en la culminación de cada proyecto, para aprovechar 
que la información recabada y la experiencia del trabajo realizado por el equipo de 
proyecto están frescas; de esta manera se tendrá una idea más clara de cómo trabajar 
para los futuros proyectos. De igual manera, la elaboración del diagnóstico de métricas 
de calidad contra el trabajo realizado que también se reelabora en el proceso de post 
mortem tiene el propósito de evaluar los resultados obtenidos y verificar el nivel de 
cumplimiento de lo planeado que, en este caso, se refiere a las métricas de calidad 
establecidas por el equipo de proyecto. 
3.2.1. Diagnóstico: métricas de calidadversus trabajo realizado 
 
Aquí aprenderás a realizar el diagnóstico de las métricas de calidad (que se realizaron 
en el plan de calidad visto en la unidad 2), y a comparar el trabajo que se realiza para 
evaluar los resultados obtenidos. Es muy importante que hayas comprendido muy bien 
el plan de calidad para realizar este proceso final post mortem. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
14 
 
Para realizar el diagnóstico de las métricas de calidad con base en el trabajo previo, se 
debe hacer uso del plan de calidad, el cual contiene la información sobre la inyección 
de defectos en el diseño y codificación. 
También es importante reunirse con cada uno de los miembros del equipo y revisar en 
conjunto los procesos que se llevan a cabo, analizar en qué están fallando o la manera 
en que pueden mejorar, así como expresar las inconformidades e inquietudes 
(Humphrey, 2006). 
El encargado de las métricas de calidad es el gerente de calidad. Se debe hacer un 
reporte de realización de los objetivos con base en lo planeado y el resultado que se 
obtuvo. Recuerda que una métrica es un valor cuantificable que puede ser medible. A 
continuación se muestra un ejemplo de análisis del trabajo realizado por parte del 
gerente de calidad en un proyecto y los resultados conseguidos. Se mostrará un 
informe post mortem para el proyecto que lleva por nombre Apertura de crédito del 
banco de los Alpes. Se observa el registro del cumplimiento de las actividades 
planeadas por semana, para que finalmente sea posible evaluar el cumplimiento de los 
objetivos planeados (Archila et ál., 2010). 
 
Acciones Semana 
12 
Semana 
13 
Semana 
14 
Semana 
15 
Semana 
16 
Seman
a 17 
Total 
Planeado 38 22,5 31 10 9,5 7 118 
Esfuerzo 18,5 42,25 15 10 8 6 99,75 
Ejecutad
o 
8 39 13,5 11,5 12 3,5 87,5 
Cumplimiento de compromisos del Líder de calidad. Tomado de Archila et ál., 2010. 
 
Aquí se ofrece la distribución de las horas planeadas por semana para la realización 
de las activadas que tiene a su cargo el líder de calidad, y que a su vez fue planeado 
por parte del equipo de proyecto. El esfuerzo se refiere a la suma de tiempos asignado 
y, por último, lo ejecutado muestra el cumplimiento real de lo que se plano. 
 
A continuación se describe el objetivo propuesto por el equipo; se revisa en la 
siguiente tabla la distribución de las métricas planeadas y el resultado obtenido; la 
métrica es el valor que se le da a la actividad para que pueda ser medido; por ejemplo, 
en la siguiente tabla, el rubro Promedios de evaluación del rol por ayudar y soporte 
superior a cuatro, el cuatro es una medida que se le asigna a cada miembro del equipo 
para saber si el cumplimiento es malo, regular, bueno, excelente o si no es aplicable 
para su evaluación. 
 
Objetivo 1 
• Ser un miembro efectivo y cooperativo. 
 
 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
15 
 
Métrica Resultado 
Promedio de evaluación del rol por ayuda y 
soporte superior a cuatro. 
B
u
e
n
o
 
Promedio de evaluación de 4,25. 
Promedio de evaluación del rol contribución 
global superior a cuatro. 
R
e
g
u
la
r 
Promedio de evaluación 
exactamente igual a 4. 
Informe de logros del equipo de trabajo: objetivos globales de grupo. Tomado de Archila et ál., 2010. 
 
 
En la siguiente tabla se observa el objetivo planeado por el líder de calidad en cuanto 
a efectividad y cooperación. 
 
Objetivo 2 
• Hacer el trabajo personal de manera disciplinada y consiste. 
 
Métrica Resultado 
Promedio de evaluación del rol por ayuda y 
soporte superior a 4. 
B
u
e
n
o
 
Promedio de evaluación de 4,25. 
Promedio de evaluación del rol contribución 
global superior a 4. 
R
e
g
u
la
r 
Promedio de evaluación 
exactamente igual a 4. 
Objetivo global líder de calidad: efectividad y cooperación. Tomada de Archila et ál., 2010. 
 
 
En la siguiente tabla la métrica cambia a un valor en porcentaje para establecer el 
cumplimiento del objetivo. Está en una escala de %0 a 100%. 
 
Objetivo 3 
• Planear y hacer seguimiento al trabajo personal. 
 
Métrica Resultado 
Porcentaje de datos personales 
registrados en las formas Resumen 
planeación y Resumen de calidad 
es 100%. N
o
 A
p
lic
a
 Las estrategias para consolidar el 
seguimiento personal fueron negociadas 
con el grupo, las formas a las que se hace 
referencia fueron descartadas. 
Porcentaje de tareas planeadas y 
completadas 100%. 
M
a
lo
 
El líder de planeación realizó sólo el 57% 
de las actividades planeadas durante el 
ciclo. 
Objetivo global líder de calidad: disciplina. Tomado de Archila et ál., 2010. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
16 
 
 
De la misma manera que los demás objetivos propuestos por el equipo de proyecto, se 
revisa el cumplimiento de lo planeado así como el resultado obtenido, tal como se 
observa en la siguiente tabla. 
 
 
 
Objetivo 4 
• Hacer productos de calidad. 
 
Métrica Resultado 
Promedio de defectos 
encontrados antes de la 
primera compilación: >70%. 
B
u
e
n
o
 
Se encontró el 72% de los defectos esperados 
antes de la primera compilación. 
Densidad de los defectos 
encontrados durante 
compilación: <10/KLOC. 
E
x
c
e
le
n
te
 Menos de 3 defectos por KLOC. 
Densidad de los defectos 
encontrados en pruebas: 
<5/KLOC. 
R
e
g
u
la
r 
Las pruebas locales funcionaron correctamente. 
Sin embargo, al tratar de exponer como un 
servicio el componente no funcionó 
adecuadamente. 
Densidad de los defectos 
encontrados después de 
pruebas: 0. 
N
o
 a
p
lic
a
 La medida no ha podido ser verificada, puesto que 
aún la herramienta no ha superado la etapa de 
pruebas. 
Medición de la calidad del producto. Tomad de Archila et ál., 2010. 
 
Siguiendo con el mismo ejemplo de rol de líder de calidad, los objetivos propuestos por 
el equipo de trabajo se observan en la tabla siguiente. 
 
Métrica Resultado 
Inspecciones y reportes de 
seguimiento a los 
procesos. 
E
x
c
e
le
n
te
 Se realizaron las inspecciones adecuadamente. 
Los reportes de seguimiento no aplican. 
Producto alineado a 
estándares definidos con 
un porcentaje de 75% libre 
de defectos. 
E
x
c
e
le
n
te
 
El producto se encuentra alineado a los estándares 
definidos, sin embargo, aunque se puede decir que 
para lo que corresponde a programación el 
porcentaje libre de defectos esperado es del 93%, 
no es posible hacer una medición de lo que 
corresponde a configuración. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
17 
 
Listas de chequeo de 
artefactos para revisiones 
e inspecciones. 
R
e
g
u
la
r 
Las listas de chequeo han sido preparadas con 
anterioridad, sin embargo, éstas no han sido 
adecuadamente utilizadas para las revisiones e 
inspecciones a lo largo del ciclo. 
Número de 
recomendaciones 
establecidas en las 
revisiones. 
E
x
c
e
le
n
te
 
De acuerdo al proceso de calidad establecido 
conjuntamente entre los miembros del grupo, se 
realizaron las modificaciones directamente sobre 
los artefactos, con un promedio de 12 
modificaciones por artefacto revisado. 
Artefactos alineados a los 
estándares definidos. 
B
u
e
n
o
 
Los artefactos se encuentran alineados a 
estándares en un 80%. La falta de seguimiento de 
las plantillas evitó que se cumplieran algunos de los 
estándares predefinidos. 
10 o menos defectos por 
KLOC hallados durante la 
compilación. 
B
u
e
n
o
 
Se encontraron en promedio 7,2 defectos por KLOC 
durante la compilación. 
5 o menos defectos por 
KLOC hallados en la fase 
de pruebas. 
R
e
g
u
la
r 
Las pruebas locales funcionaron correctamente. 
Sin embargo, al tratar de exponer como un servicio, 
el componente no funcionó adecuadamente. 
0 defectos hallados 
después de la fase de 
pruebas. 
N
o
 a
p
lic
a
 La medida no ha podido ser verificada, puesto que 
aún la herramientano ha superado la etapa de 
pruebas. 
Objetivos específicos de rol. Tomado de Archila et ál., 2010. 
 
En el ejemplo anterior se muestra las métricas de calidad establecidas por el equipo 
de trabajo, a las cuales se le asigna un resultado que de igual manera se analiza en 
forma conjunta por el líder de proyecto y los integrantes del equipo, donde se verifica 
con el objetivo propuesto por el responsable de llevar el rol que, en este caso, es el 
líder de calidad. Al final se debe hacer una conclusión o diagnóstico de los resultados 
obtenidos, en ellos se determina si se cumplió o no con los objetivos propuestos o de 
qué manera pueden mejorar. 
 
La revisión de resultados se debe realizar con cada uno de los integrantes del equipo, 
comparar y revisar los datos planeados, para que finalmente se evalúe la calidad del 
producto obtenido. Cuando se concluya con el diagnóstico para cada uno de los 
integrantes del equipo se debe realizar una serie de recomendaciones y 
observaciones que puedan ser de ayuda para poder mejorar sus procesos para los 
siguientes proyectos. 
 
En conclusión, si no se realiza un diagnóstico de las métricas de calidad con el trabajo 
realizado al final de cada proyecto en la fase de post mortem, no se podrán detectar 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
18 
 
las áreas de oportunidad y mejora; por ello es necesario analizar lo que se planeó al 
inicio del proyecto y verificar el cumplimiento de los objetivos. 
 
3.2.2. Elaborar el análisis del desempeño del equipo 
 
Ahora se abordarán los temas correspondientes a la realización del análisis de 
desempeño del equipo, el cual consiste en un estudio y evaluación del desempeño 
conseguido por el equipo, y del resultado obtenido durante el desarrollo del software. 
Esto se realiza en el paso final del proceso de TSP post mortem. Dentro de ésta se 
debe analizar el desempeño de los objetivos del equipo con base en la calidad, costos 
y el tiempo que se utilizó para el cumplimiento de los objetivos planteados por el 
equipo (Humphrey, 1999). 
TSP recomienda que antes de comenzar con la recolección de información se debe de 
tomar en cuenta de qué forma van a ser utilizados los datos recolectados; por eso se 
debe generar un plan de recolección de información, ya que de no hacerlo se puede 
llegar a perder tiempo en el proceso. 
El gestor de configuración es el encargado de preparar con anticipación la forma en 
que se va a recolectar la información; pide a los miembros del equipo que recolecten la 
información de tal manera que pueda ser presentada durante las reuniones para llevar 
a cabo el post mortem en la culminación del proyecto. 
Cada uno de los integrantes del equipo de proyecto debe tener una adecuada actitud 
durante esta fase, que inicia con las reuniones de los integrantes del equipo, donde se 
realizan las siguientes actividades (Humphrey, 2006): 
Descripción general: se debe realizar un resumen de los resultados obtenidos en 
cada paso del proceso de desarrollo del proyecto, en donde se recogen opiniones y 
observaciones por parte de los miembros del equipo. Es de suma importancia que los 
integrantes del equipo tengan una actitud objetiva. 
Revisar lanzamiento de datos: en este proceso es el gerente de planeación el 
encargado de llevar acabo las reuniones en donde se revisan los datos del 
lanzamiento; debe asegurarse que todos los datos obtenidos estén completos, sean 
precisos y estén disponibles para su revisión. Más adelante se verá una plantilla para 
realizar estas actividades. 
Preparar la propuesta de mejora de procesos: consiste en generar comentarios y 
sugerencias, por porte de los integrantes del equipo, sobre cómo poder mejorar los 
procesos a partir de la experiencia de proyectos pasados. 
Evaluación de lanzamiento: el líder del proyecto y los integrantes del equipo deben 
llevar a cabo la evaluación del lanzamiento del proyecto al culminar todo el proceso. 
Esta evaluación se utiliza para controlar la calidad del proceso de lanzamiento del TSP 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
19 
 
de tal manera que se pudenda identificar los procesos o áreas que se deben cambiar o 
mejorar. Para realizar la evaluación debe llenarse los formularios correspondientes. 
Reunión de la documentación del lanzamiento: se debe reunir la documentación de 
la propuesta de mejora de procesos y otras propuestas de manera correcta, además 
de darlas a conocer a las personas indicadas para que se lleven a cabo. 
A continuación se explica un ejemplo con los elementos necesarios para elaborar el 
documento post mortem basado en el TSP (Toro, Escallón, Villegas y Mariño, 2009). 
Introducción: es una breve explicación del contenido. 
Propósito: se redacta lo que se espera de la realización de este documento. 
Análisis por fase: se debe revisar cada una de las actividades que se realizaron en 
cada una de las fases del ciclo de vida del TSP. 
TSP recomienda primero hacer una breve descripción de lo que se realizó en cada 
etapa, después se hace uso de una tabla como la siguiente, para organizar la 
información: 
 Plan Actual 
Semana Fecha Horas 
direct
as 
Horas 
acumul
adas 
Valor 
planeado 
ganado 
Hora
s del 
equi
po 
Horas 
acumula
das 
Valor 
gana
do 
por 
sema
na 
Acumula
ción del 
valor 
ganado 
núm. 
1 01/04/2009 48 43 14,33 48 48 14,33 14,33 
2 08/04/2009 48 91 30 48 96 30 44,33 
3 15/04/2009 68 159 49,33 64 160 23 67,33 
4 27/04/2009 93 252 82,33 109 269 32,33 99,67 
5 04/05/2009 48 300 100 31 300 0,33 100 
Ejemplo de revisión post mortem por ciclos del proyecto ECOSSOCCER. Tomado de Toro, Escallón, 
Villegas y Mariño, 2009. 
En la tabla anterior se muestran las horas planeadas para realizar las actividades en la 
fase del lanzamiento. Del lado izquierdo se observan las horas planeadas por semana 
y del lado derecho el valor de cumplimiento de lo planeado. 
 
 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
20 
 
A continuación se elabora la siguiente tabla para verificar el cumplimiento de las 
tareas. 
Ejemplo de revisión de tareas del proyecto ECOSSOCCER. Tomado de Toro, Escallón, Villegas y Mariño, 
2009. 
Resultados: se describen los resultados obtenidos en la fase. 
Conclusión: se hace un comentario en general de lo que se programó y lo que se 
obtuvo en la fase. 
Lecciones aprendidas: al evaluar cada uno de los ciclos del TSP durante el 
desarrollo del proyecto, se toman en cuenta una serie de criterios con el fin de detectar 
en dónde se falló y qué se puede hacer para mejorar; por ejemplo, si los problemas 
que se encontraron fueron más concurrentes en la codificación, en la disciplina de 
trabajo, etcétera, y cómo se actuó ante estas situaciones. Finalmente, se hacer una 
recomendación para mejorar para los siguientes proyectos. 
Evaluación personal y de equipo: en esta actividad se debe llevar acabo la 
evaluación del rendimiento del equipo y de cada uno de sus miembros. A continuación 
se muestra el formato utilizado para un proyecto de desarrollo de software que lleva 
por nombre ECOOSSOCCER, donde se evalúa el rendimiento o desempeño de los 
miembros del equipo durante cada ciclo.
Fase Parte Nombre de la tarea 
Lanzamiento Alcance 
Realizar la carta de constitución del proyecto con los 
objetivos y alcance del mismo. 
Lanzamiento Equipo Conformación del equipo de trabajo. 
Lanzamiento Roles 
Asignación de roles a cada miembro del equipo de 
trabajo. 
Lanzamiento Glosario Elaboración del glosario de términos del proyecto. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
21 
 
 
Nombre Adrián Villegas Equipo ESG Líder de 
Proyecto 
Dalia Trujillo 
Fecha 29/04/2009 Ciclo núm. 01 Semana 
núm. 
 05 
 
Para cada rol, evalúa el trabajo requerido y la dificultad relativa en % durante este ciclo. 
Rol Trabajo Requerido Dificultad del Rol 
Jefe deEquipo 15 15 
Gerente de Desarrollo 25 15 
Gerente de Planeación 25 30 
Calidad/Gerente de 
Proceso 
25 30 
Gerente de Soporte 10 10 
Total Contribución 
(100%) 
100 100 
 
Evalúa el total del equipo en cada criterio: indique un número del 1 (mín.) a 5 (máx.). 
Actitud Equipo 1 2 3 4 5 
Efectividad Global 1 2 3 4 5 
Experiencia Gratificante 1 2 3 4 5 
Productividad del 
Equipo 
1 2 3 4 5 
Calidad del Proceso 1 2 3 4 5 
Calidad del Producto 1 2 3 4 5 
 
Evalúa rol por contribución total: indique un número del 1 (mín.) a 5 (máx.). 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
22 
 
Líder de Equipo 1 2 3 4 5 
Gerente de Desarrollo 1 2 3 4 5 
Gerente de Planeación 1 2 3 4 5 
Calidad/Gerente de 
Proceso 
1 2 3 4 5 
Gerente de Proceso 1 2 3 4 5 
 
Evalúa cada rol por ayuda y soporte: indique un número del 1 (mín.) a 5 (máx.). 
Jefe de Equipo 1 2 3 4 5 
Gerente de Desarrollo 1 2 3 4 5 
Gerente de Planeación 1 2 3 4 5 
Calidad/Gerente de 
Procesos 
1 2 3 4 5 
Gerente de Soporte 1 2 3 4 5 
 
Evalúa rol respecto a su desempeño: indique un número del 1 (mín.) a 5 (máx.). 
Líder de Proyecto 1 2 3 4 5 
Gerente de Desarrollo 1 2 3 4 5 
Gerente de Planeación 1 2 3 4 5 
Calidad/Gerente de 
Procesos 
1 2 3 4 5 
Gerente de Soporte 1 2 3 4 5 
 
Ejemplo de formulario de evaluación personal y del equipo. Tomado de Toro, Escallón, Villegas y 
Mariño, 2009. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
23 
 
 
En el ejemplo anterior se representa la puntuación que se le asignó a los diferentes 
roles de un equipo de trabajo durante el desarrollo del proyecto. 
Reporte de errores y control de cambios del proyecto: es un formato donde se 
registran los problemas encontrados en alguna fase o actividad, dentro del desarrollo 
del proyecto, para después hacer los cambios correspondientes y darles solución. 
Estos ajustes serializan en un documento llamado control de cambios. Siguiendo con 
el ejemplo del proyecto ECOOSSOCCER, que se mostró anteriormente, ahora se 
ejemplificará una tabla para llevar el control de cambios del proyecto, así como el 
reporte de errores. 
Nombre Grupo Experto de Software Fecha 12/04/09 
Equipo ESG (Grupo de Expertos de Software) Líder de 
proyecto 
Dalia 
Trujillo 
Parte Nuevos requerimientos del proyecto en la 
etapa de programación o desarrollo. 
Ciclo 1 
Fecha Evento Numero 
de control 
de 
cambios 
(revisión) 
 Priorida
d 
 Respo
nsable 
 Fecha 
de 
Seguimi
ento 
 Resuelto 
09/04/
09 
 Control 
de 
Cambio
s de 
requeri
mientos 
 1 Alta Guiller
mo 
Toro 
 15/04/09 Sí 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
24 
 
Descripción 
Es necesario redefinir los casos de uso a partir del análisis y 
la validación que se realizó sobre la arquitectura y la 
navegabilidad de los casos de uso. 
1. Consultar disponibilidad: se deben tener los caminos 
alternativos (consulta para el día actual y consulta con 
fecha y hora especificas) como opciones dadas desde el 
principio. 
2. Reserva: el nombre del cliente está almacenado en la 
base de datos, por lo tanto, sólo se ingresa la cédula del 
cliente para validar que exista. En la programación se 
asume que la base de datos está poblada con todos los 
campos en estado disponible. 
3. Legalizar: el nombre del cliente debe estar creado en la 
base de datos. 
4. Alquilar: el nombre del cliente debe estar creado en la 
base de datos. 
5. Recaudo: generar una clase que tenga como atributos la 
fecha, el campo y el movimiento; y otra de Recaudado 
para realizar la consulta. 
 
Se deben volver a redactar las especificaciones de todos los 
casos de uso para que puedan tener el control que se 
estableció, según el análisis realizado a la arquitectura. 
Dichos cambios ayudarán a tener un alcance definido en 
cada funcionalidad, y una especificación más clara al 
momento de implementarlas. 
LOG (bitácora) de eventos y cambios en el proyecto. Tomado de Toro, Escallón, Villegas y Mariño, 
2009. 
En el ejemplo anterior se describe la razón de los cambios en esta fase de los 
procesos. Esto es muy común ya que, durante el desarrollo del proyecto, pueden 
presentarse situaciones que lleven a la necesidad de hacer cambios en los planes 
previamente formulados. 
Reporte final de la línea base: debe contener los siguientes datos. 
1. Introducción: breve introducción del contenido del reporte. 
 
2. Ítem de configuración: se refiere a cada uno de los procesos donde se tienen 
que revisar los documentos que se elaboraron en cada fase del ciclo de vida del 
TSP. 
 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
25 
 
 
Introducción 
Ítem de configuración 
Sigla Categoría Artefactos 
Fases 
Lanzamiento LZ SCOPE Carta de constitución del proyecto 
TEAM Asignación de roles 
Planeación PL MODEL Modelo conceptual 
REQU Diagrama casos de uso 
Listado de requerimientos y casos de 
uso 
PLAN Estimación 
Plan del equipo de trabajo 
Cronograma 
Requerimientos RQ SPEC Especificación de casos de uso 
Trazabilidad de casos de uso y 
requerimientos 
Diseño de arquitectura DA ARCH Documento de diseño de arquitectura. 
Documento con el diseño detallado de 
arquitectura 
Código fuente CF SOURCE Archivos fuentes 
Librerías 
COMP Componentes de software 
FILES Archivos externos (imágenes, videos, 
etcétera) 
Testing TS PLAN Plan de pruebas 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
26 
 
Reporte de pruebas 
Cierre PM REPORT Historia del proyecto 
Artefactos de cierre TSP 
Ejemplo de los ítems de configuración. Tomado de Toro, Escallón, Villegas y Mariño, 2009. 
 
3. Seguimiento de actividades de los miembros del equipo: se realiza durante las 
reuniones de la fase post mortem donde, para llevar el control de las actividades de 
cada uno de los integrantes del equipo se debe utilizar el siguiente formulario: 
Nombre Adrián Villegas Fecha 31/03/09 
Equipo ESG (Grupo de Expertos de Software) Instructo
r 
Dalia Trujillo 
Parte/nivel Ciclo 1 
 
Fecha Inicio Fin Tiempo de 
interrupción 
Tiempo 
delta 
Fase/tarea Compone
nte 
Comentarios 
03/21/
09 
14:00 18:00 00:30 3:30 Lanzamiento Enuncia
do 
Elaboración 
del 
enunciado 
del 
problema. 
03/21/
09 
18:00 22:00 00:30 3:30 Lanzamiento Alcance Realizar la 
carta de 
constitución 
del proyecto 
con sus 
objetivos y 
alcance. 
03/22/
09 
12:00 14:00 0:00 2:00 Lanzamiento Roles y 
Equipo 
Conformaci
ón del 
equipo de 
trabajo. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
27 
 
03/22/
09 
14:00 18:00 1:00 3:00 Lanzamiento Roles y 
Equipo 
Asignación 
de roles a 
cada 
miembro del 
equipo de 
trabajo. 
03/22/
09 
19:00:
00 
21:00:
00 
00:00 2:00 Requerimient
os 
Requeri
mientos 
Validación y 
listados 
finales de 
requerimient
os y casos 
de uso con 
el grupo. 
 
03/30/
09 
21:00:
00 
23:00:
00 
00:00 2:00 Requerimient
os 
Requeri
mientos 
Especificaci
ón del caso 
de uso de 
realizar 
alquiler 
3/30/0
9 
00:00:
00 
01:00:
00 
00:00 1:00 Requerimient
os 
Requeri
mientos 
Prototipo 
del caso de 
uso realizar 
alquiler. 
 
02/04/
09 
19:00 21:00 00:00 2:00 Planeación 
de trabajo 
Planeaci
ón 
Revisión de 
las 
correccione
s a realizar 
sobre el 
proyecto. 
Definición 
del plan de 
trabajo. 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
28 
 
04/04/
09 
08:00 22:00 01:00 13:00 Lanzamiento
–estrategia–
requerimient
os 
Artefacto
s 
Correccione
s sobre 
todos los 
artefactos 
de dichas 
fases y 
elaboración 
de nuevos 
artefactos. 
05/04/
09 
09:00 23:00 01:00 13:00 Planeación-
requerimient
os 
Artefacto
s 
Correccione
s sobre 
todos los 
artefactos 
de dichas 
fases y 
elaboración 
de nuevos 
artefactos. 
 
18/04/
09 
09:00 23:00 01:0013:00 Diseño Revisión Revisión de 
tareas 
pendientes 
según 
cronograma 
de tareas de 
diseño. 
 
17/04/
09 
21:00 23:00 00:30 1:30 Construcción Revisión 
de caso 
de uso 
Revisión de 
los flujos del 
caso de uso 
para 
inspecciona
r y visionar 
la manera 
de 
implementar
lo. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
29 
 
17/04/
09 
09:00 15:00 01:00 5:00 Construcción 
 
 
 
Revisión 
de caso 
de uso 
Reunión 
con el grupo 
para validar 
el prototipo 
arquitectural 
y realizar 
primeras 
pruebas de 
funcionalida
des. 
20/04/
09 
21:00 23:00 00:00 2:00 Construcción Desarroll
o de 
caso de 
uso 
Desarrollo 
de 
funcionalida
d de 
generar 
reporte de 
recaudo 
diario. 
21/04/
09 
21:00 01:00 00:30 02:30 Construcción Desarroll
o de 
caso de 
uso 
Desarrollo 
de 
funcionalida
d de 
generar 
reporte de 
recaudo 
diario con 
sus 
respectivas 
pruebas 
unitarias. 
 
26/04/
09 
14:00 20:00 01:00 05:00 Construcción Desarroll
o de 
caso de 
uso 
Desarrollo 
de 
funcionalida
d de 
generar 
reporte de 
recaudo 
diario con 
sus 
respectivas 
pruebas 
unitarias. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
30 
 
27/04/
09 
20:00 23:00 0:30 2:30 Post mortem Evaluaci
ón 
Evaluación 
de los 
diferentes 
roles de 
TSP en el 
proyecto. 
28/04/
09 
20:00 23:00 0:30 2:30 Post mortem Evaluaci
ón 
Evaluación 
del 
desempeño 
del equipo 
el proyecto. 
Ejemplo de control de actividades por cada uno de los miembros del equipo. Tomado de Toro, Escallón, 
Villegas y Mariño 2009. 
 
 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
31 
 
3. Seguimiento del proyecto: se da seguimiento a las tareas realizadas durante el desarrollo del proyecto mediante una plantilla 
como la siguiente. 
Tareas Horas del plan Plan de 
tamaño/valor 
Actual 
F
a
s
e
 
P
a
rt
e
 
N
o
m
b
re
 d
e
 l
a
 t
a
re
a
 
N
ú
m
. 
d
e
 i
n
g
e
n
ie
ro
s
 
L
íd
e
r 
d
e
 e
q
u
ip
o
 
G
e
re
n
te
 d
e
 d
e
s
a
rr
o
ll
o
 
G
e
re
n
te
 d
e
 p
la
n
e
a
c
ió
n
 
G
e
re
n
te
 d
e
 C
a
li
d
a
d
/ 
p
ro
d
u
c
to
 
G
e
re
n
te
 d
e
 s
o
p
o
rt
e
 
T
o
ra
l 
d
e
 h
o
ra
s
 d
e
 e
q
u
ip
o
 
H
o
ra
s
 a
c
u
m
u
la
d
a
s
 
T
a
m
a
ñ
o
 d
e
 u
n
id
a
d
e
s
 
T
a
m
a
ñ
o
 
N
ú
m
. 
s
e
m
a
n
a
 
V
a
lo
r 
p
la
n
e
a
d
o
 
A
c
u
m
u
la
d
o
s
 
H
o
ra
s
 
H
o
ra
s
 a
c
u
m
u
la
d
a
s
 
S
e
m
a
n
a
 
Lanzamiento Alcance 
Realizar la carta de 
constitución del 
proyecto con sus 
objetivos y alcances. 
4 3 3 6 6 Hojas 3 1 2 2 8 8 1,2,3 
Lanzamiento Equipo 
Conformación del 
equipo de trabajo. 
4 1 1 1 1 1 5 11 Hojas 4 1 
1,
67 
3,
67 
5 13 1,2,3 
Lanzamiento Roles 
Asignación de roles a 
cada miembro del 
equipo de trabajo. 
2 2 2 4 15 Hojas 2 1 
1,
33 
5 4 17 1,2,3 
Lanzamiento Glosario 
Elaboración del 
glosario de términos 
1 1 1 1 1 1 5 20 Hojas 10 1 
1,
67 
6,
67 
3 20 1,2,3 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
32 
 
 
 
 
Seguimiento del proyecto. Tomado de Toro, Escallón, Villegas y Mariño 2009. 
 
En este ejemplo se observan las tareas que fueron planeadas en la fase de lanzamiento para cada uno de los roles del proyecto, así 
como las horas asignadas para cada miembro del equipo. Se observa el nombre de la actividad que se planeó y realizo así como las 
horas necesarias para llevarlas a cabo. Por ejemplo, en la fase de lanzamiento se planearon tres horas para que el líder de proyecto 
forme el equipo de trabajo con cuatro involucrados en conjunto con el gerente de planeación, al cual se le estimaron tres horas para 
culminar sus tareas con un total de horas acumuladas de seis, también se pueden observar las semanas en que se realizaron las 
actividades. 
 
 
 
 
 
del proyecto. 
Lanzamiento 
Estrategi
a 
Definir el ciclo de vida 
de desarrollo. 
2 4 3 7 27 Hojas 3 1 
2,
33 
9 4 24 1,2,3 
Lanzamiento 
Estrategi
a 
Elaborar el diseño 
conceptual. 
1 3 3 30 Hojas 2 1 1 10 2 26 1,2,3 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 33 
5. Reporte de cronograma. Se genera un horario para elaborar un reporte de cronograma 
donde se compara lo planeado con los resultados obtenidos, tal como el siguiente: 
 
Al concluir con las actividades se hace un análisis de los datos obtenidos configurando un 
reporte de calidad; para ello, se puede hacer uso de los siguientes elementos. 
Logros alcanzados: se hace una revisión de los logros que se pudieron alcanzar y que 
fueron planeados previamente, con una breve descripción de la actividad que se cumplió. 
Problemas encontrados: se identifican eventos o actividades en las que se tuvieron 
problemas para cumplir los objetivos, se describe porque fue que no se cumplió con lo 
planeado o si se pudo encontrar una solución para que se pudiera completar la actividad. 
Lecciones aprendidas: esto se obtiene por medio de los problemas encontrados, ya que 
se pude aprender de los errores para prevenir que se presenten en los futuros proyectos, 
así como también se puede aprender de las actividades que se completaron sin 
contratiempos. 
Oportunidades de mejora: con base en los problemas que se presentaron y las 
actividades que se cumplieron sin ningún problema, se detecta en qué se falló o la 
manera en que se pude mejorar para los siguientes proyectos. 
Nombre: Fecha: 
Equipo: Instructor: 
Nivel: Ciclo: 
 
 Plan Actual 
Semana Fecha Horas 
directa
s 
Horas 
acumulada
s 
Acumulaci
ón de valor 
planeado 
Horas 
del 
equipo 
Horas 
acumulad
as 
Semana 
valor 
agregad
o 
Acumulaci
ón de valor 
ganado 
Núm. 
1 01/04/2009 48 43 14,33 48 48 14,33 14,33 
2 08/04/2009 48 91 30 48 96 30 44,33 
3 15/04/2009 68 159 49,33 64 160 23 67,33 
4 27/04/2009 93 252 82,33 109 269 32,33 99,67 
5 04/05/2009 48 300 100 31 300 0,33 100 
Reporte de cronograma programado. Tomado de: Toro, Escallón, Villegas y Mariño 2009. 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 34 
Toda esta información debe ser registrada de manera conjunta entre líder de proyecto y 
los integrantes del equipo para evaluar los resultados obtenidos, incluyendo al 
administrador del proyecto. 
En conclusión, el objetivo principal del post mortem, ya sea de manera individual o en 
equipo, es proporcionar información y conocimientos para que sea posible mejorar 
significativamente el desempeño de las tareas asignadas. Es importante tomar en cuenta 
que, cada uno de los integrantes que conforman el equipo debe estar comprometido en la 
recopilación de la información general desde el inicio hasta la culminación del proyecto. El 
post mortem se debe realizar al final de cada ciclo y de todo proyecto, tal como lo marca 
las fases del ciclo del vida del TSP. 
 
Cierre de la unidad 
 
En esta unidad aprendiste la importancia de realizar el monitoreo y control del proyecto, 
para saber si marcha según lo planeado al inicio. También aprendiste a elaborar las 
plantillas de revisión de la administración y la de reporte administrativo del estatus. 
 
Asimismo, estudiaste la fase post mortem de TSP, que proporciona una retroalimentación 
de los aciertos y errores en el desarrollo del proyecto; la forma de comparar las métricas 
de calidad contra el trabajo realizado por parte del equipo y la manera de elaborar el 
análisis su desempeño. 
 
Como conclusión de la asignatura, es importante remarcar que para que un proyecto de 
desarrollo de software tenga éxito y se cumplan los objetivos planteados al inicio, se 
necesita una metodología de calidad como TSP, que te aporta una guía de lo que debes 
hacer para que tu proyecto se llevea cabo y logre la calidad deseada. 
 
Ojalá que la información aquí proporcionada te sirva para lograr el éxito deseado en los 
proyectos que realices en tu vida profesional, sepas qué hacer cuando un proyecto de 
desarrollo de software no marche conforme lo planeado, y seas capaz de dar soluciones a 
los problemas que se presenten dentro de la empresa o proyectos en los que estés 
laborando o te integres en un futuro. 
 
 
 
Desarrollo de software en equipo TSP 
Unidad 3. Gestión en TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 35 
Para saber más 
 
En esta página encontrarás información diversa acerca de las herramientas de medición 
de la calidad del desarrollo de software, entre ellas TSP, así como diversos artículos y 
documentos sobre dicha metodología. 
Software Engineering Institute Carnegie Mellon (2013). 
https://resources.sei.cmu.edu/library/index.cfm?fp=sei_topic:Process+Improvement&globa
l=true 
Blog del Software Engineering Institute Carnegie Mellon (2013). Recuperado de: 
https://www.sei.cmu.edu/ 
Fuentes de consulta 
 
• Archila, A. et ál. (2010). Informe Postmortem. Proceso de originación de crédito, 
Banco de los Alpes. 
 
• Esterkin, J. (2008). Qué es y cómo se hace un reporte de estado del proyecto. 
México: IAAP. 
 
• Gómez, A. (2008). Introducción a la Computación. México: Cenage Learning. 
 
• Reyes, Pulido González, Martínez Guzmán, Arredondo Reyes, Á. A. L. M. M. L. V. 
M. (s. f.). Team Software Process. www.uv.mx. Recuperado 31 de enero de 2022, 
de https://www.uv.mx/personal/ermeneses/files/2021/05/TSP-FebJul2021.pdf 
 
• Toro, G., Escallón, H., Villegas, A. y Mariño, K. (2009). Modelos y estándares de 
procesos de desarrollo de software. Bogotá: Universidad de los Andes. 
 
• Humphrey, W. (1999). Introduction to the Team SoftwareProcess. Massachusetts: 
Addison Wesley Professional. 
 
• Humphrey, W. S. (2006). TSP(SM)—Coaching Development Teams. Addison 
Wesley Professional. 
https://resources.sei.cmu.edu/library/index.cfm?fp=sei_topic:Process+Improvement&global=true
https://resources.sei.cmu.edu/library/index.cfm?fp=sei_topic:Process+Improvement&global=true
https://www.sei.cmu.edu/
https://www.uv.mx/personal/ermeneses/files/2021/05/TSP-FebJul2021.pdf
	Unidad 3. Gestión en TSP
	Presentación de la unidad
	Logros
	Competencia específica
	3.1. Monitoreo y control del proyecto
	3.1.1. Ejecutar la revisión de la administración del proyecto
	3.1.2. Elaborar el reporte administrativo del estatus del proyecto
	3.2. Análisis post mortem
	3.2.1. Diagnóstico: métricas de calidad versus trabajo realizado
	3.2.2. Elaborar el análisis del desempeño del equipo
	Cierre de la unidad
	Para saber más
	Fuentes de consulta