PSP Literatura en Espanol

UNIDAD II
Métricas y Procesos PSP

Personal Software Process
Calidad en el Desarrollo
de Software
de Software
Objetivo General:
• Introducir al alumno a la
Metodología del PSP, así como
conocer los conceptos acerca de
métricas en el desarrollo de
Software.
de Software
Índice
I. Introducción al Personal Software Process
(PSP)
II. Estructura del PSP
I. Introducción al Personal
Software Process (PSP)
de Software
de Software
I. Introducción al Personal Software Process

(PSP)
Objetivo:
• Conocer los antecedentes, principios y pasos del
PSP.
• Definir y explicar los orígenes de PSP
de Software
Antecedentes
• 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.
de Software
Antecedentes
• 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.
de Software
Antecedentes
• 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] .
de Software
¿ Cómo fue desarrollado PSP?

• Después de que Watts S. Humphrey condujera el desarrollo inicial de CMM
para software, se decidió a aplicar los principios de CMM a los programas
pequeños.
• Posteriormente, mucha gente preguntaba cómo aplicar CMM a las
organizaciones pequeñas o al trabajo de los equipos pequeños de software.
• Mientras que los principios de CMM se aplicaron a tales grupos, cada vez se
volvía mas necesaria la asesoría para saber que hacer. Fué entonces cuando
Humphrey decidió personalmente utilizar los principios de CMM para
desarrollar programas modulares para ver si dicho enfoque podría
funcionar para convencer a los ingenieros de software a que adoptaran tales
prácticas.
• Fué entonces en el desarrollo de estos programas modulares, cuando
Humphrey utilizó personalmente todas las prácticas de CMM para que él
subiera poco a poco hasta llegar al nivel 5. Poco después él comenzó a
trabajar en el proyecto tiempo completo en abril de 1989, el Instituto de la
Ingeniería de Software (SEI) hizo a Humphrey un colaborador del SEI,
permitiéndole trabajar tiempo completo en la investigación detallada de
PSP.
de Software

• Durante los siguientes tres años, él desarrolló un total de 62 programas y
definió cerca de 15 versiones de PSP. Utilizó los siguientes lenguajes de
programación: PASCAL y C++ , para desarrollar cerca de 25.000 líneas de
código que ayudarían a darle la forma final a PSP. [SEI; 2002]
• De esta experiencia, él concluyó que los principios de la administración 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 después escribió un libro que les proporcionó a varios asociados
el material necesario para enseñar 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 también 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 Aeronáutica de Embry. De acuerdo con las experiencias y los
datos que proporcionaron estos cursos, Humphrey realizó la revisión del
libro de PSP y publicó la versión 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 compañía de Servicios
Informativos Avanzados (AIS por sus siglas en
inglés) desarrollaron el primer curso para
entrenar a los instructores a enseñar el curso de
PSP en la industria. Humphrey junto con el SEI
han continuado trabajando en el desarrollo de
PSP y asímismo 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
▫ 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.
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 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.
de Software

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

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.
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 métricas de PSP.
• Identificar los objetivos de cada nivel de PSP.
de Software
Introducción
• 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
de Software
Introducción
• 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
de Software
Introducción
• 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.
de Software
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.
de Software
Flujo del Proceso

de Software
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.
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 más a checklists que a tutoriales.
• Estos no incluyen los materiales instructivos que
serían necesarios para usuarios no entrenados.
El propósito 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 capacitación en PSP o a
través de bibliografía introductoria en el uso de
PSP).
de Software
Evolución del PSP

PSP 3
Desarrollo Cíclico Proceso Personal Cíclico
PSP 2
Revisión del código Calidad Personal
Revisión del diseño
PSP 1
Estimación del Tamaño
Planificación Personal
Informe de pruebas
PSP 0 Medición Personal

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

PSP 3
Proceso
Desarrollo Cíclico
Personal
Cíclico
PSP 2.1
Administración de PSP 2 Formatos de Diseño
Calidad Personal Revisión de Código
Revisión de Diseño
PSP 1.1
PSP 1 Planeación de tareas
Proceso de Estimación de tamaño
Planeación Planeación de tiempos de
Reporte de pruebas actividades
Personal
Estándar de tipos de defectos
PSP 0.1
Proceso de PSP 0 Estándar de Codificación
Medición Proceso actual Medición de Tamaño
Personal Registro de tiempo Propuesta de mejora del proceso
Registro de defectos
Estándar de tipos 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 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.
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 estándar de
código, mediciones de tamaño y el
denominado PIP (Process Improvement
Proposal).
• 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.
II.II. PSP1
Planeación Personal Calidad en el Desarrollo
de Software
de Software
II.II. PSP1
• PSP1 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:
de Software
II.II. PSP1
• 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.
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 avergüenzan de
sus errores. El hecho de que la mayoría de los
errores sean tipográficos o errores tontos hace
que los desarrolladores sientan que pueden
mejorar haciendo más esfuerzo.
de Software
II.III. PSP2
• El problema es que hacer más 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 más 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 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.
de Software
II.III. PSP2
• 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.
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 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.
de Software
II.IV. PSP3
• 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.
de Software
Proceso Personal Cíclico

Especificaciones
Requerimientos Ciclo específico

Y
Planificación
. Diseño detallado
Diseño de . Y
Alto nivel . Repaso del diseño
Desarrollo de las pruebas

Repaso al Diseño
Y repaso
De
Alto nivel
Implementación
Desarrollo
Y Repaso del código
Cíclico
Compilación
Postmortem
Pruebas
Integración
Pruebas del sistema
. Valorar de nuevo
Uso
. Y Reciclar
.
Producto
de Software
II.IV. PSP3
• El proceso cíclico 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 verificación de la calidad del último incremento sin
preocuparse por defectos en ciclos anteriores.
• Si un incremento anterior tiene muchos defectos, la
prueba será más compleja y los beneficios de escalar PSP
se pierden. Esta es una razón para enfatizar revisiones de
diseño y código en los pasos anteriores de PSP.
de Software
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
de Software
Planeación PSP
• La primera tarea consiste en definir los requerimientos,
describiendo el trabajo a realizar en el mayor detalle posible.
• 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.
• 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).
de Software
Planeación PSP
Necesidad Define los
del usuario requerimientos Tareas
Método PROBE
Producir diseño Items

Conceptual
Estimar el tamaño Base de Datos de

del producto Tamaño
Usuario
Estimar los Base de Datos de
recursos Productividad
Recursos
Producir
disponibles
Gestión
Calendario
Entregar el Desarrollar Tamaño, Recursos, Analizar el

el producto Seguimiento de
producto Datos, Plazos proceso Reportes
de Software
Planeación PSP
• 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.
• Luego, durante la etapa de desarrollo del producto, los
desarrolladores efectúan el diseño detallado, la implementación y
las pruebas.
• 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.
• 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.
de Software
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.
de Software
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.
de Software
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 coste de los fallos
(COQ)
• Valoración del rango de fallos (A/FR)
de Software
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
de Software
Flujo del Proceso

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

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
de Software
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.
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 número 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 número 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 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.
de Software

• 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
de Software
Por 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ó Baño, 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 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
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 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.
de Software
Manejo de Interrupciones
• Puesto 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.
de Software
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.
de Software
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).
de Software
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.
de Software
Estándar 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.
de Software
Estándar tipo de Defectos

de Software
Log Registro Defectos

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

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

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

10/10/06 4 10 CÓDIGO PRUEBA 39
Descripción: Alinear y agregar instrucciones de impresión , 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.
• Número
▫ Indicar un número único para este defecto.
Comienza cada proyecto con 1.
de Software

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

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

• Finalmente, la manera más eficaz de encontrar y
arreglar defectos es repasando el código fuente
del programa personalmente. Mientras esto
puede parecer como una manera difícil de
limpiar un programa defectuoso, resulta ser más
rápido y más eficaz. Un método para realizar
revisiones de código es la utilización de guías 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
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.
de Software
Administración del Tiempo

Para la llevar a cabo una buena gestión 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
planificación, se debe documentar y más tarde compáralo con lo que
actualmente se hace.
• Para hacer planes más exactos, se deben determinar los planes
previos erróneos y que deberíamos 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 más fácil en
minutos.
de Software
Conclusiones
• Conociendo los principios y las características de la
metodología de PSP, conformada por los procesos de
planificación, estimación de tamaño y esfuerzo,
recolección de datos, manejo de calidad y
especificaciones de diseño, se plantea la posibilidad de
incorporar esta metodología al contexto de una
empresa pequeña, o grupo de desarrollo de software
pequeño analizando los factores operativos,
económicos y los riesgos a los que se expone
• Una vez implementada esta metodología en el
ambiente de trabajo, un siguiente paso consiste en
enfocarse en la mejora de la eficiencia y de la dinámica
de trabajo a nivel de equipos de desarrollo, mediante el
método conocido como TSP (Team Software Process).

PSP Literatura en Espanol

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PSP Literatura en Espanol

Cargado por

Copyright:

Formatos disponibles

UNIDAD II

Métricas y Procesos PSP

I. Introducción al Personal Software Process

• En los siguientes años, este enfoque a los procesos de trabajo, ha sido

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

• Usando inspecciones, las organizaciones han mejorado substancialmente la

¿ Cómo fue desarrollado PSP?

¿ Cómo fue desarrollado PSP?

¿ Cómo 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

Evolución del PSP

PSP 0 Medición Personal

Visión General de PSP

II.I. Los 7 Pasos de PSP

II.I.I. PSP 0.1

Mientras que la importancia de estas técnicas en proyectos

Proceso Personal Cíclico

Requerimientos Ciclo específico

Desarrollo de las pruebas

Producir diseño Items

Estimar el tamaño Base de Datos de

Entregar el Desarrollar Tamaño, Recursos, Analizar el

Elementos del Proceso

Flujo del Proceso

Guión del proceso

Guión 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

Estándar tipo de Defectos

Estándar tipo de Defectos

Log Registro Defectos

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

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

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

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

Log Registro Defectos

Log Registro Defectos

Log Registro Defectos

Log Registro Defectos

Administración del Tiempo

Seguimiento del Tiempo

También podría gustarte