Unidad 3 Gestion en TSP

Desarrollo de Software en Equipo TSP Unidad 3. Gestin en TSP

0 Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Programa de la asignatura:

Desarrollo de Software en Equipo TSP

8 Cuatrimestre

Unidad 3. Gestin en TSP

Clave:

150930934

Universidad Abierta y a Distancia de Mxico

UnADM


1

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

Actividad 1. Evidencia de administracin de trabajo y calidad del proyecto. ...................... 6

3.1.2. Elaborar el reporte administrativo del estatus del proyecto ...................................... 6

Actividad 2. Reporte del seguimiento del proyecto ........................................................... 14

3.2. Anlisis postmortem .................................................................................................. 14

3.2.1. Diagnstico: mtricas de calidad versus trabajo realizado ..................................... 15

3.2.2. Elaborar el anlisis del desempeo del equipo ...................................................... 20

Autoevaluacin ............................................................................................................... 36

Evidencia de aprendizaje. Generacin del reporte de calidad del proyecto ...................... 36

Autorreflexiones ............................................................................................................... 36

Cierre de la unidad .......................................................................................................... 37

Para saber ms ............................................................................................................... 38

Fuentes de consulta ........................................................................................................ 38


2

Unidad 3. Gestin en TSP

Presentacin de la unidad

Te damos la ms cordial bienvenida a la Unidad 3 Gestin en TSP, en la cual 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

postmortem, as como el monitoreo y control del proyecto necesarios para que la parte

administrativa del proyecto lo revise y as sea posible contar con una medida exacta

del avance que se tiene del mismo.

Tambin aprenders a implementar la fase postmortem 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 poder considerarlo para futuros proyectos.

Propsitos

Al finalizar el estudio de esta unidad podrs:

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

(TSP), para que evalen el avance que va teniendo el desarrollo del proyecto.

Identificar el estatus del proyecto a partir de un reporte para saber el estado actual

en que se encuentre el proyecto.

Analizar los problemas de calidad del equipo de trabajo que estn a cargo del

desarrollo del proyecto, mediante reportes.

Competencia especfica

Aplicar la mecnica de gestin de la metodologa Team Software Process (TSP) para

tomar decisiones gerenciales del proyecto a partir de los reportes.


3

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 va marchando 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 relacionadas al proyecto se

realicen en forma adecuada, as como el seguimiento del presupuesto que se asign

para la elaboracin del proyecto y recursos humanos involucrados en el proyecto.

Para la supervisin y seguimiento del proyecto, es necesario realizar acciones de

monitoreo y control del proyecto 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 trazados al inicio del mismo 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 del proyecto

implementando 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, el

plan de riesgos y el plan de proyecto. Cuando se ejecuta el plan de calidad se hacen

las revisiones de cdigo correspondientes al diseo y el desarrollo del proyecto. En

este captulo aprenders a realizar la revisin pero de todo lo ya realizado incluyendo

desarrollo y pruebas del sistema.

La revisin de la administracin es importante antes de arrancar la fase postmortem en

un proyecto que est ocupando la metodologa TSP. 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 est desarrollando 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 aparte se

tendr que desarrollar la parte del software donde realizarn las ventas de los

productos. Aqu el software se dividir en dos mdulos, uno que se encargar de la

parte de la fabricacin de los productos y el otro se encargar de llevar acabo las

ventas de los productos, al momento de realizar las pruebas del sistema se encontr

que el mdulo de ventas ya fue revisado y no se encontraron errores fue liberado


4

correctamente. El segundo mdulo se revis por parte del equipo de calidad pero se

encontr que ms de la mitad del mdulo tiene an errores.

Siguiendo el ejemplo anterior el equipo de desarrollo y diseo primero entregar el

mdulo correspondiente a la parte que se va a dedicar a la fabricacin de los

productos y despus se entregar el mdulo que se refiere a la venta de los mismos.

El equipo de calidad y los administradores del proyecto evaluarn, revisarn y

aprobarn cada mdulo, como se vaya terminando de revisar, si el sistema tiene an

errores se regresarn a el equipo de desarrollo, para que realicen las modificaciones

correspondientes.

Para hacer este seguimiento de la administracin del proyecto, TSP proporciona una

plantilla para hacer la revisin de la situacin del proyecto de acuerdo a las pruebas

realizadas llamada Plantilla de revisin de la administracin del proyecto y 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. (Humphrey, 2006).

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

cambios tal como se menciona en la unidad 2 en el tema 2.1.1 Documentar propsitos,

objetivos y roles del equipo.

A continuacin se explicar qu es lo que se tiene que integrar en cada columna de la

plantilla Plantilla de revisin de la administracin del proyecto.:

Nombre del mdulo: En esta columna se integrar el nombre del mdulo continuando

con el ejemplo anterior se mencionan dos mdulos, uno lleva por nombre ventas y el

otro se llamar 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 dependiendo del nmero de mdulos.

Nombre del encargado de la revisin: Aqu se integrar el nombre de la persona

que llev a cabo las pruebas del mdulo correspondiente.


5

Nombre del rol: En esta columna se escribir el rol del encargado de las pruebas del

mdulo, este rol se obtiene de acuerdo al rol que se le haya asignado segn la

metodologa TSP y el equipo en el que se encuentre.

Porcentaje completado: El porcentaje completado del mdulo correspondiente, se

integra en una columna identificada con colores dependiendo del porcentaje concluido

del mdulo correspondiente, a continuacin explicar detalladamente:


0 a 40%

41 a 80%

81 a 100%

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

administrador de calidad, integrar sus observaciones en cuanto a la revisin del

mdulo.

Retomando el ejemplo anterior, se expone el llenado de una plantilla de revisin de la

administracin del proyecto.

Nombre del mdulo

Nombre del encargado de la revisin

Nombre del rol


Observaciones

Ventas Juan Prez Administrador de calidad

100% Esto mdulo fue revisado y aprobado para su liberacin por parte del equipo de calidad

Fabricacin de productos

Juan Prez Administrador de calidad

40% En este mdulo se encontraron an muchos errores por lo que se regresaron al equipo de desarrollo para que realicen las modificaciones correspondientes

Es importante mencionar que los porcentajes de completado se definen en las juntas

que se hacen en la fase de lanzamiento de TSP esto lo realiza el administrador de

calidad junto con su equipo de pruebas.


6

En conclusin, se puede decir que esta plantilla es importante, por que proporciona

una clara idea del estado del proyecto una vez que ya se han ejecutado las pruebas

del software. Al contar con esta plantilla se tiene una medida bien definida del estado

del proyecto. El monitoreo y control se divide en dos partes, la revisin de la

administracin del proyecto y el reporte administrativo del estatus del proyecto el cual

se abordar en el siguiente captulo antes de pasar a la fase postmortem de TSP.

Actividad 1. Evidencia de administracin de trabajo y calidad del

proyecto.

Esta actividad tiene como propsito que integres los elementos de la Plantilla de

revisin de la administracin del proyecto e identifiques su relacin con elementos de

calidad del proyecto mediante el planteamiento de un problema correspondiente a un

proyecto de software que te har llegar tu Facilitador(a), una vez que cuentes con l:

1. Identifica los elementos de la plantilla de revisin de la administracin del

proyecto: nombre del mdulo, nombre del encargado de la revisin, nombre

del rol, porcentaje completado, observaciones.

2. Genera la Plantilla de revisin de la administracin del proyecto.

3. Redacta tus conclusiones acerca de los elementos que integran esta plantilla

y por qu son importantes para la revisin de la administracin del proyecto.

4. Guarda la actividad con el nombre DDSE_U3_A1_XXYZ. Sustituye las XX

por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y

la Z por tu segundo apellido.

5. Enva tu actividad al facilitador mediante la herramienta Tareas.

*No olvides consultar el documento Criterios de evaluacin para las actividades de

la unidad 3 donde podrs conocer los parmetros de evaluacin de esta actividad.


7

3.1.2. Elaborar el reporte administrativo del estatus del proyecto

En este captulo se abordar lo correspondiente al reporte administrativo del estatus

del proyecto, este reporte es esencial para poder conocer el estado actual del proyecto

en general y si los tiempos y costos del proyecto no han rebasado lo planeado.

Un reporte de estatus del proyecto es un documento que informa el estado actual de

un proyecto. Su principal propsito es comunicar al receptor si el proyecto 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: Recuerda que un proyecto como se

mencion en el captulo anterior puede dividirse en mdulos los cuales se

entregaran no todos juntos sino uno por uno, a eso se refiere este punto.

Actividades relevantes del periodo: Se describen actividades que tengan

importancia durante el periodo en que se realiza la plantilla

Riesgos : se describen los riesgos que surgieron durante el periodo de inicio

del proyecto hasta que se elabora la plantilla

Problemas: se describen problemas referentes al software realizado durante el

periodo de inicio del proyecto hasta que se elabora la plantilla.

Como se mencion, en este reporte quedar plasmada la situacin actual del

proyecto, el propsito de este reporte es comunicar si el proyecto se va desarrollando

de acuerdo a lo planeado al inicio del mismo y en caso de que no sea as poder saber

por qu no se est cumpliendo con los objetivos. Es importante remarcar que este

reporte no se utiliza para registrar el trabajo que realiz el equipo del proyecto, para

esto TSP proporciona los planes vistos en la Unidad 2. Implementacin de TSP, su

funcin principal es dar cuenta de los desvos del plan realizado al inicio del proyecto y

as poder buscar y plantear una solucin adecuada. En este reporte TSP indica que

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 y las medidas o acciones que se

tomaron para corregir este problema, el porcentaje de avance en los entregables los

cuales se mencionan en la Unidad 1 Introduccin a TSP y el costo actual del proyecto.

La plantilla para elaborar este reporte que TSP brinda tiene por nombre: Plantilla de

Reporte administrativo del estatus del proyecto y es la siguiente:


8

Proyecto Nombre del proyecto

Id Cdigo del identificador (Este cdigo depende totalmente de la

empresa que est desarrollando el software, se refiere al cdigo

que se asign al proyecto).

Lder de proyecto Nombre del lder

Periodo dd/mm/aa dd/mm/aa(periodo del inicio del proyecto hasta la

fecha en que se realiza la plantilla).

Acuerdos anteriores

Acuerdo Estado Fecha Compromiso

Responsable/Rol

Observaciones

Descripcin del acuerdo(descripcin del nmero de acuerdo al momento de realizar la plantilla)

Indica si el acuerdo est abierto o cerrado (Abierto se deja cuando no se logr el avance planeado)

Fecha lmite en la que debe cumplirse el acuerdo

Nombre o rol del encargado de cumplir el acuerdo

Comentarios relacionados al acuerdo este comentarios los

Estatus General del proyecto

Avance %

Avance planeado %

Avance real %

Desviacin % de avance planeado menos

avance real

Situacin general del proyecto Descripcin de las razones que originan el estatus del proyecto (se refiere a los motivos por los cuales hay un desvo 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

Estatus

0-40%

41-80%

81-100%


9

Nombre del entregable o fase

Indicar el estatus del entregable o fase (verde, amarillo o rojo)

Cantidad asignada al entregable o fase del proyecto(este presupuesto del proyecto se da en la fase de lanzamiento de TSP)

Costo actual del entregable o fase(es el costo del proyecto al momento de realizar la plantilla)

Porcentaje del avance del entregable o fase

Observaciones relacionados al entregable o fase

Actividades Relevantes del periodo

# Actividad

Descripcin breve de la actividad realizada en el periodo

Problemas

# Problemas Respuesta Responsable/rol Fecha Compromiso

Descripcin del problema

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 lmite para solucionar el problema (proponer una fecha para darle solucin al problema)

Riesgos

ID Riesgo Probabilidad Impacto

Prioridad Respuesta

Responsable

Nmero de la revisin correspondiente (1,2,3 etctera)

Descripcin 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

Plan de accin para hacer frente al riesgo

Nombre o rol del encargado de ejecutar el plan de respuesta


10

analizar el impacto que tendr en el proyecto(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 (Siles, 2012).

Como punto principal esta plantilla la realizar el administrador de proyectos, por lo

tanto l realizar las observaciones correspondientes que se pidan en la plantilla, ms

adelante, mediante un ejemplo se especificar concretamente.

Otro punto a remarcar es que todos los estatus se considerarn de acuerdo al avance

del proyecto y se les asignar un color, a continuacin se muestra el color de acuerdo

al avance del proyecto:


0 a 40%

41 a 80%

81 a 100%

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

plantilla anterior:

Se est realizando un proyecto de software que est dirigida al apoyo de servicios

escolares y administracin escolar de una institucin educativa el proyecto tienen por

nombre Sistema de administracin Escolar EscolaRis, se requiere que el sistema

permita:

A los profesores el poder capturar las calificaciones de los alumnos.

Al rea de servicios escolares, poder contar con los datos completos de los

alumnos y el historial acadmico as como realizar: altas, bajas, registro de

exmenes extraordinarios, etctera.

Al rea de administracin escolar contar un registro de los alumnos que estn

inscritos en la escuela y tambin de egresados.

A los padres de los alumnos contar con un mdulo va web, que les permita

conocer sus calificaciones as como las observaciones realizadas por los

profesores sobre el estatus acadmico de cada uno de sus alumnos.

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


11

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 solo se logr el 35% de avance, el costo actual del

proyecto es de$ 200,000. Algo que preocupa a la empresa que desarrolla este

software es que el cliente est solicitando ms requerimientos de los que se

plantearon al inicio del proyecto y es difcil implementarlos ya cuando 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 Administracin Escolar EscolaRis

Id AE1

Lder de proyecto Rubn Hernndez

Periodo 05/01/2012- 25/04/2012

Acuerdos anteriores

Acuerdo Estado Fecha Compromiso

Responsable/Rol Observaciones

Este es el primer acuerdo del proyecto

Abierto 22-Abril-2012

Administrador de proyectos

El acuerdo se encuentra abierto ya que es la primera revisin

Estatus General del proyecto

Avance %

Avance planeado 40

Avance real 35

Desviacin 5

Situacin general del proyecto

El proyecto est bien pero tiene una desviacin de 5% debido a que se regres al rea

de desarrollo para hacer las correcciones correspondientes de las observaciones

hechas por el equipo de calidad.

Estatus

35%


12

Estatus del proyecto a nivel entregable/fase

Entregable/fase Estatus Presupuesto Costo Avance Observaciones

Entregable 1 35% $800,000 $200,000 35% El proyecto se encuentra bien en relacin presupuesto/costo aunque tenga una desviacin del 5%

Actividades Relevantes del periodo

# Actividad

1 Se realizaron los mdulos correspondientes a los catlogos de maestros y alumnos

2 Se realizaron 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

# Problemas Respuesta Responsable/rol Fecha Compromiso

1 Requerimientos nuevos que est pidiendo el cliente

Se platicar con el cliente para poder realizar estos cambios una vez que se entregue lo acordado al principio del proyecto

Lder de Proyecto

03-Mayo-2012


13

Riesgos

ID Riesgo Probabilidad Impacto Prioridad Respuesta Responsable

1 Nuevos errores una vez que se realice la 2da revisin del proyecto

Alta Alto Alta Hacer pruebas por parte del lder de desarrollo antes de enviar a el equipo de pruebas

Lder de Desarrollo

Plantilla de reporte administrativo del estatus del proyecto.

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

directamente con el presupuesto tales como el cambio de algn integrante del equipo

o cuestiones que pongan en riesgo los objetivos que se planearon al inicio del

desarrollo del software, estas decisiones sobre la forma de solucionarlas, las tomar la

alta gerencia.

En este captulo 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 captulo se abordar el tema

correspondiente a la elaboracin de las plantillas en la fase postmortem.


14

Actividad 2. Reporte del seguimiento del proyecto

En esta actividad generars el reporte de seguimiento de un proyecto para saber el

estatus de avance que se tiene sobre el mismo, para ello, tu Facilitador te har llegar

un planteamiento de problema, una vez que cuentes con el planteamiento:

1. Identifica en el problema planteado los elementos necesarios para realizar el

reporte administrativo del estatus del proyecto.

2. Elabora la Plantilla de Reporte administrativo del estatus del proyecto.

3. Redacta tus conclusiones acerca de por qu es importante el reporte

administrativo del estatus del proyecto en relacin con el problema planteado.

4. Guarda la actividad con el nombre DDSE_U3_A2_XXYZ. Sustituye las XX por

las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z

por tu segundo apellido.

5. Enva tu actividad al facilitador mediante la herramienta base de datos.

6. Comenta la actividad de por lo menos dos de tus compaeros e identifica

semejanzas y diferencias respecto a tus propias conclusiones.

*No olvides consultar el documento Criterios de evaluacin para las actividades de la

unidad 3, donde podrs conocer los parmetros de evaluacin de esta actividad.

3.2. Anlisis postmortem

En esta unidad se explicarn las actividades que se llevan a cabo en el ltimo proceso

del TSP que es la fase postmortem, el cual es un medio de aprendizaje estructurado

para el equipo de desarrollo, ya que proporciona 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 postmortem tambin aprenders a realizar un diagnstico sobre

las mtricas de calidad aplicadas al trabajo realizado durante el desarrollo del

software.

El postmortem sirve de retroalimentacin para todos los integrantes del equipo, porque

se estudia la manera en que se trabaj durante el desarrollo del proyecto, analizando


15

la forma de realizar las actividades y detectando en qu se fall y en qu se obtuvieron

resultados positivos, todo esto con la finalidad de que los equipos y lderes de proyecto

puedan ser ms eficaces y puedan considerar los errores y las acciones positivas para

estar preparados para mejorar en los siguientes proyectos. (Humphrey, 2006)

Cuando se llega al final de cada ciclo de un proyecto se entra a la fase postmorten

donde los equipos de TSP cuentan con una gran cantidad de informacin, la cual

contiene, entre otros, los siguientes elementos:

La calidad de sus productos

Estimaciones.

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 postmortem en la culminacin de cada proyecto, aprovechando que

la informacin recabada y la experiencia del trabajo realizado por el equipo de

proyecto son 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

postmortem tiene el mismo propsito, evaluar los resultados obtenidos verificando y

verificando el nivel de cumplimiento de lo planeado que en este caso se refiere a las

mtricas de calidad establecidas por el equipo de proyecto.

3.2.1. Diagnstico: mtricas de calidad versus trabajo realizado

En este captulo aprenders a realizar el diagnstico de las mtricas de calidad que se

realizaron en el plan de calidad el cual se vio en la unidad 2 y comparar con el trabajo

que se realiza para poder evaluar los resultados obtenidos, es muy importante que se

tome en cuenta que se debe tener bien comprendido el plan de calidad para poder

realizar este proceso final postmortem.

Para poder realizar el diagnstico de las mtricas de calidad contra el trabajo que se

realiz 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 llevan a cabo y analizar en qu estn fallando o la manera

en que pueden mejorar, as como darles la oportunidad de expresar sus

inconformidades e inquietudes (Humphrey, 2006).

El encargado de las 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. Recordemos que una mtrica es un valor cuantificable que puede ser medible.

A continuacin se muestra un ejemplo sobre el anlisis del trabajo realizado por parte

del gerente de calidad en un proyecto y los resultados conseguidos. En este ejemplo


16

se mostrar el trabajo que realizo el Gerente de Calidad mediante un informe

postmortem para el proyecto que lleva por nombre Apertura de crdito del Banco de

Los Alpes en dicho ejemplo se observa el registro del cumplimiento de las actividades

planeadas por semana, para que finalmente sea posible evaluar el cumplimiento de los

objetivos planeados (Archila, Molano, Kook, Gutirrez y Larrota, 2010).

Acciones Semana 12

Semana 13

Semana 14

Semana 15

Semana 16

Semana 17

Total

Planeado 38 22,5 31 10 9,5 7 118

Esfuerzo 18,5 42,25 15 10 8 6 99,75

Ejecutado

8 39 13,5 11,5 12 3,5 87,5

Cumplimiento de compromisos del Lder de calidad. (Archila, Molano, Kook, Gutirrez

y Larrota, 2010).

En esta tabla se muestra la distribucin de las horas planeadas por semana para la

realizacin de las activadas que tiene a su cargo el rol de lder de calidad el cual fue

planeado por parte del equipo de proyecto y el esfuerzo que se refiere a la suma de

tiempos dedicados a esa actividad y por ltimo se muestra lo ejecutado que ver el

cumplimiento real de lo que se plano.

A continuacin se describe el objetivo propuesto por el equipo y se revisa en la

siguiente tabla la distribucin de las mtricas planeadas y el resultado obtenido, la

mtrica es el valor que se le est dando a la actividad para que pueda ser medido, por

ejemplo, encontramos en la tabla de objetivos globales de grupo la mtrica Promedios

de evaluacin del rol por ayudar y soporte superior a 4. El 4 es una medida que se le

asigna a cada miembro del equipo para saber si el cumplimiento es malo, regular,

bueno, excelente o si no es aplicable para su evaluacin.

Objetivo 1

Ser un miembro efectivo y cooperativo.

Mtrica Resultado

Promedio de evaluacin del rol por ayuda y soporte superior a 4

Bu

en

o

Promedio de evaluacin de 4,25.

Promedio de evaluacin del rol contribucin global superior a 4

Re

gu

lar

Promedio de evaluacin exactamente igual a 4.

Informe de logros del equipo de trabajo: objetivos globales de grupo. (Archila, Molano,

Kook, Gutirrez y Larrota, 2010).


17

En la siguiente tabla se observa el objetivo planeado por el lder de calidad en cuanto

a la efectividad y cooperacin.

Objetivo 2

Hacer el trabajo personal de manera disciplinada consistentemente.

Mtrica Resultado

Promedio de evaluacin del rol por ayuda y soporte superior a 4

Bu

en

o

Promedio de evaluacin de 4,25.

Promedio de evaluacin del rol contribucin global superior a 4

Re

gu

lar

Promedio de evaluacin exactamente igual a 4.

Objetivo global lder de calidad: efectividad y cooperacin. (Archila, Molano, Kook,

Gutirrez y Larrota, 2010).

Se observa en la siguiente tabla que la mtrica cambia a un valor en porcentaje para

establecer el cumplimiento del objetivo, que est en una escala de %0 a 100% (Ver la

siguiente tabla Objetivo global lder de calidad-Disciplina).

Objetivo 3

Planear y hacer seguimiento al trabajo personal.

Mtrica Resultado

Porcentaje de datos personales

registrados en las formas

resumen Planeacin y Resumen

Calidad es 100% No

Ap

lica Las estrategias para consolidar el

seguimiento personal fueron negociadas

con el grupo, y las formas a las que se hace

referencia fueron descartadas.

Porcentaje de tareas planeadas y

completadas 100%

Ma

lo

El lder de planeacin realiz slo el 57%

de las actividades planeadas durante el

ciclo.

Objetivo global lder de calidad: disciplina. (Archila, Molano, Kook, Gutirrez y Larrota,

2010).

De la misma manera que los dems objetivos propuestos por el equipo de proyecto se

revisa el cumplimiento de lo planeado as como su resultado obtenido como se

observa en la siguiente tabla.


18

Objetivo 4

Hacer productos de calidad.

Mtrica Resultado

Promedio de defectos encontrados antes de la primera compilacin: >70%

Bu

en

o

Se encontr el 72% de los defectos esperados antes de la primera compilacin.

Densidad de los defectos encontrados durante compilacin:


19

Nmero de

recomendaciones

establecidas en las

revisiones.

Exce

lente

De acuerdo al proceso de calidad establecido

conjuntamente entre los miembros del grupo, se

realizaron las modificaciones directamente sobre

los artefactos, con un promedio de 12

modificaciones por artefacto revisado.

Artefactos alineados a los

estndares definidos.

Bu

en

o

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.

10 o menos defectos por

KLOC hallados durante la

compilacin.

Bu

en

o

Se encontraron en promedio 7,2 defectos por KLOC

durante la compilacin.

5 o menos defectos por

KLOC hallados en la fase

de pruebas.

Re

gu

lar

Las pruebas locales funcionaron correctamente.

Sin embargo, al tratar de exponer como un servicio,

el componente no funcion adecuadamente.

0 defectos hallados

despus de la fase de

pruebas.

No

ap

lica La medida no ha podido ser verificada, puesto que

an la herramienta no ha superado la etapa de

pruebas.

Objetivos especficos de rol. (Archila, Molano, Kook, Gutirrez y Larrota, 2010).

En 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 de

manera conjunta por el lder de proyecto y los integrantes del equipo donde se va

verificando con el objetivo propuesto por el responsable de llevar el rol que en este

caso es el lder de calidad al final se debe hacer una conclusin o diagnstico de los

resultados obtenidos, en estos resultados se determina si se cumpli o no con los

objetivos propuestos o de qu manera pueden mejorar.

La 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 postmortem, 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.


20

3.2.2. Elaborar el anlisis del desempeo del equipo

En este tema 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,

esto se realiza en el paso final del proceso de TSP postmortem. Dentro de la fase de

postmortem se debe analizar el desempeo de los objetivos del equipo, esto debe

realizarse con base en la calidad, costos y el tiempo que se utiliz para el

cumplimiento de los objetivos planteados por el equipo (Humphrey, 1999).

TSP recomienda que antes de comenzar con la recoleccin de informacin se debe de

tomar en cuenta de qu forma van a ser utilizados los datos recolectados, es por eso

que se debe generar un plan de recoleccin de informacin ya que de no hacerlo se

puede llegar a perder tiempo en el procesos de recoleccin de informacin.

El gestor de configuracin es el encargado de preparar con anticipacin la forma en

que se va a recolectar la informacin pidiendo a los miembros del equipo la mejor

manera en que ellos puedan recolectar la informacin de tal manera que esta

informacin pueda ser presentada durante las reuniones que se lleguen a realizar

para llevar a cabo el postmortem en la culminacin del proyecto.

Cada uno de los integrantes del equipo de proyecto debe tener una adecuada actitud

durante la fase del postmortem.

En la fase de postmortem se tiene que iniciar con las reuniones con los integrantes del

equipo, en el cual se realizan las siguientes actividades (Humphrey, 2006):

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 de llevar

acabo las reuniones en donde se revisan los datos del lanzamiento, los cuales debe

de asegurarse que todos los datos obtenidos sean completos, precisos y que puedan

estar disponibles para su revisin, mas delante de este captulo se ver una plantilla

para realizar estas actividades.

Preparar la propuesta de mejora de procesos: Esta actividad consiste en generar

comentarios y sugerencias por porte de los integrantes del equipo sobre cmo poder

mejorar los procesos con 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


21

de tal manera que se pudenda identificar los procesos o reas que se deben de

cambiar o mejorar. Para poder hacer la evolucin de debe de llenar en formularios.

Reunin de la documentacin del lanzamiento: Finalmente se debe reunir la

documentacin de la propuesta de mejora de procesos y otras propuestas de manera

correcta y drselas 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 postmortem basado en el TSP (Toro, Escalln, Villegas y Mario, 2009).

Introduccin: Es una breve explicacin del contenido del documento del postmortem.

Propsito: Se redacta lo que se espera de la realizacin de este documento.

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 Actual

Semana Fecha Horas

direct

as

Horas

Acumul

adas

Valor

Planeado

Ganado

Hora

s del

Equi

po

Horas

Acumula

das

Valor

gana

do

por

sema

na

Acumula

cin del

valor

ganado

No.

1 01/04/2009 48 43 14,33 48 48 14,33 14,33

2 08/04/2009 48 91 30 48 96 30 44,33

3 15/04/2009 68 159 49,33 64 160 23 67,33

4 27/04/2009 93 252 82,33 109 269 32,33 99,67

5 04/05/2009 48 300 100 31 300 0,33 100

Ejemplo de revisin post mortem por ciclos del proyecto ECOSSOCCER (Toro,

Escalln, Villegas y Mario, 2009).

En la tabla anterior se muestran las horas planeadas para realizar las actividades en la

fase del lanzamiento, en la cual del lado derecho se muestran las horas planeadas por

semana y del lado derecho el valor de cumplimiento de lo planeado.


22

A continuacin se elabora la siguiente tabla para verificar el cumplimiento de las

tareas.

Ejemplo de revisin de tareas del proyecto ECOSSOCCER (Toro, Escalln, Villegas y

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 terminar de evaluar cada uno de los ciclos del TSP durante

el desarrollo del proyecto se toman en cuenta una serie de criterios para detectar en

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 disciplina de trabajo etc.,

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 como se mencion en este

captulo se debe llevar acabo la evaluacin del rendimiento del equipo y de cada uno

de los miembros del equipo. 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.

Fase Parte Nombre de la Tarea

Lanzamiento Alcance Realizar la carta de constitucin del proyecto con los

objetivos y alcance del mismo.

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.


23

Ejemplo de formulario de evaluacin personal y del equipo

Nombre Adrin Villegas Equipo ESG Lder de

Proyecto

Dalia Trujillo

Fecha 29/04/2009 Ciclo No. 01 Semana No. 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 1 2 3 4 5

Efectividad Global 1 2 3 4 5

Experiencia Gratificante 1 2 3 4 5

Productividad del

Equipo

1 2 3 4 5

Calidad del Proceso 1 2 3 4 5

Calidad del Producto 1 2 3 4 5

Evala rol por contribucin total: indique un nmero del 1 (mn.) a 5 (mx.).


24

Lder de Equipo 1 2 3 4 5

Gerente de Desarrollo 1 2 3 4 5

Gerente de Planeacin 1 2 3 4 5

Calidad/Gerente de

Proceso

1 2 3 4 5

Gerente de Proceso 1 2 3 4 5

Evala cada rol por ayuda y soporte: indique un nmero del 1 (mn.) a 5 (mx.).

Jefe de Equipo 1 2 3 4 5



Calidad/Gerente de

Procesos

1 2 3 4 5

Gerente de Soporte 1 2 3 4 5

Evala rol respecto a su desempeo: indique un nmero del 1 (mn.) a 5 (mx.).

Lder de Proyecto 1 2 3 4 5



Calidad/Gerente de

Procesos

1 2 3 4 5

Gerente de Soporte 1 2 3 4 5

(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: El reporte de errores es

una documento o formato en donde se registran los problemas encontrados en

alguna fase o actividad dentro del desarrollo del proyecto para despus hacer los

cambios correspondientes para darle solucin estos ajustes serializan en un

documento llamado control de cambios. Siguiendo con el ejemplo del proyecto


25

ECOOSSOCCER, que se mostr anteriormente ahora se ejemplificar una tabla para

poder llevar el control de cambios del proyecto as como el reporte de errores.

Nombre Grupo Experto de Software Fecha 12/04/09

Equipo ESG (Grupo de Expertos de Software) Lder de

Proyecto

Dalia

Trujillo

Parte Nuevos requerimientos del proyecto en la

etapa de programacin o desarrollo.

Ciclo 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

1 Alta Guiller

mo

Toro

15/04/09 Si


26

Descripcin:

Fruto de la validacin, 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 (Consultar 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 un clase que tenga como atributos la fecha, el campo y el movimiento, y otra clase de Recaudado para realizar la consulta.

Se deben volver a redactar las especificaciones de todos los

casos de uso para que puedan tener el control que se

estableci 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 implementarla.

LOG (Bitcora) de eventos y cambios en el proyecto. (Toro, Escalln, Villegas y

Mario, 2009).

En el ejemplo anterior se describe el pro que 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: Este reporte debe contener los siguientes datos:

Introduccin: Breve introduccin del contenido del reporte.

tem de configuracin: Este se refiere a los cada uno de los procesos donde se

tienen que revisar los documentos que se elaboraron en cada fase del ciclo de vida

del TSP. Ejemplo:


27

Introduccin

tem de configuracin

Sigla Categora Artefactos

Fases

Lanzamiento LZ SCOPE Carta de constitucin del proyecto

TEAM Asignacin de roles

Planeacin PL 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.

Libreras

COMP Componentes de Software.

FILES Archivos Externos (Imgenes, Videos,

etc.)

Testing TS PLAN Plan de Pruebas

Reporte de Pruebas


28

Cierre PM REPORT Historia del Proyecto

Artefactos de Cierre TSP

Ejemplo de los tem de configuracin. (Toro, Escalln, Villegas y Mario, 2009).

3. Seguimiento de actividades de los miembros del Equipo: Actividad que se

realiza durante las reuniones de la fase del postmortem y que para poder llevar el

control de las actividades da cada uno de los integrantes del equipo se debe de llevar

acabo el siguiente formulario:

Nombre Adrin Villegas Fecha 31/03/09

Equipo ESG (Grupo de Expertos de Software) Instructo

r

Dalia Trujillo

Parte/Nivel Ciclo 1

Fecha Inicio Fin Tiempo de

Interrupcin

Tiempo

Delta

Fase/Tarea Compone

nte

Comentarios

03/21/

09

14:00 18:00 00:30 3:30 Lanzamiento Enuncia

do

Elaboracin

del

enunciado

del

problema.

03/21/

09

18:00 22:00 00:30 3:30 Lanzamiento Alcance Realizar la

carta de

constitucin

del proyecto

con los

objetivos y

alcance del

mismo.

03/22/

09

12:00 14:00 0:00 2:00 Lanzamiento Roles y

Equipo

Conformaci

n del

equipo de

trabajo.


29

03/22/

09

14:00 18:00 1:00 3:00 Lanzamiento Roles y

Equipo

Asignacin

de roles a

cada

miembro del

equipo de

trabajo.

03/22/

09

19:00:

00

21:00:

00

00:00 2:00 Requerimient

os

Requeri

mientos

Validacin y

listados

finales de

requerimient

os y casos

de uso con

el grupo

03/30/

09

21:00:

00

23:00:

00


os

Requeri

mientos

Especificaci

n del caso

de uso de

realizar

alquiler

3/30/0

9

00:00:

00

01:00:

00


os

Requeri

mientos

Prototipo

del caso de

uso Realizar

alquiler

02/04/

09

19:00 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.


30

04/04/

09

08:00 22:00 01:00 13:00 Lanzamiento

Estrategia

Requerimient

os

Artefacto

s

Correccione

s sobre

todos los

artefactos

de dichas

fases y

elaboracin

de nuevos

artefactos.

05/04/

09

09:00 23:00 01:00 13:00 Planeacin-

Requerimient

os

Artefacto

s

Correccione

s sobre

todos los

artefactos

de dichas

fases y

elaboracin

de nuevos

artefactos.

18/04/

09

09:00 23:00 01:00 13:00 Diseo Revisin Revisin de

tareas

pendientes

segn

cronograma

de tareas de

diseo

17/04/

09

21:00 23:00 00:30 1:30 Construccin Revisin

de caso

de uso

Revisin de

los flujos del

caso de uso

para

inspecciona

r y visionar

la manera

de

implementar

lo


31

17/04/

09

09:00 15:00 01:00 5:00 Construccin

Revisin

de caso

de uso

Reunin

con el grupo

para validar

el prototipo

arquitectural

y realizar

primeras

pruebas de

funcionalida

des.

20/04/

09

21:00 23:00 00:00 2:00 Construccin Desarroll

o de

caso de

uso

Desarrollo

de

funcionalida

d de

generar

reporte de

recaudo

diario

21/04/

09


o de

caso de

uso

Desarrollo

de

funcionalida

d de

generar

reporte de

recaudo

diario con

sus

respectivas

pruebas

unitarias

26/04/

09


o de

caso de

uso

Desarrollo

de

funcionalida

d de

generar

reporte de

recaudo

diario con

sus

respectivas

pruebas

unitarias


32

27/04/

09

20:00 23:00 0:30 2:30 Postmortem Evaluaci

n

Evaluacin

de los

diferentes

roles de

TSP en el

proyecto

28/04/

09

20:00 23:00 0:30 2:30 Postmortem Evaluaci

n

Evaluacin

del

desempeo

del equipo

el proyecto

Ejemplo de control de actividades por cada uno de los miembros del equipo. (Toro,

Escalln, Villegas y Mario 2009).


33

3. Seguimiento del proyecto: finalmente se le da seguimiento a las tareas realizadas durante el desarrollo del proyecto mediante una

plantilla como la siguiente.

Tareas Horas del Plan Plan de

Tamao /

Valor

Actual

Fase

Pa

rte

No

mb

re d

e l

a T

are

a

N

de In

ge

nie

ros

Ld

er

de E

qu

ipo

Ge

ren

te d

e d

es

arr

oll

o

Ge

ren

te d

e p

lan

ea

ci

n

Ge

ren

te d

e C

ali

da

d/

pro

du

cto

Ge

ren

te d

e s

op

ort

e

To

ral

de h

ora

s d

e e

qu

ipo

Ho

ras a

cu

mu

lad

as

Tam

a

o d

e U

nid

ad

es

Tam

a

o

No

. S

em

an

a

Va

lor

Pla

ne

ad

o

Ac

um

ula

do

s

Ho

ras

Ho

ras a

cu

mu

lad

as

Se

ma

na

Lanzamiento Alcance

Realizar la carta de

constitucin del

proyecto con los

objetivos y alcance del

mismo.

4 3 3 6 6 Hojas 3 1 2 2 8 8 1,2,3

Lanzamiento Equipo Conformacin del

equipo de trabajo. 4 1 1 1 1 1 5 11 Hojas 4 1

1,

67

3,

67 5 13 1,2,3

Lanzamiento Roles

Asignacin de roles a

cada miembro del

equipo de trabajo.

2 2 2 4 15 Hojas 2 1 1,

33 5 4 17 1,2,3

Lanzamiento Glosario Elaboracin del 1 1 1 1 1 1 5 20 Hojas 10 1 1, 6, 3 20 1,2,3


34

Seguimiento del proyecto. (Toro, Escalln, Villegas y Mario 2009).

En este ejemplo se observan las tareas que fueron planeadas en la fase de lanzamiento para cada uno de los roles del proyecto, as

como las horas asignadas para cada miembro del equipo. Se observa el nombre de la actividad que se plane y realizo as como las

horas necesarias para realizar dichas actividades, por ejemplo vemos en la fase de lanzamiento en la creacin del equip con

cuatro involucrados tres horas planeadas para que el lder de proyecto forme el equipo de trabajo 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.

glosario de trminos

del proyecto.

67 67

Lanzamiento Estrategi

a

Definir el Ciclo de vida

de desarrollo. 2 4 3 7 27 Hojas 3 1

2,

33 9 4 24 1,2,3

Lanzamiento Estrategi

a

Elaborar el diseo

conceptual. 1 3 3 30 Hojas 2 1 1 10 2 26 1,2,3


Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 35

5. Finalmente se genera un horario para reporte de cronograma donde se compara lo

planeado con los resultados obtenidos: Ejemplo de reporte de cronograma.

Al concluir con las actividades se hace un anlisis de los datos obtenidos configurando un

reporte de calidad, se puede hacer uso de los siguientes elementos.

Logros alcanzados: Se hace una revisin de los logros que se pudieron alcanzar que

fueron planeados previamente con una breve descripcin de la actividad que se cumpli.

Problemas encontrados: Se identifica eventos o actividades en las que se tuvieron

problemas para cumplir los objetivos se describe porque fue que no se cumpli con lo

planeado o si se pudo encontrar una solucin para que se pudiera completar la actividad.

Lecciones aprendidas: Esto se obtiene por medio de los problemas encontrados ya que

se pude aprender de los errores para poder prevenir que se presenten nuevamente en los

futuros proyectos as como tambin se puede aprender de las actividades que se

completaron sin contratiempos.

Nombre: Fecha:

Equipo: Instructor:

Nivel: Ciclo:

Plan Actual

Semana Fecha Horas

Directa

s

Horas

Acumulada

s

Acumulaci

n de Valor

Planeado

Horas

del

Equipo

Horas

Acumula

das

Semana

Valor

Agregad

o

Acumulaci

n de Valor

Ganado No.

1 01/04/2009 48 43 14,33 48 48 14,33 14,33

2 08/04/2009 48 91 30 48 96 30 44,33

3 15/04/2009 68 159 49,33 64 160 23 67,33

4 27/04/2009 93 252 82,33 109 269 32,33 99,67

5 04/05/2009 48 300 100 31 300 0,33 100

Reporte de cronograma programado. (Toro, Escalln, Villegas y Mario 2009).



Oportunidades de mejora: Con base en los problemas que se presentaron en relacin

con 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 que conforman el equipo para poder evaluar los resultados obtenidos,

incluyendo al Administrador del proyecto.

En conclusin el objetivo principal del postmortem 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 el equipo y cada uno de los integrantes que lo conforman deben estar comprometidos

en la recopilacin de la informacin general, desde el inicio hasta la culminacin del

proyecto. El postmortem se debe realizar al final de cada ciclo del proyecto y hasta el final

de todo el proyecto como lo marca las fases del ciclo del vida del TSP.

Autoevaluacin

Antes de desarrollar la evidencia de aprendizaje, realiza la autoevaluacin con el fin de

hacer un recuento general de la unidad; as como detectar aquellos temas que no has

comprendido en su totalidad y que necesites revisar nuevamente, o bien consultar con

tus compaeros(as) y Facilitador(a).

Para realizar la Autoevaluacin, ingresa al listado de actividades en el aula.

Evidencia de aprendizaje. Generacin del reporte de calidad del

proyecto

Como evidencia de aprendizaje generars un informe de logros del equipo de trabajo para

poder evaluar el cumplimiento de los objetivos en cuanto a las mtricas propuestas para

garantizar la calidad del proyecto mediante el planteamiento de un problema

correspondiente a un proyecto de software que te har llegar tu Facilitador (a), una vez

que cuentes con l:

1. Identifica los problemas encontrados con relacin a las mtricas planeadas.

2. Elabora el plan del informe de seguimiento del proyecto asegurndote de



integrar el objetivo personal de cada uno de los roles as como las mtricas

propuestas y el resultado obtenido apoyndote del ejemplo desarrollado en

tema 3.2.1.

3. Redacta tus conclusiones acerca del origen del problema: desempeo, calidad

del producto, etctera; as como la forma en que se pueden mejorar los

problemas presentados.

4. Guarda la actividad con el nombre DDSE_U3_EA_XXYZ. Sustituye las XX por

las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z

por tu segundo apellido.

5. Enva tu actividad al portafolio de evidencias.

*Consulta la Rbrica de evaluacin de la unidad 3 para conocer los parmetros de

evaluacin de esta actividad.

Autorreflexiones

Adems de enviar tu trabajo de la Evidencia de aprendizaje, ingresa al foro Preguntas

de Autorreflexin y consulta las preguntas que tu Facilitador(a) presente, a partir de

ellas elabora tu Autorreflexin en un archivo de texto llamado DDSE_U3_ATR_XXYZ.

Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad

En esta Unidad aprendiste porqu es muy importante realizar el monitoreo y control del

proyecto, para saber si el proyecto marcha segn lo planeado al inicio del mismo.

Dentro de este punto, aprendiste a elaborar las plantillas de revisin de la administracin

de proyecto y la plantilla de reporte administrativo del estatus del proyecto.



Tambin aprendiste a implementar la fase postmortem de TSP la cual te proporcionar

una retroalimentacin de los aciertos y errores que se tuvieron durante el desarrollo del

proyecto. Y por supuesto comparar las mtricas de calidad contra el trabajo realizado por

parte del equipo y a elaborar el anlisis de desempeo del mismo.

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 del

mismo, se necesita una metodologa de calidad y TSP es una de ellas, la cual te aporta

una gua de lo que debes hacer para que tu proyecto de desarrollo de software se lleve a

cabo y se concluya logrando la calidad deseada al final del ciclo de vida del proyecto.

Esperamos que la informacin aqu proporcionada, te sirva para lograr el xito deseado

en los proyectos que realices en tu vida profesional y sepas que hacer cuando un

proyecto de desarrollo de software no va marchando conforme a lo planeado, y con esto

seas capaz de dar soluciones a los problemas que se puedan presentar dentro de la

empresa o proyectos en los que ests laborando o en los que te integres en un futuro.

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 acerca de esta metodologa.

Software Engineering Institute Carnegie Mellon (2013). Pittsburgh:

https://www.sei.cmu.edu/library/abstracts/books/201731134.cfm

Fuentes de consulta

Archila, ngela; Molano, Edison; Kook, Enrique; Gutirrez, Gustavo y Larrota,

Jess. (2010). Informe Postmortem. Proceso de originacin de crdito, Banco de

los Alpes. Panam: Grupo NEO TEC S.A. [En lnea]

http://webcache.googleusercontent.com/search?q=cache:Vh09Kn4VN_MJ:kymera.

googlecode.com/svn/trunk/Documentation/Mejoramiento%2520de%2520Procesos/

Informe%2520Postmortem.docx+&cd=3&hl=es-419&ct=clnk&gl=mx

Esterkin, J. (2008). Qu es y cmo se hace un reporte de estado del proyecto.

Mxico: IAAP.



Gmez de Silva Garza, A. (2008). Introduccin a la Computacin. Mxico, D.F:

Cenage Learning Editores.

Toro, Guillermo; Escalln, Hans; Villegas, Adrin y Mario, Kerlyn. (2009).

Modelos y estndares de procesos de desarrollo de software. Bogot: Universidad

de los Andes. [En lnea]

http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0C

CoQFjAA&url=http%3A%2F%2Ffol-fields-on-line.googlecode.com%2Fsvn-

history%2Fr67%2Ftrunk%2FFOL%2FANALISIS%2FTSP_FOL_REQUIREMENT_

Especificacion_Plan_de_Pruebas_Linea_Base.pdf&ei=W6ESUqz-

NsPl2QWVz4Ew&usg=AFQjCNHqt19027WHxSO2sJs9B7Cc0rZ3xw&bvm=bv.507

68961,d.b2I

Humphrey, W. S. (1999). Introduction to the Team SoftwareProcess.

Massachusetts: Addison Wesley Professional.

Humphrey, W. S. (2006). TSP(SM)Coaching Development Teams. Addison-

Wesley Professional.

Unidad 3 Gestion en TSP

Documents

Transcript of Unidad 3 Gestion en TSP