Jummp’s Blog

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.

Uno de los aspectos que más me preocupan en el desarrollo de proyectos informáticos es que el producto llegue al entorno de producción con el menor número de errores funcionales, que tenga un buen rendimiento y sea fácilmente mantenible a nivel de código y de documentación.

Esto que parece de perogrullo, es tremendamente difícil sobre todo si nos encontramos con proyectos de una gran envergadura con un parque de usuarios heterogéneo en localizaciones dispersas con distintos nivel de calidad en su ancho de banda.

Después de analizar las metodologías de desarrollo clásicas como Métrica v.3 y tratar de hacer uso de ella en mis proyectos (más bien un subconjunto de ella, pero aunque sea un subconjunto, por definición de Métrica v.3 sigue siendo Métrica v.3) he llegado a la conclusión de que sin ser una mala opción, hay algunos aspectos que sí es conveniente centrarse y en otros menos:

- Plan de proyecto. Contendrá el cronograma del proyecto (lo mejor es que ese cronograma se mantenga con una herramienta informática compartida: Redmine, dotProject, etc…), por lo que valdrá con una referencia a la url donde se puede seguir el cronograma del proyecto, el equipo de proyecto (igualmente lo mejor es que ese equipo de proyecto se vaya actualizando, por tanto lo mejor es una herramienta informática compartida y si es la misma que la del cronograma, mejor que mejor y se sepa si así lo desea el cliente su imputación de horas al proyecto) y la documentación que deberá acompañar al proyecto.

- Lo fundamental en un proyecto de desarrollo de software son los requisitos. La empresa que posea analistas con la suficiente capacidad para obtener del usuario lo que quiere (cosa tremendamente difícil) tienen una ventaja muy importante respecto a sus competidores. Este catálogo de requisitos es fundamental tenerlo actualizado en todas las fases del proyecto, incluido el mantenimiento. Si es necesario dedicar tiempo a una fase del proyecto concreta esta es el análisis de requisitos. El catálogo de requisitos debe ser completo y fácilmente inteligible por el usuario. Si hay presupuesto en el proyecto y puede facilitar el proceso de desarrollo el analista puede trabajar con los diagramas de casos de uso.

- Modelo de datos. Muy importante tenerlo documentado en la versión 1 del proyecto. Para posteriores versiones, si en el mantenimiento hay presupuesto y tiempo (aspectos no siempre disponibles) se puede mantener la documentación del modelo de datos, en caso contrario no pasa nada, siempre hay herramientas que te los puede obtener por ingeniería inversa a través de la base de datos.

- Interfaz de usuario. Es fundamental que el usuario conozca y valide la interfaz de usuario, ya que es donde ellos van a trabajar, de nada vale saber lo que quiere el usuario si después la interfaz de usuario no es ágil. Por este motivo también conviene invertir en esta fase del proyecto. Cuanto más se aproxime esta interfaz de usuario a su implementación real, más conciencia tendrá el usuario de lo que se va a encontrar y por tanto más posibilidades de éxito existen en el proyecto.

- Arquitectura del sistema. Debe ser breve, conciso y cuanto más gráfico mejor. Es importante para proyectos donde se deleguen funcionalidades en terceras herramientas (motor de tramitación, plataformas de autenticación y firma electrónica, etc…).

- Plan de pruebas (unitarias, integración, sistema, implantación y aceptación). Aunque es una realidad que nosotros, los clientes, tengamos nuestros propios medios para garantizar la calidad de las entregas, son absolutamente necesarias dos premisas: Que la empresa desarrolladora realice un primer filtro de pruebas muy importante (nunca es perdido el tiempo que se dedica a probar) y que se entregue un manual de pruebas al cliente donde como mínimo se pueda garantizar, tras realizar las pruebas, que el sistema funciona y que además verifica los requisitos funcionales y no funcionales más importantes.

- Manual de usuario. Debe estar siempre actualizado. Ser muy completo y tener casos de uso reales en los que se refleje, al menos, el 90% de la casuística del programa. Si el manual está accesible on-line por los usuarios mejor que mejor, independientemente de eso es aconsejable que sea también fácilmente imprimible.

A todo lo anterior es necesario sumar la necesidad de utilizar un sistema de control de versiones buenos, como por ejemplo Subversion y hacer un buen uso del mismo (política correcta de etiquetado de versiones, etc…), utilizar unos mecanismos estándar para el despliegue de los proyectos: MAVEN + Hudson + Artifactory, por ejemplo y algo fundamental, un libro blanco de desarrollo que homogeinice los desarrollos que se realizan para tu organización.