Relativamente
hace poco tiempo se ha desarrollado una disciplina denominada: Ingeniería de
Requerimientos que procura brindarnos una metodología para que podamos definir
con claridad lo que el usuario nos pide como desarrolladores de software. Esta
disciplina tiene una serie de pasos que pueden variar dependiendo de las
estrategias de desarrollo de software que se hayan adoptado. Existe una gran
literatura en la web bien extensa y completa sobre este tema. Por tanto, en
este artículo me dedicaré a exponer en forma sencilla las prácticas que me han resultado exitosas en la
definición de requerimientos basándome en mi propia experiencia y sin atarme a
ninguna tendencia específica aunque pueda estar tomando algunos puntos
importantes de ellas.
En
mi experiencia, hay dos estrategias fundamentales que garantizan la definición
exitosa de un requerimiento:
1.-Divide y Reinaras
Esto
significa no esperar hasta el final para hacer entregas ni para realizar
verificaciones de las mismas. Esto implica dividir
la definición de requerimiento en “fases”.
Cada
fase debe de la definición del requerimiento debe:
Ø Tener al menos un entregable.
Un entregable es algo material, visible y tangible
que se presenta al usuario y al equipo de trabajo de las áreas involucradas que
constituye una evidencia del avance del ANÁLISIS del requerimiento.
Un entregable puede ser un documento en Word o pdf ,
una presentación en power point; una exposición donde se muestre cómo sería la
secuencia de pantallas y los campos, registros, ventanas y subfiles que habría
en cada una de ellas, un archivo grabado en cinta, un video, etc
En lo personal, la secuencia de pantallas es mi
favorito.
El entregable hace posible que las objeciones a la definición
del requerimiento sean detectadas a tiempo; permite rectificar y unificar
criterios; detectar condiciones de
ejecución, de validación o de operatividad que en la solicitud inicial no
fueron detectadas.
Ø Propuestas con soluciones verificables.
La verificabilidad es una lista de condiciones que
toda propuesta de solución debe cumplir.
La Lista
es la Siguiente:
·
Medible en
tiempo de respuesta.
Si el requerimiento se trata de reducir tiempos de ejecución,
debemos brindar una solución en la que demostremos que la duración del proceso
fue reducida. Debe especificarse en la solución propuesta: Cómo va a ser medido
el tiempo de ejecución: Por el log del sistema, por una rutina que graba la
hora inicio y hora fin, por un cronómetro, etc.
·
Visible.
El usuario debe ver que la data emitida por el
proceso es el resultado esperado. Esto significa generar pantallas, reportes,
consultas, queries, o cualquier medio de verificación que permita al usuario dar
fe de que el resultado obtenido es el correcto. Debe especificarse en el
documento de la solución propuesta: cómo el usuario va a comprobar el resultado.
·
Debe
permitir dejar evidencias.
Las evidencias son print de pantallas o generación
de listados de “antes” y “después” que permite comparar la mejora y dejar
constancia de la correctitud de la solución a aplicar.
·
Debe ser Comprensible.
El personal involucrado en la definición del
requerimiento debe comprender las soluciones propuestas. Nadie puede verificar
algo que no comprende. El lenguaje debe ser sencillo y al alcance de los
involucrados sin importar su nivel o área de formación.
·
Integrable.
La solución propuesta en cada fase debe ser
integrable parcial o totalmente con las siguientes fases o con la operatividad
del negocio y su plataforma informática actual.
2.-Presentación de Prototipos.
Un
buen desarrollador, debe tener un “KIT” de prototipos de programas.
Aplicando
esto e desarrollos en RPG- RPGILE y sus derivados Prototipos de programas deben
ser un surtido de modelos: con subfiles dinámicos y manuales, sin subfiles, con ventanas y sin ventanas con
pull down menu, con consultas dinámicas con botones y con teclas de función, listadores,
reportes estadísticos, etc.
Un prototipo no necesariamente debe tener operativas las teclas de función, las validaciones ni una gran navegación de pantallas. Lo vital son los campos en pantalla, el formato de cada una, la calidad y variedad de información que hay en ellas y la secuencia lógica que deben tener. Lo mismo se aplica al los reportes. Un diseño previo generado por la utilidad RLU podría ser suficiente.
Es
recomendable construir una documentación propia (en Word, Excel o como resulte
mas cómodo) del pool de programas y prototipos que están en el kit del programador.
Para ellos puede clasificarse los programas con palabras claves, breves resúmenes
funcionales, categorías y subcategorías de los prototipos que permita al
desarrollador acceder rápidamente a programas parecidos que sin estar
completados ni tener validaciones activas puedan ser ajustados para crear un
prototipo-entregable rápido que se vaya ajustando en cada fase del proceso de la
revisión del requerimiento. El prototipo además de ser en si mismo un
entregable permite ajustar en forma funcional el requerimiento inicial
solicitado por el usuario quien además tendrá una interacción practica aproximada
con la herramienta final que le será entregada.
Algunos
desarrolladores acostumbran dejar para el final este acercamiento entre el usuario
y el producto final desarrollado ya que tradicionalmente, en esta etapa de análisis
no se debería desarrollar nada. Sin embargo, aunque estemos en una fase de análisis,
la creación de prototipos sencillos permite suprimir desagradables sorpresas para
el usuario quien puede no estar conforme con una solución de la cual fue excluido
durante todo el proceso. La presentación de prototipos ahorra tiempo, esfuerzo
y reclamos innecesarios hacia el analista y el desarrollador de las
aplicaciones, quienes por alguna razón terminan, en la mayoría de los casos de
conflicto, con “las tablas en la cabeza”.
Si te pareció
interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al
final del artículo. El conocimiento es valioso, compártelo.
Autor:
Ing. Liliana Suárez
No comments:
Post a Comment