UNIVERSIDAD AUTONOMA METROPOLITANA

IZTAPALAPA

DIVISION DE CIENCIAS BASICAS E INGENIERIA

LICENCIATURA EN COMPUTACION

NOMBRE DEL PROYECTO:

DESARROLLO DE SISTEMAS UTILIZANDO PSP

NOMBRE DEL ALUMNO:

OSCAR CAPITAINE AGGI
MATRICULA:
98317250

NOMBRE DEL ASESOR:

ING. LUIS FERNANDO CASTRO CAREAGA

Mxico D.F. MAYO 2007

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.

Mantenimiento: Mantener y mejorar el software para enfrentar errores descubiertos y

nuevos requisitos.
La ingeniera de software tiene varios modelos o paradigmas de desarrollo en los cuales
se puede apoyar para la realizacin de software, de los cuales podemos destacar a stos
por ser los ms utilizados y los ms completos:

Modelo en cascada
Modelo en espiral
Modelo de prototipos
Mtodo en V

Por lo regular el ms utilizado de estos paradigmas es el modelo de cascada, ya que

considero en mi opinin es el mejor de todos de todos.
Al hablar de Ingeniera de Software tambin tendremos que hablar de UML, ya que se
encuentran estrechamente ligados en el desarrollo de sistemas de alta calidad.
UML1 ha emergido como una unificacin de los diversos mtodos orientados a objetos
y se est convirtiendo en un estndar.
El Lenguaje Unificado de Modelado es ahora el esquema de representacin grfica ms
utilizado para modelar sistemas orientados a objetos. Aquellos quienes disean sistemas
Utilizan el lenguaje (en forma de diagramas) para modelar sus sistemas.
Una de las caractersticas ms atractivas de UML es su flexibilidad. UML es extensible
e independiente de los diversos procesos de A/DOO. Los modeladores de UML tienen
la libertad de disear sistemas utilizando varios procesos, pero todos los desarrolladores
pueden ahora expresar esos diseos con un conjunto de notaciones estndar.
Una de las caractersticas de PSP, es que es muy parecido a la ingeniera de software, ya
que la mayora de sus fases son muy parecidas, ms adelanta se hablara en que consiste
el PSP y cual es su propsito en el desarrollo de sistemas de alta calidad.

Modelo unificado del lenguaje (Unified Modeling Language)

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

4.1.14 PLANTILLA DE ESPECIFICACION DE ESTADOS.28

4.1.15 PLANTILLA DE ESPECIFICACION LOGICA......28

5. PLANTILLA ESTANDAR DE CONTEO DE LOCs (R1).29

6. PLANTILLA ESTANDAR DE CODIFICACION R2 C....30
7. REPORTE DE ANALISIS DE DEFECTOS R3...32
8. REPORTE DE LA PRIMERA PARTE DEL PROCESO R4..33
8.1 RESUMEN DEL PLAN DE PROYECTO R433
8.2 BITACORA DE REGISTRO DE TIEMPO R4.........34
8.3 MUESTRA DE SCRIPT DEL PROCESO DEL REPORTE R4..35
8.4 ANALISIS DE LA EXACTITUD DE ESTIMACION DE LOC..36
8.5 ANALISIS DE LA EXACTITUD DE ESTIMACION DE TIEMPO38
8.6 ANALISIS DE LOS DEFECTOS INTRODUCIDOS Y ELIMINADOS
` POR FASE [Tabla D23]..40
8.7 ANALISIS DE LOS DEFECTOS INTRODUCIDOS Y ELIMINADOS
` [R3]...42
8.8 ANALISIS DE DEFECTOS ENCONTRADOS EN COMPILADOR..43
8.9 AREAS DE MAS ALTA PRIORIDAD PARA MEJORAS EN LA
` SEGUNDA MITAD DEL CURSO...44
8.9.1 PLANEACIN..44
8.9.2 DISEO....45
8.9.3 CODIFICACIN...46

9. REPORTE DE LA SEGUNDA PARTE DEL PROCESO R5..47

9.1 RESUMEN DEL PLAN REPORTE R5....47
9.2 BITACORA DE REGISTRO DE TIEMPO R5.....48
9.3 ANALISIS DE LA EXACTITUD DE ESTIMACION DE LOC..49
9.4 ANALISIS DE LA EXACTITUD DE ESTIMACION DE TIEMPO53
9.5 ANALISIS DE DEFECTOS Y YIELD......57
9.6 PREGUSNTAS SOBRE CALIDAD.62

OBJETIVOS:

Aprender a utilizar como se debe medir y analizar el Proceso personal de software

(PSP), para aumentar mi desempeo personal, en la realizacin de un sistema.

Aprender a desarrollar un programa mediante fases, trabajando de una manera

ordenada y eficiente individualmente.

Conocer el funcionamiento de la metodologa PSP para tener un mejor control en el

desarrollo de un producto de software.

Aprender a utilizar cada una de las plantillas que proporciona el PSP para la
realizacin de cada programa.

Tener una mejor estimacin en el desarrollo de programas mediante el uso de los

datos histricos que se proporcionan las plantillas.

Aumentar la calidad y productividad de un producto mediante la utilizacin de PSP,

para crear un software ms eficiente y con mejor calidad.

Reducir errores mediante las revisiones de diseo y cdigo, para disminuir el

tiempo de desarrollo de un programa.

Disminuir los errores en las fases de compilacin y pruebas para disminuir el

tiempo de desarrollo de un 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

Un PSP es una lnea de trabajo de medicin y anlisis para ayudarle a caracterizar su

Proceso.
Tambin es un procedimiento definido que le ayuda a mejorar su desempeo, de una
manera individual, ya que dicho proceso esta creado para que el alumno se desarrolle
productivamente de una forma personalizada. Basadas en prcticas de software industrial
reducidas.

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

Figura 1.1 El flujo del Proceso del PSP

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

El PSP se introduce en siete pasos compatibles y progresivos.

PSP0: Usted establece una lnea de base de desempeo.
PSP1: Usted hace planes sobre tamao, recursos y tiempo.
PSP2: Usted practica la administracin de defectos y del rendimiento (yield).
PSP3: Usted escala los mtodos de PSP a proyectos ms grandes.
La figura 1.2 nos detalla especficamente como estn estructuradas cada una de las
variantes del PSP. As como tambin las plantillas que se incorporan en cada una de estas
fases.
En la seccin 4.1 se detallan especficamente en que consiste cada una de las plantillas y
cual es su funcionalidad a lo largo del proceso.

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

Figura 1.2 Etapas del PSP

2 DESCRIPCION DEL PROCESO

2.1 PSP 0
El PSP 0 es un proceso simple y definido.
Utiliza sus mtodos actuales de diseo y desarrollo.
Los objetivos principales del PSP 0 son:
Demostrar el uso de proceso definido al escribir un programa pequeo
Incorporar medidas bsicas en el proceso de desarrollo de software
Requiere cambios mnimos a las practicas personales
Cuenta con una serie de elementos para facilitarnos la medicin de nuestros avances a lo
largo de la tarea 1A, la idea principal durante el PSP0 es incorporando poco a poco al
proceso, para familiarizarse de una manera fcil.
Para esta primera fase, los elementos necesarios son:
Strip de Proceso
Reporte de Plan de Proyecto
Bitcora de Registro de Tiempo
Bitcora de Registro de Defectos
Estndar de Tipo de Defectos

2.2 PSP 0.1

El PSP 0.1 tiene como finalidad medir el tamao del software para relacionar la cantidad de
producto generado con el esfuerzo empleado. As como tambin para calcular nuestra
productividad (medida en LOCs2), normalizar los defectos. Las tareas 2A y 3A se realizan
con este proceso.
Los objetivos principales del PSP 0.1 son:
Medir el tamao de los programas que usted produce
Contabilizar los tipos de LOCs en los programas que produzca
Realizar mediciones de tamao exactas y precisas
Introducimos una nueva serie de elementos al proceso:
La forma de propuesta de mejora del Proceso (PIP)
Estndar de Conteo (R1)
Estndar de Codificacin (R2)

Lneas de Cdigo (Line of code)

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.4 PSP 1.1

Los Objetivos del PSP1.1 son introducir y practicar mtodos para:
Realizar planes de recursos y de calendarios de trabajo
Darle seguimiento a su desempeo en cuanto a sus planes
Juzgar la probabilidad de las fechas de terminacin del proyecto
Se incorporan nuevos elementos al proceso:
Plantilla de planeacin de tareas
Plantilla de planeacin de calendario de trabajo
Por lo regular estas plantillas se utilizan para proyectos que tardan varios das o semanas.
No se utilizaran durante las tareas de PSP.
El resumen del plan de proyecto se expandi para que incluya estadsticas bsicas del
proceso. Las tareas 5A y 6A son las realizadas con estas modificaciones al PSP.

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.6 PSP 2.1

Los objetivos del PSP2.1 son introducir.
Introducir mtricas adicionales para la administracin de la calidad
Plantillas de diseo que proporcionen una lnea de trabajo ordenado y formatos para
documentar los diseos
Existen cuatro nuevos elementos del proceso:
Lista de comprobacin de la revisin de diseo PSP2.1
Plantilla del escenario operacional
Plantilla de especificacin de estados
Plantilla de especificacin lgica
Las tareas 8A, 9A y 10A se realizan con este proceso.

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.

3 TAREAS REALIZADAS DURANTE EL PROCESO PSP

3.1 TAREA 1A
Requerimientos del Programa 1A
Calcule la media y la desviacin estndar de una serie de n nmeros reales.
Su programa debe leer los n nmeros reales de un teclado, un archivo, etc.
Utilice una lista ligada para almacenar los n nmeros durante los clculos.
La media es el promedio de n nmeros.
La desviacin estndar se calcula de la siguiente manera:

(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

El total de LOCs lgicas en un programa

El total de LOCs lgicas en un objeto o funcin
Para un lenguaje orientado a objetos, el nmero de mtodos en cada objeto

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.

Calculando los Parmetros de Regresin

La frmula para el parmetro de regresin 0 es:

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)

Para determinar los lmites de integracin

La mayora de las funciones estadsticas se integran de - a algn valor
Todas las funciones estadsticas tienen un rea total de 1.0 cuando se integran de a +

11

La regla de Simpson para calcular la integral es

xhigh

F(u)du =

xlow

W F(xlow) + 4F(xlow +W) + 2F(xlow + 2W) + 4F(xlow + 3W)K

2F(xhigh 2W) + 4F(xhigh W) + f (xhigh)

3

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

donde N es el nmero de segmentos

Con funciones simtricas (las distribuciones normal t), el procedimiento es este.

Si el valor de X es

Entonces integre desde

Positivo

0aX

sume 0.5 a los resultados

Negativo

0 a abs(X)

reste el resultado de 0.5

La frmula de la distribucin normal es

x

( x) =

2
1
e u / 2 du
(2 )

Inicie con N = 20 y un error aceptable (E) de 1E-07.

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.

Usamos la regla de integracin de Simpson del programa 5 para calcular el valor de

la distribucin t.
Use una lista ligada para almacenar los datos histricos.

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

X son los datos histricos de tamao estimado de objetos.

Y son los datos histricos de tamao nuevo y modificados reales.
B y b son los parmetros de regresin lineal de los datos Xs vs. Ys
gl es el nmero de los grados de libertad de los datos, el cual es n 2.

Encontrando t70(/2,n -2)

(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).

Una forma para hacer el clculo es la siguiente:

1. Inicie con un valor de prueba t digamos 1.
2. Haga una integral inicial y pruebe revisar si proporciona el valor apropiado; si no,
continu.
3. Si es muy bajo, sume d = 0.5 al valor de prueba t
4. Si es muy alto, reste d = 0.5 al valor de prueba t.
5. Integre de nuevo y pruebe si el resultado est dentro del error aceptable, si no,
continu.
15

6. Si es muy bajo, ajuste d; sume d al valor de prueba t.

7. Si es muy alto, ajuste d; reste d al valor de prueba t.
8. Repita pasos 5 -7.
Las reglas para ajustar d son las siguientes:
1. En tanto como las pruebas de error del resultado, proporcione el mismo signo del
error, deje d sin cambio.
2. Siempre que cambie el signo del error, divida d entre 2.

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.

Para nuestro propsito, usamos el valor de relacin rxy cuadrado, o r2.

Si r2 es
.9 r2
.7 r2< .9
.5 r2 < .7
r2 < .5

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

2. Encuentra la probabilidad p por integracin numrica de distribucin t para n 2 grados

de libertad de - a t.
3. Calcula las colas de distribucin, 2*( 1 - p).
El rea de una cola de distribucin 0.05 es considerada una evidencia fuerte de que exista
una relacin.
El rea de una cola de distribucin 0.2 es considerada una relacin casual.

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.

El algoritmo de insercin sort va encontrando la posicin correcta para un dato o elemento,

entonces el elemento dentro de la lista toma su posicin correcta.
7
1

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

Los pasos de la prueba 2 son los siguientes:

1. Ordena el conjunto de datos de n nmeros reales de forma ascendente.
2. Normalice el conjunto de datos.
Primero, calcule la desviacin estndar , para los datos usando n -1.

1 n
(xi xavg )2

n 1 i =1

Despus, transforme cada xi en zI, donde

zi =

(x x )
i

avg

3. Divida la distribucin normal entre el mismo nmero de segmentos S, donde

n/S 5
S>3
S2 n
4. Determine cuantos puntos de la distribucin normal ideal, pueden estar dentro de
cada segmento, Ni, Normalmente es n/s, para este caso es 5.
5. Determine cuantos de los datos normalizados caen dentro de cada segmento Ki.
6. Calcule el valor de Q para los segmentos
S

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

8. Calcule la cola de distribucin para 1 p.

9. Examine 1 p para interpretar el resultado.
1 p < 0.05 es generalmente considerado suficiente para
1 p > 0.2 es generalmente considerado suficiente par aceptar
Valores intermedios indican grados intermedios de
19

3.10 TAREA 10A

Requerimientos de programa10A
Usando PSP3, realice el programa 10A para calcular, los parmetros de regresin mltiple
(B0, B1,B2, B3).
Hacemos un estimado de las entradas previstas por el usuario. Y determine los
intervalos de prediccin del 70% y 90% a ser estimados.
Use adems una lista ligada para almacenar los datos y el mtodo de integracin de
Simpson del programa 5A para calcular la distribucin t.

Calculando los parmetros de regresin mltiple

La regresin mltiple proporciona un camino para estimar los efectos de mltiples variables
cuando no es posible separa los datos.
A continuacin se muestra en una serie de 13 pasos como podemos calcular la regresin
mltiple:

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

3. Cuando calcules el valor de los trminos, obtendrs el siguiente sistema de

ecuaciones lineales:
6 0 + 4,8631 + 8,7612 + 654 3 = 714
4,863 0 + 4,521,899 1 + 8,519,938 2 + 620,707 3 = 667,832
8, 761 0 + 8,519,938 1 + 21, 022, 091 2 + 905,925 3 = 1,265,493
654 0 + 620,7071 + 905,925 2 + 137, 902 3 = 100,583
20

4. Diagonalizando por el mtodo de Gauss, se elimina sucesivamente un parmetro a

la vez, dando como resultado:
6 0 + 4,8631 + 8,7612 + 654 3 = 714
0 0 + 580,437.5 1 + 1,419,148 2 + 90,640 3 = 89,135
0 0 + 0 1 + 4,759,809 2 270,635 3 = 5,002.332
0 0 + 0 1 + 0 2 + 37,073.93 3 = 9,122.275
5. La solucin para los trminos BETA es:

0 = 6.7013
1 = 0.0784
2 = 0.0150
3 = 0.2461

6. Determine el intervalo de prediccin por solucin del rango con la siguiente

ecuacin:

(wk wavg ) + (xk x avg ) + (yk yavg )

1
Range = t ( / 2,n 4) 1 + +
n (wi wavg )2 (xi xavg )2 (yi y avg )2
2

7. Calculamos la varianza como sigue:

1

2 =
(z 0 1wi 2x i 3yi )
n 4 i =1 i

8. La desviacin estndar es la siguiente:

= 2 = 513.058 = 22.651
9. Los trminos dentro de la raz cuadrada que determinan el rango son:

(New New ) = (w w ) = (650 810.5) = 25, 760.25

(Re use Re use ) = (x x ) = (3,000 1,460.17) = 2,371,076.43
(Modify Modify ) = (y y ) = (155 109) = 2,116
2

avg

avg

avg

avg

avg

avg

21

10. El valor de la distribucin t, para el intervalo de prediccin del 70% con n = 6 y p =

4 es encontrado bajo la columna del 85% y dos grados de libertad. Y el valor es:
1.386.
11. Evaluamos la raz cuadrada:
Range = 1.386 * 22.651 1 + (1/ 6) +

25,760.25 2,371,076.43 2,116

+
+
= 38.846
580, 437.5
8,229, 571
66,616

12. El estimado final es:

z = 6.71+0.0784*650+0.0150*3,000+0.2461*155
= 140.902 horas
13. El intervalo de prediccin es de: 140.902 +/- 38.84 horas. O lo que es lo mismo:
102.06 horas como mnimo y 179.74 horas como mximo.

22

4 FORMAS UTILIZADAS EN PSP

Como podemos ver en la tabla 4.1 a medida que se avanza en el PSP, se van aumentando
plantillas y formas que tienen como finalidad la de ayudarnos a mejorar nuestro desempeo
durante el proceso y la de proveer informacin la cual nos puede servir, para mejorar la
calidad de cada una de las tareas, como puede ser aumentar nuestra productividad,
disminuir el desarrollo en cada fase del PSP, disminuir el error en la estimacin de tamao
o tiempo.

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

PSP0.1 PSP1 PSP1.1 PSP2 PSP2.1 PSP3

Ver0.1 Ver1 Ver1.1 Ver2 Ver2.1 Ver3
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
X

Tabla 4.1 Formas, plantillas y Bitcoras utilizadas en PSP

23

4.1 DESCRIPCION GENERAL DE FORMAS Y PLANTILLAS

4.1.1 FORMAS DEL RESUMEN DEL PLAN DE PROYECTO
La forma del resumen de plan de proyecto proporciona un formato conveniente para
registrar las mtricas PSP ms importantes para un proyecto. En esta forma se van
registrando datos, como vienen siendo la productividad en LOC/Hora, el tiempo total de
desarrollo, el tamao del programa, los defectos encontrados en las distintas fases del
proceso, por citar algunos. Los resmenes son nicos para cada fase del PSP, conforme se
agregan nuevas mtricas en el proceso PSP1 y PSP2, el resumen de plan de proyecto va
evolucionando, de acuerdo a los requerimientos nuevos. Inicialmente es una hoja para el
PSP 0 y cuando se llega al PSP 3 consta de dos hojas.

4.1.2 BITACORA DE REGISTRO DE TIEMPO

Se introduce desde PSP 0 y se sigue utilizando hasta el PSP 3. Para tener un control del
tiempo de las actividades realizadas durante el desarrollo de cada una de las tareas,
contamos con la bitcora de registro de tiempo.
La finalidad de esta Bitcora es de proporcionarnos exactamente el tiempo que tardamos en
la realizacin de cada uno de nuestros proyectos, el tiempo de inicio y el tiempo de
terminacin de cada fase en minutos, esta perfectamente diseado para contabilizar los
tiempos en cada una de las fases, lo que nos permite ver cual de las fases es la que se tarda
ms en realizarse. Otra de las caractersticas de esta bitcora es que, en caso que se
presente una interrupcin durante el desarrollo de una fase, podemos hacer una pausa y
continuar con el proceso ms tarde, as como realizar una parte de una fase y continuar con
ella ms tarde, tambin podemos hacer comentarios acerca de cual fue el motivo de la
interrupcin.

4.1.3 BITACORA DE REGISTRO DE DEFECTOS

Otra de las Bitcoras utilizadas durante todo el PSP es la bitcora de Registro de Defectos.
As como es necesario llevar un control del registro de nuestros tiempos, tambin es
necesario llevar un control del registro de nuestros defectos. Cuando hablamos de defectos
hablamos de los Errores producidos durante el desarrollo de todo un Proyecto, desde su
fase de Planeacin hasta la fase de Pruebas. Tomando un estndar de tipo de defectos
proporcionado por el PSP, anotamos en la bitcora los defectos que se vayan encontrando
por categoras (tipos), fase en la cual se inyecto el defecto y fase donde fue removido, as
como el tiempo que se tardo en resolver el defecto y una descripcin de en que consisti el
defecto. Para la primera parte del Proceso los defectos son encontrados en las fases de
Compilacin y Pruebas, para la segunda parte del Proceso se introducen 2 nuevas plantillas
que son las revisiones de diseo y cdigo.
24

4.1.4 ESTANDAR DE TIPO DE DEFECTOS

El estndar de tipos de defectos proporciona una categora general de tipos de defectos, los
cuales se van presentando en la realizacin de los programas. Se recomienda
preferentemente utilizar el ya definido, hasta que se tengan datos suficientes para realizar
los cambios, si la persona cree que es recomendable.
Personalmente yo utilice el estndar ya establecido y me dio buenos resultados, ya que no
se me hizo muy difcil utilizarlo y ha medida que avanzaba el proceso, me familiarice con
los distintos tipos. La tabla 4.2 muestra los distintos tipos de defectos que se pueden
presentar durante la realizacin de los programas.
Nmero
de Tipo
10
20

Nombre del Tipo

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

Tabla 4.2 Estndar de Tipo de Defectos

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

4.1.6 ESTNDAR DE CONTEO DE LOC (R1)

Como queremos medir el tamao del software, tenemos que contar lneas de cdigo
(LOCs). Tenemos que crear un tipo estndar para poder contar las lneas. Este estndar se
hace en base a que lenguaje se va a utilizar para trabajar en la realizacin de las tareas. En
mi caso use Borland C++ (Versin. 3.0). Tenemos que tomar en cuenta como vamos a
contar las LOCs, ya sea que estructuras de control vamos a contar, si vamos a contar los
comentarios, instrucciones vacas, libreras, mdulos etc.

4.1.7 ESTNDAR DE CODIFICACIN (R2)

Esta forma se introduce a partir del PSP 0.1. La finalidad de este estndar es de ver de que
manera vamos a realizar cada uno de los mdulos de nuestras tareas. Que se predefina el
tipo de encabezado se van a utilizar, la declaracin de variables se realizar de tal manera,
descripcin de la funcionalidad de los mdulos, resumen del listado de los mdulos del
programa, descripcin de las constante, libreras, etc.

4.1.8 PLANTILLA DE REPORTE DE PRUEBAS

Esta plantilla tiene como finalidad la de registrar datos de cada uno de las pruebas de
nuestros programas. Ya que cada programa tiene como mnimo un nmero determinado de
pruebas a realizar, para ver a funcionalidad del mismo. Se utiliza en la fase de pruebas y en
esta plantilla se comparan, que los datos de salida de nuestros programas coincidan con los
datos de salida las pruebas a realizarse, en caso de que no coincidan los datos o este
funcionando mal nuestro programa, aun se apuntan en la plantilla como una referencia,
dicho proceso se realiza hasta que todas las pruebas concuerden con las de muestra.

4.1.9 PLANTILLA DE ESTIMACION DE TAMAO (Size Estimate)

Tiene como finalidad de aportar datos histricos para hacer las mediciones de tamao de
nuestros programas. De acuerdo a nuestro diseo conceptual, en esta plantilla se apuntan
cada uno de los mdulos que va a tener nuestro programa, cual va ha ser el nmero de
LOCs de cada uno de los mdulos, el tipo de mtodo que va ha ser. Tambin cuenta con
informacin acerca de si vamos a utilizar cdigo reutilizable, si vamos a modificar cdigo o
si vamos a construir cdigo nuevo. Esta plantilla se utiliza para la realizacin de cada uno
de los programas de PSP. Como lo dije anteriormente tiene como finalidad d estimar el
tamao de cada uno de los mdulos, para tener un error menor en cuanto al tamao real de
los mdulos.

26

4.1.10 PLANTILLA METODO PROBE

La finalidad principal de esta plantilla, es la de hacer la estimacin de tamao y tiempo en
la realizacin de cada tarea del proceso. Principalmente se basa en nuestro banco de datos
histricos proporcionados, durante el desarrollo de las primeras 3 tareas, al principio como
no se cuenta con muchos datos, es un poco difcil estimar bien que tipo de mtodo de
Estimacin (A, B, C, D) se va a utilizar. Cuenta con una grafica que se calcula utilizando
regresin lineal, donde se muestra la correlacin estimada que existe entre el tiempo
estimado Vs el tiempo actual y el tamao estimado Vs el tamao actual. La seleccin del
mtodo es en base al mayor nmero de puntos que toquen la pendiente positiva, tanto para
tamao como para tiempo.

4.1.11 LISTA DE CHEQUEO DE REVISION DE DISEO

Se introduce a partir de la segunda parte del proceso en el PSP 2.0, tiene como finalidad
encontrar los defectos introducidos durante la fase de diseo. Por lo general casi todos los
errores de tipo lgico, funcional y de sistema son removidos, durante esta fase.
Lo ideal es que todos estos tipos de defectos se eliminen durante esta fase, pero suele pasar
que alguno se pueda filtrar. Desde mi punto de vista, representa la manera de que la
calidad de nuestro producto aumente considerablemente, as como la reduccin de tiempo
en la bsqueda de errores.

4.1.12 LISTA DE CHEQUEO DE REVISON DE CODIGO

Tiene como finalidad remover todos los defectos de sintaxis, llamadas a procedimientos,
declaraciones y chequeo de tipos, inicializacin de variables, pares entre llaves o corchetes,
apuntadores y operadores lgicos.
Ambas revisiones se llevan a cabo antes de la fase de compilacin, si realizamos una buena
etapa de revisin tanto de diseo y cdigo, el nmero de errores en la fase de compilacin
puede tender a cero. Lo mismo puede ocurrir en la fase de pruebas, ocasionando una
disminucin considerable de tiempo en estas dos fases.

4.1.13 PLANTILLA DEL ESCENARIO OPERACIONAL

Es una serie de pasos entre el usuario y el sistema, muy parecido a un diagrama de casos de
uso. Cuya finalidad es que el usuario interacte con el sistema o programa, sealando
especficamente que debe hacer el usuario y la respuesta que da el sistema. Prcticamente
es una manual operacional de la utilizacin correcta del uso del sistema. En dicha plantilla
no se menciona nada acerca de los flujos de error que pueden ocurrir, estos se especifican
en la plantilla de especificacin de estados.
27

4.1.14 PLANTILLA DE ESPECIFICACION DE ESTADOS

Este tipo de plantilla tiene como finalidad, la de representar el diseo de un proyecto de
software. Representa el comportamiento de nuestro programa a nivel de una maquina de
estados finita. Especifica detalladamente como se relacionan entre si cada uno de los
mdulos de nuestro programa, el flujo que toman cada y las transacciones que existen entre
los mismos. As como tambin el flujo de error que pueda ocurrir.

4.1.15 PLANTILLA DE ESPECIFICACION LOGICA

Nos provee la interaccin que existe dentro de nuestro programa, dicho de otra forma.
Tiene como finalidad de detallar especficamente la funcionalidad de cada mdulo, cada
objeto y el programa principal de nuestros programas. Cuenta con una notacin definida y
adaptable a cualquier tipo de lenguaje de programacin, para poderlo exportar. Dicha
plantilla debe ser llenada a mano, ya que todo lo que se escribe en ella es pseudocdigo.

28

5 PLANTILLA ESTANDAR DE CONTEO DE LOCs (R1)

Como se mencion en la seccin 4.1.6, esta plantilla tiene como finalidad, contar lneas
lgicas de los mtodos o funciones que se desarrollan a lo largo de las tareas. Esta plantilla
es personalizada, en caso de que se quiera utilizar un nuevo lenguaje de programacin, debe
realizarse una nueva plantilla. No puede se modificada mientras se encuentre realizando el
PSP.
Lenguaje: C
Nombre/definicin:
Capitaine Aggi Oscar
Fecha:
Autor:
Castro Careaga Luis F.
24/10/05
Tipo de Conteo

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

Divisin de procedimientos, interfaz,

implementacin
Destinos de saltos cuando estn en lneas
separadas
Se contara una , o un ; por cada declaracion de
variable o parmetro
Contar cada #include, #define por cada # que
aparezca en el codigo
Se contara un Begin...End por cada { que
aparezca en el codigo
Se contaran 1 linea por cada una de las siguientes
palabras reservadas if, else, do, while, for,
switch, case
@

29

6 PLANTILLA ESTANDAR DE CODIFICACION R2 C

Como mencionamos en la seccin 4.1.7, esta plantilla tiene como finalidad estandarizar
cada mtodo o funcin de nuestros programas, nos presenta ejemplos de cmo tenemos que
estructurar nuestros programas. La realizamos a partir de la tarea 2A y al igual que el R1,
no puede ser modificado a lo largo del PSP.
Propsito
Encabezados del
Programa
Formato del Encabezado

Contenido del Listado

Ejemplo del Contenido

Instrucciones de
Reutilizacin
Ejemplo

Guiar el desarrollo de programas

Todos los programas comienzan con un encabezado descriptivo.

/***************************************************
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

Utilice nombres descriptivos para todas las variables, nombres de funciones,

constantes y otros identificadores. Evite las abreviaturas o nombres de variables
con un solo carcter.
int tamanio_buffer; //correcto
int x;
//incorrecto

30

Plantilla de Estndar de Codificacin R2, Continuacin

Comentarios

Buen Comentario
Mal Comentario

Secciones Importantes
Ejemplo

Espacios en blanco
Sangras

Documente lo suficientemente el cdigo para que el lector pueda comprender

su operacin. Los comentarios deben explicar tanto el propsito como el
comportamiento del cdigo. Comente la declaracin de las variables para
indicar su propsito.
/*Se lee una linea de codigo*/
if (carcter=={)
...
//cuenta un
//un operador {

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

for (cont=0; cont< TAMMAX; cont++)

{
suma+=cont ;
if (suma < CERO)
{
suma=-suma;
}
}
Todos los defines van en maysculas.
Todos los otros identificadores y palabras reservadas van en minsculas.
Los mensajes que son salidas al usuario pueden tener mezcla de maysculas
y minsculas de tal manera que hagan ms limpia la presentacin al usuario.
#define TAMBUFFER
while (cont != TAMBUFFER)

31

7 REPORTE DE ANALISIS DE DEFECTOS R3

Tiene como finalidad registrar la densidad de los tipos de defectos introducidos y
encontrados mientras se desarrollan los programas. As como tambin el tiempo que se
tarda en remover cada uno de los defectos. Los defectos producidos por KLOCs en cada
uno de los programas.
Se llena a partir de la bitcora de registro de defectos, tomando el conteo y tiempo de
eliminacin de defectos, los cuales se introducen en el diseo y se remueven en la
compilacin y pruebas, defectos introducidos en la codificacin y removidos en
compilacin y pruebas.

Defect Densities
Program
Number

New and
Changed LOC

Compile and Test Defects

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

Defect Fix Times

Defects found in Defects found in
compiling
testing
Defects

Tot. fix time

30

injected in
designing

Tot. defects
Avg. fix time

Defects

Total defects
found

93

123

15

22

13

Tot. fix time

59

41

100

injected in
coding

Tot. defects
Avg. fix time

28

34

Total

Tot. fix time

89

134

223

defects
injected

Tot. defects
Avg. fix time

43

13

56

10

32

8 REPORTE DE LA PRIMERA PARTE DEL PROCESO R4

Tiene como finalidad evaluar el desempeo del alumno, a lo largo de las primeras seis
tareas, se formulan una serie de preguntas en cuanto a estimacin de tamao, estimacin de
tiempo, calidad. Evala que tan bien ha funcionado el PSP y cuales son las metas de
mejora para la segunda parte del proceso. Cuales los principales errores que se cometen en
el proceso y de que forma se pueden corregir.

8.1 Resumen del Plan Reporte R4

Estudiante

Capitaine Aggi Oscar

Instructor

Castro Careaga Luis F.

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

Esf. Est. por

Objeto
5
5
5

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

8.2 Bitcora de Registro de Tiempo R4

Estudiante:

Capitaine Aggi Oscar

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

8.3 Muestra de Script del Proceso del Reporte R4

Fase #

Propsito

Para guiar el anlisis y la escritura del Reporte R4

Criterio de Entrada Programas 1A a 6A terminados y revisados por los instructores

Copia de los requerimientos del reporte
Forma del resumen del reporte y bitcora de registro de tiempo
1

Planeacin

Estime el tamao del reporte

nmero de prrafos de anlisis
Nmero de tablas / grficas de datos a crear
Estime el esfuerzo basndose en el tamao del reporte
Registre los estimados en la Forma de Resumen del Plan
Registre el tiempo de planeacin en la bitcora de tiempo
Para cada pregunta de anlisis
genere una grfica o tabla de datos
analice la tabla / grfica y otros datos del proceso
escriba un prrafo de anlisis

Desarrollo

Revise el desempeo completo

Identifique las reas de mejora
Defina metas cuantificables
Determine qu cambios al proceso son necesarios
Escriba un anlisis de mejora de desempeo
Registre el tiempo de desarrollo en la bitcora de tiempo

Postmortem

Mida el tamao del reporte

nmero de grficas / tablas
nmero de prrafos de anlisis
Complete la forma de resumen del plan
Registre el tiempo de postmortem en la bitcora de registro de tiempo
Reporte R4 completo
Resumen del Plan completo
Bitcora de registro de tiempo completa

Exit Criteria

35

8.4 Anlisis de la Exactitud de Estimacin de LOC

1. Analice la tendencia en la exactitud de estimacin de tamao en los primeros seis
programas.
Actual Size
350

Size Estimating Error

60

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

8.5 Anlisis de la Exactitud de Estimacin de Tiempo

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

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.

2. Para los primeros seis programas, qu tan estable fue su productividad?

Productivity
70
63.4455024

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

En la primer grafica se puede ver que mi fase de compilacin se ha mantenido estable de

cierta forma en un rango no mayor al 10% del tiempo requerido para la realizacin del
programa, la fase de pruebas a ido disminuyendo de un 27% hasta caer entre el 10% y 5%.
La fase de compilacin y pruebas, si influye en que tan buena productividad se tenga, ya
que al tener ms errores en estas 2 fases, aumenta el tiempo en el desarrollo del programa y
esto ocasiona que la productividad vari. Ya que la productividad depende del nmero de
LOCs (N&C) VS Tiempo total de todas la fases.

4. Cmo fue afectada la exactitud de sus estimados de tiempo por la calidad de sus
estimados de tamao?
Size Estimating Error

Time 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

Estimacin Tamao VS Tiempo

150
107.43

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.

8.6 Anlisis de los Defectos Introducidos y Eliminados por Fase

[Tabla D23]
1. Qu tipos de defectos se introducen ms en la fase de diseo?
tipo
20
40
50
80

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

2. Qu tipos de defectos se introducen ms en la fase de codificacin?

tipo
20
30
40
80

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

3. Qu tipos de defectos se eliminan principalmente en la fase de compilacin?

tipo
20
30
40
50
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).

4. Qu tipos de defectos se eliminan principalmente en la fase de pruebas?

Tipo
40
50
80

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

8.7 Anlisis de Defectos Introducidos y Eliminados por Fase [R3]

De la hoja R3 de su libro de trabajo del estudiante, imprima el reporte R3.
1. Analice los tiempos de eliminacin de defectos, basndose en la fase en la que los
defectos son introducidos y eliminados.

Defect Fix Times

Defects
found in
compiling
Defects

Defects
found in
testing

Tot. fix time

30

injected in

Tot. defects

designing

Avg. fix time

Defects

Total defects
found
93

123

14

22

12

Tot. fix time

59

41

100

injected in

Tot. defects

28

33

coding

Avg. fix time

Total

Tot. fix time

89

134

223

Defects

Tot. defects

43

13

55

Injected

Avg. fix time

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.

2. Qu categora tiene el tiempo promedio de eliminacin ms grande?

El tiempo promedio de eliminacin por programa es de un 37%, la fase de compilacin
presenta un promedio de 39%, en esta fase se eliminan los errores de sintaxis en su
totalidad, y tambin eliminamos la mayora de los errores de tipo 80, que son los ms
difciles de resolver, tambin la mayora de los defectos de asignacin (40), son resueltos
durante esta fase.
3. Qu categora tiene el tiempo total de eliminacin ms grande?
Defect Fix Time By Type
160
140
120
100
80
60
40
20
0
40

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.

8.8 Anlisis de Defectos Encontrados por el Compilador

1. Analice la efectividad del compilador eliminando defectos por tipo de defecto.
Para los defectos de sintaxis (20), el compilador es muy eficiente, yo dira en un 80% de
eficiencia, tambin para los defectos de asignacin (40), pero para todos los dems tipos no
se puede decir los mismo, ya que el compilador de C++ (ver. 3) no es muy bueno.

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

No necesariamente, un ejemplo muy claro es, si tengo un error de punto y coma y en la
siguiente lnea tambin se presenta el mismo error, el compilador solo reporta el primero,
hasta que se vuelva a compilar reportara el siguiente error. Lo mismo sucede con los errores
de tipo, sobre todo en el uso de FOR o el IF, si a estas sentencias se les pone un punto y
coma al final, el compilador no reconocer dicho error, pero al ejecutar el programa no
generara la operaciones que se le han asignado en su ejecucin.

43

8.9 reas de ms Alta Prioridad para Mejoras en la Segunda Mitad del

Curso
8.9.1 PLANEACIN
% Planning Time
18
16
14

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.

Su desempeo futuro deseado

Con la modificacin en la fase de planeacin, se cree que para las siguientes tareas se podr
hacer un mejor diseo, provocando que los errores se reduzcan de un promedio de 20
errores por KLOC a no mayor de 7 errores por KLOC . Con la utilizacin del PSP2 , se
podr controlar mejor los errores durante esta fase.

Sus metas de mejora

Para la segunda parte del proceso entran la revisiones (diseo y cdigo), lo cual mejorara el
proceso y se podrn filtrar los errores que se encuentra en esta fase, lo que provocara que se
tenga una disminucin de 20 errores por KLOC a un promedio no mayor a 9-5 errores por
KLOC.

45

8.9.3 CODIFICACIN

Defects Injected in Code

90

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.

Sus metas de mejora

Lo que modificara en el proceso es que una vez acabada la parte de codificacin es revisar
el cdigo con calma y principalmente, lo que es el paso de parmetros ya que la mayor
parte de mis errores son de este tipo. De esta forma se filtrarian la mayor parte de los
errores, para as disminuir de 20 errores por KLOCs, que actualmente es la media que
tengo a un promedio de 12-16 errores por KLOCs.
46

9 REPORTE DE LA SEGUNDA PARTE DEL PROCESO R5

Al igual que el R4 se evala el desempeo del alumno, en este reporte se compara la
productividad entre la primera parte del proceso y la segunda parte, el indice de estimacin
de defectos, y como a mejorado la estimacin de tamao y cdigo de los programas, as
como tambin la calidad en cada uno de ellos.

9.1 Resumen del Plan Reporte R5

Student

Capitaine Aggi Oscar

Instructor

Castro Careaga Luis Fernando

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

9.2 Bitcora de Registro de Tiempo R5

Student:

Capitaine Aggi Oscar

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

9.3 Anlisis de la Exactitud de Estimacin de LOC

1. Se alcanzaron las metas de la segunda mitad de proceso? Por qu si o por que
no?
Size Estimating Error
60
50
40

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

La tabla muestra el % de error de estimacin de tamao de cada modulo de los programas

7A-10A, podemos ver que la estimacin es psima para la mayora de los mdulos. La
TAREA 7A tiene un %Error menor al 50% de Tamao por mdulo, a pesar de esto fue la
tarea con un Error de Estimacin de tamao menor. La peor de todas las tareas fue la 8A,
ya que presenta un %Error de 50% a 171% lo cual afecto relativamente la productividad, lo
mismo ocurri con la TAREA 9A con %Error entre50%-90%. Para la TAREA 10A el
%Error se ajusto de 20%-69% debido a que se pudo interpretar mejor los datos, a pesar de
que no se estimo bien el tamao de 2 de los mdulos (calculos.c y rango.c), nuestra
productividad aumento a 60 LOCs/Hora, que era lo que se quera.

5. Se pudieron calcular tamaos relativos usando datos histricos? S?

Los datos histricos nos mostraron que exista una tendencia a subestimar los tamaos de
los mdulos de los programas, nos fueron de gran ayuda en la estimacin del tamao de los
mdulos para las tareas 7A, 8A, 9A y 10A.
Para calcular el tamao de cada nuevo objeto, necesito usar los datos histricos, y este nos
lo va dando la hoja Locmeth, y los intervalos de prediccin (UPI, LPI) que nos muestra el
tamao de los objetos que hemos realizado. Principalmente me base en los intervalos de
prediccin para hacer la estimacin del tamao de los mdulos del programa. Podemos ver
en la tabla que el total de nuestras LOCs N&C cayeron dentro del intervalo de prediccin
para cada una de las tareas, pero esto no nos garantiza que este tamao sea el optimo, por
eso tambin tenemos que tomar en cuanta nuestro Locmeth donde podemos hacer un
calculo del tamao estimado de LOC por mtodo, tomando en cuenta los tamaos de los
mtodos de las tareas anteriores.

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

6. Basado en la exactitud de estimacin del tamao del historial. Qu tan realistas

son las metas de estimacin del tamao?
Analysis
calculations
Size
Error %
Formulas 0
1
0
2
41.23223
3
55.12821
4
9.14527
5
-1.55869
6
35.4614
7
-9.93675
8
51.36021
9
29.73234
10
15.45122
Totals
226.0154
Como se puede observar en la tabla el error tiende a estabilizarse entre un 30% y un 9%
exceptuando la TAREA 8A, lo cual considero que no es excelente, pero si es bueno, lo que
implica que si se sigue utilizando este tipo de mtodo, el error tendera a estabilizarse,
ahora si analizamos todas la tareas a excepcin de la 2A,3A y 8A el Error de estimacin se
encuentra entre el 35% al 1%, que nos dice esto, con forme se avanza en el proceso se tiene
una mejor facultad para hacer una estimacin ms precisa, lo ideal sera que dicho error
estuviera entre un 10% y 5%, pero no se puede predecir el futuro y ser tan exacto, e incluso
es muy difcil alcanzar la meta ms razonable.

7. Como se puede cambiar el proceso para alcanzar estas metas?

Uno de los cambios que podra hacerle al proceso sera que cuando analice cada objeto, ver
cada una de sus funciones y de ah empezar hacer un conteo de las lneas que podra tener
cada funcin pero con ms detenimiento y atencin de lo que lo hago hasta ahora, y as
obtener el conteo para todo el objeto.

52

9.4 Anlisis de la Exactitud de Estimacin de Tiempo

1. Se alcanzaron las metas del la segunda mitad de proceso? Por qu si o
porque no?
Time Estimating Error
120
100
80

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.

3. La productividad es estable? Por qu si o por que no?

Productivity
70

LOC/Hour

60
50
40
30
20
10
0
1

10

Program Number

La productividad para la primera parte del proceso se mantuvo estable en un promedio de

40 LOC/Hora, al introducir las revisiones de Diseo y Cdigo, la productividad bajo un
poco para los primeros 2 programas de la segunda parte TAREA7A y TAREA8A, aunque
se fue normalizando y para el ultimo programa aumento considerablemente, para
producirse 60 LOC/Hora.

4. Como se puede estabilizar la productividad?

La forma ms conveniente para tener una buena productividad es la de tener una buena
estimacin de las LOC(N&A) y una buena estimacin del tiempo total de desarrollo.
Como se puede ver en la tabla para la segunda parte del proceso la productividad fue
aumentando considerablemente de 26 LOC/Hora hasta producir un total de 60 LOC/Hora,
54

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

5. Cuantas veces las estimaciones de tiempo afectaron las estimaciones de tamao?

Ayudara la regresin mltiple?
La estimacin de tamao es un punto crucial a partir del cual se obtiene la estimacin del
tiempo, y si la estimacin de tamao tiene un gran error seguramente la de tiempo ser
afectada. Y por supuesto que me ayuda la regresin mltiple a obtener un intervalo en el
cual carea la estimacin de tiempo con una muy buena exactitud.
Como conclusin tenemos que la estimacin de tiempo no afectaron las estimaciones de
tamao, en cambio la estimacin de tamao, si afecta a la de tiempo.
6. Basado en la exactitud de estimacin del tiempo del historial. Qu tan
realista son las metas de estimacin del tiempo?
Time
Error
%
0
7.04321
4.376543
106.2549
51.95974
16.31369
57.64492
14.75728
26.91608
21.47024
-9.44178
297.2948
55

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.

7. Como se puede cambiar el proceso para alcanzar estas metas?

Considero que los errores de estimacin de tiempo son pequeos, por lo que convendra
seguir el proceso, ya que nos ha dado buenos resultados. Lo nico que cambiara en el
proceso, es que fuera ms rpido en el llenado de las plantillas, ya que considero que dentro
de las dems fases me ha gustado como se han desarrollado.

56

9.5 Anlisis de Defectos y Yield

1. Qu tipo de defectos introdujo durante el diseo y la codificacin?
Tipo
20
30
40
50
60
70
80
Total

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.

2. Qu tendencias son evidentes en defectos/KLOCs encontradas en las revisiones,

en la compilacin y las pruebas?
La finalidad de las revisiones es la cachar la mayor parte de los defectos, para que de esta
forma al pasar a las fases posteriores, los defectos sean muy pocos y se ahorre el tiempo de
ejecucin de estas fases. As como tambin para aumentar la calidad en la fase de
desarrollo. Vemos que la cantidad de defectos/KLOC durante la revisin de diseo esta por
abajo de 20 KLOCs para las ltimas 2 tareas y la cantidad de defectos para la revisin de
cdigo es menor 15, lo cual se considera que es bueno.
Defects Removed in Design
Review

Defects Removed in Code

Review
16

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

Defects Removed in Test

25
20
15
10
5

50
40
30
20
10

0
1

10

Program Number

10

Program Number

3. Qu tendencias son evidentes en el total de defectos/KLOC?

El nmero de defectos en la primera mitad del curso, en especial para el primer programa
fue muy grande, conforme se fue avanzando en el proceso, tendi a regularizarse, vemos
que para la tarea 7 se volvi a elevar, esto fue a que se tuvo un Yield del 40%, en esta tarea,
pero gracias a las revisiones de diseo y cdigo, el nmero de defectos, fue disminuyendo
nuevamente para las ltimas tres tareas, como podemos ver en la grafica, ya a partir de la
tarea 10, se pudo obtener un Yiel del 57..4% y un mximo de defectos de 20 Def/KLOC,
que era la meta a llegar.
Total Defects

Defects/KLOC

100
90
80
70
60
50
40
30
20
10
0
1

10

Program Number

58

4. Cmo se comparan sus tasas de defectos removidos (en defectos

removidos/KLOC) con la revisin de diseo, la revisin de cdigo, la compilacin y las
pruebas?
Lo que ocurra en la primera mitad del proceso, era que todos defectos eran encontrados en
las fases de compilacin y pruebas, debido a que en la segunda parte del proceso se
introdujeron las revisiones de diseo y cdigo, pudimos filtrar la mayora de los defectos en
estas 2 fases y al llegar a la fase de compilacin y a la fase de pruebas, eran muy pocos los
defectos a ser corregidos.
Fase
DLDR
CDR
COMPILE
TEST
TOTAL

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 Reviewed per Hour

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

En la tabla podemos ver la tasa de revisin de diseo y la tasa de revisin de cdigo, si

tomamos por separado los valores de las tasas, tenemos que para la revisin de diseo es de
272 LOCs revisadas por hora y para cdigo 261 LOCs por hora. Si tomamos la tasa de
ambas tenemos que 133 LOCs hora en promedio, lo que se considera una buena cantidad
de LOCs revisadas durante una hora.
Programa

Tasa de Rev. Diseo

(LOC revisadas/hora)

7
8
9
10

162.9243
265.7048
230.5006
430.3963

Tasa de Rev. Cdigo

(LOC revisadas/hora)
183.5294
246.1697
224.6809
392.4731

Tasa de Rev. Ambas

DLDR VS CDR
86.30705
127.7822
113.7768
205.2804

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

(LOC
revisadas/hora)

Tasa de Rev. Cdigo

(LOC
revisadas/hora)

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

Apppraisal Cost of Quality

40

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

9.6 Preguntas sobre la calidad

1. Se alcanzaron las metas de la segunda mitad de proceso? Por qu si o
porque no?
Defects Injected in Code
90

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.

2. Cmo se puede juzgar en el momento la calidad del producto final en el ciclo de

desarrollo?
Gracias al proceso PSP, los productos que se realizan tienen un alto grado de calidad,
debido a que se lleva una disciplina estricta y constante, gracias a que se encuentra dividido
en varias fases, lo que permite al individuo tener un control detallado del programa que esta
realizando, disminuyendo considerablemente su margen de Error entre cada programa,
dando as un producto confiable y seguro.
3. Se estn encontrando los defectos en las revisiones de cdigo y de diseo?
Defect Removal Yield
70
60

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.

4. Qu se puede hacer para que el proceso sea mas efectivo y eficiente?

Una de las propuestas que considero eficiente, sera realizar el proceso como se ha hecho
pero a un nivel ms bajo, esto es realizndolo a nivel modular y no a un nivel de programa,
el problema que esto implicara sera que se llevara mucho ms tiempo de cada modulo,
pero la calidad del producto aumentara considerablemente.
5. Basado en los datos histricos. Que metas de calidad son realistas?
Failure Cost of Quality
40

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

6. Como se puede cambiar el proceso para alcanzar estas metas?

Como ya lo haba dicho al realizar este proceso de desarrollo a nivel modular se
hara mas simple y mas riguroso el proceso de desarrollo lo que nos llevara a
tener menos errores al controlar cosas mas pequeas no tan grandes donde hay
menos control.

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.

[2] Programacin en C, Metodologa, algoritmos y Estructura de Datos

Joyanes Aguilar Luis
Zahonero Martnez Ignacio
McGraw-Hill, 2001.
ISBN: 84-481-3013-8
[3] Como programar en JAVA
Deitel, Harvey M.
Deitel, Paul J.
Pearson Educacin. Mxico, 2004
ISBN: 970-26-0518-0