Una posición es que los tipos de escala debieran ser usados para proscribir el uso de estadísticas inapropiadas. La concepción de este enfoque es que las estadísticas deberían permanecer invariantes respecto de las transformaciones admisibles para el tipo de escala.
Stevens [STE62, STE68] define dos tipos de invariancia:
(a) en valor, donde el valor de la medida no varía luego de las trans- formaciones admisibles
MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—13
(b) de referencia donde el valor del estadístico puede cambiar, pero si- gue refiriendo al mismo elemento; por ejemplo la mediana refiere al mismo elemento ocupando la posición central.
El resultado se resume en la Tabla II-2.
Tipo de Escala Estadísticas Apropiadas Tipo de Estadísticas Apropiadas
Nominal Moda Frecuencia Coeficiente de Contingencia Ordinal Mediana Tau de Kendall Ro de Spearman Estadísticas no paramétricas
Intervalo Media Aritmética
Correlación de Pearson
Proporción Media Geométrica
Coeficiente de Variación
Estadísticas paramétricas y no paramé- tricas
Tabla II-2 Estadísticos apropiados según tipo de escala
Esto genera varios problemas. En primer lugar es discutible que los estadísticos no paramétricos no hagan uso más que del orden, algunos como la prueba de los signos de diferencias emparejadas de Wilcoxon calculan diferencias. Segundo, es extremadamente difícil determinar el tipo de escala de una medida [BRI95b].
II.C.2 CONCLUSIONES SOBRE TEORÍA DE LA MEDICIÓN
Los conceptos anteriormente presentados deben ser cuidadosamente analizados. La ingeniería de software se aproxima más a las llamadas ciencias blandas que a las duras. Esto se debe principalmente a las características eminentemente sociales del proceso.
Según Boehm [BOE81], en el análisis de redes existen dos estructuras, la del produc- to y la del proceso. La estructura del producto y su complejidad y algunas características del entorno de desarrollo como la volatilidad de los requisitos y la eficiencia de la organi- zación pueden medirse con prescindencia del juicio experto de forma repetible, objetiva e incluso pasible de ser automatizada.
Estas mediciones, si se impone al proceso ciertas restricciones que disminuyan su va- riabilidad, son, además, útiles como entrada de modelos de estimación de tiempo y esfuer- zo, como ya mostró Nogueira [NOG00] para el desarrollo de sistemas de tiempo real a par- tir de especificaciones formales; resultado que esta tesis extiende al dominio de los siste- mas de información [SAL04a, SAL04b, SAL04c, SAL04d, SAL05].
Dada la madurez actual de la ingeniería de software el excesivo formalismo puede detener nuestro progreso en el conocimiento y comprensión de los procesos [BRI95].
Una métrica puede no cumplir las propiedades formales esperadas y sin embargo ser útil como parte de un modelo empírico [BRI02]. Más aún, la mejor prueba de la validez de una métrica está dada por formar parte de modelos útiles para predecir los valores de va- riables dependientes y no contradecir las observaciones empíricas [JUR01, CAL99, BOE95, CHU99, FEN96].
II.C.3 MÉTRICAS
II.C.3.1OBJETIVOS Y BENEFICIOS DE LA MEDICIÓN EN LA INGENIERÍA DEL SOFTWARE
Zuse [ZUSb] identifica como objetivo principal de la medición en IS tratar de encon- trar respuesta a las siguientes preguntas:
(1) ¿Es posible predecir la propensión a errores de un sistema me- diante medidas disponibles en la fase de diseño?
MODELOS AUTOMATIZABLES DE ESTIMACIÓN MUY TEMPRANA DELTIEMPO Y ESFUERZO DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
II—14
(2) ¿Es posible extraer características cuantitativas de la represen- tación del diseño de un sistema que permitan pronosticar su fa- cilidad de mantenimiento?
(3) ¿Hay alguna característica clave cuantificable del código de un programa que nos permita pronosticar el grado de dificultad de la prueba y el número de errores residuales luego de un deter- minado nivel de prueba?
(4) ¿Es posible extraer características cuantificables de la represen- tación del diseño del software que nos permita pronosticar el es- fuerzo requerido para construir el software descrito por el dise- ño?
(5) ¿Hay alguna característica cuantificable que pueda ser extraída del código de una subrutina que nos pueda ayudar a pronosticar el esfuerzo requerido para probarla?
(6) ¿Hay características que nos permitan predecir el tamaño de un proyecto a partir de la especificación?
(7) ¿Qué propiedades mesurables del diseño son útiles para deter- minar la calidad del diseño?
En el supuesto de que el diseño sea automatizado a partir de la especificación, esta investigación contesta las preguntas (4) y (6).
Usamos métricas de software para derivar bases para las estimaciones, el seguimien- to del progreso, la determinación de la complejidad relativa, comprender cuando hemos alcanzado un cierto estado de calidad, analizar defectos y validar experimentalmente las mejores prácticas.
En la definición de una métrica es importante explicitar el dominio, el recorrido y la regla para establecer la correspondencia.
Este es uno de los problemas fundamentales ya que podríamos estar comparando mé- tricas aparentemente similares, pero que fueron tomadas con diferente criterio. Otro aspec- to importante a tener en cuenta es que las métricas deben cumplir con la condición de re- presentación [FEN96] que establece que deben preservarse las relaciones empíricas. Por
ejemplo el programa a es más complejo que el programa b si y sólo si Complejidad(a) >
Complejidad (b).
Figura II-1 Etapas en la medición formal [FEN96] IDENTIFICAR ATRIBUTOS DE LAS ENTIDADES DEL
MUNDO REAL