Managing Availability with the State Controller

3.2

TÉCNICAS DE ESTIMACIÓN

En las últimas décadas se han propuesto muchos modelos de estimación. En esta sección se proporciona una descripción general de los métodos de estimación más populares en la ingeniería del software.

Estas técnicas se pueden clasificar de diferentes maneras en función de las distintas características de los métodos, pero no hay una categorización aceptada universalmente. Por ejemplo, las podemos dividir en directas o indirectas. Directas son aquellas que pueden ser obtenidas de manera inmediata como, por ejemplo, el tamaño funcional de un programa o su número de defectos. Las indirectas son aquellas que no pueden ser directamente obtenidas, si no que se derivan de otras técnicas, por ejemplo: las líneas de código/personas-meses[9].

También pueden ser clasificadas en métricas objetivas y subjetivas: las objetivas siempre deben dar valores idénticos para una métrica determinada con dos o más observadores, mientras que, las subjetivas pueden dar distintos valores para una métrica determinada con dos o más observadores, debido a que está involucrado el juicio de cada uno de ellos.

Otra forma de distinción entre métricas, es la propuesta por Roger S Pressman en [14], en el cual se distinguen 6 grupos de métricas distintos:

• Métricas técnicas, centradas en las características del software más que en su proceso de desarrollo.

• Métricas de calidad, tanto del software desarrollado como de la efectividad del proceso de ingeniería aplicado.

• Métricas de productividad, referidas al rendimiento del proceso de desarrollo como función del esfuerzo aplicado.

• Métricas orientadas al tamaño, que miden de forma directa el software y el proceso por el cual se desarrolla.

• Métricas orientadas a la función, que se centran en la funcionalidad o utilidad del programa, y que estudiaremos en detalle en los siguientes apartados.

• Métricas orientadas a la persona, que aportan información sobre la forma en que la gente desarrolla software.

De igual forma se presenta una clasificación de métricas basadas en producto, proceso o proyecto. La clasificación que se va a seguir es la propuesta por [19], que divide a las métricas en dos grupos: métodos algorítmicos y no algorítmicos.

3.2.1 Métodos no algorítmicos

Los métodos de este grupo se basan en comparaciones e inferencias analíticas. Usan información sobre proyectos anteriores que son similares al proyecto que se pretende estimar y generalmente, este proceso de estimación se realiza de acuerdo con el análisis del conjunto de datos de los proyectos anteriores.

Juicio experto

Se trata de una técnica subjetiva basada en consultar a una serie de expertos estimaciones basadas en su experiencia. Estos expertos han de tener conocimientos suficientes en este campo, amplia experiencia, así como sentido comercial. El principal objetivo de esta técnica es, que en consenso se

CAPÍTULO 3. ESTADO DEL ARTE 31

determinen una serie de parámetros, como pueden ser el coste, el tamaño o el esfuerzo. Es una de las técnicas dominantes en el campo de las métricas de software.

Por lo general, estos expertos tienen conocimiento de esfuerzos de desarrollo similares, y el grado de similitud es relativo a su comprensión del proyecto propuesto. En cierto sentido, podemos pensar en el juicio de los expertos como una conjetura sobre el esfuerzo que se debe invertir para desarrollar un proyecto completo o una parte de este, el tamaño de este o el coste que puede generar.

Según Jorgensen [6] para poder categorizar una estimación como experta debe darse que dicha estimación sea realizada por una persona reconocida como experta en dicha tarea y que gran parte del proceso que se siguió para llegar a esa estimación esté basado en un proceso de razonamiento no explícito ni recuperable, es decir, está basado en la intuición.

Esta técnica puede estar apoyada por variedad de herramientas para ayudar a los analistas a aprovechar lo que saben. Como, por ejemplo, se pueden utilizar bases de datos de información histórica de proyectos anteriores, ayudando a comprender dónde encaja el proyecto actual. Con esto además se consigue que se aumente la credibilidad de las conclusiones. Así como en herramientas de modelización basadas en técnicas estadísticas o de inteligencia artificial.

El punto fuerte de este método es que se tienen en cuenta las diferencias existentes entre las experiencias anteriores y las nuevas técnicas, arquitecturas o aplicaciones involucradas en el nuevo proyecto. Esto permite al experto considerar condiciones excepcionales que envuelven al proyecto y que no se considerarían en otro tipo de modelos. Las predicciones realizadas en situaciones inestables resultan ser mejores que las realizadas con otros métodos.

El principal problema de esta técnica es, como se ha dicho anteriormente, que se trata de una técnica subjetiva. En general, el valor de la estimación depende de la calidad de los expertos que forman parte de ella y esta solo es conocida cuando se confrontan los resultados obtenidos con los esperados.

Por otro lado, la opinión de determinados expertos puede llegar a primar sobre el resto de las opiniones. Para mejorar esto, se hace uso de mecanismos de consenso tales como la técnica Delphi o PERT [12].

Técnica Delphi

Se trata de una forma más estructurada de hacer uso del juicio experto. Fue desarrollada por la corporación RAND en 1948, aunque se comenzó a utilizar en el campo del software en el año 1981 popularizada Barry Boehm en su libro Software Engineering Economics.

Esta técnica surge con el objetivo de conseguir un acuerdo de un grupo de expertos sin necesidad de contar con los efectos negativos de las reuniones en grupos. Es una técnica de recogida de información que permite obtener la opinión de un grupo de expertos a través de la consulta reiterada.

Un grupo de expertos es preguntado por una estimación anónima dando la oportunidad a estos expertos de revisar las estimaciones de los demás. Este proceso se repite hasta que ningún experto quiere cambiar su estimación [4].

El procedimiento de esta técnica es el siguiente:

• El coordinador es el encargado de proporcionar a cada uno de los expertos la especificación del proyecto propuesto.

• Cada experto estudia la definición y determina su estimación de forma anónima. Está permitido realizar preguntas al coordinador, pero no entre los expertos.

• El coordinador prepara y distribuye un resumen de las estimaciones afectadas con su corres- pondiente razonamiento. Se ofrece el valor medio de las opiniones recogidas y se les pide una nueva estimación anónima indicando las razones de las posibles modificaciones.

32 3.2. TÉCNICAS DE ESTIMACIÓN

• El proceso de recogida de opiniones se repite tantas veces como sea necesario hasta llegar a un consenso. No se realiza ninguna reunión en grupo.

Una versión mejorada de esta técnica fue la denominada técnica Delphi de banda ancha popula- rizada también por Boehm. La diferencia con la técnica anterior es que hay un mayor número de interacciones.

La principal ventaja de este método es que recolecta la opinión experta sobre los proyectos basado en experiencias anteriores que son difíciles de evaluar por otros medios. Por otro lado, el mayor inconveniente se encuentra, al igual que en la técnica del juicio experto, en la subjetividad de los expertos seleccionados para realizar la estimación.

Esta técnica, de carácter cualitativo, es recomendable cuando no se dispone de información suficiente para la toma de decisiones.

Bottom-up

Este método consiste en la descomposición de un proyecto en elementos más pequeños los cuales son estimados de forma separada. Las estimaciones de estos elementos individuales pueden realizarse mediante variedad de métodos de estimación y están sujetos a los beneficios y desventajas de estos. Una vez realizadas estas estimaciones se combinan para producir una estimación total del proyecto.

Este proceso de estimación implica dos pasos: descomposición e integración.

Se comienza por descomponer un proyecto en elementos más pequeños, que luego es estimado por separado, generalmente por la persona responsable del desarrollo de esta, y luego se suman los elementos para obtener la estimación total del proyecto. Dado que esta estimación requiere de más tiempo para desarrollarla es necesario usarla solo cuando el tiempo lo permite. Normalmente es difícil aplicarlo en las fases tempranas del ciclo de vida del proyecto [12].

Top-down

Esta técnica sigue una filosofía similar a la técnica anterior. Se realiza una estimación descendente, descomponiendo el proyecto en elementos más pequeños o en fases del ciclo de vida de este. Cada uno de los elementos individuales se estima utilizando otras técnicas de estimación, como puede ser analogía o juicio de expertos. Al hacer uso de otras técnicas, este método está sujeto a las características, ventajas y desventajas de estas. La estimación de estos elementos se basa en las características generales del proyecto, en lugar de sobre características funcionales o de diseño detalladas. Una vez se ha realizado la estimación de los elementos individuales, estos elementos se combinan para formar una estimación total del proyecto.

3.2.2 Métodos algorítmicos

A diferencia de los modelos algorítmicos, estos modelos se basan en fórmulas y relaciones matemáticas.

Modelo COCOMO

COCOMO (Cost Constructive Model) es un modelo matemático de base empírica que permite la estimación de esfuerzo y coste de proyectos. Fue desarrollado por Barry Boehm a comienzo de los años 80 y fue descrito en su libro Software Engineering Economics y se le conoce como COCOMO I o COCOMO 81.

Esta técnica asume que el modelo de desarrollo del proyecto software es en Cascada y que se hace uso de lenguajes imperativos de desarrollo tales como C o Pascal. Además, hace una distinción de los proyectos según su modo de desarrollo y según el modelo de estimación.

CAPÍTULO 3. ESTADO DEL ARTE 33

• Modo orgánico: se trata de proyectos sencillos, en un entorno estable, en los que el equipo tiene mucha experiencia y con un tamaño no superior a 50 KLDC.

• Modo semi-acoplado o encajado: se trata de proyectos con un tamaño mejor a 300KLDC con un nivel de complejidad mayor al anterior.

• Modo Empotrado: para proyectos sobre los que no se tiene ninguna experiencia y son de alta complejidad.

Por otra parte, se presenta una jerarquía de modelos de estimación según el nivel de detalle empleado en su utilización, la estimación es más precisa a medida que se toman en cuenta mayor cantidad de factores que influyen en el desarrollo de un producto de software:

• Básico: productos de tamaño pequeño o medio. Hace uso de la siguiente fórmula para estimar el esfuerzo:PM = A · (KSLOC)b

PM es el esfuerzo estimado en meses-persona.

KSLOC es el tamaño del software a desarrollar en miles de líneas de código. A y B son coeficientes que varían según el Modo de Desarrollo.

• Intermedio: para estimaciones más exactas, se utilizan 15 atributos. Estos atributos se clasifican en cuatro grupos: atributos del producto software, del hardware, del personal involucrado en el proyecto y propios del proyecto. Se utiliza la siguiente fórmula:PM = A · EAF · (KSLOC)b Donde PM es el esfuerzo estimado en meses-persona.

KSLOC es el tamaño del software a desarrollar en miles de líneas de código. A y B son coeficientes que varían según el Modo de Desarrollo.

EAF es el denominado factor de ajuste del esfuerzo.

• Detallado: incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de coste en cada fase (análisis, diseño, etc.). Los cambios en la industria del software llevaron a realizar una nueva formulación del modelo COCOMO denominada COCOMO II que está adaptado a los ciclos de vida de los modelos de desarrollo de software actuales.

Utiliza las líneas de código y/o puntos de función para el dimensionamiento, con modificadores para reutilización del software, un conjunto de 17 factores que afectan al coste y un conjunto de 5 factores que determinan el escalamiento del proyecto. Estos factores sustituyen a los modos de desarrollo (Orgánico, Semiacoplado y Empotrado) en el original.

Esta nueva versión consiste en tres modelos diferentes: Composición de Aplicaciones, Diseño Temprano y Modelos de Post-arquitectura[18].

• Composición de aplicación: Utilizable para proyectos construidos a través de componentes reutilizables, scripts y programación en bases de datos. Basado en puntos de objeto.

• Diseño Temprano: es aplicado antes de determinar completamente su arquitectura, en etapas tempranas del proyecto. Este modelo utiliza una serie de parámetros de costo, y nuevas ecuaciones de estimación. Se basa en Puntos de Función no Ajustados o KLDC. Ajusta el esfuerzo usando siete factores de costo.

• Post-arquitectura: este es el modelo más detallado y puede ser utilizado después de haber desarrollado la arquitectura global del proyecto. Utiliza nuevos parámetros de costo, nuevas reglas de conteo de líneas y nuevas ecuaciones. El esfuerzo se ajusta usando 17 factores multiplicadores de esfuerzo.