CSW02

UNIDAD II
Métricas y Procesos PSP

Personal Software Process
LCC. Marcela García Alonso
Calidad en el Desarrollo de Softw

are
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.

are
Índice
II.I. Introducción al Personal Software
Process (PSP)
II.II. Estructura del PSP
III.III. Métricas del PSP

are
II.I. Introducción al Personal
Software Process (PSP)

are
II.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

are
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.

are
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.
are
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] .

are
¿ 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.

are
PSP?
• 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 ]

are
PSP?
• 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.

are
¿ Qué 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.

are
II.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

are
• 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.
are
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.

are
II.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.
are
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.

are
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.
are

are
Objetivo:
• Conocer las métricas de PSP.
• Identificar los objetivos de cada nivel de
PSP.

are
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

are
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

are
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.
are
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.

are
Flujo del Proceso

are
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.

are
Elementos del Proceso

are
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).

are
Evolución del PSP
PSP
PSP 3 3
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 del diseño
Revisión del 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 0
0 Medición Personal
Proceso
Proceso
are
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.
are
II.II.I. Los 7 Pasos de PSP
PSP 3
Proceso PSP 3
Desarrollo Cíclico
Personal Desarrollo Cíclico
Cíclico
PSP 2.1
Administración de PSP 2 PSP 2.1
PSP 2 Formatos de Diseño
Calidad Personal Revisión de Código Formatos de Diseño
Revisión de Código
Revisión de Diseño
Revisión de Diseño
PSP 1.1
PSP 1 PSP 1.1
Proceso de PSP 1 Planeación de tareas
Estimación de tamaño Planeación de tareas
Planeación Estimación de tamaño Planeación de tiempos de
Reporte de pruebas Planeación de tiempos de
Personal Reporte de pruebas actividades
actividades
Estándar de tipos de defectos
PSP 0.1
Proceso de PSP 0 PSP 0.1
PSP 0 Estándar de Codificación
Medición Proceso actual Estándar de Codificación
Proceso actual Medición de Tamaño
Personal Registro de tiempo Medición de Tamaño
Registro de tiempo Propuesta de mejora del
Registro de defectos Propuesta de mejora del
Registro de defectos proceso
Estándar de tipos de defectos proceso
are
II.II.I.I. PSP0
El punto de partida de PSP

are
II.II.I.I. PSP0
• 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.
are
II.II.I.I. PSP0
• 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.

are
II.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.

are
II.II.II. PSP1
Planeación Personal

are
II.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:
are
II.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.

are
II.II.III. PSP2
Calidad Personal

are
II.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.
are
II.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.

are
II.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.
are
II.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.
are
II.II.IV. PSP3
Proceso Personal Ciclico

are
II.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.
are
II.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.
are
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
Uso . Valorar de nuevo
. Y Reciclar
.
Producto

are
II.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.

are
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
are
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).

are
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
are
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.

are
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.

are
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.

are
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)

are
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

are
Flujo del Proceso

are
Guión del proceso
Número Propósito Guiarte en el desarrollo de programas a nivel de módulo
de Fase
Entradas * Descripción del problema Formulario de Resumen del plan del Proyecto
Necesarias 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 Un programa probado
salida Un resumen del Plan de Proyectos con los datos estimados y actuales
Calidad
Las tablas en el Desarrollo
de Registro de Softw
de Tiempos y Defectos Rellenos
are
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.

are
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.

are
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
are
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.

are
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.
are
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.

are
Log Registro del Tiempo
Estudiante: ____________________ Fecha: __________
Instructor:______________________ Programa #: ______
Fecha Inicio Fin Tiempo Tiempo Fase Comenta

de Delta rios
Interrupci
ón

are
• 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.

are
• 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.

are
• 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

are
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
are
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.

are
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.

are
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.

are
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).

are
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.

are
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.

are
Estándar tipo de Defectos

are
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

are
• 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.

are
• 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.

are
• 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.

are
• 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.

are
Guía Personal de
Propósit Guía para realizar una revisión de código efectiva # # # 3 Para Para Fechar %
o 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
Inicializa Chequea las variables e inicialización de parámetros.
ción
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
are
Guía Personal de
Propósit Guía para realizar una revisión de código efectiva # # # 3 Para Para
o Fechar Fechar
%
Formato Cheque el formato de salda

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

are
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.
are
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.
are
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.

are
II.III. Métricas del PSP

are
II.III. Métricas del PSP
Objetivo:
• Aplicar las métricas de PSP.
• Definir y explicar: Los indicadores de
medición del PSP.

are
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

are
Resumen del registro de
Métricas
Nombre: Fecha: 18/10/96
Programa Programa # 13
Profesor Lenguaje: C++
Resumen Plan Actual a la Fecha
Minutos/LOC 5,92 4,87 5,73
LOC/Hora 10,14 12,32 10,47
Defectos/KLOC 94,79 106,4 96,90
Rendimiento
A/FR
Tamaño Programa (LOC):
Total nuevo & Cambiado 58 47 258
Tamaño Máximo 72
Tamaño Mínimo 41

are
Métricas
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

are
Métricas
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

are
Métricas
Eliminación de defectos Plan Actual Para Fecha Para Fecha % Def/Hora
Planing
Diseño
Código
Revisión código 2 3 8 32,0
Compilación 3 2 12 48,0
Test 1 5 20,0
Total 6 5 25 100,0

are
Comparación de PSP
Característica PSP Inspecciones CMM ISO900
Propósito Gerenciamiento y Mejora de la calidad Mejora del Gerenciamiento de
mejora de la calidad gerenciamiento la calidad
Metodología Prescriptiva Presciptiva Descriptiva Descriptiva

Definición Exacta Exacta Vaga Vaga
Audiencia Desarrolladores y Desarrolladores Gerentes Gerentes
gerentes
Cobertura Ciclo de vida del Verificación y Gerenciamiento de Aseguramiento de

desarrollo validación proyectos la Calidad
Costo Muy bajo Bajo Alto Alto

Calidad Muy alta Alta Baja Baja
Implementación Semanas Días Años Años
Alcance Integral Estrecho Ambiguo Ambiguo
Cuan Mensurable es Muy Alto Alto Bajo Bajo

are
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).

are
Team Software Process
TSP

are
Team Software Process
• El resultado final es que incluso aunque
un equipo de ingenieros esté entrenado
en PSP, todavía les queda combinar sus
procesos de trabajo personal dentro de un
único proceso de equipo. Esto es para
ellos un problema, incluso en los más
altos niveles de CMMI. Por esta razón se
ha desarrollado Team Software Process
SM (TSPSM).
are
Perspectiva de PSP
CMMI®
Construye capacidad de
organización
TSPSM
Construye productos de
calidad sobre coste y
planificación
PSPSM
Construye capacidades
individuales y disciplina
de trabajo

are
Introducción TSP
• PSPSM: Construye capacidades individuales y
disciplina de trabajo
• TSPSM: Construye productos de calidad sobre coste
y planificación
• CMMI® :Construye capacidad de organización
• TSP extiende y refina los métodos CMM y PSP, para
guiar a los miembros de los equipos en el trabajo de
mantenimiento y desarrollo. TSP les muestra como
construir un equipo autodirigido y como ser un efectivo
miembro del equipo. También les enseña como dirigir y
soportar estos equipos y como mantener un medio para
obtener un alto nivel de desarrollo.

are
Objetivos TSP
En resumen, se puede decir que TSP tiene 5 objetivos
principales:
• Construir equipos autodirigidos que planifiquen y
realicen un seguimiento de su trabajo, estableciendo
metas además sus propios procesos y planes.
• Mostrar a los directores como entrenar y motivar a sus
equipos y como ayudarles para mantenerles en el más
alto nivel de desarrollo.
• Acelerar la mejora del proceso software haciendo normal
la conducta del Nivel 5 de CMMI
• Mejorar la dirección para obtener organizaciones de un
alto nivel de madurez

are
Objetivos TSP
• La principal ventaja de TSP es que muestra a los ingenieros como
producir productos de calidad por medio de una planificación de
costos. Esto lo hace, enseñándoles cómo planificar su propio
trabajo y haciéndoles participes de los planes y procesos que se
van a llevar a cabo.
• TSP proporciona equipos de proyectos con guías explícitas sobre
como alcanzar sus objetivos. TSP conduce al equipo a través de
cuatro fases dentro de un mismo proyecto. Estos proyectos deben
empezar o terminar con alguna fase o pueden ejecutarse desde el
principio al final. Antes de cada fase, el equipo planifica y organiza
su trabajo mediante una puesta en marcha completa (launch) o
relaunch.
• Generalmente, una vez que los miembros del equipo han sido
entrenados en PSP, es suficiente alrededor de cuatro días para
proporcionar una guía para la puesta en marcha de una fase entera
del proyecto.

are
Evolución de TSUP
Fase Inicial. Creación
Fase Inicial. Creación
de los Grupos y
Lanzamiento de los Grupos y
Requerimientos
Requerimientos
Segunda
SegundaFase.
Fase.Diseño
Diseño
Relanzamiento
Tercera
TerceraFase.
Fase.
Implementación
Implementación
Relanzamiento
Cuarta
CuartaFase.
Fase.Integración
Integración
yyPruebas
Pruebas
Relanzamiento
Postmorte
Postmorte
mm
are
Equipos de Trabajo
• El Software Engineering Institute (SEI) ha desarrollado el
TSP para ayudar a equipos de ingenieros de software
a desarrollar productos de software de manera eficiente.
• Este proceso ataca varios de los problemas actuales en
el desarrollo intenso de productos de software y enseña
a equipos de trabajo y gerencia como resolverlos.
• El TSP muestra a grupos de ingenieros como aplicar
conceptos integrados en el desarrollo de software,
encamina a los ingenieros y a la gerencia en un proceso
de 4 días para establecer los objetivos, definir los roles,
atacar los riesgos y producir un plan de trabajo
comprensivo. Siguiendo el lanzamiento el TSP provee
un marco de procesos definidos y medibles para
administrar, supervisar y reportar el trabajo en equipo.

are
Equipos de Trabajo
El TSP tiene 5 fases principales.
• Requerimientos
• Diseño
• Implementación
• Pruebas
• Postmortem
Cada equipo puede estar conformado por al menos 2
personas y hasta 15 personas como máximo. Los
miembros del equipo deben trabajar hacia un objetivo
común y tiene roles específicos o responsabilidades
dentro del equipo. Existe una interdependencia entre el
trabajo de los miembros del equipo que requiere
cooperación para que el equipo sea exitoso y por lo
mismo siguen un proceso de trabajo común.
are
Generación de Equipos
con PSP y TSP
• Se puede decir que esta sería una fase preliminar a la hora
de arrancar un proyecto utilizando TSP. En esta fase se
establecen la función de cada uno de los miembros del grupo,
las metas, los mecanismos de comunicación y los datos
requeridos.
• Es importante que cada miembro del grupo sepa cual va a ser
su función y sus responsabilidades, y debería comprobar si
alguno de los miembros del grupo necesita ayuda. Además
cada miembro del grupo debe proporcionar una copia
completa del formulario WEEK para que el jefe del proyecto
pueda planificar la siguiente fase.
• Se debe crear un diseño conceptual para cada producto
planificado y dividir en ciclos y documentar el trabajo.
Además se debe de tener una infraestructura para poder
realizar estas funciones como por ejemplo formularios que
controlen los errores, el control de la entrada/salida, etc.
are
con PSP y TSP
• Los miembros del grupo deben planificar una fase de
implementación personal utilizando por ejemplo PSP. Esta
planificación y documentación debe ser estándar para todos los
miembros del grupo y para ello utilizar los mismos formularios.
• Se deben especificar los bucles de pruebas, los valores de las
variables que se van a usar y los condiciones de error que se vayan
a producir, establecer los límites de posibles valores de las
variables, los datos más críticos, etc.
• Además se debe realizar un desarrollo explicito de las pruebas que
se vayan a realizar y las revisiones de código que se vayan a hacer
• Como se ha explicado antes todas las pruebas se deben planificar
con anticipación y establecer una forma estándar de realizarlas y
documentarlas para solucionar los posibles problemas y errores
que hayan producido.
• En la documentación debe aparecer quien o quienes de los
miembros del grupo son los encargados de realizar las pruebas y
quienes son los encargados de instalar el producto final.
are
con PSP y TSP
• Al final de cada ciclo y cada grupo debe realizar una memoria de su
trabajo y comparar el resultado con las metas establecidas al
principio del ciclo para poder así extraer conclusiones.
• Esta memoria debería contener:
– El tamaño del producto
– Las horas de desarrollo
– El rango de líneas de código por hora (LOC/Hours)
– El rendimiento antes de la compilación
– El rendimiento antes de las pruebas del sistema
– El nivel de defectos en la compilación
– El nivel de defectos en todas las fases de pruebas
• Además de todo lo anterior expuesto, los grupos deberían aportar la
relación de inspecciones y revisiones realizadas y los valores
obtenidos en ellas.

are
Relación del TSP con
CMMI y PSP
• Mientras que el CMMI se enfoca en lo que tienen que
hacer las organizaciones, no especifica como alcanzar
esos objetivos. El PSP provee una guía especifica en
como los ingenieros de software de manera individual
pueden continuamente mejorar su desempeño. El TSP
provee guías especificas de como ingenieros
capacitados en PSP pueden trabajar de manera efectiva
como miembros de un equipo de alto desempeño. Todas
estas tecnologías pueden trabajar juntas para permitir a
las organizaciones producir software de calidad en
tiempo y presupuesto.

are
Relación del TSP con
CMMI y PSP
CMMI Organización
TSP Equipo
Individual
PSP

are
PSP y TSP respecto a
CMMI
• CMMI, PSP y TSP proporcionan un marco tridimensional para
la mejora de los procesos.
• CMMI (SW/SE) tiene 22 áreas de proceso, y PSP y TSP
guían a los ingenieros en el direccionamiento de casi todo el
trabajo. Estos métodos no solo ayudan a que los ingenieros
sean más efectivos sino también proporcionan el
entendimiento necesario para acelerar la mejora del proceso.
• Una vez que los grupos han empezado el proceso de mejora
y están en el camino de alcanzar el Nivel 2 de CMMI, PSP
muestra a los ingenieros como direccionar sus tareas de una
forma profesional. Aunque relativamente nuevo, PSP también
mejora la habilidad de los ingenieros para planificar y realiza
un seguimiento de su trabajo y producir así productos de
calidad.

are
Nivel Enfoque del Proceso Clase de Área de Proceso PSP TSP
PSP y TSP respecto a

5 Optimizado Mejora Continua del Proceso Análisis Causal y Resolución X X
Implementación e Innovación Organizacional X X
CMMI
4 Administración Cuantitativa Administración cuantitativa del Proyecto X X
Administrad del Proceso
Rendimiento del Proceso Organizacional
o
Cuantitativa X X
mente
3. Definido Estandarización del Proceso Enfoque en el Proceso Organizacional X X
Definición del Proceso Organizacional X X
Capacitación Organizacional
Administración del proyecto Integrado X X
Desarrollo de Requerimientos X X
Solución Técnica X X
Integración del Producto X X
Verificación X X
Validación X X
Administración de Riesgos X
Análisis y Resolución de Decisión X X
2 Administración del Proyecto Administración de Requisitos X
Administrad
Planeación de Proyectos X X
o
Monitoreo y control de Proyectos X X
Aseguramiento de la Calidad Software X
Administración de la Configuración del Software X
are
Administración de Acuerdos con Proveedores
Componentes del TSP
• Los equipos de TSP estiman proyectos con una aproximación arriba-
abajo, utilizando todo el tamaño y mediante la productividad del
equipo, determinar el programa completo. Como se ha descrito
anteriormente, el proyecto se divide en fases y cada una de ellas es
estimada y rastreada.
• En las puestas en marcha de cada fase, se definen las tareas y para
cada tarea se realiza una estimación usando métodos rigurosos de
Personal Software Process (PSPSM). Estas estimaciones se utilizan
para generar un plan detallado de valores-ganados, con el cual se
identificara el seguimiento y planificación de las metas del proyecto,
criterios de calidad y riesgos de las puestas en marcha.
• TSP requiere entrevistas periódicas donde se comparan los progresos
con la planificación del equipo en términos de valores ganados y
calidad. Si hay desviaciones con respecto a la planificación, se
pueden determinar las razones y tomar medidas para que se retorne
otra vez a dicha planificación. Es también durante estas entrevistas
periódicas, donde se revisan los riesgos que se han producido
durante la puesta en marcha.
are
Componentes del TSP
• Las puestas en marcha de TSP no concluyen satisfactoriamente
hasta que el equipo y la dirección estén de acuerdo sobre los
requerimientos y el desarrollo. Una vez que se ha determinado el
desarrollo, se usa como base para una medida personal y los
valores se rastrean por cada persona y periódicamente por el
equipo.
• El TSP también requiere replanificación de un proyecto, o más
tarde actualización, cuando las especificaciones del plan cambian.
Esto significa que cuando estas especificaciones cambian a lo largo
del proyecto, el equipo renegocia la planificación, delibera la
funcionalidad y si es necesario el coste.
• Finalmente, los problemas con la calidad pueden ser virtualmente
eliminados usando TSP, ya que los métodos de calidad usados son
los mismos que los usados en PSP y que los ingenieros realizan
individualmente cuando llevan a cabo sus revisiones, diseños y
codificaciones.

are
Roles dentro del TSP
• TSP se ha utilizado con grupos de software y también con grupos donde se
mezcla el hardware, software y sistemas. El tamaño de los grupos puede
variar desde 3 hasta 12 o 15 personas. Estos grupos a su vez pueden
interactuar entre ellos. Pero para que todo esto funcione es necesario que
previamente los integrantes de cada grupo hayan sido entrenados en PSP.
• La puesta en marcha de un proyecto TSP incluye los siguientes pasos:
– Revisar con la dirección los objetivos del proyecto.
– Establecer los roles del equipo.
– Documentar los objetivos del equipo.
– Producir la totalidad de la estrategia de desarrollo.
– Definir los procesos de desarrollo del equipo.
– Planificar los soportes que se necesitan.
– Realizar una planificación del desarrollo para el proyecto entero.
– Realizar una planificación de la calidad y el conjunto de objetivos de calidad.
– Realizar una planificación detallada para cada ingeniero para la siguiente fase.
– Unir las planificaciones individuales dentro de un plan de equipo
– Rebalancear el trabajo de equipo para conseguir un mínimo programa.
– Calcular los riesgos y asignar responsabilidades para cada clase de riesgo.
– Tener una puesta en marcha de postmortem.

are
Roles dentro del TSP
• Al final de cada puesta en marcha, el equipo revisa los
planes y los riesgos del proyecto con la dirección. Una
vez que el proyecto comienza, el equipo realiza
semanalmente reuniones y periódicamente informa de
ello a la dirección y al cliente. Después de establecer
estos pasos, TSP produce los siguientes resultados:
– Se han escrito las metas
– Se han definido los roles como por ejemplo Director de Diseño,
Director de Planificación, Director de Proceso, Director de
Soportes, Director de Pruebas o Jefe de Equipo. Normalmente
los miembros del equipo con rol, son los encargados de detectar
los riesgos. Pro ejemplo, un riesgo implica que las
negociaciones con el cliente deberían estar asignadas al
Director de Interfaces del Cliente.

are
Bibliografía
• HUMPHREY WATTS S., A DISCIPLINE
FOR SOFTWARE ENGINEERING.
(USA : ADDISON-WESLEY, 1995)

are
Deming: 14 Puntos
1. CONSTANCIA
• El propósito es mejorar constantemente los productos y servicios de la
empresa, teniendo como objetivo la consecución de la competitividad
permaneciendo en el mercado para proporcionar empleo por medio de la
innovación, la investigación, el mejoramiento continuo y el mantenimiento
adecuado.
2. NUEVA FILOSOFÍA
• Se trata de adoptar una nueva filosofía de empresa ya que estamos
viviendo una nueva era económica (mucho más ahora) en la que los
gerentes deben tomar conciencia de sus responsabilidades y afrontar la
cuota de liderazgo que les cabe para lograr el cambio.
3. LA INSPECCIÓN
• Se debe dejar de depender de la inspección masiva para alcanzar la
calidad, hay que eliminar la inspección en masa a través de la integración
del concepto de calidad en todo el proceso de producción, lo cual aminora
costos y permite aumentar calidad.

are
Deming: 14 Puntos
4. LAS COMPRAS
• Hay que eliminar la práctica de comprar basándose exclusivamente en el
precio, ya que los departamentos de compras tienden a elegir al proveedor
con los precios más bajos. En su lugar, se deben concentrar esfuerzos en
minimizar los costos totales, creando relaciones sólidas y duraderas con un
solo proveedor para cada materia prima, basándose en la fidelidad y la
confianza.
5. MEJORAMIENTO CONTINUO
• La búsqueda por mejorar debe ser continua, no momentánea ni estática, se
deben mejorar los procesos productivos, el servicio y la planeación, además
la administración debe propender por la minimización de costos a través de
la reducción de pérdidas y mermas y productos defectuosos.
6. ENTRENAMIENTO
• Se debe instituir el entrenamiento y la capacitación de los trabajadores
como una de las tareas del diario acontecer, con esto no sólo se consiguen
mejores empleados sino mayores resultados en cuanto a calidad y costos.

are
Deming: 14 Puntos
7. LIDERAZGO
• Las organizaciones deben adoptar e instituir el liderazgo, de manera que la
labor de los supervisores o jefes no se limite a dar órdenes o impartir
castigos, sino que más bien se convierta en un orientador que le ayude a la
gente a hacer mejor su trabajo y que identifique quiénes son las personas
que necesitan mayor ayuda para hacerlo.
8. EL MIEDO
• Las firmas deben desterrar el temor y el miedo de todos sus niveles, hay
que generar confianza entre la gente de manera que no sientan temor de
opinar o preguntar, esto permite mayor efectividad en el trabajo y permite
que las personas se esfuercen porque quieren que la empresa alcance el
éxito.
9. BARRERAS
• Romper las barreras que existan entre los diferentes departamentos y su
gente, no crear competencias que las hagan chocar sino más bien generar
la visión de largo plazo que les permita a todos trabajar por conseguir los
mismo objetivos, permitiendo así la colaboración y la detección temprana
de fallos.

are
Deming: 14 Puntos
10. SLOGANS
• Hay que borrar los slogans o las frases preestablecidas, estos no sirven y lo
que causan es relaciones adversas que redundan en pérdidas de
competitividad y calidad.
11. CUOTAS
• Deben eliminarse las cuotas numéricas, tanto para trabajadores como para
gerentes. Las cuotas sólo toman en cuenta los números, no los procesos,
los métodos o la calidad y por lo general se constituyen en garantía de baja
calidad y altos costos. Las cuotas se deben sustituir con liderazgo,
eliminando el concepto de gerencia por objetivos.
12. LOGROS PERSONALES
• Hay que derribar las barreras que le quitan a las personas el orgullo que les
produce su trabajo, eliminando los sistemas de comparación o de méritos,
estos sistemas sólo acarrean nerviosismo y disputas internas.

are
Deming: 14 Puntos
13. CAPACITACIÓN
• Se debe establecer un programa interno de educación y automejoramiento
para cada quien, hay que permitir la participación de la gente en la elección
de las áreas de desarrollo
14. TRANSFORMACIÓN
• Todos, absolutamente todos los miembros de la organización deben
esforzarse por alcanzar la transformación en cuanto a calidad, procesos,
productos y servicios, la transformación es el trabajo de todos, pero eso si,
hay que basarse en un equipo que reúna condiciones suficientes de
capacidad y liderazgo.

are
Deming: 7 pecados
capitales
• 1. Carencia de constancia en los propósitos
• 2. Enfatizar ganancias a corto plazo y
dividendos inmediatos
• 3. Evaluación de rendimiento, calificación de
mérito o revisión anual
• 4. Movilidad de la administración principal
• 5. Manejar una compañía basado solamente en
las figuras visibles
• 6. Costos médicos excesivos
• 7. Costos de garantía excesivo
are
Juran
Juran tiene una talla comparable a la de Deming,
pero a diferencia de éste, creó una empresa de gran
tamaño dedicada a la explicación e implantación de
la calidad total en cualquier negocio. Existen cursos,
videos, ciclos de conferencias, personal
especializado en todos los aspectos de esta teoría,
que se ofrecen a cualquier compañía que pueda
beneficiarse con la aplicación de la calidad total.
A) LOS TRES pasos:
• Alcanzar continuamente progresos estructurados, mediante la
dedicación y un sentido de urgencia
• Establecer programas abarcadores de entrenamiento
• Comprometer a los supervisores a tomar en serio sus
responsabilidades (“diminishing return”)

are
Juran
B) LOS DIEZ pasos:
• Crear conciencia de la necesidad de mejorar
• Establecer metas de progreso
• Organizarse para alcanzar las metas propuestas
• Proveer entrenamiento
• Establecer proyectos dedicados a la solución de problemas
• Hacer reportes de progreso
• Dar reconocimientos
• Hacer públicos los logros alcanzados
• Mantener un sistema operacional de medición de logros
• No dejar caer el entusiasmo por la superación aunque todo esté
marchando bien (no dormirse en los laureles)

are
Juran
– EL PRINCIPIO ...
• También llamado 80/20. Lo enunció por
primera vez el economista Wilfredo Pareto a
principios del siglo. Establece que en un
sistema de control de calidad debe hacerse un
esfuerzo por identificar las fuentes de
problemas y concentrarse en eliminarlas antes
que nada. Según datos estadísticos, las
fuentes del 80% de los problemas están en
sólo un 20% de los empleados. Aunque es
una regla antigua, Juran la demostró y
revitalizó.

are
Juran
• LA TRILOGÍA ...
– La administración de una empresa
debe tener tres programas básicos:
– Planificación de calidad que consiste en desarrollar los
productos, sistemas y procesos necesarios para satisfacer
las esperanzas de los clientes. Esto requiere los siguientes
pasos:
» Determinar quiénes son los clientes.
» Identificar sus necesidades.
» Desarrollar productos que respondan a estas
necesidades
» Desarrollar sistemas y procesos que permitan producir
esos productos, y
» Establecer planes detallados a todos los niveles de
operación.

are
Juran
• Control de calidad. Esto requiere los siguientes pasos:
– Evaluar la calidad inicial
– Comparar el funcionamiento de la empresa con lo que sería
una situación ideal, y
– Resolver las diferencias entre el estado actual y el ideal
• Mejoramiento de la calidad. Esto debe ser un objetivo al
cual deben dedicarse esfuerzos constantes. Se logra con
los siguientes cuatro pasos:
– Desarrollar la infraestructura necesaria para lograr mejoras
anuales en la calidad
– Identificar áreas específicas que deben mejorarse, y poner
en práctica planes para lograrlo
– Establecer un equipo de trabajo para cada proyecto de
mejoramiento de la calidad
– Dar a estos equipos de trabajo todo lo que necesiten para
cumplir con sus encomiendas

are

CSW02

Uploaded by

Document Information

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

CSW02

Uploaded by

Copyright:

Available Formats

UNIDAD II

Métricas y Procesos PSP

LCC. Marcela García Alonso

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

• 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

Calidad en el Desarrollo de Softw

• Usando inspecciones, las organizaciones han mejorado substancialmente

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Para que los desarrolladores lleguen a entender su

Calidad en el Desarrollo de Softw

Finalmente, deben analizar los resultados

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

El punto de partida de PSP

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Mientras que la importancia de estas técnicas en proyectos

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Proceso Personal Ciclico

Calidad en el Desarrollo de Softw

Requerimientos Ciclo específico

Desarrollo de las pruebas

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Producir diseño Items

Estimar el tamaño Base de Datos de

Entregar el Desarrollar Tamaño, Recursos, Analizar el

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

• En PSP, los desarrolladores utilizan información para

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw

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 %

Calidad en el Desarrollo de Softw

Calidad en el Desarrollo de Softw