La RAE, sin ir más lejos, no establece claramente esa diferencia:

eficacia: (Del lat. efficacĭa) Capacidad de lograr el efecto que se desea o se espera.

eficiencia: (Del lat. efficientĭa) Capacidad de disponer de alguien o de algo para conseguir un efecto determinado.

No obstante, creo que hay otras definiciones que aclaran mejor la diferencia entre ambos términos.

En Economía, y esto también lo podemos aplicar a la Ingeniería del Software, la eficiencia es la capacidad administrativa de producir el máximo de resultados con el mínimo de recursos, el mínimo de energía y en el mínimo tiempo posible.

Ejemplo:

Matar una mosca de un cañonazo es eficaz, conseguimos el objetivo, pero es poco eficiente pues se gastan recursos desmesurados para la meta buscada. Pero acabar con su vida con un matamoscas, aparte de ser eficaz, es eficiente.

– extraido de la Wikipedia

Para poder determinar la eficiencia de un determinado proceso, por tanto, es necesario medir los recursos, energía (coste) y tiempo necesarios para la producción del resultado esperado.

Medir la eficacia

Pero ¿como se mide la eficacia? Es probable que haya algunos de los efectos deseados sean cualitativos, y no puedan medirse, aunque siempre se puede intentar cuantificar artificialmente esos efectos.

Un ejemplo lo tenemos en las encuestas de satisfacción del cliente. Para medirla se suelen plantear preguntas del tipo: “de 1 a 5 ¿como considera que ha sido el trato recibido, etc.?”. La respuesta suele ser bastante subjetiva y dar resultados distintos en función de a quién preguntemos y cuándo.

Por tanto, aunque básicamente estoy de acuerdo con la afirmación de lo que no se mide no se puede controlar, y por tanto no se puede gestionar, creo que a veces se exagera un poco en lo que a métricas se refiere, lo que también acaba siendo poco eficiente.

The problem with the saying “you can’t manage what you can’t measure” -what makes it a fallacy- is that we manage things we can’t measure all the time. We manage cancer research. We manage software design. We manage all manner of things that are deeply intellectual, even creative, without any idea of what numbers we ought to have to guide us. Good knowledge worker managers tend to measure qualitatively, not quantitatively

– Robert Glass, Addison Wesley (2003)

O parafraseando a Steve McConnell:

Tratar de mejorar la (eficiencia) incrementando la cantidad de (métricas) como intentar perder peso pesándose más a menudo.

Pero volviendo al argumento original. Mantener el control sobre un proceso es bueno, y esto significa:

• Recoger la información que nos permita medir, monitorizar y ajustar el proceso para conseguir el objetivo perseguido.
• Ser capaz de tomar las acciones necesarias, lo antes posible, para garantizar los resultados deseados manteniendo los objetivos de calidad, coste y tiempo.

Tags: Métricas

 Es algo recurrente en mí. Cada año, más o menos, me entra esta ansiedad por encontrar la bola de cristal que me permita saber cuanto tiempo y esfuerzo va a costar construir el sistema A, B o C. Y cada año, tras el peregrinaje de rigor por las páginas, artículos y libros que versan sobre el tema, regreso a casa con la misma frustración.

El “Secreto de la Estimación Objetiva” dice:

Utiliza algún sistema homogéneo para medir el tamaño de un sistema.

¡Já! Empezamos por algo fácil. Es sencillo utilizar un sistema de medida homogéneo cuando las aplicaciones a medir son también homogéneas. Se pueden contar páginas, si se trata de aplicaciones web o, refinándolo más, contar los elementos que las generan (JSPs, ASPs, ficheros HTML, clases, EJBs, o lo que sea), asignándoles incluso un orden de complejidad. Esto nos permite comparar el tamaño de dos aplicaciones (“la aplicación A es el doble de grande que la aplicación “B”).

Pero ¿qué hacer si se trata de medir cosas algo diferentes? Hala! Compárenme una aplicación COBOL/CICS, con sus pantallas, transacciones, y todas sus cositas, con la aplicación web de antes. En este caso cuesta algo más comparar los tamaños de ambas.

Para salvarnos de este aprieto, aparece allá por 1979 (gracias, Allan Albrecht), los Puntos Función. En todos los casos, con algo de práctica, seremos capaces de contar los EO, EI, EQ, ILF, EIF y demás elementos. Aunque al no tratarse de pantallas, programas, rutinas, páginas, clases, etc. sino un nivel de abstracción superior, cuesta algo más de esfuerzo tomar las medidas.

Esto es otra muestra más de que cuando intentamos simplificar algo, como es el homogeneizar la medida de tamaño de sistemas heterogéneos, nos llevamos la complejidad a otra parte. Vamos, que hay que hacer un curso para medir bien con Puntos Función.

Traduce la medida resultante a algo tangible.

Es posible, por tanto, obtener una medida de tamaño de un sistema de software. Eso sí, no se consigue el tamaño en líneas de código, megabytes de los ficheros de código fuente o, lo que es mucho más util, horas de esfuerzo a realizar por un equipo de trabajo con una productividad media (otra variable más).

Para convertir los Adjusted Function Point -que tendremos que calcular a partir de los Unadjusted Function Point considerando los parámetros del entorno del proyecto- en algo útil, habrá que multiplicarlos por un “Número Mágico” que nos dará una aproximación al esfuerzo necesario de desarrollo, es decir, su coste (es decir, su precio).

Para obtener este factor -que, además no es inmutable- es preciso contar con una cierta historia en desarrollo de software. Si se conoce el esfuerzo que resultó necesario y los puntos función de cada uno de los sistemas desarrollados en el pasado, es posible obtener un factor de conversión suficientemente fiable como para ser capaces de predecir lo que costará un sistema nuevo.

Claro que es preciso que los proyectos analizados sean más o menos homogéneos, que no hayan tenido circunstancias excepcionales que desvirtúen la estimación, desarrollados preferiblemente en la misma compañía y entorno, y preferiblemente por el mismo equipo o equipos de cualificaciones semejantes.

Fácil ¿eh?

En resumen, que yo sigo contando pantallas y multiplicando por cincuenta.
Tags: Métricas, Metodología

Hay sin duda aplicaciones, muy sofisticadas, de los que el 80% de los usuarios utilizan sólo un 20% de la funcionalidad. O porcentajes parecidos. Por lo que para las pocas cosas que se utilizan se complica demasiado su uso. Además, el software se llena de errores. Y de ahí nace el concepto.

Un caso paradigmático de esto es el famoso editor de ecuaciones de Microsoft Word. ¿Cuantos habéis utilizado ese editor? Yo, algunas veces, pero muy pocas. Antes era parte del software, ahora es un add-in, o add-on, o complemento, o como se llame.

Siguiendo con el ejemplo: ¿alguien se imagina un tratamiento de textos que no permita cambiar el tipo de letra, la justificación, la corrección ortográfica o la creación automática de índices? Yo no.

Sin embargo, a veces echo de menos un micro-editor en el que pueda fijar qué estilos y cuándo se pueden utilizar, en el que el formato, aspecto y estructura estén previamente determinados y en el que los usuarios no hagan mas que “rellenar” lo que les toca.

Odio que alguien pueda escribir en Comic Sans negrita, color naranja sobre fondo amarillo…

En resumen, lo único que intento decir es que:

Menos es menos pero, a veces, es mejor.

Alejandro André

Tags: Complejidad

Cliente: Quiero descargarme el Internet ¿necesito un disco duro más grande?

Respuesta: Descarga el Intenet aquí.

Tags: Curiosidades

No hables con desconocidos

Esta regla fue formulada en la Northeastern University en 1987 por Ian Holland. Y la explica magistralmente el blog Refactoring.

Es una regla comúnmente aceptada de buen Diseño, que se basa en el mínimo conocimiento del modelo de objetos, de modo que se reduzca el número y complejidad de las interrelaciones.

Aplicado la ley de Demeter a objetos, tendríamos que una operación de un objeto sólo tendría que utilizar:

• Las operaciones propias del objeto.

• Los objetos que tenga asociados o sean atributos del objeto.

• Los objetos que recibe como parámetro la operación.

• Los objetos que cree la operación.

Tags: Metodología, Programación