MEHGEST - Seguridad / Integridad

En un entorno que seguramente va a ser complejo y con multitud de usuarios diferentes, las reglas de integridad que aseguren que todas las relaciones se mantienen correctamente y que los datos entrados son correctos son de vital importancia.

Campos Obligatorios

En toda implantación de herramientas necesitaremos poder especificar qué campos son obligatorios y cuándo lo son. Como mínimo, las herramientas nos suelen exigir toda una serie de campos obligatorios; las que son un poco más avanzadas nos permiten seleccionar qué campos son obligatorios para nuestra definición del proceso y, por último, las más avanzadas nos van a permitir indicar cuándo es obligatorio un determinado campo. Así, en un registro de incidencia el campo Interlocutor debería ser obligatorio siempre, mientras que el campo Impacto podría ser obligatorio a partir del momento en que se haya realizado el análisis de impacto de la incidencias y el campo Solución lo será a partir del momento en que demos la incidencia por cerrada.

La obligatoriedad o no de un campo no tiene que venir dada únicamente por el punto en el ciclo de vida (estado) en el que nos encontremos; también es interesante que se pueda forzar la obligatoriedad de un campo de forma dinámica en función de los valores presentes en otros campos. Así, por ejemplo, podremos decir que el valor de Tiempo Dedicado sea obligatorio siempre y cuando el tipo de Llamada de Servicio sea Solicitud de Instalación In-Situ y el Estado sea Finalizado.

Controles de Coherencia

Es posible que se entren datos en un registro que no sean coherentes. Lógicamente, no podremos aplicar todos los controles de coherencia posibles, pero si la herramienta nos permite definir reglas que evalúen la coherencia de los contenidos, podremos definir aquellos controles más importantes.

Integridad Referencial

A estas alturas no deberíamos tener la necesidad de preguntarnos si una aplicación mantiene la integridad referencial o no en las relaciones entre objetos, pero nunca se sabe. Tal y como se plantean este tipo de productos, tendremos una base de datos en la que vamos a almacenar elementos de configuracion, llamadas de servicio, problemas, personas, organizaciones, contratos... y todos estos tipos de objetos estarán relacionados entre si, de tal forma que tendremos personas en las llamadas de servicio, CIs en los contratos y en las llamadas, etc. ¿Qué pasa cuando se borra un CI? ¿Qué ocurre con todas las llamadas en las que está presente ese CI? ¿Qué ocurre con todos los contratos? ¿Y con los problemas que están relacionados con las llamadas que a su vez están relacionadas con los CI's?

Esto nos lleva normalmente a no poder borrar nada y, por lo tanto, debemos tener mecanismos que permitan "borrar pero sin borrar", dejar estos registros en el limbo de los datos referenciados.

Campos "Read-Only"

En realidad este punto debería llamarse "niveles de acceso a los campos", pero eso es un nivel de seguridad que pocas herramientas permiten. Así que como mínimo deberíamos poder establecer que determinados campos son de solo lectura para garantizar que no nos los modifiquen.