Métricas de Software
-Modelo Cocomo
El Modelo Constructivo de Costes (o 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 costes1 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).
Características
Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.
Inconvenientes
§ Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
§ Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
§ Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
§ Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
§ La medición por líneas de código no es válida para orientación a objetos.
§ Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).
Modelos de estimación
La ecuaciones que se utilizan en los tres modelos son:2
§ E = a(Kl)b * m(X), en persona-mes
§ Tdev = c(E)d, en meses
§ P = E / Tdev, en personas
donde:
§ E es el esfuerzo requerido por el proyecto, en persona-mes
§ Tdev es el tiempo requerido por el proyecto, en meses
§ P es el número de personas requerido por el proyecto
§ a, b, c y d son constantes con valores definidos en una tabla, según cada submodelo
§ Kl es la cantidad de líneas de código, en miles.
§ m(X) Es un multiplicador que depende de 15 atributos.
A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:
§ modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).
§ modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.
§ modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.
Modelo básico
Artículo principal: COCOMO Básico
Se utiliza para obtener una primera aproximación rápida del esfuerzo,2 y 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 (CosteH) = MM/TDEV
§ Costo total del proyecto (CosteM) = CosteH * 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.2
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 |
| Semilibre | 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.
Modelo Detallado
Presenta principalmente dos mejoras respecto al anterior:2
§ 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.
Modelo 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). Esta 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
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.
ADA COCOMO
Barrí Bohema & Walter Rocíe, 1987, 1988 definen el nuevo modelo COCOMO, llamado “Ada COCOMO”.
Este modelo al igual que el COCOMO estándar utiliza los manejadores de costo y ecuaciones anteriormente definidas.
COCOMO INCREMENTAL
Fue definido casi al mismo tiempo que Ada COCOMO. EL modelo COCOMO Incremental es una moderna alternativa para el tradicional modelo cascada de el desarrollo de procesos de software.
El modelo de desarrollo Incremental COCOMO permite una variedad de desarrollo de procesos. En vez de modelar el software como a esfuerzo simple para obtener un producto simple; el modelo incremental COCOMO permite desarrollar una serie de proyectos de software concurrente y producir un producto intermedio.
Esta estrategia reduce risk y permite entregar un producto inicial más fácilmente al cliente.
También existen algunas derivaciones de COCOMO como ser:
- Cocots, (Constructive Cost)
- Cossemo, (Constructive Staged Schedule & Effort Model).
- Copromo, (Constructive Productivity Improvement Model).
- Coqualmo
- Coradmo
- CONCLUSIONES
Al realizar el trabajo de investigación acerca de COCOMO llegamos a las siguientes conclusiones:
- COCOMO es una herramienta basada en la líneas de código la cual le hace muy poderoso para la estimación de costos y no como otros que solamente miden el esfuerzo en base al tamaño.
- Hoy en día es necesario para un administrador de proyectos posser una herramienta de estimación de costos; y esta herramienta puede ser COCOMO.
- COCOMO representa el más extenso modelo empírico para la estimación de software publicado hasta la fecha.
- Existen herramientas automáticas que estiman costos basados en COCOMO como ser: Costar, COCOMO 81.
- Con la realización de este trabajo ampliamos nuestro conocimientos acerca de la estimación de costos que es fundamental para un analista, administrador de proyecto.
Métrica Orientada a la Función
Las métricas del Software orientadas a la función utilizan una medida de la funcionalidad entregada por la aplicación como un valor de normalización.
El punto de función proviene de las medidas del dominio de información y de una evaluación subjetiva de la complejidad del problema.
Los puntos de función se calculan y se completan en una tabla diseñada para tal fin. Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de los dominios de información se definen de la siguiente manera:
Número de Entradas de Usuarios; se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Se deben diferenciar las entradas de las peticiones, ya que se cuentan en forma separada.
Número de Salidas de Usuario: se cuenta cada salida que proporciona al usuario información orientada a la aplicación. Las salidas serán: informes, pantallas, mensajes de error.
Número de Peticiones de Usuario: una petición se define como una entrada interactiva que produce la generación de alguna respuesta del Software inmediata en forma de salida interactiva.
Número de Archivos: se cuenta cada archivo maestro lógico, es decir, un grupo lógico de datos que puede conformar una Base de datos o un archivo independiente.
Número de Interfaces Externas: se cuentan todas las interfaces legibles por la máquina que se utilizan para transmitir información a otro sistema.
Una vez calculados los puntos de función se utilizan de forma análoga a los LDC como forma de normalizar las medidas de productividad, calidad y otros atributos del Software.
El punto de función proviene de las medidas del dominio de información y de una evaluación subjetiva de la complejidad del problema.
Los puntos de función se calculan y se completan en una tabla diseñada para tal fin. Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de los dominios de información se definen de la siguiente manera:
Número de Entradas de Usuarios; se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Se deben diferenciar las entradas de las peticiones, ya que se cuentan en forma separada.
Número de Salidas de Usuario: se cuenta cada salida que proporciona al usuario información orientada a la aplicación. Las salidas serán: informes, pantallas, mensajes de error.
Número de Peticiones de Usuario: una petición se define como una entrada interactiva que produce la generación de alguna respuesta del Software inmediata en forma de salida interactiva.
Número de Archivos: se cuenta cada archivo maestro lógico, es decir, un grupo lógico de datos que puede conformar una Base de datos o un archivo independiente.
Número de Interfaces Externas: se cuentan todas las interfaces legibles por la máquina que se utilizan para transmitir información a otro sistema.
Una vez calculados los puntos de función se utilizan de forma análoga a los LDC como forma de normalizar las medidas de productividad, calidad y otros atributos del Software.
2.4.3. Métricas Ampliadas de Punto de Función
La medida de punto de función individualmente se diseño para aplicarse a sistemas de gestión, pero resultaba inadecuada para otros sistemas de Ingeniería y sistemas empotrados que enfatizan función y control, en consecuencia se propuso extender el punto de función básica.
Una extensión del punto de función es la llamada puntos de características, el cual constituye una ampliación de la medida del punto de función que se puede aplicar a sistemas y aplicaciones de ingeniería del Software en tiempo real, de control y de proceso por la complejidad de sus algoritmos.
Los algoritmos definen un problema de cálculo limitado que se incluye dentro de un programa de computadora específico.
Las características de las tres dimensiones del Software se cuentan, cuantifican y transforman en una medida que proporciona una indicación de la funcionalidad entregada por el Software, llamada punto de función.
La dimensión de datos se calcula tal cual se explico en el punto de función básico.
La dimensión funcional se mide considerando el número de operaciones internas requeridas para transformar datos de entrada en datos de salida.
La dimensión de control se mide contando el número de transiciones entre estados. Un estado representa algún modo de comportamiento externamente observable, y una transición ocurre como resultado de algún suceso que cambia el modo de comportamiento del Software.
Métricas Orientadas a la Calidad
La Ingeniería del Software tiene como objetivo principal producir un sistema o aplicación de alta calidad, para lograr esta evaluación de la calidad en tiempo real se deben utilizar medidas técnicas que evalúan la calidad con objetividad y no subjetivamente.
La calidad de un sistema debe ser tan buena como los requerimientos que describen el problema, el diseño que modela la solución, el código que conduce el programa y las pruebas que se aplican al Software para detectar errores.
Los Ingenieros del Software utilizan para lograr el Software de alta calidad mediciones que evalúan la calidad del análisis, modelos de diseño, código fuente y los casos de prueba que se preparan para aplicar al sistema o Software desarrollado con la finalidad de detectar fallas o errores a fin de mejorar y conseguir la máxima calidad del producto.
La calidad de un sistema debe ser tan buena como los requerimientos que describen el problema, el diseño que modela la solución, el código que conduce el programa y las pruebas que se aplican al Software para detectar errores.
Los Ingenieros del Software utilizan para lograr el Software de alta calidad mediciones que evalúan la calidad del análisis, modelos de diseño, código fuente y los casos de prueba que se preparan para aplicar al sistema o Software desarrollado con la finalidad de detectar fallas o errores a fin de mejorar y conseguir la máxima calidad del producto.
2.5.1 Visión General de los Factores que afectan a la Calidad
Los factores de calidad empleados para el desarrollo de métricas de calidad de Software, evalúan el Software desde tres puntos de vista:
Operación del producto
Revisión del producto
Transición del producto, cuando se modifica para que funcione en otro entorno.
La relación entre estos factores de calidad constituye un mecanismo para que el gestor del proyecto identifique lo que se considera realmente importante. Estas cualidades son atributos del Software, además de su corrección y rendimiento funcional, que tiene implicaciones en el ciclo de vida, se deben considerar otros factores como lo son la facilidad de mantenimiento y portabilidad.
El marco de trabajo proporciona además un medio de evaluar cuantitativamente el avance del desarrollo en relación con los objetivos de calidad establecidos, aunado a la interacción del personal QA (garantía de calidad) en el esfuerzo desarrollo y la utilización de estándares e indicadores que puedan ser utilizados en proyectos futuros; por ejemplo una lista de verificación.
Operación del producto
Revisión del producto
Transición del producto, cuando se modifica para que funcione en otro entorno.
La relación entre estos factores de calidad constituye un mecanismo para que el gestor del proyecto identifique lo que se considera realmente importante. Estas cualidades son atributos del Software, además de su corrección y rendimiento funcional, que tiene implicaciones en el ciclo de vida, se deben considerar otros factores como lo son la facilidad de mantenimiento y portabilidad.
El marco de trabajo proporciona además un medio de evaluar cuantitativamente el avance del desarrollo en relación con los objetivos de calidad establecidos, aunado a la interacción del personal QA (garantía de calidad) en el esfuerzo desarrollo y la utilización de estándares e indicadores que puedan ser utilizados en proyectos futuros; por ejemplo una lista de verificación.
2.5.2. Medidas de la Calidad
Entre las medidas de la calidad del Software más utilizadas se tienen:
Corrección: el valor agregado de un programa depende de que opere o funcione correctamente. La medida más común de corrección es defectos por KLDC, en donde un defecto se define como una falta verificada de conformidad con los requisitos.
Facilidad de mantenimiento: se refiere a la facilidad con la que se puede corregir un programa si se detecta un error, donde se puede adaptar sí su entorno cambia, o mejorar si el cliente desea un cambio de requisitos. Se recomienda utilizar medidas indirectas. Por otro lado, también se puede utilizar una métrica orientada al costo para la capacidad de mantenimiento llamada Desperdicios, la cual se refiere al coste en corregir defectos encontrados después de haber distribuido el Software a sus usuarios finales.
Integridad: este atributo mide la capacidad de un sistema para resistir ataques accidentales o intencionados contra su seguridad. El ataque se puede realizar en cualquiera de los tres componentes del Software: programas, datos y documentos.
Corrección: el valor agregado de un programa depende de que opere o funcione correctamente. La medida más común de corrección es defectos por KLDC, en donde un defecto se define como una falta verificada de conformidad con los requisitos.
Facilidad de mantenimiento: se refiere a la facilidad con la que se puede corregir un programa si se detecta un error, donde se puede adaptar sí su entorno cambia, o mejorar si el cliente desea un cambio de requisitos. Se recomienda utilizar medidas indirectas. Por otro lado, también se puede utilizar una métrica orientada al costo para la capacidad de mantenimiento llamada Desperdicios, la cual se refiere al coste en corregir defectos encontrados después de haber distribuido el Software a sus usuarios finales.
Integridad: este atributo mide la capacidad de un sistema para resistir ataques accidentales o intencionados contra su seguridad. El ataque se puede realizar en cualquiera de los tres componentes del Software: programas, datos y documentos.
No hay comentarios:
Publicar un comentario