4 La estructura del TSP 9

Los principales elementos del proceso de TSP se muestran en la Figura 2. Antes de que los miembros pueden participar en un equipo TSP, deben saber cómo hacer el trabajo disciplinado. Como se muestra en esta figura, Se requiere formación en el Personal Software Process (PSP) para proporcionar a los ingenieros con los conocimientos y habilidades para utilizar el TSP. Formación PSP incluye aprender cómo hacer detallada planes , la recopilación y el uso de los datos del proceso , el desarrollo de planes de valor ganado , utilizando el valor obtenido para el seguimiento de un proyecto , medición y gestión de la calidad del producto , y la definición y el uso operacional procesos. Los ingenieros deben ser entrenados en estas habilidades antes de que puedan participar en el equipo de TSP edificio o seguir el proceso TSP definido.

Si bien hay muchas maneras de construir equipos, todos ellos requieren que los individuos trabajan juntos para llevar a cabo alguna tarea exigente. En el TSP, esta tarea de formación de equipos exigente es un cuatro proceso de planificación de días que se llama el lanzamiento del equipo. En el lanzamiento, todos los miembros del equipo a desarrollar la estrategia, proceso, y un plan para hacer su proyecto. Después de completar la puesta en marcha, el equipo sigue su propio proceso definido para hacer el trabajo. Como se muestra en la Figura 3, los equipos de TSP se relanzaron periódicamente. Debido a que el proceso de TSP sigue una estrategia de desarrollo iterativo y evolutivo, relanzamientos periódicos son necesarios para que cada fase o ciclo se pueden planificar en base a los conocimientos adquiridos en el ciclo anterior.También se requiere el relanzamiento de actualizar los planes detallados de los ingenieros, que suelen ser exacta por sólo unos pocos meses. La razón de tener un relanzamiento es que los planes detallados sólo pueden ser precisa durante unos meses. En el lanzamiento TSP, los equipos hacen un plan global y un plan detallado por alrededor de los próximos tres a cuatro meses. Después de los miembros del equipo han completado todas o la mayoría de la siguiente fase del proyecto o ciclo, que revisen el plan general, si es necesario y hacer una nueva detallada planificar para

cubrir los próximos tres a cuatro meses. Se guían en hacer esto por el TSP proceso de relanzamiento.

5 Lanzamiento de un equipo de TSP

Una vez que los miembros del equipo han sido debidamente capacitados y el equipo se ha formado, la totalidad equipo participa en la puesta en marcha del equipo TSP. El proceso de lanzamiento se muestra en el script de inicio en Tabla 1 y en la Figura 4. Cada una de las 9 reuniones de lanzamiento tiene una secuencia de comandos que se describen las actividades con suficiente detalle para que un entrenador de lanzamiento entrenado puede guiar al equipo a través de los necesarios pasos. Siguiendo el proceso de puesta en marcha, los equipos producen un plan detallado. Para convertirse en un cohesivo y la unidad de trabajo efectivo, todos los miembros del equipo deben estar comprometido con el plan. Para construir este compromiso, el TSP involucra a todos los miembros del equipo en la producción de ese plan. Por lo tanto, completando el proceso de lanzamiento TSP, todos los miembros del equipo habrá participado en la producción de la planificar y todos ellos estarán de acuerdo y estar comprometidos con el plan que ellos producen.

Tabla 1: El equipo de lanzamiento TSP -Script LAU

propósito Para orientar a los equipos integrados en el lanzamiento de un proyecto de software intensivo

Criterios de Entrada - El trabajo de preparación de lanzamiento se ha completado (PREPL, PREPT).

- Para el lanzamiento, se preparan los representantes de la dirección y de marketing y disponible para reuniones 1 y 10.

- Todos los miembros del equipo y el líder del equipo se comprometen a asistir al lanzamientoReuniones de la 1 a la 9 y la autopsia.

- Un entrenador de lanzamiento autorizado está en la mano para dirigir el proceso de lanzamiento.

General - Reuniones 1, 2 y 3 se celebran el día del lanzamiento 1.- Reuniones 4, 5 y 6 se celebran el día 2.- Reuniones 7 y 8 son en el día 3.- Reunión 9 y la autopsia lanzamiento se celebran al final del día 3 o en la mañana del día 4.

Pasos ACTIVIDADES DESRIPCION

1 Proyecto yAdministraciónObjetivos

Mantenga reunión del equipo de lanzamiento 1 (uso LAU1 script).- Revisar el proceso de lanzamiento y presentar a los miembros del equipo.- Discutir los objetivos del proyecto con la administración y hacer preguntas.

2 Objetivos del equipo yRoles

Mantenga reunión del equipo de lanzamiento 2 (uso LAU2 script).- Seleccione los roles del equipo y funciones de copia de seguridad.- Definir y documentar los objetivos del equipo

3 Estrategia del proyectoy Apoyo

Estrategia del proyectoy Apoyo

Mantenga reunión del equipo de lanzamiento 3 (uso LAU3 script).- Producir una lista diseño y solución conceptual del sistema (si es necesario).- Determinar la estrategia y productos para producir el desarrollo.- Definir el proceso de desarrollo que se utilizará.- Producir los planes de proceso y de apoyo.

4 plan general Mantenga reunión del equipo de lanzamiento 4 (uso LAU4 script).- Desarrollar las estimaciones del tamaño y el plan general

5 plan de Calidad Mantenga reunión del equipo de lanzamiento 5 (uso LAU5 script).- Desarrollar el plan de calidad

6 plan de Balance Mantenga reunión del equipo de lanzamiento 6 ( uso LAU6 script) y producir- Asignación de trabajo a los miembros del equipo- Planes de abajo hacia arriba de la próxima fase para cada miembro del equipo- Un plan de próxima fase equilibrada para el equipo y cada miembro del equipo

7 Riesgos del Proyecto

análisisMantenga reunión del equipo de lanzamiento 7 (uso LAU7 script).- Identificar y evaluar los riesgos del proyecto.- Definir los puestos de control y las responsabilidades de evaluación de riesgos.- Proponer las acciones de mitigación de riesgos de alto impacto inmediato

8 Lanzamiento Informe

Lanzamiento Informe

preparaciónMantenga reunión del equipo de lanzamiento 8 (uso LAU8 script).- Elaborar un informe de lanzamiento para la gestión.

9 administraciónrevisión

Mantenga reunión del equipo de lanzamiento 9 (uso LAU9 script).- Las actividades de revisión de lanzamiento y los planes del proyecto con la dirección.- Discutir los riesgos del proyecto, las responsabilidades y las acciones planificadas.

PM lanzamientoautopsia

Mantenga reunión del equipo de lanzamiento 9 (uso LAU9 script).- Caminar a través de la preparación del informe semanal.- Recopilar datos de lanzamiento y elaborar un informe de lanzamiento.- Introducir este informe en el cuaderno del proyecto.- Evaluar el proceso de lanzamiento y preparar PIP.

Criterios de salida - Lanzamiento completado con equipo documentado y planes de los miembros del equipo.

- Roles de Equipo definido, objetivos, procesos y responsabilidades.

- Acciones de acuerdo con el plan de gestión de equipo o resolución identificados y las responsabilidades asignadas.

- Datos de lanzamiento presentadas en el cuaderno del proyecto (CUADERNO de especulación.)

Equipos generalmente necesitan orientación profesional para completar correctamente el proceso de lanzamiento. Este se ofrece orientación por un entrenador de lanzamiento capacitado que dirige el equipo a través del proceso de lanzamiento. Mientras los scripts TSP proporcionan una orientación esencial, cada equipo tiene problemas únicos y cuestiones, por lo que un simple proceso no es posible que proporcionar todo el material necesario para guiar a un inexperto. Equipo a través del proceso de lanzamiento. A menos que los equipos son muy experimentados y tienen un líder del equipo que ha completado varios proyectos TSP, por lo general, necesitan el apoyo de una Entrenador de lanzamiento entrenado.

En reunión de lanzamiento 1, el equipo, el jefe del equipo, y el entrenador de lanzamiento cumplir con la alta dirección y representantes de marketing. La alta dirección le dice al equipo sobre el proyecto, por lo que es necesarios, las razones para iniciar el proyecto, y las metas de la administración para el proyecto. La comercialización representante explica la necesidad de comercialización del producto, cualquier importante competitiva preocupación y consideraciones especiales de los clientes que el equipo tiene que saber. El objetivo de reunión 1 es informar a todos los miembros del equipo sobre el trabajo, para describir las metas de gestión para el equipo, y para convencer a los miembros del equipo que la gestión se apoya en ellos para hacer este importante proyecto.

En las reuniones de lanzamiento de 2 a 8, el equipo, el jefe del equipo, y el entrenador se reúnen sin observadores o los visitantes. Durante estas reuniones, el equipo está dirigido a través de una serie de pasos que están diseñados para producir las condiciones para el trabajo en equipo eficaz En reunión de lanzamiento 2, el equipo documenta sus metas y selecciona los roles de los miembros del equipo. La roles de equipo TSP estándar son el líder del equipo, gestor de interfaz de cliente, gerente de diseño, implementación gerente, director de pruebas, gerente de planificación, gestor de procesos, gerente de calidad, y gerente de soporte. Otras posibles funciones se pueden asignar según sea necesario. Ejemplos de ello serían gerente de seguridad, gerente de seguridad, o administrador de rendimiento. Cada miembro del equipo tiene en menos un rol de equipo. Cuando hay más de ocho miembros del equipo, se pueden añadir funciones o algunos ingenieros pueden servir como asistentes administradores de funciones. El líder del equipo en general no toma cualquier otra función.

En las reuniones de lanzamiento de 3 y 4, el equipo hace la estrategia general del proyecto y el plan. Los ingenieros producir un diseño conceptual, diseñar la estrategia de desarrollo, definir el proceso detallado que usarán, y determinar las herramientas e instalaciones que van a necesitar apoyo. Enumeran la productos para ser producidos, estiman que el tamaño de cada producto, y juzgan el tiempo necesario para cada paso del proceso. Una vez que las tareas se han definido y calculado, los ingenieros estiman él hora de que cada miembro del equipo va a gastar en el proyecto cada semana. A partir de las estimaciones de tareas y las horas semanales, el equipo genera el horario.

Una vez que tienen un plan general, los ingenieros producir los objetivos de calidad y el plan de lanzamiento cumplir 5. Este plan tanto define las acciones de calidad del equipo planea tomar, y proporciona un base mensurable para el seguimiento de la calidad del trabajo que se hace. Al hacer el plan de calidad, los miembros del equipo estiman el número de defectos que se inyectar y retirar en cada fase, y cuántos defectos será dejada para la prueba del sistema, pruebas de aceptación del cliente, y último la entrega del producto. A continuación, en la reunión de 6, los miembros del equipo hacen planes detallados de próxima fase y a continuación, revise toda la carga de trabajo en equipo para asegurar que estos planes se distribuyen de manera uniforme las tareas entre los miembros. El resultado es entonces lo que se llama un plan de equipo equilibrado. Durante la reunión 7, los ingenieros identificar los principales riesgos del proyecto y les alinear para probabilidad y el impacto. La equipo también asigna un miembro del equipo para realizar un seguimiento de cada riesgo y prepara un plan de mitigación para el la mayoría de los riesgos significativos. Después

de que el equipo ha completado su plan, los miembros mantienen reuniones 8 a prepararse para la gestión revisan y luego llevan a cabo la revisión de la gestión en la reunión 9. Durante este reunión, el equipo explica el plan, describe cómo se produjo, y demuestra que todos los miembros están de acuerdo con y están comprometidos con el plan. Si el equipo no ha cumplido con la gestión de objetivos, se deben generalmente preparar y presentar planes alternativos que muestran lo que podría ser hecho con recursos añadidos o cambios en los requerimientos. La razón principal para mostrar alternativo planes es proporcionar a la dirección opciones a considerar en caso el plan del equipo no satisfacer las necesidades empresariales. Al final de la puesta en marcha TSP, el equipo y la gestión deben estar de acuerdo sobre cómo el equipo es proceder con el proyecto.

En la etapa de post-mortem final, el equipo revisa el proceso de puesta en marcha y presenta la mejora de procesos propuestas (PIP) en mejoras de procesos sugeridos. El equipo también reúne y archivos de los datos de lanzamiento y materiales para su uso posterior.

6 El Proceso TSP Trabajo En Equipo

Una vez que se puso en marcha el equipo de TSP, la necesidad principal es garantizar que todos los miembros del equipo siguen El plan. Esto incluye los siguientes temas principales:

• Al frente del equipo.• Proceso de la disciplina.• Seguimiento de problemas.• Comunicación.• Informes de gestión.• Mantener el plan.• Estimación de la finalización del proyecto.• El equipo de Reequilibrio carga de trabajo.• Relanzamiento del proyecto.• TSP gestión de la calidad.

6.1 Líder del EquipoEl líder del equipo es responsable de guiar y motivar a los miembros del equipo, manejo de clientes problemas, y hacer frente a la gestión. Esto incluye la dirección del día a día de la trabajo, protección de los recursos del equipo, la resolución de problemas del equipo, la realización de reuniones de equipo, y la presentación de informes en el trabajo. En general, la responsabilidad principal de la líder del equipo es mantener la La motivación del equipo y energía y para asegurarse de que está plenamente eficaz en hacer su trabajo.

Una de las responsabilidades de liderazgo clave es el mantenimiento de la disciplina proceso. Aquí, el líder del equipo asegura que los ingenieros hacen el trabajo de la manera que habían planeado para hacerlo. Durante el lanzamiento, que definen el proceso para hacer el trabajo. Mientras se hace el trabajo, el jefe del equipo supervisa la trabajar para garantizar que todo el mundo sigue el proceso y el plan que el equipo produjo.

Casi todos los proyectos se enfrentan apretado calendario y la presión de los recursos, por lo que siempre es una tentación para cortar las esquinas. Sin embargo, cuando los equipos de dejar de seguir sus procesos definidos, tienen hay manera de saber lo que se debe hacer o cuál es su posición en el trabajo. En la vigilancia disciplina proceso, el líder del equipo debe comprobar que cada miembro del equipo registra su los datos del proceso, los informes sobre el estado de la semana, y produce productos de calidad.

Otra responsabilidad importante líder del equipo es asegurar que todos los problemas que el equipo miembros se identifica son gestionados y controlados. Con el TSP, los ingenieros generalmente discuten problemas en la reunión semanal del equipo. El líder del equipo debe primero comprobar que cada número es uno que el equipo debe manejar y si lo es, decidir qué miembro del equipo debe ser responsable de la gestión y el seguimiento de la misma. Por último, el equipo de seguimiento de cada tema con el registro de seguimiento de problemas (ITL) y revisa todas las cuestiones pendientes en cada reunión semanal.

6.2 ComunicaciónEl líder del equipo es responsable de mantener la comunicación del equipo abierto y eficaz. Cuando los miembros del equipo no conocen el estado del proyecto, entender lo que sus compañeros son haciendo, o saber qué retos tiene por delante, es difícil para ellos mantener la motivación. Comunicación es una parte fundamental de mantener la energía del equipo y conducir y facilitar la comunicación es una parte clave de las responsabilidades del jefe de equipo.

Durante la reunión semanal, el líder del equipo revisa primero el estado del proyecto y cualquier gestión problemas o preocupaciones. Los miembros del equipo luego cada revisen su trabajo para la semana anterior, la trabajan planean para la próxima semana, sus actividades de gestión de papel, y el estado de los riesgos están rastreando. También mencionar cualquier problema o problemas y describir las áreas donde van a necesitar ayuda o apoyo durante la próxima semana.

Otra responsabilidad crítica líder del equipo es mantener informada a la dirección sobre el equipo estado y progreso. El proceso TSP llama para que los equipos hacen informes semanales que muestran dónde el equipo está en contra del plan. El proceso también requiere frecuente, de hecho, y completa estado de los clientes informa.

6,3 mantener el plan

Una vez que los equipos han completado la puesta en marcha del proyecto y empezar a trabajar en el trabajo, el plan guía al trabajo. También proporciona un punto de referencia para medir el progreso, así como medios para identificar problemas que puedan amenazar el cronograma del proyecto. Con suficiente antelación, los equipos pueden a menudo tomar las medidas oportunas para evitar el deslizamiento horario.Equipos TSP seguir el progreso contra el plan cada semana utilizando un método llamado valor ganado [Humphrey 95]. Con valor ganado, cada tarea se le asigna un valor basado en el porcentaje de la estimación total del proyecto que se requiere para esa tarea. Por lo tanto, si se planeó un proyecto para llevar 1.000 horas de trabajo, una tarea de 32 horas tendrían 3,2 valor planificado, o 100 * 32/1000 = 3,2%.

Entonces, cuando el equipo ha completado esa tarea, los ingenieros se han acumulado 3,2 puntos de valor ganado, no importa cuánto tiempo en realidad tomó la tarea.

Los equipos de ingeniería tienen muchos tipos de tareas y en cualquier proyecto de una complejidad razonable, las tareas suelen ser completadas en un orden diferente de lo inicialmente previsto. Dado que algunas tareas se completará temprano y otros serán finales, no hay manera fácil de decir si el proyecto es antes de lo previsto o por detrás. El método del valor ganado proporciona un valor para cada tarea, y cuando se haya completado esa tarea, el equipo gana ese valor. Por lo tanto, con el valor ganado, la equipo puede decir con precisión dónde se encuentra el proyecto. Por ejemplo, el equipo podría reportar los datos semanales que se muestran en la Tabla 2.Tabla 2: Semanal Datos Equipo

Semana 3 Plan ActualHoras de tarea 106 98Horas de tareas hasta la fecha 300 274

El valor ganado 1.9 2.1El valor ganado hasta la fecha 5.8 5.3

Incluso durante el requisitos o principios de diseño de trabajo, informó el equipo de gestión dicen precisamente donde el equipo está en contra del plan. Por ejemplo, a partir de los datos de la Tabla 2, la gestión podría ver que el rendimiento del equipo ha mejorado significativamente en la última semana. En las dos semanas anteriores, que tenían 176 horas de trabajo (274-98), o un promedio de 88 horas de trabajo por semana. Esta semana se logró 98 horas. Del mismo modo, a pesar de que están detrás de acumulativo valor actualizado ganado, que lograron más de lo previsto en la última semana.

El método del valor ganado también ayuda a los equipos estima cuándo van a terminar el trabajo. Desde los datos semanales, los ingenieros pueden ver el número de horas que han pasado por cada punto de ganado valor. Entonces, suponiendo que continúan trabajando en la misma proporción, pueden estimar cuándo van a terminar el trabajo. Por ejemplo, en la Tabla 2, el equipo ha acumulado 5,3 ganadosPuntos de valor (EV) en 3 semanas o 1.7667 EV por semana. A ese ritmo, va a tomar el trabajo 100 / 1,7667 = 56,6 semanas. Puesto que han completado la semana 3, esto es 53,6 semanas más de trabajo. Si el equipo es capaz de seguir trabajando a la velocidad para la semana más reciente, sin embargo, el trabajo total sería tomar sólo (100 - 5.8) /2.1 = 44.9 semanas más.

Los datos sobre el valor ganado no sólo ayudan a los miembros del equipo para ver dónde están, pero estos datos también ayudar a la gestión de entender lo que hay que hacer para completar el trabajo a tiempo. Con valor ganado, equipos de TSP y sus gerentes pueden anticipar problemas de horario muy temprano en el trabajo. Entonces, por lo general tienen tiempo de tomar cualquier acción de recuperación necesarios.

Mientras que el valor obtenido es útil en el seguimiento de los avances en equipo y la prestación de los ingenieros con un sentido de logro, no se ocupa de prioridades de las tareas o dependencias. Para correctamente gestionar las relaciones de trabajo, los ingenieros deben mantener sus planes personales y asegurar que identifican y resuelven todas las dependencias de tareas con sus compañeros de equipo. En los

equipos más grandes, ayudando los miembros del equipo hacen esto es una parte importante de la responsabilidad el rol del gerente de planificación.

6.4 Reequilibrio Equipo de carga de trabajoCarga de trabajo desequilibrada puede causar un equipo sea ineficiente. Esto ocurre cuando algunos ingenieros tienen mucho más trabajo de lo que otros tienen. Este problema tiene varias causas. En primer lugar, los más experimentados ingenieros participan generalmente en mucho más del trabajo de los miembros del equipo con menos experiencia. Mientras los ingenieros más experimentados probablemente podría hacer cada tarea más rápido y mejor que los demás, esto sería sobrecargarlos y dejar a los demás con poco que hacer. Otra causa de la carga de trabajo no balanceada es la fluctuación normal en el rendimiento de la ingeniería.Algunos ingenieros terminar sus tareas antes del plan, y otros se quedarán atrás.Mientras que la carga de trabajo desequilibrada es natural, no es eficiente. A menos

Que todos los miembros del equipo son siempre totalmente ocupada, el equipo no puede ser plenamente eficaz. Cada semana, cuando los examina equipo el estado del proyecto, los ingenieros pueden ver si su carga de trabajo no es equilibrada. Si es así, el equipo debe reequilibrar el plan. Con el TSP, los equipos hacen esto tan a menudo como sea necesario cada semana si necesario. Una vez que los ingenieros han completado un lanzamiento TSP y han detallado planes personales,Generalmente puede reequilibrar equipo de carga de trabajo en sólo una o dos horas.La puesta en marcha del equipo TSP produce un plan general del proyecto que se extiende desde la puesta en marcha del equipo inicial hasta la finalización del proyecto final. Dependiendo del proyecto, el plan podría cubrir un par de semanas o que podría tomar muchos años. Con el TSP, cada miembro del equipo elabora un plan detallado para la siguiente fase del proyecto. Desde ingenieros en general no pueden hacer planes detallados para más de alrededor de tres o cuatro meses, el TSP se rompe proyectos en fases de aproximadamente tres a cuatro meses de duración.Equipos relanzar sus proyectos en el comienzo de cada fase o ciclo. Siempre que los equipos encuentran que el plan ya no les ayuda a hacer su trabajo, deben relanzar sus proyectos.Los equipos también deben relanzaron cuando hay grandes cambios en el trabajo a realizar o en los miembros del equipo.

7.- Gestión de la Calidad TSP

Aunque la mayoría de las organizaciones están de acuerdo en que la calidad es importante, pocos equipos saben cómo manejar la calidad de sus productos. Además, no existen métodos generales para evitar la inyección de defectos. Las personas que desarrollan software, cometen errores. Estos errores son la fuente de defectos en el software. En el TSP, el énfasis principal cualidad es el de gestión de defectos.

Para gestionar la calidad, los equipos deben establecer medidas de calidad, los objetivos de calidad establecidos, establecer planes para cumplir con estas metas, medir el progreso en contra de los planes, y tomar medidas correctivas cuando no se cumplan los objetivos. El TSP muestra a los equipos cómo hacer esto. Los elementos de la administración de la calidad de TSP hacen un plan de calidad, identificando los problemas de calidad, y descubriendo y previniendo los problemas de calidad. Estos temas se tratan en los siguientes párrafos.

7.1 El Plan de Calidad

Durante la puesta en marcha del equipo, equipos de TSP hacen un plan de calidad. Basado en el tamaño estimado del producto y los datos históricos sobre las tasas de inyección de defectos, estiman cuántos defectos van encontrar en cada fase. Cuando los equipos no tienen datos históricos de inyección de defectos, pueden utilizar las directrices de planificación de calidad TSP se muestran en la Tabla 3. Estos les ayudarán a establecer objetivos de calidad. Una vez que los ingenieros han estimado los defectos que se encontraran, ellos estiman la eliminación de defectos, ellos usan de nuevo los datos históricos o las directrices de calidad TSP. Estas estimaciones de eliminación se basan en el rendimiento para cada fase de eliminación de defectos. Aquí, el rendimiento se refiere al porcentaje de los defectos en el producto de entrada que se eliminan en esa fase. Una vez que se han realizado las estimaciones de inyección y extracción, el equipo puede generar el plan de calidad. Finalmente, el equipo examina el plan de calidad para ver si los parámetros de calidad son razonables y si cumplen con los objetivos de calidad del equipo. Si no, los ingenieros ajustar las estimaciones y generan un nuevo plan de calidad.

Una vez que los miembros del equipo han generado el plan de calidad, el gerente de calidad les ayuda a realizar un seguimiento de rendimiento en su contra. El plan de calidad contiene la información se muestra en la Tabla 4. El responsable de calidad da un seguimiento de los datos en cada fase para cada parte del sistema para ver si las medidas están dentro de los valores establecidos por el plan de calidad. Si no, el gerente de calidad plantea la cuestión en la reunión semanal y sugiere lo que el equipo debe hacer al respecto.

7.2 Identificación de problemas de calidad

En el TSP, hay varias formas de identificar los problemas de calidad. Por ejemplo, mediante la comparación de los datos para cualquier módulo o componente con el plan de calidad, se puede ver rápidamente donde la densidad de defectos, las tasas de examen, los rendimientos, u otras medidas se desvían significativamente de los objetivos del equipo.

Porque incluso proyectos relativamente pequeños, se puede tomar una cantidad considerable de tiempo para examinar los datos de proceso. Para ayudar a aliviar este problema, el TSP introduce una serie de medidas de calidad.

Estas medidas son:

• Defecto Porcentaje de libre PDF

• Perfil de defectos de mudanza

• Perfil de Calidad

• La calidad del proceso índice de PQI

Una típica trama PDF se muestra en la Figura 5, que muestra el porcentaje de los componentes del sistema que no tenían defectos encontrados en una fase particular la eliminación de defectos. Mediante el seguimiento de las curvas de PDF, se puede ver si alguna fase particular es problemático. Esto se puede ver mediante la comparación de las curvas de PDF para varios

proyectos similares. Cuando hay problemas, el gerente de calidad puede mirar a los datos sobre los componentes de nivel inferior para identificar el origen del problema y recomendar lo que el equipo debe hacer al respecto.

La Figura 6 muestra un perfil típico defecto-extracción. Si bien la trama PDF sólo se puede producir por un sistema general o gran componente, el perfil de defectos eliminación puede extraerse para el sistema, cada uno de sus subsistemas, cualquier componente, o incluso hasta el nivel de módulo. Por lo tanto, si el perfil PDF o nivel del sistema de eliminación de defectos indica problemas, el gerente de calidad puede examinar los perfiles cada vez más bajos nivel de defectos de eliminación para encontrar la fuente del problema.

El índice de calidad de proceso (PQI) se produce tomando el producto de los cinco valores dimensionales del perfil de calidad para producir una sola cifra calidad de mérito [Humphrey 1998]. Con valores superiores a unos 0,4 PQI, los módulos del programa son generalmente libre de defectos. Con el PQI, las organizaciones pueden clasificar un gran número de módulos por sus niveles de calidad posibles. Esto es particularmente útil con sistemas muy grandes que tienen cientos o miles de módulos. Los equipos pueden concentrarse rápidamente en los módulos que son más propensos a ser problemático en la prueba o el uso de los clientes.

7.3 Encontrar y Prevención de Problemas de calidad

Las medidas de calidad TSP pueden indicar problemas de calidad que probablemente incluso antes de la primera compilación, y proporcionan una medida fiable del módulo o calidad de los componentes antes del inicio de la integración o la prueba del sistema. Una vez que un equipo de TSP ha identificado los módulos o componentes que muy probablemente tienen problemas de calidad, las medidas correctivas sugeridas por el TSP son los siguientes:

• Supervisar el módulo durante la prueba para ver si se encuentran problemas y luego determinar las medidas correctivas.

• vuelva a inspeccionar el módulo antes de la integración o el sistema de prueba.

• Haga que un ingeniero reelaborar el módulo para arreglar posibles problemas.

• reconstruir el módulo.

Los procesos de PSP y TSP están diseñados para evitar problemas antes de que ocurran. En el entrenamiento de PSP, los ingenieros suelen aprender cómo reducir sus tasas de inyección de defectos en un 40% a un 50%. En el TSP, el director de diseño puede reducir aún más las tasas de inyección de defectos al asegurar que el equipo produce un diseño completo y de alta calidad. El plan de calidad y seguimiento de procesos hacen los ingenieros más sensibles a los problemas de calidad de manera que sean más cuidadosos, lo que reduce aún más los defectos. Por último, el TSP presenta una revisión defecto donde se analiza cada defecto post-desarrollo para identificar cambios en los procesos potenciales que encontrarán o prevenir defectos similares en el futuro.

8.- Introduccion a TSP

El TSP está siendo introducido en los entornos industriales y académicos. Un proceso TSPI introductoria y los libros de texto están disponibles para su equipo los cursos universitarios de enseñanza [00] Humphrey. Antes de tomar el curso TSPI, los estudiantes deben haber tomado un curso de PSP, ya sea con la Disciplina para el texto de Ingeniería de Software o la introducción al texto Personal Software Process [Humphrey 95, Humphrey 97]. El curso TSPI se ha enseñado en varias universidades y la experiencia inicial indica que los estudiantes y los profesores encuentran útil. Sin embargo, no hay estudios publicados sobre el uso de los procesos y métodos TSPI.

Presentación de la TSP en las organizaciones de ingeniería es el foco principal de los esfuerzos de TSP en el Instituto de Ingeniería de Software (SEI). El TSP fue diseñado para los equipos de ingeniería, y su introducción ha sido prevista inicialmente en equipos de desarrollo de productos de software intensivo.

Apoyar el uso de equipos industriales que incluyen distintos de especialidades de software, el SEI ha desarrollado un curso introductorio para PSP profesionales que no son software de dominio. También ha introducido una serie de programas de formación y capacitación para que las organizaciones pueden obtener sus propios instructores de PSP. Además, el SEI proporciona formación entrenador TSP para que las organizaciones puedan iniciar y entrenar a sus propios equipos de TSP. El SEI ha establecido relaciones con una serie de socios de transición que están calificados para enseñar a la PSP y para entrenar a equipos de TSP. (Para más información sobre estos temas, consulte www.sei.cmu.edu/tsp.)

9.- Experiencia TSP

Mientras que el TSP es relativamente nuevo, los resultados han sido reportados por varias organizaciones. Algunos ejemplos se resumen en los siguientes párrafos.

• Teradyne encontró que, antes de la TSP, los niveles de defectos en la prueba de integración, prueba del sistema, pruebas de campo, y el uso de los clientes promedio de alrededor de 20 defectos por KLOC (1000 líneas de código, o LOC). El primer proyecto TSP reduce estos niveles a 1 por defecto KLOC. Desde cuesta un promedio de 12 horas de ingeniería para encontrar y corregir cada defecto, Teradyne salvó 228 horas de ingeniería para cada 1000 LOC del programa desarrollado. Dado que el costo típico de código y unidad de prueba 1000 LOC es de aproximadamente 50 horas de ingeniería, el ahorro en los costos de reparación de defectos eran aproximadamente 4,5 veces el costo de producción de los programas en el primer lugar.

• Base de la Fuerza Aérea Hill, cerca de Salt Lake City, Utah, es la primera organización del gobierno de Estados Unidos de tener una calificación CMM Nivel 5 [Paulk 95]. El primer proyecto TSP en Hill encontró que la productividad del equipo mejoró un 123% y el tiempo de prueba se redujo de un promedio de organización del 22% al 2,7% de la programación del proyecto [Webb 00].

• Boeing, en un gran proyecto de aeronautica, tuvo los resultados que se muestran en las figuras 8 y 9. La reducción del 94% en el tiempo de prueba del sistema resultó en una mejora sustancial en el cronograma del proyecto y permitieron Boeing para entregar un producto de alta calidad antes de lo previsto.

10 Situación y tendencias de futuro

La razón inicial para el desarrollo de la TSP era proporcionar un entorno donde los ingenieros entrenados PSP encontrarían natural para utilizar métodos disciplinados. Formación PSP por sí mismo no se había encontrado suficiente para conseguir ingenieros de utilizar constantemente los métodos [97] Ferguson. Hay varias razones por qué esto es así. En primer lugar, sin formación, los gerentes generalmente no entienden los métodos de PSP o apreciar sus beneficios. A continuación, a menudo se oponen a sus ingenieros que pasan tiempo en la planificación, haciendo comentarios personales, o la recolección y análisis de datos. En segundo lugar, el trabajo disciplinado es difícil de hacer, incluso con el apoyo y coaching. Sin esa ayuda, largos períodos de trabajo disciplinado sostenida son casi imposibles. La motivación inicial para el diseño de TSP era abordar estos problemas.

10.1 Capacitación y Apoyo

Formación TSP es ofrecido por el Software Engineering Institute (SEI) de los jefes de equipo y entrenadores de lanzamiento. Las principales necesidades de formación de ingenieros están cubiertos por los cursos de formación de PSP.

Soporte de la herramienta es también muy importante para el TSP. El SEI ha desarrollado un prototipo de herramienta que pone a disposición de los equipos que ha puesto en marcha, así como a sus socios de transición. También está desarrollando una especificación herramienta

para guiar vendedores comerciales en el desarrollo de herramientas para apoyar el proceso de TSP. Sin el apoyo de la herramienta adecuada, el volumen de los datos producidos por incluso los proyectos relativamente pequeños es casi inmanejable. (Para más información sobre los materiales y el apoyo disponibles SEI, consulte http://www.sei.cmu.edu/tsp.)

10.2 Tendencias futurasDesde gran medida se han cumplido los objetivos iniciales TSP, los esfuerzos de desarrollo próximo TSP actuales e inmediatos son hacer la transición del proceso básico TSP en uso industrial general, así como para aumentar el número de instituciones académicas que enseñan estos métodos. El foco principal del trabajo industrial está en mejorar los métodos de entrenamiento y de introducción para que los ingenieros siguen más fielmente el proceso y para fomentar el desarrollo de herramientas y entornos de apoyo TSP comerciales. Las actividades futuras incluirán la ampliación del proceso TSP a diversos tipos de equipos y para los equipos grandes. A más largo plazo, se necesitan extensiones para los equipos grandes. Los esfuerzos relacionados con académicos principalmente talleres facultad preocupación y la publicación de los resultados.

Debido a la amplia variedad de situaciones de trabajo en equipo, será necesaria una serie de procesos de TSP. El TSP básico fue diseñado para equipos de 2 a 20 miembros, pero es más eficaz para equipos de 3 a alrededor de 12 personas. El proceso TSP múltiple o TSPM, está diseñado para múltiples equipos de hasta aproximadamente 100 a 150 ingenieros. Además, se necesitarán varias extensiones TSP para equipos distribuidos que tienen miembros en diferentes ubicaciones físicas y para grandes proyectos con varios equipos en varias ubicaciones. Del mismo modo, será necesario un proceso de equipo funcional para equipos de prueba o de mantenimiento. Por último, se requerirá una extensión TSP para realmente grandes equipos de varios cientos a varios miles de ingenieros que trabajan en proyectos de gran envergadura en todo el programa. Este proceso también debe abarcar los límites organizacionales y tecnológicos.

Mientras los equipos se hacen más grandes, las relaciones entre la PSP, TSP, y CMM se volverán más importantes. Con verdaderamente grandes equipos de todo el programa, la distinción entre el equipo y el proceso de organización desaparecerá. Aquí, las actividades de CMM de organización deben ser incorporados en el proceso del equipo de la misma manera que las actividades de los procesos operativos se incorporan en la actualidad. Con equipos de TSP y TSPM más pequeñas, el proceso del equipo y el proceso de organización deben estar relacionados. Es preciso lograr que más de cerca par estas estrategias de mejora de procesos y de mostrar tanto las comunidades de CMM y TSP cómo estos dos marcos pueden complementar y apoyar el uno al otro.

En última instancia, la relación de los procesos de la organización con el proceso de negocio global se debe definir. El acoplamiento de los equipos relacionados con los productos con los

procesos de negocio requerirá algunos cambios fundamentales en el pensamiento organizacional. Sin embargo, una vez que estos procesos están debidamente relacionados, la capacidad de los equipos de TSP para capitalizar las habilidades de sus miembros y para planificar con precisión e informar sobre su trabajo va a mejorar significativamente el rendimiento global de las organizaciones de ingeniería.