Por qué no sé por qué se te cuelga el Word y por qué no me importa

- Oye coleguita, tú que eres informático, tengo un problemilla con el Word. Se me cuelga.

- Anda, siéntate, voy a contarte una historia.

Todos os sentiréis identificados con la siguiente situación: encendéís vuestro ordenador y las cosas no siempre funcionan como queréis  Estamos hablando de programas que se cuelgan, programas que no llegan a iniciarse: programas que no hacen lo que tienen que hacer.

Aquí lo que intento es explicar de manera esencial cuáles son los motivos que en el ámbito software sucedan estas cosas. Con esto no quiero decir que la Informática sea la única Ingeniería que tenga estos problemas, sólo quiero que después de leer este artículo tengáis algo más claro que el desarrollo de un proyecto software no es sólo ponerse a picar código como un friki.

En general, cualquier proyecto de ingeniería tiene al menos las siguientes fases:

1. Análisis del problema. Se define qué ha de hacerse, qué no y si es viable, entre otras cosas.
2. Diseño de la solución. Se realiza un modelo, sobre el cual es posible verificar ciertas propiedades.
3. Materialización de la solución. El modelo diseñado se traslada a la realidad. También se puede denominar esta fase como construcción o implementación.
4. Prueba. Aunque el modelo cumpla las propiedades, es necesario comprobar su correcto funcionamiento antes de ponerlo en servicio.

Cuando se analiza el problema por resolver, en el caso de una casa, existe una experiencia consensuada de si la construcción del hogar es viable o no, así como de una planificación estimada de la duración de la obra. Es cierto que los proyectos de construcción se retrasan, pero ¿nunca habéis sufrido múltiples retrasos en la salida de un videojuego?

Esencialmente, a no ser que sea una empresa que se dedique a hacer un tipo de software concreto, con cada producto distinto desarrollado el riesgo de que el proyecto de se retrase, cueste más o no llegue a término, aumenta. Por eso las empresas que triunfan son las que se centran en realizar un único tipo de producto o las que son lo bastante grandes como para tener suficiente experiencia en cada gama de productos que realizan.

Otro problema que aparece cuando se trabaja en el desarrollo de poyectos software es tener claro qué es lo que el cliente desea adquirir. Cuando el promotor solicita que se construya una casa, el concepto de casa está claro, al igual que el de un puente o el de un coche (siempre con matices). Debido a la naturaleza intangible y maleable del software (es más fácil añadir una funcionalidad a a una aplicación que ponerle una rueda adicional a un coche una vez construido) es, por una parte, complicado que el cliente deje claro sus requisitos, por lo que hay que extraerlos de manera especial y, además por otra parte, es posible que cambie de idea a posteriori, dejando a los responsables con el culo al aire.

Jocoso gráfico que refleja la problemática

El diseño de la solución plantea una serie de problemas inherentes a la propia teoría de la computación. En general, es imposible verificar de manera automática si un programa cumple una determinada propiedad (estoy mintiendo un poco, pero lo que está claro es que esta verificación formal juega un papel menos importante que en otras disciplinas). Ésto deja a la Ingeniería del Software en una posición de desventaja. Un ingeniero aeronáutico puede con un esfuerzo, probar la resistencia al aire del modelo de su avión. Un Ingeniero de Caminos puede saber si su puente soportará el peso de 2000 camiones. La Informática se ve relegada a darle más importancia a  la  fase de pruebas, las cuales demuestran para un conjunto de valores si el programa funciona correctamente. Por ello sólo garantizan la presencia de errores en el programa, para su posterior corrección, y no la inexistencia de los mismos. ¿No os suena el concepto de parche?

Afortunadamente se ha avanzado mucho para mitigar estos problemas. En cuanto a la planificación existe una serie de entidades (sobre todo en EEUU) que se encargan de estudiar la gestión de proyectos informáticos. La adquisición de requisitos ya supone una disciplina con existencia propia, la Ingeniería de Requisitos, que estudia no sólo como adquirirlos, sino como reutilizarlos y administrarlos. El diseño se ha visto ayudado por la aparición de formalismos, que podrían ser los equivalentes a los "mapas del software". Finalmente las dos últimas fases son las que más se han beneficiado de los avances tecnológicos y, a mi juicio, la complejidad es menor.

Me gustaría concluir el artículo respondiendo a la pregunta que tiene título la entrada:

Estimado coleguita, 

no sé por qué se te cuelga el Word ni me importa. No conozco todos los detalles que han forzado a que suceda esta situación, así que no me lo preguntes. De la misma manera que tu amigo ingeniero industrial no sabe por qué a tu coche no le funciona el limpiaparabrisas o no le preguntas a tu amigo de teleco por qué ya no puedes ver "Sálvame", yo no sé por qué tu programilla no funciona.

Pepe "Puertas de Acero" Pérez