La Ingeniería del Software (I). Requisitos

Les propongo un viaje. En muchas ocasiones he comentado la importancia de contar en la informática con principios sólidos de ingeniería, pero esta afirmación es terriblemente abstracta, y he pensado (¡sí!) que tal vez sea conveniente concretarla... La rama de la informática que se encarga de estos asuntos se conoce como "Ingeniería del Software", y para que se hagan una idea de su magnitud, en algunos países es una carrera aparte de la Ingeniería Informática convencional...

Todos usamos programas informáticos, pero realmente pocos usuarios son conscientes de los complicados procesos de diseño que rigen el desarrollo de aplicaciones. Y, ¿qué mejor forma que aprenderlo a través de un ejemplo?

A lo largo de las siguientes entregas vamos a ir viendo cómo se construye desde cero, y haciendo las cosas bien, un programa que sume dos números que el usuario le proporcione. Es decir, el usuario le dirá algo así como "5 + 5", y él responderá "10". Hacer un análisis tan complejo para una aplicación tan sencilla es como matar moscas con bombas de hidrógeno, pero es la forma perfecta de comprender los procesos ingenieriles en la informática.

Y de paso, ayudaremos a alguien que llegó a SF hace no mucho tiempo en busca de un programa para sumar dos números orientado a objetos... :-P

Lo primero que necesitamos es un "proceso", que viene a ser una metodología (abusando del lenguaje) o unos pasos que vamos a seguir para llevar a cabo nuestro programa. Hay varios modelos de proceso, y normalmente las organizaciones tienen "su proceso" y lo utilizan siempre, para seguir siempre unos pasos sistemáticos en la construcción de su software. Vamos a emplear una adaptación del llamado Proceso Unificado (UP), que es el más utilizado en los últimos tiempos y que propone una serie de pasos que seguiremos hasta lograr nuestro programa que sea capaz de sumar dos números.

El primer paso es evaluar los requisitos y los objetivos. Para eso se suelen rellenar unas plantillas, con la idea de mantener un listado coherente y organizado de lo que queremos (el "qué"). En este caso, podría ser: "Objetivo del programa: Sumar dos números"

Lo cual formalizado con una plantilla quedaría:

Estas plantillas constituyen un avance muy interesante, que debemos a dos autores españoles: Amador Durán y Beatriz Bernárdez, de la Universidad de Sevilla, que las describen en su Metodología para la Elicitación de Requisitos de Sistemas Software. Por algún misterioso motivo, son habitualmente denominadas "plantillas de Durán y Bernárdez". Qué cosas.

Para establecer las funciones que debe proporcionar la aplicación debemos elaborar generalmente un modelo de casos de uso, que es un resumen de "lo que se podrá hacer" con nuestro programa. Así, un cajero automático tendría estos casos de uso "sacar dinero", "ingresar dinero", "consultar saldo", y los que se nos ocurran.

Los casos de uso representan posibles escenarios de uso del programa, y contribuyen a concentrar el esfuerzo en torno a las funciones exactas del programa, al tiempo que facilitan establecer los requisitos que debe reunir nuestra aplicación. Para nuestro caso, sólo hay un caso de uso (que traducción más horrible, por cierto) que sería “sumar dos números”.

Respecto a los sistemas existen lo que llamamos actores. Los actores representan entidades que interactúan con el sistema. Por ejemplo, en el cajero un actor sería el cliente. En nuestro caso, sólo vamos a tener un actor: el usuario que proporcione dos números para que sean sumados. Lo vamos a llamar "usuario" a secas. Y para él vamos a rellenar también una plantilla como la que sigue:

Una vez hemos definido los actores y los casos de uso, podemos dibujar un diagrama de casos de uso, que sería una cosa así:

Tal vez les parezca algo ridículo, pero eso es porque no han visto un diagrama con cincuenta casos de usos, con relaciones de extensión, inclusión... en cualquier caso, y por muy complejo que sea un diagrama de casos de uso, siempre simplificará en gran medida la especificación de los requisitos del sistema que diseñemos.

Ahora se trata de concretar qué hacen los casos de uso. Aquí hay que ser bastante sistemático, pero el trabajo que realicemos ahora redundará en una mejora de la implementación posterior. Como sólo tenemos uno, nos quedará una bonita plantilla como ésta:

El "modelo de casos de uso" resultante del diagrama y la descripción de los escenarios da lugar a una descripción exacta y concisa de los requisitos de nuestra aplicación. Ya sabemos qué queremos hacer. En las siguientes entregas veremos cómo lo hacemos.