Psp

`
UNIVERSIDAD AUTONOMA METROPOLITANA
IZTAPALAPA

´
DIVISION DE CIENCIAS BASICAS E INGENIER´
´ IA

´
LICENCIATURA EN COMPUTACION

REPORTE DE PROYECTO FINAL

Desarrollo del Proceso Persona de Software

˜
Daniel Chinas Vega

Asesor
Eduardo Rodr´guez Flores
ı

1

´
Indice general

1. Introducci´ n
o 3

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

3. Resultados 21
3.1. Formas, Plantillas y est´ ndares para su utilizaci´ n en PSP
a o . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Bit´ cora de Tiempo. . . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Registro de defectos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Est´ ndar de Conteo de LOCs de Java (R1) . . . . . . . .
a . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5. Java Standard de codificaci´ n (R2) . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6. Estimaci´ n de tama˜ o . . . . . . . . . . . . . . . . . . .
o n . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7. Design Review Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8. Code Review Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.9. Escenario operacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10. Especificaci´ n funcional . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . . . . 31
3.11. Especificaci´ n de estados . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . . . . 32
3.12. Especificaci´ n l´ gica . . . . . . . . . . . . . . . . . . .
o o . . . . . . . . . . . . . . . . . . . . . . . . 33
3.13. Propuesta de mejora de proceso (PIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.14. Reporte de la mitad del Proceso (R4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.15. R4 Report Plan Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.16. R4 Time Recording Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.17. Reporte R4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2

3.17.1. An´ lisis de la Exactitud de Estimaci´ n de Loc . . . . . . . . . .
a o . . . . . . . . . . . . . . . . 42
3.17.2. An´ lisis de la Exactitud de Estimaci´ n de Tiempo . . . . . . . .
a o . . . . . . . . . . . . . . . . 44
3.17.3. An´ lisis de los defectos introd. Y eliminados por fase (R3). . . .
a . . . . . . . . . . . . . . . . 49
3.17.4. An´ lisis de defectos encontrados por el compilador (tabla D24)
a . . . . . . . . . . . . . . . . 50
´
3.17.5. Areas de prioridad para mejora en la 2da. Mitad del curso . . . . . . . . . . . . . . . . . . . 50
3.18. Reporte R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.18.1. Reporte de ﬁnal de proceso (R5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.18.2. R5 Report Plan Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.18.3. R5 Time Recording Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.18.4. An´ lisis de la precisi´ n de la estimaci´ n de tama˜ o . . . . . . .
a o o n . . . . . . . . . . . . . . . . 54
3.18.5. An´ lisis de estimaci´ n de tiempo . . . . . . . . . . . . . . . .
a o . . . . . . . . . . . . . . . . 54
3.18.6. Productividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.18.7. An´ lisis de tipos de defectos . . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . . . 56
3.18.8. Defectos removidos por fase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.18.9. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4. Conclusiones al termino del proceso ( PSP ) 60
´
4.0.10. Areas para mejorar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.0.11. Medidas para mejorar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.0.12. Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.0.13. Revisi´ n de metas . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.0.14. Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.0.15. Errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.0.16. Productividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.0.17. Metas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3

Cap´tulo 1
ı

Introducci´ n
o

Software.

Es el conjunto de los programas de c´ mputo, procedimientos, reglas, documentaci´ n y datos asociados que
o o
forman parte de las operaciones de un sistema de computaci´ n.[IEEE]
o
Tomando como punto de partida esta definici´ n, el software es la suma de diferentes componentes y por tanto para
o
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´ metros, indicadores o criterios de medici´ n tom´ ndose el resultado de evaluaci´ n m´ s bajo
a o a o a
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´ todos y procesos que nos permitan mantener una adecuada calidad en la
e
totalidad del software.

Ingenierá al software.
ı

La aplicaci´ n de un enfoque sistem´ tico, disciplinado y cuantificable al desarrollo operaci´ n (funcionamien-
o a o
to) y mantenimiento del software. [IEEE, 1993]
Bajo este contexto la ingenierá de software es una disciplina cuyo fin es la creaci´ n de software de la m´ s alta calidad.
ı o a
Haciendo uso de procesos cuantificables y repetibles.

Proceso de ingenierá de software
ı

Un conjunto de etapas parcialmente ordenadas con la intenci´ n de logra un objetivo, en este caso, la obten-
o
ci´ n de un producto de software de calidad [Jacobson 1998].
o
En vista de los conceptos antes mencionados es importante el contar con un proceso adecuado que nos lleve a la real-
izaci´ n de un software de alta calidad.
o

PSP
Proceso Personal de Software (PSP, por sus siglas en ingl´ s PERSONAL SOFTWARE PROCESS). PSP es
e
un proceso de auto mejoramiento de la calidad de software, nos proporciona una estructura con guás y procedimientos
ı
para el desarrollo de un proceso, que tenga como finalidad la creaci´ n de software de calidad.
o
Como ya habámos mencionado la calidad del software es el resultado de evaluaci´ n de calidad m´ s bajo de
ı o a
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´ ndares
a

El PSP es una lńea de trabajo de medici´ n y an´ lisis para ayudar a caracterizar un proceso. Tambi´ n es un
ı o a e
procedimiento definido que le ayuda a mejorar el desempe˜ o.
n

R 2002 por Carnegie Mellon University.

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

El PSP proporciona:

Una base probada para desarrollar y practicar disciplinas personales de uso avanzado.
Una disciplina que muestra c´ mo mejorar el proceso personal.
o

Los datos para mejorar continuamente la productividad, calidad y la predicci´ n del trabajo
o

Un PSP estable y maduro permite:

Estimar y planear el trabajo.
Cumplir con los compromisos.
Resistir presiones por compromisos no razonables.

5

Tambi´ n:
e
Se comprender´ n las habilidades actuales para desarrollar software.
a
Se estar´ mejor equipado para mejorar la habilidad para desarrollar software
a
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´ n de nuestro desempe˜ o.
o n
PSP1: Planiﬁcaci´ n del tama˜ o, uso de recursos y tiempo de desarrollo.
o n
PSP2: Administraci´ n de defectos y rendimiento (yield)
o
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˜ o.
n
Incorporar medidas b´ sicas en el proceso de desarrollo de software.
a

PSP 0 es simple y definido, usando los m´ todos con los que actualmente dise˜ amos y desarrollamos nuestro
e n
software.
Se recolectan datos sobre el trabajo realizado, tiempo utilizado por fase y defectos encontrados en la compi-
laci´ n y pruebas.
o
Se hace uso de una bit´ cora para el registro de los tiempos y de una bit´ cora para el reporte de los defectos,
a a
se usa un est´ ndar de defectos para llevar un control de los mismos.
a

2.2.1. Tarea 1
Creaci´ n de un programa que calcule la media y la desviaci´ n est´ ndar de una serie de n n´ meros reales,
o o a u
usando una lista ligada para almacenar los n n´ meros a usar en los c´ lculos.
u a

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

Hay dos nuevos elementos del proceso.
La forma de propuesta de mejora de proceso (PIP).
Est´ ndares de conteo ( R1 )y codificaci´ n ( R2 ).
a o

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

Los est´ ndares de codificaci´ n y conteo son necesarios para escribir los programas PSP, deben ser ajustados
a o
al lenguaje que usemos para codificar. De forma que el conteo de LOC sea m´ s f´ cil. LOC son elementos de lenguaje
a a
mńimos para llevar a cabo una operaci´ n completa (l´ gico) o elementos f´sicos como podrán ser palabras, para el
ı o o ı ı
dise˜ o de mi est´ ndar de conteo eleg´ el tipo l´ gico.
n a ı o

7

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

2.3.2. Tarea 3
Creaci´ n de un programa que cuente las LOC l´ gicas totales de un programa, las LOC l´ gicas en cada objeto
o o o
o funci´ n y el n´ mero total de m´ todos de cada objeto, tendr´ como salida el conteo de LOC totales, el conteo separado
o u e a
de LOC y el de m´ todos.
e

2.4. Reporte de an´ lisis de defectos R3
a
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´ n y pruebas.
o
Tiempo promedio de correcci´ n de defectos por fase de introducci´ n y eliminaci´ n.
o o o

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˜ o
n
del software.

2.5.1. Tarea 4
Creaci´ n de un programa para calcular los par´ metros de regresi´ n lineal b0 y b1 para n conjunto de datos,
o a o
se usara la lista ligada de la tarea 1 para el almacenamiento de los datos.
La f´ rmula del par´ metro de regresi´ n b0 es
o a o

b0 = yavg - b1xavg

8

La f´ rmula del par´ metro de regresi´ n b1 es
o a o

Figura 2.3:

2.6. PSP 1.1
Objetivos

Los objetivos del PSP 1.1 son introducir y practicar m´ todos para:
e

Hacer planes de recursos y de calendario de trabajo.
Seguir el desempe˜ o contra estos planes.
n
Juzgar la probabilidad de las fechas de terminaci´ n del proyecto.
o

2.6.1. Tarea 5
Creaci´ n de un programa para resolver una integral de una funci´ n num´ ricamente, usando la regla de simp-
o o e
son para una funci´ n de distribuci´ n normal, deber´ ser dise˜ ado para integrar usando varias funciones proporcionadas.
o o a n

La regla de Simpson.

Figura 2.4:

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

9

Para calcular el intervalo de predicci´ n, utilizar los siguientes pasos.
o

1. Leer los datos hist´ ricos, x’s y y’s.
o
2. Calcular B0 y B1.
3. Leer el estimado, xk.
4. Calcular a proyecci´ n como yk= B0 + B1 * xk.
o
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´ rmula para calcular el rango de predicci´ n es
o o

Figura 2.5:

Donde:

x son los datos hist´ ricos de tama˜ o de objeto.
o n
n es el n´ mero de puntos de los datos hist´ ricos.
u o
t70(2/α, dof ) es la distribuci´ n t de dos colas de 70 % para n - 2 grados de libertad (dof).
o

Sigma es la desviaci´ n est´ ndar de la regresi´ n lineal de los datos.
o a o

Figura 2.6:

10

Donde

x son los datos hist´ ricos de tama˜ o de objetos.
o n
y son los LOC nuevas y modificadas hist´ ricas (para tama˜ o) o tiempo (para esfuerzo).
o n
n es el n´ mero de puntos de datos hist´ ricos.
u o

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´ n es demasiado bajo, escoger un l´mite superior de prueba m´ s grande.
o ı a
• Si el resultado de la integraci´ n es demasiado alto, escoger un l´mite superior m´ s peque˜ o.
o ı a n

Hacer integraciones de prueba sucesivas hasta que el valor de la integraci´ n est´ dentro de un error aceptable,
o e
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´ lculo es usar los siguientes ocho puntos.
a

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´ dentro del error aceptable; si no continuar.
a
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´ todo para ajustar d podrá resultar en un valor de prueba de t = 0. Para protegerse contra
e ı
este problema con el m´ todo de Simpson, se debe asegurar que el programa manejar´ un valor 0 de la funci´ n que
e a o
est´ siendo integrada.
a

11

2.7. Reporte de mitad de proceso R4
Objetivos

Los objetivos d este reporte son:

Comprender los principios de la medici´ n y an´ lisis de procesos.
o a
Ganar experiencia en la definici´ n de un proceso para su uso propio.
o
Aprender a analizar los datos del proceso.
Comprender el proceso de referencia y c´ mo ha cambiado durante el curso.
o
Establecer metas medibles y definir las acciones de mejora correspondientes.

Para este reporte se debe dise˜ ar:
n

Un proceso para analizar los datos del PSP y para producir un reporte.
Se debe incluir en este proceso las fases de planeaci´ n y de postmortem.
o
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´ lisis para la exactitud de la estimaci´ n de tama˜ o y c´ mo ha evolucionado durante los programas desar-
a o n o
rollados a la fecha.
Un an´ lisis para la exactitud de la estimaci´ n de tiempo y c´ mo ha evolucionado durante los programas desar-
a o o
rollados a la fecha.
Un an´ lisis de los tipos de defectos introducidos y eliminados para los programas desarrollados a la fecha (tabla
a
D23, p´ gina 773).
a
Un an´ lisis de los defectos encontrados por el compilador (tabla D24, p´ gina 773).
a a
Un an´ lisis de los tiempo de correcci´ n de defectos, R3.
a o
Una descripci´ n de las areas de m´ s alta prioridad para la mejora personal, con su justificaci´ n.
o ´ a o

lo que se espera:

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

12

C´ mo mńimo, se deber´ n tomar los siguientes pasos para establecer los objetivos.
o ı a

Examinar los datos PSP para comprender el desempe˜ o actual.
n
Identificar las mejoras potenciales.
Priorizar las areas de mejora basandose en el peso potencial.
´
Conducir un an´ lisis para identificar las causas del desempe˜ o actual y establecer niveles de desempe˜ o futuro.
a n n
Identificar las acciones espec´ficas necesarias para lograr estos niveles de desempe˜ o.
ı n

2.8. PSP 2.0
Listas de revisi´ n de c´ digo y dise˜ o.
o o n
M´ todos para evaluar y probar lo acertado de nuestras revisiones. Se agregan al proceso:
e
Lista de chequeo de dise˜ o.
n
Lista de chequeo de codificaci´ n.
o

2.8.1. Tarea 7
Creaci´ n de un programa para calcular la correlaci´ n entre dos series de n´ mero y calcular la significancia
o o u
de esa correlaci´ n. Se hara uso de la rutina de integraci´ n de la tarea 5 para calcular los valores de la distribuci´ n t, se
o o o
almacenaran los datos en una lista ligada.

La correlaci´ n rxy puede ir de +1 to -1.
o

Cerca de +1 implica una fuerte relaci´ n positiva; cuando x se incrementa y se incrementa.
o
Cerca de -1 implica una fuerte relaci´ n negativa; cuando x se incrementa y se decrementa.
o
Cerca de 0 implica que no tienen relaci´ n.
o

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

Si r2 es La relaci´ n es
o
0,9 ≤ r2 Predictiva; usela con gran confianza.
´
0,7 ≤ r2 ¡ Fuerte y puede ser usada para planeaci´ n.
o
0,5 ≤ r2 ¡ Adecuada para planeaci´ n, pero con cuidado
o
r2 < 0,5 No es confiable para prop´ sitos de planeaci´ n
o o

13

Limitaciones de la Correlaci´ n
o

La correlaci´ n no implica causa y efecto.
o

Una fuerte correlaci´ n puede ser coincidental.
o

La f´ rmula para calcular el coeficiente de correlaci´ n r es:
o o

Figura 2.7:

Donde

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

La prueba de significancia determina la probabilidad que una correlaci´ n fuerte sea por casualidad y por lo
o
tanto no tenga significancia pr´ ctica.
a
Hay que recordar que una correlaci´ n fuerte puede ser s´ lo por coincidencia, especialmente cuando los datos son
o o
escasos. Por ejemplo, un conjunto de datos con s´ lo dos puntos siempre tendr´ r 2 = 1, pero esta correlaci´ n no es
o a o
significativa.

El c´ lculo de la significancia consiste de tres pasos:
a

1. Calcular el valor de t.

Figura 2.8:

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

14

2.9. PSP 2.1
Los objetivos del PSP2.1 son introducir:

Medidas adicionales para la administraci´ n de la calidad del proceso.
o
Plantillas de dise˜ o que proporcionan una l´nea de trabajo ordenada y formatos para registrar dise˜ os.
n ı n

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

2.9.2. Tarea 9
Creaci´ n de un programa que calcule el grado con el cual una cadena de n n´ meros reales est´ distribuido de
o u a
manera normal. Se usara la rutina de integraci´ n de la tarea 5 para calcular la distribuci´ n de c2. Supondremos una n
o o
¿20 y un m´ ltiplo par de 5 ( se puede suponer n = 50 ), se usara la rutina de ordenamiento de la tarea 8 para ordenar
u
de manera ascendente los n´ meros.
u

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

Esto es realizado al dividir la distribuci´ n normal en segmentos de area id´ nticos y comparar el n´ mero real de puntos
o ´ e u
del conjunto de datos que est´ siendo probado en cada segmento con el n´ mero de la distribuci´ n normal ideal.
a u o

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´ n est´ ndar, usando n-1.
o a

Figura 2.9:

Entonces, transformar cada xi a una zi normalizada.

Figura 2.10:

3. Dividir la distribuci´ n normal en algunos segmentos S, donde
o

15

n/S 3 5
S>3
S23 n
Para este problema, S=10 satisface estos requerimientos.
4. Determinar cu´ ntos elementos de la distribuci´ n normal caerán en cada segmento, Ni. Normalmente, esto es
a o ı
n/S; en este caso es 5.
5. Determinar cu´ ntos elementos del conjunto de datos normalizados caen en cada segmento, ki.
a
6. Calcular el valor Q para los segmentos.

Figura 2.11:

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

Figura 2.12:

Nota: La ecuaci´ n anterior para c2 difiere de la ecuaci´ n A7, p´ gina 518, por:
o o a
Sustituir dof por n.
Sustituir Q por x.
8. Calcular la cola de la distribuci´ n como 1-p.
o
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´ n de un programa para calcular los par´ metros de estimaci´ n de regresi´ n m´ ltiple de tres variables
o a o o u
(β0, β1, β2, andβ3).

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

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

16

La regresi´ n m´ ltiple proporciona una forma de estimar los efectos de m´ ltiples variables cuando no se tienen
o u u
datos separados para cada una de ellas.

Los 13 pasos se describen a continuaci´ n.
o

1. Utilizar la siguiente f´ rmula de regresi´ n m´ ltiple para calcular el valor estimado.
o o u

Figura 2.13:

2. Encontrar los par´ metros Beta resolviendo las siguientes ecuaciones lineales simult´ neas.
a a

Figura 2.14:

3. Cuando se calculen los valores de los t´ rminos, se obtendran las siguientes ecuaciones lineales simult´ neas.
e a

Figura 2.15:

17

4. Diagonalizar, utilizando el m´ todo de Gauss. Esto elimina de manera sucesiva un par´ metro a un tiempo de las
e a
ecuaciones mediante la multiplicaci´ n y resta sucesiva para dar lo siguiente.
o

Figura 2.16:

5. Resolver para los t´ rminos Beta.
e

Figura 2.17:

6. Determinar el intervalo de predicci´ n resolviendo para el rango con la siguiente ecuaci´ n.
o o

Figura 2.18:

7. Calcular la varianza como sigue.

Figura 2.19:

18

8. La varianza se eval´ a con lo siguiente.
u

Figura 2.20:

9. Los t´ rminos en la ra´z cuadrada son los siguientes.
e ı

Figura 2.21:

10. El valor de la distribuci´ n t para un intervalo de predicci´ n del 70 % es encontrado bajo la columna 85 % y dos
o o
´
grados de libertad en la tabla A2, p´ gina 489. El es 1.386.
a
11. La ra´z cuadrada se eval´ a de la siguiente manera.
ı u

Figura 2.22:

12. El estimado ﬁnal es:
z = 6.71+0.0784*650+0.0150*3,000+0.2461*155
z = 140.902 horas
13. El intervalo de predicci´ n de 38.846 horas signiﬁca que el estimado est´ entre 102.1 y 179.7 horas.
o a
Para resolver un sistema de N inc´ gnitas.
o
La eliminaci´ n Gaussiana es un algoritmo com´ n para resolver estas ecuaciones.
o u
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´ mero m´ s grande en la
u a
columna por debajo de la posici´ n I,I.)
o
3. IF P = 0 THEN SALIR (Si el resto de esta columna es cero, no existe una soluci´ n unica.)
o ´
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´ n
o
I,I.)
5. FOR J = I + 1 TO N + 1 ASIGNA AI , J = AI , J / AI , I (Coloca un 1 en la posici´ n I,I.) ASIGNA AI , I = 1.
o
6. FOR L = I + 1 to N multiplicar rengl´ n I por -AL , I y sumar a rengl´ n L (se colocan ceros a la columna por
o o
debajo de la posici´ n I,I.)
o
7. I = I + 1. IF I < N THEN IR AL PASO 2.
8. SALIR a sustituci´ n hacia atr´ s (¡Dise˜ o su propio algoritmo!)
o a n

19

2.10. R5: Reporte de An´ lisis del Proceso
a
Objetivos

Producir un reporte sobre lo que se aprendi´ en este curso que nos ayude a comprender nuestro desempe˜ o
o n
actual en el desarrollo de software y donde debemos mejorar.
Ganar experiencia en el establecimiento de metas medibles y en la detecci´ n de las acciones de mejora
o
correspondientes. Aprender a actualizar nuestro proceso personal.
Se actualizar´ el proceso usado en R4 para desarollar este reporte.
a

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´ hacer lo siguiente.
a

Analizar la exactitud en el estimado de tama˜ o y determinar el grado con el cual lo estimado estuvo dentro
n
de los intervalos estad´sticos de predicci´ n del 70 % y 90 %. Muestrar c´ mo la exactitud en la estimaci´ n del
ı o o o
tama˜ o ha evolucionado durante las tareas.
n
Analizar la exactitud en el estimado de tama˜ o y determinar el grado con el cual lo estimado estuvo dentro
n
de los intervalos estad´sticos de predicci´ n del 70 % y 90 %. Muestrar c´ mo la exactitud en la estimaci´ n del
ı o o o
tiempo ha evolucionado durante las tareas.
Analizar los tipos de defectos que se introducen en dise˜ o y codiﬁcaci´ n. Incluir un an´ lisis Pareto de estos
n o a
tipos de defectos. (Ver el Ap´ ndice A12 para una descripci´ n del procedimiento del an´ lisis de Pareto.)
e o a
Analizar las tendencias para defectos por KLOC encontrados en revisiones de dise˜ o, revisiones de c´ digo,
n o
compilaci´ n y pruebas.
o
Analizar las tendencias para los defectos totales por KLOC.
Analizar las tasas de eliminaci´ n de defectos para las revisiones de dise˜ o, revisiones de c´ digo, compilaci´ n
o n o o
versus pruebas unitarias. En aquellos casos donde no se tengan defectos, utilizar la tasa promedio de eliminaci´ n
o
de defectos de las pruebas unitarias
Analizar el rendimiento (yield) versus LOC revisadas por hora en las revisiones de c´ digo.
o
Analizar el rendimiento de la revisi´ n de dise˜ o versus las LOC revisadas por hora.
o n
Analizar el rendimiento versus el A/FR de los programas 7 al 10
Describir las areas de m´ s alta prioridad para la mejora del proceso personal y justiﬁcarlas. Aseg´ rando resumir
´ a u
el desempe˜ o actual, desempe˜ o futuro y metas de mejora. Describir c´ mo se intentan cumplir esas metas.
n n o

El dise˜ o de proceso debe incluir una:
n

Fase de planeaci´ n.
o
Fase de desarrollo.
Fase de postmortem.

20

El reporte debe incluir:

Todas las tablas y gr´ ficas requeridas, mas cualquier otra gr´ fica o datos que apoyen el an´ lisis.
a a a
An´ lisis y conclusiones por escrito.
a
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´ ndares para su utilizaci´ n en PSP
a o
Tabla de referencia

Figura 3.1: Tabla de referencia

22

3.2. Bit´ cora de Tiempo.
a
En ella registraremos cada una de las actividades que llevemos a cabo durante el lapso de tiempo que dedique-
mos a la realizaci´ n del proceso (Tareas).
o

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

3.3. Registro de defectos.
En esta se plasman la informaci´ n de defectos (errores) cometidos en la realizaci´ n de las tareas, la informa-
o o
ci´ n debe ser lo mas completa posible, el registro esta conformado por el numero de tarea donde se cometi´ , la fecha,
o o
el numero continuo, el tipo de error, tiempo de correcci´ n y una breve descripci´ n del mismo.
o o

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´ ndar de Conteo de LOCs de Java (R1)
a
Nombre de la definici´ n:
o Est´ ndar de LOCs de Java
a Lenguaje: Java
Autor: Daniel Chi˜ as vega
n Fecha: 07/10/06

Tipo de Conteo Tipo Comentarios
F´sico / L´ gico
ı o L´ gico
o
Tipo de Instrucci´ n
o Incluido Comentarios

Ejecutable Si
No ejecutable
Declaraciones Si, Nota 3
Directivas del compilador Si, Nota 4
Comentarios No
En lńeas propias
ı No
Con el fuente No
Encabezados No
Lńeas en blanco
ı No
Aclaraciones Ejemplos / Casos
Nulos continues, no-ops
Instrucciones vacás
ı Si ”;;”, ;’s solos, etc.
Intanciadores gen´ ricos
e
Begin...end Nota 1 cuando est´ n en c´ digo ejecutable
e o
Begin...end Nota 1 cuando est´ n en c´ digo no ejecutable
e o
Prueba de condiciones Si
Evaluaci´ n de expresiones
o Si Cuando se utilice como argumentos de subprogra-
mas
S´mbolos End
ı Notas 1 y 2 Cuando terminen instrucciones ejecutables
S´mbolos End
ı Notas 1 y 2 Cuando terminen declaraciones o cuerpos
else Nota 1
Palabras clave Si Divisi´ n de procedimientos, interfaz, imple-
o
mentaci´ n
o
Etiquetas Si Destinos de saltos cuando est´ n en lńeas sepa-
e ı
radas
Nota 1 A menos que sea seguido por un ; o incluido en
{ }, cuente una vez las siguientes palabras clave:
switch, case, if, else, do, while, for, private, public,
protected, try, catch.
Nota 2 Cuente una vez cada ocurrencia de: ;, ”{” . . . ”}”
Nota 3 Cuente una vez cada declaraci´ n de variable o de
o
par´ metro.
a
Nota 4 Cuente una vez cada instrucci´ n package e import.
o

25

3.5. Java Standard de codificaci´ n (R2)
o
Prop´ sito:
o Una guá para el desarrollo de programas en java
ı
Encabezado Comenzar todos los programas con un encabezado descriptivo.
Formato de /*************************************************************/
encabezado /* Asignaci´ n de programa: numero de programa
o */
/* Nombre: nombre del Desarrollador */
/* Fecha: Fecha de inicio del desarrollo del programa */
/* Descripci´ n:
o una peque˜ a descripci´ n del programa
n o */
/* y su funci´ n
o */
/*************************************************************/
Contenido del Proporcionar un resumen del contenido del listado fuente.
listado fuente
Ejemplo de /*************************************************************/
contenido /* Contenido del listado fuente: */
/* Instrucciones para su reutilizaci´ n
o */
/* Instrucciones para su modificaci´ no */
/* Instrucciones para su compilaci´ n
o */
/* Package */
/* Imports */
/* Nombre de la clase CData */
/* Declaraci´ n de Variables
o */
/* Instancias de clases */
/* Funciones y m´ todos
e */
/*************************************************************/
Instrucciones -Describe c´ mo se utiliza el programa. Proporciona el formato de declaraci´ n,
o o
de reuti- los valores y los tipos de par´ metro.
a
lizaci´ n
o - Proporcionar las advertencias para conocer los valores ilegales, las condi-
ciones de desbordamiento, o de otras condiciones que podrán potencialmente
ı
dar lugar a la operaci´ n incorrecta de la clase.
o

Ejemplo /*************************************************************/
de instruc- /* Instrucciones de reutilizaci´ n
o */
ciones de /* int PrintLine(char *cadena de caracteres) */
reutilizaci´ n
o /* Prop´ sito: para imprimir la secuencia, ”line of character”,
o */
/* en una lńea de impresi´ n a pantalla
ı o */
/* Limitaciones: El tama˜ o m´ ximo de lńea es
n a ı */
/* LONGITUD DE LINEA */
/* Devuelve : 0 si la lńea no se puede imprimir, caso contrario 1
ı */
/*************************************************************/
Identificadores Utilizar nombres que describan correctamente todas las variables, funciones,
constantes y otros identificadores. Evite el uso de abreviaturas o nombres de
una sola letra.
Ejemplo int numero de estudiantes; /* Bien */
de identifi- float X, j, fCad; /* Mal */
cadores

26

Java Standard de codificaci´ n (Continuaci´ n)
o o

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

27

˜
3.6. Estimaci´ n de tamano
o
Para la estimaci´ n de tama˜ o se usa una plantilla, la cual es suministrada por:
o n

Carnegie Mellon University

Figura 3.5: Ejemplo de plantilla de estimaci´ n de tama˜ o (tarea 6)
o n

28

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

PROGRAM NAME AND NUMBER

Purpose o o ˜
Guiarnos en la conducci´ n de una revisi´ n de diseno efectiva Program Unit Name
General - Al terminar cada paso de la revisi´ n, se˜ alar en la derecha.
o n
- Terminar la lista de comprobaci´ n para cada apartado del programa antes de
o
iniciar la siguiente.
Completo Asegurar que el dise˜ o cubre completamente los requerimientos, especifica-
n
ciones y dise˜ o de alto nivel:
n
- Se generan todas las salidas especificadas.
- Se incluyen todas las entradas necesarias.
L´ gica
o Comprobar que la secuencia del programa es la apropiada:
* Las pilas, listas y otros est´ n en el orden apropiado.
a
* La recursi´ n regresa de manera apropiada.
o
- Verificar que todos los ciclos se inicializan, incrementan y terminan de man-
era apropiada
Casos Espe- Comprobar todos los casos especiales:
ciales - Asegurar la operaci´ n apropiada de todas las variables definidas.
o
- Especificar el valor de inicio de cada variable.
- Protecci´ n por condiciones fuera de los l´mites, sobreflujo o bajoflujo.
o ı
- Aseg´ rar que las condiciones ”imposibles” sean absolutamente imposibles.
u
- Manejar todas las condiciones de entradas incorrectas
Uso Fun- - Verificar que todas las funciones, procedimientos u objetos est´ n completa-
a
cional mente comprendidos y se usan de manera apropiada.
- Verificar que todas las funciones, regresen lo esperado
Nombres Verificar lo siguiente:
- Todos los nombres y tipos especiales est´ n clara y espec´ficamente definidos.
a ı
- Los alcances de todas las variables y par´ metros son evidentes o est´ n
a a
definidos.
- Todos los nombres de los objetos se usan dentro de sus alcances declarados.
Est´ ndares
a - Revisar que el dise˜ o cumpla con todos los est´ ndares de dise˜ o que sean
n a n
aplicables.

29

3.8. Code Review Checklist
PROGRAM NAME AND NUMBER

Prop´ sito
o Guiarnos en la conducci´ n de una revisi´ n de c´ digo efectiva
o o o Program Unit Name
General - Conforme se termine cada paso de revisi´ n, compruebar el elemento en la
o
caja de la derecha.
- Terminar la lista de comprobaci´ n para cada apartado del programa antes de
o
iniciar la siguiente.
Completo - Verificar que el c´ digo cubre el dise˜ o.
o n
Import’s - Verificar que los imports est´ n completos.
a
Inicializaci´ n
o Comprobar la inicializaci´ n de variables y par´ metros:
o a
- Al inicio de la Clase.
- Al inicio de cada ciclo.
- En el inicio de cada funciones/procedimientos
Llamadas Comprobar los formatos de llamada a m´ todos:
e
- Par´ metros
a
Nombres Comprobar el uso y escritura de nombres:
- ¿Es consistente?
Los nombres de variables son consistente.
Las palabras reservadas est´ n correctamente escritas.
a
- ¿Est´ dentro del alcance declarado?
a
Formato de Comprobar el formato de salida:
Salida - ¿El espaciamiento de lńeas es el apropiado?
ı
- ¿El espaciamiento es el apropiado?
Parejas {} - Aseg´ rarse de que las {} son los apropiados y se corresponden.
u
- Aseg´ rarse de que los ( ) son los apropiados y se corresponden
u
Operadores - Verificar el uso apropiado de ==, =, ——, != y dem´ s. a
L´ gicos
o
Revisi´ n
o Comprobar cada LOC por
Lńea-por-
ı - Toda instrucci´ n termina en ;.
o
lńea
ı - Sintaxis de la instrucci´ n.
o
- Que la puntuaci´ n sea la apropiada.
o
Est´ ndares
a Aseg´ rar que el c´ digo se apega a los est´ ndares de codificaci´ n.
u o a o
Cierre y Verificar que todos los archivos est´ n:
a
Apertura de - declarados de manera apropiada,
Archivos - abiertos, y
- cerrados.

30

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

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

31

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

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

32

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

Student Chi˜ as Vega Daniel
n Date
Program Tarea 8 Program # 8A
Instructor Castro Careaga Luis Fernando Language Java
Object Lista ligada Routine Ordenamiento

State #1 Inicia Descripci´ n Checa nu-
o Attributes Lista ligada
mero de elementos en
la lista
Transition Conditions
Vacio Empty
Unico Lista ligada.size = 1
VariosElementos Lista ligada.size >1

State #2 Vacio Descripci´ n Lista sin
o Attributes Empty
elementos
Regresa null

State #3 Unico Descripci´ n Lista con
o Attributes
un elemento Lista ligada.size
=1
Termina Return lista ligada

State #4 VariosElemen- Descripci´ n Lista con
o Attributes
tos m´ s de un elemento
a Lista ligada.size
>1
Termina Lista ordenada <-
setOrdenamientoIn-
sercionDirecta (
lista ligada)

State #5 Ordena Descripci´ n Ordena la
o Attributes
lista de manera ascen- Lista ordenada,
dente tama˜ o, componente
n
Termina Return lista ordenada

33

3.12. Especiﬁcaci´ n l´ gica
o o
Especiﬁca la funcionalidad de cada objeto (Pseudo c´ digo).
o

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

34

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

PIP ( tarea 2 a la 10 )

n Date 08/10/06
Instructor Castro Careaga Luis Fernando Program # 2A
Process PSP0.1 Elements

PIP Number Problem Description:
1 1 Consumo de tiempo en la lectura para la posterior aplicaci´ n de el gui´ n de trabajo de
o o
psp
2 Constantes pausas en la realizaci´ n de la fase postmorten, por falta o dudas sobre la
o
realizaci´ n de ella (espec´ficamente la tabla de locs).
o ı
2 La estimaci´ n de lńeas de c´ digo ( L´ gicas ) resulto demasiado alejada de lo real
o ı o o

Propoal PIP Proposal Description
Number
1 1 El uso de problemas ejemplo para tener una mayor practica en el uso y manejo de los
guiones psp,
2 La utilizaci´ n de ejemplos que nos den una mayor practica en el llenado de las es-
o
tad´sticas de el proceso PSP
ı
2 Se debe tener mas cuidado en la estimaci´ n de locs, esto en base al tipo de programa
o
y como ser´ resuelto.
a

Notes and Comments:
Registro de lo aprendido del proceso: 1.la realizaci´ n y puesta en practica de un Standard, en este caso el de
o
conteo de lńeas y el de codificaci´ n.
ı o
2.El uso de la forma PIP.
No entiendo claramente el llenado Project Plan Summary en el apartado de locs.

35

n Date 21/10/06

1 La estimaci´ n de tiempo quedo bastante peque˜ a en comparaci´ n a lo real
o n o
2 Dise˜ o conceptual incompleto, se anexo una clase mas durante el dise˜ o de algoritmo
n n

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

Notes and Comments:
Registro de lo aprendido del proceso: 1.aproximaci´ n a una estimaci´ n en el tama˜ o de un programa a realizar
o o n
2.R3 an´ lisis de defectos
a
Me siento actualmente mas c´ modo con le conteo de locs, siendo esto ya algo mas natural para hacer.
o

n Date 10/11/06

1 Se debe tener en cuenta un mayor detalle a la hora de la planeaci´ n para definir con
o
menor margen de error la estimaci´ n de los m´ todos que se agregaran clases ya exis-
o e
tentes.

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

Notes and Comments:
Registro de lo aprendido del proceso: 1. Llenado de la BD de O personal para la estimaci´ n de tama˜ os
o n
2.Llenado de la plantilla de estimaci´ n de tama˜ o.
o n
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´ n en el editor de texto me ha ayudado a cometer meno errores cada vez que codifico algo nuevo
o

36

n Date 26/11/06

1 Problema en la estimaci´ n de numer´ de funciones por clase.
o o

Number
1 Hacer una planificaci´ n mas especifica y a su vez ir pensando en las posibilidades para
o
satisfacer los requerimientos para as´ lograr una mejor estimaci´ n.
ı o

Notes and Comments:
Registro de lo aprendido del proceso: 1.CPI (el ńdice de costo-desempe˜ o)
ı n

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

n Date 31/11/06

1 Problema en las pruebas. Creo esta vez el tiempo utilizado en ellas fue mayor a
cualquiera anterior.
2 La estimaci´ n de locs nuevas a la base fue muy diferente al real.
o
2 La estimaci´ n de lńeas de c´ digo ( L´ gicas ) resulto demasiado alejada de lo real
o ı o o

Number
1 Dar un poco mas tiempo a la planeacion y a la codificaci´ n, a favor de generar un
o
programa mas limpio de errores y que cumpla con su cometido
2 En la etapa de dise˜ o tomar en cuenta lo que planeamos hacer en cada clase para
n
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´ n, puesto que el error cometido fue muy difćil
o ı
de observar y por lo tanto de corregir, se debe dise˜ ar con mas calma y explicar con mas detalle lo que se hara en
n
busca de cometer menos errores.

37

n Date 05/02/07
Process PSP2 Elements

1 Confusi´ n en el llenado de algunos campos de los nuevos que se agregaron.
o

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

Notes and Comments:

Registro de lo aprendido 1 uso de listas de comprobaci´ n
o

n Date

01 Los ejemplos para el uso de las nuevas plantillas son muy reducidos.

Number
01 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˜ o
n

38

n Date

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

Number
01 Un ejemplo completo del desarrollo de esta plantilla para una mejor comprensi´ n.
o

Notes and Comments:

El uso de las 4 nuevas plantillas para mejorar el proceso de dise˜ o
n

n Date

El uso del t´ mplate de State Specification queda aun poco claro.
e

Number
Un ejemplo detallado del t´ mplate y un detallado escenario de uso para ese t´ mplate,
e e
para tener una idea mas concreta de su utilizaci´ n.
o

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

39

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

Phase # Purpose To guide the analysis and writing of the R4 Report
Criterio de entrada 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
Planning Estimaci´ n de esfuerzo para la fase de planeacion ( en minutos )
o
Estimaci´ n del tama˜ o del reporte
o n
Numero de p´ rrafos
a
Numero de graficas analizadas
Registrar las siguientes estimaciones;
Estimaci´ n de esfuerzo en base a la estimaci´ n de tama˜ o ( en minutos )
o o n
Estimaci´ n de esfuerzo para las fases del reporte siguientes
o
Registrar el tiempo de planeacion en el time log
Por cada pregunta del an´ lisis entregue lo siguiente
a
An´ lisis general de la tabla o grafica usada
a
Analizar el proceso/datos de la tabla o grafica
Escribir el p´ rrafo del an´ lisis
a a
Identificar areas de mejora
´
Determinar metas
Determinar si alg´ n proceso necesita cambios
u
Escribir el an´ lisis de mejora del funcionamiento
a
Escribir el tiempo de desarrollo en el time log
Postmortem Escriba el informe de tama˜ o del reporte (por pregunta)
n
# de tablas
# de graficas
# de p´ rrafos
a
Escriba el tiempo de post morten en el time log
Exit Criteria Completo el reporte R4
Completo el reporte de planificaci´ n o
Completo el timelog

40

3.15. R4 Report Plan Summary

Figura 3.8:

41

Psp

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (19)

Similar a Psp

Similar a Psp (20)

Psp