Técnicas de estimación de casos de uso

Aunque la estimación es más un arte que una ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes y de tiempos. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como una guía para una buena ingeniería del software, no es en absoluto aconsejable embarcarse sin ella. 

El objetivo de la Estimación es predecir las variables involucradas en el proyecto con cierto grado de certeza. Se trata de aportar una predicción de algún indicador importante para la gestión de proyectos de software: tiempo, esfuerzo, cantidad de defectos esperados, entre otros, sin dejar de tener en cuenta que la incertidumbre y el riesgo son elementos inherentes.

En la actualidad son muchos los proyectos que fracasan e incumplen sus plazos de entrega. Según el The Standish Group en su publicación Chaos Report 2009, determinó que el 24% de los proyectos informáticos fueron cancelados, solo el 32 % terminaron a tiempo y dentro del presupuesto y el 44% de los proyectos de software fueron concluidos después de la fecha estimada.

Son muchos los métodos de estimación del esfuerzo que existen en la actualidad: SLIM, COCOMO II, Juicio Experto, Analogía, algunos basados en técnicas estadísticas e Inteligencia Artificial que se basan en datos históricos para inferir el esfuerzo de nuevos proyectos.

El objetivo de este trabajo es describir el método de estimación basado en Puntos de Casos de Uso a través de un caso práctico y mostrar las ventajas y desventajas del mismo.

El método escogido se acopla con la metodología más usada hasta nuestros días, la metodología RUP (Proceso Unificado de Rational), esta metodología se basa en la identificación de los casos de uso, encargados de dirigir el proceso y la técnica escogida toma como punto de partida estos elementos.

DESARROLLO

Planificación basada en casos de uso

Este método de estimación de proyectos de software fue desarrollado en 1993 por Gustav Karner de Rational Software y está basado en una metodología orientada a objetos, dándole el nombre de "estimación de esfuerzos con casos de uso". Surgió como una mejora al método de puntos de función pero basando las estimaciones en el modelo de casos de uso, producto del análisis de requerimientos. Según su autor, la funcionalidad vista por el usuario (modelo de casos de uso) es la base para estimar el tamaño del software. [2]

Un caso de uso por sí solo no permite efectuar una estimación de esfuerzos ni de tiempos, los casos de uso son solamente herramientas para el análisis. La idea fundamental es predecir el tamaño del software a partir de los requerimientos de los casos de uso.

El objetivo fundamental de esta técnica es: Estimar las horas necesarias para ejecutar un conjunto de casos de uso. Es decir, necesitamos predecir cuánto tiempo llevará el desarrollo de software y cuántas personas se requieren para realizarlo. Para ello, es necesario cuantificar la complejidad del sistema y el tiempo necesario para producir una unidad de complejidad.

En etapas tempranas del ciclo de vida, se identifican los Actores y los Casos de Uso del sistema, y se documenta cada uno de ellos mediante una breve descripción. Aplicando el Análisis de Puntos de Función a estos Casos de Uso, se podrá obtener una estimación grosera del tamaño y a partir de ella del esfuerzo. Esta estimación es bastante imprecisa debido principalmente a la escasa información que se tiene sobre el software al principio de un proyecto, pero permitirá obtener una idea del esfuerzo necesario para llevar adelante el mismo, y podrá ser refinada a medida que se obtenga más.

El ejemplo práctico a través del cual se describirá el método consiste en una aplicación Web para la gestión de información telefónica, de reportes de averías, y de estadísticas de los estados de los teléfonos de un Centro de Educación Superior (CES). Actualmente este proceso se realiza manualmente, provocando dificultades en la organización y control de la información referente a los equipos telefónicos y a sus respectivos usuarios. La aplicación es desarrollada en la plataforma .Net, con lenguaje C#. A continuación se presentan los actores y casos de uso identificados.

Técnicas de Estimación

https://www.youtube.com/watch?v=SRwwTLfcgsE

Técnicas de Estimación

Cuando se planifica un proyecto se tienen que obtener estimaciones del esfuerzo humano requerido, de la duración cronológica del proyecto y del costo.

En la mayoría de los casos las estimaciones se hacen valiéndose de la experiencia pasada como única guía. Aunque en algunos casos puede que la experiencia no sea suficiente.

Técnicas de Estimación de Costo y Esfuerzo

Estas técnicas de estimación son una forma de resolución de problemas en donde, en la mayoría de los casos, el problema a resolver es demasiado complejo para considerarlo como una sola parte. Por esta razón, descomponemos el problema, recaracterizándolo como un conjunto de pequeños problemas.

Líneas de Código 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:

• Variables de estimación, utilizadas para calibrar cada elemento del software.

• 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:

E = a + 4m + b

6

da una mayor credibilidad a la estimación más probable y sigue una distribución de probabilidad beta.

Técnicas Delfi.

Las técnicas delfi fueron desarrolladas en la corporación Rand en el año de 1948, con el fin de obtener el consenso de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La técnica puede adaptarse a la estimación de costos de la siguiente manera:

• Un coordinador proporciona a cada experto la documentación con la definición del sistema y una papeleta para que escriba su estimación.

• Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar con el coordinador, pero no entre ellos.

• El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos.

• Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación.

• El proceso se repite varias veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso.

El siguiente enfoque es una variación de la técnica Delfi tradicional que aumenta la comunicación conservando el anonimato.

• El coordinador proporciona a cada experto la documentación con la definición del sistema y una papeleta para que escriba su estimación.

• Cada experto estudia su definición, y el coordinador llama a una reunión del grupo con el fin de que los expertos puedan analizar los aspectos de la estimación con él y entre ellos.

• Los expertos terminan su estimación en forma anónima.

• El coordinador prepara un resumen de las estimaciones efectuadas sin incluir los razonamientos realizados por algunos de los expertos.

• El coordinador solicita una reunión del grupo para discutir los puntos donde las estimaciones varíen más.

• Los expertos efectúan una segunda ronda de estimaciones, otra vez en forma anónima. El proceso se repite tantas veces como se juzgue necesario.

COCOMO.

El Modelo Constructivo de Costos (COnstructive COst Model) es una jerarquía de modelos de estimación para el software. Esta jerarquía está constituida por los siguientes modelos:

• El modelo COCOMO básico es un modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas.

• El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de “conductores de costo”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

• El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.

Los modelos COCOMO están definidos para tres tipos de proyecto de software.

Modelo Orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico).

Modelo Semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos).

Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegación para un avión).

Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:

E = ab (KLDC) exp (bb)

D = cb (E) exp (db)

donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de desarrollo en meses cronológicos y KLDC es el número estimado de Líneas de Código distribuídas (en miles) para el proyecto.

Las ecuaciones del modelo COCOMO intermedio toma la forma:

E = ai (KLDC) exp (bi) x FAE

donde E es el esfuerzo aplicado en personas-mes, KLDC es el número estimado de Líneas de Código distribuídas para el proyecto