archivo

Archivo de la etiqueta: modelo de datos

Existen muchas formas de modelar la realidad, todas ellas válidas. Sin embargo el hecho de que sea válida no quiere decir que el modelo de datos sea bueno.

Un modelo de datos más complejo de lo necesario será a la larga una fuente de problemas porque aunque esté escondido en las capas más profundas de la aplicación condiciona sin lugar a dudas todo lo demás.

A veces el modelo lo hace complejo el desarrollador, otras muchas veces el usuario que pretende almacenar información o relacionar entidades que después no va a poder mantener. Es conveniente hacerle ver al usuario si efectivamente esa complejidad adicional que va a introducir le va a aportar algún valor y si incluso aportándole van a tener recursos suficientes para mantener los datos actualizados y con calidad.

El desarrollo de software requiere cooperación e interacción, no se trata en este caso de contaminar al usuario sino de hacerle reflexionar sobre la situación, a veces una segunda o tercera pensada evita malgastar esfuerzos presentes y futuros.

Los modelos de datos deben ser lo más simples posibles sin que se pierda información que el usuario necesita (realmete) para su gestión. Si hay que dedicar algo más de tiempo en él es una inversión que al final será amortizada.

Se trata de otro antipatrón muy típico. Se dice que un sistema de información es una gran bola de lodo cuando su desarrollo no ha seguido una lógica, patrón o estructura común, es decir, no se ha respetado una arquitectura, no se ha gestionado adecuadamente el modelo de datos de la aplicación (nomenclatura no apropiada para los objetos, datos duplicados e incoherentes, etc…), no se han seguido prácticas comunes de programación y gestión de la configuración, no se han respetado buenas prácticas que minimicen la deuda técnica, se ha descuidado el rendimiento del sistema, etc…

Como podréis ver, este antipatrón se produce como consecuencia directa de la aplicación de otros antipatrones.

Se le denomina gran bola de lodo porque aunque el sistema funcione (y es cierto que aunque sea milagrosamente algunos sistemas así llegan a funcionar e incluso son aceptados por los usuarios) su mantenimiento es insufrible: requiere un gran esfuerzo (coste) y cada paso a producción de una nueva versión o un nuevo parche lo haremos con gran temor por mucho testing que hagamos, ya que el acoplamiento será tal que un cambio en un elemento podrá provocar errores hasta en el punto más insospechado de la aplicación.

¿Qué circunstancias puede llevar a sistemas de estas características? Muchas. Generalmente se tratará de sistemas en los que han participado diferentes equipos de trabajo sin existir una coordinación real o eficaz entre los mismos, en desarrollos donde los equipos de proyecto tenían una rotación alta y, como en el caso anterior, no ha existido una continuidad en la coordinación, en mantenimientos donde se han sucedido equipos distintos incluso de empresas distintas, etc…

Por supuesto, todo lo anterior se podría evitar o minimizar si además de esa coordinación, existieran unos mecanismos adecuados de control de calidad.

¿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”.

Me comentó hace poco un amigo que el pilar principal en el que se tiene que sustentar un proyecto de desarrollo de software es la realización de un buen diseño del modelo de datos.

Por un lado implica que se han capturado adecuadamente los requisitos de almacenamiento y por otro que su traslación al modelo ha sido adecuada.

Aunque pueda parecer sorprendente la calidad de los modelos de datos deja mucho que desear: falta de normalización cuando lo que conviene es normalizar, falta de desnormalización cuando lo que conviene es desnormalizar, modelos complejos en lugar de soluciones simples, etc… y como bien dice mi amigo: “Por muy bien que construyas el edificio si los cimientos no son sólidos terminará tambaleándose”.

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.

Uno de los aspectos que más me preocupan en el desarrollo de proyectos informáticos es que el producto llegue al entorno de producción con el menor número de errores funcionales, que tenga un buen rendimiento y sea fácilmente mantenible a nivel de código y de documentación.

Esto que parece de perogrullo, es tremendamente difícil sobre todo si nos encontramos con proyectos de una gran envergadura con un parque de usuarios heterogéneo en localizaciones dispersas con distintos nivel de calidad en su ancho de banda.

Después de analizar las metodologías de desarrollo clásicas como Métrica v.3 y tratar de hacer uso de ella en mis proyectos (más bien un subconjunto de ella, pero aunque sea un subconjunto, por definición de Métrica v.3 sigue siendo Métrica v.3) he llegado a la conclusión de que sin ser una mala opción, hay algunos aspectos que sí es conveniente centrarse y en otros menos:

– Plan de proyecto. Contendrá el cronograma del proyecto (lo mejor es que ese cronograma se mantenga con una herramienta informática compartida: Redmine, dotProject, etc…), por lo que valdrá con una referencia a la url donde se puede seguir el cronograma del proyecto, el equipo de proyecto (igualmente lo mejor es que ese equipo de proyecto se vaya actualizando, por tanto lo mejor es una herramienta informática compartida y si es la misma que la del cronograma, mejor que mejor y se sepa si así lo desea el cliente su imputación de horas al proyecto) y la documentación que deberá acompañar al proyecto.

– Lo fundamental en un proyecto de desarrollo de software son los requisitos. La empresa que posea analistas con la suficiente capacidad para obtener del usuario lo que quiere (cosa tremendamente difícil) tienen una ventaja muy importante respecto a sus competidores. Este catálogo de requisitos es fundamental tenerlo actualizado en todas las fases del proyecto, incluido el mantenimiento. Si es necesario dedicar tiempo a una fase del proyecto concreta esta es el análisis de requisitos. El catálogo de requisitos debe ser completo y fácilmente inteligible por el usuario. Si hay presupuesto en el proyecto y puede facilitar el proceso de desarrollo el analista puede trabajar con los diagramas de casos de uso.

– Modelo de datos. Muy importante tenerlo documentado en la versión 1 del proyecto. Para posteriores versiones, si en el mantenimiento hay presupuesto y tiempo (aspectos no siempre disponibles) se puede mantener la documentación del modelo de datos, en caso contrario no pasa nada, siempre hay herramientas que te los puede obtener por ingeniería inversa a través de la base de datos.

– Interfaz de usuario. Es fundamental que el usuario conozca y valide la interfaz de usuario, ya que es donde ellos van a trabajar, de nada vale saber lo que quiere el usuario si después la interfaz de usuario no es ágil. Por este motivo también conviene invertir en esta fase del proyecto. Cuanto más se aproxime esta interfaz de usuario a su implementación real, más conciencia tendrá el usuario de lo que se va a encontrar y por tanto más posibilidades de éxito existen en el proyecto.

– Arquitectura del sistema. Debe ser breve, conciso y cuanto más gráfico mejor. Es importante para proyectos donde se deleguen funcionalidades en terceras herramientas (motor de tramitación, plataformas de autenticación y firma electrónica, etc…).

– Plan de pruebas (unitarias, integración, sistema, implantación y aceptación). Aunque es una realidad que nosotros, los clientes, tengamos nuestros propios medios para garantizar la calidad de las entregas, son absolutamente necesarias dos premisas: Que la empresa desarrolladora realice un primer filtro de pruebas muy importante (nunca es perdido el tiempo que se dedica a probar) y que se entregue un manual de pruebas al cliente donde como mínimo se pueda garantizar, tras realizar las pruebas, que el sistema funciona y que además verifica los requisitos funcionales y no funcionales más importantes.

– Manual de usuario. Debe estar siempre actualizado. Ser muy completo y tener casos de uso reales en los que se refleje, al menos, el 90% de la casuística del programa. Si el manual está accesible on-line por los usuarios mejor que mejor, independientemente de eso es aconsejable que sea también fácilmente imprimible.

A todo lo anterior es necesario sumar la necesidad de utilizar un sistema de control de versiones buenos, como por ejemplo Subversion y hacer un buen uso del mismo (política correcta de etiquetado de versiones, etc…), utilizar unos mecanismos estándar para el despliegue de los proyectos: MAVEN + Hudson + Artifactory, por ejemplo y algo fundamental, un libro blanco de desarrollo que homogeinice los desarrollos que se realizan para tu organización.