11.18.09
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.
Goyo said,
November 21, 2009 at 1:10 pm
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.
carolina said,
February 3, 2011 at 9:42 pm
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.
Miguel said,
February 23, 2011 at 10:49 pm
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.