INGENIERIA DE SOFTWARE

Presentación del tema: "INGENIERIA DE SOFTWARE"— Transcripción de la presentación:

1 INGENIERIA DE SOFTWARE
Personal Software Process (PSP)

2 Niveles Organizacionales
Modelos y Procesos Niveles Organizacionales Organización CMM Equipos TSP Personas PSP

3 ¿Que es PSP? Un PSP es un proceso personal para desarrollar software.
pasos definidos formularios Estándares Un PSP es un marco de trabajo de medición y análisis que te ayuda a caracterizar tu proceso. Es también un procedimiento definido para ayudarte a mejorar tu rendimiento.

4 Principios de 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

5 Principios de PSP Como todo profesional de 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.

6 Principios de PSP 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.

7 Principios de PSP • 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.

8 Principios de 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.

9 Principios de PSP 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.

10 Principios de PSP 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.

11 Principios de PSP 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.

12 Estructura de PSP Objetivo: Conocer las métricas de PSP.
Identificar los objetivos de cada nivel de PSP.

13 Introducción al PSP 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.

14 Introducción al PSP 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

15 Introducción al PSP 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 prerrequisito para el TSP

16 Introducción al PSP 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.

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

18 Estructura de PSP 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.

19 Flujo del Proceso

20 Elementos del Proceso

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

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

23 Estructura de PSP 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 mientras hacen el trabajo. En otras palabras, PSP es un proceso que está diseñado para ser utilizado.

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

25 Los 7 Pasos de PSP PSP 0 PSP 0.1 Estándar de Codificación
Proceso actual Registro de tiempo Registro de defectos Estándar de tipos de defectos PSP 0.1 Estándar de Codificación Medición de Tamaño Propuesta de mejora del proceso PSP 1 Estimación de tamaño Reporte de pruebas PSP 1.1 Planeación de tareas Planeación de tiempos de actividades PSP 2 Revisión de Código Revisión de Diseño PSP 2.1 Formatos de Diseño PSP 3 Desarrollo Cíclico Proceso de Medición Personal Proceso de Planeación Personal Administración de Calidad Personal Proceso Personal Cíclico

26 PSP0 Punto de Partida de PSP
PSP0 es un proceso sencillo, definido y personal. Utiliza tus métodos actuales de diseño y desarrollo. Recoge datos sobre tu trabajo: tiempo gastado por fase defectos encontrados en compilación y pruebas Proporciona un informe resumen.

27 PSP0 Punto de Partida de PSP
El paso inicial en PSP consiste en establecer una base que incluya mediciones y un formato de reportes. Esto permite medir el progreso y define los cimientos para mejorar. Esencialmente, PSP0 es el proceso habitual con el que los desarrolladores escriben software, mejorado para proveer mediciones.

28 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) (Propuesta de Mejora de Procesos). 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.

29 PSP 1 y PSP 1.1PSP1 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.

30 PSP 1 y PSP 1.1PSP1 Planeación personal
En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. Los desarrolladores aprenden a: Entender la relación entre el tamaño de los programas que escriben y el tiempo que les toma desarrollarlos. Realizar compromisos que puedan cumplir. Preparar un plan ordenado para realizar su trabajo Establecer una base para realizar un seguimiento de su trabajo.

31 PSP 2 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.

32 PSP 2.1 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.

33 PSP 3 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.

34 PSP 3 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.

35 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

36 Planeación en 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.

37 Planeación en PSP 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;

38 Planeación en PSP 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).

39 Planeación en PSP

40 Planeación en 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.

41 Planeación en PSP 6. 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. 7. 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.

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

43 Planeación PSP 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.

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

45 Recolección de Datos 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).

46 Recolección de Datos 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.

47 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 costo de los fallos (COQ) Valoración del rango de fallos

48 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

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

50 Guión del Proceso Planificación Desarrollo Post-mortem
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.

51 Guión del Proceso Diseño Codificación Compilación
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.

52 Guión del Proceso 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.

53 Primera Aproximación a PSP
7 pasos y 4 niveles de mejoramiento PSP0 + PSP0.1 Métrica y estandarización PSP1 + PSP1.1 Mejora la estimación y planificación PSP2 + PSP2.1 Incrementamos calidad PSP 3 Repetición para escalar a grandes desarrollos

54 Resumen del Plan PSP 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 Diseño Codificación Compilación Prueba Postmortem Total Defectos Introducidos Actual A la Fecha A la Fecha% Planeación Codificación Compilación Prueba Total Defectos Removidos Actual A la Fecha A la Fecha % Codificación Compilación Prueba Después del Desarrollo

55 Resumen del Plan Encabezado Tamaño del Programa
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.

56 Resumen del Plan Tiempo Defectos introducidos y removidos:
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.

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

58 Registros de Tiempo PSP
Estudiante: ____________________ Fecha: __________ Instructor:______________________ Programa #: ______ Fecha Inicio Fin Tiempo de Interrupción Tiempo Delta Fase Comentarios

59 Registros de Tiempo Fecha Encabezado Inicio
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.

60 Registros de Tiempo Fin Tiempo de interrupción Tiempo Delta time
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.

61 Registros de Tiempo Fase Comentarios
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

62 Tiempo de Interrupción
Ejemplo Fecha Inicio Fin Tiempo de Interrupción Tiempo Delta Actividad Comentarios 9/9 9:00 9:50 50 Planeación 12:40 1:18 38 Diseño 2:45 3:53 10 58 Teléfono 6:25 7:45 80 Codificación 10/9 11:06 12:19 6+5 62 Baño, tomé café 11/9 1:15 2:35 3+8 69 Compilación Consulta de un libro 4:18 5:11 25 28 Prueba Reunión con mi jefe 12/9 6:42 9:04 114 Teléfono, Baño, Teléfono 13/9 12:33 1:16 Postmortem

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

64 Manejo de Interrupciones
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.

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

66 Manejo de Interrupciones
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.

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

68 Tamaño 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).

69 Tamaño 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.

70 Tamaño Base (son los LOC iniciales del producto original)
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)

71 Tamaño Estas son: 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).

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

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

74 Tipo de Defectos PSP

75 Registro de los Defectos PSP
Nombre: _______________________________ Fecha: ___ Instructor: ______________________________ Programa :__ Fecha Número Tipo Introducir Remover Tiempo de Arreglo Defecto Arreglado 10/10/ CÓDIGO CODIGO 11 Descripción: Agregar una variable a la estructura 10/10/ CÓDIGO CODIGO 1 Descripción: Variable multidefinida 10/10/ CÓDIGO COMPILAR 1 Descripción: Las comillas de la instrucción de impresión no existen “” 10/10/ CÓDIGO PRUEBA 39 Descripción: Alinear y agregar instrucciones de impresión , mejorar la apariencia

76 Registro de los Defectos
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.

77 Registro de los Defectos
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.

78 Registro de los Defectos
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.

79 Registro de los Defectos
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.

80 Guía de Revisión de Código
Propósito Guía para realizar una revisión de código efectiva # 3 Para Fechar Para 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 Inicialización Chequea las variables e inicialización de parámetros. 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 Inicializados a NULL Borrarlos después de crearlos Borrarlos siempre después del uso

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

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

83 Mediciones de Tiempo 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.

84 Mediciones de Tiempo 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.

85 Mediciones de 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.

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

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

88 Métricas del PSP 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

89 Resumen - Métricas del PSP
Nombre: Fecha: 18/10/96 Programa Programa # 13 Profesor Lenguaje: Java 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 Tamaño Máximo 72 Tamaño Mínimo 41

90 Resumen - Métricas del PSP
Tiempo en fase (min.) Plan Actual Para Fecha Para Fecha % Planing ,0 Diseño ,2 Código ,1 Revisión código ,5 Compilación ,2 Test ,2 Post mortem ,8 Total Tiempo Máximo 426 Tiempo Mínimo 243

91 Resumen - Métricas del PSP
Introducción de defectos Plan Actual Para Fecha Para Fecha % Def/Hora Planing Diseño ,0 Código ,0 Revisión código Compilación Test Total ,0

92 PROBE PROxy Based Estimating: Hace uso de patrones de diseño y datos históricos para solucionar los estimados de tiempo y esfuerzo en líneas de código PROXY : Patrón de Diseño