Системное проектирование автоматизированных систем, ориентированное «на результат»

Введение

В настоящее время во многих отраслях промышленности происходят масштабные изменения, вызванные требованиями повышения эффективности их функционирования в условиях необходимости преодоления накопившихся проблем, ужесточения конкуренции, повышенных требований со стороны контролирующих органов. Не является исключением и железнодорожный транспорт, для которого необходимость изменений закреплена в проработанной и принятой на правительственном уровне Программе реформирования.

Реализация новых подходов к организации процессов деятельности требует и создания новых автоматизированных систем. Организации и структурные подразделения отрасли, ответственные за результаты выполнения столь серьезных и дорогостоящих задач проектирования и внедрения, оказываются в непростой ситуации. На них, прежде всего, лежит ответственность за четкое и адекватное формулирование требований к создаваемым системам, контроль за их выполнением и соблюдением на всех стадиях и этапах процесса проектирования и внедрения таких систем. Эта задача в современной теории построения сложных информационно-управляющих систем определяется как системное проектирование. Создание системного проекта является, фактически, фазой, на которой уточняются, формализуются и документируются требования к системе со стороны заказчика. Ошибки и неточности, допущенные в системном проекте, могут стать фатальными для всего проекта в целом (что характерно для ранних стадий проектирования). Создание системного проекта позволяет обеспечить соблюдение интересов заказчика, заинтересованного в положительном эффекте от внедряемой системы.

Основные результаты системного проектирования должны содержать:

• требования к функциям системы, включая их интерфейсы;

• схему деления системы и распределения функций между компонентами, с указанием необходимости их автоматизации;

• требования к базам данных, структурам классификаторов;

• технические решения по построению информационного обеспечения, способы и механизмы связи между компонентами;

• необходимые аппаратные ресурсы, требования к системным программным компонентам, количественные характеристики этих компонентов, требования по технологии решения задач;

• ограничения, накладываемые спецификой реализации на процесс разработки — по срокам, выделяемым ресурсам, защите информации и пр.;

• границы проекта с точки зрения организационной структуры предприятия, требования по поддержке разрабатываемой системы.

При этом необходимо отметить ряд особенностей и ограничений, которые существенно влияют на выбор подходов и решений задач системного проектирования. Ниже рассматриваются основные особенности и ограничения в условиях построения систем отраслевого масштаба и процесса реформирования железнодорожного транспорта.

1. Системное проектирование приходится осуществлять в условиях жестких ограничений по срокам выполнения проекта, т.к. его результаты должны предшествовать принятию принципиальных решений по компонентам системы/подсистемам.

2. Процесс системного проектирования происходит в условиях постоянных изменений в составе и структуре будущих бизнес-процессов, вызванных их постепенной переработкой и детализацией в процессе реализации положений реформы.

3. Системные проекты характеризуются значительным масштабом, т.к. должны охватывать как широкий диапазон функций, так и разветвленную иерархию отраслевых структур.

4. В соответствии с поставленными целями системное проектирование подразумевает необходимость увязки нескольких системных аспектов: функциональных требований, информационной среды, организационной структуры, событийных потоков.

Организация системного проектирования АСУ ОАО РЖД

Одним из наиболее сложных системных проектов, выполняемых во ВНИИУП МПС России, является проект по созданию автоматизированной системы управления для ОАО РЖД (АСУ ОАО РЖД). Головной исполнитель работ по проекту — недавно созданный Центр системной интеграции и координации, исполнителем работ является ЗАО «Микротест».

Особенностью использованного в этом проекте подхода является четко сформулированный и контролируемый на всех этапах проекта принцип выполнения работ, исходя из заданного дерева целей отрасли. Это объясняется требованием руководства отрасли обеспечить конкретную и осязаемую отдачу от инвестиций в сферу информационных технологий. Требования целенаправленности, прозрачности и эффективности инвестиций определяют и общую схему выполнения работ: от определенного дерева целей отрасли — к задачам структурных подразделений — расчету экономической и технической эффективности автоматизированного решения этих задач — а затем, к выделению и контролю средств для решения этих задач.

Пример функциональной модели взаимодействия

Рис. 1. Пример функциональной модели взаимодействия

В соответствии с принятыми процедурами системного проектирования, одной из основных работ в составе первой фазы проекта (системного анализа) является построение бизнес-функций системы. Функциональная модель строилась на основе анализа конкретных задач, стоящих перед Департаментами МПС, структурными подразделениями дорожного и линейного уровней (рис. 1). Однако особенность используемого подхода состоит в том, что полученная на этом этапе функциональная модель затем отделялась от конкретной организационной структуры. При этом реальные структурные единицы заменялись псевдоструктурами в соответствии со своей функциональной нагрузкой. Например, такой субъект как Департамент грузовой и коммерческой работы заменялся в модели для конкретной бизнес-функции на «подразделение, информирующее о выполнении плана погрузки/выгрузки». Этим достигались инвариантный характер построенной модели, ее независимость от конкретного распределения функций, столь необходимая при существующей неопределенности будущих бизнес-процессов.

Сводная функциональная модель

Рис. 2. Сводная функциональная модель

 

Сжатые сроки выполнения проекта и нестабильность делового процесса диктуют необходимость функционального моделирования в условиях неполноты исходных данных. Это становится возможным при изменяющейся степени детализации конкретных бизнес-функций. Для системы в целом было создано укрупненное описание бизнес-функций, причем организационные единицы предварительно группировались по хозяйствам (путевое хозяйство, локомотивное хозяйство, кадры и пр.). Укрупненное описание позволило, не отвлекаясь на данной стадии на детали, отследить все системные взаимосвязи компонент.

Вместе с тем, наибольшая степень проработки придавалась пограничным и стыковым процессам, которые описывают взаимодействие различных функциональных блоков и характерны для функциональных границ системы. Это позволяет получить опережающими темпами совокупность требований по интерфейсам компонент системы, традиционно наиболее важных с точки зрения системной интеграции. Кроме того, управляемое изменение степени детализации составляющих функциональной модели позволяет учесть приоритеты, выставленные заказчиком для совокупности решаемых задач.

Создание системного проекта в условиях реформы диктует также необходимость учета в качестве отправной точки положений программы реформирования и сформулированных целей создания ОАО РЖД. Принятые консультантами решения по реинжинирингу бизнес-процессов корректируют функциональную модель, причем этот процесс носит непрерывный характер в силу длительности процесса реформирования, итеративного характера изменений. Инвариантный характер функциональной модели позволяет минимизировать затраты на внесение изменений в проект.

На следующем этапе в рамках системного проекта бизнес-функции детализируются, формируются соответствующие функциональные, информационные и организационные модели. Рассмотрение функциональной модели позволяет выбрать набор автоматизируемых функций будущей системы, реализация которых наиболее эффективна с использованием информационных технологий. Разработанные модели взаимодействия функций объединяются в сводную модель (рис.2).

Важным этапом является анализ информационных связей между автоматизируемыми функциями в сводной модели. Он позволяет построить первоначальную схему деления будущей системы в соответствии с принципом максимальной информационной связности внутри каждой подсистемы и минимального обмена данными между подсистемами. Это позволяет разработать варианты реализации эффективной архитектуры будущей системы. При этом учитываются оценки объемов хранимой и обрабатываемой информации и интенсивности информационного обмена между подсистемами. Принятые решения должны также опираться на передовой отечественный и зарубежный опыт построения систем подобного класса, использовать действенные интеграционные решения. С другой стороны, предложения по архитектуре новой системы обязательно должны, по возможности, использовать существующие решения. Для этого в системном проекте анализируются существующие на железнодорожном транспорте автоматизированные системы, их программное обеспечение и системно-технические платформы.

В качестве результатов работ определяется состав и функции подсистем АСУ ОАО РЖД, их взаимодействие и стратегия интеграции в единый комплекс, соответствующая программная и техническая платформы. Для будущей системы разрабатывается также и стратегия реализации в организационных и стоимостных аспектах. Решения по выбору автоматизируемых функций, реализации подсистем должны быть основаны на системе приоритетов, определяемой руководством отрасли. Эти решения должны быть ориентированы на повышение эффективности деятельности отрасли с помощью информационных технологий, обеспечивать отдачу от сделанных инвестиций. Полученные в системном проекте результаты являются исходной точкой для дальнейшего детального проектирования компонент будущей системы.

Одним из решающих шагов в описанном подходе является принятие решений об эффективном делении функциональной модели на подсистемы, которое опирается на «разрезание» такой модели на сильно связные компоненты. Ниже этот вопрос рассматривается более подробно.

Декомпозиция функциональной модели

Процедура «разрезания» опирается на разработку модели взаимодействия при выполнении бизнес-функций. При этом внимание акцентируется на следующих моментах: действиях, выполняемых системой (блоках обработки информации), протоколах информационного обмена (ПИО) и ключевых параметрах управления (КПУ). В модели раскрывается характер взаимодействия структурных подразделений, выполняющих бизнес-функции на верхнем уровне управления. Модель представляет собой схему взаимодействия и описание операций взаимодействия. Такое взаимодействие означает передачу информации от одного функционального блока к другому. Каждая операция рассматривается с точки зрения выполнения автоматизированной системой и выполнения исполнителем. Исполнителем выполняется процедура, регламентирующая порядок действий субъектов (исполнителей, должностных лиц) для достижения результата операции. Процедура может быть формализованной в некотором документе либо неформальной.

В блок обработки информации включаются функции обработки, выполнение которых предполагается информационной системой. ПИО определяет формат и периодичность информационного обмена между функциональными блоками. Анализ ПИО позволяет унифицировать информационные связи и оценить мощность связи между функциональными блоками. Ключевые параметры управления определяют контрольные параметры выполнения операции, рассчитываемые и накапливаемые информационной системой.

Связи между функциональными блоками могут быть условно разделены на две группы — прямые связи и связи подобия. Прямые связи представляют собой прямой обмен ПИО между блоками. Связи подобия являются косвенными и устанавливаются, если два блока принимают или выдают один и тот же ПИО. Связи подобия выделяются для возможности группировки функций в группы с аналогичными ПИО с тем, чтобы предусмотреть возможность их реализации с помощью типовых программных средств. В этом случае мощность связи будет складываться из двух компонент: мощности прямой связи и мощности связи подобия. Мощность прямой связи определяется через такие характеристики связи, как частота, интенсивность, формализованность и значимость:

Мощность связи подобия принимается как минимальное значение мощностей связей подобных функций:

Итоговая мощность связи учитывает оба компонента с уточняющим коэффициентом для связей подобия (величины коэффициентов и характеристик определяются экспертно):

При наличии сильных связей между функциональными блоками (связей с большой мощностью) целесообразно реализовать эти функции в одном программно-техническом комплексе для обеспечения максимальной надежности функционирования этих связей и минимальной интенсивности информационного обмена между подсистемами. При этом функции с подобными протоколами обмена могут быть реализованы одним типовым программным средством.

На этих положениях базируется подход к декомпозиции функциональной модели. Задача сводится к классической задаче разрезания на взвешенных графах с определением сильно связных компонент.

Качество разрезания определяется отношением суммарной мощности связей между функциями внутри подсистем к суммарной мощности связей в системе:

С использованием этого критерия была проанализирована архитектура существующей автоматизированной системы (рис.3). Результаты анализа представлены в табл. 1.

В таблице присутствуют случаи распределения с низкой оценкой по принятому критерию. При этом интегральные показатели соответствуют разбиению с 83% связей внутри подсистем и 17% связей между подсистемами.

Таблица 1

Оценка качества распределения функциональных блоков по подсистемам в существующей схеме

СистемаИССвязи внутриСвязи с другими системамиКачество распределения
1. Управление движениемОД410,097,233,71041,795,346,25190.75%
ЦМ410,097,233,71041,966,220,25190.72%
2. Маркетинг, экономика, финансыЦЭУ1,037,1665,522,97315.81%
ЦФ20,044,236,95427,621,72999.86%
ЦФТО20,044,227,07283,670,469,65919.33%

3. Инфраструктура

ЦТ1,304,593,470373,098,57177.76%
ЦВ1,304,593,470359,190,57378.41%
ЦП1,499,793,470373,802,57180.05%
ЦШ642,001,470341,723,37165.26%
ЦЭ1,499,743,070373,725,69180.05%
РЖДС90,801,15045,450,62166.64%
4. Управление персоналомЦКадр-22,134,498-
5. Управление пассажирскими перевозкамиЦЛ-2,800,694,769-

Архитектура существующей автоматизируемой системы

Рис3. Архитектура существующей автоматизируемой системы

В системном проекте была выполнена декомпозиция укрупненной функциональной модели с использованием описанного подхода (рис.4). Результаты оценки выполненного разрезания рассчитаны и представлены в табл.2.

Таблица 2

Оценка качества распределения функциональных блоков по подсистемам в предлагаемой схеме

СистемаИССвязи внутриСвязи с другими системамиКачество распределения
1 .Управление грузовыми перевозкамиОД451,288,537,720604,042,24199.87%
ЦМ451,105,797,000957,656,96199.79%
ЦФТО82,199,867,30021,514,829,43179.26%
2.Управление финансамиЦФ-20,071,858,683-

3. У правление затратами

ЦТ1,305,192,700372,499,34177.80%
ЦВ1,305,192,700358,591,34378.45%
ЦП1,500,392,700373,203,34180.08%
цш642,598,300341,126,54165.32%
ЦЭ1,500,339,820373,128,94180.08%
ЦЭУ3,587,9602,972,17954.69%
РЖДС91,397,84044,853,93167.08%
4.Управление персоналомЦКадр-22,134,498-
5.Управление пассажирскими перевозкамиЦЛ-2,800,694,769-

Интегральные показатели данной таблицы соответствуют разбиению с 95% связей внутри подсистем и 5% связей между подсистемами, что подтверждает улучшение качества полученной схемы.

Использование инструментальных средств

Значительный масштаб системного проекта, вовлечение в этот процесс большого количества аналитиков и технологов диктуют необходимость использования на этапах системного анализа и концептуального проектирования мощных инструментальных средств. Их применение гарантирует качество системного проекта, возможность эффективного использования его результатов как на более поздних фазах системного проектирования, так и в смежных проектах.

Предлагаемая схема деления АСУ

Рис.4. Предлагаемая схема деления АСУ

Можно определить требования к таким инструментальным средствам, исходя из определенных в статье особенностей моделирования:

• удобство совместной работы с моделями различных разработчиков и коллективов;

• поддержка всего цикла разработки систем;

• возможность интеграции моделей, отражающих разные взгляды на проектируемую систему — функциональные требования, описание информационной среды, организационную структуру; отсутствие ограничений на последовательность их проработки;

• возможность произвольного изменения степени детальности моделирования отдельных функциональных блоков;

• возможность управления изменениями, поддержка версий функциональной модели.

В качестве инструментального средства выбрана многопользовательская система ARIS, отвечающая выставленным требованиям проектирования.

Заключение

Описываются особенности и основные положения подхода к системному проектированию автоматизированных систем. Успешная реализация системного проекта позволяет получить следующие основные результаты:

• отработанная с руководством отрасли методология управления требованиями к разрабатываемым системам, ориентированная на результат;

• согласованный перечень автоматизируемых бизнес-функций, увязанных с целями информатизации;

• модели выполнения бизнес-функций;

• протоколы информационного взаимодействия автоматизируемых функций;

• оптимизированная схема деления автоматизированной системы;

• предложения по структуре программы информатизации (состав проектов и систем первого уровня);

• интеграционные требования к информационному взаимодействию систем первого уровня.

Описанный в статье подход к системному проектированию автоматизированных систем может быть использован и для других проектов, которые выполняются в условиях сжатых сроков, постоянных изменений в составе и структуре будущих бизнес-процессов, имеют существенный масштаб.










Системы передачи данных

 


Комплексные проектные решения

 


Управление распределенными системами

 


Автоматизированные рабочие места

 


Системы и средства обеспечения безопасности движения

 


Цифровые сети технологической связи

 


Информационные системы управления движением

 


Автоматизированное управление разработками проектов

 




ШуяТекс+, трикотажная одежда Иваново

 


Контрольно-измерительные приборы

 


Площадка "АПТ Телеком", предоставляет услуги в сфере телекоммуникационной интеграции, построения сетей связи по технологии VoIP (Voice over IP), информационной поддержки пользователей оборудования и программного обеспечения Avaya.

 



Copyright (c) 2008, Infotest, Inc.