5. Результаты и выводы

В первой главе приведен критический анализ основных положений «Стратегии социально-экономического развития Дальнего Востока и Байкальского региона на период до 2025 года». Дано обоснование необходимости разработки методологии решения сложной, многокритериальной и многовариантной проблемы развития мультимодальной транспортной сети на Дальнем Востоке и в Байкальском регионе.

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

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

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

Таким образом, в первой главе раскрыты основные аспекты создания методологии проектирования комплексного развития МТС с учетом изменения облика и мощности её элементов.

Согласно предложенной концепции требуется разработать:

1. Систему информационного обеспечения проектирования этапного развития МТС с учетом изменения облика и мощности ее элементов.

2. Методику и аналитический блок принятия решений по изменению облика и мощности МТС в условиях риска и неопределенности.

3. Методику формирования области эффективных альтернатив изменения облика и мощности МТС с учетом неопределенности прогнозов потребных объемов перевозок.

В следующей главе рассматриваются теоретические и практические положения построения системы информационного обеспечения проектирования комплексного развития МТС с учетом изменения облика и мощности её элементов.

2. Разработка системы информационного обеспечения проектирования развития мтс с учетом изменения облика и мощности её элементов

1. Принципы создания системы информационного обеспечения проектирования развития мтс с учетом изменения облика и мощности её элементов

На современном этапе развития мирового производства использование систем информационного обеспечения (информационных систем) в различных сферах жизнедеятельности человечества стремительно расширяется. При этом область их применения охватывает всё более сложные задачи: управление производством и ресурсами, долгосрочное и стратегическое планирование развития производительных сил общества. Процесс создания, внедрения и сопровождения информационных систем, предназначенных для решения этих задач, сложен, трудоёмок и включает в себя следующие основные этапы [69,70,71,72]:

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

• проектирование – описание функциональной структуры системы и информационных взаимосвязей её элементов;

• реализация (программирование) – разработка программного кода подсистем, объединение-соединение подсистем в единое целое;

• тестирование – проверка работы системы;

• внедрение – введение системы в действие;

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

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

При этом этапы анализа и проектирования являются основополагающими. Они характеризуются наибольшей сложностью и трудоёмкостью. Ошибки, допущенные при анализе и проектировании системы, являются критическими для последующих этапов её жизненного цикла. В работе [73] отмечается, что «нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всей работы в целом». «На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях» [72]. Поэтому правильное представление (описание) того, что система должна делать, какие у неё информационные потребности, условия взаимодействия с окружением, функциональная структура и информационные взаимосвязи элементов, является основой успешности жизненного цикла системы и её эффективного функционирования. Для решения этих вопросов при создании информационных систем широко применяются методологии структурного системного анализа.

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

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

Все созданные на данный момент методологии структурного системного анализа основываются на ряде общих принципов [69,70], из которых выделяют два базовых принципа:

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

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

К остальным принципам [69] относятся:

• принцип абстрагирования – выделение существенных аспектов системы и отвлечение от несущественных;

• принцип формализации – строгий методический подход к решению проблемы;

• принцип непротиворечивости – обоснованность и согласованность элементов;

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

Наиболее часто в методологиях структурного системного анализа для разработки информационных систем применяются следующие три средства [69,70]:

• средство функционального моделирования системы – диаграммы потоков данных – DFD (Data Flow Diagrams), либо методология SADT (Structured Analysis and Design Technique);

• средство моделирования данных системы – диаграммы сущность-связь ERD (Entity-Relationship Diagrams);

• средство моделирования поведения системы в зависимости от времени – диаграммы переходов состояний STD (State Transition Diagrams).

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

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

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

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

Все существующие методологии структурного системного анализа условно можно разбить на три группы в зависимости от используемых в них методов и средств функционального моделирования. Первая группа методологий использует методы и технологию DFD в различных нотациях, вторая – методологию SADT, третья – другие методологии. По данным Калянова Г.Н. [70], основанным на анализе 127 существующих CASE-пакетов, процентное соотношение применяемых в них методологий структурного системного анализа следующее: 94 % первой группы, 3 % – второй и 3 % – третьей.

В работах [70,73] Калянов Г.Н. отмечает, что методология SADT успешно применятся там, где хорошо специфицированы и стандартизованы бизнес-процессы. «Например, в Министерстве Обороны США десятки лет существуют четкие должностные инструкции и методики, которые жестко регламентируют деятельность, делают ее высокотехнологичной и ориентированной на бизнес-процесс. В российской действительности с ее слабой типизацией бизнес-процессов, их стихийным появлением и развитием, разумнее ориентироваться на методологию организации и/или реорганизации потоков информации и отношений: для таких задач методологии, основанные на потоковых диаграммах, не просто допустимы, а являются единственно возможными» [70].

В качестве недостатков SADT-диаграмм в сравнении с методологиями, использующими диаграммы потоков данных DFD, Каляновым Г.Н. [70,73] отмечено следующее:

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

• функциональные модели, построенные с применением методологии SADT, практически невозможно согласовать со средствами информационного (диаграммы сущность-связь ERD) и событийного (диаграммы переходов состояний STD) моделирования;

• отсутствие формальных методов преобразования SADT-диаграмм в проектные решения системы обработки информации, в то время, как DFD могут быть легко преобразованы в модели проектирования.

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

Внешняя сущность представляет собой объект вне контекста системы, предполагается, что она не участвует в обработке потоков данных.

Логическая функция – процесс обработки входных и формирования выходных потоков в соответствии с действием, задаваемым её именем. Каждая функция должна иметь уникальный номер для ссылок на неё внутри диаграммы.

Каждая логическая функция может быть детализирована при помощи DFD нижнего уровня или миниспецификации. Миниспецификация описывает логику функции при помощи спецификации процесса и является конечной вершиной иерархии DFD. Она должна выражать логику функции таким образом, чтобы по ней можно было разработать программу по выполнению соответствующего процесса. Решение о завершении детализации процесса и использовании миниспецификации принимается исходя из следующих критериев [69]:

• наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока);

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

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

• возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк).

При детализации функций на DFD должны выполняться следующие правила [69]:

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

• правило нумерации – при детализации функций должна поддерживаться их иерархическая нумерация. Например, функции, детализирующие процесс с номером 2, получают номера 2.1, 2.2, 2.3 и т. д.

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

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

Широкое применение при изображении DFD получили нотации Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson) [70]. Для дальнейшего описания методологии функционального моделирования информационных систем посредством DFD используем нотацию Йодана, элементы которой приведены в табл. 2.1.

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

Таблица 2.1