Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Unidad 1 Introduccion A TSP PDF
Unidad 1 Introduccion A TSP PDF
Programa de la asignatura:
Desarrollo de software en equipo (TSP)
Clave:
15143636
ndice
1. Introduccin a TSP ......................................................................................................... 2
Presentacin de la unidad .................................................................................................. 2
Propsitos .......................................................................................................................... 3
Competencia especfica ..................................................................................................... 3
1. 1. Proceso de Desarrollo de Team Software Process (TSP) .......................................... 3
1.1.1. Principios y objetivos de TSP ................................................................................... 6
1.1.2. Estrategia de TSP .................................................................................................... 7
1.1.3. Equipo TSP .............................................................................................................. 8
1.2. Estructura del Team Software Process (TSP) ............................................................. 9
1.2.1. Disciplina de equipo ............................................................................................... 11
1.2.2. Disciplina de administracin ................................................................................... 12
1.2.3. Disciplina de ingeniera........................................................................................... 12
1.3. Ciclo de vida del Team Software Process (TSP) ....................................................... 13
1.3.1. Fase de lanzamiento .............................................................................................. 14
1.3.2. Fase de estrategia .................................................................................................. 22
1.3.3. Fase de planeacin ................................................................................................ 25
1.3.4. Fase de requerimientos .......................................................................................... 26
1.3.5. Fase de diseo ....................................................................................................... 27
1.3.6. Fase de implementacin......................................................................................... 28
1.3.7. Fase de pruebas..................................................................................................... 29
1.3.8. Fase post mrtem................................................................................................... 31
Cierre de la unidad ........................................................................................................... 33
Para saber ms ................................................................................................................ 34
Fuentes de consulta ......................................................................................................... 34
1. Introduccin a TSP
Presentacin de la unidad
Bienvenido a la asignatura Desarrollo de software en equipo TSP (Team Software Process),
la cual forma parte del octavo semestre de la igeniera en Desarrollo de Software.
La metodologa PSP (Personal Software Process) est orientada a un contexto individual del
ingeniero en desarrollo de software, mientras que el TSP se enfoca en los equipos y roles de
trabajo. Es necesario contar con la metodologa PSP, porque gua a cada individuo a
alcanzar sus objetivos personales como parte de un proyecto de desarrollo de software, pero
sin olvidar que lo ms importante es la colaboracin, la retroalimentacin entre los miembros
del equipo de desarrollo y, por supuesto, conseguir los objetivos trazados al inicio del
proyecto.
En la Unidad 1. Introduccin a TSP, aprenders los elementos, objetivos y principios en los
cuales se basa esta metodologa, as como su estrategia y estructura, que se aplica a todo el
ciclo de desarrollo del proyecto.
Propsitos
Al trmino de esta unidad logrars:
Competencia especfica
al cliente para saber cmo quiere que funcione el sistema solicitado. Despus de
esto, los analistas e ingenieros de software crean las especificaciones del sistema.
En esta fase se integra la documentacin requerida para el arranque del proyecto, la
cual cambiar de acuerdo con la metodologa propuesta; pero nunca deben de faltar
los documentos donde se muestren los objetivos, visin, roles, puestos y
requerimientos del sistema a desarrollarse.
Funcionamiento y mantenimiento: una vez que el sistema fue aprobado por las
personas designadas en el rea de calidad y pruebas, se le entrega al cliente la
primera versin terminada del sistema, para que la pruebe en el rea de produccin y
verifique el correcto funcionamiento. Si hay nuevos requerimientos se regresa a la
primer fase para realizar las mejoras para el sistema (Sommerville, 2006).
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).
Se dice que el TSP es un proceso de desarrollo porque cumple con esta estructura, pero con
fases propias que ms adelante se explicarn.
Se recomienda el uso de TSP en grupos de 2 a 20 personas y en desarrollos de sistemas
que sean a gran escala.
El TSP se centra en la administracin de proyectos, en la construccin de los equipos de
trabajo de acuerdo a los roles y en el perfil de cada persona que se necesita para los
distintos puestos dentro del proyecto.
En un proyecto de desarrollo de software, se selecciona la cantidad de personal requerida
para los puestos de acuerdo a lo robusto que sea el sistema, pero los puestos necesarios
que propone la metodologa TSP son: lder de equipo, administrador de desarrollo,
administrador de planeacin, administrador de calidad de proceso y administrador de
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software
soporte, cargos que se explicarn con ms detalle en el Tema 1.3. Ciclo de vida del Team
Software Process.
TSP se enfoca en la gestin del equipo de trabajo, y el PSP en la calidad, pero no de todo el
proceso de desarrollo ni del equipo, sino de la calidad y la gestin individual, especialmente
en los desarrolladores de software, para tener una mtrica exacta de su productividad y, con
base en esto, mejorar la calidad en su trabajo.
Piattini (2011) afirma que el TSP se basa en los siguientes elementos:
Un punto muy importante de TSP es lograr la comunicacin entre los miembros del equipo
de desarrollo del proyecto, ya que cada individuo tiene un estilo propio para llevar a cabo las
tareas. Sin embargo, el objetivo siempre ser asegurar la calidad durante todo el proceso de
desarrollo de software.
debe cumplir con un ciclo, el cual ser elegido de acuerdo al tamao y la complejidad del
proyecto.
Por ejemplo, tomemos el modelo en cascada, el cual cuenta con cinco fases que son:
definicin de requerimientos, diseo del sistema y de software, implementacin y prueba de
unidades, integracin y pruebas del sistema, funcionamiento y mantenimiento.
La estrategia principal de TSP se basa en la bsqueda de la mejor manera de introducir sus
ocho procesos dentro de cada fase del ciclo de vida del proyecto, que en este caso sera el
modelo en cascada (Piattini, 2011). Siempre se inicia con una junta donde los lderes e
ingenieros de software presentan los objetivos del proyecto a cada uno de los miembros del
equipo; posteriormente, se aplican los otros siete restantes procesos. En la siguiente fase
(diseo del sistema y de software, segn el modelo cascada) se aplican los mismos ocho
procesos, pero se trabaja sobre lo que ya se haya desarrollado en el ciclo anterior. Con esto
se logra que el producto que, en este caso sera el software que se est desarrollando,
aumente su funcionalidad.
Como pudiste darte cuenta, la estrategia de TSP indica que no importa el modelo de ciclo de
vida que se elija para el desarrollo de software, siempre se van a utilizar los ocho procesos
que nos marca esta metodologa, y se van a implementar en cada una de las fases de
desarrollo del ciclo de vida del software a desarrollar. En el siguiente captulo aprenders las
principales caractersticas que se requieren para integrar los equipos de trabajo, de acuerdo
con algunas condiciones sealadas por el TSP.
El equipo debe formar una estrategia de trabajo en la que todos estn de acuerdo.
Establecer objetivos en comn y definir los roles por parte de los miembros del
equipo.
Definir procesos en comn.
Todos los miembros deben de participar en la creacin de un plan.
El equipo deber negociar el plan con la administracin.
La administracin revisar y aceptar el plan realizado por el equipo.
Los miembros deben de realizar su trabajo de acuerdo al plan.
Deber existir comunicacin frecuente entre los miembros del equipo.
Todos los integrantes debern cooperar y estar comprometidos con un objetivo en
comn.
Los lderes debern de obtener feedback (retroalimentacin) y deben de buscar
liderazgo que mantenga motivados a los miembros del equipo.
En este subtema se revis lo referente a las condiciones necesarias para crear equipos de
trabajo adecuados para implementar la metodologa TSP. En la siguiente actividad
identificars los elementos de la metodologa TSP y la relacin que existe entre ellos.
TSP
trabajo en
creacin
equipo
del equipo
Planes personales
Mtodo de planeacin
Valor agregado
Mtricas de calidad
Procesos definidos
Disciplina
ingenieril
Compromisos
Planes agresivos
Calidad propia
Objetivos del proyecto
Plan propio
Plan detallado
Roles
Roles del equipo
Disciplina
de equipo
Prioridad en la
calidad
Costo de la calidad
Seguir el proceso
Revisin de status
y calidad
Comunicacin
Disciplina de
administracin
Equipos
integrados
Figura 2 Estructura de TSP (Gomez y Ania, 2008).
10
Compromiso: todos los miembros debern tener bien claro cules son los
compromisos con la organizacin y con el cliente, de acuerdo a los objetivos
planteados al inicio del proyecto.
Planes agresivos: son acciones planeadas y bien estructuradas para ejecutarse
rpidamente y lograr objetivos a corto plazo; proporcionan el desempeo eficiente de
los miembros del equipo sin que se sientan presionados y reduzcan su productividad.
Calidad propia: cada desarrollador debe colocar su propio sello al desarrollo en las
pruebas a su cargo, las cuales se realizan de acuerdo al funcionamiento que debe
tener el mdulo del sistema que estn desarrollando. Es muy importante hacer
nfasis en que las pruebas son provisionales, porque las personas de calidad en la
fase de pruebas del ciclo de vida del proyecto las hacen de una manera ms
detallada, con protocolos y estndares bien definidos por el administrador de calidad
de proceso. Esto se ver ms a detalle en la unidad 3. Gestin en TSP.
Objetivo del proyecto: el equipo debe dar su punto de vista de los objetivos que se
plantean al inicio del proyecto, y as tener una visin ms clara acerca de a dnde se
desea llegar.
Plan propio: cada equipo debe de tener su propio plan, establecido por los
administradores al inicio del proyecto. Aprenders cmo hacer uno en la unidad 2.
implementacin de TSP.
Plan detallado: en la documentacin que se crea al inicio del proyecto (donde se
exponen los objetivos, los requerimientos del sistema, etc.) debe haber un plan
detallado sobre las actividades a realizarse a travs de todo el ciclo de vida del
proyecto, y sobre los riesgos que puedan surgir durante el desarrollo del software.
Todo esto lo veremos con ms detalle en el subtema 2.2. Ejecutar el trabajo en
equipo.
Roles: cada miembro del grupo debe tener bien claro cul es su rol dentro del
equipo; los roles se asignan con base en las capacidades y cualidades de cada
persona, y son establecidos por los ingenieros y administradores al inicio del
proyecto.
Recursos del equipo: el equipo debe de utilizar, de manera correcta, los recursos
proporcionados por parte de la empresa que solicita el proyecto de software, por lo
que contrata o integra un equipo TSP.
11
En conclusin, puede decirse que la disciplina de equipo indica reglas muy precisas que
guan las actividades para que se logren los objetivos del proyecto.
Esta disciplina muestra la forma en que los administradores del proyecto deben guiar al
grupo para cumplir los objetivos del proyecto de software.
Planes personales: cada miembro del equipo debe conocer su rol dentro del
proyecto y estar consciente de su responsabilidad para que el objetivo se cumpla.
Mtodo de planeacin: cada miembro debe manejar y planear correctamente sus
tiempos y las responsabilidades que tiene.
Valor agregado: cada miembro del equipo aportar su experiencia y conocimiento en
el desarrollo de los proyectos.
Mtricas de calidad: las mtricas son una referencia exacta para medir el nivel de
algo en especfico. En este caso sirven para controlar, medir, monitorizar, predecir y
probar el desarrollo de software. Por ejemplo, una mtrica podra ser una plantilla
donde muestre los avances que ha tenido el proyecto mes con mes. Esta fase se
explicar con ms detalle en el tema 3.2. Diagnstico: Mtricas de calidad versus
trabajo realizado.
Procesos definidos: muestran a los miembros del equipo un panorama general para
comenzar con el desarrollo del software.
Es muy importante entender con claridad cul es la estructura de TSP y su objetivo en cada
disciplina. Como pudiste aprender, las disciplinas son como recetas de cocina que dicen qu
acciones tomar en todas y cada una de las fases de desarrollo del proyecto. En el siguiente
tema aprenders la forma en que est estructurado el ciclo de vida de la metodologa TSP.
13
1.3.1. Fase de lanzamiento. Cada una de las fases describe las actividades que les son
propias, y que se explican a continuacin (Humphrey, 1999).
Lanzamiento
Estrategia
Planeacin
Requerimientos
Diseo
Implementacin
Pruebas
Post mrtem
Figura 3. Fases del ciclo de vida del TSP (Humphrey, 1999).
14
Objetivos
Ser un
miembro del
equipo
cooperativo y
efectivo
Realizar un
trabajo
personal
disciplinado
Planear y dar
seguimiento al
trabajo
personal
Hacer
productos de
calidad
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 (sta
es una medicin
de la eficacia y
eficiencia que el
equipo
establece,
determina, y
califica).
El porcentaje de
los datos
personales
(desempeo,
eficacia,
etctera)
registrados debe
ser 100%.
Indicador 2
Indicador 3
Indicador 4
La densidad
de defectos
encontrados
durante la
prueba de
unidad debe
La densidad
de defectos
encontrados
durante y
despus de la
prueba de
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
las tareas del
proyecto con
plan y datos
reales
registrados en
forma
correspondiente
debe ser 100%.
El porcentaje de La densidad de
defectos
defectos
encontrados
encontrados
antes de la prime durante la
compilacin
compilacin
debe ser mayor
debe ser menor
El porcentaje de
los datos del
proyecto
personal
registrados en
las formas
correspondientes
debe ser 100%.
15
a 70%.
a 10/KLOC.
ser menor a
5/KLOC.
unidad debe
ser 0.
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%
Indicador 3
Al terminar el
proyecto se debi
haber incluido el
100% de las
funcionalidades.
El porcentaje de
datos del proyecto
debe ser 100%.
Qu?
Cmo?
Cundo?
Quin?
Qu
tan
bien?
Qu
pasa
si...?
16
Los objetivos
del equipo
Diseos
conceptuales
Productos
planeados
La
estrategia
de equipo
El equipo
define el
proceso
Plan de
tareas
Funciones
del equipo
Plan de
calendario
Planes de
trabajo
Plan de
calidad
Evaluacin de
riesgos
Plan de
alternativas
Plan de valor
agregado
Tamao de
estimaciones
Figura 4. Lanzamiento del TSP (Queensland, 2010).
17
Las preguntas que se plantean en el esquema anterior: qu?, cmo?, quin?, qu tan
bien? y qu pasa si...?, permitirn establecer las bases de una estrategia del lanzamiento
para llegar a la culminacin del proyecto; en conjunto con la anterior, se deben tomar en
cuenta los requerimientos que sern establecidos por parte del cliente (Queensland, 2010).
Como se mencion anteriormente, en la fase de lanzamiento se asignan las tareas y roles
del equipo de trabajo, a continuacin de describen los roles del TSP.
Roles de TSP
Lder del proyecto
Es aquel que lleva el mando del equipo, el que lo dirige, esta figura se asegura de que todos
realicen y completen su trabajo, reporten sus procesos tal cual como fue planeado en fin, es
el que maneja los alcances del proyecto (Osorio, 2013, p.2).
El ingeniero que tenga este rol debe realizar reportes semanales sobre los avances del
equipo (Osorio, 2013). En la siguiente tabla se muestra un ejemplo para generar los reportes
de avances del equipo.
18
Equipo:
Ciclo:
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
Semana:
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
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
UABC, 2005
19
Como podrs darte cuenta, el administrador de desarrollo debe de colaborar muy de cerca
con cada uno de los miembros del equipo que desempean los distintos roles.
Administrador de planeacin
El administrador de planeacin es el principal responsable de llevar el control de los planes
del equipo, y de dar apoyo a cada miembro cuando se presenten problemas que estn
relacionadas con el plan.
Debe dirigir la generacin del plan de trabajo en cada ciclo de desarrollo y establecer cmo
estarn definidas las partes del producto final. Administra el qu, quines, cmo, cundo y
dnde se va a hacer. De ello depende la complejidad y factibilidad del proyecto. Est ligado a
los objetivos propuestos, hasta dnde se va a llegar (Osorio, 2013).
20
Administrador de calidad
El administrador de calidad se encarga de proponer el plan de calidad tanto para el proceso
como para el producto. Tiene la responsabilidad de determinar las necesidades que se
presenta dentro del proceso, y le da seguimiento a la calidad del producto.
Tambin determina las necesidades dentro del proceso de calidad que se implementar en
el proyecto de software y le da seguimiento, con el fin de mantener la calidad del producto
(Osorio, 2013).
Sus funciones bsicas son stas:
Es de suma importancia que el administrador de calidad revise que todo el equipo de trabajo
alcance los estndares y patrones de calidad; debe alertar al lder del proyecto sobre
cualquier trabajo que no los cubra.
Administrador de configuraciones
La administracin de configuraciones es considerada uno de los factores de mayor
influencia para lograr el ptimo desarrollo de productos software de alta calidad, porque es la
encargada de garantizar que los cambios sean efectivos y eficientes (Osorio, 2013,).
El administrador de configuraciones debe poseer un documento donde integre el
seguimiento del proceso, es decir, un proceso documentado para realizar el manejo de la
configuracin de los productos y subproductos, donde se indiquen los procedimientos
necesarios para llevar a cabo las labores de administracin de configuraciones tales como:
Establecer los nmeros de las versiones de los productos o que indican dichos
nmeros.
Mantener la trazabilidad (conocer el histrico del proyecto, en este caso las
versiones del producto) de los productos y subproductos desarrollados (Osorio,
2013).
Coordinar todas las actividades de cambio que realice cualquier miembro del equipo.
Administrar el versionamiento (la gestin de los cambios que se realicen en el
producto de software); es decir, administrar el control de cambios y su sistema,
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software
21
22
23
Plan de gestin de riesgos: para realizarlo se debe estar totalmente comprometido con el
proyecto, para elaborar un producto de calidad. En la siguiente tabla se muestra un ejemplo
de gestin de riesgos. Corresponde a un plan de riesgos que se implement en el desarrollo
y mantenimiento de componentes para Web 2.0 en bibliotecas especializadas.
Tabla 5. Ejemplo de gestin de Riesgos
Riesgo RI-05. Inexperiencia del equipo informtico/bibliotecario en el desarrollo e
implementacin del proyecto.
Aspectos a considerar
Por qu el riesgo es importante? Podra alterar la calidad del producto,
provocar atrasos en el desarrollo e implementacin del proyecto.
24
El TSP recomienda que las estrategias definidas sean documentadas para darles un
continuo seguimiento.
En este subtema se describi lo que es una estrategia y la manera en que debe
desarrollarse. Esto tiene como objetivo hacer un producto de calidad, para ello el equipo
debe estar de acuerdo con los criterios de la estrategia y darle seguimiento. Lo ya
mencionado permitir saber cmo se va a realizar el producto de software. Estas estrategias
ayudarn al equipo a preparar la planeacin, la cual se explicar en el siguiente subtema.
Estimacin del tamao de cada parte a ser desarrollada: ste ser determinado
por el tamao del trabajo.
Identificacin de las tareas, estimacin el tiempo necesario para completarlas:
para esto es necesario asignar las tareas a cada miembro del equipo.
Cronograma semanal para tareas terminadas: se puede hacer uso de
herramientas como Microsoft Project, y hacer diagramas de Gantt para llevar el
control de las actividades; all se programan las tareas y se propone una duracin,
fecha de inicio y trmino. Por ltimo, se lleva el control semanal sobre el porcentaje
de cumplimiento.
Plan de calidad: es un documento que especifica quin, cundo y qu
procedimientos y recursos asociados deben aplicarse a un proyecto, producto,
proceso o contrato especfico (Secretara Central de ISO, 2005).
26
denominado Libsys, utilizado por estudiantes y personal docente que solicitan libros y
documentos de otras bibliotecas.
Requerimientos funcionales de Libsys (Olivera, 2010):
1. El usuario deber tener la posibilidad de buscar en el conjunto inicial de la base de
datos o seleccionar un subconjunto.
2. El sistema deber proporcionar visores adecuados para que el usuario lea
documentos en el almacn de documentos.
3. A cada pedido se le deber asignar un identificador nico (id_pedido), que el
usuario podr copiar al rea de almacenamiento permanente de la cuenta.
Es indispensable que los requerimientos sean examinados por el equipo de trabajo para
desarrollar un plan de pruebas.
En conclusin, la fase de requerimiento nos da a conocer lo que el cliente desea y las
funciones que se proponen para el producto a realizar; se llega a un acuerdo mutuo sobre lo
que se va a construir.
Crear un diseo de alto nivel: describen los componentes principales del sistema y
la forma en que interactan entre s. El equipo puede trabajar de forma independiente
ya que es posible separar el diseo en partes. Esto se refiere a la creacin de las GUI
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software
27
Revisin de estndares
Estndares de codificacin
Estndar de tamao
Estndar de defectos
Prevencin de defectos
28
29
pruebas
Construir
prueba.
El jefe del equipo de ayuda a asignar el desarrollo de la
prueba y ensayo entre los miembros del equipo.
Los miembros del equipo de pruebas realizan sus tareas de
desarrollo de las pruebas.
Definir los procesos y procedimientos de generacin
requeridas.
Desarrollar los procedimientos de ensayo de la integracin
y las instalaciones.
Desarrollar los procedimientos de ensayo de sistemas e
instalaciones.
Medir el tamao y el tiempo de funcionamiento para cada
prueba.
Revisar los materiales de prueba y corregir errores.
El equipo construye el producto y comprueba que est
completo. Verifica que todas las piezas necesarias estn a
la mano.
Integracin
Prueba del
sistema
Documentacin
30
Criterios de salida
31
Paso
1
Actividades
Post mrtem
descripcin
general del
proceso.
Revise los
datos de
proceso.
Evaluar el
desempeo
del rol.
Ciclo de
preparacin1. Informe
Preparar
evaluaciones
de funciones
Criterios de salida
32
Cierre de la unidad
El TSP es una metodologa que sirve de gua para los ingenieros informticos; provee
mtodos para el fcil desarrollo de software por medio de miembros que llegan a formarse
en equipos, los cuales se desenvuelven de una manera organizada; tienen su roles y
actividades propias, los dirige un lder que recopila informacin y los mantiene ordenados
para lograr los objetivos planteados.
El ciclo de vida del TSP es una serie de ciclos que se llevan a cabo durante el desarrollo del
producto de software. Comienza con la declaracin de las necesidades del producto y
finaliza con la entrega final.
La fase de lanzamiento es pieza clave para el inicio del desarrollo del software; es aqu
donde se forman los equipos y se asignan las actividades que desempearan cada uno de
los miembros, como ya se explic aqu; pero esto lo vers con ms detalle, junto con la
elaboracin de planes de riesgo y calidad, en la prxima unidad.
Si se desea desarrollar un software, siempre es imprescindible utilizar un mtodo como lo es
el TSP, para lograr un producto confiable y de buena calidad; asimismo nos permitir mejorar
de una manera significativa todos los procesos implicados en el desarrollo.
33
Para saber ms
En la pgina del Institute Carnegie Mellon
(http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm), existe mucha informacin
acerca de las herramientas de medicin de la calidad del desarrollo de software, entre ellas
TSP, sobre la que encontrars diversos artculos y documentos.
Tambin puedes consultar un caso de uso de PSP y TSP en el documento Uso de
tecnologas y metodologas de desarrollo, de Roy Steeven Yarce David, que se encuentra
accesible en la seccin Material de apoyo.
Es recomendable revisar el documento de Watss S. Humprey, The Team Software Process,
donde se explica la metodologa TSP. La versin original de este documento, escrito en
ingls, se encuentra en la seccin Material de apoyo; si no posees el nivel de comprensin
de este idioma, puedes utilizar alguna de las diversas herramientas de traduccin que se
encuentran en Internet.
Fuentes de consulta
Queensland, T. U. (2010). Lecture 14: The Team Software Process. CSSE3002 The
Software Process. Recuperado de
http://itee.uq.edu.au/~csse3002/Lectures/Lect14.pdf
Tuya, Javier; Ramos Romn, Isabel & Dolado Cosn, Javier (2007). Tcnicas
cuantitativas para la gestin en la ingeniera del software. La Corua, Espaa:
Netbiblo
Bibliografa de la imagen:
35