Desarrollo de sistemas con PSP Y TSP

Proyecto de Investigaci´ on Licenciatura en Computaci´ on

Aida Alvarado Ju´ arez

Eduardo Rodr´ıguez Flores Asesor

M´ exico D.F. 17 de agosto de 2008

Alfonso Mart´ınez Mart´ınez Coordinador de la licenciatura

1

´Indice general

1. PSP Proceso Personal de Software

1

´ 1.1. INTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2. OBJETIVOS DEL PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

´ DEL PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. DEFINICION

4

1.4.

FASES DEL PROCESO PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.4.1. PSP0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.4.2. PSP0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.4.3. PSP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.4.4. PSP1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.4.5. PSP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.4.6. PSP2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.5. ENTRENAMIENTO DEL PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.5.1. TAREA 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.5.2. TAREA 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

1.5.3. TAREA 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

1.5.4. TAREA 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

1.5.5. TAREA 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

1.5.6. TAREA 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

1.5.7. TAREA 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

1.5.8. TAREA 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

1.5.9. TAREA 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

1.5.10. TAREA 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

i

´INDICE GENERAL

ii

1.6. RESUMEN DEL PLAN DEL REPORTE R5 . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

1.6.1. GU´IA DEL REPORTE R5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

1.6.2. RESUMEN DEL PLAN DEL REPORTE R5 . . . . . . . . . . . . . . . . . . . . . . .

39

´ 1.6.3. BITACORA DE REGISTRO DE TIEMPO R5 . . . . . . . . . . . . . . . . . . . . . .

40

´ ´ DE LOC . . . . . . . . . . . . . 1.6.4. ANALISIS DE LA EXACTITUD DE ESTIMACION

41

´ ´ DE TIEMPO . . . . . . . . . . 1.6.5. ANALISIS DE LA EXACTITUD DE ESTIMACION

45

´ 1.6.6. ANALISIS DE DEFECTOS Y DEL YIELD . . . . . . . . . . . . . . . . . . . . . . . .

49

´ 1.6.7. ANALISIS DE CALIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

1.7. Criterios de Evaluaci´ on

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

1.8. Sugerencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

2. TSP EQUIPO DE PROCESO DE SOFTWARE

62

´ 2.1. INTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

2.2. OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

2.3. TALLER DE LANZAMIENTO TSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

2.3.1. Junta 1 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

2.3.2. Junta 2 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

2.3.3. Junta 3 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

2.3.4. Junta 4 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

2.3.5. Junta 5 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

2.3.6. Junta 6 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

2.3.7. Junta 7 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

2.3.8. Junta 8 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

2.3.9. Junta 9 del Taller de Lanzamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

2.4. FORMAS Y RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

2.4.1. Forma SUMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

2.4.2. Forma TASK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

90

2.4.3. Forma Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

2.4.4. Forma SUMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

Cap´ıtulo 1

PSP Proceso Personal de Software

1

1.1.

´ INTRODUCCION

Como licenciados en computaci´ on, en nuestra vida diaria usamos las computadoras y d´ıa con d´ıa las vamos renovando con las nuevas t´ecnologias, pues, de la misma forma, nosotros debemos de renovar nuestra forma de craer los sistemas para evitar caer en los mismos errores de anta˜ no. Para lograr tener un mejor control o manejo en nuestros sistemas hemos estudiado un proceso personal para desarrollo de software (PSP) para tener pasos definidos, formas y est´andares en los sistema. Al estudiar el PSP, estudiamos un proceso de auto mejora; dise˜ nado para ayudarnos a controlar, administrar y mejorar la forma en que trabajamos, ya que nos provee una metodolg´ıa para planear y dar un seguimiento a su trabajo para incrementar su productividad y la calidad de los sistemas de software. El PSP es la base para poder trabajar en equipo.

2

1.2.

OBJETIVOS DEL PSP

Conocer y utilizar las medidas de analisis del PSP. Organizar las ideas de la creacion de un programa mediante la utilizaci´on de fases. Conocer las plantillas de uso en el PSP para la elaboraci´on de los programas con mayor eficencia. Saber hacer una estimaci´ on acertada. Tratar de eliminar los errores en las fases en las que por lo regular siempre se presentan (compilaci´on y pruebas). Mejorar el tiempo de desarrollo al eliminar los errores. Tener una calidad y produccion eficiente, cuando eliminamos los errores y mejoramos el tiempo de desarrollo. Conforme avanzamos debemos de manejar este proceso de una forma m´ as digerida para poder aplicarlo en sitemas y programas sin ninguna dificultad.

3

1.3.

´ DEL PSP DEFINICION

El PSP es una l´ınea de trabajo de medici´on y an´alisis para ayudarnos a caracterizar nuestro proceso. Tambi´en es un procedimiento definido que nos ayuda a mejorar nuestro desempe˜ no. Algunos de sus principios son:

La calidad de un sistema de software est´a dada por la calidad del proceso utilizado para desarrollarlo y mantenerlo. La calidad de un sistema de software est´a determinada por la calidad de su componentes m´as deficientes. La calidad de un componente de software est´a dada por el individuo que lo desarrolla. El desempe˜ no individual est´ a dado por el conocimiento, la disciplina y el compromiso del individuo. Se pretende lograr que como profesional del software, debemos conocer nuestro desempe˜ no personal. Debemos de medir, darle seguimiento y analizar su trabajo. Debemos aprender a partir de las variaciones de su desempe˜ no. Debemos incorporar estas lecciones aprendidas en nuestras pr´acticas personales. Al paso del tiempo y la practica debemos saber controlar: La estimaci´ on y planeaci´ on de nuestro trabajo, cumplir con nuestros compromisos y resistir presiones por compromisos no razonables.

4

1.4.

FASES DEL PROCESO PSP

1.4.1.

PSP0

El PSP 0 es un proceso simple y definido. Utiliza sus m´etodos actuales de dise˜ no y desarrollo. Los objetivos principales del PSP 0 son: Demostrar el uso de proceso definido al escribir un programa peque˜ no. Incorporar medidas b´ asicas 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´on 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´acil. Para esta primera fase, los elementos necesarios son: Gui´on del proceso Bit´acora de registro de tiempo Bit´acora de reporte de defectos Est´andar de tipos de defectos Forma de resumen del plan de proyecto En donde :

La planeaci´ on es la estimaci´ on del tiempo de desarrollo. El desarrollo es el producto utilizando sus m´etodos actuales. El postmortem espara completar el resumen del plan del proyecto, con el tiempo utilizado y los defectos descubiertos e introducidos en cada fase.

5

1.4.2.

PSP0.1

El PSP0.1 tiene como finalidad medir el tama˜ no del software para relacionar la cantidad de producto generado con el esfuerzo empleado. As´ı como tambi´en para calcular nuestra productividad, medida en LOC´s1 y normalizar los defectos. Se emplean en las tareas 2A y 3A. Los objetivos principales del PSP 0.1 son: Medir el tama˜ no de los programas que producimos. Contabilizar los tipos de LOC´s en los programas que producimos. Realizar´ a mediciones de tama˜ no exactas y precisas. Introducimos una nueva serie de elementos al proceso: La forma de propuesta de mejora del Proceso (PIP). Est´andar de Conteo (R1). Est´andar de Codificaci´ on (R2). El resumen de plan de proyecto ha sido expandido para incluir las mediciones de tama˜ no del software y la distribuci´ on del tiempo de planeaci´ on a lo largo de las fases.

1 Lineas

de c´ odigo

6

1.4.3.

PSP1

El PSP1 en el cual su objetivo es establecer un procedimiento ordenado y repetible para el desarrollo de estimaci´on de tama˜ no de software. La tarea 4A es la u ´nica que se realiza durante esta variaci´on de PSP. Los nuevos elementos introducidos en el PSP1 son: El m´etodo de Estimaci´ on de tama˜ no PROBE. La plantilla de Estimaci´ on de tama˜ no. La plantilla de reporte de pruebas.

7

1.4.4.

PSP1.1

En la tarea 5 y 6 utilizaremos el PSP1.1, sus Objetivos del PSP1.1 son introducir y practicar m´etodos para: Realizar planes de recursos y de calendarios de trabajo. Darle seguimiento a su desempe˜ no en cuanto a sus planes. Juzgar la probabilidad de las fechas de terminaci´on del proyecto. Se incorporan nuevos elementos al proceso: Plantilla de planeaci´ on de tareas. Plantilla de planeaci´ on 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 2 . El resumen del plan de proyecto se expandi´o para que incluya estad´ısticas b´asicas del proceso. resumen de plan de proyecto PSP1.1 reporte de pruebas forma PIP plantilla de estimaci´ on de tama˜ no hoja PROBE bit´acora de registro de tiempo bit´acora de registro de defectos lista de programa fuente resultados de las pruebas

2 Se

utilizan cuando trabajamos con TSP

8

1.4.5.

PSP2

Como profesional del software, debemos de conocer nuestro desempe˜ no personal. Debemos medir, darle seguimiento y analizar el trabajo. Aprender a partir de las variaciones de nuestro desempe˜ no e incorporarlas en nuestras praticas personales. Los objetivos de PSP2 son introducir: Las revisiones de dise˜ no y c´ odigo M´etodos para la evaluaci´ on y mejora de calidad de sus revisiones Se incorporan dos nuevos elementos al proceso: Lista de comprobaci´ on de la revisi´on de dise˜ no del PSP2 Lista de comprobaci´ on de la revisi´on de c´odigo

9

1.4.6.

PSP2.1

Los objetivos del PSP2.1 son introducir. Introducir m´etricas adicionales para la administraci´on de la calidad Plantillas de dise˜ no que proporcionen una l´ınea de trabajo ordenado y formatos para documentar los dise˜ nos. Existen cuatro nuevos elementos del proceso: Lista de comprobaci´ on de la revisi´on de dise˜ no PSP2.1 Plantilla del escenario operacional Plantilla de especificaci´ on de estados Plantilla de especificaci´ on l´ ogica Las tareas 8A, 9A y 10A se realizan con este proceso.

10

1.5.

ENTRENAMIENTO DEL PSP

Elaboramos 10 tareas con las cuales nos fuimos capacitando paso a paso al ir introduciendo en cada una de las tareas una fase del Proceso Personal del Sofware. Nos obliga a crear una disciplina que nos ayuda a mejorar nuestro proceso personal,los datos que se fureron almacenado nos servira para mejorar continuamente la productividad, calidad y la predicci´ on de nuestro trabajo.

1.5.1.

TAREA 1

* Los objetivos de la tarea 1A son: Comprender los requerimientos del programa 1A Concluir la palneaci´ on del programa 1A * Requerimientos del Programa 1A Calcular la media y la desviaci´ on est´ andar de una serie de n n´ umeros reales. Su programa debe leer los n n´ umeros reales del teclado, de un archivo, etc. Use una lista ligada para almacenar los n n´ umeros para los c´alculos. Pruebe completamente el programa. Deber´ıa usar al menos tres pruebas de los datos en las tres columnas de abajo. * Media y Desviaci´ on Est´ andar La media es el promedio de n n´ umeros. La desviaci´ on est´ andar es calculada de la siguiente forma. F´ormula de la desviaci´ on est´ andar.

Std = σ =

r Pn

i=1

donde: σ: Es el s´ımbolo de la desviaci´ on est´andar. P : El el s´ımbolo de la sumatoria.

11

(xi −xavg )2 n−1

LOC Objeto

LOC Nuevas y Modificadas

Horas de Desarrollo

160

186

15.0

591

699

69.9

114

132

6.5

229

272

22.4

230

291

28.4

270

331

65.9

128

199

19.4

1657

1890

198.7

624

788

38.8

1503

1601

138.2

Media

550.6

638.9

60.32

DesEst

572.03

625.63

62.26

Cuadro 1.1: tabla D4, p´agina 753 i: Es un ´ındice de n n´ umeros xavg : Es el valor promedio de los n n´ umeros * Las listas ligadas son: 1. Un tipo de datos abstracto utilizado para almacenar conjuntos de datos implementadas con apuntadores. 2. Una lista ligada con frecuencia tiene estos componentes. Ra´ız de la lista Nodo de la lista

12

Algunas de las opciones para la estructura de listas ligadas son La ra´ız de la lista puede apuntar al primer nodo, u ´ltimo nodo, o a ambos. Un nodo de la lista puede apuntar al siguiente nodo, al anterior, o a ambos. Por lo regular se usa un apuntador con valor nulo para indicar una lista vac´ıa o el final de la lista. Las operaciones t´ıpicias en una lista ligada incluyen agrega nodo, siguiente nodo y anterior nodo.

13

1.5.2.

TAREA 2

* Requerimientos del Programa estimado de recursos estimado de tama˜ no * Requerimientos del Programa 2A Utilice el PSP0.1 para escribir un programa que cuente el total de LOC´s l´ogicas en un programa omitiendo los comentarios y las l´ıneas en blanco. Utilice su est´ andar de conteo (R1) y su est´andar de codificaci´on (R2) para colocar una l´ınea l´ogica en cada l´ınea f´ısica y cuente las l´ıneas f´ısicas. Produzca un conteo u ´nico para el archivo de programa fuente. Prueba completamente el programa. Como una prueba, cuente las LOC´s en los programas 1A y 2A.

14

1.5.3.

TAREA 3

* Objetivos del Taller 1. Comprender´ a los requerimientos del programa 3A 2. Habr´ a concluido la planeaci´ on del programa 3A Requerimientos del programa Estimaci´ on de los recursos Estimaci´ on del tama˜ no * Requerimientos del Programa 3A Use el PSP0.1 para escribir un programa que cuente Las LOC l´ ogicas totales en un programa Las LOC l´ ogicas en cada objeto o funci´on N´ umero de m´etodos en cada objeto * Produzca e Imprima Un solo conteo de LOC para el archivo del programa fuente Conteo separados de LOC y m´etodos para cada objeto Usted puede mejorar el programa 2A para realizar el programa 3A (pero mantenga un copia del 2A). Usted puede actualizar su est´ andar de conteo de LOC (R1) y su est´andar de codificaci´on (R2) para simplificar el dise˜ no del programa 3A. Pruebe completamente este programa. Como un m´ınimo, pruebe el programa contando el programa total y las LOC por cada objeto en los programas 1A, 2A y 3A. Incluya en su reportes de prueba un tabla que proporcione los conteos obtenidos. Use el formato mostrado en la tabla D7 en la p´agina 754 del texto. * Instrucciones de la Tarea

15

Usando el proceso PSP0.1, termine la fase de planeaci´on para la tarea 3A. Cuando usted haya terminado la planeaci´on, revise su trabajo con el instructor. Despu´es de que su plan haya sido revisado, concluya la tarea utilizando el PSP0.1. Cuando usted haya concluido la fase postmortem, entregue su paquete de tarea, c´odigo fuente y resultados de prueba al instructor en este orden.

16

1.5.4.

TAREA 4

* Objetivos del Taller 1. Comprender´ a los requerimientos del programa 4A 2. Habr´ a concluido la planeaci´ on del programa 4A Dise˜ no conceptual Estimado de tama˜ no Estimado de recursos * Requerimientos del Programa 4A Calcule los par´ ametros de regresi´ on lineal β0 y β1 para n conjuntos de datos. Mejore la lista ligada desarrollada en el programa 1A para que almacene los conjuntos de n datos, donde cada conjunto de datos contiene exactamente dos n´ umero reales. Pruebe el programa con tres conjuntos de datos. 1. LOC de objeto estimadas y LOC N&C reales (tabla D8, p´agina 756) 2. LOC N&C estimadas y LOC N&C reales (tabla D8, p´agina 756) 3. LOC N&C estimadas y LOC N&C reales de sus programas 2A, 3A y 4A * Par´ ametros de Regresi´ on Par´ametro de Regresi´ on β0 es: yavg − β1 xavg

Par´ametro de Regresi´ on β1 es:

Pn xi yi −nxavg yavg β1 = Pi=1 n xi 2 −n(xavg )2 i=1

17

1.5.5.

TAREA 5

* Objetivo del Taller Despu´es de este taller, usted comprender´ a los requerimientos del programa 5A habr´ a concluido la planeaci´ on del programa 5A dise˜ no conceptual estimado de tama˜ no estimado de recursos Use el PSP1.1 para escribir un programa para integrar num´ericamente un funci´on usando la regla de Simpson para una funci´ on de la distribuci´on normal. El programa deber´ıa ser dise˜ nado para integrar utilizando varias funciones dadas. Usted necesitar´ a este programa para calcular los valores de varias distribuciones estad´ısticas utilizadas en los siguientes programas de tareas. Prueba completamente el programa. Como m´ınimo, utilice este programa para calcular los valores de la integral de la distribuci´ on normal para tres valores. Prueba

Valor Esperado

de - ∞ a 2.5

0.9938

de - ∞ a 0.2

0.5793

de - ∞ a -1.1

0.1357

* Integraci´ on Num´ erica En principio, la integraci´ on num´erica trata un funci´on como si estuviese compuesta de muchas ´areas rectangulares. Suma estas ´ areas para producir el valor de la integral. El truco es suma estas ´ areas de tal forma que el erro se minimice.

18

*L´ımites de Integraci´ on Para determinar los l´ımites de integraci´on la mayor´ıa de las funciones estad´ısticas son integradas de - ∞ a alg´ un valor todas las funciones estad´ısticas tienen una ´area total de 1.0 cuando son integradas de - ∞ a + ∞. * Funciones Sim´ etricas Con funciones sim´etricas (la distribuci´ on normal y la distribuci´on t de student), el procedimiento es este. Si el valor de X es

Integre de

y

Positivo

0aX

sume 0,5 al presultado

Negativo

0 a —X—

reste 0,5 al resultado

* Regla de Simpson La regla de simpson para integrar:

(1.1) Z

xhigh

W [F (xlow ) + 4F (xlow + W ) + 2F (xlow + 2W ) + 3 xlow 4F (xlow + 3W )... + 2F (xhigh − 2W ) + 4F (xhigh − W ) + F (xhigh )] F (u)du =

19

donde:

W es el ancho de las bloques rectangulares F es el valor de la funci´ on para cada valor de x La regla de Simpson en otra forma2

Z

xhigh

F (u)du = xlow

N −1 N −2 X X W [F (xlow ) + 4F (xlow + iW ) + 2F (xlow + iW ) + F (xhigh ] 3 i=1,3,5... i=2,4,6...

(1.2)

donde N es el n´ umero de segmentos. * Distribuci´ on Normal La f´ormula de la distribuci´ on normal es: Z

x

φ(x) = −∞

−u2 1 p e( 2 ) du (2π)

(1.3)

La p´agina 528 contiene las f´ ormulas para las distribuciones x2 y t. * Sugerencias Refi´erase a la p´ agina 517 en el Ap´endice A para un algoritmo que eval´ ue la integral usando la regla de Simpson.

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

Si usted est´ a usando C o C++, considere dise˜ nar la regla de Simpson para que acepte un apuntado a una funci´on. (Esto hace la reutilizaci´ on muy f´acil.)

Para otros lenguajes, separe el c´ alculo de la regla de Simpson de la distribuci´on normal. * Instrucciones de la Tarea 2 La

anterior ecuaci´ on de Simpson es una forma simplificada de la ecuaci´ on A5 del libro, p´ agina 518.

20

Usando el proceso PSP1.1, termine la fase de planeaci´on para la tarea 5A.

Cuando usted haya concluido la planeaci´on, revise su trabajo con el instructor.

Despu´es que su plan haya sido revisado, termine la tarea usando el PSP1.1. Cuando haya terminado la fase de postmortem, entregue al instructor su paquete de tarea, c´odigo fuente y resultados de prueba al instructor en el siguiente orden. resumen de plan de proyecto PSP1.1 reporte de pruebas forma PIP plantilla de estimaci´ on de tama˜ no hoja PROBE bit´acora de registro de tiempo bit´acora de registro de defectos lista de programa fuente resultados de las pruebas

21

1.5.6.

TAREA 6

* Requerimientos del Programa 6A Usando el formato para PSP 1.1 escribimos un programa para calcular los intervalos de predicci´on del 70 % y del 90 % de las LOC´s nuevas y modificadas estimadas, dado un conjunto de datos hist´oricos de tama˜ no y un estimado de LOC de objeto. Usamos la regla de integraci´ on de Simpson del programa 5 para calcular el valor de la distribuci´on t. Use una lista ligada para almacenar los datos hist´oricos. * Intervalo de Predicci´ on El intervalo de predicci´ on proporciona un rango de probabilidad alrededor del estimado. Un intervalo de predicci´ on de 70 % da el rango dentro del cual caer´an el 70 % de los estimados. No es un pron´ ostico, solo una expectativa. Solo aplica si el estimado se comporta como los datos hist´oricos. Se calcula a partir de los mismos datos utilizados para calcular los par´ametros de regresi´on. Par calcular el intervalo de predicci´ on, realizamos los siguientes pasos: 1. Lee los datos hist´ oricos x´s y y´s. 2. Calcule β0 y β1 . 3. Lea su estimado Xk . 4. Calcule una proyecci´ on como Yk = β0 + β1 ∗ Xk . 5. Calcule el rango para un intervalo de 70 %. 6. Calcule el U P I = Yk + Rango(70 %). 7. Calcule el LP I = Yk − Rango(70 %). 8. Repita los pasos 5 al 7 para el rango de 90 %. 9. Imprima sus resultados. 22

* La f´ ormula para el c´ alculo del rango de predicci´ on es:

s Range = t(α/2, dof )σ

1+

1 (xk − xavg )2 + Pn 2 n i=1 (xi − xavg )

(1.4)

donde x es el tama˜ no de los datos hist´ oricos. n es el n´ umero de puntos de los datos hist´oricos. t(α/2, dof ) La f´ormula para calcular la desviaci´on est´andar es: v u n u 1 X σ = t( ) (yi − β0 − β1 xi )2 gl i=1

(1.5)

donde x son los datos hist´ oricos de tama˜ no estimado de objetos y son los datos hist´ oricos de tama˜ no nuevo y modificados reales. β0 y β1 son los par´ ametros de regresi´on lineal de los datos x´s vs y´s. gl es el n´ umero de los grados de libertad de los datos, el cual es n-2. Encontrando t70 (α/2, n − 2)

,35 =

Γ( (n−1) 2 ) ((n − 2) ∗ Π)1/2 Γ( (n−2) 2 )

t70 (α/2,(n−2))

Z

(1 + 0

donde n es el n´ umero de miembros de x. Γ(x) = (x − 1)Γ(x − 1),Γ(1) = 1, y Γ(1/2) = Π1/2 . La distribuci´ on t Es parecida a la distribuci´ on normal. 23

−(n−1) u2 ) 2 du (n − 2)

(1.6)

Tiene colas muy gruesas. Es usado en estimados de par´ ametros estad´ısticos para datos limitados.

Calculando el valor de t Para calcular el valor de t(α/2, n − 2) Inicie con un valor de prueba de 1 para el l´ımite superior y calcule el valor de la integral. Compare el resultado con el valor deseado. 1. Si el resultado de la integraci´ on es demasiado grande, tome un l´ımite superior de prueba m´as grande. 2. Si el resultado de la integraci´ on es demasiado grande, tome un l´ımite superior m´as peque˜ no. Haga la integraci´ on de prueba sucesivas hasta que el valor de la integraci´on est´e dentro de un error aceptable, digamos 0.00002. 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´ alculo 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´e. 3. Si es muy bajo, sume d = 0,5 al valor de prueba t. 24

4. Si es muy alto, reste d=0.5 al valor de prueba t. 5. Integre de nuevo y pruebe si el resultado est´a dentro del error aceptable, si no, continu´e. 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.

25

1.5.7.

TAREA 7

* Objetivos del Taller: Despu´es de este taller, usted comprender´ a los requerimientos del programa 7A habr´ a terminado la planeaci´ on del programa 7A dise˜ no conceptual estimado de tama˜ no estimado de recursos estimado de defectos * Requerimientos del Programa 7A Usando el PSP2, escriba un programa que calcule la correlaci´on entre dos series de n´ umeros y calcule la significancia de esa correlaci´ on.

Utilice la rutina de integraci´ on de Simpson del programa 5A para calcular los valores de la distribuci´on t.

Almacene los datos en una lista ligada.

Pruebe el programa utilizando las LOC nuevas y modificadas reales como los datos x y las horas de desarrollo como los datos y.

26

N´ umero de elemento

LOC nuevas y modificadas reales

Horas de desarrollo

n

x

y

1

186

15,0

2

699

69,9

3

132

6,5

4

272

22,4

5

291

28,4

6

331

65,9

7

199

19,4

8

1890

197,7

9

788

38,8

10

1601

138,2

Totales

6389

603,2

Determine la correlaci´ on y significanc´ıa entre las LOC nuevas y modificadas y el tiempo de desarrollo real de sus tareas a la fecha. Determine la correlaci´ on y significancia entre las LOC nuevas y modificadas estimadas y el tiempo de desarrollo real de las tareas 2A a la 6A. Prepare y entregue un reporte de pruebas que incluya estos datos. Prueba

Valor Esperado r

t

2 ∗ (1 − p)

Tabla D12

0,9443

9,0335

1,80 ∗ 10−5

LOC Reales VS Tiempo de Des.

NA

NA

NA

LOC Estimadas Vs Tiempo de Des.

NA

NA

NA

Valor Real r

t

2 ∗ (1 − p)

* Uso de la Correlaci´ on La correlaci´ on rxy puede ir de +1 to -1. Cerca de +1 implica una fuerte relaci´ on positiva; cuando x se incrementa y se incrementa. Cerca de -1 implica una fuerte relaci´ on negativa; cuando x se incrementa y se decrementa. Cerca de 0 implica que no tienen relaci´ on.

27

La correlaci´ on es utilizada en el PSP para juzgar la calidad de la relaci´on lineal en varios datos hist´oricos del proceso que son utilizados para la planeaci´on. Para este prop´ osito, usamos el valor de la relaci´on rxy al cuadrado, o r2 . Si r2 es: 0,9 ≤ r

La relaci´ on es:

2

Predictiva; usela con gran confianza.

0,7 ≤ r2 < 0,9

fuerte y puede ser usado para planeaci´on.

,5 ≤ r2 < ,7

adecuada para planeaci´on, pero con cuidado,

r2 < ,5

no es confiable para prop´ositos de planeaci´on.

* C´ alculo de la Correlaci´ on La f´ormula para calcular el coeficiente de correlaci´on r es:

Pn



Pn
Pn xi yi − i−1 xi i−1 yi r(x, y) = rh

2 i h Pn

2 i Pn Pn Pn 2 2 n n i−1 xi − i−1 xi i−1 yi − i−1 yi n

i−1

(1.7)

donde: x y y son dos conjuntos de datos por parejas. n es el n´ umero de sus miembros.

* La Prueba de la Significancia La prueba de significancia determina la probabilidad que una correlaci´on fuerte sea por casualidad y por lo tanto no tenga significancia pr´ actica. Recu´erdese que una correlaci´on fuerte puede ser s´olo por coincidencia, especialmente cuando los datos son escasos. Por ejemplo, un conjunto de datos con s´olo dos puntos siempre tendr´a r2 = 1, pero esta correlaci´ on no es significativa.

La prueba de significancia usa la distribuci´on t.

28

* C´ alculo de la Significancia El c´alculo de la significancia consiste de tres pasos. Calcule el valor de t. donde: r(x, y) es la correlaci´ on n es el n´ umero de puntos √ |r(x, y)| n − 2 t= p 1 − r(x, y)2

(1.8)

Encuentre la probabilidad p integrando num´ericamente la distribuci´on t para n - 2 grados de libertad, de -∞ a t. Calcule la cola de la distribuci´ on, 2 ∗ (1 − p). * Interpretnado la Significancia Una ´area en la cola ≤ 0,05 se considera una evidencia fuerte que existe relaci´on.

Una ´area en la cola ≥ 0,2 se considera que la relaci´on es debida a la coincidencia.

Instrucciones de la Tarea

29

Usando el proceso PSP2, termine la fase de planeaci´on para la tarea 7A.

Cuando haya terminado la planeaci´ on, revise su trabajo con el instructor.

Despu´es que su plan haya sido revisado, termine la tarea usando el PSP2.

Cuando haya terminado la fase postmortem, entregue su paquete de la tarea, c´odigo fuente y resultados de prueba al instructor en el siguiente orden.

Resumen de plan de proyecto PSP2 reporte de pruebas listas de revisi´ on de dise˜ no listas de revisi´ on de codificaci´ on forma PIP plantilla de estimaci´ on de tama˜ no hoja PROBE bit´acora de registro de tiempo bit´acora de registro de defectos listado del programa fuente

30

1.5.8.

TAREA 8

* Despu´ es de este taller, usted comprender´ a los requerimientos del programa 8A habr´ a concluido la planeaci´ on del programa 8A - dise˜ no conceptual - estimado de tama˜ no - estimado de recursos - estimado de defectos * Requerimientos del Programa 8A Usando del PSP2.1, escriba el programa 8A para que ordene una lista ligada de n pares de n´ umeros reales en orden descendente. Proporcione la capacidad de ordenar cualquier campo de la pareja de datos. Pruebe el programa usando los datos en las dos columnas de la derecha de la tabla D14, p´agina 761, del texto. Realice dos ordenamientos, uno para cada campo. Entregue un reporte de pruebas que describa ambos resultados.

* Ordenamiento por Inserci´ on Considerando dos listas ligadas,realizaremos el oredenamiento por inserci´on. El algoritmo de ordenamiento por inserci´on ordena al encontrar la posici´on ordenada correspondiente a un elemento de dato, entonces inserta el elemento de dato en la lista de datos en esa posici´on.

31

* Instrucciones de la Tarea Usando el proceso PSP2.1, termine la fase de planeaci´on para 8A. Cuando haya terminado la planeaci´ on, revise su trabajo con el instructor. Despu´es que su plan haya sido revisado, termine la tarea utilizando el PSP2.1.

Cuando usted haya terminado la fase de postmortem, entregue su paquete de tarea, c´odigo fuente y resultados de prueba al instructor en el siguiente orden. Resumen de plan de proyecto PSP2.1 reporte de pruebas listas de revisi´ on de dise˜ no listas de revisi´ on de c´ odigo forma PIP plantilla de estimaci´ on de tama˜ no hoja PROBE plantilla de escenario operacional plantilla de especificaci´ on funcional plantilla de especificaci´ on de estados plantilla de especificaci´ on l´ ogica bit´acora de registro de tiempo bit´acora de registro de defectos listado del programa fuente

32

1.5.9.

TAREA 9

Requerimientos del programa 9A Usando el PSP2.1, escriba el programa 9A para calcular el grado al cual una cadena de n n´ umeros reales es normalmente distribuida. Use la rutina de untegraci´ on de Simpson´s del programa 5A para calcular los valores de la distribuci´on 2

X . Asuma n > 20 y siempre un m´ ultiplo de 5.(nota: se puede asumir n = 50). Use el programa 8 para ordenar los n´ımeros de forma ascendente. Prueba X2 para la normalidad La prueba X2 para la normalidad determina que tan probable es que un conjunto de datos tenga una distribuci´on normal. Se hace para comparar la estructura de un conjunto de datos con el de una distribuci´on normal ideal.

Realizamos esto dividiendo la distribuci´on normal en segmentos de igual ´area y comparando el actual n´ umero de puntos del conjunto de datos a probar con el n´ umero de una distribuci´on normal ideal. Los pasos de la prueba X2 son como sigue: 1. Ordene el conjunto de datos en orden ascendente. 2. Normalice el conjunto de datos. Primero, calcule la desviaci´ on est´andar, usando n-1 v u n u 1 X σ=t (xi − xavg )2 n − 1 i=1

(1.9)

Entonces, transforme cada xi a una zi normalizada zi =

(xi − xavg ) σ

3. Divida la distribuci´ on normal en algunos segmentos S, donde 33

(1.10)

n S

≥5

S>3 S2 ≥ n Para este problema, S = 10 satisface estos requerimientos. 4. Determine cu´ antos elementos de la distribuci´on normal caer´ıan en cada segmento, Ni . Normalmente, esto es

n S;

en este caso es 5.

5. Determine cu´ antos elementos del conjunto de datos normalizados caen en cada segmento, ki . 6. Calcule el valor Q para los segmentos. Q=

S X (Ni − ki )2 Ni i=1

(1.11)

7. Calcule la probabilidad p de la distribuci´on X 2 para S − 1 grados de libertad (dof ) al integrar de 0 a Q.

p=

Z

1 ( dof 2

2

) Γ( dof ) 2

Q

u(

dof 2

)−1 ( −u 2 )

e

du

0

Nota: La ecuaci´ on anterior para X2 difiere de la ecuaci´on A7, p´agina 518, por Sustituir dof por n . Sustituir Q por x. 8. Calcule la cola de la distribuci´ on como 1 − p. 9. Examine 1 − p para interpretar los resultados. 1 − p < 0,05 es generalmente considerado suficiente para rechazar que ajusta. 1 − p > 0,2 es generalmente considerado suficiente para aceptar que ajusta. Valores intermedios indican grados intermedios de ajuste.

34

(1.12)

1.5.10.

TAREA 10

Requerimientos del programa 10A Usando PSP 3, realice el programa 10A para calcular, los par´ametros de regresi´on m´ ultiple (β0 , β1 , β2 , β3 ). Lo primero que se va a realizar es, hacer un estimado de las entradas previstas por el usuario. Y determine los intervalos de predicci´on del 70 y 90 por ciento a ser estimados. Use adem` as una lista ligada para almacenar los datos y el m´etodo de integraci´on de Simpson del programa 5A para calcular la distribuci´on t. Calculando los par´ ametros de regresi´ on m´ ultiple La regresi´ on m´ ultiple proporciona un camino para estimar los efectos de m` ultiples variables cuando no es posible separa los datos. A continuaci` on se muestra en una serie de 13 pasos de como podemos calcular la regresi´on m´ ultiple. 1. Use la siguiente formula de regresi´on m´ ultiple, para calcular el valor del proyecto:

zk = β0 + wk β1 + xk β2 + yk β3

(1.13)

2. Encontrar los par´ ametros BETA resolviendo el siguiente sistema de ecuaciones lineales:

β0 n + β1

n X

wi + β2

n X

i=1

β0

n X

n X

wi + β1

i=1

β0

n X

i=1

xi + β1

i=1

β0

n X i=1

n X

i=1

wi2 + β2

n X

n X i=1

n X

wi xi + β2

wi xi + β3

n X i=1

wi yi + β2

n X i=1

35

yi =

i=1

i=1

i=1

yi + β1

xi + β3

n X

n X

zi

n X

wi yi =

i=1

x2i + β3

n X

n X i=1

wi zi

(1.15)

xi zi

(1.16)

y i zi

(1.17)

i=1

xi yi =

n X

i=1

xi yi + β3

(1.14)

i=1

i=1

xi yi =

n X i=1

3. Cuando calcules el valor de los t´erminos, obtendr´as el siguiente sistema de ecuaciones lineales 6β0 + 4, 863β1 + 8, 761β2 + 654β3 = 714 4863β0 + 4, 521, 899β1 + 8, 519, 938β2 + 620, 707β3 = 667, 832 8, 761β0 + 8, 519, 938β1 + 21, 022, 091β2 + 905, 925β3 = 1, 265, 493 654β0 + 620, 707β1 + 905, 925β2 + 137, 902β3 = 100, 583

4. Diagonalizando por el m´etodo de Gauss se elimina sucesivamente un par´ametro 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, 135 0β0 + 0β1 + 4, 759, 809β2 + 905, 925β3 = 5, 002,332 0β0 + 0β1 + 0β2 + 37, 073,93β3 = 100, 583

5. Resuelva para los t´erminos Beta β0 = 6,7013 β1 = 0,0784 β2 = 0,0150 β3 = 0,2461

6. Determine el intervalo de predicci´on resolviendo para el rango con la siguiente ecuaci´on.

(1.18) α range = t( , n − 4)σ 2

s 1+

1 (wk − wa vg)2 (xk − xa vg)2 (yk − ya vg)2 P P +P + + n (wi − wavg )2 (xi − xavg )2 (yi − yavg )2

7. Calculamos la varianza como sigue: σ2 = (

n X 1 ) (zi − β0 − β1 wi + β2 xi − β3 yi )2 n − 4 i=1

36

(1.19)

8. La desviaci´ on est` andar es la siguiente: √ σ=

σ2 =

p 513,058 = 22,651

(1.20)

9. Los t´erminos dentro de la ra´ız cuadrada que determinan el rango son:

(N ewk − N ewavg )2 = (wk − wavg )2

(1.21)

= (650 − 810,5)2 = 25, 760,25

(Reusek − Reuseavg )2 = (xk − xavg )2

(1.22)

= (3, 000 − 1, 460,17)2 = 2, 371, 076,43

(M odif yk − M odif yavg )2 = (yk − yavg )2

(1.23)

= (155 − 109)2 = 2, 116 10. el valor de la distribuci´ on t, para el intervalo de la predicci´on 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

r 25, 760,25 2, 371,076,43 2, 116 Range = 1,386 ∗ 22,651 1 + (1/6) + + + 580, 437,5 8, 229, 571 66, 616 Range = 38,846 12. El estimado final es: z = 6,71 + 0,0784 ∗ 650 + 0,0150 ∗ 3, 000 + 0,2461 ∗ 155 = 140,902horas 13. El intervalo de predicci´ on es de: 140,902±38,84 horas. O lo que es lo mismo: 102.06 horas como m`aximo.

37

1.6.

RESUMEN DEL PLAN DEL REPORTE R5

1.6.1.

GU´IA DEL REPORTE R5

38

1.6.2.

RESUMEN DEL PLAN DEL REPORTE R5

39

1.6.3.

´ BITACORA DE REGISTRO DE TIEMPO R5

40

1.6.4.

´ ´ DE LOC ANALISIS DE LA EXACTITUD DE ESTIMACION

¿Alcance las metas propuestas en el reporte R4 para la estimaci´ on de tama˜ nos? ¿Porque si o porque no? ´ No, La meta propuesta en el reporte R4 no ha sido cumplida ya que a partir de la tarea 6 se sobrestimo la cantidad de loc’s requeridas para cada programa, es decir en lugar de mejorar se aumento el error al hacer la estimaci´ on. Podemos apreciar en la gr´ afica 1 de LOC’s Estimadas y Actuales VS Programas,con las l´ıneas vemos el comportamiento que tuvieron los c´alculos estimados en las tareas realizadas y los puntos la distancia entre las Loc’s Estimadas y las LOC’s Actuales.

Grafica 1.

41

El error absoluto vario en todas las tareas, como podemos ver en la grafica 2, iniciamos con un -23.86 % (subestimados), en la tarea 4 subimos hasta un 27.78 % (sobreestimados), en la tarea 5A sigue aumentando el calculo sobreestimado,a partir de la tarea 6 continuamos en total desequilibrio ya que nos vamos en picada hasta llegar a -31 % en la tarea 10. A pesar de que mi estimado calculado por la hoja exel no fueron muy exactos, en mis c´ alculos propios cada vez se acercaba m´as a los reales por o cual estoy muy satisfecha con mi trabajo realizado durante este proyecto.

Grafica 2.

42

¿C´ omo fue mi estimado con respecto a los intervalos de predicci´ on del 70 % y del 90 %? A partir de la tarea 7 utilizamos el m´etodo A en la hoja de EXCEL Probe el cual solo nos indica el rango del 70 % el cual es de 107. En la tarea 10 si sobrepase el rango, dado que , en los estimados de la hoja EXCEL Summary la diferencia entre el real y el estimado es de 144 Loc’s, en las tareas anteriores la diferencia de el estimado y el real es menor al rango, lo cual indica que esta dentro de lo aceptable.

¿Qu´ e tendencia tuve acerca de sobreestimar ´ o subestimar a los objetos? Mi tendencia es sobreestimar, tratando de considerar los m´etodos de cada clase, lo que recibe cada clase como par´ametro y los par´ ametros que recibe cada m´etodo, tratando de valorar que cuando una operaci´on hace demasiados c´ alculos lo divido en secciones. ¿Qu´ e tendencia tuve al calcular mal el tama˜ no relativo de los objetos? Que quiz´ as consideraba en el objeto m´as c´alculos de los que en realidad se requer´ıan para hacer m´ as comprensible la documentaci´on de cada objeto. Y la divisi´on de m´etodos.

43

Para calcular un tama˜ no relativo ¿necesito usar mi informaci´ on hist´ orica de los objetos? ¿Puedo? Claro que si, conforme vamos avanzando ya sabemos m´as o menos cuantas Loc’ requerimos para crear ciertos objetos, un ejemplo son: Aplicaci´on que por lo general administra el uso de las clases, imprimir que despliega los resultados requeridos, y si vamos a utilizar m´etodos dentro de dicha clase, sabemos espec´ıficamente por datos anteriores los tama˜ nos de los m´etodos. Basado en mi informaci´ on hist´ orica de la estimaci´ on de tama˜ no, ¿cu´ al es una meta real de la estimaci´ on de tama˜ no para mi? El poder estimar mis programas con un rango de 20 a 60 Loc’s.,Considero que no hay mucha diferencia si este rango es sobreestimado o subestimado dado que es peque˜ no. ¿Qu´ e puedo cambiar en el proceso que me ayude a alcanzar las metas? Considero que el proceso es el adecuado, lo que hizo que se tuvieran estas fallas es la falta de experiencia en realizar dicho proceso. Le mayor´ıa de los programadores, ingenieros, licenciados, etc ... no estamos acostumbrados a trabajar con una metodolog´ıa tan buena que nos forza a ser unos programadores organizados, y a tener una buena administraci´ on de tiempo. Y conforme trabajemos con el proceso se ira mejorando.

44

1.6.5.

´ ´ DE TIEMPO ANALISIS DE LA EXACTITUD DE ESTIMACION

¿Alcance las metas propuestas en el reporte R4 para la estimaci´ on de tiempos? ¿Porque si o porque no? ´ Considero que si se mejoro dado que en los primeros programas se subestimaba el tiempo y el los siguientes se fue variando entre el subestimado y el sobreestimado. El la tabla 1 podemos observar que la diferencia o error de exactitud es m´ınima a partir de la tarea 6 A y en la tarea 10 A se disparo a un error muy grande.

Tabla 1.

45

En la grafica 3 podemos apreciar el comportamiento que existe en el tiempo subestimado y el tiempo sobreestimado con respecto a cada programa con respecto al tiempo real.

Grafica 3. ¿C´ omo fue mi estimado de predicci´ on con respecto a los intervalos de predicci´ on del 70 % y del 90 %? Como ya hab´ıamos mencionado que a partir de la tarea 7 utilizamos el m´etodo A en la hoja de EXCEL Probe el cual solo nos indica el rango del 70 % el cual es de mas/menos 70. Solo en las tareas 4A , 6 A y en la 7 A se logr´ o estar dentro del rango, en las tareas faltantes nos salimos del rango. A partir de la tarea 7 A se introdujeron unas nuevas fases de revisi´on de las cuales no se ten´ıa considerado el tiempo que tardar´ıamos en dichas fases.

46

Mi productividad ¿es estable? ¿Por qu´ e si ´ o por qu´ e no? Yo considero que mi productividad no fue estable.La productividad mejoro demasiado, de la tarea 3 a la 6 mi productividad aumento hasta 46.2 Loc’s por hora, pero al tener m´as fases por analizar mi productividad fue variando, en la tarea 7 bajo hasta 27.54 Loc’s por hora en la tarea 8 volvi´o a subir hasta 48.49 Loc’s por hora, en la nueve bajo y en la diez volvi´o a subir. Lo antes explicado lo podemos ver en la grafica 4. de una forma m´as detallada.

Grafica 4. ¿C´ omo puedo estabilizar mi productividad? Como la productividad es valorada desde la planeaci´on hasta el postmortem, debemos tener un mejor manejo en las plantillas y en las revisiones para as´ı poder realizar un mejor un tiempo de estimaci´ on, tambi´en hay que tener m´as practica al hacer el llenado del proceso EXCEL y as´ı lograr tener una productividad estable. ¿C´ omo fueron afectados mis estimados de tiempo por la precisi´ on de mis estimados de tama˜ no? (¿Me ayudo la m´ ultiple regresi´ on?) No me afecta tanto la precisi´ on de los estimados de tama˜ no ya que como mencione antes la productividad es valorada desde la planeaci´on hasta el posmotem y no solo en la 47

codificaci´on, en las graficas representamos todo el trabajo realizado en cada programa en Loc’s por hora que muchos podr´ıan interpretar que es el tiempo de codificaci´on, si fuese as´ı entonces si afectar´ıa mi estimado de tama˜ no pero como no lo es, no afecta demasiado.

Basado en mi informaci´ on hist´ orica de la estimaci´ on de tiempo, ¿cu´ al es una meta real de la estimaci´ on de tiempos para mi? Una meta, ser´ıa lograr que mi predicci´on de tiempo este dentro de un rango de 60 minutos. Para que en un futuro, al estar laborando con un cliente se le pueda dar un tiempo m´as exacto para no quedar mal en la fecha de entrega y as´ı lograr que vuelvan a utilizar nuestro servicios.

¿Qu´ e puedo cambiar en el proceso que me ayude a alcanzar las metas? No es un cambio, sino practicar y ambientarse con el proceso, sobretodo en la parte de la planeaci´ on en la cual se introdujeron unas plantillas que para mi en lo particular 3 de ellas son dif´ıciles de llenar y les invert´ı mucho tiempo que no estaba considerado.

48

1.6.6.

´ ANALISIS DE DEFECTOS Y DEL YIELD

¿Qu´ e tipo de defectos inyecte durante el dise˜ no y codificaci´ on? Los errores inyectados en dise˜ no a partir de la tarea 7 fueron del tipo: 20 (Sintaxis), 40 (Asignaci´ on),70 (Datos) y 80 (Funci´on), algunos errores incrementaron dado a la falta de informaci´on del lenguaje utilizado en la programaci´on.

Grafica 5.

49

Los errores inyectados en codificaci´ on a partir de la tarea 7 son: 20 (Sintaxis), 40 (Asignaci´ on),70 (Datos) y 80 (Funci´on), estos errores aumentaron a comparaci´on del R4 dado a la falta de concentraci´ on al realizar la codificaci´on, confiando que se iba a hacer una revisi´on muy detallada antes de la compilaci´ on.

Grafica 6.

50

¿Cu´ al fue la tendencia de los errores por KLOC encontrados en las revisiones, compilaci´ on y pruebas? Los errores encontrados en la revisi´ on de Dise˜ no fue muy buena, ya que se encontraron los errores que al compilar nos hubiera causado problemas, dado que la mayor´ıa de los errores eran del tipo de asignaciones.

Grafica 7.

51

Los defectos encontrados en la revisi´on del c´odigo ha sido de mucha ayuda, porque cuando compilamos no se han encontrado errores, eso quiere decir que este m´etodo de la revisi´on del c´odigo ha sido perfecto.

Grafica 8.

52

Gracias a las revisiones podemos apreciar en la grafica 9 que en compilaci´on no se encontraron errores.

Grafica 9. En la parte de los defectos encontrados en pruebas fue casi perfecto, salvo por un error que se cometi´o en la codificaci´on y no lo vimos en la revisi´ on y afectaba los resultados esperados.

Grafica 10. 53

En general, la tendencia es positiva ya que nos ayuda a tener una mejor calidad de programas. ¿Cu´ al es la tendencia evidente en el total de defectos por KLOC? La tendencia de introducir defectos ha bajado mucho comparado de cuando empezamos con este proceso, empezamos con 100defectos/KLOC y hemos llegado hasta 45defectos/KLOC, aunque en algunos programas llego a subir hasta 200defectos/KLOC. Todav´ıa se pueden mejorar esta tendencia conforme a la practica y atenci´on al crear y codificar cada programa.

Grafica 11. ¿Cu´ anto es mi tasa de defectos eliminados (defectos eliminados por hora) comparado con la revisi´ on de dise˜ no, revisi´ on de c´ odigo, compilaci´ on y pruebas? En la grafica 12 observamos que mi tasa de defectos eliminados es buena, conforme avanzamos en el proyecto se fueron eliminando errores; por lo cual la tasa de errores encontrados es de 9.3 en general, esto se puede entender mejor cuando sabemos que dependiendo de la cantidad de Loc son la cantidad de errores encontados. A partir de la tarea 7 lo que es compilaci´on y pruebas est´an entre el 95 % al 100 % libre de errores.

54

Grafica 12. ¿Cu´ al es la influencia en mis defectos eliminados para las revisiones de dise˜ no, revisiones de c´ odigo y compilaci´ on contra pruebas unitarias? La influencia es muy importante, para as´ı mejorar la calidad de dise˜ no y por lo tanto mejor calidad del programa, se dieron errores que no se hab´ıan presentado antes por mejorar la calidad y presentaci´on de resultados mostrados en pantalla de dicho programa, por lo cual al realizar las pruebas no se toma mucho tiempo ya que no hay errores, El u ´nico error que tuve despu´es de las revisiones y compilaci´on, fue que un dato introducido en un archivo que se utilizar´ıa para las pruebas estaba invertido, pero los archivos de prueba no se consideraron en las revisiones.

55

¿C´ omo son las tasas de revisi´ on (LOC revisadas/hora) para revisi´ on de dise˜ no y codificaci´ on? Como podemos ver en la tabla 3 las tasas de Dise˜ no son muy altas, en el caso de tareas 9 disminuye un poco y en la tarea 10 vuelve a subir. En la tasa de Codificaci´on vamos mejorando ya que se est´an revisando 99 l´ıneas por hora aproximadamente

Tabla 2. Hay alguna relaci´ on entre el yield y la tasa de revisi´on para las revisiones de dise˜ no y c´odigo? No estoy muy segura, si observamos la grafica 3.9 observamos que dependiendo de la cantidad de Loc’s revisadas por hora mejora el rendimiento de los programas, el rendimiento es del 95 % al 100 % en las ultimas tareas.

Grafica 13.

56

Ahora si vemos la tabla 4 los datos mostrados no indican ninguna relaci´on.

Tabla 3. ¿Hay alguna relaci´ on entre el yield y el A/FR para los programas 7A al 10A? Si decimos que existe una relaci´ on entre el rendimiento y la tasa de revisiones, entonces tambi´en hay una relaci´on entre el rendimiento y el radio A/FR, debido a que se esta tomando en cuenta el tiempo de revisiones ( (Dise˜ no + c´ odigo)/tiempo total) y el tiempo de compilaci´on y pruebas, aunque uno se compensa con otro, es decir, el tiempo que se invierte en las revisiones es eliminado en compilaci´on y pruebas. En la tabla 5 los datos presentados no nos muestra ninguna relaci´on.

Tabla 4.

57

1.6.7.

´ ANALISIS DE CALIDAD

¿Alcance las metas propuestas en el reporte R4 para la calidad? ¿Porque si ´ o porque no? Si, aunque no se vea reflejado en los resultados de los errores, se que he mejorado mucho, ya que los errores encontrados, la mayor´ıa no se hab´ıan visualizado antes, entonces no se repitieron los mismos siempre, hablando de la calidadse mejoro casi un 100 % ya que a la hora de compilar ya no se tuvieron errores y en pruebas solo uno y no era del programa, sino de los datos metidos en el archivo a leer. ¿C´ omo puedo juzgar la calidad de mi producto final en el ciclo de desarrollo? Bueno, ya que se logro la meta de no encontrar errores en codificaci´on y pruebas, conforme a la cantidad de errores introducidos tambi´en fueron disminuyendo aun que pueden reducirse m´as y eso se lograra conforme nos sigamos familiarizando con el lenguaje y aprender a trabajar con distracciones, ya que en un trabajo, siempre habr´ a alguien que nos distraiga.. ¿Estoy encontrando mis defectos en las revisiones de dise˜ no y codificaci´ on? ¿Por qu´ e si ´ o por qu´ e no? Si, A partir de la tarea 7 fue sorprendente que a la hora de compilar no encontrara un solo error y al hacer las pruebas encontraba los resultados esperados, esto se debe que cuando se hacen las revisiones se hacen de una forma minuciosa y sin interrupciones y tambi´en que contamos con una buena gu´ıa de chequeo. ¿Qu´ e puedo hacer para que mi proceso sea mas efectivo y mas eficiente? Practicarlo, es decir, ponerlo en practica en la vida diaria. Conforme se va uno familiarizando con el proceso para diferentes acciones lo empieza a manejar de manera inconsciente. Independientemente de que el proceso sea bueno hay que evitar cometer errores, para as´ı tener un mejor rendimiento y calidad de cada actividad que se pone en practica con el proceso. Basado en mi informaci´ on hist´ orica, ¿cu´ ales son las metas de calidad para mi? En primera una de mis metas es: no encontrar errores en mi dise˜ no, es decir, especializarme en el dise˜ no hasta el punto que al menos cuando cree el dise˜ no esta m´as que entendible el programa a realizar y as´ı crearlo sin errores.

En segundo lugar me gustar´ıa bajar la cantidad de errores introducidos a la hora de codificar, sobre todo los de sintaxis y no comerme renglones de instrucciones que a su vez se convierte en un error de tipo de datos. El rango seria de 15 Loc/hora.

58

En ultimo lugar me gustar´ıa poder codificar m´as loc’s por hora es decir mejorar mi productividad hasta una 75 Loc’s por hora como m´ınimo. ¿En qu´ e debo cambiar mi proceso para que mis metas se cumplan? El proceso es bueno tal cual es, para mi la que fallo fui yo, por lo cual la que debe tener un cambio soy yo. As´ı como familiarizarme con el lenguaje, practicar m´as, poner m´as atenci´on y no tener distracciones a la hora de crear el dise˜ no y de codificar, organizar de una manera m´as eficiente mis tiempos para la utilizaci´on del proceso y por ultimo, tener un mejor manejo en las plantillas utilizadas en el dise˜ no.

59

1.7.

Criterios de Evaluaci´ on

Su reporte de proceso debe ser Completo. Legible. En el orden especificado. Sus datos de proceso, incluyendo c´ alculos de tama˜ no, deben ser Exactos. Precisos. Auto-consistentes. Tambi´ en, ¡los resultados de prueba, no el c´ odigo, son evaluados!

60

1.8.

Sugerencias

Recuerde, usted deber´ıa terminar esta tarea el d´ıa de hoy. Mantenga sus programas lo m´ as sencillos que se pueda. Usted aprender´a igualmente de los programas peque˜ nos que de los grandes. No dude en copiar o ajustar los materiales de PSP. H´agalo bien a la primera. Si no est´ a seguro, resu´elvalo. El software no es una actividad solitaria, de tal forma que no tiene porque trabajar aislado. Sin embargo, usted debe producir sus propios estimados, dise˜ no y c´odigo. Usted puede hacer que otros revisen su trabajo y usted puede modificarlo por ello. Usted deber´ıa anotar en su reporte de proceso cualquier ayuda. Incluya el tiempo de revisi´on que usted y sus compa˜ neros dediquen y registre los defectos encontrados.

61

Cap´ıtulo 2

TSP EQUIPO DE PROCESO DE SOFTWARE

62

2.1.

´ INTRODUCCION

En la actualidad la mayor´ıa de los aspectos de nuestra vida diaria se ven interconectados con los sistemas de informaci´ on espec´ıficamente con las aplicaciones de software, mejor conocidos por la gran mayor´ıa como ”programas de computadora”, dichas aplicaciones nos ayudan en las tareas que se realizan todos los d´ıas en distintos sectores de la sociedad, como pueden ser negocios, servicios p´ ublicos, educaci´on entre otros, es por esta raz´ on que un fallo en dicho software provoca una infinidad de problemas o en el peor de los casos, grandes p´erdidas econ´ omicas. Para evitar dichas contrariedades , en los u ´ltimos a˜ nos se han realizado grandes esfuerzos para producir las aplicaciones con mayor eficiencia, en menor tiempo de desarrollo y con mayor calidad, para cumplir ´estos objetivos es necesario aplicar un enfoque sistem´atico, disciplinado y cuantificable al desarrollo, operaci´on y mantenimiento de software, es decir la aplicaci´on de la Ingenier´ıa en el software. El t´ermino de Ingenier´ıa de Software (IS) aparece a principios de la d´ecada de los 60’s, con la denominada c¸risis del software”, a partir de dicha crisis la IS comenz´o a profesionalizarse para poder atacar adecuadamente los problemas asociados al desarrollo de las aplicaciones. Dentro de ´estos problemas podemos enumerar los siguientes: naturaleza intangible del software, dificultad para lograr proyectos en tiempo y costos, dificultad de conocer un dominio de problema espec´ıfico, falta de planeaci´on, falta de preparaci´ on y uno de los mayores problemas: la dificultad de hacer software de calidad. A partir de la profesionalizaci´ on del software se pens´o en resolver todos estos problemas mediante el uso de metodolog´ıas de programaci´ on, herramientas CASE

1

, lenguajes de modelado, disciplina y uso de procesos.

Dentro de todos los procesos utilizados actualmente en del desarrollo de software podemos encontrar los procesos de PSP (Personal Software Process) y TSP (Team Software Process), al ser procesos cuentan con pasos definidos para administrar y controlar el proceso de desarrollo de aplicaciones, iniciando desde el ambiente personal ,para poder llegar a la correcta formaci´on de un equipo disciplinado, hasta culminar en la correcta planeaci´ on y administraci´ on de proyectos de desarrollo de aplicaciones. En las secciones correspondientes se detallar´a m´as a fondo cada uno de los dos procesos mencionados con anterioridad y se espera que al final de la lectura usted pueda entender la importancia del uso de los mismos para obtener un mejor desarrollo de aplicaciones y lo m´as importante llegar a producir software de calidad en tiempos y costos.

1

Computer Aided Software Engineering- Ingenier´ıa de Software Asistida por Computadora

63

2.2.

OBJETIVOS

Aprender y ejercitar el proceso de software en equipo (TSP) Comprender cada una de las fases del TSP para poder llegar a integrar el mejor equipo de trabajo para cualquier proyecto a futuro. na vez integrado el equipo, TSP nos ayudar´a en primer lugar a definir el trabajo a realizar, una vez definido se podr´ a planificar de la mejor manera y finalmente se realizar´a la asignaci´on del mismo de la manera m´ as eficiente.

64

2.3.

TALLER DE LANZAMIENTO TSP

El proceso TSP marca la realizaci´ on de nueve juntas, en las cuales se tratan objetivos muy espec´ıficos, en cada una de ellas se llena una bit´ acora con las actividades realizadas y a continuaci´on se muestra los res´ umenes de cada una de las ocho juntas.

2.3.1.

Junta 1 del Taller de Lanzamiento

* Prop´ osito: En esta junta, un director con el conocimiento correspondiente presenta el producto o la entrega del producto a ser generado. El objetivo es proporcionar a todos los miembros del equipo un entendimiento com´ un de lo que se espera del futuro proyecto. Un director se re´ une con el equipo para describir las metas de la organizaci´on y responder las preguntas del equipo. * L´ıder de la Presentaci´ on: La presentaci´on es llevada por un director quien entiende el producto deseado, lo que el cliente y usuarios previstos intentar´an hacer con este producto y el tipo de producto que la direcci´on desea generar. * Resultado buscado: Despu´es de esta presentaci´on, el equipo deber´ıa apreciar los deseos de la direcci´on y de los clientes/usuarios y ser´ a capaz de proceder con la planeaci´on del desarrollo. El equipo ser´a capaz de hacer mejores compromisos negocio/funciones/tecnolog´ıa a lo largo del proyecto y generar´a un producto m´as deseable.

Objetivos del proyecto con la direcci´ on. * Sistema que controle costos de alimentos. Log´ıstica de confecci´ on del men´ u. Procedimientos. Administraci´ on del banquete: Registro, cotizaci´on, contrataci´on, consecuci´on del banquete.

65

* Atacar oportunidades de negocio: Precios competitivos Productos de alta calidad Servicios de alta calidad * Control sobre tienda comercializadora Compras Pedidos a proveedores Control sobre sucursales Servicio a domicilio: v´ıa telef´ onica y por internet. Objetivos del proyecto con la comercializaci´ on * Parte p´ ublica Portal web del restaurante: informaci´on general, informaci´on de contacto, reservaciones y solicitudes disponible para el p´ ublico en general.

* Parte interna Recetas (ingredientes, procedimiento, responsable). Plan de realizaci´ on de recetas diario, cantidad de ingredientes por n´ umero de personas. Posmortem de la realizaci´ on de recetas: ganancias, recetas generadas. Manejar un catalogo de insumos con sus entradas y salidas en la bodega. Manejar todas las etapas del banquete, Reportes y consultas del estado del almac´en. Reportes y consultas sobre las recetas, platillo(s) exitoso(s) y peor platillo.

66

A continuaci´ on se mencionan las metas de la direcci´on que se tienen que cumplir para el proyecto: Metas de la direcci´ on del Proyecto Min´ımas

Medias

Ideales

Control de las recetas

Control de las recetas

Control de las recetas

Procedimientos

Procedimientos

Administraci´ on del banquete

Administraci´ on del banquete Control sobre tienda comercializadora Control sobre sucursales Servicio a domicilio

67

2.3.2.

Junta 2 del Taller de Lanzamiento

Los objetivos que se trataron en esta junta fueron los siguientes: Revisi´ on de las metas de la direcci´ on. Una vez concluida la junta 1, el equipo revis´o las metas de la direcci´on, una vez terminado con el an´alisis se llegaron a concretizar las siguientes metas:

METAS DE DIRECCION Control de los costos de los alimentos Atacar las oportunidades de negocios Control sobre tienda comercializadora Control sobre sucursales Controlar entregas a domicilio Control de banquetes Fecha de entrega (1 de Diciembre) Disponer de un portal del restaurante Incrementar las ventas Disponer de un sistema f´acil de utilizar(desde cualquier punto) Administrar entradas y salidas del almac´en Administrar los banquetes Disponer de la log´ıstica para la confecci´on de los men´ us Administrar los pedidos a proveedores

68

Definici´ on de metas impl´ıcitas. A pesar de que la direcci´ on dio al equipo sus metas expl´ıcitas en la primer junta , se puntualizaron aquellas metas que , tal vez, de manera inconsciente la direcci´on expuso al equipo y que son de vital importancia para realizar, por ejemplo, una mejor estimaci´on de los tiempos de desarrollo. Al realizar un amplio an´ alisis se obtuvieron las siguientes metas impl´ıcitas:

METAS IMPLICITAS Controlar la seguridad del sistema Disponer del portal en cualquier momento (24Hrs., 365d´ıas) Disponer de un portal del restaurante f´acil de mantener Contar con un sistema cuyos tiempos de respuesta sean los adecuados Contar con diferentes niveles de administraci´on del sistema Contar con un sistema que realice pago en l´ınea

Establecimiento de las metas del equipo. Aunque las metas que la direcci´ on otorga al equipo son importantes, no se puede dejar a un lado aquellas metas que el equipo desea llegar a cumplir, ya que influyen de manera directa en todo el proceso de construcci´ on de una nueva aplicaci´on y es por esta raz´on que nosotros como equipo de TSP nos hemos planteado como metas los siguientes puntos:

METAS DEL EQUIPO Ejercitar el TSP Entregar un producto de calidad Entregar el proyecto con los requerimientos m´ınimos Crear nuestro propio est´andar de codificaci´on Tener jornadas de trabajo para el proyecto razonables Evitar conflictos Estas metas se encuentran registradas en la Forma GOAL del libro de trabajo de TSP. 69

Selecci´ on de los roles del equipo.

A pesar de que todo el equipo ha recibido el entrenamiento PSP es necesario designar el rol que cada uno de los integrantes debe jugar dentro del mismo, ya que se est´a trabajando en equipo. En la siguiente tabla se pueden observar las personas asignadas a cada uno de los roles tanto como a la persona responsable y al suplente de cada uno de ellos.

ROLES DEL EQUIPO

RESPONSABLES

Lider oficial

P

Aida

del equipo

A

Armando

Administrador de la

P

Ricardo

Interfaz con el cliente

A

Julio

Administrador

P

Rafael

del Dise˜ no

A

David

Administrador de

P

Oscar

Implementaci´on

A

Ricardo

Administrador de

P

Fabian

la Planeaci´on

A

Rafael

Administrador del

P

Edgar

Proceso

A

Fabi´an

Administrador de

P

Juli´an

la Calidad

A

Edgar

Administrador de

P

Julio

Soporte

A

Oscar

Administrador de

P

Armando

Pruebas

A

Juli´an

Donde: P Principal responsable del rol. A Alternativa de la responsabilidad del rol.

70

Asignaci´ on de la responsabilidad de seguimiento de las metas.

Como el punto lo indica, se tuvo que asignar a la(s) persona(s) responsable(s) de dar seguimiento a una meta en especial, esto se hace para ver si se cumplen o no las metas mencionadas en puntos previos, en caso de que no se est´en cumpliendo tomar las adecuadas decisiones y/o acciones para poder cumplir dichas metas. A continuaci´ on se enlistan las metas m´as importantes para el equipo as´ı como el responsable de su seguimiento: Tabla de asignaci´ on de la responsabilidad de seguimiento de las metas.

71

2.3.3.

Junta 3 del Taller de Lanzamiento

Las actividades que se realizaron durante la junta 3 fueron: Dise˜ no Conceptual del producto restaurante LUCAS En esta etapa se definieron los principales componentes del producto,en base al an´alisis realizado por el equipo de desarrollo del sistema, se realiz´o el siguiente modelo conceptual, el cual cumple con todos los requerimientos.

A: Altas B: Bajas C: Cambios Estimaci´ on gruesa del tama˜ no de cada componente. En este punto se realiz´ o una estimaci´on de tama˜ no de cada uno de los componentes escritos en el dise˜ no anterior, cabe se˜ nalar que esta la primera estimaci´on no se realiza detalladamente, resultando ser una estimaci´ on ”gruesa”, a continuaci´on se muestran los resultados de dicho aproximado de l´ıneas de c´odigo por m´ odulo:

72

Tabla de estimaci´ on gruesa del tama˜ no de cada componente. Sistema Web restaurante:

400

L´ıneas

Recetas Vs Insumos:

1200

L´ıneas

Costo Recetas:

300

L´ıneas

Recetas:

200

L´ıneas

A: Altas recetas

500

L´ıneas

B: Bajas recetas

350

L´ıneas

C: Cambios recetas

600

L´ıneas

Banquetes:

250

L´ıneas

Lista Plantilla

500

L´ıneas

Control de almac´en:

200

L´ıneas

A: Altas almac´en

500

L´ıneas

B: Bajas almac´en

350

L´ıneas

C: Cambios almac´en

600

L´ıneas

P: Pedidos

400

L´ıneas

Seguridad:

800

L´ıneas

Log´ıstica:

350

L´ıneas

Cotizaci´on:

300

L´ıneas

Registro:

600

L´ıneas

Contrataci´on:

400

L´ıneas

Total de l´ıneas de c´ odigo:

800

L´ıneas de c´odigo

Definici´ on de la estrategia de desarrollo del producto. La estrategia elegida nos sirvi´ o para registrar las dediciones estrat´egicas, as´ı como asignar las funciones del producto dentro de los ciclos de desarrollo que m´as adelante nos servir´ıa para un dise˜ no de alto nivel. En la siguiente tabla se muestran los resultados, componentes o elementos principales del producto, el numero de ciclos de desarrollo, tama˜ no estimado (LOC’S) y horas de desarrollo del producto, que fueron incluidos en cada ciclo. Definici´ on del proceso de desarrollo Aqu´ı se defini´o el proceso general de desarrollo hasta la entrega final. 73

LOC del Ciclo

1

Componente, Elemento o Caracter´ıstica

Recetas VS Insumos

2

3

700

500

Horas del Ciclo

4

1

Costo Recetas

300

Seguridad

200

Recetas

100

Altas recetas

500

17

Bajas recetas

350

12

2

3

23

17

7

7

4

10 200

200

200

100

7 3

600

Cambios recetas

7

3

20

La siguiente tabla muestra las principales actividades de cada fase. 1

Contador de LOCs WEB.

2

Seguimiento de defectos en EXCEL.

3

Revisi´ on de requerimientos.

4

Revisi´ on de dise˜ no de alto nivel.

5

Check List de revisi´on de requerimientos.

6

Check List de revisi´on de dise˜ no de alto nivel.

7

Check List de inspecci´on de dise˜ no de alto nivel.

8

Check List de inspecci´on de codificaci´on.

9

Check List de inspecci´on de requerimientos.

10

Check List de inspecci´on de dise˜ no de nivel detallado.

Los elementos mostrados anteriormente pueden ser utilizados como un punto de inicio y pueden posteriormente ser refinados conforme sea necesario. Definici´ on del plan de desarrollo del producto En este punto se enlistaron los elementos del proceso que se planearon desarrollar y/o modificar, se determinaron y registraron el numero de elementos y numero de paginas a ser modificados y desarrollados nuevos, la fecha o fase en que se necesito, horas requeridas para el desarrollo, modificaci´ on, y la asignaci´on de cada ingeniero los elementos a desarrollar. Definici´ on del plan de soporte Se revisaron las herramientas e instalaciones disponibles para el desarrollo del producto. 74

LOC del Ciclo

2

3

Horas del Ciclo

Componente, Elemento o Caracter´ıstica

1

4

Control Almac´en

100

Altas Almac´en

500

17

Bajas Almac´en

350

12

100

1

2

3

3

4

3

Actualizaci´ on Almac´en

600

20

Pedidos

400

13

Banquetes

250

8

Log´ıstica

350

12

Cotizaci´ on

300

10

Registro

600

20

Contrataci´ on

400

13

Lista de Platillos

500

17

Restaurante

100

100

100

100

3

3

3

3

TOTAL

2500

3150

2850

300

84

105

94

10

Equipo 5 equipos en el LIS 5 equipos personales Requerimientos Word STAR UML Dise˜ no STAR UML

75

Codificaci´ on Ambiente Eclipse(3.3.1.1) plug-in J2EE para eclipse plug-in sub-versi´ on Base de datos MySQL 5.2 Pruebas Word, Excel Control de Versiones subversi´ on Servidor Tomcat 5

76

2.3.4.

Junta 4 del Taller de Lanzamiento

Los objetivos que se trataron en la presente junta fueron: Estimaci´ on de tama˜ no de cada elemento de la forma SUMS Para cada uno de estos elementos el administrador de dise˜ no gui´o al equipo para llevar acabo esta tarea, la siguiente tabla muestra cada uno de los estimados para cada uno de los elementos del sistema referente al numero de LOC‘s: # de LOC’s estimado Costos recetas

300

Seguridad

800

Recetas Vs. Insumo

1200

Recetas

200

Banquetes

250

Lista Platillos

500

Control Almac´ en

200

Altas Recetas

500

Bajas Recetas

350

Cambios Recetas

600

Log´ıstica

350

Cotizaci´ on

300

Registros

600

Contrataci´ on

400

Altas Almac´ en

500

Bajas Almac´ em

350

Cambios Almac´ en

600

Pedidos

400

Restaurante

400

En dicha forma (ver Anexo 2) tambi´en podemos encontrar los estimados para cheklist de revisi´ on de requerimientos, as´ı como un cheklist de inspecci´ on de codifiaci´ on, plan de prueba y reporte de las mismas, est´ andares de dise˜ no y codificaci´ on, total de LOC´s del sistema, p´ aginas de requerimientos, dise˜ no de alto nivel, etc.

77

Producir el plan de tareas El siguiente objetivo de la junta es producir un plan de tareas detallado para la duraci´ on del proyecto, para cada una de estas tareas el administrador de planeaci´ on gu´ıa al equipo a determinar el tiempo requerido para su elaboraci´ on, para llevar a cabo esto se usaron datos sobre la tasa de producci` on de cada uno de los integrantes y mediante la media poder estimar su tiempo de elaboraci´ on, los datos del plan de tareas se guarda en la forma Schedule(ver anexo 9.2.3).

78

2.3.5.

Junta 5 del Taller de Lanzamiento

El prop´ osito de la junta 5 fu´e generar los siguientes entregables: Producir el plan de calidad Se han establecido los datos de calidad las cuales son las siguientes: • Tener como m´ınimo el 80 % de las palntillas para el portal • Tener como m´ınimo un 60 % de los requerimientos • Tener una seguridad para las transacciones del 100 % • Tener una densidad de defectos m´ınimos de 20 def/KLOC • Y las jornadas de trabalo ser´an de 18 horas a la semana El programa tendr´ a 9400 LOC‘s, y la cantidad de defectos introducidos y eliminados es de 930. Los ´ındices de calidad que deber´ an estar observando durante la realizaci´on del proyecto ser´an mostrados en la siguiente tabla: Defects/KLOC

Plan

DLD Review

0.35

DLD Inspection

0.11

Code Review

66.06

Compile

14.16

Code Inspection

9.91

Unit Test

3.82

Build and Integration Test

0.34

System Test

0.07

Total Development

98.96

Acceptance Test

0.01

Product Life

0.01

Total

98.98

79

La tabla anterior muestra los defectos esperados por KLOC en cada una de las fases del proyecto, se deber´ an estar monitoreando constantemente ya que de sobrepasar nuestros estimados, obtendremos autom´ aticamente un producto de baja calidad,cabe se˜ nalar que los datos mostrados de la tabla anterior y algunos otros se almacenan en la forma SUMQ (ver anexo 9.3). Producir el calendario de trabajo En este punto no se hace m´as que establecer fechas aproximadas en las que se tendr´ an disponibles ciertos elementos del sistema que se desarrolla.

80

2.3.6.

Junta 6 del Taller de Lanzamiento

El prop´ osito de la junta seis fu´e ayudar al equipo a producir un plan balanceado de tareas para la siguiente fase. Los pasos para conseguir este prop´osito fueron los siguientes: Asignaci´ on de las tareas a los miembros del equipo El administrador de planeaci´on asigno cada una de las tareas de la hoja TASK a los integrantes del equipo, quedando la hoja EXCEL como se muestra en la figura siguiente.

Elaboraci´ on de copias del Workbook el administrador de planeaci´on gener´o copias del Workbook para cada uno de los integrantes del equipo aprimiendo el bot´on Make copies of Workbook for team members en la planilla Team. (Previamente en la hoja TEAM se crean los nombres de las hojas de c´alculo de cada integrante del equipo). Miembros del equipo hacen planes individuales Cada integrante del equipo elimino de su hoja EXCEL las tareas que no le correspond´ıan y posteriormente asigno la cantidad de horas que ten´ıan planeado trabajar semanalmente hasta que la diferencia de horas en la planilla Shedulle arrojo resultados negativos. Balanceo de carga de trabajo de el equipo El administrador de planeaci´on gui´o al equipo para obtener un plan balanceado de trabajo, es decir, que no hubiera una diferencia mayor de una semana a la fecha planeada de terminaci´ on del proyecto, en promedio la planeaci´on de trabajo de los integrantes del equipo fu´e de 13 semanas. 81

Consolidaci´ on de las tareas Una vez que se logro el balanceo de las tareas, el administrador de planeaci´ on presiono el bot´ on Consolidate plan en la plantilla TEAM, los resultados obtenidos en la plantilla SCEDULE fueron 1168 horas planeadas en 13 semanas.

82

2.3.7.

Junta 7 del Taller de Lanzamiento

Los temas de la junta 7 son los siguientes: Conducir una evaluaci´ on de riesgo del proyecto Es importante resaltar que para identificar los riesgos todos los integrantes del equipo participan y no importa si el riesgo es muy peque˜ no o muy grande pues primero sabemos cual es y despu´es se definir´an que grado de impacto tiene cada uno de ellos EL coach ayuda mucho en este tipo de decisiones pues de repente se puede perder el concepto o ser repetitivo a continuaci´on se enuncian los pasos Identificaci´ on de riesgos El l´ıder del equipo le pide al equipo que identifique riesgos. • Todos los miembros del equipo participan en sugerir riesgos. • Use un enfoque de lluvia de ideas; i.e., en este paso no eval´ ue riesgos. • El proceso contin´ ua hasta que no puede pensarse en m´as riesgos. • Registre cada riesgo para ayudar al equipo en la evaluaci´on subsiguiente. Use un rotafolios o un pizarr´ on blanco. Evaluaci´ on del Impacto Para cada riesgo, el equipo eval´ ua su impacto probable. • El impacto es alto si el efecto sobre el calendario de trabajo del proyecto fuera importante. • Los riesgos tambi´en pueden tener impacto medio o bajo en el calendario de trabajo. • Anote la evaluaci´ on del impacto. Use un rotafolios o un pizarr´on blanco. Evaluaci´ on de la Probabilidad Para cada riesgo, el equipo juzga su probabilidad La probablilidad se mide como alta, media o baja. Anote la evaluaci´ on de la probabilidad. Use un portafolios o un pizarr´on blanco.

83

Asignaci´ on de Riesgos Para los riesgos de prioridad alta y media (i.e. alta-alta, alta-media, media-alta o media-media) • Asigne un miembro para darle seguimiento al riesgo • Defina una fecha l´ımite para la cual deben tomarse las acciones de mitigaci´on • Documente el riesgo, la responsabilidad y la fecha l´ımite en la forma ITL Resultado de los riesgos totales elegidos por el equipo 1

´ DESCRIPCION

2

NO HAY SUFICIENTES RECURSOS

3

FALTA DE CONOCIMIENTOS

4

RENUNCIA DE PERSONAL

5

INTEGRANTE ENFERMO

6

DESASTRE

7

FALTA DE EQUIPO

8

´ PERDIDA DE INFORMACION

9

´ ROBO DE INFORMACION

10

´ DE TAMANO ˜ FUERA DE RANGO ESTIMACION

11

´ DE LOS REQUERIMIENTOS INICIALES MODIFICACION

12

ENTREGA DE PROYECTO A DESTIEMPO

13

ROBO DE EQUIPO

14

´ EQUIVOCADA DE REQUERIMIENTOS INTERPRETACION

84

Ponderaci´ on del impacto y probabilidad de los riesgos En el presente punto se valora el impacto que tiene cada uno de los riesgos, as´ı como su ´ındice de probabilidad de ocurrencia; una vez cuantificados ambos par´ametros para cada riesgo se procedi´o a establecer uno o m´ as responsables que se dedicar´an a observar que el riesgo propio sea mitigado de acuerdo a la estrategia de mitigaci´on, tambi´en acordada en esta junta, y finalmente una fecha para dicho prop´ osito. A continuaci´ on se muestra toda esta informaci´on en una peque˜ na tabla que resume todo lo antes descrito: Impacto

Probabilidad

Asignaci´ on

Alto

Media

RH,AA

Medio

Media

OR,DN

Fecha

Mitigaci´ on

31-01-2008

Capacitaci´on o generaci´on de prototipos

Alto

Media

JJ,JD

20-01-2008

Media

Media

JJ,JD

Reajuste de planeaci´on

ALTO

MEDIA

EP,RG

Proceso de control de cambios

85

Respaldo autom´atico

2.3.8.

Junta 8 del Taller de Lanzamiento

El objetivo de esta junta es preparar la documentaci´on necesaria y al equipo para la junta con la direcci´on; se analiza y discute el material a presentar y que integrantes del equipo lo presentar´an Revisar´ a el proceso de lanzamiento y los productos del mismo Revisar´ a el plan del proyecto y cualquier pregunta o situaci´on conm este plan La documentaci´ on que se gener´ o para presentar a la direcci´on se realiz´o en base a la siguiente gu´ıa: El l´ıder del equipo encabeza la junta presentando de forma general los objetivos de la junta. Los miembros del equipo o el l´ıder de equipo presentan: Resumen breve del trabajo realizado durante el lanzamiento Se describen los productos generados durante el lanzamiento Se entregan copias de los materiales producidos durante el lanzamiento La asignaci´ on de los roles del equipo Metas establecidas e impl´ıcitas de la direcci´ on y metas del equipo Calendario de trabajo del equipo Plan de calidad del equipo Evaluaci´ on de riesgo del equipo Estrategias de desarrollo y plan de entrega De existir se presenta un plan alternativo con recursos adicionales Cuando se requerir´ıan recursos adicionales entrenados C´ omo los recursos adicionales mejorar´ıan el desempe˜ no de las metas Los riesgos identificados por el equipo La evaluaci´ on del equipo de los riesgos clave

86

Acciones de mitigaci´ on propuestas para cada riesgo clave La conclusi´ on mediante un resumen de los elementos clave del plan y los objetivos del reporte

Con esto se demostrar´ a a la direcci´ on que el equipo de trabajo ha hecho un plan pensado, realista y completo.

87

2.3.9.

Junta 9 del Taller de Lanzamiento

El objetivo de esta junta es obtener la aprobaci´on del plan de trabajo por parte de la direcci´on. Para lograr este objetivo se siguen los siguientes pasos El equipo revisa con la direcci´ on su plan de proyecto y cualquier pregunta o situaci´on sobre el plan, en este punto el l´ıder del equipo o un miembro del equipo entrega copias de los productos de lanzamiento, revisa el proceso de lanzamiento y describe c´omo fue generado el plan. El l´ıder del equipo o miembro del equipo resume las metas del proyecto • Metas establecidas e impl´ıcitas de la direcci´on • Un resumen del plan y metas del equipo • C´ omo el plan y metas del equipo se compara con las metas de la direcci´on Si la direcci´ on le pide al equipo modificar o proporcionar un plan alternativo, el equipo necesita comprender • Cambios deseados al plan de proyecto • Que recurso o contenido de trabajo modifica el plan original Si se prepar´ o un plan alternativo, el l´ıder del equipo o un miembro del equipo distribuye y revisa el plan alternativo y el impacto esperado. Bajo ninguna circunstancia el equipo debe estar de acuerdo con un nuevo calendario de trabajo o plan sin tomarse el tiempo de estudiar o re-planear el trabajo. El l´ıder del equipo o un miembro del equipo revisa cada uno de los riesgos clave del proyecto • Resumiendo las probabilidades e impacto en el calendario de los riesgos. • Analiza las recomendaciones de mitigaci´on para los riesgos de alto impacto. El l´ıder del equipo cuestiona si no hay preguntas y cierra la junta. Cabe se˜ nalar que si en cualquier momento de la junta la direcci´on acepta el plan de trabajo elaborado por el equipo la junta concluye inmediatamente a pesar de que aun se tenga material por ser expuesto o analizado; por lo tanto el criterio de salida de esta junta es el plan de trabajo aceptado por la direcci´on. 88

2.4.

FORMAS Y RESULTADOS

2.4.1.

Forma SUMP

´ Esta forma registra los datos estimados y reales de las partes del proyecto.

89

2.4.2.

Forma TASK

En est´a forma se registra el tiempo requerido para cada tarea y se calculan las horas totales de tareas del plan de proyecto.

90

2.4.3.

Forma Schedule

En ´esta forma se registran las horas semanales del calendario de trabajo, cada desarrollador puede tener diferentes horas totales.

91

2.4.4.

Forma SUMQ

La forma SUMQ almacena la informaci´on referente al plan de calidad, ´esta forma se llena durante la junta 5 del Taller de Lanzamiento de TSP.

92

Bibliograf´ıa

[WA00] A Discipline for Software Engineering, Watts S. Humhrey, Addison - Wesley, EE.UU. 2000.

93