Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Metricas Tecnicas Del Software 1222288299021821 8
Metricas Tecnicas Del Software 1222288299021821 8
Introduccin
Se 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.
Los 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 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.
Correccin
Correccin : 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.
Portabilidad: 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 calidad Cn son coeficientes de regresin Mn son las mtricas que afectan al factor calidad
10
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)
11
12
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
13
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.
14
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.
15
16
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
17
El 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.
18
19
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
Ao 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
20
La 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.
21
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.
22
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.
23
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.
24
En 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.
25
26
La 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".
27
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 Nmero de entradas del usuario Nmero de salidas del usuario Nmero de consultas del usuario Nmero de archivos Nmero de interfaces externas Cuenta total
Cuenta
Simple
Media
Compl.
1 4
X X
7 5
10 7
15 10
= =
7 20 50
28
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
29
Puede aplicarse para desarrollar una indicacin del tamao del software a implementar como consecuencia del modelo del anlisis. 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
30
La 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.
31
32
La 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.
33
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.
34
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.
35
Fenton sugiere varias mtricas de morfologa simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas.
36
Mtricas a aplicar
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= 4 Amplitud=nmero mximo de nodos de cualquier nivel de la arquitectura. Para el ejemplo amplitud= 6
37
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
38
La 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.
39
40
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.
41
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.
42
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 20 CONTINUE CONTINUE
RETURN
END
43
Operador
Cuenta
1 2 3 4 5 6
7 6 5 2 2 2
7
8 9 10 Total
Fin de programa
.LT. .GE. GO TO 10
1
1 1 1 28
Operando
Cuenta
1 2 3 4 5 6 7 Total
X I J N 2 SAVE 1
6 5 4 2 2 2 1 22
46
La 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.
47
48
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.
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 cambiado Fa= Nmero de mdulos en la versin actual que se han aadido Fe= Nmero de mdulos en la versin actual que se han eliminado
49
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.
50
51
La 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.
52
Medidas de Control
Medidas de prediccin
Decisiones administrativas
53
54
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.
Complejidad ciclomtica
Fiabilidad
Portabilidad
Usabilidad
No dice qu relacin es
55
Se 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.
56
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.
57
58
Tiempo total dedicado al proceso, el tiempo de calendario, el tiempo invertido en el proceso por ingenieros particulares, etc.
2.
Los recursos pueden ser el esfuerzo total en personas-das, los costos de viajes, los recursos de cmputo,etc.
59
3.
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.
60
61
62
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.
63
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.
64
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
65
Productividad
Cuando 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.
66
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
67
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 .
68
(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
69
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.
70
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:
71
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.
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. 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
Ley de Parkinson:
72
Asignar 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.
73
Se 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.
74
Esfuerzo = A x TamaoB x M A 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
75
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.
76
Modelo COCOMO
Modelo emprico Se 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)
77
COCOMO Bsico
Complejidad del proyecto
Simple
Frmula
PM = 2.4 (KDSI)1.05 x M
Descripcin
Aplicaciones bien comprendidas desarrolladas por equipos pequeos
Moderada
PM = 3.0 (KDSI)1.12 x M
Proyectos ms complejos donde los miembros del equipo tienen experiencia limitada en sistemas relacionados Proyectos complejos donde el software es parte de un complejo fuertemente acoplado de hardware, software, reglas y procedimientos operacionales.
Incrustada
PM = 3.6 (KDSI)1.20 x M
78
79
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 COCOMO
COCOMO 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 procesos La 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
80
COCOMO 2
81
Considera 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.
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.
82
Permite 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.
83
Formula
PM = ( 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 productividad
Muy Baja 4
Baja
Nominal
Alta
Muy Alta
13
25
50
84
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
85
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.
86
P = A x TamaoB x M + PMm donde M= 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.
87
PMm = (ASLOC x (AT / 100)) / ATPROD ASLOC 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 postarquitectnico
Las 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:
88
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.
89
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.
Se ajusta el tamao del esfuerzo de acuerdo con la siguiente frmula: ESLOC = ASLOC x ( AA+SU+0.4DM+ 0.3IM + 0,3CM)/100
ESLOC 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 diseo CM es el % de cdigo que se modifica IM 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 escrito AA 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.
90
91
Flexibilidad
Resolucin de la arquitectura/riesgo
92
Refleja qu tan bien se conocen entre ellos los miembros del equipo de desarrollo y qu tan bien trabajan juntos. Muy bajo significa interacciones muy difciles; Extraalto significa un equipo integrado y efectivo sin problemas de comunicacin .
Refleja la madurez del proceso de la organizacin. El clculo de este valor depende del Cuestionario de Madurez del CMM pero se puede alcanzar una estimacin sustrayendo el nivel de madurez del proceso CMM de 5.
93
Atributos que se utilizan para ajustar las estimaciones iniciales en el modelo postarquitectnico (4) :
1.
2.
Atributos del producto: RELY Fiabilidad requerida del sistema CPLX Complejidad de los mdulos del sistema DOCU Amplitud de la documentacin requerida DATA Tamao de la base de datos utilizada RUSE Porcentaje requerido de componentes reutilizables Atributos de la computadora: TIME Restricciones del tiempo de ejecucin PVOL Volatilidad de la plataforma de desarrollo STOR Restricciones de memoria.
94
Atributos que se utilizan para ajustar las estimaciones iniciales en el modelo postarquitectnico (4) :
3.
4.
95
Atributos personales: ACAP Capacidad de anlisis del proyecto. PCON continuidad del personal PEXP Experiencia del programador en el dominio del proyecto PCAP Capacidad del programador AEXP Experiencia del analista en el dominio del proyecto LTEX Experiencia en el lenguaje y las herramientas Atributos del proyecto: TOOL Utilizacin de las herramientas de software SCED Comprensin de los tiempos de desarrollo SITE Amplitud del trabajo en sitios mltiples y calidad de las comunicaciones del sitio.
Ejemplo
Una 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.
96
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) 2. Flexibilidad de desarrollo: No se involucra el cliente valor Muy alto (1) 3. Resolucin de la arquitectura/riesgo: No se lleva a cabo un anlisis de riesgos valor Muy Bajo (5) 4. Cohesin del equipo: Creacin de un nuevo equipo por lo que no existe informacin Valor Nominal (3) 5. 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
1.
97
Si adems se supone que los conductores de costos clave en el proyecto son RELY, CPLX,STOR,TOOL y SCED:
Valor del Exponente Tamao del Sistema (incluyendo factores para reutilizacin y los requerimientos de volatilidad) Estimacin inicial de COCOMO sin conductores de costo 1.17 128.000 DSI 730 personas-mes
Fiabilidad Complejidad Restricciones de memoria Utilizacin de herramientas Calendarizacin Estimacin ajustada de COCOMO
Muy alta , multiplicador = 1.39 Muy alta, multiplicador = 1.3 Alta, multiplicador = 1.21 Baja, multiplicador = 1.12 Acelerada, multiplicador = 1.29 2306 personas-mes
98
Fiabilidad
Muy baja, multiplicador = 0.75 Ninguna, multiplicador = 1 Muy alta, multiplicador = 0.72 Normal, multiplicador = 1 295 personas-mes
En los ejemplos se consideraron valores extremos para ver como influye en la estimacin
99
D.Personal ms experimentado
100
101
La 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:
102
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 proyecto Este 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:
103
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.
104