Unidad 1. Introduccion A TSP

Desarrollo de Software en Equipo TSP
Unidad 1. Introduccin a TSP
8 Cuatrimestre
Programa de la asignatura:
Clave:
150930934
Universidad Abierta y a Distancia de Mxico

UnADM
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

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 ....................................................................... 7
1.1.2. Estrategia de TSP ......................................................................................... 8
1.1.3. Equipo TSP ................................................................................................... 9
Foro de la asignatura ....................................................................................................... 10

Actividad 1. Elementos de la metodologa TSP ................................................................ 10
1.2. Estructura del Team Software Process (TSP). ...................................................... 11
1.2.1. Disciplina de Equipo .................................................................................... 13
1.2.2. Disciplina de Administracin........................................................................ 14
1.2.3. Disciplina de Ingeniera ............................................................................... 15
Actividad 2. Estructura base de la metodologa TSP ........................................................ 16
1.3. Ciclo de Vida del Team Software Process (TSP) ................................................... 16
1.3.1. Fase de Lanzamiento .................................................................................. 17
1.3.2. Fase de Estrategia ...................................................................................... 25
1.3.3. Fase de Planeacin .................................................................................... 28
1.3.4. Fase de Requerimientos ............................................................................. 30
1.3.5. Fase de Diseo ........................................................................................... 31
1.3.6. Fase de Implementacin ............................................................................. 32
1.3.7. Fase de Pruebas ......................................................................................... 33
1.3.8. Fase Postmortem ........................................................................................ 35
Autoevaluacin ................................................................................................................. 37
Evidencia de aprendizaje. Identificacin de los elementos de la metodologa TSP .......... 37
Autorreflexiones ............................................................................................................... 38
Cierre de la unidad ........................................................................................................... 38
Para saber ms ................................................................................................................ 39
Fuentes de consulta ......................................................................................................... 40
1

1. Introduccin a TSP
Presentacin de la unidad
Te damos la ms cordial bienvenida a la asignatura Desarrollo de software en equipo TSP
(Team Software Process), la cual, forma parte del octavo cuatrimestre de la Ingeniera en
Desarrollo de Software.
La metodologa PSP (Personal Software Process) est orientada a un contexto individual del
ingeniero en desarrollo de software, sin embargo, TSP es una metodologa que est
orientada a equipos de trabajo y para que los miembros del equipo logren la efectividad
deseada de acuerdo a los roles que desempean dentro del mismo, es necesario contar con
una metodologa como PSP , que gue 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 alcanzar los objetivos trazados al inicio del proyecto.
En la unidad uno Introduccin a TSP aprenders los elementos, objetivos y principios en los
cuales se basa esta metodologa, as como su estrategia y estructura, misma 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
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)

Team Software Process (TSP) fue creado por Watts Humphrey en 1996. Es un proceso de
desarrollo de software en equipo y una metodologa que gua a los Ingenieros de software a
asegurar la calidad en los diferentes procesos del ciclo de vida de desarrollo de software y
principalmente la productividad de los equipos de trabajo (Ingenieros, administradores y
desarrolladores de software) para cumplir con sus objetivos (Gomez de Silva & Ania., Et al
2008). Cuando se habla de objetivos de un proyecto de desarrollo de software hay un
objetivo en particular muy importante que se tiene que cumplir, esto es que el tiempo que
dure el proyecto no debe de rebasar lo planeado al inicio del mismo. En este contexto,
implementar la metodologa TSP dentro de una organizacin ayuda a tener una mtrica
exacta de costos y la retroalimentacin de proyectos pasados para reducir tiempos y por
supuesto costos.
Para comprender la metodologa TSP es necesario saber qu es un Proceso de desarrollo
de software o tambin denominado Ciclo de vida de desarrollo de software. No es ms
que una estructura que nos indica las etapas que tiene que cumplir todo desarrollo de
software. Es muy importante saber que es un proceso de desarrollo de software, ya que TSP
es una metodologa que debe de ser utilizada dentro de este proceso. Existen muchos
procesos de desarrollo de software pero la mayora se basan en el modelo en cascada, TSP
puede utilizar cualquier otro modelo de ciclo de vida, la razn por la que se menciona el
modelo en cascada es porque es el ms utilizado y el 90% de los modelos que existen en la
actualidad, estn basados en l.
El Modelo en Cascada indica que todo desarrollo basado en este modelo 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 no es ms que
visitas con el 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, esta parte cambiar de acuerdo a la metodologa que se implemente para
realizar el desarrollo del sistema, pero nunca debe de faltar sea cual sea la
metodologa a implementar, documentos donde se muestren los objetivos, visin,
roles, puestos y los requerimientos del sistema a desarrollarse.
Diseo del sistema y el software: En esta fase nuevamente 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: En esta fase intervienen los desarrolladores

de software y prcticamente en esta fase se desarrolla por completo el sistema.
Integracin y pruebas del sistema: Aqu se observa ya un producto terminado y las

personas designadas en el rea de pruebas y calidad de software revisan que el
sistema no tenga fallos y si los hay se devuelve el producto a los desarrolladores para
que se 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 cuenta con una versin
terminada del sistema que se lleva directamente con el cliente para que lo prueben y
verifiquen su correcto funcionamiento ya en el rea de produccin. Si hay nuevos
requerimientos se vuelve a regresar a la primer fase para iniciar las mejoras para el
sistema (Sommerville, 2006).
En la siguiente figura se muestra una representacin del modelo en cascada:

Definicin de
requerimientos
Diseo del
sistema y del
software
Implementacin y
prueba de
unidades
Integracin y
prueba del
sistema
Funcionamiento y
mantenimiento
Figura 1. Modelo en cascada (Sommerville, 2006).
Entonces decimos que TSP es un Proceso de desarrollo por que cumple con esta estructura
pero con sus propias fases que ms adelante se explicarn.
Se recomienda el uso de TSP en grupos de entre 2 a 20 personas y en desarrollos de
sistemas que sean a gran escala.
TSP se centra principalmente en la administracin de proyectos, la construccin de los
equipos de trabajo de acuerdo a los roles y el perfil de cada persona que se necesiten para
los distintos puestos dentro del proyecto.
En un proyecto de desarrollo de software se selecciona a la cantidad de personal que
requieren 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 soporte, los cuales se explicarn con ms detalle en el apartado 1.3 Fases del ciclo de
vida de TSP.
A comparacin de PSP, TSP se enfoca en la gestin del equipo de trabajo y PSP en la
calidad pero no de todo el proceso de desarrollo ni del equipo, si no de la calidad y la gestin
individual, en especial enfocada en los desarrolladores de software, para tener una mtrica
exacta de su productividad y en base a esto poder mejorar la calidad en su trabajo.
Retomando a Piattini Velthuis (2011), se afirma que TSP se basa en los siguientes
elementos:
Administracin autodirigida a equipos de trabajo: como se mencion anteriormente a

comparacin de PSP, TSP est totalmente orientado a equipos de trabajo.
Est integrado de indicadores: los indicadores indican los pasos realizar y en qu
orden realizarlos.
Es un sistema de administracin de calidad: TSP tiene como principal propsito
asegurar la calidad en el desarrollo de software para que se llegue a 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:
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 se pueden aprender durante el desarrollo del proyecto.
Modelo de coaching: Mtodo que tienen como propsito instruir y dirigir a las
personas con el nico fin de lograr los objetivos y desarrollar habilidades especficas
de acuerdo a las actividades y roles que desempeen dentro del proyecto.
Un desafo muy importante de TSP es la comunicacin que existe 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 en dicho
desarrollo, los objetivos del proyecto de acuerdo a la metodologa TSP los establecen los
Ingenieros de software.
Es importante que todos los involucrados en el proyecto tengan claros los objetivos para
poder llegar a la meta en tiempo y forma, pero para lograr esto se debe asignar a cada
persona en el puesto indicado de acuerdo a sus habilidades, conocimientos y experiencia,
para de esta forma asegurar que se cuente con 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 por
supuesto si existe retroalimentacin entre los miembros del equipo. TSP cuenta con
mediciones claras establecidas y est diseado para utilizarse de manera cclica, el
uso de pequeos ciclos 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 el mismo.
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.
En este captulo se revis el significado de TSP, 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 que integran ese equipo.
Tambin se revis lo correspondiente a el significado del ciclo de vida de desarrollo de
software como un proceso, explicando a detalle el modelo en cascada y cada una de sus
fases y por ltimo, los principio y objetivos que tiene esta metodologa. En el siguiente
captulo se revisar el tema de la estrategia de TSP, donde podrs identificar la importancia
de los equipos de trabajo as como las estrategias para conformar un buen equipo de trabajo
para poder implementar esta metodologa de desarrollo de software dentro de una
organizacin.

1.1.2. Estrategia de TSP

Se puede decir que las estrategias son actividades bien estructuradas y planificadas para
lograr el objetivo o los objetivos que se tengan planeados, segn la RAE (2013), la palabra
estrategia proviene del latn stratega, y sta del griego , y se define como el []
Arte de dirigir las operaciones militares. [] Arte, traza para dirigir un asunto. [] En un
proceso regulable, conjunto de las reglas que aseguran una decisin ptima en cada
momento.
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 en cada una de sus etapas.
TSP se conforma de ocho procesos: lanzamiento, estrategia, plan, requerimientos, diseo
implementacin, prueba y postmortem, 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 de desarrollo el cual ser elegido de acuerdo al tamao y la
complejidad del proyecto.
Por ejemplo tomemos el modelo en cascada, este modelo 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 Velthuis, 2011). Siempre se inicia con una junta donde los
ingenieros de software y lderes 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, basndonos en el modelo en 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.
Cmo 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 8 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 que nos marca TSP.

1.1.3. Equipo TSP

En algn momento, a todos nos ha tocado trabajar en equipo en la escuela o al realizar
algunos juegos o en el campo laboral, segn la RAE (2013) un equipo es [] Grupo de
personas organizado para una investigacin o servicio determinado [...]. En el contexto de
TSP, metodologa que como se mencion anteriormente, fue creada pensando en los grupos
de trabajo y est dirigida hacia el trabajo en conjunto y la retroalimentacin, sin embargo,
para que un equipo se forme con base en esta metodologa hay algunas condiciones que se
deben crear para establecer un equipo de trabajo, mismas que se mencionan a continuacin
(Piattini Velthuis, 2011):
El equipo 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 (estos los establecen los ingenieros de software y
administradores del proyecto) especfico el cual debe seguir porque es una gua de lo
que debe hacer.
Para poder conformar un equipo efectivo de ingenieros se necesita que:

Los integrantes estn cualificados con las capacidades y habilidades necesarias para
desempear el rol que se les asigne.
El objetivo del proyecto sea claro, realista y bien definido.
Los recursos que se asignen al equipo deben de ser acordes al trabajo que van a
realizar.
Los integrantes del equipo deben de estar motivados y comprometidos para lograr el
objetivo.
Los miembros del equipo 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 roles bien definidos y objetivos en comn por parte de los miembros del
equipo.
Definir procesos en comn para su trabajo.
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 del equipo 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 captulo se revis lo referente a las condiciones necesarias para crear equipos de
trabajo adecuados para implementar la metodologa TSP. En el siguiente captulo
identificars los elementos d la metodloga TSP y la relacin que existe entre ellos.
Foro de la asignatura
Esta actividad tiene como finalidad, ser un espacio de integracin de todos los participantes
del grupo y conocer las expectativas que tienen acerca de la asignatura.
1. Realiza una presentacin y comparte con tus compaeros algunos datos sobre ti
con el fin de que el grupo se integre.
2. Comparte tus expectativas de la asignatura.
3. Utiliza el foro en el transcurso de la asignatura para compartir dudas u
observaciones, diversas inquietudes, informacin adicional que localices y que
pueda ser de utilidad a tus compaeros de grupo y facilitador.
Es importante que realices tus participaciones en un clima de tolerancia, respeto y
colaboracin.
Actividad 1. Elementos de la metodologa TSP

En esta actividad identificars los elementos de TSP y la relacin que existen entre ellos
como un proceso con base en lo estudiado en el tema 1.1 Proceso de desarrollo de TSP,
para ello, sigue estos pasos.
1. Identifica y redacta un problema hipottico, de tu vida cotidiana, en tu escuela o
mbito laboral (si fuera el caso) o con base en tu formacin profesional sobre un
problema que se presente a un desarrollador de software, al cual puedas dar
solucin mediante los elementos de la metodologa TSP.
10

2. Identifica en el problema los elementos del proceso de desarrollo de TSP:

elementos, principios y objetivos, estrategias y las condiciones para establecer un
equipo TSP.
3. En un archivo de texto o presentacin de plantillas elabora un mapa mental donde
expongas los elementos grficos que ejemplifiquen o representen a cada uno de
ellos as como la relacin que existe entre los mismos y la forma en que solucionan
el problema.
4. Explica tu mapa mental mencionando cul es la relacin entre los elementos de
TSP, as como las imgenes que consideras ilustran los mismos.
5. A continuacin, redacta una conclusin acerca de la importancia de esta
metodologa en el mbito del desarrollo de software.
6. Sube tu archivo con el problema, el mapa mental y tus conclusiones a la base de
datos.
7. Posteriormente, comenta el trabajo, al menos, dos de tus compaeros(as), respecto
al problema, el mapa mental y sus conclusiones. Realiza tus comentarios con
respeto y de forma constructiva.
8. Guarda tu actividad con la nomenclatura DDSE_U1_A1_XXYZ. Sustituye las XX
por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por
tu segundo apellido.
*Consulta el documento Criterios de evaluacin de actividades U1, para ver la rbrica de la
actividad y conocer los parmetros de evaluacin
1.2. Estructura del Team Software Process (TSP).

Se puede decir que TSP es una estructura porque se conforma de partes y procesos que se
encuentran relacionadas y que indican las acciones o actividades a ejecutar y el orden en el
cual deben desarrollarse. Es muy importante en la implementacin de TSP, ya que indica los
pasos a seguir al momento de trabajar en equipo, al crear el equipo y ejecutar acciones
individuales.
11

Una de las ms grandes ventajas de TSP, es que proporciona una estructura bien definida
para guiar a los ingenieros y administradores a llevar por buen camino a un equipo de
trabajo. Esta estructura tambin especifica los pasos y medidas necesarias para formar un
equipo eficaz en un buen ambiente de trabajo.
En la siguiente figura se muestra la estructura de TSP:
Figura 1.2.1. Estructura de TSP (Gomez de Silva & Ania ).

En la parte superior de la imagen en los recuadros se encuentra la metodologa que se va a
usar en esa disciplina, por ejemplo en disciplina ingenieril se refiere a PSP ya que se trata
del trabajo y habilidades que cada miembro del equipo debe tener. En las siguientes dos
disciplinas: disciplina de equipo y disciplina de administracin, se crean los equipos y se
ejecuta el trabajo en equipo, para ello, se utiliza la metodologa TSP. El conjunto de las tres
disciplinas da como resultado equipos de trabajo bien conformados e integrados.
Se refiere a disciplinas porque dentro de cada una nos muestra los pasos (en TSP se llaman
fases) bien definidos y estructurados que se van a ejecutar, al ser 3 disciplinas, llegaremos a
12

formar equipos integrados hasta que las 3 se hayan completado al 100% ejecutando cada
una de sus fases. A continuacin se explicarn cada una de las disciplinas que conforman la
estructura de TSP.
1.2.1. Disciplina de Equipo

Debido a que la estructura de TSP se divide en 3 disciplinas es necesario explicar cada una
con sus respectivas fases. En este subtema aprenders la disciplina de equipo con sus
respectivas fases.
La disciplina de equipo son una serie de reglas que debe de llevar a cabo el equipo 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: se puede decir que los 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 ponerle su propio sello de calidad al
desarrollo, esto se lleva a cabo en las pruebas que cada uno de ellos realiza. Las
pruebas se realizan de acuerdo al funcionamiento que debe de tener el mdulo del
sistema que estn desarrollando. Es muy importante hacer nfasis en que estas
pruebas son provisionales por que 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, esta parte 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 para llevar a cabo el desarrollo del software y as tener
una visin ms clara acerca de a dnde se desea llegar.
Plan propio: Cada equipo debe de tener su propio plan, los planes los establecen los
administradores al inicio del proyecto y aprenders como se hacen 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 los riesgos que puedan surgir durante el desarrollo del software, todos
13

estos planes los veremos con mas a detalle en la Unidad 2 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 a las capacidades y cualidades de cada
persona y sin establecidas 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 realizar el proyecto de software por el
cual contrata o integra un equipo TSP.
En conclusin al subtema, se puede decir que esta disciplina de equipo indica reglas muy
precisas que guan las actividades del equipo para que se logren los objetivos del proyecto,
son 3 disciplinas: ingenieril, de equipo y de administracin, en el siguiente subtema
hablaremos sobre la disciplina de administracin.
1.2.2. Disciplina de Administracin

Como se mencion en el subtema anterior la estructura de TSP se basa en tres disciplinas,
ya vimos la disciplina que est orientada al equipo, en este subtema aprenders la disciplina
enfocada a la administracin del proyecto a desarrollarse.
Esa disciplina muestra la forma en que los administradores del proyecto deben guiar al grupo
para cumplir los objetivos del proyecto de software que se desarrollar.
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 ejecutando al pie de la letra la metodologa TSP.
Costo de la calidad: de acuerdo a la calidad ser el coste, hay que asegurar que los
costos sean adecuados para llegar a la calidad planeada al inicio del proyecto. Los
costos sern adecuados al tiempo y de acuerdo con lo robusto que sea el sistema
que se vaya a desarrollar, 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 definen procesos bien definidos los
administradores deben de revisar que estos procesos se cumplan, esto se aprender
en el tema 1.3 Ciclo de Vida del Team Software Process (TSP).
Revisin de status de calidad: revisar peridicamente el estado de la calidad del
software, esto se revisa en plantillas y reportes de los cuales se auxilian tanto los
desarrolladores como los administradores estas revisiones aprenders como hacerlas
en la Unidad 3 Gestin en TSP.
Comunicacin: la comunicacin entre los miembros del equipo de desarrollo del
proyecto, no solo permite que se llegue a los objetivos deseados, tambin nos sirve
14

para tener un buen ambiente de trabajo y por supuesto la retroalimentacin que

ayuda a los miembros del equipo a no cometer errores que se hayan cometido
anteriormente ya sea en el mismo proyecto o en proyectos anteriores.
Como pudimos observar, la disciplina de la administracin se basa totalmente en los
administradores y en la forma en que medirn el nivel de calidad que se obtenga durante el
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 saben que forman
parte del grupo pero deben de 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
tiene que estar consciente de la importancia que representa para que el objetivo se cumpla.
Mtodo de planeacin: cada miembro debe manejar y planear correctamente sus tiempos y
las responsabilidades que tiene en ese lapso de tiempo.
Valor agregado: cada miembro del equipo aportar su experiencia y conocimiento en el
desarrollo de los proyectos.
Mtricas de calidad: las mtricas son un nivel de referencia exacto 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 la
Unidad 3 subtema 3.2. Diagnstico: Mtricas de calidad versus trabajo realizado
Procesos definidos: estos procesos muestran a los miembros del equipo un panorama
general para poder 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 pudimos aprender las disciplinas son como recetas de cocina que nos dicen
qu acciones tomar en todas y cada una de las fases de desarrollo del proyecto. En el
siguiente tema aprenderemos la forma en que est estructurado el ciclo de vida de la
metodologa TSP.
15

Actividad 2. Estructura base de la metodologa TSP
En esta actividad identificars la estructura base de la metodologa TSP mediante un mapa

mental, para ello, sigue estos pasos:
1. Elabora un mapa mental en una presentacin multimedia o en un archivo de texto,
por cada disciplina de la estructura base de la metodologa TSP, donde expongas la
relacin que existe entre ellas, representando con imgenes cada una de sus
caractersticas y fases de la disciplina correspondiente: ingenieril, de equipo,
administrativa. Es necesario que las imgenes y texto tengan relacin congruente
con cada una de las fases de la disciplina correspondiente.
2. Al finalizar tu mapa mental, explica la imagen que integraste representando a cada
disciplina, y por qu consideras que tiene relacin con la fase a la que corresponde.
Integra en tu explicacin la relacin que existe entre cada una de ellas y una
reflexin sobre la importancia de estas disciplinas en el quehacer del ingeniero en
desarrollo de software.
actividad y conocer los parmetros de evaluacin
1.3. Ciclo de Vida del Team Software Process (TSP)

El Ciclo de vida del TSP se conforma de una serie de ciclos organizados en ocho fases los
cuales pueden ir desde un ciclo hasta n ciclos, esto depender de la magnitud del proyecto
estos comienzan con los requerimientos del producto de Software, en cual se establecer lo
que se quiere lograr y se comenzar empezar con la creacin de diseos detallados del
software y este a su vez ser revisado por todo el equipo para que posteriormente este
diseo se convierta en cdigo , de igual modo ser revisado y analizado para realizar las
pruebas pertinentes. Finalmente se analizar la calidad del producto de software terminado,
es entonces cuando el ciclo de vida del TSP llega a su fin (Nord, R.L., 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, estas
16

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 se deben de
llevar 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 tema 1.3.1
Fase de lanzamiento. Cada una de las fases describe las actividades que involucra a cada
una de ellas y que se explican a continuacin (Humphrey, 1999).
Fases de TSP
Lanzamiento
Estrategia
Planeacin
Requerimientos
Diseo
Implementacin
Pruebas
Posmortem
Figura 1.1 Fases del Ciclo de Vida del TSP (Humphrey, 1999).
1.3.1. Fase de Lanzamiento

En este tema 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,
as como 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 manera individual y en equipo, en la tabla 1.3.1 observars un ejemplo
de los objetivos planteados de manera individual.
17

Es de gran importancia definir los objetivos de tal manera que puedan llegar a ser medibles
para poder determinar la calidad del producto generado (Ver Tabla 1.3.1). Se deben
establecer objetivos que sean ambicioso para los miembros del equipo, pero sin alejarse de
la realidad (ser un miembro del cooperativo y eficiente, Realizar un trabajo personal
disciplinado, etc.). Realizar los objetivos por escrito ayudar de manera significativa al equipo
para poder evaluar peridicamente 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.3.1 Objetivos propuestos para los miembros del equipo y sus indicadores. (Garza,
2008).
Objetivos
Ser un
miembro del
Equipo
cooperativo y
efectivo
Realizar un
trabajo
personal
disciplinado
Planear y dar
Indicador 1
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. (esta
es una medicin
de la eficacia y/o
eficiencia la cual
el equipo
determina, el
equipo es quien
establece estas
mediciones).
El porcentaje de
los datos
personales
(desempeo
eficacia,
etctera)
registrados debe
ser 100%
El porcentaje de
Indicador 2
Indicador 3
Indicador 4
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
El porcentaje de
semanas
registradas en el
documento
semanal debe
ser 100%
El porcentaje de
18

seguimiento al
trabajo
personal
Hacer
productos de
calidad
los datos del

proyecto
personal
registrados en
las formas
correspondientes
debe ser 100%
El porcentaje de
defectos
encontrados
antes de la prime
compilacin
debe ser mayor
a 70%
las tareas del

proyecto con
plan y datos
reales
registradas en
forma
correspondiente
debe ser 100%
La densidad de
defectos
encontrados
durante la
compilacin
debe ser menor
a 10/KLOC.
La densidad
de defectos
encontrados
durante la
prueba de
unidad debe
ser menor a
5/KLOC.
La densidad
de defectos
encontrados
despus
encontrados
durante la
prueba de
unidad debe
ser 0.
Tabla 1.3.2 Objetivos propuestos por el equipo y sus indicadores. (Garza, 2008)
Objetivos
Indicador 1
Indicador 2
Indicador 3
El porcentaje de
La cantidad de
Al terminar el
defectos
defectos
proyecto se debi
Producir producto
encontrados antes
encontrados en la
haber incluido el
de calidad
de la primera
prueba del sistema
100% de las
compilacin debe
debe ser 0.
funcionalidades
de ser 80%.
Llevar a cabo un
proyecto
productivo y bien
administrado
El error en la
estimacin del
producto debe ser
menor a 20%
Terminar el
proyecto a tiempo
El total de das de
retraso o adelanto
para completar el
ciclo debe ser
menor a 4.
El error en el
nmero de horas de
desarrollo debe ser
menor a 20%
El porcentaje de
datos del proyecto
debe ser 100%
19

En la tabla 1.3.1 y 1.3.2 se muestran los objetivos planteados y sus indicadores que son los
criterios que se evaluarn en cada objetivo, el cual se le establece un valor que el equipo
tendr que asignar para que pueda ser medido.
En la fase de lanzamiento se programan una serie de reuniones en las cuales participan
todos los miembros del equipo para poder generar el plan del Lanzamiento. Se recomienda
darle seguimiento a estos planteamientos para poder generar el plan de Lanzamiento:
Las empresas necesitan
metas de gestin de
requisitos del producto.
Qu?
Los objetivos
del equipo.
Diseos
Conceptuales.
Productos
Planeados.
Cmo
?
La
estrategia
de equipo.
El equipo
define el
proceso.
Cundo?
Quin
?
Plan de
Tareas
Funciones
del Equipo
Plan de
Calendario
Planes de
trabajo
Qu
tan
Bien?
Plan de
Calidad
Qu
pasa
Si?
Evaluacin de
Riesgos
Plan de
Alternativas
Plan de Valor
Agregado
Tamao de
estimaciones.
Lanzamiento del TSP (Queensland, 2010).
20

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 seguir para poder 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 haba 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).
El ingeniero que tenga este rol debe realizar reportes semanales avances del equipo (Osorio,
2013). En la siguiente tabla 1.3.3, se muestra un ejemplo para generar los reportes de
avances del equipo.
Tabla 1.3.3. Reporte de Avances de Equipo (UABC, 2005).
Reporte Semana TSP

Nombre:
Fecha:
Equipo:
Ciclo:
Semana:
21

Datos Semanales
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
Planeado
Actual
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
AD Administrador de
Desarrollo
ACP Administrador de
Calidad/Proceso
AA Administrador de
Apoyo
El lder de proyecto bsicamente es el representante ante el cliente y el encargado de llevar

a cabo la integracin de la planeacin e implementacin de todas las tareas que llevaran a
22

cabo todos los involucrados en el desarrollo del producto de software dndoles seguimiento
para poder 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 precisamente en el instante en que el proyecto se encuentra
en fase de diseo, deber ser el ingeniero con mayor conocimientos en diseo, aqu toma el
mando del proyecto. Debe adems, formular las actividades que requiera la etapa de diseo
y asegurarse de que todas estas se realicen a cabalidad (Osorio, 2013).
Las funciones principales del administrador de Desarrollo son (Osorio, 2013):
Proponer estrategias de desarrollo (Se describir ms delante de este tema).

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 mutuamente en

algunas ocasiones con cada uno de los roles que desempean los miembros del equipo.
Administrador de Planeacin
El administrador de planeacin es el principal responsable de llevar el control de los planes
del equipo y de darle a poyo a cada miembro del equipo cuando se presenten problemas que
estn relacionadas con el plan.
Debe de dirigir la generacin del plan de trabajo en cada ciclo de desarrollo y establece
como estar definidas las partes del producto final, esto se refiere a lo que se va hacer,
quienes lo van a hacer, cuanto se va a hacer, etc. Del cual depender la complejidad y
factibilidad (est ligado a los objetivos propuestos, hasta donde se va a llegar) del proyecto.
(Osorio, 2013).
23

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 de calidad, y le da seguimiento a la calidad del producto.
Tambin el administrador de calidad determinar las necesidades dentro del proceso de
calidad que se implementara en el proyecto de software y se le pueda dar seguimiento para
que este a su vez mantenga la calidad del producto (Osorio, 2013).
Son funciones bsicas del administrador de calidad:
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 y como todos los anteriores roles.
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
lleve a cabo los estndares y patrones de calidad y alertar al lder del proyecto cualquier
trabajo que no sea de calidad.
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, este documento debe indicar 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).
24

Es el responsable de coordinar todas las actividades de cambio que lleguen a realizar

cualquier miembro del equipo
El administrador de configuraciones debe administrar el versionamiento (esto se refiere a la
gestin de diversos cambios que se llegan a realizar en algn producto de software) del
producto de software, es decir, administrar el control de cambios y su sistema, recomendar
los cambios que deben realizarse o ajustes cuando esto le amerite, verificar, mantener y
evaluar la persistencia del sistema, fomentar el re-uso de cdigo y de recursos y como todos
hacer 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 ya que 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
para la fase de Estrategia.
1.3.2. Fase de Estrategia

Ya se explic lo que se debe de realizar en la fase de lanzamiento para dar inicio al
desarrollo del producto de software, al tener la elaboracin de los equipos y roles ahora es
necesario hacer las estrategias a seguir para poder dale 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, analizando e identificando las estimaciones de tamao y
esfuerzos que se requieran.
Despus de que se finaliza la etapa de lanzamiento se deben llevar a cabo las estrategias a
seguir durante el desarrollo del producto en cada una de las fases. 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:
Es importante medir el tiempo real del desarrollo y el tiempo disponible.
25

Dcorbaxeo SEO (2009).

Crear el diseo conceptual del producto: Es el punto de arranque para poder hacer una
planificacin del proyecto, ya que se hace un plan para la elaboracin del producto. Para la
elaboracin del diseo conceptual los miembros del equipo deben se basarse en
experiencias previas con la finalidad de saber cmo se puede desarrollar el siguiente
producto. Esto se crea haciendo uso de diagramas UML (Lenguaje Unificado de Modelado)
es un lenguaje grafico que permitir especificar, visualizar, construir y documentar un
sistema de software y reviste gran importancia como gua del equipo de trabajo en todo el
proceso de desarrollo de software.
Elementos de diseo de un producto. Logismarket (2013)

26

Establecer la estrategia de desarrollo: El equipo decide cual es la mejor manera para

dividir el trabajo entre los ciclos y lo que ser producido en cada uno de estos. Puede hacer
uso de Herramientas CASE.
Estimacin de tamao y esfuerzo: Esto se refiere al tamao estimado que tendr el
producto y el tiempo que se llevar en realizarlo. Se debe considerar el tiempo que se tiene
disponible para poder hacer los a ajustes necesarios a la estrategia, para que de esta
manera los tiempos puedan coincidir. Puede hacer uso de la gua del PMBOK dentro del
captulo 6.1 para poder hacer las estimaciones dichas anteriormente.
Plan de gestin de riesgos: Para realizar un plan de riesgos primeramente se tiene que
estar total mente comprometidos con el proyecto, a elaborar un producto de calidad. A
continuacin en la tabla 1.3.2 se muestra un ejemplo de gestin de riesgos.
La siguiente tabla corresponde a ejemplo de un plan de riesgos que se implement en el
desarrollo y mantenimiento de componentes para de Web 2.0 en Bibliotecas especializadas.
Tabla 1.3.2. Ejemplo de gestin de Riesgos (Kuna, Caballero, & Eunice, 2008).
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, provocara
atrasos en el desarrollo e implementacin del proyecto.
Que informacin se necesita para seguir el estado del riesgo:
Documentos de estado de avances de trabajos individuales, en donde se

explayen las tareas realizadas y las dificultades presentadas y si estas fueron
solucionadas con xito como se solucionaron dichas dificultades.
Planilla de informe de Errores y soluciones.
Quien es responsable de realizar las actividades de control del riesgo: el

responsable es el Jefe del proyecto, integrantes del equipo de trabajo.
Que recursos se necesitan para realizar las actividades de control del riesgo: para
realizar un adecuado control de este riesgo se necesitar personal capacitado para
validar las funciones desde el punto de vista tcnico/bibliotecolgico. Si el control
corresponde a una actividad informtica, este personal deber tener amplios
conocimientos en cuanto a la tecnologa incluida en el proyecto, si el control
27

corresponde a una actividad bibliotecolgica este personal deber tener conocimiento

de tecnologa aplicables a la bibliotecologa.
Plan de Accin
Cursos de capacitacin de tecnologa Web 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: plan de avance no refleja los resultados esperados, falta de calidad
en el producto
Contratar una Consultara Experta en tecnologa Web 2.0
El TSP recomienda que las estrategias definidas sean documentadas para darles un
continuo seguimiento.
En este tema se describi lo que es una estrategia y la manera en que se debe desarrollar.
Esto tiene como objetivo hacer un producto de calidad, para esto el equipo debe estar de
acuerdo con los criterios de la estrategia y darle seguimiento a estas, teniendo en cuenta lo
antes mencionado permitir saber cmo se va a realizar el producto de software. Estas
estrategias ayudarn al equipo para poder preparar la planeacin, la cual se explicar en el
siguiente tema.
1.3.3. Fase de Planeacin

Antes de entrar a esta fase el equipo debi de haber analizado las necesidades y crear un
diseo conceptual de la estimacin de tamao del producto en la fase de lanzamiento y en la
fase de estrategia las estimacin de tiempo que llevar su desarrollo, se tendrn las bases
para poder pasar al siguiente proceso que en este caso es la planeacin, teniendo en cuenta
lo antes mencionado en este tema se describir lo que se debe hacer para poder tener una
buena planeacin.
28

Dentro de la fase de planeacin los miembros del equipo generan un plan de trabajo, el cual
puede contener un inventario de los elementos que sern utilizados por el equipo. Este
puede contener.
Estima el tamao de cada parte a ser desarrollada. Este ser determinado por el
tamao del trabajo.
Se identifican las tareas: se estima el tiempo para completar cada tarea. Para
esto es necesario asignar las tareas a cada miembro del equipo.
Hacer un cronograma semanal para tareas terminadas. Se puede hacer uso de
herramientas como por ejemplo Microsoft Project, y hacer diagramas de Gantt para
llevar el control de las actividades, dentro del mismo se programadas las tareas con
fecha de inicio y fecha de trmino, la duracin y por ltimo se lleva un control del
porcentaje de cumplimiento de dicha actividad por semana.
Hacer un plan de calidad. El plan de calidad es un documento que especifica qu
procedimientos y recursos asociados deben aplicarse, quin debe aplicarlos y cundo
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 en la
cual encontrars herramientas gratuitas de gestin de proyectos y podrs observar los
lineamentos establecidos para realizar un control de calidad.
En el caso de los objetivos de calidad que encontramos en la Lnea Base de Calidad del
Proyecto se refiere a la medicin con la que evaluaran el cumplimiento de estos, las cuales
sern establecidas por el equipo de trabajo. En cuanto a 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 que no es ms que el
patrocinador o cliente.
Dependiendo del tamao del proyecto ser la complejidad para poder crear un plan de
desarrollo, el hacer un plan permitir trabajar de una manera ms eficiente de calidad. En el
siguiente tema se aplicar lo planeado con base a los requerimientos del desarrollo del
software.
29

1.3.4. Fase de Requerimientos

A continuacin revisars algunas recomendaciones necesarias para poder conocer las
especificaciones de requerimientos de Software, y el anlisis de necesidades y los criterios
necesarios para poder hacer lo que en verdad se quiere.
Una vez que se ha concluido con la fase de planeacin se pueden gestionar los
requerimientos, estos se pueden establecer con entrevistas con los clientes para poder ir
determinando lo que se va a producir (Humphrey, 1999). En esta fase es donde 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
llega a ocasionar que los requerimientos sufra cambios constante mente, los clientes creen
estar seguro de lo que desean, pero esto no siempre es as, es por esto que no se debe de
caer en suposiciones de lo que el cliente en realidad desea. Se deben de tener claro de lo
que el usuario realmente quiere.
La fase de requerimientos sugiere las siguientes actividades:
Anlisis de necesidades del cliente: Para esto se hacen entrevistas con el cliente donde
se realizan una serie de preguntas y respuestas que deben de ser lo suficientemente claras
para poder analizar las necesidades del cliente. Debe de haber participacin de todos los
involucrados tanto por parte del cliente as como los integrantes del equipo para que puedan
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: Estos se clasifican en:
Requerimientos Funcionales: Estos describen los servicios que debe proporcionar

el sistema y el comportamiento que tendr en ciertas circunstancias. Los
requerimientos dependern del tipo de software que se est desarrollando. Se
presenta a continuacin un ejemplo de requerimientos funcionales para un sistema
de biblioteca universitarios, denominados Libsys, utilizado por estudiantes y personal
docente que solicitan libros y documentos de otras bibliotecas.
Requerimientos Funcionales de Lisbys (Bligo, 2013):
30

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

datos o seleccionar un subconjunto de ella.
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. Estas pueden ser las
capacidades de almacenamiento o restricciones de tiempo de respuesta del sistema.
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.
Finalmente es indispensable que los requerimientos sean examinados por el equipo de

trabajo para poder 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 y se llega a un acuerdo mutuo sobre
lo que se va a construir.
1.3.5. Fase de Diseo

En este tema conocers los aspectos bsicos para poder crear el diseo del producto de
Software. Es en esta fase donde 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 se va desarrollar
(Humphrey, 1999).
Despus de que se tienen bien definidos los requisitos, se deben llevar acabo las siguientes
actividades:
Crear un diseo de alto nivel: Los diseos de alto nivel son los que 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).
31

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

de los diseos pero para esto tiene que estar lo mejor documentado posible.
Desarrollar un plan de evaluacin. Al disear la estructura principal de los requerimientos
del sistema permitir la implementacin y codificacin del mismo.
1.3.6. Fase de Implementacin

En este captulo aprenders las acciones que se llevan a cabo en la etapa de implantacin la
cual bsicamente 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 entra en la entapa en
la que se empieza a decodificar pero antes que esto se debe de inspeccionar
minuciosamente el cdigo del software (Garza A. G., 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 se mencionaba anteriormente 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.
Cuando se est en la fase de aplicacin es muy frecuente encontrarse con errores de

transcripcin y de codificacin que son errores que se producen en las pulsaciones de
teclas. Por esta razn es que los programadores deben revisar el cdigo y de igual forma
otros programadores deben inspeccionar el cdigo (Humphrey, 1999).
El uso de estndares te permitir encontrar y mitigar errores de escritura que permitirn
ahorrar tiempo y esfuerzo, pero para esto se necesitan hacer las pruebas correspondientes
que es de lo que veras en el siguiente tema.
32

1.3.7. Fase de Pruebas

Esta fase es una da las ms importantes ya que se debe de probar el producto alcanzado,
para as evaluar y detectar todos los defectos que se puedan presentar en el producto y que
estos a su vez sean corregidos para evitar que los costos lleguen a elevarse
considerablemente (Garza, 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 que tener
una lista de pasos a ejecutarse estas se van haciendo por partes de manera incremental
empezando desde el primer nivel hasta el ms alto para que finalmente se integren
asegurndose s que todos los elementos estn incluidos y que funcione correctamente.
A continuacin se muestra una gua que contempla TSP para llevar el control de las Pruebas
al Sistema.
Tabla 1.3.7. Integracin y Pruebas del Sistema. (Humphrey, 1999).
Propsito
Los criterios de ingreso
General
Paso Actividades
1
Prueba
Descripcin
general del
proceso
Para guiar a un equipo a travs de la integracin y prueba de

los componentes del producto en un sistema.
El equipo cuenta con una estrategia de desarrollo y el plan.
Componentes implementados, inspeccionado, y la unidad
probada bajo control de configuracin
Cuando los defectos se encuentran en construccin, integracin, o
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 registra en el
registro de defectos y debe de ser revisado por todo el equipo para
determinar:
Cuando 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
Descripcin
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
33

Desarrollo de
Pruebas
Construir
Integracin
Prueba del
Sistema
Documentacin
calidad
El administrador de desarrollo conduce el desarrollo de la 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.
Revise los materiales de prueba y corregir errores.
El equipo construye el producto y comprueba que est completo.
Verifique que todas las piezas necesarias estn a la mano.
El encargado del desarrollo del software, registra todos los
defectos en el registro de defectos.
El gerente de desarrollo o alternativas conduce las tareas de
integracin.
Compruebe la integridad y la integracin de la prueba del
producto.
Registre todas las actividades de prueba en el registro de la
prueba.
El encargado del desarrollo del software, registra todos los
El gerente de desarrollo o alternativas conduce las tareas de
prueba del sistema.
Pruebe el producto en condiciones normales y de estrs.
Pruebe el producto para la instalacin, la conversin y la
recuperacin.
Registre todas las actividades de prueba en el registro de la
prueba.
Propietario del producto (desarrollador) registra todos los
El gerente de desarrollo o suplente lleva al equipo en:
Producir el contorno usuario-documentacin y tareas
La asignacin de estas tareas al equipo de documentacin
34

Criterios de salida
Revisar el esquema con el equipo de pruebas de integridad

Elaboracin de la documentacin de usuario de primer ciclo
Revisar, corregir, y la produccin de la documentacin del
usuario
Un ciclo-1 integrado y probado producto
Formas logD y LOGTEST completadas para todas las
pruebas
Documentacin del usuario Completado y revisado
Datos de tiempo, tamao y defectos introducidos en el
sistema de apoyo TSPI
En conclusin si no se llevan a cabo las pruebas al producto de software no se podr

garantizar el funcionamiento de este, ocasionando que no sea un producto de calidad. Esta
es una de las ltimas fases del ciclo de vida del TSP, pero ahora se tiene que hacer un
anlisis de todo lo ocurrido durante el desarrollo del producto, haciendo uso de la fase de
Postmortem.
1.3.8. Fase Postmortem

Esta es la fase de la culminacin del proceso de Team Software Process. Primeramente se
comienza con la evaluacin de todas las tareas que se definieron para el proyecto,
verificando las metas del plan de calidad y el trabajo del equipo. Es necesario hacer un
registro de todos los datos en formatos para su revisin ver tabla 1.3.8. (Humphrey, 1999)
La siguiente tabla muestra un ejemplo de cmo registrar los datos para la fase Postmortem.
Tabla 1.3.8 Recoleccin de Datos (Humphrey, 1999).
Propsito
Los criterios de ingreso

General
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 ingenieros han completado y probado el producto.
Se han reunido todos los datos y completado todos los formularios.
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
35

Paso
1
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
Actividades Descripcin
Postmortem El instructor describe el proceso post-mortem.
Descripcin La necesidad de una informacin completa y precisa del proceso
general del
El contenido del informe de ciclo
proceso
El proceso de evaluacin por pares y formas
Revise los
El responsable de calidad / proceso dirige el equipo en el anlisis de
datos de
los datos del proyecto y la identificacin de las reas problemticas y
proceso
mejorar.
El liderazgo, la planificacin, el proceso, la calidad o el apoyo
Acciones y responsabilidades del equipo sugeridos
reas de instructor o instalacin mejora
Los ingenieros de preparar y presentar PIP en estas sugerencias de
mejora.
Evaluar el
El lder del equipo lidera el equipo en la evaluacin de la eficacia de
desempeo las funciones del equipo, las acciones del instructor, y las
del rol
instalaciones de apoyo.
Cuando eran eficaces
Donde hay margen de mejora
Ciclo de
El lder del equipo lidera el equipo en esbozar el informe ciclo 1.
Preparacin- La asignacin de trabajo informe a los miembros del equipo
1 Informe
Obtencin de compromisos para la seccin Informe de terminacin
Montaje, revisin y correccin del informe completo
Preparar
Cada ingeniero complete una evaluacin del equipo y de cada papel
evaluaciones en el equipo utilizando el formulario PEER.
de funciones
Dificultad y la contribucin de cada funcin
Criterios de salida
Los porcentajes deben sumar 100%

La eficacia de cada papel en una escala de 1 (inadecuado) a 5
(superior).
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.
36

Las evaluaciones inter pares se hacen y se sometieron (PEER).

El informe ciclo 1 se ha completado y presentado.
El cuaderno del proyecto se ha actualizado.
Al hacer la revisin de los datos de todo el proceso se debe examinar lo que cada miembro
del equipo hizo e identificar qu parte del proceso trabajo realiz. Despus se hace una
comparacin del rendimiento obtenido por el equipo en lo planeado y metas que se fijaron al
inicio del ciclo, as se podrn identificar las reas del problema. Cuando se utiliza el proceso
de postmortem se podrn hacer los cambios necesarios para el prximo ciclo, corrigiendo
problemas encontrados y determinando cules fueron las causas que ocasionaron las fallas
para posteriormente poder hacer medidas preventivas. Esto permitir llevar al equipo a la
mejora continua.
Autoevaluacin
Una vez concluido el estudio de la Unidad 1. Introduccin a TSP y las actividades de
aprendizaje. Antes de desarrollar la Evidencia de Aprendizaje, realiza la autoevaluacin con
el fin de realizar un repaso general de la unidad; as como detectar aquellos temas que no
has comprendido en su totalidad y que requieras revisar nuevamente, o bien, consultar con
tus compaeros(as) y Facilitador(a).
Para realizar la Autoevaluacin, ingresa al listado de actividades en el aula.
Evidencia de aprendizaje. Identificacin de los elementos de la

metodologa TSP
En la evidencia de aprendizaje identificars los elementos de la metodologa TSP con base

en un problema que plantears y al cual es posible dar solucin mediante esta metodologa.
Para ello, sigue estos pasos:
1. Plantea y describe detalladamente un problema al cual puedas dar solucin
mediante la Metodologa TSP. Puedes investigarlo de acuerdo con tus posibilidades,
en tu mbito laboral, personal, familiar, laboral, puede ser hipottico con base en
algunas experiencias en estos mbitos o con base en tu formacin profesional como
desarrollador de software.
2. Redacta el problema en un archivo de texto.
37

3. Integra un cuadro comparativo en el cual expongas: Elemento de la Metodologa

TSP, definicin de los elementos de la Metodologa TSP, ejemplo de cada uno de los
elementos de la metodologa TSP:
a. Principios y objetivos de TSP
b. Estrategia de TSP
c. Equipo TSP
d. Estructura del Team Software Process (TSP): Disciplina de equipo, disciplina
de administracin, disciplina de ingeniera.
e. Ciclo de Vida del Team Software Process (TSP): Lanzamiento, estrategia,
planeacin, requerimientos, diseo, implementacin, pruebas, postmortem.
4. Integra un documento con la descripcin del problema, el cuadro comparativo y tus
propias conclusiones acerca de la relacin que existe entre cada uno de los
elementos y la importancia de esta metodologa en el quehacer del ingeniero en
desarrollo de software.
actividad y conocer los parmetros de evaluacin.
Autorreflexiones
Adems de enviar tu trabajo de la Evidencia de aprendizaje, ingresa al foro Preguntas de
Autorreflexin y consulta las preguntas que tu Facilitador(a) presente, a partir de ellas
elabora tu Autorreflexin en un archivo de texto llamado DDSE_U1_ATR_XXYZ.
Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.
Cierre de la unidad
El TSP es una metodologa que sirve de gua para ayuda a los ingenieros informticos, el
cual provee mtodos para el fcil desarrollo de software por medio de miembros que llegan a
formarse en equipos, en el cual se desenvuelven de una manera organizativa; estos
miembros tiene su roles y actividades propias y los dirige un lder el cual recopila
informacin y los mantiene ordenados para que logren completar sus objetivos planteados.
38

El ciclo de vida del TSP son una serie de ciclos que se llevan a cabo durante el desarrollo del
producto de software, este comienza con la declaracin de las necesidades del producto y
finalizan con la entrega del producto final.
Es la fase de Lanzamiento pisa clave para el inicio del desarrollo del software ya que es aqu
donde se forman los equipos y se asignas las actividades que desempearan cada uno de
los miembros del equipo como se explic a lo largo de la unidad y que veras ms con ms
detalle en la siguiente unidad, as tambin la elaboracin de planes de riesgo y calidad.
Si se desea desarrollar un software, siempre es imprescindible utilizar un mtodo como lo es
el Team Software Process, TSP: (Equipo de Procesos de Software), para lograr un producto
confiable y de buena calidad, de igual manera nos permitir mejorar de una manera
significativa todos los procesos implicados en el desarrollo de software.
Para saber ms
En la pgina del Institute Carnegie Mellon, encontrars informacin diversa acerca de las
herramientas de medicin de la calidad del desarrollo de software, entre ellas TSP.
Encontrars diversos artculos y documentos acerca de esta metodologa.
Software Engineering Institute Carnegie Mellon (2013). Pittsburgh:
https://www.sei.cmu.edu/library/abstracts/books/201731134.cfm Fecha de consulta: 11 de
junio del 2013.
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, el cual se encuentra accesible en
la seccin Material de apoyo.
Es recomendable revisar el documento de Watss S. Humprey, The Team Software Process,
en el cual se explica la metodologa TSP. Este documento se encuentra en su versin
original en el idioma ingls, si no cuentas con una un nivel de comprensin de este idioma,
puedes utilizar alguna de las diversas herramientas de traduccin que se encuentran en la
Red Internet. Consulta este documento en la seccin Material de apoyo.
39

Fuentes de consulta
Arcos, D. T. (2009). Team Software Process .dttrujilloa blogspot. Recuperado de:

http://dtrujilloa-tsp.blogspot.mx/
Fecha de consulta: 11 de junio del 2013
Colomo Palacios & Paniagua, Ricardo. Et al. (2011). Team Software Process. Madrid,
Espaa: Universidad Carlos III de Madrid. Recuperado de:
http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-de-informacioncorporativos/material/TSP.pdf/view
Fecha de consulta 11 de junio del 2013.
Dharma Consulting Especialistas en Project Management (2013). Herramientas

gratuitas de gestin de proyectos. Recuperado de:
http://dharmacon.net/herramientas/gestion-proyectos-ejemplos/
Gomez de Silva Garza, Andrs & Ania Briseo Ignacio de Jess. (2008). Introduccion
a la Computacion. Mexico, D.F: Cenage Learning Editores.
Humphrey, Watss S. (1999). Introduction to the Team SoftwareProcess.

Massachusetts: Addison Wesley Professional.
Kuna, Horacio Daniel & Caballero, Sergio, Et al(2008). Plan de Riesgos para la
implementacin de componentes de Web 2.0. Buenos Aires: AMICUS. Universidad
Nacional de Misiones. Facultad de Humanidades y Ciencias Sociales. Departamento
de Bibliotecologa. Recuperado de:
http://www.amicus.udesa.edu.ar/documentos/6jornada/documentos/pdf/PONENCIA%
20MISIONES%20RIESGOS%20Web2.0.pdf
Fecha de consulta: 13 de junio del 2013.
Piattini Velthuis, M. (2011). Calidad de Sistemas de informacin. Mxico, D.F.: Alfa

Omega ra-ma.
Queensland, T. U. (2010). CSSE3002 The Software Process. Lecture 14: The Team
Software Process. Queensland, Australia: School of Information Technology and
Electrical Engineering. Recuperado de:
http://itee.uq.edu.au/~csse3002/Lectures/Lect14.pdf
40

RAE (Real Academia Espaola), 2013. Equipo. 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 2005. Recuperado
de: http://www.congresoson.gob.mx/ISO/normas/ISO-90002005_Fundamentos_y_Vocabulario.pdf
Sommerville, I. (2006). Ingenieria de Software. Madrid Espaa: Pearson Education

S.A.
Fuentes de las imgenes:
Logismarket (2013) Diseo y reorganizacin. Recuperado

de:http://www.logismarket.es/ip/blife-diseno-y-reorganizacion-de-almacenes-diseno-yreorganizacion-de-almacenes-491419-FGR.jpg
Dcorbaxeo SEO (2009). El largo alcance de internet en tiempo real. Recuperado

de:http://www.corbax.com/blog/img/tiempo-real.jpg Fecha de consulta: 10 de junio del
2013
41

Unidad 1. Introduccion A TSP

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Unidad 1. Introduccion A TSP

Încărcat de

Drepturi de autor:

Formate disponibile

Desarrollo de Software en Equipo TSP

Unidad 1. Introduccin a TSP

Unidad 1. Introduccin a TSP

Universidad Abierta y a Distancia de Mxico

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

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

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

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

Foro de la asignatura ....................................................................................................... 10

Desarrollo de Software en Equipo TSP

Desarrollo de Software en Equipo TSP

Identificar los elementos y objetivos que componen la metodologa TSP.

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

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

Desarrollo de Software en Equipo TSP

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

Diseo del sistema y el software: En esta fase nuevamente los analistas e

Implementacin y prueba de unidades: En esta fase intervienen los desarrolladores

Integracin y pruebas del sistema: Aqu se observa ya un producto terminado y las

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

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

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

Desarrollo de Software en Equipo TSP

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

Administracin autodirigida a equipos de trabajo: como se mencion anteriormente a

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

1.1.1. Principios y Objetivos de TSP

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

1.1.2. Estrategia de TSP

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

1.1.3. Equipo TSP

El equipo debe estar formado por al menos dos personas.

Para poder conformar un equipo efectivo de ingenieros se necesita que:

Desarrollo de Software en Equipo TSP

Deber existir comunicacin frecuente entre los miembros del equipo.

Actividad 1. Elementos de la metodologa TSP

Desarrollo de Software en Equipo TSP

2. Identifica en el problema los elementos del proceso de desarrollo de TSP:

1.2. Estructura del Team Software Process (TSP).

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Figura 1.2.1. Estructura de TSP (Gomez de Silva & Ania ).

Desarrollo de Software en Equipo TSP

1.2.1. Disciplina de Equipo

Desarrollo de Software en Equipo TSP

1.2.2. Disciplina de Administracin

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

Desarrollo de Software en Equipo TSP

para tener un buen ambiente de trabajo y por supuesto la retroalimentacin que

1.2.3. Disciplina de Ingeniera

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Actividad 2. Estructura base de la metodologa TSP

En esta actividad identificars la estructura base de la metodologa TSP mediante un mapa

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

Desarrollo de Software en Equipo TSP

1.3.1. Fase de Lanzamiento