UNIVERSIDAD AUTONOMA METROPOLITANA IZTAPALAPA

DIVISION DE CIENCIAS BASICAS E INGENIERIA

LICENCIATURA EN COMPUTACION

NOMBRE DEL PROYECTO: DESARROLLO DE SISTEMAS UTILIZANDO PSP

NOMBRE DEL ALUMNO: OSCAR CAPITAINE AGGI

MATRICULA:

98317250

NOMBRE DEL ASESOR: ING. LUIS FERNANDO CASTRO CAREAGA

Mxico D.F. MAYO 2007

INTRODUCCION: Las computadoras se han convertido en una herramienta muy importante en la vida del ser humano, es utilizada prcticamente en cualquier rea de trabajo. El desarrollo del ser humano en la actualidad se encuentra ligado al uso de las computadoras. Con ella podemos realizar problemas que anteriormente eran muy difciles de resolver, sin la utilizacin de este equipo. A medida que la tecnologa avanza, nos hemos vuelto a la necesidad de crear nuevas formas en la realizacin de un sistema, para de este modo aumentar la calidad de dicho producto y facilitarnos cada vez la forma en la que se debe realizar. Afortunadamente han sido creadas buenas herramientas y procesos, ya que si se quiere desarrollar un sistema muy grande y no se lleva a cabo un diseo estructural, podramos perdernos en alguno de los mdulos y no saber ha ciencia cierta que es lo que estamos realizando, o interpretar mal lo que el cliente quiere que realice su sistema, esta es una de las razones por lo cual existen proyectos que se cancelan ya que o bien no se llevo un control en el desarrollo del sistema o el cliente no estuvo satisfecho con dicho sistema, por que no cumpla con las especificaciones que se tenan para la finalidad y el uso que se tenia contemplado, a pesar que el sistema probablemente funcionara muy bien. De que forma podemos evitar estos problemas y hacernos la vida ms fcil? Gracias a la ingeniera de software Pero en que consiste? La Ingeniera de software es la rama de la ingeniera que crea y mantiene las aplicaciones de software aplicando tecnologas y prcticas de las ciencias computacionales, manejo de proyectos, ingeniera, el mbito de la aplicacin, y otros campos. Es relativamente nueva ya que surge a finales de las anos 60s. Comienza con una serie de tareas que hacen modelos y que resultan en una especificacin completa de requisitos y una representacin comprensiva de diseo del software que ser construido. Despus de varias pruebas utilizando diversos mtodos, es opto por hacer un estndar a los mtodos Orientados o Objetos (OO).

La ingeniera de software requiere llevar a cabo una serie de tareas, sobre todo las siguientes:

Anlisis de requisitos: Es la primera etapa para crear el programa. El cliente especifica que es lo que quiere que el sistema realice. Especificacin: Es la tarea de describir detalladamente el software a ser escrito. Diseo y arquitectura: Se refiere a determinar como funcionar de forma general sin entrar en detalles. Programacin: Es esta fase se empieza codificar el diseo. Prueba: Se comprueba que el software realice las tareas para el cual fue diseado, se recomienda probar por separado cada mdulo y ver que funciona correctamente. Documentacin: Realizacin del manual de usuario, y posiblemente un manual tcnico con el propsito de mantenimiento futuro y ampliaciones al sistema.

Mantenimiento: Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos.

La ingeniera de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realizacin de software, de los cuales podemos destacar a stos por ser los ms utilizados y los ms completos:

Modelo en cascada Modelo en espiral Modelo de prototipos Mtodo en V

Por lo regular el ms utilizado de estos paradigmas es el modelo de cascada, ya que considero en mi opinin es el mejor de todos de todos. Al hablar de Ingeniera de Software tambin tendremos que hablar de UML, ya que se encuentran estrechamente ligados en el desarrollo de sistemas de alta calidad. UML1 ha emergido como una unificacin de los diversos mtodos orientados a objetos y se est convirtiendo en un estndar. El Lenguaje Unificado de Modelado es ahora el esquema de representacin grfica ms utilizado para modelar sistemas orientados a objetos. Aquellos quienes disean sistemas Utilizan el lenguaje (en forma de diagramas) para modelar sus sistemas. Una de las caractersticas ms atractivas de UML es su flexibilidad. UML es extensible e independiente de los diversos procesos de A/DOO. Los modeladores de UML tienen la libertad de disear sistemas utilizando varios procesos, pero todos los desarrolladores pueden ahora expresar esos diseos con un conjunto de notaciones estndar. Una de las caractersticas de PSP, es que es muy parecido a la ingeniera de software, ya que la mayora de sus fases son muy parecidas, ms adelanta se hablara en que consiste el PSP y cual es su propsito en el desarrollo de sistemas de alta calidad.

1 Modelo unificado del lenguaje (Unified Modeling Language)

INDICE GENERAL OBJETIVOS................1 1. PSP....2 2. DESCRIPCION DEL PROCESO.....5 2.1 PSP 0...5 2.2 PSP 0.15 2.3 PSP 1.. 6 2.4 PSP 1.16 2.5 PSP 2...6

2.6 PSP 2.17 2.7 PSP 3...7

3. TAREAS REALIZADAS DURANTE EL PROCESO PSP8 3.1 TAREA 1A.8 3.2 TAREA 2A....9 3.3 TAREA 3A....9 3.4 TAREA 4A....9 3.5 TAREA 5A..11 3.6 TAREA 6A..13 3.7 TAREA 7A..16 3.8 TAREA 8A..18 3.9 TAREA 9A..18 3.10 TAREA 10A...20 4. FORMAS UTILIZADAS EN PSP...................................................23

4.1 DESCRIPCION GRAL DE FORMAS Y PLANTILLAS....24 4.1.1 FORMAS DEL RESUMEN DEL PLAN DE PROYECTO....24 4.1.2 BITACORA DE REGISTRO DE TIEMPO..24 4.1.3 BITACORA DE REGISTRO DE DEFECTOS..24 4.1.4 ESTANDAR DE TIPO DE EFECTOS....25 4.1.5 PIP..25 4.1.6 ESTNDAR DE CONTEO DE LOC (R1). ..26 4.1.7 ESTNDAR DE CODIFICACIN (R2).26 4.1.8 PLANTILLA DE REPORTE DE PRUEBAS....26

4.1.9 PLANTILLA DE ESTIMACION DE TAMAO (Size Estimate).26 4.1.10 PLANTILLA METODO PROBE27 4.1.11 LISTA DE CHEQUEO DE REVISION DE DISEO.27 4.1.12 LISTA DE CHEQUEO DE REVISON DE CODIGO.27 4.1.13 PLANTILLA DEL ESCENARIO OPERACIONAL..27

4.1.14 PLANTILLA DE ESPECIFICACION DE ESTADOS.28 4.1.15 PLANTILLA DE ESPECIFICACION LOGICA......28

5. PLANTILLA ESTANDAR DE CONTEO DE LOCs (R1).29 6. PLANTILLA ESTANDAR DE CODIFICACION R2 C....30 7. REPORTE DE ANALISIS DE DEFECTOS R3...32 8. REPORTE DE LA PRIMERA PARTE DEL PROCESO R4..33

8.1 RESUMEN DEL PLAN DE PROYECTO R433 8.2 BITACORA DE REGISTRO DE TIEMPO R4.........34 8.3 MUESTRA DE SCRIPT DEL PROCESO DEL REPORTE R4..35 8.4 ANALISIS DE LA EXACTITUD DE ESTIMACION DE LOC..36 8.5 ANALISIS DE LA EXACTITUD DE ESTIMACION DE TIEMPO38 8.6 ANALISIS DE LOS DEFECTOS INTRODUCIDOS Y ELIMINADOS ` POR FASE [Tabla D23]..40 8.7 ANALISIS DE LOS DEFECTOS INTRODUCIDOS Y ELIMINADOS ` [R3]...42 8.8 ANALISIS DE DEFECTOS ENCONTRADOS EN COMPILADOR..43 8.9 AREAS DE MAS ALTA PRIORIDAD PARA MEJORAS EN LA ` SEGUNDA MITAD DEL CURSO...44

8.9.1 PLANEACIN..44 8.9.2 DISEO....45

8.9.3 CODIFICACIN...46 9. REPORTE DE LA SEGUNDA PARTE DEL PROCESO R5..47 9.1 RESUMEN DEL PLAN REPORTE R5....47 9.2 BITACORA DE REGISTRO DE TIEMPO R5.....48 9.3 ANALISIS DE LA EXACTITUD DE ESTIMACION DE LOC..49

9.4 ANALISIS DE LA EXACTITUD DE ESTIMACION DE TIEMPO53 9.5 ANALISIS DE DEFECTOS Y YIELD......57 9.6 PREGUSNTAS SOBRE CALIDAD.62

1

OBJETIVOS:

Aprender a utilizar como se debe medir y analizar el Proceso personal de software (PSP), para aumentar mi desempeo personal, en la realizacin de un sistema.

Aprender a desarrollar un programa mediante fases, trabajando de una manera

ordenada y eficiente individualmente. Conocer el funcionamiento de la metodologa PSP para tener un mejor control en el

desarrollo de un producto de software. Aprender a utilizar cada una de las plantillas que proporciona el PSP para la

realizacin de cada programa. Tener una mejor estimacin en el desarrollo de programas mediante el uso de los

datos histricos que se proporcionan las plantillas. Aumentar la calidad y productividad de un producto mediante la utilizacin de PSP,

para crear un software ms eficiente y con mejor calidad. Reducir errores mediante las revisiones de diseo y cdigo, para disminuir el

tiempo de desarrollo de un programa.

Disminuir los errores en las fases de compilacin y pruebas para disminuir el tiempo de desarrollo de un programa.

Familiarizarse con cada uno de los pasos que sigue el PSP para aplicar esta

metodologa en el desarrollo de programas o sistemas posteriores.

2

1 PSP El PSP es un Proceso Personal para desarrollar Software, principalmente se divide en tres partes que son las siguientes:

Pasos Definidos Formas Estndares

Un PSP es una lnea de trabajo de medicin y anlisis para ayudarle a caracterizar su Proceso. Tambin es un procedimiento definido que le ayuda a mejorar su desempeo, de una manera individual, ya que dicho proceso esta creado para que el alumno se desarrolle productivamente de una forma personalizada. Basadas en prcticas de software industrial reducidas.

Figura 1.1 El flujo del Proceso del PSP

Requerimientos

Producto terminado

Resumen del

Proyecto

Reporte de resumen de Datos del proyecto y del

Proceso

Guiones

gua

Bitcoras

Planeacin

Diseo

Codificacin

Compilacin

Pruebas

PM

3

Como podemos ver en la figura 1.1, PSP sigue una lnea de trabajo estructurada, dividida en una serie de fases, cada una de las fases es consecuencia de la anterior y el flujo solo es hacia una direccin. Durante la fase de planeacin el alumno desarrolla el modelo conceptual, que es la base para la construccin de cada uno de los mtodos de la realizacin del sistema o programa. Al entrar en la fase de Diseo se crean o disean cada uno de los mtodos del programa, en base a la fase de planeacin. nicamente se disea en papel, no se puede utilizar un editor de texto, ya que as esta estipulado el rea de trabajo en la fase de diseo. Durante la fase de compilacin se corrigen todos los errores encontrados en el programa y se apuntan en una plantilla, donde cada defecto o error tiene un tipo especificado. Una vez corregido todos los defectos del programa se procede ha hacer una serie de pruebas, para ver que nuestro programa este funcionando de una forma eficiente, a como se tena contemplado. Por ltimo tenemos el resumen del plan de proyecto, que es otra plantilla donde aparecen los tiempos de desarrollo, el nmero de defectos encontrados, el tamao del programa, una serie de datos, que van aumentando conforme va avanzando el proceso. Durante cada una de las fases se lleva una bitcora, donde se toman los tiempos que se tardo el alumno en la realizacin de cada fase. As como tambin una serie de plantillas. Ms adelante se mencionar el funcionamiento de este tipo de bitcora y plantillas utilizadas durante todo el desarrollo de nuestro programa o sistema. El principal objetivo del PSP es ayudar a los ingenieros de software a realizar mejor su trabajo. Tambin esta diseado para demostrar el valor de utilizar procesos definidos y medidos. Finalmente, el PSP esta pensado para ayudar a los ingenieros y organizaciones a cumplir la fuerte y creciente demanda por los sistemas de software y calidad. Se aplica a tareas personalmente estructuradas. Puede ser extendido para soportar el desarrollo de sistemas de software de gran escala. PSP esta diseado mediante una serie de 10 tareas1, donde en cada uno de ellas se van incorporando nuevas plantillas, lo que hace que el proceso vaya hacindose ms robusto y la documentacin aumente. Las variantes se mencionan a continuacin:

1 Ver seccin 3

4

El PSP se introduce en siete pasos compatibles y progresivos. PSP0: Usted establece una lnea de base de desempeo. PSP1: Usted hace planes sobre tamao, recursos y tiempo. PSP2: Usted practica la administracin de defectos y del rendimiento (yield). PSP3: Usted escala los mtodos de PSP a proyectos ms grandes. La figura 1.2 nos detalla especficamente como estn estructuradas cada una de las variantes del PSP. As como tambin las plantillas que se incorporan en cada una de estas fases. En la seccin 4.1 se detallan especficamente en que consiste cada una de las plantillas y cual es su funcionalidad a lo largo del proceso.

Figura 1.2 Etapas del PSP

PSP3 Desarrollo Cclico

PSP2 Revisiones de CdigoRevisiones de Diseo

PSP2 .1 Diseo de Plantillas

PSP1 Estimacin de Tamao

Reporte de Pruebas

PSP1 .1 Planeacin de Tareas

Planeacin de Calendario

PSP0 Proceso Actual

Registro de Tiempo Registro de Defectos

Estndar de Tipos de Defectos

PSP0 .1 Estndar de Cdigo Medicin de Tamao

Propuesta de Mejora de Procesos (PIP)

Proceso personal cclico

Administracin de Calidad Personal

Proceso de Planeacin Personal

Proceso Personal de Referencia

5

2 DESCRIPCION DEL PROCESO 2.1 PSP 0 El PSP 0 es un proceso simple y definido. Utiliza sus mtodos actuales de diseo y desarrollo. Los objetivos principales del PSP 0 son:

Demostrar el uso de proceso definido al escribir un programa pequeo Incorporar medidas bsicas en el proceso de desarrollo de software Requiere cambios mnimos a las practicas personales

Cuenta con una serie de elementos para facilitarnos la medicin de nuestros avances a lo largo de la tarea 1A, la idea principal durante el PSP0 es incorporando poco a poco al proceso, para familiarizarse de una manera fcil. Para esta primera fase, los elementos necesarios son:

Strip de Proceso Reporte de Plan de Proyecto Bitcora de Registro de Tiempo Bitcora de Registro de Defectos Estndar de Tipo de Defectos

2.2 PSP 0.1 El PSP 0.1 tiene como finalidad medir el tamao del software para relacionar la cantidad de producto generado con el esfuerzo empleado. As como tambin para calcular nuestra productividad (medida en LOCs2), normalizar los defectos. Las tareas 2A y 3A se realizan con este proceso. Los objetivos principales del PSP 0.1 son:

Medir el tamao de los programas que usted produce Contabilizar los tipos de LOCs en los programas que produzca Realizar mediciones de tamao exactas y precisas

Introducimos una nueva serie de elementos al proceso:

La forma de propuesta de mejora del Proceso (PIP) Estndar de Conteo (R1) Estndar de Codificacin (R2)

2 Lneas de Cdigo (Line of code)

6

2.3 PSP 1 El Objetivo de PSP1 es establecer un procedimiento ordenado y repetido para el desarrollo de estimacin de tamao. La tarea 4A es la nica que se realiza durante esta variacin de PSP. Los nuevos elementos introducidos en el PSP1 son:

El mtodo de Estimacin de tamao PROBE La plantilla de Estimacin de tamao La plantilla de reporte de pruebas

2.4 PSP 1.1 Los Objetivos del PSP1.1 son introducir y practicar mtodos para:

Realizar planes de recursos y de calendarios de trabajo Darle seguimiento a su desempeo en cuanto a sus planes Juzgar la probabilidad de las fechas de terminacin del proyecto

Se incorporan nuevos elementos al proceso:

Plantilla de planeacin de tareas Plantilla de planeacin de calendario de trabajo

Por lo regular estas plantillas se utilizan para proyectos que tardan varios das o semanas. No se utilizaran durante las tareas de PSP. El resumen del plan de proyecto se expandi para que incluya estadsticas bsicas del proceso. Las tareas 5A y 6A son las realizadas con estas modificaciones al PSP. 2.5 PSP 2 Los objetivos de PSP2 son introducir:

Las revisiones de diseo y cdigo Mtodos para la evaluacin y mejora de calidad de sus revisiones

Se incorporan dos nuevos elementos al proceso: Lista de comprobacin de la revisin de diseo del PSP2 Lista de comprobacin de la revisin de cdigo

7

2.6 PSP 2.1 Los objetivos del PSP2.1 son introducir.

Introducir mtricas adicionales para la administracin de la calidad Plantillas de diseo que proporcionen una lnea de trabajo ordenado y formatos para

documentar los diseos Existen cuatro nuevos elementos del proceso:

Lista de comprobacin de la revisin de diseo PSP2.1 Plantilla del escenario operacional Plantilla de especificacin de estados Plantilla de especificacin lgica

Las tareas 8A, 9A y 10A se realizan con este proceso. 2.7 PSP 3 El PSP3 (cclico) proporciona una lnea de trabajo para el uso de una estrategia de desarrollo cclico, para desarrollar programas de tamao modesto. Los pasos de requerimientos, planeacin y postmortem del PSP, son realizados una sola vez para el programa total. El diseo de alto nivel particiona el programa en elementos ms pequeos y establece la estrategia de desarrollo que determina los pasos cclicos.

8

3 TAREAS REALIZADAS DURANTE EL PROCESO PSP 3.1 TAREA 1A Requerimientos del Programa 1A

Calcule la media y la desviacin estndar de una serie de n nmeros reales. Su programa debe leer los n nmeros reales de un teclado, un archivo, etc. Utilice una lista ligada para almacenar los n nmeros durante los clculos.

La media es el promedio de n nmeros. La desviacin estndar se calcula de la siguiente manera:

( )1

. 1

2

==

=n

mediDesvEst

n

ixx

donde: es el smbolo para la desviacin estndar es el smbolo para la sumatoria i es un ndice para los n nmeros Xmed es el valor promedio de los n nmeros

Las Listas ligadas son tipos de datos abstractos utilizados para almacenar conjuntos de datos. Las listas ligadas son construidas con apuntadores Una lista ligada por lo regular tiene dos componentes:

Una cabeza de lista El o los nodos de la lista

Algunas de las opciones para la estructura de una lista ligada son: La cabeza de la lista puede apunta al primer nodo, al ltimo

o a ambos. Un nodo de la lista puede apuntar al siguiente nodo, al

anterior o a ambos.

Los apuntadores nulos con frecuencia son utilizados para indicar una lista vaca o el final de la lista Las operaciones tpicas sobre una lista ligada incluyen:

Agregar un nodo Eliminar un nodo Ir al siguiente nodo Ir al nodo anterior

9

3.2 TAREA 2A Requerimientos del Programa 2A

Utilice el PSP0.1 para escribir un programa que cuente el total de LOCs lgicas en un programa omitiendo los comentarios y las lneas en blanco.

Utilice su estndar de conteo (R1) y su estndar de codificacin (R2) para colocar una lnea lgica en cada lnea fsica y cuente las lneas fsicas.

Produzca un conteo nico para el archivo de programa fuente. Prueba completamente el programa. Como una prueba, cuente las LOCs en los

programas 1A y 2A. 3.3 TAREA 3A Requerimientos del Programa 3A Utilice el PSP0.1 para escribir un programa que cuente

El total de LOCs lgicas en un programa El total de LOCs lgicas en un objeto o funcin Para un lenguaje orientado a objetos, el nmero de mtodos en cada objeto

Produzca e imprima

El conteo de LOCs para cada objeto o funcin junto con el nombre del objeto o funcin

Para un lenguaje orientado a objetos, el nmero de mtodos para cada objeto

Un conteo global para el archivo del programa fuente Usted puede adecuar el programa 2A para hacer el programa 3A (sin embargo, mantenga una copia del 2A). Usted puede actualizar su estndar de conteo (R1) y su estndar de codificacin (R2) para simplificar el diseo del programa 3A.

3.4 TAREA 4A Requerimientos del Programa 4A Utilice el PSP1 para escribir un programa que

Calcule los parmetros de regresin 0 y 1 de conjuntos de n datos. Mejore la lista ligada desarrollada en el programa 1A para que almacene los

conjuntos de datos, donde cada conjunto de datos contiene exactamente dos nmeros reales.

10

Calculando los Parmetros de Regresin La frmula para el parmetro de regresin 0 es:

0 = yprom 1 xprom

La frmula para el parmetro de regresin es 1

Pruebe completamente el programa. Como mnimo, use la tabla que se muestra a continuacin para hacer los siguientes casos de prueba:

Utilice los datos de LOC de Objeto Estimadas (xi) y LOC

Nuevas y Modificadas Reales (yi) Utilice los datos de LOC Nuevas y Modificadas Estimadas

(xi) y LOC Nuevas y Modificadas Reales (yi) Tambin, utilizando sus propios datos, calcule los parmetros beta para las LOC nuevas y modificadas estimadas (xi) y las LOC nuevas y modificadas reales (yi) para los programas 2A, 3A y 4A.

Programa LOC de Objeto Est

LOC N y M Est

LOC N y M Reales

1 130 163 186 2 650 765 699 3 99 141 132 4 150 166 272 5 128 137 291 6 302 355 331 7 95 136 199 8 945 1206 1830 9 368 433 788

10 961 1130 1601

( )promprom

n

ipromi

n

iprompromii

xy

xnx

ynxyx

10

1

2

2

11

=

=

=

=

11

3.5 TAREA 5A Requerimientos del Programa 5A Utilice PSP1.1 para escribir un programa que integre numricamente una funcin utilizando la regla de Simpson y escriba la funcin que sea la distribucin normal. El programa debe disearse para integrar utilizando varias funciones que sean proporcionadas. Usted necesitar este programa para calcular los valores de las distintas distribuciones estadsticas que se usan posteriormente en las tareas. Pruebe completamente el programa. Como mnimo, use este programa para calcular los valores de la integral de distribucin normal para tres valores. Prueba Valor Esperado - a 2.5 0.9938 - a 0.2 0.5793 a -1.1 0.1357 Integracin Numrica En principio la integracin numrica trata como si estuviese compuesta por varias reas rectangulares. Entonces suma estas reas para generar el valor de la integral El truco es sumar estas reas de tal forma que se minimice el error.

Integrating a Function

Xx(low) x(high)

Para determinar los lmites de integracin

La mayora de las funciones estadsticas se integran de - a algn valor Todas las funciones estadsticas tienen un rea total de 1.0 cuando se integran de - a +

12

La regla de Simpson para calcular la integral es

++

++++++= )()(4)2(2 )3(4)2(2)(4)(

3)(

highhighhigh

lowlowlowlowx

x xfWxFWxFWxFWxFWxFxFWduuF

high

low

K

donde W es el ancho de los segmentos F es el valor de la funcin para cada valor de x La regla de Simpson en otra forma

( ) ( ) ( ) ( ) ( )

+++++= =

=high

N

ilow

N

ilowlow

x

x

xFiWxFiWxFxFWduuFhigh

low

2

...6,4,2

1

...5,3,124

3

donde N es el nmero de segmentos Con funciones simtricas (las distribuciones normal t), el procedimiento es este.

Si el valor de X es Entonces integre desde Y Positivo 0 a X sume 0.5 a los resultados Negativo 0 a abs(X) reste el resultado de 0.5

La frmula de la distribucin normal es

=x

u duex )2(

1)( 2/2

Inicie con N = 20 y un error aceptable (E) de 1E-07.

13

3.6 TAREA 6A Requerimientos del programa 6A Ahora usando el formato para PSP 1.1 escribimos un programa para calcular los intervalos de prediccin del 70% y del 90% de las LOCs nuevas y modificadas estimadas, dado un conjunto de datos histricos de tamao y un estimado de LOC de objeto.

Usamos la regla de integracin de Simpson del programa 5 para calcular el valor de la distribucin t.

Use una lista ligada para almacenar los datos histricos. Intervalo de prediccin El intervalo de prediccin proporciona un rango de probabilidad alrededor del estimado.

Un intervalo de prediccin de 70% da el rango dentro del cual caern el 70% de los estimados.

No es un pronstico, solo una expectativa. Solo aplica si el estimado se comporta como los datos histricos.

Se calcula a partir de los mismos datos utilizados para calcular los parmetros de regresin. Par calcular el intervalo de prediccin, realizamos los siguientes pasos: 1. Lee los datos histricos xs y ys. 2. Calcule B0 y B1. 3. Lea su estimado Xk. 4. Calcule una proyeccin como Yk = B0 + B1*Xk. 5. Calcule el rango para un intervalo de 70%. 6. Calcule el UPI = Yk + Rango(70%). 7. Calcule el LPI = Yk - Rango(70%). 8. Repita los pasos 5 7 para el rango de 90%. 9. imprima sus resultados. La frmula para el clculo del rango de prediccin es:

14

( ) ( )( )=

++= n

iavgi

avgk

xx

xxn

doftRange

1

2

211,2/

Donde X es el tamao de los datos histricos N es el nmero de puntos de los datos histricos t(/2, dof) doble lados de la distribucin t para n - 2 grados de libertad.

La formula para calcular la desviacin estndar es:

( )=

=

n

iii xygl 1

210

1

Donde X son los datos histricos de tamao estimado de objetos. Y son los datos histricos de tamao nuevo y modificados reales. B y b son los parmetros de regresin lineal de los datos Xs vs. Ys gl es el nmero de los grados de libertad de los datos, el cual es n 2.

Encontrando t70(/2,n -2)

( )( )

dunu

nn

n nnat 2

]1())2(,2/(70

0

2

2/1 )2(1

2)2(*)2(

21(

35.

+

=

Donde

n es el nmero de miembros de x. (x) = (x-1) (x-1), (1) = 1, y (1/2) = 1/2.

La distribucin t La distribucin t

Es parecida a la distribucin normal. Tiene colas muy gruesas. Es usado en estimados de parmetros estadsticos para datos limitados.

15

Calculando el valor de t Para calcular el valor de t(/2, n - 2).

Inicie con un valor de prueba de 1 para el limite superior y calcule el valor de la integral.

Compare el resultado con el valor deseado 1. Si el resultado de la integracin es demasiado grande, tome un lmite superior de

prueba ms grande. 2. Si el resultado de la integracin es demasiado grande, tome un lmite superior ms

pequeo. Haga la integracin de prueba sucesivas hasta que el valor de integracin est dentro de un error aceptable, digamos 0.00001.

Para 70%, integre para tener 0.35 (0.85 0.5). Para 90%, integre para tener 0.45 (0.95 0.5).

Una forma para hacer el clculo es la siguiente:

1. Inicie con un valor de prueba t digamos 1. 2. Haga una integral inicial y pruebe revisar si proporciona el valor apropiado; si no,

continu.

3. Si es muy bajo, sume d = 0.5 al valor de prueba t

4. Si es muy alto, reste d = 0.5 al valor de prueba t. 5. Integre de nuevo y pruebe si el resultado est dentro del error aceptable, si no,

continu.

16

6. Si es muy bajo, ajuste d; sume d al valor de prueba t. 7. Si es muy alto, ajuste d; reste d al valor de prueba t. 8. Repita pasos 5 -7.

Las reglas para ajustar d son las siguientes:

1. En tanto como las pruebas de error del resultado, proporcione el mismo signo del error, deje d sin cambio.

2. Siempre que cambie el signo del error, divida d entre 2. 3.7 TAREA 7A Requerimientos del programa 7A Determine la correlacin y significancia entre las LOC nuevas y modificadas actuales y el tiempo de desarrollo actual; as como la correlacin y significancia entre las LOCs nuevas y modificadas y el tiempo de desarrollo de su histrico de datos personales. Usando la correlacin La correlacin rxy tiene un rango entre +1 y -1.

Cerca de +1 implica una fuerte relacin positiva, cuando x incrementa, y tambin. Cerca de -1 implica una fuerte relacin negativa, cuando x incrementa, y

decrementa. Cerca de 0 implica que no hay relacin.

La correlacin es usada en PSP para juzgar la calidad de la relacin linear entre varios datos de procesos histricos, que son usados para la planeacin. Para nuestro propsito, usamos el valor de relacin rxy cuadrado, o r2.

Si r2 es La relacin es .9 r2 predictiva, usela con mayor confidencia .7 r2< .9 Fuerte y puede ser usada para planeacin .5 r2 < .7 Adeacuada para planeacin, pero usela con cautela r2 < .5 No confiable para procesos de planeacin

17

Calculando la correlacin La formula para calcular el coeficiente de correlacin r es

r x,y( ) =n xiyi

i =1

n xii =1

n yii =1

nn xi

2

i =1

n xii =1

n 2

n yi2

i =1

n yii =1

n 2

donde x y y son los pares de conjunto de datos.

n es el nmero de esos miembros. La prueba de significancia determina la probabilidad que una fuerte correlacin sea posible y si tiene o no significancia prctica. Por ejemplo, un conjunto de solamente dos puntos siempre tendr una r2 = 1 pero su correlacin No significante. Calculando la significancia El procedimiento para calcular la significancia de la correlacin es el siguiente: 1. Calcula t

t = r x, y( ) n 2

1 r x, y( )2 Donde r es la correlacin

2. Encuentra la probabilidad p por integracin numrica de distribucin t para n 2 grados de libertad de - a t. 3. Calcula las colas de distribucin, 2*( 1 - p). El rea de una cola de distribucin 0.05 es considerada una evidencia fuerte de que exista una relacin. El rea de una cola de distribucin 0.2 es considerada una relacin casual.

18

3.8 TAREA 8A Requerimientos del programa 8A Utilice PSP 2.1 para escribir un programa que ordene una lista ligada de n pares de nmeros reales de forma ascendente. Proporcionando la capacidad de ordenar con respecto a cualquier campo numrico. Insercin sort Existen muchos algoritmos para el ordenamiento de datos, pero la insercin sort puede ser la ms simple para ordenar una lista ligada. El algoritmo de insercin sort va encontrando la posicin correcta para un dato o elemento, entonces el elemento dentro de la lista toma su posicin correcta.

1 3 5 8 9 12

7

14 15 16 18 19 22

Se considera que se utilicen dos listas ligadas para la realizacin de la tarea, una lista desordenada y una lista ordenada. 3.9 TAREA 9A Requerimientos del programa 9A Usando PSP2.1, escriba el programa 9A para calcular el grado al cual una cadena de n nmeros reales es normalmente distribuida.

Use la rutina de integracin de Simpsons del programa 5A para calcular los valores de la distribucin X2.

Asuma n > 20 y siempre un mltiplo de 5. (nota, se puede asumir n = 50). Use el programa 8 para ordenar los nmeros de forma ascendente.

Prueba X2 para normalidad La prueba X2 para normalidad determina que tan probable es que un conjunto de datos tenga una distribucin normal. Se hace para comparar la estructura de un conjunto de datos con el de una distribucin normal ideal. Realizamos este dividiendo la distribucin normal en segmentos de igual rea y comparando el actual nmero de puntos del conjunto de datos a probar con el esperado nmero de una distribucin normal ideal.

19

Los pasos de la prueba 2 son los siguientes:

1. Ordena el conjunto de datos de n nmeros reales de forma ascendente.

2. Normalice el conjunto de datos.

Primero, calcule la desviacin estndar , para los datos usando n -1.

( )=

=n

iavgi xxn 1

2

11

Despus, transforme cada xi en zI, donde ( )

avgi

i

xxz

= 3. Divida la distribucin normal entre el mismo nmero de segmentos S, donde

n/S 5 S > 3 S2 n

4. Determine cuantos puntos de la distribucin normal ideal, pueden estar dentro de cada segmento, Ni, Normalmente es n/s, para este caso es 5. 5. Determine cuantos de los datos normalizados caen dentro de cada segmento Ki. 6. Calcule el valor de Q para los segmentos

( )Q

N kN

i i

ii

S

= =

2

1

7. Calcule la probabilidad p para las distribucin X2 para S 1 grados de libertad, para integrar desde 0 a Q.

pdof

u e dudofdof u

Q

= 1

2 22 1 2

02

8. Calcule la cola de distribucin para 1 p. 9. Examine 1 p para interpretar el resultado.

1 p < 0.05 es generalmente considerado suficiente para 1 p > 0.2 es generalmente considerado suficiente par aceptar Valores intermedios indican grados intermedios de

20

3.10 TAREA 10A Requerimientos de programa10A Usando PSP3, realice el programa 10A para calcular, los parmetros de regresin mltiple (B0, B1,B2, B3).

Hacemos un estimado de las entradas previstas por el usuario. Y determine los intervalos de prediccin del 70% y 90% a ser estimados.

Use adems una lista ligada para almacenar los datos y el mtodo de integracin de Simpson del programa 5A para calcular la distribucin t.

Calculando los parmetros de regresin mltiple La regresin mltiple proporciona un camino para estimar los efectos de mltiples variables cuando no es posible separa los datos. A continuacin se muestra en una serie de 13 pasos como podemos calcular la regresin mltiple:

1. Use la siguiente formula de regresin mltiple, para calcular el valor del proyecto: zk = 0 + wk1 + xk2 + yk3

2. Encontrar los parmetros BETA resolviendo el siguiente sistema de ecuaciones

lineales:

0n + 1 wii=1

n + 2 xii=1

n + 3 yii =1

n = zii =1

n0 wi

i =1

n + 1 wi2i =1

n + 2 wixii =1

n + 3 wiyii =1

n = wizii=1

n

0 xii =1

n + 1 wixii =1

n + 2 xi2i=1

n + 3 xiyii=1

n = xizii =1

n

0 yii =1

n + 1 wiyii=1

n + 2 xiyii =1

n + 3 yi2i =1

n = yizii =1

n 3. Cuando calcules el valor de los trminos, obtendrs el siguiente sistema de

ecuaciones lineales:

60 + 4,8631 +8,7612 + 6543 = 7144,8630 + 4,521,8991 + 8,519,9382 + 620,7073 = 667,8328, 7610 + 8,519,9381 + 21, 022, 0912 + 905,9253 = 1,265,4936540 + 620,7071 + 905,9252 +137, 9023 = 100,583

21

4. Diagonalizando por el mtodo de Gauss, se elimina sucesivamente un parmetro a

la vez, dando como resultado:

60 + 4,8631 +8,7612 + 6543 = 71400 + 580,437.51 +1,419,1482 + 90,6403 = 89,13500 + 01 + 4,759,8092 270,6353 = 5,002.33200 + 01 + 02 + 37,073.933 = 9,122.275

5. La solucin para los trminos BETA es:

0 = 6.70131 = 0.07842 = 0.01503 = 0.2461

6. Determine el intervalo de prediccin por solucin del rango con la siguiente

ecuacin:

Range = t / 2,n 4( ) 1 + 1n

+ wk wavg( )2wi wavg( )2 +

xk xavg( )2xi xavg( )2 +

yk yavg( )2yi yavg( )2

7. Calculamos la varianza como sigue:

2 = 1n 4

zi 0 1wi 2xi 3yi( )i =1n 2

8. La desviacin estndar es la siguiente:

= 2 = 513.058 = 22.651

9. Los trminos dentro de la raz cuadrada que determinan el rango son:

Newk Newavg( )2 = wk wavg( )2 = 650 810.5( )2 = 25, 760.25Re usek Re useavg( )2 = xk xavg( )2 = 3,000 1,460.17( )2 = 2,371,076.43Modifyk Modifyavg( )2 = yk yavg( )2 = 155 109( )2 = 2,116

22

10. El valor de la distribucin t, para el intervalo de prediccin del 70% con n = 6 y p =

4 es encontrado bajo la columna del 85% y dos grados de libertad. Y el valor es: 1.386.

11. Evaluamos la raz cuadrada:

Range = 1.386 * 22.651 1 + 1/ 6( )+ 25,760.25580, 437.5

+ 2,371,076.438,229, 571

+ 2,11666,616

= 38.846 12. El estimado final es:

z = 6.71+0.0784*650+0.0150*3,000+0.2461*155 = 140.902 horas

13. El intervalo de prediccin es de: 140.902 +/- 38.84 horas. O lo que es lo mismo:

102.06 horas como mnimo y 179.74 horas como mximo.

.

23

4 FORMAS UTILIZADAS EN PSP Como podemos ver en la tabla 4.1 a medida que se avanza en el PSP, se van aumentando plantillas y formas que tienen como finalidad la de ayudarnos a mejorar nuestro desempeo durante el proceso y la de proveer informacin la cual nos puede servir, para mejorar la calidad de cada una de las tareas, como puede ser aumentar nuestra productividad, disminuir el desarrollo en cada fase del PSP, disminuir el error en la estimacin de tamao o tiempo.

Formas, plantillas y estndares

PSP0 PSP0.1 PSP1 PSP1.1 PSP2 PSP2.1 PSP3

Forma del Resumen del Plan de Proyecto

Ver0 Ver0.1 Ver1 Ver1.1 Ver2 Ver2.1 Ver3

Bitcora de registro de Tiempo

X X X X X X X

Bitcora de Registro de Defectos

X X X X X X X

Estndar de Tipos de Defectos

X X X X X X X

PIP X X X X X X Estndar de Codificacin X X X X X X Estndar de Conteo de LOC X X X X X X Plantilla de Reporte de Pruebas

X X X X X

Plantilla de Estimacin de tamao

X X X X X

Plantilla Mtodo PROBE X X X X X Lista de Chequeo de la Rev. De Diseo

X X X

Lista de Chequeo de la Rev. De Codificacin

X X X

Plantilla del Escenario Operacional

X X

Plantilla de la Especificacin de Estados

X X

Plantilla de Especificacin de Lgica

X X

Tabla 4.1 Formas, plantillas y Bitcoras utilizadas en PSP

24

4.1 DESCRIPCION GENERAL DE FORMAS Y PLANTILLAS 4.1.1 FORMAS DEL RESUMEN DEL PLAN DE PROYECTO La forma del resumen de plan de proyecto proporciona un formato conveniente para registrar las mtricas PSP ms importantes para un proyecto. En esta forma se van registrando datos, como vienen siendo la productividad en LOC/Hora, el tiempo total de desarrollo, el tamao del programa, los defectos encontrados en las distintas fases del proceso, por citar algunos. Los resmenes son nicos para cada fase del PSP, conforme se agregan nuevas mtricas en el proceso PSP1 y PSP2, el resumen de plan de proyecto va evolucionando, de acuerdo a los requerimientos nuevos. Inicialmente es una hoja para el PSP 0 y cuando se llega al PSP 3 consta de dos hojas. 4.1.2 BITACORA DE REGISTRO DE TIEMPO Se introduce desde PSP 0 y se sigue utilizando hasta el PSP 3. Para tener un control del tiempo de las actividades realizadas durante el desarrollo de cada una de las tareas, contamos con la bitcora de registro de tiempo. La finalidad de esta Bitcora es de proporcionarnos exactamente el tiempo que tardamos en la realizacin de cada uno de nuestros proyectos, el tiempo de inicio y el tiempo de terminacin de cada fase en minutos, esta perfectamente diseado para contabilizar los tiempos en cada una de las fases, lo que nos permite ver cual de las fases es la que se tarda ms en realizarse. Otra de las caractersticas de esta bitcora es que, en caso que se presente una interrupcin durante el desarrollo de una fase, podemos hacer una pausa y continuar con el proceso ms tarde, as como realizar una parte de una fase y continuar con ella ms tarde, tambin podemos hacer comentarios acerca de cual fue el motivo de la interrupcin. 4.1.3 BITACORA DE REGISTRO DE DEFECTOS Otra de las Bitcoras utilizadas durante todo el PSP es la bitcora de Registro de Defectos. As como es necesario llevar un control del registro de nuestros tiempos, tambin es necesario llevar un control del registro de nuestros defectos. Cuando hablamos de defectos hablamos de los Errores producidos durante el desarrollo de todo un Proyecto, desde su fase de Planeacin hasta la fase de Pruebas. Tomando un estndar de tipo de defectos proporcionado por el PSP, anotamos en la bitcora los defectos que se vayan encontrando por categoras (tipos), fase en la cual se inyecto el defecto y fase donde fue removido, as como el tiempo que se tardo en resolver el defecto y una descripcin de en que consisti el defecto. Para la primera parte del Proceso los defectos son encontrados en las fases de Compilacin y Pruebas, para la segunda parte del Proceso se introducen 2 nuevas plantillas que son las revisiones de diseo y cdigo.

25

4.1.4 ESTANDAR DE TIPO DE DEFECTOS El estndar de tipos de defectos proporciona una categora general de tipos de defectos, los cuales se van presentando en la realizacin de los programas. Se recomienda preferentemente utilizar el ya definido, hasta que se tengan datos suficientes para realizar los cambios, si la persona cree que es recomendable. Personalmente yo utilice el estndar ya establecido y me dio buenos resultados, ya que no se me hizo muy difcil utilizarlo y ha medida que avanzaba el proceso, me familiarice con los distintos tipos. La tabla 4.2 muestra los distintos tipos de defectos que se pueden presentar durante la realizacin de los programas. Nmero de Tipo

Nombre del Tipo Descripcin

10 Documentacin Comentarios o mensajes 20 Sintaxis Ortografa, puntuacin, tipos, formatos de

instrucciones 30 Componentes o configuracin Administracin de cambios, control de versiones,

bibliotecas 40 Asignacin Declaracin, nombres duplicados, alcance, lmites 50 Internas Llamadas y referencias a procedimientos, E/S,

formatos de usuarios 60 Chequeo de Tipos Mensajes de error, chequeos inadecuados 70 Datos Estructura, contenido 80 Funcin o lgicos Defectos por lgica, apuntadores, ciclos, reexcursin,

clculos, funciones 90 Sistema Configuracin, sincronizacin, memoria 100 Ambiente Problemas de diseo, compilacin, prueba, u otros con

los sistemas de desarrollo

Tabla 4.2 Estndar de Tipo de Defectos 4.1.5 PIP La Forma de Propuesta de Mejora de Proceso(PIP), tiene la finalidad de registrar los problemas que se presentaron, durante la realizacin de cada tarea y proponer propuestas de mejora para las tareas futuras. El PIP se introduce a partir de la tarea 3A (PSP0.1). Podemos poner cualquier sugerencia que se tenga para la mejora del proceso, cualquier tipo de problema que se presento durante la realizacin del programa. As como tambin las observaciones y descubrimientos que se presentaron durante la realizacin del ejercicio, y algunas notas o comentarios, que nos pueden servir ms adelante conforme avanzamos en el proceso, como una mejora personal en la realizacin de las tareas.

26

4.1.6 ESTNDAR DE CONTEO DE LOC (R1) Como queremos medir el tamao del software, tenemos que contar lneas de cdigo (LOCs). Tenemos que crear un tipo estndar para poder contar las lneas. Este estndar se hace en base a que lenguaje se va a utilizar para trabajar en la realizacin de las tareas. En mi caso use Borland C++ (Versin. 3.0). Tenemos que tomar en cuenta como vamos a contar las LOCs, ya sea que estructuras de control vamos a contar, si vamos a contar los comentarios, instrucciones vacas, libreras, mdulos etc. 4.1.7 ESTNDAR DE CODIFICACIN (R2) Esta forma se introduce a partir del PSP 0.1. La finalidad de este estndar es de ver de que manera vamos a realizar cada uno de los mdulos de nuestras tareas. Que se predefina el tipo de encabezado se van a utilizar, la declaracin de variables se realizar de tal manera, descripcin de la funcionalidad de los mdulos, resumen del listado de los mdulos del programa, descripcin de las constante, libreras, etc. 4.1.8 PLANTILLA DE REPORTE DE PRUEBAS Esta plantilla tiene como finalidad la de registrar datos de cada uno de las pruebas de nuestros programas. Ya que cada programa tiene como mnimo un nmero determinado de pruebas a realizar, para ver a funcionalidad del mismo. Se utiliza en la fase de pruebas y en esta plantilla se comparan, que los datos de salida de nuestros programas coincidan con los datos de salida las pruebas a realizarse, en caso de que no coincidan los datos o este funcionando mal nuestro programa, aun se apuntan en la plantilla como una referencia, dicho proceso se realiza hasta que todas las pruebas concuerden con las de muestra. 4.1.9 PLANTILLA DE ESTIMACION DE TAMAO (Size Estimate) Tiene como finalidad de aportar datos histricos para hacer las mediciones de tamao de nuestros programas. De acuerdo a nuestro diseo conceptual, en esta plantilla se apuntan cada uno de los mdulos que va a tener nuestro programa, cual va ha ser el nmero de LOCs de cada uno de los mdulos, el tipo de mtodo que va ha ser. Tambin cuenta con informacin acerca de si vamos a utilizar cdigo reutilizable, si vamos a modificar cdigo o si vamos a construir cdigo nuevo. Esta plantilla se utiliza para la realizacin de cada uno de los programas de PSP. Como lo dije anteriormente tiene como finalidad d estimar el tamao de cada uno de los mdulos, para tener un error menor en cuanto al tamao real de los mdulos.

27

4.1.10 PLANTILLA METODO PROBE La finalidad principal de esta plantilla, es la de hacer la estimacin de tamao y tiempo en la realizacin de cada tarea del proceso. Principalmente se basa en nuestro banco de datos histricos proporcionados, durante el desarrollo de las primeras 3 tareas, al principio como no se cuenta con muchos datos, es un poco difcil estimar bien que tipo de mtodo de Estimacin (A, B, C, D) se va a utilizar. Cuenta con una grafica que se calcula utilizando regresin lineal, donde se muestra la correlacin estimada que existe entre el tiempo estimado Vs el tiempo actual y el tamao estimado Vs el tamao actual. La seleccin del mtodo es en base al mayor nmero de puntos que toquen la pendiente positiva, tanto para tamao como para tiempo. 4.1.11 LISTA DE CHEQUEO DE REVISION DE DISEO Se introduce a partir de la segunda parte del proceso en el PSP 2.0, tiene como finalidad encontrar los defectos introducidos durante la fase de diseo. Por lo general casi todos los errores de tipo lgico, funcional y de sistema son removidos, durante esta fase. Lo ideal es que todos estos tipos de defectos se eliminen durante esta fase, pero suele pasar que alguno se pueda filtrar. Desde mi punto de vista, representa la manera de que la calidad de nuestro producto aumente considerablemente, as como la reduccin de tiempo en la bsqueda de errores. 4.1.12 LISTA DE CHEQUEO DE REVISON DE CODIGO Tiene como finalidad remover todos los defectos de sintaxis, llamadas a procedimientos, declaraciones y chequeo de tipos, inicializacin de variables, pares entre llaves o corchetes, apuntadores y operadores lgicos. Ambas revisiones se llevan a cabo antes de la fase de compilacin, si realizamos una buena etapa de revisin tanto de diseo y cdigo, el nmero de errores en la fase de compilacin puede tender a cero. Lo mismo puede ocurrir en la fase de pruebas, ocasionando una disminucin considerable de tiempo en estas dos fases. 4.1.13 PLANTILLA DEL ESCENARIO OPERACIONAL Es una serie de pasos entre el usuario y el sistema, muy parecido a un diagrama de casos de uso. Cuya finalidad es que el usuario interacte con el sistema o programa, sealando especficamente que debe hacer el usuario y la respuesta que da el sistema. Prcticamente es una manual operacional de la utilizacin correcta del uso del sistema. En dicha plantilla no se menciona nada acerca de los flujos de error que pueden ocurrir, estos se especifican en la plantilla de especificacin de estados.

28

4.1.14 PLANTILLA DE ESPECIFICACION DE ESTADOS Este tipo de plantilla tiene como finalidad, la de representar el diseo de un proyecto de software. Representa el comportamiento de nuestro programa a nivel de una maquina de estados finita. Especifica detalladamente como se relacionan entre si cada uno de los mdulos de nuestro programa, el flujo que toman cada y las transacciones que existen entre los mismos. As como tambin el flujo de error que pueda ocurrir. 4.1.15 PLANTILLA DE ESPECIFICACION LOGICA Nos provee la interaccin que existe dentro de nuestro programa, dicho de otra forma. Tiene como finalidad de detallar especficamente la funcionalidad de cada mdulo, cada objeto y el programa principal de nuestros programas. Cuenta con una notacin definida y adaptable a cualquier tipo de lenguaje de programacin, para poderlo exportar. Dicha plantilla debe ser llenada a mano, ya que todo lo que se escribe en ella es pseudocdigo.

29

5 PLANTILLA ESTANDAR DE CONTEO DE LOCs (R1) Como se mencion en la seccin 4.1.6, esta plantilla tiene como finalidad, contar lneas lgicas de los mtodos o funciones que se desarrollan a lo largo de las tareas. Esta plantilla es personalizada, en caso de que se quiera utilizar un nuevo lenguaje de programacin, debe realizarse una nueva plantilla. No puede se modificada mientras se encuentre realizando el PSP. Nombre/definicin: Capitaine Aggi Oscar Lenguaje: C Autor: Castro Careaga Luis F. Fecha: 24/10/05 Tipo de Conteo

tipo Comentarios

Fsico / Lgico Tipo de Instruccin Incluido Comentarios Ejecutable Si No ejecutable Si Declaraciones Si, nota 1 Directivas del compilador Si Comentarios No En lneas propias No Con el fuente No Encabezados No Lneas en blanco No Aclaraciones Ejemplos / Casos Nulos No continues, no-ops Instrucciones vacas Si ;;, ;s solos, etc. Intanciadores genricos Begin...end Si, nota 3 cuando estn en cdigo ejecutable Begin...end Si, nota 3 cuando estn en cdigo no ejecutable Prueba de condiciones Si Evaluacin de expresiones Si Cuando se use como argumentos de

subprogramas Smbolos End No Cuando terminen instrucciones ejecutables Smbolos End No Cuando terminen declaraciones o cuerpos Then, else, otherwise Si, nota 4 Elseif Si, nota 4 Palabras clave No Divisin de procedimientos, interfaz,

implementacin Etiquetas No Destinos de saltos cuando estn en lneas

separadas Nota 1 Se contara una , o un ; por cada declaracion de

variable o parmetro Nota 2 Contar cada #include, #define por cada # que

aparezca en el codigo Nota 3 Se contara un Begin...End por cada { que

aparezca en el codigo Nota 4 Se contaran 1 linea por cada una de las siguientes

palabras reservadas if, else, do, while, for, switch, case @

30

6 PLANTILLA ESTANDAR DE CODIFICACION R2 C Como mencionamos en la seccin 4.1.7, esta plantilla tiene como finalidad estandarizar cada mtodo o funcin de nuestros programas, nos presenta ejemplos de cmo tenemos que estructurar nuestros programas. La realizamos a partir de la tarea 2A y al igual que el R1, no puede ser modificado a lo largo del PSP. Propsito Guiar el desarrollo de programas Encabezados del Programa

Todos los programas comienzan con un encabezado descriptivo.

Formato del Encabezado /*************************************************** Nombre del programa: lexico.c Autor: Capitaine Aggi Oscar Materia: Proytecto de investigacin 1 Tarea: PSP2A Fecha: **/**/**** Descripcin: Este programa cueta lineas de codigo ****************************************************/

Contenido del Listado Proporciona un resumen del contenido del listado. Ejemplo del Contenido /**********************************************

El archivo contienen los siguientes elementos Funcion_1() Funcion_2() .

.

.

Funcion_n() ***********************************************/ nota: en caso de que sea una solo funcion no se declara el contenido

Instrucciones de Reutilizacin

Describe cmo se usa el programa. Proporciona un formato de declaracin, tipos y valores de parmetros y lmites de parmetros. Proporciona advertencias de valores ilegales, condiciones de sobreflujo u otras condiciones que podran resultar potencialmente en una operacin inadecuada.

Ejemplo /*************************************************** void lee_archivo(char nomarch{})

proposito: Esta funcion regresa el nombre de un archivo *****************************************************/

Identificadores Utilice nombres descriptivos para todas las variables, nombres de funciones, constantes y otros identificadores. Evite las abreviaturas o nombres de variables con un solo carcter.

Ejemplo de identificadores

int tamanio_buffer; //correcto int x; //incorrecto

31

Plantilla de Estndar de Codificacin R2, Continuacin

Comentarios Documente lo suficientemente el cdigo para que el lector pueda comprender

su operacin. Los comentarios deben explicar tanto el propsito como el comportamiento del cdigo. Comente la declaracin de las variables para indicar su propsito.

Buen Comentario /*Se lee una linea de codigo*/ if (carcter=={) ...

Mal Comentario //cuenta un //un operador {

if (carcter=={) Secciones Importantes Las secciones importantes del programa deben estar precedidas por un

bloque de comentarios que describan el procesamiento que se hace en la siguiente seccin.

Ejemplo /*** Esta funcion recibe una lista ligada y calcula la media de una serie de numeros ****/ int media(nodo *lista)

Espacios en blanco Escriba programas con el suficiente espaciamiento tal que sean fciles de leer. Separe cada construccin del programa con al menos un espacio.

Sangras Coloque sangras en cada nivel de bloque con respecto al anterior. Llaves que abren y cierran deben estar en una sola lnea y alineadas una con la otra.

Ejemplo for (cont=0; cont< TAMMAX; cont++) { suma+=cont ; if (suma < CERO) { suma=-suma; } }

Maysculas Todos los defines van en maysculas. Todos los otros identificadores y palabras reservadas van en minsculas. Los mensajes que son salidas al usuario pueden tener mezcla de maysculas y minsculas de tal manera que hagan ms limpia la presentacin al usuario.

Ejemplo de Maysculas #define TAMBUFFER while (cont != TAMBUFFER)

32

7 REPORTE DE ANALISIS DE DEFECTOS R3 Tiene como finalidad registrar la densidad de los tipos de defectos introducidos y encontrados mientras se desarrollan los programas. As como tambin el tiempo que se tarda en remover cada uno de los defectos. Los defectos producidos por KLOCs en cada uno de los programas. Se llena a partir de la bitcora de registro de defectos, tomando el conteo y tiempo de eliminacin de defectos, los cuales se introducen en el diseo y se remueven en la compilacin y pruebas, defectos introducidos en la codificacin y removidos en compilacin y pruebas.

Defect Densities Compile and Test Defects

Program Number

New and Changed LOC Total Defects

Defects per KLOC

Defects found in compile

Compile defects per

KLOCDefects found

in testTest defects per KLOC

1 128 12 94 8 63 4 312 298 16 54 13 44 3 103 121 6 50 4 33 2 174 144 6 42 5 35 1 75 206 5 24 4 19 1 56 330 12 36 9 27 3 97 156 10 64 3 19 3 198 133 8 60 2 15 1 89 220 8 36 2 9 1 5

10 365 7 19 1 3 2 5

Totals 90 0 51 0 21 0

Defect Fix Times

Defects found in compiling

Defects found in testing

Total defects found

Defects Tot. fix time 30 93 123injected in Tot. defects 15 7 22designing Avg. fix time 2 13 6

Defects Tot. fix time 59 41 100injected in Tot. defects 28 6 34

coding Avg. fix time 2 7 3

Total Tot. fix time 89 134 223defects Tot. defects 43 13 56injected Avg. fix time 2 10 4

33

8 REPORTE DE LA PRIMERA PARTE DEL PROCESO R4 Tiene como finalidad evaluar el desempeo del alumno, a lo largo de las primeras seis tareas, se formulan una serie de preguntas en cuanto a estimacin de tamao, estimacin de tiempo, calidad. Evala que tan bien ha funcionado el PSP y cuales son las metas de mejora para la segunda parte del proceso. Cuales los principales errores que se cometen en el proceso y de que forma se pueden corregir.

8.1 Resumen del Plan Reporte R4

Estudiante Capitaine Aggi Oscar Fecha 26/01/2006 Instructor Castro Careaga Luis F.

Datos de Tamao Estimacin de Esfuerzo Objeto Nmero

Planeado Nmero

Real Esf. Est. por

Objeto Esfuerzo

Estimado Parrafos 18 18 5 90 Graficas 16 14 5 80 Tablas 9 6 5 45 Anlisis de Graficas / Tablas

25

20

5

125

Prrafos para el Reporte final

4

9

5

20

Total 360

Datos de Esfuerzo Fase Tiempo Plan. Tiempo Real Planeacin 20 18 Desarrollo 360 227

Post Morten

15 25

Total 395 270

34

8.2 Bitcora de Registro de Tiempo R4

Estudiante: Capitaine Aggi Oscar Fecha: 26/01/2006 Fecha Inicio Alto Tiempo

de Interrupcin

Tiempo Efectivo

Fase Comentarios

1/26/06 12:38 12:48 10 Plan Exitoso 1/26/06 16:05 16:13 8 Plan Exitoso 1/28/06

21:25

22:13

48

Desarrollo

Anlisis de la Exactitud de

Estimacin de LOC

1/29/06

21:44

22:35

51

Desarrollo

Anlisis de la Exactitud de

Estimacin de Tiempo

1/30/06

20:15

20:57

41

Desarrollo

Anlisis de los Defectos

Introducidos y Eliminados por

Fase [D24]

1/31/06

18:37

18:56

19

Desarrollo

Anlisis de Defectos

Introducidos y Eliminados por

Fase [R3] 1/31/06

20:12

20:27

15

Desarrollo

Anlisis de Defectos

Encontrados por el

Compilador 2/02/06

11:37

12:30

53

Desarrollo

reas de ms Alta Prioridad para Mejoras en la Segunda

Mitad del Curso2/02/06 15:39 16:04 25 PostMorten Exitoso

35

8.3 Muestra de Script del Proceso del Reporte R4

Fase # Propsito Para guiar el anlisis y la escritura del Reporte R4

Criterio de Entrada Programas 1A a 6A terminados y revisados por los instructores Copia de los requerimientos del reporte Forma del resumen del reporte y bitcora de registro de tiempo

1 Planeacin Estime el tamao del reporte nmero de prrafos de anlisis Nmero de tablas / grficas de datos a crear Estime el esfuerzo basndose en el tamao del reporte Registre los estimados en la Forma de Resumen del Plan Registre el tiempo de planeacin en la bitcora de tiempo

2 Desarrollo Para cada pregunta de anlisis genere una grfica o tabla de datos analice la tabla / grfica y otros datos del proceso escriba un prrafo de anlisis Revise el desempeo completo Identifique las reas de mejora Defina metas cuantificables Determine qu cambios al proceso son necesarios Escriba un anlisis de mejora de desempeo Registre el tiempo de desarrollo en la bitcora de tiempo

3 Postmortem Mida el tamao del reporte nmero de grficas / tablas nmero de prrafos de anlisis Complete la forma de resumen del plan Registre el tiempo de postmortem en la bitcora de registro de tiempo

Exit Criteria Reporte R4 completo Resumen del Plan completo Bitcora de registro de tiempo completa

36

8.4 Anlisis de la Exactitud de Estimacin de LOC

1. Analice la tendencia en la exactitud de estimacin de tamao en los primeros seis

programas.

Actual Size

0

303

121144

206

330

0 0 0 00

50

100

150

200

250

300

350

1 2 3 4 5 6 7 8 9 10

Program Number

LOC

Size Estimating Error

0

43,6018957

55,1282051

7,85817956

-1,7732236

34,5830992

0 0 0 0

-10

0

10

20

30

40

50

60

1 2 3 4 5 6 7 8 9 10

Program Number%

Como se pueden ver en las graficas, para la mayora de los programas, la estimacin en el tamao ha sido buena, en el caso del programa 5 se puede ver que la grafica 2 muestra un porcentaje negativo, en comparacin a los dems programas, al ser un programa un poco complicado y no tener cdigo BASE, la estimacin fue calculada como en el primer programa, al tanteo, pero a medida que se avanza gracias a la reutilizacin de cdigo y el uso la tabla SIZE ESTIMATE del stuwbk, se puede tener un margen de estimacin de tamao ms exacto. 2. Para cada uno de los programa 4, 5 y 6, cmo se comparan las LOC de objeto

estimadas con las LOC de objeto reales?

comparacion de locs

0

50

100

150

200

250

300

350

4 5 6

num. programa

num

. loc

s

locsestimadaslocs reales

Para el programa 4 , la diferencia fue muy pequea, por que se trataba de un programa pequeo, a pesar que en el programa 5 todo el cdigo fue nuevo, tambin se tuvo una buena aproximacin, el programa 6 no tuvo una buena aproximacin, como podemos ver en la grfica.

37

3. Para cada uno de los programa 4, 5 y 6, si las LOC de objeto estimadas no estn

cercanas las LOC de objeto reales, determine por qu. El mayor problema fue en el programa 6, se tenia suficiente cdigo BASE pero tambin se tuvo que realizar mucho cdigo nuevo, y no se tuvo una buena aproximacin, otra cosa que influyo fue perder el ritmo de trabajo entre el programa 5 y el 6, ocasionando una mala estimacin, como se ve en la grafica anterior, la diferencia es de un 30% aprox. Muy mala en comparacin con los programas anteriores. 4. Basado en el anlisis anterior, cul es la mejor cosa que usted podra hacer para

mejorar su exactitud en la estimacin? Hacer un anlisis detallado del programa que se va ha resolver, cada uno de los puntos importantes, y ver los valores estadsticos de los programas anteriores para tener una mejor aproximacin, de lo que se quiere estimar. La reutilizacin de cdigo tambin influye en que tan buena sea la estimacin, ya que solo se crean algunos mdulos y es mucho ms fcil estimar el tamao. 5. Vaya a la hoja PROBE de su libro de trabajo del estudiante y ponga el selector del

programa para el programa 7. Examine las betas del mtodo A. Son tiles para la estimacin del programa 7? Explique por qu si o por qu no.

PROBE Method A B C D

Size Time Size Time Size Time Size Time Estimate -13 60 4 55 0 0 0

R-Squared 0,93 0,78 0,82 0,78 Beta0 -12,66 60,38 3,53 54,64 0,00 0,00 0,00 0,00 Beta1 1,58 1,79 1,24 1,40 1,26 1,71 1,00 #DIV/0!

Range (70%) 150 333 97 124 UPI 138 393 100 178 LPI 0 0 0 0

Variance 1233,16 6044,32 2102,79 3415,64 Std. Deviation 35,12 77,75 45,86 58,44

No, por que para poder utilizar el mtodo A debemos de tener una correlacin (R^2) mayor a 0.7, una B1 entre 0.7 y 1.3 y una B0 relativamente pequea en comparacin de las LOCs Estimadas. Si vemos la tabla del mtodo PROBE podemos darnos cuenta de que a pesar que la correlacin se encuentra dentro del rango 0.93, la B1 esta fuera del rango 1.58, la B0 tiene un valor negativo lo que ocasionara una productividad negativa y nuestro Estimado tambin es negativo. El mtodo B tiene las mismas condiciones que el mtodo A, si observamos la tabla se tieneR^2=0.82

38

8.5 Anlisis de la Exactitud de Estimacin de Tiempo

1. Analice la tendencia en la exactitud de estimacin de esfuerzo en los seis primeros

programas.

Estimacin de Esfuerzo

-1000

100200300400500

1 2 3 4 5 6

Programas

Min

utos T. Estimado

Tiempo RealError

Vemos que para los primeros dos programas la estimacin se encontraba en un rango, yo considerara que es bueno, la grfica muestra que en programa 6, la estimacin fue muy mala, debido a que no se tuvo un buen ritmo de trabajo y esto provoc que no se siguiera un proceso equitativo, en cada una de las fases. 2. Para los primeros seis programas, qu tan estable fue su productividad?

Productivity

26.572862

63.4455024

41.410780539.500152444.677390245.482389

0 0 0 00

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

Program Number

LOC

/Hou

r

39

Yo considero que mi productividad como muestra la grafica a sido estable, como podemos ver en el programa 3 mi productividad bajo un poco en comparacin con los dems programas, otra cosa que influye en la productividad es el grado de dificultad que tenga cada programa y que tanto cdigo BASE se tenga para reutilizarse, tambin podemos ver que para los programas 5 y 6 al parecer la productividad se mantiene estable. Esto se debe a que conforme se avanza en el PSP uno tiene mejor control en sus programas y posee mayor informacin para el desarrollo de sus programas. 3. Para los primeros seis programas, si la productividad vari, los cambios estn

relacionados con la cantidad de tiempo utilizando en corregir los defectos en las fases de compilacin y pruebas?

% Compile Time

0123456789

10

1 2 3 4 5 6 7 8 9 10

Program Number

%

% Test Time

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10

Program Number

%

En la primer grafica se puede ver que mi fase de compilacin se ha mantenido estable de cierta forma en un rango no mayor al 10% del tiempo requerido para la realizacin del programa, la fase de pruebas a ido disminuyendo de un 27% hasta caer entre el 10% y 5%. La fase de compilacin y pruebas, si influye en que tan buena productividad se tenga, ya que al tener ms errores en estas 2 fases, aumenta el tiempo en el desarrollo del programa y esto ocasiona que la productividad vari. Ya que la productividad depende del nmero de LOCs (N&C) VS Tiempo total de todas la fases. 4. Cmo fue afectada la exactitud de sus estimados de tiempo por la calidad de sus

estimados de tamao?

Size Estimating Error

0

43,6018957

55,1282051

7,85817956

-1,7732236

34,5830992

0 0 0 0

-10

0

10

20

30

40

50

60

1 2 3 4 5 6 7 8 9 10

Program Number

%

Time Estimating Error

7,0432098816,0198135

107,431373

56,864131

-0,2295929

53,3595241

0 0 0 0

-20

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

Program Number

%

40

Estimacin Tamao VS Tiempo

7.04 16.01

107.43

56.86

-0.22

53.35

-50

0

50

100

150

0 43.6 55.12 7.85 -1.77 34.58

%Error Tamao

%Er

ror T

iem

po

Como podemos ver en las grficas, los picos muestran que se tuvieron un error de estimacin de tamao y de estimacin de tiempo muy alto, lo que provoc que la calidad en la exactitud fuera psima para las tareas 3 y 6. En la tercera grafica podemos apreciar que mejor estos errores, podemos notar que las tareas 2 y 5 fueron las que mejor se estimo el Tamao VS Tiempo. La fase de compilacin y pruebas son las que afectan que ocurra esto, probablemente nuestra estimacin en tamao fue mala.

8.6 Anlisis de los Defectos Introducidos y Eliminados por Fase [Tabla D23]

1. Qu tipos de defectos se introducen ms en la fase de diseo?

tipo num. Defectos 20 1 40 13 50 4 80 5

Como se puede ver en la grfica, la mayora de los defectos producidos son los de tipo 40 (Asignacin) y los de tipo 80 (funciones o lgicos). Lo que ocasion que existiesen muchos defectos de tipo 40, fue que en el programa 2, no se definieron bien las variables de tipo buffer para nuestro contador de LOCs y esto ocasion que existiesen demasiados errores de este tipo.

41

2. Qu tipos de defectos se introducen ms en la fase de codificacin?

tipo num. Defectos 20 10 30 2 40 18 80 3

Como se podr ver en la grafica, los errores de asignacin (40), y los errores de sintaxis (20), son los ms predominantes, durante esta fase. Tambin se presentan otros tipos de errores como son los de componentes o configuracin (30) y los errores de funciones y lgicos (80). 3. Qu tipos de defectos se eliminan principalmente en la fase de compilacin?

tipo num. Defectos 20 10 30 2 40 23 50 3 80 2

Todos los defectos de sintaxis (20) son eliminados durante esta fase, en ninguna otra fase se eliminan. Vemos que la mayora de los defectos de asignacin (40), tambin son eliminados durante esta fase, al igual sucede con los de funciones o lgicos (80), los de componentes o configuracin (30). 4. Qu tipos de defectos se eliminan principalmente en la fase de pruebas?

Tipo num.

Defectos 40 6 50 2 80 6

Al parecer durante esta fase, aun se siguen presentando los de funciones o lgicos (80), de asignacin (40), pero en comparacin con la fase de compilacin es mucho menor, ya que en la fase de compilacin, la mayora de ellos son filtrados, y solo un nmero pequeo de ellos se presentan durante la fase de pruebas.

42

8.7 Anlisis de Defectos Introducidos y Eliminados por Fase [R3]

De la hoja R3 de su libro de trabajo del estudiante, imprima el reporte R3. 1. Analice los tiempos de eliminacin de defectos, basndose en la fase en la que los

defectos son introducidos y eliminados.

Defect Fix Times

Defects found in

compiling

Defects found in testing

Total defects found

Defects Tot. fix time 30 93 123

injected in Tot. defects 14 8 22

designing Avg. fix time 2 12 6

Defects Tot. fix time 59 41 100

injected in Tot. defects 28 5 33

coding Avg. fix time 2 8 3

Total Tot. fix time 89 134 223

Defects Tot. defects 43 13 55

Injected Avg. fix time 2 10 4

En la tabla podemos ver que la mayor cantidad de defectos, son introducidos en la fase de codificacin, pero se tarda un mayor tiempo en resolver los defectos que se introducen en el diseo a pesar de que son menos. 2. Qu categora tiene el tiempo promedio de eliminacin ms grande? El tiempo promedio de eliminacin por programa es de un 37%, la fase de compilacin presenta un promedio de 39%, en esta fase se eliminan los errores de sintaxis en su totalidad, y tambin eliminamos la mayora de los errores de tipo 80, que son los ms difciles de resolver, tambin la mayora de los defectos de asignacin (40), son resueltos durante esta fase. 3. Qu categora tiene el tiempo total de eliminacin ms grande?

Defect Fix Time By Type

020406080

100120140160

40 80 50 20 30 10 60 70 90 100

43

Como se puede ver en la tabla, los defectos encontrados que tardan el mayor tiempo, en resolverse son los defectos de tipo 40 (Asignacin). La fase en que se tarda el mayor tiempo de resolverlos son durante la fase pruebas, ya que para resolver estos problemas tenemos que ir haciendo watch, (en mi caso utiliz C++ ver. 3) para poder encontrar donde se encuentra el error.

8.8 Anlisis de Defectos Encontrados por el Compilador 1. Analice la efectividad del compilador eliminando defectos por tipo de defecto. Para los defectos de sintaxis (20), el compilador es muy eficiente, yo dira en un 80% de eficiencia, tambin para los defectos de asignacin (40), pero para todos los dems tipos no se puede decir los mismo, ya que el compilador de C++ (ver. 3) no es muy bueno. 2. El compilador encuentra todos sus defectos del tipo 20 (sintaxis / tipos)? No necesariamente, un ejemplo muy claro es, si tengo un error de punto y coma y en la siguiente lnea tambin se presenta el mismo error, el compilador solo reporta el primero, hasta que se vuelva a compilar reportara el siguiente error. Lo mismo sucede con los errores de tipo, sobre todo en el uso de FOR o el IF, si a estas sentencias se les pone un punto y coma al final, el compilador no reconocer dicho error, pero al ejecutar el programa no generara la operaciones que se le han asignado en su ejecucin.

44

8.9 reas de ms Alta Prioridad para Mejoras en la Segunda Mitad del

Curso

8.9.1 PLANEACIN

% Planning Time

02

46

810

1214

1618

1 2 3 4 5 6 7 8 9 10

Program Number

%

Su desempeo actual Como podemos ver en la grafica, la fase de planeacin no ha sido muy buena, sobre todo en el programa 5 y el programa 6 se encuentran en un porcentaje de planeacin de un 16% aproximadamente, en comparacin con los dems programas que estn entre un 6% y 8%. Lo que provoca que el tiempo en esta fase en porcentaje con las dems (diseo, codificacin, compilacin, pruebas y post morten), sea mayor. Lo ideal es que la fase de planeacin no sea mayor a un 5%. Ya que no debe de tardar ms de 10 minutos en el desarrollo de la misma. Su desempeo futuro deseado Una de mis principales metas es la de bajar el error de estimacin en el tiempo, esto es que nuestro tiempo en planeacin no exceda los 10 minutos (no exceda el 5% de tiempo total de desarrollo del programa) ya que tengo muchos problemas para hacer un clculo aproximado de dicho error, comprender mejor el uso de la tabla SIZE ESTIMATE y ser ms disciplinado. Sus metas de mejora Hacer un anlisis detallado de los requerimientos del programa y que no exedan de 10 minutos, para que la fase de diseo conceptual, se estimen bien el tamao de los mdulos, otra propuesta es la de estimar cuantas LOCs contendr cada funcin de los mdulos, ya que tengo un margen de 25% a 30% de error en cuanto al tamao de cada modulo. Para ser mas preciso y ahorrar tiempo en las otras fases.

45

8.9.2 DISEO

Defects Injected in Design

0

5

10

15

20

25

30

35

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

Su desempeo actual La grfica muestra que en el programa 5 no se tuvieron muchos errores en la fase de diseo (5 errores para ser exactos) en comparacin con la media que se mantiene en 20 errores por KLOC, se puede decir que obtuvimos un gol, pero no es lo recomendable, lo ideal seria que la pendiente negativa se fuera aproximando a cero paulatinamente, pero en este caso se ve muy drstico. Su desempeo futuro deseado Con la modificacin en la fase de planeacin, se cree que para las siguientes tareas se podr hacer un mejor diseo, provocando que los errores se reduzcan de un promedio de 20 errores por KLOC a no mayor de 7 errores por KLOC . Con la utilizacin del PSP2 , se podr controlar mejor los errores durante esta fase. Sus metas de mejora Para la segunda parte del proceso entran la revisiones (diseo y cdigo), lo cual mejorara el proceso y se podrn filtrar los errores que se encuentra en esta fase, lo que provocara que se tenga una disminucin de 20 errores por KLOC a un promedio no mayor a 9-5 errores por KLOC.

46

. 8.9.3 CODIFICACIN

Defects Injected in Code

010

2030

4050

6070

8090

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

Desempeo actual La grfica muestra que el porcentaje de error se ha mantenido constante, con aproximadamente 20 errores por KLOCs, aun as el porcentaje se considera alto lo que no es muy bueno, ya que conforme se avanza en el PSP si estos errores no disminuyen, mi productividad la cual esta en 43 LOC/Hora no se incrementara , o peor an puede disminuir, como aparece en el plan de la tarea 7A que esta en 27 LOC/Hora a la Fecha. Desempeo deseado Lo que se espera en la segunda parte del PSP es la de disminuir los errores introducidos durante esta fase, lo que podemos ver en la grfica anterior es que a pesar que los errores durante todos los programas se mantiene constante, an siguen siendo altos, ya que tengo un promedio de 36 errores por KLOCs, lo que espero es que se encuentre mximo de 20 errores por KLOCs. Sus metas de mejora Lo que modificara en el proceso es que una vez acabada la parte de codificacin es revisar el cdigo con calma y principalmente, lo que es el paso de parmetros ya que la mayor parte de mis errores son de este tipo. De esta forma se filtrarian la mayor parte de los errores, para as disminuir de 20 errores por KLOCs, que actualmente es la media que tengo a un promedio de 12-16 errores por KLOCs.

47

9 REPORTE DE LA SEGUNDA PARTE DEL PROCESO R5 Al igual que el R4 se evala el desempeo del alumno, en este reporte se compara la productividad entre la primera parte del proceso y la segunda parte, el indice de estimacin de defectos, y como a mejorado la estimacin de tamao y cdigo de los programas, as como tambin la calidad en cada uno de ellos.

9.1 Resumen del Plan Reporte R5

Student Capitaine Aggi Oscar Date 02/05/07

Instructor Castro Careaga Luis Fernando

Size Data Effort Estimate Object Plan

Number Actual

Number Est Effort

per Object Estimated

Effort Prrafos 28 22 5 140 Graficas 15 6 5 125 Tablas 9 10 5 45 Anlisis de Graficas / Tablas

25 16 5 125

Total 435

Effort Data Phase Plan Time Actual Time Planeacin 10 13 Desarrollo 320 434 Post Mortem

15 11

Total 345 458

48

9.2 Bitcora de Registro de Tiempo R5

Student: Capitaine Aggi Oscar Date:

02/05/07 Fecha Inicio Alto Tiempo

de Interrupcion

Tiempo Efectivo

Fase Comentarios

02/05/07

10:21:15 10:38:33

13.3

PLAN EXITOSO

02/06/07 10:13:39

13:07:08

173.5

DESARROLLO

02/07/07 10:36:21 13:15:12 158.9 DESARROLLO 02/08/07 10:37:15

11:33:13

56.0

DESARROLLO

02/09/07 11:35:01 12:20:45

45.7

DESARROLLO EXITOSO

02/10/07 16:35:44

16:46:58

11.2

POST MORTEN EXITOSO

49

9.3 Anlisis de la Exactitud de Estimacin de LOC

1. Se alcanzaron las metas de la segunda mitad de proceso? Por qu si o por que no?

Size Estimating Error

-20

-10

0

10

20

30

40

50

60

1 2 3 4 5 6 7 8 9 10

Program Number

%

Item: EstLoc ActLocFormulas 1 0 128 2 211 298 3 78 121 4 131.9343 144 5 209.2617 206 6 243.6118 330 7 173.2116 156 8 87.86986 133 9 169.5799 220 10 316.1508 365 Totals 1620.62 2101

No, como podemos ver en la tabla los errores de estimacin de tamao en la ltima parte del proceso no fueron muy buenos a excepcin de la TAREA 7A, ya que se tuvo una diferencia de 50 LOC aproximadamente por programa, en la grfica podemos constatar que durante todo el proceso, la estimacin de tamao fue mi principal problema, el cual no pude resolver. Lo nico bueno que puedo atribuirle a mi desempeo en esta parte del proceso, es que al menos el error de estimacin de tamao se mantuvo constante durante las ultimas 3 tareas.

50

2. Qu tan frecuente se esta dentro del intervalo de prediccin estadstico del 70% (90%)?

LOC Estimadas UPI(70%) LPI(70%) tarea 7 137 236 111 tarea 8 77 163 13 tarea 9 137 226 114 tarea 10 263 373 260

Como podemos ver en la tabla, todas las tareas estuvieron dentro del intervalo de prediccin, se utilizo el mtodo B para la estimacin de tamao, lo curioso es que a pesar de que se estuvo dentro del intervalo tuve un Error grande en cuanto al clculo de las LOC Totales Reales de cada programa. Esto es debido a que el intervalo de prediccin, solo sirve para calcular cual mtodo nos conviene ms para hacer la estimacin del tamao de un programa. 3. Hay una tendencia a agregar o quitar objetos enteros? NO, por que todos los objetos que se utilizaron fueron los necesarios para la realizacin de cada uno de los programas. 4. Hay una tendencia a juzgar mal el tamao relativo de los objetos? Si, ya que aun no se pudo definir una buena aproximacin en cuanto al tamao de los mdulos, a pesar que se contaban con la ayuda de los datos histricos, creo que el mayor problema fue que no supe interpretar bien los valores y hacer un buen uso de este material.

LOC Estimado LOC Actual % Error Tarea 7A 17 24 41.1764706 main 50 45 -10 correl 60 74 23.3333333 signif 10 13 30 imprime Tarea 8A 15 23 53.3333333 main 45 78 73.3333333 ordena 7 19 171.428571 imprime 10 13 30 selec Tarea 9A 12 22 83.3333333 main 7 11 57.1428571 imprime 25 29 16 distk2 13 23 76.9230769 normal 48 93 93.75 calculaQ 32 42 31.25 calculaP Tarea 10A 17 28 64.7058824 main 90 127 41.1111111 calculos 55 93 69.0909091 rango 35 25 -28.5714286 calc_zk 30 36 20 desvia 20 26 30 imprime

51

La tabla muestra el % de error de estimacin de tamao de cada modulo de los programas 7A-10A, podemos ver que la estimacin es psima para la mayora de los mdulos. La TAREA 7A tiene un %Error menor al 50% de Tamao por mdulo, a pesar de esto fue la tarea con un Error de Estimacin de tamao menor. La peor de todas las tareas fue la 8A, ya que presenta un %Error de 50% a 171% lo cual afecto relativamente la productividad, lo mismo ocurri con la TAREA 9A con %Error entre50%-90%. Para la TAREA 10A el %Error se ajusto de 20%-69% debido a que se pudo interpretar mejor los datos, a pesar de que no se estimo bien el tamao de 2 de los mdulos (calculos.c y rango.c), nuestra productividad aumento a 60 LOCs/Hora, que era lo que se quera. 5. Se pudieron calcular tamaos relativos usando datos histricos? S? Los datos histricos nos mostraron que exista una tendencia a subestimar los tamaos de los mdulos de los programas, nos fueron de gran ayuda en la estimacin del tamao de los mdulos para las tareas 7A, 8A, 9A y 10A. Para calcular el tamao de cada nuevo objeto, necesito usar los datos histricos, y este nos lo va dando la hoja Locmeth, y los intervalos de prediccin (UPI, LPI) que nos muestra el tamao de los objetos que hemos realizado. Principalmente me base en los intervalos de prediccin para hacer la estimacin del tamao de los mdulos del programa. Podemos ver en la tabla que el total de nuestras LOCs N&C cayeron dentro del intervalo de prediccin para cada una de las tareas, pero esto no nos garantiza que este tamao sea el optimo, por eso tambin tenemos que tomar en cuanta nuestro Locmeth donde podemos hacer un calculo del tamao estimado de LOC por mtodo, tomando en cuenta los tamaos de los mtodos de las tareas anteriores.

Total N&C (N)

LOC Estimados UPI(70%) LPI(70%)

tarea 7 156 137 236 111 tarea 8 133 77 163 13 tarea 9 200 137 226 114 tarea 10 357 263 373 260

52

6. Basado en la exactitud de estimacin del tamao del historial. Qu tan realistas son las metas de estimacin del tamao?

Analysis calculations

Size Error %

Formulas 0 1 0 2 41.232233 55.128214 9.14527 5 -1.558696 35.4614 7 -9.936758 51.360219 29.7323410 15.45122Totals 226.0154

Como se puede observar en la tabla el error tiende a estabilizarse entre un 30% y un 9% exceptuando la TAREA 8A, lo cual considero que no es excelente, pero si es bueno, lo que implica que si se sigue utilizando este tipo de mtodo, el error tendera a estabilizarse, ahora si analizamos todas la tareas a excepcin de la 2A,3A y 8A el Error de estimacin se encuentra entre el 35% al 1%, que nos dice esto, con forme se avanza en el proceso se tiene una mejor facultad para hacer una estimacin ms precisa, lo ideal sera que dicho error estuviera entre un 10% y 5%, pero no se puede predecir el futuro y ser tan exacto, e incluso es muy difcil alcanzar la meta ms razonable. 7. Como se puede cambiar el proceso para alcanzar estas metas? Uno de los cambios que podra hacerle al proceso sera que cuando analice cada objeto, ver cada una de sus funciones y de ah empezar hacer un conteo de las lneas que podra tener cada funcin pero con ms detenimiento y atencin de lo que lo hago hasta ahora, y as obtener el conteo para todo el objeto.

53

9.4 Anlisis de la Exactitud de Estimacin de Tiempo

1. Se alcanzaron las metas del la segunda mitad de proceso? Por qu si o porque no?

Time Estimating Error

-20

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10

Program Number

%

En la grafica se puede ver, que en comparacin con las primeras tareas el Error de Estimacin de Tiempo bajo considerablemente, mantenindose entre un 15%-25% del tamao real. Aunque no podemos considerarla muy buena pero al menos se mantuvo constante en ese rango. En la tabla podemos ver para la TAREA 7A la estimacin de Error fue buena en comparacin con las TAREA 8A y TAREA 9A la mejor estimacin se presento durante la TAREA 10A ya que el error estimado es de 9.4%, esto quiere decir que se realizo el programa antes del tiempo propuesto.

Time Error % Formulas 0 1 7.04321 2 4.376543 3 106.2549 4 51.95974 5 16.31369 6 57.64492 7 14.75728 8 26.91608 9 21.47024 10 -9.44178 Totals 297.2948

54

2. Qu tan frecuente se esta dentro del intervalo de prediccin estadstico del 70% (90%)?

Tiempo Real

Tiempo Estimado UPI(70%) LPI(70%)

tarea 7 355 309 437 224 tarea 8 220 173 261 85 tarea 9 320 263 329 198 tarea 10 383 401 474 328

Podemos ver que siempre estuve dentro de mi intervalo de prediccin con un margen de error de 50-20 minutos y esto me dice que el tiempo en cuanto a la realizacin de las tareas disminuyo, lo que contribuyo a tener una mejor estimacin para la realizacin de los programas, otra cosa que fue de gran ayuda, fueron las revisiones de diseo y cdigo, gracias a ellas se redujo considerablemente el tiempo en las fases de compilacin y pruebas. 3. La productividad es estable? Por qu si o por que no?

Productivity

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

Program Number

LOC

/Hou

r

La productividad para la primera parte del proceso se mantuvo estable en un promedio de 40 LOC/Hora, al introducir las revisiones de Diseo y Cdigo, la productividad bajo un poco para los primeros 2 programas de la segunda parte TAREA7A y TAREA8A, aunque se fue normalizando y para el ultimo programa aumento considerablemente, para producirse 60 LOC/Hora. 4. Como se puede estabilizar la productividad? La forma ms conveniente para tener una buena productividad es la de tener una buena estimacin de las LOC(N&A) y una buena estimacin del tiempo total de desarrollo. Como se puede ver en la tabla para la segunda parte del proceso la productividad fue aumentando considerablemente de 26 LOC/Hora hasta producir un total de 60 LOC/Hora,

55

esto se logro gracias a las revisiones de Diseo y Cdigo, ya que la mayora de los errores se corrigieron en estas Fases y se redujo el tiempo de correccin de errores en las fases de Compilacin y Pruebas.

ProductivityLOC/Hour 0 26.57286 63.4455 41.41078 39.50015 44.67739 45.48239 26.39594 36.34707 41.26504 60.34443 42.96792

5. Cuantas veces las estimaciones de tiempo afectaron las estimaciones de tamao? Ayudara la regresin mltiple? La estimacin de tamao es un punto crucial a partir del cual se obtiene la estimacin del tiempo, y si la estimacin de tamao tiene un gran error seguramente la de tiempo ser afectada. Y por supuesto que me ayuda la regresin mltiple a obtener un intervalo en el cual carea la estimacin de tiempo con una muy buena exactitud. Como conclusin tenemos que la estimacin de tiempo no afectaron las estimaciones de tamao, en cambio la estimacin de tamao, si afecta a la de tiempo. 6. Basado en la exactitud de estimacin del tiempo del historial. Qu tan realista son las metas de estimacin del tiempo?

Time Error % 0 7.04321 4.376543106.254951.9597416.3136957.6449214.7572826.9160821.47024-9.44178297.2948

56

En lo que respecta a la estimacin de tiempo, no tuve gran problema, como podemos ver en la tabla, que el % de Error para la segunda parte del proceso, se encuentra entre un 26% y un 9%, lo cual es bueno. Para mi punto de vista lo ideal sera que este Error se encontrara dentro del 10% al 5%, si vemos detalladamente la tabla se aprecia que el tiempo de estimacin de Error aumento en la tarea 3A, 4A y 6A, esto incremento se debi, a que en estas tareas se cambio el proceso y se incorporaron nuevas tablas y plantillas, como fueron el mtodo PROBE, el SIZE ESTIMATE y las revisiones de diseo y cdigo. Esta parte fue la que pude dominar ms