La OEPM presenta la candidatura del proyecto Alfa a los premios ASLAN 2012. La documentación que acompaña al proyecto es el artículo que escribimos para su presentación al Tecnimap 2010, titulado «El proyecto ALFA – Gestión de invenciones de la Oficina Española de Patentes y Marcas«. Este documento se escribió a principios de 2010, hace casi ya dos años. Han cambiado cosas importantes, entre ellas, que el sistema ha sido puesto en marcha y lleva ya funcionando más de un año. Por ello, como revisión del desarrollo de las etapas finales de la concepción y las iniciales de su alumbramiento, me he decidido a escribir este artículo.
Érase una vez…
El sistema Alfa se concibió para reeemplazar el anterior sistema de información operativo en la OEPM para la Gestión de Invenciones: SITADIN. Este sistema databa de mediados de los 80, y se desarrolló sobre una plataforma Bull GCOS8 y fué programado principalmente en COBOL y PACBASE. 25 años son una vida larga para un sistema de información. Cuanto un sistema de información tiene tal edad, suceden varias cosas un tanto inusuales, sobre todo para los que estamos acostumbrados de cambiar de sistema operativo cada 5 años:
- Muchos usuarios han crecido con el sistema. Por tanto han adaptado su mente al funcionamiento del sistema. Querrán que el nuevo sistema funcione «como el antiguo».
- Los constructores iniciales del sistema puede que ya no estén con nosotros. Parte del conocimiento necesario para entender su funcionamiento ya no lo tenemos, o es muy difícil de extraer de las miles y miles de líneas de código.
- Los nuevos sistemas han ido creciendo a su alrededor, como una especie de capas tecnológicas estratigráficas sucesivas, parecidas a las que vemos en las excavaciones arqueológicas.
- La interrelación y comunicación entre el antiguo sistema y los nuevos se realizó con los medios disponibles en la época, en muchos casos manuales, en otros por los clásicos procesos Batch. La integración on-line de los procesos ha llegado mucho más recientemente. A pesar de ello, las necesidades de comunicación e intercambio de datos han aumentado fuertemente en la última década.
Hay que reconocer que las circunstancias hacen que la elaboración de un proyecto de estas características es sin duda costosa. A la dificultad técnica de tratar de emular funciones antiguas con nuevos sistemas, se añade la dificultad cultural la resistencia al cambio. Quizás ello explica que el proyecto Alfa no fué el primer intento de modernizar el sistema de gestión de Invenciones. Hubo otros intentos antes, pero fracasaron. Solamente cuando se convenció todo el mundo de la necesidad de reemplazarlo, cuando apareció la urgencia del cambio, fue posible acometerlo con éxito.
El diseño de la transición
Una cuestión importante es el diseño de la transición. Generalmente, hay dos aproximaciones a la transición. La primera es una transición progresiva, con los dos sistemas solapándose en el tiempo, y trasladando progresivamente las funcionalidades del antiguo al nuevo, hasta que toda la funcionalidad está transferida. La segunda es la denominda comunmente migración, en la que el antiguo sistema permanece completamente operativo hasta que el día D se detiene el servicio, se realiza una migración de los datos existentes al nuevo sistema, y una vez finalizada se arranca el nuevo. En Alfa se optó por esta segunda opción.
Generalmente, la transición progresiva es menos arriesgada, permite una mejor acomodación de los usuarios al nuevo sistema, permite arreglar posibles desperfectos y funcionalidades a medida que se avanza, y tiene una más fácil vuelta atrás, en caso de problemas graves. Sin embargo, no siempre es posible, por problemas de compatibilidad técnica. También es más cara y requiere más recursos, pues supone mantener durante un tiempo ambos sistemas en marcha, así como los subsistemas que sincronizan los datos entre ambos, que luego además serán descartados una vez finalizada la transición.
La migración «de una vez» tiene por contra la ventaja de que es más rápida, necesita menos recursos, por lo que es más barata, y reduce el peligro de una vuelta atrás por presiones de los usuarios a los que no les gusta el nuevo sistema. Sin embargo es más arriesgada; requerirá por lo tanto de un mayor y más intenso periodo de pruebas; no será posible probar en real el sistema antes de su entrada en explotación, porque de manera inevitable algunas cosas no se podrán probar bien, y surgirán errores y problemas que habrá que corregir después, con el sistema ya en marcha.
La integración
El sistema de Gestión de Invenciones constituye uno de los dos núcleos de negocio de la OEPM (el otro es la gestión de Signos Distintivos) y fué el primero en automatizarse. Como vimos antes, los sistemas periféricos, al principio manuales, fueron automatizándose también, pero con un bajo nivel de integración, muchas veces manual. De hecho, uno de los principales objetivos de Alfa era lograr esa integración de los sistemas de información y por tanto de los procesos, obteniendo netas ventajas des de el punto de vista de la calidad de la información, y de la agilidad de los procesos, lo que redunda entre otros en el acortamiento de los plazos que la OEPM logra en la tramitación de las solicitudes. La integración también ha permitido simplificar y acortar la publicación del BOPI, eliminando la necesidad de un postprocesado de la información que, anteriormente a Alfa, se contrataba externamente, con el consiguiente ahorro.
Pero la integración no es fácil. De hecho, durante la fase de desarrollo, y debido a dificultad o incluso inexistencia en algunos casos de plataformas de preexplotación de los sistemas con los que se había de integrar, y en otros de la carencia o inmadurez de estándares en los interfaces, los desarrollos se hicieron sobre interfaces simulados. Eso permitió avanzar a buen ritmo las labores de desarrollo, pero retrasó notablemente la última fase del proyecto, la fase de integración. En algunos casos, ni siquiera estuvo claro, hasta fases muy avanzadas del proyecto, el reparto de funciones a ambos lados del interfaz.
Otro problema derivado es que finalmente no se han logrado todavía definir de forma estandar y unívoca todos los interfaces. Esto hace, por ejemplo, que existan diferentes formatos para intercomunicar unos y otros sistemas con Alfa, aunque intercambien la misma información.
De modo que, para mí, la moraleja es clara: los interfaces son una parte integral de un proyecto ya desde el principio, al igual que es el diseño funcional. No podemos minimizar ni tampoco dejar de definir, diseñar y probar los interfaces para el final del proyecto, so pena de encontrarnos con retrasos inesperados, sobrecostes y problemas de interoperabilidad que pueden persistir mucho tiempo después de que el sistema ha entrado en explotación.
Los usuarios y las especificaciones funcionales
Cuando un proyecto como éste se extiende durante tanto tiempo, se parte de unas especificaciones, más o menos definidas, con las que se diseña. Pero es inevitable que los requisitos iniciales vayan cambiando, del mismo modo que avanza la tecnología. Esto, si no es que aparecen cambios normativos de obligado cumplimiento, como fué la ley 11/2007.
Otra cosa que también sucede es que es muy dificil conseguir de los usuarios una especificación definida y detallada. Incluso cuando se consigue, puede suceder también que la interpretación no era la correcta. También sucede que determinados usuarios (determinado perfil de usuario) tiene unas necesidades, y otros tipos de usuario tienen otras, que no siendo incompatibles con las anteriores, complican sin embargo el trabajo de diseño y de poner la aplicación «al gusto de todos». Por ello, siempre que sea posible, es preferible diseñar sistemas con un ciclo de vida corto, lo cual permite poner en marcha unas primeras funcionalidades mínimas, que posteriormente se irán refinando, mejorando y ampliando.
Pero esto es relativamente fácil para un sistema nuevo; no es tan fácil para un sistema, como Alfa, que reemplaza a un sistema anterior. Esta sería una de las consideraciones que habrá que tener en cuenta, también, cuando se decide el modelo de transición comentado anteriormente.
La parametrización
Muy relacionado con el asunto anterior está la capacidad de parametrización. Suele ser el gran olvidado en el diseño, quizás porque cuando se diseña con unas especificaciones dadas se piensa que todo va a ser así siempre, que es obvio. Uno de los ejemplos más evidentes es el logotipo. Si se diseña Alfa para la OEPM, que es dependiente del Ministerio de Industria, Turismo y Comercio, no es frecuente pensar que cualquier día ese Ministerio se extinga, y se reemplace por otro denominado Ministerio de Industria, Energía y Turismo. Suena parecido, pero no es igual.
La existencia de una función de parametrización de estos datos facilita muy grandemente los cambios, ya no solo por el tiempo que se tarda, los cortes de servicio que se ahorran, sino porque si no está parametrizado, seguramente habrá que hacer una labor «de chinos» revisando todo el código a ver donde se llama al logotipo, o al texto «Ministerio de Industria, Turismo y Comercio» para reemplazarlo por su nuevo equivalente. Y eso contando con que aún tenemos al programador que codificó el sistema, pues si es al cabo de 10 años, ¿quién sabe dónde andará?. Lo mismo podemos decir de los cambios en las plantillas de documentos, los cambios en el diseño de los flujos de trabajo, etc. todo lo que sea configurable mejora sin duda el sistema a largo plazo.
La testeabilidad
Me atrevo a utilizar este palabro (en lugar de «probabilidad» que no es aplicable en este caso, y la que sería aplicable «comprobabilidad» no existe en el diccionario RAE) para indicar la capacidad de ser probado de un sistema. La testeabilidad implica que en el diseño se tengan en cuenta las necesidades que tiene el sistema de ser probado para ver si cumple las especificaciones, tanto funcionales como operativas, así como para, durante su fase de explotación, para obtener indicadores internos que arrojen los parámetros importantes para el negocio, de forma que permita evaluar su correcto funcionamiento sin necesidad de llamar continuamente al que lo diseñó para que lo pruebe.
Al igual que los interfaces, la testeabilidad (también se oye testabilidad) no se pueden dejar para el final. Tienen que abordarse desde las fases iniciales del diseño. Eso implica que los ingenieros de pruebas tienen que participar en las fases iniciales del proyecto. Es probable que parezca que los requisitos que se imponen adicionalmente a los de diseño funcional sean un plus innecesario, o que se puedan dejar para el momento en que el sistema va a ser pasado a explotación.
Sin embargo, como en el caso de la integración, no es fácil, y a veces incluso imposible, añadir estas funcionalidades al final. Y si el sistema no es adecuadamente comprobable, será muy dificil verificarlo, por lo que las pruebas serán más costosas, y además no lo probaremos totalmente, por lo que una serie de fallos subsistirán cuando el sistema esté en producción.
Y del mismo modo, hay que prever los indicadores y variables que vamos a querer obtener del sistema (por ejemplo las longitud de las colas de trabajo en los procedimientos, para detectar los cuellos de botella) pues tan importante como que el sistema funcione es tener indicadores de cómo está funcionando. Si no tenemos los indicadores apropiados es como si conducimos un coche sin tablero de mandos.
La seguridad
No podemos hablar de un proyecto como éste sin hablar de la seguridad… pero no creáis que voy a decir en público como esta diseñada e implantada la seguridad de Alfa. Todo lo que diré por el momento es que me parece adecuada a las necesidades del sistema.
No obstante, si quiero abordar un par de puntos importantes sobre la seguridad. El primero se refiere al error común de creer que porque un sistema es sólo de uso interno, ya está suficientemente protegido por la seguridad perimetral. Alfa es un sistema de trastienda (backoffice) y no es accesible desde el exterior. Podríamos creer que con eso hemos reducido en su inmensa mayor parte los problemas de seguridad, pero es un error. Entre el 60% y el 80% de los incidentes de seguridad en las organizaciones provienen de usuarios internos, según el Computer Security Institute (CSI) de San Francisco.
Lo cual nos lleva al segundo asunto importante de la seguridad: está en manos de los usuarios. Servirá de poco todos los mecanismos de control que pongamos, si los usuarios no los utilizan y colaboran activamente. E igualmente de los directivos, quienes tienen que asumir, cada uno en las áreas de negocio que les competa, que la seguridad no es responsabilidad de TI, sino de todos y cada uno de los empleados, y tienen que transmitírselo directamente a las personas a su cargo. De modo que, en seguridad, las palabras más importantes son: formación y concienciación.
Planificando el final
Finalmente, hay algo que raramente se contempla, y es la fase final de un sistema en explotación. Su extinción o traslado a otro sistema. Porque es inevitable que ningún sistema, por bueno que sea, va a durar eternamente. Especialmente importante es la elaboración de utilidades de exportación de todos los datos en los formatos estándares (por ej. XML) que permitan su importación en otro sistema distinto, junto con la documentación necesaria para entender y explotar esta información.
En fin, en todo proyecto se aprende algo, espero que estas ideas sacadas de un proyecto felizmente en explotación pero con extremos mejorables sean útiles para nuestros lectores. Si habéis llegado hasta aquí, y os ha servido para algo, quizás os apetezca 😉 votarnos a los premios ASLAN (en la categoría Administración Central)… y poder recuperar fuerzas para seguir adelante.
eFuncionario 