Sie sind auf Seite 1von 8

Team Software Process

(TSP)
Abstract

Se describirá el TSP, cómo y para quién fue desarrollado, su estructura, una breve explicación
de la metodología, resultados de una aplicación real y la versión educativa (TSPi).

¿Qué es el TSP?

Es una metodología para dirigir el trabajo de mejora y desarrollo de software además de


establecer un entorno donde el trabajo efectivo de equipo sea normal y natural

ENTORNOS

ANTECEDENTES

TSP PROSIGUE LAS ESTRATEGIAS DE CALIDAD AMERICANAS QUE INICIO:

DEMMING EN LA INDUSTRIA EN 1982,


FAGAN EN EL PROCESO DE SW 1986,
W. HUMPHREY SW, CMM 1987,
W. HUMPHREY SW, PSP 1995,
W. HUMPHREY SW, TSP 1999.
ESTRUCTURA DE TSP

Planes personales Compromiso Prioridad en calidad


Método planeación Planes agresivos Costo de calidad
Valor agregado Calidad propia Seguir el proceso
Métricas calidad Objetivos proyecto Revisión de status y calidad
Procesos definidos Plan propio Comunicación
Plan detallado
Roles
Recursos de equipo

Objetivos del TSP

 Generar un marco basado en PSP


 Desarrollar productos en varios ciclos
 Establecer estándares para medir la calidad y el comportamiento
 Proporcionar métricas para equipos
 Evaluar roles y equipos
 Guías para solución de problemas en equipos.
 Resumen:

Maximizar calidad SW
Minimizar costos
Antecedentes de trabajo en equipo

Cuando fracasa un proyecto de software es, en la mayoría de los casos, por un problema de
equipo y no por problemas técnicos.

Problemas comunes de Equipos

 Falta de liderazgo
 Falta de compromiso y ganas de cooperar
 Diferencia en contribuciones
 Falta de confianza
 Falta de calidad
 Mejoras excesivas
 Revisiones entre colegas inefectivas

Metodología TSP

Lanzamiento

Requerimientos

Diseño high level

Implementación

Integración y pruebas

Lanzamiento TSP, checklist para planeacion

1. Establecer productos y objetivos de empresa


2. Establecer roles y objetivos de equipo
3. Definir estrategía de desarrollo
4. Hacer un plan general
5. Hacer un plan de calidad
6. Balancear el plan (cargas de trabajo)
7. Proyecto de riesgos
8. Diseñar reporte para administración
9. Revision del plan con administración
10. Analisis Postmortem, nuevo equipo revisa proceso
Lanzamiento TSP, Plan de reuniones

Programa de reuniones

Los puntos 1,2,3 seran en el día 1

Los puntos 4,5,6 seran en el día 2

Los puntos 7,8 seran en el día 3

El punto 9 y el analisis postmortem seran en el dia 4 o bien al final del dia 3

Productos planeacion para lanzamiento TSP

 Objetivos de equipo por escrito


 Roles definidos
 Plan de desarrollo
 Plan de calidad
 Plan de soporte al proyecto
 Desarrollo en conjunto de planes y programas
 Plan detallado para cada ingeniero
 Plan contra riesgos
 Reporte del estado del proyecto

Producto esperado como equipo de trabajo

Los miembros establecen metas comunes y roles definidos

Equipo desarrolla estrategia consensada y todos participan en su creación

El equipo negocia el plan con la Administración

Los miembros hacen el trabajo en la forma planeada

La comunicación es libre y frecuente

Se forma grupo con cohesión, hay cooperación

Cada miembro conoce su status, se realimenta con su trabajo y tiene liderazgo que sustenta su
motivación
Lanzamiento del plan del equipo TSP

Una vez lanzado el plan lo mas importante es que los miembros sigan el plan

Liderear el equipo (guiar,motivar,disciplinar)

Seguimiento de problemas

Comunicación

Reporte administrativo

Mantener plan, seguimiento avance

Equilibrar cargas de trabajo

Manejo de la calidad

Plan de calidad

Identificar problemas de calidad

Encontrar prevenir problemas de calidad

Plan de la calidad

Se enfatiza en la administración de defectos.

Se basa en los estimados de tamaño e historicos, y estimaran los defectos en cada fase, sino
hay historico se basaran en la tabla 3.

Manejo de la calidad

Ejemplo Plan de Calidad


Nombre: x Proyecto: xx parte: xxy
Defectos Plan Actual
Compilación 140 220
En producto 7 21
Revisión código 23 52

Grafica PDF, Porcentaje de Defectos Encontrados

DATOS TIPICOS SIN TSP

DATOS TIPICOS UTILIZANDO TSP

Encontrando y Previniendo Problemas

Las Métricas de TSP indican problemas de calidad antes de la primera compilacion, las acciones
remediales son:

 Monitoree el modulo durante las pruebas y corrija


 Reinspeccione el modulo antes de la integracion y pruebas
 Que el programador retrabaje el modulo o corrija
 Redesarrolle el modulo
Resultados de una aplicación practica, Hill Air Base Force,
Utah

El miedo fue a los altos costos por la planeacion excesiva, entrevistas personales, levantamiento
de informacion pero esto mismo (TSP) reduce las mejoras al plan y el tiempo de pruebas al
grado de sostener que "la calidad es gratis".

Quizás el cambio mas grande fue la relacion administracion e ingenieros, mejoróy asi sera
siempre que la administración crea que los ingenieros trabajan efectivamente.

Además de la confianza entre administración e ingenieros, deben seguirse metodos confiables y


apropiados, reportando constantemente a administración.

Administración deberá entender que los ingenieros saben mas del software y que se ocuparan
solamente de que el equipo de software siga el método disciplinadamente.

Numeros:

Productividad aumento un 123%

Tiempo de prueba redujo de 22% a 2.7%

Cíclo de vida de TSP (TSPi)

 Es una serie de ciclos que inician con la declaración de las necesidades del producto y
terminan con la entrega del producto final
 A continuación presentaremos una representación gráfica con diagramas de actividades
de TSP en su versión educativa conocida como TSPi.

Cíclo de TSPi dividido en fases

 Lanzamiento
 Estrategia
 Planeación
 Requerimientos
 Diseño
 Implementación
 Prueba
 Postmortem

Experiencia, AMCIS

 Lo mejor: definición de roles y sus actividades, desarrollo incremental en varios ciclos.


 Lo más difícil: planeación y recaudación de métricas. Cumplimiento de compromisos.
Bibliografía

 "The Capability Maturity Model Guidelines for Improving the Software Process",
Carnegie Mellon University, Software Engineering Institute, Addison-Wesley, 1994.
 ISO/IEC15504, Reporte Técnico.
 www.sei.cmu.edu/CMMI
 Jacobson I., G. Booch, J. Rumbaugh, "The Unified Software Development Process",
Addison-Wesley, 1999.
 www.rational.com
 Watts S. Humphrey, "A Discipline for Software Engineering", SEI Series in Software
Engineering, Addison Wesley, 1995.
 Watts S. Humphrey, "Introduction to Personal Software Process", SEI Series in Software
Engineering, Addison Wesley, 1997.
 Watts S. Humphrey, "Introduction to Team Software Process", SEI Series in Software
Engineering, Addison Wesley, 2000.
 www.dynamics.unam.edu/TSPi

Das könnte Ihnen auch gefallen