archivo

Archivo de la etiqueta: análisis de requisitos

¿Cuántas veces nos hemos encontrado con que una vez desarrollado un sistema de información no hay dinero para mantenimiento?. Demasiadas veces.

Alguno podrá pensar, ¿para qué está la garantía? Como es lógico, para corregir errores, pero cuando los mismos sean imputables al trabajo exclusivamente del proveedor.

Si embargo muchas de las correcciones que requiere el programa son consecuencia de una incorrecta definición del sistema por la parte usuaria y esto no debería entrar en garantía, ya que se trataría de un cambio de los requerimientos y por tanto un mantenimiento evolutivo. A esto hay que añadir lo que sería mantenimiento evolutivo puro y duro, por las necesidades de añadir nuevas funcionalidades al sistema.

No quiero decir que el proveedor no tenga nada de culpa en la incorrecta especificación del sistema, la tiene y mucha, ya que la experiencia de los analistas, su experiencia en el negocio, sus habilidades y la utilización de estrategias y modelos para captar requisitos y modelar el análisis pueden reducir (que nunca eliminar completamente, salvo que el sistema sea muy simple y aún así) este tipo de problemas. Sin embargo y en cualquier caso, es una responsabilidad compartida, pudiéndose negociar con el proveedor en cualquier caso qué asume cada uno, lo cual también dependerá de las concesiones que haya o no realizado el mismo en el transcurso del proyecto. De la misma forma que el objetivo de un proveedor es conseguir la satisfacción del cliente y que dentro de unos márgenes sería conveniente asumir parte de la culpa, un cliente tampoco debe abusar de su condición de poder y hacer cargar al proveedor con más responsabilidad de lo que es justo.

Robert Glass indica que el coste del mantenimiento se sitúa entre el 40% y el 80% del coste total del software, del cual el 60% son mejoras. Esto dependerá mucho de las condiciones en que el producto haya llegado a producción y de la existencia o no de cambios drásticos en los procesos que se informatizan, en cualquier caso como valor de referencia puede servir.

Por tanto, el mantenimiento es inevitable y si no se tiene presupuestado o previsto se corre el riesgo de que el sistema en producción fracase y/o provoque problemas en la ejecución ordinaria del proceso o procesos relacionados con el mismo.

Aunque pueda parecer mentira, lo más difícil en un proyecto de desarrollo de software es descubrir qué es lo que realmente quiere el usuario y qué es lo que espera del mismo.

En el mundo académico generalmente siempre se parte de que se conocen los requisitos, cuando en realidad es lo más difícil de obtener. Se especifican técnicas que ayuden a determinar cuáles son, pero generalmente los esfuerzos se dirigen más a lo que es la propia ingeniería del software y a la programación que si bien son importantes (tremendamente importantes, ya que desde otra perspectiva, de nada vale tener una buena materia prima de entrada, si después la ejecución no es buena y/o se obtiene un producto inmantenible), requieren que su entrada sea buena, ya que un desarrollo de software será tan bueno como claro se tenga lo que quiere el usuario, es decir, se podrá tener una ejecución impecable pero si el producto no hace lo que el usuario quiere o si hace lo que quiere el usuario pero no de la forma que quiere, todo el esfuerzo de ingeniería del software y desarrollo servirá exclusivamente para que retocar el software no sea tan costoso (que no es poco, pero que a estas alturas siempre será más caro que si desde el principio se hubiera determinado qué es lo que se quiere).

Los desarrolladores tienden a dar menos importancia a la fase de análisis y dar cada vez mayor trascendencia a la construcción. Estas prisas ni van a hacer que el producto sea mejor, ni van a provocar que el producto lo tengamos antes (es posible que lo entregues incluso antes de plazo, pero después prepárate a llevarte haciendo correctivos, mucho tiempo). El análisis es fundamental hacerlo de la mejor manera posible y eso requiere ciertas habilidades, ya que captar lo que el usuario requiere no es nada fácil, cierto es que el proyecto tiene que seguir hacia adelante y no podemos estar eternamente en el análisis, por ese motivo la clave es dedicarle la atención que se merece, no considerar que es un mal necesario (o innecesario) por el que hay que pasar y que a partir de él se genera el resto del proyecto: diseño, construcción e implantación del sistema de información.

El análisis no es una barra libre, es decir, el usuario pedirá cosas que no son posibles. Es importante que cuando un usuario pida funcionalidades que no se les van a poder ofrecer o que su complejidad es considerable, se les exponga con claridad y se trate o bien de descartarla (y ver si realmente ese descarte impactará en su impresión final del sistema) o de buscar una solución más simple. Por regla general, si a los usuarios se les explican las cosas terminan siendo bastante sensatos y si no lo son y muestran malestar o son insensatos tampoco pasa nada, ya que si algo no se puede hacer, no se va a poder hacer y mejor que se enfade ahora, que llevarse la impresión o expectativa que va a tener una funcionalidad que sabemos a ciencia cierta que no va a ser posible.

El análisis no consiste solo en los requisitos, es mucho más: obtener el modelo de datos, obtener la interfaz de usuario, definir casos de uso (al menos los más importantes), etc… y es muy importante cerrarlo con el usuario.

Cerrar el análisis no es cerrar la puerta completamente, ya que cuando el usuario empiece a ver el producto en diversas fases de su desarrollo descubrirá cosas nuevas y eso es normal porque por mucha capacidad de abstracción que se tenga y por muy buen trabajo que hayan realizado los analistas, es imposible hacer el trabajo perfecto. Ser flexible no implica tener barra libre, ya que estar continuamente retocando diseños y desarrollos es tremendamente costoso. Si el usuario quiere empezar a cambiar muchas cosas, habría que plantearse parar y volver a repasar con el usuario lo que quiere, eso tiene su coste y el usuario deberá saberlo desde el principio del proyecto, es como si cuando tienes tu casa a medio construir quieres empezar a hacer cambios, eso es siempre más costoso que si se hace sobre plano, ya que ahí lo único que se necesita es una goma de borrar.

La conciencia de que es muy difícil acertar con lo que se quiere el usuario es lo que ha provocado la aparición de muchas metodologías ágiles, basadas en obtener resultados mediante aproximaciones sucesivas o iteraciones. Me parecen soluciones bastante aceptables, incluso óptimas en entornos donde resulta complicado obtener del usuario lo que quiere. No hay que tener medio a variar de una metodología más clásica a otra más ágil si se aprecia que es la mejor solución para un proyecto concreto.

También me resulta aceptable aplicar diferentes estrategias para acertar lo máximo posible en el análisis: realizar prototipos, simulaciones, etc… y no tener nunca miedo en preguntar al usuario ninguna duda, aunque ya te lo haya explicado diez veces.

Hace poco tuve la ocasión de asistir a una reunión de toma de requisitos en la que participaban cuatro usuarios que habían sido seleccionados por el área usuaria y que cubrían una parte importante de las funcionalidades del sistema de información que se estaba analizando.

Pese a que no pude quedarme mucho tiempo en esa reunión, salí con una gran satisfacción de la misma, ya que veía a usuarios que tenían muy claro qué era lo que querían y lo que no, que tenían una gran experiencia en la materia, conocían la problemática que la rodeaba y tenían los pies en el suelo, ya que sabían que un sistema de información les ayuda en la realización de sus funciones, pero sólo si este hacía lo que necesitaban.

Aunque pueda parecer algo extraño, encontrarnos con usuarios que desde etapas tan tempranas saben lo que necesitan no es nada fácil. Con otros tipos de usuarios, siendo incluso excelentes usuarios también, no resulta en ocasiones tan sencillo obtener el catálogo de objetivos, requisitos y casos de uso, debiéndose aplicar diferentes técnicas y dedicándose bastante tiempo para intentar que dichos catálogos sean lo más completos y exactos posibles y así evitar problemas en fases posteriores del desarrollo.

Bien es cierto que este sistema consiste en una redifición funcional y tecnológica de otro que se venía utilizando durante muchos años y que los usuarios que asistieron a la reunión de análisis tenían una gran experiencia en su uso, lo que facilitaba bastante las cosas, ya que eran conscientes de lo que había ido mal y bien en el anterior sistema y así lo expresaron, además como eran usuarios de otros sistemas de información más avanzados tecnológicamente del que se va a sustituir, también querían añadir funcionalidades que entendían que les iban a resultar de gran utilidad, como por ejemplo, la posibilidad de firma electrónica de los documentos que se generen a través de la aplicación, interoperabilidad con otros sistemas para suministrarles y recibir información y servicios de ellos, etc…

No obstante, independientemente o no de que las circunstancias fueran favorables a que supieran expresar todo lo que querían, siempre es de agradecer encontrarnos con usuarios así. Todavía queda trabajar mucho con ellos para terminar de perfilarlo todo muy bien, pero en cualquier caso todo pinta de manera bastante favorable y la labor del equipo de proyecto es intentar extraer de ellos esa información y ese conocimiento que tienen y hacerles sentir lo que son, una parte fundamental del proyecto.

Puede que al final el proyecto, lo mismo, tome otros derroteros y no consigamos buenos resultados, pero desde luego que estos inicios no pueden ser más esperanzadores.

Otro error muy común en el proceso de desarrollo de software (y en el que yo también he caído) es olvidar que el producto que se está implementando no es para nosotros sino para el usuario final e independientemente de que tengamos la sensación de que conozcamos perfectamente lo que quiere el usuario o que dominamos la materia, tenemos que buscar hasta donde sea posible la implicación del usuario, no solo durante el proceso de definición del sistema, sino durante el proceso de construcción.

Si los que nos dedicamos al desarrollo de software, que ya tenemos una cierta experiencia en abstraer problemas, nos encontramos con dificultades en numerosas ocasiones para llevar a un programa de ordenador un determinado proceso y nos damos cuenta muchas veces cuando se está construyendo que hay piezas que no encajan, ¿podemos pedir al usuario que tenga esa misma capacidad de abstracción?, algunos pensaréis: “era obligación del usuario leerse el análisis”, ¿de verdad pensáis que el usuario puede llegar mucho más allá del análisis de requisitos, de la descripción de casos de uso, de la revisión de las interfaces de usuario y su navegación?, salvo que el sistema no sea excesivamente grande, que los entregables que acabo de indicar se realicen de la forma más completa, exacta y clara posible, y que el usuario se esmere en repasarlos (y aún así), quedarán resquicios que cuanto más se tarden en corregir más costosos serán para el desarrollador.

Lo que acabo de comentar en el párrafo anterior no es un vale todo para el usuario, es decir, éste debe asumir su responsabilidad en el proyecto y de alguna u otra forma se lo tenemos que hacer ver. El desarrollo de software no se hace con una pizarra y una tiza, donde se puede borrar y volver a escribir libremente, es un proceso tan complejo en el que no vale la barra libre. Lo que vengo a comentar es que en el desarrollo de software se debe ser consciente de que cuanto más se tarde en detectar un error más vale corregirlo y que los usuarios en la mayoría de los casos no toman conciencia del programa y de los problemas hasta que se enfrentan a él. Como podéis ver se trata prácticamente de dos extremos, de hecho cuanto peor se hagan las cosas (por parte del desarrollador y del usuario (por no hacer frente, este último, a su responsabilidad)) se cumplirán ambos extremos, lo que provocará que el proyecto salga caro (lo cual puede repercutir sobre el usuario o sobre el desarrollador (más bien, sobre este último)) y que la calidad del mismo se vea muy perjudicada.

Por tanto, es importante que no olvidemos que las aplicaciones se desarrollan para los usuarios y que por tanto hay que buscar la mayor implicación posible por parte de los mismos en todo el proceso de desarrollo de software. ¿Qué el usuario no se implica? Hay que intentar que siempre quede patente este hecho (evidentemente hay que saber hacerlo con tacto), ya que más adelante si el proyecto no ha salido como debía y hay que empezar a parchear, que todo el gasto de ese parcheo no repercuta directamente sobre el desarrollador.

No es lo mismo 1+1 que 1+2, no es lo mismo tablón que cab…

Pues eso, la toma de requisitos requiere precisión y por tanto que te enteres con exactitud qué quiere el usuario. ¿Qué tienes que preguntarle 1000 veces? Le preguntas 1000 veces.

El usuario quiere un producto final que le valga para algo, que le sirva para tener informatizado su proceso y si es posible además que le agilice el trabajo. Pues bien, para que le sirva para algo y para que le agilice el trabajo se requiere un análisis de requisitos que recoja con precisión lo que quiere y necesita.

La base de cualquier proyecto informático es saber qué es lo que quiere el cliente. Esto que parece es muy sencillo es tremendamente complicado, en ocasiones por la dificultad de entender el proceso que quiere informatizar y otras porque no siempre es sencillo sacar del cliente todo lo que quiere.

Un buen analista de requisitos es una pieza fundamental en cualquier proyecto, sin embargo no suele ser un puesto especializado, sino que un analista o varios llevan el proyecto del principio hasta el final. De hecho en ninguna de las empresas con las que he trabajado y en ninguno de los proyectos en los que he trabajado me he encontrado con un técnico especializado en análisis de requisitos.

Yo particularmente apostaría por intentar encontrar un especialista en este área, ya que alguien que consiga plasmar en un papel con claridad que es lo que quiere el cliente traducido a un lenguaje que entienda éste y el equipo va a trabajar con el proyecto va a ahorrar muchos problemas al mismo.

Es una garantía para el cliente y para el proveedor que el análisis de requisitos esté por escrito y se obtenga la aprobación de ambos y a ser posible que quede también reflejada dicha aprobación de alguna forma.

En un mundo ideal con un cliente ideal y un analista de requisitos ideal el análisis de requisitos saldrá perfecto, en el mundo real no es así, sobre todo si el sistema de información que hay que implementar es muy complejo desde el punto de vista funcional. Un analista de requisitos excelente hará que casi todos sus análisis no requieran ningún tipo de ajuste y que cuando lo requieran sean menores.

Si hay que hacer ajustes en un análisis de requisitos se hacen, ya que lo importante es que el cliente termine satisfecho del producto, pero es fundamental que esos ajustes se produzcan en las etapas más tempranas del proyecto y es básico que el cliente sepa las consecuencias de futuras o posibles modificaciones en el análisis de requisitos en fases posteriores del proyecto, es decir, que el producto sufrirá retrasos, que rehacer cosas implica un coste que tendrá que asumir, etc…

Hacer una aplicación que verifique los requisitos no significa una ejecución óptima del proyecto, hay muchos más factores, pero esto no debe minusvalorar el análisis de requisitos, ya que permite delimitar el alcance del proyecto (si no se delimita se corre el riesgo de que el proyecto no termine nunca) e indica el resultado final que espera el cliente.

Sabemos en este punto, qué es lo que quiere el usuario que haga el nuevo sistema de información y también los datos que quiere almacenar en el mismo.

Pues bien, todo lo anterior no sirve de nada sin una interfaz de usuario que le facilite el trabajo.

Mi recomendación es que se haga siempre un prototipo de la interfaz de usuario (al menos de las pantallas más significativas) y que quede reflejado además de forma clara el esquema de navegación entre pantallas.

El prototipo puede ir desde esquemas hechos con VISIO a páginas HTML e incluso algunas pantallas con funcionamiento dinámico u una combinación de las anteriores. Lo importante es que el usuario tenga claro que es lo que se va a encontrar cuando se implemente el programa y no se lleve sorpresas después que serán negativas para él y para el que desarrolla. Por otro lado cuando se le muestre el modelo cartón piedra de las pantallas es recomendable que se realice un repaso de los requisitos funcionales con el usuario para que pueda apreciar que todo lo que ha pedido (y se pueda verificar en esta revisión) está reflejado en el diseño de pantallas que se le muestra.

También es importante que se revise con esmero la información que aparece en las mismas, para que el usuario vea que todos los datos que ha pedido que se persistan están en las pantallas que se muestran.