Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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. 2

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 Ventas Fabricacin de productos Nombre del encargado de la revisin Nombre del rol Porcentaje completado Observacione s

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.

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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: Porcentaje completado 0 a 40% 41 a 80% 81 a 100% Observaciones: En esta columna el encargado de hacer la plantilla que ser el administrador de calidad, integrar sus observaciones en cuanto a la revisin del mdulo. Retomando el ejemplo anterior, se expone el llenado de una plantilla de revisin de la administracin del proyecto. Nombre del mdulo Ventas Nombre del encargado de la revisin Juan Prez Nombre del rol Administrador de calidad Porcentaje completado 100% Observaciones

Fabricacin de productos

Juan Prez

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 regresaron al equipo de desarrollo para que realicen las modificaciones correspondiente s

Es importante mencionar que los porcentajes de completado se definen en las juntas que se hacen en la fase de lanzamiento de TSP esto lo realiza el administrador de calidad junto con su equipo de pruebas.

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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.

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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:

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

Proyecto Id

Lder de proyecto Periodo

Nombre del proyecto Cdigo del identificador (Este cdigo 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

Acuerdo

Estado

Fecha Compromis o
Fecha lmite en la que debe cumplirse el acuerdo

Responsable/R ol
Nombre o rol del encargado de cumplir el acuerdo

Observacione s
Comentarios relacionados al acuerdo este comentarios los

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)

Estatus General del proyecto

Avance Avance planeado Avance real Desviacin

% % % % de avance planeado menos avance real

Estatus 0-40% 41-80% 81-100%

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/fas e

Estatus

Presupuesto

Costo

Avance

Observacione s 8

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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
Descripcin del problema

Respuesta
Plan de accin para gestionar el problema (Describir la solucin que se le va a dar al problema)

Responsable/rol
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
Nmero de la revisin correspondie nte (1,2,3 etctera)

Riesgo
Descripci n del riesgo

Probabilidad
Indica probabilidad de ocurrencia(Alt a, media o baja)

Impact o
Indica si el impact o es alto medio o bajo

Prioridad
Indica la urgencia con la que debe tratarse el cambio, se debe

Respues ta
Plan de accin para hacer frente al riesgo

Responsab le
Nombre o rol del encargado de ejecutar el plan de respuesta

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

analizar el impacto que tendr en el proyecto(Al to 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: Porcentaje completado 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 $. 10

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 Id Lder de proyecto Periodo Administracin Escolar EscolaRis AE1 Rubn Hernndez 05/01/2012- 25/04/2012

Acuerdos anteriores

Acuerdo Este es el primer acuerdo del proyecto

Estado 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% debido a que se regres al rea de desarrollo para hacer las correcciones correspondientes de las observaciones hechas por el equipo de calidad.

11

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

# 1

Problemas Requerimientos nuevos que est pidiendo el cliente

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

Responsable/rol Lder de Proyecto

Fecha Compromiso 03-Mayo-2012

12

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

Riesgos

ID 1

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

Probabilidad Impacto Alta Alto

Prioridad Alta

Respuesta Responsable Hacer Lder de pruebas Desarrollo por parte del lder de desarrollo antes de enviar a el equipo de pruebas

Plantilla de reporte administrativo del estatus del proyecto. Un punto a considerarse es que si surgen riesgos y problemas que impacten directamente 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.

13

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 14

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 15

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 Seman a 17 Total

Planeado 38 22,5 31 10 9,5 7 118 Esfuerzo 18,5 42,25 15 10 8 6 99,75 Ejecutad 8 39 13,5 11,5 12 3,5 87,5 o 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 Promedio de evaluacin del rol por ayuda y soporte superior a 4 Resultado Promedio de evaluacin de 4,25. Bueno Regular Promedio de evaluacin exactamente igual a 4.

Promedio de evaluacin del rol contribucin global superior a 4

Informe de logros del equipo de trabajo: objetivos globales de grupo. (Archila, Molano, Kook, Gutirrez y Larrota, 2010).

16

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 Promedio de evaluacin del rol por ayuda y soporte superior a 4 Resultado Promedio de evaluacin de 4,25. Bueno Regular Promedio de evaluacin exactamente igual a 4.

Promedio de evaluacin del rol contribucin global superior 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 Porcentaje de datos personales registrados en las formas resumen Planeacin y Resumen Calidad es 100% Porcentaje de tareas planeadas y completadas 100% Resultado Las estrategias para consolidar el seguimiento personal fueron negociadas con el grupo, y 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. (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. Malo No Aplica

17

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

Objetivo 4 Hacer productos de calidad. Mtrica Promedio de defectos encontrados antes de la primera compilacin: >70% Densidad de los defectos encontrados durante compilacin: <10/KLOC Densidad de los defectos encontrados en pruebas: <5/KLOC Densidad de los defectos encontrados despus de pruebas: 0 Resultado Se encontr el 72% de los defectos esperados antes de la primera compilacin.

Excelente Bueno Regular No aplica Excelente Regular Excelente

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. (Archila, Molano, Kook, Gutirrez y Larrota, 2010). Para el caso de los objetivos especficos de cada rol se observa siguiendo con el mismo ejemplo de rol de Lder de calidad los objetivos propuestos por el equipo de trabajo como se observa en la tabla siguiente. Mtrica Inspecciones y reportes de seguimiento a los procesos. Producto alineado a estndares definidos con un porcentaje de 75% libre de defectos. Resultado Se realizaron las inspecciones adecuadamente. Los reportes de seguimiento no aplican.

Listas de chequeo de artefactos para revisiones e inspecciones.

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.

18

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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.

No aplica

0 defectos hallados despus de la fase de pruebas.

Regular

5 o menos defectos por KLOC hallados en la fase de pruebas.

Bueno

10 o menos defectos por KLOC hallados durante la compilacin.

Bueno

Artefactos alineados a los estndares definidos.

Excelente

Nmero de recomendaciones establecidas en las revisiones.

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

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.

19

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

20

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 Semana No. Fecha Actual

Horas Horas Valor Hora Horas Valor Acumula direct Acumul Planeado s del Acumula gana cin del as adas Ganado Equi das do valor po por ganado sema na 48 48 68 93 43 91 159 252 14,33 30 49,33 48 48 64 48 14,33 96 160 30 23 14,33 44,33 67,33 99,67 100

1 01/04/2009 2 08/04/2009 3 15/04/2009 4 27/04/2009

82,33 109

269 32,33

5 04/05/2009 48 300 300 0,33 100 31 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.

21

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

A continuacin se elabora la siguiente tabla para verificar el cumplimiento de las tareas. Fase Nombre de la Tarea Realizar la carta de constitucin del proyecto con los Lanzamiento Alcance objetivos y alcance del mismo. Lanzamiento Equipo Lanzamiento Roles Conformacin del equipo de trabajo. Asignacin de roles a cada miembro del equipo de trabajo. Parte

Lanzamiento Glosario Elaboracin del glosario de trminos del proyecto. 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.

22

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

Ejemplo de formulario de evaluacin personal y del equipo

Nombre

Adrin Villegas

Equipo

ESG

Lder de Proyecto Semana No.

Dalia Trujillo

Fecha

29/04/2009

Ciclo No.

01

05

Para cada rol, evala el trabajo requerido y la dificultad relativa en % durante este ciclo. Rol Jefe de Equipo Gerente de Desarrollo Gerente de Planeacin Calidad/Gerente de Proceso Gerente de Soporte Total Contribucin (100%) Trabajo Requerido 15 25 25 25 Dificultad del Rol 15 15 30 30

10 100

10 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 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 4 4 4 4 4 4 5 5 5 5 5 5

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

23

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

Lder de Equipo Gerente de Desarrollo Gerente de Planeacin Calidad/Gerente de Proceso Gerente de Proceso

1 1 1 1 1

2 2 2 2 2

3 3 3 3 3

4 4 4 4 4

5 5 5 5 5

Evala cada rol por ayuda y soporte: indique un nmero del 1 (mn.) a 5 (mx.). Jefe de Equipo Gerente de Desarrollo Gerente de Planeacin Calidad/Gerente de Procesos Gerente de Soporte 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3 4 4 4 4 4 5 5 5 5 5

Evala rol respecto a su desempeo: indique un nmero del 1 (mn.) a 5 (mx.). Lder de Proyecto Gerente de Desarrollo Gerente de Planeacin Calidad/Gerente de Procesos Gerente de Soporte 1 1 1 1 1 2 2 2 2 2 3 3 3 3 3 4 4 4 4 4 5 5 5 5 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

24

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 Equipo Grupo Experto de Software ESG (Grupo de Expertos de Software) Fecha Lder Proyecto 12/04/09 de Dalia Trujillo 1

Parte

Nuevos requerimientos del proyecto en la Ciclo etapa de programacin o desarrollo. Evento Numero de control de cambios (revisin) 1 Priorida d Respo nsable Fecha de Seguimi ento

Fecha

Resuelto

09/04/ 09

Control de Cambio s de Requeri mientos

Alta

Guiller mo Toro

15/04/09

Si

25

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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:

26

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

Introduccin tem de configuracin Sigla Categora Artefactos Fases Lanzamiento LZ SCOPE TEAM Planeacin PL MODEL REQU Carta de constitucin del proyecto Asignacin de roles Modelo conceptual 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 FILES Componentes de Software. Archivos Externos (Imgenes, Videos, etc.) Plan de Pruebas Reporte de Pruebas

Testing

TS

PLAN

27

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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 Equipo Adrin Villegas ESG (Grupo de Expertos de Software) Fecha Instructo r Ciclo 31/03/09 Dalia Trujillo

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

03/21/ 09 18:00 22:00 00:30 3:30 Lanzamiento Alcance

03/21/ 09 12:00 03/22/ 09 14:00 0:00 2:00 Lanzamiento Roles y Equipo

Elaboracin del enunciado del problema. Realizar la carta de constitucin del proyecto con los objetivos y alcance del mismo. Conformaci n del equipo de trabajo.

28

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

14:00

18:00

1:00

3:00

Lanzamiento

Roles y Equipo

03/22/ 09 19:00: 00 21:00: 00 00:00 2:00 Requerimient os Requeri mientos

03/22/ 09 00:00 2:00 Requerimient os Requeri mientos

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 Revisin de las correccione s a realizar sobre el proyecto. Definicin del plan de trabajo.

03/30/ 09

21:00: 00

23:00: 00 00:00 1:00 Requerimient os Requeri mientos

3/30/0 9

00:00: 00

01:00: 00 21:00 00:00 2:00 Planeacin de trabajo Planeaci n

02/04/ 19:00 09

29

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

04/04/ 08:00 09

22:00

01:00

13:00

Lanzamiento Estrategia Requerimient os

Artefacto s

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. Correccione s sobre todos los artefactos de dichas fases y elaboracin de nuevos artefactos. Revisin de tareas pendientes segn cronograma de tareas de diseo Revisin de los flujos del caso de uso para inspecciona r y visionar la manera de implementar lo

18/04/ 09:00 09

23:00

01:00

13:00

Diseo

Revisin

17/04/ 21:00 09

23:00

00:30

1:30

Construccin

Revisin de caso de uso

30

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

21/04/ 21:00 09

01:00

00:30

02:30

Construccin

Desarroll o de caso de uso

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 Desarrollo de funcionalida d de generar reporte de recaudo diario con sus respectivas pruebas unitarias 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

31

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

27/04/ 20:00 09

Evaluacin de los diferentes roles de TSP en el proyecto 28/04/ 20:00 23:00 0:30 2:30 Postmortem Evaluaci Evaluacin 09 n 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).

23:00

0:30

2:30

Postmortem

Evaluaci n

32

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

Horas acumuladas Tamao de Unidades

Actual

Toral de horas de equipo

Gerente de planeacin

Gerente de desarrollo

Gerente de Calidad/ producto Gerente de soporte

Nombre de la Tarea

Valor Planeado Acumulados Horas Horas acumuladas 1 2 2 8 1 1

N de Ingenieros

Lder de Equipo

Tamao No. Semana

Realizar la carta de constitucin del Lanzamiento Alcance proyecto con los objetivos y alcance del mismo. Lanzamiento Equipo Conformacin del equipo de trabajo. Asignacin de roles a cada miembro del equipo de trabajo.

6 6 Hojas

8 1,2,3

4 2 1

1 2 1

1 2

5 11 Hojas 4 15 Hojas

4 2

1, 3, 5 13 1,2,3 67 67 1, 5 4 17 1,2,3 33

Lanzamiento Roles

Lanzamiento Glosario Elaboracin del

5 20 Hojas 10

1 1, 6, 3 20 1,2,3 33

Semana

Parte

Fase

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

glosario de trminos del proyecto. Lanzamiento Lanzamiento Estrategi Definir el Ciclo de vida a de desarrollo. Estrategi Elaborar el diseo a conceptual.

67 67 2 1 4 3 3 7 27 Hojas 3 30 Hojas 3 2 1 2, 9 4 24 1,2,3 33

1 1 10 2 26 1,2,3

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.

34

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

5. Finalmente se genera un horario para reporte de cronograma donde se compara lo planeado con los resultados obtenidos: Ejemplo de reporte de cronograma.

Nombre: Equipo: Nivel: Plan

Semana Fecha

Fecha: Instructor: Ciclo: Actual

No.

Horas Horas Acumulaci Horas Horas Semana Acumulaci Directa Acumulada n de Valor del Acumula Valor n de Valor s s Planeado Equipo das Agregad Ganado o

1 01/04/2009 2 08/04/2009 3 15/04/2009 4 27/04/2009 5 04/05/2009

48 48 68 93 48

43 91 159 252 300

14,33 30 49,33 82,33 100

48 48 64 109 31

48 96 160 269 300

14,33 30 23 32,33 0,33

14,33 44,33 67,33 99,67 100

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

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.

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

35

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

36

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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.

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

37

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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.

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

38

Desarrollo de Software en Equipo TSP

Unidad 3. Gestin en TSP

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%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. S. (1999). Introduction to the Team SoftwareProcess. Massachusetts: Addison Wesley Professional. Humphrey, W. S. (2006). TSP(SM)Coaching Development Teams. AddisonWesley Professional.

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

39