Unidad 2. Implementación de TSP

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

UnADM
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

ndice
Unidad 2. Implementacin de TSP ..................................................................................... 2
Presentacin de la unidad .................................................................................................. 2
Propsitos .......................................................................................................................... 2
Competencia especfica ..................................................................................................... 2
2.1. Formar Equipos de Trabajo ......................................................................................... 2
2.1.1. Documentar propsitos, objetivos y roles del Equipo ................................................ 6
2.1.2. Planear y ejecutar el lanzamiento del proyecto ......................................................... 9
Actividad 1. Planeacin del lanzamiento del proyecto de software ................................... 15
2.2. Ejecutar el trabajo en equipo ..................................................................................... 16
2.2.1 Elaborar el plan del proyecto ................................................................................... 16
2.2.2 Elaborar Plan de Calidad .....................................................................................
20
2.2.3 Elaborar Plan de Riesgos ...................................................................................... 30

Actividad 2. Plan del proyecto .......................................................................................... 35
Autoevaluacin ................................................................................................................. 35
Evidencia de aprendizaje. Generacin del plan de calidad y de riesgos ........................... 36
Cierre de la unidad ........................................................................................................... 36
Para saber ms ................................................................................................................ 37
Fuentes de consulta ......................................................................................................... 37


Presentacin de la unidad
Implementacin segn la RAE (2013), es poner en funcionamiento, aplicar mtodos,
medidas, etc., para llevar algo a cabo. En el marco de la metodologa TSP, la
implementacin se refiere a la ejecucin de las actividades en la cual se debe tener en
cuenta los equipos de trabajo, objetivos, roles y planeacin de proyecto, calidad y riesgos.
En la unidad dos Implementacin de TSP aprenders a implementar esta metodologa para
un proyecto de desarrollo de software, conocers los componentes de la metodologa del
TSP y aprenders la forma adecuada para realizar el propsito y los objetivos del proyecto,
as como las estrategias de integracin de los miembros del equipo y la asignacin de los
diferentes roles que TSP propone. Tambin conocers la forma de hacer los documentos
para establecer el plan del proyecto, el plan de calidad y el plan de riesgos para llevar por
buen camino el proyecto y lograr que los objetivos se cumplan.
Propsitos
Identificars los componentes de la metodologa Team Software Process (TSP) de

acuerdo a la fase del proyecto correspondiente.
Analizars los productos de trabajo de acuerdo a las funciones correspondientes.
Elaborars los productos de trabajo de acuerdo a su objetivo.
Competencia especfica
Analizar los componentes de la metodologa Team Software Process (TSP) para
implementar productos de trabajo en los equipos autodirigidos, mediante la elaboracin de
documentos.
2.1. Formar Equipos de Trabajo

Durante la fase de lanzamiento que TSP propone, es muy importante saber cmo formar un
buen equipo de trabajo no slo donde exista un buen ambiente si no tambin un equipo que
sea capaz, con base en actitud y aptitud llevar el desarrollo del proyecto por buen camino
siempre teniendo presente el objetivo principal del proyecto.
En este captulo aprenders cmo se forman equipos de trabajo adecuados para poder
implementar la metodologa TSP en un proyecto de desarrollo de software. El

establecimiento de un equipo de trabajo se lleva a cabo en la fase de lanzamiento, para que

un equipo de trabajo sea realmente efectivo todos sus miembros deben estar bien
capacitados para las actividades que van a llevar a cabo dentro del proyecto y tambin
trabajar de manera conjunta para lograr cumplir con los objetivos trazados al inicio del
proyecto.
TSP indica ciertas caractersticas que un equipo que trabaje bajo esta metodologa debe
tener (Humphrey, 1999):
Los miembros del equipo deben contar con las habilidades requeridas, esto quiere
decir que si se buscan desarrolladores de software y el proyecto se va a desarrollar
en algn lenguaje de programacin en especfico, se deben buscar personas que
sean expertos en ese lenguaje.
El objetivo del proyecto debe ser claro, bien definido y realista.
Los miembros del equipo debern estar comprometidos en cumplir el objetivo
principal del proyecto a desarrollar.
Entre los miembros del equipo deben ayudarse para solucionar problemas ms
rpidamente y para que exista un buen ambiente en el equipo de trabajo.
Los miembros del equipo deben ser disciplinados en su trabajo.
El equipo debe innovar y ser eficaz, pero para que esto se logre, se debe trabajar en
un ambiente de confianza y apoyarse unos a otros en todo momento.
Los principales elementos para la formacin del equipo de trabajo se muestran en el

siguiente esquema.

Asignacin
de recursos
Habilidades tcnicas:
Trabajo en equipo:
Estimacin y planificacin
Habilidades
necesarias
Gestin de calidad
Comportamiento
interpersonal
Reclutamiento
Dominio de las
aplicaciones
Tecnologa del
producto
Herramientas y
mtodos
Evaluar:
Destrezas y habilidad
Inters por el trabajo
Actitud y energa
Proporcionar
capacitacin
Miembros del equipo

expertos y entrenados
Elementos necesarios para la formacin del equipo (Humphrey, 1999).

Asignacin de recursos: el primer paso para formar el equipo implica llegar a un acuerdo
de administracin de los recursos necesarios. La mayora de los proyectos de desarrollo de
software inician siempre con una estimacin preliminar de costos esperados, de acuerdo al
tamao y a lo complejo del proyecto.
Habilidades necesarias: como se muestra en el la figura anterior las habilidades necesarias
recaen en dos categoras generales que son: la tcnica y el trabajo en equipo.
Dominio de las aplicaciones: se necesitar por lo menos un miembro o ms en el equipo
que tengan total conocimiento y dominio sobre el software que se va a desarrollar, por
ejemplo: para el desarrollo de un software del rea contable, se requiere a alguien que sepa
perfectamente contabilidad para poder orientar el desarrollo del software en cuanto a ciertas
caractersticas especficas del rea de contabilidad y que requieran considerarse para
integrar en el software y as poder ayudar a los dems miembros del equipo a lograr los
objetivos.
Tecnologa del producto: la tecnologa del producto se refiere a lo complejo que puede
llegar a ser el software, esto se basa en qu tan grande o novedoso va a ser el software a
desarrollar, si el proyecto es complejo se necesitar que las personas que conforman el
equipo cuenten con la suficiente experiencia en el desarrollo de sistemas similares para
ayudar a los dems miembros del equipo.
Herramientas y mtodos: se refiere a la herramientas que se necesitarn para llevar a cabo
el desarrollo del proyecto de software tales como el lenguaje de programacin que se va a
ocupar, el motor de base de datos, herramientas para el anlisis y el diseo del software, los
mtodos se refieren a la forma como se van a utilizar esas herramientas. Se requiere que el
equipo cuente con profesionales de software para saber qu herramientas y mtodos se
utilizarn para desarrollar el sistema.
Trabajo en equipo
Hay tres puntos importantes segn la figura anterior de trabajo en equipo:
Estimacin y planificacin: cuando se habla de estimacin, se hace referencia a las
personas que conforman el equipo que sean capaces de estimar o calcular tiempos y as
hacer una planificacin con tiempos adecuados y reales. Las personas con estas cualidades
pueden lograr que el equipo sea auto dirigido, es decir que si se cuenta con una persona con
las cualidades de estimar y planear, sta se encargar de dirigir al equipo sin necesidad de
capacitaciones y as ahorrar tiempo en el desarrollo del proyecto, obviamente al tener
personas con estas habilidades se lograr contar con equipos autodirigidos, que no
necesiten de alguien que para llevar acabo sus actividades, sino por el contrario que aporten

su experiencia al equipo y ayuden a sus dems compaeros para lograr los objetivos
trazados.
Gestin de la calidad: Esto es un aspecto esencial en todos los proyectos que utilicen la
metodologa TSP, Los miembros del equipo de software deben ser competentes en esta
habilidad y todos ellos deben creer que es importante gestionar personalmente la calidad de
su trabajo, incluso cuando estn trabajando bajo presin.
Comportamiento interpersonal: para ser eficaces en un equipo, todos deben ser capaces
de trabajar conjuntamente, participar en la resolucin de problemas y ayudar a los dems
cuando sea necesario. Es necesario enfatizar que, al momento de seleccionar al personal
que formar parte del equipo, quizs se encuentre a personas muy aptas en cuanto a
conocimientos y habilidades pero, si tiene una actitud negativa en cuanto a los aspectos de
colaboracin y desempeo grupal, esto puede generar problemas al interior del grupo y
obstaculizar el ptimo desarrollo de las actividades.
Reclutamiento. Para contratar a las personas que formarn el equipo de trabajo, se requiere
identificar una mezcla particular de destrezas y habilidades. Por eso es muy importante que
antes de iniciar el proceso de reclutamiento, se definan estas necesidades para formar un
equipo adecuado.
Proporcionar capacitacin. Es necesario que se capacite a los miembros del equipo
respecto a la metodologa TSP, las herramientas de comunicacin que se utilizarn y los
diversos procesos en los que intervendrn.
Una vez que se cuenta con un equipo es necesario documentar los propsitos, objetivos y
roles que guiarn las diversas acciones, a continuacin se explicar la forma de
documentacin.
2.1.1. Documentar propsitos, objetivos y roles del equipo

Sin duda la documentacin es una parte muy importante del proceso en la metodologa de
TSP y se refiere a la integracin en documentos de los propsitos, objetivos y roles del
equipo, la creacin de stos se realiza al inicio de la fase de lanzamiento, para despus
redactarlos e integrarlos en una plantilla que se muestran en una junta a todos los miembros
del equipo.
Los objetivos, propsitos y roles del equipo se deben documentar o plasmar en un
documento para que todos los miembros del equipo los puedan ver en cualquier momento,
tambin para que, si se integra un miembro nuevo en una etapa ya avanzada del desarrollo
del proyecto, este tenga acceso a dicha informacin. Lo anterior es muy importante porque

en la plantilla se va a ver reflejado lo que se desea alcanzar cuando el proyecto llegue a su

fin. Cabe sealar que estos documentos se comparten por medio de una red Intranet.
Normalmente los objetivos, propsitos y roles se redactan en un formato o plantilla que debe
contener lo siguiente:
Logo de la empresa que desarrolla el software: esto se ocupara como encabezado y
debe aparecer en todas las pginas del documento.
Nombre del proyecto: es importante saber a qu proyecto pertenece este documento,
recuerda que en una empresa de desarrollo de software normalmente se trabaja en varios
proyectos a la vez, obviamente por eso TSP propone hacer equipos de trabajo, para tener
los proyectos ms controlados y con una estructura bien definida para cada proyecto que se
est realizando. Este nombre se debe de poner debajo del logotipo de la empresa tambin
como encabezado del documento
Control de cambios: no es ms que una pequea tabla donde se controlan los cambios que
va sufriendo el documento original, la cual en el encabezado debe llevar la fecha de
medicacin y el nombre de la persona que cre o modific, por ejemplo:
FECHA DE MODIFICACION
NOMBRE DEL RESPONSABLE
Cabe mencionar que se debern agregar ms filas, cada que una persona realice un cambio
en la plantilla.
Tema del contenido: se tiene que poner como ttulo qu es lo que va a contener esta
plantilla (objetivos, propsitos, roles etc.).
Despus estos documentos se suben a una Intranet; una intranet es parecido a una pgina
web, la nica diferencia es que slo permite ver el contenido a las personas que estn dentro
de la red de la empresa. Esto se hace con la finalidad de que todos los miembros del equipo
de acuerdo al proyecto en el que estn trabajando puedan acceder a estos documentos en
cualquier momento.
TSP como metodologa proporciona algunas plantillas como por ejemplo la plantilla LAU 1
(por las primeras letras de la palabra lanzamiento en ingles Launch) que se mostrar en el
siguiente subtema.
Propsitos

Un propsito es un discurso claro, que se debe redactar en mximo dos prrafos en el cual
se reflejarn las intenciones o lo que se pretende alcanzar de un proyecto (Saskatchewan,
2002). Es preciso mencionar que redactar el propsito del proyecto es muy importante,
porque ms tarde se reflejar en los objetivos del mismo, los propsitos dan una visin de
qu se quiere lograr al final del proyecto, los encargados de hacer el propsito son el lder de
proyecto, el auxiliar de planeacin y el administrador de desarrollo, y son aprobados por la
alta gerencia, ms adelante se mencionar quines son estas personas.
Objetivos
Los objetivos son las metas que se espera alcanzar cuando un proyecto llegue a su fin. Los
objetivos siempre deben comenzar con un verbo en infinitivo; estos verbos son los que no
estn conjugados y todos tienen la terminacin ar, er, ir, algunos ejemplos serian:
desarrollar, analizar, concluir, examinar, interpretar, describir.
Para realizar un buen objetivo para un proyecto de sistemas de informacin, se debe primero
poner el verbo en infinitivo y contestar las preguntas que se desean realizar en torno a qu
tipo de software se desarrollar? Por ejemplo: puede ser contable, para administracin de
alumnos en una escuela, software para controlar el rea de ventas etctera, para quin
ser el software a desarrollar?, es decir, el cliente o empresa que requiere este recurso, y
por ltimo con qu se va realizar?, se refiere a las herramientas necesarias para llevar a
cabo ese proyecto de sistemas de informacin.
El ejemplo de un objetivo de acuerdo a un proyecto a realizar ocupando la metodologa TSP
sera el siguiente:
Desarrollar un sistema de administracin contable completo y fcil de utilizar para la empresa
Contab S.A de C.V que permita a los usuarios del sistema realizar la contabilidad para sus
clientes y obtener reportes accesibles, con el uso de herramientas como .net, Hibernate,
JQuery y SQL Server crear un software de calidad que cumpla con todos los requerimientos,
estndares y necesidades que la empresa Contab requiere.
Roles
En la Unidad 1 captulo 1.1.3. Fase de lanzamiento, se describen y explican los cinco roles
bsicos que propone TSP y que conforman la parte medular de un equipo en TSP, que
desempean 5 personas que conformaran la base del equipo:
Lder de proyecto
Administrador de desarrollo
Auxiliar de planeacin
Administrador de calidad

Administrador de configuraciones
Estos roles que propone la metodologa TSP son necesarios si se quiere implementar esta
metodologa. Hay que tomar en cuenta que se requiere de un grupo de desarrolladores de
software formados en PSP e ingenieros de calidad, que estarn a cargo del administrador de
calidad y del administrador de desarrollo, los cuales determinarn la cantidad con base en el
tamao del software a desarrollar. La experiencia y la capacidad individual de cada
desarrollador e ingeniero de calidad sern un factor muy importante al momento de hacer
esta seleccin, recuerda que estas actividades se llevan a cabo en la fase de lanzamiento
del proyecto y estos se redactan en una plantilla que indica la metodologa TSP llamada
LAU1 y se detallar en el siguiente subtema, es importante mencionar que tambin ya
finalizada la fase de lanzamiento se puede utilizar la plantilla de la unidad uno captulo 1.3.3.
Fase de planeacin.
En este subtema aprendiste dnde se integran los propsitos y objetivos as como los roles
que propone la metodologa TSP, en el siguiente subtema revisars ms a detalle la plantilla
LAU1 y la forma en que planean y ejecutan los administradores del proyecto el lanzamiento
del mismo.
2.1.2 Planear y ejecutar el lanzamiento del proyecto

En este captulo aprenders cmo se planea y ejecuta un proyecto utilizando la metodologa
TSP, tambin se revisar la forma en que se integran los datos en la plantilla LAU1
(LAUNCH script 1) que propone TSP para realizar el lanzamiento del software a
desarrollarse.
Antes de empezar con todo la fase de lanzamiento, TSP propone realizar un checklist. En el
se redactarn las actividades y el orden en el que se llevarn a cabo todas las tareas de esta
fase, este checklist contiene lo siguiente:
1
2
3
4
5
6
7
8
9
10
Actividad
Establecer productos y objetivos de la empresa
Establecer roles y objetivos del equipo
Definir estrategia de desarrollo
Hacer un plan general
Hacer un plan de calidad
Balancear el plan(carga de trabajo)
Plan de riesgos
Disear reporte de administracin
Revisin del plan con administracin
Anlisis Postmortem. el equipo revisa el proceso
Estatus

En la columna estatus se pude palomear, pero lo ms correcto, es poner todos en

pendiente y conforme se vayan completando las actividades se cambie el estatus a
completado.
Una vez que el lder del proyecto, el auxiliar de planeacin y el administrador de desarrollo
redacten los objetivos, el propsito, roles y el checklist, crearn una plantilla que la
metodologa TSP seala como esencial llamada LAU1, como se muestra en la figura 2.2,
posteriormente se impartir un curso y se mostrar esta plantilla a todos los miembros del
equipo.
Como se mencion anteriormente en una empresa que se dedica al desarrollo de software
pueden trabajar en varios proyectos a la vez, para cada proyecto se conforman equipos de
trabajo llamados clulas de trabajo, dentro de cada una de estas clulas, estarn las cinco
personas que obtendrn los roles que TSP propone y un grupo de desarrolladores e
ingenieros de calidad que se encargarn del desarrollo del proyecto al que hayan sido
asignados dentro de su clula. Los reportes que cada equipo debe entregar son definidos en
las reuniones que TSP seala para ejecutar el lanzamiento del proyecto. Ms adelante se
explicar a detalle qu temas se tocan en cada reunin.
Propsito
Crear los equipos en el primer ciclo de desarrollo
Criterios
de entrada
Todos los miembros del equipo deben completar el curso de PSP
General
Con esta plantilla se inicia el proyecto en equipo

Los objetivos se describen en esta junta
Se forman los equipos y se realiza la asignacin de roles
Se explican los objetivos del proyecto a desarrollar.
Se establecen las juntas de los equipos y los tiempos de entrega de los reportes.
Paso
1
4
5
Actividad
Resumen del
curso
Informacin del
integrante del
equipo
Objetivos del
producto
Asignacin de
equipos
Objetivos del
Descripcin
El instructor describe los objetivos del curso
Qu se espera que los miembros el equipo logren
Cmo ser evaluado y calificado su trabajo
Principios bsicos del trabajo en equipo
El proceso de TSP
El instructor explica los criterios para hacer la asignacin de equipos
Informacin necesaria para la asignacin adecuada
Roles del equipo, responsabilidades y aptitudes

El instructor describe los objetivos del producto.
Los objetivos crticos que deben ser satisfechos.
Los objetivos deseables y opcionales.
Los criterios para evaluar un producto terminado.

El instructor asigna a los asistentes su equipo y les asigna su rol
El instructor describe los parmetros de los objetivos.
10

equipo
Reuniones del
equipo
La primera
reunin del equipo
Datos requeridos
Inicia el proyecto
Por qu se necesitan los objetivos y metas del equipo.

El instructor explica las reuniones del equipo y su propsito.
El propsito de las juntas de equipo, fechas y reportes.
Datos requeridos semanalmente

El lder del equipo tiene su primera reunin con su equipo.
Se discuten los roles de los miembros del equipo.
Se discuten y se acuerdan los objetivos del ciclo 1.
Se establecen los tiempos de las reuniones semanales.
Se especifican y se acuerdan los tiempos semanales de todos

los miembros del equipo para dar sus reportes semanales al
administrador de planeacin.
El administrador de planeacin revisa por equipo:
Los datos requeridos por cada miembro del equipo

semanalmente.
Los reportes que sern generados y entregados al equipo de

estos datos
Los equipos inician su trabajo en el proyecto
Plantilla LAU 1
A continuacin se explicarn los elementos que se deben integrar en cada columna de la
plantilla LAU1, mismos que conforman el listado de acciones o checklist de la fase de
lanzamiento de TSP.
Propsito. En el propsito general se describen los objetivos del curso que son los
siguientes:
Asignar los roles (recuerda que cada rol que propone TSP lo adquiere una persona
cualificada para ese rol).
A cada uno de ellos se les asigna un equipo de trabajo.
Criterios de entrada. En la fila criterios de entrada (entry criteria) se integrar como primer
requisito que los miembros del equipo hayan completado su curso de PSP, como se revis
en la asignatura Mtricas de Calidad PSP, es una metodologa de calidad a nivel personal y
es de suma importancia si se quiere aplicar TSP que todos los integrantes del equipo
conozcan y dominen PSP.
General. El instructor del curso expone los objetivos del software a desarrollar:
Establecer los tiempos de las juntas.

Establecer los reportes a entregar.
Paso 1. En esta fila se integra una introduccin y un resumen del curso a los miembros el
equipo, la persona encargada de la junta describe los siguientes puntos:
Qu se espera que logren los miembros del equipo a lo largo del curso.
Como ser evaluado su desempeo dentro del curso.
11

Explicar brevemente el tema trabajo en equipo. Este tema lo expondr la persona

encargada de impartir el curso.
Exponer ante el equipo qu es la metodologa TSP y sus diferentes procesos, por lo cual
el instructor la explicar en esta parte del curso.
Paso 2. En esta fila, se expone a los asistentes al curso la forma en que se realizar la
asignacin de los equipos
Informacin necesaria para la asignacin adecuada de cada integrante al su

respectivo equipo.
Se redacta a detalle la informacin sobre los diferentes roles del equipo, as como las
responsabilidades y aptitudes que deben tener cada miembro para cada rol. Las
responsabilidades son las obligaciones y el compromiso que adquiere cada miembro
del equipo para realizar el proyecto de acuerdo a su rol y las aptitudes son los
conocimientos, experiencia y habilidades especficas que una persona necesita para
adquirir y desempear un rol dentro del equipo
Paso 3. En esta fila se sealan los objetivos del producto a desarrollar y se deben exponer
los siguientes puntos:
El objetivo principal del proyecto de desarrollo de software, que generalmente

explicar que funcionamiento tendr el software, la empresa que solicit el recurso de
software que se desarrollar y las herramientas para desarrollar el software en
cuestin.
Los objetivos secundarios del proyecto, estos objetivos pueden ser objetivos ms
pequeos y a corto plazo los cuales en conjunto permitirn lograr el objetivo principal.
Los criterios para que se pueda evaluar el software como un producto terminado. En
esta parte se describen los documentos entregables al final del desarrollo del
proyecto (Manual de usuario, manual tcnico, ejecutable o instalador del software
desarrollado, las licencias requeridas, etctera).
Paso 4. En este paso, se indica la forma en que se integrarn los nombres de cada uno de
los miembros del equipo. El instructor del curso dar a conocer a cada miembro uno de los
miembros, el equipo al que se integrarn y la asignacin de roles para cada puesto.
Paso 5. En esta parte el instructor del curso describe los objetivos para los equipos de
trabajo y los roles.
Paso 6. En este paso el instructor da a conocer las fechas de las futuras juntas el tiempo
que dure el desarrollo del sistema.
Paso 7. Se indica que cada lder de equipo tendr la primera junta con su equipo (aqu solo
se mencionan las fechas, ms adelante se explican las reuniones y qu se va a ver en cada
reunin), y se indican algunos puntos que se deben discutir en dicha junta:
12

Los roles de los miembros del equipo.

Objetivos del equipo.
Establecer un estndar para las juntas semanales.
Paso 8. Se explica que el administrador de planeacin deber revisar con el equipo el

trabajo que se le haya solicitado a cada miembro una vez por semana, as como generar
reportes (plantillas de PSP donde se haga el anlisis individual de trabajo) donde se plasmen
estos avances.
Paso 9. Por ltimo en el paso 9 una vez aclarados todos los pasos, se inicia el proyecto y se
pasa a la siguiente fase de TSP que es implementacin.
El lanzamiento TSP es una serie estructurada de las actividades del equipo guiados por un
entrenador TSP que tambin es el encargado de dar el curso donde se muestra la plantilla
LAU 1; el proceso de ejecucin del lanzamiento tiene una duracin de dos a cinco das, e
incluye nueve reuniones y una post-mortem.
Las reuniones de ejecucin del lanzamiento son las siguientes:
Reunin 1: Los administradores presentan los objetivos del proyecto y dan a conocer gastos
crticos si no se entrega el proyecto, fechas de entregas o los requisitos de calidad. . El
equipo tiene la oportunidad de hacer preguntas acerca de los requisitos y limitaciones con el
fin de aclarar su comprensin de la presentacin de los administradores.
Reunin 2: El equipo define sus objetivos.
Reunin 3: El equipo crea el diseo conceptual del software a desarrollar, definen el
proceso y los planes de apoyo del equipo, crean la estrategia del proyecto y reparten el
trabajo.
Reunin 4: El equipo calcula el tamao de las partes del diseo conceptual y crea el plan
general donde vienen los recursos del proyecto as como el calendario de desarrollo del
mismo.
Reunin 5: El equipo crea el plan de calidad.
Reunin 6: El equipo divide el trabajo en proyectos personales individuales para cada fase
del desarrollo y as balancear la carga de trabajo.
Reunin 7: El equipo identifica riesgos que puedan surgir durante el desarrollo del proyecto.
Reunin 8: El equipo prepara un plan para presentar el plan que crearon con la alta
gerencia (comn mente estos puestos los ocupan los dueos de la empresa que va a
desarrollar el software).
13

Reunin 9: El equipo presenta sus planes y planes alternativos (si es que los tienen) para la
administracin del proyecto y recibe la aprobacin de la alta gerencia. En el paso 9 se indica
que una vez concluida la reunin se inicia el proyecto.
Lanzamiento post-mortem: En este paso se generan las mejoras a los procesos de la fase
de desarrollo y se hace una evaluacin de toda la fase de lanzamiento.
14

Actividad 1. Planeacin del lanzamiento del proyecto de software

Esta actividad tiene como propsito identificar los pasos mediante los cuales se generar el
checklist de la planeacin del lanzamiento del proyecto de software. Para ello, revisa el
documento que te enviar previamente tu Facilitador(a) y posteriormente realiza lo que a
continuacin se te indica:
1. Identifica los elementos de la planeacin del lanzamiento del proyecto.
2. Genera el checklist con base en el planteamiento recibido.
3. Redacta tus conclusiones acerca de los elementos que integran el problema y
cmo se relacionan con los elementos de planeacin del lanzamiento de TSP.
4. Identifica si hay elementos que faltan respecto al checklist de la fase de
lanzamiento y cules son los efectos que puede tener para el desarrollo del
proyecto si no se cubre este elemento. Redacta este anlisis en una conclusin
al final del checklist sealando cul es la solucin que plantearas para que no
repercutiera en el desarrollo del proyecto.
5. Guarda la actividad con el nombre DDSE_U2_A1_XXYZ. Sustituye las XX por
las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por
tu segundo apellido.
6. Enva tu actividad al facilitador mediante la herramienta bases de datos
7. Comenta la actividad de por lo menos dos de tus compaeros e identifica
semejanzas y diferencias respecto a tus propias conclusiones.
*No olvides consultar el documento Criterios de evaluacin para las actividades de la unidad
2 donde podrs conocer los parmetros de evaluacin de esta actividad.
Nota: para integrar los datos correspondientes a algunos de los pasos de la fase de
lanzamiento, se requiere consultar la Unidad 1.
15

2.2. Ejecutar el trabajo en equipo

En este captulo aprenders cmo una vez que se cuenta con la definicin del propsito, los
objetivos y los roles bien definidos, se ejecuta el trabajo en equipo.
Una vez que todos los miembros del equipo conocen cul es el rol que les toca desempear
dentro del proyecto, los lderes son los encargados de mantener a los miembros del equipo
motivados para que realicen sus actividades de la mejor manera. Como se observ en la
unidad 1, TSP brinda una metodologa muy bien definida para trabajar con grupos en todos
los ciclos de vida del desarrollo del proyecto, pero aqu surgen algunas preguntas para los
administradores del proyecto Cmo controlar el proyecto de acuerdo a su tamao?,
Cmo saber que el producto est cumpliendo con la calidad deseada?, si ocurre algn
problema durante el desarrollo del proyecto cmo controlar los riesgos que puedan
surgir durante el desarrollo del mismo?
Afortunadamente TSP brinda una serie de planes para resolver estas preguntas y llevar por
buen rumbo el desarrollo del proyecto para llegar a los objetivos planteados en la fase de
lanzamiento del mismo.
En los siguientes subtemas aprenders la forma y estrategias de creacin de estos planes,
para contar con una mtrica exacta de posibles errores que surjan en el desarrollo del
proyecto, y as poder controlar de una manera ms adecuada y dar solucin a estos
problemas, para lograr entregar el producto final en el tiempo estimado y con la calidad
requerida.
2.2.1. Elaborar el plan del proyecto

En este tema conocers qu es el plan de proyecto, la importancia de aplicarlo durante el
desarrollo del mismo y las actividades que se deben realizar para hacer un adecuado plan.
Un plan de proyecto es una gua de las actividades que se realizan en un proyecto y la
manera en que deben estar organizadas en cuanto a tiempo, as como la secuencia y orden.
Dentro del plan de proyecto se dividen las tareas y actividades, as mismo se ordenan entre
los hitos del proyecto, un hito se refiere a la duracin de una tarea o actividad que termina
hasta la culminacin de su objetivo, estos tienen descripcin y fecha bien definidas
(Rodrguez, 2007).
Un plan de proyecto se debe hacer una vez que ha sido convenido formalmente por el cliente
y el equipo el proyecto a desarrollar. El plan de proyecto es un medio de comunicacin que
dar a conocer las decisiones que se lleguen a tomar por los participantes del proyecto. El
16

plan de proyecto permite que la comunicacin sea mucho ms fcil entre los involucrados en
el desarrollo del proyecto.
El principal responsable de generar el plan de proyecto es el lder de proyecto, quien debe
asegurar que se elabore correctamente, que contenga los elementos necesarios y se
ejecute. En un plan de proyecto se contemplan los siguientes cuestionamientos Quin?,
Qu?, Por qu?, Cundo?, Dnde?, Cmo? y Cundo?
A continuacin se mencionan los elementos que componen un plan de proyecto.
Definicin del alcance.

Estructura de desglose de trabajo.
Cronograma de actividades.
Recursos requeridos.
Presupuesto definitivo del proyecto.
Asignacin de roles y responsabilidades.
Riesgos.
Definicin del alcance

Para poder expresar el alcance es muy importante generar un enunciado correcto en donde
se va a establecer hasta dnde se va a hacer. Para poder generar el enunciado del alcance
se recomienda incluir lo siguiente:
Los objetivos. Estos sern los objetivos planteados para el proyecto.

Descripcin. Esta se har de los productos o servicios que se realizarn.
Lmites del Proyecto. Lo que se incluye y excluye.
Supuestos. Esto se refiere a las situaciones que se dan por hecho, por ejemplo se
cuenta con el equipo de cmputo necesario para la programacin del sistema.
Restricciones. Son las normas, reglas y polticas a las cuales el proyecto debe de
seguir.
Estructura de desglose de trabajo
La estructura de desglose de trabajo (EDT) es una herramienta que se utiliza para
especificar el alcance de un proyecto, y es una representacin grfica de los elementos
principales de la planeacin del proyecto. La estructura de desglose de trabajo es semejante
la estructura de un organigrama de una empresa, la cual identifica las los elementos de un
proyecto. El EDT depender de los requerimientos del proyecto, los cuales revisar el equipo
17

de proyecto. En la siguiente ilustracin se muestra un ejemplo de la estructura de desglose

de trabajo para el desarrollo e implementacin del sistema de gestin de compras de una
empresa.
Esquema ejemplo de estructura de desglose de trabajo (Cybertesis, 2009).
Sistema de
gestin de
compras
1. Anlisis y diseo
1.1
Requerimientos
del Sistema
2. Desarrollo
5.2.1Plan de gestin
de alcance
3. Pruebas
2.1 Visar
requerimiento
3.1 Plan de
pruebas
2. 2 Aprobar
requerimiento
3.2 Actas de
conformidad
de pruebas
4. Implementacin
5. Gestin
4.1 Manual
de usuario
5.1 Inicio
4.2
Instaladores
del sistema
5.2
Planificaci
n
5.2.2 EDT
5.2.3
Cronograma
del proyecto
5.2.4 Presupuesto de
costos
1. 2 Diagrama del
sistema
5.2.5 Plan de
gestin de calidad
2.3 Seleccionar
cotizaciones
3.3 Manuales
de sistema
5.3 Ejecucin
5.2.6 Registro de
riesgos
1.3 Prototipo
1.4 Informes
preliminares de
anlisis y diseo
2.4 Aprobar
cotizaciones
5.4
Seguimiento
y control
5.2.7 Plan de
gestin de riesgos
5.2.8 Plan de
gestin de
personal
5.5 Cierre
2.5 Visar
orden de
compra
5.2.9 Plan de
gestin de
comunicaciones
2.6 Aprobar
orden de
compra
5.2.10 Plan de
gestin de
adquisiciones
5.2.11 Acta
de aceptacin
final
18

Cronograma de actividades.
El diagrama de actividades es una representacin grfica detallada de la secuencia en la que
sern ejecutadas las actividades, estas secuencias se deben de establecer por medio de
fechas. Existen diversas herramientas para generar este tipo de diagramas, solo por
mencionar una de estas se encuentra Microsoft Project.
Recursos requeridos.
Los recursos humanos y materiales se establecen a partir de los roles y actividades de los
miembros del equipo
Presupuesto definitivo del Proyecto. Las estimaciones de costo se hacen en base a los
costos asignados a las actividades y recursos que se hayan realizado en el proyecto.
Asignacin de roles y responsabilidades. Es de suma importancia delegar a los miembros
del equipo las tareas y actividades que desempearan dependiendo de las habilidades,
actitudes y aptitudes como ya se ha explicado en los temas anteriores.
Riesgos. La gestin de riesgos es una de las actividades ms importantes dentro de la
planeacin del proyecto ya que de ste depender el cumplimiento de los objetivos del
proyecto, en el captulo 2.2.3 se abordar ms a detalle la elaboracin del plan de riesgos
dentro de esta unidad.
Dentro de un plan de proyecto se deben considerar los objetivos y actividades a realizar,
estas deben ser claras y bien definidas. En un plan de proyecto se contempla la versin
inicial del proyecto, cada una de estas versiones del plan de proyecto debe ser colocada en
la administracin de configuracin, adems de contener un calendario para programar las
actualizaciones futuras del plan de proyecto.
Es de gran importancia generar un plan de proyecto ya que de ste depender que los
objetivos propuestos en cada una de las actividades puedan cumplirse en tiempo y forma.
As tambin al generar un plan de proyecto de establecer las bases de hasta donde se
quiere hacer y lo que se va a hacer.
19

2.2.2. Elaborar plan de calidad

En este captulo aprenders a elaborar un plan de calidad de acuerdo a la metodologa TSP,
este plan es muy importante porque con ste se podr tener una mtrica exacta de qu se
est haciendo bien y los posibles fallos que surjan a travs del desarrollo del proyecto.
En la fase de lanzamiento del proyecto se define el plan de calidad, se basa en el tamao del
proyecto y de acuerdo a esto se inyectarn defectos (Humphrey, 2006) que no es ms que
introducir defectos en cada una de las fases de desarrollo. Para entender ms claro este
punto, el plan de calidad se basa totalmente en PSP; es necesario recordar que en PSP se
hacen plantillas, por ejemplo los desarrolladores plasman en estas plantillas los errores que
van teniendo al codificar, el tiempo que pierden al tener estos errores y al final del da se
hace un anlisis de cules fueron los errores que ms se repitieron para tener oportunidad
de mejora. Por ejemplo, para los desarrolladores de software, el error ms comn al codificar
son los errores de punto y coma, el administrador de desarrollo retoma esta concurrencia de
errores y al momento de aplicar el plan de calidad se inyectan estos errores en el cdigo
para saber de manera exacta qu tan bien estn codificando los desarrolladores.
Una vez que los ingenieros y administradores han identificado qu errores inyectar TSP se
propone usar un histrico con estimaciones (yields), estos darn el porcentaje de
productividad de acuerdo al trabajo realizado por cada miembro del equipo al que
corresponda. Finalmente el equipo examina este plan de calidad para ver si los parmetros
son razonables y si cumplen con los objetivos de calidad del equipo de trabajo.
El contenido del plan de calidad debe integrarse por los siguientes elementos los cuales se
exponen uno por uno detalladamente a continuacin:
Resumen de porcentaje. Se refiere a la exposicin breve y precisa del porcentaje de
errores por lnea de cdigo.
Los porcentajes tienen tres medidas en la calidad del proceso:
LOC/Horas (por sus siglas en ingls LOC quiere decir Line Of Code Lnea de cdigo): Esta
operacin de dividir las lneas de cdigo entre las horas por da o segn se establezca, con
base en el registro de tiempos que se indica en PSP mencionada en la asignatura Mtricas
de desarrollo de software. El resumen del porcentaje indica la calidad global del equipo, un
nmero grande indica costos bajos y productividad alta.
% Reutilizacin: mide el porcentaje del producto si fue reutilizado de algn otro u otros
proyectos.
% Reutilizacin Nuevo: mide la contribucin del ciclo en futuros proyectos.
20

Porcentaje Libre de Defectos (PDF). Mide el porcentaje de los componentes de un

producto cuando no se encuentran defectos en una fase dada.
Un ejemplo de PDF sera:
En un componente de 10 partes al momento de hacer las pruebas 9 de ellas tienen errores,
el PDF en la fase e compilacin es de 10% (no se toman en cuenta los errores slo la parte
que est bien).
Defectos por pgina. Muestra los defectos removidos en cada pgina del documento de
requerimientos.
Defectos por KLOC. KLOC significa mil lneas de cdigo LOC por sus siglas en ingls Line
Of Code significa lnea de cdigo. La experiencia muestra que cuando un producto tiene
menos de 0.5 defectos/KLOC en construccin y pruebas de integracin y menos de 0.2
defectos/KLOC en pruebas de sistema, generalmente no habr defectos para que encuentre
el usuario (producto de alta calidad) estas mtricas se ejemplifican al final del captulo. (Para
recordar cmo se pueden contar las lneas de cdigo, recurre a la asignatura Mtricas de
desarrollo de software).
Proporcin de defectos (RATIO)
Proporciona mayor calidad a detalle en las revisiones de diseo y de cdigo, esto se mide en
nmero de defectos encontrados en revisin de diseo contra nmero de defectos
encontrados en pruebas unitarias. La proporcin para considerar un producto de calidad
deber ser mayor a 2.0.
Proporcin de tiempos de desarrollo.
25% del tiempo de requerimientos debe designarse a la inspeccin de requerimientos.
50% del tiempo de diseo de alto nivel debe designarse a las inspecciones y revisiones.
100% del tiempo de diseo detallado debe asignarse a ser las inspecciones y revisiones.
A/FR (appraisal to failure ratio)
Esta parte se refiere a la revisin y pruebas del sistema la medida para que se considere un
producto de calidad seria de 2.0 para programas pequeos y 1.0 en programas grandes.
21

Porcentaje de revisin e inspeccin

En requerimientos debe ser <2.0 pginas de texto a espacio simple por hora.
En diseo de alto nivel <5.0 pginas de diseo por hora.
Diseo detallado la revisin debe ser <100 lneas de pseudo cdigo por hora.
En cdigo debe ser <200 lneas de cdigo por hora.
Porcentaje de inyeccin de defectos (yield)
De acuerdo a experiencias basadas en PSP la inyeccin de defectos debe ser de 2 defectos
por hora en diseo detallado y de 6 defectos inyectados por hora en codificacin.
Porcentaje de eliminacin de defectos
Tomando en cuenta el punto el porcentaje de inyeccin de defectos, se obtienen los
siguientes datos:
En revisin de cdigo de 0 a 20 defectos por hora sern 6 defectos por hora para el 61.5%
de los miembros del equipo de desarrollo. (Para recordar sobre la forma de documentar esta
revisin, consulta la asignatura Mtricas de desarrollo de software).
En revisin de diseo ser de 2 o ms defectos por hora para el 57.9% de los miembros de
equipo de diseo.
Rendimiento yield de fase
Para entender este punto se expone un ejemplo:
Se tienen 19 defectos en un programa a la entrada de la revisin de cdigo, se inyect un
defecto durante la revisin de cdigo, se encontraron 15 defectos durante la revisin.
1. Inyeccin del defecto.
2. Se detectaron 15 defectos en la revisin.
Contando con estos datos, para obtener el rendimiento yield se aplica la siguiente frmula:
Yield = 100* (defectos encontrados)/ (defectos en el producto) = 100* 15/(19+1) = 75%
Se sabe que el yield slo se puede calcular cuando se ha terminado el programa y se sabe
la cantidad total de defectos.
22

Rendimiento yield de proceso

Estos yields son el porcentaje de defectos removidos antes de cada fase se puede decir que
antes de entrar a la fase de pruebas de sistema se debe de tener el 99% de defectos
removidos.
Ejemplo de plan de calidad.
En el siguiente ejemplo se observar la forma en que se puede realizar un plan de calidad
(Cano, 2009):
En primer lugar se responde al cuestionamiento siguiente:
1. Qu tipo de defectos se introdujeron durante el diseo y la codificacin?
En la fase de diseo los defectos ms frecuentemente introducidos fueron los de tipo 70 y
80 pues ambos ocurrieron con una frecuencia de 4 y con un porcentaje de 33.3% como se
muestra en la tabla Defectos introducidos en las fases de diseo y codificacin.
As mismo los defectos de tipo 20 fueron los que tuvieron la mayor ocurrencia en la fase de
codificacin con una ocurrencia de 30 y un porcentaje de 52.6% como se puede observar en
la siguiente tabla llamada Defectos introducidos en las fases de diseo y codificacin.
Tipo
10
20
30
40
50
60
70
80
90
100
Total
Nmero
inyectado
Diseo cdigo
0
1
2
30
0
3
1
2
1
2
0
0
4
9
4
6
0
4
0
0
12
57
Porcentaje inyectado
Diseo
0,0%
16,7%
0,0%
8,3%
8,3%
0,0%
33,3%
33,3%
0,0%
0,0%
Cdigo
1,8%
52,6%
5,3%
3,5%
3,5%
0,0%
15,8%
10,5%
7,0%
0,0%
Defectos introducidos en las fases de diseo y codificacin (Cano, 2009):
El nmero de defectos introducidos en la fase de diseo fueron doce, como se indica en la

tabla anterior, esto es un nmero aceptable de errores de diseo pues son los ms costosos
en tiempo tanto para encontrarlos como para corregirlos.
23

A diferencia de la fase de codificacin los defectos de tipo 20 no figuraron entre los

defectos ms comunes, como se muestra en la siguiente tabla llamada Defectos menos
introducidos en la fase de diseo.
Defectos menos introducidos en la fase de diseo
Nmero
Porcentaje inyectado
inyectado
10
0
0,0%
20
2
16,7%
30
0
0,0%
40
1
8,3%
50
1
8,3%
60
0
0,0%
90
0
0,0%
100
0
0,0%
Defectos menos introducidos en la fase de diseo
Tipo
Para la fase de codificacin el nmero de errores es mucho mayor en comparacin de la

fase de Diseo y los errores ms comunes fueron los de tipo 20 con 30 ocurrencias y un
porcentaje de 52.6%.
Es necesario hacer una clasificacin de errores ms comunes tanto en la fase de diseo
como en la de codificacin y vale la pena tener una clasificacin de estos pues ocurrieron por
distintos motivos.
Clasificacin de defectos de tipo 70 en diseo
Clasificacin del defecto
Nmeros de defectos
introducidos
71
Mal clculo de la funcin
2
72
Error de parmetros
2
Total
4
Clasificacin de los errores tipo 70 introducidos en la fase de diseo
Tipo
Clasificacin de defectos tipo 80 en diseo

Tipo
Nmero de defectos introducidos
81
Mal funcionamiento
3
82
Recodificacin
1
Total
4
Clasificacin de los errores tipo 80 introducidos en la fase de diseo
Tipo
21
Clasificacin del defecto tipo 20 en codificacin

Nmero de defectos
introducidos
Error de dedo
18
24

22
Inicializacin de variables
5
23
Tipo de dato incompatible
6
24
Error de parmetros
1
Total
30
Clasificacin de los errores tipo 20 introducidos en la fase de codificacin
2. Qu tendencias son evidentes en defectos/KLOC encontradas en las revisiones, en

la compilacin y en las pruebas?
Las revisiones permiten mitigar un gran nmero de defectos y as los programas llegaron a
las fases posteriores con revisiones y con menos errores.
Grficas de defectos eliminados durante las revisiones de diseo y codificacin.

En la grfica anterior se muestra la tendencia a dejar pasar cada vez menos defectos a las
fases posteriores y esto ocasion que los programas se hicieran con mayor calidad.
En las fases de compilacin y pruebas se observaron cada vez menos errores como una
situacin favorable que aport la intervencin de las revisiones de diseo y codificacin que
fueron las que ms errores captaron.
25

Grficos de defectos eliminados en las fases de compilacin y pruebas.
3. Qu tendencias son evidentes en el total de defectos/KLOC?

El nmero de errores en la primera mitad del curso fue muy elevado como se observa en la
grfica anterior, pero cuando se introdujeron las revisiones de diseo y cdigo el nmero de
errores baj considerablemente, la tendencia que se advierte, es que, si se integraran
revisiones personales adicionales (check list) que permitan tener un menor nmero de
defectos, se obtendra una mayor calidad en los programas.
Grfica del total de defectos por programa y por KLOC.
26

4. Cmo se comparan sus tasas de defectos removidos (en defectos

eliminados/KLOC) con la revisin de diseo, la revisin de cdigo, la compilacin y las
pruebas?
En la primera mitad del curso todos los errores eran captados por las fases de compilacin y
pruebas, pero en la segunda mitad del curso ya introducidas las revisiones de diseo y
cdigo fueron reduciendo el nmero de errores que llegaban a compilacin y pruebas, esto
se nota claramente en la tabla Tasa de defectos eliminados en las fases de revisin de
diseo, revisin de cdigo, codificacin y pruebas, si se hubieran metido estas revisiones
desde un inicio las revisiones de diseo y cdigo tendran la mayor tasa de defectos
eliminados.
Fase
Nmero de defectos
Tasa de defectos eliminados
eliminados
(%)
DLDR
5
7.0%
CR
11
15.5%
COMPILE
31
43.7%
TEST
24
33.8%
TOTAL
71
100.0
Tasa de defectos eliminados en las fases de revisin de diseo, revisin de cdigo,
codificacin y pruebas.
5. Cules son sus influencias de defectos removidos por revisin de diseo, revisin
de cdigo y compilacin contra pruebas unitarias?
Las Pruebas Unitarias se realizan despus de las revisiones de diseo y cdigo y de la fase
de compilacin, por lo tanto el nmero de defectos encontrados y eliminados en esta fase es
mucho menor que en las fases anteriores a esta, esto debido a que las revisiones de diseo
y cdigo y la compilacin ya eliminaron la mayor parte de los errores.
6. Cules son sus tasas de revisin (en LOC revisadas/hora) para revisiones de
diseo y de cdigo?
En la siguiente figura llamada LOCS revisadas por hora en revisiones de diseo de cdigo
se muestra la tendencia a ir aumentando el nmero de LOC`s revisadas por hora tanto en la
revisin de diseo como en la de cdigo.
27

LOCS revisadas por hora en revisiones de diseo de cdigo.

En la siguiente tabla se muestra numricamente las tasas de revisin para diseo y cdigo.
En las revisiones por separado la tasa est en un promedio de 261 LOC`s revisadas por hora
para diseo y para cdigo 267 LOCs por hora, pero tomndolas juntas se cuenta con una
revisin promedio de 130 LOC`s revisadas por hora.
Programa
Tasa de revisin de
Tasa de revisin de
Tasa para ambas
diseo (LOC
cdigo (LOC
revisiones (LOC
revisadas/hora)
revisadas/hora)
revisadas/hora)
7
231.4
237.1
115.7
8
246
246
117.1
9
230
235.9
115.3
10
335.4
346.8
170.5
Tasa de revisin (en LOC revisadas por/hora para revisiones de diseo y cdigo).
8. Hay una relacin entre el Yield y el A/FR para los programas del 7 al 10?
La relacin que hay entre el Yield y el A/FR de las tareas en la segunda parte del curso
estuvieron muy relacionadas pues se refiere a la grfica siguiente se puede observar que
cuando el AF/R aumentaba tambin lo hacia el Yield y viceversa.
28

Grficas de yield y AF/R de las tareas 7A a la 10A

En la grfica anterior se observa que el yield siempre crece a excepcin de la tarea 9, el
promedio del yield para la segunda mitad del curso fue de 76.785%, esto indica que una gran
parte de los defectos se fueron eliminando antes de llegar a la fase de desarrollo. El AF/R en
la grfica representa una tendencia creciente, eso significa que como los valores de A/FR
siempre fueron mayores a 1, el tiempo dedicado a las revisiones tanto de diseo como de
cdigo fue superior a los tiempos de compilacin y pruebas.
9. Cmo se puede hacer el proceso ms efectivo y eficiente?
Realizar pruebas de escritorio despus de la fase de revisin de diseo para eliminar los
errores de pruebas que se pudieran introducir. El tiempo en el diseo aumentara, pero eso
beneficiara al tiempo de pruebas y calidad del programa.
10. Basados en los datos histricos Cules son los objetivos de calidad?
a) Obtener una tasa de defectos menor a 20 defectos/KLOC. b) Reducir el nmero de los
errores ms comunes. c) Alcanzar un yield promedio del 85%.
11. Cmo se puede cambiar el proceso para llegar a esos objetivos?
Para mejorar la tasa de defectos, en estos momentos es de 29 defectos/KLOC, es necesario
dedicar ms tiempo a entender los requerimientos del programa pues es lo que ha dado
como resultado el tener defectos muy difciles de resolver. Para reducir el nmero de
defectos comunes es necesario agregar validaciones al checklist y dedicar ms tiempo
cuando se aplique, pues por aplicarlo rpido no se eliminaron defectos detectables. El yield
actual es de 76.785%, para alcanzar un yield de 85% es necesario que se use con ms
eficiencia el estndar de diseo, parte de esto es incluir documentacin entre el cdigo para
29

que pueda interpretarse fcilmente. Para lograr los objetivos es necesario integrar nuevos
checklist que permitan reducir errores y tiempos al solucionar los que se identifiquen.
2.2.3. Elaborar plan de riesgos

En este tema se explicar lo correspondiente a los riesgos que se presentan en un proyecto
de software y de qu manera se deben tratar los problemas que pueden ocasionar para lo
cual debe se debe generar y examinar un plan de riesgos que ayudar al equipo a definir y
evaluar los riesgos del proyecto. Entenders la importancia que tiene gestionar los riesgos, y
las actividades que se deben realizar en plan de riesgos.
Primeramente se explicar qu se entiende como riesgo, un riesgo es una medida de la
probabilidad y gravedad de los efectos adversos (Lawrence, 1976). Un riesgo es algo que
puede o no llegar a suceder. Cuando se est seguro de que un evento se llegar a producir
esto no es un riesgo ya que se sabe que ese evento se va a presentar en algn momento
por lo cual se dice que es un evento de certidumbre (Humphrey, 2006).
El surgimiento de los riesgos tiene relacin con la incertidumbre que rodea a las decisiones y
los resultados del proyecto. Cuando se presenta la incertidumbre en la toma de decisiones
se est presentando un elemento de riesgo que puede llevar al no cumplimiento de los
requerimientos del cliente.
La incertidumbre acarrea complicaciones a la planeacin y ejecucin del proyecto,
lamentablemente esto es una realidad que es inevitable, es por eso que el uso de una
adecuada toma de decisiones requiere que siempre se considere la incertidumbre y que de
tal manera se evalen los posibles impactos que llegue a tener.
Un plan de riesgos es una serie de mtodos para poder complementar la toma de decisiones
bajo un ambiente de incertidumbre que se da a travs de la identificacin, anlisis, respuesta
y seguimiento de las situaciones de incertidumbre, las cuales puede llegar a afectar o
cambiar lo planeado.
Es de gran importancia generar un plan de riesgo ya que si se prevn los riesgos y se toman
las decisiones apropiadas con anticipacin, existe una alta posibilidad para poder evitar los
riesgos y problemas en el proyecto.
Otro aspecto importante es el costo de la recuperacin de un riesgo en la mayora de los
casos en que este se presente es ms alto de lo que hubiera costado aplicar las medidas
para evitar los riesgos. Es por esta razn que la prevencin de los riesgos y la toma de
decisiones acertada para poder evitarlos, brindar el ahorro de tiempo y esfuerzo.
30

Finalmente otro aspecto importante que se toma en cuenta para realizar la planeacin de los
riesgos es que en la mayora de los casos los problemas que llegaran a presentarse se
pueden conocer con suficiente anticipacin.
Dentro del plan de riesgo TSP contempla cinco directrices bsicas (Humphrey, 2006):
1.
2.
3.
4.
5.
Aprender de los errores del pasado.

Todos los equipos deben gestionar los riesgos.
Empoderar a los miembros del equipo para gestionar los riesgos.
Cada riesgo se debe asignar un propietario.
Revisar peridicamente los riesgos.
Aprender de los errores del pasado: Una gran mayora de los riesgos son conocidos, por
lo cual son pocos los errores nuevos que se llegan a presentar, al conocer los problemas
ms comunes que se presentaron en los proyectos pasados los equipos pueden determinar
los problemas ms comunes que se pueden presentar para los futuros proyectos.
Todos los equipos deben gestionar los riesgos: Esto se refiere a que todos los
participantes que trabajan en el proyecto son los que estn ms al tanto de los riesgos que
se pueden presentar es por esta razn que los equipos de trabajo pueden anticipar de una
manera ms fcil los problemas y de igual manera solucionarlos cuando an se puedan
prevenir.
Empoderar a los miembros del equipo para gestionar los riesgos: Quiere decir que los
participantes que estn directamente relacionados con el plan de riesgos deben de ser
tratados como si fueran parte de la gestin del sistema esto ayudar a tener una mejor
cooperacin y participacin de ellos. Empoderar a los miembros del equipo es darles cierta
responsabilidad para que tomen las decisiones adecuadas para poder dale seguimiento y
solucin a un riesgo pero estos solamente se harn a personas que estn involucradas en el
desarrollo del proyecto.
A cada riesgo significativo se debe asignar un propietario: Cuando se identifica un
riesgo significativo este tiene que asignarse a un responsable con esto se lograr que la
cobertura del riesgo sea la ms adecuada y que al darle seguimiento se tomen las medidas
necesarias para mitigar y corregir el riesgo para evitar futuros problemas. A manera de
ejemplo si se encontr un riesgo relacionado con el entorno de desarrollo y programacin el
responsable de darle seguimiento ser el Programador.
Revisar peridicamente los riesgos: Esto se debe de llevar acabo despus de que el
equipo identific los riesgos de ms importancia para as darles el seguimiento adecuado y
asignar al responsable que se encargara de hacer una revisin peridica junto con el equipo
esto depender de la importancia del riesgo y sus consecuencias.
Para la administracin de los riesgos se deben realizar las siguientes acciones:
31

1.
2.
3.
4.
5.
Identificar los riesgos

Analizar los riesgos
Elaborar planes de contingencia
Controlar el estado de los riesgos
Analizar los resultados y aprender de ellos.
Identificar los riesgos. En la identificacin de los riesgos se recuperan todas las

inquietudes y preocupaciones que estn ligadas con la elaboracin del proyecto, para esto
cada miembro del equipo hacen aportaciones haciendo mencin de los riegos que ellos
consideran que se puedan presentar en el desarrollo del proyecto. Para poder identificar los
riesgos lo miembros del equipo traban en conjunto mediante reuniones en las culs se
genera una lluvia de ideas de cada participante que expondr los posibles riegos que
considere puedan presentarse durante el desarrollo del proyecto.
A continuacin se muestra un ejemplo de una tabla de identificacin de riesgos de un
sistema en web en el cual se evalan los riesgos en cuanto a la seguridad.
Tabla de Identificacin de Riesgos. (Romero, 2013)
Seguridad
ID
Tipo
Interno Externo
R18MS
R19MS
R20MS
X
X
X
Descripcin del Riesgo
Posibles Consecuencias
Ataques contra contraseas de

Usuarios.
Des encriptacin de informacin
Vulnerabilidad del antivirus
Prdida de acceso a
Informacin.
Copia de datos
Inestabilidad en el servicio.
R21MS
Vulnerabilidad en los puertos
Prdida de servicios
R22MS
Prdida de consistencia.
R23MS
Ataques de SQL
a la base de
Datos.
Vulnerabilidad en el Firewalls
R24MS
R25MS
X
X
Vulnerabilidad en el servidor
Robo de conexin WI-FI
R26MS
R27MS
Vulnerabilidad
de certificados
digitales
Vulnerabilidad del acache ARP
Contaminacin por virus

informticos.
Robo de informacin,
Prdida de calidad en el
servidor.
Prdida de datos.
Retraso de servicios.
En la tabla anterior de construye con una serie de elementos que a continuacin se

describen:
32

ID: El ID este se utiliza para darle una clave con la cual se identificar el riego en las
siguientes tablas para su control y seguimiento.
Tipo: Este debe de ser evaluado y clasificado por los involucrados en el desarrollo
del proyecto, este pude ser interno o externo dependiendo el rea de afectacin que
pueda provocar el riesgo. Ejemplo: si es un riego se presenta en los estndares,
financiamiento, gestin del alcance, integracin del equipo etc., entonces se dice que
es un riesgo de tipo interno, pero si se presenta en cuanto a los clientes,
proveedores, mercado etc., es un riesgo de tipo externo.
Descripcin del riego: Se explica a detalle las caractersticas del riesgo.
Posibles consecuencias: Se describe la forma negativa en que pude llegar a afectar
el riesgo al proyecto.
Analizar los riesgos. Cuando se tienen identificados los riesgos se debe de realizar un
anlisis cualitativo de los riesgos en cual se deben de priorizar los riegos ms significativos,
esto en base a lo siguiente:
Probabilidad: Se refiere a la probabilidad de que se presente el riesgo esta puede

ser 1 a 100 porcentual que es el grado de probabilidad de que ocurra.
Impacto: El efecto que tendr el riesgo si se llegara a presentar, que de igual manera
se clasifica de 1 a 100 porcentual.
Para poder clasificar los eventos y la magnitud se utiliza la escala de 1 a 100 porcentual,
pero para poder realizar el clculo se utiliza 0.10 contemplando cuando el riesgo es de bajo
impacto y 1.0 cuando es de mayor impacto teniendo en cuenta que, por ejemplo, si el valor
en escala porcentual es de 90% este ser 0.90 para poder realizar la operacin. La magnitud
se obtiene del resultado de la multiplicacin de la probabilidad y del impacto que tendr el
riesgo en el proyecto. Ejemplo:
0.50 x 0.90 =0.45
Finalmente para poder representar el resultado obtenido se utiliza una matriz cualitativa del
riesgo que contiene la probabilidad y la magnitud del impacto, misma que se observars a
continuacin.
Matriz cualitativa de riesgo.
Probabilidad
0.10
Impacto
0.35 0.50 0.80 1.00
Escala de prioridad de eventos de riesgo

Riesgo bajo
Riesgo medio
Riesgo alto
33

0.90
0.70
0.50
0.30
0.10
0.09
0.07
0.05
0.03
0.0.1
0.32
0.25
0.18
0.11
0.04
0.45
0.35
0.25
0.15
0.05
0.72
0.56
0.40
0.24
0.08
0.90
0.70
0.50
0.30
0.10
En la siguiente tabla se muestra un ejemplo de anlisis de riesgo.
ID
18MS
Tabla de anlisis del riesgo y estrategias

Anlisis del riesgo
Magnitud:
Alta
Descripcin
Las cuentas de usuarios pertenecientes a un sistema Microsoft Windows
estn guardados en pares de datos, es decir, datos que hacen referencia a
sus respectivas contraseas.
Impacto
En la seguridad ya que otras personas podran adquirir los privilegios de
administrador y cambiar ciertas funciones.
Estrategia para tratar el riesgo:
Establecer mtodos de autentificacin como: NTL
Sokerberos.
Elaborar Planes de Contingencia. Se entiende por plan de contingencia al conjunto de

procedimientos alternativos a la operativa normal de cada empresa, cuya finalidad es la de
permitir el funcionamiento de sta, aun cuando alguna de sus funciones deje de hacerlo por
culpa de algn incidente tanto interno como ajeno a la organizacin (Castillo, 2013). Se
elabora con la finalidad de disminuir significativamente la ocurrencia de los riesgos, el cual
contiene recomendaciones para reducir las amenazas e incrementar las oportunidades
dentro de los objetivos del proyecto.
Controlar el estado de los riesgos. Dentro del control de los riesgos se implementan los
planes de respuesta de los riesgos que se identificaron.
34

Analizar los resultados y aprender de ellos. Los resultados de las observaciones en

proyecto pasados sirven para poder aprender de estos y as estimar y prever la presencia de
los riesgos. Para llevar un anlisis y gestin de los riegos se debe generar una matriz de
riegos la cual se aplicara en las reuniones con los participantes en el desarrollo del proyecto
para poder darle el seguimiento necesario.
La utilizacin de un plan de riesgos es muy importante ya que ayuda al equipo identificar los
riesgos potenciales dentro del proyecto, en la mayora de los casos muchos de los riesgos
pueden ser evitados lo que permitir reducir problemas en el proyecto.
Actividad 2. Plan del proyecto

En esta actividad generars el plan del proyecto con base en un problema planteado por tu
Facilitador (a). Realiza los siguientes pasos:
1. Identifica en el problema planteado por el Facilitador (a) los elementos del plan
del proyecto.
2. Elabora el plan del proyecto y el anlisis de riesgos.

3. Redacta tus conclusiones acerca de los elementos que integran el plan del
proyecto e identifica cules son los riesgos que podran afectar el desarrollo.
4. Guarda la actividad con el nombre DDSE_U2_A2_XXYZ. Sustituye las XX por
las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por
tu segundo apellido.
5. Enva tu actividad al facilitador mediante la herramienta Tareas.
Autoevaluacin
35

El propsito de esta actividad es realizar un anlisis del avance que has tenido para
detectar las reas de oportunidad respecto al estudio de la primera unidad.
Para realizar la Autoevaluacin, ingresa al listado de actividades en el aula.
Evidencia de aprendizaje. Generacin del plan de calidad y de riesgos
Como evidencia de aprendizaje realizars un plan de calidad con las mtricas del proyecto
global y el plan de riesgos identificando los elementos que puedan afectar a un proyecto.
Para ello, tu Facilitador(a) te enviar un problema ejemplo previamente. Tras recibirlo:
1. Identifica los elementos del plan de calidad y del plan de riesgos en el ejemplo de
proyecto de desarrollo de software.
2. Indica cules elementos corresponden a un plan de calidad y cules de ellos
corresponden a un plan de riesgos y cmo se relacionan.
3. Argumenta la explicacin de cada uno de los elementos identificados en el
problema.
4. Guarda la actividad con el nombre DDSE_U2_EA_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu
segundo apellido.
5. Enva tu actividad al facilitador mediante el Portafolio de evidencias.
Nota: para integrar los datos correspondientes a algunos de los elementos del plan de
calidad y de riesgos, recurre a los contenidos de la Unidad 2.
Cierre de la unidad
36

Dentro del TSP para poder formar los equipos de trabajo es primordial tener cuenta que para
formar un equipo de trabajo deben existir habilidades, actitud y aptitud por parte de los
integrantes del esquipo as como tener la capacidad para realizar las actividades que van a
desempear dentro del proyecto estando siempre comprometidos con los objetivos
planeados del proyecto bajo una estricta disciplina de trabajo.
Para poder ejecutar el trabajo en los miembros del equipo deben de tener claro el rol que
desempearn en el proyecto as como las tareas que realizarn, y que estn relacionadas
con el rol que le fue asignado. El lder de proyecto tiene la responsabilidad de motivar a los
miembros del equipo para que puedan desempear sus tareas de una manera adecuada.
La importancia de genera un plan de proyecto es fundamental para poder determinar lo que
se va a hacer y hasta dnde se quiere llegar, as como llevar un control de las actividades
que se realizarn para asegurar el cumplimiento de cada una de ellas para poder llegar a la
culminacin del proyecto. De igual manera la planeacin de calidad dar la evitar retrasos
en el proyecto por la presencia de errores de codificacin, por lo que se garantizar la
calidad del proyecto. Otra actividad que es de suma importancia es la generacin del plan de
riesgos, este evitar y mitigar los posibles riesgos que se pueden presentar a lo largo del
desarrollo del proyecto y que puedan llevar al no cumplimiento de los objetivos planteados.
Para saber ms
En esta pgina encontrars informacin diversa acerca de las herramientas de medicin de
la calidad del desarrollo de software, entre ellas TSP, as como diversos artculos y
documentos acerca de esta metodologa.
Software Engineering Institute Carnegie Mellon (2013). Pittsburgh:
https://www.sei.cmu.edu/library/abstracts/books/201731134.cfm Fecha de consulta: 11 de
junio del 2013
Fuentes de consulta
Castillo, C. Q. (2013). Proyecto plan de contingencia. [En lnea]:

http://es.scribd.com/doc/33729961/Proyecto-4-Plan-de-Contingencia
Colomo Palacios, Ricardo, Paniagua M., et al. (2011). Team Software Process.
Madrid, Espaa: Universidad Carlos III de Madrid. Recuperado de:
37

http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-de-informacioncorporativos/material/TSP.pdf/view
Fecha de consulta 11 de junio del 2013.
Gmez de Silva Garza, A. (2008). Introduccin a la Computacin. Mxico, D.F:

Cenage Learning Editores.
Humphrey, W. S. (1999). Introduction to the Team Software Process. Massachusetts:

Addison Wesley Professional.
Humphrey, W. S. (2006). TSP(SM) Coaching Development Teams. Massachusetts:

Addison-Wesley Professional.
Lawrence, W. W. (1976). Science and the Determination of Safety. Los Altos, CA:
William Kaufman.
Cano Hernndez, (2009). Desarrollo de Sistemas con PSP, TSP y UML. Mxico, D.F:
UAM. Recuperado de: http://148.206.53.231/UAMI14384.pdf
Fecha de consulta: Julio del 2013.
Piattini Velthuis, M. (2011). Calidad de Sistemas de informacin. Mxico, D.F.: Alfa

Omega ra-ma.
Queensland, T. U. (2010). CSSE3002 The Software Process. Lecture 14: The Team
Software Process. Queensland, Australia: School of Information Technology and
Electrical Engineering. Recuperado
de:http://itee.uq.edu.au/~csse3002/Lectures/Lect14.pdf
Fecha de consulta: 11 de junio del 2013.
RAE (Real Academia Espaola), 2013. Implementacin. Recuperado de:

http://lema.rae.es/drae/?val=equipo
Fecha de consulta: 11 de junio del 2013.
Rodrguez, J. R.,Coord. (2007). Gestin de proyectos informticos: mtodos,

herramientas y casos. Barcelona: Editorial UOC.
Fuente del esquema de sistemas de gestin:
Cybertesis (2009) Gerencia de proyectos. Recuperado de:

http://cybertesis.upc.edu.pe/upc/2009/molina_np/xml/ressources/fig003a.jpg
Fecha de consulta: 10 de julio del 2013.
38

Unidad 2. Implementación de TSP

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Unidad 2. Implementación de TSP

Загружено:

Авторское право:

Доступные форматы

Desarrollo de Software en Equipo TSP

Unidad 2. Implementacin de TSP

Unidad 2. Implementacin de TSP

Universidad Abierta y a Distancia de Mxico

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

2.2.3 Elaborar Plan de Riesgos ...................................................................................... 30

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Unidad 2. Implementacin de TSP

Identificars los componentes de la metodologa Team Software Process (TSP) de

2.1. Formar Equipos de Trabajo

Desarrollo de Software en Equipo TSP

establecimiento de un equipo de trabajo se lleva a cabo en la fase de lanzamiento, para que

Los principales elementos para la formacin del equipo de trabajo se muestran en el

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Miembros del equipo

Elementos necesarios para la formacin del equipo (Humphrey, 1999).

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

2.1.1. Documentar propsitos, objetivos y roles del equipo

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

en la plantilla se va a ver reflejado lo que se desea alcanzar cuando el proyecto llegue a su

NOMBRE DEL RESPONSABLE

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

2.1.2 Planear y ejecutar el lanzamiento del proyecto

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

En la columna estatus se pude palomear, pero lo ms correcto, es poner todos en

Crear los equipos en el primer ciclo de desarrollo

Todos los miembros del equipo deben completar el curso de PSP

Con esta plantilla se inicia el proyecto en equipo

Qu se espera que los miembros el equipo logren

Cmo ser evaluado y calificado su trabajo

Principios bsicos del trabajo en equipo

Informacin necesaria para la asignacin adecuada

Roles del equipo, responsabilidades y aptitudes

Los objetivos crticos que deben ser satisfechos.

Los objetivos deseables y opcionales.

Los criterios para evaluar un producto terminado.

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Por qu se necesitan los objetivos y metas del equipo.

El propsito de las juntas de equipo, fechas y reportes.

Datos requeridos semanalmente

Se discuten los roles de los miembros del equipo.

Se discuten y se acuerdan los objetivos del ciclo 1.

Se establecen los tiempos de las reuniones semanales.

Se especifican y se acuerdan los tiempos semanales de todos

Los datos requeridos por cada miembro del equipo

Los reportes que sern generados y entregados al equipo de

Establecer los tiempos de las juntas.

Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software

Desarrollo de Software en Equipo TSP

Explicar brevemente el tema trabajo en equipo. Este tema lo expondr la persona

Informacin necesaria para la asignacin adecuada de cada integrante al su

El objetivo principal del proyecto de desarrollo de software, que generalmente