TECNICAS DE CALIDAD DE SOFTWARE Control de Calidad de Software.
metricas-tecnicas-del-software-1222288299021821-8
-
Upload
yalenis-sepulveda-vergel -
Category
Documents
-
view
214 -
download
0
Transcript of metricas-tecnicas-del-software-1222288299021821-8
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
1/104
1
Mtricas Tcnicas
del Software
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
2/104
2
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 vidapermitiendo descubrir y corregir problemas
potenciales.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
3/104
3
Calidad del Software
Los requisitos del Software son la base de lasmedidas de calidad. La falta de concordanciacon los requisitos es una falta de calidad.
Unos estndares especficos definen unconjunto de criterios de desarrollo que guan lamanera en que se hace la ingeniera delSoftware. Si no se siguen los criterios , habrseguramente poca calidad.
Existe un conjunto de requisitos implcitos queha menudo no se nombran. Si el softwarecumple con sus requisitos explcitos pero fallaen los implcitos , la calidad del software noser fiable.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
4/104
4
Factores de calidad de
McCall Los factores que afectan la calidad se
pueden categorizar en: Factores que se pueden medir directamente,
como por ejemplo los defectos por punto defuncin.
Factores que se pueden medir sloindirectamente, como por ejemplo lafacilidad de uso o mantenimiento.
En todos los casos debe aparecer lamedicin. Debe ser posible comparar elsoftware (documentos, programas, datos)con una referencia y llegar a una conclusinsobre la calidad.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
5/104
5
Factores de calidad
McCall y colegas (1997)
Revisin del
Producto
Transicin del
producto
Operacindel producto
Correccin Fiabilidad Usabilidad Integridad Eficiencia
Facilidad de
mantenimiento
Flexibilidad
Facilidad de prueba
Portabilidad
Reusabilidad
Interoperatividad
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
6/104
6
Operacin del Producto
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 recursosinformticos y de cdigo necesarios para
que un programa realice su funcin.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
7/104
7
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.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
8/104
8
Revisin del producto
Facilidad de mantenimiento: Elesfuerzo 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 programapara asegurarse de que realiza sufuncin pretendida.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
9/104
9
Transicin del producto
Portabilidad: El esfuerzo necesario paratransferir el programa de un entorno desistema hardware y/o software a otro
entorno diferente.
Reusabilidad ( capacidad de reutilizacin):Hasta donde se puede volver a emplear unprograma ( o partes de un programa) en
otras aplicaciones. Interoperatividad: El esfuerzo necesario
para acoplar un sistema con otro.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
10/104
10
Es difcil desarrollar medidas directas de los
factores de calidad sealadosanteriormente, 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
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
11/104
11
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 proponees una escala del 0 (bajo) al 10 (alto)
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
12/104
12
Mtrica para el esquema de
puntuacin: Facilidad de auditora: la facilidad con la
que se puede comprobar el cumplimientode los estndares.
Exactitud: la exactitud de lo clculos y elcontrol.
Estandarizacin de comunicaciones: elgrado de empleo de estndares deinterfaces, protocolos y anchos de banda.
Compleccin: el grado con que se halogrado la implementacin total de unafuncin.
Concisin :Lo compacto que es elprograma en trminos de lneas de cdigo
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
13/104
13
Consistencia: El empleo de un diseouniforme y de tcnicas de documentacin a lolargo del proyecto de desarrollo del software.
Estandarizacin de datos: El empleo deestructuras y tipos de datos estndares a lolargo 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 sepueden ampliar el diseo arquitectnico, de
datos o procedimental. Generalidad: la amplitud de aplicacin
potencial de los componentes del programa.
Independencia del hardware: El grado conque se desacopla el software del hardwaredonde opera.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
14/104
14
Instrumentacin:El grado con el que elprograma vigila su propio funcionamiento eidentifica los errores que ocurren.
Modularidad: La independencia funcionalde componentes de programa.
Operatividad: La facilidad de operacin deun programa.
Seguridad: La disponibilidad demecanismos que controlan o protegen losprogramas y los datos.
Autodocumentacin: El grado en que elcdigo fuente proporciona documentacin
significativa. Simplicidad: El grado de facilidad con que
se puede entender un programa.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
15/104
15
Independencia del sistema de software:
El grado de independencia de programa
respecto a las caractersticas del lenguajede programacin no estndar ,
caractersticas del sistema operativo y otras
restricciones del entorno.
Trazabilidad: La capacidad de seguir unarepresentacin 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 nuevosusuarios.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
16/104
16
FURPS (Funcionality, Usability,
Reliability, Performance, Supportability)
Hewlett Packard ha desarrollado un conjuntode factores de calidad del software al que se leha dado el acrnimo de FURPS: funcionalidad,facilidad de empleo, fiabilidad, rendimiento y
capacidad de soporte. Los factores de calidadson cinco y se definen de acuerdo al siguienteconjunto de atributos:
Funcionalidad. Se valora evaluando elconjunto de caractersticas y capacidades del
programa, la generalidad de las funcionesentregadas y la seguridad del sistema global.
Facilidad de uso. Se valora considerandofactores humanos, la estetica, consistencia ydocumentacin general.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
17/104
17
Fiabilidad. Se evala midiendo la frecuencia ygravedad de los fallos, la exactitud de las
salidas, el tiempo medio entre fallos, lacapacidad de recuperacin de un fallo y lacapacidad de prediccin del programa.
Rendimiento. Se mide por la velocidad deprocesamiento, el tiempo de respuesta,
consumo de recursos, rendimiento efectivo totaly eficacia.
Capacidad de soporte. Combina la capacidadde ampliar el programa (extensibilidad),adaptabilidad y servicios, as como la
capacidad de hacer pruebas, compatibilidad,capacidad de configuracin, la facilidad deinstalacin de un sistema y la facilidad con quese pueden localizar los problemas
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
18/104
18
Factores de Calidad ISO
9126 El estndar identifica seis atributos clave de
calidad:
Funcionalidad: El grado en que el software
satisface las necesidades indicadas por lossiguientes subatributos: idoneidad,correccin, interoperatividad,conformidad yseguridad.
Con
fiabilidad:
Cantidad de tiempo que elsoftware est disponible para su uso. Esta
referido por los siguientes subatributos:madurez, tolerancia a fallos y facilidad derecuperacin.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
19/104
19
Usabilidad: Grado en que el software es fcilde usar. Viene reflejado por los siguientessubatributos: facilidad de comprensin,
facilidad de aprendizaje y operatividad.
Eficiencia: Grado en que el software haceptimo el uso de los recursos del sistema.Viene reflejado por los siguientes subatributos:tiempo de uso y recursos utilizados.
Facilidad de mantenimiento: La facilidad conque una modificacin puede ser realizada. Estindicada por los siguientes subatributos:facilidad de anlisis , facilidad de cambio,estabilidad y facilidad de prueba.
Portabilidad: La facilidad con que el softwarepuede ser llevado de un entorno a otro. Estreferido por los siguientes subatributos:facilidad de instalacin, facilidad de ajuste,
facilidad de adaptacin al cambio
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
20/104
20
Paradoja de Jacob
Bronkowski Ao tras ao ingeniamos
instrumentos ms exactos con los que
observar la naturaleza con masexactitud. Y cuando miramos lasobservaciones estamosdesconcertados de ver que todavs
son confusas y tenemos la sensacinde que son tan inciertas comosiempre
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
21/104
21
Estructura para las mtricas
del Software La medicin asigna nmeros o smbolos a
atributos de entidades en el mundo real. Paraconseguirlo es necesario un modelo de medicinque comprenda un conjunto consistente de reglas.
Existe la necesidad de medir y controlar lacomplejidad del software, es bastante difcilobtener un solo valor para representar una"mtrica de calidad", sin embargo es posibledesarrollar medidas de diferentes atributos
internos del programa como ser: modularidadefectiva, independencia funcional y otros atributos.Estas mtricas y medidas obtenidas puedenutilizarse como indicadores independientes de lacalidad de los modelos de anlisis y diseo.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
22/104
22
Los principios bsicos de la medicin,sugeridos por Roche, pueden caracterizarsemediante cinco actividades: Formulacin. Obtencin de medidas y
mtricas del software apropiadas para larepresentacin del software en cuestin.
Coleccin. Mecanismo empleado paraacumular datos necesarios para obtener las
mtricas formuladas. Anlisis. Clculo de las mtricas y la
aplicacin de herramientas matemticas.
Interpretacin. Evaluacin de los resultadosde las mtricas en un esfuerzo por conseguir
una visin interna de la calidad de larepresentacin.
Realimentacin. Recomendacionesobtenidas de la interpretacin de mtricastcnicas transmitidas al equipo software.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
23/104
23
Ejiogu define un conjunto de atributosque deberan acompaar a las
mtricas efectivas del software. Lamtrica obtenida y las medidas queconducen a ello deberan ser:
Simple y fcil de calcular.
Emprica e intuitivamente persuasiva.
Consistente y objetiva.
Consistente en el empleo de unidadesy tamaos.
Independiente del lenguaje deprogramacin.
Un eficaz mecanismo para larealimentacin de calidad.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
24/104
24
La experiencia indica que unamtrica tcnica se usa
nicamente si es intuitiva y fcil
de calcular. Si se requieredocenas de contadores y se
han de utilizar complejos
clculos, la mtrica no serampliamente utilizada.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
25/104
25
Mtricas del Modelo de
Anlisis En esta fase es deseable que las
mtricas tcnicas proporcionen una
visin interna a la calidad del modelode anlisis. Estas mtricas examinan
el modelo de anlisis con la intencin
de predecir el "tamao" del sistema
resultante; es probable que el tamaoy la complejidad del diseo estn
directamente relacionadas.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
26/104
26
Mtricas basadas en la
Funcin La mtrica del punto de funcin (PF) sepuede utilizar como medio para predecir eltamao de un sistema obtenido a partir deun modelo de anlisis. Para visualizar esta
mtrica se utiliza un diagrama de flujo dedatos, el cual se evaluar para determinarlas siguientes medidas clave que sonnecesarias para el clculo de la mtrica depunto de funcin:
Nmero de entradas del usuario Nmero de salidas del usuario
Nmero de consultas del usuario
Nmero de archivos
Nmero de interfaces externas
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
27/104
27
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 todaslas entradas PF obtenidas de la figura
9.2 y Fi (i=1 a 14) son los "valores de
ajuste de complejidad".
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
28/104
28
Para el ejemplo descrito en la figura 9.2 se asume quela 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
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
29/104
29
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 lenguajeorientado 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 deplanificacin basada en el modelo de anlisis
en lugar de estimaciones preliminares
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
30/104
30
Otras Mtricas para el
Modelo de Anlisis La 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
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
31/104
31
Mtricas del modelo de
Diseo La gran irona de las mtricas de diseo
para el software es que las mismas estndisponibles, pero la gran mayora de los
desarrolladores de software continan sinsaber que existen.
No son perfectas y contina el debate sobresu eficacia y como deberan aplicarse.
Algunos expertos sealan que es necesario
mayor experimentacin hasta que sepuedan emplear adecuadamente. Sinembargo el diseo sin medicin es unaalternativa inaceptable.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
32/104
32
Mtricas de diseo de alto nivel
Se concentran en las caractersticas
de la arquitectura del programa , con
nfasis en la estructura arquitectnicay 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.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
33/104
33
Card y Glass definen las siguientes
tres medidas de complejidad
La complejidad estructural, S(i), de un
mdulo i se define de la siguiente
manera: S(i)=f2
out(i). Donde fout(i) esla expansin del mdulo i.La
expansin indica el nmero de
mdulos que son invocados
directamente por el mdulo i.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
34/104
34
La complejidad de datos, D(i),
proporciona una indicacin de la
complejidad en la interfaz interna deun 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 mduloi.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
35/104
35
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.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
36/104
36
Fenton sugiere varias mtricas de morfologa
simples que permiten comparar diferentes
arquitecturas mediante un conjunto de
dimensiones directas.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
37/104
37
Tamao= n + a . Donde n es elnmero de nodos (mdulos) y a es elnmero de arcos (lneas de control).Para la arquitectura mostrada se tienetamao= 17+18=35.
Profundidad= camino ms largodesde el nodo raz a un nodo hoja.Para el ejemplo Profundidad= 4
Amplitud=nmero mximo de nodosde cualquier nivel de la arquitectura.Para el ejemplo amplitud= 6
Mtricas a aplicar
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
38/104
38
Relacin arco a nodo, r=a/n, mide la
densidad de conectividad de la
arquitectura y proporciona unaindicacin sencilla de acoplamiento
de la arquitectura. Para el ejemplo
r=18/17= 1.06
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
39/104
39
Mtricas del Cdigo Fuente
La teora de la ciencia del softwarepropuesta por Halstead es probablementela medida de complejidad mejor conocida y
minuciosamente estudiada. La ciencia delsoftware propuso la primera ley analtica ycuantitativa para el software decomputadora.
Utiliza un conjunto de medidas primitivasque pueden obtenerse una vez que se hangenerado o estimado el cdigo despus decompletar el diseo.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
40/104
40
Estas medidas son:
n1: nmero de operadores diferentes
que aparecen en le programa.
n2: nmero de operandos diferentesque aparecen en el programa.
N1: nmero total de veces que
aparece el operador. N
2: nmero total de veces que
aparecen el operando.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
41/104
41
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 defallos en el software.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
42/104
42
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 deprogramacin y representa el volumen de
informacin (en bits) necesarios para
especificar un programa.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
43/104
43
Ejemplo:
Programa de ordenacin por intercambioSUBROUTINE 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
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
44/104
44
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 n1=10 y N1=28.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
45/104
45
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
De esta tabla se desprenden los valores de n2=7 y N
2=22.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
46/104
46
Mtricas para las Pruebas
La mayora de las mtricas para pruebas seconcentran en el proceso de prueba, no en lascaractersticas tcnicas de las pruebas mismas. Engeneral, los responsables de las pruebas deben fiarseen las mtricas de anlisis, diseo y cdigo para quesirvan de gua en el diseo y ejecucin de los casosde prueba.
El esfuerzo de las pruebas tambin se puede estimarutilizando mtricas obtenidas de las medidas deHalstead. Usando la definicin del volumen de un
programa, V, y nivel de programa, NP, el esfuerzo dela ciencia del software puede calcularse como:
NP = 1/[(n1/2) x (N2/n2)] (Ec. 9.1)
e = V/NP (Ec. 9.2)
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
47/104
47
El porcentaje del esfuerzo global depruebas a asignar a un mdulo k se puedeestimar utilizando la siguiente relacin:
Porcentaje de esfuerzo depruebas(k) = e(k)/e(i) (Ec. 9.3)
Donde e(k) se calcula para el mdulo kutilizando las ecuaciones (Ec. 9.1) y (Ec.
9.2
), la suma en el denominador de laecuacin (Ec. 9.3) es la suma del esfuerzode la ciencia del software a lo largo detodos los mdulos del sistema.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
48/104
48
A medida que se van haciendo las pruebas, tresmedidas 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 delnumero total de ellos. Indica la complecin del plan depruebas.
Profundidad de las pruebas. Medida del porcentaje de
los caminos bsicos independientes probados conrelacin al nmero total de estos caminos en elprograma. Se puede calcular una estimacinrazonablemente exacta del nmero de caminosbsicos sumando la complejidad ciclomtica de todoslos mdulos del programa.
Perfiles de fallos. Se emplean para dar prioridad ycategorizar los errores. La prioridad indica la severidaddel problema. Las categoras de los fallosproporcionan una descripcin de un error, de maneraque se puedan llevar a cabo anlisis estadstico deerrores.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
49/104
49
MTRICAS DEL
MANTENIMIENTO Todas las mtricas descritas pueden utilizarse para el
desarrollo de nuevo software y para el mantenimientodel existente.
El estndarIEEE 982.1-1988 sugiere el ndice demadurez del software (IMS) que proporciona una
indicacin de la estabilidad de un producto softwarebasada en los cambios que ocurren con cada versindel producto. Con el IMS se determina la siguienteinformacin:
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 sehan eliminado
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
50/104
50
El ndice de madurez del software secalcula de la siguiente manera:
IMS= [MT - (Fc + Fa + Fe)]/MT
A medida que el IMS se aproxima a 1el producto se empieza a estabilizar.El IMS puede emplearse tambin
como mtrica para la planificacin delas actividades de mantenimiento delsoftware.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
51/104
51
Medicin y mtricas de
Software [Sommerville]cap.24
La medicin del software se refiere a derivara un valor numrico para algn atributo deun 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 mtricassistemticas de software. La reticencia aluso es debido a que los beneficios noson
claros.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
52/104
52
Por otra parte no existen estndares paralas mtricas y, por lo tanto existe ayudalimitada para la recoleccin y anlisis dedatos.
Las mtricas son de control o de prediccin: Control: por lo general se asocian con los
procesos del software. Ejemplo, el esfuerzoy el tiempo promedio requerido para repararlos defectos reportados.
Prediccin : se asocian con los productosdel software. Ejemplo, la complejidadciclomtica de un mdulo, la longitud
promedio de los indicadores en un programay el nmero de atributos y operacionesasociadas con los objetos de un diseo.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
53/104
53
Toma de decisiones
administrativas
Proceso de
Software
Medidas
de Control
Decisiones
administrativas
Producto de
software
Medidas de
prediccin
Ambas mtricas influyen en la toma de
decisiones administrativas
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
54/104
54
Mtricas para predecir la
calidad A menudo es imposible medir los atributos
de calidad del software en forma directa.
Los atributos como la complejidad , lamantenibilidad y la comprensin se venafectados por diversos factores y no existenmtricas directas para ellos.
Ms bien es necesario medir un atributointerno del software ( como el tamao) ysuponer que existe una relacin entre loque se puede medir y lo que se quieresaber.
De forma ideal , existe una relacin claravlida entre los atributos de softwareinternos y externos.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
55/104
55
Relacin entre los atributos
externos e internos
Mantenibilidad
Fiabilidad
Portabilidad
Usabilidad
Nmero de parmetros
del procedimiento
Complejidad ciclomtica
Tamao del programa
en lneas de cdigo
Nmero de mensajes deerror
Extensin del manual
de usuarioNo dice qu relacin es
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
56/104
56
Mtricas del producto
Se refiere a las caractersticas del software.
En general las organizaciones construyensus bases de datos histricas para
relacionar las mediciones obtenidas. Se dividen en dos clases:
Mtricas dinmicas recolectadas por lasmediciones hechas en un programa enejecucin.
Las mtricas estticas recolectadas por lasmediciones hechas en las representacionesdel sistema como el diseo, el programa o ladocumentacin.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
57/104
57
Estas diferentes mtricas estnrelacionadas con diversos atributos decalidad.
Las mtricas dinmicas ayudan a a valorarla eficiencia y la fiabilidad de un programamientras que las mtricas estticas ayudana valorar la complejidad, la comprensin yla mantenibilidad de un sistema desoftware.
Las mtricas estticas , por otro lado,tienen una relacin indirecta con losatributos de calidad.
Las mtricas especficas relevantesdependen del proyecto, de las metas delequipo de administracin de la calidad y deltipo de software a desarrollar.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
58/104
58
Medicin del proceso
cap.25
Son datos cuantitativos de losprocesos del software.
Se utilizan para evaluar si la eficienciade un proceso ha mejorado. Porejemplo se puede medir el esfuerzo ytiempo dedicado a las pruebas. Las
mejoras efectivas para los procesosde prueba reducen el esfuerzo , eltiempo de prueba o ambos.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
59/104
59
Se pueden recolectar tres
clases de mtricas del proceso:
1. 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.
2. 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.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
60/104
60
3. 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 modificadasen respuesta a un cambio de
requerimientos, etc.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
61/104
61
Estimacin del Costo del
SoftwareC
ap.23
La estimacin y calendarizacin delproyecto se llevan a cabo de formaconjunta.
Sin embargo se debe contar conestimaciones previas para ver losefectos sobre la calendarizacin y
stas se actualizan de forma regular. Permite la utilizacin efectiva de los
recursos y una adecuada planeacin.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
62/104
62
Parmetros involucrados en
el costo total de un proyecto: Costos de hardware y software ,
incluyendo mantenimiento.
Costos de viajes y capacitacin Costos de esfuerzo ( pago a los
ingenieros de Software)
Para muchos proyectos , el costodominante es el costo de esfuerzo.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
63/104
63
Costos de esfuerzo:
Costos de proveer, calentar e iluminar lasoficinas.
Costos del personal de apoyo como
contadores , secretarias, limpiadores ytcnicos.
Costos de las redes y las comunicaciones.
Costos de los recursos centralizados comobibliotecas, los recursos recreativos,etc.
Costos de seguridad social y de beneficiode empleados como las pensiones yseguros de salud.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
64/104
64
Factores que afectan la
asignacin de precios al software.
Oportunidad de mercado: penetracin demercado con cotizacin de bajos costos alinicio.
Incertidumbre: Si no hay seguridad en elcosto estimado, por alguna contingenciapuede incrementar su precio por encima delbeneficio normal.
Trminos contractuales: Reducir el costo a
partir de asumir restricciones como porejemplo entrega del cdigo fuente y que eldesarrollador lo pueda reutilizar en otrosproyectos.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
65/104
65
Volatilidad de los requerimientos: Si esprobable que los requerimientos cambien,podra reducirse los precios para ganar uncontrato. Despus del contrato se cargan
precios altos a los cambios derequerimientos.
Salud Financiera: Cuando losdesarrolladores tienen dificultadesfinancieras podran bajar sus costos para
ganar contratos. Esto es mejor que quedarfuera del negocio o quebrar
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
66/104
66
Productividad
Cuando se produce soluciones condiferentes atributos, no tiene sentidocomparar tasas de productividad, sin
embargo las estimaciones son necesariaspara las estimaciones del proyecto y paravalorar si los procesos o las mejorastecnolgicas son efectivas.
Por lo general estas estimaciones se basanen medir algunos atributos del software ydividir el resultado entre el esfuerzo totalrequerido para el desarrollo.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
67/104
67
Medidas utilizadas:
Relacionadas con el Tamao: serelacionan con el tamao de algunasalida de una actividad. La medidams comn son las lneas de cdigofuente entregadas. Tambin se utilizael nmero de instrucciones de cdigoobjeto entregado o el nmero depginas de la documentacin delsistema
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
68/104
68
Medidas utilizadas:
Relacionadas con la funcin: se
relacionan con la funcionalidad total
del software entregado. Laproductividad se expresa en trminos
de la cantidad de funcionalidad til
producida en un tiempo dado.
Ejemplos de esta medidas son puntosde funcin y puntos de objetos .
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
69/104
69
(Un parntesis ) Puntos de objetos : el nmero de puntos de objeto
en un programa es una estimacin de peso ( no sonclases de objetos que se producen cuan se consideraorientacin objeto para el desarrollo del software):
El nmero de pantallas independientes que sedespliegan. Las pantallas sencillas cuentan como 1
punto de objeto, las moderadamente complejascuentan como 2 y las muy complejas cuentan como 3puntos de objeto.
El nmero de informes que se producen, simples son2 puntos de objeto, moderadamente complejos son 5puntos de objeto y para informes que son difciles de
producir8 puntos de objetos.
El nmero de mdulos 3GL que deben desarrollarsepara complementar el cdigo 4GL. Cada mdulo 3GLcuenta como 10 puntos objetos
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
70/104
70
Tcnicas de Estimacin
No existe una forma simple de hacer unaestimacin precisa del esfuerzo requeridopara desarrollar un sistema de software.
Por lo general, las estimaciones de loscostos del proyecto se cumplen por supropia naturaleza.
A pesar de las dificultades e impresiones
las organizaciones requieren haceresfuerzos de software y estimaciones decostos.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
71/104
71
Tcnicas de estimaciones de
costos Modelado del algoritmo de costos:
Se desarrolla un modelo utilizandoinformacin histrica de costos querelaciona alguna mtrica de software( por logeneral su tamao) con el costo del
proyecto. Se hace una estimacin de samtrica y el modelo predice el esfuerzorequerido.
Opinin de expertos: Se consultan varios expertos en las tcnicas
de desarrollo de software propuestas y en eldominio de la aplicacin. Cada uno de ellosestima el costo del proyecto. Estasestimaciones se comparan y discuten. Elproceso de estimacin se itera hasta que seacuerda una estimacin.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
72/104
72
Estimacin por analoga: Esta tcnica es aplicable cuando otros
proyectos en el mismo dominio de aplicacinse han completado. Se estima el costo deun nuevo proyecto por analoga con estosproyectos completados.
Ley de Parkinson: Establece que el trabajo se extiende para
llenar el tiempo disponible. El costo sedetermina por los recursos disponibles msque por los objetivos logrados. Si el softwarese tiene que entregar en 12 meses y sedispone de cinco personas, el esfuerzorequerido se estima en 60 personas-mes
Tcnicas de estimaciones de
costos
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
73/104
73
Asignar precios para ganar:
El costo del software se estima independientementede lo que el cliente est dispuesto a pagar por elproyecto. El esfuerzo estimado depende delpresupuesto del cliente y no de la funcionalidad del
software.
Cada tcnica de estimacin tiene sus propiasdebilidades y fortalezas.
Para proyectos grandes se deben aplicar varias
tcnicas de estimaciones de costos y comparar susresultados.
Estas tcnicas de estimacin son aplicables cuandoexiste un documento de requerimientos para elsistema.
Tcnicas de estimaciones
de costos
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
74/104
74
Modelado algortmico de costos
Se construye analizando los costos yatributos de los proyectos realizados.
Se utiliza una frmula matemtica para
predecir los costos basados enestimaciones del tamao del proyecto,nmero de programadores y otros factoresde los procesos y productos.
Kitchenham (1990) describe 13
modelosalgoritmos de costos desarrollados a partirde observaciones empricas.
Forma mas general para expresar
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
75/104
75
Forma mas general para expresar
una estimacin algortmica de
costos: Esfuerzo = A x TamaoB x M
A es un factor constante que depende de las prcticasorganizacionales locales y del tipo de software que sedesarrolla.
Tamao es una valoracin del tamao del cdigo delsoftware o una estimacin de la funcionalidadexpresada en puntos de funcin o de objetos.
El valor del exponente B por lo general se encuentraentre 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
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
76/104
76
Dificultades comunes:
Es difcil estimar Tamao en una
primera etapa de un proyecto donde
solamente esta disponible laespecificacin.
Las estimaciones de los factores B y
M son subjetivas. Vara de una
persona a otra segn su experiencia yconocimiento.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
77/104
77
Modelo COCOMO
Modelo emprico
Se obtuvo recolectando datos de variosproyectos de software grandes, y despus
analizando esos datos para descubrirfrmulas que se ajustarn mejor a lasobservaciones.
Esta bien documentado, es de dominiopblico y lo apoyan herramientas
comerciales. Se ha utilizado y evaluado ampliamente.
Ha evolucionado del COCOMO81( 1981) alCOCOMO2 (1995)
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
78/104
78
COCOMO Bsico
Complejidad
del proyecto
Frmula Descripcin
Simple PM = 2.4 (KDSI)1.05 x M 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
Incrustada PM = 3.6 (KDSI)1.20 x M Proyectos complejos donde el software
es parte de un complejo fuertemente
acoplado de hardware, software, reglas
y procedimientos operacionales.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
79/104
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
80/104
80
Evolucin COCOMO
COCOMO81 supone que el software se desarrollaacorde a un proceso en cascada y que la mayora delsoftware se construye desde cero.
Lo anterior hoy no es vlido pues existe creacin de
software a partir de el ensamblado de componentesreutilizables vinculndolos a travs de script(secuencia de comandos).
Los modelos de procesos mas comnmente utilizadoshoy son el de prototipos y el incremental.
Se utiliza la reingeniera para crear nuevos procesos
La utilizacin de mejores herramientas como lasCASE hacen mas dinmico el proceso deconstruccin.
Todo lo anterior hace evolucionar al COCOMO81 alactual modelo COCOMO2
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
81/104
81
COCOMO2
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.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
82/104
82
Niveles del COCOMO2
Nivel de construccin de prototipo inicial: Las estimaciones de tamao se basan en puntos de
objeto y se utiliza un frmula sencillatamao/productividad para estimar el esfuerzorequerido.
Nivel de diseo inicial: Corresponde a la terminacin de requerimientos del
sistema con algn diseo inicial.. Las estimaciones sebasan en puntos de funcin que se convierten anmero de lneas de cdigo fuente.
Nivel postarquitectnico:
Una vez que se disea la arquitectura del sistema sehace una estimacin razonablemente precisa deltamao del software. En este nivel se utiliza unconjunto mas grande de multiplicadores que reflejan lacapacidad del personal, el producto y las caractersticasdel proyecto.
Ni l d t i d
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
83/104
83
Nivel de construccin de
prototipo inicial Permite la estimacin del esfuerzo requerido en
construccin de prototipos y para proyectos donde elsoftware se desarrolla utilizando componentesexistentes.
Se basa en una estimacin de los puntos de objetosde peso, la cual se divide en una cifra estndar deproductividad estimada.
La productividad del programador depende de laexperiencia y capacidad del desarrollador y las
caractersticas de las herramientasCASE.
La reutilizacin es comn , por lo que el nmero depuntos de objeto utilizados en la estimacin del tiempose ajusta para tomar en cuenta el porcentaje dereutilizacin que se espera.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
84/104
84
Formula PM= ( NOPx (1 - %reutilizacin/100)) / PROD
PM es el esfuerzo en personas-mes
NOP es el nmero de puntos de objeto y
PROD es la productividad
Experiencia y
capacidad de los
desarrolladores
Muy
Baja
Baja Nominal Alta MuyAlta
Madurez ycapacidadCASE
MuyBaja Baja
Nominal
Alta
Muy
Alta
PROD (NOP/mes) 4 7 13 25 50
Productividad de los Puntos de objeto
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
85/104
85
El nivel de Diseo Inicial
Las estimaciones se basan en frmulaestndar para modelos algortmicos:
Esfuerzo = A x TamaoB x M
A segn Boehm (experimentacin) es de 2.5para las estimaciones hechas a este nivel.
Tamao se expresa en KSLOC, es decir, elnmero de miles de lneas de cdigo fuente.
KSLOC
se calcula estimando el nmero depuntos de funcin en el software y convirtiendoloste a KSLOC utilizando la tabla estndar querelacionan el tamao del software a puntos defuncin para diferentes lenguajes deprogramacin
El exponente B refleja el esfuerzo creciente
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
86/104
86
El exponente B refleja el esfuerzo crecienterequerido al incrementarse el tamao delproyecto. Puede variar de 1.1 a 1.24dependiendo de la novedad del proyecto, laflexibilidad del desarrollo , los procesosutilizados de resolucin de riesgos, lacohesin del equipo de desarrollo y en nivelde madurez.
M se basa en un conjunto de simplificado de 7
conductores de proyectos y procesos en losque se incluye la fiabilidad y complejidad delproducto (RCPX), la reutilizacin requerida(RUSE), la dificultad de la plataforma (PDIF),la capacidad del personal (PERS), laexperiencia del personal (PREX), la
calendarizacin (SCED) y los recursos deapoyo (FCIL). Estos pueden estimarse en unaescala de 1 a 6, 1 corresponde a un valor muybajo y 6 a valores muy altos.
Formula del esfuerzo segn los
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
87/104
87
Formula del esfuerzo segn los
multiplicadores sealados:
P=Ax TamaoB xM + PMm donde
M= PERS x RCPX x RUSE x PDIF x FCIL xSCED.
PMm es un factor que se utiliza cunado un
porcentaje importante del cdigo se generade forma automtica. PMm = (ASLOCx (AT / 100)) / ATPROD
ASLOC nmero de lneas generadasautomticamente de cdigo fuente.
ATPROD es el nivel de productividad paraeste tipo de produccin de cdigo.
AT porcentaje del cdigo total del sistemaque se genera automticamente
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
88/104
88
El nivel postarquitectnico
Las estimaciones se basan en la mismafrmula bsica que se utiliza en lasestimaciones iniciales del diseo.
La estimacin del tamao para el softwarees mas precisa utilizando 17 atributos enlugar de 7 para refinar el clculo delesfuerzo inicial.
La estimacin del nmero total de lneas de
cdigo fuente se ajusta para tomar encuenta dos factores importantes delproyecto:
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
89/104
89
La volatilidad de los requerimientos:
Se realiza un estimacin de la revisin, quepuede ser requerida para acomodarcambios en los requerimientos del sistema.Se expresa como el nmero de lneas decdigo fuente que se deben modificar y estenmero se suma a la estimacin inicial del
tamao. Amplitud de la posible reutilizacin:
Una reutilizacin amplia significa que sedeben modificar el nmero de lneas decdigo fuente que realmente se
desarrollarn. El costo no es lineal puesdebido al esfuerzo inicial requerido paradescubrir y seleccionar los componentes ydebido al esfuerzo requerido para modificary comprender los componentes reutilizablesy sus interfaces.
Ef t d l tili i
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
90/104
90
Efecto de la reutilizacin en
COCOMO2 Se ajusta el tamao del esfuerzo de acuerdo con la siguiente
frmula:
ESLOC=ASLOCx ( AA+SU+0.4DM+ 0.3IM + 0,3CM)/100
ESLOC es el nmero equivalente de lneas de cdigo nuevo.
ASL
OC
es el nmero de lneas de cdigo reutilizable quedeben 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 elsoftware reutilizado.
SU
es un factor que se basa en el costo de comprensin delsoftware que vara desde 50 para cdigo complejo noestructurado hasta 10 para cdigo orientado al objeto bienescrito
AAes un factor que refleja los costos de valoracin inicial de laposible reutilizacin del software. Va desde 0 a 8. Depende dela cantidad de pruebas y evaluaciones requeridas.
E ti i d l E t d l
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
91/104
91
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
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
92/104
92
Factores de escala utilizados en el
clculo del exponente del COCOMO2
Precedentes Refleja la experiencia previa de la organizacin coneste tipo de proyectos. Muy bajo significa sin
experiencia previa; Extraalto significa que la
organizacin est completamente familiarizada con
este dominio de aplicacin
Flexibilidad Refleja el grado de flexibilidad en el proceso dedesarrollo. Muy bajo significa que se utiliza un proceso
prescrito; Extraalto significa que el cliente establece
slo metas generales
Resolucin de la
arquitectura/riesgo
Refleja la amplitud del anlisis de riesgo que se lleva a
cabo . Muy bajo significa poco anlisis; Extraalto
significa un anlisis de riesgo completo y detallado.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
93/104
93
Cohesin del
equipo
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 .
Madurez del
Proceso
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.
Atributos que se utilizan para ajustar las
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
94/104
94
Atributos que se utilizan para ajustar las
estimaciones iniciales en el modelo
postarquitectnico (4) :
1. 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 componentesreutilizables
2. Atributos de la computadora:
TIME Restricciones del tiempo de ejecucin
PVOL Volatilidad de la plataforma de desarrollo
STOR Restricciones de memoria.
Atributos que se utilizan para ajustar las
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
95/104
95
Atributos que se utilizan para ajustar las
estimaciones iniciales en el modelo
postarquitectnico (4) :
3. Atributos personales:
ACAP Capacidad de anlisis del proyecto.
PCON continuidad del personal
PEXP Experiencia del programador en el dominiodel proyecto
PCAP Capacidad del programador
AEXP Experiencia del analista en el dominio delproyecto
LTEX Experiencia en el lenguaje y las herramientas
4. Atributos del proyecto: TOOL Utilizacin de las herramientas de software
SCED Comprensin de los tiempos de desarrollo
SITE Amplitud del trabajo en sitios mltiples ycalidad de las comunicaciones del sitio.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
96/104
96
Ejemplo
Una organizacin trabaja un proyecto en elque se tiene poca experiencia en eldominio. El cliente del proyecto no hadefinido el proceso a utilizar y noproporciona suficiente tiempo en lacalendarizacin del proyecto para que sehaga un anlisis de riesgos. Se tiene queformar un nuevo equipo de desarrollo paraimplementar este sistema. La organizacin
ha puesto en proceso un programa demejoramiento y ha obtenido en Nivel 2 delmodelo CMM.
Posibles valores de los factores de
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
97/104
97
Posibles valores de los factores de
escala utilizados en el clculo del
exponente son:
1. Precedentes : Este es un proyecto nuevo para laorganizacin valor Bajo (4)
2. Flexibilidad de desarrollo: No se involucra el clientevalor Muy alto (1)
3. Resolucin de la arquitectura/riesgo: No se lleva acabo un anlisis de riesgos valor Muy Bajo (5)
4. Cohesin del equipo: Creacin de un nuevo equipopor 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
Si adems se supone que los conductores de
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
98/104
98
Si adems se supone que los conductores de
costos clave en el proyecto son RELY,
CPLX,STOR,TOOL y SCED:
Valor del Exponente 1.17
Tamao del Sistema (incluyendo factores para reutilizaciny los requerimientos de volatilidad)
128.000 DSI
Estimacin inicial de COCOMO sin conductores de
costo
730 personas-mes
Fiabilidad Muy alta , multiplicador = 1.39
Complejidad Muy alta, multiplicador = 1.3
Restricciones de memoria Alta, multiplicador = 1.21
Utilizacin de herramientas Baja, multiplicador = 1.12
Calendarizacin Acelerada, multiplicador = 1.29
Estimacin ajustada de COCOMO 2306 personas-mes
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
99/104
99
Fiabilidad Muy baja, multiplicador = 0.75
Complejidad Muy baja, multiplicador = 0.75
Restricciones de memoria Ninguna, multiplicador = 1
Utilizacin de herramientas Muy alta, multiplicador = 0.72
Calendarizacin Normal, multiplicador = 1
Estimacin ajustada de COCOMO 295 personas-mes
En los ejemplos se consideraron valores extremos
para ver como influye en la estimacin
Modelos algortmicos de costos en
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
100/104
100
Modelos algortmicos de costos en
la planeacin del proyecto
A. Utilizar el hardware existente, sistema
de desarrollo y equipo de desarrollo
B. Actualizacin del Procesador y de la
memoria
Los costos de hardware se
incrementan , la experiencia decrece
E. Nuevo sistema de desarrollo
Los costos de hardware se
incrementan . La experiencia
decrece
C.Slo actualizacin de la
memoria
Los costos de hardware se
incrementan
D.Personal ms
experimentado
F. Personal con experienciaen hardware
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
101/104
Duracin y personal del
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
102/104
102
Duracin y personal del
proyecto
La relacin entre el nmero de personasque trabajan en un proyecto, el esfuerzototal requerido y el tiempo de desarrollo noes lineal.
Formula para estimar el tiempo calendariorequerido para completar un proyectoTDEV: TDVE = 3 x (PM) (0.33+0.2x(B-1.01))
PM es el clculo del esfuerzo
B es el exponente que refleja el esfuerzocreciente requerido al incrementarse eltamao del proyecto
Este clculo predice la duracin nominal delproyecto
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
103/104
103
La duracin prevista del proyecto y larequerida por el plan del proyecto noson necesariamente lo mismo. Laduracin planeada es ms corta o mslarga que la duracin prevista original.
Sin embargo existe un lmite obvio paralos cambios de duracin, el cual sepredice en COCOMO2 como: TDVE = 3 x (PM) (0.33+0.2x(B-1.01)) x SCEDpercentage/100
SCEDpercentage es el porcentaje decrecimiento o decrecimiento en laduracin nominal.
-
8/7/2019 metricas-tecnicas-del-software-1222288299021821-8
104/104
Un crecimiento muy rpido del
personal del proyecto a menudo est
correlacionado con retrasos en laduracin del proyecto.
Si se reduce el tiempo de desarrollo ,
siendo un factor clave, el esfuerzo
requerido para desarrollar el sistemacrece exponencialmente.