Desarrollo de Sistema de Información utilizando el …148.206.53.84/tesiuami/UAMI16774.pdf ·...
-
Upload
nguyenkiet -
Category
Documents
-
view
221 -
download
0
Transcript of Desarrollo de Sistema de Información utilizando el …148.206.53.84/tesiuami/UAMI16774.pdf ·...
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
2
Desarrollo de Sistema de Información utilizando Personal Software Process (PSP) y Team Software Process (TSP)
PROYECTO TERMINAL
PROF. HUMBERTO CERVANTES MACEDA
GARCÍA CRUZ ELENA BEATRIZ
Matrícula: 206361684
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
3
Contenido INTRODUCCIÓN ................................................................................................................................... 5
PERSONAL SOFTWARE PROCESS (PSP) .............................................................................................. 6
Introducción ................................................................................................ 6
Desarrollo de prácticas utilizando PSP ........................................................ 8
PROYECTO PSP (Resultados) ............................................................................................................. 20
Análisis de la exactitud de la estimación del tamaño ............................... 20
Análisis de la exactitud de estimación del tiempo .................................... 22
Análisis de defectos de rendimiento ......................................................... 24
Análisis de calidad ..................................................................................... 30
TEAM SOFTWARE PROCESS (TSP) ..................................................................................................... 32
Introducción .............................................................................................. 32
El lanzamiento (Launch) ............................................................................ 36
Forma MTG ................................................................................................ 37
Junta 1 ....................................................................................................... 38
Junta 2 ....................................................................................................... 39
Junta 3 ....................................................................................................... 43
Junta 4 ....................................................................................................... 44
Junta 5 ....................................................................................................... 45
Junta 6 ....................................................................................................... 46
Junta 7 ....................................................................................................... 48
Junta 8 ....................................................................................................... 49
Junta 9 ....................................................................................................... 50
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
4
DESARROLLO DEL SISTEMA USANDO TSP ......................................................................................... 51
Implementación del sistema ..................................................................... 66
DOCUMENTACIÓN DEL SISTEMA ...................................................................................................... 69
Diagrama de componentes del sistema .................................................... 69
CONCLUSIONES ................................................................................................................................. 71
REFERENCIAS ..................................................................................................................................... 72
ANEXOS ............................................................................................................................................. 73
Anexo 1. Forma ROLE ................................................................................ 73
Anexo 2. Forma ROLEMX ........................................................................... 73
Anexo 3. Forma MTG ................................................................................. 75
Anexo 4. Guión WEEK ................................................................................ 76
Anexo 5. Cuadros de Avance ..................................................................... 78
Anexo 6. Historias de Usuario ................................................................... 82
Anexo 7. Datos importantes del dashboard .............................................. 85
Anexo 8. WBS ............................................................................................ 88
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
5
INTRODUCCIÓN
El software es ahora la clave del éxito de muchos de los sistemas basados en computadora. El
software marca la diferencia. Lo que diferencia una compañía de otra es la suficiencia, exactitud y
oportunidad de la información dada por el software.
La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y
técnicas que se utilizan en el desarrollo de los programas informáticos (software). Esta disciplina
trasciende la actividad de programación, que es el pilar fundamental a la hora de crear una
aplicación. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se
pueda desarrollar en un plazo determinado y con el presupuesto previsto. [1]
Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas,
predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto
software.
El PSP / TSP (Personal Software Process / Team Software Process) es un modelo que es utilizado
para aumentar la calidad de los productos de software a través de un equipo disciplinado y auto
dirigido. A diferencia de otros modelos, el PSP se implementa a nivel personal, para después
integrase las actividades en el equipo de trabajo TSP. [2]
Este proyecto se llevó a cabo en dos etapas: La primera etapa consistió en capacitar a los
integrantes del equipo en PSP (Personal Software Process), en esta etapa cada integrante trabajó
de forma individual, sus tareas fueron llevadas a cabo siguiendo un proceso y contabilizando
tiempos. La segunda etapa consistió en capacitar al equipo en TSP (Team Software Process), en
esta etapa se trabajó en equipo y cada integrante llevó a cabo sus tareas utilizando PSP.
Los integrantes del equipo fueron:
Alvarado Suárez José Williams Beltrán Sánchez Jesica García Cruz Elena Beatriz García López Jorge Alberto Salazar Suárez Marco Fabián Zamora Ramos Diego Armando
El objetivo principal de este proyecto fue implementar un sistema de información utilizando los
procesos TSP y PSP. Donde el sistema fue desarrollado utilizando Java J2EE y los frameworks
Hibernate, Spring y JSF, basándose en el Modelo Vista Controlador (MVC).
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
6
PERSONAL SOFTWARE PROCESS (PSP)
Introducción
Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que se realizan o
suceden (alternativa o simultáneamente) bajo ciertas circunstancias con un fin determinado.
Conjunto de las diferentes fases o etapas sucesivas que tiene una acción o un fenómeno complejo.
Este concepto describe la acción de avanzar, al paso del tiempo y al conjunto de etapas
sucesivas advertidas en un fenómeno natural, o necesarias para concretar una operación artificial.
El Personal Software Process, conocido por sus siglas como PSP, es una metodología de reciente
creación, proveniente del Instituto de Ingeniería del Software (SEI). PSP es una alternativa dirigida
a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software.
Considerando aspectos como la planeación, calidad, estimación de costos y productividad, PSP es
una metodología que vale la pena revisar cuando el ingeniero de software está interesado en
aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo
individual.
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso
de desarrollo de un producto de software, están puntualmente definidas en un conjunto de
documentos conocidos como scripts. La calidad en PSP, es un aspecto fuertemente relacionado
con la cantidad de defectos que el producto de software contiene. [3]
El diseño de PSP se basa en los siguientes principios de planeación y de calidad:
Cada ingeniero es esencialmente diferente; para ser más precisos, los ingenieros deben
planear su trabajo y basar sus planes en sus propios datos personales.
Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente
procesos bien definidos y medidos.
Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente
comprometidos con la calidad de sus productos.
Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en
las etapas subsecuentes.
Es más eficiente prevenir defectos que encontrarlos y arreglarlos.
La manera correcta de hacer las cosas es siempre la manera más rápida y más barata de hacer
un trabajo.
El PSP define actividades del marco de trabajo:
1. PLANEACIÓN.
2. DISEÑO
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
7
3. CODIFICACIÓN
4. COMPILACIÓN
5. PRUEBAS
6. POSTMORTEM
Niveles de PSP
Medición personal (PSP0, PSP0.1): Su objetivo es proveer una hoja de trabajo para recolectar
datos iniciales de proceso.
Planeación personal (PSP1, PSP1.1): PSP1 adiciona la estimación de tamaño y de recursos,
además de un reporte de pruebas. PSP1.1 nos proporciona formatos de planeación de tareas y
calendario.
Calidad personal (PSP2, PSP2.1): PSP2 se da la prevención de defectos mediante la administración
de los errores. Listas para revisiones de diseño y de código. PSP2.1 especificaciones de diseño a
nivel individual.
Proceso personal cíclico (PSP3): Proceso lineal para construir programas pequeños. Introduce a
métodos individuales encaminados a proyectos de gran tamaño pero sin introducirnos a
problemas de comunicación y coordinación (se hará en TSP). [4]
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
8
Desarrollo de prácticas utilizando PSP
En la primera parte del proyecto se realizaron prácticas para poder aprender cómo llevar a cabo el
Personal Software Process, en cada práctica se nos proporcionaba un documento con la
especificación del programa que debíamos implementar, y de las pruebas que teníamos que
realizar, teníamos la oportunidad de elegir el lenguaje de programación que emplearíamos. A
continuación se muestra un reporte, que describe los resultados obtenidos de una de las prácticas,
cabe mencionar que después de cada práctica se entregaba un reporte de este tipo:
ALUMNO: GARCÍA CRUZ ELENA BEATRIZ.
PSP. PROGRAMA 3.
Forma del Resumen del Plan de Proyecto PSP1
Figura 1.1. Se definieron las características del proyecto, el nombre del responsable , así como la fecha de inicio y fecha fin del mismo, y el lenguaje con el cuál sería desarrollado.
Figura 1.2. Se registró la estimación de tamaño y tiempo de proyecto, así como el tamaño y tiempo real del mismo, y la suma de tiempo y tamaño de todos los proyectos que se habían realizado.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
9
Figura 1.3. Se registró la estimación detallada del tamaño del programa, el tamaño actual y la suma del tamaño de todos los proyectos que se habían realizado.
Figura 1.4. Se registraron los tiempos de cada fase, la estimación y el tamaño real.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
10
Figura 1.5. Se realizó el registro de los defectos inyectados en cada fase (estimación, tamaño real y el total a la fecha)
Figura 1.6. Se realizó el registro de los defectos eliminados en cada fase (estimación, tamaño real y el total a la fecha)
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
11
A continuación se muestra el reporte de pruebas, en el cual se consideraron todos los posibles casos que se podían presentar en el programa, así como el resultado esperado, esto nos permitió saber si el programa cumplía con todas las especificaciones:
Reporte de Pruebas
Desarrollador Elena Beatriz García Cruz Fecha 19/Feb/2012
Proyecto T3 Regresión Lineal Programa P3
Número/Nombre de la Prueba 1er caso de Prueba
Objetivo de la Prueba Asegurar que calcula correctamente el programa
Descripción de la Prueba 1. Ejecutar Aplicacion.java
2. Proporcionar el nombre del archivo a usar prueba1.txt
3. Proporcionar la xk = 386
4. Presionar enter
5. Se despliegan resultados y Fin del programa
Condiciones de la Prueba El archivo existe y tiene los datos de la C1 y la C3 como los
Datos x, y.
Resultados Esperados Beta0 = -22.55; Beta1 = 1.7279; rx,y = 0.9545; r^2 = 0.911;
yk = 644.429
Resultados Reales KO Corrida 1: Beta0 = -22.5525; Beta1 = 1.7279; rxy = 4.9050 E-
8 ; r^2 = 2.4 E-15; yk=644.4293.
KO Corrida 2: Beta0 = -22.5525; Beta1 = 1.7279; rxy = NaN ; r^2
= NaN; yk=644.4293.
OK Corrida 3: Beta0 = -22.5525; Beta1 = 1.7279; rx,y = 0.9544;
r^2 = 0.9110; yk = 644.4293.
Número/Nombre de la Prueba 2do caso de Prueba
Objetivo de la Prueba Asegurar que calcula correctamente el programa
Descripción de la Prueba 1. Ejecutar Aplicación.java
2. Proporcionar el nombre del archivo a usar prueba2.txt
3. Proporcionar la xk = 386
4. Presionar enter.
5. Se despliegan resultados y Fin del programa
Condiciones de la Prueba El archivo existe y tiene los datos de la C1 y la C4 como los
Datos x, y.
Resultados Esperados Beta0 = -4.039; Beta1 = 0.1681; rx,y = 0.9333; r^2 = 0.8711;
yk = 60.858
Resultados Reales OK Corrida 3: Beta0 = -4.0388; Beta1 = 0.1681; rx, y = 0.9333;
r^2 = 0.8710; yk = 60.8580.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
12
Número/Nombre de la Prueba 3er caso de Prueba
Objetivo de la Prueba Asegurar que calcula correctamente el programa
Descripción de la Prueba 1. Ejecutar Aplicación.java
2. Proporcionar el nombre del archivo a usar prueba3.txt
3. Proporcionar la xk = 386
4. Presionar enter
5. Se despliegan resultados y Fin del programa
Condiciones de la Prueba El archivo existe y tiene los datos de la C2 y la C3 como los
Datos x, y.
Resultados Esperados Beta0 = -23.92 ; Beta1 = 1.4309; rx,y = 0.9631; r^2 = 0.9276;
yk = 528.4294
Resultados Reales OK Corrida 3: Beta0 = -23.9238; Beta1 = 1.4309; rx, y = 0.9631;
r^2 = 0.9275; yk = 528.4293.
Número/Nombre de la Prueba 4to caso de Prueba
Objetivo de la Prueba Asegurar que calcula correctamente el programa
Descripción de la Prueba 1. Ejecutar Aplicación.java
2. Proporcionar el nombre del archivo a usar prueba4.txt
3. Proporcionar la xk = 386
4. Seleccionar Continuar
5. Se despliegan resultados y Fin del programa
Condiciones de la Prueba El archivo existe y tiene los datos de la C2 y la C4 como los
Datos x, y.
Resultados Esperados Beta0 = -4.604 ; Beta1 = 0.1401; rx,y = 0.9480; r^2 = 0.8988;
yk = 49.4994
Resultados Reales OK Corrida 3: Beta0 = -4.6037; Beta1 = 0.1401; rx, y = 0.9631;
r^2 = 0.9275; yk = 49.4993.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
13
Número/Nombre de la
Prueba 5to caso de Prueba
Objetivo de la Prueba Comprobar lo que pasa cuando se introduce el nombre de un
archivo que no existe.
Descripción de la Prueba 1. Ejecutar Aplicación.java
2. Proporcionar el nombre del archivo a usar prueba.txt
3. Presionar enter
4. Se despliega el resultado y Fin del programa
Condiciones de la Prueba El archivo que se va utilizar no existe
Resultados Esperados Mensaje de error, y no se pueden obtener los valores de
La regresión lineal
Resultados Reales OK Corrida 1: Aparece un mensaje de error indicando que el
Sistema no puede encontrar el archivo especificado, y los
valores de las variables no se pudieron calcular.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
14
Este formato nos permitió identificar los problemas que se presentaron durante el desarrollo del programa y sugerir una solución, para que en los próximos programas se pudiera evitar repetir estos problemas:
Propuesta de Mejora de Proceso (PIP)
Desarrollador Elena Beatriz García Cruz Fecha 22-02-2012
Proyecto Programa 3
Proceso PSP Elementos
Número
de PIP
Descripción del Problema
1 Es difícil estimar los tamaños de los componentes a crear, y de las líneas a
modificar o eliminar, de los componentes base.
2 Aún es difícil identificar el tipo de defectos
Propuesta
Número
de PIP
Descripción de la Propuesta
1 Consultar el código que será reutilizado y analizar qué líneas serán
modificadas, eliminadas o agregadas.
2 Tener una lista con la mayor cantidad posible de ejemplos que nos
permitan identificar el tipo de defectos.
Notas y Comentarios
El proceso aún se me hace difícil, por la falta de costumbre.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
15
Plantilla de Estimación de Tamaño
Figura 1.7. Se realizó el registro de la estimación del tamaño de cada módulo así como sus tamaños reales, la estimación es detallada, ya que se consideró el número de LOC's base, agregados, eliminados y modificados.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
16
Hoja de cálculo PROBE
Figura 1.8. Este reporte nos permitió saber la productividad que teníamos, así como saber si estabamos subestimando o sobreestimando tamaños y tiempo de los programas.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
17
Bitácora de Registro de Tiempo
Figura 1.9. Esta bitácora nos permitió llevar un control de tiempo de cada fase, se registraron sólo los tiempos durante los cuales se estaban llevando a cabo las tareas.
Bitácora de Registro de Defectos
Figura 1.10. Esta bitácora nos permitió registrar los defectos de forma más detallada, ya que se indicó el tipo, la fase en la que fue inyectado, la fase en la que fue eliminado, el tiempo que tomó eliminarlo y una breve descripción del defecto.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
18
Aquí se llevaron a cabo las pruebas que se definieron anteriormente:
Resultados de las pruebas
Datos utilizados:
Programa
Número
Tamaño
Estimado de
Proxy
Tamaño Agregado
y Modificado
Planeado
Tamaño
Agregado y
Modificado Real
Tiempo Real de
Desarrollo
1 130 163 186 15.0
2 650 765 699 69.9
3 99 141 132 6.5
4 150 166 272 22.4
5 128 137 291 28.4
6 302 355 331 65.9
7 95 136 199 19.4
8 945 1206 1890 198.7
9 368 433 788 38.8
10 961 1130 1601 138.2
Prueba 1: Calcule los parámetros de regresión y coeficientes de correlación entre el tamaño estimado de
proxy y el tamaño agregado y modificado real de la Tabla 1. Calcule el tamaño agregado y modificado
planeado dado un tamaño estimado de proxy de = 386.
Prueba 2: Calcule los parámetros de regresión y coeficientes de correlación entre el tamaño estimado de
Proxy y el tiempo real de desarrollo de la Tabla 1. Calcule el tiempo estimado dado un tamaño estimado de
proxy = 386.
Prueba 3: Calcule los parámetros de regresión y los coeficientes de correlación entre el tamaño agregado y
modificado planeado y el tamaño agregado y modificado real de la Tabla 1. Calcule el tamaño agregado y
modificado planeado dado un tamaño estimado de proxy de = 386.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
19
Prueba 4: Calcule los parámetros de regresión y coeficientes de correlación entre el tamaño agregado y
modificado planeado y el tiempo real de desarrollo de la Tabla 1. Calcule el tiempo estimado dado un tamaño
estimado de proxy de = 386.
Prueba 5: Ejecutar el programa, e introducir el nombre de un archivo que no existe, y reportar el error que se
produce.
Después de realizar las pruebas, se realizó una comparación entre los valores esperados y los valores reales,
esto con el fin de saber si el programa funcionaba correctamente:
Resultados
esperados
Prueba Valores Esperados Valores Reales
0 1 yxr , 2r ky 0 1 yxr , 2r ky
Prueba 1 -22.55 1.7279 0.9545 0.9111 644.429 -22.5525 1.7279 0.9544 0.9110 644.4293
Prueba 2 -4.039 0.1681 0.9333 .8711 60.858 -4.0388 0.1681 0.9333 0.8710 60.8580
Prueba 3 -23.92 1.43097 .9631 .9276 528.4294 -23.9238 1.4309 0.9631 0.9275 528.4293
Prueba 4 -4.604 0.140164 .9480 .8988 49.4994 -4.6037 0.1401 0.9480 0.8987 49.4993
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
20
Al finalizar el curso de PSP, se realizó el siguiente reporte que contiene un análisis general de todos los
programas realizados, el análisis incluyó: estimación del tamaño, estimación del tiempo, de los defectos y de
la calidad.
PROYECTO PSP (Resultados)
Análisis de la exactitud de la estimación del tamaño
¿Qué tan frecuentemente estuvo mi tamaño real del programa dentro de mi intervalo
estadístico de predicción del 70%?
Proyecto/Tarea LOC Agregadas
Estimado LOC
Total
Program 1 0
Program 2 150 200
Program 3 128 259
Program 4 183 153
Program 5 132 116
Program 6 80 98
¿Tengo una tendencia a agregar/no considerar objetos completos?
Sólo en un programa, no se consideró un objeto completo, esto se debió a que un objeto realizaba
dos tareas, pero esto no es conveniente, pues de esta manera resulta más difícil poder reutilizar
objetos en un futuro, entonces para que el programa esté bien modularizado se agregó un objeto
más. Así logramos que se pueda reutilizar el código, más adelante.
¿Tengo una tendencia a juzgar equivocadamente el tamaño relativo de objetos?
Si, en la siguiente gráfica se puede observar, que el tamaño de los objetos es muy inestable, pero
hay dos programas en los cuales el error es más grande, podemos ver que en la tarea 3 se
subestimó el tamaño del programa, pero en la tarea 4 se sobreestimo el tamaño del programa,
estos son programas intermedios, en los programas finales, hubo una mejor estimación, el error
ha disminuido debido a que se tomaron en cuenta los datos históricos, para poder hacer una
estimación, a diferencia de las primeras estimaciones, en las cuales no teníamos datos históricos
que nos ayudarán a poder estimar los tamaños de los programas.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
21
¿Necesito calcular el rango de tamaño relativo usando mis datos de objeto históricos? ¿Puedo?
Sí, porque en los primeros programas había mucho error de estimación, debido a que no
contábamos con estimaciones anteriores, y la estimación se hacía en base a nuestro criterio, pero
esto no resultó tan efectivo. Pero lo que hice fue basarme en datos y aproximaciones anteriores,
para obtener una mejor estimación de tamaño.
Si puedo calcular el rango de tamaño relativo, ya que cuento con datos históricos con los que
puedo hacer un análisis del tamaño de cada nuevo programa.
Basado en mis datos históricos de exactitud de estimación de tamaño, ¿cuál es una meta de
estimación de tamaño realista para mí?
Una meta realista es seguir llevando a cabo el proceso PSP, ya que esto me ayudará a que en un
futuro mi error de estimación disminuya aún más, gracias a que cuento con los datos históricos
para poder hacer una mejor estimación cada vez.
¿Cómo puedo modificar mi proceso para cumplir esa meta?
Para cumplir la meta antes mencionada, tomaré en cuenta que los datos histórico son de gran
importancia, y que siempre que haga una nueva estimación, los debo tomar en cuenta. También
hay una dificultad cuando se trata de estimar el número de líneas base, nuevas, modificadas y
eliminadas. Si se logra cambiar esto habrá una mejor estimación.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
22
Análisis de la exactitud de estimación del tiempo
¿Mi productividad es estable? ¿Por qué si o por qué no?
No, en la gráfica se puede observar que en los primeros programas la productividad era más
inestable, pero en los últimos comenzó a estabilizarse un poco, debido a que se contaba con datos
de los primeros programas, y se esperaría que en futuros programas la productividad se estabilice,
debido a que ya tendríamos más experiencia y más datos históricos.
¿Cómo puedo estabilizar mi productividad?
Haciendo una mejor estimación de tamaño y tiempo, ya que ambas afectan a la productividad, y
esto sólo se puede lograr adquiriendo más experiencia con PSP, haciendo más programas,
siguiendo este proceso y utilizando los datos históricos para realizar las estimaciones.
¿Cuánto están mis estimados de tiempo afectados por la exactitud de mis estimados de
tamaño? (¿La regresión lineal me ayudaría?)
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
23
Podemos ver que los estimados de tiempo soy muy afectados por las malas estimaciones de
tamaño y que las gráficas son muy parecidas, esto nos indica que entre más grande sea el error de
estimación de tamaño, más grande será el error de estimación de tiempo.
Basado en mis datos históricos de exactitud de estimación de tiempo, ¿cuál es una meta de
estimación de tiempo realista para mí?
Debido a que hay una relación en la estimación de tiempo y en la estimación de tamaño, y si
realizo una mala estimación de tamaño, esto afectará al tiempo. La meta es realizar una mejor
estimación de tamaño, para obtener una mejor estimación de tiempo.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
24
¿Cómo puedo modificar mi proceso para cumplir esa meta?
Para realizar una mejor estimación de tamaño, hay que seguir el proceso PSP, y basarnos en los
datos históricos. También analizar con detalle los requerimientos para poder hacer un buen
diseño, y una buena estimación de cada módulo del sistema.
Análisis de defectos de rendimiento
¿Qué tipo de defectos introduzco durante el diseño y la codificación?
En la siguiente tabla podemos observar el tipo de errores que se han cometido, y la frecuencia con
que han ocurrido, podemos observar que el tipo de defectos que más se ha introducido son los de
función y sintaxis, así como de interfaz y asignación.
También podemos observar que en la fase de codificación es en la que se han inyectado más
defectos, y que los defectos de sintaxis han llegado hasta la fase de compilación. Y que hay ciertos
tipos de defectos que no se cometieron, como son de datos, de documentación, etc.
Número de inyectados Porcentaje de inyectados
Tipo de defecto Diseño Codificación Diseño Codificación
Assignment 0 12 0% 29%
Build, package 0 3 0% 7%
Checking 0 0 0% 0%
Data 0 0 0% 0%
Documentation 0 0 0% 0%
Environment 0 0 0% 0%
Function 4 9 80% 21%
Interface 0 6 0% 14%
Syntax 1 12 20% 29%
System 0 0 0% 0%
Total 5 42 100% 100%
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
25
¿Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados
en las revisiones, compilaciones y pruebas?
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
26
En base a las gráficas anteriores, podemos decir que los defectos se disminuyeron con las
revisiones. Ya que en los primeros programas no se realizaban revisiones, y esto provocaba que los
defectos no fueran encontrados a tiempo, ya sea del diseño o la compilación. Esto nos indica que
si seguimos realizando revisiones, podemos obtener menos defectos en compilación, y más aún en
pruebas, que son más costosos.
Y en las gráficas anteriores podemos ver que disminuyó considerablemente el número de defectos
encontrados en pruebas y en compilación, y esto nos ayuda a obtener programas de mayor
calidad. Podemos decir que si se siguen haciendo revisiones, los defectos encontrados en pruebas
y en compilación, seguirán disminuyendo.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
27
¿Qué tendencias son aparentes en los defectos totales por unidad de tamaño?
Lo que la figura nos muestra es que el número de defectos ha ido disminuyendo, esto se debe a
que se han hecho revisiones, tanto de diseño, como de código. Y esto es debido a que al principio
no se realizaban revisiones y esto ocasionaba que los defectos se fueran hasta compilación y
pruebas. Esto nos indica que cada vez se obtuvieron mejores programas con mayor calidad.
¿Cómo mis tasas de eliminación de defectos (defectos eliminados/hora) se comparan para la
revisión de diseño, revisión de código, compilación y pruebas?
En los primeros programas los errores se encontraban en compilación y pruebas, pero en lo
últimos cuando ya fueron introducidas las revisiones de diseño y de código fueron reduciendo el
número de errores que llegaban a compilación y pruebas, esto nos indica que si hubiéramos
introducido las revisiones desde el principio, hubiéramos podido obtener mejores resultados.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
28
¿Cuáles son mis tasas de revisión (tamaño revisado/hora) para la revisión de diseño y revisión
de código?
Esta gráfica nos muestra que las tasas de revisión del diseño y del código son muy similares, y que
ha ido aumentando el número de LOC’s revisadas por hora, tanto en las revisión de diseño, como
en la de código.
¿Cuáles son mis influencias de eliminación de defectos para la revisión de diseño, revisión de
código y compilación contra las pruebas unitarias?
Que han disminuido el número de errores encontrados en compilación y en pruebas, y esto a su
vez aumenta la calidad, ya que como he mencionado antes, los errores más costosos son los
encontrados en compilación, pero sobre todo en pruebas, entonces al tener pocos errores en
pruebas, se obtiene un producto de mayor calidad.
¿Hay alguna relación entre el rendimiento y la tasa de revisión (tamaño revisado/hora) para las
revisiones de diseño y código?
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
29
Si existe una relación entre el rendimiento y las revisiones, ya que como podemos observar en las
figuras, mientras se revisen más LOC’s por hora, el rendimiento aumentará.
¿Hay una relación entre el rendimiento y A/FR para los programas 5 al 8?
La relación que hay entre el Yield y el A/FR de las tareas es muy significativa, ya que podemos ver
que cuando el A/FR aumenta, también lo hace el Yield, y viceversa.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
30
Análisis de calidad
¿Cómo puedo juzgar la calidad de mi producto final de manera temprana en mi ciclo de
desarrollo?
La calidad de mi producto final fue buena, debido a que los datos históricos fueron de gran ayuda,
porque conforme fue avanzando el curso iba tomando la información obtenida de programas
anteriores. Pero considero que aún hay cosas que puedo mejor como la planeación de mi proceso.
¿Estoy encontrando mis defectos en las revisiones de diseño y código? ¿Por qué si o por qué
no?
Si, la mayoría de los defectos han sido encontrados en las revisiones, esto se logró, debido a que
tomé en cuenta, cuáles errores fueron los que se cometían con mayor frecuencia, de esta manera,
concentre más mi atención en el tipo de defectos más comúnmente cometidos.
¿Cómo puedo hacer más efectivo y eficiente mi proceso?
Realizando pruebas de escritorio, para disminuir la probabilidad de encontrar errores en pruebas
unitarias. Realizar las revisiones de diseño y codificación de manera estricta, esto se logrará
respetando los tiempos que se tengan estimados para dichas revisiones. Así aumentaría la
probabilidad de generar un producto de calidad.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
31
Basado en mis datos históricos, ¿cuáles son algunas metas de calidad realistas para mí?
Alcanzar un Yield promedio del 85%. Obtener una tasa de defectos menor a 20 defectos/KLOC. Reducir el número de los errores más comunes.
¿Cómo puedo cambiar mi proceso para cumplir esas metas?
En primer lugar puedo considerar incluir más checklist que me permitan reducir errores y tiempo
al solucionar los errores que identifique.
También es necesario dedicar más tiempo a entender los requerimientos del programa, para
poder disminuir la tasa de defectos.
Para reducir el número de defectos más comunes es necesario que agreguemos validaciones para
mi checklist y dedicar el tiempo necesario para realizar una buena revisión.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
32
TEAM SOFTWARE PROCESS (TSP)
Introducción
El Proceso de Software en Equipo (TSP por sus siglas en inglés), es una guía que ayuda a los
equipos que están desarrollando software. Con el TSP las organizaciones establecen prácticas de
ingeniería de una forma más madura y con una mejor disciplina, lo que conlleva a que se produzca
software seguro y fiable en tiempos cortos y a un menor costo. El TSP puede ser aplicado en
pequeñas y grandes organizaciones.
El TSP se compone de:
- Un proceso para construir el equipo (team building process), en el cual se especifican las
metas del equipo, el comité, las metas de cohesión y la estructuración del producto. Un
equipo de TSP puede estar formado por 3 o hasta 15 miembros más el líder del equipo.
- Un proceso de trabajo en equipo (team working process), enfocado en el proceso de
ingeniería y las practicas que serán utilizadas por el equipo para desarrollar el producto.
- Para que un equipo pueda utilizar el TSP, es necesario que cada integrante del mismo
tenga un conocimiento de los conceptos básicos de la ingeniería de software así como
también de los niveles de procesos que son estudiados en el PSP (Personal Software
Process).
El TSP da un seguimiento a los proyectos basándose en los procesos, prácticas y mediciones
utilizados en el PSP; ya que la planeación en equipo e individual facilitan dar este seguimiento de
una manera más precisa durante el desarrollo de los productos. [5]
Las responsabilidades de cada miembro del equipo son:
Recolectar los datos de su trabajo
La calidad del trabajo que produce
Mantener la comunicación con cada miembro del equipo
Monitorear continuamente su estado actual contra su plan
El TSP se compone de 4 fases que son:
Requerimientos
Diseño de alto nivel
Implementación
Pruebas
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
33
Flujo detallado del TSP
Un proyecto que está siendo desarrollado usando TSP, puede ser inicializado y/o finalizado en
cualquier fase.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
34
Solo requerimientos
Solo diseño de alto nivel
Desde los requerimientos hasta las pruebas de sistema
Cualquier combinación
Las estrategias de desarrollo que abarca el TSP son:
Desarrollo incremental
Desarrollo iterativo
Trabajo en conjunto
Construcción múltiple o cíclico
ROLES DE LOS MIEMBROS DEL EQUIPO
El TSP reparte las responsabilidades dentro del equipo en 8 roles definidos más el de un líder de
equipo, el cual no podrá tomar ninguno de los 8 roles restantes; esta repartición de roles se hace
para distribuir las tareas entre cada ingeniero y de esta manera definir las responsabilidades para
gestionar la manera en la que se trabajara durante el desarrollo del proyecto; cada miembro del
equipo escoge su rol durante el lanzamiento. Los roles son:
- Líder de equipo.- Dirige al equipo, presta asesoría a los miembros del equipo, es el encargado de
mantener al equipo unido para lo cual tiene que tener una buena comunicación con cada
miembro del equipo.
- Administrador de interfaz con el cliente.- Es el encargado de mantener la comunicación con el
cliente, informa al equipo los cambios en los requerimientos, así como el establecimiento y
mantenimiento de los mismos.
- Administrador de diseño.- Dirige y administra los cambios en el diseño de los componentes,
también se encarga de establecer y mantener los estándares de diseño.
- Administrador de proceso.- Se encarga de definir los procesos con los cuales se llevaran a cabo
las actividades, analiza estos procesos para descubrir posibles problemas que puedan tener estos
procesos.
- Administrador de calidad.- Mantiene un registro de la calidad con la que se está desarrollando el
producto, realizando un análisis de esta para que el producto final tenga una calidad alta.
- Administrador de planeación.- Administra las planeaciones del equipo, da seguimiento y
mantiene un registro del progreso que se esté teniendo.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
35
- Administrador de soporte.- Establece y configura las herramientas de soporte, se encarga de que
cada miembro del equipo cuente con todas las herramientas necesarias para desarrollar sus
tareas.
- Administrador de pruebas.- Se encarga de realizar la planeación de las pruebas de integración y
de sistema, el soporte y análisis de las mismas.
- Administrador de implementación.- Dirige y administra los cambios en la implementación,
también se encarga de establecer y mantener los estándares de la implementación. [6]
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
36
El lanzamiento (Launch)
El propósito que se persigue durante el lanzamiento, es el de producir el plan de trabajo que el
equipo seguirá, así como acordar con la dirección el seguimiento de dicho plan, otro de los
objetivos de esta parte del proceso es la de lograr la integración del equipo que estará trabajando
en el desarrollo del proyecto.
Para el lanzamiento se sigue el siguiente estándar:
En estas juntas de lanzamiento deben participar el líder y todos los miembros del equipo. En cada
junta hay roles, una agenda y se maneja un reporte de la misma.
Los roles de la junta consisten en un moderador, que es el encargado de encabezar la junta, un
crono metrista que se encarga de tomar los tiempos de cada tópico tratado en la junta y un
anotador, el cual se encarga de apuntar todas las decisiones importantes y acciones planeadas.
En total son 9 juntas las que se requieren para este lanzamiento.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
37
Forma MTG
Antes de comenzar con las juntas es importante describir un elemento fundamental de cada una
de estas, el formato MTG, que se encargó de recopilar los datos más importantes de cada junta y
el tiempo que se dedicó a tratar cada uno de los puntos relevantes de las juntas.
Antes de llenar el formato MTG, se hizo una lista de los temas a tratar en la junta y se hizo un
estimado del tiempo que tomaría abordar cada uno de los temas.
Después se eligió un anotador y un cronometrista, el anotador se encargó de llenar el formato
MTG, indicó la fecha y el lugar de la junta, el nombre y rol de cada uno de los participantes, así
como el nombre del mismo anotador y el tema o propósito de la junta. En otro apartado se
encargó de ir anotando los tiempos de inicio y fin de cada uno de los puntos tratados en la junta y
la persona que se encargó de abarcar dicho punto.
El cronometrista fue el encargado de tomar el tiempo que el equipo ocupó para abordar cada uno
de los temas que se establecieron para cada junta, esto se hizo con el objetivo de que se
respetaran los tiempos que se destinaron para abordar cada tema y así las juntas no se volvieran
tediosas e improductivas. El cronometrista, a su vez, tenía que informar al equipo el momento en
que el tiempo predestinado para cada tema hubiera concluido y en caso de que el equipo
considerara necesario que se necesitaba más tiempo se continuaba, en caso contrario se daba por
concluido el tema actual y se proseguía con el siguiente.
A continuación se muestra la forma MTG:
Nombre Fecha
Moderador Lugar
Fecha de la junta Hora Inicio: Hora Fin:
Tema/Propósito
Asistentes
Nombre Rol
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
38
Agenda
Tiempos (min.) Temas Líder de Presentación
Plan Inicio Fin
Decisiones, Acciones e Información Clave
Qué Quién Cuándo
VER DETALLES DE LLENADO DE FORMA MTG A continuación se lista una breve descripción de cada junta:
Junta 1
En esta junta el objetivo principal fue que se establecieran las metas que se deseaban alcanzar con
el producto a desarrollar; en la junta, el cliente planteó la necesidad que deseaba cubrir, el tiempo
en el que esperaría tener resultados que la cubrían y definió la forma en la que se consideraría al
proyecto como exitoso, así como los recursos y restricciones que se tenían para desarrollarlo. Los
integrantes del equipo debían estar atentos a lo que el cliente planteó, para que si se tenían dudas
se aclararan inmediatamente, y así evitar futuros conflictos. Esta junta ayudó al equipo para que
comenzara a definir las actividades que se realizarían para el desarrollo del producto.
En nuestro caso se estableció lo siguiente:
Se desea desarrollar un Sistema de Estimación y Análisis de Proyectos el cual será un sistema
moderno que además de realizar estimados, permitirá el análisis de datos proporcionados por el
usuario, así como los datos históricos del mismo. Finalmente, el sistema generará reportes que
permitirán realizar una estimación más precisa de los proyectos.
Durante la junta se hizo el llenado del formato correspondiente a la junta 1:
Nombre Jorge Alberto García López Fecha 2011/09/13
Moderador Luis Castro Lugar LIS
Fecha de la junta 24/04/12 Hora Inicio: Hora Fin:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
39
Tema/Propósito Junta 1 del Lanzamiento de TSP: Revisar las
necesidades de la dirección y comercialización para el proyecto
Asistentes
Nombre Rol
Elena Beatriz García Cruz
Diego Armando Zamora Ramos Anotador
Jorge Alberto García López Crono metrista
Marco Fabián Salazar Suarez
José Williams Alvarado Suarez
Jesica Beltrán Sánchez
Luis Castro
Alan García Zamora Equipo
Agenda
Tiempos (min.) Temas Líder de Presentación
Plan Inicio Fin
5 Agenda y proceso de la junta Coach de lanzamiento
30 Repaso del lanzamiento Coach de lanzamiento
25 Necesidades de negocio para el proyecto Dirección
25 El producto deseado Comercialización
5 Cierre de la junta y reporte Coach de lanzamiento
Junta 2
En esta junta se definieron las metas del equipo y se asignaron los roles que jugaría cada miembro
durante el desarrollo del producto. Para la definición de las metas de equipo se partió de las metas
establecidas por la dirección.
Los roles que se debían de cubrir son:
Interfaz con el cliente
Diseño
Implementación
Pruebas
Planeación
Proceso
Calidad
Soporte
DEFINICIÓN DE METAS DEL EQUIPO:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
40
Se plasmaron las metas de la dirección en el formato GOAL, y a partir de estas se obtuvieron las
metas del equipo. Después se planteó quién sería el responsable de dar seguimiento a estas
metas, así como la frecuencia con la que se daría el seguimiento de las mismas.
Metas de la dirección de TSP - Forma GOAL
Nombre Jorge Alberto García López Fecha 25/04/12
Proyecto TSP Lanzamiento/Fase Junta 2
Medidas Responsabilidad de Seguimiento Meta Meta Actual
Terminar el sistema en 3 meses. Desviación menor que 10% de fecha planeada.
AG
Entregar un producto de calidad. Densidad de defectos en pruebas de sistemas 5 def/ KLOC.
DZ
Entregar un producto funcional. Desviación menor que 40% de los requerimientos del sistema.
MS
Utilizar tecnologías modernas de desarrollo de software.
Usar 3 tecnologías (una para cada capa del sistema).
JA
Entregar un producto escalable. MS
Aplicar el control de versiones. 100% de los elementos del sistema dentro del repositorio.
JA
Aplicar el TSP para el desarrollo de las tareas del sistema.
Llevar a cabo al menos 11 juntas. AG
Establecer horarios de trabajo y respetarlos.
3 faltas como máximo, 15 minutos de tolerancia.
EG
Tener una buena comunicación en equipo y con los asesores.
EG
Aprender tecnologías de desarrollo modernas.
MS
Apoyo entre compañeros. EG
Reuniones para convivir como equipo. 1 reunión cada 15 días. EG
A partir de la tabla anterior, las metas que el equipo consideró en esta junta fueron:
METAS DEL EQUIPO
Responsable Meta Medida de la meta Quien Cuando
Equipo Seguir TSP EG Semanal
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
41
Equipo Cumplir con el tiempo efectivo de trabajo.
105 horas MS Semanal
Equipo Seguir las metas de calidad sugeridas por TSP.
Guía de Calidad DZ Semanal
Equipo Exactitud en la planeación. 20% de error de estimación.
AG Semanal
Equipo Buena comunicación entre los miembros del equipo
Sin discusiones personales.
EG Semanal
ASIGNACIÓN DE LOS ROLES QUE JUGARÁ CADA MIEMBRO DEL EQUIPO: Utilizando la forma ROLE, se realizó la asignación de los roles que cada miembro tendría, así como la asignación de un suplente para cada rol. Y se obtuvo lo siguiente: ROLES
Roles Miembro del Equipo
Team Leader Elena Beatriz García Cruz
Jorge Alberto García López
Customer Interface Manager Marco Fabián Salazar Suárez
José Williams Alvarado Suárez
Design Manager Marco Fabián Salazar Suárez
Jorge Alberto García López
Implementation Manager Jesica Beltrán Sánchez
Diego Armando Zamora Ramos
Planning Manager Alan García Zamora
Elena Beatriz García Cruz
Process Manager Alan García Zamora
Jesica Beltrán Sánchez
Quality Manager Diego Armando Zamora Ramos
Jesica Beltrán Sánchez
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
42
Support Manager José Williams Alvarado Suárez
Diego Armando Zamora Ramos
Test Manager Jorge Alberto García López
José Williams Alvarado Suárez
Ver forma ROLE
Al terminar esta junta, los resultados obtenidos fueron los siguientes:
Nombre Jorge Alberto García López Fecha 25/04/12
Moderador Luis Castro Lugar LIS
Fecha de la junta 25/04/12 Hora Inicio: 12:45 hrs. Hora Fin:
Tema/Propósito Junta 2 del Lanzamiento de TSP: Asignar los roles del equipo y establecer las metas
del proyecto
Asistentes
Nombre Rol
Elena Beatriz García Cruz Líder
Diego Armando Zamora Ramos Crono metrista
Jorge Alberto García López Anotador
Marco Fabián Salazar Suarez Equipo
José Williams Alvarado Suarez Equipo
Jesica Beltrán Sánchez Equipo
Luis Castro Coach
Alan García Zamora Equipo
Agenda
Tiempos (min.) Temas Líder de Presentación
Plan Inicio Fin
5 12:45 12:50 Agenda y proceso de la junta Coach de lanzamiento
20 12:57 13:00 Revisión de las metas de la dirección Líder del Equipo
45 13:00 13:30 Definición de metas implícitas Líder del Equipo
60 13:45 14:15 Establecimiento de las metas del equipo Líder del Equipo
50 15:43 16:09 Selección de los roles del equipo Coach de lanzamiento
25 16:09 16:11 Asignación de la responsabilidad de Líder del Equipo
16:11 16:15 seguimiento de las metas
5 16:15 Cierre de la junta y reporte Coach de lanzamiento
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
43
Junta 3
En esta junta el equipo definió la estrategia que seguiría para el desarrollo del producto, así como
el proceso que usarían; el equipo elaboró un diseño primario y se estimó el posible tamaño que
tendría el producto final, con lo cual también se estimó el tiempo que se tomaría el equipo para
desarrollar el producto.
El diseño conceptual que se generó se ve a continuación:
Después de esto se realizó una tabla con el estimado del tamaño de cada uno de los componentes,
donde cada componente corresponde a una capa del sistema, es decir: Capa de Interfaz, Capa de
Negocio y Capa de Datos. Para cada componente se realizó una ponderación, donde los factores
son los nombres de los tamaños y el valor es el número de LOC´s.
Capa de Interfaz LOCs
MP 20
P 40
M 60
G 120
MG 240
Capa de Negocio LOCs
MP 10
P 30
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
44
M 60
G 150
MG 300
Capa de Datos LOCs
MP 10
P 20
M 60
G 80
MG 130
Después se elaboró una lista de los componentes del sistema, y para cada componente se estimó
su tamaño, en base a la tabla anterior. Así, al final obtuvimos el tamaño total del sistema en LOC’s,
este tamaño fue inicial, ya que en el transcurso del proyecto se iría adaptando a los cambios o
ajustes que fueran necesarios.
Componente Interfaz Negocio Datos Tamaño total
LeeDashboard
G G 230
LeeDatosUsuario G M M 240
estimadoTiempo M G M 270
estimadoTamaño M G M 270
estimadoError M G M 270
Análisis MG MG *500 G 820
Reportes G G G 350
RecuperaDatos
G G 230
Almacena
M G 140
Integración
MG
300
Total LOC’s Base de Datos
Junta 4
Aquí el equipo realizó un plan para identificar las tareas que se deberían realizar para la
elaboración del proyecto, se elaboró un calendario con las tareas a realizar, basándose en las
horas disponibles de cada integrante. Este plan de trabajo se elaboró con la finalidad de cumplir
las metas del equipo así como las del cliente.
El calendario que se elaboró consideró 3 iteraciones:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
45
Fechas: Inicio del proyecto = 7/05/2012 Fin de la iteración 1 = 5/06/2012 Fin de la iteración 2 = 3/07/2012 Fin de la iteración 3 = 14/07/2012
Para el desarrollo del proyecto usamos el proceso iterativo-incremental; debido a que este
proceso maneja la idea de desarrollar un sistema de programas de manera incremental,
permitiendo que en el desarrollo se saque ventaja de lo que se ha aprendido a lo largo del
desarrollo anterior, incrementando, versiones entregables del sistema.
Junta 5
El equipo generó un plan de la calidad del producto, tomando como base a las metas que el cliente
deseaba alcanzar con el mismo y también las del equipo. Una vez ya generado este plan, se tuvo
que analizar detenidamente para ver que fuera consistente y de no ser así realizar los ajustes
necesarios.
Plan de calidad del equipo
Para el sistema de Sistema de Estimación y Análisis de Proyectos se establecieron los siguientes
aspectos de calidad:
Realizará estimaciones con una desviación de +-20%
Sera hará uso de tecnologías para cada capa de software para establecer un sistema rápido, funcional y seguro.
Producto con calidad con 0.01 defectos por KLOC, para lograr esto se pretende seguir las metas de calidad sugeridas por el TSP. Se planean introducir 727 defectos en el proyecto cuya longitud es de 3,735 Líneas de código.
Aquí se muestra el plan de calidad, en dónde se planteó el número de defectos que se eliminarían
por fase.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
46
Fase Defectos eliminados
Requirements Review 33.6
Requirements Inspection 10.1
HLD Review 39.4
HLD Inspection 11.8
Detailed Design Review 74.2
Detailed Design Inspection 22.3
Code Review 369
Compile 81
Code Inspection 56.7
Unit Test 25.9
Build and Integration Test 2.31
System Test 0.46
Total 727
Junta 6
Se construyeron los planes pero ahora de una forma más detallada, se realizó un balance de las
tareas asignadas de modo que todos los integrantes del equipo terminaran sus tareas al mismo
tiempo, es decir se buscó un equilibrio en la carga de trabajo de los integrantes; con esto se
generó un plan de equipo, el cual sería la guía el trabajo en conjunto para cada fase del proyecto.
Cuando se realizó la estimación del tamaño total del sistema, se definieron componentes y a cada
uno de estos se les asignó un tamaño aproximado, pero cada componente podía dividirse a su vez
en más componentes, esto fue con el fin de que cada tarea pudiera ser desarrollada con PSP por
cualquier integrante del equipo.
Fue entonces cuando procedimos a descomponer el sistema en pequeños fragmentos que serían
asignados a los integrantes, donde, de acuerdo a su tamaño se debería ir haciendo un balance,
donde se buscaba que cada integrante realizara la misma cantidad de trabajo.
Después de dividir el sistema en pequeños fragmentos obtenemos lo siguiente:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
47
Componente Locs del ciclo
IT1 It2 It3
LeeDashboard Neg 60 LeeDashboard Dat 60 LeeDatosUsuario Neg 60 LeeDatosUsuario Dat 40 LeeDatosUsuario Int 120 estimadoTiempo Neg
150
estimadoTiempo Dat
40 estimadoTiempo Int
60
estimadoTamaño Neg
150 estimadoTamaño Dat
40
estimadoTamaño Int
60 estimadoError Neg
150
estimadoError dat
40 estimadoError Int
60
Analisis Neg
240
Analisis Dat
300
Analisis Int
60
Reportes Neg
120
Reportes Dat
150
Reportes Int
60
RecuperaDatos Neg
150 RecuperaDatos Dat
60
Almacena Neg 60 Almacena Dat 60 Integración Neg
300
Base de Datos Manual de usuario
25 paginas
Script de instalación
100
Doc caso de uso 20 paginas 20 paginas 20 paginas
Checklist de casos de uso revision 1 pagina Doc Vision 7 paginas Checklist casos de uso inspeccion 1 pagina Modelo de casos de uso 1 pagina 1 pagina 1 pagina
Plan de pruebas de sistema
1 pagina
Documento de diseño* 14 páginas 10 páginas 10 páginas
Plan de pruebas de integración 3 páginas 3 páginas 3 páginas
Checklist de revision del diseño 3 páginas
De esta manera se obtuvo el WBS, un archivo que contenía todos los componentes y
subcomponentes del sistema, así como sus respectivos tamaños y el nombre del integrante
responsable de su desarrollo. Ver WBS
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
48
Junta 7
En esta junta el equipo de desarrolladores identificó todos los posibles riesgos que podían ir
apareciendo durante el desarrollo del producto; estos riesgos se evaluaron con respecto al
impacto o probabilidad que tenían de aparecer o no, lo cual llevó a definir la manera en que se
mitigarían los riesgos de media y alta prioridad.
Cada uno de los riesgos fue asignado a cada miembro del equipo para que este fuera el encargado
de poner más atención en el riesgo, sin embargo todos los miembros del equipo debían estar al
tanto de todos los posibles riesgos. Cada semana se debía revisar la tabla de riesgos, para ver si se
estaban mitigando y poder eliminarlos de la lista, de no ser así, se cambiaba de estrategia.
Los riesgos que se identificaron son:
Riesgo Estrategia Tarea Asig.
No se puede obtener la información del Process DashBoard.
Recurrir a los manuales o código del Process DashBoard.
Estudiar manuales del Process DashBoard.
JA S
Falta de especificación de requerimientos.
MS S
Poca disponibilidad del cliente para levantamiento de requerimientos.
Informarle al cliente que retrasaría la fecha de entrega
MS S
Mala comprensión en los requerimientos.
Preguntar al cliente si es lo que desea.
Recibir y corregir las observaciones.
MS S
Tareas no planeadas. Agregar más tiempo a las tareas de investigación.
AG S
Mala estimación del plan del proyecto o de alguna de sus tareas.
Ajustar el WBS. AG S
Desconocimiento de alguna herramienta de trabajo.
Buscar información sobre el funcionamiento de la herramienta.
Instalar y configurar herramientas.
JA S
Subestimación en el tiempo de aprendizaje de las tecnologías.
Considerar más tiempo en el aprendizaje de las tecnologías.
JB S
Mala organización en el equipo. Hacer juntas. AG S
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
49
Junta 8
El equipo preparó una presentación de todo lo planeado, que sería mostrada a la dirección; en
esta presentación se mostró la estrategia que usaría el equipo para el desarrollo, así como
también se describían los posibles planes alternativos que pudieran requerirse a la hora de la
realización del producto, estos planes alternos podían contemplar el agregar más recursos al
proyecto, modificar alguna funcionalidad del sistema, etc.
Se llenó el siguiente formato:
Nombre Jorge Alberto García López Fecha 04/05/12
Moderador Coach del Lanzamiento Lugar LIS
Fecha de la junta 04/05/12 Hora Inicio: 13:10 Hora Fin:
Tema/Propósito Junta 8 del Lanzamiento de TSP: Prepararse para la junta con la dirección.
Asistentes
Nombre Rol
Elena Beatriz García Cruz Líder
Diego Armando Zamora Ramos Equipo
Jorge Alberto García López Anotador
Marco Fabián Salazar Suarez Crono metrista
José Williams Alvarado Suarez Equipo
Jesica Beltrán Sánchez Equipo
Luis Castro Coach
Alan García Zamora Equipo
Agenda
Tiempos (min.) Temas Líder de Presentación
Plan Inicio Fin
10 13:15 13:17 Agenda y proceso de la junta Coach de lanzamiento
60 13:17 13:40 Plan de la junta de la presentación a la dirección
Líder del Equipo
15 13:40 13:48 Asignación de las tareas de preparación de la Líder del Equipo
junta
5 13:48 13:53 Cierre de la junta y reporte Coach de lanzamiento
Decisiones, Acciones e Información Clave
Qué Quién Cuándo
Anotador Williams Junta9
Crono metrista Alan Junta 9
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
50
Expositor Marco Junta 9
Apoyo expositor Jorge Junta 9
Metas cliente implícitas y explicitas Jorge Junta 8
Plan y asignación roles Elena Junta 8
Calendario y trabajo José Junta 8
Plan calidad Marco Junta 8
Metas equipo Jesica Junta 8
Riesgos Alan Junta 8
Junta 9
En esta junta se contó con la presencia de la dirección, para que se le mostrara la presentación
elaborada en la reunión 8, la dirección expresó al equipo todas sus inquietudes con respecto al
plan que le fue mostrado, y el equipo evaluó otras alternativas.
Los datos más importantes que se presentaron a la dirección son:
Fechas:
Inicio del proyecto = 7/05/2012
Fin de la iteración 1 = 5/06/2012
Fin de la iteración 2 = 3/07/2012
Fin de la iteración 3 = 14/07/2012
Donde cada iteración abarcó lo siguiente:
Componentes que se elaborarán en la Iteración 1
Leer datos del Dashboard
Leer datos introducidos por el usuario
Base de datos
Almacén de datos
Componentes que se elaborarán en la Iteración 2
Recuperar datos
Estimar Tiempo
Estimar Tamaño
Estimar Error
Componentes que se elaborarán en la Iteración 3
Análisis
Reportes
Integración
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
51
El desarrollo del sistema fue implementado mediante el proceso iterativo-incremental, esto con el
fin de obtener un sistema temporal y funcional al final de cada iteración, en cada iteración, se
realizaron cambios en el diseño y se agregaron nuevas funcionalidades y capacidades al sistema.
Cabe mencionar que el sistema sería desarrollado usando el patrón MVC (Modelo Vista
Controlador) que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario
y el módulo encargado de gestionar los eventos y las comunicaciones.
Así mismo vale la pena especificar qué framework sería utilizado para cada una de las capas:
Capa de Interfaz (JSF): Es un framework para aplicaciones Java basadas en web que simplifica el
desarrollo de interfaces de usuario en aplicaciones Java EE. [7]
Capa de Negocio (Spring): Es un framework para el desarrollo de aplicaciones y contenedor de
inversión de control, de código abierto para la plataforma Java. [8]
Capa de Datos (Hibernate): Es una herramienta de Mapeo objeto-relacional (ORM) que facilita el
mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una
aplicación, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que
permiten establecer estas relaciones. [9]
DESARROLLO DEL SISTEMA USANDO TSP
Una vez que se concluyeron las juntas, se procedió a comenzar el desarrollo del sistema utilizando
el TSP. En este punto se tenía un dashboard general que estaba ligado a los dashboard de cada
uno de los integrantes, el dashboard de cada uno de los integrantes contenía las tareas que se le
asignaron y el tiempo estimado de cada una de ellas.
El proceso que siguió cada integrante fue el siguiente:
El integrante comenzó con su primera tarea asignada utilizando PSP, esto implicó seguir una serie
de actividades e ir registrando el tiempo que se tardaba en cada una de estas. Cuando terminaba
una tarea, la marcaba como terminada y continuaba con la siguiente, y así sucesivamente con
cada una de las tareas.
Cada semana se realizaba una junta para ver los avances de los integrantes y así mismo poder ver
el avance del proyecto, esto se logró después de que cada uno de los integrantes sincronizara su
dashboard con el principal.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
52
Cabe mencionar que existe un documento que nos ayudó a planear y conducir las juntas
semanales del equipo, el Guión WEEK.
En cada junta se realizó una tabla de avances del equipo, en donde se registraron los siguientes
datos:
Nombre del integrante Valor generado(porcentaje) Número de tareas terminadas Horas dedicadas Valor planeado Tiempo planeado
Este cuadro nos sirvió para saber si realmente se estaban dedicando las horas planeadas o si
debíamos hacer algún ajuste en los tiempos. En la segunda junta se detectó que el tiempo
planeado y el tiempo real diferían de forma considerable, por lo que se tomó la decisión de ajustar
los tiempos, para que el estimado de la fecha fin fuera lo más real posible.
Un ejemplo de la tabla de avances es de la junta 1:
Investigar cómo se sacan datos del DashBoard Levantar requerimientos con el cliente (planear juntas) Crear un proceso para los requerimientos Ajustar los módulos existentes, a los nuevos requerimientos Reasignar tareas Ajustar tiempos de los integrantes del equipo Estándar de diseño Estándar de codificación Ajustar el checklist de diseño para los integrantes del proyecto Ajustar el checklist de código para los integrantes del proyecto Investigar y acordar cuál será el proceso para validar los requerimientos. Ajustar el WBS Dar clase sobre JUnit Realizar checklist del documento de visión. Realizar inspección del documento de visión. Validación del documento de visión por el cliente
Valor Generado (%)
Tareas Terminadas
Horas dedicadas
Valor Planeado Tiempo Plan
Elena 2.6 3 2:43 9.1 20
Jesica 3.4 2 6 6.5 10
Diego 1.5 1 2:28 8.3 20
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
53
Jorge 9.1 4 10 10.1 20
Williams 10.5 4 5:34 10.5 10
Alan 5 1 0:29 8.7 5
Marco 9.8 6 14.38 9.8 20
Pendientes:
Checar si la enseñanza de tecnologías se mete como tarea. Checar si el levantamiento de requerimientos se mete como tarea. Hacer proceso de requerimientos.
En este caso, aparte de obtener el cuadro de avance de la semana, se hizo una lista detallada de
las actividades que teníamos pendientes y debíamos resolver durante la semana siguiente, esto
nos permitía, agregar al WBS tareas que no habíamos considerado, para que las tareas y los
tiempos fueran los más claros posible.
VER CUADROS DE AVANCE
TAREAS DESARROLLADAS
Anteriormente se mencionaba que el Proceso TSP permitía repartir todas las tareas que contiene
el WBS entre los integrantes del equipo, de manera tal que cada integrante tuviera la misma
cantidad de trabajo. Entonces las tareas que me fueron asignadas son las siguientes:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
54
A continuación se describirán sólo algunas de las tareas más importantes que tuve asignadas.
Documento de visión = 3:35
Realizar Documento de Visión = 2:55
Mi primera tarea fue elaborar el documento de visión con ayuda de una compañera, nos reunimos
y describimos detalladamente la visión y el alcance del proyecto, en base a los requerimientos del
cliente, esto se realizó siguiendo el proceso PSP, y obtuvimos el siguiente documento:
Documento de Visión y Alcance
1. Introducción
El presente documento describe la visión y alcance del Sistema de Estimación y Análisis de
Proyectos. Este documento permite establecer los requerimientos iniciales acerca del desarrollo
que se va a realizar.
2. Contexto de negocio
Antecedentes
La Universidad Autónoma Metropolitana (UAM) es una de las principales universidades públicas
de la ciudad de México. Dentro del área de ingeniería de software, se tienen nuevas ideas para
contribuir con la educación de los alumnos, una de ellas es desarrollar una herramienta que ayude
a los alumnos involucrados en desarrollo de proyectos de software.
Frase del problema
Actualmente el proceso que se sigue dentro de la organización, para realizar la predicción del
tiempo de desarrollo de sistemas, es de forma artesanal, es decir, no se basan en datos históricos
de la organización, sino que realizan estimaciones basándose en su intuición y criterio, esto tiene
varios inconvenientes, debido a que las estimaciones son muy deficientes y esto provoca una gran
pérdida, tanto de tiempo como de costos.
Dada la urgencia de resolver los problemas anteriormente mencionados, se requiere poder
automatizar los elementos fundamentales de operación en la primera etapa del proyecto.
Objetivos de negocio
ID Descripción del objetivo de negocio
ON-1 Predecir el tiempo de desarrollo de un sistema con una desviación de calendario pequeña.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
55
ON-2 Hacer una mejor estimación de la calidad del sistema que se desea desarrollar.
ON-3 Registrar estimaciones y predicciones de proyectos anteriores.
ON-4 Agilizar el proceso de estimación o predicción del tiempo del desarrollo de un sistema.
3. Visión de la solución
Frase de visión
El Sistema de Estimación y Análisis de Proyectos será un sistema moderno de estimación de
proyectos. Permitirá además el análisis de datos proporcionados por el usuario, así como los datos
históricos del mismo. Finalmente, el sistema generará reportes que permitirán realizar una
estimación más precisa de los proyectos.
Características del sistema
ID Descripción Prioridad Objetivo de negocio asociado
CAR-1 Dar de alta un proyecto en el sistema.
Alta ON- 1
CAR-2 Almacenar datos de proyectos anteriores.
Alta ON-1,ON-,ON-3
CAR-3 Permitir almacenar datos de Alta ON-1, ON-4
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
56
postmortem de proyectos.
CAR-4 Actualizar y agregar nuevos datos en la BD
Alta ON-1,ON-3
CAR-5 Consultar datos de proyectos históricos
Media ON-4
CAR-6 Permitir al administrador realizar análisis de datos
Baja ON-4
CAR-7 Integración con sistemas externos.
Media ON-1
4. Alcance y limitaciones
Alcance
Número de release Tema principal ID de Características a incluir
Release 1.0 Funcionalidad básica CAR-1,CAR-2,CAR-3,CAR-4
Release 2.0 Función de análisis de datos
CAR-5
Release 3.0 Función de reporteo CAR-6
Limitaciones
Queda excluido el acceso vía celular
5. Contexto del sistema
Resumen de Involucrados
Nombre Descripción Responsabilidades
Humberto Cervantes Maceda
Director de la empresa que solicita el sistema
Aprobar visión
Validar requerimientos
Aprobar entregas del proyecto
Luis Fernando Castro Careaga
Coach del equipo de desarrollo
Proporcionar y validar requerimientos
Validar prototipos
Mostrar la manera en que se realizan las tareas que serán automatizadas.
Guiar al equipo de desarrollo.
Elena Beatriz Líder de equipo de Participar en todas las actividades del desarrollo
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
57
García Cruz desarrollo Consolidar el trabajo del equipo de desarrollo.
Marco Fabián Salazar Suárez
Administrador de Interface y Diseño
Administrador de Interface:
Negocia requerimientos
Negocia criterios de aceptación
Negocia toda solicitud de cambios y la protocoliza (nuevo requerimiento, cambio a requerimiento, refinamiento de un requerimiento)
Establece estándares de documentación de requerimientos
Administrador de Diseño:
Producir los diseños
Comunicarse con el CIM
Responsable de la calidad del diseño
Responsable de los estándares que utiliza el diseño
Responsable de la construcción de los casos de prueba de integración y de sistema
Jesica Beltrán Sánchez
Administrador de Implementación
Responsable de los estándares de codificación y conteo
Responsable de seguimiento y resolución de problemas de implementación (performance, seguridad).
Alan García Zamora
Administrador de Planeación y Proceso
Administrador de Planeación:
Consolida y divide el plan de trabajo
Está pendiente de los indicadores del proyecto
Ajusta los parámetros de planeación Administrador de Proceso:
Responsable por las metas de cuantitivas de proceso del equipo
Responsable que todos los miembros del equipo sigan los procesos definidos por el equipo
Procesa los PIP’s
Es el autorizado a modificar los procesos del equipo
Diego Armando Zamora Ramos
Administrador de Calidad
Seguimiento a las metas cuantitativas de calidad
Estándares de calidad
Decisiones de calidad
Inspecciones por colegas
José Williams Alvarado Suárez
Administrador de Soporte
Responsable de la Administración de Configuración (versiones y solicitudes de cambio)
Conforma el CCB
Responsable de los procesos de Administración de Configuración.
Jorge Alberto García López
Administrador de Pruebas
Realizar los planes de prueba
Responsable de la plataforma de pruebas, software, estándares, etc.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
58
Entorno de operación
El sistema será utilizado mediante computadoras fijas y mediante computadoras conectadas vía
red inalámbrica.
El sistema se ejecutará en un servidor que será adquirido para fines de albergar la aplicación.
La plataforma donde se utilizará el sistema, será Windows XP, Vista 7.
Para hacer uso del sistema es necesario contar con navegador de internet (Firefox, IE, Chrome, Opera, Safari).
Información adicional
Junto con el sistema se entregará:
Manual de usuario.
Manual técnico.
Script de instalación.
Código fuente y ejecutables.
CheckList Revisión de casos de uso = 0:51
Realizar CheckList RCU = 0:51
Se realizó además el documento Checklist de revisión del documento de casos de uso, es un
documento que nos sirve para saber si el documento de casos de uso contiene toda la información
necesaria para poder implementar los casos de uso.
Checklist de revisión del documento de casos de uso
Instrucciones: Una vez lleno un documento de caso de uso, recorrer cada uno de los puntos y, una vez que la pregunta se contesta de forma positiva, marcarlo como revisado. El documento no se considera como terminado hasta que no se han cubierto todos los puntos.
Id Punto a revisar Revisado
1 ¿Se ha elegido un identificador único para el caso de uso? [ ]
2 ¿Se ha elegido un nombre apropiado para el caso de uso (verbo en infinitivo, nombre)? [ ]
3 ¿La descripción del caso de uso explica el objetivo que alcanzan los actores mediante el caso de uso?
[ ]
4 ¿Los actores corresponden a información que está en el glosario? [ ]
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
59
5 ¿Las pre-condiciones están descritas como condiciones? [ ]
6 ¿Se puede verificar que las pre-condiciones sean verdaderas antes de la ejecución del caso de uso?
[ ]
7 ¿Las post-condiciones están descritas como condiciones? [ ]
8 ¿Se puede verificar que las post-condiciones sean verdaderas antes de la ejecución del caso de uso?
[ ]
9 ¿El flujo principal se describe como una interacción entre usuario y sistema? [ ]
10 ¿Se describe a partir de qué punto bifurcan los flujos alternativos y excepcionales del flujo principal?
[ ]
11 ¿Los flujos alternativos retoman en el flujo principal? [ ]
12 ¿El primer paso del flujo principal es la acción del usuario que arranca el caso de uso (disparador)?
[ ]
Modelos de casos de uso V1 = 0:56
Hacer Modelo de casos de uso v1 = 0:56
Una tarea más que se realizó fue crear el modelo de casos de uso, el cual es una secuencia de
interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que
inicia un actor principal sobre el propio sistema y que sirve para especificar la comunicación y el
comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. En
nuestro caso se obtuvo lo siguiente:
Documento de casos de uso V1 = 6:21
Hacer Documento de CU1 Alta Proyecto = 2:07
Se realizó la documentación de un caso de uso: Alta de Proyecto
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
60
CU-1 Dar de alta proyecto
1.- Identificador y nombre
CU-1 Dar de alta proyecto.
2.- Descripción
El caso de uso permite al usuario del sistema dar de alta un proyecto en la BD del programa.
3.- Actores
Administrador
4.- Pre-condiciones
El administrador se encuentra en la ventana principal V-P El proyecto no se encuentra registrado en el sistema
5.- Post-condiciones
El nuevo proyecto ha sido dado de alta en el sistema y se muestra un mensaje confirmando que la
acción fue realizada.
6.- Flujo principal
1. El administrador da click en la opción alta de proyecto 2. El sistema muestra la ventana de alta de proyecto 3. El administrador introduce los datos del nuevo proyecto da click en la opción aceptar 4. El sistema valida los datos y crea un nuevo proyecto dentro del sistema y pregunta al
usuario si desea recuperar datos del dashboard 5. El administrador selecciona la opción NO 6. El sistema muestra un mensaje con los datos del nuevo proyecto 7. El usuario selecciona la opción aceptar 8. El sistema regresa a la página principal V-P
7.- Flujos alternativos En 3.
Si los datos del proyecto son incorrectos y/o incompletos
1. El sistema muestra un mensaje de error, indicando cuáles datos son incorrectos 2. El flujo se retoma en el paso 2
En 5.
El administrador selecciona la opción SI
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
61
a. El sistema muestra una ventana (Ventana Cargar datos) b. El flujo se retoma en el paso 8
8.- Flujos excepcionales
En 2. Si el administrador cancela
1. El sistema borra la información que había sido introducida, y se queda en la ventana de alta de
proyecto.
9.- Requerimientos funcionales detallados y reglas de negocio asociados
ID Descripción del requerimiento
UC-1.RF1 El sistema debe guardar la siguiente información de los proyectos: - Nombre - Descripción - Fecha inicio - Nombre de integrantes
UC-1.RF1.1
El nombre es obligatorio y deberá ser de 5 a 20 caracteres alfanuméricos
UC-1.RF1.2
La descripción debe ser opcional
UC-1.RN1
10.- Requerimientos no-funcionales asociados.
ID Descripción del requerimiento
UC-1.RNF1
Usabilidad: En caso de que uno o más campos estén incorrectos, el sistema debe señalar visualmente dichos campos.
11.- Ventana asociada
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
62
Documento de diseño V1 = 5:10
Hacer diagrama de clases = 2:08
Otra de las tareas más importantes, fue definir el diagrama de clases, este modelo es un tipo de
diagrama estático que describe la estructura de un sistema, mostrando sus clases, atributos y las
relaciones entre ellos. Es utilizado durante el proceso de análisis y diseño de los sistemas, donde
se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes
que se encargarán del funcionamiento y la relación entre uno y otro.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
63
Principal Interfaz = 9:26
Programar Principal Interfaz = 9:26
Respecto a la implementación se realizaron tareas de programación de interfaces, en este caso se
realizó la interfaz de la pantalla principal:
AltaDeProyecto Interfaz = 8:33
Programar AltaDeProyecto Interfaz = 8:33
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
64
Una tarea más de programación, fue realizar la pantalla de Alta de Proyecto:
Es importante mencionar que estas tareas se realizaron utilizando JSF, cuando se estaba
trabajando sin AppFuse, más adelante se mostrará cómo quedaron estas interfaces al final del
proyecto.
Es importante mencionar que sólo se concluyó la primera iteración del sistema, se anexarán las
tareas que me asignaron en las otras dos iteraciones.
Datos importantes del dashboard
Con anterioridad se mencionaba el hecho de que no se estaban cumpliendo las metas propuestas
respecto al tiempo que se dedicaría al proyecto, esto tuvo impacto en la fecha fin del proyecto, se
tuvieron que ir haciendo ajustes y tomando decisiones, y el dashboard nos generaba gráficas como
estas:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
65
Podemos notar que el valor actual generado siempre estuvo debajo del valor generado planeado.
Después de realizar junta con los integrantes del equipo, se llegó a la conclusión de que uno de los
principales problemas era que unas tareas dependían de otras, y estas tareas se habían asignado
de forma tal, que algunos integrantes ya no podían avanzar, la solución que se propuso, fue
reasignar las tareas de tal manera que los integrantes que se encontraban detenidos, pudieran
continuar.
También se realizó un ajuste al estimado del tiempo, porque con las tareas que se habían realizado
nos dimos cuenta, que habíamos subestimado algunas cosas y otras más no las habíamos
considerado.
Otro problema fue que no se estaban cumpliendo las horas planeadas, esto debido a que no se
contabilizaban las horas que nos tomaba resolver otro tipo de problemas que no estaban en el
WBS, es por esto que se propuso agregar otra columna a las tablas de avance, para que las horas
dedicadas fueran más reales, así como agregar algunas tareas al WBS que no se habían
considerado.
Un problema más, fue el hecho de que en las primeras semanas teníamos varias dudas acerca de
los requerimientos del cliente, entonces se decidió planear juntas con el cliente para que nos
pudiera aclarar nuestras dudas y así poder seguir adelante con el desarrollo del sistema. La
solución para este problema fue la realización de un documento llamado “Historias de Usuario” el
cual es una técnica que tiene como propósito principal presentar un resumen de las
funcionalidades que se solicitan para el sistema.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
66
Implementación del sistema
Es importante mencionar algunos aspectos de la implementación del sistema, ya que influyó en
varias decisiones del proyecto.
Inicialmente se planteó que el sistema sería desarrollado utilizando tres frameworks, uno por cada
capa del sistema (Capa de Interfaz (JSF), Capa de Negocio (Spring), Capa de Datos
(Hibernate)), esto implicaba que un integrante desarrollara cada capa de un módulo, y cuando las
tres estuvieran terminadas, se haría la integración de dicho módulo. Pero al querer integrar las
tres capas nos dimos cuenta que no era sencillo, esto nos llevó a tomar una decisión, la cual
implicaba utilizar Appfuse que es una aplicación web base donde el trabajo de conectar todos los
frameworks ya está hecho. [10]
Pero para poder implementar nuestro sistema con esta tecnología, tuvimos que seguir unos
tutoriales, entonces estas tareas también tuvimos que agregarlas al WBS, y esto provocó que las
fechas se fueran moviendo cada vez más.
Al final obtuvimos nuestro sistema con algunas funcionalidades básicas:
PÁGINA PRINCIPAL: Esta página permite loggearse, para poder entrar al sistema.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
67
Si el usuario o contraseña no son válidos, se muestra un mensaje.
PÁGINA DE ALTA UN PROYECTO: Nos permite dar de alta un proyecto, indicando su nombre,
descripción y fecha, donde se indica con un * que los tres valores son obligatorios.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
68
Ventana que muestra una lista de todos los proyectos dados de alta en el sistema
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
69
DOCUMENTACIÓN DEL SISTEMA
Diagrama de componentes del sistema
Figura 1.11. Diseño de alto nivel de los componentes de la primer iteración.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
70
Diagrama de secuencia de alta de proyecto
Figura 1.12. Diagrama de secuencia del caso de uso “Alta de proyecto” de la primer Iteración.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
71
CONCLUSIONES
Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas,
predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto
software.
El TSP nos permite seguir una estrategia de calidad, esto con el propósito de obtener un software
seguro y confiable que se adecue a las necesidades de un cliente, con el menor costo y en el
menor tiempo posible.
El propósito de este proyecto fue aprender a utilizar los procesos PSP y TSP, aplicando estos
conocimientos en el desarrollo de un sistema de información, en la primer parte del curso cada
integrante aplicó el PSP en diversas prácticas, para que al llegar a la segunda parte del curso, cada
integrante pudiera aplicar esos conocimientos, pero esta vez a nivel de equipo.
El sistema que se pretendía implementar, constaba de tres iteraciones, de las cuales se desarrolló
sólo la primer parte, esto debido a diversos conflictos que surgieron durante el transcurso del
proyecto: inicialmente no se especificaron todas las tareas, se realizó una mala estimación del
tiempo y el tamaño de cada una de estas, cuando comenzó el proyecto se hizo una mala
distribución de las actividades, ya que no se consideró el hecho de que algunas tareas dependían
de otras, y esto provocó que algunos integrantes no pudieran avanzar en sus actividades.
Sin embargo se cumplió la meta de llevar a cabo el proceso TSP y PSP, pero por una mala
estimación de tiempos y falta de conocimientos en las tecnologías que utilizamos para desarrollar
el sistema, este no se pudo concluir, aunado a esto, se encuentra el hecho de que al final se tuvo
que recurrir a una nueva herramienta que nos ayudara a integrar las tres capas del sistema.
Es importante mencionar que el trabajo en equipo es básico en el proceso TSP, y en este caso el
equipo estableció metas comunes y definieron roles, hubo buena comunicación y apoyo en el
equipo. Esto ayudó a que se cumpliera una meta más del proceso.
Cabe destacar que este proyecto nos sirvió de experiencia para que en futuros proyectos se
realicen mejores estimaciones tomando en cuenta nuestros datos históricos y se consideren las
limitaciones que tuvimos esta primer vez que trabajamos con TSP y PSP, para que sean tomadas
como riesgos y se tomen medidas para poder mitigarlos.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
72
REFERENCIAS
[1] http://definicion.de/ingenieria-de-software/
[2] http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
[3] http://html.rincondelvago.com/personal-software-process-psp.html
[4] http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/pelaez_r_jj/capitulo2.pdf
[5]
http://repository.lasallista.edu.co/dspace/bitstream/10567/696/1/Implementacion_metodologia_
PSPTSP.pdf
[6] http://alejandrogomeztsp.blogspot.mx/
[7] http://es.wikipedia.org/wiki/JavaServer_Faces
[8] http://es.wikipedia.org/wiki/Spring_Framework
[9] http://es.wikipedia.org/wiki/Hibernate
[10] http://en.wikipedia.org/wiki/AppFuse
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
73
ANEXOS
Anexo 1. Forma ROLE
Esta forma nos ayuda a asignar los roles del equipo y su respectivo suplente, considerando a
todos los integrantes.
Asignación de Roles del Equipo TSP - Forma ROLE
Nombre Jorge Alberto García López Fecha 25/04/12
Proyecto TSP Lanzamiento/Fase Junta 2
Roles de Miembros del Equipo Requerimientos Diseño Implementación
Integración y Pruebas
Líder Oficial del Equipo P EG
A
Administrador de la Interfaz con el Cliente
P MS
A JA
Administrador del Diseño
P MS
A JG
Administrador de Implementación
P JB
A DZ
Administrador de la Planeación
P AG
A EG
Administrador del Proceso
P AG
A JB
Administrador de la Calidad
P DZ
A JB
Administrador de Soporte
P JA
A DZ
Administrador de Pruebas
P JG
A JA
Anexo 2. Forma ROLEMX
Esta forma nos ayuda a realizar la asignación de roles.
Matriz de Asignación de Roles de TSP - Forma ROLEMX
Nombre Jorge Alberto García López Fecha 25/04/12
Proyecto TSP Lanzamiento/Fase Junta 2
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
74
Roles de
los
miembros
del Equipo
Miembros
del Equipo
Ad
min
istr
ad
or
de l
a In
terf
az c
on
Clien
te
Ad
min
istr
ad
or
del D
iseñ
o
Ad
min
istr
ad
or
de l
a Im
ple
men
tació
n
Ad
min
istr
ació
n d
e l
a P
lan
eació
n
Ad
min
istr
ació
n d
el
Pro
ce
so
Ad
min
istr
ació
n d
e l
a C
ali
dad
Ad
min
istr
ad
or
de S
op
ort
e
Ad
min
istr
ad
or
de P
rueb
as
Elena Beatriz
García Cruz
Diego
Armando
Zamora
Ramos
2 1 3
Jorge Alberto
García López
2 1 3
Marco Fabián
Salazar
Suarez
1 2 3
José Williams
Alvarado
Suarez
1 2 3
Jesica Beltrán
Sánchez
2 1 3
Alan García
Zamora 3 2 1
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
75
Encargado
Suplente
Anexo 3. Forma MTG
Esta forma se utiliza para registrar las disposiciones y resultados de cada junta.
Instrucciones del Reporte de Junta TSP – Forma MTG Propósito Use esta forma para registrar las disposiciones y resultados de la junta.
General Llene las porciones del encabezado, propósito y agenda de esta forma previamente a la junta
Al principio de la junta, determine quiénes llevarán los roles de cronometrista y anotador.
Para más espacio, adjunte otra forma u hojas separadas.
Encabezado Registre su nombre y la fecha de llenado de la forma.
Registre el nombre del moderador.
Registre el tiempo y lugar planeados de la junta.
Tema/Propósito Nombre del tipo de junta: semanal del equipo, estado, revisión, etc.
Brevemente describa el propósito de la junta.
Si usted no puede describir brevemente lo que se espera de la junta, reconsidere sostener la junta.
Asistentes Enliste los asistentes planeados a la junta.
Usted debe saber previamente quién presidirá la junta.
Roles de la Junta El moderador preside la discusión y se asegura que se sigan el proceso y la agenda de la junta.
El moderador también se asegura que los roles de la junta sean asignados al principio de la junta.
El cronometrista registra los tiempos de la junta y le ayuda al moderador a mantener la junta a tiempo.
El anotador asegura que todas las conclusiones, decisiones y acciones planeadas sean entendidas y documentadas.
El anotador llena la forma del reporte de la junta y lo entrega al moderador.
El moderador prepara y distribuye el reporte de la junta.
En la mayoría de los casos, una copia de la forma MTG llena es un reporte adecuado.
Agenda Enliste los temas de la agenda con los tiempos y líderes de discusión.
Todos los líderes de discusión deben conocer previamente su tema de agenda.
Si usted necesita espacio adicional, utilice otra forma o anexe una hoja
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
76
separada con la agenda.
Decisiones, Acciones e
Información Clave
Para todas las decisiones, acciones e información clave, enliste clara y
completamente
qué es lo que va a ser o fue
cuándo hacer la decisión o se llevará a cabo la acción
qué información fue proporcionada por quién
cuándo las acciones serán tomadas
cuando sean necesarios datos adicionales, anexe hojas por separado
Anexo 4. Guión WEEK
Este guión permite planear y conducir las juntas semanales del equipo.
Junta Semanal del Equipo TSP – Guión WEEK
Propósito - Planear y conducir las juntas semanales del equipo. - Estas juntas se realizan para asegurar que todos los miembros del
equipo comprenden el estado actual del proyecto y conocer qué es lo que sigue por hacer.
Criterio de Entrada - Todos los ingenieros le han proporcionado al administrador de la planeación - hojas de cálculo actualizadas de tareas y calendario de trabajo - estado y planes de desarrollo, rol y riesgos
- El administrador de la planeación ha generado copias para el equipo de la hoja de cálculo de valor generado del equipo con estado y proyecciones.
- Formas: MTG, WEEK. - Especificación: NOTEBOOK, ROLE, STATUS
General - Las juntas están programadas a una hora estándar cada semana. - Todos los miembros deberían asistir de manera regular.
Paso Actividades Descripción
1 Roles de la Junta - El líder del equipo por lo regular guía la junta (guión MTG). - Los roles del cronometrista y el anotador pueden ser intercambiados
entre los miembros del equipo o de manera regular ser manejados por los mismos miembros.
2 Agenda de la Junta - Revisar el propósito y la agenda de la junta y seleccionar los roles. - Revisar cualquier cambio en el propósito o agenda.
3 Reporte de la Administración
El líder del equipo abre la junta con un breve resumen de cualquier nuevo desarrollo o situación.
4 Reporte de los Los miembros del equipo revisan las responsabilidades de sus roles
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
77
Roles asignados y el estado de cada uno contra el rol (especificación ROLE).
5 Reporte de Metas Cada ingeniero responsable de metas reporta el estado de las mismas contra las metas del equipo.
6 Reporte de Riesgos - Los miembros del equipo revisan el estado y cambios en sus riesgos asignados desde el último reporte y señala cualquier impedimento para cumplir las fechas señaladas y las acciones requeridas.
7 Estado del Proyecto
- Cada miembro del equipo revisa su avance y estado. - tareas concluidas en la semana anterior actuales contra
planeadas - valor generado en la semana anterior actual contra planeado
- El administrador de la planeación resume el avance y estado del equipo - valor generado y horas dedicadas del equipo actual contra
planeado - proyección para la conclusión del valor generado actual
8 Planes de la Siguiente Semana
- Cada miembro del equipo resume las tareas planeadas para la siguiente semana y cualquier dependencia especial.
- El líder del equipo revisa situaciones o acciones esperadas. - El equipo define las metas de tareas, horas y EV para la siguiente
semana.
9 Cierre de la Junta El líder del equipo revisa que todos los elementos necesarios hayan sido cubiertos. - Todos los ingenieros han reportado su estado de proyecto. - Todos los riesgos y roles han sido reportados. - Cualquier riesgo identificado nuevo han sido evaluados y asignados. - Cualquier otro tema de la agenda se ha cubierto.
10 Conclusión de la Junta
El líder del equipo pregunta si hay comentarios adicionales. - confirma las decisiones y acciones planeadas de la junta - acuerda los temas de las juntas con la dirección y el cliente
(especificación STATUS) - solicita cualquier mejora sugerida en el proceso de la junta
11 Reporte de la Junta
El anotador y el líder del equipo generan el reporte de la junta (forma MTG). - horas planeadas contra actuales y valor generado - riesgos que requieren la atención de la dirección y por qué - cualquier decisión, acción planeada u otra información clave
Criterio de Salida Las formas WEEK y MTG terminadas son archivadas en el cuaderno de notas del proyecto.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
78
Anexo 5. Cuadros de Avance
Avances del equipo por semana, contiene: valor planeado, valor generado, tareas terminadas,
horas planeadas y horas dedicadas.
Junta Semanal 1(21/05/12-25/05/12) Fecha: 21/05/2012
Valor Generado (%)
Tareas Terminadas
Horas dedicadas
Valor Planeado Tiempo Plan
Elena 2.6 3 2:43 9.1 20
Jesica 3.4 2 6 6.5 10
Diego 1.5 1 2:28 8.3 20
Jorge 9.1 4 10 10.1 20
Williams 10.5 4 5:34 10.5 10
Alan 5 1 0:29 8.7 5
Marco 9.8 6 14.38 9.8 20
Junta Semanal 2
Valor Generado (%)
Tareas Terminadas
Horas dedicadas
Valor Planeado
Tiempo Plan
Elena 10.7 4 7:52 20.2 20
Jesica 5.7 2 3:38 17.9 10
Diego 4.9 3 6:11 20.5 20
Jorge 10.2 1 7:46 18.5 20
Williams 15 3 7:39 17.8 10
Alan 19.5 6 2:42 14.9 5
Marco 11.3 3 8.94 18.3 20
Fecha: 28/05/2012 Junta Semanal 3(21/05/12-25/05/12)
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
79
Valor
Generado (%) Tareas
Terminadas Horas
dedicadas Overhead
Valor Planeado (%)
Tiempo Plan
Elena 11.36 2 6:15
28.5 20
Jesica 7.4 2 5:27 3 30.1 10
Diego 4.9 0 4:23
30.8 20
Jorge 13.9 3 3:33 4 27.1 20
Williams 19.6 3 3:04 2:30 25.8 10
Alan 27.1 1 1:05
27.1 5
Marco 16.1 3 11:36 4 26.2 20
Junta Semanal 4(27/05/12-02/06/12) Fecha: 04/05/2012 Valor
Generado(%) acumulado
Valor planeado en la semana (%)
Valor generado en la semana (%)
Tareas Terminadas en la semana
Horas dedicadas en la semana
Overhead semanal
Valor Planeado(%) acumulado
Tiempo Planeado semanal
Elena 17.7 10.7 6.34 3 12:41 4 39.2 20
Jesica 13.7 *
6.3 3 4.7 3 ….. 10
Diego 7.4 9.1 2.5 1 13:20 3 39.9 20
Jorge 20.3 11.3 6.4 3 11:09 4 38.4 20
Williams 22.5 12.4 5.8 2 6:30 3 33.8 10
Alan 37.2 16.7 10.1 1 0:15 3:30 43.8 5
Marco 21.7 15.1 5.6 4 11:48 4 41.3 20
Junta Semanal 5(3/06/12-09/06/12) Fecha: 10/05/2012 Valor
Generado(%) acumulado
Valor planeado en la semana (%)
Valor generado en la semana (%)
Tareas Terminadas en la semana
Horas dedicadas en la semana
Overhead semanal
Valor Planeado(%) acumulado
Tiempo Planeado semanal
Elena *- - - - - - - 20
Jesica 10
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
80
Diego 11.4 12.7 4.0 4 19:38 2:16 54.6 20
Jorge 22.7 9.8 3.3 2 18:40 3:30 46.6 20
Williams 28.2 13.1 5.7 2 7:30 2:15 46.7 10
Alan *- - - - - - - 5
Marco 23.8 8.8 5.9 2 16.27 6 48.5 20
Junta Semanal 6(10/06/12-16/06/12) Fecha: 17/06/2012 Valor
Generado(%) acumulado
Valor planeado en la semana (%)
Valor generado en la semana (%)
Tareas Terminadas en la semana
Horas dedicadas en la semana
Overhead semanal
Valor Planeado(%) acumulado
Tiempo Planeado semanal
Elena 31 10.8 4.9 1 15:40 7:30 57.16 20
Jesica 19 6 2 6 2 49.7 10
Diego 13.2 10.3 2.8 6 20:37 2:42 64.9 20
Jorge 24.1 8.2 1.4 2 15.36 3:00 54.8 20
Williams 33.8 8.2 4.6 1 7:12 2:10 55.2 10
Alan 5
Marco 32.2 7.1 7.1 6 16:13 5:30 61.1 20
Junta Semanal 7(18/06/12-22/06/12) Fecha: 24/06/2012 Valor
Generado(%) acumulado
Valor planeado en la semana (%)
Valor generado en la semana (%)
Tareas Terminadas en la semana
Horas dedicadas en la semana
Overhead semanal
Valor Planeado(%) acumulado
Tiempo Planeado semanal
Elena 54.8 10.2 9.1 2 15:42 3:30 91.1 15
Jesica 66.9 46.9 46.9 2 6 2:30 100 7
Diego 21.3 9.5 8.9 5 14:32 1:13 73.4 15
Jorge 36.4 10.1 9.0 2 14:10 2:30 71.8 15
Williams 47.9 7.8 7.1 1 8:58 3:42 72.8 7
Alan 39 7.7 0 0 0:00 2:30 73.6 5
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
81
Marco 36.9 6.4 7.0 4 14:18 1:00 74.49 15
Junta Semanal 8(24/06/12-30/06/12) Fecha: 02/07/2012 Valor
Generado(%) acumulado
Valor planeado en la semana (%)
Valor generado en la semana (%)
Tareas Terminadas en la semana
Horas dedicadas en la semana
Overhead semanal
Valor Planeado(%) acumulado
Tiempo Planeado semanal
Elena 57.3 9.8 8.3 2 14:12 4:00 94.8 15
Jesica 41.4 11.2 11.2 2 5:38 2:12 100 7
Diego 25.7 10.3 9.2 4 13:18 1:16 83.7 15
Jorge 42.3 7.5 5.9 1 12:34 2:00 79.3 15
Williams 49.0 6.2 4.5 2 7:52 2:11 74.8 7
Alan 35.1 7.7 0 0 0:00 0:30 75.6 5
Marco 48.1 14.8 9.5 3 13:22 3:00 79.80 15
Junta Semanal 9(01/07/12-07/07/12) Fecha: 09/07/2012 Valor
Generado(%) acumulado
Valor planeado en la semana (%)
Valor generado en la semana (%)
Tareas Terminadas en la semana
Horas dedicadas en la semana
Overhead semanal
Valor Planeado(%) acumulado
Tiempo Planeado semanal
Elena 57.3 9.8 8.3 2 14:12 4:00 94.8 15
Jesica 41.4 11..2 11.2 2 6:30 2:12 100 7
Diego 25.7 10.3 9.2 4 13:18 1:16 83.7 15
Jorge 48.1 6.9 5.8 2 13:40 2:00 86.2 15
Williams 55.7 6.7 6.7 2 8:36 1:31 78.0 7
Alan 35.1 7.7 0 0 0:00 0:30 75.6 5
Marco 49.2 3.3 3.3 2 9:19 7 86.1 15
Equipo
Junta Semanal 10(09/07/12-15/07/12) Fecha: 16/07/2012
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
82
Valor
Generado(%) acumulado
Valor planeado en la semana (%)
Valor generado en la semana (%)
Tareas Terminadas en la semana
Horas dedicadas en la semana
Overhead semanal
Valor Planeado(%) acumulado
Tiempo Planeado semanal
Elena 58.2 4.2 3.7 1 14:12 2:30 92.0 15
Jesica 67.6 15.8 15.8 3 6:40 2:49 100 7
Diego 25.7 0 0 10:18 1:16 83.7 15
Jorge 50 6.8 6.9 1 13:19 2:00 83.9 15
Williams 61.7 7.6 6.0 1 7:37 1:03 82.6 7
Alan 35.1 7.7 0 0 0:00 0:30 75.6 5
Marco 58.0 11.4 11.4 4 16.35 2 86.5 15
Equipo 40.4 4.3 3.9 10 67.69 11.28 88.6 85
Anexo 6. Historias de Usuario
Documento que contiene todas las especificaciones necesarias para poder generar cada caso de
uso.
Historia: Administrador da de alta un proyecto (Prioridad Alta)
Como Administrador
Quiero Dar de alta un nuevo proyecto en el sistema
Para lograr Asociar información general al proyecto y poder asociar datos provenientes del dashboard al proyecto
Escenario No. 1 Alta de proyecto
Dado Que se ha seleccionado alguna opción para dar de alta un nuevo proyecto
Cuando Se introduce la información relativa al proyecto
Entonces Se crea un proyecto dentro del sistema
y El sistema pregunta si en ese momento se quieren recuperar datos del dashboard
Escenario No. 2 Datos inválidos
Dado Que se ha seleccionado alguna opción para dar de alta un nuevo proyecto
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
83
Cuando Se introduce la información inválida relativa al proyecto
Entonces El sistema le explica al usuario de forma clara qué información es incorrecta y le solicita que la introduzca de nuevo
Historia: Administrador carga datos de lanzamiento del proyecto (Prioridad Alta)
Como Administrador
Quiero Cargar los datos relacionados con el lanzamiento del proyecto
Para lograr Poblar la base de datos históricos con información inicial del proyecto
Escenario No. 1 Carga inicial
Dado Que se ha seleccionado un proyecto en el sistema
y se ha elegido la opción de cargar datos iniciales
y el proyecto no tiene datos asociados
Cuando El usuario presiona una opción de aceptar
Entonces El sistema se comunica con dashboard
y Recupera los datos y los asocia al proyecto
Escenario No. 2 Recarga de datos
Dado Que se ha seleccionado un proyecto en el sistema
y se ha elegido la opción de cargar datos iniciales
y el proyecto ya tiene datos asociados
Cuando El usuario presiona una opción de aceptar
Entonces El sistema solicita al usuario confirmar que se van a borrar datos existentes
y Recupera los datos de dashboard cuando el usuario confirma
Escenario No. 3 Falla en comunicación
Dado Que se ha seleccionado un proyecto en el sistema
y se ha elegido la opción de cargar datos iniciales
y el usuario ha presionado una opción de aceptar
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
84
Cuando El sistema se conecta con dashboard y ocurre un error
Entonces El sistema muestra un mensaje de error al usuario
y solicita si se desea intentar de nuevo
Historia: Administrador carga datos de cierre del proyecto (Prioridad Alta)
Como Administrador
Quiero Cargar los datos relacionados con el postmortem del proyecto
Para lograr Poblar la base de datos históricos con información final del proyecto
Historia: Administrador edita datos del proyecto (Prioridad Media)
Como Administrador
Quiero Editar los datos de información general o datos colectados de un proyecto
Para lograr Tener información pertinente del proyecto
Escenario No. 1 Opciones de edición
Dado Que se ha seleccionado un proyecto en el sistema
y se ha elegido la opción de modificar la información
Cuando El usuario presiona alguna opción de aceptar
Entonces El sistema muestra opciones de modificación de datos del proyecto: modificación de información general o modificación de datos cargados de dashboard
Escenario No. 2 Edición exitosa
Dado Que se ha modificado información relativa a un proyecto
Cuando El usuario presiona alguna opción de aceptar
Entonces El sistema solicita confirmación y almacena los datos modificados
Historia: Usuario consulta datos de proyectos históricos (Prioridad Media)
Titulo Usuario consulta datos de proyectos históricos
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
85
Como Usuario
Quiero Consultar datos de proyectos históricos
Para lograr Realizar estimación de proyectos nuevos
Historia: Administrador realiza análisis (Prioridad Baja)
Como Administrador
Quiero Realizar análisis de datos históricos
Para lograr Entender tendencias organizacionales y buscar oportunidades de mejora
Anexo 7. Datos importantes del dashboard
Cuadro de valor generado. Contiene el valor planeado y generado por semana. Así como el
tiempo que se dedicó por semana.
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
86
Tareas correspondientes a la primer iteración:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
87
Tareas correspondientes a la segunda iteración:
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
88
Tareas correspondientes a la tercer iteración:
Anexo 8. WBS
En este documento se registran todas las tareas que se deben desarrollar para poder
implementar el sistema, así como el integrante asignado a cada tarea y la estimación de tamaño
y tiempo de cada tarea.
Time EG
DZ
MS JA
AG JG
JB
Unassigned Time
12P 1071.36
1278 19
7 19
4 21
1 11
2 53.2
206
98 1
Sistema Iteracion1 405.061
2782 55 59 91 62 30.7 80
Entorno de desarrollo 22 0 0 16 4 0 2
Instalar herramientas 22 0 0 16 4 0 2
Instalar StarUML 0.5 0 0 0 0.5 0 0
Instalar Eclipse Indigo EE 3.5 0 0 3.5 0 0 0
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
89
Instalar SubVersion Tortoise 0.5 0 0 0 0.5 0 0
Instalar MySQL 3 0 0 0 3 0 0
Instalar plugin JSF 3 0 0 3 0 0 0
Instalar plugin Spring 3 0 0 3 0 0 0
Instalar plugin Hibernate 3.5 0 0 3.5 0 0 0
Instalar plugin JUnit 2 0 0 0 0 0 2
Instalar servidor web Apache Tomcat 3 0 0 3 0 0 0
Documento de proceso de requerimientos 2 0 0 0 0 2 0
Realizar Documento de Proceso de Requerimientos 2 0 0 0 0 2 0 0 0
CheckList Documento de Vision 1 0 0 0 0 1 0 0 0
Realizar CheckList Documento de Vision 1 0 0 0 0 1 0 0 0
Documento de vision 12 3.3 0 0 0
5.33 0
3.3 0
Realizar Documento de Vision 7 2.3 0 0 0
2.33 0
2.3 28 0
Inspect Documento de Vision 3 1 0 0 0 1 0 1 0 0
Validar el documento de vision 2 0 0 0 0 2 0 0 0 0
Estandares 2 0 0 1 1 0 0 0 0 0
Realizar documento de estandar de diseño 1 0 0 1 0 0 0 0 0 0
Realizar documento de estandar de código 1 0 0 0 1 0 0 0 0 0
CheckList Revision de casos de uso 1 1 0 0 0 0 0 0 0 0
Realizar CheckList RCU 1 1 0 0 0 0 0 0 0 0
Checklist de Modelo de Casos de Uso 1 0 0 0 0 1 0 0 0 0
Realizar ChekList de Modelo de Casos de Uso 1 0 0 0 0 1 0 0 0 0
CheckList de Documento de Vision 1 0 0 0 0 1 0 0 0 0
Realizar ChekList de Documento de Vision 1 0 0 0 0 1 0 0 0 0
CheckList de revisión de diseño 3 0 3 0 0 0 0 0 0 0
Realizar CheckList RDLD 3 0 3 0 0 0 0 0 0
Prototipos de tecnologias IT1 67 3 3 19 15 3 21 3 0
Estudiar JSF 3 0 0 3 0 0 0 0 0
Realizar Prototipo JSF 4 0 0 4 0 0 0 0 0
Estudiar Spring 5 0 0 5 0 0 0 0 0
Realizar Prototipo Spring 4 0 0 4 0 0 0 0 0
Estudiar Hibernate 6 0 0 0 6 0 0 0 0
Realizar Prototipo Hibernate 6 0 0 0 6 0 0 0 0
Estudiar JUnit 4 0 0 0 0 0 4 0 0
Realizar Prototipo JUnit 4 0 0 0 0 0 4 0 0
Estudiar MySQL 6 0 0 0 0 0 6 0 0
Realizar Prototipo MySQL 4 0 0 0 0 0 4 0 0
Impartir clase de tecnologias 21 3 3 3 3 3 3 3 0
Modelos de casos de uso V1 5.35 1. 0 0 0 3. 0 0 0
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
90
8 6
Hacer Modelo de casos de uso v1 1.75 1.8 0 0 0 0 0 0 0
Realizar revision de modelo de casos de uso v1 1.8 0 0 0 0
1.8 0 0 0
Realizar validacion de modelo de casos de uso v1 1.8 0 0 0 0
1.8 0 0 0
Estudiar manuales de DashBoard 9 0 0 0 3 0 3 3 0
Documento de casos de uso V1 18.5112
782 7.5
3.5 1 2 0
4.5 0 0
Hacer Documento de CU1 Alta Proyecto 2 2 0 0 0 0 0 0 0
Realizar revision del Documento de casos de uso Alta Proyecto
1.503759398
1.5 0 0 0 0 0 0 0
Realizar inspeccion de Documento de casos de uso Alta Proyecto 2 0 0 0 1 0 1 0 0
Hacer Documento de CU2 Cargar Datos Lanzamiento 2 0 2 0 0 0 0 0 0
Realizar revision del Documento de casos de uso Cargar Datos Lanzamiento
1.503759398 0
1.5 0 0 0 0 0 0
Realizar inspeccion de Documento de casos de uso Cargar Datos Lanzamiento 2 1 0 1 0 0 0 0 0
Hacer Documento de CU3 Cargar Datos Cierre 2 0 0 0 0 0 2 0 0
Realizar revision del Documento de casos de uso Cargar Datos Cierre
1.503759398 0 0 0 0 0
1.5 0 0
Realizar inspeccion de Documento de casos de uso Cargar Datos Cierre 2 1 0 0 1 0 0 0 0
Validar los casos de uso 2 2 0 0 0 0 0 0 0
Documento de diseño V1 61 11 4 15 10 0 18 3 0
Hacer diagrama de clases 3 3 0 0 0 0 0 0 0
Hacer diagrama de secuencia 18 0 0 6 6 0 6 0 0
Hacer el diseño de la BD 6 0 0 0 0 0 3 3 0
Hacer el diseño de la arquitectura 16 4 0 4 4 0 4 0 0
Realizar revision de Diseño 10 0 0 5 0 0 5 0 0
Realizar inspeccion de HLD 8 4 4 0 0 0 0 0 0
Plan de pruebas de integracion V1 7 0 0 0 0 0 7 0 0
Recibir y corregir observaciones. 2 0 0 2 0 0 0 0 0
BD 8 0 0 0 0 0 8 0 0
Realizar BD 8 0 0 0 0 0 8 0 0
AltaDeProyecto 53.6 12 1.8 25
0.8 1 1
12 0
AltaDeProyecto Interfaz 26 0 0 25 0 0 1 0 0
Programar LeeDatosUsuario Interfaz 24 0 0 24 0 0 0 0 0
Inspec DLD LeeDatosUsuario Interfaz 1 0 0 0.5 0 0
0.5 0 0
Inspec COD LeeDatosUsuario Interfaz 1 0 0 0. 0 0 0. 0 0
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
91
5 5
AltaDeProyecto Negocio 13.6 12 0.8 0
0.8 0 0 0 0
Programar LeeDatosUsuario Negocio 12 12 0 0 0 0 0 0 0
Inspec DLD LeeDatosUsuario Negocio 1 0 0.5 0
0.5 0 0 0 0
Inspec COD LeeDatosUsuario Negocio 0.6 0 0.3 0
0.3 0 0 0 0
AltaDeProyecto Datos 14 0 1 0 0 1 0 12 0
Programar LeeDatosUsuario Datos 12 0 0 0 0 0 0 12 0
Inspec DLD LeeDatosUsuario Datos 1 0 0.5 0 0
0.5 0 0 0
Inspec COD LeeDatosUsuario Datos 1 0 0.5 0 0
0.5 0 0 0
CargarDatosProyecto 21 5 4 3 7 0 2 0 0
CargarDatosProyecto Interfaz 7 4 2 0 1 0 0 0 0
Programar CargarDatosProyecto Interfaz 3 3 0 0 0 0 0 0 0
Inspec DLD CargarDatosProyecto Interfaz 2 1 1 0 0 0 0 0 0
Inspec COD CargarDatosProyecto Interfaz 2 0 1 0 1 0 0 0 0
CargarDatosProyecto Negocio 6 1 1 3 0 0 1 0 0
Programar CargarDatosProyecto Negocio 2 0 0 2 0 0 0 0 0
Inspec DLD CargarDatosProyecto Negocio 2 0 1 0 0 0 1 0 0
Inspec COD CargarDatosProyecto Negocio 2 1 0 1 0 0 0 0 0
CargarDatosProyecto Datos 8 0 1 0 6 0 1 0 0
Programar CargarDatosProyecto Datos 6 0 0 0 6 0 0 0 0
Inspec DLD CargarDatosProyecto Datos 1 0 0.5 0 0 0
0.5 0 0
Inspec COD CargarDatosProyecto Negocio 1 0 0.5 0 0 0
0.5 0 0
CargarDatosProyectoLanz 35 9.5 10 9 4 1 1
0.5 0
CargarDatosProyectoLanz Interfaz 7 1 1 1 4 0 0 0 0
Programar CargarDatosProyectoLanz Interfaz 3 0 0 0 3 0 0 0 0
Inspec DLD CargarDatosProyectoLanz Interfaz 2 1 1 0 0 0 0 0 0
Inspec COD CargarDatosProyectoLanz Interfaz 2 0 0 1 1 0 0 0 0
CargarDatosProyectoLanz Negocio(LeeDashboard) 10 0
8.5 0 0
0.5 1 0 0
Programar CargarDatosProyectoLanz Negocio 8 0 8 0 0 0 0 0 0
Inspec DLD CargarDatosProyectoLanz Negocio 1 0
0.5 0 0 0
0.5 0 0
Inspec COD CargarDatosProyectoLanz 1 0 0 0 0 0. 0. 0 0
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
92
Negocio 5 5
CargarDatosProyectoLanz Datos 18 8.5
0.5 8 0
0.5 0
0.5 0
Programar CargarDatosProyectoLanz Datos 16 8 0 8 0 0 0 0 0
Inspec DLD CargarDatosProyectoLanz Datos 1
0.5
0.5 0 0 0 0 0 0
Inspec COD CargarDatosProyectoLanz Datos 1 0 0 0 0
0.5 0
0.5 0
CargarDatosProyectoCierre 29 1 21 0 2 1 2 2 0
Almacena 25.6 0 1 0 13 10.8 0
0.8 0
Almacena Negocio 13.6 0 0 0 12 0.8 0
0.8 0
Programar Almacena Negocio 12 0 0 0 12 0 0 0 0
Inspec DLD Almacena Negocio 1 0 0 0 0 0.5 0
0.5 0
Inspec COD Almacena Negocio 0.6 0 0 0 0 0.3 0
0.3 0
Almacena Datos 12 0 1 0 1 10 0 0 0
Programar Almacena Datos 10 0 0 0 0 10 0 0 0
Inspec DLD Almacena Datos 1 0 0.5 0
0.5 0 0 0 0
Inspec COD Almacena Datos 1 0 0.5 0
0.5 0 0 0 0
Integracion del Sistema V1 18 0 8 0 0 0 10 0 0
Integrar el sistema 16 0 8 0 0 0 8 0 0
Ejecutar las pruebas del sistema 2 0 0 0 0 0 2 0 0
Sistema Iteracion 2 269 10
0 87 13.7 12 3 35
19 0
Prototipos de tecnologias IT2 7 0 0 4 3 0 0 0 0
Realizar prototipo JSF 1 0 0 1 0 0 0 0 0
Realizar Prototipo Spring 3 0 0 3 0 0 0 0 0
Realizar Prototipo Hibernate 3 0 0 0 3 0 0 0 0
Modelos de casos de uso V2 3 1 1 0 0 0 0 1 0
Hacer Modelos de casos de uso V2 3 1 1 0 0 0 0 1 0
Documento de casos de uso V2 6 0 0 2 2 0 2 0 0
Hacer Documento de casos de uso V2 6 0 0 2 2 0 2 0 0
Documento de diseño V2 13 4 0 4 0 0 5 0 0
Plan de pruebas de integracion V2 13 4 0 4 0 0 5 0 0
Hacer Plan de pruebas de integracion V2 1 0 0 0 0 0 1 0 0
Realizar revision de Diseño 4 0 0 0 0 0 4 0 0
Realizar inspeccion de HLD 8 4 0 4 0 0 0 0 0
RecuperaDatos 50.3 30 16 2.
15 2.2 0 0 0 0
RecuperaDatos Negocio 32.5 30 0 1. 1. 0 0 0 0
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
93
25 3
Programar RecuperaDatos Negocio 30 30 0 0 0 0 0 0 0
Inspec DLD RecuperaDatos Negocio 1 0 0 0.5
0.5 0 0 0 0
Inspec COD RecuperaDatos Negocio 1.5 0 0 0.
75 0.8 0 0 0 0
RecuperaDatos Datos 17.8 0 16 0.9
0.9 0 0 0 0
Programar RecuperaDatos Datos 16 0 16 0 0 0 0 0 0
Inspec DLD RecuperaDatos Datos 1 0 0 0.5
0.5 0 0 0 0
Inspec COD RecuperaDatos Datos 0.8 0 0 0.4
0.4 0 0 0 0
EstimadoTiempo 58.7 1.8 30
0.55 0 1 25
0.8 0
EstimadoTiempo Interfaz 13.6 0.8 0 0 0 0 12
0.8 0
Programar EstimadoTiempo Interfaz 12 0 0 0 0 0 12 0 0
Inspec DLD EstimadoTiempo Interfaz 1 0.5 0 0 0 0 0
0.5 0
Inspec COD EstimadoTiempo Interfaz 0.6 0.3 0 0 0 0 0
0.3 0
EstimadoTiempo Negocio 32 1 30 0 0 1 0 0 0
Programar EstimadoTiempo Negocio 30 0 30 0 0 0 0 0 0
Inspec DLD EstimadoTiempo Negocio 1 0.5 0 0 0
0.5 0 0 0
Inspec COD EstimadoTiempo Negocio 1 0.5 0 0 0
0.5 0 0 0
EstimadoTiempo Datos 13.1 0 0 0.
55 0 0 13 0 0
Programar EstimadoTiempo Datos 12 0 0 0 0 0 12 0 0
Inspec DLD EstimadoTiempo Datos 0.5 0 0 0.
25 0 0 0.3 0 0
Inspec COD EstimadoTiempo Datos 0.6 0 0 0.3 0 0
0.3 0 0
EstimadoTamaño 56.5 13 31 0 1.3 0
2.3 9 0
EstimadoTamaño Interfaz 14 12 0 0 0 0 1 1 0
Programar EstimadoTamaño Interfaz 12 12 0 0 0 0 0 0 0
Inspec DLD EstimadoTamaño Interfaz 1 0 0 0 0 0 0.5
0.5 0
Inspec COD EstimadoTamaño Interfaz 1 0 0 0 0 0 0.5
0.5 0
EstimadoTamaño Negocio 32.5 0 30 0 1.3 0
1.3 0 0
Programar EstimadoTamaño Negocio 30 0 30 0 0 0 0 0 0
Inspec DLD EstimadoTamaño Negocio 1 0 0 0 0. 0 0. 0 0
Desarrollo de Sistema de Información utilizando Team Software Process (TSP)
Elena Beatriz García Cruz
94
5 5
Inspec COD EstimadoTamaño Negocio 1.5 0 0 0 0.8 0
0.8 0 0
EstimadoTamaño Datos 10 1 1 0 0 0 0 8 0
Programar EstimadoTamaño Datos 8 0 0 0 0 0 0 8 0
Inspec DLD EstimadoTamaño Datos 1 0.5
0.5 0 0 0 0 0 0
Inspec COD EstimadoTamaño Datos 1 0.5
0.5 0 0 0 0 0 0
EstimadoError 56.5 42 1 1 1.3 2
1.3 8 0
EstimadoError Interfaz 14 12 0 1 0 1 0 0 0
Programar EstimadoError Interfaz 12 12 0 0 0 0 0 0 0
Inspec DLD EstimadoError Interfaz 1 0 0 0.5 0
0.5 0 0 0
Inspec COD EstimadoError Interfaz 1 0 0 0.5 0
0.5 0 0 0
EstimadoError Negocio 32.5 30 0 0 1.3 0
1.3 0 0
Programar EstimadoError Negocio 30 30 0 0 0 0 0 0 0
Inspec DLD EstimadoError Negocio 1 0 0 0 0.5 0
0.5 0 0
Inspec COD EstimadoError Negocio 1.5 0 0 0 0.8 0
0.8 0 0
EstimadoError Datos 10 0 1 0 0 1 0 8 0
Programar EstimadoError Datos 8 0 0 0 0 0 0 8 0
Inspec DLD EstimadoError Datos 1 0 0.5 0 0
0.5 0 0 0
Inspec COD EstimadoError Datos 1 0 0.5 0 0
0.5 0 0 0
Integracion del Sistema V2 18 8 8 0 2 0 0 0 0
Integrar el sistema 16 8 8 0 0 0 0 0 0
Ejecutar las pruebas del sistema 2 0 0 0 2 0 0 0 0
Sistema Iteracion 3 397.3 42 48 10
6 39 19.5 91
51 1