archivo

Archivo de la etiqueta: análisis funcional

Como comenté en el antipatrón “Escuela de traductores” se espera por parte del proveedor que aporte valor a la solución, no por su cuenta, sino enriqueciendo las soluciones que especifican desde el área funcional, así como asesorando, mirando por los intereses del cliente (por encima de los suyos propios).

Se nota mucho cuando un equipo de proyecto incurre en ese antipatrón, un caso concreto lo tenemos en aquellos casos donde los requisitos recogidos no proporcionen una especificación completa de una determinada funcionalidad, donde las culpas siempre se dirigirán al usuario, aunque sean de materias de preescolar de programación o de análisis funcional.

Ahí es donde está la diferencia entre “equipos grandes” y “equipos pequeños” en el desarrollo de software, entre ser de primera división o de tercera, ¿con quién prefieres trabajar tu?.

Los requisitos funcionales y no funcionales de un sistema de información determinan el mapa inicial de lo que los usuarios esperan del sistema. Se trata de una predicción sobre lo que que quieren y que después tendrán que constrastar con el producto final.

Lo normal es que exista una diferencia entre una versión de un producto y lo que se esperaba de ella, por lo que después son necesarios mecanismos de ajustes que disminuyan esa distancia a unos umbrales razonables o que la eliminen. Lo ideal es que esa diferencia sea la menor posible y los analistas funcionales y orgánicos y los responsables de codificar el proyecto intenten que así sea, sin embargo los proyectos de desarrollo de software están sometidos a muchos factores que afectan negativamente a ese objetivo.

En cualquier caso, los requisitos representan necesidades y expectativas de los usuarios y es necesario, por tanto, conocerlos y tenerlos en cuenta como referencia en el desarrollo del producto software.

Por tanto, este área de proceso requiere que los requisitos estén perfectamente identificados y, además, sean conocidos y entendidos por todos los implicados en el proyecto (equipo de proyecto, usuarios, responsable técnicos del cliente, etc…).

Otro de los requerimientos de este área es que se tenga control sobre el cambio en los requisitos, para ello es necesario que solo un grupo reducido de personas tengan la capacidad de decidir en ese sentido.

Esto no quiere decir que cualquier usuario no pueda proponer cambios, antes al contrario, cualquier aportación debe ser acogida de forma positiva, el matiz en este caso, es que esas propuestas deben ser analizadas por unos pocos (que se entienden que son designados como expertos del proceso o procesos que se informatizan) y que con el asesoramiento de los técnicos software (sería lo más recomendable) toman la decisión sobre qué cambios realizar, cuáles no y en definitiva, cuáles son las prioridades.

Ante una decisión de cambio en los requisitos, este área de proceso tiene el requerimiento de que el resto de artefactos/entregables del proyecto se mantengan consistentes.

Por este motivo hay que tener mucho cuidado a la hora de definir los entregables documentales de un proyecto, ya que cuántos más y más complejos sean, mayor será el esfuerzo necesario para ponerlos consistentes. Es importante apoyarse en herramientas CASE para facilitar la consecución de este objetivo.

Otro requerimiento es la trazabilidad bidireccional y sobre esto habría mucho que hablar. Si se toma al pie de la letra quiere decir que debería poder conocer todos los componentes de ingeniería del software y del producto software (a nivel de clase) asociados a un requisito y también en el sentido contrario, es decir, que partir de una clase se sepa a qué requisito o requisitos puede afectar un cambio en la misma. El objetivo de esto es poder realizar un análisis de impacto y servir también de soporte para la detección de inconsistencias entre los requisitos y los productos derivados del proyecto (incluido el propio sistema de información).

Sin embargo, esta trazabilidad bidireccional resulta costosa de conseguir y no resultaría aconsejable su aplicación en determinados tipos de proyectos (se estaría matando moscas a cañonazos) y en otros, llegar a nivel de clase en el código no aportaría mucho ya que la organización en capas, de las clases, etc… viene condicionada por el generador de código utilizado y el framework.

Para poder respectar en lo posible este objetivo, es importante definir un nivel de entregables documentales acordes a la naturaleza del proyecto (maś entregables, más complejidad, así que hay que tener cuidado con esto) y tener un conocimiento del framework de desarrollo y de la arquitectura de la aplicación, de manera que se sepa de manera rápida donde hay que mirar para conocer el impacto de la modificación de determinados requisitos (lo que se hace es mirar de más arriba la codificación de la aplicación y no entrar a un detalle a nivel de clase). También resulta fundamental un código lo más claro y limpio posible.

Sobre la trazabilidad lo importante, entiendo que debe ser quedarse con el espíritu de la misma y tener unos procedimientos en el proyecto que permitan hacer un análisis de impacto y análisis de consistencia en un tiempo razonable. Hay que recordar que CMMI establece un modelo de referencia, determina el qué pero no el cómo.

Existe una diferencia entre la percepción del desarrollador, la percepción de los usuarios y el universo de discurso. Hay que tener en cuenta que los usuarios son expertos en los procesos que manejan y aunque el desarrollador conozca bien el negocio, cada organización es diferente y lo que en una funciona, en otra no necesariamente tiene que dar los mismos resultados.

También hay que tener en cuenta que el desarrollador es el que conoce las limitaciones de la tecnología que va a utilizar, en el sentido sobre todo de la dificultad y coste de los que se pide (más que en el sentido de si se puede hacer o no), por lo que su percepción también es valiosa.

Habrá proyectos donde diferentes desarrolladores participen en las etapas de análisis y cada uno de ellos puede entender el problema de una manera, no necesariamente diferentes, pero tampoco idénticas.

Visiones diferentes requieren del consenso y comunicación entre usuarios y desarrolladores para que se pueda reducir esa diferencia entre lo que se cree que se quiere y lo que se quiere realmente, objetivo que necesitará también saber elegir en cada proyecto de forma adecuada la proporción de la visión de los usuarios y desarrolladores que llevará la fórmula (además de seleccionar los ingredientes que aporta cada uno).

Richard (Dick) E. Fairley es una profesor universitario y autor americano especialista en ingeniería del software y sobre tema comenta lo siguiente (traducción libre): “En el sentido más real, el ingeniero de software convierte modelos de situaciones físicas en software. El mapeo entre el modelo y la realidad que ha sido modelada se conoce con el nombre de distancia intelectual entre el problema y la solución computerizada del problema.

Uno de los objetivos principales de la ingeniería del software consiste en diseñar productos software que minimicen la distancia intelectual entre el problema y la solución; sin embargo, la variedad de posibles soluciones en el desarrollo de software solo está limitada por la creatividad e ingenuidad del programador. En muchos casos no está claro cuál de las soluciones es la que minimizará la distancia intelectual y a menudo diferentes soluciones podrán minimizar diferentes dimensiones de la distancia intelectual”

Lo fácil puede ser optar por la estrategia de tú me pides, yo lo hago. Sin embargo, la mejor estrategia es, tu pides, yo lo analizo, te comento los riesgos (si hay), tu decides y yo ejecuto.

Hay veces que el usuario o el cliente pide una funcionalidad, que lo mismo es algo accesorio o que no es importante, que lo mismo puede ser útil pero que al fin y al cabo no es necesaria para que pueda desempeñar sus tareas de manera más o menos eficiente a través del sistema de información. Ellos pagan, luego tienen la posibilidad de pedir, pero lo mismo se piensan dos veces una determinada petición si se les explica las “contraindicaciones” que tienen la realización de la misma.

Porque, ¿cuántas veces ha llevado la realización de una mejora o la implementación de una nueva funcionalidad a una versión peor del producto? si nos ponemos a pensar, es más que probable que cada uno tengamos varios ejemplos.

Tanto si vamos a trabajar con metodologías ágiles, como con otras metodologías como RUP y sobre todo, en ciclos de vida clásicos o en cascada, resulta fundamental delimitar cuanto antes el alcance del proyecto.

Como mínimo hay que llegar a una primera aproximación en la negociación del contrato con el cliente (cuanto mejor sea la misma, más variables se tendrán a favor para hacer una correcta valoración en esfuerzo y plazos del proyecto) y es más que recomendable hacer otra aproximación al inicio del proyecto.

Acotar el alcance no debe ser entendido como poner límites al proyecto, al menos en el sentido estricto, ya que a través de la propia evolución del software, la aplicación tenderá a ir hacia donde van las expectativas del usuario. Pero sí se debe entender como un marco hacia donde enfocar el desarrollo, ya que no todas las funcionalidades que se quieren implementar son iguales de prioritarias o críticas.

El proyecto debe centrarse en lo verdaderamente importante, dejando para más adelante aquello que no lo es. Probablemente no habrá presupuesto (por lo menos en primera instancia) para todo, por lo que lo primordial es cubrir lo que resulta necesario.

Si no delimitamos el alcance, se quedarán demasiadas puertas abiertas por detrás, con el riesgo de que el cliente o usuarios quieran volver a ellas. Es cierto que al final el proyecto va hacia donde quiere el cliente o los usuarios, pero no es lo mismo tener pactado por escrito un alcance que no tenerlo y no es lo mismo hacer pedagogía desde el inicio del proyecto que no hacerla.

En el último artículo que publiqué sobre la temática de los casos de uso, un lector me dejó el siguiente enlace (en inglés): Cómo implementar operaciones CRUD en UML, en el que como respuesta se indica que si la representación en los diagramas/modelos no aportaba valor, tal vez la mejor solución pasaba por no representarlos.

Y me parece una buena propuesta, ¿por qué no?, sin embargo sí que soy partidario que cómo mínimo, en el caso de los casos de uso se estereotipen los que se correspondan a gestiones CRUD y que se haga referencia a un guía, libro blanco, etc…, de la organización en la que se especifique cómo debería ser el comportamiento en este caso, en los maestros/detalle o en cualquier otro tipo de figura que se quiera estandarizar.

Los generadores de código suelen resolver la problemática del CRUD, sin embargo, no todos la resuelven de la misma manera. Si existen diversas empresas que desarrollan para tu organización, te encontrarás con que utilizan diversos generadores y la solución de salida será distinta, algo que en la medida de lo posible resulta interesante evitar.

Dentro del libro blanco de desarrollo de una organización o de las normas de calidad del software resulta de mucha utilidad contar con un catálogo de validaciones.

Este catálogo define de manera única cómo validar determinados tipos de atributos como por ejemplo un NIF.

Cuando se esté especificando un requisito funcional (o cualquier otra técnica que se utilice para representar lo que quiere el usuario) y se quiera indicar cómo validar esos atributos, bastará con referenciar al código de validación que le corresponda a cada uno (no teniendo que volver a repetir en qué consiste la validación lo cual a su vez puede ser fuente de errores si no se expresa con las mismas palabras lo que ya está definido en el catálogo de validaciones).

Antoni Gaudí utilizaba los planos, sus modelos en yeso y otro tipo de abstracciones de lo que posteriormente serían sus obras como un instrumento de trabajo, posteriormente estaba a pie de obra y se encargaba personalmente de solicitar modificaciones sobre el proyecto base.

No hace mucho escuché una entrevista a Achero Mañas donde comentaba la necesidad de adaptar los guiones en el propio proceso de rodaje de la película porque lo que parecía funcionar en papel, no conseguía transmitir lo que él quería cuando se llevaba a cámara.

En el desarrollo de software lo especificado en el análisis podría perfectamente adaptarse a lo que he comentado en los dos párrafos anteriores, es decir, por mucha capacidad de abstracción que se tenga, posteriormente (puede que en el diseño, en la construcción o en el mantenimiento) será necesario realizar modificaciones sobre la propuesta base, ya que la falta de flexibilidad en estos casos, puede ir a favor de la agilidad y la rentabilidad en el proceso de desarrollo pero en contra del éxito en la implantación del sistema de información.

¿Hasta dónde se puede ser flexible? Salvo que el proyecto cuente con un presupuesto muy por encima del necesario para desarrollar el producto y además se cuente con unos plazos de entrega holgados es necesario establecer ciertos límites, no obstante, pienso que muchos problemas se podrían solucionar mediante la aplicación de una metodología adecuada, es decir, seguirá siendo necesaria la flexibilidad pero el objetivo será reducir el número de casos en proceso de desarrollo.

Cada vez soy más partidario de realizar el análisis utilizando como base prototipos, ya que los usuarios nos tienen que especificar lo que quieren y a través de los prototipos les resulta mucho más sencillo. También soy cada vez más proclive a que el proceso de desarrollo (más concretamente el diseño y construcción) sea iterativo, es decir, vamos liberando y pasando a explotación módulos de la aplicación (aunque partiendo de un análisis global realizado a partir del trabajo con el prototipo), tal vez las primeras versiones todavía no tengan funcionalidad suficiente para que el sistema entre efectivamente en producción, pero hará más sencillo la localización de errores, simplificará los posteriores pasos a explotación del resto de módulos y también permitirá que el usuario pueda empezar a familiarizarse con el sistema y a poder solicitar cambios (ahí es donde entra en funcionamiento la flexibilidad) que modificarán el análisis y en consecuencia futuras iteraciones.

¿Sirven para algo los casos de uso? En una charla con un grupo de amigos, uno de ellos hizo esa pregunta y se hicieron unos cuantos segundos de silencio.

Supongo que cada uno tendrá su experiencia y por tanto los casos de uso tendrán sus detractores y defensores. No es el objeto de este artículo analizar quién puede tener razón sino tan solo ofrecer mi punto de vista, acertado o equivocado.

Los casos de uso según Métrica versión 3, tendrían un doble propósito:

– Servir de herramienta para la especificación de requisitos ya que ayuda a los usuarios a reducir la complejidad de abstraer la aplicación que quieren que se desarrolle (o se mantenga).
– Guiar el proceso de desarrollo.

Tal vez no haya tenido suerte, pero en todo el tiempo que llevo en este negocio, no he tenido la oportunidad de estar en proyectos donde los casos de uso hayan resultado decisivos para la especificación de requisitos (es más, en la mayoría de las situaciones ha sido un producto que ha derivado de los requisitos o que se ha obtenido posteriormente) o para el proceso de desarrollo.

En lo que a la especificación de requisitos se refiere, los usuarios prefieren la especificación de requisitos en lenguaje natural (y ellos poder discutirlos) y trabajar con posibles interfaces de usuario. Los diagramas de casos de uso siguen siendo de otra galaxia y hay que explicárselos muy bien para que lo entiendan.

En mi opinión, para que los casos de uso tengan utilidad real hay que trabajar bien los diagramas y sobre todo realizar la especificación de cada caso de uso y eso requiere un gran esfuerzo importante en el momento en que la aplicación tiene una cierta complejidad y si se quiere que realmente el usuario entienda paso a paso las distintas funcionalidades que el desarrollador ha ido detectando en las distintas sesiones de recopilación de requisitos. Por supuesto, en todo lo anterior, es conveniente que el usuario esté asistido si así lo requiere, ya que es posible que tenga alguna duda en la interpretación de lo que está viendo y leyendo.

Un proveedor me comentó un día que el mayor enemigo para la calidad del software es el tiempo, entendiéndose este en sus dos vertientes: en las existencia de fechas de entrega y que los costes del proyecto están directamente relacionados con el tiempo dedicado al mismo.

Desde luego que no le falta razón, pero estoy seguro que el simple hecho de tener más tiempo o algo de más presupuesto no implica tener un producto de mayor calidad. Muchas veces disponer de más tiempo supone simplemente tener más tiempo que perder.

Por tanto, el tiempo puede ser un factor importante pero más lo es la existencia de unos procesos internos de revisión funcional y de código de las aplicaciones. Ahí sí que se marca la diferencia. Cuesta dinero, claro que sí, pero ¿más que tener que dedicar tiempo al proyecto una vez entregado teniendo en cuenta que probablemente interrumpirá otras actividades en otros proyectos?, ¿más que los beneficios que se obtienen por tener una imagen de empresa asociada a la calidad de los desarrollos?.

Como he comentado en otros artículos, la calidad del software no empieza por el final, es decir, por retocar lo ya construido porque eso es costoso, sino que parte desde la realización de un buen análisis funcional (el principio de todo), pasando por la seleccion de una arquitectura y framework que sienten las bases para un desarrollo posterior de calidad, no asegura nada, pero mejor partir de una buena base que carecer de ella.

Desde que comienza a codificarse tomando como base el framework empezarán las desviaciones en cuanto a la calidad del producto final desde el punto de vista de la programación, como es lógico si el análisis no es bueno, las deficiencias empiezan desde antes, pero si a un análisis mejorable le sucede un diseño o una codificación mala, serán mayores los problemas a los que tengan que enfrentarse cliente y proveedor en un futuro debido a que cuando se tenga que tocar la aplicación para ajustar los requisitos funcionales costará muchísimo más trabajo si el código no facilita el mantenimiento.

Por ese motivo las revisiones funcionales y de código deben empezar desde el principio ya que cuanto más tiempo pase hasta que se detecten los defectos más costoso será tomar soluciones, tanto, que determinados tipos de problemas se obviaran debido al coste que tendría solucionarlos. ¿Tiene esto un coste? Desde luego, ya que las revisiones además deberían hacerlas personas ajenas al equipo de desarrollo, pero realmente la clave está en pensar que la entrega de un mal producto implica que ese coste (probablemente mayor que la inversión a realizar por aplicar estas revisiones) repercute tras la entrega en lugar de repartirse a lo largo del proyecto.

Tengo muy claro que la mayoría de los proveedores de desarrollo de software estarán en desacuerdo con este artículo por la sencilla razón de que habla de un “mundo ideal” en el que el cliente es un comprensivo corderito y desde ese punto de vista tengo que dar la razón, ya que el cliente va a ser exigente y además de eso va a tratar de meter evoluciones del producto dentro de la garantía y eso va a pasar independientemente de si el trabajo ha sido bueno o malo o si la calidad del software ha sido óptima o regular. Llegado a ese punto toca negociar y mejor hacerlo siempre con un producto en las mejores condiciones ya que será más fácil hacerlo teniendo el as en la manga de una buena ejecución y también porque las modificaciones que haya que hacer se realizarán con mayor facilidad.

Sé que esta estrategia de revisión continua se ve como ciencia ficción en el mundo real, lo cual no quita que piense que puede traer buenos resultados e incluso haciendo media, una reducción de costes en los proyectos tanto para el cliente como para el proveedor.