Plantillas Desarrollo De Software

` UNIVERSIDAD AUTONOMA METROPOLITANA IZTAPALAPA ´ DE CIENCIAS BASICAS ´ DIVISION E INGENIER´IA

´ LICENCIATURA EN COMPUTACION REPORTE DE PROYECTO FINAL

Desarrollo del Proceso Persona de Software ˜ Vega Daniel Chinas

Asesor Eduardo Rodr´ıguez Flores

1

´ Indice general 1. Introducci´on 2. Desarrollo 2.1. PSP . . . . . . . . . . . . . . . . . 2.2. PSP 0 . . . . . . . . . . . . . . . . 2.2.1. Tarea 1 . . . . . . . . . . . 2.3. PSP 0.1 . . . . . . . . . . . . . . . 2.3.1. Tarea 2 . . . . . . . . . . . 2.3.2. Tarea 3 . . . . . . . . . . . 2.4. Reporte de an´alisis de defectos R3 . 2.5. PSP 1 . . . . . . . . . . . . . . . . 2.5.1. Tarea 4 . . . . . . . . . . . 2.6. PSP 1.1 . . . . . . . . . . . . . . . 2.6.1. Tarea 5 . . . . . . . . . . . 2.6.2. Tarea 6 . . . . . . . . . . . 2.7. Reporte de mitad de proceso R4 . . 2.8. PSP 2.0 . . . . . . . . . . . . . . . 2.8.1. Tarea 7 . . . . . . . . . . . 2.9. PSP 2.1 . . . . . . . . . . . . . . . 2.9.1. Tarea 8 . . . . . . . . . . . 2.9.2. Tarea 9 . . . . . . . . . . . 2.9.3. Tarea 10 . . . . . . . . . . . 2.10. R5: Reporte de An´alisis del Proceso

3 . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

4 4 6 6 6 7 7 7 7 7 8 8 8 11 12 12 14 14 14 15 19

3. Resultados 3.1. Formas, Plantillas y est´andares para su utilizaci´on en PSP 3.2. Bit´acora de Tiempo. . . . . . . . . . . . . . . . . . . . . 3.3. Registro de defectos. . . . . . . . . . . . . . . . . . . . 3.4. Est´andar de Conteo de LOCs de Java (R1) . . . . . . . . 3.5. Java Standard de codificaci´on (R2) . . . . . . . . . . . . 3.6. Estimaci´on de tama˜no . . . . . . . . . . . . . . . . . . . 3.7. Design Review Checklist. . . . . . . . . . . . . . . . . . 3.8. Code Review Checklist . . . . . . . . . . . . . . . . . . 3.9. Escenario operacional. . . . . . . . . . . . . . . . . . . 3.10. Especificaci´on funcional . . . . . . . . . . . . . . . . . 3.11. Especificaci´on de estados . . . . . . . . . . . . . . . . . 3.12. Especificaci´on l´ogica . . . . . . . . . . . . . . . . . . . 3.13. Propuesta de mejora de proceso (PIP) . . . . . . . . . . 3.14. Reporte de la mitad del Proceso (R4) . . . . . . . . . . . 3.15. R4 Report Plan Summary . . . . . . . . . . . . . . . . . 3.16. R4 Time Recording Log . . . . . . . . . . . . . . . . . 3.17. Reporte R4 . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

21 21 22 22 24 25 27 28 29 30 31 32 33 34 39 40 41 42

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

2

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

3.17.1. An´alisis de la Exactitud de Estimaci´on de Loc . . . . . . . . . . 3.17.2. An´alisis de la Exactitud de Estimaci´on de Tiempo . . . . . . . . 3.17.3. An´alisis de los defectos introd. Y eliminados por fase (R3). . . . 3.17.4. An´alisis de defectos encontrados por el compilador (tabla D24) ´ 3.17.5. Areas de prioridad para mejora en la 2da. Mitad del curso . . . 3.18. Reporte R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18.1. Reporte de final de proceso (R5) . . . . . . . . . . . . . . . . . 3.18.2. R5 Report Plan Summary . . . . . . . . . . . . . . . . . . . . 3.18.3. R5 Time Recording Log . . . . . . . . . . . . . . . . . . . . . 3.18.4. An´alisis de la precisi´on de la estimaci´on de tama˜no . . . . . . . 3.18.5. An´alisis de estimaci´on de tiempo . . . . . . . . . . . . . . . . 3.18.6. Productividad . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18.7. An´alisis de tipos de defectos . . . . . . . . . . . . . . . . . . . 3.18.8. Defectos removidos por fase . . . . . . . . . . . . . . . . . . . 3.18.9. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Conclusiones al termino del proceso ( PSP ) ´ 4.0.10. Areas para mejorar . . . . . . . 4.0.11. Medidas para mejorar . . . . . 4.0.12. Calidad . . . . . . . . . . . . . 4.0.13. Revisi´on de metas . . . . . . . 4.0.14. Tiempo . . . . . . . . . . . . . 4.0.15. Errores . . . . . . . . . . . . . 4.0.16. Productividad . . . . . . . . . . 4.0.17. Metas . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

42 44 49 50 50 52 52 53 53 54 54 55 56 57 58

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

60 60 60 61 61 61 62 63 63

Cap´ıtulo 1

Introducci´on Software. Es el conjunto de los programas de c´omputo, procedimientos, reglas, documentaci´on y datos asociados que forman parte de las operaciones de un sistema de computaci´on.[IEEE] Tomando como punto de partida esta definici´on, el software es la suma de diferentes componentes y por tanto para hablar de calidad de software se deben tomar en cuenta cada uno de ellos, cabe recordar que para controlar la calidad es necesario, definir par´ametros, indicadores o criterios de medici´on tom´andose el resultado de evaluaci´on m´as bajo obtenido en cualquiera de los componentes del software para indicar la calidad de este, de ahi la importancia en su desarrollo. Por ello debemos contar con m´etodos y procesos que nos permitan mantener una adecuada calidad en la totalidad del software.

Ingenier´ıa al software. La aplicaci´on de un enfoque sistem´atico, disciplinado y cuantificable al desarrollo operaci´on (funcionamiento) y mantenimiento del software. [IEEE, 1993] Bajo este contexto la ingenier´ıa de software es una disciplina cuyo fin es la creaci´on de software de la m´as alta calidad. Haciendo uso de procesos cuantificables y repetibles.

Proceso de ingenier´ıa de software Un conjunto de etapas parcialmente ordenadas con la intenci´on de logra un objetivo, en este caso, la obtenci´on de un producto de software de calidad [Jacobson 1998]. En vista de los conceptos antes mencionados es importante el contar con un proceso adecuado que nos lleve a la realizaci´on de un software de alta calidad.

PSP Proceso Personal de Software (PSP, por sus siglas en ingl´es PERSONAL SOFTWARE PROCESS). PSP es un proceso de auto mejoramiento de la calidad de software, nos proporciona una estructura con gu´ıas y procedimientos para el desarrollo de un proceso, que tenga como finalidad la creaci´on de software de calidad. Como ya hab´ıamos mencionado la calidad del software es el resultado de evaluaci´on de calidad m´as bajo de cualquiera de los componentes de este y la calidad de cada uno de ellos esta dada por la persona que lo desarrollo de ah´ı la importancia de contar con un proceso personal que nos permita 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 Est´andares

El PSP es una l´ınea de trabajo de medici´on y an´alisis para ayudar a caracterizar un proceso. Tambi´en es un procedimiento definido que le ayuda a mejorar el desempe˜no. 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 an´alisis 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 c´omo mejorar el proceso personal. Los datos para mejorar continuamente la productividad, calidad y la predicci´on del trabajo

Un PSP estable y maduro permite: Estimar y planear el trabajo. Cumplir con los compromisos. Resistir presiones por compromisos no razonables.

5

Tambi´en: Se comprender´an las habilidades actuales para desarrollar software. Se estar´a 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 medici´on de nuestro desempe˜no. PSP1: Planificaci´on del tama˜no, uso de recursos y tiempo de desarrollo. PSP2: Administraci´on 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 de nuestro Proceso personal de software. 6

2.2. PSP 0 Objetivos Demostrar el uso de un proceso definido al escribir un programa peque˜no. Incorporar medidas b´asicas en el proceso de desarrollo de software.

PSP 0 es simple y definido, usando los m´etodos con los que actualmente dise˜namos y desarrollamos nuestro software. Se recolectan datos sobre el trabajo realizado, tiempo utilizado por fase y defectos encontrados en la compilaci´on y pruebas. Se hace uso de una bit´acora para el registro de los tiempos y de una bit´acora para el reporte de los defectos, se usa un est´andar de defectos para llevar un control de los mismos.

2.2.1. Tarea 1 Creaci´on de un programa que calcule la media y la desviaci´on est´andar de una serie de n n´umeros reales, usando una lista ligada para almacenar los n n´umeros a usar en los c´alculos.

2.3. PSP 0.1 Objetivos Medir el tama˜no de los programas que produzca. Contabilizar los tipos de LOCs en los programas que produzca. Realizar mediciones de tama˜no exactas y precisas.

Hay dos nuevos elementos del proceso. La forma de propuesta de mejora de proceso (PIP). Est´andares de conteo ( R1 )y codificaci´on ( R2 ).

Para mejorar el proceso, es necesario registrar los problemas y propuestas de mejora para una referencia futura. El PIP contiene informaci´on de mejora del proceso N´umero de PIP. Descripci´on del problema. Soluci´on propuesta. Notas y comentarios.

Los est´andares de codificaci´on y conteo son necesarios para escribir los programas PSP, deben ser ajustados al lenguaje que usemos para codificar. De forma que el conteo de LOC sea m´as f´acil. LOC son elementos de lenguaje m´ınimos para llevar a cabo una operaci´on completa (l´ogico) o elementos f´ısicos como podr´ıan ser palabras, para el dise˜no de mi est´andar de conteo eleg´ı el tipo l´ogico. 7

2.3.1. Tarea 2 Creaci´on de un programa que cuente el total de LOC l´ogicas en un programa omitiendo comentarios y l´ıneas en blanco. Haciendo uso de nuestro est´andar de conteo. Lo Probaremos contando las LOC de los programas 1A y 2A.

2.3.2. Tarea 3 Creaci´on de un programa que cuente las LOC l´ogicas totales de un programa, las LOC l´ogicas en cada objeto o funci´on y el n´umero total de m´etodos de cada objeto, tendr´a como salida el conteo de LOC totales, el conteo separado de LOC y el de m´etodos.

2.4. Reporte de an´alisis 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 compilaci´on y pruebas. Tiempo promedio de correcci´on de defectos por fase de introducci´on y eliminaci´on. 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 ordenado y repetible para el desarrollo de estimados para el tama˜no del software.

2.5.1. Tarea 4 Creaci´on de un programa para calcular los par´ametros de regresi´on 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 f´ormula del par´ametro de regresi´on b0 es

b0 = yavg - b1xavg

8

La f´ormula del par´ametro de regresi´on b1 es

Figura 2.3:

2.6. PSP 1.1 Objetivos Los objetivos del PSP 1.1 son introducir y practicar m´etodos para: Hacer planes de recursos y de calendario de trabajo. Seguir el desempe˜no contra estos planes. Juzgar la probabilidad de las fechas de terminaci´on del proyecto.

2.6.1. Tarea 5 Creaci´on de un programa para resolver una integral de una funci´on num´ericamente, usando la regla de simpson para una funci´on de distribuci´on normal, deber´a ser dise˜nado para integrar usando varias funciones proporcionadas.

La regla de Simpson.

Figura 2.4:

2.6.2. Tarea 6 Creaci´on de un programa para calcular el estimado de LOCs nuevas y modificadas as´ı como los intervalos de predicci´on de 70 % y 90 %, dado un conjunto de datos hist´oricos y un estimado de LOCs. Se hara uso de la rutina de integraci´on de la regla de simpson dise˜nada en la tarea 5 para calcular el valor de la distribuci´on t. Se usara una lista ligada para almacenar los datos hist´oricos.

9

Para calcular el intervalo de predicci´on, utilizar los siguientes pasos. 1. Leer los datos hist´oricos, x’s y y’s. 2. Calcular B0 y B1. 3. Leer el estimado, xk. 4. Calcular a proyecci´on 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 f´ormula para calcular el rango de predicci´on es

Figura 2.5: Donde: x son los datos hist´oricos de tama˜no de objeto. n es el n´umero de puntos de los datos hist´oricos. t70(2/α, dof ) es la distribuci´on t de dos colas de 70 % para n - 2 grados de libertad (dof).

Sigma es la desviaci´on est´andar de la regresi´on lineal de los datos.

Figura 2.6:

10

Donde x son los datos hist´oricos de tama˜no de objetos. y son los LOC nuevas y modificadas hist´oricas (para tama˜no) o tiempo (para esfuerzo). n es el n´umero de puntos de datos hist´oricos.

Para calcular el valor de t(, 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 integraci´on es demasiado bajo, escoger un l´ımite superior de prueba m´as grande. • Si el resultado de la integraci´on es demasiado alto, escoger un l´ımite superior m´as peque˜no.

Hacer integraciones de prueba sucesivas hasta que el valor de la integraci´on est´e 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 c´alculo 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 valor apropiado 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 est´a dentro del error 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 m´etodo para ajustar d podr´ıa resultar en un valor de prueba de t = 0. Para protegerse contra este problema con el m´etodo de Simpson, se debe asegurar que el programa manejar´a un valor 0 de la funci´on que est´a siendo integrada. 11

2.7. Reporte de mitad de proceso R4 Objetivos Los objetivos d este reporte son: Comprender los principios de la medici´on y an´alisis de procesos. Ganar experiencia en la definici´on de un proceso para su uso propio. Aprender a analizar los datos del proceso. Comprender el proceso de referencia y c´omo ha cambiado durante el curso. Establecer metas medibles y definir las acciones de mejora correspondientes.

Para este reporte se debe dise˜nar: Un proceso para analizar los datos del PSP y para producir un reporte. Se debe incluir en este proceso las fases de planeaci´on 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 an´alisis para la exactitud de la estimaci´on de tama˜no y c´omo ha evolucionado durante los programas desarrollados a la fecha. Un an´alisis para la exactitud de la estimaci´on de tiempo y c´omo ha evolucionado durante los programas desarrollados a la fecha. Un an´alisis de los tipos de defectos introducidos y eliminados para los programas desarrollados a la fecha (tabla D23, p´agina 773). Un an´alisis de los defectos encontrados por el compilador (tabla D24, p´agina 773). Un an´alisis de los tiempo de correcci´on de defectos, R3. Una descripci´on de las a´ reas de m´as alta prioridad para la mejora personal, con su justificaci´on.

lo que se espera: Identificar las oportunidades de mayor influencia para mejorar el desempe˜no personal. Establecer metas cuantitativas y medibles. Describir las acciones espec´ıficas (e.g. cambios al proceso) que se tomar´an para lograr estas metas.

12

C´omo m´ınimo, se deber´an tomar los siguientes pasos para establecer los objetivos. Examinar los datos PSP para comprender el desempe˜no actual. Identificar las mejoras potenciales. Priorizar las a´ reas de mejora basandose en el peso potencial. Conducir un an´alisis para identificar las causas del desempe˜no actual y establecer niveles de desempe˜no futuro. Identificar las acciones espec´ıficas necesarias para lograr estos niveles de desempe˜no.

2.8. PSP 2.0 Listas de revisi´on de c´odigo y dise˜no. M´etodos para evaluar y probar lo acertado de nuestras revisiones. Se agregan al proceso: Lista de chequeo de dise˜no. Lista de chequeo de codificaci´on.

2.8.1. Tarea 7 Creaci´on de un programa para calcular la correlaci´on entre dos series de n´umero y calcular la significancia de esa correlaci´on. Se hara uso de la rutina de integraci´on de la tarea 5 para calcular los valores de la distribuci´on t, se almacenaran los datos en una lista ligada. La correlaci´on rxy puede ir de +1 to -1. Cerca de +1 implica una fuerte relaci´on positiva; cuando x se incrementa y se incrementa. Cerca de -1 implica una fuerte relaci´on negativa; cuando x se incrementa y se decrementa. Cerca de 0 implica que no tienen relaci´on.

La correlaci´on es utilizada en el PSP para juzgar la calidad de la relaci´on lineal en varios datos hist´oricos del proceso que son utilizados para la planeaci´on. Para este prop´osito, usamos el valor de la relaci´on rxy al cuadrado, o r 2.

Si r2 es 0,9 ≤ r2 0,7 ≤ r2 ¡ 0,5 ≤ r2 ¡ r2 < 0,5

La relaci´on es Predictiva; u´ sela con gran confianza. Fuerte y puede ser usada para planeaci´on. Adecuada para planeaci´on, pero con cuidado No es confiable para prop´ositos de planeaci´on

13

Limitaciones de la Correlaci´on La correlaci´on no implica causa y efecto. Una fuerte correlaci´on puede ser coincidental. La f´ormula para calcular el coeficiente de correlaci´on r es:

Figura 2.7:

Donde x y y son dos conjuntos de datos por parejas. n es el n´umero de sus miembros.

La prueba de significancia determina la probabilidad que una correlaci´on fuerte sea por casualidad y por lo tanto no tenga significancia pr´actica. Hay que recordar que una correlaci´on fuerte puede ser s´olo por coincidencia, especialmente cuando los datos son escasos. Por ejemplo, un conjunto de datos con s´olo dos puntos siempre tendr´a r 2 = 1, pero esta correlaci´on no es significativa. El c´alculo de la significancia consiste de tres pasos: 1. Calcular el valor de t.

Figura 2.8: Donde: r(x,y) es la correlaci´on. n es el n´umero de puntos. 2. Encontrar la probabilidad p integrando n´umericamente la distribuci´on t para n -2 grados de libertad, de -Y a t. 3. Calcular la cola de la distribuci´on, 2*(1-p). Una a´ rea en la cola £ 0.05 se considera una evidencia fuerte que existe relaci´on. Una a´ rea en la cola3 0.2 se considera que la relaci´on es debida a la coincidencia.

14

2.9. PSP 2.1 Los objetivos del PSP2.1 son introducir: Medidas adicionales para la administraci´on de la calidad del proceso. Plantillas de dise˜no que proporcionan una l´ınea de trabajo ordenada y formatos para registrar dise˜nos.

2.9.1. Tarea 8 Creaci´on de un programa para ordenar una lista ligada de n pares de n´umeros reales en orden descendente.

2.9.2. Tarea 9 Creaci´on de un programa que calcule el grado con el cual una cadena de n n´umeros reales est´a distribuido de manera normal. Se usara la rutina de integraci´on de la tarea 5 para calcular la distribuci´on de c2. Supondremos una n ¿20 y un m´ultiplo par de 5 ( se puede suponer n = 50 ), se usara la rutina de ordenamiento de la tarea 8 para ordenar de manera ascendente los n´umeros. La prueba c2 para normalidad determina la probabilidad que un conjunto de datos siga una distribuci´on normal. Esto es realizado al comparar la estructura del conjunto de datos con la estructura de una distribuci´on normal ideal. Esto es realizado al dividir la distribuci´on normal en segmentos de a´ rea id´enticos y comparar el n´umero real de puntos del conjunto de datos que est´a siendo probado en cada segmento con el n´umero de la distribuci´on 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 desviaci´on est´andar, usando n-1.

Figura 2.9: Entonces, transformar cada xi a una zi normalizada.

Figura 2.10: 3. Dividir la distribuci´on normal en algunos segmentos S, donde

15

n/S 3 5 S>3 S23 n Para este problema, S=10 satisface estos requerimientos. 4. Determinar cu´antos elementos de la distribuci´on normal caer´ıan en cada segmento, Ni. Normalmente, esto es n/S; en este caso es 5. 5. Determinar cu´antos 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 distribuci´on c2 para S-1 grados de libertad (dof) al integrar de 0 a Q.

Figura 2.12: Nota: La ecuaci´on anterior para c2 difiere de la ecuaci´on A7, p´agina 518, por: Sustituir dof por n. Sustituir Q por x. 8. Calcular la cola de la distribuci´on 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 Creaci´on de un programa para calcular los par´ametros de estimaci´on de regresi´on m´ultiple de tres variables (β0, β1, β2, andβ3).

Hacer un estimado de las entregas proporcionadas por el usuario y determinar los intervalos de predicci´on del 70 % y 90 % para el estimado.

Se hara uso de una lista ligada para almacenar los datos y de la rutina de integraci´on de la tarea 5 para calcular la distribuci´on t. 16

La regresi´on m´ultiple proporciona una forma de estimar los efectos de m´ultiples variables cuando no se tienen datos separados para cada una de ellas. Los 13 pasos se describen a continuaci´on. 1. Utilizar la siguiente f´ormula de regresi´on m´ultiple para calcular el valor estimado.

Figura 2.13: 2. Encontrar los par´ametros Beta resolviendo las siguientes ecuaciones lineales simult´aneas.

Figura 2.14: 3. Cuando se calculen los valores de los t´erminos, se obtendran las siguientes ecuaciones lineales simult´aneas.

Figura 2.15:

17

4. Diagonalizar, utilizando el m´etodo de Gauss. Esto elimina de manera sucesiva un par´ametro a un tiempo de las ecuaciones mediante la multiplicaci´on y resta sucesiva para dar lo siguiente.

Figura 2.16: 5. Resolver para los t´erminos Beta.

Figura 2.17: 6. Determinar el intervalo de predicci´on resolviendo para el rango con la siguiente ecuaci´on.

Figura 2.18: 7. Calcular la varianza como sigue.

Figura 2.19:

18

8. La varianza se eval´ua con lo siguiente.

Figura 2.20: 9. Los t´erminos en la ra´ız cuadrada son los siguientes.

Figura 2.21: 10. El valor de la distribuci´on t para un intervalo de predicci´on del 70 % es encontrado bajo la columna 85 % y dos ´ es 1.386. grados de libertad en la tabla A2, p´agina 489. El 11. La ra´ız cuadrada se eval´ua de la siguiente manera.

Figura 2.22: 12. El estimado final es: z = 6.71+0.0784*650+0.0150*3,000+0.2461*155 z = 140.902 horas 13. El intervalo de predicci´on de 38.846 horas significa que el estimado est´a entre 102.1 y 179.7 horas. Para resolver un sistema de N inc´ognitas. La eliminaci´on Gaussiana es un algoritmo com´un 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 n´umero m´as grande en la columna por debajo de la posici´on I,I.) 3. IF P = 0 THEN SALIR (Si el resto de esta columna es cero, no existe una soluci´on u´ nica.) 4. IF K > I THEN FOR J = I TO N + 1 INTERCAMBIA A(I,J) Y A(K,J) (Tome el valor del pivote en la posici´on I,I.) 5. FOR J = I + 1 TO N + 1 ASIGNA AI , J = AI , J / AI , I (Coloca un 1 en la posici´on I,I.) ASIGNA AI , I = 1. 6. FOR L = I + 1 to N multiplicar rengl´on I por -AL , I y sumar a rengl´on L (se colocan ceros a la columna por debajo de la posici´on I,I.) 7. I = I + 1. IF I < N THEN IR AL PASO 2. 8. SALIR a sustituci´on hacia atr´as (¡Dise˜no su propio algoritmo!) 19

2.10. R5: Reporte de An´alisis del Proceso Objetivos Producir un reporte sobre lo que se aprendi´o en este curso que nos ayude a comprender nuestro desempe˜no actual en el desarrollo de software y donde debemos mejorar. Ganar experiencia en el establecimiento de metas medibles y en la detecci´on de las acciones de mejora correspondientes. Aprender a actualizar nuestro proceso personal. Se actualizar´a 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 deber´a hacer lo siguiente. Analizar la exactitud en el estimado de tama˜no y determinar el grado con el cual lo estimado estuvo dentro de los intervalos estad´ısticos de predicci´on del 70 % y 90 %. Muestrar c´omo la exactitud en la estimaci´on del tama˜no ha evolucionado durante las tareas. Analizar la exactitud en el estimado de tama˜no y determinar el grado con el cual lo estimado estuvo dentro de los intervalos estad´ısticos de predicci´on del 70 % y 90 %. Muestrar c´omo la exactitud en la estimaci´on del tiempo ha evolucionado durante las tareas. Analizar los tipos de defectos que se introducen en dise˜no y codificaci´on. Incluir un an´alisis Pareto de estos tipos de defectos. (Ver el Ap´endice A12 para una descripci´on del procedimiento del an´alisis de Pareto.) Analizar las tendencias para defectos por KLOC encontrados en revisiones de dise˜no, revisiones de c´odigo, compilaci´on y pruebas. Analizar las tendencias para los defectos totales por KLOC. Analizar las tasas de eliminaci´on de defectos para las revisiones de dise˜no, revisiones de c´odigo, compilaci´on versus pruebas unitarias. En aquellos casos donde no se tengan defectos, utilizar la tasa promedio de eliminaci´on de defectos de las pruebas unitarias Analizar el rendimiento (yield) versus LOC revisadas por hora en las revisiones de c´odigo. Analizar el rendimiento de la revisi´on de dise˜no versus las LOC revisadas por hora. Analizar el rendimiento versus el A/FR de los programas 7 al 10 Describir las a´ reas de m´as alta prioridad para la mejora del proceso personal y justificarlas. Aseg´urando resumir el desempe˜no actual, desempe˜no futuro y metas de mejora. Describir c´omo se intentan cumplir esas metas.

El dise˜no de proceso debe incluir una: Fase de planeaci´on. Fase de desarrollo. Fase de postmortem. 20

El reporte debe incluir: Todas las tablas y gr´aficas requeridas, mas cualquier otra gr´afica o datos que apoyen el an´alisis. An´alisis 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 est´andares para su utilizaci´on en PSP Tabla de referencia

Figura 3.1: Tabla de referencia

22

3.2. Bit´acora de Tiempo. En ella registraremos cada una de las actividades que llevemos a cabo durante el lapso de tiempo que dediquemos a la realizaci´on del proceso (Tareas).

Figura 3.2: Ejemplo de la Bit´acora de Tiempo (Tarea 6)

3.3. Registro de defectos. En esta se plasman la informaci´on de defectos (errores) cometidos en la realizaci´on de las tareas, la informaci´on debe ser lo mas completa posible, el registro esta conformado por el numero de tarea donde se cometi´o, la fecha, el numero continuo, el tipo de error, tiempo de correcci´on y una breve descripci´on 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. Est´andar de Conteo de LOCs de Java (R1) Nombre de la definici´on: Autor:

Est´andar de LOCs de Java Daniel Chi˜nas vega

Tipo de Conteo F´ısico / L´ogico Tipo de Instrucci´on

Tipo L´ogico Incluido

Ejecutable No ejecutable Declaraciones Directivas del compilador Comentarios En l´ıneas propias Con el fuente Encabezados L´ıneas en blanco Aclaraciones Nulos Instrucciones vac´ıas Intanciadores gen´ericos Begin...end Begin...end Prueba de condiciones Evaluaci´on de expresiones

Si

Si Nota 1 Nota 1 Si Si Notas 1 y 2 Notas 1 y 2 Nota 1 Si

Etiquetas

Si

Nota 2 Nota 3 Nota 4

Java 07/10/06

Comentarios Comentarios

Si, Nota 3 Si, Nota 4 No No No No No

S´ımbolos End S´ımbolos End else Palabras clave

Nota 1

Lenguaje: Fecha:

Ejemplos / Casos continues, no-ops ”;;”, ;’s solos, etc. cuando est´en en c´odigo ejecutable cuando est´en en c´odigo no ejecutable Cuando se utilice como argumentos de subprogramas Cuando terminen instrucciones ejecutables Cuando terminen declaraciones o cuerpos Divisi´on de procedimientos, interfaz, implementaci´on Destinos de saltos cuando est´en en l´ıneas separadas 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. Cuente una vez cada ocurrencia de: ;, ”{” . . . ”}” Cuente una vez cada declaraci´on de variable o de par´ametro. Cuente una vez cada instrucci´on package e import.

25

3.5. Java Standard de codificaci´on (R2) Prop´osito: Encabezado Formato de encabezado

Contenido del listado fuente Ejemplo de contenido

Instrucciones de reutilizaci´on

Ejemplo de instrucciones de reutilizaci´on

Identificadores

Ejemplo de identificadores

Una gu´ıa para el desarrollo de programas en java Comenzar todos los programas con un encabezado descriptivo. /*************************************************************/ /* Asignaci´on de programa: numero de programa */ /* Nombre: nombre del Desarrollador */ /* Fecha: Fecha de inicio del desarrollo del programa */ /* Descripci´on: una peque˜na descripci´on del programa */ /* y su funci´on */ /*************************************************************/ Proporcionar un resumen del contenido del listado fuente. /*************************************************************/ /* Contenido del listado fuente: */ /* Instrucciones para su reutilizaci´on */ /* Instrucciones para su modificaci´on */ /* Instrucciones para su compilaci´on */ /* Package */ /* Imports */ /* Nombre de la clase CData */ /* Declaraci´on de Variables */ /* Instancias de clases */ /* Funciones y m´etodos */ /*************************************************************/ -Describe c´omo se utiliza el programa. Proporciona el formato de declaraci´on, los valores y los tipos de par´ametro. - Proporcionar las advertencias para conocer los valores ilegales, las condiciones de desbordamiento, o de otras condiciones que podr´ıan potencialmente dar lugar a la operaci´on incorrecta de la clase. /*************************************************************/ /* Instrucciones de reutilizaci´on */ /* int PrintLine(char *cadena de caracteres) */ */ /* Prop´osito: para imprimir la secuencia, ”line of character”, /* en una l´ınea de impresi´on a pantalla */ /* Limitaciones: El tama˜no m´aximo de l´ınea es */ */ /* LONGITUD DE LINEA /* Devuelve : 0 si la l´ınea no se puede imprimir, caso contrario 1 */ /*************************************************************/ Utilizar nombres que describan correctamente todas las variables, funciones, constantes y otros identificadores. Evite el uso de abreviaturas o nombres de una sola letra. int numero de estudiantes; /* Bien */ float X, j, fCad; /* Mal */

26

Java Standard de codificaci´on (Continuaci´on) Comentarios

Buen comentario Mal comentario Secciones importantes Ejemplo

Espacios blanco

en

Tabuladores

Ejemplo de tabulaci´on

May´usculas

Ejemplo may´usculas M´etodos Ejemplo de m´etodos

- Documente el c´odigo de modo que el lector pueda entender su funcionamiento. - Los comentarios deben explicar el prop´osito y el comportamiento del c´odigo. - Comente la declaraci´on de variables para indicar su prop´osito. if(contador registro ¿limite) /* se han procesado todos los registros? */ if(contador registro ¿limite) /* revisa si contador registro es mayor que limite */ Las partes importantes del programa deben estar precedidas por un comentario de esa secci´on, este comentario debe describir el funcionamiento de esa parte el programa. /*************************************************************/ /* Esta secci´on del programa examinar´a el contenido del arreglo ”califica” */ /* y calcular´a el valor medio para la clase. */ /*************************************************************/ - Escribe el programa con suficiente espaciamiento de modo que no parezca que hay poco espacio. - Separara cada parte del programa con al menos un espacio. - Indica claramente cada nivel del programa. - El inicio y fin deben encontrarse alineados correctamente as´ı como las l´ıneas de cada nivel. while (distancia ¿limite) { accion = muebe mano (lugar apuntado); if (codigo accion = fallo movimiento) { printf(”El movimiento de la mano fallo.\n”); } } - Estar´an en May´usculas todas las constantes. - Deben ir en min´usculas todos los dem´as identificadores y palabras reservadas. - Los mensajes que lee el usuario (Salidas del programa) pueden ir en may´usculas / min´usculas, para hacer una mejor presentaci´on para el usuario. #define DEFAULT-NUMBER-OF-STUDENTS 15 int class-size = DEFAULT-NUMBER-OF-STUDENTS; Todo m´etodo debe tener claramente indicado su tipo, esto es: Private, Protected y Public void metodo() //mala definici´on Public metodo() //buena definici´on de un m´etodo

27

˜ 3.6. Estimaci´on de tamano Para la estimaci´on de tama˜no se usa una plantilla, la cual es suministrada por: Carnegie Mellon University

Figura 3.5: Ejemplo de plantilla de estimaci´on de tama˜no (tarea 6)

28

3.7. Design Review Checklist. El checklist nos proporciona un m´etodo controlado y repetible para mantener un control de calidad en nuestros dise˜nos, es la principal herramienta para mejorar la calidad de nuestros proyectos. Este chequeo debe llevarse a cabo antes de dar por finalizada la etapa correspondiente.

PROGRAM NAME AND NUMBER Purpose General

Completo

L´ogica

Casos ciales

Espe-

Uso cional

Fun-

Nombres

Est´andares

˜ efectiva Guiarnos en la conducci´on de una revisi´on de diseno - Al terminar cada paso de la revisi´on, se˜nalar en la derecha. - Terminar la lista de comprobaci´on para cada apartado del programa antes de iniciar la siguiente. Asegurar que el dise˜no cubre completamente los requerimientos, especificaciones y dise˜no de alto nivel: - Se generan todas las salidas especificadas. - Se incluyen todas las entradas necesarias. Comprobar que la secuencia del programa es la apropiada: * Las pilas, listas y otros est´an en el orden apropiado. * La recursi´on regresa de manera apropiada. - Verificar que todos los ciclos se inicializan, incrementan y terminan de manera apropiada Comprobar todos los casos especiales: - Asegurar la operaci´on apropiada de todas las variables definidas. - Especificar el valor de inicio de cada variable. - Protecci´on por condiciones fuera de los l´ımites, sobreflujo o bajoflujo. - Aseg´urar que las condiciones ”imposibles” sean absolutamente imposibles. - Manejar todas las condiciones de entradas incorrectas - Verificar que todas las funciones, procedimientos u objetos est´an completamente comprendidos y se usan de manera apropiada. - Verificar que todas las funciones, regresen lo esperado Verificar lo siguiente: - Todos los nombres y tipos especiales est´an clara y espec´ıficamente definidos. - Los alcances de todas las variables y par´ametros son evidentes o est´an definidos. - Todos los nombres de los objetos se usan dentro de sus alcances declarados. - Revisar que el dise˜no cumpla con todos los est´andares de dise˜no que sean aplicables.

29

Program Unit Name

3.8. Code Review Checklist PROGRAM NAME AND NUMBER Prop´osito General

Completo Import’s Inicializaci´on

Llamadas Nombres

Formato Salida

de

Parejas {} Operadores L´ogicos Revisi´on L´ınea-porl´ınea Est´andares Cierre y Apertura de Archivos

Guiarnos en la conducci´on de una revisi´on de c´odigo efectiva - Conforme se termine cada paso de revisi´on, compruebar el elemento en la caja de la derecha. - Terminar la lista de comprobaci´on para cada apartado del programa antes de iniciar la siguiente. - Verificar que el c´odigo cubre el dise˜no. - Verificar que los imports est´an completos. Comprobar la inicializaci´on de variables y par´ametros: - Al inicio de la Clase. - Al inicio de cada ciclo. - En el inicio de cada funciones/procedimientos Comprobar los formatos de llamada a m´etodos: - Par´ametros Comprobar el uso y escritura de nombres: - ¿Es consistente? Los nombres de variables son consistente. Las palabras reservadas est´an correctamente escritas. - ¿Est´a dentro del alcance declarado? Comprobar el formato de salida: - ¿El espaciamiento de l´ıneas es el apropiado? - ¿El espaciamiento es el apropiado? - Aseg´urarse de que las {} son los apropiados y se corresponden. - Aseg´urarse de que los ( ) son los apropiados y se corresponden - Verificar el uso apropiado de ==, =, ——, != y dem´as. Comprobar cada LOC por - Toda instrucci´on termina en ;. - Sintaxis de la instrucci´on. - Que la puntuaci´on sea la apropiada. Aseg´urar que el c´odigo se apega a los est´andares de codificaci´on. Verificar que todos los archivos est´an: - declarados de manera apropiada, - abiertos, y - cerrados.

30

Program Unit Name

3.9. Escenario operacional. Describe los escenarios de prueba de acuerdo a los requerimientos dados por el usuario de tal forma que se especifican todas las interacciones entre el sistema y el usuario.

Figura 3.6: Ejemplo de un escenario de operaci´on (Tarea 8)

31

3.10. Especificaci´on funcional Define los servicios funcionales proporcionados por los objetos

Figura 3.7: Ejemplo de la especificaci´on funcional de un objeto ( Tarea 9)

32

3.11. Especificaci´on de estados Especifica los estados de cada objeto y la interacci´on entre los mismos. Table C70 State Specification Template

Student Program Instructor Object

Chi˜nas Vega Daniel Tarea 8 Castro Careaga Luis Fernando Lista ligada

State #1 Inicia

Date Program # Language Routine

8A Java Ordenamiento

Descripci´on Checa numero de elementos en la lista Transition Conditions Empty Lista ligada.size = 1 Lista ligada.size >1

Attributes Lista ligada

State #2 Vacio

Descripci´on Lista sin elementos Transition Conditions Regresa null

Attributes Empty

State #3 Unico

Descripci´on Lista con un elemento

Attributes Lista ligada.size =1

Vacio Unico VariosElementos

Termina

Transition Conditions Return lista ligada

State #4 VariosElementos

Descripci´on Lista con m´as de un elemento

Termina

State #5 Ordena

Termina

Attributes Lista ligada.size >1

Transition Conditions Lista ordenada <setOrdenamientoInsercionDirecta ( lista ligada) Descripci´on Ordena la lista de manera ascendente Transition Conditions Return lista ordenada

33

Attributes Lista ordenada, tama˜no, componente

3.12. Especificaci´on l´ogica Especifica la funcionalidad de cada objeto (Pseudo c´odigo).

Logic reference numbers

Program logic, in pseudocode Lista OrdenaLista(Lista lista ligada, int componente) { Lista lista resultado = null; si(lista ligada.esvacia) { lista resultado = null; } otro caso { int tama˜no; tama˜no = NumElementos(lista ligada); si(tama˜no==1) { lista resultado = lista ligada; } otro caso { si(tama˜no>1) { lista ordenada = lista ligada; oredena(lista ordenada,tama˜no,componente); lista resultado = traelista; } } } retorna lista resultado; }

34

3.13. Propuesta de mejora de proceso (PIP) La forma PIP es un est´andar previamente dise˜nado para presentar propuestas de mejora al proceso PSP. Dicha propuesta de mejora nace conforme obtengamos m´as experiencia y confianza al usar el PSP.

PIP ( tarea 2 a la 10 )

Student Instructor Process

PIP Number 1

2

08/10/06 2A

Proposal Description 1 2

2

Date Program #

Problem Description: Consumo de tiempo en la lectura para la posterior aplicaci´on de el gui´on de trabajo de psp Constantes pausas en la realizaci´on de la fase postmorten, por falta o dudas sobre la realizaci´on de ella (espec´ıficamente la tabla de locs). La estimaci´on de l´ıneas de c´odigo ( L´ogicas ) resulto demasiado alejada de lo real

1 2

Propoal PIP Number 1

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP0.1 Elements

El uso de problemas ejemplo para tener una mayor practica en el uso y manejo de los guiones psp, La utilizaci´on de ejemplos que nos den una mayor practica en el llenado de las estad´ısticas de el proceso PSP Se debe tener mas cuidado en la estimaci´on de locs, esto en base al tipo de programa y como ser´a resuelto.

Notes and Comments: Registro de lo aprendido del proceso: conteo de l´ıneas y el de codificaci´on.

1.la realizaci´on y puesta en practica de un Standard, en este caso el de

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

35

Student Instructor Process

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP0.1 Elements

Date Program #

21/10/06 3A

PIP Number 1 2

Problem Description: La estimaci´on de tiempo quedo bastante peque˜na en comparaci´on a lo real Dise˜no conceptual incompleto, se anexo una clase mas durante el dise˜no de algoritmo

Propoal PIP Number 1

Proposal Description

2

Se debe tener en cuenta tanto lo nuevo que se har´a como las modificaciones de lo que ya se tenia, y todo lo que esto conlleva para poder hacer una estimaci´on mas cercana del tiempo. Se debe tomar un poco mas de tiempo para detallar correctamente el dise˜no conceptual, as´ı mismo el dise˜no se debe de hacer con mas cuidado para no olvidar nada.

Notes and Comments: Registro de lo aprendido del proceso:

1.aproximaci´on a una estimaci´on en el tama˜no de un programa a realizar 2.R3 an´alisis de defectos Me siento actualmente mas c´omodo con le conteo de locs, siendo esto ya algo mas natural para hacer.

Student Instructor Process

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP0.1 Elements

Date Program #

10/11/06 4A

PIP Number 1

Problem Description: Se debe tener en cuenta un mayor detalle a la hora de la planeaci´on para definir con menor margen de error la estimaci´on de los m´etodos que se agregaran clases ya existentes.

Propoal PIP Number 1

Proposal Description Se debe tener en cuenta tanto lo nuevo que se har´a como las modificaciones de lo que ya se tenia, y todo lo que esto conlleva para poder hacer una estimaci´on mas cercana del tiempo.

Notes and Comments: Registro de lo aprendido del proceso:

1. Llenado de la BD de O personal para la estimaci´on de tama˜nos 2.Llenado de la plantilla de estimaci´on de tama˜no. 3.Uso del PROBE. 4. Calculo de LOCs/Hora 5.Pruebas automatizadas El promedio de errores por k/loc disminuyo, aunque aun cometo numerosos errores, el hecho de llevar a cabo la fase de codificaci´on en el editor de texto me ha ayudado a cometer meno errores cada vez que codifico algo nuevo

36

Student Instructor Process

PIP Number 1

Propoal PIP Number 1

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP1.1 Elements

Date Program #

26/11/06 5A

Problem Description: Problema en la estimaci´on de numer´o de funciones por clase.

Proposal Description Hacer una planificaci´on mas especifica y a su vez ir pensando en las posibilidades para satisfacer los requerimientos para as´ı lograr una mejor estimaci´on.

Notes and Comments: Registro de lo aprendido del proceso:

1.CPI (el ´ındice de costo-desempe˜no)

El promedio de errores por k/loc disminuyo, creo que este m´etodo de codificaci´on si el uso de otras herramientas me ha servido para mejorar esto, aunque aun tengo que mejorar aun mas.

Student Instructor Process

PIP Number 1 2 2

Propoal PIP Number 1 2

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP1.1 Elements

Date Program #

31/11/06 6A

Problem Description: Problema en las pruebas. Creo esta vez el tiempo utilizado en ellas fue mayor a cualquiera anterior. La estimaci´on de locs nuevas a la base fue muy diferente al real. La estimaci´on de l´ıneas de c´odigo ( L´ogicas ) resulto demasiado alejada de lo real

Proposal Description Dar un poco mas tiempo a la planeacion y a la codificaci´on, a favor de generar un programa mas limpio de errores y que cumpla con su cometido En la etapa de dise˜no tomar en cuenta lo que planeamos hacer en cada clase para calcular de mejor manera las adicciones a la base planteada.

Notes and Comments: El tiempo empleado en pruebas fue casi igual al de la codificaci´on, puesto que el error cometido fue muy dif´ıcil de observar y por lo tanto de corregir, se debe dise˜nar con mas calma y explicar con mas detalle lo que se hara en busca de cometer menos errores.

37

Student Instructor Process

PIP Number 1

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP2 Elements

Date Program #

05/02/07 7A

Problem Description: Confusi´on en el llenado de algunos campos de los nuevos que se agregaron.

Propoal PIP Number 1

Proposal Description Revisar el proceso de nuevo par alimentar los nuevos conocimientos.

Notes and Comments: Registro de lo aprendido 1 uso de listas de comprobaci´on

Student Instructor Process

PIP Number 01

Propoal PIP Number 01

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP2.1 Elements

Date Program #

8A

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

Proposal Description Un ejemplo completo en el que se describa el llenado de cada plantilla.

Notes and Comments: El uso de las 4 nuevas plantillas para mejorar el proceso de dise˜no

38

Student Instructor Process

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP2.1 Elements

Date Program #

9A

PIP Number 01

Problem Description: El llenado de la plantilla de State Specification y los ejemplos de la misma son poco espec´ıficos.

Propoal PIP Number 01

Proposal Description Un ejemplo completo del desarrollo de esta plantilla para una mejor comprensi´on.

Notes and Comments: El uso de las 4 nuevas plantillas para mejorar el proceso de dise˜no

Student Instructor Process

PIP Number

Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP2.1 Elements

Date Program #

10A

Problem Description: El uso del t´emplate de State Specification queda aun poco claro.

Propoal PIP Number

Proposal Description Un ejemplo detallado del t´emplate y un detallado escenario de uso para ese t´emplate, para tener una idea mas concreta de su utilizaci´on.

Notes and Comments: En esta tarea se utilizo PSP 2.1. 1.Omit´ı el uso del t´emplate de state specification y de Functional Specification

39

3.14. Reporte de la mitad del Proceso (R4) Script Phase #

Purpose Criterio de entrada

Planning

Postmortem

Exit Criteria

To guide the analysis and writing of the R4 Report Programas del 1A al 6A Terminados Copia de los requerimientos de cada programa Copia de los reportes entregados para cada programa Copia del Stuwbk.xls Estimaci´on de esfuerzo para la fase de planeacion ( en minutos ) Estimaci´on del tama˜no del reporte Numero de p´arrafos Numero de graficas analizadas Registrar las siguientes estimaciones; Estimaci´on de esfuerzo en base a la estimaci´on de tama˜no ( en minutos ) Estimaci´on de esfuerzo para las fases del reporte siguientes Registrar el tiempo de planeacion en el time log Por cada pregunta del an´alisis entregue lo siguiente An´alisis general de la tabla o grafica usada Analizar el proceso/datos de la tabla o grafica Escribir el p´arrafo del an´alisis Identificar a´ reas de mejora Determinar metas Determinar si alg´un proceso necesita cambios Escribir el an´alisis de mejora del funcionamiento Escribir el tiempo de desarrollo en el time log Escriba el informe de tama˜no del reporte (por pregunta) # de tablas # de graficas # de p´arrafos Escriba el tiempo de post morten en el time log Completo el reporte R4 Completo el reporte de planificaci´on Completo el timelog

40

3.15. R4 Report Plan Summary

Figura 3.8:

41

3.16. R4 Time Recording Log Student:

Chi˜nas Vega Daniel

Date:

03/12/06

Date 03/12/06

Start 13:27:00

Stop 13:38:00

Interruption Time 0

03/12/06

13:41:00

15:59:00

09/12/06 09/12/06

12:14:00 14:20:00

13:47:00 14:30:00

DeltaTime 11

Phase planeacion

0

138

Desarrollo

0 0

83 10

Desarrollo PM

42

Comments Termine con la planeacion de reporte R4 Desarrollo terminados los dos primeros an´alisis, se tomo algunos d´ıas para corregir los errores de las hojas R3 y R4 del archivo de Excel Fin del desarrollo Postmorten terminada

3.17. Reporte R4 3.17.1. An´alisis de la Exactitud de Estimaci´on de Loc ˜ en los primeros seis programas. Analice la tendencia en la exactitud de estimaci´on de tamano

Figura 3.9: Error en el estimado de tama˜no para cada programa Si bien la estimaci´on de tama˜no para cada programa se pueden observar claramente dos picos el mayor de ellos el de subestimaci´on para A2 y el otro pico para sobre Estimaci´on en el programa 6A, si bien a partir del programa 3A la estimaci´on de tama˜no 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 y herramientas adquiridas en los anteriores programas se obtiene de nuevo una estimaci´on errada considerablemente, esto se debe al poco tiempo que le dedico a la planeacion y al dise˜no.

Figura 3.10: Tiempo de Planeaci´on El tiempo de planeaci´on venia increment´andose a partir del programa 3A lo que resultaba en una mejor estimaci´on de tama˜no, lo cual en el programa 6A disminuye, aun cuando el programa 6A tenia una mayor complejidad con respecto a sus antecesores, de eso se desprende el que la estimaci´on fuera mayor a lo real.

43

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

Figura 3.11: Se nota una clara tendencia a la sobreestimaci´on, si bien en el 5A esta iba disminuyendo en el 6A esta aumenta considerablemente con respecto a lo anteriormente visto.

Para cada uno de los programa 4, 5 y 6, si las LOC de objeto estimadas no est´an cercanas las LOC de objeto reales, determine por qu´e. El error se debe a la mala planeacion y un mal estimado en el tama˜no de los m´etodos por lo cual se tend´ıa a esperar m´as locs por objeto. Esto aumento en el programa 6A puesto que depend´ıa de mas m´etodos y por lo tanto el error fue mayor.

Basado en el an´alisis anterior, ¿cu´al es la mejor cosa que usted podr´ıa hacer para mejorar su exactitud en la estimaci´on? Tomar mas tiempo en al fase de planeaci´on para llevar a cabo una mejor estimaci´on de la cantidad de m´etodos y su tama˜no, as´ı como aprovechar mejor los datos hist´oricos con los que cuento para en base a ellos llevar a cabo mi planificaci´on.

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 m´etodo A. ¿Son utiles ´ para la estimaci´on del programa 7? Explique por qu´e o por qu´e no PROBE Method Selector Project 7 Estimate (E) 0 Size Method B Selector Size Estimate 210,42676 Range 203,05957 B0 210,42676 B1 0,0118365 R2 0,0002841

De procedimiento. Si Beta 0 no es cercana a cero o si Beta 1 no esta razonablemente cerca de 1.0 (entre 0.5 y 1.5) no se puede utilizar este procedimiento para calcular el estimado de tama˜no de un programa,en base a esto no es posible usar estos valores para la estimaci´on de tama˜no.

3.17.2. An´alisis de la Exactitud de Estimaci´on de Tiempo Analice la tendencia en la exactitud de estimaci´on 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 estimaci´on para el programa 3A lo cual va disminuyendo considerablemente para lo siguiente, mostrando una leve subestimaci´on en el programa 6A.

45

Para los primeros seis programas, ¿qu´e 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 6A es 3 veces mayor que en el 2A , se debe observar que en el 5A la productividad disminuyo con respecto al anterior, era aun mejor que los tres primeros.

Para los primeros seis programas, si la productividad vari´o, ¿los cambios est´an relacionados con la cantidad de tiempo utilizado en corregir los defectos en las fases de compilaci´on y pruebas?

Figura 3.14:

46

De las dos graficas anteriores se nota una clara tendencia a la disminuci´on de defectos removidos en la compilaci´on, mientras que en test no existe una tendencia a aumentar a partir del programa 4A.

Figura 3.15: As´ı mismo el tiempo de compilaci´on a disminuido con respecto a anteriores programas, esto con respecto al programa 6A , en base a esto puedo decir que la disminuci´on de tiempo en la compilaci´on se debe a la disminuci´on de errores*kloc que se deben corregir en esa fase, por lo tanto la productividad a aumentado considerablemente. ˜ ¿C´omo 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 gr´aficas no afecto ya que no siguen una misma tendencia en su crecimiento o ca´ıda.

An´alisis de los defectos introd. Y eliminados por fase (tabla D23)

Table D23 Type 10 20 30 40 50 60 70 80 90 100 Total

Number Injected Design 0 0 0 2 1 0 5 1 0 0 9

Code 0 83 0 10 2 0 0 3 0 0 98

Percentage Injected Design 0.00 % 0.00 % 0.00 % 22.20 % 11.10 % 0.00 % 55.60 % 11.10 % 0.00 % 0.00 %

Code 0.00 % 84.70 % 0.00 % 10.20 % 2.00 % 0.00 % 0.00 % 3.10 % 0.00 % 0.00 %

47

Number Removed Compile 0 82 0 9 1 0 0 2 0 0 94

Test 0 1 0 2 2 0 5 1 0 0 11

Percentage Removed Compile 0.00 % 87.20 % 0.00 % 9.60 % 1.10 % 0.00 % 0.00 % 2.10 % 0.00 % 0.00 %

Test 0.00 % 9.10 % 0.00 % 18.20 % 18.20 % 0.00 % 45.50 % 9.10 % 0.00 % 0.00 %

˜ ¿Qu´e tipos de defectos se introducen m´as en la fase de diseno?

Type 10 20 30 40 50 60 70 80 90 100 Total

Design 0 0 0 2 1 0 5 1 0 0 9

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

31/11/2006 31/11/2006 31/11/2006 31/11/2006 31/11/2006 31/11/2006

102 103 104 105 106 107

70 40 70 70 70 70

DLD DLD DLD DLD DLD DLD

TEST TEST TEST TEST TEST TEST

10,0 15,0 10,0 20,0 1,0 1,0

se debe calcular primero b1 y luego b0 se debe volver a dar el valor de lista a listaTemporal se debe calcular el valor de porcentaje como x*,01 se debe mantener los valores doubles es decir 1,00 no 1 se cambio 1 por 1,00 se cambio 2 por 2,00

Errores debidos a la falta de dise˜no y el correcto uso de los tipos de datos usados en las operaciones efectuadas y el mal calculo de algunas de ellas.

¿Qu´e tipos de defectos se introducen m´as en la fase de codificaci´on?

Type 10 20 30 40 50 60 70 80 90 100 Total

Code 0 83 0 10 2 0 0 3 0 0 98

El error m´as cometido en la codificaci´on es el tipo 20, es decir el de sintax esto debido en gran medida al poco cuidado que se le pone a la codificaci´on, puesto que algunas funciones son dise˜nadas o ampliamente modificadas de su dise˜no original en esta fase. 48

Qu´e tipos de defectos se eliminan principalmente en la fase de compilaci´on

Type 10 20 30 40 50 60 70 80 90 100 Total

Compile 0 82 0 9 1 0 0 2 0 0 94

El tipo de defecto que es mayormente removido en esta etapa es tambi´en el mas cometido en la codificaci´on es decir el de syntax, esto es normal puesto no podremos compilar correctamente hasta haber escrito la syntaxi correctamente para cada instrucci´on. Puesto que el compilador no me dejara avanzar mientras estos errores existan.

¿Qu´e tipos de defectos se eliminan principalmente en la fase de pruebas? 10 20 30 40 50 60 70 80 90 100

0 1 0 2 2 0 5 1 0 0

En este caso es claro que el tipo 70, lo cual nos lleva al mismo caso de cuales son los defectos que mas se insertan en la fase de dise˜no y en ambos casos el programa 6A fue el que ocasiono este tipo de error. Errores debidos a la falta de dise˜no y el correcto uso de los tipos de datos usados en las operaciones efectuadas y el mal calculo de algunas de ellas.

49

3.17.3. An´alisis de los defectos introd. Y eliminados por fase (R3). Program Number 1 2 3 4 5 6 7 8 9 10 Totals

Defect Densities New and Total Defects Changed LOC 137 24 136 22 92 12 318 25 199 10 321 14 0 0 0 0 0 0 0 0 107

Defects KLOC 175 162 130 79 50 44 0 0 0 0 0

per

Defects found in compile 23 20 10 24 9 8 0 0 0 0 94

Compile and Test Defects Compile Defects found defects per in test KLOC 168 1 147 2 109 0 75 1 45 1 25 6 0 0 0 0 0 0 0 0 0 11

Test defects per KLOC 7 15 0 3 5 19 0 0 0 0 0

R3

Analice los tiempos de eliminaci´on de defectos, bas´andose en la fase en la que los defectos son introducidos y eliminados Defect Fix Times Defects injected in designing

Defects injected in coding

Total defects injected

Tot. fix time Tot. defects Avg. fix time Tot. fix time Tot. defects Avg. fix time Tot. fix time Tot. defects Avg. fix time

Defects found in compiling 0 0 0 155 94 2 155 94 2

Defects found in testing 58 7 8 21 4 5 79 11 7

Total defects found 64 9 7 176 98 2 240 107 2

Bueno es claro que la fase que mas defectos inyecta es la de codificaci´on y que es en la de compilaci´on donde son removidos, si bien el tiempo promedio que se ocupa en removerlos es menor en compilaci´on en comparaci´on a la fase de test que es 2.5 veces mayor, si se compara el tiempo total que se uso para remover los defectos no encontramos con que la fase de codificaci´on ocupa 2/3 del tiempo mientras que solo 1/3 parte del tiempo es ocupado en remover defectos en el test. ¿Qu´e categor´ıa tiene el tiempo promedio de eliminaci´on m´as grande? El tiempo de eliminaci´on en test es mayor, esto debido a que los errores removidos en esa fase son mayormente inyectados en la fase de dise˜no ¿Qu´e categor´ıa tiene el tiempo total de eliminaci´on m´as grande? El tiempo m´as grande de eliminaci´on de errores es la de compilaci´on, esto debido en gran medida a que la mayor cantidad de errores son de sintaxis, los cuales son removidos en la fase de compilaci´on.

50

3.17.4. An´alisis de defectos encontrados por el compilador (tabla D24) Defect Type 10 20 30 40 50 60 70 80 90 100 Total

Number of defects through Compile 0 83 0 11 3 0 5 3 0 0 105

Tabla D24 Number of defects found in Compileg 0 83 0 9 1 0 0 2 0 0 94

Percentage of Type found by the Compiler 98.8 % 81.8 % 33.3 % 0.0 % 66.7 %

89.5 %

Analice la efectividad del compilador eliminando defectos por tipo de defecto Los tipos de defecto 20, 40 y 80 son encontrados mayoritariamente por el compilador, el cual por lo visto hace muy bien su trabajo, puesto que la mayor´ıa de estos es debido a una mala sintaxis, asignaci´on de tipos de variable es 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 ldefinir el tipo de error puesto que el error que no detecta 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 m´as propiamente de asignaci´on. Por lo tanto excluyendo este podr´ıamos decir que efectivamente 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 desempe˜no personal.

˜ Planeacion y Diseno Planeacion Mi desempe˜no en esta a´ rea a sido errado con respecto a la estimaci´on de tama˜no 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 que dispongo para auxiliarme en esta etapa del desarrollo de mis tareas. Al aumentar un poco de tiempo en esta a´ rea es decir poner mas atenci´on en los requerimientos que se me piden, para poder hacer una mejor planeacion. Dise˜no En este apartado, creo debo ser mas especifico en mis dise˜nos y dejar menos cosa ambiguas, as´ı el tiempo de codificaci´on ser´a menor y los errores introducidos disminuir´an, lo que llevar a un menor tiempo en las fases de compilaci´on y pruebas, lo que mejorara mi desempe˜no. Productividad 51

En base a lo anterior se espera aumentar mi productividad, actual mente para el programa es 57,49, por lo cual el prop´osito seria mantenerla cercana a 60 para as´ı mejorar la productividad a la fecha que es de 36,86, que esperar´ıa fuera de 45 al terminar los proyectos de psp Cambios en Etapas Etapa de Planeacion Propongo hacer m´as espec´ıfica esta etapa, a˜nadiendo al diagrama actualmente utilizado, uno que cuente con cada una de las clases planeadas, los m´etodos planeados para cada fase en forma de tablas, a cada funci´on se le designara un tama˜no espec´ıfico y la suma de sus locs ser´a el total de locs de la clase. Etapa de dise˜no El dise˜no comprender´a en una primera instancia un diagrama de secuencia para hacer el dise˜no mas espec´ıfico.

52

3.18. Reporte R5 3.18.1. Reporte de final de proceso (R5) Script Fase #

Prop´osito Criterio de entrada

1

Planeaci´on

2

Desarrollo

3

Postmortem

4

Criterio de Salida

Guiar el an´alisis y la realizaci´on del reporte R5 - Tareas 1A a 10A completos - Reportes R1, R2, R3 y R4 - Student workbook (hoja excel) - Estimar el tama˜no del reporte * Numero de parrafos de analisis * Numero de tablas/graficas a utilizar - Estimar el esfuerzo basado en el tama˜no del reporte - Registrar estimados en la forma Plan Summary - Registrar tiempo de planeaci´on en time log. - Para cada pregunta del an´alisis * Generar una/s tabla/gr´afica para an´alisis o una tabla de datos si es posible * Analizar tabla/gr´afica y datos del proceso * Escribir parrafo de an´alisis - Revisi´on del desenvolvimiento general - Identifcar areas en donde mejorar - Revisi´on de metas pasadas - Determinar cambios y proponer medidas al proceso - Poner metas cuantificables - Darle formato - Registrar tiempo de desarrollo en time log - Medir tama˜no del reporte * Numero de tablas/gr´aficas * Numero de parrafos de analisis - Completar la forma Plan Summary - Registrar tiempo de postmortem en timelog - Reporte R5 completo - Plan Summary completo - Time log completo

53

3.18.2. R5 Report Plan Summary Student Instructor

Daniel Chi˜nas Vega Luis Fernando Castro

Date

27/01/08

Size Data Object Tablas Gr´aficas Parrafos

Effort Estimate Plan Number 2 17 34

Actual Number 2 19 32

Est Effort per Object 1 1 12 Total

Estimated Effort 2 17 364 283

Effort Data Phase Planeacion Desarollo Postmortem Total

Plan Time 20 283 10 313

Actual Time 19 250 16 285

3.18.3. R5 Time Recording Log Student:

Date 27/01/07 27/01/07 27/01/07

Start 15:23 16:05 11:00

Daniel Chi˜nas Vega

Stop 15:45 10:43 11:16

Date:

Interruption Time 3 28

54

28/01/07

Delta Time 19 250 16

Phase 1 2 3

Comments Revisi´on de la R4 Consultas a la gu´ıa R4

˜ 3.18.4. An´alisis de la precisi´on de la estimaci´on de tamano

Figura 3.17: La estimaci´on de tama˜no 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 respecto a la primera parte del proceso, esto debido en gran parte a la madurez obtenida y el uso de una base de datos, que para la tarea 7A contaba ya con informaci´on suficientes para ayudarnos en la estimaci´on, de esta forma la mejora es notoria conforme el avance en las tareas pues se reduce claramente el error en la estimaci´on del tama˜no, cabe notar que a partir de la tarea tres y aun con la modificaci´on del proceso siempre hubo una sobre estimaci´on del tama˜no, una tendencia clara en las tareas 3A-10A. La introducci´on de dos fases nuevas al proceso Revisi´on de Dise˜no y Codificaci´on a partir de la segunda etapa del proceso (7A-10A) mejoraron las estimaciones, principalmente la revisi´on del dise˜no ayudo a una mejor estimaci´on del tama˜no, al introducir esta etapa de revisi´on disminuimos los errores en el dise˜no y mejoramos la estimaci´on de locs (Unidad de medida del tama˜no).

3.18.5. An´alisis de estimaci´on de tiempo

Figura 3.18:

55

La estimaci´on de tiempo para cada Tarea resulto dentro del 70 % de efectividad (30 % en la grafica). No se noto una mejora tan marcada como en el caso de la estimaci´on del tama˜no, se nota a partir del cambio en el proceso (Tareas 7A-10A) una variaci´on en el porcentaje de error que cambia de sobre estimaci´on a subestimaci´on, aunque se mantiene en el rango de efectividad planteado no es consistente. La experiencia obtenida hasta el momento fue importante para mantenernos dentro del rango esperado, sin embargo la falta de un mejor progreso se debe en gran medida al cambio de proceso, creo necesitar´ıa de un par de tareas extras para desenvolverme mejor en el proceso con respecto a la estimaci´on de tiempo. La introducci´on de dos fases nuevas al proceso Revisi´on de Dise˜no y Codificaci´on a partir de la segunda etapa del proceso (7A-10A) fueron un de factor importante que me permitieron mantenerme en un rango satisfactorio con respecto al porcentaje de error, al poder corregir de manera temprana los posibles errores que hubieran consumido m´as tiempo en etapas adelantadas del proceso.

3.18.6. Productividad

Figura 3.19: La productividad se mantuvo por debajo de 60, en las primeras tres tareas de la segunda parte del proceso (7A-9A) esto debido al cambio en el proceso, los cambios as´ı como la inserci´on de dos nuevas etapas al proceso tuvieron un costo claro en mi productividad. En el an´alisis anterior me propuse mantener mi productividad en 60 lo cual se cumpli´o superando mis expectativas al lograr un aumento considerable en la misma en la u´ ltima tarea.

56

3.18.7. An´alisis de tipos de defectos

Figura 3.20: Es claro que la mayor cantidad en defectos son del tipo c´odigo, seguidos de los de funci´on, esto nos muestra cual importantes son las etapas de dise˜no y codificaci´on, as´ı mismo es ah´ı donde se insertan las dos nuevas etapas de revisi´on, de ah´ı la importancia de elaborar dise˜nos m´as claros y pseudoc´odigos m´as espec´ıficos, de tal forma que reduzcamos estos errores. Type 10 20 30 40 50 60 70 80 90 100 Total

Number Injected Design 0 1 0 10 3 0 8 2 0 0 24

Code 0 88 0 16 2 0 2 8 0 0 116

Percentage Injected Design 0.00 % 4.20 % 0.00 % 11.70 % 12.50 % 0.00 % 33.30 % 8.30 % 0.00 % 0.00 %

Code 0.00 % 75.90 % 0.00 % 13.80 % 1.70 % 0.00 % 1.70 % 6.90 % 0.00 % 0.00 %

De la cantidad de defectos cometidos la gran mayor´ıa de estos son inyectados en la fase de codificaci´on siendo una raz´on m´as por la cual fue introducida una nueva fase de revisi´on despu´es de la codificaci´on aunado a esto en vista de los resultados obtenidos es de suma importancia tener un mejor control de la etapa de codificaci´on, buscando reducir aun mas los errores cometidos.

57

3.18.8. Defectos removidos por fase

Figura 3.21: la introducci´on de dos nuevas etapas en el proceso PSP denotan una claro cambio en la cantidad de errores removido por etapa disminuyendo considerablemente los defectos removidos en compilaci´on y disminuy´endolos en las pruebas a s´ı mismo es claro que la experiencia adquirida as´ı como el uso de procesos que se vuelven mas met´odicos conforme 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 gran medida a la inserci´on de las dos nuevas etapas, las cuales son de revisi´on, lo cual podr´ıa darnos una justificaci´on aceptable para la inserci´on de mas o mejorar las ya establecidas etapas de revisi´on en pos de disminuir aun m´as el costo por fallas.

58

3.18.9. Rendimiento

Figura 3.23: Es claro el aumento de locs revisadas por hora en ambas etapas nuevas, lo que denota la clara mejora obtenida a partir de ellas y consecuentemente un mejor uso de ambas etapas para mejorar nuestro PSP.

Figura 3.24: El rendimiento en la fase de revisi´on de dise˜no se muestra ambiguo, no se denota ninguna relaci´on con respecto a LOC/Hora, se necesitar´ıan de m´as datos para poder tener una opini´on relevante con respecto a esto.

59

Figura 3.25: Es claro una tendencia a la disminuci´on en el rendimiento conforme aumentan las LOC a revisar por hora, la importancia de la etapa de codificaci´on y como esta afecta nuestro rendimiento es clara, debemos concentrarnos mas en 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 disminuci´on del rendimiento conforme el aument´o de LOC/hora, esto denota la importancia de ambas etapas, la cantidad de locs afectara de manera directa nuestro rendimiento.

60

Cap´ıtulo 4

Conclusiones al termino del proceso ( PSP ) ´ 4.0.10. Areas para mejorar Dise˜no Revisi´on de dise˜no Codificaci´on Revisi´on de c´odigo Tiempo de revisi´on promedio Calidad

4.0.11. Medidas para mejorar Etapas Dise˜no y Revisi´on de dise˜no La etapa de dise˜no afecta directamente las siguientes etapas del proceso debo trabajar en ella de tal forma que realice una mejor estimaci´on de LOC y Tiempo, la etapa de revisi´on deberia hacerse mas minuciosa para reducir los errores que pasan a las siguientes etapas. Codificaci´on y revisi´on de c´odigo Puesto que la mayor´ıa de los errores encontrados son de tipo c´odigo es de suma importancia mejorar en esta etapa, prestando una mayor atenci´on la codificar reduciendo los errores que encontraremos en la etapa de revisi´on y de esta forma mejorar nuestro rendimiento as´ı mismo la etapa de revisi´on debe enriquecerse a un mas haciendo un mayor uso de los checklist para disminuir aun mas los errores que pasan a las siguientes etapas. Tiempo de revisi´on Una posible mejora en nuestro proceso seria reducir los tiempos de revisi´on, esto se ve afectado directamente por las etapas de dise˜no y codificaci´on, en ellas debemos ser mas minuciosos de tal forma que reduzcamos los errores procedentes de las mismas, de esta forma reducir´ıamos los errores y mejorar´ıamos nuestros tiempos de revisi´on, en este punto creo solo la experiencia nos permitir´ıa mejorar as´ı mismo no hay que dejar de lado tener m´as cuidado al hacer las cosas y prestar m´as atenci´on 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 se˜nalados, de esta manera el desarrollo de mi trabajo mejorara. Una forma de medir esto es el uso del Yield y el A/FR al mejorarlos podremos decir que aumento la calidad de nuestro proceso, podre se˜nalar de manera confiable y basado en pruebas que tanto se ha mejorado. La reducci´on de errores inyectados en las diferentes etapas que constituyen el proceso, as´ı como una mejor estimaci´on del LOC y tiempo son importantes metas a seguir si quiero mejorar, de esta manera aumentare la calidad y con lo anterior mente expuesto, tendr´e una medida mas clara sobre si existe una mejora o no.

4.0.13. Revisi´on de metas Estas fueron las metas propuestas en R4. ˜ Planeaci´on y diseno Planeaci´on Aumentar tiempo en esta a´ rea es decir poner m´as atenci´on en los requerimientos que se me piden, para poder hacer una mejor planeaci´on. Dise˜no En este apartado, creo debo ser mas especifico en mis dise˜nos y dejar menos cosas ambiguas, as´ı el tiempo de codificaci´on ser´a menor y los errores introducidos disminuir´an, lo que lleva a un menor tiempo en las fases de compilaci´on y pruebas, lo que mejorara mi desempe˜no. Productividad En base a lo anterior se espera aumentar mi productividad, actual mente para el programa es 57,49, por lo cual el prop´osito seria mantenerla cercana a 60 para as´ı mejorar la productividad a la fecha que es de 36,86, que esperar´ıa fuera de 45 al terminar los proyectos de psp.

4.0.14. Tiempo

Figura 4.1: En este punto es claro que el tama˜no de los programas realizados en cada tarea creci´o r´apidamente, al igual que el tiempo de desarrollo a partir de la tarea numero 9, por lo cual es justificado el hecho que el tiempo de desarrollo para las ultimas dos tareas aumentara significativamente.

62

Figura 4.2: El porcentaje de tiempo ocupado para la planeaci´on de cada tarea disminuyo considerablemente, siendo contrario a las metas planteadas en r4 sin embargo es claro que e´ l porcentaje de tiempo en la compilaci´on disminuyo considerablemente concuerda con lo que busc´abamos obtener. La meta se cumpli´o parcialmente aun necesito mejorar y tomar con mas importancia las etapas de planeaci´on.

4.0.15. Errores

Figura 4.3: En t´erminos Generales esta meta se cumpli´o pues es clara una disminuci´on en los errores encontrados a lo largo del proceso. En un estudio m´as a fondo observamos lo siguiente: Program Number 1 2 3 4 5 6 7 8 9 10 Totals

Defect Densities New and Total Defects Changed LOC 137 24 136 22 92 12 318 25 199 10 321 14 252 10 281 5 519 13 1134 5 140

Defects KLOC 175 162 130 79 50 44 40 18 25 4 0

per

Defects found in compile 23 20 10 24 9 8 1 0 0 0 95

63

Compile and Test Defects Compile Defects found defects per in test KLOC 168 1 147 2 109 0 75 1 45 1 25 6 4 0 0 0 0 3 0 2 0 16

Test defects per KLOC 7 15 0 3 5 19 0 0 6 2 0

En esta cabe notar que la cantidad de errores por KLOC disminuyo considerablemente a lo largo de todo el proceso siendo de 4 KLOC al llegar a la tarea 10 con lo cual cumpl´ı mi meta de reducir los errores, a si mismo los defectos encontrados en compilaci´on se reducen a 0 en la etapa de compilaci´on en las tres u´ ltimas tareas, cabe notar que un punto alarmante son los errores encontrados en la etapa de pruebas (TEST) un apartado en el que deber´ıa trabajar m´as, esto es mejorar mis dise˜nos y elaborar aun mas mis pruebas de escritorio para encontrar los errores antes de pasar a la etapa de codificaci´on 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 lo cual puedo decir esta meta fue cumplida.

4.0.17. Metas El proceso se mantendr´a igual, puesto que las metas alcanzadas hasta ahora son satisfactorias como ya se explico anteriormente, puesto que quedaron detalles que faltaron mejorar se toman como metas a futuro las siguientes.

˜ Planeaci´on y Diseno Siendo las dos etapas m´as importantes en el desarrollo de toda la tarea, estimo dedicar m´as tiempo a desarrollar correctamente estas dos etapas, a fin de reducir el error en la estimaci´on de tama˜no y cantidad de loc por programa asi mismo reducir los errores provenientes del dise˜no. 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”Presentaci´on. Rational Software. Presentaci´on disponible en http://www.rational.com/uml como UMLconf.zip

65

66