2
Reporte Final.
Guerrero Camacho Juan Carlos.
Guión de Proceso para el Reporte Final de PSPFase # 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
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 Estimado Esfuerzo
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
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.
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
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?
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%?
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?
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?
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
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
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
Programa Defectos Tiempo en fase (min)
5 3 48
6 5 28
7 5 33
8 6 55
total 19 164
Defectos eliminados/hora = 6.95 DEFECTOS REMOVIDOS EN
COMPILACIÓN
Programa Defectos Tiempo en fase (min)
5 1 3
6 1 2
7 2 11
8 4 10
total 8 26
Defectos eliminados/hora = 18.46
DEFECTOS REMOVIDOS EN PRUEBAS
Programa Defectos Tiempo en fase (min)
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?
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
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é?
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.
17
REPORTE DE PROYECTO TERMINAL.
(Personal Software Process &Team Software Process)
Sistema Punto de Venta al Detalle.
ASESOR:
Mtro. Luis Fernando Castro Careaga.
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
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
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
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
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
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
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
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
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
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.
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.
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).
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
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.
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/Junta5/MTGJunta5.doc
6 Forma TSP generada en Junta 6, véase MaterialJuntasDeLanzamiento/Junta6/MTGJunta6.doc
7 Forma TSP generada en Junta 7, véase MaterialJuntasDeLanzamiento/Junta7/MTGJunta7.doc
8 Forma TSP generada en Junta 8, véase MaterialJuntasDeLanzamiento/Junta8/MTGJunta 8.doc
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%
34
6.2
Análisis de recursosPara 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 2 240 min. 238 min.
Junta 3 240 min. 819 min.
Junta 4 240 min. 1244 min.
Junta 5 60 min. 39 min.
Junta 6 240 min. 1111 min.
Junta 7 90 min. 65 min.
Junta 8 90 min. 19 min.
Junta 9 90 min. 90 min.
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
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ñoListado 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
36
Es parte de Nombre Tamaño
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
37
Es parte de Nombre Tamaño
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
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
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
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
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
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
43
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
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
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.
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:
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”.
