Unidad 3 Gestion en TSP

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 
 
8º Cuatrimestre 
 
 
 
 
Unidad 3. Gestión en TSP 
 
 
 
Clave: 
150930934 
 
 
 
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 
Propósitos .......................................................................................................................... 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 
Actividad 1. Evidencia de administración de trabajo y calidad del proyecto. ...................... 6 
3.1.2. Elaborar el reporte administrativo del estatus del proyecto ...................................... 6 
Actividad 2. Reporte del seguimiento del proyecto ........................................................... 14 
3.2. Análisis postmortem .................................................................................................. 14 
3.2.1. Diagnóstico: métricas de calidad versus trabajo realizado ..................................... 15 
3.2.2. Elaborar el análisis del desempeño del equipo ...................................................... 20 
Autoevaluación ............................................................................................................... 36 
Evidencia de aprendizaje. Generación del reporte de calidad del proyecto ...................... 36 
Autorreflexiones ............................................................................................................... 36 
Cierre de la unidad .......................................................................................................... 37 
Para saber más ............................................................................................................... 38 
Fuentes de consulta ........................................................................................................ 38 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
2 
 
Unidad 3. Gestión en TSP 
 
Presentación de la unidad 
 
Te damos la más cordial bienvenida a la Unidad 3 Gestión en TSP, en la cual 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 
postmortem, 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 postmortem 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 poder considerarlo para futuros proyectos. 
Propósitos 
 
Al finalizar el estudio de esta unidad podrás: 
 
 Determinar la función de gestión a partir de la metodología Team Software Process 
(TSP), para que evalúen el avance que va teniendo el desarrollo del proyecto. 
 Identificar el estatus del proyecto a partir de un reporte para saber el estado actual 
en que se encuentre el proyecto. 
 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 va marchando 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 relacionadas al proyecto se 
realicen en forma adecuada, así como el seguimiento del presupuesto que se asignó 
para la elaboración del proyecto y recursos humanos involucrados en el proyecto. 
 
Para la supervisión y seguimiento del proyecto, es necesario realizar acciones de 
monitoreo y control del proyecto 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 trazados al inicio del mismo 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 del proyecto 
implementando 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, el 
plan de riesgos y el plan de proyecto. Cuando se ejecuta el plan de calidad se hacen 
las revisiones de código correspondientes al diseño y el desarrollo del proyecto. En 
este capítulo aprenderás a realizar la revisión pero 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 postmortem en 
un proyecto que está ocupando la metodología TSP. 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 está desarrollando 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 aparte se 
tendrá que desarrollar la parte del software donde realizarán las ventas de los 
productos. Aquí el software se dividirá en dos módulos, uno que se encargará de la 
parte de la fabricación de los productos y el otro se encargará de llevar acabo las 
ventas 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 fue liberado 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
4 
 
correctamente. El segundo módulo se revisó por parte del equipo de calidad pero se 
encontró que más de la mitad del módulo tiene aún errores. 
Siguiendo el ejemplo anterior el equipo de desarrollo y diseño primero entregará el 
módulo correspondiente a la parteque se va a dedicar a la fabricación de los 
productos y después se entregará el módulo que se refiere a la venta de los mismos. 
El equipo de calidad y los administradores del proyecto evaluarán, revisarán y 
aprobarán cada módulo, como se vaya terminando de revisar, si el sistema tiene aún 
errores se regresarán a el equipo de desarrollo, para que realicen las modificaciones 
correspondientes. 
Para hacer este seguimiento de la administración del proyecto, TSP proporciona una 
plantilla para hacer la revisión de la situación del proyecto de acuerdo a las pruebas 
realizadas llamada “Plantilla de revisión de la administración del proyecto” y que se 
observa a continuación. 
Nombre del 
módulo 
Nombre del 
encargado de la 
revisión 
Nombre del 
rol 
Porcentaje 
completado 
Observacione
s 
Ventas 
Fabricación de 
productos 
 
 
 
 
 
Plantilla de revisión de la administración del proyecto. (Humphrey, 2006). 
Recuerda que esta plantilla puede ir en un documento de Word con un control de 
cambios tal como se menciona en la unidad 2 en el tema 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 “Plantilla de revisión de la administración del proyecto.”: 
Nombre del módulo: En esta columna se integrará el nombre del módulo continuando 
con el ejemplo anterior se mencionan dos módulos, uno lleva por nombre ventas y el 
otro se llamará 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 dependiendo del número de módulos. 
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. 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
5 
 
Nombre del rol: En esta columna se escribirá el rol del encargado de las pruebas del 
módulo, este rol se obtiene de acuerdo al rol que se le haya asignado según la 
metodología TSP y el equipo en el que se encuentre. 
Porcentaje completado: El porcentaje completado del módulo correspondiente, se 
integra en una columna identificada con colores dependiendo del porcentaje concluido 
del módulo correspondiente, a continuación explicaré detalladamente: 
Porcentaje completado 
0 a 40% 
41 a 80% 
81 a 100% 
 
Observaciones: En esta columna el encargado de hacer la plantilla que será el 
administrador de calidad, integrará sus observaciones en cuanto a la revisión del 
módulo. 
Retomando el ejemplo anterior, se expone el llenado de una plantilla de revisión de la 
administración del proyecto. 
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 
regresaron al 
equipo de 
desarrollo para 
que realicen las 
modificaciones 
correspondiente
s 
 
Es importante mencionar que los porcentajes de completado se definen 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. 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
6 
 
En conclusión, se puede decir que esta plantilla es importante, por que proporciona 
una clara idea del estado del proyecto una vez que ya se han ejecutado 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 el cual 
se abordará en el siguiente capítulo antes de pasar a la fase postmortem de TSP. 
 
 
Actividad 1. Evidencia de administración de trabajo y calidad del 
proyecto. 
 
Esta actividad tiene como propósito que integres los elementos de la Plantilla de 
revisión de la administración del proyecto e identifiques su relación con elementos de 
calidad del proyecto mediante el planteamiento de un problema correspondiente a un 
proyecto de software que te hará llegar tu Facilitador(a), una vez que cuentes con él: 
 
1. Identifica los elementos de la plantilla de revisión de la administración del 
proyecto: nombre del módulo, nombre del encargado de la revisión, nombre 
del rol, porcentaje completado, observaciones. 
 
2. Genera la Plantilla de revisión de la administración del proyecto. 
 
3. Redacta tus conclusiones acerca de los elementos que integran esta plantilla 
y por qué son importantes para la revisión de la administración del proyecto. 
 
4. Guarda la actividad con el nombre DDSE_U3_A1_XXYZ. Sustituye las XX 
por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y 
la Z por tu segundo apellido. 
 
5. Envía tu actividad al facilitador mediante la herramienta Tareas. 
 
*No olvides consultar el documento Criterios de evaluación para las actividades de 
la unidad 3 donde podrás conocer los parámetros de evaluación de esta actividad. 
 
 
 
 
 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
7 
 
3.1.2. Elaborar el reporte administrativo del estatus del proyecto 
 
En este capítulo se abordará lo correspondiente al reporte administrativo del estatus 
del proyecto, este reporte es esencial para poder conocer el estado actual del proyecto 
en general y si los tiempos y costos del proyecto no han rebasado lo planeado. 
Un reporte de estatus del proyecto es un documento que informa el estado actual de 
un proyecto. Su principal propósito es comunicar al receptor si el proyecto 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: Recuerda que un proyecto como se 
mencionó en el capítulo anterior puede dividirse en módulos los cuales se 
entregaran no todos juntos sino uno por uno, a eso se refiere este punto. 
 Actividades relevantes del periodo: Se describen actividades que tengan 
importancia durante el periodo en que se realiza la plantilla 
 Riesgos : se describen los riesgos que surgieron 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 de este reporte es comunicar si el proyecto se va desarrollando 
de acuerdo a lo planeado al inicio del mismo y en caso de que no sea así poder 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í poder buscar y plantear una solución adecuada. En este reporte TSP indica que 
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 y las medidas o accionesque se 
tomaron para corregir este problema, el porcentaje de avance en los entregables los 
cuales se mencionan en la Unidad 1 Introducción a TSP y el costo actual del proyecto. 
La plantilla para elaborar este reporte que TSP brinda tiene por nombre: “Plantilla de 
Reporte administrativo del estatus del proyecto” y es la siguiente: 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
8 
 
Proyecto Nombre del proyecto 
Id Código del identificador (Este código 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 
Compromis
o 
Responsable/R
ol 
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 o 
cerrado 
(Abierto se 
deja cuando no 
se logró el 
avance 
planeado) 
Fecha límite 
en la que 
debe 
cumplirse el 
acuerdo 
Nombre o rol del 
encargado de 
cumplir el 
acuerdo 
Comentarios 
relacionados al 
acuerdo este 
comentarios los 
 
 
 
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 (se refiere a los 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 
Estatus 
0-40% 
41-80% 
81-100% 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
9 
 
Nombre del 
entregable o 
fase 
Indicar el 
estatus del 
entregable 
o fase 
(verde, 
amarillo o 
rojo) 
Cantidad 
asignada al 
entregable o 
fase del 
proyecto(este 
presupuesto 
del proyecto 
se da en la 
fase de 
lanzamiento 
de TSP) 
Costo 
actual del 
entregable 
o fase(es 
el costo del 
proyecto al 
momento 
de realizar 
la plantilla) 
Porcentaje 
del avance 
del 
entregable 
o fase 
Observaciones 
relacionados al 
entregable o 
fase 
 
 
 
Actividades Relevantes del periodo 
 
# Actividad 
 Descripción breve 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 Probabilidad Impact
o 
Prioridad Respues
ta 
Responsab
le 
Número de la 
revisión 
correspondie
nte (1,2,3 
etcétera) 
Descripci
ón del 
riesgo 
Indica 
probabilidad 
de 
ocurrencia(Alt
a, media o 
baja) 
Indica 
si el 
impact
o es 
alto 
medio 
o bajo 
Indica la 
urgencia 
con la que 
debe 
tratarse el 
cambio, se 
debe 
Plan de 
acción 
para 
hacer 
frente 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 
10 
 
analizar el 
impacto 
que tendrá 
en el 
proyecto(Al
to 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 (Siles, 2012). 
Como punto principal esta plantilla la realizará el administrador de proyectos, por lo 
tanto él realizará las observaciones correspondientes que se pidan en la plantilla, más 
adelante, mediante un ejemplo se especificará concretamente. 
Otro punto a remarcar es que todos los estatus se considerarán de acuerdo al avance 
del proyecto y se les asignará un color, a continuación se muestra el color de acuerdo 
al avance del proyecto: 
Porcentaje completado 
0 a 40% 
41 a 80% 
81 a 100% 
 
A continuación se expone un ejemplo mediante el cual se ilustrará la forma de llenar la 
plantilla anterior: 
Se está realizando un proyecto de software que está dirigida al apoyo de servicios 
escolares y administración escolar de una institución educativa el proyecto tienen por 
nombre “Sistema de administración Escolar EscolaRis”, se requiere que el sistema 
permita: 
 A los profesores el poder capturar las calificaciones de los alumnos. 
 Al área de servicios escolares, poder 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 un registro de los alumnos que están 
inscritos en la escuela y también de egresados. 
 A los padres de los alumnos contar con un módulo vía web, que les permita 
conocer sus calificaciones así como las observaciones realizadas por 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 $. 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
11 
 
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 
ser de 40% del total del proyecto al realizar esta tarea se encontraron errores de 
codificación y diseño por lo cual solo 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 está solicitando más requerimientos de los que se 
plantearon al inicio del proyecto y es difícil implementarlos ya cuando 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 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% debido a que se regresó al área 
de desarrollo para hacer las correcciones correspondientes de las observaciones 
hechas por el equipo de calidad. 
 
Estatus 
35% 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
12 
 
Estatus del proyecto a nivel entregable/fase 
 
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 realizaron 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 
el cliente para 
poder realizar 
estos cambios 
una vez que se 
entregue lo 
acordado al 
principio del 
proyecto 
Líder de 
Proyecto03-Mayo-2012 
 
 
 
 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
13 
 
Riesgos 
 
ID Riesgo Probabilidad Impacto Prioridad Respuesta Responsable 
1 Nuevos 
errores 
una vez 
que se 
realice la 
2da 
revisión 
del 
proyecto 
Alta Alto Alta Hacer 
pruebas 
por parte 
del líder 
de 
desarrollo 
antes de 
enviar a el 
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 con 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, estas decisiones sobre la forma de solucionarlas, las tomará la 
alta gerencia. 
En este capítulo 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 capítulo se abordará el tema 
correspondiente a la elaboración de las plantillas en la fase postmortem. 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
14 
 
Actividad 2. Reporte del seguimiento del proyecto 
 
En esta actividad generarás el reporte de seguimiento de un proyecto para saber el 
estatus de avance que se tiene sobre el mismo, para ello, tu Facilitador te hará llegar 
un planteamiento de problema, una vez que cuentes con el planteamiento: 
 
1. Identifica en el problema planteado los elementos necesarios para realizar el 
reporte administrativo del estatus del proyecto. 
 
2. Elabora la “Plantilla de Reporte administrativo del estatus del proyecto.” 
 
3. Redacta tus conclusiones acerca de por qué es importante el reporte 
administrativo del estatus del proyecto en relación con el problema planteado. 
 
4. Guarda la actividad con el nombre DDSE_U3_A2_XXYZ. Sustituye las XX por 
las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z 
por tu segundo apellido. 
 
5. Envía tu actividad al facilitador mediante la herramienta base de datos. 
 
6. Comenta la actividad de por lo menos dos de tus compañeros e identifica 
semejanzas y diferencias respecto a tus propias conclusiones. 
 
*No olvides consultar el documento Criterios de evaluación para las actividades de la 
unidad 3, donde podrás conocer los parámetros de evaluación de esta actividad. 
 
 
 
3.2. Análisis postmortem 
 
En esta unidad se explicarán las actividades que se llevan a cabo en el último proceso 
del TSP que es la fase postmortem, el cual 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 postmortem 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 postmortem sirve de retroalimentación para todos los integrantes del equipo, porque 
se estudia la manera en que se trabajó durante el desarrollo del proyecto, analizando 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
15 
 
la forma de realizar las actividades y detectando 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 
puedan ser más eficaces y puedan considerar los errores y las acciones positivas para 
estar preparados para mejorar en los siguientes proyectos. (Humphrey, 2006) 
Cuando se llega al final de cada ciclo de un proyecto se entra a la fase postmorten 
donde los equipos de TSP cuentan con una gran cantidad de información, la cual 
contiene, entre otros, los siguientes elementos: 
 La calidad de sus productos 
 Estimaciones. 
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 postmortem en la culminación de cada proyecto, aprovechando que 
la información recabada y la experiencia del trabajo realizado por el equipo de 
proyecto son 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 
postmortem tiene el mismo propósito, evaluar los resultados obtenidos verificando y 
verificando 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 calidad versus trabajo realizado 
 
En este capítulo aprenderás a realizar el diagnóstico de las métricas de calidad que se 
realizaron en el plan de calidad el cual se vio en la unidad 2 y comparar con el trabajo 
que se realiza para poder evaluar los resultados obtenidos, es muy importante que se 
tome en cuenta que se debe tener bien comprendido el plan de calidad para poder 
realizar este proceso final postmortem. 
Para poder realizar el diagnóstico de las métricas de calidad contra el trabajo que se 
realizó 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 llevan a cabo y analizar en qué están fallando o la manera 
en que pueden mejorar, así como darles la oportunidad de expresar sus 
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. Recordemos que una métrica es un valor cuantificable que puede ser medible. 
A continuación se muestra un ejemplo sobre el análisis del trabajo realizado por parte 
del gerente de calidad en un proyecto y los resultados conseguidos. En este ejemplo 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
16 
 
se mostrará el trabajo que realizo el Gerente de Calidad mediante un informe 
postmortem para el proyecto que lleva por nombre “Apertura de crédito del Banco de 
Los Alpes” en dicho ejemplo 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, Molano, Kook, Gutiérrez y Larrota, 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. (Archila, Molano, Kook, Gutiérrez 
y Larrota, 2010). 
 
En esta tabla se muestra la distribución de las horas planeadas por semana para la 
realización de las activadas que tiene a su cargo el rol de líder de calidad el cual fue 
planeado por parte del equipo de proyecto y el esfuerzo que se refiere a la suma de 
tiempos dedicados a esa actividad y por último se muestra lo ejecutado que ver el 
cumplimiento real de lo que se plano. 
 
A continuación se describe el objetivo propuesto por el equipo y 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 está dando a la actividad para que pueda ser medido, por 
ejemplo, encontramos en la tabla de objetivos globales de grupo la métrica “Promedios 
de evaluación del rol por ayudar y soporte superior a 4”. El 4 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 aplicablepara su evaluación. 
 
Objetivo 1 
Ser un miembro efectivo y cooperativo. 
 
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. 
Informe de logros del equipo de trabajo: objetivos globales de grupo. (Archila, Molano, 
Kook, Gutiérrez y Larrota, 2010). 
 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
17 
 
En la siguiente tabla se observa el objetivo planeado por el líder de calidad en cuanto 
a la efectividad y cooperación. 
 
Objetivo 2 
Hacer el trabajo personal de manera disciplinada consistentemente. 
 
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. (Archila, Molano, Kook, 
Gutiérrez y Larrota, 2010). 
 
 
Se observa en la siguiente tabla que la métrica cambia a un valor en porcentaje para 
establecer el cumplimiento del objetivo, que está en una escala de %0 a 100% (Ver la 
siguiente tabla Objetivo global líder de calidad-Disciplina). 
 
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 
Calidad” es 100% N
o
 A
p
lic
a
 Las estrategias para consolidar el 
seguimiento personal fueron negociadas 
con el grupo, y 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. (Archila, Molano, Kook, Gutiérrez y Larrota, 
2010). 
 
De la misma manera que los demás objetivos propuestos por el equipo de proyecto se 
revisa el cumplimiento de lo planeado así como su resultado obtenido como se 
observa en la siguiente tabla. 
 
 
 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
18 
 
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. (Archila, Molano, Kook, Gutiérrez y Larrota, 2010). 
 
Para el caso de los objetivos específicos de cada rol se observa siguiendo con el 
mismo ejemplo de rol de Líder de calidad los objetivos propuestos por el equipo de 
trabajo como se observa 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. 
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. 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
19 
 
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 herramienta no ha superado la etapa de 
pruebas. 
Objetivos específicos de rol. (Archila, Molano, Kook, Gutiérrez y Larrota, 2010). 
 
En 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 de 
manera conjunta por el líder de proyecto y los integrantes del equipo donde se va 
verificando 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 estos resultados 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 postmortem, no se podrán detectar 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. 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
20 
 
3.2.2. Elaborar el análisis del desempeño del equipo 
 
En este tema 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 postmortem. Dentro de la fase de 
postmortem se debe analizar el desempeño de los objetivos del equipo, esto debe 
realizarse 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, es por eso 
que se debe generar un plan de recolección de información ya que de no hacerlo se 
puede llegar a perder tiempo en el procesos de recolección de información. 
El gestor de configuración es el encargado de preparar con anticipación la formaen 
que se va a recolectar la información pidiendo a los miembros del equipo la mejor 
manera en que ellos puedan recolectar la información de tal manera que esta 
información pueda ser presentada durante las reuniones que se lleguen a realizar 
para llevar a cabo el postmortem en la culminación del proyecto. 
Cada uno de los integrantes del equipo de proyecto debe tener una adecuada actitud 
durante la fase del postmortem. 
En la fase de postmortem se tiene que iniciar con las reuniones con los integrantes del 
equipo, en el cual 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 de llevar 
acabo las reuniones en donde se revisan los datos del lanzamiento, los cuales debe 
de asegurarse que todos los datos obtenidos sean completos, precisos y que puedan 
estar disponibles para su revisión, mas delante de este capítulo se verá una plantilla 
para realizar estas actividades. 
Preparar la propuesta de mejora de procesos: Esta actividad consiste en generar 
comentarios y sugerencias por porte de los integrantes del equipo sobre cómo poder 
mejorar los procesos con 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 
21 
 
de tal manera que se pudenda identificar los procesos o áreas que se deben de 
cambiar o mejorar. Para poder hacer la evolución de debe de llenar en formularios. 
Reunión de la documentación del lanzamiento: Finalmente se debe reunir la 
documentación de la propuesta de mejora de procesos y otras propuestas de manera 
correcta y dárselas 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 postmortem basado en el TSP (Toro, Escallón, Villegas y Mariño, 2009). 
Introducción: Es una breve explicación del contenido del documento del postmortem. 
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 
No. 
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 (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, en la cual del lado derecho se muestran 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 
22 
 
A continuación se elabora la siguiente tabla para verificar el cumplimiento de las 
tareas. 
Ejemplo de revisión de tareas del proyecto ECOSSOCCER (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 terminar de evaluar cada uno de los ciclos del TSP durante 
el desarrollo del proyecto se toman en cuenta una serie de criterios para 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., 
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 como se mencionó en este 
capítulo se debe llevar acabo la evaluación del rendimiento del equipo y de cada uno 
de los miembros del equipo. 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 
23 
 
Ejemplo de formulario de evaluación personal y del equipo 
 
Nombre Adrián Villegas Equipo ESG Líder de 
Proyecto 
Dalia Trujillo 
Fecha 29/04/2009 Ciclo No. 01 Semana No. 05 
 
Para cada rol, evalúa el trabajo requerido y la dificultad relativa en % durante este ciclo. 
Rol Trabajo Requerido Dificultad del Rol 
Jefe de Equipo 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 
24 
 
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 
(Toro, Escallón, Villegas y Mariño, 2009) 
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: El reporte de errores es 
una documento o formato en donde se registran los problemas encontrados en 
alguna fase o actividad dentro del desarrollo del proyecto para después hacer los 
cambios correspondientes para darle solución estos ajustes serializan en un 
documento llamado control de cambios. Siguiendo con el ejemplo del proyecto 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
25 
 
ECOOSSOCCER, que se mostró anteriormente ahora se ejemplificará una tabla para 
poder 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 Si 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
26 
 
Descripción: 
Fruto de la validació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 (Consultar 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 un clase que tenga como atributos la 
fecha, el campo y el movimiento, y otra clase 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 implementarla. 
LOG (Bitácora) de eventos y cambios en el proyecto. (Toro, Escallón, Villegas y 
Mariño, 2009). 
En el ejemplo anterior se describe el pro que 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: Este reporte debe contener los siguientes datos: 
Introducción: Breve introducción del contenido del reporte. 
Ítem de configuración: Este se refiere a los cada uno de los procesos donde se 
tienen que revisar los documentos que se elaboraron en cada fase del ciclo de vida 
del TSP. Ejemplo: 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
27 
 
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.) 
Testing TS PLAN Plan de Pruebas 
Reporte de Pruebas 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
28 
 
Cierre PM REPORT Historia del Proyecto 
Artefactos de Cierre TSP 
Ejemplo de los Ítem de configuración. (Toro, Escallón, Villegas y Mariño, 2009). 
 
3. Seguimiento de actividades de los miembros del Equipo: Actividad que se 
realiza durante las reuniones de la fase del postmortem y que para poder llevar el 
control de las actividades da cada uno de los integrantes del equipo se debe de llevar 
acabo 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 los 
objetivos y 
alcance del 
mismo. 
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 
29 
 
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 
30 
 
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:00 13: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 
31 
 
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 
32 
 
27/04/
09 
20:00 23:00 0:30 2:30 Postmortem Evaluaci
ón 
Evaluación 
de los 
diferentes 
roles de 
TSP en el 
proyecto 
28/04/
09 
20:00 23:00 0:30 2:30 Postmortem Evaluaci
ón 
Evaluación 
del 
desempeño 
del equipo 
el proyecto 
Ejemplo de control de actividades por cada uno de los miembros del equipo. (Toro, 
Escallón, Villegas y Mariño 2009). 
 
 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
33 
 
3. Seguimiento del proyecto: finalmente se le 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
° 
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
ren
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
o
. 
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 los 
objetivos y alcance del 
mismo. 
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 1 1 1 1 1 1 5 20 Hojas 10 1 1, 6, 3 20 1,2,3 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
34 
 
 
 
 
 
Seguimiento del proyecto. (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 realizar dichas actividades, por ejemplo vemos en la fase de lanzamiento en la creación del equipó con 
cuatro involucrados tres horas planeadas para que el líder de proyecto forme el equipo de trabajo 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. 
 
 
 
 
 
glosario de términos 
del proyecto. 
67 67 
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 35 
5. Finalmente se genera un horario para reporte de cronograma donde se compara lo 
planeado con los resultados obtenidos: Ejemplo de reporte de cronograma. 
 
Al concluir con las actividades se hace un análisis de los datos obtenidos configurando un 
reporte de calidad, se puede hacer uso de los siguientes elementos. 
Logros alcanzados: Se hace una revisión de los logros que se pudieron alcanzar que 
fueron planeados previamente con una breve descripción de la actividad que se cumplió. 
Problemas encontrados: Se identifica 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 poder prevenir que se presenten nuevamente en los 
futuros proyectos así como también se puede aprender de las actividades que se 
completaron sin contratiempos. 
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 
Acumula
das 
Semana 
Valor 
Agregad
o 
Acumulaci
ón de Valor 
Ganado 
No. 
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. (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 36 
Oportunidades de mejora: Con base en los problemas que se presentaron en relación 
con 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. 
Toda esta información debe ser registrada de manera conjunta entre líder de proyecto y 
los integrantes que conforman el equipo para poder evaluar los resultados obtenidos, 
incluyendo al Administrador del proyecto. 
En conclusión el objetivo principal del postmortem 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 el equipo y cada uno de los integrantes que lo conforman deben estar comprometidos 
en la recopilación de la información general, desde el inicio hasta la culminación del 
proyecto. El postmortem se debe realizar al final de cada ciclo del proyecto y hasta el final 
de todo el proyecto como lo marca las fases del ciclo del vida del TSP. 
 
 
Autoevaluación 
Antes de desarrollar la evidencia de aprendizaje, realiza la autoevaluación con el fin de 
hacer un recuento general de la unidad; así como detectar aquellos temas que no has 
comprendido en su totalidad y que necesites revisar nuevamente, o bien consultar con 
tus compañeros(as) y Facilitador(a). 
Para realizar la Autoevaluación, ingresa al listado de actividades en el aula. 
 
 
Evidencia de aprendizaje. Generación del reporte de calidad del 
proyecto 
 
Como evidencia de aprendizaje generarás un informe de logros del equipo de trabajo para 
poder evaluar el cumplimiento de los objetivos en cuanto a las métricas propuestas para 
garantizar la calidad del proyecto mediante el planteamiento de un problema 
correspondiente a un proyecto de software que te hará llegar tu Facilitador (a), una vez 
que cuentes con él: 
 
1. Identifica los problemas encontrados con relación a las métricas planeadas. 
 
2. Elabora el plan del informe de seguimiento del proyecto asegurándote de 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 37 
integrar el objetivo personal de cada uno de los roles así como las métricas 
propuestas y el resultado obtenido apoyándote del ejemplo desarrollado en 
tema 3.2.1. 
 
3. Redacta tus conclusiones acerca del origen del problema: desempeño, calidad 
del producto, etcétera; así como la forma en que se pueden mejorar los 
problemas presentados. 
 
4. Guarda la actividad con el nombre DDSE_U3_EA_XXYZ. Sustituye las XX por 
las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z 
por tu segundo apellido. 
 
5. Envía tu actividad al portafolio de evidencias. 
 
*Consulta la Rúbrica de evaluación de la unidad 3 para conocer los parámetros de 
evaluación de esta actividad. 
 
 
Autorreflexiones 
 
Además de enviar tu trabajo de la Evidencia de aprendizaje, ingresa al foro Preguntas 
de Autorreflexión y consulta las preguntas que tu Facilitador(a) presente, a partir de 
ellas elabora tu Autorreflexión en un archivo de texto llamado DDSE_U3_ATR_XXYZ. 
 
Posteriormente envía tu archivo mediante la herramienta Autorreflexiones. 
 
 
 
Cierre de la unidad 
 
En esta Unidad aprendiste porqué es muy importante realizar el monitoreo y control del 
proyecto, para saber si el proyecto marcha según lo planeado al inicio del mismo. 
Dentro de este punto, aprendiste a elaborar las plantillas de revisión de la administración 
de proyecto y la plantilla de reporte administrativo del estatus del proyecto. 
 
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 38 
También aprendiste a implementar la fase postmortem de TSP la cual te proporcionará 
una retroalimentación de los aciertos y errores que se tuvieron durante el desarrollo del 
proyecto. Y por supuesto comparar las métricas de calidad contrael trabajo realizado por 
parte del equipo y a elaborar el análisis de desempeño del mismo. 
 
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 del 
mismo, se necesita una metodología de calidad y TSP es una de ellas, la cual te aporta 
una guía de lo que debes hacer para que tu proyecto de desarrollo de software se lleve a 
cabo y se concluya logrando la calidad deseada al final del ciclo de vida del proyecto. 
 
Esperamos que la información aquí proporcionada, te sirva para lograr el éxito deseado 
en los proyectos que realices en tu vida profesional y sepas que hacer cuando un 
proyecto de desarrollo de software no va marchando conforme a lo planeado, y con esto 
seas capaz de dar soluciones a los problemas que se puedan presentar dentro de la 
empresa o proyectos en los que estés laborando o en los que te integres en un futuro. 
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 acerca de esta metodología. 
Software Engineering Institute Carnegie Mellon (2013). Pittsburgh: 
https://www.sei.cmu.edu/library/abstracts/books/201731134.cfm 
Fuentes de consulta 
 
 Archila, Ángela; Molano, Edison; Kook, Enrique; Gutiérrez, Gustavo y Larrota, 
Jesús. (2010). Informe Postmortem. Proceso de originación de crédito, Banco de 
los Alpes. Panamá: Grupo NEO TEC S.A. [En línea] 
http://webcache.googleusercontent.com/search?q=cache:Vh09Kn4VN_MJ:kymera.
googlecode.com/svn/trunk/Documentation/Mejoramiento%2520de%2520Procesos/
Informe%2520Postmortem.docx+&cd=3&hl=es-419&ct=clnk&gl=mx 
 
 Esterkin, J. (2008). Qué es y cómo se hace un reporte de estado del proyecto. 
México: IAAP. 
 
https://www.sei.cmu.edu/library/abstracts/books/201731134.cfm
Desarrollo de Software en Equipo TSP 
Unidad 3. Gestión en TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 39 
 Gómez de Silva Garza, A. (2008). Introducción a la Computación. México, D.F: 
Cenage Learning Editores. 
 
 Toro, Guillermo; Escallón, Hans; Villegas, Adrián y Mariño, Kerlyn. (2009). 
Modelos y estándares de procesos de desarrollo de software. Bogotá: Universidad 
de los Andes. [En línea] 
http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0C
CoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-
history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_
Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-
NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.507
68961,d.b2I 
 
 Humphrey, W. S. (1999). Introduction to the Team SoftwareProcess. 
Massachusetts: Addison Wesley Professional. 
 
 Humphrey, W. S. (2006). TSP(SM)—Coaching Development Teams. Addison-
Wesley Professional. 
http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.50768961,d.b2I
http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.50768961,d.b2I
http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.50768961,d.b2I
http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.50768961,d.b2I
http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.50768961,d.b2I
http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.50768961,d.b2I