Mtricas Tcnicas del Software

IntroduccinSe aplica las mtricas para valorar la calidad de los productos de ingeniera o los sistemas que se construyen.Proporcionan una manera sistemtica de valorar la calidad basndose en un conjunto de reglas claramente definidas.Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales.

Calidad del SoftwareLos requisitos del Software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.Unos estndares especficos definen un conjunto de criterios de desarrollo que guan la manera en que se hace la ingeniera del Software. Si no se siguen los criterios , habr seguramente poca calidad.Existe un conjunto de requisitos implcitos que ha menudo no se nombran. Si el software cumple con sus requisitos explcitos pero falla en los implcitos , la calidad del software no ser fiable.

Factores de calidad de McCallLos factores que afectan la calidad se pueden categorizar en:Factores que se pueden medir directamente, como por ejemplo los defectos por punto de funcin.Factores que se pueden medir slo indirectamente, como por ejemplo la facilidad de uso o mantenimiento.En todos los casos debe aparecer la medicin. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusin sobre la calidad.

Factores de calidadMcCall y colegas (1997)Revisin del ProductoTransicin del productoOperacin del productoCorreccin Fiabilidad Usabilidad Integridad EficienciaFacilidad de mantenimientoFlexibilidadFacilidad de pruebaPortabilidad Reusabilidad Interoperatividad

Operacin del ProductoCorreccin : Hasta donde satisface un programa su especificacin y logra los objetivos del cliente.Fiabilidad: Hasta dnde se puede esperar que un programa lleve a cabo de su funcin con la exactitud requerida.Eficiencia: La cantidad de recursos informticos y de cdigo necesarios para que un programa realice su funcin.

Integridad: Hasta dnde se puede controlar el acceso al software o a los datos por personas no autorizadas.Usabilidad (facilidad de manejo):El esfuerzo necesario para aprender a operar los datos de entrada e interpretar las salidas de un programa.

Revisin del productoFacilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar un error en un programa.Flexibilidad: El esfuerzo necesario para modificar un programa operativo.Facilidad de prueba: El esfuerzo necesario para probar un programa para asegurarse de que realiza su funcin pretendida.

Transicin del productoPortabilidad: El esfuerzo necesario para transferir el programa de un entorno de sistema hardware y/o software a otro entorno diferente.Reusabilidad ( capacidad de reutilizacin): Hasta donde se puede volver a emplear un programa ( o partes de un programa) en otras aplicaciones.Interoperatividad: El esfuerzo necesario para acoplar un sistema con otro.

Es difcil desarrollar medidas directas de los factores de calidad sealados anteriormente, por consiguiente se definen un conjunto de mtricas para desarrollar expresiones que utilicen los factores de acuerdo a la siguiente relacin: Fq = c1 x m1 + c2 x m2 +.+cn x mn

Fq es factor de calidadCn son coeficientes de regresinMn son las mtricas que afectan al factor calidad

Lamentablemente muchas de las mtricas definidas por McCall solamente pueden medirse de manera subjetiva.Las mtricas se acomodan en una lista de comprobacin que se emplea para puntuar atributos especficos del software.El esquema de puntuacin que se propone es una escala del 0 (bajo) al 10 (alto)

Mtrica para el esquema de puntuacin:Facilidad de auditora: la facilidad con la que se puede comprobar el cumplimiento de los estndares.Exactitud: la exactitud de lo clculos y el control.Estandarizacin de comunicaciones: el grado de empleo de estndares de interfaces, protocolos y anchos de banda.Compleccin: el grado con que se ha logrado la implementacin total de una funcin.Concisin :Lo compacto que es el programa en trminos de lneas de cdigo

Consistencia: El empleo de un diseo uniforme y de tcnicas de documentacin a lo largo del proyecto de desarrollo del software.Estandarizacin de datos: El empleo de estructuras y tipos de datos estndares a lo largo del programa.Tolerancia al error : el dao causado cuando un programa encuentra un error.Eficiencia de ejecucin: El rendimiento del funcionamiento de un programa.Capacidad de expansin: El grado con que se pueden ampliar el diseo arquitectnico, de datos o procedimental.Generalidad: la amplitud de aplicacin potencial de los componentes del programa.Independencia del hardware: El grado con que se desacopla el software del hardware donde opera.

Instrumentacin:El grado con el que el programa vigila su propio funcionamiento e identifica los errores que ocurren.Modularidad: La independencia funcional de componentes de programa.Operatividad: La facilidad de operacin de un programa.Seguridad: La disponibilidad de mecanismos que controlan o protegen los programas y los datos.Autodocumentacin: El grado en que el cdigo fuente proporciona documentacin significativa.Simplicidad: El grado de facilidad con que se puede entender un programa.

Independencia del sistema de software: El grado de independencia de programa respecto a las caractersticas del lenguaje de programacin no estndar , caractersticas del sistema operativo y otras restricciones del entorno.Trazabilidad: La capacidad de seguir una representacin del diseo o un componente real del programa hasta los requisitos.Formacin : El grado en que ayuda el software a manejar el sistema a los nuevos usuarios.

FURPS (Funcionality, Usability, Reliability, Performance, Supportability)Hewlett Packard ha desarrollado un conjunto de factores de calidad del software al que se le ha dado el acrnimo de FURPS: funcionalidad, facilidad de empleo, fiabilidad, rendimiento y capacidad de soporte. Los factores de calidad son cinco y se definen de acuerdo al siguiente conjunto de atributos:Funcionalidad. Se valora evaluando el conjunto de caractersticas y capacidades del programa, la generalidad de las funciones entregadas y la seguridad del sistema global. Facilidad de uso. Se valora considerando factores humanos, la estetica, consistencia y documentacin general.

Fiabilidad. Se evala midiendo la frecuencia y gravedad de los fallos, la exactitud de las salidas, el tiempo medio entre fallos, la capacidad de recuperacin de un fallo y la capacidad de prediccin del programa. Rendimiento. Se mide por la velocidad de procesamiento, el tiempo de respuesta, consumo de recursos, rendimiento efectivo total y eficacia. Capacidad de soporte. Combina la capacidad de ampliar el programa (extensibilidad), adaptabilidad y servicios, as como la capacidad de hacer pruebas, compatibilidad, capacidad de configuracin, la facilidad de instalacin de un sistema y la facilidad con que se pueden localizar los problemas

Factores de Calidad ISO 9126El estndar identifica seis atributos clave de calidad:Funcionalidad: El grado en que el software satisface las necesidades indicadas por los siguientes subatributos: idoneidad, correccin, interoperatividad,conformidad y seguridad.Confiabilidad: Cantidad de tiempo que el software est disponible para su uso. Esta referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de recuperacin.

Usabilidad: Grado en que el software es fcil de usar. Viene reflejado por los siguientes subatributos: facilidad de comprensin, facilidad de aprendizaje y operatividad.Eficiencia: Grado en que el software hace ptimo el uso de los recursos del sistema. Viene reflejado por los siguientes subatributos: tiempo de uso y recursos utilizados.Facilidad de mantenimiento: La facilidad con que una modificacin puede ser realizada. Est indicada por los siguientes subatributos: facilidad de anlisis , facilidad de cambio, estabilidad y facilidad de prueba.Portabilidad: La facilidad con que el software puede ser llevado de un entorno a otro. Est referido por los siguientes subatributos: facilidad de instalacin, facilidad de ajuste, facilidad de adaptacin al cambio

Paradoja de Jacob BronkowskiAo tras ao ingeniamos instrumentos ms exactos con los que observar la naturaleza con mas exactitud. Y cuando miramos las observaciones estamos desconcertados de ver que todavs son confusas y tenemos la sensacin de que son tan inciertas como siempre

Estructura para las mtricas del SoftwareLa medicin asigna nmeros o smbolos a atributos de entidades en el mundo real. Para conseguirlo es necesario un modelo de medicin que comprenda un conjunto consistente de reglas.Existe la necesidad de medir y controlar la complejidad del software, es bastante difcil obtener un solo valor para representar una "mtrica de calidad", sin embargo es posible desarrollar medidas de diferentes atributos internos del programa como ser: modularidad efectiva, independencia funcional y otros atributos. Estas mtricas y medidas obtenidas pueden utilizarse como indicadores independientes de la calidad de los modelos de anlisis y diseo.

Los principios bsicos de la medicin, sugeridos por Roche, pueden caracterizarse mediante cinco actividades:Formulacin. Obtencin de medidas y mtricas del software apropiadas para la representacin del software en cuestin. Coleccin. Mecanismo empleado para acumular datos necesarios para obtener las mtricas formuladas. Anlisis. Clculo de las mtricas y la aplicacin de herramientas matemticas. Interpretacin. Evaluacin de los resultados de las mtricas en un esfuerzo por conseguir una visin interna de la calidad de la representacin. Realimentacin. Recomendaciones obtenidas de la interpretacin de mtricas tcnicas transmitidas al equipo software.

Ejiogu define un conjunto de atributos que deberan acompaar a las mtricas efectivas del software. La mtrica obtenida y las medidas que conducen a ello deberan ser:Simple y fcil de calcular. Emprica e intuitivamente persuasiva. Consistente y objetiva. Consistente en el empleo de unidades y tamaos. Independiente del lenguaje de programacin. Un eficaz mecanismo para la realimentacin de calidad.

La experiencia indica que una mtrica tcnica se usa nicamente si es intuitiva y fcil de calcular. Si se requiere docenas de contadores y se han de utilizar complejos clculos, la mtrica no ser ampliamente utilizada.

Mtricas del Modelo de AnlisisEn esta fase es deseable que las mtricas tcnicas proporcionen una visin interna a la calidad del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el "tamao" del sistema resultante; es probable que el tamao y la complejidad del diseo estn directamente relacionadas.

Mtricas basadas en la FuncinLa mtrica del punto de funcin (PF) se puede utilizar como medio para predecir el tamao de un sistema obtenido a partir de un modelo de anlisis. Para visualizar esta mtrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el clculo de la mtrica de punto de funcin:Nmero de entradas del usuario Nmero de salidas del usuario Nmero de consultas del usuario Nmero de archivos Nmero de interfaces externas

La cuenta total debe ajustarse utilizando la siguiente ecuacin: PF = cuenta-total x (0,65 + 0,01 x Fi)Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad".

Para el ejemplo descrito en la figura 9.2 se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56

Factor de ponderacin Parmetro de medicin Cuenta Simple Media Compl. Nmero de entradas del usuario 3 X 3 4 6 = 9 Nmero de salidas del usuario 2 X 4 5 7 = 8 Nmero de consultas del usuario 2 X 3 4 6 = 6 Nmero de archivos 1 X 7 10 15 = 7 Nmero de interfaces externas 4 X 5 7 10 = 20 Cuenta total 50 Fig. 9.2 Clculo de puntos de funcin

Basndose en el valor previsto del PF obtenido del modelo de anlisis, el equipo del proyecto puede estimar el tamao global de implementacin de las funciones de interaccin. Asuma que los datos de los que se dispone indican que un PF supone 60 lneas de cdigo (se utilizar un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF. Estos datos histricos proporcionan al gestor del proyecto una importante informacin de planificacin basada en el modelo de anlisis en lugar de estimaciones preliminares

Otras Mtricas para el Modelo de AnlisisLa Mtrica Bang [De Marco]Puede aplicarse para desarrollar una indicacin del tamao del software a implementar como consecuencia del modelo del anlisis.Mtricas de la calidad de la especificacin:Davis y colegas proponen una lista de caractersticas que pueden emplearse para valorar la calidad del modelo de anlisis y la correspondiente especificacin de requisitos

Mtricas del modelo de DiseoLa gran irona de las mtricas de diseo para el software es que las mismas estn disponibles, pero la gran mayora de los desarrolladores de software continan sin saber que existen.No son perfectas y contina el debate sobre su eficacia y como deberan aplicarse.Algunos expertos sealan que es necesario mayor experimentacin hasta que se puedan emplear adecuadamente. Sin embargo el diseo sin medicin es una alternativa inaceptable.

Mtricas de diseo de alto nivel

Se concentran en las caractersticas de la arquitectura del programa , con nfasis en la estructura arquitectnica y en la eficiencia de los mdulos.Estas mtricas son de caja negra en el sentido que no requieren ningn conocimiento del trabajo interno de un mdulo en particular del sistema.

Card y Glass definen las siguientes tres medidas de complejidadLa complejidad estructural, S(i), de un mdulo i se define de la siguiente manera: S(i)=f2out(i). Donde fout(i) es la expansin del mdulo i.La expansin indica el nmero de mdulos que son invocados directamente por el mdulo i.

La complejidad de datos, D(i), proporciona una indicacin de la complejidad en la interfaz interna de un mdulo i y se define como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el nmero de variables de entrada y salida que entran y salen del mdulo i.

La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos : C(i)= S(i) + D(i)A medida que crecen los valores de complejidad , la complejidad arquitectnica o global del sistema tambin aumenta. Esto lleva a una mayor probabilidad de que aumente el esfuerzo necesario para la integracin y las pruebas.

Fenton sugiere varias mtricas de morfologa simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas.

Tamao= n + a . Donde n es el nmero de nodos (mdulos) y a es el nmero de arcos (lneas de control). Para la arquitectura mostrada se tiene tamao= 17+18=35.Profundidad= camino ms largo desde el nodo raz a un nodo hoja. Para el ejemplo Profundidad= 4Amplitud=nmero mximo de nodos de cualquier nivel de la arquitectura. Para el ejemplo amplitud= 6Mtricas a aplicar

Relacin arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura y proporciona una indicacin sencilla de acoplamiento de la arquitectura. Para el ejemplo r=18/17= 1.06

Mtricas del Cdigo FuenteLa teora de la ciencia del software propuesta por Halstead es probablemente la medida de complejidad mejor conocida y minuciosamente estudiada. La ciencia del software propuso la primera ley analtica y cuantitativa para el software de computadora.Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el cdigo despus de completar el diseo.

Estas medidas son:n1: nmero de operadores diferentes que aparecen en le programa.n2: nmero de operandos diferentes que aparecen en el programa.N1: nmero total de veces que aparece el operador.N2: nmero total de veces que aparecen el operando.

Halstead utiliza medidas primitivas para desarrollar expresiones par la longitud global del programa; volumen mnimo potencial para un algoritmo; el volumen real (nmero de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras caractersticas tales como el esfuerzo de desarrollo,,tiempo de desarrollo e incluso el nmero esperado de fallos en el software.

Halstead propone las siguientes mtricas:Longitud N se puede estimar como: N = n1log2n1 + n2log2n2. Volumen de programa se define como: V = N n1log2(n1 + n2). Tomando en cuenta que V variar con el lenguaje de programacin y representa el volumen de informacin (en bits) necesarios para especificar un programa.

Ejemplo:Programa de ordenacin por intercambio

SUBROUTINE SORT(X,N) DIMENSION X(N) IF (N .LT. 2) RETURN DO 20 I=2, N DO 10 J=1, I IF (X(I) .GE. X(J)) GO TO 10 SAVE = X(I) X(I) = X(J) X(J) = SAVE 10 CONTINUE 20 CONTINUE RETURN END

De esta tabla se desprenden los valores de n1=10 y N1=28.

Operador Cuenta 1 Fin de sentencia 7 2 Subndices de arreglos 6 3 = 5 4 IF() 2 5 DO 2 6 , 2 7 Fin de programa 1 8 .LT. 1 9 .GE. 1 10 GO TO 10 1 Total 28

De esta tabla se desprenden los valores de n2=7 y N2=22.

Operando Cuenta 1 X 6 2 I 5 3 J 4 4 N 2 5 2 2 6 SAVE 2 7 1 1 Total 22

Mtricas para las PruebasLa mayora de las mtricas para pruebas se concentran en el proceso de prueba, no en las caractersticas tcnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las mtricas de anlisis, diseo y cdigo para que sirvan de gua en el diseo y ejecucin de los casos de prueba.El esfuerzo de las pruebas tambin se puede estimar utilizando mtricas obtenidas de las medidas de Halstead. Usando la definicin del volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software puede calcularse como:NP = 1/[(n1/2) x (N2/n2)] (Ec. 9.1)e = V/NP (Ec. 9.2)

El porcentaje del esfuerzo global de pruebas a asignar a un mdulo k se puede estimar utilizando la siguiente relacin: Porcentaje de esfuerzo de pruebas(k) = e(k)/e(i) (Ec. 9.3)Donde e(k) se calcula para el mdulo k utilizando las ecuaciones (Ec. 9.1) y (Ec. 9.2), la suma en el denominador de la ecuacin (Ec. 9.3) es la suma del esfuerzo de la ciencia del software a lo largo de todos los mdulos del sistema.

A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicacin de la complecin de las pruebas:Medida de amplitud de las pruebas. Proporciona una indicacin de cuantos requisitos se han probado del numero total de ellos. Indica la complecin del plan de pruebas. Profundidad de las pruebas. Medida del porcentaje de los caminos bsicos independientes probados con relacin al nmero total de estos caminos en el programa. Se puede calcular una estimacin razonablemente exacta del nmero de caminos bsicos sumando la complejidad ciclomtica de todos los mdulos del programa. Perfiles de fallos. Se emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categoras de los fallos proporcionan una descripcin de un error, de manera que se puedan llevar a cabo anlisis estadstico de errores.

MTRICAS DEL MANTENIMIENTO Todas las mtricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente. El estndar IEEE 982.1-1988 sugiere el ndice de madurez del software (IMS) que proporciona una indicacin de la estabilidad de un producto software basada en los cambios que ocurren con cada versin del producto. Con el IMS se determina la siguiente informacin:MT= Nmero de mdulos en la versin actualFc= Nmero de mdulos en la versin actual que se han cambiadoFa= Nmero de mdulos en la versin actual que se han aadidoFe= Nmero de mdulos en la versin actual que se han eliminado

El ndice de madurez del software se calcula de la siguiente manera: IMS= [MT - (Fc + Fa + Fe)]/MT A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar. El IMS puede emplearse tambin como mtrica para la planificacin de las actividades de mantenimiento del software.

Medicin y mtricas de Software [Sommerville]cap.24La medicin del software se refiere a derivar a un valor numrico para algn atributo de un producto de software o un proceso de software.Comparando estos valores entre ellos y con los estndares aplicados en la organizacin, es posible sacar conclusiones de la calidad del software o de los procesos del software.Sin embargo , an es poco comn la utilizacin de medidas y mtricas sistemticas de software. La reticencia al uso es debido a que los beneficios noson claros.

Por otra parte no existen estndares para las mtricas y, por lo tanto existe ayuda limitada para la recoleccin y anlisis de datos.Las mtricas son de control o de prediccin:Control: por lo general se asocian con los procesos del software. Ejemplo, el esfuerzo y el tiempo promedio requerido para reparar los defectos reportados.Prediccin : se asocian con los productos del software. Ejemplo, la complejidad ciclomtica de un mdulo, la longitud promedio de los indicadores en un programa y el nmero de atributos y operaciones asociadas con los objetos de un diseo.

Toma de decisiones administrativasProceso de SoftwareMedidas de ControlDecisiones administrativasProducto de softwareMedidas de prediccinAmbas mtricas influyen en la toma de decisiones administrativas

Mtricas para predecir la calidad A menudo es imposible medir los atributos de calidad del software en forma directa.Los atributos como la complejidad , la mantenibilidad y la comprensin se ven afectados por diversos factores y no existen mtricas directas para ellos.Ms bien es necesario medir un atributo interno del software ( como el tamao) y suponer que existe una relacin entre lo que se puede medir y lo que se quiere saber.De forma ideal , existe una relacin clara vlida entre los atributos de software internos y externos.

Relacin entre los atributos externos e internosMantenibilidadFiabilidadPortabilidadUsabilidadNmero de parmetros del procedimientoComplejidad ciclomticaTamao del programa en lneas de cdigoNmero de mensajes de errorExtensin del manual de usuarioNo dice qu relacin es

Mtricas del productoSe refiere a las caractersticas del software.En general las organizaciones construyen sus bases de datos histricas para relacionar las mediciones obtenidas.Se dividen en dos clases:Mtricas dinmicas recolectadas por las mediciones hechas en un programa en ejecucin.Las mtricas estticas recolectadas por las mediciones hechas en las representaciones del sistema como el diseo, el programa o la documentacin.

Estas diferentes mtricas estn relacionadas con diversos atributos de calidad. Las mtricas dinmicas ayudan a a valorar la eficiencia y la fiabilidad de un programa mientras que las mtricas estticas ayudan a valorar la complejidad, la comprensin y la mantenibilidad de un sistema de software.Las mtricas estticas , por otro lado, tienen una relacin indirecta con los atributos de calidad.Las mtricas especficas relevantes dependen del proyecto, de las metas del equipo de administracin de la calidad y del tipo de software a desarrollar.

Medicin del proceso cap. 25Son datos cuantitativos de los procesos del software.Se utilizan para evaluar si la eficiencia de un proceso ha mejorado. Por ejemplo se puede medir el esfuerzo y tiempo dedicado a las pruebas. Las mejoras efectivas para los procesos de prueba reducen el esfuerzo , el tiempo de prueba o ambos.

Se pueden recolectar tres clases de mtricas del proceso:El tiempo requerido para completar un proceso particular:Tiempo total dedicado al proceso, el tiempo de calendario, el tiempo invertido en el proceso por ingenieros particulares, etc.Los recursos requeridos para un proceso en particular:Los recursos pueden ser el esfuerzo total en personas-das, los costos de viajes, los recursos de cmputo,etc.

El nmero de ocurrencias de un evento en particular:Ejemplos de eventos que se pueden supervisar son el nmero de defectos descubiertos durante la inspeccin del cdigo, el nmero de peticiones de cambios en los requerimientos, el nmero promedio de lneas de cdigo modificadas en respuesta a un cambio de requerimientos, etc.

Estimacin del Costo del Software Cap. 23 La estimacin y calendarizacin del proyecto se llevan a cabo de forma conjunta.Sin embargo se debe contar con estimaciones previas para ver los efectos sobre la calendarizacin y stas se actualizan de forma regular.Permite la utilizacin efectiva de los recursos y una adecuada planeacin.

Parmetros involucrados en el costo total de un proyecto:Costos de hardware y software , incluyendo mantenimiento.Costos de viajes y capacitacinCostos de esfuerzo ( pago a los ingenieros de Software)Para muchos proyectos , el costo dominante es el costo de esfuerzo.

Costos de esfuerzo:Costos de proveer, calentar e iluminar las oficinas.Costos del personal de apoyo como contadores , secretarias, limpiadores y tcnicos.Costos de las redes y las comunicaciones.Costos de los recursos centralizados como bibliotecas, los recursos recreativos,etc.Costos de seguridad social y de beneficio de empleados como las pensiones y seguros de salud.

Factores que afectan la asignacin de precios al software.Oportunidad de mercado: penetracin de mercado con cotizacin de bajos costos al inicio.Incertidumbre: Si no hay seguridad en el costo estimado, por alguna contingencia puede incrementar su precio por encima del beneficio normal.Trminos contractuales: Reducir el costo a partir de asumir restricciones como por ejemplo entrega del cdigo fuente y que el desarrollador lo pueda reutilizar en otros proyectos.

Volatilidad de los requerimientos: Si es probable que los requerimientos cambien, podra reducirse los precios para ganar un contrato. Despus del contrato se cargan precios altos a los cambios de requerimientos.Salud Financiera: Cuando los desarrolladores tienen dificultades financieras podran bajar sus costos para ganar contratos. Esto es mejor que quedar fuera del negocio o quebrar

ProductividadCuando se produce soluciones con diferentes atributos, no tiene sentido comparar tasas de productividad, sin embargo las estimaciones son necesarias para las estimaciones del proyecto y para valorar si los procesos o las mejoras tecnolgicas son efectivas.Por lo general estas estimaciones se basan en medir algunos atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo.

Medidas utilizadas:Relacionadas con el Tamao: se relacionan con el tamao de alguna salida de una actividad. La medida ms comn son las lneas de cdigo fuente entregadas. Tambin se utiliza el nmero de instrucciones de cdigo objeto entregado o el nmero de pginas de la documentacin del sistema

Medidas utilizadas:Relacionadas con la funcin: se relacionan con la funcionalidad total del software entregado. La productividad se expresa en trminos de la cantidad de funcionalidad til producida en un tiempo dado. Ejemplos de esta medidas son puntos de funcin y puntos de objetos .

(Un parntesis )Puntos de objetos : el nmero de puntos de objeto en un programa es una estimacin de peso ( no son clases de objetos que se producen cuan se considera orientacin objeto para el desarrollo del software):El nmero de pantallas independientes que se despliegan. Las pantallas sencillas cuentan como 1 punto de objeto, las moderadamente complejas cuentan como 2 y las muy complejas cuentan como 3 puntos de objeto.El nmero de informes que se producen, simples son 2 puntos de objeto, moderadamente complejos son 5 puntos de objeto y para informes que son difciles de producir 8 puntos de objetos.El nmero de mdulos 3GL que deben desarrollarse para complementar el cdigo 4GL. Cada mdulo 3GL cuenta como 10 puntos objetos

Tcnicas de Estimacin No existe una forma simple de hacer una estimacin precisa del esfuerzo requerido para desarrollar un sistema de software.Por lo general, las estimaciones de los costos del proyecto se cumplen por su propia naturaleza.A pesar de las dificultades e impresiones las organizaciones requieren hacer esfuerzos de software y estimaciones de costos.

Tcnicas de estimaciones de costosModelado del algoritmo de costos: Se desarrolla un modelo utilizando informacin histrica de costos que relaciona alguna mtrica de software( por lo general su tamao) con el costo del proyecto. Se hace una estimacin de sa mtrica y el modelo predice el esfuerzo requerido.Opinin de expertos:Se consultan varios expertos en las tcnicas de desarrollo de software propuestas y en el dominio de la aplicacin. Cada uno de ellos estima el costo del proyecto. Estas estimaciones se comparan y discuten. El proceso de estimacin se itera hasta que se acuerda una estimacin.

Tcnicas de estimaciones de costosEstimacin por analoga:Esta tcnica es aplicable cuando otros proyectos en el mismo dominio de aplicacin se han completado. Se estima el costo de un nuevo proyecto por analoga con estos proyectos completados.Ley de Parkinson: Establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles ms que por los objetivos logrados. Si el software se tiene que entregar en 12 meses y se dispone de cinco personas, el esfuerzo requerido se estima en 60 personas-mes

Tcnicas de estimaciones de costosAsignar precios para ganar:El costo del software se estima independientemente de lo que el cliente est dispuesto a pagar por el proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software.

Cada tcnica de estimacin tiene sus propias debilidades y fortalezas.Para proyectos grandes se deben aplicar varias tcnicas de estimaciones de costos y comparar sus resultados.Estas tcnicas de estimacin son aplicables cuando existe un documento de requerimientos para el sistema.

Modelado algortmico de costosSe construye analizando los costos y atributos de los proyectos realizados.Se utiliza una frmula matemtica para predecir los costos basados en estimaciones del tamao del proyecto, nmero de programadores y otros factores de los procesos y productos.Kitchenham (1990) describe 13 modelos algoritmos de costos desarrollados a partir de observaciones empricas.

Forma mas general para expresar una estimacin algortmica de costos: Esfuerzo = A x TamaoB x MA es un factor constante que depende de las prcticas organizacionales locales y del tipo de software que se desarrolla.Tamao es una valoracin del tamao del cdigo del software o una estimacin de la funcionalidad expresada en puntos de funcin o de objetos.El valor del exponente B por lo general se encuentra entre 1 y 1.5 y refleja el esfuerzo requerido para proyectos grandes .M es un multiplicador generado al combinar diferentes procesos , atributos del producto y del desarrollo

Dificultades comunes:Es difcil estimar Tamao en una primera etapa de un proyecto donde solamente esta disponible la especificacin.Las estimaciones de los factores B y M son subjetivas. Vara de una persona a otra segn su experiencia y conocimiento.

Modelo COCOMOModelo empricoSe obtuvo recolectando datos de varios proyectos de software grandes, y despus analizando esos datos para descubrir frmulas que se ajustarn mejor a las observaciones.Esta bien documentado, es de dominio pblico y lo apoyan herramientas comerciales.Se ha utilizado y evaluado ampliamente.Ha evolucionado del COCOMO 81( 1981) al COCOMO 2 (1995)

COCOMO Bsico

El COCOMO 81 , primera versin del modelo COCOMO , fue un modelo de tres niveles donde stos reflejaban el detalle del anlisis de la estimacin del costo. El primer nivel bsico provee una estimacin inicial burda.El segundo nivel la modifica utilizando varios multiplicadores del proyecto y del proceso, y El nivel ms detallado produce estimaciones para las diferentes fases del proyecto

Evolucin COCOMOCOCOMO 81 supone que el software se desarrolla acorde a un proceso en cascada y que la mayora del software se construye desde cero.Lo anterior hoy no es vlido pues existe creacin de software a partir de el ensamblado de componentes reutilizables vinculndolos a travs de script (secuencia de comandos).Los modelos de procesos mas comnmente utilizados hoy son el de prototipos y el incremental.Se utiliza la reingeniera para crear nuevos procesosLa utilizacin de mejores herramientas como las CASE hacen mas dinmico el proceso de construccin.Todo lo anterior hace evolucionar al COCOMO 81 al actual modelo COCOMO 2

COCOMO 2Considera diferentes enfoques para el desarrollo del software.Los niveles del modelo no reflejan simplemente estimaciones detallas con complejidad creciente.Los niveles se asocian a las actividades del proceso por lo que las estimaciones iniciales se llevan cabo al inicio del proceso y las estimaciones detalladas se llevan a cabo despus del que se defini la arquitectura del sistema.

Niveles del COCOMO 2Nivel de construccin de prototipo inicial:Las estimaciones de tamao se basan en puntos de objeto y se utiliza un frmula sencilla tamao/productividad para estimar el esfuerzo requerido.Nivel de diseo inicial: Corresponde a la terminacin de requerimientos del sistema con algn diseo inicial.. Las estimaciones se basan en puntos de funcin que se convierten a nmero de lneas de cdigo fuente.Nivel postarquitectnico: Una vez que se disea la arquitectura del sistema se hace una estimacin razonablemente precisa del tamao del software. En este nivel se utiliza un conjunto mas grande de multiplicadores que reflejan la capacidad del personal, el producto y las caractersticas del proyecto.

Nivel de construccin de prototipo inicialPermite la estimacin del esfuerzo requerido en construccin de prototipos y para proyectos donde el software se desarrolla utilizando componentes existentes.Se basa en una estimacin de los puntos de objetos de peso, la cual se divide en una cifra estndar de productividad estimada.La productividad del programador depende de la experiencia y capacidad del desarrollador y las caractersticas de las herramientas CASE.La reutilizacin es comn , por lo que el nmero de puntos de objeto utilizados en la estimacin del tiempo se ajusta para tomar en cuenta el porcentaje de reutilizacin que se espera.

FormulaPM = ( NOP x (1 - %reutilizacin/100)) / PROD

PM es el esfuerzo en personas-mes NOP es el nmero de puntos de objeto y PROD es la productividadProductividad de los Puntos de objeto

El nivel de Diseo InicialLas estimaciones se basan en frmula estndar para modelos algortmicos:

Esfuerzo = A x TamaoB x M

A segn Boehm (experimentacin) es de 2.5 para las estimaciones hechas a este nivel.Tamao se expresa en KSLOC, es decir, el nmero de miles de lneas de cdigo fuente.KSLOC se calcula estimando el nmero de puntos de funcin en el software y convirtiendolo ste a KSLOC utilizando la tabla estndar que relacionan el tamao del software a puntos de funcin para diferentes lenguajes de programacin

El exponente B refleja el esfuerzo creciente requerido al incrementarse el tamao del proyecto. Puede variar de 1.1 a 1.24 dependiendo de la novedad del proyecto, la flexibilidad del desarrollo , los procesos utilizados de resolucin de riesgos, la cohesin del equipo de desarrollo y en nivel de madurez.M se basa en un conjunto de simplificado de 7 conductores de proyectos y procesos en los que se incluye la fiabilidad y complejidad del producto (RCPX), la reutilizacin requerida (RUSE), la dificultad de la plataforma (PDIF), la capacidad del personal (PERS), la experiencia del personal (PREX), la calendarizacin (SCED) y los recursos de apoyo (FCIL). Estos pueden estimarse en una escala de 1 a 6, 1 corresponde a un valor muy bajo y 6 a valores muy altos.

Formula del esfuerzo segn los multiplicadores sealados:

P = A x TamaoB x M + PMm dondeM= PERS x RCPX x RUSE x PDIF x FCIL x SCED.PMm es un factor que se utiliza cunado un porcentaje importante del cdigo se genera de forma automtica.PMm = (ASLOC x (AT / 100)) / ATPRODASLOC nmero de lneas generadas automticamente de cdigo fuente.ATPROD es el nivel de productividad para este tipo de produccin de cdigo. AT porcentaje del cdigo total del sistema que se genera automticamente

El nivel postarquitectnicoLas estimaciones se basan en la misma frmula bsica que se utiliza en las estimaciones iniciales del diseo.La estimacin del tamao para el software es mas precisa utilizando 17 atributos en lugar de 7 para refinar el clculo del esfuerzo inicial.La estimacin del nmero total de lneas de cdigo fuente se ajusta para tomar en cuenta dos factores importantes del proyecto:

La volatilidad de los requerimientos: Se realiza un estimacin de la revisin, que puede ser requerida para acomodar cambios en los requerimientos del sistema. Se expresa como el nmero de lneas de cdigo fuente que se deben modificar y este nmero se suma a la estimacin inicial del tamao.Amplitud de la posible reutilizacin:Una reutilizacin amplia significa que se deben modificar el nmero de lneas de cdigo fuente que realmente se desarrollarn. El costo no es lineal pues debido al esfuerzo inicial requerido para descubrir y seleccionar los componentes y debido al esfuerzo requerido para modificar y comprender los componentes reutilizables y sus interfaces.

Efecto de la reutilizacin en COCOMO 2Se ajusta el tamao del esfuerzo de acuerdo con la siguiente frmula:ESLOC = ASLOC x ( AA+SU+0.4DM+ 0.3IM + 0,3CM)/100ESLOC es el nmero equivalente de lneas de cdigo nuevo.ASLOC es el nmero de lneas de cdigo reutilizable que deben definirse.DM es el % de modificacin del diseoCM es el % de cdigo que se modificaIM es el % del esfuerzo original requerido para integrar el software reutilizado.SU es un factor que se basa en el costo de comprensin del software que vara desde 50 para cdigo complejo no estructurado hasta 10 para cdigo orientado al objeto bien escritoAA es un factor que refleja los costos de valoracin inicial de la posible reutilizacin del software. Va desde 0 a 8. Depende de la cantidad de pruebas y evaluaciones requeridas.

Estimacin del Exponente de la frmula del Esfuerzo (B)Considera 5 factores de escala valorados desde muy bajo hasta extraalto(5 a0). Los valores resultantes se suman , se dividen entre 100 y al resultado se le suma 1.01 par dar ese exponente

Factores de escala utilizados en el clculo del exponente del COCOMO 2

Atributos que se utilizan para ajustar las estimaciones iniciales en el modelo postarquitectnico (4) :Atributos del producto:RELY Fiabilidad requerida del sistemaCPLX Complejidad de los mdulos del sistemaDOCU Amplitud de la documentacin requeridaDATA Tamao de la base de datos utilizadaRUSE Porcentaje requerido de componentes reutilizablesAtributos de la computadora:TIME Restricciones del tiempo de ejecucinPVOL Volatilidad de la plataforma de desarrolloSTOR Restricciones de memoria.

Atributos que se utilizan para ajustar las estimaciones iniciales en el modelo postarquitectnico (4) :Atributos personales:ACAP Capacidad de anlisis del proyecto.PCON continuidad del personalPEXP Experiencia del programador en el dominio del proyectoPCAP Capacidad del programadorAEXP Experiencia del analista en el dominio del proyectoLTEX Experiencia en el lenguaje y las herramientasAtributos del proyecto:TOOL Utilizacin de las herramientas de softwareSCED Comprensin de los tiempos de desarrolloSITE Amplitud del trabajo en sitios mltiples y calidad de las comunicaciones del sitio.

EjemploUna organizacin trabaja un proyecto en el que se tiene poca experiencia en el dominio. El cliente del proyecto no ha definido el proceso a utilizar y no proporciona suficiente tiempo en la calendarizacin del proyecto para que se haga un anlisis de riesgos. Se tiene que formar un nuevo equipo de desarrollo para implementar este sistema. La organizacin ha puesto en proceso un programa de mejoramiento y ha obtenido en Nivel 2 del modelo CMM.

Posibles valores de los factores de escala utilizados en el clculo del exponente son: Precedentes : Este es un proyecto nuevo para la organizacin valor Bajo (4)Flexibilidad de desarrollo: No se involucra el cliente valor Muy alto (1)Resolucin de la arquitectura/riesgo: No se lleva a cabo un anlisis de riesgos valor Muy Bajo (5)Cohesin del equipo: Creacin de un nuevo equipo por lo que no existe informacin Valor Nominal (3)Madurez del Proceso: Algn control del proceso en el lugar Valor Nominal (3)La suma de estos valores es 16 por lo que el exponente toma un valor de 1.17

Si adems se supone que los conductores de costos clave en el proyecto son RELY, CPLX,STOR,TOOL y SCED:

En los ejemplos se consideraron valores extremos para ver como influye en la estimacin

Modelos algortmicos de costos en la planeacin del proyectoA. Utilizar el hardware existente, sistema de desarrollo y equipo de desarrolloB. Actualizacin del Procesador y de la memoriaLos costos de hardware se incrementan , la experiencia decreceNuevo sistema de desarrolloLos costos de hardware se incrementan . La experiencia decreceC.Slo actualizacin de la memoriaLos costos de hardware se incrementanD.Personal ms experimentadoF. Personal con experiencia en hardware

Costo del software SC se calcula:SC = Esfuerzo esyimado x RELY x TIME x STOR x TOOL x EXP x CPCP = costo promedio de una persona mes de esfuerzo

Duracin y personal del proyectoLa relacin entre el nmero de personas que trabajan en un proyecto, el esfuerzo total requerido y el tiempo de desarrollo no es lineal.Formula para estimar el tiempo calendario requerido para completar un proyecto TDEV:TDVE = 3 x (PM) (0.33+0.2x(B-1.01))PM es el clculo del esfuerzo B es el exponente que refleja el esfuerzo creciente requerido al incrementarse el tamao del proyectoEste clculo predice la duracin nominal del proyecto

La duracin prevista del proyecto y la requerida por el plan del proyecto no son necesariamente lo mismo. La duracin planeada es ms corta o ms larga que la duracin prevista original. Sin embargo existe un lmite obvio para los cambios de duracin, el cual se predice en COCOMO 2 como:TDVE = 3 x (PM) (0.33+0.2x(B-1.01)) x SCEDpercentage/100SCEDpercentage es el porcentaje de crecimiento o decrecimiento en la duracin nominal.

Un crecimiento muy rpido del personal del proyecto a menudo est correlacionado con retrasos en la duracin del proyecto.Si se reduce el tiempo de desarrollo , siendo un factor clave, el esfuerzo requerido para desarrollar el sistema crece exponencialmente.