CC BY
56
No. 6 (54) 2014
Д. А. Разумов, Российская корпорация средств связи (в составе ГК «Ростехнологии»), г. Москва,
Dmitrirazumov@yandex.ru
В. Д. Алёшин, канд. техн. наук, доцент, профессор Российской академии народного хозяйства и государственной службы при Президенте РФ, г. Москва, aleshin_vladimir@mail.ru
Моделирование в жизненном цикле автоматизированных систем управления в кризисных и чрезвычайных ситуациях
Практика преодоления техногенных катастроф последних лет сформировала требования к проектированию и созданию современных региональных автоматизированных систем управления . В работе предлагаются модели жизненного цикла (ЖЦ) системы правообладателя и поставщика . На основе моделей ЖЦ предлагается формализация задач, для которых целесообразно использовать имитационное моделирование (ИМ) . Фактически речь идет о формализации ЖЦ системы, построении модели ЖЦ системы как со стороны заказчика, так и со стороны поставщика стандартного решения, о необходимости «привязки» задач, которые могли бы эффективно решаться на основе ИМ к модели ЖЦ системы .
Ключевые слова: АСУ в кризисных и чрезвычайных ситуациях, жизненный цикл, моделирование
введение
В статье предлагается комплексная модель разработки, эксплуатации и последующего развития системы управления в кризисных и чрезвычайных ситуациях. Она строится на основании современного понимания жизненного цикла автоматизированных систем (ГОСТ Р ИСО/ МЭК 15288:2005), опираясь на базовые положения ГОСТ 34, которые для государственных организаций являются основой культуры проектирования. Устоявшаяся «линейная» модель ГОСТ 34 дополняется идеями непрерывности и постоянного совершенствования. Это как нельзя лучше соответствует специфике АСУ в кризисных и чрезвычайных ситуациях. Помимо базовых стандартов особое внимание уделяется участникам создания и эксплуатации АСУ в кризисных и чрезвычайных ситуациях, их ролям и взаимодействию на всех фазах жизненного цикла.
Техногенные катастрофы последних лет, практика их преодоления помимо методов и средств по предотвращению кризисных и чрезвычайных ситуаций выдвигают требования к созданию современных автоматизированных систем управления (АСУ). Условия и специфика в каждом случае свои, но работы по созданию и использованию АСУ в кризисных и чрезвычайных ситуациях имеют много общего. И это общее может и должно быть зафиксировано в модели жизненного цикла системы. О возможности выделить общие этапы жизни системы говорит и теория стадийности, исходящая из предположения, что «...всякая система (экономическая, социальная и т. д.), развиваясь, проходит определенные стадии, которые могут быть систематизированы на абстрактном уровне. В соответствии с этой теорией можно утверждать, что каждая бизнес-система проходит за время своей жизни определенные стадии, независимо от того, когда она начала первую — становление бизнеса.
№ 6 (54) 2014
Понимание теории стадийности применительно к управлению компанией может помочь ей сократить путь от становления до зрелости»1. Надо отметить, что АСУ в кризисных и чрезвычайных ситуациях — большая система и будет востребована всегда. И при этом жизненный цикл конкретного экземпляра2 этой АСУ конечен. По мере эксплуатации системы накапливаются дополнительные требования к системе, ее функциональным возможностям, инфраструктуре, и наступает момент, после которого необходимо переосмыслить концепции, лежащие как в основе системы, так и в основе ее системы управления. Другими словами, планируя окончание прекращения эксплуатации конкретной АСУ, нужно начинать проектирование новой системы.
Жизненный цикл системы
Рассмотрение проблемы начнем с общих определений, которыми будем далее руководствоваться. Совокупность процессов и этапов развития технических систем, продуктов производства от моментов зарождения или появления потребности их создания и использования до прекращения функционирования или применения принято называть жизненным циклом.
Жизненный цикл автоматизированной системы — совокупность взаимосвязанных процессов создания и последовательного изменения состояния автоматизированной системы от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации3.
1 Гантер Р. Методы управления проектированием программного обеспечения. М.: Мир, 1981.
2 Экземпляр ПО — приобретенная в собственность (взятая в лизинг) версия ПО, установленная и, возможно, кастомизированная.
3 ГОСТ Р ИСО/МЭК 12207-99 «Информационная
технология. Процессы жизненного цикла программных
средств». Идентичный ISO/IEC 12207:1995 System and
software engineering — Software life cycle processes.
Программное средство (ПС)4 — ключевая компонента АСУ в кризисных и чрезвычайных ситуациях. В этой связи важно отметить, что жизненный цикл ПС имеет существенные отличия от жизненного цикла оборудования, так как ПС подвержены изменениям в течение всей их жизни.
В ГОСТ Р ИСО/МЭК 15288:2005 стадия определяется так:
Стадия жизненного цикла — это период в пределах жизненного цикла системы, относящийся к состоянию системного описания или непосредственно к самой системе. Стадии отображают значимый прогресс и достижение запланированных этапов развития системы на протяжении всего жизненного цикла и дают начало важнейшим решениям относительно своих входов и выходов5.
Модель жизненного цикла включает одну или несколько стадий и «...собирается в виде последовательности стадий».
Используемые стандарты
Создание и эксплуатация столь сложных систем, как автоматизированная система управления, в кризисных и чрезвычайных ситуациях требует понимания стандартов, которые необходимо заложить в ее основу. Любой стандарт предназначен для обеспечения взаимопонимания между заказчиком и исполнителем. Стандарт также обеспечивает формальные требования для предоставляемых правообладателю результатов, т. е. постулирует необходимый набор документов, которые в любом случае должен разработать исполнитель. Стандарт обеспечивает базу, которая поможет заказчику контролировать ход реализации проекта и существенным образом сократить время на прием результатов выполненных работ.
4 Авторы используют понятие «программное средство» в соответствии с идеологией группы ГОСТ 34.
5 ГОСТ Р ИСО/МЭК 15288:2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем». Идентичный ^О/IEC 15288:2002 System engineering — System life cycle processes.
No. 6 (54) 2014
При разработке модели жизненного цикла автоматизированной системы управления в кризисных и чрезвычайных ситуациях будем основываться на идеях следующих стандартов:
• серия стандартов ГОСТ 34;
• ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная инженерия. Процессы жизненного цикла систем»;
• ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»6.
Сложившиеся в России подходы к построению АСУ большими системами основаны преимущественно на функциональном подходе и механистической модели управления. При построении же больших систем настало время использовать идеи стандарта ГОСТ Р ИСО-МЭК 15288-2005. Этот стандарт «.распространяется на системы, которые созданы человеком и состоят из одного или нескольких следующих элементов: технические средства, программные средства, люди, процессы, процедуры.» Центральная идея стандарта — междисциплинарный подход к проблеме успешного создания систем и средство для ее решения. В качестве ключевых аспектов системной инженерии в стандарте определены: системный подход, жизненный цикл системы, инжиниринг требований, архитектурное проектирование, процессный и проектный подходы.
Помимо этого, необходимо творчески переосмыслить комплекс стандартов на автоматизированные системы ГОСТ 34. Для государственных организаций ГОСТ 34 являются основой культуры проектирования, и они выдвигают использование стандартов этой группы в качестве необходимого условия участия в тендерах на поставку (разработку) системы. К несомненным достоинствам стандартов серии ГОСТ 34 можно отнести
6 Нам важна ссылка на указанный стандарт, так как при создании крупных АСУ потребуется формулировать частные технические задания (в том числе на ка-стомизацию ПС), и данный ГОСТ может выступить в качестве замены системы ГОСТ 19 группы.
то, что они разработаны профессионалами, опиравшимися при их разработке на опыт успешно выполненных проектов. Стандарты серии ГОСТ 34 максимально полно описывают такую сложную абстрактную сущность, которой является любая автоматизированная система, через комплекс документов7:
• ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;
• ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;
• РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».
Основной минус этой группы стандартов — они создавались в конце 1980-х годов, и поэтому их положения частично устарели. Например, при рассмотрении архитектуры автоматизированной системы рассматривается только двухуровневая модель. Аналогичные претензии можно отнести и к описанию требований к входным и выходным формам. Вместе с тем полагаем, что указанные стандарты при их глубоком осмыслении могут быть использованы и сегодня. Их не нужно рассматривать как истину в последней инстанции, они полезны в качестве «подстрочника», позволяющего проверить полноту описания.
Участники стадий жизненного цикла А0У
В случае АСУ в кризисных и чрезвычайных ситуациях важно не просто выделять стадии жизненного цикла, но и организации, принимающие участие в работах:
Приобретающая сторона — это заинтересованное лицо, которое приобретает или получает продукт или услугу от поставщика (приобретающая сторона — это собирательный термин, ею может быть покупатель, заказчик, владелец).
7 Стандарты серии ГОСТ 34 введены в действие
с 1990 по 1993 г.
№ 6 (54) 2014
Поставщик — это организация или лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги (иногда приобретающая сторона и поставщик являются частью одной и той же организации)8.
Важно отметить, что для таких систем, как АСУ в кризисных и чрезвычайных ситуациях, поставщик — сложное понятие. Причина в том, что локализацию системы, как правило, выполняет российская компания, и эта компания выступает в качестве владельца локализованной системы. Возможна ситуация, при которой разработчиком решения и локализованной версии будет выступать третья компания.
Особенностью АСУ, применяемых в государственных организациях, является то, что как локализованная, так и кастомизи-рованная версии системы подлежат сертификации. Важно понимать, что сертификации подлежит вся система в целом, включая комплекс технических средств, комплекс программных средств и т. д. Поэтому применительно к АСУ в кризисных и чрезвычайных ситуациях мы считаем необходимым выделить следующих поставщиков:
• разработчик (поставщик) «Концепции безопасности» управляемого объекта;
• разработчик (поставщик) решения и «Концепции автоматизированной системы» (в ряде случаев — прототипа системы);
• поставщик (разработчик) экземпляра системы (локализованной версии);
• поставщик (разработчик) стандартной системы (лицензий базовой поставки).
Поясним, почему важно соблюдать такую градацию.
Разработчик «Концепции безопасности». Прежде чем приступать к созданию автоматизированной системы, необходимо понять, как в кризисной и чрезвычайной ситуации будет обеспечиваться безопасность
8 ГОСТ Р ИСО/МЭК 12207-2010 «Системная и программная инженерия. Процессы жизненного цикла программных средств». Идентичен стандарту ISO/IEC 12207:2008 System and software engineering — Software life cycle processes.
и непрерывность работы нашего объекта управления. То есть необходимо разработать «Концепцию безопасности» управляемого объекта. Разработку концепции управления большой системой обычно поручают научно-исследовательской отраслевой организации, имеющей опыт и специалистов соответствующей квалификации. На данной стадии должны быть заданы основные реперные точки и требования для разработки автоматизированной системы на основе исследования международного опыта, имеющейся практики и нормативно-правовой базы РФ. Основной целью ее является помощь в формировании видения заказчика на возможности реализации системы, ее функционал на базе имеющегося потенциала и наработанного опыта.
В дальнейшем автор концепции, как правило, выступает наряду с заказчиком (правообладателем) в качестве контролирующей организации, которая курирует проектирование системы с точки зрения соответствия ее первоначальному замыслу, целям или идее. На практике это означает, что на всех документах в титулах появляются согласующие штампы разработчика концепции системы. Это обязывает разработчиков решения, о которых речь пойдет ниже, согласовывать свою работу в том числе и с разработчиком концепции.
Разработчик решения. Достаточно часто предпринимаются попытки построения АСУ в кризисных и чрезвычайных ситуациях собственными силами. Однако практика создания больших систем показывает, что наиболее рациональным является создание ее на основе некоторого стандартного решения. В общем случае принято отделять исполнителей решения и собственно разработчика автоматизированной системы. Решение является конечным продуктом (адаптированным и кастомизированным), принимаемым в эксплуатацию заказчиком9.
9 Иногда роли разработчика решения, разработчика локализованной версии системы и поставщика системы (базовых лицензий) могут выполняться одной организацией.
No. 6 (54) 2014
Во многих случаях целесообразно не создавать систему с нуля, а использовать в качестве базового решения некий локализованный прототип. Поэтому уже на фазе разработки концепции или на последующих фазах проектирования могут быть предложены варианты решений, наиболее удовлетворяющих требованиям заказчика. Поставщиком «Концепции автоматизированной системы», в ряде случаев прототипа системы, является разработчик решения.
Поставщик (разработчик) экземпляра системы. В общем случае он выполняет локализацию системы, предоставляемую разработчику решения. Кроме того, он может выступать в качестве поставщика лицензий готового продукта. Но в общем случае необходимо отдельно выделить поставщика лицензий.
Поставщик (разработчик) стандартной системы (лицензий базовой поставки).
Он выполняет разработку и поставку часто не локализованной версии АС (иностранный производитель), обладающей встроенными механизмами кастомизации, локализации, настройки и интеграции, основанными на международных стандартах и практиках.
Сертификационный орган. Кроме того, для государственных систем большое значение имеет реализация требований по сертификации продукта, которая обеспечивает необходимую безопасность решения в самом широком смысле. Это особенно важно для продукции иностранных поставщиков. Для систем класса АСУ в кризисных и чрезвычайных ситуациях это означает, что поставщик должен предъявлять на экспертизу программные коды и оборудование. Нужно иметь в виду, что каждая новая (кастомизи-рованная) версия обязана получать отдельный сертификат. Поэтому, как правило, сертификация должна проводиться после решения всех проблем по адаптации системы для правообладателя (заказчика). Иногда сертификация может производиться поставщиком локализованной версии после осуществления локализации для конкретной территории или страны на уровне общеси-
стемного ПО, однако в случае внесения изменений в программные коды кастомизиро-ванной версии потребуется новый сертификат. Если локализацию и кастомизацию проводит непосредственно поставщик базовых лицензий, то он также может провести сертификацию продукта на этом уровне.
Базовая модель жизненного цикла асу в кризисных и чрезвычайных ситуациях
Основываясь на ГОСТ Р ИСО/МЭК 15288:2005 и ГОСТ 34.601-9010, предлагаем выделять следующие стадии жизненного цикла автоматизированных систем управления в кризисных и чрезвычайных ситуациях:
1. Стадия замысла системы управления.
2. Стадия выбора поставщика решения на автоматизированную систему.
3. Стадия разработки технического задания на автоматизированную систему.
4. Стадия технорабочего проекта.
5. Стадия ввода в действие автоматизированной системы.
6. Стадия проведения опытной эксплуатации автоматизированной системы.
7. Стадия использования11 (применения) автоматизированной системы.
8. Стадия сопровождения12 (поддержка применения) автоматизированной системы.
9. Стадия прекращения использования (применения) и списания автоматизированной системы.
Участие поставщиков, о которых говорилось выше, и сертификационного органа на стадиях жизненного цикла АСУ в кризисных и чрезвычайных ситуациях, а также взаимодействия правообладателя и постав-
10 ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы стадии создания».
11 В ГОСТ Р ИСО/МЭК 15288:2005 используется термин «применение», а в ГОСТ Р 12207-2010 используется термин «функционирование».
12 В ГОСТ Р ИСО/МЭК 15288:2005 используется термин «поддержка применения».
№ 6 (54) 2014
Рис. 1. Стадии жизненного цикла АСУ в кризисных и чрезвычайных ситуациях
щиков в структуре стадий жизненного цикла АСУ в кризисных и чрезвычайных ситуациях показаны на рис. 1. Прокомментируем кратко каждую из выделенных стадий, а также их принципиальные цели.
Принципиальные цели каждой из выделенных нами стадий представлены в табл. 1.
1. Стадия замысла системы управления (формирования требований к автоматизированной системе). Она начинается
Таблица 1
Стадии жизненного цикла автоматизированной системы управления в кризисных и чрезвычайных ситуациях, с точки зрения правообладателя
Стадия Цель Основные результаты
Стадия замысла системы управления Определить потребности правообладателя в виде документа «Концепция безопасности» 1. Распоряжения губернатора. 2 . Проектная структура . 3. Описание объекта . 4 . Тендерная документация, включая ТЗ на тендер «Концепция безопасности» . 5 . Объявление тендера. 6 . Результаты тендера (победитель) . 7 . Договор на разработку «Концепции безопасности» 8 . «Концепция безопасности»
Стадия выбора поставщика решения на автоматизированную систему Определить «видение» и возможности построения АС, с точки зрения правообладателя, в «Концепции АСУ КЧС» (разработка концепции на АС) 1. Тендерная документация (требования к проекту, к разработчику решения), включая ТЗ на тендер «Концепция АСУ КЧС» . 2 . Объявление тендера. 3 . Результаты тендера (победитель) . 4 . Договор с поставщиком решения на разработку АСУ КЧС . 5 . «Концепция АСУ КЧС»
Стадия разработки технического задания на автоматизированную систему Уточнить системные требования и проектные решения в формате ТЗ на АСУ КЧС 1. ТЗ на АСУ КЧС . 2 . Прототип АС, на основе которого будет создаваться АСУ КЧС . 3 . Договор с разработчиком решения
No. 6 (54) 2014
Окончание табл. 1
Стадия Цель Основные результаты
Стадия технорабочего проекта Разработать рабочую документацию на АСУ КЧС, необходимую для развертывания системы, и кастомизиро-вать ПО прототипа АС 1. Проектная документация на АС . 2 . Рабочая документация на АС и ее части . 3 . Список субподрядчиков . 4 . Проектно-сметная документация на поставку изделий для комплектования АС . 5 . Поставщики оборудования и ПО . 6 . ЧТЗ на кастомизацию ПО . 7 . Методика обучения . 8 . Методика приемо-сдаточных испытаний . 9 . Сводный отчет
Стадия ввода в действие автоматизированной системы Подготовить объект автоматизации к развертыванию АСУ КЧС у правообладателя, развернуть основные модули системы на объектах заказчика 1. Закупленное и поставленное оборудование, ПО . 2 . Инсталлированное, кастомизированное ПО . 3 . Ввод данных. 4 . Обученный и сертифицированный персонал . 5 . Тендерная документация на поддержку АС 6 . Определение победителя тендера. 7 . Договоры о поддержке применения АСУ КЧС 1 и 2 уровни ITIL . 8 . Акт приемки АСУ КЧС в опытную эксплуатацию
Стадия проведения опытной эксплуатации автоматизированной системы Выявить отклонения эксплуатационных характеристик от заявленных параметров Определить дополнительные требования . Проверить выполнение заявленных функций в рамках решаемых задач разработки (сопровождения) 1. Репортинг: акты и сообщения об ошибках и запросах на изменения (trouble request, change request) 2 . Устраненные замечания 3 . Акт о приеме АСУ КЧС в постоянную эксплуатацию
Стадия проведения опытной эксплуатации автоматизированной системы Использование функционала АСУ КЧС для решения целевых задач . Разработка отчета о применении АСУ КЧС и предложений о продолжении эксплуатации/применения АС 1. Отчеты о применении, включая сообщения об ошибках и запросах на изменения (trouble request, change request) . 2 . Предложения о продолжении применения АСУ КЧС
Стадия использования (применения) автоматизированной системы Обеспечение непрерывного функционирования системы . Предоставление услуг, поддерживающих ее применение 1. Запросы на поддержку 2 . Отчеты о закрытии запросов на поддержку. 3 . Отчеты о поддержке применения АСУ КЧС
Стадия прекращения применения и списания АСУ КЧС Утилизация старой версии АСУ КЧС 1. Распоряжение губернатора . 2 . Персонал, выполняющий утилизацию . 3 . Акт об утилизации старой версии АСУ КЧС
108 j
№ 6 (54) 2014
с проведения правообладателем тендера по выбору разработчика «Концепции безопасности» управляемого объекта. На основании «Описания объекта», являющегося составной частью тендерной документации, участники тендера и готовят свои предложения. Основным результатом «Стадии замысла системы управления» является согласованная со всеми заинтересованными сторонами «Концепция безопасности» управляемого объекта. В ее основе лежит видение правообладателем контуров и функционала автоматизированной системы с учетом его специфики. Иногда разработчик «Концепции безопасности» определяется без тендера, например, в случае подготовки материалов для проектов государственной важности может быть выбран и утвержден профильный научный или проектный государственный орган. На рис. 1 показано, что при выполнении целей и задач данной фазы происходит тесное взаимодействие правообладателя и исполнителя.
2. Стадия выбора поставщика решения. Она начинается с проведения правообладателем тендера по выбору поставщика решения. На основании «Концепции безопасности» участники тендера готовят свои предложения по «Концепции АСУ в кризисных и чрезвычайных ситуациях». Основным результатом данной стадии является согласованная со всеми заинтересованными сторонами и утвержденная «Концепция АСУ в кризисных и чрезвычайных ситуациях». На рис. 1 вертикальной стрелкой обозначен характер взаимодействия поставщика решения и правообладателя. Главными ролевыми участниками данной стадии являются правообладатель и разработчик решения.
3. Стадия разработки технического задания на автоматизированную систему. Она начинается с утверждения документа «Концепция АСУ в кризисных и чрезвычайных ситуациях». На этой стадии принимается окончательное решение относительно использования предлагаемого прототипа системы и заключается договор с разработчиком прототипа системы (он становит-
ся разработчиком решения). Здесь важно, что демонстрация прототипа, которым, как правило, выступает не кастомизированная под заказчика версия, является часто важнейшим элементом для принятия решения о победителе тендера. Потенциальный разработчик решения взаимодействует с поставщиком экземпляра системы и предлагает одну из версий системы для оценки заказчику. Данная версия может быть уже локализована поставщиком экземпляра или самим разработчиком первичного лицензионного дистрибутива. Детальное уточнение системных требований и проектных решений оформляется в формате технического задания (ТЗ) на АСУ в кризисных и чрезвычайных ситуациях.
4. Стадия технорабочего проекта. Она начинается с момента подписания правообладателем и разработчиком решения ТЗ на АСУ в кризисных и чрезвычайных ситуациях. Целью данной стадии является создание такой системы, которая удовлетворяет требованиям правообладателя (приобретающей стороны), может быть испытана, оценена, использована по назначению и сопровождаема. Формально для стадии рабочего проекта исполнитель может быть выбран с помощью тендерных процедур. Однако, как правило, в качестве исполнителя ТЗ выступает разработчик решения, либо он поддерживает создание системы в рамках организации правообладателя. Разработчик решения заключает договор с поставщиком системы на поставку некастомизированной версии системы. В случае отсутствия достаточного опыта или квалификации у разработчика решения разработчик системы может также привлекаться к исполнению ТЗ.
5. Стадия ввода в действие АСУ в кризисных и чрезвычайных ситуациях.
На этом этапе в соответствии с рабочей документацией, разработанной на стадии рабочего проекта, разработчиком решения осуществляется интеграция13 приобретен-
13 В ГОСТ Р 12207-2010 используется термин «ком-плексирование».
No. 6 (54) 2014
ного оборудования и кастомизация ПО. Производятся обучение и сертификация персонала, определяются организации, которые будут участвовать в поддержке использования АСУ в кризисных и чрезвычайных ситуациях, проводятся предварительные испытания и устраняются выявленные недостатки. Заканчивается данная стадия подписанием Акта приемки системы в опытную эксплуатацию и договоров на поддержку. Если кастомизация требует достаточно глубоких доработок кодов или аппаратуры, то в процесс вовлекается поставщик системы. После ка-стомизации ПО для государтсвенных организаций необходимо сертифицировать полученный экземпляр в органах сертификации. Кастомизация предполагает тесное взаимодействие всех вышеперечисленных поставщиков с целью получения адаптированного для конкретного заказчика продукта.
6. Стадия опытной эксплуатации АСУ в кризисных и чрезвычайных ситуациях. На этой стадии необходимо выявить отклонения эксплуатационных характеристик от заявленных, отработать все вопросы, связанные с поддержкой применения. Как правило, в процессе опытной эксплуатации заказчик готовит материалы для устранения замечаний и недостатков. В процессе их устранения принимают участие как разработчик решения, так и поставщик системы в зависимости от глубины требуемых проработок. При выявлении и устранении ошибок поставщик решения взаимодействует с поставщиками локализованного экземпляра и иногда непосредственно с поставщиком первичных лицензий в случае, если кастоми-зация системы требует изменений в кодах. При этом может потребоваться сертификация вновь полученной версии, поэтому, как правило, кастомизированная версия отправляется на окончательную сертификацию после устранения всех ошибок и недостатков и выполнения всех требований заказчика. Иногда кастомизация может быть выполнена без вмешательства в изменения базовых кодов с помощью специализированных средств настройки и адаптации. В этом слу-
чае сертификация версии системы не требуется. Заканчивается данная стадия подписанием Акта о приемке АСУ в эксплуатацию.
7. Стадия использования (применения) АСУ. Эта стадия и стадия сопровождения (поддержки применения) АСУ протекают параллельно с момента подписания акта о приеме АСУ в кризисных и чрезвычайных ситуациях в постоянную эксплуатацию. На стадии использования (применения) АСУ она используется в «боевом режиме», и осуществляется мониторинг характеристик функционирования, идентификация, классификация и составление отчетов об отклонениях, недостатках и отказах, а также запросов на изменения. Здесь существенна роль разработчика решения, который производит отладку и доводку версии системы до требуемых надежностных и функциональных характеристик. В отношении глобального процесса эксплуатации в течение данной стадии АСУ в кризисных и чрезвычайных ситуациях может совершенствоваться, могут возникать различные конфигурации, версии (на основании предложений о продолжении применения АС, формируемых на базе отчетов). Поставщик системы может также участвовать в процессе подготовки подобных предложений, в устранении ошибок функционирования. Основа такой работы — гарантийные обязательства или договоры, заключаемые на поддержку применения. На основании предложений принимается решение либо о расширении функциональных возможностей АСУ в кризисных и чрезвычайных ситуациях и возврата на «Стадию техническое задание», либо о приобретении новой системы и возврата на «Стадию замысла». Понятно, что в любом из этих случаев АСУ должна продолжать функционировать, а ликвидация ее старой версии начинается в момент перехода новой версии на «Стадию использования АСУ в кризисных и чрезвычайных ситуациях (эксплуатации)», т. е. подписания акта о приемке новой версии системы в эксплуатацию. Здесь следует отметить, что для решения описанных задач поставщик решения осуществляет взаимо-
№ 6 (54) 2014
действие с поставщиком экземпляра системы и, если требуется, то и непосредственно или опосредованно с поставщиком первичных лицензий. При этом, если устранение ошибок или доработки требуют производить изменения в кодах системы, то вновь полученная версия должна быть представлена на сертификацию.
8. Стадия сопровождения (поддержки применения) АСУ в кризисных и чрезвычайных ситуациях. На этой стадии пользователям системы предоставляются поддерживающие услуги. В соответствии с методологией 1Ж при сопровождении предполагается три уровня, которые должны осуществлять:
• правообладатель (0-й уровень 1Т^),
• разработчик решения (1-й уровень 1Т^),
• поставщик экземпляра системы (2-й уровень 1Т^).
9. Стадия прекращения использования (применения) и списания АСУ в кризисных и чрезвычайных ситуациях. Она начинается в момент перехода новой версии АСУ на стадию использования (эксплуатации), т. е. подписания акта о приемке новой версии АСУ в эксплуатацию. На этой стадии осуществляется утилизация прежней системы или ее версии, проводится архивирование данных и подготовка копий ПО, которые отправляются на хранение. Данные проблемы решает правообладатель либо организация, осуществляющая эксплуатацию системы по договору с правообладателем.
В первой части статьи были выявлены фазы жизненного цикла (ЖЦ) АСУ в кризисных и чрезвычайных ситуациях для правообладателя и поставщиков, показаны многообразие, взаимовлияние и зависимости процедур и процессов взаимодействия основных участников реализации задач ЖЦ системы. Обоснована необходимость использования подхода при построении АСУ КЧС, базирующегося на международных и отечественных стандартах и включающего в себя непрерывное взаимодействие этапов ЖЦ.
Далее будет показано, как, опираясь на парадигму процессного управления,
с помощью моделей SADT, в рамках приведенных стандартов можно рассматривать ЖЦ системы как непрерывный циклический процесс, включающий в себя этапы ее перманентного совершенствования, адаптации к меняющимся внешним условиям и требованиям заказчика.
Системный подход к построению больших систем (тем более с участием людей) диктует использование такого инструмента, как моделирование, в том числе ролевого функционального и имитационного моделирования. Фактически речь идет о формализации ЖЦ системы, построении модели ЖЦ системы как со стороны заказчика, так и со стороны поставщика. Необходима «привязка» задач, которые могли бы эффективно решаться на основе моделирования.
Описание модели
Основные процессы системы могут рассматриваться с точки зрения поддержки стратегического и оперативного уровня управления.
Как было показано в [7], «поскольку основные процессы (бизнес-процессы) организации — это организованная деятельность часто больших междисциплинарных коллективов, их можно и нужно рассматривать с позиций кибернетического подхода, используя понятия стратегического и оперативного управления. Исходя из этого можно заключить следующее: стратегическое управление — это аспект управления, связанный с определением траектории состояний системы. Так как в цикле PDCA осуществляется целеполагание, будем связывать его со стратегическим управлением. Оперативное управление — это аспект управления при удержании системы на определенной траектории (определенной на уровне стратегического управления) (регулирование) и связанный с циклом SDCA.
Детальное рассмотрение взаимосвязи циклов PDCA и SDCA дано в [7]. Однако не-
No. 6 (54) 2014
обходимо отметить, что «первично построение траектории состояний системы — це-леполагание и, соответственно, цикл PDCA. Удержание же системы на определенной траектории может быть реализовано посредством цикла SDCA. Значит, цикл PDCA должен быть разорван» [7].
В рассматриваемом случае стратегические задачи лежат в области разработки решений и нормативной базы, обеспечивающей платформу для проектирования и внедрения системы, поддержки ее эксплуатации и подготовки необходимых материалов для развития. Таким образом, на стратегическом уровне создается и поддерживается базис, обеспечивающий основу для фаз ЖЦ Системы. Из этого следует, что модель управления жизненным циклом (ключевое слово цикл) включает в себя элементы замкнутых обратных связей и обеспечивает непрерывность во времени рассматриваемых процедур.
АСУ КЧС, как уже было отмечено, это система, которая существует и совершенствуется непрерывно во времени, поэтому стадии ее ЖЦ включают элементы замкнутых обратных циклов.
Модель управления Жц на стратегическом уровне
Как было показано, задачи стратегического уровня предполагают создание базовых условий и развитие принципов, необходимых для поддержки фаз ЖЦ.
Функциональная модель управления ЖЦ уровня А-0 представлена на рис. 2.
Цель моделирования. Точка зрения
С точки зрения губернатора цель моделирования — формализовать процесс на стратегическом и оперативном уровне, определить участников процесса, их роли для разработки и определения нормативной базы, на основе которой создается ее кастомизированная версия, для конкретной ситуации, а также произвести действия по управлению в этой ситуации.
Переченьвопросов:
• На какие стадии разбивается процесс управления в КЧС на стратегическом уровне?
• Кто является ответственным за выполнение каждой стадии?
• Какими документами (ограничениями) руководствуются при реализации, поддержке каждого этапа?
Рис. 2. Модель управления на стратегическом уровне А-0
112
№ 6 (54) 2014
Таблица 2
Аспекты моделирования. Функции
Функции Описание
Принимать решения Утвердить перечень документов, обеспечивающих нормативно-правовую базу для заключения договоров, разработки модели угроз, концепции безопасности, проектной документации, планов действий в КЧС, методических указаний по организации процессов ликвидации и утилизации АСУ КЧС и т . д . Выпуск приказов и распоряжений, обеспечивающих комплекс мер, направленных на поддержание и координацию управления в КЧС
Готовить проекты решений и документов Органы администрации (обычно комиссия при губернаторе по предупреждению и ликвидации ЧС и пожарной безопасности — комиссия по ЧС и ПБ) с привлечением внешних специализированных организаций разрабатывают проекты нормативно-распорядительных документов, модели угроз, планов, программ и мероприятий на основе имеющейся нормативной базы, законов РФ, ГОСТ, указов Президента РФ . Таким образом, производится как бы касто-мизация имеющейся нормативной базы федерального уровня на региональную специфику Кроме того, осуществляется подготовка тендерной документации для реализации фазы ЖЦ, выявление поставщика решения на основе результатов конкурса
Управлять стадией ЖЦ На основе подготовленной нормативно-правовой и договорной базы осуществляется процесс непосредственно реализации фазы ЖЦ . Со стороны администрации (Заказчика) процессом, как правило, управляет назначаемый руководитель проекта, который взаимодействует с представителями генерального подрядчика, готовит соответствующий репортинг для анализа ситуации со стороны администрации
• Какие результаты являются входными и выходными на каждой стадии?
В табл. 2 представлены основные аспекты моделирования.
На рис. 3 дается декомпозиция основного управляющего блока модели уровня А0.
В табл. 3 описаны объекты моделирования функциональной модели ЖЦ.
Рис. 3. Управление КЧС на стратегическом уровне А0
113
NO. 6 (54) 2014
journal of applied informatics
Заключение
С помощью моделей SADT было показано, что стадии создания системы, изложен-
ные в ГОСТ 34 и дополненные в ИСО/МЭК 15288, определяя последовательно жизненный цикл системы, обеспечивают одновременно непрерывность и цикличность про-
Таблица 3
Объекты моделирования
Дуга Объект Описание
Вход Информация об объекте Набор данных о территории, объектах промышленного, социально-общественного, административного назначения, критически важных объектах и др . , природных, техногенных и других факторах, связанных с этими объектами и территорией, на которой они располагаются
Ресурсы Штатные структуры администрации, МВД, МЧС, ФСБ и др . , материально-технические ресурсы, денежные средства, выделяемые в рамках программы реализации ЖЦ
Документы исполнителей Документы и материалы, разрабатываемые исполнителями (ТЗ, пояснительная записка, Концепция)
Согласованный документ Документы, согласованные с Заказчиком и утвержденные уполномоченным органом для реализации фазы ЖЦ
Документы исполнителя стадии Прошедшие процедуру утверждения и согласования принятые актами материалы: ТЗ, Концепция, пояснительная записка, рабочая документация и т д
Договоры Договоры, заключаемые для реализации стадий ЖЦ
Выход Нормативно-распорядительные документы Приказы, распоряжения, на основе которых запускаются тендерные процедуры, утверждаются разработанные подзаконные акты и нормативы
Концепция безопасности Разработанные специализированной организацией основные подходы и видение Системы
Документы исполнителям Документация для реализации фазы ЖЦ ТЗ на тендер, описание
Договоры Подписанные договоры для реализации фазы ЖЦ
Документ на согласование Разработанный исполнителем документ, представляемый на согласование Заказчику (ТЗ, ПЗ, Концепция, РД и т . д . )
Согласованный документ + пояснительная записка Документы, прошедшие стадию предварительного согласования с руководителем проекта и отправленные на анализ и утверждение по инстанции (Управление по ГО ЧС и Б)
Письма исполнителям Документы, регулирующие отношения генерального подрядчика и субподрядчика: протоколы, замечания и т. п .
Сводный статус-отчет Отчеты генподрядчика перед Заказчиком о ходе выполнения работ, например о выполнении этапов календарного плана, и т . п .
№ 6 (54) 2014
Окончание табл. 3
Дуга Объект Описание
Управление Законы РФ, указы Президента, ГОСТы, международные сстандарты Основополагающие государственные и международные акты, на основе которых осуществляется принятие решений
Стратегические цели Показатели эффективности, характеризующие достижение определенного уровня безопасности жизни
Механизм Губернатор Первое лицо, несущее ответственность за достижение стратегических целей и выполнение ключевых показателей
Управление ГОЧС и безопасности Постоянно действующий орган управления в составе администрации региона, который отвечает за работу по направлениям ГО ЧС и обеспечения безопасности, координирует работу силовых ведомств и органов госвласти в регионе
Руководитель проекта Ответственное лицо из состава администрации, назначаемое для управления процессом работ по реализации фаз ЖЦ Системы
Рабочая группа РП Рабочая группа из состава представителей Заказчика, занимающаяся реализацией проекта
цесса эксплуатации и развития. Это как раз характерно для больших систем, к которым относится система управления в кризисных и чрезвычайных ситуациях и которые существуют независимо от уровня автоматизации и состояния технической инфраструктуры, так как безопасность является базовым понятием существования и развития гражданского общества и какого-либо общества вообще. Кроме того, представленная модель дает обобщенную функционально-ролевую картину основных процессов и фаз разработки АСУ для государственных структур, зоны ответственности которых распространяются на такую специфичную область деятельности, как обеспечение безопасности в самом широком смысле этого слова.
Подходы, связанные с применением имитационных моделей, использующие в качестве постановки задачи изложенный функционально-целевой принцип, позволяют выйти на ряд конкретных количественных и финансовых показателей, определяющих качественную и затратную характеристики внедрения [6]. Представленный материал может оказаться полезным для проектировщиков и разработчиков автоматизированных систем, в том числе в такой специфической области, к которой относятся орга-
ны государственной власти и управления, органы безопасности.
Литература
1. ГОСТ Р ИСО/МЭК 15288:2005 «Системная инженерия. Процессы жизненного цикла систем» (ISO/IEC 15288:2002 «System engineering — System life cycle processes»).
2. Толковый словарь по вычислительным системам. М.: Машиностроение, 1990.
3. Липаев В. В. Программная инженерия. Методологические основы. Курс лекций. М.: Теис, 2006.
4. ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств».
5. Фокс Дж. Программное обеспечение и его разработка. М.: Мир, 1985.
6. Разумов Д. А., Алешин В. Д. Имитационное моделирование в жизненном цикле автоматизированных систем управления в кризисных и чрезвычайных ситуациях. Пятая всероссийская научно-практическая конференция по имитационному моделированию и его применению в науке и промышленности. Санкт-Петербург: Труды конференции, 2011.
7. Алешин В. Д., Баскаков А. В, Ерхов Е. В. Обеспечение непрерывности бизнеса. Часть 1. Модель управления процессами. М. Information Management. 02.2013.
No. 6 (54) 2014
8. Алешин В. Д. Проблемы использования цикла Деминга в международных стандартах. Сборник трудов XVI научно-практической конференции «Инжиниринг предприятий и управление знаниями». М., 2013.
9. Разумов Д. А., Алешин В. Д. Модель жизненного цикла АСУ в кризисных и чрезвычайных ситуациях // Information Management. 2013. № 14.
References
1. GOST R ISO/MJeK 15288:2005 Sistemnaja inzhenerija. Processy zhiznennogo cikla sistem (ISO/IEC 15288:2002 «System engineering — System life cycle processes»).
2. Tolkovyj slovar'po vychislitel'nym sistemam. M.: Mashinostroenie, 1990.
3. Lipaev V. V. Programmnaja inzhenerija. Metodologicheskie osnovy. Kurs lekcij. M.: Teis, 2006.
4. GOST R ISO/MJeK 12207- 99 Informacionna-ja tehnologija. Processy zhiznennogo cikla pro-grammnyh sredstv.
5. Foks Dzh. Programmnoe obespechenie i ego raz-rabotka. M.: Mir, 1985.
6. Razumov D. A., Aljoshin V. D. Imitacionnoe mod-elirovanie v zhiznennom cikle avtomatizirovannyh sistem upravlenija v krizisnyh i chrezvychajnyh situacijah. Pjataja vserossijskaja nauchno-prak-ticheskaja konferencija po imitacionnomu mode-lirovaniju i ego primeneniju v nauke i promyshlen-nosti — Sankt-Peterburg: Trudy konferencii, 2011.
7. Aleshin V. D., Baskakov A. V., Jorhov E. V. Obespechenie nepreryvnosti biznesa. Chast' 1. Model' upravlenija processami. M. Information Management. 02.2013.
8. Aleshin V. D. Problemy ispol'zovanija cikla Deminga v mezhdunarodnyh standartah. Sbornik trudov XVI nauchno-prakticheskoj konferencii «Inzhiniring predprijatij i upravlenie znanijami». M., 2013.
9. Razumov D. A., Aleshin V. D. Model' zhiznennogo cikla ASU v krizisnyh i chrezvychajnyh situacijah. Information Management, 2013, no. 14.
D. Razumov, Russian Telecom Equipment Company (part of the Russian technologies state Corporation), Moscow, Dmitrirazumov@yandex.ru
V. Aleshin, Dr of Technique, Associate Professor Russian Academy of national economy and state service under the President of the Russian Federation, Moscow, aleshin_vladimir@mail.ru
Models in life cycle of the automated control systems in crisis and extreme situations
Anthropogenic accidents of last years, practice of their overcoming besides methods and means on prevention of crisis situations make demands to designing and creation of the modern regional automated control systems. Based on lifecycle models, proposes formalization of tasks for which it is expedient to use Simulation Modeling (SM). Actually talking about the formalization of a life cycle (LC) system, building a model of a system lifecycle as with customer, as in the case of supplier and standard decision about the necessity of «binding» targets that could effectively be addressed using SM to model lifecycle of the system. In article is offered the complex model of development, operation and the subsequent development of a control system in crisis and emergency situations. It is under construction on the basis of modern understanding of life cycle of the automated systems (State standard specification P ISO/MEK 15288:2005), relying on basic provisions state standard specifications 34 which for the state organizations are a basis of culture of design. The settled state standard specification 34 «linear» model is supplemented with ideas of a continuity and continuous improvement. It as well as possible corresponds to specifics of ACS in crisis and emergency situations. Besides basic standards, the special attention is paid to participants of creation and operation of ACS in crisis and emergency situations, to their roles and interaction on all phases of life cycle. Keywords: automated control systems for accident situation, life cycle, modelling.
116 I
