Unidad 3 Gestion en TSP

Desarrollo de Software en Equipo TSP Unidad 3. Gestión en TSP

Programa de la asignatura: Desarrollo de Software en Equipo TSP 8º Cuatrimestre

Unidad 3. Gestión en TSP

Clave: 150930934

Universidad Abierta y a Distancia de México UnADM

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

0


Índice Unidad 3. Gestión en TSP ................................................................................................. 2 Presentación de la unidad ................................................................................................. 2 Propósitos Propósitos................................. .................................................. .................................. ................................. .................................. .................................. ..................... ..... 2 Competencia específica ..................................................................................................... 2 3.1. Monitoreo y control del proyecto ................................................................................. 3 3.1.1. Ejecutar la revisión revisión de la administración administración del proyecto .................. ......... ................... ................... .................. ......... 3 Actividad 1. Evidencia Evidencia de administración administración de trabajo trabajo y calidad calidad del proyecto. ...................... .................. .... 6 3.1.2. Elaborar el reporte administrativo del estatus del proyecto ...................................... 6 Actividad 2. Reporte Reporte del seguimiento seguimiento del proyecto proyecto.................. ......... .................. .................. ................... ................... ............. .... 14 3.2. Análisis postmortem .................................................................................................. 14 3.2.1. Diagnóstico: Diagnóstico: métricas de calidad versus versus trabajo realizado realizado ...................... ............. ................... ............... ..... 15 3.2.2. Elaborar el análisis del desempeño del equipo ...................................................... 20 Autoevaluación Autoevaluación ................... .......... .................. .................. ................... ................... .................. ................... ................... .................. .................. .................. ......... 36 Evidencia de aprendizaje. Generación del reporte de calidad del proyecto .................. ......... ............. .... 36 Autorreflexiones Autorreflexiones ................... .......... .................. .................. ................... ................... .................. ................... ................... .................. .................. .................. ......... 36 Cierre de la unidad .......................................................................................................... 37 Para saber saber más ................................ ................................................. .................................. .................................. .................................. ............................ ........... 38 Fuentes de consulta ........................................................................................................ 38


Índice Unidad 3. Gestión en TSP ................................................................................................. 2 Presentación de la unidad ................................................................................................. 2 Propósitos Propósitos................................. .................................................. .................................. ................................. .................................. .................................. ..................... ..... 2 Competencia específica ..................................................................................................... 2 3.1. Monitoreo y control del proyecto ................................................................................. 3 3.1.1. Ejecutar la revisión revisión de la administración administración del proyecto .................. ......... ................... ................... .................. ......... 3 Actividad 1. Evidencia Evidencia de administración administración de trabajo trabajo y calidad calidad del proyecto. ...................... .................. .... 6 3.1.2. Elaborar el reporte administrativo del estatus del proyecto ...................................... 6 Actividad 2. Reporte Reporte del seguimiento seguimiento del proyecto proyecto.................. ......... .................. .................. ................... ................... ............. .... 14 3.2. Análisis postmortem .................................................................................................. 14 3.2.1. Diagnóstico: Diagnóstico: métricas de calidad versus versus trabajo realizado realizado ...................... ............. ................... ............... ..... 15 3.2.2. Elaborar el análisis del desempeño del equipo ...................................................... 20 Autoevaluación Autoevaluación ................... .......... .................. .................. ................... ................... .................. ................... ................... .................. .................. .................. ......... 36 Evidencia de aprendizaje. Generación del reporte de calidad del proyecto .................. ......... ............. .... 36 Autorreflexiones Autorreflexiones ................... .......... .................. .................. ................... ................... .................. ................... ................... .................. .................. .................. ......... 36 Cierre de la unidad .......................................................................................................... 37 Para saber saber más ................................ ................................................. .................................. .................................. .................................. ............................ ........... 38 Fuentes de consulta ........................................................................................................ 38


Unidad 3. Gestión en TSP Presentación de la unidad Te damos la más cordial bienvenida a la Unidad 3 Gestión en TSP , en la cual se abordarán conceptos relacionados con la administración de un proyecto de desarrollo de software utilizando la metodología TSP. En la unidad 1 aprendiste conceptos básicos sobre la metodología TSP, ciclo de vida de un proyecto de desarrollo de software y las fases de esta metodología. En la unidad 2 aprendiste a llevar a cabo la fase de lanzamiento del proyecto según la metodología TSP y a ejecutar la fase de implementación implementación mediante el plan de riesgos, plan de calidad y plan de proyecto. En esta unidad aprenderás a realizar las plantillas correspondientes a la fase postmortem, así como el monitoreo y control del proyecto necesarios para que la parte administrativa del proyecto lo revise y así sea posible contar con una medida exacta del avance que se tiene t iene del mismo. También aprenderás a implementar la fase postmortem la cual tiene dos componentes que son: diagnóstico de métricas de calidad versus trabajo realizado y la elaboración del análisis del desempeño del equipo. Esto será una parte muy importante en el proyecto de desarrollo de software que se esté desarrollando, porque se podrá contar con una retroalimentación retroalimentación de los errores y de las cosas que se hicieron bien en el proyecto y poder considerarlo para futuros proyectos.

Propósitos Al finalizar el estudio estudio de esta unidad unidad podrás: 





Determinar la función de gestión a partir de la metodología Team Software Process (TSP), para que evalúen el avance que va teniendo el desarrollo del proyecto. Identificar el estatus estatus del proyecto a partir de de un reporte para para saber saber el estado actual en que se encuentre el proyecto. Analizar los problemas de calidad del equipo de trabajo que estén a cargo del desarrollo del proyecto, mediante reportes.

Competencia específica Aplicar la mecánica mecánica de gestión de de la metodología metodología Team Software Process (TSP) para tomar decisiones gerenciales gerenciales del proyecto a partir de los reportes.


3.1. Monitoreo y control del proyecto El monitoreo y control del proyecto es un conjunto de actividades de gestión que permiten verificar si el proyecto va marchando según lo planificado (Humphrey, (Humphrey, 1999). Para lograr la calidad deseada en todos los proyectos de desarrollo de software, es necesario supervisar el que las actividades y tareas relacionadas al proyecto se realicen en forma adecuada, así como el seguimiento del presupuesto que se asignó para la elaboración del proyecto y recursos humanos involucrados en el proyecto. Para la supervisión y seguimiento del proyecto, es necesario realizar acciones de monitoreo y control del proyecto utilizando la metodología TSP, esto reviste esencial importancia porque permite medir de una manera correcta la situación del proyecto, se puede decir que el monitoreo y control son acciones necesarias para que se cumplan los objetivos trazados al inicio del mismo de una manera exitosa. En los siguientes capítulos aprenderás a realizar las plantillas que TSP proporciona como una mecánica para la gestión del proyecto, con el fin de que comprendas cómo influyen estos reportes en la toma t oma de las decisiones gerenciales del proyecto implementando esta metodología. metodología.

3.1.1. Ejecutar la revisión de la administración del proyecto En la Unidad 2 Implementación de TSP aprendiste aprendiste cómo realizar el plan de calidad, el plan de riesgos y el plan de proyecto. Cuando se ejecuta el plan de calidad se hacen las revisiones de código correspondientes al diseño y el desarrollo del proyecto. En este capítulo aprenderás a realizar la revisión pero de todo lo ya realizado incluyendo desarrollo y pruebas del sistema. La revisión de la administración es importante antes de arrancar la fase postmortem en un proyecto que está ocupando la metodología TSP. Recuerda que un proyecto de acuerdo a su tamaño se puede dividir en módulos; para que se entienda mejor se expone el siguiente ejemplo. Se está desarrollando un software para llevar el control de una empresa que se dedica a la venta y fabricación de textiles, al momento de levantar los requerimientos con el cliente por parte del administrador administrador de proyectos, se encontró que el sistema será muy amplio, ya que tendrá que dar de alta los materiales para hacer los textiles y aparte se tendrá que desarrollar la parte del software donde realizarán las ventas de los productos. Aquí el software se dividirá en dos módulos, uno que se encargará de la parte de la fabricación de los productos y el otro se encargará de llevar acabo las ventas de los productos, al momento de realizar las pruebas del sistema se encontró que el módulo de ventas ya fue revisado y no se encontraron errores fue liberado


correctamente. El segundo módulo se revisó por parte del equipo de calidad pero se encontró que más de la mitad del módulo tiene aún errores. Siguiendo el ejemplo anterior el equipo de desarrollo y diseño primero entregará el módulo correspondiente a la parte que se va a dedicar a la fabricación de los productos y después se entregará el módulo que se refiere a la venta de los mismos. El equipo de calidad y los administradores del proyecto evaluarán, revisarán y aprobarán cada módulo, como se vaya terminando de revisar, si el sistema tiene aún errores se regresarán a el equipo de desarrollo, para que realicen las modificaciones correspondientes. Para hacer este seguimiento de la administración del proyecto, TSP proporciona una plantilla para hacer la revisión de la situación del proyecto de acuerdo a las pruebas realizadas llamada “Plantilla de revisión de la administración d el proyecto” y que se observa a continuación.

Nombre del módulo

Nombre del encargado de la revisión

Nombre del rol

Porcentaje completado

Observacione s

Ventas Fabricación de productos

Plantilla de revisión de la administración del proyecto. (Humphrey, 2006). Recuerda que esta plantilla puede ir en un documento de Word con un control de cambios tal como se menciona en la unidad 2 en el tema 2.1.1 Documentar propósitos, objetivos y roles del equipo. A continuación se explicará qué es lo que se tiene que integrar en cada columna de la plantilla “Plantilla de revisión de la administración del proyecto.”:

Nombre del módulo: En esta columna se integrará el nombre del módulo continuando con el ejemplo anterior se mencionan dos módulos, uno lleva por nombre ventas y el otro se llamará fabricación de productos, estos nombres se definen al inicio del proyecto. Si el proyecto se integrara de más de dos módulos, se deberán insertar las filas que sean necesarias dependiendo del número de módulos. Nombre del encargado de la revisión: Aquí se integrará el nombre de la persona que llevó a cabo las pruebas del módulo correspondiente.


Nombre del rol: En esta columna se escribirá el rol del encargado de las pruebas del módulo, este rol se obtiene de acuerdo al rol que se le haya asignado según la metodología TSP y el equipo en el que se encuentre. Porcentaje completado: El porcentaje completado del módulo correspondiente, se integra en una columna identificada con colores dependiendo del porcentaje concluido del módulo correspondiente, a continuación explicaré detalladamente: Porcentaje completado 0 a 40% 41 a 80% 81 a 100% Observaciones: En esta columna el encargado de hacer la plantilla que será el administrador de calidad, integrará sus observaciones en cuanto a la revisión del módulo. Retomando el ejemplo anterior, se expone el llenado de una plantilla de revisión de la administración del proyecto.

Nombre del módulo Ventas

Fabricación de productos

Nombre del encargado de la revisión Juan Pérez

Juan Pérez

Nombre del rol

Porcentaje completado

Observaciones

Administrador de calidad

100%

Administrador de calidad

40%

Esto módulo fue revisado y aprobado para su liberación por parte del equipo de calidad En este módulo se encontraron aún muchos errores por lo que se regresaron al equipo de desarrollo para que realicen las modificaciones correspondiente s

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


En conclusión, se puede decir que esta plantilla es importante, por que proporciona una clara idea del estado del proyecto una vez que ya se han ejecutado las pruebas del software. Al contar con esta plantilla se tiene una medida bien definida del estado del proyecto. El monitoreo y control se divide en dos partes, la revisión de la administración del proyecto y el reporte administrativo del estatus del proyecto el cual se abordará en el siguiente capítulo antes de pasar a la fase postmortem de TSP.

Actividad 1. Evidencia de administración de trabajo y calidad del proyecto. Esta actividad tiene como propósito que integres los elementos de la Plantilla de revisión de la administración del proyecto e identifiques su relación con elementos de calidad del proyecto mediante el planteamiento de un problema correspondiente a un proyecto de software que te hará llegar tu Facilitador(a), una vez que cuentes con él: 1. Identifica los elementos de la plantilla de revisión de la administración del proyecto: nombre del módulo, nombre del encargado de la revisión, nombre del rol, porcentaje completado, observaciones. 2. Genera la Plantilla de revisión de la administración del proyecto. 3. Redacta tus conclusiones acerca de los elementos que integran esta plantilla y por qué son importantes para la revisión de la administración del proyecto. 4. Guarda la actividad con el nombre DDSE_U3_A1_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. 5. Envía tu actividad al facilitador mediante la herramienta Tareas. *No olvides consultar el documento Criterios de evaluación para las actividades de la unidad 3 donde podrás conocer los parámetros de evaluación de esta actividad.


3.1.2. Elaborar el reporte administrativo del e s t a t u s del proyecto En este capítulo se abordará lo correspondiente al reporte administrativo del estatus del proyecto, este reporte es esencial para poder conocer el estado actual del proyecto en general y si los tiempos y costos del proyecto no han rebasado lo planeado. Un reporte de estatus del proyecto es un documento que informa el estado actual de un proyecto. Su principal propósito es comunicar al receptor si el proyecto se va desarrollando según lo planeado y por qué, o si no se va desarrollando según lo planeado, también el por qué (Esterkin, 2008). Los elementos que conforman este reporte son los siguientes: 









Estatus general del proyecto: muestra el estado del proyecto al momento de hacer la plantilla. Estatus del proyecto a nivel entregable: Recuerda que un proyecto como se mencionó en el capítulo anterior puede dividirse en módulos los cuales se entregaran no todos juntos sino uno por uno, a eso se refiere este punto. Actividades relevantes del periodo: Se describen actividades que tengan importancia durante el periodo en que se realiza la plantilla Riesgos : se describen los riesgos que surgieron durante el periodo de inicio del proyecto hasta que se elabora la plantilla Problemas: se describen problemas referentes al software realizado durante el periodo de inicio del proyecto hasta que se elabora la plantilla.

Como se mencionó, en este reporte quedará plasmada la situación actual del proyecto, el propósito de este reporte es comunicar si el proyecto se va desarrollando de acuerdo a lo planeado al inicio del mismo y en caso de que no sea así poder saber por qué no se está cumpliendo con los objetivos. Es importante remarcar que este reporte no se utiliza para registrar el trabajo que realizó el equipo del proyecto, para esto TSP proporciona los planes vistos en la Unidad 2. Implementación de TSP , su función principal es dar cuenta de los desvíos del plan realizado al inicio del proyecto y así poder buscar y plantear una solución adecuada. En este reporte TSP indica que debe contener un resumen que mencione si el proyecto se está desarrollando según lo planeado, si se cumplen con las fechas estimadas de entregas, si surgieron riesgos nuevos o aumentó la probabilidad o el impacto de riesgos conocidos elaborados en el plan de riesgos. También debe contener una breve descripción de aquellas cosas del proyecto que no se desarrollan según lo planeado y las medidas o acciones que se tomaron para corregir este problema, el porcentaje de avance en los entregables los cuales se mencionan en la Unidad 1 Introducción a TSP y el costo actual del proyecto. La plantilla para elaborar este reporte que TSP brinda tiene por nombre: “Plantilla de Reporte administrativo del estatus del proyecto” y es la siguiente:


Proyecto Id

Nombre del proyecto Código del identificador (Este código depende totalmente de la empresa que esté desarrollando el software, se refiere al código que se asignó al proyecto). Nombre del líder dd/mm/aa – dd/mm/aa(periodo del inicio del proyecto hasta la fecha en que se realiza la plantilla).

Líder de proyecto Periodo

Acuerdos anteriores Acuerdo

Estado

Fecha Compromis o

Responsable/R ol

Observacione s

Descripción del acuerdo(descripción del número de acuerdo al momento de realizar la plantilla)

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

Fecha límite en la que debe cumplirse el acuerdo

Nombre o rol del encargado de cumplir el acuerdo

Comentarios relacionados al acuerdo este comentarios los

Estatus General del proyecto Avance Avance planeado Avance real Desviación

% % % % de avance planeado menos avance real

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

Situación general del proyecto Descripción de las razones que originan el estatus del proyecto (se refiere a los motivos por los cuales hay un desvío entre lo planeado y el avance real, o si el proyecto avanza conforme a lo planeado)

Estatus del proyecto a nivel entregable/fase Entregable/fas e

Estatus

Presupuesto

Costo

Avance

Observacione s


Nombre del entregable o fase

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

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

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

Porcentaje del avance del entregable o fase

Observaciones relacionados al entregable o fase

Actividades Relevantes del periodo #

Actividad Descripción breve de la actividad realizada en el periodo

Problemas #

Problemas Descripción del problema

Respuesta

Responsable/rol

Fecha Compromiso

Plan de acción para gestionar el problema (Describir la solución que se le va a dar al problema)

Nombre o rol del encargado de gestionar el plan de respuesta.

Fecha límite para solucionar el problema (proponer una fecha para darle solución al problema)

Riesgos ID

Riesgo

Número de la revisión correspondie nte (1,2,3 etcétera)

Descripci ón del riesgo

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

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

Responsab le

Plan de acción para hacer frente al riesgo

Nombre o rol del encargado de ejecutar el plan de respuesta


analizar el impacto que tendrá en el proyecto(Al to medio, bajo) (Se integran tantas filas como se requiera de acuerdo con el número de revisiones)

Plantilla de Reporte administrativo del estatus del proyecto (Siles, 2012). Como punto principal esta plantilla la realizará el administrador de proyectos, por lo tanto él realizará las observaciones correspondientes que se pidan en la plantilla, más adelante, mediante un ejemplo se especificará concretamente. Otro punto a remarcar es que todos los estatus se considerarán de acuerdo al avance del proyecto y se les asignará un color, a continuación se muestra el color de acuerdo al avance del proyecto: Porcentaje completado 0 a 40% 41 a 80% 81 a 100%

A continuación se expone un ejemplo mediante el cual se ilustrará la forma de llenar la plantilla anterior: Se está realizando un proyecto de software que está dirigida al apoyo de servicios escolares y administración escolar de una institución educativa el proyecto tienen por nombre “Sistema de administración Escolar EscolaRis ”, se requiere que el sistema permita:  





A los profesores el poder capturar las calificaciones de los alumnos. Al área de servicios escolares, poder contar con los datos completos de los alumnos y el historial académico así como realizar: altas, bajas, registro de exámenes extraordinarios, etcétera. Al área de administración escolar contar un registro de los alumnos que están inscritos en la escuela y también de egresados. A los padres de los alumnos contar con un módulo vía web, que les permita conocer sus calificaciones así como las observaciones realizadas por los profesores sobre el estatus académico de cada uno de sus alumnos.

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


El sistema ya pasó la primera revisión de pruebas, en las juntas que se tuvieron en la fase de lanzamiento del proyecto se acordó que para esta revisión el avance tenía que ser de 40% del total del proyecto al realizar esta tarea se encontraron errores de codificación y diseño por lo cual solo se logró el 35% de avance, el costo actual del proyecto es de$ 200,000. Algo que preocupa a la empresa que desarrolla este software es que el cliente está solicitando más requerimientos de los que se plantearon al inicio del proyecto y es difícil implementarlos ya cuando se concluyó la fase de pruebas del desarrollo del proyecto. Cabe señalar que el proyecto se encuentra en la fase de integración y pruebas del sistema de acuerdo al ciclo de vida de desarrollo de software. Con los datos proporcionados anteriormente se procede al llenado de la plantilla de reporte administrativo del estatus del proyecto que se presenta a continuación. Proyecto Id Líder de proyecto Periodo

Administración Escolar EscolaRis AE1 Rubén Hernández 05/01/2012- 25/04/2012 Acuerdos anteriores

Acuerdo

Estado

Fecha Responsable/Rol Observaciones Compromiso 22-Abril Administrador de El acuerdo se encuentra 2012 proyectos abierto ya que es la primera revisión

Este es el Abierto primer acuerdo del proyecto

Estatus General del proyecto Avance Avance planeado Avance real Desviación

% 40 35 5

Estatus 35%

Situación general del proyecto El proyecto está bien pero tiene una desviación de 5% debido a que se regresó al área de desarrollo para hacer las correcciones correspondientes de las observaciones hechas por el equipo de calidad.


Estatus del proyecto a nivel entregable/fase Entregable/fase Entregable 1

Estatus 35%

Presupuesto Costo $800,000 $200,000

Avance Observaciones 35% El proyecto se encuentra bien en relación presupuesto/costo aunque tenga una desviación del 5%

Actividades Relevantes del periodo # 1 2

Actividad Se realizaron los módulos correspondientes a los catálogos de maestros y alumnos Se realizaron la parte de la calificación de alumnos por parte de los profesores y se tuvo un adelanto en el módulo de inscripciones aun no revisado por el equipo de calidad

Problemas # 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 Líder de Proyecto

Fecha Compromiso 03-Mayo-2012


Riesgos ID 1

Riesgo Nuevos errores una vez que se realice la 2da revisión del proyecto

Probabilidad Impacto Alta Alto

Prioridad Alta

Respuesta Responsable Hacer Líder de pruebas Desarrollo por parte del líder 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 algún integrante del equipo o cuestiones que pongan en riesgo los objetivos que se planearon al inicio del desarrollo del software, estas decisiones sobre la forma de solucionarlas, las tomará la alta gerencia. En este capítulo se observó la forma de realizar la plantilla de reporte administrativo del estatus del proyecto esta plantilla ofrece un amplio panorama sobre el avance real de todo el desarrollo del proyecto. En el siguiente capítulo se abordará el tema correspondiente a la elaboración de las plantillas en la fase postmortem.


Actividad 2. Reporte del seguimiento del proyecto En esta actividad generarás el reporte de seguimiento de un proyecto para saber el estatus de avance que se tiene sobre el mismo, para ello, tu Facilitador te hará llegar un planteamiento de problema, una vez que cuentes con el planteamiento: 1. Identifica en el problema planteado los elementos necesarios para realizar el reporte administrativo del estatus del proyecto.

2. Elabora la “Plantilla de Reporte administrativo del

estatus del proyecto. ”

3. Redacta tus conclusiones acerca de por qué es importante el reporte administrativo del estatus del proyecto en relación con el problema planteado. 4. Guarda la actividad con el nombre DDSE_U3_A2_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. 5. Envía tu actividad al facilitador mediante la herramienta base de datos. 6. Comenta la actividad de por lo menos dos de tus compañeros e identifica semejanzas y diferencias respecto a tus propias conclusiones. *No olvides consultar el documento Criterios de evaluación para las actividades de la unidad 3, donde podrás conocer los parámetros de evaluación de esta actividad.

3.2. Análisis p o s t m o r t e m En esta unidad se explicarán las actividades que se llevan a cabo en el último proceso del TSP que es la fase postmortem, el cual es un medio de aprendizaje estructurado para el equipo de desarrollo, ya que proporciona información sobre la eficacia del líder de proyecto y cada uno de los miembros del equipo así como el rendimiento de cada uno de ellos (Humphrey, 2006). Dentro del proceso de postmortem también aprenderás a realizar un diagnóstico sobre las métricas de calidad aplicadas al trabajo realizado durante el desarrollo del software. El postmortem sirve de retroalimentación para todos los integrantes del equipo, porque se estudia la manera en que se trabajó durante el desarrollo del proyecto, analizando


la forma de realizar las actividades y detectando en qué se falló y en qué se obtuvieron resultados positivos, todo esto con la finalidad de que los equipos y líderes de proyecto puedan ser más eficaces y puedan considerar los errores y las acciones positivas para estar preparados para mejorar en los siguientes proyectos. (Humphrey, 2006) Cuando se llega al final de cada ciclo de un proyecto se entra a la fase postmorten donde los equipos de TSP cuentan con una gran cantidad de información, la cual contiene, entre otros, los siguientes elementos:  

La calidad de sus productos Estimaciones.

Información debe estar debidamente recolectada y organizada, de no ser así se presentarán problemas para poder reconstruir el trabajo realizado. Es por eso que TSP propone realizar el postmortem en la culminación de cada proyecto, aprovechando que la información recabada y la experiencia del trabajo realizado por el equipo de proyecto son frescas, de esta manera se tendrá una idea más clara de cómo trabajar para los futuros proyectos. De igual manera la elaboración del diagnóstico de métricas de calidad contra el trabajo realizado que también se reelabora en el proceso de postmortem tiene el mismo propósito, evaluar los resultados obtenidos verificando y verificando el nivel de cumplimiento de lo planeado que en este caso se refiere a las métricas de calidad establecidas por el equipo de proyecto.

3.2.1. Diagnóstico: métricas de calidad v e r s u s trabajo realizado En este capítulo aprenderás a realizar el diagnóstico de las métricas de calidad que se realizaron en el plan de calidad el cual se vio en la unidad 2 y comparar con el trabajo que se realiza para poder evaluar los resultados obtenidos, es muy importante que se tome en cuenta que se debe tener bien comprendido el plan de calidad para poder realizar este proceso final postmortem. Para poder realizar el diagnóstico de las métricas de calidad contra el trabajo que se realizó se debe hacer uso del plan de calidad, el cual contiene la información sobre la inyección de defectos en el diseño y codificación. También es importante reunirse con cada uno de los miembros del equipo y revisar en conjunto los procesos que llevan a cabo y analizar en qué están fallando o la manera en que pueden mejorar, así como darles la oportunidad de expresar sus inconformidades e inquietudes (Humphrey, 2006). El encargado de las métricas de calidad es el gerente de calidad. Se debe hacer un reporte de realización de los objetivos con base en lo planeado y el resultado que se obtuvo. Recordemos que una métrica es un valor cuantificable que puede ser medible. A continuación se muestra un ejemplo sobre el análisis del trabajo realizado por parte del gerente de calidad en un proyecto y los resultados conseguidos. En este ejemplo


se mostrará el trabajo que realizo el Gerente de Calidad mediante un informe postmortem para el proyecto que lleva por nombre “ Apertura de crédito del Banco de Los Alpes” en dicho ejemplo se observa el registro del cumplimiento de las actividades planeadas por semana, para que finalmente sea posible evaluar el cumplimiento de los objetivos planeados (Archila, Molano, Kook, Gutiérrez y Larrota, 2010). Acciones

Semana 12

Semana 13

Semana 14

Semana 15

Semana 16

Seman a 17

Total

22,5 31 10 9,5 7 118 Planeado 38 Esfuerzo 18,5 42,25 15 10 8 6 99,75 39 13,5 11,5 12 3,5 87,5 Ejecutad 8 o Cumplimiento de compromisos del Líder de calidad. (Archila, Molano, Kook, Gutiérrez y Larrota, 2010). En esta tabla se muestra la distribución de las horas planeadas por semana para la realización de las activadas que tiene a su cargo el rol de líder de calidad el cual fue planeado por parte del equipo de proyecto y el esfuerzo que se refiere a la suma de tiempos dedicados a esa actividad y por último se muestra lo ejecutado que ver el cumplimiento real de lo que se plano. A continuación se describe el objetivo propuesto por el equipo y se revisa en la siguiente tabla la distribución de las métricas planeadas y el resultado obtenido, la métrica es el valor que se le está dando a la actividad para que pueda ser medido, por ejemplo, encontramos en la tabla de objetivos globales de grupo la métrica “Promedios de evaluación del rol por ayudar y soporte superior a 4”. El 4 es una medida que se le asigna a cada miembro del equipo para saber si el cumplimiento es malo, regular, bueno, excelente o si no es aplicable para su evaluación. Objetivo 1 Ser un miembro efectivo y cooperativo.

Métrica Promedio de evaluación del rol por ayuda y soporte superior a 4

Resultado Promedio de evaluación de 4,25. o n e u B

Promedio de evaluación del rol contribución global superior a 4 al

r

Promedio de evaluación exactamente igual a 4. u g e R

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


En la siguiente tabla se observa el objetivo planeado por el líder de calidad en cuanto a la efectividad y cooperación. Objetivo 2 Hacer el trabajo personal de manera disciplinada consistentemente.

Métrica Promedio de evaluación del rol por ayuda y soporte superior a 4

Resultado Promedio de evaluación de 4,25. o n e u B

Promedio de evaluación del rol contribución global superior a 4 al

r

Promedio de evaluación exactamente igual a 4. u g e R

Objetivo global líder de calidad: efectividad y cooperación. (Archila, Molano, Kook, Gutiérrez y Larrota, 2010).

Se observa en la siguiente tabla que la métrica cambia a un valor en porcentaje para establecer el cumplimiento del objetivo, que está en una escala de %0 a 100% (Ver la siguiente tabla Objetivo global líder de calidad-Disciplina ). Objetivo 3 Planear y hacer seguimiento al trabajo personal.

Métrica Porcentaje de datos personales registrados en las formas

Resultado Las estrategias para consolidar el a ci seguimiento personal fueron negociadas l p “resumen Planeación” y “Resumen con el grupo, y las formas a las que se hace A o Calidad” es 100% referencia fueron descartadas. N Porcentaje de tareas planeadas y El líder de planeación realizó sólo el 57% completadas 100% de las actividades planeadas durante el ol a ciclo. M Objetivo global líder de calidad: disciplina. (Archila, Molano, Kook, Gutiérrez y Larrota, 2010). De la misma manera que los demás objetivos propuestos por el equipo de proyecto se revisa el cumplimiento de lo planeado así como su resultado obtenido como se observa en la siguiente tabla.


Objetivo 4 Hacer productos de calidad.

Métrica Promedio de defectos encontrados antes de la primera compilación: >70% o

Resultado Se encontró el 72% de los defectos esperados antes de la primera compilación. n e u B

Densidad de los defectos encontrados durante compilación: <10/KLOC

Menos de 3 defectos por KLOC. et n le e c x E

Densidad de los defectos encontrados en pruebas: <5/KLOC r

Las pruebas locales funcionaron correctamente. Sin embargo, al tratar de exponer como un servicio, el componente no funcionó adecuadamente. al u g e R

Densidad de los defectos encontrados después de pruebas: 0

La medida no ha podido ser verificada, puesto que aún la herramienta no ha superado la etapa de pruebas. a ci l p a o N

Medición de la calidad del producto. (Archila, Molano, Kook, G utiérrez y Larrota, 2010). Para el caso de los objetivos específicos de cada rol se observa siguiendo con el mismo ejemplo de rol de Líder de calidad los objetivos propuestos por el equipo de trabajo como se observa en la tabla siguiente.

Métrica Inspecciones y reportes de seguimiento a los procesos. el

n

et

Resultado Se realizaron las inspecciones adecuadamente. Los reportes de seguimiento no aplican. e c

Producto alineado a estándares definidos con un porcentaje de 75% libre de defectos.

E

x

e

el

n

et c x E

Listas de chequeo de artefactos para revisiones e inspecciones. R

e

g

u

al

r

El producto se encuentra alineado a los estándares definidos, sin embargo, aunque se puede decir que para lo que corresponde a programación el porcentaje libre de defectos esperado es del 93%, no es posible hacer una medición de lo que corresponde a configuración. 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.


Número de recomendaciones establecidas en las revisiones. x

c

e

el

n

et

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 estándares en un 80%. La falta de seguimiento de las plantillas evitó que se cumplieran algunos de los estándares predefinidos. Se encontraron en promedio 7,2 defectos por KLOC durante la compilación.

Artefactos alineados a los estándares definidos.

E

n

o e u B

10 o menos defectos por KLOC hallados durante la compilación. o n e

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

B

u

0 defectos hallados después de la fase de pruebas.

R

e

g

u

al

r

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 aún la herramienta no ha superado la etapa de pruebas. o

a

p

l

ci

a

N

Objetivos específicos de rol. (Archila, Molano, Kook, Gutiérrez y Larrota, 2010). En ejemplo anterior se muestra las métricas de calidad establecidas por el equipo de trabajo a las cuales se le asigna un resultado que de igual manera se analiza de manera conjunta por el líder de proyecto y los integrantes del equipo donde se va verificando con el objetivo propuesto por el responsable de llevar el rol que en este caso es el líder de calidad al final se debe hacer una conclusión o diagnóstico de los resultados obtenidos, en estos resultados se determina si se cumplió o no con los objetivos propuestos o de qué manera pueden mejorar. La revisión de resultados se debe realizar con cada uno de los integrantes del equipo, comparar y revisar los datos planeados, para que finalmente se evalúe la calidad del producto obtenido. Cuando se concluya con el diagnóstico para cada uno de los integrantes del equipo se debe realizar una serie de recomendaciones y observaciones que puedan ser de ayuda para poder mejorar sus procesos para los siguientes proyectos. En conclusión, si no se realiza un diagnóstico de las métricas de calidad con el trabajo realizado al final de cada proyecto en la fase de postmortem, no se podrán detectar las áreas de oportunidad y mejora, por ello es necesario analizar lo que se planeó al inicio del proyecto y verificar el cumplimiento de los objetivos.


3.2.2. Elaborar el análisis del desempeño del equipo En este tema se abordarán los temas correspondientes a la realización del análisis de desempeño del equipo el cual consiste en un estudio y evaluación del desempeño conseguido por el equipo y del resultado obtenido durante el desarrollo del software, esto se realiza en el paso final del proceso de TSP postmortem. Dentro de la fase de postmortem se debe analizar el desempeño de los objetivos del equipo, esto debe realizarse con base en la calidad, costos y el tiempo que se utilizó para el cumplimiento de los objetivos planteados por el equipo (Humphrey, 1999). TSP recomienda que antes de comenzar con la recolección de información se debe de tomar en cuenta de qué forma van a ser utilizados los datos recolectados, es por eso que se debe generar un plan de recolección de información ya que de no hacerlo se puede llegar a perder tiempo en el procesos de recolección de información. El gestor de configuración es el encargado de preparar con anticipación la forma en que se va a recolectar la información pidiendo a los miembros del equipo la mejor manera en que ellos puedan recolectar la información de tal manera que esta información pueda ser presentada durante las reuniones que se lleguen a realizar para llevar a cabo el postmortem en la culminación del proyecto. Cada uno de los integrantes del equipo de proyecto debe tener una adecuada actitud durante la fase del postmortem. En la fase de postmortem se tiene que iniciar con las reuniones con los integrantes del equipo, en el cual se realizan las siguientes actividades (Humphrey, 2006):

Descripción general: Se debe realizar un resumen de los resultados obtenidos en cada paso del proceso de desarrollo del proyecto, en donde se recogen opiniones y observaciones por parte de los miembros del equipo. Es de suma importancia que los integrantes del equipo tengan una actitud objetiva. Revisar lanzamiento de datos: En este proceso es el gerente de planeación de llevar acabo las reuniones en donde se revisan los datos del lanzamiento, los cuales debe de asegurarse que todos los datos obtenidos sean completos, precisos y que puedan estar disponibles para su revisión, mas delante de este capítulo se verá una plantilla para realizar estas actividades. Preparar la propuesta de mejora de procesos: Esta actividad consiste en generar comentarios y sugerencias por porte de los integrantes del equipo sobre cómo poder mejorar los procesos con la experiencia de proyectos pasados. Evaluación de lanzamiento: EL líder del proyecto y los integrantes del equipo deben llevar a cabo la evaluación del lanzamiento del proyecto al culminar todo el proceso. Esta evaluación se utiliza para controlar la calidad del proceso de lanzamiento del TSP


de tal manera que se pudenda identificar los procesos o áreas que se deben de cambiar o mejorar. Para poder hacer la evolución de debe de llenar en formularios.

Reunión de la documentación del lanzamiento: Finalmente se debe reunir la documentación de la propuesta de mejora de procesos y otras propuestas de manera correcta y dárselas a conocer a las personas indicadas para que se lleven a cabo. A continuación se explica un ejemplo con los elementos necesarios para elaborar el documento postmortem basado en el TSP (Toro, Escallón, Villegas y Mariño, 2009).

Introducción: Es una breve explicación del contenido del documento del postmortem. Propósito: Se redacta lo que se espera de la realización de este documento. Análisis por fase: Se debe revisar cada una de las actividades que se realizaron en cada una de las fases del ciclo de vida del TSP. TSP recomienda primero hacer una breve descripción de lo que se realizó en cada etapa, después se hace uso de una tabla como la siguiente, para organizar la información:

Plan Actual Semana Fecha Horas Horas Valor Hora Horas Valor Acumula direct Acumul Planeado s del Acumula gana ción del No. as adas Ganado Equi das do valor po por ganado sema na 1 01/04/2009 48 43 48 14,33 14,33 48 14,33 2 08/04/2009 48 91 96 44,33 30 48 30 3 15/04/2009 68 159 160 23 67,33 49,33 64 4 27/04/2009 252 269 32,33 99,67 93 82,33 109 5 04/05/2009 48 300 300 0,33 100 100 31 Ejemplo de revisión post mortem por ciclos del proyecto ECOSSOCCER (Toro, Escallón, Villegas y Mariño, 2009). En la tabla anterior se muestran las horas planeadas para realizar las actividades en la fase del lanzamiento, en la cual del lado derecho se muestran las horas planeadas por semana y del lado derecho el valor de cumplimiento de lo planeado.


A continuación se elabora la siguiente tabla para verificar el cumplimiento de las tareas. Fase

Parte

Nombre de la Tarea Realizar la carta de constitución del proyecto con los Lanzamiento Alcance bjetivos y alcance del mismo. Lanzamiento Equipo Conformación del equipo de trabajo. Asignación de roles a cada miembro del equipo de Lanzamiento Roles trabajo. Lanzamiento Glosario Elaboración del glosario de términos del proyecto. Ejemplo de revisión de tareas del proyecto ECOSSOCCER (Toro, Escallón, Villegas y Mariño, 2009)

Resultados: Se describen los resultados obtenidos en la fase. Conclusión: Se hace un comentario en general de lo que se programó y lo que se obtuvo en la fase. Lecciones aprendidas: Al terminar de evaluar cada uno de los ciclos del TSP durante el desarrollo del proyecto se toman en cuenta una serie de criterios para detectar en dónde se falló y qué se puede hacer para mejorar por ejemplo si los problemas que se encontraron fueron más concurrentes en la codificación, en la disciplina de trabajo etc., y cómo se actuó ante estas situaciones. Finalmente se hacer una recomendación para mejorar para los siguientes proyectos. Evaluación personal y de equipo: En esta actividad como se mencionó en este capítulo se debe llevar acabo la evaluación del rendimiento del equipo y de cada uno de los miembros del equipo. A continuación se muestra el formato utilizado para un proyecto de desarrollo de software que lleva por nombre ECOOSSOCCER donde se evalúa el rendimiento o desempeño de los miembros del equipo durante cada ciclo.


Ejemplo de formulario de evaluación personal y del equipo

Nombre

Adrián Villegas

Equipo

ESG

Líder de Proyecto

Dalia Trujillo

Fecha

29/04/2009

Ciclo No.

01

Semana No.

05

Para cada rol, evalúa el trabajo requerido y la dificultad relativa en % durante este ciclo. Rol

Trabajo Requerido

Dificultad del Rol

Jefe de Equipo

15

15

Gerente de Desarrollo

25

15

Gerente de Planeación

25

30

Calidad/Gerente de Proceso

25

30

Gerente de Soporte

10

10

Total Contribución (100%)

100

100

Evalúa el total del equipo en cada criterio: indique un número del 1 (mín.) a 5 (máx.). Actitud Equipo

1

2

3

4

5

Efectividad Global

1

2

3

4

5

Experiencia Gratificante

1

2

3

4

5

Productividad del Equipo Calidad del Proceso

1

2

3

4

5

1

2

3

4

5

Calidad del Producto

1

2

3

4

5

Evalúa rol por contribución total: indique un número del 1 (mín.) a 5 (máx.).


Líder de Equipo

1

2

3

4

5


1

2

3

4

5


1

2

3

4

5

Calidad/Gerente de Proceso Gerente de Proceso

1

2

3

4

5

1

2

3

4

5

Evalúa cada rol por ayuda y soporte: indique un número del 1 (mín.) a 5 (máx.). Jefe de Equipo

1

2

3

4

5


1

2

3

4

5


1

2

3

4

5

Calidad/Gerente de Procesos Gerente de Soporte

1

2

3

4

5

1

2

3

4

5

Evalúa rol respecto a su desempeño: indique un número del 1 (mín.) a 5 (máx.). Líder de Proyecto

1

2

3

4

5


1

2

3

4

5


1

2

3

4

5

Calidad/Gerente de Procesos Gerente de Soporte

1

2

3

4

5

1

2

3

4

5

(Toro, Escallón, Villegas y Mariño, 2009) En el ejemplo anterior se representa la puntuación que se le asignó a los diferentes roles de un equipo de trabajo durante el desarrollo del proyecto.

Reporte de errores y control de cambios del proyecto: El reporte de errores es una documento o formato en donde se registran los problemas encontrados en alguna fase o actividad dentro del desarrollo del proyecto para después hacer los cambios correspondientes para darle solución estos ajustes serializan en un documento llamado control de cambios. Siguiendo con el ejemplo del proyecto


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

Equipo

ESG (Grupo de Expertos de Software)

Líder Proyecto

Parte

Nuevos requerimientos del proyecto en la Ciclo etapa de programación o desarrollo.

12/04/09 de Dalia Trujillo 1

Fecha

Evento

Numero de control de cambios (revisión)

Priorida d

Respo nsable

Fecha de Seguimi ento

Resuelto

09/04/ 09

Control de Cambio s de Requeri mientos

1

Alta

Guiller mo Toro

15/04/09

Si


Descripción: Fruto de la validación, es necesario redefinir los casos de uso a partir del análisis y la validación que se realizó sobre la arquitectura y la navegabilidad de los casos de uso.

1. Consultar Disponibilidad: Se deben tener los caminos alternativos (Consultar para el día actual y consulta con fecha y hora especificas) como opciones dadas desde el principio. 2. Reserva: El nombre del cliente está almacenado en la base de datos, por lo tanto sólo se ingresa la cédula del cliente para validar que exista. En la programación, se asume que la base de datos está poblada con todos los campos en estado disponible. 3. Legalizar: El nombre del cliente debe estar creado en la base de datos. 4. Alquilar: El nombre del cliente debe estar creado en la base de datos. 5. Recaudo: Generar un clase que tenga como atributos la fecha, el campo y el movimiento, y otra clase de Recaudado para realizar la consulta. Se deben volver a redactar las especificaciones de todos los casos de uso para que puedan tener el control que se estableció según el análisis realizado a la arquitectura. Dichos cambios ayudarán a tener un alcance definido en cada funcionalidad y una especificación más clara al momento de implementarla. LOG (Bitácora) de eventos y cambios en el proyecto. (Toro, Escallón, Villegas y Mariño, 2009). En el ejemplo anterior se describe el pro que de los cambios en esta fase de los procesos, esto es muy común ya que durante el desarrollo del proyecto pueden presentarse situaciones que lleven a la necesidad de hacer cambios en los planes previamente formulados.

Reporte final de la línea base: Este reporte debe contener los siguientes datos: Introducción: Breve introducción del contenido del reporte. Ítem de configuración: Este se refiere a los cada uno de los procesos donde se tienen que revisar los documentos que se elaboraron en cada fase del ciclo de vida del TSP. Ejemplo:


Introducción Ítem de configuración Sigla Categoría Artefactos Fases Lanzamiento

Planeación

LZ

PL

SCOPE

Carta de constitución del proyecto

TEAM

Asignación de roles

MODEL

Modelo conceptual

REQU

Diagrama casos de uso Listado de requerimientos y casos de Uso

PLAN

Estimación Plan del Equipo de Trabajo Cronograma

Requerimientos

RQ

SPEC

Especificación de Casos de Uso. Trazabilidad de Casos de Uso y Requerimientos

Diseño de arquitectura

DA

ARCH

Documento de Diseño de Arquitectura. Documento con el Diseño Detallado de Arquitectura

Código fuente

CF

SOURCE

Archivos Fuentes. Librerías

Testing

TS

COMP

Componentes de Software.

FILES

Archivos Externos (Imágenes, Videos, etc.)

PLAN

Plan de Pruebas Reporte de Pruebas


Cierre

PM

REPORT

Historia del Proyecto Artefactos de Cierre TSP

Ejemplo de los Ítem de configuración. (Toro, Escallón, Villegas y Mariño, 2009).

3. Seguimiento de actividades de los miembros del Equipo: Actividad que se realiza durante las reuniones de la fase del p o s t m o r t e m y que para poder llevar el control de las actividades da cada uno de los integrantes del equipo se debe de llevar acabo el siguiente formulario: Nombre

Adrián Villegas

Fecha

31/03/09

Equipo

ESG (Grupo de Expertos de Software)

Instructo r

Dalia Trujillo

Ciclo

1

Parte/Nivel

Fecha

Inicio

Fin

Tiempo de Tiempo Interrupción Delta

Fase/Tarea

Compone nte

Comentarios

14:00

18:00

00:30

3:30

Lanzamiento

Enuncia do

18:00

22:00

00:30

3:30

Lanzamiento

Alcance

12:00

14:00

0:00

2:00

Lanzamiento

Roles y Equipo

Elaboración del enunciado del problema. Realizar la carta de constitución del proyecto con los objetivos y alcance del mismo. Conformaci ón del equipo de trabajo.

03/21/ 09

03/21/ 09

03/22/ 09


14:00

18:00

1:00

3:00

Lanzamiento

Roles y Equipo

19:00: 21:00: 00:00 00 00

2:00

Requerimient os

Requeri mientos

00:00

2:00

Requerimient os

Requeri mientos

00:00

1:00

Requerimient os

Requeri mientos

00:00

2:00

Planeación de trabajo

Planeaci ón

03/22/ 09

03/22/ 09

03/30/ 21:00: 23:00: 09 00 00

3/30/0 00:00: 01:00: 9 00 00 02/04/ 19:00 09

21:00

Asignación de roles a cada miembro del equipo de trabajo. Validación 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 Revisión de las correccione s a realizar sobre el proyecto. Definición del plan de trabajo.


04/04/ 08:00 09

22:00

01:00

13:00

Lanzamiento Artefacto Correccione –Estrategia – s s sobre Requerimient todos los os artefactos de dichas fases y elaboración de nuevos artefactos. Planeación- Artefacto Correccione Requerimient s s sobre os todos los artefactos de dichas fases y elaboración de nuevos artefactos.

05/04/ 09:00 09

23:00

01:00

13:00

18/04/ 09:00 09

23:00

01:00

13:00

Diseño

Revisión

Revisión de tareas pendientes según cronograma de tareas de diseño

17/04/ 21:00 09

23:00

00:30

1:30

Construcción

Revisión de caso de uso

Revisión de los flujos del caso de uso para inspecciona r y visionar la manera de implementar lo


17/04/ 09:00 09

15:00

01:00

5:00

Construcción

Revisión de caso de uso

20/04/ 21:00 09

23:00

00:00

2:00

Construcción

Desarroll o de caso de uso

21/04/ 21:00 09

01:00

00:30

02:30

Construcción


26/04/ 14:00 09

20:00

01:00

05:00

Construcción


Reunión 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


27/04/ 20:00 09

23:00

0:30

2:30

Postmortem

Evaluaci ón

Evaluación de los diferentes roles de TSP en el proyecto 28/04/ 20:00 23:00 0:30 2:30 Postmortem Evaluaci Evaluación 09 ón del desempeño del equipo el proyecto Ejemplo de control de actividades por cada uno de los miembros del equipo. (Toro, Escallón, Villegas y Mariño 2009).


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

a

Horas del Plan

er s T ei

s F P

e a

n

q

u

d

e

et L

er

Lanzamiento Lanzamiento

Realizar la carta de constitución del Alcance proyecto con los objetivos y alcance del mismo. Conformación del Equipo equipo de trabajo. Asignación de roles a Roles cada miembro del equipo de trabajo. Glosario Elaboración del

et et er

3

4

1

2

2

1

1

G

et

o n

1

1

m

ar

er

a

d l ar H o

1

2 1

o

1

T ñ

e G

1

s

o

m lo

u

o N

c a V

a

m c e a

H

r .

a u

o

P S

a

a

T

1

d

u

e

n m

ar

al

m

c h

3

1

e

s al

m

a u

d n

a

u

e G

U

ar d

e e

G

4

er n

e

s

m

e

e a

ñ

la

o

n

n

d

a

o

u

a s

d a

id

d s

p n

n

o or

d

dí N

d

u

e d

r °

N

Lanzamiento

e d

la

s o

a

e

c

p

nI b

Lanzamiento

d

e

d

e

C

ot

d d

e p

a la

e e

er o

n

E

d

l

s

g m

e

e a

q o

di

Actual

s s

u r

a

a

e

a

a

pi et

d c

ip

e r

r

o /

ói or

or al

et

n l

o

a

ol

Plan de Tamaño / Valor

S

A

ar

s

T

o H

6 6 Hojas

3

1 2 2 8

5 11 Hojas

4

1

1, 3, 5 13 1,2,3 67 67

4 15 Hojas

2

1

1, 5 4 17 1,2,3 33

5 20 Hojas 10

8 1,2,3

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


glosario de términos del proyecto. Estrategi Definir el Ciclo de vida Lanzamiento a de desarrollo. Estrategi Elaborar el diseño Lanzamiento a conceptual.

67 67 2

4

1

3

3

2, 9 4 24 1,2,3 33

7 27 Hojas

3

1

3 30 Hojas

2

1 1 10 2 26 1,2,3

Seguimiento del proyecto. (Toro, Escallón, Villegas y Mariño 2009). En este ejemplo se observan las tareas que fueron planeadas en la fase de lanzamiento para cada uno de los r oles del proyecto, así como las horas asignadas para cada miembro del equipo. Se observa el nombre de la actividad que se planeó y realizo así como las horas necesarias para realizar dichas actividades, por ejemplo vemos en la fase de lanzamiento en la creación del equipó con cuatro involucrados tres horas planeadas para que el líder de proyecto forme el equipo de trabajo en conjunto con el gerente de planeación al cual se le estimaron tres horas para culminar sus tareas con un total de horas acumuladas de seis, también se pueden observar las semanas en que se realizaron las actividades.


glosario de términos del proyecto. Estrategi Definir el Ciclo de vida Lanzamiento a de desarrollo. Estrategi Elaborar el diseño Lanzamiento a conceptual.

67 67 2

4

1

3

3

2, 9 4 24 1,2,3 33

7 27 Hojas

3

1

3 30 Hojas

2

1 1 10 2 26 1,2,3

Seguimiento del proyecto. (Toro, Escallón, Villegas y Mariño 2009). En este ejemplo se observan las tareas que fueron planeadas en la fase de lanzamiento para cada uno de los r oles del proyecto, así como las horas asignadas para cada miembro del equipo. Se observa el nombre de la actividad que se planeó y realizo así como las horas necesarias para realizar dichas actividades, por ejemplo vemos en la fase de lanzamiento en la creación del equipó con cuatro involucrados tres horas planeadas para que el líder de proyecto forme el equipo de trabajo en conjunto con el gerente de planeación al cual se le estimaron tres horas para culminar sus tareas con un total de horas acumuladas de seis, también se pueden observar las semanas en que se realizaron las actividades.

34


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:

Fecha: Instructor: Ciclo: Plan

Semana

No.

Fecha

Actual

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


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:

Fecha: Instructor: Ciclo: Plan

Semana

No.

Fecha

Actual

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 48 43 48 48 14,33 14,33 2 08/04/2009 48 91 48 96 30 30 3 15/04/2009 68 159 64 160 23 49,33 4 27/04/2009 252 269 32,33 93 82,33 109 5 04/05/2009 48 300 31 300 0,33 100 Reporte de cronograma programado. (Toro, Escallón, Villegas y Mariño 2009).

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

Al concluir con las actividades se hace un análisis de los datos obtenidos configurando un reporte de calidad, se puede hacer uso de los siguientes elementos. Logros alcanzados: Se hace una revisión de los logros que se pudieron alcanzar que fueron planeados previamente con una breve descripción de la actividad que se cumplió. Problemas encontrados: Se identifica eventos o actividades en las que se tuvieron problemas para cumplir los objetivos se describe porque fue que no se cumplió con lo planeado o si se pudo encontrar una solución para que se pudiera completar la actividad. Lecciones aprendidas: Esto se obtiene por medio de los problemas encontrados ya que se pude aprender de los errores para poder prevenir que se presenten nuevamente en los futuros proyectos así como también se puede aprender de las actividades que se completaron sin contratiempos.


35


Oportunidades de mejora: Con base en los problemas que se presentaron en relación con las actividades que se cumplieron sin ningún problema se detecta en qué se falló o la manera en que se pude mejorar para los siguientes proyectos. Toda esta información debe ser registrada de manera conjunta entre líder de proyecto y los integrantes que conforman el equipo para poder evaluar los resultados obtenidos, incluyendo al Administrador del proyecto. En conclusión el objetivo principal del postmortem ya sea de manera individual o en equipo es proporcionar información y conocimientos para que sea posible mejorar significativamente el desempeño de las tareas asignadas. Es importante tomar en cuenta que el equipo y cada uno de los integrantes que lo conforman deben estar comprometidos en la recopilación de la información general, desde el inicio hasta la culminación del proyecto. El postmortem se debe realizar al final de cada ciclo del proyecto y hasta el final de todo el proyecto como lo marca las fases del ciclo del vida del TSP.

Autoevaluación Antes de desarrollar la evidencia de aprendizaje, realiza la autoevaluación con el fin de hacer un recuento general de la unidad; así como detectar aquellos temas que no has comprendido en su totalidad y que necesites revisar nuevamente, o bien consultar con tus compañeros(as) y Facilitador(a). Para realizar la Autoevaluación, ingresa al listado de actividades en el aula.

Evidencia de aprendizaje. Generación del reporte de calidad del proyecto Como evidencia de aprendizaje generarás un informe de logros del equipo de trabajo para poder evaluar el cumplimiento de los objetivos en cuanto a las métricas propuestas para garantizar la calidad del proyecto mediante el planteamiento de un problema correspondiente a un proyecto de software que te hará llegar tu Facilitador (a), una vez que cuentes con él: 1. Identifica los problemas encontrados con relación a las métricas planeadas. 2. Elabora el plan del informe de seguimiento del proyecto asegurándote de


36


integrar el objetivo personal de cada uno de los roles así como las métricas propuestas y el resultado obtenido apoyándote del ejemplo desarrollado en tema 3.2.1. 3. Redacta tus conclusiones acerca del origen del problema: desempeño, calidad del producto, etcétera; así como la forma en que se pueden mejorar los problemas presentados. 4. Guarda la actividad con el nombre DDSE_U3_EA_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. 5. Envía tu actividad al portafolio de evidencias. *Consulta la Rúbrica de evaluación de la unidad 3 para conocer los parámetros de evaluación de esta actividad.

Autorreflexiones Además de enviar tu trabajo de la Evidencia de aprendizaje, ingresa al foro Preguntas de Autorreflexión y consulta las preguntas que tu Facilitador(a) presente, a partir de ellas elabora tu Autorreflexión en un archivo de texto llamado DDSE_U3_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad En esta Unidad aprendiste porqué es muy importante realizar el monitoreo y control del proyecto, para saber si el proyecto marcha según lo planeado al inicio del mismo. Dentro de este punto, aprendiste a elaborar las plantillas de revisión de la administración de proyecto y la plantilla de reporte administrativo del estatus del proyecto.


37


También aprendiste a implementar la fase postmortem de TSP la cual te proporcionará una retroalimentación de los aciertos y errores que se tuvieron durante el desarrollo del proyecto. Y por supuesto comparar las métricas de calidad contra el trabajo realizado por parte del equipo y a elaborar el análisis de desempeño del mismo. Como conclusión de la asignatura, es importante remarcar que para que un proyecto de desarrollo de software tenga éxito y se cumplan los objetivos planteados al inicio del mismo, se necesita una metodología de calidad y TSP es una de ellas, la cual te aporta una guía de lo que debes hacer para que tu proyecto de desarrollo de software se lleve a cabo y se concluya logrando la calidad deseada al final del ciclo de vida del proyecto. Esperamos que la información aquí proporcionada, te sirva para lograr el éxito deseado en los proyectos que realices en tu vida profesional y sepas que hacer cuando un proyecto de desarrollo de software no va marchando conforme a lo planeado, y con esto seas capaz de dar soluciones a los problemas que se puedan presentar dentro de la empresa o proyectos en los que estés laborando o en los que te integres en un futuro.

Para saber más En esta página encontrarás información diversa acerca de las herramientas de medición de la calidad del desarrollo de software, entre ellas TSP, así como diversos artículos y documentos acerca de esta metodología. Software Engineering Institute Carnegie Mellon (2013). Pittsburgh: https://www.sei.cmu.edu/library/abstracts/books/201731134.cfm

Fuentes de consulta 



Archila, Ángela; Molano, Edison; Kook, Enrique; Gutiérrez, Gustavo y Larrota, Jesús. (2010). Informe Postmortem. Proceso de originación de crédito, Banco de los Alpes. Panamá: Grupo NEO TEC S.A. [En línea] http://webcache.googleusercontent.com/search?q=cache:Vh09Kn4VN_MJ:kymera. googlecode.com/svn/trunk/Documentation/Mejoramiento%2520de%2520Procesos/ Informe%2520Postmortem.docx+&cd=3&hl=es-419&ct=clnk&gl=mx Esterkin, J. (2008). Qué es y cómo se hace un reporte de estado del proyecto . México: IAAP.


38

Unidad 3 Gestion en TSP

Recommend Documents