Memoria Eduardo Miranda

UNIVERSIDAD DE SANTIAGO DE CHILE
FACULTAD DE INGENIERA
DEPARTAMENTO DE INGENIERA INFORMTICA

UN MODELO PARA LA ESTIMACIN DEL ESFUERZO EN
PROYECTOS DE DESARROLLO DE SOFTWARE

EDUARDO ANDRS MIRANDA PEREIRA

Profesor Gua: Dr. Hctor Antillanca

Santiago Chile
2012

Trabajo de titulacin presentado en
conformidad a los requisitos para obtener
el Ttulo de Ingeniero Civil en Informtica.

i

AGRADECIMIENTOS

Hay una fuerza motriz ms poderosa que el vapor, la electricidad y la energa atmica:
la voluntad.

En la etapa final de esta larga carrera, quisiera agradecerle a todos aquellos que
contribuyeron a hacerla ms amena. Aquellas personas que considero, ms que
compaeros de curso, amigos para toda la vida.

Le agradezco al Profesor Hctor Antillanca por su apoyo en el proceso de desarrollo del
Trabajo de Titulacin y a las Profesoras Correctoras: Sra. Consuelo Ramrez y Srta.
Mara Carolina Chamorro A., que contribuyeron en forma importante a la validacin y,
por ende, a la mejora del mismo.

Les agradezco a todas las personas que intervinieron directa e indirectamente en este
largo proceso.

Le agradezco a la vida por permitirme aprender cada da.

Le agradezco a mi familia por su apoyo.

Le agradezco a la ciencia por las respuestas que me ha dado, pero sobre todo, por las
preguntas que me regala a cada instante.

ii

RESUMEN

La contribucin fundamental que ha tenido en las ltimas dcadas, el desarrollo de
productos de software, no sera posible, si los proyectos que originaron dichos
productos, hubiesen fracasado antes de finalizarlos. Frente al alto porcentaje de
proyectos que no se completan en forma exitosa, 63% segn (Schwaber & Sutherland,
2012), una de las causas principales, corresponde a la deficiente planificacin. Una
forma de contrarrestar aquel punto dbil, es mejorar la precisin de las estimaciones. Por
ello, se desarroll un Modelo de Estimacin del Esfuerzo que permite, de acuerdo al
grado de informacin disponible, realizar distintas evaluaciones con distintos niveles de
exactitud. El mismo, se basa en conceptos como: Puntos de Funcin, Puntos de Casos de
Uso, COCOMO II y Lgica Difusa, entre otros.

Si bien el alcance de la solucin se centra, principalmente, en los proyectos
desarrollados en el Departamento de Ingeniera Informtica, los mtodos implementados
tienen un carcter genrico, es decir, pueden ser aplicados a cualquier proyecto de
desarrollo de software. Evaluados una serie de proyectos de la asignatura Proyecto de
Ingeniera de Software, los resultados arrojaron un porcentaje de precisin, que en
algunos casos fue cercano al 98%, donde los Mtodos de Puntos de Funcin,
demostraron ser ms exactos que los Mtodos de Puntos de Casos de Uso, especialmente
al promediar los resultados obtenidos.

El conjunto de mtodos analizados, diseados e implementados, busca simplemente
convertirse en una ayuda, en un punto de partida para investigar, en bsqueda de una
mejora continua e incremental de los mismos; valorando por sobre todo, la trascendencia
de las estimaciones de esfuerzo.
Palabras Claves: Mtodos de Estimacin; Puntos de Funcin; COCOMO II; Puntos de
Casos de Uso; Lgica Difusa
iii

TABLA DE CONTENIDOS

CAPTULO 1. INTRODUCCIN .......................................................................................................... 1
1.1 ANTECEDENTES Y MOTIVACIN .............................................................................................. 1
1.2 DESCRIPCIN DEL PROBLEMA .................................................................................................. 2
1.3 SOLUCIN PROPUESTA ................................................................................................................ 3
1.4 OBJETIVOS Y ALCANCE DEL PROYECTO ................................................................................. 5
1.4.1 Objetivo general ........................................................................................................................ 5
1.4.2 Objetivos especficos ................................................................................................................. 5
1.4.3 Alcances .................................................................................................................................... 6
1.5 METODOLOGAS Y HERRAMIENTAS UTILIZADAS ................................................................ 8
1.5.1 Metodologa a usar.................................................................................................................... 8
1.5.2 Herramientas de desarrollo ...................................................................................................... 9
1.5.3 Ambiente de desarrollo ............................................................................................................ 10
1.6 ORGANIZACIN DEL DOCUMENTO ........................................................................................ 10
CAPTULO 2. MARCO TERICO ..................................................................................................... 12
2.1 INTRODUCCIN ........................................................................................................................... 12
2.2 PRERREQUISITOS PARA LA ESTIMACIN DEL ESFUERZO ................................................ 13
2.3 PRINCIPALES DIFICULTADES EN LA ESTIMACIN DEL ESFUERZO ................................ 15
2.4 MTRICAS DE INGENIERA DE SOFTWARE Y APROXIMACIONES ................................... 17
2.4.1 Mtricas orientadas al tamao ................................................................................................ 19
2.4.2 Mtricas orientadas a la funcin ............................................................................................. 20
2.5 MODELOS, TCNICAS Y HERRAMIENTAS PARA LA ESTIMACIN DEL ESFUERZO ..... 21
2.5.1 Tcnica Delphi ........................................................................................................................ 21
2.5.2 Work Breakdown Structure (WBS) .......................................................................................... 23
2.5.3 Estimacin Bottom-up ............................................................................................................. 25
2.5.4 Modelamiento Paramtrico ..................................................................................................... 27
2.5.5 Herramientas de Estimacin Automatizada ............................................................................ 30
2.5.6 Estimaciones anlogas ............................................................................................................ 32
2.5.7 Estimacin basada en supuestos ............................................................................................. 34
2.5.8 Time Boxing ............................................................................................................................. 34
2.5.9 Heursticas............................................................................................................................... 35
2.6 PROBLEMAS EN LA ESTIMACIN DEL ESFUERZO EN PROYECTOS INFORMTICOS .. 36
2.7 CONCLUSIN ................................................................................................................................ 37
CAPTULO 3. DESARROLLO ............................................................................................................. 39
3.1 INTRODUCCIN ........................................................................................................................... 39
3.2 MTODO PUNTOS DE FUNCIN TRADICIONAL (PFT) ......................................................... 39
3.2.1 Anlisis del Mtodo Puntos de Funcin Tradicional .............................................................. 39
3.2.1.1 Cuenta de Puntos Funcin sin Ajustar ............................................................................................... 41
3.2.2 Diseo del Mtodo Puntos de Funcin Tradicional ................................................................ 44
3.2.3 Implementacin del Mtodo Puntos de Funcin Tradicional .................................................. 47
iv

3.2.3.1 Implementacin del Mtodo de Ajuste Tradicional ........................................................................... 52
3.2.3.2 Anlisis Diseo e Implementacin del Mtodo de Ajuste Modificado .............................................. 55
3.2.4 Puntos de Funcin Tradicional Mtodo de Ajuste COCOMO II............................................. 59
3.2.4.1 Anlisis .............................................................................................................................................. 59
3.2.4.2 Diseo ................................................................................................................................................ 62
3.2.4.3 Implementacin ................................................................................................................................. 64
3.2.5 Puntos de Funcin Tradicional Mtodo Indirecto .................................................................. 67
3.2.5.1 Anlisis .............................................................................................................................................. 67
3.2.5.2 Diseo ................................................................................................................................................ 76
3.2.5.5 Implementacin ................................................................................................................................. 76
3.3 PUNTOS DE FUNCIN MODIFICADO 1 (PFM1) ....................................................................... 80
3.3.1 Anlisis .................................................................................................................................... 80
3.3.1.1 Aproximacin a la Teora de los Conjuntos Difusos ......................................................................... 81
3.3.1.2 Anlisis de Puntos de Funcin Difusos.............................................................................................. 83
3.3.2 Diseo ....................................................................................................................................... 92
3.3.3 Implementacin ........................................................................................................................ 96
3.4 PUNTOS DE FUNCIN MODIFICADO 2 (PFM2) ....................................................................... 98
3.4.1 Anlisis .................................................................................................................................... 98
3.4.2 Diseo .................................................................................................................................... 100
3.4.3 Implementacin ..................................................................................................................... 103
3.5 PUNTOS DE CASOS DE USO VERSIN 1 ................................................................................. 105
3.5.1 Anlisis .................................................................................................................................. 105
3.5.1.1 Introduccin ..................................................................................................................................... 105
3.5.1.2 Clculo de Casos de Usos sin Ajustar .............................................................................................. 106
3.5.1.3 Clculo de Puntos de Casos de Uso Ajustados ................................................................................ 108
3.5.2 Diseo .................................................................................................................................... 108
3.5.3 Implementacin ..................................................................................................................... 110
3.6 PUNTOS DE CASOS DE USO VERSIN 2 ................................................................................. 118
3.6.1 Anlisis .................................................................................................................................. 118
3.6.1.1 Puntos de Tamao de Casos de Uso (PTCU)................................................................................... 118
3.6.1.2 Puntos de Casos de Uso Difusos (PCUD) ....................................................................................... 124
3.6.2 Diseo .................................................................................................................................... 127
3.6.3 Implementacin ..................................................................................................................... 131
3.7 CONCLUSIN .................................................................................................................................. 137
CAPTULO 4. RESULTADOS ........................................................................................................... 140
4.1 INTRODUCCIN ......................................................................................................................... 140
4.2 RESULTADOS DE LOS PROYECTOS ANALIZADOS ............................................................. 140
4.2.1 Resultados Proyecto de Denuncias Web ............................................................................... 141
4.2.1.1 Enunciado del Problema .................................................................................................................. 141
4.2.1.2 Mtodo de Puntos de Casos de Uso 1 .............................................................................................. 142
4.2.1.4 Mtodo de Puntos de Funcin ......................................................................................................... 149
4.2.2 Resultados Proyecto Sistema de Administracin de Informes ............................................... 151
v

4.2.3 Resultados Proyecto Sistema de Control de Recursos .......................................................... 158
4.2.4 Resultados Proyecto Sistema de Difusin Cultural ............................................................... 165
4.3 CONCLUSIN .............................................................................................................................. 173
CAPTULO 5. CONCLUSIONES ....................................................................................................... 178
5.1 ASPECTOS GENERALES ........................................................................................................... 178
5.2 CONCLUSIN ACERCA DE OBJETIVOS ESPECFICOS ....................................................... 181
5.3 TRABAJOS FUTUROS ................................................................................................................ 182
REFERENCIAS BIBLIOGRFICAS .................................................................................................. 184
APNDICES ...................................................................................................................................... 192
APNDICE A: TABLAS DEFUSIFICACIN MTODO 1................................................................ 192
APNDICE B: TABLAS DEFUSIFICACIN MTODO 2 ................................................................ 200
APNDICE C: DETALLE DEL RESULTADO MTODO INDIRECTO PROYECTO DENUNCIAS
WEB ..................................................................................................................................................... 207
APNDICE D: FACTORES DE CONVERSIN COCOMO II ........................................................... 213

vi

NDICE DE FIGURAS

Figura 2-1: Modelo de estimacin de ingeniera de software .......................................... 19
Figura 2-2: Paquete de Trabajo ........................................................................................ 24
Figura 3-1: Modelo de Puntos de Funcin (Kushal, 2007) .............................................. 44
Figura 3-2: Clculo de Puntos de Funcin Sin Ajustar .................................................... 45
Figura 3-3: Formulario Inicial del Mtodo de Puntos de Funcin ................................... 48
Figura 3-4: Detalle del formulario Inicial ........................................................................ 48
Figura 3-5: Inicio del Mtodo de Puntos de Funcin Tradicional ................................... 49
Figura 3-6: Validacin del tipo de entrada ....................................................................... 49
Figura 3-7: Validacin de campos nulos .......................................................................... 50
Figura 3-8: Validacin de abandono del sistema ............................................................. 50
Figura 3-9: Ingreso de 1 o n tipos de Entradas ................................................................ 51
Figura 3-10: Clculo de los Puntos de Funcin Sin Ajustar ............................................ 51
Figura 3-11: Ingreso de Datos para el Grado Total de Influencia ................................... 53
Figura 3-12: Validacin para el Grado de Influencia....................................................... 53
Figura 3-13: Validacin para completar la tabla de ponderadores de complejidad ......... 54
Figura 3-14: Clculo de los Puntos de Funcin Ajustados .............................................. 54
Figura 3-15: Validacin de Datos para la Nueva Versin del Grado Total de Influencia
.......................................................................................................................................... 56
Figura 3-16: Ingreso del Factor de Conversin y de las Horas Efectivas de Trabajo ...... 56
Figura 3-17: Asignacin del Porcentaje de Esfuerzo por Actividad ................................ 57
Figura 3-18: Resultados de la Estimacin ........................................................................ 58
Figura 3-19: Guardando los resultados en un archivo ..................................................... 58
Figura 3-20: Eleccin del Lenguaje de Programacin ..................................................... 64
Figura 3-21: Ingreso de Variables Escalares COCOMO II ............................................. 65
Figura 3-22: Ingreso de Multiplicadores de Esfuerzo ...................................................... 66
Figura 3-23: Clculo del Esfuerzo Mediante Ajuste COCOMO II.................................. 67
Figura 3-24: Formulario para el ingreso de los datos de las Entradas ............................. 77
Figura 3-25: Decisin entre ingreso de otra Entrada o de las Salidas .............................. 77
Figura 3-26: Formulario para el ingreso de los datos de las Salidas ................................ 78
Figura 3-27: Decisin entre ingreso de otra Salida o de las Consultas ............................ 78
Figura 3-28: Formulario para el ingreso de los datos de los Archivos Lgicos Internos 79
Figura 3-29: Decisin entre ingreso de otro Archivo Lgico Interno o de Interfaces ..... 79
Figura 3-30: Eleccin del Mtodo de Ajuste: .................................................................. 80
Figura 3-31: Nmero Difuso Trapezoidal ........................................................................ 84
vii

Figura 3-32: Nmero Difuso Trapezoidal para el trmino lingstico Medio, de 2 a 5
RETs ................................................................................................................................. 86
Figura 3-33: Funcin de Pertenencia para los nmeros difusos caso ILFs con 1 RET ... 88
Figura 3-34: Funcin de Pertenencia para los nmeros difusos caso ILFs desde 2 a 5
RETs ................................................................................................................................. 89
Figura 3-35: Funcin de Pertenencia para los nmeros difusos caso ILFs con 6 ms
RETs ................................................................................................................................. 89
Figura 3-36: Ingreso de Datos de entradas PF Modificado Directo ................................ 97
Figura 3-37: Ingreso de Datos para Mtodo Indirecto ..................................................... 97
Figura 3-38: Eleccin del Tipo de Mtodo de Puntos de Funcin ................................... 98
Figura 3-39: Ingreso de Datos de entradas PF Modificado Directo V2 ......................... 104
Figura 3-40: Ingreso de datos de los Actores ................................................................. 110
Figura 3-41: Validacin del Ingreso de los Actores....................................................... 111
Figura 3-42: Decisin entre ingreso de otro Actor o ingreso de Casos de Uso ............. 111
Figura 3-43: Pantalla de Ingreso de Casos de Uso ......................................................... 112
Figura 3-44: Validacin del Ingreso de Casos de Uso ................................................... 112
Figura 3-45: Decisin entre el ingreso de otro Caso de Uso o el paso a la Etapa de
Clculo de PCUSA ......................................................................................................... 113
Figura 3-46: Clculo de PCUSA .................................................................................... 114
Figura 3-47: Ingreso de Factores de Complejidad Tcnica ........................................... 114
Figura 3-48: Ingreso de Factores de Ambiente .............................................................. 115
Figura 3-49: Clculo de los PCUA ................................................................................ 115
Figura 3-50: Incorporacin del Factor de Conversin y de las Horas de Efectivas de
Trabajo ........................................................................................................................... 116
Figura 3-51: Asignacin de Porcentaje de Esfuerzo por Actividad ............................... 117
Figura 3-52: Visualizacin de los resultados de la estimacin. ..................................... 117
Figura 3-53: Grficos trapezoidales para los Actores y Precondiciones........................ 125
Figura 3-54: Grficos trapezoidales para los Escenarios y Excepciones ....................... 126
Figura 3-55: Grficos trapezoidales para las Postcondiciones ....................................... 126
Figura 3-56: Entradas para los Actores .......................................................................... 131
Figura 3-57: Decisin entre ingreso de otro Actor o una Precondicin ......................... 132
Figura 3-58: Eleccin entre el ingreso de otra Postcondicin o el clculo de PCUSA . 132
Figura 3-59: Eleccin del mtodo de clculo de los Puntos de Casos de Uso Sin Ajustar
........................................................................................................................................ 133
Figura 3-60: Ingreso de los Factores de Complejidad Tcnica ...................................... 133
Figura 3-61: Ingreso de los Factores de Ambiente ........................................................ 134
Figura 3-62: Valor de los Puntos de Casos de Uso Ajustados ....................................... 135
viii

Figura 3-63: Ingreso del Factor de Conversin y las Horas efectivas de trabajo mensual
........................................................................................................................................ 135
Figura 3-64: Clculo del esfuerzo en Horas o Meses-Hombre. ..................................... 136
Figura 3-65: Asignacin de porcentaje de esfuerzo por actividad. ................................ 136
Figura 3-66: Resultado final de la estimacin................................................................ 137

ix

NDICE DE TABLAS

Tabla 2.1: Principales Cost Drivers ................................................................................. 14
Tabla 2.2: Atributos de ajustes de la ecuacin de Bailey-Basili ...................................... 29
Tabla 3.1: Diferencias entre el Mtodo (Albrecht, 1979) y (Albrecht, 1983) ................. 40
Tabla 3.2: Componentes primarios en el Mtodo de Puntos de Funcin (IFPUG, 1994)41
Tabla 3.3: Clculo del Grado Total de Influencia ............................................................ 46
Tabla 3.4: Porcentaje de Tiempo por Actividad .............................................................. 47
Tabla 3.5: Variables Escalares COCOMO II ................................................................... 63
Tabla 3.6: Multiplicadores de Esfuerzo COCOMO II ..................................................... 63
Tabla 3.7: Criterio para determinar la complejidad en Archivos Lgicos ....................... 70
Tabla 3.8: Criterio para determinar la complejidad de las Entradas ................................ 72
Tabla 3.9: Criterio para determinar la complejidad de las Salidas y Consultas ............... 76
Tabla 3.10: Representacin del almacenamiento de los datos principales del mtodo ... 76
Tabla 3.11: Matriz de Complejidad de los Archivos Lgicos. ........................................ 85
Tabla 3.12: Valores de m
i
para el trmino lingstico muy alto ...................................... 87
Tabla 3.13: Matriz extendida de complejidad para los ILFs ............................................ 88
Tabla 3.14: Tabla de diferencias finitas para ILF ............................................................ 91
Tabla 3.15: Esquema de clculo de los Puntos de Funcin Modificados No Difusos ..... 93
Tabla 3.16: Complejidad de las Entradas ......................................................................... 94
Tabla 3.17: Complejidad de las Salidas ........................................................................... 94
Tabla 3.18: Complejidad de las Consultas ....................................................................... 95
Tabla 3.19: Complejidad de los Archivos Lgicos .......................................................... 95
Tabla 3.20: Complejidad de Interfaces ............................................................................ 96
Tabla 3.21: Resumen de clculo de los Puntos de Funcin Modificados No Difusos V2
........................................................................................................................................ 100
Tabla 3.22: Complejidad de las Entradas Mtodo 2 ...................................................... 101
Tabla 3.23: Complejidad de las Salidas Mtodo 2 ......................................................... 102
Tabla 3.24: Complejidad de las Consultas Mtodo 2 .................................................... 102
Tabla 3.25: Complejidad de los Archivos Lgicos Mtodo 2 ....................................... 102
Tabla 3.26: Complejidad de las Interfaces Mtodo 2 .................................................... 103
Tabla 3.27: Factor de Peso de los Actores sin Ajustar ................................................... 107
Tabla 3.28: Factor de Peso de los Casos de Uso sin Ajustar ......................................... 107
Tabla 3.29: Campos que se almacenan en la Primera Etapa del Proceso ...................... 108
Tabla 3.30: Factores de Complejidad Tcnica ............................................................... 109
Tabla 3.31: Factores de Ambiente ................................................................................. 109
Tabla 3.32: Clasificacin de Actores en PTCU ............................................................. 119
x

Tabla 3.33: Clasificacin de Precondiciones en PTCU ................................................. 120
Tabla 3.34: Clasificacin de los Escenarios en PTCU ................................................... 120
Tabla 3.35: Clasificacin de Excepciones en PTCU ..................................................... 121
Tabla 3.36: Clasificacin de Postcondiciones en PTCU ................................................ 122
Tabla 3.37: Factores Tcnicos (Braz & Vergilio, 2006) ................................................ 122
Tabla 3.39: Valores para Fusificacin de los Trminos ................................................. 125
Tabla 3.40: Entradas para los Actores y Precondiciones ............................................... 128
Tabla 3.41: Entradas para Escenarios, Excepciones y Postcondiciones ........................ 128
Tabla 3.42: Valor defusificacin complejidad de Actores ............................................. 128
Tabla 3.43: Valor defusificacin complejidad de Precondiciones ................................. 129
Tabla 3.44: Valor defusificacin complejidad de Escenarios ........................................ 129
Tabla 3.45: Valor defusificacin complejidad de Excepciones ..................................... 129
Tabla 3.46: Valor defusificacin complejidad de Postcondiciones ............................... 130
Tabla 3.47: Factores Tcnicos........................................................................................ 130
Tabla 3.49: xito y Fracaso en Proyectos Informticos (Domnguez, 2009), (Schwaber
& Sutherland, 2012) ....................................................................................................... 138
Tabla 4.1: Entradas Mtodo de Casos de Uso 1............................................................. 142
Tabla 4.2: Factores de Complejidad Tcnica ................................................................. 142
Tabla 4.3: Factores de Ambiente ................................................................................... 143
Tabla 4.4: Porcentaje por Actividad............................................................................... 144
Tabla 4.5: Esfuerzo por Actividad en Horas Hombre .................................................... 144
Tabla 4.6: Esfuerzo por Actividad en Meses-Hombre ................................................... 144
Tabla 4.7: Entradas Mtodo de Puntos de Casos de Uso 2 ............................................ 145
Tabla 4.8: Resultados PCUSA ....................................................................................... 145
Tabla 4.9: Factores de Complejidad Tcnica ................................................................. 146
Tabla 4.11: Resultados Puntos de Casos de Uso Ajustados .......................................... 147
Tabla 4.12: Esfuerzo por Actividad en Horas - Hombre ............................................... 147
Tabla 4.13: Esfuerzo por Actividad en Meses-Hombre ................................................. 147
Tabla 4.14: Esfuerzo por Actividad en Horas-Hombre ................................................. 148
Tabla 4.15: Esfuerzo por Actividad en Meses-Hombre ................................................. 148
Tabla 4.16: Resultados Caso Ingreso Directo de Complejidades .................................. 149
Tabla 4.17: Resultados Ingreso Indirecto de Complejidades ......................................... 150
Tabla 4.18: Entradas Mtodo Casos de Uso 1 ............................................................... 152
xi

Tabla 4.21: Porcentaje por Actividad ............................................................................ 153
Tabla 4.22: Resultado en Horas y Meses - Hombre....................................................... 154
Tabla 4.23: Entradas Mtodo PCU 2 ............................................................................. 154
Tabla 4.24: Resultados PCUSA ..................................................................................... 155
Tabla 4.27: Resultado PCU Ajustados ........................................................................... 156
Tabla 4.28: Resultado Final en Horas - Hombre............................................................ 156
1

CAPTULO 1. INTRODUCCIN

1.1 ANTECEDENTES Y MOTIVACIN

Un proyecto, en general, es esencialmente un conjunto de actividades interrelacionadas,
con un inicio y una finalizacin definida, que utiliza recursos limitados para lograr
un objetivo deseado. Sin embargo, un proyecto informtico es un sistema de cursos de
accin simultneos y/o secuenciales que incluye personas, equipamientos de hardware,
software y comunicaciones, enfocados en obtener uno o ms resultados deseables sobre
un sistema de informacin (Periss, 2001).

Si bien el problema de la estimacin del esfuerzo en Proyectos Informticos (y en
particular, en Proyectos de Desarrollo de Software) tiene una larga data, donde se podra
considerar como fecha inicial a la segunda mitad de la dcada de los 60, en la cual se
estableci el software como producto y aparecieron empresas dedicadas al desarrollo y
distribucin masiva del mismo (Barzanallana, 2009); no es hasta 1981 donde uno de los
precursores del anlisis del esfuerzo, establece una de las primeras aproximaciones para
proceder a la estimacin inicial de ste (Boehm, 1981).

Es altamente conocido que la gestin constituye uno de los parmetros ms relevantes al
momento de determinar el xito o el fracaso de un proyecto. Dentro de la gestin, la
planificacin juega un rol trascendental. Adems, la planificacin de un proyecto se basa
en una buena estimacin del esfuerzo requerido para realizarlo; de tal forma que dicho
proceso, es vital al momento de llevar a cabo cualquier proyecto de desarrollo de
software (Varas, 1995).

De hecho, se estima que no ms de un 20% de los proyectos informticos finalizan
exitosamente, el 80% restante finaliza de forma defectuosa o fracasa rotundamente y
2
CAPTULO 1: INTRODUCCIN

entre los aspectos que influyen en ello, se encuentra la deficiente (o poco precisa)
planificacin del proyecto (Thompson, 2006).

En los proyectos informticos, por ejemplo, se tiene que la tendencia a la disminucin de
los costos del hardware y al aumento de los costos del software provoca que el problema
se centre en los costos de personal para el desarrollo de las aplicaciones. La mayor parte
de los costos del software se encuentra en las horas de anlisis, diseo, programacin y
prueba que se deben utilizar para obtenerlo. Por ello, cuando se habla de estimacin de
costos, se hace referencia, principalmente, a las horas de trabajo requeridas para
construir el software (Barcel, 2005).

Por lo anterior, la determinacin del esfuerzo en Proyectos de Desarrollo de Software, es
trascendental para determinar el xito o el fracaso de un Proyecto Informtico.

1.2 DESCRIPCIN DEL PROBLEMA

A continuacin se proceder a explicar a nivel contextual el problema, adems de
realizar una primera aproximacin al enunciado propiamente tal.
A pesar del reconocimiento que se le otorga a la realizacin de una correcta
determinacin del esfuerzo en proyectos de desarrollo de software, los modelos
existentes actualmente, no han alcanzado gran aceptacin, de tal forma que, en muchos
casos, en particular, en proyectos de menor envergadura, se contina realizando
estimaciones en base a supuestos y no en base a modelos formales. Por ello, se hace
necesario crear un modelo que contribuya (dentro de lo posible) a mejorar en este
aspecto, enfocado principalmente en el plano local.

3

1.3 SOLUCIN PROPUESTA

La solucin propuesta contempla un minucioso anlisis de los distintos mtodos
existentes actualmente y utilizados a travs de la historia; pero enfocado en el
Departamento de Ingeniera Informtica, y en particular en proyectos desarrollados en la
asignatura de Proyectos de Ingeniera de Software.

Dicha solucin, se originar de un anlisis exhaustivo de las alternativas existentes, el
cual est contemplado entre los objetivos especficos del presente trabajo de titulacin.
sta, contempla una posible combinacin de los mtodos existentes, que aborden de
mejor forma el problema, como por ejemplo: puntos de funcin, puntos de
caractersticas o un mtodo innovador sustentado por el material bibliogrfico existente.

Por lo anterior, y como el origen de la solucin se basa en el anlisis de aquellas
alternativas que sean un aporte al desarrollo del trabajo de titulacin y no en una
decisin apresurada sobre las posibilidades existentes, se considera adecuada la solucin
propuesta.

Producto del alto grado de imprecisin existente en el rea de estimacin del esfuerzo en
proyectos informticos, debido al importante nivel de complejidad que presentan esta
clase de proyectos, la solucin propuesta, no puede pretender convertirse en la solucin
definitiva en este mbito. Solamente puede buscar contribuir dentro de los limitados
recursos disponibles (horas hombre, nivel de acceso a informacin de proyectos, entre
otros) y enfocado principalmente a casos del medio local (DIINF), como por ejemplo
aquellos desarrollados en la asignatura de Proyectos de Ingeniera de Software y no a
proyectos de gran envergadura, implementados a nivel mundial.

4

Adems, la solucin a construir se apoyar en un anlisis acabado de lo realizado en esta
rea hasta el momento (modelos tales como SLIM, Bailey-Basili y COCOMO, entre
otros). De tal forma, que el anlisis antes mencionado, constituye una herramienta en s
mismo para cumplir con el objetivo general del trabajo de titulacin. Esto, permitir
obtener las mtricas y variables ms relevantes a utilizar en el modelo que se
desarrollar. Una vez diseado ste, ser posible implementar un prototipo, que sea una
ayuda para la asignatura de Proyectos de Ingeniera de Software y eventualmente se
pueda aplicar a organizaciones reales.

Como medida de prueba o validacin del modelo, se contempla la posibilidad de la
aplicacin a diversos proyectos ya finalizados pertenecientes a la asignatura de
Proyectos de Ingeniera de Software. Cabe destacar que para la creacin del modelo se
utilizar principalmente el material bibliogrfico existente, debido al respaldo que
constituyen las fuentes desde donde se rescata la informacin.

De acuerdo al objetivo general planteado, que consiste en el Diseo de un Modelo para
la Estimacin del esfuerzo en Proyectos de Desarrollo de Software, el presente trabajo
de titulacin busca lograr un avance en un rea que hasta ahora ha tenido poco
desarrollo, es decir, la estimacin de proyectos informticos. Es importante destacar, que
una vez obtenido el modelo de estimacin del esfuerzo, se contempla el desarrollo de un
prototipo que ser aplicado a una serie de proyectos de la asignatura de Proyectos de
Ingeniera de Software, con lo que se busca generar una herramienta de ayuda a sta.
5

1.4 OBJETIVOS Y ALCANCE DEL PROYECTO

1.4.1 Objetivo general

Diseo de un Modelo para la Estimacin del Esfuerzo en Proyectos de Desarrollo de
Software.

1.4.2 Objetivos especficos

Para conseguir el objetivo general se plantean los correspondientes objetivos
intermedios:

1. Anlisis de metodologas y modelos existentes para la determinacin del
esfuerzo en Proyectos de Desarrollo de Software.

2. Determinacin de las principales mtricas utilizadas en Proyectos de Desarrollo
de Software en general.

3. Seleccin de mtricas y variables aplicadas al Medio Local para Proyectos de
Desarrollo de Software.

4. Realizacin de un modelo de estimacin del esfuerzo en Proyectos de Desarrollo
de Software enfocado en el Medio Local.

6

5. Construccin de un prototipo de estimacin del esfuerzo en Proyectos de
Desarrollo de Software enfocado en el Medio Local.

6. Aplicacin a una serie de proyectos desarrollados en la asignatura Proyectos de
Ingeniera de Software, y conclusin con respecto a ello.

1.4.3 Alcances

A continuacin se sealan los principales elementos considerados entre los alcances y
limitaciones.

- El modelo de estimacin del esfuerzo en proyectos de desarrollo de software se
elaborar en base, principalmente, a las variables o mtricas que se obtengan con
respecto a la correspondiente revisin bibliogrfica (papers indexados o libros,
principalmente).

- El tipo de proyectos que se considerar en el desarrollo del Modelo, corresponde
a aquellos que ya se encuentren finalizados. De tal forma de acotar el tiempo de
elaboracin del mismo.

- El modelo desarrollado se aplicar a un nmero determinado de proyectos de la
asignatura de Proyectos de Ingeniera de Software. Lo anterior, puede servir
como una herramienta de ayuda para la asignatura antes mencionada.

- La fase de implementacin corresponde al desarrollo de un prototipo, por
ejemplo un plug-in para una herramienta igual o similar a Excel perteneciente a
7

Microsoft Office, que permita aplicar el modelo diseado, de forma ms rpida y
cmoda al ingresar los datos de los proyectos analizados. En dicha
implementacin, no se considera reparar demasiado en aspectos grficos y de
usabilidad en general, debido a que este trabajo de titulacin se centrar,
mayormente, en el desarrollo de un Modelo para la Estimacin del Esfuerzo en
Proyectos de Desarrollo de Software.

- Solamente se busca contribuir dentro de los limitados recursos disponibles (horas
hombre, nivel de acceso a informacin de proyectos, entre otros) y enfocado
principalmente a casos del medio local (DIINF), como por ejemplo aquellos
desarrollados en la asignatura de Proyectos de Ingeniera de Software y no a
proyectos de gran envergadura, implementados a nivel mundial.

- Dentro de las limitaciones se considera adems, que no se considera una etapa de
mantencin, debido a que el trabajo de titulacin tiene plazos acotados y los
perodos de mantencin en general son procesos que persisten por aos.

- En el caso de la capacitacin, se deja planteado la posibilidad de que cada
estudiante que desee aplicar algunos de los mtodos implementados, lea en
profundidad la presente Memoria, donde se explicar en detalle cada uno de
ellos. No obstante, no se considera una explicacin presencial de ninguno de
estos.

8

1.5 METODOLOGAS Y HERRAMIENTAS UTILIZADAS

1.5.1 Metodologa a usar

Se utilizar una versin adaptada del modelo en cascada, debido a que ste cumple con
las caractersticas necesarias para completar el trabajo de titulacin, donde las etapas
estn rigurosamente definidas y es necesario completar cada una de ellas para pasar a la
siguiente. Cabe destacar, que de acuerdo al objetivo general del proyecto, donde se
busca obtener un Modelo para la Estimacin del Esfuerzo en Proyectos de Desarrollo
de Software y no un producto de software, se utilizar el modelo general en cascada y
no una metodologa en particular, debido a que stas se enfocan principalmente en la
obtencin de un producto de software, lo cual no se ajusta a la tipologa del proyecto.

Anlisis: consiste en la investigacin y el anlisis de las distintas metodologas y
mtodos de estimacin del esfuerzo existentes actualmente y elaborados a travs
de la historia. Esto, se obtendr a partir del material bibliogrfico existente y
servir de base para construir el modelo a desarrollar.

Diseo: en esta etapa se disear el Modelo para la Estimacin del Esfuerzo en
Proyectos de Desarrollo de Software, donde previamente se determinarn las
mtricas y variables a utilizar.

Implementacin: una vez realizado el modelo antes descrito, se proceder a
desarrollar un prototipo, como se mencion anteriormente. Un ejemplo de ello
sera un plug-in para alguna herramienta tipo Excel, que permita realizar la
9

estimacin del Esfuerzo en Proyectos de Desarrollo de Software de una forma
ms rpida y sistemtica; con el objetivo de ser aplicado a una serie de proyectos
desarrollados en la asignatura de Proyectos de Ingeniera de Software.

Pruebas: como no existe un cliente en particular, las pruebas se realizarn a
medida que se implementen cada uno de los mtodos y por lo tanto no se
contempla una etapa de verificacin. Solamente se comprobar que los clculos
sean correctos y no se presenten errores de codificacin. Dada las caractersticas
de las pruebas, no es posible reflejarlas directamente en la memoria, debido a que
no se posee una herramienta que permita realizar el proceso de manera
sistemtica dejando registro de aquello. Adems, cabe destacar, que el objetivo
principal del presente Trabajo de Titulacin es obtener un Modelo y no un
Producto de software. El prototipo se genera, solamente, como una forma de
complementar la investigacin realizada.

Como se mencion con anterioridad, se contempla aplicar la herramienta
desarrollada, en proyectos reales, implementados y finalizados en la asignatura
de Proyectos de Ingeniera de Software. De tal forma de validar el Modelo
construido y obtener conclusiones con respecto a ello. No obstante, dicho
proceso no se ajusta a la definicin formal de la Etapa de Pruebas.

1.5.2 Herramientas de desarrollo

- Herramientas de software utilizadas:
Sistema Operativo Windows 7 Ultimate.
Microsoft Excel 2007, para el manejo de los resultados y para la
elaboracin del plug-in implementado en base al modelo diseado.
Microsoft Word 2007, para la escritura de la memoria.
10

Microsoft Project 2007, para la elaboracin y mantencin de la carta
Gantt.
- Herramientas de hardware utilizadas:
Notebook ASUS cuyas caractersticas principales de hardware son las
siguientes:
Procesador Intel i7 Quad-core a una frecuencia base de 2.0 Ghz. 2.8 Ghz
con turbo boost.
500 GB de Disco Duro a 7200 RPM SATA.
8 GB de RAM. DDR3 (1333 Mhz).

1.5.3 Ambiente de desarrollo

El ambiente de desarrollo del trabajo es principalmente las dependencias del
Departamento de Ingeniera Informtica de la Universidad de Santiago de Chile. Bajo la
supervisin del profesor gua, el Dr. Hctor Antillanca.

1.6 ORGANIZACIN DEL DOCUMENTO

El presente documento se divide en cinco captulos, en los cuales se describe por completo
el trabajo realizado, considerando ste como el primero.
En el captulo 2, se presenta el marco terico donde se detallan y explican los conceptos y
temas abordados en el desarrollo del documento. Entre ellos, los diferentes modelos,
tcnicas y herramientas existentes para realizar estimaciones de esfuerzo, as como las
mtricas de software que se utilizan como parmetro fundamental para construirlos.
En el captulo 3, se presenta toda la documentacin asociada al desarrollo del trabajo,
describiendo el anlisis, diseo e implementacin de cada uno de los mtodos desarrollados
como producto del actual trabajo de investigacin.
11

En el captulo 4, se presentan los resultados obtenidos una vez que se han aplicado cada uno
de los mtodos propuestos, a proyectos de la asignatura de Proyectos de Ingeniera de
Software (PINGESO).
Finalmente, en el captulo 5 se exponen las conclusiones finales, luego de completar el
presente trabajo de titulacin, donde destaca la verificacin del cumplimiento tanto de los
objetivos especficos como del objetivo principal definidos inicialmente. Adems, se indican
posibles trabajos futuros en el rea explorada, que podran desarrollar otros memoristas.
12

CAPTULO 2. MARCO TERICO

2.1 INTRODUCCIN

En esta seccin se expondrn los avances y distintos enfoques que ha tenido la
estimacin del esfuerzo, a nivel histrico. Destacando entre ellas las aproximaciones
hechas en el campo de los proyectos informticos, en general.
Cabe destacar, que cada estimacin tiene un riesgo inherente asociado. El riesgo de
estimacin se mide por el grado de incertidumbre en las estimaciones cuantitativas
establecidas para recursos, costos y programa de trabajo. Si el mbito del proyecto se
comprende en forma deficiente o los requisitos del proyecto estn sujetos a eventuales
cambios, la incertidumbre y el riesgo de la estimacin se incrementan peligrosamente. El
planificador y, en forma ms importante, el cliente deben reconocer que la variabilidad
de los requisitos del software significa inestabilidad en costo y programa de trabajo
(Pressman, 2005).
Antes de referirse a los modelos propiamente tal, se describen algunos conceptos
fundamentales que permiten clarificar lo expuesto en la siguiente seccin.
Medicin: es el proceso mediante el cual se asignan nmeros o smbolos a los atributos
de entidades reales para definirlas de acuerdo a reglas claramente establecidas (Fenton,
1991).
Mtricas: proveen la base para la ingeniera de software y se refieren a una amplia gama
de medidas para evaluar objetivamente, software computacional (Pressman, 2001).
El tamao y el esfuerzo en un sistema de software, corresponden a dos trminos
diferentes pero correlacionados; el tamao mide que tan grande es el sistema (a travs de
distintas mtricas), mientras que el esfuerzo especifica cunto tiempo en horas, das o
13
CAPTULO 2: MARCO TERICO

meses hombre se requieren para finalizar un proyecto de un tamao determinado. (Jeng,
Yeh, Wang, Chu & Chen, 2010). Dada una tarea de un tamao similar, el esfuerzo
requerido para diferentes equipos de trabajo puede variar mucho, debido al nivel de
productividad de cada equipo. Por lo tanto, es el esfuerzo el que provee una referencia
ms til para la estimacin de costos en el proyecto, la planificacin del calendario,
entre otros (Molokken & Jorgensen, 2003). No obstante, la estimacin de costos en un
proyecto de software, no solamente obedece a la determinacin del esfuerzo (el cual
constituye un factor importante) sino a un gran nmero de otros elementos, algunos de
los cuales se describen en la siguiente seccin. Cabe destacar que en este trabajo de
titulacin slo se profundizar en el esfuerzo y no en los dems conceptos, debido a la
necesidad obvia de acotar el campo de trabajo.

2.2 PRERREQUISITOS PARA LA ESTIMACIN DEL ESFUERZO

La estimacin del esfuerzo en el desarrollo de software, puede ser visto desde varios
puntos de vista; desde la perspectiva organizacional por ejemplo, hay diversas formas de
mejorar la administracin de proyectos de software: asignacin de responsabilidades,
toma de decisiones, organizar el trabajo del proyecto, monitorear y auditar el desarrollo
de las tareas. Desde un punto de vista sociolgico y sicolgico: destaca el grado de
compromiso, cohesin en la organizacin grupal, estilo de liderazgo, por nombrar
algunos. Desde la perspectiva tcnica, tambin hay varios factores que considerar: la
disponibilidad de un buen equipo de diseo, programacin, pruebas y herramientas de
documentacin, adems de adecuados dispositivos de hardware, entre otros (Heemstra,
1992).

Hay muchos factores que influyen en el esfuerzo y duracin del desarrollo de software.
Varios prerrequisitos, deben ser cumplidos, para hacer frente a los problemas sealados
anteriormente y garantizar una base slida para predecir el esfuerzo, duracin y la
14

capacidad para desarrollar el proyecto de software. Los prerrequisitos son los siguientes
(Heemstra, 1992):

a) Conocimiento de las caractersticas de:
o El producto (software) que va a ser desarrollado
o Los medios de produccin
o El personal de produccin
o La organizacin de la produccin
o La organizacin del usuario para el cual se producir el producto

b) Disponibilidad de:
o Tcnicas y herramientas para la estimacin de costos del software
o Una forma de estructurar los cost drivers
o Un listado de drivers que comnmente son considerados como
importantes
o Algunas consideraciones generales

En la tabla 2.1 se aprecia adems un resumen con algunos de los cost drivers ms
importantes segn (Heemstra, 1992).
Tabla 2.1: Principales Cost Drivers
Producto Medios Personal Proyecto Usuario
- Tamao del
software
- Calidad requerida
- Volatilidad de los
requerimientos
- Complejidad del
software
- Nivel de
reusabilidad
- Cantidad de
documentacin
- Tipo de aplicacin
- Restricciones
computacionales
o Tiempo de
ejecucin
o Tiempo de
respuesta
o Capacidad de
memoria

- Uso de herramientas

- Calidad del
personal
- Experiencia
del personal
- Calidad de la
administracin
- Disponibilidad
del proyecto
- Requerimientos
de duracin del
proyecto
o Extensin
o Compresin

- Participacin
- Nmero de
usuarios
- Estabilidad de
la organizacin
de los usuarios,
procedimientos
y formas de
trabajo
- Uso de tcnicas
modernas de
programacin

- Base para el
control del
proyecto
- Experiencia del
usuario con la
automatizacin
15

Producto Medios Personal Proyecto Usuario
o Ocultamiento de
informacin
o Jefe del equipo
de programacin
o Programa
estructurado
o Diseo top-down
o Incremental
o Desarrollo
lineal
o Desarrollo de
software
o Creacin de
prototipos
o Organizacin
del proyecto
o Organizacin
matricial
- Nivel de
educacin en la
automatizacin

A continuacin se sealan brevemente, las principales dificultades de la estimacin de
proyectos de software, en general.

2.3 PRINCIPALES DIFICULTADES EN LA ESTIMACIN DEL
ESFUERZO

Existen mltiples razones que explican el por qu de la alta complejidad asociada al
desarrollo de estimaciones de software algunas de ellas se sealan a continuacin
(Heemstra, 1992):

1. Existe una ausencia de datos sobre proyectos de software completos. Este tipo de
datos puede apoyar la administracin de proyectos y la realizacin de
estimaciones.

2. Las estimaciones muchas veces son efectuadas apresuradamente, sin una
apreciacin por el esfuerzo requerido para hacer un trabajo creble. Adems,
frecuentemente se da el caso de que una estimacin se necesita antes de que
hayan especificaciones claras de los requerimientos del sistema. Por lo tanto, una
situacin tpica es que las personas que realizan las estimaciones, actan bajo
presin para desarrollar una estimacin muy rpidamente, de un sistema que no
comprenden completamente.
16

3. Especificaciones claras, completas y confiables son difciles de formular,
especialmente al inicio de un proyecto. Cambios, adaptaciones y adicin de
requerimientos, constituyen ms una regla que una excepcin: en consecuencia la
planificacin y el presupuesto tambin deben ser adaptados.

4. Las caractersticas del software y del desarrollo del software hacen que las
estimaciones sean difciles. Por ejemplo, el nivel de abstraccin, la complejidad,
la dimensionalidad del producto y proceso, aspectos de innovacin, entre otros.

5. Un gran nmero de factores tienen una influencia en el esfuerzo y el tiempo para
el desarrollo de software. Estos factores son denominados cost drivers
(direccionadores de costos). Algunos ejemplos son: el tamao y la complejidad
del software, el grado de compromiso y participacin de la organizacin usuaria
del sistema y la experiencia del equipo de desarrollo. En general estos
direccionadores de costos son difciles de determinar

6. Los cambios rpidos en las tecnologas de la informacin y en las metodologas
de desarrollo de software son un problema para la estabilizacin del proceso de
estimacin. Por ejemplo, es difcil predecir la influencia de un nuevo workbench,
de los lenguajes de cuarta y quinta generacin, de las estrategias de creacin de
prototipos, entre otros.

7. El encargado de la estimacin (generalmente el jefe de proyecto) es difcil que
tenga mucha experiencia en dicha rea, especialmente en proyectos grandes.
Debido a que los proyectos de gran tamao se realizan con poca frecuencia.

8. La tendencia de los desarrolladores de software hacia la subestimacin. Un
estimador tiende a considerar el tiempo que toma desarrollar una cierta parte de
software y luego extrapolar esta estimacin para el resto del sistema, ignorando
17

los aspectos no-lineales del desarrollo de software, como por ejemplo la
coordinacin y la administracin.

9. El encargado de la estimacin, estima el tiempo que debera demorar en
desarrollar una determinada tarea personalmente, ignorando el hecho de que un
gran porcentaje del trabajo ser desarrollado por personas con menos experiencia
que, por ende, tiene un ratio de productividad menor.

10. Existe la presuncin equivocada de que hay una relacin lineal entre la capacidad
requerida por unidad de tiempo y el tiempo disponible. Esto significa por
ejemplo, que el software desarrollado por 25 personas en 2 aos puede ser
completado por 50 personas en 1 ao. Esta suposicin es notoriamente errnea.
De acuerdo a (Brooks, 1975) el corolario principal es: Agregando gente a un
proyecto en forma tarda, solamente har que ste se retrase ms.

11. El encargado de la estimacin tiende a reducir sta en cierto grado, con el
objetivo de hacer una oferta econmica ms atractiva.

2.4 MTRICAS DE INGENIERA DE SOFTWARE Y
APROXIMACIONES

La ingeniera de software corresponde a la aplicacin de un enfoque sistemtico,
disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software
(Pressman, 2005). Las mtricas por otro lado, proveen la base para la ingeniera de
software y se refieren a una amplia gama de medidas para evaluar objetivamente
software computacional. El mayor desafo para estimar un proyecto TI es determinar el
tiempo y esfuerzo para el entregable ms grande del proyecto, el sistema de aplicacin.
18

El mantenimiento de sistemas y la instalacin de paquetes de software pueden
experimentar dificultades similares.
El desafo consiste en tratar de estimar algo que es lgico, ms que fsico y eso no estar
bien definido hasta las etapas posteriores del ciclo de vida del proyecto. La definicin
del alcance puede solamente proveer una vista a alto nivel de qu est y qu no est
dentro del lmite del alcance del proyecto. Los requerimientos especficos, en trminos
de caractersticas y funcionalidad, generalmente, no estarn bien definidos hasta que se
inicie la fase de diseo. Adems, la complejidad y los desafos tcnicos de implementar
estas caractersticas son desconocidos u optimistamente pasados por alto en las primeras
etapas del proyecto. Como resultado, estimar un proyecto TI puede ser como tratar de
golpear un blanco en movimiento, requiere de continuos ajustes para alcanzar dicho
objetivo.
Como se ilustra en la figura 2.1, la primera etapa para estimar una aplicacin TI es
determinar el tamao (Jones, 1998). Sin entrar en demasiados detalles en este punto,
debera ser intuitivo que tome ms esfuerzo (en trminos de calendario, recursos y
presupuesto) el construir un sistema ms grande que uno ms pequeo. Sin embargo, el
tamao de la aplicacin es slo una pieza del puzle de estimacin. Una buena parte de
tiempo y esfuerzo se gastar en caractersticas y funcionalidades que son ms complejas.
Como resultado de la mayor complejidad, el mayor tiempo y esfuerzo que ser gastado.
Las restricciones y varios y influyentes tambin afectarn el tiempo y esfuerzo
necesitado para desarrollar una aplicacin en particular. Estas restricciones pueden ser
atributos de la aplicacin (Jones, 1998) o incluir los procesos, personas, tecnologa,
entorno y calidad requerida del producto (Royce, 1998). Una vez que los recursos y el
tiempo estimado son conocidos, las actividades especficas o tareas pueden ser
secuenciadas con el fin de crear el calendario del proyecto y el presupuesto del mismo
(Marchewka, 2006).
19

Figura 2-1: Modelo de estimacin de ingeniera de software

2.4.1 Mtricas orientadas al tamao

Contar el nmero de lneas de cdigo en programas computacionales es la mtrica de
software ms tradicional y ampliamente usada para dimensionar el producto de la
aplicacin. Es tambin la ms controversial (Marchewka, 2006).
El desarrollo de mtricas que se asimilen con mtricas similares precedentes de otros
proyectos requiere elegir lneas de cdigo como valor de normalizacin. A partir de los
datos rudimentarios, se puede desarrollar un conjunto de mtricas simples orientadas al
tamao para cada proyecto: errores por KLDC (miles de lneas de cdigo), defectos por
KLDC, costo por KLDC, entre otras (Pressman, 2005).
Las mtricas orientadas al tamao no se aceptan universalmente como la mejor forma de
medir el proceso del software (Jones, 1986). La mayor parte de la controversia gira en
torno al uso de lneas de cdigo como medida clave. Los partidarios de la medida LDC
afirman que stas son un artefacto de todos los proyectos de desarrollo de software
20

que pueden fcilmente contarse, que muchos modelos de estimacin de software
existentes usan LDC o KLDC como entrada clave, y que ya existe un gran cuerpo de
bibliografa y datos publicados para LDC. Por otra parte, los detractores argumentan que
las medidas LDC dependen del lenguaje de programacin, que, cuando se considera la
productividad, castigan los programas bien diseados, pero ms cortos, que no pueden
amoldar con facilidad lenguajes que no provienen del proceso y cuyo empleo en la
estimacin requiere un nivel de detalle que sera difcil de lograr (es decir, el
planificador debe estimar que las LDC se producirn mucho antes de que el anlisis y el
diseo se hayan completado) (Pressman, 2005).

2.4.2 Mtricas orientadas a la funcin

Las mtricas de software orientadas a la funcin emplean como un valor de
normalizacin una medida de la funcionalidad que entrega la aplicacin. La mtrica
orientada a la funcin utilizada con mayor amplitud es el punto de funcin (PF). El
clculo del punto de funcin se basa en caractersticas del dominio de informacin y la
complejidad del software. (Pressman, 2005).
El punto de funcin, al igual que la medida LDC, es controversial. Los partidarios
afirman que el PF es independiente del lenguaje de programacin, caracterstica que lo
hace ideal para aplicaciones que utilizan lenguajes convencionales y no procedimentales,
y que se basa en datos que probablemente se conocern en una etapa ms temprana en el
ciclo de un proyecto, lo que hace al PF an ms atractivo como enfoque de estimacin.
Los detractores afirman que el mtodo requiere cierta prestidigitacin en cuanto a que
el clculo se basa en datos subjetivos ms que objetivos, que el conteo del dominio de
informacin (y otras dimensiones) puede ser difcil de recopilar despus del hecho y que
el PF no tiene significado fsico directo: es slo un nmero. (Pressman, 2005).

21

2.5 MODELOS, TCNICAS Y HERRAMIENTAS PARA LA
ESTIMACIN DEL ESFUERZO

En esta seccin se describen los distintos tipos de tcnicas, modelos y herramientas para
la estimacin del esfuerzo en proyectos informticos; aplicables, algunas de ellas, a todo
tipo de proyectos. stas, se ordenan cronolgicamente y de acuerdo al enfoque bajo el
cual se aborda el problema.

2.5.1 Tcnica Delphi

Creada en los aos 40 en EE.UU. Se comienza a utilizar en el campo del software a
partir de 1981 por Barry Boehm. (Pressman, 2005)
La tcnica Delphi involucra mltiples expertos quienes llegan a un consenso sobre un
tema o problema en particular. Aunque la tcnica Delphi es generalmente usada por
grupos que intervienen en la toma de decisiones, puede ser una herramienta til para
estimar cuando el tiempo y el dinero justifican el esfuerzo extra. (Roetzheim & Beasley,
1998).
Para estimar usando la tcnica Delphi, varios expertos necesitan ser reclutados para
estimar el mismo tem. Basado en la informacin suministrada, cada experto hace una
estimacin y entonces todos los resultados son comparados. Si las estimaciones son
razonablemente cercanas, pueden ser promediadas y usadas como una estimacin. De
otra forma, las estimaciones son redistribuidas a los expertos quienes discuten las
diferencias y entonces hacen otra estimacin. (Marchewka, 2006).
En general, estas iteraciones son annimas y pueden realizarse varias veces hasta que
alcanzar un consenso. No es sorprendente, que el usar la tcnica Delphi pueda tomar
ms tiempo y costar ms que la mayora de los mtodos de estimacin, pero puede ser
22

muy efectiva y proveer una certeza razonable cuando el asunto en cuestin es importante
y el margen de error es bajo. (Marchewka, 2006).
Segn (Alonso, 2009), dicha tcnica fue creada en los aos cuarenta en EE.UU. y se
comienza a utilizar en el campo del software a partir de 1981 por Barry Boehm.
Los pasos a seguir son:
- Un coordinador proporciona a cada experto una especificacin del proyecto
propuesto y un impreso para expresar su opinin.
- Los expertos rellenan el impreso de manera annima. Pueden hacer preguntas al
coordinador pero no entre ellos.
- El coordinador ofrece a cada experto el valor medio de las opiniones recogidas.
Se pide una nueva estimacin annima indicando las razones de las posibles
modificaciones.
- Se repite el proceso de recoleccin de opiniones hasta llegar a un consenso. No
se realizan reuniones en grupo en ningn momento.
Boehm propone un refinamiento a esta tcnica en 1981, denominada Delphi de banda
ancha, en donde los pasos a seguir son:
1. El coordinador proporciona a cada experto una especificacin del proyecto
propuesto y un impreso para expresar su opinin.
2. El coordinador rene a los expertos para que intercambien puntos de vista sobre
el proyecto.
3. Los expertos rellenan el impreso de manera annima.
4. El coordinador ofrece a cada experto el valor medio de las opiniones recogidas.
Se pide una nueva estimacin annima, sin indicar las razones de las posibles
modificaciones.
5. El coordinador convoca una reunin para que los expertos discutan las razones
de las diferencias entre sus estimaciones.
23

6. Se rellenan annimamente los impresos y se repite los puntos 4, 5 y 6 hasta
llegar a un consenso.

2.5.2 Work Breakdown Structure (WBS)

Una de las primeras aproximaciones al concepto de Work Breakdown Structure nace en
el documento para el Sistema PERT/COST publicado por la NASA en 1962 (Stretton,
2007). WBS se caracteriza por proveer una estructura jerrquica que esboza las
actividades o trabajo que se necesita realizar para completar el alcance del proyecto.
WBS tambin provee un puente o conexin entre el alcance del proyecto y el plan
detallado del proyecto que se convertir en un paquete de software de administracin de
proyectos.
Una vez que se define el alcance del proyecto, el siguiente paso es precisar las
actividades o tareas que el equipo del proyecto debe realizar para completar los
entregables requeridos. Work Breakdown Structure (WBS) es una herramienta til para
desarrollar el esquema del proyecto y las conexiones entre el alcance del proyecto, el
calendario y el presupuesto.
El WBS representa una descomposicin lgica del trabajo que se realizar; se enfoca en
cmo el producto, servicio, o resultado debiera ser subdividido. Es un esquema del
trabajo que va a ser realizado. El WBS provee un framework para desarrollar un plan
tctico y as poder estructurar el trabajo del proyecto (Haugan, 2002).

- Paquetes de trabajo: WBS descompone, o subdivide, el proyecto en componentes
ms pequeos y unidades de trabajo ms manejables denominadas paquetes de
trabajo. Los paquetes de trabajo proveen una base lgica para definir las actividades
del proyecto y asignar recursos a estas actividades, de tal forma que todo el trabajo
24

del proyecto es identificado (Haugan, 2002). Un paquete de trabajo hace posible
desarrollar un plan de proyecto, calendario y presupuesto del proyecto, por ende
permite monitorear el progreso del mismo.
Como se ilustra en la figura 2.2, un paquete de trabajo puede ser visto como una
jerarqua que inicia con el proyecto mismo. El proyecto se descompone entonces en
fases, donde cada fase tiene uno o ms entregables. Ms especficamente, debera
proveer por lo menos un entregable en especfico, esto es, una pieza de trabajo
tangible y verificable. (Marchewka, 2006).

Figura 2-2: Paquete de Trabajo

Subsecuentemente, las actividades o tareas son identificadas con el fin de producir
entregables del proyecto.

- Entregables e hitos: constituye una de las salidas ms comunes en un WBS. Un hito
es un evento significativo o logro, que provee evidencia de que ese entregable ha
sido completado o que una fase es formalmente terminada.
25

Entregables e hitos estn relacionados estrechamente, pero no son lo mismo. Los
entregables pueden incluir presentaciones o reportes, planes, prototipos y la
aplicacin final del sistema. Un hito, por otro lado, debe enfocarse en un logro. Por
ejemplo, un entregable puede ser un prototipo de una interfaz de usuario, pero el
hito sera la aceptacin formal de un inversionista de dicha interfaz de usuario.
Solamente la aceptacin formal o aprobacin de la interfaz de usuario por el
patrocinador del proyecto permitir al equipo del proyecto avanzar a la siguiente
fase del mismo (Marchewka, 2006).
Una vez que los entregables del proyecto han sido definidos, la siguiente etapa en el
desarrollo del calendario y el presupuesto del proyecto ser estimar la duracin de
cada actividad. Una de las ms cruciales y difciles actividades en la administracin
del proyecto es estimar el tiempo que tomar completar una tarea en particular.
Dado que un recurso generalmente est asociado a una tarea en particular, un costo
asociado con dicho recurso debe ser asignado como parte del tiempo que toma
completar dicha tarea. El tiempo estimado para completar una tarea en particular
tendr una influencia directa sobre el presupuesto del proyecto (Marchewka, 2006).

2.5.3 Estimacin Bottom-up

Involucra estimar tems de trabajo individual y sumarlos para llegar al total del proyecto.
El tamao de los tems de trabajo individual y la experiencia de los estimadores,
manejan la precisin de las estimaciones. Si est disponible un WBS (Work Breakdown
Structure) detallado para un proyecto, el administrador del mismo podra tener cada
persona responsable para un paquete de trabajo desarrollando su propia estimacin de
costos para ese paquete de trabajo. Todas las estimaciones entonces seran sumadas para
crear estimaciones para cada tem WBS del nivel superior y finalmente para la totalidad
del proyecto. Usando tems de trabajo ms pequeos se incrementa la precisin de la
26

estimacin, porque la gente asignada a hacer el trabajo desarrolla la estimacin en lugar
de alguien poco familiarizado con el trabajo. El inconveniente con la estimacin
bottom-up, es que ellas involucran tiempo-intensivo y, por lo tanto, son caras de
desarrollar.
La mayora de las estimaciones del mundo real son hechas usando estimaciones tipo
bottom-up (Royce, 1998). Las estimaciones tipo bottom-up involucran dividir el
proyecto en mdulos ms pequeos y entonces directamente se estima el tiempo y
esfuerzo en trminos de horas-persona, semanas-persona, o meses-persona para cada
mdulo. El Work Breakdown Structure provee la base para la estimacin bottom-up
porque todas las fases del proyecto y las actividades estn definidas.
El administrador de proyecto, o mejor an el equipo de proyecto, puede proveer
estimaciones de tiempo razonables para cada actividad. En pocas palabras, la estimacin
bottom-up se inicia con una lista de todas las tareas o actividades requeridas y entonces
se hace una estimacin para la cantidad de esfuerzo que demandara cada una de ellas.
El tiempo total y el costo asociado para cada actividad proveen la base tanto para el
calendario como para el presupuesto, definidos previamente como objetivos del proyecto
(Brooks, 1995).
Las estimaciones estn en funcin de la actividad misma, los recursos y el apoyo
prestado. Ms especficamente, la duracin estimada de una actividad depender
primero de la naturaleza de la actividad en trminos de su complejidad y grado de
estructuracin. En general, las actividades altamente complejas y no estructuradas
tomarn ms tiempo en completarse que las actividades simples y bien estructuradas.
Los recursos asignados a una actividad en particular tambin influenciarn una
estimacin. Por ejemplo, asignando un individuo experimentado y bien entrenado a una
tarea en particular debera significar que menos tiempo es requerido para completarla
que si un novato fuese asignado. Sin embargo, experiencia y especializacin son
27

solamente parte de la ecuacin. Tambin se deben considerar elementos tales como el
nivel de motivacin de la persona y entusiasmo.
Finalmente, el apoyo entregado tambin influencia las estimaciones. El apoyo puede
incluir tecnologa, herramientas, entrenamiento, y el entorno fsico de trabajo
(Marchewka, 2006).

2.5.4 Modelamiento Paramtrico
Usa caractersticas de proyectos (parmetros) en un modelo matemtico, para realizar las
estimaciones. Un modelo paramtrico puede proveer una estimacin de 50 dlares por
lnea de cdigo para un proyecto de desarrollo de software basado en el lenguaje de
programacin que el proyecto est usando, el nivel de experticia de los trabajadores, el
tamao y complejidad de los datos involucrados, entre otros.
Los modelos paramtricos son ms confiables cuando los datos histricos que fueron
usados para crear el modelo son precisos, los parmetros son fcilmente cuantificables, y
el modelo es flexible en trminos del tamao del proyecto.
- Modelo SLIM

En 1978, Putnam desarroll un modelo de estimacin del esfuerzo total y del tiempo de
finalizacin para proyectos muy grandes. Las ecuaciones bsicas se pueden ajustar para
pequeos proyectos. El modelo asume que el esfuerzo para proyectos de desarrollo de
software se distribuye de forma similar a una coleccin de curvas de Rayleigh, una para
cada actividad del desarrollo. A partir de la frmula bsica de la curva de Rayleigh,
Putnam us observaciones empricas sobre la productividad para obtener su ecuacin
de software:

3 / 4
d
3 / 1
t CK tamao = (2.1)
28

Con C factor de tecnologa:
2000 para entornos de desarrollo pobres
8000 para entornos de desarrollo buenos
11000 para entornos de desarrollo excelentes

K: corresponde al esfuerzo total medio en tcnicos-ao
t
d
: corresponde al tiempo de finalizacin del proyecto, en aos.

La ecuacin anterior, permite valorar el efecto de modificar el tiempo de entrega y el
esfuerzo total necesario para completar el proyecto (Putnam, 1978).

- COCOMO

Barry Boehm (en 1981) desarroll el popular Constructive Cost Model (COCOMO), un
modelo paramtrico para estimacin de costos de desarrollo de software basado en
parmetros tales como las lneas de cdigo fuente o puntos de funcin. Puntos de
funcin son evaluaciones de tecnologa-independiente de las funciones involucradas en
el desarrollo de un sistema. Por ejemplo, el nmero de entradas y salidas, el nmero de
archivos mantenidos y el nmero de actualizaciones.
COCOMO es un ejemplo de modelo paramtrico porque usa variables dependientes,
tales como costo o duracin, basado en una o ms variables independientes que son
ndices cuantitativos de rendimiento y/o atributos fsicos del sistema. Frecuentemente,
los modelos paramtricos pueden ser refinados y bien calibrados para proyectos
especficos dentro de industrias especficas (Rad, 2002).
Para estimar con COCOMO se inicia determinando el tipo de proyecto a ser analizado.
Segn (Marchewka, 2006) los tipos de proyectos pueden ser clasificados como:
29

1: Orgnico: estos son proyectos rutinarios donde la tecnologa, procesos, y gente
son considerados para que trabajen todos juntos sin problemas.
2: De Integracin: un proyecto de integracin es visto como un proyecto desafiante.
Por ejemplo, puede ser un sistema para apoyar un nuevo proceso de negocio o un
rea que es un nuevo campo para la organizacin. La gente puede ser menos
experimentada, y los procesos y tecnologa pueden estar menos asimilados.

3: Semi-individualizado: si los proyectos orgnicos son vistos como fciles y los
proyectos de integracin como difciles o desafiantes, entonces los semi-
individualizados caen en algn lugar en el medio. Estos proyectos pueden no ser
simples y sencillos, pero la organizacin siente confianza que sus procesos, gente
y tecnologa son adecuadas para cumplir el desafo.

- Modelo de Bailey-Basili

Tambin en 1981, (Bailey & Basili, 1981) sugirieron una tcnica para obtener un
modelo de coste a partir de sus propios datos. La ecuacin 2.2 se obtuvo a partir del
esfuerzo calculado en 18 grandes proyectos.

E = 5.5 + 0.63 S
1.16

Dicha ecuacin, se ajusta mediante un Factor de Ajuste del Esfuerzo calculado a partir
de los atributos de la tabla 2.2. A cada entrada en la tabla 2.2 se le da una puntuacin de
0 a 5. Los valores obtenidos se usan para ajustar la ecuacin 2.3:
Ajuste del esfuerzo = a METH + b CPLX + c EXP + d
Tabla 2.2: Atributos de ajustes de la ecuacin de Bailey-Basili
Metodologa
(METH)
Complejidad acumulada
(CPLX)
Experiencia acumulada
(EXP)
Diagramas de rboles Complejidad de la interfaz
de usuario
Cualificacin del
programador
(2.2)
(2.3)
30

Metodologa
(METH)
Complejidad acumulada
(CPLX)
Experiencia acumulada
(EXP)
Diseo top-down Complejidad de la
aplicacin
Experiencia del
programador con la
mquina.
Documentacin formal Complejidad del flujo de
programa
Experiencia del
programador en el lenguaje
Equipos con programador
jefe
Complejidad de
comunicacin interna
Experiencia del
programador en la
aplicacin
Entrenamiento formal Complejidad de la base de
datos
Experiencia del equipo
Formalismos de diseo Complejidad de la
comunicacin externa

Lectura de cdigo Cambios en el diseo
solicitados por el usuario

Carpetas de desarrollo de
unidad

Planes de pruebas formales

2.5.5 Herramientas de Estimacin Automatizada

Un nmero de herramientas automatizadas puede ser usado para estimaciones de costo,
de calendario y de recursos. Estas herramientas incluyen hojas de clculo, herramientas
de administracin de proyectos, sistemas de administracin de base de datos, software
de estimacin de costos y herramientas de procesos o metodologas. Muchas de estas
herramientas no solamente ayudan a estimar, sino tambin le permiten a la organizacin
crear una base de datos o repositorios de proyectos pasados. De hecho, se encontr que
las estimaciones usualmente tienen una precisin de entre 5 y 10 por ciento cuando los
datos histricos son precisos. Adems, las herramientas de estimacin automatizadas son
generalmente ms conservadoras cuando no son precisas, al contrario de los mtodos
manuales que son generalmente optimistas (Jones, 1998).
Un ejemplo de herramienta computacional es COCOMO II, la cual constituye un
software basado en el modelo de Boehm que permite estimar el costo, esfuerzo y
31

calendario cuando se planifica una nueva actividad de desarrollo de software. Boehm
sugiere que solamente los modelos algortmicos y paramtricos no sufren de los lmites
de la capacidad humana de decisin-accin. Como consecuencia, Boehm y muchos otros
expertos en software favorecen el uso de modelos algortmicos cuando se estiman costos
en proyectos de software.
Como la complejidad de los proyectos de desarrollo de software se ha incrementado en
las ltimas dcadas, el mercado para las herramientas de estimacin de software tambin
ha aumentado. Algunas de las herramientas automatizadas disponibles incluyen
COCOMO II (descrito anteriormente), SLIM, CHECKPOINT, Knowledge Plan, y
Cost*Xpert. Las investigaciones sugieren que los proyectos que usan una herramienta de
estimacin formal tienen una mejor probabilidad de entregar un sistema que se completa
a tiempo y dentro del presupuesto (Marchewka, 2006).
Debido a la escasez general de informacin, es complejo poder determinar con un nivel
alto de precisin, la evolucin que han tenido las herramientas automatizadas de
estimacin de software en los ltimos aos y establecer una proyeccin acotada, de lo
que se puede esperar para el futuro. No obstante, si se consideran las cifras de la
altamente prestigiosa consultora Gartner, que indican, por ejemplo, que durante el 2010
el mercado mundial de software aument un 8%, que durante el 2011 el mercado de
software empresarial creci en cerca de un 10% y que el gasto en TI de las empresas
ser de 3.6 billones de dlares en el 2012, marcando un crecimiento de 3% a nivel
mundial (Manzhirova, 2012); es posible concluir, indirectamente, que el uso de mtodos
formales de estimacin, sean o no automatizados, ser un factor determinante que
contribuya a desarrollar proyectos exitosos en un contexto de altas cifras econmicas.
Las prdidas en un mercado tan dinmico y riesgoso pueden ser multimillonarias si no
se realizan planificaciones correctas, usando como base estimaciones precisas.
A los tipos de estimaciones anteriormente sealados, se pueden sumar los que se
exponen a continuacin, los cuales no tienen necesariamente una definicin formal, pero
son ampliamente utilizados.
32

2.5.6 Estimaciones anlogas

Tambin llamadas estimaciones top-down, usan el costo real de un proyecto previo y
similar como base para estimar el costo del proyecto real. Esto corresponde a una forma
de juicio experto. Este mtodo es generalmente menos costoso que otros, pero tambin
menos preciso. Las estimaciones anlogas son las ms confiables cuando los proyectos
previos son similares, de hecho y no slo en apariencia. Adems, los grupos que
preparan estimaciones deben tener la experticia necesaria para determinar si ciertas
partes del proyecto sern ms o menos costosas que los proyectos semejantes. Sin
embargo, si el proyecto que va a ser estimado involucra un nuevo lenguaje de
programacin o trabajo con un nuevo tipo de hardware o redes, la aproximacin anloga
podra resultar fcilmente en una estimacin poco certera (Schwalbe, 1999).
La estimacin top-down involucra estimar el calendario y/o costo del proyecto completo
en trminos de cunto tiempo debera tomar o cunto debera costar. La estimacin top-
down es un caso muy comn que con frecuencia se origina de un mandato hecho por la
alta direccin.
Con frecuencia, el calendario y/o estimacin de costos es producto de algn plan
estratgico o porque alguien piensa que debera demorar una cierta cantidad de tiempo o
costar una cantidad de dinero en especfico. Por otro lado, la estimacin top-down puede
ser una reaccin al entorno de negocio. Por ejemplo, el proyecto puede tener que ser
completado dentro de seis meses como resultado de las acciones de un competidor o
para ganar el negocio de un cliente (es decir, que el cliente necesite que el proyecto se
finalice en 6 meses).
Una vez que los objetivos en trminos de calendario o presupuesto estn identificados,
corresponde al director del proyecto asignar porcentajes a varias fases del ciclo de vida
del mismo y a las actividades o tareas asociadas. La informacin proveniente de los
proyectos pasados puede ser muy til en la aplicacin de porcentajes y asegurar que las
33

estimaciones sean razonables. Es importante tener en mente que la estimacin top-down
funciona bien cuando los objetivos son razonables, realistas y factibles. No obstante,
cuando es hecha por personas independientes del equipo de trabajo, estos objetivos son
con frecuencia, demasiado optimistas y demasiado agresivos. Estos objetivos poco
realistas llevan a la denominada marcha de la muerte del proyecto (Marchewka, 2006).
Los parmetros del proyecto incluyen calendario, personal, presupuesto u otros recursos,
y funcionalidad, caractersticas, requerimientos de rendimiento y otros aspectos del
proyecto. Una marcha hacia la muerte de un proyecto significa que una o ms de las
siguientes restricciones han sido impuestas (Yourdon, 1999):
- El calendario del proyecto ha sido comprimido a menos del 50 por ciento de su
estimacin original.
- El personal originalmente asignado o requerido para completar el proyecto ha
sido reducido a menos del 50 por ciento.
- El presupuesto y los recursos necesarios han sido reducidos en un 50 por ciento o
ms.
- La funcionalidad, caractersticas u otros requerimientos tcnicos o de
rendimiento son el doble de lo que deberan ser bajo circunstancias tpicas.
Por otro lado, la estimacin top-down puede ser una aproximacin muy efectiva para el
anlisis de costos y calendario (Royce, 1998). Ms especficamente, una aproximacin
top-down puede forzar al administrador del proyecto a examinar los riesgos del proyecto
ms estrechamente, de tal forma que un presupuesto o calendario especfico pueda ser
alcanzado. Comprendiendo los riesgos, ventajas y desventajas y sensibilidades
objetivamente, los diversos inversionistas del proyecto pueden desarrollar una
comprensin mutua que los lleve a mejores estimaciones. Este resultado, sin embargo,
requiere que todos los inversionistas tengan la voluntad de comunicarse y hacer
concesiones (Marchewka, 2006).

34

2.5.7 Estimacin basada en supuestos

Las estimacin basada en adivinar o en slo escoger nmeros del aire no es la mejor
forma para deducir el calendario y presupuesto del proyecto. Desafortunadamente
muchos administradores con poca experiencia en proyectos, tienden a estimar basndose
en supuestos, o a adivinar en las estimaciones, porque es rpido y fcil. El problema es
que el adivinar en las estimaciones se basa en sentimientos en lugar de evidencia
concreta.
Las personas son a menudo excesivamente optimistas y, por ende sus estimaciones son
excesivamente optimistas. Subestimar puede redundar en una duracin mayor de lo
esperado del proyecto, adems de reducir la calidad del producto, sumado a
especificaciones del cliente que resulten insatisfechas (Marchewka, 2006).

2.5.8 Time Boxing

El time boxing es una tcnica en donde una caja de tiempo es asignada para una
actividad o tarea especfica. Dicha asignacin est basada ms en un requerimiento que
slo en conjeturas. Por ejemplo, un equipo de proyecto puede tener dos (y solamente
dos) semanas para construir un prototipo. Al final de las dos semanas, el trabajo en el
prototipo se detiene, sin tener en cuenta si el prototipo est 100% completo.
Usado efectivamente, time boxing puede ayudar a concentrar el esfuerzo del equipo de
trabajo en una tarea importante y crtica. La presin del calendario para cumplir un plazo
en particular, sin embargo, puede resultar en un periodo ms largo de tiempo del
estimado y una mayor presin para alcanzar el xito. Usado inapropiadamente o con
demasiada frecuencia, los miembros del equipo de proyecto se desgastarn y se
frustrarn (Marchewka, 2006).
35

2.5.9 Heursticas

Las heursticas son reglas de oro. Se basan en el hecho de que las mismas actividades
bsicas sern requeridas por un proyecto tpico de desarrollo de software y estas
actividades necesitarn un porcentaje predecible del esfuerzo total (Roetzheim &
Beasley, 1998).
(Jones, 1998) provee un nmero de heursticas o reglas de oro para estimar proyectos de
software basadas en puntos de funcin. Algunas de estas reglas incluyen:
- Los requerimientos de usuario crecern en un promedio de 2 por ciento por mes
desde el diseo hasta las fases de codificacin.

- Cada etapa de prueba de software encontrar y remover el 30 por ciento de los
bugs que estn presentes.

- Cada inspeccin formal de diseo encontrar y remover el 65 por ciento de bugs
presente.

- Cada inspeccin formal de cdigo encontrar y remover el 60 por ciento de
bugs presente.

- Los programadores de mantenimiento pueden reparar ocho bugs por persona
mensual.
(Jones, 1998) hace una importante observacin: Las reglas de oro son fciles, pero no
son precisas.
Una estimacin precisa es una funcin de aplicar un proceso y reconocer que el esfuerzo
debe ser gastado en crear una lnea base de experiencia que permitir incrementar la
36

precisin de esos procesos. Estimar no requiere una bola de cristal; simplemente
requiere compromiso (Garmus & Herron, 1996).

2.6 PROBLEMAS EN LA ESTIMACIN DEL ESFUERZO EN
PROYECTOS INFORMTICOS

Aunque existe una variada gama de herramientas y tcnicas para ayudar a crear
estimaciones del esfuerzo en proyectos informticos, la mayora son altamente
imprecisas, especialmente aquellas que involucran nuevas tecnologas o desarrollo de
software. Tom DeMarco, un conocido autor en el rea del desarrollo de software,
sugiere cuatro razones para estas imprecisiones y algunos mtodos para superarlas
(DeMarco, 1982).
1. Desarrollar una estimacin para un gran proyecto de desarrollo de software es
una tarea compleja requiriendo de una significativa cantidad de esfuerzo. Muchas
estimaciones deben ser hechas rpidamente y antes de que los requerimientos
definitivos del sistema hayan sido generados. Especialmente en los proyectos que
presentan una gran complejidad. Antes de comprender que informacin los
expertos realmente necesitan en el sistema, alguien tiene que crear una
estimacin a grandes rasgos y una estimacin presupuestaria para el proyecto.
Rara vez son ms precisas las estimaciones iniciales que las estimaciones
posteriores, en proyectos informticos. Es importante recordar que las
estimaciones son hechas en varias etapas del proyecto, y los administradores del
mismo necesitan explicar la razn de ser de cada estimacin.

2. Las personas que desarrollan estimaciones de costos de software a menudo no
tienen mucha experiencia con estimaciones de costo, especialmente para
proyectos grandes. Tampoco hay suficiente precisin o datos confiables de
proyectos disponibles en los cuales basar las estimaciones. Si las compaas
37

utilizan una administracin de proyectos adecuada y mantienen informacin til
de proyectos, incluyendo estimaciones anteriores, debera ser de ayuda para
mejorar las estimaciones actuales.

3. Los seres humanos tienen una tendencia hacia la subestimacin. Por ejemplo, los
profesionales con vasta experiencia o los directores de proyecto, pueden hacer
estimaciones basadas en sus propias habilidades olvidando que mucha gente
joven trabajar en el mismo. Las personas que realizan las estimaciones, pueden
olvidarse de considerar costos extras necesarios para integracin y pruebas en
proyectos informticos de gran tamao. Es importante para los administradores
de proyectos y para la alta direccin revisar las estimaciones y realizar las
preguntas necesarias para asegurarse que las estimaciones no sean sesgadas.

4. El director del proyecto puede solicitar una estimacin, pero en realidad, slo
puede estar buscando una justificacin numrica para ayudarlo a crear una oferta,
conseguir un mejor contrato u obtener fondos internos. Es importante para los
administradores de proyectos ayudar a desarrollar buenas estimaciones y usar sus
habilidades de liderazgo y de negociacin para cumplir con ellas.

2.7 CONCLUSIN

Desafortunadamente, no existe un mtodo o herramienta en particular para estimar
precisamente proyectos informticos. Puede ser una buena idea, usar ms de una tcnica
para estimar. Se pueden tener probablemente dos estimaciones diferentes (Marchewka,
2006).
Si las estimaciones desde diferentes tcnicas de estimacin tienen resultados bastante
similares, entonces se pueden promediar con un alto grado de confianza. Si las
38

estimaciones varan ampliamente, entonces probablemente se debera ser escptico con
respecto a una o ambas estimaciones y revisar los datos que fueron recogidos
(Roetzheim & Beasley, 1998).
La estimacin inicial probablemente tendr que ser ajustada hacia arriba o hacia abajo,
basada en la experiencia pasada o datos de proyectos pasados. Muchas veces, sin
embargo, (en una mala prctica) las estimaciones iniciales son negociadas por la alta
direccin o el cliente, en lugar de centrarse en su precisin. Como resultado, se puede
estar trabajando en un proyecto que est destinado a fracasar.
Lo anterior, bsicamente se reduce a si el proyecto puede o no ser entregado a tiempo.
Le corresponde al administrador del proyecto no solamente llegar a una estimacin, sino
tambin apoyar las estimaciones. De otra forma, el calendario y presupuesto del
proyecto pueden ser muy poco realistas. Trabajar un prolongado perodo de tiempo, bajo
mucha presin, seguramente tendr un impacto negativo en el equipo del proyecto. El
jefe de proyecto debera siempre anticiparse y hacer lo posible por determinar un plazo
realista y recursos adecuados, de acuerdo a como fueron definidos por el calendario y el
presupuesto del proyecto en una primera instancia (Marchewka, 2006).

39

CAPTULO 3. DESARROLLO

3.1 INTRODUCCIN

A continuacin, se describir cada uno de los mtodos implementados, para la
estimacin del esfuerzo en proyectos de desarrollo de software. Bsicamente, se trata de
una combinatoria de mtodos, donde estn insertos conceptos tales como: Puntos de
Funcin, Casos de Uso, Lgica Difusa y COCOMO II, entre otros. En el presente
captulo se mostrar en detalle las caractersticas fundamentales, las ventajas y
desventajas de cada uno de los mtodos y la etapa en la que pueden ser utilizados, dentro
del proceso de Ingeniera de Software. Se analizar y describir desde la base terica
desde la que nacen cada uno de los mtodos, hasta la forma en que fueron
implementados, en el siguiente trabajo de titulacin.

3.2 MTODO PUNTOS DE FUNCIN TRADICIONAL (PFT)

3.2.1 Anlisis del Mtodo Puntos de Funcin Tradicional

Basado en una de las premisas del anlisis y solucin de problemas en general: divide y
vencer, el Anlisis de Punto Funcin es una tcnica que mediante la descomposicin de
un sistema en componentes ms pequeos, permite que stos puedan ser mejor
comprendidos y analizados en forma individual. Tambin provee una tcnica
estructurada para resolver problemas (Longstreet, D., 2001).
Como se indic en el Captulo 2, los Puntos de Funcin constituyen una medida
(mtrica) del tamao de un sistema de software y del proyecto que lo construye. El
Anlisis de Punto Funcin (APF) se basa en la teora de que las funciones de una
40
CAPTULO 3: DESARROLLO

aplicacin son la mejor medida del tamao de un sistema. El Punto de Funcin mide el
software mediante la cuantificacin de la funcionalidad que el sistema le brinda al
usuario basado fundamentalmente en el diseo lgico. Es independiente del lenguaje de
computacin, de la metodologa de desarrollo, de la tecnologa utilizada y de la
capacidad del equipo de trabajo para desarrollar la aplicacin (IFPUG, CPM., 2000).
Si bien la versin original (Albrecht, 1979), considera cuatro tipos de funciones:
archivos, entradas, salidas y consultas; con pesos de 10, 4, 5 y 4, respectivamente. En el
presente trabajo de titulacin, se considera como Mtodo Tradicional de Puntos de
Funcin, aquella actualizacin realizada por el mismo autor cuatro aos ms tarde
(Albrecht, 1983). Las diferencias entre ambos mtodos se pueden ver ms claramente,
en la Tabla 3.1

Tabla 3.1: Diferencias entre el Mtodo (Albrecht, 1979) y (Albrecht, 1983)
Albrecht 79 Albrecht 83
Tipos de
Funciones
Pesos Tipos de Funciones Complejidad
Baja Media Alta
Archivos 10 Archivos Lgicos Internos 7 10 15
Entradas 4 Archivos de Interfaces 5 7 10
Salidas 5 Entradas Externas 3 4 6
Consultas 4 Salidas Externas 4 5 7
Consultas Externas 3 4 6

Otro dato importante a considerar es que el modelo de 1979 presentaba 10 Factores de
Complejidad Tcnica, cuyo Factor de Ajuste poda variar como mximo un 25%. Por
otra parte, el modelo de 1983 fue expandido a cinco tipos de funciones, tres sets de
pesos para cada tipo de funcin (complejidades) y 14 factores de Complejidad Tcnica,
para un mximo Factor de Ajuste de un 35% (Abran & Robillard, 1996). En la versin
de (Albrecht, 1983), la evaluacin de la complejidad de los tipos de funcin, era un
proceso subjetivo. Para transformar esta evaluacin en un proceso objetivo,
transversalmente consistente entre individuos y organizaciones, la versin GUIDE 84
41

introdujo una nueva dimensin para el (APF): los Puntos de Funcin fueron divididos en
componentes primarios y matrices de dos dimensiones, con rangos predeterminados de
valores, usados para propsitos de clasificacin aquellos componentes quedan
representados en la Tabla 3.2.

Tabla 3.2: Componentes primarios en el Mtodo de Puntos de Funcin (IFPUG, 1994)
Tipos Abreviacin Definicin
Tipo de Elemento de
dato
TED (DET, sigla en ingls) Un campo nico reconocible por el
usuario, en un registro lgico interno o
registro de interface externo.
Tipo de Elemento de
Registro
TER (RET, sigla en ingls) Un subgrupo nico de datos
elementales reconocibles por el
usuario.
Tipo de Archivo
Referenciado
TAR (FTR, sigla en ingls) Cada registro (interno o externo) ledo
o mantenido por un tipo de funcin
transaccional.

En 1984, el Internacional Function Points Users Group (IFPUG, Grupo Internacional de
Usuarios de Puntos de Funcin) fue creado para clarificar las reglas, establecer
estndares y promover su uso y evolucin. No obstante, a partir de aquel ao, dicha
agencia internacional no ha introducido ningn cambio significativo en la estructura del
Mtodo de Puntos de Funcin, ms all de proveer una mayor clarificacin de las reglas,
directrices y criterios de aplicacin del mismo.

3.2.1.1 Cuenta de Puntos Funcin sin Ajustar

La cuenta de Punto Funcin sin Ajustar refleja las especficas funcionalidades
contabilizadas que se le proporcionan al usuario por el proyecto o la Aplicacin. Las
funcionalidades de usuario especficas son evaluadas en trminos del Qu es lo que
42

proporcionan y no en el Cmo es proporcionado. La cuenta sin ajustar tiene dos tipos de
funciones: de datos y de transacciones (DICYT, 2004).

Funciones de Datos
Las funciones de datos representan las funcionalidades brindadas al usuario para reunir
los requerimientos de datos internos y externos a la frontera de la aplicacin. Las
funciones de datos son siempre ficheros lgicos internos (Internal Logical File o ILF) o
ficheros lgicos externos (External Logical File o ELF).
- Un ILF es un grupo de datos relacionados lgicamente o informacin de control
reconocida por el usuario y mantenida dentro de la frontera de la aplicacin. El
objetivo fundamental de un ILF es manejar los datos mantenidos a travs de uno
o ms procesos elementales (o acciones) de la aplicacin que est siendo
contada.
- Un ELF es un grupo de datos relacionados lgicamente o informacin de control
reconocida por el usuario y referenciada pero mantenida dentro de la frontera de
otra aplicacin. El objetivo principal de un ELF es manejar los datos
referenciados mediante uno o ms procesos elementales (o acciones) dentro de la
frontera de la aplicacin contada.
Cuando se hace la referencia a un archivo lgico interno (ILF) o interfaz de archivo
externa (ELF), el trmino archivo no tiene el significado tradicional de procesamiento de
datos sino que se refiere a un grupo de datos lgicamente relacionado sin tener en cuenta
la implementacin fsica de dicho grupo. Se corresponde con las entidades que se
identifican que se gestionan mediante el sistema.

Funciones Transaccionales
Las funciones transaccionales representan las funcionalidades que el sistema le brinda al
usuario para procesar datos. Las funciones transaccionales son siempre entradas (EI -
external inputs), salidas (EO - external output) o consultas (o EQ - external queries).
- Un EI es un proceso elemental o una accin que procesa datos o informacin de
control que viene desde afuera de la frontera de la aplicacin hacia adentro. Los
datos pueden venir desde otra aplicacin o desde una pantalla de ingreso de
datos. El objetivo fundamental es mantener uno o ms archivos lgicos internos
(o ILF de Internal Logical File) y/o alterar el comportamiento del sistema.
43

- Un EO es un proceso elemental o una accin que enva datos o informacin de
control hacia fuera de la frontera de la aplicacin. El objetivo fundamental es
presentar informacin al usuario a travs de procesamiento lgico de los datos o
de la informacin de control obtenida. El procesamiento lgico debe contener al
menos un frmula o clculo matemtico o crear datos derivados de los obtenidos.
Un EO podra mantener uno o ms ILF y/o alterar el comportamiento del
sistema.

- Un EQ es un proceso elemental o una accin que enva datos o informacin de
control hacia fuera de la frontera de la aplicacin. El objetivo principal de un EQ
es presentar informacin al usuario a travs de la obtencin meramente del dato o
de la informacin de control. A diferencia del EO, el procesamiento lgico no
debe contener ninguna frmula o clculo matemtico, ni tampoco debe crear
datos derivados de los obtenidos. Por otra parte ningn ILF es mantenido
mientras se procesa la accin de un EQ ni tampoco el comportamiento del
sistema se ve alterado (DICYT, 2004).
Este mtodo corresponde al que se define en la aplicacin desarrollada con el nombre de
Puntos de Funcin Tradicional Directo.
Mecanismo

Para cada uno de los 5 tipos de elementos, se deben identificar aquellos que surgen de
los requerimientos o funcionalidades que proveer el sistema. Es posible para ello
basarse en ciertas reglas, que se explicarn a lo largo del presente Captulo. Luego, se
debe analizar la complejidad de cada uno, que puede ser Alta, Media o Baja. Existen
reglas detalladas para definir la complejidad de cada uno de los elementos segn su tipo,
las cuales se explicarn en la Seccin 3.2.5. Con estos datos, y utilizando los pesos
correspondientes a cada uno de los elementos identificados es posible calcular el total de
Puntos Funcin.

44

3.2.2 Diseo del Mtodo Puntos de Funcin Tradicional

En la Figura 3-1 se puede apreciar el modelo general de puntos de funcin, donde se
representa la interaccin que existe entre: Entradas Externas (External Inputs, EI),
Salidas Externas (External Outputs, EO), Consultas Externas (External Queries, EQ),
Archivos Lgicos Internos (Internal Logical Files, ILF) y Archivos de Interfaces
Externas (External Interface Files, EIF). En el centro del modelo, se puede apreciar la
aplicacin medida, es decir, aquella a la cual se le aplica el mtodo de Puntos de
Funcin, la cual interacta con el usuario y, eventualmente, con otra aplicacin. Cada
una de las funciones de datos y transaccionales fueron definidas en detalle en la seccin
anterior.

Figura 3-1: Modelo de Puntos de Funcin (Kushal, 2007)

El mtodo de Puntos de Funcin se compone de tres partes principales:
45

- Clculo de Puntos de Funcin Sin Ajustar: sta corresponde a la etapa
fundamental del proceso en general y consiste en asignar un factor de
complejidad a cada una de las funciones de datos y transaccionales y luego
realizar la sumatoria de estos elementos ponderados. Esto se puede apreciar con
ms detalle en la Figura 3-2.

Figura 3-2: Clculo de Puntos de Funcin Sin Ajustar

Matemticamente el concepto anterior se puede expresar mediante la Ecuacin 3.1:

= =
=
5
1 i
3
1 j
ij ij
z w PFSA
(3.1)

Donde Zij corresponde a la cuenta por componente i en el nivel j (por ejemplo: consultas
con complejidad alta) y Wij corresponde al peso asignado por el procedimiento de
(Albrecht, 1983).
46

- Clculo del Factor de Ajuste: se calcula a travs de 14 parmetros (ponderadores
de complejidad tcnica) a los cuales se les asigna un grado de influencia entre 0 y
5 y luego se realiza la sumatoria ponderada de aquellos parmetros. Esto
corresponde al Grado Total de Influencia (Ver Tabla 3.3 y Ecuacin 3.2).
Finalmente, el Factor de Ajuste se puede representar a travs de la Ecuacin 3.3.

Tabla 3.3: Clculo del Grado Total de Influencia
Clculo Tradicional del Factor de Ajuste
Ponderadores de Complejidad Tcnica Grado de Influencia
F1: Comunicacin de Datos
F2: Proceso Distribuido de Datos
F3: Rendimiento
F4: Configuraciones Fuertemente Utilizadas
F5: Frecuencia de Transacciones
F6: Entrada Datos En-lnea
F7: Eficiencia del Usuario Final
F8: Actualizaciones En-lnea
F9: Procesamiento Complejo
F10: Reusabilidad del Cdigo
F11: Facilidad de Instalacin
F12: Facilidad de Operacin
F13: Instalaciones Mltiples
F14: Facilidad de Cambios
GRADO TOTAL DE INFLUENCIA

- Clculo de Puntos de Funcin Ajustados: en esta etapa simplemente se multiplica
los Puntos de Funcin Sin Ajustar por el Factor de Ajuste.

65 . 0 01 . 0 * GTI FA + = (3.3)
(3.2)
=
=
14
1 i
i
I GTI
47

FA * PFSA PFA=

(3.4)

Es importante destacar, que como paso final, siempre es necesario realizar la conversin
entre Puntos de Funcin Ajustados y Horas-Hombre. El esfuerzo obtenido ya sea en
horas o meses hombre, representa solamente aquel relacionado con el tiempo estimado
de programacin. En general, para estimar el esfuerzo total de un proyecto, se
considerarn los porcentajes que se indican en la Tabla 3.4

Tabla 3.4: Porcentaje de Tiempo por Actividad
Porcentaje de tiempo por Actividad
Actividad Porcentaje
Anlisis 10,0%
Diseo 20,0%
Programacin 40,0%
Pruebas 15,0%
Sobrecarga 15,0%
Total 100,0%

3.2.3 Implementacin del Mtodo Puntos de Funcin Tradicional

Es importante resaltar, que realizar una estimacin basada en el mtodo de puntos de
funcin, no es un proceso trivial. Involucra un nivel de abstraccin alto y se necesita
idealmente, un grado de experiencia importante en el desarrollo de sistemas de software.
Complementariamente, el uso correcto del Mtodo, se alcanza luego de aos de uso del
mismo. Como una forma de contrarrestar o mitigar dichas dificultades, se decidi
realizar la implementacin mediante formularios y macros de ActiveX (Excel). De esa
forma se puede orientar al usuario para que de una formal lineal, pueda paso a paso,
completar el proceso de estimacin. Adems, se implementaron un importante nmero
de validaciones por ejemplo en el tipo de datos de entradas, y en general, en la forma en
que deben ser completadas cada una de las etapas de ste y todos los mtodos
48

implementados. El objetivo era simplificar lo ms posible el proceso, recalcando que
obviamente, que la aplicacin y/o mtodos descritos en el presente trabajo de titulacin
no estn enfocados en cualquier usuario, sino que en aquellos que tienen ciertos
conocimientos acerca de estimaciones de esfuerzo, es decir, al menos una formacin
enfocada en las tecnologas de la informacin, y ms especficamente, en el desarrollo
de sistemas de software.

Figura 3-3: Formulario Inicial del Mtodo de Puntos de Funcin

Figura 3-4: Detalle del formulario Inicial
49

La Primera etapa se puede apreciar en las Figuras 3-3 y 3-4, donde se debe elegir el
mtodo con el cual se desea evaluar el nuevo proyecto. En este caso se pondr nfasis en
el primer mtodo implementado, en la Figura 3-5 es posible constatar como el sistema le
indica al usuario que ingrese la cantidad de entradas y la complejidad asociada a las
mismas, las cual puede ser simple, media o compleja.

Figura 3-5: Inicio del Mtodo de Puntos de Funcin Tradicional

Se valida que el usuario solamente pueda ingresar nmeros enteros mayor o igual a cero,
ello queda representado en la Figura 3-6.

Figura 3-6: Validacin del tipo de entrada
50

Adems, se valida que se ingrese un valor para ambos campos (cantidad de entradas y
complejidad) para mantener la consistencia de datos. Esto se puede apreciar en la Figura
3-7.

Figura 3-7: Validacin de campos nulos

Complementariamente, en cada una de las pantallas del sistema se valid que apareciera
un mensaje que ratificara la intencin de abandonar el sistema, con un mensaje que le
indica al usuario que los datos no guardados se perdern. Ello se visualiza en la Figura
3-8.

Figura 3-8: Validacin de abandono del sistema
51

El mtodo est construido de tal forma que se puedan ingresar una cantidad n de
entradas, cada una asociada a su tipo de complejidad. El usuario puede decidir si desea
ingresar por ejemplo, un nuevo tipo de entrada o si desea ingresar el siguiente tipo de
funcin transaccional o de datos. Aquello queda expresado en la Figura 3-9.

Figura 3-9: Ingreso de 1 o n tipos de Entradas

Una vez ingresados todos los tipos de funciones transaccionales y de datos, el sistema
calcula automticamente el valor de los Puntos de Funcin Sin Ajustar, eso se visualiza
en la Figura 3-10. Luego, se puede pasar a la etapa de Ajustes de los Puntos de Funcin.

Figura 3-10: Clculo de los Puntos de Funcin Sin Ajustar
52

3.2.3.1 Implementacin del Mtodo de Ajuste Tradicional

i. Anlisis: Este corresponde al mtodo de ajuste original (Albrecht, 1983) descrito
anteriormente en la seccin 3.2.2, el cual contempla un impacto de un mximo
de un 35%. La granularidad de cada ponderador de complejidad puede tomar
valores de entre 0 a 5. La Ecuacin 3.2 representa el Grado Total de Influencia y
las Ecuaciones 3.3 y 3.4 representan el mtodo de clculo del Factor de Ajuste y
de los Puntos de Funcin Ajustados, respectivamente.

(3.3)

FA * PFSA PFA =

(3.4)

ii. Diseo: en este caso se crea una tabla en la que se registran los valores para cada
ponderador de complejidad que como se dijo anteriormente pueden tomar
valores de nmeros enteros entre 0 y 5. Luego, se calcula la sumatoria de estos
valores, para obtener el Grado Total de Influencia (GTI).

iii. Implementacin: utilizando los conceptos recogidos del anlisis y el diseo
realizado, se procede a efectuar la implementacin del Mtodo de Ajuste
Tradicional. En la aplicacin, se cre una tabla donde el usuario, simplemente
haciendo click, puede ingresar cada uno de los datos necesarios. Para simplificar
aquello, se muestra en un campo de texto en la parte inferior, el ponderador de
complejidad y el grado de influencia correspondiente (entre 0 y 5) el cual deber
incorporar el usuario. Estos conceptos, se pueden apreciar con mayor detalle, en
las Figuras 3-11 y 3-12, respectivamente.
65 . 0 01 . 0 * GTI FA + =
(3.2)
=
=
14
1 i
i
I GTI
53

Figura 3-11: Ingreso de Datos para el Grado Total de Influencia

Figura 3-12: Validacin para el Grado de Influencia

54

Otra validacin que se incluy, es el hecho de que el usuario deba completar la tabla en
su totalidad para poder pasar a la siguiente etapa, esto en la eventualidad de que olvide
incorporar alguno de los 14 tipos de ponderadores de complejidad (Ver Figura 3-13).

Figura 3-13: Validacin para completar la tabla de ponderadores de complejidad

Una vez completada la tabla anterior, el sistema calcula el Factor de Ajuste mediante la
Ecuacin 3.3 y luego, en forma inmediata, los Puntos de Funcin Ajustados a travs del
Ecuacin 3.4. Esto queda reflejado en la Figura 3-14.

Figura 3-14: Clculo de los Puntos de Funcin Ajustados
55

3.2.3.2 Anlisis Diseo e Implementacin del Mtodo de Ajuste Modificado

i. Anlisis: una de las formas en que se modific el mtodo original, fue con
respecto a su mtodo de ajuste. En este caso, se realizaron cambios para producir
un mayor impacto de este factor con respecto a los Puntos de Funcin Ajustados.
El mtodo original de (Albrecht, 1979) consideraba un nivel de impacto de un
25%. El modelo ms utilizado y adems uno de los implementados en el presente
trabajo de titulacin (Albrecht, 1983), contempla un impacto de un mximo de
un 35%. Con estos antecedentes, se implement un mtodo que como mximo
puede influir en un 42%. Para ello, se aument la granularidad de cada
ponderador de complejidad el cul en este caso puede tomar valores de entre 0 a
6. Las Ecuaciones 3.5 y 3.6 representan este cambio.

(3.5)

) 2 ( FA * PFSA PFA=

(3.6)

ii. Diseo: en este caso el diseo es similar, se mantiene una tabla en la que se
registran los valores, con la nica diferencia (como se indicaba en el anlisis) que
cada ponderador de complejidad puede tomar valores de nmeros enteros entre 0
y 6. Luego, nuevamente se calcula la sumatoria de estos valores, para calcular el
Grado Total de Influencia 2 (GTI(2)) y el nuevo Factor de Ajuste se obtiene
segn la Ecuacin 3.6.

iii. Implementacin: de acuerdo al anlisis y el diseo realizado, se procede a
efectuar la implementacin del Mtodo de Ajuste Modificado, lo cual se puede
visualizar en la Figura 3-15. En este caso se ampla nicamente el espectro de
valores que puede tomar el grado de influencia para cada parmetro y las
Ecuaciones 3.5 y 3.6, se utilizan para el clculo interno de los Puntos de Funcin
Ajustados (con el nuevo mtodo de ajuste).
58 . 0 01 . 0 * ) 2 ( GTI ) 2 ( FA + =
56

Figura 3-15: Validacin de Datos para la Nueva Versin del Grado Total de Influencia

Una vez calculados los Puntos de Funcin Ajustados con alguno de los dos mtodos
descritos anteriormente, se debe introducir el factor de conversin entre puntos de
funcin y horas-hombre, de acuerdo al lenguaje de programacin que utilizar en el
sistema que se est estimando. Adems es necesario incorporar las horas de trabajo
efectivas en el mes. Aquello se puede apreciar en la Figura 3.16.

Figura 3-16: Ingreso del Factor de Conversin y de las Horas Efectivas de Trabajo
57

Luego, se debe asignar el porcentaje de esfuerzo por actividad de acuerdo al proceso de
ingeniera de software, debido a que el resultado obtenido del mtodo de estimacin,
corresponde solamente al proceso de Programacin. Aquello queda representado en la
Figura 3-17.

Figura 3-17: Asignacin del Porcentaje de Esfuerzo por Actividad

Finalmente se mostrar el esfuerzo estimado por actividad, tanto en horas-hombre como
en meses-hombre. Aquello se puede apreciar en la Figura 3-18.
Una vez que los datos se han visualizado por pantalla, el usuario puede decidir si guarda
los resultados en un archivo en formato .xls o .xlsx, por ejemplo. De tal forma de que
pueda consultarlos de forma cmoda, posteriormente (ver Figura 3-19). Adems, puede
elegir otro Mtodo de Ajuste u otro Mtodo de Estimacin, escogiendo entre los ya
analizados o los que se explicarn a continuacin.

58

Figura 3-18: Resultados de la Estimacin

Figura 3-19: Guardando los resultados en un archivo
59

3.2.4 Puntos de Funcin Tradicional Mtodo de Ajuste COCOMO II

3.2.4.1 Anlisis
Para apoyar a los distintos sectores del mercado de software, COCOMO II proporciona
una familia de modelos de estimacin de costos de software cada vez ms detallados y
tiene en cuenta las necesidades de cada sector y el tipo de informacin disponible para
realizar la estimacin del costo de software. Esta familia de modelos est compuesta por
tres submodelos cada uno de los cuales ofrece mayor fidelidad a medida que uno avanza
en la planificacin del proyecto y en el proceso de diseo. Estos tres submodelos se
denominan:

- El modelo de Composicin de Aplicaciones.

Indicado para proyectos construidos con herramientas modernas de construccin de
interfaces grficas para usuario.

- El modelo de Diseo Anticipado.

Este modelo puede utilizarse para obtener estimaciones aproximadas del coste de un
proyecto antes de que est determinada por completo su arquitectura. Utiliza un pequeo
conjunto de drivers de costos nuevos y nuevas ecuaciones de estimacin. Est basado en
Punto de Funcin sin ajustar o KSLOC (Miles de Lneas de Cdigo Fuente).

- El modelo Post-Arquitectura.

Este es el modelo COCOMO II ms detallado. Se utiliza una vez que se ha desarrollado
por completo la arquitectura del proyecto. Tiene nuevos drivers de coste, nuevas reglas
para el recuento de lneas y nuevas ecuaciones.
60

Por ltimo, la experiencia ha demostrado que si una organizacin calibra la constante
multiplicativa en COCOMO II para sus propios datos empricos, la precisin del modelo
puede aumentar significativamente por encima de los resultados de calibracin genricos
obtenidos con las versiones mencionadas anteriormente (Moreno, 2007).

- Utilizacin del Modelo de Diseo Anticipado

El nivel de detalle de este modelo puede ser consistente con el nivel general de
informacin disponible y con el nivel general de aproximacin de la estimacin
requerida en esta etapa.

La correspondiente capacidad de COCOMO II incluye el uso de Puntos de Funcin y un
conjunto de siete drivers de coste de grano grueso (por ejemplo, dos drivers de coste
para capacidad del personal y experiencia del personal en lugar de los seis drivers de
coste del Modelo Post-Arquitectura que cubren varios aspectos de capacidad del
personal, continuidad y experiencia).

El modelo de Diseo Anticipado usa Puntos de Funcin No Ajustados como mtrica de
medida. Este modelo se utiliza en las primeras etapas de un proyecto software, cuando
se conoce muy poco sobre el tamao del producto que se va a desarrollar, la naturaleza
de la plataforma objetivo, la naturaleza del personal involucrado en el proyecto
especificaciones detalladas del proceso que se va a usar (Moreno, 2007).

En el modelo de Diseo Anticipado, la estimacin del esfuerzo se realiza tomando como
base la Ecuacin 3.7.

B
nominal
) Size ( A PM - =
(3.7)
Donde:
- PM
nominal
: es el esfuerzo nominal requerido, en meses hombre.
61

- Size: es el tamao estimado del software, en miles de lneas de cdigo
(KSLOC) o en Puntos de Funcin Sin Ajustar (convertibles a KSLOC mediante
un factor de conversin que depende del lenguaje y de la tecnologa).
- A: es una constante que se utiliza para capturar los efectos multiplicativos en el
esfuerzo requerido de acuerdo al crecimiento del tamao del software. El
modelo la calibra inicialmente con un valor de 2.94
- B: es una constante denominada Factor escalar, la cual tiene un impacto
exponencial en el esfuerzo y su valor est dado por la resultante de los aspectos
positivos sobre los negativos que presenta el proyecto. La ecuacin 3.8 permite
calcula dicho factor.

- + = ) W ( 01 , 0 91 , 0 B
i
(3.8)
El Factor escalar B se calcula a partir de la sumatoria de los aportes de distintas
Variables Escalares, las cuales son variables que indican las caractersticas que el
proyecto presenta en lo que a su complejidad y entorno de desarrollo se refiere.

Las Variables escalares de COCOMO II son las siguientes:
o PREC, variable de precedencia u orden secuencial del desarrollo.
o FLEX, variable de flexibilidad del desarrollo.
o RSEL, indica la fortaleza de la arquitectura y mtodos de estimacin y
reduccin de riesgos.
o TEAM, esta variable refleja la cohesin y madurez del equipo de trabajo.
o PMAT, relaciona el proceso de madurez del software.

Cada una de estas variables se cuantifica con un valor desde Muy Bajo hasta Extra Alto.

62

- Ajuste del esfuerzo nominal
El esfuerzo calculado en la Ecuacin (3.7) es un valor nominal y debe ser ajustado en
base a las caractersticas del proyecto. COCOMO II obtiene los datos necesarios para el
ajuste del esfuerzo nominal considerando un conjunto de Multiplicadores de Esfuerzo
(ME), los cuales representan las caractersticas del proyecto y expresan su impacto en el
desarrollo total del producto de software. Los Multiplicadores de esfuerzo se cuantifican
con una escala que va desde Extra Bajo a Extra Alto, y cada multiplicador tiene un valor
asociado a cada nivel de la escala. En definitiva, el esfuerzo ajustado se calcula mediante
la Ecuacin 3.9:
(3.9)

Los Multiplicadores de Esfuerzo de COCOMO II son los siguientes:
o RCPX, complejidad del producto.
o RUSE, reusabilidad.
o PDIF, dificultad de la plataforma.
o PERS, capacidad del personal.
o PREX, experiencia del personal.
o FCIL, facilidades.
o SCED, calendario.

3.2.4.2 Diseo
Para la etapa de diseo, las Variables Escalares citadas en la seccin anterior,
especficamente en la Ecuacin (3.8) y cada uno de sus valores se almacenaron en la
Tabla (3.5) con todo el rango de valores posibles, con la idea de utilizar dicha tabla para
crear un comboBox en la etapa de implementacin.

[
- = ) ME ( PM PM
i nominal ajustado
63

Tabla 3.5: Variables Escalares COCOMO II
Variables Escalares de COCOMO II

Factor Escalar Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
PREC
6,20 4,96 3,72 2,48 1,24 0,00
FLEX
5,07 4,05 3,04 2,03 1,01 0,00
RESL
7,07 5,65 4,24 2,83 1,41 0,00
TEAM
5,48 4,38 3,29 2,19 1,10 0,00
PMAT
7,80 6,24 4,68 3,12 1,56 0,00

El caso de los Multiplicadores de Esfuerzo es similar. En este caso se tiene como
referencia la Ecuacin (3.9) y los valores se almacenaron en la Tabla (3.6), con la idea
nuevamente, de utilizar dicha tabla para crear un comboBox en la etapa de
implementacin.
Tabla 3.6: Multiplicadores de Esfuerzo COCOMO II
Multiplicadores de Esfuerzo de COCOMO II
Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto
RCPX
0,73 0,81 0,98 1,00 1,30 1,74 2,38
RUSE
- - 0,95 1,00 1,07 1,15 1,24
PDIF
- - 0,87 1,00 1,29 1,81 2,61
PERS
2,12 1,62 1,26 1,00 0,83 0,63 0,50
PREX
1,59 1,33 1,12 1,00 0,87 0,71 0,62
FCIL
1,43 1,30 1,10 1,00 0,87 0,73 0,62
SCED
- 1,43 1,14 1,00 1,00 1,00 -

64

3.2.4.3 Implementacin
Como todos los mtodos de ajustes implementados, COCOMO II recibe como entrada
los Puntos de Funcin Sin Ajustar. Dicha entrada permite calcular el valor del parmetro
Size citado en la Ecuacin 3.7. Para ello se implement un comboBox donde el usuario
solamente debe elegir el lenguaje de programacin con el cual se desarrollar el sistema,
y la aplicacin internamente, realiza todos los clculos necesarios. Esto se ilustra en la
Figura 3-20. El detalle de todas las opciones de lenguaje de programacin se puede
verificar en el Apndice D.

Figura 3-20: Eleccin del Lenguaje de Programacin

Luego de calcular el parmetro Size, se debe obtener el valor de B que se describe en la
Ecuacin (3.8). Para ello se implement una tabla donde simplemente haciendo click, en
cualquier columna, se puede ingresar la ponderacin para cada Variable Escalar, a travs
de un comboBox. Posteriormente, y en forma automtica, el sistema calcula el valor de
la sumatoria de las Variables Escalares. Aquello queda reflejado en la Figura 3-21.
65

Figura 3-21: Ingreso de Variables Escalares COCOMO II

Una vez calculado el Esfuerzo nominal, se debe calcular el Esfuerzo Ajustado
(PM
ajustado
). Para ello, se utiliza la Ecuacin 3.8, definida en la etapa de anlisis. La
aplicacin realiza el clculo en forma automtica una vez registrados los valores
correspondientes a los Multiplicadores de Esfuerzo. Para realizar este ltimo proceso, se
implement una tabla donde simplemente haciendo click, en cualquier celda, se puede
ingresar la ponderacin para el Multiplicador de Esfuerzo correspondiente, a travs de
un comboBox que se genera en forma dinmica en cada fila, de acuerdo al rango
definido en la etapa de diseo. Aquello se grafica en la Figura 3-22.

66

Figura 3-22: Ingreso de Multiplicadores de Esfuerzo

Finalmente, en la Figura 3-23 se muestra la pantalla en la que se presenta al usuario el
esfuerzo en horas y meses hombre, de acuerdo al mtodo de ajuste COCOMO II. En la
pantalla final, al igual que con los otros mtodos de ajuste, se puede: guardar los datos
en un archivo con formato .xls o .xlsx, seleccionar otro mtodo de ajuste, estimar otro
proyecto o simplemente salir de la aplicacin.
67

Figura 3-23: Clculo del Esfuerzo Mediante Ajuste COCOMO II

3.2.5 Puntos de Funcin Tradicional Mtodo Indirecto
3.2.5.1 Anlisis

Como se indic anteriormente, el Mtodo de Puntos de Funcin Tradicional que se basa
en (Albrecht, 1983), asigna los niveles de complejidad (baja, media o alta) en forma
completamente subjetiva. Es decir, no se rige por un criterio unificado. Como una forma
de subsanar dicha falencia, como se seal en la seccin 3.2.1 la versin (GUIDE, 1984)
introduce los conceptos de DETs (Data Type Element, Tipo de elemento de dato), RETs
(Record Element Type, Tipo de elemento de registro) y FTR (File Type Referenced,
Tipo de archivo referenciado), una definicin de cada uno de estos conceptos se seala
en la Tabla 3.2.
68

A continuacin, se explica cmo calcular la complejidad de cada una de las funciones
transaccionales y de datos, a travs del uso de los conceptos indicados previamente.
- Determinacin de complejidad de los Ficheros Lgicos

Primeramente es pertinente definir dichos conceptos con mayor profundidad:

Ficheros Lgicos Internos (ILF)

Un ILF es un grupo de datos relacionados lgicamente o informacin de control
reconocida por el usuario y mantenida dentro de la frontera de la aplicacin. El objetivo
fundamental de un ILF es manejar los datos mantenidos a travs de uno o ms procesos
elementales (o acciones) de la aplicacin que est siendo contada.
Reglas para identificarlos:

1. El grupo de datos o informacin de control es un grupo de datos lgico
identificable por el usuario que cubre de manera completa requisitos especficos
de este.
2. El grupo de datos es mantenido dentro de los lmites de la aplicacin.
3. El grupo de datos es mantenido o modificado por medio de un proceso elemental
de la aplicacin.
4. El grupo de datos identificado no se ha contado como ELF de la aplicacin.

Ficheros Lgicos Externos (ELF)

Un ELF es un grupo de datos relacionados lgicamente o informacin de control
reconocida por el usuario y referenciada, pero mantenida dentro de la frontera de otra
aplicacin. El objetivo principal de un ELF es manejar los datos referenciados mediante
uno o ms procesos elementales (o acciones) dentro de la frontera de la aplicacin
contada. La principal diferencia entre un archivo lgico interno ILF y una interfaz de
69

archivo externa ELF es que el ILF es mantenido dentro de la frontera de la aplicacin
mientras que el ELF es mantenido por otra aplicacin. El ELF es referenciado por la
aplicacin que se est contando, pero no mantenido por ella.

Reglas:

1. El grupo de datos o informacin de control es un grupo de datos lgico
identificable por el usuario que cubre de manera completa requisitos especficos
de este.
2. El grupo de datos es referenciado y es externo a la aplicacin que est siendo
contada.
3. El grupo de datos no es mantenido por la aplicacin que est siendo contada.
4. El grupo de datos se ha contado como ILF en al menos otra aplicacin.
5. El grupo de datos identificado no ha sido contado como un ILF para la aplicacin
(DICYT, 2004).

La complejidad de los ficheros lgicos, tanto internos como externos se basa en la
cuenta de DETs y RETS:

DET: Data Element Type. Contar un DET por cada uno de los campos reconocibles por
el usuario que componen el fichero.

Se aplican adems las siguientes reglas:
1. Los campos que existen como claves forneas para referenciar otro ILF segn los
requerimientos, tambin se consideran como DET.
2. Un campo lgico nico, almacenado en varios campos fsicos, se cuenta como un
nico DET.
3. Los campos repetitivos se cuentan como un nico DET cada uno.
4. Los campos que aparecen ms de una vez por tcnicas de implementacin se
cuentan como un nico DET.
70

5. Los campos que aparecen debido a tcnicas de implementacin, que no son
reconocibles por el usuario, no se cuentan como DET.

RET: Record Element Type. Contar un RET por cada subgrupo de datos elementales
reconocibles por el usuario.

Existen dos tipos de subgrupos:
1. Opcional: son aquellos que el usuario tiene la opcin de usar uno o ningn
subgrupo durante un proceso elemental que agrega o crea una instancia de datos.
2. Obligatorio: son subgrupos donde el usuario debe usar al menos uno.
A la hora de contar RETs, una de las siguientes reglas debe aplicar:
1. Cuente como un RET para cada subgrupo opcional u obligatorio de un ILF/ELF
2. De no haber subgrupos, cuente el ILF o ELF como un RET.

En caso de identificar grupos repetitivos en una entidad, sume 1 RET por cada grupo
repetitivo. Por ejemplo, para una entidad factura donde se identifican los datos de cada
lnea que se repiten, smele un RET a la entidad factura (DICYT, 2004).

Una vez identificados los DETs y RETs de un fichero lgico, se puede utilizar la Tabla
3.7 para determinar su complejidad.

Tabla 3.7: Criterio para determinar la complejidad en Archivos Lgicos
1 a 19 DETs 20 a 50 DETs 51 ms DETs
1 RET Baja Baja Media
2 a 5 RETs Baja Media Alta
6 ms RETs Media Alta Alta

71

- Determinacin de complejidad de las Entradas (EI)

Una Entrada es un proceso elemental o una accin que procesa datos o informacin de
control que vienen desde afuera de la frontera de la aplicacin hacia adentro. Los datos
pueden venir desde otra aplicacin o desde una pantalla de ingreso de datos. El objetivo
fundamental es mantener uno o ms archivos lgicos internos (o ILF de Internal Logical
File) y/o alterar el comportamiento del sistema.
Se aplican las siguientes reglas:
1. Los datos se reciben desde fuera de los lmites de la aplicacin.
2. Los datos mantienen un ILF a travs de un proceso elemental de la aplicacin.
3. El proceso es la unidad ms pequea de actividad que es significativa para el
negocio del usuario final.
4. El proceso es autocontenido y deja la aplicacin que est siendo contada en un
estado consistente.
5. El proceso identificado debe verificar alguna de estas reglas:
Su lgica de proceso es nica respecto de otras entradas externas de la
aplicacin.
Los elementos de datos identificados son distintos a los de las otras EI de la
aplicacin.
Los ficheros lgicos referenciados son diferentes
La complejidad de las entradas se basa en la cuenta de DETs y FTRs:
DET: Data Element Type. Contar un DET por cada uno de los campos que cruzan las
fronteras de la aplicacin.
- Contar 1 DET por cada campo reconocible por el usuario, no repetido que
cruza los lmites de la aplicacin.
72

- No contar los campos que son recuperados o derivados por el sistema y
almacenados en un ILF si estos no cruzan la frontera de la aplicacin.
- Contar los siguientes elementos como un DET extra cada uno:
o Definicin del comienzo de la ejecucin del proceso que procesa la
entrada (botn de Aceptar o Enter). Si hay varias formas, contar una
sola.
o Mensajes de error que pueden desplegarse durante la ejecucin del
proceso (un DET para todos).
FTR: File Type Referenced. Contar un FTR por cada fichero (interno o externo)
ledo/mantenido por el proceso de la entrada (DICYT, 2004).
Una vez identificados los DETs y FTR, se puede utilizar la Tabla 3.8 para determinar su
complejidad.
Tabla 3.8: Criterio para determinar la complejidad de las Entradas
0 a 1 FTR Baja Baja Media
2 FTRs Baja Media Alta
3 ms FTRs Media Alta Alta

- Determinacin de complejidad de las Salidas (EO) y Consultas (EQ)

Salidas: una Salida es un proceso elemental o una accin que enva datos o informacin
de control hacia fuera de la frontera de la aplicacin. El objetivo fundamental es
presentar informacin al usuario a travs del procesamiento lgico de los datos o de la
informacin de control obtenida. El procesamiento lgico debe contener al menos una
frmula o clculo matemtico o crear datos derivados de los obtenidos. Un EO podra
mantener uno o ms ILF y/o alterar el comportamiento del sistema.
73

1. El proceso enva datos informacin de control.
2. Los datos o informacin de control se envan a travs de un proceso elemental de
la aplicacin.
3. El proceso es la unidad ms pequea de actividad que es significativa para el
negocio del usuario final.
4. El proceso es autocontenido y deja a la aplicacin en un estado consistente.
5. El proceso identificado debe verificar alguna de estas reglas:
a. Su lgica de proceso es nica respecto de otras salidas externas de la
aplicacin.
b. Los elementos de datos identificados son distintos a los de otras EOs de
la aplicacin.
c. Los ficheros lgicos referenciados son distintos.
6. Debe cumplirse al menos una de las siguientes condiciones:
a. El proceso elemental contiene al menos una frmula matemtica o
clculo.
b. El proceso crea datos derivados
c. El proceso que genera la salida mantiene algn ILF
d. El proceso que genera la salida altera el comportamiento del sistema.
7. La transferencia de datos a otras aplicaciones se cuenta como salidas
8. Los informes escritos y online se cuentan como salidas independientes.
9. Los grficos se cuentan como una salida cada uno.
Consultas: es un proceso elemental o una accin que enva datos o informacin de
control hacia fuera de la frontera de la aplicacin. El objetivo principal de un EQ es
presentar informacin al usuario a travs de la mera obtencin del dato o de la
informacin de control. A diferencia del EO, el procesamiento lgico no debe contener
ninguna frmula o clculo matemtico, ni tampoco debe crear datos derivados de los
obtenidos.
74

Por otra parte ningn ILF es mantenido mientras se procesa la accin de un EQ ni
tampoco el comportamiento del sistema se ve alterado.
Es una combinacin de entrada/salida que se obtiene de una bsqueda de datos, no
actualiza ficheros lgicos y no contiene datos derivados (aquellos que requieren un
proceso distinto a bsqueda, edicin o clasificacin).
1. Una peticin entra dentro del lmite de la aplicacin.
2. Un resultado sale del lmite de la aplicacin
3. Hay recuperacin de datos
4. Los datos recuperados no contienen datos derivados.
5. El proceso lgico no contiene frmulas matemticas o clculos
6. El proceso que genera la consulta no mantiene ningn ILF ni altera el
comportamiento del sistema
7. La peticin de entrada y el resultado de salida juntos, hacen del proceso la unidad
de actividad ms pequea que es significativa para el negocio del usuario final.
8. El proceso es autocontenido y deja a la aplicacin que est siendo contada en un
estado consistente.
9. El proceso no actualiza ILFs.
10. El proceso verifica alguna de estas dos reglas:
a. La lgica del proceso sobre la entrada y la salida es nica respecto a otras
consultas de la aplicacin
b. Los elementos de datos que forman la entrada y la salida son distintos a los
de las otras consultas de la aplicacin.
Los ficheros lgicos referenciados son distintos.
11. El proceso no actualiza ILFs.
12. El proceso verifica alguna de estas dos reglas:
75

a. La lgica del proceso sobre la entrada y la salida es nica respecto a otras
consultas de la aplicacin
b. Los elementos de datos que forman la entrada y la salida son distintos a los
de las otras consultas de la aplicacin.
c. Los ficheros lgicos referenciados son distintos.
La complejidad de las entradas se basa en la cuenta de DETs y FTRs:
DET: Data Element Type. Contar un DET por cada uno de los campos que cruzan las
fronteras de la aplicacin (tanto en la entrada como en la salida para el caso de las
consultas)
1. Contar un DET por cada campo reconocible por el usuario, no repetido, que entra
a la aplicacin y que se requiere para especificar cundo, qu o cmo deben ser
recuperados los datos de la salida.
2. Contar un DET por cada campo reconocible por el usuario no repetido que sale
de los lmites de la aplicacin.
3. Si un dato entra y sale de la aplicacin, contarlo una sola vez.
4. Sumar un DET por todos los mensajes de error del proceso.
5. Sumar un DET por la iniciacin del proceso, solo una vez aunque haya varias
formas de hacerlo.
6. No contar los datos recuperados o derivados por el sistema si no cruzaron los
lmites de la aplicacin.
FTR: File Type Referenced. Contar un FTR por cada fichero (interno o externo) ledo
por el proceso de la salida o consulta (DICYT, 2004).
Una vez identificados los DETs y FTRs de la salida, se puede utilizar la Tabla 3.9 para
determinar la complejidad.
76

Tabla 3.9: Criterio para determinar la complejidad de las Salidas y Consultas
0 a 1 FTR Baja Baja Media
2 a 3 FTRs Baja Media Alta
4 ms FTRs Media Alta Alta

3.2.5.2 Diseo

Para la etapa de diseo, solamente es importante considerar que cada una de las
funciones transaccionales y de datos, deben tener asociados sus respectivos DETs,
RETs, y FTRs. De tal forma de poder ser almacenar y procesar los datos para
realizar los clculos correspondientes. Esto queda reflejado en la Tabla 3.10.

Tabla 3.10: Representacin del almacenamiento de los datos principales del mtodo
CANTIDAD
ENTRADAS
CANTIDAD DETS
ENTRADAS
CANTIDAD FTRS
ENTRADAS
CANTIDAD
SALIDAS
CANTIDAD DETS
SALIDAS
CANTIDAD FTRS
SALIDAS

CANTIDAD
CONSULTAS
CANTIDAD DETS
CONSULTAS
CANTIDAD FTRS
CONSULTAS
CANTIDAD
ARCHIVOS
CANTIDAD DETS
ARCHIVOS
CANTIDAD RETS
ARCHIVOS

3.2.5.5 Implementacin

Siguiendo el principio anterior, en la etapa de implementacin, se crean los formularios
correspondientes, que le permitirn al usuario incorporar los datos del sistema o
proyecto del que desea estimar su esfuerzo. Cada uno de los campos del formulario
estarn validados segn los criterios sealados en la seccin 3.2.4.1 (de anlisis). Por
ejemplo: debern ser nmero enteros positivos, entre otros factores a considerar. En la
Figura 3-24 se puede apreciar el formulario correspondiente a las Entradas (External
CANTIDAD
INTERFACES
CANTIDAD DETS
INTERFACES
CANTIDAD RETS
INTERFACES

77

Inputs). En la Figura 3-25 se visualiza el formulario que permite decidir entre incorporar
otro tipo de Entrada o por el contrario, pasar al ingreso de las Salidas (External Outputs)
del sistema que se est evaluando. El sistema en general, permite el ingreso de un
nmero indeterminado de tipos de funciones transaccionales y de datos.

Figura 3-24: Formulario para el ingreso de los datos de las Entradas

Figura 3-25: Decisin entre ingreso de otra Entrada o de las Salidas
78

El proceso para incorporar los datos de las Salidas es similar. Aquello queda
representado en las Figuras 3-26 y 3-27.

Figura 3-26: Formulario para el ingreso de los datos de las Salidas

Figura 3-27: Decisin entre ingreso de otra Salida o de las Consultas

En el caso de los funciones de datos (archivos lgicos internos y externos), el proceso es
similar, pero en este caso, los datos que se almacenan corresponden a los componentes
79

primarios DETs y RETs. Aquello queda representado en la Figura 3-28. Luego, el
usuario puede decidir entre ingresar otro tipo de Archivo Lgico Interno o bien, pasar al
ingreso de los datos asociados a los Archivos Lgicos Externos, tambin conocidos
como Interfaces. Esto se puede visualizar en le Figura 3-29.

Figura 3-28: Formulario para el ingreso de los datos de los Archivos Lgicos Internos

Figura 3-29: Decisin entre ingreso de otro Archivo Lgico Interno o de Interfaces

80

El proceso de clculo de los Puntos de Funcin Sin Ajustar (PFSA) es similar y se basa
en las mismas ecuaciones que el Mtodo de Puntos de Funcin Tradicional con entradas
directas. Los mtodos de clculo ya han sido explicados a lo largo del presente Captulo.
Una vez calculados los PFSA, se puede escoger alguno de los Mtodos de Ajuste
descritos anteriormente tal como aparece en la Figura 3-30.

Figura 3-30: Eleccin del Mtodo de Ajuste:
El resultado final de la estimacin, se muestra de la misma forma que por ejemplo en la
Figura 3-18.

3.3 PUNTOS DE FUNCIN MODIFICADO 1 (PFM1)

3.3.1 Anlisis

Una de las falencias del mtodo de puntos de funcin tradicional, es su baja
granularidad, la cual permite clasificar la complejidad de sus entradas (funciones
transaccionales y de datos) solamente en tres categoras: simples, medias y complejas.
Adems, se pueden identificar por lo menos dos problemas serios en este mtodo de
clasificacin:
81

- P1: Funciones de diferentes tamaos, reciben el mismo valor desde la
perspectiva de APF.
- P2: Funciones similares, se clasifican abruptamente en grupos diferentes.
En el mtodo de puntos de funcin modificado, se busca enfrentar dicha falencia,
precisamente aumentando la granularidad del mtodo tradicional.
Para ello, se utilizaron conceptos de Teora de Lgica Difusa para extender el Anlisis
de Puntos de Funcin (APF) en Anlisis de Puntos de Funcin Difusos (APFD)
(Belchior, Junior & Farias, 2003).
La motivacin principal de la lgica difusa es el deseo de construir una estructura
cuantitativa formal, capaz de capturar la imprecisin del conocimiento humano, es decir,
la manera en la cual el conocimiento se expresa en lenguaje natural. Esta teora busca
reducir la brecha que separa los modelos matemticos tradicionales necesitados para
sistemas fsicos, y la representacin mental, generalmente imprecisa, de tales sistemas
(Dubois & Prade, 1991).
3.3.1.1 Aproximacin a la Teora de los Conjuntos Difusos

La teora difusa est inspirada en la forma en que los cerebros humanos obtienen y
procesan los datos con bajos costos y alta eficiencia (Wang & Tan, 1997), es decir, la
forma en que las mentes humanas usan conceptos subjetivos, por ejemplo, alto, bajo,
nuevo y viejo (trminos lingsticos) considerando el hecho natural de organizacin,
clasificacin y agrupamiento de conjuntos, objetos con caractersticas comunes (Pedrycz
& Gomide, 1998).
Un conjunto difuso se caracteriza por una funcin de pertenencia, la cual mapea los
elementos de un dominio, espacio o universo del discurso X por un nmero real en [0,
1]. Formalmente, ] 1 , 0 [ X : A
~
.Por lo tanto, un conjunto difuso es presentado como un
conjunto de pares ordenados en los cuales el primer elemento es X xe , y el segundo,
82

) x (
A
~ , es el grado de pertenencia o la funcin de pertenencia de x en A
~
, la cual mapea
x en el intervalo [0, 1], o, } X x | )) x ( , x {( A
~
A
~ e = (Zadeh, 1965).
La pertenencia de un elemento dentro de cierto conjunto se convierte en una cuestin de
grado, substituyendo el dicotmico proceso actual impuesto por la teora de conjuntos
(Pedrycz & Gomide, 1998), cuando este trato no es adecuado. En casos extremos, el
grado de pertenencia es 0, en cuyos caso el elemento no es miembro del conjunto, o el
grado de pertenencia es 1, si el elemento es un 100% miembro del conjunto (Turksen,
1991).
Por lo tanto, un conjunto difuso emerge de la extensin de un conjunto ntido que
empieza por incorporar aspectos de incerteza. Este proceso de conoce como
Fusificacin. La Defusificacin corresponde al proceso inverso, esto es, la conversin
del conjunto difuso en un valor ntido (o un vector de valores) (Zimmermann, 1991).
Tericamente, cualquier funcin de la forma: ] 1 , 0 [ X : A
~
puede ser asociada con un
conjunto difuso dependiendo de los conceptos y propiedades que necesite para ser
representado junto con el contexto en el cual el conjunto se inserta. Sin embargo, la
literatura ya contiene familias de funciones de pertenencia parametrizadas como por
ejemplo: funciones, triangulares, exponenciales y de Gauss, entre otras. Cada una de
estas funciones se caracteriza por un nmero difuso que es un convexo y normalizado
conjunto difuso definido en el conjunto de los nmeros reales 9, tal que su funcin de
pertenencia tiene la forma ] 1 , 0 [ :
A
~ 9 (Klir & Yuan, 1995).
La lgica difusa es tambin otra extensin realizada a la lgica booleana que puede ser
considerada una generalizacin de la lgica multivaluada. Modelando las incertezas del
lenguaje natural a travs de conceptos de valores parciales de verdad cayendo en algn
lugar entre completamente verdad y completamente falso (Kantrowitz, 1997). La lgica
difusa trata con tales valores a travs de conjuntos difusos en el intervalo [0, 1]. Estas
caractersticas le permiten a la lgica difusa manipular objetos del mundo real que
83

poseen lmites imprecisos. Utilizando predicados difusos (viejo, nuevo, alto, entre otros),
cuantificadores difusos (muchos, pocos, casi todos, por nombrar algunos), valores de
verdad difusos (completamente verdad, ms o menos verdad) (Dubois & Prade, 1991) y
generalizando el significado de conectores y operadores lgicos, la lgica difusa se
considera como un medio de razonamiento aproximado (Grauel, 1999).
3.3.1.2 Anlisis de Puntos de Funcin Difusos

La idea central de extender APF a APFD mediante la teora de conjuntos difusos, es
expandir la semntica tradicional de APF utilizando conceptos y formalismos
matemticos de esta conocida teora.
Los tipos de funciones de datos (ILF y EIF) y funciones transaccionales (EI, EO y EQ),
dentro de sus respectivas matrices de complejidad funcional, pueden ser mapeadas a un
universo X, el cual corresponde a DETs referenciados, los cuales corresponden a una
unidad de medida comn a todas las matrices de complejidad funcional. Todas estas
matrices usan los mismos trminos lingsticos: bajo, medio y alto, para expresar su
complejidad. Para cada lnea de estas matrices, los nmeros difusos fueron generados
por cada uno de sus trminos lingsticos.
Los nmeros difusos con forma triangular son perfectos para representar valores
alrededor de un punto especfico, un hecho que tambin puede ser observado a travs de
sus propiedades geomtricas. Esta caracterstica impide que tales tipos de nmeros
difusos puedan ser usados en el modelo, porque APF usa intervalos de valores en sus
matrices de complejidad.
Los nmeros difusos representados por las funciones S y

pueden ser aplicados por
bandas de valores. Sin embargo, estas funciones empiezan a generar el valor 1 cuando el
nmero de DETs sobrepasa una cierta cantidad. Este resultado es slo deseable en las
funciones que pertenecen al ltimo intervalo de complejidad. Tales funciones fueron
descartadas para mantener la uniformidad a lo largo del modelo, aplicando la misma
84

clase de funciones de pertenencia para todos los intervalos de las matrices de
complejidad de APF.
Siguiendo estas preferencias, los nmeros difusos de forma trapezoidal fueron
seleccionados para ser aplicados en el modelo de APFD, porque son apropiados para
usar bandas de valores. Mediante los nmeros difusos de forma trapezoidal, fue posible
mantener los valores usados en las matrices de complejidad en APF, adems permiten
superar las desventajas presentes en APF y comentadas anteriormente.
Un nmero difuso con forma trapezoidal puede ser representado por ) b , n , m , a ( N
~
, cuyas
funciones de pertenencia son representadas en la Ecuacin 3.10. El valor de a y b
identifica el lmite ms bajo y ms alto respectivamente, de la base ms grande del
trapezoide, donde 0 ) x (
A
~ = . Los valores m y n corresponden a los lmites ms bajo y
ms alto respectivamente, de la base ms pequea del trapezoide, donde 1 ) x (
A
~ = , lo
cual se muestra en la Figura 3-31.

= ) x (
A
~

Figura 3-31: Nmero Difuso Trapezoidal
0, para x < a
(x - a)/(m - a), para x [a, m]
1, para x [m, n]
(b - x)/(b - n), para x [n, b]
0, para x > b
(3.10)
85

El anlisis de puntos difusos de funcin (APDF) consiste en cuatro etapas (Lima, 2001):
1. Fusificacin de trminos lingsticos de las matrices de complejidad de APF,
generando nmeros difusos trapezoidales.
2. Extender las matrices de complejidad de APF, generando nuevos trminos
lingsticos.
3. Determinar valores de puntos de funcin para estos nuevos trminos lingsticos.
4. Defusificacin de los trminos lingsticos.

1. Primera etapa
En esta etapa, los nmeros difusos trapezoidales ) b , n , m , a ( N
~
se generan para cada
trmino lingstico T
i
(bajo, medio, alto) perteneciendo a la matriz de complejidad de las
funciones transaccionales y de datos. El valor m
i
asume el lmite ms bajo del trmino
lingstico i de la matriz de complejidad que est siendo analizada. El valor n
i
se calcula
con el promedio matemtico de los valores de m
i
y m
i+1
. Los valores para n
i-1
y

m
i+1
se
atribuyen a a
i
y b
i
, respectivamente.

Los ajustes necesarios se realizan cuando se trata
con el primero o el ltimo trmino lingstico de acuerdo a la Ecuacin 3.10.
Como ejemplo, en la Figura 3-32 se puede apreciar la matriz de complejidad de un ILF.
De acuerdo a la Tabla 3.11, considerando un nmero de RETs entre 2 y 5, y el trmino
lingstico medio. En este caso, m = 20 y n = (20+51)/2 = 35,5. El valor para a y b es
10,5 y 51, respectivamente.
Tabla 3.11: Matriz de Complejidad de los Archivos Lgicos.
Determinacin de Complejidad de los Archivos Lgicos
N de tipos de registros lgicos N de campos

1 a 19 20 a 50 51 y ms

1 Simple Simple Medio

2 a 5 Simple Medio Complejo

6 y ms Medio Complejo Complejo

86

Figura 3-32: Nmero Difuso Trapezoidal para el trmino lingstico Medio, de 2 a 5
RETs

2. Segunda Etapa

En esta etapa se busca minimizar el segundo problema (P2) mencionado en la seccin
3.3.1, el cual se vuelve an ms crtico cuando el nmero de RETs y el nmero de FTRs
se incrementa en las funciones de datos y transaccionales, respectivamente.
En este contexto, un nuevo intervalo de alta complejidad fue agregado a las funciones de
datos y transaccionales que requera un mayor intervalo de complejidad media. Por la
misma razn, un nuevo intervalo de complejidad muy alta, fue agregado para las
restantes funciones, aplicando el modificador muy para el trmino lingstico alto.
Debido a la semntica del nuevo nmero difuso generado en APFD (muy alta), la
operacin de transformacin indicada en la literatura para el modificador muy no fue
aplicada. La pregunta crtica respecto a este nuevo nmero difuso
i
N
~
es el clculo del
valor ms apropiado para m
i
y n
i-1.
El valor de n
i-1,
para el cual se calcula el valor de m
i,
corresponde al punto en el cual la funcin de pertenencia empezar a perder
caractersticas de alta complejidad y consecuentemente comienza a adquirir
caractersticas de muy alta complejidad.
87

La ltima lnea de la matriz de complejidad de cada funcin fue el punto de inicio para
la creacin del nuevo nmero difuso. De acuerdo con lo que se ha establecido en
(FPCPM, 1999), las funciones que caen en las ltimas dos celdas de la matriz son de
complejidad alta. Con la intencin de mantener el uso de valores usados por la (FPCPM,
1999), se decidi que el nmero que indica el lmite menor de la tercera columna de la
matriz, representa el valor n del conjunto difuso de las funciones de alta complejidad.
En un ILF, por ejemplo, el valor de n
i-1
debera ser 51 DETs, como se muestra en la
Tabla 3.12. Desde que el valor de n
i-1
de cualquier nmero difuso dado corresponde al
valor de a
i
, se entiende que el valor de a
i
para el nmero difuso de una funcin de muy
alta complejidad debera ser 51. Desde que el valor de a
i
se calcula con el promedio
matemtico de m
i
y m
i-1
, entonces para un ILF, el valor de m
i
= 82, como se indica a
continuacin.
(m + 20)/2 = 51 => m = 82
La Tabla 3.12 representa la extensin realizada a los valores del trmino lingstico muy
alto, a cada funcin correspondiente a APF.
Tabla 3.12: Valores de m
i
para el trmino lingstico muy alto
Tipo de
Funcin
T
i-1
n
i-1
m
i-1
T
i
m
i

ILF ALTO 51 20 MUY ALTO 82
EIF ALTO 51 20 MUY ALTO 82
EI ALTO 16 5 MUY ALTO 27
EO ALTO 20 6 MUY ALTO 34
EQ ALTO 20 6 MUY ALTO 34

Desde este punto en adelante, el valor de m
i
para un nmero difuso de muy alta
complejidad se expresar en trminos de k, generalizando este nuevo trmino lingstico
88

en relacin a los otros que ya existen. El valor correspondiente a k debe ser calculado
para cada una de los cinco tipos de funciones pertenecientes a APF.
La Tabla 3.13 representa la versin extendida de la matriz de complejidad para los ILFs
(Archivos Lgicos Internos).
Tabla 3.13: Matriz extendida de complejidad para los ILFs

Determinacin de Complejidad de los Archivos Lgicos Internos

N de tipos de registros lgicos
(RETs)

N de campos (DETs)

1 a 19 20 a 50 51 a k-1 k o ms
1

Simple Simple Medio Complejo
2 a 5

Simple Medio Complejo Muy
Complejo
6 ms

Medio Complejo Complejo Muy
Complejo

Reemplazando por k = 82 (valor calculado anteriormente) y basndose en la Tabla 3.13,
las funciones de pertenencia de los nmeros difusos trapezoidales, se presentan en las
Figuras 3-33, 3-34 y 3-35 para cada una de las tres lneas de la matriz de complejidad de
un ILF, de acuerdo al modelo descrito anteriormente.

Figura 3-33: Funcin de Pertenencia para los nmeros difusos caso ILFs con 1 RET
89

Figura 3-34: Funcin de Pertenencia para los nmeros difusos caso ILFs desde 2 a 5
RETs

Figura 3-35: Funcin de Pertenencia para los nmeros difusos caso ILFs con 6 ms
RETs

3. Tercera Etapa

En APF, p
i
puntos de funcin son atribuidos a cada trmino lingstico T
i
(bajo, medio y
alto) de acuerdo con la matriz de complejidad que se est analizando. En APFD, estos
puntos son directamente asociados con los nmeros difusos de los trminos lingsticos,
donde 1 (x)
N
~ = .

El valor de los puntos de funcin para el nuevo trmino lingstico de muy alta
complejidad se calcula por la interpolacin de los valores ya definidos para los trminos
bajo, medio y alto de cada funcin.
90

Ya que los grupos que representan los trminos lingsticos estn igualmente
espaciados, se vuelve viable aplicar interpolacin con diferencias finitas, un caso
especial de un binomio de interpolacin en el cual las abscisas de los puntos son
equidistantes. Especialmente, la frmula o polinomio de Newton la cual se explica
detalladamente en (Santos, 1972). Esta se puede apreciar en la Ecuacin 3.11.
0
n
u
n
0
2
u
2
0
u
1
0 n
f ... f f f (u) p
|
.
|
\
|
+ +
|
.
|
\
|
+
|
.
|
\
|
+ =

Donde f
0
es el primer valor de la serie numrica, u es el valor correspondiente a la
abscisa x en la interpolacin y

es el operador de las diferencias progresivas. En este
caso, los valores para las abscisas 1, 2, 3 y 4 fueron atribuidos a los trminos bajo,
medio, alto y muy alto, respectivamente. El valor de u se obtiene mediante la Ecuacin
3.12.
h
x x
u
0
=
Donde h es el paso, en otras palabras, al diferencia entre el valor de dos valores
subsecuentes de x. El valor de u es 3 para todas las funciones transaccionales y de datos,
ya que h = 1(paso), x = 4 (muy alto) y x
0
= 1 (bajo).
Los trminos f
i
y [f(x)]
n
de la funcin de aproximacin se calculan segn las
Ecuaciones 3.13 y 3.14.
i 1 i i
f f f + =
+

)] x ( f [ )] h x ( f [ )] x ( f [
1 n 1 n n
+ =
Donde f
i+1
y f
i
son dos valores subsecuentes de la serie numrica y n = 2, 3,.
(3.11)
(3.12)
(3.13)
(3.14)
91

Aplicando las definiciones anteriores, los valores obtenidos para los nmeros difusos de
las funciones de muy alta complejidad fueron estimados, lo cual se muestra en la Tabla
3.14.
Tabla 3.14: Tabla de diferencias finitas para ILF
Complejidad i fi
2
fi
Bajo 0 7 3 2
Media 1 10 5 -
Alta 2 15 - -

El valor de los puntos de funcin para el trmino muy alto de un ILF se obtuvo
sustituyendo los trminos anteriores en la funcin de aproximacin, de la siguiente
forma:
-
0
2
u
2
0
u
1
0 2
f f f (u) p
|
|
.
|
\
|
+
|
|
.
|
\
|
+ =
- 2 3 7 (3) p
3
2
3
1
2

|
|
.
|
\
|
+
|
|
.
|
\
|
+ =
- 22 (2) 3 (3) 3 7 (3) p
2
= + + =
De esta forma, un ILF de muy alta complejidad equivale a 22 puntos de funcin.
Repitiendo las definiciones anteriores, los valores de 14, 9, 10 y 9 puntos de funcin
fueron obtenidos por los nmeros difusos de las funciones de muy alta complejidad, para
los tipos de funciones: EIFs, EIs, EOs and EQs, respectivamente.

92

4. Cuarta Etapa

Siguiendo el criterio de defusificacin de (Leekwijck, 1999). En APFD, para obtener el
nmero de puntos de funcin p
d
desde los nmeros difusos trapezoidales, donde
(x) < 1, se ejecuta el siguiente proceso de Defusificacin (Ecuacin 3.14).

1 i
N
~
i
N
~
d
p ) x ( p ) x ( p
+
+ =
Aplicando la definicin anterior, a un ILF con 1 RET y 35 DETs, se tiene:
64 , 0 ) 26 51 /( ) 35 51 ( ) 35 (
N
~ = = y el complemento
36 , 0 ) 35 (
N
~ =
08 , 8 ) 10 ( 36 , 0 ) 7 ( 64 , 0 p
d
= + = Puntos de funcin.

3.3.2 Diseo

Una vez terminada la etapa de anlisis, en la etapa de diseo se expondrn aquellas
tablas que resumen los valores ms relevantes, obtenidos luego de aplicar
sistemticamente las definiciones y ecuaciones indicadas en la seccin anterior. La
Tabla 3.15 por ejemplo, muestra el resultado de aplicar el mtodo de diferencias finitas y
el polinomio de interpolacin de Newton para obtener las complejidades de cada una de
las funciones transaccionales y de datos. Adems, al igual que el Mtodo de Puntos de
Funcin Tradicional, el Mtodo de Puntos de Funcin Modificado, ya sea en su versin
difusa o no difusa, se puede ajustar a travs de tres diferentes mtodos: el tradicional, el
modificado y COCOMO II. Dichos mtodos de ajuste ya fueron descritos en las
secciones: 3.2.3.1, 3.2.3.2 y 3.2.4, respectivamente.
(3.14)
93

Tabla 3.15: Esquema de clculo de los Puntos de Funcin Modificados No Difusos

Factor

*

N

=

Puntos

Entradas
Simple 3 *

0

Media 4 *

0

Compleja 6 *

0

Muy Compleja 9 *

0

Consultas
Simple 3 *

0

Media 4 *

0

Compleja 6 *

0

Muy Compleja 9 *

0

Salidas
Simple 4 *

0

Promedia 5 *

0

Compleja 7 *

0

Muy Compleja 10 *

0

Archivos
Lgicos
Simple 7 *

0

Media 10 *

0

Compleja 15 *

0

Muy Compleja 22 *

0

Interfaces
Simple 5 *

0

Media 7 *

0

Compleja 10 *

0

Muy Compleja 14 *

0

Total Puntos de Funcin Sin Ajustar
(PFSA)

=

Suma de Puntos

Factor de Ajuste (FA): Depender del mtodo de ajuste escogido, que puede ser: el
tradicional, el modificado o COCOMO II

Total Punto de Funcin Ajustados (PFA)

=

PFSA * FA

94

La Tabla 3.15 permite realizar el clculo de los Puntos de Funcin Modificados
mediante el mtodo directo, es decir, cuando se asigna el tipo de complejidad de forma
subjetiva. Por el contrario, Las Tablas 3.16, 3.17, 3.18, 3.19 y 3.20 permiten el clculo
de los Puntos de Funcin Modificados en forma Indirecta, en donde los tipos de
complejidad se asignan mediante un mtodo objetivo utilizando como parmetros de
medicin el nmero de RETs, DETs y FTRs.
Tabla 3.16: Complejidad de las Entradas

Determinacin de Complejidad de las Entradas

N de archivos lgicos necesarios
en lnea
N de campos en entrada

1 a 4 5 a 15 16 a 26 27 y ms
0 1

2

Complejo
3 o ms

Complejo

Tabla 3.17: Complejidad de las Salidas

Determinacin de Complejidad de las Salidas
N de archivos lgicos necesarios en
lnea

1 a 5 6 a 19 20 a 33 34 y ms
0 1 Simple Simple Medio Complejo
2 3 Simple Medio Complejo Muy
Complejo
4 y ms Medio Complejo Complejo Muy
Complejo

95

Tabla 3.18: Complejidad de las Consultas

Determinacin de Complejidad de las Consultas

lnea


1 a 5 6 a 19 20 a 33 34 y ms
0 1

2 3

Complejo
4 y ms

Complejo

Tabla 3.19: Complejidad de los Archivos Lgicos



N de campos

1 a 19 20 a 50 51 a 81 82 y ms
1

2 a 5

Complejo
6 y ms

Complejo

96

Tabla 3.20: Complejidad de Interfaces

Determinacin de Complejidad de las Interfaces


N de campos

1 a 19 20 a 50 51 a 81 82 y ms
1

2 a 5

Complejo
6 y ms

Complejo

Las tablas que permiten realizar el clculo de los Puntos de Funcin Difusos, se incluyen
en el Apndice A.

3.3.3 Implementacin

Una vez terminado el anlisis y el diseo, la implementacin se realiz en dos etapas. En
la primera, se implement el Mtodo de Puntos de Funcin Modificado con entradas
directas, donde el usuario puede ingresar la complejidad de cada una de las funciones
transaccionales y de datos en forma inmediata y subjetiva. Aquello se puede apreciar en
la Figura 3-36. Se pone como ejemplo solamente el ingreso de los datos
correspondientes a las Entradas, debido a que dicho proceso se repite de forma similar
con la incorporacin de los datos de los dems tipos de funciones.
En la segunda etapa, se implement el clculo de los Puntos de Funcin con entradas
indirectas, en donde se calcula en forma inmediata tanto la versin difusa como No
difusa, debido a que las entradas son las mismas. Aquello se puede visualizar en la
Figura 3-37. Nuevamente el proceso se repite de forma similar con el resto de las
funciones, por ende, se omite el detalle.
97

Figura 3-36: Ingreso de Datos de entradas PF Modificado Directo

Figura 3-37: Ingreso de Datos para Mtodo Indirecto

Una vez ingresados todos los datos necesarios, el usuario deber elegir con qu tipo de
mtodo desea calcular los Puntos de Funcin Sin Ajustar. En este caso puede elegir entre
Mtodo Lgica Difusa 1 o Mtodo Tradicional M1, los cuales se explicaron en la
actual seccin. Esto se puede apreciar en la Figura 3-38.
98

Figura 3-38: Eleccin del Tipo de Mtodo de Puntos de Funcin

Finalmente, el usuario puede escoger el mtodo de ajuste que estime ms conveniente,
entre las tres opciones disponibles: Mtodo de Ajuste Tradicional, Mtodo de Ajuste
Modificado y COCOMO II, los cuales fueron descritos en las secciones 3.2.3.1,
3.2.3.2 y 3.2.4, respectivamente.

3.4 PUNTOS DE FUNCIN MODIFICADO 2 (PFM2)

3.4.1 Anlisis

El objetivo de esta versin del mtodo de puntos de funcin, fue aumentar an ms la
granularidad con respecto al mtodo anterior. Considerando por ejemplo, que una de las
desventajas del Anlisis de Puntos de Funcin (APF) en general, es que su nivel de
99

precisin disminuye al estimar proyectos de menor tamao, es decir, de menos de 100
PFs (Systemation, 2009). Por lo tanto, en este caso se agreg un grado ms de
granularidad con respecto a aquellas funciones transaccionales y de datos de menor
complejidad, incorporando el trmino lingstico muy simple. La idea principal era
incorporar un parmetro para medir aquellos casos en donde, producto de la
configuracin original del mtodo, necesariamente partan de un valor asociado a la
complejidad (simple) mayor que el real. Agregando entonces una nueva opcin (muy
simple), se puede tender a ajustar el mtodo para aquellos proyectos de menor
complejidad.
Originalmente, se realiz el clculo del nuevo valor asociado al trmino lingstico muy
simple, mediante la utilizacin del mtodo de diferencias finitas y polinomio de
interpolacin Newton, tomando como base los valores calculados en el mtodo de
puntos de funcin definido en la seccin anterior. No obstante, los resultados no fueron
satisfactorios, debido a que la diferencia entre el valor calculado para el trmino
lingstico muy simple y el trmino lingstico simple, fue mnima y en algunos casos,
inexistente.
De acuerdo a lo anterior, se decidi incorporar un valor razonablemente diferente para el
nuevo trmino lingstico, el cual realmente aportara en granularidad al mtodo en
general. Luego, tomando como base este factor, junto a aquellos valores de complejidad
base del Anlisis de Puntos de Funcin (APF), se aplico el mtodo de diferencias finitas
y el polinomio de interpolacin de Newton para recalcular el valor asociado al trmino
lingstico muy complejo. Los resultados finales se pueden apreciar en la Tabla 3.21. Las
ecuaciones necesarias para realizar los clculos se explicaron en la seccin anterior.

100

3.4.2 Diseo

El diseo es similar al descrito en el mtodo anterior, debido a que se basa en principios
similares. En la Tabla 3.21 por lo tanto, se muestra el resultado de aplicar el mtodo de
diferencias finitas y el polinomio de interpolacin de Newton para obtener las
complejidades de cada una de las funciones transaccionales y de datos. Adems, al igual
que el Mtodo de Puntos de Funcin Tradicional, el Mtodo de Puntos de Funcin
Modificado Versin 2, ya sea en su versin difusa o no difusa, se puede ajustar a travs
de tres diferentes mtodos: el tradicional, el modificado y COCOMO II. Dichos mtodos
de ajuste ya fueron descritos en las secciones: 3.2.3.1, 3.2.3.2 y 3.2.4, respectivamente.

Tabla 3.21: Resumen de clculo de los Puntos de Funcin Modificados No Difusos V2

Factor * N = Punto
s
Entradas
Muy Simple 2
*
0

Simples 3 * 0
Promedia 4 * 0
Compleja 6 * 0
Muy Compleja 10 * 0

Consultas
Muy Simple 2 0

Simples 3 * 0
Promedia 4 * 0
Compleja 6 * 0
Muy Compleja 10 * 0

Salidas
Muy Simple 3 * 0

Simples 4 * 0
Promedia 5 * 0
Compleja 7 * 0
Muy Compleja 11 * 0

101

Archivos Lgicos
Muy Simple 5 * 0
Simples 7 * 0
Promedia 10 * 0
Compleja 15 * 0
Muy Compleja 23 * 0

Interfaces
Muy Simple 4 * 0

Simples 5 * 0
Promedia 7 * 0
Compleja 10 * 0
Muy Compleja 14 * 0

Total Puntos de Funcin Sin Ajustar (PFSA) = Suma de Puntos
Factor de Ajuste (FA): Depender del Mtodo de ajuste escogido, que puede ser: el tradicional, el
modificado o COCOMO II

Total Punto de Funcin Ajustados (PFA) = PFSA * FA

La Tabla 3.21 permite realizar el clculo de los Puntos de Funcin Modificados
mediante el mtodo directo, es decir, cuando se asigna el tipo de complejidad de forma
subjetiva. Por el contrario, Las Tablas 3.22, 3.23, 3.24, 3.25 y 3.26 permiten el clculo
de los Puntos de Funcin Modificados (Versin 2) en forma indirecta, en donde los tipos
de complejidad se asignan mediante un mtodo objetivo utilizando como parmetros de
medicin el nmero de RETs, DETs y FTRs.
Tabla 3.22: Complejidad de las Entradas Mtodo 2
Determinacin de Complejidad de las Entradas
lnea
1 a 2 3 a 4 5 a 15 16 a 26 27 y ms
0 1 Muy
Simple
Muy Simple Simple Medio Complejo
2

Muy
Simple
Complejo
3 ms Simple Medio Complejo Complejo Muy
Complejo
102

Tabla 3.23: Complejidad de las Salidas Mtodo 2
Determinacin de Complejidad de las Salidas

N de archivos lgicos
necesarios en lnea


1 a 2 3 a 5 6 a 19 20 a 33 34 y ms
0 1

Muy Simple Muy
Simple
Simple Medio Complejo
2 3 Muy Simple Simple Medio Complejo Muy
Complejo
4 y ms Simple Medio Complejo Complejo Muy
Complejo

Tabla 3.24: Complejidad de las Consultas Mtodo 2
Determinacin de Complejidad de las Consultas

N de archivos lgicos
necesarios en lnea


1 a 2 3 a 5 6 a 19 20 a 33 34 y ms
0 1 Muy Simple Muy Simple Simple Medio Complejo
2 3 Muy Simple Simple Medio Complejo Muy
Complejo
4 y ms Simple Medio Complejo Complejo Muy
Complejo

Tabla 3.25: Complejidad de los Archivos Lgicos Mtodo 2
N de tipos de registros
lgicos
N de campos
1 a 9 10 a 19 20 a 50 51 a 81 82 y ms
1

Muy Simple Muy Simple Simple Medio Complejo
2 a 5

Muy Simple Simple Medio Complejo Muy
Complejo
6 y ms

Simple Medio Complejo Complejo Muy
Complejo
103

Tabla 3.26: Complejidad de las Interfaces Mtodo 2
Determinacin de Complejidad de las Interfaces
N de tipos de registros
lgicos
N de campos
1 a 9 10 a 19 20 a 50 51 a 81 82 y ms
1

Muy Simple Muy Simple Simple Medio Complejo
2 a 5

Muy Simple Simple Medio Complejo Muy
Complejo
6 y ms

Simple Medio Complejo Complejo Muy
Complejo

Las tablas que permiten realizar el clculo de los Puntos de Funcin Difusos Versin 2,
se incluyen en el Apndice B.

3.4.3 Implementacin

Una vez finalizado el anlisis y el diseo, la implementacin se realiz en dos etapas. En
la primera, se implement el Mtodo de Puntos de Funcin Modificado (Versin 2) con
entradas directas, donde el usuario puede ingresar la complejidad de cada una de las
funciones transaccionales y de datos en forma inmediata y subjetiva. Aquello se puede
apreciar en la Figura 3-39. Se pone como ejemplo solamente el ingreso de los datos
correspondientes a las Entradas, debido a que dicho proceso se repite de forma similar
con la incorporacin de los datos de los dems tipos de funciones.
En la segunda etapa, se implement el clculo de los Puntos de Funcin con entradas
indirectas, en donde se calcula en forma inmediata tanto la versin difusa como No
difusa, debido a que las entradas son las mismas. Aquello se puede visualizar en la
Figura 3-37. Nuevamente el proceso se repite de forma similar con el resto de las
funciones, por ende, se omite el detalle.

104

Figura 3-39: Ingreso de Datos de entradas PF Modificado Directo V2

Una vez ingresados todos los datos necesarios, el usuario deber elegir con qu tipo de
mtodo desea calcular los Puntos de Funcin Sin Ajustar. En este caso puede elegir entre
Mtodo Lgica Difusa 2 o Mtodo Tradicional M2, los cuales se explicaron en la
actual seccin. Esto se puede apreciar en la Figura 3-38.

Finalmente, el usuario puede escoger el mtodo de ajuste que estime ms conveniente,
entre las tres opciones disponibles: Mtodo de Ajuste Tradicional, Mtodo de Ajuste
Modificado y COCOMO II, los cuales fueron descritos en las secciones 3.2.3.1,
3.2.3.2 y 3.2.4, respectivamente.

105

3.5 PUNTOS DE CASOS DE USO VERSIN 1

3.5.1 Anlisis

Primeramente se describirn todos aquellos aspectos relevantes que se consideraron en
la etapa de anlisis, la cual es la base para el desarrollo el mtodo de Puntos de Casos de
Uso Versin 1

3.5.1.1 Introduccin

Una de las desventajas que presentan los Puntos de Funcin, es que corresponde a un
mtodo altamente abstracto, y para poder aplicarlo con un mayor grado de precisin, se
necesitan aos de experiencia en la utilizacin del mismo. Como una forma de mejorar
aquella falencia, surge la posibilidad de complementar el mtodo antes citado, con el
concepto de Casos de Uso, el cual es ampliamente utilizado en ingeniera de software.
La especificacin de los requerimientos mediante Casos de Uso ha probado ser uno de
los mtodos ms efectivos para capturar la funcionalidad de un sistema. Este hecho se
puede apreciar en algunas metodologas actuales ampliamente difundidas, como el
Proceso Unificado de Rational (Rational Unified Process).

Existe una relacin natural entre los Puntos de Funcin y los Casos de Uso. Los Puntos
de Funcin permiten estimar el tamao del software a partir de sus requerimientos,
mientras que los Casos de Uso permiten documentar los requerimientos del software.
Ambos tratan de ser independientes de las tecnologas utilizadas para la implementacin.

En etapas tempranas del ciclo de vida, se identifican los Actores y los Casos de Uso del
sistema, y se documenta cada uno de ellos mediante una breve descripcin. Aplicando el
Anlisis de Puntos de Funcin a estos Casos de Uso, se podr obtener una estimacin
del tamao y a partir de ella el esfuerzo. Esta estimacin es bastante imprecisa debido
106

principalmente, a la escasa informacin que se tiene sobre el software al principio de un
proyecto, pero permitir obtener una idea del esfuerzo necesario para llevar adelante el
mismo, y podr ser refinada a medida que se obtenga ms informacin.
Posteriormente se ampla la documentacin de cada Caso de Uso, describiendo los
Escenarios que se producen dentro del mismo. Un Escenario relata la secuencia de pasos
que efectan los actores y el sistema durante la ejecucin del Caso de Uso. Si se aplica
nuevamente el Anlisis de Puntos de Funcin sobre estos Casos de Uso detallados, la
estimacin del tamao y esfuerzo ser ms precisa que la anterior.
Otro concepto importante a considerar, es el de transaccin. La cual est representada
por uno o ms pasos del flujo de eventos principal del Caso de Uso, pudiendo existir
ms de una transaccin dentro del mismo. Los flujos de eventos alternativos dentro del
Caso de Uso, ayudan a clarificar las transacciones (Peralta, 2004).

3.5.1.2 Clculo de Casos de Usos sin Ajustar

Una vez definidos los conceptos generales, es posible detallar el mtodo de clculo de
los Puntos de Casos de Uso. En primera instancia, se deben calcular los Puntos de Casos
de Uso sin Ajustar, para ello se utiliza la Ecuacin 3.15.

FPCUSA FPASA PCUSA + =

Donde,
- PCUSA = Puntos de Casos de Uso sin Ajustar
- FPASA = Factor de Peso de los Actores sin Ajustar
- FPCUSA = Factor de Peso de los Casos de Uso sin Ajustar
(3.15)
107

- Factor de Peso de los Actores sin ajustar

Este valor se calcula mediante un anlisis de la cantidad de Actores presentes en el
sistema y la complejidad de cada uno de ellos. La complejidad de los Actores se
establece teniendo en cuenta en primer lugar si se trata de una persona o de otro sistema,
y en segundo lugar, la forma en la que el actor interacta con el sistema. Los criterios se
muestran en la Tabla 3.27:
Tabla 3.27: Factor de Peso de los Actores sin Ajustar
Tipo de Actor Descripcin Factor de
Peso
Simple Otro sistema que interacta con el sistema a desarrollar
mediante una interfaz de programacin (API, Application
Programming Interface)
1
Medio Otro sistema que interacta con el sistema a desarrollar
mediante un protocolo o una interfaz basada en texto
2
Complejo Una persona que interacta con el sistema mediante
una interfaz grfica
3

- Factor de Peso de los Casos de Uso sin ajustar

Este valor se calcula mediante un anlisis de la cantidad de Casos de Uso presentes en el
sistema y la complejidad de cada uno de ellos. La complejidad de los Casos de Uso se
establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo, donde
una transaccin se entiende como una secuencia de actividades atmica, es decir, se
efecta la secuencia de actividades completa, o no se efecta ninguna de las actividades
de la secuencia. Los criterios se muestran en la Tabla 3.28:
Tabla 3.28: Factor de Peso de los Casos de Uso sin Ajustar
Tipo de Caso
de Uso
Descripcin Factor de
Peso
Simple El Caso de Uso contiene de 1 a 3 transacciones 5
Medio El Caso de Uso contiene de 4 a 7 transacciones 10
Complejo El Caso de Uso contiene ms de 8 transacciones 15
108

3.5.1.3 Clculo de Puntos de Casos de Uso Ajustados

Una vez obtenidos los Puntos de Casos de Uso sin ajustar, estos se ajustan mediante la
Ecuacin 3.16, donde el Factor de Complejidad Tcnica se calcula a travs de la
Ecuacin 3.17 y el Factor de Ambiente se calcula mediante la Ecuacin 3.18.

FA FCT PCUSA PCUA - - = (3.16)

(3.17)

(3.18)

3.5.2 Diseo

Una vez precisados los conceptos y ecuaciones principales que permiten entender y
construir el mtodo descrito, es posible exponer las lneas generales y consideraciones
que en una primera instancia permitieron disearlo, base para la posterior
implementacin. En la Tabla 3.29 se puede visualizar cules son los campos principales
que se debern almacenar en la aplicacin que realizar, primeramente, el clculo de los
Puntos de Casos de Uso sin Ajustar.
Tabla 3.29: Campos que se almacenan en la Primera Etapa del Proceso
Cantidad Actores Tipo de Actor Cantidad Casos de Uso Tipo Caso de Uso

Considerando que los dems procesos descritos en la etapa de anlisis se realizarn en
forma interna y dependen de las ecuaciones antes descritas y no de captura de datos, se
expondr la forma en que (desde una perspectiva de diseo) se almacenarn los dems
) Asignado Valor Peso ( 01 . 0 6 . 0 FCT
i i
- - + =
) Asignado Valor Peso ( 03 . 0 4 . 1 FA
i i
- - =
109

datos que deber incorporar el usuario. La Tabla 3.30 representa el ingreso de los datos
correspondientes al Factor de Complejidad Tcnica valor que se utilizar para realizar el
clculo de los Puntos de Casos de Uso Ajustados (PCUA).
Tabla 3.30: Factores de Complejidad Tcnica
FACTOR Valor PESO FCTi
T1: Sistema Distribuido 2 0
T2: Performance 1 0
T3: Eficiencia del Usuario Final 1 0
T4: Complejidad del Procesamiento Interno 1 0
T5: Reusabilidad del Cdigo 1 0
T6: Facilidad de Instalacin 0,5 0
T7: Facilidad de Uso 0,5 0
T8: Portabilidad 2 0
T9: Facilidad de Cambio 1 0
T10: Concurrencia 1 0
T11: Objetivos Especiales de Seguridad 1 0
T12: Acceso Directo a terceros 1 0
T13: Entrenamiento de Usuarios 1 0
pesoi*ValorAsignadoi 0
FCT 0

Los Factores de Ambiente constituyen el elemento final y queda representado por la
Tabla 3.31. Luego, usando la Ecuacin 3.16 se puede realizar el clculo de los PCUA.

Tabla 3.31: Factores de Ambiente
FACTOR Valor PESO FAi
E1: Familiaridad con el Modelo de Proyecto

1,5 0
E2: Experiencia en la Aplicacin 0,5 0
E3: Experiencia en O.O. 1 0
E4: Capacidad del Analista Lder 0,5 0
E5: Motivacin 1 0
E6: Estabilidad de los Requerimientos 2 0
E7: Personal Part-time -1 0
110

E8: Dificultad del L.P. -1 0
Total 0
FA 0

3.5.3 Implementacin

Siguiendo las directrices de las secciones anteriores, para realizar la implementacin, se
utilizaron una serie de formularios para capturar los datos, primeramente de la Cantidad
de Actores y del Tipo (o complejidad) de ese conjunto de actores. Aquello se puede
visualizar en la Figura 3-40. En el caso del ingreso de la Cantidad de Actores, se
implement en base a un campo de texto y en el caso de los Tipos de Actores se
desarroll utilizando un ComboBox.

Figura 3-40: Ingreso de datos de los Actores

Adems, se realizaron todas las validaciones correspondientes, un ejemplo de ello se
puede apreciar en la Figura 3-41, donde se indica el tipo de nmero que se puede
ingresar en campo de Cantidad de Actores.
111

Figura 3-41: Validacin del Ingreso de los Actores

Luego de ingresar los datos de los actores, se muestra un cuadro de dilogo donde el
usuario puede decidir entre ingresar otro tipo de actor o pasar a la etapa del ingreso de
Casos de Uso. Esto se puede apreciar en la Figura 3-42.

Figura 3-42: Decisin entre ingreso de otro Actor o ingreso de Casos de Uso

En forma similar al ingreso de los datos correspondientes a los actores, los casos de uso
se incorporan mediante un campo de texto que solamente acepta nmeros enteros
112

positivos y un comboBox para seleccionar la complejidad asociada a cada uno de ellos.
En la Figura 3-43, se muestra el detalle de aquello.

Figura 3-43: Pantalla de Ingreso de Casos de Uso

Obviamente se realizan las validaciones correspondientes, en donde, si se llega a
incorporar algn dato con formato incorrecto, esto se le indica al usuario para que lo
rectifique, borrando automticamente el campo errneo. Aquello se refleja en la Figura
3-44.

Figura 3-44: Validacin del Ingreso de Casos de Uso

113

Luego de ingresar los datos del primer tipo de casos de uso, se muestra un cuadro de
dilogo donde el usuario puede decidir entre ingresar otro tipo de caso de uso o pasar a
la etapa de Clculo de Puntos de Casos de Uso sin Ajustar. Esto se puede apreciar en la
Figura 3-45.

Figura 3-45: Decisin entre el ingreso de otro Caso de Uso o el paso a la Etapa de
Clculo de PCUSA

Una vez ingresados todos los tipos de Actores y Casos de Uso, se pasa a la etapa de
Clculo de Puntos de Casos de Uso sin Ajustar (PCUSA). Todo este proceso se realiza
en forma interna y el usuario solamente necesita presionar aceptar para poder conocer el
valor deseado. El detalle de aquello se puede apreciar en la Figura 3-46.
Luego de realizado el proceso anterior, como se describi en la etapa de anlisis, se
deben calcular los Puntos de Casos de Uso Ajustados (PCUA). Para ello, se
implementaron dos formularios, compuestos por tablas, uno para incorporar los datos de
los Factores de Complejidad Tcnica y el otro para ingresar los datos de los Factores de
Ambiente. Esto se puede apreciar en las Figuras 3-47 y 3-48, respectivamente.
114

Figura 3-46: Clculo de PCUSA

Figura 3-47: Ingreso de Factores de Complejidad Tcnica

115

Figura 3-48: Ingreso de Factores de Ambiente

Posteriormente al ingreso de los Factores Tcnicos y de Ambiente, se puede pasar a la
pantalla donde se indica el valor de los Puntos de Casos de Uso Ajustados, el proceso de
clculo lo realiza el sistema en forma interna utilizando como base las ecuaciones
indicadas en la etapa de anlisis. El detalle se muestra en la Figura 3-49.

Figura 3-49: Clculo de los PCUA
116

Para finalizar, se deben transformar los Puntos de Casos de Uso Ajustados al esfuerzo
equivalente. Para ellos se debe incorporar el Factor de Conversin de PCU a Horas-
Hombre. Adems, es necesario incorporar las horas de trabajo efectivas mensuales, de
tal forma de poder expresar el esfuerzo tanto en Horas como en Meses-Hombre. Lo
anterior se puede visualizar en la Figura 3-50.

Figura 3-50: Incorporacin del Factor de Conversin y de las Horas de Efectivas de
Trabajo

Cabe recordar, que el valor obtenido solamente representa el tiempo requerido para
completar la etapa de implementacin (o programacin). Por ende, se usa esta
informacin como parmetro para estimar el tiempo asociado a las dems etapas. Esto se
puede visualizar en la Figura 3-51. Una vez incorporados los porcentajes de cada una de
las etapas del proceso de desarrollo del sistema, se puede conocer el detalle del esfuerzo
por actividad, tanto en horas como en meses-hombre. En la Figura 3-52 se puede
apreciar el detalle de lo antes descrito.
117

Figura 3-51: Asignacin de Porcentaje de Esfuerzo por Actividad

Figura 3-52: Visualizacin de los resultados de la estimacin.
118

3.6 PUNTOS DE CASOS DE USO VERSIN 2

3.6.1 Anlisis

An cuando la mtrica de Puntos de Casos de Uso (PCU) puede ser bastante til y
simple de utilizar, posee algunas limitaciones relacionadas principalmente con la
granularidad de los Casos de Uso. Para superar estas limitaciones, se implementar un
mtodo donde se introducen dos nuevas mtricas, ambas basadas en los CU. La primera,
denominada Puntos de Tamao de Casos de Uso (PTCU), considera las estructuras
internas de los CU y, por lo tanto, captura mejor su funcionalidad. La segunda,
denominada Puntos de Tamao de Casos de Uso Difusos (PTCUD), considera
conceptos de la Teora de Conjuntos Difusos para crear clasificaciones graduales que
enfrentan mejor la incertidumbre (Braz & Vergilio, 2006).
Aunque el mtodo descrito en la seccin 3.5 introduce nuevos elementos al campo de los
Puntos de Funcin al relacionarlos con los Casos de Uso, posee algunas limitaciones que
reducen la precisin de la estimacin. Por ejemplo, los CU solamente pueden ser
clasificados en tres categoras, independientemente de su estructura interna. No hay
diferencia entre CU grandes y enormes, ambos son clasificados como complejos. Otra
limitacin radica en que los se basan en ciertos elementos subjetivos, de forma similar a
los Puntos de Funcin de (Albrecht, 1983).
A continuacin, se explicarn en detalle aquellas mtricas que ayudan a superar aquellas
limitaciones.
3.6.1.1 Puntos de Tamao de Casos de Uso (PTCU)

Considera CU con notacin expandida (Larman, 2002) los cuales incluyen diferentes
secciones. Gracias a esto los PTCU pueden capturar mejor los aspectos de las
funcionalidades de los Casos de Uso. Adems puede ser aplicada a cada Caso de Uso en
forma separada. De esta forma, es posible estimar el esfuerzo para un CU en particular y
119

no para el sistema completo. Esto permite una mejor evaluacin del tamao del Caso de
Uso, ya que el CU puede ser mucho ms complejo que otro, dependiendo de la forma en
que el sistema es dividido. (Braz & Vergilio, 2006). En oposicin, cuando se usa el
mtodo descrito en la Seccin 3.5 un CU puede ser a lo ms 3 veces ms complejo que
otro.
Esta mtrica mide las funcionalidades considerando el nmero y peso de: Escenarios,
Actores, Precondiciones, Postcondiciones. Para poder determinar los PTCU, las
secciones de un Caso de Uso son analizadas y sus elementos deben ser clasificados. Los
PTCU del sistema completo se obtienen mediante la suma de los PTCU para cada Caso
de Uso. Para poder realizar este proceso, se deben seguir las siguientes etapas:
1. Clasificacin de Actores: cada actor tiene su complejidad (CA) determinada de
acuerdo a los datos entregados o recibidos del CU que est siendo analizado (Tabla
3.32). La complejidad total de los actores en el caso de uso (CTA) se calcula
mediante la Ecuacin 3.19.
=
=
n
1 i
i
CTA CTA (3.19)
Donde n corresponde al nmero de actores.
Tabla 3.32: Clasificacin de Actores en PTCU
Complejidad Datos PTCUSA
Simple 5 2
Media 6 a 10 4
Compleja > 10 6

2. Clasificacin de Precondiciones: cada precondicin del caso de uso tiene su propia
complejidad (CPrec) determinada de acuerdo al nmero de expresiones lgicas
120

puestas a pruebas por la condicin (Tabla 3.33). La complejidad total de todas las
precondiciones (CTPrec) se obtiene mediante la Ecuacin 3.20.
=
=
n
1 i
i
ec Pr C ec Pr CT
Donde n corresponde al nmero de precondiciones.
Tabla 3.33: Clasificacin de Precondiciones en PTCU
Complejidad Expresiones Testeadas PTCUSA
Simple 1 expresin lgica 1
Media 2 3 expresiones lgicas 2
Compleja > 3 expresiones lgicas 3

3. Clasificacin de los Escenarios: tanto el escenario principal como los escenarios
alternativos se clasifican de una forma similar. Para realizar la clasificacin, se utiliza
como parmetro el nmero de Entidades y el nmero de Pasos elementales necesarios
para que el escenario concluya. La complejidad de los escenarios (CEs) est dada por
la suma de ambos valores (Tabla 3.34). La complejidad total de los escenarios
(CTEs) se obtiene mediante la Ecuacin 3.21

=
=
n
1 i
i
CEs CTEs (3.21)
Donde n corresponde al nmero de escenarios.
Tabla 3.34: Clasificacin de los Escenarios en PTCU
Complejidad Entidades + Pasos PTCUSA
Muy Simple 5 4
Simple 6 a 10 6
Media 11 a 15 8
(3.20)
121

Complejidad Entidades + Pasos PTCUSA
Compleja 16 a 20 12
Muy Compleja > 20 16

4. Clasificacin de las Excepciones: cada excepcin presente en determinado caso de
uso puede ser analizada de acuerdo a su complejidad (CExc), la cual est
determinada por el nmero de expresiones lgicas testeadas para detectar la
ocurrencia de dicha excepcin. La complejidad total de las excepciones (CTExc) se
obtiene mediante la Ecuacin 3.22. La Tabla 3.35 muestra la clasificacin de las
Excepciones.
=
=
n
1 i
i
CExc CTExc (3.22)
Donde n corresponde al nmero de excepciones.
Tabla 3.35: Clasificacin de Excepciones en PTCU
Complejidad Expresiones Testeadas PTCUSA
Simple 1 expresin lgica 1
Media 2 3 expresiones lgicas 2
Compleja > 3 expresiones lgicas 3

5. Clasificacin de las Postcondiciones: la complejidad de las postcondiciones (CPost)
se determina mediante el nmero de entidades relacionadas. El detalle de aquello se
puede apreciar en la Tabla 3.36. La complejidad total de postcondiciones (CTPost)
se obtiene mediante la Ecuacin 3.23.
=
=
n
1 i
i
CPost CTPost (3.23)
Donde n corresponde al nmero de postcondiciones.
122

Tabla 3.36: Clasificacin de Postcondiciones en PTCU
Complejidad Entidades PTCUSA
Simple 3 1
Media 4 a 6 2
Compleja > 6 3

6. Clculo de los Puntos de Tamao de Casos de Uso sin Ajustar (PTCUSA): el valor
sin ajustar de los Puntos de Tamao de Casos de Uso se obtiene por la suma de los
valores de complejidad de todas las secciones del caso de uso, segn se seala en la
Ecuacin 3.24.
CTPost CTExc CTEs CTPrec CTA PTCUSA + + + + = (3.24)
7. Clculo de los Puntos de Tamao de Casos de Uso Ajustados: el mtodo de ajuste
para los PTCU se relaciona con el mtodo de Puntos de Funcin y el Mtodo de
Puntos de Casos de Uso. Se consideran Factores Tcnicos y Factores de Ambiente,
los cuales se muestran en las Tablas 3.37 y 3.38, respectivamente.

Tabla 3.37: Factores Tcnicos (Braz & Vergilio, 2006)
Factor Requerimiento Influencia
F1
Comunicacin de Datos I1
F2
Proceso Distribuido I2
F3
Rendimiento I3
F4
Configuracin Operacional Compartida I4
F5
Ratio de Transacciones I5
F6
Entrada Datos En Lnea I6
F7
Eficiencia del Usuario Final I7
F8
Actualizaciones En Lnea I8
F9
Complejidad Proceso Interno I9
F10
Reusabilidad del Cdigo I10
F11
Conversin e Instalacin I11
F12
Facilidad de Operacin I12
F13
Instalaciones Mltiples I13
F14
Facilidad de Cambios I14
123

- Factores de Ajuste Tcnico: representa la influencia que algunas caractersticas
tcnicas pueden tener sobre el software, las cuales son inherente a todos los casos
de uso del sistema. Cada factor de ajuste recibe un valor entre 0 y 5 de acuerdo al
grado de influencia sobre el caso de uso, donde 5 representa la mayor influencia.
la Ecuacin 3.25 permite el clculo de este factor.
) I 01 . 0 ( 65 . 0 FAT
14
1 i
i
=
- + = (3.25)
Factor Descripcin Influencia
A1 Existencia de un Proceso de Desarrollo Formal I1
A2 Experiencia con la Aplicacin que se est Desarrollando I2
A3 Experiencia del Equipo con las Tecnologas Utilizadas I3
A4 Presencia de un Analista Experimentado I4
A5 Estabilidad de los Requerimientos I5

- Factores de Ajuste de Ambiente: representan algunas caractersticas existentes en
el ambiente de desarrollo que pueden influir en el esfuerzo necesario para
construir el software. Cada uno de los factores descritos en la Tabla 3.38 recibe
valores entre 0 y 5 al igual que los Factores de Ajuste Tcnico. El clculo estos
se realizar mediante la Ecuacin 3.26.
) I 01 . 0 ( FAA
5
1 i
i
=
- = (3.26)
Para completar el clculo y por ende, ajustar los puntos de casos de uso, se utiliza la
Ecuacin 3.27.
) FAA FAT ( PTCUSA PTCU - = (3.27)

124

3.6.1.2 Puntos de Casos de Uso Difusos (PCUD)

La mtrica descrita anteriormente, aade nuevos elementos para medir las
funcionalidades de los CU. Sin embargo, tambin usa una clasificacin discreta de la
complejidad de las funcionalidades, de la misma forma que APF y PCU. El uso de tablas
de clasificacin no permite un cambio gradual desde una categora de complejidad a la
otra. Para permitir aquel cambio gradual, se utilizaran conceptos del Teora de Lgica
Difusa dando origen a la mtrica de Puntos Difusos de Casos de Uso (PDCU).
Primeramente, las funcionalidades de los CU recibirn una clasificacin continua.
Posteriormente, se deben aplicar los mtodos de Fusificacin y Defusificacin de los
trminos lingsticos.
1. Fusificacin de Trminos Lingsticos: las tablas de clasificacin son transformadas
en una clasificacin continua, este proceso se conoce como Fusificacin. Una
definicin ms precisa de este trmino se puede encontrar en (Klir & Folger, 1988).
Esto se puede realizar a travs de la generacin de nmeros difusos trapezoidales.
Luego, cada tabla de clasificacin para un CU (actores, precondiciones,
postcondiciones, excepciones y escenarios) se representa a travs de un grfico.
Para generar dicho grfico, que corresponde al nmero trapezoidal, se calculan las
siguientes variables, para cada categora en las tablas de clasificacin (1 i n,
donde n es el nmero de trminos lingsticos en la tabla de clasificacin que est
siendo analizada). En resumen:
- m
i
= valor ms bajo del trmino lingstico T
i
en la tabla de clasificacin.
-
2
) m m (
n
1 i i
i
+
+
=

-
1 i i
n a

=
-
1 i i
m b
+
=
La Tabla 3.39 muestra los valores para cada tabla de clasificacin de los PTCU.
125

Tabla 3.39: Valores para Fusificacin de los Trminos
Tabla m1 n1 a1 b1 m2 n2 a2 b2 m3 n3 a3 b3 m4 n4 a4 b4 m5 n5 a5 b5
1 1 3,5 6 6 8,5 3,5 11 11 8,5
2 1 1,5 2 2 3 1,5 4 4 3
3 1 3,5 6 6 8,5 3,5 11 11 13,5 8,5 16 16 18,5 13,5 21 21 18,5
4 1 1,5 2 2 3 1,5 4 4 3
5 1 2,5 4 4 5,5 2,5 7 7 5,5

Las Figuras 3-53, 3-54 y 3-55 muestran los grficos trapezoidales correspondientes a
cada una de las tablas de clasificacin para los PTCU.

Figura 3-53: Grficos trapezoidales para los Actores y Precondiciones
126

Figura 3-54: Grficos trapezoidales para los Escenarios y Excepciones

Figura 3-55: Grficos trapezoidales para las Postcondiciones

2. Defusificacin de los Trminos Lingsticos

El proceso de traducir los nmeros difusos en un solo valor real, es denominado
Defusificacin. Una definicin ms precisa de este trmino se puede encontrar en (Klir
& Folger, 1988). En este caso dicho proceso fue realizado dos reglas que se describen a
continuacin. Cada regla se aplica en una situacin particular, la primera se aplica
cuando el nmero obtenido pertenece solamente a un nmero difuso y la segunda se
127

aplica cuando el valor se encuentra entre dos nmeros difusos (en una regin de
transicin).
a) Si el nmero a ser clasificado (expresiones lgicas, entidades, entidades ms
pasos) est entre los valores de m
i
y n
i
del correspondiente nmero difuso, el
valor ser el mismo de la categora a la cual este nmero pertenece. Esto ocurre
porque este est en la parte superior de la base del nmero trapezoidal, por lo
tanto, el valor de la funcin de pertenencia es igual a 1, generando el mismo
valor que la mtrica PTCU produce.
b) Cuando el nmero a ser clasificado (expresiones lgicas, entidades, entidades
ms pasos) est entre los valores n
i
y b
i
del correspondiente nmero difuso, en
otras palabras, est localizado en un rango comn para dos nmeros difusos
(porque tambin est entre a
i+1
y m
i+1
). Por lo tanto, es necesario calcular el grado
de pertenencia que el nmero tiene con respecto a cada uno de los nmeros
difusos correspondientes. Para ello es necesario aplicar la Ecuacin 3.28.
1 i i
PTCU ). x ( PTCU ). x ( ) x ( dPCUD
+
+ = (3.28)
Donde dPCUD(x) corresponde al valor obtenido despus de la Defusificacin del
nmero x, PTCU
i
representa el valor de PTCU para la categora i y PTCU
i+1
es el valor
de PTCU para la categora i+1.

3.6.2 Diseo

Independiente de la mtrica utilizada, las entradas para este mtodo de puntos de casos
de uso, son las mismas. El clculo de una u otra mtrica se realiza en forma interna. La
forma en que se almacenan los datos, desde la perspectiva del diseo, es la que se
muestra en las Tablas 3.40 y 3.41. En resumen, corresponden a cada una de las partes
del caso de uso, acompaado del elemento que permite determinar su complejidad.
128

Tabla 3.40: Entradas para los Actores y Precondiciones
Cantidad de Actores Cantidad de Datos
Cantidad de
Precondiciones
Cantidad de
Expresiones
Testeadas1

Tabla 3.41: Entradas para Escenarios, Excepciones y Postcondiciones
Cantidad de
Escenarios
Cantidad de
Entidades+Pasos
Cantidad de
Excepciones
Cantidad de
Expresiones
Testeadas2
Cantidad de
Postcondiciones
Cantidad de
Entidades

El clculo de los PTCU se puede realizar en forma directa, con las entradas sealadas
anteriormente, no obstante, la versin difusa de estos, es decir, los PDCU, deben pasar
por un proceso de Fusificacin y Defusificacin. Para facilitar el clculo, se procedi a
construir las tablas respectivas calculando previamente los valores correspondientes a
cada parte de los casos de uso defusificadas. Aquello se puede apreciar desde la Tabla
3.42 a la 3.46.
Tabla 3.42: Valor defusificacin complejidad de Actores
Valor Tabla1 (Actores) Valor Defusificado
1 2
2 2
3 2
4 2,4
5 3,2
6 4
7 4
8 4
9 4,4
10 5,2
11 6

129

Tabla 3.43: Valor defusificacin complejidad de Precondiciones
Valor Tabla 2 (Precondiciones) Valor Defusificado
1 1
2 2
3 2
4 3

Tabla 3.44: Valor defusificacin complejidad de Escenarios
Valor Tabla 3 (Escenarios) Valor Defusificado
1 4
2 4
3 4
4 4,4
5 5,2
6 6
7 6
8 6
9 6,4
10 7,2
11 8
12 8
13 8
14 8,8
15 10,4
16 12
17 12
18 12
19 12,8
20 14,4
21 16

Tabla 3.45: Valor defusificacin complejidad de Excepciones
Valor Tabla 4 (Excepciones) Valor Defusificado
1 1
2 2
3 2
4 3
130

Tabla 3.46: Valor defusificacin complejidad de Postcondiciones
Valor Tabla 5 (Postcondiciones) Valor Defusificado
1 1
2 1
3 1,333
4 2
5 2
6 2,333
7 3

Otro elemento a considerar en la fase de diseo, es la forma en que se almacenarn los
datos de los factores tcnicos y de ambiente, esto se puede apreciar en la Tabla 3.47 y
3.48, respectivamente. En la parte inferior de cada tabla sirve para realizar los clculos
para cada factor.
Tabla 3.47: Factores Tcnicos
FACTOR INFLUENCIA

F2: Proceso Distribuido

F3: Rendimiento

F4: Configuracin Operacional
Compartida
F5: Ratio de Transacciones

F6: Entrada Datos En Lnea


F8: Actualizaciones En Lnea

F9: Complejidad Proceso Interno


F11: Conversin e Instalacin




ii = 0
FCT =

131

FACTOR
INFLUENCIA
A1: Existencia de un Proceso de
Desarrollo Formal
A2: Experiencia con la Aplicacin
que se est Desarrollando
A3: Experiencia del Equipo con
las Tecnologas Utilizadas
A4: Presencia de un Analista
Experimentado
A5: Estabilidad de los
Requerimientos
ii =

FA =

3.6.3 Implementacin
De una forma similar a la implementacin de los mtodos anteriores, en este caso se
realiza en base a formularios. Se solicitan las entradas correspondientes para cada uno de
las partes del caso de uso: Actores, Precondiciones, Escenarios, Postcondiciones y
Excepciones. En la Figura 3-56, se aprecia el ingreso de los Actores.

Figura 3-56: Entradas para los Actores
132

Una vez incorporado los datos de los actores se puede escoger entre ingresar los datos de
otro tipo de actores o por el contrario, pasar al ingreso de las precondiciones. Aquello se
puede visualizar en la Figura 3-57.

Figura 3-57: Decisin entre ingreso de otro Actor o una Precondicin

Este proceso se repite sistemticamente con las dems partes del caso de uso. Una vez
incorporados los datos de todos los elementos que conforman el caso de uso, se procede
al clculo de los Puntos de Casos de Uso Sin Ajustar. Aquello se puede apreciar en la
Figura 3-58.

Figura 3-58: Eleccin entre el ingreso de otra Postcondicin o el clculo de PCUSA
133

Luego se debe escoger el mtodo con el que se desea ajustar los puntos de casos de uso.
Puede ser el mtodo difuso PDCU o el mtodo no difuso PTCU, lo cual se puede
apreciar en la Figura: 3-59.

Figura 3-59: Eleccin del mtodo de clculo de los Puntos de Casos de Uso Sin Ajustar

Figura 3-60: Ingreso de los Factores de Complejidad Tcnica
134

Una vez calculados los puntos de casos de uso sin ajustar, ya sea a travs del mtodo
difuso o no difuso, estos deben ser ajustados. Para ello, como se ha indicado
anteriormente, se incorporan factores tcnicos y factores de ambiente. En la Figura 3-60,
se aprecia el ingreso de los primeros y en la Figura 3-61 se aprecia el ingreso de los
segundos.

Figura 3-61: Ingreso de los Factores de Ambiente

Una vez incorporados todos los datos necesarios, el clculo de los Puntos de Casos de
Uso Ajustados PCUA, se realiza en forma interna y se muestran mediante la pantalla
correspondiente. Aquello se visualiza en la Figura 3-62.
Realizado el ajuste correspondiente, se debe ingresar el factor de conversin de Puntos
de casos de uso a horas-hombre y las horas efectivas de trabajo mensuales. Para poder
obtener los resultados de la estimacin tanto en horas como en meses-hombre. Esto se
puede apreciar en la Figura 3-63.
135

Figura 3-62: Valor de los Puntos de Casos de Uso Ajustados

Figura 3-63: Ingreso del Factor de Conversin y las Horas efectivas de trabajo mensual

Finalmente, en la pantalla siguiente se puede elegir entre calcular el esfuerzo en horas o
en meses-hombre. Esto se visualiza en la Figura 3-64. Cabe destacar, que este
corresponde solamente al esfuerzo asociado a la etapa de programacin, para poder
conocer el esfuerzo total del proyecto, se debe ingresar el porcentaje de tiempo que se
136

utilizar para completar cada una de las etapas: Anlisis, Diseo, Programacin, Pruebas
y Sobrecarga (u otras actividades). Esto queda representado en la Figura 3-65.

Figura 3-64: Clculo del esfuerzo en Horas o Meses-Hombre.

Figura 3-65: Asignacin de porcentaje de esfuerzo por actividad.
137

Una vez incorporados los porcentajes correspondientes, se puede conocer el resultado de
la estimacin, para cada una de las actividades del proyecto. El resultado se muestra
tanto en horas como en meses-hombre. Adems, el usuario puede escoger entre guardar
los datos en un archivo en formato .xls o xlsx (entre otros), estimar otro proyecto o salir
de la aplicacin. Aquello se puede visualizar en la Figura 3-66.

Figura 3-66: Resultado final de la estimacin.

3.7 Conclusin

Una vez descritos cada uno de los mtodos implementados, cabe destacar que el foco de
este trabajo de investigacin es principalmente el anlisis, ms all de la implementacin
misma.

Durante el desarrollo, fue posible asimilar una importante cantidad de mtodos de
estimacin, de los cuales slo se tena un vago conocimiento previo antes de comenzar
el trabajo de titulacin. Para construir estos, se conjugaron conceptos tales como: Casos
138

de Uso, Lgica Difusa y Puntos de Funcin, entre otros, lo cual constituye un
reforzamiento positivo de disciplinas y tcnicas aprendidas a lo largo de la formacin
acadmica. Esto, con el objetivo de generar un producto tangible, para el uso propio o de
otros estudiantes del Departamento de Ingeniera Civil Informtica.

Otro objetivo fue generar una base que le permita por ejemplo, a otros memoristas,
depurar a travs del tiempo, uno o ms de los mtodos implementados, adems de
incorporar otros, en futuros trabajos de titulacin.

Se busc abarcar una considerable cantidad de mtodos, que le permita al usuario tener
una amplia gama de posibilidades para utilizar, de acuerdo a las caractersticas del
proyecto que tenga que estimar. Esto, debido a que en general, existe un
desconocimiento de los mtodos de estimacin de proyectos, lo cual es crucial para
realizar una planificacin adecuada que asegure el xito del proyecto o que simplemente
permita determinar a priori, si es viable desarrollarlo, frente a plazos restringidos.

Tabla 3.49: xito y Fracaso en Proyectos Informticos (Domnguez, 2009), (Schwaber
& Sutherland, 2012)
1994 1996 1998 2000 2002 2004 2006 2009 2012
Exitoso
16% 27% 26% 28% 34% 29% 35% 32% 37%
Deficiente
53% 33% 46% 49% 51% 53% 46% 44% 42%
Fracasado
31% 40% 28% 23% 15% 18% 19% 24% 21%

De acuerdo a la investigacin realizada, no es posible indicar, por ejemplo, el porcentaje
exacto de profesionales que desconocen o no utilizan mtodos formales de estimacin de
proyectos. No obstante, en la Tabla 3.49 se puede apreciar cmo desde 1994 hasta el
2012, an cuando existe una mejora en el porcentaje de proyectos exitosos, la
139

proporcin de proyectos deficientes y fracasados, se mantiene alta (Domnguez, 2009),
(Schwaber & Sutherland, 2012).

Como se explic en la Seccin 1.1, la gestin constituye uno de los factores ms
relevantes al momento de determinar el xito o el fracaso de un proyecto y dentro de
sta, la planificacin juega un rol trascendental, la cual se basa, necesariamente, en una
buena estimacin del esfuerzo requerido para realizar un determinado proyecto (Varas,
1995).

Por lo tanto, se puede concluir indirectamente, que al menos hasta el ao 2012, las
tcnicas de estimacin no se utilizan en forma correcta, lo cual se traduce en un bajo
porcentaje de proyectos finalizados en forma completamente exitosa.

140

CAPTULO 4. RESULTADOS

4.1 INTRODUCCIN

En el presente captulo se analizarn cuatro proyectos desarrollados en la asignatura de
Proyectos de Ingeniera de Software. El objetivo fundamental, es determinar cul es el
grado de precisin de cada uno de los mtodos implementados, adems de proponer
ciertos cambios a algunos parmetros, es decir, realizar un proceso de calibracin que
permita incrementar la exactitud de dichas tcnicas. Cabe destacar, que aplicar cada uno
de los mtodos implementados, en una etapa posterior a la realizacin de los proyectos,
tiene ciertas desventajas. Por ejemplo, la imposibilidad de tener contacto directo con los
integrantes de los equipos desarrolladores, implica que no se puede tener certeza del
nivel de experiencia de cada uno de ellos, en un determinado lenguaje de programacin,
lo cual se podra reflejar en cambios en los niveles de productividad. Adems, no se
tiene una visin precisa del entorno o ambiente de desarrollo, lo cual tambin puede
afectar la estimacin.

Considerando lo anterior, en cada uno de los puntos sobre los cuales se tuvo alguna
duda, se consideraron valores nominales para completar por ejemplo las tablas de
Complejidad Tcnica y de Ambiente, de tal forma de no afectar en demasa el resultado
de la estimacin.

4.2 RESULTADOS DE LOS PROYECTOS ANALIZADOS

En esta seccin se explicarn los resultados obtenidos en los cuatro proyectos
analizados, correspondientes a la asignatura de PINGESO.
141
CAPTULO 4: RESULTADOS

4.2.1 Resultados Proyecto de Denuncias Web

Este proyecto en particular, fue desarrollado en el segundo semestre del ao 2011. A
continuacin se presenta el enunciado del problema para que se tenga una idea general
de las caractersticas del mismo. En general, se omitirn los detalles de cada uno de los
proyectos, por motivos de sntesis.
4.2.1.1 Enunciado del Problema

Debido a la deficiente informacin que es entregada a travs de las denuncias online de
la Ilustre Municipalidad de Pealoln, se requiere desarrollar un sistema que permita
ingresar denuncias annimas de forma interactiva, validable, cabal y sencilla, de modo
que la informacin entregada pueda generar una causa con datos suficientes para obtener
resultados legales.
En cuanto a los problemas de seguimiento de las denuncias, se necesita establecer
estados para las denuncias, as como tambin la posibilidad de aportar informacin a
medida que avanzan de un estado a otro. Adems, los problemas de generacin de
informes y encaminamiento de las denuncias a la fiscala, tambin deben ser abordados
de tal manera que los procesos puedan ser optimizados y digitalizados.
En el mbito estadstico, los problemas de ubicacin y disposicin de la informacin
(actualmente todo se encuentra en correos electrnicos) deben ser solucionados para
poder generar datos estadsticos de forma sencilla y rpida.
Bajo estas directrices el cliente espera conseguir que el sistema de denuncias sea ms
eficiente en el ingreso de stas, con el propsito de mejorar los procesos actuales e
incrementar la calidad del servicio ofrecido por la municipalidad (Saenz, Gonzalez &
Flores, 2011).
142

Otro dato importante es que el sistema fue desarrollo con el lenguaje PHP y el motor de
Base de Datos MySql.
Una vez descrito el problema en forma global, se muestran los resultados
correspondientes al Mtodo de Puntos de Casos de Uso Versin 1.
4.2.1.2 Mtodo de Puntos de Casos de Uso 1

- Entradas: las entradas obtenidas al aplicar ste mtodo estn representadas en la
Tabla 4.1
Tabla 4.1: Entradas Mtodo de Casos de Uso 1
Cantidad_Actores Tipo_Actor Cantidad_CU Tipo_CU
3 3 3 10

2 5

- Resultados Puntos de Casos de Uso sin Ajustar: El resultado en este caso es de 49
PCUSA

- Factores de Complejidad Tcnica y de Ambiente: en las Tablas 4.2 y 4.3 se pueden
visualizar los Factores de Complejidad Tcnica y los Factores de Ambiente,
respectivamente.
T1: Sistema Distribuido 0 2 0
T2: Performance 3 1 3
T3: Eficiencia del Usuario Final 3 1 3
T4: Complejidad del Procesamiento Interno 2 1 2
T5: Reusabilidad del Cdigo 1 1 1
T6: Facilidad de Instalacin 2 0,5 1
T7: Facilidad de Uso 3 0,5 1,5
T8: Portabilidad 1 2 2
T9: Facilidad de Cambio 2 1 2
143

T10: Concurrencia 0 1 0
T11: Objetivos Especiales de Seguridad 3 1 3
T12: Acceso Directo a terceros 2 1 2
T13: Entrenamiento de Usuarios 2 1 2
pesoi*ValorAsignadoi 22,5
FCT =
0,825

E1: Familiaridad con el Modelo de Proyecto 3 1,5 4,5
E2: Experiencia en la Aplicacin 3 0,5 1,5
E3: Experiencia en O.O. 3 1 3
E4: Capacidad del Analista Lder 2 0,5 1
E5: Motivacin 3 1 3
E6: Estabilidad de los Requerimientos 3 2 6
E7: Personal Part-time 0 -1 0
E8: Dificultad del L.P. 3 -1 -3
Total 16
FA =
0,92

- Puntos de Casos de Uso Ajustados: una vez aplicados los factores anteriores, dio
como resultado 37,191 Puntos de Casos de Uso Ajustados

- Porcentaje por Actividad: en la Tabla 4.4 se puede apreciar el porcentaje por
actividad considerado en la estimacin. Debido a que el resultado de esfuerzo
obtenido, solamente representa aquel relacionado con el esfuerzo de desarrollo, ste
se utiliza como base para calcular el esfuerzo asociado a las dems etapas del
proyecto, y por ende, el total.

144

Tabla 4.4: Porcentaje por Actividad
Porcentaje por Actividad
Anlisis 15,0%
Diseo 15,0%
Programacin 45,0%
Pruebas 15,0%
Sobrecarga 10,0%
Total 100,0%

- Resultados por Actividad en Horas - Hombre: se considera un Factor de Conversin
de 4,5 Horas por Punto de Casos de Uso, esto se puede apreciar en la Tabla 4.5.
Tabla 4.5: Esfuerzo por Actividad en Horas Hombre
Esfuerzo por Actividad en Horas-Hombre
Actividad Horas-Hombre

Anlisis 55,787

Diseo 55,787

Programacin 167,360

Pruebas 55,787

Sobrecarga 37,191

Total 371,910

- Resultados por Actividad en Meses-Hombre: se consideran 60 horas efectivas de
trabajo mensual. Aquello se muestra en la Tabla 4.6
Tabla 4.6: Esfuerzo por Actividad en Meses-Hombre
Esfuerzo por Actividad en Meses-Hombre
Actividad Meses-Hombre

Anlisis 0,930

Diseo 0,930

Programacin 2,789

Pruebas 0,930

Sobrecarga 0,620

Total 6,199

145


- Entradas: las entradas correspondientes al Mtodo de Puntos de Casos de Uso 2, se
muestran en la Tabla 4.7.
Tabla 4.7: Entradas Mtodo de Puntos de Casos de Uso 2
Cantidad de
Precondiciones
Cantidad de
Expresiones Testeadas1
3 3 1 1

1 2

1 2

1 2

1 1
Cantidad de
Escenarios
Cantidad de
Entidades+Pasos
Cantidad de
Excepciones
Cantidad de
Expresiones
Testeadas2
Cantidad de
Postcondiciones
Cantidad de
Entidades
1 9 1 2 1 1
1 2 1 1 1 1
1 5 1 1 1 1
1 3 2 1 1 2
1 4 2 1 1 2

- Puntos de Casos de Uso sin Ajustar: los resultados correspondientes a los Puntos de
Casos de Uso sin Ajustar se pueden apreciar en la Tabla 4.8

Tabla 4.8: Resultados PCUSA
PUNTOS DE CASOS DE USO SIN AJUSTAR
49
PUNTOS DIFUSOS DE CASOS DE USO SIN AJUSTAR
51

- Factores de Complejidad Tcnica y de Ambiente: en las Tablas 4.9 y 4.10
respectivamente, se pueden apreciar los Factores de Complejidad Tcnica y de
Ambiente asociados al Mtodo de Casos de Uso 2. En este caso, como se explic en
el Captulo 3, existe una variacin con respecto al mtodo anterior, considerndose
146

14 Factores de Complejidad Tcnica y 5 Factores de Ambiente, a diferencia de los
13 y 8 que se utilizan respectivamente en el primer mtodo.

FACTOR INFLUENCIA
2
0
F3: Rendimiento
3
Compartida 2
2
2
2
2
2
1
2
2
1
2
ii = 25
FCT =
0,9

FACTOR
INFLUENCIA
Desarrollo Formal 3
que se est Desarrollando 2
las Tecnologas Utilizadas 2
Experimentado 2
Requerimientos 3
147

FACTOR
INFLUENCIA
ii = 12
FA =
0,12

- Puntos de Casos de Uso Ajustados: una vez aplicados los factores de ajuste
anteriores se pueden visualizar los resultados en la Tabla 4.11

Tabla 4.11: Resultados Puntos de Casos de Uso Ajustados
Puntos de Casos de Uso
Ajustados 38,22
Puntos de Casos de Uso
Difusos Ajustados 39,78

- Resultados Mtodo No Difuso: finalmente en las Tablas 4.12 y 4.13 se pueden
apreciar los resultados de ste mtodo tanto en horas como en meses hombre.

Tabla 4.12: Esfuerzo por Actividad en Horas - Hombre

Anlisis 57,330

Diseo 57,330

Programacin 171,990

Pruebas 57,330

Sobrecarga 38,220

Total 382,200


Anlisis 0,956

Diseo 0,956

Programacin 2,867

148


Pruebas 0,956

Sobrecarga 0,637

Total 6,370

- Resultados Mtodo Difuso: el resultado correspondiente al Mtodo Difuso se
aprecia en las Tablas 4.14 y 4.15
Tabla 4.14: Esfuerzo por Actividad en Horas-Hombre

Anlisis 59,670

Diseo 59,670

Programacin 179,010

Pruebas 59,670

Sobrecarga 39,780

Total 397,800


Anlisis 0,995

Diseo 0,995

Programacin 2,984

Pruebas 0,995

Sobrecarga 0,663

Total 6,630

149

4.2.1.4 Mtodo de Puntos de Funcin

Debido a que la combinatoria entre los distintos Mtodos de Puntos de Funcin y los
diversos Mtodos de Ajuste da como resultado 24 resultados posibles, el detalle de cada
proceso se incluir en el Apndice C. Por lo tanto, en esta seccin solamente se mostrar
el resultado final de cada Mtodo.

A. Caso Ingreso Directo del tipo de Complejidad
En la Tabla 4.16 se muestra el resumen de los resultados obtenidos al evaluar el
Proyecto de Denuncias Web sistemticamente bajo los mtodos de puntos de funcin
donde el valor de complejidad de ingresa en forma directa, y por tanto, de manera
subjetiva.
Tabla 4.16: Resultados Caso Ingreso Directo de Complejidades
Mtodo Ajuste Total en Horas
PF 1 Tradicional 361,867
Modificado 334,333
COCOMO II 352,187
Modificado 334,333
COCOMO II 352,187
Modificado 312,375
COCOMO II 287,299

150

B. Caso Ingreso Indirecto del tipo de Complejidad
Debido a que slo en este caso, existen 15 tipos de resultados posibles, se omitir el
detalle por actividad. Por ende, en esta seccin solamente se mostrar una tabla resumen
con los resultados totales de cada mtodo y tipo de ajuste. Aquello se puede apreciar en
la Tabla 4.17.

Tabla 4.17: Resultados Ingreso Indirecto de Complejidades
Modificado 334,333
COCOMO II 352,187
Modificado 334,333
COCOMO II 352,187
Modificado 312,375
COCOMO II 287,299
PF Difuso 1 Tradicional 372,666
Modificado 344,311
COCOMO II 363,728
Modificado 278,697
COCOMO II 288,468

151

4.2.2 Resultados Proyecto Sistema de Administracin de Informes

Este proyecto fue desarrollado en el primer semestre del ao 2010. A continuacin se
presenta el enunciado del problema, para que se tenga una idea global de las
particularidades del mismo.


Se solicita la creacin de un sistema que permita al Departamento Social de la
Municipalidad de Pumanque la administracin de informes. El sistema debe disponer de
daros centralizados de manera que todos los usuarios del sistema puedan acceder a todos
los informes. El sistema debe permitir la rpida administracin de informes por persona,
grupo familiar, por tipo de informe y por fecha. Adems, el sistema debe permitir la
creacin de informes tipo con sus respectivas secciones, y la opcin de crear un nuevo
tipo de informe. El sistema debe permitir el manejo de usuarios para saber quien emiti
que informe. Se estudia tambin la posibilidad de generar estadsticas y grficos (Garca,
Gatica & Maldonado, 2010).
Este proyecto tambin fue desarrollado con el lenguaje PHP y el motor de Base de Datos
MySql.
Una vez descrito en forma general el proyecto en cuestin, se procede a detallar los
resultados del Mtodo de Puntos de Casos de Uso 1.


Tabla 4.18
152

Tabla 4.18: Entradas Mtodo Casos de Uso 1
3 3 3 10

1 5

PCUSA

- Factores de Complejidad Tcnica y de Ambiente: estos factores se pueden apreciar en
las Tablas 4.19 y 4.20, respectivamente.
T1: Sistema Distribuido 0 2 0
pesoi*ValorAsignadoi 23,5
FCT =
0,835

153

E1: Familiaridad con el Modelo de Proyecto 2 1,5 3
E4: Capacidad del Analista Lder 3 0,5 1,5
E5: Motivacin 4 1 4
Total 17
FA =
0,89

Procesados los datos anteriores e ingresados los porcentajes por actividad de acuerdo a
la Tabla 4.21, se pueden apreciar los resultados finales de este mtodo, tanto en horas
como en meses hombre en la Tabla 4.22. Adems, cabe destacar que en este caso se
consider un factor de conversin de 5 horas por Punto de Caso de Uso, con la idea de
calibrar de una mejor forma el mtodo.
Anlisis 15,0%
Diseo 15,0%
Programacin 45,0%
Pruebas 15,0%
Sobrecarga 10,0%
Total 100,0%

154

Tabla 4.22: Resultado en Horas y Meses - Hombre

Anlisis 54,498

Diseo 54,498

Programacin 163,493

Pruebas 54,498

Sobrecarga 36,332

Total 363,318


Anlisis 0,908

Diseo 0,908

Programacin 2,725

Pruebas 0,908

Sobrecarga 0,606

Total 6,055


- Entradas: se pueden visualizar en la Tabla 4.23
Tabla 4.23: Entradas Mtodo PCU 2
Cantidad de
Precondiciones
Cantidad de
3 3 1 2

1 2

1 1

1 1
Cantidad de
Escenarios
Cantidad de
Entidades+Pasos
Cantidad de
Excepciones
Cantidad de
Expresiones
Testeadas2
Cantidad de
Postcondiciones
Cantidad de
Entidades
1 5 1 1 1 1
1 2 1 1 1 1
1 4 2 1 1 2
1 4 2 1 1 2
155

El resultado de los Puntos de Casos de Uso sin Ajustar se puede ver en la Tabla 4.24

38
40

Los Factores de Complejidad Tcnica y de Ambiente, para este mtodo, se puede ver en

FACTOR INFLUENCIA
3
0
F3: Rendimiento
3
Compartida 2
2
3
2
2
2
1
1
3
0
2
ii = 26
FCT =
0,91

156

FACTOR
INFLUENCIA
Desarrollo Formal 3
Experimentado 2
Requerimientos 3
ii = 14
FA =
0,14

Utilizando las tablas anteriores, se realiza el clculo de los PCU Ajustados, cuyo
resultado se aprecia en la Tabla 4.27.
Tabla 4.27: Resultado PCU Ajustados
PCUA = 29,26
PCUA (Difusos) = 30,8

Finalmente, los resultados en horas hombre, para cada uno de los mtodos anteriores
se pueden ver en la Tabla 4.28.
Tabla 4.28: Resultado Final en Horas - Hombre
Total No Difuso 325,111
Total Difuso 342,222

157


Debido a que la combinatoria entre los distintos Mtodos de Puntos de Funcin y los
diversos Mtodos de Ajuste da como resultado 24 resultados posibles, se omitir el
detalle de cada proceso. Por lo tanto, en esta seccin solamente se mostrar el resultado
final de cada Mtodo. Adems, no se mostrarn los resultados asociados al caso de
ingreso de complejidades en forma directa, debido a que los proyectos que se analizaron,
ya finalizaron y por ende, se utiliz el mtodo indirecto el cual es ms exacto y objetivo.
De tal forma, la combinatoria se reduce a 15 resultados posibles los cuales se muestran
en la Tabla 4.29
Modificado 533,200
COCOMO II 580,064
Modificado 533,200
COCOMO II 580,064
Modificado 464,400
COCOMO II 498,526
Modificado 533,200
COCOMO II 580,064
Modificado 483,511
COCOMO II 521,065

158

4.2.3 Resultados Proyecto Sistema de Control de Recursos

Este proyecto fue desarrollado en el primer semestre del ao 2010. A continuacin se
presenta el enunciado del problema para que se tenga una idea general de las
caractersticas del mismo.


La municipalidad de Pumanque, en pos de una mejora en los actuales procesos internos
que realiza, ha decidido aceptar el desarrollo de propuestas por parte de los alumnos del
curso de proyecto de Ingeniera de Software para el desarrollo de herramientas TICs,
para el apoyo de sus procesos.
Uno de los temas importantes para la municipalidad es el control del inventario del
departamento de educacin.
Actualmente se identifican los siguientes problemas generales:
- El proceso es realizado en papel, lo que desaprovecha las actuales herramientas
computacionales para el manejo de datos.
- El actual proceso no es tolerante a fallos, por lo que las validaciones deben ser
hechas durante la revisin de los papeles.
- No es posible llevar un control ordenado sobre las peticiones ya atendidas y
despachos exitosos.
Como problemas especficos se detallan:

- El material que se pide a la municipalidad est enmarcado por planes del
MINEDUC, como es el caso de la Ley SEP, por lo que se necesita acceder a
159

estos datos fcilmente (Ej. Obtener un informe de los materiales pedidos por una
escuela en particular bajo la ley SEP).
- Por cada programa existe un tope anual de presupuesto, por lo que por cada
nuevo requerimiento deben consultar las cuentas anteriores y comprobar que no
se ha excedido del lmite.
- Se necesitan generar dos tipos de documentos: un memorndum, el cual es
generado en el DAEM con el detalle del pedido y una gua de despacho (2
copias) con los insumos a despachar.
Por lo tanto, es necesario crear un sistema computacional para manejar el inventario que
permita subsanar las actuales falencias descritas anteriormente (Acosta, Liberona &
Naranjo, 2010).
Este proyecto fue desarrollado con el framework Microsoft .Net y el motor de base de
datos SQL Server 2008.
Una vez descrito el problema, se exponen los resultados del primer mtodo de
estimacin aplicado.

Tabla 4.30
3 3 3 10

5 5

PCUSA

160

T1: Sistema Distribuido
0
2 0
pesoi*ValorAsignadoi

22
FCT =
0,82
3
1,5 3
E5: Motivacin 5 1 4
Total 18,5
FA =
0,845

161

como en meses hombre en la Tabla 4.34. Adems cabe destacar, que en este caso se
consider un factor de conversin de 3,5 horas por Punto de Caso de Uso, con la idea de
Anlisis
15,0%
Diseo 20,0%
Programacin 45,0%
Pruebas 10,0%
Sobrecarga 10,0%
Total 100,0%


Anlisis
51,737

Diseo 68,982

Programacin 155,210

Pruebas 34,491

Sobrecarga 34,491

Total 344,910


Anlisis
0,304

Diseo
0,406

Programacin
0,913

Pruebas
0,203

Sobrecarga
0,203

Total
2,029

162


Las entradas correspondientes a este mtodo, se pueden visualizar en la Tabla 4.35
Cantidad de
Precondiciones
Cantidad de
3 5 8 1
Cantidad de
Escenarios
Cantidad de
Entidades+Pasos
Cantidad de
Excepciones
Cantidad de
Expresiones
Testeadas2
Cantidad de
Postcondiciones
Cantidad de
Entidades
1 9 1 2 1 3
1 8 7 1 3 2
1 7

4 1
5 5


69
79,3

FACTOR INFLUENCIA
F1: Comunicacin de Datos 2
F2: Proceso Distribuido 0
F3: Rendimiento 3
Compartida
2
F5: Ratio de Transacciones 2
F6: Entrada Datos En Lnea 2
163

FACTOR INFLUENCIA
F7: Eficiencia del Usuario Final 2
F8: Actualizaciones En Lnea 2
F9: Complejidad Proceso Interno 2
F10: Reusabilidad del Cdigo 2
F11: Conversin e Instalacin 2
F12: Facilidad de Operacin 2
F13: Instalaciones Mltiples 0
F14: Facilidad de Cambios 2
ii =
25
FCT =
0,9

FACTOR
INFLUENCIA
Desarrollo Formal 3
Experimentado 2
Requerimientos 3
ii = 14
FA =
0,14

PCUA =
52,44

164



Por las razones sealadas anteriormente, en esta seccin solamente se mostrar el
resultado final de cada Mtodo. Adems, no se mostrarn los resultados asociados al
caso de ingreso de complejidades en forma directa, debido a que los proyectos que se
analizaron, ya finalizaron y por ende, se utiliz el mtodo indirecto el cual es ms exacto
y objetivo. De tal forma, la combinatoria se reduce a 15 resultados posibles los cuales se
muestran en la Tabla 4.41
Modificado 320,933
COCOMO II 382,172
Modificado 320,933
COCOMO II 349,329
Modificado 254,533
COCOMO II 296,397
Modificado 322,409
165

COCOMO II 384,099
Modificado 265,641
COCOMO II 310,609

4.2.4 Resultados Proyecto Sistema de Difusin Cultural

Este proyecto fue desarrollado en el segundo semestre del ao 2011. A continuacin se
presenta el enunciado del problema para que se tenga una idea general de las
caractersticas del mismo.


La municipalidad de Pealoln trabaja da a da para lograr el progreso de la comuna, y
poder transformarse de esta forma en la mejor de Chile. Uno de los principales objetivos
que posee es convertirse en la primera Comuna Digital del pas. Para ello, la Municipalidad
ha gestionado una serie de reas, entre las cuales se encuentra el rea cultural.

La corporacin Cultural de Pealoln es una entidad jurdica de derecho privado sin fines de
lucro. Su objetivo es promover la cultura y los patrimonios en Pealoln, impulsando de esta
forma el desarrollo cultural de la comuna, y estimulando la participacin de la comunidad.

Para cumplir estos objetivos, la Municipalidad posee una pgina Web denominada:
http://cultura.penalolen.cl/, la cual provee una serie de informacin a la comunidad,
comunicando actividades, talleres, eventos realizados, entre otros. Esta pgina se cre con el
166

fin de convertirse en el centro de difusin cultural, capaz de llegar a toda la comunidad e
informar acerca de las actividades realizadas.

El problema que posea la Municipalidad de Pealoln, es que la difusin que ellos
esperaban, no se produjo con la intensidad deseada, por lo que la pgina web fue dejada de
lado. Alexis Zamorano se hizo cargo de la administracin de la pgina, y requiri generar
elementos de mejor calidad y de mayor funcionalidad, mejorando la difusin para llegar a
las personas que pertenecen a la comuna, y que no acceden a una serie de eventos por falta
de informacin. Alexis, por tanto, corresponde a la principal persona involucrada, ya que l
es el encargado de recibir la informacin y publicarla.

Luego de una serie de reuniones, se estableci en conjunto con Alexis Zamorano una serie
de deseos por parte del cliente:

- Se desea que exista una forma de difusin que unifique a las redes sociales, como
por ejemplo Facebook y Twitter, esto es para que en el momento de creacin de un
evento, ste pueda ser alcanzado por la mayora de las personas de la comuna

- Existe una especial preocupacin por las bsquedas de talleres (pagados y gratuitos)
a los que puede acceder la poblacin. Se necesita difundir esta informacin de la
mejor forma posible, indicando un listado de talleres, la forma de inscribirse a stos,
permitiendo la filtracin de datos segn diversas caractersticas, se requiere la
creacin de un registro de inscripciones, etc. Es importante mejorar el sistema
respecto a este tema, ya que faltan ayudas que permitan a los usuarios facilitar la
inscripcin a travs de formularios, facilitar sus bsquedas, entre otras.

- Se requiere una mejora entre la interaccin del usuario con respecto a la pgina de
difusin. Esto quiere decir que se deben crear elementos que permitan al usuario
llevar a cabos sus acciones de una forma ms sencilla.
167

- Se debe, incluso, relacionar los Sistemas de la unidad cultural con la difusin, esto
quiere decir, por ejemplo, que el avance de los proyectos se difunda a sus
interesados a travs de un mail informativo.

- Se requiere mayor dinamismo con el usuario.

- Se desea permitir tambin la generacin de reservaciones de asientos para eventos
efectuados en cines, teatros o en algn concierto.

- Se desea mejorar la interfaz de la pgina de cultura, con el fin de que los usuarios se
sientan ms interesados por ella (Valenzuela, Varas & Ziga, 2011).

Un factor importante a considerar, es que el proyecto anteriormente descrito, fue
desarrollado utilizando WordPress, un Sistema de Gestin de Contenido.
Los resultados correspondientes al primer mtodo aplicado, son los que se presentan a
continuacin.


- Las entradas obtenidas al aplicar ste mtodo estn representadas en la Tabla 4.42

2 3 2 10
2 5

168

PCUSA


T1: Sistema Distribuido
0
2 0
T6: Facilidad de Instalacin
2
0,5 1
pesoi*ValorAsignadoi 22
FCT =
0,82

3
1,5 3
169

E5: Motivacin 3 1 4
E8: Dificultad del L.P.
2
-1 -2
Total 17,5
FA =
0,875

como en meses hombre en la Tabla 4.46. Adems cabe destacar que en este caso se
consider un factor de conversin de 2 horas por Punto de Caso de Uso, con la idea de

Anlisis
20,0%
Diseo 15,0%
Programacin 45,0%
Pruebas 10,0%
Sobrecarga 10,0%
Total 100,0%


Anlisis
22,960

Diseo
17,220

Programacin
51,660

Pruebas
11,480

170


Sobrecarga
11,480

Total
114,800


Anlisis
0,383

Diseo
0,287

Programacin
0,861

Pruebas
0,191

Sobrecarga
0,191

Total
1,913


- Las entradas para este mtodo se pueden visualizar en la Tabla 4.47
Cantidad de
Precondiciones
Cantidad de
2 5 4 1
Cantidad de
Escenarios
Cantidad de
Entidades+Pasos
Cantidad de
Excepciones
Cantidad de
Expresiones
Testeadas2
Cantidad de
Postcondiciones
Cantidad de
Entidades
2 5 11 1 4 1
1 8

1 10


43
49

171


FACTOR INFLUENCIA
F1: Comunicacin de Datos 2
F2: Proceso Distribuido 0
F3: Rendimiento 2
Compartida
2
F5: Ratio de Transacciones 2
F6: Entrada Datos En Lnea 2
2
F8: Actualizaciones En Lnea 2
F9: Complejidad Proceso Interno 2
F10: Reusabilidad del Cdigo 2
F11: Conversin e Instalacin 2
F12: Facilidad de Operacin 2
F13: Instalaciones Mltiples 2
F14: Facilidad de Cambios 2
ii = 26
FCT =
0,91

FACTOR
INFLUENCIA
Desarrollo Formal
3
que se est Desarrollando
3
las Tecnologas Utilizadas
3
Experimentado
2
172

FACTOR
INFLUENCIA
Requerimientos
4
ii = 15
FA =
0,15

PCUA = 32,68



Como se coment previamente, en esta seccin solamente se mostrar el resultado final
de cada Mtodo. Adems, no se mostrarn los resultados asociados al caso de ingreso de
complejidades en forma directa, debido a que los proyectos que se analizaron, ya
finalizaron y por ende, se utiliz el mtodo indirecto el cual es ms exacto y objetivo. De
tal forma, la combinatoria se reduce a 15 resultados posibles los cuales se muestran en la
Tabla 4.53

173

Modificado 127,613
COCOMO II 118,147
Modificado 130,033
COCOMO II 137,233
Modificado 99,600
COCOMO II 102,445
Modificado 114,744
COCOMO II 119,644
Modificado 105,441
COCOMO II 109,050

4.3 CONCLUSIN

Primeramente, hay que considerar que en todos los proyectos analizados, una vez
implementados estos, se dej un registro del tiempo de desarrollo, en horas. Lo cual es
altamente valioso al momento de realizar el anlisis correspondiente y es un punto a
destacar en la asignatura de Proyectos de Ingeniera de Software. Cada uno de los
valores que se indican como tiempo real, fueron obtenidos directamente de los informes
finales, elaborados por los desarrolladores.
174

De acuerdo a lo anterior, y una vez evaluados los mismos, se puede concluir lo
siguiente:
- Con respecto al Primero (Denuncias Web): se tiene que el valor ms cercano al
tiempo real (336 horas), se obtiene mediante la estimacin realizada con los
Mtodos de Puntos de Funcin Tradicional y Tradicional Modificado, en ambos
casos considerando el Mtodo de Ajuste Modificado. El valor obtenido es de 334
horas, solamente 2 horas menos que el valor real. La razn de por qu se obtiene
el mismo valor aplicando mtodos distintos, corresponde a que el Mtodo de
Puntos de Funcin Modificado agrega granularidad al incorporar el trmino
lingsticos muy alto y como las complejidades obtenidas en los proyectos
evaluados, varan entre simple y media, dicha mejora no tiene ninguna
implicancia, mantenindose similar para los primeros tres niveles de
complejidad. sta, con un alto grado de seguridad, se puede indicar que ser la
tnica cada vez que se evale un proyecto pequeo (menos de 100 puntos de
funcin) (Systemation, 2009).
- Por otro lado, se puede sealar adems, que el Mtodo de Puntos de Funcin
Modificado 2 (el cual se abreviar como PF3) tiende a la subestimacin (300
horas aproximadamente), en este proyecto en particular. Cabe resaltar, que la
subestimacin en general, es altamente castigada al momento de realizar
estimaciones, debido a que subestimar un proyecto constituye un error fatal, que
puede provocar el fracaso en el desarrollo del proyecto, ya sea por tiempo y/o
dinero. El caso contrario ocurre con los Mtodos de Puntos de Casos de Uso,
donde se tiende a la sobrestimacin (385 horas aproximadamente). sta no
constituye una falta tan grave (dependiendo del grado de sobrestimacin), ya que
en el peor de los casos se puede perder una alternativa de negocio, pero
generalmente existirn otras alternativas, de tal forma que no se tendrn mayores
prdidas econmicas.

175

- Con respecto al Segundo Proyecto (Administracin de Informes), el resultado
ms cercano se obtiene con el Mtodo de Puntos de Funcin Tradicional y el
Ajuste Tradicional, donde se obtiene un resultado de 576 horas solamente 10
horas ms que el valor real (566 horas), lo cual corresponde a menos de un 2%
de diferencias. Nuevamente con el Mtodo de Puntos de Funcin Modificado se
obtienen los mismos resultados que con el tradicional y en el caso del Mtodo
PF3, de nuevo se tiende a la subestimacin, obteniendo resultados en torno a las
500 horas. Sin embargo (en este caso), todas las variantes de mtodos de Puntos
de Funcin, demuestran ser ms precisas que los mtodos de Puntos de Casos de
Uso los cuales arrojaron resultados cercanos a las 350 horas. Aquello se puede
explicar debido a que en estos, existe menos informacin que en el caso de los
PF, y por ende, disminuye el grado de precisin que se puede obtener. En otras
palabras, a medida que aumenta el grado de informacin que se tiene con
respecto a un sistema que se busca desarrollar, las estimaciones sern ms
precisas.

- En el caso del Sistema de Control de Recursos (SISCORE), se tiene que el
Mtodo de Puntos de Casos de Uso 1, dio como resultado 344 horas-hombre, un
valor cercano al real (327 horas-hombre). No obstante, el segundo mtodo de
puntos de casos de uso, en su versin difusa y no difusa arroj resultados
superiores, es decir que sobrevaloran en demasa el esfuerzo asociado a la
realizacin del proyecto. Especficamente, los resultados fueron 469 y 408 horas-
hombre, respectivamente. Con respecto a los Mtodos de Puntos de Funcin, se
tiene que los resultados ms cercanos, se obtienen con el Mtodo de Puntos de
Funcin Tradicional y Mtodo de Ajuste Modificado, el cual arroja 321 horas-
hombre. En el caso del Mtodo de Puntos de Funcin Difuso y Mtodo de Ajuste
Modificado el resultado es de 322 horas hombre. El inconveniente se produce
porque an cuando los resultados, en estos casos, son bastante cercanos,
constituyen una subestimacin del valor real, lo cual, por lo general, se castiga
176

bastante, debido a las implicancias econmicas que puede ocasionar el
subvalorar un proyecto (Marchewka, 2006). Finalmente, se puede agregar que el
Mtodo de Puntos de Funcin Modificado entreg resultados similares, los
cuales se pueden verificar en la Tabla 4.41. Por otro lado, los Mtodos: Puntos de
Funcin Modificado 2 y Puntos de Funcin Difusos 2, tuvieron una tendencia
clara hacia la subestimacin. El promedio de todos los mtodos es de 335,45
horas hombre, lo que representa un porcentaje de error de un 2.45% ms que el
valor real.

- Con respecto al Sistema de Difusin Cultural, se tiene que el Mtodo de Puntos
de Casos de Uso 1, dio como resultado un valor levemente superior, es decir, 114
horas-hombre versus las 107 horas-hombre reales. En el Mtodo de Puntos de
Casos de Uso 2, se tendi a la sobrestimacin. La misma tnica se repiti en el
Mtodo de Puntos de Funcin, con algunas excepciones como es el caso de PF3
(Puntos de Funcin Modificado 2) con ajuste tradicional donde el resultado
entregado fue el ms cercano de todos (108 horas-hombre). El promedio de todos
los Mtodos, es de 122,97 horas-hombre, lo que representa un error de un
14.93% ms que el valor real.
Entre los factores que pueden influir en la importante diferencia en el esfuerzo real entre
los proyectos analizados, se pueden nombrar los siguientes:
- Utilizacin de un Entorno de Desarrollo Integrado (EDI): puede influir el tipo
empleado o la no utilizacin del mismo. Por ejemplo: uso de Visual Studio
(Sistema de Control de Recursos) vs no utilizacin de EDI (Sistema de
Administracin de Informes. Corresponden al mismo semestre, y en el primer
caso, el esfuerzo fue de 327 horas vs 566 del grupo que no utiliz dicho tipo de
entorno de desarrollo.
- Tipo de FrameWork utilizado: Por ejemplo: Microsoft .NET (Sistema de Control
de Recursos) vs CakePHP (Sistema de Administracin de Informes).
177

- Lenguaje de Programacin: Uso de C# (Sistema de Control de Recursos) vs
PHP (Sistema de Administracin de Informes).
- Experiencia de los desarrolladores con respecto a las tecnologas utilizadas: si
bien este es un factor importante que considerar, este es uno de los datos que no
se conoce con exactitud, porque no se tuvo contacto directo con las alumnos que
realizaron llevaron a cabo los proyectos.
- Uso de Sistemas de Gestin de Contenido: en el caso del Sistema de Difusin
cultural, desarrollado con WordPress, se tiene el menor esfuerzo de los cuatro
proyectos analizados, lo cual es un indicio de que esta clase de herramientas
proveen de un alto nivel de productividad, cuando el enfoque del proyecto es el
contenido. No obstante, poseen ciertas limitantes y se debe ser cuidadoso al
momento de elegirlas. Cuando el sistema que se busca desarrollar no est
enfocado en el contenido, no se justifica su utilizacin, debido a que estn
concebidos en primera instancia para el desarrollo de sitios Web y no de
Sistemas en s.
- Coyuntura Institucional o Ambiente de Desarrollo: los proyectos efectuados el
segundo semestre del ao 2011, como es el caso del Sistema de Denuncias Web
y del Sistema de Difusin Cultural, tuvieron que enfrentarse a un Paro de
Actividades, lo cual pudo redundar en menores tiempos para el desarrollo de los
sistemas y, por ende, una eventual simplificacin en los requerimientos de los
mismos. Destaca el hecho, que la suma del tiempo de desarrollo de aquellos
proyectos realizados en un contexto de Paro de Actividades, corresponde
aproximadamente a un 50% del tiempo del esfuerzo de los proyectos
desarrollados en perodo de clases regulares.

En el prximo Captulo, se analizarn todas las implicancias del presente Trabajo de
Titulacin, determinando, por ejemplo, si los resultados obtenidos demuestran o refutan
lo dicho por los autores citados, en el estado del arte.
178

CAPTULO 5. CONCLUSIONES

El presente captulo, busca resaltar y detallar las principales conclusiones a las que se puede
llegar, luego de finalizado este trabajo de titulacin. Para ello, se divide en tres secciones. En
la primera, se describen aspectos generales correspondientes al trabajo. Posteriormente, se
seala el grado de cumplimiento de cada uno de los objetivos especficos. Y finalmente, se
plantean trabajos futuros.

5.1 ASPECTOS GENERALES

El problema de la estimacin del esfuerzo en Proyectos de Desarrollo de Software tiene
una larga data, donde se puede considerar como fecha inicial a la segunda mitad de la
dcada de los 60, en la cual se estableci el software como producto. Desde aquel
entonces y hoy ms que nunca, el software en general, resulta vital para automatizar los
procesos, en organizaciones de diversa ndole.

Como resultado de esta valorizacin, actualmente el desarrollo de software constituye
una industria pujante, bajo la cual se tranzan miles de millones de dlares al ao. No
obstante, un porcentaje importante de aquellos proyectos fracasa debido a una incorrecta
planificacin.

Si consideramos adems, que la planificacin de un proyecto se basa en una buena
estimacin del esfuerzo requerido para realizarlo; es fcil concluir que dicho proceso, es
vital al momento de llevar a cabo cualquier proyecto de desarrollo de software.

179
CAPTULO 5: CONCLUSIONES

Desafortunadamente, no existe un mtodo o herramienta infalible y 100% precisa para
estimar proyectos informticos. Es ah donde el trabajo de titulacin realizado, busca
contribuir en la medida de lo posible.
Por ende, se implementaron dos tipos de Mtodos de Puntos de Casos de Uso (PCU),
que permiten realizar estimaciones en una etapa temprana del ciclo de desarrollo de
software, lo cual permite conocer a groso modo la dimensin del sistema que se busca
construir y en consecuencia, tener cierta nocin de la factibilidad del proyecto. El
segundo mtodo de PCU incorpora adems, conceptos de lgica difusa que busca
aumentar su grado de precisin.
Por otro lado, se abord tambin el problema desde la perspectiva de los Puntos de
Funcin (PF). Logrando implementar tres versiones, dos de las cuales poseen una
versin difusa. Adems, cada uno de los mtodos anteriores se puede ajustar a travs de
tres formas distintas.
Una vez descritos cada uno de los mtodos implementados, cabe destacar que el foco de
este trabajo de investigacin fue principalmente el anlisis, ms all de la
implementacin misma. Se busc abarcar una considerable cantidad de mtodos, que le
permita al usuario tener una amplia gama de posibilidades para utilizar, de acuerdo a las
caractersticas del proyecto que tenga que estimar. Esto, debido a que en general, existe
un desconocimiento de los mtodos formales de estimacin de proyectos, lo que implica
que las estimaciones se realicen de forma poco precisa, impidiendo as una planificacin
adecuada que asegure el xito del proyecto o que simplemente permita determinar a
priori, si es viable desarrollarlo, frente a plazos restringidos.
A su vez, otro objetivo fue construir una base que le permita por ejemplo, a otros
memoristas, depurar a travs del tiempo, uno o ms de los mtodos implementados,
adems de incorporar otros, en futuros trabajos de titulacin.
180

Otro aspecto importante a destacar, es que cada uno de los mtodos de estimacin
alcanza su real grado de precisin cuando se ha calibrado lo suficiente, a travs de
continuas iteraciones. Por ello, es de vital importancia tener un registro de los proyectos
a travs del tiempo, almacenando la mayor cantidad de documentacin posible de cada
uno de ellos. Este es un aspecto a destacar de la Asignatura de Proyecto de Ingeniera de
Software, de donde se obtuvo los datos necesarios para realizar las evaluaciones.
Esta debiera ser una tnica tanto a nivel acadmico como empresarial, pero la falta de
informacin constituye una de las principales trabas al momento de pretender desarrollar
mtodos de estimacin del esfuerzo.
Con respecto a los resultados obtenidos, se detect que los mtodos de Puntos de
Funcin (PF) en general, poseen un mayor grado de precisin que los mtodos de Puntos
de Casos de Uso (PCU), esto se explica debido a que es necesaria una mayor cantidad de
informacin para realizar una estimacin mediante PF, por ello se puede concluir que a
medida que aumenta el grado de informacin que se tiene con respecto al sistema que se
busca desarrollar, las estimaciones sern ms precisas.
Como regla general, tambin se puede agregar que, si las estimaciones realizadas a
travs de diferentes tcnicas, tienen resultados razonablemente similares, entonces se
pueden promediar con un alto grado de confianza. Si las estimaciones varan
ampliamente, entonces probablemente se debera descartar una o ambas y revisar los
datos analizados (Roetzheim & Beasley, 1998).
Si analizamos el caso del Sistema de Denuncias Web, se tiene que los Mtodos de
Puntos de Casos de Uso tienen en promedio un error del 14,07%, en cambio, los
Mtodos de Puntos de Funcin presentan un porcentaje de error de slo un 1,87%. En el
caso del Sistema de Administracin de Informes, para el Mtodo de Puntos de Casos de
Uso, existe 65,01% de error, en circunstancias que para el Mtodo de Puntos de
Funcin, el error es de un 5,31%. Los resultados de la evaluacin del Sistema de Control
de Recursos, indican que el promedio de los Mtodos de Puntos de Casos de Uso,
181

contiene un 24,46% de error, en tanto que para el Mtodo de Puntos de Funcin, el error
es solamente de un 1,86%. Finalmente, para el Sistema de Difusin Cultural, se tiene un
error del 31,78% en el Mtodo de Puntos de Casos de Uso, y un 11,21% para el Mtodo
de Puntos de Funcin.
5.2 CONCLUSIN ACERCA DE OBJETIVOS ESPECFICOS

En esta seccin se determinar si se cumplieron o no, cada uno de los objetivos
especficos, los cuales en su conjunto constituyen el objetivo general: Diseo de un
Modelo para la Estimacin del Esfuerzo en Proyectos de Desarrollo de Software.
- Objetivos especficos:
1. Anlisis de metodologas y modelos existentes para la determinacin del
esfuerzo en Proyectos de Desarrollo de Software: el objetivo se cumpli a
cabalidad, muestra de aquello es el Captulo 2, especficamente la seccin 2.5,
donde se aborda un importante nmero de modelos y metodologas existentes.

2. Determinacin de las principales mtricas utilizadas en Proyectos de Desarrollo
de Software en general: nuevamente el objetivo se cumple lo cual se puede
verificar en la seccin 2.4.

3. Seleccin de mtricas y variables aplicadas al Medio Local para Proyectos de
Desarrollo de Software: claramente se utilizaron las mtricas de puntos de
funcin, puntos de casos de uso y lneas de cdigo fuente, de acuerdo a cada uno
de los mtodos implementados.

4. Realizacin de un modelo de estimacin del esfuerzo en Proyectos de Desarrollo
de Software enfocado en el Medio Local: en total se disearon 5 mtodos, los
182

cuales consideran distintos mtodos de ajuste y en algunos casos tambin
consideran una versin difusa. Por ende, se considera cumplido dicho objetivo

5. Construccin de un prototipo de estimacin del esfuerzo en Proyectos de
Desarrollo de Software enfocado en el Medio Local: Los mtodos descritos a lo
largo de la Memoria, pasaron por una etapa de Anlisis, Diseo e
Implementacin, lo cual implica que se desarrollo un prototipo funcional y, por
ende, se considera cumplido el Objetivo Especfico N 5

6. Aplicacin a una serie de proyectos desarrollados en la asignatura Proyectos de
Ingeniera de Software, y conclusin con respecto a ello: en el Captulo 4 se
presenta en detalle cada uno de los proyectos analizados y se realiza una
conclusin con respecto a los resultados obtenidos. Adems, en el Captulo 5 se
retoman las ideas generales y se profundiza en algunos puntos. Por lo tanto, se
considera cumplido el Objetivo Especfico N 6

Como se considera que cada uno de los objetivos especficos se cumpli a cabalidad,
esto implica que el Objetivo General del Trabajo de Titulacin, tambin se alcanza.

5.3 TRABAJOS FUTUROS

Finalmente, prevalece la satisfaccin de que los diversos mtodos de estimacin
implementados son aplicables a la Asignatura de Proyectos de Ingeniera de Software, y
por ende, se espera que a travs del tiempo no solamente se utilicen, si no que se
depuren y complementen con futuros trabajos de titulacin. Adems, sera interesante
estimar proyectos en otras reas como la empresarial por ejemplo, lo cual constituye un
183

valor agregado al producto que se desarroll y se espera que a lo largo de los aos exista
una mejora continua del mismo.
Por el momento, no se considera atribuirle un carcter comercial a los mtodos
implementados, debido a que estos se basan en publicaciones que expertos de todo el
mundo, han publicado a lo largo de las ltimas dcadas, teniendo como incentivo el
progreso de la ingeniera de software, ms all de buscar un provecho econmico. El fin
ltimo, es que los mtodos desarrollados sean mejorados en trabajos futuros, de tal
manera de aumentar el grado de precisin de estos y ampliar tanto la cantidad como el
tipo de proyectos analizados, en bsqueda de una mayor robustez de los mismos.

184

REFERENCIAS BIBLIOGRFICAS

Acosta, C., Liberona, N., & Naranjo, M. (2010). Sistema de Control de Recursos:
Informe Final. Departamento de Ingeniera Informtica, Universidad de Santiago de
Chile.

Abran, A., & Robillard, P. (1996). Function Points Analysis: An Empirical Study of Its
Meaasurement Processes. IEEE Transactions on Software Engineering, Vol. 22, Nro. 12
doi:10.1109/32.553638

Albrecht, A. (1979). Measuring Application Development Productivity. Proc Of IBM
Applications Development Symposium, Monterrey, California. Recuperado el da 7 de
Enero de 2012, de: http://www.bfpug.com.br/Artigos/Albrecht/MeasuringApplication
DevelopmentProductivity.pdf

Albrecht, A. (1983). Software Functions, Source Lines of Code, and Development Effort
Prediction: A Software Science Validation. IEEE Transactions on Software Engineering,
Vol. 9, Nro. 6. doi:10.1109/TSE.1983.235271

Alonso, J. (2009). Gestin de Proyectos: Estimacin, Escuela Tcnica Superior de
Ingeniera Informtica, Universidad de Sevilla, Espaa. Recuperado el da 12 de Enero
de 2012, de: http://www.lsi.us.es/docencia/get.php?id=2270

Bailey, J., & Basili, V. (1981). A Meta-Model for Software Development Resource
Expenditures. IEEE Fifth International Conference on Software Engineering, 107-116.
ISBN: 0897911466

Backer, M. (1983). Contabilidad de Costos. (Segunda ed.). McGraw-Hill, Mxico.
ISBN: 968451381X
185

Backer, M., Jacobson L., & Ramrez, D. (1988). Contabilidad de Costos: Un enfoque
administrativo para la toma de decisiones. (Segunda ed.). McGraw-Hill, Mxico.
ISBN: 6073210248

Barcel, M. (2005). Estimacin de Costes de un Proyecto Informtico, Universitat
Oberta de Catalunya, Barcelona, Espaa. Recuperado el da 20 de Febrero de 2012, de:
http://es.scribd.com/doc/62136299/Est-Imac-Ion-de-Costes-de-Un-Proyecto-Informatico

Barzanallana, R. (2009). Ingeniera del Software. Departamento de Informtica,
Universidad de Murcia, Espaa. Recuperado el da 17 de Enero de 2012, de:
http://www.um.es/docencia/barzana/IAGP/IAGP2-Ingenieria-software-
introduccion.html#BM2

Boehm, B. (1981). Software Engineering Economics. Prentice Hall. Upper Saddle River,
New Jersey, USA. ISBN: 0138221227
Braz, M., & Vergilio, S. (2006). Software Effort Estimation Based on Use Cases.
Computer Science Department, Federal University of Parana, Curitiba, Brazil.
doi:10.1109/COMPSAC.2006.77

Brooks, F. (1995). The Mythical Man-Month. Addison Wesley, Reading, Massachusetts,
USA. ISBN: 0201835959

DeMarco, T. (1982). Controlling Software Projects. Yourdon Press, New York, USA.
ISBN: 0917072324

Direccin de Innovacin Ciencia y Tecnologa para el Desarrollo (DICyT), (2004).
Instructivo para la cuenta de Puntos de Funcin. Ministerio de Educacin y Cultura,
Uruguay. Recuperado el da 10 de Diciembre de 2011, de:
http://www.pdt.gub.uy/pdt/files/6.2.5%20-%20puntosFuncion.pdf
186

Domnguez, J. (2009). The Curious Case of the CHAOS Report 2009. Recuperado el da
12 de Septiembre de 2012, de: http://www.projectsmart.co.uk/the-curious-case-of-the-
chaos-report-2009.html

Dubois, D., & Prade, H. (1991). Fuzzy Sets in Approximate Reasoning, Part 1: Inference
with possibility distributions, In Fuzzy Sets and Systems. IFSA, Special Memorial Value:
25 Years of Fuzzy Sets, Amsterdam. doi:10.1016/0165-0114(91)90050-Z

Garca, N., Gatica, A., & Maldonado, M. (2010). Sistema de administracin de informes
del Departamento Social de la Municipalidad de Pumanque: Informe Final.
Departamento de Ingeniera Informtica, Universidad de Santiago de Chile.

Garmus, D., & Herron, D. (1996). Measuring the Software Process. Prentice Hall,
Upper Saddle River, New Jersey, USA. ISBN: 0133490025

Guajardo, F. (2009). Metodologa de estimacin de costos para procesos de reparacin
de usabilidad de aplicaciones colaborativas con MUG, Departamento de Ingeniera
Informtica, Universidad de Santiago de Chile.

Grauel, A. (1999). Analytical and structural considerations in fuzzy modeling. Fuzzy
Sets and Systems, 101: 205-206. doi:10.1016/S0165-0114(98)00163-8

Haugan, G. T. (2002). Effective Work Breakdown Structures. Management Concepts,
Inc. Vienna, Italia. ISBN: 1567261353

Heemstra, F. C., (1992). Software Cost Estimation. Information and Software
Technology 34, 627-639. doi:10.1016/0950-5849(92)90068-Z

187

Horngren, Ch. T. (1996). Contabilidad de Costos: Un Enfoque Gerencial. (Octava ed.).
Prentice-Hall Hispanoamericana, Mxico. ISBN-10: 9688805025

Jeng, B., Yeh, D., Wang, D, Chu, S., & Chen, C. (2011). A Specific Effort Estimation
Method Using Function Point. Journal of Information Science and Engineering, Vol 27,
1363-1376. Recuperado el 10 de Mayo de 2012, de:
www.iis.sinica.edu.tw/page/jise/2011/201107_11.html

Jijena, R. (2008). Gestin de Proyectos Informticos Sesin N20: Estimacin de Costos
de un Proyecto, Universidad Diego Portales, Chile. Recuperado el 5 de Diciembre de
2011, de: http://rjijena.ublog.cl/archivos/796/20_gpi_estimacion_de_costos.ppt

Jones, T. (1998). Estimating Software Costs. McGraw-Hill, New York, USA.
ISBN: 0079130941

Kantrowitz, M. (1997). Answers to questions about fuzzy logic and fuzzy experts systems
Recuperado el da 4 de Diciembre de 2011, de:
http://www.cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/fuzzy/faq/fuzzy.faq

Klir, G.J., & Yuan, B. (1995). Fuzzy Sets and Fuzzy Logic: Theory and Applications,
Prentice-Hall, Englewood Cliffs, New Jersey. USA. ISBN: 0131011715

Klir, G., & Folger, T. (1988). Fuzzy Sets, Uncertainty and Information. Prentice Hall.
ISBN: 0133459845

Kushal, S. (2007). Recuperado el da 08 de Marzo de 2012, de:
http://www.codeproject.com/Articles/18024/Calculating-Function-Points.

188

Manzhirova, V. (2012). Recuperado el da 05 de Septiembre de 2012, de:
http://www.tuexpertoit.com/tag/gartner/

Marchewka, J. (2006). Information Technology Project Management: Providing
Measurable Organizational Value.(Segunda ed.). John Wiley & Sons, USA.
ISBN: 0471715395

Merino, A., & Vsquez, W. (2007). Diseo de un modelo para la determinacin del
costo da cama del Hospital de Nios de Dr. Exequiel Gonzlez Corts, Departamento
de Ingeniera Industrial, Universidad de Santiago de Chile.

Moreno, A. (2007). Estimacin de Proyectos de Software: COCOMO II. Escuela de
Ingeniera Civil Informtica, Universidad Catlica del Maule. Chile. Recuperado el da
05 de Febrero de 2012, de: http://www.eici.ucm.cl/Academicos/ygomez/descargas/
Ing_Sw2/apuntes/cocomo_manual_espanol.pdf

Pedrycz, W., & Gomide, F. (1998). An Introduction to Fuzzy Sets Analysis and
Design, The MIT Press, Cambridge, MA. ISBN: 0262161710

Peralta, M. (2004). Estimacin del Esfuerzo Basado en Casos de Uso. Centro de
Ingeniera del Software en Ingeniera del Conocimiento (CAPIS), Escuela de Postgrado,
Instituto Tecnolgico de Buenos Aires, Argentina. Recuperado el da 17 de Marzo de
2012, de: http://es.scribd.com/doc/52466176/estimacion-del-esfuerzo-basada-en-casos-
de-usos

Periss, M. (2001). Proyecto Informtico: Una Metodologa Simplificada. Buenos Aires,
Argentina. Recuperado el da 12 de Enero de 2012, de:
http://www.cyta.com.ar/biblioteca/bddoc/bdlibros/proyectoinformatico/libro/index.htm

189

Polimeni, R. (1998). Contabilidad de Costos. (Tercera ed.). McGraw-Hill, Mxico.
ISBN: 9586001954

Pressman, R. (2001). Software Engineering: A Practitioners Approach. McGraw-Hill,
Boston, USA. ISBN: 0071181822

Pressman, R. (2005). Ingeniera del software: Un Enfoque Prctico. (Sexta ed.).
McGraw-Hill, Mxico. ISBN: 9701054733

Putnam, L. (1978). A General Empirical Solution to the Macro Software Sizing and
Estimating Problem. IEEE Transactions on Software Engineering Vol. SE-4, NO. 4,
July, 345-361. doi:10.1109/TSE.1978.231521

Roetzheim, W., & Beasley, R., (1998). Software Project Cost and Schedule Estimating:
Best Practices. Prentice Hall, New Jersey, USA. ISBN: 0136820891

Rossi, W., & Santos, L. (2005). El costeo basado en actividades: Aportes y limitaciones.
Facultad de Ciencias Econmicas y de Administracin, Universidad de la Repblica,
Uruguay. Recuperado el da 18 de Abril de 2012, de:
http://www.ccee.edu.uy/ensenian/catconpg/docs/costeo

Royce, W. (1998). Software Project Management: A Unified Framework. Addison
Wesley, Reading, Massachusetts, USA. ISBN: 0201309580

Saenz, F., Gonzlez, F., & Flores, J. (2011). Sistema de Denuncia Annima: Informe
Final. Departamento de Ingeniera Informtica, Universidad de Santiago de Chile.

190

Schwaber, K., & Sutherland, J. (2012). Software in 30 Days: How Agile Managers Beat
the Odds, Delight Their Customers, And Leave Competitors In the Dust. John Wiley &
Sons, USA. ISBN: 978-1-1182-0666-9.

Schwalbe, K. (1999). Information Technology Project Management. Course
Technology, USA. ISBN-10: 076001180X

Stretton, A. (2007). A Short History of Modern Project Management. (Segunda ed.) PM
World Today, Sidney, Australia. Recuperado el da 23 de Mayo de 2012, de:
http://stanyanakiev.files.wordpress.com/2011/04/stretton-10-07.pdf

Systemation, (2009). Estimating and Risk Management. Recuperado el da 15 de Abril
de 2012, de: http://www.itcourseware.com/docs/sy-estrisk-1.0/evals/sy-estrisk-1.0.pdf

Thompson, D. (2006). Proyectos Informticos: Fracasos y Lecciones Aprendidas,
Direccin de Tecnologa de Informacin y Comunicaciones (DTIC), UNED, San Jos,
Costa Rica. Recuperado el da 18 de Mayo de 2012, de:
http://www.uned.ac.cr/redti/cuarta/art8.pdf

Turksen, I.B. (1991). Measurement of Membership Functions and their Acquisition, In
Fuzzy Sets and Systems. IFSA, Special Memorial Volume: 25 Years of Fuzzy Sets,
North Holland, Amsterdam. doi:10.1016/0165-0114(91)90045-R

Valenzuela, A., Varas, N., & Ziga, F. (2011). Sistema de Difusin Cultural Etapa
Final. Departamento de Ingeniera Informtica, Universidad de Santiago de Chile.

Varas, M. (1995). Modelo de Gestin de Proyectos de Software: Estimacin del
Esfuerzo de Desarrollo. Departamento de Ingeniera Informtica y Ciencias de la
191

Computacin. Universidad de Concepcin. Recuperado el da 15 de Enero de 2012, de:
http://www.inf.udec.cl/~mvaras/papers/arica/arica.htm

Wang, P., & Tan, S. (1997). Soft Computing and Fuzzy Logic, Soft Computing 1: 35-41.
doi:10.1007/s005000050004

Yourdon, E. (1999). Death March. Prentice Hall. Upper Saddle River, New Jersey,
USA. ISBN: 0130146595

Zadeh, L.A. (1965). Fuzzy Sets, Information and Control, Vol. 8. pp. 338-353.
Recuperado el da 30 de Junio de 2012, de: http://www-bisc.cs.berkeley.edu/Zadeh-
1965.pdf

Zimmermann, H.J. (1991). Fuzzy Set Theory and Its Applications, 2
nd
revised edition,
Kluwer, Boston. ISBN: 079239075X

192

APNDICES

APNDICE A: TABLAS DEFUSIFICACIN MTODO 1

Las siguientes, corresponden a las tablas que se utilizaron para implementar el primer
mtodo de Puntos de Funcin Difusos.
ENTRADAS con 0 1 FTR

ENTRADAS con 2 FTRs

ENTRADAS con 3 o ms FTRs
CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE
DETS
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado
1 3

1 3

1 4
2 3

2 3

2 4
3 3

3 3

3 4
4 3

4 3,5

4 4
5 3

5 4

5 4
6 3

6 4

6 4
7 3

7 4

7 4
8 3

8 4

8 4
9 3,066666667

9 4

9 4,133333333
10 3,2

10 4

10 4,4
11 3,333333333

11 4,181818182

11 4,666666667
12 3,466666667

12 4,545454545

12 4,933333333
13 3,6

13 4,909090909

13 5,2
14 3,733333333

14 5,272727273

14 5,466666667
15 3,866666667

15 5,636363636

15 5,733333333
16 4

16 6

16 6
17 4

17 6

17 6
18 4

18 6

18 6
19 4

19 6

19 6
20 4

20 6

20 6
21 4

21 6

21 6
22 4,181818182

22 6,272727273

22 6,272727273
23 4,545454545

23 6,818181818

23 6,818181818
24 4,909090909

24 7,363636364

24 7,363636364
25 5,272727273

25 7,909090909

25 7,909090909
193
APNDICES

26 5,636363636

26 8,454545455

26 8,454545455
27 6

27 9

27 9

SALIDAS con 0 1 FTR

SALIDAS con 2 a 3 FTRs

SALIDAS con 4 ms FTRs
CANTIDAD
DE DETs
Valor
Defusificado

CANTIDAD
DE DETs
Valor
Defusificado

CANTIDAD
DE DETs
Valor
Defusificado
1 4

1 4

1 5
2 4

2 4

2 5
3 4

3 4

3 5
4 4

4 4,2

4 5,4
5 4

5 4,6

5 6,2
6 4

6 5

6 7
7 4

7 5

7 7
8 4

8 5

8 7
9 4

9 5

9 7
10 4

10 5

10 7
11 4,052631579

11 5

11 7
12 4,157894737

12 5

12 7
13 4,263157895

13 5

13 7
14 4,368421053

14 5,285714286

14 7
15 4,473684211

15 5,571428571

15 7
16 4,578947368

16 5,857142857

16 7
17 4,684210526

17 6,142857143

17 7
18 4,789473684

18 6,428571429

18 7
19 4,894736842

19 6,714285714

19 7
20 5

20 7

20 7
21 5

21 7

21 7,214285714
22 5

22 7

22 7,428571429
23 5

23 7

23 7,642857143
24 5

24 7

24 7,857142857
25 5

25 7

25 8,071428571
26 5

26 7

26 8,285714286
27 5

27 7

27 8,5
28 5,285714286

28 7,428571429

28 8,714285714
29 5,571428571

29 7,857142857

29 8,928571429
30 5,857142857

30 8,285714286

30 9,142857143
31 6,142857143

31 8,714285714

31 9,357142857
194
APNDICES

32 6,428571429

32 9,142857143

32 9,571428571
33 6,714285714

33 9,571428571

33 9,785714286
34 7

34 10

34 10

CONSULTAS con 0 1 FTR

CONSULTAS con 2 3 FTRs

CONSULTAS con 4 ms FTRs
CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE
DETS
Valor
Defusificado
1 3

1 3

1 4
2 3

2 3

2 4
3 3

3 3

3 4
4 3

4 3,2

4 4,4
5 3

5 3,6

5 5,2
6 3

6 4

6 6
7 3

7 4

7 6
8 3

8 4

8 6
9 3

9 4

9 6
10 3

10 4

10 6
11 3,052631579

11 4

11 6
12 3,157894737

12 4

12 6
13 3,263157895

13 4

13 6
14 3,368421053

14 4,285714286

14 6
15 3,473684211

15 4,571428571

15 6
16 3,578947368

16 4,857142857

16 6
17 3,684210526

17 5,142857143

17 6
18 3,789473684

18 5,428571429

18 6
19 3,894736842

19 5,714285714

19 6
20 4

20 6

20 6
21 4

21 6

21 6,214285714
22 4

22 6

22 6,428571429
23 4

23 6

23 6,642857143
24 4

24 6

24 6,857142857
25 4

25 6

25 7,071428571
26 4

26 6

26 7,285714286
27 4

27 6

27 7,5
28 4,285714286

28 6,428571429

28 7,714285714
29 4,571428571

29 6,857142857

29 7,928571429
30 4,857142857

30 7,285714286

30 8,142857143
195
APNDICES

31 5,142857143

31 7,714285714

31 8,357142857
32 5,428571429

32 8,142857143

32 8,571428571
33 5,714285714

33 8,571428571

33 8,785714286
34 6

34 9

34 9

ARCHIVOS con 1 RET

ARCHIVOS con 2 a 5 RETs

ARCHIVOS con 6 ms RETs
CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE DETs
Valor
Defusificado
1 7

1 7

1 10
2 7

2 7

2 10
3 7

3 7

3 10
4 7

4 7

4 10
5 7

5 7

5 10
6 7

6 7

6 10
7 7

7 7

7 10
8 7

8 7

8 10
9 7

9 7

9 10
10 7

10 7

10 10
11 7

11 7,157894737

11 10,26315789
12 7

12 7,473684211

12 10,78947368
13 7

13 7,789473684

13 11,31578947
14 7

14 8,105263158

14 11,84210526
15 7

15 8,421052632

15 12,36842105
16 7

16 8,736842105

16 12,89473684
17 7

17 9,052631579

17 13,42105263
18 7

18 9,368421053

18 13,94736842
19 7

19 9,684210526

19 14,47368421
20 7

20 10

20 15
21 7

21 10

21 15
22 7

22 10

22 15
23 7

23 10

23 15
24 7

24 10

24 15
25 7

25 10

25 15
26 7

26 10

26 15
27 7,12

27 10

27 15
28 7,24

28 10

28 15
29 7,36

29 10

29 15
30 7,48

30 10

30 15
31 7,6

31 10

31 15
196
APNDICES

32 7,72

32 10

32 15
33 7,84

33 10

33 15
34 7,96

34 10

34 15
35 8,08

35 10

35 15
36 8,2

36 10,16129032

36 15
37 8,32

37 10,48387097

37 15
38 8,44

38 10,80645161

38 15
39 8,56

39 11,12903226

39 15
40 8,68

40 11,4516129

40 15
41 8,8

41 11,77419355

41 15
42 8,92

42 12,09677419

42 15
43 9,04

43 12,41935484

43 15
44 9,16

44 12,74193548

44 15
45 9,28

45 13,06451613

45 15
46 9,4

46 13,38709677

46 15
47 9,52

47 13,70967742

47 15
48 9,64

48 14,03225806

48 15
49 9,76

49 14,35483871

49 15
50 9,88

50 14,67741935

50 15
51 10

51 15

51 15
52 10

52 15

52 15,22580645
53 10

53 15

53 15,4516129
54 10

54 15

54 15,67741935
55 10

55 15

55 15,90322581
56 10

56 15

56 16,12903226
57 10

57 15

57 16,35483871
58 10

58 15

58 16,58064516
59 10

59 15

59 16,80645161
60 10

60 15

60 17,03225806
61 10

61 15

61 17,25806452
62 10

62 15

62 17,48387097
63 10

63 15

63 17,70967742
64 10

64 15

64 17,93548387
65 10

65 15

65 18,16129032
66 10

66 15

66 18,38709677
67 10,16129032

67 15,22580645

67 18,61290323
68 10,48387097

68 15,67741935

68 18,83870968
69 10,80645161

69 16,12903226

69 19,06451613
70 11,12903226

70 16,58064516

70 19,29032258
197
APNDICES

71 11,4516129

71 17,03225806

71 19,51612903
72 11,77419355

72 17,48387097

72 19,74193548
73 12,09677419

73 17,93548387

73 19,96774194
74 12,41935484

74 18,38709677

74 20,19354839
75 12,74193548

75 18,83870968

75 20,41935484
76 13,06451613

76 19,29032258

76 20,64516129
77 13,38709677

77 19,74193548

77 20,87096774
78 13,70967742

78 20,19354839

78 21,09677419
79 14,03225806

79 20,64516129

79 21,32258065
80 14,35483871

80 21,09677419

80 21,5483871
81 14,67741935

81 21,5483871

81 21,77419355
82 15

82 22

82 22

INTERFACES con 1 RET

INTERFACES con 2 a 5 RETs

INTERFACES con 6 ms RETS
Cantidad de
DETs
Valor
Defusificado

Cantidad de DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado
1 5

1 5

1 7
2 5

2 5

2 7
3 5

3 5

3 7
4 5

4 5

4 7
5 5

5 5

5 7
6 5

6 5

6 7
7 5

7 5

7 7
8 5

8 5

8 7
9 5

9 5

9 7
10 5

10 5

10 7
11 5

11 5,105263158

11 7,157894737
12 5

12 5,315789474

12 7,473684211
13 5

13 5,526315789

13 7,789473684
14 5

14 5,736842105

14 8,105263158
15 5

15 5,947368421

15 8,421052632
16 5

16 6,157894737

16 8,736842105
17 5

17 6,368421053

17 9,052631579
18 5

18 6,578947368

18 9,368421053
19 5

19 6,789473684

19 9,684210526
20 5

20 7

20 10
21 5

21 7

21 10
198
APNDICES

22 5

22 7

22 10
23 5

23 7

23 10
24 5

24 7

24 10
25 5

25 7

25 10
26 5

26 7

26 10
27 5,08

27 7

27 10
28 5,16

28 7

28 10
29 5,24

29 7

29 10
30 5,32

30 7

30 10
31 5,4

31 7

31 10
32 5,48

32 7

32 10
33 5,56

33 7

33 10
34 5,64

34 7

34 10
35 5,72

35 7

35 10
36 5,8

36 7,096774194

36 10
37 5,88

37 7,290322581

37 10
38 5,96

38 7,483870968

38 10
39 6,04

39 7,677419355

39 10
40 6,12

40 7,870967742

40 10
41 6,2

41 8,064516129

41 10
42 6,28

42 8,258064516

42 10
43 6,36

43 8,451612903

43 10
44 6,44

44 8,64516129

44 10
45 6,52

45 8,838709677

45 10
46 6,6

46 9,032258065

46 10
47 6,68

47 9,225806452

47 10
48 6,76

48 9,419354839

48 10
49 6,84

49 9,612903226

49 10
50 6,92

50 9,806451613

50 10
51 7

51 10

51 10
52 7

52 10

52 10,12903226
53 7

53 10

53 10,25806452
54 7

54 10

54 10,38709677
55 7

55 10

55 10,51612903
56 7

56 10

56 10,64516129
57 7

57 10

57 10,77419355
58 7

58 10

58 10,90322581
59 7

59 10

59 11,03225806
60 7

60 10

60 11,16129032
199
APNDICES

61 7

61 10

61 11,29032258
62 7

62 10

62 11,41935484
63 7

63 10

63 11,5483871
64 7

64 10

64 11,67741935
65 7

65 10

65 11,80645161
66 7

66 10

66 11,93548387
67 7,096774194

67 10,12903226

67 12,06451613
68 7,290322581

68 10,38709677

68 12,19354839
69 7,483870968

69 10,64516129

69 12,32258065
70 7,677419355

70 10,90322581

70 12,4516129
71 7,870967742

71 11,16129032

71 12,58064516
72 8,064516129

72 11,41935484

72 12,70967742
73 8,258064516

73 11,67741935

73 12,83870968
74 8,451612903

74 11,93548387

74 12,96774194
75 8,64516129

75 12,19354839

75 13,09677419
76 8,838709677

76 12,4516129

76 13,22580645
77 9,032258065

77 12,70967742

77 13,35483871
78 9,225806452

78 12,96774194

78 13,48387097
79 9,419354839

79 13,22580645

79 13,61290323
80 9,612903226

80 13,48387097

80 13,74193548
81 9,806451613

81 13,74193548

81 13,87096774
82 10

82 14

82 14

200
APNDICES

APNDICE B: TABLAS DEFUSIFICACIN MTODO 2

Las siguientes, corresponden a las tablas que se utilizaron para implementar el segundo
mtodo de Puntos de Funcin Difusos.
ENTRADAS con 0 1 FTR

ENTRADAS con 2 FTRs

ENTRADAS con 3 o ms FTRs
Cantidad de
DETs
Valor
Defusificado

CANTIDAD DE
DETS
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado
1 2

1 2

1 3
2 2

2 2

2 3
3 2

3 3

3 4
4 2,5

4 3

4 4
5 3

5 4

5 6
6 3

6 4

6 6
7 3

7 4

7 6
8 3

8 4

8 6
9 3

9 4

9 6
10 3

10 4

10 6
11 3,090909091

11 4,181818182

11 6
12 3,272727273

12 4,545454545

12 6
13 3,454545455

13 4,909090909

13 6
14 3,636363636

14 5,272727273

14 6
15 3,818181818

15 5,636363636

15 6
16 4

16 6

16 6
17 4

17 6

17 6,363636364
18 4

18 6

18 6,727272727
19 4

19 6

19 7,090909091
20 4

20 6

20 7,454545455
21 4

21 6

21 7,818181818
22 4,181818182

22 6,363636364

22 8,181818182
23 4,545454545

23 7,090909091

23 8,545454545
24 4,909090909

24 7,818181818

24 8,909090909
25 5,272727273

25 8,545454545

25 9,272727273
26 5,636363636

26 9,272727273

26 9,636363636
27 6

27 10

27 10

201
APNDICES

SALIDAS con 0 1 FTR

SALIDAS con 2 a 3 FTRs

SALIDAS con 4 ms FTRs
CANTIDAD
DE DETs
Valor
Defusificado

CANTIDAD
DE DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado
1 3

1 3

1 4
2 3

2 3

2 4
3 3

3 4

3 5
4 3,2

4 4

4 5
5 3,6

5 4,333333333

5 5,666666667
6 4

6 5

6 7
7 4

7 5

7 7
8 4

8 5

8 7
9 4

9 5

9 7
10 4

10 5

10 7
11 4

11 5

11 7
12 4

12 5

12 7
13 4

13 5

13 7
14 4,142857143

14 5,285714286

14 7
15 4,285714286

15 5,571428571

15 7
16 4,428571429

16 5,857142857

16 7
17 4,571428571

17 6,142857143

17 7
18 4,714285714

18 6,428571429

18 7
19 4,857142857

19 6,714285714

19 7
20 5

20 7

20 7
21 5

21 7

21 7,285714286
22 5

22 7

22 7,571428571
23 5

23 7

23 7,857142857
24 5

24 7

24 8,142857143
25 5

25 7

25 8,428571429
26 5

26 7

26 8,714285714
27 5

27 7

27 9
28 5,285714286

28 7,571428571

28 9,285714286
29 5,571428571

29 8,142857143

29 9,571428571
30 5,857142857

30 8,714285714

30 9,857142857
31 6,142857143

31 9,285714286

31 10,14285714
32 6,428571429

32 9,857142857

32 10,42857143
33 6,714285714

33 10,42857143

33 10,71428571
34 7

34 11

34 11

202
APNDICES

CONSULTAS con 0 1 FTR

CONSULTAS con 2 3 FTRs

CONSULTAS con 4 ms FTRs
CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE
DETS
Valor
Defusificado
1 2

1 2

1 3
2 2

2 2

2 3
3 2

3 3

3 4
4 2,2

4 3

4 4
5 2,6

5 3,333333333

5 4,666666667
6 3

6 4

6 6
7 3

7 4

7 6
8 3

8 4

8 6
9 3

9 4

9 6
10 3

10 4

10 6
11 3

11 4

11 6
12 3

12 4

12 6
13 3

13 4

13 6
14 3,142857143

14 4,285714286

14 6
15 3,285714286

15 4,571428571

15 6
16 3,428571429

16 4,857142857

16 6
17 3,571428571

17 5,142857143

17 6
18 3,714285714

18 5,428571429

18 6
19 3,857142857

19 5,714285714

19 6
20 4

20 6

20 6
21 4

21 6

21 6,285714286
22 4

22 6

22 6,571428571
23 4

23 6

23 6,857142857
24 4

24 6

24 7,142857143
25 4

25 6

25 7,428571429
26 4

26 6

26 7,714285714
27 4

27 6

27 8
28 4,285714286

28 6,571428571

28 8,285714286
29 4,571428571

29 7,142857143

29 8,571428571
30 4,857142857

30 7,714285714

30 8,857142857
31 5,142857143

31 8,285714286

31 9,142857143
32 5,428571429

32 8,857142857

32 9,428571429
33 5,714285714

33 9,428571429

33 9,714285714
34 6

34 10

34 10

203
APNDICES

ARCHIVOS con 1 RET

ARCHIVOS con 2 a 5 RETs

ARCHIVOS con 6 ms RETs
CANTIDAD
DE DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado
1 5

1 5

1 7
2 5

2 5

2 7
3 5

3 5

3 7
4 5

4 5

4 7
5 5

5 5

5 7
6 5

6 5,222222222

6 7,333333333
7 5

7 5,666666667

7 8
8 5

8 6,111111111

8 8,666666667
9 5

9 6,555555556

9 9,333333333
10 5

10 7

10 10
11 5,105263158

11 7

11 10
12 5,315789474

12 7

12 10
13 5,526315789

13 7

13 10
14 5,736842105

14 7

14 10
15 5,947368421

15 7

15 10
16 6,157894737

16 7,6

16 11
17 6,368421053

17 8,2

17 12
18 6,578947368

18 8,8

18 13
19 6,789473684

19 9,4

19 14
20 7

20 10

20 15
21 7

21 10

21 15
22 7

22 10

22 15
23 7

23 10

23 15
24 7

24 10

24 15
25 7

25 10

25 15
26 7

26 10

26 15
27 7

27 10

27 15
28 7

28 10

28 15
29 7

29 10

29 15
30 7

30 10

30 15
31 7

31 10

31 15
32 7

32 10

32 15
33 7

33 10

33 15
34 7

34 10

34 15
35 7

35 10

35 15
204
APNDICES

36 7,096774194

36 10,16129032

36 15
37 7,290322581

37 10,48387097

37 15
38 7,483870968

38 10,80645161

38 15
39 7,677419355

39 11,12903226

39 15
40 7,870967742

40 11,4516129

40 15
41 8,064516129

41 11,77419355

41 15
42 8,258064516

42 12,09677419

42 15
43 8,451612903

43 12,41935484

43 15
44 8,64516129

44 12,74193548

44 15
45 8,838709677

45 13,06451613

45 15
46 9,032258065

46 13,38709677

46 15
47 9,225806452

47 13,70967742

47 15
48 9,419354839

48 14,03225806

48 15
49 9,612903226

49 14,35483871

49 15
50 9,806451613

50 14,67741935

50 15
51 10

51 15

51 15
52 10

52 15

52 15,25806452
53 10

53 15

53 15,51612903
54 10

54 15

54 15,77419355
55 10

55 15

55 16,03225806
56 10

56 15

56 16,29032258
57 10

57 15

57 16,5483871
58 10

58 15

58 16,80645161
59 10

59 15

59 17,06451613
60 10

60 15

60 17,32258065
61 10

61 15

61 17,58064516
62 10

62 15

62 17,83870968
63 10

63 15

63 18,09677419
64 10

64 15

64 18,35483871
65 10

65 15

65 18,61290323
66 10

66 15

66 18,87096774
67 10,16129032

67 15,25806452

67 19,12903226
68 10,48387097

68 15,77419355

68 19,38709677
69 10,80645161

69 16,29032258

69 19,64516129
70 11,12903226

70 16,80645161

70 19,90322581
71 11,4516129

71 17,32258065

71 20,16129032
72 11,77419355

72 17,83870968

72 20,41935484
73 12,09677419

73 18,35483871

73 20,67741935
74 12,41935484

74 18,87096774

74 20,93548387
205
APNDICES

75 12,74193548

75 19,38709677

75 21,19354839
76 13,06451613

76 19,90322581

76 21,4516129
77 13,38709677

77 20,41935484

77 21,70967742
78 13,70967742

78 20,93548387

78 21,96774194
79 14,03225806

79 21,4516129

79 22,22580645
80 14,35483871

80 21,96774194

80 22,48387097
81 14,67741935

81 22,48387097

81 22,74193548
82 15

82 23

82 23

INTERFACES con 1 RET

INTERFACES con 2 a 5 RETs

INTERFACES con 6 ms RETS
Cantidad de
DETs
Valor
Defusificado

Cantidad de
DETs
Valor
Defusificado

CANTIDAD DE
DETs
Valor
Defusificado
1 4

1 4

1 5
2 4

2 4

2 5
3 4

3 4

3 5
4 4

4 4

4 5
5 4

5 4

5 5
6 4

6 4,111111111

6 5,222222222
7 4

7 4,333333333

7 5,666666667
8 4

8 4,555555556

8 6,111111111
9 4

9 4,777777778

9 6,555555556
10 4

10 5

10 7
11 4,052631579

11 5

11 7
12 4,157894737

12 5

12 7
13 4,263157895

13 5

13 7
14 4,368421053

14 5

14 7
15 4,473684211

15 5

15 7
16 4,578947368

16 5,4

16 7,6
17 4,684210526

17 5,8

17 8,2
18 4,789473684

18 6,2

18 8,8
19 4,894736842

19 6,6

19 9,4
20 5

20 7

20 10
21 5

21 7

21 10
22 5

22 7

22 10
23 5

23 7

23 10
24 5

24 7

24 10
25 5

25 7

25 10
206
APNDICES

26 5

26 7

26 10
27 5

27 7

27 10
28 5

28 7

28 10
29 5

29 7

29 10
30 5

30 7

30 10
31 5

31 7

31 10
32 5

32 7

32 10
33 5

33 7

33 10
34 5

34 7

34 10
35 5

35 7

35 10
36 5,064516129

36 7,096774194

36 10
37 5,193548387

37 7,290322581

37 10
38 5,322580645

38 7,483870968

38 10
39 5,451612903

39 7,677419355

39 10
40 5,580645161

40 7,870967742

40 10
41 5,709677419

41 8,064516129

41 10
42 5,838709677

42 8,258064516

42 10
43 5,967741935

43 8,451612903

43 10
44 6,096774194

44 8,64516129

44 10
45 6,225806452

45 8,838709677

45 10
46 6,35483871

46 9,032258065

46 10
47 6,483870968

47 9,225806452

47 10
48 6,612903226

48 9,419354839

48 10
49 6,741935484

49 9,612903226

49 10
50 6,870967742

50 9,806451613

50 10
51 7

51 10

51 10
52 7

52 10

52 10,12903226
53 7

53 10

53 10,25806452
54 7

54 10

54 10,38709677
55 7

55 10

55 10,51612903
56 7

56 10

56 10,64516129
57 7

57 10

57 10,77419355
58 7

58 10

58 10,90322581
59 7

59 10

59 11,03225806
60 7

60 10

60 11,16129032
61 7

61 10

61 11,29032258
62 7

62 10

62 11,41935484
63 7

63 10

63 11,5483871
64 7

64 10

64 11,67741935
207
APNDICES

65 7

65 10

65 11,80645161
66 7

66 10

66 11,93548387
67 7,096774194

67 10,12903226

67 12,06451613
68 7,290322581

68 10,38709677

68 12,19354839
69 7,483870968

69 10,64516129

69 12,32258065
70 7,677419355

70 10,90322581

70 12,4516129
71 7,870967742

71 11,16129032

71 12,58064516
72 8,064516129

72 11,41935484

72 12,70967742
73 8,258064516

73 11,67741935

73 12,83870968
74 8,451612903

74 11,93548387

74 12,96774194
75 8,64516129

75 12,19354839

75 13,09677419
76 8,838709677

76 12,4516129

76 13,22580645
77 9,032258065

77 12,70967742

77 13,35483871
78 9,225806452

78 12,96774194

78 13,48387097
79 9,419354839

79 13,22580645

79 13,61290323
80 9,612903226

80 13,48387097

80 13,74193548
81 9,806451613

81 13,74193548

81 13,87096774
82 10

82 14

82 14

APNDICE C: DETALLE DEL RESULTADO MTODO
INDIRECTO PROYECTO DENUNCIAS WEB

Estos constituyen los resultados por actividad, en horas y meses hombre, del mtodo
de entradas indirectas correspondiente al proyecto de denuncias Web.

- Mtodo de Puntos de Funcin Tradicional - Mtodo de Ajuste Tradicional

Anlisis 57,040

Diseo 57,040

Programacin 171,120

Pruebas 57,040

Sobrecarga 38,027

Total 380,267

208
APNDICES


Anlisis 0,951

Diseo 0,951

Programacin 2,852

Pruebas 0,951

Sobrecarga 0,634

Total 6,338

- Mtodo de Puntos de Funcin Tradicional - Mtodo de Ajuste Modificado

Anlisis 52,700

Diseo 52,700

Programacin 158,100

Pruebas 52,700

Sobrecarga 35,133

Total 351,333


Anlisis 0,878

Diseo 0,878

Programacin 2,635

Pruebas 0,878

Sobrecarga 0,586

Total 5,856

- Mtodo de Puntos de Funcin Tradicional - Mtodo de Ajuste COCOMO II

Anlisis 55,781

Diseo 55,781

Programacin 167,342

209
APNDICES

Pruebas 55,781

Sobrecarga 37,187

Total 371,870


Anlisis 0,930

Diseo 0,930

Programacin 2,789

Pruebas 0,930

Sobrecarga 0,620

Total 6,198

- Mtodo de Puntos de Funcin Tradicional Modificado - Mtodo de Ajuste
Tradicional

Anlisis 57,040

Diseo 57,040

Programacin 171,120

Pruebas 57,040

Sobrecarga 38,027

Total 380,267


Anlisis 0,951

Diseo 0,951

Programacin 2,852

Pruebas 0,951

Sobrecarga 0,634

Total 6,338

210
APNDICES

Modificado

Anlisis 39,525

Diseo 79,050

Programacin 158,100

Pruebas 59,288

Sobrecarga 59,288

Total 395,250


Anlisis 0,659

Diseo 1,318

Programacin 2,635

Pruebas 0,988

Sobrecarga 0,988

Total 6,588

COCOMO II

Anlisis 55,781

Diseo 55,781

Programacin 167,342

Pruebas 55,781

Sobrecarga 37,187

Total 371,870


Anlisis 0,930

Diseo 0,930

211
APNDICES

Programacin 2,789

Pruebas 0,930

Sobrecarga 0,620

Total 6,198

- Mtodo de Puntos de Funcin Tradicional Modificado Versin 2 - Mtodo de Ajuste
Tradicional

Anlisis 33,788

Diseo 67,575

Programacin 135,150

Pruebas 50,681

Sobrecarga 50,681

Total 337,875


Anlisis 0,563

Diseo 1,126

Programacin 2,253

Pruebas 0,845

Sobrecarga 0,845

Total 5,631

Tradicional Modificado

Anlisis 48,760

Diseo 48,760

Programacin 146,280

Pruebas 48,760

Sobrecarga 32,507

Total 325,067

212
APNDICES


Anlisis 0,813

Diseo 0,813

Programacin 2,438

Pruebas 0,813

Sobrecarga 0,542

Total 5,418

COCOMO II

Anlisis 55,781

Diseo 55,781

Programacin 167,342

Pruebas 55,781

Sobrecarga 37,187

Total 371,870


Anlisis 0,930

Diseo 0,930

Programacin 2,789

Pruebas 0,930

Sobrecarga 0,620

Total 6,198

213
APNDICES

APNDICE D: FACTORES DE CONVERSIN COCOMO II

Estos corresponden a los Factores de conversin entre puntos de funcin sin ajustar y
lneas de cdigo fuente.

Lenguaje de
Programacin
Factor de Conversin PFSA/SLOC

Promedio Mediana Menor Ms Alto
ABAP (SAP)
18 18 16 20
Access
36 38 15 47
Ada
154 - 104 205
Advantage
38 38 38 38
APS
86 83 20 184
ASP
56 50 32 106
Assembler
209 203 91 320
C
148 107 22 704
C++
59 53 20 178
C#
58 59 51 66
Clipper
40 39 26 53
COBOL
80 78 8 400
ColdFusion
68 56 52 105
Cool:Gen/IEF
37 35 10 180
Culprit
51 - - -
Datastage
67 79 16 85
DBase IV
52 - - -
Easytrieve+
33 34 25 41
Excel
47 46 31 63
Focus
45 45 40 49
FORTRAN
90 118 35 -
FoxPro
36 35 34 38
HTML
43 42 35 53
Ideal
66 52 34 203
Informix
42 31 24 57
J2EE
57 50 50 67
214
APNDICES

Java
55 53 9 214
JavaScript
54 55 45 63
JCL
96 59 58 173
JSP
59 - - -
KML
50 50 49 50
Lotus Notes
23 21 15 46
Maestro
30 30 30 30
Mantis
71 27 22 250
Mapper
69 70 58 81
Natural
51 53 34 60
.NET
60 60 60 60
Netron/CAP
296 323 105 399
Openroad
39 34 20 69
Oracle
42 29 12 217
Oracle Dev 2K
35 30 23 100
Pacbase
42 43 26 52
PeopleSoft
37 32 34 40
PHP
67 - - -
Perl
57 57 45 60
PL/1
58 57 27 92
PL/SQL
47 39 16 78
Powerbuilder
28 22 8 105
Powerhouse
63 25 79
REXX
50 - - -
RPG II/III
61 49 24 155
Sabretalk
70 61 54 94
SAS
50 35 32 102
Siebel Tools
13 13 5 20
Slogan
81 80 66 100
Smalltalk
28 19 17 55
SQL
31 30 13 80
SQL Forms
11 11 10 15
Taskmate
45 47 37 51
Uniface
61 50 31 120
VB.Net
28 - - -
VBScript
38 37 29 50
215
APNDICES

Visual Basic
50 52 14 276
VPF
95 95 92 98
Web Scripts
44 15 9 114

Memoria Eduardo Miranda

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Memoria Eduardo Miranda

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD DE SANTIAGO DE CHILE

(x) < 1, se ejecuta el siguiente proceso de Defusificacin (Ecuacin 3.14).

Potrebbero piacerti anche