Modelo Orientado Al Tamaño
Modelo Orientado A La Función
Modelo Ampliado De Punto De Función
Modelo Para La Calidad
Modelo Para Organizaciones Pequeñas
Modelo Constructivo de Costos
(COCOMO, por su acrónimo del inglés COnstructive COst MOdel)
Es un modelo matemático de base empírica utilizado para estimación de costos de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).
Modelo básico
Se utiliza para obtener una primera aproximación rápida del esfuerzo.
Hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:
MODO | a | b | c | d |
Orgánico | 2.40 | 1.05 | 2.50 | 0.38 |
Semilibre | 3.00 | 1.12 | 2.50 | 0.35 |
Rígido | 3.60 | 1.20 | 2.50 | 0.32 |
Estos valores son para las fórmulas:
Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
Personas necesarias para realizar el proyecto (CostoH) = MM/TDEV
Costo total del proyecto (CostoM) = CostoH * Salario medio entre los programadores y analistas.
Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno
Modelo intermedio
Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.
Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar.
Los valores de las constantes a reemplazar en la fórmula son:
MODO | a | b |
Orgánico | 3.20 | 1.05 |
Semi_libre | 3.00 | 1.12 |
Rígido | 2.80 | 1.20 |
Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.
Atributos
Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).
El significado de los atributos es el siguiente, según su tipo:
De software
RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad).
DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la relación: D / K, donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.
CPLX: representa la complejidad del producto.
De hardware
TIME: limitaciones en el porcentaje del uso de la CPU.
STOR: limitaciones en el porcentaje del uso de la memoria.
VIRT: volatilidad de la máquina virtual.
TURN: tiempo de respuesta requerido.
De personal
ACAP: calificación de los analistas.
AEXP: experiencia del personal en aplicaciones similares.
PCAP: calificación de los programadores.
VEXP: experiencia del personal en la máquina virtual.
LEXP: experiencia en el lenguaje de programación a usar.
De proyecto
MODP: uso de prácticas modernas de programación.
TOOL: uso de herramientas de desarrollo de software.
SCED: limitaciones en el cumplimiento de la planificación.
El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:
Atributos | Valor | |||||
Muy bajo | Bajo | Nominal | Alto | Muy alto | Extra alto | |
Atributos de software | ||||||
Fiabilidad | 0,75 | 0,88 | 1,00 | 1,15 | 1,40 | |
Tamaño de Base de datos | 0,94 | 1,00 | 1,08 | 1,16 | ||
Complejidad | 0,70 | 0,85 | 1,00 | 1,15 | 1,30 | 1,65 |
Atributos de hardware | ||||||
Restricciones de tiempo de ejecución | 1,00 | 1,11 | 1,30 | 1,66 | ||
Restricciones de memoria virtual | 1,00 | 1,06 | 1,21 | 1,56 | ||
Volatilidad de la máquina virtual | 0,87 | 1,00 | 1,15 | 1,30 | ||
Tiempo de respuesta | 0,87 | 1,00 | 1,07 | 1,15 | ||
Atributos | Valor | |||||||||||
Muy bajo | Bajo | Nominal | Alto | Muy alto | Extra alto | |||||||
Atributos de personal | ||||||||||||
Capacidad de análisis | 1,46 | 1,19 | 1,00 | 0,86 | 0,71 | |||||||
Experiencia en la aplicación | 1,29 | 1,13 | 1,00 | 0,91 | 0,82 | |||||||
Calidad de los programadores | 1,42 | 1,17 | 1,00 | 0,86 | 0,70 | |||||||
Experiencia en la máquina virtual | 1,21 | 1,10 | 1,00 | 0,90 | ||||||||
Experiencia en el lenguaje | 1,14 | 1,07 | 1,00 | 0,95 | ||||||||
Atributos | Valor | ||||||||||
Muy bajo | Bajo | Nominal | Alto | Muy alto | |||||||
Atributos del proyecto | |||||||||||
Técnicas actualizadas de programación | 1,24 | 1,10 | 1,00 | 0,91 | 0,82 | ||||||
Utilización de herramientas de software | 1,24 | 1,10 | 1,00 | 0,91 | 0,83 | ||||||
Restricciones de tiempo de desarrollo | 1,23 | 1,08 | 1,00 | 1,04 | 1,10 | ||||||
Presenta principalmente dos mejoras respecto al anterior:
Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la aplicación, utilización de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y además van variando de una etapa a otra.
Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema.
Modelos empíricos de estimación.
Un modelo empírico de estimación para software puede utilizar fórmulas
derivadas empíricamente para predecir el esfuerzo como una función de LDC y PF. (Líneas De Código Y Punto De Función)
Los datos empíricos que soportan la mayoría de los modelos de estimación se obtienen de una muestra limitada de proyectos.
Es por eso que estos modelos de estimación no son adecuados para todas clases de software y en todos los entornos de desarrollo.
Por consiguiente, los resultados obtenidos de dichos modelos se deben utilizar con prudencia.
Los modelos de estimación se deben evaluar para necesidades particulares.
Entre los muchos modelos de estimación orientados a LDC se encuentran los siguientes:
E = 5.2 x (KLDC)0.91 Modelo de Walston-Felix
E = 5.5 + 0.73 x (KLDC)1.16 Modelo de Bailey-Basisli
E = 3.2 x (KLDC) 1.05 Modelo simple de Boehm
E= 5.288 x (KLDC)1.047 Modelo Doty para KLDC >9
También se han propuesto los modelos orientados a PF.
Entre estos modelos se incluyen:
E = -13.39 + 0.054 PF Modelo de Albretch y Gaffney
E = 60.62 x 7.728 x 10 PF8 Modelo de Kemerer
E = 585. 7 + 15.12 PF Modelo de Matson, Barnett y Mellichamp
Métricas para la Calidad del Software
Indicadores útiles:
Corrección
Grado en que el software desempeña la función para la que fue creado.
Se mide en Defectos por KLOC.
Facilidad de mantenimiento
Sencillez con que un programa puede corregirse si se encuentra un error,
adaptarse si su entorno cambia,o mejorar si el cliente cambia los requisitos.
Se mide en forma indirecta en TMC (tiempo medio de cambio).
Integridad
Habilidad de un sistema para resistir ataques.
Requiere la definición de Amenaza y Seguridad
Integridad = 1 – (amenaza x (1 - seguridad))
Facilidad de Uso
Intento por cuantificar la sencillez de una aplicación al utilizarla.
Eficacia en la eliminación de defectos (EED)
Medida de la habilidad de filtrar las actividades de la garantía de calidad y de control conforme se aplica a través de todas las actividades del marco de trabajo del proceso.
EED = E/(E+D)
E: número de errores encontrados antes de entregar el software al usuario final
D: número de defectos encontrados después de la entrega
También se aplica para valorar la habilidad de encontrar errores antes de pasar a la siguiente actividad del marco de trabajo.
EEDi = Ei/(Ei+Ei+1)
Ei: número de errores encontrados durante la actividad i
Ei+1: número de errores encontrados durante la actividad i+1
Métricas para organizaciones pequeñas
Medidas que se pueden recopilar fácilmente:
Tiempo que transcurre desde que se hace una solicitud hasta que la evaluación esté completa.
Esfuerzo necesario para hacer la evaluación.
Tiempo que transcurre desde que se completa la evaluación hasta que se asigna el pedido de cambio al personal.
Esfuerzo requerido para hacer el cambio.
Tiempo requerido para hacer el cambio.
Errores descubiertos mientras se hacía el cambio.
Defectos descubiertos después de que el cambio es liberado a los clientes.
No hay comentarios:
Publicar un comentario