METRICAS DEL PRODUCTO PARA

EL SOFTWARE
Docente: MSc. Claudia Benavidez Rugama
INTRODUCCION
La medicin es un elemento clave en
cualquier proceso de ingeniera. Las
medidas se emplean para comprender
mejor los atributos de los modelos que se
crean y evaluar la calidad de los
productos de la ingeniera o de los
sistemas que se construyen.
INTRODUCCION
Aunque las mtricas del producto para el
software de computadora no pueden ser
absolutas, proporcionan una manera
sistemtica de evaluar la calidad a partir de un
conjunto de reglas definidas con claridad.
Tambin proporcionan al ingeniero de software
informacin inmediata y en el sitio, no
posterior al hecho. Esto permite al ingeniero
descubrir y corregir problemas potenciales
antes de que se conviertan en defectos
catastrficos.
Tipos de Mtricas

UN MARCO CONCEPTUAL PARA LAS MTRICAS DEL PRODUCTO

Medidas, mtricas e indicadores
Aunque estos tres trminos pueden utilizarse de manera intercambiable, es
necesario especificar las diferencias entre stos.

Medida: Proporciona indicacin cuantitativa de la extensin, la cantidad, la
dimensin, la capacidad o el tamao de algn atributo de un producto o
proceso.

Algunos ejemplos son los siguientes:
1. Lneas de cdigo (LDC).
2. Esfuerzo en hombre-mes.
3. Costo en pesos o dlares.
4. Nmero de pginas de documentacin.
5. Nmero de errores. Fallas detectadas antes de entregar el software al
cliente.
6. Nmero de defectos. Fallas detectadas despus de entregar el software al
cliente.
7. Nmero de personas en el proyecto.

Medicin: Acto de determinar una medida.

Mtrica: Medida cuantitativa del grado en que un sistema, componente o
proceso posee un atributo determinado.
Ejemplo:
1. Errores por KLDC (mil lneas de cdigo).
2. Defectos por KLDC.
3. Costo por KLDC.
4. Pginas de documentacin por KLDC.
5. Errores por hombre-mes.
6. LDC por hombre-mes.
7. Costo por pgina de documentacin.

Indicador: Mtrica o combinacin de mtricas que proporcionan conocimientos.
Estos conocimientos le permiten al jefe de proyecto o a los ingenieros de
software ajustar el proceso, el proyecto o el producto para que las cosas sean
mejores.

Los indicadores permiten:
1. Evaluar el estado del proyecto en curso.
2. Seguir la pista de los riesgos potenciales.
3. Detectar las reas de problemas.



Por ejemplo: Si una organizacin de software mantiene registros sencillos, se
puede crear una tabla de datos orientados al tamao como se muestra en la
siguiente figura:
Proyecto Esfuerzo $ KLDC Pag.Doc Errores Gente
999-01 24 168 12.1 365 29 3
CCC-04 62 440 27.2 1124 86 5
FFF-03 43 314 20.2 1050 64 6
La tabla lista cada proyecto del
desarrollo del software de los
ltimos aos correspondientes,
datos orientados al tamao de c/u.
Refirindonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12.1KLDC
(miles de lneas de cdigo) con un esfuerzo de 24 personas mes y un costo de168 mil
dlares.

Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las
actividades de la ingeniera de software como son anlisis, diseo, codificacin y prueba.

Otra informacin del proyecto 999-01 indica que se desarrollaron 365 pginas mientras
que se encontraron 29 errores tras entregrselo al cliente, dentro del primer ao de
utilizacin tambin sabemos que trabajaron 3 personas en el desarrollo del proyecto.

En los rendimientos del sistema y los rudimentarios datos contenidos en la
tabla se puede desarrollar, para cada proyecto un conjunto de mtricas
sencillas de productividad y calidad orientadas al tamao.

Se obtienen las siguientes formulas:
Donde la frmula del esfuerzo de Bassili es:

E=5.5 + 0.73 KLOC
1.16


El reto de las mtricas del producto
Aunque se han propuesto docenas de medidas de complejidad, cada una
tiene un concepto diferente de la complejidad y de los atributos de un
sistema que llevan a la complejidad.

El peligro de tratar de encontrar medidas que caractericen tantos
atributos diferentes es que inevitablemente las medidas tienen que
satisfacer objetivos que entran en conflicto entre s.

Muchas personas argumentan que la medicin del producto realizada
durante las primeras etapas del proceso de software proporciona a los
ingenieros un mecanismo consistente y objetivo para evaluar la calidad.

Importancia de las Mtricas.
Permiten obtener una comprensin cuantitativa del proceso, as como
evaluar un producto o controlarlo; adems permiten producir un
estimado y mejorar la calidad del software.

Principios de medicin:



Formulacin.
Recoleccin
Anlisis.
Interpretacin.
Retroalimentacin


Roche sugiere un proceso de medicin al que caracterizan cinco
actividades:

La derivacin de medidas y mtricas
apropiadas para la representacin del
software que se considere.
Mecanismo con que se acumulan
los datos necesarios para derivar
las mtricas formuladas.
Clculo de las mtricas y la
aplicacin de herramientas
matemticas.
Evaluacin de las mtricas en un
esfuerzo por conocer mejor la
calidad de la representacin.
Recomendaciones derivadas de la
interpretacin de las mtricas del
producto transmitidas al equipo del
software.
Principios de medicin:






Existen principios que son representativos de muchos otros
que podran proponerse para caracterizar y validar las
mtricas:

Una mtrica debe tener propiedades matemticas
deseables.
Cuando una mtrica representa una caracterstica de
software que aumenta cuando se presentan rasgos
positivos o que disminuye al encontrar rasgos
indeseables, el valor de la mtrica debe aumentar o
disminuir en el mismo sentido.
Cada mtrica debe validarse empricamente en una
amplia variedad de contextos antes de publicarse o
aplicarse a la toma de decisiones.
Mtodo Medicin
Identificar los atributos
de las entidades del dominio
Identificar relaciones
empricas para los
atributos
Identificar relaciones
numricas correspondientes
a cada relacin emprica
Definir el mapping entre
las
entidades y los nmeros
Verificar que la
semntica de las
relaciones empricas se
preserva en las
relaciones numricas
Medicin del Software Orientado a Objetivos


Basili y Weiss desarrollaron el paradigma
objetivo/pregunta/mtrica (OPM) como una tcnica para
identificar mtricas significativas aplicables en cualquier parte
del proceso del software. El OPM destaca la necesidad de:

1. Establecer un objetivo de medicin explicito que sea
especifico para la actividad del proceso o las caractersticas
del producto que se est evaluando.
2. Definir un conjunto de preguntas que deben responderse con
el fin de alcanzar el objetivo.
3. Identificar mtricas bien formuladas que ayuden a responder
esas preguntas.


Basili ha proporcionado una serie de plantillas que son tiles para los
desarrolladores que deseen utilizar OPM para desplegar mtricas
realistas sobre sus proyectos. Cada una de sus plantillas se explica a
continuacin:

La plantilla o esquema de clculo denominada de propsito. Se
utiliza para articular o comparar lo que est siendo analizado.

Una segunda plantilla est relacionada con la perspectiva. Esta
plantilla pone su atencin en los factores que son importantes
dentro del propio proceso o producto evaluado.

Una tercera plantilla implica el entorno. Este es el contexto dentro
del cual el mtodo OPM se aplica e implica el examen del personal,
la propia empresa y los entornos de recursos en los que el anlisis se
est llevando a cabo.










Ejemplo de aplicacin de estos tres puntos:



Deseamos examinar el efecto de utilizar un constructor de
interfaces grficas, sobre la mejora de las interfaces hombre-
mquina, que producimos para nuestros sistemas de administracin.
En particular, deseamos examinar cmo puede esto afectar a la
facilidad de manejo de estas interfaces por parte del usuario. Un
foco de atencin principales cmo percibirn los usuarios de estos
sistemas que dichas interfaces han cambiado.


Aqu, el propsito es analizar una herramienta-con el objetivo de
determinar una mejora con respecto a la facilidad de uso, bajo el
punto de vista del usuario dentro del contexto de los sistemas
administrativos.

Los atributos de las
mtricas efectivas del
software

Ejiogu define un conjunto de
atributos que toda mtrica
efectiva del software debe
abarcar:

Simples y calculable
Consistentes y objetivas
Consistentes en el uso de
unidades y dimensiones
Independientes del
lenguaje de programacin
Mecanismos efectivos para
la retroalimentacin de
alta calidad
4T2-IS, 4TN-IS
Panorama de las mtricas del producto
Aunque se ha propuesto una amplia variedad de taxonomas mtricas, el
siguiente esquema atiende las reas ms importantes de las mtricas.

Mtricas para el modelo de anlisis: Atienden varios aspectos del modelo de
anlisis e incluyen:

Funcionalidad entregada
Tamao del sistema
Calidad de la especificacin

Mtricas para el modelo de diseo: Estas mtricas cuantifican los atributos del
diseo de manera tal que le permiten al ingeniero de software evaluar la
calidad del diseo, la mtrica incluye:
Mtricas arquitectnicas: Proporcionan un indicio de la calidad del diseo arquitectnico.
Mtricas al nivel de componente: Mide la complejidad de los componentes del software y otras
caractersticas que impactan la calidad.
Mtricas de diseo de la interfaz: Se concentra principalmente en la facilidad de uso.
Mtricas especializadas en diseo orientado a objetos: Miden caractersticas de clases,
adems de las correspondientes a comunicacin y colaboracin.
Mtricas para el cdigo fuente: Estas mtricas miden el cdigo fuente y se
usan para evaluar su complejidad, adems de la facilidad con que se
mantiene y prueba, entre otras caractersticas.
Mtricas de Halstead
Mtricas de complejidad
Mtricas de longitud

Mtricas para pruebas: Ayudan a disear casos de prueba efectivos y evaluar
la eficacia de las pruebas.

Mtricas de cobertura de instrucciones y ramas
Mtricas relacionadas con los defectos
Efectividad de la prueba
Mtricas en el proceso

En muchos modelos las mtricas de un modelo pueden aplicarse en actividades
posteriores a la ingeniera del software.
Estas mtricas atienden varios aspectos del modelo de anlisis e incluyen:
1. Funcionalidad entregada: proporciona una medida indirecta de la
funcionalidad que se empaqueta con el software.
2. Tamao del sistema: mide el tamao general del sistema, definido desde
el punto de vista de la informacin disponible como parte del modelo de
anlisis.
3. Calidad de la especificacin: proporciona una indicacin de la especifidad
o el grado en que se ha completado la especificacin de los requisitos.
En esta fase es deseable que las mtricas tcnicas proporcionen una visin
interna a la calidad del modelo de anlisis. Estas mtricas examinan el
modelo de anlisis con la intencin de predecir el tamao del sistema
resultante; el tamao es en ocasiones un indicador de la complejidad del
diseo y casi siempre resulta un indicador de un mayor esfuerzo de
codificacin, integracin y prueba.
La mtrica de punto de funcin (PF), propuesta inicialmente por Albretch
[ALB79], se usa de manera efectiva como medio para medir la funcionalidad
que entrega un sistema.
El PF se
utiliza
para
Estimar el costo o el
esfuerzo requerido
para disear, codificar
y probar el software
Predecir el numero
de errores que se
encontraran
durante la prueba
Pronosticar el
numero de
componentes, de
lneas de cdigos
proyectadas, o
ambas en el sistema
implementado
La mtrica del punto de funcin (PF) se puede utilizar como medio para
predecir el tamao de un sistema obtenido a partir de un modelo de anlisis.
Para visualizar esta mtrica se utiliza un diagrama de flujo de datos, el cual
se evaluar para determinar las siguientes medidas clave que son necesarias
para el clculo de la mtrica de punto de funcin:
1. Nmero de entradas del usuario o externas (EE): cada entrada se origina
en un usuario o es transmitida desde otra aplicacin y proporciona
distintos datos a la aplicacin o informacin de control. Las entradas
deben distinguirse de las consultas.

2. Numero de salidas del usuario o externas (SE): proporciona informacin
al usuario. Alude a informes, pantallas, mensajes de error, etc. Los
elementos de datos individuales dentro de un informe no se cuentan por
separado.
3. Numero de consultas del usuario o externas (CE): se define como la entrada
en lnea que lleva a la generacin de respuesta inmediata por parte del
software.

4. Numero de archivos lgicos internos (ALI): es un agrupamiento lgicos de
datos que reside dentro de los limites de las aplicaciones que se mantienen
mediante entradas externas.

5. Numero de archivos de interfaz externa (AIE): es un agrupamiento lgico de
datos externos a la aplicacin pero que proporciona datos que podran usarse.


Una vez que se han recolectado los datos se completa una tabla y se asocia un
valor de complejidad con cada conteo. Las organizaciones que usan mtodos de
punto de funcin desarrollan criterios para determinar si una entrada es
simple, promedio o compleja. No obstante, la determinacin de la complejidad
es un poco subjetiva.
Para calcular el punto de funcin se utiliza la siguiente relacin:

Donde:
Conteo total: es la suma de todas las entradas de PF
Fi de rango de (i= 1 a 14): son factores de ajuste de valor
basados en las respuestas a las siguientes preguntas.
1. El sistema requiere respaldo y recuperacin confiable?
2. Se requieren comunicaciones de datos especializadas para transferir
informacin a la aplicacin, u obtenerlas de ella?
3. Hay funciones distribuidas de procesamiento?
4. El desempeo es critico?
5. El sistema requiere entrada de datos en lnea?
6. Los archivos lgicos internos (ALI) se utilizan en lnea?
7. Es complejo el procesamiento interno?
8. El cdigo diseado ser reutilizable?
9. Esta diseado el sistema para instalaciones mltiples en diferentes
organizaciones?
Cada una de estas preguntas se responde empleando una escala que
va de 0 a 5
Donde: 0 (no importante o aplicable)
5 (absolutamente esencial)
Los valores constantes de la informacin se determina
empricamente.
Para ilustrar el empleo de la mtrica de PF se ideo la representacin
simple del modelo de anlisis en la siguiente figura
Se representa un diagrama de flujo de datos dentro de un software llamado
HogarSeguro. Su funcin es la de manejar la interaccin con el usuario, donde
este permite o acepta una contrasea del usuario para activar o desactivar el
sistema, tambin permite realizar consultas sobre el estado de las zonas d
seguridad. La funcin de este sistema despliega una serie de mensaje y enva
seales de control apropiadas a varios componentes del sistema de seguridad.
En la figura se muestra tres entradas externas (Contrasea, botn de pnico y
activar/desactivar) junto con 2 consultas externas (consulta de zona y
consulta de sensor). Se muestra un ALI (archivo de configuracin del sistema),
tambin estn presentes 2 salidas de usuario (mensaje y estatus del sensor) y
4 AIE (sensor de prueba, configuracin de zona, activar/desactivar y alerta de
alarma).
El conteo total debe ajustarse empleando la ecuacin:
PF= conteo total* [0.65 + 0.01 * (Fi)]
Donde:
El conteo total: es la suma de todas la entradas de PF= 50
Fi (i= 1 a 14): son factores de ajuste de valor, para los objetivos de este
ejemplo supngase que Fi = 46 (un producto moderadamente complejo).
Entonces:
PF= 50 * [0.65 + (0.01* 46)]= 56
Con base en el valor proyectado del PF derivado del modelo de
anlisis, el equipo del proyecto puede estimar el tamao
implementado general de la funcin de interaccin del usuario de
HogarSeguro.

Mtricas para la calidad de la especificacin
Davis y sus colegas proponen una lista de caractersticas con las
cuales pueden evaluarse la calidad del modelo de anlisis y la
correspondiente especificacin de requisitos:
Especificidad: (falta de ambigedad), grado de avance,
correccin, facilidad de comprensin, facilidad de verificacin,
consistencia interna y externa, facilidad para alcanzar los
objetivos, concisin, facilidad para darle seguimiento, facilidad
para modificarse, precisin y facilidad de reutilizacin.

Los autores observan que las especificaciones de alta calidad deben
estar almacenadas electrnicamente, ser ejecutable o por lo menos
interpretables , ser estable, estar organizadas, incluir referencia
cruzadas y especificarse con el grado de detalle correcto.
Muchas de estas caractersticas tienen una naturaleza cualitativa, Davis
sugiere que cada una puede representarse empleando una o mas mtricas.

Por ejemplo:
Supngase que hay nf requisitos en una especificacion de modo que;
nf = nf + nnf

Donde:
nf: es el numero de requisitos funcionales
nnf: es el numero de requisitos no funcionales (como el desempeo).

Para determinar la especificacion (falta de ambigedad) de los requisitos,
Davis sugiere una mtrica basada en la consistencia de la interpretacin de los
revisores de cada requisito:

Q1 = nui/nf
Donde:
nui : es el numero de requisitos que todos los revisores interpretaron de la
misma manera. (Cuando mas cercano este el valor de Q a 1, menor ser la
ambigedad de la especificacion)

El grado de avance de los requisitos funcionales se determina al calcular
la relacin

Q2 = nu/[ni * ns]

Donde:
nu: es el numero de requisitos de funcin nica.
ni: es el numero de entradas (estmulos) definidos o implcitos en la
especificacion
ns: es el numero de estados especificados.
La relacin Q2 mide el porcentaje de funciones necesarias que se han
especificado para un sistema.
Si embargo, no se atienden requisitos que no son funcionales para
incorporarlos a una mtrica general del grado de avance, se debe
considerar el grado de validacin de los requisitos:

Q3 = nc/[nc + nnv]

Donde:
nc: es el numero de requisito que se han validado como correctos.
nnv: numero de requisito que aun no se validan


METRICAS PARA EL MODELO DE DISEO
Las mtricas de diseo para el software de
computadora, como todas las dems mtricas
no son perfectas.

Estas mtricas se usan para definir medidas de
diseo, aspectos de calidad. La irona de esto
es que la gran mayora de desarrolladores han
ignorando la existencia de estas mtricas
METRICAS DE DISEO ARQIOTECTPMOCO
Se concentran en las caractersticas de la
arquitectura del programa. Estas mtricas son
de caja negra en el sentido que no requieren
ningn conocimiento del funcionamiento
interno de un componente de software en
particular.
Se definen 3 tipos de complejidad del diseo de
software: estructural, de datos y de sistema

En el caso de la arquitectura jerrquicas (por
ejemplo las arquitectura de llamadas y
retorno), la complejidad estructural de un
modulo i se define de la siguiente manera:
S(i)= f out(i)
Donde fout(i) es la dependencia hacia afuera del
modulo i.

Describe 9 caractersticas distintivas y
mensurables en un diseo orientado a objetos.
1. Tamao: se define a partir de cuatro
conceptos poblacin, volumen longitud y
funcionalidades.
2. Complejidad Whitmire considera la
complejidad desde el punto de vista
estructural.


Mtricas para el diseo orientado a
objetos
Mtricas orientadas a clases: la
coleccin de mtricas ck
Mtricas para el cdigo fuente
Las mtricas de cdigo son un conjunto de medidas de
software que proporcionan a los programadores una mejor
visin del cdigo que estn desarrollando. Al aprovechar
las mtricas de cdigo, los programadores pueden
entender qu tipos y mtodos se deben rehacer o probar
ms a fondo. Los equipos de desarrollo pueden identificar
los riesgos potenciales, entender el estado actual de un
proyecto y seguir el progreso durante el desarrollo del
software.
Mtricas para el cdigo fuente
Miden el cdigo fuente y se utilizan para medir la
complejidad a dems con la facilidad con a que se
mantiene y prueba:

1. Mtricas de Halstead
2. Mtricas de Complejidad
1. Mtricas de Halstead
Durante el final de los aos 70 y principios de los 80, Maurice
Halstead desarrolla un conjunto de mtricas llamadas Halstead
Software Science, mtricas basadas en el clculo de palabras clave
(reservadas) y variables.

Su teora est basada en un simple cuenta (muy fcil de
automatizar) de operadores y operandos en un programa:
Los operadores son las palabras reservadas del lenguaje, tales
como IF-THEN, READ, FOR,...; los operadores aritmticos +, -,
*,..... los de asignacin y los operadores lgicos AND, EQUAL
TO,....
Los operandos son las variables, literales y las constantes del
programa.

Halstead distingue entre el nmero de operadores y
operandos nicos y el nmero total de operadores y
operando. Por ejemplo, un programa puede tener un READ,
siete asignaciones y un WRITE; por lo tanto tiene tres nicos
operadores, pero nueve en total operadores, y de manera
idntica se procede con los operandos. Se utiliza la
siguiente notacin:

n1 - nmero de operadores nicos que aparecen en un
programa.
N1 - nmero total de ocurrencias de operadores.
n2 - nmero de operandos nicos que aparecen en un
programa.
N2 - nmero total de ocurrencias de operandos.
1. Mtricas de Halstead (Continuacin)
Las mtricas de la Ciencia del Software para cualquier programa escrito en
cualquier lenguaje pueden ser derivadas de estas cuatro cuentas. A partir
de ellas han sido elaboradas diferentes medidas para diversas propiedades
de los programas, tales como longitud, volumen, etc...
Por ejemplo, consideremos el siguiente trozo de programa:

IF (N<2) THEN
BEGIN
A=B*N;
WRITE (A)
END

A partir de aqu se deduce:
N2 = 6 (N, 2, A, B, N, A)
N1 = 6 (IF-THEN, BEGIN-END, WRITE, =, *, <)
n2 = 4 (N, A, B, 2)
n1 = 6 (IF-THEN, BEGIN-END, WRITE, =, *, <)
1. Mtricas de Halstead (Continuacin)
Halstead permite obtener una medida de la longitud, N, de un
programa, que es calculada como:

N = N1 + N2

N es una simple medida del tamao de un programa. Cuanto
ms grande sea el tamao de N, mayor ser la dificultad para
comprender el programa y mayor el esfuerzo para
mantenerlo. N es una medida alternativa al simple conteo de
lneas de cdigo. Aunque es casi igual de fcil de calcular, N
es ms sensible a la complejidad que el contar el nmero de
lneas porque N no asume que todas las instrucciones son igual
de fcil o de difcil de entender.

1. Mtricas de Halstead (Continuacin)
1. Mtricas de Halstead (Continuacin)
La medida de longitud, N, es usada en otra
estimacin de tamao de Halstead llamada
volumen. Mientras que la longitud es una simple
cuenta (o estimacin) del total de operadores y
operandos, el volumen da un peso extra al nmero
de operadores y operandos nicos. Por ejemplo, si
dos programas tienen la misma longitud N pero uno
tiene mayor nmero de operadores y operandos
nicos, que naturalmente lo hacen ms difcil de
entender y mantener, este tendr un mayor
volumen. La frmula es la siguiente:

volumen V = N x log2(n)
donde n = n1 + n2.
1. Mtricas de Halstead (Continuacin)
El esfuerzo es otra medida estudiada por Halstead que ofrece una medida del
trabajo requerido para desarrollar un programa. Desde el punto de vista del
mantenimiento, el esfuerzo se puede interpretar como una medida del trabajo
requerido para comprender un software ya desarrollado.
La frmula es la siguiente:

esfuerzo E = V / L

donde el volumen V es dividido por el nivel del lenguaje L. ste indica si se est
utilizando un lenguaje de alto o bajo nivel. Por ejemplo, una simple llamada a un
procedimiento podra tener un valor L de 1; el COBOL podra tener 0,1 y el
ensamblador podra tener un L de 0,01. As pues el esfuerzo aumenta
proporcionalmente con el volumen, pero decrece con la utilizacin de lenguajes
de alto nivel.
Atendiendo a varios estudios empricos, el esfuerzo, E, es incluso una medida
mejor de la entendibilidad (comprensin) que N.


* El leguaje COBOL (acrnimo de COmmon Business-Oriented Language, Lenguaje
Comn Orientado a Negocios) fue creado en el ao 1959 con el objetivo de crear
un lenguaje de programacin universal que pudiera ser usado en cualquier
ordenador.
Ejemplo:

{
for
(i=2;i<=n;i++)
for
(j=1;j<=i;j++)
if (x[i] < x[j])

}
aux = x[i];
x[i] = x[j];
x[j] = aux;

}
}
1. Mtricas de Halstead (Continuacin)
Operadores

{..} 2
for(;;) 2
= 5
if 1
; 3
(..) 1
< 1
< = 2
++ 2
[ ] 4

n1=10
N1=23
Operandos

i 7
n 1
j 6
x 6
aux 2

n2=5
N2=22
N = N1 + N2 N=23+22=45
V = N x log2 (n) V=45 x log2(15)=175.8
2. Complejidad Ciclomtica
La complejidad Ciclomtica se basa en el recuento del nmero de
caminos lgicos individuales contenidos en un programa. Para calcular
la complejidad del software, Thomas McCabe utiliz la teora y flujo de
grafos. Para hallar la complejidad Ciclomtica, el programa se
representa como un grafo, y cada instruccin que contiene, un nodo del
grafo. Las posibles vas de ejecucin a partir de una instruccin (nodo)
se representan en el grafo como aristas. Por ejemplo, el cdigo que se
muestra a continuacin con 2 sentencias selectivas anidadas genera el
siguiente grafo:
2. Complejidad Ciclomtica (Continuacin)
Si se realizase el grafo, se observara que se encuentran 3 caminos posibles
para llegar de la sentencia 1 a la sentencia 6:
Camino 1 (si ambos IFs son verdad): Sentencias 1, 2, 3, 6
Camino 2 (si el primer IF es verdad y el segundo es falso): Sentencias 1, 4,6
Camino 3 (si el primer IF es falso): Sentencias 1, 6
Este programa tiene una complejidad Ciclomtica de 3.
La complejidad Ciclomtica se puede calcular de otras maneras. Se puede
utilizar la frmula:

v(G) = e - n + 2

donde e representa el nmero de aristas y n el nmero de nodos.
Otra forma de calcular la complejidad Ciclomtica consiste en aplicar la
siguiente frmula:

v(G) = nmero de regiones cerradas en el grafo + 1


2. Complejidad Ciclomtica (Continuacin)
Ejemplo:


2. Complejidad Ciclomtica (Continuacin)