archivo

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

Comenta Frederick Brooks en su libro “The Mythical Man Month” que: “La mayoría de la documentación falla en que se da muy poca visión global. Se describen los árboles, se comentan la corteza y las hojas pero no hay un mapa del bosque”.

Estoy bastante de acuerdo con esa afirmación ya que resulta complejo obtener una visión global del sistema simplemente con la lectura de la documentación del proyecto porque como dice Brooks la información está segmentada y se describe con más o menos detalle cada uno de esos segmentos pero no el funcionamiento en conjunto de todos ellos.

Y todo esto en el caso de que haya alguien que revise la documentación de manera más o menos concienzuda, porque esa es otra, se pueden invertir innumerables horas de trabajo en tratar de hacerla con la mayor calidad posible, pero al final hay personas que tienen que leerla y entenderla y no suele haber gente con mucho tiempo y/o paciencia para iniciar sobre ella un proceso iterativo de revisión y mejora.

Esto es un problema importante cuando se desarrolla basado prácticamente en exclusividad en la documentación y no se suple esa carencia a través de la comunicación con personas que puedan ofrecer la información necesarias para cubrir los huecos en la misma lo que provoca generalmente problemas de coherencia en el sistema y aspectos funcionales a los que el desarrollador da una solución sin entender realmente qué lugar ocupa esa funcionalidad dentro del sistema.

La solución, como comento en el párrafo anterior, es la comunicación y además (y en lo posible) en explicar lo que tiene que hacer el sistema y las expectativas del usuario a quien no haya tenido la oportunidad de conocerlo, algo que generalmente (y desgraciadamente) no se suele hacer.

Un enfoque iterativo incremental de ciclos cortos y el feedback que se obtiene a partir de ellos permite probar la efectividad de los enfoques de los usuarios (que inicialmente no son más que hipótesis sobre lo que quieren) y realizar ajustes que nos van acercando progresivamente a una solución que realmente satisface las expectativas del usuario.

En los enfoques clásicos las hipótesis no se compruebas hasta etapas finales del desarrollo en donde los presupuestos están casi agotados y en donde el tamaño del producto dificulta la realización de modificaciones. Menos dinero, más envergadura del producto, más deuda técnica, menos margen de maniobra.

Todos los que hemos trabajado con ciclos de vida en cascada y/o con contratos llave en mano hemos sufrido esa situación. Da igual lo bien que trates de hacer el análisis que siempre habrá funcionalidades que no se han definido correctamente, que ni siquiera se han definido o que son mejorables y, además, siempre existirán circunstancias a lo largo de la ejecución del proyecto que impliquen cambios de prioridades.

El conocimiento real del producto se va obteniendo conforme se va desarrollando, ¿por qué? pues porque se contrastan las hipótesis y con ello se va mejorando y adquiriendo nuevo conocimiento.

Está bien tener una visión de lo que se quiere pero el detalle se debe trabajar poco a poco, lo demás es correr un riesgo importante de desperdiciar esfuerzo y no nos podemos permitir ese lujo porque en el propio devenir del proyecto y del desarrollo del producto habrá esfuerzo que no proporcione un valor directo, ya que a veces la solución elegida para una determinada funcionalidad deberá cambiar de orientación o ser perfilada en diferentes iteraciones, algo que es normal en cualquier proyecto y que, por tanto, debe contar con suficiente respaldo presupuestario que, como no andará sobrado, es conveniente cuidarlo desde un principio.

La versatilidad y la polivalencia son características muy apreciadas en los integrantes de equipos de trabajo ágiles. Si además, se promueve la rotación de tareas, se entiende que cualquiera está preparado para cualquier actividad que se presente en el proyecto, dotando al equipo de una mayor eficiencia y de una gran flexibilidad que resulta muy útil a la hora de afrontar las diferentes contingencias que, seguro, vamos a encontrar.

Sin embargo, no se debe menospreciar la especialización. No es ágil prescindir a priori de la idea de tener determinados especialistas en el proyecto (en general no es ágil crear restricciones sin analizar la situación).

Un analista es un especialista. Su misión es interpretar las expectativas del usuario, trasladarlas al equipo de proyecto, recoger el feedback y vuelta a empezar. No es un intermediario, sino un facilitador tanto para usuarios como para desarrolladores, no es alguien que está en el medio, sino alguien que está con ellos. Esa es la visión de este perfil en un proyecto ágil.

En un enfoque clásico, la división en procesos hace que los analistas sí que tengan una mayor separación con respecto a los programadores, aunque dependerá mucho de cómo se haya organizado el proyecto, ya que es frecuente también que presten soporte en el proceso de construcción.

Pero incluso en estos casos, la diferencia con un proyecto ágil se encuentra en la intensidad. En el enfoque clásico los analistas dedican un mayor esfuerzo en la fase de captura de requisitos y análisis, en los enfoques ágiles su esfuerzo se mantiene constante, ya que mientras se ejecuta una iteración, preparan la materia prima para la siguiente (interviniendo en ambas tareas con la dedicación que se precise en ese momento en el proyecto).

Existen requisitos que tardan en salir a la luz. A veces el usuario lo da por entendidos, en otros casos se da cuenta más tarde o bien se trata de ajustes sobre alguno de los ya especificados.

Es complicado traducir la imagen abstracta del sistema de información que el usuario tiene en la cabeza que en la mayoría de los casos está como cubierta con niebla y que solo se empieza a ver con claridad cuando nos aproximamos a ella (conforme el usuario tenga más claro el producto final con el que se va a encontrar).

Es importante sacar cuanto antes estos requisitos ocultos a la superficie porque a su vez pueden sacar a la luz otros requisitos ocultos y porque pueden tener importancia en el resultado final del producto. Para ello es importante aplicar enfoques iterativos incrementales para que en cada iteración el usuario esté más cerca del producto final y empiece a ver con mayor nitidez determinados aspectos del producto que está esperando así como aplicar otras estrategias o instrumentos como puede ser el prototipado.

Si el usuario no solicita cambios sobre las especificaciones iniciales es una señal de alarma ya que lo más probable es que no haya dedicado suficiente atención a la especificación de los requisitos, a la revisión de los mismos o a las diferentes iteraciones del producto que se están liberando. ¿Es posible que se haya acertado a la primera? Sí, es posible pero yo por si acaso pondría un intensa luz parpadeante de color rojo como alarma.

Sin esa visión global estás construyendo el sistema a base de retales de manera que funcionalidades que podrían tener una solución general, la tienen de manera particular y eso de lugar a más pantallas, más tablas, más código. Si el sistema es grande y se produce muchas veces este problema estamos haciendo un sistema más complejo, con un mayor coste, más difícil de mantener y más complicado de administrar (a nivel de aplicación).

Como decía en el artículo de ayer, no se trata de hacer un análisis completo del sistema, no me refiero a eso, sino a tener una visión global de qué es lo que se quiere hacer, no se requiere por tanto la formalidad de un análisis de un ciclo de vida clásico y tampoco seguir sus etapas.

Se puede analizar y empezar a construir, así vamos obteniendo feedback del usuario que nos será de mucha utilidad porque esa visión global que nos la da el usuario y el estudio de sistemas de información que viniera utilizando antes para ese mismo proceso (u otro similar existente en otra organización) sigue estando basada en un concepción abstracta del sistema y hasta que el usuario no empieza a ver cosas tangibles no saldrán a la luz comportamientos y funcionalidades que formaban parte de sus expectativas pero que todavía no habían salido a la superficie.

El enfoque clásico o en cascada del desarrollo de software es un modelo de carácter predictivo. Se realiza un análisis del sistema a desarrollar o de los módulos a evolucionar (alcance), se estiman costes y plazos y se trata de gestionar esta agenda (lo que se denomina triángulo de hierro) durante el resto del proceso de desarrollo.

Resulta razonable que pueda funcionar, sin embargo, es un modelo basado en la estabilidad del contexto y en la rigidez de los requisitos y ahí es dónde empieza a tener problemas porque una vez sentadas las bases, lo que cobra prioridad es el cumplimiento de la agenda ya que se entiende que el producto está definido.

La realidad es que los requisitos van a cambiar, conforme vaya avanzando el desarrollo del producto el usuario se dará cuenta de que determinadas especificaciones no son buenas o son mejorables, que se le ha olvidado tal o cual gestión o que las prioridades indicadas tienen que modificarse.

No se trata de que el desarrollador (analista o el componente del equipo que haya hecho ese trabajo) o el usuario lo hayan hecho mejor o peor (por supuesto que un buen trabajo permite trabajar en unas condiciones mucho más favorables) sino de algo que es natural en un proyecto de desarrollo de software y es que haya una evolución ya sea del negocio y/o de la percepción que tienen los usuarios con respecto al sistema de información o algo tan simple y tan frecuente (y humano) como que nos hayamos equivocado.

Esto no es algo que yo me esté inventando, ¿en cuántos proyectos has trabajado en los que no se hayan tenido que cambiar algunos de los requisitos iniciales o se hayan tenido que añadir otros nuevos?.

Como la realidad es esta, tenemos que gestionarla: hay un catálogo de requisitos que permanece vivo a lo largo del proceso de desarrollo.

Como esa es la realidad, los enfoques iterativos incrementales son, a mi juicio, la mejor estrategia para afrontarla, teniendo en cuenta pueden existir proyectos, ¿por qué no?, donde el enfoque clásico sea el más apropiado.

No sé que es peor, si intentar por todos los medios que el contenido del análisis o del catálogo de requisitos sea inmutable o pensar que lo va a ser.

Si has participado en proyectos de desarrollo de software sabrás que (entre otras muchas cosas):

– Los usuarios van aprendiendo conforme el producto se va desarrollando y como consecuencia de ese aprendizaje te van a pedir cambios.

– Lo que en papel o en un generador de prototipos parece sencillo, a la hora de enfrentarse a su construcción puede ser tan complejo que resulte recomendable aplicar otro tipo de estrategia.

– El negocio y/o las prioridades puede cambiar y como consecuencia algunas de las especificaciones iniciales ya no sirven.

En base a estas situaciones pensar que el análisis es inmutable es dejarse cegar por la teoría y exigirlo es ir en contra del valor del producto final.

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%.