La “mantenibilidad” del software

El reciclaje en la UPV en muchos casos está dando sus frutos. Hay algunos temas que comentaré hoy y en los próximos días que me han parecido especialmente interesantes de las clases prácticas en la ETSINF, y básicamente son dos perspectivas. Por un lado el factor de “mantenibilidad” de una aplicación y por otro lado la “interoperabilidad” e integración entre aplicaciones de redes sociales y el poder de información que conlleva para muchos agentes sociales y empresas.

Centrándonos en el concepto de mantenibilidad, es un concepto interesante y muy poco tenido en cuenta por parte de los ingenieros del software, y por aquellos que contratamos software a terceros o realizamos desarrollos ad-hoc. Se define la mantenibilidad como la cantidad de esfuerzo necesaria para conservar el correcto funcionamiento de un software, y como correcto funcionamiento también se incluye la adaptabilidad a nuevos cambios (modificación en las especificaciones), corrección de bugs y mejoras funcionales.

Si pensamos un poco en nuestras aplicaciones informáticas, por encima de lo que hagan realmente o dejen de hacer, deberíamos de preocuparnos “la faena” que luego nos va a dar. Centrándonos en el ámbito de la informática en la administración, si por ejemplo adquirimos un software de Gestión Tributaria, quizás a priori la aplicación pueda servirnos en primera instancia para todo aquello que necesitamos sin embargo puede suceder (y sucederá) que: pidamos modificaciones en la aplicación porque no cumple todas nuestras expectativas iniciales, que surjan nuevas funcionalidades requeridas por ley o que en las sucesivas versiones aparezcan errores de ejecución.

La subsanación de estos asuntos es lo que se conoce como proceso de Mantenimiento, y hay técnicas para medir cuánto de mantenible es un software. Actualmente como se comentó en anteriores post, el trabajo de un informático tipo de cualquier entidad local es prácticamente de “parcheo” y poco de “construcción” o de “desarrollo”. De ingeniería al fin y al cabo. En la mayoría de estos casos es detección y reporte de errores, o seguimiento de los mismos en las aplicaciones informáticas. Si el porcentaje de errores baja y el tiempo de resolución de los mismos es corto, el esfuerzo y la dedicación a estos menesteres, o lo que llamamos “parcheo” de sistemas es sensiblemente mejor.

Por encima de otras técnicas comentadas en otras ocasiones como la implantación de entornos de prueba in situ, para evitar la aparición de estos problemas, o el correcto estudio de la especificación de requerimientos para no tener que acudir a modificaciones de última hora, cuando un software es fácilmente mantenible este problema se reduce sensiblemente.

En el caso de Picanya, yo realicé un estudio del proceso de mantenimiento de software para nuestro principal proveedor de aplicaciones de gestión. No detallaré los pormenores del sistema de mantenimiento propuesto por dicha empresa (que al final no es utilizado más que un 60% de lo previsto) puesto que son datos confidenciales de la misma, pero sí que hay un aspecto a considerar y que hace replantear a dicha empresa el testeo de las aplicaciones. Pues es ahí, en la fase de pruebas de los desarrollos, donde se escapan muchos de los bugs de la misma.

El problema radica en que, al igual que podría suceder con un software para el desarrollo de otro software, es decir un entorno de desarrollo y su compilador (por ejemplo el Visual Studio o el Eclipse) podemos probar fácilmente el correcto funcionamiento del entorno, pero no podemos prever el comportamiento del resultado de la compilación de todas las aplicaciones que pueda desarrollar el usuario, puesto que la casuística es enorme. Para abordar este asunto, existen dos alternativas:

1) Crear entornos tipo y hacer combinatorias de prueba de manera desasistida. Es decir, tener diferentes tipos de programas o procesos con todas y cada una de las casuísticas diferentes y proceder a combinaciones aletorias. Este es el sistema que habitualmente se utiliza en los entornos de desarrollo. El proceso es largo y costoso.

2) Reproducir en el cliente clonaciones de los procesos que se usan con datos de prueba ofreciendo un report final con los resultados del testeo, a parte de los test habituales que se realizan con la liberación de la versión.

En nuestro caso, con el sistema de procesos de negocio en BPM, se opta por la segunda opción, que está por ver y probar y esperemos que acabe de una vez por todas por el martirio que supone la liberación de versiones o las continuas paradas del sistema por errores no controlados.

Mantendremos informados.

Software-Structural-Flaws-300x199[1]

 

Anuncios