análisis de exactitud en la estimación del tamaño148.206.53.84/tesiuami/uami15652.pdf · este...
TRANSCRIPT
1
2
ÍNDICE GENERAL
INTRODUCCIÓN ..................................................................................................................................... 3
OBJETIVOS ............................................................................................................................................. 4
1. OBJETIVO DEL PROYECTO TERMINAL ................................................................................................. 5
2. PERSONAL SOFTWARE PROCESS (PSP) ............................................................................................... 5
3. PASOS DEL PROCESO PSP .................................................................................................................. 6
3.1 PSP 0 ............................................................................................................................................... 7 3.2 PSP 0.1 ........................................................................................................................................... 7 3.3 PSP 1 .............................................................................................................................................. 7 3.4 PSP 1.1 ........................................................................................................................................... 7 3.5 PSP 2.0 ........................................................................................................................................... 7 3.6 PSP 2.1 ........................................................................................................................................... 7 3.7 PSP 3.0 ........................................................................................................................................... 7
4. REPORTE R5 ...................................................................................................................................... 8
4.1 RESUMEN DEL PLAN DEL REPORTE R5 ............................................................................................... 8 4.2 ANÁLISIS DE EXACTITUD EN LA ESTIMACIÓN DEL TAMAÑO ............................................................................... 9 4.3 ANÁLISIS DE LA EXACTITUD EN LA ESTIMACIÓN DEL TIEMPO........................................................................... 12 4.4 ANÁLISIS DE DEFECTOS Y RENDIMIENTO .................................................................................................... 15 4.5 ANÁLISIS DE CALIDAD ............................................................................................................................ 17
5. TEAM SOFTWARE PROCESS ( TSP) .................................................................................................... 18
6. TALLER DE LANZAMIENTO TSP ......................................................................................................... 18
6.1 JUNTA 1 DEL TALLER DE LANZAMIENTO .................................................................................................... 19 6.2 JUNTA 2 DEL TALLER DE LANZAMIENTO .................................................................................................... 20 6.3 JUNTA 3 DEL TALLER DE LANZAMIENTO .................................................................................................... 23 6.4 JUNTA 4 DEL TALLER DE LANZAMIENTO .................................................................................................... 26 6.5 JUNTA 5 DEL TALLER DE LANZAMIENTO .................................................................................................... 27 6.6 JUNTA 6 DEL TALLER DE LANZAMIENTO .................................................................................................... 28 6.7 JUNTA 7 DEL TALLER DE LANZAMIENTO .................................................................................................... 29 6.8 JUNTA 8 DEL TALLER DE LANZAMIENTO .................................................................................................... 31 6.9 JUNTA 9 DEL TALLER DE LANZAMIENTO .................................................................................................... 32
7. CONCLUSIONES ................................................................................................................................ 33
8. BIBLIOGRAFÍA .................................................................................................................................. 33
9. ANEXOS ........................................................................................................................................... 34
9.1. TAREAS REALIZADAS DURANTE EL CURSO ...................................................................................... 34 9.1.1 TAREA 1A ...................................................................................................................................... 34 9.1.2 TAREA 2A ...................................................................................................................................... 36 9.1.3 TAREA 3A ...................................................................................................................................... 37 9.1.4 TAREA 4A ...................................................................................................................................... 39 9.1.5 TAREA 5A ...................................................................................................................................... 41 9.1.6 TAREA 6A ...................................................................................................................................... 44 9.1.7 TAREA 7A ...................................................................................................................................... 47 9.1.8 TAREA 8A ...................................................................................................................................... 53 9.1.9 TAREA 9A ...................................................................................................................................... 54 9.1.10 TAREA 10A .................................................................................................................................. 56
3
INTRODUCCIÓN
Las computadoras se han convertido en una herramienta muy importante en la vida del
ser humano, es utilizada prácticamente en cualquier área de trabajo. El desarrollo del ser
humano en la actualidad se encuentra ligado al uso de las computadoras. Con ella
podemos realizar aplicaciones que anteriormente eran muy difíciles de resolver, sin la
utilización de este equipo, dichas aplicaciones nos ayudan en las tareas que se realizan
todos los días en distintos sectores de la sociedad, como pueden ser negocios, servicios
públicos, educación entre otros, es por esta razón que un fallo en dicho software
provoca una infinidad de problemas o en el peor de los casos, grandes pérdidas
económicas.
Para evitar dichas contrariedades , en los últimos años se han realizado grandes
esfuerzos para producir las aplicaciones con mayor eficiencia, en menor tiempo de
desarrollo y con mayor calidad, para cumplir éstos objetivos es necesario aplicar un
enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y
mantenimiento de software, es decir la aplicación de la Ingeniería en el software.
La Ingeniería de software es la rama de la ingeniería que crea y mantiene las
aplicaciones de software aplicando tecnologías y prácticas de las ciencias
computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros
campos. Es relativamente nueva ya que surge a finales de las años 60’s. Comienza con
una serie de tareas que hacen modelos y que resultan en una especificación completa de
requisitos y una representación comprensiva de diseño del software que será construido.
La ingeniería de software requiere llevar a cabo una serie de tareas, sobre todo las
siguientes:
Análisis de requisitos: Es la primera etapa para crear el programa. El cliente especifica
que es lo que quiere que el sistema realice.
Especificación: Es la tarea de describir detalladamente el software a ser escrito.
Diseño y arquitectura: Se refiere a determinar como funcionará de forma general sin
entrar en detalles.
Programación: Es esta fase se empieza codificar el diseño.
Prueba: Se comprueba que el software realice las tareas para el cual fue diseñado, se
recomienda probar por separado cada módulo y ver que funciona correctamente.
Documentación: Realización del manual de usuario, y posiblemente un manual técnico
con el propósito de mantenimiento futuro y ampliaciones al sistema.
Dentro de todos los procesos utilizados actualmente en del desarrollo de software
podemos encontrar los procesos de PSP (Personal Software Process) y TSP (Team
Software Process), al ser procesos que cuentan con pasos definidos para administrar y
controlar el proceso de desarrollo de aplicaciones, iniciando desde el ambiente personal
para poder llegar a la correcta formación de un equipo disciplinado, hasta culminar en la
correcta planeación y administración de proyectos de desarrollo de aplicaciones.
Llevando a cabo estos procesos podemos tener una muy buena estimación de los
tiempos a emplear, la calidad que se esta obteniendo, los contratiempos y los recursos a
emplear del desarrollo de software y llegar a entregar a tiempo y en calidad el producto.
4
OBJETIVOS
Los objetivos del proyecto Terminal son los siguientes:
Conocer las etapas o fases del proceso PSP para poder tener un buen
desempeño en el desarrollo de un producto de software.
Aprender a desarrollar un producto de software mediante etapas eficientes y
ordenadas propuestas por las fases de PSP I
Aprender a utilizar cada una de las plantillas de PSP para mejorar mi proceso de
desarrollo de software.
Aprender y comprender los distintos métodos de medición propuestos por el
PSP, de esta manera conocer mis medidas actuales de desempeño y para el final
del curso aumentarlo de la mejor manera posible.
Tener una buena estimación de tamaño, tiempo y defectos para poder generar
objetos de software de mejor calidad y al mismo tiempo tener una
productividad buena.
5
1. OBJETIVO DEL PROYECTO TERMINAL
Este proyecto terminal tiene como principal objetivo capacitar a cada uno de los
alumnos que deciden tomarlo en el Proceso Personal de Software (PSP) para poder, al
final del proyecto, estar en posición de ser miembro de un equipo TSP (Proceso de
Software en Equipo [Team Software Process] ).
De manera implícita al ser capacitados en PSP se tiene como objetivos la mejora
personal en el desarrollo y la calidad de los productos de software que generemos de
hoy en adelante.
2. PERSONAL SOFTWARE PROCESS (PSP)
El PSP es un proceso personal para desarrollar software que cuenta con:
• pasos definidos
• formas
• estándares
El PSP es una línea de trabajo de medición y análisis que nos ayuda a determinar los
atributos peculiares de nuestro trabajo, de modo que nos ayuda a mejorar nuestro
desempeño.
Fig. 1 Flujo del proceso del PSP
El PSP es un proceso diseñado para un uso individual, basado en prácticas de software
industrial reducidas cuyo principal objetivo es ayudar a los ingenieros de software a
realizar mejor su trabajo, también está diseñado para demostrar el valor de utilizar
procesos definidos y medidos.
6
El PSP aplica a tareas personales estructuradas.
• desarrollo de módulos de programa
• definición de requerimientos o procesos
• conducción de revisiones o pruebas
• escritura de documentación, etc.
PSP puede ser extendido para soportar el desarrollo de sistemas de software de gran
escala.
Es un proceso de nivel 5 para individuos y un prerrequisito para el Proceso de Software
en Equipo (TSP Team Software Process).
Finalmente, el PSP está pensado para ayudar a los ingenieros y organizaciones a
cumplir la fuerte y creciente demanda por sistemas de software de calidad.
3. PASOS DEL PROCESO PSP
El PSP se introduce en 7 pasos compatibles y progresivos.
Evolución del PSP
PSP1 .1 Planeación de Tareas
Planeación de Calendario
PSP3 Desarrollo Cíclico
PSP2 Revisiones de Código
Revisiones de Diseño
PSP2 .1 Plantillas de Diseño
PSP1 Estimación de Tamaño
Reporte de Pruebas
PSP0 Proceso Actual
Registro de Tiempo Registro de Defectos
Estándar de Tipos de Defectos
PSP0.1 Estándar de Código Medición de Tamaño
Propuesta de Mejora de Procesos (PIP)
Proceso personal cíclico
Administración de Calidad Personal
Proceso de Planeación Personal
Proceso Personal de Referencia
7
3.1 PSP 0
El primer paso en el PSP es establecer la línea base que incluye algunas mejoras básicas
y un formato de reporte. En este primer paso mediremos nuestro proceso registraremos
nuestros tiempos de desarrollo y clasificaremos los defectos.
3.2 PSP 0.1
El segundo paso es una mejora del PSP 0 ya que agregaremos un estándar de
codificación y un estándar de conteo para medir el tamaño del software que se produce,
en esta paso introduciremos una propuesta de mejora de procesos (forma PIP).
3.3 PSP 1
El objetivo del PSP 1 es establecer un procedimiento ordenado y repetido para el
desarrollo de estimación de tamaño, en este paso se maneja una estimación de tamaño y
una plantilla de reporte de pruebas.
3.4 PSP 1.1
En el PSP 1.1 se incluyen las plantillas de planeación de tareas y de calendario de
trabajo, pero nosotros no lo utilizaremos en los programas que vamos a desarrollar ya
que son programas pequeños y estas formas se utilizan cuando los proyectos tardan
varios días y semanas.
3.5 PSP 2.0
El objetivo del PSP 2.0 es llegar a la fase de compilación y pruebas con la mínima
cantidad de errores para esto se introduce una fase de revisión de diseño lo cual elimina
errores de lógica del programa, también se introduce una fase de revisión de código lo
cual nos permitirá filtrar errores antes de entrar a la fase de compilación. Para llevar a
cabo estas revisiones se agrega una lista de revisión de diseño y una lista de revisión de
código.
3.6 PSP 2.1
El objetivo del PSP 2.1 es dirigir el proceso de diseño, para esto utiliza cuatro tipos de
plantillas para representar el diseño, las cuales son:
1. Plantilla de escenario operacional.
2. Plantilla de especificación funcional.
3. Plantilla de especificación de estado.
4. Plantilla de especificación de lógica.
3.7 PSP 3.0
El objetivo del PSP 3.0 es escalar los métodos de PSP a proyectos más grandes. La
idea es subdividir un programa grande en piezas donde se pueda utilizar el PSP 2.
8
4. REPORTE R5 Este es el reporte de la segunda parte del curso, el cual da una referencia para analizar
mi proceso personal durante el mismo y de esta manera poder establecer que tanto
cumplí con las metas establecidas en la mitad del curso, así como concretizar mis
puntos débiles y las áreas de mejora, todas las estadísticas de la presente sección se
obtienen de la recopilación y análisis de los resultados obtenidos a través de cada una de
las 10 tareas realizadas durante el curso (ver Anexo 9.1).
4.1 RESUMEN DEL PLAN DEL REPORTE R5
Estudiante Gama García Ricardo
Instructor Carreaga Castro Luís Fernando
Datos de Tamaño Estimación de Esfuerzo
Objeto Número
Planeado
Número
Real
Esf. Est. por
Objeto
Esfuerzo
Estimado
Gráfica 14 14 12 168
Párrafo 35 32 10 350
Tabla 14 15 8 112
Total 30 630
Datos de Esfuerzo
Fase Tiempo Plan. Tiempo Real
Planeación 9 11
Desarrollo 630 539
Postmortem 15 12
Total 654 562
Como se pudo ver en la tabla, el total de tiempo que fue requerido para la realización
del reporte R5 fue de 562 min.
9
4.2 Análisis de Exactitud en la Estimación del Tamaño
¿Cumplí las metas de estimación de tamaño que definí en el reporte de medio
curso? ¿Por qué si o por qué no?
Las metas de estimación de tamaño que definí en el reporte de medio curso fueron
cumplidas, la siguiente tabla y grafica demuestran que se cumplió la meta de tener un
error menor al 15% en las tareas posteriores al reporte de medio curso (R4), esto es de
la tarea 7 a la tarea 10.
No. Tarea LOC's Estimadas LOC's Reales Error % Error
1 0 119 119.00 0.00
2 220 211 9.00 -4.09
3 56 72 16.00 28.57
4 60 100 39.50 65.30
5 130 116 13.75 -10.60
6 200 235 34.87 17.42
7 122 114 7.58 -6.23
8 100 99 0.58 -0.58
9 160 162 1.77 1.11
10 400 392 8.45 -2.11
Tabla de Loc’s Estimadas y Loc’s Reales.
¿Qué tan frecuentemente mi estimado de tamaño estuvo dentro del intervalo
estadístico de predicción del 70% y 90%?
Como podemos ver en la siguiente tabla, las tareas posteriores al R4 estuvieron dentro
del intervalo de predicción del 70%.
10
No. Tarea LOC Estimadas LPI(70%) UPI(70%)
7 122 85 158
8 100 66 133
9 160 131 189
10 457 379 535
¿Tengo una tendencia de agregar/olvidar objetos completos?
Tengo una tendencia a olvidar objetos completos, en la tarea 9 se me olvidaron 2/11 y
en la tarea 10 se me olvido 1/11.
¿Tengo una tendencia de mal juzgar el tamaño relativo de los objetos?
Considero que no tengo una tendencia de mal juzgar el tamaño relativo de los objetos,
esto se debe en gran medida a que contaba con datos históricos permitiendo con ello
definir una buena aproximación.
La siguiente tabla muestra el % de error de estimación de tamaño de cada modulo de los
programas 7A-10A, se puede ver que en general la estimación es buena para la mayoría
de los módulos.
No. Tarea LOC Estimadas LOC Reales % Error Objecto
7 10 10 0.00 Resultado
20 25 20.00 Significancia
30 47 36.17 Principal7A
45 32 40.63 Correlación
8 48 47 2.13 Principal 8A
18 25 28.00 Sort
19 27 29.63 Resultado
9 19 18 5.56 Normalidad
29 31 6.45 Principal9A
10 9 11.11 FuncionX2
80 91 12.09 Cálculos
8 7 14.29 Resultado
10 90 86 4.65 Cálculos
90 86 4.65 Gauss
15 16 6.25 Resultado
125 138 9.42 Rango
45 51 11.76 Principal10A
15 13 15.38 Estimados
11
¿Necesito calcular los datos del rango de tamaño relativo utilizando mis datos
históricos de datos de objeto? ¿Puedo hacerlo?
En la mayoría de los casos es fundamental realizar el cálculo de los datos del rango de
tamaño relativo utilizando mis datos históricos de datos de objeto. En general, entre mas
datos históricos tenga se podrá hacer un mejor estimación del tamaño de los módulos.
Basado en mis datos históricos de estimación de tamaño, ¿qué meta de estimación
de tamaño es realista para mí?
La meta de estimación de tamaño realista para mi, es aquella en la cual debo de obtener
un error menor al 10% en mis futuras tareas.
¿Cómo puedo modificar mi proceso para cumplir esa meta?
Uno de los cambios que podría hacerle al proceso sería que cuando analice cada objeto,
ver cada una de sus funciones y de ahí hacer un conteo de las líneas que tendría cada
función pero con más atención de lo que lo hago hasta ahora, y con ello obtener el
conteo para todo el objeto.
12
4.3 Análisis de la Exactitud en la Estimación del Tiempo
¿Cumplí las metas de estimación de tiempo que definí para mí en el reporte de
medio curso? ¿Por qué si o por qué no?
La siguiente tabla y grafica demuestran definitivamente que no se cumplió la meta de
tener un error menor al 25% en las tareas posteriores al R4, solo se cumplió en 2/4
tareas.
No. Tarea Tiempo Estimado Tiempo Real Error % Error
1 125 138 13 10.40
2 175 241 66 37.78
3 85 77 8 -9.41
4 130 160 30 22.96
5 162 230 68 42.16
6 284 278 6 -2.00
7 198 195 3 -1.52
8 155 264 109 70.33
9 228 344 116 50.76
10 489 542 53 10.78
Tabla de Tiempo Estimado y Tiempo Real.
Analizando mis estimaciones puedo llegar a la conclusión que las variaciones mostradas
en el siguiente gráfico se debieron a los siguientes factores:
13
1. Introducción de las diferentes plantillas de diseño del proceso PSP 2.1 para las
tareas 8A, 9A y 10A
a. plantilla de escenario operacional
b. plantilla de especificación funcional
c. plantilla de especificación de estados
d. plantilla de especificación lógica
2. Subestimación de tiempo en la fase de codificación.
Tiempo Estimado vs Real
0
100
200
300
400
500
600
0 1 2 3 4 5 6 7 8 9 10
Núm. de Programa
LO
C´s Est. Tiempo
Tiempor Real
¿Qué tan frecuentemente mi estimado de tiempo estuvo dentro del intervalo
estadístico de predicción del 70% y 90%?
Aun cuando las metas del reporte R4 no se cumplieron, todas las tareas posteriores al
R4 estuvieron dentro del intervalo estadístico de predicción del 70%, esto se puede ver
en la siguiente tabla:
No. Tarea Tiempo Estimado UPI(70%) LPI(70%)
7 198 134 262
8 155 102 208
9 228 162 294
10 489 338 640
¿Mi productividad es estable? ¿Por qué si o por qué no?
La productividad para la primera parte del proceso se mantuvo estable en un promedio
de 46.5 LOC/Hora, al introducir las Plantillas de Diseño la productividad bajo
notablemente para los programas 8A y 9A, recuperando la estabilidad con el programa
10A con 43.5 LOC/Hora, esto se puede ver en el siguiente grafico:
14
¿Cómo puedo estabilizar mi productividad?
La productividad la puedo estabilizar mejorando mi estimación de tamaño y tiempo, a
su vez implica mejorar en la comprensión de los requerimientos del programa así como
mejorar la fase de diseño y con ello buscar incrementar mi productividad en futuros
programas.
¿Cuánto son afectados mis estimados de tiempo por la exactitud de mis estimados
de tamaño? (¿La regresión múltiple me ayudaría?)
La estimación de tamaño es un punto crucial a partir del cual se obtiene la estimación
del tiempo, si la estimación de tamaño tiene un gran error seguramente la estimación de
tiempo será afectada.
En definitiva la regresión múltiple ayuda de forma importante a estimar con una muy
buen exactitud la estimación de tiempo en base a los intervalos de predicción.
Como conclusión tenemos que la estimación de tamaño si afecta directamente a la
estimación de tiempo, sin embargo la estimación de tiempo no afectara las estimaciones
de tamaño.
Basado en mi exactitud histórica de estimación de tiempo, ¿qué meta de estimación
de tiempo es realista para mí?
Una meta realista para mi es aquella en la cual debo de obtener un porcentaje de error
menor al 15% en mis futuras tareas.
15
¿Cómo puedo modificar mi proceso para cumplir esa meta?
En base a mis datos históricos de porcentaje de estimación de tamaño, deberé agregar
un 15% de tiempo a mis estimaciones, teniendo en cuenta que mi tendencia a la hora de
realizar estimaciones de tiempo es la de subestimar.
4.4 Análisis de Defectos y Rendimiento
¿Qué tipos de defectos introduzco durante el diseño y la codificación?
Durante la etapa de diseño, el tipo de los defectos que introduzco son:
Tipo No. De defectos
40 - Asignación 3
50 - Interfaz 1
60 - Cheque de
Tipos 3
80 - Función 4
11/50
Durante la etapa de codificación el tipo de los defectos que introduzco son:
Tipo No. De defectos
20 - Sintaxis 16
40 - Asignación 6
50 - Interfaz 1
60 - Cheque de
Tipos 3
80 - Función 9
35/50
¿Qué tendencias son aparentes en defectos por KLOC encontrados en revisiones,
compilación y pruebas?
La finalidad de las revisiones es la cachar la mayor parte de los defectos, para que de
esta forma al pasar a las fases posteriores, los defectos sean muy pocos y se ahorre el
tiempo de ejecución de estas fases, así como también para aumentar la calidad en la fase
de desarrollo.
Vemos que la cantidad de defectos/KLOC durante la revisión de diseño esta por abajo
de 30 KLOC’s para las últimas 2 tareas y la cantidad de defectos para la revisión de
código es menor 7 defectos/KLOC, lo cual se considera que es bueno.
16
Para las fases de compilación y pruebas, gracias a las revisiones de diseño y código, el
número de efectos disminuyo considerablemente, podemos ver en las graficas que el
número de defectos para la fase de compilación disminuyo de 20 KLOC’s a 7KLOC’s
para la tarea 10A. Y para la fase de pruebas en los últimos 3 programas se mantuvo un
promedio de 7 defectos/KLOC. Para finalizar la tendencia consiste en dejar cada vez
menos defectos, al pasar a una nueva fase, para aumentar la calidad del producto y el
tiempo de desarrollo.
La tendencia principal es que a partir de las revisiones se encuentran casi el doble de
defectos en la fase de pruebas que en codificación.
Fase No. De defectos
CR 3
TEST 8
11/50
17
4.5 Análisis de Calidad
¿Alcance las metas propuestas en el reporte R4 para la calidad? ¿Porque si ó
porque no?
Sí, porque se ha logrado minimizar el numero de errores cometidos, en especial del tipo
sintáctico que era el más común en la tareas pasadas.
¿Cómo puedo juzgar la calidad de mi producto final en el ciclo de desarrollo?
Por el total de defectos encontrados por KLoc’s. En este caso, en las últimas cuatro
tareas se minimizo el numero de defectos por KLoc’s a 8.155.
Num
Programa Calidad
7 0
8 0
9 14.39
10 18.23
¿Estoy encontrando mis defectos en las revisiones de diseño y codificación? ¿Por
qué si ó por qué no?
No, porque a diferencia de las tareas anteriores en que introducía errores de tipo
sintáctico, ahora no son cometidos, y los errores que no son eliminados por las
revisiones, son errores inconscientes debido a una mala comprensión del problema.
¿Qué puedo hacer para que mi proceso sea más efectivo y más eficiente?
Así como minimice el número de errores de tipo sintáctico entre otros, ahora debo
minimizar el número de errores de tipo funcional y asignación, para lo que debo ser más
consiente en la plantación y diseño de cada uno de los programas a realizar. Con esto no
solo minimizare el total de errores en general sino también mis estimados de tiempo y
tamaño mejoraran considerablemente.
Basado en mi información histórica, ¿cuáles son las metas de calidad para mí?
Tener en cada tarea un Total de defectos por KLoc’s aproximadamente de 10 errores
por KLoc’s.
¿En qué debo cambiar mi proceso para que mis metas se cumplan?
Creo que el proceso PSP hasta ahora es eficiente, sin embargo yo debo ser más
disciplinado, organizado, paciente y por ultimo pero no menos importante adquirir
practica, esta solo la adquiriré trabajando.
18
5. TEAM SOFTWARE PROCESS ( TSP)
El TSP es una línea de trabajo y un proceso estructurado para construir y guiar equipos
de ingeniería que desarrollan software.
El TSP contiene
• un proceso de integración de equipo que trata los aspectos de objetivos,
compromiso, cohesión y estructura del equipo
• un proceso de trabajo en equipo que trata los procesos y prácticas de
ingeniería usadas por el equipo
Un prerrequisito para que un equipo use el TSP es un entendimiento de las habilidades
de ingeniería de software y procesos enseñados en el PSP.
Fig. X Puntos indispensables para una integración exitosa de Quipos con TSP.
6. TALLER DE LANZAMIENTO TSP
El proceso TSP marca la realización de nueve juntas, en las cuales se tratan
objetivos muy específicos, en cada una de ellas se llena una bitácora con las actividades
realizadas y a continuación se muestra los resúmenes de cada una de las ocho juntas.
19
6.1 Junta 1 del Taller de Lanzamiento
Propósito: En esta junta, un director con el conocimiento correspondiente presenta el
producto o la entrega del producto a ser generado. El objetivo es proporcionar a todos
los miembros del equipo un entendimiento común de lo que se espera del futuro
proyecto.
Un director se reúne con el equipo para describir las metas de la organización y
responder las preguntas del equipo.
Líder de la Presentación: La presentación es llevada por un director quien entiende el
producto deseado, lo que el cliente y usuarios previstos intentarán hacer con este
producto y el tipo de producto que la dirección desea generar.
Resultado buscado: Después de esta presentación, el equipo debería apreciar los
deseos de la dirección y de los clientes/usuarios y será capaz de proceder con la
planeación del desarrollo. El equipo será capaz de hacer mejores compromisos
negocio/funciones/tecnología a lo largo del proyecto y generará un producto más
deseable.
Objetivos del proyecto con la dirección
Sistema que controle costos de alimentos.
Logística de confección del menú
Procedimientos
Administración del banquete: Registro, cotización, contratación,
consecución del banquete.
Atacar oportunidades de negocio:
Precios competitivos
Productos de alta calidad
Servicios de alta calidad
Control sobre tienda comercializadora
Compras
Pedidos a proveedores
Control sobre sucursales
Servicio a domicilio: vía telefónica y por internet.
Objetivos del proyecto con la comercialización
Parte publica
Portal web del restaurante: información general, información de contacto,
reservaciones y solicitudes disponible para el público en general.
20
Parte interna
Recetas (ingredientes, procedimiento, responsable).
Plan de realización de recetas diario, cantidad de ingredientes por número de
personas.
Posmortem de la realización de recetas: ganancias, recetas generadas.
Manejar un catalogo de insumos con sus entradas y salidas en la bodega.
Manejar todas las etapas del banquete,
Reportes y consultas del estado del almacén.
Reportes y consultas sobre las recetas, platillo(s) exitoso(s) y peor platillo.
A continuación se mencionan las metas de la dirección que se tienen que
cumplir para el proyecto:
Metas de la dirección del proyecto
Mínimas Medias Ideales
Control de las
recetas
Control de las recetas
Procedimientos
Administración del
banquete.
Control de las recetas
Procedimientos
Administración del
banquete.
Control sobre tienda
comercializadora.
Control sobre sucursales.
Servicio a domicilio.
6.2 Junta 2 del Taller de Lanzamiento
Los objetivos que se trataron en esta junta fueron los siguientes:
Revisión de las metas de la dirección
Una vez concluida la junta 1, el equipo revisó las metas de la dirección, una vez
terminado con el análisis se llegaron a concretizar las siguientes metas:
METAS DE DIRECCIÓN
Control de los costos de los alimentos
Atacar las oportunidades de negocios
Control sobre tienda comercializadora
Control sobre sucursales
Controlar entregas a domicilio
Control de banquetes
Fecha de entrega (1 de Diciembre)
Disponer de un portal del restaurante
Incrementar las ventas
Disponer de un sistema fácil de utilizar(desde cualquier punto)
Administrar entradas y salidas del almacén
Administrar los banquetes
Disponer de la logística para la confección de los menús
Administrar los pedidos a proveedores
21
Definición de metas implícitas
A pesar de que la dirección dio al equipo sus metas explícitas en la primer junta ,
se puntualizaron aquellas metas que , tal vez, de manera inconsciente la
dirección expuso al equipo y que son de vital importancia para realizar, por
ejemplo, una mejor estimación de los tiempos de desarrollo. Al realizar un
amplio análisis se obtuvieron las siguientes metas implícitas:
METAS IMPLICITAS
Controlar la seguridad del sistema
Disponer del portal en cualquier momento (24Hrs., 365días)
Disponer de un portal del restaurante fácil de mantener
Contar con un sistema cuyos tiempos de respuesta sean los adecuados
Contar con diferentes niveles de administración del sistema
Contar con un sistema que realice pago en línea
Establecimiento de las metas del equipo
Aunque las metas que la dirección otorga al equipo son importantes, no se puede
dejar a un lado aquellas metas que el equipo desea llegar a cumplir, ya que
influyen de manera directa en todo el proceso de construcción de una nueva
aplicación y es por esta razón que nosotros como equipo de TSP nos hemos
planteado como metas los siguientes puntos:
Meta del equipo
Ejercitar el TSP
Entregar un producto de calidad
Entregar el proyecto con los requerimientos mínimos
Crear nuestro propio estándar de codificación
Tener jornadas de trabajo para el proyecto razonables
Evitar conflictos
Estas metas se encuentran registradas en la Forma GOAL del libro de trabajo de
TSP.
Selección de los roles del equipo
A pesar de que todo el equipo ha recibido el entrenamiento PSP es necesario
designar el rol que cada uno de los integrantes debe jugar dentro del mismo, ya
que se está trabajando en equipo. En la siguiente tabla se pueden observar las
personas asignadas a cada uno de los roles tanto como a la persona principal y al
suplente de cada uno de ellos.
Roles de Miembros del
Equipo Responsables
Líder Oficial del
Equipo
P Aida
A Armando
Administrador de la
Interfaz con el Cliente
P Ricardo
A
Administrador del
Diseño
P Rafael
A David
Administrador de
Implementación
P Oscar
A
22
Asignación de la responsabilidad de seguimiento de las metas
Como el punto lo indica, se tuvo que asignar a la(s) persona(s) responsable(s) de
dar seguimiento a una meta en especial, esto se hace para ver si se cumplen o no
las metas mencionadas en puntos previos, en caso de que no se estén cumpliendo
tomar las adecuadas decisiones y/o acciones para poder cumplir dichas metas. A
continuación se enlistan las metas más importantes para el equipo así como el
responsable de su seguimiento:
META RESPONSABLE
Control de los costos de los alimentos Ricardo
Atacar las oportunidades de negocios Julio
Control sobre tienda comercializadora David
Fecha de entrega (1 de Diciembre) Aida
Disponer de un sistema fácil de utilizar(desde cualquier punto) Ricardo
Administrar entradas y salidas del almacén David
Administrar los banquetes Armando
Disponer de la logística para la confección de los menús Aida
Administrar los pedidos a proveedores Julio
Controlar la seguridad del sistema Edgar
Disponer del portal en cualquier momento (24Hrs., 365días) Fabián
Disponer de un portal del restaurante fácil de mantener Julián
Contar con un sistema cuyos tiempos de respuesta sean los adecuados Rafael
Contar con diferentes niveles de administración del sistema Oscar
Ejercitar el TSP Edgar
Entregar un producto de calidad Julián
Entregar el proyecto con los requerimientos mínimos Aida
Crear nuestro propio estándar de codificación Armando
Tener jornadas de trabajo para el proyecto razonables Fabián
Evitar conflictos Aida
Administrador de la
Planeación
P Fabián
A
Administrador del
Proceso
P Edgar
A
Administrador de la
Calidad
P Julián
A
Administrador de
Soporte
P Julio
A
Administrador de
Pruebas
P Armando
A
23
6.3 Junta 3 del Taller de Lanzamiento
Las actividades que se realizaron durante la junta 3 fueron:
Diseño Conceptual del producto restaurante LUCAS En esta etapa se definieron los principales componentes del producto,en base al
análisis realizado por el equipo de desarrollo del sistema, se realizó el siguiente
modelo conceptual, el cual cumple con todos los requerimientos.
A: Altas
B: Bajas
C: Cambios
Estimación gruesa del tamaño de cada componente En este punto se realizó una estimación de tamaño de cada uno de los
componentes escritos en el diseño anterior, cabe señalar que esta la primera
estimación no se realiza detalladamente, resultando ser una estimación “gruesa”,
a continuación se muestran los resultados de dicho aproximado de líneas de
código por módulo:
Sistema Web restaurante: 400 Líneas
Recetas Vs Insumos: 1200 Líneas
Costo Recetas: 300 Líneas
Recetas: 200 Líneas
A: Altas recetas 500 Líneas
B: Bajas recetas 350 Líneas
C: Cambios recetas 600 Líneas
Banquetes: 250 Líneas
Lista Plantilla 500 Líneas
Control de almacén: 200 Líneas
A: Altas almacén 500 Líneas
Sistema Web
restaurante
Recetas
Vs
Insumos
Lista
plantilla
Recetas
Cotizaci
ón
Banquete
s
Costo
Recetas
Control
de
almacén
Segurida
d
Logística Registro Contrataci
ón
P
C
B
A
C
B
A
24
B: Bajas almacén 350 Líneas
C: Cambios almacén 600 Líneas
P: Pedidos 400 Líneas
Seguridad: 800 Líneas
Logística: 350 Líneas
Cotización: 300 Líneas
Registro: 600 Líneas
Contratación: 400 Líneas
Total de líneas de código: 8800 Líneas de código
Definición de la estrategia de desarrollo del producto La estrategia elegida nos sirvió para registrar las dediciones estratégicas, así
como asignar las funciones del producto dentro de los ciclos de desarrollo que
más adelante nos serviría para un diseño de alto nivel.
En la siguiente tabla se muestran los resultados, componentes o elementos
principales del producto, el numero de ciclos de desarrollo, tamaño estimado
(LOC’S) y horas de desarrollo del producto, que fueron incluidos en cada ciclo.
LOC del Ciclo Horas del Ciclo
Componente, Elemento o
Característica
1 2 3 4 1 2 3 4
700 500 23 17
Costo Recetas 300 10
Seguridad 200 200 200 200 7 7 7 7
Recetas 100 100 3 3
Altas recetas 500 17
Bajas recetas 350 12
Cambios recetas 600 20
Control Almacén 100 100 3 3
Altas Almacén 500 17
Bajas Almacén 350 12
Actualización Almacén 600 20
pedidos 400 13
Banquetes 250 8
Logística 350 12
Cotización 300 10
Registro 600 20
Contratación 400 13
Lista de Platillos 500 17
Restaurante 100 100 100 100 3 3 3 3
TOTAL 2500 3150 2850 300 84 105 94 10
25
Definición del proceso de desarrollo Aquí se definió el proceso general de desarrollo hasta la entrega final.
La siguiente tabla muestra las principales actividades de cada fase.
Los elementos mostrados anteriormente pueden ser utilizados como un punto de
inicio y pueden posteriormente ser refinados conforme sea necesario.
Definición del plan de desarrollo del producto En este punto se enlistaron los elementos del proceso que se planearon
desarrollar y/o modificar, se determinaron y registraron el numero de elementos
y numero de paginas a ser modificados y desarrollados nuevos, la fecha o fase en
que se necesito, horas requeridas para el desarrollo, modificación, y la
asignación de cada ingeniero los elementos a desarrollar.
Definición del plan de soporte Se revisaron las herramientas e instalaciones disponibles para el desarrollo del
producto.
Equipo
5 equipos en el LIS
5 equipos personales
Requerimientos
Word
STAR UML
Diseño
STAR UML
Codificación
ambiente Eclipse(3.3.1.1)
plug-in J2EE para eclipse
plug-in sub-versión
Base de datos
MySQL 5.2
Pruebas
1 Contador de LOCs WEB
2 Seguimiento de defectos en EXCEL
3 Revisión de requerimientos
4 Revisión de diseño de alto nivel
5 Check List de revisión de requerimientos
6 Check List de revisión de diseño de alto nivel
7 Check List de inspección de diseño de alto nivel
8 Check List de inspección de codificación
9 Check List de inspección de requerimientos
10 Check List de inspección de diseño de nivel detallado
26
Word, Excel
Control de Versiones
subversión
Servidor
Tomcat 5
6.4 Junta 4 del Taller de Lanzamiento
Los objetivos que se trataron en la presente junta fueron:
Estimación de tamaño de cada elemento de la forma SUMS Para cada uno de estos elementos el administrador de diseño guió al equipo para
llevar acabo esta tarea, la siguiente tabla muestra cada uno de los estimados para
cada uno de los elementos del sistema referente al número de LOC’s:
# de LOC’s estimado
Costo recetas 300
Seguridad 800
Recetas Vs. Insumo 1200
Recetas 200
Banquetes 250
Lista Platillos 500
Control Almacén 200
Altas Recetas 500
Bajas Recetas 350
Cambios Recetas 600
Logística 350
Cotización 300
Registros 600
Contratación 400
Altas Almacén 500
Bajas Almacén 350
Cambios Almacén 600
Pedidos 400
Restaurante 400
En dicha forma(ver Anexo 2) también podemos encontrar los estimados para
checklist de revisión de requerimientos, así como un checklist de inspección de
codificación, plan de prueba y reporte de las mismas, estándares de diseño y
codificación, total de LOC’s del sistema, paginas de requerimientos, diseño de
alto nivel, etc.
Producir el plan de tareas El siguiente objetivo de la junta es producir un plan de tareas detallado para la
duración del proyecto, para cada una de estas tareas el administrador de
planeación guía al equipo a determinar el tiempo requerido para su elaboración,
para llevar acabo esto se usaron datos sobre la tasa de producción de cada uno de
27
los integrantes y mediante la media poder estimar su tiempo de elaboración, los
datos del plan de tareas se guarda en la forma Schedule(ver anexo 9.2.3).
6.5 Junta 5 del Taller de Lanzamiento
El propósito de la junta 5 fue generar los siguientes entregables:
Producir el plan de calidad
Se han establecido los datos de calidad las cuales son las siguientes:
Tener como mínimo el 80% de las pantallas para el portal.
Tener como mínimo un 60% de los requerimientos.
Tener una seguridad para transacciones del 100%.
Tener una densidad de defectos mínimos de 20 def/KLOC.
Y las jornadas de trabajo serán de 18 horas a la semana.
El programa tendrá 9400 LOC’s, y la cantidad de defectos introducidos y
eliminados es de 930.
Los índices de calidad que se deberán estar observando durante la realización del
proyecto serán los mostrados en la siguiente tabla:
La tabla anterior muestra los defectos esperados por KLOC en cada una de las
fases del proyecto, se deberán estar monitoreando constantemente ya que de
sobrepasar nuestros estimados, obtendremos automáticamente un producto de
baja calidad,cabe señalar que los datos mostrados en la tabla anterior y algunos
otros se almacenan en la forma SUMQ(ver anexo 9.3).
Producir el calendario de trabajo En este punto no se hace más que establecer fechas aproximadas en las que se
tendrán disponibles ciertos elementos del sistema que se desarrolla.
Defects/KLOC Plan
DLD Review 0.35
DLD Inspection 0.11
Code Review 66.06
Compile 14.16
Code Inspection 9.91
Unit Test 3.82
Build and Integration Test 0.34
System Test 0.07
Total Development 98.96
Acceptance Test 0.01
Product Life 0.01
Total 98.98
28
6.6 Junta 6 del Taller de Lanzamiento
El propósito de la junta seis fue ayudar al equipo a producir un plan balanceado de
tareas para la siguiente fase. Los pasos para conseguir este propósito fueron los
siguientes:
Asignación de las tareas a los miembros del equipo.
El administrador de planeación asigno cada una de las tareas de la hoja TASK a
los integrantes del equipo, quedando la hoja EXCEL como se muestra en la
figura siguiente.
Elaboración de copias del Workbook.
El administrador de planeación genero copias del Workbook para cada uno de
los integrantes del equipo oprimiendo el botón “Make copies of Workbook for
team members” en la plantilla Team. (Previamente en la hoja TEAM se crean
los nombres de las hojas de cálculo de cada integrante del equipo).
Miembros del equipo hacen planes individuales.
Cada integrante del equipo elimino de su hoja EXCEL las tareas que no le
correspondían y posteriormente asigno la cantidad de horas que tenían planeado
trabajar semanalmente hasta que la diferencia de horas en la plantilla Schedule
arrojo resultados negativos.
Balanceo de la carga de trabajo de el equipo.
El administrador de planeación guió al equipo para obtener un plan balanceado
de trabajo, es decir, que no hubiera una diferencia mayor de una semana a la
fecha planeada de terminación del proyecto, en promedio la planeación de
trabajo de los integrantes del equipo fue de 13 semanas.
Asignación de las tareas a los miembros del equipo.
29
El administrador de planeación asigno cada una de las tareas de la hoja TASK a
los integrantes del equipo, quedando la hoja EXCEL como se muestra en la
figura siguiente.
Consolidación de tareas.
Una vez que se logro el balanceo de las tareas, el administrador de planeación
presiono el botón “Consolídate plan” en la plantilla TEAM, los resultados
obtenidos en la plantilla SCEDULE fueron 1168 horas planeadas en 13
semanas.
6.7 Junta 7 del Taller de Lanzamiento
Los temas de la junta siete son los siguientes:
Conducir una evaluación de riesgo del proyecto
Es importante resaltar que para identificar los riesgos todos los integrantes del
equipo participan y no importa si el riesgo es muy pequeño o muy grande pues
primero sabemos cual es y después se definirán que grado de impacto tiene cada
uno de ellos.
El coach ayuda mucho en este tipo de decisiones pues de repente se puede
perder el concepto o ser repetitivo a continuación se enuncian los pasos
Identificación
de riesgos
El líder del equipo le pide al equipo que identifique riesgos.
Todos los miembros del equipo participan en sugerir riesgos.
Use un enfoque de lluvia de ideas; i.e., en este paso no evalúe riesgos.
El proceso continúa hasta que no puede pensarse en más riesgos.
Registre cada riesgo para ayudar al equipo en la evaluación subsiguiente.
Use un rotafolios o un pizarrón blanco.
Evaluación del
Impacto
Para cada riesgo, el equipo evalúa su impacto probable.
El impacto es alto si el efecto sobre el calendario de trabajo del proyecto
fuera importante.
Los riesgos también pueden tener impacto medio o bajo en el calendario de
trabajo.
Anote la evaluación del impacto. Use un rotafolios o un pizarrón blanco.
30
Evaluación de la
Probabilidad
Para cada riesgo, el equipo juzga su probabilidad.
La probabilidad se mide como alta, media o baja.
Anote la evaluación de la probabilidad. Use un rotafolios o un pizarrón
blanco.
Asignación de
Riesgos
Para los riesgos de prioridad alta y media (i.e. alta-alta, alta-media, media-alta o
media-media)
asigne un miembro para darle seguimiento al riesgo
defina una fecha límite para la cual deben tomarse las acciones de
mitigación
documente el riesgo, la responsabilidad y la fecha límite en la forma ITL
Mitigación de
Riesgos
Para los riesgos de prioridad alta y media, identifique aquellos que sean de corto
plazo.
Determine un plan de mitigación efectivo.
Recomiende acciones para reducir o eliminar el impacto del riesgo.
Resultado de los riesgos totales elegidos por el equipo
1 DESCRIPCION
2 NO HAY SUFICIENTES RECURSOS
3 FALTA DE CONOCIMIENTOS
4 RENUNCIA DE PERSONAL
5 INTEGRANTE ENFERMO
6 DESASTRE
7 FALTA DE EQUIPO
8 PERDIDA DE INFORMACION
9 ROBO DE INFORMACION
10 ESTIMACION EN TAMAÑO FUERA DE RANGO
11 MODIFICACION DE LOS REQUERIMIENTOS INICIALES
12 ENTREGA DE PROYECTO A DESTIEMPO
13 ROBO DE EQUIPO
14 INTERPRETACION EQUIVOCADA DE REQUERIMIENTOS
Ponderación del impacto y probabilidad de los riesgos
En el presente punto se valora el impacto que tiene cada uno de los riesgos, así
como su índice de probabilidad de ocurrencia; una vez cuantificados ambos
parámetros para cada riesgo se procedió a establecer uno o más responsables
que se dedicarán a observar que el riesgo propio sea mitigado de acuerdo a la
estrategia de mitigación, también acordada en esta junta, y finalmente una fecha
para dicho propósito. A continuación se muestra toda esta información en una
pequeña tabla que resume todo lo antes descrito:
IMPACTO PROBABILIDAD ASIGNACION
FECHA LIMITE
DE MITIGACION MITIGACION
ALTO MEDIA RH,AA
MEDIA MEDIA OR, DN 31-01-2008
CAPACITACION O GENERACION DE
PROTOTIPOS
ALTO MEDIA JJ,JD 20-01-2008 RESPALDO AUTOMATICO
MEDIO MEDIA JJ,JD REAJUSTE DE PLANEACIÓN
ALTO ALTA EP,RG PROCESO DE CONTROL DE CAMBIOS
MEDIA MEDIA FR 21-01-2008 CONTRATACION DE PERSONAL EXTRA
31
ALTO ALTA AC 21-01-2008
PROCESO DE REVISIÓN E INSPECCIÓN DE
LOS REQS.
6.8 Junta 8 del Taller de Lanzamiento
El objetivo de esta junta es preparar la documentación necesaria y al equipo para la
junta con la dirección; se analiza y discute el material a presentar y que integrantes del
equipo lo presentarán.
revisará el proceso de lanzamiento y los productos del mismo
revisará el plan del proyecto y cualquier pregunta o situación con este plan
La documentación que se generó para presentar a la dirección se realizó en base a la
siguiente guía:
El líder del equipo encabeza la junta presentando de forma general los objetivos
de la junta
Los miembros del equipo o el líder de equipo presentan:
Resumen breve del trabajo realizado durante el lanzamiento.
Se describen lo productos generados durante el lanzamiento.
Se entregan copias de los materiales producidos durante el lanzamiento.
La asignación de los roles del equipo.
Metas establecidas e implícitas de la dirección y metas del equipo
Calendario de trabajo del equipo.
Plan de calidad del equipo.
Evaluación de riesgo del equipo.
Estrategias de desarrollo y plan de entrega.
De existir se presenta un plan alternativo con recursos adicionales.
Cuando se requerirían recursos adicionales entrenados.
Cómo los recursos adicionales mejorarían el desempeño de las metas.
Los riesgos identificados por el equipo.
La evaluación del equipo de los riesgos clave.
Acciones de mitigación propuestas para cada riesgo clave.
La conclusión mediante un resumen de los elementos clave del plan y los
objetivos del reporte.
Con esto se demostrará a la dirección que el equipo de trabajo ha hecho un plan
pensado, realista y completo.
32
6.9 Junta 9 del Taller de Lanzamiento
El objetivo de esta junta es obtener la aprobación del plan de trabajo por parte de la
dirección.
Para lograr este objetivo se siguen los siguientes pasos:
El equipo revisa con la dirección su plan de proyecto y cualquier pregunta o
situación sobre el plan, en este punto el líder del equipo o un miembro del
equipo entrega copias de los productos de lanzamiento, revisa el proceso de
lanzamiento y describe cómo fue generado el plan.
El líder del equipo o miembro del equipo resume las metas del proyecto:
Metas establecidas e implícitas de la dirección.
Un resumen del plan y metas del equipo.
Cómo el plan y metas del equipo se compara con las metas de la
dirección.
Si la dirección le pide al equipo modificar o proporcionar un plan alternativo, el
equipo necesita comprender
los cambios deseados al plan de proyecto.
Que recurso o contenido de trabajo modifica el plan original.
Si se preparó un plan alternativo, el líder del equipo o un miembro del equipo
distribuye y revisa el plan alternativo y el impacto esperado.
Bajo ninguna circunstancia el equipo debe estar de acuerdo con un nuevo
calendario de trabajo o plan sin tomarse el tiempo de estudiar o re-planear el
trabajo.
El líder del equipo o un miembro del equipo revisa cada uno de los riesgos clave
del proyecto:
Resumiendo las probabilidades e impacto en el calendario de los
riesgos.
Analiza las recomendaciones de mitigación para los riesgos de alto
impacto.
El líder del equipo cuestiona si no hay preguntas y cierra la junta.
Cabe señalar que si en cualquier momento de la junta la dirección acepta el plan
de trabajo elaborado por el equipo la junta concluye inmediatamente a pesar de
que aun se tenga material por ser expuesto o analizado; por lo tanto el criterio de
salida de esta junta es el plan de trabajo aceptado por la dirección.
33
7. CONCLUSIONES
Hoy en día para poder desarrollar productos de software de calidad dentro de
los tiempos y costos estimados de desarrollo es muy importante la utilización de
procesos disciplinados de desarrollo para poder colocarlos dentro del mercado tan
competitivo de hoy en día.
Para poder llegar a cumplir con todas las características mencionadas es necesario
producir el software mediante el uso de procesos disciplinados, en este caso el uso de
PSP es muy importante en este aspecto; ya que me enseño a medir la calidad de mi
software en base a mis tiempos de desarrollo, cantidad de defectos introducidos,
filtrados y corregidos en las distintas fases que componen al PSP.
Ahora que fui entrenado en PSP tengo la capacidad de poder ser miembro de un equipo
TSP, en el cual no solo la calidad del desarrollo se ve desde el ámbito personal, sino que
ahora también se puede analizar desde la perspectiva grupal, es por esto que un equipo
TSP es más fácil de coordinar, el establecer las metas del equipo, calendarizar el
trabajo colectivo y de la mejor manera posible para poder generar un excelente producto
de software.
8. BIBLIOGRAFÍA
“A Discipline for Software Engineering”
Watts S. Humhrey
Addison – Wesley
USA, 2000
TSP Launch Workshop Notebook
http://www.sei.cmu.edu/tsp/psp.html
34
9. ANEXOS
9.1. TAREAS REALIZADAS DURANTE EL CURSO
En la siguiente sección se describe cada una de las tareas realizadas durante el curso de
PSP y al final de la descripción de cada una de ellas se muestran los resultados
obtenidos.
9.1.1 TAREA 1A
Requerimientos Calcular la media y la desviación estándar de una serie de n números reales.
Su programa debe leer los n números reales del teclado, de un archivo, etc.
Use una lista ligada para almacenar los n números para los cálculos.
Media y Desviación Estándar
La media es el promedio de n números.
La desviación estándar es calculada de la siguiente forma.
Std
xi xavg2
i 1
n
n 1
σ es el símbolo de la desviación estándar
∑ es el símbolo de la sumatoria
i es un índice de los n números
Xavg es el valor promedio de los n números
Listas Ligadas Son un tipo de datos abstracto utilizado para almacenar conjuntos de datos
implementadas con apuntadores.
Una lista ligada con frecuencia tiene estos componentes:
• raíz de la lista
• nodo de la lista
HEAD
NODE 1 NODE 2 NODE n... NODE n-1
Pointers to next node
Pointerto first node
Pointerto last node
Data Data Data Data
null
Algunas de las opciones para la estructura de listas ligadas son
•la raíz de la lista puede apuntar al primer nodo, último nodo, o a ambos
•un nodo de la lista puede apuntar al siguiente nodo, al anterior, o a ambos
35
Por lo regular se usa un apuntador con valor nulo para indicar una lista vacía o el final
de la lista.
Las operaciones típicas en una lista ligada incluyen agrega nodo, siguiente nodo y
anterior nodo.
Resultados esperados del Programa 1A Prueba completamente el programa. Debería usar al menos tres pruebas de los datos en
las tres columnas de abajo (tabla D4, página 753).
LOC Objeto LOC Nuevas y Modificadas Horas de Desarrollo
160
591
114
229
230
270
128
1657
624
1503
186
699
132
272
291
331
199
1890
788
1601
15.0
69.9
6.5
22.4
28.4
65.9
19.4
198.7
38.8
138.2
Media 550.6 638.9 60.32
DesEst
572.03
625.63
62.26
Prueba 1:
Prueba 2:
36
Prueba 3:
9.1.2 TAREA 2A
Requerimientos
Use el PSP0.1 para escribir un programa para que cuente el total de LOC lógicas en un
programa, omitiendo comentarios y líneas en blanco.
Use su estándar de conteo (R1, ver sección 5) y estándar de codificación (R2, ver
sección 6) para colocar una línea lógica en cada línea física y cuente las líneas físicas.
Produzca un conteo simple para el programa completo en archivos fuente.
Pruebe el programa. Como una prueba, cuente las LOC en los programas 1A y 2A.
Resultados del Programa 2A
Pruebas para la tarea1A
El total de LOC’s para la tarea 1 son 111.
37
Pruebas para la tarea2
El total de LOC’s para la tarea 2 son 203.
9.1.3 TAREA 3A
Requerimientos del Programa 3A
Use el PSP0.1 para escribir un programa que cuente
•las LOC lógicas totales en un programa
•las LOC lógicas en cada objeto o función
•número de métodos en cada objeto
Produzca e imprima
•un solo conteo de LOC para el archivo del programa fuente
•conteo separados de LOC y métodos para cada objeto
Ejemplo de salida
Usted puede mejorar el programa 2A para realizar el programa 3A (pero mantenga un
copia del 2A).
Usted puede actualizar su estándar de conteo de LOC (R1) y su estándar de codificación
(R2) para simplificar el diseño del programa 3A.
Pruebe completamente este programa. Como un mínimo, pruebe el programa contando
el programa total y las LOC por cada objeto en los programas 1A, 2A y 3A. Incluya en
sus reportes de prueba un tabla que proporcione los conteos obtenidos.
Número de
Programa
Nombre de
Objecto
Númber de
Méthodos
LOC de Objecto LOC Totales del
Programa
1a ABC 3 86
DEF 1 8
GHI 1 92
212
38
Resultados del Programa 3A
Pruebas para la tarea1A
El total de LOC’s para la tarea 1 son 119.
Pruebas para la tarea2
El total de LOC’s para la tarea 2 son 211.
39
Pruebas para la tarea3A
El total de LOC’s para la tarea 3A son 233.
9.1.4 TAREA 4A
Requerimientos del Programa 4A
Calcule los parámetros de regresión lineal β0 y β 1 para n conjuntos de datos.
Mejore la lista ligada desarrollada en el programa 1A para que almacene los conjuntos
de n datos, donde cada conjunto de datos contiene exactamente dos número reales.
Pruebe el programa con tres conjuntos de datos.
•LOC de objeto estimadas y LOC N&C reales
•LOC N&C estimadas y LOC N&C reales
•LOC N&C estimadas y LOC N&C reales de sus programas 2A, 3A y 4A
Program
Number
Estimated
Object LOC
Estimated New
and Changed
LOC
Actual New
and Changed
LOC
1 130 163 186
2 650 765 699
3 99 141 132
4 150 166 272
5 128 137 291
6 302 355 331
7 95 136 199
8 945 1206 1890
9 368 433 788
10 961 1130 1601
40
Prepare un reporte de sus pruebas que incluya una tabla de los resultados planeados y
reales de estas pruebas en el formato de la siguiente tabla.
Parámetro de Regresión - β0
La fórmula del parámetro de regresión β0 es: β0 = yavg - β1xavg
Parámetros de Regresión - β1
La fórmula del parámetro de regresión β1 es:
(A13)
)(1
22
11 n
i
avgi
n
i
avgavgii
xn
ynxyx
x
LOC de objeto estimadas y LOC N&C reales (tabla D8, página 756)
Test Expected Results Actual Results
0 1 0 1
1 -22.55 1.7279
2 -23.92 1.4310
3
41
LOC N&C estimadas y LOC N&C reales (tabla D8, página
756)
LOC N&C estimadas y LOC N&C reales de sus programas 2A, 3A y 4ª
9.1.5 TAREA 5A
Requerimientos del Programa 5A
Utilice PSP1.1 para escribir un programa que integre numéricamente una función
utilizando la regla de Simpson y escriba la función que sea la distribución normal.
El programa debe diseñarse para integrar utilizando varias funciones que sean
proporcionadas. Usted necesitará este programa para calcular los valores de las distintas
distribuciones estadísticas que se usan posteriormente en las tareas.
Pruebe completamente el programa. Como mínimo, use este programa para calcular los
valores de la integral de distribución normal para tres valores.
Prueba Valor Esperado
42
• - ∞ a 2.5 0.9938
• - ∞ a 0.2 0.5793
• ∞ a -1.1 0.1357
Integración Numérica
En principio la integración numérica trata como si estuviese compuesta por varias áreas
rectangulares.
Entonces suma estas áreas para generar el valor de la integral
El truco es sumar estas áreas de tal forma que se minimice el error.
Para determinar los límites de integración
• La mayoría de las funciones estadísticas se integran de - ∞ a algún valor
• Todas las funciones estadísticas tienen un área total de 1.0 cuando se integran de -
∞ a + ∞
12
La regla de Simpson para calcular la integral es
donde
• W es el ancho de los segmentos
• F es el valor de la función para cada valor de x
La regla de Simpson en otra forma
donde N es el número de segmentos
Con funciones simétricas (las distribuciones normal t), el procedimiento es este.
43
La fórmula de la distribución normal es
Inicie con N = 20 y un error aceptable (E) de 1E-07.
Resultados del Programa 5A
De - ∞ to 2.5
De - ∞ to 0.2
44
De - ∞ to -
1.1
9.1.6 TAREA 6A
Requerimientos del programa 6A
En esta tarea se escribirá un programa para calcular los intervalos de predicción del 70%
y del 90% de las LOC’s nuevas y modificadas estimadas, dado un conjunto de datos
históricos de tamaño y un estimado de LOC de objeto.
• Usamos la regla de integración de Simpson del programa 5 para calcular el valor de
la distribución t.
• Use una lista ligada para almacenar los datos históricos.
Intervalo de predicción
El intervalo de predicción proporciona un rango de probabilidad alrededor del estimado.
• Un intervalo de predicción de 70% da el rango dentro del cual caerán el 70% de los
estimados.
• No es un pronóstico, solo una expectativa.
• Solo aplica si el estimado se comporta como los datos históricos.
Se calcula a partir de los mismos datos utilizados para calcular los parámetros de
regresión.
Para calcular el intervalo de predicción, realizamos los siguientes pasos:
1. Lee los datos históricos x’s y y’s.
2. Calcule B0 y B1.
3. Lea su estimado Xk.
4. Calcule una proyección como Yk = B0 + B1*Xk.
5. Calcule el rango para un intervalo de 70%.
6. Calcule el UPI = Yk + Rango(70%).
7. Calcule el LPI = Yk - Rango(70%).
8. Repita los pasos 5 – 7 para el rango de 90%.
9. imprima sus resultados.
La fórmula para el cálculo del rango de predicción es:
45
Donde
• X es el tamaño de los datos históricos
• N es el número de puntos de los datos históricos
• t(α/2, dof) doble lados de la distribución t para n - 2 grados de libertad.
La formula para calcular la desviación estándar es:
Donde
• X son los datos históricos de tamaño estimado de objetos.
• Y son los datos históricos de tamaño nuevo y modificados reales.
• B y b son los parámetros de regresión lineal de los datos X’s vs. Y’s
• gl es el número de los grados de libertad de los datos, el cual es n – 2.
Encontrando t70(α/2,n -2)
Donde
• n es el número de miembros de x.
• Г(x) = (x-1) Г (x-1), Г (1) = 1, y Г (1/2) = π1/2.
La distribución t
La distribución t
• Es parecida a la distribución normal.
• Tiene colas muy gruesas.
• Es usado en estimados de parámetros estadísticos para datos limitados.
46
Calculando el valor de t
Para calcular el valor de t(α/2, n - 2).
• Inicie con un valor de prueba de 1 para el limite superior y calcule el valor de la
integral.
• Compare el resultado con el valor deseado1. Si el resultado de la integración es
demasiado grande, tome un límite superior de prueba más grande. Si el resultado de la
integración es demasiado grande, tome un límite superior más
pequeño. Haga la integración de pruebas sucesivas hasta que el valor de integración esté
dentro de un error aceptable, digamos 0.00001.
• Para 70%, integre para tener 0.35 (0.85 – 0.5).
• Para 90%, integre para tener 0.45 (0.95 – 0.5).
Una forma para hacer el cálculo es la siguiente:
1. Inicie con un valor de prueba t digamos 1.
2. Haga una integral inicial y pruebe revisar si proporciona el valor apropiado; si
no, continué.
3. Si es muy bajo, sume d = 0.5 al valor de prueba t
4. Si es muy alto, reste d = 0.5 al valor de prueba t.
5. Integre de nuevo y pruebe si el resultado está dentro del error aceptable, si no,
continué.
6. Si es muy bajo, ajuste d; sume d al valor de prueba t.
7. Si es muy alto, ajuste d; reste d al valor de prueba t.
8. Repita pasos 5 -7.
Las reglas para ajustar d son las siguientes:
1. En tanto como las pruebas de error del resultado, proporcione el mismo signo
del error, deje d sin cambio.
2. Siempre que cambie el signo del error, divida d entre 2.
47
Resultados del Programa 6A
Las LOC de objetos estimadas y las LOC nuevas y modificadas reales en la tabla D8
(pagina 756) con un estimado de LOC de objeto 386.
Mis LOC nuevas y modificadas estimadas y sus LOC nuevas y modificadas reales de
los programas 2A al 5A.
9.1.7 TAREA 7A
Requerimientos del Programa 7A
Usando el PSP2, escriba un programa que calcule la correlación entre dos series de
números y calcule la significancia de esa correlación.
Utilice la rutina de integración de Simpson del programa 5A para calcular los valores de
la distribución t.Almacene los datos en una lista ligada.
48
Pruebe el programa utilizando las LOC nuevas y modificadas reales de la siguiente
tabla, como los datos x y las horas de desarrollo de la siguiente. tabla como los datos y.
Determine la correlación y significancia entre las LOC nuevas y modificadas y el
tiempo de desarrollo real de sus tareas a la fecha.
Determine la correlación y significancia entre las LOC nuevas y modificadas estimadas
y el tiempo de desarrollo real de las tareas 2A a la 6A.
Uso de la Correlación
La correlación rxy puede ir de +1 a -1.
Cerca de +1 implica una fuerte relación positiva; cuando x se incrementa y se
incrementa.
Cerca de -1 implica una fuerte relación negativa; cuando x se incrementa y se
decrementa.
Cerca de 0 implica que no tienen relación.
La correlación es utilizada en el PSP para juzgar la calidad de la relación lineal en
varios datos históricos del proceso que son utilizados para la planeación.
Número de
elemento
LOC Nuevas y
Modificadas reales
Horas de
Desarollo
n x y
1 186 15.0
2 699 69.9
3 132 6.5
4 272 22.4
5 291 28.4
6 331 65.9
7 199 19.4
8 1890 198.7
9 788 38.8
10 1601 138.2
Totales 6389 603.2
Prueba Valor Esperado Valor Real
r t 2*(1-p) r t 2*(1-p)
Tabla
D12
0.9543 9.0335 1.80*10-5
LOC
Reales vs.
Tiempo
de Des.
N/A NA NA
LOC
Estimad.
vs.
Tiempo
de Des.
NA NA NA
49
Para este propósito, usamos el valor de la relación rxy al cuadrado, o r 2.
Limitaciones de la Correlación
La correlación no implica causa y efecto.
Una fuerte correlación puede ser coincidental.
Muchas correlaciones coincidentales pueden ser encontradas en los datos históricos del
proceso.
Para usar una correlación, debe comprenderse las relaciones causa-y-efecto del proceso.
Cálculo de la Correlación
La fórmula para calcular el coeficiente de correlación r es
donde
x y y son dos
conjuntos de datos
por parejas
n es el número de
sus miembros
La Prueba de la Significancia
La prueba de significancia determina la probabilidad que una correlación fuerte sea por
casualidad y por lo tanto no tenga significancia práctica.
Recuérdese que una correlación fuerte puede ser sólo por coincidencia, especialmente
cuando los datos son escasos.
Por ejemplo, un conjunto de datos con sólo dos puntos siempre tendrá r 2 = 1, pero esta
correlación no es significativa.
Si r 2 es
la relación es
.9 r 2 predictiva; úsela con gran confianza
.7 r 2
< .9
fuerte y puede ser usada para planeación
.5 r 2
< .7
adecuada para planeación, pero con cuidado
r 2 < .5 no es confiable para propósitos de planeación
2
11
2
2
11
2
111,
n
i
i
n
i
i
n
i
i
n
i
i
n
i
i
n
i
i
n
i
ii
yynxxn
yxyxn
yxr
50
La prueba de significancia usa la distribución t.
Cálculo de la Significancia
El cálculo de la significancia consiste de tres pasos.
1. Calcule el valor de t.
donde
r(x,y) es la correlación
n es el número de puntos
Cálculo de la Significancia -2
2. Encuentre la probabilidad p integrando numéricamente la distribución t para n – 2
grados de libertad, de -∞ a t.
3. Calcule la cola de la distribución, 2*(1-p).
Interpretnado la Significancia
Un área en la cola < 0.05 se considera una evidencia fuerte que existe relación.
Un área en la cola > 0.2 se considera que la relación es debida a la coincidencia.
Resultados del Programa 7A
Test Expected Value Actual Value
r t 2*(1-p) r t 2*(1-p)
Table D12 0.9543 9.0335 1.80*10-5
0.95431 9.03350 1.54*10-5
Actual
LOC vs.
Dev. Time
N/A NA NA 0.37110 0.89361 0.37153
Estimated
LOC vs.
Dev. Time
NA NA NA 0.98255 9.14998 1.56*10-5
Distribución t de Student
2),(1
2),(
yxr
nyxrt
51
Las LOC nuevas y modificadas reales la tabla D12, como los datos x y las horas
de desarrollo como los datos y.
Número de
elemento
LOC Nuevas y
Modificadas reales
Horas de
Desarollo
n x y
1 186 15.0
2 699 69.9
3 132 6.5
4 272 22.4
5 291 28.4
6 331 65.9
7 199 19.4
8 1890 198.7
9 788 38.8
10 1601 138.2
Totales 6389 603.2
Tabla D12
Mis LOC nuevas y modificadas reales y el tiempo de desarrollo real de mis tareas a la
fecha (6).
Número de
elemento
LOC Nuevas y
Modificadas reales
Horas de
Desarollo
N x y
1 119 2.3
2 211 4.0
3 72 1.3
4 100 2.7
5 116 3.8
6 235 4.6
Totales 853 18.7
52
Mis LOC nuevas y modificadas estimadas y el tiempo de desarrollo real de las tareas
2A a la 6A.
Número de
elemento
LOC Nuevas y
Modificadas estimadas
Horas de
Desarollo
n X y
2 220 241.1166667
3 56 77
4 60 159.85
5 130 230.2
6 200 278.3333333
Totales 666 986.5
53
9.1.8 TAREA 8A
Requerimientos del Programa 8A
Usando del PSP2.1, escriba el programa 8A para que ordene una lista ligada de n pares
de números reales en orden descendente.
Proporcione la capacidad de ordenar cualquier campo de la pareja de datos.
Pruebe el programa usando los datos en las dos columnas de la siguiente tabla:
n x y
1 186 15
2 699 69.9
3 132 6.5
4 272 22.4
5 291 28.4
6 331 65.9
7 199 19.4
8 1890 198.7
9 788 38.8
10 1601 138.2
Realice dos ordenamientos, uno para cada campo.
Entregue un reporte de pruebas que describa ambos resultados.
Ordenamiento por Inserción -1
El algoritmo de ordenamiento por inserción ordena al encontrar la posición ordenada
correspondiente a un elemento de dato, entonces inserta el elemento de dato en la lista
de datos en esa posición.
Resultados del programa 8A
Las LOC nuevas y modificadas reales la tabla D12, como el conjunto X y las horas de
desarrollo como el conjunto Y.
Número de
elemento
LOC Nuevas y
Modificadas reales
Horas de
Desarollo
n x y
1 186 15.0
2 699 69.9
3 132 6.5
54
4 272 22.4
5 291 28.4
6 331 65.9
7 199 19.4
8 1890 198.7
9 788 38.8
10 1601 138.2
Totales 6389 603.2
Tabla D12
9.1.9 TAREA 9A
Requerimientos del programa 9A
Usando PSP2.1, escriba el programa 9A para calcular el grado al cual una cadena de n
números reales es normalmente distribuida.
• Use la rutina de integración de Simpson’s del programa 5A para calcular los valores
de la distribución X2.
• Asuma n > 20 y siempre un múltiplo de 5. (nota, se puede asumir n = 50).
• Use el programa 8 para ordenar los números de forma ascendente.
Prueba X2 para normalidad
La prueba X2 para normalidad determina que tan probable es que un conjunto de datos
tenga
una distribución normal. Se hace para comparar la estructura de un conjunto de datos
con el
55
de una distribución normal ideal.
Realizamos este dividiendo la distribución normal en segmentos de igual área y
comparando el actual número de puntos del conjunto de datos a probar con el esperado
número de una distribución normal ideal.
Los pasos de la prueba X2 son los siguientes:
1. Ordena el conjunto de datos de n números reales de forma ascendente.
2. Normalice el conjunto de datos.
Primero, calcule la desviación estándar σ, para los datos usando n -1.
Después, transforme cada xi en zI, donde
3. Divida la distribución normal entre el mismo número de segmentos S, donde
• n/S ≥ 5
• S > 3
• S2 ≥ n
4. Determine cuantos puntos de la distribución normal ideal, pueden estar dentro de
cada segmento, Ni, Normalmente es n/s, para este caso es 5.
5. Determine cuantos de los datos normalizados caen dentro de cada segmento Ki.
6. Calcule el valor de Q para los segmentos
7. Calcule la probabilidad p para las distribución X2 para S – 1 grados de libertad, para
integrar
desde 0 a Q.
8. Calcule la cola de distribución para 1 – p.
9. Examine 1 – p para interpretar el resultado.
• 1 – p < 0.05 es generalmente considerado suficiente para
• 1 – p > 0.2 es generalmente considerado suficiente par aceptar
• Valores intermedios indican grados intermedios de
56
Resultados del programa 9A
Este es el resultado al utilizar las LOC/Método de la tabla D14, página 761, del texto.
Si el nombre del archivo es incorrecto:
9.1.10 TAREA 10A
Requerimientos de programa 10A
Usando PSP2.1, realice el programa 10A para calcular, los parámetros de regresión
múltiple
(B0, B1, B2, B3).
• Hacemos un estimado de las entradas previstas por el usuario. Y determine los
57
intervalos de predicción del 70% y 90% a ser estimados.
• Use además una lista ligada para almacenar los datos y el método de integración de
Simpson del programa 5A para calcular la distribución t.
Calculando los parámetros de regresión múltiple
La regresión múltiple proporciona un camino para estimar los efectos de múltiples
variables
cuando no es posible separar los datos.
A continuación se muestra en una serie de 13 pasos como podemos calcular la regresión
múltiple:
1. Use la siguiente formula de regresión múltiple, para calcular el valor del proyecto:
2. Encontrar los parámetros BETA resolviendo el siguiente sistema de ecuaciones
lineales:
3. Cuando calcules el valor de los términos, obtendrás el siguiente sistema de
ecuaciones lineales:
4. Diagonalizando por el método de Gauss, se elimina sucesivamente un parámetro a
la vez, dando como resultado:
5. La solución para los términos BETA es:
58
6. Determine el intervalo de predicción por solución del rango con la siguiente
ecuación:
7. Calculamos la varianza como sigue:
8. La desviación estándar es la siguiente:
9. Los términos dentro de la raíz cuadrada que determinan el rango son:
10. El valor de la distribución t, para el intervalo de predicción del 70% con n = 6 y p =
4 es encontrado bajo la columna del 85% y dos grados de libertad. Y el valor es:
1.386.
11. Evaluamos la raíz cuadrada:
12. El estimado final es:
z = 6.71+0.0784*650+0.0150*3,000+0.2461*155
= 140.902 horas
13. El intervalo de predicción es de: 140.902 +/- 38.84 horas. O lo que es lo mismo:
102.06 horas como mínimo y 179.74 horas como máximo.
59
Resultados del programa 10A
Este es el resultado los datos de la tabla D16, página 763, como los datos históricos.
Para las entradas del usuario:
• 185 LOC de código nuevo
• 150 LOC de código reutilizado
• 45 LOC de código modificado.
Este es el resultado de de los datos de la tabla 32, página 556, como los datos históricos.
Para las entradas del usuario:
• 650 LOC de código nuevo
• 3000 LOC de código reutilizado
• 155 LOC de código modificado
60
Si el nombre del archivo es incorrecto:
