You are on page 1of 66

`

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

definir par´ametros. 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. en este caso. Ingenier´ıa al software. reglas. procedimientos. Proceso de ingenier´ıa de software Un conjunto de etapas parcialmente ordenadas con la intenci´on de logra un objetivo. cabe recordar que para controlar la calidad es necesario. la obtenci´on de un producto de software de calidad [Jacobson 1998]. La aplicaci´on de un enfoque sistem´atico. 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. PSP Proceso Personal de Software (PSP. nos proporciona una estructura con gu´ıas y procedimientos para el desarrollo de un proceso. PSP es un proceso de auto mejoramiento de la calidad de software. documentaci´on y datos asociados que forman parte de las operaciones de un sistema de computaci´on. disciplinado y cuantificable al desarrollo operaci´on (funcionamiento) y mantenimiento del software. que tenga como finalidad la creaci´on de software de calidad. por sus siglas en ingl´es PERSONAL SOFTWARE PROCESS). [IEEE. 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. 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.Cap´ıtulo 1 Introducci´on Software. Haciendo uso de procesos cuantificables y repetibles. de ahi la importancia en su desarrollo.[IEEE] Tomando como punto de partida esta definici´on. Por ello debemos contar con m´etodos y procesos que nos permitan mantener una adecuada calidad en la totalidad del software. 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. 4 . Es el conjunto de los programas de c´omputo.

R 2002 por Carnegie Mellon University. 5 . 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. Resistir presiones por compromisos no razonables. 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. Una disciplina que muestra c´omo mejorar el proceso personal.1. Cumplir con los compromisos.Cap´ıtulo 2 Desarrollo 2. Tambi´en es un procedimiento definido que le ayuda a mejorar el desempe˜no. 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. Es un proceso enfocado en el mejoramiento personal de las pr´acticas usadas en el desarrollo de software.

PSP1: Planificaci´on del tama˜no. 6 . Figura 2. El Proceso del PSP se puede describir mediante el siguiente diagrama.1: El aprendizaje del psp se puede dividir en tres bloques: PSP0: Establecer una base para la futura medici´on de nuestro desempe˜no.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. uso de recursos y tiempo de desarrollo.2: Esta dividido en 10 Tareas que nos introducen de una manera estructurada y progresiva en el desarrollo de nuestro Proceso personal de software. PSP2: Administraci´on de defectos y rendimiento (yield) Proceso de aprendizaje PSP Figura 2.

PSP 0 es simple y definido. Hay dos nuevos elementos del proceso. Se hace uso de una bit´acora para el registro de los tiempos y de una bit´acora para el reporte de los defectos. 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 los m´etodos con los que actualmente dise˜namos y desarrollamos nuestro software. 2.3. 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. De forma que el conteo de LOC sea m´as f´acil.2. PSP 0. se usa un est´andar de defectos para llevar un control de los mismos. La forma de propuesta de mejora de proceso (PIP). Realizar mediciones de tama˜no exactas y precisas. Est´andares de conteo ( R1 )y codificaci´on ( R2 ).1 Objetivos Medir el tama˜no de los programas que produzca. El PIP contiene informaci´on de mejora del proceso N´umero de PIP. Soluci´on propuesta. usando una lista ligada para almacenar los n n´umeros a usar en los c´alculos. 7 . para el dise˜no de mi est´andar de conteo eleg´ı el tipo l´ogico. Los est´andares de codificaci´on y conteo son necesarios para escribir los programas PSP. Descripci´on del problema. deben ser ajustados al lenguaje que usemos para codificar. Notas y comentarios. Para mejorar el proceso. Se recolectan datos sobre el trabajo realizado. Incorporar medidas b´asicas en el proceso de desarrollo de software. es necesario registrar los problemas y propuestas de mejora para una referencia futura. PSP 0 Objetivos Demostrar el uso de un proceso definido al escribir un programa peque˜no. 2.2. Contabilizar los tipos de LOCs en los programas que produzca. tiempo utilizado por fase y defectos encontrados en la compilaci´on y pruebas.2.1.

2.5. Densidad de defectos en las fases de compilaci´on y pruebas.1. 2.1. Forma parte de los reportes R4 y R5 que se trataran mas adelante. 2. Tiempo promedio de correcci´on de defectos por fase de introducci´on y eliminaci´on. 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. tendr´a como salida el conteo de LOC totales. registrar y reportar cuidadosamente los datos del proceso. el conteo separado de LOC y el de m´etodos. 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. 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. Incluye las siguientes tablas Densidad de defectos. Lo Probaremos contando las LOC de los programas 1A y 2A.4. 2.b1xavg 8 . las LOC l´ogicas en cada objeto o funci´on y el n´umero total de m´etodos de cada objeto.2. Reporte de an´alisis de defectos R3 Objetivos La densidad y tipos de defectos introducidos y encontrados mientras se desarrollan programas. La f´ormula del par´ametro de regresi´on b0 es b0 = yavg .5.3.3. Importancia de recolectar.2. Tarea 3 Creaci´on de un programa que cuente las LOC l´ogicas totales de un programa. Haciendo uso de nuestro est´andar de conteo.

1 Objetivos Los objetivos del PSP 1.2. Tarea 5 Creaci´on de un programa para resolver una integral de una funci´on num´ericamente.3: 2. 9 . La regla de Simpson.6. dado un conjunto de datos hist´oricos y un estimado de LOCs.La f´ormula del par´ametro de regresi´on b1 es Figura 2. deber´a ser dise˜nado para integrar usando varias funciones proporcionadas. Seguir el desempe˜no contra estos planes. Juzgar la probabilidad de las fechas de terminaci´on del proyecto.4: 2.6. 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 %. 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.1.1 son introducir y practicar m´etodos para: Hacer planes de recursos y de calendario de trabajo.6. 2. Se usara una lista ligada para almacenar los datos hist´oricos. Figura 2. PSP 1. usando la regla de simpson para una funci´on de distribuci´on normal.

La f´ormula para calcular el rango de predicci´on es Figura 2.Rango (70 %). Leer el estimado. Sigma es la desviaci´on est´andar de la regresi´on lineal de los datos. 8. 7. Calcular el Rango para un intervalo de 70 %.2 grados de libertad (dof). n es el n´umero de puntos de los datos hist´oricos. 5. Repetir los pasos 5-7 para el Rango de un intervalo de 90 %. utilizar los siguientes pasos. Imprimir los resultados. 3. t70(2/α.Para calcular el intervalo de predicci´on. 1. Leer los datos hist´oricos. Figura 2. x’s y y’s. Calcular a proyecci´on como yk= B0 + B1 * xk.5: Donde: x son los datos hist´oricos de tama˜no de objeto. Calcular el LPI = yk .6: 10 . dof ) es la distribuci´on t de dos colas de 70 % para n . 9. xk. 6. Calcular el UPI = yk + Rango (70 %). 2. Calcular B0 y B1. 4.

restar d del valor de prueba t. dividir d entre 2.5 del valor de prueba t. digamos 0. Para protegerse contra este problema con el m´etodo de Simpson. • Si el resultado de la integraci´on es demasiado bajo.0. Si es demasiado bajo. 4. se debe asegurar que el programa manejar´a un valor 0 de la funci´on que est´a siendo integrada. Reciclar en 5. continuar. 5.Donde x son los datos hist´oricos de tama˜no de objetos. Si es demasiado alto. Para 70 %.0. ajustar d. 8. n es el n´umero de puntos de datos hist´oricos. Integrar de nuevo y probar si el resultado est´a dentro del error aceptable. integrar para obtener 0. y son los LOC nuevas y modificadas hist´oricas (para tama˜no) o tiempo (para esfuerzo).85 . 11 . restar d = 0. Para 90 %. 1. escoger un l´ımite superior m´as peque˜no. no modificar a d. Hacer una integral inicial y pruebar para ver si da el valor apropiado de p.45 (0. 2. Para calcular el valor de t(. 6. integrar para obtener 0.5 al valor de prueba t. 2/αdof ) Iniciar con un valor de prueba para el l´ımite superior y calcular el valor de la integral. Si es demasiado alto. Siempre que el signo del error cambie. ajustar d. sumar d al valor de prueba t.00001. Comparar el resultado con el valor deseable. Si es demasiado bajo. si no. Las reglas para ajustar d son: En tanto que las pruebas del error de los resultados den el mismo signo del error.0.35 (0. • Si el resultado de la integraci´on es demasiado alto.5). Iniciar con un valor de prueba de t.5). 7. escoger un l´ımite superior de prueba m´as grande. si no continuar. digamos 1. Note que este m´etodo para ajustar d podr´ıa resultar en un valor de prueba de t = 0.95 . sumar d = 0. Una forma para hacer este c´alculo es usar los siguientes ocho puntos. 3. Hacer integraciones de prueba sucesivas hasta que el valor de la integraci´on est´e dentro de un error aceptable.

7. Un an´alisis de los defectos encontrados por el compilador (tabla D24. Ganar experiencia en la definici´on de un proceso para su uso propio. Un an´alisis de los tiempo de correcci´on de defectos. Un an´alisis para la exactitud de la estimaci´on de tiempo y c´omo ha evolucionado durante los programas desarrollados a la fecha. Se debe incluir en este proceso las fases de planeaci´on y de postmortem.g. 12 . 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. • Analizar los datos de proceso. p´agina 773). Utilizar el proceso para: • Planear las tareas del reporte R4. R3. 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. Una descripci´on de las a´ reas de m´as alta prioridad para la mejora personal. Comprender el proceso de referencia y c´omo ha cambiado durante el curso.2. Para este reporte se debe dise˜nar: Un proceso para analizar los datos del PSP y para producir un reporte. • Concluir el postmortem. Aprender a analizar los datos del proceso. cambios al proceso) que se tomar´an para lograr estas metas. • Producir el reporte. Establecer metas medibles y definir las acciones de mejora correspondientes. lo que se espera: Identificar las oportunidades de mayor influencia para mejorar el desempe˜no personal. Un an´alisis de los tipos de defectos introducidos y eliminados para los programas desarrollados a la fecha (tabla D23. Describir las acciones espec´ıficas (e. Establecer metas cuantitativas y medibles. p´agina 773). con su justificaci´on.

1. PSP 2. 2. Identificar las mejoras potenciales. 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. u´ sela con gran confianza.7 ≤ r2 ¡ 0. o r 2. Fuerte y puede ser usada para planeaci´on.0 Listas de revisi´on de c´odigo y dise˜no. Se agregan al proceso: Lista de chequeo de dise˜no. Priorizar las a´ reas de mejora basandose en el peso potencial.C´omo m´ınimo.5 ≤ r2 ¡ r2 < 0. Cerca de 0 implica que no tienen relaci´on. Conducir un an´alisis para identificar las causas del desempe˜no actual y establecer niveles de desempe˜no futuro.9 ≤ r2 0.8. pero con cuidado No es confiable para prop´ositos de planeaci´on 13 . cuando x se incrementa y se incrementa. Examinar los datos PSP para comprender el desempe˜no actual. Lista de chequeo de codificaci´on. La correlaci´on rxy puede ir de +1 to -1.8. Adecuada para planeaci´on. 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. Para este prop´osito. cuando x se incrementa y se decrementa. Identificar las acciones espec´ıficas necesarias para lograr estos niveles de desempe˜no. Cerca de +1 implica una fuerte relaci´on positiva. 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. se deber´an tomar los siguientes pasos para establecer los objetivos. Cerca de -1 implica una fuerte relaci´on negativa. M´etodos para evaluar y probar lo acertado de nuestras revisiones. 2.5 La relaci´on es Predictiva. usamos el valor de la relaci´on rxy al cuadrado. Si r2 es 0.

n es el n´umero de puntos. 3.2 se considera que la relaci´on es debida a la coincidencia. Figura 2. 2*(1-p). 2. n es el n´umero de sus miembros. La f´ormula para calcular el coeficiente de correlaci´on r es: Figura 2. 14 . especialmente cuando los datos son escasos.y) es la correlaci´on. Una fuerte correlaci´on puede ser coincidental. Por ejemplo. Una a´ rea en la cola3 0. Calcular el valor de t.Limitaciones de la Correlaci´on La correlaci´on no implica causa y efecto. pero esta correlaci´on no es significativa. Encontrar la probabilidad p integrando n´umericamente la distribuci´on t para n -2 grados de libertad. un conjunto de datos con s´olo dos puntos siempre tendr´a r 2 = 1. Una a´ rea en la cola £ 0.7: Donde x y y son dos conjuntos de datos por parejas. El c´alculo de la significancia consiste de tres pasos: 1. de -Y a t. La prueba de significancia determina la probabilidad que una correlaci´on fuerte sea por casualidad y por lo tanto no tenga significancia pr´actica.8: Donde: r(x. Hay que recordar que una correlaci´on fuerte puede ser s´olo por coincidencia. Calcular la cola de la distribuci´on.05 se considera una evidencia fuerte que existe relaci´on.

9: Entonces. Plantillas de dise˜no que proporcionan una l´ınea de trabajo ordenada y formatos para registrar dise˜nos.2. se usara la rutina de ordenamiento de la tarea 8 para ordenar de manera ascendente los n´umeros.9. Dividir la distribuci´on normal en algunos segmentos S. Normalizar el conjunto de datos. transformar cada xi a una zi normalizada. Figura 2. Supondremos una n ¿20 y un m´ultiplo par de 5 ( se puede suponer n = 50 ). usando n-1.1. Los pasos de la prueba c2 son como sigue: 1.1 son introducir: Medidas adicionales para la administraci´on de la calidad del proceso. Primero.9. Esto es realizado al comparar la estructura del conjunto de datos con la estructura de una distribuci´on normal ideal. La prueba c2 para normalidad determina la probabilidad que un conjunto de datos siga una distribuci´on normal. 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. 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.10: 3. 2. 2. Se usara la rutina de integraci´on de la tarea 5 para calcular la distribuci´on de c2.2. calcular la desviaci´on est´andar.1 Los objetivos del PSP2. 2.9. donde 15 . Tarea 8 Creaci´on de un programa para ordenar una lista ligada de n pares de n´umeros reales en orden descendente. PSP 2. Figura 2. Ordenar el conjunto de datos en orden ascendente.

por: Sustituir dof por n. esto es n/S.2 es generalmente considerado suficiente para aceptar que ajusta. Examinar 1-p para interpretar los resultados. 1 − p > 0. 16 . S=10 satisface estos requerimientos. Ni. Determinar cu´antos elementos de la distribuci´on normal caer´ıan en cada segmento. Calcular la cola de la distribuci´on como 1-p. p´agina 518. Hacer un estimado de las entregas proporcionadas por el usuario y determinar los intervalos de predicci´on del 70 % y 90 % para el estimado.3. Calcular el valor Q para los segmentos. Valores intermedios indican grados intermedios de ajuste. Figura 2. Figura 2. en este caso es 5. 1 − p < 0. 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. β2. Tarea 10 Creaci´on de un programa para calcular los par´ametros de estimaci´on de regresi´on m´ultiple de tres variables (β0.11: 7. 5.12: Nota: La ecuaci´on anterior para c2 difiere de la ecuaci´on A7. Normalmente. 8.9.n/S 3 5 S>3 S23 n Para este problema. 2. 9. β1. ki. Sustituir Q por x. Calcular la probabilidad p de la distribuci´on c2 para S-1 grados de libertad (dof) al integrar de 0 a Q. andβ3). Determinar cu´antos elementos del conjunto de datos normalizados caen en cada segmento. 4. 6.05 es generalmente considerado suficiente para rechazar que ajusta.

15: 17 . se obtendran las siguientes ecuaciones lineales simult´aneas. Figura 2.14: 3.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. 1. Cuando se calculen los valores de los t´erminos.13: 2. Figura 2. Utilizar la siguiente f´ormula de regresi´on m´ultiple para calcular el valor estimado. Encontrar los par´ametros Beta resolviendo las siguientes ecuaciones lineales simult´aneas. Figura 2. Los 13 pasos se describen a continuaci´on.

Resolver para los t´erminos Beta. Figura 2. Figura 2.4. Calcular la varianza como sigue. Figura 2. Determinar el intervalo de predicci´on resolviendo para el rango con la siguiente ecuaci´on. Diagonalizar.16: 5.18: 7.19: 18 .17: 6. Figura 2. 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.

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. FOR J = I + 1 TO N + 1 ASIGNA AI . Para resolver un sistema de N inc´ognitas. Los t´erminos en la ra´ız cuadrada son los siguientes.902 horas 13.8.J) (Tome el valor del pivote en la posici´on I. I = 1. 6.21: 10.) 3. I = 1 2. LET P=AK .22: 12. El 11. J = AI . I = maxjAJ. J / AI .000+0.I. 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. I = I + 1.I.) ASIGNA AI . grados de libertad en la tabla A2.I. IF I < N THEN IR AL PASO 2. IF P = 0 THEN SALIR (Si el resto de esta columna es cero. Figura 2.0150*3.71+0.7 horas. Figura 2. El estimado final es: z = 6. I (Coloca un 1 en la posici´on I. Algoritmo de gauss 1.) 5.I. El intervalo de predicci´on de 38. SALIR a sustituci´on hacia atr´as (¡Dise˜no su propio algoritmo!) 19 . no existe una soluci´on u´ nica.386.1 y 179. p´agina 489.J) Y A(K. FOR L = I + 1 to N multiplicar rengl´on I por -AL . La ra´ız cuadrada se eval´ua de la siguiente manera. La eliminaci´on Gaussiana es un algoritmo com´un para resolver estas ecuaciones. La varianza se eval´ua con lo siguiente.) 7. 8.0784*650+0. IF K > I THEN FOR J = I TO N + 1 INTERCAMBIA A(I. Figura 2.846 horas significa que el estimado est´a entre 102.) 4.2461*155 z = 140. I y sumar a rengl´on L (se colocan ceros a la columna por debajo de la posici´on I.20: 9.

Fase de desarrollo.) Analizar las tendencias para defectos por KLOC encontrados en revisiones de dise˜no. Analizar los tipos de defectos que se introducen en dise˜no y codificaci´on. En aquellos casos donde no se tengan defectos. Fase de postmortem. 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 las tasas de eliminaci´on de defectos para las revisiones de dise˜no. Producir el reporte. 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. 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. Utilizar este proceso para: Planear las tareas del reporte R5. Incluir un an´alisis Pareto de estos tipos de defectos. compilaci´on versus pruebas unitarias. 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 %. Al menos se deber´a hacer lo siguiente. Aprender a actualizar nuestro proceso personal. 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 %. (Ver el Ap´endice A12 para una descripci´on del procedimiento del an´alisis de Pareto. Aseg´urando resumir el desempe˜no actual. Se actualizar´a el proceso usado en R4 para desarollar este reporte. revisiones de c´odigo. compilaci´on y pruebas. 20 . Muestrar c´omo la exactitud en la estimaci´on del tiempo ha evolucionado durante las tareas. Analizar sus datos de proceso.10. Describir c´omo se intentan cumplir esas metas. El dise˜no de proceso debe incluir una: Fase de planeaci´on. Ganar experiencia en el establecimiento de metas medibles y en la detecci´on de las acciones de mejora correspondientes. desempe˜no futuro y metas de mejora. Muestrar c´omo la exactitud en la estimaci´on del tama˜no ha evolucionado durante las tareas.2. Analizar las tendencias para los defectos totales por KLOC. revisiones de c´odigo. Analizar el rendimiento de la revisi´on de dise˜no versus las LOC revisadas por hora. Completar el postmortem.

mas cualquier otra gr´afica o datos que apoyen el an´alisis. 21 .El reporte debe incluir: Todas las tablas y gr´aficas requeridas. Metas de mejora cuantitativas y medibles y acciones espec´ıficas que se planeen tomar para lograr esas metas. An´alisis y conclusiones por escrito.

Plantillas y est´andares para su utilizaci´on en PSP Tabla de referencia Figura 3. Formas.1: Tabla de referencia 22 .1.Cap´ıtulo 3 Resultados 3.

2: Ejemplo de la Bit´acora de Tiempo (Tarea 6) 3. Figura 3.3: Ejemplo del registro de errores (Tarea 6) 23 . Bit´acora de Tiempo. el tipo de error. En esta se plasman la informaci´on de defectos (errores) cometidos en la realizaci´on de las tareas. el numero continuo.3. la fecha. el registro esta conformado por el numero de tarea donde se cometi´o. tiempo de correcci´on y una breve descripci´on del mismo. Figura 3. Registro de defectos. 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).3.2. la informaci´on debe ser lo mas completa posible.

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

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

˜ 3. Estimaci´on de tamano Para la estimaci´on de tama˜no se usa una plantilla.6.5: Ejemplo de plantilla de estimaci´on de tama˜no (tarea 6) 28 . la cual es suministrada por: Carnegie Mellon University Figura 3.

7. listas y otros est´an en el orden apropiado.Manejar todas las condiciones de entradas incorrectas . incrementan y terminan de manera apropiada Comprobar todos los casos especiales: . . especificaciones y dise˜no de alto nivel: . Asegurar que el dise˜no cubre completamente los requerimientos. regresen lo esperado Verificar lo siguiente: . . Este chequeo debe llevarse a cabo antes de dar por finalizada la etapa correspondiente.Terminar la lista de comprobaci´on para cada apartado del programa antes de iniciar la siguiente.Revisar que el dise˜no cumpla con todos los est´andares de dise˜no que sean aplicables. El checklist nos proporciona un m´etodo controlado y repetible para mantener un control de calidad en nuestros dise˜nos.Verificar que todas las funciones. * La recursi´on regresa de manera apropiada. se˜nalar en la derecha. .Especificar el valor de inicio de cada variable.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. Design Review Checklist. . sobreflujo o bajoflujo. .Se generan todas las salidas especificadas. Comprobar que la secuencia del programa es la apropiada: * Las pilas. es la principal herramienta para mejorar la calidad de nuestros proyectos.Al terminar cada paso de la revisi´on.3. . 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 . .Verificar que todas las funciones.Verificar que todos los ciclos se inicializan.Asegurar la operaci´on apropiada de todas las variables definidas.Aseg´urar que las condiciones ”imposibles” sean absolutamente imposibles. procedimientos u objetos est´an completamente comprendidos y se usan de manera apropiada. 29 Program Unit Name .Todos los nombres de los objetos se usan dentro de sus alcances declarados. . .Protecci´on por condiciones fuera de los l´ımites.Se incluyen todas las entradas necesarias. . .

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

3. Figura 3. 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.9. Escenario operacional.6: Ejemplo de un escenario de operaci´on (Tarea 8) 31 .

10.3. 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. 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 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. Especificaci´on de estados Especifica los estados de cada objeto y la interacci´on entre los mismos. tama˜no.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. componente .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.size = 1 Lista ligada.

} otro caso { int tama˜no. Especificaci´on l´ogica Especifica la funcionalidad de cada objeto (Pseudo c´odigo). si(tama˜no==1) { lista resultado = lista ligada.componente). in pseudocode Lista OrdenaLista(Lista lista ligada. Logic reference numbers Program logic. } otro caso { si(tama˜no>1) { lista ordenada = lista ligada. int componente) { Lista lista resultado = null. } 34 . lista resultado = traelista.esvacia) { lista resultado = null. tama˜no = NumElementos(lista ligada). } } } retorna lista resultado.12.tama˜no. oredena(lista ordenada.3. si(lista ligada.

en este caso el de 2. 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. 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. 1. No entiendo claramente el llenado Project Plan Summary en el apartado de locs.El uso de la forma PIP. Propuesta de mejora de proceso (PIP) La forma PIP es un est´andar previamente dise˜nado para presentar propuestas de mejora al proceso PSP. esto en base al tipo de programa y como ser´a resuelto. 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. 35 . Dicha propuesta de mejora nace conforme obtengamos m´as experiencia y confianza al usar el PSP.la realizaci´on y puesta en practica de un Standard. Notes and Comments: Registro de lo aprendido del proceso: conteo de l´ıneas y el de codificaci´on.3. por falta o dudas sobre la realizaci´on de ella (espec´ıficamente la tabla de locs).13.1 Elements El uso de problemas ejemplo para tener una mayor practica en el uso y manejo de los guiones psp.

Calculo de LOCs/Hora 5.Pruebas automatizadas El promedio de errores por k/loc disminuyo. aunque aun cometo numerosos errores.Uso del PROBE. y todo lo que esto conlleva para poder hacer una estimaci´on mas cercana del tiempo. y todo lo que esto conlleva para poder hacer una estimaci´on mas cercana del tiempo. 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. 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 . 3. Se debe tomar un poco mas de tiempo para detallar correctamente el dise˜no conceptual. 4.Llenado de la plantilla de estimaci´on de tama˜no. as´ı mismo el dise˜no se debe de hacer con mas cuidado para no olvidar nada. Llenado de la BD de O personal para la estimaci´on de tama˜nos 2. siendo esto ya algo mas natural para hacer. 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. Notes and Comments: Registro de lo aprendido del proceso: 1. 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. 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.Student Instructor Process Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP0.R3 an´alisis de defectos Me siento actualmente mas c´omodo con le conteo de locs.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.

37 .1 Elements Date Program # 31/11/06 6A Problem Description: Problema en las pruebas. puesto que el error cometido fue muy dif´ıcil de observar y por lo tanto de corregir. La estimaci´on de locs nuevas a la base fue muy diferente al real.1 Elements Date Program # 26/11/06 5A Problem Description: Problema en la estimaci´on de numer´o de funciones por clase. aunque aun tengo que mejorar aun mas. Creo esta vez el tiempo utilizado en ellas fue mayor a cualquiera anterior. Notes and Comments: El tiempo empleado en pruebas fue casi igual al de la codificaci´on. 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. Notes and Comments: Registro de lo aprendido del proceso: 1. 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. Student Instructor Process PIP Number 1 2 2 Propoal PIP Number 1 2 Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP1. 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.Student Instructor Process PIP Number 1 Propoal PIP Number 1 Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP1. se debe dise˜nar con mas calma y explicar con mas detalle lo que se hara en busca de cometer menos errores. creo que este m´etodo de codificaci´on si el uso de otras herramientas me ha servido para mejorar esto.CPI (el ´ındice de costo-desempe˜no) El promedio de errores por k/loc disminuyo.

1 Elements Date Program # 8A Problem Description: Los ejemplos para el uso de las nuevas plantillas son muy reducidos.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. 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. 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 . Propoal PIP Number 1 Proposal Description Revisar el proceso de nuevo par alimentar los nuevos conocimientos.

1. para tener una idea mas concreta de su utilizaci´on.1 Elements Date Program # 10A Problem Description: El uso del t´emplate de State Specification queda aun poco claro.1.Omit´ı el uso del t´emplate de state specification y de Functional Specification 39 .Student Instructor Process Chi˜nas Vega Daniel Castro Careaga Luis Fernando PSP2. 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. Propoal PIP Number 01 Proposal Description Un ejemplo completo del desarrollo de esta plantilla para una mejor comprensi´on.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. Notes and Comments: En esta tarea se utilizo PSP 2. Propoal PIP Number Proposal Description Un ejemplo detallado del t´emplate y un detallado escenario de uso para ese t´emplate.

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 . 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.3.14.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.

3. R4 Report Plan Summary Figura 3.8: 41 .15.

16.3. se tomo algunos d´ıas para corregir los errores de las hojas R3 y R4 del archivo de Excel Fin del desarrollo Postmorten terminada . 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.

17. si bien a partir del programa 3A la estimaci´on de tama˜no a sido sobre estimada. En el programa 2A se debe a la falta de una planeacion correcta.17.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. Reporte R4 3.3.1. de eso se desprende el que la estimaci´on fuera mayor a lo real.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. en el 6A alcanza un valor considerable. 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. 43 . Figura 3. aun cuando el programa 6A tenia una mayor complejidad con respecto a sus antecesores. lo cual en el programa 6A disminuye. esto se debe al poco tiempo que le dedico a la planeacion y al dise˜no. Analice la tendencia en la exactitud de estimaci´on de tamano Figura 3. An´alisis de la Exactitud de Estimaci´on de Loc ˜ en los primeros seis programas.

¿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. si bien en el 5A esta iba disminuyendo en el 6A esta aumenta considerablemente con respecto a lo anteriormente visto. 5 y 6. 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. si las LOC de objeto estimadas no est´an cercanas las LOC de objeto reales. Basado en el an´alisis anterior.11: Se nota una clara tendencia a la sobreestimaci´on. 44 . Para cada uno de los programa 4. as´ı como aprovechar mejor los datos hist´oricos con los que cuento para en base a ellos llevar a cabo mi planificaci´on. 5 y 6.Para cada uno de los programa 4. ¿c´omo se comparan las LOC de objeto estimadas con las LOC de objeto reales? Figura 3. determine por qu´e. Esto aumento en el programa 6A puesto que depend´ıa de mas m´etodos y por lo tanto el error fue mayor.

5) no se puede utilizar este procedimiento para calcular el estimado de tama˜no de un programa.0002841 De procedimiento.0118365 R2 0. Si Beta 0 no es cercana a cero o si Beta 1 no esta razonablemente cerca de 1. Figura 3. Examine las betas del m´etodo A.0 (entre 0. 45 .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.en base a esto no es posible usar estos valores para la estimaci´on de tama˜no. 3.42676 Range 203.05957 B0 210.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.42676 B1 0.De la hoja PROBE de su libro de trabajo del estudiante y ponga el selector del programa para el programa 7. ¿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.17.5 y 1.

era aun mejor que los tres primeros.13: Productividad Loc/hora para los primeros 6 programas Se nota una clara tendencia hacia la alta.14: 46 . es decir la productividad a mejorado puesto que en el programa 6A es 3 veces mayor que en el 2A .Para los primeros seis programas. ¿qu´e tan estable fue su productividad? Figura 3. si la productividad vari´o. Para los primeros seis programas. ¿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. se debe observar que en el 5A la productividad disminuyo con respecto al anterior.

00 % 0.00 % 0.00 % Test 0.20 % 2.00 % 87.00 % 9.10 % 0. 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.60 % 1.00 % 18.00 % 0.00 % 0.00 % 84. esto con respecto al programa 6A . Figura 3.00 % 0. por lo tanto la productividad a aumentado considerablemente.00 % 2. An´alisis de los defectos introd.70 % 0.60 % 11.10 % 0.00 % 9.20 % 18.50 % 9.16: Por lo visto en ambas gr´aficas no afecto ya que no siguen una misma tendencia en su crecimiento o ca´ıda.15: As´ı mismo el tiempo de compilaci´on a disminuido con respecto a anteriores programas.10 % 0. mientras que en test no existe una tendencia a aumentar a partir del programa 4A.00 % Code 0.00 % 3. ˜ ¿C´omo fue afectada la exactitud de sus estimados de tiempo por la calidad de sus estimados de tamano? Figura 3.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.10 % 0.00 % 0.20 % 0.00 % .10 % 0.20 % 11.De las dos graficas anteriores se nota una clara tendencia a la disminuci´on de defectos removidos en la compilaci´on. 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.20 % 0.10 % 0.00 % 10.00 % 0.00 % 22.00 % 0.10 % 0.00 % 45.00 % 0.00 % 55.

0 15.0 1.0 20.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*.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. 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.01 se debe mantener los valores doubles es decir 1.0 1.00 no 1 se cambio 1 por 1. es decir el de sintax esto debido en gran medida al poco cuidado que se le pone a la codificaci´on. 48 .0 10. puesto que algunas funciones son dise˜nadas o ampliamente modificadas de su dise˜no original en esta fase. ¿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.˜ ¿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.

¿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. Puesto que el compilador no me dejara avanzar mientras estos errores existan. 49 . 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 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. 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. esto es normal puesto no podremos compilar correctamente hasta haber escrito la syntaxi correctamente para cada instrucci´on.

fix time Tot. defects Avg. 50 . ¿Qu´e categor´ıa tiene el tiempo promedio de eliminaci´on m´as grande? El tiempo de eliminaci´on en test es mayor. Y eliminados por fase (R3).5 veces mayor. 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. defects Avg. esto debido en gran medida a que la mayor cantidad de errores son de sintaxis. fix time Tot. An´alisis de los defectos introd. defects Avg. los cuales son removidos en la fase de compilaci´on. 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. fix time Tot.3.3. 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. 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. 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. 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. fix time Tot.17.

4. Mitad del curso ´ Areas para mejorar y que cuentan con mayor prioridad para un mejor desempe˜no personal.0 falta ( ) en la evaluacio nde la funcion El cual podr´ıa ser m´as propiamente de asignaci´on. Al aumentar un poco de tiempo en esta a´ rea es decir poner mas atenci´on en los requerimientos que se me piden. puesto que la mayor´ıa de estos es debido a una mala sintaxis. 40 y 80 son encontrados mayoritariamente por el compilador. asignaci´on de tipos de variable es normal que esto suceda.3 % 0. Por lo tanto excluyendo este podr´ıamos decir que efectivamente encuentra todos los errores de tipo 20. esto debido en gran medida al poco tiempo que le doy. Productividad 51 . 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. lo que llevar a un menor tiempo en las fases de compilaci´on y pruebas.7 % 89. ¿El compilador encuentra todos sus defectos del tipo 20 (sintaxis / tipos)? No le falta un defecto. creo debo ser mas especifico en mis dise˜nos y dejar menos cosa ambiguas. 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. ˜ 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 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. Dise˜no En este apartado. Areas de prioridad para mejora en la 2da.5.0 % 66. ´ 3.5 % Analice la efectividad del compilador eliminando defectos por tipo de defecto Los tipos de defecto 20. el cual por lo visto hace muy bien su trabajo. as´ı el tiempo de codificaci´on ser´a menor y los errores introducidos disminuir´an.8 % 81.8 % 33.17.3. lo que mejorara mi desempe˜no.17. para poder hacer una mejor planeacion.

En base a lo anterior se espera aumentar mi productividad. 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. los m´etodos planeados para cada fase en forma de tablas. por lo cual el prop´osito seria mantenerla cercana a 60 para as´ı mejorar la productividad a la fecha que es de 36. 52 . 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.49. actual mente para el programa es 57. uno que cuente con cada una de las clases planeadas. a˜nadiendo al diagrama actualmente utilizado. 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.86.

R3 y R4 .Registrar tiempo de postmortem en timelog .Plan Summary completo .Poner metas cuantificables . Reporte R5 3.Reporte R5 completo .Registrar tiempo de desarrollo en time log .3.Estimar el esfuerzo basado en el tama˜no del reporte .1.Registrar tiempo de planeaci´on en time log.Estimar el tama˜no del reporte * Numero de parrafos de analisis * Numero de tablas/graficas a utilizar .Revisi´on del desenvolvimiento general . 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 .Time log completo 53 .18.Tareas 1A a 10A completos . .Darle formato .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 . R2.Revisi´on de metas pasadas .Registrar estimados en la forma Plan Summary .Identifcar areas en donde mejorar .18.Reportes R1.Medir tama˜no del reporte * Numero de tablas/gr´aficas * Numero de parrafos de analisis .Completar la forma Plan Summary .Student workbook (hoja excel) .Determinar cambios y proponer medidas al proceso .

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 .18.2.18.3.3. 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.

esto debido en gran parte a la madurez obtenida y el uso de una base de datos. An´alisis de la precisi´on de la estimaci´on de tamano Figura 3. que para la tarea 7A contaba ya con informaci´on suficientes para ayudarnos en la estimaci´on.˜ 3. 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).17: La estimaci´on de tama˜no para cada programa a partir de la segunda etapa. 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. An´alisis de estimaci´on de tiempo Figura 3.18. 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. Se nota una mejora clara con respecto a la primera parte del proceso.18: 55 . principalmente la revisi´on del dise˜no ayudo a una mejor estimaci´on del tama˜no.18.4. 3. una tendencia clara en las tareas 3A-10A. durante el cambio del proceso (Tareas 7A-10A) se mantuvo dentro del 70 % de efectividad (30 % en la grafica). 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.5.

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.6. 56 .18. en las primeras tres tareas de la segunda parte del proceso (7A-9A) esto debido al cambio en el proceso. al poder corregir de manera temprana los posibles errores que hubieran consumido m´as tiempo en etapas adelantadas del proceso.La estimaci´on de tiempo para cada Tarea resulto dentro del 70 % de efectividad (30 % en la grafica). 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. 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. creo necesitar´ıa de un par de tareas extras para desenvolverme mejor en el proceso con respecto a la estimaci´on de tiempo. Productividad Figura 3. 3. No se noto una mejora tan marcada como en el caso de la estimaci´on del tama˜no.19: La productividad se mantuvo por debajo de 60. 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.

00 % 11.30 % 8. 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.20 % 0.80 % 1.3.70 % 12.00 % 75.90 % 0.00 % 33. esto nos muestra cual importantes son las etapas de dise˜no y codificaci´on.18.00 % 4. seguidos de los de funci´on. de tal forma que reduzcamos estos errores.20: Es claro que la mayor cantidad en defectos son del tipo c´odigo. as´ı mismo es ah´ı donde se insertan las dos nuevas etapas de revisi´on.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.00 % 0.00 % Code 0.70 % 0.90 % 0.00 % 1. An´alisis de tipos de defectos Figura 3.70 % 6. de ah´ı la importancia de elaborar dise˜nos m´as claros y pseudoc´odigos m´as espec´ıficos.7.50 % 0.00 % 13. 57 .30 % 0.00 % 0.

8.3. Defectos removidos por fase Figura 3. Figura 3. 58 . 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. las cuales son de revisi´on.18.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.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.

lo que denota la clara mejora obtenida a partir de ellas y consecuentemente un mejor uso de ambas etapas para mejorar nuestro PSP.3. Rendimiento Figura 3.18.9.23: Es claro el aumento de locs revisadas por hora en ambas etapas nuevas. se necesitar´ıan de m´as datos para poder tener una opini´on relevante con respecto a esto. 59 . no se denota ninguna relaci´on con respecto a LOC/Hora.24: El rendimiento en la fase de revisi´on de dise˜no se muestra ambiguo. Figura 3.

la importancia de la etapa de codificaci´on y como esta afecta nuestro rendimiento es clara. la cantidad de locs afectara de manera directa nuestro rendimiento.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.Figura 3. Figura 3. 60 . debemos concentrarnos mas en esta etapa para poder mejorar el rendimiento.25: Es claro una tendencia a la disminuci´on en el rendimiento conforme aumentan las LOC a revisar por hora. esto denota la importancia de ambas 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.0.11. 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.0.10.Cap´ıtulo 4 Conclusiones al termino del proceso ( PSP ) ´ 4. de esta forma reducir´ıamos los errores y mejorar´ıamos nuestros tiempos de revisi´on. 61 . 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. 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. Areas para mejorar Dise˜no Revisi´on de dise˜no Codificaci´on Revisi´on de c´odigo Tiempo de revisi´on promedio Calidad 4. 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. en ellas debemos ser mas minuciosos de tal forma que reduzcamos los errores procedentes de las mismas.

62 . 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. as´ı el tiempo de codificaci´on ser´a menor y los errores introducidos disminuir´an.12. tendr´e una medida mas clara sobre si existe una mejora o no. Productividad En base a lo anterior se espera aumentar mi productividad.14. podre se˜nalar de manera confiable y basado en pruebas que tanto se ha mejorado.4. Tiempo Figura 4. de esta manera aumentare la calidad y con lo anterior mente expuesto.0. por lo cual es justificado el hecho que el tiempo de desarrollo para las ultimas dos tareas aumentara significativamente. por lo cual el prop´osito seria mantenerla cercana a 60 para as´ı mejorar la productividad a la fecha que es de 36.86. 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. ˜ 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.13. Revisi´on de metas Estas fueron las metas propuestas en R4. 4. al igual que el tiempo de desarrollo a partir de la tarea numero 9. Calidad La Calidad es algo que se debe lograr en la medida que mejoren los puntos antes se˜nalados. creo debo ser mas especifico en mis dise˜nos y dejar menos cosas ambiguas. 4.1: En este punto es claro que el tama˜no de los programas realizados en cada tarea creci´o r´apidamente. que esperar´ıa fuera de 45 al terminar los proyectos de psp. de esta manera el desarrollo de mi trabajo mejorara. Dise˜no En este apartado. lo que mejorara mi desempe˜no.49. actual mente para el programa es 57.0.0. para poder hacer una mejor planeaci´on. lo que lleva a un menor tiempo en las fases de compilaci´on y pruebas.

2: El porcentaje de tiempo ocupado para la planeaci´on de cada tarea disminuyo considerablemente.15.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. 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. 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 . La meta se cumpli´o parcialmente aun necesito mejorar y tomar con mas importancia las etapas de planeaci´on.Figura 4.0. 4. Errores Figura 4.

˜ Planeaci´on y Diseno Siendo las dos etapas m´as importantes en el desarrollo de toda la tarea. puesto que las metas alcanzadas hasta ahora son satisfactorias como ya se explico anteriormente. 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.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. 64 .0. 4. Productividad Figura 4. puesto que quedaron detalles que faltaron mejorar se toman como metas a futuro las siguientes. 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.17. estimo dedicar m´as tiempo a desarrollar correctamente estas dos etapas.16. 4. Metas El proceso se mantendr´a igual. Errores Mantener la cantidad de errores en 4 k/loc Productividad Mantener una productividad superior a las 70 loc/hora siendo constantes.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. 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.0. 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.

Presentaci´on disponible en http://www.Bibliograf´ıa [1] acobson. 1998.com/uml como UMLconf. ”Applying UML in The Unified Process”Presentaci´on. I. Rational Software.rational.zip 65 .

66 .