Beruflich Dokumente
Kultur Dokumente
Programa de la asignatura:
Desarrollo de Software en Equipo TSP
8 Cuatrimestre
Clave:
150930934
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
Propsitos
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.
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.
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
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.
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.
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
Criterios
de entrada
General
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
El proceso de TSP
El instructor explica los criterios para hacer la asignacin de equipos
10
equipo
Reuniones del
equipo
La primera
reunin del equipo
Datos requeridos
Inicia 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:
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
Paso 2. En esta fila, se expone a los asistentes al curso la forma en que se realizar la
asignacin de los equipos
Paso 3. En esta fila se sealan los objetivos del producto a desarrollar y se deben exponer
los siguientes puntos:
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:
Ciencias Exactas, Ingeniera y Tecnologa | Desarrollo de Software
12
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
15
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.
17
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
20
21
22
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%
23
Tipo
Tipo
Tipo
21
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
25
26
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
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
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.
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: 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.
Tipo
Interno Externo
R18MS
R19MS
R20MS
X
X
X
Posibles Consecuencias
Prdida de acceso a
Informacin.
Copia de datos
Inestabilidad en el servicio.
R21MS
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
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:
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.
Probabilidad
0.10
Impacto
0.35 0.50 0.80 1.00
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
ID
18MS
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.
34
*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.
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.
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.
*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 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
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.
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.
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.
38