Hace algún
tiempo, cuando me involucré en las iniciativas de mejoramiento de procesos de
Intergrupo, las que finalmente condujeron a alcanzar el nivel CMMI 5, entendí
que la cultura orgánica tiene su propio proceso natural de supervivencia y
éxito y que siempre debía medir cuidadosamente lo que es adicionado y es
removido de mi entorno. Por supuesto, siempre he tenido claro cuando ser
“interno” o “externo” al proceso.
Fue una
época en que puse en práctica algunos de los principios memorables de Deming en
Administración: “La mejora de procesos debe ser realizada para mejorar el negocio – No
como un objetivo en sí misma”. Y empezaba a pregonar que un proceso debe usar
prácticas probadas en la industria, no solo la última moda, lo que escuchamos
en la conferencia del día anterior o lo que leímos en el último artículo de la
IEEE.
Y lo más importante, difundía a mil voces que debemos ser prácticos, que
debemos entregar la información que se necesita, cuando se requiere y en un
formato que se pueda usar. Con todo esto en mente, usamos un modelo de madurez
típico como CMMI para mejorar nuestros procesos. Y uno de los primeros procesos
que optimizamos fue este de la Ingeniería de Requisitos.
Pero ¿cómo saber si tu proceso es lo suficientemente maduro? ¿En la
práctica qué significa identificar, documentar y administrar requisitos de
software de una manera formal y razonable? Según el SEI (siglas en inglés del
Instituto de Ingeniería de Software), autor del modelo CMMI, “los requisitos
son manejados y las inconsistencias con los planes de proyecto y los productos
de trabajo son identificadas”.
Lo que no dice el SEI en su área de proceso de RM (siglas en inglés de
Administración de Requisitos), es que esas inconsistencias deben detectarse a
tiempo porque cualquier cambio que involucre requisitos es altamente costoso
para el proyecto y para los participantes en el mismo.
Para manejar los requisitos, el SEI recomienda:
·
Entender los requisitos
·
Acordar los requisitos con todos los involucrados
·
Administrar los cambios a los requisitos
·
Mantener una rastreabilidad bidireccional de los requisitos
·
Identificar las inconsistencias entre el trabajo del proyecto y los
requisitos
Parece
sencillo pero quienes hemos trasegado por los vericuetos de la Ingeniería de
Requisitos con casos de uso sabemos que es más fácil decirlo que hacerlo y,
sobre todo, hacerlo bien. Por ejemplo, sin duda es más simple entender y
acordar requisitos entre las personas que están más involucradas en el proyecto,
como los Analistas y los usuarios que quienes empiezan a llegar a medida que
avanza el ciclo de vida, como los programadores o los certificadores.
Manejar los
cambios, naturales por demás en un proyecto típico de software, es muchas veces
otro dolor de cabeza para los participantes. Hay quienes creen que una
solicitud de cambio es algo de menor valía, cuando la experiencia nos ha
enseñado que sea cual fuere el momento y la fuente de la solicitud, siempre hay
un impacto significativo y hay costos ocultos que solo los experimentados son
capaces de descubrir a tiempo.
Por su
parte, mantener una trazabilidad adecuada de los requisitos en ambas
direcciones, lo que significa tener un mapa desde las necesidades del usuario y
características del software, hasta el código ejecutable, pasando por los casos
de prueba y otros artefactos importantes, es algo que solo se puede lograr
adecuadamente con el uso de herramientas especializadas. En proyectos pequeños
es posible que un Excel sirva, pero en algo más elaborado necesitamos de los
instrumentos apropiados.
En cualquier
caso, estas prácticas recomendadas (y esta es la palabra clave:
“recomendadas”), son apenas un primer escaño para alcanzar la tan ansiada
madurez en nuestros procesos de Ingeniería de Requisitos. Volveremos sobre ello
más adelante.
