Quien me iba a decir a mí que hace solo unos días he estado hablando de este sistema como de extremada validez hoy en día. Así que tras la conversación del otro día me fui a revisar casi nostálgicamente los antiguos documentos. Quedé contento. Lo tenía todo. Si tenemos que hacer algo parecido o mejor, tenemos material de partida para hacerlo para quien pueda solicitarlo. Habría que, eso sí, reimplementarlo. Es decir, reprogramarlo de nuevo acorde a nuevos lenguajes de programación, nuevos entornos de Bases de datos y adaptarlo a los sistemas actuales que un cliente pueda tener o si no los tiene aún, va a querer tener.
En mi asignatura de "Validación de software" una de las cosas -si no la que más importancia tiene-, es la producción de documentación técnica de software. Y es uno de los grandes problemas para el mantenimiento del software. Muchos de los que lean esto, al igual que me dicen mis alumnos que trabajan en empresas, seguramente se sentirán identificados entre ellos como "no productores" de documentación técnica del software producido. Y no acabo de saber si es que no saben o no quieren. No hay que olvidar que la producción de documentación técnica de software se lleva más tiempo que la programación (un poquitín más por término medio) y por supuesto, eso que se ahorra el que "produce".
La picaresca llega al término de que un día un alumno me dijo que con las "metodologías ágiles" precisamente no habia que producir esa documentación o al menos toda ella. Le tuve que replicar que las metodologías ágiles precisamente lo que hay que producir con mucho esmero es la documentación técnica. De nuevo tuve que deducir o desconocimiento o intención en la ausencia de producción de dicha documentación.
Para mi es una cosa inherente, es decir, no es concebible producir programas y no documentarlos. Eso es una forma de "sisar" al cliente una parte del trabajo que hay que hacer. Pero por el otro lado el cliente tampoco sabe que documentación pedir. El resultado es que el cliente de hoy acepta un software para el que siempre tiene prisa, sin darse cuenta de que antes o después ese sistema va a necesitar mantenimiento (cambios) y si no hay documentación técnica en muchas ocasiones quien ha de hacer esos cambios, en realidad ya no serán cambios sino reconstrucción completa de módulos enteros a precios exorbitados en relación a lo que hubiese costado de haber habido dicha documentación.
Es curioso este fenómeno porque en otras ingenierías sería inconcebible que una casa, o un barco, o un avión, o un automóvi,l o un puente, no se hicieran acorde a planos y cálculos y que tras terminar todos esos sistemas no se guardasen celosamente esos planos y cálculos por si hubiese que hacer cambios. Es uno de los problemas de la ingeniería informática al menos en España, y es que aunque se llame así al profesional (Ingeniero) no hay colegios de ingenieros que se ocupen de visar proyectos, es decir, de comprobar que se entrega lo que se ha hecho y que lo hecho es lo que había que hacer. ¿Les resulta familiar esta situación? A mí, en mi propia experiencia mucho. De hecho estoy pensando en organizar un curso para clientes (sí, para quienes pagan sistemas) de software, para enseñar a un cliente qué debe exigir al ingeniero a o su empresa.
En fin, yo tengo la documentación y los "planos" de aquel sistema de los años 90 aun válido hoy en día. Y a pesar de ser complejo, podríamos rehacerlo, en meses. Y desde luego nada que ver con volverlo a hacer desde cero. Les voy a contar brevemente lo que hacía aunque ya le he mencionado algún detalle antes. Teníamos entonces un estudio que demostraba que nada menos que el 40% del tiempo de trabajo en una empresa se iba en dos actividades, una era buscar documentación Ya trataremos ese tema más adelante) y otra en leer documentación que le llegaba a uno indebidamente y redirigirla a quien correspondía. No tengo idea de cuánto sería ese porcentaje hoy en día. Sería un curioso estudio.
En todo caso esa casuística le será conocida a muchos de ustedes. El sistema permitía como ya les conté, que llegase un documento electrónico a una única dirección por empresa, se registraba automáticamente, se clasificaba en una serie de buzones virtuales y luego estaba el sistema de distribución, es decir, el que llevaba esos documentos al escritorio de la persona a quien correspondía. Como ya les conté el índice de fallos era sorpresivamente bajo (menos del 5%).
Bueno, pues ya han visto en primera línea como algo de los años 90 (en forma de "planos" y know-how) acaba de pasar al inventario. Como nos pongamos a "revolver cajones", a saber las cosas que vamos a sacar y que vamos a incorporar al "inventario". Les dejo por hoy. Sigo otro día, que como ya le dije, aún estamos a mediados de los 90. Ya vamos rescatando cosas.
En mi asignatura de "Validación de software" una de las cosas -si no la que más importancia tiene-, es la producción de documentación técnica de software. Y es uno de los grandes problemas para el mantenimiento del software. Muchos de los que lean esto, al igual que me dicen mis alumnos que trabajan en empresas, seguramente se sentirán identificados entre ellos como "no productores" de documentación técnica del software producido. Y no acabo de saber si es que no saben o no quieren. No hay que olvidar que la producción de documentación técnica de software se lleva más tiempo que la programación (un poquitín más por término medio) y por supuesto, eso que se ahorra el que "produce".
La picaresca llega al término de que un día un alumno me dijo que con las "metodologías ágiles" precisamente no habia que producir esa documentación o al menos toda ella. Le tuve que replicar que las metodologías ágiles precisamente lo que hay que producir con mucho esmero es la documentación técnica. De nuevo tuve que deducir o desconocimiento o intención en la ausencia de producción de dicha documentación.
Para mi es una cosa inherente, es decir, no es concebible producir programas y no documentarlos. Eso es una forma de "sisar" al cliente una parte del trabajo que hay que hacer. Pero por el otro lado el cliente tampoco sabe que documentación pedir. El resultado es que el cliente de hoy acepta un software para el que siempre tiene prisa, sin darse cuenta de que antes o después ese sistema va a necesitar mantenimiento (cambios) y si no hay documentación técnica en muchas ocasiones quien ha de hacer esos cambios, en realidad ya no serán cambios sino reconstrucción completa de módulos enteros a precios exorbitados en relación a lo que hubiese costado de haber habido dicha documentación.
Es curioso este fenómeno porque en otras ingenierías sería inconcebible que una casa, o un barco, o un avión, o un automóvi,l o un puente, no se hicieran acorde a planos y cálculos y que tras terminar todos esos sistemas no se guardasen celosamente esos planos y cálculos por si hubiese que hacer cambios. Es uno de los problemas de la ingeniería informática al menos en España, y es que aunque se llame así al profesional (Ingeniero) no hay colegios de ingenieros que se ocupen de visar proyectos, es decir, de comprobar que se entrega lo que se ha hecho y que lo hecho es lo que había que hacer. ¿Les resulta familiar esta situación? A mí, en mi propia experiencia mucho. De hecho estoy pensando en organizar un curso para clientes (sí, para quienes pagan sistemas) de software, para enseñar a un cliente qué debe exigir al ingeniero a o su empresa.
En fin, yo tengo la documentación y los "planos" de aquel sistema de los años 90 aun válido hoy en día. Y a pesar de ser complejo, podríamos rehacerlo, en meses. Y desde luego nada que ver con volverlo a hacer desde cero. Les voy a contar brevemente lo que hacía aunque ya le he mencionado algún detalle antes. Teníamos entonces un estudio que demostraba que nada menos que el 40% del tiempo de trabajo en una empresa se iba en dos actividades, una era buscar documentación Ya trataremos ese tema más adelante) y otra en leer documentación que le llegaba a uno indebidamente y redirigirla a quien correspondía. No tengo idea de cuánto sería ese porcentaje hoy en día. Sería un curioso estudio.
En todo caso esa casuística le será conocida a muchos de ustedes. El sistema permitía como ya les conté, que llegase un documento electrónico a una única dirección por empresa, se registraba automáticamente, se clasificaba en una serie de buzones virtuales y luego estaba el sistema de distribución, es decir, el que llevaba esos documentos al escritorio de la persona a quien correspondía. Como ya les conté el índice de fallos era sorpresivamente bajo (menos del 5%).
Bueno, pues ya han visto en primera línea como algo de los años 90 (en forma de "planos" y know-how) acaba de pasar al inventario. Como nos pongamos a "revolver cajones", a saber las cosas que vamos a sacar y que vamos a incorporar al "inventario". Les dejo por hoy. Sigo otro día, que como ya le dije, aún estamos a mediados de los 90. Ya vamos rescatando cosas.