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