Reporte Final. - 148.206.53.84148.206.53.84/tesiuami/204214629.pdf · 10-Dic-2010 14:42 14:52 10...

2

Reporte Final. Guerrero Camacho Juan Carlos.

Guión de Proceso para el Reporte Final de PSP

Fase # Propósito Guiar el análisis y la escritura del reporte final de PSP

Criterio de

Entrada Todos los Programas PSP finalizados. Copia de los requerimientos del reporte. Bitácora de registro de tiempo y forma del resumen del reporte final PSP

1 Planeación Estimar el tamaño del reporte.

- Número de párrafos de análisis.

- Número de tablas de datos o graficas a crear.

Estimar el esfuerzo basándose en el tamaño del reporte.

Registrar los estimados en la Forma de Resumen del Plan.

Registrar el tiempo de planeación en la Bitácora de Tiempo.

2 Desarrollo. Para cada pregunta de análisis. - Generar la grafica o tabla de datos para análisis. - Analizar la grafica o tabla y otros datos del proceso. - Escribir el párrafo de análisis.

Registrar el tiempo de desarrollo del reporte final de PSP en la bitácora de

tiempo.

3 Post Mortem Medir el tamaño del reporte.

- Número de graficas y tablas.

- Números de párrafos de análisis.

Completar la forma de Resumen de Plan.

Registrar el tiempo del Post Mortem en la Bitácora de tiempo.

Criterio de

Salida

Reporte Final de PSP finalizado.

Resuman del Plan finalizado.

Bitácora de Tiempo finalizado.

3

Resumen del Plan del Reporte Final PSP

Estudiante Juan Carlos Guerrero Camacho. Fecha 21 – Sep - 2012

Instructor Luis Fernando Castro.

Datos de Tamaño Estimado de Esfuerzo

Objeto Número

Planeado

Número

Real

Esf. Estim.

por Objeto

Esfuerzo

Estimado

Párrafos 25 26 8 min. 200

Tablas 10 17 7 min. 70

Graficas 10 3 7 min. 70

Total 340

Datos de Esfuerzo

Fase Tiempo Plan Tiempo Real

Planeación 15 18

Desarrollo 340 205

PM 20 17

Total 375 240

4

Bitácora de Registro de Tiempo.

Estudiante: Juan Carlos Guerrero

Camacho.

Fecha: 21 – Sep –

2012

Fecha Inicio Alto Tiempo de

Interrupción

Tiempo

Delta

Fase Comentarios

18-Nov-2010 14:05 14:23 18 Planeación Termine Fase de

Planeación.

20-Nov-2010 22:35 23:14 39 Desarrollo Empecé fase de

Desarrollo.

25-Nov-2010 16:18 16:55 37 Desarrollo Continúo con la

pregunta cuatro.

04-Dic-2010 21:54 22:27 33 Desarrollo Continúo con la

pregunta nueve.

10-Dic-2010 14:42 14:52 10 Desarrollo Continúo con la

pregunta trece.

Llamada telefónica,

aquí lo dejo y continúo

después.

19-May-2012 23:12 23:52 40 Desarrollo Continúo con la

pregunta quince.

20-May-2012 17:33 18:00 27 Desarrollo Continúo con la

pregunta veintiuno.

25-Ago-2012 19:26 19:45 19 Desarrollo Continúo con la

pregunta veintiséis.

Termine Fase de

Desarrollo.

21-Sep-2012 20:39 20:56 17 Post Mortem Termine Fase de Post

Mortem

5

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

Prog.\Tam. Estimado Real Diferencia

5 125.70 116 9.70

6 176.14 147 29.14

7 462.21 411 51.21

8 450.04 535 84.96

Promedio de diferencia 43.75

De un promedio de 25.0 loc’s de diferencia entre el real y el estimado antes del reporte intermedio

cambio a 43.7 loc’s en los últimos cuatro programas notando que aumento un 75.2% y pensando que

la principal razón de este aumento es la omisión de módulos y la contemplación de módulos que no se

utilizaron en algunos programas.

6

¿Qué tan frecuentemente estuvo mi tamaño real del programa dentro de mi intervalo estadístico de predicción del 70%?

Prog.\Tam. Estimado Real UPI LPI

5 125.70 116 181.45 69.94 si estuvo dentro del rango

6 176.14 147 136.24 32.04 10.76 por encima de UPI

7 462.21 411 259.70 178.72 151.30 por encima de UPI

8 450.04 535 362.58 263.50 172.42 por encima de UPI

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

Si tengo tendencia a no considerar los objetos completos e incluso a no considerar un modulo y ello

conlleva a que aumente el número de loc's que se deben programar e incrementa el tiempo.

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

Si tengo una tendencia a juzgar equivocadamente el tamaño de los objetos pero con la base de ajuste del

70% tienden a no ser tan malas

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

Con los datos históricos que tengo si puedo calcular el rango de tamaño relativo y sí puedo calcularlos

ya que tenemos un programa (que realizamos en una de las tareas ) para calcular el tamaño

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

Creo que lo dejaría en un 70% ya que el promedio entre el real y el estimado es de 34.3 loc’s y que en

cuatro programas sobrestimo y en tres subestimo el tamaño real.

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

Planear y pensar mejor la estructura del programa y dedicar más tiempo al pseudocódigo.

7

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

Prog.\Tam. Metodo Estimado Real diferencia

1 165.00 217.00 52.00 subestimado

2 210.00 267.00 57.00 subestimado

3 C 249.02 281.10 32.08 subestimado

4 C 139.17 237.50 98.33 subestimado

prom. de

diferencia 59.85

5 D 183.00 345.80 162.80 subestimado

6 D 140.00 146.70 6.70 subestimado

7 C 375.45 219.20 156.25 sobrestimado

8 D 400.00 359.50 40.50 sobrestimado

prom. de

diferencia 91.56

El promedio aumento ya que en el programa 5 subestime demasiado ya que le dedique más tiempo en el

diseño y en el programa 7 se sobrestimo y pienso que por estos dos datos es que aumento el promedio.

¿Qué tan frecuentemente estuvo mi tiempo de desarrollo real dentro de mi intervalo estadístico de predicción del 70%?

Ya que se utilizaron los métodos C y D no tengo datos del rango del 70% es decir UPI y LPI en

PSP Size Estimating Template de los programas en mi Libro de Trabajo.

8

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

Mi productividad no es estable pensando en que debo mejorar (aumentar el tiempo) en el diseño (y

aumentar el conocimiento en el lenguaje en que se está programando,) ya que si tengo conocimiento en el

lenguaje sé que no lo domino completamente.

¿Cómo puedo estabilizar mi productividad?

Pensando en que debo aumentar el tiempo y mejorar en el diseño y aumentar el conocimiento del

lenguaje en que se trabaja para dominarlo completamente.

9

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

Prog.\Tiempo Estimado Real diferencia

5 183.00 345.80 162.80 subestimado

6 140.00 146.70 6.70 subestimado

7 375.45 219.20 156.25 sobrestimado

8 400.00 359.50 40.50 sobrestimado

Tengo un promedio de 91.56 de diferencia entre los tiempos estimados y los reales y en uno de ellos

subestime y otro sobrestime demasiado La regresión lineal me serviría para checar las variables de

regresión y con ellas decidir si agregamos valores menores o mayores a los estimados que ya tenemos.

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

Viendo mis datos lo dejaría en un 70 % hasta el momento en que fuesen consistentes para los

programas hechos.

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

Planear mejor la estructura del programa, cronometrando aun mejor los tiempos de cada fase, aunque

creo que se hacía bien podemos mejorarlos con un cronometro más exacto y revisando constantemente

nuestros estimados.

10

Análisis de defectos de rendimiento

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

DEFECTOS EN DISEÑO

Error\Prog. 5 6 7 8 Total

80 - Function 1 1 0 1 3

50 - Interface 0 0 1 1 2

40 - Assignament 1 0 2 0 3

20 - Sintaxis 0 2 1 0 3

Vemos que en los últimos cuatro programas tengo errores de Función, Interface, Asignación y de

Sintaxis en la Fase de Diseño.

DEFECTOS EN CODIFICACION

Error\Prog. 5 6 7 8 total

20 - Sintaxis 2 4 1 4 11

40 - Assignament 1 0 3 3 7

80 - Function 1 1 1 4 7

50 - Interface 0 0 0 1 1

10 -

Documentacion 0 0 2 0 2

Vemos que los últimos cuatro programas tengo errores de Sintaxis, Asignación, Función, Interface y

Documentación en la Fase de Codificación.

11

¿Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados en las revisiones, compilaciones y pruebas?

Programa

Tam.

Prog. Loc's A y M

Defectos

DLDR

Defectos

CR

Defectos

COMPILE

Defectos

UT

5 116 116 0 3 1 2

6 147 55 2 5 1 0

7 411 160 4 5 2 0

8 535 398 2 6 4 2

total 729 8 19 8 4

tendencia defectos (Kloc) = 10.97 26.06 10.97 5.49

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

DEFECTOS

Programa Defectos

Loc's A y

M

5 6 116

6 8 55

7 11 160

8 14 398

total 39 729

Tendencia de defectos = 53.50

Tendencia de los defectos totales en KLoc para el próximo programa a realizar tomando en cuenta los

programas del cinco al ocho.

12

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

DEFECTOS REMOVIDOS EN REVISIÓN DE

DISEÑO

Programa Defectos Tiempo en fase (min)

5 0 54

6 2 26

7 4 36

8 2 39

total 8 155

Defectos eliminados/hora = 3.10

Como vemos en revisión de diseño y revisión de código tenemos el mayor número de defectos

removidos y ya que ocupamos más tiempo en estas fases tenemos 3.10 y 6.95 defectos

eliminados/hora respectivamente y nos ayuda para cuando llegamos a las fases de compilación y pruebas

que nos reduce el número de defectos.

DEFECTOS REMOVIDOS EN REVISIÓN DE

CÓDIGO


5 3 48

6 5 28

7 5 33

8 6 55

total 19 164


DEFECTOS REMOVIDOS EN

COMPILACIÓN


5 1 3

6 1 2

7 2 11

8 4 10

total 8 26


DEFECTOS REMOVIDOS EN PRUEBAS


5 2 26

6 0 8

7 0 12

8 2 40

total 4 86


13

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

Programa

Loc's A y

M

Tiempo en fase

Revisión de

Diseño (min)

Tiempo en

fase de

Revisión de

Código (min)

5 116 54 48

6 55 26 28

7 160 36 33

8 398 39 55

total 729 155 164

Tamaño revisado/hora

= 282.19 266.71

En la fase de Revisión de Diseño tenemos que por hora revisamos 282.19 Loc's, es decir, una línea de

código en 12.76 seg.

En la fase de Revisión de Código tenemos que por hora revisamos 266.71 Loc´s, es decir, una línea de

código en 13.50 seg.

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

Nota: Imagen tomada de PSP2.1 Project Plan Summary de Programa 8, ya que tiene el dato Real y A la Fecha.

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

Claro está que si mejoramos las revisiones y detectamos a un más defectos antes de llegar a la fase de

compilación nuestro rendimiento mejorara y así tendremos más calidad en nuestro producto.

14

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

Ya que A/FR es la tasa de costos que es calculada con los tiempos de desarrollo de las fases de revisión

de diseño y codificación y con el tiempo de desarrollo de las fases de compilación y desarrollo que son en

donde detectamos los defectos y nuestro rendimiento que es el porcentaje de defectos introducidos y

eliminados antes de la primera compilación.

Programa Yield % A/FR

5 50.00 3.50

6 87.50 5.30

7 81.80 3.00

8 57.10 1.90

15

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

Comparando el número de defectos que tenemos en los primeros cuatro programas con los de los últimos

cuatro programas notamos que disminuyeron notablemente y pienso que sería porque reutilizábamos

código y se hicieron checklist para las revisiones.

16

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

desarrollo? Observando de la tabla anterior la disminución de defectos encontrados en compilación y pruebas creo

que ha mejorado la calidad del producto, pero aun así debemos mejorar en la fase de planeación.

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

Si estoy encontrando mis defectos en las revisiones ayudado de los checklist y más aun en la revisión

de codificación ya que es cuando vemos realmente las líneas de código y como es que va a quedar

conformado nuestro programa y podemos observar la falta de líneas de código.

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

Mejorando en las fases de planeación, diseño y estudiando o analizando mejor las partes que

consideremos nos sean difíciles para codificar.

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

Reducir los defectos totales en el programa.

Detectar los defectos en las Fases de Revisión de Diseño y Revisión de Codificación.

Reducir de ocho a cuatro defectos máximo en los siguientes cuatro programas en la Fase de

Compilación.

Mantener por ahora de cero a dos defectos en la Fase de Pruebas.

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

Aumentar el conocimiento en el lenguaje de programación, mejora en la Fase de Planeación y Diseño,

definir y mejorar nuestro CheckList para las fases de Revisión, estudiar, entender y resolver a un más

problemas que pensemos nos darán problemas en la Fase de Diseño para que no se compliquen en la

Fase de Codificación y empezando con esta metas podremos reducir los defectos encontrados en las Fases

de Compilación y Pruebas.

Con esto empezaremos a tener una mejor calidad en nuestro producto.

17

REPORTE DE PROYECTO TERMINAL.

(Personal Software Process &Team Software Process)

Sistema Punto de Venta al Detalle.

ASESOR:

Mtro. Luis Fernando Castro Careaga.

ALUMNO: Juan Carlos Guerrero Camacho.

18

1. Presentación .................................................................................................................................... 3 2. Presentación PSP ............................................................................................................................ 3 2.1 Reporte Final PSP ........................................................................................................................ 4 2.1.1 Análisis de la exactitud de la estimación del tamaño. .................................................................. 4 2.1.2 Análisis de la exactitud de estimación del tiempo. ....................................................................... 4 2.1.3 Análisis de defectos de rendimiento. ........................................................................................... 4 2.1.4 Análisis de calidad. ..................................................................................................................... 4 3. Presentación TSP ............................................................................................................................ 4 3.1 ¿Por qué contar con un proceso de software? ............................................................................... 4 3.2 ¿Qué es TSP? ............................................................................................................................... 4 3.3 Estrategia de TSP .......................................................................................................................... 6 3.4 Ciclo TSP ....................................................................................................................................... 6 3.4.1 Lanzamiento ............................................................................................................................... 6 3.4.2 Requerimientos ........................................................................................................................... 7 3.4.3 Diseño de alto nivel ..................................................................................................................... 7 3.4.4 Implementación ........................................................................................................................... 7 3.4.5 Integración y pruebas .................................................................................................................. 7 3.4.6 Post Mortem ............................................................................................................................... 7 3.5 El lanzamiento ............................................................................................................................... 8 3.5.1 Junta 1 ........................................................................................................................................ 9 3.5.2 Junta 2 ........................................................................................................................................ 9 3.5.3 Junta 3 ...................................................................................................................................... 10 3.5.4 Junta 4 ...................................................................................................................................... 10 3.5.5 Junta 5 ....................................................................................................................................... 11 3.5.6 Junta 6 ....................................................................................................................................... 11 3.5.7 Junta 7 ....................................................................................................................................... 11 3.5.8 Junta 8 ....................................................................................................................................... 11 3.5.9 Junta 9 ....................................................................................................................................... 11 3.6 Post Mortem ................................................................................................................................ 12 4. Proyecto ........................................................................................................................................ 12 4.1 Introducción ................................................................................................................................. 12 4.2 Sistema de punto de venta POS Detallista ................................................................................... 12 5. Lanzamiento del proyecto .............................................................................................................. 13 5.1 Juntas .......................................................................................................................................... 14 5.1.1 Junta 1 ...................................................................................................................................... 14 5.1.2 Junta 2 ...................................................................................................................................... 14 5.1.3 Junta 3 ...................................................................................................................................... 15 5.1.4 Junta 4 ...................................................................................................................................... 16 5.1.5 Junta 5 ...................................................................................................................................... 16 5.1.6 Junta 6 ...................................................................................................................................... 16 5.1.7 Junta 7 ...................................................................................................................................... 16 5.1.8 Junta 8 ...................................................................................................................................... 16 5.1.9 Junta 9 ...................................................................................................................................... 16 5.1.10 Post Mortem……………………………........................................................................................16 6 Reporte resumen del proyecto ........................................................................................................ 17 6.1 Análisis del calendario de trabajo ................................................................................................. 17 6.2 Análisis de recursos ..................................................................................................................... 18 6.3 Análisis de tamaño ....................................................................................................................... 19 6.4 Análisis de productividad .............................................................................................................. 22 6.5 Análisis de defectos ..................................................................................................................... 23 6.6 Análisis de rendimiento ................................................................................................................ 25 7. Conclusiones ................................................................................................................................. 29

19

1. Presentación 2. Presentación PSP

El PSP (Personal Software Process o Proceso Personal de Software) 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 definido para quien este interesado en

aumentar la calidad de los productos de software que desarrolla dentro de un contexto de

trabajo individual.

El PSP se divide en dos partes:

Etapas que se siguen durante el desarrollo del proceso:

PSP Parte I : Planeación • Introducción al PSP

• Medición del Proceso

• Estimación con PROBE I

• Estimación con PROBE II

• Usando los datos de PSP

PSP Parte I : Planeación • Calidad de Software

• Diseño de maquinas de

estado y verificación

• Diseño

• Verificación del Diseño

• Usando el PSP

20

2.1 Reporte Final PSP 2.1.1 Análisis de la exactitud de la estimación del tamaño. 2.1.2 Análisis de la exactitud de estimación del tiempo. 2.1.3 Análisis de defectos de rendimiento. 2.1.4 Análisis de calidad.

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

artístico, 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 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.

21

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.

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.

22

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

23

calidad, se 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.

24

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.

25

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

26

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

27

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.

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

28

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.

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.

29

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). 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 Camacho (JC). Pedro Aguilar Cayetano (PA).

30

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 11

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.

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.2 Junta 22

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.

1 Forma TSP generada en Junta 1, véase archivo

MaterialJuntasDeLanzamiento/Junta1/MTGJunta1.doc 2 Forma TSP generada en Junta 2, véase archivo

MaterialJuntasDeLanzamiento/Junta2/MTGJunta2.doc

31

El resultado de esto se muestra en la siguiente tabla

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 33

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.

3 Forma TSP generada en Junta 3, véase


32

5.1.4 Junta 44 5.1.5 Junta 55 5.1.6 Junta 66 5.1.7 Junta 77 5.1.8 Junta 88 5.1.9 Junta 99 5.1.10 Post Mortem

4 Forma TSP generada en Junta 4, véase

MaterialJuntasDeLanzamiento/Junta4/MTGJunta4.doc 5 Forma TSP generada en Junta 5, véase




MaterialJuntasDeLanzamiento/Junta8/MTGJunta 8.doc 9 Forma TSP generada en Junta 9, véase


33

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

6.1 Análisis del calendario de trabajo A continuación se muestran los diferentes tamaños de unidades en cuanto a horas de trabajo, el calendario completo de los casi seis meses de trabajo ininterrumpido, representando de manera detallada los momentos más relevantes durante la realización del proyecto. Lo que nos ayudará a mejorar la planeación de proyectos posteriores

Punto de Referencia clave fecha planeada fecha actual porcentaje

Comienzo de las juntas de lanzamiento 12/05/2010 12/05/2010 0%

Finalización de las juntas de lanzamiento 27/05/2010 27/05/2010 0%

Lanzamiento del proyecto 31/05/2010

31/05/2010

0%

1ra Iteración 26/07/2010 11/08/2010 59%

2da Iteración 06/09/2010 15/09/2010 86.2%

3ra Iteración 04/10/2010 08/11/2010 97.3%

Fin del proyecto 31/10/2010 08/11/2010 100%

34

6.2 Análisis de recursos

Para la planeación de proyectos posteriores es necesario conocer el porcentaje de tiempo planeado y actual dedicado a cada fase, para cada uno de los puntos de referencia del proyecto.

Fase Punto de Referencia

Tiempo planeado

Tiempo real Porcentaje de dedicación

Juntas de lanzamiento

Junta 1 90 min. 157 min.

Fuera de tiempo para horas

dedicadas al proyecto









Junta Post Mortem

90 min. min.

Requerimientos

Arquitectura 644.7 Hrs. 731.8 Hrs 25.4%

Proyecto

Revisión de requerimientos

Inspección de requerimientos

Diseño de alto nivel (HLD)

Arquitectura 139 Hrs. 183.3 Hrs. 6.4%

Proyecto

Revisión de HLD

Inspección de HLD

Diseño detallado (DLD)

DLD 406.8 Hrs. 599.8 Hrs. 20.8%

DLDR

Inspección DLD

Codificación Código 385.8 Hrs. 568.1 Hrs. 19.8%

Inspección de Código

Revisión de codificación

35

Fase Punto de Referencia

Tiempo planeado

Tiempo real Porcentaje de dedicación

Compilación Compilación de todos los módulos

30.1 Hrs. 39.9 Hrs. 1.4%

Pruebas unitarias Pruebas individuales

110.7 Hrs. 113 Hrs. 3.9%

Pruebas de Sistema

Pruebas del Sistema

30 Hrs. 25.8 Hrs. 1%

Pruebas de integración

Pruebas para integrar módulos

72 Hrs. 66.6 Hrs. 2.4%

Documentos TSP

Guiones, estándares, procesos, listas de verificación.

559.2 Hrs. 548.8 Hrs. 18.9%

6.3 Análisis de tamaño

Listado de productos generados en cada una de las tareas del proyecto y su tamaño.

Es parte de Nombre Tamaño

Documento de procesos y procedimientos del equipo

6

Documento de Procedimiento de Inspección DLD

6

Documento de Estándar de Nomenclatura

15

Check In 7

Documento de Estándares de Diseño

8

Documento de Estándar de Tamaño

3

Documento de Procedimiento de Revisión de HLD

6

Check List de Revisión de HLD

5

Check List de Inspección HLD

6

Check List de Revisión de DLD

5

Check List de Inspección 5

36


Documentación TSP (Páginas de texto)

HLD

Check List de Revisión de requerimientos

6

Check List de Inspección de Requerimientos

4

Check List de Revisión de Código

5

Check List de Inspección de Código

6

Documento de Procedimiento de Revisión de DLD

7

Documento de Estándares de Codificación

7

Documento de Estándar de mensajes

5

Documento de Procedimiento de Inspección HLD

7

Guión de Revisión de Código 8

Guión de Revisión de HLD 6

Guión de Revisión de DLD 7

Guión de Entrega Total 5

Guión de Inspección de Código

5

Guión de Entrega Parcial 6

Guión de Post Mortem 3

Guión de Revisión de Requerimientos

6

Proceso para revisión de Código

8

Proceso para revisión de Diseño Detallado

6

Proceso de captación de nuevos Requerimientos

8

Proceso de Evaluación de nuevos requerimientos

6

Proceso de integración de nuevos Requerimientos

5

Proceso de respuesta al Cliente de nuevos

6

37


Requerimientos

CU1 Ventas 60

CU2 Devolución 6

CU3 Caja 25

CU8 Configuración 46

CU9 Productos 80

CU10 Usuario 23

CU11 Acceso 10

CU12 Interfaz 34

Requerimientos

(Páginas de requerimientos)

Especificación del Sistema 29

Matriz de Trazabilidad 2

HLD (Páginas de diseño)

Especificación del Diseño de Alto Nivel

10

Especificación de la Arquitectura

23

Pruebas de sistema (Páginas de texto)

Reporte de pruebas Unitarias 52

Reporte de pruebas de integración del sistema

21

Reporte de pruebas del sistema

15

Plan de Validación de Pruebas

8

Plan de pruebas Unitarias 25

Plan de pruebas de Integración

3

Procedimiento para pruebas 6

38

6.4 Análisis de productividad A continuación se muestran las Tasas de Productividad de los documentos generados.

Tarea Productividad

Páginas de texto / hora

Documento de procesos y procedimientos del equipo 0.30

Documento de Procedimiento de Inspección DLD 0.75

Documento de Estándar de Nomenclatura 1.65

Check In 1.75

Documento de Estándares de Diseño 0.39

Documento de Estándar de Tamaño 0.77

Documento de Procedimiento de Revisión de HLD 0.86

Check List de Revisión de HLD 0.96

Check List de Inspección HLD 1.20

Check List de Revisión de DLD 1.67

Check List de Inspección HLD 1.00

Check List de Revisión de requerimientos 2.00

Check List de Inspección de Requerimientos 0.48

Check List de Revisión de Código 1.00

Check List de Inspección de Código 0.92

Documento de Procedimiento de Revisión de DLD 0.84

Documento de Estándares de Codificación 0.39

Documento de Estándar de mensajes 0.67

Documento de Procedimiento de Inspección HLD 0.88

Guión de Revisión de Código 1.33

Guión de Revisión de HLD 0.71

Guión de Revisión de DLD 1.03

Guión de Entrega Total 1.11

Guión de Inspección de Código 1.11

Guión de Entrega Parcial 1.00

Guión de Post Mortem 0.50

Guión de Revisión de Requerimientos 1.71

Proceso para revisión de Código 0.45

Proceso para revisión de Diseño Detallado 0.75

Proceso de captación de nuevos Requerimientos 1.14

Proceso de Evaluación de nuevos requerimientos 0.78

39

Tarea Productividad

Proceso de integración de nuevos Requerimientos 0.71

Proceso de respuesta al Cliente de nuevos Requerimientos

0.48

CU1 Ventas 1.03

CU2 Devolución 0.83

CU3 Caja 1.05

CU8 Configuración 1.11

CU9 Productos 1.30

CU10 Usuario 2.30

CU11 Acceso 1.18

CU12 Interfaz 0.15

Páginas de requerimientos / hora

Especificación del Sistema 0.85

Matriz de Trazabilidad 0.24

Páginas de diseño / hora

Especificación del Diseño de Alto Nivel 0.23

Especificación de la Arquitectura 1.18

Páginas de texto / hora

Plan de Validación de Pruebas 1.60

Plan de pruebas Unitarias 2.50

Plan de pruebas de Integración 0.65

Procedimiento para pruebas 0.50

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

40

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.

Figura 4

Tasa de defectos inyectados por fase del proyecto

Figura 5

Tasa de defectos eliminados por fase del proyecto

41

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

42

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

43

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. La tabla siguiente muestra como se había planeado ganar valor del proyecto y como se realizo el proyecto en realidad y como se fue ganando valor.

Semana Valor generado planeado por

semana

Valor generado real por

semana

semana 23 y 24 0.0 0.1

Semana 22 0.0 0.9.

Semana 21 0.0 1.1

Semana 20 0.0 0.7

Semana 19 0.1 1.4

Semana 18 3.0 3.3

Semana 17 4.0 6.4

Semana 16 3.9 5.1

Semana 15 4.4 6.0

Semana 14 5.1 5.1

Semana 13 5.4 6.5

Semana 12 0.0 3.5

Semana 11 0.0 0.7

Semana 10 0.0 0.5

Semana 9 8.3 3.0

44

Semana Valor generado planeado por

semana

Valor generado real por

semana

Semana 8 9.4 4.4

Semana 7 6.4 5.0

Semana 6 8.5 8.1

Semana 5 8.4 6.7

Semana 4 8.5 7.8

Semana 3 7.4 8.8

Semana 2 8.9 7.4

Semana 1 8.0 7.5

En la tabla anterior podemos visualizar que las primeras 9 semanas el valor generado planeado nunca se cumplió, esto ocurrió por varios factores por ejemplo falta de compromiso individual, desconocimiento del lenguaje, o falta de compromiso para trabajar en equipo como fue el caso de las inspecciones, sin embargo después de la semana 9 se vio un realce en el valor generado por parte del desarrollo del proyecto ; pues aunque las semanas 10, 11 y 12 fueron planeadas como vacaciones aun en ese periodo se reflejo valor agregado.

Grafica que representa el valor acumulado planeado y real.

45

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

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.

46

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

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

Reporte Final. - 148.206.53.84148.206.53.84/tesiuami/204214629.pdf · 10-Dic-2010 14:42 14:52 10...

Documents

Transcript of Reporte Final. - 148.206.53.84148.206.53.84/tesiuami/204214629.pdf · 10-Dic-2010 14:42 14:52 10...