Программные продукты и системы

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

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

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

Этап разработки информационной модели объекта автоматизации

Практика создания сложных технических систем свидетельствует, что жизненный цикл любой системы от появления замысла ее создания до утилизации включает строго определенные этапы. Состав и содержание этапов жизненного цикла АСУ, в том числе реализуемых по принципам автоматизированных систем поддержки принятия решений (СППР), их составных частей определяются соответствующими нормативными документами. Этапность создания ПО определяется ГОСТ 19.102, АСУ в целом – ГОСТ 34.601 [1–3].

В соответствии с ГОСТ РВ 15.004-2004 и 1210-012-2010, стадиями создания АСУ являются следующие:

-     формирование требований к АСУ;

-     разработка концепции построения АСУ;

-     разработка технического задания;

-     разработка эскизного и технического проектов (данные этапы могут совмещаться);

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

-     ввод системы в действие;

-     сопровождение применения АСУ [4, 5].

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

По нормативным документам, для АСУ первым этапом создания является информационное обследование объекта автоматизации в соответствии с ГОСТ РВ 52333-2006 и ГОСТ РВ 1210-012-2010. Данные ГОСТ в основном обеспечивают получение необходимых для построения информационной модели данных, но обладают существенным недостатком – нацеленностью на методы работы с бумажными носителями информации. Впрочем, этот недостаток характерен для большинства применяемых в настоящее время нормативных документов [6]. Такая ситуация создает существенные проблемы в деятельности разработчиков автоматизированных систем, обусловливая «разрывы» в едином процессе разработки. Суть этих проблем определяется переходами на большинстве этапов создания системы от информации, получаемой в бумажном виде, к электронной и обратно. Наличие таких переходов, определяемых существующими нормативными документами, повышает непроизводительные затраты труда на создание и модернизацию АСУ, увеличивает время создания и количество ошибок.

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

Практика показала, что организованное в полном соответствии с ГОСТ информационное обследование не всегда приводит к положительному результату на начальном этапе разработки АСУ. В соответствии с ГОСТ начинается оно с разработки, заполнения и обработки опросных анкет на бумажных носителях. Для выполнения работ по опросу по местам дислокации органов управления снаряжаются рабочие группы. После завершения их работы производится обработка собранных данных [7, 8].

Практика показала, что организованное в соответствии с ГОСТ информационное обследование характеризуется целым рядом объективных и субъективных проблем, снижающих эффективность указанного процесса:

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

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

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

-     в методическом аппарате, предлагаемом ГОСТ, отсутствуют методики контроля полноты, целостности и непротиворечивости обрабатываемой информации.

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

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

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

Анализ существующих инструментальных сред поддержки автоматизированного проектирования ПО позволяет сделать вывод о том, что весь их спектр можно условно разделить на два основных класса. Каждый из этих классов реализует одну из соответствующих методологий: либо структурного системного анализа и проектирования SADT (structured ana- lysis and design technique), либо объектно-ориентированного проектирования OMT (object modeling technique) и OOSE (object-oriented software engineering). Структурные методологии нашли наибольшее применение при разработке моделей функционирования ОТС и информационных моделей для различных уровней представления, объектно-ориентированные – при разработке ПО АСУ. В то же время обе эти технологии могут параллельно реализовываться средствами наиболее развитых CASE-систем (computer-aided software engineering), к основным из которым можно отнести Oracle CDM, IBM Rational Software, CA ERWin Process & Data Modeler.

С учетом этого процесс разработки программных продуктов при выполнении ряда научно-исследовательских работ в части информационного обследования органов управления был организован на практике с использованием программного инструментария соответствующего назначения. При сопровождении разработки ПО специалистами института использовалась CASE-система построения информационных моделей бизнес-процессов фирмы Sybase Designer. Впрочем, марка и разработчик инструментария в данном случае не имеют значения. Например, в руководящем документе РД IDEF0-2000 предлагается использовать программный продукт Design/IDEF фирмы Meta Software Corporation. Как уже отмечалось, возможности современных продуктов, реализующих CASE-технологии, обеспечивают их «сквозное» использование на всех этапах создания АСУ за счет диаграммных техно- логий, реализующих принципы корректного преобразования информации, перепроектирования и реверсного проектирования. Поэтому главное – не конкретный тип программного продукта, а функциональные возможности используемого инструментария, обес- печивающего полноту и качество описания всех исследуемых процессов и функций, а также удобство в работе.

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

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

Указанные категории специалистов целесообразно объединять в три группы:

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

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

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

Первым шагом на пути централизованного планирования разработки модели информационных ресурсов обследуемой ОТС является создание модели функционирования деятельности ее должностных лиц в ходе организации своей повседневной деятельности.

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

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

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

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

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

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

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

С использованием программных продуктов, реализующих серию стандартов IDEF (ICAM Definition) в рамках технологии CALS (continuous acquisition and lifecycle support), определяющей подходы к информационной поддержке жизненного цикла изделий, процесс проектирования автоматизированной системы был выстроен в соответствующем порядке (см. рисунок).

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

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

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

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

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

Здесь необходимо отметить еще одну важную особенность предлагаемого подхода: получаемую информационную модель можно постепенно наращивать и детализировать, используя начальную структуру как базовую. Например, модель действий лица, принимающего решения, можно сначала описать в самом общем виде: постановка задачи, контроль результата, выбор оптимального плана из представленных, согласование документов и их доведение до исполнителей. Далее методом итераций можно создавать вложенные алгоритмы, обеспечивающие формирование документов. Эти алгоритмы детализируются путем работы с теми, кто их реализует на практике, и так далее до достижения нужной степени детализации. Процесс может быть прерван и продолжен в любое время. Итогом таких работ будет динамическая модель системы класса IDEF2 (Simulation Model Design), а в перспективе и модель оптимизации ее организации IDEF6 (Design Rationale Capture).

Практика применения указанного алгоритма в рамках научно-исследовательских и опытно-конструкторских работ по созданию компонентов АСУ и автоматизированных СППР показала ряд существенных преимуществ:

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

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

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

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

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

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

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

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

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

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

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

Примером может служить разработка многоуровневой модели типовой автоматизированной СППР (см. http://www.swsys.ru/uploaded/image/2019-1/2019-1-dop/ 17.jpg). Кроме уже указанных преимуществ, эти модели, как показала практика, могут успешно использоваться и при проведении научных исследований. Получаемые с применением CASE-технологий модели позволяют не просто корректно описать и изучить существующий процесс управления, но и могут исполь- зоваться для проведения электронных экспериментов с целью выявления возможности совершенствования алгоритмов работы и структуры автоматизируемых органов управления.

Такая интелектуализация в практике промышленной автоматизации является общемировым трендом. Яркий пример – автоматизация в банковской сфере, где внедрение программ-роботов (Robotic Process Automation, RPA) для обслуживания клиентов не автоматизирует рутинные функции отдельных работников, а заменяет часть из них, оптимизируя структуру обслуживания в целом. Подобный процесс получил название фундаментального реинжиниринга автоматизируемой системы (business process reengineering, BPR). Использование электронных информационных моделей в подобном ключе позволяет расширять рамки процесса, переходя от автоматизации системы в состоянии «как есть» к комплексному подходу оптимизации управления.

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

Проблема в том, что не только ГОСТ по инфор- мационному обследованию, но и другие документы, описывающие все последующие этапы работы, ориентированы на бумажные носители информации. Например, ГОСТы серии ЕСПД, в частности, ГОСТ 19.701-90, при описании алгоритмов заставляют переводить описание в «плоский» вид, удалять комментарии, математические выкладки и образцы (шаблоны) документов, приводя к потере существенных элементов диаграмм процессов, теряя большую часть содержания ранее выполненных работ. Справедливости ради стоит отметить, что внедрению процесса электронной документации мешают не только ГОСТ, но и другие организационные документы по разработке АСУ, например, руководства и положения по разработке и сопровождению программной продукции.

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

Заключение

Практика показала, что для реализации современных технологий разработки программных продуктов объективно необходимо предусмотреть механизм использования в этом процессе электронных схем и документов: как минимум – допустить замену опросных листов электронными документами, в идеале – разрешить как альтернативу отчетам в бумажной форме использовать BPM или DFD-диаграммы. Определенные шаги в этом направлении делаются. Так, руководя- щими указаниями РД IDEF 0-2000 «в связи с расширя- ющимся применением информационных технологий и, в частности, CALS-технологий в народном хозяйстве Российской Федерации» описан порядок работы с моделями стандарта IDEF. Рекомендациями по стандартизации Р 50.1.028-2001 разрешено применение для описания функциональных моделей системы управления в нотациях IDEF0. Понятно, что документы класса «рекомендация» по значимости и обязательности использования не дотягивают даже до ГОСТ, не говоря уже о технических регламентах и других обязательных документах (№ 184-ФЗ от 27.12.2002). Более того, разрешена к использованию лишь небольшая часть методов, эффективность которых, кроме всего прочего, снижается в процессе перевода описания модели в бумажный вид. Для разработки автоматизированных СППР такая ситуация – нонсенс. И применяемый в настоящее время ГОСТ 2.051-2013, определяющий порядок разработки электронных документов в составе рабочей конструкторской документации, ее существа не меняет, позволяя формировать документы в виде файлов, в том числе интерактивных, но не модель системы. С введением системы электронного документооборота сделан только первый шаг в направлении применения современных информационных технологий разработки АСУ, остается необходимость продолжать работу в направлении совершенствования документации по организации разработки программных продуктов, разрешения использования нотаций стандартов IDEF до версии 14 и далее по мере их доработки и внедрения в практику [9–12]. Материальная основа для этого создана [13–15], осталось скорректировать документацию в части уточнения перечня рабочей конструкторской документации на АСУ и принципов документирования функциональных, информационных и других моделей.

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

-     установления порядка совершенствования структуры и уточнения функций органов управления по результатам формирования функциональной, информационной и динамических моделей [16, 17], то, что в мировой практике относят к BPR;

-     определения принципов использования средств автоматизированного управления процессом разработки программных продуктов [8];

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

-     расширения возможностей использования ти- повых технологических решений на основе стандар- тов по управлению разработкой PMBoK (Project Management Body of Knowledge) [18–20], управлению бизнес-процессами CBOK (Business Process Management Common Body of Knowledge) и других (разумеется, с учетом ограничений по требованиям информационной безопасности);

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

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

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

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

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

Для реализации указанных преимуществ потребуется доработка организационных документов: ГОСТ, технических регламентов, руководств и положений по разработке программных продуктов. Это требует определенных временных и организационных затрат, но в итоге в области создания автоматизированных СППР обещает существенный рост эффективности.

Литература

1.     Емельянова Н.З., Партыка Т.Л., Попов И.И. Проектирование информационных систем. М.: Форум, ИНФРА-М, 2014. 432 с.

2.     Махрин В.В., Басовский Л.Е. Совершенствование управления промышленным предприятием с учетом современных информационных технологий. Тула: Тульский полиграфист, 2002. 120 с.

3.     Ветошкина М.А. Теоретические аспекты управления информационными ресурсами организации // Современные проблемы управления: матер. Всерос. науч.-практич. конф. Тюмень, 2015. 175 с.

4.     Базанов В.М., Ветошкин В.М., Лялюк И.Н. [и др.]. Автоматизированные системы управления полетами и воздушным движе- нием авиации РФ. М.: Изд-во ВВА им. проф. Н.Е. Жуковского и Ю.А. Гагарина, 2010. 209 c.

5.     Голосовский М.С. Модель жизненного цикла разработки программного обеспечения в рамках научно-исследовательских работ // Автоматизация. Современные технологии. 2014. № 1. С. 43–46.

6.     Андрюшкевич С.К. Построение информационной модели крупномасштабных объектов технологического управления с применением аспектно-ориентированного подхода // Вестн. НГУ: Информ. технологии. 2010. Т. 8. Вып. 3. С. 34–45.

7.     Лукинова О.В. Методологические аспекты управления жизненным циклом информационной системы на основе инструментов функциональной стандартизации // Программные продукты и системы. 2016. № 4. С. 27–35.

8.     Саяпин О.В., Тиханычев О.В., Макарцев Л.В. Об уточнении функций фонда алгоритмов и программ в интересах автоматизации проектирования автоматизированных систем управления войсками // Военная мысль. 2018. № 6. С. 74–79.

9.     Ветошкин В.М. Базы данных. М.: Изд-во ВВИА им. проф. Н.Е. Жуковского, 2005. 388 с.

10.  Bresnahan T. Computerisation and wage dispersion: an analytical reinterpretation. J. Royal Economic Society, 1999, vol. 109, no. 456, pp. 390–415.

11.  Щеглов И.Н., Печатнов Ю.А., Богомолов А.В. Интенсификация разработки автоматизированных систем обучения на основе нейросетевых технологий // Информационные технологии. 2003. № 4. С. 31.

12.  Carol M. Woods, Nan Lin Item response theory with estimation of the latent density using davidian curves. Applied Psychological Measurement, 2009, vol. 33, no. 2, pp. 102–117.

13.  IDEF Users Group. IDEF: framework, draft report (IDEF-U.S.-0001). 1990. URL: http://www.iso.staratel.com/IDEF/BPR/IDEFFAMI. pdf (дата обращения: 13.09.2018).

14.  Mayer R.J. (Ed.). IDEFØ function modeling: A reconstruction of the original Air Force report. 1990. URL: https://ntrs.nasa.gov/ archive/nasa/casi.ntrs.nasa.gov/19920017344.pdf (дата обращения: 13.09.2018).

15.  Menzel C., Mayer R.J., & Edwards D. IDEF3 process descriptions and their semantics. In A. Kuziak, & C. Dagli (Eds.), Intelligent systems in design and manufacturing. NY, ASME Press, 1994, 58 p.

16.  Painter M.K. Modeling with an IDEF perspective: some practical insights. Proc. SME AutoFact 90. Dearborn, MI: Society of Manufacturing Engineers, 1990, 236 p.

17.  Тиханычев О.В., Саяпин О.В., Гахов В.Р. Современные технологии информационного обследования как фактор успеха автоматизации управления // Информатизация и связь. 2013. № 6. С. 90–93.

18.  Ветошкин В.М., Саяпин О.В. Методика построения концептуальной информационной модели организационной системы // Изв. ЮФУ. Технич. науки. 2013. № 3. С. 250–255.

19.  Тиханычев О.В. Теория и практика автоматизации поддержки принятия решений. М.: Эдитус, 2018. 76 с.

20.  Сныткин Т.И., Поляков А.Е., Руденко Г.А. Системное проектирование автоматизированной системы военного назначения с использованием нотаций Archimate 2.1 // Динамика сложных сис- тем – XXI век. 2018. Т. 12. № 2. С. 44–55.

References

1. Emelyanova N.Z., Partyka T.L., Popov I.I. Data Systems Engineering. Moscow, Forum, Infra-M Publ., 2014, 432 p.
2. Makhrin V.V., Basovsky L.E. Improving Industrial Enterprise Management in view of Modern Information Technologies. Tula, Tulsky poligrafist Publ., 2002, 120 p.
3. Vetoshkina M.A. Theoretical aspects of information resources management in a company. Modern Management Problems: Proc. All-Russ. Sci. and Pract. Conf. Tyumen, 2015, 175 p. (in Russ.).
4. Bazanov V.M., Vetoshkin V.M., Lyalyuk I.N. Automated Flight and Air Traffic Control Systems of the Russian Federation. Moscow: VVA n.a. Prof. N.E. Zhukovsky and Yu.A. Gagarin Publ., 2010, 209 p.
5. Golosovsky M.S. A life cycle model of software development in research and development. Automation. Modern Technologies. 2014, no. 1, pp. 43–46 (in Russ.).
6. Аndryushkevich S.K. Creation of an information model of large-scale objects of technological management using an aspect-oriented approach. Bulletin of NSU. Series: Information Technologies. 2010, vol. 8, no. 3, pp. 34–45 (in Russ.).
7. Lukinova O.V. Methodological aspects of information system life cycle management based on functional standardization tools. Software & Systems. 2016, no. 4, pp. 27–35 (in Russ.).
8. Sayapin O.V., Tikhanychev O.V., Makartsev L.V. On the refinement of the functions of the fund of algorithms and programs in the interest of automating design of automated control systems for troops. Military Thought. 2018, no. 6, pp. 74–79 (in Russ.).
9. Vetoshkin V.M. Databases. Moscow, VVIA im. prof. N.E. Zhukovsky Publ., 2005, 388 p.
10. Bresnahan T. Computerisation and wage dispersion: An analytical reinterpretation. The Economic J. of Royal Economic Society. 1999, vol. 109, no. 456, pp. 390–415.
11. Shcheglov I.N., Pechatnov Yu.A., Bogomolov A.V. Intensification of the development of automated learning systems based on neural network technologies. Information Technologies. 2003, no. 4, p. 31 (in Russ.).
12. Woods C.M., Lin N. Item response theory with estimation of the latent density using Davidian curves. Applied Psychological Measurement. 2009, vol. 33, no. 2, pp. 102–117.
13. IDEF Users Group. IDEF: framework, draft report (IDEF-U.S.-0001). 1990. Available at: http://www.iso.staratel.com/IDEF/
    BPR/IDEFFAMI.pdf (accessed September 13, 2018).
14. Mayer R.J. (Ed.). IDEFØ function modeling: A reconstruction of the original Air Force report. 1990. Available at:  https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19920017344.pdf (accessed September 13, 2018).
15. Menzel C., Mayer R.J., Edwards D. IDEF3 Process Descriptions and Their Semantics. A. Kuziak, C. Dagli (Eds.), Intelligent systems in design and manufacturing. NY, ASME Press, 1994, 58 p.
16. Painter M.K. Modeling with an IDEF perspective: some practical insights. Proc. SME AutoFact 90. Dearborn, MI, Society of Manufacturing Engineers Publ., 1990, 236 p.
17. Tikhanychev O.V., Sayapin O.V., Gakhov V.R. Modern information technology survey as a factor in the success of the automation of control. Informatization and Communication. 2013, no. 6, pp. 90–93 (in Russ.).
18. Vetoshkin V.M., Sayapin O.V. Methodology of development of a conceptual information model of an organizational system. Proc. of SFedU. Technical Science. 2013, no. 3, pp. 250–255 (in Russ.).
19. Tikhanychev O.V. Theory and Practice of Decision Support Automation. Мoscow, Editus Publ., 2018, 76 p.
20. Snytkin T.I., Polyakov А.E., Rudenko G.А. System design of an automated military system using Archimate 2.1 Notation. Dynamics of Complex Systems – XXI Century. 2018, no. 2, pp. 44–55 (in Russ.).