02 Capitulo

Capítulo 2
LA MEDIDA DE LA CALIDAD DEL SOFTWARE
Una diferencia principal entre una "bien desarrollada "

ciencia como la f i ~ i c ay algunas de las menos "bien
desarrolladas" ciencias tales como la sicología o
sociologia es el grado en el cual las cosas son medida.^.'
El objetivo actual de las industrias, incluida la industria de la producción del

software, es la calidad. Pero para alcanzarla es necesario saber en qué situación se
está, y por tanto es necesario estimar o medir la calidad. Se inicia este capitulo con
las definiciones de estimación y medida con sus respectivas características y
propiedades. Se presenta la teoría de la medida y una aproximación histórica a su
aplicación a la industria del software. Se estudiarán, igualmente, las medidas más
importantes propuestas en la historia breve, pero intensa, de la ingeniería del
software.
A mediados de la década de los sesenta el desarrollo de programas para

ordenador presentaba serias disfunciones. Pobre calidad en los sistemas,
aplicaciones entregadas fuera de plazo y con numerosos errores y elevados costes
de mantenimiento eran hechos que se repetían con demasiada asiduidad
' Roberts, Fred S. Meosuremenr Theory wirh Applicorionr 10 Deririonmukinb: Urilify. ond rhr Social Scirnces.
Encyclopedio ?fMorhemarics and i ü Applicarions. Addison Wesley Publishing Company, 1979.
Roberts, Fred S. Director del Centro de Matemáticas Discretas y Teoría de la Ciencia Computaeianal, consorcio
formado por las universidades de Rutgers y Prinienton junto a diversas empresas tecnol6gicas (AT&T, Lucent
Technologies, NEC, entre otras). Consultar la dirección de intemet http:/l dimacs.mtgen.edulindexhtml.
M LA MEDIDA DE LA CALIDAD DEL SOFTWARE
[Marciniak, 19941. La situación era de tal gravedad que la Organización del

Tratado del Atlántico Norte (OTAN) patrocinó en otoño de 1968 una conferencia
internacional en Garmisch-Partenkirchen, Alemania, en la que se dieron cita medio
centenar de los más afamados estudiosos de la disciplina informática. Esta
convención supuso uno de los más importantes hitos en la moderna historia del
software. En ella no sólo se reconoció el estado de crisis en el que se encontraba el
desarrollo de programas para ordenador, sino que también se aportó la solución. En
1968 se acuñó el concepto de "ingeniería del software" como una nueva disciplina
al servicio del desarrollo estructurado y metodológico de los programas
informáticos. La unión de estas dos palabras "ingenieria" y "software", no fue un
hecho espontáneo, tal y como reconocieron los propios organizadores. En las actas
se recogen diferentes apreciaciones en este sentido, siendo una de las más explícita
la cita siguiente:
"La frase "ingenieria del software" fue deliberadamente escogida por

provocadora, dando a entender la necesidad de que la manufactura del
software se base sobre tipos de fundamentos teóricos y disciplinas
prácticas, que son tradicionales en ramas establecidas en la ingenieria."2
Más de veinte años después Norma E. Fenton se cuestiona "¿Algo ha ido mal o
esperamos demasiado, demasiado pronto?"3. Esta pregunta se justifica, cuatro
lustros después de la conferencia de Garmish, en la situación en la que el desarrollo
de programas para ordenador se encuentra sumido y que ~ i b b ilustras ~ de forma
contundente:
" ... por cada seis nuevos sistemas de programación de gran tamaño que
entran en servicio, otros dos quedan cancelados. Los proyectos de
desarrollo de programas de tamaño medio suelen consumir vez y media el
tiempo previsto, situación que empeora en los grandes. Y alrededor de tres
cuartas partes de todos los sistemas de gran tamaño son "fracasos
operativos", lo que significa que o no funcionan como se quería o no se
utilizan para nada."'
' Jamcs E. Tomayco. "Milestones in Software Engineering", Encyclopedia af Software Engineering, John Wiley
& Sons, 1994 pp. 687-697. La traducción es nuestra.
' Fenlun. Noman E. S<flwure Mrirics. A Higorous Approach. London, Chapman & Hall, 1992. Pág 5 . La
traducción es nuestra.
' Gibbs, W. Wayt. Licenciado en Fisica E InglEs por la universidad de Cornell, afamado articulista de Scienrific
Ameriron. ha oublidado numerosos articulas sobre el software v cicncias afincs. Ha desarrollado labores de
investigación en nanotecnologia y biotecnologia en el MIT. Consultar http:/lweb.mit.eduknight-sciencel
' Gibbs, W. Wayt. "La crisis crónica de la programación", Inve.~tigaci6ny Ciencia, Tendencias en Informática.
Pág. 73.
LA CALIDAD DEL SOFTWARE Y SU MEDIDA 65
2. NECESIDAD DE LA MEDIDA DEL SOFTWARE
2.1. La medida como elemento de mejora metodológica
La respuesta a las reflexiones de Fenton nos la proporciona él mismo al

considerar que, a pesar de una clara aproximación a un proceso metodológico en el
desarrollo de programas informáticos, éste no ha considerado la medida del
software con la profundidad y rigor que se requiere, "mejoras metodológicas en
solitario no hacen una disciplina ingenieril"6. Parece evidente que el proceso
estmcturado del desarrollo del software ha proporcionado una clara evolución en la
programación informática, muy alejada de filosofía general de programación
manejada en los orígenes de los ordenadores de propósito general, en la que el
técnico desarrollaba el programa, lo probaba, corregía e incluso utilizaba, tras un
proceso de creación artesanal y sin apenas hacer uso de herramientas o
metodología alguna. Pero este hecho no ha erradicado severos problemas tal y
como nos demuestra la estadística mencionada en la última cita.
Bajo esta realidad podemos indicar que en estos momentos existe una clara
tendencia hacia la obtención de medidas rigurosas, también en el software. No es
extraño encontrar referencias enérgicas en esta dirección aportadas por estudiosos
que nos hacen recordar otras declaraciones, no menos tajantes, enunciadas por
científicos de otras disciplinas, ramas del saber que vieron en el proceso de medida
una base fundamental en su trabajo. Así, por ejemplo, Tom ~ e ~ a r c apuntao' que
"no podemos controlar aquello que no se puede medir"', Fenton va más allá y
sentencia, "la producción de software está fuera de control porque no se puede
medir"9.
La medida del software no es una aspiración nueva, tal y como comprobaremos
en el siguiente apartado, pero quizás ha sido la década de los años noventa aquella
en la que se ha reconocido toda la importancia que esta actividad posee. En la
conferencia celebrada en París Eurometrics 1991, H. D. ~ o m b a c h " perteneciente
'Fenton, Norman E., op. cit. pág. 5. La traducci0n es nuestra.

' DeMarco, Tom. Graduado por las universidades de Columbia, Cornell y La Sorbona de Paris, comenzó su
canera profesional en los laboraturios Bell. Ha trabajado en numerusos proyectos entre los que cabe destacar la
implantación de sistemas informáticos bancatios en Holanda, Suecia, Finlandia y Francia. En 1999 se le concedió
el premio Stevens por su contribución a la ingeniería del software. Consultar Encyclopedia of Software
Engineering, John Wiley & Sons, 1994.
'Tom DeMarco. Controlling Software Proyects: Management, Measurement and Estimation. Englewood Cliffs,
New York Prentice Hall, 1982. La traducción es nuestra.
' Fenton, Noman E., op. cit. pág. 6. La traducción es nuestra.
'O Rombach, H. Deiter. Profesor de Ciencia de la Computación en la universidad de Kaiserlautern en Alemania. Ha
centrado su investigación en la calidad del software y su medida. Consultar Encyclopedia of Software
66 LA MEDIDA DE LA CALIDAD DEL SOFTWARE
al Software Engineering Laboratory (SEL), afirmó "no deberíamos preguntamos

por más tiempo si debemos medir, la cuestión hoy en día es cómo.""
2.2. La medida y el conocimiento
Las ciencias empíricas, junto con las diferentes ingenierías, poseen en el

proceso de medida una larga tradición y fundamentado conocimiento, alcanzado
gracias a siglos de investigación y aportaciones de eminentes cientifi~os'~. La
trascendencia que a esta actividad se le ha conferido queda patente en actitudes
reflejadas en citas como aquella que ilustra este capitulo, u otras de no menos
compromiso o rotundidad. Lord Kelvin, el famoso matemático y fisico británico, a
finales del siglo pasado sentenciaba:
"Cuando puedes medir aquello de lo que hablas, y expresarlo en números,

tú conoces algo acerca de ello; pero cuando no puedes medirlo, cuando no
puedes expresarlo en números, tu conocimiento es insatisfactorio y escaso:
podría ser el comienzo del saber, pero apenas has avanzado en tus ideas
hacia un estado cientifico"".
Medir es conocer, y este conocimiento nos permite avanzar sobre bases sólidas.
Pero medir nos proporciona algo más, nos posibilita aplicar las poderosas
herramientas que las matemáticas nos ofrecen, facilitando la manipulación de datos
con objeto de alcanzar una visión de la entidad estudiada que de otra forma hubiera
sido imposible obtener.
2.3. Importancia de la medida
La trascendencia de la actividad, centro de atención de este capitulo, va más allá

de lo expuesto. La consecución de nuevas, y cada vez más exactas medidas, ha
impulsado la aparición de novedosas técnicas y sofisticado instrumental, pero
' Software Enginccring Laboratoiy. Collected Software Engineering Papers. Vol.: X, SEL-92-003, November,
1992. P=g. 164. La traduccion es nuestra.
" Existen numerosos 4emplos que ratitican esta afimación. Muchos de ellos representaron el comienzo de una
nueva era para la investigación o un avance sustancial en campos cientificos de muy diversa orientación. Galileo
Galilei (1546-1642) inventó el termómetro, paso fundamental para el desarrollo de la termodinámica. Evangelista
Tomcelli (1608-1647) en 1643, realizó el experimento que permitió la invención del barómetro. Henry Cavendish
(1731-1810). inventor de la balanza que lleva su nombre, permite el cálculo de la masa de un cuerpo basándose en
la fuerza de atracción ejercidas por ambas debido a la interacción gravitacional. Willian Crookes (1832-1919)
inventó el radiómetro en 1875. Aparato diseñado para la medida de la energía de una radiación. O los modernos
sistemas del cálculo de distancias basados en el haz láser, son ejemplos que nos permiten afirmar la importancia
que los cicntificos de todas las épocas han dado a la obtención de medidas fiables. Consultar enciclopedia Salvat
Universal. Barcelona. 1996.
'' Kclvin. Willian Thomson, referencia en: Alan L. Mackay. Diccionario de citas cientificas. Ediciones de la
Torre. 1992.
también ha provocado el progreso de disciplinas concretas, estimulando la

aparición de innovadoras hipótesis de notable importancia. Medir, como tarea
científica en si misma, es un verdadero generador de nuevas teorías que han
permitido abrir nuevas perspectivas a muy diferentes campos de investigación. Un
claro ejemplo de este hecho lo tenemos en el desarrollo teórico del concepto de
"temperatura empírica" aportado por la termodinámica. Partiendo, en sus más
remotos orígenes, de la concepción fisiológica de caliente y frío, la diferenciación
entre calor y temperatura no fue correctamente interpretada hasta la intervención en
1760 de Joseph ~ l a c k 'quien
~ aportó la definición de calor específico. Casi un
siglo más tarde, en 1843 James P. ~ o u l e determinó
l~ el equivalente mecánico del
calor, asimilando esta entidad a la energía interna de un cuerpo teóricamente
distinta de la concepción de temperatura, definida como una función de estado, es
decir, dependiente de variables que permite especificar su estado de equilibrio
térmico. Una actividad tan habitual y aparentemente simple como es conocer la
temperatura a la que se encuentra una habitación se apoya en un profundo y
científico conocimiento del atributo que está siendo medido.
Las ingenierías, como disciplinas que aplican el conocimiento cientifico sobre
constmcciones o artefactos que nos son útiles, no son ajenas a la trascendencia del
proceso de medida. Modelos matemáticos y teorías deben apoyarse en medidas
fiables. Si deseamos conocer la resistencia que cierto circuito eléctrico opondrá al
paso de la corriente, es de obligado conocimiento el voltaje soportado por el
mismo, así como la intensidad de corriente que fluirá por el conductor. Sin estos
datos o con información errónea la ley de Ohm sena de muy dificil aplicación.
Esta concepción del desarrollo cientifico, apoyado en la obtención de medidas
fiables, se encuentra avalada por el método científico, verdadera columna vertebral
del conocimiento cientifico y tecnológico, por lo que no nos ha de extrañar el
trascendental papel que esta actividad ha jugado en el devenir cientifico desde hace
siglos.
" Black, Joseph. Quimico y fisico escocés del siglo XVIII. Entre otras aportaciones descubrió el calor latente y el
calor especifico. Consultar enciclopedia Salvat Universal. Barcelona. 1996.
" Joule, James Prescott. Física brithnico del siglo XIX. Estableció la teoria mecanica del calor. Consultar
enciclopedia Salval Universal. Barcelona. 1996.
3.1. Definición y problemática
La estimación es el proceso de predicción de la duración, esfuerzos y costes

necesarios para realizar todas las actividades y obtener todos los productos
asociados a un proyecto.
Es necesario tener en cuenta numerosos aspectos que afectan a la estimación
como la complejidad del proyecto, su estructuración, el tamaño, los recursos
involucrados y los riesgos asociados.
La estimación es siempre dificil de realizar por diversas razones, entre las que
se encuentran:
No existe un modelo ni una fórmula de estimación universal.

Son muchas las personas implicadas en el proyecto, desde la alta dirección
de la empresa a los ejecutivos del proyecto, que precisan de las
estimaciones.
La utilidad de una estimación varia con la etapa de desarrollo en que se
encuentra el proyecto.
Las estimaciones precisas son dificiles de formular, sobre todo al inicio del
proyecto.
La estimación suele hacerse superficialmente, sin tener en cuenta el
esfuerzo necesario para hacer el trabajo.
La rapidez del cambio de las metodologias y las tecnologías no permiten la
estabilización del proceso de estimación.
Los estimadores pueden no tener experiencias.
El estimador suele hacer la estimación en función del tiempo que a él le
llevaría en realizar el trabajo, sin tener en cuenta la experiencia y formación
de la persona que realmente lo realiza.
Existen malas interpretaciones en las relaciones lineales entre la capacidad
requerida por unidad de tiempo y el tiempo disponible. Como consecuencia
se cumple una de las leyes de Murphy, que dice "la duración del trabajo se
ajustará como mínimo al tiempo disponible. Añadir recursos un proyecto
retrasado, no tiene por qué disminuir el retraso."
El estimador tiende a reducir en alguna medida sus estimaciones para hacer
más aceptable su oferta.
3.2. Los métodos de estimación
Además de los métodos algorítmicos se suelen utilizar por su sencillez los

siguientes:
El juicio del experto
La realidad indica que el método utilizado en gran parte de los proyectos

software, y en numerosas empresas en el momento de estimar el coste de los
desarrollos se basan principalmente en juicios emitidos por uno o varios expertos
avalados por su experiencia en entomos similares y apoyados, aunque no en todos
los casos, en datos objetivos obtenidos de proyectos anteriores y almacenados en
bases de datos históricas.
El método de Wideband Delphi es una aproximación que se puede definir como
un protocolo multipaso cuyo fin es hacer coincidir la opinión de un grupo de
expertos evitando así estimaciones parciales de individuos aislados. Los pasos a
ejecutar serían:
1. El coordinador del equipo técnico de expertos presenta a cada uno de ellos

una especificación de estimación.
2. El coordinador convoca una reunión con el gmpo de expertos para que se
produzca un intercambio de opiniones entre ellos sobre el producto y sus
estimaciones.
3. Cada experto aporta su estimación.
4. El coordinador remite a cada experto un informe con el valor medio de las
estimaciones obtenidas así como el valor propuesto por cada individuo.
5 . Se convoca una segunda reunión entre expertos.
6. Los expertos vuelven a emitir sus estimaciones de forma independiente.
7 . Se repiten los pasos 2 al 6 hasta la obtención de un valor en el que todos los
expertos estén de acuerdo.
Este método tiene como desventaja evidente el alto coste en tiempo y recursos
humanos necesarios para su implantación, así como la subordinación al nivel de
experiencia y conocimientos en el entorno que puedan aportar los técnicos.
Como ventajas se podrían indicar que las estimaciones parciales son
neutralizadas y se presenta una estimación global. Por otro lado las estimaciones
suministradas por este gmpo de expertos dificilmente pueden ser obviadas gracias
a la trascendencia que la organización otorga a este proceso al proporcionar
costosos recursos a esta tarea.
La analogía
Se hace la estimación de un proyecto nuevo por analogía con las estimaciones

de proyectos anteriores comparables y que estén terminados.
La lev de Parkinson
En 1987, C. N. Parkinson formuló unas leyes que, reformuladas, se pueden

aplicar a la ingeniería del software. Una de ellas dice "los programas son como los
gases perfectos, ocupan todo el espacio que se les da". Esto significa que la
estimación del esfuerzo se hace en base a los recursos disponibles y no al producto.
La mejor oferta
Se procura conocer hasta cuánto el cliente está dispuesto a pagar y cuáles son
las ofertas de la competencia. El valor que permite lograr el proyecto se toma como
estimación del esfuerzo.
Las estimaciones global y detallada
La estimación global, también denominada descendente, se hace teniendo en

cuenta las funcionalidades del producto, pasándose posteriormente al detalle.
La estimación detallada o ascendente empieza por la estimación de los
esfuerzos individuales, los cuales se suman para obtener el esfuerzo del proyecto.
Tiene el peligro de olvidarse de las tareas generales.
3.3. Las reglas de estimaci6n de De Marco
De Marco formuló las siguientes nueve reglas, relativas a la estimación:
1. Estimar no es repetir.
2. Estimar no es negociar.
3. Las estimaciones no admiten regateo.
4. Estimar no es dividir en partes una duración fija.
5. Un retraso en una fase de un proyecto implica un retraso proporcional en
todas las fases siguiente.
6. Si desea que se le proporcione una estimación significativa, no sugiera la
respuesta.
7 . Una estimación útil es una proyección en la que la probabilidad no es
optimista ni pesimista.
8 . El ratio entre la estimación más optimista y la útil es medianamente

uniforme para cualquier persona.
9. Las estimaciones deben formularlas un comité.
3.4. Evaluación de las estimaciones
Una primera evaluación.de una estimación seria la diferencia entre el esfuerzo

estimado y el real. Pero un error de, por ejemplo, 5 horas-hombre en un proyecto
de 1000, no es el mismo que en un proyecto de 20.000 horas-hombre. Por
consiguiente se suele utilizar el test de porcentaje de error dado por la fórmula:
(Estimado Real) 1 Real

-
Hay que tener en cuenta que los errores pueden ser de infravaloración o de
sobrestimación, cuya importancia sigue la ley de Brooke, en el primer caso, y la de
Parkinson, en el segundo. Los dos tipos de errores no se anulan uno al otro cuando
se hace la media de numerosos errores.
4. ESTIMACIÓN DE COSTES Y ESFUERZO
En los primeros años de la era de la programación, la década de los cuarenta, el

hardware fue el principal objeto de estudio y atención por parte de investigadores
y científicos. Los emergentes sistemas de información automatizada giraban en
tomo a los equipos y su optimización. Hoy en día, por el contrario, es el software el
componente que aporta un mayor valor añadido a estos sistemas. Si, además,
consideramos que el soporte infomático es una actividad estratégica de primer
orden en la sociedad actual, no es extraño que el cumplimiento de plazos y costes
sea una exigencia inevitable en el proceso de creación del software.
El conocimiento de costes y esfuerzos futuros permite prever la asignación de
recursos adecuándolos a las necesidades venideras.
Se presenta como evidente que estimar, es decir, conocer cuál será el valor de
cierta magnitud, no es una tarea simple, más aún en una disciplina joven como es el
caso del desarrollo de programas informáticos, y en el que factores de muy diversa
naturaleza están presentes. Sin embargo, esta decisión por vaticinar el futuro
basándose en datos del presente y en estudios anteriores, ha permitido un cierto
desarrollo de métodos y modelos matemáticos.
4.1. Definiciones de coste y esfuerzo
El coste y el esfuerzo son atributos propios del proceso de desarrollo del

software. Dependiendo del modelo utilizado para su medida serán necesarios datos
de diferente naturaleza tal y como observaremos en los modelos que se explicarán.
Como paso previo a su estimación definamos estos atributos.
El esfuerzo se entiende como el tiempwnecesario para la realización de una
cierta tarea por parte del equipo de desarrollo. Suele venir expresados en hombre-
mes.
El coste se encuentra relacionado directamente con el esfuerzo de cada tarea
aunque en este caso se exprese en términos económicos.
4.2. Los principales modelos
Los modelos matemáticos más importante en la estimación del coste y esfuerzo

son COCOMO, SLIM y Puntos de Funcionalidad, al que se dedicará un capitulo.
Es posible que alguno de estos métodos sea citado en otros apartados del libro ya
que han sido utilizados para la medida de otros atributos del software, como en el
caso del tamaño o en la medida de la calidad. Sin embargo, en este capitulo es
donde se hará una explicación más extensa y detallada de los dos primeros.
El modelo COCOMO (COnstructive COst MOdel) fue ideado por Boehm, el
modelo Punto Función lo desarrolló Albretch y el SLlM (Software, LIfe Cycle
Management) fue creado por Putman.
El modelo COCOMO y el de Punto Función pueden encuadrarse en aquellos
modelos empiricos dependientes de una variable principal a los que se añaden
factores de ajuste relacionados con la productividad. Son dos claros ejemplos de
modelos estáticos.
El modelo SLIM es un modelo dinámico que realiza una repartición del
esfuerzo en función del tiempo.
4.3. COCOMO
El modelo COCOMO permite la estimación del esfuerzo como una medida

indirecta del el tamaño del código fuente. Boehm presentó este método en su libro
Sofhvare Engineering Economies, publicado en 1981.
El modelo de Boehm basa su estimación del esfuerzo en la posibilidad de
conocer el tamaño del programa, es, por tanto. una traslación del proceso
predictivo desde un atributo (esfuerzo) a otro (tamaño). Este modelo fue ideado
tras el estudio de 63 proyectos software realizados por el autor, y ha sido de
indudable impacto en la ingeniería del software.
El modelo COCOMO se basa en la existencia de tres niveles que han de

aplicarse según el estado en que se encuentre el desarrollo del proyecto.
Modelo básico. Se utiliza al principio del proyecto. La información que facilita

es una estimación en cuanto al orden de magnitud del esfuerzo.
Las ecuaciones que rigen este modelo son:
E = a (KLOC)' Ecuación 2.1
T = C E ~ Ecuación 2.2
Donde E es el esfuerzo expresado en personas-mes, el número de líneas de

código estimadas excluyendo comentarios (en miles) viene indicado por KLOC.
Los valores a, b, c. d son valores constantes (tabla 2.1) que dependen de la clase de
proyecto o "modo" que estemos evaluando. El valor T representa el número de
meses estimados para el desarrollo.
Tabla 2.1. COCOMO básico.
Los posibles modos son:
Orgánico. Equipos pequeños de trabajo. Existe un buen conocimiento de la

aplicación y del sistema utilizado. Poca influencia de las comunicaciones.
Semiacoplado. Se sitúan en una posición media en cuanto a complejidad y

tamaño, entre el modo Orgánico y el Integrado. Equipo formado por expertos y
principiantes. Se han de satisfacer requisitos no excesivamente estrictos. Por
ejemplo aplicaciones bancarias o que impliquen transacciones con bases de datos.
Integrado. Sistema hardwareisoftware complejo con influencia clara de la

seguridad o tiempo real. Costes de validación muy elevados. Requisitos estrictos e
inamovibles. Un ejemplo claro lo tendríamos en el software de control de un
sistema de defensa o de una central nuclear.
Modelo intermedio. Se aplica cuando el proyecto ha sido dividido en

subsistemas. En este modelo se han de considerar factores relativos a atributos del
producto software y de recursos (materiales, métodos y personal). Lo valores de las
constantes también se ven afectadas.
En este caso la ecuación es:
E = a (KLDC)~~(X) Ecuación 2.3
Donde E, KLOC, a y b tienen el mismo significado que en el caso del

COCOMO básico. Aunque el valor de los parámetros a y b son diferentes (tabla
2.2).
El valor m(*) es el peso del factor de coste xj, y cuya expresión matemática es:
=n 15
,=I
m@,) Ecuación 2.4
El valor m(x) en el caso del modelo básico tiene como valor fijo la unidad.
Boehm consideró quince factores de coste diferentes, agrupados según el
siguiente esquema.
1. Atributos del producto.

1 . 1 . Fiabilidad requerida.
1.2. Tamaño de la base de datos.
1.3. Complejidad del producto.
2. Atnhutos de los recursos.
2.1. El material.
2.1.1. Restricciones del rendimiento en tiempo de ejecución.
2.1.2. Restricciones de memoria.
2.1.3. Inestabilidad de la máquina virtual.
2.1.4. Tiempo de espera requerido.
2.2. El personal.
2.2.1. Capacidad de análisis.
2.2.2. Capacidad del ingeniero de software.
2.2.3. Experiencia en aplicaciones.
2.2.4. Experiencia con máquina virtual.
2.2.5. Experiencia con lenguaje de programación.
2.3. Métodos y herramientas.
2.3.1. Práctica de los métodos modernos de programación.
2.3.2. Utilización de herramientas de software.
2.4. Tiempo.
2.4.1. Planificación temporal del desarrollo requerida
Cada factor es valorado por separado en una escala ordinal de seis puntos (muy
bajoibajolnominallaltaimuy altalextra alta). A partir de las tablas hechas públicas
por Boehm se asigna un valor numérico a cada factor y se aplica la ecuación 2.4, el
resultado es el factor de ajuste del esfuerzo.
Tabla 2.2. COCOMO intermedio.
COCOMO detallado. El modelo de COCOMO detallado se basa en dividir el

esfuerzo en fases, de forma que para cada una de ellas se obtenga el factor de coste
correspondiente. Finalmente se ha de sumar cada uno de ellos para obtener el
global.
Como guía para el uso del modelo COCOMO, en cualquiera de sus variedades,
podemos indicar los siguientes pasos a seguir:
1. Identificar el "modo" de desarrollo para el nuevo proyecto.

2 . Estimar el tamaño del proyecto en KLOC y derivar una predicción del
esfuerzo.
3. Determinar el valor de los 15 valores de ajuste.
4. Hacer uso de la ecuación de estimación del esfuerzo.
5. Hacer uso de la ecuación que estima el tiempo de desarrollo.
El modelo COCOMO posee un claro inconveniente al involucrar la evaluación

del número líneas de código en el propio sistema de predicción. Por otro lado la
selección del modo de desarrollo es extremadamente importante. El modelo
COCOMO es un modelo muy dependiente de datos históricos de la organización
que no siempre están disponibles.
En el aspecto positivo indicar la transparencia del modelo así como el acierto de
los factores definidos para obtener el factor de ajuste al ser de gran ayuda al técnico
a la hora de entender el impacto de cada factor en el proyecto software.
4.4. SLIM
El modelo de Putnam, Slim, se apoya en que la distribución del esfuerzo en un

proyecto software viene especificado por la denominada curva de
RayleighNorden. Esta curva se obtuvo basándose en datos recopilados por Norden
y las descripciones analíticas de las curvas realizadas por Lord Rayleigb.
Putnam propuso la siguiente "ecuación del software".
L = Ck K ' ! ~td4I3 Ecuación 2.5
Donde L es el número de líneas de código esperadas en magnitudes de

sentencias fuente, Ck es una constante dependiente del nivel tecnológico en el que
se desarrolla la aplicación, suele obtenerse gracias a datos históricos recopilados de
desarrollos anteriores. El factor K es el esfuerzo de desarrollo expresado en
personas-años y finalmente tdes el tiempo de desarrollo expresado en años.
De la ecuación 2.5 podemos obtener fácilmente la ecuación:
K =L ~(ck3
/ td4) Ecuación 2.6
De esta segunda ecuación podemos deducir interesantes conclusiones. El factor

td al estar afectado por una potencia tal alta indica que pequeñas variaciones en el
tiempo de entrega pueden modificar enormemente el esfuerzo a realizar. Por otro
lado también observamos la dependencia de este modelo del valor asociado a Ci, ,
hecho que gran cantidad de especialistas consideran una desventaja, ya que
pequeiias modificaciones en este valor implican grandes modificaciones en el valor
del esfuerzo.
técnicas automatizadas
Tabla 2.3. Algunos valores de CI,propuestos por Pressman.
Putnam definió la denominada aceleración de la potencia de trabajo como
D , = K I ~ ~ ~ Ecuación 2.7
Esta ecuación es sumamente útil a la hora de comparar los modelos de Boehm y

de Putnam. El tiempo de desarrollo es proporcional a la raíz cúbica de K, valor
similar al propuesto por Boehm que recordemos oscilaba entre (0,32 y 0,38). Por
otro lado el esfuerzo es proporcional a la potencia 917, es decir, 1,28 también
similar al exponente del modelo COMOCO que oscilaba entre 1,05 y 1,20. El
valor D,, toma valores específicos para diferentes modalidades de desarrollos, así
en el caso de nuevo software con interacciones con otros sistemas el valor D ,es
7,3, si es un sistema aislado es 15 y para sistemas con gran cantidad de
reutilización de código el valor es de 27.
El modelo de Putnam ha recibido algunas criticas como es el hecho de que las
curvas de Rayleigh y Nordem no consideran la fase de especificación de requisitos,
por lo que no se tiene en cuenta esta fase del desarrollo en la correspondiente
ecuación propuesta por Putnam. Por otro lado algunos técnicos consideran difícil
utilizar este modelo en entomos de desarrollo pequeños. Esta limitación tiene su
origen que los datos recopilados para su creación han sido tomados en entornos de
desarrollo grandes.
O 1 2 3 1 E
Figura 2.1. Aproximación a las Curvas de RayleighNorden.

5. MEDIDA
5.1. Definiciones
Se encuentran diferentes definiciones que identifican la actividad de medir. De

entre todas ellas la más adecuada es la propuesta por Norman E. en ton'^ que
define la acción de medir de la siguiente forma:
o Medir. Proceso a través del cual números o símbolos son asignados a

atributos de entidades en el mundo real de tal manera que los describe de
acuerdo a reglas claramente definidas"
De igual manera se define el resultado de este proceso, es decir, la medida

como:
Medida. Una medida es una asignación objetiva y empírica de un número

(o símbolo) a una entidadpara caracterizar un atributo e . ~ ~ e c ~ c o " .
Se puede clasificar las medidas realizadas en dos tipos bien definidos, medidas
directas y medidas indirectas. Se definen de la siguiente manera:
o Medida directa. La medida directa de un atributo es una medida que no

depende de medidas de otros atributos.
o Medida indirecta. Medida indirecta de un atributo es aquella que

involucra la medición de otros atributos (uno o varios) '.
En numerosos casos la obtención de medidas indirectas es enormemente útil.
Atributos, de muy diversa naturaleza, pueden ser estudiados más adecuadamente
haciendo uso de este tipo de medidas.
Algunos conceptos utilizados en la medida de atributos propios del software se
han utilizado de forma poco concisa e incluso contradictoria. Este es el caso de la
palabra métrica. Para evitar confusiones y sentar una definición objetiva definimos
métrica de la siguiente forma:
"' Fenton, N o m a n . Profesor de la Universidad de Queen Mary (Universidad de Londres). Ha sido investigador
principal de cn numerosos proyectos relacionados con la medida del software, métodos formales y aspectos
teóricos de la ingenieria del software. Consultar Encyclopedia of Software Engineering, John Wiley & Sons, 1994.
Fenton. Norman E. Soflware Merrics. A Rl,qorous Approach. London, Chapman & Hall, 1992. Pig. 3 . La
traducclón es nuestra.
I X Fenton, Noman E., op. cit. pág. 17. La traducción es nuestra.
I Y Fenton, Noman E., op. cit. pág. 19. La traducción es nuestra.

o Métrica. La caracterización numérica de un atributo "simple" en

contraposición al concepto de medida, entendido como ,función cuyos
parametros serán las métricas obtenidas y que nos permitirún estudios de
atributos más complejos*o.
Evidentemente en el entorno de la medida del software el concepto "métrica" no

tiene relación con el concepto asociado al espacio métrico propio de la topología en
las matemáticas.
Las definiciones anteriores unidas a la teoría representacional de la medida que
a continuación introduciremos nos permiten definir un marco teórico apropiado del
que luego haremos uso para ajustarlo definitivamente al medio informático.
5.2. Teoría general de la medida
La teoría de la medida se sustenta en el teorema de representación, teorema de

unicidad y la definición del sistema de relación. Expliquemos cada uno de ellos.
El "sistema de relación empírico" tiene como función determinar las
propiedades (o axiomas) acerca de los atributos, las cuales capturan cualquier
comprensión intuitiva u observación empírica sobre los mismos. La medida es
precedida del concepto (recordemos el desarrollo de la noción de temperatura
empírica reseñada en el apartado anterior), de forma que un atributo ha de ser
caracterizado a partir de las relaciones empíricas que podamos establecer, primer
paso hacia la consecución de su medida.
De manera formal, los atributos se encuentran caracterizados por un conjunto de
relaciones empíricas "R", que unido al de entidades "C", constituyen el
denominado sistema de relaciones empíricas.
En lenguaje propio de las matemáticas podemos escribir:
c (C, R)
siendo:
C: Sistema de relación empírico.

C: Conjunto de las entidades consideradas.
R: Conjunto de relaciones observadas sobre las entidades
Así, por ejemplo, podríamos considerar un conjunto de entidades y relaciones

de la siguiente manera:
20
Fenton, N o m a n E., op. cit. pág. 21. La traducción es nuestra
donde las relaciones involucrarian elementos del conjunto C
Habríamos establecido el sistema de relaciones empirico, primer paso hacia la

medida de los atributos propios de las entidades estudiadas. Se nos presenta como
evidente que un aumento en el número de relaciones que pueden establecerse
implica un mayor conocimiento de la entidad estudiada.
Una vez establecido el sistema de relación empírico, y tomando éste como base,
se ha de establecer el denominado "sistema de relación numérico", consistente en
un conjunto de números y una o más relaciones definidas sobre los mismos. Cada
relación propia del sistema empirico ha de tener su correspondiente relación en el
sistema numérico.
Matemáticamente:
N (N, P)
siendo:
N: Sistema de relación numérico.

N: Conjunto de números considerados.
P: Conjunto de relaciones observadas sobre el conjunto N.
Siguiendo con el ejemplo anterior, debemos definir el sistema de relaciones

numéricas en función al sistema empirico.
donde las relaciones involucrarían elementos del conjunto N.

Una vez definido el sistema empírico y su correspondiente sistema numérico

estamos en disposición de definir la medida de un atributo.
La medida de un atributo es una correspondencia desde un sistema de relación
empírica (C,R), para el atributo, sobre un sistema de relación numérica (N,P). La
relación, M, hará corresponder entidades del conjunto C en "números", esto es,
entidades del conjunto N, además de hacer corresponder cada relación R en una
relación en P. Como requisito adicional se ha de cumplir la "condición de
representación" que implica el que toda relación empirica ha de ser mantenida en el
sistema de relación numérico. Si la relación M cumple esta condición se denomina
homeomorfismo o representación.
En simbología matemática podemos escribir:
En diagramas de Venn y considerando los ejemplos indicados arriba, la

correspondencia podría expresarse:
Figura 2.2. Diagrama de Venn para la relación M.
La condición de representación requiere que medir sea el establecimiento entre

entidades en C y números, de tal forma que las relaciones en C inducidas por el
atributo impliquen y sean implicadas por las relaciones entre sus imágenes en el
conjunto de números elegidos. La condición de representación puede ser vista
como la definición formal de aquello que nosotros queremos hacer significar a
través de la medida, describiendo o caracterizando un atributo.
5.3. Escalas
Bajo este soporte teórico definimos el concepto de "escala" como la tnpleta

(C,N,M). En muchos casos, cuando los sistemas de relación numérico y empíriea
se nos presentan como evidentes la notación se simplifica y asociamos la definición
de escala con el simbolo que indica la correspondencia, es decir M.
Pueden existir diferentes escalas al poder definir varias representaciones para un
mismo sistema empírico en estudio. Para un sistema de relación dado, cualquier
correspondencia que transforme una representación M en otra representación M'
válida, se denomina representación admisible. El tipo de transformación admisible
para un determinado sistema de relación empírica define cuán única es la escala y
si puede ser utilizada como escala tipo. Esto implica que la escala tipo depende de
las reescalas permitidas. La tabla 2.4 expone las transformaciones más habituales,
hecho que definirá el tipo de escala que estemos utilizando en un momento dado.
"F" monótona creciente.

M(x) > M(y) =. M'(x) 2 M'(y)
M ' = a M + b (a>O) Intervalo

M'=aM (a > O) Ratio
M'=M Absoluta
Tabla 2.4. Tipos de escalas más habituales,
Basándonos en los conceptos estudiados de escala describamos la noción de

"significación" en el entorno de la medida de atributos. Esta definición será útil a la
hora de establecer las limitaciones sobre el tipo de manipulaciones matemáticas a
las que podemos someter los valores resultado de una medida realizada en el
entorno de una determinada escala.
Se dice que un enunciado que envuelve escalas numéricas es significativo si su
verdad (o falsedad) permanece inalterable si cada escala M implicada es
reemplazada por una escala aceptable M'. La relación M' es una escala aceptable si
puede derivarse de la relación M por una transformación admisible.
6.1. Los orígenes
El deseo de obtener valores numéricos que representan atributos propios del

desarrollo y ejecución de programas para ordenador ha sido una aspiración para
investigadores y estudioso desde hace más de treinta años.
Uno de los primeros y principales trabajos que de forma más importante han
influenciado en la teoria aplicada a la medida del software, fue publicado en 1964
por arquitecto británico Cbistopher Alexander, lo tituló Notes on fhe Synfhesis of
Fonn.En su escrito Alexander describió la naturaleza del proceso de diseño según
su óptica. Para este investigador un ingenio ha sido bien diseñado si los
componentes que forman parte de él son relativamente independientes entre sí.
Alexander finalizaba su escrito presentando un programa informático cuya
aplicación seria ayudar a técnicos y profesionales en la tarea del diseño. Este
programa aceptaba como datos de entrada las relaciones existentes entre los
diferentes componentes del artefacto. Haciendo uso de un análisis en racimo
proporcionaba como resultado un diseño en el que se pretendía minimizar en
número de componentes del mismo. Como podemos apreciar la relación del trabajo
de este arquitecto con la práctica informática se produce exclusivamente en el
desarrollo del programa que ideó para ayudar a extender su visión en el diseño
industrial. A pesar de este hecho, las propuestas de Alexander han sido uno de los
pilares sobre los que se han apoyado investigadores que han apreciado en sus tesis
una concepción adecuada para el proceso de creación de productos software. Más
adelante, en este mismo capítulo, podremos apreciar hasta que punto las ideas de
Christopher Alexander han condicionado la investigación de la medida del
software.
6.2. Maurice Halstead
Maurice ~alstead" fue el primer investigador que de forma consistente propuso

un proceso de medida para el software. Para ello se apoyó en diferentes fuentes
teóricas, que van desde la sicología del conocimiento, teoria de la información o la
termodinámica, hasta concretar un proceso de medida determinado. La filosofía
básica en la que asentó su teoría fue que la comprensión del software era similar al
proceso mental de manipulación de señales. Halstead definió un conjunto de
medidas que pueden ser extraídas del código fuente del programa. Su influencia en
" Halstead, Maurice H. Graduado en meteorologia por la universidad de Berkeley en 1940. doctor por la
universidad de Jonhs Hopkins de Baltimore, es considerado uno de los pioneros en el software para computadaras.
Realizó imponantes aportaciones en la rnetncas del software a las que inicialmente las denominó "Termodinámica
del Software". Consultar el sitio *?vw.itee.uq.edulau.
la teoria informática ha sido muy importante y su trabajo fue utilizado en la

industria además de ser impulsor de la concepción de la medida del software como
actividad de principal interés para el desarrollo informático. La influencia de este
investigador se extendió de forma definitiva durante la década de los setenta y
primeros años de los ochenta y podemos hablar de centenares de estudios e
investigaciones basadas en los principios propuestos por este investigador.
~ a k e ?y ~zwebenZ3hicieron uso de medidas basadas en la teoría propuesta por
Halstead para evaluar el grado de modularización de un sistema [Baker, 19791.
curtisZ4y SUS colegas intentaron demostrar que cierto parámetro definido por
Halstead [Halstead, 19771 era un buen sistema de predicción del tiempo de
corrección de errores [Curtis et al, 19791. Éstos son algunos de los muchos
ejemplos que podríamos aportar.
La teoria de Halstead perdió numerosos adeptos a mediados de la década de los
ochenta. Este hecho se basa en ciertos contenciosos conceptuales que esta teoria no
llegó a superar [Fenton, 19921:
o Muchas de las asunciones sobre la sicología cognoscitiva en la que se baso

Halstead se consideran ahora erróneas.
o Muchos de los experimentos realizados se encuentran pobremente
diseñados y los resultados obtenidos poseían errores estadísticos. La teoria
propuesta se basaba en medidas de carácter general, de forma opuesta a la
actual consideración de medidas especificas que respondan a preguntas
concretas.
o Las medidas propuestas se basaban en el código del programa, de forma
preponderante. Este hecho supone un grado de limitación muy elevado para
el programador, que tiene poca libertad de acción a la hora de alterar el
curso del proyecto ya que muchos recursos han sido ya utilizados pues la
aplicación ha pasado por varias fases que, quizás, deberían reconsiderarse.
O Las reglas de conteo de las que hace uso, no se encuentran totalmente
definidas.
Estas deficiencias han llevado a que las medidas propuestas por Halstead hayan
sido prácticamente eliminadas del contexto industrial, a excepción de algunos
experimentos aislados. A pesar de esta afirmación hemos encontrado investigadores
" Baker, A.L. Matemático británico condecorado con la Medalla Fields en 1970 por su trabajo en el campo de la
teoria de los numeros. Consultar el sitio http:l/www.britamica.com.
" Zweben, Stuan. Profesor de la universidad del Estado de Ohio y responsable del Depanamento de Ciencia de la
Información y la Computación. Estudioso de la ingeniería del software, ha centrado sus estudios en la medida de la
calidad del software. Consultar Encyclopedia of Software Engineenng, John Wiley & Sons, 1994.
24
Cuctis, Bill. Conocido internacionalmente por sus investigaciones sobre la medida del software, diseño de
interfaces o factores humanos y de organización que afectan al proceso soítware. Doctor por la universidad
Cristiana de Tejas, entre otros titulos, ha publicado casi un centenar de articulas y desarrollado su carrera en
prestigiosos centros de estudio. Consultar Encyclopedia of Software Engineering. John Wiley & Sons. 1994.
que no han perdido toda la esperanza en los procesos propuestos por Halstead.
Alguno de ellos incluso lamenta la muerte de este investigador pues consideran que
su talento hubiera podido superar las críticas que ahora recaen sobre su teoría.
6.3. El control de flujo de programas
A mediados de la década de los setenta surgió un gran interés por la medida del
software basado en el control de flujo de un programa o módulo. Este hecho
coincidió con el auge de la programación estructurada como aproximación sensible
al desarrollo detallado del diseño de módulos. En este contexto teórico un sistema
un programa fácil de leer, desarrollar, mantener y corregir es aquel que se
encuentra diseñado bajo un limitado número de estructuras de control.
La medida clásica del control de flujo es la denominada "complejidad
ciclomática". Esta medida fue desarrollada por el cientifico norteamericano
internacionalmente conocido en el ámbito de la medida del software por sus
aportaciones en este campo, Thomas ~ c c a b e . ~ Esta
' es una medida basada en una
teoria gráfica, relacionada directamente con el número de "caminos" asociados a
un programa o módulo. McCabe postuló que un valor elevado de la complejidad
ciclomática de un grafo que representa un módulo o programa de forma directa,
implicaria un grado elevado de dificultad en las propiedades de comprensibilidad y
facilidad de prueba. La razón de este discernimiento es que un valor elevado en la
complejidad ciclomática implicaria una densidad elevada de instmcciones tipo "IF,
WHILE" o "REPEAT". La incidencia de estas constmcciones es un mayor grado
de dificultad a la hora de leer esos programas o probarlos, ya que implicarían un
mayor número de caminos a explorar al realizar pruebas de datos.
El trabajo de McCabe de 1976, es de obligada referencia en cualquier texto de
ingeniería del software al ser uno de los modelos más originales y copiados de la
historia de la medida del software.
A pesar de este hecho han aparecido estudios críticos sobre la medida propuesta
por McCabe. Se demostró que muchos de los experimentos eran estadísticamente
sospechosos y que la complejidad ciclomática no proporciona mejores predicciones
que aquellas que nos ofrece el modelo de las líneas de código. Esta afirmación se
soporta sobre numerosas experiencias empíricas [Fenton, 19921.
Existen, además, otras criticas realizadas hacia esta teoría gráfica. Por un lado la
falta de trascendencia dada por este modelo a las condiciones de un módulo o
programa. Así, por ejemplo, dos módulos con igual complejidad ciclomática son
enormemente distintos debido al uso de múltiples operadores booleanos,
expresiones aritméticas complejas o abuso de los "flags" en el programa. Otros de
" MacCabe Thomas,J. Licenciado en matemáticas por las universidades de Privilence y Cannecticut. Prestigioso
consultor y autoridad en las áreas de la calidad del software, técnicas de validacicin y pruebas del software.
Consultar Encyclopedia of S o h a r e Engineering, John Wiley & Sons, 1994.
los problemas se encuentra e n el tratamiento de los datos. Dos programas pueden

tener igual complejidad ciclomática, pero uno de ellos puede ser mucho más dificil
de entender que el otro debido al número y extensión de las variables utilizadas por
cada uno de éstos. A finales de los setenta y principio de los ochenta han aparecido
algunas variantes del modelo de McCabe que intentaban superar estas criticas.
Aparecen modelos que consideran el nivel de anidamiento o complejidad booleana
o tienen en cuenta factores asociados a los datos tratados y de qué forma, por parte
del programa.
Las medidas basadas en el control de flujo impulsaron un área de aplicación de
las medidas del software de enorme potencial. Si un programador utiliza un
detallado diseño, de forma que sea isomórfico con el código final generado,
medidas tales como la complejidad ciclomática pueden ser utilizadas durante la
fase de diseño detallado del programa.
Una de las mayores críticas vertidas sobre el modelo de McCabe es que haya
sido utilizado para medir más factores de calidad que aquellos para los que fue
ideado. Muchos trabajadores, escondidos tras el paraguas del término complejidad,
han erróneamente extendido éste hacia áreas donde McCabe nunca intentó ir.
6.4. Sistemas de diseiío
Si la década de los setenta puede definirse como el decenio de la programación

estmcturada los ochenta se pueden caracterizar como la década de los "sistemas de
diseño". La característica más significativa de esta concepción del desarrollo de
programa para ordenador se centra en restar trascendencia a la fase de
programación, recayendo el peso del desarrollo sobre tareas anteriores a ésta, tales
como la captura de las especificaciones del sistema o la fase de diseño. Esta
concepción se inspiró en la industria tradicional y es dónde las tesis propuestas por
Christopber Alexander alcanzan su mayor influencia tras casi veinte años desde su
publicación.
Tal como propuso Alexander la idea principal de los modernos sistemas de
medida están basados en la idea de que el sistema software es aquel en el cual los
componentes del mismo (subrutinas, módulos, rutinas) son relativamente
independientes y se encuentran aislados entre si. Estos sistemas tienen la propiedad
de que sus módulos son fáciles de entender, corregir y probar. El diseño
estructurado de Yourdon tiene como elemento sustancial de su método de
programación las ideas originales de Alexander, y los trabajos sobre la abstracción
de datos propuestos por David parnasz6, o los iniciales intentos de caracterizar la
26
Parnas, David Lorge. Profesor de lngenieria Computacional y Electricidad de la universidad de McMaster,
Ontario. Miembro de Laboratorio de Invedigaci6n de Comunicaciones del Instituto de Telecomunicaciones de
Ontario. Autor de m i s de 150 publicaciones orientadas al estudio de la estructura del software, diseao de
LACALIDAD DEL SOFTWARE Y SU MEDIDA 87
complejidad del sistema, fueron catalizadores de esta visión y su aplicación a los

modernos modelos de medida. El modelo de ~ a f u r a " y ~ e n r J 8 es,
probablemente, el diseño más utilizado desarrollado hasta ahora. La idea principal
de este sistema es que la complejidad es medida en términos de flujos de
información y que aquellos módulos más complejos del sistema son aquellos a los
que fluyen más datos.
6.5. Costes y esfuerzos
En paralelo con el trabajo sobre la medida de los sistemas de diseño, los últimos
años de la década de los setenta y los primeros años de la década de los ochenta
vieron algunos trabajos derivados de las medidas de las especificaciones. Las
medidas extraídas de las especificaciones funcionales del sistema se idearon pare
estimar el coste y esfuerzo o para asegurar la productividad. Allan ~ l b r e t c hes~el~
investigador por excelencia en esta área de estudio.
La medida propuesta por Alhretch, "punto de funcionalidad", tiene en su ánimo
medir el tamaño funcional del software. Originalmente se intentó en el
procesamiento comercial de datos.
~ ~ m o n sdesarrolló
~' un producto industrial basado en la idea original de
Albretch. Este modelo es utilizado, sobre todo, para administradores de grandes
bases de datos, en cuyos sistemas esta medida es de las más populares.
Un problema achacado al punto de funcionalidad es que asume un limitado
número de aplicaciones tipo, principalmente sistemas basados en ficheros de gran
volumen, muy propios de entidades financieras, pero no puede considerarse en
sistemas híbridos tales como aquellos de control de stocks con un gran componente
de comunicaciones. En los primeros años de los ochenta DeMarco presentó una
medida llamada " B A N G que intentaba superar este hecho apoyado en factores de
ajuste que dependían del grado de fortaleza de datos y de funciones.
lenguajes, software de seguridad, entre otros campos de estudio. Consultar . Encyclopedia of Software
Engineexing, John Wiley & Sons, 1994.
'' Kafura, Dennis F. Licenciado en matemáticas por la universidad de San Francisco y doctor por la universidad
de Purdue, actualmente es responsable del Depanamento de Ciencia de la Computación del Instituto Politécnico
de la universidad de Virginia. Su labor investigadora ha alcanzado la programación orientada a objeto.
computación paralela, seguridad informitica, mktricas, entre otros campos. Consultar Encyclopedia of Software
'%enry, Sallie. DoEtora en Ciencia de la Computación por la universidad del Estado de lowa, ha trabajado en los
campos de la medida del software, metodologias de diseao y programación orientada a objeto. Consultar el sitio
http://ww.cs.vt.edul
'' Albrech, Allan J. Internacionalmente conocido como inventor de la medida denominada anAlisis del punto
función. Graduado por la universidad de Bucknell en 1949 como ingeniero eléctrico y elecn6nico. trabajó en IBM
donde desarrolló gran parte de su carrera. Se retiró en 1998 desarrollando ahora una labor de consultor
independiente. Consultar Encyclopedia of Software Engineexing, John Wiley & Sons, 1994.
'O Symons, Charles. Cientifico con más de cuarenta años de experiencia, fue pionero en la medida del software
desarrollando la técnica denominada puntos función MKII. Comenzó su carrera en el uso de ordenadores aplicados
a la energía atómica. Consultar Encyclopedia of SoRware Engineeing, John Wiley & Sons, 1994.
La medida de una aplicación a través de los puntos de funcionalidad posee hoy

en día una extensión mundial, aunque se ha implantado de forma más amplia en los
Estados Unidos de América, Australia, Japón y algunos paises europeos. En estas
localizaciones han aparecido asociaciones de usuarios de gran influencia y que a
través de foros de debate y cursos extienden este modelo por todo el mundo".
En los últimos años de la década de los setenta se incrementó el interés por la
medida de las pruebas estructurales. Un número de medidas fueron desarrolladas
con el deseo de cuantificar el grado de profundidad que deben poseer el proceso de
pruebas. Estos modelos se han basado en medidas estructurales, pocos trabajos se
han llevado acabo sobre pruebas de tipo funcional.
A finales de la década de los setenta y en la década de los ochenta los
programadores encontraron sus mayores problemas en el coste y estimación del
proyecto software. El deseo era encontrar un modelo que tuviera un número de
entradas y que produjera alguna forma de estimación de recursos para el proyecto.
Los problemas de la estimación del coste.
El método más conocido es el modelo COCOMO desarrollado por el científico
Bany ~oehm". Como elemento primordial indica la necesidad de una base de
datos del proyecto previa. Otros modelos como el SOFTCOST desarrollado en
Pasadena por investigadores de la "Jet Propulsion Laboratory". A través de
cuarenta y siete preguntas y de las correspondientes respuestas se deduce el valor
de sesenta y ocho parámetros. La filosofia del proyecto es desarrollar un programa
de esfuerzos, niveles de equipos, documentación y requisitos de capacidad de
procesamiento.
Como se puede apreciar en este breve recomdo por la historia de la medida del
software, esta actividad ha sido centro de atención de numerosos investigadores.
Sin embargo aún hoy en día existen algunos problemas que todavía no han sido
resueltos:
o Falta de madurez en la medida del software.

m Inexistencia de estandarización en las medidas.
o Medidas del software aún no ampliamente aceptadas [Zuse, 19981,
alrededor del mundo.

'' Boehm, Barry. Profesar de Ingeniena del Soflware y Director del Depanamento de Ciencia CompuLlcianal en el
Centro de lngenieria del Software. Doctor ingeniero por la universidad de UCLA en 1961, ha realizado numerosas
aportaciones a la ingenieria del software. tales como el modelo COCOMO, el Modelo Espiral o aproximaciones
teóricas a la administración del software. entre aüas. Consultar Encyclopedia of Software Engineenng, John Wiley
& Sons, 1994.
7. LA MEDIDA DEL SOFTWARE
7.1. Marco teórico
Tras definir concepto básicos, propios de la teoría de la medida, este apartado

propone un marco teórico y conceptual sobre el que asentaremos las diferentes
actividades asociadas con la medida del software. De nuevo haremos referencia al
texto de Norman E. Fenton como bibliografía básica en este apartado aunque
introduciremos aportaciones de otros autores que refuercen este acercamiento
teórico al proceso de medida de programas informáticos, aportaciones que
indicaremos puntualmente.
La realización de medidas aplicadas en un entorno propio del desarrollo de
programas informáticos necesita definiciones concisas que identifiquen claramente
las entidades a estudiar así como aquellos atributos que serán objeto de dichas
medidas.
Procesos, productos y recursos serán los entes objeto de estudio en este entorno.
A continuación los definimos y acompañamos estas definiciones con ejemplos que
pretendemos aclaren definitivamente estas exposiciones.
Procesos. Serán aquellas actividades relacionadas con el software que

normalmente poseen e/ parámefro "tiempo" comofactor. Por tanto son
actividades que se realizan durante una parte del tiempo total que dura el
proyecto sofhuare 33,
Ejemplos de esta entidad podrían ser desde la construcción de especificaciones

hasta el propio desarrollo del sistema software, desde la captura de los requisitos
hasta la liberación al usuario del producto.
Productos. Se entienden como aquellos servicios, herramientas o

documentos derivados de los procesos, entendidos como resultados de
éstos34.
Como ejemplos de esta entidad podríamos indicar la documentación propia de

las especificaciones o del diseño, representación del código fuente u objeto, entre
otros.
" Fenton, Noman E . Sofmare Melricr. A Rigoruus Approoch. London. Chapman & tlall, 1992. La traducci6~es
nuestra.
II
Fenton, N o m a n E . So&orr Metrics. A Rigorous Approoch. London, Chapman & Hall, 1992. Pig. 42. La
Recursos. Se dejnen como un conjunto de entidades considerados como

entradas para la producción del s o f h ~ a r e ~ ~ .
Ejemplo de recursos seria el personal implicado, herramientas utilizadas o

método manejado.
Una vez definidos las entidades que serán objeto de nuestra atención hemos de
considerar los atributos a medir. Como primera aproximación indiquemos una muy
fundamental división de los mismos en dos tipos bien definidos. "Atributos
directos" como aquellos que pueden ser medidos en términos de las entidades a
estudiar y "atributos indirectos", definidos como aquellos que sólo pueden ser
medidos por medio de cómo productos, procesos y recursos se relacionan con su
entorno.
Basándonos en las entidades consideradas anteriormente, podemos encontrar un
número determinado de atributos de interés.
Asociados al estudio de los procesos, como atributo interno, Fenton aporta un
número limitado de éstos. Tiempo, entendido como duración del proceso, esfuerzo
asociado al proceso y número de incidentes de cierto tipo que pueden acaecer
durante el proceso estudiado. Evidentemente podemos encontrar numerosas
combinaciones de medidas directas cuyo resultado sería la pertinente medida
indirecta que, recordemos, pueden ser de igual e incluso de mayor interés que las
medidas directas. Ejemplos de atributos externos podríamos citar la estabilidad,
coste, calidad, entre otros.
Atributos internos propios de los productos serían, longitud, funcionalidad,
redundancia, grado de acoplamiento etc. Como atributos externos podríamos citar
la comprensibilidad, facilidad de mantenimiento, fiabilidad.
En el caso de los recursos, podríamos citar como atributo interno la edad o
sueldo (del programador), nivel de comunicación en los equipos de trabajo o la
rapidez o precio de los equipos hardware. Como atributos externos podemos
indicar la facilidad de uso, grado de ergonoinia o experiencia.
La tabla 2.5 muestra un resumen de atributos, recursos, procesos y entidades
relacionadas con la medida del software.
Los atributos externos son aquellos que sólo pueden ser medidos de forma
indirecta, según se encuentren conectados con su entorno, mientras que los
atributos internos son los que su medida puede realizarse de forma directa como
atributo del recurso. producto o proceso estudiado. La relación entre atributos
internos y medidas directas, así como entre atributos externos y medidas indirectas
es clara. Pueden existir pocos atributos internos de cierta entidad, sin embargo la
combinación de éstos nos puede proporcionar una información muy interesante y
3s
Fenton, Noman E., op. cit. pág. 43. La traducción es nuestra
LACALIDAD DEL SOFTWARE Y SU MEDIDA Y1
ser tan abundante como la combinación de atributos internos sea posible. La tabla
2.6 muestra algunos atributos y su entidad asociada. según la visión "METKIT".
[Funcionalidad 1 _ 1 1 Producto (especificaciones, diseño, código.. .)

Coste Proceso (diseño, pruebas, captura de
l;
-
especificaciones...)
Esfuerzo
-
1 Proceso (diseño, pruebas, captura de
1 especificaciones...)
Reuso - 1 Producto (especificaciones, diseño, código.. .)
Productividad 1 1 1 Recurso (equipo de trabajo, programador,
Calidad
, lhardwar;;) ) );
Producto rueba con datos, diseño, códi o .. .
)
Calidad Proceso creación de es ecificaciones...

Calidad Recursos software, hardware, ersonal ...
Com le'idad Productos diseño
Facilidad Producto (código)
-
de uso
Fiabilidad _ Producto (código), Recurso (Software, personal,
hardware.. .)
Tabla 2.5. Ejemplos de atributos internos y externos.
Dos últimas definiciones nos permitirán finalizar este repaso teórico a la medida
del software.
El fin último del proceso de medida es el cálculo de alguna magnitud conocida
o predecir un atributo aún inexistente. Este hecho nos lleva a dos definiciones
importantes.
Modelo. Entendido como una representación abstracta de un objetoj6.
Podemos dividir los modelos existentes en representaciones abstractas de varios

productos, procesos o recursos. Tales modelos capturan atributos que están siendo
medidos sin ambigüedad posible. Por otro lado existen modelos que indican
abstractas representaciones entre atributos de entidades. Estos modelos relacionan,
por lo general, más de dos medidas a través de una fórmula matemática.
Pero la consecución de un modelo no es suficiente para desarrollar un proceso
de predicción. Necesitamos determinar parámetros para el modelo e interpretar los
36
Fenton, Noman E. Soflware Melrici. A R i p r u u s Approach. London. Chapman & Hall, 1992. PAg. 48. La
resultados de forma correcta. Basándonos en esto podemos definir:
Sistema. Sistema de predicción como un modelo matemático junto a un

conjunto de procedimientos predictivos que permiten determinar parámetros
desconocidos e interpretar resultadosJ7.
en cualquier proyecto.
Reutilización etc.
ser de muy diversa naturaleza. equipo hardware capacidad de

Herramientas, métodos, (entre otros) reutilización (entre
materiales, son ejemplos de otros)
recursos.
Tabla 2.6. Entidades objeto de medida según el marco teórico propuesto.
Las definiciones expuestas nos permitirán abordar el proceso de medida del

software bajo una base científica.
" Fenton, Norma" E. Op. Cit. pág. 48. La traducción es nuestra.

8. LA NORMA ISOllEC9126
No podemos acabar este capitulo sin hacer referencia a la norma ISOIIEC 9126.
Esta norma es trascendente por diversos motivos. Es un intento por normalizar la
medida de la calidad del software por parte de un organismo tan importante como
es el caso de ISO. Asume la medida del software a través de una metodología de
amplia utilización en las ciencias empíricas como es la descomposición jerárquica
en árbol. Considera la medida de la calidad a través de la medida de atributos
directos, indirectos y medida de la calidad de uso, siguiendo la propuesta de Fenton
en su texto sobre la medida del software. La norma ISOIIEC 9126 también propone
un procedimiento de medida con objeto de ser una referencia de carácter
internacional.
Estudiaremos en detalle esta norma en el capitulo VII.
a nomas
Adherencia SoRware Facilidad Facilidad de
Seguridad
a nomas atractivo para pniebas reemplazo
Adherencia Adherencia Adherencia Adherencia
a nomas a nonnas a nomas a nomas
Tabla 2.6. La norma ISOIIEC 9126

02 Capitulo

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

02 Capitulo

Încărcat de

Drepturi de autor:

Formate disponibile

Capítulo 2

LA MEDIDA DE LA CALIDAD DEL SOFTWARE

Una diferencia principal entre una "bien desarrollada "

El objetivo actual de las industrias, incluida la industria de la producción del

A mediados de la década de los sesenta el desarrollo de programas para

[Marciniak, 19941. La situación era de tal gravedad que la Organización del

"La frase "ingenieria del software" fue deliberadamente escogida por

2. NECESIDAD DE LA MEDIDA DEL SOFTWARE

2.1. La medida como elemento de mejora metodológica

La respuesta a las reflexiones de Fenton nos la proporciona él mismo al

'Fenton, Norman E., op. cit. pág. 5. La traducci0n es nuestra.

al Software Engineering Laboratory (SEL), afirmó "no deberíamos preguntamos

2.2. La medida y el conocimiento

Las ciencias empíricas, junto con las diferentes ingenierías, poseen en el

"Cuando puedes medir aquello de lo que hablas, y expresarlo en números,

2.3. Importancia de la medida

La trascendencia de la actividad, centro de atención de este capitulo, va más allá

también ha provocado el progreso de disciplinas concretas, estimulando la

3.1. Definición y problemática

La estimación es el proceso de predicción de la duración, esfuerzos y costes

No existe un modelo ni una fórmula de estimación universal.

3.2. Los métodos de estimación

Además de los métodos algorítmicos se suelen utilizar por su sencillez los

El juicio del experto

La realidad indica que el método utilizado en gran parte de los proyectos

1. El coordinador del equipo técnico de expertos presenta a cada uno de ellos

Se hace la estimación de un proyecto nuevo por analogía con las estimaciones

En 1987, C. N. Parkinson formuló unas leyes que, reformuladas, se pueden

Las estimaciones global y detallada

La estimación global, también denominada descendente, se hace teniendo en

3.3. Las reglas de estimaci6n de De Marco

De Marco formuló las siguientes nueve reglas, relativas a la estimación:

8 . El ratio entre la estimación más optimista y la útil es medianamente

3.4. Evaluación de las estimaciones

Una primera evaluación.de una estimación seria la diferencia entre el esfuerzo

(Estimado Real) 1 Real

4. ESTIMACIÓN DE COSTES Y ESFUERZO

En los primeros años de la era de la programación, la década de los cuarenta, el

4.1. Definiciones de coste y esfuerzo

El coste y el esfuerzo son atributos propios del proceso de desarrollo del

4.2. Los principales modelos

Los modelos matemáticos más importante en la estimación del coste y esfuerzo

El modelo COCOMO permite la estimación del esfuerzo como una medida

El modelo COCOMO se basa en la existencia de tres niveles que han de

Modelo básico. Se utiliza al principio del proyecto. La información que facilita

E = a (KLOC)' Ecuación 2.1

Donde E es el esfuerzo expresado en personas-mes, el número de líneas de

Tabla 2.1. COCOMO básico.

Los posibles modos son:

Orgánico. Equipos pequeños de trabajo. Existe un buen conocimiento de la

Semiacoplado. Se sitúan en una posición media en cuanto a complejidad y

Integrado. Sistema hardwareisoftware complejo con influencia clara de la

Modelo intermedio. Se aplica cuando el proyecto ha sido dividido en

En este caso la ecuación es:

E = a (KLDC)~~(X) Ecuación 2.3

Donde E, KLOC, a y b tienen el mismo significado que en el caso del

1. Atributos del producto.

Tabla 2.2. COCOMO intermedio.

COCOMO detallado. El modelo de COCOMO detallado se basa en dividir el

1. Identificar el "modo" de desarrollo para el nuevo proyecto.

El modelo COCOMO posee un claro inconveniente al involucrar la evaluación

El modelo de Putnam, Slim, se apoya en que la distribución del esfuerzo en un