PDF de programación - Medidas de la complejidad del software

Medidas de la complejidad del software



1



Medidas de la complejidad del software.



Introducción.
Estudio del software desde el marco HxIxO->IO.
Las métricas como instrumentos para abordar la complejidad.
Tipos de métricas.
Métricas del tamaño del programa.

Numero de líneas.
Métricas de Halstead.

Estructura y flujo de datos.

Intervalo entre referencias a datos.
Par de uso segmento-global.
Medida Q de Chapin.

Estructuras de control del programa.

Número ciclomático.
Extensión de Myers al número ciclomático.

Medidas híbridas.

Métrica de Hansen.
Métrica de Oviedo.

Resumen.
Bibliografía.



Los programas tienen errores. Desde los pequeños programas comerciales para ordenadores
personales, que se venden en los grandes almacenes, hasta los megaprogramas que corren en redes
de grandes ordenadores, prácticamente ninguno está a salvo de que de vez en cuando, al cumplirse
ciertas condiciones, su funcionamiento sea muy distinto del previsto.

Si consiguiéramos desarrollar código de tal forma que quien lo leyera (o lo escribiera) fuera capaz
de comprender exactamente y en todos los casos posibles el comportamiento de ese código,
probablemente los errores desaparecerían.

Hoy por hoy nos contentamos con medir la complejidad de los programas, para intentar hacerlos
más sencillos, con vistas a que el mantenimiento y corrección de errores sea más fácil de realizar.


Complejidad y Tecnologías de la Información (Tecnologías de la información)

Medidas de la complejidad del software



2



G

M

T.I.


1. Introducción.



Todo el mundo que haya tenido que escribir alguna vez un programa de tamaño medio (o incluso
pequeño) estará de acuerdo en que la producción de software es algo, cuando menos, complicado.
Pero para decidir de una forma rigurosa si podemos calificarlo como "complejo", recurriremos a la
definición de Sáez Vacas (ver capítulo "Marcos Conceptuales"). Tras la revisión de esta definición,
podemos concluir que el software se ajusta a ella al menos en los siguientes aspectos:


a. "Dificultad de comprensión". Por lo pronto podemos decir sin temor a equivocarnos que el
software es normalmente algo difícil de entender. Cuando nos encontramos ante un listado,
sólo tras un cuidadoso examen podemos deducir qué es lo que hace el programa
correspondiente. Y aún así, esta deducción suele ser aproximada. Lo que verdaderamente
sucede en la ejecución sólo podemos saberlo con certeza después, precisamente, de esta
ejecución. Si el lector ha tenido que descifrar alguna vez un código escrito por otro
programador, o incluso uno suyo, pero desarrollado hace algún tiempo, comprenderá sin
duda de qué estamos hablando. La evolución de los lenguajes de programación, por
ejemplo, está fuertemente marcada por el intento de conseguir listados más legibles. Por
ejemplo Ada, el lenguaje promovido por el Departamento de Defensa de los Estados
Unidos, ha sido diseñado buscando de forma especial el facilitar la comprensión del
código. La idea es que un programador diferente del original pueda entender un listado con
relativa facilidad, y no le sea difícil hacerse una idea exacta de cómo se comportará el
programa correspondiente al ejecutarse. Así suele decirse que Ada es un lenguaje mucho
más fácil de leer que de escribir.



b. "Requiere una gran cantidad de información y tiempo, y el esfuerzo coordinado de personas
y maquinaria". En efecto, cualquier proyecto informático de mediana entidad requiere de
un equipo de profesionales (analistas, programadores, etc.) que se ocupe de definirlo,
desarrollarlo, probarlo, mantenerlo e incluso quizás, modificarlo, durante toda su vida útil.
La gestión del software es un problema hasta la fecha no resuelto en su totalidad, aunque
se han propuesto varias técnicas para afrontarlo. Por otra parte, las herramientas CASE
(ingeniería software asistida por ordenador) se están desarrollando a gran velocidad, y no
por capricho. Para manejar toda la información generada en el proceso de producción de
un programa, se hace necesario el contar con estas herramientas. Si no, el problema llega a
ser, sencillamente, inabordable. Para hacernos una idea de lo que supone el tiempo en el
proceso de desarrollo, basta recordar los repetidos retrasos que a menudo ha sufrido la
aparición de populares programas para pc. Son muy conocidos, por ejemplo, los casos del
dBase IV y de la nueva versión del Lotus 123. Y es que el tiempo de desarrollo no sólo
suele ser largo, sino que también es muy difícil de predecir.


c. "Efectos positivos y negativos simultáneos". Prácticamente todo el software que se utiliza
tiene errores, unos más evidentes y otros menos, unos más peligrosos y otros más

Complejidad y Tecnologías de la Información (Tecnologías de la información)

Medidas de la complejidad del software



3



benignos, unos conocidos y otros desconocidos (hasta que aparecen, claro, causando
normalmente algún perjuicio). Así pues, los programas de que se dispone hacen
normalmente lo que se espera de ellos, excepto en el caso de que se encuentren con un
error de programación. Los errores no son más que comportamientos no deseados del
programa bajo ciertas condiciones que, por alguna razón, pasaron desapercibidas en las
etapas de diseño y codificación. Y cuando estas condiciones aparecen, los efectos pueden
ser desastrosos. Por ejemplo, a finales de 1.988 alguien utilizó defectos en algunos
programas de comunicaciones y de correo electrónico ampliamente extendidos para
construir un programa que se "reprodujo", sin permiso (y durante cierto tiempo, sin
conocimiento) de los usuarios, por gran parte de la red DARPA, en Estados Unidos. Así
los programas de comunicaciones que, en principio, producen efectos positivos, produjeron
también el efecto negativo de disminuir la seguridad del sistema.


d. "Comportamiento impredecible". Normalmente, lo más que podemos asegurar de un
programa es que ha sido probado bajo muchas condiciones, y que durante esas pruebas no
ha presentado comportamientos "extraños". Pero nada más. De hecho, la del software es la
única ingeniería que vende sus productos sin garantía, en el sentido de que es común la
venta "tal cual", sin garantizar un determinado comportamiento del sistema informático.
Los estudios sobre fiabilidad y verificación constituyen un campo donde la investigación
es muy activa, aunque hasta el momento no ha deparado resultados espectaculares (véase
el capítulo sobre el desarrollo del software).



2. Estudio del software desde el marco HxIxO = IO.

Una vez que hemos llegado a la conclusión de que el software es efectivamente algo bastante
complejo, podemos analizarlo dentro del marco conceptual HxIxO -> IO, propuesto por Sáez
Vacas. Para ello, comencemos por identificar cada uno de los elementos de este marco.

De una forma sencilla, podremos identificar el objeto (O) como el propio software, tal y como
estamos acostumbrados a entenderlo. Eso es, un programa dado, que una vez ejecutado determina el
comportamiento de un ordenador, y que está escrito en algún lenguaje de programación.
Consideraremos como objeto el código fuente y no el código objeto porque este primero es con el
que se enfrenta el programador (o cualquier otra persona que participa en el diseño, desarrollo o
mantenimiento), y del que depende en último extremo el funcionamiento del programa. Estamos
asumiendo implícitamente que la herramienta que utilizamos para convertirlo en ejecutable
(normalmente un compilador o un intérprete) funciona adecuadamente, sin errores y sin efectos
"extraños". Aunque esto no siempre es cierto, no nos planteará demasiados problemas, ya que la
herramienta no es más que otro objeto software, al que podríamos aplicar el mismo tratamiento que
vamos a aplicar a nuestro programa.

Si queremos enmarcar este objeto dentro del modelo de tres niveles de complejidad, no tendremos
problemas en colocarlo en el nivel más bajo, donde nos ocupamos de la complejidad de los
elementos aislados (ver capítulo sobre marcos conceptuales).


Complejidad y Tecnologías de la Información (Tecnologías de la información)

Medidas de la complejidad del software



4



El H de nuestra fórmula puede ser asociado a toda persona que participe en el ciclo de vida de un
programa, desde que se especifica su funcionalidad, hasta que se retira de la vida activa. Cada una
de ellas tendrá sus intereses y motivaciones, y buscará un aspecto diferente dentro del objeto
considerado. Así, al personal encargado del mantenimiento y modificación le interesará que no haya
dificultad en la comprensión y sí facilidad para cambiar partes del código. El codificador estará
interesado en la capacidad expresiva de las herramientas que use al programar, y en conseguir con
el menor esfuerzo posible una codificación eficiente y sin errores. Y así, cada uno de ellos se
centrará en unas características diferentes del programa.

Un caso especial aparece cuando identificamos H con el usuario del programa. Aquí O no es
propiamente el código fuente, sino el programa en ejecución, y sobre todo su interfaz con la persona
que lo usa. En este caso particular (y muy importante), que no vamos a tratar detalladamente, los
aspectos relevantes serán la facilidad de manejo, la convivencialidad de la interacción hombre-
máquina, la adecuación de lo que hace el ordenador a las necesida