Metodología para dirigir el trabajo de mejora y desarrollo de software

1. Team Software Process (TSP)
Sistemas de Calidad en TI

2. INTEGRANTES:
CHAVEZ MORENO SYLVIA
GONZALEZ ENCINAS CUAUHTEMOC
SEPTIEMBRE 2011

3. Índice
• Definición TSP.
• Estructura TSP.
• Entornos.
• Objetivo.
• Ventajas y desventajas
• Fases.
• Informes Postmortem.
• Organización TSP.

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

5. E
S
T
R
U Planes personales Compromiso Prioridad en calidad
Método planeación Planes agresivos Costo de calidad
C Valor agregado Calidad propia Seguir el proceso
Métricas calidad Objetivos proyecto Revisión de status y calidad
T Procesos definidos Plan propio Comunicación
U Plan detallado
Roles
R Recursos de equipo
A
D
E
T
S
P

6. TSP - Entornos

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

8. Ventajas
• Mejora la productividad de las personas.
• Mejora en los hábitos de programación.
• Detección temprana de defectos y riesgos.
• Mejora en la calidad

9. Desventajas
• Los miembros tiene que tener el compromiso y
la disciplina de seguir el plan.
• Debe de llenar toda la documentación
requerida.
• Se debe de contar con un buen conjunto de
métricas y parámetros de calidad.
• Cada miembro debe de estar entrenado en el
PSP.

10. Fases del Ciclo de Vida TSP
Lanzamiento - Launch
• ™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.

11. Estrategia – Strategy
• ™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 .

12. Requerimientos – Requirements
• ™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.

13. Diseño - Design
• ™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

14. Implementación – Implementation
• ™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.

15. Pruebas – Test
• ™Se construye e integra el sistema.
• ™Se llevan a cabo las pruebas del sistema.
• ™Se produce la documentación de usuario.

16. Después de la Muerte – Postmortem
• ™Análisis de resultados.
• ™Se escribe el reporte del ciclo.
• ™Se producen evaluaciones de pares y
• equipo.

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

18. Signoffs
Historial de revisiones

19. Los procesos que fueron más efectivos
Los procesos que tuvieron un efecto negativo sobre el proyecto

20. Organización de TSP

21. 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
• Análisis Postmortem, nuevo equipo revisa proceso

22. Bibliografías:
• http://eisc.univalle.edu.co/materias/Material_Desarrollo_Software
/PSP-TSP.pdf
http://ingsw.ccbas.uaa.mx/sitio/images/material/tsp.htm