2.2.

1 PSP y TSP
PSP

Es un conjunto de prcticas disciplinadas para la gestin del tiempo y mejora de la productividad personal de los programadores o ingenieros de software,
en tareas de desarrollo y mantenimiento de sistemas. Est alineado y diseado para emplearse en organizaciones con modelos de procesos CMMI o ISO
15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the
Personal Software Process" se dirige ahora a ingenieros juniors.
Se puede considerar como la gua de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez
o de capacidad de procesos que implica la medicin cualitativa y mejora de procesos.
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesin por la toma de datos y elaboracin de
tablas. El PSP se orienta el conjunto de reas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.
PSP, es uno de los 3 vrtices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organizacin, los otros 2 son CMM y TSP.
El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software, concentrndose en las practicas de trabajo de los
ingenieros en una forma individual, enseando como manejar la calidad desde el principio de un producto. PSP son nuestras propias mtricas, que
permiten estructurar y ordenar nuestro trabajo del da a da (no solo de desarrollo de software, esto lo voy a explicar mas adelante). El resultado de nuestro
trabajo, adems puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es comandado por un sistema de gestin de la
configuracin y por supuesto, un Jefe de Proyecto quien evala los resultados y avances de los miembros del equipo.

TSP
Team Software Process (TSP) es un mtodo de establecimiento y mejora del trabajo en equipo para procesos software.
TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la
organizacin pueda establecer prcticas de ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad. Est formado por dos
componentes primarios que abarcan distintos aspectos del trabajo en equipo:

Formacin del equipo de trabajo.

Gestin del equipo de trabajo.

Existen diferentes metodologas para la mejora de procesos, la mayora de ellas se basa en la mejora de los procesos que dan como resultado un servicio
o producto. El TSP busca integrar un equipo que tenga como punto de partida la unificacin del mismo, para poder llevar a cabo todos aquellos
procedimientos que puedan realizar mejora a los procesos que desarrollan.
El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo
de software de calidad. TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con
el fin de que la organizacin pueda establecer prcticas de ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad.
TSP es una solucin basada en procesos para resolver problemas de negocio, tales como:

Predictibilidad de costo y tiempo

Mejora de productividad

Ciclos de desarrollo y mejora de calidad de productos.

Caractersticas de los grupos eficaces:

Miembros expertos en papeles de liderazgo y pertenencia.

Relaciones tranquilas y establecidas entre los miembros.

Los miembros se sienten atrados por el grupo y son fieles.

Los valores y metas del grupo son los de sus integrantes

Los miembros estn motivados por hacer lo que puedan por el grupo.

La interaccin y toma de decisiones tiene lugar en el ambiente adecuado.

El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada miembro a adquirir su pleno potencial.

Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas.

Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.

Existe una atmsfera de creatividad.

El grupo conoce el conformismo constructivo y se sirve de l.

Existe gran motivacin para iniciar y recibir las comunicaciones.

Los miembros son flexibles y adaptables en sus metas y actitudes.

Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten seguros al tomar decisiones que les parecen apropiadas al
entender la filosofa de la operacin.

Sus orgenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tena en el mbito industrial. PSP result muy efectivo
para que los ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus habilidades de estimacin y la reduccin de los
defectos introducidos en los productos sin afectar a su productividad, pero PSP slo se enfocaba en las fases de desarrollo de software (diseo y pruebas
unitarias); la aplicacin que lo ingenieros hicieron del PSP dentro de las empresas resulto en prcticas no satisfactorias.
Por tal motivo, Watts Humphrey desarroll el TSP, el cual consideraba como parte importante, adems de lo previsto por el PSP, los requisitos, las pruebas
de integracin, la documentacin y otras actividades tpicas en todo proyecto de desarrollo, de igual manera inclua actividades como los roles de equipo,
interrelaciones dentro de la organizacin y la definicin de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organizacin.

Los Roles (responsabilidades) en los equipos en STP son:

Lder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se plane. Realiza
los reportes semanales del avance del equipo.

Gestor de desarrollo: Gua al equipo en el diseo y desarrollo del producto.

Gestor de Planificacin: Apoya y gua al equipo en la planificacin y seguimiento del trabajo.

Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a establecer y administrar el plan de calidad. Genera

estndares para obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto generado.

Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de software y ayuda a dar a conocer la tecnologa y
en las necesidades de apoyo administrativo. Administra el plan de configuracin

Es necesario que los ingenieros que usan TSP estn formados en PSP. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del
proceso de desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de manera importante el tiempo de pruebas. Con un testing
ms corto, el ciclo completo se reduce.
A diferencia de otros mtodos, TSP mejora el desempeo tanto de equipos como individuos, es disciplinado y gil, provee beneficios inmediatos y
medibles y acelera las iniciativas de mejora de procesos organizacionales.
En las fases del Ciclo TSP se planea el nmero de ciclos. Dentro de cada ciclo se realiza:

Lanzamiento

Estrategia

Plan

Requisitos

Diseo

Implementacin

Pruebas

Postmortem

Los objetivos que tiene el TSP son:

Maximizar calidad software, minimizar costos.

Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y san sueos de sus procesos y planes.

Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su mxima productividad.

Acelerar la mejora continua de monitoreo.

Proveer de una gua para e mejoramiento en organizaciones maduras

Sus entornos son:

CMM- Administracin.

TSP- Equipo Ingenieros.

PSP-Ingeniero.

https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-de-software/2-2-1-psp-y-tsp

Team Software Process

(TSP)
Abstract
Se describir el TSP, cmo y para quin fue desarrollado, su estructura, una breve explicacin de la metodologa, resultados de
una aplicacin real y la versin educativa (TSPi).

Qu es el TSP?
Es una metodologa para dirigir el trabajo de mejora y desarrollo de software adems 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
Mtodo planeacin
Valor agregado
Mtricas calidad
Procesos definidos

Compromiso
Planes agresivos
Calidad propia
Objetivos proyecto
Plan propio
Plan detallado
Roles
Recursos de equipo

Prioridad en calidad
Costo de calidad
Seguir el proceso
Revisin de status y calidad
Comunicacin

Objetivos del TSP

Generar un marco basado en PSP

Desarrollar productos en varios ciclos

Establecer estndares para medir la calidad y el comportamiento

Proporcionar mtricas para equipos

Evaluar roles y equipos

Guas para solucin de problemas en equipos.

Resumen:
Maximizar calidad SW
Minimizar costos

Antecedentes de trabajo en equipo

Cuando fracasa un proyecto de software es, en la mayora de los casos, por un problema de equipo y no por problemas tcnicos.

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

Metodologa TSP
Lanzamiento
Requerimientos

Diseo high level

Implementacin
Integracin y pruebas

Lanzamiento TSP, checklist para planeacion

1. Establecer productos y objetivos de empresa
2. Establecer roles y objetivos de equipo
3. Definir estratega 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. Disear reporte para administracin
9. Revision del plan con administracin

10. Analisis Postmortem, nuevo equipo revisa proceso

Lanzamiento TSP, Plan de reuniones

Programa de reuniones
Los puntos 1,2,3 seran en el da 1
Los puntos 4,5,6 seran en el da 2
Los puntos 7,8 seran en el da 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 creacin
El equipo negocia el plan con la Administracin
Los miembros hacen el trabajo en la forma planeada
La comunicacin es libre y frecuente
Se forma grupo con cohesin, hay cooperacin

Cada miembro conoce su status, se realimenta con su trabajo y tiene liderazgo que sustenta su motivacin

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
Comunicacin
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 administracin de defectos.
Se basa en los estimados de tamao 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

Compilacin

140

220

En producto

21

Revisin cdigo

23

52

Grafica PDF, Porcentaje de Defectos Encontrados

DATOS TIPICOS SIN TSP

DATOS TIPICOS UTILIZANDO TSP

Encontrando y Previniendo Problemas

Las Mtricas 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 aplicacin 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".
Quizs el cambio mas grande fue la relacion administracion e ingenieros, mejory asi sera siempre que la administracin crea
que los ingenieros trabajan efectivamente.
Adems de la confianza entre administracin e ingenieros, deben seguirse metodos confiables y apropiados, reportando
constantemente a administracin.
Administracin deber entender que los ingenieros saben mas del software y que se ocuparan solamente de que el equipo de
software siga el mtodo disciplinadamente.
Numeros:
Productividad aumento un 123%

Tiempo de prueba redujo de 22% a 2.7%

Cclo de vida de TSP (TSPi)

Es una serie de ciclos que inician con la declaracin de las necesidades del producto y terminan con la entrega del
producto final

A continuacin presentaremos una representacin grfica con diagramas de actividades de TSP en su versin educativa
conocida como TSPi.

Cclo de TSPi dividido en fases

Lanzamiento

Estrategia

Planeacin

Requerimientos

Diseo

Implementacin

Prueba

Postmortem

Experiencia, AMCIS

Lo mejor: definicin de roles y sus actividades, desarrollo incremental en varios ciclos.

Lo ms difcil: planeacin y recaudacin de mtricas. Cumplimiento de compromisos.

http://ingsw.ccbas.uaa.mx/sitio/images/material/tsp.htm
http://es.slideshare.net/DanielNuez8/savedfiles?s_title=modelo-tsp&user_login=ivanvidal1

Integrando TSP y CMMI: Lo mejor de dos mundos

Autor:
Oscar Mondragn Campos
Publicado en :
SG #31 (Febrero - Abril 2011)
Seccin:
Procesos de desarrollo de software
10

El desarrollo de software es una actividad joven, comparada con otras ingenieras. En sus inicios, sta disciplina se desarroll con
base en habilidades personales y con la firme creencia de que su naturaleza era artesanal. La falta de procesos, la indisciplina
personal y la falta de visin para conceptualizar al desarrollo de software como una ingeniera se materializ en la crisis del software
en los aos 70 y desde entonces se han tomado acciones para cambiar las malas prcticas y considerar al desarrollo de software
como una ingeniera.

Se integraron prcticas universales de la administracin de proyectos y se refinaron ciclos de vida. Adicionalmente, la IEEE creo la
Certificacin para Profesionistas de Desarrollo de Software (CSDP), liber el libro del conocimiento de ingeniera de software
(SWEBOK) y en conjunto con la ACM hicieron el diseo curricular de la carrera de Ingeniero de Software en el 2004.
Desafortunadamente, los esfuerzos no han sido suficientes. En el reporte Resumen del Caos 2009 del Grupo Standish se indica
que tan solo el 32% de los proyectos evaluados fueron exitosos, es decir: fueron entregados en tiempo, en presupuesto y con la
funcionalidad requerida.
Otra lnea de accin para aliviar el problema ha sido el promover la mejora de procesos de software en las organizaciones a travs
del estndar ISO 9000, el modelo TSP y el modelo CMMI.
Este artculo describe cmo el TSP y el CMMI estn apoyando a desarrollar software de manera ms disciplinada.

Proceso para equipos de software (TSP)

El TSP (Team Software Process) es una estrategia enfocada a procesos para ayudar a los equipos de software a mejorar su
habilidad para producir software de alta calidad en los tiempos y costos comprometidos [1]. La mejora en el desempeo
organizacional se logra mejorando el desempeo personal y posteriormente el del equipo asignado a un proyecto.
El TSP es un marco de trabajo de procesos diseado especficamente para equipos de software. Para lograr los beneficios, TSP
requiere que los miembros del equipo hayan sido entrenados en el Proceso Personal de Software (PSP, por sus siglas en ingls). El
PSP es un marco de trabajo personal que ayuda a los ingenieros hacer su trabajo de desarrollo de software de manera disciplinada.
El PSP incluye un conjunto de mtodos, plantillas y procesos que ayudan a los ingenieros a planear, medir y administrar su trabajo.
Cuando el PSP es usado en equipos de TSP, la meta es producir productos con cero defectos en el tiempo y costo planeado [2].
El PSP se desarroll considerando los siguientes principios de calidad y planeacin:

Cada ingeniero debe planear su trabajo con base en sus datos histricos personales.

Los ingenieros deben medir su trabajo y analizar los resultados para mejorar su desempeo.

Los ingenieros deben sentirse personalmente responsables de la calidad de sus productos buscando decididamente hacer
trabajo de calidad.

Es ms eficiente prevenir los defectos que encontrarlos y corregirlos.

La manera correcta es siempre la manera ms rpida y econmica de hacer el trabajo.

La importancia del entrenamiento y el marco de trabajo personal del PSP es que provee a los ingenieros un proceso disciplinado,
mtricas de desempeo, habilidades de planeacin y estimacin y habilidades de administracin de la calidad.
El TSP es un proceso diseado para equipos de software auto-dirigidos y de alto desempeo, ayudndolos a planear su trabajo,
negociar compromisos con la gerencia, dar seguimiento cabal a sus compromisos y producir productos de calidad mientras mejoran
su rendimiento. El marco de trabajo de TSP incluye roles, plantillas, procesos, guas, especificaciones y listas de chequeo. La Figura
1 muestra el marco de trabajo con algunos ejemplos de los elementos de proceso.

Figura 1. Elementos de proceso de TSP.

El TSP tiene caractersticas propias que lo distinguen de otras metodologas. Por ejemplo:

Usa equipos auto-dirigidos con base en el estilo de administracin de Peter Drucker (administracin del conocimiento) junto
con un coach que ayuda a desarrollar las habilidades de trabajo en equipo en los individuos.

Tiene procesos operacionales flexibles que permiten a los equipos adaptar los procesos, contando adems con un marco de
trabajo de mtricas que soporta a su proceso e incluye tcnicas para la administracin de la calidad usando revisiones
personales, inspecciones e ndices de desempeo de la calidad.

Usa planes detallados con actividades no mayores a 10 hrs en periodos de 3-6 meses y establece juntas de cierre
(postmortems) para finales de ciclo o de proyecto.

Utiliza lanzamientos de proyectos de 3.5 das para planear las actividades y para integrar a los miembros del equipo.

Cada miembro tienen asignado roles, metas y riesgos del proyecto.

Los calendarios del equipo son desglosados en calendarios personales que son ajustados con base en datos personales.

La fortaleza de la tcnica radica en la sinergia del equipo auto-dirigido comprometido con un calendario y un plan de calidad. La
Figura 2 ilustra las principales caractersticas de ambas metodologas [3].

Figura 2. Caractersticas de PSP y TSP.

Las desventajas de ests metodologas estn ligadas a sus fortalezas: El PSP se desarroll para ayudar a los ingenieros de software
hacer productos de calidad, sin embargo, se requiere de un cambio organizacional que no puede ser sustentado por los ingenieros
(de abajo hacia arriba). As mismo, los equipos de TSP fueron concebidos como entidades independientes careciendo de una
infraestructura organizacional para la administracin de las mejoras y el mantenimiento de los procesos. Una solucin radica en
implementar un grupo de mejora despus de los pilotos de TSP para que los procesos estndares y la mejora de procesos fluyan de
manera natural.

Modelo de Capacidad y madurez integrado (CMMI)

El Modelo de Capacidad y Madurez Integrado del SEI (CMMI) provee un camino para la mejora de procesos, el cual proporciona a
las organizaciones con elementos esenciales para lograr procesos efectivos. El modelo puede ser usado en un proyecto o en una
divisin dentro de la organizacin. CMMI [4] ayuda a integrar reas funcionales, establecer objetivos de mejora y sus prioridades,
guiar procesos de calidad e incrementar la eficiencia en el desarrollo y mantenimiento de productos y servicios.
CMMI se enfoca en los procesos de la organizacin y considera como premisa que la calidad de un sistema es fuertemente
influenciada por la calidad de los procesos usados para adquirirlos, desarrollarlos y mantenerlos.
El modelo CMMI [4] ha ayudado a las organizaciones a:

Ligar explcitamente las actividades de administracin e ingeniera con los objetivos de negocio.

A desarrollar funciones organizacionales adicionales que son crticas para sus productos y servicios.

Incorporar lecciones aprendidas en los proyectos a travs de la mejora continua de sus procesos.

El reporte del SEI Process Maturity Profile del ao 2010, indica que 5499 organizaciones han sido evaluadas en el modelo de
referencia CMMI en los continentes de Asia, Europa, frica y Amrica.
El modelo CMMI tiene tres constelaciones: desarrollo, adquisiciones y servicios, las cuales son colecciones de componentes CMMI
que incluyen un modelo de referencia, material de entrenamiento y materiales de evaluacin relacionados a un rea de inters en
particular. CMMI tiene dos representaciones: continua y por etapas. Ambas representaciones incluyen 22 reas de proceso y ayudan
a las organizaciones a llevar procesos pobremente definidos a procesos controlados estadsticamente.
La representacin por etapas de CMMI incluye 5 niveles de madurez y cada uno de ellos tiene asignadas reas de proceso. CMMI
DEV provee guas para medir, monitorear y planear la construccin de productos.
En la Figura 3 se muestran los niveles de madurez, su enfoque y las reas de proceso asignadas (predeterminadas).

Figura 3. Representacin por etapas de CMMI.

La representacin por etapas ya tiene predefinidas las reas de proceso asignadas a cada nivel y es la representacin ms usada a
nivel mundial. Las reas de proceso indican caractersticas tcnicas de un rea de conocimiento en particular. Un proceso
administrado incluye [4]: la inclusin de una poltica, planea sus actividades, les asigna recursos y responsables, capacita y
desarrolla habilidades del personal que los ejecuta, administra los productos de trabajo que produce, considera a los involucrados
relevantes, monitorea y controla los pasos del proceso, hace revisiones de adherencia a procesos y productos, y retroalimenta a la
alta gerencia sobre el estatus del proceso.
El modelo CMMI es un conjunto de buenas prcticas para implementar procesos eficientes y efectivos que han sido probadas por la
industria. Es importante entender que CMMI es un modelo de referencia, CMMI no es un conjunto de procesos. Lo importante de
una implementacin de CMMI es la interpretacin del modelo a la realidad de la empresa ya que los nuevos procesos
implementados deben de agregar valor y resolver los problemas operativos de la empresa. Un aspecto frecuentemente ignorado en
las implementaciones del modelo es el reconocer que una implementacin de procesos es en esencia un cambio organizacional.

Para que la iniciativa de mejora sea exitosa, sta se debe administrar como un proyecto de alta prioridad en la organizacin con
recursos y presupuestos asignados desde su incepcin. La metodologa IDEAL del SEI puede ser usada para la administracin de la
mejora de procesos, la cual debe ser considerada como una actividad continua. Los costos asociados a una implementacin del
CMMI son altos porque se deben desarrollar nuevos procesos, plantillas, material de entrenamiento y herramientas. La larga
duracin de la implementacin de procesos dificulta presentar reportes tempranos de retorno de inversin, principalmente en el nivel
2 de madurez. La falta de patrocinio, recursos, habilidades tcnicas y asignacin apropiada de responsabilidades puede terminar en
falsos inicios de mejora.
Con respecto al desempeo de los procesos implementados con CMMI, depende de lo siguiente:

El tipo de implementacin realizada.

Experiencia de la gente involucrada.

Enfoque hacia obtener el nivel vs. mejorar la operacin.

Magnitud de recursos y tiempos asignados.

La cultura de calidad de la empresa al inicio del proyecto.

Integrando TSP y CMMI

TSP y CMMI son dos tecnologas del SEI enfocadas a la mejora de procesos de las organizaciones. Ambas comparten las mismas
metas: ayudar a las empresas a desarrollar productos de calidad en los tiempos y presupuestos asignados.
Por un lado, CMMI es un modelo de referencia y por otro lado, TSP es una implementacin de procesos de alto rendimiento que es
utilizada por equipos auto-dirigidos. Mientras CMMI considera aspectos e infraestructura organizacional, TSP se enfoca en
desarrollar disciplina de procesos y una cultura de calidad a nivel personal (a travs de PSP) as mismo construye equipos de alto
desempeo.

Una de las fortalezas de TSP, es la calidad de los productos desarrollados: El promedi de errores reportado despus de la entrega
del producto es de 0.06 por cada mil lneas de cdigo (KLOC) nuevas o modificadas mientras que el promedio de empresas CMMI
N5 es 1.05 [04].
El CMMI es un cmo, mientras el TSP es un producto con elementos de procesos, materiales de entrenamiento y un marco de
trabajo para mtricas, planeacin y calidad. Las debilidades de TSP se pueden resolver con el enfoque organizacional de CMMI. El
riesgo de implementar procesos burocrticos que no aportan valor agregado a la empresa se mitiga usando TSP.
En lugar de seguir considerando estas tecnologas como rivales e independientes, las tecnologas se deben combinar tomando
ventaja de la sinergia que se produce [5]. La idea principal de combinar TSP y CMMI es reducir el tiempo para alcanzar CMMI nivel 3
(de 4 aos a 18 meses) obteniendo la institucionalizacin de procesos definidos que son usados en equipos auto-dirigidos
comprometidos con los planes, con un fuerte enfoque personal en la calidad, con ciclos de prueba cortos, teniendo alto desempeo,
y haciendo uso de una infraestructura para administrar la mejora continua [5].
La idea de combinarlos es apoyada por el nivel de cobertura que brinda TSP sobre CMMI. La Figura 4 muestra los resultados de un
mapeo de TSP con CMMI indicando el porcentaje de prcticas especificas de CMMI con el que cubre TSP: 85% para el nivel 2; 78%
para el nivel 3; 54% para el nivel 4 y 25% para el nivel 5 [04]. El estudio tambin comenta que el 80% de las prcticas especificas de
CMMI nivel 2 y 3 son implementadas por TSP.

Figura 4. Prcticas de CMMI consideradas por TSP.

Uno de los promotores de combinar TSP y CMMI fue la Secretaria de Economa Mexicana en el 2008, a travs de su programa
PROSOFT (Programa del Desarrollo del Sector de Servicios de Tecnologas de Informacin) quien reconoce la fortaleza de ambos
modelos y le pide al SEI que desarrolle una versin extendida del TSP que cumpla con la mayora de prcticas de CMMI nivel 3.
El SEI extendi el TSP para poder cubrir con algunas de las prcticas especficas de CMM nivel 3 que no haban sido consideradas
en TSP. A la versin extendida se le llam 2008.09.TSPm.
En noviembre del 2009, la empresa SILAC en Zacatecas, Mxico, iniciaron un piloto del TSP-CMMI Accelerated Improvement
Method (TC AIM). La empresa haba implementado TSP en algunos proyectos [5].
La primera actividad realizada fue crear el Grupo de Ingeniera de Procesos (EPG) para administrar las actividades de Mejora de
Procesos de Software (SPI) a nivel organizacional. El EPG fue lanzado como equipo TSP para que las actividades de SPI fueran
administradas con el mismo rigor y disciplina de un proyecto TSP, ver Figura 5.

Figura 5. Integrando TSP y CMMI.

El TSPm es una versin de TSP para administrar proyectos con mltiples equipos, ver Figura 6. Los nuevos roles de TSPm definen
responsabilidades para:

Crear y administrar el Conjunto Estndar de Procesos Organizacionales (OSSP, por sus siglas en ingls).

Establecer un canal para reportar y/o escalar los asuntos de no conformidad a procesos.

Establecer y mantener el entrenamiento organizacional.

Dar seguimiento a las actividades del coach.

Establecer y mantener los procesos definidos del proyecto.

El TSPm tambin incluye nuevos elementos de procesos para cubrir ms prcticas de CMMI de la administracin de procesos y
riesgos, aseguramiento de calidad, anlisis de decisin y administracin de la configuracin.
Durante el Workshop anual de TSP en septiembre 2010, se anunci la liberacin del Mtodo Acelerado de Mejora (AIM). El SEI
liber en octubre 2010 el TSP+ a sus partners con coach TSP certificado. El TSP+ es la nueva versin del TSPm descrito en este
artculo. El TSP+ es la versin de TSP usada en el AIM.

Conclusiones
TSP y CMMI son estrategias complementarias que combinadas proveen una poderosa sinergia, porque a nivel personal se
establece una forma de trabajo disciplinada enfocada a la calidad y con un marco de trabajo para mtricas y estimaciones. A nivel
equipo, se establecen equipos de desarrollo de software auto-dirigidos que se comprometen a planes de trabajo balanceados y
alcanzables y que le dan seguimiento a planes agresivos de calidad. A nivel organizacional, se genera la infraestructura para
administrar la mejora continua, se establece una librera con procesos estndares, y se construyen las bases para la
institucionalizacin de procesos definidos.
Combinar TSP y CMMI, sin embargo, no es una tarea fcil. Cuando un profesional de una de estas estrategias trata de asimilar la
otra, podra confundirse y malinterpretar los conceptos y filosofas. Adems, es muy importante tener asesora objetiva y calificada
durante la implementacin porque stos marcos de referencia han sido errneamente percibidos como opuestos.
Independientemente del riesgo arriba mencionado, vale la pena combinar TSP y CMMI para aplicar procesos de alto desempeo en
equipos auto-dirigidos, que son administrados y mejorados organizacionalmente y que permiten entregar productos de alta calidad
en los tiempos y costos estipulados.
La versin completa de este artculo se escribi para el V Taller de Calidad en las Tecnologas de la Informacin y las
Comunicaciones, Cuba, 2011.

Figura 6. Componentes de TSPm.

Bio:
El Dr. Oscar Mondragn colabora en el SIE Center como consultor de modelos de calidad de software.

Si deseas dejar un comentario, por favor haz login

http://sg.com.mx/revista/45/integrando-tsp-y-cmmi-lo-mejor-dos-mundos#.VOE8uf_651U