Sistemas de Seguridad.El Proceso de Desarrollo de Sistemas

Con el conocimiento de lo que es un Sistema, de lo que significa la Seguridad y con algunos principios básicos, relativos al desarrollo de sistemas, podemos emprender la descripción del proceso de desarrollo de un sistema de Seguridad.

Como siempre, debemos dejar claro que aquí nos ocuparemos de aspectos generales, que cada sistema tendrá sus particularidades y que éstas podrían ser determinantes en el éxito del sistema.En el proceso de desarrollo de un Sistema de Seguridad quedan comprendidas siete grandes tareas:

1. Declaración del problema. 2. Investigación de alternativas. 3. Modelación del sistema. 4. Integración del sistema. 5. Liberación del sistema. 6. Evaluación del Desempeño. 7. Re-evaluación y mejoramiento de la calidad.

Como se ilustra en el diagrama, la primera gran tarea consiste en la identificación del cliente, así como de sus requerimientos; enseguida, las tareas restantes se ejecutarán ordenadamente hasta conseguir integrar los procesos y/ o productos que satisfagan los requerimientos del Cliente.

1

Sin embargo, el desarrollo de un sistema de seguridad, como se observa en la ilustración, no es un proceso lineal que inicie y termine, sino que es un proceso cíclico que continuamente revisa el desempeño de sus productos y procesos, así como los cambios en los requerimientos de los clientes o en los clientes mismos. Esta tarea, de continua autoevaluación, del sistema de seguridad es la que asegurará el mejoramiento en la calidad y la continuidad de su operación, así como la inalterabilidad de los valores.

En las páginas que siguen revisaremos con un poco más de detalle cada una de las tareas implicadas en el proceso de desarrollo de un sistema.

1. DECLARACIÓN DEL PROBLEMA

Esta tarea, la declaración del problema, es probablemente la más importante del proceso de desarrollo del Sistema de Seguridad. Los clientes del sistema tienen una perspectiva especial respecto de lo que desean obtener del sistema de Seguridad: ellos desean solución a sus problemas. En otras palabras, desean evitar todo aquello que ocasione desviaciones a las situaciones que ellos consideran normales.

Ya lo hemos mencionado antes, un problema es cualquier desviación de una norma (Explícita o Implícita); así pues nuestra labor consistirá en auxiliar al cliente a expresar las normas, a identificar las desviaciones y a generar productos y procesos que eviten o reduzcan tales desviaciones.No importa que tanto ingenio, tecnología o recursos se empleen en una solución, si ésta se aplica al problema equivocado o a uno inexistente.

Debemos comenzar la declaración del problema con la descripción de la Misión (la función de más alto nivel) que el sistema deberá cumplir o de la deficiencia que el sistema deberá eliminar. Es importante preceder el inicio con una razón que justifique los cambios, seguida de una declaración de la Visión (Los efectos que se esperan conseguir).

La Misión y la Visión permitirán establecer la indispensable equifinalidad para el resto del proceso; Es necesario que estas declaraciones se hagan en cuanto a lo que se debe hacer, no a la manera de hacerlo.Las ideas que conformarán la Misión y la Visión deben provenir de usuarios finales, operadores, propietarios, leyes, patrocinadores, Mercadotecnia, Manufactura, etc., todos aquellos que serán afectados por la solución.

2

Aunque ya lo hemos mencionado, recordaremos que los problemas de los sistemas complejos no pueden tener una única solución óptima. La gran diversidad de componentes relaciones y criterios a considerar, hacen que existan diversas alternativas de solución; de hecho, la labor del responsable del desarrollo del Sistema de Seguridad es crear un conjunto de diseños alternativos que satisfagan los criterios de costo y rendimiento en grados variantes. Cuando revisamos las diversas alternativas, encontraremos que algunas de ellas satisfacen mejor ciertos criterios, mientras que empeoran en el cumplimiento de otros, es decir, descubriremos relaciones de interdependencia. Es prácticamente imposible que una de las alternativas optimize todos los criterios. Por consiguiente, ningún sistema complejo tiene la probabilidad de resultar óptimo para todas las personas, todo el tiempo.

La anterior afirmación nos permite comprender la importancia de la constante revisión del desempeño de un Sistema y la interminable labor de mejoramiento del mismo. Siempre será posible mejorar algunos subsistemas, pero cuando estas mejoras son integradas al sistema global, podemos esperar reacciones imprevistas.

Como en los deportes de conjunto, el mejor equipo no se integra, necesariamente, con los mejores jugadores, así el mejor sistema no necesariamente resulta de la integración de los subsistemas que mejor funcionan en forma independiente.

a. Las Necesidades del Cliente

A los clientes o beneficiarios del sistema de Seguridad frecuentemente les resulta difícil detallar lo que quieren o necesitan. Los responsables del Sistema de Seguridad están obligados a comprender el ambiente en que el cliente se desempeña.

Básicamente las necesidades de los beneficiarios del sistema de seguridad se manifestarán en términos tales que relacionen los Valores con las diversas amenazas que podrían afectarlos, es decir en términos que expresen las hipótesis de daño.Las expectativas de los clientes del sistema de Seguridad se centrarán en que los valores considerados permanecerán sin alteración alguna, gracias a la protección que dicho sistema proporcionará (Solución). Recuerde:

1. Identifique a los clientes del sistema, usuarios y funcionarios. 2. Identifique los Valores para cada uno. 3. Defina, con los clientes, los criterios de Prioridad.

3

4. Clasifique por prioridades expresas. 5. Identifique las Amenazas para cada Valor. 6. Describa parámetros de Daño, Peligro y Seguridad. 7. Desarrolle una declaración para cada Hipótesis de Daño. (Declaración

del Problema).

Procure que en esta fase sus criterios sean suficientemente amplios para dar flexibilidad al Diseño; para auxiliarse procure elaborar prototipos, servirán para identificar aspectos que podrían soslayarse.

El término Cliente implica a todos cuantos están habilitados para expresar requerimientos en el sistema: instituciones de Gobierno, dueños, beneficiarios, usuarios finales, funcionarios, víctimas, etc.

b. Los Requerimientos del Sistema

Podemos clasificar los Requerimientos de un Sistema como: Obligatorios y Preferenciales (ponderables).Los Requerimientos Obligatorios aseguran que el sistema satisfaga las necesidades operacionales del cliente. Algunas de sus características son las siguientes:

Especifican las condiciones indispensables y suficientes que un sistema mínimo debe contener para ser aceptable (se escriben normalmente con las palabras debe y deberá.). Los criterios para calificarlos sólo pueden ser: Cumplido o Fallados; No puede haber términos medios en su calificación, ni se usan sistemas de puntaje. Su carácter obligatorio no permite que su satisfacción sea negociada con otros requerimientos.

Un ejemplo de un requerimiento del cliente puede ser expresado de la forma siguiente:

“Las armas de fuego son un medio de defensa. No se utilizarán para amenazar ni se dispararán en señal de advertencia o con motivo de faltas administrativas.”

4

Hipótesis : El uso indebido del arma de fuego, por parte del Personal de seguridad, puede ocasionar daño a la Vida Humana. Requerimiento del Sistema“Jamás se proporcionará un arma al personal de seguridad sin antes entrenarlo en su manejo. Debe además capacitársele periódicamente en el uso de la misma”.

La mayor utilidad de los requerimientos obligatorios estriba en que permiten eliminar las alternativas que no los satisfacen, evitando consideraciones posteriores. En el ejemplo de arriba, el requerimiento del cliente, reexpresado como requerimiento obligatorio del sistema, permite eliminar la consideración de emplear personal de seguridad, sin entrenamiento en el uso de armas de fuego, para los puestos en que éstas son requeridas.

Aquellas alternativas que pasen el filtro de los requerimientos obligatorios podrán ser evaluadas en función de los requerimientos preferenciales. Estos últimos tienen las siguientes características:

Declaran condiciones cuya calificación guarda una relación directa proporcional con la satisfacción del cliente, (se escriben a menudo con la palabra debería.); Utilizan funciones de puntaje para evaluar su desempeño, y Cuando su evaluación depende de más de un criterio requieren del empleo de alguna técnica que permita ponderar relaciones de interdependencia.

Los Requerimientos Preferenciales típicos pueden ser expesados de la forma siguiente:“La cobertura del CCTV debería abarcar todos los accesos de las instalaciones principales”.“La cobertura del CCTV debería ser de 24 horas en los accesos a las instalaciones principales”.

En los ejemplos anteriores, puede ser que alguna alternativa sólo cubra dos tercios de los accesos, durante las 24 horas y que una segunda alternativa cubra el total de los accesos, pero no pueda operar más de 12 horas continuas.Mucho cuidado debemos tener al declarar los requerimientos, palabras tales como perfeccionar, maximizar y minimizar, deben ser evitadas ya que no permiten la cuantificación del requerimiento.

5

c. La Validación de los Requerimientos.

Una vez que los requerimientos han sido identificados, declarados y clasificados, debemos iniciar su Validación, esta tarea implica que:

Podamos asegurar que el conjunto de requerimientos esta completo y que es consistente con la Misión del Sistema. Requerimientos tales como “incrementar la calidad del proceso de teñido”, pueden no corresponder a las misiones de nuestro sistema de seguridad. Cada requerimiento disponga de criterios de evaluación y unidades de medida. Hemos mencionado antes que algunos requerimientos presentarán dificultades para su evaluación, sin embargo debemos dejar constancia de esto por escrito y debemos procurar agregar métodos de evaluación. Ejemplo: “Debe mejorar el trato del personal de Seguridad hacia los empleados de la empresa. Para evaluar este requerimiento se efectuarán encuestas trimestrales entre el personal y se publicarán los resultados”. Los requerimientos apuntan hacia soluciones posibles y alcanzables. Algunos requerimientos pueden empujarnos hacia soluciones Financiera, Tecnológica o Legalmente imposibles. Ejemplo: “Debe aplicarse un examen antidopping a toda persona que desee ingresar a las oficinas principales”.

Si el responsable del Proyecto descubre que los Requerimientos del cliente describen una solución imposible o irreal debe volver a revisar las necesidades con los clientes del sistema. Es frecuente que durante la validación de los requerimientos se descubra que estos hacen referencia a algún sistema ya existente, alguno que satisface, en gran medida, los requerimientos expresados.

2. EVALUACIÓN DE ALTERNATIVAS

Una vez que hemos logrado claridad en la expresión de los requerimientos y hemos descartado las alternativas que no satisfacen los requerimientos obligatorios, estamos en posibilidad de iniciar la evaluación de las alternativas restantes. Esta evaluación se realizará aplicando criterios relacionados con el desempeño, del costo y otras figuras de mérito.

Entre las dificultades de esta tarea podemos advertir la posibilidad de encontrarnos con varias alternativas que satisfacen mejor algunos criterios que otras y que, a pesar de esto, no encontremos, a simple vista, una alternativa que pueda ser calificada como la mejor; es aquí donde debemos echar mano de técnicas para la toma de decisiones con criterios

6

múltiples, que nos permitan descubrir las alternativas que satisfagan mejor las preferencias. Ejemplo:

Eliminar las alternativas que no satisfagan los requerimientos obligatorios: Identificar, listar y clasificar por prioridad los requerimientos preferenciales:

Describir la manera en que cada alternativa satisface cada requerimiento y asignarle una calificación de entre un rango especificado. La mayor calificación en el rango para la mejor satisfacción y la menor calificación en el rango para la peor satisfecha.

En cuanto más complejo es un sistema, la Evaluación de Alternativas adquiere una mayor importancia, ya que ayuda a reducir el riesgo del proyecto. No olvide considerar la evaluación de alternativas raras o absurdas, así como la “alternativa NULA”, pues esto mejorará la comprensión del problema.

3. MODELACIÓN DEL SISTEMA

Una vez que hemos filtrado las alternativas y hemos decidido por las mejores, de acuerdo con los requerimientos de los clientes, debemos desarrollar un modelo para cada alternativa seleccionada. Existen muy diversos tipos modelos de sistemas, tales como aparatos físicos, ecuaciones, maquetas, diagramas y simulaciones por computadora. La utilización de los modelos nos permite reducir los costos y la ineficiencia derivados de la redundancia de esfuerzos, de los cuellos de botella y de actividades fragmentadas.

a. Diseño del Sistema

Como parte importante de la tarea de Modelación del Sistema esta el Diseño, en esta subtarea es importante considerar los siguientes aspectos:

El Análisis. Se debe dividir el sistema global en subsistemas, se deben dividir los subsistemas en ensamblajes, etc.

La Reusabilidad. En el caso de nuevos diseños, los componentes que se creen deben considerar ser reusados en productos futuros. En el caso de rediseños, los subsistemas se deben crear para emplear al máximo posible los componentes existentes o los comercialmente disponibles. Ejemplos:

7

Si se desarrolla un Reglamento Interno de Seguridad, es conveniente utilizar un método de codificación y registro de las normas, que permita agregar, eliminar o modificar la normatividad, sin necesidad de tirar los reglamentos anteriores.

Innovación. Una de las decisiones a tomar consistirá en fabricar o comprar los componentes; se debe tratar de usar lo comercialmente disponible. En caso de que esta opción no satisfaga los requerimientos, entonces debe acudirse a la modificación de componentes existentes. Sólo en caso de que esto último no resulte satisfactorio, se podrá recurrir al diseño propio de los componentes. Ejemplos: aún cuando resulta sumamente atractiva la utilización de tecnología de avanzada, asegúrese de que los componentes que está integrando a su sistema de seguridad están disponibles en el mercado o que existe la posibilidad de reemplazarlos por otros existentes.

Interacción. Al diseñar o integrar un componente o subsistema es indispensable tener una clara comprensión de los subsistemas y/o componentes con los que su sistema interactuará. Recuerde que cada vez que integra algún cambio puede estar afectando las operaciones de otros sistemas con los que se relaciona. Ejemplo: La contratación de nuevo personal de seguridad, acarreará necesariamente nuevas tareas administrativas.

La Flexibilidad. La amplitud en los parámetros que delimitan las normas, permitirá que las desviaciones sean menos frecuentes. Si usted se preocupa por la optimización, entonces la probabilidad de desviarse de las normas será más alta. Ejemplo:

El cambio de turno ser llevará a cabo a las 06:00 A.M.El cambio de turno se realizará entre las 05:45 y las 6:30 A.M.El Bioware. Al diseñar su sistema de Seguridad no olvide que integrará Bioware (seres humanos y otros organismos biológicos), y que estos la agregarán cierta imprevisibilidad que influirá en el desempeño final.

Mantenimiento. Importantísima consideración debe hacerse respecto de los medios y procesos necesarios para el cuidado y manipulación de cada componente del sistema de Seguridad; con especial atención en el bioware y su capacitación. Ejemplos:

Debemos prever periodos de descanso, alimentación y satisfacción de otras necesidades fisiológicas, para el personal de seguridad.

Deben especificarse previsiones para dar mantenimiento preventivo a todas las partes mecánicas del CCTV.

8

b. Creación de Escenarios de Comportamiento

Un escenario de Comportamiento es un conjunto de secuencias hipotéticas de eventos a las cuales el sistema propuesto se verá expuesto. Los escenarios pueden ser descripciones estadísticas del comportamiento histórico o pueden estar basadas en modelos mentales de comportamientos futuros. Los escenarios de comportamiento facilitan la descripción y discusión sobre el desempeño de los sistemas y es fácil transportar las observaciones al diseño del sistema.

Se recomienda construir escenarios, para cada componente del sistema, desde los primeros pasos de su diseño. Siempre que sea posible deben probarse nuevos escenarios, incluso aquellos que parezcan absurdos.

c. Definición de la arquitectura del sistema

Otro aspecto importante de la modelación del sistema de seguridad es su Arquitectura, esta consiste de aspectos tales como:

El método que se empleará para el Análisis: Subsistemas especializados por tipo de instalación, División Funcional de la estructura( Brigadas de Vigilancia, Brigadas de Reacción), etc. Los aspectos que se considerarán como prioritarios en el Diseño del Sistema: Altos Requerimientos Estéticos (Que las cámaras y el cableado del CCTV no se noten), Ergonomía (Que los aparatos de radiocomunicación del personal de seguridad, no interfieran en su labor), etc. La manera en que se ejercerá el control sobre el sistema: Control Centralizado (todo desplazamiento del personal de seguridad debe ser autorizado por el responsable de turno), Inteligencia Distribuida (El personal de seguridad está autorizado a desplazarse en un radio de 50 mts, en el cumplimiento de su función), etc. El destino final del sistema: Para uso exclusivo, para ser estandarizado y comercializado, etc. Estos aspectos ejercerán una influencia determinante en el diseño y desarrollo del sistema de seguridad.

9

d. Descomposición Funcional

La descomposición funcional es la reducción de la Misión del sistema a funciones específicas que puedan ser desempeñadas por algún componente de hardware, software o bioware o por un conjunto integrado de estos.

En el caso de sistemas nuevos, la descomposición funcional debe:

(1) Enlazar funciones con componentes físicos, para asegurar que cada función esté v relacionada con un elemento ejecutor.

(2) Enlazar funciones con los requerimientos del sistema.(3) Enlistar las tareas necesarias, verificar la lista y que no exista redundancia ni

carencia.

En el caso de sistemas existentes, el propósito es mejorar su desempeño; en este caso suele denominarse ingeniería de valor; La descomposición funcional se guiará por el desempeño supuesto del sistema., debiendo entonces:

(1) Describir el Estado Actual de cada función del Sistema.(2) Describir el Estado Deseado de cada función del Sistema.(3) Sugerir las modificaciones que harán viables el estado deseado.

A la realización de cambios radicales y dramáticos en un sistema se le denomina Reingeniería. A la realización de pequeños cambios incrementales se le denomina Administración de la Calidad Total.La descripción de las funciones que un sistema debe ejecutar es sólo una parte de la descripción de un sistema; los objetos y su estado (circunstancias) deben ser también descriptos.

e. Análisis de Sensitividad

Un análisis de sensitividad consiste en realizar modificaciones a cada parámetro o requerimiento y observar y documentar los efectos resultantes. El Análisis de Sensitividad puede ser usado para detectar los requerimientos y parámetros que tienen los efectos más grandes sobre los costos, sobre el tiempo y sobre el desempeño. La detección de estos efectos puede utilizarse como directriz para la asignación de recursos.

f. Evaluación y Administración de Riesgos

En el proceso del desarrollo del sistema pueden ocurrir fallas, es posible identificar dos tipos de ellas:

Que hacen fracasar el Proyecto:

Costos excesivos o cálculo erróneo, desfazamiento del tiempo programado o errores en el cumplimiento de las especificaciones de desempeño.Que producen Daño a los Valores:Normalmente asociado con la seguridad de las personas, de las instalaciones y del equipo.

Algunas recomendaciones para reducir la ocurrencia de fallas son:

Supervisión estricta de las especificaciones de desempeño, Obtención oportuna de los insumos y suministros,

10

Desarrollo de hipótesis y modelos de Daño, Desarrollo de procedimientos de Seguridad, (Preventivos y Reactivos), Capacitación del personal y Supervisión exhaustiva.

Es indispensable especificar y analizar Hipótesis de falla del proceso de desarrollo del Sistema, considerando tanto la probabilidad de que cada falla ocurra como la severidad del daño, en caso de que la falla se presentara.

INTEGRACIÓN DE COMPONENTES DEL SISTEMA

Integración significa conjuntar e interrelacionar los componentes del sistema (Hardware, Software, Bioware, Orgware) para hacerlos funcionar como un todo. La Integración del sistema significa, además, asegurarse de que los componentes interactúan como está previsto, que producen los resultados deseados y que los resultados satisfacen los requerimientos de los clientes.

Las tareas previas a la Integración, que podrían ser llamadas de Análisis y Diseño, nos han permitido separar las funciones que integran el proceso que dará Seguridad a los Valores definidos por los Clientes del Sistema de seguridad; También nos permitieron identificar y seleccionar los componentes que son capaces de desempeñar las funciones especificadas, dentro de parámetros que se desprenden de los requerimientos de los clientes.

De cada componente se desprenden requerimientos operacionales y administrativos que deberán ser comprendidos por los Usuarios del Sistema de seguridad, (Funcionarios y Beneficiarios). Esos requerimientos operacionales y administrativos dan origen a Programas de Capacitación, Información al Usuario, Manuales de Operación, Instalación y Mantenimiento, Manuales de Métodos y Procedimientos y todas aquellas herramientas que nos permitan asegurar que el Humanware (Beneficiarios y Funcionarios) podrá interactuar eficientemente dentro del sistema. Como parte del proceso de integración debemos comprender el desarrollo de cursos, manuales, prácticas con prototipos y simulacros.

11

Diseño y Administración de las Interfaces

Fundamental en el desarrollo de un sistema de Seguridad son las Relaciones o Interfaces. Recordemos que cualquier componente puede ser a su vez un subsistema y mantener relaciones con otros componentes; tampoco olvidemos que nuestro sistema es una abstracción en el Universo, por lo tanto estará relacionado con el medio ambiente circundante. Es indispensable reconocer los límites y relaciones existentes entre componentes de nuestro sistema de seguridad y los sistemas del Ambiente (Sistema Nacional de Seguridad, Sistema Nacional de Protección Civil, Sistema de Nómina de la Empresa, Sistema de Control de Inventarios de la Empresa, etc.).

Las interfaces internas de nuestro sistema y las que mantendrá con el mundo exterior deben ser cuidadosamente consideradas y documentadas, pues cualquier modificación a los componentes interrelacionados afectara los resultados de nuestro Sistema de Seguridad. Ejemplo:

Un cambio en el Sistema Nacional de Seguridad, que obligue a los individuos que prestan servicios de Seguridad Privada a Certificarse Oficialmente, podría acarrear drásticos cambios en las relaciones con las Empresas proveedoras de estos servicios, e impactar profundamente el desempeño de nuestro Sistema de Seguridad. Cada componente o subsistema intercambia algún tipo de producto o insumo, este intercambio puede ser de Materiales, Servicios y/o Información, y se realiza a través de las Interfaces. Ejemplos:

El Departamento de Ventas elabora una relación de los clientes que han concertado citas para el día siguiente, esta relación es enviada al Departamento de Seguridad al final del Día. Finanzas elabora una relación de los proveedores que podrán tener acceso al área de Caja al día siguiente, esta relación es enviada al Departamento de Seguridad al final del Día. Debemos, al diseñar los enlaces, considerar la retroalimentación, es decir las maneras en que los subsistemas intercambiarán información respecto de los resultados del desempeño de sus enlaces.

12

Ejemplo:

El Departamento de Seguridad regresa, al final del Día, al Departamento de Ventas la Relación de Citas de Clientes, en la cuál se ha subrayado el nombre de cada uno de los clientes que acudieron a su cita y se anexan aquellos clientes que sin cita fueron autorizados a ingresar a las instalaciones, previa autorización del Gerente de Ventas. El flujo de información en las interfaces es útil para detectar Redundancia o pobreza en el desempeño, o bien una función deficientemente fragmentada. Los cuellos de botella de información, a través de una interfase, suelen indicar que una función no ha sido fragmentada suficientemente.

LIBERACIÓN DEL SISTEMA

Al diseñar un sistema de seguridad, los requerimientos de protección de los clientes son transformados en el diseño de los procesos que mantendrán los valores, especificados por el cliente, a salvo de las amenazas previstas; durante la integración del sistema, los elementos, funciones y relaciones son probados, primero individualmente y luego en conjunto, verificando que el proceso genere la seguridad que satisface al cliente.

Liberar un sistema significa lograr que el sistema satisfaga, continuamente, las expectativas planteadas: que los insumos, los procesos, las funciones, las interfaces y los productos se comporten de acuerdo a lo previsto y satisfagan los requerimientos del cliente.

Administración del Cambio.

Esta tarea permite asegurar que cualquier modificación en los requerimientos, en el diseño o en la integración sea cuidadosamente identificada, registrado con precisión y controlada.Al tomar decisiones sobre el sistema de seguridad se debe tener la oportunidad de racionalizar respecto de las modificaciones y sus efectos. La Decisión de efectuar un cambio se debe registrar incluyendo las circunstancias prevalecientes en el momento de la decisión. Es indispensable notificar, respecto de cualquier cambio en el sistema, a todos los usuarios y clientes involucrados, pues los efectos de cualquier cambio se transmiten a través de las interfaces y se extienden, frecuentemente, más allá de nuestro sistema.

Las modificaciones que se realizan sin registrase o sin comunicarse, son, generalmente, las responsables de la mayoría de las fallas y conflictos durante la operación del sistema.

Conforme sea más complejo, el sistema de seguridad deberá integrar dentro de sus funciones el mantenimiento de una Bitácora de Modificaciones, que permita, con facilidad,

13

realizar un Rastreo de Requerimientos. Es posible que una modificación no nos permita advertir efectos futuros o lejanos, por tanto es indispensable conocer el qué, el porqué, el quién y el cuándo de tales decisiones, para poder revertir sus efectos adversos.

Administración del Proyecto

Ya sea que se trate de un nuevo Sistema de Seguridad o de la Reingeniería de uno existente, el proyecto consumirá, tiempo, recursos humanos, recurso financieros que deberán ser administrados. La Administración del Proyecto de Desarrollo del Sistema de Seguridad consistirá en planificar, organizar, dirigir y controlar los recursos destinados a analizar, diseñar, integrar y liberar el conjunto de soluciones que satisfagan lo demandado por los clientes del sistema, dentro de un tiempo determinado, dentro de un rango de costos y con un nivel de desempeño predefinido. Entre las subtareas comprendidas en la Administración del Proyecto de Desarrollo del Sistema están:

Desarrollar la división del trabajo, partiendo del árbol del Análisis Funcional, asociando los recursos materiales y humanos adecuados a la especialización requerida por cada función, sin perder de vista los requerimientos del cliente. Definir los procesos que han de ser diseñados y desarrollados, interrelacionando medios y funciones, y orientado su funcionamiento hacia la satisfacción de las necesidades de protección especificadas en los requerimientos de usuarios y funcionarios.. Diseñar la estructura jerárquica que permita distribuir las misiones entre los equipos de trabajo, así como el presupuesto de desarrollo; estructura que, además, deberá propiciar una adecuada supervisión y control.. Estas tareas apuntan, como en cualquier otro caso al desarrollo y seguimiento de programas de trabajo, así como al adecuado ejercicio y control del presupuesto.

Documentación del Proyecto.

Recuerde la frase: “Si no está por escrito, no sucedió”; todas y cada una de las actividades del proyecto de desarrollo del Sistema deben ser documentadas. El medio documental debe ser suficientemente independiente, debe permitir un fácil registro, una rápida localización y una clara consulta de la información, así como un eficiente control de acceso a la información y procedimientos de respaldo.Las Inferencias que en razón de las hipótesis de daño se hagan, los resultados de los intercambios y negociaciones entre los requerimientos, así como los fundamentos de las decisiones críticas deben ser registrados.

Este documento debe mantenerse en proceso de continuo desarrollo. Su utilidad es evidente durante todo el ciclo de vida del sistema; incluso al final del ciclo de vida podría ayudarnos a describir y localizar el modelo más exacto del sistema requerido, que remplazase al sistema actual en su fase de jubilación.

Liderazgo de Equipos de Trabajo.

Los Sistemas complejos no pueden ser desarrollados por una única persona. Por consiguiente suele distribuirse el desarrollo de los subsistemas entre Equipos Integrados de Desarrollo. Estos son equipos multidisciplinarios con especialistas en Negocios, Ingeniería, Manufactura, etc.

Tratándose de Sistemas de Seguridad, la participación o representatividad de los beneficiarios y funcionarios del sistema es indispensable, pues permitirá establecer

14

compromisos sólidos.

Dichos equipos son frecuentemente encabezados por Líderes de Proyecto: individuos experimentados en el desarrollo de Sistemas, a veces con conocimientos formales, otras informales.

EVALUACIÓN DEL DESEMPEÑO.

Una vez que el sistema ha sido liberado, iniciará la fase de operación y mantenimiento de su ciclo de vida; A partir de este evento, el rendimiento del sistema debe ser medido, constantemente.Inicialmente estas mediciones se usarán para verificar que el sistema opera conforme a sus requerimientos. Más tarde se usarán para descubrir el comienzo de procesos de deterioro y arrancar proyectos de mantenimiento o remplazo.

Prescripción de Pruebas

Desde el diseño del sistema, deben preverse las pruebas que serán aplicadas continuamente, para demostrar que el sistema satisface los requerimientos del cliente.

Una buena alternativa es integrar dentro de la operación normal del sistema, procedimientos y dispositivos de autoverificación. Estas autoverificaciones deben ser aplicadas a partir de la fase de liberación, durante la comprobación de la implantación, en los diagnósticos diarios de inicio y fin de operaciones y durante los procedimientos de mantenimiento. Una manera sencilla de aplicar estas autoverificaciones, es el diseño y llenado de Listas de Verificación (Check List), al inicio y fin de las operaciones diarias o por turno. Las listas de verificación deberán incluir, por lo menos, los aspectos críticos del Sistema de Seguridad.El responsable del sistema de seguridad, al recibir los resultados de cada prueba y, cuando proceda, al determinar acciones correctivas, debe documentar las evaluaciones, las correcciones sugeridas, los efectos esperados y los efectos producidos.

Conducción de Revisiones

El responsable del Sistema debe tener la certeza de que se han conducido y documentado apropiadamente, todas las pruebas pertinentes; La extensión y profundidad de las revisiones dependen del tamaño, complejidad y del cliente del proyecto.

El siguiente conjunto de revisiones es el más comúnmente aplicado:Revisión del Concepto de la Misión General de Seguridad. Revisión de los Requerimientos del Sistema de Seguridad. Revisión del Modelo Preliminar del Sistema de Seguridad. Revisión de la Viabilidad del Desarrollo. Prueba General del Sistema de Seguridad.

Cada una de estas revisiones define momentos críticos en el avance del proyecto. Cada tarea en el proyecto comienza y termina con una revisión. La fase de producción del ciclo de vida del sistema, no iniciará sin antes realizar la Prueba General del Sistema y liberarlo.Para asegurar que el sistema ha sido exitosamente integrado y realizar una liberación libre de errores, es necesario:

Certificar, documentando la aprobación del Usuario, que satisface los requerimientos obligatorios, y

15

Verificar la proporción en que son satisfechos los requerimientos preferenciales, documentando los resultados y registrando la anuencia de los usuarios.

Ocasionalmente, cuando todo parece funcionar bien, se puede sentir la tentación de considerar innecesaria la Prueba General del Sistema, sin embargo, considérela indispensable. Los costos asociados a las correcciones son generalmente muy altos y los retrasos que se sufren terminan por parecer interminables.

RE-EVALUACIÓN Y MEJORAMIENTO DE LA CALIDAD.

Esta tarea suele considerarse como separada del resto, incluso suele llamársele Mejoramiento de la Calidad; sin embargo, recordemos que hemos sugerido integrar procedimientos o dispositivos de autoevaluación que constantemente generen información respecto del desempeño de cada componente y permitan realizar las correcciones pertinentes. Realizar grandes evaluaciones o complejas auditorías periódicas, puede resultar en acciones tardías, no obstante es imposible negar que este tipo de evaluaciones son útiles. Lo recomendable es integrar dentro de cada componente o función elemental, dispositivos de evaluación continua que generen una oportuna retroalimentación.

La retroalimentación es una de las herramientas fundamentales del desarrollo de sistemas, significa observar los desempeños y usar la información derivada de las observaciones para corregir las desviaciones en el producto o en el proceso.

La Reevaluación debe ser un proceso incesante, todo el mundo debe continuamente reevaluar su desempeño en el sistema en busca de maneras de mejorarlo.

16