"Expedición software", al límite de lo posible

Comenzó como muchos montañeros, ascendiendo a cumbres o haciendo rutas de montaña cuando era un chaval. Pero su espíritu aventurero era fuerte y le arrastró más lejos y más alto. Necesitaba más y cada vez se fue embarcando en empresas de mayor tamaño. Al final, esa manera de hacer las cosas se ha convertido para él en una forma de vida y, por ello, sus proyectos se han hecho más atrayentes, más exóticos y más arriesgados.

En la actualidad sus expediciones habitualmente son extensas rutas invernales y en solitario. Así que, después de las Navidades, suele partir hacia destinos cercanos al extremo norte del globo terráqueo. O hacia el extremo sur, si es verano. Por ejemplo, una de ellas fue alcanzar Cabo Norte, partiendo en pleno mes de enero desde una pequeña ciudad al norte de Suecia. Su intención era recorrer unos 1000 km en solitario tirando de una pulka, un trineo donde transportar todos sus enseres, hasta alcanzar el punto más septentrional de Europa. Alcanzó su meta después de una larga travesía a pie y a pesar de que la última etapa de pocos kilómetros le costara varios días de lucha contra un viento que le impedía avanzar. En su web podéis ver algunas fotos de las expedición Ártico Invernal.

Tener éxito en una empresa de esta envergadura desde luego requiere la valoración de todas las necesidades que van a ir surgiendo mientras ésta se lleva a cabo. Desde las más fundamentales como disponer de comida o agua potable en medio de un desierto helado, hasta las más remotas, como saber si en la ruta puede haber animales salvajes. Hay que contar con la mayor cantidad de información posible para poder solventarlas cuando éstas se planteen. De esta forma también se puede planificar cuáles serán las etapas del viaje, qué esfuerzo puede suponer cada una de ellas y qué riesgos implican.

La forma en que deberíamos actuar no es muy diferente cuando emprendemos un viaje en el mundo del software. Básicamente es una expedición para obtener un producto final funcional, de calidad y que se ajusta a lo solicitado por el cliente. Con ese objetivo, no es suficiente tener sólo una clara idea del resultado esperado. Tenemos que tener en cuenta cada una de las etapas y todo lo necesario para cubrirla con el menor número de incidencias posibles. Igual que nuestro expedicionario que no sólo se plantea alcanzar el final de su ruta.

La valoración pormenorizada de un proyecto mediante una especificación de requisitos de calidad es clave, no ya sólo para alcanzar con éxito esa meta final - el producto que los stakeholders necesitan - sino también para hacer que ese producto tenga mayor calidad y cubra en mayor medida las expectativas solicitadas. La labor del analista será la de sondear las problemáticas del cliente a las que tenemos que dar solución y plasmarlas en un producto backlog o en un documento funcional con una serie de puntos o pasos clave durante el proceso:

• Habitualmente la problemática planteada será un conjunto de necesidades que vamos identificando y describiendo en forma de requisitos, y que plasmamos en el documento. Identificar de la forma más completa posible qué hará el sistema, cuáles son todas las necesidades y cómo transformarlas en requisitos, es el primer paso del proceso de análisis.
• Organizar esos requisitos de forma estructurada, estableciendo prioridades entre ellos, y validar con el cliente que todas sus especificaciones están recogidas y priorizadas correctamente, es el siguiente paso. Cada necesidad planteada por el cliente tiene un peso concreto para él y debemos tenerlo en cuenta, por ejemplo, a la hora de determinar qué etapas del desarrollo realizar antes o después.

Partiendo de toda esta información organizada y estructurada, el análisis y la especificación de los requisitos nos van a permitir definir las funcionalidades que cubren correctamente esas necesidades. Es a partir de este punto donde se revela una de las grandes fortalezas del proceso de análisis, que nos permite visualizar cómo se va a comportar el producto en desarrollo antes de ser implementado y saber qué va a dar respuesta a las especificaciones del usuario final. Esto nos aporta numerosas ventajas:

• Por ejemplo, en muchos casos, a pesar de que el cliente conoce su negocio, contar con una visión estructurada del problema en el documento funcional aporta una nueva visión enriquecedora, permite que podamos ofrecer soluciones más útiles que las que podríamos obtener teniendo únicamente una perspectiva general.
• Además, el trabajo realizado con los requisitos del sistema en desarrollo nos facilita la identificación, con mayor antelación, de problemáticas en la ejecución del proyecto. De esta manera, podemos solventarlas ya desde las etapas tempranas del desarrollo o al menos encontrar una forma de evitar riesgos antes de que lleguen a presentarse. Podemos determinar las acciones preventivas antes de toparnos con el problema.
• Aun teniendo todo bien planificado en el transcurso del proyecto, es fácil que surjan imprevistos de todo tipo. Por ejemplo, cambian las prioridades del cliente respecto de las especificaciones del producto a desarrollar. Contar con la información estructurada de los requisitos y de las funcionalidades es fundamental para poder identificar los puntos sobre los que va a incidir ese cambio o conocer el punto más adecuado para realizarlo. La capacidad para absorber cambios, al menos minimizando el impacto que puedan causar sobre la totalidad del sistema, es una de las grandes fortalezas que aporta el análisis funcional.
• Otro valor añadido es facilitar un canal de comunicación entre todos los participantes del proceso. Desde el punto de vista de los conceptos que manejamos dentro de un proyecto, estos van a quedar definidos en el documento funcional y van a permitir compartir un lenguaje común entre el equipo de desarrollo y los stakeholders. No siempre es lo mismo para todos un "interviniente", un estado “en expediente” o un "subproyecto", por poner algunos ejemplos.
• Además, la labor de identificar las funcionalidades a implementar aporta otro beneficio importante ya que nos permite diseñar pruebas de cobertura para ellas. Tener identificadas las circunstancias en que será posible o no ejecutar una funcionalidad, o saber de qué modo va a comportarse, nos permite crear una batería de casos de prueba con los que verificar, con mayor grado de fiabilidad, si la implementación se ajusta a la funcionalidad demandada por el cliente.

Con todo ello, incluir un proceso de análisis funcional dentro de un proyecto de creación de un nuevo producto software siempre genera una suma de beneficios. Es la forma de garantizar que alcanzamos nuestra meta, entregar un producto con mayor probabilidad de éxito. Al permitirnos planificar con una visión más clara y global nuestro objetivo, también nos permite alcanzarlo con menor esfuerzo y con un resultado final más cercano a las especificaciones y con menor nivel de riesgos.

Sin duda, mi amigo expedicionario nunca se plantearía emprender una de sus aventuras únicamente con unas buenas botas y una chaqueta abrigada. Y más, si su intención es llegar hasta el final de la ruta y volver de una pieza. Tratar de abordar un proyecto software de cierta complejidad, sin el respaldo de una fase de análisis del sistema a implementar, es cuanto menos arriesgado. La manera de asegurarnos que vamos a llegar más lejos, alcanzando el objetivo y regresando intactos, pasa por evaluar a qué nos enfrentamos y cómo solucionarlo antes de dar los primeros pasos hacia la meta.

Hay una frase que resume muy bien lo anterior y que me llegó también de un montañero: "No llega más lejos quien más arriesga. Llega más lejos quien más asegura".