archivo

Archivo de la etiqueta: información

Para Alistair Cockburn: “Cada equipo de proyecto debería tener como objetivo reducir el coste total de energía necesario para detectar y transferir ideas”.

Comparto absolutamente esa reflexión. Un equipo que comparte información, la buena y la mala, que conoce lo que está pasando, los objetivos del proyecto y el contexto es un equipo que comprenderá mejor las decisiones que se toman y funcionará más como conjunto que como individualidades.

Si la información no llega, surgirán los malos entendidos, mucha de ella vendrá sesgada (que es casi peor que el hecho de que no llegue), provocará distracciones y distanciamiento entre los miembros del equipo y/o entre el propio equipo y el resto de la organización.

Es importante que todos, absolutamente todos los miembros del equipo tengan acceso a la información del estado actual del proyecto y de los problemas que hay.

¿Qué aporta el oscurantismo?, ¿qué aporta ofrecer solo información interesada?, ¿qué aporta que solo unos cuantos elegidos conozcan la realidad del proyecto? Nada.

¿Cuántas veces hemos escuchado al usuario comentar qué por qué el sistema le solicita una información que ya se encuentra almacenada en el mismo o por qué no le proporciona información calculada que se podría obtener con los datos ya introducidos?

Quitando aquellos casos en los que el usuario se equivoca (porque realmente el sistema no tiene almacenado los datos que él pensaba) es un problema que se produce en muchas ocasiones y que se traduce en la necesidad de un mantenimiento evolutivo del sistema.

Un buen diseño de modelo de datos es muy importante ya que permite que los datos se almacenen de forma que su posterior recuperación o su utilización para devolver datos calculados sea lo más sencilla posible. Un mal diseño del modelo de datos provocará consultas complejas para obtener aquellos datos o información más utilizados en el sistema.

Pero tan importante resulta tener un buen diseño del modelo como conocerlo de manera adecuada. A lo largo de la vida de un sistema diferentes personas habrán participado en el diseño y si no se conoce de manera adecuada dará lugar a un redundancia de datos, un incremento de la complejidad del modelo, un manejo deficiente de los datos, etc…

Sobre esto hay una cita de Rick Lemmons que viene muy bien para exponer este caso: “No hagas que la interfaz de usuario proporcione información que el sistema ya sabe”.

No hay peor síntoma en el funcionamiento de un equipo de proyecto cuando información importante que debe conocer un determinado perfil no le llega o le llega tarde.

Soy de la opinión de que la comunicación en un equipo de proyecto debe ser fluida, de manera que las problemáticas y contingencias sean conocidas por todos, así como los plazos y expectativas del cliente.

Habrá veces que por el bien del proyecto sea conveniente que determinado tipo de información no llegue a todos pero eso debe ser siempre excepciones, debidamente justificadas.

Si la información no fluye, empiezan los malos entendidos ya que cada cual tendrá a rellenar lo que quiere saber y no conoce con lo que está percibiendo y como nadie interpreta lo mismo de igual forma, se crea una brecha que no produce ningún beneficio al proyecto.

Volviendo a un tema que toqué en diversos artículos desde que publiqué mis reflexiones sobre el documental “La oscura era digital” os comento una breve charla que tuve con la responsable de archivo de mi organización.

Resulta que un departamento quiere hacer una limpia importante de documentos que no tienen trascendencia, pero que como suele pasar en estos casos, cuesta deshacerse de ellos por si en algún momento fuera necesario acudir a ellos. Como buena parte de los mismos procedían de listados de un sistema de información actualmente sustituido por otro y en el proceso de migración se mapearon los datos origen a otros distintos (para mejorar, entre otras cosas, la calidad de los mismos), los responsables del departamento querían conservar una copia en el archivo de mi organización, de los datos de la aplicación antigua, los cuales se encuentran todavía en la base de datos de explotación ya que el cambio de sistema se realizó no hace excesivo tiempo y por si acaso, queremos tenerlo a mano por si hiciera falta acudir a ellos (tampoco hubiera habido problema si se hubiera decidido tenerlo almacenado en cinta).

Traté de explicarles que en informática nos encargaríamos de hacer una copia del esquema de base de datos cuando se vaya a quitar de producción pero como es lógico, ellos querían tocar pelo y tener custodiado en el archivo una copia en soporte digital en el archivo. Al fin y al cabo los responsables de los datos son ellos y si prefieren hacerlo así, poco más allá puedo ir.

Una vez que finalmente decidieron la opción del archivo, la responsable de archivo me pidió un manual que permitiera que a partir de la información almacenada en el soporte físico se pudiera recuperar la información en el caso de que sea necesario. Esto puede parecer una petición lógica, pero, ¿se nos habría ocurrido a nosotros?, ¿se nos habría ocurrido qué tal vez dentro de de bastantes años sea necesario recuperar esa información y tal vez la tecnología de base de datos utilizada ya no sea la predominante o bien exista otros paradigmas de almacenamiento de datos?. Lo que parece trivial no lo es tanto y lo expone perfectamente el documental “La oscura era digital”.

¿Persistirá la información digital que actualmente se encuentra dispersa en infinidad de soportes?, en el caso de que persista, ¿se dispondrán de los medios adecuados para leer e interpretar dicha información?. Si no se hace nada al respecto, esta era (la actual) será una época oscura sobre la que no quedó rastro de lo que sucedió en la misma, si se intenta buscar información de la misma dentro de miles de años. Sobre esta base gira el documental “La oscura era digital” (del año 2003) que tuve la oportunidad de ver hace unos días.

Pese a que vi el documental desde una posición un tanto excéptica a sus plantemientos (ya que me pareció excesivamente alarmante, teniendo en cuenta de que gran parte de la información (y mucha de ella muy relevante) sigue (y seguirá teniendo aunque cada vez menos), su reflejo en medios físicos: libros, periódicos, etc…) y que tardé en abrir un poco la mente, al final me quedé con la moraleja de que es necesario de alguna manera buscar la persistencia de la información, pensando en ella no como un bien que necesito mantener en el presente, sino como un bien que se necesita consultar en un futuro (mirando este como algo a muy largo plazo), para ello no basta solo con almacenar los bits de información (que ya de por sí es algo costoso, no solo por su mantenimiento, sino por la sucesiva migración de los soportes que los contienen (la tecnología tiene eso, un avance continuo y progresivo que hace que cada cierto tiempo aparezca una nueva que desbanca a la anterior)), sino que además es necesario persistir la manera en que se interpreta ese conjunto de ceros y unos (sin esas interpretaciones no tenemos nada, simplemente ceros y unos sin sentido)).

Para poder persistir esa interpretación existen diversas posibilidades como por ejemplo almacenar el conjunto de programas y aplicaciones informáticos que permiten interpretarlos (sería algo así como tener un Arca de Noé de software), algo que es complejo debido a la gran cantidad de software que se genera y manteniente a lo que hay que sumar que también habría que almacenar en el arca los sistemas operativos sobre los que funcionaban y una emulación de cada uno de los sistemas físicos que lo soportaban (o disponer de un Arca de Noé del hardware). No obstante, la posibilidad más lógica es persistir la especificación de los formatos de los ficheros lógicos, para ello en primer lugar los formatos deben ser abiertos y por tanto conocidos (sin formatos abiertos esta posibilidad no existe para gran cantidad de información digital, de hecho, gran parte de la información almacenada en formato digital corre el riesgo de no ser interpretada en un futuro, al no ser abiertos sus formatos (lo que hace que o se tiene el software que lo interpretaba (Arca de Noé del software) o no hay nada que hacer (salvo intentar descifrarlo, algo que puede resultar bastante costoso)).

Tras la visión del documental, tengo más claro que nunca que debemos dirigirnos lo más rápido posible al uso de software que permita almacenar ficheros (audio, video, texto, imágenes, etc, etc, etc….) siguiendo especificaciones abiertas, de hecho a la mañana siguiente solicité una serie de modificaciones en el libro blanco de desarrollo de mi organización en lo que se refiere a la documentación de los proyectos (más adelante, no depende de mi, intentaré abordar un tema más complejo como es el de la información documental generada por los sistemas de información, ya que ésta también deberá seguir la filosofía de utilizar soluciones que tengan especificaciones abiertas).

Si importante es un análisis de requisitos, no menos importante es hacer un buen modelo de datos.

Hacer un buen modelo de datos no consiste en abstraer la información que hay que persistir a una serie de entidades que verifican al menos la tercera forma normal. Sino en hacer un modelo de datos inteligible y que asegure un buen rendimiento del sistema. Si hay que desnormalizar algunas tablas se desnormaliza. De nada te vale una base de datos teóricamente perfecta si en la práctica hacer una consulta requiere el cruce de miles de registros.

El modelo de datos es importante y la posterior implementación en el sistema de gestión de base de datos final también, ya que además de verificar las directrices de implementación que indiquen los administradores de base de datos del cliente, se debe realizar una implementación que permita exprimir todas las posibilidades que ofrezca el sistema de gestión de base de datos.

Ya comenté la necesidad de especialistas en análisis de requisitos, aqui también resultaría interesante esa especialización o al menos la existencia de un arquitecto de la información que revise los modelos de datos de los diferentes proyectos, los optimice y se preocupe por realizar la implementación más adecuada en el sistema de gestión de base de datos destino.

Los usuarios en ocasiones desean magia, que se obtengan listados o se obtenga información a partir de datos inexistentes o grabados incorrectamente.

Sin una disciplina en la grabación de datos, los procedimientos de extracción de información y conocimiento son muy costosos y con escasa precisión.

Es importante por parte de los gestores de proyecto, informar a los directores usuarios de la importancia que tiene grabar datos con calidad. Es responsabilidad de los directores usuarios imponer una política entre el conjunto de usuarios orientada al uso correcto del sistema de información y a la grabación de datos precisos y con calidad.