SISTEMA INTEGRAL DE INFORMACIÓN ADMINISTRATIVA

ESPECIFICACIONES GENERALES

INTRODUCCIÓN

Este apartado presenta el diseño del sistema computacional para el Sistema Integral de Información Administrativa (SIIA), así como las especificaciones técnicas para su construcción.

Para las especificaciones técnicas de construcción se han buscado aquellas tecnologías que, más allá de ser consideradas como el estado del arte en la ingeniería de sistemas, respondan a las necesidades de las instituciones en cuanto al tipo de sistema que se requiere implantar así como la flexibilidad que deberá tener para adaptarse a cambios institucionales o a los posibles cambios de reingeniería que se requieran a través del tiempo.

OBJETIVO DEL SISTEMA
Objetivo general

Construir un sistema de información que de manera integral permita la administración eficiente y confiable de los recursos humanos, financieros y de control escolar, de las instituciones educativas, y que coadyuve a generar información útil para la planeación, evaluación y toma de decisiones.

Objetivos Específicos
  • Contar con un sistema de información administrativa único e integral.
  • Que el sistema adopte los principios y criterios de la contabilidad de fondos.
  • Que el sistema genere información confiable y oportuna.
  • Que el sistema coadyuve a la toma de decisiones.
  • Que el sistema presente estados financieros bajo un enfoque integral, normalizado nacionalmente y compatible con estándares internacionales.
  • Que el sistema coadyuve a la modernización y eficientización de los procesos y estructuras administrativas de las instituciones donde se implante.
  • Diseño de Sistemas
Consideraciones Preliminares

Sobre la ingeniería de software se está llevando a cabo una fuerte discusión teórica por la evidente debilidad de las bases que le dan fundamento.

Esta discusión se centra en dos aspectos fundamentales, el primero que tiene que ver con una epistemología basada en el principio de autoridad ya que la mayoría de los tratados de ingeniería de software están basados en una combinación de experiencia anecdótica y autoridad humana, raramente se acompañan de evidencia lógica o experimental. Esto provoca la carencia de una base sólida que le dé un carácter científico a la ingeniería de software.

El segundo tiene que ver con un principio práctico aplicado de manera generalizada en la ingeniería de software, y es el famoso precepto de "divide y vencerás", es decir, se ha venido aplicando dogmáticamente este principio, separando las actividades propias del análisis de las actividades de diseño.

Por otra parte, se presupone que una vez establecido el algoritmo que se obtiene de la división del proceso de desarrollo de software en diversas etapas, se asume que es factible desarrollarlo sin considerar la posibilidad de llevar a cabo la construcción de un algoritmo que implique un costo injustificado e irrealizable en la práctica.

Es claro entonces que hay una falta de comprensión de la relación que existe entre las actividades de diseño y las de análisis. Dado lo anterior se puede establecer que durante la etapa de análisis se constituye el problema, pues no se obtiene un problema, sólo hechos, y justamente este paso de constitución del problema está necesariamente referido a su solución, es decir, a la etapa de diseño.

En este orden de ideas, la estrategia y metodología que se propone para la elaboración del diseño computacional del sistema no puede ser tajante ni rígida, por el contrario, sólo puede limitarse a enunciar un par de ellas, con el propósito de que cada institución valore y determine conforme a sus características, la mas adecuada a sus necesidades, o la combinación de diferentes modelos y metodologías de la ingeniería de software en un intento de robustecer (en la medida de lo posible, pues es un problema muy complejo) el diseño y la construcción del SIIA.

Modelo de Ingeniería de Software

Dos metodologías que pudieran adaptarse perfectamente para el diseño del SIIA son la comúnmente conocida como "modelo lineal y secuencial" y la del "modelo de construcción por prototipos".

Así también se pudiera considerar la opción de utilizar la combinación de ambos modelos, utilizando en primera instancia el modelo lineal secuencial(8) (solo para sus dos primeras etapas: análisis y diseño) lo cual permitirá establecer ciertas funciones y procesos de una manera formal así como documentar una gran cantidad de funciones y procesos que no se encuentren en documentos de manera formal; y el modelo por prototipos(9) para la construcción del sistema.

Consideraciones generales sobre el diseño del SIIA

A continuación se detalla una serie de consideraciones que se recomienda tomar en cuenta desde la etapa del diseño y respetarlas a lo largo del ciclo de vida del sistema.

El diseño del sistema deberá garantizar que los datos que integren al sistema se capturan una sola vez. En el caso de la base de datos se garantizará que no exista información redundante.

Para cada uno de los sistemas que componen el sistema integral, se deberán construir los mecanismos que hagan posible el seguimiento y control de gestión. Esto es poder monitorear el estatus en que se encuentra un movimiento.

El sistema deberá contemplar los filtros y sistemas de validación necesarios para garantizar la calidad de la información.

El sistema deberá contemplar los mecanismos y políticas de acceso; y seguridad que garanticen la confiabilidad e integridad de la misma.

El sistema deberá evitar en la medida de lo posible que se realicen movimientos no permitidos (que violen la normatividad de las instituciones). De preferencia deberá mantener una bitácora de las afectaciones e intentos por alterar la base de datos.

El sistema deberá estar diseñado para generar información de manera ágil y oportuna, de tal forma que coadyuve a la toma de decisiones.

Especificaciones de construcciones

  • Arquitectura cliente-servidor
  • La arquitectura cliente-servidor ha sido seleccionada como la más conveniente para la construcción del sistema, en virtud de la eficiencia que ha demostrado en aplicaciones de tamaño intermedio y de gran escala, las facilidades que las plataformas actuales de cómputo tienen, facilitan la implantación de aplicaciones cliente-servidor, flexibles y de fácil mantenimiento.

  • Capas
  • Una manera de potenciar la arquitectura cliente-servidor y que responda a las características que debe tener un sistema de esta naturaleza es la arquitectura de tres capas, la idea fundamental de esta tecnología es dividir las funcionalidades del sistema en tres grandes grupos: los servicios de usuarios, esta primera capa se encarga de identificar los objetos necesarios que interactúan con la interfaz de la aplicación; los servicios de negocios, esta capa agrupa los objetos que trabajan directamente con los procesos internos del negocio y los servicios de datos que son una colección de objetos que manipulan decisiones de los datos independientes de las reglas de negocio, esto se convierte directamente en un sistema para el manejo de base de datos. En la mayoría de los casos estas operaciones se realizan con la instrucción SQL.

    Se recomienda usar arquitectura de tres capas por tratarse de un sistema de lato volumen de usuarios concurrentes, una esperanza de vida de la aplicación mayor a tres años, la necesidad de autentificar usuarios individualmente de acuerdo con su acceso a la base de datos y una fácil implantación de componentes sin impactar de manera sustancial al sistema lo que permite flexibilidad en los cambios que se requieran producto de la evolución del mismo.

  • Niveles de acceso
  • Aunque podría considerarse tratado el tema de nivel de acceso de los usuarios en el punto anterior, conviene establecer de manera muy clara la necesidad de precisar en este sistema los niveles de acceso adecuados para cada componente del mismo. Esto evidentemente requerirá de la participación de la universidad en la definición de los niveles de acceso adecuados para cada usuario del sistema.

    Para el control de los accesos se deberá construir un modelo especial en donde para cada usuario o grupo de usuarios se deberán especificar los privilegios que tienen para ejecutar, acceder o modificar determinado proceso, subsistema o tipo de dato.

    Respecto al manejador de base de datos deberá existir un control estricto sobre quién tiene acceso a la base de datos. El administrador de la base de datos se responsabilizará de esta actividad.

    Así también deberá integrarse un programa de respaldos que garantice la reconstrucción de la base de datos a partir de los mismos.

Plataforma de construcción
Herramienta CASE

Para la definición del modelo entidad-relación se recomienda utilizar herramientas de tipo CASE. En el caso del desarrollo se propone el uso de alguna herramienta que permita la generación de código y documentación de manera semiautomática, con facilidades de reingeniería e ingeniería en reversa y que permita transportabilidad a diferentes plataformas y arquitecturas. También es importante mencionar que el uso de este tipo de herramientas apoyan de manera sustancial las actividades del desarrollo del sistema. Sin embargo, es la participación del usuario lo que garantizará un correcto desarrollo y desempeño del sistema.

Base de datos

Se requiere de un manejador de base de datos relacional que soporte el estándar SQL. Adicionalmente, que soporte un volumen de datos a gran escala, así como un número importante de usuarios concurrentes; que sea tolerante a fallas y que permita su rápida recuperación en caso de contingencias. Deberá soportar la arquitectura cliente-servidor.

Cliente de la base de datos

Se puede optar por una herramienta orientada a objetos para el desarrollo de servicios de negocios y un cliente de tipo visual o cualquier otro asociado a la base de datos seleccionada para la capa de servicios de usuarios. Es pertinente mencionar que una sola herramienta puede ser utilizada para el desarrollo de estas dos capas, sin embargo resulta muy eficiente usar la herramienta orientada a objetos para los servicios de negocios por la definición tecnológica de componente que éstos tienen.

Digitalización

Para todas las tareas de digitalización de documentos se propone el uso de escaners de alta velocidad con un motor de administración y recuperación de imágenes que permita la conexión natural a la base de datos seleccionada. Adicionalmente deberá permitir la incorporación de un sistema de reconocimiento óptico o inteligente de caracteres.

Análisis posconstrucción

A pesar de que esta metodología no es muy socorrida dentro de los desarrollos de sistemas tradicionales, principalmente por los costos adicionales que implica, debido a la magnitud del proyecto en cuestión, se considera pertinente que las instituciones que estén en condiciones implanten esta metodología.

Este análisis consiste en llevar a cabo una evaluación cuantitativa y cualitativa del desarrollo del proyecto con la finalidad de sistematizar el conocimiento adquirido durante su desarrollo, formalizar recomendaciones para hacer mejoras a las metodologías empleadas y la determinación del nivel de éxito y la calidad alcanzada en el desarrollo del proyecto.

Esta información pasará a formar parte de la base de datos de conocimientos de la universidad y coadyuvará a mejorar la calidad y el éxito de los futuros proyectos que se emprendan.

Infraestructura computacional

El dimensionamiento es uno de los aspectos que requieren mayor atención, ya que normalmente olvidamos que la infraestructura tiene un costo y el proyecto debe tener metas o acciones muy definidas, por lo que es necesario determinar los alcances del proyecto y los recursos que se requieren para tener un servicio con niveles aceptables en un tiempo aceptable. Normalmente la inexperiencia en este sentido incrementa los costos del servicio y los tiempos para obtener la solución, esto en el mejor de los casos.

Antes de tomar cualquier decisión es necesario diseñar el servicio que desee obtener y la forma en la que el servicio se va a portar. Apoyándose en los usuarios de cada área, en las herramientas que soportan las tecnologías de información y de ser necesario, en asesores de experiencia, se debe diseñar una estrategia robusta y un estudio del costo-beneficio, más aún, cuestionarnos objetivamente si el momento para el módulo es primero o cuál depende del otro para no duplicar la tarea.

(8) El modelo lineal secuencial sugiere un enfoque sistemático secuencial del desarrollo del software que comienza en un nivel de sistemas (conceptual) y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

(9) Recordemos que el modelo por prototipos permite al cliente valorar permanentemente los avances en el desarrollo lo que no sucede en el modelo lineal secuencial donde el cliente conoce el resultado del trabajo hasta el final de su desarrollo.