\appendix

\chapter{Métricas de código}
\label{apendiceA}


\subsection*{Complejidad Ciclomática de \emph{McCabe}}
\label{apendiceA:mccabe}

[Fuente: Wikipedia\footnote{http://es.wikipedia.org/wiki/Complejidad\_ciclomatica}]

La Complejidad Ciclomática (en inglés, \emph{Cyclomatic Complexity}) es una
métrica del software que proporciona una medición cuantitativa de la
complejidad lógica de un programa. Es una de las métricas de software
de mayor aceptación, ya que ha sido concebida para ser independiente
del lenguaje.

Esta métrica, propuesta por \emph{Thomas McCabe} en 1976, se basa en
el diagrama de flujo determinado por las estructuras de control de un
determinado código. De dicho análisis se puede obtener una medida
cuantitativa de la dificultad de crear pruebas automáticas del código
y también es una medición orientativa de la fiabilidad del mismo. El
nombre “Complejidad Ciclomática” puede resultar engañoso para un
programador ya que la idea de esta métrica no es contar los bucles en
el código de un programa sino en el resultado de contar el número de
ciclos diferentes que se siguen en un fragmento de código de un
programa habiendo creado una rama imaginaria desde el nodo de salida
al nodo de entrada del diagrama de flujo correspondiente a este
fragmento de código. Un nombre más adecuado podría ser Complejidad
condicional ya que el cálculo de esta métrica se ajusta más al hecho
de buscar condiciones que contar ejecuciones de predicados dentro de
bucles.

El resultado obtenido en el cálculo de la complejidad ciclomática
define el \textbf{número de caminos independientes dentro de un fragmento
  de código} y determina la cota superior del número de pruebas que se
deben realizar para asegurar que se ejecuta cada sentencia al menos
una vez. La medida resultante puede ser utilizada en el desarrollo,
mantenimiento y reingeniería para estimar el riesgo, costo y
estabilidad. Algunos estudios experimentales indican la existencia de
distintas relaciones entre la métrica de McCabe y el número de errores
existentes en el código fuente, así como el tiempo requerido para
encontrar y corregir esos errores.

Una vez calculada la complejidad ciclomática de un fragmento de
código, se puede determinar el riesgo que supone utilizando los rangos
definidos en la tabla \ref{tabla:rangos}.

\begin{table}[htbp]
\begin{center}
\footnotesize
\begin{tabular}{||l|p{9cm}||}
\hline
\hline
\bf{Complejidad Ciclomática} & \bf{Evaluación del Riesgo}  \\
\hline
1-10 &  Programa Simple, sin mucho riesgo \\
\hline
11-20 & Más complejo, riesgo moderado \\
\hline
21-50 & Complejo, programa de alto riesgo  \\
\hline
50 & Programa difícilmente testeable, muy alto riesgo \\
\hline
\hline
\end{tabular}
\end{center}
\normalsize
\caption{Rangos de la complejidad ciclomática.}
\label{tabla:rangos}
\end{table}



\subsection*{Modelo Constructivo de Costes \emph{COCOMO}}
\label{apendiceA:cocomo}

[Fuente: Wikipedia\footnote{http://es.wikipedia.org/wiki/COCOMO}]

El Modelo Constructivo de Costes (o \emph{COCOMO}, por su acrónimo del
inglés \emph{COnstructive COst MOdel}) es un modelo matemático de base
empírica utilizado para estimación de costes de software. Incluye
tres submodelos, cada uno ofrece un nivel de detalle y aproximación,
cada vez mayor, a medida que avanza el proceso de desarrollo del
software: básico, intermedio y detallado. Este modelo fue desarrollado
por \emph{Barry W. Boehm} a finales de los años 70 y comienzos de los
80, exponiéndolo detalladamente en su libro \emph{Software Engineering
  Economics} (Prentice-Hall, 1981).

Pertenece a la categoría de modelos de sub-estimaciones basados en
estimaciones matemáticas. Está orientado a la magnitud del producto
final, midiendo el ``tamaño'' del proyecto, en líneas de código
principalmente. Algunas de sus características:

\begin{itemize}
\item Los resultados no son proporcionales a las tareas de gestión ya que no
tiene en cuenta los recursos necesarios para realizarlas.
\item Se puede desviar de la realidad si se indica mal el porcentaje de
líneas de comentarios en el código fuente.
\item Es un tanto subjetivo, puesto que está basado en estimaciones y
parámetros que pueden ser ``vistos'' de distinta manera por distintos
analistas que usen el método.
\item Se miden los costes del producto, de acuerdo a su tamaño y otras
características, pero no la productividad.
\item La medición por líneas de código no es válida para orientación a
objetos.
\item Utilizar este modelo puede resultar un poco complicado, en
  comparación con otros métodos (que también sólo estiman).
\end{itemize}