Académique Documents
Professionnel Documents
Culture Documents
IZTAPALAPA
LICENCIATURA EN COMPUTACION
INTRODUCCION:
Las computadoras se han convertido en una herramienta muy importante en la vida del
ser humano, es utilizada prcticamente en cualquier rea de trabajo. El desarrollo del ser
humano en la actualidad se encuentra ligado al uso de las computadoras. Con ella
podemos realizar problemas que anteriormente eran muy difciles de resolver, sin la
utilizacin de este equipo.
A medida que la tecnologa avanza, nos hemos vuelto a la necesidad de crear nuevas
formas en la realizacin de un sistema, para de este modo aumentar la calidad de dicho
producto y facilitarnos cada vez la forma en la que se debe realizar.
Afortunadamente han sido creadas buenas herramientas y procesos, ya que si se quiere
desarrollar un sistema muy grande y no se lleva a cabo un diseo estructural, podramos
perdernos en alguno de los mdulos y no saber ha ciencia cierta que es lo que estamos
realizando, o interpretar mal lo que el cliente quiere que realice su sistema, esta es una
de las razones por lo cual existen proyectos que se cancelan ya que o bien no se llevo un
control en el desarrollo del sistema o el cliente no estuvo satisfecho con dicho sistema,
por que no cumpla con las especificaciones que se tenan para la finalidad y el uso que
se tenia contemplado, a pesar que el sistema probablemente funcionara muy bien.
De que forma podemos evitar estos problemas y hacernos la vida ms fcil?
Gracias a la ingeniera de software
Pero en que consiste?
La Ingeniera de software es la rama de la ingeniera que crea y mantiene las
aplicaciones de software aplicando tecnologas y prcticas de las ciencias
computacionales, manejo de proyectos, ingeniera, el mbito de la aplicacin, y otros
campos. Es relativamente nueva ya que surge a finales de las anos 60s.
Comienza con una serie de tareas que hacen modelos y que resultan en una
especificacin completa de requisitos y una representacin comprensiva de diseo del
software que ser construido. Despus de varias pruebas utilizando diversos mtodos, es
opto por hacer un estndar a los mtodos Orientados o Objetos (OO).
La ingeniera de software requiere llevar a cabo una serie de tareas, sobre todo las
siguientes:
Anlisis de requisitos: Es la primera etapa para crear el programa. El cliente especifica
que es lo que quiere que el sistema realice.
Especificacin: Es la tarea de describir detalladamente el software a ser escrito.
Diseo y arquitectura: Se refiere a determinar como funcionar de forma general sin
entrar en detalles.
Programacin: Es esta fase se empieza codificar el diseo.
Prueba: Se comprueba que el software realice las tareas para el cual fue diseado, se
recomienda probar por separado cada mdulo y ver que funciona correctamente.
Documentacin: Realizacin del manual de usuario, y posiblemente un manual tcnico
con el propsito de mantenimiento futuro y ampliaciones al sistema.
Modelo en cascada
Modelo en espiral
Modelo de prototipos
Mtodo en V
INDICE GENERAL
OBJETIVOS................1
1. PSP....2
2. DESCRIPCION DEL PROCESO.....5
2.1 PSP 0...5
2.2 PSP 0.15
2.3 PSP 1.. 6
2.4 PSP 1.16
2.5 PSP 2...6
2.6 PSP 2.17
2.7 PSP 3...7
3. TAREAS REALIZADAS DURANTE EL PROCESO PSP8
3.1 TAREA 1A.8
3.2 TAREA 2A....9
3.3 TAREA 3A....9
3.4 TAREA 4A....9
3.5 TAREA 5A..11
3.6 TAREA 6A..13
3.7 TAREA 7A..16
3.8 TAREA 8A..18
3.9 TAREA 9A..18
3.10 TAREA 10A...20
4. FORMAS UTILIZADAS EN PSP...................................................23
4.1 DESCRIPCION GRAL DE FORMAS Y PLANTILLAS....24
4.1.1 FORMAS DEL RESUMEN DEL PLAN DE PROYECTO....24
4.1.2 BITACORA DE REGISTRO DE TIEMPO..24
4.1.3 BITACORA DE REGISTRO DE DEFECTOS..24
4.1.4 ESTANDAR DE TIPO DE EFECTOS....25
4.1.5 PIP..25
4.1.6 ESTNDAR DE CONTEO DE LOC (R1). ..26
4.1.7 ESTNDAR DE CODIFICACIN (R2).26
4.1.8 PLANTILLA DE REPORTE DE PRUEBAS....26
4.1.9 PLANTILLA DE ESTIMACION DE TAMAO (Size Estimate).26
4.1.10 PLANTILLA METODO PROBE27
4.1.11 LISTA DE CHEQUEO DE REVISION DE DISEO.27
4.1.12 LISTA DE CHEQUEO DE REVISON DE CODIGO.27
4.1.13 PLANTILLA DEL ESCENARIO OPERACIONAL..27
OBJETIVOS:
Aprender a utilizar cada una de las plantillas que proporciona el PSP para la
realizacin de cada programa.
Familiarizarse con cada uno de los pasos que sigue el PSP para aplicar esta
metodologa en el desarrollo de programas o sistemas posteriores.
1 PSP
El PSP es un Proceso Personal para desarrollar Software, principalmente se divide en tres
partes que son las siguientes:
Pasos Definidos
Formas
Estndares
Requerimientos
Planeacin
Diseo
gua
Guiones
Codificacin
Bitcoras
Compilacin
Resumen
del
Proyecto
Pruebas
PM
Producto terminado
Reporte de resumen de
Datos del proyecto y del
Proceso
Como podemos ver en la figura 1.1, PSP sigue una lnea de trabajo estructurada, dividida
en una serie de fases, cada una de las fases es consecuencia de la anterior y el flujo solo es
hacia una direccin. Durante la fase de planeacin el alumno desarrolla el modelo
conceptual, que es la base para la construccin de cada uno de los mtodos de la realizacin
del sistema o programa.
Al entrar en la fase de Diseo se crean o disean cada uno de los mtodos del programa, en
base a la fase de planeacin. nicamente se disea en papel, no se puede utilizar un editor
de texto, ya que as esta estipulado el rea de trabajo en la fase de diseo.
Durante la fase de compilacin se corrigen todos los errores encontrados en el programa y
se apuntan en una plantilla, donde cada defecto o error tiene un tipo especificado.
Una vez corregido todos los defectos del programa se procede ha hacer una serie de
pruebas, para ver que nuestro programa este funcionando de una forma eficiente, a como se
tena contemplado.
Por ltimo tenemos el resumen del plan de proyecto, que es otra plantilla donde aparecen
los tiempos de desarrollo, el nmero de defectos encontrados, el tamao del programa, una
serie de datos, que van aumentando conforme va avanzando el proceso.
Durante cada una de las fases se lleva una bitcora, donde se toman los tiempos que se
tardo el alumno en la realizacin de cada fase. As como tambin una serie de plantillas.
Ms adelante se mencionar el funcionamiento de este tipo de bitcora y plantillas
utilizadas durante todo el desarrollo de nuestro programa o sistema.
El principal objetivo del PSP es ayudar a los ingenieros de software a realizar mejor su
trabajo. Tambin esta diseado para demostrar el valor de utilizar procesos definidos y
medidos.
Finalmente, el PSP esta pensado para ayudar a los ingenieros y organizaciones a cumplir la
fuerte y creciente demanda por los sistemas de software y calidad. Se aplica a tareas
personalmente estructuradas. Puede ser extendido para soportar el desarrollo de sistemas de
software de gran escala.
PSP esta diseado mediante una serie de 10 tareas1, donde en cada uno de ellas se van
incorporando nuevas plantillas, lo que hace que el proceso vaya hacindose ms robusto y
la documentacin aumente. Las variantes se mencionan a continuacin:
Ver seccin 3
PSP3
Proceso
personal cclico
Desarrollo Cclico
PSP2 .1
PSP2
Administracin
de Calidad Personal
Proceso de
Planeacin Personal
Diseo de Plantillas
Revisiones de Cdigo
Revisiones de Diseo
PSP1 .1
PSP1
Estimacin de Tamao
Reporte de Pruebas
Planeacin de Tareas
Planeacin de Calendario
PSP0 .1
Proceso Personal
de Referencia
PSP0
Estndar de Cdigo
Medicin de Tamao
Propuesta de Mejora de Procesos (PIP)
Proceso Actual
Registro de Tiempo
Registro de Defectos
Estndar de Tipos de Defectos
2.3 PSP 1
El Objetivo de PSP1 es establecer un procedimiento ordenado y repetido para el desarrollo
de estimacin de tamao. La tarea 4A es la nica que se realiza durante esta variacin de
PSP.
Los nuevos elementos introducidos en el PSP1 son:
El mtodo de Estimacin de tamao PROBE
La plantilla de Estimacin de tamao
La plantilla de reporte de pruebas
2.5 PSP 2
Los objetivos de PSP2 son introducir:
Las revisiones de diseo y cdigo
Mtodos para la evaluacin y mejora de calidad de sus revisiones
Se incorporan dos nuevos elementos al proceso:
Lista de comprobacin de la revisin de diseo del PSP2
Lista de comprobacin de la revisin de cdigo
2.7 PSP 3
El PSP3 (cclico) proporciona una lnea de trabajo para el uso de una estrategia de
desarrollo cclico, para desarrollar programas de tamao modesto.
Los pasos de requerimientos, planeacin y postmortem del PSP, son realizados una sola vez
para el programa total.
El diseo de alto nivel particiona el programa en elementos ms pequeos y establece la
estrategia de desarrollo que determina los pasos cclicos.
(xi x med )
n
DesvEst. = =
i =1
n 1
donde:
es el smbolo para la desviacin estndar
es el smbolo para la sumatoria
i es un ndice para los n nmeros
Xmed es el valor promedio de los n nmeros
Las Listas ligadas son tipos de datos abstractos utilizados para almacenar conjuntos de
datos.
Las listas ligadas son construidas con apuntadores
Una lista ligada por lo regular tiene dos componentes:
Una cabeza de lista
El o los nodos de la lista
Algunas de las opciones para la estructura de una lista ligada son:
La cabeza de la lista puede apunta al primer nodo, al ltimo
o a ambos.
Un nodo de la lista puede apuntar al siguiente nodo, al
anterior o a ambos.
Los apuntadores nulos con frecuencia son utilizados para indicar una lista vaca o el final
de la lista
Las operaciones tpicas sobre una lista ligada incluyen:
Agregar un nodo
Eliminar un nodo
Ir al siguiente nodo
Ir al nodo anterior
8
3.2 TAREA 2A
Requerimientos del Programa 2A
Utilice el PSP0.1 para escribir un programa que cuente el total de LOCs lgicas en
un programa omitiendo los comentarios y las lneas en blanco.
Utilice su estndar de conteo (R1) y su estndar de codificacin (R2) para colocar
una lnea lgica en cada lnea fsica y cuente las lneas fsicas.
Produzca un conteo nico para el archivo de programa fuente.
Prueba completamente el programa. Como una prueba, cuente las LOCs en los
programas 1A y 2A.
3.3 TAREA 3A
Requerimientos del Programa 3A
Utilice el PSP0.1 para escribir un programa que cuente
Produzca e imprima
El conteo de LOCs para cada objeto o funcin junto con el
nombre del objeto o funcin
Para un lenguaje orientado a objetos, el nmero de mtodos
para cada objeto
Un conteo global para el archivo del programa fuente
Usted puede adecuar el programa 2A para hacer el programa 3A (sin embargo, mantenga
una copia del 2A).
Usted puede actualizar su estndar de conteo (R1) y su estndar de codificacin (R2) para
simplificar el diseo del programa 3A.
3.4 TAREA 4A
Requerimientos del Programa 4A
Utilice el PSP1 para escribir un programa que
Calcule los parmetros de regresin 0 y 1 de conjuntos de n datos.
Mejore la lista ligada desarrollada en el programa 1A para que almacene los
conjuntos de datos, donde cada conjunto de datos contiene exactamente dos
nmeros reales.
0 = yprom 1 xprom
La frmula para el parmetro de regresin es 1
n
1 =
x y
nx prom y prom
2
i
n(x prom )
i =1
x
i =1
0 = y prom 1 x prom
Pruebe completamente el programa. Como mnimo, use la tabla que se muestra a
continuacin para hacer los siguientes casos de prueba:
Utilice los datos de LOC de Objeto Estimadas (xi) y LOC
Nuevas y Modificadas Reales (yi)
Utilice los datos de LOC Nuevas y Modificadas Estimadas
(xi) y LOC Nuevas y Modificadas Reales (yi)
Tambin, utilizando sus propios datos, calcule los parmetros beta para las LOC nuevas y
modificadas estimadas (xi) y las LOC nuevas y modificadas reales (yi) para los programas
2A, 3A y 4A.
Programa
1
2
3
4
5
6
7
8
9
10
LOC de
Objeto Est
130
650
99
150
128
302
95
945
368
961
LOC N y M
Est
163
765
141
166
137
355
136
1206
433
1130
LOC N y M
Reales
186
699
132
272
291
331
199
1830
788
1601
10
3.5 TAREA 5A
Requerimientos del Programa 5A
Utilice PSP1.1 para escribir un programa que integre numricamente una funcin utilizando
la regla de Simpson y escriba la funcin que sea la distribucin normal.
El programa debe disearse para integrar utilizando varias funciones que sean
proporcionadas. Usted necesitar este programa para calcular los valores de las distintas
distribuciones estadsticas que se usan posteriormente en las tareas.
Pruebe completamente el programa. Como mnimo, use este programa para calcular los
valores de la integral de distribucin normal para tres valores.
Valor Esperado
Prueba
0.9938
- a 2.5
0.5793
- a 0.2
a -1.1
0.1357
Integracin Numrica
En principio la integracin numrica trata como si estuviese compuesta por varias reas
rectangulares.
Entonces suma estas reas para generar el valor de la integral
El truco es sumar estas reas de tal forma que se minimice el error.
Integrating a Function
x(low)
x(high)
11
F(u)du =
xlow
donde
W es el ancho de los segmentos
F es el valor de la funcin para cada valor de x
La regla de Simpson en otra forma
x high
F (u )du =
x low
W
3
N 1
N 2
(
)
(
)
F
x
4
F
x
iW
2 F ( xlow + iW ) + F (xhigh )
+
+
+
low
low
i =1, 3, 5...
i = 2 , 4 , 6...
Si el valor de X es
Positivo
0aX
Negativo
0 a abs(X)
( x) =
2
1
e u / 2 du
(2 )
12
3.6 TAREA 6A
Requerimientos del programa 6A
Ahora usando el formato para PSP 1.1 escribimos un programa para calcular los intervalos
de prediccin del 70% y del 90% de las LOCs nuevas y modificadas estimadas, dado un
conjunto de datos histricos de tamao y un estimado de LOC de objeto.
Intervalo de prediccin
El intervalo de prediccin proporciona un rango de probabilidad alrededor del estimado.
Un intervalo de prediccin de 70% da el rango dentro del cual caern el 70% de los
estimados.
No es un pronstico, solo una expectativa.
Solo aplica si el estimado se comporta como los datos histricos.
Se calcula a partir de los mismos datos utilizados para calcular los parmetros de regresin.
Par calcular el intervalo de prediccin, realizamos los siguientes pasos:
1. Lee los datos histricos xs y ys.
2. Calcule B0 y B1.
3. Lea su estimado Xk.
4. Calcule una proyeccin como Yk = B0 + B1*Xk.
5. Calcule el rango para un intervalo de 70%.
6. Calcule el UPI = Yk + Rango(70%).
7. Calcule el LPI = Yk - Rango(70%).
8. Repita los pasos 5 7 para el rango de 90%.
9. imprima sus resultados.
La frmula para el clculo del rango de prediccin es:
13
1
Range = t ( / 2, dof ) 1 + +
n
(x x )
(x x )
2
avg
i =1
avg
Donde
X es el tamao de los datos histricos
N es el nmero de puntos de los datos histricos
t(/2, dof) doble lados de la distribucin t para n - 2 grados de libertad.
La formula para calcular la desviacin estndar es:
= ( y i 0 1 xi )2
gl i =1
Donde
(n 1
(( n 1)]
t 70 ( a / 2 ,( n 2 ))
2
2
u
2
.35 =
du
1
+
0 (n 2)
1 / 2 ( n 2)
((n 2) * )
2
Donde
n es el nmero de miembros de x.
(x) = (x-1) (x-1), (1) = 1, y (1/2) = 1/2.
La distribucin t
La distribucin t
Es parecida a la distribucin normal.
Tiene colas muy gruesas.
Es usado en estimados de parmetros estadsticos para datos limitados.
14
Calculando el valor de t
Para calcular el valor de t(/2, n - 2).
Inicie con un valor de prueba de 1 para el limite superior y calcule el valor de la
integral.
Compare el resultado con el valor deseado
1. Si el resultado de la integracin es demasiado grande, tome un lmite superior de
prueba ms grande.
2. Si el resultado de la integracin es demasiado grande, tome un lmite superior ms
pequeo.
Haga la integracin de prueba sucesivas hasta que el valor de integracin est dentro de un
error aceptable, digamos 0.00001.
Para 70%, integre para tener 0.35 (0.85 0.5).
Para 90%, integre para tener 0.45 (0.95 0.5).
3.7 TAREA 7A
Requerimientos del programa 7A
Determine la correlacin y significancia entre las LOC nuevas y modificadas actuales y el
tiempo de desarrollo actual; as como la correlacin y significancia entre las LOCs nuevas
y modificadas y el tiempo de desarrollo de su histrico de datos personales.
Usando la correlacin
La correlacin rxy tiene un rango entre +1 y -1.
Cerca de +1 implica una fuerte relacin positiva, cuando x incrementa, y tambin.
Cerca de -1 implica una fuerte relacin negativa, cuando x incrementa, y
decrementa.
Cerca de 0 implica que no hay relacin.
La correlacin es usada en PSP para juzgar la calidad de la relacin linear entre varios
datos de procesos histricos, que son usados para la planeacin.
La relacin es
predictiva, usela con mayor confidencia
Fuerte y puede ser usada para planeacin
Adeacuada para planeacin, pero usela con cautela
No confiable para procesos de planeacin
16
Calculando la correlacin
La formula para calcular el coeficiente de correlacin r es
n
r(x,y ) =
i =1
i =1
n x i yi xi yi
i =1
n 2 n n 2 n 2
n xi xi n yi yi
i
=1
i
=1
i
=1
i =1
donde
x y y son los pares de conjunto de datos.
n es el nmero de esos miembros.
La prueba de significancia determina la probabilidad que una fuerte correlacin sea posible
y si tiene o no significancia prctica. Por ejemplo, un conjunto de solamente dos puntos
siempre tendr una r2 = 1 pero su correlacin No significante.
Calculando la significancia
El procedimiento para calcular la significancia de la correlacin es el siguiente:
1. Calcula t
t=
r(x, y) n 2
1 r(x, y )
Donde r es la correlacin
2
17
3.8 TAREA 8A
Requerimientos del programa 8A
Utilice PSP 2.1 para escribir un programa que ordene una lista ligada de n pares de
nmeros reales de forma ascendente. Proporcionando la capacidad de ordenar con respecto
a cualquier campo numrico.
Insercin sort
Existen muchos algoritmos para el ordenamiento de datos, pero la insercin sort puede ser
la ms simple para ordenar una lista ligada.
12
14
15
16
18
19
22
Se considera que se utilicen dos listas ligadas para la realizacin de la tarea, una lista
desordenada y una lista ordenada.
3.9 TAREA 9A
Requerimientos del programa 9A
Usando PSP2.1, escriba el programa 9A para calcular el grado al cual una cadena de n
nmeros reales es normalmente distribuida.
Use la rutina de integracin de Simpsons del programa 5A para calcular los valores
de la distribucin X2.
Asuma n > 20 y siempre un mltiplo de 5. (nota, se puede asumir n = 50).
Use el programa 8 para ordenar los nmeros de forma ascendente.
Prueba X2 para normalidad
La prueba X2 para normalidad determina que tan probable es que un conjunto de datos tenga
una distribucin normal. Se hace para comparar la estructura de un conjunto de datos con el
de una distribucin normal ideal.
Realizamos este dividiendo la distribucin normal en segmentos de igual rea y
comparando el actual nmero de puntos del conjunto de datos a probar con el esperado
nmero de una distribucin normal ideal.
18
1 n
(xi xavg )2
n 1 i =1
zi =
(x x )
i
avg
Q=
(N
i =1
ki )
Ni
7. Calcule la probabilidad p para las distribucin X2 para S 1 grados de libertad, para integrar
desde 0 a Q.
Q
dof 1
1
u
2
p = dof
u
e 2 du
2 2 dof 2 0
1. Use la siguiente formula de regresin mltiple, para calcular el valor del proyecto:
zk = 0 + wk 1 + x k 2 + yk 3
2. Encontrar los parmetros BETA resolviendo el siguiente sistema de ecuaciones
lineales:
n
i=1
i=1
i =1
0 n + 1 wi + 2 xi + 3 yi =
n
i =1
n
i =1
n
i =1
i =1
i =1
n
i=1
n
i=1
n
i =1
n
0 wi + 1 wi2 + 2 wi xi + 3 wi yi = wi zi
0 x i + 1 wi xi + 2 xi2 + 3 xi y i = x izi
i =1
n
i =1
n
i=1
n
i =1
i=1
i =1
0 yi + 1 wi yi + 2 x i yi + 3 yi2 = yi zi
i =1
i =1
0 = 6.7013
1 = 0.0784
2 = 0.0150
3 = 0.2461
2 =
(z 0 1wi 2x i 3yi )
n 4 i =1 i
= 2 = 513.058 = 22.651
9. Los trminos dentro de la raz cuadrada que determinan el rango son:
avg
avg
avg
avg
avg
avg
21
22
Formas, plantillas y
PSP0
estndares
Forma del Resumen del Plan Ver0
de Proyecto
Bitcora de registro de
X
Tiempo
Bitcora de Registro de
X
Defectos
Estndar de Tipos de
X
Defectos
PIP
Estndar de Codificacin
Estndar de Conteo de LOC
Plantilla de Reporte de
Pruebas
Plantilla de Estimacin de
tamao
Plantilla Mtodo PROBE
Lista de Chequeo de la Rev.
De Diseo
Lista de Chequeo de la Rev.
De Codificacin
Plantilla del Escenario
Operacional
Plantilla de la Especificacin
de Estados
Plantilla de Especificacin de
Lgica
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Documentacin
Sintaxis
30
Componentes o configuracin
40
50
Asignacin
Internas
60
70
80
Chequeo de Tipos
Datos
Funcin o lgicos
90
100
Sistema
Ambiente
Descripcin
Comentarios o mensajes
Ortografa, puntuacin, tipos, formatos de
instrucciones
Administracin de cambios, control de versiones,
bibliotecas
Declaracin, nombres duplicados, alcance, lmites
Llamadas y referencias a procedimientos, E/S,
formatos de usuarios
Mensajes de error, chequeos inadecuados
Estructura, contenido
Defectos por lgica, apuntadores, ciclos, reexcursin,
clculos, funciones
Configuracin, sincronizacin, memoria
Problemas de diseo, compilacin, prueba, u otros con
los sistemas de desarrollo
4.1.5 PIP
La Forma de Propuesta de Mejora de Proceso(PIP), tiene la finalidad de registrar los
problemas que se presentaron, durante la realizacin de cada tarea y proponer propuestas
de mejora para las tareas futuras. El PIP se introduce a partir de la tarea 3A
(PSP0.1).
Podemos poner cualquier sugerencia que se tenga para la mejora del proceso, cualquier tipo
de problema que se presento durante la realizacin del programa. As como tambin las
observaciones y descubrimientos que se presentaron durante la realizacin del ejercicio, y
algunas notas o comentarios, que nos pueden servir ms adelante conforme avanzamos en
el proceso, como una mejora personal en la realizacin de las tareas.
25
26
28
Comentarios
tipo
Fsico / Lgico
Tipo de Instruccin
Ejecutable
No ejecutable
Declaraciones
Directivas del compilador
Comentarios
En lneas propias
Con el fuente
Encabezados
Lneas en blanco
Aclaraciones
Nulos
Instrucciones vacas
Intanciadores genricos
Begin...end
Begin...end
Prueba de condiciones
Evaluacin de expresiones
Smbolos End
Smbolos End
Then, else, otherwise
Elseif
Palabras clave
Etiquetas
Nota 1
Nota 2
Nota 3
Nota 4
Incluido
Si
Si
Si, nota 1
Si
No
No
No
No
No
No
Si
Si, nota 3
Si, nota 3
Si
Si
No
No
Si, nota 4
Si, nota 4
No
No
Comentarios
Ejemplos / Casos
continues, no-ops
;;, ;s solos, etc.
cuando estn en cdigo ejecutable
cuando estn en cdigo no ejecutable
Cuando se use como argumentos de
subprogramas
Cuando terminen instrucciones ejecutables
Cuando terminen declaraciones o cuerpos
29
Instrucciones de
Reutilizacin
Ejemplo
/***************************************************
Nombre del programa: lexico.c
Autor: Capitaine Aggi Oscar
Materia: Proytecto de investigacin 1
Tarea: PSP2A
Fecha: **/**/****
Descripcin: Este programa cueta lineas de codigo
****************************************************/
Proporciona un resumen del contenido del listado.
/**********************************************
El archivo contienen los siguientes elementos
Funcion_1()
Funcion_2()
.
.
.
Funcion_n()
***********************************************/
nota: en caso de que sea una solo funcion no se
declara
el contenido
Describe cmo se usa el programa. Proporciona un formato de declaracin, tipos
y valores de parmetros y lmites de parmetros.
Proporciona advertencias de valores ilegales, condiciones de sobreflujo u otras
condiciones que podran resultar potencialmente en una operacin inadecuada.
/***************************************************
void lee_archivo(char nomarch{})
proposito: Esta funcion regresa el nombre de un
archivo
*****************************************************/
Identificadores
Ejemplo de
identificadores
30
Buen Comentario
Mal Comentario
Secciones Importantes
Ejemplo
Espacios en blanco
Sangras
if (carcter=={)
Las secciones importantes del programa deben estar precedidas por un
bloque de comentarios que describan el procesamiento que se hace en la
siguiente seccin.
/***
Esta funcion recibe una lista ligada y calcula la
media de una serie de numeros
****/
int media(nodo *lista)
Escriba programas con el suficiente espaciamiento tal que sean fciles de
leer.
Separe cada construccin del programa con al menos un espacio.
Coloque sangras en cada nivel de bloque con respecto al anterior.
Llaves que abren y cierran deben estar en una sola lnea y alineadas una con
la otra.
Ejemplo
Maysculas
Ejemplo de Maysculas
31
Defect Densities
Program
Number
New and
Changed LOC
Total Defects
Defects per
KLOC
Defects found
in compile
Compile
defects per
KLOC
Defects found
in test
Test defects
per KLOC
128
12
94
63
31
298
16
54
13
44
10
121
50
33
17
144
42
35
206
24
19
330
12
36
27
156
10
64
19
19
133
60
15
220
36
10
365
19
90
51
21
Totals
30
injected in
designing
Tot. defects
Avg. fix time
Defects
Total defects
found
93
123
15
22
13
59
41
100
injected in
coding
Tot. defects
Avg. fix time
28
34
Total
89
134
223
defects
injected
Tot. defects
Avg. fix time
43
13
56
10
32
Instructor
Fecha
Datos de Tamao
Objeto
Parrafos
Graficas
Tablas
Anlisis
de
Graficas /
Tablas
Prrafos
para el
Reporte
final
26/01/2006
Estimacin de Esfuerzo
Nmero
Planeado
18
16
9
Nmero
Real
18
14
6
Esfuerzo
Estimado
90
80
45
25
20
125
20
Total
Datos de Esfuerzo
Fase
Tiempo Plan.
Planeacin
20
Desarrollo
360
Post
15
Morten
Total
395
360
Tiempo Real
18
227
25
270
33
Fecha
Inicio
Alto
1/26/06
1/26/06
12:38
16:05
12:48
16:13
1/28/06
21:25
22:13
Fecha: 26/01/2006
Tiempo Tiempo
de
Efectivo
Interrup
cin
10
8
48
Fase
Plan
Plan
Desarrollo
1/29/06
21:44
22:35
51
Desarrollo
1/30/06
20:15
20:57
41
Desarrollo
Comentarios
Exitoso
Exitoso
Anlisis de la
Exactitud de
Estimacin de
LOC
Anlisis de la
Exactitud de
Estimacin de
Tiempo
Anlisis de los
Defectos
Introducidos y
Eliminados por
Fase
[D24]
1/31/06
18:37
1/31/06
20:12
2/02/06
11:37
2/02/06
15:39
19
Desarrollo
15
Desarrollo
12:30
53
Desarrollo
16:04
25
PostMorten
18:56
20:27
Anlisis de
Defectos
Introducidos y
Eliminados por
Fase [R3]
Anlisis de
Defectos
Encontrados
por el
Compilador
reas de ms
Alta Prioridad
para Mejoras
en la Segunda
Mitad del Curso
Exitoso
34
Propsito
Planeacin
Desarrollo
Postmortem
Exit Criteria
35
330
55,1282051
303
300
50
43,6018957
40
34,5830992
206
200
30
150
LOC
250
144
20
121
100
10
7,85817956
50
0
0
1
0
8
0
9
0
10
-10
Program Number
0
1
0
0
0
-1,77322360
6
7
8
9 10
Program Number
Como se pueden ver en las graficas, para la mayora de los programas, la estimacin en el
tamao ha sido buena, en el caso del programa 5 se puede ver que la grafica 2 muestra un
porcentaje negativo, en comparacin a los dems programas, al ser un programa un poco
complicado y no tener cdigo BASE, la estimacin fue calculada como en el primer
programa, al tanteo, pero a medida que se avanza gracias a la reutilizacin de cdigo y el
uso la tabla SIZE ESTIMATE del stuwbk, se puede tener un margen de estimacin de
tamao ms exacto.
2. Para cada uno de los programa 4, 5 y 6, cmo se comparan las LOC de objeto
estimadas con las LOC de objeto reales?
comparacion de locs
350
num. locs
300
250
200
locsestimadas
150
locs reales
100
50
0
4
num. programa
Para el programa 4 , la diferencia fue muy pequea, por que se trataba de un programa
pequeo, a pesar que en el programa 5 todo el cdigo fue nuevo, tambin se tuvo una buena
aproximacin, el programa 6 no tuvo una buena aproximacin, como podemos ver en la
grfica.
36
3. Para cada uno de los programa 4, 5 y 6, si las LOC de objeto estimadas no estn
cercanas las LOC de objeto reales, determine por qu.
El mayor problema fue en el programa 6, se tenia suficiente cdigo BASE pero tambin se
tuvo que realizar mucho cdigo nuevo, y no se tuvo una buena aproximacin, otra cosa que
influyo fue perder el ritmo de trabajo entre el programa 5 y el 6, ocasionando una mala
estimacin, como se ve en la grafica anterior, la diferencia es de un 30% aprox. Muy mala
en comparacin con los programas anteriores.
4. Basado en el anlisis anterior, cul es la mejor cosa que usted podra hacer para
mejorar su exactitud en la estimacin?
Hacer un anlisis detallado del programa que se va ha resolver, cada uno de los puntos
importantes, y ver los valores estadsticos de los programas anteriores para tener una mejor
aproximacin, de lo que se quiere estimar. La reutilizacin de cdigo tambin influye en
que tan buena sea la estimacin, ya que solo se crean algunos mdulos y es mucho ms
fcil estimar el tamao.
5. Vaya a la hoja PROBE de su libro de trabajo del estudiante y ponga el selector del
programa para el programa 7. Examine las betas del mtodo A. Son tiles para la
estimacin del programa 7? Explique por qu si o por qu no.
PROBE
Method
A
Size
Estimate
B
Time
Size
C
Time
Size
D
Time
Size
-13
60
55
0,93
-12,66
0,78
60,38
0,82
3,53
0,78
54,64
0,00
0,00
0,00
Beta1
Range (70%)
1,58
150
1,79
333
1,24
97
1,40
124
1,26
1,71
1,00
UPI
LPI
138
0
393
0
100
0
178
0
1233,16
35,12
6044,32
77,75
2102,79
45,86
3415,64
58,44
R-Squared
Beta0
Variance
Std. Deviation
Time
0,00
#DIV/0!
No, por que para poder utilizar el mtodo A debemos de tener una correlacin (R^2) mayor
a 0.7, una B1 entre 0.7 y 1.3 y una B0 relativamente pequea en comparacin de las LOCs
Estimadas. Si vemos la tabla del mtodo PROBE podemos darnos cuenta de que a pesar
que la correlacin se encuentra dentro del rango 0.93, la B1 esta fuera del rango 1.58, la B0
tiene un valor negativo lo que ocasionara una productividad negativa y nuestro Estimado
tambin es negativo.
El mtodo B tiene las mismas condiciones que el mtodo A, si observamos la tabla se
tieneR^2=0.82<0.7, B1=1.24 que es mayor a 0.7 y menor1.3 y nuestra B0=3.53 que es
relativamente pequea a nuestro estimado E=4.
37
Minutos
Estimacin de Esfuerzo
500
400
300
200
100
0
-100
T. Estimado
Tiempo Real
Error
1
Programas
Vemos que para los primeros dos programas la estimacin se encontraba en un rango, yo
considerara que es bueno, la grfica muestra que en programa 6, la estimacin fue muy
mala, debido a que no se tuvo un buen ritmo de trabajo y esto provoc que no se siguiera un
proceso equitativo, en cada una de las fases.
LOC/Hour
60
50
45.482389
44.6773902
41.4107805
39.5001524
40
30
26.572862
20
10
0
0
1
0
8
0
9
0
10
Program Number
38
Yo considero que mi productividad como muestra la grafica a sido estable, como podemos
ver en el programa 3 mi productividad bajo un poco en comparacin con los dems
programas, otra cosa que influye en la productividad es el grado de dificultad que tenga
cada programa y que tanto cdigo BASE se tenga para reutilizarse, tambin podemos ver
que para los programas 5 y 6 al parecer la productividad se mantiene estable. Esto se debe a
que conforme se avanza en el PSP uno tiene mejor control en sus programas y posee mayor
informacin para el desarrollo de sus programas.
3. Para los primeros seis programas, si la productividad vari, los cambios estn
relacionados con la cantidad de tiempo utilizando en corregir los defectos en las
fases de compilacin y pruebas?
% Compile Time
% Test Time
10
9
30
25
20
8
7
6
5
4
3
2
15
10
5
1
0
0
1
10
Program Number
10
Program Number
4. Cmo fue afectada la exactitud de sus estimados de tiempo por la calidad de sus
estimados de tamao?
Size Estimating Error
60
120
55,1282051
50
107,431373
100
43,6018957
40
80
34,5830992
30
56,86413153,3595241
60
20
40
10
7,85817956
0
-10
0
1
0
0
0
-1,77322360
5
6
7
8
9 10
Program Number
20
16,0198135
7,04320988
0
-20
-0,22959290
0
0
0
6
7
8
9 10
Program Number
39
%Error Tiempo
100
56.86
50
7.04
0
-50
16.01
43.6
55.12
7.85
53.35
-0.22
-1.77 34.58
%Error Tamao
Como podemos ver en las grficas, los picos muestran que se tuvieron un error de
estimacin de tamao y de estimacin de tiempo muy alto, lo que provoc que la calidad en
la exactitud fuera psima para las tareas 3 y 6. En la tercera grafica podemos apreciar que
mejor estos errores, podemos notar que las tareas 2 y 5 fueron las que mejor se estimo el
Tamao VS Tiempo.
La fase de compilacin y pruebas son las que afectan que ocurra esto, probablemente
nuestra estimacin en tamao fue mala.
num. Defectos
1
13
4
5
Como se puede ver en la grfica, la mayora de los defectos producidos son los de tipo 40
(Asignacin) y los de tipo 80 (funciones o lgicos). Lo que ocasion que existiesen muchos
defectos de tipo 40, fue que en el programa 2, no se definieron bien las variables de tipo
buffer para nuestro contador de LOCs y esto ocasion que existiesen demasiados errores
de este tipo.
40
num. Defectos
10
2
18
3
Como se podr ver en la grafica, los errores de asignacin (40), y los errores de sintaxis
(20), son los ms predominantes, durante esta fase. Tambin se presentan otros tipos de
errores como son los de componentes o configuracin (30) y los errores de funciones y
lgicos (80).
num. Defectos
10
2
23
3
2
Todos los defectos de sintaxis (20) son eliminados durante esta fase, en ninguna otra fase se
eliminan. Vemos que la mayora de los defectos de asignacin (40), tambin son
eliminados durante esta fase, al igual sucede con los de funciones o lgicos (80), los de
componentes o configuracin (30).
num.
Defectos
6
2
6
Al parecer durante esta fase, aun se siguen presentando los de funciones o lgicos (80),
de asignacin (40), pero en comparacin con la fase de compilacin es mucho menor, ya
que en la fase de compilacin, la mayora de ellos son filtrados, y solo un nmero pequeo
de ellos se presentan durante la fase de pruebas.
41
Defects
found in
testing
30
injected in
Tot. defects
designing
Defects
Total defects
found
93
123
14
22
12
59
41
100
injected in
Tot. defects
28
33
coding
Total
89
134
223
Defects
Tot. defects
43
13
55
Injected
10
En la tabla podemos ver que la mayor cantidad de defectos, son introducidos en la fase de
codificacin, pero se tarda un mayor tiempo en resolver los defectos que se introducen en el
diseo a pesar de que son menos.
80
50
20
30
10
60
70
90
100
42
Como se puede ver en la tabla, los defectos encontrados que tardan el mayor tiempo, en
resolverse son los defectos de tipo 40 (Asignacin). La fase en que se tarda el mayor
tiempo de resolverlos son durante la fase pruebas, ya que para resolver estos problemas
tenemos que ir haciendo watch, (en mi caso utiliz C++ ver. 3) para poder encontrar donde
se encuentra el error.
43
12
10
8
6
4
2
0
1
10
Program Number
Su desempeo actual
Como podemos ver en la grafica, la fase de planeacin no ha sido muy buena, sobre todo en
el programa 5 y el programa 6 se encuentran en un porcentaje de planeacin de un 16%
aproximadamente, en comparacin con los dems programas que estn entre un 6% y 8%.
Lo que provoca que el tiempo en esta fase en porcentaje con las dems (diseo,
codificacin, compilacin, pruebas y post morten), sea mayor. Lo ideal es que la fase de
planeacin no sea mayor a un 5%. Ya que no debe de tardar ms de 10 minutos en el
desarrollo de la misma.
Su desempeo futuro deseado
Una de mis principales metas es la de bajar el error de estimacin en el tiempo, esto es que
nuestro tiempo en planeacin no exceda los 10 minutos (no exceda el 5% de tiempo total de
desarrollo del programa) ya que tengo muchos problemas para hacer un clculo aproximado
de dicho error, comprender mejor el uso de la tabla SIZE ESTIMATE y ser ms
disciplinado.
Sus metas de mejora
Hacer un anlisis detallado de los requerimientos del programa y que no exedan de 10
minutos, para que la fase de diseo conceptual, se estimen bien el tamao de los mdulos,
otra propuesta es la de estimar cuantas LOCs contendr cada funcin de los mdulos, ya
que tengo un margen de 25% a 30% de error en cuanto al tamao de cada modulo. Para ser
mas preciso y ahorrar tiempo en las otras fases.
44
8.9.2 DISEO
Defects Injected in Design
35
Defects/KLOC
30
25
20
15
10
5
0
1
10
Program Number
Su desempeo actual
La grfica muestra que en el programa 5 no se tuvieron muchos errores en la fase de diseo (5
errores para ser exactos) en comparacin con la media que se mantiene en 20 errores por KLOC,
se puede decir que obtuvimos un gol, pero no es lo recomendable, lo ideal seria que la pendiente
negativa se fuera aproximando a cero paulatinamente, pero en este caso se ve muy drstico.
45
8.9.3 CODIFICACIN
Defects/KLOC
80
70
60
50
40
30
20
10
0
1
10
Program Number
Desempeo actual
La grfica muestra que el porcentaje de error se ha mantenido constante, con
aproximadamente 20 errores por KLOCs, aun as el porcentaje se considera alto lo que no
es muy bueno, ya que conforme se avanza en el PSP si estos errores no disminuyen, mi
productividad la cual esta en 43 LOC/Hora no se incrementara , o peor an puede
disminuir, como aparece en el plan de la tarea 7A que esta en 27 LOC/Hora a la Fecha.
Desempeo deseado
Lo que se espera en la segunda parte del PSP es la de disminuir los errores introducidos
durante esta fase, lo que podemos ver en la grfica anterior es que a pesar que los errores
durante todos los programas se mantiene constante, an siguen siendo altos, ya que tengo
un promedio de 36 errores por KLOCs, lo que espero es que se encuentre mximo de 20
errores por KLOCs.
Instructor
02/05/07
Date
Size Data
Effort Estimate
Object
Plan
Number
28
15
9
25
Prrafos
Graficas
Tablas
Anlisis
de
Graficas /
Tablas
Actual
Number
22
6
10
16
Est Effort
per Object
5
5
5
5
Estimated
Effort
140
125
45
125
Total
435
Effort Data
Phase
Planeacin
Desarrollo
Post
Mortem
Plan Time
10
320
15
Total
345
Actual Time
13
434
11
458
47
Date:
02/05/07
Fecha
Inicio
Alto
Tiempo
de
Interrupci
on
02/05/07
10:21:15
10:38:33
13.3
PLAN
02/06/07
10:13:39
13:07:08
173.5
DESARROLLO
02/07/07
02/08/07
10:36:21
10:37:15
13:15:12
11:33:13
158.9
56.0
DESARROLLO
DESARROLLO
02/09/07
11:35:01
12:20:45
45.7
DESARROLLO
EXITOSO
02/10/07
16:35:44
16:46:58
11.2
POST MORTEN
EXITOSO
Tiempo
Efectivo
Fase
Comentarios
EXITOSO
48
30
20
10
0
-10
10
-20
Program Number
Item:
Formulas
1
2
3
4
5
6
7
8
9
10
Totals
EstLoc
ActLoc
0
211
78
131.9343
209.2617
243.6118
173.2116
87.86986
169.5799
316.1508
1620.62
128
298
121
144
206
330
156
133
220
365
2101
No, como podemos ver en la tabla los errores de estimacin de tamao en la ltima parte
del proceso no fueron muy buenos a excepcin de la TAREA 7A, ya que se tuvo una
diferencia de 50 LOC aproximadamente por programa, en la grfica podemos constatar que
durante todo el proceso, la estimacin de tamao fue mi principal problema, el cual no pude
resolver. Lo nico bueno que puedo atribuirle a mi desempeo en esta parte del proceso, es
que al menos el error de estimacin de tamao se mantuvo constante durante las ultimas 3
tareas.
49
2. Qu tan frecuente se esta dentro del intervalo de prediccin estadstico del 70%
(90%)?
LOC Estimadas
UPI(70%) LPI(70%)
tarea 7
137
236
111
tarea 8
77
163
13
tarea 9
137
226
114
tarea 10
263
373
260
Como podemos ver en la tabla, todas las tareas estuvieron dentro del intervalo de
prediccin, se utilizo el mtodo B para la estimacin de tamao, lo curioso es que a pesar
de que se estuvo dentro del intervalo tuve un Error grande en cuanto al clculo de las LOC
Totales Reales de cada programa. Esto es debido a que el intervalo de prediccin, solo sirve
para calcular cual mtodo nos conviene ms para hacer la estimacin del tamao de un
programa.
3. Hay una tendencia a agregar o quitar objetos enteros?
NO, por que todos los objetos que se utilizaron fueron los necesarios para la realizacin de
cada uno de los programas.
4. Hay una tendencia a juzgar mal el tamao relativo de los objetos?
Si, ya que aun no se pudo definir una buena aproximacin en cuanto al tamao de los
mdulos, a pesar que se contaban con la ayuda de los datos histricos, creo que el mayor
problema fue que no supe interpretar bien los valores y hacer un buen uso de este material.
LOC Estimado
LOC Actual % Error
17
24
41.1764706 main
Tarea 7A
50
45
-10
correl
60
74
23.3333333 signif
10
13
30
imprime
15
23
53.3333333 main
Tarea 8A
45
78
73.3333333 ordena
7
19
171.428571 imprime
10
13
30
selec
12
22
83.3333333 main
Tarea 9A
7
11
57.1428571 imprime
25
29
16
distk2
13
23
76.9230769 normal
48
93
93.75
calculaQ
32
42
31.25
calculaP
28
64.7058824 main
Tarea 10A 17
90
127
41.1111111 calculos
55
93
69.0909091 rango
35
25
-28.5714286 calc_zk
30
36
20
desvia
20
26
30
imprime
50
tarea 7
tarea 8
tarea 9
tarea 10
Total
(N)
156
133
200
357
N&C LOC
Estimados
137
77
137
263
UPI(70%)
236
163
226
373
LPI(70%)
111
13
114
260
51
52
60
40
20
0
-20
10
Program Number
En la grafica se puede ver, que en comparacin con las primeras tareas el Error de
Estimacin de Tiempo bajo considerablemente, mantenindose entre un 15%-25%
del tamao real. Aunque no podemos considerarla muy buena pero al menos se mantuvo
constante en ese rango. En la tabla podemos ver para la TAREA 7A la estimacin de Error
fue buena en comparacin con las TAREA 8A y TAREA 9A
la mejor estimacin se presento durante la TAREA 10A ya que el error estimado es de
9.4%, esto quiere decir que se realizo el programa antes del tiempo propuesto.
Time Error
%
Formulas 0
1
7.04321
2
4.376543
3
106.2549
4
51.95974
5
16.31369
6
57.64492
7
14.75728
8
26.91608
9
21.47024
10
-9.44178
Totals
297.2948
53
2. Qu tan frecuente se esta dentro del intervalo de prediccin estadstico del 70%
(90%)?
tarea 7
tarea 8
tarea 9
tarea 10
Tiempo
Real
355
220
320
383
Tiempo
Estimado
309
173
263
401
UPI(70%)
437
261
329
474
LPI(70%)
224
85
198
328
Podemos ver que siempre estuve dentro de mi intervalo de prediccin con un margen de
error de 50-20 minutos y esto me dice que el tiempo en cuanto a la realizacin de las tareas
disminuyo, lo que contribuyo a tener una mejor estimacin para la realizacin de los
programas, otra cosa que fue de gran ayuda, fueron las revisiones de diseo y cdigo,
gracias a ellas se redujo considerablemente el tiempo en las fases de compilacin y pruebas.
LOC/Hour
60
50
40
30
20
10
0
1
10
Program Number
esto se logro gracias a las revisiones de Diseo y Cdigo, ya que la mayora de los errores
se corrigieron en estas Fases y se redujo el tiempo de correccin de errores en las fases de
Compilacin y Pruebas.
Productivity
LOC/Hour
0
26.57286
63.4455
41.41078
39.50015
44.67739
45.48239
26.39594
36.34707
41.26504
60.34443
42.96792
En lo que respecta a la estimacin de tiempo, no tuve gran problema, como podemos ver en
la tabla, que el % de Error para la segunda parte del proceso, se encuentra entre un 26% y
un 9%, lo cual es bueno. Para mi punto de vista lo ideal sera que este Error se encontrara
dentro del 10% al 5%, si vemos detalladamente la tabla se aprecia que el tiempo de
estimacin de Error aumento en la tarea 3A, 4A y 6A, esto incremento se debi, a que en
estas tareas se cambio el proceso y se incorporaron nuevas tablas y plantillas, como fueron
el mtodo PROBE, el SIZE ESTIMATE y las revisiones de diseo y cdigo. Esta parte fue
la que pude dominar ms, ya que el Error de estimacin disminuyo considerablemente en la
segunda parte del curso.
56
Diseo
1
0
19
4
3
1
13
41
Cdigo
13
4
24
1
1
0
5
48
La tabla muestra una descripcin detallada de los tipos de defectos que se presentaron a lo
largo del curso de PSP durante las fases de diseo y cdigo. Los errores que se presentaron
ms durante la fase de diseo, fueron los errores de asignacin (40), y los errores de
funciones y lgicos (80), son los ms predominantes durante esta fase. Para la fase de
Cdigo los defectos de sintaxis (20) son eliminados durante esta fase, en ninguna otra fase
se eliminan. Vemos que la mayora de los defectos de asignacin (40), tambin son
eliminados durante esta fase, al igual sucede con los de funciones o lgicos (80) y los de
componentes o configuracin (30). Podemos ver que se eliminan ms errores durante la
fase de cdigo que durante la fase de diseo.
20
Defects/KLOC
Defects/KLOC
25
15
10
5
14
12
10
8
6
4
2
Program Number
10
10
Program Number
57
Para las fases de compilacin y pruebas, gracias a las revisiones de diseo y cdigo, el
nmero de efectos disminuyo considerablemente, podemos ver en las graficas que el
nmero de defectos para la fase de compilacin disminuyo de 20 KLOCs a 7KLOCs para
la tarea 10A. Y para la fase de pruebas en los ltimos 3 programas se mantuvo un promedio
de 7 defectos/KLOC. Para finalizar la tendencia consiste en dejar cada vez menos defectos,
al pasar a una nueva fase, para aumentar la calidad del producto y el tiempo de desarrollo.
Defects Removed in Compile
35
70
30
60
Defects/KLOC
Defects/KLOC
25
20
15
10
5
50
40
30
20
10
0
1
10
Program Number
10
Program Number
Defects/KLOC
100
90
80
70
60
50
40
30
20
10
0
1
10
Program Number
58
Nm.
Defectos
Removidos
9
9
43 + 8=51
14 + 7 =21
90
Tasa de
Defectos
Removidos
10%
10%
56.6%
23.4%
100%
En la tabla podemos ver el nmero total de defectos removidos, en las cuatro fases de
revisin de diseo, cdigo, compilacin y pruebas. Para la segunda parte del proceso,
vemos que durante la fase de compilacin y pruebas, los defectos fueron mucho menores en
comparacin con los encontrados en las revisiones, 8 defectos para compilacin y 7
defectos para pruebas. El promedio general del Yield para las ltimas 4 tareas es de
54.55%, lo ideal debi ser que estuviera por arriba del 60%, pero se debi que durante la
tarea 7 el Yield fue del 40%, lo cual no fue muy bueno.
5. Cules son sus influencias de defectos removidos por Revisin de Diseo, Revisin
de Cdigo y Compilacin contra Pruebas Unitarias?
Debido a que las pruebas Unitarias son realizadas despus de las revisiones de Diseo y
cdigo, y una vez terminada la fase de compilacin, esto ocasiona que el nmero de
defectos encontrados durante la fase de pruebas disminuya considerablemente y sea mucho
menor, que los defectos encontrados en las fases anteriores.
6. Cules son sus tasas de revisin (en LOC revisadas/hora) para revisiones de diseo
y de cdigo?
Podemos ver en la grafica la tendencia de ir aumentando el nmero de LOCs revisadas por
hora durante las revisiones de diseo y cdigo.
59
LOC/Hour
500
450
400
350
300
Both
250
200
150
100
CDR
DLDR
50
0
1 2 3 4 5 6 7 8 9 1
Program Number
7
8
9
10
162.9243
265.7048
230.5006
430.3963
7. Hay alguna relacin entre el Yield y la tasa de revisin (en LOC revisadas/hora)
para revisiones de diseo y cdigo?
La relacin que se puede ver en la tabla es que a medida que aumenta el Yield aumenta el
nmero de LOCs de las revisiones por hora.
Programa
Tasa de Rev.
Ambas
DLDR VS CDR
7
8
9
10
162.9243
265.7048
230.5006
430.3963
183.5294
246.1697
224.6809
392.4731
86.30705
127.7822
113.7768
205.2804
Yield
actual
(%)
40
62.5
62.5
57.4
60
8. Hay una relacin entre el Yield y el A/FR para los programas del 7 al 10?
Podemos ver en ambas graficas que la relacin que hay entre el Yield y el A/FR, para la
segunda parte del proceso, es que a medida que aumentaba el Yield, tambin aumentaba el
A/FR.
Defect Removal Yield
60
35
Appraisal Cost %
70
Yield %
50
40
30
20
10
30
25
20
15
10
5
Program Number
10
10
Program Number
El Yield siempre crece a excepcin de la tarea 10A donde disminuyo un poco. Esto quiere
decir, que nuestro promedio del Yield se mantuvo arriba del 60%, provocando que la mayor
parte de los defectos se eliminaran antes de entrar a la fase de compilacin. Tambin
Podemos ver que el A/FR muestra una tendencia creciente, a excepcin de la tarea 8A, esto
nos dice que para la mayora de las tareas de la segunda parte del proceso los valores del
A/FR fueron mayores a 1 (4 para ser exacto). En consecuencia, durante las revisiones de
diseo y cdigo el tiempo fue mucho mayor al empleado durante las fases de compilacin y
pruebas.
61
Defects/KLOC
80
70
60
50
40
30
20
10
0
1
10
Program Number
Si, por que la finalidad era de reducir los Errores a menos de 20 defectos KLOCs, ya que
siempre me mantena un poco arriba de este margen, gracias a las revisiones de Diseo y
Cdigo pude entrar en lo recomendado, aunque me hubiera gustado estar en 10 Defectos
por KLOCs, pero no se pudo.
Yield %
50
40
30
20
10
0
1
10
Program Number
62
Si, para las ultimas 3 tareas el promedio del Yield se mantuvo en un 60%, esto quiere decir
que durante las revisiones de Diseo y de Cdigo se pudieron eliminar mas de la mitad de
los defectos de los programas, en mi caso de 23 defectos por KLOC puedo filtrar 15 en las
revisiones, lo que es un muy bueno por que se disminuye considerablemente las fases de
Compilacin y Pruebas.
Failure Cost %
35
30
25
20
15
10
5
0
1
10
Program Number
Los costos de los defectos de los ltimos programas adems del promedio de densidad
de defectos (19.75 Def/KLOC) de los ltimos 4 programas, nos dice que podemos estar por
debajo de esta densidad ya que la tendencia era a estar debajo de 20 Def/KLOC que es una
densidad aceptable. Una de mis metas seria estar debajo de los 10 Def/KLOC.
Esto incrementara considerablemente la calidad de mis programas, as como tambin la
productividad y el tiempo de realizacin.
Def. inj. in Code
Def/KLOC
0
78.125
23.48993
24.79339
20.83333
19.41748
18.18182
25.64103
22.55639
22.72727
8.219178
263.9848
63
64
CONCLUSIONES:
PSP es un proceso el cual una vez que te haz familiarizado, es muy fcil de utilizar.
Al principio cuando comenc a utilizar el proceso se me hacia muy difcil pero
conforme fui avanzando mis dudas fueron resolvindose. Prcticamente el proceso te
lleva de la mano durante el desarrollo de un sistema (software). Si tuviera la
oportunidad de desarrollar un sistema es muy probable que utilizara PSP para su
desarrollo. El proceso me ayudo a ser mas disciplinado y ver cuales son mis errores a la
hora de de iniciar un proyecto y poder corregir esos errores para no volverlos a cometer
durante el desarrollo del proyecto.
Una de las principales ventajas, que desde mi punto de vista, le veo al PSP, es que no
nicamente el proceso se puede utilizar para el desarrollo de sistemas, sino que tambin
podemos utilizarlo para desarrollar cualquier producto, el cual debe ser estructurado y
su tiempo de desarrollo se encuentra condicionado a cierta fecha de entrega.
En la actualidad en nuestro pas, existen muchas empresas de desarrollo de software,
pero no se si alguna de ellas utilice PSP o TSP para desarrollar sus sistemas. Una de los
principales problemas cuando los proyectos son cancelados es debido a que no son
diseados bien o el sistema no hace lo que el cliente desea. A pesar de que existen
mtodos para desarrollo de sistemas como UML o RUP creo que si utilizaran PSP o
TSP, sus productos tendran una mejor calidad y el tiempo de desarrollo de los sistemas
disminuira considerablemente.
BIBLIOGRAFIA:
[1] A Discipline for Software Engineering
Humphrey, Watts. S
Addison Wesley, 1996.