Unidad 1. Introduccion a TSP

Desarrollo de software en equipo (TSP ) Unidad 1. Introduccin a TSP

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Ingeniera en Desarrollo de Software

6 Semestre

Programa de la asignatura:

Desarrollo de software en equipo (TSP)

Unidad 1. Introduccin a TSP

Clave:

15143636

Universidad Abierta y a Distancia de Mxico


Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software 1

ndice

1. Introduccin a TSP ......................................................................................................... 2

Presentacin de la unidad .................................................................................................. 2

Propsitos .......................................................................................................................... 3

Competencia especfica ..................................................................................................... 3

1. 1. Proceso de Desarrollo de Team Software Process (TSP) .......................................... 3

1.1.1. Principios y objetivos de TSP ................................................................................... 6

1.1.2. Estrategia de TSP .................................................................................................... 7

1.1.3. Equipo TSP .............................................................................................................. 8

1.2. Estructura del Team Software Process (TSP) ............................................................. 9

1.2.1. Disciplina de equipo ............................................................................................... 11

1.2.2. Disciplina de administracin ................................................................................... 12

1.2.3. Disciplina de ingeniera ........................................................................................... 12

1.3. Ciclo de vida del Team Software Process (TSP) ....................................................... 13

1.3.1. Fase de lanzamiento .............................................................................................. 14

1.3.2. Fase de estrategia .................................................................................................. 22

1.3.3. Fase de planeacin ................................................................................................ 25

1.3.4. Fase de requerimientos .......................................................................................... 26

1.3.5. Fase de diseo ....................................................................................................... 27

1.3.6. Fase de implementacin ......................................................................................... 28

1.3.7. Fase de pruebas..................................................................................................... 29

1.3.8. Fase post mrtem ................................................................................................... 31

Cierre de la unidad ........................................................................................................... 33

Para saber ms ................................................................................................................ 34

Fuentes de consulta ......................................................................................................... 34



1. Introduccin a TSP

Presentacin de la unidad

Bienvenido a la asignatura Desarrollo de software en equipo TSP (Team Software Process),

la cual forma parte del octavo semestre de la igeniera en Desarrollo de Software.

La metodologa PSP (Personal Software Process) est orientada a un contexto individual del

ingeniero en desarrollo de software, mientras que el TSP se enfoca en los equipos y roles de

trabajo. Es necesario contar con la metodologa PSP, porque gua a cada individuo a

alcanzar sus objetivos personales como parte de un proyecto de desarrollo de software, pero

sin olvidar que lo ms importante es la colaboracin, la retroalimentacin entre los miembros

del equipo de desarrollo y, por supuesto, conseguir los objetivos trazados al inicio del

proyecto.

En la Unidad 1. Introduccin a TSP, aprenders los elementos, objetivos y principios en los

cuales se basa esta metodologa, as como su estrategia y estructura, que se aplica a todo el

ciclo de desarrollo del proyecto.

Relacin entre PSP y TSP

Contenido de la imagen basado en Tuya, Javier y otros, (2007). Imagen basada en Dreamstime (2013).



Propsitos

Al trmino de esta unidad logrars:

Identificar los elementos y objetivos que componen la metodologa TSP.

Comprender la relacin que existe con PSP.

Conocer la estructura TSP.

Comprender la estrategia que sigue TSP para el desarrollo de sistemas de calidad.

Competencia especfica

Identificar la metodologa Team Software Process (TSP) para comprender los

conceptos principales y el ciclo de vida a partir del marco contextual del desarrollo de

software.

1. 1. Proceso de Desarrollo de Team Software Process (TSP)

El Team Software Process (TSP) fue creado por Watts Humphrey en 1996. Es un proceso y

una metodologa de desarrollo de software en equipo, que guan a los ingenieros para

asegurar la calidad en las diferentes etapas del ciclo de vida de desarrollo de software y,

principalmente, la productividad de los equipos de trabajo integrados por ingenieros,

administradores y desarrolladores de software (Gomez y Ania, 2008). Cuando se habla de

objetivos de un proyecto de desarrollo de software, hay uno en particular que se debe

cumplir: el tiempo del proyecto puede rebasar lo planeado. Para esto, implementar la

metodologa TSP dentro de una organizacin ayuda a tener una mtrica exacta de costos.

Tambin la experiencia de proyectos pasados cuenta mucho.

Para comprender la metodologa TSP es necesario saber qu es un proceso de desarrollo

de software (la primera se realiza dentro del segundo). Tambin denominado ciclo de vida

de desarrollo de software, consiste en una estructura que indica las etapas que debe

cumplir todo desarrollo de software. Existen muchos modelos de ciclo de vida; TSP puede

utilizar cualquiera, pero el de cascada es el ms utilizado. El 90% de los que existen en la

actualidad estn basados en l.

El modelo en cascada indica que todo desarrollo basado en l debe cumplir con las

siguientes fases:

Anlisis y definicin de requerimientos: es muy importante conocer qu desea el

cliente, para esto se hace el levantamiento de requerimientos, que consiste en visitas



al cliente para saber cmo quiere que funcione el sistema solicitado. Despus de

esto, los analistas e ingenieros de software crean las especificaciones del sistema.

En esta fase se integra la documentacin requerida para el arranque del proyecto, la

cual cambiar de acuerdo con la metodologa propuesta; pero nunca deben de faltar

los documentos donde se muestren los objetivos, visin, roles, puestos y

requerimientos del sistema a desarrollarse.

Diseo del sistema y el software: los analistas e ingenieros de software establecen

una arquitectura completa del sistema, el diseo nos muestra cmo va a funcionar y

si se va a comunicar con otro sistemas.

Implementacin y prueba de unidades: prcticamente, en esta fase se desarrolla

por completo el sistema.

Integracin y pruebas del sistema: aqu se observa ya un producto terminado. Las

personas designadas en el rea de pruebas y calidad de software revisan que el

sistema no tenga fallos; si los hay, se devuelve el producto a los desarrolladores para

que hagan las modificaciones correspondientes.

Funcionamiento y mantenimiento: una vez que el sistema fue aprobado por las

personas designadas en el rea de calidad y pruebas, se le entrega al cliente la

primera versin terminada del sistema, para que la pruebe en el rea de produccin y

verifique el correcto funcionamiento. Si hay nuevos requerimientos se regresa a la

primer fase para realizar las mejoras para el sistema (Sommerville, 2006).

En la siguiente figura se muestra una representacin del modelo en cascada:



Figura 1. Modelo en cascada (Sommerville, 2006).

Se dice que el TSP es un proceso de desarrollo porque cumple con esta estructura, pero con

fases propias que ms adelante se explicarn.

Se recomienda el uso de TSP en grupos de 2 a 20 personas y en desarrollos de sistemas

que sean a gran escala.

El TSP se centra en la administracin de proyectos, en la construccin de los equipos de

trabajo de acuerdo a los roles y en el perfil de cada persona que se necesita para los

distintos puestos dentro del proyecto.

En un proyecto de desarrollo de software, se selecciona la cantidad de personal requerida

para los puestos de acuerdo a lo robusto que sea el sistema, pero los puestos necesarios

que propone la metodologa TSP son: lder de equipo, administrador de desarrollo,

administrador de planeacin, administrador de calidad de proceso y administrador de

Definicin de requerimientos

Diseo del sistema y del

software

Implementacin y prueba de unidades

Integracin y prueba del

sistema

Funcionamiento y mantenimiento



soporte, cargos que se explicarn con ms detalle en el Tema 1.3. Ciclo de vida del Team

Software Process.

TSP se enfoca en la gestin del equipo de trabajo, y el PSP en la calidad, pero no de todo el

proceso de desarrollo ni del equipo, sino de la calidad y la gestin individual, especialmente

en los desarrolladores de software, para tener una mtrica exacta de su productividad y, con

base en esto, mejorar la calidad en su trabajo.

Piattini (2011) afirma que el TSP se basa en los siguientes elementos:

Administracin autodirigida para equipos de trabajo. Como ya se mencion, a

comparacin de PSP, TSP est totalmente orientado a equipos de trabajo.

Est integrado por indicadores: stos sealan los pasos a realizar y el orden a seguir.

Es un sistema de administracin de calidad: TSP tiene como principal propsito

asegurar la calidad en el desarrollo de software y, de este modo, conseguir la

satisfaccin total del cliente.

La estrategia del equipo est dirigida al desarrollo rpido: al utilizar la

retroalimentacin entre los miembros del equipo se evita cometer errores observados

en desarrollos pasados.

Proceso operativo apoyado por la formacin y capacitacin proporcionadas al equipo,

y dirigido a toda el rea de desarrollo. Aun cuando los desarrolladores ya cuenten con

la experiencia y la capacidad de ejecutar el trabajo, siempre hay cosas nuevas y

especficas que pueden aprenderse durante el desarrollo del proyecto.

Modelo de coaching: mtodo cuyo propsito es instruir y dirigir a las personas con el

propsito de que logren los objetivos y desarrollen habilidades especficas de

acuerdo a las actividades y roles que desempeen dentro del proyecto.

Un punto muy importante de TSP es lograr la comunicacin entre los miembros del equipo

de desarrollo del proyecto, ya que cada individuo tiene un estilo propio para llevar a cabo las

tareas. Sin embargo, el objetivo siempre ser asegurar la calidad durante todo el proceso de

desarrollo de software.

1.1.1. Principios y objetivos de TSP

El objetivo de TSP es mejorar y asegurar la calidad y productividad en un proyecto de

desarrollo de software. Para ayudar a alcanzar los costos y tiempos planeados, los objetivos

del proyecto los establecen los ingenieros de software, de acuerdo con la metodologa TSP.

Es importante que todos los involucrados tengan claros los objetivos para poder llegar a la

meta en tiempo y forma, pero para lograrlo se debe asignar a cada persona en el puesto

indicado de acuerdo con sus habilidades, conocimientos y experiencia. As se asegura un



buen ambiente de trabajo y que en todo momento exista comunicacin y retroalimentacin

dentro del equipo.

TSP est basado en cuatro principios fundamentales (Tuya, J. y otros, 2007):

1. El aprendizaje es mucho ms eficaz si se sigue un proceso claro y bien definido y,

adems, si existe retroalimentacin entre los miembros del equipo. TSP cuenta con

mediciones claras y est diseado para utilizarse de manera cclica, esto permite al

equipo recibir informacin continua sobre su desempeo y avances dentro del

proyecto.

2. Para que el trabajo sea productivo es necesario definir objetivos claros, liderazgo y un

ambiente de trabajo agradable.

3. Es importante contar con guas apropiadas para dar solucin a los problemas de

desarrollo que surjan durante el tiempo que dure ste.

4. Las instrucciones son ms claras cuando ya se haba adquirido el conocimiento y la

experiencia en situaciones pasadas. TSP se basa en el conocimiento y la experiencia

sobre equipos de desarrollo de software.

Hasta ahora se ha revisado el significado de TSP y sus diferencias con PSP; pudiste

observar que aunque las dos buscan la calidad, TSP se enfoca en los equipos de trabajo de

desarrollo de software, y PSP en cada una de las personas lo integran. Tambin se revis lo

correspondiente al significado del ciclo de vida de desarrollo de software como un proceso;

se explic a detalle el modelo en cascada y cada una de sus fases; por ltimo, los principios

y objetivos que tiene esta metodologa.

En el siguiente subtema se revisar la estrategia de TSP, con la cual podrs identificar la

importancia de los equipos de trabajo, as como las estrategias para conformar uno para

implementar esta metodologa de desarrollo de software dentro de una organizacin.

1.1.2. Estrategia de TSP

Las estrategias son actividades bien estructuradas y planificadas para lograr el objetivo o los

objetivos que se tengan planeados.

La estrategia de TSP es muy importante para que esta metodologa se implemente de

manera correcta, ya que indica la mejor forma de aplicar los procesos que conforman TSP

en todo el ciclo de vida de desarrollo del proyecto, y en cada una de sus etapas.

TSP se conforma de ocho procesos: lanzamiento, estrategia, plan, requerimientos, diseo,

implementacin, prueba y post mrtem, los cuales se explicarn con ms detalle en el Tema

1.3. Ciclo de Vida del Team Software Process (TSP). Toda la fase de desarrollo de software



debe cumplir con un ciclo, el cual ser elegido de acuerdo al tamao y la complejidad del

proyecto.

Por ejemplo, tomemos el modelo en cascada, el cual cuenta con cinco fases que son:

definicin de requerimientos, diseo del sistema y de software, implementacin y prueba de

unidades, integracin y pruebas del sistema, funcionamiento y mantenimiento.

La estrategia principal de TSP se basa en la bsqueda de la mejor manera de introducir sus

ocho procesos dentro de cada fase del ciclo de vida del proyecto, que en este caso sera el

modelo en cascada (Piattini, 2011). Siempre se inicia con una junta donde los lderes e

ingenieros de software presentan los objetivos del proyecto a cada uno de los miembros del

equipo; posteriormente, se aplican los otros siete restantes procesos. En la siguiente fase

(diseo del sistema y de software, segn el modelo cascada) se aplican los mismos ocho

procesos, pero se trabaja sobre lo que ya se haya desarrollado en el ciclo anterior. Con esto

se logra que el producto que, en este caso sera el software que se est desarrollando,

aumente su funcionalidad.

Como pudiste darte cuenta, la estrategia de TSP indica que no importa el modelo de ciclo de

vida que se elija para el desarrollo de software, siempre se van a utilizar los ocho procesos

que nos marca esta metodologa, y se van a implementar en cada una de las fases de

desarrollo del ciclo de vida del software a desarrollar. En el siguiente captulo aprenders las

principales caractersticas que se requieren para integrar los equipos de trabajo, de acuerdo

con algunas condiciones sealadas por el TSP.

1.1.3. Equipo TSP

En el contexto de TSP (metodologa creada para los grupos de trabajo y la

retroalimentacin), para que un equipo se forme hay algunas condiciones que deben

crearse, las cuales se mencionan a continuacin (Piattini, 2011):

Debe estar formado por al menos dos personas.

Los integrantes del equipo deben trabajar en conjunto para lograr el objetivo del

proyecto.

Todos los miembros del equipo deben de apoyarse mutuamente. Para lograr el

objetivo principal del proyecto se necesita de la ayuda y la colaboracin de todos los

miembros del equipo.

Cada persona tiene un rol especfico (establecidos por los ingenieros de software y

administradores del proyecto), el cual debe seguir porque es una gua de sus

deberes.

Para conformar un equipo efectivo de ingenieros se necesita que:



Los integrantes estn cualificados con las capacidades y habilidades propias de su

rol.

El objetivo del proyecto debe ser claro, realista y bien definido.

Los recursos que se asignen al equipo deben de ser acordes al trabajo que van a

realizar.

Los integrantes deben de estar motivados y comprometidos para lograr el objetivo.

Los miembros deben de ser disciplinados y responsables en su trabajo.

Para formar el equipo de trabajo se deben de dar las siguientes condiciones:

El equipo debe formar una estrategia de trabajo en la que todos estn de acuerdo.

Establecer objetivos en comn y definir los roles por parte de los miembros del

equipo.

Definir procesos en comn.

Todos los miembros deben de participar en la creacin de un plan.

El equipo deber negociar el plan con la administracin.

La administracin revisar y aceptar el plan realizado por el equipo.

Los miembros deben de realizar su trabajo de acuerdo al plan.

Deber existir comunicacin frecuente entre los miembros del equipo.

Todos los integrantes debern cooperar y estar comprometidos con un objetivo en

comn.

Los lderes debern de obtener feedback (retroalimentacin) y deben de buscar

liderazgo que mantenga motivados a los miembros del equipo.

En este subtema se revis lo referente a las condiciones necesarias para crear equipos de

trabajo adecuados para implementar la metodologa TSP. En la siguiente actividad

identificars los elementos de la metodologa TSP y la relacin que existe entre ellos.

1.2. Estructura del Team Software Process (TSP)

TSP es una estructura porque se conforma de partes y procesos que se encuentran

relacionados, adems indican las acciones o actividades a ejecutar y el orden en el cual

deben desarrollarse. Esto es muy importante en la implementacin de TSP, ya que indica los

pasos a seguir al momento de crear el equipo, trabajar y ejecutar acciones individuales.

Una de las ms grandes ventajas de TSP consiste en que proporciona una estructura bien

definida para guiar a los ingenieros y administradores, con el objetivo de llevar por buen

camino al equipo de trabajo. Esta estructura tambin especifica los pasos y medidas

necesarios para formar un equipo eficaz y un buen ambiente de trabajo.



En la siguiente figura se muestra la estructura de TSP:

Planes personales

Mtodo de planeacin

Valor agregado

Mtricas de calidad

Procesos definidos

Figura 2 Estructura de TSP (Gomez y Ania, 2008).

En los recuadros de la parte superior de la imagen se encuentra la metodologa que va a

usarse. Por ejemplo, la disciplina ingenieril hace referencia a PSP ya que se trata del trabajo

y habilidades que cada miembro del equipo debe tener. En las siguientes dos disciplinas, de

equipo y de administracin, se crean los equipos y se ejecuta el trabajo; para ello, se utiliza

la metodologa TSP. El conjunto de las tres da como resultado equipos de trabajo bien

conformados e integrados.

Cada una nos muestra los pasos (en TSP se llaman fases) bien definidos y estructurados

que van a ejecutarse; se forman equipos integrados hasta que hayan completado al 100%

todas sus fases. A continuacin se explicarn cada una de las disciplinas que conforman la

estructura de TSP.

TSP

trabajo en

equipo

TSP

creacin

del equipo

Compromisos

Planes agresivos

Calidad propia

Objetivos del proyecto

Plan propio

Plan detallado

Roles

Roles del equipo

Prioridad en la

calidad

Costo de la calidad

Seguir el proceso

Revisin de status

y calidad

Comunicacin

Disciplina

ingenieril

Disciplina

de equipo

Disciplina de

administracin

Equipos

integrados



1.2.1. Disciplina de equipo

En este subtema aprenders la disciplina de equipo con sus respectivas fases.

La disciplina de equipo consiste en una serie de reglas que deben llevarse a cabo a lo largo

del proceso de desarrollo de software. Estas reglas tambin pueden ser vistas como fases

dentro de esta disciplina y a continuacin se explicarn a detalle cada una:

Compromiso: todos los miembros debern tener bien claro cules son los

compromisos con la organizacin y con el cliente, de acuerdo a los objetivos

planteados al inicio del proyecto.

Planes agresivos: son acciones planeadas y bien estructuradas para ejecutarse

rpidamente y lograr objetivos a corto plazo; proporcionan el desempeo eficiente de

los miembros del equipo sin que se sientan presionados y reduzcan su productividad.

Calidad propia: cada desarrollador debe colocar su propio sello al desarrollo en las

pruebas a su cargo, las cuales se realizan de acuerdo al funcionamiento que debe

tener el mdulo del sistema que estn desarrollando. Es muy importante hacer

nfasis en que las pruebas son provisionales, porque las personas de calidad en la

fase de pruebas del ciclo de vida del proyecto las hacen de una manera ms

detallada, con protocolos y estndares bien definidos por el administrador de calidad

de proceso. Esto se ver ms a detalle en la unidad 3. Gestin en TSP.

Objetivo del proyecto: el equipo debe dar su punto de vista de los objetivos que se

plantean al inicio del proyecto, y as tener una visin ms clara acerca de a dnde se

desea llegar.

Plan propio: cada equipo debe de tener su propio plan, establecido por los

administradores al inicio del proyecto. Aprenders cmo hacer uno en la unidad 2.

implementacin de TSP.

Plan detallado: en la documentacin que se crea al inicio del proyecto (donde se

exponen los objetivos, los requerimientos del sistema, etc.) debe haber un plan

detallado sobre las actividades a realizarse a travs de todo el ciclo de vida del

proyecto, y sobre los riesgos que puedan surgir durante el desarrollo del software.

Todo esto lo veremos con ms detalle en el subtema 2.2. Ejecutar el trabajo en

equipo.

Roles: cada miembro del grupo debe tener bien claro cul es su rol dentro del

equipo; los roles se asignan con base en las capacidades y cualidades de cada

persona, y son establecidos por los ingenieros y administradores al inicio del

proyecto.

Recursos del equipo: el equipo debe de utilizar, de manera correcta, los recursos

proporcionados por parte de la empresa que solicita el proyecto de software, por lo

que contrata o integra un equipo TSP.



En conclusin, puede decirse que la disciplina de equipo indica reglas muy precisas que

guan las actividades para que se logren los objetivos del proyecto.

1.2.2. Disciplina de administracin

Esta disciplina muestra la forma en que los administradores del proyecto deben guiar al

grupo para cumplir los objetivos del proyecto de software.

Prioridad de calidad: en todo desarrollo de software, el principal objetivo debe ser la

calidad y la satisfaccin del cliente. Esta calidad se logra mediante una buena

planeacin y ejecucin al pie de la letra la metodologa TSP.

Costo de la calidad: de acuerdo a la calidad ser el coste. Debe asegurarse que los

costos sean adecuados para llegar a la calidad planeada al inicio del proyecto,

adecuados al tiempo y de acuerdo con lo robusto del sistema que vaya a

desarrollarse. Cabe mencionar que esta planeacin se hace al inicio del proyecto por

parte de los ingenieros y los administradores.

Seguir el proceso: al inicio del proyecto se establecen procesos bien definidos, y los

administradores deben de revisar se cumplan. Esto se aprender en el tema 1.3.

Ciclo de vida del Team Software Process (TSP).

Revisin de status de calidad: para este fin, tanto los desarrolladores como los

administradores utilizan plantillas y reportes, que t aprenders a hacer en la unidad

3. Gestin en TSP.

Comunicacin: la comunicacin entre los miembros del equipo no solo permite que

se llegue a los objetivos deseados, tambin sirve para tener un buen ambiente de

trabajo y llevar a cabo la retroalimentacin que ayuda a no repetir errores ya

cometidos, en el mismo proyecto o en anteriores.

Como se puede notar, la disciplina de la administracin se basa en los administradores y en

la forma de medir el nivel de calidad del desarrollo del proyecto. En el siguiente subtema

conocers la disciplina que est orientada a las personas que conforman el equipo de

desarrollo de un proyecto.

1.2.3. Disciplina de ingeniera

Esa disciplina se basa totalmente en PSP, ya que es necesario medir la calidad respecto a

las habilidades individuales de los miembros del equipo, quienes deben saber que forman

parte del grupo y, al mismo tiempo, ser responsables de sus actividades de acuerdo a los

roles que se les hayan asignado. La disciplina de ingeniera se conforma por las siguientes

actividades:



Planes personales: cada miembro del equipo debe conocer su rol dentro del

proyecto y estar consciente de su responsabilidad para que el objetivo se cumpla.

Mtodo de planeacin: cada miembro debe manejar y planear correctamente sus

tiempos y las responsabilidades que tiene.

Valor agregado: cada miembro del equipo aportar su experiencia y conocimiento en

el desarrollo de los proyectos.

Mtricas de calidad: las mtricas son una referencia exacta para medir el nivel de

algo en especfico. En este caso sirven para controlar, medir, monitorizar, predecir y

probar el desarrollo de software. Por ejemplo, una mtrica podra ser una plantilla

donde muestre los avances que ha tenido el proyecto mes con mes. Esta fase se

explicar con ms detalle en el tema 3.2. Diagnstico: Mtricas de calidad versus

trabajo realizado.

Procesos definidos: muestran a los miembros del equipo un panorama general para

comenzar con el desarrollo del software.

Es muy importante entender con claridad cul es la estructura de TSP y su objetivo en cada

disciplina. Como pudiste aprender, las disciplinas son como recetas de cocina que dicen qu

acciones tomar en todas y cada una de las fases de desarrollo del proyecto. En el siguiente

tema aprenders la forma en que est estructurado el ciclo de vida de la metodologa TSP.

1.3. Ciclo de vida del Team Software Process (TSP)

El ciclo de vida del TSP se conforma de una serie de ciclos (puede ir desde uno hasta un

nmero indefinido, dependiendo de la magnitud del proyecto), organizada en ocho fases.

stas comienzan con los requerimientos del producto de software, donde se establece lo que

se quiere lograr y comienza con la creacin de diseos detallados del software, que es

revisado por todo el equipo. Posteriormente, dicho diseo se convierte en cdigo, el cual

tambin es revisado y analizado para realizar las pruebas pertinentes; finalmente se analiza

la calidad del producto de software terminado. Es entonces cuando el ciclo de vida del TSP

llega a su fin (Nord, R; McHale, J., & Bachmann, F., 2010).

En la aplicacin del ciclo de vida del proceso de software de equipo de TSP, se definen las

fases del desarrollo de software que se realizarn por parte del equipo de trabajo, las cuales

describen una serie de pasos para ayudar a alcanzar productos de calidad. La metodologa

del TSP contempla ocho faces de desarrollo bien definidas (ver figura 1.1), que deben

llevarse a cabo de manera cclica durante el proceso de desarrollo de software. Es preciso

mencionar que el equipo de trabajo realizar el proceso de desarrollo de software y de

control de la calidad; sin embargo, el encargado de revisar que esto se cumpla es el

administrador de calidad dentro de los roles del equipo, lo que se explicar en el subtema



1.3.1. Fase de lanzamiento. Cada una de las fases describe las actividades que les son

propias, y que se explican a continuacin (Humphrey, 1999).

Figura 3. Fases del ciclo de vida del TSP (Humphrey, 1999).

1.3.1. Fase de lanzamiento

En este subtema se revisarn las directrices a seguir para dar comienzo con el desarrollo del

producto de software.

Dentro de la fase de lanzamiento se establecen las metas y objetivos del equipo de proyecto;

tambin se determinan los roles y responsabilidades que desempearn cada uno de los

integrantes, y la manera idnea para forma el equipo de trabajo. Las metas y objetivos se

llevan a cabo de forma individual y en equipo, en la tabla 1 observars un ejemplo de los

objetivos planteados de manera individual.

Es de gran importancia definir los objetivos de tal manera que sean medibles, y as

determinar la calidad del producto generado (ver tabla 1). Deben establecerse objetivos

ambiciosos para los miembros del equipo, pero sin alejarse de la realidad (ser un miembro

eficiente del cooperativo, realizar un trabajo personal disciplinado, etc.). Poner los objetivos

por escrito ayudar de manera significativa al equipo para determinar, de forma peridica,

hasta qu grado fue cumplido cada objetivo planteado. Todos los miembros del equipo

deben estar comprometidos con los objetivos programados y participar activamente con l.

Tabla 1. Objetivos propuestos para los miembros del equipo y sus indicadores

Lanzamiento

Estrategia

Planeacin

Requerimientos

Diseo

Implementacin

Pruebas

Post mrtem



Objetivos Indicador 1 Indicador 2 Indicador 3 Indicador 4

Ser un

miembro del

equipo

cooperativo y

efectivo

El promedio de

la evaluacin de

cada miembro

del equipo,

efectuada por los

pares acerca de

la disposicin a

ayudar y la

aportacin del

trabajo, debe ser

mayor a 3 (sta

es una medicin

de la eficacia y

eficiencia que el

equipo

establece,

determina, y

califica).

El promedio de

la evaluacin de

cada miembro

del equipo,

efectuada por

los pares acerca

de la

contribucin

general hecha al

equipo, debe ser

mayor a 3.

Realizar un

trabajo

personal

disciplinado

El porcentaje de

los datos

personales

(desempeo,

eficacia,

etctera)

registrados debe

ser 100%.

El porcentaje de

semanas

registradas en el

documento

semanal debe

ser 100%.

Planear y dar

seguimiento al

trabajo

personal

El porcentaje de

los datos del

proyecto

personal

registrados en

las formas

correspondientes

debe ser 100%.

El porcentaje de

las tareas del

proyecto con

plan y datos

reales

registrados en

forma

correspondiente

debe ser 100%.

Hacer

productos de

calidad

El porcentaje de

defectos

encontrados

antes de la prime

compilacin

debe ser mayor

La densidad de

defectos

encontrados

durante la

compilacin

debe ser menor

La densidad

de defectos

encontrados

durante la

prueba de

unidad debe

La densidad

de defectos

encontrados

durante y

despus de la

prueba de



a 70%. a 10/KLOC. ser menor a

5/KLOC.

unidad debe

ser 0.

Gmez y Ania, 2008

Tabla 2. Objetivos propuestos por el equipo y sus indicadores

Objetivos Indicador 1 Indicador 2 Indicador 3

Crear producto de

calidad

El porcentaje de

defectos

encontrados antes

de la primera

compilacin debe

de ser 80%.

La cantidad de

defectos

encontrados en la

prueba del sistema

debe ser 0.

Al terminar el

proyecto se debi

haber incluido el

100% de las

funcionalidades.

Llevar a cabo un

proyecto

productivo y bien

administrado

El error en la

estimacin del

producto debe ser

menor a 20%.

El error en el

nmero de horas de

desarrollo debe ser

menor a 20%

El porcentaje de

datos del proyecto

debe ser 100%.

Terminar el

proyecto a tiempo

El total de das de

retraso o adelanto

para completar el

ciclo debe ser

menor a 4.

Gmez y Ania, 2008

En la tabla 1y 2 se muestran los objetivos planteados y sus indicadores, que son los criterios

a evaluar en cada objetivo, a los cuales se les establece un valor que el equipo asigna para

que puedan ser medidos.

En la fase de lanzamiento se programa una serie de reuniones, donde participan todos los

miembros del equipo para generar el plan del lanzamiento. Se recomienda dar seguimiento a

los planteamientos que se presentan a continuacin:

Las empresas necesitan

metas de gestin de

requisitos del producto.

Qu? Cmo? Cundo? Quin?

Qu

tan

bien?

Qu

pasa

si...?



Figura 4. Lanzamiento del TSP (Queensland, 2010).

Los objetivos del equipo Diseos conceptuales Productos planeados Tamao de estimaciones

La estrategia de equipo El equipo define el proceso

Plan de tareas Plan de calendario Plan de valor agregado

Funciones del equipo Planes de trabajo

Plan de calidad

Evaluacin de riesgos Plan de alternativas



Las preguntas que se plantean en el esquema anterior: qu?, cmo?, quin?, qu tan

bien? y qu pasa si...?, permitirn establecer las bases de una estrategia del lanzamiento

para llegar a la culminacin del proyecto; en conjunto con la anterior, se deben tomar en

cuenta los requerimientos que sern establecidos por parte del cliente (Queensland, 2010).

Como se mencion anteriormente, en la fase de lanzamiento se asignan las tareas y roles

del equipo de trabajo, a continuacin de describen los roles del TSP.

Roles de TSP

Lder del proyecto

Es aquel que lleva el mando del equipo, el que lo dirige, esta figura se asegura de que todos

realicen y completen su trabajo, reporten sus procesos tal cual como fue planeado en fin, es

el que maneja los alcances del proyecto (Osorio, 2013, p.2).

El ingeniero que tenga este rol debe realizar reportes semanales sobre los avances del

equipo (Osorio, 2013). En la siguiente tabla se muestra un ejemplo para generar los reportes

de avances del equipo.



Tabla 4. Reporte de avances de equipo

Reporte semanal TSP

Nombre: Equipo:

Fecha: Ciclo: Semana:

Datos semanales Planeado Actual

Horas del proyecto para esta

semana

Horas del proyecto de este ciclo

a la fecha

Valor ganado para esta semana

Valor ganando en este ciclo a la

fecha

Horas totales para las tareas

terminadas en esta fase a la

fecha

Datos

semanales por

rol

Horas

planeadas

Horas actuales Valor planeado Valor agregado

Tareas de

desarrollo

terminadas

Horas

planeadas

Horas actuales Valor ganado Semana

planeada

Seguimiento de asuntos o riesgos Estatus

Otros asuntos

importantes

LE Lder de equipo AP Administrador de planeacin AA Administrador de

apoyo

AD Administrador de

desarrollo

ACP Administrador de

calidad/proceso

UABC, 2005



El lder de proyecto es el representante ante el cliente, el encargado de la integracin de la

planeacin e implementacin de todas las tareas de los involucrados en el desarrollo del

producto de software, con el objetivo de culminar el proyecto.

Administrador de desarrollo

Los administradores de desarrollo guan al equipo en la planificacin y seguimiento del

desarrollo del producto de software.

Su principal objetivo se centra en la fase de diseo del proyecto. Aqu toma el mando del

proyecto el ingeniero con mayor conocimiento en diseo, quien formular las actividades que

requiera esta etapa, adems de asegurarse de que todas se realicen a cabalidad (Osorio,

2013).

Las funciones principales del administrador de desarrollo son (Osorio, 2013):

Proponer estrategias de desarrollo (se describirn ms delante).

Auxiliar al lder de proyecto para estimar los tiempos, recursos y tamao del producto

de software.

Dirigir el anlisis de alto nivel.

Dirigir el diseo.

Dirigir la implementacin de pruebas.

Colaborar con el equipo de desarrollo.

Como podrs darte cuenta, el administrador de desarrollo debe de colaborar muy de cerca

con cada uno de los miembros del equipo que desempean los distintos roles.

Administrador de planeacin

El administrador de planeacin es el principal responsable de llevar el control de los planes

del equipo, y de dar apoyo a cada miembro cuando se presenten problemas que estn

relacionadas con el plan.

Debe dirigir la generacin del plan de trabajo en cada ciclo de desarrollo y establecer cmo

estarn definidas las partes del producto final. Administra el qu, quines, cmo, cundo y

dnde se va a hacer. De ello depende la complejidad y factibilidad del proyecto. Est ligado a

los objetivos propuestos, hasta dnde se va a llegar (Osorio, 2013).



Administrador de calidad

El administrador de calidad se encarga de proponer el plan de calidad tanto para el proceso

como para el producto. Tiene la responsabilidad de determinar las necesidades que se

presenta dentro del proceso, y le da seguimiento a la calidad del producto.

Tambin determina las necesidades dentro del proceso de calidad que se implementar en

el proyecto de software y le da seguimiento, con el fin de mantener la calidad del producto

(Osorio, 2013).

Sus funciones bsicas son stas:

Mantener estndares de desarrollo.

Mantener los patrones de calidad que se deban seguir durante el mismo proceso.

Dirigir las inspecciones de calidad del producto de software.

Registrar y documentar las reuniones que se hagan relacionadas con el equipo y su

proyecto software, como todos los roles anteriores.

Colaborar con el equipo de desarrollo de software (Osorio, 2013).

Es de suma importancia que el administrador de calidad revise que todo el equipo de trabajo

alcance los estndares y patrones de calidad; debe alertar al lder del proyecto sobre

cualquier trabajo que no los cubra.

Administrador de configuraciones

La administracin de configuraciones es considerada uno de los factores de mayor

influencia para lograr el ptimo desarrollo de productos software de alta calidad, porque es la

encargada de garantizar que los cambios sean efectivos y eficientes (Osorio, 2013,).

El administrador de configuraciones debe poseer un documento donde integre el

seguimiento del proceso, es decir, un proceso documentado para realizar el manejo de la

configuracin de los productos y subproductos, donde se indiquen los procedimientos

necesarios para llevar a cabo las labores de administracin de configuraciones tales como:

Establecer los nmeros de las versiones de los productos o que indican dichos

nmeros.

Mantener la trazabilidad (conocer el histrico del proyecto, en este caso las

versiones del producto) de los productos y subproductos desarrollados (Osorio,

2013).

Coordinar todas las actividades de cambio que realice cualquier miembro del equipo.

Administrar el versionamiento (la gestin de los cambios que se realicen en el

producto de software); es decir, administrar el control de cambios y su sistema,



recomendar los cambios o ajustes que deben realizarse, verificar, mantener y

evaluar la persistencia del sistema, fomentar la reutilizacin del cdigo y recursos

Sentirse parte del desarrollo.

Sin duda alguna, la fase de lanzamiento es una de las etapas primordiales y ms

importantes dentro del ciclo de vida del TSP. De ella emana lo que se va a hacer, cmo se

va a hacer y hasta dnde se quiere llegar, la culminacin de esta fase dar el banderazo de

inicio a la de estrategia.

1.3.2. Fase de estrategia

Ya se explic lo que debe realizarse en la fase de lanzamiento para dar inicio al desarrollo

del producto de software. Ya se elaboraron los equipos y se asignaron los roles, ahora es

necesario plantear las estrategias a seguir para dar seguimiento a desarrollo del producto de

software. En esta fase conocers las estrategias de desarrollo para entender lo que se va a

producir en cada ciclo, analizars e identificars las estimaciones de tamao y esfuerzo que

se requieran.

En la fase de la estrategia los equipos idean un diseo conceptual del producto previsto. De

igual manera se hacen estimaciones sobre el tamao y el tiempo que tomar el desarrollo,

teniendo en cuenta que el tiempo que se llegue a considerar debe ser acorde con el tiempo

que se tiene disponible. La fase de estrategia contempla los siguientes puntos principales:

Medir el tiempo real del desarrollo y el tiempo disponible.

El largo alcance de internet en tiempo real. Tomado de http://www.corbax.com/blog/img/tiempo-real.jpg

Crear el diseo conceptual del producto: es el punto de arranque para realizar la

planificacin del proyecto. Se establece un plan para la elaboracin del producto.

Para la elaboracin del diseo conceptual, los miembros del equipo deben basarse

en experiencias previas con la finalidad de saber cmo puede desarrollarse el

siguiente producto; para esto se utilizan los diagramas UML (lenguaje unificado de



modelado), lenguaje grafico que permitir especificar, visualizar, construir y

documentar un sistema de software. Reviste gran importancia como gua del equipo

de trabajo en todo el proceso.

Diseo y reorganizacin. Tomado de http://www.logismarket.es/ip/blife-diseno-y-reorganizacion-de-almacenes-

diseno-y-reorganizacion-de-almacenes-491419-FGR.jpg

Establecer la estrategia de desarrollo: el equipo decide cul es la mejor manera para

dividir el trabajo entre los ciclos y lo que ser producido en cada uno de stos. Puede hacer

uso de herramientas CASE.

Estimacin de tamao y esfuerzo: se refiere al tamao estimado que tendr el producto y

el tiempo que se llevar en realizarlo. Debe considerarse el tiempo disponible para hacer los

a ajustes necesarios a la estrategia, y que los tiempos puedan coincidir. Puedes hacer uso

de la gua del PMBOK (captulo 6.1.) para realizar estas estimaciones.



Plan de gestin de riesgos: para realizarlo se debe estar totalmente comprometido con el

proyecto, para elaborar un producto de calidad. En la siguiente tabla se muestra un ejemplo

de gestin de riesgos. Corresponde a un plan de riesgos que se implement en el desarrollo

y mantenimiento de componentes para Web 2.0 en bibliotecas especializadas.

Tabla 5. Ejemplo de gestin de Riesgos

Riesgo RI-05. Inexperiencia del equipo informtico/bibliotecario en el desarrollo e

implementacin del proyecto.

Aspectos a considerar

Por qu el riesgo es importante? Podra alterar la calidad del producto,

provocar atrasos en el desarrollo e implementacin del proyecto.

Qu informacin se necesita para seguir el estado del riesgo:

o Documentos de estado de avances de trabajos individuales, en donde se

explayen las tareas realizadas y las dificultades presentadas; si stas

fueron solucionadas con xito y cmo se consigui.

o Planilla de informe de errores y soluciones.

Los responsables de realizar el control del riesgo son el jefe del proyecto y los

integrantes del equipo de trabajo.

Para realizar un adecuado control del riesgo se necesitar personal capacitado

en validar las funciones desde el punto de vista tcnico/bibliotecolgico. Si el

control corresponde a una actividad informtica, el personal deber tener

amplios conocimientos sobre la tecnologa incluida en el proyecto; si el control

corresponde a una actividad bibliotecolgica, deber poseer el conocimiento de

la tecnologa aplicable a la bibliotecologa.

Plan de accin

Cursos de capacitacin de tecnologa y administracin de componentes web.

2.0 para el personal bibliotecario.

Realizar talleres y actividades integradoras.

Reuniones semanales entre informticos y bibliotecarios.

Contratar personal Informtico especializado en:

Tecnologa web.

Base de datos.

Diseo de pginas web.

Plan de contingencia

Disparador: el plan de avance no refleja los resultados esperados, falta de

calidad en el producto.

Contratar una consultara experta en tecnologa Web 2.0.

Kuna, Caballero et l., 2008



El TSP recomienda que las estrategias definidas sean documentadas para darles un

continuo seguimiento.

En este subtema se describi lo que es una estrategia y la manera en que debe

desarrollarse. Esto tiene como objetivo hacer un producto de calidad, para ello el equipo

debe estar de acuerdo con los criterios de la estrategia y darle seguimiento. Lo ya

mencionado permitir saber cmo se va a realizar el producto de software. Estas estrategias

ayudarn al equipo a preparar la planeacin, la cual se explicar en el siguiente subtema.

1.3.3. Fase de planeacin

En la fase de lanzamiento, el equipo debi haber analizado las necesidades y creado un

diseo conceptual de la estimacin de tamao del producto; en la fase de estrategia, debi

realizar una estimacin de tiempo que llevar el desarrollo. stas son las bases para el

siguiente proceso que, en este caso, es la planeacin.

Dentro de la fase de planeacin los miembros del equipo generan un plan de trabajo, que

puede contener un inventario de los elementos que sern utilizados. ste puede contener:

Estimacin del tamao de cada parte a ser desarrollada: ste ser determinado

por el tamao del trabajo.

Identificacin de las tareas, estimacin el tiempo necesario para completarlas:

para esto es necesario asignar las tareas a cada miembro del equipo.

Cronograma semanal para tareas terminadas: se puede hacer uso de

herramientas como Microsoft Project, y hacer diagramas de Gantt para llevar el

control de las actividades; all se programan las tareas y se propone una duracin,

fecha de inicio y trmino. Por ltimo, se lleva el control semanal sobre el porcentaje

de cumplimiento.

Plan de calidad: es un documento que especifica quin, cundo y qu

procedimientos y recursos asociados deben aplicarse a un proyecto, producto,

proceso o contrato especfico (Secretara Central de ISO, 2005).

Es posible observar los formatos de un plan de gestin de calidad para un programa de

capacitacin en la pgina de Dharma Consulting Especialistas en Project Managemen, ah

encontrars herramientas gratuitas de gestin de proyectos y podrs observar los

lineamentos establecidos para realizar un control de calidad.

Los objetivos de calidad, que se encuentran en la lnea base de calidad del proyecto, se

refieren a la medicin con la que se evaluar el cumplimiento de las metas establecidas por

el equipo de trabajo. La mtrica se refiere, de igual manera, a una medida que proporciona



una indicacin cuantitativa (dimensin o tamao de algunos atributos). Otra observacin

importante es el sponsor, patrocinador o cliente.

La complejidad para elaborar un plan de desarrollo depende del tamao del proyecto. El

hacer un plan permitir trabajar de una manera ms eficiente en el rubro de calidad. En el

siguiente subtema se aplicar lo planeado con base en los requerimientos del desarrollo del

software.

1.3.4. Fase de requerimientos

A continuacin revisars algunas recomendaciones necesarias para conocer las

especificaciones de requerimientos de software, el anlisis de necesidades y los criterios

necesarios para realizar lo que en verdad se quiere.

Una vez que se ha concluido con la fase de planeacin se pueden gestionar los

requerimientos, stos se establecen al entrevistar a los clientes para determinar lo que se va

a producir (Humphrey, 1999). En esta fase se construyen las especificaciones de

requerimiento de software; esto nos sirve de gua durante el proceso del desarrollo del

producto. Es importante que el equipo de trabajo lleve estos requerimientos en documentos y

que todos lleguen a un acuerdo acerca de lo que se va desarrollar.

En muchas ocasiones los requisitos que especifica el cliente llegan a ser imprecisos, lo que

ocasiona que los requerimientos sufran cambios de manera constante. Los clientes creen

estar seguro de sus deseos, pero esto no siempre es as. Por ello no se debe caer en

suposiciones, y s tener muy claro lo que el cliente desea en realidad.

La fase de requerimientos sugiere las siguientes actividades.

Anlisis de necesidades del cliente. Se realiza una serie de preguntas y respuestas que

deben ser lo suficientemente claras para poder analizar las necesidades del cliente. Debe de

haber participacin de todos los involucrados, integrantes del equipo y cliente, para llegar a

un acuerdo mutuo. En este punto, TSP indica el qu, pero las preguntas respecto al cmo se

debe general al interior del equipo, de tal manera que puedan recolectar la informacin

necesaria.

Especificacin de requerimientos. stos se clasifican en:

Requerimientos funcionales: describen los servicios que debe proporcionar el

sistema y el comportamiento que tendr en ciertas circunstancias. Los requerimientos

dependern del tipo de software que est en desarrollo. A continuacin se presenta

un ejemplo de requerimientos funcionales para un sistema de biblioteca universitaria,



denominado Libsys, utilizado por estudiantes y personal docente que solicitan libros y

documentos de otras bibliotecas.

Requerimientos funcionales de Libsys (Olivera, 2010):

1. El usuario deber tener la posibilidad de buscar en el conjunto inicial de la base de

datos o seleccionar un subconjunto.

2. El sistema deber proporcionar visores adecuados para que el usuario lea

documentos en el almacn de documentos.

3. A cada pedido se le deber asignar un identificador nico (id_pedido), que el

usuario podr copiar al rea de almacenamiento permanente de la cuenta.

Requerimientos no funcionales: son aquellos requerimientos que no estn

involucrados directamente a las funciones del sistema. Pueden ser las capacidades

de almacenamiento o restricciones de tiempo de respuesta. Ejemplo: si se requiere

desarrollar un programa para un cajero automtico y el cliente desea que el programa

est funcionando las 24 horas del da, en este caso se observa que el requerimiento

no funciona, es decir, la disponibilidad.

Es indispensable que los requerimientos sean examinados por el equipo de trabajo para

desarrollar un plan de pruebas.

En conclusin, la fase de requerimiento nos da a conocer lo que el cliente desea y las

funciones que se proponen para el producto a realizar; se llega a un acuerdo mutuo sobre lo

que se va a construir.

1.3.5. Fase de diseo

En este subtema conocers los aspectos bsicos para crear el diseo del producto de

software. Aqu se genera la estructura general del producto; para esto se deben definir las

especificaciones del diseo del software. Se debe generar un diseo completo de los

requisitos para poder precisar claramente el producto que va a desarrollarse

(Humphrey, 1999).

Despus de que se tienen bien definidos los requisitos, se deben llevar acabo las siguientes

actividades:

Crear un diseo de alto nivel: describen los componentes principales del sistema y

la forma en que interactan entre s. El equipo puede trabajar de forma independiente

ya que es posible separar el diseo en partes. Esto se refiere a la creacin de las GUI



(interface grfica de usuario), que ser la va de comunicacin entre el usuario y el

sistema (software).

Inspeccionar el diseo: al inspeccionar se puede mejorar de manera importante la

calidad de los diseos, pero para esto se tiene que estar lo mejor documentado

posible.

Desarrollar un plan de evaluacin: disear la estructura principal de los

requerimientos del sistema permitir la implementacin y codificacin de ste.

1.3.6. Fase de implementacin

Ahora aprenders las acciones que se llevan a cabo en la etapa de implementacin, que

est relacionada con la codificacin y el uso de estndares dentro del sistema.

En esta fase se realiza la implementacin del producto de software; se empieza a

decodificar, pero antes se debe inspeccionar minuciosamente el cdigo del software (Gmez

y Ania, 2008).

Los estndares en esta fase cumplen un papel muy importante. El equipo de trabajo debe

definir estas normas al inicio de proyecto; esto puede hacerles ahorrar mucho tiempo en

desarrollo del sistema.

Como ya se mencion, los estndares de diseo dentro de esta fase son fundamentales. A

continuacin se muestran algunos de ellos:

Revisin de estndares

Estndares de codificacin

Estndar de tamao

Estndar de defectos

Prevencin de defectos

En la fase de aplicacin es muy frecuente encontrar errores de transcripcin y de

codificacin, errores producidos al pulsar una tecla por otra. Por esta razn, varios

programadores deben revisar e inspeccionar el cdigo (Humphrey, 1999).

El uso de estndares te permitir encontrar y mitigar errores de escritura, as ahorrars

tiempo y esfuerzo; pero para esto se necesitan hacer las pruebas correspondientes que

veras en el siguiente subtema.



1.3.7. Fase de pruebas

Esta fase es una da las ms importantes ya que debe probarse el producto y evaluar,

detectar y corregir todos sus defectos; de esta manera se evita que los costos lleguen a

elevarse considerablemente (Gmez y Ania, 2008).

En esta etapa se realizan diferentes pruebas al sistema, con el fin de asegurar su calidad y

evaluar el desempeo del equipo de trabajo. Para administrar las pruebas se debe tener una

lista de pasos a seguir; se hace por partes, de manera gradual, y se empieza desde el primer

nivel hasta el ms alto para que, al final, se integre de tal manera que todos los elementos

estn incluidos y que funcionen correctamente.

A continuacin se muestra una gua que contempla TSP para llevar el control de las pruebas

al sistema.

Tabla 6. Integracin y pruebas del sistema

Propsito Para guiar a un equipo a travs de la integracin y prueba de

los componentes del producto en un sistema.

Los criterios de ingreso El equipo cuenta con un plan y una estrategia de desarrollo.

Componentes implementados, inspeccionados, y la unidad

probada bajo control de configuracin.

General Cuando los defectos se encuentran en construccin, integracin o

en la prueba del sistema, el responsable de calidad/proceso

determina si la prueba debe continuar. Todo defecto que se

encuentra en la integracin o pruebas del sistema se consigna en

el registro de defectos, y debe de ser revisado por todo el equipo

para determinar:

Cuntos defectos similares pueden permanecer en el

producto.

Cmo y cundo encontrar y corregir esos defectos.

El proceso cambia para prevenir defectos similares en el

futuro.

Paso Actividades Descripcin

1 Prueba descripcin

general del

proceso.

El administrador de calidad describe:

El proceso de pruebas de integracin y de sistema.

La necesidad de componentes de calidad antes de probar.

La necesidad y el contenido de las normas de ensayo.

La estrategia para el manejo de componentes de baja

calidad.

2 Desarrollo de El administrador de desarrollo conduce el progreso de la



pruebas prueba.

El jefe del equipo de ayuda a asignar el desarrollo de la

prueba y ensayo entre los miembros del equipo.

Los miembros del equipo de pruebas realizan sus tareas de

desarrollo de las pruebas.

Definir los procesos y procedimientos de generacin

requeridas.

Desarrollar los procedimientos de ensayo de la integracin

y las instalaciones.

Desarrollar los procedimientos de ensayo de sistemas e

instalaciones.

Medir el tamao y el tiempo de funcionamiento para cada

prueba.

Revisar los materiales de prueba y corregir errores.

3 Construir El equipo construye el producto y comprueba que est

completo. Verifica que todas las piezas necesarias estn a

la mano.

El encargado del desarrollo del software, consigna todos

los errores en el registro de defectos.

4 Integracin El gerente de desarrollo o alternativas:

Conduce las tareas de integracin.

Comprueba la integridad y la integracin de la prueba del

producto.

Escribe todas las actividades de prueba en el registro de la

misma.

El encargado del desarrollo del software, registra todos los

defectos en el registro de defectos.

5 Prueba del

sistema

El gerente de desarrollo o alternativas conduce las tareas de

prueba del sistema.

Prueba el producto en condiciones normales y de estrs.

Prueba el producto para la instalacin, la conversin y la

recuperacin.

Consigna todas las actividades de prueba en el registro de

la prueba.

El propietario del producto (desarrollador) asienta todos los

errores en el registro de defectos.

6 Documentacin El gerente de desarrollo o suplente se encarga de:

Producir el contorno usuario-documentacin y tareas.

La asignacin de estas tareas al equipo de documentacin.



Revisar el esquema con el equipo de pruebas de

integridad.

Elaborar la documentacin de usuario de primer ciclo.

Producir, revisar y corregir la documentacin del usuario.

Criterios de salida Un ciclo-1 integrado y probado del producto.

Formas logD y LOGTEST completadas para todas las

pruebas.

Documentacin del usuario completada y revisada.

Datos de tiempo, tamao y defectos introducidos en el

sistema de apoyo TSPI.

Humphrey, 1999

En conclusin, si no se llevan a cabo las pruebas al producto de software no se podr

garantizar su funcionamiento, lo cual ocasiona que no sea un producto de calidad. sta es

una de las ltimas fases del ciclo de vida del TSP. Ahora se tiene que hacer un anlisis de

todo lo ocurrido durante el desarrollo del producto en la fase post mrtem.

1.3.8. Fase post mrtem

sta es la fase de la culminacin del proceso de TSP. Se comienza con la evaluacin de

todas las tareas que se definieron para el proyecto, se verifican las metas del plan de calidad

y del trabajo del equipo.

Es necesario hacer un registro de todos los datos en formatos para su revisin, ver tabla 6.

(Humphrey, 1999).

A continuacin se ofrece un ejemplo de cmo registrar los datos para la fase post mrtem.

Tabla 7. Recoleccin de Datos

Propsito Recoger, analizar y registrar los datos del proyecto para evaluar el

equipo y el desempeo de cada funcin.

Identificar las formas de mejorar el proceso de ciclo 2 para producir

el informe ciclo-1.

Los criterios de ingreso Los ingenieros han completado y probado el producto.

Se han reunido todos los datos y completado todos los formularios.

General El informe de ciclo-1 contiene un anlisis del proyecto por cada

funcin.

El rendimiento general del equipo: lder del equipo.

Plan de actuacin frente al actual: gerente de planificacin.

Diseo de producto global y las normas: gerente de desarrollo.



Gestin del cambio y proyecto de apoyo: gerente de soporte.

La calidad de proceso y producto: gestor de calidad/proceso.

El informe ciclo debe:

Utilizar los datos de proceso para apoyar las declaraciones de los

ingenieros.

Cuidadosamente considerar el significado de los resultados

obtenidos.

Sea breve y conciso.

Paso Actividades Descripcin

1 Post mrtem

descripcin

general del

proceso.

El instructor describe el proceso post mrtem.

La necesidad de una informacin completa y precisa del proceso.

El contenido del informe de ciclo.

El proceso de evaluacin por pares y formas.

2 Revise los

datos de

proceso.

El responsable de calidad/proceso dirige el equipo en el anlisis de

los datos del proyecto y la identificacin de las reas problemticas a

mejorar.

El liderazgo, la planificacin, el proceso, la calidad o el apoyo.

Acciones y responsabilidades del equipo sugeridas.

reas de instructor o instalacin mejora.

Los ingenieros encargados de preparar y presentar PIP en estas

sugerencias de mejora.

3 Evaluar el

desempeo

del rol.

El lder del equipo lo conduce en la evaluacin de la eficacia de las

funciones del equipo, las acciones del instructor y las instalaciones

de apoyo.

Cundo eran eficaces.

Dnde hay margen de mejora.

4 Ciclo de

preparacin-

1. Informe

El lder del equipo lo conduce al esbozar el informe ciclo-1.

La asignacin de trabajo; informe a los miembros del equipo.

Obtencin de compromisos para la seccin informe de terminacin.

Montaje, revisin y correccin del informe completo.

5 Preparar

evaluaciones

de funciones

Cada ingeniero completa una evaluacin del equipo y de cada

participacin individual con base en el formulario PEER.

Dificultad y la contribucin de cada funcin.

Los porcentajes deben sumar 100%.

La eficacia de cada papel en escala de uno (inadecuado) a cinco

(superior).

Criterios de salida El ciclo de desarrollo ha resultado en un producto de alta calidad con

toda la documentacin requerida.

El producto terminado est bajo control de la configuracin.

Todos los datos de proceso se han evaluado y presentado PIP.



Las evaluaciones interpares se realizaron y sometieron (PEER).

El informe ciclo-1 se ha completado y presentado.

El cuaderno del proyecto se ha actualizado.

Humphrey, 1999

Al hacer la revisin de los datos de todo el proceso debe examinarse lo que cada miembro

del equipo hizo, adems de identificar qu parte del proceso realiz. Despus se hace una

comparacin del rendimiento obtenido por el equipo en lo planeado y metas fijadas al inicio

del ciclo, as se podrn identificar las reas del problema. Cuando se utiliza el proceso post

mrtem se podrn hacer los cambios necesarios para el prximo ciclo, corregir problemas

encontrados y determinar cules fueron las causas que ocasionaron las fallas para,

posteriormente, tomar medidas preventivas. Esto permitir llevar al equipo a la mejora

continua.

Cierre de la unidad

El TSP es una metodologa que sirve de gua para los ingenieros informticos; provee

mtodos para el fcil desarrollo de software por medio de miembros que llegan a formarse

en equipos, los cuales se desenvuelven de una manera organizada; tienen su roles y

actividades propias, los dirige un lder que recopila informacin y los mantiene ordenados

para lograr los objetivos planteados.

El ciclo de vida del TSP es una serie de ciclos que se llevan a cabo durante el desarrollo del

producto de software. Comienza con la declaracin de las necesidades del producto y

finaliza con la entrega final.

La fase de lanzamiento es pieza clave para el inicio del desarrollo del software; es aqu

donde se forman los equipos y se asignan las actividades que desempearan cada uno de

los miembros, como ya se explic aqu; pero esto lo vers con ms detalle, junto con la

elaboracin de planes de riesgo y calidad, en la prxima unidad.

Si se desea desarrollar un software, siempre es imprescindible utilizar un mtodo como lo es

el TSP, para lograr un producto confiable y de buena calidad; asimismo nos permitir mejorar

de una manera significativa todos los procesos implicados en el desarrollo.



Para saber ms

En la pgina del Institute Carnegie Mellon

(http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm), existe mucha informacin

acerca de las herramientas de medicin de la calidad del desarrollo de software, entre ellas

TSP, sobre la que encontrars diversos artculos y documentos.

Tambin puedes consultar un caso de uso de PSP y TSP en el documento Uso de

tecnologas y metodologas de desarrollo, de Roy Steeven Yarce David, que se encuentra

accesible en la seccin Material de apoyo.

Es recomendable revisar el documento de Watss S. Humprey, The Team Software Process,

donde se explica la metodologa TSP. La versin original de este documento, escrito en

ingls, se encuentra en la seccin Material de apoyo; si no posees el nivel de comprensin

de este idioma, puedes utilizar alguna de las diversas herramientas de traduccin que se

encuentran en Internet.

Fuentes de consulta

Colomo, R., y Paniagua, F. et al. (2011). Team Software Process. Madrid:

Universidad Carlos III de Madrid. Recuperado de http://ocw.uc3m.es/ingenieria-

informatica/desarrollo-de-sistemas-de-informacion-corporativos/material/TSP.pdf/view

Dharma Consulting Especialistas en Project Management (2013). Herramientas

gratuitas de gestin de proyectos. Recuperado de

http://dharmacon.net/herramientas/gestion-proyectos-ejemplos/

Gmez, A. y Ania, I. (2008). Introduccin a la computacin. Mxico: Cenage Learning.

Humphrey, W. (1999). Introduction to the Team Software Process. Massachusetts:

Addison Wesley Professional.

Kuna, H., Caballero, S. et al. (2008). Plan de Riesgos para la implementacin de

componentes de web 2.0. Recuperado de

http://www.amicus.udesa.edu.ar/documentos/6jornada/documentos/pdf/PONENCIA%

20MISIONES%20RIESGOS%20web2.0.pdf

Nord, Robert, McHale, J., & Bachmann, F. (2010). Combining Architecture-Centric

Engineering with the Team Software Proces. Pensilvania: Carnegie Mellon University



Olivera Sosa, . G. (2010). Planificacin y modelado. Escrcega: 2010.

Osorio, H. R. (2010). Roles en TSP. [En lnea]

http://es.slideshare.net/hansellramos/roles-para-t-s-p

Piattini, V. (2011). Calidad de sistemas de informacin. Mxico: AlfaOmega/Ra-ma.

Queensland, T. U. (2010). Lecture 14: The Team Software Process. CSSE3002 The

Software Process. Recuperado de

http://itee.uq.edu.au/~csse3002/Lectures/Lect14.pdf

Real Academia Espaola (2009), Diccionario de la lengua espaola, 22a. ed.

Recuperado de http://lema.rae.es/drae/?val=equipo

Secretara Central de ISO. (2005). Norma Internacional ISO 9000:2005. Sistemas de

gestin de la calidad. Fundamentos y vocabulario. Ginebra: ISO. Recuperado de

http://www.congresoson.gob.mx/ISO/normas/ISO-9000-

2005_Fundamentos_y_Vocabulario.pdf

Sommerville, I. (2006). Ingenieria de software. Madrid: Pearson Educacin.

Trujillo, D. (2009). Team Software Process. [Mensaje de un blog]. Recuperado de

http://dtrujilloa-tsp.blogspot.mx/

Tuya, Javier; Ramos Romn, Isabel & Dolado Cosn, Javier (2007). Tcnicas

cuantitativas para la gestin en la ingeniera del software. La Corua, Espaa:

Netbiblo

Bibliografa de la imagen:

Dreamstime (2013). Engranajes del asunto. Recuperado de:

http://thumbs.dreamstime.com/x/engranajes-del-asunto-28681457.jpg

Fecha de consulta: 5 de junio del 2013

Unidad 1. Introduccion a TSP

Documents

Transcript of Unidad 1. Introduccion a TSP