UNIDAD IZTAPALAPA

DIVISIN DE CIENCIAS BSICAS E INGENIERIA

LICENCIATURA EN COMPUTACIN

PROYECTO:
DESARROLLO DE SISTEMAS UTILIZANDO EL
PROCESO PERSONAL DE SOFTWARE (PSP)

ALUMNO:
ZANABRIA GONZLEZ DANIEL
201320609

ASESOR:
ING. LUIS FERNANDO CASTRO CAREAGA

MXICO D.F. FEBRERO DEL 2011






























INDICE GENERAL

INTRODUCCIN
0. INTRODUCCIN.............1
0.1. PROLOGO.....1
0.2. OBJETIVOS.5
0.3. JUSTIFICACIN.5
0.4. HIPTESIS..6
0.5. METODOLOGA6

DESARROLLO
1. PSP.......................................7
1.1. PSP0........8
1.2. PSP0.1......8
1.3. PSP1........9
1.4. PSP01.1....9
1.5. SCRIPT DEL PROCESO.9
1.6. FORMA DE RESUMEN DEL PLAN DE PROYECTO10
1.7. BITACORA DE REGISTRO DE TIEMPO..11
1.8. BITACORA DE REGISTRO DE DEFECTOS.12
1.9. ESTANDAR DE TIPO DE DEFECTOS12
2. PSP213
2.1. USO DEL PSP2.13
2.2. REVISIONES DE DISEO Y CDIGO..........................................................13
2.3. MOTIVOS PARA REALIZAR REVISIONES.14
2.4. LA ESTRATEGIA DE REVISIN EN EL PSP15
2.5. MEDIDAS DE LAS REVISIONES.17
2.6. CONSIDERACIONES DE LAS REVISIONES19
2.7. CALIDAD DEL SOFTWARE..20
2.8. PRUEBAS E INSPECCIONES20
2.9. EL COSTO DE LA CALIDAD21
2.10. LA ESTRATEGIA DE LA CALIDAD22
2.11. ESTRATEGIAS DE ELIMINACIN DE DEFECTOS.23
2.12. ESTIMANDO EL TIEMPO DE REVISIN..27
2.13. TIEMPO EN FASE A LA FECHA Y % A LA FECHA.27
2.14. EFICIENCIA Y OPORTUNIDAD DE ELIMINACIN DE DEFECTOS.29
3. PSP330
3.1. PSP3...30
3.2. EL PROCESO DE SOFTWARE EN EQUIPO (TSP) Y SU USO..30
3.3. ENTRENAMIENTO Y MEJORA..32


4. REPORTE R533
4.1. REPORTE R5.33
4.2. ANLISIS DE LA EXACTITUD DE ESTIMACIN DE LOC.36
4.3. ANLISIS DE LA EXACTITUD DE ESTIMACIN DE TIEMPO38
4.4. ANLISIS DE DEFECTOS Y DE YIELD..40
4.5. ANLISIS DE LA CALIDAD..46

CONCLUSIONES
CONCLUSIONES FINALES48

BIBLIOGRAFA
BIBLIOGRAFA..49





1
INTRODUCCIN

PROLOGO

La computadora se ha convertido en una de las herramientas ms importantes
en la actualidad, es utilizada en prcticamente cualquier rea y el desarrollo
tecnolgico del ser humano va ligado a su uso.
Debido a que la tecnologa avanza, los desarrolladores de software nos hemos
visto obligados a crear nuevas formas y mtodos para realizar un sistema, con el
objetivo de aumentar la calidad del producto y facilitarnos la manera en que
este se realiza.
Es por esto que la meta de cualquier desarrollador de sistemas es entregar
software de calidad en los plazos y con los costos especificados al cliente.
Para lograrlo debemos tener en cuenta principalmente los siguientes objetivos:
1. Realizar un plan de proyecto.
2. Cumplir el plan realizado.
3. Dar al producto la mxima calidad posible.

Cmo podemos cumplir con estos objetivos?
Con la Ingeniera de Software.

La Ingeniera de Software es la disciplina de la Ingeniera que nos provee de
mtodos y tcnicas para desarrollar y mantener software; trata de sistematizar
este proceso con el fin de disminuir el riesgo de fracaso en la consecucin del
objetivo, esto lo hace por medio de diversas tcnicas que se han demostrado en
base a la experiencia previa.
Precisamente esta experiencia ha buscado encontrar procesos y metodologas,
que sean sistemticas, predecibles y repetibles, a fin de mejorar la
productividad en el desarrollo y la calidad del software.

Etapas del Proceso
La Ingeniera de Software est compuesta de las siguientes etapas:
Anlisis de los requisitos: Los clientes siempre piensan que ellos saben lo
que el software tiene que hacer, sin embargo se requiere habilidad y
experiencia en la Ingeniera de Software para reconocer requisitos
incompletos, ambiguos o contradictorios. El resultado de este anlisis se
plasma en el ERS Especificacin de Requerimientos del Sistema. Esta
parte es tan crucial en el logro de los objetivos finales, que ya se habla de
la Ingeniera de Requisitos.
Especificacin: Describe el comportamiento esperado del sistema, una
vez desarrollado.
La tcnica ms usada en la especificacin son los Casos de Uso.


2
Arquitectura: Consiste en el diseo de componentes de una aplicacin
(entidades del negocio), describiendo en general como se construir e
sistema. Para ello se documenta utilizando diagramas de clase, de bases
de datos, de despliegue y de secuencia.
Programacin: En esta etapa es donde se realiza la codificacin del
diseo y su duracin y complejidad est ntimamente relacionada al o a
los lenguajes de programacin utilizados, as como al diseo previamente
realizado.
Prueba: Consiste en comprobar que el sistema realice correctamente ls
tareas indicadas en la especificacin del problema. Se debe probar por
separado cada mdulo del sistema y despus verificarlo de manera
integral, para de esta manera llegar al objetivo.
Documentacin: Es toda la informacin concerniente del desarrollo del
sistema y de la gestin del proyecto, pasando por modelados (UML),
diagramas, pruebas, manuales de usuario, manuales tcnicos, etc.
Esto con el propsito de tener todo el material e informacin disponible,
para eventuales correcciones, mantenimiento futuro y ampliaciones al
sistema.
Mantenimiento: Es la etapa encargada de mantener y mejorar el sistema,
para corregir errores descubiertos as como nuevos requisitos. Alrededor
de 2/3 partes de toda la Ingeniera de Software tiene que ver con el
mantenimiento. Una pequea parte consiste en arreglar errores o bugs y
la mayor parte consiste en extender las funcionalidades del sistema.

Modelos de desarrollo de software
La ingeniera de software tiene varios modelos, paradigmas o filosofas 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 o Clsico (modelo tradicional)
Modelo de prototipos
Modelo en espiral (modelo evolutivo)
Desarrollo por etapas
Desarrollo iterativo y creciente o Iterativo e Incremental
RAD (Rapid Application Development)
Desarrollo concurrente
Proceso Unificado
RUP (Proceso Unificado de Rational)
El ms utilizado es el Modelo en Cascada y consiste en ordenar rigurosamente
las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa
debe esperar a la finalizacin de la inmediatamente anterior.


3
De esta forma, cualquier error detectado en la etapa de pruebas conduce al
rediseo y nueva programacin del cdigo afectado aumentando los costos del
desarrollo. La palabra cascada sugiere mediante la metfora de la fuerza de
gravedad, el esfuerzo necesario para introducir un cambio en las fases ms
avanzadas de un proyecto.
UML
El UML (Unified Model Language) se encuentra estrechamente ligado a la
ingeniera de software en el desarrollo de sistemas de alta calidad.
UML es el lenguaje de modelado de sistemas de software ms conocido y
utilizado en la actualidad; est respaldado por el OMG (Object Management
Group). Es un lenguaje grfico para visualizar, especificar, construir y
documentar un sistema. UML ofrece un estndar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocio y funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y componentes
reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar
o para describir mtodos o procesos. Se utiliza para definir un sistema, para
detallar los artefactos en el sistema y para documentar y construir. En otras
palabras, es el lenguaje en el que est descrito el modelo.
Esta compuesto de varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.
En la versin 2.0 hay 13 tipos distintos de diagramas, los cuales son
categorizados de la siguiente manera:
Diagramas de Estructura: Enfatizan los elementos que deben de existir en el
sistema modelado:
Diagrama de Clases
Diagrama de Componentes
Diagrama de Objetos
Diagrama de Estructura Compuesta (UML 2.0)
Diagrama de Despliegue
Diagrama de Paquetes
Diagramas de Comportamiento: Enfatizan lo que debe suceder, hacer, el
sistema modelado.
Diagrama de Actividades


4
Diagrama de Casos de Uso
Diagrama de Estados
Diagramas de Interaccin: Son un subtipo de diagramas de comportamiento,
que se enfocan en el flujo de control y de datos del sistema modelado.
Diagrama de Secuencia
Diagrama de Comunicacin
Diagrama de Tiempos (2.0)
Diagrama global de Interacciones (2.0)
PSP
El PSP (Personal Software Process); es un conjunto de prcticas disciplinadas
para la gestin del tiempo y mejora de la productividad personal de los
programadores o ingenieros de software, en tareas de desarrollo y
mantenimiento de sistemas de alta calidad.
Se considera como la gua de trabajo personal para ingenieros de software, ya
que implica la medicin cualitativa y mejora de procesos.
























5

OBJETIVOS:

Conocer y utilizar las medidas de anlisis del PSP, para aumentar el
desempeo personal en la realizacin de programas y tareas.

Entender el funcionamiento de la metodologa del 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.

Mejorar la estimacin en el desarrollo de programas, mediante el uso de
los datos histricos que proporcionan las plantillas.

Aumentar la calidad y productividad de mi software, mediante la
utilizacin de PSP.

Reducir el nmero de errores mediante las revisiones de diseo y cdigo,
lo cual ayudara a disminuir el desarrollo total del producto.

Minimizar el nmero de errores en la fase de compilacin y pruebas.


Familiarizarse con cada una de las fases del PSP, para aplicarlo en
desarrollos posteriores.

JUSTIFICACIN:

La realizacin de programas con la ms alta calidad, en el menor tiempo posible
y con el costo ms bajo, es una de las cualidades ms importantes, o tal vez la
ms importante en el mercado laboral. Por lo que es necesario conocer
metodologas que ayuden a pulir las virtudes y eliminar los defectos que cada
persona pueda tener en la organizacin de sus tareas.
Esta es la razn por la que eleg este proyecto, requiero conocer la metodologa
de trabajo del PSP, para cumplir con las exigencias del mercado laboral y tener
mejores oportunidades y desempeos.









6

HIPOTESIS:

Al terminar de estudiar la metodologa del PSP, la estimacin del tamao, el
nmero de errores, el tiempo de desarrollo y la calidad del software habrn
mejorado en ms de un 50%.

METODOLOGA:

1. Estudiar previamente los temas del PSP.
2. Asistir a las sesiones y revisar junto con el asesor los temas del PSP.
3. Planteamiento de los ejercicios de trabajo.
4. Realizar los ejercicios de trabajo de cada uno de los temas del PSP.
5. Discutir los resultados de los ejercicios de trabajo con el asesor.
Para la realizacin de los programas se utilizo Visual Basic .Net 2005, para el
llenado de la bitcora se uso Excel y para las formas Word.





























7

PSP

La calidad de un sistema de software esta dada por el peor de sus componentes
y la calidad de un componente est dada por el individuo que lo desarrolla; esto
ltimo esta dado por conocimiento, disciplina y compromiso.
El PSP es un proceso personal para desarrollar software, se divide en tres
partes:
1. Pasos Definidos
2. Formas
3. Estndares
Es una lnea de trabajo de medicin y anlisis para ayudarle a caracterizar su
trabajo, as como un procedimiento definido que ayuda a mejorar el
desempeo.
El PSP se introduce en siete pasos compatibles y progresivos, se realizan uno o
dos programas en cada paso, esto con el objetivo de obtener y analizar los
datos; para mejorar el trabajo subsecuente.


Figura 1.1 Etapas del PSP


DESCRIPCIN DEL PROCESO
PSP 0 Se establece una lnea base de desempeo.
PSP 1 Se realizan planes sobre tamao, recursos y calendario.
PSP 2 Se prctica la administracin de defectos y del yield.
PSP 3 Se escalan los mtodos de PSP a proyectos ms grandes.



8

Figura 1.2 Mapa de las formas del PSP, plantillas y estndares.

1.1 PSP0
Es un proceso personal simple y definido, utiliza los mtodos de diseo y
desarrollo actuales del participante.

Genera datos acerca su trabajo:
Tiempo utilizado en cada fase.
Defectos encontrados en la compilacin y en las pruebas.

Tiene como objetivos:
Demostrar el uso de un proceso definido, para programas pequeos.
Incorporar medidas bsicas en el proceso de desarrollo de software.

Los elementos que lo componen son:
Script de proceso.
Forma de resumen del plan de proyecto.
Bitcora de registro de tiempo.
Bitcora de reporte de defectos.
Estndar de tipos de defectos.

1.2 PSP0.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 LOCs), normalizar los defectos.
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.


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

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

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


1.5 SCRIPT DEL PROCESO
Planeacin.- Estimar el tiempo de desarrollo.
Desarrollo.- Realizar el producto utilizando sus mtodos actuales.
Diseo.
Codificacin.
Compilacin.
Pruebas.

Postmortem.- Completar el resumen del plan de proyecto, con el tiempo
utilizado y los defectos descubiertos e introducidos en cada fase.



10
1.6 FORMA DEL RESUMEN DEL PLAN DE PROYECTO
Proporciona un formato conveniente para registrar las mtricas PSP ms
importantes para un proyecto.


Figura 1.3 Forma del Plan de Proyecto PSP0

Encabezado: Introduzca los datos solicitados; nombre, programa, instructor,
fecha y lenguaje.
Tiempos: Registre el mejor estimado del tiempo total que tomar el desarrollo,
as como los minutos reales utilizados en cada fase.
Defectos: Ingrese el nmero de errores detectados y eliminados en cada fase.















11
1.7 BITCORA DE REGISTRO DE TIEMPO

Figura 1.4 Bitcora de Registro de Tiempo

Encabezado: Introduzca el nombre, fecha, instructor y nmero de programa.
Fecha: Registre la fecha actual.
Inicio: Ingrese la hora cuando inicie una fase del proyecto.
Alto: Registre los minutos que detuvo su trabajo durante una fase del proyecto.
Tiempo de Interrupcin: Ingrese cualquier tiempo que perdi debido a
interrupciones.
Tiempo Efectivo: Es el tiempo transcurrido entre los tiempos de Inicio y
Detencin menos el tiempo de Interrupcin.
Fase: Anote el nombre de la etapa en la que se encuentra trabajando (Diseo,
Desarrollo, Compilacin, etc.)
Comentarios: Descripciones de la interrupcin, la tarea que se realizo, cualquier
cosa que afecte su trabajo.


















12
1.8 BITCORA DE REGISTRO DE DEFECTOS


Figura 1.5 Bitcora de Registro de Defectos

Encabezado: Introduzca el nombre, fecha, instructor y nmero de programa.
Fecha: Ingrese la fecha cuando se encuentra y corrige el defecto.
Nmero: Registre un nmero nico para este defecto, inicie cada proyecto a
partir del nmero 1.
Tipo: Escriba el tipo de error a partir del estndar de tipo de defectos.
Introducido: Introduzca la fase durante la cual se puede establecer que el
defecto fue introducido.
Eliminado: Registre la fase en la cual se encontr y elimino el defecto.
Tiempo de eliminacin: Ingrese el tiempo que le tomo encontrar y eliminar el
defecto.
Defecto que resuelve: Si el error fue introducido mientras se estaba eliminando
otro defecto, registre ese nmero de error o una x si no sabe cual es.

1.9 ESTNDAR DE TIPO DE DEFECTOS
Proporciona un conjunto general de categoras de defectos, para poder llevar
un mejor control en la bitcora de defectos.
Los tipos de defectos PSP son:
10 Documentacin
20 Sintaxis
30 Componentes o configuracin
40 Asignacin
50 Interfaz
60 Chequeo de Tipos
70 Datos
80 Funcin o lgicos
90 Sistema
100 Ambiente



13
PSP2
2.1 USO DEL PSP2
El PSP2 tiene como objetivos introducir las revisiones de diseo y cdigo, as
como los mtodos para la evaluacin y mejora de la calidad de sus revisiones.
En esta etapa se introducen:
1. La lista de comprobacin de la revisin del diseo PSP2.
2. La lista de comprobacin de la revisin de cdigo.
Defectos en pruebas por KLOC, es un indicador de la calidad del programa que
se coloca en las pruebas.

Defectos en Pruebas/KLOC = 1000 * (Defectos Eliminados en Pruebas/ Total de LOCS nuevas y Modificadas)

2.2 REVISIONES DE DISEO Y CDIGO
Entre los mtodos para verificar nuestro software tenemos:
1 Inspecciones: Fueron introducidas por Fagan en IBM en 1976, siguen un
proceso estructurado y son tiles para requerimientos, diseos, casos de
prueba, planes y todo lo que se les parezca. Cuentan con las siguientes
caractersticas:
son realizadas por los compaeros.
los administradores no asisten.
cada participante tiene un papel definido.
el objetivo es encontrar problemas.
2. Recorridas: Siguen el formato de las juntas o reuniones. Son tiles para
aspectos de requerimientos o diseo del sistema.
La audiencia puede incluir compaeros, administradores u otras partes
interesadas.
El objetivo es comunicar u obtener la aprobacin.
No se requiere ninguna preparacin.


1. Revisiones: Es una forma de examinar personalmente su propio trabajo,
tiene el objetivo de descubrir y resolver los productos de manera temprana
en el proceso de desarrollo. Se usan para requerimientos, diseo y cdigo.
Un profesionista revisa de manera privada su producto.
El objetivo es encontrar defectos antes de la primera compilacin y las
pruebas.








14

2.3 MOTIVOS PARA REALIZAR REVISIONES
Es mucho ms eficiente encontrar defectos en las revisiones que en las pruebas.
En las pruebas unitarias, por lo regular slo se encuentran alrededor de 2 a 4
defectos por hora. En las revisiones de cdigo se encuentran de 6 a 10 defectos
por hora. Mientras que los revisores con experiencia pueden encontrar 70% o
ms de los defectos de un producto. Las pruebas unitarias rara vez exceden
50% de rendimiento (yield).

Los datos de PSP muestran que las revisiones encuentran de 2 a 5 veces ms
defectos por hora que las pruebas unitarias.

Despus de las pruebas unitarias, la eliminacin de defectos se vuelve ms
costosa.
En las pruebas de integracin y de sistema, toma de 10 a 40 horas de
programador encontrar y eliminar cada defecto.
Las inspecciones por lo regular toman menos de una hora por defecto.

Los defectos deben ser eliminados tan pronto como sea posible, por las
siguientes razones.
Cada revisin, inspeccin, compilacin y pruebas encuentran slo una
fraccin de los defectos.
Por lo mismo, mientras ms limpio sea el cdigo que entra a una fase,
ms limpio ser al salir de la misma.

La eliminacin temprana de defectos ahorra tiempo y dinero.
Los defectos son ms costosos mientras ms tarde se encuentren y
eliminen en el proceso de desarrollo.
Los defectos son mucho ms costosos cuando se encuentran y eliminan
despus de la terminacin del producto.

Otro punto a favor es que las revisiones son mucho ms eficientes, por ejemplo:
En las pruebas
usted inicia con un problema
entonces usted debe encontrar el defecto
en seguida, usted plantea una correccin
finalmente, usted implementa y prueba la correccin
Con las revisiones e inspecciones
usted ve el defecto
entonces usted plantea una correccin
Finalmente, usted implementa y prueba la correccin

En las pruebas, si el sistema produce un resultado inusual, usted debe


15
detectar que fue inusual
imaginarse lo que est haciendo el programa
encontrar en donde se est del programa
imaginarse qu defecto puede provocar tal comportamiento

Con las revisiones e inspecciones
usted sigue su propia lgica
cuando usted encuentra un defecto, usted sabe exactamente en
donde est
usted sabe qu debe hacer y qu no debe hacer el programa
usted sabe por qu ste es un defecto
usted est en una mejor posicin para plantear una correccin
efectiva y completa

2.4 LA ESTRATEGIA DE REVISIN EN EL PSP
El objetivo del PSP es producir la ms alta calidad de programa posible en cada
fase del proceso.
La estrategia de revisin para lograrlo es:
recolectar datos de sus revisiones
estudiar estos datos
decidir que le est funcionando mejor
ajustar su proceso de acuerdo con esto

Las revisiones en PSP siguen un proceso disciplinado con
criterios de entrada y salida
una estructura de la revisin
guas, listas de comprobacin y estndares
El objetivo de la revisin sugerido por el PSP es encontrar todo defecto antes de
la primera compilacin o prueba.
Para lograr ese objetivo, usted debe
usar estndares de codificacin
usar criterios que aseguren que el diseo es completo
medir y mejorar su proceso de revisin

Principios de la revisin de diseo:
1. Producir diseos que puedan ser revisados.
2. Seguir una estrategia explicita de revisin.
3. Revisar el diseo en etapas.
4. Verificar que la lgica implanta correctamente los requerimientos.






16

Producir Diseos que puedan ser revisados
Un diseo revisable tiene
un contexto definido
una representacin precisa
una estructura clara y consistente
Esto sugiere que
el propsito y funcin del diseo estn explcitamente establecidas
usted tiene un criterio para asegurar que el diseo est completo
el diseo est estructurado en elementos lgicos

Siguiendo una Estrategia de Revisin
La estrategia de revisin especifica el orden en el que usted revisa los elementos
de diseo.
Esto depende de la estructura del producto.
De esta forma, la estrategia de revisin debe ser considerada durante
el diseo.
El objetivo debe ser producir un diseo que pueda ser
revisado en etapas
probado en etapas
integrado en etapas

Revisar el Diseo en Etapas
Al revisar en etapas, usted asegura que todos los temas seleccionados se revisan
cuidadosamente.
Las etapas sugeridas de la revisin son las siguientes:
Revise que todos los elementos han sido diseados.
1. Verifique el flujo y la estructura del programa completo.
2. Revise que sean correctas las estructuras lgicas.
3. Revise para asegurar la robustez.
4. Revise las llamadas a funciones, mtodos y procedimiento para asegurar
su uso apropiado.
5. Revise variables especiales, parmetros, tipos y archivos para asegurar su
uso apropiado.

Verifique que la Lgica Implementa Correctamente los Requerimientos
Revise los requerimientos para asegurar que cada funcin requerida es tomada
en cuenta por el diseo.
Revise cuidadosamente por equivocaciones u omisiones.






17
2.5 MEDIDAS DE LAS REVISIONES
Medidas Explcitas:
tamao del programa que se revisa
tiempo de revisin
nmero de defectos encontrados
nmero de defectos no encontrados (los que se escaparon)
Medidas derivadas:
rendimiento (yield) de revisin (porcentaje de descubiertos)
LOC revisadas por hora
defectos descubiertos por KLOC
defectos encontrados por hora de revisin
influencia de la revisin

El rendimiento (yield) se puede definir como:
una medida de la calidad del proceso
el porcentaje de defectos en el producto al momento de la revisin que
fueron encontrados por la revisin
una medida de efectividad de un paso del proceso
revisiones de diseo y cdigo
del proceso completo (antes de las pruebas)
del proceso de desarrollo (incluyendo las pruebas)

Yield = 100 x (defectos encontrados) / (defectos encontrados + defectos no
encontrados)

El rendimiento no puede ser calculado hasta que todos los defectos hayan sido
encontrados a travs de las pruebas y el uso del producto.
El rendimiento puede ser til de manera temprana en el proceso si todos o la
mayora de los defectos estn contabilizados.
defectos en revisin de diseo y cdigo
defectos en compilacin
defectos en pruebas unitarias
El uso de datos del proceso y parmetros de control puede ayudar a asegurar
revisiones con altos rendimientos.

La DRL (Influencia de la eliminacin de defectos) mide la efectividad relativa de
un paso del proceso en la eliminacin de defectos, tambin es el nmero de
defectos eliminados por hora por un paso del proceso en relacin a un proceso
base. Usualmente se toma como base las pruebas unitarias (UT).
De esta manera DRL (X/UT) es la DRL para la fase X con respecto a las pruebas
unitarias.
La DRL se calcula como sigue:


18
DRL (X/UT) = (Defectos / hora fase X) / defectos / Hora Pruebas Unitarias)
Desafortunadamente estas medidas se encuentran disponibles hasta despus
de terminado el proceso.

La investigacin en PSP ha encontrado las siguientes correlaciones con el
rendimiento.
LOC/Hora: -0.63, con significancia > 0.005
defectos/hora: 0.14, con significancia de 0.25
defectos/KLOC: 0.47, con significancia de 0.01

Mientras que ninguno es bueno, LOC/Hora es el mejor.


Figura 6.4 Rendimiento vs LOC/Hora Estudiante 12.




19
Figura 6.5 Rendimiento vs LOC/Hora Estudiante 20.
Estos ejemplos muestran que las revisiones estructuradas pueden ser efectivas
si stas:
siguen un procedimiento definido
usan listas de comprobacin
estn configuradas para la experiencia en defectos de cada ingeniero
Para el PSP, una sugerencia como objetivo de control es no revisar ms
de alrededor de 200 LOC por hora.

2.6 CONSIDERACIONES DE LAS REVISIONES
Listas de Comprobacin se definen como los pasos de la revisin en el orden
sugerido de su realizacin.
Al revisar cada punto, es ms probable que esta se realice apropiadamente.
Construya una lista de chequeo personal que est ajustada a su experiencia de
defectos.

Revisin antes de compilar, el PSP exige revisiones de cdigo antes de la
primera compilacin, esto se debe a que:
El tiempo de revisin es el mismo si se hace antes o despus de la
compilacin.
Las revisiones de cdigo encuentra defectos que el compilador deja
pasar.
Las revisiones de cdigo compilado tiende a ser mucho menos efectivas.
El compilador es igualmente efectivo antes o despus de las revisiones.

El PSP usa la compilacin como un chequeo de la calidad de las revisiones.
SI se encuentran demasiados defectos en la compilacin, se requiere otra
revisin.
Si la compilacin es limpia, es probable que la mayora de los defectos
hayan sido encontrados.

Revisiones e Inspecciones
El principal objetivo de las inspecciones debe ser encontrar aquellos problemas
de requerimientos y diseo que usted no haya encontrado.
Cuando los programas tienen muchos defectos sencillos, los inspectores se
distraen y con frecuencia pierden problemas ms importantes.
Al revisar primero el cdigo
proporciona un producto de calidad para la inspeccin
muestra respeto al tiempo de los inspectores
produce inspecciones de ms alta calidad





20

2.7 CALIDAD DEL SOFTWARE
Hablamos de calidad del software, cuando este cumple con las necesidades del
usuario, para lograrlo el sistema debe ser:
Usable y conveniente
Econmico y entregado en tiempo
Slido y confiable
Cumplir los requerimientos de desempeo
Realizar las tareas requeridas

Un software solo puede ser usado cuando:
Se instala rapida y facilmente
Se ejecuta de manera consistente
Maneja apropiadamente los casos normales y anomales
No realiza cosas destructivas o inesperadas
Esta libre de defectos (en escencia)
Para lograr estos objetivos debe de llevarse a cabo un proceso de calidad. En el
PSP los defectos son la medida bsica de la calidad. Aunque estos no son
importantes para el usuario mientras no afecten operaciones, provoquen
inconvenientes, cuesten tiempo y dinero o causen perdida de confianza en los
resultados del programa.
Un contenido bajo de defectos es un prerrequisito esencial para un proceso de
calidad de software. Un contenido bajo de defectos puede obtenerse de mejor
manera al nivel de PSP.
El nivel PSP es donde los defectos son introducidos, y este es donde los
ingenieros deben
eliminarlos
determinar sus causas
aprender a prevenirlos

2.8 PRUEBAS E INSPECCIONES
Sin inspecciones y con un sistema de 50,000 LOC:
El sistema contiene 25+ defectos/KLOC al comienzo de las pruebas.
Eso significa 1250 defectos.
A un tiempo tpico de 10+ horas por defecto, eso es 12,500+ horas
programador.
Eso es 6 aos programador.
Si se planea apropiadamente, estas pruebas pueden realizarse en 12 a 15
meses.
Si no se planea, las pruebas pueden tomar 2 o ms aos.

Con inspecciones y un sistema de 50,000 LOC:


21
Las inspecciones toman alrededor de 10 horas programador por cada 250
LOC, o cerca de 2,000 horas.
Esto es un ao programador.
Si se hacen bien, las inspecciones pueden eliminar alrededor del 80% de
los defectos.
Esto significa que 250 defectos restaran para las pruebas.
Esto tomara alrededor de 2,500 horas, o un ahorro de
8,000 horas
4 aos programador

Con el PSP la calidad del cdigo es mejorada notoriamente, con lo cual se
pueden ahorrar miles de horas. Las inspecciones se siguen realizando, pero se
pone atencin en que sean realizadas sobre el diseo, esta ayuda a mejorar la
calidad del producto, logrando un calendario de trabajo ms predecible y
proporcionando el tiempo para atender los aspectos ms importantes de la
calidad.

2.9 EL COSTO DE LA CALIDAD (COQ)
Es una forma de medir la calidad de un proceso. El COQ tiene costos de las
fallas, de apreciacin, de prevencin.
Costos de las fallas; son la reparacin, reelaboracin y desechar. Incluyen todo
el tiempo de compilacin y pruebas.
Costos de apreciacin; incluyen todos los tiempos de revisiones de diseo y de
cdigo.
Costos de prevencin; incluyen encontrar y resolver las causas de los defectos,
deben de ser manejados antes de que el proyecto comience y considerarse
como un proceso y no una actividad.
En el PSP los costos de prevencin son:
especificacin formal o trabajo de diseo
Manejo de prototipos
Anlisis y mejora de procesos

Una medida til de COQ es la razn de los costos de apreciacin con los de falla
(A/FR). Esto es (COQ apreciacin) / (COQ falla)
Experiencia en A/FR
La medida A/FR no es ampliamente usada.
Si es medida, para la mayor parte de las organizaciones de software
sera cercana a cero.
En el PSP, A/FR debe exceder 2.0.
Una A/FR alta est asociada con nmeros bajos de defectos en
pruebas y con alta calidad de producto.




22
2.10 LA ESTRATEGIA DE LA CALIDAD
Se deben de identificar los objetos de calidad de su PSP, es decir:
Eliminar todos los defectos antes de la primera compilacin
Lograr alta productividad
Producir planes exactos

Tambin se deben establecer las mediciones de calidad de proceso del PSP, es
decir:
rendimiento del proceso completo
COQ de apreciacin vs. costos de fallas (A/FR)
LOC revisadas por hora
ndice de desempeo del costo (CPI)

Examine los proyectos que usted halla realizado.
1. Determine sus calificaciones de estas medidas.
2. Vea qu comportamientos han tenido un efecto en estos resultados.
Basado en estos datos, identifique las prcticas ms efectivas para su trabajo.
Incorpore estas prcticas en su proceso al utilizar:
scripts de proceso
listas de chequeo
formas

Identifique las medidas que predicen razonablemente la calidad del proceso.
Establzcalas como variables de control.
Defina las especificaciones para estas variables.
Dele seguimiento a su desempeo contra estas especificaciones.
Dele seguimiento a su proceso para determinar
si se cambian las especificaciones y cundo
acciones a tomar ms adelante para mejorar el proceso
Un mtodo para darle seguimiento a la mejora de procesos debe
considerar la calidad y la productividad
proporcionar un medio para comparar procesos usados por
diferentes personas u organizaciones
ser insensible a aspectos especficos de los proyectos
En el presente, las tcnicas de comparacin de software son dependientes del
proceso.
Sin embargo, an son tiles, en tanto,
se establezcan medidas objetivas
se les d seguimiento en el tiempo
las utilice para mejorar el proceso para el cual estn diseadas
Para usar las comparaciones se debe establecer un conjunto consistente de
medidas para evaluar el desempeo del proceso. Estas medidas deben de
tomarse en cada proyecto, adems debe de comparar los proyectos individuales


23
para determinar tendencias o problemas. En base a estas medidas se debern
establecer objetivos de mejora a corto y largo plazo.

2.11 ESTRATEGIAS DE ELIMINACIN DE DEFECTOS
Enfocar las inspecciones y revisiones en especialidades.
revisiones HLD: aspectos estructurales
revisiones DLD: correctez lgica
revisiones de cdigo: detalles de implantacin
Para ahorrar tiempo, no resuelva
aspectos de sistema en el DLD
aspectos de diseo en revisiones de cdigo

Haga pruebas unitarias rigurosas.
Revise todos los parmetros en valores normales, en los lmites y en los valores
fuera de los lmites.
Revise todos los ciclos y recursiones por terminacin normal y anormal.
Revise todas las dependencias entre procedimientos y objetos.

La prevencin de defectos es importante porque:
siempre es costoso encontrar defectos
si se pueden prevenir los defectos, se evitan estos costos
se incurre una sola vez en los costos del anlisis de prevencin de
defectos, pero ahorran tiempo para todo el proyecto
La prevencin de defectos debe seguir una estrategia ordenada y un proceso
definido.
Para el PSP, las acciones de prevencin de defectos incluyen mtodos de diseo
mejorados y el uso de prototipos.
Para prevenir los defectos, se deben considerar aquellos tipos que se
encuentran con mayor frecuencia en las pruebas de integracin y en las pruebas
de sistema. Utilice los datos del PSP para elegir uno o dos tipos de defectos para
realizar con ellos una accin inicial.
No slo intente hacer un mayor esfuerzo; establezca acciones de prevencin
explcitas. Incorpore estas acciones en sus scripts de proceso, listas de chequeo
y formas.











24



Figura 7.1 Defectos de Pruebas por KLOC

Defectos totales por KLOC, es una medida del total de defectos introducidos
durante el proceso.
Defectos totales/KLOC = 1000 * (Total de Defectos Eliminados / Total de LOCS nuevas y Modificadas)


Figura 7.2 Defectos Totales por KLOC










25
El Rendimiento (Yield), es el porcentaje de defectos introducidos y eliminados
antes de la 1era. Compilacin.
Rendimiento(total) = 100 * (Defectos Eliminados antes de compilar / Defectos introducidos antes de Compilar)



Figura 7.3 Rendimiento (Yield)

Los intervalos de prediccin inferior y superior del tamao del programa son
calculados usando el mtodo descrito anteriormente.
Estos valores slo se calculan si se usa el mtodo A o B de PROBE.


Figura 7.4 Intervalos de prediccin superior e inferior del tamao del programa




26

Los intervalos de prediccin inferior y superior del tiempo de desarrollo se
calculan usando el mtodo descrito anteriormente.
Estos valores slo se calculan si se usa el mtodo A o B de PROBE.


Figura 7.5 Intervalos de prediccin superior e inferior del tiempo de desarrollo

Al PSP2 se le agrega el tiempo en fase de las revisiones de diseo y cdigo.
Sino ha proporcionado datos histricos personales para estas fases, pueden
utilizarse datos comparativos de PSP para estimar el tiempo de la fase.


Figura 7.6 Datos histricos personales















27

2.12 ESTIMANDO EL TIEMPO DE REVISIN
Pueden usarse estos comparativos de PSP para estimar el tiempo en fase de la
revisin de diseo y revisin de cdigo.

Comparativa Objetivo de Planeacin
Tasa de revisin de cdigo < 200 LOC/Hora
Tasa de eliminacin de defectos
revisin de diseo
revisin de cdigo
Tasa de eliminacin de defectos
3 a 5 defectos/hora
5 a 10 defectos/hora
A/FR (Tasa de appraisal to failure) 2.0

Tiempo de la Revisin de Cdigo = LOCs Nuevas y Modificadas Planeadas / 200
*
60

Para agregar el tiempo de revisin a su plan:
incremente los minutos totales.
reduzca los tiempos de compilacin y pruebas.
Como una comprobacin final de su estimado, asegrese que:
las tasas de revisin son menores a 200 LOC por hora
las tasas de eliminacin de defectos estn entre
o a 3 por hora para la revisin de diseo
o a 10 por hora para la revisin de cdigo
A/FR es de alrededor de 2.0

2.13 TIEMPO EN FASE A LA FECHA Y % A LA FECHA
La introduccin de revisiones PSP modificar la distribucin histrica del tiempo
de desarrollo.
Para corregir el A la Fecha y % A la Fecha
Con el PSP2 reinicie A la Fecha y % A la Fecha
Use tanto los valores anteriores como los nuevos para el tiempo en fase
planeado para las revisiones de diseo y cdigo.


Figura 7.7 Tiempo en fase a la fecha y % a la fecha



28
En PSP2 se planean los defectos introducidos y eliminados por fase.



Figura 7.8 Planeacin de Defectos introducidos y eliminados por fase

Para estimar los defectos introducidos y eliminados por fase se debe:
1 Estimar el tamao del programa.
2 Calcular los defectos totales planeados.
3 Usar los datos histricos de % a la fecha para distribuir los defectos-
Adems se utilizara la formula Defectos totales planeados = (LOC nuevas y
modificadas totales * Defectos totales a la fecha/KLOC)/1000

Si no existen datos histricos para las fases de revisin de diseo y de cdigo,
entonces los defectos introducidos son 0 y los defectos eliminados son 0
alguna pocin de los defectos que son eliminados por fase.

Las revisiones modificaran la distribucin histrica de defectos, de tal forma que
con el PSP2 se inicializan el a la fecha y el % a la fecha.














29
2.14 EFICIENCIA Y OPORTUNIDAD DE ELIMINACIN DE DEFECTOS
La eficiencia de eliminacin de defectos muestra el nmero de defectos
eliminados por hora para:
revisin de diseo
revisin de cdigo
compilacin
pruebas

La eficiencia de eliminacin de defectos se calcula usando la frmula:
Defectos Eliminados en la Fase / Tiempo en la Fase
*
60



Figura 7.9 Eficiencia de eliminacin de defectos

La oportunidad de eliminacin de defectos compara la eficiencia de eliminacin de las fases de
revisin de diseo, revisin de cdigo y compilacin con la fase pruebas unitarias.
Oportunidad de eliminacin de defectos es la divisin:
(defectos eliminados por hora de una fase de revisin o compilacin) / (los defectos
eliminados por hora en las pruebas unitarias).


Figura 7.10 Oportunidad de eliminacin de defectos











30
PSP3
3.1 PSP3
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 divide el programa en elementos ms pequeos y
establece la estrategia de desarrollo que determina los pasos cclicos.


3.2 EL PROCESO DE SOFTWARE EN EQUIPO (TSP) Y SU USO
Este proceso identifica las tareas clave del proyecto y :
las relaciona unas con otras
establece criterios de entrada y de salida
asigna roles a los miembros del equipo
establece las mediciones del equipo
establece las metas y los criterios de calidad del equipo

Tambin proporciona una lnea de trabajo dentro de la cual pueden relacionarse
los PSPs individuales;
o define la interfaz equipo/PSP.
o establece estndares y mediciones.
o especifica dnde y cundo usar inspecciones.
o establece las guas para la planeacin y los reportes.

Implicaciones Personales del PSP
Si se busca la excelencia personal, el PSP puede ayudar a obtenerla, ya que al
definir y medir el trabajo, se obtiene el conocimiento para mejorar el
desempeo personal. El PSP proporciona una lnea de trabajo adecuada y un
conjunto de mediciones para examinar de manera crtica este desempeo.
Tambin lo ayudara a desempearse profesionalmente, an cuando las dems
personas con las que trabaje no lo hagan.





Los costos del PSP
El proceso de desarrollo toma alrededor de una a dos horas por forma y guin.
Las actualizaciones al proceso sern necesarias al menos cada tres meses.
La captura y anlisis de datos tomarn alrededor de una hora por cada proyecto
dimensionado con PSP.


31
Adems el PSP toma mucho trabajo, y hay varias frustraciones, ya que
claramente se visualizan las limitaciones propias. Si no puede encarar estas
limitaciones, entonces no debe de usar el PSP.

Los beneficios del PSP
Se comprenden las fortalezas y debilidades, se reafirma el control sobre uno
mismo, son potenciadas las habilidades crticas y se ven muchas formas de
mejorar el desempeo. Adems los planes son ms confiables y siempre se
puede saber el estatus en el que se encuentra. Se visualiza donde y como se ha
mejorado.

Uso del PSP en una organizacin
Para introducir el PSP en una organizacin deben de considerarse las siguientes
situaciones:
El programador aislado utilizando el PSP.
El equipo aislado utilizando el PSP.
La adopcin general de la organizacin del PSP.

Programador aislado utilizando el PSP
Es difcil mantener la disciplina personal sin el apoyo de los colegas y los
administradores.
Es fcil desanimarse por la lentitud del avance personal.
Sus colegas pueden burlarse de usted por desperdiciar su tiempo con el PSP.
Por estas razones hasta que no se tengan datos para apoyar los beneficios del
PSP lo mejor es hablar poco de l.

El equipo aislado utilizando el PSP
Cuando su equipo haya sido entrenado en el PSP, usted tendr una poderosa
base de apoyo.
Ser capz de:
revisar el trabajo de otros
compartir ideas y resultados de mejora de procesos
celebrar el xit
tener apoyo cuando usted lo necesite

Debe ser cauteloso con respecto a mostrar el trabajo a otros, ya que estos
pueden criticar su trabajo y esto puede llevar a discusiones, incluso si los
resultados son superiores puede provocar que los dems equipos se encuentren
a la defensiva.
Introduccin del PSP en una organizacin
El acercamiento ms efectivo es implantar el PSP en toda la organizacin.
Para este acercamiento es necesario el apoyo de la organizacin:
1. educacin y entrenamiento


32
2. bases de datos y anlisis
3. definicin de procesos
4. herramientas
Para obtener el apoyo, usted necesitar el compromiso y soporte de la alta
direccin. Para lograrlo se debe mostrar que el trabajo es un prototipo para
toda la organizacin, adems de datos que muestren el beneficio del PSP en su
equipo.

Adems es necesario que el PSP sea introducido con un curso formal, donde
todos los profesionales participen voluntariamente, con tiempo suficiente para
que los ingenieros trabajen y los directivos proporcionen estmulo y apoyo
semanal para que los ingenieros terminen los ejercicios del PSP.

No intente introducir el PSP sin apoyo, ya que se requiere tiempo para tomar el
curso del PSP y para hacer los ejercicios y se requiere un instructor con
experiencia, adems el apoyo al curso requiere al menos 75% del tiempo de un
ingeniero.

3.3 ENTRENAMIENTO Y MEJORA
Un entrenador puede ayudarle a mejorar su desempeo personal al:
motivar un desempeo superior.
demandar el compromiso personal.
insistir en una dedicacin a la excelencia.
apoyar y guiar su desarrollo.
Busque el apoyo de entrenamiento de sus colegas y sus jefes.
Con frecuencia es sorprendente que logremos nuestros objetivos en formas que
no esperamos, de tal manera que hay que mantener una mente abierta y seguir
buscando. Ya que todos buscamos el mismo fin, debemos concentrarnos en el
camino. Si podemos ocasionalmente lograr la excelencia, bien podra valer la
pena el esfuerzo.

Recuerda que el PSP est diseado para ayudarte, por esta razn hay que
utilizarlo para mejorar el desempeo y para actuar profesionalmente en
situaciones difciles. Enfatiza lo que el PSP ha hecho por ti e impulsa a otros a
descubrir por s mismos lo que har por ellos.










33
4.1 REPORTE 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 ndice 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.

R5 Script del Proceso del Reporte

Fase # Propsito Para guiar el anlisis y la escritura del reporte R5.
Criterio de Entrada Programas 1A a 10A 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.
2 Desarrollo 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
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.
3 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.
Criterio de Salida Reporte R5 completo.
Resumen del Plan completo.
Bitcora de registro de tiempo completa.




34
R5 Resumen del Plan de Reporte

Estudiante Daniel Zanabria Gonzlez Fecha 09/04/2006
Instructor Luis Fernando Castro Careaga

Datos de Tamao Estimacin de Esfuerzo

Objeto Nmero
Planeado
Nmero
Real
Esf. Est. por
Objeto
Esfuerzo
Estimado
Grficas 15 12 13 195
Parrafos 30 32 10 300
Tablas 10 4 7 40






Total 55 48 Total 30 535


Datos de Esfuerzo

Fase Tiempo Planeado Tiempo Real
Planeacin 10 15
Diseo 18 23
Desarrollo 400 422
Postmortem 15 17
Total 443 477















35

Bitcora de Registro de Tiempo R5

Estudiante: Daniel Zanabria
Gonzlez
Fecha: 09/04/2006

Fecha Inicio Alto Tiempo de
Interrupcin
Tiempo
Efectivo
Fase Comentarios
09/04/06 10:35 10:50 Ninguno 15 Planeacin Se realiz la
planeacin.
09/04/06 10:55 11:18 Ninguno 23 Diseo Se realiz el
diseo.
09/04/06 11:21 13:58 Descanso 152 Desarrollo Se realizo parte
del desarrollo.
09/04/06 21:30 00:00 Descanso 140 Desarrollo Se realizo parte
del desarrollo.
10/04/06 09:40 12:00 Descanso 130 Desarrollo Se termino el
desarrollo.
10/04/06 12:10 12:22 Ninguno 17 PostMortem Se realizo la
postmortem.






























36

4.2 ANLISIS DE LA EXACTITUD DE ESTIMACIN DE LOC
Alcance las metas propuestas en el reporte R4 para la estimacin de tamaos? Por
qu si porque no?


Figura 10.12 Error en el estimado de tamao


No, la meta propuesta en el reporte R4 (error menor al 15%) no se cumpli. Esto a
pesar de que en la tarea 7, el error fue del -12.04%, en la 8 empeoro un poco -22.95% y
desafortunadamente en la tarea 9 y debido a las prisas y presiones este error se fue
hasta el -49.87%, logre recuperar un poco en la tarea 10 con un error del -14.10%,
desafortunadamente no fue suficiente y en todos los casos se subestimo el tamao.
El error absoluto promedio se ubica en 24.74%, se mejoro con respecto a los primeros
seis programas, lo cual me deja muy satisfecho, a pesar de que no fue suficiente para
cumplir el objetivo final.

Cmo fue mi estimado con respecto a los intervalos de prediccin del 70% (90%)?
Como utilice el mtodo D a partir de la tarea 7, los estimados con respecto al 70% y
90% fueron nulos.

Qu tendencia tuve acerca de sobreestimar subestimar a los objetos?
Mi tendencia es subestimar, ya que al considerar los mtodos de una clase, as como
los parmetros que recibir, generalmente quedo abajo, esto ocurre debido a que no
analizo correctamente la complejidad de los objetos.







37


Qu tendencia tuve al calcular mal el tamao relativo de los objetos?
Tiendo a estimar un menor nmero de LOC para los objetos, esto se debe a que no
identifico correctamente los parmetros, o bien las estructuras de datos que se usaran
en cada uno de ellos.

Para calcular un tamao relativo, necesito usar mi informacin histrica de los
objetos? Puedo?
Por supuesto, conforme voy avanzando en el conocimiento y al encontrarme con
problemas similares, puedo identificar ms o menos cuantas locs requiero para
realizar ciertos objetos.

Basado en mi informacin histrica de la estimacin de tamao, Cul es una meta
real de la estimacin de tamao para mi?
Estimar tamaos con un rango de 20 a 70 locs, no importa si se sobreestima o
subestima, ya que al ser pequeo (el rango) los riesgos son bajos.

Qu puedo cambiar en el proceso que me ayude a alcanzar las metas?
Considero que el proceso es adecuado, lo que provoco las fallas que tuve, fue la falta
de disciplina y las prisas, ya que empec retrasado en el curso y estudie a marchas
forzadas las diapositivas, as como las primeras tareas fueran realizadas con mucha
presin. Creo que al aprender a ser ms organizado, as como una mejor
administracin del tiempo se ira mejorando sin necesidad de modificarle nada al
proceso.
























38
4.3 ANLISIS DE LA EXACTITUD DE ESTIMACIN DE TIEMPO
Alcance las metas propuestas en el reporte R4 para la estimacin de tiempos? Por
qu si porque no?


Figura 10.13 Error en el estimado de tiempo
A pesar de que existi un pico bastante grande en la tarea 9, considero que se mejoro
notablemente la estimacin de tiempo, ya que en los programas (2,3,4 y 5) siempre
estuve con un error de ms del 35% y en los ltimos 4, y a pesar del pico del 31% del
programa 9, siempre logre un % de error menor al 10%, logrando grandes resultados
en la tarea 8 y 10.

Cmo fue mi estimado de prediccin con respecto a los intervalos de prediccin del
70% y 90%?

TAREA UPI (70%) LPI (70%) TIEMPO ESTIMADO
7 387 557 472
8 302 143 222
9 317 188 252
10 335 208 271

Como se puede observar en la tabla, el estimado de tiempo siempre quedo dentro del
estimado de prediccin.










39
Mi productividad es estable? Por qu si por que no?


Figura 10.14 Productividad

Como se observa en la grfica, la productividad no fue estable, cambio de un programa
a otro ya sea subiendo o bajando y tristemente solo dos veces logre estar por encima
de 30 LOCs por hora.

Cmo puedo estabilizar mi productividad?
La productividad es valorada desde la fase de planeacin y hasta el postmorten, la
experiencia me dice que puedo codificar fcilmente por arriba de 30 locs por hora,
pero los resultados del PSP indican que esto solo ocurri dos veces en todo el curso,
entonces Qu sucedi? Considero que las revisiones, as como el manejo de las
plantillas y el Excel me costo trabajo, lo cual se reflejo terriblemente en mi
productividad.

Cmo fueron afectados mis estimados de tiempo, por la precisin de mis estimados
de tamao? (Me ayudo la regresin multiple?)
No me afecto tanto la estimacin de tamao, ya que la productividad abarca todo el
proceso y no solo la codificacin, la grfica representa todo el trabajo realizado en
toda la tarea, expresandolo en LOCs por horas, mucha gente podra pensar que solo
incluye la codificacin, y si fuera cierto si afectara mi estimado de tamao.

Basado en mi informacin histrica de la estimacin de tiempo, Cul es una meta
real de la estimacin de tiempos para mi?
Una meta sera lograr predicciones sobreestimadas con un rango de error de 60-120
minutos, esto me ayudara muchsimo en el mercado laboral, al poder indicarle a mis
jefes tiempos bastante exactos y siempre por encima del tiempo ocupado.




40
Qu puedo cambiar en el proceso que me ayude a alcanzar las metas?
Tal vez redisearia las plantillas y el Excel, para que fueran ms fciles de llenar, por
que a mi en lo particular me costo trabajo e invert mucho tiempo en entenderlas.

4.4 ANLISIS DE DEFECTOS Y DEL YIELD
Qu tipo de defectos inyecte durante el diseo y la codificacin?

TIPO DISEO CODIFICACIN
10 0 0
20 10 13
30 2 0
40 1 14
50 0 0
60 0 0
70 5 3
80 0 3
90 0 0
100 1 0
19 33

Ms del 50% de los defectos que introduje en el diseo, fueron de sintaxis (20) 5%
correspondieron a datos (70).
Para la codificacin la mayora de errores fue de asignacin (40), mientras que los de
sintaxis ocuparon el segundo lugar.


Cul fue la tendencia de los errores por KLOC, encontrados en las revisiones,
compilacin y pruebas?
La cantidad de errores eliminados en las revisiones fue bastante buena, ya que se
hallaron errores que al compilar hubieran causado problemas, debido a que la mayora
de ellos era de asignaciones.



41
Figura 10.15 Defectos eliminados en la revisin de Diseo

La revisin de cdigo fue irregular, ya que en algunos casos, la compilacin fue
perfecta debido a los errores encontrados en esta fase, pero en otros se realizo (la
revisin) demasiado rpido o sin el cuidado adecuado y su efectividad fue nula, lo que
provoco errores en la compilacin.


Figura 10.16 Defectos eliminados en la revisin de Cdigo


La realizacin de las tareas 9 y 10 estuvo cargada de las presiones conjuntas debidas al
fin de trimestre, lo que provoco que la racha perfecta de 5 tareas se arruinara; creo
que sin prisas soy muy bueno para compilar y revisar el cdigo en etapas anteriores.


Figura 10.17 Defectos eliminados en la Compilacin



42
En la fase de pruebas se vuelve a presentar la irregularidad y los picos, aunque cerre de
manera perfecta en la tarea 10.


Figura 10.18 Defectos eliminados en las pruebas

La tendencia creo que es positiva, aunque cargada de irregularidad, debido a las prisas
y mala planeacin.

Cul es la tendencia evidente en el total de defectos por KLOC?


Figura 10.18 Total de Defectos

En las primeras etapas del proceso la tendencia fue positiva, ya que el nmero de
defectos estuvo disminuyendo constantemente, desafortunadamente para la parte
final del curso se produjo un punto de inflexin y lo que se haba logrado se perdi.
Esto podra indicar que el proceso no funciono, pero creo ms bien que la dificultad de


43
los ltimos programas y las prisas provocaron que la codificacin no fuera tan buena
como me hubiese gustado.

Cunto es mi tasa de defectos eliminados (defectos eliminados por hora)
comparado con la revisin de diseo, revisin de cdigo, compilacin y pruebas?


Figura 10.19 Tasa de Defectos eliminados por Fase


La dificultad de los ltimos 4 programas provoco que mi lnea invicta de 4 tareas sin
errores en la compilacin se viera arruinada, a pesar de esto considero que si no se
hubiesen implementado la revisin de diseo y de cdigo el nmero de errores en la
fase de compilacin hubiese sido mayor de la que se aprecia en la grfica.

Cul es la influencia en mis defectos eliminados para las revisiones de diseo,
revisiones de cdigo, y compilacin contra pruebas unitarias?
Gracias a que las pruebas unitarias son hechas despus de las revisiones de diseo y de
cdigo, y obviamente una vez que se ha terminado la fase de compilacin, esto
provoca que el nmero de errores hallados en esta fase disminuya considerablemente
y sea mucho mejor. Esto ayudara en la vida laboral, ya que cuando se fuese a entregar
el producto para que el usuario lo revise, este tendra una calidad bastante aceptable,
ya que los cambios solicitados por el usuario seran mnimos.












44
Cmo son las tasas de revisin (LOC/revisadas por hora) para la revisin de diseo y
codificacin?


Figura 10.20 LOCs revisadas por Hora

Programa Tasa de Rev. Diseo
(LOC revisadas/hora)
Tasa de Rev. Cdigo
(LOC revisadas/hora)
Tasa de Rev. De
ambas
7 381.14 221.69 140.16
8 310.75 382.97 171.55
9 130.43 136.36 66.66
10 198.46 271.57 114.66

Como se puede observar en la tabla, recin se introdujeron las fases de revisin de
diseo y de cdigo, y al ser algo completamente nuevo, no se les tomo la seriedad
necesaria y se revisaron una buena cantidad de loc por hora. Para la parte final y con
ms experiencia en el manejo de ambas se disminuyo este valor por uno ms realista.
Creo que un promedio para ambas arriba de 100, pero debajo de 150 es un buen
equilibrio entre productividad y calidad.
















45
Hay alguna relacin entre el yield y la tasa de revisiones de diseo y cdigo?


Figura 10.21 LOCs revisadas por Hora vs Yield (Diseo y revisin de Cdigo)

Al observar la grfica me indica (en tres programas) que el rendimiento es mayor
cuantas ms horas se revisan por hora, sin embargo hay un caso donde el nmero de
locs por hora revisados es el ms grande, sin embargo la productividad es la ms baja.
Por lo que no estoy seguro.

Hay alguna relacin entre el yield y el A/FR para los programas 7 al 10?


Figura 10.22 Relacin Yield y el A/FR









46
Programa Yield A/FR
7 71.42 15.72
8 14.28 9.57
9 28.57 13.59
10 44.44 17.04

Al revisar las grficas, podemos ver que el comportamiento de las curvas es anlogo,
pero al observar los valores de las tablas, no veo ninguna relacin entre ambos, por lo
que no estoy seguro.

4.5 ANLISIS DE LA CALIDAD
Alcance las metas propuestas en el reporte R4 para la calidad? Porque si o Porque
no?

Figura 10.23 Defectos introducidos en el Cdigo

No, por que al final el nmero de defectos encontrados en la codificacin, regreso a los
niveles del programa nmero 2, aunque personalmente siento que he mejorado
mucho, ya que los errores cometidos al final se los atribuyo a las prisas, as como a
trabajar en la noche o sin el descanso adecuado.

Cmo puedo juzgar la calidad de mi producto final en el ciclo de desarrollo?
Si nos dejramos llevar por los datos de las ltimas tres tareas, se podra pensar que la
calidad es igual de mala que en el programa nmero 2, ms sin embargo no hay
comparacin entre la complejidad de este y la del programa 8,9 o 10. Por lo que creo
que la calidad de mis productos ha mejorado bastante.

Estoy encontrando mis defectos en las revisiones de diseo y codificacin? Porque
si o porque no?
No, por que a diferencia de las tareas anteriores (1 a 6), en las que hubo compilaciones
en las que se tuvieron cero errores, en las ltimas 4 se introdujeron bastantes fallas en
la compilacin, lo cual lo atribuyo a una mala planeacin de los tiempos para realizar
las tareas.


47

Qu puedo hacer para que mi proceso sea ms efectivo y eficiente?
Practicarlo constantemente en la vida diaria, ya que conforme nos vamos
familiarizando con el proceso, sus plantillas y pasos se empiezan a manejar de manera
inconciente. Otra cosa que hara sera planear adecuadamente mis tiempos y trabajar
en momentos en los que no me encuentre agotado mental o fisicamente.

Basado en mi informacin histrica, Cules son las metas de calidad para mi?
Convertirme en una persona que trabaje con regularidad y que deje de tener los picos
que obtuve en la parte final del programa, ya que esto da la impresin de que puedo
trabajar de una manera excelente o tener un desempeo bastante cuestionable.
Por otra parte requiero trabajar ms en el diseo, para evitar correcciones sobre la
marcha y tener una codificacin ms amigable y productiva.
Me gustara bajar a menos de 15 defectos por KLOC y mantenerme por encima de los
30 LOCs por hora de codificacin fcilmente y por que no alcanzar valores de 70 LOC
por hora.

En que debo cambiar mi proceso para que mis metas se cumplan?
El PSP es un excelente proceso, no en vano cuenta con los apoyos de instituciones tan
importantes como el departamento de defensa de los E.U.A.
El que fallo fui yo, por lo que soy yo quien debe cambiar sus hbitos de trabajo.
Qu hbitos?
Familiarizarme con el lenguaje.
Poner atencin en los requerimientos.
Evitar las distracciones mientras se esta trabajando.
Organizar de una manera ms eficiente mis tiempos.
Aprender a trabajar bajo presin, para mantener resultados dentro de rangos
aceptables y evitar los picos de la parte final.
En resumen muchisima disciplina, no dejar para maana lo que se puede hacer hoy, ya
que esto provoca que los tiempos me ahorquen y la calidad y productividad se
desplome.

















48
CONCLUSIONES
El PSP es un proceso con una curva de aprendizaje amigable, ms sin embargo las
diapositivas y ayudas estn tan bien explicadas que puede ocurrir que el alumno
subestime el proceso y realice de manera incorrecta los pasos.
Yo fui una de estas personas, aunque al final mejore en la aplicacin de los pasos del
proceso, pero descuide algunas reas de la codificacin, creo que esta es la principal
razn por la que existen los lderes de proyecto y analistas de sistemas, para que los
programadores se concentren en la codificacin y no se preocupen por el avance del
proyecto.
Cuando realice algn sistema es casi probable al 100% que utilice el PSP para su
implementacin, otra de las ventajas del PSP es que no esta amarrado a la
construccin de un sistema y puede ser aplicado por un deportista, una ama de casa o
cualquier tipo de profesionista.

ACTUALIZACIN 2011
Solo en una ocasin he podido aplicar el PSP, y eso fue casi inmediatamente que
termine el curso, (en las elecciones del 2006) estuve trabajando para el PAN y las
personas a las que les reportaba tenan un conocimiento nulo en sistemas, lo cual me
ayudo a establecer y a que ellos aceptaran los tiempos y modos que yo utilizaba.
El PSP me ayudo mucho en el desarrollo de los 3 sistemas que implemente para ellos,
ya que entregue productos de calidad en los tiempos establecidos por mi
anteriormente.
Desafortunadamente en trabajos posteriores nunca he podido implementar el PSP, ya
que los jefes presionan mucho en cuanto a las entregas y prefieren cumplir con los
tiempos y el alcance a costa de la calidad, lo que lleva a errores y correcciones cuando
el sistema ya se encuentra implementado.
Tengo experiencia con malos diseos desde la estructura y que incluso a la fecha no
han podido ser corregidos totalmente o si lo han hecho es con un nmero
interminable de parches y siempre rezando que no se vaya a descomponer otra cosa.
Tristemente veo poco apoyo de parte de las consultaras Mexicanas a este tipo de
procesos (llmese PSP, CMMI, MPROSOFT, etc.) lo que provoca grandes retrasos (me
han tocado hasta de un ao) sistemas difciles de mantener (malos diseos de
mtodos) e incluso gran cantidad de funciones redundantes.
Y es que el objetivo de las empresas Mexicanas es 100% el dinero y no la calidad del
software. Se que el dinero es importante, pero si logras una calidad buena, las
perdidas son menores a futuro y la imagen de la compaa y la persona se ve
beneficiada.











49
BIBLIOGRAFIA
[1] Programacin en Microsoft Visual Basic .NET para bases de datos Microsoft Access
Dobson, Rick
McGrawHill, 2003

[2] Anlisis y Diseo orientado a objetos con UML y el Proceso unificado
Schach, Stephen
McGrawHill, 2005