Please enable JavaScript.
Coggle requires JavaScript to display documents.
TEMA 49 : LA ESTIMACIÓN DEL ESFUERZO EN EL DESARROLLO DE SISTEMAS DE…
TEMA 49 : LA ESTIMACIÓN DEL ESFUERZO EN EL DESARROLLO DE SISTEMAS DE INFORMACIÓN
INTRODUCCIÓN
Una de las tareas de mayor importancia en la administración de proyectos de software es la
estimación de costes
Aunque es una de las primeras tareas, tras la especificación de requerimientos,
se ejecuta regularmente
a medida que el proyecto progresa con el fin de ajustar la estimación
En la construcción de software interviene un conjunto de costes muy variado, aunque
dominan los costes del personal técnico
Debemos disponer de diferentes unidades de medida
(métricas)
que nos pueden ser útiles para caracterizar y medir varias funcionalidades del software (tamaño, calidad y fiabilidad..) y asociarlas con el esfuerzo en horas de trabajo o con el coste monetario que cuesta implementarlas
Métrica :
asignación cuantitativa de valor o grado a un atributo de una entidad propia del software, ya sea un producto o un proceso.
Para la estimación de costes, las métricas de productividad son las que tienen más relevancia en la calificación de un proyecto informático
Existen diversos modelos para efectuar esta estimación, pero todos se basan de alguna manera en
datos obtenidos en la evaluación de proyectos anteriores
MÉTRICAS DE PRODUCTIVIDAD
Recogen la
eficiencia
del proceso de producción de software y sirven para relacionar el software que se ha construido con el esfuerzo y/o tiempo que ha costado elaborarlo.
Las líneas de código :
ha sido la medida ,más utilizada para determinar el tamaño de un proyecto informático
Inconveniente :
habitualmente falta una definición apropiada de lo que son y cómo se cuentan
Denominaciones
LOC
Líneas de código. La más habitual y antigua
KLOC
Miles de líneas de código
DSI
Instrucciones de código fuente realmente entregadas(quitando las generadas automáticamente)
NCLOC
Líneas de código fuente sin tener en cuenta los comentarios
NSLOC
Nuevas líneas de código fuente, utilizadas en el modelo COCOMO II. Evolución de DSI pero sin el código reutilizado
Los puntos de función :
los desarrolladores de software consideran más significativo evaluar el tamaño de la aplicación
en base a la cantidad de funciones
que implementa o que debe contener según sus especificaciones
Modelos
Puntos de Función (PF)
de Albretch
Puntos de Función Mark-II
de Symmons
Puntos de Caso de Uso
de Karner
En muchos casos, a partir de los puntos de función se calcula su equivalente en líneas de código para aplicar otros modelos de estimación
MODELOS DE ESTIMACIÓN
Objetivo :
proporcionar sistemas y métodos generales para proceder a realizar la estimación de costes en la construcción del software de aplicación
Modelos históricos
: son los más antiguos y en cierta manera primitivos. Se basan en la
experiencia personal
y en la analogía con otros proyectos parecidos ya finalizados.
Subjetivo y propenso a errores
Juicio experto
Pura
: un experto estudia las especificaciones y hace su estimación.
Conjunta :
se utiliza la estimación de más de un experto
Media :
la media entre las estimaciones obtenidas por separado
Media ponderada :
se da menos valor a las estimaciones más pesimistas y optimistas
Técnica de Delphi :
es el procedimiento más complejo. Diferentes estimadores dan por separado su estimación. Los resultados se trasladan anónimamente a los otros estimadores para que puedan matizar y rehacer la propia estimación considerando lo que han expuesto los demás. Es
iterativo.
Analogía
: consiste en comparar las especificaciones de un proyecto con las de otros anteriores teniendo en cuenta que pueden variar algunos factores.
Distribución de la utilización de recursos en el ciclo de vida
: se basa en la estructura de costes de los proyectos históricos
Modelos empíricos o estadísticos
: intentan superar la experiencia a partir del estudio estadístico de los datos reales tomados de un conjunto significativo de proyectos ya acabados y obtenidos de múltiples fuentes.
Generan fórmulas que relacionan las diferentes unidades de medida del software y el esfuerzo con el coste expresado en
personas-mes
Modelos teóricos
: a partir de una serie de ideas generales sobre la manera de distribuir el esfuerzo , elaboran fórmulas que relacionan diferentes métricas de software
Pultman
en 1978, adoptó la distribución de esfuerzos en el tiempo en forma de curva
La idea es que a partir de un esfuerzo K y un tiempo de desarrollo tD , existe una fórmula que indica la productividad en la construcción de software y nos da el número de KLOC que se obtienen
(adjuntar fórmula)
La fórmula incluye una
constante tecnológica
que es una medida del estado de la tecnología que se aplica al proyecto
En la práctica el modelo de Pultman sólo puede ser utilizado por aquellos que adquieren
SLIM (Software Lifecycle Model)
, una herramienta informática que implementa el modelo completo. Es capaz después de una batería de preguntas de determinar la constante tecnológica y el resto de datos que interesan para la estimación de un proyecto
Modelos compuestos
: usan todas las ventajas de los modelos estadísticos y teóricos. Se parte de una serie de planteamientos teóricos y se complementan o corrigen con datos estadísticos obtenidos de proyectos ya acabados
Suelen utilizar las líneas de código
(LOC)
como base para obtener otras medidas como :
Esfuerzo medido en personas-mes o los meses de construcción del proyecto
Número de profesionales que deberías estar involucrados
Número de errores que se puede esperar tener
Número de páginas de documentación que es necesario realizar..
Etc...
Sin embargo, las LOC dependen demasiado de los lenguajes de programación y más desde la aparición de las herramientas RAD que generan gran parte de las líneas, por lo que han aparecido algunos modelos que lo tienen en cuenta
MODELOS DE CÁLCULO DE TAMAÑO ORIENTADOS A FUNCIONALIDAD
Puntos de Función (Albretch)
El tamaño del software es producto de
dos factores
El
tamaño del tratamiento de la información
. Una cierta medida de la información tratada y proporcionada por el sistema
Factor de complejidad técnica
que tiene en cuenta diversos
factores (14)
implicados en el desarrollo e implantación de los requisitos del sistema
La aplicación del método se centra en
calcular los puntos de función como unidad de medida
para estimar el tamaño y el esfuerzo necesario para desarrollar cierto sistema.
La métrica de puntos de función es
la más utilizada
. Su recuento se elabora a partir de unas
características funcionales
que pueden ser da datos o de transacción
Características funcionales de datos
Ficheros lógicos internos (LIF) :
grupos de datos interno y propios de la aplicación, interrelacionados lógicamente y que pueden ser claramente identificados. Son los ficheros de la aplicación
Ficheros de interfaces externas (EIF) :
proceden de fuera de los lñimites de la aplicación y se mantienen al margen de ésta. Representan los ficheros o tablas que la aplicación utiliza pero que no crea ni mantiene.
Características funcionales de transacción
Entradas externas (EI) :
elementos que procesan datos o información de control introducidos a la aplicación desde fuera de sus límites.
Salidas externas (EO) :
proceso elemental que genere datos o información de control que salga de los límites de la aplicación.
Consultas externas (EQ) :
proceso elemental formado por una combinación de entrada y salida que permite la recuperación de datos.
Mediante la
ponderación de cada característica funcional
se obtienen
los puntos de función sin ajustar
(TUFP)
Cada uno de los 5 componentes se clasifica
como de complejidad "baja", "media" o "alta", dependiendo del número de elementos de datos de cada tipo y otros factores.
El número total de puntos de función sin ajustar se obtiene sumando los productos del número de elementos de cada tipo y nivel de complejidad por los pesos establecidos para cada característica
Albretch observó que las características funcionales no eran suficientes para definir la complejidad de una aplicación. Añadío
otras 14 características generales del sistema
Comunicación de datos
Procesamiento distribuido de datos
Rendimiento
Configuraciones fuertemente utilizadas
Frecuencia de transacciones
Entrada de datos online
Eficiencia del usuario final
Actualizaciones online
Procesamiento complejo
Reusabilidad
Facilidad de instalación
Facilidad de operación
Instalación múltiple
Facilidad de cambio
Se evalúan de 0 a 5
según su grado de influencia en el sistema y la suma de éstas se denomina
grado total de influencia (TDI)
A partir del TDI se determina el ajuste por la complejidad del proceso (PCA) según la fórmula
PCA = 0.65 + (0.01 x TDI)
FInalmente los puntos de función (FP) se obtienen ajustados y definitivos
FP = TUFP x PCA
Con los puntos de función se puede calcular las
horas-hombre aplicando un factor de conversión (datos históricos de productividad)
.
Puntos de Función Mark-II
:
Planteado por Symmons en 1991, se basa en los Puntos de Función de Albretch, pero intentando paliar algunos problemas del mismo
En vez de utilizar 5 características funcionales se analiza la especificación del sistema desde el punto de vista de las
transacciones-tipo lógicas
Las
interfaces y las consultas
se tratan como una entrada o salida más
Aparece el concepto de
entidad-tipo,
que es un objeto real o abstracto, del universo del discurso acerca del cual el sistema proporciona información
El método se basa en contar para cada transacción-tipo
El número de elementos de entrada y de salida que implica
Las entidades-tipo tratadas o referenciadas
Se calcula los Puntos de Función No Ajustados con la fórmula
UFP = Ni x Wi + Ne x We + No x Wo
Symmonds propone añadir
5 nuevos factores
a los 14 identificados por Albretch
Interfaz con otras aplicaciones
Características de seguridad especiales
Proporcionar acceso directo a terceros
Requisitos de documentación
Facilidades especiales de formación a usuarios
A partir del tamaño total del proyecto, Symmons propone otras fórmulas para determinar..
El esfuerzo total necesario, en función de factores como la productividad por punto de función para determinados entornos de programación
La tasa de tiempo de entrega (puntos de función por semana)
El tiempo total de entrega
Puntos de casos de uso
: es un método de estimación de tamaño y esfuerzo desarrollado por
Karner
basándose en el método de Puntos de Función
Utiliza a los
actores y casos de uso
relevantes para el cálculo
A los
casos de uso
se les asigna una complejidad basada en transacciones, entendidas como una interacción entre el usuario y el sistema
A los
actores
se les asigna una complejidad basada en su tipo, es decir, si son interfaces con usuarios u otros sistemas
Se usan
factores de entorno y de complejidad técnica
para ajustar el resultado
Puntos de caso de uso sin ajustar (UUCP)
UUCP = UAW (factor de peso de los actores sin ajustar)+ UUCW (factor de peso de los casos de uso sin ajustar)
Factor de peso de los actores sin ajustar (UAW)
Se evalúa la complejidad de los actores, determinando si cada actor es una persona u otro sistema, la forma en que este interactúa con el caso de uso y la cantidad de actores de cada tipo
UAW = (nº actores simples x 1) + (nº actores medios x 2) + (nº actores complejos x 3)
Factor de peso de los casos de uso sin ajustar (UUCW)
Basado en transacciones
: se evalúa en función del número de transacciones que se pueden realizar en un caso de uso
Basado en clases de análisis
: se evalúa en función del número de clases que tiene un caso de uso
UUCW = (nº_casos_simples x 5) + (nº casos_medios x 10) + (nº_casos_complejos x 15)
Puntos de caso de uso ajustados (UCP)
UCP = UUCP x TCF x EF
TCF Factores Técnicos
; existen 13 factores que evalúan la complejidad de los módulos del sistema donde cada uno tiene un peso definido, y que se evalúan según su relevancia en el sistema
TFactor = Sum (Peso x Valor)
TCF = 0,6 + (0,01 x TFactor)
EF Factores ambientales
: existen 8 factores que están relacionados con las habilidades y experiencia del grupo de personas involucradas en el desarrollo del proyecto
EFactor = Sum (Peso x Valor)
EF = 1,4 + (-0,03 x EFactor)
Esfuerzo horas-hombre (E)
El esfuerzo en la fase de codificación vendrá dado por la fórmula
E = UCP x CF
(factor de productividad en horas-persona)
Para obtener el factor de productividad se debe contar la cantidad de factores ambientales del E1 al E6 que tienen una influencia menor a 3, y los E7 y E8 con influencia mayor a 3. Con ese valor se acude a una table donde se sacará el CF en horas-persona
Este modelo parte de la base de que la
programación supone el 40%
del esfuerzo total de todo el proyecto.. Se ajustará en base a los datos históricos de la propia organización
MODELOS DE ESTIMACIÓN COCOMO Y COCOMO II (Constructive Cost Model)
Introducción
Es un modelo de estimación
algorítmico
propuesto por Boehm en 1981, que fundamenta su estimación en el número de intrucciones de código fuente (LOC) de los diferentes programas que componen la aplicación que quiere evaluar.
COCOMO clásico o COCOMO 81
Supone que se utiliza el ciclo de vida en cascada y programación en lenguajes imperativos (C, Pascal, etc)
3 versiones según el grado de complejidad que queramos incorporar al cálculo
Básico :
válido para obtener una estimación rápida del orden de magnitud del esfuerzo (meses-hombre) en función del tamaño (KLOC) estimado al inicio del ciclo de vida
Intermedio :
añade el efecto de unos atributos que influyen en el coste (CDA), con los cuales se quiere tener en cuenta el tipo de aplicación y tecnología, la experiencia del personal, el entorno de diseño y programación y las herramientas disponibles
Avanzado :
tiene en cuenta diferentes CDA para cada fase de construcción del software (análisis, diseño y construcción)
Ecuaciones
E = a x L elevado b x CDA
T = C x E elevado d
P = E / T
E : esfuerzo personas-mes
L = líneas de código en KLOC
T : tiempo de desarrollo del proyecto en meses
P : número de personas requerido para el proyecto
CDA : efecto de ciertos atributos
a, b, c , d : coeficientes que el modelo proporciona
3 tipos de proyectos
Orgánico :
proyectos relativamente pequeños y sencillos, con poca innovación tecnológica, pequeño equipo y requerimientos poco rígidos
Semiacoplado :
proyectos de tamaño intermedio, complejidad y sofisticación técnica, con equipos diferentes y requerimientos medianamente rígidos
Empotrado :
proyectos de gran tamaño y complejidad, con varios equipos y los requerimientos son muy rígidos
Según el modelo y el tipo de proyecto se asignan valores a los coeficientes a,b,c y d
El valor de CDA se calcula multiplicando el valor de 15 atributos cuyo valor oscilará según tengan mayor o menos impacto
Hipótesis de base
El
periodo de desarrollo
va desde el análisis funcional hasta la integración de pruebas
Los
requisitos
del sistema no variarán sustancialmente en todo el proyecto
El
número de instrucciones fuente
son aquellas con el proyecto desarrollado, excluyendo las de pruebas, comentarios y programas de utilidad no modificados
Una
persona-mes supone 152 horas
de trabajo
COCOMO II (COCOMO 2000)
Surge en el año 1995 y surge una evolución del mismo COCOMO 2000. Desarrollado también por Boehm
Objetivo :
desarrollar un modelo de estimación de costes y planificación del software adecuado para los
ciclos de vida usados a partir de los 90
(espiral, con prototipos, etc) y las
herramientas de desarrollo rápido
(RAD. Tamién incorpora los
beneficios del análisis de los Puntos de Función
3 modelos
Modelo de composición de aplicación
Utilizado durante las primeras etapas, y se suele utilizar prototipos
El tamaño del software se mide en
puntos aplicación
PM = NAP x ((1 - %Reutilización) / 100) / PROD
PM : esfuerzo estimado en personas-mes
NAP : total de puntos de aplicación en el sistema a desarrollar
%Reutilización : estimación cantidad código reutilizado
PROD : productividad en puntos aplicación/mes, obtenidos de información histórica
Procedimiento
Determinar cantidad de objetos, estimando cantidad de pantallas, listados y otros componentes de programación
Clasificar cada objeto según sus niveles de complejidad (simple, media, alta)
Dar el peso a cada objeto según el nivel de complejidad
Determinar la cantidad de puntos objeto, sumando todos los pesos de los objetos especificados
Modelo de diseño temprano
La estimación se realiza después de que se hayan establecido los
primeros requerimientos
Esfuerzo = 2,94 x (Tam) elevado B x M
Tam (tamaño) : medido en KSLOC (miles de líneas de código fuente) calculado a partir de los Puntos de Función
B : valor que se estima a partir de 5 factores
M : se calcula con 7 caracteristicas o factores de coste que se evalúan de 1 a 6
Modelo de post-arquitectura
Es
el más detallado y preciso
, y se utiliza cuando se conoce el diseño de la arquitectura del sistema y durante la construcción del software
La misma fórmula del modelo de diseño temprano pero con
17 multiplicadores
El tamaño total de código es la suma de 3 partes
Estimación del nº de líneas de código nuevas
Estimación del nº de líneas de código que deben modificarse
Estimación del nº de líneas de código equivalentes para el código que se va a reutilizar