DDSE_U1_Contenido

Vista previa del material en texto

Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 
 
 
 
 
Ingeniería en Desarrollo de Software 
6º Semestre 
 
 
 
Programa de la asignatura: 
Desarrollo de software en equipo (TSP) 
 
 
 
Unidad 1. Introducción a TSP 
 
 
 
Clave: 
15143636 
 
Ciudad de México, enero del 2023 
 
Universidad Abierta y a Distancia de México 
 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 1 
 
Índice 
1. Introducción a TSP ............................................................................................................. 2 
Presentación de la unidad ..................................................................................................... 2 
Logros ..................................................................................................................................... 3 
Competencia específica ......................................................................................................... 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 administración ...................................................................................... 12 
1.2.3. Disciplina de ingeniería .............................................................................................. 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 planeación .................................................................................................... 25 
1.3.4. Fase de requerimientos ............................................................................................. 26 
1.3.5. Fase de diseño ........................................................................................................... 27 
1.3.6. Fase de implementación ............................................................................................ 28 
1.3.7. Fase de pruebas ........................................................................................................ 29 
1.3.8. Fase post mórtem ...................................................................................................... 31 
Cierre de la unidad ............................................................................................................... 33 
Para saber más .................................................................................................................... 34 
Fuentes de consulta ............................................................................................................. 34 
 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 2 
 
1. Introducción a TSP 
 
Presentación de la unidad 
 
Bienvenido a la asignatura Desarrollo de software en equipo TSP (Team Software Process), 
la cual forma parte del sexto semestre de la ingeniería en Desarrollo de Software. 
 
La metodología 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 metodología PSP, porque guía a cada individuo a 
alcanzar sus objetivos personales como parte de un proyecto de desarrollo de software, pero 
sin olvidar que lo más importante es la colaboración, la retroalimentación entre los miembros 
del equipo de desarrollo y, por supuesto, conseguir los objetivos trazados al inicio del 
proyecto. 
 
En la Unidad 1. Introducción a TSP, aprenderás los elementos, objetivos y principios en los 
cuales se basa esta metodología, así como su estrategia y estructura, que se aplica a todo el 
ciclo de desarrollo del proyecto. 
 
 
Relación entre PSP y TSP 
Contenido de la imagen basado en Tuya, Javier y otros, (2007). Imagen basada en Dreamstime (2013). 
 
 
 
 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 3 
 
Logros 
 
Al término de esta unidad lograrás: 
 
• Identificar los elementos y objetivos que componen la metodología TSP. 
• Comprender la relación que existe con PSP. 
• Conocer la estructura TSP. 
• Comprender la estrategia que sigue TSP para el desarrollo de sistemas de calidad. 
 
 
Competencia específica 
 
• Identificar la metodología 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 metodología de desarrollo de software en equipo, que guían 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 
metodología TSP dentro de una organización ayuda a tener una métrica exacta de costos. 
También la experiencia de proyectos pasados cuenta mucho. 
 
Para comprender la metodología TSP es necesario saber qué es un proceso de desarrollo 
de software (la primera se realiza dentro del segundo). También 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 más utilizado. El 90% de los que existen en la 
actualidad están basados en él. 
 
El modelo en cascada indica que todo desarrollo basado en él debe cumplir con las 
siguientes fases: 
 
• Análisis y definición de requerimientos: es muy importante conocer qué desea el 
cliente, para esto se hace el levantamiento de requerimientos, que consiste en visitas 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 4 
 
al cliente para saber cómo quiere que funcione el sistema solicitado. Después de 
esto, los analistas e ingenieros de software crean las especificaciones del sistema. 
En esta fase se integra la documentación requerida para el arranque del proyecto, la 
cual cambiará de acuerdo con la metodología propuesta; pero nunca deben de faltar 
los documentos donde se muestren los objetivos, visión, roles, puestos y 
requerimientos del sistema a desarrollarse. 
 
• Diseño del sistema y el software: los analistas e ingenieros de software establecen 
unaarquitectura completa del sistema, el diseño nos muestra cómo va a funcionar y 
si se va a comunicar con otros sistemas. 
 
• Implementación y prueba de unidades: prácticamente, en esta fase se desarrolla 
por completo el sistema. 
 
• Integración 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 versión terminada del sistema, para que la pruebe en el área de producción 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 representación del modelo en cascada: 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 5 
 
 
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 más adelante se explicarán. 
 
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 administración de proyectos, en la construcción 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 metodología TSP son: líder de equipo, administrador de desarrollo, 
administrador de planeación, administrador de calidad de proceso y administrador de 
Definición de 
requerimientos
Diseño del 
sistema y del 
software
Implementación y 
prueba de 
unidades
Integración y 
prueba del 
sistema
Funcionamiento y 
mantenimiento
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 6 
 
soporte, cargos que se explicarán con más detalle en el Tema 1.3. Ciclo de vida del Team 
Software Process. 
 
TSP se enfoca en la gestión 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 gestión individual, especialmente 
en los desarrolladores de software, para tener una métrica 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: 
 
• Administración autodirigida para equipos de trabajo. Como ya se mencionó, a 
comparación de PSP, TSP está totalmente orientado a equipos de trabajo. 
• Está integrado por indicadores: éstos señalan los pasos a realizar y el orden a seguir. 
• Es un sistema de administración de calidad: TSP tiene como principal propósito 
asegurar la calidad en el desarrollo de software y, de este modo, conseguir la 
satisfacción total del cliente. 
• La estrategia del equipo está dirigida al desarrollo rápido: al utilizar la 
retroalimentación entre los miembros del equipo se evita cometer errores observados 
en desarrollos pasados. 
• Proceso operativo apoyado por la formación y capacitación 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 
específicas que pueden aprenderse durante el desarrollo del proyecto. 
• Modelo de coaching: método cuyo propósito es instruir y dirigir a las personas con el 
propósito de que logren los objetivos y desarrollen habilidades específicas de 
acuerdo a las actividades y roles que desempeñen dentro del proyecto. 
 
Un punto muy importante de TSP es lograr la comunicación 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 metodología 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 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 7 
 
buen ambiente de trabajo y que en todo momento exista comunicación y retroalimentación 
dentro del equipo. 
 
TSP está basado en cuatro principios fundamentales (Tuya, J. y otros, 2007): 
 
1. El aprendizaje es mucho más eficaz si se sigue un proceso claro y bien definido y, 
además, si existe retroalimentación entre los miembros del equipo. TSP cuenta con 
mediciones claras y está diseñado para utilizarse de manera cíclica, esto permite al 
equipo recibir información continua sobre su desempeño 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 guías apropiadas para dar solución a los problemas de 
desarrollo que surjan durante el tiempo que dure éste. 
4. Las instrucciones son más claras cuando ya se había 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. También 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 metodología. 
 
En el siguiente subtema se revisará la estrategia de TSP, con la cual podrás identificar la 
importancia de los equipos de trabajo, así como las estrategias para conformar uno para 
implementar esta metodología de desarrollo de software dentro de una organización. 
 
 
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 metodología 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, diseño, 
implementación, prueba y post mórtem, los cuales se explicarán con más detalle en el Tema 
1.3. Ciclo de Vida del Team Software Process (TSP). Toda la fase de desarrollo de software 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 8 
 
debe cumplir con un ciclo, el cual será elegido de acuerdo al tamaño y la complejidad del 
proyecto. 
 
Por ejemplo, tomemos el modelo en cascada, el cual cuentacon cinco fases que son: 
definición de requerimientos, diseño del sistema y de software, implementación y prueba de 
unidades, integración y pruebas del sistema, funcionamiento y mantenimiento. 
 
La estrategia principal de TSP se basa en la búsqueda de la mejor manera de introducir sus 
ocho procesos dentro de cada fase del ciclo de vida del proyecto, que en este caso sería el 
modelo en cascada (Piattini, 2011). Siempre se inicia con una junta donde los líderes 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 
(diseño del sistema y de software, según 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 sería 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 metodología, y se van a implementar en cada una de las fases de 
desarrollo del ciclo de vida del software a desarrollar. En el siguiente capítulo aprenderás las 
principales características que se requieren para integrar los equipos de trabajo, de acuerdo 
con algunas condiciones señaladas por el TSP. 
 
 
1.1.3. Equipo TSP 
 
En el contexto de TSP (metodología creada para los grupos de trabajo y la 
retroalimentación), para que un equipo se forme hay algunas condiciones que deben 
crearse, las cuales se mencionan a continuación (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 colaboración de todos los 
miembros del equipo. 
• Cada persona tiene un rol específico (establecidos por los ingenieros de software y 
administradores del proyecto), el cual debe seguir porque es una guía de sus 
deberes. 
 
Para conformar un equipo efectivo de ingenieros se necesita que: 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 9 
 
 
• Los integrantes estén 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 estén de acuerdo. 
• Establecer objetivos en común y definir los roles por parte de los miembros del 
equipo. 
• Definir procesos en común. 
• Todos los miembros deben de participar en la creación de un plan. 
• El equipo deberá negociar el plan con la administración. 
• La administración revisará y aceptará el plan realizado por el equipo. 
• Los miembros deben de realizar su trabajo de acuerdo al plan. 
• Deberá existir comunicación frecuente entre los miembros del equipo. 
• Todos los integrantes deberán cooperar y estar comprometidos con un objetivo en 
común. 
• Los líderes deberán de obtener feedback (retroalimentación) 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 metodología TSP. En la siguiente actividad 
identificarás los elementos de la metodología TSP y la relación 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, además indican las acciones o actividades a ejecutar y el orden en el cual 
deben desarrollarse. Esto es muy importante en la implementación de TSP, ya que indica los 
pasos a seguir al momento de crear el equipo, trabajar y ejecutar acciones individuales. 
Una de las más 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 también especifica los pasos y medidas 
necesarios para formar un equipo eficaz y un buen ambiente de trabajo. 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 10 
 
En la siguiente figura se muestra la estructura de TSP: 
 
 
 
 
• Planes personales 
• Método de planeación 
• Valor agregado 
• Métricas 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 metodología 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 administración, se crean los equipos y se ejecuta el trabajo; para ello, se utiliza 
la metodología 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 continuación, se explicarán cada una de las disciplinas que conforman la 
estructura de TSP. 
 
 
TSP 
trabajo en 
equipo 
 
TSP 
creación 
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 
• Revisión de status 
y calidad 
• Comunicación 
Disciplina 
ingenieril 
Disciplina 
de equipo 
Disciplina de 
administración 
Equipos 
integrados 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 11 
 
1.2.1. Disciplina de equipo 
 
En este subtema aprenderás 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 también pueden ser vistas como fases 
dentro de esta disciplina y a continuación se explicarán a detalle cada una: 
 
• Compromiso: todos los miembros deberán tener bien claro cuáles son los 
compromisos con la organización y con el cliente, de acuerdo a los objetivos 
planteados al inicio del proyecto. 
• Planes agresivos: son acciones planeadas y bien estructuradas para ejecutarse 
rápidamente y lograr objetivos a corto plazo; proporcionan el desempeño 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 módulo del sistema que estén 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 más 
detallada, con protocolos y estándares bien definidos por el administrador de calidad 
de proceso. Esto se verá más a detalle en la unidad 3. Gestión en TSP. 
• Objetivodel proyecto: el equipo debe dar su punto de vista de los objetivos que se 
plantean al inicio del proyecto, y así tener una visión más clara acerca de a dónde se 
desea llegar. 
• Plan propio: cada equipo debe de tener su propio plan, establecido por los 
administradores al inicio del proyecto. Aprenderás cómo hacer uno en la unidad 2. 
implementación de TSP. 
• Plan detallado: en la documentación 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 través 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 más detalle en el subtema 2.2. Ejecutar el trabajo en 
equipo. 
• Roles: cada miembro del grupo debe tener bien claro cuál 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. 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 12 
 
En conclusión, puede decirse que la disciplina de equipo indica reglas muy precisas que 
guían las actividades para que se logren los objetivos del proyecto. 
 
 
1.2.2. Disciplina de administración 
 
 
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 satisfacción del cliente. Esta calidad se logra mediante una buena 
planeación y ejecución al pie de la letra la metodología 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 planeación 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). 
• Revisión de status de calidad: para este fin, tanto los desarrolladores como los 
administradores utilizan plantillas y reportes, que tú aprenderás a hacer en la unidad 
3. Gestión en TSP. 
• Comunicación: la comunicación entre los miembros del equipo no solo permite que 
se llegue a los objetivos deseados, también sirve para tener un buen ambiente de 
trabajo y llevar a cabo la retroalimentación que ayuda a no repetir errores ya 
cometidos, en el mismo proyecto o en anteriores. 
 
Como se puede notar, la disciplina de la administración se basa en los administradores y en 
la forma de medir el nivel de calidad del desarrollo del proyecto. En el siguiente subtema 
conocerás la disciplina que está orientada a las personas que conforman el equipo de 
desarrollo de un proyecto. 
 
 
1.2.3. Disciplina de ingeniería 
 
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 ingeniería se conforma por las siguientes 
actividades: 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 13 
 
 
• 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. 
• Método de planeación: 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. 
• Métricas de calidad: las métricas son una referencia exacta para medir el nivel de 
algo en específico. En este caso sirven para controlar, medir, monitorizar, predecir y 
probar el desarrollo de software. Por ejemplo, una métrica podría ser una plantilla 
donde muestre los avances que ha tenido el proyecto mes con mes. Esta fase se 
explicará con más detalle en el tema 3.2. Diagnóstico: Métricas 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 cuál 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 aprenderás la forma en que está estructurado el ciclo de vida de la metodología 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 
número 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 creación de diseños detallados del software, que es 
revisado por todo el equipo. Posteriormente, dicho diseño se convierte en código, el cual 
también 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 aplicación del ciclo de vida del proceso de software de equipo de TSP, se definen las 
fases del desarrollo de software que se realizarán por parte del equipo de trabajo, las cuales 
describen una serie de pasos para ayudar a alcanzar productos de calidad. La metodología 
del TSP contempla ocho faces de desarrollo bien definidas (ver figura 1.1), que deben 
llevarse a cabo de manera cíclica 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 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 14 
 
1.3.1. Fase de lanzamiento. Cada una de las fases describe las actividades que les son 
propias, y que se explican a continuación (Humphrey, 1999). 
 
 
 
Figura 3. Fases del ciclo de vida del TSP (Humphrey, 1999). 
 
 
1.3.1. Fase de lanzamiento 
 
En este subtema se revisarán 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; 
también se determinan los roles y responsabilidades que desempeñarán cada uno de los 
integrantes, y la manera idónea para forma el equipo de trabajo. Las metas y objetivos se 
llevan a cabo de forma individual y en equipo, en la tabla 1 observarás 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 periódica, 
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
Planeación
Requerimientos
Diseño
Implementación
Pruebas
Post mórtem
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 15 
 
Objetivos Indicador 1 Indicador 2 Indicador 3 Indicador 4 
Ser un 
miembro del 
equipo 
cooperativo y 
efectivo 
El promedio de 
la evaluación de 
cada miembro 
del equipo, 
efectuada por los 
pares acerca de 
la disposición a 
ayudar y la 
aportación del 
trabajo, debe ser 
mayor a 3 (ésta 
es una medición 
de la eficacia y 
eficiencia que el 
equipo 
establece, 
determina, y 
califica). 
El promedio de 
la evaluación de 
cada miembro 
del equipo, 
efectuada por 
los pares acerca 
de la 
contribución 
general hecha al 
equipo, debe ser 
mayor a 3. 
 
Realizar un 
trabajo 
personal 
disciplinado 
El porcentaje de 
los datos 
personales 
(desempeño, 
eficacia, 
etcétera) 
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 
compilación 
debe ser mayor 
La densidad de 
defectos 
encontrados 
durante la 
compilación 
debe ser menor 
La densidad 
de defectos 
encontrados 
durante la 
prueba de 
unidad debe 
La densidad 
de defectos 
encontrados 
durante y 
después de la 
prueba de 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 16 
 
a 70%. a 10/KLOC. ser menor a 
5/KLOC. 
unidad debe 
ser 0. 
Gómez 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 
compilación 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 
estimación del 
producto debe ser 
menor a 20%. 
El error en el 
número 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 días de 
retraso o adelanto 
para completar el 
ciclo debe ser 
menor a 4. 
 
Gómez 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 continuación: 
 
 
 
 
 
 
 
 
 
Las empresas necesitan 
metas de gestión de 
requisitos del producto. 
¿Qué? ¿Cómo? ¿Cuándo? ¿Quién? 
¿Qué 
tan 
bien? 
¿Qué 
pasa 
si...? 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 17 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4. Lanzamiento del TSP (Queensland, 2010). 
 
Los objetivos 
del equipo 
 
Diseños 
conceptuales 
 
Productos 
planeados 
 
Tamaño 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 
Evaluación de 
riesgos 
 
Plan de 
alternativas 
 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 18 
 
Las preguntas que se plantean en el esquema anterior: ¿qué?, ¿cómo?, ¿quién?, ¿qué tan 
bien? y ¿qué pasa si...?, permitirán establecer las bases de una estrategia del lanzamiento 
para llegar a la culminación del proyecto; en conjunto con la anterior, se deben tomar en 
cuenta los requerimientos que serán 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 continuación de describen los roles del TSP. 
 
Roles de TSP 
 
Líder 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. 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 19 
 
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 Líder de equipo AP Administrador de planeación AA Administrador de 
apoyo 
AD Administrador de 
desarrollo 
ACP Administrador de 
calidad/proceso 
 
 
UABC, 2005 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 20 
 
El líder de proyecto es el representante ante el cliente, el encargado de la integración de la 
planeación e implementación 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 guían al equipo en la planificación y seguimiento del 
desarrollo del producto de software. 
 
Su principal objetivo se centra en la fase de diseño del proyecto. Aquí toma el mando del 
proyecto el ingeniero con mayor conocimiento en diseño, quien formulará las actividades que 
requiera esta etapa, además 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 describirán más delante). 
• Auxiliar al líder de proyecto para estimar los tiempos, recursos y tamaño del producto 
de software. 
• Dirigir el análisis de alto nivel. 
• Dirigir el diseño. 
• Dirigir la implementación de pruebas.• Colaborar con el equipo de desarrollo. 
 
Como podrás darte cuenta, el administrador de desarrollo debe de colaborar muy de cerca 
con cada uno de los miembros del equipo que desempeñan los distintos roles. 
 
Administrador de planeación 
 
El administrador de planeación 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 estén 
relacionadas con el plan. 
 
Debe dirigir la generación del plan de trabajo en cada ciclo de desarrollo y establecer cómo 
estarán definidas las partes del producto final. Administra el qué, quiénes, cómo, cuándo y 
dónde se va a hacer. De ello depende la complejidad y factibilidad del proyecto. Está ligado a 
los objetivos propuestos, hasta dónde se va a llegar (Osorio, 2013). 
 
 
 
 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 21 
 
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. 
 
También 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 básicas son éstas: 
 
• Mantener estándares 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 estándares y patrones de calidad; debe alertar al líder del proyecto sobre 
cualquier trabajo que no los cubra. 
 
Administrador de configuraciones 
 
“La administración 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 
configuración de los productos y subproductos, donde se indiquen los procedimientos 
necesarios para llevar a cabo las labores de administración de configuraciones tales como: 
 
• Establecer los números de las versiones de los productos o que indican dichos 
números. 
• Mantener la trazabilidad (conocer el histórico 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 gestión de los cambios que se realicen en el 
producto de software); es decir, administrar el control de cambios y su sistema, 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 22 
 
recomendar los cambios o ajustes que deben realizarse, verificar, mantener y 
evaluar la persistencia del sistema, fomentar la reutilización del código y recursos 
• Sentirse parte del desarrollo. 
 
Sin duda alguna, la fase de lanzamiento es una de las etapas primordiales y más 
importantes dentro del ciclo de vida del TSP. De ella emana lo que se va a hacer, cómo se 
va a hacer y hasta dónde se quiere llegar, la culminación 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 conocerás las estrategias de desarrollo para entender lo que se va a 
producir en cada ciclo, analizarás e identificarás las estimaciones de tamaño y esfuerzo que 
se requieran. 
 
En la fase de la estrategia los equipos idean un diseño conceptual del producto previsto. De 
igual manera se hacen estimaciones sobre el tamaño 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 diseño conceptual del producto: es el punto de arranque para realizar la 
planificación del proyecto. Se establece un plan para la elaboración del producto. 
Para la elaboración del diseño conceptual, los miembros del equipo deben basarse 
en experiencias previas con la finalidad de saber cómo puede desarrollarse el 
siguiente producto; para esto se utilizan los diagramas UML (lenguaje unificado de 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 23 
 
modelado), lenguaje grafico que permitirá especificar, visualizar, construir y 
documentar un sistema de software. Reviste gran importancia como guía del equipo 
de trabajo en todo el proceso. 
 
 
 
 
Diseño y reorganización. 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 cuál 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. 
 
Estimación de tamaño y esfuerzo: se refiere al tamaño 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 guía del PMBOK (capítulo 6.1.) para realizar estas estimaciones. 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 24 
 
Plan de gestión 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 gestión 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 gestión de Riesgos 
 
Riesgo RI-05. Inexperiencia del equipo informático/bibliotecario en el desarrollo e 
implementación del proyecto. 
Aspectos a considerar 
• ¿Por qué el riesgo es importante? Podría alterar la calidad del producto, 
provocar atrasos en el desarrollo e implementación del proyecto. 
 
• Qué información 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 cómo 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 técnico/bibliotecológico. Si el 
control corresponde a una actividadinformática, el personal deberá tener 
amplios conocimientos sobre la tecnología incluida en el proyecto; si el control 
corresponde a una actividad bibliotecológica, deberá poseer el conocimiento de 
la tecnología aplicable a la bibliotecología. 
Plan de acción 
• Cursos de capacitación de tecnología y administración de componentes web. 
2.0 para el personal bibliotecario. 
• Realizar talleres y actividades integradoras. 
• Reuniones semanales entre informáticos y bibliotecarios. 
• Contratar personal Informático especializado en: 
▪ Tecnología web. 
▪ Base de datos. 
▪ Diseño de páginas web. 
Plan de contingencia 
• Disparador: el plan de avance no refleja los resultados esperados, falta de 
calidad en el producto. 
• Contratar una consultaría experta en tecnología Web 2.0. 
Kuna, Caballero et ál., 2008 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 25 
 
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 cómo se va a realizar el producto de software. Estas estrategias 
ayudarán al equipo a preparar la planeación, la cual se explicará en el siguiente subtema. 
 
 
1.3.3. Fase de planeación 
 
En la fase de lanzamiento, el equipo debió haber analizado las necesidades y creado un 
diseño conceptual de la estimación de tamaño del producto; en la fase de estrategia, debió 
realizar una estimación de tiempo que llevará el desarrollo. Éstas son las bases para el 
siguiente proceso que, en este caso, es la planeación. 
 
Dentro de la fase de planeación los miembros del equipo generan un plan de trabajo, que 
puede contener un inventario de los elementos que serán utilizados. Éste puede contener: 
 
• Estimación del tamaño de cada parte a ser desarrollada: éste será determinado 
por el tamaño del trabajo. 
• Identificación de las tareas, estimación 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 duración, 
fecha de inicio y término. Por último, se lleva el control semanal sobre el porcentaje 
de cumplimiento. 
• Plan de calidad: es un documento que especifica quién, cuándo y qué 
procedimientos y recursos asociados deben aplicarse a un proyecto, producto, 
proceso o contrato específico (Secretaría Central de ISO, 2005). 
 
 
Es posible observar los formatos de un plan de gestión de calidad para un programa de 
capacitación en la página de Dharma Consulting Especialistas en Project Managemen, ahí 
encontrarás herramientas gratuitas de gestión de proyectos y podrás observar los 
lineamentos establecidos para realizar un control de calidad. 
 
Los objetivos de calidad, que se encuentran en la línea base de calidad del proyecto, se 
refieren a la medición con la que se evaluará el cumplimiento de las metas establecidas por 
el equipo de trabajo. La métrica se refiere, de igual manera, a una medida que proporciona 
http://dharmacon.net/herramientas/gestion-proyectos-ejemplos/
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 26 
 
una indicación cuantitativa (dimensión o tamaño de algunos atributos). Otra observación 
importante es el sponsor, patrocinador o cliente. 
 
La complejidad para elaborar un plan de desarrollo depende del tamaño del proyecto. El 
hacer un plan permitirá trabajar de una manera más 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 continuación, revisarás algunas recomendaciones necesarias para conocer las 
especificaciones de requerimientos de software, el análisis de necesidades y los criterios 
necesarios para realizar lo que en verdad se quiere. 
 
Una vez que se ha concluido con la fase de planeación 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 guía 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. 
 
Análisis 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 participación 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 cómo se 
debe general al interior del equipo, de tal manera que puedan recolectar la información 
necesaria. 
 
Especificación 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 
dependerán del tipo de software que esté en desarrollo. A continuación, se presenta 
un ejemplo de requerimientos funcionales para un sistema de biblioteca universitaria, 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 27 
 
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 almacén 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 están 
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 automático y el cliente desea que el programa 
esté funcionando las 24 horas del día, 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 conclusión, 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 diseño 
 
En este subtema conocerás los aspectos básicos para crear el diseño del producto de 
software. Aquí se genera la estructura general del producto; para esto se deben definir las 
especificaciones del diseñodel software. Se debe generar un diseño completo de los 
requisitos para poder precisar claramente el producto que va a desarrollarse 
(Humphrey, 1999). 
 
Después de que se tienen bien definidos los requisitos, se deben llevar acabo las siguientes 
actividades: 
 
• Crear un diseño de alto nivel: describen los componentes principales del sistema y 
la forma en que interactúan entre sí. El equipo puede trabajar de forma independiente 
ya que es posible separar el diseño en partes. Esto se refiere a la creación de las GUI 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 28 
 
(interface gráfica de usuario), que será la vía de comunicación entre el usuario y el 
sistema (software). 
 
• Inspeccionar el diseño: al inspeccionar se puede mejorar de manera importante la 
calidad de los diseños, pero para esto se tiene que estar lo mejor documentado 
posible. 
 
• Desarrollar un plan de evaluación: diseñar la estructura principal de los 
requerimientos del sistema permitirá la implementación y codificación de éste. 
 
 
1.3.6. Fase de implementación 
 
Ahora aprenderás las acciones que se llevan a cabo en la etapa de implementación, que 
está relacionada con la codificación y el uso de estándares dentro del sistema. 
 
En esta fase se realiza la implementación del producto de software; se empieza a 
decodificar, pero antes se debe inspeccionar minuciosamente el código del software (Gómez 
y Ania, 2008). 
 
Los estándares 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 estándares de diseño dentro de esta fase son fundamentales. A 
continuación, se muestran algunos de ellos: 
 
• Revisión de estándares 
• Estándares de codificación 
• Estándar de tamaño 
• Estándar de defectos 
• Prevención de defectos 
 
En la fase de aplicación es muy frecuente encontrar errores de transcripción y de 
codificación, errores producidos al pulsar una tecla por otra. Por esta razón, varios 
programadores deben revisar e inspeccionar el código (Humphrey, 1999). 
 
El uso de estándares te permitirá encontrar y mitigar errores de escritura, así ahorrarás 
tiempo y esfuerzo; pero para esto se necesitan hacer las pruebas correspondientes que 
veras en el siguiente subtema. 
 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 29 
 
1.3.7. Fase de pruebas 
 
Esta fase es una da las más 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 (Gómez y Ania, 2008). 
 
En esta etapa se realizan diferentes pruebas al sistema, con el fin de asegurar su calidad y 
evaluar el desempeño 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 más alto para que, al final, se integre de tal manera que todos los elementos 
estén incluidos y que funcionen correctamente. 
 
A continuación, se muestra una guía que contempla TSP para llevar el control de las pruebas 
al sistema. 
 
Tabla 6. Integración y pruebas del sistema 
 
Propósito Para guiar a un equipo a través de la integración 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 configuración. 
General Cuando los defectos se encuentran en construcción, integración o 
en la prueba del sistema, el responsable de calidad/proceso 
determina si la prueba debe continuar. Todo defecto que se 
encuentra en la integración o pruebas del sistema se consigna en 
el registro de defectos, y debe de ser revisado por todo el equipo 
para determinar: 
• Cuántos defectos similares pueden permanecer en el 
producto. 
• Cómo y cuándo encontrar y corregir esos defectos. 
• El proceso cambia para prevenir defectos similares en el 
futuro. 
Paso Actividades • Descripción 
1 Prueba descripción 
general del 
proceso. 
El administrador de calidad describe: 
• El proceso de pruebas de integración 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 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 30 
 
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 generación 
requeridas. 
• Desarrollar los procedimientos de ensayo de la integración 
y las instalaciones. 
• Desarrollar los procedimientos de ensayo de sistemas e 
instalaciones. 
• Medir el tamaño 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 están a 
la mano. 
 
• El encargado del desarrollo del software, consigna todos 
los errores en el registro de defectos. 
4 Integración El gerente de desarrollo o alternativas: 
• Conduce las tareas de integración. 
• Comprueba la integridad y la integración 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 estrés. 
• Prueba el producto para la instalación, la conversión y la 
recuperación. 
• 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 Documentación El gerente de desarrollo o suplente se encarga de: 
• Producir el contorno usuario-documentación y tareas. 
• La asignación de estas tareas al equipo de documentación. 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 31 
 
• Revisar el esquema con el equipo de pruebas de 
integridad. 
• Elaborar la documentación de usuario de primer ciclo. 
• Producir, revisar y corregir la documentación del usuario. 
Criterios de salida • Un ciclo-1 integrado y probado del producto. 
• Formas logD y LOGTEST completadas para todas las 
pruebas. 
• Documentación del usuario completada y revisada. 
• Datos de tiempo, tamaño y defectos introducidos en el 
sistema de apoyo TSPI. 
Humphrey, 1999 
 
En conclusión, 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 análisis de 
todo lo ocurrido durante el desarrollo del producto en la fase post mórtem. 
 
 
1.3.8. Fase post mórtem 
 
Ésta es la fase de la culminación del proceso de TSP. Se comienza con la evaluación 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 revisión, ver tabla6. 
(Humphrey, 1999). 
 
A continuación, se ofrece un ejemplo de cómo registrar los datos para la fase post mórtem. 
 
Tabla 7. Recolección de Datos 
Propósito Recoger, analizar y registrar los datos del proyecto para evaluar el 
equipo y el desempeño de cada función. 
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 análisis del proyecto por cada 
función. 
El rendimiento general del equipo: líder del equipo. 
Plan de actuación frente al actual: gerente de planificación. 
Diseño de producto global y las normas: gerente de desarrollo. 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 32 
 
Gestión 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 Descripción 
1 Post mórtem 
descripción 
general del 
proceso. 
El instructor describe el proceso post mórtem. 
La necesidad de una información completa y precisa del proceso. 
El contenido del informe de ciclo. 
El proceso de evaluación por pares y formas. 
2 Revise los 
datos de 
proceso. 
El responsable de calidad/proceso dirige el equipo en el análisis de 
los datos del proyecto y la identificación de las áreas problemáticas a 
mejorar. 
El liderazgo, la planificación, el proceso, la calidad o el apoyo. 
Acciones y responsabilidades del equipo sugeridas. 
Áreas de instructor o instalación mejora. 
Los ingenieros encargados de preparar y presentar PIP en estas 
sugerencias de mejora. 
3 Evaluar el 
desempeño 
del rol. 
El líder del equipo lo conduce en la evaluación de la eficacia de las 
funciones del equipo, las acciones del instructor y las instalaciones 
de apoyo. 
Cuándo eran eficaces. 
Dónde hay margen de mejora. 
4 Ciclo de 
preparación-
1. Informe 
El líder del equipo lo conduce al esbozar el informe ciclo-1. 
La asignación de trabajo; informe a los miembros del equipo. 
Obtención de compromisos para la sección informe de terminación. 
Montaje, revisión y corrección del informe completo. 
5 Preparar 
evaluaciones 
de funciones 
Cada ingeniero completa una evaluación del equipo y de cada 
participación individual con base en el formulario PEER. 
Dificultad y la contribución de cada función. 
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 documentación requerida. 
El producto terminado está bajo control de la configuración. 
Todos los datos de proceso se han evaluado y presentado PIP. 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 33 
 
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 revisión de los datos de todo el proceso debe examinarse lo que cada miembro 
del equipo hizo, además de identificar qué parte del proceso realizó. Después se hace una 
comparación del rendimiento obtenido por el equipo en lo planeado y metas fijadas al inicio 
del ciclo, así se podrán identificar las áreas del problema. Cuando se utiliza el proceso post 
mórtem se podrán hacer los cambios necesarios para el próximo ciclo, corregir problemas 
encontrados y determinar cuáles 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 metodología que sirve de guía para los ingenieros informáticos; provee 
métodos para el fácil 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 líder que recopila información 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 declaración 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 desempeñaran cada uno de 
los miembros, como ya se explicó aquí; pero esto lo verás con más detalle, junto con la 
elaboración de planes de riesgo y calidad, en la próxima unidad. 
 
Si se desea desarrollar un software, siempre es imprescindible utilizar un método 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. 
 
 
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 34 
 
Para saber más 
 
En la página del Institute Carnegie Mellon 
http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm ,existe mucha información 
acerca de las herramientas de medición de la calidad del desarrollo de software, entre ellas 
TSP, sobre la que encontrarás diversos artículos y documentos. 
 
También puedes consultar un caso de uso de PSP y TSP en el documento Uso de 
tecnologías y metodologías de desarrollo, de Roy Steeven Yarce David, que se encuentra 
accesible en la sección Material de apoyo. 
 
Es recomendable revisar el documento de Watss S. Humprey, The Team Software Process, 
donde se explica la metodología TSP. La versión original de este documento, escrito en 
inglés, se encuentra en la sección Material de apoyo; si no posees el nivel de comprensión 
de este idioma, puedes utilizar alguna de las diversas herramientas de traducción 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://www.rcolomo.com/papers/74.pdf 
 
• Dharma Consulting Especialistas en Project Management (2013). Herramientas 
gratuitas de gestión de proyectos. Recuperado de https://dharmacon.net/ 
 
• Gómez, A. y Ania, I. (2008). Introducción a la computación. México: 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 implementación de 
componentes de web 2.0. Recuperado de 
https://repositoriosdigitales.mincyt.gob.ar/vufind/Record/SEDICI_36fcbe9a53f10034c6
adb5483e3fc931 
 
 
http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm
http://www.rcolomo.com/papers/74.pdf
https://dharmacon.net/
https://repositoriosdigitales.mincyt.gob.ar/vufind/Record/SEDICI_36fcbe9a53f10034c6adb5483e3fc931
https://repositoriosdigitales.mincyt.gob.ar/vufind/Record/SEDICI_36fcbe9a53f10034c6adb5483e3fc931
Desarrollo de software en equipo (TSP ) 
Unidad 1. Introducción a TSP 
Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 35 
 
• La gestión de proyectos usando un marco de calidad - Gestion de Proyectos 
Software. (s. f.). sites.google.com. Recuperado 31 de enero de 2022, de 
https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-de-
software/2-1-la-gestion-de-proyectos-usando-un-marco-de-calidad 
 
• Nord, Robert, McHale, J., & Bachmann, F.(2010). Combining Architecture-Centric 
Engineering with the Team Software Proces. Pensilvania: Carnegie Mellon University 
 
• Olivera Sosa, Á. G. (2010). Planificación y modelado. Escárcega: 2010. 
 
• Osorio, H. R. (2010). Roles en TSP. [En línea] 
http://es.slideshare.net/hansellramos/roles-para-t-s-p 
 
• Piattini, V. (2011). Calidad de sistemas de información. México: AlfaOmega/Ra-ma. 
 
• Queensland, T. U. (2010). Lecture 14: The Team Software Process. CSSE3002 The 
Software Process. Recuperado de https://my.uq.edu.au/programs-
courses/course.html?course_code=csse3002 
 
• Real Academia Española (2009), Diccionario de la lengua española, 22a. ed. 
Recuperado de http://lema.rae.es/drae/?val=equipo 
 
• Secretaría Central de ISO. (2005). Norma Internacional ISO 9000:2005. Sistemas de 
gestión de la calidad. Fundamentos y vocabulario. Ginebra: ISO. Recuperado de: 
https://www.iso.org/obp/ui/es/#iso:std:iso:9000:ed-3:v1:es 
 
• Sommerville, I. (2006). Ingenieria de software. Madrid: Pearson Educación. 
 
• Trujillo, D. (2009). Team Software Process. [Mensaje de un blog]. Recuperado de 
http://dtrujilloa-tsp.blogspot.mx/ 
 
• Tuya, Javier; Ramos Román, Isabel & Dolado Cosín, Javier (2007). Técnicas 
cuantitativas para la gestión en la ingeniería del software. La Coruña, España: 
Netbiblo 
 
Bibliografía 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 
https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-de-software/2-1-la-gestion-de-proyectos-usando-un-marco-de-calidad
https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-de-software/2-1-la-gestion-de-proyectos-usando-un-marco-de-calidad
http://es.slideshare.net/hansellramos/roles-para-t-s-p
https://my.uq.edu.au/programs-courses/course.html?course_code=csse3002
https://my.uq.edu.au/programs-courses/course.html?course_code=csse3002
http://lema.rae.es/drae/?val=equipo
https://www.iso.org/obp/ui/es/#iso:std:iso:9000:ed-3:v1:es
http://dtrujilloa-tsp.blogspot.mx/
http://es.dreamstime.com/illustration/engranajes-del-asunto.html
http://thumbs.dreamstime.com/x/engranajes-del-asunto-28681457.jpg
	1. Introducción a TSP
	Presentación de la unidad
	Logros
	Competencia específica
	1. 1. Proceso de Desarrollo de Team Software Process (TSP)
	1.1.1. Principios y objetivos de TSP
	1.1.2. Estrategia de TSP
	1.1.3. Equipo TSP
	1.2. Estructura del Team Software Process (TSP)
	1.2.1. Disciplina de equipo
	1.2.2. Disciplina de administración
	1.2.3. Disciplina de ingeniería
	1.3. Ciclo de vida del Team Software Process (TSP)
	1.3.1. Fase de lanzamiento
	1.3.2. Fase de estrategia
	1.3.3. Fase de planeación
	1.3.4. Fase de requerimientos
	1.3.5. Fase de diseño
	1.3.6. Fase de implementación
	1.3.7. Fase de pruebas
	1.3.8. Fase post mórtem
	Cierre de la unidad
	Para saber más
	Fuentes de consulta