Unidad 3 Gestion en TSP

Desarrollo de software en equipo (TSP)
Unidad 3. Gestin en TSP
Ingeniera en Desarrollo de software

6 Semestre
Programa de la asignatura:
Clave:
15143636
Universidad Abierta y a Distancia de Mxico
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

ndice
Unidad 3. Gestin en TSP ..................................................................................................2
Presentacin de la unidad ..................................................................................................2
Propsitos ..........................................................................................................................2
Competencia especfica .....................................................................................................2
3.1. Monitoreo y control del proyecto ..................................................................................3
3.1.1. Ejecutar la revisin de la administracin del proyecto ...............................................3
3.1.2. Elaborar el reporte administrativo del estatus del proyecto .......................................5
3.2. Anlisis post mortem .................................................................................................11
3.2.1. Diagnstico: mtricas de calidad versus trabajo realizado ......................................12
3.2.2. Elaborar el anlisis del desempeo del equipo .......................................................15
Cierre de la unidad ...........................................................................................................28
Para saber ms ................................................................................................................29
Fuentes de consulta .........................................................................................................29


Presentacin de la unidad
Bienvenido(a) a la Unidad 3. Gestin en TSP, aqu se abordarn conceptos
relacionados con la administracin de un proyecto de desarrollo de software
utilizando la metodologa TSP.
En la unidad 1 aprendiste conceptos bsicos sobre la metodologa TSP, ciclo de vida
de un proyecto de desarrollo de software y las fases de esta metodologa. En la
unidad 2 aprendiste a llevar a cabo la fase de lanzamiento del proyecto, segn la
metodologa TSP, y a ejecutar la fase de implementacin mediante el plan de
riesgos, plan de calidad y plan de proyecto.
En esta unidad aprenders 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.
Tambin aprenders a implementar la fase post mortem, la cual tiene dos
componentes que son: diagnstico de mtricas de calidad versus trabajo realizado, y
la elaboracin del anlisis del desempeo 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 retroalimentacin de los errores y de las cosas que
se hicieron bien en el proyecto, y as poder considerarlo para futuros proyectos.
Propsitos
Al trmino de esta unidad logrars:
Determinar la funcin de gestin a partir de la metodologa 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 estn a cargo del
desarrollo del proyecto, mediante reportes.
Competencia especfica
Aplicar la mecnica de gestin de la metodologa 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 gestin que
permiten verificar si el proyecto marcha segn 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 supervisin y seguimiento del proyecto, es necesario realizar acciones de
monitoreo y control utilizando la metodologa TSP; esto reviste esencial importancia
porque permite medir, de una manera correcta, la situacin 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 captulos aprenders a realizar las plantillas que TSP proporciona
como una mecnica para la gestin del proyecto, con el fin de que comprendas cmo
influyen estos reportes en la toma de las decisiones gerenciales al implementar esta
metodologa.
3.1.1. Ejecutar la revisin de la administracin del proyecto

En la Unidad 2. Implementacin de TSP aprendiste cmo realizar el plan de calidad,
de riesgos y de proyecto. Cuando se ejecuta el plan de calidad se hacen las
revisiones de cdigo correspondientes al diseo y al desarrollo del proyecto. En este
captulo aprenders a realizar la revisin de todo lo ya realizado, incluyendo
desarrollo y pruebas del sistema.
La revisin de la administracin es importante antes de arrancar la fase post mortem.
Recuerda que un proyecto, de acuerdo a su tamao, se puede dividir en mdulos.
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 fabricacin 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
adems se desarrollar la parte del software donde se realizarn las ventas de los
productos. Aqu el software se dividir en dos mdulos, uno se encargar de lo
relativo a la fabricacin y el otro a la venta de los productos. Al momento de realizar
las pruebas del sistema se encontr que el mdulo de ventas ya fue revisado y no se
encontraron errores, por lo tanto fue liberado correctamente. El segundo mdulo lo
revis el equipo de calidad, y encontr que ms de la mitad tiene errores.
Siguiendo el ejemplo anterior, el equipo de desarrollo y diseo primero entregar el
mdulo correspondiente a la fabricacin de los productos, y despus el que se refiere
a la venta. El equipo de calidad y los administradores del proyecto evaluarn,
revisarn y aprobarn cada mdulo; conforme se termine de revisar, si el sistema

tiene an errores se regresar al equipo de desarrollo, para que realice las

modificaciones correspondientes.
Para hacer el seguimiento de la administracin del proyecto de acuerdo a las
pruebas realizadas, TSP proporciona la plantilla que se observa a continuacin.
Nombre del
mdulo
Nombre del
encargado de la
revisin
Nombre del
rol
Porcentaje
completado
Observaciones
Ventas
Fabricacin de
productos
Plantilla de revisin de la administracin 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
propsitos, objetivos y roles del equipo.
A continuacin se explicar qu es lo que se tiene que integrar en cada columna de
la plantilla:
Nombre del mdulo: como el ttulo lo indica, en esta columna se integrar el
nombre del mdulo. En el ejemplo anterior se mencionan dos mdulos: ventas y
fabricacin de productos. Estos nombres se definen al inicio del proyecto. Si el
proyecto se integrara de ms de dos mdulos, se debern insertar las filas que sean
necesarias.
Nombre del encargado de la revisin: aqu se integrar el nombre de la persona
que llev a cabo las pruebas del mdulo correspondiente.
Nombre del rol: en esta columna se escribir el rol del encargado de las pruebas del
mdulo, segn la metodologa TSP y el equipo en el que se encuentre.
Porcentaje completado: se integra en una columna identificada con colores segn
el porcentaje concluido del mdulo correspondiente, tal como se muestra a
continuacin.
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 revisin del mdulo.
Con base en el ejemplo anterior, se expone el siguiente ejemplo:

Nombre
del
mdulo
Ventas
Nombre del
encargado de
la revisin
Juan Prez
Fabricacin Juan Prez

de
productos
Nombre del
rol
Porcentaje
completado
Observaciones
Administrador
de calidad
100%
Administrador
de calidad
40%
Esto mdulo fue

revisado y aprobado
para su liberacin por
parte del equipo de
calidad.
En este mdulo se
encontraron an muchos
errores, por lo que se
regres al equipo de
desarrollo para que
realice las
modificaciones
correspondientes.
Plantilla de revisin de la administracin 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 conclusin, 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 revisin de la administracin del
proyecto y el reporte administrativo del estatus del proyecto, este ltimo se abordar
en el siguiente captulo.
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 propsito es comunicar si se va desarrollando segn lo
planeado y por qu, o si no se va desarrollando segn lo planeado, tambin 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 mdulos, 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 situacin actual del

proyecto. El propsito 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. Implementacin de TSP), su funcin
principal es dar cuenta de los desvos del plan realizado al inicio del proyecto, y as
buscar y plantear una solucin adecuada. En este reporte TSP indica qu debe
contener un resumen que mencione si el proyecto se est desarrollando segn 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. Tambin debe contener una breve descripcin de aquellas cosas
del proyecto que no se desarrollan segn 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
Id
Nombre del proyecto

Cdigo del identificador (depende totalmente de la empresa que
est desarrollando el software, se refiere al cdigo que se asign
al proyecto).
Nombre del lder
dd/mm/aa dd/mm/aa (periodo del inicio del proyecto hasta la
fecha en que se realiza la plantilla).
Acuerdos anteriores
Estado
Fecha
Responsable/rol Observaciones
compromiso
Lder de proyecto
Periodo
Acuerdo
Descripcin del
acuerdo (descripcin
del nmero de
acuerdo al momento
de realizar la
plantilla).
Avance
Avance planeado
Avance real
Desviacin
Indica si el
acuerdo est
abierto
(cuando no se
logr el
avance
planeado) o
cerrado.
Fecha lmite
en la que
debe
cumplirse el
acuerdo.
Nombre o rol del

encargado de
cumplir el
acuerdo.
Comentarios
relacionados al
acuerdo.
Estatus general del proyecto

%
%
Estatus
%
0-40%
% de avance
41-80%
planeado menos
81-100%
avance real
Situacin general del proyecto
Descripcin de las razones que originan el estatus del proyecto (motivos por los cuales hay un
desvo entre lo planeado y el avance real, o si el proyecto avanza conforme a lo planeado)
Entregable/fase
Nombre del
entregable o
fase.
Estatus del proyecto a nivel entregable/fase

Estatus
Presupuesto
Costo
Avance
Indicar el
estatus del
entregable
o fase
Cantidad
asignada al
entregable o
fase del
Costo
actual del
entregable
o fase (es
Porcentaje
del avance
del
entregable
Observaciones
Observaciones
relacionadas al
entregable o
fase.

(verde,
amarillo o
rojo).
proyecto (este
presupuesto
se da en la
fase de
lanzamiento
de TSP).
el costo del
proyecto al
momento
de realizar
la plantilla).
o fase.
Actividades relevantes del periodo
Actividad
Breve descripcin de la actividad realizada en el periodo.
Problemas
Problemas
Descripcin del
problema.
Respuesta
Responsable/rol
Plan de accin
para gestionar el
problema
(describir la
solucin que se le
va a dar al
problema).
Nombre o rol del

encargado de
gestionar el plan
de respuesta.
Fecha
Compromiso
Fecha lmite para
solucionar el
problema
(proponer una
fecha para darle
solucin al
problema).
Riesgos
ID
Riesgo
Probabilida
d
Impact
o
Priorida
d
Respuest
a
Responsabl
e
Nmero de la
revisin
correspondien
te (uno, dos,
tres, etctera).
Descripci
n del
riesgo.
Indica
probabilidad
de
ocurrencia
(alta, media
o baja).
Indica
si el
impacto
es alto
medio o
bajo.
Indica la
urgencia
con la
que
debe
tratarse
el
cambio,
se debe
analizar
el
impacto
que
tendr
en el
proyecto
Plan de
accin
para hacer
frente al
riesgo.
Nombre o rol
del
encargado
de ejecutar
el plan de
respuesta.

(alto
medio,
bajo).
Se integran
tantas filas
como se
requiera, de
acuerdo con el
nmero 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. Ms adelante, mediante un ejemplo se ahondar
en este punto.
Otro punto a remarcar es que todos los estatus se considerarn de acuerdo al
avance del proyecto y se les asignar un color, tal como se muestra a continuacin:
0 a 40%
41 a 80%
81 a 100%
Porcentaje completado
A continuacin 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
administracin escolar de una institucin educativa. El proyecto tiene por nombre
Sistema de administracin 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 acadmico, as como realizar: altas, bajas, registro de exmenes
extraordinarios, etctera
Al rea de administracin escolar, contar con un registro de los alumnos
inscritos en la escuela y tambin de egresados
A los padres de los alumnos, contar con un mdulo va Web para conocer sus
calificaciones, as como las observaciones de los profesores sobre el estatus
acadmico de cada uno de sus alumnos
Para el desarrollo del software se asign un presupuesto de $ 800,000.

El sistema ya pas la primera revisin de pruebas, en las juntas que se tuvieron en la
fase de lanzamiento del proyecto se acord que para esta revisin el avance tena
que ser de 40% del total del proyecto; al realizar esta tarea se encontraron errores de
codificacin y diseo, por lo cual slo 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 ms requerimientos de los que se plantearon al
inicio del proyecto, y es difcil implementarlos porque ya se concluy la fase de
pruebas del desarrollo del proyecto. Cabe sealar que el proyecto se encuentra en la

fase de integracin 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 continuacin.
Proyecto
Id
Lder de proyecto
Periodo
Sistema de administracin escolar EscolaRis

AE1
Rubn Hernndez
05/01/2012- 25/04/2012
Acuerdos anteriores
Acuerdo
Estado
Este es el
primer
acuerdo del
proyecto.
Abierto
Fecha
Compromiso
22-Abril2012
Responsable/rol Observaciones
Administrador
de proyectos
El acuerdo se
encuentra abierto ya
que es la primera
revisin.
Estatus General del proyecto
Avance
Avance planeado
Avance real
Desviacin
%
40
35
5
Estatus
35%
Situacin general del proyecto

El proyecto est bien, pero tiene una desviacin 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
Entregable 1
Estatus
35%
Presupuesto
Costo
$800,000
$200,000
Avance
35%
Observaciones
El proyecto se
encuentra bien en
relacin
presupuesto/costo
aunque tenga una
desviacin del 5%.

Actividades relevantes del periodo
#
1
2
Actividad
Se realizaron los mdulos correspondientes a los catlogos de
maestros y alumnos.
Se realiz la parte de la calificacin de alumnos por parte de los
profesores, y se tuvo un adelanto en el mdulo de inscripciones, aun
no revisado por el equipo de calidad.
Problemas
#
1
Problemas
Respuesta
Requerimientos
nuevos que est
pidiendo el cliente.
Se platicar con
l para realizar
estos cambios
una vez que se
entregue lo
acordado al
principio del
proyecto.
Responsable/rol
Lder de
proyecto
Fecha
Compromiso
03-Mayo-2012
Riesgos
ID
1
Riesgo
Nuevos
errores
una vez
que se
realice la
segunda
revisin
del
proyecto.
Probabilidad Impacto
Alta
Alto
Prioridad
Alta
Respuesta Responsable
Hacer
Lder de
pruebas
desarrollo
por parte
del lder
de
desarrollo
antes de
enviarlo al
equipo de
pruebas.
Plantilla de reporte administrativo del estatus del proyecto
10

Un punto a considerarse es que si surgen riesgos y problemas que impacten

directamente en el presupuesto, tales como el cambio de algn 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 elaboracin de las
plantillas en la fase post mortem.
3.2. Anlisis post mortem

Aqu se explicarn 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 informacin sobre la eficacia del lder 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 tambin aprenders a realizar un diagnstico
sobre las mtricas de calidad aplicadas al trabajo realizado durante el desarrollo del
software.
El post mortem sirve de retroalimentacin 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
lderes de proyecto sean ms 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 informacin, la cual
contiene, entre otros, los siguientes elementos:
Calidad de los productos

Estimaciones.
La informacin debe estar debidamente recolectada y organizada, de no ser as se

presentarn problemas para poder reconstruir el trabajo realizado. Es por eso que
TSP propone realizar el post mortem en la culminacin de cada proyecto, para
aprovechar que la informacin recabada y la experiencia del trabajo realizado por el
equipo de proyecto estn frescas; de esta manera se tendr una idea ms clara de
cmo trabajar para los futuros proyectos. De igual manera, la elaboracin del
diagnstico de mtricas de calidad contra el trabajo realizado que tambin se
reelabora en el proceso de post mortem tiene el propsito de evaluar los resultados
obtenidos y verificar el nivel de cumplimiento de lo planeado que, en este caso, se
refiere a las mtricas de calidad establecidas por el equipo de proyecto.
11

3.2.1. Diagnstico: mtricas de calidad versus trabajo realizado

Aqu aprenders a realizar el diagnstico de las mtricas 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 diagnstico de las mtricas de calidad con base en el trabajo previo,
se debe hacer uso del plan de calidad, el cual contiene la informacin sobre la
inyeccin de defectos en el diseo y codificacin.
Tambin 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 estn fallando o la
manera en que pueden mejorar, as como expresar las inconformidades e
inquietudes (Humphrey, 2006).
El encargado de las mtricas de calidad es el gerente de calidad. Se debe hacer un
reporte de realizacin de los objetivos con base en lo planeado y el resultado que se
obtuvo. Recuerda que una mtrica es un valor cuantificable que puede ser medible.
A continuacin se muestra un ejemplo de anlisis 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 crdito del
banco de los Alpes. Se observa el registro del cumplimiento de las actividades
planeadas por semana, para que finalmente sea posible evaluar el cumplimiento de
los objetivos planeados (Archila et l., 2010).
Acciones
Semana
12
Planeado 38
Esfuerzo 18,5
Ejecutad 8
o
Semana
13
Semana
14
Semana
15
Semana
16
Seman
a 17
Total
22,5
42,25
39
31
15
13,5
10
10
11,5
9,5
8
12
7
6
3,5
118
99,75
87,5
Cumplimiento de compromisos del Lder de calidad. Tomado de Archila et l., 2010.
Aqu se ofrece la distribucin de las horas planeadas por semana para la realizacin
de las activadas que tiene a su cargo el lder 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 continuacin se describe el objetivo propuesto por el equipo; se revisa en la
siguiente tabla la distribucin de las mtricas planeadas y el resultado obtenido; la
mtrica 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 evaluacin 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 evaluacin.
Objetivo 1
12

Ser un miembro efectivo y cooperativo.
Promedio de evaluacin del rol contribucin

global superior a cuatro.
Bueno
Resultado
Promedio de evaluacin de 4,25.
Regular
Mtrica
Promedio de evaluacin del rol por ayuda y
soporte superior a cuatro.
Promedio de evaluacin
exactamente igual a 4.
Informe de logros del equipo de trabajo: objetivos globales de grupo. Tomado de Archila et l., 2010.
En la siguiente tabla se observa el objetivo planeado por el lder de calidad en cuanto

a efectividad y cooperacin.
Objetivo 2
Hacer el trabajo personal de manera disciplinada y consiste.
Promedio de evaluacin del rol contribucin

global superior a 4.
Bueno
Resultado
Promedio de evaluacin de 4,25.
Regular
Mtrica
Promedio de evaluacin del rol por ayuda y
soporte superior a 4.
Promedio de evaluacin
exactamente igual a 4.
Objetivo global lder de calidad: efectividad y cooperacin. Tomada de Archila et l., 2010.
En la siguiente tabla la mtrica cambia a un valor en porcentaje para establecer el

cumplimiento del objetivo. Est en una escala de %0 a 100%.
Malo
Mtrica
Porcentaje de datos personales
registrados en las formas
Resumen planeacin y Resumen
de calidad es 100%.
Porcentaje de tareas planeadas y
completadas 100%.
No Aplica
Objetivo 3
Planear y hacer seguimiento al trabajo personal.
Resultado
Las estrategias para consolidar el
seguimiento personal fueron negociadas
con el grupo, las formas a las que se hace
referencia fueron descartadas.
El lder de planeacin realiz slo el 57%
de las actividades planeadas durante el
ciclo.
Objetivo global lder de calidad: disciplina. Tomado de Archila et l., 2010.
13

De la misma manera que los dems 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.
Densidad de los defectos

encontrados en pruebas:
<5/KLOC.
encontrados despus de
pruebas: 0.
Regular

encontrados durante
compilacin: <10/KLOC.
No aplica
Mtrica
Promedio de defectos
encontrados antes de la
primera compilacin: >70%.
Excelente Bueno
Objetivo 4
Hacer productos de calidad.
Resultado
Se encontr el 72% de los defectos esperados
antes de la primera compilacin.
Menos de 3 defectos por KLOC.
Las pruebas locales funcionaron correctamente.

Sin embargo, al tratar de exponer como un
servicio el componente no funcion
adecuadamente.
La medida no ha podido ser verificada, puesto
que an la herramienta no ha superado la etapa
de pruebas.
Medicin de la calidad del producto. Tomad de Archila et l., 2010.
Listas de chequeo de
artefactos para revisiones
e inspecciones.
Nmero de
recomendaciones
establecidas en las
Excelente
Producto alineado a
estndares definidos con
un porcentaje de 75% libre
de defectos.
Excelente Regular
Mtrica
Inspecciones y reportes de
seguimiento a los
procesos.
Excelente
Siguiendo con el mismo ejemplo de rol de lder de calidad, los objetivos propuestos
por el equipo de trabajo se observan en la tabla siguiente.
Resultado
Se realizaron las inspecciones adecuadamente.
Los reportes de seguimiento no aplican.
El producto se encuentra alineado a los

estndares definidos, sin embargo, aunque se
puede decir que para lo que corresponde a
programacin el porcentaje libre de defectos
esperado es del 93%, no es posible hacer una
medicin de lo que corresponde a configuracin.
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.
De acuerdo al proceso de calidad establecido
conjuntamente entre los miembros del grupo, se
realizaron las modificaciones directamente sobre
14

los artefactos, con un promedio de 12

modificaciones por artefacto revisado.
Artefactos alineados a los

estndares definidos.
Los artefactos se encuentran alineados a

estndares en un 80%. La falta de seguimiento de
las plantillas evit que se cumplieran algunos de
los estndares predefinidos.
Se encontraron en promedio 7,2 defectos por
KLOC durante la compilacin.
0 defectos hallados
despus de la fase de
pruebas.
Bueno
Regular
5 o menos defectos por

KLOC hallados en la fase
de pruebas.
No aplica
10 o menos defectos por

KLOC hallados durante la
compilacin.
Bueno
revisiones.
Las pruebas locales funcionaron correctamente.

Sin embargo, al tratar de exponer como un
servicio, el componente no funcion
adecuadamente.
La medida no ha podido ser verificada, puesto que
an la herramienta no ha superado la etapa de
pruebas.
Objetivos especficos de rol. Tomado de Archila et l., 2010.
En el ejemplo anterior se muestra las mtricas 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 lder 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
lder de calidad. Al final se debe hacer una conclusin o diagnstico de los resultados
obtenidos, en ellos se determina si se cumpli o no con los objetivos propuestos o de
qu manera pueden mejorar.
La revisin de resultados se debe realizar con cada uno de los integrantes del
equipo, comparar y revisar los datos planeados, para que finalmente se evale la
calidad del producto obtenido. Cuando se concluya con el diagnstico 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 conclusin, si no se realiza un diagnstico de las mtricas de calidad con el
trabajo realizado al final de cada proyecto en la fase de post mortem, no se podrn
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 anlisis del desempeo del equipo

Ahora se abordarn los temas correspondientes a la realizacin del anlisis de
desempeo del equipo, el cual consiste en un estudio y evaluacin del desempeo
conseguido por el equipo, y del resultado obtenido durante el desarrollo del software.
15

Esto se realiza en el paso final del proceso de TSP post mortem. Dentro de sta se
debe analizar el desempeo 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 recoleccin de informacin se debe
de tomar en cuenta de qu forma van a ser utilizados los datos recolectados; por eso
se debe generar un plan de recoleccin de informacin, ya que de no hacerlo se
puede llegar a perder tiempo en el proceso.
El gestor de configuracin es el encargado de preparar con anticipacin la forma en
que se va a recolectar la informacin; pide a los miembros del equipo que recolecten
la informacin de tal manera que pueda ser presentada durante las reuniones para
llevar a cabo el post mortem en la culminacin 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):
Descripcin 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 planeacin el
encargado de llevar acabo las reuniones en donde se revisan los datos del
lanzamiento; debe asegurarse que todos los datos obtenidos estn completos, sean
precisos y estn disponibles para su revisin. Ms 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 cmo poder mejorar los
procesos a partir de la experiencia de proyectos pasados.
Evaluacin de lanzamiento: el lder del proyecto y los integrantes del equipo deben
llevar a cabo la evaluacin del lanzamiento del proyecto al culminar todo el proceso.
Esta evaluacin 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 evaluacin debe llenarse los formularios
correspondientes.
Reunin de la documentacin del lanzamiento: se debe reunir la documentacin
de la propuesta de mejora de procesos y otras propuestas de manera correcta,
adems de darlas a conocer a las personas indicadas para que se lleven a cabo.
A continuacin se explica un ejemplo con los elementos necesarios para elaborar el
documento post mortem basado en el TSP (Toro, Escalln, Villegas y Mario, 2009).
Introduccin: es una breve explicacin del contenido.
Propsito: se redacta lo que se espera de la realizacin de este documento.
16

Anlisis 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 descripcin de lo que se realiz en cada
etapa, despus se hace uso de una tabla como la siguiente, para organizar la
informacin:
Plan
Semana
Fecha
nm.
Horas Horas
direct acumul
as
adas
Actual
Valor
Hora Horas Valor Acumula
planeado s del acumula gana cin del
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
31
300 0,33
100
100
Ejemplo de revisin post mortem por ciclos del proyecto ECOSSOCCER. Tomado de Toro, Escalln,
Villegas y Mario, 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 continuacin se elabora la siguiente tabla para verificar el cumplimiento de las
tareas.
Ejemplo de revisin de tareas del proyecto ECOSSOCCER. Tomado de Toro, Escalln, Villegas y
Fase
Parte
Nombre de la tarea
Realizar la carta de constitucin del proyecto con los

objetivos y alcance del mismo.
Lanzamiento Equipo Conformacin del equipo de trabajo.
Asignacin de roles a cada miembro del equipo de
Lanzamiento Roles
trabajo.
Lanzamiento Glosario Elaboracin del glosario de trminos del proyecto.
Lanzamiento Alcance
Mario, 2009.
Resultados: se describen los resultados obtenidos en la fase.

Conclusin: 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 dnde se fall y qu se puede hacer para mejorar; por ejemplo, si los
problemas que se encontraron fueron ms concurrentes en la codificacin, en la
17

disciplina de trabajo, etctera, y cmo se actu ante estas situaciones. Finalmente,

se hacer una recomendacin para mejorar para los siguientes proyectos.
Evaluacin personal y de equipo: en esta actividad se debe llevar acabo la
evaluacin del rendimiento del equipo y de cada uno de sus miembros. A
continuacin se muestra el formato utilizado para un proyecto de desarrollo de
software que lleva por nombre ECOOSSOCCER, donde se evala el rendimiento o
desempeo de los miembros del equipo durante cada ciclo.
Nombre
Adrin Villegas
Equipo
ESG
Fecha
29/04/2009
Ciclo nm. 01
Lder de
Proyecto
Dalia Trujillo
Semana
nm.
05
Para cada rol, evala 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 Planeacin
25
30
Calidad/Gerente de
Proceso
25
30
Gerente de Soporte
10
10
Total Contribucin
(100%)
100
100
Evala el total del equipo en cada criterio: indique un nmero del 1 (mn.) a 5 (mx.).
Actitud Equipo
Efectividad Global
Experiencia Gratificante
Productividad del
Equipo
Calidad del Proceso
Calidad del Producto
Evala rol por contribucin total: indique un nmero del 1 (mn.) a 5 (mx.).
18

Lder de Equipo
Calidad/Gerente de
Proceso
Gerente de Proceso
Evala cada rol por ayuda y soporte: indique un nmero del 1 (mn.) a 5 (mx.).
Jefe de Equipo
Calidad/Gerente de
Procesos
Gerente de Soporte
Evala rol respecto a su desempeo: indique un nmero del 1 (mn.) a 5 (mx.).

Lder de Proyecto
Calidad/Gerente de
Procesos
Gerente de Soporte
Ejemplo de formulario de evaluacin personal y del equipo. Tomado de Toro, Escalln, Villegas y
Mario, 2009.
En el ejemplo anterior se representa la puntuacin 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 despus hacer los cambios correspondientes y darles solucin.
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.
19

Nombre
Grupo Experto de Software
Fecha
Equipo
ESG (Grupo de Expertos de Software)
Lder
proyecto
Parte
Nuevos requerimientos del proyecto en la Ciclo

etapa de programacin o desarrollo.
12/04/09
de Dalia
Trujillo
1
Fecha
Evento
Numero
de control
de
cambios
(revisin)
Priorida
d
Respo
nsable
Fecha
de
Seguimi
ento
Resuelto
09/04/
09
Control
de
Cambio
s
de
requeri
mientos
Alta
Guiller
mo
Toro
15/04/09
Descripcin
Es necesario redefinir los casos de uso a partir del anlisis y
la validacin 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 da 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, slo se ingresa la cdula del
cliente para validar que exista. En la programacin 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, segn el anlisis realizado a la arquitectura.
Dichos cambios ayudarn a tener un alcance definido en
cada funcionalidad, y una especificacin ms clara al
momento de implementarlas.
LOG (bitcora) de eventos y cambios en el proyecto. Tomado de Toro, Escalln, Villegas y Mario,
2009.
20

En el ejemplo anterior se describe la razn de los cambios en esta fase de los

procesos. Esto es muy comn 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 lnea base: debe contener los siguientes datos.
1. Introduccin: breve introduccin del contenido del reporte.
2. tem de configuracin: 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.
Introduccin
tem de configuracin
Sigla Categora Artefactos
Fases
Lanzamiento
Planeacin
LZ
PL
SCOPE
Carta de constitucin del proyecto
TEAM
Asignacin de roles
MODEL
Modelo conceptual
REQU
Diagrama casos de uso

Listado de requerimientos y casos de
uso
PLAN
Estimacin
Plan del equipo de trabajo
Cronograma
Requerimientos
RQ
SPEC
Especificacin de casos de uso

Trazabilidad de casos de uso y
requerimientos
Diseo de arquitectura
DA
ARCH
Documento de diseo de arquitectura.

Documento con el diseo detallado de
arquitectura
Cdigo fuente
CF
SOURCE
Archivos fuentes
21

Libreras
Testing
TS
COMP
Componentes de software
FILES
Archivos externos (imgenes, videos,

etctera)
PLAN
Plan de pruebas
Reporte de pruebas
Cierre
PM
REPORT
Historia del proyecto

Artefactos de cierre TSP
Ejemplo de los tems de configuracin. Tomado de Toro, Escalln, Villegas y Mario, 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
Adrin Villegas
Fecha
31/03/09
Equipo
ESG (Grupo de Expertos de Software)
Instructo
r
Dalia Trujillo
Ciclo
Parte/nivel
Fecha
Inicio
Fin
Tiempo de
interrupcin
Tiempo
delta
Fase/tarea
Compone
nte
Comentarios
14:00
18:00
00:30
3:30
Lanzamiento
Enuncia
do
18:00
22:00
00:30
3:30
Lanzamiento
Alcance
12:00
14:00
0:00
2:00
Lanzamiento
Roles y
Equipo
Elaboracin
del
enunciado
del
problema.
Realizar la
carta de
constitucin
del proyecto
con sus
objetivos y
alcance.
Conformaci
n del
equipo de
trabajo.
03/21/
09
03/21/
09
03/22/
09
22

14:00
18:00
1:00
3:00
Lanzamiento
Roles y
Equipo
19:00:
00
21:00:
00
00:00
2:00
Requerimient
os
Requeri
mientos
00:00
2:00
Requerimient
os
Requeri
mientos
00:00
1:00
Requerimient
os
Requeri
mientos
03/22/
09
03/22/
09
03/30/
09
3/30/0
9
21:00:
00
00:00:
00
23:00:
00
01:00:
00
Asignacin
de roles a
cada
miembro del
equipo de
trabajo.
Validacin y
listados
finales de
requerimient
os y casos
de uso con
el grupo.
Especificaci
n del caso
de uso de
realizar
alquiler
Prototipo
del caso de
uso realizar
alquiler.
02/04/ 19:00
09
21:00
00:00
2:00
Planeacin
de trabajo
Planeaci
n
Revisin de
las
correccione
s a realizar
sobre el
proyecto.
Definicin
del plan de
trabajo.
04/04/ 08:00
09
22:00
01:00
13:00
Lanzamiento
estrategia
requerimient
os
Artefacto
s
Correccione
s sobre
todos los
artefactos
de dichas
fases y
elaboracin
de nuevos
artefactos.
23

05/04/ 09:00
09
23:00
01:00
13:00
Planeacinrequerimient
os
Artefacto
s
Correccione
s sobre
todos los
artefactos
de dichas
fases y
elaboracin
de nuevos
artefactos.
18/04/ 09:00
09
23:00
01:00
13:00
Diseo
Revisin
Revisin de
tareas
pendientes
segn
cronograma
de tareas de
diseo.
17/04/ 21:00
09
23:00
00:30
1:30
Construccin
Revisin
de caso
de uso
17/04/ 09:00
09
15:00
01:00
5:00
Construccin
Revisin
de caso
de uso
20/04/ 21:00
09
23:00
00:00
2:00
Construccin
Desarroll
o de
caso de
uso
Revisin de
los flujos del
caso de uso
para
inspecciona
r y visionar
la manera
de
implementar
lo.
Reunin
con el grupo
para validar
el prototipo
arquitectural
y realizar
primeras
pruebas de
funcionalida
des.
Desarrollo
de
funcionalida
d de
generar
reporte de
recaudo
diario.
24

21/04/ 21:00
09
01:00
00:30
02:30
Construccin
Desarroll
o de
caso de
uso
Desarrollo
de
funcionalida
d de
generar
reporte de
recaudo
diario con
sus
respectivas
pruebas
unitarias.
26/04/ 14:00
09
20:00
01:00
05:00
Construccin
Desarroll
o de
caso de
uso
27/04/ 20:00
09
23:00
0:30
2:30
Post mortem
Evaluaci
n
28/04/ 20:00
09
23:00
0:30
2:30
Post mortem
Evaluaci
n
Desarrollo
de
funcionalida
d de
generar
reporte de
recaudo
diario con
sus
respectivas
pruebas
unitarias.
Evaluacin
de los
diferentes
roles de
TSP en el
proyecto.
Evaluacin
del
desempeo
del equipo
el proyecto.
Ejemplo de control de actividades por cada uno de los miembros del equipo. Tomado de Toro, Escalln,
Villegas y Mario 2009.
25

3. Seguimiento del proyecto: se da seguimiento a las tareas realizadas durante el desarrollo del proyecto mediante una plantilla
como la siguiente.
Realizar la carta de
Lanzamiento Alcance constitucin del proyecto con
sus objetivos y alcances.
Lanzamiento Equipo
Conformacin del equipo de

trabajo.
Lanzamiento Roles
Asignacin de roles a cada

miembro del equipo de
trabajo.
Lanzamiento Glosario
Elaboracin del glosario de

trminos del proyecto.
3
1
2
1
Lanzamiento
Estrategi Definir el ciclo de vida de

a
desarrollo.
Lanzamiento
Estrategi Elaborar el diseo

a
conceptual.
1
3
Tamao
Nm. semana
6 6 Hojas
1 2 2 8 8
1,2,3
5 11 Hojas
1, 3,
5 13
67 67
1,2,3
4 15 Hojas
1,
5 4 17
33
1,2,3
5 20 Hojas 10
1, 6,
3 20
67 67
1,2,3
7 27 Hojas
2,
9 4 24
33
1,2,3
3 30 Hojas
1 1 10 2 26
1,2,3
Seguimiento del proyecto. Tomado de Toro, Escalln, Villegas y Mario 2009.
Actual
Valor planeado
Acumulados
Horas
Horas acumuladas
Semana
Plan de
tamao/valor
Horas acumuladas
Tamao de unidades
Toral de horas de equipo
Gerente de Calidad/
producto
Gerente de soporte
Gerente de planeacin
Gerente de desarrollo
Lder de equipo
Nm. de ingenieros
Horas del plan
Nombre de la tarea
Fase
Parte
Tareas
26

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 lder de proyecto forme el equipo
de trabajo con cuatro involucrados en conjunto con el gerente de planeacin, al cual se le
estimaron tres horas para culminar sus tareas con un total de horas acumuladas de seis,
tambin 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
Semana
Fecha
Nm.
Actual
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
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, Escalln, Villegas y Mario 2009.
Al concluir con las actividades se hace un anlisis de los datos obtenidos configurando un
reporte de calidad; para ello, se puede hacer uso de los siguientes elementos.
Logros alcanzados: se hace una revisin de los logros que se pudieron alcanzar y que
fueron planeados previamente, con una breve descripcin 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 solucin para que se pudiera completar la actividad.
27

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 tambin 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 ningn problema, se detecta en qu se fall o la
manera en que se pude mejorar para los siguientes proyectos.
Toda esta informacin debe ser registrada de manera conjunta entre lder de proyecto y
los integrantes del equipo para evaluar los resultados obtenidos, incluyendo al
administrador del proyecto.
En conclusin, el objetivo principal del post mortem, ya sea de manera individual o en
equipo, es proporcionar informacin y conocimientos para que sea posible mejorar
significativamente el desempeo de las tareas asignadas. Es importante tomar en cuenta
que, cada uno de los integrantes que conforman el equipo debe estar comprometido en la
recopilacin de la informacin general desde el inicio hasta la culminacin 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 segn lo planeado al inicio. Tambin aprendiste a elaborar las
plantillas de revisin de la administracin y la de reporte administrativo del estatus.
Asimismo estudiaste la fase post mortem de TSP, que proporciona una retroalimentacin
de los aciertos y errores en el desarrollo del proyecto; la forma de comparar las mtricas
de calidad contra el trabajo realizado por parte del equipo y la manera de elaborar el
anlisis su desempeo.
Como conclusin 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 metodologa de calidad como TSP, que te aporta una gua de lo que debes
hacer para que tu proyecto se lleve a cabo y logre la calidad deseada.
Ojal que la informacin 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 ests
laborando o te integres en un futuro.
28

Para saber ms
En esta pgina encontrars informacin diversa acerca de las herramientas de medicin
de la calidad del desarrollo de software, entre ellas TSP, as como diversos artculos y
documentos sobre dicha metodologa.
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 originacin de crdito,

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 cmo se hace un reporte de estado del proyecto.

Mxico: IAAP.
Gmez, A. (2008). Introduccin a la Computacin. Mxico: Cenage Learning.
Toro, G., Escalln, H., Villegas, A. y Mario, K. (2009). Modelos y estndares 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%2Fsvnhistory%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_
Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqzNsPl2QWVz4Ew&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.
29

Unidad 3 Gestion en TSP

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Unidad 3 Gestion en TSP

Caricato da

Copyright:

Formati disponibili

Desarrollo de software en equipo (TSP)

Unidad 3. Gestin en TSP

Ingeniera en Desarrollo de software

Unidad 3. Gestin en TSP

Universidad Abierta y a Distancia de Mxico

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

Unidad 3. Gestin en TSP

Determinar la funcin de gestin a partir de la metodologa Team Software

Aplicar la mecnica de gestin de la metodologa TSP para tomar decisiones

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

3.1. Monitoreo y control del proyecto

3.1.1. Ejecutar la revisin de la administracin del proyecto

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

tiene an errores se regresar al equipo de desarrollo, para que realice las

Plantilla de revisin de la administracin del proyecto. Tomado de Humphrey, 2006.

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

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

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

Fabricacin Juan Prez

Esto mdulo fue

Plantilla de revisin de la administracin del proyecto.

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

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 situacin actual del

Desarrollo de software en equipo (TSP)

lo planeado en un inicio, y en caso de que no sea as saber por qu no se est

Nombre del proyecto

Nombre o rol del

Estatus general del proyecto

Estatus del proyecto a nivel entregable/fase

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

Actividades relevantes del periodo

Nombre o rol del

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

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

A continuacin se expone un ejemplo mediante el cual se ilustra la forma de llenar la

A los profesores, capturar las calificaciones de los alumnos

Para el desarrollo del software se asign un presupuesto de $ 800,000.

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

fase de integracin y pruebas del sistema, de acuerdo al ciclo de vida de desarrollo

Sistema de administracin escolar EscolaRis

Estatus General del proyecto

Situacin general del proyecto

Estatus del proyecto a nivel entregable/fase

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

Actividades relevantes del periodo

Plantilla de reporte administrativo del estatus del proyecto

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de software en equipo (TSP)

Un punto a considerarse es que si surgen riesgos y problemas que impacten

3.2. Anlisis post mortem

Calidad de los productos

La informacin debe estar debidamente recolectada y organizada, de no ser as se