archivo

Archivo de la etiqueta: análisis

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.

Anuncios

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.

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