archivo

Archivo de la etiqueta: analista funcional

Conozco a excelentes programadores y arquitectos de software, a magníficos profesionales a los que confiaría proyectos críticos porque sé que estarían a la altura de las circunstancias, sin embargo ninguno de ellos es infalible y si no han probado de manera adecuada un producto software habrá incidencias importantes que lleguen a producción y si no se ha revisado convenientemente el análisis con los usuarios probablemente se esté lejos de cumplir las expectativas de los mismos.

Es decir, se puede tener un excelente potencial y unas cualidades magníficas que hagan que el software que se desarrolla tenga una deuda técnica aceptable y que sea, por tanto, factible de mantener y evolucionar, pero si no se es estricto con la necesidad de revisar lo que se está haciendo buena parte de ese trabajo se puede ir al traste.

No es cuestión de detectar todos los errores y desviaciones respecto a lo que el usuario espera, al menos no lo es en la mayoría de los sistemas de información que se desarrollan (sí que lo es en sistemas donde esté en juego la vida de personas o la cuenta de resultados de una organización), sino de minimizar o evitar, si es posible, el número de incidencias con un impacto grave en el entorno de producción.

Por tanto, sin testing, sin método para llevarlo a cabo, sin una sistematización de este tipo de trabajo desde el inicio del proyecto no hay confianza en que el producto llegue en condiciones a producción.

Uno de los problemas de los desarrollos siguiendo el ciclo de vida clásico o en cascada es que se tiende a entregar versiones completas de un sistema de información invirtiendo prácticamente todo el presupuesto del proyecto en conseguirla.

¿Problema? Tenemos una aplicación con muchas funcionalidades (cuando no muchos subsistemas) y sobre la cual el usuario empezará a reportar mejoras y correcciones, con el objeto de adaptar el sistema a sus expectativas. Esto no sería problema si estuviera contemplado en el presupuesto, pero lo más normal es que no lo esté y estaremos en una situación de poner en marcha un sistema casi sin recursos, lo que imposibilitará materializar el feedback del usuario.

Esta situación la tendremos incluso con un análisis óptimo del sistema y esto es así porque la naturaleza del software no es predictiva sino adaptativa o evolutiva. Un buen analista conseguirá reducir el margen de error entre la predicción y lo que el usuario realmente quiere (teniendo en cuenta además las contingencias propias de cualquier desarrollo, como que por ejemplo a mitad de la partida cambien las reglas del juego).

Por ese motivo lo mejor es aplicar un enfoque ágil, con una visión iterativa e incremental del sistema, de esa forma un buen trabajo de análisis es más efectivo, se reduce el tiempo en el que pueden ocurrir circunstancias que afecten al desarrollo y permite enfocar los esfuerzos en aspectos concretos del sistema. Es más, soy partidario de que incluso si se prevé que la primera versión del producto se extienda demasiado, se entreguen esqueletos andantes, sobre todo si existe voluntad de los usuarios en participar activamente en el proceso de desarrollo.

De esta forma, con la puesta en marcha paulatina de funcionalidades se puede controlar la existencia de muchos frentes abiertos, ya que la prioridad debe ser que cada módulo liberado del sistema esté acorde a las expectativas del usuario.

Cuando existen muchos frentes abiertos la sensación (y la realidad) es que las circunstancias controlan el proyecto en lugar de ser tú quien lo maneja. Apagar fuegos soluciona problemas a muy corto plazo, pero difícilmente ofrece una solución a futuro.

Clifford Michael Bleszinski (CliffyB) es un diseñador y desarrollador de videojuegos que trabaja en la actualidad en la empresa Epic Games. Es conocido entre otras cosas por su trabajo en el juego Gears of War.

El desarrollo de videojuegos, sobre todo de la envergadura de los que participa es el resultado de un trabajo en equipo y gran parte del coste de desarrollo de los mismos y de su posterior éxito depende muy mucho de cómo han trabajado individualmente y en colectivo las distintas personas que intervienen con mayor o menor dedicación y con mayor o menos implicación en el mismo.

Sobre el trabajo en equipo, Cliff Bleszinski realiza la siguiente reflexión (traducción libre): “Nadie es el más importante de la banda. Hacer un juego implica todo un equipo de personas con talento y dedicadas. Un sola persona no hace ningún producto, de la misma forma que un equipo que gana la Super Bowl no es el quaterback, un juego no es cuestión de un programador o de un diseñador. Un buen equipo trabaja bien junto, a veces falla y funciona como una máquina bien engrasada”.

El ego de los que nos dedicamos al desarrollo de software, que suele ser bastante importante por regla general, hace mucho daño al resultado final de nuestro trabajo. Tendemos a pensar que nuestra solución, nuestra perspectiva y nuestra aportación es esencial.

Puede ser incluso hasta cierto, pero un gestor de proyectos no es nadie sin su equipo, un programador puede hacer su trabajo extraordinariamente pero si el análisis realizado no es bueno, el producto no es bueno, un analista puede interpretar las expectativas del usuario de manera excepcional, pero si la arquitectura y/o la codificación no es buena, el resultado final se resentirá, un programador y un analista pueden ser excelentes profesionales, pero si el jefe de proyectos o el responsable de la venta de los servicios no ha hecho una buena negociación afectará, sin duda, a la calidad final que se obtenga.

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.