plantillas desarrollo de software

UNIVERSIDAD AUTONOMA METROPOLITANAIZTAPALAPA

DIVISION DE CIENCIAS BASICAS E INGENIERIA

LICENCIATURA EN COMPUTACION

REPORTE DE PROYECTO FINAL

Desarrollo del Proceso Persona de Software

Daniel Chinas Vega

Asesor

Eduardo Rodrıguez Flores

1

Indice general

1. Introduccion 3

2. Desarrollo 42.1. PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 42.2. PSP 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 6

2.2.1. Tarea 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 62.3. PSP 0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 6

2.3.1. Tarea 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 72.3.2. Tarea 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 7

2.4. Reporte de analisis de defectos R3 . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 72.5. PSP 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 7

2.5.1. Tarea 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 72.6. PSP 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 8

2.6.1. Tarea 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 82.6.2. Tarea 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 8

2.7. Reporte de mitad de proceso R4 . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 112.8. PSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 12

2.8.1. Tarea 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 122.9. PSP 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 14

2.9.1. Tarea 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 142.9.2. Tarea 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 142.9.3. Tarea 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 15

2.10. R5: Reporte de Analisis del Proceso . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 19

3. Resultados 213.1. Formas, Plantillas y estandares para su utilizacionen PSP . . . . . . . . . . . . . . . . . . . . . . . . 213.2. Bitacora de Tiempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 223.3. Registro de defectos. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 223.4. Estandar de Conteo de LOCs de Java (R1) . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 243.5. Java Standard de codificacion (R2) . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 253.6. Estimacion de tamano . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 273.7. Design Review Checklist. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 283.8. Code Review Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 293.9. Escenario operacional. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 303.10. Especificacion funcional . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 313.11. Especificacion de estados . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 323.12. Especificacion logica . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 333.13. Propuesta de mejora de proceso (PIP) . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 343.14. Reporte de la mitad del Proceso (R4) . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 393.15. R4 Report Plan Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 403.16. R4 Time Recording Log . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 413.17. Reporte R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 42

2

3.17.1. Analisis de la Exactitud de Estimacion de Loc . . . .. . . . . . . . . . . . . . . . . . . . . . 423.17.2. Analisis de la Exactitud de Estimacion de Tiempo .. . . . . . . . . . . . . . . . . . . . . . . 443.17.3. Analisis de los defectos introd. Y eliminados por fase (R3). . . . . . . . . . . . . . . . . . . . 493.17.4. Analisis de defectos encontrados por el compilador (tabla D24) . . . . . . . . . . . . . . . . 503.17.5. Areas de prioridad para mejora en la 2da. Mitad del curso . . . .. . . . . . . . . . . . . . . 50

3.18. Reporte R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 523.18.1. Reporte de final de proceso (R5) . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 523.18.2. R5 Report Plan Summary . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 533.18.3. R5 Time Recording Log . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . 533.18.4. Analisis de la precision de la estimacion de tamano . . . . . . . . . . . . . . . . . . . . . . . 543.18.5. Analisis de estimacion de tiempo . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . 543.18.6. Productividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 553.18.7. Analisis de tipos de defectos . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 563.18.8. Defectos removidos por fase . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 573.18.9. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 58

4. Conclusiones al termino del proceso ( PSP ) 604.0.10. Areas para mejorar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 604.0.11. Medidas para mejorar . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 604.0.12. Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 614.0.13. Revision de metas . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 614.0.14. Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 614.0.15. Errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . 624.0.16. Productividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 634.0.17. Metas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 63

3

Capıtulo 1

Introducci on

Software.

Es el conjunto de los programas de computo, procedimientos, reglas, documentacion y datos asociados queforman parte de las operaciones de un sistema de computacion.[IEEE]Tomando como punto de partida esta definicion, el software es la suma de diferentes componentes y por tanto parahablar de calidad de software se deben tomar en cuenta cada uno de ellos, cabe recordar que para controlar la calidades necesario, definir parametros, indicadores o criteriosde medicion tomandose el resultado de evaluacion mas bajoobtenido en cualquiera de los componentes del software paraindicar la calidad de este, de ahi la importancia en sudesarrollo. Por ello debemos contar con metodos y procesosque nos permitan mantener una adecuada calidad en latotalidad del software.

Ingenierıa al software.

La aplicacion de un enfoque sistematico, disciplinado y cuantificable al desarrollo operacion (funcionamien-to) y mantenimiento del software. [IEEE, 1993]Bajo este contexto la ingenierıa de software es una disciplina cuyo fin es la creacion de software de la mas alta calidad.Haciendo uso de procesos cuantificables y repetibles.

Proceso de ingenierıa de software

Un conjunto de etapas parcialmente ordenadas con la intencion de logra un objetivo, en este caso, la obten-cion de un producto de software de calidad [Jacobson 1998].En vista de los conceptos antes mencionados es importante elcontar con un proceso adecuado que nos lleve a la real-izacion de un software de alta calidad.

PSP

Proceso Personal de Software (PSP, por sus siglas en inglesPERSONAL SOFTWARE PROCESS). PSP esun proceso de auto mejoramiento de la calidad de software, nos proporciona una estructura con guıas y procedimientospara el desarrollo de un proceso, que tenga como finalidad la creacion de software de calidad.

Como ya habıamos mencionado la calidad del software es el resultado de evaluacion de calidad mas bajo decualquiera de los componentes de este y la calidad de cada unode ellos esta dada por la persona que lo desarrollo deahı la importancia de contar con un proceso personal que nospermita tener altas cotas de calidad.

4

Capıtulo 2

Desarrollo

2.1. PSP

El PSP es un proceso personal para desarrollar software con:

Pasos definidos

Formas

Estandares

El PSP es una lınea de trabajo de medicion y analisis para ayudar a caracterizar un proceso. Tambien es unprocedimiento definido que le ayuda a mejorar el desempeno.

R© 2002 por Carnegie Mellon University.

Es un proceso enfocado en el mejoramiento personal de las pr´acticas usadas en el desarrollo de software.Hace uso de mediciones y analisis de las mismas para ayudarnos a caracterizar nuestro proceso de desarrollo.

El PSP proporciona:

Una base probada para desarrollar y practicar disciplinas personales de uso avanzado.

Una disciplina que muestra como mejorar el proceso personal.

Los datos para mejorar continuamente la productividad, calidad y la prediccion del trabajo

Un PSP estable y maduro permite:

Estimar y planear el trabajo.

Cumplir con los compromisos.

Resistir presiones por compromisos no razonables.

5

Tambien:

Se comprenderan las habilidades actuales para desarrollar software.

Se estara mejor equipado para mejorar la habilidad para desarrollar software

R© 2002 por Carnegie Mellon University.

El Proceso del PSP se puede describir mediante el siguiente diagrama.

Figura 2.1:

El aprendizaje del psp se puede dividir en tres bloques:

PSP0: Establecer una base para la futura medicion de nuestro desempeno.PSP1: Planificacion del tamano, uso de recursos y tiempo de desarrollo.PSP2: Administracion de defectos y rendimiento (yield)

Proceso de aprendizaje PSP

Figura 2.2:

Esta dividido en 10 Tareas que nos introducen de una manera estructurada y progresiva en el desarrollo denuestro Proceso personal de software.

6

2.2. PSP 0

Objetivos

Demostrar el uso de un proceso definido al escribir un programa pequeno.

Incorporar medidas basicas en el proceso de desarrollo de software.

PSP 0 es simple y definido, usando los metodos con los que actualmente disenamos y desarrollamos nuestrosoftware.

Se recolectan datos sobre el trabajo realizado, tiempo utilizado por fase y defectos encontrados en la compi-lacion y pruebas.

Se hace uso de una bitacora para el registro de los tiempos y de una bitacora para el reporte de los defectos,se usa un estandar de defectos para llevar un control de los mismos.

2.2.1. Tarea 1

Creacion de un programa que calcule la media y la desviacion estandar de una serie de n numeros reales,usando una lista ligada para almacenar los n numeros a usar en los calculos.

2.3. PSP 0.1

Objetivos

Medir el tamano de los programas que produzca.

Contabilizar los tipos de LOCs en los programas que produzca.

Realizar mediciones de tamano exactas y precisas.

Hay dos nuevos elementos del proceso.

La forma de propuesta de mejora de proceso (PIP).

Estandares de conteo ( R1 )y codificacion ( R2 ).

Para mejorar el proceso, es necesario registrar los problemas y propuestas de mejora para una referencia futura.

El PIP contiene informacion de mejora del proceso

Numero de PIP.

Descripcion del problema.

Solucion propuesta.

Notas y comentarios.

Los estandares de codificacion y conteo son necesarios para escribir los programas PSP, deben ser ajustadosal lenguaje que usemos para codificar. De forma que el conteo de LOC sea mas facil. LOC son elementos de lenguajemınimos para llevar a cabo una operacion completa (logico) o elementos fısicos como podrıan ser palabras, para eldiseno de mi estandar de conteo elegı el tipo logico.

7

2.3.1. Tarea 2

Creacion de un programa que cuente el total de LOC logicas en un programa omitiendo comentarios y lıneasen blanco. Haciendo uso de nuestro estandar de conteo. Lo Probaremos contando las LOC de los programas 1A y 2A.

2.3.2. Tarea 3

Creacion de un programa que cuente las LOC logicas totalesde un programa, las LOC logicas en cada objetoo funcion y el numero total de metodos de cada objeto, tendra como salida el conteo de LOC totales, el conteo separadode LOC y el de metodos.

2.4. Reporte de analisis de defectos R3

Objetivos

La densidad y tipos de defectos introducidos y encontrados mientras se desarrollan programas.

Importancia de recolectar, registrar y reportar cuidadosamente los datos del proceso.

Incluye las siguientes tablas

Densidad de defectos.

Densidad de defectos en las fases de compilacion y pruebas.

Tiempo promedio de correccion de defectos por fase de introduccion y eliminacion.

Forma parte de los reportes R4 y R5 que se trataran mas adelante.

2.5. PSP 1

Objetivo

El objetivo de PSP1 es establecer un procedimiento ordenadoy repetible para el desarrollo de estimados para el tamanodel software.

2.5.1. Tarea 4

Creacion de un programa para calcular los parametros de regresion lineal b0 y b1 para n conjunto de datos,se usara la lista ligada de la tarea 1 para el almacenamiento de los datos.

La formula del parametro de regresion b0 es

b0 = yavg - b1xavg

8

La formula del parametro de regresion b1 es

Figura 2.3:

2.6. PSP 1.1

Objetivos

Los objetivos del PSP 1.1 son introducir y practicar metodos para:

Hacer planes de recursos y de calendario de trabajo.

Seguir el desempeno contra estos planes.

Juzgar la probabilidad de las fechas de terminacion del proyecto.

2.6.1. Tarea 5

Creacion de un programa para resolver una integral de una funcion numericamente, usando la regla de simp-son para una funcion de distribucion normal, debera ser disenado para integrar usando varias funciones proporcionadas.

La regla de Simpson.

Figura 2.4:

2.6.2. Tarea 6

Creacion de un programa para calcular el estimado de LOCs nuevas y modificadas ası como los intervalos deprediccion de 70 % y 90 %, dado un conjunto de datos historicos y un estimado de LOCs.

Se hara uso de la rutina de integracion de la regla de simpsondisenada en la tarea 5 para calcular el valor dela distribucion t. Se usara una lista ligada para almacenarlos datos historicos.

9

Para calcular el intervalo de prediccion, utilizar los siguientes pasos.

1. Leer los datos historicos, x’s y y’s.

2. Calcular B0 y B1.

3. Leer el estimado, xk.

4. Calcular a proyeccion como yk= B0 + B1 * xk.

5. Calcular el Rango para un intervalo de 70 %.

6. Calcular el UPI = yk + Rango (70 %).

7. Calcular el LPI = yk - Rango (70 %).

8. Repetir los pasos 5-7 para el Rango de un intervalo de 90 %.

9. Imprimir los resultados.

La formula para calcular el rango de prediccion es

Figura 2.5:

Donde:

x son los datos historicos de tamano de objeto.

n es el numero de puntos de los datos historicos.

t70(2/α, dof) es la distribucion t de dos colas de 70 % para n - 2 grados de libertad (dof).

Sigma es la desviacion estandar de la regresion lineal delos datos.

Figura 2.6:

10

Donde

x son los datos historicos de tamano de objetos.

y son los LOC nuevas y modificadas historicas (para tamano)o tiempo (para esfuerzo).

n es el numero de puntos de datos historicos.

Para calcular el valor det(, 2/αdof)

Iniciar con un valor de prueba para el lımite superior y calcular el valor de la integral.

Comparar el resultado con el valor deseable.

• Si el resultado de la integracion es demasiado bajo, escoger un lımite superior de prueba mas grande.

• Si el resultado de la integracion es demasiado alto, escoger un lımite superior mas pequeno.

Hacer integraciones de prueba sucesivas hasta que el valor de la integracion este dentro de un error aceptable,digamos 0.00001.

Para 70 %, integrar para obtener 0.35 (0.85 - 0.5).

Para 90 %, integrar para obtener 0.45 (0.95 - 0.5).

Una forma para hacer este calculo es usar los siguientes ocho puntos.

1. Iniciar con un valor de prueba de t, digamos 1.0.

2. Hacer una integral inicial y pruebar para ver si da el valorapropiado de p, si no, continuar.

3. Si es demasiado bajo, sumar d = 0.5 al valor de prueba t.

4. Si es demasiado alto, restar d = 0.5 del valor de prueba t.

5. Integrar de nuevo y probar si el resultado esta dentro delerror aceptable; si no continuar.

6. Si es demasiado bajo, ajustar d; sumar d al valor de prueba t.

7. Si es demasiado alto, ajustar d; restar d del valor de prueba t.

8. Reciclar en 5.

Las reglas para ajustar d son:

En tanto que las pruebas del error de los resultados den el mismo signo del error, no modificar a d.

Siempre que el signo del error cambie, dividir d entre 2.

Note que este metodo para ajustar d podrıa resultar en un valor de prueba de t = 0. Para protegerse contraeste problema con el metodo de Simpson, se debe asegurar queel programa manejara un valor 0 de la funcion queesta siendo integrada.

11

2.7. Reporte de mitad de proceso R4

Objetivos

Los objetivos d este reporte son:

Comprender los principios de la medicion y analisis de procesos.

Ganar experiencia en la definicion de un proceso para su uso propio.

Aprender a analizar los datos del proceso.

Comprender el proceso de referencia y como ha cambiado durante el curso.

Establecer metas medibles y definir las acciones de mejora correspondientes.

Para este reporte se debe disenar:

Un proceso para analizar los datos del PSP y para producir un reporte.

Se debe incluir en este proceso las fases de planeacion y de postmortem.

Utilizar el proceso para:

• Planear las tareas del reporte R4.

• Analizar los datos de proceso.

• Producir el reporte.

• Concluir el postmortem.

El reporte debe contener:

Un analisis para la exactitud de la estimacion de tamano ycomo ha evolucionado durante los programas desar-rollados a la fecha.

Un analisis para la exactitud de la estimacion de tiempo y como ha evolucionado durante los programas desar-rollados a la fecha.

Un analisis de los tipos de defectos introducidos y eliminados para los programas desarrollados a la fecha (tablaD23, pagina 773).

Un analisis de los defectos encontrados por el compilador (tabla D24, pagina 773).

Un analisis de los tiempo de correccion de defectos, R3.

Una descripcion de las areas de mas alta prioridad para lamejora personal, con su justificacion.

lo que se espera:

Identificar las oportunidades de mayor influencia para mejorar el desempeno personal.

Establecer metas cuantitativas y medibles.

Describir las acciones especıficas (e.g. cambios al proceso) que se tomaran para lograr estas metas.

12

Como mınimo, se deberan tomar los siguientes pasos para establecer los objetivos.

Examinar los datos PSP para comprender el desempeno actual.

Identificar las mejoras potenciales.

Priorizar las areas de mejora basandose en el peso potencial.

Conducir un analisis para identificar las causas del desempeno actual y establecer niveles de desempeno futuro.

Identificar las acciones especıficas necesarias para lograr estos niveles de desempeno.

2.8. PSP 2.0

Listas de revision de codigo y diseno.

Metodos para evaluar y probar lo acertado de nuestras revisiones. Se agregan al proceso:

Lista de chequeo de diseno.

Lista de chequeo de codificacion.

2.8.1. Tarea 7

Creacion de un programa para calcular la correlacion entre dos series de numero y calcular la significanciade esa correlacion. Se hara uso de la rutina de integracionde la tarea 5 para calcular los valores de la distribucion t,sealmacenaran los datos en una lista ligada.

La correlacion rxy puede ir de +1 to -1.

Cerca de +1 implica una fuerte relacion positiva; cuando x se incrementa y se incrementa.

Cerca de -1 implica una fuerte relacion negativa; cuando x se incrementa y se decrementa.

Cerca de 0 implica que no tienen relacion.

La correlacion es utilizada en el PSP para juzgar la calidadde la relacion lineal en varios datos historicos delproceso que son utilizados para la planeacion. Para este proposito, usamos el valor de la relacion rxy al cuadrado, o r2.

Si r2 es La relacion es0,9 ≤ r2 Predictiva; usela con gran confianza.0,7 ≤ r2 ¡ Fuerte y puede ser usada para planeacion.0,5 ≤ r2 ¡ Adecuada para planeacion, pero con cuidador2 < 0,5 No es confiable para propositos de planeacion

13

Limitaciones de la Correlacion

La correlacion no implica causa y efecto.

Una fuerte correlacion puede ser coincidental.

La formula para calcular el coeficiente de correlacion r es:

Figura 2.7:

Donde

x y y son dos conjuntos de datos por parejas.

n es el numero de sus miembros.

La prueba de significancia determina la probabilidad que unacorrelacion fuerte sea por casualidad y por lotanto no tenga significancia practica.Hay que recordar que una correlacion fuerte puede ser solopor coincidencia, especialmente cuando los datos sonescasos. Por ejemplo, un conjunto de datos con solo dos puntos siempre tendra r 2 = 1, pero esta correlacion no essignificativa.

El calculo de la significancia consiste de tres pasos:

1. Calcular el valor de t.

Figura 2.8:

Donde:

r(x,y) es la correlacion.

n es el numero de puntos.

2. Encontrar la probabilidad p integrando numericamente la distribucion t para n -2 grados de libertad, de -Y a t.

3. Calcular la cola de la distribucion, 2*(1-p). Una area en la cola£ 0.05 se considera una evidencia fuerte queexiste relacion. Una area en lacola3 0.2 se considera que la relacion es debida a la coincidencia.

14

2.9. PSP 2.1

Los objetivos del PSP2.1 son introducir:

Medidas adicionales para la administracion de la calidad del proceso.

Plantillas de diseno que proporcionan una lınea de trabajo ordenada y formatos para registrar disenos.

2.9.1. Tarea 8

Creacion de un programa para ordenar una lista ligada de n pares de numeros reales en orden descendente.

2.9.2. Tarea 9

Creacion de un programa que calcule el grado con el cual una cadena de n numeros reales esta distribuido demanera normal. Se usara la rutina de integracion de la tarea5 para calcular la distribucion de c2. Supondremos una n¿20 y un multiplo par de 5 ( se puede suponer n = 50 ), se usara larutina de ordenamiento de la tarea 8 para ordenarde manera ascendente los numeros.

La prueba c2 para normalidad determina la probabilidad que un conjunto de datos siga una distribucion normal.Esto es realizado al comparar la estructura del conjunto de datos con la estructura de una distribucion normal ideal.

Esto es realizado al dividir la distribucion normal en segmentos de area identicos y comparar el numero real de puntosdel conjunto de datos que esta siendo probado en cada segmento con el numero de la distribucion normal ideal.

Los pasos de la prueba c2 son como sigue:

1. Ordenar el conjunto de datos en orden ascendente.

2. Normalizar el conjunto de datos.

Primero, calcular la desviacion estandar, usando n-1.

Figura 2.9:

Entonces, transformar cada xi a una zi normalizada.

Figura 2.10:

3. Dividir la distribucion normal en algunos segmentos S, donde

15

n/S35

S > 3

S23nPara este problema, S=10 satisface estos requerimientos.

4. Determinar cuantos elementos de la distribucion normal caerıan en cada segmento, Ni. Normalmente, esto esn/S; en este caso es 5.

5. Determinar cuantos elementos del conjunto de datos normalizados caen en cada segmento, ki.

6. Calcular el valor Q para los segmentos.

Figura 2.11:

7. Calcular la probabilidad p de la distribucion c2 para S-1grados de libertad (dof) al integrar de 0 a Q.

Figura 2.12:

Nota: La ecuacion anterior para c2 difiere de la ecuacion A7, pagina 518, por:

Sustituir dof por n.

Sustituir Q por x.

8. Calcular la cola de la distribucion como 1-p.

9. Examinar 1-p para interpretar los resultados.

1 − p < 0,05 es generalmente considerado suficiente para rechazar que ajusta.

1 − p > 0,2 es generalmente considerado suficiente para aceptar que ajusta.

Valores intermedios indican grados intermedios de ajuste.

2.9.3. Tarea 10

Creacion de un programa para calcular los parametros de estimacion de regresion multiple de tres variables(β0, β1, β2, andβ3).

Hacer un estimado de las entregas proporcionadas por el usuario y determinar los intervalos de predicciondel 70 % y 90 % para el estimado.

Se hara uso de una lista ligada para almacenar los datos y de larutina de integracion de la tarea 5 para calcularla distribucion t.

16

La regresion multiple proporciona una forma de estimar los efectos de multiples variables cuando no se tienendatos separados para cada una de ellas.

Los 13 pasos se describen a continuacion.

1. Utilizar la siguiente formula de regresion multiple para calcular el valor estimado.

Figura 2.13:

2. Encontrar los parametros Beta resolviendo las siguientes ecuaciones lineales simultaneas.

Figura 2.14:

3. Cuando se calculen los valores de los terminos, se obtendran las siguientes ecuaciones lineales simultaneas.

Figura 2.15:

17

4. Diagonalizar, utilizando el metodo de Gauss. Esto elimina de manera sucesiva un parametro a un tiempo de lasecuaciones mediante la multiplicacion y resta sucesiva para dar lo siguiente.

Figura 2.16:

5. Resolver para los terminos Beta.

Figura 2.17:

6. Determinar el intervalo de prediccion resolviendo parael rango con la siguiente ecuacion.

Figura 2.18:

7. Calcular la varianza como sigue.

Figura 2.19:

18

8. La varianza se evalua con lo siguiente.

Figura 2.20:

9. Los terminos en la raız cuadrada son los siguientes.

Figura 2.21:

10. El valor de la distribucion t para un intervalo de prediccion del 70 % es encontrado bajo la columna 85 % y dosgrados de libertad en la tabla A2, pagina 489.El es 1.386.

11. La raız cuadrada se evalua de la siguiente manera.

Figura 2.22:

12. El estimado final es:z = 6.71+0.0784*650+0.0150*3,000+0.2461*155z = 140.902 horas

13. El intervalo de prediccion de 38.846 horas significa queel estimado esta entre 102.1 y 179.7 horas.

Para resolver un sistema de N incognitas.

La eliminacion Gaussiana es un algoritmo comun para resolver estas ecuaciones.Algoritmo de gauss

1. I = 1

2. LET P=AK , I = maxjAJ, Ij : I£J£N (Encuentre el valor pivote el cual es el numero mas grande en lacolumna por debajo de la posicion I,I.)

3. IF P = 0 THEN SALIR (Si el resto de esta columna es cero, no existe una solucion unica.)

4. IFK > I THEN FOR J = I TO N + 1 INTERCAMBIA A(I,J) Y A(K,J) (Tome el valordel pivote en la posicionI,I.)

5. FOR J = I + 1 TO N + 1 ASIGNA AI , J = AI , J / AI , I (Coloca un 1 en la posicion I,I.) ASIGNA AI , I = 1.

6. FOR L = I + 1 to N multiplicar renglon I por -AL , I y sumar a renglon L (se colocan ceros a la columna pordebajo de la posicion I,I.)

7. I = I + 1. IF I < N THEN IR AL PASO 2.

8. SALIR a sustitucion hacia atras (¡Diseno su propio algoritmo!)

19

2.10. R5: Reporte de Analisis del Proceso

Objetivos

Producir un reporte sobre lo que se aprendio en este curso que nos ayude a comprender nuestro desempenoactual en el desarrollo de software y donde debemos mejorar.

Ganar experiencia en el establecimiento de metas medibles yen la deteccion de las acciones de mejoracorrespondientes. Aprender a actualizar nuestro proceso personal.

Se actualizara el proceso usado en R4 para desarollar este reporte.

Utilizar este proceso para:

Planear las tareas del reporte R5.

Analizar sus datos de proceso.

Producir el reporte.

Completar el postmortem.

Al menos se debera hacer lo siguiente.

Analizar la exactitud en el estimado de tamano y determinarel grado con el cual lo estimado estuvo dentrode los intervalos estadısticos de prediccion del 70 % y 90 %. Muestrar como la exactitud en la estimacion deltamano ha evolucionado durante las tareas.

Analizar la exactitud en el estimado de tamano y determinarel grado con el cual lo estimado estuvo dentrode los intervalos estadısticos de prediccion del 70 % y 90 %. Muestrar como la exactitud en la estimacion deltiempo ha evolucionado durante las tareas.

Analizar los tipos de defectos que se introducen en diseno ycodificacion. Incluir un analisis Pareto de estostipos de defectos. (Ver el Apendice A12 para una descripci´on del procedimiento del analisis de Pareto.)

Analizar las tendencias para defectos por KLOC encontradosen revisiones de diseno, revisiones de codigo,compilacion y pruebas.

Analizar las tendencias para los defectos totales por KLOC.

Analizar las tasas de eliminacion de defectos para las revisiones de diseno, revisiones de codigo, compilacionversus pruebas unitarias. En aquellos casos donde no se tengan defectos, utilizar la tasa promedio de eliminacionde defectos de las pruebas unitarias

Analizar el rendimiento (yield) versus LOC revisadas por hora en las revisiones de codigo.

Analizar el rendimiento de la revision de diseno versus las LOC revisadas por hora.

Analizar el rendimiento versus el A/FR de los programas 7 al 10

Describir las areas de mas alta prioridad para la mejora del proceso personal y justificarlas. Asegurando resumirel desempeno actual, desempeno futuro y metas de mejora. Describir como se intentan cumplir esas metas.

El diseno de proceso debe incluir una:

Fase de planeacion.

Fase de desarrollo.

Fase de postmortem.

20

El reporte debe incluir:

Todas las tablas y graficas requeridas, mas cualquier otra grafica o datos que apoyen el analisis.

Analisis y conclusiones por escrito.

Metas de mejora cuantitativas y medibles y acciones especıficas que se planeen tomar para lograr esas metas.

21

Capıtulo 3

Resultados

3.1. Formas, Plantillas y estandares para su utilizacion en PSP

Tabla de referencia

Figura 3.1: Tabla de referencia

22

3.2. Bitacora de Tiempo.

En ella registraremos cada una de las actividades que llevemos a cabo durante el lapso de tiempo que dedique-mos a la realizacion del proceso (Tareas).

Figura 3.2: Ejemplo de la Bitacora de Tiempo (Tarea 6)

3.3. Registro de defectos.

En esta se plasman la informacion de defectos (errores) cometidos en la realizacion de las tareas, la informa-cion debe ser lo mas completa posible, el registro esta conformado por el numero de tarea donde se cometio, la fecha,el numero continuo, el tipo de error, tiempo de correccion yuna breve descripcion del mismo.

Figura 3.3: Ejemplo del registro de errores (Tarea 6)

23

Tipos de defecto

Figura 3.4: Tabla de tipos de defecto

24

3.4. Estandar de Conteo de LOCs de Java (R1)

Nombre de la definicion: Estandar de LOCs de JavaLenguaje: JavaAutor: Daniel Chinas vega Fecha: 07/10/06

Tipo de Conteo Tipo ComentariosFısico / Logico LogicoTipo de Instruccion Incluido Comentarios

Ejecutable SiNo ejecutable

Declaraciones Si, Nota 3Directivas del compilador Si, Nota 4Comentarios No

En lıneas propias NoCon el fuente NoEncabezados No

Lıneas en blanco NoAclaraciones Ejemplos / CasosNulos continues, no-opsInstrucciones vacıas Si ”;;”, ;’s solos, etc.Intanciadores genericosBegin...end Nota 1 cuando esten en codigo ejecutableBegin...end Nota 1 cuando esten en codigo no ejecutablePrueba de condiciones SiEvaluacion de expresiones Si Cuando se utilice como argumentos de subprogra-

masSımbolos End Notas 1 y 2 Cuando terminen instrucciones ejecutablesSımbolos End Notas 1 y 2 Cuando terminen declaraciones o cuerposelse Nota 1Palabras clave Si Division de procedimientos, interfaz, imple-

mentacionEtiquetas Si Destinos de saltos cuando esten en lıneas sepa-

radasNota 1 A menos que sea seguido por un ; o incluido en

{ }, cuente una vez las siguientes palabras clave:switch, case, if, else, do, while, for, private, public,protected, try, catch.

Nota 2 Cuente una vez cada ocurrencia de: ;, ”{” . . . ”}”Nota 3 Cuente una vez cada declaracion de variable o de

parametro.Nota 4 Cuente una vez cada instruccion package e import.

25

3.5. Java Standard de codificacion (R2)

Proposito: Una guıa para el desarrollo de programas en javaEncabezado Comenzar todos los programas con un encabezado descriptivo.Formato deencabezado

/************************************************** ***********//* Asignacion de programa: numero de programa *//* Nombre: nombre del Desarrollador *//* Fecha: Fecha de inicio del desarrollo del programa *//* Descripcion: una pequena descripcion del programa *//* y su funcion *//************************************************** ***********/

Contenido dellistado fuente

Proporcionar un resumen del contenido del listado fuente.

Ejemplo decontenido

/************************************************** ***********//* Contenido del listado fuente: *//* Instrucciones para su reutilizacion *//* Instrucciones para su modificacion *//* Instrucciones para su compilacion *//* Package *//* Imports *//* Nombre de la clase CData *//* Declaracion de Variables *//* Instancias de clases *//* Funciones y metodos *//************************************************** ***********/

Instruccionesde reuti-lizacion

-Describe como se utiliza el programa. Proporciona el formato de declaracion,los valores y los tipos de parametro.- Proporcionar las advertencias para conocer los valores ilegales, las condi-ciones de desbordamiento, o de otras condiciones que podrıan potencialmentedar lugar a la operacion incorrecta de la clase.

Ejemplode instruc-ciones dereutilizacion

/************************************************** ***********//* Instrucciones de reutilizacion *//* int PrintLine(char *cadenade caracteres) *//* Proposito: para imprimir la secuencia, ”lineof character”, *//* en una lınea de impresion a pantalla *//* Limitaciones: El tamano maximo de lınea es *//* LONGITUD DE LINEA *//* Devuelve : 0 si la lınea no se puede imprimir, caso contrario 1 *//************************************************** ***********/

Identificadores Utilizar nombres que describan correctamente todas las variables, funciones,constantes y otros identificadores. Evite el uso de abreviaturas o nombres deuna sola letra.

Ejemplode identifi-cadores

int numerode estudiantes; /* Bien */float X, j, fCad; /* Mal */

26

Java Standard de codificacion (Continuacion)

Comentarios - Documente el codigo de modo que el lector pueda entender sufuncionamien-to.- Los comentarios deben explicar el proposito y el comportamiento del codigo.- Comente la declaracion de variables para indicar su prop´osito.

Buen comen-tario

if(contadorregistro ¿limite) /* se han procesado todos los registros? */

Mal comen-tario

if(contadorregistro ¿limite) /* revisa si contadorregistro es mayor que limite*/

Secciones im-portantes

Las partes importantes del programa deben estar precedidaspor un comentariode esa seccion, este comentario debe describir el funcionamiento de esa parteel programa.

Ejemplo /************************************************** ***********//* Esta seccion del programa examinara el contenido del arreglo ”califica” *//* y calculara el valor medio para la clase. *//************************************************** ***********/

Espacios enblanco

- Escribe el programa con suficiente espaciamiento de modo que no parezcaque hay poco espacio.- Separara cada parte del programa con al menos un espacio.

Tabuladores - Indica claramente cada nivel del programa.- El inicio y fin deben encontrarse alineados correctamente ası como las lıneasde cada nivel.

Ejemplo detabulacion

while (distancia ¿limite){

accion = muebemano (lugarapuntado);if (codigo accion = fallomovimiento){printf(”El movimiento de la mano fallo.\n”);}

}Mayusculas - Estaran en Mayusculas todas las constantes.

- Deben ir en minusculas todos los demas identificadores y palabras reservadas.- Los mensajes que lee el usuario (Salidas del programa) pueden ir en mayuscu-las / minusculas, para hacer una mejor presentacion para el usuario.

Ejemplo mayusculas #define DEFAULT-NUMBER-OF-STUDENTS 15int class-size = DEFAULT-NUMBER-OF-STUDENTS;

Metodos Todo metodo debe tener claramente indicado su tipo, esto es: Private, Protectedy Public

Ejemplo de metodos void metodo() //mala definicionPublic metodo() //buena definicion de un metodo

27

3.6. Estimacion de tamano

Para la estimacion de tamano se usa una plantilla, la cual es suministrada por:

Carnegie Mellon University

Figura 3.5: Ejemplo de plantilla de estimacion de tamano (tarea 6)

28

3.7. Design Review Checklist.

El checklist nos proporciona un metodo controlado y repetible para mantener un control de calidad en nue-stros disenos, es la principal herramienta para mejorar lacalidad de nuestros proyectos. Este chequeo debe llevarse acabo antes de dar por finalizada la etapa correspondiente.

PROGRAM NAME AND NUMBER

Purpose Guiarnos en la conduccion de una revision de diseno efectiva Program Unit NameGeneral - Al terminar cada paso de la revision, senalar en la derecha.

- Terminar la lista de comprobacion para cada apartado del programa antes deiniciar la siguiente.

Completo Asegurar que el diseno cubre completamente los requerimientos, especifica-ciones y diseno de alto nivel:- Se generan todas las salidas especificadas.- Se incluyen todas las entradas necesarias.

Logica Comprobar que la secuencia del programa es la apropiada:* Las pilas, listas y otros estan en el orden apropiado.* La recursion regresa de manera apropiada.

- Verificar que todos los ciclos se inicializan, incrementany terminan de man-era apropiada

Casos Espe-ciales

Comprobar todos los casos especiales:- Asegurar la operacion apropiada de todas las variables definidas.- Especificar el valor de inicio de cada variable.- Proteccion por condiciones fuera de los lımites, sobreflujo o bajoflujo.- Asegurar que las condiciones ”imposibles” sean absolutamente imposibles.- Manejar todas las condiciones de entradas incorrectas

Uso Fun-cional

- Verificar que todas las funciones, procedimientos u objetos estan completa-mente comprendidos y se usan de manera apropiada.- Verificar que todas las funciones, regresen lo esperado

Nombres Verificar lo siguiente:- Todos los nombres y tipos especiales estan clara y especıficamente definidos.- Los alcances de todas las variables y parametros son evidentes o estandefinidos.- Todos los nombres de los objetos se usan dentro de sus alcances declarados.

Estandares - Revisar que el diseno cumpla con todos los estandares de diseno que seanaplicables.

29

3.8. Code Review Checklist

PROGRAM NAME AND NUMBER

Proposito Guiarnos en la conduccion de una revision de codigo efectiva Program Unit NameGeneral - Conforme se termine cada paso de revision, compruebar el elemento en la

caja de la derecha.- Terminar la lista de comprobacion para cada apartado del programa antes deiniciar la siguiente.

Completo - Verificar que el codigo cubre el diseno.Import’s - Verificar que los imports estan completos.Inicializacion Comprobar la inicializacion de variables y parametros:

- Al inicio de la Clase.- Al inicio de cada ciclo.- En el inicio de cada funciones/procedimientos

Llamadas Comprobar los formatos de llamada a metodos:- Parametros

Nombres Comprobar el uso y escritura de nombres:- ¿Es consistente?

Los nombres de variables son consistente.Las palabras reservadas estan correctamente escritas.

- ¿Esta dentro del alcance declarado?Formato deSalida

Comprobar el formato de salida:- ¿El espaciamiento de lıneas es el apropiado?- ¿El espaciamiento es el apropiado?

Parejas{} - Asegurarse de que las{} son los apropiados y se corresponden.- Asegurarse de que los ( ) son los apropiados y se corresponden

OperadoresLogicos

- Verificar el uso apropiado de ==, =, ——, != y demas.

RevisionLınea-por-lınea

Comprobar cada LOC por- Toda instruccion termina en ;.- Sintaxis de la instruccion.- Que la puntuacion sea la apropiada.

Estandares Asegurar que el codigo se apega a los estandares de codificacion.Cierre yApertura deArchivos

Verificar que todos los archivos estan:- declarados de manera apropiada,- abiertos, y- cerrados.

30

3.9. Escenario operacional.

Describe los escenarios de prueba de acuerdo a los requerimientos dados por el usuario de tal forma que seespecifican todas las interacciones entre el sistema y el usuario.

Figura 3.6: Ejemplo de un escenario de operacion (Tarea 8)

31

3.10. Especificacion funcional

Define los servicios funcionales proporcionados por los objetos

Figura 3.7: Ejemplo de la especificacion funcional de un objeto ( Tarea 9)

32

3.11. Especificacion de estados

Especifica los estados de cada objeto y la interaccion entrelos mismos.Table C70 State Specification Template

Student Chinas Vega Daniel DateProgram Tarea 8 Program # 8AInstructor Castro Careaga Luis FernandoLanguage JavaObject Lista ligada Routine Ordenamiento

State #1 Inicia Descripcion Checa nu-mero de elementos enla lista

Attributes Listaligada

Transition ConditionsVacio EmptyUnico Lista ligada.size = 1VariosElementos Lista ligada.size>1

State #2 Vacio Descripcion Lista sinelementos

Attributes Empty

Transition ConditionsRegresa null

State #3 Unico Descripcion Lista conun elemento

AttributesLista ligada.size=1

Transition ConditionsTermina Return listaligada

State #4 VariosElemen-tos

Descripcion Lista conmas de un elemento

AttributesLista ligada.size>1

Transition ConditionsTermina Lista ordenada <-

setOrdenamientoIn-sercionDirecta (lista ligada)

State #5 Ordena Descripcion Ordena lalista de manera ascen-dente

AttributesLista ordenada,tamano, componente

Transition ConditionsTermina Return listaordenada

33

3.12. Especificacion logica

Especifica la funcionalidad de cada objeto (Pseudo codigo).

Logic referencenumbers

Program logic, in pseudocode

Lista OrdenaLista(Lista listaligada, int componente){

Lista lista resultado = null;si(lista ligada.esvacia){

lista resultado = null;}otro caso{

int tamano;tamano = NumElementos(listaligada);si(tamano==1){

lista resultado = listaligada;}otro caso{

si(tamano>1){

lista ordenada = listaligada;oredena(listaordenada,tamano,componente);lista resultado = traelista;

}}

}retorna listaresultado;}

34

3.13. Propuesta de mejora de proceso (PIP)

La forma PIP es un estandar previamente disenado para presentar propuestas de mejora al proceso PSP. Dichapropuesta de mejora nace conforme obtengamos mas experiencia y confianza al usar el PSP.

PIP ( tarea 2 a la 10 )

Student Chinas Vega Daniel Date 08/10/06Instructor Castro Careaga Luis FernandoProgram # 2AProcess PSP0.1 Elements

PIP Number Problem Description:1 1 Consumo de tiempo en la lectura para la posterior aplicacion de el guion de trabajo de

psp2 Constantes pausas en la realizacion de la fase postmorten, por falta o dudas sobre la

realizacion de ella (especıficamente la tabla de locs).2 La estimacion de lıneas de codigo ( Logicas ) resulto demasiado alejada de lo real

Propoal PIPNumber

Proposal Description

1 1 El uso de problemas ejemplo para tener una mayor practica en el uso y manejo de losguiones psp,

2 La utilizacion de ejemplos que nos den una mayor practica en el llenado de las es-tadısticas de el proceso PSP

2 Se debe tener mas cuidado en la estimacion de locs, esto en base al tipo de programay como sera resuelto.

Notes and Comments:

Registro de lo aprendido del proceso: 1.la realizacion y puesta en practica de un Standard, en este caso el deconteo de lıneas y el de codificacion.

2.El uso de la forma PIP.No entiendo claramente el llenado Project Plan Summary en elapartado de locs.

35


PIP Number Problem Description:1 La estimacion de tiempo quedo bastante pequena en comparacion a lo real2 Diseno conceptual incompleto, se anexo una clase mas durante el diseno de algoritmo

Propoal PIPNumber


1 Se debe tener en cuenta tanto lo nuevo que se hara como las modificaciones de lo queya se tenia, y todo lo que esto conlleva para poder hacer una estimacion mas cercanadel tiempo.

2 Se debe tomar un poco mas de tiempo para detallar correctamente el diseno concep-tual, ası mismo el diseno se debe de hacer con mas cuidado para no olvidar nada.

Notes and Comments:

Registro de lo aprendido del proceso: 1.aproximacion a unaestimacion en el tamano de un programa a realizar2.R3 analisis de defectos

Me siento actualmente mas comodo con le conteo de locs, siendo esto ya algo mas natural para hacer.


PIP Number Problem Description:1 Se debe tener en cuenta un mayor detalle a la hora de la planeacion para definir con

menor margen de error la estimacion de los metodos que se agregaran clases ya exis-tentes.

Propoal PIPNumber


1 Se debe tener en cuenta tanto lo nuevo que se hara como las modificaciones de lo queya se tenia, y todo lo que esto conlleva para poder hacer una estimacion mas cercanadel tiempo.

Notes and Comments:

Registro de lo aprendido del proceso: 1. Llenado de la BD de O personal para la estimacion de tamanos2.Llenado de la plantilla de estimacion de tamano.3.Uso del PROBE.4. Calculo de LOCs/Hora5.Pruebas automatizadas

El promedio de errores por k/loc disminuyo, aunque aun cometo numerosos errores, el hecho de llevar a cabo lafase de codificacion en el editor de texto me ha ayudado a cometer meno errores cada vez que codifico algo nuevo

36


PIP Number Problem Description:1 Problema en la estimacion de numero de funciones por clase.

Propoal PIPNumber


1 Hacer una planificacion mas especifica y a su vez ir pensandoen las posibilidades parasatisfacer los requerimientos para ası lograr una mejor estimacion.

Notes and Comments:

Registro de lo aprendido del proceso: 1.CPI (el ındice de costo-desempeno)

El promedio de errores por k/loc disminuyo, creo que este metodo de codificacion si el uso de otras herramientasme ha servido para mejorar esto, aunque aun tengo que mejoraraun mas.


PIP Number Problem Description:1 Problema en las pruebas. Creo esta vez el tiempo utilizado en ellas fue mayor a

cualquiera anterior.2 La estimacion de locs nuevas a la base fue muy diferente al real.2 La estimacion de lıneas de codigo ( Logicas ) resulto demasiado alejada de lo real

Propoal PIPNumber


1 Dar un poco mas tiempo a la planeacion y a la codificacion, a favor de generar unprograma mas limpio de errores y que cumpla con su cometido

2 En la etapa de diseno tomar en cuenta lo que planeamos haceren cada clase paracalcular de mejor manera las adicciones a la base planteada.

Notes and Comments:

El tiempo empleado en pruebas fue casi igual al de la codificacion, puesto que el error cometido fue muy difıcilde observar y por lo tanto de corregir, se debe disenar con mas calma y explicar con mas detalle lo que se hara enbusca de cometer menos errores.

37

Student Chinas Vega Daniel Date 05/02/07Instructor Castro Careaga Luis FernandoProgram # 7AProcess PSP2 Elements

PIP Number Problem Description:1 Confusion en el llenado de algunos campos de los nuevos quese agregaron.

Propoal PIPNumber


1 Revisar el proceso de nuevo par alimentar los nuevos conocimientos.

Notes and Comments:

Registro de lo aprendido 1 uso de listas de comprobacion

Student Chinas Vega Daniel DateInstructor Castro Careaga Luis FernandoProgram # 8AProcess PSP2.1 Elements

PIP Number Problem Description:01 Los ejemplos para el uso de las nuevas plantillas son muy reducidos.

Propoal PIPNumber


01 Un ejemplo completo en el que se describa el llenado de cadaplantilla.

Notes and Comments:

El uso de las 4 nuevas plantillas para mejorar el proceso de diseno

38


PIP Number Problem Description:01 El llenado de la plantilla de State Specification y los ejemplos de la misma son poco

especıficos.

Propoal PIPNumber


01 Un ejemplo completo del desarrollo de esta plantilla parauna mejor comprension.

Notes and Comments:

El uso de las 4 nuevas plantillas para mejorar el proceso de diseno


PIP Number Problem Description:El uso del template de State Specification queda aun poco claro.

Propoal PIPNumber


Un ejemplo detallado del template y un detallado escenariode uso para ese template,para tener una idea mas concreta de su utilizacion.

Notes and Comments:

En esta tarea se utilizo PSP 2.1.1.Omitı el uso del template de state specification y de Functional Specification

39

3.14. Reporte de la mitad del Proceso (R4)

Script

Phase # Purpose To guide the analysis and writing of the R4 ReportCriterio de entrada Programas del 1A al 6A Terminados

Copia de los requerimientos de cada programaCopia de los reportes entregados para cada programaCopia del Stuwbk.xls

Planning Estimacion de esfuerzo para la fase de planeacion ( en minutos )Estimacion del tamano del reporte

Numero de parrafosNumero de graficas analizadas

Registrar las siguientes estimaciones;Estimacion de esfuerzo en base a la estimacion de tamano (en minutos )Estimacion de esfuerzo para las fases del reporte siguientesRegistrar el tiempo de planeacion en el time logPor cada pregunta del analisis entregue lo siguiente

Analisis general de la tabla o grafica usadaAnalizar el proceso/datos de la tabla o graficaEscribir el parrafo del analisis

Identificar areas de mejoraDeterminar metasDeterminar si algun proceso necesita cambiosEscribir el analisis de mejora del funcionamientoEscribir el tiempo de desarrollo en el time log

Postmortem Escriba el informe de tamano del reporte (por pregunta)# de tablas# de graficas# de parrafos

Escriba el tiempo de post morten en el time logExit Criteria Completo el reporte R4

Completo el reporte de planificacionCompleto el timelog

40

3.15. R4 Report Plan Summary

Figura 3.8:

41

3.16. R4 Time Recording Log

Student: Chinas Vega Daniel Date: 03/12/06

Date Start Stop Interruption Time DeltaTime Phase Comments03/12/06 13:27:00 13:38:00 0 11 planeacion Termine con la

planeacion de re-porte R4

03/12/06 13:41:00 15:59:00 0 138 Desarrollo Desarrollo termina-dos los dos primerosanalisis, se tomoalgunos dıas paracorregir los erroresde las hojas R3 y R4del archivo de Excel

09/12/06 12:14:00 13:47:00 0 83 Desarrollo Fin del desarrollo09/12/06 14:20:00 14:30:00 0 10 PM Postmorten termina-

da

42

3.17. Reporte R4

3.17.1. Analisis de la Exactitud de Estimacion de Loc

Analice la tendencia en la exactitud de estimacion de tamano en los primeros seis programas.

Figura 3.9: Error en el estimado de tamano para cada programa

Si bien la estimacion de tamano para cada programa se pueden observar claramente dos picos el mayor deellos el de subestimacion para A2 y el otro pico para sobre Estimacion en el programa 6A, si bien a partir del programa3A la estimacion de tamano a sido sobre estimada, en el 6A alcanza un valor considerable.

En el programa 2A se debe a la falta de una planeacion correcta, en contraste en el 6A aun con la experiencia yherramientas adquiridas en los anteriores programas se obtiene de nuevo una estimacion errada considerablemente,esto se debe al poco tiempo que le dedico a la planeacion y al diseno.

Figura 3.10: Tiempo de Planeacion

El tiempo de planeacion venia incrementandose a partir del programa 3A lo que resultaba en una mejor es-timacion de tamano, lo cual en el programa 6A disminuye, aun cuando el programa 6A tenia una mayor complejidadcon respecto a sus antecesores, de eso se desprende el que la estimacion fuera mayor a lo real.

43

Para cada uno de los programa 4, 5 y 6, ¿como se comparan las LOC de objeto estimadas con las LOC deobjeto reales?

Figura 3.11:

Se nota una clara tendencia a la sobreestimacion, si bien enel 5A esta iba disminuyendo en el 6A esta au-menta considerablemente con respecto a lo anteriormente visto.

Para cada uno de los programa 4, 5 y 6, si las LOC de objeto estimadas no estan cercanas las LOC de objetoreales, determine por que.

El error se debe a la mala planeacion y un mal estimado en el tamano de los metodos por lo cual se tendıa aesperar mas locs por objeto. Esto aumento en el programa 6A puesto que dependıa de mas metodos y por lo tanto elerror fue mayor.

Basado en el analisis anterior, ¿cual es la mejor cosa que usted podrıa hacer para mejorar su exactitud en laestimacion?

Tomar mas tiempo en al fase de planeacion para llevar a cabo una mejor estimacion de la cantidad de metodosy su tamano, ası como aprovechar mejor los datos historicos con los que cuento para en base a ellos llevar a cabo miplanificacion.

44

De la hoja PROBE de su libro de trabajo del estudiante y ponga el selector del programa para el programa 7.Examine las betas del metodo A. ¿Son utiles para la estimacion del programa 7? Explique por que o por que no

PROBE Method SelectorProject 7

Estimate (E) 0Size Method B

SelectorSize Estimate 210,42676

Range 203,05957B0 210,42676B1 0,0118365R2 0,0002841

De procedimiento.

Si Beta 0 no es cercana a cero o si Beta 1 no esta razonablementecerca de 1.0 (entre 0.5 y 1.5) no se puedeutilizar este procedimiento para calcular el estimado de tamano de un programa,en base a esto no es posible usar estosvalores para la estimacion de tamano.

3.17.2. Analisis de la Exactitud de Estimacion de Tiempo

Analice la tendencia en la exactitud de estimacion de esfuerzo en los seis primeros programas.

Figura 3.12: Error en el estimado de tiempo para cada programa

Se muestra claro pico en la estimacion para el programa 3A locual va disminuyendo considerablemente paralo siguiente, mostrando una leve subestimacion en el programa 6A.

45

Para los primeros seis programas, ¿que tan estable fue su productividad?

Figura 3.13: Productividad Loc/hora para los primeros 6 programas

Se nota una clara tendencia hacia la alta, es decir la productividad a mejorado puesto que en el programa 6Aes 3 veces mayor que en el 2A , se debe observar que en el 5A la productividad disminuyo con respecto al anterior, eraaun mejor que los tres primeros.

Para los primeros seis programas, si la productividad vario, ¿los cambios estan relacionados con la cantidadde tiempo utilizado en corregir los defectos en las fases de compilacion y pruebas?

Figura 3.14:

46

De las dos graficas anteriores se nota una clara tendencia a ladisminucion de defectos removidos en lacompilacion, mientras que en test no existe una tendencia aaumentar a partir del programa 4A.

Figura 3.15:

Ası mismo el tiempo de compilacion a disminuido con respecto a anteriores programas, esto con respecto alprograma 6A , en base a esto puedo decir que la disminucion detiempo en la compilacion se debe a la disminucion deerrores*kloc que se deben corregir en esa fase, por lo tanto la productividad a aumentado considerablemente.

¿Como fue afectada la exactitud de sus estimados de tiempo por la calidad de sus estimados de tamano?

Figura 3.16:

Por lo visto en ambas graficas no afecto ya que no siguen una misma tendencia en su crecimiento o caıda.

Analisis de los defectos introd. Y eliminados por fase (tabla D23)

Table D23

Number Injected Percentage Injected Number Removed Percentage RemovedType Design Code Design Code Compile Test Compile Test10 0 0 0.00 % 0.00 % 0 0 0.00 % 0.00 %20 0 83 0.00 % 84.70 % 82 1 87.20 % 9.10 %30 0 0 0.00 % 0.00 % 0 0 0.00 % 0.00 %40 2 10 22.20 % 10.20 % 9 2 9.60 % 18.20 %50 1 2 11.10 % 2.00 % 1 2 1.10 % 18.20 %60 0 0 0.00 % 0.00 % 0 0 0.00 % 0.00 %70 5 0 55.60 % 0.00 % 0 5 0.00 % 45.50 %80 1 3 11.10 % 3.10 % 2 1 2.10 % 9.10 %90 0 0 0.00 % 0.00 % 0 0 0.00 % 0.00 %100 0 0 0.00 % 0.00 % 0 0 0.00 % 0.00 %Total 9 98 94 11

47

¿Que tipos de defectos se introducen mas en la fase de diseno?

Type Design10 020 030 040 250 160 070 580 190 0100 0Total 9

Es claro que el error mas cometido es el tipo 70 es decir un error de datos, tambien es correcto afirmar queestos errores fueron cometidos en el programa 6A.

6 31/11/2006 102 70 DLD TEST 10,0 se debe calcular primero b1 y luego b06 31/11/2006 103 40 DLD TEST 15,0 se debe volver a dar el valor de lista a listaTemporal6 31/11/2006 104 70 DLD TEST 10,0 se debe calcular el valor de porcentaje como x*,016 31/11/2006 105 70 DLD TEST 20,0 se debe mantener los valores doubles es decir 1,00 no 16 31/11/2006 106 70 DLD TEST 1,0 se cambio 1 por 1,006 31/11/2006 107 70 DLD TEST 1,0 se cambio 2 por 2,00

Errores debidos a la falta de diseno y el correcto uso de los tipos de datos usados en las operaciones efectu-adas y el mal calculo de algunas de ellas.

¿Que tipos de defectos se introducen mas en la fase de codificacion?

Type Code10 020 8330 040 1050 260 070 080 390 0100 0Total 98

El error mas cometido en la codificacion es el tipo 20, es decir el de sintax esto debido en gran medida alpoco cuidado que se le pone a la codificacion, puesto que algunas funciones son disenadas o ampliamente modificadasde su diseno original en esta fase.

48

Que tipos de defectos se eliminan principalmente en la fase de compilacion

Type Compile10 020 8230 040 950 160 070 080 290 0100 0Total 94

El tipo de defecto que es mayormente removido en esta etapa estambien el mas cometido en la codificaciones decir el de syntax, esto es normal puesto no podremos compilar correctamente hasta haber escrito la syntaxi correc-tamente para cada instruccion. Puesto que el compilador nome dejara avanzar mientras estos errores existan.

¿Que tipos de defectos se eliminan principalmente en la fase de pruebas?

10 020 130 040 250 260 070 580 190 0100 0

En este caso es claro que el tipo 70, lo cual nos lleva al mismo caso de cuales son los defectos que mas seinsertan en la fase de diseno y en ambos casos el programa 6A fue el que ocasiono este tipo de error.

Errores debidos a la falta de diseno y el correcto uso de los tipos de datos usados en las operaciones efectu-adas y el mal calculo de algunas de ellas.

49

3.17.3. Analisis de los defectos introd. Y eliminados por fase (R3).Defect Densities Compile and Test Defects

ProgramNumber

New andChangedLOC

Total Defects Defects perKLOC

Defects foundin compile

Compiledefects perKLOC

Defects foundin test

Test defectsper KLOC

1 137 24 175 23 168 1 72 136 22 162 20 147 2 153 92 12 130 10 109 0 04 318 25 79 24 75 1 35 199 10 50 9 45 1 56 321 14 44 8 25 6 197 0 0 0 0 0 0 08 0 0 0 0 0 0 09 0 0 0 0 0 0 010 0 0 0 0 0 0 0Totals 107 0 94 0 11 0

R3

Analice los tiempos de eliminacion de defectos, basandose en la fase en la que los defectos son introducidos yeliminados

Defect Fix TimesDefects found in compiling Defects found in testing Total defects found

Defects injected in designing Tot. fix time 0 58 64Tot. defects 0 7 9

Avg. fix time 0 8 7Defects injected in coding Tot. fix time 155 21 176

Tot. defects 94 4 98Avg. fix time 2 5 2

Total defects injected Tot. fix time 155 79 240Tot. defects 94 11 107

Avg. fix time 2 7 2

Bueno es claro que la fase que mas defectos inyecta es la de codificacion y que es en la de compilacion donde sonremovidos, si bien el tiempo promedio que se ocupa en removerlos es menor en compilacion en comparacion a la fasede test que es 2.5 veces mayor, si se compara el tiempo total que se uso para remover los defectos no encontramoscon que la fase de codificacion ocupa 2/3 del tiempo mientrasque solo 1/3 parte del tiempo es ocupado en removerdefectos en el test.

¿Que categorıa tiene el tiempo promedio de eliminacion mas grande?

El tiempo de eliminacion en test es mayor, esto debido a que los errores removidos en esa fase son mayor-mente inyectados en la fase de diseno

¿Que categorıa tiene el tiempo total de eliminacion mas grande?

El tiempo mas grande de eliminacion de errores es la de compilacion, esto debido en gran medida a que lamayor cantidad de errores son de sintaxis, los cuales son removidos en la fase de compilacion.

50

3.17.4. Analisis de defectos encontrados por el compilador (tabla D24)

Tabla D24Defect Type Number of defects through CompileNumber of defects found in CompilegPercentage of Type found by the Compiler

10 0 020 83 83 98.8 %30 0 040 11 9 81.8 %50 3 1 33.3 %60 0 070 5 0 0.0 %80 3 2 66.7 %90 0 0100 0 0Total 105 94 89.5 %

Analice la efectividad del compilador eliminando defectospor tipo de defecto

Los tipos de defecto 20, 40 y 80 son encontrados mayoritariamente por el compilador, el cual por lo vistohace muy bien su trabajo, puesto que la mayorıa de estos es debido a una mala sintaxis, asignacion de tipos de variablees normal que esto suceda.

¿El compilador encuentra todos sus defectos del tipo 20 (sintaxis / tipos)?

No le falta un defecto, esto podria ser por error mio a ldefinirel tipo de error puesto que el error que nodetecta es el siguiente

5 11/18/06 93 20 CODE TEST 5,0 falta ( ) en la evaluacio nde la funcion

El cual podrıa ser mas propiamente de asignacion. Por lo tanto excluyendo este podrıamos decir que efecti-vamente encuentra todos los errores de tipo 20.

3.17.5. Areas de prioridad para mejora en la 2da. Mitad del curso

Areas para mejorar y que cuentan con mayor prioridad para un mejor desempeno personal.

Planeacion y Diseno

Planeacion

Mi desempeno en esta area a sido errado con respecto a la estimacion de tamano en loc de los programas,esto debido en gran medida al poco tiempo que le doy, ası mismo el poco uso que le e dado a las herramientas con quedispongo para auxiliarme en esta etapa del desarrollo de mistareas.

Al aumentar un poco de tiempo en esta area es decir poner mas atencion en los requerimientos que se mepiden, para poder hacer una mejor planeacion.

Diseno

En este apartado, creo debo ser mas especifico en mis disenosy dejar menos cosa ambiguas, ası el tiempode codificacion sera menor y los errores introducidos disminuiran, lo que llevar a un menor tiempo en las fases decompilacion y pruebas, lo que mejorara mi desempeno.

Productividad

51

En base a lo anterior se espera aumentar mi productividad, actual mente para el programa es 57,49, por lo cualel proposito seria mantenerla cercana a 60 para ası mejorar la productividad a la fecha que es de 36,86, que esperarıafuera de 45 al terminar los proyectos de psp

Cambios en EtapasEtapa de Planeacion

Propongo hacer mas especıfica esta etapa, anadiendo al diagrama actualmente utilizado, uno que cuente concada una de las clases planeadas, los metodos planeados para cada fase en forma de tablas, a cada funcion se ledesignara un tamano especıfico y la suma de sus locs sera eltotal de locs de la clase.

Etapa de diseno

El diseno comprendera en una primera instancia un diagrama de secuencia para hacer el diseno mas especıfi-co.

52

3.18. Reporte R5

3.18.1. Reporte de final de proceso (R5)

Script

Fase # Proposito Guiar el analisis y la realizacion del reporte R5Criterio de entrada - Tareas 1A a 10A completos

- Reportes R1, R2, R3 y R4- Student workbook (hoja excel)

1 Planeacion - Estimar el tamano del reporte* Numero de parrafos de analisis* Numero de tablas/graficas a utilizar

- Estimar el esfuerzo basado en el tamano del reporte- Registrar estimados en la forma Plan Summary- Registrar tiempo de planeacion en time log.

2 Desarrollo - Para cada pregunta del analisis* Generar una/s tabla/grafica para analisis o una tabla de datos si es

posible* Analizar tabla/grafica y datos del proceso* Escribir parrafo de analisis

- Revision del desenvolvimiento general- Identifcar areas en donde mejorar- Revision de metas pasadas- Determinar cambios y proponer medidas al proceso- Poner metas cuantificables- Darle formato- Registrar tiempo de desarrollo en time log

3 Postmortem - Medir tamano del reporte* Numero de tablas/graficas* Numero de parrafos de analisis

- Completar la forma Plan Summary- Registrar tiempo de postmortem en timelog

4 Criterio de Salida - Reporte R5 completo- Plan Summary completo- Time log completo

53

3.18.2. R5 Report Plan Summary

Student Daniel Chinas Vega Date 27/01/08Instructor Luis Fernando Castro

Size Data Effort Estimate

Object Plan Number Actual Number Est Effort per Object Estimated EffortTablas 2 2 1 2Graficas 17 19 1 17Parrafos 34 32 12 364

Total 283

Effort Data

Phase Plan Time Actual TimePlaneacion 20 19Desarollo 283 250

Postmortem 10 16Total 313 285

3.18.3. R5 Time Recording Log

Student: Daniel Chinas VegaDate: 28/01/07

Date Start Stop Interruption Time Delta Time Phase Comments27/01/07 15:23 15:45 3 19 1 Revision de la R427/01/07 16:05 10:43 28 250 2 Consultas a la guıa R427/01/07 11:00 11:16 16 3

54

3.18.4. Analisis de la precision de la estimacion de tamano

Figura 3.17:

La estimacion de tamano para cada programa a partir de la segunda etapa, durante el cambio del proceso(Tareas 7A-10A) se mantuvo dentro del 70 % de efectividad (30% en la grafica). Se nota una mejora clara con respectoa la primera parte del proceso, esto debido en gran parte a la madurez obtenida y el uso de una base de datos, que parala tarea 7A contaba ya con informacion suficientes para ayudarnos en la estimacion, de esta forma la mejora es notoriaconforme el avance en las tareas pues se reduce claramente elerror en la estimacion del tamano, cabe notar que a partirde la tarea tres y aun con la modificacion del proceso siemprehubo una sobre estimacion del tamano, una tendenciaclara en las tareas 3A-10A.La introduccion de dos fases nuevas al proceso Revision deDiseno y Codificacion a partir de la segunda etapa delproceso (7A-10A) mejoraron las estimaciones, principalmente la revision del diseno ayudo a una mejor estimacion deltamano, al introducir esta etapa de revision disminuimoslos errores en el diseno y mejoramos la estimacion de locs(Unidad de medida del tamano).

3.18.5. Analisis de estimacion de tiempo

Figura 3.18:

55

La estimacion de tiempo para cada Tarea resulto dentro del 70 % de efectividad (30 % en la grafica). No senoto una mejora tan marcada como en el caso de la estimacion del tamano, se nota a partir del cambio en el proceso(Tareas 7A-10A) una variacion en el porcentaje de error quecambia de sobre estimacion a subestimacion, aunquese mantiene en el rango de efectividad planteado no es consistente. La experiencia obtenida hasta el momento fueimportante para mantenernos dentro del rango esperado, sinembargo la falta de un mejor progreso se debe en granmedida al cambio de proceso, creo necesitarıa de un par de tareas extras para desenvolverme mejor en el proceso conrespecto a la estimacion de tiempo.

La introduccion de dos fases nuevas al proceso Revision deDiseno y Codificacion a partir de la segundaetapa del proceso (7A-10A) fueron un de factor importante que me permitieron mantenerme en un rango satisfactoriocon respecto al porcentaje de error, al poder corregir de manera temprana los posibles errores que hubieran consumidomas tiempo en etapas adelantadas del proceso.

3.18.6. Productividad

Figura 3.19:

La productividad se mantuvo por debajo de 60, en las primerastres tareas de la segunda parte del proceso(7A-9A) esto debido al cambio en el proceso, los cambios asıcomo la insercion de dos nuevas etapas al procesotuvieron un costo claro en mi productividad.En el analisis anterior me propuse mantener mi productividad en 60 lo cual se cumplio superando mis expectativas allograr un aumento considerable en la misma en la ultima tarea.

56

3.18.7. Analisis de tipos de defectos

Figura 3.20:

Es claro que la mayor cantidad en defectos son del tipo codigo, seguidos de los de funcion, esto nos muestracual importantes son las etapas de diseno y codificacion, ası mismo es ahı donde se insertan las dos nuevas etapasde revision, de ahı la importancia de elaborar disenos m´as claros y pseudocodigos mas especıficos, de tal forma quereduzcamos estos errores.

Number Injected Percentage InjectedType Design Code Design Code

10 0 0 0.00 % 0.00 %20 1 88 4.20 % 75.90 %30 0 0 0.00 % 0.00 %40 10 16 11.70% 13.80 %50 3 2 12.50% 1.70 %60 0 0 0.00 % 0.00 %70 8 2 33.30% 1.70 %80 2 8 8.30 % 6.90 %90 0 0 0.00 % 0.00 %

100 0 0 0.00 % 0.00 %Total 24 116

De la cantidad de defectos cometidos la gran mayorıa de estos son inyectados en la fase de codificacionsiendo una razon mas por la cual fue introducida una nueva fase de revision despues de la codificacion aunado aesto en vista de los resultados obtenidos es de suma importancia tener un mejor control de la etapa de codificacion,buscando reducir aun mas los errores cometidos.

57

3.18.8. Defectos removidos por fase

Figura 3.21:

la introduccion de dos nuevas etapas en el proceso PSP denotan una claro cambio en la cantidad de erroresremovido por etapa disminuyendo considerablemente los defectos removidos en compilacion y disminuyendolos enlas pruebas a sı mismo es claro que la experiencia adquiridaası como el uso de procesos que se vuelven mas metodicosconforme las tareas progresan y el proceso se define mas disminuyen significativamente los errores.

Figura 3.22:

Es clara la baja en el costo por fallos cabe notar que esto ocurre a partir de la tarea 7A esto debido en granmedida a la insercion de las dos nuevas etapas, las cuales son de revision, lo cual podrıa darnos una justificacionaceptable para la insercion de mas o mejorar las ya establecidas etapas de revision en pos de disminuir aun mas elcosto por fallas.

58

3.18.9. Rendimiento

Figura 3.23:

Es claro el aumento de locs revisadas por hora en ambas etapasnuevas, lo que denota la clara mejora obtenidaa partir de ellas y consecuentemente un mejor uso de ambas etapas para mejorar nuestro PSP.

Figura 3.24:

El rendimiento en la fase de revision de diseno se muestra ambiguo, no se denota ninguna relacion conrespecto a LOC/Hora, se necesitarıan de mas datos para poder tener una opinion relevante con respecto a esto.

59

Figura 3.25:

Es claro una tendencia a la disminucion en el rendimiento conforme aumentan las LOC a revisar por hora, laimportancia de la etapa de codificacion y como esta afecta nuestro rendimiento es clara, debemos concentrarnos masen esta etapa para poder mejorar el rendimiento.

Figura 3.26:

Al unir ambas etapas y confrontarlas con el rendimiento notamos una leve tendencia a la disminucion delrendimiento conforme el aumento de LOC/hora, esto denota la importancia de ambas etapas, la cantidad de locsafectara de manera directa nuestro rendimiento.

60

Capıtulo 4

Conclusiones al termino del proceso ( PSP )

4.0.10. Areas para mejorar

Diseno

Revision de diseno

Codificacion

Revision de codigo

Tiempo de revision promedio

Calidad

4.0.11. Medidas para mejorar

EtapasDiseno y Revision de diseno

La etapa de diseno afecta directamente las siguientes etapas del proceso debo trabajar en ella de tal formaque realice una mejor estimacion de LOC y Tiempo, la etapa derevision deberia hacerse mas minuciosa para reducirlos errores que pasan a las siguientes etapas.

Codificacion y revision de codigo

Puesto que la mayorıa de los errores encontrados son de tipocodigo es de suma importancia mejorar en estaetapa, prestando una mayor atencion la codificar reduciendo los errores que encontraremos en la etapa de revision y deesta forma mejorar nuestro rendimiento ası mismo la etapa de revision debe enriquecerse a un mas haciendo un mayoruso de los checklist para disminuir aun mas los errores que pasan a las siguientes etapas.

Tiempo de revision

Una posible mejora en nuestro proceso seria reducir los tiempos de revision, esto se ve afectado directamentepor las etapas de diseno y codificacion, en ellas debemos ser mas minuciosos de tal forma que reduzcamos los erroresprocedentes de las mismas, de esta forma reducirıamos los errores y mejorarıamos nuestros tiempos de revision, eneste punto creo solo la experiencia nos permitirıa mejorarası mismo no hay que dejar de lado tener mas cuidado alhacer las cosas y prestar mas atencion a lo que estamos realizando en pos de tener menos errores.

61

4.0.12. Calidad

La Calidad es algo que se debe lograr en la medida que mejoren los puntos antes senalados, de esta manerael desarrollo de mi trabajo mejorara. Una forma de medir estoes el uso del Yield y el A/FR al mejorarlos podremosdecir que aumento la calidad de nuestro proceso, podre senalar de manera confiable y basado en pruebas que tanto seha mejorado.La reduccion de errores inyectados en las diferentes etapas que constituyen el proceso, ası como una mejor estimaciondel LOC y tiempo son importantes metas a seguir si quiero mejorar, de esta manera aumentare la calidad y con loanterior mente expuesto, tendre una medida mas clara sobresi existe una mejora o no.

4.0.13. Revision de metas

Estas fueron las metas propuestas en R4.

Planeacion y disenoPlaneacion

Aumentar tiempo en esta area es decir poner mas atencion en los requerimientos que se me piden, para poder haceruna mejor planeacion.

Diseno

En este apartado, creo debo ser mas especifico en mis disenosy dejar menos cosas ambiguas, ası el tiempo de codifi-cacion sera menor y los errores introducidos disminuiran, lo que lleva a un menor tiempo en las fases de compilaciony pruebas, lo que mejorara mi desempeno.

Productividad

En base a lo anterior se espera aumentar mi productividad, actual mente para el programa es 57,49, por lo cual elproposito seria mantenerla cercana a 60 para ası mejorar la productividad a la fecha que es de 36,86, que esperarıafuera de 45 al terminar los proyectos de psp.

4.0.14. Tiempo

Figura 4.1:

En este punto es claro que el tamano de los programas realizados en cada tarea crecio rapidamente, al igualque el tiempo de desarrollo a partir de la tarea numero 9, por lo cual es justificado el hecho que el tiempo de desarrollopara las ultimas dos tareas aumentara significativamente.

62

Figura 4.2:

El porcentaje de tiempo ocupado para la planeacion de cada tarea disminuyo considerablemente, siendocontrario a las metas planteadas en r4 sin embargo es claro que el porcentaje de tiempo en la compilacion disminuyoconsiderablemente concuerda con lo que buscabamos obtener.

La meta se cumplio parcialmente aun necesito mejorar y tomar con mas importancia las etapas de planeacion.

4.0.15. Errores

Figura 4.3:

En terminos Generales esta meta se cumplio pues es clara una disminucion en los errores encontrados a lolargo del proceso. En un estudio mas a fondo observamos lo siguiente:

Defect Densities Compile and Test DefectsProgramNumber

New andChangedLOC

Total Defects Defects perKLOC

Defects foundin compile

Compiledefects perKLOC

Defects foundin test

Test defectsper KLOC

1 137 24 175 23 168 1 72 136 22 162 20 147 2 153 92 12 130 10 109 0 04 318 25 79 24 75 1 35 199 10 50 9 45 1 56 321 14 44 8 25 6 197 252 10 40 1 4 0 08 281 5 18 0 0 0 09 519 13 25 0 0 3 610 1134 5 4 0 0 2 2Totals 140 0 95 0 16 0

63

En esta cabe notar que la cantidad de errores por KLOC disminuyo considerablemente a lo largo de todoel proceso siendo de 4 KLOC al llegar a la tarea 10 con lo cual cumplı mi meta de reducir los errores, a si mismolos defectos encontrados en compilacion se reducen a 0 en laetapa de compilacion en las tres ultimas tareas, cabenotar que un punto alarmante son los errores encontrados en la etapa de pruebas (TEST) un apartado en el que deberıatrabajar mas, esto es mejorar mis disenos y elaborar aun mas mis pruebas de escritorio para encontrar los errores antesde pasar a la etapa de codificacion y de esta manera evitar errores en etapas futuras del proceso.

4.0.16. Productividad

Figura 4.4:

La productividad se mantuvo al alza llegando en la ultima tarea a una meta cercana a 90 LOC/Hora por locual puedo decir esta meta fue cumplida.

4.0.17. Metas

El proceso se mantendra igual, puesto que las metas alcanzadas hasta ahora son satisfactorias como ya seexplico anteriormente, puesto que quedaron detalles que faltaron mejorar se toman como metas a futuro las siguientes.

Planeacion y Diseno

Siendo las dos etapas mas importantes en el desarrollo de toda la tarea, estimo dedicar mas tiempo a desarrol-lar correctamente estas dos etapas, a fin de reducir el error en la estimacion de tamano y cantidad de loc por programaasi mismo reducir los errores provenientes del diseno.

Errores

Mantener la cantidad de errores en 4 k/loc

Productividad

Mantener una productividad superior a las 70 loc/hora siendo constantes.

64

Bibliograf ıa

[1] acobson, I. 1998. ”Applying UML in The Unified Process”Presentacion. Rational Software. Pre-sentacion disponible en http://www.rational.com/uml como UMLconf.zip

65

plantillas desarrollo de software

Documents

reporte de analisis

proceso psp

analisis de estimacion

proceso r5

proceso r4

reporte r5

reporte r4

reporte de mitad