Modelo COCOMO
Entre los distintos métodos de estimación de costes de desarrollo de software, el modelo COCOMO (COnstructive COst MOdel) desarrollado por Barry M. Boehm, se engloba en el grupo de los modelos algorítmicos que tratan de establecer una relación matemática la cual permite estimar el esfuerzo y tiempo requerido para desarrollar un producto.
COCOMO permite estimar cómo se distribuye el esfuerzo y el tiempo en las distintas fases del desarrollo de un proyecto y dentro de cada fase, en las actividades principales. Las fases consideradas por COCOMO son:
Diseño del Producto (PD)
Se define la arquitectura del hardware, software y las estructuras de datos y control.
También se desarrolla un bosquejo del manual del usuario y los planes de aceptación y testeo.
Diseño Detallado (DD)
Codificación y Testeo de Unidades (CT)
En estas dos fases el diseño global de la fase anterior es implementado, creando las componentes de software, que son testeadas y evaluadas individualmente.
Integración y Testeo (IT)
Se fusionan todas las componentes de software desarrolladas con el fin de lograr que el producto de software funcione correctamente. Los requerimientos definidos son usados para controlar las aptitudes del producto liberado.
Los costos y tiempos de las fases excluidas (Requerimientos y Mantenimiento) deben ser estimados en forma separada empleando otros modelos.
Se distinguen las siguientes actividades principales:
Análisis de Requerimientos
Determinación, especificación, revisión y actualización de la funcionalidad, performance e interface del software
Por un lado COCOMO define tres modos de desarrollo o tipos de proyectos:
· Orgánico: proyectos relativamente sencillos, menores de 50 KDLC líneas de código, en los cuales se tiene experiencia de proyectos similares y se encuentran en entornos estables.
· Semi-acoplado: proyectos intermedios en complejidad y tamaño (menores de 300 KDLC), donde la experiencia en este tipo de proyectos es variable, y las restricciones intermedias.
· Empotrado: proyectos bastante complejos, en los que apenas se tiene experiencia y se engloban en un entorno de gran innovación técnica. Además se trabaja con unos requisitos muy restrictivos y de gran volatilidad.
Y por otro lado existen diferentes modelos que define COCOMO:
· Modelo básico: Se basa exclusivamente en el tamaño expresado en LDC.
· Modelo intermedio: Además del tamaño del programa incluye un conjunto de medidas subjetivas llamadas conductores de costes.
· Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto de cada conductor de coste en las distintas fases de desarrollo.
Para nuestro caso el modelo intermedio será el que usaremos, dado que realiza las estimaciones con bastante precisión.
Así pues las fórmulas serán las siguientes:
· E = Esfuerzo = a KLDC e * FAE (persona x mes)
· T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)
· P= Personal = E/T (personas)
Para calcular el Esfuerzo, necesitaremos hallar la variable KDLC (Kilo-líneas de código), donde los PF son 261,36 (dato conocido) y las líneas por cada PF equivalen a 32 según vemos en la tabla que se ilustra a continuación:
LENGUAJE | |
Ensamblador | 320 |
C | 150 |
COBOL | 105 |
Pascal | 91 |
Prolog/LISP | 64 |
C++ | 64 |
 Visual Basic | 32 |
SQL | 12 |
Así pues tras saber que son 32 LDC por cada PF, por el hecho de ser Visual Basic el resultado de los KDLC será el siguiente:
KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363 KDLC
Así pues, en nuestro caso el tipo orgánico será el más apropiado ya que el número de líneas de código no supera los 50 KLDC, y además el proyecto no es muy complejo, por consiguiente, los coeficientes que usaremos serán las siguientes:
Proyecto Software | a | e | c | d |
Orgánico | 3,2 | 1,05 | 2,5 | 0,38 |
Semi-acoplado | 3,0 | 1,12 | 2,5 | 0,35 |
Empotrado | 2,8 | 1,20 | 2,5 | 0,32 |
Y por otro lado también hemos de hallar la variable FAE, la cual se obtiene mediante la multiplicación de los valores evaluados en los diferentes 15 conductores de coste que se observan en la siguiente tabla:
Conductores de coste | VALORACIÓN | |||||
Muy bajo | Bajo | Nominal | Alto | Muy alto | Extr. alto | |
Fiabilidad requerida del software | 0,75 | 0,88 | 1.00 | 1,15 | 1,40 | - |
Tamaño de la base de datos | - | 0,94 | 1.00 | 1,08 | 1,16 | - |
Complejidad del producto | 0,70 | 0,85 | 1.00 | 1,15 | 1,30 | 1,65 |
Restricciones del tiempo de ejecución | - | - | 1.00 | 1,11 | 1,30 | 1,66 |
Restricciones del almacenamiento principal | - | - | 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 del ordenador | - | 0,87 | 1.00 | 1,07 | 1,15 | - |
Capacidad del analista | 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 | - |
Capacidad de los programadores | 1,42 | 1,17 | 1.00 | 0,86 | 0,70 | - |
Experiencia en S.O. utilizado | 1,21 | 1,10 | 1.00 | 0,90 | - | - |
Experiencia en el lenguaje de programación | 1,14 | 1,07 | 1.00 | 0,95 | - | - |
Prácticas de programación modernas | 1,24 | 1,10 | 1.00 | 0,91 | 0,82 | - |
Utilización de herramientas software | 1,24 | 1,10 | 1.00 | 0,91 | 0,83 | - |
Limitaciones de planificación del proyecto | 1,23 | 1,08 | 1.00 | 1,04 | 1,10 | - |
FAE=1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,70*1,00*0,95*1,00*0,91*1,08 = 0,53508480
Justificación de los valores:
Atributos de software
· Fiabilidad requerida del software: Si se produce un fallo por el pago de un pedido, o fallo en alguna reserva, etc... puede ocasionar grandes pérdidas a la empresa (Valoración Alta).
· Tamaño de la base de datos: La base de datos de nuestro producto será de tipo estándar (Valoración Nominal).
· Complejidad del producto: La aplicación no va a realizar cálculos complejos (Valoración Baja).
Atributos de hardware
· Restricciones del tiempo de ejecución: En los requerimientos se exige alto rendimiento (Valoración Alta).
· Restricciones del almacenamiento principal: No hay restricciones al respecto (Valoración Nominal).
· Volatilidad de la máquina virtual: Se usarán sistemas de la “Familia Windows” (Valoración Nominal).
· Tiempo de respuesta del ordenador: Deberá ser interactivo con el usuario (Valoración Alta).
Atributos del personal
· Capacidad del analista: Capacidad alta relativamente, debido a la experiencia en análisis en proyecto similar (Valoración Alta)
· Experiencia en la aplicación: Se tiene cierta experiencia en aplicaciones de esta envergadura (Valoración muy alta).
· Capacidad de los programadores: Teóricamente deberá tenerse una capacidad muy alta por la experiencia en anteriores proyectos similares (Valoración muy alta).
· Experiencia en S.O. utilizado: Con Windows 2000 Professional la experiencia es a nivel usuario (Valoración Nominal).
· Experiencia en el lenguaje de programación: Es relativamente alta, dado que se controlan las nociones básicas y las propias del proyecto (Valoración Alta).
Atributos del proyecto
· Prácticas de programación modernas: Se usarán prácticas de programación mayormente convencional (Valoración Nominal).
· Utilización de herramientas software: Se usarán herramientas estándar que no exigirán apenas formación, de las cuales se tiene cierta experiencia (Valoración Alta).
· Limitaciones de planificación del proyecto: Existen pocos límites de planificación. (Valoración Baja).
Cálculo del esfuerzo del desarrollo:
E = a KLDC e * FAE = 3,2 * (8.363)^1,05 * 0,53508480 = 15,91 personas /mes
Cálculo tiempo de desarrollo:
T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses
Productividad:
PR = LDC/Esfuerzo = 8363/15,91 = 525 ,64 LDC/personas mes
Personal promedio:
P = E/T = 15,91/7,15 = 2,22 personas
Según estas cifras será necesario un equipo de 3 personas trabajando alrededor de 7 meses, pero puesto que el desarrollo del proyecto debe realizarse en un plazo 3 meses, incrementaremos a 6 personas el número de personas del equipo de proyecto (ya que 15,91/3 nos da alrededor de este resultado).
Así pues tendremos un equipo formado por 1 Jefe de proyecto, 2 Analistas, 2 programadores y 1 Responsable de calidad.
Modelo COCOMO II
Los objetivos principales que se tuvieron en cuenta para construir el modelo COCOMO II fueron:
Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que se adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras. Construir una base de datos de proyectos de software que permitiera la calibración continua del modelo, y así incrementar la precisión en la estimación. Implementar una herramienta de software que soportara el modelo.
Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en las diferentes etapas del ciclo de vida de desarrollo.
COCOMO II está compuesto por tres modelos denominados: Composición de Aplicación,
Diseño Temprano y Post-Arquitectura.
Éstos surgen en respuesta a la diversidad del mercado actual y futuro de desarrollo de software. Esta diversidad podría representarse con el siguiente esquema.
Aplicaciones desarrolladas por Usuarios Finales: En este sector se encuentran las aplicaciones de procesamiento de información generadas directamente por usuarios finales, mediante la utilización de generadores de aplicaciones tales como planillas de cálculo, sistemas de consultas, etc. Estas aplicaciones surgen debido al uso masivo de estas herramientas, conjuntamente con la presión actual para obtener soluciones rápidas y flexibles.
Generadores de Aplicaciones: En este sector operan firmas como Lotus, Microsoft, Novell,
Borland con el objetivo de crear módulos pre-empaquetados que serán usados por usuarios finales y programadores.
Aplicaciones con Componentes: Sector en el que se encuentran aquellas aplicaciones que son específicas para ser resueltas por soluciones pre-empaquetadas, pero son lo suficientemente simples para ser construidas a partir de componentes interoperables.
Componentes típicas son constructores de interfaces gráficas, administradores de bases de datos, buscadores inteligentes de datos, componentes de dominio-específico (medicina, finanzas, procesos industriales, etc.). Estas aplicaciones son generadas por un equipo reducido de personas, en pocas semanas o meses.
Sistemas Integrados: Sistemas de gran escala, con un alto grado de integración entre sus componentes, sin antecedentes en el mercado que se puedan tomar como base. Porciones de estos sistemas pueden ser desarrolladas a través de la composición de aplicaciones. Entre las empresas que desarrollan software representativo de este sector, se encuentran grandes firmas que desarrollan software de telecomunicaciones, sistemas de información corporativos, sistemas de control de fabricación, etc.
Infraestructura: Área que comprende el desarrollo de sistemas operativos, protocolos de redes, sistemas administradores de bases de datos, etc. Incrementalmente este sector direccionará sus soluciones, hacia problemas genéricos de procesamiento distribuido y procesamiento de transacciones, a soluciones middleware. Firmas representativas son
Microsoft, Oracle, SyBase, Novell y NeXT.
Los tres modelos de COCOMO II se adaptan tanto a las necesidades de los diferentes sectores descriptos, como al tipo y cantidad de información disponible en cada etapa del ciclo de vida de desarrollo, lo que se conoce por granularidad de la información.
Se puede afirmar que para las aplicaciones desarrolladas por usuarios finales no se justifica la utilización de un modelo de estimación de costos. Estas aplicaciones normalmente se construyen en poco tiempo, por lo tanto requieren solamente una estimación basada en actividades.
El modelo Composición de Aplicación, es el modelo de estimación utilizado en los proyectos de software que se construyen a partir de componentes pre-empaquetadas. En este caso, se emplean Puntos Objeto para estimar el tamaño del software, lo cual está acorde al nivel de información que generalmente se tiene en la etapa de planificación, y el nivel de precisión requerido en la estimación de proyectos de esta naturaleza.
Para los demás sectores del mercado se aplica un modelo mixto, combinación de los tres modelos.
El modelo Composición de Aplicación se emplea en desarrollos de software durante la etapa de prototipo.
El modelo Diseño Temprano se utiliza en las primeras etapas del desarrollo en las cuales se evalúan las alternativas de hardware y software de un proyecto. En estas etapas se tiene poca información, lo que concuerda con el uso de Puntos Función6, para estimar tamaño y el uso de un número reducido de factores de costo.
El modelo Post-Arquitectura se aplica en la etapa de desarrollo propiamente dicho, después que se define la arquitectura del sistema, y en la etapa de mantenimiento. Este modelo utiliza:
Puntos Función y/o Líneas de Código Fuente7 para estimar tamaño, con modificadores que contemplan el re-uso, con y sin traducción automática, y el "desperdicio" (breakage).
Un conjunto de 17 atributos, denominados factores de costo9, que permiten considerar características del proyecto referentes al personal, plataforma de desarrollo, etc., que tienen injerencia en los costos.
Cinco factores que determinan un exponente, que incorpora al modelo el concepto de des economía y economía de escala. Estos factores reemplazan los modos Orgánico,
Semiacoplado y Empotrado del modelo COCOMO.
Métricas ampliadas de punto de función.
Los puntos de función fueron diseñados originalmente para sistemas de información y por eso le da más importancia a los datos y menos a los aspectos de control y funcionales. Para subsanar esto, se han propuesto los puntos de característica y los puntos de función 3D.
Puntos de característica.
Se calcula igual que el punto de función y solo agrega la cuenta de algoritmos. En este contexto se define un algoritmo como un problema de cálculo limitado que se incluye dentro de un programa de computadora específico. Invertir una matriz, decodificar un string o manejar una interrupción son ejemplos de algoritmos.
Puntos de función 3D.
Los puntos de función 3D se calculan llenando la siguiente tabla:
donde:
Ø Estructuras internas de datos: Son arreglos, listas ligadas, pilas, colas, etc.
Datos externos. Equivale a la suma de los archivos y las interfaces externas tal y como están definidos para el punto de función.
Ø Entradas de usuario: Definidas igual que para el punto de función.
Ø Salidas de usuario: Definidas igual que para el punto de función.
Ø Peticiones de usuario: Definidas igual que para el punto de función.
Ø Transformaciones: Son las operaciones internas requeridas para transformar datos de entrada en datos de salida. Multiplicar dos matrices cuenta como una transformación. Leer datos de un archivo y guardarlos en memoria no.
Ø Transiciones: Ocurre cuando el software pasa de un estado a otro como resultado de algún suceso. En un sistema de altas, bajas y cambios, al tomar la opción de altas, pasa del estado "menú principal" al estado "procesa altas" y puede ser que en ese momento pida datos para dar la alta.
Indicaciones:
Ø Para cada medida, contar por separado, de acuerdo a algún criterio de asignación de complejidad, las veces que aparezca con complejidad baja, media y alta.
Ø Para cada medida, multiplicar cada cuenta por el factor de complejidad correspondiente, sumar las tres cantidades y escribir el total en la columna de la extrema derecha.
Ø Sumar la columna de la extrema derecha y obtener el punto de función 3D.
Funcionalidad de los lenguajes de programación:
La tabla siguiente proporcional estimaciones informales del número de líneas de código que se necesitan para construir un punto de función en varios lenguajes de programación:
Observando la tabla podemos decir que, en promedio, un programa en ensamblador tendrá 320/128 = 2.5 veces más líneas de código que un programa en C que haga lo mismo, y casi 11 veces más que un lenguaje orientado a objetos (OOL) con la misma funcionalidad.
Métricas Orientadas a la Calidad
El gestor de proyectos también debe evaluar la calidad objetivamente, y no subjetivamente. A medida que el proyecto progresa el gestor del proyecto también debe evaluar la calidad. Las métricas privadas recopiladas por ingenieros del software particulares se asimilan para proporcionar resultados en los proyectos. Aunque se pueden recopilar muchas medidas de calidad, el primer objetivo en el proyecto es medir errores y defectos. Las métricas que provienen de estas medidas proporcionan una indicación de la efectividad de las actividades de control y de la garantía de calidad en grupos o en particulares
Visión general de los factores que afectan a la calidad
Hace 25 años, McCall y Cavano definieron un juego de factores de calidad como los primeros pasos hacia el desarrollo de métricas de la calidad del software. Estos factores evalúan el software desde tres puntos de vista distintos:
(1) Operación del producto (utilizándolo), (2) revisión del producto (cambiándolo), y (3) transición del producto (modificándolo para que funcione en un entorno diferente, por ejemplo, «portándolo»). Los autores, en su trabajo, describen la relación entre estos factores de calidad (lo que llaman un «marco de trabajo») y otros aspectos del proceso de ingeniería del software:
En primer lugar, el marco de trabajo proporciona un mecanismo para que el gestor del proyecto identifique lo que considera importante. Estas cualidades son atributos del software, además de su corrección y rendimiento funcional, que tiene implicaciones en el ciclo de vida. En otros factores, como son facilidad de mantenimiento y portabilidad, se ha demostrado que tienen un impacto significativo en el coste del ciclo de vida.. .
En segundo lugar, el marco de trabajo proporciona un medio de evaluar cuantitativamente lo bien que va progresando el desarrollo en relación con los objetivos de calidad establecidos.. .
En tercer lugar, el marco de trabajo proporciona más interacción del personal de QA (garantía de calidad) en el esfuerzo de desarrollo....
Por Último,. . . el personal de garantía de calidad puede utilizar indicaciones de calidad pobre para ayudar a identificar estándares [mejores] a enfrentar en el futuro.
Un estudio detallado del marco de trabajo de McCall y Cavano, así como otros factores de calidad, se presentan en el Capítulo 19. Es interesante destacar que casi todos los aspectos del cálculo han sufrido cambios radicales con el paso de los años desde que McCall y Cavano hicieron su trabajo, con gran influencia, en 1978.
Pero los atributos que proporcionan una indicación de la calidad del software siguen siendo los mismos.
Medida de la calidad
Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de mantenimiento, integridad, y facilidad de uso proporcionan indicadores Útiles para el equipo del proyecto. Gilb ha sugerido definiciones y medidas para cada uno de ellos.
Corrección. Un programa debe operar correctamente o proporcionará poco valor a sus usuarios. La corrección es el grado en el que el software lleva a cabo su función requerida. 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. El mantenimiento del software cuenta con más esfuerzo que cualquier otra actividad de ingeniería del software. La facilidad de mantenimiento es la facilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entorno cambia, o mejorar si el cliente desea un cambio de requisitos. No hay forma de medir directamente la facilidad de mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una simple métrica orientada al tiempo es el tiempo medio de cambio (TMC), es decir el tiempo que se tarda en analizar la petición de cambio, en diseñar una modificación adecuada, en implementar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. Como media, los programas que se pueden mantener tendrán un TMC más bajo (para tipos equivalentes de cambios) que los programas que no son más fáciles de mantener. Hitachi ha utilizado una métrica orientada al coste para la capacidad de mantenimiento llamada «desperdicios» consta en corregir defectos encontrados después de haber distribuido el software de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad.
El ataque se puede realizar en cualquiera de los tres componentes del software: programas, datos y documentos. Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. Amenaza es la probabilidad (que se puede estimar o deducir de la evidencia empírica) de que un ataque de un tipo determinado ocurra en un tiempo determinado. La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia empírica) de que se pueda repeler el ataque de un tipo determinado. La integridad del sistema se puede definir como: integridad = C [(1 - amenaza) x (1 - seguridad)] donde se suman la amenaza y la seguridad para cada tipo de ataque.
Facilidad de uso. El calificativo «amigable con el usuario» se ha convertido en omnipresente en las discusiones sobre productos de software. Si un programa no es «amigable con el usuario», frecuentemente está abocado al fracaso, incluso aunque las funciones que realice sean valiosas. La facilidad de uso es un intento de cuantificar «lo amigable que puede ser con el usuario
» Y se puede medir en función de cuatro características:
(1) Habilidad intelectual y/o física requerida para aprender el sistema; (2) el tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema;
(3) aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien utiliza el sistema moderadamente y eficientemente; y (4) valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema.
Eficacia de la Eliminación de Defectos
Una métrica de la calidad que proporciona beneficios tanto a nivel del proyecto como del proceso, es la eficacia de la eliminación de defectos (EED). Cuando un proyecto se toma en consideración globalmente, EED se define de la forma siguiente:
EED = E / (E + D) (4.4)
Donde E es el número de errores encontrados antes de la entrega del software al usuario final y D es el número de defectos encontrados después de la entrega.
El valor ideal de EED es 1. Esto es, no se han encontrado defectos en el software. De forma realista, D será mayor que cero, pero el valor de EED todavía se puede aproximar a 1. Cuando E aumenta (para un valor de D dado), el valor total de EED empieza a aproximarse a 1. De hecho, a medida que E aumenta, es probable que el valor final de D disminuya (los errores se filtran antes de que se conviertan en defectos). Si se utilizan como una métrica que proporciona un indicador de la habilidad de filtrar las actividades de la garantía de la calidad y del control, EED anima a que el equipo del proyecto de software instituya técnicas para encontrar todos los errores posibles antes de su entrega.
EED también se puede utilizar dentro del proyecto para evaluar la habilidad de un equipo en encontrar errores antes de que pasen a la siguiente actividad estructural o tarea de ingeniería del software. Por ejemplo, la tarea del análisis de los requisitos produce un modelo de análisis que se puede revisar para encontrar y corregir errores. Esos errores que no se encuentren durante la revisión del modelo de análisis se pasan a la tarea de diseño (en donde se pueden encontrar o no). Cuando se utilizan en este contexto, EED se vuelve a definir como:
EEDi = Ei / (Ei + Ei + I) (4.5)
En donde Ei es el número de errores encontrado durante la actividad de ingeniería del software i y Ei es el número de errores encontrado durante la actividad de ingeniería del software i + I que se puede seguir para llegar a errores que no se detectaron en la actividad de la ingeniería del software i.
Métricas para organizaciones pequeñas
La amplia mayoría de las organizaciones de desarrollo de software tienen menos de 20 personas dedicadas al software. Es poco razonable, y en la mayoría de los casos no es realista, esperar que organizaciones como éstas desarrollen programas métricos de software extensos. Sin embargo, si que es razonable sugerir que organizaciones de software de todos los tamaños midan y después utilicen las métricas resultantes para ayudar a mejorar sus procesos de software local y la calidad y oportunidad de los productos que realizan. Kautz describe un escenario típico que ocurre cuando se piensa en programas métricos para organizaciones pequeñas de software: Originalmente, los desarrolladores de software acogían nuestras actividades con un alto grado de escepticismo, pero al final las aceptaban debido a que nosotros conseguíamos que nuestras medidas fueran simples de realizar, adaptadas a cada organización y se aseguraba que dichas medidas producían una información válida y útil. Al final, los programas proporcionaban una base para encargarse de los clientes y para la planificación y desarrollo de su trabajo futuro.
Lo que Kautz sugiere es una aproximación para la implementación de cualquier actividad relacionada con el proceso del software: que sea simple; adaptada a satisfacer las necesidades locales y que se constate que realmente añada valor. En los párrafos siguientes examinamos cómo se relacionan estas líneas generales con las métricas utilizadas para negocios pequeños.
«Para hacerlo fácil», es una línea de acción que funciona razonablemente bien en muchas actividades. Pero ¿cómo deducimos un conjunto sencillo de métricas de software que proporcionen valor, y cómo podemos estar seguros de que estas métricas sencillas lograran satisfacer las necesidades de una organización de software particular? Comenzamos sin centrarnos en la medición, pero sí en los resultados finales. El grupo de software es interrogado para que defina un objetivo simple que requiera mejora. Por ejemplo, «reducir el tiempo para evaluar e implementar las peticiones de cambio». Una organización pequeña puede seleccionar el siguiente conjunto de medidas fácilmente recolectables:
Tiempo (horas o días) que transcurren desde el momento que es realizada una petición hasta que se complete su evaluación, tcola.
Es fuerzo (horas-persona) para desarrollar la evaluación, WeVa1.
Tiempo (horas o días) transcurridos desde la terminación de la evaluación a la asignación de una orden de cambio al personal, teval.
Esfuerzo (horas-persona) requeridas para realizar el cambio, Wcambio.
Tiempo requerido (horas o días) para realizar el cambio
Errores descubiertos durante el trabajo para realizar el cambio, Ecambio.
bio, t,-,bio*
Una vez que estas medidas han sido recogidas para un cierto número de peticiones de cambio, es posible calcular el tiempo total transcurrido desde la petición de cambio hasta la implementación de dicho cambio y el porcentaje de tiempo consumido por el proceso de colas iniciales, la asignación de cambio y evaluación, y la implementación del cambio propiamente dicho. De forma similar, el porcentaje de esfuerzo requerido para la evaluación y la implementación puede también ser determinado.
Estas métricas pueden ser evaluadas en el contexto de los datos de calidad, Ecambio y DcanIbio Los porcentajes proporcionan un análisis interno para buscar el lugar donde los procesos de petición de cambio se ralentizan y pueden conducir a unos pasos de mejoras de proceso para reducir tco!a ' wevgl i.teva [; Wcambioy y/o Ecambio* la eficiencia de eliminación de defectos (EED) puede ser calculada de la siguiente manera:
EED = Ecambio ' (Ecambio + Dcamhio)
EED puede compararse con el tiempo transcurrido y el esfuerzo total para determinar el impacto de las actividades de aseguramiento de la calidad sobre el tiempo y el esfuerzo requeridos para realizar un cambio.
Para grupos pequeños, el coste de incorporar medidas y métricas de cálculo oscila entre el 3 y el 8 % del presupuesto del proyecto durante la fase de aprendizaje y después cae a menos del del presupuesto del proyecto una vez que la ingeniería del software y la gestión de proyectos se hayan familiarizado con el programa de métricas. Estos costes pueden representar una mejora de las inversiones siempre que el análisis derivado a partir de los datos de la métrica conduzca a una mejora de procesos significativa para la organización del software.
Programa de Métricas y Planificación (Uso de MS Proj)
No hay comentarios:
Publicar un comentario