PSP Literatura en Espanol

UNIDAD II
Mtricas y Procesos PSP

Personal Software Process
Calidad en el Desarrollo
de Software
de Software
Objetivo General:
Introducir al alumno a la
Metodologa del PSP, as como
conocer los conceptos acerca de
mtricas en el desarrollo de
Software.
de Software
ndice
I. Introduccin al Personal Software Process (PSP)
II. Estructura del PSP
I. Introduccin al Personal
Software Process (PSP)
de Software
de Software
I. Introduccin al Personal Software Process

(PSP)
Objetivo:
Conocer los antecedentes, principios y pasos del
PSP.
Definir y explicar los orgenes de PSP
de Software
Antecedentes
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.
de Software
Antecedentes
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.
de Software
Antecedentes
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] .
de Software
Cmo fue desarrollado PSP?

Despus de que Watts S. Humphrey condujera el desarrollo inicial de CMM
para software, se decidi a aplicar los principios de CMM a los programas
pequeos.
Posteriormente, mucha gente preguntaba cmo aplicar CMM a las
organizaciones pequeas o al trabajo de los equipos pequeos de software.
Mientras que los principios de CMM se aplicaron a tales grupos, cada vez se
volva mas necesaria la asesora para saber que hacer. Fu entonces cuando
Humphrey decidi personalmente utilizar los principios de CMM para
desarrollar programas modulares para ver si dicho enfoque podra
funcionar para convencer a los ingenieros de software a que adoptaran tales
prcticas.
Fu entonces en el desarrollo de estos programas modulares, cuando
Humphrey utiliz personalmente todas las prcticas de CMM para que l
subiera poco a poco hasta llegar al nivel 5. Poco despus l comenz a
trabajar en el proyecto tiempo completo en abril de 1989, el Instituto de la
Ingeniera de Software (SEI) hizo a Humphrey un colaborador del SEI,
permitindole trabajar tiempo completo en la investigacin detallada de
PSP.
de Software

Durante los siguientes tres aos, l desarroll un total de 62 programas y
defini cerca de 15 versiones de PSP. Utiliz los siguientes lenguajes de
programacin: PASCAL y C++ , para desarrollar cerca de 25.000 lneas de
cdigo que ayudaran a darle la forma final a PSP. [SEI; 2002]
De esta experiencia, l concluy que los principios de la administracin de
procesos que desarroll Deming y de Juran eran totalmente aplicables tanto al
trabajo de los ingenieros de software de manera individual como a ingenieros
enfocados al trabajo en equipo, el resultado? Proceso en equipo de software
(TSP)
Humphrey despus escribi un libro que les proporcion a varios asociados el
material necesario para ensear cursos de PSP. En septiembre de 1993, Howie
Dow ense el primer curso de PSP a cuatro estudiantes graduados en la
Universidad de Massachusetts.
Humphrey tambin ense el curso de PSP durante el semestre del invierno
de 1993-1994 en la universidad de Carnegie Mellon, al igual que Nazim
Madhavji en la Universidad McGill y Soheil Khajanoori lo ense en la
Universidad Aeronutica de Embry. De acuerdo con las experiencias y los
datos que proporcionaron estos cursos, Humphrey realiz la revisin del libro
de PSP y public la versin final a finales de 1994. [HUMPHREY; 95 ]
de Software

Casi al mismo tiempo, Jim Over y Neil Reizer del
SEI y Robert Powels de la compaa de Servicios
Informativos Avanzados (AIS por sus siglas en
ingls) desarrollaron el primer curso para
entrenar a los instructores a ensear el curso de
PSP en la industria. Humphrey junto con el SEI
han continuado trabajando en el desarrollo de
PSP y asmismo han aplicado los mismos
principios al Proceso en Equipo de Software o
TSP.
de Software
Qu es PSP?
Un PSP es un proceso personal para 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.
de Software
I.I.Principios del 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
de Software

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

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.
de Software
I.I. Principios del PSP

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

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

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

Objetivo:
Conocer las mtricas de PSP.
Identificar los objetivos de cada nivel de PSP.
de Software
Introduccin
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
de Software
Introduccin
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
de Software
Introduccin
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.
de Software
Estructura de PSP
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.
de Software
Flujo del Proceso

de Software
Estructura de PSP
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.
de Software
Elementos del Proceso

de Software
Estructura de PSP
Est construido en un formato simple de utilizar
con instrucciones simples y precisas. Si bien los
scripts describen qu hacer, en realidad se
parecen ms a checklists que a tutoriales.
Estos no incluyen los materiales instructivos que
seran necesarios para usuarios no entrenados.
El propsito de los scripts es el de guiar a los
desarrolladores en el uso consistente de los
procesos, los cuales ellos conocen (mediante la
asistencia a cursos de capacitacin en PSP o a
travs de bibliografa introductoria en el uso de
PSP).
de Software
Evolucin del PSP

PSP
PSP 33
Desarrollo Proceso Personal Cclico
Desarrollo Cclico
Cclico
PSP
PSP 22
Revisin
Revisin del
del cdigo
cdigo Calidad Personal
Revisin
Revisin del
del diseo
diseo
PSP
PSP 11
Estimacin
Estimacin del
del Tamao
Tamao Planificacin Personal
Informe
Informe de
de pruebas
pruebas
PSP
PSP 00 Medicin Personal
Proceso
Proceso
de Software
Visin General de PSP

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.
de Software
II.I. Los 7 Pasos de PSP PSP 3

Proceso PSP 3
Desarrollo Cclico
Personal Desarrollo Cclico
Cclico
PSP 2.1
Administracin de PSP 2 PSP 2.1
PSP 2 Formatos de Diseo
Calidad Personal Revisin de Cdigo Formatos de Diseo
Revisin de Cdigo
Revisin de Diseo
Revisin de Diseo
PSP 1.1
PSP 1 PSP 1.1
Proceso de PSP 1 Planeacin de tareas
Estimacin de tamao Planeacin de tareas
Planeacin Estimacin de tamao Planeacin de tiempos de
Reporte de pruebas Planeacin de tiempos de
Personal Reporte de pruebas actividades
actividades
Estndar de tipos de defectos
PSP 0.1
Proceso de PSP 0 PSP 0.1
PSP 0 Estndar de Codificacin
Medicin Proceso actual Estndar de Codificacin
Proceso actual Medicin de Tamao
Personal Registro de tiempo Medicin de Tamao
Registro de tiempo Propuesta de mejora del proceso
Registro de defectos Propuesta de mejora del proceso
Registro de defectos
II.I.I. PSP0
El punto de partida de PSP Calidad en el Desarrollo
de Software
de Software
II.I.I. PSP0
El punto de partida de PSP
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.
de Software
II.I.I. PSP0
El 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.
de Software
II.I.I. PSP 0.1

Se pasa a PSP0.1 agregando un estndar de
cdigo, mediciones de tamao y el denominado
PIP (Process Improvement Proposal).
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.
II.II. PSP1
Planeacin Personal Calidad en el Desarrollo
de Software
de Software
II.II. PSP1
PSP1 Planeacin personal
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:
de Software
II.II. PSP1
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.
II.III. PSP2
Calidad Personal Calidad en el Desarrollo
de Software
de Software
II.III. PSP2
Un objetivo de PSP es ayudar a los
desarrolladores a lidiar de manera realista y
objetiva con los defectos que introducen. Los
programadores por lo general se avergenzan de
sus errores. El hecho de que la mayora de los
errores sean tipogrficos o errores tontos hace
que los desarrolladores sientan que pueden
mejorar haciendo ms esfuerzo.
de Software
II.III. PSP2
El problema es que hacer ms esfuerzo por lo
general hace que las cosas empeoren; las claves,
como en otras actividades, son las habilidades
inherentes y las capacidades.
En PSP2 se enfoca en mejorar la habilidad del
desarrollador para producir programas de calidad.
La idea es hacer al trabajo de calidad ms natural y
consistente. Mejoras significativas en la frecuencia
de defectos de los desarrolladores no son posibles a
menos que conozcan cuantos errores cometen y que
comprendan sus causas y consecuencias.
de Software
II.III. PSP2
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.
de Software
II.III. PSP2
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.
II.IV. PSP3
Proceso Personal Ciclico Calidad en el Desarrollo
de Software
de Software
II.IV. PSP3
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.
de Software
II.IV. PSP3
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.
de Software
Proceso Personal Cclico

Especificaciones
Requerimientos Ciclo especfico

Y
Planificacin
. Diseo detallado
Diseo de . Y
Alto nivel . Repaso del diseo
Desarrollo de las pruebas

Repaso al Diseo
Y repaso
De
Alto nivel
Implementacin
Desarrollo
Y Repaso del cdigo
Cclico
Compilacin
Postmortem
Pruebas
Integracin
Pruebas del sistema
Uso . Valorar de nuevo
. Y Reciclar
.
Producto
de Software
II.IV. PSP3
El proceso cclico PSP3 puede ser un elemento efectivo
en un proceso de desarrollo de gran escala solo si cada
incremento sucesivo de software es de alta calidad.
De esta manera los desarrolladores pueden concentrarse
en la verificacin de la calidad del ltimo incremento sin
preocuparse por defectos en ciclos anteriores.
Si un incremento anterior tiene muchos defectos, la
prueba ser ms compleja y los beneficios de escalar PSP
se pierden. Esta es una razn para enfatizar revisiones de
diseo y cdigo en los pasos anteriores de PSP.
de Software
Planeacin en PSP
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
de Software
Planeacin PSP
La primera tarea consiste en definir los requerimientos,
describiendo el trabajo a realizar en el mayor detalle posible.
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.
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).
de Software
Planeacin PSP
Necesidad Define los
del usuario requerimientos Tareas
Mtodo PROBE
Producir diseo Items

Conceptual
Estimar el tamao Base de Datos de

del producto Tamao
Usuario
Estimar los Base de Datos de
recursos Productividad
Recursos
Producir
disponibles
Gestin
Calendario
Entregar el Desarrollar Tamao, Recursos, Analizar el

el producto Seguimiento de
producto Datos, Plazos proceso Reportes
de Software
Planeacin PSP
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.
Luego, durante la etapa de desarrollo del producto, los
desarrolladores efectan el diseo detallado, la implementacin y
las pruebas.
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.
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.
de Software
Planeacin PSP
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.
de Software
Recoleccin de datos
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.
de Software
Recoleccin de datos
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 coste de los fallos
(COQ)
Valoracin del rango de fallos (A/FR)
de Software
Elementos del Proceso

Elementos
un guin de proceso
un formulario resumen de plan proyecto
un registro tiempo
un registro de defectos
un estndar de tipos defecto
de Software
Flujo del Proceso

de Software
Guin del proceso

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.
de Software
Guin del proceso

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.
de Software
Resumen del Plan

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
Codificacin53 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
Codificacin10 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
Codificacin3 3 30
Compilacin 5 5 50
Prueba 2 2 20
Total 10 10 100
Despus del Desarrollo 0 0 0
de Software
Resumen del Plan

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.
de Software
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 nmero actual de defectos inyectados y
eliminados en cada fase.
de Software
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.
Log Registro del Tiempo
Estudiante: ____________________ Fecha: __________
Instructor:______________________ Programa #: ______
Fecha Inicio Fin Tiempo Tiempo Fase Comenta

de Delta rios
Interrupci
n
Calidad en el Desarrollo de Software

de Software

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

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

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
de Software
Por ejemplo
Fecha Inicio Fin Tiempo de Tiempo Actividad Comentarios
Interrupcin Delta
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 Codificaci

n
10/9 11:06 12:19 6+5 62 Codificaci Bao, tom caf
n
11/9 9:00 9:50 50 Codificaci
n
1:15 2:35 3+8 69 Compilaci Consulta de un libro
n
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
de Software
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 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.
de Software
Manejo de Interrupciones
Puesto 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.
de Software
Tamao
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.
de Software
Tamao
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).
de Software
Tamao
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.
de Software
Estndar tipo de Defectos

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.
de Software
Estndar tipo de Defectos

de Software
Log Registro Defectos

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

10/10/06 2 20 CDIGO CODIGO 1
Descripcin: Variable multidefinida

10/10/06 3 w0 CDIGO COMPILAR 1
Descripcin: Las comillas de la instruccin de impresin no existen

10/10/06 4 10 CDIGO PRUEBA 39
Descripcin: Alinear y agregar instrucciones de impresin , mejorar la apariencia
de Software

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

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

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

Finalmente, la manera ms eficaz de encontrar y
arreglar defectos es repasando el cdigo fuente
del programa personalmente. Mientras esto
puede parecer como una manera difcil de
limpiar un programa defectuoso, resulta ser ms
rpido y ms eficaz. Un mtodo para realizar
revisiones de cdigo es la utilizacin de guas en
las que se determina cuales son los defectos que
mas frecuentemente se inyectan.
de Software
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 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.
de Software
Administracin del Tiempo

Para la llevar a cabo una buena gestin del tiempo se pueden tener en
cuenta los siguientes puntos:
Tener en cuenta que normalmente el tiempo se gasta de la misma
forma.
Se debe realizar un seguimiento la forma en la que se gasta el tiempo.
Para chequear con exactitud las estimaciones del tiempo y la
planificacin, se debe documentar y ms tarde compralo con lo que
actualmente se hace.
Para hacer planes ms exactos, se deben determinar los planes
previos errneos y que deberamos hacer mejor.
Planificar el tiempo y seguir un plan.
Todo esto se puede resumir mejor diciendo que la mejor forma de
gestionar el tiempo es comprender como empleamos el tiempo y esto
exige que sepamos catalogar las actividades, registrar el tiempo
empleado en cada actividad y almacenar estos datos en un lugar
conveniente.
de Software
Seguimiento del 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 ms fcil en
minutos.
de Software
Conclusiones
Conociendo los principios y las caractersticas de la
metodologa de PSP, conformada por los procesos de
planificacin, estimacin de tamao y esfuerzo,
recoleccin de datos, manejo de calidad y
especificaciones de diseo, se plantea la posibilidad de
incorporar esta metodologa al contexto de una
empresa pequea, o grupo de desarrollo de software
pequeo analizando los factores operativos,
econmicos y los riesgos a los que se expone
Una vez implementada esta metodologa en el
ambiente de trabajo, un siguiente paso consiste en
enfocarse en la mejora de la eficiencia y de la dinmica
de trabajo a nivel de equipos de desarrollo, mediante el
mtodo conocido como TSP (Team Software Process).

PSP Literatura en Espanol

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PSP Literatura en Espanol

Uploaded by

Copyright:

Available Formats

UNIDAD II

Mtricas y Procesos PSP

I. Introduccin al Personal Software Process

En los siguientes aos, este enfoque a los procesos de trabajo, ha sido

La estrategia tradicional que haba de "prueba-y-arregla" ahora es

Usando inspecciones, las organizaciones han mejorado substancialmente la

Cmo fue desarrollado PSP?

Cmo fue desarrollado PSP?

Cmo fue desarrollado PSP?

I.I.Principios del PSP

I.I.Principios del PSP

I.I.Principios del PSP

I.I. Principios del PSP

I.I. Principios del PSP

Para que los desarrolladores lleguen a entender su

I.I. Principios del PSP

Finalmente, deben analizar los resultados de

II. Estructura del PSP

Flujo del Proceso

Elementos del Proceso

Evolucin del PSP

Visin General de PSP

II.I. Los 7 Pasos de PSP PSP 3

II.I.I. PSP 0.1

Mientras que la importancia de estas tcnicas en proyectos

Proceso Personal Cclico

Requerimientos Ciclo especfico

Desarrollo de las pruebas

Producir diseo Items

Estimar el tamao Base de Datos de

Entregar el Desarrollar Tamao, Recursos, Analizar el

Elementos del Proceso

Flujo del Proceso

Guin del proceso

Guin del proceso

Resumen del Plan

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

Defectos Introducidos Actual A la Fecha A la Fecha%

Defectos Removidos Actual A la Fecha A la Fecha %

Resumen del Plan

Resumen del Plan

Resumen del Plan

Fecha Inicio Fin Tiempo Tiempo Fase Comenta

Calidad en el Desarrollo de Software

Log Registro del Tiempo

Log Registro del Tiempo

Log Registro del Tiempo

12:40 1:18 38 Diseo

2:45 3:53 10 58 Diseo Telfono

6:25 7:45 80 Codificaci

12/9 6:42 9:04 10+6+12 114 Prueba Telfono, Bao, Telfono

Estndar tipo de Defectos

Estndar tipo de Defectos

Log Registro Defectos

Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado

Log Registro Defectos

Log Registro Defectos

Log Registro Defectos

Log Registro Defectos

Administracin del Tiempo