archivo

Archivo de la etiqueta: análisis del sistema de información

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.

Te podrás reunir con el usuarios mil veces y las mil veces te cambiará cosas ya sea sobre un análisis o sobre el sistema de información en funcionamiento. En ese camino sin fin hacia la perfección el límite lo pone (o lo debería poner) siempre el usuario en base a las restricciones presupuestarias que tenga el proyecto.

El usuario tiene la llave pero debemos recordarle que se tiene que centrar en sus prioridades y que si invierte excesivo esfuerzo en una determinada funcionalidad es posible que no se cuente con recursos para tener una mínima unidad del producto que sea utilizable.

Es decir, el usuario manda pero tenemos la obligación de comunicarnos con él, expresar nuestras opiniones y de informar sobre los costes, de lo contrario nos encontraremos con una panorama en el que el usuario querrá llegar a mucho más de lo presupuestado y a partir de ahí se entra en una espiral peligrosa en el proyecto que no sabemos realmente hacia donde nos llevará pero que sabemos que ocasionará desgaste, pérdida de dinero y a un producto con una calidad cuestionable.

El usuario siempre estará predispuesto a hacer cambios sobre lo definido y lo implementado algo que se agrava exponencialmente si entran en juego otros usuarios porque cada cual tiene una percepción y gustos distintos. Es cierto que sobre papel y maquetas los cambios tienen poco coste pero también es cierto que son cambios sobre algo que no están viendo en funcionamiento y que les hace tener menos precisión en sus especificaciones (por la complejidad de entender una idea abstracta como es el sistema de información que se va a desarrollar).

Soy partidario de desarrollar con intención y no del prueba y error, también de ir dando pasos hacia adelante y no perdernos en una etapa de análisis sin fin. Alcanzar ese justo medio no es sencillo. Es decir, creo en el desarrollo iterativo e incremental, creo en el desarrollo de software como un proceso evolutivo y creo también que se tiene que entender lo que el usuario quiere y eso puede requerir un tiempo antes de empezar a construir.

En el desarrollo de software los extremos no son buenos. A veces se le da al programador un diseño tan detallado que básicamente lo que hace es traducirlo a código fuente en el contexto del framework con el que trabaja. Otras veces no existe diseño o bien las especificaciones no son completas y son los programadores solos o en colaboración con analistas los que rellenan los huecos.

Desde mi punto de vista es importante que el programador sepa lo que tiene que hacer, es decir, que las especificaciones las conozca y que también conozca los objetivos no funcionales pero sobre esa base es necesario darle libertad para que dentro de esas restricciones pueda realizar la solución que resulta más conveniente.

Es necesario tener en cuenta que si se realiza un desarrollo en base a un análisis y/o diseño que se realizó hace tiempo es muy posible que quien lo hiciera no tuviera en cuenta determinados factores que sí son conocidos en el presente y no resulta lógico no echar cuenta a una solución mejor por tener en cuenta un trabajo que se efectuó sin conocer determinados tipos de detalles.

También es importante precisar que ese margen de maniobra permite que el programador dentro de esas restricciones pueda expresar su creatividad (algo que todos llevamos dentro) y realice su trabajo más motivado, algo que todos sabemos termina produciendo resultados de mayor calidad.

Como siempre es importante evaluar el contexto. No hay verdades absolutas. Es posible que en determinadas situaciones tener un nivel de detalle importante resulta fundamental, por ejemplo, cuando se externaliza a otro equipo de trabajo las tareas propias de programación de un desarrollo (o parte de él), aunque incluso en estos casos hay que tener en cuenta que la comunicación seguirá siendo necesaria (y se debe considerar un problema si no la hay) porque siempre quedará algún detalle que no se ha especificado al 100%.

Es más, es posible que el que conozcas o que el que se defina en un análisis de un sistema de información no te lleve a ella. Es más, es posible que tengas que coger diferentes rutas para alcanzarla, que muchas de ellas se descubran por el camino, que incluso tengas que desandar parte de lo avanzado o que tal vez, tengas que conformarte con un objetivo más acorde al contexto en que se ha desarrollado el proyecto. Y en otras muchas ocasiones te termines quedando en el camino.

Eso es el desarrollo de software, saber a dónde se quiere ir, aceptar la incertidumbre y estar lo más preparado posible para adaptarse al cambio y que dicha adaptación requiera el menor esfuerzo posible.

En estos caminos habrá obstáculos, eso es seguro, unos serán sorteables (no sin esfuerzo), a veces nos encontraremos con otros que obligarán a abandonar parte del equipaje y no podremos llegar tan lejos como quisiéramos y en otros los obstáculos no nos permitirán llegar siquiera a un destino aceptable o nos dejarán tirados en medio del camino o de la nada.

Así es el desarrollo de software.

No contar con los interlocutores adecuados es una causa muy común de fracaso en un proyecto de desarrollo de software.

Entre los principales errores que se suelen cometer en este sentido se encuentra la selección de interlocutores que no participan en el día a día de la ejecución de un proceso. Esto normalmente lleva a soluciones que están alejadas de las necesidades reales de los usuarios reales del sistema de información.

¿Y si se quiere aprovechar el nuevo sistema para hacer cambios en el proceso? Mi consejo es que esos cambios se realicen siempre que sea posible antes de que la aplicación se haya puesto en marcha, recordemos el mantra de que “la informática y el software no resuelven problemas organizativos” y que en el caso de que sea a la vez, todo el mundo tenga muy claro previamente la dirección a la que nos dirigimos.

En cualquier caso, con cambio de proceso o sin cambio de proceso, en la definición de las funcionalidades de un sistema de información, así como para la transmisión de las expectativas en relación a la experiencia de usuario tienen que intervenir representantes de los que van a utilizar el sistema de manera cotidiana, sin que ello suponga restricción alguna a que puedan intervenir, incluso coordinando todas las consultas a las diferentes áreas usuarias, personas que tengan un perfil orientado más a la gestión, es más, alguien al final tendrá que resolver posibles situaciones de conflicto en cuanto a la visión de los procesos y establecer prioridades, lo que hará necesario a que de manera directa o delegada tenga la suficiente autoridad para hacerlo.

Hasta que el usuario no interacciona con el producto software no comprueba si sus expectativas están satisfechas.

Las expectativas van más allá de una visión funcional del software ya que es absolutamente fundamental que el usuario tenga una buena experiencia de uso. Tal vez usuarios con una gran capacidad de abstracción y que hayan dedicado mucho tiempo al proyecto puedan atisbar antes de interactuar con el producto si funcionalmente les satisface, pero la experiencia de uso no se tiene hasta que se utiliza.

Por ese motivo las metodologías clásicas no terminan de producir buenos resultados, ya que entienden que es posible acertar con todo desde el análisis y que si no, ya vendrá el mantenimiento. El problema que suele producirse en estos casos es que el presupuesto de mantenimiento no existe o de existir suele ser inferior a la envergadura de los cambios que van a ser necesarios.

El feedback del usuario es fundamental desde las etapas más tempranas posibles del desarrollo, de ahí la necesidad de ir construyendo y liberando el producto de manera progresiva.

Los enfoques clásicos se basan en una especificación detallada de requisitos para, a partir de la misma, proceder al desarrollo del producto, de manera que la relación con los usuarios es más intensa en ese momento y vuelve a recobrar importancia cuando se acerca la implantación del sistema.

Mientras tanto, habrá reuniones de seguimiento para informar al área usuaria del estado del proyecto, en las que se podrían mostrar incluso funcionalidades del producto ya implementadas. Estas reuniones sirven sobre todo para mantener tranquilo al cliente, ya que el tiempo que transcurre entre el análisis y la entrega puede ser significativo.

Esta estrategia de desarrollo supone que las especificaciones se van a mantener estables durante el proceso de construcción.

Ahí acaba la teoría porque todos sabemos lo que pasa en estos casos: los requisitos permanecen abiertos hasta el final porque el usuario se irá dando cuenta de funcionalidades que no ha descrito de manera adecuada o de nuevos módulos que quiere incorporar al sistema.

Por tanto, se ha realizado un esfuerzo importante en tener unos requisitos al detalle y lo normal es que más adelante un buen número de los mismos se tengan que redefinir. Ojalá el problema solo fuera ese, ya que el principal es que en muchos casos, estos cambios se solicitan demasiado tarde, cuando buena parte del producto ya está construido, por lo que el coste de hacer las modificaciones suele ser importante.

Y ahí es donde entran en conflicto desarrolladores y área usuaria porque los segundos entienden de manera equivocada y por regla general, que los cambios son de escasa entidad y que el proveedor debe soportarlos.

Las estrategias, enfoques y metodologías ágiles parten de la visión del producto, de tal forma que no es necesario tenerlo especificado al detalle sino de tener presente qué se tiene y a dónde se quiere ir. En este contexto, solo es necesario tener especificada la materia prima de la siguiente iteración (aunque normalmente se trabaja mirando un poco más hacia adelante).

Por tanto, no se define el sistema por completo, sino que vamos trabajando con las funcionalidades más prioritarias (sin perder la visión del producto) y al final de cada sprint se obtiene el feedback del usuario que le permitirá ir haciendo ajustes sobre lo definido.

De esta forma, se hace el esfuerzo que necesita el sistema, no requiere esos largos períodos de análisis que terminan en documentación en donde buena parte de ella no termina ajustándose al producto final (salvo que se haya hecho el esfuerzo considerable de ir actualizándola). Y no solo eso, permite incrementar el valor del producto conforme se desarrolla, a diferencia del enfoque clásico que limita el valor (teóricamente) al que existe en el momento en que se aprueba el análisis.