 |
Концептуальное проектирование на региональном уровне
|
|
|
|
Архитектура региональной информатизации
Рассмотрим кратко слои архитектуры региональной информатизации в применении к конкретным задачам. Прорабатывая каждый уровень, важно не забывать общую цель, ради которой проводится описание — согласование интересов и построение программы, реализация которой направлена на решение поставленных перед региональной информатизацией задач.
Для того чтобы описание соответствовало поставленным целям, необходимо придерживаться следующих правил:
1. Стройте описание, исходя из реальных, а не формальных взаимосвязей в регионе: рекомендуется строить функциональную модель в соответствии с нормативными правовыми актами, предпочитая проект закона закону, особенно если проект больше соответствует изменившейся реальности.
2. Четко отделяйте политические соображения от профессиональных: в описании отведите политически важным моментам отдельное (как правило — ведущее) место. Рекомендуется первый (верхний) слой каждого из уровней делать «политическим».
3. Используйте разные источники информации: любой, даже самый опытный специалист обладает только одной точкой зрения.
4. На каждом шаге описания проверяйте предыдущие шаги: предоставляется масса возможностей уточнить модель.
5. Помните, что создание архитектуры требует специальной квалификации: лучше поручите его специалистам.
Каждый из слоев архитектуры региональной информатизации представляет собой условное (модельное) описание соответствующих аспектов информатизации, представленное архитектурными моделями. Архитектурная модель — это аналитическое описание какого-либо из аспектов деятельности, построенное на основе заранее подготовленной классификации (справочной модели) и/или четко определенном правиле описания (стандарте). Рассмотрим, как строится архитектурное описание региональной информационной системы на основе функциональной и процессной моделей архитектуры деятельности, компонентной модели прикладных систем, модели данных и технической модели, а также с учетом моделей эффективности и безопасности.
|
|
|
Минимальный состав приложений, которые необходимо разработать, внедрить и поддерживать в регионе, определен в «Концепции региональной информатизации до 2010 года». С точки зрения региональной информатизации этот комплекс приложений является наиболее универсальным: все из перечисленных подсистем имеются или должны быть созданы в каждом регионе, причем специфика каждого региона не является определяющим фактором.
1. Модель эффективности
Для того чтобы регионы можно было сравнивать с точки зрения эффективности информатизации, необходимо, чтобы в проектах региональной информатизации использовался единый набор показателей. К сожалению, сегодня не существует общепринятого подхода к расчету эффективности ИКТ-проектов. Поэтому мы предлагаем использовать для построения модели эффективности справочную модель, основанную на классификации государственных информационных систем по функционалу, предложенную специалистами ГУ ВШЭ.
Для описания данного архитектурного слоя необходимо:
- Во-первых, определить общий список критериев эффективности региона. Как правило, он приводится в стратегии социально-экономического развития региона.
- Во-вторых, определить, как внедрение региональной ИКТ-системы повлияет на эти показатели. Для этого мы соотносим с вышеназванной классификацией и определяем функциональный класс системы. Для каждого класса в справочной модели приводится перечень социально-значимых результатов внедрения такой системы. Вы устанавливаете соответствие между показателями эффективности региона и эффектами от внедрения системы, выбранными из перечня. При необходимости можно провести экспертную оценку количественного или сравнительную оценку качественного влияния системы.
|
|
|
- В-третьих, выбрать из полученных взаимосвязей существенные, т.е. те, которые дают заметный эффект.
- В-четвертых, при принятии архитектурных решений необходимо ориентироваться на полученную модель.
2. Архитектура деятельности
Начнем рассмотрение архитектуры деятельности с функционального описания системы. Набор функций, который необходимо выполнять в рамках некоторой деятельности, меняется крайне медленно, особенно это касается функций государственного управления. Поэтому функциональная модель — наиболее стабильная из всех моделей архитектуры.
Во всем мире функциональные модели строятся, исходя из заранее подготовленных справочных моделей, но в России нет пока общепризнанной справочной модели функций. Вместо этого, в качестве источника информации для построения модели функций можно рассматривать нормативную и законодательную базу.
Особое подмножество функциональных моделей — модели сервисов, например, государственных услуг.
Функциональная модель строится по следующему алгоритму:
1. Определяется область деятельности, подлежащая информатизации, формулируются ее границы. В результате формируется перечень нормативных правовых актов и (или) их проектов, а также описание новых направлений деятельности, входящих в данную область. В самом общем виде формулируются результаты деятельности.
2. На основе анализа нормативных правовых актов выделяется набор государственных функций верхнего уровня, необходимых для достижения результата деятельности. Название функции формулируется с точки зрения получаемого результата. Например, «Защита прав инвесторов» или «Охрана здоровья населения региона». При этом, как правило, не принимаются в расчет обеспечивающие функции, не имеющие выхода на конкретный «внешний» результат. Например, «Подготовка отчетности губернатору».
3. На основе анализа внутренних и межведомственных нормативных правовых актов и регламентов для каждой из функций верхнего уровня выделяется 5—9 базовых подфункций 1-го уровня, реализация которых направлена непосредственно на результаты соответствующей функции верхнего уровня. Виды работ, направленные на обеспечение процесса, не учитываются. Если в итоге получилось большее количество подфункций, необходимо их агрегировать.
|
|
|
4. Предыдущий шаг повторяется для каждой из подфункций 1-го уровня.
В качестве языка описания можно использовать, например, SADT — метод описания функций, предложенный Россом в 1960-х годах и реализованный в стандарте IDEF0.
Как правило, достаточно детализации функций до 3-го уровня. Но, в принципе, детализация может производиться до уровня операции. Операция обладает следующими особенностями:
§ законченное юридически значимое действие;
§ выполняется одним субъектом (исполнителем или их группой), обладающим определенной квалификацией;
§ начинается одним конкретным типом событий;
§ имеет на выходе единственный результат.
Модель процессов. Системное представление административных процессов
Вторая из моделей, относящихся к архитектуре деятельности — модель процессов. В отличие от других моделей, для модели процессов невозможно построение единой справочной модели, т.е. устойчивого набора «стандартных» процессов, подходящих для любой организации. Эта модель отражает уникальность, особенности организации работ и, зачастую, несет на себе отпечаток стиля управления руководителя.
Вместо этого для данной модели может быть сформирован набор правил описания административных процессов.
Существуют разные форматы (нотации) описания административных процессов: от текстовых описаний (регламентов) до формальных схем. В настоящее время можно ориентироваться на тот способ описания, который принят в регионе, поскольку единого универсального подхода к описанию процессов не существует. Наиболее распространенными являются:
- SADT — несмотря на то, что она разработана для описания функций, реализована, например, в AllFusion Process Modeller;
|
|
|
- IDEF3 — менее известная в России;
- eEPC — реализованная в ARIS.
Принято считать, что процесс реализует определенную функцию. Во избежание путаницы мы будем называть элементы процессов работами. Работы, в свою очередь, могут описываться подпроцессами. Оптимальная глубина декомпозиции процессов — 4 уровня.
Необходимо отметить, что вспомогательные функции, не учитываемые в функциональной модели, не могут быть проигнорированы в процессной: они подлежат обязательному описанию.
3. Архитектура компонент прикладных систем. Компонентная структура ИКТ решений
На этом слое происходит переход от описания деловой архитектуры к системной архитектуре. Этот слой описывает способ, которым информационная система реализует процессы в организации.
Для классификации компонент, как правило, используют функциональный подход, т.е. подход, основанный на стандартизации деловых функций. К сожалению, на сегодня такого стандарта в России не существует, равно как не существует и единой справочной модели функций с достаточной степенью детализации.
Для построения архитектурной компонентной модели может быть использован подход, основанный на маркетинговых терминах. В ходе рыночного отбора появились термины для систем автоматизации всех основных управленческих функций.
Так, например, в приложении к концепции региональной информатизации приводится следующая компонентная схема:
- информационно-аналитическая подсистема;
- системы информационного обмена;
- интеграционные подсистемы;
- общая информационно-технологическая инфраструктура.
Чтобы разработать компонентную архитектуру необходимо:
1. Выбрать справочную компонентную модель. Пока не принят общефедеральный стандарт, можно использовать принятую в ведомстве или регионе или обратиться к одной из классификаций (таксономий) ведущих аналитических агентств (Gartner Group, IDC, Forrester…).
2. Сопоставить каждому из элементов процессной модели набор компонент.
3. Создать список сервисов общего пользования, подобрать компоненты.
4. Минимизировать перечень поставщиков и компонент. Начните с поставщиков. Если возможно, совмещайте функции в рамках одной компоненты — проанализируйте все возможности. Принимайте во внимание «китайские стены» между подразделениями и организациями, соображения безопасности. В случае возникновения вариантов, используйте сначала ограничения безопасности, затем — эффективности.
5. Сформировать порядок использования компонент в рамках процессов с учетом исполнителей, необходимых входов и выходов. Используйте диаграммы.
6. Подготовить текстовое описание.
|
|
|
4. Архитектура информации. Модель данных. Метаданные (онтология)
Функции организации определяют набор тех информационных объектов, с которыми она оперирует. Модель данных определяет их номенклатуру и состав.
Метаданные — информация о данных, их зависимостях, представлении и правилах изменения.
Полная информация о некотором аспекте человеческой деятельности, выраженная в терминах метаданных с помощью концептуальной схемы называется онтологией. Обычно такая схема состоит из иерархической структуры данных, содержащей все необходимые классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области.
На региональном уровне модель данных позволяет описать все информационные источники, необходимые и доступные для принятия решений при помощи ИКТ-системы в рамках каждой из функций регионального управления.
Для описания онтологий предложено несколько формальных языков (нотаций), например, IDEF5 или OWL (web ontology language). Более скромные средства — описание реляционных моделей данных предоставляет стандарт IDEF1X.
Очень важно, чтобы системы, образующие единое информационное пространство региона, имели совместимые онтологии, т.е.:
- у каждого информационного объекта была бы единая (или совместимая) форма представления;
- данные, представляющие одну и ту же характеристику объекта, имели бы единую семантику, т.е. представляли бы ее одинаково, в единой системе отсчета, по одинаковым правилам;
- для каждого из информационных объектов был сформирован единый жизненный цикл в рамках информационного пространства, исключающий конфликты данных. На практике, как правило, это означает, что порождение экземпляров каждого из информационных объектов закреплено за определенной информационной системой, откуда он распространяется при помощи средств интеграции;
- во всех системах использовались единые справочники, классификаторы и система кодификации.
Очень важной задачей является создание и поддержание на уровне Российской Федерации эталонной модели метаданных, определяющих общую структуру и состав тех информационных объектов, которые имеют междисциплинарное значение. К сожалению, такая работа ведется очень медленно и фрагментарно. Сегодня описаны модели и идет работа по созданию средств хранения географических данных (РИПД), модели персональных данных.
5. Технологическая архитектура
Модель технологической инфраструктуры. Базовые технические стандарты
Технологическая инфраструктура включает в себя три подслоя: описание системной среды, описание сетевой среды (инфраструктуры) и профиль стандартов. Первые два, как правило, не вызывают трудностей, поэтому остановимся на третьем.
Описывая систему, необходимо выявить и перечислить те стандарты, протоколы и технические нормативы, соблюдение которых считается обязательным.
Использование стандартов гарантирует, что система будет сохранять работоспособность и не потребует переделки при смене технического окружения, тех систем, подсистем и программных компонент, которые:
- обеспечивают платформу для функционирования данной системы (это, обыкновенно, операционные системы, СУБД, сетевые и аппаратные средства);
- являются источниками и потребителями информации (другие информационные системы того же уровня, связанные с данной в рамках какого-либо административного процесса через стандартизованные интерфейсы);
- функционируют в среде, или «поверх» создаваемой системы (специализированные надстройки, внешние подключаемые компоненты и т.д.).
Говоря о стандартах, необходимо учитывать потенциальную противоречивость различных семейств стандартов, особенно проприетарных, принадлежащих какому-либо производителю или их группе. Чтобы учесть этот фактор, создается т.н. «профиль стандартов» — набор стандартов и/или их частей, применяющийся для решения данной задачи с указанием, для чего и в какой части применяется какой стандарт.
Справочная модель стандартов, принятых в Российской Федерации, — система государственных стандартов ГОСТ. Данная модель может быть расширена включением в нее других общепринятых стандартов и соглашений.
Чтобы создать профиль стандартов, необходимо:
1) определить круг систем, с которыми будет взаимодействовать создаваемая. Не забудьте включить в список стандартные учетные системы: бухгалтерскую, систему документооборота, региональный портал и т.д.;
2) для каждой из этих систем определить требования к стандартам и протоколам информационного обмена, а также к стандартам представления (описания) данных;
3) провести обследование существующей инфраструктуры, в которой будет функционировать решение, получить список стандартов и соглашений, применяемых в ее элементах.
|
|
|
