archivo

Archivo de la etiqueta: analista funcional

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

El prototipado es una técnica aplicable a prácticamente cualquier metodología de desarrollo ya que no es más que concretar en un entregable, que puede ir desde una serie de imágenes (para mostrar como sería el diseño de un formulario) hasta un producto software, las ideas que el usuario va lanzando sobre lo que quiere que la aplicación haga.

En ciertos tipos de ciclos de vida como el clásico o en cascada este tipo de técnica tiene mucho interés porque independientemente de que estas metodologías sean predictivas y no adaptativas, sí que resulta conveniente que por lo menos, de inicio, la diferencia entre lo que el usuario espera y lo que el analista interpreta sea la menor posible.

En metodologías evolutivas como lo son, por ejemplo, RUP o el conjunto de metodologías ágiles, cuando las iteraciones son cortas, la importancia del prototipado disminuye, si bien sigue resultando un instrumento muy útil cuando se trata de abstraer a un programa de ordenador un aspecto de negocio complejo o para intentar obtener la información más precisa posible del usuario, cuando este no tiene muy claro lo que quiere o no lo sabe explicar de manera adecuada.

Sobre el prototipado Larry Bernstein realiza la siguiente reflexión: “El prototipado reduce el tiempo de desarrollo y el coste en un 40%”.

Hace unas semanas comenté una posible solución para la representación de la gestión CRUD a través de casos de uso (es muy recomendable la lectura de los dos artículos que le dedico a esa solución porque la que planteo en este no es más que una adaptación o continuación de la misma y tal vez algún aspecto que exponga no se entienda de manera adecuada si no se toman como referencia ambos artículos).

En esta ocasión voy a realizar una propuesta para representar las relaciones maestro/detalle. De igual forma que en el caso anterior, no pretende dar una solución académica u ortodoxa, sino una solución que pretende ser práctica, sencilla y repetible que pueda ser adaptada a las características de la aplicación que se quiere representar o incluso al nivel de detalle al que queramos llegar en la definición de los casos de uso.

Como en el caso de la gestión CRUD, todo gira alrededor de los casos de uso de negocio y a través de ellos se orquestan las operaciones que se pueden hacer sobre el caso de uso.

En este caso creamos un caso de uso genérico al que podemos denominar Gestionar Maestro.

Sobre el maestro se realizarán normalmente las operación de consulta, inserción de nuevos registros, borrar registros (siempre y cuando no tengan registros asociados, salvo que se admita el borrado en cascada, cualquiera de las dos alternativas se tendrá que tener en cuenta en la definición del caso de uso que extiende al caso de uso principal y que representa a la operación de borrado) y actualizarlo.

Si se prefiere no sería necesario definir los casos de uso que representan a las operaciones de inserción y consulta, salvo que presenten alguna modificación respecto a las definidas en el caso de uso genérico del CRUD (Gestionar Entidad). Si se opta por esta opción, se tendría que poner el caso de uso Gestionar Maestro heredando de Gestionar Entidad.

Pues bien, sobre el caso de uso de actualización es donde extenderán los distintos casos de uso que se encargan de la gestión de los detalles. En la definición de este caso de uso genérico, valdrá con una relación de extend a otro caso de uso genérico que será Gestionar Detalle y que será el que se “sobreescribirá”, mediante una relación extend con el Maestro en cada representación particular de Maestro/Detalle.

Como estos casos de uso de detalle son mayoritariamente a su vez gestión CRUD o gestión maestro/detalle, también es posible simplificar su representación. Los que sean de gestión CRUD no será necesario definirlos, simplemente especificarlos y en todo caso lo único que habrá que hacer será reflejar las operaciones que se añaden o las que varían su comportamiento respecto a la definición inicial que se haga del CRUD (todo ello vendrá dado por la relación de herencia que habrá entre esta caso de uso y el caso de uso genérico “Gestionar Entidad”) y los que sean gestión de Maestro/Detalle podrán heredar a su vez del caso de uso “Gestionar Maestro”.

Maya Elhalal-Levavi es una emprendedora israelí especializada en Internet y redes sociales. Siendo una importante conocedora del negocio y de la experiencia de usuario resulta muy interesante su siguiente cita:

“La interfaz gráfica de usuario (GUI) siempre es intuitiva para quienes la desarrollan”.

Una gran verdad y un gran error por parte de muchos analistas ya que es necesario tener muy en cuenta a quiénes van a ser los verdaderos destinatarios de las mismas.

Capers Jones es un ingeniero de software americano especialista en estimación de costes, metodologías de desarrollo y calidad del software. También es autor de artículos y libros sobre esas materias.

En la segunda edición de su libro “From Applied Software Measurement” realiza la siguiente reflexión (traducción libre):

“El software es una industria que hace un uso intensivo del papel. El volumen total de documentos utilizados en proyectos software es superior al utilizado en la mayoría de los productos fabricados por el hombre… En proyectos software de gran tamaño del ámbito militar, el volumen total de documentos en papel puede superar el millón de páginas.

Lo que resulta sorprendente es que en sistemas muy grandes el volumen de documentación de las especificaciones y documentos técnicos puede ser lo suficientemente extenso como para ser leído en la vida de un solo analista. Suponiendo una velocidad de lectura técnica de alrededor de 200 palabras por minuto, hay algunos sistemas en los que un empleado puede llevarse una vida laboral de 40 años sin hacer nada salvo leer la documentación y encima no terminar de realizar esa tarea”

Lo más significativo de esa reflexión es que es absolutamente cierta. ¿Qué porcentaje de la documentación generada en un proyecto de desarrollo de software resulta de utilidad?. Esto no es una cruzada contra la documentación es más, estoy a favor de ella, siempre y cuando sirva para algo.

¿Qué tareas realiza un analista funcional?, ¿cuáles un analista orgánico?. Depende de la entidad en la que trabajen y del proyecto en sí, la limitación de las funciones de cada uno.

Por regla general, se considera analista funcional a quien se encarga de la recopilación del catálogo de requisitos y de la definición de los casos de uso (o historias de usuario). Su objetivo es describir las funcionalidades del sistema y su comportamiento mediante el estudio de las necesidades del usuario. Su trabajo es muy importante y sin embargo no se le da el valor que se merece, ya he comentado en más de una ocasión que lo técnico suele resultar más glamuroso.

Los sistemas se desarrollan para el usuario y para que sean de utilidad hay que saber captar qué es lo que quiere el usuario y cómo desea interactuar con el sistema.

La técnica es muy importante, pero no lo es menos que la vertiente funcional, todos suman y todos restan si no hacen adecuadamente su trabajo.

El analista orgánico se encarga del diseño que no es otra cosa que la particularización de las necesidades del usuario a una implementación concreta. Para un proyecto concreto vendría a ser el arquitecto de la solución, ya que entraría incluso a definir el framework con el que se va a trabajar.

Lo habitual en los proyectos de desarrollo de software es encontrarnos con analistas que realizan las dos funciones, aunando en un solo perfil lo funcional y lo técnico. Tiene como principal ventaja que no es necesario transferir el conocimiento entre diferentes fases o procesos del desarrollo y que cada tarea es realizada por un experto en la misma. El principal inconveniente es que no existe una especialización, no obstante, hay que ser bastante bueno en uno de los dos perfiles para marcar de manera clara la diferencia respecto a analistas que realicen ambos trabajos (ahora, quien las marca es que es muy bueno y por tanto, vale mucho dinero).

En desarrollos iterativos e incrementales con una orientación ágil lo deseable es que la evolución del desarrollo sea rápida (realizándose los incrementos con cierta frecuencia) y resulta fundamental la participación del usuario, a ser posible como una pieza más del equipo de proyecto, lo normal es que no exista distinción entre analista funcional y orgánico, si bien, tendrá una vertiente más técnica, por las características particulares de este tipo de desarrollos. Existirán excepciones, en proyectos que por su naturaleza requiera de desarrolladores que den apoyo funcional, por la experiencia que tengan en un tipo de negocio concreto.

Si no se tiene un perfil técnico se está estigmatizado, como si se tuviera menos confianza en la capacidad de esa persona en un proyecto de desarrollo de software o en una empresa del sector.

Viste mucho o tiene más glamour ser arquitecto, analista orgánico o realizar tareas de programación. Son funciones importantes, eso es innegable, pero también lo son las tareas funcionales (sobre todo teniendo en cuenta que son los primeros que toman contacto con el proyecto y que su trabajo, bueno o malo, condiciona el resto del desarrollo).

Programadores los hay excelentes y muy malos, los analistas funcionales no son una excepción.

Un buen analista funcional no tiene precio. Si es capaz de realizar una definición adecuada del proyecto crecen las posibilidades de que salga bien, un mal análisis es difícil de remontarse por muy buenos técnicos que participen en el proyecto.

Es necesario respetar todos los perfiles que participan en un proyecto, tras los perfiles hay personas y lo podrán hacer bien o mal. Es decir, se puede hacer una selección no adecuada de perfiles en un proyecto o acertar y quienes desempeñen un determinado rol no funcionar, pero en ningún caso es culpa del perfil en sí.

Por tanto, si un perfil de analista funcional no encaja en un proyecto será porque el proyecto requiere otro tipo de perfiles o requiere que quien desempeñe el papel de analista funcional, sea polivalente y pueda ser también analista orgánico o realizar tareas de construcción, pero como en el fútbol, es muy complicado ser a la vez buen delantero, buen centrocampista y buen defensa.

Durante mucho tiempo he recibido análisis de requisitos donde se describían las funcionalidades a demasiado alto nivel. Esto tiene un gran problema y es que al final casi todo es interpretable y en muchos casos ambiguo. Este problema se trasladaba después a los casos de uso.

Al final tenemos un análisis que no cumple sus objetivos, ya que los analistas programadores y programadores no disponen de la información necesaria para hacer su trabajo, por lo que necesitarán la continua asistencia del analista, el cual además, al no ser un experto funcional en la mayoría de los casos, sino alguien que ha aprendido el negocio en el proyecto, tendrá lagunas que, si no quiere arriesgar demasiado, tendrá que consultar con el grupo de usuarios expertos.

El problema no es que se tenga que preguntar en medio del diseño o de la construcción (que lo es), sino el coste que eso conlleva, ya que requiere una mayor atención al proyecto por parte del analista, cuando la mayor parte de su trabajo debería haber sido llevado a cabo antes de manera adecuada.

Pero el problema principal es que al final la interpretación de los requisitos y de cómo interactúa el usuario con la aplicación deja vendido a las dos partes, cliente y proveedor y empiezan las luchas de poder, en las que generalmente el proveedor tiene las de perder. El hecho de que el cliente tenga ventaja en las disputas no quiere decir que este tipo de situaciones sean convenientes, ya que al final, en las negociaciones siempre se perderán funcionalidades interesantes o estas se conseguirán después de mucho desgaste entre las partes.

Por estos motivos, me he planteado como objetivo ser mucho más riguroso en estas etapas iniciales del proyecto, estoy seguro que al final merecerá la pena.

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

No hace mucho tuve una charla con un amigo que es totalmente partidario de los procesos de industrialización del software y que entiende el proceso de desarrollo, una vez elaborado el análisis, como si fuera una cadena de montaje.

Me comentaba que conseguir eso implicaba trabajar, hablando en términos muy generales, de la siguiente manera:

– Los analistas discutirían el diseño del sistema con los arquitectos (en el caso de que hubiera alguna contingencia que hiciera necesario esto).

– Los analistas entregarían el diseño a uno de los responsables de recepción de trabajo de la factoría que se encargaría de distribuir el trabajo en el equipo.

– Dentro del equipo de la factoría habría un perfil asignado al proyecto que se encargaría de ensamblar los componentes y de verificar si el sistema cumple las especificaciones del diseño y del análisis.

– Una vez construido el proyecto (o en diversas iteraciones) el mismo pasaría a ser revisado por un departamento de calidad que haría las verificaciones finales del producto previas a la entrega.

La visión de mi amigo no es ni mucho menos mala, es simplemente otra opción en el proceso de desarrollo de software, es otra manera de hacer las cosas y que puede ser muy rentable si se dan las condiciones necesarias (o se reunen muchas de ellas para trabajar de esa manera).

Algunas de esas condiciones pueden ser las siguientes:

– El proceso de desarrollo de software desde su concepción hasta su entrega está regido por procesos, de manera que en cada fase cada cual conozca su rol y las tareas que debe realizar. Existirían personas encargadas de velar por el cumplimiento y mejora continua de los procesos.

– Los requisitos se encuentran cerrados en el momento en que se entrega el diseño a la factoría. Todos sabemos que eso es bastante complicado de conseguir ya que muchos usuarios terminan por afinar el concepto que tienen de aplicación conforme van viendo plasmada su construcción y a veces estos detalles son los que marcan las diferencias entre una buena terminación y otra no tan adecuada. Esto se complica sobre todo si el proyecto es de gran magnitud.

Pese a que es complicado y yo personalmente soy partidario de ser lo suficientemente flexible con el usuario y dar la posibilidad de introducir cambios menores en los requisitos más allá del análisis (con el coste y riesgos que ello conlleva), si el analista funcional hace un buen trabajo y/o se prevén fases de mantenimiento evolutivo posteriores y/o se opta por un desarrollo incremental del sistema sí que sería posible un escenario donde los requisitos estuvieran debidamente cerrados (no necesariamente al 100% pero sí muy aproximado a ese límite) en la fase de construcción.

Un inconveniente que se puede plantear con esta dinámica de trabajo es la separación entre el equipo funcional y el equipo que realiza la construcción del sistema de información. Esa frontera puede ser causa de problemas salvo que se establezcan mecanismos adecuados de interlocución entre el equipo de personas que construyen y los analistas funcionales, supuestamente si todo estuviera bien especificado en el diseño y en el análisis la comunicación no debería ser necesaria, pero eso es un modelo teórico a mi juicio ya que requeriría que no quedasen resquicios en el diseño y en el análisis, algo que resulta muy complicado y que se complica todavía más conforme se incrementa la complejidad y tamaño del sistema.

Si los mecanismos de interlocución funcionan y todos reman en la misma dirección, estos problemas pueden minimizarse, pero si no es así el equipo de construcción tenderá a rellenar los huecos del análisis y el diseño, algo que es muy arriesgado ya que ellos no han participado en la etapa de definición funcional de la aplicación y no han trabajado con quienes van a utilizar finalmente la aplicación.

Podría pensarse que la colaboración entre los equipos de trabajo debería ser algo fluido, pero no necesariamente va a ser así, sobre todo si los responsables funcionales y los del proceso de construcción son distintos y pertenecen a departamentos diferentes, lo que implicaría que el jefe común entre ambos equipos estaría situado bastante por encima en la jerarquía de la organización, lo que dificultaría las tareas de coordinación en caso de conflicto (cuanto más arriba esté quien realiza estas tareas, pierde la visión del día a día, este tipo de problemáticas no les resulta de interés, en función de otras que suelen tener (principalmente de carácter económico de los proyectos o departamentos a su carga) y además asusta más requerir su participación porque se piensa que su intervención puede ser semajante a la de un elefante cuando entra en una cacharrería).

– La construcción tiene que ser lo más homogénea posible. Es decir, en la medida de lo posible los desarrollos deben estar construidos siguiendo el mismo framework y automatizándose en lo posible el proceso de construcción mediante la utilización de generadores de código e incluso con la posibilidad de utilizar frameworks gráficos. Esto será posible cuando los clientes planteen libertad en cuanto a framework o arquitectura o exista un alto grado de compatibilidad entre la solución que requiere el cliente y aquella con la que se trabaja, en otros casos tales como aplicaciones desarrolladas siguiendo otra estrategia (y en las que se va a realizar mantenimiento evolutivo) o nuevos desarrollos que sigan otro framework habrá que aplicar otro tipo de estrategias para hacerse cargo de ellos.

Cuando el desarrollo sigue una línea diferente a la utilizada en la factoría lo ideal sería especializar un grupo de trabajo en el desarrollo con esa arquitectura, framework o tecnología, pero eso requeriría una vinculación a medio o largo plazo con el cliente y/o tener expectativas más o menos ciertas de negocio. ¿Por qué especializar? Pues porque la productividad va a ser mayor, no ya solo por el dominio que este equipo puede tener de la tecnología, sino porque se pueden adoptar soluciones (aunque sea paulatinamente) para mejorar el rendimiento en el desarrollo. Si el proyecto no es lo suficientemente grande, duradero o las expectativas de trabajar en otros proyectos similares no están claras, lo mismo hay que plantearse que la solución más adecuada no pasa porque el contrato (en el que caso de que se quiera o pueda asumir) lo realice la factoría, lo mismo resulta mucho más adecuado formar un equipo de proyecto tradicional para llevarlo a cabo.

En la charla, mi amigo tenía muy claro que había que invertir en el framework, en la generación de código y en la reutilización de módulos y componentes y que es absolutamente necesario tener a personas dedicadas exclusivamente a mejorarlo, a corregir incidencias y a asesorar y que había que perder el miedo a tener estas personas haciendo estas funciones, ya que aunque sean perfiles altos (deben serlo para que el resultado de sus trabajos sea el más óptimo posible debido al impacto que tendrá en el conjunto de proyectos) el retorno de la inversión está asegurado.

Hace bastante tiempo escribí un conjunto de articulos dedicados a la producción industrializada de software, si queréis echarle un vistazo os dejo a continuación sus enlaces:

Producción industrializada de software I
Producción industrializada de software II
Producción industrializada de software III
Producción industrializada de software IV
Producción industrializada de software V
Producción industrializada de software VI