La importancia de los datos

Reza una frase bastante famosa: Lo que no se define no se puede medir. Lo que no se mide, no se puede mejorar. Lo que no se mejora, se degrada siempre [1].

Los números son tan importantes en la Ingeniería de Software como para cualquier otra disciplina y en la Arquitectura pueden ser usados para soportar todas las decisiones. Pero ¿Cómo lograr obtener datos numéricos? y ¿Cómo usarlos para tomar decisiones y soportar los diseños o las estrategias seleccionadas? Pues esta es la ciencia.

Podemos decir que este enfoque consta de un laboratorio de experimentación para la construcción de prototipos que cumplan ciertas características bajo un escenario de calidad dado y que pueda ser proyectado a un escenario real usando el conocimiento del ambiente para el cual la Arquitectura es importante. ¿Muy enredado? Imaginemos cómo se logra el diseño para la construcción de un automóvil o de un edificio.

Generalmente se establece una necesidad, los requisitos, las características funcionales y no funcionales. En el caso del auto,  podría ser por ejemplo, la velocidad máxima esperada, el grado de comodidad reflejado a través de alguna comparación o benchmarking e incluso el precio y el sector socioeconómico al que se espera competir. Si lo consideramos, para el caso de un edificio, el tema es muy similar; el sector, el confort, los metros cuadrados, el máximo número de pisos, las normas legales, etc.

Con base en todas las características recopiladas se comienza un diseño y la construcción de un prototipo. Simulaciones, planos y prototipos, aplican para los ejemplos. He visto las simulaciones de los flujos de aire para lograr diseños aerodinámicos y conseguir mayor aceleración en un automóvil y de carga y estrés en materiales y estructuras para edificios, incluso se diseñan maquetas a escala que logran representar las condiciones en un ambiente real.

Luego del diseño, se inicia la preconstrucción y la puesta en producción. Se obtienen los costos que tomará la implementación, se revisa la viabilidad de las propuestas y finalmente, se planifica la producción. Todo gracias a los datos recolectados y a las pruebas y simulaciones logradas.

Conociendo lo anterior, me preguntaba constantemente de qué modo se deben aplicar esas estrategias a la construcción de software. Es común que se hagan pruebas de carga, por ejemplo, pero ya cuando el desarrollo ha sido terminado, es como hacerle pruebas de resistencia a un edificio cuando ya fue construido o averiguar si un carro es cómodo o no cuando ya fue ensamblado. No tiene sentido, ¿Cierto?

Recordando las fases de construcción de la arquitectura de acuerdo a ACDM y basados en las fases de construcción de cualquier producto a nivel industrial, se coincide en una etapa importante de experimentación y preconstrucción o creación de prototipos.

La experimentación se ejecuta previa a la implementación y es el soporte para garantizar los requerimientos funcionales y no funcionales o atributos de calidad. En la experimentación es correcto hacer pruebas de estrés, de carga, desarrollar prototipos, hacer simulaciones, generar modelos matemáticos y es, a mi parecer, la parte más entretenida de la Arquitectura.

Revisemos a continuación un ejemplo sencillo pero práctico para entender los pasos comunes de la experimentación y el rol de los datos:

Consideremos una aplicación web para la compra de entradas a cine, que durante el proceso requiere el registro de nuevos clientes potenciales. Cuando la compra se realiza, se desea recopilar el feedback de cada cliente que realiza la transacción.

Es común que los requisitos funcionales den información limitada de lo que se necesita y es parte de nuestras habilidades lograr reducir esa incertidumbre basado en los datos. Del enunciado de ejemplo se pueden extraer gran cantidad de dudas y preguntas. Por ejemplo qué información se desea recopilar, cuánto debería durar la operación de registro de feedback, en dónde debería ubicarse la opción o cuál puede ser la reacción de los clientes al observar la solicitud de esos datos. Trataré en posteriores artículos describir cómo recolectar datos para sustentar atributos de calidad en distintos escenarios, pero en este caso y para mantener la simplicidad, usaré el tiempo de respuesta.

Pero, ¿Cuál debería ser un tiempo de respuesta adecuado? Existen varias formas de conocerlo, la más fácil, preguntando directamente al cliente e indagando. Pero la forma más científica, es investigando cómo se comportan los usuarios en el sitio, usando, por ejemplo google analytics o incluso herramientas para la traza de peticiones como awstats [2]. Es útil conocer cuánto tiempo duran los usuarios comprando un tiquete y qué hacen luego de realizar la compra, si siguen navegando o abandonan la página. Reconocer estas características no funcionales, técnicamente conocidas como atributos de calidad, es la analogía a la primera fase en la construcción de los productos que usaba de ejemplo y se hace en la fase de requisitos de ACDM.

Es importante entender que se deben seleccionar con cuidado todos los atributos de calidad que se desean soportar, pues no existe software perfecto y no es posible satisfacer todos los requerimientos no funcionales sin que exista una pérdida de algún otro, el trade off o como alguna vez lo nombró Fred Brooks, no hay balas de plata.

Como resultado de esta etapa, los atributos de calidad deben registrarse a través de métricas que permitan indicar si son o no satisfechos. Digamos que para este caso se encontró, apoyados en los datos recolectados, que los usuarios solo ingresan a la aplicación para comprar los tiquetes y se retiran luego de dar 2 o 3 clics más, lo que les toma aproximadamente de 3 a 5 segundos. Aunque a primera vista lo recolectado no dice mucho, es buen momento para convertir los datos en información. Podríamos suponer que el registro de feedback debe ser tan sencillo, tal que se pueda aprovechar el tiempo adicional que el usuario permanece en la página.

Ejemplo. Registro de métrica en Documento de Arquitectura de Software.

De lo anterior se infiere que el registro de esta información no debe tomar más de 3 segundos, ya que perderíamos el interés de los usuarios. Consideremos por otro lado que el sistema de compras está soportado sobre un ERP y se integra a un CRM a través de servicios web y que el registro de feedback, por alguna razón funcional, requiere conocer el número de compras del cliente para determinar el grado de relevancia que tiene su opinión.

Construir un prototipo en la Ingeniería de Software se traduce como el desarrollo de una aplicación que ejecuta una tarea puntual en un entorno específico, su construcción o reúso depende de los datos que se requieren obtener y de los escenarios de calidad planteados.

La construcción del prototipo se puede acompañar de la simulación de un ambiente tan cercano a la realidad como sea posible, teniendo en cuenta que la exactitud no se logra sin recurrir a gastos excesivos, esta tarea puede apoyarse de herramientas para pruebas de carga, concurrencia y estrés [3]. Es en este punto que se deben identificar los posibles elementos que afecten las métricas planteadas para los atributos de calidad, podríamos construir un prototipo que simule la conexión a un servicio web y obtener como resultado que el tiempo de respuesta entre la solicitud y la transformación de registros toma más de 3 segundos y es acá donde las estrategias y las decisiones arquitecturales toman lugar. ¿Cómo debería solucionarse? Depende del escenario y de las características del sistema, pero en todo caso los experimentos deben soportar la decisión seleccionada y dar datos suficientes para argumentar su implementación, viabilidad y costo.

Los datos son necesarios para inyectar la Ingeniería que requiere la construcción de un producto de software y evitar la prueba y error que puede generar grandes inversiones en mantenimiento y solución de incidencias.

Referencias

[1] http://www.slideshare.net/DavidHerce/lo-que-no-se-mide-no-se-mejora. Posible autor de la frase. 12 de octubre de 2013

[2] http://webdesign.about.com/od/loganalysis/tp/free_web_log_analysis_tools.htm. Listado de las principales herramientas de análisis de tráfico http y log de servidores web. 14 de octubre de 2013.

[3] http://www.itjobswatch.co.uk/contract.aspx?page=1&sortby=0&orderby=0&q=&id=1500&lid=2616. Principales herramientas usadas en Inglaterra para las pruebas al desarrollo de software. 14 de octubre de 2013.