Diseñando Sistemas III: El análisis del sistema

Continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información (véase Diseñando Sistemas II: El diseño del sistema y Diseñando Sistemas I: La toma de requerimientos), una vez definido el diseño del sistema, entramos en la fase de análisis detallado del mismo. En esta etapa, si es necesario, se puede plantear un documento de análisis detallado de las funciones o directamente un análisis técnico de las mismas. Bajo mi experiencia, el primero solo reflejaría el flujo de información y las decisiones y ramificaciones posibles del mismo, así como los puntos de entrada de la información y los diferentes casos de conjuntos de datos que pueden darse para su proceso. Igualmente indicaría las transacciones válidas y el modo de controlarlas, y las prohibidas —si las hubiera— y el modo de actuar sobre ellas.

El análisis técnico debe reflejar con suficiente detalle los controles y acciones a ejecutar con cada modelo posible de datos, así como los conceptos que componen su proceso y como llevarlo a cabo. Es decir, debe definir con detalle las transacciones y sus condiciones de proceso, así como los resultados que se pretende obtener, reflejando su contenido, formatos y también cualquier control o acción requeridos con antelación o posteriormente.

Son conceptos básicos pero que frecuentemente se olvidan —aunque les parezca mentira hoy aún se olvidan—. Por ejemplo hacer la captura de datos en línea, incluyendo la validación de éstos en el momento de su captura y no en procesos posteriores, ya que la información errónea no debería entrar en el sistema ni formar parte de su base de datos. Esto evitará procesos inútiles y revisiones posteriores de los datos. Si quien la genera sabe que en el caso de no ser correcta, la información será rechazada, procurará depurarla por sí mismo.

Obviamente, para poder hacer lo anterior, es necesario tener cuidadosamente definidos los controles a realizar y estos son los que deben describirse en el análisis detallado, indicando contra qué otra información o combinación de informaciones se va a validar cada uno. Para ello ya propuse en el artículo sobre el diseño detallado, la definición de parámetros y datos de control que el administrador del sistema o el usuario experto responsable deberá introducir previamente en las tablas de control.

Una vez dada por buena la información introducida, lo lógico es que sea válida para alguna de las posibles transacciones que el sistema “sabe” ejecutar y por tanto no haya problemas de error de datos o cancelación de programas si estos han sido desarrollados de acuerdo a las especificaciones detalladas del análisis técnico y éste ha previsto las diferentes posibilidades. Para conseguir esto, dicho análisis debe reflejar cómo ejecutar cada paso del proceso o transacción, con información suficiente para que el programador pueda comprenderlo y aplicarlo en su código, e igualmente pueda plantear las pruebas y validar los resultados.

Creo que es de suma importancia llegar a este punto con la mejor definición de los procesos que sea posible y que esta quede bien documentada, evitando que sea transmitida en reuniones de viva voz (muy frecuente) confiando en el buen hacer de los programadores que tomarán sus notas interpretando por si mismos lo que el analista o jefe de proyecto les cuenta, y que a su vez, es una interpretación de lo que el cliente les ha pedido. Un buen análisis funcional (o diseño del sistema) es la base para un buen análisis técnico (o especificaciones de programa) y estos dos son la base para desarrollar un sistema fiable y rentable.

Bajo mi experiencia, transmitirle al programador el fundamento de los procesos es esencial, no solo para obtener un buen resultado técnico sino para que facilite igualmente su gestión posterior por parte de los usuarios, así como su explotación. La fase de programación y pruebas de un sistema ha sido considerado tradicionalmente la de mayor duración en el desarrollo de un proyecto, pero generalmente esto se debe a la falta de definición de las necesidades del cliente y de los detalles del proceso requerido, en definitiva a un análisis incompleto o poco documentado. La experiencia me ha enseñado que la inversión de tiempo en estas dos etapas anteriores al desarrollo es muy rentable si este último puede hacerse con claridad y rapidez, y las pruebas plantearse con criterios de conocimiento adquirido de lo que se pretende obtener.

Considerar que el programador no necesita conocer el fundamento o el porqué de muchas de las decisiones que el programa va a ejecutar es un tremendo error, ya que limita de manera importante su creatividad y la aplicación de su propio conocimiento y experiencia en el desarrollo, incluso impide que el programador que conoce bien las herramientas que al final van a procesar la información, pueda sugerir algunas mejoras en la propuesta técnica, aportando cierto valor añadido a la misma. Lo más probable es que esto conduzca a tener ciclos de error – revisión – prueba – y nuevo error, hasta perder mucho tiempo (y aumentar el coste) y lo que es peor, comenzar a estresar al equipo porque las fechas de entrega se acercan o sobrepasan y el coste se dispara, lo que genera casi siempre nuevos errores y acaba con la entrega de un producto de calidad inferior a la deseada y prometida al cliente, que va a requerir soporte continuo hasta quedar depurado. Frecuentemente suele disimularse o camuflarse el coste indeseado de esta última fase, dentro de las actividades de un nuevo proyecto, lo que además de injusto, vuelve a ser un error.

Así pues, el responsable del proyecto deberá controlar cada etapa del mismo y validar la documentación y el medio mediante el cual se transmite la información y el conocimiento adquirido sobre los procesos a ejecutar, para que cada componente del equipo pueda realizar correctamente su trabajo.