Cómo elegir software (II)

El otro día comentaba que para elegir software, o para elegir un coche nuevo, nos fijamos una serie de criterios para luego poder elegir con fundamento.

Cuando uno va a elegir software no se puede fijar en el consumo en ciudad, ni en si tiene o no llantas de aleación. Eso no tiene sentido. Los criterios para elegir software son diferentes que los que usamos para elegir un coche, o para elegir naranjas para zumo. La pregunta clave es, entonces

¿Qué criterios podemos usar para elegir software?

Pues muchísimos, claro. Son tantos que conviene agruparlos en diferentes categorías, para hacer digerible la cosa. A mí me gusta agrupar los criterios en dos categorías principales: criterios funcionales y criterios no funcionales:

Grupo I: Criterios funcionales

En esta categoría ponemos los criterios que tienen que ver con la funcionalidad del software: qué cosas nos permite hacer.

El airscarf, o bufanda de aire. Una funcionalidad "calentita" de los descapotables Mercedes. Yo quiero uno de éstos.

En la analogía con la compra de un coche sería como aquellos "extras" que le pedimos al coche (si tiene llantas de aleación, o aire acondicionado, o elevalunas eléctricos).

Por ejemplo, si el software a elegir es una "tienda online" uno de los criterios podría ser si soporta que los productos tengan precio en diferentes divisas (de modo que puedan visitarla personas que pagan en dólares, en euros o en yenes), o si permite incluir fotos "con zoom" de los productos que quiero vender (para que los potenciales compradores puedan ver de cerca el producto), o si tiene integrado un sistema para pagos con tarjeta de crédito o PayPal (que acepte Visa y Mastercard, por ejemplo), o si permite a los usuarios hacer comentarios sobre el producto, por ejemplo.

Enumerar los criterios funcionales es muy complicado, porque hay tantos como "extras" tiene un coche. Lo que sí es posible es hacer listas de los criterios funcionales más frecuentes para una familia de productos software: para plataformas de blogging, o para tiendas virtuales, o para compiladores, o para lenguajes de programación, por poner ejemplos.

Hay muchas páginas web por ahí adelante que tienen comparativas entre productos software, y la mayoría de estas páginas web se centran principalmente en los criterios funcionales, a veces ignorando completamente los criterios no funcionales. Por ejemplo, si está buscando una tienda virtual aquí hay una extensa comparativa de muchos productos.

Las comparativas de criterios funcionales que hay en la web pueden servir de punto de partida para elegir software, con las precauciones obvias de todas las comparativas web, comprobando que lo que dicen es realmente cierto: ¡hay mucho listo suelto que paga por salir guapo en la foto!.

Quizá lo más interesante de estas comparativas es que nos dan "ideas" sobre qué funcionalidades podemos pedir a nuestro software. Es como echarle un vistazo a los folletos publicitarios de los concesionarios de coches: uno se da cuenta que una marca ofrece un "extra" determinado (que la radio tenga Bluetooth, por ejemplo) y entonces utiliza esta información para comprobar si el resto de marcas ofrecen este extra o no.

Es decir: el folleto de un producto de software nos puede servir de fuente de información para hacernos un inventario de criterios funcionales para nuestra comparativa.

Grupo II: Criterios no funcionales

Euro NCAP

Cuatro modelos de vehículo pasando las pruebas estándar Euro NCAP para medir el criterio no funcional "seguridad". Vaya tortazo.

Además de los criterios funcionales hay también un conjunto de criterios no funcionales, que son muy importantes porque afectan directamente al coste del software. Como con los coches, estos criterios no funcionales nos sirven de indicadores de cómo va a evolucionar y a comportarse el software una vez en marcha.

Si estamos eligiendo un coche, por ejemplo, los criterios de "consumo en ciudad", "coste de los recambios", "averías frecuentes", "red de talleres" o "seguridad" serían criterios no funcionales.

Para el software se usan criterios equivalentes: la "escalabilidad", la "facilidad de adaptación a nuevas funcionalidades", el "tiempo de respuesta", o "la seguridad" son algunos criterios no funcionales del software y, sí, como con los coches, son indicadores importantes de cómo va a evolucionar el coste del software a lo largo del tiempo.

Como con los coches hay muchos criterios no funcionales que conviene conocer si uno va a elegir software de forma eficaz. La lista es tan grande, que lo vamos a dejar para una próxima entrada en el blog.

Pruebas de criterios no funcionales

Al igual con los coches, los criterios no funcionales para el software tienen que evaluarse generalmente con pruebas específicas para cada producto.

Los coches europeos, por ejemplo, pasan esta serie de pruebas de seguridad EuroNCAP y cada modelo de coche (el Ford EcoSport, por ejemplo) tiene una puntuación Euro NCAP determinada, que nos permite comparar diferentes modelos de coches atendiendo a este criterio. El consumo en ciudad se mide con el "New European Driving Cycle", un circuito específico que deben pasar todos los vehículos y que permite calcular cuánto van a consumir en ciudad.

Con el software, por el contrario, no hay tantos organismos que establezcan estándares para criterios no funcionales. El Transaction Processing Performance Council quizá sea la excepción: es una asociación de fabricantes de software y hardware (éstos, exactamente) que hace unas pruebas "estándares" para comprobar el rendimiento de diferentes tipos de software, y que publica los resultados online. Lamentablemente las pruebas son caras, y sólo "los grandes" se animan a pasarlas tras haber "tuneado" sus sistemas a conciencia.

Las cosas, sin embargo, parecen estar cambiando en lo referente a la valoración de los criterios no funcionales del software, y se ve en el horizonte la necesidad de establecer sistemas de medida de éstos. A principios de 2013 la asociación IFPUG (International Function Point Users Group) presentaba SNAP, un proceso para auditar los criterios no funcionales del software (Software Non-Functional Assessment Process).

Mientras no haya procesos estándar de medida de criterios no funcionales para el software no nos queda más remedio que hacernos nuestros propios "Euro NCAP" para software, o nuestros propios "circuitos de consumo para ciudad", o nuestras "pruebas de disponibilidad", o de "escalabilidad", y hacer pasar a los diferentes productos software por éstas para ver cómo se comportan no-funcionalmente durante las pruebas. Una verdadera lata, desde luego, pero una lata que compensa a la larga si somos capaces de reducir los costes operativos del software en producción.

Otro día comento sobre circuitos de pruebas para evaluar los criterios no funcionales. Por hoy creo que llega, ¿no?