Actividad 10. La aplicación de métricas

Métricas de calidad 

La principal intención de la ingeniería del software es mejorar "la calidad de sus productos" para lograr que estos sean competitivos, y así se ajusten a los requerimientos establecidos por el cliente (usuarios finales).

Actualmente se ha incrementado la conciencia de que los programas de aplicación interactiva deberían ser más confiables para los usuarios. Este modelo de calidad es definido como "la opinión que tiene un usuario al utilizar una aplicación de software", la cual se deriva de los resultados obtenidos al evaluar dicha aplicación.

El objetivo principal de la calidad en uso es proporcionar al usuario final de un producto de software "una garantía de los requisitos necesarios para su óptima utilización" (específicamente en aplicaciones web). El modelo de calidad en uso es una reciente incorporación en el estándar ISO/IEC 9126, el cual incorpora métricas de la calidad en uso a aplicar en una evaluación.

El estándar ISO/IEC 9126 es un documento para la calidad del software que ha sido definido por una comunidad internacional mayoritaria, donde cada vez más países se integran a su estandarización. Este estándar define un modelo de calidad mediante tres aspectos: calidad interna, calidad externa y calidad en uso.

Los aspectos de calidad interna y externa son muy similares.

Ambos cuentan con un modelo de tres capas (niveles) compuesto de características, subcaracterísticas y métricas. Por supuesto, las métricas asociadas difieren de la calidad interna y externa. La mayor diferencia con la primera representación de ISO/IEC 9126 es la introducción de la propuesta de las métricas para medir cada subcaracterística, y la integración del conjunto de métricas (internas y externas) está asociada a la calidad en uso.

La definición de la calidad en uso de acuerdo al ISO/IEC91261 es "la capacidad de un producto de software de facilitar a usuarios específicos alcanzar metas especificas con efectividad, productividad, seguridad y satisfacción en un contexto de uso especifico".

Métricas de tamaño

El tamaño del SW podría medirse en términos de los bytes que ocupa en el disco, el número de programas, el número de líneas de código, la funcionalidad que proporciona, o simplemente el número de pantallas o reportes que tiene.

 Boletín de Política Informática Núm. 6, 2003 42A simple vista podríamos intuir que algunas de estas propuestas son mejores que otras si queremos medir el tamaño de una forma que tenga más correlación con el esfuerzo. Pero antes de seleccionar alguna, hagamos otras consideraciones. Una aplicación de software es un conjunto de líneas de código que se ejecutan en una computadora.

 Sin embargo mucho del costo de producir ese SW no está directamente relacionado con la codificación, que es entre el 20 y 25% del costo total. Elementos como la administración del proyecto, el nivel de detalle de la documentación técnica o la documentación de pruebas, y las pruebas por sí mismas también deben considerarse. 

Por otro lado, hoy en día hay una amplia gama de lenguajes y herramientas para producir SW, lo que ha provocado que pueda generarse la misma funcionalidad con lenguajes de programación distintos. Y esto con un número de líneas de código distintos y, lo que es más impactante, con un esfuerzo distinto.

 Veamos un poco más a detalle las implicaciones del enunciado anterior mediante un ejemplo sencillo. Supongamos que yo requiero de cierta funcionalidad en una aplicación de SW y tengo la opción de hacerlo con dos empresas. La empresa A utiliza un lenguaje que requeriría 8 mil líneas de código. 

La empresa B utiliza otro lenguaje que requeriría aproximadamente 5 mil líneas de código. A simple vista parecería que con la empresa A tendría “más” trabajo, pero con la empresa B me podría salir más barato, dado que tienen que hacer menos líneas de código. La comparación se complica si los programadores de ambas empresas producen a distintas velocidades. Es decir, los de la compañía A producen casi el doble de código por día que los de la compañía B. 

Como resultado de lo anterior, tendría que la línea de código de la empresa A podría costar mucho menos que la de la compañía B. Entonces parecería que debería comprarle a la empresa A dado que cuesta menos cada línea de código, pero también podría comprarle a la empresa B dado que tiene que producir menos líneas de código, y por lo tanto el costo total sería menor o podría tener menos posibilidad de errores. 

Ciertamente esta secuencia de análisis puede ser engañosa. Si retomamos los conceptos mencionados previamente, entonces una mejor métrica para establecer el tamaño es la basada en los requerimientos del usuario y no en la tecnología que se va a utilizar; una métrica basada en la funcionalidad. 

Métricas por producto

Las métricas de proceso de software se emplean para fines estratégicos, y las métricas del proyecto de software son tácticas, éstas últimas van a permitir proporcionar al desarrollado de proyectos del software una evaluación al proyecto que sigue en continuo desarrollo, equivalentemente podrá ver los defectos que logren provocar riesgos a largo plazo (áreas problema); y observar si el área de trabajo (equipo) y las distintas tareas se ajustarán. 

Existe una preocupación en la unificación de las métricas dentro del proceso del software, dado que los des arrolladores mexicanos de software no tienen la cultura de la medición. 

Es por eso que el uso de métricas demanda un cambio cultural, tanto en el recopilado de datos (investigación histórica), como en el cálculo de métricas (LDC, PF, métricas de calidad y orientadas a objetos) y asimismo en la evaluación (resultados obtenido), para poder comenzar un 14 programa de bases de métricas y justamente obtener una guía, asimismo una base de datos tanto de los procesos como de los productos y de este modo adquirir una visión más profunda de lo que se está elaborando.

Las métricas de software nos aportan una manera de estimar la calidad de los atributos internos del producto, permitiendo así al ingeniero de software valorar la calidad antes de construir el producto, así el tiempo invertido será identificando, examinando y administrando el riesgo, este esfuerzo merece la pena por muchas razones ya que habrá disminución de disturbios durante el proyecto, asimismo se podrá desarrollar una habilidad de seguir y controlar el proyecto y se alcanzará la seguridad que da planificar los problemas antes de que ocurran, además conseguiremos absorber una cantidad significativa del esfuerzo en la planificación del proyecto.

Del mismo modo existen diferentes tipos de métricas para poder evaluar, mejorar y clasificar al software desde sus inicios hasta el producto final, de las cuales se verán en los siguientes capítulos.

Métricas por costo

Antes de ilustrar los puntos de controversia defendidos por Eliyahu Goldratt y su teoría de restricciones, es necesario hacer referencia a aquellos supuestos base de la técnica contable.

• Los costos directos (materias primas y mano de obra directa) son la mayor parte de los costos totales en los que se incurre en la fabricación de un producto.
• Es importante contar con la capacidad de asignar los diferentes costos en los que se incurre entre diversos productos y líneas de productos para saber si son rentables, si vale la pena continuar con ellos o para detectar que deben tomarse acciones correctivas.
• Por lo tanto, los costos indirectos de fabricación (overhead) se pueden asignar de alguna manera en proporción con los directos (casi siempre con la mano de obra), dado que en general su tamaño es relativamente pequeño.

La contabilidad de costos tradicional es hija de la revolución industrial, es decir, sus principios y costumbres se remontan a comienzos del siglo XX o más atrás. Evidentemente, mucho ha cambiado la forma de hacer negocios desde esa época hasta nuestros días.

• Supuesto 1. Muchas empresas han ido prescindiendo cada vez más de instalaciones fabriles propias, optando por la subcontratación y la maquila, esquemas en los cuales estos costos que se consideraban directos se convierten en gastos o en pagos por servicios prestados.

Además, los componentes de diseño y servicio a los clientes se han convertido cada vez más en factores determinantes de la competitividad de las empresas.

Esto ha conducido a la desaparición de la infraestructura fabril en empresas cuyo atractivo está en el diseño, ya que posteriormente contratan la fabricación con otras compañías.

• Supuestos 2 y 3. La teoría de restricciones insiste en la variabilidad de los procesos, por lo que no acepta los promedios como estándar de producción de una planta. Los sistemas de costos basados en estándares están destinados a incorporar los parámetros de variabilidad de proceso que menciona TOC.

Por otra parte, los procesos de asignación de costos sin importar la técnica que se use, son una respuesta equivocada a un problema, que no necesariamente es el centro de la discusión, la determinación del costo unitario de los productos. La teoría de restricciones (TOC) incorpora los costos directos en el cálculo de un indicador que se denominaráthroughput, sin embargo, no exige que la empresa intente hacer directos los costos que definitivamente no lo son.