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

México D.F. MAYO 2007

INTRODUCCION: Las computadoras se han convertido en una herramienta muy importante en la vida del ser humano, es utilizada prácticamente 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 difíciles de resolver, sin la utilización de este equipo. A medida que la tecnología avanza, nos hemos vuelto a la necesidad de crear nuevas formas en la realización 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 diseño estructural, podríamos perdernos en alguno de los módulos 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 cumplía con las especificaciones que se tenían 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 más fácil? Gracias a la ingeniería de software ¿Pero en que consiste? La Ingeniería de software es la rama de la ingeniería que crea y mantiene las aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros campos. Es relativamente nueva ya que surge a finales de las anos 60’s. Comienza con una serie de tareas que hacen modelos y que resultan en una especificación completa de requisitos y una representación comprensiva de diseño del software que será construido. Después de varias pruebas utilizando diversos métodos, es opto por hacer un estándar a los métodos Orientados o Objetos (OO).

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

Análisis de requisitos: Es la primera etapa para crear el programa. El cliente especifica que es lo que quiere que el sistema realice. Especificación: Es la tarea de describir detalladamente el software a ser escrito. Diseño y arquitectura: Se refiere a determinar como funcionará de forma general sin entrar en detalles. Programación: Es esta fase se empieza codificar el diseño. Prueba: Se comprueba que el software realice las tareas para el cual fue diseñado, se recomienda probar por separado cada módulo y ver que funciona correctamente. Documentación: Realización del manual de usuario, y posiblemente un manual técnico con el propósito de mantenimiento futuro y ampliaciones al sistema.

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

La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

• Modelo en cascada • Modelo en espiral • Modelo de prototipos • Método en V

Por lo regular el más utilizado de estos paradigmas es el modelo de cascada, ya que considero en mi opinión es el mejor de todos de todos. Al hablar de Ingeniería de Software también tendremos que hablar de UML, ya que se encuentran estrechamente ligados en el desarrollo de sistemas de alta calidad. UML1 ha emergido como una unificación de los diversos métodos orientados a objetos y se está convirtiendo en un estándar. El Lenguaje Unificado de Modelado es ahora el esquema de representación gráfica más utilizado para modelar sistemas orientados a objetos. Aquellos quienes diseñan sistemas Utilizan el lenguaje (en forma de diagramas) para modelar sus sistemas. Una de las características más 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 diseñar sistemas utilizando varios procesos, pero todos los desarrolladores pueden ahora expresar esos diseños con un conjunto de notaciones estándar. Una de las características de PSP, es que es muy parecido a la ingeniería de software, ya que la mayoría de sus fases son muy parecidas, más adelanta se hablara en que consiste el PSP y cual es su propósito 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.1……………………………………………………………5 2.3 PSP 1…………………………………………………………….. 6 2.4 PSP 1.1……………………………………………………………6 2.5 PSP 2………………………………………………………….…..6

2.6 PSP 2.1……………………………………………………………7 2.7 PSP 3………………………………………………………….…..7

3. TAREAS REALIZADAS DURANTE EL PROCESO PSP…………8 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 ESTÁNDAR DE CONTEO DE LOC (R1). ………………………..26 4.1.7 ESTÁNDAR DE CODIFICACIÓN (R2)………………………….26 4.1.8 PLANTILLA DE REPORTE DE PRUEBAS…………………...….26

4.1.9 PLANTILLA DE ESTIMACION DE TAMAÑO (Size Estimate).………26 4.1.10 PLANTILLA METODO PROBE………………………………27 4.1.11 LISTA DE CHEQUEO DE REVISION DE DISEÑO.………………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 LOC’s (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 R4………………………33 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 TIEMPO…38 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 PLANEACIÓN……………..……………………………44 8.9.2 DISEÑO………………………………………..….…….45

8.9.3 CODIFICACIÓN…………………..……………….……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 TIEMPO…53 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 desempeño personal, en la realización de un sistema.

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

ordenada y eficiente individualmente. • Conocer el funcionamiento de la metodología 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

realización de cada programa. • Tener una mejor estimación en el desarrollo de programas mediante el uso de los

datos históricos que se proporcionan las plantillas. • Aumentar la calidad y productividad de un producto mediante la utilización de PSP,

para crear un software más eficiente y con mejor calidad. • Reducir errores mediante las revisiones de diseño y código, para disminuir el

tiempo de desarrollo de un programa.

• Disminuir los errores en las fases de compilación 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

metodología 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 • Estándares

Un PSP es una línea de trabajo de medición y análisis para ayudarle a caracterizar su Proceso. También es un procedimiento definido que le ayuda a mejorar su desempeño, de una manera individual, ya que dicho proceso esta creado para que el alumno se desarrolle productivamente de una forma personalizada. Basadas en prácticas 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

guía

Bitácoras

Planeación

Diseño

Codificación

Compilación

Pruebas

PM

3

Como podemos ver en la figura 1.1, PSP sigue una línea 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 dirección. Durante la fase de planeación el alumno desarrolla el modelo conceptual, que es la base para la construcción de cada uno de los métodos de la realización del sistema o programa. Al entrar en la fase de Diseño se crean o diseñan cada uno de los métodos del programa, en base a la fase de planeación. Únicamente se diseña en papel, no se puede utilizar un editor de texto, ya que así esta estipulado el área de trabajo en la fase de diseño. Durante la fase de compilación 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 tenía contemplado. Por último tenemos el resumen del plan de proyecto, que es otra plantilla donde aparecen los tiempos de desarrollo, el número de defectos encontrados, el tamaño del programa, una serie de datos, que van aumentando conforme va avanzando el proceso. Durante cada una de las fases se lleva una bitácora, donde se toman los tiempos que se tardo el alumno en la realización de cada fase. Así como también una serie de plantillas. Más adelante se mencionará el funcionamiento de este tipo de bitácora 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. También esta diseñado 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 diseñado mediante una serie de 10 tareas1, donde en cada uno de ellas se van incorporando nuevas plantillas, lo que hace que el proceso vaya haciéndose más robusto y la documentación aumente. Las variantes se mencionan a continuación:

1 Ver sección 3

4

El PSP se introduce en siete pasos compatibles y progresivos. PSP0: Usted establece una línea de base de desempeño. PSP1: Usted hace planes sobre tamaño, recursos y tiempo. PSP2: Usted practica la administración de defectos y del rendimiento (yield). PSP3: Usted escala los métodos de PSP a proyectos más grandes. La figura 1.2 nos detalla específicamente como están estructuradas cada una de las variantes del PSP. Así como también las plantillas que se incorporan en cada una de estas fases. En la sección 4.1 se detallan específicamente 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 Cíclico

PSP2 Revisiones de CódigoRevisiones de Diseño

PSP2 .1 Diseño de Plantillas

PSP1 Estimación de Tamaño

Reporte de Pruebas

PSP1 .1 Planeación de Tareas

Planeación de Calendario

PSP0 Proceso Actual

Registro de Tiempo Registro de Defectos

Estándar de Tipos de Defectos

PSP0 .1 Estándar de Código Medición de Tamaño

Propuesta de Mejora de Procesos (PIP)

Proceso personal cíclico

Administración de Calidad Personal

Proceso de Planeación 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 métodos actuales de diseño y desarrollo. Los objetivos principales del PSP 0 son:

• Demostrar el uso de proceso definido al escribir un programa pequeño • Incorporar medidas básicas en el proceso de desarrollo de software • Requiere cambios mínimos a las practicas personales

Cuenta con una serie de elementos para facilitarnos la medición 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 fácil. Para esta primera fase, los elementos necesarios son:

• Strip de Proceso • Reporte de Plan de Proyecto • Bitácora de Registro de Tiempo • Bitácora de Registro de Defectos • Estándar de Tipo de Defectos

2.2 PSP 0.1 El PSP 0.1 tiene como finalidad medir el tamaño del software para relacionar la cantidad de producto generado con el esfuerzo empleado. Así como también para calcular nuestra productividad (medida en LOC’s2), normalizar los defectos. Las tareas 2A y 3A se realizan con este proceso. Los objetivos principales del PSP 0.1 son:

• Medir el tamaño de los programas que usted produce • Contabilizará los tipos de LOC’s en los programas que produzca • Realizará mediciones de tamaño exactas y precisas

Introducimos una nueva serie de elementos al proceso:

• La forma de propuesta de mejora del Proceso (PIP) • Estándar de Conteo (R1) • Estándar de Codificación (R2)

2 Líneas de Código (Line of code)

6

2.3 PSP 1 El Objetivo de PSP1 es establecer un procedimiento ordenado y repetido para el desarrollo de estimación de tamaño. La tarea 4A es la única que se realiza durante esta variación de PSP. Los nuevos elementos introducidos en el PSP1 son:

• El método de Estimación de tamaño PROBE • La plantilla de Estimación de tamaño • La plantilla de reporte de pruebas

2.4 PSP 1.1 Los Objetivos del PSP1.1 son introducir y practicar métodos para:

• Realizar planes de recursos y de calendarios de trabajo • Darle seguimiento a su desempeño en cuanto a sus planes • Juzgar la probabilidad de las fechas de terminación del proyecto

Se incorporan nuevos elementos al proceso:

• Plantilla de planeación de tareas • Plantilla de planeación de calendario de trabajo

Por lo regular estas plantillas se utilizan para proyectos que tardan varios días o semanas. No se utilizaran durante las tareas de PSP. El resumen del plan de proyecto se expandió para que incluya estadísticas básicas 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 diseño y código • Métodos para la evaluación y mejora de calidad de sus revisiones

Se incorporan dos nuevos elementos al proceso: • Lista de comprobación de la revisión de diseño del PSP2 • Lista de comprobación de la revisión de código

7

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

• Introducir métricas adicionales para la administración de la calidad • Plantillas de diseño que proporcionen una línea de trabajo ordenado y formatos para

documentar los diseños Existen cuatro nuevos elementos del proceso:

• Lista de comprobación de la revisión de diseño PSP2.1 • Plantilla del escenario operacional • Plantilla de especificación de estados • Plantilla de especificación lógica

Las tareas 8A, 9A y 10A se realizan con este proceso. 2.7 PSP 3 El PSP3 (cíclico) proporciona una línea de trabajo para el uso de una estrategia de desarrollo cíclico, para desarrollar programas de tamaño modesto. Los pasos de requerimientos, planeación y postmortem del PSP, son realizados una sola vez para el programa total. El diseño de alto nivel particiona el programa en elementos más pequeños y establece la estrategia de desarrollo que determina los pasos cíclicos.

8

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

• Calcule la media y la desviación estándar de una serie de n números reales. • Su programa debe leer los n números reales de un teclado, un archivo, etc. • Utilice una lista ligada para almacenar los n números durante los cálculos.

La media es el promedio de n números. La desviación estándar se calcula de la siguiente manera:

( )1

. 1

2

−==

∑ −=

n

mediDesvEst

n

ixx

σ

donde: σ es el símbolo para la desviación estándar Σ es el símbolo para la sumatoria i es un índice para los n números Xmed es el valor promedio de los n números

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 vacía o el final de la lista Las operaciones típicas 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 LOC’s lógicas en un programa omitiendo los comentarios y las líneas en blanco.

• Utilice su estándar de conteo (R1) y su estándar de codificación (R2) para colocar una línea lógica en cada línea física y cuente las líneas físicas.

• Produzca un conteo único para el archivo de programa fuente. • Prueba completamente el programa. Como una prueba, cuente las LOC’s 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 LOC’s lógicas en un programa • El total de LOC’s lógicas en un objeto o función • Para un lenguaje orientado a objetos, el número de métodos en cada objeto

Produzca e imprima

• El conteo de LOC’s para cada objeto o función junto con el nombre del objeto o función

• Para un lenguaje orientado a objetos, el número de métodos 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 estándar de conteo (R1) y su estándar de codificación (R2) para simplificar el diseño del programa 3A.

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

• Calcule los parámetros de regresión β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 números reales.

10

Calculando los Parámetros de Regresión La fórmula para el parámetro de regresión β0 es:

β0 = yprom – β1 xprom

La fórmula para el parámetro de regresión es β1

Pruebe completamente el programa. Como mínimo, use la tabla que se muestra a continuación 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) También, utilizando sus propios datos, calcule los parámetros 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 numéricamente una función utilizando la regla de Simpson y escriba la función que sea la distribución normal. El programa debe diseñarse para integrar utilizando varias funciones que sean proporcionadas. Usted necesitará este programa para calcular los valores de las distintas distribuciones estadísticas que se usan posteriormente en las tareas. Pruebe completamente el programa. Como mínimo, use este programa para calcular los valores de la integral de distribución normal para tres valores. Prueba Valor Esperado • - ∞ a 2.5 0.9938 • - ∞ a 0.2 0.5793 • ∞ a -1.1 0.1357 Integración Numérica En principio la integración numérica 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 límites de integración

• La mayoría de las funciones estadísticas se integran de - ∞ a algún valor • Todas las funciones estadísticas 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 función 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 número de segmentos Con funciones simétricas (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 fórmula de la distribución 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 predicción del 70% y del 90% de las LOC’s nuevas y modificadas estimadas, dado un conjunto de datos históricos de tamaño y un estimado de LOC de objeto.

• Usamos la regla de integración de Simpson del programa 5 para calcular el valor de la distribución t.

• Use una lista ligada para almacenar los datos históricos. Intervalo de predicción El intervalo de predicción proporciona un rango de probabilidad alrededor del estimado.

• Un intervalo de predicción de 70% da el rango dentro del cual caerán el 70% de los estimados.

• No es un pronóstico, solo una expectativa. • Solo aplica si el estimado se comporta como los datos históricos.

Se calcula a partir de los mismos datos utilizados para calcular los parámetros de regresión. Par calcular el intervalo de predicción, realizamos los siguientes pasos: 1. Lee los datos históricos x’s y y’s. 2. Calcule B0 y B1. 3. Lea su estimado Xk. 4. Calcule una proyección 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 fórmula para el cálculo del rango de predicción es:

14

( ) ( )

( )∑=

−

−++= n

iavgi

avgk

xx

xxn

doftRange

1

2

211,2/ σα

Donde • X es el tamaño de los datos históricos • N es el número de puntos de los datos históricos • t(α/2, dof) doble lados de la distribución t para n - 2 grados de libertad.

La formula para calcular la desviación estándar es:

( )∑=

−−⎟⎟⎠

⎞⎜⎜⎝

⎛=

n

iii xy

gl 1

210

1 ββσ

Donde

• X son los datos históricos de tamaño estimado de objetos. • Y son los datos históricos de tamaño nuevo y modificados reales. • B y b son los parámetros de regresión lineal de los datos X’s vs. Y’s • gl es el número 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 número de miembros de x. • Г(x) = (x-1) Г (x-1), Г (1) = 1, y Г (1/2) = π1/2.

La distribución t La distribución t

• Es parecida a la distribución normal. • Tiene colas muy gruesas. • Es usado en estimados de parámetros estadísticos 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 integración es demasiado grande, tome un límite superior de

prueba más grande. 2. Si el resultado de la integración es demasiado grande, tome un límite superior más

pequeño. Haga la integración de prueba sucesivas hasta que el valor de integración 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 cálculo 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 correlación y significancia entre las LOC nuevas y modificadas actuales y el tiempo de desarrollo actual; así como la correlación y significancia entre las LOC’s nuevas y modificadas y el tiempo de desarrollo de su histórico de datos personales. Usando la correlación La correlación rxy tiene un rango entre +1 y -1.

• Cerca de +1 implica una fuerte relación positiva, cuando x incrementa, y también. • Cerca de -1 implica una fuerte relación negativa, cuando x incrementa, y

decrementa. • Cerca de 0 implica que no hay relación.

La correlación es usada en PSP para juzgar la calidad de la relación linear entre varios datos de procesos históricos, que son usados para la planeación. Para nuestro propósito, usamos el valor de relación rxy cuadrado, o r2.

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

17

Calculando la correlación La formula para calcular el coeficiente de correlación r es

r x,y( ) =n xiyi

i =1

n

∑ − xii =1

n

∑ yii =1

n

∑

n xi2

i =1

n

∑ − xii =1

n

∑⎛ ⎝ ⎜ ⎞

⎠

2⎡

⎣ ⎢

⎤

⎦ ⎥ n yi

2

i =1

n

∑ − yii =1

n

∑⎛ ⎝ ⎜ ⎞

⎠

2⎡

⎣ ⎢

⎤

⎦ ⎥

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

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

t =

r x, y( ) n − 2

1 − r x, y( )2

Donde r es la correlación

2. Encuentra la probabilidad p por integración numérica de distribución t para n – 2 grados de libertad de -∞ a t. 3. Calcula las colas de distribución, 2*( 1 - p). El área de una cola de distribución ≤ 0.05 es considerada una evidencia fuerte de que exista una relación. El área de una cola de distribución ≥ 0.2 es considerada una relación 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 números reales de forma ascendente. Proporcionando la capacidad de ordenar con respecto a cualquier campo numérico. Inserción sort Existen muchos algoritmos para el ordenamiento de datos, pero la inserción sort puede ser la más simple para ordenar una lista ligada. El algoritmo de inserción sort va encontrando la posición correcta para un dato o elemento, entonces el elemento dentro de la lista toma su posición correcta.

1 3 5 8 9 12

7

14 15 16 18 19 22

Se considera que se utilicen dos listas ligadas para la realización 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 números reales es normalmente distribuida.

• Use la rutina de integración de Simpson’s del programa 5A para calcular los valores de la distribución X2.

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

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

19

Los pasos de la prueba χ2 son los siguientes:

1. Ordena el conjunto de datos de n números reales de forma ascendente.

2. Normalice el conjunto de datos.

Primero, calcule la desviación estándar σ, para los datos usando n -1.

( )∑

=

−−

=n

iavgi xx

n 1

2

11σ

Después, transforme cada xi en zI, donde

( )σ

avgii

xxz

−=

3. Divida la distribución normal entre el mismo número de segmentos S, donde • n/S ≥ 5 • S > 3 • S2 ≥ n

4. Determine cuantos puntos de la distribución 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 distribución X2 para S – 1 grados de libertad, para integrar desde 0 a Q.

pdof

u e dudof

dof uQ

=⎛⎝⎜

⎞⎠⎟

⎛⎝⎜

⎞⎠⎟ − −∫

1

2 2

2 12

02Γ

8. Calcule la cola de distribución 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 parámetros de regresión múltiple (B0, B1,B2, B3).

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

• Use además una lista ligada para almacenar los datos y el método de integración de Simpson del programa 5A para calcular la distribución t.

• Calculando los parámetros de regresión múltiple La regresión múltiple proporciona un camino para estimar los efectos de múltiples variables cuando no es posible separa los datos. A continuación se muestra en una serie de 13 pasos como podemos calcular la regresión múltiple:

1. Use la siguiente formula de regresión múltiple, para calcular el valor del proyecto: zk = β0 + wkβ1 + xkβ2 + ykβ3

2. Encontrar los parámetros BETA resolviendo el siguiente sistema de ecuaciones

lineales:

β0n + β1 wii=1

n

∑ + β2 xii=1

n

∑ + β3 yii =1

n

∑ = zii =1

n

∑

β0 wii =1

n

∑ + β1 wi2

i =1

n

∑ + β2 wixii =1

n

∑ + β3 wiyii =1

n

∑ = wizii=1

n

∑

β0 xii =1

n

∑ + β1 wixii =1

n

∑ + β2 xi2

i=1

n

∑ + β3 xiyii=1

n

∑ = xizii =1

n

∑

β0 yii =1

n

∑ + β1 wiyii=1

n

∑ + β2 xiyii =1

n

∑ + β3 yi2

i =1

n

∑ = yizii =1

n

∑

3. Cuando calcules el valor de los términos, obtendrás el siguiente sistema de

ecuaciones lineales:

6β0 + 4,863β1 +8,761β2 + 654β3 = 714

4,863β0 + 4,521,899β1 + 8,519,938β2 + 620,707β3 = 667,8328, 761β0 + 8,519,938β1 + 21, 022, 091β2 + 905,925β3 = 1,265,493654β0 + 620,707β1 + 905,925β2 +137, 902β3 = 100,583

21

4. Diagonalizando por el método de Gauss, se elimina sucesivamente un parámetro a

la vez, dando como resultado:

6β0 + 4,863β1 +8,761β2 + 654β3 = 714

0β0 + 580,437.5β1 +1,419,148β2 + 90,640β3 = 89,1350β0 + 0β1 + 4,759,809β2 − 270,635β3 = 5,002.3320β0 + 0β1 + 0β2 + 37,073.93β3 = 9,122.275

5. La solución para los términos BETA es:

β0 = 6.7013β1 = 0.0784β2 = 0.0150β3 = 0.2461

6. Determine el intervalo de predicción por solución del rango con la siguiente

ecuación:

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

+wk − wavg( )2

wi − wavg( )2∑+

xk − xavg( )2

xi − xavg( )2∑+

yk − yavg( )2

yi − yavg( )2∑

7. Calculamos la varianza como sigue:

σ 2 =1

n − 4⎛ ⎝

⎞ ⎠ zi − β0 − β1wi − β2xi − β3yi( )

i =1

n∑2

8. La desviación estándar es la siguiente:

σ = σ 2 = 513.058 = 22.651

9. Los términos dentro de la raíz cuadrada que determinan el rango son:

Newk − Newavg( )2= wk − wavg( )2

= 650 − 810.5( )2 = 25, 760.25

Re usek − Re useavg( )2= xk − xavg( )2

= 3,000 −1,460.17( )2 = 2,371,076.43

Modifyk − Modifyavg( )2= yk − yavg( )2

= 155 −109( )2 = 2,116

22

10. El valor de la distribución t, para el intervalo de predicción 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 raíz cuadrada:

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

+2,371,076.43

8,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 predicción es de: 140.902 +/- 38.84 horas. O lo que es lo mismo:

102.06 horas como mínimo y 179.74 horas como máximo.

.

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 desempeño durante el proceso y la de proveer información 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 estimación de tamaño o tiempo.

Formas, plantillas y estándares

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

Bitácora de registro de Tiempo

X X X X X X X

Bitácora de Registro de Defectos

X X X X X X X

Estándar de Tipos de Defectos

X X X X X X X

PIP X X X X X X Estándar de Codificación X X X X X X Estándar de Conteo de LOC X X X X X X Plantilla de Reporte de Pruebas

X X X X X

Plantilla de Estimación de tamaño

X X X X X

Plantilla Método PROBE X X X X X Lista de Chequeo de la Rev. De Diseño

X X X

Lista de Chequeo de la Rev. De Codificación

X X X

Plantilla del Escenario Operacional

X X

Plantilla de la Especificación de Estados

X X

Plantilla de Especificación de Lógica

X X

Tabla 4.1 Formas, plantillas y Bitácoras 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 métricas PSP más 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 tamaño del programa, los defectos encontrados en las distintas fases del proceso, por citar algunos. Los resúmenes son únicos para cada fase del PSP, conforme se agregan nuevas métricas 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 bitácora de registro de tiempo. La finalidad de esta Bitácora es de proporcionarnos exactamente el tiempo que tardamos en la realización de cada uno de nuestros proyectos, el tiempo de inicio y el tiempo de terminación de cada fase en minutos, esta perfectamente diseñado para contabilizar los tiempos en cada una de las fases, lo que nos permite ver cual de las fases es la que se tarda más en realizarse. Otra de las características de esta bitácora es que, en caso que se presente una interrupción durante el desarrollo de una fase, podemos hacer una pausa y continuar con el proceso más tarde, así como realizar una parte de una fase y continuar con ella más tarde, también podemos hacer comentarios acerca de cual fue el motivo de la interrupción. 4.1.3 BITACORA DE REGISTRO DE DEFECTOS Otra de las Bitácoras utilizadas durante todo el PSP es la bitácora de Registro de Defectos. Así como es necesario llevar un control del registro de nuestros tiempos, también 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 Planeación hasta la fase de Pruebas. Tomando un estándar de tipo de defectos proporcionado por el PSP, anotamos en la bitácora los defectos que se vayan encontrando por categorías (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 descripción de en que consistió el defecto. Para la primera parte del Proceso los defectos son encontrados en las fases de Compilación y Pruebas, para la segunda parte del Proceso se introducen 2 nuevas plantillas que son las revisiones de diseño y código.

25

4.1.4 ESTANDAR DE TIPO DE DEFECTOS El estándar de tipos de defectos proporciona una categoría general de tipos de defectos, los cuales se van presentando en la realización 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 estándar ya establecido y me dio buenos resultados, ya que no se me hizo muy difícil 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 realización de los programas. Número de Tipo

Nombre del Tipo Descripción

10 Documentación Comentarios o mensajes 20 Sintaxis Ortografía, puntuación, tipos, formatos de

instrucciones 30 Componentes o configuración Administración de cambios, control de versiones,

bibliotecas 40 Asignación Declaración, nombres duplicados, alcance, límites 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 Función o lógicos Defectos por lógica, apuntadores, ciclos, reexcursión,

cálculos, funciones 90 Sistema Configuración, sincronización, memoria 100 Ambiente Problemas de diseño, compilación, prueba, u otros con

los sistemas de desarrollo

Tabla 4.2 Estándar 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 realización 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 realización del programa. Así como también las observaciones y descubrimientos que se presentaron durante la realización del ejercicio, y algunas notas o comentarios, que nos pueden servir más adelante conforme avanzamos en el proceso, como una mejora personal en la realización de las tareas.

26

4.1.6 ESTÁNDAR DE CONTEO DE LOC (R1) Como queremos medir el tamaño del software, tenemos que contar líneas de código (LOC’s). Tenemos que crear un tipo estándar para poder contar las líneas. Este estándar se hace en base a que lenguaje se va a utilizar para trabajar en la realización de las tareas. En mi caso use Borland C++ (Versión. 3.0). Tenemos que tomar en cuenta como vamos a contar las LOC’s, ya sea que estructuras de control vamos a contar, si vamos a contar los comentarios, instrucciones vacías, librerías, módulos etc. 4.1.7 ESTÁNDAR DE CODIFICACIÓN (R2) Esta forma se introduce a partir del PSP 0.1. La finalidad de este estándar es de ver de que manera vamos a realizar cada uno de los módulos de nuestras tareas. Que se predefina el tipo de encabezado se van a utilizar, la declaración de variables se realizará de tal manera, descripción de la funcionalidad de los módulos, resumen del listado de los módulos del programa, descripción de las constante, librerías, 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 mínimo un número 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 TAMAÑO (Size Estimate) Tiene como finalidad de aportar datos históricos para hacer las mediciones de tamaño de nuestros programas. De acuerdo a nuestro diseño conceptual, en esta plantilla se apuntan cada uno de los módulos que va a tener nuestro programa, cual va ha ser el número de LOC’s de cada uno de los módulos, el tipo de método que va ha ser. También cuenta con información acerca de si vamos a utilizar código reutilizable, si vamos a modificar código o si vamos a construir código nuevo. Esta plantilla se utiliza para la realización de cada uno de los programas de PSP. Como lo dije anteriormente tiene como finalidad d estimar el tamaño de cada uno de los módulos, para tener un error menor en cuanto al tamaño real de los módulos.

27

4.1.10 PLANTILLA METODO PROBE La finalidad principal de esta plantilla, es la de hacer la estimación de tamaño y tiempo en la realización de cada tarea del proceso. Principalmente se basa en nuestro banco de datos históricos proporcionados, durante el desarrollo de las primeras 3 tareas, al principio como no se cuenta con muchos datos, es un poco difícil estimar bien que tipo de método de Estimación (A, B, C, D) se va a utilizar. Cuenta con una grafica que se calcula utilizando regresión lineal, donde se muestra la correlación estimada que existe entre el tiempo estimado Vs el tiempo actual y el tamaño estimado Vs el tamaño actual. La selección del método es en base al mayor número de puntos que toquen la pendiente positiva, tanto para tamaño como para tiempo. 4.1.11 LISTA DE CHEQUEO DE REVISION DE DISEÑO 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 diseño. Por lo general casi todos los errores de tipo lógico, 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 reducción de tiempo en la búsqueda 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, inicialización de variables, pares entre llaves o corchetes, apuntadores y operadores lógicos. Ambas revisiones se llevan a cabo antes de la fase de compilación, si realizamos una buena etapa de revisión tanto de diseño y código, el número de errores en la fase de compilación puede tender a cero. Lo mismo puede ocurrir en la fase de pruebas, ocasionando una disminución 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 interactúe con el sistema o programa, señalando específicamente que debe hacer el usuario y la respuesta que da el sistema. Prácticamente es una manual operacional de la utilización 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 especificación de estados.

28

4.1.14 PLANTILLA DE ESPECIFICACION DE ESTADOS Este tipo de plantilla tiene como finalidad, la de representar el diseño 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 módulos de nuestro programa, el flujo que toman cada y las transacciones que existen entre los mismos. Así como también el flujo de error que pueda ocurrir. 4.1.15 PLANTILLA DE ESPECIFICACION LOGICA Nos provee la interacción que existe dentro de nuestro programa, dicho de otra forma. Tiene como finalidad de detallar específicamente la funcionalidad de cada módulo, cada objeto y el programa principal de nuestros programas. Cuenta con una notación definida y adaptable a cualquier tipo de lenguaje de programación, para poderlo exportar. Dicha plantilla debe ser llenada a mano, ya que todo lo que se escribe en ella es pseudocódigo.

29

5 PLANTILLA ESTANDAR DE CONTEO DE LOC’s (R1) Como se mencionó en la sección 4.1.6, esta plantilla tiene como finalidad, contar líneas lógicas de los métodos 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 programación, debe realizarse una nueva plantilla. No puede se modificada mientras se encuentre realizando el PSP. Nombre/definición: Capitaine Aggi Oscar Lenguaje: C Autor: Castro Careaga Luis F. Fecha: 24/10/05 Tipo de Conteo

tipo Comentarios

Físico / Lógico Tipo de Instrucción Incluido Comentarios Ejecutable Si No ejecutable Si Declaraciones Si, nota 1 Directivas del compilador Si Comentarios No En líneas propias No Con el fuente No Encabezados No Líneas en blanco No Aclaraciones Ejemplos / Casos Nulos No continues, no-ops Instrucciones vacías Si “;;”, ;’s solos, etc. Intanciadores genéricos Begin...end Si, nota 3 cuando estén en código ejecutable Begin...end Si, nota 3 cuando estén en código no ejecutable Prueba de condiciones Si Evaluación de expresiones Si Cuando se use como argumentos de

subprogramas Símbolos End No Cuando terminen instrucciones ejecutables Símbolos End No Cuando terminen declaraciones o cuerpos Then, else, otherwise Si, nota 4 Elseif Si, nota 4 Palabras clave No División de procedimientos, interfaz,

implementación Etiquetas No Destinos de saltos cuando estén en líneas

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

variable o parámetro 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 sección 4.1.7, esta plantilla tiene como finalidad estandarizar cada método o función de nuestros programas, nos presenta ejemplos de cómo 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. Propósito 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 investigación 1 Tarea: PSP2A Fecha: **/**/**** Descripción: 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 Reutilización

Describe cómo se usa el programa. Proporciona un formato de declaración, tipos y valores de parámetros y límites de parámetros. Proporciona advertencias de valores ilegales, condiciones de sobreflujo u otras condiciones que podrían resultar potencialmente en una operación 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 carácter.

Ejemplo de identificadores

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

31

Plantilla de Estándar de Codificación R2, Continuación

Comentarios Documente lo suficientemente el código para que el lector pueda comprender

su operación. Los comentarios deben explicar tanto el propósito como el comportamiento del código. Comente la declaración de las variables para indicar su propósito.

Buen Comentario /*Se lee una linea de codigo*/ if (carácter==’{’) ...

Mal Comentario //cuenta un //un operador { if (carácter==’{’)

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 sección.

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 fáciles de leer. Separe cada construcción del programa con al menos un espacio.

Sangrías Coloque sangrías en cada nivel de bloque con respecto al anterior. Llaves que abren y cierran deben estar en una sola línea y alineadas una con la otra.

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

Mayúsculas Todos los defines van en mayúsculas. Todos los otros identificadores y palabras reservadas van en minúsculas. Los mensajes que son salidas al usuario pueden tener mezcla de mayúsculas y minúsculas de tal manera que hagan más limpia la presentación al usuario.

Ejemplo de Mayúsculas #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 también el tiempo que se tarda en remover cada uno de los defectos. Los defectos producidos por KLOC’s en cada uno de los programas. Se llena a partir de la bitácora de registro de defectos, tomando el conteo y tiempo de eliminación de defectos, los cuales se introducen en el diseño y se remueven en la compilación y pruebas, defectos introducidos en la codificación y removidos en compilación 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 desempeño del alumno, a lo largo de las primeras seis tareas, se formulan una serie de preguntas en cuanto a estimación de tamaño, estimación de tiempo, calidad. Evalúa 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 Tamaño Estimación de Esfuerzo Objeto Número

Planeado Número

Real Esf. Est. por

Objeto Esfuerzo

Estimado Parrafos 18 18 5 90 Graficas 16 14 5 80 Tablas 9 6 5 45 Análisis de Graficas / Tablas

25

20

5

125

Párrafos para el Reporte final

4

9

5

20

Total 360

Datos de Esfuerzo Fase Tiempo Plan. Tiempo Real Planeación 20 18 Desarrollo 360 227

Post Morten

15 25

Total 395 270

34

8.2 Bitácora de Registro de Tiempo R4

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

de Interrupción

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

Análisis de la Exactitud de

Estimación de LOC

1/29/06

21:44

22:35

51

Desarrollo

Análisis de la Exactitud de

Estimación de Tiempo

1/30/06

20:15

20:57

41

Desarrollo

Análisis de los Defectos

Introducidos y Eliminados por

Fase [D24]

1/31/06

18:37

18:56

19

Desarrollo

Análisis de Defectos

Introducidos y Eliminados por

Fase [R3] 1/31/06

20:12

20:27

15

Desarrollo

Análisis de Defectos

Encontrados por el

Compilador 2/02/06

11:37

12:30

53

Desarrollo

Áreas de más 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 # Propósito Para guiar el análisis 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 bitácora de registro de tiempo

1 Planeación Estime el tamaño del reporte • número de párrafos de análisis • Número de tablas / gráficas de datos a crear Estime el esfuerzo basándose en el tamaño del reporte Registre los estimados en la Forma de Resumen del Plan Registre el tiempo de planeación en la bitácora de tiempo

2 Desarrollo Para cada pregunta de análisis • genere una gráfica o tabla de datos • analice la tabla / gráfica y otros datos del proceso • escriba un párrafo de análisis Revise el desempeño completo Identifique las áreas de mejora Defina metas cuantificables Determine qué cambios al proceso son necesarios Escriba un análisis de mejora de desempeño Registre el tiempo de desarrollo en la bitácora de tiempo

3 Postmortem Mida el tamaño del reporte • número de gráficas / tablas • número de párrafos de análisis Complete la forma de resumen del plan Registre el tiempo de postmortem en la bitácora de registro de tiempo

Exit Criteria Reporte R4 completo Resumen del Plan completo Bitácora de registro de tiempo completa

36

8.4 Análisis de la Exactitud de Estimación de LOC

1. Analice la tendencia en la exactitud de estimación de tamaño 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 mayoría de los programas, la estimación en el tamaño ha sido buena, en el caso del programa 5 se puede ver que la grafica 2 muestra un porcentaje negativo, en comparación a los demás programas, al ser un programa un poco complicado y no tener código BASE, la estimación fue calculada como en el primer programa, al tanteo, pero a medida que se avanza gracias a la reutilización de código y el uso la tabla SIZE ESTIMATE del stuwbk, se puede tener un margen de estimación de tamaño más exacto. 2. Para cada uno de los programa 4, 5 y 6, ¿cómo se comparan las LOC de objeto

estimadas con las LOC de objeto reales?

comparacioón de loc´s

0

50

100

150

200

250

300

350

4 5 6

num. programa

num

. loc

´s

locs´estimadasloc´s reales

Para el programa 4 , la diferencia fue muy pequeña, por que se trataba de un programa pequeño, a pesar que en el programa 5 todo el código fue nuevo, también se tuvo una buena aproximación, el programa 6 no tuvo una buena aproximación, como podemos ver en la gráfica.

37

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

cercanas las LOC de objeto reales, determine por qué. El mayor problema fue en el programa 6, se tenia suficiente código BASE pero también se tuvo que realizar mucho código nuevo, y no se tuvo una buena aproximación, otra cosa que influyo fue perder el ritmo de trabajo entre el programa 5 y el 6, ocasionando una mala estimación, como se ve en la grafica anterior, la diferencia es de un 30% aprox. Muy mala en comparación con los programas anteriores. 4. Basado en el análisis anterior, ¿cuál es la mejor cosa que usted podría hacer para

mejorar su exactitud en la estimación? Hacer un análisis detallado del programa que se va ha resolver, cada uno de los puntos importantes, y ver los valores estadísticos de los programas anteriores para tener una mejor aproximación, de lo que se quiere estimar. La reutilización de código también influye en que tan buena sea la estimación, ya que solo se crean algunos módulos y es mucho más fácil estimar el tamaño. 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 método A. ¿Son útiles para la estimación 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 método A debemos de tener una correlación (R^2) mayor a 0.7, una B1 entre 0.7 y 1.3 y una B0 relativamente pequeña en comparación de las LOC´s Estimadas. Si vemos la tabla del método PROBE podemos darnos cuenta de que a pesar que la correlación se encuentra dentro del rango 0.93, la B1 esta fuera del rango 1.58, la B0 tiene un valor negativo lo que ocasionaría una productividad negativa y nuestro Estimado también es negativo. El método B tiene las mismas condiciones que el método A, si observamos la tabla se tieneR^2=0.82<0.7, B1=1.24 que es mayor a 0.7 y menor1.3 y nuestra B0=3.53 que es relativamente pequeña a nuestro estimado E=4.

38

8.5 Análisis de la Exactitud de Estimación de Tiempo

1. Analice la tendencia en la exactitud de estimación de esfuerzo en los seis primeros

programas.

Estimación 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 estimación se encontraba en un rango, yo consideraría que es bueno, la gráfica muestra que en programa 6, la estimación 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 comparación con los demás programas, otra cosa que influye en la productividad es el grado de dificultad que tenga cada programa y que tanto código BASE se tenga para reutilizarse, también 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 información para el desarrollo de sus programas. 3. Para los primeros seis programas, si la productividad varió, ¿los cambios están

relacionados con la cantidad de tiempo utilizando en corregir los defectos en las fases de compilación 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 compilación se ha mantenido estable de cierta forma en un rango no mayor al 10% del tiempo requerido para la realización del programa, la fase de pruebas a ido disminuyendo de un 27% hasta caer entre el 10% y 5%. La fase de compilación y pruebas, si influye en que tan buena productividad se tenga, ya que al tener más 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 número de LOC´s (N&C) VS Tiempo total de todas la fases. 4. ¿Cómo fue afectada la exactitud de sus estimados de tiempo por la calidad de sus

estimados de tamaño?

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

Estimación Tamaño 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 Tamaño

%Er

ror T

iem

po

Como podemos ver en las gráficas, los picos muestran que se tuvieron un error de estimación de tamaño y de estimación de tiempo muy alto, lo que provocó que la calidad en la exactitud fuera pésima 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 Tamaño VS Tiempo. La fase de compilación y pruebas son las que afectan que ocurra esto, probablemente nuestra estimación en tamaño fue mala.

8.6 Análisis de los Defectos Introducidos y Eliminados por Fase [Tabla D23]

1. ¿Qué tipos de defectos se introducen más en la fase de diseño?

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

Como se puede ver en la gráfica, la mayoría de los defectos producidos son los de tipo 40 (Asignación) y los de tipo 80 (funciones o lógicos). 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 LOC´s y esto ocasionó que existiesen demasiados errores de este tipo.

41

2. ¿Qué tipos de defectos se introducen más en la fase de codificación?

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

Como se podrá ver en la grafica, los errores de asignación (40), y los errores de sintaxis (20), son los más predominantes, durante esta fase. También se presentan otros tipos de errores como son los de componentes o configuración (30) y los errores de funciones y lógicos (80). 3. ¿Qué tipos de defectos se eliminan principalmente en la fase de compilación?

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 mayoría de los defectos de asignación (40), también son eliminados durante esta fase, al igual sucede con los de funciones o lógicos (80), los de componentes o configuración (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 lógicos (80), de asignación (40), pero en comparación con la fase de compilación es mucho menor, ya que en la fase de compilación, la mayoría de ellos son filtrados, y solo un número pequeño de ellos se presentan durante la fase de pruebas.

42

8.7 Análisis 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 eliminación de defectos, basándose 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 codificación, pero se tarda un mayor tiempo en resolver los defectos que se introducen en el diseño a pesar de que son menos. 2. ¿Qué categoría tiene el tiempo promedio de eliminación más grande? El tiempo promedio de eliminación por programa es de un 37%, la fase de compilación presenta un promedio de 39%, en esta fase se eliminan los errores de sintaxis en su totalidad, y también eliminamos la mayoría de los errores de tipo 80, que son los más difíciles de resolver, también la mayoría de los defectos de asignación (40), son resueltos durante esta fase. 3. ¿Qué categoría tiene el tiempo total de eliminación más 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 (Asignación). 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 Análisis 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 diría en un 80% de eficiencia, también para los defectos de asignación (40), pero para todos los demás 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 línea también 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 ejecución.

44

8.9 Áreas de más Alta Prioridad para Mejoras en la Segunda Mitad del

Curso

8.9.1 PLANEACIÓN

% Planning Time

02

46

810

1214

1618

1 2 3 4 5 6 7 8 9 10

Program Number

%

Su desempeño actual Como podemos ver en la grafica, la fase de planeación no ha sido muy buena, sobre todo en el programa 5 y el programa 6 se encuentran en un porcentaje de planeación de un 16% aproximadamente, en comparación con los demás programas que están entre un 6% y 8%. Lo que provoca que el tiempo en esta fase en porcentaje con las demás (diseño, codificación, compilación, pruebas y post morten), sea mayor. Lo ideal es que la fase de planeación no sea mayor a un 5%. Ya que no debe de tardar más de 10 minutos en el desarrollo de la misma. Su desempeño futuro deseado Una de mis principales metas es la de bajar el error de estimación en el tiempo, esto es que nuestro tiempo en planeación no exceda los 10 minutos (no exceda el 5% de tiempo total de desarrollo del programa) ya que tengo muchos problemas para hacer un cálculo aproximado de dicho error, comprender mejor el uso de la tabla SIZE ESTIMATE y ser más disciplinado. Sus metas de mejora Hacer un análisis detallado de los requerimientos del programa y que no exedan de 10 minutos, para que la fase de diseño conceptual, se estimen bien el tamaño de los módulos, otra propuesta es la de estimar cuantas LOC´s contendrá cada función de los módulos, ya que tengo un margen de 25% a 30% de error en cuanto al tamaño de cada modulo. Para ser mas preciso y ahorrar tiempo en las otras fases.

45

8.9.2 DISEÑO

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 desempeño actual La gráfica muestra que en el programa 5 no se tuvieron muchos errores en la fase de diseño (5 errores para ser exactos) en comparación 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 drástico. Su desempeño futuro deseado Con la modificación en la fase de planeación, se cree que para las siguientes tareas se podrá hacer un mejor diseño, provocando que los errores se reduzcan de un promedio de 20 errores por KLOC a no mayor de 7 errores por KLOC . Con la utilización del PSP2 , se podrá controlar mejor los errores durante esta fase. Sus metas de mejora Para la segunda parte del proceso entran la revisiones (diseño y código), lo cual mejorara el proceso y se podrán filtrar los errores que se encuentra en esta fase, lo que provocara que se tenga una disminución de 20 errores por KLOC a un promedio no mayor a 9-5 errores por KLOC.

46

. 8.9.3 CODIFICACIÓN

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

Desempeño actual La gráfica muestra que el porcentaje de error se ha mantenido constante, con aproximadamente 20 errores por KLOC´s, 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 aún puede disminuir, como aparece en el plan de la tarea 7A que esta en 27 LOC/Hora a la Fecha. Desempeño 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 gráfica anterior es que a pesar que los errores durante todos los programas se mantiene constante, aún siguen siendo altos, ya que tengo un promedio de 36 errores por KLOC´s, lo que espero es que se encuentre máximo de 20 errores por KLOC´s. Sus metas de mejora Lo que modificaría en el proceso es que una vez acabada la parte de codificación es revisar el código con calma y principalmente, lo que es el paso de parámetros 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 KLOC´s, que actualmente es la media que tengo a un promedio de 12-16 errores por KLOC´s.

47

9 REPORTE DE LA SEGUNDA PARTE DEL PROCESO R5 Al igual que el R4 se evalúa el desempeño del alumno, en este reporte se compara la productividad entre la primera parte del proceso y la segunda parte, el indice de estimación de defectos, y como a mejorado la estimación de tamaño y código de los programas, así como también 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 Párrafos 28 22 5 140 Graficas 15 6 5 125 Tablas 9 10 5 45 Análisis de Graficas / Tablas

25 16 5 125

Total 435

Effort Data Phase Plan Time Actual Time Planeación 10 13 Desarrollo 320 434 Post Mortem

15 11

Total 345 458

48

9.2 Bitácora 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 Análisis de la Exactitud de Estimación 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 estimación de tamaño en la última parte del proceso no fueron muy buenos a excepción de la TAREA 7A, ya que se tuvo una diferencia de 50 LOC aproximadamente por programa, en la gráfica podemos constatar que durante todo el proceso, la estimación de tamaño fue mi principal problema, el cual no pude resolver. Lo único bueno que puedo atribuirle a mi desempeño en esta parte del proceso, es que al menos el error de estimación de tamaño se mantuvo constante durante las ultimas 3 tareas.

50

2. ¿Qué tan frecuente se esta dentro del intervalo de predicción estadístico 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 predicción, se utilizo el método B para la estimación de tamaño, lo curioso es que a pesar de que se estuvo dentro del intervalo tuve un Error grande en cuanto al cálculo de las LOC Totales Reales de cada programa. Esto es debido a que el intervalo de predicción, solo sirve para calcular cual método nos conviene más para hacer la estimación del tamaño 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 realización de cada uno de los programas. 4. ¿Hay una tendencia a juzgar mal el tamaño relativo de los objetos? Si, ya que aun no se pudo definir una buena aproximación en cuanto al tamaño de los módulos, a pesar que se contaban con la ayuda de los datos históricos, 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 estimación de tamaño de cada modulo de los programas 7A-10A, podemos ver que la estimación es pésima para la mayoría de los módulos. La TAREA 7A tiene un %Error menor al 50% de Tamaño por módulo, a pesar de esto fue la tarea con un Error de Estimación de tamaño 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 tamaño de 2 de los módulos (calculos.c y rango.c), nuestra productividad aumento a 60 LOCs/Hora, que era lo que se quería. 5. ¿Se pudieron calcular tamaños relativos usando datos históricos? ¿Sí? Los datos históricos nos mostraron que existía una tendencia a subestimar los tamaños de los módulos de los programas, nos fueron de gran ayuda en la estimación del tamaño de los módulos para las tareas 7A, 8A, 9A y 10A. Para calcular el tamaño de cada nuevo objeto, necesito usar los datos históricos, y este nos lo va dando la hoja Locmeth, y los intervalos de predicción (UPI, LPI) que nos muestra el tamaño de los objetos que hemos realizado. Principalmente me base en los intervalos de predicción para hacer la estimación del tamaño de los módulos del programa. Podemos ver en la tabla que el total de nuestras LOC´s N&C cayeron dentro del intervalo de predicción para cada una de las tareas, pero esto no nos garantiza que este tamaño sea el optimo, por eso también tenemos que tomar en cuanta nuestro Locmeth donde podemos hacer un calculo del tamaño estimado de LOC por método, tomando en cuenta los tamaños de los métodos 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 estimación del tamaño del historial. ¿Qué tan realistas son las metas de estimación del tamaño?

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 método, el error tendería a estabilizarse, ahora si analizamos todas la tareas a excepción de la 2A,3A y 8A el Error de estimación 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 estimación más precisa, lo ideal sería que dicho error estuviera entre un 10% y 5%, pero no se puede predecir el futuro y ser tan exacto, e incluso es muy difícil alcanzar la meta más razonable. 7. ¿Como se puede cambiar el proceso para alcanzar estas metas? Uno de los cambios que podría hacerle al proceso sería que cuando analice cada objeto, ver cada una de sus funciones y de ahí empezar hacer un conteo de las líneas que podría tener cada función pero con más detenimiento y atención de lo que lo hago hasta ahora, y así obtener el conteo para todo el objeto.

53

9.4 Análisis de la Exactitud de Estimación 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 comparación con las primeras tareas el Error de Estimación de Tiempo bajo considerablemente, manteniéndose entre un 15%-25% del tamaño 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 estimación de Error fue buena en comparación con las TAREA 8A y TAREA 9A la mejor estimación 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 predicción estadístico 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 predicción con un margen de error de 50-20 minutos y esto me dice que el tiempo en cuanto a la realización de las tareas disminuyo, lo que contribuyo a tener una mejor estimación para la realización de los programas, otra cosa que fue de gran ayuda, fueron las revisiones de diseño y código, gracias a ellas se redujo considerablemente el tiempo en las fases de compilación 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 Diseño y Código, 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 más conveniente para tener una buena productividad es la de tener una buena estimación de las LOC(N&A) y una buena estimación 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 Diseño y Código, ya que la mayoría de los errores se corrigieron en estas Fases y se redujo el tiempo de corrección de errores en las fases de Compilación 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 tamaño? ¿Ayudaría la regresión múltiple? La estimación de tamaño es un punto crucial a partir del cual se obtiene la estimación del tiempo, y si la estimación de tamaño tiene un gran error seguramente la de tiempo será afectada. Y por supuesto que me ayuda la regresión múltiple a obtener un intervalo en el cual carea la estimación de tiempo con una muy buena exactitud. Como conclusión tenemos que la estimación de tiempo no afectaron las estimaciones de tamaño, en cambio la estimación de tamaño, si afecta a la de tiempo. 6. Basado en la exactitud de estimación del tiempo del historial. ¿Qué tan realista son las metas de estimación 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 estimación 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 sería que este Error se encontrara dentro del 10% al 5%, si vemos detalladamente la tabla se aprecia que el tiempo de estimación 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 método PROBE, el SIZE ESTIMATE y las revisiones de diseño y código. Esta parte fue la que pude dominar más, ya que el Error de estimación disminuyo considerablemente en la segunda parte del curso. 7. ¿Como se puede cambiar el proceso para alcanzar estas metas? Considero que los errores de estimación de tiempo son pequeños, por lo que convendría seguir el proceso, ya que nos ha dado buenos resultados. Lo único que cambiaría en el proceso, es que fuera más rápido en el llenado de las plantillas, ya que considero que dentro de las demás fases me ha gustado como se han desarrollado.

57

9.5 Análisis de Defectos y Yield 1. ¿Qué tipo de defectos introdujo durante el diseño y la codificación?

Tipo Diseño Código 20 1 13 30 0 4 40 19 24 50 4 1 60 3 1 70 1 0 80 13 5

Total 41 48 La tabla muestra una descripción detallada de los tipos de defectos que se presentaron a lo largo del curso de PSP durante las fases de diseño y código. Los errores que se presentaron más durante la fase de diseño, fueron los errores de asignación (40), y los errores de funciones y lógicos (80), son los más predominantes durante esta fase. Para la fase de Código los defectos de sintaxis (20) son eliminados durante esta fase, en ninguna otra fase se eliminan. Vemos que la mayoría de los defectos de asignación (40), también son eliminados durante esta fase, al igual sucede con los de funciones o lógicos (80) y los de componentes o configuración (30). Podemos ver que se eliminan más errores durante la fase de código que durante la fase de diseño. 2. ¿Qué tendencias son evidentes en defectos/KLOC’s encontradas en las revisiones, en la compilación y las pruebas? La finalidad de las revisiones es la cachar la mayor parte de los defectos, para que de esta forma al pasar a las fases posteriores, los defectos sean muy pocos y se ahorre el tiempo de ejecución de estas fases. Así como también para aumentar la calidad en la fase de desarrollo. Vemos que la cantidad de defectos/KLOC durante la revisión de diseño esta por abajo de 20 KLOC’s para las últimas 2 tareas y la cantidad de defectos para la revisión de código es menor 15, lo cual se considera que es bueno.

Defects Removed in Design Review

0

5

10

15

20

25

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

Defects Removed in Code Review

02468

10121416

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

58

Para las fases de compilación y pruebas, gracias a las revisiones de diseño y código, el número de efectos disminuyo considerablemente, podemos ver en las graficas que el número de defectos para la fase de compilación disminuyo de 20 KLOC’s a 7KLOC’s para la tarea 10A. Y para la fase de pruebas en los últimos 3 programas se mantuvo un promedio de 7 defectos/KLOC. Para finalizar la tendencia consiste en dejar cada vez menos defectos, al pasar a una nueva fase, para aumentar la calidad del producto y el tiempo de desarrollo.

Defects Removed in Test

0

5

10

15

20

25

30

35

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

Defects Removed in Compile

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

3. ¿Qué tendencias son evidentes en el total de defectos/KLOC? El número de defectos en la primera mitad del curso, en especial para el primer programa fue muy grande, conforme se fue avanzando en el proceso, tendió a regularizarse, vemos que para la tarea 7 se volvió a elevar, esto fue a que se tuvo un Yield del 40%, en esta tarea, pero gracias a las revisiones de diseño y código, el número de defectos, fue disminuyendo nuevamente para las últimas tres tareas, como podemos ver en la grafica, ya a partir de la tarea 10, se pudo obtener un Yiel del 57..4% y un máximo de defectos de 20 Def/KLOC, que era la meta a llegar.

Total Defects

0102030405060708090

100

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

59

4. ¿Cómo se comparan sus tasas de defectos removidos (en defectos removidos/KLOC) con la revisión de diseño, la revisión de código, la compilación y las pruebas? Lo que ocurría en la primera mitad del proceso, era que todos defectos eran encontrados en las fases de compilación y pruebas, debido a que en la segunda parte del proceso se introdujeron las revisiones de diseño y código, pudimos filtrar la mayoría de los defectos en estas 2 fases y al llegar a la fase de compilación y a la fase de pruebas, eran muy pocos los defectos a ser corregidos.

Fase Núm. Defectos Removidos

Tasa de Defectos Removidos

DLDR 9 10% CDR 9 10% COMPILE 43 + 8=51 56.6% TEST 14 + 7 =21 23.4% TOTAL 90 100%

En la tabla podemos ver el número total de defectos removidos, en las cuatro fases de revisión de diseño, código, compilación y pruebas. Para la segunda parte del proceso, vemos que durante la fase de compilación y pruebas, los defectos fueron mucho menores en comparación con los encontrados en las revisiones, 8 defectos para compilación y 7 defectos para pruebas. El promedio general del Yield para las últimas 4 tareas es de 54.55%, lo ideal debió ser que estuviera por arriba del 60%, pero se debió que durante la tarea 7 el Yield fue del 40%, lo cual no fue muy bueno. 5. ¿Cuáles son sus influencias de defectos removidos por Revisión de Diseño, Revisión de Código y Compilación contra Pruebas Unitarias? Debido a que las pruebas Unitarias son realizadas después de las revisiones de Diseño y código, y una vez terminada la fase de compilación, esto ocasiona que el número de defectos encontrados durante la fase de pruebas disminuya considerablemente y sea mucho menor, que los defectos encontrados en las fases anteriores. 6. ¿Cuáles son sus tasas de revisión (en LOC revisadas/hora) para revisiones de diseño y de código? Podemos ver en la grafica la tendencia de ir aumentando el número de LOC´s revisadas por hora durante las revisiones de diseño y código.

60

LOC Reviewed per Hour

050

100150200250300350400450500

1 2 3 4 5 6 7 8 9 1

Program Number

LOC

/Hou

r

BothCDRDLDR

En la tabla podemos ver la tasa de revisión de diseño y la tasa de revisión de código, si tomamos por separado los valores de las tasas, tenemos que para la revisión de diseño es de 272 LOC’s revisadas por hora y para código 261 LOC’s por hora. Si tomamos la tasa de ambas tenemos que 133 LOC’s hora en promedio, lo que se considera una buena cantidad de LOC’s revisadas durante una hora. Programa Tasa de Rev. Diseño

(LOC revisadas/hora) Tasa de Rev. Código (LOC revisadas/hora)

Tasa de Rev. Ambas DLDR VS CDR

7 162.9243 183.5294 86.30705 8 265.7048 246.1697 127.7822 9 230.5006 224.6809 113.7768 10 430.3963 392.4731 205.2804

7. ¿Hay alguna relación entre el Yield y la tasa de revisión (en LOC revisadas/hora) para revisiones de diseño y código? La relación que se puede ver en la tabla es que a medida que aumenta el Yield aumenta el número de LOC’s de las revisiones por hora. Programa Tasa de Rev. Diseño

(LOC revisadas/hora)

Tasa de Rev. Código (LOC revisadas/hora)

Tasa de Rev. Ambas DLDR VS CDR

Yield actual (%)

7 162.9243 183.5294 86.30705 40 8 265.7048 246.1697 127.7822 62.5 9 230.5006 224.6809 113.7768 62.5 10 430.3963 392.4731 205.2804 57.4

61

8. ¿Hay una relación entre el Yield y el A/FR para los programas del 7 al 10? Podemos ver en ambas graficas que la relación que hay entre el Yield y el A/FR, para la segunda parte del proceso, es que a medida que aumentaba el Yield, también aumentaba el A/FR.

Defect Removal Yield

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

Program Number

Yiel

d %

Apppraisal Cost of Quality

0

5

10

15

20

25

30

35

40

1 2 3 4 5 6 7 8 9 10

Program Number

App

rais

al C

ost %

El Yield siempre crece a excepción de la tarea 10A donde disminuyo un poco. Esto quiere decir, que nuestro promedio del Yield se mantuvo arriba del 60%, provocando que la mayor parte de los defectos se eliminaran antes de entrar a la fase de compilación. También Podemos ver que el A/FR muestra una tendencia creciente, a excepción de la tarea 8A, esto nos dice que para la mayoría de las tareas de la segunda parte del proceso los valores del A/FR fueron mayores a 1 (4 para ser exacto). En consecuencia, durante las revisiones de diseño y código el tiempo fue mucho mayor al empleado durante las fases de compilación y pruebas.

62

9.6 Preguntas sobre la calidad 1. ¿Se alcanzaron las metas de la segunda mitad de proceso? ¿Por qué si o porque no?

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

Si, por que la finalidad era de reducir los Errores a menos de 20 defectos KLOC´s, ya que siempre me mantenía un poco arriba de este margen, gracias a las revisiones de Diseño y Código pude entrar en lo recomendado, aunque me hubiera gustado estar en 10 Defectos por KLOC´s, pero no se pudo. 2. ¿Cómo se puede juzgar en el momento la calidad del producto final en el ciclo de desarrollo? Gracias al proceso PSP, los productos que se realizan tienen un alto grado de calidad, debido a que se lleva una disciplina estricta y constante, gracias a que se encuentra dividido en varias fases, lo que permite al individuo tener un control detallado del programa que esta realizando, disminuyendo considerablemente su margen de Error entre cada programa, dando así un producto confiable y seguro. 3. ¿Se están encontrando los defectos en las revisiones de código y de diseño?

Defect Removal Yield

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

Program Number

Yie

ld %

63

Si, para las ultimas 3 tareas el promedio del Yield se mantuvo en un 60%, esto quiere decir que durante las revisiones de Diseño y de Código se pudieron eliminar mas de la mitad de los defectos de los programas, en mi caso de 23 defectos por KLOC puedo filtrar 15 en las revisiones, lo que es un muy bueno por que se disminuye considerablemente las fases de Compilación y Pruebas. 4. ¿Qué se puede hacer para que el proceso sea mas efectivo y eficiente? Una de las propuestas que considero eficiente, sería realizar el proceso como se ha hecho pero a un nivel más bajo, esto es realizándolo a nivel modular y no a un nivel de programa, el problema que esto implicaría sería que se llevaría mucho más tiempo de cada modulo, pero la calidad del producto aumentaría considerablemente. 5. Basado en los datos históricos. ¿Que metas de calidad son realistas?

Failure Cost of Quality

0

5

10

15

20

25

30

35

40

1 2 3 4 5 6 7 8 9 10

Program Number

Failu

re C

ost %

Los costos de los defectos de los últimos programas además del promedio de densidad de defectos (19.75 Def/KLOC) de los últimos 4 programas, nos dice que podemos estar por debajo de esta densidad ya que la tendencia era a estar debajo de 20 Def/KLOC que es una densidad aceptable. Una de mis metas seria estar debajo de los 10 Def/KLOC. Esto incrementaría considerablemente la calidad de mis programas, así como también la productividad y el tiempo de realización.

Def. inj. in Code Def/KLOC 0 78.125 23.48993 24.79339 20.83333 19.41748 18.18182 25.64103 22.55639 22.72727 8.219178 263.9848

64

6. ¿Como se puede cambiar el proceso para alcanzar estas metas? Como ya lo había dicho al realizar este proceso de desarrollo a nivel modular se haría mas simple y mas riguroso el proceso de desarrollo lo que nos llevaría a tener menos errores al controlar cosas mas pequeñas no tan grandes donde hay menos control.

CONCLUSIONES: PSP es un proceso el cual una vez que te haz familiarizado, es muy fácil de utilizar. Al principio cuando comencé a utilizar el proceso se me hacia muy difícil pero conforme fui avanzando mis dudas fueron resolviéndose. Prácticamente el proceso te lleva de la mano durante el desarrollo de un sistema (software). Si tuviera la oportunidad de desarrollar un sistema es muy probable que utilizara PSP para su desarrollo. El proceso me ayudo a ser mas disciplinado y ver cuales son mis errores a la hora de de iniciar un proyecto y poder corregir esos errores para no volverlos a cometer durante el desarrollo del proyecto. Una de las principales ventajas, que desde mi punto de vista, le veo al PSP, es que no únicamente el proceso se puede utilizar para el desarrollo de sistemas, sino que también podemos utilizarlo para desarrollar cualquier producto, el cual debe ser estructurado y su tiempo de desarrollo se encuentra condicionado a cierta fecha de entrega. En la actualidad en nuestro país, existen muchas empresas de desarrollo de software, pero no se si alguna de ellas utilice PSP o TSP para desarrollar sus sistemas. Una de los principales problemas cuando los proyectos son cancelados es debido a que no son diseñados bien o el sistema no hace lo que el cliente desea. A pesar de que existen métodos para desarrollo de sistemas como UML o RUP creo que si utilizaran PSP o TSP, sus productos tendrían una mejor calidad y el tiempo de desarrollo de los sistemas disminuiría considerablemente.

BIBLIOGRAFIA: [1] A Discipline for Software Engineering Humphrey, Watts. S Addison Wesley, 1996. [2] Programación en C, Metodología, algoritmos y Estructura de Datos Joyanes Aguilar Luis Zahonero Martínez Ignacio McGraw-Hill, 2001. ISBN: 84-481-3013-8 [3] Como programar en JAVA Deitel, Harvey M. Deitel, Paul J. Pearson Educación. México, 2004 ISBN: 970-26-0518-0