Malas Prácticas: Documentos Funcionales Ligados a la Tecnologí­a

Hasta el momento solo habí­amos hablado de malas y buenas prácticas que estaban asociadas a labores de construcción de bajo nivel, pero, éstas, aunque siendo sin duda malas prácticas, quedan bajo la sombra que provocan otras prácticas de dudosa viabilidad que se llevan a cabo en niveles más altos, y sobre las que el impacto en un proyecto de desarrollo de software es aíºn mucho más pesado.
Un ejemplo muy claro es el incluir en un documento de descripción de la funcionalidad (Documento funcional o de Requerimientos o como estéis más acostumbrado a llamarlo), descripciones que tienen que ver con la parte técnica. Si además de describir cómo ha de comportarse algo funcionalmente, incluimos la pantalla asociada a la funcionalidad en el mismo documento, y además describimos lo que tiene que hacer la pantalla (si pulso aquí­ se desplegará un meníº, si hago botón derecho me saldrán las opciones “juan” y “pedro”, si paso el ratón por encima de la zona central se mostrará un aviso indicando el nombre del formulario…) estamos haciendo el documento funcional totalmente dependiente de la tecnologí­a a emplear, cuando este íºltimo deberí­a limitarse íºnicamente a describir el negocio de la aplicación.
De ahí­ que, bajo mi punto de vista, así­ como el uso de diferentes capas a la hora de definir una arquitectura de software es una buena herramienta de diseño, aplicar el mismo concepto a la documentación funcional también lo es.
Serí­a interesante entonces trabajar a dos niveles. Inicialmente crear el documento estrictamente funcional, desarrollado por un analista o experto en el negocio  incluyendo en el mismo casos de uso, requerimientos y reglas del negocio. A partir de ahí­, y tras análisis del documento funcional, un perfil algo más técnico, con conocimientos de usabilidad y de arquitectura de software, deberí­a evaluar la documentación y proponer (además de una arquitectura de software adecuada para el tipo de funcionalidad requerida), cómo orientar la funcionalidad a la pantalla que va a ver el usuario, creando los prototipos pertinentes, bajo la perspectiva de la tecnologí­a seleccionada para la solución.
Saludos.
Miguel.

4 thoughts on “Malas Prácticas: Documentos Funcionales Ligados a la Tecnologí­a”

  1. Pero todas esas funcionalidades van por modas, en mi opinion enmarañan mucho el diseño de las páginas, ya que molestan bastante cuando se van abriendo al pasar el ratón.
    Hacen mas dificil la navegación por la página y ademas hace que se cargue mas lentamente.

  2. Hola Miguel:
    muy interesante tu artí­culo, estoy totalmente deacuerdo contigo.
    no se porque existe ese afán de los analistas de negocio poner requerimientos visuales o de usabilidad, siendo que existen profesionales con acabados conocimientos que pueden tomar estos requerimientos con el conocimiento tecnico que le permite determinar si es posible realizarlo o no.

  3. El problema que nos encontramos muchas veces es la selección de la tecnologí­a sin tener en cuenta factores de usabilidad, rendimiento, etc.
    Utilizando nuevamente el sí­mil de la construcción de edificios, a nadie se le ocurrirí­a construir un edificio sin tener claro qué es lo que dicho edificio tiene que soportar… porque si nos equivocamos, el edificio se caerá.
    Los requerimientos de sistema son básicos para decidir una arquitectura o una tecnologí­a y son los que pueden llevar a un proyecto al éxito o al fracacaso.
    Un saludo.

  4. En la toma de requerimientos y el análisis funcional es imprescindible traspasar la necesidad de negocio a los desarrolladores para que implementen una herramienta que haga lo que se necesita.
    Si el analista funcional se mete también en el diseño debe tener conocimientos de la arquitectura del software y del sistema para no solicitar una implementación inefeciente.
    En mi experiencia, la interfaz del usuario es clave para que una herramienta demuestre que puede optimizar procesos desde el punto de vista de la productividad o rendimiento de cada usuario, especialmente cuando hablamos de alta producción en la que una diferencia de segundos es muy significativa al final del proceso.
    Por eso, creo que es mala práctica pretender que un pantallazo sea el equivalente a un requisito (a veces se dan así!), pero no que el analista funcional llegue hasta el diseño funcional. Por supuesto, los requerimientos, en mi opinión, deberían mantenerse alejados de la parte funcional y de diseño si se están dando por una persona diferente de la que hace el análisis.
    ¿Qué pensáis?

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.