On the use of modern technologies of information survey

Tikhanychev Oleg Vasilyevich ORCID: 0000-0003-4759-2931 PhD in Technical Science Deputy Head of Department in the Office of Advanced Development, Technoserv Group  111395, Russia, Moscow, Yunosti str., 13 tow65@yandex.ru Other publications by this author

Введение

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

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

Состав и содержание этапов жизненного цикла АСУ, неотъемлемой часть которого является процесс разработки, в настоящее время определяется соответствующими руководящими документами. Например, этапность создания программного обеспечения АСУ определяется ГОСТ 19.102 ^[1], а автоматизированных систем управления в целом ГОСТ 34.601, для специализированных систем – рядом ведомственных стандартов ^[2-5].

В соответствии с указанными ГОСТ, стадиями создания автоматизированных систем управления являются:

- формирование требований к системе;

- предпроектные исследования, разработка концепции АСУ;

- формализация и детализация требований, разработка технического задания на опытно-конструкторскую работу (ОКР) по созданию системы;

- разработка детальных проектных решений в рамках эскизного и технического проектов в ходе этапов выполнения ОКР;

- разработка опытного образца и рабочей документации, приёмо-сдаточные испытания и сертификация системы;

- производство, ввод системы в эксплуатацию;

- сопровождение АСУ, авторский надзор.

В терминах подходов, реализуемых за рубежом, похожая этапность описывается в рамках модели управления жизненным циклом PLM (Product Lifecycle Management).

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

Во-первых, именно на них задаётся облик создаваемой АСУ, получаемая в ходе их выполнения информационная модель объекта служит фундаментом для разработки концепции автоматизированной системы. Концепции, которая в дальнейшем кардинально не меняется, а лишь уточняется по мере детализации информации.

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

В то же время, в современном состоянии процесса организации информационного обследования существуют значительные проблемы, снижающие его эффективность, и как следствие, качество создаваемой системы в целом ^[6]. Особенно это актуально для разработки программ специального назначения: если при разработке «бытовых» программ – навигаторов, планировщиков и им подобных, разработчик сам, отчасти, является специалистом в предметной области и потенциальным пользователем, то в большинстве случаев разработки специализированных программ он оперирует только тем, что удаётся узнать в результате проведения информационного обследования. И именно недостаточное качество обследования, чаще всего, порождает проблемы в ходе разработки программных систем специального назначения: АСУ управления технологическими процессами, систем военного назначения.

Этими факторами определяется крайняя актуальность поставленной в статье задачи уточнения принципов организации информационного обследования объекта автоматизации.

1.Технологии автоматизации процесса информационного обследования

Считается, что одним из путей повышения эффективности формирования информационной модели автоматизируемой системы является использование современных технологий обследования объектов автоматизации ^[7,8,9].

Для реализации современных технологий информационного обследования, реализующих методы структурного анализа и проектирования SADT (Structured Analysis & Design Technique), в настоящее время разработано достаточно много специализированных программных средств: от полнофункциональных Power Designer, Enterprise Architect и Design/IDEF до простейшего yEd Graph Editor. Часть из них разрешена к использованию в нашей стране ^[10-13], остальные могут быть сертифицированы для применения по мере необходимости ^[14].

Подобные программные системы и методы реализуют концепцию CASE (Computer-Aided Software Engineering), применяемую, в том числе, для построения информационных моделей бизнес-процессов.

С использованием программных продуктов, реализующих CASE-технологии на основе нотаций IDEF (ICAM Definition), в рамках концепции информационной поддержки жизненного цикла изделий CALS (Continuous Acquisition and Lifecycle Support), процесс разработки прикладного программного обеспечения выстраивается в порядке, обеспечивающем оптимизацию создания программного обеспечения АСУ.

Этапность работ с применением нотаций IDEF средств обычно строится по следующему алгоритму (рисунок 1):

1) формирование обобщённой модели процесса функционирования автоматизируемых объектов (диаграммы BPM), описывающей детализированный алгоритм работы должностных лиц;

2) детализация описания потоков данных (DFD-диаграммы);

3) описание ER-диаграммы процессов функционирования автоматизируемых объектов как детальной информационной модели объекта автоматизации, разработка программ;

4) последовательная разработка на основе ER-диаграмм концептуальной, логической и физической моделей базы данных АСУ.

Рисунок 1 - Укрупнённый алгоритм разработки программного обеспечения с применением современных технологий (вариант)

В результате реализации такого алгоритма последовательно формируется «многослойная» модель процессов, выполняемых на объектах автоматизации, учитывающая связи между задачами и применяемые методы их решения. Имеющиеся в составе большинства CASE-продуктов встроенные средства контроля вводимых данных обеспечивают логическую целостность разрабатываемой модели. Более того, мероприятия по ряду этапов удаётся совместить (рисунок 1), сокращая тем самым общее время работы и, как результат, трудозатраты.

Впрочем, для описания моделей процессов могут использоваться и любые другие средства. Например, в терминах UML-моделей (Unified Modelling Language), в нотациях EPC (extended Event Driven Process Chain) системы AEIS (Architecture of Integrated Information Systems), в нотациях FlowChart, или в достаточно популярных сейчас нотациях BPMN (Business Process Model and Notation). Неважен конкретный инструмент или модель, главное – сам подход к описанию функций и процессов в виде электронной модели. Просто средства, реализующие семейство нотаций IDEF несколько более распространены, поэтому рассматривается именно их применение. А проблемы, как показывает опыт применения, у всех перечисленных средств схожи.

2.Проблемные вопросы использования современных технологий информационного обследования

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

- несоответствие результатов применения современных информационных технологий формальным требованиям нормативной документации, определяющей разработку АСУ ^[9]

- запрет на использование инструментальных средств импортной разработки;

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

Впрочем, процесс легитимизации использования инструментальных средств построения информационных моделей постепенно продвигается, позволяя решать первые две из указанных проблем, хотя и не так быстро, как хотелось бы ^[15-22]. В частности, ГОСТ разрешено выполнение конструкторских и эксплуатационных документов АСУ в электронном виде ^[23,24,25].

А вот последняя проблема, во многом, по опыту автора, определяемая сложностью взаимодействия в звене «эксперт предметной области – аналитик», до настоящего времени не решена в полном объёме. Мешает этому целый ряд препятствий.

Препятствия эти, в основном, организационные, субъективного плана:

- постоянный недостаток времени у эксперта, вынужденного во время обследования в полном объёме выполнять свои функциональные обязанности;

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

- аналитик, по этой же совокупности причин, не может выявить ожидания пользователя;

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

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

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

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

2) Последовательное описание алгоритмов работы пользователей. Такой подход заключается в выявлении потребностей в автоматизации процесса от начала работы пользователя: описания управляющих форм, с которых начинается запуск процесса выработки решения (сигналом, командой, документом, событием), построение порядка действий по вариантам, на основе элементарных реакций на развитие событий (функций реагирования), которые осуществляются через входные формы задачи. Эти формы описываются в обобщённом виде, который на сленге программисты иногда называют «мокапы овнера» (Mock up – схема управляющей формы, макет интерфейса). Такой подход, во-многом, совпадает с принципами работы UX/UI-дизайнеров (user experience / user interface).

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

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

Таблица – Сравнительные характеристики существующего и предлагаемых подходов к организации информационного обследования

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

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

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

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

Как показала практика, в том числе выполнение проектов, в которых участвовал лично автор, средства автоматизации построения информационных моделей позволяют (рисунок 2):

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

- последовательно декомпозировать его по «вложенным» задачам;

- поэтапно детализировать каждый его компонент по мере накопления информации;

- описать все компоненты модели с точки зрения используемой информации.

На рисунке 2 отображен верхний, наиболее общий, уровень алгоритма функционирования типового ситуационного центра, выполненный средствами инструментария Power Designer. На рисунке видно, что на многих элементах алгоритма имеется знак «+», обозначающий, что внутри них имеются вложенные элементы, детализирующие описание работы. Данная детализация могла быть проведена в любое время, на любом этапе разработки информационной модели. Кроме процессов, в модели отображены условия выбора, перехода к другому направлению работы, а также условные знаки формируемых программой документов. Все элементы схемы имеют скрытые описания, позволяющие детализировать их свойства или структуру, характеристики используемой информации.

Рисунок 2 – Форма отображения электронной модели автоматизированной СППР ситуационного центра

Эти же средства, обеспечивают, например, загрузку шаблона выходного документа (рисунок 3) и описание входящей в него информации (рисунок 4). Или прикрепление к алгоритму действующего макета входной формы компонента программы (рисунок 5), с указанием структуры входных и выходных данных.

Рисунок 3 - Внешний вид формы описания информационной модели процесса планирования поражения противника с шаблоном формируемого документа, созданной в системе Power Designer

Рисунок 4 – Описание данных, необходимых для формирования выходного документа

Рисунок 5 – Привязка к информационной модели автоматизируемого процесса прототипа формы ввода входных данных

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

1) описать обобщённый алгоритм функционирования автоматизируемого объекта и последовательно его детализировать, как по структуре, так и по содержанию;

2) описать данные, необходимые для формирования документа в свойстве Data компонента Message Format Properties (рисунок 4), а сам шаблон документа загрузить во вкладку Notes того же компонента (рисунок 3);

3) загрузить прототип входной формы программы во вкладку Notes компонента Process Properties (рисунок 5), а состав и формат вводимой информации описать в свойстве Data этого компонента.

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

Sybase PowerDesigner выбран для описания информационной модели ситуационного центра в качестве примера. В самом деле, большинство современных программ, реализующих инструментарий описания информационных моделей: Enterprise Architect, ER/Studio, Designer 2000, Visio Enterprise и другие, обладают аналогичными возможностями. То есть, как показывает проведённый анализ, существующий инструментарий обладает достаточным набором функций, обеспечивающих его использование по любому из предложенных алгоритмов.

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

- принятой на предприятии методологии разработки;

- уровня и принципов взаимодействия с заказчиком;

- сроков разработки и возможности разбить процесс на этапы.

Разумеется, оценка предложенных подходов будет не полной, если она ориентирована только на организацию взаимодействия между экспертами предметной области и аналитиками, упуская последующие связи в звене «аналитик – программист». Наивно полагать, что на этапе информационного обследования будет получено 100% информации, необходимой для создания программного обеспечения АСУ. Это идеальная ситуация, к которой необходимо стремиться, но которая недостижима, как горизонт. Опыт показывает, что по завершению этапа информационного обследования взаимодействие «аналитик – эксперт предметной области» не закончится, потому что абсолютно полное описание процесса сделать физически невозможно по целому ряду объективных и субъективных причин. В том числе и потому, что и сам автоматизируемый процесс меняется, как уточняются и требования к нему. И соответственно, в процессе уточнения будут задействованы все участники процесса разработки: алгоритмисты, программисты, руководство.

Таким образом, цель использования современного инструментария при проведении информационного обследования не в обеспечении строгого разделения этапов разработки АСУ по времени, а в сведении необходимости общения с экспертом на этапе непосредственной разработки программ до минимума, предоставив программисту в качестве исходных данных либо полноценный документ «Постановка задачи» ^[26,27], либо вполне информативную информационную модель объекта автоматизации (рисунок 1). Это делается, чтобы минимизировать отрыв разработчиков на уточнение исходных данных и не требовать от аналитика повторения ранее выполненных работ, умножая простои программистов. Использование предлагаемых подходов или их комбинаций обещает решить указанную проблему, дав аналитику методологию использования современного инструментария обследования объектов автоматизации.

Заключение

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

Методический аппарат описания данных информационного обследования давно и успешно реализован существующими CASE-средствами. Впрочем, и в них ещё есть, что доработать. Например, создать встроенные компоненты экспертной системы, помогающие аналитику описывать сущности информационной модели: не только зафиксировать обязательное наименование компонентов и перечень их входов-выходов, но и в режиме диалога подсказать вопросы к эксперту по количеству объектов или процессов описываемого типа, их сходству и различиям, о внутренних принципах обработки информации каждого процесса. Желательно, с отчуждаемым файлом базы вопросов и связей между ними. Это может существенно повысить функциональные возможности CASE-средств для всех участников в рамках всех рассмотренных подходов к применению.

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

Есть все основания предполагать, что решение сформулированной задачи обеспечит эффективное использование современных технологий информационного обследования и встраивание их в единый целостный процесс разработки: как организационно, так и технически ^[28-31]. Особенно это актуально, как отмечалось ранее, для разработки программ специального назначения, где проблема качества информационного обследования стоит наиболее остро и требует скорейшего решения.

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