metricas-tecnicas-del-software-1222288299021821-8

8/7/2019 metricas-tecnicas-del-software-1222288299021821-8

1/104

1

Mtricas Tcnicas

del Software


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.


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.


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.


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


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.


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/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.


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.


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


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)


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


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.


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.


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.


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.


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


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.


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


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


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.


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.


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.


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.


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.


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


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".


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


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


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


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.


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.


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.


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.


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.


36/104

36

Fenton sugiere varias mtricas de morfologa

simples que permiten comparar diferentes

arquitecturas mediante un conjunto de

dimensiones directas.


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


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


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.


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.


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.


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.


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


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.


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.


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)


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.


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.


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


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.


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.


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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


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 .


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


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.


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.


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


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


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


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


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.


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)


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.


79/104


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


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.


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


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.


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


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


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


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


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:


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


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


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


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.


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


94/104

94


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.



95/104

95


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.


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


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


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


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


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


incrementan . La experiencia

decrece

C.Slo actualizacin de la

memoria


incrementan

D.Personal ms

experimentado

F. Personal con experienciaen hardware


101/104

Duracin y personal del


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


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.


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.

metricas-tecnicas-del-software-1222288299021821-8

Documents

Transcript of metricas-tecnicas-del-software-1222288299021821-8