METRICAS DEL PRODUCTO PARA

EL SOFTWARE

Docente: MSc. Claudia Benavidez Rugama

 INTRODUCCION

 La medición es un elemento clave en

cualquier proceso de ingeniería. Las
medidas se emplean para comprender
mejor los atributos de los modelos que se
crean y evaluar la calidad de los
productos de la ingeniería o de los
sistemas que se construyen.
 INTRODUCCION
 Aunque las métricas del producto para el
software de computadora no pueden ser
absolutas, proporcionan una manera
sistemática de evaluar la calidad a partir de un
conjunto de reglas definidas con claridad.
También proporcionan al ingeniero de software
información 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
catastróficos.
Tipos de Métricas
UN MARCO CONCEPTUAL PARA LAS MÉTRICAS DEL PRODUCTO

 Medidas, métricas e indicadores

Aunque estos tres términos pueden utilizarse de manera intercambiable, es
necesario especificar las diferencias entre éstos.

 Medida: Proporciona indicación cuantitativa de la extensión, la cantidad, la

dimensión, la capacidad o el tamaño de algún atributo de un producto o
proceso.

Algunos ejemplos son los siguientes:

1. Líneas de código (LDC).
2. Esfuerzo en hombre-mes.
3. Costo en pesos o dólares.
4. Número de páginas de documentación.
5. Número de errores. Fallas detectadas antes de entregar el software al
cliente.
6. Número de defectos. Fallas detectadas después de entregar el software al
cliente.
7. Número de personas en el proyecto.

 Medición: Acto de determinar una medida.

 Métrica: Medida cuantitativa del grado en que un sistema, componente o
proceso posee un atributo determinado.
Ejemplo:
1. Errores por KLDC (mil líneas de código).
2. Defectos por KLDC.
3. Costo por KLDC.
4. Páginas de documentación por KLDC.
5. Errores por hombre-mes.
6. LDC por hombre-mes.
7. Costo por página de documentación.

 Indicador: Métrica o combinación de métricas 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 organización de software mantiene registros sencillos, se
puede crear una tabla de datos orientados al tamaño como se muestra en la
siguiente figura:
Proyecto Esfuerzo $ KLDC Pag.Doc Errores Gente La tabla lista cada proyecto del
desarrollo del software de los
999-01 24 168 12.1 365 29 3
últimos años correspondientes,
CCC-04 62 440 27.2 1124 86 5 datos orientados al tamaño de c/u.
FFF-03 43 314 20.2 1050 64 6

 Refiriéndonos a la entrada de la tabla del proyecto 999-01 se desarrollaron 12.1KLDC

(miles de líneas de código) con un esfuerzo de 24 personas mes y un costo de168 mil
dólares.

 Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las
actividades de la ingeniería de software como son análisis, diseño, codificación y prueba.

 Otra información del proyecto 999-01 indica que se desarrollaron 365 páginas mientras
que se encontraron 29 errores tras entregárselo al cliente, dentro del primer año de
utilización también 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 métricas
sencillas de productividad y calidad orientadas al tamaño.

Se obtienen las siguientes formulas:

Donde la fórmula del esfuerzo de Bassili es:

1.16
E=5.5 + 0.73 ∗ KLOC
El reto de las métricas 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 medición 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 Métricas.

Permiten obtener una comprensión cuantitativa del proceso, así como
evaluar un producto o controlarlo; además permiten producir un
estimado y mejorar la calidad del software.
Principios de medición:

Roche sugiere un proceso de medición al que caracterizan cinco

actividades:
La derivación de medidas y métricas
apropiadas para la representación del
Formulación. software que se considere.

Mecanismo con que se acumulan

los datos necesarios para derivar Recolección
las métricas formuladas.
Cálculo de las métricas y la
aplicación de herramientas
Análisis. matemáticas.

Evaluación de las métricas en un

esfuerzo por conocer mejor la
calidad de la representación. Interpretación.

Retroalimentación Recomendaciones derivadas de la

interpretación de las métricas del
producto transmitidas al equipo del
software.
Principios de medición:
Existen principios que son representativos de muchos otros
que podrían proponerse para caracterizar y validar las
métricas:

• Una métrica debe tener propiedades matemáticas

deseables.
• Cuando una métrica representa una característica de
software que aumenta cuando se presentan rasgos
positivos o que disminuye al encontrar rasgos
indeseables, el valor de la métrica debe aumentar o
disminuir en el mismo sentido.
• Cada métrica debe validarse empíricamente en una
amplia variedad de contextos antes de publicarse o
aplicarse a la toma de decisiones.
Método Medición

Identificar los atributos

de las entidades del dominio

Identificar relaciones
empíricas para los
atributos

Verificar que la
semántica de las
Identificar relaciones relaciones empíricas se
numéricas correspondientes
preserva en las
relaciones numéricas
a cada relación empírica

Definir el mapping entre

las
entidades y los números
Medición del Software Orientado a Objetivos

Basili y Weiss desarrollaron el paradigma

objetivo/pregunta/métrica (OPM) como una técnica para
identificar métricas significativas aplicables en cualquier parte
del proceso del software. El OPM destaca la necesidad de:

1. Establecer un objetivo de medición explicito que sea

especifico para la actividad del proceso o las características
del producto que se está evaluando.
2. Definir un conjunto de preguntas que deben responderse con
el fin de alcanzar el objetivo.
3. Identificar métricas 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 métricas
realistas sobre sus proyectos. Cada una de sus plantillas se explica a
continuación:

La plantilla o esquema de cálculo denominada de propósito. Se

utiliza para articular o comparar lo que está siendo analizado.

Una segunda plantilla está relacionada con la perspectiva. Esta

plantilla pone su atención 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 método OPM se aplica e implica el examen del personal,
la propia empresa y los entornos de recursos en los que el análisis se
está llevando a cabo.
Ejemplo de aplicación de estos tres puntos:

Deseamos examinar el efecto de utilizar un constructor de

interfaces gráficas, sobre la mejora de las interfaces hombre-
máquina, que producimos para nuestros sistemas de administración.
En particular, deseamos examinar cómo puede esto afectar a la
facilidad de manejo de estas interfaces por parte del usuario. Un
foco de atención principales cómo percibirán los usuarios de estos
sistemas que dichas interfaces han cambiado.

Aquí, el propósito 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.
 4T2-IS, 4TN-IS

Los atributos de las

métricas efectivas del
software

Ejiogu define un conjunto de

atributos que toda métrica
efectiva del software debe
abarcar:

 Simples y calculable
 Consistentes y objetivas
 Consistentes en el uso de
unidades y dimensiones
 Independientes del
lenguaje de programación
 Mecanismos efectivos para
la retroalimentación de
alta calidad
Panorama de las métricas del producto
Aunque se ha propuesto una amplia variedad de taxonomías métricas, el
siguiente esquema atiende las áreas más importantes de las métricas.

Métricas para el modelo de análisis: Atienden varios aspectos del modelo de

análisis e incluyen:

• Funcionalidad entregada
• Tamaño del sistema
• Calidad de la especificación

Métricas para el modelo de diseño: Estas métricas cuantifican los atributos del
diseño de manera tal que le permiten al ingeniero de software evaluar la
calidad del diseño, la métrica incluye:
• Métricas arquitectónicas: Proporcionan un indicio de la calidad del diseño arquitectónico.
• Métricas al nivel de componente: Mide la complejidad de los componentes del software y otras
características que impactan la calidad.
• Métricas de diseño de la interfaz: Se concentra principalmente en la facilidad de uso.
• Métricas especializadas en diseño orientado a objetos: Miden características de clases,
además de las correspondientes a comunicación y colaboración.
Métricas para el código fuente: Estas métricas miden el código fuente y se
usan para evaluar su complejidad, además de la facilidad con que se
mantiene y prueba, entre otras características.

• Métricas de Halstead
• Métricas de complejidad
• Métricas de longitud

Métricas para pruebas: Ayudan a diseñar casos de prueba efectivos y evaluar

la eficacia de las pruebas.

• Métricas de cobertura de instrucciones y ramas

• Métricas relacionadas con los defectos
• Efectividad de la prueba
• Métricas en el proceso

En muchos modelos las métricas de un modelo pueden aplicarse en actividades

posteriores a la ingeniería del software.
 En esta fase es deseable que las métricas técnicas proporcionen una visión
interna a la calidad del modelo de análisis. Estas métricas examinan el
modelo de análisis con la intención de predecir el «tamaño» del sistema
resultante; el tamaño es en ocasiones un indicador de la complejidad del
diseño y casi siempre resulta un indicador de un mayor esfuerzo de
codificación, integración y prueba.

Estas métricas atienden varios aspectos del modelo de análisis e incluyen:

1. Funcionalidad entregada: proporciona una medida indirecta de la

funcionalidad que se empaqueta con el software.
2. Tamaño del sistema: mide el tamaño general del sistema, definido desde
el punto de vista de la información disponible como parte del modelo de
análisis.
3. Calidad de la especificación: proporciona una indicación de la especifidad
o el grado en que se ha completado la especificación de los requisitos.
La métrica de punto de función (PF), propuesta inicialmente por Albretch
[ALB79], se usa de manera efectiva como medio para medir la funcionalidad
que entrega un sistema.

Predecir el numero
de errores que se
encontrarían
durante la prueba
Pronosticar el
numero de
Estimar el costo o el
componentes, de
esfuerzo requerido
líneas de códigos
para diseñar, codificar
proyectadas, o
y probar el software
ambas en el sistema
implementado

El PF se
utiliza
para
 La métrica del punto de función (PF) se puede utilizar como medio para
predecir el tamaño de un sistema obtenido a partir de un modelo de análisis.
Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual
se evaluar para determinar las siguientes medidas clave que son necesarias
para el cálculo de la métrica de punto de función:

1. Número de entradas del usuario o externas (EE): cada entrada se origina

en un usuario o es transmitida desde otra aplicación y proporciona
distintos datos a la aplicación o información de control. Las entradas
deben distinguirse de las consultas.

2. Numero de salidas del usuario o externas (SE): proporciona información

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 línea que lleva a la generación de respuesta inmediata por parte del
software.

4. Numero de archivos lógicos internos (ALI): es un agrupamiento lógicos 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 lógico de

datos externos a la aplicación pero que proporciona datos que podrían 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 métodos de
punto de función desarrollan criterios para determinar si una entrada es
simple, promedio o compleja. No obstante, la determinación de la complejidad
es un poco subjetiva.
Para calcular el punto de función se utiliza la siguiente relación:

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 recuperación confiable?
2. ¿Se requieren comunicaciones de datos especializadas para transferir
información a la aplicación, u obtenerlas de ella?
3. ¿Hay funciones distribuidas de procesamiento?
4. ¿El desempeño es critico?
5. ¿El sistema requiere entrada de datos en línea?
6. ¿Los archivos lógicos internos (ALI) se utilizan en línea?
7. ¿Es complejo el procesamiento interno?
8. ¿El código diseñado será reutilizable?
9. ¿Esta diseñado el sistema para instalaciones múltiples 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 información se determina
empíricamente.
 Para ilustrar el empleo de la métrica de PF se ideo la representación
simple del modelo de análisis en la siguiente figura

Se representa un diagrama de flujo de datos dentro de un software llamado

HogarSeguro. Su función es la de manejar la interacción con el usuario, donde
este permite o acepta una contraseña del usuario para activar o desactivar el
sistema, también permite realizar consultas sobre el estado de las zonas d
seguridad. La función de este sistema despliega una serie de mensaje y envía
señales de control apropiadas a varios componentes del sistema de seguridad.
En la figura se muestra tres entradas externas (Contraseña, botón de pánico y
activar/desactivar) junto con 2 consultas externas (consulta de zona y
consulta de sensor). Se muestra un ALI (archivo de configuración del sistema),
también están presentes 2 salidas de usuario (mensaje y estatus del sensor) y
4 AIE (sensor de prueba, configuración de zona, activar/desactivar y alerta de
alarma).
 El conteo total debe ajustarse empleando la ecuación:
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 supóngase 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
análisis, el equipo del proyecto puede estimar el tamaño
implementado general de la función de interacción del usuario de
HogarSeguro.

Métricas para la calidad de la especificación

Davis y sus colegas proponen una lista de características con las
cuales pueden evaluarse la calidad del modelo de análisis y la
correspondiente especificación de requisitos:

Especificidad: (falta de ambigüedad), grado de avance,

corrección, facilidad de comprensión, facilidad de verificación,
consistencia interna y externa, facilidad para alcanzar los
objetivos, concisión, facilidad para darle seguimiento, facilidad
para modificarse, precisión y facilidad de reutilización.

Los autores observan que las especificaciones de alta calidad deben

estar almacenadas electrónicamente, 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 características tienen una naturaleza cualitativa, Davis
sugiere que cada una puede representarse empleando una o mas métricas.

Por ejemplo:
Supóngase 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 desempeño).

Para determinar la especificacion (falta de ambigüedad) de los requisitos,

Davis sugiere una métrica basada en la consistencia de la interpretación 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
ambigüedad de la especificacion)
El grado de avance de los requisitos funcionales se determina al calcular
la relación

• Q2 = nu/[ni * ns]

Donde:
nu: es el numero de requisitos de función única.
ni: es el numero de entradas (estímulos) definidos o implícitos en la
especificacion
ns: es el numero de estados especificados.
La relación 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 métrica general del grado de avance, se debe
considerar el grado de validación 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 DISEÑO

 Las métricas de diseño para el software de

computadora, como todas las demás métricas
no son perfectas.

 Estas métricas se usan para definir medidas de

diseño, aspectos de calidad. La ironía de esto
es que la gran mayoría de desarrolladores han
ignorando la existencia de estas métricas
METRICAS DE DISEÑO ARQIOTECTPMOCO

 Se concentran en las características de la

arquitectura del programa. Estas métricas son
de caja negra en el sentido que no requieren
ningún conocimiento del funcionamiento
interno de un componente de software en
particular.
 Se definen 3 tipos de complejidad del diseño de
software: estructural, de datos y de sistema

En el caso de la arquitectura jerárquicas (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.
Métricas para el diseño orientado a
objetos
 Describe 9 características distintivas y
mensurables en un diseño orientado a objetos.
1. Tamaño: se define a partir de cuatro
conceptos población, volumen longitud y
funcionalidades.
2. Complejidad Whitmire considera la
complejidad desde el punto de vista
estructural.
Métricas orientadas a clases: la
colección de métricas ck
 Métricas para el código fuente

Las métricas de código son un conjunto de medidas de

software que proporcionan a los programadores una mejor
visión del código que están desarrollando. Al aprovechar
las métricas de código, los programadores pueden
entender qué tipos y métodos se deben rehacer o probar
más 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.
Métricas para el código fuente

Miden el código fuente y se utilizan para medir la

complejidad a demás con la facilidad con a que se
mantiene y prueba:

1. Métricas de Halstead
2. Métricas de Complejidad
 1. Métricas de Halstead

Durante el final de los años 70 y principios de los 80, Maurice

Halstead desarrolla un conjunto de métricas llamadas Halstead
Software Science, métricas basadas en el cálculo de palabras clave
(reservadas) y variables.

• Su teoría está basada en un simple cuenta (muy fácil 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 aritméticos +, -,
*,..... los de asignación y los operadores lógicos AND, EQUAL
TO,....
• Los operandos son las variables, literales y las constantes del
programa.
 1. Métricas de Halstead (Continuación)
Halstead distingue entre el número de operadores y
operandos únicos y el número 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
idéntica se procede con los operandos. Se utiliza la
siguiente notación:

n1 - número de operadores únicos que aparecen en un

programa.
N1 - número total de ocurrencias de operadores.
n2 - número de operandos únicos que aparecen en un
programa.
N2 - número total de ocurrencias de operandos.
 1. Métricas de Halstead (Continuación)
Las métricas 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. Métricas de Halstead (Continuación)
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 tamaño de un programa. Cuanto

más grande sea el tamaño 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
líneas de código. Aunque es casi igual de fácil de calcular, N
es más sensible a la complejidad que el contar el número de
líneas porque N no asume que todas las instrucciones son igual
de fácil o de difícil de entender.
1. Métricas de Halstead (Continuación)
La medida de longitud, N, es usada en otra
estimación de tamaño de Halstead llamada
volumen. Mientras que la longitud es una simple
cuenta (o estimación) del total de operadores y
operandos, el volumen da un peso extra al número
de operadores y operandos únicos. Por ejemplo, si
dos programas tienen la misma longitud N pero uno
tiene mayor número de operadores y operandos
únicos, que naturalmente lo hacen más difícil de
entender y mantener, este tendrá un mayor
volumen. La fórmula es la siguiente:

volumen V = N x log2(n)
donde n = n1 + n2.
 1. Métricas de Halstead (Continuación)
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 fórmula 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 podría tener un valor L de 1; el COBOL podría tener 0,1 y el
ensamblador podría tener un L de 0,01. Así pues el esfuerzo aumenta
proporcionalmente con el volumen, pero decrece con la utilización de lenguajes
de alto nivel.
Atendiendo a varios estudios empíricos, el esfuerzo, E, es incluso una medida
mejor de la entendibilidad (comprensión) que N.

* El leguaje COBOL (acrónimo de COmmon Business-Oriented Language, Lenguaje

Común Orientado a Negocios) fue creado en el año 1959 con el objetivo de crear
un lenguaje de programación universal que pudiera ser usado en cualquier
ordenador.
 1. Métricas de Halstead (Continuación)

Ejemplo: Operadores Operandos

{ {..} 2 i 7
for for(;;) 2 n 1
= 5 j 6
(i=2;i<=n;i++)
if 1 x 6
for ; 3 aux 2
(j=1;j<=i;j++) (..) 1
if (x[i] < x[j]) < 1 n2=5
<= 2 N2=22
} ++ 2
aux = x[i]; [] 4
x[i] = x[j];
n1=10
x[j] = aux;
N1=23

}
}
N = N1 + N2 N=23+22=45
V = N x log2 (n) V=45 x log2(15)=175.8
 2. Complejidad Ciclomática

La complejidad Ciclomática se basa en el recuento del número de

caminos lógicos individuales contenidos en un programa. Para calcular
la complejidad del software, Thomas McCabe utilizó la teoría y flujo de
grafos. Para hallar la complejidad Ciclomática, el programa se
representa como un grafo, y cada instrucción que contiene, un nodo del
grafo. Las posibles vías de ejecución a partir de una instrucción (nodo)
se representan en el grafo como aristas. Por ejemplo, el código que se
muestra a continuación con 2 sentencias selectivas anidadas genera el
siguiente grafo:
 2. Complejidad Ciclomática (Continuación)
Si se realizase el grafo, se observaría que se encuentran 3 caminos posibles
para llegar de la sentencia 1 a la sentencia 6:
Camino 1 (si ambos IF’s 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 Ciclomática de 3.
La complejidad Ciclomática se puede calcular de otras maneras. Se puede
utilizar la fórmula:

v(G) = e - n + 2

donde e representa el número de aristas y n el número de nodos.

Otra forma de calcular la complejidad Ciclomática consiste en aplicar la
siguiente fórmula:

v(G) = número de regiones cerradas en el grafo + 1

2. Complejidad Ciclomática (Continuación)

Ejemplo:
2. Complejidad Ciclomática (Continuación)