1

Personal Software Process (PSP)

TCIN CHRISTIAN HERNAN BEDOYA SUAREZ
2
Per l ft re Pr ess (PSP)
eam Soft are Process ( SP)
Creadas por Watts Humphrey (SEI)
Orgenes en CMM
Motivacin
Implementacin de CMM
Administracin de tiempo y Costo
Administracin de calidad
Reducir el tiempo de desarrollo
Estado Actual
En uso con muy buenos resultados
Efectividad en acelerar SPI
Diseminando esta tecnologa
3
Niveles Organizacionales
CMM
TSP
PSP
Organizacin
Equipos
Personas
4
Despus de la segunda guerra mundial, la estrategia de calidad en la
mayora de las organizaciones industriales se basaba casi por completo en
las pruebas. Las empresas establecieron departamentos especiales de la
calidad para encontrar y arreglar problemas despus de la produccin de
los productos.
No fu sino hasta los aos 70 y los aos 80 que W. Edwards Deming y J.M.
Juran convencieron a la industria estadounidense que se centrara en
mejorar la forma en la que la gente haca sus trabajos y desarrollaban sus
procesos. [ DEMING; 82 ], [ JURAN 88]
En los siguientes aos, este enfoque a los procesos de trabajo, ha sido
responsable de las mejoras importantes en la calidad de automviles, de la
electrnica, o de casi cualquier otra clase de producto.
La estrategia tradicional que haba de "prueba-y-arregla" ahora es
reconocida como costosa, que desperdicia tiempo y que adems es
ineficaz para el trabajo de la ingeniera y de la fabricacin.
5
Aunque la mayora de las organizaciones industriales ahora han adoptado
principios modernos de calidad, la comunidad del software ha continuado
confiando en la prueba como el mtodo principal de la administracin de la
calidad. Para el software, la primera medida principal en la direccin iniciada
por Deming y Juran fu tomada por Michael Fagan cuando en 1976 l introdujo
las inspecciones del software [ FAGAN; 86]
Usando inspecciones, las organizaciones han mejorado substancialmente la
calidad del software. Otra medida significativa en la mejora de calidad del
software fu tomada con la introduccin del modelo de capacidad de madurez
(CMM) en 1987.
El enfoque principal de CMM estaba en el sistema que administraba la ayuda
que se le proporcionaba a los ingenieros de desarrollo. CMM ha tenido un
efecto positivo en el funcionamiento de las organizaciones del software [
HERBSLEB; 97]
Otra medida significativa en la mejora de calidad del software fu tomada con la
esencia del proceso personal del software (PSP) ya que PSP ampla el proceso
de mejora a la gente que realiza el trabajo de desarrollo de software.
6
PSP se concentra en las prcticas de trabajo de los ingenieros en una
forma individual. El principio detrs de PSP es se, sirve para producir
software de calidad, cada ingeniero debe trabajar en la necesidad de
realizar trabajo de calidad.
PSP se dise para ayudar a profesionales del software
para que utilicen constantemente prcticas sanas de
ingeniera de software.
Asimismo les ensea a cmo planear y darle un seguimiento a su trabajo, a
utilizar un proceso bien definido y medido, a establecer metas mesurables,
y finalmente a la utilizacin del rastreo constante para alcanzar dichas
metas.
PSP les demuestra a los ingenieros a cmo manejar la calidad desde el
principio del trabajo, a cmo analizar los resultados de cada trabajo, y a
cmo utilizar los resultados para mejorar el proceso del proyecto siguiente.
[SEI; 2000] .
7
Un PSP es un proceso personal desarrollar
software.
pasos definidos
formularios
estndares
Un PSP es un marco de trabajo de medicin y
anlisis que te ayuda a caracterizar tu proceso.
Es tambin un procedimiento definido para
ayudarte a mejorar tu rendimiento.
8
La calidad de un sistema software est
condicionada por la calidad del peor de sus
componentes.
La calidad de un componente software est
condicionada por el individuo que lo desarroll.
Est condicionada por tu:
conocimiento
disciplina
compromiso
9
Como todo profesional software deberas
conocer tu propio rendimiento.
Deberas medir, seguir y analizar tu
trabajo.
Deberas aprender de tus variaciones de
tu rendimiento.
Deberas incorporar esas lecciones a tu
manera personal de hacer.
10
El diseo de PSP se basa en los siguientes principios
de planeacin y de calidad [HUMPHREY; 95]
Cada ingeniero es esencialmente diferente; para ser ms
precisos, los ingenieros deben planear su trabajo y basar
sus planes en sus propios datos personales.
Para mejorar constantemente su funcionamiento, los
ingenieros deben utilizar personalmente procesos bien
definidos y medidos.
Para desarrollar productos de calidad, los ingenieros deben
sentirse personalmente comprometidos con la calidad de
sus productos.
11
Cuesta menos encontrar y arreglar errores en
la etapa inicial del proyecto que encontrarlos
en las etapas subsecuentes.
Es ms eficiente prevenir defectos que
encontrarlos y arreglarlos.
La manera correcta de hacer las cosas es
siempre la manera ms rpida y ms barata
de hacer un trabajo.
12
Para hacer un trabajo de ingeniera de software de la
manera correcta, los ingenieros deben planear de la
mejor manera su trabajo antes de comenzarlo y
deben utilizar un proceso bien definido para realizar de
la mejor manera la planeacin del trabajo.
Para que los desarrolladores lleguen a entender su
funcionamiento de manera personal, deben medir el
tiempo que pasan en cada proceso, los defectos que
inyectan y remueven de cada proyecto y finalmente
medir los diferentes tamaos de los productos que
llegan a producir.
13
Para producir constantemente productos de
calidad, los ingenieros deben planear, medir
y rastrear constantemente la calidad del
producto y deben centrarse en la calidad
desde el principio de un trabajo.
Finalmente, deben analizar los resultados de
cada trabajo y utilizar estos resultados para
mejorar sus procesos personales.
14
Objetivo:
Conocer las mtricas de PSP.
Identificar los objetivos de cada nivel de
PSP.
15
El PSP es un proceso diseado para uso individual, basado
en una versin a escala de un proceso industrial.
El principal objetivo del PSP es ayudar a los ingenieros
software a hacer mejor su trabajo.
EL PSP se ha diseado tambin para demostrar el valor del
uso de un proceso definido y medido.
Por ultimo, el PSP intenta ayudar a los ingenieros y a las
organizaciones a que cumplan las demandas cada vez mas
estrictas para el desarrollo de sistemas software de calidad
16
El PSP se aplica en tareas personales
estructuradas:
Desarrollo de mdulos de programas.
Definicin de requisitos o procesos.
Realizacin de revisiones o pruebas.
Escritura de documentacin, etc.
El PSP se puede extender al desarrollo de sistemas
software de gran tamao.
Es un proceso de Nivel 5 para los individuos y es un
prerrequisito para el TSP
17
PSP se introduce con siete pasos
compatibles.
Escribes uno o dos pequeos programas
en cada paso.
Recoges y analizas los datos de tu
trabajo.
Los usas y analizas para mejorar tu
trabajo.
18
Comenzando con los requerimientos, el primer paso en el
proceso de PSP es la planificacin.
Existe un script de planificacin que sirve de gua y un
resumen del plan para registrar todos los datos del mismo.
Mientras los desarrolladores van siguiendo el lineamiento de
trabajo sugerido por los scripts, deben ir registrando los
tiempos dedicados y los datos de defectos en los logs de
tiempos y defectos.
Al final de la tarea, durante la fase de postmortem (PM),
deben resumir los datos de tiempo y defectos, medir el
tamao del programa, e ingresar esos datos en el formulario
de sumario del plan. Al finalizar, deben entregar el producto
finalizado y el formulario de sumario del plan completado.
19
20
21
Debido a que generalmente ciertos mtodos de PSP no son
utilizados por los desarrolladores, los mtodos de PSP son
presentados en una serie de siete versiones de procesos.
Estas versiones son denominadas como PSP0 a PSP3. Cada
versin tiene un mismo conjunto de logs, formularios, scripts,
y standards.
Los scripts de proceso definen los pasos de cada parte del
proceso, los logs y formularios proveen templates para
registrar y almacenar datos, y los standards guan a los
desarrolladores a mientras hacen el trabajo.
En otras palabras, PSP es un proceso que est diseado
para ser utilizado.
22
PSP 3
Desarrollo Cclico
PSP 3
Desarrollo Cclico
PSP 2
Revisin del cdigo
Revisin del diseo
PSP 2
Revisin del cdigo
Revisin del diseo
PSP 1
Estimacin del Tamao
Informe de pruebas
PSP 1
Estimacin del Tamao
Informe de pruebas
PSP 0
Proceso
PSP 0
Proceso
Medicin Personal
Planificacin Personal
Calidad Personal
Proceso Personal Cclico
23
PSP0 - estableces una lnea base del rendimiento
mensurable.
PSP1 - haces planes de tamao, recursos y
calendario.
PSP2 - Practicas gestin de defectos y
rendimiento.
PSP3 - Amplias los mtodos del PSP a proyecto
mayores.
24
PSP 0
Proceso actual
Registro de tiempo
Registro de defectos
Estndar de tipos de
defectos
PSP 0
Proceso actual
Registro de tiempo
Registro de defectos
Estndar de tipos de
defectos
PSP 0.1
Estndar de Codificacin
Medicin de Tamao
Propuesta de mejora del proceso
PSP 0.1
Estndar de Codificacin
Medicin de Tamao
Propuesta de mejora del proceso
PSP 1
Estimacin de tamao
Reporte de pruebas
PSP 1
Estimacin de tamao
Reporte de pruebas
PSP 1.1
Planeacin de tareas
Planeacin de tiempos de
actividades
Estndar de tipos de
defectos
PSP 1.1
Planeacin de tareas
Planeacin de tiempos de
actividades
Estndar de tipos de
defectos
PSP 2
Revisin de Cdigo
Revisin de Diseo
PSP 2
Revisin de Cdigo
Revisin de Diseo
PSP 2.1
Formatos de Diseo
PSP 2.1
Formatos de Diseo
PSP 3
Desarrollo Cclico
PSP 3
Desarrollo Cclico
Proceso
de
Medicin
Personal
Proceso
de
Planeaci
n
Personal
Administraci
n de Calidad
Personal
Proceso
Personal
Cclico
25
PSP0 es un proceso sencillo, definido y
personal.
Utiliza tus mtodos actuales de diseo y
desarrollo.
Recoge datos sobre tu trabajo:
tiempo gastado por fase
defectos encontrados en compilacin y
pruebas
Proporciona un informe resumen.
26
El paso inicial en PSP consiste en establecer
una base que incluya mediciones y un formato
de reportes. Esto permite medir el progreso y
define los cimientos para mejorar.
Esencialmente, PSP0 es el proceso habitual con
el que los desarrolladores escriben software,
mejorado para proveer mediciones.
27
Se pasa a PSP0.1 agregando un estndar de cdigo,
mediciones de tamao y el denominado PIP (Process
Improvement Proposal) (Propuesta de Mejora de
Procesos).
El PIP provee una manera estructurada de registrar
problemas, experiencias y sugerencias para mejorar.
PSP0.1 tambin mejora las mediciones para contar
separadamente mtodos y procedimientos.
28
PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega
estimaciones de tamao y recursos y un reporte de prueba.
En PSP1.1 se introduce planeamiento de cronograma y seguimiento del
proyecto. Los desarrolladores son enseados a:
Entender la relacin entre el tamao de los programas que escriben y el
tiempo que les toma desarrollarlos.
Aprender a realizar compromisos que puedan cumplir.
Preparar un plan ordenado para realizar su trabajo
Establecer una base para realizar un seguimiento de su trabajo.
Mientras que la importancia de estas tcnicas en proyectos grandes es
comprendida, pocos desarrolladores las aplican a su trabajo personal. PSP
demuestra el valor de estos mtodos en el nivel personal.
29
PSP2 agrega diseo personal y revisiones de
cdigo a PSP1. Estas revisiones ayudan a
encontrar defectos de manera temprana y a ver
los beneficios que esto proporciona. Los
desarrolladores analizan los defectos que
encuentran en los primeros programas y usan
estos datos para establecer checklists de
revisin que estn hechos a medida de su
experiencia de defectos personales.
30
El proceso de diseo es contemplado en
PSP2.1. El objetivo no es decirle a los
desarrolladores como disear sino orientar
el criterio para la finalizacin del diseo,
es decir, cuando han terminado que es lo
que deben haber obtenido. Se establece
un criterio de completitud de diseo y se
examinan varias tcnicas de verificacin y
consistencia de diseo.
31
Hasta este punto PSP se concentr en el
proceso lineal para construccin de
pequeos programas. PSP3 presenta
mtodos para ser usados por individuos
en la realizacin de programas de gran
escala. De todas formas sigue enfocado
en el individuo y no trata los problemas de
comunicacin y coordinacin que son una
parte importante del desarrollo de
sistemas de gran escala.
32
Para escalar PSP2 a proyectos ms grandes la
estrategia consiste en subdividir el proceso
personal de desarrollo de grandes programas
en elementos en la escala de PSP2. Estos
programas son entonces diseados para ser
desarrollados en pasos incrementales. La
primera construccin consiste en un mdulo
base o kernel que es ampliado en ciclos
iterativos. En cada iteracin se utiliza un PSP2
completo, incluyendo diseo, codificacin,
compilacin y pruebas.
33
Por qu hacer planes?
Te permiten llegar a acuerdos que tu puedas cumplir
Proporcionar las bases para acuerdo en tu trabajo
Gua tu trabajo
Te ayuda a seguir tu progreso
Terminacin del proyecto
34
1. La primera tarea consiste en definir los requerimientos,
describiendo el trabajo a realizar en el mayor detalle posible.
2. Como la etapa de planificacin es demasiado temprana como para
hacer un diseo completo del producto, los desarrolladores
realizan un diseo conceptual, mediante el cual se obtiene un
primer acercamiento de cmo debe basarse el producto a ser
construido en la etapa de desarrollo.
3. La siguiente tarea consiste en la estimacin de tamao y de
esfuerzo. La correlacin entre el tamao de un programa y tiempo
de desarrollo es moderadamente buena para equipos de
desarrollo; sin embargo, para un solo desarrollador, la correlacin
es generalmente un poco mayor. Los desarrolladores realizan las
estimaciones utilizando datos histricos personales de tamao y
productividad. En PSP, las estimaciones se efectan mediante el
mtodo PROBE (PROxy Based Estimating).
35
36
4. Una vez que los desarrolladores conocen el tiempo requerido para cada
proceso, deben estimar el tiempo que van a dedicar al trabajo cada da
de la semana, conformando entonces el calendario.
5. Luego, durante la etapa de desarrollo del producto, los
desarrolladores efectan el diseo detallado, la implementacin y las
pruebas.
6. Despus de completar el trabajo, los desarrolladores realizan un
anlisis postmortem, en el cual se actualiza el sumario del plan con los
datos reales de tiempos invertidos en cada etapa del desarrollo,
defectos encontrados y removidos, etc, y se comparan los resultados
obtenidos con lo planeado.
7. Finalmente, los desarrolladores registran toda esta informacin en sus
bases de datos histricas de tamao y productividad. Adems se
examinan las Propuestas de Mejoras (PIP) para hacer ajustes en los
procesos.
37
La Medicin del trabajo personal es el primer paso por el
que comienza el PSP. Es este primer paso los
ingenieros deben aprender como aplicar los formularios
del PSP y apuntar datos de su trabajo personal. Para
hacer todo esto se mide el desarrollo del tiempo y de los
defectos. Esto hace que los ingenieros recojan datos
reales y prcticos y les proporciona una serie de marcar
con las cuales ir midiendo el proceso.
Para realizar un trabajo con PSP se debe empezar por
el primer paso de medicin personal que incluye la
gestin del tiempo y el siguiente rastreo del mismo.
38
En PSP, los desarrolladores utilizan informacin para monitorear
su trabajo, la cual los ayuda a hacer mejores planes. Para esto,
deben recolectar datos de los tiempos que dedican a cada fase
del proceso, de los tamaos de los productos que producen, y de
la calidad de esos productos.
Las medidas bsicas de PSP son el tiempo que el ingeniero
utiliza en cada fase del proceso, los defectos introducidos y
encontrados en cada fase, y los tamaos de los productos
desarrollados en lneas de cdigo (LOC).
Estos datos se recopilan en cada fase del proceso y se resumen
a la terminacin del proyecto. Todos estos datos se utilizan para
proporcionar una familia de medidas de calidad de procesos que
los ingenieros usan como gua en su trabajo.
39
Las principales medidas son:
Tamao tiempo de estimacin de errores
Coste de realizacin
Defectos producidos y corregidos por hora
Produccin del proceso
Valoracin y calidad del costo de los fallos (COQ)
Valoracin del rango de fallos (A/FR)
40
Elementos
un guin de proceso
un formulario resumen de plan proyecto
un registro tiempo
un registro de defectos
un estndar de tipos defecto
41
Nmero
de Fase
Propsito Guiarte en el desarrollo de programas a nivel de mdulo
Entradas
Necesarias
* Descripcin del problema Formulario de Resumen del plan del Proyecto PSPO
Tablas de Registro de Tiempos y Defectos
Cronometro (opcional)
1 Planificacin Producir u obtener los requisitos
Estimar las LOC necesarias
Estimar el tiempo de desarrollo necesario
Indicar los datos del plan en el Resumen del Plan de Proyecto
Completar el Log de Registro de Tiempos
2 Desarrollo Disear el programa
Implementar el diseo
Compilar el programa y corregir todos los defectos encontrados
Completar la Tabla de Registro de Tiempos
3 Post-mortem * Completar el Resumen del plan del Proyecto con los datos actuales de tiempo, defectos
y tamao
Criterios de salida Un programa probado
Un resumen del Plan de Proyectos con los datos estimados y actuales
Las tablas de Registro de Tiempos y Defectos Rellenos
42
Planificacin
Estimar tiempo de desarrollo.
Desarrollo
Desarrollar el producto utilizando tus mtodos
actuales.
Post-mortem
Completar el resumen del plan proyecto, con los
tiempos gastados y defectos encontrados e
inyectados en cada fase.
43
Diseo
Disear el programa, usando tus mtodos de diseo
actuales.
Codificacin
Implementa el programa.
Compilacin
Compila hasta que este libre defectos.
Prueba
Prueba el programa y corrige todos los defectos.
Registra los defectos en el Log de defectos y
tiempos por fase en el Log de tiempos.
44
7 pasos y 4 niveles de mejoramiento
PSP0 + PSP0.1 Mtrica y estandarizacin
PSP1 + PSP1.1 Mejora la estimacin y
planificacin
PSP2 + PSP2.1 Incrementamos calidad
PSP 3 Repeticin para escalar a grandes
desarrollos
45
Estudiante: _Juan Lus Guerra_________ Fecha: _09/10/06__
Programa:_Raz Cuadrada_____________ Programa #: _1A
Instructor: _XX_______________________ Lenguaje: ___C____
Tamao del programa (LOC) Plan Actual
Total (Nuevas&Modificadas) 50 33
Tiempo en Fase (minutos) Plan Actual A la Fecha A la Fecha%
Planeacin 2 2 1.6
Diseo 0 0 0
Codificacin 53 53 44.2
Compilacin 20 20 16.7
Prueba 25 25 20.8
Postmortem 20 20 16.7
Total 240 120 120 100.0
Defectos Introducidos Actual A la Fecha A la Fecha%
Planeacin 0 0 0
Diseo 0 0 0
Codificacin 10 10 100
Compilacin 0 0 0
Prueba 0 0 0
Total 10 10 100
Defectos Removidos Actual A la Fecha A la Fecha %
Planeacin 0 0 0
Diseo 0 0 0
Codificacin 3 3 30
Compilacin 5 5 50
Prueba 2 2 20
Total 10 10 100
Despus del Desarrollo 0 0 0
46
Encabezado
Nombre, fecha, programa, instructor, lenguaje.
Tamao del Programa
Plan :Indica tu mejor estimacin del tiempo total
que tendr el desarrollo.
Actual :Indica el tiempo actual en minutos
gastado en cada fase.
47
Tiempo
A la fecha: Indica el tiempo total gastado en cada
fase hasta hoy. Para programa 1A, es el tiempo
gastado en el programa 1A.
A la fecha % :Indica el porcentaje del total tiempo
hasta hoy que se gasto en cada fase.
Defectos introducidos y removidos:
Indicar el nmero actual de defectos inyectados y
eliminados en cada fase.
48
Defectos
A la fecha: Indica el total de defectos
inyectados y eliminados en cada fase hasta
hoy. Para el programa 1A, son los defectos
inyectados y eliminados en el programa 1A.
A la fecha % :Indicar el porcentaje sobre el
total defectos inyectados y eliminados hasta
hoy en cada fase.
49
Fecha Inicio Fin Tiempo
de
Interrupci
n
Tiempo
Delta
Fase Comenta
rios
Estudiante: ____________________ Fecha: __________
Instructor:______________________ Programa #: ______
50
Encabezado
Indicar nombre, fecha, instructor y nmero de
programa.
Fecha
Indicar la fecha actual.
Inicio
Indicar el tiempo en minutos cuando empiezas
una fase del proyecto.
51
Fin
Indicar el tiempo en minutos cuando tu paraste tu trabajo
en una fase del proyecto, aun cuando tu no has terminado
esa fase.
Tiempo de interrupcin
Indicar el tiempo perdido por interrupciones desde el
periodo de arranque a parada.
Tiempo Delta time
Indicar el tiempo transcurrido desde el inicio al tiempo de
parada descontado el tiempo de interrupcin.
52
Fase
Anotar la fase en la que estas trabajando.
Use el nombre de cada fase.
Comentarios
Descripcin de la interrupcin
La tarea que estas haciendo
Cualquier aspecto significativo que afecte a tu
trabajo
53
Fecha Inicio Fin Tiempo de
Interrupcin
Tiempo
Delta
Actividad Comentarios
9/9 9:00 9:50 50 Planeacin
12:40 1:18 38 Diseo
2:45 3:53 10 58 Diseo Telfono
6:25 7:45 80 Codificacin
10/9 11:06 12:19 6+5 62 Codificacin Bao, tom caf
11/9 9:00 9:50 50 Codificacin
1:15 2:35 3+8 69 Compilacin Consulta de un libro
4:18 5:11 25 28 Prueba Reunin con mi jefe
12/9 6:42 9:04 10+6+12 114 Prueba Telfono, Bao, Telfono
13/9 9:00 9:50 50 Prueba
12:33 1:16 38 Postmortem
54
Uno de los problemas que se presenta a la hora de
gestionar el tiempo son las interrupciones. Es muy
normal que nos interrumpan por llamadas de telfono,
gente que viene a hablar con nosotros, o tenemos que
parar porque necesitan nuestra ayuda.
Cuando se producen estos casos se almacena este
tiempo en el Registro de Almacenamiento de Tiempo
anotndolo en la columna Tiempo de Interrupcin.
Durante este periodo no solo se anota el tiempo de la
interrupcin sino tambin porqu se ha producido en la
columna de Comentarios.
55
Ya que el tiempo de interrupcin no es un tiempo productivo
para el trabajo, se debe llevar un registro de las
interrupciones. El tiempo de las interrupciones suele ser
variable, por lo tanto si no se mide, se debera aadir un
nmero aleatorio para todos los datos de tiempo.
Estos datos de tiempo pueden ser tiles para comprender
mejor como es interrumpido el trabajo, ya que las
interrupciones no solo gastan tiempo, sino que rompen la
forma de trabajo y pueden provocar que se produzcan
errores. Conocer como son las interrupciones podra ayudar a
realizar un trabajo ms eficaz y de ms calidad.
56
El tiempo en desarrollar un producto se encuentra altamente
determinado por el tamao del mismo. En PSP, los
desarrolladores primero estiman el tamao de los productos
que planean desarrollar. Luego, al finalizar el producto, se
mide el tamao real obtenido.
Esta informacin permite a los desarrolladores realizar a
futuro una estimacin de tamaos ms precisa. Sin embargo,
para que esta informacin sea til, el tamao de las
mediciones debe corresponderse con el tiempo de desarrollo
del producto. En PSP, el tamao se mide en Lneas de
Cdigo (LOC).
Para realizar un seguimiento de la variacin del tamao de un
programa durante el desarrollo, se deben considerar varias
categoras de LOC.
57
Estas son:
Base (son los LOC iniciales del producto original)
Agregadas (es el cdigo agregado a un programa base existente)
Modificadas (es el cdigo base que es modificado en un programa existente)
Eliminadas (es el cdigo base que es eliminado de un programa existente)
Reutilizacin (es el cdigo tomado de una librera u utilizado, sin realizar
ninguna modificacin, en un nuevo programa)
Nueva Reutilizacin (esta medida cuenta los LOC que se agregan a una
librera)
Total (es tamao total del programa, independientemente del cdigo fuente).
58
Luego, para medir el tamao total de un producto, el
clculo es el siguiente:
Total LOC = Base Eliminadas + Agregadas +
Reutilizacin
Las LOC modificadas y de nueva reutilizacin no son
incluidas en el total; esto se debe a que las LOC
modificadas pueden representarse por LOC eliminadas
y agregadas, y las LOC de nuevo reutilizacin ya se
encuentran contabilizadas en las LOC agregadas.
59
El estndar de tipos de defectos proporciona un
conjunto general de categoras de defectos.
Aunque tu puedes reemplazar este estndar por
el tuyo propio, es deseable que te manejes con
estas definiciones simples de tipos hasta que
tengas datos que te puedan guiar en las
modificaciones.
60
61
Nombre: _______________________________ Fecha: ___
Instructor: ______________________________ Programa :__
Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado
10/10/06 1 40 CDIGO CODIGO 11
Descripcin: Agregar una variable a la estructura
Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado
10/10/06 2 20 CDIGO CODIGO 1
Descripcin: Variable multidefinida
Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado
10/10/06 3 10 CDIGO COMPILAR 1
Descripcin: Las comillas de la instruccin de impresin no existen
Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado
10/10/06 4 10 CDIGO PRUEBA 39
Descripcin: Alinear y agregar instrucciones de impresin , mejorar la apariencia
62
Encabezado
Indicar el nombre, fecha, instructor, y numero de
programa.
Fecha
Indicar la fecha cuando encontraste y corregiste el
defecto.
Nmero
Indicar un nmero nico para este defecto. Comienza
cada proyecto con 1.
63
Tipo
Indicar el tipo de defecto a partir del estndar de tipos de
defectos.
Introducido
Indicar la fase donde tu juzgas que el defecto fue inyectado o
introducido.
Eliminado
Indicar la fase en la que encontraste y eliminaste el defecto.
64
Tiempo de Arreglo
Indicar el tiempo que tomaste para corregir el defecto. Tu
puedes dar el tiempo exacto o usar tu mejor estimacin.
Defecto Arreglado
Si este defecto fue inyectado durante la correccin de otro
defecto, indicar el nmero de ese defecto o una X si lo
desconoces.
Nota
Un defecto es cualquier cosa en el programa que debe ser
cambiado para que sea desarrollado, mejorado o utilizado de
manera adecuada.
65
Tipo
Indicar el tipo de defecto a partir del estndar de tipos
de defectos.
Introducido
Indicar la fase donde tu juzgas que el defecto fue
inyectado o introducido.
Eliminado
Indicar la fase en la que encontraste y eliminaste el
defecto.
66
Propsito Gua para realizar una revisin de cdigo efectiva # # # 3 Para
Fechar
Para Fechar %
General Cuando se completa cada paso de revisin, anota el
nmero de defectos del tipo encontrado in la caja de la
derecha.
Completa el catlogo para un programa, clase, objeto o
mtodo antes de empezar la prxima revisin
Completa Verifica que todas las funciones del diseo estn
codificadas.
Includes Verifica cada include que est completo
Inicializacin Chequea las variables e inicializacin de parmetros.
Llamadas Chequea los formatos de llamadas de funcin: punteros,
parmetros.
Nombres Chequea los nombres y su uso: consistencia,
declaraciones, y estructuras.
Strings Chequea que los punteros estn:
Identificados por punteros
Terminados en NULL
Punteros Chequea que los punteros estn:
Inicializados a NULL
Borrarlos despus de crearlos
Borrarlos siempre despus del uso
67
Formato de salida Cheque el formato de salda
{} Parejas Asegurarse de que {} estn cerrados
Operadores
lgicos
Verificar el uso de ==, =, ||, etc.
Chequea cada funcin entre ()
Chequeeo Lnea
por lnea
Chequea cada lnea del cdigo:
Sintaxis de las instrucciones
Puntuacin
Estndares Asegura que el cdigo sigue el estndar de codificacin
Abrir y cerrar
ficheros
Verificar que todos los ficheros estas:
Declarados
Abiertos
Declarados
Global Realizar un escaneo global del programa para chequear el
sistema e inspeccionar los problemas
68
Los desarrolladores utilizan el log de registro de tiempo para medir
el tiempo que dedican a cada fase del proceso. En este log se anota
la hora en que empezaron a trabajar en una tarea, la hora en que
terminaron una tarea, y cualquier hora en que efectuaron una
interrupcin y/o retomaron una tarea.
Por ejemplo, una interrupcin podra ser una llamada telefnica, un
descanso, o alguien interrumpiendo para hacer una pregunta.
Tomando estos tiempos en forma precisa, los desarrolladores
pueden conocer el esfuerzo que realmente se dedica a las tareas
del proyecto. Debido a que los tiempos de interrupciones son
esencialmente al azar, ignorar estos tiempos sera introducir un
error de gran tamao en la informacin de tiempos que reducira la
exactitud de las estimaciones.
69
Una vez que sabemos gestionar el tiempo, es
necesario almacenar todos estos datos de
alguna forma mediante un formulario. Es
importante resaltar que utilizar como unidad de
medida la hora no nos proporciona detalles para
manejar o planificar el trabajo, es mucho ms
fcil en minutos.
70
Objetivo:
Aplicar las mtricas de PSP.
Definir y explicar: Los indicadores de
medicin del PSP.
71
Con datos de tamao, tiempo y defectos, existen muchas formas de medir, evaluar, y
manejar la calidad de un programa. PSP provee una serie de mediciones de calidad
que ayudan a los desarrolladores a examinar la calidad de sus programas desde
varias perspectivas. Como ninguna medicin por s sola puede indicar
adecuadamente la calidad de un programa, el panorama que provee la utilizacin de
todas estas mediciones es generalmente un indicador confiable de calidad.
Las principales mediciones de calidad son:
Densidad de defectos
ndice de revisin
ndices de tiempo de desarrollo
ndices de defectos
Rendimiento
Defectos por hora
Efectividad de remocin de defectos
Evaluacin del ndice de fallas
72
Nombre: Fecha: 18/10/96
Programa Programa # 13
Profesor Lenguaje: Java
Resumen Plan Actual a la Fecha
Minutos/LOC 5,92 4,87 5,73
LOC/Hora 10,14 12,32 10,47
Defectos/KLOC 94,79 106,4 96,90
Rendimiento
A/FR
Tamao Programa (LOC):
Total nuevo & Cambiado 58 47 258
Tamao Mximo 72
Tamao Mnimo 41
73
Tiempo en fase (min.) Plan Actual Para Fecha Para Fecha %
Planing 18 22 88 6,0
Diseo 35 24 151 10,2
Cdigo 149 93 637 43,1
Revisin cdigo 20 37 111 7,5
Compilacin 24 4 92 6,2
Test 64 8 240 16,2
Postmortem 33 41 160 10,8
Total 343 229 1479 100
Tiempo Mximo 426
Tiempo Mnimo 243
74
Introduccin de defectos Plan Actual Para Fecha Para Fecha %
Def/Hora
Planing
Diseo 1 4 16,0
Cdigo 5 5 21 84,0
Revisin cdigo
Compilacin
Test
Total 6 5 25 100,0