EINA. Análisis de la evolución de una aplicación informática
con un modelo de simulación

Roger Salmerón
rsaneas@gmail.com

Este mismo año trabajé como programador en una consultoría. El grupo de trabajo al que me incorporé se encargaba del mantenimiento de la aplicación que utilizaban todos los trabajadores de los diferentes departamentos de una Empresa Aseguradora.

Como tengo conocimientos de psicología social me di cuenta que habían caído en una homeostasis social que se traducía en que nadie tenia un conocimiento general de la Aplicación. Porque el conocimiento compartido sobre ésta era básicamente oral. Me explico, lo que pudiera recordar un miembro del departamento sobre una parte concreta de la aplicación no tendría que ser necesariamente lo actual. Además este individuo, por tener una memoria limitada, probablemente desecharía dicho conocimiento para retener otro más actual. Si generalizamos este comportamiento a todos los individuos del departamento, al final obtenemos que aunque existe un conocimiento social compartido que nos identifica como miembros del departamento de informática. Si intentamos estructurar el conocimiento social compartido disponible sobre la Aplicación. Nos damos cuenta que el conocimiento disponible varía enormemente con el tiempo y además como no tenemos un registro de las variaciones, una referencia, una perspectiva temporal, no nos sirve de casi nada. Por lo que nos veremos obligados a partir de casi cero siempre que nos dispongamos a analizar la aplicación. A medida que esta crezca y se vaya haciendo más compleja, más difícil aún será nuestro trabajo. Si la Aplicación en un principio y haciendo una analogía, se diseñó como un conjunto de carreteras y autopistas bien señalizadas e interconectadas. En la actualidad, y siguiendo con la analogía, tendríamos que ese conjunto de autovías y carreteras iniciales. Se la habrían añadido otro de autopistas y algunos caminos de cabras, con o sin señalización, e interconectadas, muchas veces, de manera poco rigurosa.

El modelo que te he presentado es una primera aproximación sobre esta problemática. Verás que he introducido dos tablas: Gradiente de Desconocimiento del Sistema y Modificación de la Estructura de la Aplicación. Están explicadas brevemente más adelante, aunque es verdad que la primera era mi objetivo principal. Porque a mi modo de ver es el motor de la homeostasis.

Al final el mantenimiento se hacía de una manera sencilla. Se iban añadiendo modificaciones hasta que la Aplicación aguantara. Llegado a éste punto se implementaban y sustituían conjuntos de la aplicación, cada vez mayores hasta llegar a una macro modificación, basada en las modificaciones anteriores llamada NUEVA APLICACION.

A continuación te explico brevemente los componentes utilizados en la simulación:

Tipos de modificaciones, dependiendo del grado de complejidad que se puede efectuar sobre el sistema:

-Incidencia: modificación leve de la aplicación. (5 horas teóricas)

-Evolutivo: modificación importante de la aplicación. (10 horas teóricas)

-Nuevo Desarrollo: modificación sustancial de la aplicación. (30 horas teóricas)

Proporción teórica del tiempo dedicado a cada una de las tres partes de las que consta la actuación:

-K1: 3/5, tiempo dedicado a la implantación de los cambios necesarios para suplir la demanda del usuario.

-K2: 1/5, tiempo necesario para entender la demanda del usuario (no sé explican bien).

-K3: 1/5, tiempo necesario para localizar el código implicado a cambiar según la demanda del usuario.

Gradiente de Desconocimiento del Sistema: recoge como las diferentes acciones sobre este aumentan la complejidad de las relaciones entre los diferentes elementos. Este gradiente que nace de la modificación de la estructura recoge factores como: el rigor en seguir los protocolos de actuación de la empresa. La eficiencia y efectividad de la actuación. El nivel de desconcierto que supone ver código antiguo, código repetido, código absurdo, errores….

Modificación de la Estructura de la Aplicación: como el nombre indica recoge el número de componentes necesarios para hacer viables las demandas del usuario. Parte de las horas reales que los informáticos dedican a implementarlas y se traducen en nuevo código generado.

El periodo de 0-50 semanas se puede entender como un periodo que se caracteriza por la total libertad que tiene el programador para implementar sus cambios. El siguiente periodo 51-420 semanas sería el periodo donde se pondría a prueba la flexibilidad de la aplicación para absorber dichos cambios. A partir de entonces se trabajaría con la idea de ir sustituyendo conjuntos de la aplicación cada vez mayores.

El Código de la Aplicación es el número total de componentes de los que consta la aplicación.

Horas Teóricas Previstas: es el número total de horas por semana de trabajo necesarias para resolver las demandas planteadas por los usuarios. Habrán diferentes coeficientes dependiendo del grado de dificultad de la acción: Incidencia (5 horas teóricas), Evolutivo (10 horas teóricas), Nuevo Desarrollo (30 horas teóricas).

Las Horas de trabajo extra recogen las demandas de los usuarios de los diferentes departamentos que aún no se han resuelto.

Horas Reales de trabajo: son las horas necesarias para modificar la Aplicación según las demandas de los usuarios.

Empresa Subcontratada: Se subcontrata a partir de la semana 400 para ir resolviendo parte del trabajo pendiente.

Precio acordado: recoge la cantidad que cobraría a la semana, 7’5 euros la hora.

Incremento de capital del Dept. Informática: nos indica el gasto final necesario para contratar a la gente requerida para mantener al día la Aplicación.

Para acabar: C1, C2, C3, C4, C5 son constantes que he utilizado para cuadrar las unidades.

La mejor vía que se me ha ocurrido para solucionar el problema. Es atacar precisamente el Desconocimiento sobre la aplicación que se va acumulando. Éste hace que prácticamente partamos desde cero. Usando una analogía, si nos encontráramos en el paleolítico y tuviéramos que cazar o recolectar, sabríamos que en el bosque efectivamente hay caza, tubérculos y frutas. Y encontraríamos mejor o peor comida en función de nuestra habilidad como cazador y recolector. Pero lo verdaderamente inteligente no sería cazar ni recolectar. Sino capturar a aquellos animales que nos interese comer y meterlos en un corral; coger las semillas de las plantas y hacernos un huerto y hacer que críen y florezcan según nuestras necesidades. Además y usando otra analogía, ¿qué modelo de urbanización es mejor seguir: el de l’Eixample o el de una Favela o una Barriada? Cuanto más se ajuste nuestro conocimiento sobre el sistema que queremos modificar a su realidad estructural mejores serán las respuestas, pero sin ningún tipo de mapa difícilmente podremos aventurarnos a proyectar soluciones verdaderamente racionales.

Eina puede entenderse como una nueva organización del capital humano, de los grupos de trabajo. Si antes todo el mundo se encargaba del conjunto de la aplicación, se podría dividir la aplicación en grupos de trabajo especializados que sólo operasen sobre esa parte de la aplicación. Eina también puede entenderse como un Software que recoge de una manera clara todo el conocimiento actual de la estructura.

¿Cuál de las opciones es mejor?

La primera y retomando la primera analogía. Establecería que en vez de encontrarnos con un grupo de cazadores y recolectores. Nos encontraríamos con cazadores especializados en caza mayor, caza menor…según la temporada. Y también con diferentes tipos de recolectores según el producto y la estación. Esta respuesta si bien es efectiva, no nos permite establecer un verdadero control sobre la dinámica de cambio, sólo nos permite mejorar parcialmente los resultados. Imaginemos que no disponemos del experto o experta en un área de la aplicación, porqué está de vacaciones. Entonces otra persona tendría que aventurarse empezando des de casi cero, lo que se hace actualmente.

La segunda por el contrario, nos permitiría estar a un click de distancia de la realidad estructural de la aplicación. Esta opción hace que pasemos de la caza a la ganadería, de la recolección a la agricultura. Realmente supondría una revolución neolítica en el mantenimiento de aplicaciones.