Fase # Propósito Guiar el análisis y la escritura del reporte final de PSP.

Transcripción

1 Guión de Proceso para el Reporte Final de PSP Instructor: Luis Castro Alumno: Ernesto Pavel Rosales Camacho M: Fase # Propósito Guiar el análisis y la escritura del reporte final de PSP. Criterio de Entrada Todos los programas PSP finalizados. Todas las tareas de reportes previos finalizadas. Bitácora de registro de tiempo y forma del resumen del reporte final PSP. 1 Planeación Estimar el tamaño del reporte: Número de párrafos de análisis. Número de tablas de datos / gráficas a crear. Estimar el esfuerzo basándose en el tamaño del reporte. Registrar los estimados en la Forma de Resumen del Plan. Registrar el tiempo de planeación en la bitácora de tiempo. 2 Desarrollo Para cada punto del análisis: o Generar la gráfica o tabla de datos para análisis. o Analizar la gráfica/tabla y otros datos del proceso. o Escribir el párrafo del análisis. Registrar el tiempo de desarrollo de reporte final de PSP en la bitácora de tiempo. 3 Post Mortem Medir el Tamaño del reporte: o Número de gráficas/tablas. o Número de párrafos de análisis. Completar la forma de Resumen del Plan. Registrar el tiempo del post mortem en la bitácora de tiempo. Criterio de Salida Reporte Final de PSP finalizado. Resumen del Plan finalizado. Bitácora de tiempo finalizada.

2 Resumen del Plan del Reporte Final de PSP Estudiante Ernesto Pavel Rosales Camacho Instructor Luis Castro Fecha 20 sep. 10 Datos de Tamaño Estimado de Esfuerzo Objeto Número Número Esf. Estim. Esfuerzo Planeado Real por Objeto Estimado Párrafos Gráficas Tablas Total 250 Datos de Esfuerzo Fase Tiempo Plan Tiempo Real PLAN DES PM Total

3 Bitácora de Registro de Tiempo Estudiante: Pavel Rosales Fecha: 20 sep. 10 Fecha Inicio Alto Tiempo de Interrupció n 20 11:32 sep.10 am 29 sep. 10:03 10:59 10 pm pm 30 sep. 9:33 10:46 10 pm pm 2 oct. 10:00 12:30 10 pm am 21 ene. 6:00 7: ene. 11 pm 7:46 pm Tiempo Delta Fase Comentarios 12: PLA Fin Planeación N DES Llamada por teléfono pm 8:01 pm 7 66 DES Llamada por teléfono DES Llamada por teléfono DES Instalación software 0 15 PM

4 Preguntas de análisis del reporte: Análisis de la exactitud de la estimación del tamaño Compare el reporte intermedio línea base para la exactitud de estimación de tamaño con los programas posteriores al reporte. Cuánto cambió su exactitud de estimación de tamaño? Por qué? Programa Error R: Se observa que a partir del programa 5 el error de estimación de tamaño nunca pasó de un 70%, en programa #7 presenta un error del 55%, omitiendo este dato se observa una tendencia lineal lo cual es lo deseable. El motivo de esto es que se utilizaron los métodos de cálculo probe para estimar el tamaño usando los datos históricos previos.

5 Qué tan frecuentemente estuvo mi tamaño real del programa dentro de mi intervalo estadístico de predicción del 70%? R: Siempre se estuvo dentro del intervalo de predicción. Tengo una tendencia a agregar/no considerar objetos completos? R: Si, el tamaño de los programas #6, #7 y #8 están por encima de lo estimado, el número 7, tiene un error de 55%, es decir la mitad del tamaño no fue considerado, el número 6 tiene un 27% por encima, es decir, casi un tercio del programa sobrepasa la estimación. Tengo una tendencia a juzgar equivocadamente el tamaño relativo de objetos? R: Si, generalmente subestimo el tamaño de mis objetos, en particular los de cálculo. Necesito calcular el rango de tamaño relativo usando mis datos de objeto históricos? Puedo? R: Si, en general los objetos mantienen una tendencia, si se puede predecir usando las mismas herramientas estadísticas. Basado en mis datos históricos de exactitud de estimación de tamaño, cuál es una meta de estimación de tamaño realista para mí? R: Una meta realista para mi es estar en un 15% de error. Cómo puedo modificar mi proceso para cumplir esa meta? R: Debemos planear el tamaño de los objetos en el mismo tiempo, pero pensando a detalle cuántos métodos se necesitan por clase y así realizar un estimado más exacto.

6 Análisis de la exactitud de estimación del tiempo Compare el reporte intermedio línea base para la exactitud de estimación de tiempo con los programas posteriores al reporte. Cuánto cambió su exactitud de estimación de tiempo? Por qué? Programa Error de estimación de tiempo R: A partir del programa #5 se observan puntos más agrupados, esto es por los históricos que se ocupan para estimar el tiempo. Sin embargo todavía existen variaciones importantes.

7 Qué tan frecuentemente estuvo mi tiempo de desarrollo real dentro de mi intervalo estadístico de predicción del 70%? R: El programa 2 tuvo un error de 103%, lo cual significa que el programa tuvo el doble de tamaño de lo estimado, todos los demás estuvieron dentro del intervalo de error. Mi productividad es estable? Por qué si o por qué no? Programa Productividad R: No es estable se observa un incremento abrupto en el programa #4 y luego decae a unidades por hora para el programa #5, sólo se observa estabilidad en el programa #7 y #8, donde se ubica alrededor de 48 unidades por hora. Esto es por la complejidad de los problemas a resolver en los programas.

8 Cómo puedo estabilizar mi productividad? R: Se estabilizó hasta que se utilizó el PSP 2.1, siempre que se haga una administración de calidad adecuada podremos obtener este nivel de productividad. Es importante realizar las revisiones de diseño y de código dedicándole el tiempo necesario. Cuánto están mis estimados de tiempo afectados por la exactitud de mis estimados de tamaño? ( La regresión lineal me ayudaría?) Programa Error de Tiempo Error de tamaño R: Pues no se observa alguna relación, entre el error de tiempo y el error de tamaño, pero existe una relación lineal con el tiempo real y con los defectos. Tiempo real Tiempo real Programa Error de tamaño Tiempo real

9 Aquí graficamos el error de estimación de tamaño vs el tiempo de desarrollo de las tareas se observa que si hay una tendencia lineal, es decir el tiempo de desarrollo real es linealmente dependiente del error en la estimación de tamaño. Basado en mis datos históricos de exactitud de estimación de tiempo, cuál es una meta de estimación de tiempo realista para mí? R: Una estimación realista sería estar dentro de un intervalo de error del 20%. Cómo puedo modificar mi proceso para cumplir esa meta? Error de estimación de tiempo Error de estimación de tiempo Programa Densidad defectos compilación y pruebas Error de estimación de tiempo R: Observemos que existe una tendencia a aumentar el error de estimación de tiempo conforme la densidad de defectos aumenta, así una forma de estar en un rango de +-20% de error en la estimación de tiempo sería mantener una densidad de defectos baja. Es decir cometer el menor número de defectos apegados al Proceso de Software Personal.

10 Análisis de defectos de rendimiento Qué tipo de defectos introduzco durante el diseño y la codificación? R: Se observa que introduzco defectos de los tipos: 10, 20, 40, 50, 80 y 100 en fase de diseño. En fase de codificación introduzco defectos de los tipos: 20, 40, 50, 60, Diseño Codificación

11 Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados en las revisiones, compilaciones y pruebas? En compilación y pruebas se va reduciendo la densidad de defectos conforme se fue haciendo más robusto el PSP, es decir una vez que se implementaron las revisiones la densidad decreció notablemente.

12 La densidad de defectos fue significativa en las revisiones en los programas #5, #6 y #8, el #7 casi no tiene densidad ya que no se encontraron defectos en las fases de revisión.

13 Qué tendencias son aparentes en los defectos totales por unidad de tamaño? R: Varía durante las diferentes tareas, sin embargo al final se mantiene en un rango entre 32 y 40 defectos por unidades de tamaño, que es el 25% de la densidad que se tenía al principio, es decir 140 defectos por unidad de tamaño. Se observa que se redujo en un 75% los defectos totales por unidad des tamaño. Cómo mis tasas de eliminación de defectos (defectos eliminados/hora) se comparan para la revisión de diseño, revisión de código, compilación y pruebas? R: La eficiencia mayor la muestra la etapa de compilación con 14.9 defectos por hora, esto es porque el compilador encuentra mucho más rápido los errores que el programador, sin embargo si comparamos los valores actuales, la eficiencia es mayor de lo planeado para las revisiones, en pruebas es 2.9 que es menor de lo planeado 4.3, pero no es un valor despreciable.

14 Cuáles son mis tasas de revisión (tamaño revisado/hora) para la revisión de diseño y revisión de código? Size Units Reviewed per Hour Programa DLDR CRR Ambos R: Se observa que se incremento la velocidad de revisión por unidad de tamaño respecto a los programas 5 y 6, en el programa 8 decrece la velocidad ya que el proceso de revisión se hizo más detallado para captar más errores.

15 Cuáles son mis influencias de eliminación de defectos para la revisión de diseño, revisión de código y compilación contra las pruebas unitarias? R: La eficiencia para remover errores de la fase de pruebas unitarias nos sirve para tener un parámetro de eficiencia de las demás fases, es claro que la fase de compilación siempre será la más eficiente ya que la computadora nos ayuda a depurar los defectos muy rápido. Se observa que se tenía planeado alcanzar una velocidad de 4.3 en la fase de pruebas unitarias, la cual se superó en el último programa con 5.0, el cociente nos indica la influencia de las revisiones y compilación en la fase de pruebas. Las influencias actuales son 1.1, 1.8, 5.1 para la revisión de diseño, revisión de código y compilación respectivamente. Las planeadas son 0.3, 0.8 y 3.0 respectivamente.

16 Hay alguna relación entre el rendimiento y la tasa de revisión (tamaño revisado/hora) para las revisiones de diseño y código? Gráfica de rendimiento en la remoción de defectos y gráfica de tamaño revisado por hora: Relación entre rendimiento y tamaño revisado por hora: R: El rendimiento depende tanto del tiempo en el que se revisan las líneas de código como de la cantidad, si vamos a una velocidad lenta de revisión tanto al acelerar la revisión baja el rendimiento, es recomendable conservar una velocidad entre 150 y 200 unidades por hora.

17 Hay una relación entre el rendimiento y A/FR para los programas 5 al 8? Gráfica del A/FR: A/FR Program ID Rendimiento: Yield Program ID

18 Rendimiento vs A/FR R: Claramente se ve una relación lineal entre el rendimiento y el A/FR, esto significa que el rendimiento en la remoción de defectos está directamente relacionado con el A/FR, es decir si se invierte más del doble de tiempo en la revisión de diseño y de código respecto al tiempo de compilación y pruebas el rendimiento es superior llegando a casi el 70% cuando el cociente A/FR alcanza un 3.5. Recordemos que el PSP nos recomienda mantener un A/FR superior a 2.0.

19 Análisis de Calidad Compare el reporte intermedio de base para la calidad en las pruebas unitarias con los programas posteriores al reporte. Cuánto cambió la calidad de los programas entrando a las pruebas unitarias? Por qué? R: Notablemente la densidad de defectos decrece considerablemente en la fase de pruebas, ya que hasta ese punto hemos depurado el código con el proceso. Veamos que la densidad del último programa en pruebas unitarias es del 2.72, lo cual es bastante bajo en comparación de los otros. En promedio podemos entregar 1.1 errores por cada mil líneas de código en la etapa de pruebas unitarias. Cómo puedo juzgar la calidad de mi producto final de manera temprana en mi ciclo de desarrollo? R: Con la densidad de defectos en una etapa temprana podemos proyectar y estimar la densidad de defectos al final del desarrollo.

20 Estoy encontrando mis defectos en las revisiones de diseño y código? Por qué si o por qué no? R: Sí, pero no todos los defectos, yo creo que el proceso ataca los errores comunes en una etapa temprana, pero es difícil encontrar todos los defectos cuando son muchas las líneas de código. Cómo puedo hacer más efectivo y eficiente mi proceso? R: Mejorando las listas de verificación e incrementando al doble el tiempo de revisión revisiones después de cada etapa. Basado en mis datos históricos, cuáles son algunas metas de calidad realistas para mí? R: Basado en los totales podemos asegurar una meta de calidad basada en los promedios, por ejemplo podemos esperar de forma realista en un artefacto que no sobrepase los 70 defectos por cada mil líneas de código, además podemos asegurar una densidad de defectos no mayor a 40 defectos por cada mil líneas de código en la etapa de compilación y al final podemos entregar un artefacto con no más de 12 defectos por cada 100 líneas de código en la etapa de pruebas unitarias. Cómo puedo cambiar mi proceso para cumplir esas metas? R: Apegándose al proceso rigurosamente, dedicando en las revisiones el doble de tiempo y mejorando las listas de verificación después de cada artefacto, poniendo énfasis en los errores más comunes a la hora de revisar.