Mantenimiento de Software y Gestión de Riesgos

Por Montserrat Guardia Güell:  SPIR-IT Program Manager, Technip.

¿Por qué debemos preocuparnos por el mantenimiento y la gestión de riesgos?

Leí vuestra pregunta sobre cómo deben, inicialmente, hacerlo el 80% de los desarrolladores de software. Rápidamente, me imagine una reacción generalizada de estado de alerta. Imagine una activación de adrenalina debida al hecho de plantearse el porqué de una preocupación con las palabras software, mantenimiento, gestión y riesgos. Sobre todo, esta última hace que salten todas las alarmas, y nos preparemos para atacar o para escapar y protegernos.

Sin embargo, es precisamente esta palabra la que debe reducir la tensión. Para ello debemos relacionar las palabras riesgos y tiempo (más precisamente ventanas de tiempo).

Debemos preocuparnos porque, empíricamente, sabemos que si nos PRE-ocupamos de los riesgos, éstos se convierten en oportunidades; dan valor al futuro y traen beneficios ya que permiten no tener pérdidas inesperadas.

Aunque muchas veces no es exactamente esto lo que nos encontramos. Y es que para mantener y gestionar riesgos, debemos metódicamente tener conocimiento y aplicar secuencialmente lo siguiente: identificar los riesgos que tiene nuestro software -o que pueden afectar a nuestro software-, darles el apropiado contexto, evaluar la probabilidad de que sucedan, estimar su impacto y las acciones para eliminar dicho impacto, estimar cuánto costará realizar estas acciones y, finalmente, dejar que un grupo de profesionales de distintos ámbitos (pero que permiten que se use nuestro software) decidan si aceptar o reducir el impacto de los riesgos identificados, en base a la información que hemos proporcionado.

Simplifiquemos y centrémonos en la relación riesgo-tiempo. Estamos en la etapa inicial: identificar con anticipación. Lo hacemos en orden a qué punto está nuestro software respecto a su uso. Sabemos que identificamos y que hicimos en la etapa previa a la actual. Y con ésta información, anotamos como vemos actualmente la etapa siguiente. Estamos actualizando fotos sobre el futuro. Gestionamos bien nuestros riesgos si nos ocupamos, en esta etapa previa, de imaginar lo que puede suceder en las etapas siguientes. Nos basamos en nuestra experiencia previa, o en la documentada por otros, e imaginamos casos que pueden suceder; asignando una probabilidad al hecho de que realmente sucedan. Somos creativos. No se trata de tener el máximo de detalles de solo una foto futura, y sufrir de parálisis por análisis.

Se trata de avanzar periódicamente en el ejercicio de proyección; tomando fotos y completando detalles que quizás no hemos visto anteriormente. Lo hacemos de forma pragmática y repetitiva: mantenemos y gestionamos. Como en un juego de nuestra consola, PC, teléfono móvil o “Tablet”, queremos seguir “pasando pantallas”, así que debemos anticiparnos a las sorpresas que nos podemos encontrar; su impacto, su probabilidad, y cómo podríamos tratarlas.

Debemos preocuparnos porque los desarrolladores de software somos creativos, y la gestión de riesgos tiene un atrayente aspecto dinámico y lúdico.

Centrémonos en nuestro contexto: relación riesgo-tiempo-mantenimiento de software. Un software, como un vino, es creado para que tenga una vida y una calidad concreta. A medida que pasa el tiempo estamos obligados a anticipar como este software puede cubrir más funcionalidad; como puede modificarse para mejorar su rendimiento, -que puede no ser el esperado en algunas funcionalidades-, o cómo puede adaptarse a nuevas plataformas de Hardware. Entonces, evolucionaran como la tecnología en las bodegas, inevitablemente. En todos los casos, debemos anticipar cada una de las imágenes y decidir cómo queremos que encajen en toda la película.

Debemos preocuparnos en tener -como autores del software- el poder de influencia, en el futuro, de la obra creada.

Más de nuestro contexto, relación riesgos-tiempo-tangible-intangible. El software, como el vino, está a merced de factores que pueden hacer que una alteración se produzca inesperadamente. Un cambio en un vino que está madurando en barrica a su temperatura y/o humedad, sin que sea lo que estaba previsto, hará que cambie dramáticamente el resultado final de este vino, sin que se perciba el momento en que se produjo la alteración. Un cambio en el software, sin la previsión de donde se efectúa este cambio y cuál es el impacto en el contexto (uso que se hace de este software) llevará a la misma situación de perplejidad e insatisfacción que tendremos con el vino.

Debemos preocuparnos porque queremos que nuestro software sea utilizado por el máximo de usuarios, y que su funcionalidad beneficie lo máximo posible a un usuario, el máximo de tiempo posible. Solo los desarrolladores tenemos información sobre la arquitectura de software, y podemos anticipar los factores que pueden alterarlo, una vez éste software está en producción. Sabemos aplicar y reaccionar a los resultados de un método del control sistemático. Podemos realizar un ejercicio constante de creatividad para la actualización de la lista de estos factores durante el tiempo de vida del software. Creamos un software que seguirá siendo vigente durante años.

Y, finalmente, ya no estamos en tensión. Tenemos un poco más claras las razones por las que debemos preocuparnos por el mantenimiento y la gestión de los riesgos como desarrolladores de software; ya nos podemos plantear ¿cómo podemos continuar desarrollando mientras otros mantienen nuestro software?

Continuamos desarrollando, ya que nos hemos anticipado a esta situación y contexto: hemos identificado los riesgos, evaluado su probabilidad de aparición, su impacto, identificado las acciones para reducirlo y estimado el esfuerzo a invertir en estas acciones. Tenemos la documentación relacionada actualizada, y la conseguimos transferir periódicamente a los grupos que se pueden dedicar a mantener nuestro software.