ppeeerrrssso oonnaaalll w sssooffftttwwwa aar rreee e ...148.206.53.233/tesiuami/uami15680.pdf · 1...

1

DDII VV II SS II ÓÓ NN DDEE CC II EE NNCC II AASS BB ÁÁSS II CC AASS EE II NNGGEE NNII EE RR ÍÍ AA

PROYECTO TERMINAL

PPPeeerrrsssooonnnaaalll SSSoooffftttwwwaaarrreee PPPrrroooccceeessssss &&& TTTeeeaaammm SSSoooffftttwwwaaarrreee PPPrrroooccceeessssss

SSSiiisssttteeemmmaaa PPPuuunnntttooo dddeee VVVeeennntttaaa aaalll DDDeeetttaaalllllleee

LICENCIATURA EN COMPUTACIÓN

PRESENTA

PEDRO AGUILAR CAYETANO MATRICULA 206214308

Asesor.

Luis Fernando Castro Careaga

26 de Enero de 2011

Luis Fernando Castro Careaga

Prof. Dep. de Ing. Eléctrica

Pedro Aguilar Cayetano

Presentador del Proyecto

Personal Software Process & Team Software Process

2

Tabla De Contenido

1. Presentación ..........................................................................................................................................................4

2. Presentación PSP ..................................................................................................................................................5

2.1 Reporte Final ......................................................................................................................................................8

2.1.1 Análisis de la exactitud de la estimación del tamaño. .....................................................................................8

2.1.2 Análisis de la exactitud de estimación del tiempo. ........................................................................................12

2.1.3 Análisis de defectos de rendimiento. .............................................................................................................17

2.1.4 Análisis de calidad. ........................................................................................................................................29

3. Presentación TSP ................................................................................................................................................35

3.1 ¿Por qué contar con un proceso de software? ...................................................................................................35

3.2 ¿Qué es TSP? ....................................................................................................................................................35

3.3 Estrategia de TSP..............................................................................................................................................37

3.4 Ciclo TSP ..........................................................................................................................................................37

3.4.1 Lanzamiento ..................................................................................................................................................37

3.4.2 Requerimientos ..............................................................................................................................................38

3.4.3 Diseño de alto nivel .......................................................................................................................................38

3.4.4 Implementación .............................................................................................................................................38

3.4.5 Integración y pruebas.....................................................................................................................................38

3.4.6 Post Mortem ..................................................................................................................................................38

3.5 El lanzamiento ..................................................................................................................................................39

3.5.1 Junta 1 ............................................................................................................................................................40

3.5.2 Junta 2 ............................................................................................................................................................40

3.5.3 Junta 3 ............................................................................................................................................................41

3.5.4 Junta 4 ............................................................................................................................................................42

3.5.5 Junta 5 ............................................................................................................................................................42

3.5.6 Junta 6 ............................................................................................................................................................42

3.5.7 Junta 7 ............................................................................................................................................................42

3.5.8 Junta 8 ............................................................................................................................................................42

3.5.9 Junta 9 ............................................................................................................................................................43

3.6 Post Mortem .....................................................................................................................................................43

4. Proyecto ..............................................................................................................................................................44

4.1 Introducción ......................................................................................................................................................44

4.2 Sistema de punto de venta POS Detallista ........................................................................................................44

5. Lanzamiento del proyecto ..................................................................................................................................45

5.1 Juntas ................................................................................................................................................................45

5.1.1 Junta 1 ............................................................................................................................................................45

5.1.10 Post Mortem ................................................................................................................................................46

5.1.2 Junta 2 ............................................................................................................................................................46

5.1.3 Junta 3 ............................................................................................................................................................47

5.1.4 Junta 4 ............................................................................................................................................................48

5.1.5 Junta 5 ............................................................................................................................................................48

5.1.6 Junta 6 ............................................................................................................................................................49

5.1.7 Junta 7 ............................................................................................................................................................49

5.1.8 Junta 8 ............................................................................................................................................................49

5.1.9 Junta 9 ............................................................................................................................................................50

6 Seguimiento del proyecto ....................................................................................................................................50

6.1 Inspecciones en TSP .........................................................................................................................................50

6.2 Documentos para un proyecto TSP ..................................................................................................................50


3

6.3 Proceso Check In ..............................................................................................................................................51

6.4 Seguimiento semanal del proyecto ...................................................................................................................51

6.4.1 Semana 1 A 8 .................................................................................................................................................51

6.4.2 Semana 9 .......................................................................................................................................................52

6.4.3 Semana 10,11 y 12 .........................................................................................................................................53

6.4.4 Semana 13 .....................................................................................................................................................54

6.4.5 Semana 14 .....................................................................................................................................................55

6.4.6 Semana 15 .....................................................................................................................................................55

6.4.7 Semana 16 .....................................................................................................................................................56

6.4.8 Semana 17 .....................................................................................................................................................57

6.4.9 Semana 18 .....................................................................................................................................................57

6.4.10 Semana 19 ...................................................................................................................................................58

6.4.11 Semana 20 ....................................................................................................................................................59

6.4.12 Semana 21 ...................................................................................................................................................59

6.4.13 Semana 22 ...................................................................................................................................................60

6.4.14 Semana 23 ...................................................................................................................................................60

6.4.15 Semana 24 (Post Mortem del proyecto) ......................................................................................................61

7 Reporte resumen del proyecto .............................................................................................................................62

7.1 Análisis del calendario de trabajo .....................................................................................................................62

7.2 Análisis de recursos ..........................................................................................................................................62

7.3 Análisis de tamaño ............................................................................................................................................62

7.4 Análisis de productividad .................................................................................................................................62

7.5 Análisis de defectos ..........................................................................................................................................62

7.6 Análisis de rendimiento ....................................................................................................................................64

8. Conclusiones.......................................................................................................................................................67

9.Anexo ..................................................................................................................................................................69

10. Bibliografia .......................................................................................................................................................69


4

1. Presentación

En el presente documento se detallan los reportes de los cursos de Personal Software Process

(PSPSM

) y Team Software Process (TSPSM

), los cuales están considerados dentro de la

formación académica de la Universidad Autónoma Metropolitana unidad Iztapalapa del nivel

licenciatura. Estos como parte de las opciones de Proyecto Terminal I, curso de PSPSM

, y

Proyecto Terminal II, el curso de TSP. Por lo que el objetivo principal del documento es

brindarle al lector un panorama general de las actividades realizadas durante el desarrollo de

ambas asignaturas.

La primera parte del documento presenta lo realizado en la asignatura del Proyecto Terminal I,

el cual correspondió a las actividades realizadas en el curso de PSP para Ingenieros, por lo que

al seguir este curso se pudo obtener los elementos fundamentales del proceso industrial de

construcción de Software, buscando la creación de trabajos de calidad a través del mismo

proceso y así obtener y mejorar la forma de construcción de Software, sobre todo como meta

personal a largo plazo.

Para este apartado primero se presenta una breve introducción con la teoría de lo que es el PSP y

posteriormente se integra la parte correspondiente al reporte final del curso de PSP, donde se

hacen análisis de la exactitud de la estimación del tamaño de programas, del tiempo, análisis de

los defectos de rendimiento y un análisis de la calidad. Todos estos con base en la información

generada durante el curso de PSP y las ocho tareas consideradas en el mismo.

Para la segunda parte se aborda lo correspondiente al curso de TSP, ya que se ha adquirido

cierto conocimiento y habilidad del curso previo, el cual está dentro de la asignatura del

Proyecto Terminal II. Para lo cual se conforma un equipo de trabajo y se aborda un taller de

TSP, el cual tiene el propósito de iniciar con el desarrollo de un proyecto de Software, primero

organizando el lanzamiento del proyecto a través de un conjunto de nueve juntas, las cuales

tienen como objetivo establecer un conocimiento y entendimiento común de la problemática por

parte del equipo, acerca de las necesidades y alcances del proyecto, así como establecer las

metas del equipo y el plan de trabajo para la construcción e implementación del mismo. Una vez

establecido lo anterior se da marcha a la construcción del proyecto teniendo en cuenta tanto la

metodología seguida en el PSP como los elementos establecidos en las juntas de lanzamiento

del TSP con lo cual se busca obtener un producto de calidad


5

2. Presentación PSP El software hoy en día lo encontramos en la mayoría de las actividades humanas, como los sistemas

militares, de negocio y de gobierno, por esta razón el costo, tiempo de desarrollo y calidad del

software ahora es un interés crítico dentro de los negocios.

Cuando se plantea la realización de un proyecto de Software, con frecuencia los compromisos del

mismo, en ocasiones, no son realistas debido a diferentes factores como que los proyectos son

grandes y en consecuencia son más difíciles de controlar o se han adquirido compromisos que

requieren de una pronta conclusión, etcétera. Para ser efectivos, los equipos necesitan liderazgo que

los guie exitosamente y realizar una administración adecuada.

En la actualidad se requieren sistemas de software más grandes, más complejos, de calidad y más

seguros en tiempos predecibles. El PSP proporciona el conocimiento y habilidad que los

desarrolladores necesitan para trabajar dentro de un equipo auto dirigido TSP.

El PSP fue definido por Watts S. Humphrey siendo parte del Software Engineering Institute (SEI)

en la Carnegie Mellon University.

La calidad de un sistema de software puede ser algo subjetivo pero en general está determinada por

la calidad de sus componentes más deficientes, es gobernada por el individuo que lo desarrolla y

depende del proceso utilizado para desarrollarlo y mantenerlo. Es decir la clave para la calidad es la

habilidad, compromiso y disciplina de proceso personal individual del desarrollador

El PSP es un proceso personal para desarrollar software o para hacer cualquier otra actividad

definida. Proporciona un marco de trabajo de medición y análisis para caracterizar y administrar el

trabajo personal. También es un proceso definido ayuda a mejorar el desempeño personal.

El PSP propone a los ingenieros de software una forma disciplinada de estructurar su trabajo

personal.

El proceso PSP consta de métodos, formularios y procedimientos que ayudan a los

ingenieros de software a planificar, medir, y gestionar su trabajo.

El PSP sirve para trabajar con cualquier lenguaje de programación y metodología de diseño

y contempla la mayoría de los aspectos de los trabajos de desarrollo de software, como

especificación de requerimientos, pruebas, definición de procesos, y eliminación de

defectos.

Al usar el PSP, el objetivo del proceso debería ser obtener productos sin defectos y dentro de

los plazos y costos previstos.

Utilizado en conjunción con el Team Software Process (TSP), el PSP permite lograr

efectivamente estos objetivos.


6

El proceso PSP está diseñado para uso individual, basado en prácticas de software industriales en

pequeña escala. Demuestra el valor de utilizar procesos definidos y medidos.

El PSP se introduce en seis pasos compatibles y progresivos. El estudiante escribe uno o más

programas del tamaño de un módulo en cada paso; posteriormente recolecta y analiza datos de su

trabajo; y finalmente usa los resultados para mejorar su desempeño personal.

La figura siguiente muestra las fases que se necesitan para el aprendizaje revisa y comprende los

Guiones; en las cuales se establece la lección de aprendizaje a la tarea correspondiente; una vez que

se ha comprendido la lección el alumno debe de realizar la tarea correspondiente. De aquí deberá de

o planeación de su tarea. Mediante la etapa de diseño se podrá comprender mejor los requerimientos

del sistema, de esta manera la Codificación será más rápida y se podrá obtener una compilación

libre de errores correcto funcionamiento de la aplicación. En el PM (Post Mortem) se deberá hacer

el análisis del proceso que se llevo. La bitácoras se Usan para registrar tiempos y anotaciones de la

etapa de Diseño, compilación y PM. El resumen del proyecto se deberá realizar para que el Asesor

revise los resultados obtenidos

El aprendizaje PSP se divide en 3 versiones: PSP0, PSP1 y PSP2, complementadas con una serie de

tareas. PSP0: Establece una referencia del desempeñoR1

Tarea 1:

Programa para calcular la media y la desviación estándar de un conjunto de n números reales1.

1 Tarea 1 ver Archivos Anexos/PSP/Tareas/Tarea 1

R1 Proceso PSP0, véase archivo Anexo/PSP/MaterialSEI/Sesion1/L1 Introduction to PSP.ppt


7

Tarea 2:

Programa para contar (en LOC’s) el:

• Tamaño total de un programa.

• Tamaño total de cada una de las partes de un programa (clases, funciones procedimientos).

• El número de elementos (o métodos) en cada parte2

PSP1: Hacer planes sobre tamaño, recursos y tiempo.R2

Tarea 3:

Programa para:

Calcular los parámetros de la regresión lineal 0 y 1, los coeficientes de correlación rx,y y

r2 para un conjunto de n parejas de datos.

Dado un estimado, xk calcule una predicción mejorada, yk donde:

Yk = 0 + 1 xk 3

Tarea 4:

Programa para calcular los rangos de tamaño relativos para establecer rangos muy pequeños,

pequeños, medianos, grandes y muy grandes utilizando la desviación estándar4.

PSP2 Practicar la administración de defectos y el rendimiento (yield). R3

Tarea 5:

Programa para integrar numéricamente una función usando la regla de Simpson5.

Tarea 6:

Programa para encontrar el valor de x para el cual integrar la función t de 0 a x dando el resultado

de p6. Tarea 7:

Programa para

• Calcular la correlación entre dos conjuntos de números x y y

• Calcular la significancia de esa correlación

• Calcular los parámetros de regresión lineal 0 y 1 para un conjunto de n parejas de datos

• Dado un estimado, xk calcule una predicción mejorada, yk donde

yk = 0 + 1 xk • calcule el intervalo de predicción del 70% para ese estimado

7

Tarea 8:

Programa para calcular los parámetros de estimación de regresión múltiple de tres variables

( 0, 1, 2, 3).8 Los resultados obtenidos durante el proceso, serán usados para responder las

siguientes preguntas como parte del Reporte Final PSP.

2 Tarea 2 ver Archivos Anexos/PSP/Tareas/Tarea 2 3 Tarea 3 ver Archivos Anexos/PSP/Tareas/Tarea 3 4 Tarea 4 ver Archivos Anexos/PSP/Tareas/Tarea 4 5 Tarea 5 ver Archivos Anexos/PSP/Tareas/Tarea 5 6 Tarea 6 ver Archivos Anexos/PSP/Tareas/Tarea 6 7Tarea 7 ver Archivos Anexos/PSP/Tareas/Tarea 7 8 Tarea 8 ver Archivos Anexos/PSP/Tareas/Tarea 8 R2

Proceso PSP1, véase archivo Anexos/PSP/MaterialSEI/Sesion3/Using PSP1.ppt R3

Proceso PSP2, véase archivo Anexos/PSP/MaterialSEI/Sesion5/Using PSP2.ppt


8

2.1 Reporte Final

Después de haber realizado el curso de PSP y concluido con todas las tareas establecidas en el

mismo se realizo el siguiente reporte final donde se realizan los análisis correspondientes en

base a los datos recabados.

Análisis de la exactitud de la estimación del tamaño

Compare el reporte intermedio línea base para la exactitud de estimación de tamaño con los

programas posteriores al reporte. ¿Cuánto cambió su exactitud de estimación de tamaño?

¿Por qué?

En el reporte intermedio se obtuvo el error total acumulado del análisis de los programas 2-

4:

No. Programa Tamaño

Estimado

Tamaño real Error total

acumulado

2 150 189 31.0% por debajo

3 186 289 35.6% por debajo

4 202 225 10.3% por debajo

NOTA: tomando en consideración el error absoluto

En los programas (5-8) posteriormente realizados se obtuvo el error total acumulado:

No. Programa Tamaño

Estimado

Tamaño real Error total

acumulado

5 164 162 1.2 % por arriba

6 180 189 4.7% por debajo

7 508 521 2.5% por debajo

8 477 552 13.6% por debajo


En general podemos observar que la exactitud de la estimación del tamaño del programa

siempre estuvo por debajo del tamaño real, sin embargo podemos observar que el tamaño de

la estimación en los primeros programas (2.-4) se encuentran en promedio un 25.6 % por

debajo del tamaño real. Posterior mente en los programas (5-8) se encuentra en promedio

un 4.9% por debajo del tamaño real.

Es decir la exactitud de la estimación del tamaño de los últimos programas (5-8) mejoro ya

que al introducir la fase de revisión de diseño, nos queda más claro lo que debe de hacer

cada programa y así podernos aproximar mejor el tamaño real del programa.


9

¿Qué tan frecuentemente estuvo mi tamaño real del programa dentro de mi intervalo

estadístico de predicción del 70%?

No. Programa

Intervalo de

predicción

del 70%/UPI

Intervalo de

predicción

del 70%/LPI

Tamaño

Estimado(A&M)

Tamaño real

(A&M)

Prog. 5 189.88 138.10 164 162

Prog. 6 146.62 42 94.32 103

Prog. 7 213.84 122.10 167.97 181

Prog. 8 310.41 210.32 260.37 387

Tabla.UPI & LPI de tamaño

Grafica: UPI & LPI de tamaño

Podemos Observar en la tabla y grafica anterior que en cada uno de los programas

realizados el tamaño real (A&M) se encuentra dentro del intervalo de predicción UPI &

LIP (70%) a excepción del último en donde se presenta un incremento considerable.

¿Tengo una tendencia a agregar/no considerar objetos completos?

En términos Generales si tengo una tendencia a agregar objetos completos ya que en la

realización de los programas que realice en PSP los objetos que se estimaron fueron los

necesarios y suficientes para realizar todas las tareas cubriendo los requerimientos

presentados.

0

50

100

150

200

250

300

350

400

450

prog5 prog6 prog7 prog8

UPI

LPI

REAL


10

¿Tengo una tendencia a juzgar equivocadamente el tamaño relativo de objetos?

No Tengo una tendencia equivocadamente del tamaño relativo del objeto, dada a que a lo

largo de la realización de los 8 programas el tamaño estimado del objeto se presento por

debajo del real, aunque en general no varía mucho, es decir se tiene una idea de que tan

grande debe de ser el programa que se va a desarrollar y lo podemos observar en la grafica

sig. Que corresponde al error estimado del tamaño de cada uno de los programas realizados.

Grafica Error Estimado del tamaño.

¿Necesito calcular el rango de tamaño relativo usando mis datos de objeto históricos?

¿Puedo?

No es necesario calcular el rango de tamaño relativo usando mis datos de objeto histórico.

Sin embargo Si puedo hacerlo utilizando mis datos históricos y observando el tamaño del los

objetos para cada una de las tareas, considerando de que categoría eran los objetos y cuál era

su tamaño es decir; si eran Very Small, Small, Medium, Large y Very Large ya que

dependiendo de la categoría, el tamaño era distinto para cada objeto y a partir de este

análisis poder determinar cuál sería un posible tamaño para un objeto dependiendo de la

categoría, basándome en los datos anteriores. Esto funcionara ya que los datos que se

utilizarían para determinar el tamaño de un objeto serian mis datos reales con los cuales

trabaje durante este proceso.


11

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

Considero que mi estimación de tamaño en un principio no fue muy buena pero, ya para las

últimas tareas fue mejorando y podemos decir que la exactitud de la estimación del tamaño

se encuentre en ± 20 LOCS en cada una de mis estimaciones.

¿Cómo puedo modificar mi proceso para cumplir esa meta?

Se puede modificar el proceso dedicándole más tiempo a la fase de planeación y diseño,

dado a que si comprendemos lo que se debe de realizar podemos estimar un tamaño real

adecuado para el programa a desarrollar.


12

Análisis de la exactitud de estimación del tiempo

Compare el reporte intermedio línea base para la exactitud de estimación de tiempo con los

programas posteriores al reporte. ¿Cuánto cambió su exactitud de estimación de tiempo?

¿Por qué?

En el reporte intermedio se obtuvo el error total acumulado del análisis de los programas 1-

4:

No. Programa Tiempo

Estimado

Tiempo real Error total

acumulado

1 155 240 35.4% por debajo

2 220 357 38.38% por debajo

3 360 355 1.40% por arriba

4 189 155 22.00% por arriba


En los programas (5-8) posteriormente realizados se obtuvo el error total acumulado:

No. Programa Tiempo

Estimado

Tiempo real Error total

acumulado

5 312 302 3.31 % por arriba

6 138.4 307 55.0% por debajo

7 305.8 336 8.90 % por debajo

8 433 495 12.5% por debajo


Podemos observar que la exactitud de la estimación del tiempo de desarrollo de los

programas estuvo por debajo del tiempo real, sin embargo podemos decir que el tiempo de

la estimación en los primeros programas (1.-4) se encuentran en promedio un 12.6% por

debajo del tiempo real. Posterior mente en los programas (5-8) se encuentra en promedio

un 18.27 % por debajo del tiempo real. Y en general a lo largo de la realización de las 8

tareas se tuvo en promedio un 8.5% por debajo del tiempo real.


13

Es decir la exactitud de la estimación del tiempo de los últimos programas (5-8) aumento

ya que empezamos a introducir fases de revisión (Diseño, código) y a utilizar el método C,

B y A en los que el tiempo es calculado por medio del numero de métodos, en comparación

a los primeros programas en donde no se tenía muy clara el tiempo de desarrollo de cada

uno de los métodos dependiendo de su tipo (Cálculos, Datos, I/O, etc...).

Grafica: Estimación de Error de tiempo


14

¿Qué tan frecuentemente estuvo mi tiempo de desarrollo real dentro de mi intervalo

estadístico de predicción del 70%?

No. Programa Intervalo de

Predicción

del 70%/

UPI

Intervalo de

Predicción

del 70%/ LPI

Tiempo

Estimado

Tiempo real

Prog. 5 NA NA 312 302

Prog. 6 251.97 24.82 138.4 307

Prog. 7 420.21 191.32 305.77 336

Prog. 8 557 308.89 433.21 495 Tabla.UPI & LPI de Tiempo

Grafica: UPI & LPI de Tiempo

Observamos por la tabla y la grafica anterior que en el programa 5 no se tiene un intervalo

de predicción dado a que en ese momento se estaba utilizando el método D, posteriormente

al programa 6 no se presenta el tiempo de desarrollo real dentro del intervalo estadístico de

predicción del 70% dado a que se realizo una mala estimación, posterior mente los sig

programas si se presentan dentro del intervalo de predicción del 70%.

0

100

200

300

400

500

600

prog6 prog7 prog8

UPI

LPI

REAL


15

¿Mi productividad es estable? ¿Por qué si o por qué no?

Podemos observar que mi productividad se presenta estable a lo largo del desarrollo de los

programa (Intervalo de 30 a 40 Loc´s/Hora), salvo en el programa 6 que decae

aproximadamente a 20 loc´s/Hora debido a una mala estimación de tiempo .

Grafica: Productividad

En promedio a lo largo de la realización de los 8 programas se tiene una producción de

34.83 Loc´s/Hora.

¿Cómo puedo estabilizar mi productividad?

Considero que mi productividad se puede estabilizar un poco mas realizando una buena

planeación con respecto al tamaño del programa y a un buen estimado del tiempo de

desarrollo en cada uno de ellos. Dado a que el estimado de tamaño y tiempo de desarrollo

de cada uno de los programas son factores muy importantes que determinan la

productividad.


16

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

Considero que mis estimados de tiempo fueron poco afectados por la calidad de mis

estimados de tamaño. Mi estimado de tiempo se ve afectado además por el llenado de

Formas, el tiempo dedicado a la revisión y corrección de defectos (Fase de Revisión de

Diseño y Codificación).

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

Una forma de saber cuánto tiempo se va a invertir en el programa es tener en cuenta los

tiempos históricos de los programas anteriores, con esto obtenemos valores que nos

determinan que tendencia se sigue durante todos los programas, los valores antes

mencionados los podemos ver en el coeficiente R2 el cual debe ser mayor a 0.9, con esto los

datos que se estimen van a estar más próximo con el tiempo real.

Una meta de estimación de tiempo para mi es realizar cada uno de los programas en un

Rango de tiempo de 20 minutos entre el tiempo real y el tiempo estimado.

¿Cómo puedo modificar mi proceso para cumplir esa meta?

Considero que es necesario en la fase de planeación y diseño tomar en cuenta el tamaño

del programa con respecto al dato histórico de la productividad en ese momento, para

poder estimar un tiempo de desarrollo adecuado.


17

Análisis de defectos de rendimiento

¿Qué tipo de defectos introduzco durante el diseño y la codificación?

La tendencia a cometer errores ha disminuido considerablemente en comparación con los

primeros programas.

Grafica: defectos Inyectados en Diseño


18

Grafica: defectos Inyectados en Codificación

Tabla. Tipo de defectos Introducidos en Diseño y Codificación


19

Podemos observar que a lo largo del desarrollo de los 8 programas en la fase de Diseño se

introdujo defectos de tipo de Sintaxis (20), Asignación (40), Interfaz (50), Dato (70) y

Función (80).

El tipo de defecto mayor introducido a lo largo del desarrollo del proceso corresponde al

tipo de Interfaz (50).

En la fase de Codificación se introdujo defectos de tipo de Sintaxis (20), Asignación (40),

Interfaz (50) y Función (80).

El tipo de defecto mayor introducido a lo largo del desarrollo del proceso es de tipo de

Sintaxis (20).

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

encontrados en las revisiones, compilaciones y pruebas?

Las revisiones me permitieron mitigar un gran número de defectos y así mis programas

llegaban a las fases posteriores con revisiones y con menos errores.

Grafica: Defectos Inyectados en Diseño


20

Grafica: defectos Removidos en revisión de Diseño

Grafica: Defectos inyectados en Codificación


21

Grafica: Defectos Removidos en Revisión de Código

Podemos apreciar que antes de introducir la fase de Revisión de Código se llegaba a fases

posteriores con un gran número de defectos, posteriormente al introducir la fase de Revisión

de Código la mayoría de defectos introducidos en la fase anterior (Codificación) se pueden

detectar y corregir, así se puede llegar a las siguiente fases con menores defectos lo cual

disminuye el tiempo de cada una de ellas considerablemente.


22

Grafica: Defectos Removidos en Compilación

Grafica: Defectos Removidos en Pruebas


23

Apreciamos que al llegar a fases finales como compilación y pruebas los defectos

encontrados y corregidos son mínimos dado a que las fases posteriores de revisión (Revisión

de Diseño y Código) son de gran ayuda para mitigar un gran número de defectos y así obtener

un producto de gran calidad.

.

Grafica: porcentaje de Defectos Removidos por fase


24

¿Qué tendencias son aparentes en los defectos totales por unidad de tamaño?

Grafica: Total de Defectos

El número de Defectos en la primera mitad del curso fue muy elevado, pero cuando se

introdujeron las revisiones de diseño y código el número de defectos bajo considerablemente,

la tendencia que se ve en la grafica anterior; por otro lado si se anexan revisiones personales

adicionales (check list) que permitan tener un menor número de defectos, obtendríamos una

mayor calidad en los programas.

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

Las Pruebas Unitarias se realizan después de las revisiones de Diseño, Código y de la fase de

Compilación, por lo tanto el número de defectos encontrados y eliminados en esta fase son

mucho menor que en las fases anteriores a esta, esto debido a que las revisiones de Diseño,

Código y Compilación ya eliminaron la mayor parte de los errores.

La fase de Compilación elimina defectos en un tiempo muy corto, por el contrario en la Revisión

de Diseño, el tiempo es mayor.


25

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

Grafica: Tasa de Revisión.

Como se muestra el DLDRRvwRate y el CRRvwRate son muy buenos para el buen

desarrollo del software porque se eliminan errores en fases tempranas del desarrollo y no en

fases finales en donde su detección y costo es más compleja.


26

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

Grafica: porcentaje de Defectos Removidos por fase

En general se puede apreciar que si se detectaron varios defectos en revisión de diseño,

revisión de codificación y en compilación, entonces este número de errores se verá afectado

directamente en los defectos que se produzcan en la fase de pruebas. Las revisiones hicieron

que los defectos en compilación y pruebas disminuyeran considerablemente.


27

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

Grafica: Tasa de Revisión DLDR vs Rendimiento

Grafica: Tasa Revisión CR vs Rendimiento.


28

¿Hay una relación entre el rendimiento y A/FR para los programas 5 al 8?

Grafica: Yield vs A/FR

El A/FR es el cociente del costo de valoración entre el costo de fallo, en promedio se tiene un yield

de 80.09 y un A/FR 11.17 i.e cuando se hacen revisiones de alta calidad de valoración de A/FR

quiere decir que se tiene el doble de COQ corresponde respecto al fallos.


29

Análisis de calidad

Compare el reporte intermedio de base para la calidad en las pruebas unitarias con los

programas posteriores al reporte. ¿Cuánto cambió la calidad de los programas entrando a las

pruebas unitarias? ¿Por qué?

Tabla: Densidad de Defectos

Observamos en la tabla anterior que la cantidad de errores introducidos conforme fueron

avanzando en el desarrollo de los programas fueron disminuyendo considerablemente tanto en

compilación como en pruebas , así en los programas finales se llega a obtener cero defectos

en la fase de compilación y pruebas.

Este cambio es posible gracias a la introducción y uso de revisiones de codificación y

diseño. Lo cual hace que los defectos se filtren en etapas tempranas del desarrollo.


30

Grafica: Porcentaje tiempo de Pruebas.

Podemos Observar que el tiempo dedicado a la fase de pruebas disminuyo conforme se

avanzaba en los programas dado a que al llegar a esta fase se tenía un número pequeño de

defectos y podemos decir se tiene gran calidad en el programa.

¿Cómo puedo juzgar la calidad de mi producto final de manera temprana en mi ciclo de

desarrollo?

#Programa Densidad(defectos/KLOC)

prog5 160.49

prog6 97.09

prog7 38.67

prog8 5.17

Tabla: Densidad de defectos (prog 5-8)


31

Observamos que en promedio la densidad de defectos en mis programas 5-8 (uso de check

list), es aproximadamente 75 Def/KLOC.

Es decir por ejemplo si se tiene un programa de 200LOC, introduciremos 15 defectos en el

programa, esto lo podemos saber antes o durante el ciclo de desarrollo del programa.

¿Estoy encontrando mis defectos en las revisiones de diseño y código? ¿Por qué si o por qué

no?



32




33


Si, la gran mayoría de defectos fueron encontrados en las revisiones como puede verse en

las graficas anteriores, y se encontraron en las revisiones porque tome en cuenta los datos

históricos de los errores que más cometía y eso ayudo a identificarlos con mayor facilidad

y disminuirlos en cada uno de los programas posteriores.

¿Cómo puedo hacer más efectivo y eficiente mi proceso?

· Mejorando mis diseños conceptuales

· Mejorando mi planeación

¿Basado en mis datos históricos, ¿cuáles son algunas metas de calidad realistas para mí?

Reducir el número de los errores más comunes.

Dado al análisis realizado anterior podemos decir que al finalizar el proceso se obtiene en

cada uno de los programas un alto grado de calidad dado a que se pudo llegar a la fase

de compilación y pruebas con cero defectos lo cual era la meta al comienzo del

desarrollo de proceso PSP.


34

¿Cómo puedo cambiar mi proceso para cumplir esas metas?

Para mejorar la tasa de defectos, en estos momentos es de 75 Defectos/KLOC, es

necesario dedicar más tiempo a entender los requerimientos del programa pues es lo que

me ha hecho tener defectos muy difíciles de resolver.

Para reducir el número de defectos comunes es necesario agregar validaciones a mi

checklist y dedicar más tiempo cuando lo aplique, pues por aplicarlo rápido no elimine

defectos detectables.

En general creo que el proceso PSP hasta ahora es eficiente, sin embargo yo debo ser más

disciplinado, organizado, paciente en practicarlo y adquirir práctica.


35

3. Presentación TSP

3.1 ¿Por qué contar con un proceso de software?

Hasta hace poco tiempo, la producción de software era realizada con un enfoque

artesanal, a diferencia de un enfoque industrial. Ante la constante presencia de proyectos

fallidos, y con el objetivo de mejorar la calidad de los productos, en los últimos años las

organizaciones introdujeron los métodos de ingeniería de software. A partir de estos, se

formalizó el enfoque de ingeniería de producto para desarrollar software. Factores como la

globalización han obligado a las distintas organizaciones a contar con marcos de trabajo que las

ayuden hacer las cosas de la manera más eficiente. Fue entonces que se incorporó la ingeniería

de procesos al desarrollo de software.

Actualmente existe una gran diversidad de opciones relacionadas con procesos de

desarrollo. Constantemente se escuchan diferentes acrónimos como CMM, CMMI, RUP, ISO,

PSP, TSP, etc., que causan confusión, principalmente debido a la mala interpretación de los

mismos.

Revisemos entonces nuestro proceso de desarrollo TSP, así como los estándares

relacionados.

3.2 ¿Qué es TSP?

Team Software Process (TSP) es un marco para el desarrollo de software que pone igual

énfasis en el proceso, producto y trabajo en equipo. Al igual que PSP, TSP fue propuesto por

Watts Humphrey.

TSP se basa en PSP, y se fundamenta en que el software, en su mayoría, es desarrollado

por equipos, por lo que los ingenieros de software deben primero saber controlar su trabajo, y

después saber trabajar en equipo.


36

TSP le enseña a los ingenieros a construir equipos auto dirigidos y desempeñarse como

un miembro efectivo del equipo. También muestra a los administradores como guiar y soportar

estos equipos.

Se inicia el TSP con juntas de lanzamiento las cuales tienen bien definidas sus objetivos,

al termino de estas juntas, el equipo tiene un plan de tareas robusto para desarrollar el software y

en caso de ser necesario se puede modificar para contar con distintos planes que cubran los

requerimientos del cliente en forma parcial o total con tiempos establecidos para realizar la

entrega final al cliente, entre las tareas más importantes a realizar se encuentran revisiones e

inspecciones de diseño y de código las cuales proporcionan en gran medida la calidad del

producto, en estas juntas también se definen objetivos y metas del quipo

Además se realizan juntas semanales entre todos los miembros del equipo para que cada

uno exponga sus avances realizados durante la semana, sus avances planeados para la siguiente

semana, dudas y sugerencias con respecto al proyecto.

Esta forma de guiar un proyecto es muy útil ya que siempre se sabe si el plan se está

cumpliendo o no y en caso de ser necesario se toman las medidas necesarias para que el plan se

cumpla.

La idea del TSP es que todos los miembros del equipo cumplan con sus tareas, cuando

algún miembro del equipo se atrasa con sus tareas o simplemente no se pueden terminar en el

tiempo establecido por que se subestimo en tiempo o recursos, entonces se pueden suspender

tareas de otros miembros del equipo para que colaboren y se cumpla el plan.

En los casos cuando un miembro del equipo ha finalizado todas sus tareas, debe avisarlo

al líder de proyecto para que este le indique en que otras tareas puede ayudar a los demás

miembros del equipo, después de todo la idea es que todos los miembros del equipo estén

comprometidos con el proyecto y con el equipo.


37

3.3 Estrategia de TSP

• Proveer un proceso sencillo basado en PSP.

• Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento, Estrategia, Plan,

Requerimientos, Diseño, Implementación, Pruebas, Postmortem.

• Establecer medidas estándares para calidad y desempeño.

• Proveer definiciones de roles, y evaluaciones de rol y de equipo.

• Requiere disciplina de proceso.

• Provee guía para manejo de problemas de trabajo en equipo.

Compatibilidad de PSP y TSP con CMM y CMMI se enfocan en la mejora organizacional basada en modelos.

TSP contiene prácticas operativas para el desarrollo de equipos. PSP se enfoca en la mejora a nivel individua

3.4 Ciclo TSP

El proceso TSP básicamente consta de 6 etapas por las que se desarrolla el TSP.

3.4.1 Lanzamiento

Básicamente el lanzamiento es la parte fundamental para el éxito de un proyecto, esto es

debido a que en este punto se asignan los roles del equipo, definen métricas de calidad, se


38

definen los objetivos del equipo así como los de la dirección y del cliente, mejoras al proceso, así

como la planeación del proyecto.

3.4.2 Requerimientos

En esta fase se identifican todos los requerimientos del sistema, mediante entrevistas

plasmadas en documentos, que servirán como referencia para crear una arquitectura y un diseño.

Todo documento será inspeccionado por un grupo del equipo asignado para esta tarea. En esta

etapa se realizan las pruebas del sistema.

3.4.3 Diseño de alto nivel

En esta etapa se define una arquitectura así como el diseño de alto nivel de los módulos

encontrados para el sistema. Se crea el diseño de alto nivel y se inspeccionan los documentos,

también se crean las pruebas de integración

3.4.4 Implementación

En esta fase se desarrollan las técnicas, métricas y estándares usados en el PSP, en esta

fase se crea el diseño detallado, y se procede a la codificación; todo esto se realiza con la ayuda

de estándares y revisiones.

3.4.5 Integración y pruebas

Etapa en la cual se realizan las pruebas desde unitarias, pasando por las pruebas de

integración, y si el sistema lo requiere se realizan las pruebas de sistema.

3.4.6 Post Mortem

Esta etapa es la que funciona para recopilar las métricas y saber si se obtuvieron los

resultados deseados, en esta fase se hacen los ajustes de mejora del proceso para el siguiente

proyecto de desarrollo y se producen evaluaciones del equipo.


39

Fig. 1

Elementos clave de un equipo TSP integrado.

La estructura del TSP proporciona un proceso definido para la gestión, seguimiento y

presentación de informes y progresos del equipo. Su uso en la organización puede construir

equipos auto dirigidos de ese plan y hacer un seguimiento de su trabajo, establecer objetivos, sus

propios procesos y planes.

El lanzamiento es una de las partes más importantes del proceso, ya que es la fase

encargada de crear al equipo de desarrollo. En la Fig. 1, se muestra la estructura de TSP, donde

se muestra que una de las partes más importantes es el PSP, la cual sirve para formar una

disciplina individual, el lanzamiento para además de formar al equipo, crea una disciplina y

ambiente de trabajo para el equipo. Formando así un equipo integrado con disciplina de

administración.

3.5 El lanzamiento

El lanzamiento del TSP es un taller de cuatro días que involucran al equipo y a la dirección.

Participan el asesor del curso y los integrantes del equipo.


40

Fig. 2

Elementos que genera el lanzamiento.

El taller de lanzamiento acelera la construcción del equipo, construye un entendimiento común

del trabajo para establecer acuerdos en cómo realiza el trabajo, compromiso con un plan de

equipo, apoyo de la dirección al plan.(Fig. 2) El taller de lanzamiento se divide en 9 juntas que

se realizan a lo largo de 4 días.

3.5.1 Junta 1

Es aquella en que se les proporciona a los integrantes del equipo TSP los requerimientos

necesarios del proyecto que se desea construir. En esta junta el equipo de trabajo se entrevista

con el cliente, la dirección usualmente describe los productos necesarios y los tiempos en que se

requieren. El equipo debe entender las verdaderas necesidades de la dirección para resolverlas,

para ello se deben de formular suficientes preguntas para entender los objetivos de la dirección.

La junta número uno es guiada por el asesor del curso, los integrantes del equipo se basan en el

conjunto de guías que el TSP ofrece.

3.5.2 Junta 2

La junta 2 tiene dos objetivos. Obtener un acuerdo sobre las metas del equipo y establecer los

roles de los miembros del equipo. La persona que tendrá el rol de líder de equipo, por lo regular

guía al equipo a través del análisis de las metas, con la ayuda del asesor de TSP. Se analizan las


41

metas implícitas pero no establecidas por la dirección. Se acuerdan las metas del equipo,

finalmente, se definen las métricas de las metas. Después de asignar las metas, el líder del

proyecto y el asesor guían la junta para realizar la asignación de los roles.

Los roles que el proceso TSP propone son:

Administrador de la interfaz con el cliente. Es el punto focal para aspectos de

requerimientos y relacionados con el cliente.

Administrador de diseño: Establece los estándares de diseño y guía el trabajo de diseño.

Administrador de implementación: define los estándares de implementación y maneja

los aspectos de implementación.

Administrador de pruebas: Asegura que las situaciones de pruebas sean consideradas

apropiadamente.

Administrador de planeación: Ayuda al equipo a mantener, seguir y reportar el plan y el

estado del plan.

Administrador de procesos: Guía el trabajo de definición de procesos, maneja los PIP's y

revisa los datos del proceso.

Administrador de calidad: Revisa la calidad del proceso y del producto y está pendiente

de las inspecciones.

Administrador de soporte: Asegura que las herramientas de apoyo y ayudas apropiadas

estén disponibles y maneja situaciones de apoyo.

El líder del equipo por lo regular no toma ningún rol del equipo. Las responsabilidades

del líder del equipo son dar liderazgo al equipo, obtener recursos y reportar a la dirección.

3.5.3 Junta 3

El equipo define los productos a ser generados, se acuerda sobre un diseño conceptual de los

elementos del producto, se desarrolla una estrategia de proyecto y se define el proceso de

desarrollo. Con la guía del asesor, el líder del equipo guía a los integrantes del equipo en la

definición de sus productos, también guía para establecer la estrategia de desarrollo, el

administrador de diseño guía el esfuerzo para producir un diseño conceptual y el administrador

de proceso guía al equipo en la definición de su proceso de desarrollo.


42

3.5.4 Junta 4

El equipo desarrolla un estimado detallado del tamaño del producto. Entonces, basándose en su

proceso definido, los miembros del equipo definen las tareas para el trabajo y estiman el tiempo

para cada una, en esta junta con frecuencia el equipo descubre que no puede cumplir las

necesidades de la dirección con los recursos disponibles. Entonces el equipo visualiza planes

alternos con mezclas variadas de recursos, funciones y tiempo disponible.

3.5.5 Junta 5

Se desarrolla un plan de calidad, registrando los datos estimados de introducción de defectos por

cada fase. También se usan datos históricos de rendimiento para estimar los defectos eliminados

por fase. El equipo analiza y acuerda sobre la estrategia y el plan de administración de calidad.

3.5.6 Junta 6

Los miembros del equipo hacen planes personales para cada ciclo del plan, por lo regular de

tres a cinco meses. El administrador de planeación del equipo guía este esfuerzo, bajo la guía del

asesor de TSP, se planea quién manejará cada tarea, cada miembro planea para las tareas

asignadas. El equipo revisa el plan consolidado y re balancea la carga de trabajo de los

miembros del equipo si es necesario.

3.5.7 Junta 7

Se evalúan los riesgos percibidos para el plan, el equipo decide qué riesgos seguir, asignar a las

personas que se harán cargo de administrarlos y cuales planes de mitigación son necesarios.

3.5.8 Junta 8

En esta junta el equipo prepara su junta 9 para la presentación del plan a la dirección. Se realiza

una agenda típica, acerca de lo que se va a presentar a la dirección, que normalmente incluye el

resumen de todos los resultados obtenidos por el equipo a lo largo de los 4 días:

Un breve resumen de las conclusiones de las juntas.

Una revisión del proceso de lanzamiento.

El resumen de las metas del equipo y de la dirección.

Las asignaciones de roles de los miembros del equipo.

La estrategia de desarrollo y el proceso.

El plan y los planes alternos principales.

El plan de calidad.

La evaluación y mitigación de riesgo.


43

3.5.9 Junta 9

El propósito de esta junta es:

Describir el plan del equipo a la dirección.

Contestar las preguntas de la dirección.

Obtener la aprobación de la dirección al plan o a la alternativa seleccionada.

Identificar las acciones necesarias, quién las llevará a cabo y cuándo.

El producto de la junta es por lo regular un plan aprobado o las acciones necesarias para obtener

la aprobación de la dirección.

Figura 3

Características de las juntas del Lanzamiento TSP. La figura muestra las metas que tiene cada junta. Cuyo objetivo es obtener una planeación del

proyecto.

3.6 Post Mortem

El PostMortem del lanzamiento es para consolidar el plan y los datos que se generaron, revisar el

proceso del lanzamiento, producir las formas PIP faltantes, analizar los problemas abiertos y

acordar cómo manejarlos. Los pasos finales del lanzamiento son asignar la responsabilidad del

cuaderno de notas del proyecto (con frecuencia al administrador de proceso), asignar la

responsabilidad para manejar las formas PIP y archivar los datos del lanzamiento en el cuaderno

de notas del proyecto.


44

4. Proyecto

4.1 Introducción

Para llevar a cabo el Proyecto de Investigación II, se eligió un proyecto en el cual se

desarrollara un sistema, en este sistema el objetivo es aplicar los procesos PSP y TSP, ya que

estos procesos son primordiales para el desarrollo de sistemas de calidad.

4.2 Sistema de punto de venta POS Detallista

Grupo Yoli es una empresa líder en el mercado de bebidas refrescantes embotelladas, con sede en

Acapulco Guerrero, la cual siempre se ha caracterizado por ofrecer productos de calidad a todos

sus consumidores.

Grupo Yoli ideo una estrategia de Ventas, la cual consistía en otorgar: computadora,

báscula, lector de código de barras e impresora, a cada establecimiento, donde estos proveen sus

productos. En la computadora se integrara un sistema de ventas, el cual permitirá a los dueños de

los establecimientos automatizarlos.

Con este sistema Grupo Yoli pretende que sus clientes reduzcan el tiempo por cada venta

que realicen, así como mayor facilidad para manejar todos los productos, y con esto aumentar las

ventas, es decir el dueño del establecimiento se debe preocupar solo por vender, dejando que el

sistema lleve un control de sus productos, ventas, inventarios etc.

Con este sistema Grupo Yoli sabrá de forma precisa cuanto producto se está

consumiendo, por cada establecimiento y de esta forma el dueño del establecimiento tendrá

como respaldar lo que en realidad vende de los productos de Grupo Yoli, así como de toda su

mercancía en general.

Aunque no se concreto un trato con la empresa, esta nos otorgo los requerimientos de

dicho sistema, así como ciertas especificaciones, con lo cual pudimos tener un mayor

acercamiento a lo que son las necesidades y tratos con empresas en el mundo del desarrollo del

software. De esta forma se realizo un sistema que cumple con todas las expectativas deseadas del

Grupo Yoli.

Esto llevo al equipo TSP a desarrollar el sistema POS Detallista, un sistema que cumple

con los requerimientos especificados por el cliente, a la vez desarrolla todos los procesos y

cumple con todos los estándares de un sistema de alta calidad, todo esto bajo el Proceso de

desarrollo de Team Software Process (TSP).


45

El sistema POS Detallista debe cubrir las siguientes funcionalidades:

Administración de Productos.

Administración de Ventas.

Administración de Clientes.

Administración de Inventarios.

Administración de Caja.

Administración de Promociones.

Administración de Reportes.

5. Lanzamiento del proyecto

Los integrantes del equipo fueron:

Laura Mafra Corona (LM).

Dulce María Sánchez Suazo (DS).

Aldo Hernández Martínez (AH).

Paulina Valencia Franco (PV).

Perla Berenice Jiménez Moreno (BJ).

Andrés Gómez Godínez (AG).

Alejandro Galavíz Álvarez (AA).

Antonio Nuñez Reyna (AN).

Juan Carlos Guerrero (JC).

Pedro Aguilar Cayetano (PA).

Víctor Hugo Ordoñez González (VO.)

Alondra Caballero López (AC).

El coach de TSP fue:

Mtro. Luis Fernando Castro Careaga

A continuación se presentara la información de lo realizado durante las juntas 9 y el Post

Mortem de lanzamiento TSP, referente al proyecto antes mencionado.

5.1 Juntas

5.1.1 Junta 19

Durante la presente junta se realizó el un taller de repaso de TSP en donde el coach

describió el proceso así como se realizó una revisión de las necesidades de la dirección y

comercialización para el proyecto, presentándolo el mismo coach pero fungiendo como

director y gerente de comercialización.

9 Forma TSP generada en Junta 1, véase archivo Anexos/TSP/proyecto/MTGJunta1.doc


46

Como director presentó las necesidades del negocio para el presente proyecto y

como

Gerente de comercialización expuso los requerimientos deseados para el producto

requerido.

5.1.10 Postmortem de las juntas.

En la junta final que corresponde al lanzamiento, se concluyó que todos los datos

fueron correctamente recolectados, que todas las tareas pendientes fueron finalizadas y

registradas en las formas apropiadas.

También se evaluó y documentó las metas del equipo y al término de esta junta se

obtuvo una forma MTG con el resumen de la misma.

En la junta de postmortem y con todos los datos reunidos, se verificaron las

mejoras, también se identificaron los errores que se cometieron en el lanzamiento, se

crearon PIB´s para establecer los puntos potenciales de mejoramiento para un proyecto

posterior y de esta manera obtener mejores resultados en proyectos futuros.

5.1.2 Junta 210

En esta junta se fijaron las metas establecidas por la dirección identificando aquellas

que metas explicitas e implícitas para posteriormente establecer las metas del equipo. De

las cuales podemos destacar:

Metas de la Dirección:

Sistema que incluya todos los requerimientos establecidos.

Que el sistema sea de calidad y tenga pocos defectos.

El sistema debe ser confiable.

El sistema debe ser de fácil manejo para el usuario.

Metas del Equipo:

Seguir el proceso TSP

Reducir el tiempo de desarrollo del sistema.

Una vez establecidas las metas se procedió a asignar los roles a cada miembro del

equipo.

El resultado de esto se muestra en la siguiente tabla

10 Forma TSP generada en Junta 2, véase archivo Anexos/TSP/proyecto/MTGJunta2.doc


47

Roles de Equipo

Miembro del equipo

(iniciales)

Líder del Equipo VO

Suplente PA

Administrador de Interfaz con el Cliente AG

Suplente AA

Administrador de Diseño AH

Suplente AA

Administrador de Implementación PV

Suplente AN

Administrador de Planeación AC

Suplente LM

Administrador de Proceso BJ

Suplente PA

Administrador de Calidad LM

Suplente JC

Administrador de Soporte DS

Suplente AH

Administrador de Pruebas JC

Suplente BJ

5.1.3 Junta 311

En este apartado se definió el diagrama conceptual, con base en este se definió la

estrategia de desarrollo, se enlistaron los productos a ser generados y el proceso de

desarrollo, generando tanto el plan de proceso como el plan de soporte, así como la

definición e integración del comité de control de cambios.

La estrategia de desarrollo consistió en realizar la implementación del sistema en 5

iteraciones, considerando la realización de interfaces y prototipos en la primera, segunda y

tercera iteración, para la cuarta y quinta iteración se planeo realizar las versiones

definitivas de cada uno de los módulos además se planeo realizar la integración de cada

uno de estos en la quinta iteración.

11

Forma TSP generada en Junta 3, véase archivo Anexos/TSP/proyecto/MTGJunta3.doc


48

5.1.4 Junta 412

En este apartado se determinaron las tareas y sus tamaños, debido a que no se tenía

experiencia en proyectos como este, las tazas que fueron propuestas son las siguientes:

Creación de documentos 0.5 Pág./Hr.

Revisión de documentos 1.0 Pág./Hr.

Revisión de código: 200 LOC/Hr.

Revisión de diseño detallado: 200 LOC/Hr.

Después se determinó el tiempo de dedicación al proyecto por integrante, se asignaron 20

horas de trabajo a 8 integrantes, y a los otros 4 integrantes se asignaron 10 horas, dando un

total de 200 horas de trabajo dedicado al proyecto semanalmente.

De esta manera se genero el plan que se debe de seguir en todo el proyecto, asignando las

tareas a los integrantes del equipo, en función del rol que cada uno de ellos tenía asignado,

así como por habilidades de cada uno de ellos, este plan permite definir las posibles fechas

de terminación para el proyecto.

5.1.5 Junta 513

Esta junta se realizo la revisión de las metas de calidad del equipo, por lo cual fue

encabezada por el administrador de calidad, utilizando las guías de calidad que el proceso

TSP propone.

Una vez establecidas las metas de calidad del equipo se realizo la estimación de defectos

por hora con la siguiente fórmula:

Defectos introducidos(X) = Tiempo en fase(x) * Tasa de introd. de defectos(x)

donde x es la fase

El administrador de calidad encabeza al equipo para evaluar y ajustar el plan para que las

metas se cumplan a lo largo de la realización del proyecto, para ello se evaluaron las

densidades de los defectos y tasas de eliminación resultantes, y se ajustaron los tiempos y/o

rendimientos de cada fase.

12

Forma TSP generada en Junta 4, véase archivo Anexos/TSP/proyecto/MTGJunta4.doc 13



49

5.1.6 Junta 614

En esta junta se hace la asignación de las tareas a todos los miembros del equipo, para que

cada integrante haga una estimación del tiempo va a invertir en cada una de estas tarea.

Para la fase de implementación cada miembro del equipo realizo sus planes a nivel PSP,

realizo un plan de calidad, que al final de la junta el administrador de planeación tuvo que

revisar estos planes propuestos por cada integrante del equipo, evaluando que se

cumplieran los criterios de calidad, obteniendo así un plan consolidado de Trabajo

Completo.

5.1.7 Junta 715

En esta junta se establecieron los riesgos que se pueden generar a lo largo del proyecto,

así como la forma arreglarlos y sacar adelante el proyecto.

Para esto se realizo una lluvia de ideas, primero cada integrante del equipo sugirió algún

riesgo para ser tomado en cuenta, para después evaluar el impacto que pudieran tener en

el calendario de trabajo. Para cada riesgo mencionado por los integrantes del equipo se

juzga la probabilidad de que ocurra Baja, Media, o Alta.

Una vez identificada la probabilidad y el impacto, se asignan los riesgos de mayor

prioridad a los integrantes del equipo, para que cada uno de los integrantes del equipo le

de seguimiento al riesgo que le fue asignado.

5.1.8 Junta 816

En esta junta se preparo la información que se le daría a la dirección explicándoles todo lo

que se realizo en las 7 juntas realizadas previamente. Los puntos que se acordaron

presentar a la dirección fueron los siguientes:

Resultados del Lanzamiento

Metas de la Dirección

Proceso de Lanzamiento

Metas del Equipo

Fechas clave del Proyecto

Diseño Conceptual

Plan Alternativo

Riesgos

14





50

5.1.9 Junta 917

Se presentaron los resultados que el equipo género tanto del plan de trabajo como los

planes alternativos a la dirección, con el fin de convencerlos y poder iniciar con el

proyecto.

6 Seguimiento del proyecto 6.1 Inspecciones en TSP

Como parte del proceso de desarrollo del proyecto tenemos la fase de inspecciones. Una

inspección consiste en realizar un análisis de un producto elaborado, denominamos producto a un

documento, caso de uso, cualquier fase terminada de PSP, en fin, cualquier tarea señalada dentro

de la hoja Task del libro de trabajo, el integrante que elabora dicho producto se le llama productor

quien después de terminar su producto realiza la revisión del mismo como lo señala el PSP. Es

obligación de cada productor enviar su producto a cada inspector asignado dentro la hoja Task y

al administrador de calidad quien programa una cita con los inspectores y productor para realizar

la inspección correspondiente. Cada inspector debe cumplir el tiempo señalado dentro de la hoja

Task para su inspección, en caso de haberla terminado antes debe analizar de nuevo el producto

hasta cumplir dicho tiempo. Las juntas de inspección son guiadas por el administrador de calidad,

durante la junta cada inspector aporta sus conocimientos para mejorar cada producto elaborado, el

productor debe anotar en su bitácora de defectos (forma LOGD del libro de trabajo del equipo) las

observaciones hechas por los inspectores hacia su producto, el administrador de calidad fija un día

con el productor para verificar que efectivamente fueron corregidos los aspectos señalados en la

junta, de no ser así el productor debe corregir nuevamente su producto hasta lograr generar un

entregable de calidad que posteriormente se guardara en el repositorio del equipo.

6.2 Documentos para un proyecto TSP

Durante la fase de planeación del proyecto se acordó elaborar documentos que guíen al equipo,

de forma disciplinada, en el cumplimiento de los requerimientos para éste proyecto.

1. Documento SRC, documento de especificación de requerimientos, proporcionado por el asesor

de proyecto.

2. Documento de procesos y procedimientos del equipo. Es un documento que señala la fecha y

hora de las juntas semanales, y algunas reglas de comportamiento del equipo para trabajar bajo

un ambiente de respeto.

3. Checklist para revisión. Documento que guían al equipo en la revisión de sus productos para la

detección de errores.

4. Guión de inspección. Documento que guía a los inspectores para realizar un estricto análisis de

los productos para atrapar el mayor numero de defectos en ésta fase y alcanzar así las metas de

calidad.

17



51

5. Estándar de nomenclatura, de codificación, de documentación. Son documentos necesarios para

que el equipo elabore productos homogéneos.

6. Documento de Procesos. Son documentos describen la forma en la que se dará seguimiento a

las tareas señaladas en la forma Task, tenemos el documento de procesos de HLD, DLD, de

Pruebas, de check in, por mencionar algunos.

6.3 Proceso Check In (Administración de la configuración)

Una de las labores del administrador de soporte fue la creación de un repositorio para almacenar

todos los documentos que el equipo desarrolló para el proyecto. Tiene una organización en 3

iteraciones, dentro de cada iteración existe una clasificación de cada documento. Cumpliendo con

el proceso TSP, el equipo envía sus entregables al administrador de soporte para que sea él quien

haga check in al repositorio y así llevar un control del trabajo realizado en cada iteración.

6.4 Seguimiento semanal del proyecto

6.4.1 Semana 1 A 8

El trabajo realizado por 12 integrantes del equipo TSP durante el periodo 31-mayo-2010 al 19-

julio-2010 correspondientes a la semana 1 – 8 comprende lo siguiente:

1. Documento de procesos y procedimientos de equipo

2. Documentos de análisis, evaluación y aceptacion de requerimientos

3. Guiones para dar seguimiento al plan elaborado durante el lanzamiento

4. Documentos HLD

5. Checklist en todas sus categorias (HLD, DLD, codificacion, nomenclatura, etc)

6. Documentos de estándares (codificación, nomenclatura, mensajes, etc.)

7. Documentación de todos los Casos de Uso

8. Documentos para la Arquitectura del Sistema

9. Inspecciones de los documentos realizados anteriormente asi como sus correcciones.

RESULTADOS DE EQUIPO, SEMANAS 1- 8

Resumen semanal 1-8 de trabajo – Libro de trabajo TSP


52

ANÁLISIS DE RESULTADOS DE EQUIPO SEMANAS 1 - 8

El equipo realizó el trabajo planeado para éste periodo. Los datos que dio el equipo durante las

juntas semanales reflejan una sobreestimación en el tiempo para realizar ciertas tareas tales

como los documentos de requerimientos y checklist, lo cual se refleja claramente en los datos

de horas actuales = 1417.9 Vs horas planeadas = 1550. Al término de la semana 8 de teníamos

el 55% del valor total generado. Cabe señalar que durante la semana 3 se alcanzó el máximo

valor generado por equipo lo que indica que se teminaron varias tareas en ésta sema y hubo

mayor compromiso por parte del equipo.

No fue sencillo adaptarnos al proceso TSP en cuanto a inspecciones se refiere dado que cada

integrante tenia distintas actividades y muchas veces no coincidiamos en los tiempos

acordados para las inspecciones, sin embargo en cada junta semanal se pidio disposición a

todos los integrantes para realizar satisfactoriamente las actividades.

Es importante mencionar que durante éste periodo el equipo TSP decide cambiar la

Arquitectura SOA propuesta por el asesor de proyecto Ing. Luis Castro por la Arquitectura de

3 capas debido a que es una arquitectura ya conocida por todos los integrantes del equipo,

porque el equipo deseaba cumplir con el 100% de los requerimientos y entregarlo dentro del

tiempo planeado (21 semanas).

6.4.2 Semana 9

En la Semana 9 realizamos las interfaces de todo el Sistema, para la realización de dichas

interfaces no utilizamos un proceso PSP ya que utilizamos el Editor Grafico de Eclipse Yoxos y

lo consideramos como un documento más realizado para el Sistema POS Detallista.


53

En la grafica anterior podemos observar como el Valor Acumulado Planeado hasta la Semana 9

supero al Valor Generado por el Equipo TSP, por lo que se propone dar seguimiento de manera

estricta al documento de procesos y procedimientos del equipo, en el cual se mencionan las

sanciones que recibirá cada integrante del equipo que no cumpla con sus tareas en el tiempo

señalado en el libro de trabajo.

6.4.3 Semana 10,11 y 12

Las Semanas 10, 11 y 12 son las Semanas que acordamos que serian nuestras Vacaciones, por lo

que estas semanas nuestro valor generado planeado es de cero, aunque algunos miembros del

equipo aprovecharon estas semanas para ponerse al corriente ó adelantar algunas tareas.

En la siguiente Grafica se muestra como antes de las Semanas de Vacaciones el equipo llevaba

varias Horas debajo de lo planeado y al concluir la Semana 12 prácticamente nos habíamos

emparejado con las Horas de retraso que llevábamos.


54

6.4.4 Semana 13

Periodo: 23-agosto-2010. El equipo está integrado por 8 miembros. A continuación se detallan las

tareas realizadas durante la semana 13

1. PSP de Configuración Negocio versión 0.1

2. PSP de Productos Negocio versión 0.1

3. Caja Negocio versión 0.1 codificación, inspección de codificación y compilación.

4. Ventas Negocio versión 0.1 DLD, revisión DLD, Inspección DLD y TD.

5. Usuarios Negocio versión 0.1 TD, codificación e inspección de codificación.


RESULTADOS DE EQUIPO, SEMANA 13

Resumen semana 13 de trabajo – Libro de trabajo TSP

ANÁLISIS DE RESULTADOS DE EQUIPO SEMANA 13

El equipo logra avances que superan las tareas y horas planeadas. El valor generado planeado por

semana es de 5.4 y el equipo supera éste valor generando 6.5, fue una semana exitosa dado que el

equipo mostró compromiso para cumplir las metas de la semana 13.


55

6.4.5 Semana 14

Periodo: 30-agosto-2010. A continuación se detallan las tareas realizadas durante la semana 14:

1. Se concluye el PSP de Configuración Negocio versión 0.1

2. Productos Negocio versión 0.2 DLD, DLDR, inspección DLD, TD

3. Caja Negocio versión 0.1 UT

4. Continuación de Ventas Negocio versión 0.1 codificación.

5. Usuarios Negocio versión 1.0 DLD, DLDR, inspección DLD y TD.




ANÁLISIS DE RESULTADOS DE EQUIPO SEMANA 14

Hubo avance porque se conluyo exitosamente las pruebas unitarias de los casos de uso

Configuración, Usuarios, Productos y Caja. Para el caso de Ventas es comprensible que se

continúe trabajando en su realización porque comprende muchas pruebas, validaciones y

dependencias de resultados de otros casos de uso como en el caso de Productos, Departamentos,

Promociones. Sin embargo lo miembros del equipo a cargo de ésta tarea brindan apoyo al equipo

en actividades como inspecciones, verifican que se de seguimiento al documento de pruebas para

que se cumpla el 100% UT.

6.4.6 Semana 15

Periodo: 06-Septiembre-2010. A continuación se detallan las tareas realizadas durante la semana

15:


2. Productos Negocio versión 0.2 se inicia codificación

3. Caja Negocio versión 1.0 DLD, DLDR, inspección DLD y TD, se inicia codificación.

4. Continuación de Ventas Negocio versión 0.1 codificación.

5. Usuarios Negocio versión 1.0 codificación, revisión e inspección de codificación,

compilación.

6. PSP de Configuración Negocio versión 1.0 DLD

7. PSP Acceso Negocio versión 0.1


56



ANÁLISIS DE RESULTADOS DE EQUIPO, SEMANA 15

El equipo supera en 1.6 puntos al valor generado planeado, trabaja 67.2 horas mas de las

planeadas, y registra un valor total generado de 81.1% estos resultados indican que el equipo ha

cumplido las metas individuales planteadas en las juntas semanales, referentes a practicar

disciplinadamente el PSP. Las revisiones e inspecciones nos ayudan a reducir el tiempo de

compilación y pruebas unitarias porque resultan libres de errores.

6.4.7 Semana 16

Periodo: 13-Septiembre-2010. A continuación se detallan las tareas realizadas durante la semana

16:


2. Se concluye Productos Negocio versión 0.2

3. Se concluye Usuarios Negocio versión 1.0

4. PSP Acceso Negocio versión 0.1

5. PSP Instalación automática del Sistema POS Detallista versión 0.1




El equipo trabajo 73 horas mas de las planeadas, obtuvo un valor generado de 5.1 superando en

1.2 puntos al valor planeado, el equipo no ha podido cumplir con la meta de alcanzar el valor

total generado, seguimos por debajo en 6.3 puntos. La razón por la que el equipo trabaja mas

horas de las planeadas es porque se pretende entregar el proyecto antes de las 21 semanas

planeadas.


57

El asesor de proyecto Ing. Luis Castro propone al equipo disminuir el alcance del proyecto para

entregarlo dentro de las 21 semanas planeadas durante el lanzamiento. El equipo acepta la

propuesta y durante la junta 16 acordamos no realizar el manual de usuario, inventarios y el

cobro de 3 clientes a la vez.

6.4.8 Semana 17

En la Semana 17 básicamente se termino con las Versiones 0.1 de la Capa de Negocio y en

algunos casos se comenzó con la Versión 0.2. También nos pusimos de acuerdo para las fechas en

que se realizarían las inspecciones de las Versiones 0.1 de la Capa de Negoción.

En la grafica anterior podemos observar como en la Semana 17 estábamos por arriba de las horas

planeadas, habíamos planeado llevar para la Semana 17 2390horas y acumulamos para esta

semana 2654horas.

6.4.9 Semana 18

En la Semana 18 se empezó con las inspecciones de las Versiones 0.1 de la Capa de Negocio y se

continúo ó se comenzó con la Versión 0.2 de la Capa de Negocio según fue el caso.

En la siguiente grafica podemos observar como en la Semana 18 estábamos 280 horas arriba de

lo que habíamos planeado.


58

6.4.10 Semana 19

En la Semana 19 se termino con las Versiones 0.2 de la Capa de Negocio y se programaron las

inspecciones de las Versiones 0.2 de la Capa de Negocio, se comenzó en algunos casos con las

Versiones 1.0 de la Capa de Negocio.

En la siguiente grafica podemos observar como en la Semana 19 solo generamos 49.9 horas, por

lo que solo quedamos 200 horas por arriba de lo planeado.


59

6.4.11 Semana 20 En la Semana 20 se continuo con las Versiones 1.0 de la Capa de Negocio, algunos integrantes

del equipo terminaron con la ultima Version de la Capa de Negocio y se pusieron a ayudar a ls

miembros del equipo que todavia no terminaban con sus versines de la Capa de Negocio, sto con

la intencon d o retrazar mas el proyecto.

En la siguiente grafica podemos observar como en la Semana 20 solo generamos 40.9 horas por

lo que solo estábamos 100 horas por arriba de lo planeado.

6.4.12 Semana 21

Periodo: 18-Octubre-2010. A continuación se detallan las tareas realizadas durante la semana 21:

1. Se concluye Ventas Negocio versión 1.0

2. Se concluye PSP de Configuración Negocio versión 1.0

3. PSP Instalación automática del Sistema POS Detallista versión 1.0




60


Se pretendía entregar el proyecto en la semana 21 o antes pero ésta meta no se ha cumplido aún

así acumulamos el 99% del valor total generado.

Hemos seguido en forma estricta nuestro PSP y los resultados han sido asombrosos porque

detectamos mas del 75% de los errores de los cuales la mayoría han sido introducidos en la fase

de codificación seguida de DLD.

6.4.13 Semana 22

Periodo: 25-Octubre-2010. A continuación se detallan las tareas realizadas durante la semana 22:

1. Se concluye el PSP de Ventas Negocio versión 1.0





Se ha cumplido con el 100% del valor total generado aunque todavía hay tareas por terminar. Es

necesario mencionar que en las ultimas 2 semanas (21 y 22) el equipo demostró poca disposición

para concluir el proyecto, además de que algunos miembros no asistían a las juntas semanales.

Una parte del equipo se encuentra en la fase de integración y pruebas de integración.

6.4.14 Semana 23

Periodo: 01-Noviembre-2010. A continuación se detallan las tareas realizadas durante la semana

23:

1. Se concluye el PSP de Ventas Negocio versión 1.0





61


Durante ésta semana se realizan pruebas de sistema, siguiendo el Documento de Pruebas.

Se presenta algunos datos registrados al término del proyecto:

Plan Actual

LOC’s Totales 17,456 24,403

Tiempo en HLD 119.0 164.2

Tiempo en DLD 157.6 236.4

Tiempo en codificación 140.0 227.8

Tiempo UT 110.7 113.0

Defectos introducidos HLD 29.8 27.0

Defectos introducidos DLD 118.2 231.0

Defectos introducidos codificación 280.0 261.0

Defectos introducidos compilación 9.0 0.0

LOC’s por hora 5.5 5.4

Los datos anteriores se encuentran dentro de los estándares de calidad que dicta el TSP por ésta

razón consideramos que el proyecto desarrollado considera calidad, además de que cubre el

100% de los requerimientos acordados después de la replaneación, es robusto y fácil de instalar y

usar.

6.4.15 Semana 24 (Post Mortem del proyecto)

Durante el Post Mortem del proyecto, el asesor Ing. Luis Castro Careaga guío al equipo para el

análisis de resultados en el Libro de trabajo del equipo. Se analizaron los siguientes aspectos:

1. Número de horas en la realización del proyecto, el equipo reconoce que hubo una

sobreestimación de algunas tareas especialmente en las primeras 3 semanas de trabajo.

2. La fecha de entrega del proyecto fue 3 semanas después de la fecha planeada debido a un

cambio en la arquitectura del proyecto, incumplimiento de horas de trabajo por parte de los

integrantes de equipo.

3. Cada administrador (integrante del equipo) menciona las metas a su cargo y dice si se

cumplieron o no. Se elaboró el documento Metas del Equipo con información que soporta las

respuestas de cada administrador.

4. Se elaboraron PIP’s mas adelante mencionados.

5. En calidad el equipo cumplió las metas de equipo y con los estándares de calidad del TSP.

Mencionados también en el documento de Metas del Equipo.

Dentro del libro de trabajo del equipo quedan registrados las tareas y tiempo empleado para la

realización del proyecto Sistema POS Detallista.

El equipo concluyo mencionando lo grato que fue haber experimentado la disciplina TSP y

reconoce que dicha experiencia aportará herramientas para producir software de alta calidad.


62

7 Reporte resumen del proyecto

Después de 24 semanas de trabajo, el equipo obtuvo los siguientes resultados:

Análisis y documentación formal (documentos SRS y documento de casos de uso),

requerimientos de la arquitectura, documentos de captación, evaluación respuesta e

integración de nuevos requerimientos.

Análisis y documentación formal para el diseño de alto nivel para las funcionalidades del

proyecto punto de venta al detalle, como: documentos de procedimiento, revisión e

inspección de HLD.

Documentación de diseño detallado para el sistema de punto de venta al detalle, como:

documento de procedimiento, revisión e inspección de DLD.

Documentos de procedimiento y validación de pruebas para el sistema punto de venta al

detalle.

Diseño de pruebas de sistema para el proyectos punto de venta al detalle (PSP).

Para obtener los datos que el proyecto generó, el proceso TSP ofrece la especificación SUMMARY en

la hoja SUMP, el cual tiene como propósito generar un informe de la productividad obtenida al final de

un proyecto TSP, esto permite ofrecer una base para la evaluación y mejora del proceso, así como tener

datos históricos para mejorar la planeación de proyectos futuros.

7.1 Análisis del calendario de trabajoA1

7.2 Análisis de recursos A1

7.3 Análisis de tamaño A1

7.4 Análisis de productividad

A1

7.5 Análisis de defectos

Con respecto a la calidad del proyecto a continuación se presentan las tasas de densidades de

introducción y eliminación de defectos por fase. Se pueden observar los resultados que se obtienen en

el libro de trabajo con la información de la última consolidación realizada, hay que considerar que se

utilizan la unidad número de defectos inyectados y eliminados por hora.

A1 El análisis del trabajo lo podemos consultar en el anexo A, Anexos/TSP/ResumenProyecto/ANEXO_A.docx


63

Figura 4

Tasa de defectos inyectados por fase del proyecto

Figura 5

Tasa de defectos eliminados por fase del proyecto


64

7.6 Análisis de rendimiento

La gráfica siguiente presenta la información del porcentaje de defectos inyectados y eliminados del

proyecto por fase.

Gráfica 1

Distribución de defectos inyectados por fase

En la fase de requerimientos se inyectó 19.3% de los defectos, mientras que en HLD el valor fue de

4.20%, para DLD fue 35.92 y finalmente en la fase de codificación se inyectó el 40.59% del total de

defectos.


65

Gráfica 2

Porcentaje de defectos eliminados por fase

Fase Valor porcentual para eliminación de

defectos

Inspección de requerimientos 17.3

Diseño de alto nivel 0.4

Inspección de diseño de alto nivel 4.8

Revisión de Diseño Detallado 19.8

Inspección de Diseño Detallado 12.6

Revisión de Código 26.3

Inspección de Código 7.3

Compilación 6.5

Pruebas Unitarias 4.5

Pruebas de Integración 0.50

En la siguiente gráfica se hace una evaluación entre el número de horas que el equipo planeó dedicar al

proyecto y el número de horas reales dedicadas a proyecto


66

Gráfica 3

Horas planeadas del proyecto VS horas reales de dedicación

El equipo no logró cumplir la meta de horas planeadas semanalmente en todas las ocasiones, algunas

ocasiones estuvimos por debajo de lo planeado y en otras sobrepasamos la meta semana planeada.


67

Grafica que representa el valor acumulado planeado y real.

8 Conclusiones.

POSMORTEM (CONCLUSIONES DEL PROYECTO).

Dentro de los principales resultados obtenidos en el desarrollo del Sistema POS Detallista, se

observó que, cumple todos los requerimientos establecidos de acuerdo al plan aceptado por el

cliente.

Cubre el 100% de los casos de uso

1. Venta.

2. Devolución.

3. Productos (promociones, combo, importar productos).

4. Usuarios

5. Caja.

6. Configuración (respaldo automático, exportar productos y configuración periféricos).

7. Instalación Automática y configuración inicial del software.


68

Es sencillo de utilizar.

Es rápido.

Considera seguridad.

Es fácil de instalar.

Es robusto.

La productividad que alcanzamos como equipo tuvo un acierto sorprendente, pues el libro de

trabajo nos mostraba como planeado 5.5 LOC’s /Hora, y el valor real obtenido fue de 5.4 LOC’s / Hora.

En la propuesta aceptada por el cliente se mencionaba que el desarrollo del sistema POS

Detallista se concluiría en 18 semanas. Sin embargo el tamaño del sistema fue subestimado, es decir:

Se había contemplado como tamaño total del sistema 17,456 (LOCS) y en el conteo final se

obtuvieron 24,403(LOCS), casi un 30% más de lo planeado, por lo que nuestro calculo fue

subestimado considerablemente; sin embargo, proyectando la equivalencia en semanas de acuerdo al

tamaño real del Sistema, era fácil pensar que la fecha real de terminó debía ser cuatro semanas después

de la fecha objetivo, es decir el 04/11/2010. Gracias al esfuerzo y colaboración del equipo TSP

terminamos solamente tres semanas después de la fecha objetivo es decir el 31/10/2010 haciendo buen

uso del tiempo empleado en el desarrollo del sistema.

Algunos de los PIBS que vale la pena recalcar son:

“Problema: Existen dos periodos de baja productividad durante el desarrollo del sistema, en uno

de ellos, cubrimos solamente un 10% del total del sistema POS Detallista en 1/3 del tiempo total de

desarrollo del sistema”.

Este inconveniente surgió por falta de compromiso por parte de cada integrante a cumplir sus

actividades, o en su defecto la disponibilidad para ayudar a otro integrante del quipo en caso de que las

tareas del primero ya hubieran sido finalizadas.

“Problema: Falta de establecer un Administrador de Bases de Datos”.

La solución sería contemplar este integrante con igual importancia al resto desde el inicio del

proyecto.

“Problema: falta de acuerdo para fijar día de inspecciones”.

La solución es tener la estricta coordinación tanto de inspectores como del productor; además

de fijar más de un Administrador para regular este proceso por ejemplo Administrador de Calidad y

Administrador de implementación.


69

9 Anexos.

Las Tareas semanales realizadas a lo largo del proyecto se presentan en forma electrónica.A2

Las Tareas semanales Realizadas a lo largo del proyecto por parte del equipo se presentan en forma

electrónica.A3

El Resultado del proyecto se presenta de forma electrónica. A4

El Desarrollo del proyecto se presenta organizado atreves de 3 iteraciones las cuales se presentan de

forma electrónica.A5, A6, A7

El Sistema Realizado a lo largo del proyecto se encuentra en la carpeta Intalador_Abarrotes-UAMI A8

El código fuente de la aplicación se presenta en forma electrónica A9

El material desarrollado como Guiones, Caso de Usos, Procedimientos, Requerimientos y Check-list

que cubren parte de la documentación del proyecto se presenta de forma electrónica A10

10 Bibliografías.

Watts S. Introducción al Proceso de Software Personal PSP, Addison – Wesley, 2001.

A2 Anexos/TSP/LibroDeTrabajo/PA.xls A3

Anexos/TSP/LibroDeTrabajo/*.xls A4

Anexos/TSP/LibroDeTrabajo/consolidadoFINAL.xslm A5

Anexos/TSP/IteracionesTSP/Iteracion1

A6 Anexos/ TSP/IteracionesTSP/Iteracion2

A7 Anexos/ TSP/IteracionesTSP/Iteracion3

A8 Intalador_Abarrotes-UAMI/

A9 Anexos\TSP\IteracionesTSP\Iteracion3\Codigo\Workspace

A10 Anexos\TSP\IteracionesTSP\Iteracion1\Documentacion

ppeeerrrssso oonnaaalll w sssooffftttwwwa aar rreee e ...148.206.53.233/tesiuami/uami15680.pdf · 1...

Documents