Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

domingo, 29 de junio de 2014

¡Hey!... ¡Eso No Fue lo Que Yo te Pedí!

























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 hay comentarios: