La estimación es una de las primeras actividades de la gestión de proyectos informáticos. Se define como “la predicción del personal, del esfuerzo, de los costos y del tiempo que se requerirán para realizar todas las actividades y construir todos los productos asociados con el proyecto”
Su objetivo es conocer en etapas tempranas y de manera aproximada, el costo, la duración y los recursos necesarios para el desarrollo de proyectos de software.
Se trata de una apreciación del futuro y la exactitud con la que ésta se realice, depende la mayoría de las veces de una buena herramienta de estimación, de la experiencia del estimador y del acceso a una base de información histórica de los proyectos.
Cuando no contamos con la experiencia necesaria para determinar el costo, el tiempo de realización o cualquier otro aspecto de importancia para el desarrollo de un proyecto de Sistemas o de Software podemos usar métricas de estimación, que nos pueden ayudar a hacer las estimaciones necesarias, que si no son perfectas, igual nos son de mucha ayuda.
A continuación menciono algunas de estas métricas:
*****Líneas de Código (LOC) y Puntos de Función:
Los datos de líneas de código (LDC) y los puntos de función (PF) se emplean de dos formas durante la estimación del proyecto de software:
1. Variables de estimación, utilizadas para calibrar cada elemento del software.
2. Métricas de base, recogidas de anteriores proyectos utilizadas junto con las variables de estimación para desarrollar proyecciones de costo y esfuerzo.
Estas técnicas son diferentes pero tienen características comunes. El planificador del proyecto comienza con una declaración restringida del ámbito del software y, a partir de esa declaración, intenta descomponer el software en pequeñas subfunciones que pueden ser estimadas individualmente. Entonces, estima las LDC o PF (la variable de estimación) para cada subfunción. Luego, aplica las métricas básicas de productividad a la variable de estimación apropiada y deriva el costo y el esfuerzo para la subfunción. Combinando las estimaciones de las subfunciones se produce la estimación total para el proyecto entero.
Difieren en el nivel de detalle que requiere la descomposición. Cuando se utiliza LDC como variable de estimación, la descomposición funcional es absolutamente esencial y, a menudo, se lleva hasta considerables niveles de detalle. Debido a que los datos requeridos para estimar los Puntos de Función son más macroscópicos, en nivel de descomposición al que se llega cuando PF es la variable de estimación es considerablemente menos detallado. También, debe de tenerse en cuenta que mientras que LDC se estima directamente, PF se determina indirectamente mediante la estimación del número de entradas, salidas, archivos de datos, peticiones e interfaces externas, entre otras.
Independientemente de la variable de estimación que use, el planificador del proyecto, normalmente, proporciona un rango de valores para cada función descompuesta. A partir de los datos históricos o (cuando todo lo demás falla) usando su intuición, el planificador estima los valores optimista, más probable y pesimista de LDC o de PF para cada función. Cuando lo que se especifica es un rango de valores, implícitamente se proporciona una indicación del grado de incertidumbre.
Entonces, se calcula el valor esperado de LDC o de PF. El valor esperado para la variable de estimación, E, se obtiene como una medida ponderada de las estimaciones LDC o PF óptima (a), más probable (m) y pesimista (b).
Por ejemplo:
Da una mayor credibilidad a la estimación más probable y sigue una distribución de probabilidad beta.
*****Heurística:
En computación, dos objetivos fundamentales son encontrar algoritmos con buenos tiempos de ejecución y buenas soluciones, usualmente las óptimas. Una heurística es un algoritmo que abandona uno o ambos objetivos; por ejemplo, normalmente encuentran buenas soluciones, aunque no hay pruebas de que la solución no pueda ser arbitrariamente errónea en algunos casos; o se ejecuta razonablemente rápido, aunque no existe tampoco prueba de que siempre será así. Las heurísticas generalmente son usadas cuando no existe una solución óptima bajo las restricciones dadas (tiempo, espacio, etc.), o cuando no existe del todo.
A menudo, pueden encontrarse instancias concretas del problema donde la heurística producirá resultados muy malos o se ejecutará muy lentamente. Aún así, estas instancias concretas pueden ser ignoradas porque no deberían ocurrir nunca en la práctica por ser de origen teórico. Por tanto, el uso de heurísticas es muy común en el mundo real.
Para problemas de búsqueda del camino más corto el término tiene un significado más específico. En este caso una heurística es una función matemática, h(n) definida en los nodos de un árbol de búsqueda, que sirve como una estimación del coste del camino más económico de un nodo dado hasta el nodo objetivo. Las heurísticas se usan en los algoritmos de búsqueda informada como la búsqueda egoísta. La búsqueda egoísta escogerá el nodo que tiene el valor más bajo en la función heurística. A* expandirá los nodos que tienen el valor más bajo para g(n) + h(n), donde g(n) es el coste (exacto) del camino desde el estado inicial al nodo actual. Cuando h(n) es admisible, esto es si h(n) nunca sobrestima los costes de encontrar el objetivo; A* es probablemente óptimo.
Un problema clásico que usa heurísticas es el puzzle-n. Contar el número de casillas mal colocadas y encontrar la suma de la distancia Manhattan entre cada bloque y su posición al objetivo son heurísticas usadas a menudo para este problema.
*****COCOMO:
COCOMO básico es un forma rápida y sencilla de estimar la magnitud de los costes de un proyecto software, pero este alcance está necesariamente limitado porque hay muchos factores sin contabilizar, como son las diferencias de requisitos hardware, la calidad y experiencia del personal, utilización de técnicas y herramientas más sofisticadas, y otra serie de atributos conocidos que tiene mucha influencia en los costes de un proyecto.
COCOMO es un modelo sencillo de COCOMO. Cocomo puede ser aplicado a tres tipos de proyectos software. Esto nos da una impresión general del proyecto.
Proyectos Orgánicos – son relativamente pequeños, con proyectos software sencillo en los que el equipo tiene mucha experiencia y tienen pocos requisitos estrictos.
Proyectos Medios – son intermedios (en tamaño y complejidad), proyecto software en los que no tienen la misma experiencia todos los miembros del equipo. Hay requisitos más y menos rígidos.
Proyectos empotrados – son proyectos software que se deben desarrollar con unos requisitos hardware, software y de operación.
La ecuación de COCOMO en este modo básico es:
Donde E es el esfuerzo aplicado en persona-mes, D es el tiempo de desarrollo en meses, KLOC es el número de líneas estimadas para el proyecto (en miles) y P es el número de personas necesarias. Los coeficientes a, b, c y d se obtienen de la siguiente tabla:
*****COCOMO II:
El nuevo modelo incorporado en el año 1990, tiene características de los modelos COCOMO 81 y Ada COCOMO. COCOMO II tiene también tres submodelos; El modelo de composición de la aplicación es usada para estimar el esfuerzo y planificación de proyectos que usa las herramientas integradas CASE (Computer Aided Software Engineering) para un desarrollo rápido de la aplicación.
Realizando una comparación entre COCOMO 81 y COCOMO II; a este último se le añadió nuevos manejadores de costos para la aplicaciones precedentes, flexibilidad en el desarrollo, necesita documentación para el ciclo de vida, múltiples sitios de desarrollo y requiere software reusable.
Modelo COCOMO II post-arquitectura cubre el actual desarrollo y mantenimiento de un producto de software. Esta etapa del ciclo de vida procede mas a un costo efectivo, si el ciclo de vida de una arquitectura de software ha sido desarrollada, validada con respecto a la misión del sistema y establecida como un marco de trabajo para el producto.
El modelo de post-arquitectura predice el esfuerzo de desarrollo del software, personas-mes (PM), utiliza un conjunto de 17 multiplicadores de manejadores de costo (EM) y un conjunto de 5 escalas de manejadores de costo para determinar la escala del exponente del proyecto (SF). Estas escalas de los manejadores de costo remplazan los modos de aplicación (orgánico, sem.-acoplado y acoplado); el modelo tiene la siguiente forma:
PM = A * (Size) 1.01 + "j5= 1*
I17= 1 Emil
Los manejadores de costo tiene para elegir una de las seis posibilidades que son: Very Low (VL), Low (L), Nominal (N), High (H), Very High (VH), y Extra High (XH); no todos los rangos son válidos para todos los manejadores de costo.
CONTINUA EN LA SIGUIENTE ENTRADA>>>>>
