archivo

Archivos Mensuales: septiembre 2010

El danés Bjarne Stroustrup fue el padre del C++ y es catedrático en la Universidad A&M de Texas. Su trayectoria le permitió ser reconocido hace dos décadas como uno de los doce mejores científicos jóvenes de Estados Unidos según la revista Fortune y a recibir desde entonces diferentes premios y reconocimientos.

Sobre la evolución en la complejidad y funcionalidades de los dispositivos móviles comentó lo siguiente (traducción libre): “Siempre he deseado que mi ordenador fuese tan fácil de utilizar como mi teléfono. Mi deseo se ha convertido en realidad porque ya no sé como utilizar mi teléfono”.

Detrás de esta ironía, se encuentra el hecho de que realmente los dispositivos móviles han ido adquiriendo progresivamente un mayor número de funciones y posibilidades que los han convertido en un ordenador, con una ventaja sobre estos por su tamaño y también con inconvenientes por el mismo motivo.

No hace mucho escribí un artículo denominado “Un sistema de información sin mantenimiento” en el que especifico las características que debe tener una aplicación para no requerir tareas de mantenimiento continuo y lo que podría ocurrir en el caso de que necesitándolo no se pongan a su disposición los recursos que precisa.

Dentro de muy poquito uno de los sistemas de información que gestiono se queda sin presupuesto para mantenimiento. Es una aplicación grande, con muchos usuarios, con bastante uso, que afecta a varios departamentos, que está desarrollada en la tecnología prácticamente obsoleta, que tiene ya casi siete años de puesta en producción (aunque su concepción y análisis se remonta prácticamente cuatro años atrás) y que a lo largo de este tiempo ha sufrido numerosas modificaciones y ampliaciones funcionales, correcciones, etc… incrementándose su complejidad de forma paulatina.

¿Deberían haber sido siete años suficientes para dejar medianamente estable el sistema? La respuesta es que en condiciones normales sí, pero esas no han sido las circunstancias que han rodeado al mismo, ¿qué lo podíamos haber hecho mejor? También, y soy consciente de ello.

¿Por qué se queda sin presupuesto? Principalmente (y lo pongo por encima de la crisis económica, aunque de no existir ésta se hubiese encontrado financiación) porque los gestores de los departamentos a los que presta servicio no ven crítico que no haya dinero para mantenimiento, en unos casos porque probablemente no terminen de verle la utilidad al sistema y en otros porque en el fondo piensan que se encontrará una solución por parte de informática para que el sistema no quede sin soporte. No voy a entrar a juzgar esto, ya que cada cual tiene que hacer frente con sus presupuestos a sus áreas de gestión y nadie mejor que ellos saben dónde deben gastar e invertir.

Como miembro del departamento de desarrollo todo este asunto me podría dar un poco igual ya que sería en todo caso el departamento de explotación el que tendría que hacer frente a las demandas de los usuarios en cualquiera de los niveles de atención a usuarios ya que desde desarrollo no se podría dar respuesta a las incidencias y peticiones que nos escalen, la cual quedarían sin resolver de forma indefinida, debiéndose buscar alternativas en el programa para sortearlas (a veces será posible, otras no).

Sin embargo, cuando uno ha trabajado en un sistema tanto tiempo, le ha dedicado tanto esfuerzo y ha sufrido muchísimo desgaste, no puede abandonarlo como tal, por lo que en previsión de lo que podía pasar (y era algo que se veía desde hace prácticamente un par de años ya que el presupuesto ha ido disminuyendo paulatinamente hasta quedar en la actualidad y hasta dentro de muy poco, una cantidad simbólica) he intentado buscar alternativas para que el impacto sea el menor posible (muchas de ellas no salieron).

Entre ellas (y es de las primeras que se logró) es que se distinguiera claramente las tareas que correspondían al CAU de las tareas de desarrollo, por lo que el presupuesto de atención a usuarios de la aplicación se desvió a la bolsa general de atención a usuarios de mi organización. Esto que puede parecer lógico y que ya está implantado en mi organización, estaba todavía en fase muy embrionaria cuando se llevó a efecto. De esta forma la atención a usuarios de primer y segundo nivel estaba garantizada y además con unos niveles de calidad muy buenos porque el equipo de personas que está detrás también lo es.

Una vez que la atención a usuarios estaba cubierta quedaba otra parte y es tener la posibilidad de dar respuesta ante incidencias en el uso del sistema que necesiten la participación del departamento de desarrollo así como al mayor número de peticiones relacionadas con alguna modificación funcional.

Sobre esto he tenido mucho menos margen de maniobra y los resultados, como es lógico, no han podido ser muy significativos. Dado que una parte de la aplicación está construida en Java (una parte muy pequeña) y algunos de los componentes que utiliza (y que son parte de la aplicación) también lo están, dada la precariedad de los recursos económicos de mantenimiento del sistema, se tomó la decisión de que entrasen dentro del proyecto de mantenimiento global de sistemas de información desarrollados en Java, por lo que por lo menos una parte de la aplicación (aunque mínima) estaba cubierta ante posibles incidencias.

¿Qué pasa con el resto (que es casi todo)? Pues en estos últimos meses en colaboración con el CAU y con el soporte todavía vigente de la aplicación, se han desarrollado funcionalidades en el área de administración del sistema para incrementar la casuística de incidencias que puede atender el CAU. También se ha trabajado en aquellas funcionalidades de la aplicación que presentan más problemas. Todo esto sigue siendo insuficiente para poder prestar un servicio de calidad a los usuarios cuando nos quedemos sin mantenimiento pero siempre será mejor que nada.

¿Qué pasará? Todavía tengo la esperanza de que se consiga algo de financiación que nos permita alargar el soporte algunos meses más, pero en el caso de que no se llegue a ella, probablemente algunas de las consecuencias indicadas en el artículo al que hacía referencia en el primer párrafo se producirán, teniendo cada vez una comunidad de usuarios más molesta que dará lugar a una disminución paulatina en el uso de la herramienta, así como en la calidad de las tareas que se realizan a través de ella.

Vivimos en una roca, dentro de uno de los cientos de miles de millones de sistemas que conforman una galaxia mediana como es la Vía Láctea. Esa es nuestra realidad, en comparación con el universo tal vez un grano de arena en el desierto tenga más relevancia que nosotros.

Por tanto cada uno de nosotros somos pequeñas gotas de agua en este inmenso océano del que todavía se desconocen la mayoría de sus secretos.

Las evidencias por tanto nos invitan a pensar que cada uno de nosotros no somos el centro de nada que no seamos nosotros mismos y cualquier otra apreciación es errónea. Nada gira alrededor nuestra, más allá de nuestros pensamientos, nuestros sentimientos, todo el conjunto de cualidades que hacen que seamos como somos.

Pero eso pasa con respecto al universo externo, es decir, todo aquello que no somos nosotros y que se rige por distintas leyes. En nuestro universo, dentro de nosotros mismos, somos infinitos y si en él existe equilibrio nuestra relación con el exterior será mucho más fluida.

Se codifica, se construye la aplicación, pero en demasiadas ocasiones se tiene en cuenta como fin único la entrega del proyecto, dejando al margen o dedicándole menos importancia a una programación pensando en futuros mantenimientos.

La dificultad de los mantenimientos depende de muchos factores y algunos de ellos están por encima en importancia de una codificación clara y de calidad, como por ejemplo la búsqueda de una alta cohesión y un bajo acoplamiento, lo cual no debería ser una excusa para olvidarnos de este asunto ya que no se trata solo de que se pueda comprender lo que se ha programado (que no es poco) sino que un código poco cuidado probablemente influirá en una mayor complejidad ciclomática de la aplicación (además de a la mayoría de las variables que determinan la deuda técnica de la aplicación) dificultando, en consecuencia, a la mantenibilidad.

Generalmente nos solemos acordar de todo esto cuando toca realizar el mantenimiento del sistema de información y nos encontramos con que la forma en que se ha codificado hace que se requiera un mayor esfuerzo y en consecuencia coste. Por este motivo importa y mucho como se codifica.

El problema de todo esto es que resulta complicado detectar este tipo de problemas en tiempo de desarrollo ya que obliga a estar encima y revisar el código, lo que puede hacer que casi cueste más el collar que el perro. Por tanto, tenemos que utilizar otras estrategias que faciliten la localización de estos problemas, como es por ejemplo estudiar variables que se pueden incrementar indirectamente por una mala programación (se puede realizar una revisión periódica de las métricas que devuelve Sonar) y complementarlo, si es posible, con la revisión, también periódica, de una muestra de clases de la aplicación.

Siendo realista, veo complicado que una empresa de desarrollo, salvo que las deficiencias encontradas en el proceso de verificación interno sean serias, se pongan a rehacer a módulos ya codificados, pero por lo menos si se aplican estas políticas se puede reconducir la tendencia en el desarrollo y que el proyecto se encuentre dentro de unos umbrales de calidad aceptables (los cuales en algunos casos podrán ser exigidos y verificados por el cliente y provocar un rechazo en la entrega y la consiguiente necesidad de refactorizar partes de la aplicación lo cual se volverá en contra del proveedor ya que tendrá que sufrir en sus carnes las consecuencias de unas malas prácticas.

Martin Fowler es un importante y reconocido autor especialista en ingeniería del software y en el proceso de desarrollo (particularmente en el campo de la refactorización) el cual ya he tenido la oportunidad de citar en un artículo sobre una regla de CheckStyle que no comprendía su significado.

Steve C. McConnell es otro reputadísimo autor y especialista en ingeniería del software, tanto es así, que durante años fue considerado junto a Linus Torvalds y Bill Gates unas de las personas más influyentes en el negocio del desarrollo de software. En la actualidad posee una empresa llamada Construx Software que se dedica a consultoría y formación sobre buenas prácticas en desarrollo de software.

Ambos autores son responsables de las siguientes citas relacionadas con la comprensión del código:

Martin Fowler (traducción libre): “Cualquiera puede escribir código que un ordenador pueda entender. Los buenos programadores son aquellos que escriben código que los humanos puedan entender”.

Steve McConnell (traducción libre): “El buen código es su mejor documentación. Cuando vayas a escribir un comentario, pregúntate, ¿cómo puedo mejorar el código para que este comentario no sea necesario?”.

Sobre este tema ya publiqué una cita que se atribuye a Martin Golding en unos casos y a John F. Woods en otros que complementa perfectamente a éstas.

Como he comentado en otras ocasiones, hacer las cosas bien, tarde o temprano, marca la diferencia.

Cuando hablo de enfrentamiento no me estoy refiriendo a tener opiniones distintas o que en el transcurso de una reunión o en el contenido de un correo haya una palabra más alta que otra.

El desarrollo de software es un negocio y por tanto detrás de él hay dinero, carreras profesionales, intereses personales, etc… y no se puede esperar que en un entorno como ese todo sea siempre paz y tranquilidad. Este mundillo es así y ese tipo de problemas los terminarás percibiendo de una u otra manera independientemente del puesto que ocupes en tu organización, ya que incluso estando recién incorporado a tu puesto de trabajo y sin experiencia te puede tocar un proyecto con unos plazo de entrega digamos que complicados.

No obstante a los problemas normales de funcionamiento dentro de una organización (plazos, trabajo en equipo, etc…) hay que sumar aquellos derivados de trabajar con el cliente y con sus usuarios.

Habrá proyectos que vayan bien, ¿por qué no?, esos casos existen, pero también habrá otros donde vengan mal dadas, pudiendo ser los motivos de lo más variopinto (mala estimación temporal y/o económica del proyecto, requisitos funcionales cambiantes, equipos improductivos, errores en el proceso de desarrollo, etc…).

Cuando el proyecto vaya mal las posibilidades de choques con el cliente incrementan casi exponencialmente ya que si se llega a este punto quiere decir que el proyecto está en pérdidas o tiene todas las papeletas para estarlo. En estos casos se tratará por parte del proveedor de intentar reenfocar el proyecto de alguna manera con el objeto de que la cuantía de las perdidas no se dispare, pero el cliente, sobre todo si considera que no ha sido el responsable máximo de la situación, tratará de que el proyecto vaya hacia donde cree que debe ir (pudiendo ser este destino y el del proveedor discordantes y en algunos casos, opuestos).

Cuando surge el conflicto hay que evitar el enfrentamiento con el cliente, más tarde cuando finalice el proyecto puedes tomar la decisión (o tu empresa) de no volver a trabajar más con él (antes de tomar una decisión de este tipo hay que valorar lo más objetivamente posible, cuáles han sido los problemas que han existido en el proyecto y la responsabilidad de los mismos), pero un enfrentamiento con un proyecto no finalizado no arregla nada y pone más barreras entre cliente y proveedor que serán motivo de mayores costes. Ante el problema, negociación, mejor una mala negociación que un buen enfrentamiento (en el primer caso por lo menos puedes conseguir algo, en el segundo se llegará a que las cosas vayan a peor).

Los resultados de la negociación deben quedar por escrito y aprobados por las distintas partes que han participado en la misma. Lo mismo una negociación concreta no soluciona los problemas del proyecto, pero nadie dijo que no se pudiera negociar más de una vez cuando los asuntos que se traten sean distintos a los que se hayan negociado anteriormente o bien las circunstancias hayan cambiado.

Que habrá ocasiones en que las cosas no se puedan arreglar por las buenas o por las medios buenas, no lo niego, pero por lo menos es necesario intentarlo.

Muchas veces se plantean las aplicaciones como un lugar donde simplemente los usuarios graban datos (extiéndase esto a generar documentos o a sacar una serie de informes más o menos básicos).

El planteamiento en sí no es erróneo ya que cualquier software que se desarrolle para realizar mantenimiento de datos siempre me va a parecer mejor que cualquiera hecho por un usuario para realizar esa tarea y no quiero con esto restarle el más mínimo valor a esas soluciones ofimáticas, ya que a muchos les permite sacar adelante el trabajo del día a día.

Son varios los inconvenientes que plantean, me centraré en dos (aunque no hay que obviar otros, como es el mantenimiento de datos de carácter personal en ficheros que no cumplen los requisitos establecidos por la Ley o la posibilidad de pérdidas de información si los archivos no se encuentran ubicados en espacios donde se apliquen copias de seguridad):

– Este tipo de soluciones no siguen una normalización de la información, lo que provoca que la explotación de la misma resulte compleja, es decir, puedes encontrar lo que estás buscando, pero extraer otro tipo de conclusiones sobre ellas es complicado. Esto es un problema inherente a la extrema flexibilidad que ofrecen este tipo de herramientas y a que el uso que se le suele dar a las mismas es muy superficial (depósito de datos organizado de una determinada manera).

– Muchas veces este tipo de alternativas son como una caja B de las aplicaciones informáticas, donde se almacena información que el programa no contempla o bien se utiliza esta estrategia por resultarles más sencillo mantener el dato de esta manera. Esto plantea múltiples inconvenientes, ya que dará lugar más que posiblemente a una falta de coherencia en los datos, es decir, en la aplicación principal y en las “no oficiales” una misma entidad puede tener información distinta, ¿cuál es la buena?.

Este artículo no trata de criticar estas soluciones, sino de intentar exponer una de las causas que llevan a los usuarios a las mismas:

Tal vez no sea la causa más importante de la proliferación de soluciones basadas en herramientas ofimáticas, pero sí es una que da lugar a la aparición de cajas B y no es otra que el desarrollo de aplicaciones que simplemente se encargan de permitir grabarle datos. Eso ya lo tienen con su hoja de cálculo o con su base de datos ofimática y además lo pueden hacer más rápido y fácil (de hecho, como ya he dicho en otras ocasiones nada puede competir contra este tipo de herramientas salvo que las alternativas ofrezcan utilidades que ahorre trabajo) . En su lugar se les ha puesto un programa que les hace lo mismo, solo que la productividad con él disminuye ya que se tarda más en grabar los datos y es más complicado y además se encuentran con errores que no siempre se arreglan tan pronto como desearían.

Las aplicaciones no solo hay que pensarlas como almacén de datos, sino también como una colección de utilidades que realmente proporcionen un valor añadido al que las usa, si el usuario nota esa diferencia no pondrá tanto inconveniente en utilizar una herramienta más compleja y que les obliga a trabajar de una determinada manera, se trata de un “tu me das, yo doy”. Cuando se rompe el equilibrio, los usuarios (salvo instrucciones expresas que obliguen al uso de la aplicación) tenderán a los caminos alternativos (no todos, porque la ruptura del equilibrio no se produce para todos en el mismo sitio y a la vez)

Muchas veces nos enredamos en un problema e invertimos mucho tiempo y esfuerzo intentando encontrar una solución, hasta tal punto que nos empeñamos en resolverlo sin mirar el reloj y sintiéndonos cada vez más presionados por nosotros mismos.

Precisamente, cuando llegamos al punto en que nos da coraje no encontrar la respuesta es cuando pienso que hay que recoger los bártulos y volver a intentarlo mañana u otro día. Aunque creamos que no, nuestra mente seguirá trabajando en el asunto y probablemente cuando lo volvamos a intentar se nos ocurrirán cosas nuevas que no llegamos a probar en el intento anterior.

Otro aspecto que es importante considerar es la importancia de aquello que pretendemos arreglar y que no damos con la clave y los trabajos que podríamos estar haciendo y que tenemos parados porque nuestra atención está en ese otro problema. Salvo que sea algo de extrema urgencia y que requiera que tengamos todos nuestros sentidos en ello (si somos objetivos, pocas tareas merecen ese calificativo), no hay que olvidar que tenemos otras tareas, algunas de las cuales además pueden ser cuello de botella para que otras personas puedan continuar con su trabajo.

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos.

Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos:

– Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”

– Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.

Con las definiciones por delante resulta bastante sencillo discernir un tipo de mantenimiento de otro, ya que el primero está centrado en un cambio en las necesidades del usuario o lo que es lo mismo, en una modificación de los requisitos funcionales de la aplicación (por muy pequeños o grandes que sean) y el segundo se basa en los cambios en cualquiera de los elementos que conforman el entorno sobre el que funciona el programa, a los ejemplos que indica Métrica V.3, yo añadiría los servidores de aplicaciones, servidores web e incluso las interfaces con terceros sistemas, es decir, si una aplicación se comunica con otra por servicios web y ésta modifica la interfaz el cambio a realizar en la aplicación es de carácter adaptativo ya que el requisito funcional (que es comunicarse con ese tercer sistema) no ha variado.

Lo fuí y mucho tiempo. Me hubiera gustado ganar lo que ahora mucho antes, me gustaría que cada mes mi nómina fuera mayor que la que tengo en estos momentos, en realidad y no es solo mi caso, es difícil determinar cuánto resulta suficiente.

Que quisiera cobrar más no quiere decir que no me sienta contento con lo que gano, probablemente en la facultad si me hubieran puesto un papel por delante indicándome que iba a tener el salario que tengo y sus condiciones laborales y lo hubiera firmado sin mirarlo. Estoy contento, si dijera lo contrario sería injusto, pero también mentiría si dijese que no aspiro a ganar más.

Como estoy contento no me planteo otras alternativas más allá de seguir desarrollando mi profesión en mi organización y realmente si termino por irme serán otras causas (y no precisamente económicas, salvo que la diferencia sea sensible), probablemente un proyecto, unas tareas que me resulten suficientemente motivantes.

Como sé lo que es ser mileurista, como lo he sido más tiempo del que hubiera deseado, como sentía que merecía ganar más de lo que ganaba y veía con frustración que no lo conseguía, sé de lo que hablo. De hecho para dejar de ser mileurista tuve que trabajar muchísimo porque tenía claro que el nivel de vida que quería tener estaba sostenido con alfileres con ese sueldo.

De hecho ahí está la clave de todo, en el nivel de vida que queramos tener, ya que ahí se sitúa el límite del gasto y por tanto de los ingresos que debemos tener. Cuánto más alto pongamos el listón más dinero necesitaremos ganar, de esta forma personas que cobran más dinero las pueden pasar canutas para llegar a fin de mes y personas que ganan menos pueden llegar más desahogadas.

No soy persona de grandes gastos o caprichos, quienes me conocen lo saben, tengo un coche pequeño y que ya tiene algunos años, no uso ropa cara, tengo una hipoteca acorde a mis posibilidades, etc…, por ese motivo mi sueldo actual me permite estar contento, ya que con él puedo mantener mi nivel de vida sin ningún tipo de presión, siendo mileurista la cosa estaría más apretada y tal vez algunos de mis hábitos tendrían que cambiar y esos autoregalos que me hago de vez en cuando (sobre todo por tener la capacidad de poder ahorrar) tendrían que diferirse en el tiempo.

No quiero ganar más dinero para elevar mi nivel de vida (por lo menos no es ese el motivo, aunque tampoco puedo asegurar que teniendo un colchón más amplio, casi sin querer adquiera algún hábito nuevo de gasto) sino porque siento que mi sueldo no está acorde con mi trabajo. Esto es un aspecto muy subjetivo, ya que como es lógico muchos no estarán de acuerdo con ello, pero en este caso, la única opinión que debe tener voz y voto es la de uno mismo.

Quiero dejar claro que respeto totalmente a aquellas personas que decidan llevar un nivel de vida superior o inferior al mío, ya que este tipo de decisiones son personales y yo no soy nadie para decir si mi decisión es más acertada o no en este sentido.

No es fácil salir del mileurismo en términos generales, ya que depende muchísimo del tipo de profesión que tenga cada uno, la preparación, etc… Yo me voy a centrar en lo que conozco que es el desarrollo de software, en donde el mileurismo es un objetivo en demasiadas ocasiones incluso lejano a los que empiezan en esta profesión porque eso es otra, se ha instaurado en las empresas que todos los que empezamos en esto tenemos que ganar poco dinero, ¿por qué? pues porque sí (evidentemente detrás hay motivos económicos y a menor salario, más margen de beneficios por tu trabajo, esto es respetable, ya que las empresas están para ganar dinero, pero también sería respetable, porque nosotros también queremos ganar dinero, que las condiciones laborales medias de los que empiezan en esta profesión sean superiores a las actuales, no obstante veo bastante complicado que esto cambie).

Como la base de partida es pequeña, para empezar a ganar un dinero relativamente decente tenemos que dejar pasar bastante tiempo y comernos bastantes marrones (el tiempo puede ser mayor o menor en función de nuestras capacidades y de que alguien nos apoye, menciono la palabra apoyo porque no solo vale con hacer el trabajo bien, sino en conseguir que alguien lo aprecie de verdad y eso no siempre se va a encontrar).

En el desarrollo de software se sale del mileurismo con paciencia y con trabajo (no son ingredientes ni necesarios ni suficientes, pero son una buena base), si se quieren atajos habrá que ir a buscarlos, que consistirá básicamente en encontrar a alguna empresa que te pague uno o varios escalones más de lo que cobras en la actualidad (por regla general, incluso en etapas como la actual, se puede conseguir), ahora bien, cuando se tome esa decisión hay que hacerlo teniendo muy claras las consecuencias y si el motivo para irse a otro lado es meramente económico mi recomendación es que solo se haga si se tiene claro que realmente en tu trabajo actual tu progresión salarial es por debajo de la que deseas (o necesitas) y resulta complicado romper esa tendencia, esto es así porque si el motivo es solo el sueldo quiere decir que los otros aspectos de tu trabajo resultan satisfactorios (es difícil que exista siempre un solo motivo para algo, generalmente es la suma de ellos lo que nos hace tomar unas decisiones u otras, pero en este caso lo que quiero indicar es que la causa principal, la que tiene un peso que supera al de las demás sumadas entre sí, es el factor económico).

Un aspecto está claro, si uno no mira por uno mismo no debe esperar a que otros lo hagan por ti, por tanto el primer paso para salir del mileurismo lo tiene que dar uno y sobre todo se debe ser consciente de que se puede tardar tiempo en salir de ahí, de hecho incluso a veces es mejor esperar más y tener más base que buscar soluciones más rápidas ya que cuanto más desarrolladas estén nuestras habilidades y mayor sea nuestra experiencia, más valdremos en nuestra empresa y fuera de ella, de manera que tendremos un precio de mercado y ya será decisión de cada uno (del trabajador y de la empresa) determinar la solución a esta ecuación.

Como he dicho en otros artículos hay otros aspectos que sin tener una recompensa económica directa sí que la tiene de forma indirecta. La posibilidad de tener un mayor tiempo libre en el que podamos hacer lo que queramos vale dinero (incluso más que el material), el sentirse integrado, satisfecho y la capacidad de aprendizaje y desarrollar habilidades, también tienen su valor.

Es cierto que llega un momento en la vida de cada persona donde es necesario que el dinero sea el suficiente para colmar sus necesidades (o aspiraciones) y eso solo lo da el dinero físico, el que se refleja en la nómina. Por tanto, es en esta circunstancia o bien la recompensa no monetaria no termina de compensar cuando muchos se plantean buscar otras soluciones, generalmente si aprecian que si situación actual, sin cambios, resulta difícil de cambiar.

La documentación de los proyectos es un asunto muy controvertido y en el que en la comunidad de desarrolladores hay prácticamente tantas respuestas como personas a las siguientes preguntas:

¿Tiene utilidad la documentación de un proyecto?

¿Cuál debería ser la documentación mínima exigible?

En este artículo voy a dar mi opinión siendo consciente de que probablemente gran parte de los lectores no se sienta identificado con la misma, pero como he dicho muchas veces leer o escuchar opiniones diferentes nunca está de más.

Sobre si tiene utilidad documentar un proyecto no puedo dar una respuesta absoluta. Depende. Casi prefiero un proyecto sin documentar que un proyecto con documentación deficiente, ya que el resultado es el mismo y no se habrá gastado esfuerzo en balde. Por tanto para pueda servir la documentación de un proyecto ésta debe ser de calidad. Es importante señalar que no estoy hablando de cantidad, sino de calidad, es decir, la poca o mucha que haya, que sea buena.

Cuando hablo de calidad me refiero no solo a que los modelos e información que se reflejen en los documentos estén bien hechos sino que sean acordes a la realidad de lo que posteriormente se va a implementar. Muchas veces se tiene ejecutado un análisis y un diseño y después cuando se está construyendo se toman determinadas decisiones que no han tenido reflejo en la documentación.

Lo ideal es que además cuando se hablase de calidad lo estuviéramos haciendo en el sentido de que las decisiones reflejadas en la documentación sean adecuadas, es decir, que los requisitos que se hayan tomado sean buenos, que los modelos y arquitectura representados sean coherentes, etc…, sin embargo una documentación puede ser válida aunque se hayan cometido errores en los procesos de análisis y diseño (que, por otra parte, no es solo algo probable sino algo totalmente cierto), lo importante, es que lo que contega, tal y como he comentado en el párrafo anterior sea acorde con lo que se ha hecho y si en la construcción hay que hacer cambios respecto a lo planificado que dichos cambios estén recogidos en la documentación.

Si la documentación es buena sí que puede tener utilidad (no es condición suficiente). Todos (no soy una excepción) hemos renegado de la documentación de los proyectos de desarrollo de software, sin embargo, siempre nos acordamos de ella cuando la necesitamos y no disponemos de la misma (fundamentalmente cuando nos queremos integrar con un tercer sistema o cuando adoptamos un sistema de información que se encuentra en etapas tardías del desarrollo o en mantenimiento).

Otro característica que debe tener la documentación sea útil es que sea sostenible con el futuro mantenimiento del proyecto, si no es así, gran parte de la documentación quedará desactualizada en el proceso de mantenimiento (que recordemos, según Robert Glass supone entre el 40% y el 80% del montante total del proyecto, siendo un 60% mejoras). Por tanto, no debemos pedir en los proyectos, documentación que después no podamos mantener (quedará muy bonito como histórico del proyecto e incluso puede tener una cierta utilidad para comprender los objetivos del mismo, pero al final, si se quiere entrar en detalle habrá que pelearse con el programa). Como es lógico queda fuera de esto la documentación propia de la gestión ordinaria del proyecto como por ejemplo actas de reuniones, documentación de referencia, etc… que forman parte del día a día y que no requieren actualización. También es importante señalar que la estrategia de la gestión de la configuración de la documentación debe permitir que dada una determinada versión del programa, podamos rescatar la que le corresponde a la misma (no es tan fácil como parece).

Hay que tener en cuenta también que aunque se dispongan de los medios necesarios, lo mismo la naturaleza del proyecto no requiere una documentación extensa, eso es necesario valorarlo y no invertir más dinero y esfuerzo que el que realmente se requiere (hay que tener en cuenta que buena parte de los modelos se pueden obtener por ingeniería inversa).

Si la documentación es de calidad y acorde a los medios presentes (y que se estimen futuros) del proyecto ya se va por el buen camino, pero siguen sin ser suficientes para que la documentación cumpla todo lo que debería ser su propósito, ya que no solo debe dejar rastro de lo que se ha hecho y de cómo está en la actualidad el sistema de información sino que la misma debe formar parte del proceso de desarrollo, es decir, la construcción del sistema de información no debe ser una cosa y la documentación otra, sino que lo que se construya debe ser resultado de dicha documentación.

Utilizar la estrategia de integrar la documentación de los proyectos en el proceso de desarrollo no asegura nada, ya que la ejecución final puede ser deficiente, el análisis y el diseño pueden tener errores, etc… y además se pueden construir sistemas que funcionen de manera adecuado sin haber documentación de por medio. Pese a la no existencia de garantías, yo sí creo en que el proceso de desarrollo de software es un proceso de ingeniería y que cuanto más y mejor se aplique mejores resultados se obtendrán.

Por tanto y a grandes rasgos, para que una documentación pueda ser de utilidad debe integrarse en el proceso de desarrollo, ser de calidad y acorde a las posibilidades que se prevén tengamos en el futuro mantenimiento.