PSP

2. PSP es un proceso de auto-mejora
que nos ayuda a controlar, gestionar
y mejorar la forma en la que
realizamos nuestro trabajo. Es un
marco de trabajo estructurado,
compuesto de guías y
procedimientos para desarrollar
software. Usado de manera
adecuada el PSP nos brinda la
información necesaria para hacer y
cumplir compromisos (en términos
de calidad y calendario) y hacer
mas eficiente y predecible la forma
en que realizamos el trabajo.

3. La filosofía del PSP se basa en:
Para mejorar su rendimiento y
calidad, los desarrolladores
deben medir su trabajo, analizar
sus resultados y trazarse metas
de mejora usándolos
Cada Desarrollador es absolutamente
diferente, pero para ser efectivos, los
desarrolladores deben planear su trabajo
usando como referencia su información
histórica (Comportamiento en proyectos
anteriores)

4. La Calidad del Producto/Software/Proyecto es
responsabilidad del quien lo desarrolla (El
Desarrollador) y dicha calidad no es accidental,
exigiendo de los desarrolladores un compromiso
personal.
Encontrar los defectos (errores, bugs,
requerimientos no contemplados, etc) en
fases tempranas del Proceso es mucho
menos costoso que encontrarlas en
Pruebas de Unidad, del Sistema, de
Integración y mucho mas que cuando son
encontrados por el usuario

5. El PSP se compone de 4 elementos fundamentales, que unidos
aportan las herramientas para la mejora continua, estos elementos
son:
Scripts: Son los elementos que documentan el
proceso e indican que hacer y cuando hacerlo.
Siendo apegados a la definición formal, su
propósito es proveer una guía de alto nivel de
como usar el proceso. Un ejemplo puede ser el
siguiente (Script general del Proceso)

6. Medidas: Miden el proceso y el producto,
muestran si las cosas están funcionando bien.
Algunas de las medidas que PSP recoge se
enfoca en 4 aspectos, Tamaño, Esfuerzo,
Calidad y Programación (Agenda ó
Cronograma)
Formas: Son formularios para recopilar de manera
sencilla y consistente la información. Entre los mas
básicos: Log de Tiempo (Donde se almacena cuando
se invierte en cada fase o tarea del proyecto), Log de
Defectos (En el cual se recopila la información de los
defectos encontrados)
Estándares: Definen como yo
(personalmente) hago las cosas. Por
ejemplo: Estándar de Código (Permite
saber como cada uno de los
desarrolladores escribirá su código)

7. PSP y posteriormente TSP (Team Software Process) se aprenden de
manera incremental, iniciando por PSP0, PSP1, PSP2 y luego TSP. Existen
unos procesos transicionales PSP0.1 y PSP2.1, el siguiente gráfico trata de
mostrarlo mejor.

8. En PSP0 y PSP0.1 se aprende a usar de manera eficiente y eficaz un
proceso y a recopilar información, siendo tal vez el punto donde muchos
desarrolladores se hacen a un lado pues nunca o muy pocas veces nos
hemos preocupado por saber cuanto tiempo nos demoramos haciendo XYZ
tarea del proyecto o cuanto invertimos en las pruebas o cuanto nos
demoramos corrigiendo un defecto (error/cambio). Esta parte del proceso
es particularmente sorprendente!
En PSP1 se conoce como estimar el tamaño de un producto de software
partiendo claro está, de información histórica y si no se tiene se acude a
una excelente herramienta de estimación llamada PROBE, donde con un
diseño conceptual encontramos partes del producto y estimamos de
acuerdo a unas tablas relativas de tamaño. Básicamente se contestan estas
preguntas ¿cuan grande será mi producto (Tamaño)? ¿Cuanto esfuerzo
tendré que usar para terminarlo?
PSP2 y PSP2.1 son especialmente interesantes para los amantes del
Diseño y la Calidad, pues a través de “artefactos” de Diseño, se desarrollan
diseños detallados del producto y se incorporan nuevas actividades de