Supongamos que hemos estado trabajando toda la tarde con nuestra aplicación software favorita y es el momento de guardar nuestros últimos cambios. Pulsamos guardar, pero la aplicación falla y no responde como debería. Nuestro pulso se acelera y nuestra tensión se dispara. Nuestras pupilas se dilatan y nuestro rostro cambia a una expresión más seria y fría.
¿Se habrán guardado los últimos cambios?
¿Se habrán corrompido nuestro trabajo?
¿Podremos recuperarlo?
¿Te es familiar este escenario?
En esta entrada vamos a desentrañar uno de los misterios más sonados de nuestro tiempo: por qué las aplicaciones software fallan.
¿Qué es el software?
Vamos a comenzar explicando un poco lo que es el software. El software no es más que un conjunto de instrucciones muy sencillas junto con unos datos iniciales. Decimos que estas instrucciones han de ser sencillas puesto que las ejecuta una máquina (el procesador) y ésta no entiende dobles sentidos, ironía, sarcasmo, etc. Sólo entiende órdenes simples y claras, como 2 + 5.
Podemos ver el software como una receta de cocina. Por ejemplo, la receta de una paella. La paella necesita arroz, marisco y muchos otros ingredientes que se han de preparar por separado y mezclar en el momento justo mientras poco a poco se va cocinando la paella. No mezclar los ingredientes en el orden correcto o no cumplir con los tiempos de cocción harán que la paella no se pueda comer.
Luego, podemos decir que la paella va pasando por distintos estados durante su cocinado y en cada estado se le añaden unos ingredientes en una cantidad determinada. Por lo tanto, la paella va cambiando de estado.
¿Cómo se hace?
Antiguamente los desarrolladores se comunicaban de tú a tú con el procesador escribiendo en ceros y unos, pero esos tiempos pasaron y ahora escribimos en lenguajes artificiales que se traducen a ceros y unos de forma automática por otros programas.
Estos lenguajes se conocen como lenguajes de programación y hay multitud de ellos en función del ámbito de uso. Por ejemplo, en intelligenia, usamos Python y PHP para el desarrollo de aplicaciones web.
Los desarrolladores se han aprendido la sintaxis de estos lenguajes y son capaces de expresar las instrucciones en lo que se conoce como código fuente que no es más que textos escritos en estos lenguajes.
Los estados del software
Decimos que la paella va cambiando de estado en función de los pasos y el software también, sólo que mientras los estados en un plato de comida son pocos. En cambio, los estados en el software suelen ser muchos. Vamos a poner un ejemplo.
Los estados normalmente se expresan como conjuntos de variables lógicas relacionadas entre sí. ¿Qué es una variable lógica? Un enunciado que puede ser verdad o mentira. Por ejemplo: "ayer fui al gimnasio", "me gusta hacer deporte los fines de semana" o "ayer vi la película de El mago de Oz".
Estos enunciados se pueden relacionar mediante operadores Y, O y NO. Normalmente cada una de estas variables lógicas se nombra con una letra. Por lo tanto supongamos la siguiente situación:
C = "ayer fui al cine"
M = "ayer vi la película de El mago de Oz"
Podemos crear una expresión lógica con estas dos variables diciendo que ayer fui al cine pero no vi la película de El mago de Oz. Esto es: C Y NO M.
De esta forma, tendremos tantos estados como posibles combinaciones de variables tengamos. Volviendo a un ejemplo un poco más real, supongamos el software de un ascensor de un edificio de una planta con las variables:
isGround: el ascensor está en la planta baja.
isFirstFloor: el ascensor está en la planta superior.
isGoingDown: el ascensor está bajando.
isGoingUp: el ascensor está subiendo.
isStopped: el ascensor está parado.
Si expresamos las relaciones entre las distintas variables con un diagrama en el que las flechas punteadas simbolizan el camino a tomar si dicha variable es falsa y las flechas continuas simbolizan el camino a tomar si la variable es verdadera, nos encontramos con el siguiente grafo:
Por ejemplo, si el ascensor no está en la planta de abajo y no está en la primera planta el ascensor está en un estado ilegal o inconsistente. De ahí que llegue al nodo con el texto "false" (falso en inglés).
En cambio, si el ascensor no está en la planta de abajo, está en la primera y no está bajando sino que está parado, el ascensor se encuentra en un estado legal o consistente. Por eso está marcado dicho nodo con "true" (verdadero en inglés).
Como se puede ver, el sistema es algo complejo de seguir. De hecho, aunque la representación ayuda, habría que probar que todos los posibles caminos que llevan a "true" sean efectivamente estados correctos del ascensor.
El problema del estado
El ejemplo anterior, si bien era un poco difícil de entender, podía comprobarse el resultado de cada uno de los estados en función de sus variables de forma manual en pocos minutos.
En cambio, supongamos este ejemplo real de 17 variables y 10 reglas. Con este número no muy alto de variables y reglas, obtenemos un grafo de estados de 97 vértices que es imposible de verificar manualmente en un plazo de tiempo corto.
Nosotros a diario trabajamos con sistemas de este nivel de complejidad, por lo que es relativamente sencillo dejar que el software alcance estados inconsistentes.
El software evoluciona
Además de estas limitaciones, debemos de tener en cuenta que los estados no están bien definidos. ¿A qué nos referimos con esto? Nos referimos simplemente a que el software evoluciona porque el negocio cambia y si el software no cambia, se queda obsoleto.
Lo que antes era de una determinada forma, ahora es de otra y dada la cantidad de relaciones entre las variables, un pequeño cambio puede afectar a todo el sistema. No revisar el sistema al completo puede tener un efecto similar al de quitar una carta en un castillo de naipes.
Es mucho más importante poder adaptarse a las necesidades de los usuarios que tener un software 100% libre de fallos, ya que los usuarios demandan funcionalidad y (hasta cierto punto) están dispuestos a aceptar una tasa de fallos razonable.
Así, no sólo nos enfrentamos a un problema complejo, sino también cambiante.
¿Hay solución a estos problemas?
Puede parecer que este problema ha sido resuelto con éxito por grandes industrias que hacen uso del software, como los bancos, pero a tenor de la última noticia de la congelación de más de 600000 pagos por un error de software en el Royal Bank of Scotland no es así.
Hay algunos métodos que tratan de paliar esto como son:
- Las pruebas: si probamos los caminos más comunes, podemos asegurarnos que nuestro software funcione en la mayoría de las ocasiones.
- Los métodos formales: basados en la demostración matemática de la consistencia del código desarrollado.
Normalmente, los métodos formales se dejan para software crítico que tiene vidas humanas a su cargo (transportes, transacciones bancarias, centrales térmicas, dispositivos médicos...).
Conclusión
¿Es posible hacer software sin errores? Sí, pero es tan costoso que su uso se reduce a sectores críticos y no a sistemas del día a día. Por lo general se hace uso de pruebas intensivas para certificar que (con un porcentaje de acierto medianamente elevado) no hay fallos. Aun así, los fallos pueden aparecer.
¿He de temer las consecuencias de un fallo software? No. Por lo general los sistemas críticos son tolerantes a fallos o tienen sistemas de respaldo. El caso del Royal Bank of Scotland es un caso aislado.
No hay comentarios:
Publicar un comentario