Uno de los avances más grandes en el desarrollo del software fue el intento de estandarizar, industrializar o sistematizar el proceso de creación del software. Este esfuerzo nos ha llevado a disponer de técnicas de gestión del tiempo, procesos y tareas. Ha evolucionado la generación de software. ¿Qué debemos hacer? Indica el análisis. ¿Cómo lo hacemos? Indica el diseño... pero, ¿Por qué lo hacemos?
Las fases acotadas del desarrollo tradicional de software indican que hay tres fases en la construcción de un software: Análisis, Diseño y Desarrollo. Estas son a grandes rasgos y se podrían desglosar hasta aparecer cientos de fases dentro de cada una de ellas.
En esencia, un análisis debe responder la pregunta, ¿qué debe de hacer el software? Este análisis obedece a unos requisitos que ha expuesto el cliente sobre qué es lo que quiere.
Este análisis es convertido en un diseño cuando se validan estos requisitos y se obtiene respuesta a la pregunta ¿cómo debe de hacerlo el software?. Se tienen en cuenta todos los condicionantes del cliente, de los requisitos, del entorno y de los elementos a emplear.
Es un sistema sencillo y práctico. Pero cuando comenzamos a desarrollar el software o incluso cuando ya lo obtenemos hay veces que surge la pregunta más importante de todas y que se debería de haber realizado antes del cómo e incluso antes del qué... ¿por qué debe hacer eso el software?
Muchas de la solicitudes que se hacen como requisitos son realizadas sin un estudio previo o desde el desconocimiento de la persona que lo solicita. Los requisitos deben ser analizados no solo desde el prisma de qué quiere decir el cliente con ese requisito (para así convertirlo en un caso de uso) sino por qué lo está pidiendo el cliente.
Recordemos que uno de los aspectos de nuestra profesión, además de convertir procesos manuales en automáticos a través de programas, es la optimización de los procesos, sean automáticos o no.
El documento de análisis por tanto, además de recoger los requisitos del cliente, es de suma importancia agregar un preámbulo en el que se especifiquen algunos datos clave para entender el negocio del cliente como:
-
El Modelo de Dominio, algo así como un diccionario o la jerga empleada por el cliente para referirse a elementos típicos de su actividad laboral y/o comercial.
-
Los Objetivos a alcanzar a través de este desarrollo por parte del cliente. ¿Qué quiere conseguir con este desarrollo? ¿Qué valor le aporta?
-
Los Procesos empleados por el cliente en el día a día. Cómo lo hace ahora. Servirá como validación para saber si hemos mejorado y optimizado los procesos del cliente en base a tiempo, esfuerzo y/o dinero.
Hay casos donde se desarrolla un producto interno. La propia empresa propia es el cliente. El Modelo de Dominio puede elaborarse para uso interno de los trabajadores. Los objetivos y procesos deberían indicarse como si el proyecto fuese para otra empresa.
¿Parece razonable? ¿Empleas en tu trabajo estas líneas para obtener información de tu cliente cuando vas a desarrollar un proyecto? ¿Agregarías algo más?
