Obviemos la opción habitual: no vale decir que lo escrito sobre una servilleta de bar mientras tomamos un café son las especificaciones del usuario; ni tampoco vale decir que lo que quiere el usuario es lo que cualquiera sabe ya. Ni responder con que no nos pagan por plantear problemas sino por encontrar soluciones.
Como hemos dicho anteriormente en este blog, existen muchos estándares de documentación (uno de los más reputados es el del IEEE Pierre Bourque and Robert Dupuis, ed (2004). Guide to the Software Engineering Body of Knowledge - 2004 Version. IEEE Computer Society. p. 2–1. ISBN 0-7695-2330-7. http://www.swebok.org). Como todo estándard, lo importante es interpretarlo correctamente; por ejemplo, no hay que tomarlo al pie de la letra sino interpretarlo. Esto no significa reducirlo a un documento vanal sino adecuarlo a nuestras necesidades.
En SoftAuction hemos incluido modelos de especificaciones; las hemos dividido en dos partes:
- Documento Público: permite dar una visión general de las necesidades de la aplicación. Este documento es visible para todos los usuarios con perfil Desarrollador de Software registrados en la plataforma, siendo la información disponible para realizar una primera puja a la baja sobre el proyecto. Incluye los siguientes apartados (obviando el capítulo 1, que es genérico):
- Perspectivas del proyecto: Es una descripción general del proyecto. Esta sección pone el proyecto en perspectiva con otros sistemas relacionados. Si el proyecto reemplaza un sistema existente este deberá ser referenciado y explicado.
- Capacidades generales: Esta sección describirá las principales capacidades y por qué son necesarias. Se explicará el proceso que realiza el software.
- Limitaciones generales: Se describirán todos los elementos que puedan limitar las opciones de los programadores.
- Características de los usuarios: Esta sección deberá describir las características generales de los usuarios afectados por los requerimientos específicos.
- Entorno operativo: Se describirá el entorno real en el que operará el software.
- Hipótesis y dependencias: Se describirán las hipótesis en las que están basados los requerimientos específicos.
- Documento Privado: permite dar una visión concreta de las necesidades de la aplicación. Este documento es visible sólo para tres usuarios ganadores de la primera puja; siendo la información disponible para realizar una segunda puja definitiva a la baja sobre el proyecto. Incluye los siguientes apartados (obviando el capítulo 1, que es genérico):
- Requisitos relativos a capacidades de la Aplicación: que tiene que hacer la aplicación.
- Requisitos relativos a limitaciones de la Aplicación: que limitaciones se imponen a la aplicación
Estos requisitos tienen una tipificación concreta y exhaustiva. Cuando finalice el proceso de desarrollo, serán la base para realizar las pruebas de usuario que permiten demostrar que se ha desarrollado lo que el usuario solicitaba. Lo que no esta especificado no puede exigirse.
Es decir, sobre modelos más exhaustivos, en SoftAuction proponemos un modelo suficientemente detallado sin caer en el extremismo. Pueden utilizarse otros modelos (¿gato blanco o gato negro? ¡que más da! mientras cace ratones...) pero no se permite no especificar. Y se revisa que las especificaciones sean adecuadas.
De esta forma, podemos confiar en que se sabe lo que se quiere y que se puede exigir lo que se ha pedido. Gana la empresa que necesita una aplicación de negocio para optimizar sus procesos y gana el desarrollador que realize un trabajo profesional.
2 comentarios:
En general, de acuerdo con todo lo detallado. Ahora bien, es cierto que uno de los "miedos" que demuestran las empresas en esta fase del proyecto es el llegar a la "concreción" exhaustiva de los requerimientos, puesto que asocian que, luego son inamovibles y que, frente a ausencias, dudas u olvidos, tendran problemas en posteriores fases del ciclo de vida del proyecto.
Nada mas lejos de la realidad. Afortunadamente, las metodologías ya contemplan esa casuística y constan todas de los mecanismos adecuados para la modificación de los requerimientos sin perjuicio del resultado final.
Es decir, que haya cosas que no están del todo claras no significa que haya que dejarlas vagas e imprecisas en esta fase del proyecto, luego "Empresas: Especificad vuestras necesidades!!!"
Si nos fijamos en el modelo de especificación privada que proponemos, existe, para cada requisito, unas tipologías que indican si ese requisito es modificable, estable, etc.
Está estudiado que (dependiendo del número de requisitos de una aplicación; cuanto mayor el número de requisitos, menor el %) entre el 20% y el 40% de los requisitos sufren algún tipo de modificación durante las fases del proyecto.
Es decir, nada es innamovible, aunque algunas cosas si deben estar fijadas y no cambiarse (puedo cambiar el tipo de ruedas o instalarle un GPS en el concesionario pero no parece muy sensato que cambie de ser un deportivo a ser una furgoneta).
Una forma de tranquilizar a las Empresas para que especifiquen es aclararles que no todo tiene que ser especificado. Una forma de tranquilizar al Desarrollador para que haga un proyecto de calidad es asegurarle que lo principal esta especificado. El primero quiere tener flexibilidad; el segundo quiere tener seguridad. Como siempre, un punto intermedio en el que la colaboración entre estos dos actores sea honesta es el adecuado.
Por eso es por lo que es muy necesaria la figura de un Consultor con un profundo conocimiento del negocio que haga de intermediario entre las necesidades de la empresa y el detalle necesario por el desarrollador.
Publicar un comentario