PFC Jesus Alvarez

Contenido
1. REVISIN DE LOS MODELOS DE ESTIMACIN SOFTWARE ...... 2 1.1. MEDIDAS DE ESTIMACIN ............................................................. 2 1.2. MEDIDAS Y MTRICAS DEL SOFTWARE ...................................... 5 1.3. CLASIFICACIN DE LOS MODELOS DE ESTIMACIN ................ 6 1.4. PROBLEMAS DE LA ESTIMACIN SOFTWARE ............................ 7 1.5. MODELOS DE ESTIMACIN SOFTWARE ...................................... 7 1.5.1. Aproximaciones paramtricas .............................................. 8 1.5.2. Aproximaciones heursticas ............................................... 20 1.5.3. Otras herramientas de apoyo a la estimacin .................... 22 1.6 COMPARATIVA DE DIFERENTES MODELOS DE ESTIMACIN 24 2. ESTIMACIN POR ANALOGA ...................................................... 2.1. JUSTIFICACIN DEL USO DE LA ESTIMACIN POR ANALOGA .................................................................................................................. 40 2.2. PROCESO DE ESTIMACIN POR ANALOGA .............................. 40 2.2.1. Ajuste mediante algoritmos genticos ................................ 42 2.2.2. Ajuste por regresin hacia la media ............................... 43 2.3. VENTAJAS E INCONVENIENTES DE LA ESTIMACIN POR ANALOGA ........................................................................................ 45 2.4. HERRAMIENTAS PARA LA ESTIMACIN POR ANALOGA ....... 47 2.4.1. ESTOR ................................................................................ 48 2.4.2. ANGEL ............................................................................... 48 2.5. CRITERIOS DE EVALUACIN ....................................................... 49
iii
3. ESTUDIOS DE ALGORITMOS DE CLASIFICACIN PARA ESTIMACIN .................................................................................... 3.1. REPRESENTACIN DE LOS DATOS .............................................. 55 3.1.1. Normalizacin de los datos ................................................. 56 3.2. MEDIDA DE SIMILITUD .................................................................57 3.3. ALGORITMO KNN .......................................................................... 58 3.4. ESTIMACIN BASADA EN ANALOGA ......................................... 59 4. DISEO DE LAS PRUEBAS Y RESULTADOS OBTENIDOS ............ 4.1. PARMETROS DE CONFIGURACIN DE LAS PRUEBAS ........... 65 4.2. DESARROLLO DE LAS PRUEBAS .................................................. 66
iv
PRLOGO
La Ingeniera del Software es uno de las cuestiones ms olvidadas y rechazadas entre la mayora de estudiantes de Ingeniera Informtica. Sin embargo, es una de las temticas ms importantes en el conjunto global de la titulacin de Ingeniera Informtica, y fundamental para el correcto desarrollo de productos software. Errneamente se identifica la creacin de software slo con su programacin y prueba, dando de lado el proceso anterior de planificacin y diseo, as como de asignacin de recursos y de esfuerzo. Quiz para productos sencillos y de carcter acadmico, como los realizados por los estudiantes de Ingeniera Informtica, la asignacin de dinero, tiempo y recursos no sea decisiva para la calidad y correccin del programa, pero en una empresa dedicada al desarrollo software, cuyos productos necesitan una gran cantidad de programadores, y el tiempo de desarrollo y los gastos deben ser prefijados, la estimacin y planificacin del proyecto son fundamentales e indispensables. Este es uno de los motivos que han hecho decantarme por este proyecto, ya que adems de ser una materia fundamental de cara a las salidas laborales, siempre he sentido especial predileccin e inters por ella. Adems existe una gran necesidad en las empresas de desarrollo software de estimar y planificar proyectos, siendo este uno de los hechos que ms me ha hecho decidirme por su eleccin. Como ya he indicado anteriormente, la Ingeniera Software es vital para la correcta elaboracin de productos software. Antes de comenzar la tarea puramente de programacin y creacin del programa es necesario realizar una estimacin y una previsin sobre la cantidad de tiempo que llevar su realizacin as como del esfuerzo y el personal necesario para completarlo. Para llevar a cabo esta estimacin existen una serie de modelos que actualmente son
utilizados por las empresas de desarrollo software, y cuyos resultados poseen una calidad dependiente del entorno. Por ello este estudio intentar esclarecer cules son los mejores modelos as como mostrar una comparativa entre ellos. Todos estos modelos y herramientas pueden ser directamente aplicados a la estimacin de parmetros como esfuerzo y costo de proyectos de tipo software. Pero en este proyecto, aparte de dar una visin general sobre estos utensilios, se va a proponer una alternativa para la estimacin, basada en una tcnica muy extendida como es la estimacin por analoga. La estimacin por analoga se basa en la seleccin de proyectos anlogos a aquel que quiere ser estimado previamente completados y almacenados en una base de datos. Con los datos de estos proyectos se realizarn una serie de operaciones y ajustes encaminados a determinar cules son los ms parecidos al proyecto bajo cuestin, para poder ofrecer una estimacin de su esfuerzo. Entre estas operaciones, encontramos principalmente los clculos de similitud entre proyectos, que en nuestro lugar ser la medida del coseno, por su fcil aplicacin sobre informacin vectorial, que es la que almacenaremos en nuestra base de datos, y por los buenos resultados derivados de su aplicacin en otros mbitos. Por tanto, como principal objetivo de este proyecto se plantea un estudio de los diferentes modelos de estimacin, sobre todo de los basados en la analoga, proponiendo una alternativa para realizar la estimacin del esfuerzo utilizando para ello algoritmos de clasificacin de instancias. De entre todos los algoritmos existentes para la clasificacin, se ha escogido kNN, por su sencillez, eficiencia y por los buenos resultados que consigue al ser aplicado en otros mbitos. Adems, es un algoritmo directamente aplicable a nuestro propsito de estimar esfuerzo en proyectos software basndonos en analogas. Una vez que kNN ha preparado el camino, puede aplicarse ya la estimacin por analoga. Este es un sencillo mtodo que aporta como valor de
vi
esfuerzo estimado aquel que poseen los proyectos ms parecidos al que est siendo sometido a examen. Si embargo, no considerando como definitivo este valor, hemos aplicado un ajuste para tener en cuenta las diferencias existentes entre proyectos. El ajuste seleccionado est basado en un fenmeno estadstico conocido como regresin hacia la media, que en nuestro caso hace que los valores de esfuerzo de los proyectos se muevan hacia la media del conjunto de los ms cercanos, por lo que este ajuste desplazar el valor estimado hacia la media del conjunto, segn una serie de medidas y correlaciones. Proponemos adems el uso de MMRE como medida del error cometido en las estimaciones hechas. sta es una medida comnmente usada en el mbito de la Ingeniera Software, que presenta adems un clculo sencillo y sin grandes necesidades de computacin, y que es un excelente indicador de la exactitud y precisin con la que nuestra alternativa realiza las estimaciones. Estas medidas y algoritmos sern evaluados sobre un conjunto de datos reales sobre proyectos software ya completados, almacenados en una base de datos disponible a travs de la web, creada y mantenida por la asociacin ISBSG (Internacional Software Benchmarking Standards Group). En esta base de datos se guardan datos sobre 2047 proyectos de diversos pases, con un gran nmero de caractersticas. Para poder concretar cules son los parmetros ms adecuados de los algoritmos empleados en la propuesta de estimacin presentada, se realizar un estudio de su efectividad considerando muy diversas configuraciones, determinndose finalmente cul es la ms apropiada. La ejecucin de diversas pruebas nos va a permitir realizar todo tipo de comparaciones entre los resultados obtenidos, en funcin de los parmetros de configuracin que poseen los algoritmos empleados. Estas comparativas nos conducirn a la determinacin de los valores idneos que deben tomar estos parmetros. Mediante la realizacin de este Proyecto fin de Carrera se pretende por tanto, realizar una comparativa entre los diferentes modelos de estimacin en vii
proyectos software y analizar ms en profundidad la tcnica de estimacin por analoga, complementada con un sencillo ajuste matemtico que aporta buenos resultados. Para completar estos objetivos se debe en primer lugar realizar una profunda bsqueda de bibliografa que muestre el estado actual de la disciplina de la estimacin software, y que indique las modificaciones hechas a tcnicas ya anticuadas para poder adaptarlas a los nuevos requerimientos del desarrollo software. Adems, ser crucial la obtencin de datos reales sobre proyectos software ya completados, para poder realizar con ellos las pruebas y experimentos diseados. Una vez obtenidos los datos necesarios, se proceder a la
implementacin de la alternativa planteada a lo largo del proyecto, y su posterior ejecucin y obtencin de resultados.
viii
ix
Jess
CAPTULO 1
REVISIN DE LOS MODELOS DE ESTIMACIN SOFTWARE
Jess lvarez Sez
titulo
Jess lvarez Sez
titulo
CAPTULO 1
REVISIN DE LOS MODELOS DE ESTIMACIN SOFTWARE
Contenidos 1.1. Proceso de estimacin ................................................................ 2 1.2. Medidas y mtricas del software ............................................... 5 1.3. Clasificacin de los modelos de estimacin ............................... 6 1.4. Problemas de la estimacin software ........................................ 7 1.5. Modelos de estimacin software ................................................ 7 1.5.1. Aproximaciones paramtricas ..................................... 8 1.5.2. Aproximaciones heursticas ......................................... 20 1.5.3. Otras herramientas de apoyo a la estimacin ............. 22 1.6 Comparativa de los diferentes modelos de estimacin .............. 24
Escuela Politcnica Superior de Jan
Jess
Cuanto mayor es la necesidad de utilizar el software en cualquier

actividad humana, mayor es tambin la complejidad y dificultad de implementacin que ste adquiere. Aunque cada vez existan ms tcnicas que facilitan el diseo y desarrollo de los sistemas, las nuevas exigencias de los usuarios y los nuevos dominios de aplicacin generan nuevos problemas. Esto crea la necesidad de prestar cada vez ms atencin a los procesos de planificacin, medicin y estimacin de diversos parmetros software, antes de comenzar con el desarrollo propiamente dicho. Esta necesidad convierte la gestin de los proyectos software en una tarea de vital importancia, siendo uno de sus puntos clave la estimacin del esfuerzo y el tiempo necesario para la finalizacin de estos productos. Sin unas buenas estimaciones de estos parmetros, comienzan a surgir imprevistos y problemas durante el desarrollo que imposibilitan la entrega del producto final en el plazo acordado, con sus consiguientes aumentos en los gastos y prdidas econmicas. En las empresas de desarrollo software se realizan continuamente estimaciones acerca de los productos que desarrollan. Esto hace que surjan cada vez ms modelos y tcnicas para poder hacer predicciones sobre el tamao o el esfuerzo necesario para completar estos productos, ya que en dichas organizaciones se adaptan en ocasiones los mtodos tradicionales segn sus necesidades. En este captulo se pretende dar una visin general sobre los distintos mtodos de estimacin de proyectos software, abarcando multitud de modelos desde los ms utilizados a otros ms novedosos y actuales, fruto de las nuevas tcnicas y entornos de programacin. Previo a este anlisis, se explicar cmo se llevan a cabo las estimaciones en las organizaciones, proceso que engloba el clculo del tamao del software as como el esfuerzo y tiempo requerido para su creacin.
Jess lvarez Sez
titulo
Como cabe esperar, en estos procesos de previsin y estimacin intervienen una gran cantidad de mtricas y medidas, que sern analizadas y explicadas brevemente, para posibilitar as una mejor comprensin de los modelos. Por ltimo, y antes de profundizar en cada modelo, se plantean una serie de problemas que afectan a las estimaciones en la actualidad, para dar as una visin ms realista de estos procesos.
1.1 PROCESO DE ESTIMACIN

En la industria en general, es necesario calcular y estimar el esfuerzo y el tamao del proyecto en etapas muy tempranas del desarrollo del mismo. Sin embargo, si en el mbito software se hacen las estimaciones en estas fases iniciales, dichas previsiones pueden estar basadas en unos requerimientos errneos o incompletos, por lo que disminuye mucho su fiabilidad. El proceso de estimacin del coste de un producto software est formado por un conjunto de tcnicas y procedimientos que se usan en la organizacin para poder llegar a una prediccin fiable. ste es un proceso continuo, que debe ser usado y consultado a lo largo de todo el ciclo de vida del proyecto. Se divide en los siguientes pasos [AGA01]: Estimacin del tamao. Estimacin del costo y del esfuerzo. Estimacin de la programacin temporal. Estimacin de la cantidad de recursos computacionales. Asuncin de riesgos. Inspeccin y aprobacin. Redaccin de informes de estimacin.
Jess Medicin y perfeccionamiento del proceso.
En la ilustracin 1 pueden observarse los distintos pasos del proceso de estimacin, as como las interacciones existentes entre ellos.
Anlisis de requerimientos
Estimacin del tamao
Base de Datos de Proceso de organizacin Software
Estimacin del esfuerzo y costo
Estimacin de la programacin temporal
Estimacin de la cantidad de recursos computacionales
Asuncin de riesgos
Inspeccin y aprobacin
Redaccin de informes
Medida y mejora del proceso
Ilustracin 1: Actividades de la estimacin de proyectos software
Todas estas estimaciones necesarias estn basadas en probabilidades debido a la influencia de factores externos de difcil control. Adems de estas probabilidades, es necesario recurrir a informacin histrica, que debe ser fcilmente accesible y disponible para la organizacin en cualquier momento.
Jess lvarez Sez
titulo
Por desgracia, no siempre se presta la suficiente atencin al cuidado de estos datos, por lo que en ocasiones acceder a ellos no resulta sencillo. La cantidad de esfuerzo y tiempo dedicada a la estimacin depende del tamao del proyecto, del equipo de desarrollo y del objetivo a cumplir. La naturaleza del proyecto y el entorno en el que se desarrolla son factores determinantes en esta tarea, y afectan en gran medida al mtodo de estimacin que se utilice. De una manera general podemos afirmar que existen dos maneras diferentes de estimar el presupuesto y el tiempo para un proyecto software: usando modelos de costo y usando razonamiento basado en similitud. En ambas opciones es necesario recurrir a informacin histrica y de proyectos anteriores previamente almacenados en bases de datos. Existen cuatro puntos fundamentales sobre los que se apoya la estimacin: Las consideraciones y opiniones de los profesionales de la materia, basada en la experiencia y la madurez de los gestores de proyecto, los cuales tendrn que adivinar y predecir el tiempo de realizacin del proyecto o su coste. La participacin de expertos, cuyas opiniones no deben ser consideradas y abordadas como las de los profesionales y gestores de proyecto, ya que los expertos no pertenecen a la organizacin y pueden estar no familiarizados con las prcticas propias de la organizacin. La utilizacin de factores estndar de tiempos, calculados y establecidos a partir de proyectos anteriores. Por ltimo el empleo de frmulas y funciones, que implica la existencia de datos cuantitativos que representen una buena aproximacin a la estimacin. Adems no deben existir dudas acerca de la fiabilidad y seguridad del predictor usado. Escuela Politcnica Superior de Jan 5
Jess
1.2. MEDIDAS Y MTRICAS DEL SOFTWARE

En el campo de la ingeniera del software, se suele hablar indistintamente de mtricas y de medidas, pero sin embargo existen diferencias entre estos trminos. Una medida indica cuantitativamente algn atributo de proceso o de producto (extensin, cantidad, dimensiones, capacidad, tamao, etc.). Una mtrica es definida por el Glosario de estndares del IEEE (Institute of Electrical and Electronics Engineers) [IEE93] como una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo determinado. Si se recopila un slo tipo de datos, como por ejemplo el nmero de errores dentro de un componente, se ha establecido una medida. Una mtrica de software relaciona de alguna manera las medidas individuales. Siguiendo nuestro ejemplo, podramos tratar el nmero de errores encontrados en cada revisin o prueba [PRE98]. Los ingenieros de software, a partir de las medidas, elaboran mtricas que les proporcionan informacin para poder controlar el proceso o el proyecto software. Aqu radica la diferencia entre estos trminos. Hecha esta aclaracin, podemos pasar a tratar algunas mtricas de proyecto usadas por los ingenieros del software, todas ellas de vital importancia durante los procesos de estimacin. Suelen ser recopiladas de proyectos anteriores, de manera que se comparan sucesivamente con los valores actuales de esfuerzo y tiempo, y as se puede supervisar la correccin de las estimaciones realizadas. Otras mtricas de gran utilidad pueden ser el nmero de pginas de documentacin, las horas de revisin, el nmero de errores detectados, etc. [PRE98]. Referente a las medidas del software, tambin vitales en la estimacin, podemos clasificarlas en directas o indirectas: entre las directas se encuentran las lneas de cdigo, velocidad de ejecucin, tamao de la memoria, etc. y hacen 6 Escuela Politcnica Superior de Jan
Jess lvarez Sez
titulo
referencia a atributos cuantitativos del producto; como indirectas se podran citar la funcionalidad, la calidad, complejidad, eficiencia, fiabilidad, etc. En general, pueden elaborarse infinidad de mtricas a partir de medidas. Por ejemplo el tamao lo podemos asociar al nmero de lneas de cdigo o de documentacin, al tamao del equipo de desarrollo, a la cantidad de dinero, etc., y obtener a partir de estas medias multitud de mtricas: cantidad de dinero por lnea, lneas de cdigo por persona, pginas de documentacin por persona, etc.
1.3. CLASIFICACIN DE LOS MODELOS DE ESTIMACIN

Los diferentes modelos de estimacin para proyectos pueden ser clasificados de diversas maneras, de entre las cuales se deben destacar las aportadas por dos autores principales [CHA96]: Segn Basili Segn este autor existen tres modelos: Modelos con una o varias variables estticas, que se basan en aplicar funciones y constantes a algunas propiedades del proyecto, por ejemplo el LOC (Lines Of Code). Modelos con varias variables dinmicas, que miden el tiempo del proyecto frente a su costo, usando una distribucin obtenida de manera emprica. Modelos tericos con algoritmos prediseados, que se basan en una hiptesis para realizar una prediccin a travs de una funcin obtenida teniendo en cuenta informacin histrica. Segn Kitchenham
Jess Kitchenham propone una clasificacin ms simple para estos modelos, basada en distinguir entre aquellos que especifican la relacin entre varios parmetros de costo, llamados modelos de restriccin, y los que predicen el valor de un parmetro de costo, llamado modelos de factor emprico. Como ejemplo de esta clasificacin podemos encontrar entre los modelos de restriccin los de Putnam, Jensen, Cocomo, o Parr. Algunos modelos de factor emprico son Esfuerzo de Cocomo, Wolverton, Softcost, Estimacs, o Price. Otras clasificaciones Otras maneras ms simples de clasificar los modelos de estimacin distinguen tres categoras bsicas: Juicio experto: aunque no es un mtodo en el sentido estricto de obtener resultados de una manera explcita y repetitiva, es una de las prcticas ms extendidas, en las que se combinan las opiniones de varios expertos para obtener estimaciones, como por ejemplo el mtodo Delphi. Modelos algortmicos: se basan en frmulas y parmetros con los que realizan las estimaciones. Son tambin muy conocidos y empleados en la actualidad, encontrndose en este grupo el modelo COCOMO o puntos de funcin. Analoga: puede ser tomada como una variante del juicio experto, ya que tambin intervienen las opiniones de los estimadores, pero a diferencia de este tipo, necesita caracterizar claramente el proyecto que se va a estimar y almacenar los proyectos previos para buscar entre ellos el ms parecido al actual.
1.4. PROBLEMAS PRESENTADOS POR LA ESTIMACIN DEL ESFUERZO DE PROYECTOS SOFTWARE

8 Escuela Politcnica Superior de Jan
Jess lvarez Sez
titulo
A pesar de la amplia variedad de mtodos y paquetes de software que apoyan la estimacin para proyectos de desarrollo software, la planificacin es an una tarea muy difcil. En la prctica, todos los modelos de estimacin presentan una serie de problemas: Dan unas predicciones muy deficientes cuando se aplican sobre conjuntos de datos independientes entre s. Estn basados en apreciaciones subjetivas acerca de las variables de entrada, y por tanto ofrecen resultados muy diferentes cuando se aplican sobre el mismo problema, ya que estas valoraciones estn muy influidas por el medio en el que se desarrolla el proyecto y su entorno. Estiman el tiempo o costo slo para las ltimas etapas del proceso de desarrollo, olvidndose en la mayora de los casos las iniciales. Usan KLOC (Thousand of Lines of code) o KDSI (Thousand of Delivered Source Instruction) como factores, para estimar el tiempo o costo inicial de la fase de codificacin, constituyndose como base para la estimacin del resto de etapas, a pesar de aquellas recomendaciones que afirman que estos factores no son del todo apropiados. El factor KDSI no tiene en cuenta los recursos disponibles para el equipo de desarrollo (como herramientas software), ni las caractersticas propias del equipo, como por ejemplo su grado de experiencia. Sin embargo, como resultados de diversos estudios y experimentos, se demuestra cmo la capacidad del equipo de desarrollo es uno de los factores que ms afectan al tiempo total de realizacin del proyecto.
1.5. MODELOS DE ESTIMACIN SOFTWARE
Jess Hay dos aproximaciones principales para estimar el volumen de un proyecto software: paramtricas y heursticas [AGA01].
1.5.1. Aproximaciones paramtricas

Las estimaciones paramtricas usan como predictor una mtrica determinada fcilmente al comienzo del ciclo de vida del software. Una buena mtrica nos asegura una correcta correlacin con el esfuerzo del proyecto, y facilita la estimacin del mismo. Las dos mtricas ms comnmente usadas son el nmero de lneas del cdigo fuente (SLOC. Source Lines of Code) y los puntos de funcin (FP, Function Points). Para sistemas dirigidos por datos, domina el uso de puntos de funcin. Es con sistemas dirigidos por computacin con los que es ms frecuente el uso de SLOC, ya que la mayor parte del tiempo lo consume el procesador ejecutando operaciones, relegando el papel de los datos y del usuario como fuente de informacin sobre el tamao del sistema. COCOMO COCOMO (COnstructive COst MOdel) fue propuesto por Barry Boehm en 1981, y es un ejemplo claro de micromodelo con tecnologa ascendente. Adems, es el modelo de estimacin de costes ms utilizado. El principal clculo en el modelo COCOMO es el uso de la ecuacin del esfuerzo para estimar el nmero de personas o de meses necesarios para desarrollar el proyecto. El resto de resultados del modelo se derivan de esta medida. ESFUERZO = A x TAMAOB
10
Jess lvarez Sez
titulo
En esta sencilla ecuacin, A y B son constantes obtenidas empricamente y dependientes del modo de desarrollo. La estimacin del tamao del proyecto queda expresada en SLOC, definida con las siguientes reglas: Lneas de cdigo creadas por el personal del proyecto (no el creado por generadores de aplicaciones). Una instruccin es una lnea de cdigo. Las declaraciones se toman como instrucciones. Los comentarios no se cuentan como instrucciones.
En COCOMO es fundamental el trmino que hace referencia al modo de desarrollo del proyecto, que influye directamente en el costo y duracin del mismo, y que puede ser: Modo orgnico: cuando el proyecto es desarrollado en un ambiente familiar y estable, y en el que el producto es similar a otros desarrollados previamente. Son adems productos pequeos y poco novedosos, con unos requerimientos definidos y poco rgidos. Modo empotrado: para proyectos caracterizados por unos requerimientos y restricciones poco flexibles, que requieren un gran esfuerzo de innovacin. Tambin poseen un elevado nivel de complejidad hardware. Modo semiacoplado: es un modelo para proyectos que presentan caractersticas intermedias entre el orgnico y el empotrado, con un equipo formado por miembros de distintos niveles de experiencia, que trabajan sobre un conjunto de requisitos ms o menos flexibles.
11
Jess COCOMO est definido en trminos de tres modelos diferentes: modelo bsico, intermedio y detallado, que reflejan el nivel de detalle considerado a la hora de realizar la estimacin del coste. El modelo bsico provee una estimacin inicial poco refinada, el intermedio la modifica utilizando una serie de multiplicadores relacionados con el proyecto y el proceso, y el detallado realiza diferentes estimaciones para cada fase del proyecto. ste ltimo es el ms complejo, y cuenta con ms factores que influyen en el software, consiguiendo as mejores estimaciones. a) Modelo bsico Este modelo hace sus previsiones en funcin del tamao del proyecto medido en miles de lneas de cdigo (KSLOC). Estas estimaciones de esfuerzo calculadas, se expresan en Personas - Mes (PM), considerando 152 horas de trabajo mensuales, y 19 das de trabajo por mes. La ecuacin bsica del esfuerzo queda definida de la siguiente forma [AGA01]:
MODO DE DESARROLLO Orgnico Semiacoplado Empotrado ECUACIN BSICA DEL ESFUERZO Esfuerzo = 2.4 * KSLOC1.05 Esfuerzo = 3.0 * KSLOC1.12 Esfuerzo = 3.6 * KSLOC1.20
Tabla 1: Ecuacin bsica del esfuerzo en COCOMO (modelo bsico)
Las estimaciones sobre el tiempo son:

MODO DE DESARROLLO Orgnico Semiacoplado Empotrado ECUACIN BSICA DEL TIEMPO Tiempo de desarrollo = 2.5 * Esfuerzo0.38 Tiempo de desarrollo = 2.5 * Esfuerzo0.35 Tiempo de desarrollo = 2.5 * Esfuerzo0.32
Tabla 2: Ecuacin bsica del tiempo en COCOMO (modelo bsico)
b) Modelo intermedio El modelo intermedio y el detallado, usan un factor de ajuste del esfuerzo (EAF), y los coeficientes de las ecuaciones de esfuerzo varan notoriamente con respecto a los del modelo bsico, permaneciendo el clculo del tiempo sin cambios.
12
Jess lvarez Sez

MODO DE DESARROLLO Orgnico Semiacoplado Empotrado ECUACIN BSICA DEL ESFUERZO Esfuerzo = EAF * 3.2 * KSLOC1.05 Esfuerzo = EAF * 3.0 * KSLOC1.12 Esfuerzo = EAF * 2.8 * KSLOC1.20
titulo
Tabla 3: Ecuacin bsica del esfuerzo en COCOMO (modelo intermedio y detallado)
Este modelo obtiene unos mejores resultados, en gran parte debido al establecimiento de 15 factores de costo, que determinan la duracin y el coste del proyecto. En la siguiente tabla se pueden apreciar los diferentes factores de costo establecidos en COCOMO [AGA01].
MUY BAJO RELY DATA CPLX TIME STOR VIRT TURN ACAP AEXP PCAP VEXP LEXP MODP TOOL SCED 0.75 0.7 1.46 1.29 1.42 1.21 1.14 1.24 1.24 1.23 MUY ALTO 1.40 1.16 1.30 1.30 1.21 1.30 1.15 0.71 0.82 0.70 0.82 0.83 1.10
EXTR. ALTO
Factor de costo ATRIBUTOS DEL PRODUCTO Fiabilidad requerida Tamao de base de datos Complejidad Tiempo de ejecucin Memoria principal Permanencia de la mquina virtual Tiempo de ejecucin Capacidad del analista ATRIBUTOS DEL PERSONAL Experiencia en aplicaciones Capacidad del programador Experiencia con mquinas virtuales Experiencia con el lenguaje ATRIBUTOS DEL PROYECTO Prcticas de programacin modernas Uso de herramientas software Programacin necesaria del desarrollo
BAJO 0.88 0.94 0.85 0.87 0.87 1.19 1.13 1.17 1.10 1.07 1.10 1.10 1.08
MEDIO
ALTO 1.15 1.08 1.15 1.11 1.06 1.15 1.07 0.86 0.91 0.86 0.90 0.95 0.91 0.91 1.04
1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00
1.65 1.66 1.56 -
ATRIBUTOS DEL COMPUTADOR
Tabla 4: Factores de costo en COCOMO
El Factor de Ajuste del esfuerzo (EAF), se calcula multiplicando los correspondientes factores asociados a cada variable de costo.
13
Jess Otro de los motivos que justifica que el modelo intermedio obtenga mejores resultados que el bsico es la posibilidad de poder dividir el sistema en componentes. Esto implica que valores como SLOC o los factores de costo puedan ser escogidos en funcin de determinadas partes del sistema, no considerndolo como un todo. De esta manera se pueden hacer estimaciones sobre el personal, el costo y la duracin de cada componente, permitindose as elaborar distintas estrategias de desarrollo. c) Modelo detallado La nica diferencia existente entre el modelo intermedio y el detallado, es que este ltimo utiliza diferentes multiplicadores del esfuerzo para cada fase del proyecto. Las seis fases que define COCOMO son: requerimientos, diseo del producto, diseo detallado, codificacin y pruebas de unidad, integracin y test y por ltimo mantenimiento. Las fases comprendidas entre el diseo del producto y la integracin y test son llamadas fases de desarrollo. COCOMO II COCOMO II es un modelo que permite estimar el coste, el esfuerzo y el tiempo cuando se planifica una nueva actividad de desarrollo software, y est asociado a los ciclos de vida modernos. Fue desarrollado a partir de COCOMO, incluyendo actualizaciones y nuevas extensiones ms adecuadas a los requerimientos de los ingenieros software. Est construido para satisfacer aquellas necesidades expresadas por los estimadores software, como por ejemplo el apoyo a la planificacin de proyectos, la previsin de personal de proyecto, replanificacin, seguimiento, negociaciones de contrato o la evaluacin del diseo. COCOMO II proporciona una familia de modelos de estimacin muy detallados, y que tiene muy en cuenta el tipo informacin disponible. Este conjunto de modelos se divide en tres:
14
Jess lvarez Sez -
titulo
Modelo de composicin de aplicaciones, para proyectos de construccin de interfaces grficas de usuario.
Modelo de diseo preliminar, utilizado para obtener estimaciones sobre el coste de un proyecto, antes de que est determinada por completo su arquitectura.
Modelo post-arquitectura, que es el ms detallado, y debe ser usado una vez determinada la arquitectura al completo.
El usar un modelo u otro depende del nivel de detalle del proyecto, de la fidelidad requerida de las estimaciones, y de la definicin de los requerimientos y de los detalles de la arquitectura. De una manera general, podemos determinar en qu momentos es ms adecuado la utilizacin de un modelo u otro: El modelo de composicin de aplicaciones se aplicar sobre todo en las primeras fases o ciclos en espiral. El modelo de diseo preliminar es til para las siguientes fases o ciclos espirales, en los que se incluye la exploracin de arquitecturas alternativas o estratgicas de desarrollo incremental. Una vez que el proyecto est listo para desarrollar y sostener un sistema especializado, el submodelo de Post-arquitectura proporciona informacin ms precisa de los controladores de coste de entradas y permite clculos de coste ms exactos. Sendos modelos usan la siguiente ecuacin: PM = 2.45 * EAF * TamaoB Donde EAF (Effort Adjustment Factor) es el producto de siete multiplicadores de esfuerzo para el modelo de desarrollo temprano, y diecisiete para el modelo post-arquitectural.
15
Jess B es un factor que toma valores comprendidos entre 1.01 y 1.26, que viene dado por B = 1.01 + wi, siendo wi la suma de cinco factores que causan efecto en la economa del proyecto, y que son: Existencia de precedentes al proyecto. Flexibilidad del desarrollo. Resolucin de riesgos. Cohesin del equipo. Madurez del proceso.
Los multiplicadores de esfuerzo para COCOMO II son [AGA01]:

MODELO DE DESARROLLO TEMPRANO Fiabilidad y complejidad del producto (RCPX) Necesidad de reutilizacin (RUSE) Dificultad de la plataforma (PDIF) MODELO POST-ARQUITECTURAL Fiabilidad requerida del software (RELY) Tamao de la base de datos (DATA) Complejidad del producto (CPLX) Necesidad de documentacin (DOCU) Necesidad de reutilizacin (RUSE) Restriccin de tiempo de ejecucin (TIME) Restriccin de almacenamiento principal (STOR) Estabilidad de la plataforma (PVOL) Capacidad del analista (ACAP) Capacidad del programador (PCAP) Continuidad del personal (PCON) Experiencia en aplicaciones (AEXP) Experiencia con la plataforma (PEXP) Experiencia con el lenguaje y herramientas (LTEX) Uso de herramientas software (TOOL) Desarrollo distribuido (SITE) Programacin requerida del desarrollo (SCED)
Capacidad del personal (PERS)
Experiencia del personal (PREX) Facilidades (FCIL) Programacin (SCED)
Tabla 5: Multiplicadores de esfuerzo para COCOMO II
COCOTS Los modelos COCOTS (Constructive Commercial Off-The-Shelf) se utilizan en proyectos caracterizados principalmente por dos aspectos: su cdigo fuente no est disponible para el desarrollador de la aplicacin, y su evolucin no es supervisada por el mismo.
16
Jess lvarez Sez El actividades: Valoracin de los componentes COTS desarrollo de software utilizando COCOTS implica
titulo cuatro
Esta actividad permite escoger productos software COCOTS para ser integrados en el sistema global. Los candidatos viables se determinan en funcin de una serie de caractersticas: Requerimientos funcionales: capacidad ofrecida. Requerimientos de rendimiento: restricciones de tiempo y tamao. Requerimientos no funcionales: coste, formacin, instalacin, mantenimiento y fiabilidad. Esta valoracin se realiza en dos fases. En la primera, se agrupan componentes viables, eliminando aquellos que no se adecuan al contexto actual, y en la segunda se hace una seleccin final de productos, en funcin de las caractersticas que presentan. Adaptacin de componentes En esta fase se configuran los productos COTS para ser usados en un contexto especfico, realizando principalmente inicializacin de parmetros, interfaces de usuario, distribucin de los informes de salida, instalacin de protocolos de seguridad, etc. Para poder medir y calibrar el esfuerzo empleado en realizar estas labores de adecuacin e integracin de productos COTS, se asigna a cada tarea de adecuacin un valor concreto y establecido segn la complejidad de dicha tarea. El esfuerzo total de la fase de adaptacin es una funcin dependiente del nmero de productos COTS cuya modificacin haya sido necesaria. Escuela Politcnica Superior de Jan 17
Jess La dificultad del proceso de adaptacin se basa en los siguientes aspectos: Especificacin de parmetros. Desarrollo de scripts. Especificacin de informes de entrada o salida, de interfaces grficas de usuario. Inicializacin de protocolos de seguridad y acceso Fiabilidad de las herramientas de adaptacin utilizadas.
Teniendo en cuenta cada uno de estos aspectos, se asignan los niveles de complejidad a cada producto COTS. Sumando los esfuerzos necesarios para cada producto modificado, se estima el esfuerzo total del proceso de adaptacin. Cdigo de unin En esta fase se ensamblan los diferentes productos COTS, para pasar a formar parte de un sistema mayor. Puede ser necesaria la unin de productos COTS entre s o bien con un sistema de un nivel superior. Los multiplicadores de esfuerzo utilizados por COCOTS son [AGA01]:
Experiencia del responsable de integracin con el producto Capacidad personal del responsable de integracin Experiencia del responsable de integracin Continuidad personal de responsable de integracin Madurez del producto Fiabilidad del distribuidor Complejidad de la interfaz Soporte del distribuidor Formacin aportada por el distribuidor Restricciones sobre la fiabilidad del sistema Complejidad de la interfaz de la aplicacin Restricciones para el desarrollo tcnico de COTS Portabilidad de la aplicacin Aplicacin de Ingeniera Arquitectural
FACTORES PERSONALES
FACTORES DE PRODUCTOS COTS
FACTORES DE APLICACIN Y DEL SISTEMA FACTOR DE ESCALA NO LINEAL
Tabla 6: Multiplicadores de esfuerzo para COCOTS
Puntos de funcin
18
Jess lvarez Sez
titulo
El anlisis por puntos de funcin fue desarrollado a mediados de los setenta para intentar superar las dificultades asociadas al uso de las lneas de cdigo como medida del tamao del software, y para aportar un mecanismo para predecir el esfuerzo necesario para el desarrollo de un proyecto software. Las medidas realizadas mediante puntos de funcin son totalmente independientes de la tecnologa. Sea cual sea el lenguaje utilizado, el mtodo de desarrollo o la plataforma hardware usada, el nmero de puntos de funcin permanece siempre constante. El anlisis por puntos de funcin puede ser usado tambin para comparar herramientas, entornos o lenguajes entre s, bien dentro de una misma organizacin o entre varias. Esta es una de las grandes ventajas de este tipo de anlisis. Los puntos de funcin ofrecen una medida de la funcionalidad entregada por la aplicacin [PRE06], es decir, las caractersticas funcionales aportadas por la aplicacin una vez creada. Como este valor no se puede medir directamente, se debe derivar de manera indirecta mediante otras medidas. Las tareas asociadas a los puntos de funcin deben ser incluidas como parte del proyecto, y por tanto deben ser planeadas y programadas. Principales componentes del anlisis por puntos de funcin Desde el momento en que los sistemas computacionales comenzaron a interactuar con otros computadores, fue necesaria la existencia de un lmite o frontera alrededor de cada uno de estos sistemas antes de clasificar componentes. Este lmite debe ser dibujado desde el punto de vista del usuario, es decir, delimitando el proyecto o aplicacin a ser medida y la parte externa de la misma, o dominio del usuario. Una vez que se ha establecido dicha frontera, los componentes pueden ser clasificados, ordenados y tasados. Los cinco componentes principales son [PRE98]:
19
Jess Entradas de usuario (External Inputs o EI): son procesos elementales en los que los datos atraviesan la frontera desde fuera hacia dentro de la aplicacin. Estos datos pueden provenir de formularios de entrada por pantalla, o de otras aplicaciones, y puede ser informacin de control o relativa al negocio. Normalmente, los datos relativos al problema son usados para actualizar ciertos archivos relativos a la lgica interna del programa (Internal Logical Files). Salidas de usuario (External Outputs o EO): al contrario que las EI, son procesos que atraviesan la frontera desde dentro hacia la parte externa de la aplicacin o sistema. Esta informacin, que tambin actualiza ILFs mediante la creacin de informes o ficheros de salida, est orientada al programa. Peticiones de usuario (External Queries o EQ): son procesos de entrada y salida que solicitan informacin contenida en los ILFs y en los ficheros de interfaces, sin realizar ningn tipo de actualizacin de ficheros. Son entradas interactivas que producen la generacin de alguna respuesta del software inmediata en forma de salida interactiva. Ficheros de lgica Interna (Internal Logical Files o ILF): archivos de datos relacionados entre s que residen en el interior del sistema, como parte de una gran base de datos o como ficheros independientes. Ficheros Externos de Interfaz external Interface Files o EIF): Son datos que residen fuera de la aplicacin y son mantenidos por otras diferentes. Son ILF para otras aplicaciones, y son usados slo como referencia. Engloban todas las interfaces legibles por la mquina que se utilizan para transmitir informacin a otro sistema. Una vez que los componentes de la aplicacin han sido clasificados en los cinco grupos principales (EIs, EOs, EQs, ILFs, EIFs), se les califica como 20 Escuela Politcnica Superior de Jan
Jess lvarez Sez
titulo
de nivel bajo, medio o alto. Esta es una tarea algo subjetiva, aunque las organizaciones han desarrollado criterios para esta calificacin, como por ejemplo las siguientes tablas:
COMPLEJIDAD DE LAS ENTRADAS N tipos de archivos referenciados 0-1 2-3 4 N tipos de elementos de datos incluidos 1-4 Baja Baja Media 5-15 Baja Media Alta 16 Media Alta Alta
Tabla 7: Calibracin de la complejidad de las entradas en Puntos de Funcin
COMPLEJIDAD DE LAS SALIDAS Y PETICIONES N tipos de archivos referenciados 0-1 2-3 4 N tipos de elementos de datos incluidos 1-5 Baja Baja Media 6-19 Baja Media Alta 20 Media Alta Alta
Tabla 8:Calibracin de la complejidad de las salidas y peticiones en Puntos de Funcin
COMPLEJIDAD DE LOS ARCHIVOS E INTERFACES N tipos de archivos referenciados 0-1 2-5 6 N tipos de elementos de datos incluidos 1-19 Baja Baja Media 20-50 Baja Media Alta 51 Media Alta Alta
Tabla 9: Calibracin de la complejidad de los archivos interfaces en Puntos de Funcin
Hecha la clasificacin, se calcula la cuenta total mediante la siguiente tabla [PRE98]:

PARMETRO DE MEDICIN Cuenta Nmero de entradas de _______ x usuario Nmero de salidas de _______ x usuario FACTOR DE PONDERACIN Simple Medio Complejo 3 4 6 = ________
= ________
21
Jess
Nmero de peticiones de usuario Nmero de archivos
_______ x
= ________
_______ x
10
15
= ________
Nmero de interfaces _______ x externas CUENTA TOTAL
10
= ________ = _______
Tabla 10: Cuenta total de los puntos de funcin
Con esta cuenta total se pueden calcular ya los puntos de funcin, segn la siguiente relacin: PF = cuenta_total x [0,65 + 0,01 x Fi ] Donde Fi es la suma de los valores de ajuste de la complejidad, segn las respuestas dadas a las 14 preguntas destacadas a continuacin [PRE98]:
No influencia 0
EVALUACIN DE LOS FACTORES DE COMPLEJIDAD Incidental Moderado Medio Significativo 1 2 3 4
Esencial 5
Tabla 11: evaluacin de los factores de complejidad en Puntos de Funcin
1.
Requiere el sistema copias de seguridad y de recuperacin fiables?
2. 3. 4. 5.
Se requiere comunicacin de datos? Existen funciones de procesamiento distribuido? Es crtico el rendimiento? Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado?
6. 7.
Requiere el sistema entrada de datos interactiva? Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones?
22
Jess lvarez Sez 8. 9. Se actualizan los archivos maestros de forma interactiva?
titulo
Son complejas las entradas, las salidas, los archivos o las peticiones?
10. Es complejo el procesamiento interno? 11. Se ha diseado el cdigo para ser reutilizable?
12. Estn incluidas en el diseo la conversin y la instalacin? 13. Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? 14. Se ha diseado la aplicacin para facilitar los cambios y ser fcilmente utilizada por el usuario?
1.5.2. Aproximaciones heursticas

Bottom - up Esta filosofa de estimacin divide el proyecto en pequeas partes, aplicndole a cada una evaluacin directa del esfuerzo. El valor obtenido se normaliza en funcin del peso y la importancia de cada parte. Posteriormente se irn uniendo estas partes en subsistemas. La principal ventaja que aporta este sistema, es que las personas que realizan la estimacin son las mismas que van a hacer el desarrollo. Sin embargo, tiene el inconveniente de que normalmente no se cuenta el tiempo de estimacin, que suele ser importante. Otra desventaja sera que si se descubren errores en las partes finales del proceso, habra que rechazar prcticamente toda la estimacin hecha hasta el momento [AGA01]. Top - down
23
Jess En primer lugar se estiman los costes a nivel de sistema, de una manera general, para posteriormente ir obteniendo los costes de cada uno de los diferentes subsistemas identificados [AGA01]. Juicio experto: tcnica Delphi La tcnica Delphi se basa en la obtencin de un consenso de un grupo de expertos, que expresan sus opiniones y ofrecen estimaciones sobre el proyecto en cuestin. Los expertos expresan sus opiniones mediante unos formularios que le son entregados y que rellenan de manera totalmente annima. Estos cuestionarios contiene cada una de las estimaciones realizadas a nivel personal por cada componente del grupo. Estos cuestionarios son entregados al coordinador del proceso, quien se encarga de comunicarle a cada experto la opinin de los dems, junto con datos estadsticos sobre todas las estimaciones entregadas. Una vez que cada estimador posee esta informacin, vuelven a rellenar los cuestionarios y los entregan nuevamente al coordinador. Este proceso se repetir hasta que el coordinador encuentre un consenso y una opinin generalizada acerca de la estimacin del proyecto. Con este mtodo, se producen juicios de consenso de una manera rpida y eficaz. Adems es un mtodo estructurado para estudiar la anticipacin de sucesos futuros, permitiendo la incorporacin de factores no racionales, algo muy til cuando existan variables sociales que puedan tener impacto en la previsin. Sin embargo, ofrece una serie de desventajas, relacionadas con la elaboracin de los cuestionarios y la seleccin de los expertos. Para salvar la primera dificultad, se debe realizar un diseo mucho ms elaborado y detallado de los cuestionarios entregados a los expertos. El segundo inconveniente puede ser solucionado mediante una eleccin aleatoria de entre todo el universo de
24
Jess lvarez Sez
titulo
estimadores con experiencia, para evitar as selecciones tendenciosas y dirigidas.
1.5.3. Estimacin para proyectos orientados a objetos

Lorenz y Kidd [LOR94] disearon un modelo de estimacin exclusivo para proyectos software orientados a objetos. La importancia de este paradigma de programacin hace que sea comentado junto al resto de tcnicas de estimacin. Esta tcnica se desarrolla siguiendo los siguientes pasos: Se hacen estimaciones siguiendo cualquier mtodo propio de aplicaciones convencionales. Posteriormente se aplica el modelado de anlisis orientado a objetos, desarrollando casos de uso. A partir de este modelo de anlisis, se calcula el nmero de clases clave. Determinar el tipo de interfaz a implementar, asocindole un multiplicador segn la siguiente tabla:
Tipo de interfaz Sin IUG Interfaz basada en texto IUG IUG compleja Multiplicador 2.0 2.25 2.25 3.0
Tabla 12: Multiplicadores para interfaces en estimacin de proyectos OO
Multiplicar el nmero de clases clave por el multiplicador, para obtener una estimacin del nmero de clases soporte.
Multiplicar el nmero total de clases por el nmero promedio de unidades de trabajo por clase (15-20 personas-da por clase, segn Lorenz y Kidd).
25
Jess Comprobar de manera cruzada la estimacin basada en clase al multiplicar el nmero promedio de unidades de trabajo por caso de uso [PRE06].
1.5.4. Estimacin para desarrollo gil

Se denomina proyecto gil de software a aquel que rene las siguientes caractersticas [PRE06]: Es muy difcil predecir aquellos requerimientos de software que persistirn y cules cambiarn con el tiempo. Tienen el diseo y la construccin intercalados, de modo que se prueban los modelos de diseo conforme se crean. El anlisis, el diseo y la implementacin no son predecibles.
La estimacin en este tipo de proyectos sigue los siguientes pasos: Cada escenario de usuario se considera por separado, y se descompone en un conjunto de funciones y tareas de ingeniera software necesarias para desarrollarlo. Cada tarea se estima por separado, con cualquier mtodo, y el volumen mediante LDC o puntos de funcin. Las estimaciones de cada tarea se suman para obtener una estimacin de cada escenario. El volumen del escenario se traduce en esfuerzo mediante la aplicacin de datos histricos. Las estimaciones de esfuerzo de cada escenario se suman con el fin de obtener el esfuerzo total de cada incremente de software.
1.5.5. Estimacin para proyectos de ingeniera web

26 Escuela Politcnica Superior de Jan
Jess lvarez Sez
titulo
Los proyectos de ingeniera web adoptan normalmente el modelo de proceso gil. Por este motivo, es frecuente utilizar una medicin de puntos de funcin modificada en conjunto con los pasos de la estimacin en proyectos giles. Para calcular los puntos de funcin adaptados se utilizan los siguientes valores de dominio de informacin: Por entradas se toma cada pantalla o formato de entrada (por ejemplo CGI-beans). Salidas son cada pgina web esttica o cada guin de pgina dinmica (ASP, ISAPI, etc.). Tablas son cada tabla lgica en la base de datos ms cada objeto XML, si ste es empleado para almacenar datos en un archivo. Las interfaces siguen tomndose de igual manera que en puntos de funcin tradicionalConsultas son cada interfaz publicada externamente, tales como las referencias externas DCOM o COM. Estos puntos de funcin calculados son un indicador razonable del volumen de una aplicacin web.
1.5.6. Herramientas software de apoyo a la estimacin

PRICE-S El modelo PRICE-S (Programming Review of Information Costing and Evaluation Software) fue desarrollado por RCA PRICE Systems. Su filosofa se basa en evitar que los conceptos e ideas sobre las que se apoya el modelo son inaccesibles para el usuario, como es el caso de COCOMO y Puntos de funcin, que son presentados a los usuarios como una caja negra. Por Escuela Politcnica Superior de Jan 27
Jess ello, el usuario de PRICE-S enva sus peticiones a un ordenador que trabaja a tiempo compartido situado en EE.UU, Reino Unido o Francia, y devuelve sus estimaciones inmediatamente [HEE92]. Modelo Putnam Putnam desarroll este modelo basndose en el trabajo de Norden, quien observ las distribuciones de frecuencia de diversos proyectos de IBM, y analiz cunta gente se asignaba para el desarrollo y mantenimiento de productos software a lo largo de su ciclo de vida. Las curvas obtenidas por Norden coincidan muy bien con la curva Rayleigh, descubrimiento totalmente emprico al que no consigui encontrar una explicacin [HEE92]. Before You Leap (BYL) BYL es un paquete comercial, que se basa para sus estimaciones en los puntos de funcin y en el modelo COCOMO. En primer lugar, obtiene el total de puntos de funcin de la aplicacin. Esta cantidad la traduce a miles de lneas de cdigo (KSLOC) en funcin del lenguaje de programacin que se vaya a utilizar. Este nmero de lneas de cdigo se utiliza para realizar la estimacin con COCOMO [HEE92]. Estimacs Es un paquete comercial de estimacin que se compone de 9 mdulos de diversa aplicacin: asuncin de riesgos, puntos de funcin, estimacin, etc. El ms valioso de estos mdulos es el que realiza las estimaciones de esfuerzo de desarrollo y mantenimiento, usando un mtodo desconocido para los usuarios, quienes se limitan a contestar a 25 preguntas acerca de la complejidad de la organizacin y del tamao del producto a desarrollar [HEE92].
28
Jess lvarez Sez SPQR-20
titulo
SPQR ofrece estimaciones acerca de la duracin, costo y esfuerzo de desarrollo de productos software, as como de costes de mantenimiento. Utiliza puntos de funcin para establecer el tamao del programa, y plantea al usuario una serie de preguntas sobre el proyecto a desarrollar. Su potencia radica en las preguntas que realiza al usuario (entre 10 y 100) y en una enorme base de datos en la que almacena datos sobre proyectos pasados [HEE92]. BIS-estimator Es una herramienta diferente a las dems, basada en el conocimiento. Sin embargo, no se califica certeramente como tal, ya que sus creadores ocultan gran parte de su funcionamiento. En primer lugar hace una primera estimacin basndose en las respuestas que da el usuario a una serie de preguntas. Posteriormente, hace una estimacin global del proyecto para cada fase del mismo, haciendo comparaciones con otros proyectos previos indicados por el usuario. Su principal ventaja radica en el hecho de hacer estimaciones diferentes para cada una de las fases del proyecto [HEE92]. La naturaleza de esta herramienta se parece a la alternativa planteada en este proyecto para la estimacin de esfuerzo de proyectos software: a partir de informacin sobre proyectos completados obtenida de los ingenieros software, se buscan proyectos parecidos al que se quiere estimar, mediante comparaciones y clculos de distancia. Costar
29
Jess Desarrollado por Sofstar Systems, emplea el modelo COCOMO II para desarrollar estimaciones software. Cost Xpert Herramienta software que integra mltiples modelos de estimacin y una base de datos histrica de proyectos. Estimate Professional Basado en COCOMO II y el modelo de Slim. Knowledge Plan Utiliza la entrada de puntos de funcin como principal controlador para un paquete de estimacin completo. SEER/SEM Herramienta que proporciona adems de estimaciones, anlisis de sensibilidad y valoracin de riesgos.
1.6. COMPARATIVA DE LOS DIFERENTES MODELOS DE ESTIMACIN DE PROYECTOS SOFTWARE

Para un gestor de proyecto existen una serie de cuestiones clave cuya respuesta ser analizada comparando los diferentes modelos explicados en secciones anteriores del presente documento: Qu modelo de estimacin se debe usar. Qu medida de tamao de producto debe tomarse: lneas de cdigo o puntos de funcin.
30
Jess lvarez Sez
titulo
En general, se puede afirmar que no existe un mtodo que sea mejor que cualquier otro. Todos presentan una serie de ventajas e inconvenientes que hacen que la eleccin sea difcil. Gran cantidad de parmetros del proyecto y del mbito en el que se desarrolla hacen que el estimador se decida sobre un mtodo u otro. Por un lado, los modelos puramente algortmicos, que precisan de unas entradas concretas y utilizan ciertos factores y variables para producir las estimaciones, son mtodos muy objetivos, sujetos a operaciones matemticas y que producen resultados similares con proyectos igualmente parecidos. Sin embargo, no prestan ninguna atencin a circunstancias
excepcionales que puedan ocurrir en torno al desarrollo del proyecto, y rechazan tambin las opiniones subjetivas de expertos o de desarrolladores doctos en su materia (solamente intervienen para calibrar factores en niveles, tarea en ocasiones muy difcil de realizar). Esta falta de atencin hacia factores externos y personales, se puede compensar con la eficiencia que presentan los clculos necesarios para la estimacin. Globalmente podemos concluir que los mtodos algortmicos son idneos en proyectos con escasas alteraciones accidentales y del entorno, as como para equipos de desarrollo estables, que se enfrentan a productos relativamente sencillos y con pocos factores de costo, que faciliten la aplicacin del mtodo en cuestin. Por otro lado, si el estimador se decanta por el juicio experto, tendr gran cantidad de opiniones subjetivas, y se tendrn en cuenta las circunstancias especiales en las que se crea el producto software, pero es excesiva la dependencia de los expertos, as como de la eleccin de los mismos y de la comunicacin establecida con ellos. Adems, en ocasiones puede ser muy difcil adoptar la postura de un experto y hacer uso de su conocimiento, llegando el momento en el que sus
31
Jess decisiones se vuelvan demasiado generales e inaplicables a la situacin que atraviese el proyecto. A pesar de estos problemas, esta tcnica resulta ideal para las primeras fases de desarrollo del producto, cuando las especificaciones son difusas y deben ser continuamente adaptadas. Las estimaciones hechas en estas etapas son unos muy buenos indicadores del tiempo y del esfuerzo que puede llegar a ser necesitado. Acerca de los anlisis descendentes o top-down, podemos destacar su eficiencia y su capacidad de centrarse en diferentes partes del sistema. Resulta crucial la divisin que se haga del proyecto, as como las estimaciones hechas para cada unidad. Una mala estimacin en alguna parte puede hacer que al sumarse todas se obtengan resultados no muy fiables y que conlleven errores en las previsiones. Por desgracia, realizar esta divisin no es una tarea fcil. Por el contrario, las filosofas ascendentes (bottom-up) ofrecen un mayor nivel de detalle y estabilidad, pero pueden caer en el grave error de sobrepasar y desestimar ciertos niveles del sistema, cuyo coste deba ser valorado. La solucin a este error pasa por una fuerte supervisin del proceso, que acarrea gran cantidad de esfuerzo y atencin. Si tratamos con un producto fcilmente separable en partes, y se pueden hacer estimaciones cmodas sobre dichas porciones, se aconseja el uso de tcnicas descendentes. Si ocurre que dividir el sistema en partes supone un gran esfuerzo y trabajo a la organizacin, se debe rechazar el anlisis por partes, y optar por filosofas de estimacin ascendentes. No obstante, una de las opciones ms recomendada es utilizar varias tcnicas simultneamente, comparando los resultados e iterando los procesos de estimacin. La combinacin de tcnicas depender del nivel de detalle a alcanzar. Como posibles combinaciones encontramos, por ejemplo, estimaciones descendentes junto con juicio experto, aplicando analoga si se
32
Jess lvarez Sez
titulo
dispone de informacin suficiente, o mtodos algortmicos cuyas entradas sean aportadas por filosofas ascendentes. En la siguiente tabla pueden observarse de manera resumida todas estas ventajas e inconvenientes comentados anteriormente:
MODELO DE ESTIMACIN APLICACIN IDNEA Proyectos con escasas alteraciones accidentales, con equipos de desarrollo estables y productos sencillos
VENTAJAS Entradas y parmetros concretos Objetividad Eficiencia en clculos Gran cantidad de opiniones subjetivas Consideracin de circunstancias excepcionales Eficiencia Capacidad de centrarse en diferentes partes del sistema Mayor nivel de detalle
INCONVENIENTES No prestan atencin a circunstancias excepcionales Rechazan opiniones subjetivas Dependencia de los expertos Posturas de expertos difciles de adoptar Decisiones inaplicables La divisin que se haga del proyecto es decisiva y no siempre fcil de determinar Se pueden desestimar ciertos niveles del sistema Gran cantidad de esfuerzo y atencin
Modelos algortmicos
Juicio experto
Primeras fases de desarrollo del producto
Anlisis descendentes
Proyectos con divisiones claras
Anlisis ascendentes
Proyectos muy difciles de dividir
Tabla 13: Ventas e inconvenientes de los modelos de estimacin
Otra de las cuestiones presentadas a los estimadores software hace referencia a la medida del tamao del proyecto. Normalmente se identifica SLOC como el mejor indicador de tamao, fcil de medir (aunque difcil de estimar), e intrnsecamente asociado al lenguaje de programacin utilizado. Desgraciadamente, el uso de lenguajes muy avanzados, de programacin basada en componentes reutilizables, o basados en objetos, convierten esta medida en algo ms inexacta, debido a la existencia de cdigo generado automticamente, o cdigo ya desarrollado en anteriores proyectos. En estas situaciones aparece puntos de funcin como un excelente indicador de tamao, ya que es totalmente independiente de la tecnologa empleada y puede ser calculado fcilmente en fases tempranas del proyecto. Su
33
Jess desventaja reside en ser ms abstracto y no directamente derivable del producto. Estas indicaciones hacen decantarnos por SLOC cuando se traten proyectos en lenguajes sencillos, y con no demasiadas funcionalidades, y puntos de funcin para productos con gran cantidad de componentes ya implementados y cdigo no generado manualmente por los desarrolladores. En la siguiente tabla se esquematizan estas ventajas e inconvenientes citadas:
MEDIDA DEL TAMAO APLICACIN IDNEA Proyectos con lenguajes sencillos y con no mucha funcionalidad Productos con gran cantidad de componentes reutilizados
VENTAJAS Fcil de medir Asociado al lenguaje de programacin Independiente de la tecnologa Calculado fcilmente en fases tempranas del proyecto
INCONVENIENTES Difcil de estimar No apropiado con lenguajes OO o basado en componentes es ms abstracto que SLOC No es directamente derivable del producto
SLOC
Puntos de funcin
Tabla 14: Ventajas e inconvenientes de SLOC y Puntos de funcin como indicadores de tamao
34
Jess lvarez Sez
titulo
35
Jess
CAPTULO 2
ESTIMACIN POR ANALOGA
Jess lvarez Sez
titulo
Jess
CAPTULO 2
ESTIMACIN POR ANALOGA
Contenidos 2.1. Justificacin del uso de la estimacin por analoga .................. 40 2.2. Proceso de estimacin por analoga .......................................... 40 2.2.1. Ajuste mediante algoritmos genticos ......................... 42 2.2.2. Ajuste por regresin hacia la media ......................... 43 2.3. Ventajas e inconvenientes de la estimacin por analoga ........ 45 2.4. Herramientas para la estimacin por analoga ......................... 47 2.4.1. ESTOR .......................................................................... 48 2.4.2. ANGEL ......................................................................... 48 2.5. Criterios de evaluacin .............................................................. 49
38
Jess lvarez Sez
titulo
39
Jess
Tal y como se ha expuesto en el captulo anterior, existe una gran

variedad de tcnicas y filosofas de estimacin, que permiten a las organizaciones prever y calcular la cantidad de esfuerzo y dinero necesarios para llevar a cabo el proyecto software en cuestin. De entre esta variedad, haciendo una comparativa resaltaba el hecho de no existir un mtodo mejor que cualquier otro, sino que todo es funcin del entorno y de las caractersticas del proyecto, as como del conocimiento que se tiene acerca del mismo. Para un estimador puede resultarle en ocasiones ms cmodo y fcil aplicar un mtodo de estimacin que simule el comportamiento humano en la realidad. Este mtodo es denominado estimacin por analoga, y se demuestra que obtiene resultados equiparables e incluso mejores que los obtenidos mediante otras formas ms extendidas, como el modelo COCOMO o la estimacin por puntos de funcin. La estimacin basada en analoga es el proceso por el cual se localizan uno o ms proyectos previos similares al que est siendo desarrollado y se derivan estimaciones a partir de ellos [CHI06]. Es fundamental en este proceso medir el grado de similitud del proyecto bajo examen con respecto a los almacenados en la base de datos de histricos. As podemos identificar los proyectos ms parecidos al actual y estimar a partir de ellos. No obstante, resulta obvio pensar que es prcticamente imposible que exista uno o varios proyectos exactamente iguales al que queremos estimar, por lo que no se debe utilizar directamente el esfuerzo asociado a estos proyectos. La solucin aportada consiste en aplicarle algn tipo de ajuste, en funcin de la distancia existente entre dicho proyecto obtenido como el ms parecido y el proyecto sobre el que vamos a hacer una estimacin. Para ajustar estos valores de esfuerzo de proyectos ya completados existen multitud de tcnicas, siendo una de las ms apropiadas la bsqueda del
40
Jess lvarez Sez
titulo
conjunto ptimo de factores a tener en cuenta para obtener la estimacin final. Los algoritmos ms potentes en este campo son los genticos, cuyo desarrollo simula el proceso de evolucin natural de las especies.
2.1. JUSTIFICACIN DEL USO DE LA ESTIMACIN POR ANALOGA

El uso de la analoga para la estimacin est apoyado y confirmado por diversos estudios empricos, que demuestran que se obtienen resultados ms exactos y consistentes que los obtenidos con mtodos como COCOMO y puntos de funcin. Gran cantidad de autores han examinado a fondo esta forma de estimacin, obteniendo unos muy buenos resultados. Estos anlisis se recogen en [ANG00], [HUA06], [JOR04], o [SHE97] Adems de sus buenos resultados, es uno de los mtodos ms usados por las organizaciones, tal y como se demuestra en un estudio con ms de 600 empresas de la industria del software [HEE92].
2.2 PROCESO DE ESTIMACIN POR ANALOGA

Para poder realizar una estimacin sobre un proyecto software utilizando la analoga, es necesario en primer lugar determinar cul o cules de los proyectos ya completados y almacenados en una base de datos son ms parecidos al que queremos estimar. Para realizar esta tarea, debe determinarse el criterio para establecer las distancias entre proyectos. Existen multitud de medidas de similitud entre ejemplares, siendo las ms usadas las distancias de Euclides, de Manhattan y de Minkowski. sta ltima viene determinada por la siguiente frmula:
41
Jess
m
d ( Pxi , Pyi ) =
i =1
Pxi Pyi
donde Px es el proyecto que est siendo estimado y Py es un proyecto de la base de datos; Pxi es el valor que toma el factor i en el proyecto Px, y Pyi el valor del mismo factor i pero en el proyecto Py; m es el nmero de factores de esfuerzo de los proyectos. Las distancias de Euclides y de Manhattan pueden tomarse como casos particulares de Minkowski cuando e vale 2 y 1, respectivamente. Por tanto, la expresin de la distancia de Manhattan quedara:
m
d ( Pxi , Pyi ) =
Y la distancia Eucldea:
i =1
Pxi Pyi
d ( Pxi , Pyi ) =
(P
m i =1
xi
Pyi )
Esta ltima expresin es la ms comn, ya que representa la distancia geomtrica entre dos puntos del espacio Eucldeo, muy usada en Matemticas. Mediante esta frmula de la distancia, podemos obtener ya el conjunto de proyectos ms parecidos al que est bajo examen. Lgicamente, este grupo estar formado por los ejemplares con la menor distancia al proyecto en cuestin. El nmero de proyectos anlogos a considerar puede variar entre ciertos valores. No obstante, debe tenerse en cuenta que escoger un nmero muy pequeo puede conducir a considerar solamente proyectos muy independientes del resto, y un nmero demasiado grande disminuye la potencia ofrecida por la analoga, al tomar como similares proyectos que apenas lo son.
42
Jess lvarez Sez
titulo
Algunos estudios afirman que no existen demasiadas diferencias en la exactitud de las estimaciones al considerar grupos de proyectos anlogos de diferentes tamaos [CHI06] [JEF00] [SHE97]. S es cierto que un incremento en el nmero de anlogos provoca un aumento del error relativo [CHI06], y los nmeros pequeos deben ser tomados con conjuntos de datos igualmente pequeos. Una vez obtenido el conjunto de proyectos similares, slo falta ajustar los valores de esfuerzo de dichos proyectos para poder estimar el del proyecto en cuestin. Existen multitud de tcnicas y mtodos de ajuste, comentndose a continuacin dos de los ms frecuentes.
2.2.1. Ajuste mediante algoritmos genticos

Este enfoque pretende escoger el mejor conjunto de caractersticas de los proyectos ms cercanos al que se quiere examinar, y realizar las estimaciones con ellas. Para seleccionar dicho grupo se deben calcular los errores producidos al estimar con sus componentes, y buscar aquel conjunto que minimice este error en la estimacin. En principio se podran obtener todos lo posibles conjuntos de caractersticas y seleccionar aquel que produzca el menor error en la precisin. Esto resulta fcil para proyectos con pocos factores de esfuerzo, pero por desgracia esta no es la situacin ms normal. Es frecuente que contengan multitud de caractersticas que hacen demasiado ineficiente la aplicacin de un algoritmo de fuerza bruta. A este problema se le han buscado muchas soluciones, siendo la ms apropiada el uso de algoritmos genticos. Un algoritmo gentico apropiado para esta seleccin estara formado por individuos que representan conjuntos de caractersticas de proyectos ya completados. Cada ejemplar tendra asociado un valor de error en la estimacin, de manera que con los operadores genticos y de mutacin se sucederan las generaciones, buscando siempre el individuo con menor error.
43
Jess Una vez identificado, se estimara el proyecto en cuestin sumndole al valor de esfuerzo del proyecto ms parecido el error del individuo ms fuerte de la poblacin. Con esto hemos conseguido identificar el conjunto de caractersticas ms apropiado para tener en cuenta a la hora de estimar, minimizando el error cometido [CHI06]. Este tipo de ajuste de las estimaciones es costoso en trminos de computacin y tiempo, y no ha sido empleado en la alternativa propuesta en este proyecto porque pensamos que con algoritmos y tcnicas ms simples se pueden alcanzar resultados equiparables. Por ello, se ha implementado una tcnica ms eficiente y rpida, basada en un fenmeno estadstico explicado a continuacin.
2.2.2. Ajuste por regresin hacia la media

La regresin hacia la media es un fenmeno estadstico ligado a aquellas variables cuyo coeficiente de correlacin es inferior al 100 %. Fue descubierto por Sir Francis Galton en el siglo XIX, cuando al medir la altura de padres e hijos observ que los padres muy altos tenan hijos que no lo eran tanto, y los padres de menor altura tenan hijos ms altos que ellos. La regresin hacia la media provoca que aquellas muestras que presentan caractersticas extremas dentro de una poblacin (outliers), se correspondan con otros individuos de caractersticas opuestas y tambin extremas, tendindose siempre al mantenimiento de la media del conjunto. Existen estudios que demuestran que la regresin hacia la media es muy frecuente en situaciones de la vida cotidiana, pero que en realidad pasa desapercibida para la mayora de la gente. Centrndonos en la estimacin de proyectos software por analoga, el fenmeno de la regresin hacia la media aporta un ajuste del esfuerzo asociado a aquellos proyectos que se han seleccionado como los ms parecidos al que se pretende estimar.
44
Jess lvarez Sez
titulo
La relevancia de este tipo de ajuste est en parte debida a la aleatoriedad ligada de manera intrnseca a cualquier proyecto de desarrollo software. Siempre existen eventos de difcil previsin, o incluso totalmente imprevisibles, que tienen consecuencias drsticas en el proceso de desarrollo, convirtiendo en errneas aquellas estimaciones que en principio se tomaron por fiables. Esta aleatoriedad provoca tambin que aquellos proyectos que presentan caractersticas similares no tengan valores de esfuerzo y tiempo igualmente parecidos, por lo que surge la necesidad de ajustar estos valores de los proyectos anlogos al que se va a estimar. Antes de realizar un ajuste por regresin hacia la media (RTM), deben valorarse dos importantes aspectos: la exactitud de la estimacin hecha a partir de los proyectos anlogos, y las situaciones extremas que pueden presentar sus caractersticas. Si el modelo de estimaciones es muy seguro, no se realizaran ajustes en los valores de esfuerzo de los proyectos anlogos, por muy diferentes que sean del resto de proyectos considerados. Si por el contrario el modelo no es muy fiable, es razonable buscar un valor estimado que se aproxime a la media del conjunto. La dimensin de este ajuste, depende de la naturaleza de los proyectos seleccionados como anlogos: ser mayor cuanto ms extremos sean los valores de sus caractersticas. El mtodo de ajuste aplicado se basa en la frmula desarrollada por Galton:
Pr oductividad = PCA + ( M PCA) (1 c) ,
siendo PCA la productividad de los proyectos anlogos, M la media del conjunto y c la correlacin entre la productividad de los proyectos anlogos y el actual [JOR03].
45
Jess
Esta frmula tiene en cuenta la distancia a la media de los proyectos considerados anlogos (M - PCA) y la correlacin histrica entre los valores de productividad del proyecto estimado y los ms similares (c). La aplicacin de este ajuste no es una tarea sencilla. Su uso requiere: que los proyectos incluidos en el clculo de la correlacin c sean representativos para la exactitud de la estimacin, que el grupo de proyectos similares tiendan hacia el mismo valor medio M, y que dicho valor sea conocido. De todas formas el ajuste RTM (Regression Toward the Mean) es muy aconsejable, sobre todo para proyectos que presenten unos valores muy extremos de productividad. Incluso en situaciones en las que la correlacin no sea muy buena, debe aplicarse este ajuste.
2.3. VENTAJAS E INCONVENIENTES DE LA ESTIMACIN POR ANALOGA

Como se ha citado en anteriores ocasiones, la estimacin por analoga es uno de los mtodos ms utilizados en las organizaciones de desarrollo software. Esto hace que existan multitud de estudios en los que se analiza la exactitud y fiabilidad de sus estimaciones. Estas investigaciones nos pueden ayudar a encontrar ventajas e inconvenientes planteadas por el uso de la estimacin por analoga. Entre sus ventajas podemos citar las siguientes: El mtodo de razonamiento empleado es similar al realizado por la mente humana. Las bsquedas por analoga son familiares para el estimador, que se siente cmodo usando esta alternativa. Es un modelo muy apropiado para aquellas situaciones en las que el dominio es difcil de modelar. Se sabe que existen multitud de factores que influyen en la cantidad de esfuerzo necesaria para completar un proyecto software. Sin embargo, lo que no siempre
46
Jess lvarez Sez
titulo
se sabe es cmo interactan estos factores entre s, o a qu factores se les debe otorgar mayor peso e importancia. Es en estas situaciones cuando la estimacin por analoga ofrece unos muy buenos resultados sin necesidad de tener un modelo claro o de saber exactamente cmo el esfuerzo est relacionado con otros factores de proyecto. Puede ser usado teniendo un conocimiento parcial del proyecto que se quiere estimar. La informacin que ms importa es la de proyectos ya completados y almacenados que se usan de conjunto de bsqueda para encontrar los ms parecidos al que est siendo estimado. Puede suavizar problemas debidos a la calibracin. La estimacin basada en la analoga proporciona buenas estimaciones incluso cuando se utilizan datos procedentes de otra organizacin, siempre y cuando el proyecto anlogo sea encontrado en el conjunto de datos que se use para la estimacin, y se midan las variables siguiendo un criterio uniforme y consistente en todo el conjunto, sea cual sea su procedencia. Mitiga problemas asociados con los outliers (elementos extremos). La existencia de proyectos muy diferentes al resto no afecta en las estimaciones hechas por analoga, si el proyecto a estimar no es en s un outlier. Si por el contrario tratamos con un proyecto que es un outlier, ya que contiene valores muy distintos de sus caractersticas, al menos se encontrarn proyectos similares tambin con caractersticas extremas, pudiendo completarse la estimacin sin problemas. Entre las principales desventajas de este mtodo de estimacin podemos citar: El proyecto seleccionado como anlogo puede no ser apropiado para la estimacin, ya que algunos de sus factores que afectan al
47
Jess
esfuerzo hayan cambiado radicalmente con el tiempo. Por estos motivos, el mantenimiento y actualizacin de las bases de datos de proyectos ya completados afecta profundamente al proceso de estimacin. Un estimador puede usar su juicio experto para excluir aquellos proyectos inapropiados, pero tambin puede utilizarlo para escoger uno similar a ciegas, sin justificacin alguna, existiendo la posibilidad de que tambin sea inapropiado. Esta caracterstica es propia del razonamiento humano, en el que se observa la tendencia a encontrar evidencias que confirmen nuestras opiniones, y rechazar situaciones contrarias. Normalmente en la estimacin por analoga se usa la distancia de Eucldes como criterio de seleccin de proyectos anlogos, otorgando el mismo peso a cada factor. A pesar de que los resultados obtenidos son excelentes, no hay nada que indique que este mtodo de pesado sea el idneo, existiendo la posibilidad de que algunos factores deban tener un mayor peso a la hora de calcular las distancias. Como alternativas la asignacin de pesos encontramos el juicio experto, los coeficientes de correlacin o los algoritmos genticos. Una vez determinado el proyecto anlogo, al estimador se le plantea la cuestin de ajustar su valor de esfuerzo. De nuevo el abanico de posibles ajustes es muy amplio, por lo que la eleccin de uno u otro se vuelve complicada, sobretodo al tener en cuenta las diferentes caractersticas del proyecto que se quiere estimar y del anlogo. Adems, se pueden escoger como anlogos 1, 2 e incluso 3 proyectos, ya que los resultados obtenidos en diversas experimentaciones afirman que apenas influye la eleccin de este nmero Resumiendo, la exactitud y precisin de las estimaciones hechas por analoga se apoya en 4 factores: la seleccin adecuada de un proyecto anlogo, la
48
Jess lvarez Sez
titulo
estrategia utilizada para encontrarlo, el tratamiento de las diferencias existentes entre el anlogo y el proyecto a estimar para realizar predicciones, y la fiabilidad del conjunto de datos usado. Todas estas ventajas e inconvenientes del uso de la estimacin por analoga, se muestran de manera abreviada en la tabla 15.
2.4. ANALOGA
HERRAMIENTAS
PARA
LA
ESTIMACIN
POR
Hasta ahora se ha seguido un enfoque terico para explicar la tcnica de estimacin por analoga de proyectos software. Por otra parte, se ha comentado cmo este mtodo es uno de los ms extendidos y utilizados en la actualidad por las empresas de desarrollo software. Como apoyo a estas afirmaciones, se presentan a continuacin las herramientas software ms utilizadas para los procesos de estimacin.
VENTAJAS El mtodo de razonamiento es similar al empleado por la mente humana Es apropiado para situaciones con un dominio difcil de modelar. Se puede aplicar sin necesidad de conocer completamente el proyecto a estimar Suaviza problemas asociados a la calibracin. Tolera la existencia de outliers. INCONVENIENTES El proyecto seleccionado como anlogo puede no ser apropiado para la estimacin. El estimador segn su juicio personal puede escoger proyectos anlogos no recomendables, o excluir aquellos que s sean vlidos. Existe controversia sobre cul es el mejor mtodo de clculo de similitud. No existe un mecanismo de ajuste del esfuerzo del proyecto anlogo mejor que otro.
Tabla 15: Ventajas e inconvenientes de la estimacin por analoga
2.4.1. ESTOR
ESTOR es una herramienta de razonamiento basada en casos, utilizada para la estimacin de esfuerzo en proyectos software. Fue desarrollada en 1992 por Mukhopadhyay, Vicinanza y Prietula y maneja como mtricas los puntos de funcin y algunos parmetros del modelo intermedio de COCOMO [MUK92].
49
Jess
Los casos utilizados por esta herramienta son proyectos software y cada uno se representa mediante los valores de sus medidas. Las mtricas que utiliza son puntos de funcin y algunos parmetros utilizados con el modelo intermedio de COCOMO. Se recupera un slo caso como anlogo, basndose en el valor de los puntos de funcin del proyecto a estimar. La solucin inicial aportada por ESTOR es el valor de esfuerzo para el proyecto anlogo. Sin embargo, para tener en cuenta las diferencias existentes con el proyecto que se va a estimar, se le aplican una serie de ajustes tomando como gua un conjunto de reglas derivadas de las opiniones de un experto.
2.4.2. ANGEL
ANGEL (ANaloGy SoftwarE tooL) es una herramienta que tambin realiza estimaciones basndose en la analoga de proyectos software aunque, en comparacin con otras herramientas, dota de una mayor libertad al usuario para configurar a su medida el proceso de estimacin. En primer lugar, el estimador puede escoger cualquier conjunto de datos que est disponible para realizar la bsqueda de los proyectos anlogos. Una vez establecido el conjunto de datos, se seleccionan las variables que se van a tener en cuenta a la hora de buscar analogas. Este conjunto de variables lo puede determinar el usuario, o bien se puede ordenar a ANGEL que encuentre el mejor subconjunto de caractersticas a tener en cuenta, minimizndose as los errores y el ruido. Tras estos pasos ANGEL devuelve un conjunto de proyectos anlogos al que se est estimando, ordenados por distancias. El valor de esfuerzo ofrecido es la media de esfuerzo del conjunto de anlogos, de modo que si el usuario decide utilizar grupos de un elemento, se dar su valor de esfuerzo como estimacin, y se decide que sean por ejemplo 4, se calcular la media de sus esfuerzos.
2.5. CRITERIOS DE EVALUACIN
50
Jess lvarez Sez
titulo
Una vez hechas las estimaciones y desarrollados los proyectos, se deben tomar medidas de la exactitud del modelo de estimacin empleado. Para esta labor, existen tres magnitudes fundamentales: el MMRE (mean magnitude of relative error), MdMRE (median magnitud of relative error), y Pred(0,25). La frmula general del MMRE es:
1 n Ax x MMRE = , n x =1 Ax
que calcula la media de los errores cometidos siendo Ax el valor actual del esfuerzo para el proyecto que se est estimando, y x el esfuerzo estimado con el error ya aadido. Un valor aceptable para esta medida ronda el 25 %, que indica que como media la exactitud de los modelos de estimacin aplicados es menor a un 25 % [CHI06]. Otro criterio muy usado el Pred(l), que representa el porcentaje de MRE (magnitude of relative error) menor o igual al valor l, de entre todos los proyectos. Su frmula es muy simple:
k , n
Pr ed (l ) =
Siendo n el nmero total de observaciones y k el nmero de observaciones en las que MRE es menor o igual al valor l. Normalmente, l suele tomar valor 0.25, indicando por tanto Pred(0.25) el porcentaje de proyectos con un MMRE menor o igual al 25 %.
51
Jess
CAPTULO 3
ESTUDIO DE ALGORITMOS DE CLASIFICACIN PARA LA ESTIMACIN
Jess lvarez Sez
titulo
Jess
CAPTULO 3
ESTUDIO DE ALGORITMOS DE CLASIFICACIN PARA LA ESTIMACIN
Contenidos 3.1. Representacin de los datos ....................................................... 56 3.1.1. Descripcin de los datos utilizados .............................. 58 3.1.2. Normalizacin de los datos .......................................... 57 3.2. Algoritmo kNN .......................................................................... 62 3.2.1. Medida de similitud ..................................................... 3.3. Estimacin basada en analoga ................................................. 63
Jess lvarez Sez
titulo
Jess
n el presente captulo se explicar con detalle la implementacin
del modelo de estimacin por analoga propuesto en el proyecto, basado en la utilizacin de algoritmos de clasificacin de instancias previos a la estimacin, y en el ajuste de las estimaciones por regresin hacia la media. Anteriormente fueron revisados varios ajustes que pueden aplicarse a las estimaciones de proyectos software hechas basndose en la analoga. De entre ellos, para la implementacin de este sistema ha sido escogido el ajuste por regresin hacia la media por su sencillez y por los buenos resultados que ofrece en este tipo de estimaciones. Sin embargo, previo a este ajuste se realizan una serie de pasos que se apoyan en medidas de similitud y en algoritmos de seleccin de elementos anlogos a uno determinado. En nuestra propuesta se ha utilizado como medida de similitud entre proyectos la medida del coseno, muy apropiada para una representacin vectorial de los datos. De entre todos los algoritmos de seleccin de anlogos, ha sido implementado el kNN, o k vecinos ms cercanos. Existen multitud de posibilidades de implementacin para este tipo de sistemas, pero se ha credo conveniente la utilizacin de algoritmos y medidas sencillas y de gran potencia y precisin, con las que se pretender alcanzar unas buenas estimaciones, con bajas cotas de error. Adems, los buenos resultados conseguidos por estas medidas de similitud y estos algoritmos de clasificacin en otros mbitos han hecho decantarnos por esta alternativa, pretendiendo alcanzar resultados equiparables a los obtenidos en anteriores investigaciones, con un bajo costo computacional y temporal, gracias a la eficiencia intrnseca de las operaciones y tcnicas empleadas. Como la evaluacin de los resultados se har en funcin de los errores cometidos al estimar, no es necesario escatimar a la hora de escoger un lenguaje de programacin, ya que la eficiencia y el tiempo no van a ser valorados. Por estos motivos, buscndose la potencia y la comodidad de la programacin, se ha
56
Jess
escogido el lenguaje Java, que adems aporta una buena precisin en todos los clculos matemticos requeridos para el desarrollo de este estudio. En definitiva, la propuesta de este proyecto se basa en la utilizacin de un algoritmo de clasificacin como kNN previo a la estimacin de esfuerzo en proyectos software, con el objetivo de obtener los ejemplares ms parecidos al proyecto objeto de estudio. Una vez obtenido este conjunto de anlogos, se realizar una primera estimacin segn dichos elementos, y este valor calculado ser posteriormente ajustado mediante regresin hacia la media, con una simple operacin matemtica. En la ilustracin 2, podemos observar el proceso seguido por la alternativa de estimacin propuesta:
Datos originales de proyectos

Normalizacin
Datos normalizados
kNN
Estimacin sin ajustar
4
Regresin hacia la media
Estimacin definitiva
Analoga
Proyectos clasificados
Ilustracin 2: Diagrama de secuencia de la estimacin por analoga
57
Jess
3.1. REPRESENTACIN DE LOS DATOS

Los datos necesarios para entrenar y realizar las pruebas del modelo de estimacin hacen referencia a proyectos software, donde cada elemento est determinado por un identificador de proyecto, posee una serie de parmetros cuantificados numricamente, y adems tiene asociado un esfuerzo total de desarrollo, que ser el parmetro sobre el que se realizarn las estimaciones. Esto hace que los proyectos puedan ser representados mediante una clase, con un identificador de proyecto, un esfuerzo y un vector de valores que representan cada una de las caractersticas disponibles de dicho proyecto. Esta representacin de los parmetros de los proyectos nos va a facilitar mucho los clculos, ya que pueden aplicarse fcilmente medidas de similitud y cercana entre elementos en un espacio vectorial de n dimensiones, siendo n el nmero de parmetros conocidos de cada proyecto. Adems, para el ajuste que se har para la estimacin es necesario conocer la correlacin entre algunas caractersticas, por lo que de nuevo la representacin vectorial se presenta como idnea para dicha tarea. En un principio no se dispona de datos reales con los que probar el modelo de estimacin planteado, por lo que se decidi generar de manera aleatoria los datos de cada proyecto a utilizar. Con esto conseguimos obtener de una manera rpida la informacin con la que entrenar y probar el sistema, pero surge un problema: no existe relacin entre las caractersticas de los proyectos y sus esfuerzos, ya que son todos nmeros aleatorios. Esta situacin obliga a utilizar datos reales de proyectos software, que sern igualmente almacenados y tratados.
3.1.1. Descripcin de los datos utilizados

Los datos sobre proyectos software ya completados han sido obtenidos de una organizacin internacional, la ISBSG (Internacional Software Benchmarking Standards Group), que pone a disposicin un repositorio de
58
Jess
datos sobre 2047 proyectos software. La informacin de cada uno de estos proyectos ha sido voluntariamente proporcionada por sus responsables a la ISBSG, de manera totalmente gratuita. Para cada proyecto software se han considerado los siguientes atributos: Identificador de proyecto: la ISBSG asigna a cada proyecto completado un identificador nico. Valor ajustado de puntos de funcin: este valor final de puntos de funcin ha sido ajustado segn el valor del atributo explicado a continuacin. Valor de ajuste de los puntos de funcin: es un nmero utilizado para ajustar la cuenta de puntos de funcin de cada proyecto. Esfuerzo total del proyecto expresado en horas. Este es el valor que ser estimado por nuestra alternativa. Mtodo de conteo del esfuerzo: este parmetro indica la manera en que se ha tomado el nmero de horas empleadas para desarrollar el proyecto (conteo diario, porcentaje de horas dedicadas al proyecto, tiempo de desarrollo slo). Nivel del recurso: este parmetro indica qu parte de la organizacin ha sido la que ha empleado el nmero de horas indicado en el parmetro del esfuerzo total para completar el proyecto (equipo de desarrollo, cmputo, usuarios finales, etc.). Tamao mximo de los equipos involucrados en el desarrollo del proyecto. Tipo de desarrollo: puede ser nuevo, de mejora o hecho a partir de otro proyecto anterior. Plataforma de desarrollo: toma valores como PC, main frame o plataforma intermedia.
59
Jess
Tipo de lenguaje empleado: de primera generacin, segunda, tercera, etc.
Lenguaje de programacin. Utilizacin de alguna base de datos. Utilizacin de herramientas Upper CASE: herramientas que ayudan en las fases de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
Utilizacin de herramientas Lower CASE: herramientas que semiautomatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin.
Utilizacin de herramientas Coger CASE no generadoras de cdigo.
Uso de herramientas CASE ya integradas en el sistema. Uso de alguna metodologa especfica de programacin. Tiempo de desarrollo transcurrido, expresado en meses. Tiempo en el que el proyecto estuvo detenido por cualquier razn, expresado en meses.
Nmero de defectos muy graves detectados en el primer mes de uso del producto.
Nmero de defectos graves detectados en el primer mes de uso del producto.
Nmero de defectos leves detectados en el primer mes de uso del producto.
Indica si el proyecto es parte de un paquete software.
60
Jess
Esfuerzo empleado en la planificacin del proyecto, expresado en horas.
Esfuerzo empleado en la especificacin del proyecto, expresado en horas.
Esfuerzo empleado en la construccin del producto, expresado en horas.
Esfuerzo empleado en la fase de test del producto, expresado en horas.
Esfuerzo empleado en la implementacin del producto, expresado en horas.
Entradas de usuario, para los puntos de funcin. Salidas de usuario. Peticiones de usuario. Ficheros de lgica interna. Ficheros externos de interfaz. Puntos de funcin aadidos. Puntos de funcin cambiados. Puntos de funcin eliminados de la cuenta total. Nmero de lneas de cdigo. Suma total de defectos encontrados. Suma total de esfuerzo por fases. Esfuerzo de aquellos proyectos que no han completado todas sus fases.
Nmero de puntos de funcin sin ajustar.

61
Jess
Fiabilidad otorgada por la organizacin a la cuenta de los puntos de funcin sin ajustar.
Sin embargo, en la base de datos original de ISBSG existen otros atributos que no han sido incluidos en este estudio, al considerar que no influyen en el valor de esfuerzo necesario para completar el proyecto, como por ejemplo el pas donde se realiz el proyecto, su fecha de inicio y finalizacin o el mbito de la empresa desarrolladora. Los datos utilizados han sido normalizados segn la expresin indicada en el siguiente punto, antes de ser tratados por el algoritmo de clasificacin. Adems, como existen atributos desconocidos en varios proyectos, se ha asignado un valor -1 para dichas situaciones, de manera que el clculo de las distancias y de las estimaciones no tenga en cuenta aquellas caractersticas desconocidas en algn proyecto.
3.1.2. Normalizacin de los datos

Un factor fundamental que debe ser tenido en cuenta a la hora de almacenar los datos, es la necesidad de que estn expresados en el mismo intervalo, es decir, que cada caracterstica de los proyectos est expresada en un rango igual para todos ellos. Por ello, a los datos se les debe aplicar primeramente una normalizacin segn la siguiente expresin:
xx
x' =
donde x es el valor que toma un parmetro en un determinado proyecto, x es la media de ese parmetro y es su desviacin tpica.
62
Jess
Con esto conseguimos que las medidas de distancia empleadas sean mucho ms coherentes y no se den como parecidos aquellos proyectos que en realidad no lo son. En el siguiente ejemplo podemos apreciar la necesidad de la normalizacin: Supongamos dos variables, una de ellas expresada con valores en torno a 1000, y la otra expresada con valores prximos al 5. Estos valores son la media de cada variable. Sin aplicar normalizacin, un elemento de caractersticas (1012, 5) ser muy parecido a otro formado por (1014, 7), sin darle importancia a la diferencia existente entre el 5 y el 7. esto hace que se le de un mayor peso o importancia a la primera caracterstica en lugar de a la segunda. Al aplicar normalizacin, la diferencia existente entre el valor 5 y el 7 de ambos elementos se agudiza, por lo que se aumenta la distancia existente entre ellos. La aplicacin de esta normalizacin, concluye la etapa 2 de la ilustracin 2, que muestra el proceso del modelo planteado.
3.2. ALGORITMO kNN

k-Vecinos ms cercanos (del ingls k Nearest Neighbours) es uno de los algoritmos ms utilizados para clasificar instancias. Est basado en la bsqueda de los k elementos ms parecidos a uno dadoEn nuestra propuesta, dicho algoritmo se encargar de seleccionar los proyectos ms parecidos al que se quiere estimar, para obtener a partir de ellos un valor aproximado de esfuerzo para el proyecto bajo anlisis.
63
Jess
Esta seleccin de elementos parecidos implica la necesidad de utilizar una determinada medida de similitud entre instancias, que en este sistema ser la medida del coseno, explicada posteriormente. Para alcanzar nuestro objetivo de encontrar los k proyectos ms parecidos a uno dado, el algoritmo kNN implementado sigue los siguientes pasos: Se selecciona un proyecto. Para cada uno de los proyectos restantes: o Se calcula la distancia que lo separa del proyecto elegido. o Esta distancia se introduce en un mapa ordenado, siendo la clave el valor del coseno. Se escogen los k elementos con mayor valor de similitud.
Al final de este algoritmo, obtendremos una matriz n x k, donde n es el nmero de proyectos evaluados, y las k columnas contienen los proyectos que ms se le parecen. Con esta matriz podemos comenzar a realizar las estimaciones basadas en la analoga (fin de la etapa 3, ilustracin 2).
3.2.1. MEDIDA DE SIMILITUD

Existen multitud de medidas empleadas para determinar el grado de cercana entre elementos de un espacio vectorial, pero dada la naturaleza de los datos y su representacin, se ha escogido razonadamente la medida del coseno. Este coeficiente indica el valor del coseno formado por dos elementos del espacio vectorial como medida de similitud entre ambos. Su expresin es bien sencilla:
64
Jess
n
s ( x, y ) =
x y
i =1 i n n i =1 2 i
x yi2
i =1
donde xi e yi son el valor que adquiere la propiedad i en los proyectos x e y, cada uno de n caractersticas. El valor que alcanza esta medida en caso de mxima similitud es de 1, no pudiendo rebasa nunca este valor. El caso contrario ocurre cuando el valor del coseno vale 0, lo que implica la mxima diferencia entre proyectos. Para aquellas caractersticas expresadas mediante valores numricos, la aplicacin de la frmula no requiere ningn tratamiento especial. Sin embargo, si una variable queda expresada mediante letras, tomndose cada letra como identificadora de un tipo o clase, se debe definir una funcin de distancia, que determine cuando dos caractersticas son iguales. En nuestro sistema, esta funcin es bien sencilla:
1 si d ( A, B) = 0 si
A= B A B
Con el valor ofrecido por la frmula del coseno para un determinado proyecto con respecto a los dems, podemos seleccionar los que ms se le parecen.
3.3. ESTIMACIN BASADA EN LA ANALOGA

Para poder realizar una estimacin del esfuerzo necesario para completar un proyecto software, se necesita primero conocer los esfuerzos de los k proyectos determinados como ms cercanos por el algoritmo anterior.
65
Jess
La estimacin por analoga en primer lugar aporta un valor estimado que es igual al esfuerzo del proyecto ms cercano, en nuestro sistema a la media de, como mximo, los 3 ms cercanos (fin de la etapa 4, ilustracin 2). Este es un valor indicativo del esfuerzo del proyecto, que debe ser ajustado para tener en cuenta las diferencias existentes con sus vecinos ms cercanos. Para realizar este ajuste, existen gran cantidad de tcnicas y procedimientos, que pasan por redes neuronales, algoritmos genticos, redes bayesianas, etc. Nuestro alternativa implementa un ajuste sencillo y matemticamente muy simple, pero con unos resultados muy buenos, sobretodo al ser aplicado sobre proyectos homogneos y expresados vectorialmente. El ajuste utilizado se basa en un fenmeno estadstico y se denomina ajuste por regresin hacia la media, y fue explicado ampliamente en el anterior captulo del presente documento. La expresin que adopta el ajuste es la siguiente:
Esfuerzo = ECA + ( M ECA) (1 c) ,
siendo ECA el esfuerzo asociado a los proyectos ms cercanos dentro de los anlogos, M la media del conjunto y c la correlacin existente entre los valores reales de esfuerzo y los predichos por la analoga. Este sencillo ajuste no pierde vista la existencia de elementos con caractersticas extremas, y procura ofrecer valores que tiendan a mantener la media del conjunto. En las primeras implementaciones de nuestro sistema de estimacin, se tom M como la media de todos los proyectos existentes, observndose la tendencia a predecir valores muy parecidos en general para todos los proyectos, y haciendo que en multitud de ocasiones el error cometido fuese muy grande. Por eso, en posteriores revisiones y mejoras se limit el clculo de la media a los
66
Jess
k vecinos ms cercanos, con lo que se disminuy considerablemente el error obtenido en las estimaciones.
67
Jess
CAPTULO 4
DISEO DE LAS PRUEBAS Y RESULTADOS OBTENIDOS
Jess
Jess
CAPTULO 4
DISEO DE LAS PRUEBAS Y RESULTADOS OBTENIDOS

Contenidos 4.1. Parmetros de configuracin de las pruebas ............................ 69 4.2. Desarrollo de las pruebas .......................................................... 70 4.3. Resultados obtenidos ................................................................ 72
Jess
Jess
A lo
largo de este captulo, se realizarn diversas pruebas de
estimacin siguiendo el modelo propuesto a lo largo de este documento. Los resultados obtenidos en cada ejecucin sern analizados y comparados para determinar cules son los valores que deben tomar los parmetros de los algoritmos de clasificacin y de las tcnicas de estimacin utilizadas. Con una base de datos tan grande como la que disponemos para la realizacin de este proyecto, no se pueden ir realizando pruebas con parmetros elegidos sin un anlisis y planificacin previa, ya que podramos no conseguir resultados aceptables, y realizar experimentos que aporten informacin de escaso valor. En este tipo de sistemas en los que se realizan predicciones acerca del valor que tomarn ciertos parmetros, es muy importante el entrenamiento al que se somete el programa, y los resultados obtenidos se ven con frecuencia afectados por los parmetros del algoritmo empleado, en nuestro caso por el nmero k de vecinos seleccionado. De entre todas las tcnicas existentes para el entrenamiento de este tipo de modelos, se ha escogido la validacin hold-out, que se basa en la divisin de la base de datos en dos conjuntos disjuntos, llamados conjunto de test y de entrenamiento. El primero de ellos tiene menor tamao, y contiene los elementos que sern evaluados, utilizando para realizar dicha evaluacin los contenidos en el segundo grupo. Esta tcnica presenta como principal ventaja la eficiencia, ya que otras tcnicas, como la validacin cruzada (cross validation), requiere que sean evaluados todos los ejemplares de la base de datos, lo que acarrea un gran esfuerzo computacional, sobre todo en situaciones en las que existe una cantidad considerable de ejemplares a examinar. Adems, en hold-out el conjunto de test se crea aleatoriamente, realizndose una buena evaluacin del modelo si se ejecuta varias veces.
72
Jess
Los tamaos de los conjuntos de test y de entrenamiento tambin adquieren gran relevancia, por lo que deben ser combinados de diversas formas para obtener multitud de resultados, y poder escoger as la configuracin que alcanza menores cotas de error en las estimaciones.
4.1. PRUEBAS
PARMETROS
DE
CONFIGURACIN
DE
LAS
El conjunto de todos los datos de proyectos software ser dividido en dos conjuntos disjuntos de diferente tamao. Uno de ellos ser el conjunto de test, formado por proyectos cuyo valor de esfuerzo ser estimado. Para poder realizar esta estimacin, ser necesaria una base de informacin de proyectos con los que trabajar para seleccionar los vecinos ms cercanos y hacer el ajuste por analoga. Este grupo de proyectos utilizados para tal efecto es el denominado conjunto de entrenamiento. Se deben por tanto disear pruebas con distintos tamaos del conjunto de test y de entrenamiento, siendo preferible un menor tamao del de test, para poder tener as muchos proyectos para entrenar y realizar las estimaciones. Otro parmetro del sistema que se debe tener en cuenta es el nmero de vecinos ms cercanos que se seleccionarn para cada proyecto del conjunto de test y poder as realizar las estimaciones. Este parmetro tomar obviamente valores menores que el tamao del conjunto de entrenamiento, ya que no se pueden seleccionar ms vecinos de los que hay en dicho conjunto. Se observar en los experimentos que para valores muy altos del nmero de vecinos seleccionados se introduce mucho ruido en las estimaciones. Adems, dada la naturaleza del ajuste hecho a la estimacin, que tiene en cuenta la media de esfuerzo de los k vecinos, este ruido en teora se debe ver incrementado.
73
Jess
Por el contrario, valores muy pequeos del nmero de vecinos pueden hacer que el valor estimado del esfuerzo sea prcticamente igual que el de sus anlogos, perdiendo de vista las diferencias existentes entre ellos. Un tercer parmetro que ser combinado con los anteriores es el nmero de proyectos ms parecidos de entre los k seleccionados por kNN, con los que se calcular una primera estimacin sin ajustar, a la que se le aplicar posteriormente el ajuste por regresin hacia la media. En la tabla 16 se pueden ver reflejados los valores que tomarn estos tres parmetros de configuracin de las pruebas, que al combinarlos entre s se forman 36 experimentos en total.
4.2. DESARROLLO DE LAS PRUEBAS

Una vez establecidos los parmetros de configuracin de las pruebas, comenzar el desarrollo de las mismas. En primer lugar, se dividir el conjunto de todos los proyectos en dos grupos: el de test y el de entrenamiento. Para ello se seleccionarn aleatoriamente n proyectos, siendo n el tamao del conjunto de test. El conjunto de entrenamiento ser creado incluyendo en l todos aquellos proyectos que no formen parte del grupo de test.
NMERO DE MS CERCANOS DE ENTRE LOS K SELECCIONADOS 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2
TAMAO DEL CONJUNTO DE TEST
NMERO DE VECINOS SELECCIONADOS
NOMBRE DEL EXPERIMENTO Prueba 1 Prueba 2 Prueba 3 Prueba 4 Prueba 5 Prueba 6 Prueba 7 Prueba 8 Prueba 9 Prueba 10 Prueba 11 Prueba 12 Prueba 13 Prueba 14 Prueba 15 Prueba 16 Prueba 17
k=5
k=10 10 % k=20
k=50 20 % k=5 k=10
74
Jess
3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 Prueba 18 Prueba 19 Prueba 20 Prueba 21 Prueba 22 Prueba 23 Prueba 24 Prueba 25 Prueba 26 Prueba 27 Prueba 28 Prueba 29 Prueba 30 Prueba 31 Prueba 32 Prueba 33 Prueba 34 Prueba 35 Prueba 36
k=20
k=50
k=5
k=10 30 % k=20
k=50
Tabla 16: Pruebas diseadas
Con esto realizado, se comenzar a seleccionar para cada elemento del conjunto de test, los k elementos ms parecidos a l provenientes del conjunto de entrenamiento. Una vez determinados estos proyectos, se realizar una estimacin de su esfuerzo mediante analoga, realizando posteriormente el ajuste por regresin hacia la media. Cuando se tengan hechas las estimaciones de cada proyecto del conjunto de test, se proceder al clculo del error cometido, a travs de la siguiente expresin:
1 n ER EE MMRE = n i =1 ER
donde ER es el esfuerzo real de proyecto, EE el esfuerzo estimado y n el nmero de proyectos del conjunto de test. Este MMRE (Mean Magnitude of Relative Error), es el error cometido por el experimento, que nos servir para determinar al final cul es la mejor configuracin de los mismos. Es una medida muy comn para mostrar la eficiencia de las estimaciones en Ingeniera Software.
75
Jess
Como la creacin de los conjuntos de test y entrenamiento es aleatoria, cada experimento ser realizado 20 veces, obtenindose al finalizar todas las ejecuciones la media de los MMRE obtenidos en cada iteracin. Otra medida que ser tenida en cuenta a la hora de realizar las ejecuciones, es el nmero de ocasiones en los que el ajuste por regresin hacia la media realizado a cada estimacin ha conseguido un valor de esfuerzo ms cercano al real que el aportado inicialmente teniendo en cuenta slo los elementos ms parecidos.
4.3. RESULTADOS OBTENIDOS

Antes de comenzar a comentar los resultados obtenidos en las ejecuciones, es conveniente mostrar los porcentajes de tamao de los conjuntos de test y de entrenamiento considerados para realizar las pruebas, as como el nmero de proyectos incluidos en cada caso. En la tabla 17 se puede observar la distribucin de estos tamaos, segn los porcentajes asignados a cada uno de los conjuntos. Los conjuntos de test y de entrenamiento creados para cada prueba no poseen ningn elemento en comn, y engloban la totalidad de los proyectos de la base de datos, en total 2027.
PORCENTAJE CONJUNTO TEST / TRAINING 10 % - 90 % 20 % - 80 % 30 % - 70 % NMERO DE ELEMENTOS CONJUNTO TEST 203 406 608 NMERO DE ELEMENTOS CONJUNTO TRAINING 1824 1621 1419
Tabla 17: Tamaos de los conjuntos de Test y Entrenamiento
En la tabla 18 pueden observarse los resultados de las pruebas, con los MMRE obtenidos y los porcentajes de mejoras en las estimaciones gracias al ajuste por regresin.
ESTIMACIONES HECHAS 4060 MEJORAS POR REGRESIN 2684
PRUEBA 1
MMRE 1.4240353
% MEJORAS 66.1084%
76
Jess
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 0.9248598 0.88683033 1.2652854 0.9283263 1.1535473 1.0953348 1.1732101 0.84652203 0.9617287 1.0202768 1.0323083 1.07788 1.024119 0.950191 1.2807004 1.0464857 0.93076813 0.9554926 0.958801 1.0361177 1.2096382 1.0122854 1.0188601 1.2203498 0.9988824 0.95995396 1.1595623 1.034171 1.0339931 1.1660955 0.93949234 0.89622515 1.1606127 1.0452673 0.95805824 4060 4060 4060 4060 4060 4060 4060 4060 4060 4060 4060 8120 8120 8120 8120 8120 8120 8120 8120 8120 8120 8120 8120 12160 12160 12160 12160 12160 12160 12160 12160 12160 12160 12160 12160 2441 2281 2836 2477 2352 2719 2523 2329 2565 2387 2300 5549 4891 4535 5533 4905 4755 5375 4844 4699 5224 4759 4475 8257 7360 6786 8353 7596 7085 8113 7278 7021 7949 7209 6908 60.1232% 56.1823% 69.8522% 61.0099% 57.9310% 66.9704% 62.1429% 57.3645% 63.1773% 58.7931% 56.6502% 68.3374% 60.2340% 55.8498% 68.1404% 60.4064% 58.5591% 66.1946% 59.6552% 57.8695% 64.3350% 58.6084% 55.1108% 67.9030% 60.5263% 55.8059% 68.6924% 62.4671% 58.2648% 66.7188% 59.8520% 57.7385% 65.3701% 59.2845% 56.8092%
Tabla 18: Resultados de las pruebas
En la tabla 19 se observan los valores medios obtenidos de MMRE y de mejoras por regresin hacia la media conseguidos con todas las ejecuciones
MEDIA TOTAL DE MMRE MEDIA TOTAL DE MEJORAS 1.049618561 61.3622%
Tabla 19: Media de los resultados obtenidos
Con estos resultados a la vista, podemos obtener un gran nmero de conclusiones. Primeramente podemos hacer referencia a los porcentajes de mejoras alcanzados por el ajuste por regresin hacia la media. Una primera estimacin nos ofrece el valor de esfuerzo de los proyectos ms parecidos dentro del conjunto de los k vecinos encontrados. Recordemos que segn las pruebas diseadas, se pueden escoger 1, 2 3 proyectos para realizar esta primera estimacin, basada tan slo en obtener la media de esfuerzo de estos elementos.
77
Jess
A este dato aportado se le aplica el ajuste por regresin hacia la media, y se comparan las diferencias existentes entre los dos valores estimados (uno sin ajuste y otro ajustado) con el valor real de esfuerzo del proyecto en cuestin. Pues bien, de este conteo de mejoras se deduce fcilmente la conveniencia de usar este tipo de ajuste, no slo por su buen porcentaje de resultados, sino por su eficiencia y sencillez, al estar basado en una simple operacin matemtica y un clculo del coeficiente de regresin lineal entre dos variables. En esta expresin del ajuste por regresin hacia la media, interviene la media de esfuerzo del conjunto. Este valor puede ser interpretado como la media de todos los proyectos contenidos en la base de datos, o como la media de los k proyectos seleccionados por el algoritmo kNN. En las primeras ejecuciones de las pruebas se tomaba como valor de media para el ajuste la media de toda la base de datos, observndose unos valores muy altos del MMRE, y extremadamente bajos del porcentaje de mejora en la estimacin. Esto provoc la sustitucin de este valor por el de la media del conjunto devuelto por kNN, aprecindose una notable mejora en todos los sentidos. Los malos resultados obtenidos por las estimaciones considerando la media de toda la base de datos no merecen ser reflejados en este documento, por la escasa informacin que aportan. Con respecto a los errores cometidos, medidos segn MMRE, podemos concluir la obtencin de unos resultados aceptables y comparables con los alcanzados por la literatura en este mbito [CHI06] [JOR03]. Existen muchas diferencias en las cotas de error alcanzadas en las estimaciones en funcin de los parmetros de la prueba, por lo que a continuacin se estudiar la influencia de cada uno de estos factores en los resultados de las mismas. El primer parmetro de configuracin que salta a la vista es el tamao del conjunto de test y del de entrenamiento. Se han considerado valores
78
Jess
pequeos para el conjunto de test, aportando cada uno de ellos unos resultados parecidos, como podemos apreciar en la tabla 20.
PORCENTAJE CONJUNTO TEST / TRAINING 10 % - 90 % 20 % - 80 % 30 % - 70 % MMRE 1.05935543 1.041778269 1.047721983 MEJORAS POR REGRESION 61.3588% 61.5445% 61.5538%
Tabla 20: Resultados obtenidos en funcin del tamao del conjunto de Test
Como norma general, las variaciones del MMRE y de los porcentajes de mejora no varan mucho en funcin del tamao del conjunto de test. Las medias se mantienen ms o menos parecidas, aunque si tuviramos que decantarnos por una configuracin quiz fuera conveniente hacerlo por la segunda, que ofrece un tamao del 20 % para el grupo de test, y que ofrece los valores ms bajos de MMRE, siendo las mejoras por regresin cercanas a las mejores, alcanzadas con un 10%. Una vez determinado que el tamao ptimo para el conjunto de test ronda el 20 %, debemos analizar el resto de parmetros de configuracin de las pruebas. Para ello la tabla 20 no nos sirve de mucho, por lo que para conseguir este objetivo puede interesarnos ms analizar los datos agrupados por dichos factores:
1.1 1.08 1.06 MMRE 1.04 1.02 1 0.98 0.96 5 10 K 20 50
Ilustracin 2: MMRE en funcin de k
79
Jess
Parece claro que k no debe tomar valores extremos, ni muy pequeos ni muy grandes. Esto se explica por dos motivos. En primer lugar, valores muy pequeos hacen que el ajuste por regresin hacia la media funcione peor, ya que toma como media la de un conjunto reducido. Con valores muy grandes, se introduce demasiado ruido en la estimacin, y asigna a proyectos que presenten unas caractersticas extremas valores de esfuerzo demasiado cercanos a la media. Por estos motivos, y tal y como se aprecia en la ilustracin 2 el valor idneo de k para el algoritmo kNN es 20. Esta decisin queda apoya por la ilustracin 3, en la que se observa un elevado nivel de mejoras en la regresin con un valor de k=20. Veamos ahora lo que ocurre con el nmero de proyectos ms cercanos a considerar dentro de los k seleccionados. Para ello podemos servirnos de la ilustracin 4, que, muestra una clara predileccin por valores altos, como el 3. La respuesta a esta predileccin radica en que apenas existen proyectos en la base de datos con caractersticas extremas. Esto hace que la estimacin inicial dada por los ms parecidos sea bastante buena de por s, vindose an mejorada por el ajuste por regresin.
80
Jess
63.5000% 63.0000% 62.5000% 62.0000% 61.5000% 61.0000% 60.5000% 60.0000% 59.5000% 59.0000% 58.5000% 58.0000% 5 10 K 20 50
mejoras por regresin
Ilustracin 3: Mejoras por regresin segn k
1.2 1.15 1.1 MMRE 1.05 1 0.95 0.9 0.85 1 2 Nmero de cercanos 3
Ilustracin 4: MMRE segn el nmero de proyectos cercanos
Todas estas conclusiones nos han ido encaminando a la obtencin de la configuracin ms apropiada de la alternativa para la estimacin de esfuerzo de proyectos software planteada en este trabajo. Esta configuracin se corresponde con un tamao del conjunto de test del 10 % del total de la base de proyectos, un nmero k para el algoritmo kNN
81
Jess
de 20, y la consideracin de 3 proyectos como los ms parecidos para realizar la estimacin inicial previa al ajuste por regresin. Efectivamente, la prueba configurada con estas caractersticas es la que consigue el menor valor de MMRE de todas. Esta es la prueba nmero 9.
82
Jess
83
Jess
CONCLUSIONES
Jess
Jess
La realizacin de un trabajo de la envergadura de un proyecto fin de carrera aporta a cualquier estudiante un gran nmero de conclusiones sobre la labor realizada. La exposicin de estas ideas es una tarea difcil y compleja, ya que involucra concentrar en unas lneas todo lo aprendido a lo largo de meses de dedicacin. No obstante, el recordar y comentar las conclusiones obtenidas constituye en s una aportacin ms a la formacin del autor, que cerrar as con brillantez la etapa de desarrollo del proyecto. La dificultad encontrada por cualquier estudiante para extraer las conclusiones finales, se ve acentuada an ms si cabe si ste pertenece a una carrera tcnica con gran implicacin e importancia en la sociedad actual, o si ha desarrollado un proyecto acerca de un tema de gran trascendencia o futuro. En mi caso, al pertenecer a una titulacin con grandes salidas laborales y de enorme implicacin en la sociedad, me veo obligado a realizar un profundo anlisis que debe comprender desde el momento en que opt por cursar esta titulacin, hasta la eleccin de este proyecto fin de carrera. Completado este anlisis, aportar ya una serie de conclusiones ms tcnicas y derivadas directamente de los resultados obtenidos de las ejecuciones del modelo planteado en el proyecto. Cierto es que opt por estudiar Ingeniera Informtica por lo llamativas y variadas que eran sus salidas laborales, aunque tambin senta una especial curiosidad e intriga por la Programacin. Sin embargo desconoca todo el proceso que rodea a la codificacin de un producto software, pensando solamente en su creacin mediante un determinado lenguaje de programacin. Cierto tambin es que me agrad conocer y practicar diversas tcnicas de programacin y construccin de programas, pero segua ignorando la labor realizada fuera de los lenguajes.
86
Jess
Llegado el momento de aprender ciertas nociones bsicas de Ingeniera Software, me percat de la enorme importancia que sta adquiere en la creacin de programas y productos informticos, por lo que no tuve ninguna duda a la hora de escoger una temtica para mi proyecto fin de carrera. Recuerdo ahora con mucha ilusin el comienzo de este trabajo, sentando sus bases y delimitando sus objetivos; y es ahora cuando de verdad comprendo el papel tan importante que juega la Ingeniera Software en la creacin de productos totalmente funcionales y de calidad. Sin perder de vista el mundo laboral, cada vez ms cercano para cualquier estudiante que se encuentre elaborando su proyecto fin de carrera, las empresas desarrolladoras de Software convierten en totalmente imprescindible la aplicacin de mtodos y tcnicas de Ingeniera Software, ya que su esencia y supervivencia dependen de la entrega de programas fiables y correctamente desarrollados. Estas empresas pueden dedicar absolutamente todo su esfuerzo en desarrollar excelentes programas, pero surge la necesidad de medir y controlar este esfuerzo, para no acabar en situacin de prdida de dinero, tiempo, empleados, etc. Ante esta situacin se debe actuar, y la mejor manera pasa por realizar predicciones sobre diversas caractersticas del proyecto software previas al desarrollo del mismo. Una de las predicciones ms importantes que se hace es la del esfuerzo, para evitar desembocar en situaciones similares a las comentadas anteriormente. Razonadamente pienso que no conozco todos los secretos de la Ingeniera Software, pero al menos me he dado cuenta de que uno de sus momentos ms delicados y dificultosos sucede a la hora de realizar las estimaciones del esfuerzo necesario para completar un determinado proyecto. Esta decisin conlleva un gran riesgo a cualquier organizacin que deba tomarla, por lo que deban existir tcnicas que ayudaran a realizarla y que
87
Jess
indicaran de alguna manera la probabilidad de errar al dar como prediccin un cierto valor. Efectivamente son muchas las tcnicas existentes para la estimacin. Creo que algunas son demasiado antiguas, y necesitan una adaptacin a los modelos actuales de desarrollo software. Otras por el contrario son muy novedosas, y responden con precisin a las dudas planteadas por los estimadores. En general, de entre la multitud de formas de realizar predicciones, se debe elegir la que mejor se adapte a la informacin disponible y a las caractersticas del proyecto. No debe surgir el temor de no encontrar un modelo de estimacin que se ajuste a lo necesitado. Al revs, debe contemplarse siempre la posibilidad de combinar tcnicas y crear nuevos modelos y alternativas, como ha pretendido hacer quien escribe estas lneas. Puede escogerse un modelo, y utilizar sus salidas como entrada para otro; o puede aplicarse un sistema que tome las ecuaciones y operaciones de otro; o se puede, de una manera ms atrevida, emplear algoritmos que en principio estn destinados a otros propsitos para mejorar modelos ya establecidos. Esta ltima alternativa ha sido la escogida en este proyecto, donde a un mtodo robusto y fiable como la estimacin por analoga, se le ha aplicado un algoritmo de clasificacin de instancias, cerrando este proceso de prediccin un ajuste tambin conocido y utilizado, aunque de naturaleza estadstica y matemtica. Si ya de por s tena una visin de la estimacin como un proceso importante y de enorme impacto en cualquier empresa de desarrollo, ahora ms an lo comprendo, al haber trabajado y comprobado desde una posicin privilegiada las dificultades que esta tarea conlleva. De todas formas, no debemos pensar que la estimacin sea un proceso excesivamente complicado. Efectivamente es muy delicado por las repercusiones que puede tener en la actividad normal de una empresa, pero como proceso algortmico e informtico puede llegar a ser bastante sencillo. De
88
Jess
hecho, la alternativa que propongo no utiliza complicados ajustes ni operaciones; tan slo se basa en la aplicacin de un mecanismo de clasificacin de elementos, y en el ajuste de la estimacin inicial mediante una muy sencilla operacin matemtica. Sobre estos algoritmos empleados he obtenido tambin varias conclusiones. La primera es que creo que, al igual que ocurre con los modelos de estimacin, existen multitud de mtodos de clasificacin de instancias. Debemos escoger siempre el que ms se ajuste a la estructura de la informacin que poseamos, y el que veamos que puede alcanzar mejores resultados en funcin de los mbitos en que suele ser ejecutado. Poniendo como ejemplo la alternativa a la estimacin que planteo en este proyecto, conocemos de antemano que vamos a realizar las predicciones de esfuerzo basndonos en las analogas existentes entre proyectos. Si queremos aplicar un algoritmo de clasificacin, de poco nos va a servir aquel que prediga la clase a la que pertenece un elemento. Nos va a venir mejor un mtodo que asigne a un proyecto determinado un conjunto de ejemplares parecidos, adems ordenados por su valor de distancia. Estos motivos expuestos son los que hicieron que se escogiera como algoritmo de clasificacin kNN, ya que se amolda perfectamente a nuestros requerimientos, y sabemos adems que ofrece unos buenos resultados, muy coherentes con las medidas de similitud que utiliza. La eleccin de esta medida de similitud no present muchos problemas, ya que desde el momento que supe que los datos de los proyectos estaban expresados en forma vectorial, pens en la medida del coseno como algo natural y propio, de fcil implementacin, eficaz y robusta. Me resulta muy llamativa la sencillez con la que kNN crea los conjuntos de proyectos anlogos a uno dado. Adems, el poder disponer de potentes estructuras de datos como las ofrecidas por el lenguaje de programacin utilizado lo convierte en un proceso ms transparente si cabe, y ms fcil de entender por cualquier persona. Slo basta con proporcionarle las medidas de
89
Jess
distancia del elemento que queremos clasificar con el resto, y el algoritmo ya se encarga de crear los conjuntos de parecidos. Ya con estos conjuntos creados, el modelo planteado realiza las estimaciones y las ajusta por el mecanismo de regresin hacia la media. A la vista de los resultados obtenidos, podemos concluir que la regresin hacia la media es un ajuste sencillo que en la mayora de las ocasiones consigue mejorar la estimacin inicial aportada por la analoga. Existen una gran cantidad de ajustes posibles, pero considero que la eleccin hecha en nuestro modelo ha sido acertada, al ser palpable la sencillez con la que pueden ser alcanzados unos buenos resultados, y al ser muy adecuado para la informacin con la que hemos trabajado. No obstante, pueden aplicar se en trabajos futuros otro tipo de ajuste a las estimaciones, y poder as comparar qu mecanismo resulta mejor. A lo largo de las ejecuciones, salta a la vista una cierta aleatoriedad a la hora de realizar las estimaciones, ya que las predicciones iniciales se realizan en funcin de los proyectos ms parecidos, pudiendo ser estos 1, 2 3. Las pruebas han demostrado que la probabilidad de error disminuye cuanto mayor es el nmero de vecinos con los que se calcula una estimacin inicial. Adems, los valores de error obtenidos varan en funcin del conjunto de test con el que se trabaje, debido a esta aleatoriedad con la que se eligen los miembros de los conjuntos de test y de entrenamiento. Por estos motivos expuestos anteriormente se propone para
investigaciones futuras la implementacin de modelos que tengan en cuenta ms proyectos anlogos para realizar las estimaciones iniciales. En nuestro modelo, se han tomado como mximo 3, al ser ste el valor ms frecuentado en la literatura. Puede resultar tambin interesante aplicar diferentes pesos a los atributos de los proyectos, en funcin de su importancia o influencia en el valor final de esfuerzo; o incluso realizar una seleccin de caractersticas, en lugar de hacer los clculos tenindolas todas en cuenta. Todas estas posibles ampliaciones, me hacen darme cuenta de que ste ha sido un proyecto innovador por su temtica, y que acepta multitud de modificaciones futuras, lo
90
Jess
cual me alegra, ya que eso significa que este trabajo ha sido una aportacin no slo a mi formacin acadmica, sino tambin a la disciplina de la estimacin en Ingeniera Software.
91
Jess
92
Jess
REFERENCIAS Y BIBLIOGRAFA
Jess
Jess
REFERENCIAS
[AGA01] Agarwal, R. y Kumar, M. Estimating software projects, Software engineering Notes, 26(4), 60-67, 2001. [ANG00] Angelis L, y Stamelo, I. A simulation tool for efficient analogy
based cost estimation, Empirical Software engineering 5, 35-68, 2000. [BAR06] XIII, 664. [CHA96] project Chatzoglou, P. D. y Macaulay, L. A. A review of existing models for planning and estimation and the need for a new approach, Journal of Project Management, 14(3), 173-183, 1996 Barranco, M. J., y Martnez, L. "Un Sistema de Recomendacin 30th November- 2nd December, 2006, Hammamet, Tnez, pp. 645-
Basado en Conocimiento con Informacin Lingstica Multigranular" SIGEF
International [CHI06] effort and [HEE92] Software [HUA06] Software [IEEE93] 1993. [JEF00]
Chiu, N. H. y Huang, S. J., The adjusted analogy-based software estimation based on similarity distances, The Journal of Systems Software, 80(2007), 628-640, 2006. Heemstra, F. J. Software cost estimation, Information and engineering, 34(10), 627-639, 1992. Huang, S. J., y Chiu, N. H., in press. Optimization of analogy Technology, 2006 IEEE Standard Glossary of Software Engineering Terminology,
weights by genetic algorithm for software effort estimation, Information and
Jeffery, R. y Ruhe, M. A comparative study of two software cost modeling techniques using multi-organizational and
development
95
Jess
company-specific 2000. [JOR03] and 68 [JOR04]
data, Information and software Technology, 42, 1099-1016,
Jrgensen, M., y Indahl, U. Software effort estimation by analogy regresin toward the mean, The Journal of Systems and Software (2003), 253-262, 2003. Jrgensen, M. y Sjberg, D. I. K. The impact of customer software development effort estimates, Internacional
expectation on
Journal of Project Management, 22, 317-325, 2004. [LOR94] hall, 1994. [MUK92] Mukhopadhyay, T. y Vicinanza, S. Estimating the feasibility of a case-based reasoning model for software effort estimation, MIS Quarterly 16(2), 155- 171, 1992. [PRE98] Pressman, R. Ingeniera del Software. Un enfoque prctico, 1998. Lorenz, M. y Kidd, J. Object-oriented Software Metrics, Prentice-
McGraw Hill, [PRE06]
Pressman, R. Ingeniera del Software. Un enfoque prctico, 2006.
McGraw Hill, [SHE97] using 736-743,
Shepperd, M. y Schofield, C. Estimating software project effort analogies, IEEE Transactions on Software engineering 23 (12), 1997.
96
Jess
BIBLIOGRAFA
Gramajo, E. y Garca-Martnez, R. Combinacin de alternativas para la estimacin de proyectos software, Centro de Actualizacin Permanente en Ingeniera de Software. Varas, M. Una experiencia con la Estimacin del Tamao del Software, disponible en Internet (http://www.inf.udec.cl/revista/edicion1/mvaras.htm). Mtricas, estimacin y planificacin en Proyectos de Software, disponible en Internet (www.willydev.net). Estimacin del software, Coleccin de Apuntes Asignatura Planificacin de Sistemas informticos, Universidad de Jan. Repositorio de datos del International Software Benchmarking Standards Group, disponible en Internet (www.isbsg.org).
97

PFC Jesus Alvarez

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PFC Jesus Alvarez

Загружено:

Авторское право:

Доступные форматы

Contenido

REVISIN DE LOS MODELOS DE ESTIMACIN SOFTWARE

Jess lvarez Sez

Jess lvarez Sez

REVISIN DE LOS MODELOS DE ESTIMACIN SOFTWARE

Escuela Politcnica Superior de Jan

Cuanto mayor es la necesidad de utilizar el software en cualquier

Escuela Politcnica Superior de Jan

Jess lvarez Sez

1.1 PROCESO DE ESTIMACIN

Escuela Politcnica Superior de Jan

Jess Medicin y perfeccionamiento del proceso.

Estimacin del tamao

Base de Datos de Proceso de organizacin Software

Estimacin del esfuerzo y costo

Estimacin de la programacin temporal

Estimacin de la cantidad de recursos computacionales

Medida y mejora del proceso

Ilustracin 1: Actividades de la estimacin de proyectos software

Escuela Politcnica Superior de Jan

Jess lvarez Sez

1.2. MEDIDAS Y MTRICAS DEL SOFTWARE

Jess lvarez Sez

1.3. CLASIFICACIN DE LOS MODELOS DE ESTIMACIN

Escuela Politcnica Superior de Jan

1.4. PROBLEMAS PRESENTADOS POR LA ESTIMACIN DEL ESFUERZO DE PROYECTOS SOFTWARE

Jess lvarez Sez

1.5. MODELOS DE ESTIMACIN SOFTWARE

Escuela Politcnica Superior de Jan

1.5.1. Aproximaciones paramtricas

Escuela Politcnica Superior de Jan

Jess lvarez Sez

Escuela Politcnica Superior de Jan

Tabla 1: Ecuacin bsica del esfuerzo en COCOMO (modelo bsico)

Las estimaciones sobre el tiempo son:

Tabla 2: Ecuacin bsica del tiempo en COCOMO (modelo bsico)

Escuela Politcnica Superior de Jan

Jess lvarez Sez

Tabla 3: Ecuacin bsica del esfuerzo en COCOMO (modelo intermedio y detallado)

1.65 1.66 1.56 -

ATRIBUTOS DEL COMPUTADOR

Tabla 4: Factores de costo en COCOMO

Escuela Politcnica Superior de Jan

Escuela Politcnica Superior de Jan

Jess lvarez Sez -

Modelo de composicin de aplicaciones, para proyectos de construccin de interfaces grficas de usuario.

Escuela Politcnica Superior de Jan

Los multiplicadores de esfuerzo para COCOMO II son [AGA01]:

Capacidad del personal (PERS)

Experiencia del personal (PREX) Facilidades (FCIL) Programacin (SCED)

Tabla 5: Multiplicadores de esfuerzo para COCOMO II

Escuela Politcnica Superior de Jan

FACTORES DE PRODUCTOS COTS

FACTORES DE APLICACIN Y DEL SISTEMA FACTOR DE ESCALA NO LINEAL

Tabla 6: Multiplicadores de esfuerzo para COCOTS

Escuela Politcnica Superior de Jan

Jess lvarez Sez

Escuela Politcnica Superior de Jan

Jess lvarez Sez

Tabla 7: Calibracin de la complejidad de las entradas en Puntos de Funcin

Tabla 8:Calibracin de la complejidad de las salidas y peticiones en Puntos de Funcin

Tabla 9: Calibracin de la complejidad de los archivos interfaces en Puntos de Funcin

Hecha la clasificacin, se calcula la cuenta total mediante la siguiente tabla [PRE98]: