El documento resume la metodología Team Software Process (TSP). TSP es un conjunto de procesos estructurados para dirigir el trabajo de equipos de software. El objetivo es maximizar la calidad y minimizar los costos mediante la integración de equipos independientes que planeen y registren su trabajo. TSP también ayuda a los gerentes a monitorear y motivar a sus equipos para alcanzar su máxima productividad.

1. Integrantes: López Rodríguez Cesar Emigdio
Vidal Miranda Iván Eduardo

2. 1. Historia de TSP
2. Que es TSP?
3. Objetivos
4. Entornos
5. Fases del ciclo de vida
6. Estructura TSP
7. Relación PSP-TSP
8. Ventajas y desventajas
9. Caso de uso
10. Herramientas
11. Bibliografía
12. Conclusiones
2

3. La versión inicial del TSP fue desarrollada por Watts
Humphrey en 1996, y el primer Reporte Técnico para
TSP fue publicado en el año 2000, patrocinado por el
Departamento de Defensa de los Estados Unidos. El
libro de Watts Humphrey llamado "Introduction to the
Team Software Process" (Addison Wesley Professional,
Massachusetts, 1999).
3

4. * Esuna 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.
* Conjunto de procesos estructurados que indican qué
hacer en cada fase del desarrollo del proyecto y muestra
cómo conectar cada fase para construir un producto
completo
4

5. * Maximizar calidad Software, Minimizar costos.
* Integrarequipos independientes de alto rendimiento
que planeen y registren su trabajo, establezcan metas,
y sean dueños de sus procesos y planes.
5

6. * Mostrar a los gerentes como monitorear y motivar a
sus equipos de trabajo y como ayudarlos a alcanzar
su máxima productividad.
* Acelerar la mejora continúa de procesos.
* Proveer de una guía para el mejoramiento en
organizaciones maduras
6

7. 7

8. • Implementación
• Lanzamiento
• Estrategia
• Planeamiento
• Requerimientos
• Diseño
• Pruebas
• Postmorten
8

9. * Se usa PSP para implementar módulos y unidades.
* Se crea el diseño detallado de los módulos y
unidades.
* Se revisa el diseño.
* Se convierte el diseño al código .
* Se inspecciona el código
* Se compilan y prueban los módulos y unidades.
* Se analiza la calidad de los módulos/unidades.
9

10. * Revisión de objetivos a perseguir.
* Asignación de equipos y roles al personal.
* Se describen las necesidades del cliente.
* Se establece las metas individuales y del
equipo.
10

11. Lanzamiento TSP, checklist para planeación
* Establecer productos y objetivos de empresa
* Establecer roles y objetivos de equipo
* Definir estrategia de desarrollo
* Hacer un plan general
* Hacer un plan de calidad
* Balancear el plan (cargas de trabajo)
* Proyecto de riesgos
* Diseñar reporte para administración
* Revisión del plan con administración
* Analisis Postmortem, nuevo equipo revisa proceso
11

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

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

14. * Crear un diseño conceptual para el producto.
* Se establece la estrategia de desarrollo: se decide
que será producido en cada ciclo.
* Se hacen estimaciones iniciales de esfuerzos y
tamaño.
* Se establece un plan de administración de la
configuración.
* Se reutiliza el plan anterior.
* Se establecen riesgos de administración
14

15. * Estima el tamaño de cada artefacto a ser
desarrollado.
* Se identifican las tareas: se estima el tiempo para
completar cada tarea; se asignan tareas a los
miembros del equipo.
* Hacer un cronograma semanal para tareas
* terminadas.
* Hacer un plan de calidad
15

16. * Se analizan las necesidades del cliente y se
entrevistan
* Se especifican los requerimientos.
* Se hace inspección de los requerimientos.
* Se diseña un plan de pruebas del sistema.
16

17. * Se crea un diseño de alto nivel.
* Se especifica el diseño.
* Se inspecciona el diseño.
* Se desarrolla una plan de pruebas de
integración
17

18. * Se construye e integra el sistema.
* Se llevan a cabo las pruebas del sistema.
* Se produce la documentación de usuario
18

19. * Análisis de resultados.
* Se escribe el reporte del ciclo.
* Se produce producen evaluaciones de pares y
* equipo.
19

20. * Es el paso final del proceso TSP.
* El Postmortem comienza con la evaluación del proceso de
calidad definido para el proyecto.
* Verificando las metas del plan de calidad:
Cuales fueron cumplidas y cuales no?
Los inconvenientes que impidieron que se cumplieran estas metas de
calidad.
Se realiza una evaluación de las metas de cada uno de los líderes.
Para cada uno de los roles.
Finalmente se evalúa la participación de cada uno de los miembros
en termino de trabajo personal y trabajo de equipo.
20

21. Se enfoca principalmente en el desarrollo de:
Análisis de resultados.
Se escribe el reporte del ciclo.
Se produce producen evaluaciones de pares y
equipo.
21

22.  Cada nuevo proyecto debe ser una oportunidad para mejorar
aprendiendo de las experiencias anteriores: Mejoramiento continuo
del proceso.
 Analizar las oportunidades de mejoramiento y definir como cambiar
las prácticas en el ciclo siguiente o en el proyecto siguiente.
Se debe evaluar:
El producto realizado.
El esfuerzo invertido para hacerlo.
El proceso seguido para hacerlo
22

23. Reporte del ciclo
Describe qué funcionó
Describe lo que se produjo,
que no funcionó y cómo
el proceso que se uso y los
hacerlo mejor en el
roles.
próximo ciclo.
Describe el desempeño de cada uno de los integrantes
del grupo con respecto a sus responsabilidades, su rol
individual y su rol de desarrollador.
23

24. Reporte de Ingeniero
* Cada ingeniero debe reportar su desempeño
personal en las actividades de desarrollo.
* Contrastar lo planeado contra lo ejecutado.
* Describir oportunidades de mejoramiento personal
24

25. Post Mortem Informe
 Los propietarios y Lista de Contactos
25

26. 26

27. 27

28. 28

29. * Ambos procesos pueden usarse juntos.
* PSP y el TSP son aplicables tanto a pequeña como a
gran escala.
* Equipos sencillos, 5 - 15 profesionales
* Multi-Equipos, muchas docenas de profesionales.
29

30. * Mejora la productividad de las personas.
* Mejora en los hábitos de programación.
* Se puede lograr una detección temprana de
defectos y riesgos lo que deriva en una
disminución de los defectos.
* Una mejora en la calidad.
* Una reducción en el ciclo de vida.
30

31. * Es necesario que cada uno de los miembros tiene
que tener el compromiso y la disciplina de seguir el
plan.
* Debe de llenar toda la documentación requerida que
incluye sus registros, planificación, las plantillas o
formularios.
* Se debe de contar con un buen conjunto de métricas
y parámetros de calidad, lo cual, para algunas
organizaciones, puede ser difícil de definir.
31

32. Dos comandos de la organización de sistemas
navales aéreos de los estados unidos integraron
el uso de la metodología de TSP y el marco de
trabajo de CMM para el progreso de nivel de
madurez 1 al 4 en 30 meses (menos de la mitad
del tiempo promedio que le toman a otras
organizaciones completar el mismo nivel de
maduración).
32

33. El Introductory Team Software Process (TSPi) es
una versión académica-baja del TSP el cual guía
graduantes y a estudiantes avanzados aplicando
los principios y practicas del TSP
33

34. * Scrum es un marco de trabajo para la gestión y
desarrollo de software basada en un proceso
iterativo e incremental utilizado comúnmente
en entornos basados en el desarrollo ágil de
software.
* Aunque Scrum estaba enfocado a la gestión de
procesos de desarrollo de software, puede ser
utilizado en equipos de mantenimiento de
software, o en una aproximación de gestión de
programas: Scrum de Scrums.
34

35. * Formato: Tapa dura (Hardcover)
Editorial: Addison-wesley - Estados Unidos
Tema: COMPUTERS / Software Development &
Engineering / General
Tags: Software engineering, Teams in the workplace
Idioma: Inglés
Páginas: 463
Peso: 839.9 gramos
Estado: Nuevo
ISBN: 020147719X
ISBN 13: 9780201477191
35

36. Al trabajar con este tipo de modelo se mejora la calidad
de los procesos y reducen los costos, esto gracias a la
generación mínima de errores y el poco tiempo en que
estos procesos se realizan
36