INGENIERIA DE SOFTWARE 1

Personal Software Process (PSP)

TCIN™ CHRISTIAN HERNAN BEDOYA SUAREZ

 Dos Tecnologías de Vanguardia

Personal Software Process (PSP)

Team Software Process (TSP)

• Creadas por Watts Humphrey (SEI)

– Orígenes en CMM
– Motivación
• Implementación de CMM
• Administración de tiempo y Costo
• Administración de calidad
• Reducir el tiempo de desarrollo

• Estado Actual
– En uso con muy buenos resultados
– Efectividad en acelerar SPI
– Diseminando esta tecnología

2
Modelos y Procesos

Niveles Organizacionales

CMM Organización

Equipos
TSP

Personas
PSP

3
 Antecedentes- PSP
• Después de la segunda guerra mundial, la estrategia de calidad en la mayoría 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 después de la producción de los productos.

• No fué sino hasta los años 70 y los años 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 hacía sus trabajos y desarrollaban sus procesos. [ DEMING; 82 ],
[ JURAN 88]

• En los siguientes años, este enfoque a los procesos de trabajo, ha sido responsable
de las mejoras importantes en la calidad de automóviles, de la electrónica, o de casi
cualquier otra clase de producto.

• La estrategia tradicional que había de "prueba-y-arregla" ahora es reconocida como

costosa, que desperdicia tiempo y que además es ineficaz para el trabajo de la
ingeniería y de la fabricación.

4
 Antecedentes- PSP
• Aunque la mayoría de las organizaciones industriales ahora han adoptado principios
modernos de calidad, la comunidad del software ha continuado confiando en la
prueba como el método principal de la administración de la calidad. Para el software,
la primera medida principal en la dirección 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 introducción 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 amplía el proceso de
mejora a la gente que realiza el trabajo de desarrollo de software.

5
 Antecedentes - PSP
• PSP se concentra en las prácticas de trabajo de los ingenieros en una forma
individual. El principio detrás 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 prácticas sanas de ingeniería de
software.

• Asimismo les enseña a cómo planear y darle un seguimiento a su trabajo, a utilizar

un proceso bien definido y medido, a establecer metas mesurables, y finalmente a
la utilización del rastreo constante para alcanzar dichas metas.

• PSP les demuestra a los ingenieros a cómo manejar la calidad desde el principio del
trabajo, a cómo analizar los resultados de cada trabajo, y a cómo utilizar los
resultados para mejorar el proceso del proyecto siguiente. [SEI; 2000] .

6
 ¿Que es PSP?
• Un PSP es un proceso personal desarrollar software.
– pasos definidos
– formularios
– estándares
• Un PSP es un marco de trabajo de medición y análisis
que te ayuda a caracterizar tu proceso.
• Es también un procedimiento definido para ayudarte
a mejorar tu rendimiento.

7
 Principios de PSP
• 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

8
 Principios de PSP
• Como todo profesional software deberías
conocer tu propio rendimiento.
• Deberías medir, seguir y analizar tu trabajo.
• Deberías aprender de tus variaciones de tu
rendimiento.
• Deberías incorporar esas lecciones a tu manera
personal de hacer.

9
 Principios de PSP
El diseño de PSP se basa en los siguientes principios de
planeación y de calidad [HUMPHREY; 95]

• Cada ingeniero es esencialmente diferente; para ser más

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.

10
 Principios de PSP
•Cuesta menos encontrar y arreglar errores en la etapa
inicial del proyecto que encontrarlos en las etapas
subsecuentes.

• Es más eficiente prevenir defectos que encontrarlos y

arreglarlos.

• La manera correcta de hacer las cosas es siempre la

manera más rápida y más barata de hacer un trabajo.

11
 Principios de PSP
• Para hacer un trabajo de ingeniería 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 planeación 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 tamaños de los productos que llegan a producir.

12
 Principios de PSP
• 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.

13
 Estructura de PSP
Objetivo:

• Conocer las métricas de PSP.

• Identificar los objetivos de cada nivel de PSP.

14
 Introducción al PSP
• El PSP es un proceso diseñado para uso individual, basado en
una versión 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 diseñado también 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

15
 Introducción al PSP
• El PSP se aplica en tareas personales estructuradas:
– Desarrollo de módulos de programas.
– Definición de requisitos o procesos.
– Realización de revisiones o pruebas.
– Escritura de documentación, etc.
– El PSP se puede extender al desarrollo de sistemas
software de gran tamaño.
– Es un proceso de Nivel 5 para los individuos y es un
prerrequisito para el TSP

16
 Introducción al PSP
• PSP se introduce con siete pasos compatibles.
• Escribes uno o dos pequeños programas en
cada paso.
• Recoges y analizas los datos de tu trabajo.
• Los usas y analizas para mejorar tu trabajo.

17
 Estructura de PSP
• Comenzando con los requerimientos, el primer paso en el
proceso de PSP es la planificación.

• Existe un script de planificación que sirve de guía 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 tamaño 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.

18
Flujo del Proceso

19
Elementos del Proceso

20
 Estructura de PSP
• Debido a que generalmente ciertos métodos de PSP no son
utilizados por los desarrolladores, los métodos de PSP son
presentados en una serie de siete versiones de procesos.

• Estas versiones son denominadas como PSP0 a PSP3. Cada versión

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 guían a los desarrolladores a mientras hacen
el trabajo.

• En otras palabras, PSP es un proceso que está diseñado para ser

utilizado.

21
Evolución de PSP
PSP
PSP 33
Desarrollo Proceso Personal Cíclico
Desarrollo Cíclico
Cíclico

PSP
PSP 22
Revisión
Revisión del
del código
código Calidad Personal
Revisión
Revisión del
del diseño
diseño

PSP
PSP 11
Estimación
Estimación del
del Tamaño
Tamaño Planificación Personal
Informe
Informe de
de pruebas
pruebas

PSP
PSP 00 Medición Personal
Proceso
Proceso

22
 Visión General de PSP
• PSP0 - estableces una línea base del rendimiento
mensurable.

• PSP1 - haces planes de tamaño, recursos y calendario.

• PSP2 - Practicas gestión de defectos y rendimiento.

• PSP3 - Amplias los métodos del PSP a proyecto

mayores.

23
 Los 7 Pasos de PSP
Proceso PSP
PSP33
Personal Desarrollo
DesarrolloCíclico
Cíclico
Cíclico

PSP PSP
PSP2.1
2.1
Administración PSP22 Formatos
de Calidad Revisión
RevisióndedeCódigo
Código Formatos deDiseño
de Diseño
Personal Revisión
RevisióndedeDiseño
Diseño
PSP
PSP1.11.1
PSP
PSP11 Planeación
Proceso de
Estimación Planeación detareas
de tareas
Planeación Estimacióndedetamaño
tamaño Planeación
Planeación de tiemposdede
de tiempos
Reporte de pruebas
Reporte de pruebas actividades
Personal actividades
Estándar
Estándar detipos
de tiposdededefectos
defectos
Proceso de PSP 0
PSP 0 PSP
PSP0.10.1
Proceso actual Estándar
Medición Proceso actual
Registro de tiempo EstándardedeCodificación
Codificación
Personal Registro de tiempo Medición
Medición deTamaño
de Tamaño
Registro de defectos
Registro de defectos Propuesta
Propuesta de mejoradel
de mejora delproceso
proceso
Estándar de tipos de defectos
Estándar de tipos de defectos
24
 PSP0 Punto de Partida de PSP
• PSP0 es un proceso sencillo, definido y
personal.
• Utiliza tus métodos actuales de diseño y
desarrollo.
• Recoge datos sobre tu trabajo:
– tiempo gastado por fase
– defectos encontrados en compilación y pruebas
• Proporciona un informe resumen.

25
 PSP0 Punto de Partida de PSP
• 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.

26
 PSP 0.1
• Se pasa a PSP0.1 agregando un estándar de código,
mediciones de tamaño 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 también mejora las mediciones para contar

separadamente métodos y procedimientos.

27
 PSP 1 y PSP 1.1PSP1 Planeación personal

• PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega estimaciones

de tamaño y recursos y un reporte de prueba.

• En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto.

Los desarrolladores son enseñados a:

• Entender la relación entre el tamaño 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 técnicas en proyectos grandes es comprendida,

pocos desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos
métodos en el nivel personal.
28
 PSP 2
• PSP2 agrega diseño personal y revisiones de código 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 revisión
que estén hechos a medida de su experiencia de
defectos personales.

29
 PSP 2.1
• El proceso de diseño es contemplado en
PSP2.1. El objetivo no es decirle a los
desarrolladores como diseñar sino orientar el
criterio para la finalización del diseño, es
decir, cuando han terminado que es lo que
deben haber obtenido. Se establece un criterio
de completitud de diseño y se examinan varias
técnicas de verificación y consistencia de
diseño.
30
 PSP 3
• Hasta este punto PSP se concentró en el
proceso lineal para construcción de pequeños
programas. PSP3 presenta métodos para ser
usados por individuos en la realización de
programas de gran escala. De todas formas
sigue enfocado en el individuo y no trata los
problemas de comunicación y coordinación
que son una parte importante del desarrollo de
sistemas de gran escala.

31
 PSP 3
• Para escalar PSP2 a proyectos más 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
diseñados para ser desarrollados en pasos
incrementales. La primera construcción consiste en
un módulo base o kernel que es ampliado en ciclos
iterativos. En cada iteración se utiliza un PSP2
completo, incluyendo diseño, codificación,
compilación y pruebas.

32
 Planeación en PSP
• ¿Por qué hacer planes?

• Te permiten llegar a acuerdos que tu puedas cumplir

• Proporcionar las bases para acuerdo en tu trabajo

• Guía tu trabajo

• Te ayuda a seguir tu progreso

• Terminación del proyecto

33
 Planeación en PSP
1. La primera tarea consiste en definir los requerimientos, describiendo el
trabajo a realizar en el mayor detalle posible.

2. Como la etapa de planificación es demasiado temprana como para hacer

un diseño completo del producto, los desarrolladores realizan un diseño
conceptual, mediante el cual se obtiene un primer acercamiento de cómo
debe basarse el producto a ser construido en la etapa de desarrollo.

3. La siguiente tarea consiste en la estimación de tamaño y de esfuerzo.

La correlación entre el tamaño de un programa y tiempo de desarrollo es
moderadamente buena para equipos de desarrollo; sin embargo, para un
solo desarrollador, la correlación es generalmente un poco mayor. Los
desarrolladores realizan las estimaciones utilizando datos históricos
personales de tamaño y productividad. En PSP, las estimaciones se
efectúan mediante el método PROBE (PROxy Based Estimating).

34
Planeación en PSP

35
 Planeación en PSP
4. Una vez que los desarrolladores conocen el tiempo requerido para cada proceso,
deben estimar el tiempo que van a dedicar al trabajo cada día de la semana,
conformando entonces el calendario.
5. Luego, durante la etapa de desarrollo del producto, los desarrolladores
efectúan el diseño detallado, la implementación y las pruebas.
6. Después de completar el trabajo, los desarrolladores realizan un análisis
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 información en sus bases de
datos históricas de tamaño y productividad. Además se examinan las Propuestas
de Mejoras (PIP) para hacer ajustes en los procesos.

36
 Planeación PSP
• La Medición 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 prácticos 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 medición personal que incluye la gestión del tiempo y
el siguiente rastreo del mismo.

37
 Recolección de Datos
• En PSP, los desarrolladores utilizan información 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 tamaños de los productos que producen, y de la
calidad de esos productos.

• Las medidas básicas de PSP son el tiempo que el ingeniero utiliza

en cada fase del proceso, los defectos introducidos y encontrados
en cada fase, y los tamaños de los productos desarrollados en
líneas de código (LOC).

• Estos datos se recopilan en cada fase del proceso y se resumen a

la terminación del proyecto. Todos estos datos se utilizan para
proporcionar una familia de medidas de calidad de procesos que
los ingenieros usan como guía en su trabajo.
38
 Recolección de Datos
Las principales medidas son:

• Tamaño tiempo de estimación de errores

• Coste de realización

• Defectos producidos y corregidos por hora

• Producción del proceso

• Valoración y calidad del costo de los fallos (COQ)

• Valoración del rango de fallos (A/FR)

39
 Elementos del Proceso
Elementos

• un guión de proceso
• un formulario resumen de plan proyecto
• un registro tiempo
• un registro de defectos
• un estándar de tipos defecto

40
 Guión del Proceso
Número de Propósito Guiarte en el desarrollo de programas a nivel de módulo
Fase

Entradas Necesarias * Descripción del problema Formulario de Resumen del plan del Proyecto PSPO
•Tablas de Registro de Tiempos y Defectos
•Cronometro (opcional)

1 Planificación •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 •Diseñar el programa

•Implementar el diseño
•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 tamaño

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

41
 Guión del Proceso
• Planificación
– Estimar tiempo de desarrollo.

• Desarrollo
– Desarrollar el producto utilizando tus métodos actuales.

• Post-mortem
– Completar el resumen del plan proyecto, con los
tiempos gastados y defectos encontrados e inyectados
en cada fase.

42
 Guión del Proceso
• Diseño
– Diseñar el programa, usando tus métodos de diseño actuales.

• Codificación
– Implementa el programa.

• Compilación
– 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.
43
 Primera Aproximación a PSP
7 pasos y 4 niveles de mejoramiento

•PSP0 + PSP0.1 Métrica y estandarización

•PSP1 + PSP1.1 Mejora la estimación y planificación

•PSP2 + PSP2.1 Incrementamos calidad

•PSP 3 Repetición para escalar a grandes desarrollos

44
 Resumen del Plan PSP
Estudiante: _Juan Luís Guerra_________ Fecha: _09/10/06__
Programa:_Raíz Cuadrada_____________ Programa #: _1A
Instructor: _XX_______________________ Lenguaje: ___C____
Tamaño del programa (LOC) Plan Actual
Total (Nuevas&Modificadas) 50 33

Tiempo en Fase (minutos) Plan Actual A la Fecha A la Fecha%

Planeación 2 2 1.6
Diseño 0 0 0
Codificación 53 53 44.2
Compilación 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%

Planeación 0 0 0
Diseño 0 0 0
Codificación 10 10 100
Compilación 0 0 0
Prueba 0 0 0
Total 10 10 100

Defectos Removidos Actual A la Fecha A la Fecha %

Planeación 0 0 0
Diseño 0 0 0
Codificación 3 3 30
Compilación 5 5 50
Prueba 2 2 20
Total 10 10 100
Después del Desarrollo 0 0 0

45
 Resumen del Plan
• Encabezado
– Nombre, fecha, programa, instructor, lenguaje.

• Tamaño del Programa

– Plan :Indica tu mejor estimación del tiempo total

que tendrá el desarrollo.
– Actual :Indica el tiempo actual en minutos gastado
en cada fase.

46
 Resumen del Plan
• 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 número actual de defectos inyectados y
eliminados en cada fase.

47
 Resumen del Plan
• 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.

48
 Registros de Tiempo PSP
Estudiante: ____________________ Fecha: __________
Instructor:______________________ Programa #: ______

Fecha Inicio Fin Tiempo Tiempo Fase Comenta

de Delta rios
Interrupci
ón

49
 Registros de Tiempo
• Encabezado
– Indicar nombre, fecha, instructor y número de programa.

• Fecha
– Indicar la fecha actual.

• Inicio
– Indicar el tiempo en minutos cuando empiezas una fase
del proyecto.

50
 Registros de Tiempo
• 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 interrupción
– 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 interrupción.

51
 Registros de Tiempo
• Fase
– Anotar la fase en la que estas trabajando.
– Use el nombre de cada fase.

• Comentarios
– Descripción de la interrupción
– La tarea que estas haciendo
– Cualquier aspecto significativo que afecte a tu
trabajo

52
 Ejemplo
Fecha Inicio Fin Tiempo de Tiempo Actividad Comentarios
Interrupción Delta
9/9 9:00 9:50 50 Planeación
12:40 1:18 38 Diseño
2:45 3:53 10 58 Diseño Teléfono
6:25 7:45 80 Codificación

10/9 11:06 12:19 6+5 62 Codificación Baño, tomé café

11/9 9:00 9:50 50 Codificación

1:15 2:35 3+8 69 Compilación Consulta de un libro

4:18 5:11 25 28 Prueba Reunión con mi jefe

12/9 6:42 9:04 10+6+12 114 Prueba Teléfono, Baño, Teléfono
13/9 9:00 9:50 50 Prueba
12:33 1:16 38 Postmortem
53
 Manejo de Interrupciones
• 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 teléfono, 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 anotándolo en la
columna Tiempo de Interrupción. Durante este periodo no solo
se anota el tiempo de la interrupción sino también porqué se
ha producido en la columna de Comentarios.

54
 Manejo de Interrupciones
• Ya que el tiempo de interrupción 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 debería añadir un número 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 podría ayudar a realizar
un trabajo más eficaz y de más calidad.

55
 Tamaño
• El tiempo en desarrollar un producto se encuentra altamente
determinado por el tamaño del mismo. En PSP, los desarrolladores
primero estiman el tamaño de los productos que planean
desarrollar. Luego, al finalizar el producto, se mide el tamaño real
obtenido.

• Esta información permite a los desarrolladores realizar a futuro una

estimación de tamaños más precisa. Sin embargo, para que esta
información sea útil, el tamaño de las mediciones debe
corresponderse con el tiempo de desarrollo del producto. En PSP,
el tamaño se mide en Líneas de Código (LOC).

• Para realizar un seguimiento de la variación del tamaño de un

programa durante el desarrollo, se deben considerar varias
categorías de LOC.

56
 Tamaño
Estas son:

• Base (son los LOC iniciales del producto original)

• Agregadas (es el código agregado a un programa base existente)

• Modificadas (es el código base que es modificado en un programa existente)

• Eliminadas (es el código base que es eliminado de un programa existente)

• Reutilización (es el código tomado de una librería u utilizado, sin realizar

ninguna modificación, en un nuevo programa)

• Nueva Reutilización (esta medida cuenta los LOC que se agregan a una librería)

• Total (es tamaño total del programa, independientemente del código fuente).

57
 Tamaño
Luego, para medir el tamaño total de un producto, el cálculo es el
siguiente:

• Total LOC = Base – Eliminadas + Agregadas + Reutilización

• Las LOC modificadas y de “nueva reutilización” 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 reutilización” ya se encuentran contabilizadas
en las LOC agregadas.

58
 Tipo de Defectos
• El estándar de tipos de defectos proporciona un
conjunto general de categorías de defectos.

• Aunque tu puedes reemplazar este estándar 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.

59
Tipo de Defectos PSP

60
 Registro de los Defectos PSP
Nombre: _______________________________ Fecha: ___
Instructor: ______________________________Programa :__

Fecha Número Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

10/10/06 1 40 CÓDIGO CODIGO 11
Descripción: Agregar una variable a la estructura

Fecha Número Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

10/10/06 2 20 CÓDIGO CODIGO 1
Descripción: Variable multidefinida

Fecha Número Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

10/10/06 3 10 CÓDIGO COMPILAR 1
Descripción: Las comillas de la instrucción de impresión no existen “”

Fecha Número Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

10/10/06 4 10 CÓDIGO PRUEBA 39
Descripción: Alinear y agregar instrucciones de impresión , mejorar la apariencia

61
 Registro de los Defectos
• Encabezado
– Indicar el nombre, fecha, instructor, y numero de programa.

• Fecha
– Indicar la fecha cuando encontraste y corregiste el defecto.

• Número
– Indicar un número único para este defecto. Comienza cada
proyecto con 1.

62
 Registro de los Defectos
• Tipo
– Indicar el tipo de defecto a partir del estándar 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.

63
 Registro de los Defectos
• Tiempo de Arreglo
– Indicar el tiempo que tomaste para corregir el defecto. Tu puedes dar el
tiempo exacto o usar tu mejor estimación.

• Defecto Arreglado
– Si este defecto fue inyectado durante la corrección de otro defecto,
indicar el número 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.

64
 Registro de los Defectos
• Tipo
– Indicar el tipo de defecto a partir del estándar 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.

65
 Guía de Revisión de Código
Propósito Guía para realizar una revisión de código efectiva # # # 3 Para Para Fechar %
Fechar
General Cuando se completa cada paso de revisión, anota el
número de defectos del tipo encontrado in la caja de la
derecha.
Completa el catálogo para un programa, clase, objeto o
método antes de empezar la próxima revisión
Completa Verifica que todas las funciones del diseño están
codificadas.
Includes Verifica cada include que esté completo
Inicialización Chequea las variables e inicialización de parámetros.
Llamadas Chequea los formatos de llamadas de función: punteros,
parámetros.
Nombres Chequea los nombres y su uso: consistencia,
declaraciones, y estructuras.
Strings Chequea que los punteros están:
Identificados por punteros
Terminados en NULL
Punteros Chequea que los punteros están:
Inicializados a NULL
Borrarlos después de crearlos
Borrarlos siempre después del uso

66
 Guía de Revisión de Código
Formato de salida Cheque el formato de salda
{} Parejas Asegurarse de que {} están cerrados
Operadores Verificar el uso de ==, =, ||, etc.
lógicos Chequea cada función entre ()
Chequeeo Línea Chequea cada línea del código:
por línea Sintaxis de las instrucciones
Puntuación
Estándares Asegura que el código sigue el estándar de codificación
Abrir y cerrar Verificar que todos los ficheros estas:
ficheros Declarados
Abiertos
Declarados
Global Realizar un escaneo global del programa para chequear el
sistema e inspeccionar los problemas

67
 Mediciones de Tiempo
• 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 interrupción y/o retomaron una
tarea.

• Por ejemplo, una interrupción podría ser una llamada telefónica, 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 sería introducir un error de gran tamaño en la información de
tiempos que reduciría la exactitud de las estimaciones.

68
 Mediciones de Tiempo
• 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 más fácil en minutos.

69
 Métricas del PSP
Objetivo:

• Aplicar las métricas de PSP.

• Definir y explicar: Los indicadores de
medición del PSP.

70
 Métricas del PSP
• Con datos de tamaño, 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 medición por sí sola puede indicar adecuadamente la calidad de un programa, el
panorama que provee la utilización de todas estas mediciones es generalmente un indicador
confiable de calidad.

• Las principales mediciones de calidad son:

– Densidad de defectos
– Índice de revisión
– Índices de tiempo de desarrollo
– Índices de defectos
– Rendimiento
– Defectos por hora
– Efectividad de remoción de defectos
– Evaluación del índice de fallas

71
 Resumen - Métricas del PSP
Nombre: Fecha: 18/10/96
Programa Programa # 13
Profesor Lenguaje: Java
Resumen PlanActual a la Fecha
Minutos/LOC 5,924,875,73
LOC/Hora 10,14 12,32 10,47
Defectos/KLOC 94,79 106,4 96,90
Rendimiento
A/FR
Tamaño Programa (LOC):
Total nuevo & Cambiado 58 47 258
Tamaño Máximo 72
Tamaño Mínimo 41

72
 Resumen - Métricas del PSP
Tiempo en fase (min.) Plan Actual Para Fecha Para Fecha %

Planing 18 22 88 6,0
Diseño 35 24 151 10,2
Código 149 93 637 43,1
Revisión código 20 37 111 7,5
Compilación 24 4 92 6,2
Test 64 8 240 16,2
Postmortem 33 41 160 10,8
Total 343 229 1479 100
Tiempo Máximo 426
Tiempo Mínimo 243

73
 Resumen - Métricas del PSP
Introducción de defectos Plan Actual Para Fecha Para Fecha % Def/Hora

Planing
Diseño 1 4 16,0
Código 5 5 21 84,0
Revisión código
Compilación
Test
Total 6 5 25 100,0

74