Desarrollo de Sistema de Información utilizando el …148.206.53.84/tesiuami/UAMI16774.pdf · Conjunto de las diferentes fases o etapas sucesivas que tiene una acción o un fenómeno

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



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



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



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).



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



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]



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.



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.



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)



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


Descripción de la Prueba 1. Ejecutar Aplicación.java



4. Presionar enter.



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.



12

Número/Nombre de la Prueba 3er caso de Prueba





4. Presionar enter



Datos x, y.

Resultados Esperados Beta0 = -23.92 ; Beta1 = 1.4309; rx,y = 0.9631; r^2 = 0.9276;

yk = 528.4294


r^2 = 0.9275; yk = 528.4293.

Número/Nombre de la Prueba 4to caso de Prueba





4. Seleccionar Continuar



Datos x, y.

Resultados Esperados Beta0 = -4.604 ; Beta1 = 0.1401; rx,y = 0.9480; r^2 = 0.8988;

yk = 49.4994


r^2 = 0.9275; yk = 49.4993.



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.


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.



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.



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.



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.



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.



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.



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



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.



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.



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?)



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.



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%



25

¿Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados

en las revisiones, compilaciones y pruebas?



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.



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.



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?



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.



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.



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.



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



33

Flujo detallado del TSP

Un proyecto que está siendo desarrollado usando TSP, puede ser inicializado y/o finalizado en

cualquier fase.



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.



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]



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.



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



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:



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


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


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:



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


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



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


Implementation Manager Jesica Beltrán Sánchez

Diego Armando Zamora Ramos

Planning Manager Alan García Zamora


Process Manager Alan García Zamora


Quality Manager Diego Armando Zamora Ramos




42

Support Manager José Williams Alvarado Suárez


Test Manager Jorge Alberto García López


Ver forma ROLE

Al terminar esta junta, los resultados obtenidos fueron los siguientes:


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


Agenda


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



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



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:



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.



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:



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



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



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:


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


Agenda


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



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



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


Recuperar datos

Estimar Tiempo

Estimar Tamaño

Estimar Error


Análisis

Reportes

Integración



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.



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



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:



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.



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



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



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


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


Administrador de Calidad

Seguimiento a las metas cuantitativas de calidad

Estándares de calidad

Decisiones de calidad

Inspecciones por colegas


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.


Administrador de Pruebas

Realizar los planes de prueba

Responsable de la plataforma de pruebas, software, estándares, etc.



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? [ ]



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



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



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



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.



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



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:



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.



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.



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.



68

Ventana que muestra una lista de todos los proyectos dados de alta en el sistema



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.



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.



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.



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

http://definicion.de/ingenieria-de-software/

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

http://html.rincondelvago.com/personal-software-process-psp.html

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/pelaez_r_jj/capitulo2.pdf

http://repository.lasallista.edu.co/dspace/bitstream/10567/696/1/Implementacion_metodologia_PSPTSP.pdf

http://repository.lasallista.edu.co/dspace/bitstream/10567/696/1/Implementacion_metodologia_PSPTSP.pdf

http://alejandrogomeztsp.blogspot.mx/

http://es.wikipedia.org/wiki/JavaServer_Faces

http://es.wikipedia.org/wiki/Spring_Framework

http://es.wikipedia.org/wiki/Hibernate

http://en.wikipedia.org/wiki/AppFuse



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



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





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



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



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



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.



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)



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







Overhead semanal



Elena *- - - - - - - 20

Jesica 10



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







Overhead 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







Overhead 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



81

Marco 36.9 6.4 7.0 4 14:18 1:00 74.49 15







Overhead 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







Overhead 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



82

Valor






Overhead 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



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



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



y el usuario ha presionado una opción de aceptar



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


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



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.



86

Tareas correspondientes a la primer iteración:



87

Tareas correspondientes a la segunda iteración:



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



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



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



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



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



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



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

Documents

Desarrollo de Sistema de Información utilizando el …148.206.53.84/tesiuami/UAMI16774.pdf · Conjunto de las diferentes fases o etapas sucesivas que tiene una acción o un fenómeno