PSP Métricas y Procesos para Calidad en Desarrollo de Software

UNIDAD II Mtricas y Procesos PSP
Personal Software Process

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

I. Introduccin al Personal Software Process (PSP)

Objetivo: Conocer los antecedentes, principios y pasos del PSP. Definir y explicar los orgenes de PSP
Antecedentes
Despus de la segunda guerra mundial, la estrategia de calidad en la mayora de las organizaciones industriales se basaba casi por completo en las pruebas. Las empresas establecieron departamentos especiales de la calidad para encontrar y arreglar problemas despus de la produccin de los productos. No fu sino hasta los aos 70 y los aos 80 que W. Edwards Deming y J.M. Juran convencieron a la industria estadounidense que se centrara en mejorar la forma en la que la gente haca sus trabajos y desarrollaban sus procesos. [ DEMING; 82 ], [ JURAN 88] En los siguientes aos, este enfoque a los procesos de trabajo, ha sido responsable de las mejoras importantes en la calidad de automviles, de la electrnica, o de casi cualquier otra clase de producto. La estrategia tradicional que haba de "prueba-y-arregla" ahora es reconocida como costosa, que desperdicia tiempo y que adems es ineficaz para el trabajo de la ingeniera y de la fabricacin.
Antecedentes
Aunque la mayora de las organizaciones industriales ahora han adoptado principios modernos de calidad, la comunidad del software ha continuado confiando en la prueba como el mtodo principal de la administracin de la calidad. Para el software, la primera medida principal en la direccin iniciada por Deming y Juran fu tomada por Michael Fagan cuando en 1976 l introdujo las inspecciones del software [ FAGAN; 86] Usando inspecciones, las organizaciones han mejorado substancialmente la calidad del software. Otra medida significativa en la mejora de calidad del software fu tomada con la introduccin del modelo de capacidad de madurez (CMM) en 1987. El enfoque principal de CMM estaba en el sistema que administraba la ayuda que se le proporcionaba a los ingenieros de desarrollo. CMM ha tenido un efecto positivo en el funcionamiento de las organizaciones del software [ HERBSLEB; 97] Otra medida significativa en la mejora de calidad del software fu tomada con la esencia del proceso personal del software (PSP) ya que PSP ampla el proceso de mejora a la gente que realiza el trabajo de desarrollo de software.
Antecedentes
PSP se concentra en las prcticas de trabajo de los ingenieros en una forma individual. El principio detrs de PSP es se, sirve para producir software de calidad, cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad.
PSP se dise para ayudar a profesionales del software para que utilicen constantemente prcticas sanas de ingeniera de software.
Asimismo les ensea a cmo planear y darle un seguimiento a su trabajo, a utilizar un proceso bien definido y medido, a establecer metas mesurables, y finalmente a la utilizacin del rastreo constante para alcanzar dichas metas. PSP les demuestra a los ingenieros a cmo manejar la calidad desde el principio del trabajo, a cmo analizar los resultados de cada trabajo, y a cmo utilizar los resultados para mejorar el proceso del proyecto siguiente. [SEI; 2000] .
Cmo fue desarrollado PSP?

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

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

Casi al mismo tiempo, Jim Over y Neil Reizer del SEI y Robert Powels de la compaa de Servicios Informativos Avanzados (AIS por sus siglas en ingls) desarrollaron el primer curso para entrenar a los instructores a ensear el curso de PSP en la industria. Humphrey junto con el SEI han continuado trabajando en el desarrollo de PSP y asmismo han aplicado los mismos principios al Proceso en Equipo de Software o TSP.
Qu es PSP?
Un PSP es un proceso personal para desarrollar software.
pasos definidos formularios estndares
Un PSP es un marco de trabajo de medicin y anlisis que te ayuda a caracterizar tu proceso. Es tambin un procedimiento definido para ayudarte a mejorar tu rendimiento.
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

Como todo profesional software deberas conocer tu propio rendimiento. Deberas medir, seguir y analizar tu trabajo. Deberas aprender de tus variaciones de tu rendimiento. Deberas incorporar esas lecciones a tu manera personal de hacer.

El diseo de PSP se basa en los siguientes principios de planeacin y de calidad [HUMPHREY; 95]
Cada ingeniero es esencialmente diferente; para ser ms precisos, los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales. Para mejorar constantemente su funcionamiento, los ingenieros deben utilizar personalmente procesos bien definidos y medidos. Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos.
I.I. Principios del PSP

Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes. Es ms eficiente prevenir defectos que encontrarlos y arreglarlos. La manera correcta de hacer las cosas es siempre la manera ms rpida y ms barata de hacer un trabajo.

Para hacer un trabajo de ingeniera de software de la manera correcta, los ingenieros deben planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un proceso bien definido para realizar de la mejor manera la planeacin del trabajo. Para que los desarrolladores lleguen a entender su funcionamiento de manera personal, deben medir el tiempo que pasan en cada proceso, los defectos que inyectan y remueven de cada proyecto y finalmente medir los diferentes tamaos de los productos que llegan a producir.

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.
II. Estructura del PSP

II. Estructura del PSP

Objetivo: Conocer las mtricas de PSP. Identificar los objetivos de cada nivel de PSP.
Introduccin
El PSP es un proceso diseado para uso individual, basado en una versin a escala de un proceso industrial. El principal objetivo del PSP es ayudar a los ingenieros software a hacer mejor su trabajo. EL PSP se ha diseado tambin para demostrar el valor del uso de un proceso definido y medido. Por ultimo, el PSP intenta ayudar a los ingenieros y a las organizaciones a que cumplan las demandas cada vez mas estrictas para el desarrollo de sistemas software de calidad
Introduccin
El PSP se aplica en tareas personales estructuradas:
Desarrollo de mdulos de programas. Definicin de requisitos o procesos. Realizacin de revisiones o pruebas. Escritura de documentacin, etc. El PSP se puede extender al desarrollo de sistemas software de gran tamao. Es un proceso de Nivel 5 para los individuos y es un prerrequisito para el TSP
Introduccin
PSP se introduce con siete pasos compatibles. Escribes uno o dos pequeos programas en cada paso. Recoges y analizas los datos de tu trabajo. Los usas y analizas para mejorar tu trabajo.
Estructura de PSP
Comenzando con los requerimientos, el primer paso en el proceso de PSP es la planificacin. Existe un script de planificacin que sirve de gua y un resumen del plan para registrar todos los datos del mismo. Mientras los desarrolladores van siguiendo el lineamiento de trabajo sugerido por los scripts, deben ir registrando los tiempos dedicados y los datos de defectos en los logs de tiempos y defectos. Al final de la tarea, durante la fase de postmortem (PM), deben resumir los datos de tiempo y defectos, medir el tamao del programa, e ingresar esos datos en el formulario de sumario del plan. Al finalizar, deben entregar el producto finalizado y el formulario de sumario del plan completado.
Flujo del Proceso
Estructura de PSP
Debido a que generalmente ciertos mtodos de PSP no son utilizados por los desarrolladores, los mtodos de PSP son presentados en una serie de siete versiones de procesos. Estas versiones son denominadas como PSP0 a PSP3. Cada versin tiene un mismo conjunto de logs, formularios, scripts, y standards. Los scripts de proceso definen los pasos de cada parte del proceso, los logs y formularios proveen templates para registrar y almacenar datos, y los standards guan a los desarrolladores a mientras hacen el trabajo. En otras palabras, PSP es un proceso que est diseado para ser utilizado.
Elementos del Proceso
Estructura de PSP
Est construido en un formato simple de utilizar con instrucciones simples y precisas. Si bien los scripts describen qu hacer, en realidad se parecen ms a checklists que a tutoriales. Estos no incluyen los materiales instructivos que seran necesarios para usuarios no entrenados. El propsito de los scripts es el de guiar a los desarrolladores en el uso consistente de los procesos, los cuales ellos conocen (mediante la asistencia a cursos de capacitacin en PSP o a travs de bibliografa introductoria en el uso de PSP).
Evolucin del PSP

PSP 3 Desarrollo Cclico
PSP 2 Revisin del cdigo Revisin del diseo
PSP 1 Estimacin del Tamao Informe de pruebas
Proceso Personal Cclico
Calidad Personal
Planificacin Personal
PSP 0 Proceso
Medicin Personal
Visin General de PSP

PSP0 - estableces una lnea base del rendimiento mensurable. PSP1 - haces planes de tamao, recursos y calendario. PSP2 - Practicas gestin de defectos y rendimiento. PSP3 - Amplias los mtodos del PSP a proyecto mayores.
II.I. Los 7 Pasos de PSP

PSP 3 Desarrollo Cclico Administracin de Calidad Personal PSP 2 Revisin de Cdigo Revisin de Diseo PSP 2.1 Formatos de Diseo
Proceso de Planeacin Personal
PSP 1 Estimacin de tamao Reporte de pruebas
PSP 1.1 Planeacin de tareas Planeacin de tiempos de actividades Estndar de tipos de defectos
Proceso de Medicin Personal
PSP 0 Proceso actual Registro de tiempo Registro de defectos Estndar de tipos de defectos
PSP 0.1 Estndar de Codificacin Medicin de Tamao Propuesta de mejora del proceso
II.I.I. PSP0
El punto de partida de PSP
II.I.I. PSP0
PSP0 es un proceso sencillo, definido y personal. Utiliza tus mtodos actuales de diseo y desarrollo. Recoge datos sobre tu trabajo:
tiempo gastado por fase defectos encontrados en compilacin y pruebas
Proporciona un informe resumen.
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.
II.I.I. PSP 0.1

Se pasa a PSP0.1 agregando un estndar de cdigo, mediciones de tamao y el denominado PIP (Process Improvement Proposal). El PIP provee una manera estructurada de registrar problemas, experiencias y sugerencias para mejorar. PSP0.1 tambin mejora las mediciones para contar separadamente mtodos y procedimientos.
II.II. PSP1
Planeacin Personal
II.II. PSP1
PSP1 Planeacin personal PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega estimaciones de tamao y recursos y un reporte de prueba. En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. Los desarrolladores son enseados a:
II.II. PSP1
Entender la relacin entre el tamao de los programas que escriben y el tiempo que les toma desarrollarlos. Aprender a realizar compromisos que puedan cumplir. Preparar un plan ordenado para realizar su trabajo Establecer una base para realizar un seguimiento de su trabajo. Mientras que la importancia de estas tcnicas en proyectos grandes es comprendida, pocos desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos mtodos en el nivel personal.
II.III. PSP2
Calidad Personal
II.III. PSP2
Un objetivo de PSP es ayudar a los desarrolladores a lidiar de manera realista y objetiva con los defectos que introducen. Los programadores por lo general se avergenzan de sus errores. El hecho de que la mayora de los errores sean tipogrficos o errores tontos hace que los desarrolladores sientan que pueden mejorar haciendo ms esfuerzo.
II.III. PSP2
El problema es que hacer ms esfuerzo por lo general hace que las cosas empeoren; las claves, como en otras actividades, son las habilidades inherentes y las capacidades. En PSP2 se enfoca en mejorar la habilidad del desarrollador para producir programas de calidad. La idea es hacer al trabajo de calidad ms natural y consistente. Mejoras significativas en la frecuencia de defectos de los desarrolladores no son posibles a menos que conozcan cuantos errores cometen y que comprendan sus causas y consecuencias.
II.III. PSP2
PSP2 agrega diseo personal y revisiones de cdigo a PSP1. Estas revisiones ayudan a encontrar defectos de manera temprana y a ver los beneficios que esto proporciona. Los desarrolladores analizan los defectos que encuentran en los primeros programas y usan estos datos para establecer checklists de revisin que estn hechos a medida de su experiencia de defectos personales.
II.III. PSP2
El proceso de diseo es contemplado en PSP2.1. El objetivo no es decirle a los desarrolladores como disear sino orientar el criterio para la finalizacin del diseo, es decir, cuando han terminado que es lo que deben haber obtenido. Se establece un criterio de completitud de diseo y se examinan varias tcnicas de verificacin y consistencia de diseo.
II.IV. PSP3
Proceso Personal Ciclico
II.IV. PSP3
Hasta este punto PSP se concentr en el proceso lineal para construccin de pequeos programas. PSP3 presenta mtodos para ser usados por individuos en la realizacin de programas de gran escala. De todas formas sigue enfocado en el individuo y no trata los problemas de comunicacin y coordinacin que son una parte importante del desarrollo de sistemas de gran escala.
II.IV. PSP3
Para escalar PSP2 a proyectos ms grandes la estrategia consiste en subdividir el proceso personal de desarrollo de grandes programas en elementos en la escala de PSP2. Estos programas son entonces diseados para ser desarrollados en pasos incrementales. La primera construccin consiste en un mdulo base o kernel que es ampliado en ciclos iterativos. En cada iteracin se utiliza un PSP2 completo, incluyendo diseo, codificacin, compilacin y pruebas.

Especificaciones Requerimientos Y Planificacin Ciclo especfico Diseo de Alto nivel
. . .
Diseo detallado Y Repaso del diseo
Repaso al Diseo De Alto nivel Desarrollo Cclico
Desarrollo de las pruebas Y repaso
Implementacin Y Repaso del cdigo
Compilacin Postmortem Pruebas Integracin Pruebas del sistema Uso
. . .
Valorar de nuevo Y Reciclar
Producto
II.IV. PSP3
El proceso cclico PSP3 puede ser un elemento efectivo en un proceso de desarrollo de gran escala solo si cada incremento sucesivo de software es de alta calidad. De esta manera los desarrolladores pueden concentrarse en la verificacin de la calidad del ltimo incremento sin preocuparse por defectos en ciclos anteriores. Si un incremento anterior tiene muchos defectos, la prueba ser ms compleja y los beneficios de escalar PSP se pierden. Esta es una razn para enfatizar revisiones de diseo y cdigo en los pasos anteriores de PSP.
Planeacin en PSP
Por qu hacer planes? Te permiten llegar a acuerdos que tu puedas cumplir Proporcionar las bases para acuerdo en tu trabajo Gua tu trabajo Te ayuda a seguir tu progreso Terminacin del proyecto
Planeacin PSP
La primera tarea consiste en definir los requerimientos, describiendo el trabajo a realizar en el mayor detalle posible. Como la etapa de planificacin es demasiado temprana como para hacer un diseo completo del producto, los desarrolladores realizan un diseo conceptual, mediante el cual se obtiene un primer acercamiento de cmo debe basarse el producto a ser construido en la etapa de desarrollo. La siguiente tarea consiste en la estimacin de tamao y de esfuerzo. La correlacin entre el tamao de un programa y tiempo de desarrollo es moderadamente buena para equipos de desarrollo; sin embargo, para un solo desarrollador, la correlacin es generalmente un poco mayor. Los desarrolladores realizan las estimaciones utilizando datos histricos personales de tamao y productividad. En PSP, las estimaciones se efectan mediante el mtodo PROBE (PROxy Based Estimating).
Planeacin PSP
Necesidad del usuario Define los requerimientos
Mtodo PROBE
Tareas
Producir diseo Conceptual
Items
Estimar el tamao del producto
Base de Datos de Tamao
Usuario
Estimar los recursos Base de Datos de Productividad
Producir Calendario
Recursos disponibles
Gestin
Entregar el producto
Desarrollar el producto
Tamao, Recursos, Datos, Plazos
Analizar el proceso
Seguimiento de Reportes
Planeacin PSP
Una vez que los desarrolladores conocen el tiempo requerido para cada proceso, deben estimar el tiempo que van a dedicar al trabajo cada da de la semana, conformando entonces el calendario. Luego, durante la etapa de desarrollo del producto, los desarrolladores efectan el diseo detallado, la implementacin y las pruebas. Despus de completar el trabajo, los desarrolladores realizan un anlisis postmortem, en el cual se actualiza el sumario del plan con los datos reales de tiempos invertidos en cada etapa del desarrollo, defectos encontrados y removidos, etc, y se comparan los resultados obtenidos con lo planeado. Finalmente, los desarrolladores registran toda esta informacin en sus bases de datos histricas de tamao y productividad. Adems se examinan las Propuestas de Mejoras (PIP) para hacer ajustes en los procesos.
Planeacin PSP
La Medicin del trabajo personal es el primer paso por el que comienza el PSP. Es este primer paso los ingenieros deben aprender como aplicar los formularios del PSP y apuntar datos de su trabajo personal. Para hacer todo esto se mide el desarrollo del tiempo y de los defectos. Esto hace que los ingenieros recojan datos reales y prcticos y les proporciona una serie de marcar con las cuales ir midiendo el proceso. Para realizar un trabajo con PSP se debe empezar por el primer paso de medicin personal que incluye la gestin del tiempo y el siguiente rastreo del mismo.
Recoleccin de datos
En PSP, los desarrolladores utilizan informacin para monitorear su trabajo, la cual los ayuda a hacer mejores planes. Para esto, deben recolectar datos de los tiempos que dedican a cada fase del proceso, de los tamaos de los productos que producen, y de la calidad de esos productos. Las medidas bsicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso, los defectos introducidos y encontrados en cada fase, y los tamaos de los productos desarrollados en lneas de cdigo (LOC). Estos datos se recopilan en cada fase del proceso y se resumen a la terminacin del proyecto. Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como gua en su trabajo.
Recoleccin de datos
Las principales medidas son: Tamao tiempo de estimacin de errores Coste de realizacin Defectos producidos y corregidos por hora Produccin del proceso Valoracin y calidad del coste de los fallos (COQ) Valoracin del rango de fallos (A/FR)
Elementos del Proceso

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

Planificacin
Estimar tiempo de desarrollo.
Desarrollo
Desarrollar el producto utilizando tus mtodos actuales.
Post-mortem
Completar el resumen del plan proyecto, con los tiempos gastados y defectos encontrados e inyectados en cada fase.
Guin del proceso

Diseo Codificacin
Disear el programa, usando tus mtodos de diseo actuales. Implementa el programa. Compila hasta que este libre defectos. Prueba el programa y corrige todos los defectos.
Compilacin Prueba
Registra los defectos en el Log de defectos y tiempos por fase en el Log de tiempos.
Resumen del Plan

Estudiante: _Juan Lus Guerra_________ Programa:_Raz Cuadrada_____________ Instructor: _XX_______________________ Tamao del programa (LOC) Plan Total (Nuevas&Modificadas) 50 33 Tiempo en Fase (minutos) Plan Planeacin Diseo Codificacin Compilacin Prueba Postmortem Total Defectos Introducidos Planeacin Diseo Codificacin Compilacin Prueba Total Actual 2 0 53 20 25 20 240 Actual 0 0 10 0 0 Fecha: _09/10/06__ Programa #: _1A Lenguaje: ___C____ Actual A la Fecha 2 0 53 20 25 20 120 A la Fecha 0 0 10 0 0 10 A la Fecha% 1.6 0 44.2 16.7 20.8 16.7 120 A la Fecha% 0 0 100 0 0 10
100.0
100
Defectos Removidos Planeacin Diseo Codificacin Compilacin Prueba Total Despus del Desarrollo
Actual 0 0 3 5 2
0
A la Fecha 0 0 3 5 2 10 0
A la Fecha % 0 0 30 50 20 10 100 0
Resumen del Plan

Encabezado
Nombre, fecha, programa, instructor, lenguaje.
Tamao del Programa

Plan :Indica tu mejor estimacin del tiempo total que tendr el desarrollo. Actual :Indica el tiempo actual en minutos gastado en cada fase.
Resumen del Plan

Tiempo
A la fecha: Indica el tiempo total gastado en cada fase hasta hoy. Para programa 1A, es el tiempo gastado en el programa 1A. A la fecha % :Indica el porcentaje del total tiempo hasta hoy que se gasto en cada fase.
Defectos introducidos y removidos:

Indicar el nmero actual de defectos inyectados y eliminados en cada fase.
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: ____________________ Instructor:______________________ Fecha Inicio Fin Tiempo Tiempo de Delta Interrupci n Fecha: __________ Programa #: ______ Fase Comenta rios

Encabezado
Indicar nombre, fecha, instructor y nmero de programa.
Fecha
Indicar la fecha actual.
Inicio
Indicar el tiempo en minutos cuando empiezas una fase del proyecto.

Fin
Indicar el tiempo en minutos cuando tu paraste tu trabajo en una fase del proyecto, aun cuando tu no has terminado esa fase.
Tiempo de interrupcin
Indicar el tiempo perdido por interrupciones desde el periodo de arranque a parada.
Tiempo Delta time

Indicar el tiempo transcurrido desde el inicio al tiempo de parada descontado el tiempo de interrupcin.

Fase
Anotar la fase en la que estas trabajando. Use el nombre de cada fase.
Comentarios
Descripcin de la interrupcin La tarea que estas haciendo Cualquier aspecto significativo que afecte a tu trabajo
Por ejemplo
Fecha 9/9 Inicio 9:00 12:40 2:45 6:25 10/9 11/9 11:06 9:00 1:15 4:18 12/9 6:42 Fin 9:50 1:18 3:53 7:45 12:19 9:50 2:35 5:11 9:04 3+8 25 10+6+12 6+5 10 Tiempo de Interrupcin Tiempo Delta 50 38 58 80 62 50 69 28 114 Actividad Planeacin Diseo Diseo Codificaci n Codificaci n Codificaci n Compilaci n Prueba Prueba Consulta de un libro Reunin con mi jefe Telfono, Bao, Telfono Bao, tom caf Telfono Comentarios
13/9
9:00
12:33
9:50
1:16
50
38
Prueba
Postmortem
Manejo de Interrupciones
Uno de los problemas que se presenta a la hora de gestionar el tiempo son las interrupciones. Es muy normal que nos interrumpan por llamadas de telfono, gente que viene a hablar con nosotros, o tenemos que parar porque necesitan nuestra ayuda. Cuando se producen estos casos se almacena este tiempo en el Registro de Almacenamiento de Tiempo anotndolo en la columna Tiempo de Interrupcin. Durante este periodo no solo se anota el tiempo de la interrupcin sino tambin porqu se ha producido en la columna de Comentarios.
Manejo de Interrupciones
Puesto que el tiempo de interrupcin no es un tiempo productivo para el trabajo, se debe llevar un registro de las interrupciones. El tiempo de las interrupciones suele ser variable, por lo tanto si no se mide, se debera aadir un nmero aleatorio para todos los datos de tiempo. Estos datos de tiempo pueden ser tiles para comprender mejor como es interrumpido el trabajo, ya que las interrupciones no solo gastan tiempo, sino que rompen la forma de trabajo y pueden provocar que se produzcan errores. Conocer como son las interrupciones podra ayudar a realizar un trabajo ms eficaz y de ms calidad.
Tamao
El tiempo en desarrollar un producto se encuentra altamente determinado por el tamao del mismo. En PSP, los desarrolladores primero estiman el tamao de los productos que planean desarrollar. Luego, al finalizar el producto, se mide el tamao real obtenido. Esta informacin permite a los desarrolladores realizar a futuro una estimacin de tamaos ms precisa. Sin embargo, para que esta informacin sea til, el tamao de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP, el tamao se mide en Lneas de Cdigo (LOC). Para realizar un seguimiento de la variacin del tamao de un programa durante el desarrollo, se deben considerar varias categoras de LOC.
Tamao
Estas son: Base (son los LOC iniciales del producto original) Agregadas (es el cdigo agregado a un programa base existente) Modificadas (es el cdigo base que es modificado en un programa existente) Eliminadas (es el cdigo base que es eliminado de un programa existente) Reutilizacin (es el cdigo tomado de una librera u utilizado, sin realizar ninguna modificacin, en un nuevo programa) Nueva Reutilizacin (esta medida cuenta los LOC que se agregan a una librera) Total (es tamao total del programa, independientemente del cdigo fuente).
Tamao
Luego, para medir el tamao total de un producto, el clculo es el siguiente: Total LOC = Base Eliminadas + Agregadas + Reutilizacin Las LOC modificadas y de nueva reutilizacin no son incluidas en el total; esto se debe a que las LOC modificadas pueden representarse por LOC eliminadas y agregadas, y las LOC de nuevo reutilizacin ya se encuentran contabilizadas en las LOC agregadas.
Estndar tipo de Defectos

El estndar de tipos de defectos proporciona un conjunto general de categoras de defectos. Aunque tu puedes reemplazar este estndar por el tuyo propio, es deseable que te manejes con estas definiciones simples de tipos hasta que tengas datos que te puedan guiar en las modificaciones.
Estndar tipo de Defectos
Log Registro Defectos

Nombre: _______________________________ Instructor: ______________________________
Fecha Nmero Tipo Introducir 10/10/06 1 40 CDIGO Descripcin: Agregar una variable a la estructura Fecha Nmero Tipo 10/10/06 2 20 Descripcin: Variable multidefinida Introducir CDIGO Remover CODIGO Tiempo de Arreglo 11
Fecha: ___ Programa :__

Defecto Arreglado
Remover CODIGO
Tiempo de Arreglo 1
Defecto Arreglado
Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo 10/10/06 3 w0 CDIGO COMPILAR 1 Descripcin: Las comillas de la instruccin de impresin no existen
Fecha Nmero Tipo Introducir Remover Tiempo de Arreglo 10/10/06 4 10 CDIGO PRUEBA 39 Descripcin: Alinear y agregar instrucciones de impresin , mejorar la apariencia
Defecto Arreglado
Defecto Arreglado

Encabezado
Indicar el nombre, fecha, instructor, y numero de programa.
Fecha
Indicar la fecha cuando encontraste y corregiste el defecto.
Nmero
Indicar un nmero nico para este defecto. Comienza cada proyecto con 1.

Tipo
Indicar el tipo de defecto a partir del estndar de tipos de defectos.
Introducido
Indicar la fase donde tu juzgas que el defecto fue inyectado o introducido.
Eliminado
Indicar la fase en la que encontraste y eliminaste el defecto.

Tiempo de Arreglo
Indicar el tiempo que tomaste para corregir el defecto. Tu puedes dar el tiempo exacto o usar tu mejor estimacin. Si este defecto fue inyectado durante la correccin de otro defecto, indicar el nmero de ese defecto o una X si lo desconoces. Un defecto es cualquier cosa en el programa que debe ser cambiado para que sea desarrollado, mejorado o utilizado de manera adecuada.
Defecto Arreglado
Nota

Finalmente, la manera ms eficaz de encontrar y arreglar defectos es repasando el cdigo fuente del programa personalmente. Mientras esto puede parecer como una manera difcil de limpiar un programa defectuoso, resulta ser ms rpido y ms eficaz. Un mtodo para realizar revisiones de cdigo es la utilizacin de guas en las que se determina cuales son los defectos que mas frecuentemente se inyectan.
Mediciones de Tiempo
Los desarrolladores utilizan el log de registro de tiempo para medir el tiempo que dedican a cada fase del proceso. En este log se anota la hora en que empezaron a trabajar en una tarea, la hora en que terminaron una tarea, y cualquier hora en que efectuaron una interrupcin y/o retomaron una tarea. Por ejemplo, una interrupcin podra ser una llamada telefnica, un descanso, o alguien interrumpiendo para hacer una pregunta. Tomando estos tiempos en forma precisa, los desarrolladores pueden conocer el esfuerzo que realmente se dedica a las tareas del proyecto. Debido a que los tiempos de interrupciones son esencialmente al azar, ignorar estos tiempos sera introducir un error de gran tamao en la informacin de tiempos que reducira la exactitud de las estimaciones.
Administracin del Tiempo

Para la llevar a cabo una buena gestin del tiempo se pueden tener en cuenta los siguientes puntos: Tener en cuenta que normalmente el tiempo se gasta de la misma forma. Se debe realizar un seguimiento la forma en la que se gasta el tiempo. Para chequear con exactitud las estimaciones del tiempo y la planificacin, se debe documentar y ms tarde compralo con lo que actualmente se hace. Para hacer planes ms exactos, se deben determinar los planes previos errneos y que deberamos hacer mejor. Planificar el tiempo y seguir un plan. Todo esto se puede resumir mejor diciendo que la mejor forma de gestionar el tiempo es comprender como empleamos el tiempo y esto exige que sepamos catalogar las actividades, registrar el tiempo empleado en cada actividad y almacenar estos datos en un lugar conveniente.
Seguimiento del Tiempo

Una vez que sabemos gestionar el tiempo, es necesario almacenar todos estos datos de alguna forma mediante un formulario. Es importante resaltar que utilizar como unidad de medida la hora no nos proporciona detalles para manejar o planificar el trabajo, es mucho ms fcil en minutos.
Conclusiones
Conociendo los principios y las caractersticas de la metodologa de PSP, conformada por los procesos de planificacin, estimacin de tamao y esfuerzo, recoleccin de datos, manejo de calidad y especificaciones de diseo, se plantea la posibilidad de incorporar esta metodologa al contexto de una empresa pequea, o grupo de desarrollo de software pequeo analizando los factores operativos, econmicos y los riesgos a los que se expone Una vez implementada esta metodologa en el ambiente de trabajo, un siguiente paso consiste en enfocarse en la mejora de la eficiencia y de la dinmica de trabajo a nivel de equipos de desarrollo, mediante el mtodo conocido como TSP (Team Software Process).

PSP Métricas y Procesos para Calidad en Desarrollo de Software

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PSP Métricas y Procesos para Calidad en Desarrollo de Software

Încărcat de

Drepturi de autor:

Formate disponibile

UNIDAD II Mtricas y Procesos PSP

Personal Software Process

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

I. Introduccin al Personal Software Process (PSP)

Calidad en el Desarrollo de Software

I. Introduccin al Personal Software Process (PSP)

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Cmo fue desarrollado PSP?

Calidad en el Desarrollo de Software

Cmo fue desarrollado PSP?

Calidad en el Desarrollo de Software

Cmo fue desarrollado PSP?

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

I.I.Principios del PSP

Calidad en el Desarrollo de Software

I.I.Principios del PSP

Calidad en el Desarrollo de Software

I.I.Principios del PSP

Calidad en el Desarrollo de Software

I.I. Principios del PSP

Calidad en el Desarrollo de Software

I.I. Principios del PSP

Calidad en el Desarrollo de Software

I.I. Principios del PSP

II. Estructura del PSP

Calidad en el Desarrollo de Software

II. Estructura del PSP

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Flujo del Proceso

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Elementos del Proceso

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Evolucin del PSP

Proceso Personal Cclico

Calidad en el Desarrollo de Software

Visin General de PSP

Calidad en el Desarrollo de Software

II.I. Los 7 Pasos de PSP

Proceso de Planeacin Personal

PSP 1 Estimacin de tamao Reporte de pruebas

Proceso de Medicin Personal

Calidad en el Desarrollo de Software

Proporciona un informe resumen.

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

II.I.I. PSP 0.1

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Calidad en el Desarrollo de Software

Fecha: _ Programa :