En el desarrollo de sistemas de software, muchos años de análisis de requerimientos, nos han enseñado que el único enfoque exitoso es aceptar lo que existe en el entorno del usuario, sin importar cuán lejos estén de lo ideal esas condiciones, y trabajar dentro de esas limitaciones.
Puede ser muy tentador usar el tiempo de análisis para intentar reenfocar cómo el usuario hace negocios. Sin embargo, los esfuerzos para rediseñar o hacer reingeniería, a menos que sean específicamente solicitados por el usuario, generalmente serán un desperdicio.
Aunque su evaluación puede ser correcta y sus sugerencias potencialmente útiles, ser correcto es menos importante en esta situación que ser asertivo y comprender la capacidad de sus usuarios para implementar y utilizar con éxito lo que necesitan.
Los analistas tienden a ignorar esta simple hecho, para gran disgusto de ellos mismos y de sus clientes.
Observar un ejemplo típico de una situación de análisis ayudará a ilustrar este punto.
Supongamos que una empresa necesita un modelo de base de datos relacional para recopilar información sobre un área temática del negocio.
Hay varias oficinas que necesitarán conectarse a un servicio proporcionado a nivel nacional. Los usuarios no están de acuerdo sobre la misión de las aplicaciones y no pueden determinar qué informes o información de consulta desean.
Algunas oficinas están automatizadas, pero no tienen el mismo software y hardware. Hay poca experiencia en la comunidad de usuarios para determinar los requisitos de datos y los diseños de archivos (identificando elementos en cada archivo).
La gerencia ha solicitado que el analista establezca una especificación que identifique los requisitos del sistema, así como el hardware y software necesarios.
Ante una tarea tan difícil de manejar, muchos analistas adoptarán el siguiente enfoque en un intento de imponer orden a una situación desordenada:
- Forzar a los usuarios a definir todos los requisitos. Dado que no pueden hacerlo, esta insistencia probablemente resultará en que adivinen o proporcionen información incompleta.
- Determinar la configuración de hardware y software, a pesar de tener requisitos inexactos o incompletos e ignorar la seguridad.
- Establecer un plan de proyecto que todos saben que fallará, pero hay que seguir adelante con él de todos modos.
Debe quedar claro que este enfoque es incorrecto, en varios aspectos diferentes. Sin embargo, tal enfoque es demasiado típico para los analistas que se enfrentan a un entorno de trabajo menos que ideal.
Afortunadamente, hay un mejor enfoque para todos los interesados, uno que reconoce y responde a las condiciones realmente presentes en el sitio de los usuarios en cuanto al Desarrollo de Sistemas de Software.
En este caso, es evidente que los usuarios no están posicionados para proporcionar los requisitos para un sistema, en gran parte porque no comprenden completamente sus propias necesidades y porque no están de acuerdo entre sí.
Lo que el analista necesita comprender en tal situación es que, debido a esta falta de conocimiento y organización, las necesidades del usuario tenderán a cambiar durante el proceso de análisis y diseño del producto.
Tales cambios son de esperar; son simplemente parte del ciclo de vida en el desarrollo de sistemas de software para esta implementación en particular.
Ignorar la situación e intentar implementar un sistema es invitar al fracaso. En pocas palabras, entonces, se debe de trabajar bajo estas circunstancias aceptando la realidad y no tratando de modificarla.
La tarea del analista de requerimientos es trabajar con lo que se tiene, en lugar de intentar cambiarlo o, incluso peor, simplemente negarlo.
Una vez que que se comprende esa realidad, también se comprenderá que la solución debe acomodar lo que inevitablemente ocurrirá.
- Concentrarse en diseñar un modelo que pueda proporcionar a los usuarios y consumidores la capacidad que desean. Crear un plan de proyecto que asuma que la base de datos estará incompleta durante la Fase I debido a la incapacidad de los usuarios para definir la información correcta. Por lo tanto, el proceso de desarrollo de sistemas de software será iterativo y se finalizará durante las últimas etapas del ciclo de vida del desarrollo.
- No se debe intentar identificar el hardware antes de que esté claro cuáles son los requisitos de uso, como el procesamiento en horas pico, el número de usuarios, etc.
- Es buena práctica establecer un sistema o herramienta de software que permita a los usuarios generar nuevos escenarios para que puedan ver cómo estos escenarios se relacionan con todo el sistema.
- Configurar un programa piloto. Esto requerirá que ciertas oficinas acepten ser sitios de prueba para las primeras versiones del software. La función del piloto es proporcionar comentarios sobre la efectividad y las deficiencias del producto. Es importante establecer claramente los objetivos del piloto y el formato de los comentarios para garantizar el éxito del ejercicio.
- Formulare un plan que represente un cronograma para implementar en toda la empresa y poner en funcionamiento en el nuevo sistema de software. Es importante ser sensible a las políticas de la situación y utilizar un enfoque realista que no requiera un cambio de cultura organizacional para implementar el software en el entorno existente.
La esencia de este enfoque en el desarrollo de sistemas de software es contemplar una estrategia que se ajuste a la realidad del entorno, en lugar de forzar al entorno a cambiar.
No hay dos proyectos de desarrollo de sistemas de software idénticos, y cuanto más familiarizado esté el analista con el entorno, más exitoso será el proyecto. La combinación de metodologías le brinda al analista una gama más amplia de herramientas.
La experiencia práctica demuestra que este tipo de combinación de metodologías se puede hacer con bastante éxito y que es apropiado en un gran número de situaciones de análisis.