Unidad 3 Gestion en TSP PDF

Desarrollo de software en equipo (TSP)
Unidad 3. Gestión en TSP
Ingeniería en Desarrollo de software

6º Semestre
Programa de la asignatura:
Clave:
15143636
Universidad Abierta y a Distancia de México
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 0

Í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
3.1.2. Elaborar el reporte administrativo del estatus del proyecto .......................................5
3.2. Análisis post mortem .................................................................................................11
3.2.1. Diagnóstico: métricas de calidad versus trabajo realizado ......................................12
3.2.2. Elaborar el análisis del desempeño del equipo .......................................................15
Cierre de la unidad ...........................................................................................................28
Para saber más ................................................................................................................29
Fuentes de consulta .........................................................................................................29

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.
Propósitos
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 TSP para tomar decisiones

gerenciales del proyecto a partir de los reportes.

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.
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 Nombre del Nombre del Porcentaje Observaciones

módulo encargado de la rol completado
revisión
Ventas
Fabricación de
productos
Plantilla de revisión de la administración del proyecto. Tomado de 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 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
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 Nombre del Nombre del Porcentaje Observaciones

del encargado de rol completado
módulo la revisión
Ventas Juan Pérez Administrador 100% Esto módulo fue
de calidad revisado y aprobado
para su liberación por
parte del equipo de
calidad.
Fabricación Juan Pérez Administrador 40% En este módulo se
de de calidad encontraron aún muchos
productos 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.
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:
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 Responsable/rol Observaciones
compromiso
Descripción del Indica si el Fecha límite Nombre o rol del Comentarios
acuerdo (descripción acuerdo está en la que encargado de relacionados al
del número de abierto debe cumplir el acuerdo.
acuerdo al momento (cuando no se cumplirse el acuerdo.
de realizar la logró el acuerdo.
plantilla). avance
planeado) o
cerrado.
Estatus general del proyecto

Avance %
Avance planeado %
Avance real % Estatus
Desviación % de avance 0-40%
planeado menos 41-80%
avance real 81-100%
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/fase Estatus Presupuesto Costo Avance Observaciones
Nombre del Indicar el Cantidad Costo Porcentaje Observaciones
entregable o estatus del asignada al actual del del avance relacionadas al
fase. entregable entregable o entregable del entregable o
o fase fase del o fase (es entregable fase.

(verde, proyecto (este el costo del o fase.

amarillo o presupuesto proyecto al
rojo). se da en la momento
fase de de realizar
lanzamiento la plantilla).
de TSP).
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 Plan de acción Nombre o rol del Fecha límite para
problema. para gestionar el encargado de solucionar el
problema gestionar el plan problema
(describir la de respuesta. (proponer una
solución que se le fecha para darle
va a dar al solución al
problema). problema).
Riesgos
ID Riesgo Probabilida Impact Priorida Respuest Responsabl

d o d a e
Número de la Descripció Indica Indica Indica la Plan de Nombre o rol
revisión n del probabilidad si el urgencia acción del
correspondien riesgo. de impacto con la para hacer encargado
te (uno, dos, ocurrencia es alto que frente al de ejecutar
tres, etcétera). (alta, media medio o debe riesgo. el plan de
o baja). bajo. tratarse respuesta.
el
cambio,
se debe
analizar
el
impacto
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 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 Responsable/rol Observaciones

Compromiso
Este es el Abierto 22-Abril- Administrador El acuerdo se
primer 2012 de proyectos encuentra abierto ya
acuerdo del que es la primera
proyecto. revisión.
Estatus General del proyecto
Avance %
Avance planeado 40 Estatus
Avance real 35 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
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 Se platicará con Líder de 03-Mayo-2012
nuevos que está él para realizar proyecto
pidiendo el cliente. estos cambios
una vez que se
entregue lo
acordado al
principio del
proyecto.
Riesgos
ID Riesgo Probabilidad Impacto Prioridad Respuesta Responsable

1 Nuevos Alta Alto Alta Hacer Líder de
errores pruebas desarrollo
una vez por parte
que se del líder
realice la de
segunda desarrollo
revisión antes de
del enviarlo al
proyecto. equipo de
pruebas.
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.
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 calidad versus 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.
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 Semana Semana Semana Semana Seman Total

12 13 14 15 16 a 17
Planeado 38 22,5 31 10 9,5 7 118
Esfuerzo 18,5 42,25 15 10 8 6 99,75
Ejecutad 8 39 13,5 11,5 12 3,5 87,5
o
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.
Métrica Resultado
Promedio de evaluación del rol por ayuda y Promedio de evaluación de 4,25.
soporte superior a cuatro.
Bueno
Promedio de evaluación del rol contribución Promedio de evaluación
global superior a cuatro. exactamente igual a 4.
Regular
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 Promedio de evaluación de 4,25.
soporte superior a 4.
Bueno
Promedio de evaluación del rol contribución Promedio de evaluación

global superior a 4. exactamente igual a 4.
Regular
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 Las estrategias para consolidar el
No Aplica
registrados en las formas seguimiento personal fueron negociadas

Resumen planeación y Resumen con el grupo, las formas a las que se hace
de calidad es 100%. referencia fueron descartadas.
Porcentaje de tareas planeadas y El líder de planeación realizó sólo el 57%
completadas 100%. de las actividades planeadas durante el
Malo
ciclo.
Objetivo global líder de calidad: disciplina. Tomado de Archila et ál., 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 el resultado obtenido, tal como se
observa en la siguiente tabla.
Objetivo 4
 Hacer productos de calidad.
Métrica Resultado
Promedio de defectos Se encontró el 72% de los defectos esperados
encontrados antes de la antes de la primera compilación.
Excelente Bueno
primera compilación: >70%.
Densidad de los defectos Menos de 3 defectos por KLOC.

encontrados durante
compilación: <10/KLOC.
Densidad de los defectos Las pruebas locales funcionaron correctamente.

encontrados en pruebas: Sin embargo, al tratar de exponer como un
Regular
<5/KLOC. servicio el componente no funcionó

adecuadamente.
Densidad de los defectos La medida no ha podido ser verificada, puesto
No aplica
encontrados después de que aún la herramienta no ha superado la etapa

pruebas: 0. 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 Se realizaron las inspecciones adecuadamente.
Excelente
seguimiento a los Los reportes de seguimiento no aplican.

procesos.
Producto alineado a El producto se encuentra alineado a los

estándares definidos con estándares definidos, sin embargo, aunque se
un porcentaje de 75% libre puede decir que para lo que corresponde a
Excelente
de defectos. 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 Las listas de chequeo han sido preparadas con
artefactos para revisiones anterioridad, sin embargo, éstas no han sido
Excelente Regular
e inspecciones. adecuadamente utilizadas para las revisiones e

inspecciones a lo largo del ciclo.
Número de De acuerdo al proceso de calidad establecido
recomendaciones conjuntamente entre los miembros del grupo, se
establecidas en las realizaron las modificaciones directamente sobre

revisiones. los artefactos, con un promedio de 12

modificaciones por artefacto revisado.
Artefactos alineados a los Los artefactos se encuentran alineados a

estándares definidos. estándares en un 80%. La falta de seguimiento de
Bueno
las plantillas evitó que se cumplieran algunos de
los estándares predefinidos.
10 o menos defectos por Se encontraron en promedio 7,2 defectos por
KLOC hallados durante la KLOC durante la compilación.
compilación. Bueno
5 o menos defectos por Las pruebas locales funcionaron correctamente.

KLOC hallados en la fase Sin embargo, al tratar de exponer como un
Regular
de pruebas. servicio, el componente no funcionó

adecuadamente.
0 defectos hallados La medida no ha podido ser verificada, puesto que
No aplica
después de la fase de aún la herramienta no ha superado la etapa de

pruebas. 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 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 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 Horas Valor Hora Horas Valor Acumula
núm. direct acumul planeado s del acumula gana ción del
as adas ganado equi das do valor
po por ganado
sema
na
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.
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
Fase Parte Nombre de la tarea
Realizar la carta de constitución del proyecto con los
Lanzamiento Alcance
objetivos y alcance del mismo.
Lanzamiento Equipo Conformación del equipo de trabajo.
Asignación de roles a cada miembro del equipo de
Lanzamiento Roles
trabajo.
Lanzamiento Glosario Elaboración del glosario de términos del proyecto.
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.
Nombre Adrián Villegas Equipo ESG Líder de Dalia Trujillo

Proyecto
Fecha 29/04/2009 Ciclo núm. 01 Semana 05

núm.
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 25 30
Proceso
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 1 2 3 4 5
Equipo
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.).

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 1 2 3 4 5
Proceso
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
Procesos
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
Procesos
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.
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 Dalia

proyecto Trujillo
Parte Nuevos requerimientos del proyecto en la Ciclo 1

etapa de programación o desarrollo.
Fecha Evento Numero Priorida Respo Fecha Resuelto

de control d nsable de
de Seguimi
cambios ento
(revisión)
09/04/ Control 1 Alta Guiller 15/04/09 Sí

09 de mo
Cambio Toro
s de
requeri
mientos
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.
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
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 Dalia Trujillo

r
Parte/nivel Ciclo 1
Fecha Inicio Fin Tiempo de Tiempo Fase/tarea Compone Comentarios

interrupción delta nte
14:00 18:00 00:30 3:30 Lanzamiento Enuncia Elaboración
do del
enunciado
03/21/ del
09 problema.
18:00 22:00 00:30 3:30 Lanzamiento Alcance Realizar la
carta de
constitución
del proyecto
con sus
03/21/ objetivos y
09 alcance.
12:00 14:00 0:00 2:00 Lanzamiento Roles y Conformaci
Equipo ón del
03/22/ equipo de
09 trabajo.

14:00 18:00 1:00 3:00 Lanzamiento Roles y Asignación

Equipo de roles a
cada
miembro del
03/22/ equipo de
09 trabajo.
19:00: 21:00: 00:00 2:00 Requerimient Requeri Validación y
00 00 os mientos listados
finales de
requerimient
os y casos
03/22/ de uso con
09 el grupo.
00:00 2:00 Requerimient Requeri Especificaci

os mientos ón del caso
de uso de
03/30/ 21:00: 23:00: realizar
09 00 00 alquiler
00:00 1:00 Requerimient Requeri Prototipo
os mientos del caso de
3/30/0 00:00: 01:00: uso realizar
9 00 00 alquiler.
02/04/ 19:00 21:00 00:00 2:00 Planeación Planeaci Revisión de

09 de trabajo ón las
correccione
s a realizar
sobre el
proyecto.
Definición
del plan de
trabajo.
04/04/ 08:00 22:00 01:00 13:00 Lanzamiento Artefacto Correccione

09 –estrategia– s s sobre
requerimient todos los
os artefactos
de dichas
fases y
elaboración
de nuevos
artefactos.

05/04/ 09:00 23:00 01:00 13:00 Planeación- Artefacto Correccione

09 requerimient s s sobre
os todos los
artefactos
de dichas
fases y
elaboración
de nuevos
artefactos.
18/04/ 09:00 23:00 01:00 13:00 Diseño Revisión Revisión de

09 tareas
pendientes
según
cronograma
de tareas de
diseño.
17/04/ 21:00 23:00 00:30 1:30 Construcción Revisión Revisión de

09 de caso los flujos del
de uso caso de uso
para
inspecciona
r y visionar
la manera
de
implementar
lo.
17/04/ 09:00 15:00 01:00 5:00 Construcción Revisión Reunión
09 de caso con el grupo
de uso para validar
el prototipo
arquitectural
y realizar
primeras
pruebas de
funcionalida
des.
20/04/ 21:00 23:00 00:00 2:00 Construcción Desarroll Desarrollo
09 o de de
caso de funcionalida
uso d de
generar
reporte de
recaudo
diario.


09 o de de
uso d de
generar
reporte de
recaudo
diario con
sus
respectivas
pruebas
unitarias.

09 o de de
uso d de
generar
reporte de
recaudo
diario con
sus
respectivas
pruebas
unitarias.
27/04/ 20:00 23:00 0:30 2:30 Post mortem Evaluaci Evaluación
09 ón de los
diferentes
roles de
TSP en el
proyecto.
28/04/ 20:00 23:00 0:30 2:30 Post mortem Evaluaci Evaluación
09 ó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.

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 Actual
tamaño/valor
Toral de horas de equipo

Gerente de planeación
Gerente de desarrollo
Tamaño de unidades
Gerente de Calidad/
Núm. de ingenieros
Gerente de soporte
Nombre de la tarea
Horas acumuladas
Horas acumuladas
Líder de equipo
Valor planeado
Núm. semana
Acumulados
producto
Tamaño
Semana
Horas
Parte
Fase
Realizar la carta de
Lanzamiento Alcance constitución del proyecto con 4 3 3 6 6 Hojas 3 1 2 2 8 8 1,2,3
sus objetivos y alcances.
Conformación del equipo de 1, 3,
Lanzamiento Equipo 4 1 1 1 1 1 5 11 Hojas 4 1 5 13 1,2,3
trabajo. 67 67
Asignación de roles a cada
1,
Lanzamiento Roles miembro del equipo de 2 2 2 4 15 Hojas 2 1 5 4 17 1,2,3
33
trabajo.
Elaboración del glosario de 1, 6,
Lanzamiento Glosario 1 1 1 1 1 1 5 20 Hojas 10 1 3 20 1,2,3
términos del proyecto. 67 67
Estrategi Definir el ciclo de vida de 2,
Lanzamiento 2 4 3 7 27 Hojas 3 1 9 4 24 1,2,3
a desarrollo. 33
Estrategi Elaborar el diseño
Lanzamiento 1 3 3 30 Hojas 2 1 1 10 2 26 1,2,3
a conceptual.
Seguimiento del proyecto. Tomado de Toro, Escallón, Villegas y Mariño 2009.

En la tabla anterior se observan las tareas (como un ejemplo) 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.
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:
Nombre: Fecha:
Equipo: Instructor:
Nivel: Ciclo:
Plan Actual
Semana Fecha Horas Horas Acumulaci Horas Horas Semana Acumulaci
directa acumulada ón de valor del acumulad valor ón de valor
s s planeado equipo as agregad ganado
Núm.
o
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.
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.
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 lleve a 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.

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).
http://www.sei.cmu.edu/process/
Blog del Software Engineering Institute Carnegie Mellon (2013). Recuperado de
http://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. Recuperado de
http://webcache.googleusercontent.com/search?q=cache:Vh09Kn4VN_MJ:kymera.
googlecode.com/svn/trunk/Documentation/Mejoramiento%2520de%2520Procesos/
Informe%2520Post mortem.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.
 Gómez, A. (2008). Introducción a la Computación. México: Cenage Learning.
 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.
Recuperado de
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. (1999). Introduction to the Team SoftwareProcess. Massachusetts:

Addison Wesley Professional.
 Humphrey, W. S. (2006). TSP(SM)—Coaching Development Teams. Addison

Wesley Professional.

Unidad 3 Gestion en TSP PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Unidad 3 Gestion en TSP PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Desarrollo de software en equipo (TSP)

Unidad 3. Gestión en TSP

Ingeniería en Desarrollo de software

Unidad 3. Gestión en TSP

Universidad Abierta y a Distancia de México

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 0

Unidad 3. Gestión en TSP ..................................................................................................2

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 1

Unidad 3. Gestión en TSP

Bienvenido(a) a la Unidad 3. Gestión en TSP, aquí se abordarán conceptos

En la unidad 1 aprendiste conceptos básicos sobre la metodología TSP, ciclo de vida

En esta unidad aprenderás a realizar las plantillas correspondientes a la fase post

También aprenderás a implementar la fase post mortem, la cual tiene dos

Al término de esta unidad lograrás:

 Determinar la función de gestión a partir de la metodología Team Software

 Aplicar la mecánica de gestión de la metodología TSP para tomar decisiones

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 2

3.1. Monitoreo y control del proyecto

El monitoreo y control del proyecto es un conjunto de actividades de gestión que

Para la supervisión y seguimiento del proyecto, es necesario realizar acciones de

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,

La revisión de la administración es importante antes de arrancar la fase post mortem.

Se desarrolla un software para llevar el control de una empresa que se dedica a la

Siguiendo el ejemplo anterior, el equipo de desarrollo y diseño primero entregará el

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 3

Para hacer el seguimiento de la administración del proyecto de acuerdo a las

Nombre del Nombre del Nombre del Porcentaje Observaciones

Plantilla de revisión de la administración del proyecto. Tomado de Humphrey, 2006.

Recuerda que esta plantilla puede ir en un documento de Word con un control de

A continuación se explicará qué es lo que se tiene que integrar en cada columna de

Nombre del módulo: como el título lo indica, en esta columna se integrará el

Nombre del encargado de la revisión: aquí se integrará el nombre de la persona

Porcentaje completado: se integra en una columna identificada con colores según

Observaciones: en esta columna el encargado de hacer la plantilla, que será el

Con base en el ejemplo anterior, se expone el siguiente ejemplo:

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 4

Nombre Nombre del Nombre del Porcentaje Observaciones

Es importante mencionar que el porcentaje completado se define en las juntas que

En conclusión, se puede decir que esta plantilla es importante porque proporciona

3.1.2. Elaborar el reporte administrativo del estatus del proyecto

 Estatus general del proyecto: muestra el estado del proyecto al momento de

Como se mencionó, en este reporte quedará plasmada la situación actual del

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 5

La plantilla para elaborar este reporte es la siguiente:

Proyecto Nombre del proyecto

Estatus general del proyecto

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 6

(verde, proyecto (este el costo del o fase.

Actividades relevantes del periodo

# Problemas Respuesta Responsable/rol Fecha

ID Riesgo Probabilida Impact Priorida Respuest Responsabl

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 7

Esta plantilla la realizará el administrador de proyectos, por lo tanto, él realizará las

Otro punto a remarcar es que todos los estatus se considerarán de acuerdo al

A continuación se expone un ejemplo mediante el cual se ilustra la forma de llenar la

Se realiza un proyecto de software dirigido al apoyo de servicios escolares y

 A los profesores, capturar las calificaciones de los 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

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 8

fase de integración y pruebas del sistema, de acuerdo al ciclo de vida de desarrollo

Con los datos proporcionados anteriormente se procede al llenado de la plantilla de