Fuoqns1579188918 PDF

1
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 Todos los Programas PSP finalizados.
Entrada 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 Reporte Final de PSP finalizado.

Salida Resuman del Plan finalizado.
Bitácora de Tiempo finalizado.
2
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 Número Esf. Estim. Esfuerzo

Planeado Real por Objeto 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
3
Bitácora de Registro de Tiempo.
Estudiante: Juan Carlos Guerrero Fecha: 21 – Sep –

Camacho. 2012
Fecha Inicio Alto Tiempo de Tiempo Fase Comentarios

Interrupción Delta
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
4
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.
5
¿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.
6
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.
7
¿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.
8
¿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.
9
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.
10
¿Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados en
las revisiones, compilaciones y pruebas?
Tam. Defectos Defectos Defectos Defectos

Programa Prog. Loc's A y M DLDR CR COMPILE 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
Loc's A y
Programa Defectos 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.
11
¿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 DEFECTOS REMOVIDOS EN REVISIÓN DE
CÓDIGO
Programa Defectos Tiempo en fase (min)
5 0 54 Programa Defectos Tiempo en fase (min)
6 2 26 5 3 48
7 4 36 6 5 28
8 2 39 7 5 33
total 8 155 8 6 55
total 19 164
Defectos eliminados/hora = 3.10
DEFECTOS REMOVIDOS EN DEFECTOS REMOVIDOS EN PRUEBAS
COMPILACIÓN
Programa Defectos Tiempo en fase (min)
Programa Defectos Tiempo en fase (min) 5 2 26
5 1 3 6 0 8
6 1 2 7 0 12
7 2 11 8 2 40
8 4 10 total 4 86
total 8 26
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.
12
¿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?
Tiempo en
Tiempo en fase fase de
Loc's A y Revisión de Revisión de
Programa M Diseño (min) 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.
13
¿Hay una relación entre el rendimiento y A/FR para los programas 5 al 8?
Programa Yield % A/FR

5 50.00 3.50
6 87.50 5.30
7 81.80 3.00
8 57.10 1.90
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.
14
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.
15
¿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.
16
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.
17
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
18
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:
PSP Parte I : Planeación PSP Parte I : Planeación

• Introducción al PSP • Calidad de Software
• Medición del Proceso • Diseño de maquinas de
• Estimación con PROBE I estado y verificación
• Estimación con PROBE II • Diseño
• Usando los datos de PSP • Verificación del Diseño
• Usando el PSP
Etapas que se siguen durante el desarrollo del proceso:
19
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.
20
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.
21
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
22
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.
23
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.
24
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.
25
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.
26
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
27
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.
28
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).
29
 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
30
El resultado de esto se muestra en la siguiente tabla
Miembro del
Roles de Equipo 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

31
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

MaterialJuntasDeLanzamiento/Junta8/MTGJunta 8.doc
32
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%
33
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 Tiempo Tiempo real Porcentaje de

Referencia planeado dedicación
Junta 1 90 min. 157 min.
Fuera de tiempo
Juntas de Junta 5 60 min. 39 min. para horas
lanzamiento Junta 6 240 min. 1111 min. dedicadas al
Junta 7 90 min. 65 min. proyecto

Junta Post 90 min. min.
Mortem
Arquitectura 644.7 Hrs. 731.8 Hrs 25.4%
Proyecto
Requerimientos
Revisión de
requerimientos
Inspección de
requerimientos
Arquitectura 139 Hrs. 183.3 Hrs. 6.4%
Proyecto
Diseño de alto
nivel (HLD) Revisión de HLD
Inspección de
HLD
Diseño detallado DLD 406.8 Hrs. 599.8 Hrs. 20.8%
(DLD) 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
34
Fase Punto de Tiempo Tiempo real Porcentaje de
Referencia planeado dedicación
Compilación Compilación de 30.1 Hrs. 39.9 Hrs. 1.4%
todos los
módulos
Pruebas unitarias Pruebas 110.7 Hrs. 113 Hrs. 3.9%
individuales
Pruebas de Pruebas del 30 Hrs. 25.8 Hrs. 1%
Sistema Sistema
Pruebas para 72 Hrs. 66.6 Hrs. 2.4%
Pruebas de integrar módulos
integración
Guiones, 559.2 Hrs. 548.8 Hrs. 18.9%
Documentos TSP estándares,
procesos, listas
de verificación.
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 6
procedimientos del equipo
Documento de Procedimiento 6
de Inspección DLD
Documento de Estándar de 15
Nomenclatura
Check In 7
Documento de Estándares de 8
Diseño
Tamaño
de Revisión de HLD
Check List de Revisión de 5
HLD
Check List de Inspección 6
HLD
DLD
Check List de Inspección 5
35
HLD
Documentación TSP requerimientos
(Páginas de texto)
Check List de Inspección de 4
Requerimientos
Código
Check List de Inspección de 6
Código
de Revisión de DLD
Documento de Estándares de 7
Codificación
mensajes
de Inspección HLD
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 5
Código
Guión de Entrega Parcial 6
Guión de Post Mortem 3
Guión de Revisión de 6
Requerimientos
Proceso para revisión de 8
Código
Proceso para revisión de 6
Diseño Detallado
Proceso de captación de 8
nuevos Requerimientos
Proceso de Evaluación de 6
nuevos requerimientos
Proceso de integración de 5
nuevos Requerimientos
Proceso de respuesta al 6
Cliente de nuevos
36
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
Especificación del Sistema 29
Requerimientos Matriz de Trazabilidad 2
(Páginas de requerimientos)
Especificación del Diseño de 10
Alto Nivel
Especificación de la 23
Arquitectura
HLD
(Páginas de diseño)
Reporte de pruebas Unitarias 52
Pruebas de sistema Reporte de pruebas de 21
(Páginas de texto) integración del sistema
Reporte de pruebas del 15
sistema
Plan de Validación de 8
Pruebas
Plan de pruebas Unitarias 25
Plan de pruebas de 3
Integración
Procedimiento para pruebas 6
37
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
38
Tarea Productividad
Proceso de integración de nuevos Requerimientos 0.71
Proceso de respuesta al Cliente de nuevos 0.48
Requerimientos
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
39
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
40
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.
41
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
42
G
rá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 Valor generado real por

semana 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
43
Semana Valor generado planeado por Valor generado real por
semana 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.
44
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.
45
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.
46
47

Fuoqns1579188918 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Fuoqns1579188918 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

1

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

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

2 Desarrollo. Para cada pregunta de análisis.

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

3 Post Mortem Medir el tamaño del reporte.

Completar la forma de Resumen de Plan.

Criterio de Reporte Final de PSP finalizado.

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

Datos de Tamaño Estimado de Esfuerzo

Objeto Número Número Esf. Estim. Esfuerzo

Fase Tiempo Plan Tiempo Real

Total 375 240

Estudiante: Juan Carlos Guerrero Fecha: 21 – Sep –

Fecha Inicio Alto Tiempo de Tiempo Fase Comentarios

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

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

Prog.\Tam. Estimado Real Diferencia

Promedio de diferencia 43.75

Prog.\Tam. Estimado Real UPI LPI

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

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

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

Prog.\Tam. Metodo Estimado Real diferencia

5 D 183.00 345.80 162.80 subestimado

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

¿Cómo puedo estabilizar mi productividad?

Prog.\Tiempo Estimado Real diferencia

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

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

Tam. Defectos Defectos Defectos Defectos

tendencia defectos (Kloc) = 10.97 26.06 10.97 5.49

Tendencia de defectos = 53.50

DEFECTOS REMOVIDOS EN REVISIÓN DE

Programa Yield % A/FR

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

Reducir los defectos totales en el programa.

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

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

(Personal Software Process &Team Software Process)

Sistema Punto de Venta al Detalle.

ALUMNO: Juan Carlos Guerrero Camacho.

El PSP (Personal Software Process o Proceso Personal de Software) es una

El PSP se divide en dos partes:

PSP Parte I : Planeación PSP Parte I : Planeación

Etapas que se siguen durante el desarrollo del proceso:

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

Actualmente existe una gran diversidad de opciones relacionadas con procesos de

3.2 ¿Qué es TSP?

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

• Proveer un proceso sencillo basado en PSP.

3.4 Ciclo TSP

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

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

3.4.3 Diseño de alto nivel

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

3.4.5 Integración y pruebas

3.4.6 Post Mortem

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

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

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

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