Desarrollo de un concepto de operaciones



Documentos relacionados
CMMI (Capability Maturity Model Integrated)

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M

CAPÍTULO 4. FORMA DE EVALUACIÓN CMM. 4.1 Evolución de los métodos de valoración del SEI

0. Introducción Antecedentes

Master en Gestion de la Calidad

AUDITORÍAS Y AUDITORES ISO 9000:2000

-OPS/CEPIS/01.61(AIRE) Original: español Página Estructura del programa de evaluación con personal externo

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

Elementos requeridos para crearlos (ejemplo: el compilador)

Nombre del Documento: Manual de Gestión de la Calidad. Referencia a punto de la norma ISO 9001:2000: DIRECCIÓN GENERAL DE EVALUACIÓN

Proceso: AI2 Adquirir y mantener software aplicativo

Directrices para la auto- evaluación A.l Introducción

Figure 7-1: Phase A: Architecture Vision

Planeación del Proyecto de Software:

Sistemas de Gestión de Calidad. Control documental

Hoja Informativa ISO 9001 Comprendiendo los cambios

Una estructura conceptual para medir la efectividad de la administración

Charlas para la Gestión del Mantenimiento Fernando Espinosa Fuentes

Metodología básica de gestión de proyectos. Octubre de 2003

Sistema de auto-evaluación para la sostenibilidad

I. Información General del Procedimiento

HOJAS DE INFORMACIÓN COMPLEMENTARIA DE TRABAJO DE MONITOREO Y EVALUACIÓN

LINEAMIENTOS DE RENDICIÓN DE CUENTAS DE LA CREG

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

Antes de imprimir este documento piense en el medio ambiente!

ISO 9000 Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007

PROPUESTA METODOLOGICA PARA LA EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN

TALLER: CALIFICACIÓN DE EQUIPOS Y SISTEMAS

Gestión de Riesgos en Proyectos

Sistemas de gestión de la calidad Requisitos

Introducción. Enfoque de Control de CobiT Los Procesos del Modelo Mapeo de los Procesos

ISO 9001:2015 Cuestionario de autoevaluación

CURSO COORDINADOR INNOVADOR

ISO 9000:2000. Roberto Aprili Justiniano Rodrigo Ramírez Pérez. Roberto Aprili, Rodrigo Ramírez

COMITÉ TECNICO DE NORMALIZACION DE GESTION Y ASEGURAMIENTO DE LA CALIDAD

CRITERIOS DE ACREDITACIÓN. Programas de Computación Ciclo de Evaluaciones

FACULTAD DE CONTADURIA Y CIENCIAS ADMINISTRATIVAS FINANZAS I NORMAS DE INFORMACION FINANCIERA

cumple y hay evidencias objetivas

"Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

CUESTIONARIO AUDITORIAS ISO

ARQUITECTURA TÉCNICA ASIGNATURA: MATERIALES DE CONSTRUCCIÓN II CURSO: APUNTES TEMA 1: CONTROL DE CALIDAD

//

UN RECORRIDO POR LA FAMILIA ISO

Orientación acerca del enfoque basado en procesos para los sistemas de gestión de la calidad

Serie Casos de Estudio: Edición El Impacto del Desarrollo de Capacidades en la GIRH en América Latina:

2. DEFINICIÓN DEL SISTEMA INTEGRADO DE GESTIÓN - SIG

COMPILACION BIBLIOGRAFICA PMBOK, OPM3 JHON FREDY GIRALDO. Docente: Carlos Hernán Gomez Asignatura: Auditoria de Sistemas

Traducción del. Our ref:

Modelo de Proceso de Desarrollo de Software

El impacto del relevamiento y modelado de procesos en la implantación de sistemas informáticos

GLOSARIO DE TERMINOLOGIA SOBRE SISTEMAS DE GESTIÓN DE LA CALIDAD

POLÍTICA DE CONTINUIDAD DEL NEGOCIO (BCP,DRP)

Sistema de Gestión de Proyectos Estratégicos.

CONFEDERACIÓN INTERNACIONAL DE MATRONAS Herramienta para evaluar la capacidad de una asociación miembro (MACAT) (por sus siglas en inglés)

GUIA PARA TRABAJO PRÁCTICO DIAGNOSTICO ESTRATÉGICO DE UN SISTEMA DE GESTIÓN DE LA CALIDAD

Tecnología de la Información. Administración de Recursos Informáticos

RICARDO REYES TAVARA. Avance de los Cambios de la Norma ISO 9001:2015 Apuntes de clase : Fuente LRQA

GUÍA PARA LAS FAMILIAS

Norma ISO Francisco D Angelo Douglas García Claudia Herrera Luis Laviosa

Taller: Planificación Estratégica. Centro de Iniciativas Comunitarias y Base de Fe

Esri Partner Network. Preguntas Fecuentes Julio de Programa para Partners que desarrollan soluciones y servicios GIS sobre la plataforma Esri

PREPARADO POR: FECHA DE EMISIÓN: FECHA DE VALIDACIÓN:

Bechtle Solutions Servicios Profesionales

CUESTIONARIO AUDITORIAS ISO

IAP TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)

PROCEDIMIENTO DE AUDITORIAS INTERNAS. CALIDAD INSTITUCIONAL Versión: 02

PROCEDIMIENTO ELABORACIÓN DE DOCUMENTOS

ISO 9001:2015 Comprender los cambios clave. Lorri Hunt

CAPITULO VI PLAN DE IMPLEMENTACIÓN DEL SISTEMA DE PRESUPUESTOS DE COSTOS DE TIEMPOS ESTÁNDARES DE CONFECCIÓN DE PRENDAS DE VESTIR DE TEJIDO DE PUNTO.

ISO 14001:2015 ISO 14001:2004 GUÍA. 0. Introducción 0. Introducción

Unidad VI: Supervisión y Revisión del proyecto

GUÍA PARA LAS FAMILIAS To Para Obtener Asistencia Financiera

Ministerio de Educación, Cultura y Deporte. Joomla! La web en entornos educativos. Guía del alumnado

ENFOQUE ISO 9000:2000

Marco Normativo de IT

ADMINISTRACIÓN DE PROYECTOS

Usos de los Mapas Conceptuales en Educación

Informe final de evaluación del seguimiento de la implantación de títulos oficiales

Procedimiento de Sistemas de Información

ITIL FOUNDATION V3 2011

EMPRESAS PÚBLICAS DE MEDELLÍN E.S.P. DIRECCIÓN CONTROL INTERNO PROYECTO NORMALIZACIÓN ACTIVIDAD DE AUDITORÍA INTERNA

I INTRODUCCIÓN. 1.1 Objetivos

Términos definiciones

Conceptos Básicos. El Instituto de administración de Proyectos, PMI, define un proyecto como:

NORMA INTERNACIONAL DE AUDITORÍA 501

NOMBRE DEL DOCUMENTO: PROCEDIMIENTO PARA AUDITORÍA INTERNA. Referencia a la Norma ISO 9001: Página 1 de 7

BOLETIN INFORMATVO PROTOCOLO DE SEGURIDAD IMPLEMENTADO POR SEGURIDAD DOSSI Y CIA LTDA

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.

Inicio Catálogo Noticias Innovaciones Mis datos Galería

Basado en la ISO 27001:2013. Seguridad de la Información

C O N T E N I D O. 1. Propósito. 2. Alcance. 3. Responsabilidad y autoridad. 4. Normatividad aplicable. 5. Políticas

Servicios de instalación y puesta en marcha de HP para HP Insight Control

5. Anexo: declaración del nivel de aplicación G3

SISTEMA INTEGRADO DE GESTION DE CALIDAD Y CONTROL INTERNO ALCALDIA MUNICIPAL DE SABANAGRANDE

LICENCIA PLATAFORMA ERM

Programa de Certificación en Dirección de Proyectos (7 Días) El Enfoque Kerzner para la Excelencia en la Dirección de Proyectos

NEXTPLAYS INSPIRED SOCIAL INNOVATION

Transcripción:

Capítulo 9 Desarrollo de un concepto de operaciones Qué contiene este capítulo? En este último capítulo, exploramos el desarrollo de un Concepto de Operaciones (ConOps) para un sistema de alerta temprana (SAT) de crecida repentina. Los SAT de crecidas repentinas son sistemas complejos y por eso este capítulo explica el propósito de un ConOps dentro del contexto del proceso del ciclo de vida de ingeniería de sistemas. Luego enumera los elementos principales de cualquier ConOps de un SAT de crecida repentina. Concluye con una orientación general para evitar errores comunes en el desarrollo de un ConOps y una lista de verificación que enlaza cada uno de los capítulos anteriores con el proceso de desarrollar un ConOps de SAT de crecida repentina. Por qué necesita el SMHN un ConOps de SAT de crecida repentina? Como se indicó anteriormente en esta Guía, los SAT contemporáneos son sistemas complejos y dinámicos. De hecho, la siguiente figura, presentada antes en el capítulo introductorio, muestra Sistema de Alerta Temprana de Crecidas Repentinas Información de riesgos (ver Capítulo 7) Evaluaciones de riesgo Bases de datos de amenazas Estadísticas de amenazas Herramientas de análisis Ciencia e investigación (ver Capítulo 2) Información de riesgos en alertas Datos de amenazas y pronósticos Redes de monitoreo (ver Capítulo 3) Detección y análisis Infraestructura informática (ver Capítulo 4) Predicción de crecidas repentinas (ver Capítulo 5) Emisión de alertas Comunicación y divulgación (ver Capítulo 6) Divulgación de alertas oportunas Redes de voz y datos para personal de primera respuesta Medios de comunicación Alarmas y sirenas RUTA DE EVACUACIÓN Preparación y respuesta (ver Capítulo 7) Planificación para emergencias a nivel comunitario Educación y extensión Capacitación y ejercicios de preparación Seguro de inundación Estabilización y refuerzo de suelos Reconstrucción y reasentamiento Retroalimentación del sistema Figura 9.1 Componentes de un SAT de crecida repentina The The COMET COMET Program Program Guía de referencia para sistemas de alerta temprana de crecidas repentinas 9-1

que usualmente son un sistema de sistemas que integra un gran número de interesados e infraestructura, de maneras bastante sofisticadas. Al invertir en el desarrollo de un ConOps, un SMHN puede maximizar la probabilidad de que los diferentes subsistemas SAT funcionen como un SAT integrado y efectivo, aún si existen muchos interesados responsables de los diferentes subsistemas. Recuerde Una inversión adecuada en el desarrollo y mantenimiento de un ConOps es una de las estrategias más efectivas para cualquier grupo que esté contemplando la implementación de operaciones de SAT de crecida repentina. El diseño de un SAT es un proceso iterativo que requiere comprender el proceso del ciclo de vida de ingeniería de sistemas (ver Figura 9.2 abajo). El primer paso de ese proceso es el desarrollo del ConOps. El desarrollo de un ConOps no sólo facilita el resto del proceso de ingeniería de sistemas, sino que también aporta un método para validar el éxito de ese esfuerzo una vez que el sistema está operativo.1 El riesgo de fracaso técnico, político y económico es mucho más bajo con un ConOps bien desarrollado, que si un SMHN intenta implementar un SAT de crecida repentina sin invertir en conceptualizar las operaciones de ese sistema. Concepto de Operaciones Evaluación Operaciones y mantenimiento Requisitos de alto nivel Requisitos detallados Verificación del sistema Definición y desglose Diseño de alto nivel Diseño detallado Verificación de subsistemas Integración y pruebas Integración, verificación y validación Implementación Tiempo The COMET Program Figura 9.2 Proceso del ciclo de vida de ingeniería de sistemas 1 Existen varias guías reconocidas para el desarrollo de un concepto de operaciones que sirven de referencia útil desde la perspectiva de la tecnología: (a) DI-IPSC-81430 Operational Concept Description, December 1994 [MIL-STD-498], (b) ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents, January 1993 y (c) IEEE Std 1362-1998 Guide for Information Technology System Definition Concept de Operations Document. 9-2 Guía de referencia para sistemas de alerta temprana de crecidas repentinas

Un estudio realizado en 2005 por el Gobierno de Estados Unidos identificó al menos tres beneficios para tener un ConOps bien preparado. Éstos son: 1. Consenso entre los interesados asegurar que cada socio entienda y apoye el sistema propuesto 2. Reducción de riesgos forzar el proceso algunas veces doloroso pero siempre beneficioso de predeterminar cada aspecto del sistema antes de que sea adquirido o implementado 3. Mejora de calidad descubrir cada oportunidad para apalancar la infraestructura existente y nueva para mejorar el desempeño del sistema. 2 Proceso del ciclo de vida de ingeniería de sistemas 3 Un ConOps efectivo debe considerar a todos los interesados de un sistema propuesto o en operación, sin importar cuál sea su rol o interés. Además, un ConOps efectivo debe ser tan legible y relevante para los tomadores de decisiones de los niveles superiores como lo es para los operadores del sistema. El desarrollo del ConOps es el primer paso en el proceso del ciclo de vida de ingeniería de sistemas, que involucra un total de ocho pasos básicos: Paso 1 Concepto de Operaciones Esta es la manera en que se va a utilizar el sistema. Paso 2 Requisitos La definición general y específica de lo que va a hacer el sistema. Paso 3 Diseño La definición general y específica de cómo el sistema va a llenar los requisitos. Paso 4 Implementación La construcción y despliegue de los componentes del sistema. Paso 5 Integración y pruebas Conforme se completa cada componente del sistema, éste se integra dentro del sistema total y se prueba para asegurar que las especificaciones se hayan cumplido. Paso 6 Verificación del sistema También llamado prueba de aceptación, este paso asegura que el sistema completo sea consistente con el diseño y que cumpla con los requisitos. Paso 7 Operaciones y mantenimiento Esta etapa representa el proceso continuo de usar el sistema de la forma en que fue diseñado (y validar que pueda ser usado de esta manera) y el mantenimiento del sistema. Paso 8 Evaluación Verificación regular de que el ConOps refleja el método óptimo para las operaciones y que las operaciones respetan el método prescrito por el ConOps. 2 U.S. Department of Transportation, Federal Highways Administration, Developing and Using a Concept of Operations in Transportation Management Systems (FHWA-HOP-07-001), August 2005. 3 Adaptado de Dept of Transportation, ITS Standards for System Engineering Process (http://www.standards.its.dot.gov/ learn_syseng.asp) Guía de referencia para sistemas de alerta temprana de crecidas repentinas 9-3

La Figura 9.2 ilustra que el desarrollo del ConOps puede ser el primer paso en la ingeniería de sistemas, pero aún después de la implementación del sistema, es necesario mantener ese ConOps durante toda la vida del sistema. La ingeniería de sistemas es un método continuo, orientado hacia el proceso para implementar y luego operar sistemas complejos (como un SAT de crecida repentina) de tal manera que (1) reduzca el riesgo, (2) controle el costo y el cronograma, (3) mejore la calidad, y (4) llene las necesidades de los usuarios. El ConOps de un sistema determina el éxito de cada aspecto de ese proceso. Qué es un ConOps? Aunque existe una amplia gama de interpretaciones del término Concepto de Operaciones, la siguiente definición es especialmente relevante para organizaciones que están planeando implementar un SAT de crecida repentina: Un Concepto de Operaciones (ConOps) describe la operación probable de un sistema futuro o existente en la terminología de sus usuarios, proporcionando información importante para la adquisición y/o desarrollo de ese sistema. Puede incluir la identificación y discusión de lo siguiente: 1. Por qué es necesario el sistema y una descripción del sistema mismo; 2. El ciclo de vida completo del sistema, desde su lanzamiento hasta su desactivación; 3. Diferentes aspectos de uso del sistema, incluyendo operaciones, mantenimiento, soporte y desactivación; 4. Las diferentes clases de usuarios, incluidos los operadores, encargados de mantenimiento, proveedores de soporte y sus diferentes destrezas y limitaciones; 5. Los ambientes en los cuales se usa y se soporta el sistema; 6. Los límites del sistema y sus interfaces y relaciones con otros sistemas y sus ambientes; 7. Cuándo se usará el sistema y bajo qué circunstancias; 8. Cómo y qué tan bien se están llenando las capacidades necesarias (usualmente por los sistemas existentes); 9. Cómo se utilizará el sistema, incluyendo operaciones, mantenimiento y soporte; y 10. Escenarios que ilustran actividades operativas específicas relacionadas con el uso del sistema. 4 En resumen, el ConOps de un SAT de crecida repentina debe ser un documento legible, integral y de orientación que permita a todos los interesados tanto estratégicos como operativos entender el quién, cuándo, qué, dónde, por qué y cómo del SAT. 4 Andrew P Gabb, Operational Concepts - Some Variations, from the Proceedings of the Systems Engineering, Test & Evaluation Conference, Sydney, Australia, October 30, 2002 9-4 Guía de referencia para sistemas de alerta temprana de crecidas repentinas

Cómo Qué recursos son necesarios para diseñar y construir el sistema? Quién Quiénes son los interesados involucrados con el sistema? Dónde Cuáles son las ubicaciones geográficas y físicas del sistema? Concepto de operaciones Por qué Qué necesita la organización que el sistema le proporcionará? Cuándo Cuál es la secuencia de tiempo de las actividades que se llevarán a cabo? Qué Cuáles son los elementos conocidos y las capacidades de alto nivel del sistema? Figura 9.3 Preguntas que dirigen el desarrollo de un ConOps The COMET Program Elementos del concepto de operaciones de un SAT de crecida repentina El American National Standards Institute (ANSI) publicó una norma para el Concepto de Operaciones (ANSI/AIAA G-043-1992) que ofrece una descripción útil de los elementos que permiten a un Concepto de Operaciones describir cualquier característica de un sistema desde la perspectiva operativa y contestar la pregunta cómo se ve el sistema? desde el punto de vista de cada interesado. La Figura 9.3 resume las preguntas principales que cualquier ConOps debe contestar. Dentro del contexto de un SAT típico de crecida repentina, las preguntas quién, cuándo, dónde, por qué, qué y cómo se pueden contestar asegurando que su ConOps trate los siguientes temas: Alcance esto establece: 4 La visión para el sistema 4 Un resumen de los contenidos del documento 4 El propósito de implementar el sistema 4 La audiencia / los beneficiarios meta 4 Las limitaciones del contenido cubierto Guía de referencia para sistemas de alerta temprana de crecidas repentinas 9-5

Referencias de conocimiento describe los expertos y los métodos consultados por medio de: 4 Discusiones con interesados, académicos y otros expertos 4 Estudios de sistemas de otros países alrededor del mundo 4 Análisis de los requisitos de misión y de las necesidades operativas 4 Recomendaciones ofrecidas por los proveedores y los manuales de productos Descripción operativa describe el sistema desde la perspectiva de los usuarios e incluye: 4 Resumen del rol y las actividades de cada usuario 4 Aclaración del orden de operaciones de los usuarios 4 Resumen de los procedimientos del proceso operativo 4 Descripción y flujogramas asociados con las estructuras de tomas de decisiones y gestión de la organización Descripción del sistema esta es una descripción de alto nivel de los requisitos de misión y las interrelaciones de los componentes clave del sistema y establece: 4 Metas y objetivos específicos mesurables y específicos en el tiempo 4 Interdependencias entre subsistemas 4 Confirmación de que las capacidades del sistema cumplirán con su misión Ambientes operativos y de soporte describe la infraestructura asociada con los siguientes aspectos de cada subsistema: 4 Instalaciones 4 Equipo 4 Hardware 4 Software 4 Personal 4 Procedimientos operativos 4 Requisitos de mantenimiento, capacitación y soporte Recuerde No hay atajos y no realizar todo el proceso de desarrollo del ConOps al final derrotaría su propósito. Escenarios operativos describe el sistema en acción usando uno o más escenarios representativos de crecida repentina para reflejar: 4 Una gama de perspectivas de los interesados 4 Una gama de escenarios de estrés/fracaso 4 Circunstancias tanto típicas como extremas 9-6 Guía de referencia para sistemas de alerta temprana de crecidas repentinas

Obviamente existen muchas maneras diferentes de escribir un ConOps y la forma en que usted organice su ConOps debe reflejar la audiencia única que debe servir. Cada SMHN debe considerar los requisitos de sus interesados y luego identificar la manera más efectiva de tratar los temas arriba citados en el ConOps del SAT de crecida repentina. El desarrollo del ConOps no sólo toma tiempo, experticia y dinero, sino que también requiere liderazgo para asegurar que cada interesado tenga una voz en definir el éxito una vez que el sistema esté operativo. Es precisamente ese difícil proceso de realizar consultas extensas con los interesados e investigación técnica y luego conceptualizar un único sistema a partir de una serie de subsistemas, que hace tan crítico al ConOps. Errores comunes que se deben evitar cuando se desarrolla un ConOps Existen varios errores que cometen las organizaciones que no tienen experiencia o no están totalmente comprometidas con el proceso de desarrollar un ConOps. Éstos incluyen: 1. Esperar que los proveedores, contratistas u otros socios externos del sistema les desarrollen su ConOps como parte de los otros entregables. Para que sea relevante y para asegurar que se apropie profundamente del sistema, un SMHN debe asegurar que el personal estratégico y operativo del sistema sea responsable del desarrollo de su ConOps. 2. Posponer el desarrollo del ConOps hasta después de que el sistema haya sido diseñado y entregado. Un ConOps es un documento viviente que debe ser escrito antes de finalizar el diseño del sistema y luego debe ser actualizado continuamente conforme cambian las necesidades del sistema. 3. Asignar recursos insuficientes de personal (tiempo y dinero) para el desarrollo del ConOps. El proceso de conceptualizar la operación de un SAT de crecida repentina es complejo, tedioso y consume tiempo. Además requiere misiones de investigación para conocer las prácticas actuales en el desarrollo de ConOps de otros programas de SAT líderes a nivel regional e internacional. 4. Asignar personal no calificado para el desarrollo del ConOps. Es inútil crear un equipo de ConOps sin asegurar representación adecuada del personal con experiencia en los programas estratégicos, operativos, técnicos, administrativos, financieros y de comunicaciones. El equipo no sólo necesita conceptualizar las operaciones del SAT, sino también tiene que poder documentar la visión efectivamente en la forma de un ConOps escrito. 5. Cortar y pegar del ConOps de otra organización. Copiar el plan de otra organización para evitar el proceso de deliberar su propio plan podría parecer un atajo eficiente, pero es muy probable que se vuelvan a repetir los errores que otros cometieron. Aún peor, el compromiso de los interesados (especialmente los operadores del sistema) será mucho menor con ese ConOps importado que si se les hubiera dado la oportunidad de contribuir en el desarrollo de su propio ConOps. Guía de referencia para sistemas de alerta temprana de crecidas repentinas 9-7

6. No actualizar el ConOps mientras se implementa el nuevo SAT de crecida repentina y una vez que esté operativo. A menos que su ConOps refleje constantemente el diseño real del sistema, los requisitos de la misión y la visión operativa, se convertirá rápidamente en un documento poco confiable e inútil. Asegúrese de que como parte de su programa operativo, el ConOps se revise y actualice sistemáticamente para asegurar que continúe siendo relevante. Lista de verificación de requisitos para un ConOps de crecida repentina La siguiente lista de verificación no tiene como objetivo ser exhaustiva ni prescriptiva, sino más bien representativa de buenas prácticas en el desarrollo de un ConOps de crecida repentina. Puede imprimirse y utilizarse como punto de partida para desarrollar su ConOps de SAT de crecida repentina. Como mínimo, un ConOps de SAT de crecida repentina debe incluir los siguientes elementos: Documentación c Lista de distribución cada una de las personas que debe recibir una copia del ConOps c Lista de revisiones adenda y versiones revisadas que han sido publicadas desde el lanzamiento de la versión original c Documentación asociada todos los manuales, guías o políticas que apoyan el ConOps c Referencias y fuentes quién y qué se consultó en la preparación del ConOps c Método cómo se desarrolló el ConOps Introducción c Alcance visión, propósito y escala del sistema c Descripción definición simple y comprensible del sistema c Prioridades las prioridades a ser tratadas por el sistema c Método el proceso seguido para desarrollar el ConOps c Contribuyentes nombres y afiliaciones de todas las personas que participaron en el desarrollo del ConOps c Glosario de términos el significado de todos los términos clave utilizados en el ConOps c Lista de Siglas el nombre completo de todos los términos abreviados en el ConOps 9-8 Guía de referencia para sistemas de alerta temprana de crecidas repentinas

Marco estratégico c Declaración de misión articulación clara y sucinta de los entregables finales del sistema c Mandato de política fundamento para que el SMHN entregue los requisitos de la misión c Metas y objetivos específicos, mesurables, alcanzables, realistas y con límites de tiempo c Definición del sistema descripción del sistema en prosa simple y comprensible Marco operativo c Instalaciones identificación de toda la infraestructura existente y nueva requerida para que el sistema sea operativo c Roles y responsabilidades descripción de la contribución de cada operador de subsistema a un nivel operativo c Personal lista de todo el personal requerido para operar el sistema exitosamente, tanto a corto como a largo plazo c Desarrollo de destrezas descripción del régimen de capacitación, ejercicios y simulacros necesarios para asegurar la sostenibilidad del sistema a largo plazo c Comunicaciones descripción de los canales primarios y redundantes a través de los cuales pasará la información entre y más allá de cada subsistema (ver capítulos 3 y 4) c Datos inventario de los requisitos de información de cada subsistema, incluida la necesidad de datos históricos para la calibración del modelo, así como datos en tiempo real para el pronóstico de una crecida repentina (ver Capítulo 3) c Modelos descripción de los modelos hidrometeorológicos utilizados para generar pronósticos de crecida repentina (ver Capítulo 4) c Productos y servicios definición de los diferentes productos generados por el sistema (ver Capítulo 6 y Apéndice E) c Hardware descripción de la infraestructura tecnológica del sistema y los sensores hidrometeorológicos, incluidas las redes de pluviómetros, radares y satélites (ver Capítulo 4) c Software descripción de las aplicaciones y paquetes operativos utilizados por cada subsistema (ver Capítulo 4) c Mantenimiento y remplazo predicción de los requisitos de mantenimiento y longevidad de cada subsistema (ver Capítulo 4) Guía de referencia para sistemas de alerta temprana de crecidas repentinas 9-9

c Investigación y desarrollo provisión del marco para involucrar a los operadores del sistema y a otros socios en el desarrollo de aplicaciones (ver Capítulo 6) c Extensión y educación pública identificación de la estrategia para asegurar participación sólida a nivel comunitario en el éxito del SAT de crecida repentina (ver Capítulo 7) c Escenarios operativos representación de varios escenarios realistas de crecidas repentinas que describen el desempeño del sistema durante condiciones normales y extremas (ver Capítulo 8) Evaluación e indicadores de desempeño c Mediciones del desempeño del sistema general definición del tiempo mínimo de anticipación para la evacuación de poblaciones vulnerables, tasa máxima de falsos positivos /alertas erróneas de crecida repentina, percepción a nivel comunitario de valor y confiabilidad, etc. c Mediciones de desempeño de los subsistemas definición del porcentaje mínimo de tiempo que el subsistema de radares meteorológicos necesita para ser funcional, costos máximos permisibles para el mantenimiento de las redes de pluviómetros, etc. Apéndices c Diagramas del sistema general y los subsistemas c Planes de presupuesto operativo, de mantenimiento y de reemplazo Puntos importantes que recordar acerca del desarrollo de un ConOps 4 El desarrollo de un Concepto de Operaciones (ConOps) es el primer paso en el ciclo de vida de la ingeniería del sistema de alerta temprana de crecidas repentinas. 4 Cada ConOps es un documento único y viviente que requiere insumos de todos los interesados y mantenimiento regular. 4 Un ConOps intenta contestar, en lenguaje relativamente simple, las preguntas quién, qué, cómo, dónde, cuando y por qué del sistema. 4 No trate de tomar atajos en el desarrollo de un ConOps requiere de atención seria y dedicada por parte del personal estratégico y operativo para ser efectivo. Referencias U.S. Department of Transportation, Federal Highways Administration, 2005. Developing and Using a Concept of Operations in Transportation Management Systems (FHWA- HOP-07-001), August 2005, p. 43 9-10 Guía de referencia para sistemas de alerta temprana de crecidas repentinas

Guía de referencia para sistemas de alerta temprana de crecidas repentinas 9-11