1

Московский авиационный институт

(национальный исследовательский университет)

Кафедра 302

Проектирование АСОИУ
Конспект лекций для бакалавров

Доцент Романов О.Т.

Москва
2014 г.

1
 2

МОДУЛЬ 1. АСОИУ КАК ОБЪЕКТ ПРОЕКТИРОВАНИЯ

(5-й осенний семестр, 3-й курс)

ГЛАВА 1. АСОИУ КАК ОБЪЕКТ ПРОЕКТИРОВАНИЯ

Лекция 1.

1.1. Классификация АСУ

В настоящее время сложились два направления автоматизации различного рода тех-

нических, экономических и организационно-технических (производственных) систем. Пер-
вое направление осуществляется за счет автоматических систем различных типов, которые
без участия человека выполняют измерение, контроль, регулирование и управление рабо-
той агрегатов, машин, устройств, технологических линий и систем, таких, например, как
транспортные системы, системы воздушного движения и т.п.
Существует четыре группы автоматических систем:
1) измерительно-информационные системы (ИИС);
2) системы автоматического контроля (САК);
3) системы автоматического регулирования (САР);
4) системы автоматического управления (САУ).
Развитие техники и методов управления в экономических, организационно-
экономических и организационно-технических системах, необходимость повышения эф-
фективности их функционирования привели к созданию принципиально нового класса
систем управления – автоматизированных систем. Как известно, в любой системе управ-
ления решаются три основные задачи: 1) сбор и передача информации об управляемом
объекте; 2) обработка информации и принятие решений; 3) выдача управляющего воздей-
ствия на объект управления.
Автоматизированная система управления обеспечивает решение перечисленных за-
дач в комплексе с обязательным участием человека, основываясь на использовании средств
вычислительной техники, экономико-математических методов, прогрессивных изменений
организационной структуры, совершенствования информационной базы объекта автомати-
зации, рационального распределения функций между человеком и техникой.
Дадим развернутое определение этому понятию.
Автоматизированной системой обработки информациии управления называют
систему, состоящую из взаимосвязанных и взаимодействующих в пространстве и во
времени вычислительных и алгоритмических средств, средств связи, источников
информации с метрологическим обеспечением, средств моделирования и отображе-
ния информации, а также средств управления этими процессами, применяемыми

2
 3

для получения продукта заданного качества в определенных условиях функциони-

рования с обязательным участием человека.
По своей структуре, целям и функциям АСОИУ относят к классу больших систем.
Основными признаками АСОИУ, характеризующими ее как большую систему, считают
следующие признаки
I. Иерархичность структуры, т.е. возможность выделения отдельных элементов - под-
систем АСОИУ с устойчивыми пространственно-временными связями, имеющими под-
чиненный характер. Подчиненность выражается как структурным местоположением эле-
ментов подсистем, так и распределением управляющих функций между ними.
II. Адаптация и самоорганизация системы в целом и отдельных ее подсистем. По-
скольку практически нельзясразу создать АСОИУ, удовлетворяющую всем запросам поль-
зователей в будущем, и она должна развиваться по мере изменения характера объекта
управления и целей функционирования, то необходимо заложить в системе возможность ее
совершенствования, т.е. адаптирования и самоорганизации к изменениям внешней среды.
III. Наличие ЭВМ в подсистемах различных рангов для оптимизации принимаемых
решений, преобразования и обработки информации, поступающей из различных источни-
ков.
Широкий спектр систем, попадающих под определение АСОИУ (в дальнейшем, со-
гласно гопредщелению ГОСТа, просто АС), требует их классификации по ряду признаков.
Основными из этих признаков являются следующие признаки:
По уровню управления различают следующие АС:
- межгосударственные
- общегосударственные
- отраслевые и межотраслевые
- предприятий и объединений (фирм)
- подразделений предприятий
- технологических процессов или операций.
По назначению или характеру объектов управления различают следующие АС:
- административные
- общественно-политические
- коммерческие
- оборонные
- транспортные
- производственно-технические и др.
По характеру решаемых задач различают АС:
- стратегические (например, перспективного планирования отрасли или фирмы)
3
 4

- тактические (например, текущего планирования фирмы)

- оперативные
- информационные.
По степени использования выходных результатов различают следующие АС:
- информационно-справочные
- информационно-советующие
- информационно-управляющие.
По структуре различают АС:
- централизованные
- иерархические
- децентрализованные.
По характеру протекающих поцессов в объекте управления различают АС:
-для предприятий и организаций с непрерывным производством;
- для предприятий и организаций с дискретным производством;
- для предприятий и организаций с дискретно-непрерывным производством.
По выполняемым функциям различают три класса АС:
1) АСУП – автоматизированные системы управления производством; 2) АСУТП – автома-
тизированные системы управления технологическим процессом; 3) САПР – системы авто-
матического проектирования.
АСУП создаются как человеко – машинные системы, предназначенные для автомати-
зации управления производственно–хозяйственной деятельностью на предприятии или ка-
кой–либо другой организации. Они представляют собой сложную иерархическую, много-
уровневую систему, состоящую из коллектива работников аппарата управления, комплекса
технических средств (КТС), различных методик и инструкций по управлению объектом,
носителей данных, т.е. документов и технических носителей информации. Как всякая
сложная система, АСУП подразделяется на подсистемы, органические взаимодействия ко-
торых при реализации задач управления обеспечивает достижение основной цели АСУП –
оптимизацию принятия управленческих решений.
АСУП обычно интегрируется как элемент в автоматизированной системе более вы-
сокого уровня организационного управления – отраслевые АС или АС крупными компа-
ниями, возможно межгосударственными или территориально-отраслевыми АС.
Появление второго класса АС – АСУТП связано, во-первых, с развитием автоматиче-
ских устройств и совершенствованием технологического оборудования и, во-вторых, со
значительным усложнением всех функций управления технологическими процессами.
Принципиально важным для создания АСУТП было появление оборудования с числовым
программным управлением (ЧПУ), промышленных роботов, управляемых ЭВМ, обраба-
тывающих центров и т.п.
Под АСУТП в настоящее время понимают человеко-машинную систему, которая при
участии операторов, технологов, диспетчеров, контролеров, в реальном масштабе времени
4
 5

обеспечивает автоматизированное управление процессом изготовления изделий из исход-

ных материалов в соответствии с заданной технологией и установленными технико-
экономическими критериями. К АСУТП в области авиации можно отнести АСУ воздуш-
ным движением в стране в целом или отдельных аэроузлах – регионах страны, а также
управление боевыми операциями, операциями по организации защиты отдельных наибо-
лее важных регионов страны.
По степени охвата управляемого процесса АСУТП делятся на локальные, т.е. управ-
ляющие отдельными станками, агрегатами, линиями, участками, регионами для АСУ воз-
душным движением в зоне аэропорта или взлетной полосы, и комплексные, которые
управляют группами установок, цехами, заводами, имеющими отдельные подсистемы.
По степени участия человека в управлении технологическими процессами различают
информационные, информационно-советующие и управляющие АСУТП.
Третий класс АСУ – САПР, предназначен для реализации автоматизированных про-
цедур проектирования тех или иных объектов различного класса. Под САПР обычно по-
нимают организационно-техническую систему, состоящую из комплекса средств автомати-
зации проектирования, взаимосвязанного с подразделениями проектной организации, и вы-
полняющую автоматизированное проектирование тех или иных объектов. Об этом мы бу-
дем подробно говорить в следующем, т.е. весеннем семестре.
Автоматизированные системы управления рассмотренных классов (АСУП, АСУТП
и САПР) различаются, прежде всего, по виду информации, отражающей только одну опре-
деленную сторону деятельности автоматизированного объекта управления: организации,
предприятия или объединения. Однако на практике реализация функций управления связа-
на с необходимостью получения и переработки всей информации о состоянии управляемо-
го объекта на данный момент времени с целью выработки оптимального решения.
Разрешение противоречия между реализацией локальных функций управления с од-
ной стороны и необходимостью оптимизации функционирования всей автоматизирован-
ной системы в целом с другой стороны привело к созданию так называемых интегрирован-
ных АС – ИАСУ. В ИАСУ совокупно и взаимосвязано взаимодействуют все перечислен-
ные классы АС, используя единую организационную, информационную, техническую и
программно-математическую основу.
Классификационные признаки предприятий, содержащих разные классы АС и их ин-
теграция в ИАСУ, могут быть сведены в следующую таблицу 1.1.
Таблица 1.1
Группа Основные состав- Характер интеграции
предпри- ляющие АСУ
ятий
I 1. САПР Проектирование, технология, эко-
2. АСУТП номико-организационные процессы
3. АСУП
II 1. САПР Проектирование, экономико-
5
 6

2. АСУП организационные процессы

III 1. АСУТП Технология, экономико-
2. АСУП организационные процессы
IV АСУП Экономико-организационные про-
цессы

В ИАСУ научно-производственным объединением можно выделить следующие ав-

томатизированные системы (см. рис. 1):
 САПР, которая конструирует изделия, узлы, детали, разрабатывает требования к ним;
 АСУП, планирующая и координирующая работу всех структурных элементов (подраз-
делений, подсистем) интегрированного автоматизированного производства;
 АСНИ, исследующая готовые и проектируемые образцы изделий на соответствие тре-
бованиям ТЗ;
 АСТПП, проектирующая технологические процессы и управляющие программы для
станков с ЧПУ, технологическую оснастку, инструмент;
 Автоматизированная система организационно-экономического управления, осуществ-
ляющая текущее и оперативное планирование и учет хода производственных процессов
(АСОЭУ);
 Автоматизированная система организационно-технологического управления, осущест-
вляющая управление технологическими объектами управления, состоящими из ком-
плекса производственных модулей, снабженных локальными информационно-
управляющими системами управления (АСУОТ);
 Распределенная система автоматического контроля, осуществляющая контроль качест-
ва функционирования интегрированного автоматизированного производства и качество
изготовления изделий (САК);
 Интегрированная информационно-управляющая система (банк данных интегрирован-
ного автоматизированного производства) – ИУС.
Подсистемы САПР, АСУП, АСНИ объединяют в комплекс верхнего
уровня иерархии интегрированного автоматизированного производства. На
этом верхнем уровне вырабатывается стратегия организационно-
экономического управления, планируется загрузка автоматизированного
производства по номенклатуре и числу изделий, осуществляется подготовка
производства, автоматизировано проектируются изделия. Таким образом,
компоненты АСУП-САПР-АСНИ генерируют своеобразную информацион-
ную среду для всего интегрированного автоматизированного производства,
реализованную в виде верхнего уровня общего распределенного банка дан-
ных системы. Компоненты АСТПП, АСОЭУ, САК, АСУОТ объединяют в
6
 7

комплекс иерархии нижнего уровня интегрированного автоматизированного

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

Лекция 2

1.2. Структуризация АС

1.2.1. Виды структур АС

Проектирование любого объекта, в том числе и АС, требует предварительного анали-

за этого объекта с целью его структуризации.
Структуризация АС – это локализация ее границ и выделение структурных составных
частей. Выделенную по определенному признаку часть АС называют ее подсистемой. Со-
вокупность действий, направленную на достижение определенной цели, называют функ-
цией АС. Выполнение автоматизированной системой управления функций, осуществляе-
мое на действующем объекте управления и обеспечивающее достижение заданных целей,
называют функционированием АС (ГОСТ 24.003-84).
Структура системы управления отражает строение и внутреннюю форму
организации, относительно устойчивые взаимоотношения и взаимосвязи
элементов системы. В автоматизировнной системе, как и любой сложной систе-
ме, можно выделить большое число элементов, свойств, связей между элементами.
В процессе создания и в ходе функционирования АС выделяют различные аспекты ее
внутреннего строения, различая в соответствии с этим разные виды структур системы: ор-
ганизационную, функциональную, информационную, комплекса технических средств и
др.

7
 8

Рис. 1.1. Схема организационной структуры ИАСУ предприятием

Организационная структура АС отражает существование в системе управления объ-

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

жения объектом управления определенной цели. Понятие функции управления переносит-

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

Рис. 1.2. Организационная структура АСУ производственного объеди-

нения

9
 10

Рис. 1.3. Пример организационной структуры АСУ воздушным

движением страны

Связи между элементами функциональной структуры АСОИУ – это потоки ин-

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

10
 11

Рис. 1.4. Типичные функциональные группы дискретного производства

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

ными исследованиями (АСНИ) приведена на рис. 1.5

11
 12

Рис. 1.5. Пример функциональной структуры АСНИ

Если в организационной структуре системы управления существуют структурные

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

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

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

Рис. 1.6. Пример совмещения организационной и функциональной

структур АСУ ВД

Близкие по методам решения или исходной информации задачи управления, решае-

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

13
 14

Если в качестве структурообразующего элемента АСОИУ выступает модуль, то го-

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

1.2.2. Виды обеспечений АСОИУ и их структура

Качество и эффективность функционирования АСОИУ во многом определяются тем,

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

14
 15

Организационное обеспечение АСОИУ представляет собой совокупность средств и

методов, предназначенных для проведения:
1) технико-экономического анализа существующей системы управления;
2) выбора и постановки задач автоматизации управления;
3) организации процесса функционирования объекта управления в условиях АСО-
ИУ.
Оно необходимо для обеспечения взаимодействия персонала АСОИУ с техниче-
скими средствами и между собой в процессе решения задач управления. Структура органи-
зационного обеспечения на примере АСУ ВД представлена на рис. 1.7.
Информационное обеспечение АСОИУ – это совокупность реализованных решений
по объемам, размещению и формам организации информации, циркулирующей в системе
при функционировании. Оно включает нормативно-справочную информацию, необходи-
мые классификаторы используемой информации и их коды, унифицированные документы,
массивы и базы данных, используемых при решении задач АСОИУ. Структура информа-
ционного обеспечения на примере АСУ ВД представлена на рис. 1.8.
Техническое обеспечение АСОИУ – это комплекс технических средств, обеспечиваю-
щий эффективное функционирование системы. Его специфика состоит в необходимости
систематического обслуживания, проверки исправности, профилактики, различных видов
ремонта. Эта специфическая область работы АСОИУУ выполняется специалистами по элек-
тронике и вычислительной технике и не входит в круг обязанностей специалистов по разра-
ботке и эксплуатации АСОИУ. Однако проектирование всего комплекса технических
средств АСОИУ, объединенного в обеспечивающую подсистему, является непосредствен-
ной задачей разработчиков системы. Структура технического обеспечения на примере АСУ
ВД представлена на рис. 1.9.

15
 16

Рис. 1.7. Схема структуры организационного обеспечения АСУ ВД

Рис. 1.8. Схема структуры информационного обеспечения АСУ ВД

16
 17

Рис. 1.9. Схема структуры технического обеспечения АСУ ВД

В плане реализации для конкретных АС технические средства могут об-

разовывать достаточно сложные иерархические структуры на основе по-
строения распределенных вычислительных сетей (РВС). Примеры таких
структур приведены на рис.1.10, 1.11 и 1.12.
Лекция 3
Под программным обеспечением АСОИУпонимают совокупность программ и про-
граммных средств для реализации всего комплекса задач системы на базе применения
средств вычислительной техники, а также соответствующие инструктивно-методические
материалы.
Программное обеспечение обычно разбивают на две части:
- общее программное обеспечение,
- специальное (функциональное) программное обеспечение.
Специальное программное обеспечение в управляющих ЭВМ часто занимает 50-70
% от общего объема памяти программ.
Общее программное обеспечение можно разделить на две крупные компоненты:
- программное обеспечение вычислительного процесса,
-программное обеспечение технологии создания и сопровождения специального про-
граммного обеспечения (см. рис. 1.13).
Специальное программное обеспечение обычно разделяют на три компоненты:
- пакеты прикладных программ,
- программно-ориентированные системы,
- программы организации вычислительного процесса (см. рис. 1.14).

17
 18

Рис. 1.10. Схема структуры РВС для планирования и диспетчеризации

основного производства

Рис. 1.11. Схема структуры распределенной вычислительной системы (РВС)

для координации производства

18
 19

Рис. 1.12. Схема структуры КТС на уровне технологической линии

19
 20

Рис. 1.13. Схема структуры общего программного обеспечения АСОИУ

Рис. 1.14. Схема структуры специального программного обеспечения

АСОИУ

Основные компоненты комплекса программ АСОИУ, определяющие взаимодейст-

вие с внешними объектами, контроль и организацию последовательности решения задач,
могут быть объединены в типовую схему, структура которой слабо связана с содержанием
функциональных задач АСУ и включает несколько (четких) групп программ:
I. Обмена с внешними объектами;
II. Организации вычислительного процесса;
III. Контроля и обеспечения надежности;
20
 21

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

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

Рис. 1.15. Типовая схема взаимосвязей программ АСОИУ

I. Программы обмена с внешними абонентами. Эта группа состоит из программ приема и

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

II. Программы организации вычислительного процесса включают: программу периодиче-

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

21
 22

петчер; местные диспетчеры; программы взаимодействия ЭВМ и процессоров в вычисли-

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

III. Программы контроля обеспечения надежности осуществляют режимы контроля и вос-

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

22
 23

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

23
 24

На основе анализа специализированных сообщений функционального контроля и

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

IV. Программы решения функциональных задач (специальное программное обеспече-

ние) определяются типом и задачами системы управления. Включение функциональных
групп программ производится либо через местный диспетчер (программы S5, S6, S7), либо
непосредственной передачей управления между программами.
Для реализации процесса вычислений в системе оперативная память ЭВМ должна
иметь определенную структуру, предполагающую существование нескольких зон памяти.
В типовой структуре оперативной памяти может быть выделено шесть таких зон:
1) зона программ организации вычислительного процесса;
2) зона входной информации;
3) зона выдаваемой информации;
4) зоны результатов обработки;
5) зоны контроля;
6) зоны хранения программ.
Каждая из этих зон имеет свой объем, причем он может быть как постоянный, так и
динамический, и свою структуру, представленную на рис. 1.16.

24
 25

Рис. 1.16 . Типовая схема структур расширения оперативной памятиоперативной

памяти
Для комплекса программ вычислительной системы, осуществляющей управление
некоторым объектом, можно выделить несколько основных режимов его функционирова-
ния. Такими режимами являются:
1. Режим начального пуска, подготавливающий необходимые исходные дан-
ные для последующего функционирования АСУ в данном режиме.
2. Режим тестового контроля и поиска неисправностей. Его можно разделить
на два подрежима:
25
 26

2.1. С помощью специальных диагностических тестов;

2.2. С помощью контрольных задач являющихся частью комплекса программ,
постоянно функционирующих в рабочем режиме.
3. Режим функционального контроля управляющей системы. Этот режим в
значительной степени связан с режимом начального пуска и должен обеспечивать проверку
безопасности включения рабочих режимов, выявление ограничений на функционирование,
связанных с состоянием внешних объектов, и выдачу обслуживающему персоналу свод-
ных данных, необходимых для принятия решения о включении управляющей системой и
допустимых режимах ее функционирования.
4. Рабочий режим можно разбить на три подрежима в зависимости от нагрузки
вычислительной системы основными функциональными задачами.
В подрежиме отсутствия внешних сообщений и ожидания информации система
включена полностью в объект управления, может с ним взаимодействовать. Она находится
в состоянии дежурства и ожидания, а рабочий режим сводится к готовности принятия об-
работать сообщение и к интенсивному контролю своих элементов и внешних абонентов.
Периодически отображаются результаты контроля и включаются тесты для проверок всех
компонент системы управления. Из программ, непосредственно связанных с решением
функциональных задач, могут включаться, например, программы итогового отображения
состояния системы.
В подрежиме рабочего функционирования при малой и средней загрузки вычислительной
системы включается основное количество программ решения функциональных задач и ус-
танавливается нормальный темп включения периодических программ. При этом может не-
сколько снижаться темп функционального контроля вычислительной системы и внешних
абонентов.
В подрежиме предельной загрузки и перегрузке вычислительной системы, работаю-
щей в реальном времени, рабочий режим должен перестраиваться для решения основных
функциональных задач с допустимыми задержками и потерями входной и выходной ин-
формации. Для рационального использования производительности вычислительной систе-
мы в этих случаях приходиться сокращать объем и темп проверок, снижать в допустимых
пределах темп включения периодических функциональных задач и переходить на решение
ряда функциональных задач по запасным, т.е. «упрощенным» алгоритмам.
Лингвистическое обеспечение АСУ – это совокупность языковых средств формали-
зации естественного языка, построения сочетания информационных единицы при общении
персонала АС в условиях ее функционирования, общения персонала со средствами вычис-
лительной техники (тезаурусы, языки описания и манипулирования данными). Структура
лингвистического обеспечения на примере АСУ ВД приведена на рис. 1.17.

26
 27

Рис. 1.17. Схема структуры лингвистического обеспечения АСУ ВД

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

Рис. 1.18. Схема структуры математического обеспечения АСУ ВД

Под правовым обеспечением АСУ понимают совокупность норм, выраженных в

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

27
 28

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

Рис. 1.19. Схема структуры правового обеспечения АСУ ВД

Эргономическое обеспечение АСОИУ – это совокупность реализованных методов и

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

проектные решения полно отражают все виды обеспечений.

Отсутствие или неполное описание какого-либо вида обеспечения АСОИУ приводит
к ее неэффективному использованию.
Компоненты АСОИУ могут быть сгруппированы в три класса компонент:
1) функциональные компоненты, определяющие, какие функции управления
объектом и в каком объеме выполняет система;
2) организационные компоненты, регламентирующие порядок взаимодействия
структурных подразделений объекта управления в процессе разработки, вне-
дрения и функционирования АСУ;
3) 3) компоненты системы обработки данных, отражающие разные аспекты
внутренней структуры процессов и средств их технической реализации, обес-
печивающих получение, хранение, обработку и передачу информации, необ-
ходимой для автоматизируемого управления объектом управления. Обоб-
щенная схема структуры АСОИУ в виде укрупненной декомпозиции состав-
ляющих ее компонент представлена на рис.1.20.
Особенность этой схемы, кроме ее обобщенного вида, пригодного для описания лю-
бой АС или ее функциональной подсистемы, состоит в том, что в качестве основного прин-
ципа построения система обработки данных АСОИУ принят принцип независимости:

29
 30

30
 31

- компонентов математических моделей от компонентов моделей управления объек-

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

1. Эффективность АС - свойство АС, характеризуемое степенью достиже-

ния целей, поставленных при ее создании. К видам эффективности АС,
относят, например, экономическую, техническую, социальную и др.
2. Совместимость АС - комплексное свойство двух или более АС, характе-
ризуемое их способностью взаимодействовать при функционировании.
Совместимость АС включает техническую, программную, информацион-
ную, организационную, лингвистическую и, при необходимости, метро-
логическую совместимость.
3. Адаптивность АС - способность АС изменяться для сохранения своих
эксплуатационных показателей в заданных пределах при изменениях
внешней среды.
4. Надежность АС - комплексное свойство АС сохранять во времени в ус-
тановленных пределах значения всех параметров, характеризующих спо-
собность АС выполнять свои функции в заданных режимах и условиях
эксплуатации. Надежность АС включает свойства безотказности и ремон-
топригодности АС, а в некоторых случаях и долговечности технических
средств АС.
5. Живучесть АС - свойство АС, характеризуемое способностью выполнять
установленный объем функций в условиях воздействий внешней среды и
отказов компонентов системы в заданных пределах.
6. Помехоустойчивость АС - свойство АС, характеризуемое способностью
выполнять свои функции в условиях воздействия помех, в частности от
электромагнитных полей.
Итак, мы ввели несколько базовых терминов, описали основные со-
ставляющие АСОИУ, отметили основные характеристики этих систем.
Лекция 4
ГЛАВА 2. СРЕДА И НОРМАТИВНАЯ БАЗА
ПРОЕКТИРОВАНИЯ АСОИУ

2.1. Среда создания автоматизированной системы

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

ны. Соответственно, каждый разработчик автоматизированной системы

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

33
 34

Рис. 2.1. Среда создания АСОИУ: 1 — финансирование; 2 - техниче-

ское предложение; 3 - техническое задание; 4 - договорная документация; 5
-результаты
результаты разработки; 6 - организационно-распорядительная
распорядительная докумен-
докуме
тация; 7 - требования пользователей, варианты решений, оценки качества;
8 - обучение; 9 — обсуждение проблем и формулирование рекомендаций по
их устранению; 10 - консультации; 11 — обновление программного обеспе- обесп
чения и документации; 12 - открытая информация об аналогах и прототи-
протот
пах; 13 — покупные инструментальные средства и лицензии на их использиспользо-
вание; 14 - фирменные информационные технологии; 15 - информация о ха-
рактеристиках компонент; 16 —покупные
покупные изделия; 17 —расходные мате-
риалы; 18 — оцениваемые материалы и экспертные закл заключения.
Наряду с представителями высшего руководства, объект автоматиза
автоматизации
представляют в отношениях с разработчиком еще две категории должнос должност-
ных лиц - конечные пользователи и эксплуатационный персонал. Эти со-
трудники не наделены полномочиями принятия ре решений,
шений, но взаимодейству-
взаимодейств
ют с представителями разработчика на фазах разработ
разработки,
ки, внедрения и сопро-
сопр
вождения АСОИУ.
За исключением начальных этапов фазы обоснования создания АС АСО-
ИУ, отношения между разработчиком и заказчиком строятся на возмездной
основе, закладываемой
дываемой договором на создание (внедрение) научно
научно- техниче-
ской продукции, соответствующим требованиям (часть вторая Гражданск
Гражданско-
го кодекса Российской федерациифедерации. [Электронный
Электронный ресурс] URL:
http://www.garant.ru/main
main/10064072-000.htm).
). Финансовые отношения между
основными участниками процес
процесса
са создания АСОИУ, а также между ними и
сторонними контрагентами покапоказаны
заны на рис. 2.1 связью (1).

34
 35

На фазе обоснования создания АСОИУ отношения между заказчиком

и разработчиком заключаются в формулировании и обсуждении техниче-
ского предложения о создании системы (связь 2 на рис. 2.1), составлении и
согласовании технического задания (3) и договорной документации (4).
На фазе разработки автоматизированная система заказчику переда-
ются результаты деятельности разработчика: материалы обследования объ-
екта автоматизации, проектная, рабочая и эксплуатационная документация,
описывающая предлагаемые решения, а также оригинальное программное
обеспечение (5).
На фазе внедрения АСОИУ разработчик совместно с заказчиком орга-
низовывает, проводит и документирует испытания системы, а также состав-
ляет и оформляет организационно-распорядительную документацию (6).
Отношения между представителями разработчика и конечными поль-
зователями создаваемой автоматизированная система поддерживаются на
фазах разработки и внедрения системы. На фазе разработки собираются и
уточняются требования будущих пользователей к конкретным компонентам
создаваемой системы, разъясняются, обсуждаются и оцениваются разраба-
тываемые решения (7). На фазе внедрения разработчик обучает пользовате-
лей выполнению должностных обязанностей в рамках созданной системы
(8).
Отношения между представителями разработчика и эксплуатацион-
ным персоналом АСОИУ поддерживаются на фазе эксплуатации системы.
В частности, на стадии авторского надзора разработчик обсуждает с пред-
ставителями сервисных служб системы возникающие проблемы и форму-
лирует рекомендации по их устранению или - в гарантийных случаях - са-
мостоятельно принимает меры по их ликвидации (9). На стадии сопровож-
дения автоматизированной системы разработчик предоставляет эксплуата-
ционному персоналу необходимые консультации (10), а также передает ему
обновления программного обеспечения и документации (11).
Наряду с разработчиком и заказчиком, в процессе создания АСОИУ
принимают косвенное участие партнеры (контрагенты) - предприятия и ор-
ганизации, поддерживающие деятельность основных участников или снаб-
жающие их необходимыми ресурсами. Среди таких партнеров можно выде-
лить:
■ Источники информации об аналогах и прототипах - наряду с собственным
профессиональным опытом, разработчик активно пользуется информацией о
методах, технологиях и средствах проектирования, а также о результатах
проектной деятельности коллег-разработчиков и внедренческих фирм, пуб-
ликуемых в открытой печати (специальные периодические издания, учебная

35
 36

и научная литература, интернет - публикации), рекламных материалах, нор-

мативно-справочной документации (государственные и ведомственные стан-
дарты, руководящие материалы и т. п.); еще одна категория источников ин-
формации — встречи и обсуждения в рамках научно-практических конфе-
ренций и семинаров, заседаний специализированных научно-технических об-
ществ и рабочих групп, а также участие в качестве экспертов в апробации
аналогичных разработок, созданными коллегами; необходимо отметить, что
из открытых (бесплатных) источников чаще всего удается получить лишь
общую информацию обзорного характера (12); более детальные сведения (в
частности, методики проектирования, рабочая документация и т. п.), как пра-
вило, составляют коммерческую тайну их разработчиков либо предоставля-
ются при условии приобретения соответствующей лицензии.
■ Поставщики инструментальных средств разработки приложений — для
автоматизации предпроектного обследования и повышения эффективности
проектирования, а также для разработки оригинальных проектных решений в
области программного и машинного информационного обеспечения разра-
ботчик приобретает необходимые инструментальные средства (системы про-
граммирования, CASE- и/или RAD-средства, системы проектирования баз
данных и т. п.) и лицензии на их использование у фирм-разработчиков этих
продуктов либо у их законных представителей - дилеров или дистрибьюто-
ров (13); при согласовании условий соответствующих лицензионных со-
глашений необходимо обращать особое внимание на срок действия лицензии
(неограниченный или ограниченный), а также на условия применения про-
дукта - в рассматриваемой ситуации (создание АС для стороннего заказчика)
лицензия должна разрешать разработку продуктов для коммерческого рас-
пространения.
■Поставщики технологий — для использования в АС апробированных фир-
менных решений, предлагаемых ведущими компаниями - производителями
интегрированных систем и программного обеспечения, разработчик должен
приобрести технологии реализации этих решений (14); в таком случае наряду
с необходимыми инструментальными средствами покупатель получает де-
тальное описание методики выполнения всех необходимых проектных и вне-
дренческих действий, готовые решения по организационной структуре объ-
екта автоматизации, алгоритмы и технологические схемы обработки инфор-
мации, образцы входных и выходных документов и видеокадров и другие
элементы высокой степени готовности; довольно часто сотрудникам раз-
работчика предоставляется возможность пройти обучение (повысить профес-
сиональную квалификацию) в фирменном учебном центре поставщика тех-

36
 37

нологии и получить соответствующий сертификат, что существенно повыша-

ет статус специалиста на рынке ИТ-услуг.
■Поставщики компонент — включаемые в состав автоматизированной сис-
темы элементы, выпускаемые как серийная продукция производственно-
технического назначения (вычислительная техника, периферийное и сетевое
оборудование, системное программное обеспечение, пакеты прикладных
программ и т. п.), выбираются разработчиком на основании информации из
фирменной документации, прайс-листов, рекламных материалов и других
источников (15) и рекомендуются заказчику для приобретения непосредст-
венно упоставщиков (16); такая схема взаимодействия позволяет оптимизи-
ровать капитальные затраты на создание системы и обеспечивает эффектив-
ное гарантийное обслуживание покупных изделий.
■Поставщики расходных материалов - на фазе эксплуатации автоматизиро-
ванной системы заказчик периодически закупает расходные материалы (бла-
ночная продукция, бумага и красящие материалы для принтеров, оптические
и иные носители информации и т. п.), необходимые для обеспечения беспе-
ребойного функционирования системы (17); информация о характеристиках
необходимых расходных материалов, их количестве и периодичности попол-
нения запасов приводится разработчиком в документации, описывающей
комплекс технических средств АС.
■Эксперты - если у заказчика нет собственных высококвалифицированных
ИТ-специалистов, то для оценивания предложенных разработчиком решений
он может привлечь в качестве экспертов сторонних консультантов - сотруд-
ников других организаций или физических лиц; экспертиза заключается в
индивидуальном изучении представленных материалов - документации или
программного обеспечения - и формулировании заключения (как правило,
письменного) об их достоинствах и недостатках или в коллегиальном оцени-
вании созданной АС в составе приемочной комиссии (18); в подавляющем
большинстве случаев экспертиза проводится на платной основе.
Представленная на рис. 2.1 наиболее общая схема может модифици-
роваться в зависимости от конкретной ситуации, в которой создается АСО-
ИУ. Наиболее часты изменения в направлениях финансовых и материальных
потоков. В частности, если разработчик не заинтересован в многократном
использовании СУБД и других инструментальных средств разработки и ком-
мерческого тиражирования приложений, то он может предложить заказчику
приобрести их напрямую на условиях однократного применения.
Оборудование может приобретаться заказчиком не только по прямым
договорам в соответствии с рекомендациями разработчика, но и на конкурс-
ной (тендерной) основе. Если в качестве разработчика выступает компания –

37
 38

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

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

2.2. Нормативная база проектирования АСОИУ

Создание автоматизированной системы - сложный, длительный и тру-

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

привести отношения с налоговыми органами, а также отношения с владель-

цами интеллектуальной и иной собственности, используемой при создании
системы.

Нормативная база создания АСОИУ обладает следующими свойства-

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

тивной базы оформляются в виде документов и вводятся в действие орга-

нами (учреждениями), наделенными соответствующими полномочиями;
■ юридическая значимость - срок действия документов, входящих в нор-

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

ми создания автоматизированной системы;
■ непротиворечивость - положения нормативной базы не содержат взаимо-

исключающих положений и указаний;

■ иерархичность - положения нормативной базы, содержащиеся в до-

кументах, введенных в действие нижестоящим органом (учреждением), не

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

толкований и одинаково интерпретируются всеми участниками процесса

создания АСОИУ;
Нормативная база создания автоматизированных систем имеет шес-
тиуровневую иерархическую структуру, представленную в табл.2.1.

Таблица 2.1. Иерархия нормативной базы создания АСОИУ

№ Уровень Характер документа

п/ принятия Вид доку-
п докумен- мента
та
Закон РФ Основополагающий документ, закладывающий
I Государст- принципы и направления государственной полити-
венная Ду-
ки в области информационных и коммуникацион-
ма РФ
ных технологий и смежных аспектах деятельности
Постанов- Подзаконные акты, формирующие основы реали-
II Правитель- ление, зации государственной политики в области инфор-
ство РФ
распоря- мационных и коммуникационных технологий и
жение, по- смежных аспектах деятельности, а также регламен-
ложение и тирующие создание межгосударственных и госу-
т. д. дарственных АСОИУ
39
 40

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

2.2.1.Законы и правительственные подзаконные акты

Основу нормативной базы создания АСОИУ составляетзаконодательство
РФ, точнее, те законы, которые предопределяют стратегические направления
государственной политики в области разработки и использования информа-
ционных и коммуникационных технологий, регламентируют отношения ме-
жду участниками создания АСОИУ, а также отношения между ними и госу-
дарством. Важнейшими среди таких законов можно считать (по состоянию
на февраль 2009 г.) следующие:
■ Федеральный закон «Об информации, информационных техно-
логиях и о защите информации» № 149-ФЗ от 27.07.2006 г., который «ре-
гулирует отношения, возникающие при:
- осуществлении права на поиск, получение, передачу, производство и
распространение информации;
- применении информационных технологий;
- обеспечении защиты информации».
■" Гражданский кодекс РФ (ч. 1-4), который, среди прочего, регули-
рует отношения между участниками создания автоматизированной системы
(в первую очередь — договорные и финансовые), а также права на результа-
ты интеллектуальной деятельности (авторские права), в частности на произ-
40
 41

ведения науки, программы для электронных вычислительных ма-

шин,базыданных, изобретения, полезные модели, промышленные образцы и
секреты производства (ноу-хау).
■Федеральный закон «Об электронной цифровой подписи» № 258-
ФЗ от 08.11.2007 г., который определяет «обеспечение правовых условий
использования электронной цифровой подписи в электронных документах,
при соблюдении которых электронная цифровая подпись в электронном до-
кументе признается равнозначной собственноручной подписи в документе на
бумажном носителе».
■Федеральный закон «О лицензировании отдельных видов дея-
тельности» № 334-ф3 от 06.12.2007 г., который «регулирует отношения,
возникающие между федеральными органами исполнительной власти, орга-
нами исполнительной власти субъектов Российской Федерации, юридиче-
скими лицами и индивидуальными предпринимателями в связи с осуществ-
лением лицензирования отдельных видов деятельности», в том числе:
• деятельность по распространению шифровальных (криптографиче-
ских) средств;
• деятельность по техническому обслуживанию шифровальных криптогра-
фических) средств;
• предоставление услуг в области шифрования информации;
•разработка, производство шифровальных (криптографических) средств, за-
щищенных с использованием шифровальных (криптографических) средств
информационных систем, телекоммуникационных систем;
•деятельность по разработке и (или) производству средств защиты конфи-
денциальной информации;
•деятельность по технической защите конфиденциальной информации.
■Налоговый кодекс РФ (ч. 1 и 2), который, среди прочего, устанавли-
вает порядок введения и уплаты налогов и сборов участниками создания
АСОИУ.
■Трудовой кодекс РФ, который создает «необходимые правовые ус-
ловия для достижения оптимального согласования интересов сторон трудо-
вых отношений, интересов государства», а также обеспечивает «правовое ре-
гулирование трудовых отношений и иных непосредственно связанных с ни-
ми отношений», в том числе в сфере создания и эксплуатации АСОИУ.
Отдельные аспекты создания иэксплуатацииавтоматизированной сис-
темы регламентируются другими законами РФ, в том числе «Основами зако-
нодательства РФ об охране здоровья граждан», «О коммерческой тайне», «О
государственной тайне» и т. д.
Законы РФ имеют рамочный характер. Для создания условий и опре-
деления механизмов их реализации, а также для регламентации создания
межгосударственных и государственных автоматизированных систем вы-
пускаются подзаконные акты Правительства РФ.
В качестве общезначимых документов Правительства РФ, посвящен-
ных созданию автоматизированных систем, можно назвать постановления
«О государственном учете и регистрации баз и банков данных» в редакции
41
 42

от 02.03.2005 № 101, «О лицензировании деятельности по технической за-

щите конфиденциальной информации» от 15.08.2006 № 504 и «О государ-
ственной аккредитации организаций, осуществляющих деятельность в об-
ласти информационных технологий» от 06.11.2007 № 758.
Примерами постановлений о создании общегосударственных автома-
тизированных систем могут служить постановления «Об утверждении под-
программы "Создание системы кадастра недвижимости (2006-2011 гг.)" фе-
деральной целевой программы "Создание автоматизированной системы ве-
дения государственного земельного кадастра и государственного учета объ-
ектов недвижимости (2002-2007 гг.)"» от 13.09.2005 № 560.
Следующий уровень нормативной базы - обязательные для примене-
ния документы, введенные в действие министерствами, государствен-
ными комитетами и федеральными агентствами РФ. Эти документы де-
тализируют и развивают конкретные аспекты создания и эксплуатации авто-
матизированных систем. Особое значение имеют государственные стандар-
ты (ГОСТ), руководящие документы (РД), рекомендации (Р), санитарные
правила и нормативы (СанПиН) и правила охраны труда (ПОТ).
Лекция 5

2.2.2. Государственные стандарты

Согласно ГОСТ 1.1-2002 «Межгосударственная система стандартиза-
ции. Термины и определения», стандартом называется «нормативный доку-
мент, который устанавливает для всеобщего и многократного использования
правила, общие принципы или характеристики, касающиеся различных ви-
дов деятельности или их результатов, и который направлен на достижение
оптимальной степени упорядочения в определенной области».
Государственные стандарты принимаются и вводятся в действие Фе-
деральным агентством по техническому регулированию и метрологии (до
2004 г. - Государственный комитет Российской Федерации по стан-
дартизации и метрологии) и являются обязательными для применения на
всей территории Российской Федерации.
Множество государственных стандартов, регламентирующих практику
создания и сопровождения автоматизированной систем, можно декомпози-
ровать на следующие категории:
■ ГОСТ 24 «Система технической документации на АСУ» и «Еди-
ная система стандартов автоматизированных систем управления».

42
 43

Общий и достаточно серьезный недостаток этих документов - их фор-

мальная ориентация на одну из групп объектов проектирования — автомати-
зированные системы управления (АСУ).
В первой группе стандартов этой категории, введенных в действие в
80-гг. XX в., формулируются основные положения и общие требования как к
самим АС (ГОСТ 24.104-85), так и к отдельным аспектам их создания - в ча-
стности к надежности (ГОСТ 24.701-86), эффективности (ГОСТ 24.702-85) и
типовым проектным решениям (ГОСТ 24.703-85).
Вторую группу составляют стандарты, регламентирующие создание
технической документации на автоматизированную систему; это наиболее
сильно устаревшие документы, не учитывающие возможности современных
технологий разработки и ведения документации.
С точки зрения практикующего разработчика автоматизированной
системы, наибольший интерес представляют ГОСТ 24.104-85 «Автоматизи-
рованные системы управления. Общие требования» (определяющий наибо-
лее универсальные и общезначимые требования к автоматизированных сис-
тем независимо от их масштаба, ведомственной принадлежности и т. п.),
ГОСТ 24.301-80 «Система технической документации на АСУ. Общие требо-
вания к выполнению текстовых документов» (определяющий порядок струк-
туризации и оформления технических документов, содержащих, в основном,
сплошной текст) и ГОСТ 24.303-80 «Система технической документации на
АСУ. Обозначения условные графические технических средств».
■ГОСТ 34, ГОСТ Р 34 «Информационная технология» (табл. П1.2).
Стандарты категории ГОСТ 34 вводились в действие как замена ГОСТ 24,
однако работа осталась незавершенной. Ряд документов (в частности, ГОСТ
34.003-90, 34.201-89, 34.601-90, 34.602-89, 34.603-92) играет важнейшую роль
в процессе проектирования и внедрения АС. Некоторые стандарты (напри-
мер, ГОСТ Р 34.1702.3-92 «Информационная технология. Машинная графи-
ка. Связь ядра графической системы с языком программирования Ада»,
ГОСТ 34.402-91 «Информационная технология. Обмен информацией на кас-
сете с магнитной лентой шириной 3,81 мм (0,15 дюйма) с плотностью записи
4 символа/мм (100 символов/дюйм) способом фазового кодирования при 63
переходах потоков/мм (1600 переходов потока/дюйм)» и другие) регламен-
тируют устаревшие и фактически не применяемые решения.
■ГОСТ 19 «Единая система программной документации» (табл.
П1.3). Наиболее важным и широко применяющимся стандартом этой катего-
рии является ГОСТ 19.701-90 «Единая система программной документации.
Схемы алгоритмов, программ, данных и систем. Условные обозначения и
правила выполнения». К сожалению, большинство стандартов основаны на
практически полностью устаревших подходах к документированию про-
43
 44

граммного обеспечения. Так, ГОСТ 19.506-79 «Единая система про-

граммной документации. Описание языка. Требования к содержанию
и оформлению» регламентирует описание язы- ка программирования, ис-
пользовавшегося для разработки программ; ГОСТ 19.403-79 «Единая
система программной документации. Ведомость держателей подлинников»
предполагает существование института держателей подлинников программ-
ных продуктов, отсутствующее в действующем законодательстве об ав-
торском праве и смежных правах.
Явные противоречия с современной практикой разработки и докумен-
тирования программных продуктов наблюдаются и в других стандартах рас-
сматриваемой категории, что свидетельствует о необходимости их радикаль-
ного пересмотра или замены.
■ГОСТ Р ИСО и ГОСТ Р ИСО/МЭК (табл. П1.4). Государственные
стандарты Российской Федерации, в основу которых положены стандарты
Международной организации по стандартизации (англ. InternationalStandar-
dOrganization- ISO) или Международной электротехнической комиссии
(МЭК). Эти стандарты представляют собой практически дословный перевод
англоязычных оригиналов.Такой подход позволяет унифицировать требова-
ния к объектам стандартизации и в некоторой степени упрощает интеграцию
отечественных предприятий в мировую экономическую систему.
Ннаиболее важное методическое значение для разработчиков любы-
хавтоматизированных системимеют стандарты:
■ ГОСТ Р ИСО/МЭК 12119-2000 «Информационная технология. Пакеты про-

грамм. Требования к качеству и тестирование»;

■ ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы

жизненного цикла программных средств»;

• ГОСТ Р ИСО/МЭК 14764-2002 «Информационная технология. Со-

провождение программных средств»;

• ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология. Уровни це-

лостности систем и программных средств»;

■ ГОСТ Р ИСО/МЭК 15288-2005 «Информационная технология. Системная

инженерия. Процессы жизненного цикла систем»;

• ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс

создания документации пользователя программного средства»;

■ ГОСТ Р ИСО/МЭК 17799-2005 «Информационная технология. Практиче-

ские правила управления информационной безопасностью»;

■ ГОСТ Р ИСО/МЭК 8631-94 «Информационная технология. Программные

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

44
 45

• ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология. Оценка про-

граммной продукции. Характеристики качества и руководства по их приме-
нению»;
■ ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология. Класси-

фикация программных средств»;

■ ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руково-

дство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного

цикла программных средств)»;
• ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология. Руководство

по управлению документированием программного обеспечения».

Государственные стандарты играют важнейшую роль в процессе
создания автоматизированных систем. В ситуации, когда фирменные ме-
тодики создания и внедрения таких систем или их компонент практически
недоступны широкому кругу самостоятельных разработчиков (в силу их
высокой стоимости или по соображениям конкуренции), именно стандар-
ты чаще всего оказываются источником знаний, необходимых для грамот-
ного и эффективного выполнения проектных и внедренческих функций.
Процесс обновления стандартов набирает силу, поэтому мониторинг ката-
лога государственных стандартов, расположенного на официальном сайте
Федерального агентства по техническому регулированию и метрологии
РФ www.gost.ru, позволит своевременно получать информацию о введен-
ных в действие документах и оперативно актуализировать свои профес-
сиональные знания.
2.2.3. Руководящие документы по стандартизации и другие
общегосударственные нормативные документы
Эта группа нормативных документов дополняет и детализирует поло-
жения государственных стандартов применительно к конкретным компонен-
там объектов стандартизации. Так же как и стандарты, РД обязательны для
исполнению для любого вида автоматизированных систем. Изложение со-
держания РД в форме методических указаний делает их незаменимым посо-
бием не только для начинающего, но и для опытного разработчика автомати-
зированных систем. Таким документом были в свое время «Общеотраслевые
руководящие методические материалы по созданию АСУ», которые были
настольной книгой любого специалиста. Ввиду отсутствия общедоступной
справочной и методической литературы, РД используются в качестве спра-
вочных и инструктивно-методических материалов по отдельным аспектам
создания автоматизированных систем.

45
 46

Наряду с руководящими документами, Федеральным агентством

по техническому регулированию и метрологии РФ и предшествовавшими
ему учреждениями выпущены так называемые руководствагруппы Р 50, ко-
торые формально не считаются обязательными к применению, но фак-
тически играют роль руководящих документов. К ним относятся руководя-
щие документы РД 50 и рекомендациии Р 50.
Наиболее важными и чаще всего используемыми среди них можно
признать:
■ РД 50-34.698-90. Комплекс стандартов и руководящих документов на ав-

томатизированные системы. Автоматизированные системы. Требования к

содержанию документов.
■ РД 50-680-88. Методические указания. Автоматизированные системы.
Основные положения.
■ РД 50-682-89. Комплекс стандартов и руководящих документов на авто-

матизированные системы. Общие положения.

■ РД 50-613-86. Методические указания по внедрению и применению
ГОСТ 6.10.4-84. «УСД. Придание юридической силы документам на ма-
шинном носителе и машинограмме, создаваемым средствами вы-
числительной техники. Основные положения».
■ Р 50-34.126-92. Информационная технология. Правила проведения работ

при создании автоматизированных систем.

Комплекс руководящих документов, которым должны соответство-
вать решения по защите автоматизированной системы от несанкциониро-
ванного доступа к информации и другим аспектам информационной безо-
пасности, разработан и введен в действие Федеральной службой РФ по тех-
ническому и экспортному контролю, ранее называвшейся «Гостехкомиссия
РФ». Содержащиеся в этих документах указания обязательны для исполне-
ния при создании АСОИУ, в которых предъявляются особые требования к
обеспечению информационной безопасности. В первую очередь они приме-
няются в системах обработки информации, составляющей государственную,
военную и т. п. тайну.
Еще одна группа документов регламентирует обеспечение безопасно-
сти жизнедеятельности участников создания и эксплуатации АСОИУ. Сани-
тарные правила и нормативы (СанПиН) 2.2.2/2.4.1340-03 «Гигиенические
требования к персональным электронно-вычислительным машинам и орга-
низация работ» и изменения к ним 2.2.2/2.4.2198-07 определяют медико-
биологические основы организации человеко-машинного взаимодействия.
Они играют важнейшую роль при создании технического и эргономического
обеспечения АСОИУ, а также при формировании временных регламентов
решения функциональных и вспомогательных (обеспечивающих) задач
АСОИУ. Ввод в действие правил охраны труда (ПОТ) нацелен на предупре-
46
 47

ждение и предотвращение производственного травматизма в процессе соз-

дания и эксплуатации АСОИУ. Необходимо отметить, что до настоящего
времени не выработаны специфические охранительные нормы для таких ви-
дов деятельности, как написание и отладка программных продуктов, работа
оператора ЭВМ и т. п.
2.2.4. Ведомственные нормативные документы
В дополнение к нормативным документам общегосударственного
масштаба, многие министерства и ведомства (например, министерства обо-
роны или внутренних дел), а также отдельные корпорации и предприятия
(ОАО «Газпром», ОАО «РЖД» и многие другие) вводят в действие собст-
венные нормативные акты, регламентирующие практику создания и экс-
плуатации АС на подведомственных объектах. Отличительными особенно-
стями таких документов можно считать:
■ ограниченность сферы применения - любой ведомственный документ

обязателен для исполнения только на предприятиях (в учреждениях), струк-

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

щает и делает обязательной для применения исторически сложившуюся

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

содержат информацию (служебную, коммерческую,knowhow и т. д.), разгла-

шение которой способно нанести вред непосредственно объекту автоматиза-
ции или ведомству в целом; по этой причине многие такие документы имеют
гриф «Для служебного пользования» или другой атрибут секретности и не-
доступны для свободного ознакомления.
Наиболее распространенная форма ведомственного нормативного до-
кумента - отраслевой стандарт (ОСТ), разрабатываемый в случае от-
сутствия на объект стандартизации ГОСТ Р или при необходимости ус-
тановления требований, превышающих установленные ГОСТ Р. Порядок
разработки ОСТ устанавливается отраслевым органом государственного или
ведомственного управления. В качестве примера можно привести отраслевой
стандарт Министерства образования РФ ОСТ ВШ 01.001.94 «Информацион-
ные технологии в высшей школе. Общие положения».
В свою очередь, отраслевой руководящий документ чаще всего кон-
кретизирует практику применения государственного или отраслевого стан-
дарта, или иного нормативного акта в специфических условиях конкретного
ведомства. Отраслевые документы могут иметь форму методических указа-
47
 48

ний, типового положения, типовой инструкции и т. п. В качестве примера

можно привести отраслевой руководящий документ Государственного та-
моженного комитета РФ РД 77.02-99(2) «Порядок сбора, контроля, передачи
и обработки первичной таможенной информации для формирования баз
данных на всех уровнях таможенной службы».
О существовании закрытых ведомственных документов, требования
которых необходимо учитывать при создании АСОИУ, разработчик чаще
всего узнает из предварительных бесед с потенциальным заказчиком или на
основании предыдущего профессионального опыта. Как правило, руко-
водство ведомства крайне неохотно раскрывает служебную информацию
сторонним разработчикам и предпочитает сотрудничать с организациями,
обладающими необходимыми полномочиями и допусками. Поэтому шансы
заключения договора на создание АСОИУ в подобной ситуации невелики.
Последний, наиболее низкий уровень нормативной базы создания
АСОИУ - внутренние документы предприятия-участника этого процесса.
Наряду с традиционными документами (приказами и распоряжениями), ус-
танавливающими регламенты выполнения конкретных работ, должностные
обязанности исполнителей, распределение заданий между ними и т. п., осо-
бое значение имеет разработка и ввод в действие так называемых стандар-
тов предприятия (СТП). В частности, такие стандарты могут устанавливать
единый и обязательный для всех сотрудников организации-разработчика по-
рядок применения инструментальных средств разработки ПО (в том числе
правила наименования и форматирования объектов, соглашения о структуре
межмодульного интерфейса, структурные и цветовые решения при проекти-
ровании документов и видеокадров и т. п.), унифицировать процессы доку-
ментирования проектных решений, нормировать отладку программных про-
дуктов и регламентировать иные вопросы практической деятельности раз-
работчика АСОИУ. Применение стандартов предприятия упорядочивает
проектный процесс, облегчает совместную деятельность исполнителей и уп-
рощает их взаимозаменяемость, а также существенно снижает трудоемкость
выполняемых действий и операций.
Положения нормативной базы создания АСОИУ обязательны для ис-
полнения каждым участником этого процесса. Незнание отдельных законов,
стандартов или нормативов не освобождает от ответственности за их неис-
полнение или за неполное (неправильное) применение. Любая норма, регла-
ментирующая процесс создания АСОИУ, должна исполняться в полном объ-
еме независимо от ее явного упоминания в двух- или многостороннем дого-
воре между участниками этого процесса. Наблюдающееся в последние годы
все более активное обновление нормативной базы создания АСОИУ застав-
ляет разработчиков оперативно отслеживать ввод в действие новых законо-
дательных и подзаконных актов и принимать меры для их грамотного при-
менения в своей практической деятельности.
48
 49

Лекция 6

ГЛАВА 3. РЕГЛАМЕНТАЦИЯ ПОРЯДКА ПРОЕКТИРОВАНИЯ АСУОИ

3.1. Общий порядок проектирования АСОИУ

Создание новых и развитие действующих АСОИУ осуществляется в соответствии с

государственными, общеотраслевыми и отраслевыми методическими материалами, обяза-
тельными в части состава, содержания и порядка выполнения работ для всех организаций,
разрабатывающих и внедряющих такие системы. Эти документы отразили в себе большой
опыт по проектированию АСОИУ.
Как правило, разработчиками АСОИУ крупными производственными
объединениями и организациями непроизводственного назначения являются
специализированные научно-исследовательские и проектные институты. За-
казчиком таких работ являются те объединения и организации, для которых
создаются эти системы. В некоторых случаях, объединение, предприятие или
организация разрабатывает АСОИУ самостоятельно, используя для этого
специально созданное подразделение, как правило, в составе вычислительно-
го центра. В этом случае, оно само получает права и обязанности разработ-
чика АСОИУ и несет всю полную ответственность за качество выполненных
проектных работ.Работы по созданию новых и развитию существующих сис-
тем, осуществляются по стадиям и этапам. В общем случае их состав опреде-
лен ГОСТ 34.601-90 и приведен в таблице 3.1.
В зависимости от специфики создаваемой АСОИУ и условий ее разработки, допуска-
ется исключить стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объе-
динять стадии «Технический проект» и «Рабочая документация» в одну стадию - «Техно-
рабочий проект». Можно также выполнять отдельные этапы работы до завершения пред-
шествующих стадий, параллельное во времени выполнение этапов работ, включение новых
этапов работ.Конкретный состав выполняемых стадий и этапов устанавливается в техниче-
ском задании на систему и в договорах между участниками работ по ее созданию.

Таблица 3.1. Стадии и этапы создания АСОИУ.

Стадии Этапы
1. Формирова- 1.1. Обследование объекта и обоснование необходимости создания
ние требова- АСОИУ.
ний к АСО- 1.2. Формирование требований пользователя АСОИУ.
1.3. Оформление отчета о выполненной работе и заявки на разработку
ИУ АСОИУ (тактико-технического задания).

49
 50

2. Разработка 2.1. Изучение объекта автоматизации.

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

3. Техническое 3.1. Разработка и утверждение технического задания (ТЗ).

задание
4. Эскизный 4.1. Разработка предварительных проектных решений по системе и ее
проект частям.
4.2. Разработка документации на АСОИУ и ее части.

5. Технический 5.1. Разработка проектных решений по системе и ее частям.

проект 5.2. Разработка документации на систему и ее части.
5.3. Разработка и оформление документации на поставку изделий для
комплектования АСОИУ и (или) технических требований (техниче-
ских заданий) на их разработку.
5.4. Разработка заданий на проектирование в смежных частях проекта
объекта автоматизации.

6. Рабочая до- 6.1. Разработка рабочей документации на систему и ее части.

кументация 6.2. Разработка и адаптация программ.
7. Ввод в дей- 7.1 Подготовка объекта автоматизации к вводу АСОИУ в действие.
ствие 7.2 Подготовка персонала
7.3 Комплектация системы поставляемыми изделиями (программными
и техническими средствами, программно-техническими комплексами,
информационными изделиями).
7.4 Строительно-монтажные работы
7.5 Пуско-наладочные работы.
7.6 Проведение предварительных испытаний.
7.7 Проведение опытной эксплуатации.
7.8 Проведение приемочных испытаний.

8. Сопровож- 8.1. Выполнение работ в соответствии с гарантийными обязательства-

дение АСУ ми.
8.2. Послегарантийное обслуживание системы.

3.2. Содержание работ предпроектных стадий создания АСОИУ.

Стадии «Формирование требований к АСОИУ», «Разработка концепции

АСОИУ» и «Техническое задание» относят к предпроектным стадиям созда-
ния систем. Основная цель их выполнения – обосновать необходимость соз-
дания АСОИУ, сформулировать требования, которым она должна удовлетво-
рять, определить ее структуру, состав и последовательность выполняемых
работ.
Первая стадия - «Формирование требований к АСОИУ», состоит из трех
этапов.
50
 51

На этапе 1.1. «Обследование объекта и обоснование необходимости

создания АСУ» выполняют в общем случае следующие работы:

1. Сбор информации о ранее выполненных разработках по созданию АСО-

ИУ аналогичными объектами;
2. Сбор данных об объекте автоматизации и осуществляемых видах его дея-
тельности;
3. Оценка качества функционирования объекта и осуществляемых им видов
деятельности, выявление проблем, решение которых возможно средства-
ми автоматизации;
4. Оценка (технико-экономической, социальной и т.п.) целесообразности
создания АСОИУ.
Этап 1.2. «Формирование требований пользователя АСОИУ» включает
две группы работ.
Первая группа состоит из работ, связанных с подготовкой исходных
данных для формирования требований к АСОИУ. К таким данным относят:
описание существующей информационной системы объекта автоматизации,
выявление ее недостатков и обоснование необходимости совершенствования,
цели, критерии и ограничения создания системы, функции и задачи созда-
ваемой АСОИУ и т.д.
Вторая группа работ связана с формировкой и оформлением требований
пользователя АСОИУ. Эта группа работ во многом опирается на результаты,
получаемые в процессе выполнения работ предыдущей группы.
Этап 1.3. «Оформление отчета о выполненной работе и заявки на разра-
ботку АСОИУ (тактико-технического задания)» является завершающим для
стадии «Формирование требований к АСОИУ». Этот этап заканчивается со-
ставлением отчета по ГОСТ 7.32 и заявкой на разработку системы.
В общем случае основная часть отчета состоит из восьми разделов (РД–
50–34.698-90).
1) Раздел «Характеристика объектов и результатов его функционирования»
содержит общую характеристику объекта, включающую требования к объек-
ту со стороны вышестоящей организации и (или) характер взаимодействия с
внешней средой, организационную структуру объекта, требования к объему,
номенклатуре и качеству результатов его функционирования.
2) Раздел «Описание существующей информационной системы» содержит
сведения о функциональной и информационной структуре системы, ее каче-
ственных и количественных характеристик, показывающих взаимодействие
ее компонентов в процессе функционирования. К таким характеристикам от-
носят номенклатуру и объемы обрабатываемой информации, сроки и перио-
дичность обработки, применяемые формальные методы решения задач и ис-
пользуемые технические средства.
51
 52

3) В разделе «Описание недостатков существующей информационной систе-

мы» приводят результаты диагностического анализа системы. Его цель –
оценить качество функционирования и организационно-технологический
уровень системы, с точки зрения обеспечения объектом управления постав-
ленных перед ним целей и задач, выявить недостатки в организации и техно-
логии функционирования информационных процессов, определить степень
влияния этих недостатков на качество функционирования системы.
4) В разделе «Обоснование необходимости совершенствования информаци-
онной системы объекта» показывают возможность повышения показателей
функционирования объекта до уровня требуемых, за счет совершенствования
его информационной системы путем создания АСОИУ.
5) Раздел «Цели, критерии и ограничения создания АСОИУ» содержит сле-
дующее:
- формулировки производственно-хозяйственных, научно-технических, эко-
номических и др. целей создания АСОИУ,
- критерии, позволяющие оценивать степень достижения этих целей,
- характеристику ограничений по созданию системы (временные, стоимост-
ные, трудовые и т.д.).
6) Раздел «Функции и задачи создаваемой АСОИУ» содержит обоснование
выбора перечня автоматизируемых функций и комплексов задач с указанием
очередности их внедрения, требования к характеристикам реализации функ-
ций и задач в соответствии с общими техническими требованиями к АСОИУ
конкретного вида.
7) Раздел «Ожидаемые технико-экономические результаты создания АСО-
ИУ» содержит следующее:
- перечень основных источников экономической эффективности, получае-
мых в результате создания системы,
- оценку ожидаемых изменений основных технико-экономических и соци-
альных показателей производственно-хозяйственной деятельности объекта,
- оценку ожидаемых затрат на создание и эксплуатацию АСОИУ, с распре-
делением их по очереди создания системы и по годам,
- ожидаемые обобщающие показатели экономической эффективности АСО-
ИУ.
8) Раздел «Выводы и предложения» - это завершающий раздел отчета по ста-
дии «Формирование требований к АСОИУ». Этот раздел рекомендуется раз-
делить на три подраздела.
8.1. Подраздел «Выводы о производственно-хозяйственной необходи-
мости и технико-экономической целесообразности создания АСОИУ» со-
держит сопоставление ожидаемых результатов создания системы с установ-

52
 53

ленными целями, принципиальное решение о ее создании (положительное

или отрицательное).
8.2. Подраздел «Предложения по совершенствованию организации и
технологии процесса деятельности» содержит предложения по совершенст-
вованию производственно-хозяйственной деятельности объекта, организаци-
онной и функциональной структур системы управления, методов обработки
информации, видов обеспечений АСОИУ.
8.3. Подраздел «Рекомендации по созданию АСОИУ» содержит сле-
дующие рекомендации:
- по виду создаваемой АСОИУ и ее совместимости с другими автома-
тизированными системами,
- по организационной и функциональной структуре, составу и характе-
ристикам подсистем и видов обеспечения,
- по использованию технических средств и организации разработки и
внедрения АСОИУ,
- по рациональному использованию имеющихся и привлекающихся ре-
сурсов.
При положительном заключении о целесообразности создания АСОИУ
составляется заявка на ее разработку. Заявка составляется в произвольной
форме и содержит предложения организации-пользователя к организации-
разработчику на проведение работ по созданию системы и его требования к
системе, условия и ресурсы на ее создание.
Перейдем ко второй стадии – «Разработка концепции АСОИУ». Эта ста-
дия в общем случае состоит из четырех этапов.
На этапе 2.1. «Изучение объекта» организация - разработчик по специ-
альной программе проводит детальное изучение объекта автоматизации с це-
лью:
1) выявления перечня, содержания и периодичности выполнения
функций и задач управления на всех уровнях структуры объекта и его систе-
мы управления, по каждому подразделению и отдельным должностным ли-
цам;
2) получения количественных характеристик системы информацион-
ных потоков между подразделениями и отдельными должностными лицами
системы управления;
3) разработки формальных и неформальных методов обработки ин-
формации и принятия решений в системе управления, прав и обязанностей
должностных лиц.
На этапе 2.2. «Проведение необходимых научно-исследовательских
работ» организация-разработчик выполняет необходимые научно-
исследовательские работы, связанные с поиском путей и оценкой возможно-
сти реализации требований пользователя.
На этапе 2.3. «Разработка вариантов концепции АСОИУ и выбор вариан-
та концепции АСОИУ, удовлетворяющего требованиям пользователя» орга-
53
 54

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

бот:
1) разрабатывает альтернативные варианты концепции создаваемой системы,
то есть определяются варианты облика и тех принципов и руководящих идей,
которые могут быть положены в ее основу;
2) разрабатывает планы реализации каждого альтернативного варианта и дает
оценку необходимых для этого ресурсов;
3) дает оценку преимуществ и недостатков каждого варианта, осуществляет
выбор оптимального рационального варианта;
4) определяет требования, гарантирующие качество функционирования вы-
бранного варианта АСОИУ, условия приемки системы.

На этапе 2.4. «Оформление отчета о выполненной работе» организа-

ция-разработчик подготавливает и оформляет отчет согласно требованиям
ГОСТ 7.32. В основной части этого отчета приводят:
1) описание результатов изучения объекта автоматизации;
2) описание и оценку преимуществ и недостатков разработанных альтер-
нативных вариантов концепции создаваемой АСОИУ, их сопоставительный
анализ, на предмет удовлетворения требованиям пользователя;
3) обоснование выбора оптимального рационального варианта концепции
и описание предлагаемой АСОИУ;
4) ожидаемые результаты и эффективность реализации выбранного вари-
анта, ориентировочный план его реализации;
5) необходимые затраты ресурсов и требования, гарантирующие качество
АСОИУ;
6) условия приемки системы.

Лекция 7

Стадия 3 – «Техническое задание» - это очень важная стадия. Она со-

стоит из одного этапа.
На этапе 3.1. «Разработка и утверждение технического задания на созда-
ние АСОИУ» проводят разработку, оформление, согласование и утверждение
технического задания на разрабатываемую систему.
Техническое задание (ТЗ) разрабатывают и оформляют в соответствии с
ГОСТ 34.602-89. Оно является основным документом, определяющим требо-
вания и порядок создания АСОИУ.В соответствии с ним проводится разра-
ботка системы и ее приемка при вводе в действие.
ТЗ на АСОИУв общем случае содержит следующие 9 разделов, которые
могут быть разделены на подразделы:
1) общие сведения;
54
 55

2)назначение и цели создания (развития) системы;

3)характеристика объектов автоматизации;
4)требования к системе;
5)состав и содержание работ по созданию системы;
6)порядок контроля и приемки системы;
7)требования к составу и содержанию работ по подготовке объекта ав-
томатизации к вводу системы в действие;
8) требования к документированию;
9) источники разработки.
1) В разделе «Общие сведения» указывают: полное наименование
системы и ее условное обозначение; шифр темы или договора; наименование
организаций-разработчиков и заказчика системы; основание для выполнения
работ и сроки их выполнения; сведения об источниках и порядке финансиро-
вания работ по созданию системы; порядок оформления и предъявления за-
казчику результатов работы по созданию системы.
2) В разделе «Назначение и цели создания (развития) системы»
указывают вид автоматизируемой деятельности и перечень объектов автома-
тизации, на которых предполагается ее использование, приводят наименова-
ния и требуемые значения тех показателей объекта автоматизации (техниче-
ских, экономических и др.), которые должны быть достигнуты в результате
создания АСОИУ, указывают критерии оценки достижения целей.
3) В разделе «Характеристики объекта автоматизации» приво-
дят краткие сведения об объекте автоматизации со ссылкой на документы,
содержащие такую информацию, а также сведения об условиях эксплуатации
объекта автоматизации и характеристиках окружающей среды.
4) Раздел «Требования к системе» состоит из следующих подразделов:
1) требования к системе в целом; 2) требования к функциям (задачам), вы-
полняемым системой; 3) требования к видам обеспечения.
4.1. В подразделе «Требования к системе в целом» указывают требо-
вания к структуре и функционированию системы, численности и квалифика-
ции персонала и режиму его работы, безопасности и надежности работы, эр-
гономические требования, требования по сохранности информации при ава-
риях, другие специальные требования, обусловленные особенностями и ус-
ловиями функционирования системы.
4.2. В подразделе «Требования к функциям (задачам), выполняемым
системой» приводят:
- по каждой подсистеме перечень функций, задач и их комплексов (в
том числе обеспечивающих взаимодействие частей системы), подлежащих
автоматизации;
- временной регламент реализации каждой функции (задачи или ком-
плекса задач);
55
 56

- требования к качеству реализации каждой функции (задачи или ком-

плекса задач), к форме представления выходной информации, характеристи-
ки необходимой точности и времени выполнения, требования одновременно-
сти выполнения группы функций, достоверности выдачи результатов;
- перечень и критерии отказов для каждой функции, по которой зада-
ются требования по надежности.
4.3. В подразделе «Требования по видам обеспечения» в зависимости
от вида системы приводят требования к математическому, информационно-
му, лингвистическому, программному и другим видам обеспечения АСУ.
Рассмотрим эти требования более подробно.
Для математического обеспечения в ТЗ приводят требования к соста-
ву, области применения и способам использования в системе математических
методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разра-
ботке.
Для информационного обеспечения системы приводят требования:
1) к составу, структуре и способам организации данных в системе;
2) к информационному обмену между компонентами системы и со
смежными системами;
3) по использованию государственных, отраслевых и других класси-
фикаторов и унифицированных форм документов;
4) по применению систем управления базами данных;
5) к структуре процесса сбора, обработки, передачи данных в системе
и представлению данных;
6) к защите данных от разрушений при авариях и сбоях в системе и от
несанкционированного доступа;
7) к процедуре придания юридической силы документам, продуцируе-
мым техническими средствами АСОИУ.
Для лингвистического обеспечения системы приводят требования к
применению в системе языков программирования высокого уровня, языков
взаимодействия пользователей и технических средств системы, требования к
кодированию и декодированию данных, к языкам ввода и вывода данных, и
манипулирования данными, средствам описания объекта автоматизации, к
способам организации диалога.
Для программного обеспечения системы приводят перечень покупных
программных средств, а также следующие требования:
1) к независимости программных средств от используемых техниче-
ских средств и операционной среды;
2) к качеству программных средств и способам его обеспечения и кон-
троля;
3) по необходимости согласования вновь разрабатываемых программ-
ных средств с фондом алгоритмов и программ.

56
 57

Для технического обеспечения системы приводят требования к видам

технических средств, в том числе программно-технических комплексов, к их
функциональным, конструктивным и эксплуатационным характеристикам.
Для организационного обеспечения системы приводят следующие тре-
бования:
1) к структуре и функциям подразделений, участвующих в функцио-
нировании системы или обеспечивающих ее эксплуатацию;
2) к организации функционирования системы и порядку взаимодейст-
вия персонала АСУ и объекта управления;
3) к защите от ошибочных действий персонала системы.
5) Раздел ТЗ «Состав и содержание работ по созданию (развитию)
системы» должен содержать перечень стадий и этапов работ по созданию
системы, сроки их выполнения и перечень организаций-исполнителей. Кроме
этого, в этом разделе приводят перечень документов, предъявляемых по
окончании соответствующих стадий и этапов, вид и порядок проведения экс-
пертизы технической документации, программу работ по обеспечению тре-
буемого уровня надежности создаваемой системы и ее метрологическому
обеспечению.
6) В разделе «Порядок контроля и приемки системы» указывают:
1) виды, состав, объем и методы испытаний системы или ее частей;
2) общие требования к приемке работ по стадиям, порядок согласования
и утверждения приемочной документации;
3) статус приемочной комиссии.
7) В разделе «Требования к составу и содержанию работ по подго-
товке объекта автоматизации к вводу системы в действие» необходимо
привести перечень основных мероприятий и их исполнителей.

8) В разделе «Требования к документированию» приводится перечень

подлежащих разработке документов, вид и формы их представления заказчи-
ку.
9) В разделе «Источники разработки» должны быть перечислены
документы и информационные материалы, на основании которых разрабаты-
валось ТЗ и которые должны быть использованы при создании системы.

В процессе создания (развития) АСОИУ может возникнуть необходи-

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

57
 58

ветствии с экономической целесообразностью или по иным соображениям,

создание АСОИУ может осуществляться в виде последовательности очере-
дей. В этом случае ТЗ составляется и утверждается на систему в целом, с вы-
делением первой очереди системы. При этом, допускается формировать за-
дание на всю систему в обобщенном виде, с конкретизацией задач первой
очереди, вплоть до составления и утверждения ТЗ на первую очередь, с ука-
занием основных показателей развития системы в целом. На дальнейшее
расширение или реконструкцию системы составляется и утверждается от-
дельное техническое задание.
В заключение отметим, что сформулированное ТЗ полностью опреде-
ляет логику функционирования создаваемой АСОИУ. Поэтому стадию тех-
нического задания можно назвать стадией логического проектирования соз-
даваемой системы. Логическому проектированию предшествует концепту-
альное проектирование (стадия 2 по ГОСТу), а ему – предпроектный анализ
(стадия 1 по ГОСТу). Таким образом, технологический процесс создания
АСОИУ на предпроектных стадиях можно представить в виде схемы, пред-
ставленной на рис. 3.1.

Рис. 3.1. Технологический процесс создания АС на

предпроектных стадиях проектирования
Обобщенная характеристика этапа «Логическое проектирование сис-
темы» представлена на рис. 3.2
Лекция 8
3.3. Содержание работ проектных стадий создания АСОИУ

Непосредственное проектирование создаваемой системы осуществля-

ется на стадиях: 4. «Эскизный проект»; 5. «Технический проект»; 6. «Рабочая

документация».

Работы, выполняемые на стадии 4. «Эскизный проект», носят предва-

рительный характер.

58
 59

На этой стадии, как правило, решают общесистемные задачи, для чего:

1) определяют функциональную и организационную структуры созда-

ваемой АСОИУ и структуру комплекса технических средств;

2) уточняют функции подсистем и состав относящихся к ним комплек-

сов задач и отдельных задач;

3) разрабатывают и обосновывают концепцию информационной базы и

ее укрупненную структуру.

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

параметры основных программных средств. Завершается данная стадия раз-

работкой документов, виды которых определены ГОСТ 34.201. Требования к

содержанию некоторых из этих документов будут приведены ниже.

Основные проектные решения по созданию АСОИУ принимаются на

стадии 5 - «Технический проект». Эта стадия включает в себя четыре этапа.

59
 60

Рис. 3.2 Обобщенная характеристика этапа «Логическое проектирова-

ние системы»

60
 61

На этапе 5.1. «Разработка проектных решений по системе и ее частям»

выполняют работы, связанные с поиском и принятием общих решений по
системе и ее частям:
1) функционально-алгоритмической структуре системы;
2) по функциям персонала и организационной структуре;
3) по структуре комплекса технических средств;
4) по алгоритмам и применяемым языкам;
5) по организации и ведению информационной базы, системе классифи-
кации и кодирования информации;
6) по программному обеспечению.
На этапе 5.2. «Разработка документации на АСОИУ и ее части» про-
водят разработку, оформление, согласование и утверждение документации в
объеме, необходимом для описания полной совокупности принятых проект-
ных решений и достаточном для дальнейшего выполнения работ по созда-
нию системы. Виды документов – по ГОСТ 34.201. Требования к содержа-
нию некоторых из этих документов будут приведены ниже.
На этапе 5.3. «Разработка и оформление документации на поставку изде-
лий для комплектования системы и (или) технических требований (техниче-
ских заданий) на их разработку» проводят подготовку и оформление доку-
ментации на поставку изделий для комплектования системы, определяют
технические требования и составляют ТЗ на разработку изделий, которые не
изготовляются серийно.
На этапе 5.4. «Разработка заданий на проектирование в смежных частях
проекта объекта автоматизации» осуществляют разработку, оформление, со-
гласование и утверждение заданий на проектирование в смежных частях
проекта объекта автоматизации для проведения строительных, электротехни-
ческих, санитарно-технических и других подготовительных работ, связанных
с созданием АСОИУ.
Отметим, что стадию «Технический проект» еще называют стадией
«Физического проектирования». Этим подчеркивается, что на этой стадии
переходят от умозрительного проектирования на стадиях «Техническое зада-
ние» и стадии «Эскизный проект», к реальному проектированию. Обобщен-
ная характеристика стадии «Технический проект» представлена на рис. 3.3.

61
 62

Рис. 3.3. Обобщенная характеристика стадии «Технический проект».

62
 63

Стадия 6. «Рабочая документация» состоит из двух этапов.

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

3.4. Содержание работ на стадиях ввода в действие и сопровождения АСОИУ

Стадия 7. «Ввод в действие», в общем случае, состоит из восьми этапов.

На этапе 7.1. «Подготовка объекта к вводу АСОИУ в действие» осущест-
вляют реализацию принятых проектных решений по организационной струк-
туре системы, обеспечивают подразделения объекта управления необходи-
мыми инструктивно-методическими материалами, внедряют классификаторы
информации.
Этап 7.2. «Подготовка персонала» включает обучение персонала и про-
верку его способности к работе по обеспечению функционирования системы.
Этап 7.4. «Строительно-монтажные работы» состоит из работ, связанных
со строительством специализированных зданий, прокладкой кабельных свя-
зей, выполнением работ по монтажу технических средств и линий связи, ис-
пытанием и подготовкой технических средств для проведения пуско-
наладочных работ.

63
 64

Рис. 3.4. Обобщенная характеристика этапа «Программная реализация»

64
 65

На этапе 7.5. «Пуско-наладочные работы» проводят автономную наладку

технических средств, загрузку информации в базу данных и проверку систе-
мы ее ведения, комплексную наладку всех средств системы.
Этап 7.6. «Проведение предварительных испытаний» включает испыта-
ния системы на работоспособность и соответствие ТЗ, устранение неисправ-
ностей и внешние изменения в документацию. Завершается этап формирова-
нием акта о приемке системы в опытную эксплуатацию.
На этапе 7.7. «Проведение опытной эксплуатации» проводят опытную
эксплуатацию АСОИУ, анализируют полученные результаты и, при необхо-
димости, выполняют доработку программного обеспечения и дополнитель-
ную наладку технических средств. Заканчивается этап актом о завершении
опытной эксплуатации.
Этап 7.8. «Проведение приемочных испытаний» выполняют с целью оп-
ределения соответствия разработанной АСОИУ техническому заданию. По-
сле проведения испытаний и устранения недостатков, выявленных при испы-
таниях, оформляется акт о приемке системы в постоянную эксплуатацию.
Стадия 8. «Сопровождение АСОИУ» состоит из двух этапов.
На этапе 8.1. «Выполнение работ в соответствии с гарантийными обяза-
тельствами» осуществляют работы по устранению недостатков, выявленных
при эксплуатации системы, в течение установленных гарантийных сроков,
внесению изменений в документацию на систему.
Этап 8.2. «Послегарантийное обслуживание» включает работы по анализу функцио-
нирования системы, выявлению отклонения фактических эксплуатационных характери-
стик АСОИУ от проектных значений, устранению выявленных недостатков, внесению не-
обходимых изменений в документацию на систему.
Лекция 9
ГЛАВА 4. МЕТОДЫ И МОДЕЛИ АНАЛИЗА И СИНТЕЗА АС НА
ПРЕДПРОЕКТНЫХ И ПРОЕКТНЫХ СТАДИЯХ ЕЕ СОЗДАНИЯ
4.1. Методы анализа документооборота в исследуемом объекте управления
Основой разработки АС является составленная модель существующей
системы управления. Построение такой модели осуществляется в результате
реализации диагностического анализа организации и детального анализа су-
ществующей системы обработки данных. Диагностический анализ – это ком-
плекс исследований, проводимых с целью выявления общих тенденций раз-
вития объекта управления и системы управления, изучения характеристик
типовых задач управления, разработки требований и мероприятий по улуч-
шению системы управления. Основной целью детального анализа сущест-
вующей системы является изучение характеристик алгоритмов принятия ре-
шений, существующей системы обработки данных и документооборота.
Результаты анализа объекта и системы управления фиксируются в спе-
циальных документах. Комплект этих документов называют системной спе-

65
 66

цификацией. Использование системных спецификаций при анализе и проек-

тировании АСОИУ позволяет:
 Систематизировать полученные в результате анализа данные и пред-
ставить их в наглядном и удобном для дальнейшего использования
виде;
 Упростить и облегчить передачу результатов работы одних специа-
листов другим;
 Обеспечить взаимозаменяемость исполнителей;
 Формализовать процедуры ввода исправлений и дополнений;
 Облегчить контроль качества выполнения каждого этапа работы.
Подготовка спецификаций требует значительных затрат времени и тру-
да. Однако эффективность их использования возрастает с масштабами разра-
ботки. Основные этапы диагностического и детального анализа существую-
щей системы управления и перечень документов системной спецификации
приведены в таблице 4.1.
Таблица 4.1.
Этапы разработки Наименование форм документации
I. Изучение структу- 1. Описание организации
ры, целей и ограни- 2. Структурная схема организации
чений существую- 3. Таблица целей и функций организации
щей системы управ- 4. Характеристика задач организации
ления 5. Описание функций подразделения
6. Описание информационных потоков подразделений
7. Структурная схема каждого подразделения
8. Таблица функций подразделения
9. Обобщенная структурно-информационно-временная
схема
II. Изучение и анализ 1. Характеристики документов
информационных 2. Описание документов
потоков и алгорит- 3. Характеристики массивов
мов переработки 4. Описание массивов
данных в сущест- 5. Характеристики процедур (задач)
вующей системе 6. Описание процедур (задач)
управления 7. Схема детального анализа процедур
Как правило, стремятся унифицировать используемые бланки для про-
стоты их заполнения.
Для описания информационных потоков подразделения дадим, вначале,
ему определение. Понятие потока информации определяется как совокуп-
ность двух понятий: схемы потока информации и элемента потока информа-
ции.

66
 67

Схема потока информации задается указанием отношений вхождения

относительно каждого элемента потока.
Элементами потока информации могут быть:
а) документы;
б) элементы документов (показатели, реквизиты);
в) операторы (люди, устройства, подразделения).
В потоке информации определяются два основных параметра: направле-
ние потока и плотность потока. Направление потока задается местом его
V
входа и выхода, а плотность соотношением   , где ΔV – объем инфор-
t
мации (бит, количество документов или документострок и т.д.), Δt – дли-
тельность передачи, приема или обработки заданного объема информации.
Общее число документов, циркулирующих на предприятии, составляет
1224 формы. По отношению к внешней среде они делятся на входные (199
форм), внутренние, т.е. создаваемые на предприятии, и выходные (219), чис-
ло которых входит в число внутренних.
Для формирования 438 форм не требуются данные из других докумен-
тов, причем 64 формы из них выходят за рамки предприятия – это первичные
документы. Остальные 587 форм формируются на основе данных, содержа-
щихся в других документах - производные документы.
Для принятия решений используется 108 + 237 + 294 = 639 форм – ак-
тивные документы. Остальные 91 +201 + 293 = 585 форм только используются
в процессе обработки информации – пассивные документы.
Анализ указанных форм документов показывает, что среднее число по-
вторений одних и тех же показателей, фигурирующих в потоке информации,
превышает 17000.
Если учесть сложность потоков информации, и то, что все документы
обычно имеют копии и встречаются в нескольких подразделениях, то станут
очевидными те огромные объемы информации, которые необходимо обраба-
тывать в процессе управления предприятием.
Для получения данных, необходимых для построения схемы потока ин-
формации требуется провести большую работу, связанную с анализом суще-
ствующего документооборота. Такой анализ осуществляют путем заполнения
специальных опросных анкет.
Обычно используют два вида анкет. Первый вид предназначен для отра-
жения характеристик документов (разрабатываемых и поступающих) с указа-
нием маршрута их движения. Пример такой анкеты дан на рис. 4.1.1. Второй
вид анкеты отражает характеристики показателей (разрабатываемых и посту-
пающих) с указанием маршрута их движения, алгоритмов формирования или
степени использования для формирования других показателей. Пример анкеты
дан на рис. 4.1.2.

67
 1
1

68
шифр подразделения сообщающего све- шифр документа
дения

2
2
шифр документа шифр подразделения, где доку-

3
мент обрабатывается
шифр показателя

4
3
шифр подразделения, где показатель ис- шифр подразделения – постав-
пользуется щика

4
шифр I-го показателя
шифр подразделения – получа-
шифр документа теля
шифр подразделения - поставщи- 5 шифры документов, при разра-
ка

5.1 5.2 5.3 5.4

шифр действия ботке которых используется

ры вида действия
данный документ

ское представление (см. рис. 4.1.3).

шифр II-го показателя
6

шифры документов, которые ис-

68

шифр документа пользуются при разработке дан-

ного документа
7

шифр подразделения - поставщи-

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

5.X 5.XI 5.XII 5.XII 6

шифр вида документа (актив-
шифр периодичности разработки доку-
ный, пассивный)
мента

7
9

шифр значности показателя

объем документа (в строках, зна-
Рис. 4.1.1. Пример анкеты для характеристики документа

8
ках)

Рис. 4.1.2. Пример анкеты для характеристики показателей

шифр вида показателя

9
10

количество экземпляров
шифр вида документа
11

трудоемкость составления

10
примечания
12

примечания

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

получают различного рода аналитические материалы о документообороте.

Наиболее простым представлением документооборота является его графиче-

 69

Руководитель Начальник отдела Ведущий исполни- Машинистка

Предприятия тель

Приказ
Архив
1 составление Приказ
4

2 Выбор ис-
полнителя
Приказ

3 Ознакомление

План по План по
форме №1 форме №1
(рукопись) (рукопись)
План по 6 Просмотр 5 Составление
форме №1
(рукопись)

7 Просмотр Печать
плана
8 Печать
План по
форме
План по
форме №1 9 Проверка

10 Утверждение

Рис. 4.1.3 Упрощенная карта документооборота

Более сложной является так называемая матричная информационная мо-

дель (см. рис. 4.1.4).

В I-ом квадранте модели отражаются все документы и показатели, кото-

рые разрабатываются в обследуемом подразделении. Этот квадрант имеет

шахматную композицию, т.е. одинаковое наименование документов и показа-

телей по строкам и столбцам.

69
 70

Рис. 4.1.4. Матричная информационная модель

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

70
 71

ся показатель данной строки. Итоговые результаты первого квадранта харак-

теризуют:
— по столбцу – количество разработанных в подразделении показателей,
используемых для формирования показателя данного столбца;
— по строке – степень использования данного показателя в формирова-
нии других показателей этого документа или в создании показателей
каких-либо других документов подразделения.
II-й квадрант отражает выход разработанных в данном подразделении
документов и показателей по потребителям. Каждый столбец II-го квадранта
отражает степень заполнения документов или их частей, разрабатываемых в
подразделении и передаваемых другим. Соответственно, строки II-го квад-
ранта характеризуют распределение показателей из данных документов по
подразделениям – потребителям. Итоговый столбец II-го квадранта отражает
количество показателей передаваемых данным подразделением всем другим.
Итоговая строка характеризует использование показателей или документов
данного подразделения во всех других подразделениях.
Наименование столбцов III-го квадранта совпадает с наименованием
столбцов I-го квадранта. Содержание строк этого квадранта – входящие доку-
менты и показатели в разрезе подразделений – поставщиков. Столбцы III-го
квадранта характеризуют использование получаемых от других подразделе-
ний сведений для формирования новых показателей или документов. Соответ-
ственно, строки III-го квадранта характеризуют использование поступающих
документов и показателей в данном подразделении. Итоговый столбец III-го
квадранта характеризует применимость поступающих показателей, а итоговая
строка – количество входящих показателей для формирования показателя I-го
квадранта или простую их переписку в другой документ.
В IV-ом квадранте содержание строк совпадает с III-м квадрантом, а со-
держание столбцов – со II-м. IV-й квадрант характеризует передачу данным
подразделением поступающих документов другим подразделениям.
Левый вспомогательный раздел отражает признаки, являющиеся состав-
ными элементами структуры показателей каждого из документов, которые
разрабатываются или поступают в данное подразделение. Каждый отдельный
столбец этого раздела характеризует применяемость признака в различных до-
кументах и показателях (разрабатываемые и поступающие) данного подразде-
ления. Строка отражает набор тех признаков, которые включаются в каждый
из документов данного подразделения.
Левый вспомогательный раздел в свою очередь делится на две части А и
Б. Подраздел А отражает те признаки, которые имеются в разрабатываемых
данным подразделением документах. Подраздел Б отражает признаки посту-
пающих документов.
Нижний раздел содержит сведения об исполнителях, осуществляющих
разработку документов и показателей.
Правый раздел содержит обобщающую характеристику разрабатываемых
показателей модели.

71
 72

4.2. Метод анализа документооборота на основе теории графов

Для анализа потока информации, c целью выработки рекомендаций по

его улучшению, можно использовать формализованный метод, основанный на
применении теории графов.
Если структурные компоненты (элементы) потока x1,x2,…,xn сопоставить
вершинам графа x1,x2,…,xn и каждую пару вершин xi и xj соединить дугой,
идущей от xi к xj в том и только в том случае, когда компонента xi является
входом компоненты xj, то получится схема, называемая информационным
графом. Информационный граф может быть построен для уровня документов,
уровня показателей и синтетического уровня (документы и показатели).
Пользуясь известными свойствами графов, можно выявить ряд важных
характеристик схем потоков информации. Для этого образуем матрицу А с n
строками и n столбцами А  aij , где
0, если элемент xi не соединяется с элементом x j ;
aij  
 1, если элемент xi соединяется с элментом x j .
Если G – информационный граф и А – его матрица смежности, то элемент
 
a ij
матрицы А(λ) , полученной возведением матрицы А в степень λ, равен
числу различных путей длиной λ, идущих от вершины xi к вершине x j . Возве-
дение матрицы А в степень N следует производить до тех пор, пока A N  0 , а
A N 1  0 , если информационный граф не содержит конту-
N
ров.Последовательность матриц А1, А2,…, АN и матрица    A позволяют
 1

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

Свойство 1.Порядком  j компоненты x j называют длину наибольшего

пути, связывающего эту компоненту с компонентой xi (i, j  1, n , i  j ) . Фор-
мально  j определяется следующим соотношением:
  j (   j )  0;

 j (   j  1)  0.
В этом соотношении  j ( ) - это сумма элементов j  го столбца матрицы
n
A j , т.е.  j ( )   aij ( ). Физический смысл величины  j – это номер такта
i 1

(длина наибольшего пути, связывающего элемент xi с элементом x j ), к кото-

рому «готовы» все составляющие элемента потока x j .
Свойство 2. Число N  max  j (максимум находится по всем компонентам
j 1,n

потока) называется порядком информационного графа. Если для N справедли-

во соотношение АN≠ 0 и АN+1 = 0, то соответствующая схема потока называет-
ся N-тактной.
Свойство 3. Признаком контура (ошибка обследования) служит появле-
ние ненулевых элементов на главной диагонали любой из матриц Аλ.
72
 73

Свойство 4. Равенство нулю суммы элементов j-го столбца матрицы

смежности А, т.е.  j (  1)  0 служит признаком формального выделения
входных компонент потока. Значение k   j (  1)  0 равно числу компонент,
участвующих в формировании элемента x j .
Свойство 5. Аналогично свойству 4, равенство нулю суммы элементов i-
ой строки матрицы А служит признаком для выделения выходных функцио-
нальных результатов, а сумма этих чисел L   j (  1)  0 равна числу компо-
нент, в которые входит xj.
Свойство 6. Если при некотором i  j одновременно
  i (  1)  0

 j (  1)  0,
то это означает, что к рассматриваемой схеме потока информации эта компо-
нента x j отношения не имеет (ошибка обследования).
Свойство 7. Число путей длины λ от компоненты xi к компоненте x j оп-
 
ределяется элементом aij матрицы Аλ.
Свойство 8. Число всевозможных путей от компоненты xi к компоненте xj
N
определяется элементом δij матрицы    A .
 1

Свойство 9. Отличные от нуля элементы j-го столбца матрицы δ указы-

вают все компоненты, участвующие в формировании элемента xj, а ненулевые
элементы i-той строки матрицы δ указывают все элементы, при формировании
которых используется элемент xj.
Свойство 10. Номер такта j, после которого может быть “погашен” во
внешней памяти элемент xi, равен максимальному значению порядка элемен-
та, для которого элементы i-й строки матрицы А отличны от 0.
Свойство 11. Число тактов, в течение которых компонента «хранится» во
внешней памяти, равна θi=τi – πi.
Формальное преобразование описанной модели с помощью ЭВМ позволяет выявить
ряд характеристик, важных как для реализации потока, так и для последующего программи-
рования процедур обработки информации:
а) определить последовательность решения задач, установив порядок (ранг)
πj каждой задачи;
б) выделить активные и пассивные компоненты потока относительно опера-
торов управления;
в) выявить дублирующую информацию и связи;
г) подготовить данные для расчета памяти ЭВМ и организации работы сис-
темы.

73
 74

4.3. Математическая модель оптимизации движения информационных

потоков в системе управления
На предпроектной стадии разработки АСОИУ важно выделить возмож-
ные узкие места в проектируемой системе обработки информации данной ор-
ганизации. Это позволит оптимально (рационально) распределить средства
вычислительной техники по подразделениям, обеспечить должную загрузку
технических средств и гарантировать решение всех управленческих задач в
требуемые сроки.
Пусть организация состоит из n подразделений, имеющих взаимные
информационные связи. Каждому подразделению p  1, n поставим в соответ-
ствие следующую совокупность функций:
w p (t ) – входной поток первичной (внешней) информации, поступающей в подразде-
ление p в момент времени t ;
v ip (t ) – информационный поток из подразделения i данной организации в подразде-
ление p этой же организации в момент времени t , (i  1, n; i  p ) .
В общем случае входной поток первичной информации имеет трендо-
вую, сезонную и циклическую составляющие, а также на него могут влиять
случайные изменения с нулевым математическим ожиданием и постоянной
дисперсией. Поэтому w p (t ) можно представить в виде:
w p (t )  f p ( t )  s p ( t )  c p (t )   , (1)
где :
w p (t ) – объем первичной информации (в байтах, документах, документостроках и т.д.), по-
ступающей для обработки в подразделение p в момент времени t ;
f p (t ) – трендовая составляющая потока;
s p (t ) – сезонная составляющая потока;
c p (t ) – циклическая составляющая потока;
 p – случайная составляющая потока, причем полагают, что M  p   0; D p   const .
Принципиально важно, что объем информационного потока, передаваемого от под-
разделения i к подразделению p для последующей обработки, является эндогенной для
рассматриваемой системы величиной, зависящей от совокупного объема информации, по-
ступившего для обработки в подразделение i , укомплектованности его кадрами и осна-
щенности средствами вычислительной техники.
Рассмотрим с формально - логической точки зрения процесс обработки информации в
подразделении p , которое будем считать «черным ящиком», преобразующим входную
информацию Vвхp (совокупный объем входной информации, который поступил в подраз-
деление p ) в выходную информацию Vвых р
.
Это можно записать так:
р
Vвых   р (Vвхр ). (2)

74
 75

Если, однако, пропускная способность подразделения p недостаточна для обработки

всего поступившего объема информации в единицу времени, то фактически получаемый
объем выходной информации в момент времени t , т.е. Vвых
р
(t ) таков, что будет справедливо
следующее неравенство:
р
Vвых (t )   p (Vвхр (t )) . (3)
Поэтому в динамике, т.е. с учетом временного фактора, равенство (2) примет вид:

V р
вых   р (V (t ))   Vвых
р
вх
р
( )d . (4)
t

Равенство (4) гарантирует получение всего требуемого, т.е. «положенного», объема

выходной информации за определенный период времени и то лишь в том случае, если под-
разделение р обладает определенными вычислительными ресурсами в течение зависящего
от величины этих ресурсов времени от поступления «порции» входной информации.
Для формализации введем следующие переменные:
- X p (t ) – объем входной информации, который может быть обработан в подразделе-
нии р в момент времени t ,
- V p (t ) – совокупный объем информации, поступившей в подразделение р , но не об-
работанной к моменту времени t .
Тогда, если интервал времени t достаточно мал, то можно записать, что прирост, не
обработанной за время t информации, равен:
V p (t  t )  V p (t )  (Vвхр (t )  X p ))t  O( t 2 ) (5)
Поделив выражение (5) на ∆t при ∆t→0, получим:
dV p (t )
 Vp (t )  Vвхp (t )  X p (t ). (6)
dt
Дифференциальное уравнение (6) определяет динамику изменения объема необрабо-
танной в подразделении p информации.
Так как поток входной информации складывается из первичной информации, посту-
пающей из внешней среды, и информационных потоков из других подразделений, то с уче-
том ранее введенных обозначений можно записать
n
V (t )  wp (t )   vip (t ) ,
p
вх (7)
i 1

где vip (t ) - количество информации, поступившей в подразделение p из других (n – 1) под-

разделений.
p
Поскольку в действительности Vвых (t ) – это объем информации, который являет-
ся продуктом работы подразделения p , т.е. выходящей из подразделения p информации,
зависит от объема переработанной информации X p (t ) , то можно записать:
p
Vвых ( t )   p ( X p (t )) (8)
Введем еще одни обозначения.
Обозначим через pj (Vвых
p
) функции, характеризующие объем информации, переда-
ваемой от подразделения p подразделению с номером j  1, n .

75
 76

p
Так как вся вновь созданная в подразделении p информация Vвых (t ) распределяется
между (n–1) подразделениями организации в соответствии с функциями pj (Vвых p
) , то мож-
но записать:
v pj (t )   pj (t , p ( X p (t ))) j  1, n (9)
Теперь можно определить структуру модели. Основные соотношения из (6), (7), (8) и
(9) следующие:
n
Vp (t )  w p (t )   v ip (t )  X p (t ), p  1, n (10)
i 1

V p (t0 )  V p( 0 ) , p  1, n (11)
v pj (t )   pj (t ,  p ( X p (t ))) , p, j  1, n (12)
где Wp(t) определяется формулой (1).
Будем считать заданными функции  pj (Vвых (t )) (они определяется структурой и на-
значением подразделений организации) и функции  p ( X p (t )) (они определяет общий объ-
ем выходной, т.е. созданной информации от количества обработанной входной информа-
ции).
Тогда для определения эндогенных (внутренних) n2+2n переменных модели, т.е.
функций
V p (t ) – объем необработанной информации в единицу времени в подразделении p ,
v pj (t ) – объемы информации, передаваемой от одного подразделения к другому,
X p (t ) – объем информации, обрабатываемой в единицу времени подразделением p ,
имеем n дифференциальных уравнений (10) и n 2 обычных уравнений (12).
Поскольку система уравнений (10) – (12) является неопределенной, то представляет
интерес постановка задачи как оптимизационной.
Пусть: X p (t ) – предельная пропускная способность подразделения p в момент вре-
мени t. Ее величина соответствует полной загрузке персонала и технических средств данно-
го подразделения; X p (t0 )  X p – предельная пропускная способность подразделения в
(0)

начальный момент времени;

C p ( X p ) – заданная функция величины затрат на обеспечение пропускной способности
подразделения p в размере X единиц информации в единицу времени. Эти затраты склады-
ваются из заработной платы сотрудников данного подразделения и средств, необходимых
для технического обслуживания ПЭВМ, другой вычислительной и оргтехники, а также за-
трат на сопровождение ПО;
U p (t ) – прирост максимальной пропускной способности подразделения в период t.
Отрицательная величина соответствует продаже или выходу из строя тех или иных техни-

ческих средств, увольнению или болезни сотрудников и т.д.; т.е. U p (t )  X p (t ).
K p (U p ) – заданная функция зависимости величины дополнительных капиталовложе-
ний при изменении пропускной способности подразделения p на U p единиц.
Теперь решение вопроса о выборе рациональной организации наращивания пропуск-
ных способностей подразделений организации по выпуску информации, при критерии ми-
76
 77

нимума совокупных затрат, может быть сведено к решению задачи математической теории
оптимального управления:
T n

 {C
t 0 p 1
p ( X p (t ))  K p (U p (t ))}dt  min (13)
n
V p (t )  w p (t )   v ip (t )  X p (t ) , p  1, n (14)
i 1

V p (t 0 )  V p(0) , p  1, n (15)
v pj (t )   pj ( p ( X p (t ))) , p  1, n , j  1, n (16)
0  X p (t )  X p (t ) , p  1, n (17)
X p (t )  U p (t ) , p  1, n (18)
X p (t 0 )  X p( 0) , p  1, n (19)
0  V p (t )  V p (t ) , p  1, n (20)
Здесь Т – горизонт планирования, а V p (t ) – ограничения на величину «задолженно-
сти» подразделения р по обработке информации. Введение ограничений (20) необходимо
для обеспечения формального требования неотрицательной величины необработанной
информации, т.к. обработка информации «впрок» до ее получения невозможна. Ограниче-
ние сверху на Vp(t) объясняется требованием завершения обработки информации в срок по
всем цепочкам процессов ее преобразования.
Рассмотренный вариант модели соответствует полностью распределенной обработке
данных в организации, т.к. условиями (17) задаются ограничения на пропускные способно-
сти каждого подразделения, чем неявно предполагается возможность перераспределения
технических средств между ними. При централизованном варианте СОД условия (17)
должны быть заменены на:
n

X
p 1
h (t )  X (t ) , (21)
где X (t ) – мощность специализированного вычислительного подразделения (объем
информации, который может быть обработан ВЦ учреждения при максимальном уровне
загрузки средств вычислительной техники).
Кроме того, вместо системы функций X p (t ) , Up(t) должна рассматриваться лишь па-
ра функций X (t ) и U(t), где U(t) – прирост мощностей по обработке информации специали-
зированного вычислительного подразделения в момент времени t. При этом условия (18) и
(19) заменяются на:
X (t )  U (t ) , (22)
X (t0 )  X ,(0)
(23)
и требуют переопределения функции C p ( X ) и Kp(U).
Функционал (13) предполагает оптимизацию основных переменных по критерию
минимума совокупных затрат. Возможна другая постановка задачи, если в качестве крите-

77
 78

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

 V
t0 PP
p (t )dt  min (24)

а ограничения (20) должны быть заменены на

n

C
p 1
p ( X p (t ))  c(t ) (25)

K
p 1
p (U p (t ))  k (t ) (26)

где c(t) – лимит на текущие затраты учреждения в период t,

k(t) – лимит на капитальные затраты учреждения.
Смысл функционала (24) состоит в том, чтобы свести к минимуму величину необра-
ботанной информации в тех подразделениях, от которых требуется наиболее оперативное
решение задач.
Все перечисленные выше изменения не выводят задачу из класса задач теории опти-
мального управления. Поэтому как аналитическое исследование, так и численное ее реше-
ние можно получить известными методами и алгоритмами.

Лекция 7

4.4. Структурный анализ систем средствами IDEF-моделирования

4.4.1. Общие положения

Постоянное усложнение производственно-технических и организацион-
но-экономических систем – фирм, предприятий, производств, и др. субъектов
производственно-хозяйственной деятельности – и необходимость их анализа с
целью совершенствования функционирования и повышения эффективности
обусловливают необходимость применения специальных средств описания и
анализа таких систем. Эта проблема приобретает особую актуальность в связи
с появлением интегрированных компьютеризированных производств и авто-
матизированных предприятий.
В США это обстоятельство было осознано еще в конце 70-ых годов, ко-
гда ВВС США предложили и реализовали Программу интегрированной ком-
пьютеризации производства ICAM (ICAM - IntegratedComputerAidedManufac-
turing), направленную на увеличение эффективности промышленных предпри-
ятий посредством широкого внедрения компьютерных (информационных)
технологий.
78
 79

Реализация программы ICAM потребовала создания адекватных методов

анализа и проектирования производственных систем и способов обмена ин-
формацией между специалистами, занимающимися такими проблемами. Для
удовлетворения этой потребности в рамках программы ICAM была разработа-
на методология IDEF (ICAMDefinition), позволяющая исследовать структуру,
параметры и характеристики производственно-технических и организационно-
экономических систем (в дальнейшем, там, где это не вызывает недоразуме-
ний – систем)
Методология IDEF в настоящее время поддерживается семейством из 11
стандартов, отражающих различные аспекты моделирования систем. Мы ог-
раничимся тремя технологиями моделирования, а именно методом функцио-
нального моделирования IDF0, методом описания бизнес-процессов IDF3 и
методом построения диаграмм потоков данных DFD.
Своим появлением семейство стандартов IDEF во многом обязано поя-
вившейся в 80-х гг. технологии автоматизированной поддержки разработки
информационных систем CASE (ComputerAidedSoftwareEngineering). До на-
стоящего времени эта технология с успехом применяется при разработке раз-
нообразного программного обеспечения. Однако в последнее время CASE-
технологии приобретают все большее распространение для моделирования и
анализа деятельности предприятий, предоставляя богатый набор возможно-
стей для оптимизации или, в терминах CASE, реинжиниринга технологиче-
ских процедур, выполняемых этими предприятиями – бизнес-процессов.
Метод функционального моделирования IDEF0, ранее известный как
технология структурированного анализа и разработки (StructuredAnalysisand-
DesignTechnique – SADT), был разработан компанией SofTech, Inc. в конце 60-
х гг. как набор рекомендаций по построению сложных систем, которые пред-
полагали взаимодействие механизмов и обслуживающего персонала. Значи-
тельная часть SADT была принята ВВС США как часть их программы интег-
рированной компьютерной поддержки производства (IntegratedComputer-
AidedManufacturing – ICAM) в конце 70-х гг. Эта технология, переименован-
ная в IDEF0, довольно быстро стала стандартом технологии моделирования
деятельности в министерстве обороны США.
В 1993 г. группа пользователей IDEF (IDEFUsersGroup, в настоявшее
время SocietyofEnterpriseEngineering – SEE), совместно с Национальным ин-
ститутом стандартов и технологии (NationalInstituteofStandardsandTechnology –
NIST) предприняли попытку создания документированного стандарта для
IDEF0, который мог бы использоваться как военными, так и гражданскими
департаментами правительства США. Этот стандарт был опубликован как фе-
деральный стандарт обработки информации (FederalInformationProcessingStan-
dard – FIPS).
Несколько независимо, но с использованием аналогичных подходов
технология DFD (DataFlowDiagrams – диаграммы потоков данных) завоевала
популярность для структурной разработки (а впоследствии и структурного
анализа) проектов построения информационных систем. Диаграммы потоков
данных во многом аналогичны моделям IDEF0 и могут быть использованы
79
 80

при проектировании информационных систем, например, после разработки

моделей анализа IDEF0.
Стандарт IDEF3 был специально разработан для закрытого проекта ВВС
США. Это технология получения описания деталей процесса от экспертов в
предметной области и разработки таких моделей процессов, в которых важно
понять последовательность выполнения действий и взаимозависимости между
ними.
Подход SADT относится к классу формальных методов, используемых
при анализе и разработке систем. Несмотря на то, что вполне допустима неза-
висимая разработка функциональных моделей, методология SADT предпола-
гает ведение структурированного проекта анализа, в процессе которого проис-
ходит их создание. В дополнение к функциональному моделированию SADT
структурный анализ предполагает построение информационных моделей дан-
ных и диаграмм состояний (State-TransitionDiagrams – STD), которые модели-
руют поведение системы во времени.
Основной принцип SADT состоит в том, что тщательный анализ систе-
мы обусловливает получение возможного оптимального решения. Использо-
вание SADT автоматически приводит к необходимости сбора и обработки зна-
чительного количества информации о системе. Традиционно такая информа-
ция собирается аналитиком посредством формализованного опроса экспертов
предметной области – людей, владеющих информацией о механизме функ-
ционирования системы в целом или ее частей. С течением времени некоторые
эксперты освоили технологию моделирования, что привело к появлению
IDEF3-технологии получения знаний от экспертов. Однако роль системного
аналитика в проектах SADT оставалась ключевой.
Часто разработка моделей применяется для документирования ситуации,
сложившейся к определенному моменту (модели "как есть" – «asis»). Впослед-
ствии они применяются при создании новых моделей функционирования сис-
темы (модели "как должно быть" – «tobe»), а также для проверки моделей
«tobe», с тем, чтобы удостовериться, что предлагаемые изменения действи-
тельно повлекут улучшение функционирования системы. Модели «tobe» ис-
пользуются также для планирования загрузки частей системы; калькуляции
бюджета и распределения ресурсов; при построении плана реорганизации сис-
темы, определяющего действия по переводу системы из состояния «asis» в со-
стояние «tobe».

4.4.2. Методология функционального моделирования IDEF0

4.4.2.1. Общие положения

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

80
 81

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

диаграммы IDEF0 приведем на рис. 4.4.1, 4.4.2.4.4.3, 4.4.3а.
Наиболее часто IDEF0 применяется как технология исследования и про-
ектирования систем на логическом уровне. По этой причине IDEF0, как пра-
вило, используется на ранних этапах разработки проекта до IDEF3-
моделирования, для сбора данных и моделирования процесса "как есть". Ре-
зультаты IDEF0-анализа могут применяться при проведении проектирования с
использованием моделей IDEF3 и диаграмм потоков данных DFD.
Первый шаг при построении модели IDEF0 заключается в определении
цели или назначения модели – набора вопросов, на которые должна отвечать
модель. Набор вопросов можно сравнить с предисловием, в котором раскры-
вается назначение книги.
Границы моделирования предназначены для обозначения ширины охвата
предметной области и глубины детализации и являются логическим продол-
жением уже определенного назначения модели. Как читающий модель, так и
непосредственно ее автор должны понимать степень детальности ответов на
поставленные в назначении модели вопросы.
Следующим шагом указывается предполагаемая целевая аудитория, для
нужд которой создается модель. Зачастую от выбора целевой аудитории зави-
сит уровень детализации, с которым должна создаваться модель. Перед по-
строением модели необходимо иметь представление о том, какие сведения о
предмете моделирования уже известны, какие дополнительные материалы и
(или) техническая документация для понимания модели могут быть необхо-
димы целевой аудитории, какие язык и стиль изложения являются наиболее
подходящими.
Под точкой зрения понимается перспектива, с которой наблюдалась
система при построении модели. Точка зрения выбирается таким образом,
чтобы учесть уже обозначенные границы моделирования и назначение моде-
ли. Однажды выбранная точка зрения остается неизменной для всех элемен-
тов модели. При необходимости могут быть созданы другие модели, отобра-
жающие систему с других точек зрения. Примеры цели, границы и точки
зрения приведены на рис. 4.4.1.
Синтаксис графического языка IDEF0 включает блоки, стрелки, диа-
граммы и правила.
Блоки представляют функции, определяемые как деятельность, про-
цесс, операция, действие или преобразование (см. ниже). Стрелки представ-
ляют данные или материальные объекты, связанные с функциями. Правила
определяют, как следует применять компоненты; диаграммы обеспечивают
формат графического и словесного описания моделей. Формат образует ос-
нову для управления конфигурацией модели.
81
 82

82
 83

83
 84

84
 85

Блок представляет собой прямоугольник, внутри которого помещается

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

Рис. 4.4.4. Пример блока

Поскольку модели IDEF0 моделируют систему как множество иерар-

хически вложенных функций, то в первую очередь должна быть определена
функция, описывающая систему в целом – контекстная функция. В IDEF0 эта
контекстная функция представляется в виде одного прямоугольника. Пример
такой контекстной функции приведен на рис.4.4.1.
Любой блок может быть декомпозирован на составляющие его блоки.
Декомпозицию часто ассоциируют с моделированием "сверху вниз", однако
это не совсем верно. Функциональную декомпозицию корректнее определять
как моделирование «снаружи внутрь», при котором рассматриваем систему
наподобие луковицы, с которой последовательно снимаются слои.
Описание любого блока должно как минимум включать описание объ-
ектов, которые блок создает в результате своей работы ("выхода") и объек-
тов, которые блок потребляет или преобразует ("вход").
В IDEF0 также моделируются управление и механизмы исполнения. Под
управлением понимаются объекты, воздействующие на способ, которым
блок преобразует вход в выход. Механизм исполнения – объекты, которые
непосредственно выполняют преобразование входа в выход, но остаются не-
изменными.
Для типизации категорий информации на IDEF0-диаграммах использу-
ется аббревиатура ICOM, означающая четыре возможных типа стрелок:
I (Input) – вход – то, что потребляется в ходе выполнения процесса;
С (Control) – управление – ограничения и инструкции, влияющие на
ход выполнения процесса;
О (Output) – выход – то, что является результатом выполнения процес-
са;
М (Mechanism) – исполняющий механизм – то, что используется для
выполнения процесса, но остается неизменным.
На рис. 4.4.5 представлены четыре возможных типа стрелок в IDEF0,
каждый из которых соединяется с определенной стороной функционального
блока.

85
 86

Рис. 4.4.5Каждый тип стрелки соединяется с определенной стороной

функционального блока
Для названия стрелок, как правило, употребляются имена существи-
тельные. Как и в случае с функциональными блоками, присвоение имен всем
стрелкам на диаграмме является необходимым условием для понимания сути
изображенного. Примеры наименований стрелок приведены на рис. 4.4.1,
4.4.2, 4.4.3, 4.4.3а.
Дадим подробное назначение каждой стрелки.
Стрелки входа. Вход, представляет собой сырье или информацию, по-
требляемую или преобразуемую функциональным блоком для производства
выхода. Стрелки входа всегда направлены в левую сторону прямоугольника,
обозначающего в IDEF0 функциональный блок. Наличие входных стрелок на
диаграмме не является обязательным, так как возможно, что некоторые бло-
ки ничего не преобразуют и не изменяют. Примером блока, не имеющего
входа, может служить принятие решения руководством, где анализируется
несколько факторов, но ни один из них непосредственно не преобразуется и
не потребляется в результате принятия какого-либо решения.
Стрелки управления.Стрелки управления отвечают за регулирование
того, как и когда выполняется функциональный блок. Так как управление
контролирует поведение функционального блока для обеспечения создания
желаемого выхода, каждый функциональный блок должен иметь как мини-
мум одну стрелку управления. Стрелки управления всегда входят в функцио-
нальный блок сверху.
Управление часто существует в виде правил, инструкций, законов, по-
литики, набора необходимых процедур или стандартов. Влияя на работу бло-
ка, оно само остается неизменным. Может оказаться, что целью функцио-
нального блока является как раз изменение того или иного правила, инструк-
ции, стандарта и т.п. В этом случае стрелка, содержащая соответствующую
информацию, должна рассматриваться не как управление, а как вход функ-
ционального блока.
Управление можно рассматривать как специфический вид входа. В
случаях, когда неясно, относить ли стрелку к входу или к управлению, пред-
почтительно относить ее к управлению до момента, пока неясность не будет
разрешена.
Стрелки выхода. Выход – это продукция или информация, получаемая
в результате работы функционального блока. Каждый блок должен иметь
как минимум один выход. Действие, которое не имеет никакого четко опреде-
86
 87

ляемого выхода, желательно не моделировать вообще или это один из пе пер-

вых кандидатов на исключение из модели.
При моделировании непроизвод
непроизводственных
ственных предметных областей выходами, как пра-пр
вило, являются данные, в каком
каком-либо
либо виде обрабатываемые функциональным блоком. В
этом случае важно, чтобы названия стрелок входа и выхода были достаточно различимы по
своему смыслу. Например, блок "Прием пациен
пациентов"
тов" может иметь стрелку "Данные о паци-
пац
енте" как на входе, так и на выходе. В такой ситуации входящую стрелку можно назвать
"Предварительные данные о пациенте", а исходящую – "Подтвержденные данные о паци- пац
енте".
Стрелки механизма исполнения
исполнения. Механизмы являются
являю ресурсом, ко-
торый непосредственно исполняет моделируемое действие. С помощью м ме-
ханизмов исполнения могут моделироваться: ключевой персонал, техника
и/или оборудование.. Стрелки механизма исполнения могут отсутствовать, в
случае если оказывается, что они не являются необходимыми для достиже- достиж
ния поставленной цели моделирования.
Комбинированные стрелкистрелки. В IDEF00 существует пять основных видов
комбинированных стрелок: 1) выход – вход, 2) выход – управление, 3) выход
– механизм исполнения, 4) выход – обратная связь вязь на управление и 5) выход–
выход
обратная связь на вход.
1) Стрелка выход – вход применяется, когда один из блоков должен полностью за- з
вершить работу перед началом работы другого блока. Так, на рис. 4..4.6 формирование счета
должно предшествовать приему заказа
заказа.

Рис. 4.4.6.. Комбинация стрелок выход – вход

2)Стрелка выход – управление отражает ситуацию преобладания одно-

одн
го блока над другим, когда один блок управляет работой другого
другого. На рис.
4.4.7 принципы формирования инвестиционного портфеля влияют на пов пове-
дениее брокеров на бирже.

Рис. 4.4.7.. Комбинированная стрелка выход – управление

3)Стрелки выход – механизм исполнения встречаются реже и отража-

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

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

Рис. 4.4.8. Комбинированная стрелка выход – механизм исполнения

Рис. 4.4.9. Комбинированная стрелка выход – обратная связь

на управление

5) Стрелка выход – обратная связь на вход обычно применяется для описания циклов
повторной обработки чего-либо (рис. 4.4.10). Кроме того, связи выход – обратная связь на
вход могут применяться в случае, если бракованная продукция может заново использовать-
ся в качестве сырья, как это происходит, например, в процессе производства оконного стек-
ла, когда разбитое стекло перемалывается и переплавляется заново вместе с исходным
сырьем.

88
 89

Рис. 4.4.10. Комбинированная стрелка выход – обратная связь на вход

Разбиение и соединение стрелок. Выход функционального блока мо-

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

Рис.4.4.11. Разъединенная на две части и переименованная стрелка

На IDEF0-диаграммах есть еще стрелки вида (). Такие стрелки назы-

вают туннелями. Они связаны с понятием связанных стрелок, котороеис-

89
 90

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

Рис. 4.4.12.. Пример применения туннеля

Кроме того, туннели при применяются
меняются для отражения ситуации, когда
стрелка, присутствующая на родительской диаграмме, отсутствует в дидиа-
грамме декомпозиции соответствующего блока. На рис. 4.4.13 туннель у
стрелки "модуль производственного отдела" обозначает, что на диаграмме
декомпозиции
ции производственного отдела отсутствует стрелка механизма
управления с соответствующим наименованием.

Рис. 4.4.13.. Пример применения туннеля

90
 91

Полностью составленная IDEF0-диаграмма любого уровня содержит на

своих полях служебную информацию, которая состоит из хорошо выделен-
ных верхнего и нижнего колонтитулов (заголовка и "подвала"). Элементы за-
головка используются для отслеживания процесса создания модели. Элемен-
ты "подвала" отображают наименование модели, к которой относится диа-
грамма, и показывают ее расположение относительно других диаграмм моде-
ли.
Все элементы заголовка диаграммы перечислены в табл. 4.4.1.
Таблица 4.4.1. Элементы заголовка диаграммы IDEF0
Поле Назначение
Используется для отражения внешних ссылок
USEDAT на данную диаграмму (заполняется на печатном до-
кументе вручную)
Содержит ФИО автора диаграммы, дату соз-
Author, date,
дания, дату последнего внесения изменений, наиме-
project
нование проекта, в рамках которого она создавалась
При ручном редактировании диаграмм пользователи
Notes 1 ... 10 могут зачеркивать цифру каждый раз, когда они
вносят очередное исправление
Статус отражает состояние разработки или утвер-
ждения данной диаграммы. Это поле используется
Status
для реализации формального процесса публикации с
шагами пересмотра и утверждения
Новая диаграмма, глобальные изменения или новый
Working автор для существующей диаграммы
Диаграмма достигла некоторого приемлемого для
Draft читателей уровня и готова для представления на ут-
верждение
Recommend- Диаграмма одобрена и утверждена. Какие-либо из-
ed менения не предвидятся
Диаграмма готова для окончательной печати и пуб-
Publication ликации
Reader ФИО читателя
Date Дата знакомства читателя с диаграммой
Набросок расположения функциональных блоков на
родительской диаграмме, на котором подсвечен де-
Context композируемый данной диаграммой блок. Для диа-
граммы самого верхнего уровня (контекстной диа-
граммы) в поле помещается контекст ТОР
Все элементы "подвала" диаграммы перечислены в табл. 4.4.2.

91
 92

Таблица 4.4.2. Элементы "подвала" диаграммы IDEF0

Поле Назначение
Номер диаграммы, совпадающий с номером родитель-
Node
ского функционального блока
Title Имя родительского функционального блока
Уникальный идентификатор данной версии данной диа-
граммы. Таким образом, каждая новая версия данной
диаграммы будет иметь новое значение в этом поле. Как
правило, С-Number состоит из инициалов автора (кото-
рые предполагаются уникальными среди всех аналитиков
Number (еще
проекта) и последовательного уникального идентифика-
называют С-
тора, например SDO005. При публикации эти номера мо-
Number)
гут быть заменены стандартными номерами страниц. Ес-
ли диаграмма замещает другую диаграмму, номер заме-
няемой диаграммы может быть заключен в скобки –
SDO005 (SDO004). Это обеспечивает хранение истории
изменений всех диаграмм модели

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

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

Формально механизм рецензирования и модификации диаграмм под-

держивается полями Status и нумерацией диаграмм, контроль истории изме-
нений – полем Field (см. табл.4.4.2).

Ни одна модель не должна строиться без ясного осознания объекта и

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

92
 93

впоследствии служат основой для четкого и краткого определения цели мо-

делирования.

4.4.2.2. Точка зрения

С методической точки зрения при моделировании полезно использо-

вать мнение экспертов, имеющих разные взгляды на предметную область,
однако каждая отдельно взятая модель должна разрабатываться исходя из
единственной заранее определенной точки зрения. Часто другие точки зрения
вкратце документируются в прикрепленных диаграммах FEO (см. ниже) ис-
ключительно для наглядности изложения.
Точку зрения нужно подбирать достаточно аккуратно, основой для выбо-
ра должна служить поставленная цель моделирования. Наименованием точки
зрения может быть наименование должности, подразделения или роли (напри-
мер, руководитель отдела или менеджер по продажам). Как и в случае с опре-
делением цели моделирования, четкое определение точки зрения необходимо
для обеспечения внутренней целостности модели и предотвращения постоянно-
го изменения ее структуры. Может оказаться необходимым построение моде-
лей с разных точек зрения для детального отражения всех особенностей выде-
ленных в системе функциональных блоков.
Одним из положительных результатов построения функциональных мо-
делей оказывается четкое определение границ моделирования системы в целом
и ее основных компонентов. Хотя и предполагается, что в процессе работы над
моделью будет происходить некоторое изменение границ моделирования, их
вербальное (словесное) описание должно поддерживаться с самого начала для
обеспечения координации работы участвующих в проекте аналитиков. Как и
при определении цели моделирования, отсутствие границ затрудняет оценку
степени завершенности модели, поскольку границы моделирования имеют тен-
денцию к расширению с увеличением размеров модели.
Границы моделирования имеют два компонента: ширину охвата и глуби-
ну детализации. Ширина охвата обозначает внешние границы моделируемой
системы. Глубина детализации определяет степень подробности, с которой
нужно проводить декомпозицию функциональных блоков.
Чтобы облегчить правильное определение границ моделирования при
разработке IDEF0-моделей, существенные усилия затрачиваются на разработку
и рецензирование контекстной диаграммы IDEF0 (диаграммы "самого верхне-
го" уровня). Иногда даже прибегают к построению дополнительной диаграммы
для отображения уровня более высокого, чем контекстный для данной модели,
что позволяет обозначить систему, внутри которой располагается объект для
моделирования. Существенные затраты на разработку контекстной диаграммы
вполне оправданы, поскольку она является своего рода "точкой отсчета" для
остальных диаграмм модели, и вносимые в нее изменения каскадом отражают-
ся на все лежащие ниже уровни.
Когда границы моделирования понятны, также становится ясным, какие
объекты системы по тем или иным причинам не вошли в модель. Рекомендуе-
93
 94

мой последовательностью действий при построении модели "с нуля" являются:

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

4.4.2.3. Определение стрелок на контекстной диаграмме

Стрелки IDEF0-диаграмм обычно проще проектировать в следующем по-

рядке: выход, вход, механизм исполнения, управление. Каждый функциональ-
ный блок обозначает отдельную функцию, и эта функция часто имеет четко
описываемые результаты работы. Наличие неясностей при анализе выходов то-
го или иного функционального блока – возможный сигнал необходимости про-
ведения реинжиниринга рассматриваемого бизнес-процесса.
Определение выходов. После идентификации возможных выходов полез-
но провести анализ модели на предмет предвидения всех возможных сценариев
поведения процесса. Это означает, что если существует вероятность возникно-
вения той или иной ситуации в ходе процесса, модель ее отражает. Многие на-
чинающие аналитики забывают отразить негативные результаты работы функ-
циональных блоков. Например, блок "Провести экзамен по вождению" опреде-
ленно произведет поток водителей, только что получивших права, но вполне
правомерно ожидать и поток лиц, не сдавших экзамен. Негативные результаты
часто используются в качестве обратных связей, их анализ должен проводиться
для каждого блока. Также важным является необходимость включения в мо-
дель "спорных" стрелок, решение о наличии которых в модели могут прини-
мать рецензирующие модель эксперты.
Определение входов. Входы можно рассматривать как особым образом
преобразуемые функциональными блоками сырье или информация для полу-
чения выхода. В производственных отраслях определить, как входное сырье
преобразуется в готовую продукцию, обычно довольно просто. Однако при
моделировании информационных потоков входной поток данных может
представляться не потребляемым и не обрабатываемым вообще. Случаи, ко-
гда входящие и исходящие стрелкиназываются одинаково, крайне редки и в
основном указывают на бесполезность данного блока для системы в целом
или на некорректный выбор имени для исходящей стрелки. Решением может
служить применение более подробного описания для входящих и исходящих
потоков данных. Например, вход может иметь название "Предварительный
диагноз пациента", а выход – "Уточненный диагноз пациента".
Определение механизмов исполнения. После создания входов и выхо-
дов можно приступить к рассмотрению механизмов исполнения или ресур-
сов, относящихся к функциональному блоку. В понятие механизма исполне-
ния входят персонал, оборудование, информационные системы и т.п. Напри-
94
 95

мер, функциональный блок "Собрать деталь" может потребовать использова-

ния какого-либо оборудования, например, гаечного ключа. При приеме экза-
менов на водительские права механизмом исполнения является инспектор
ГИБДД. Как правило, определить механизмы исполнения для функциональ-
ных блоков довольно просто.
Определение управления. Наконец, должно быть определено управле-
ние, контролирующее ход работы функционального блока. Все функцио-
нальные блоки в IDEF0 должны иметь хотя бы одно управление. В случаях
когда неясно, относить ли стрелку ко входу или к управлению, следует ее ри-
совать как управление. Важно помнить, что управление можно рассматри-
вать как особую форму входа функционального блока.
Когда контекстная диаграмма представляется завершенной, попробуй-
те задать следующие вопросы: обобщает ли диаграмма моделируемый биз-
нес-процесс, согласуется ли диаграмма с границами моделирования, точкой
зрения и целью моделирования, подходит ли выбранный уровень детализа-
ции стрелок для контекстного блока? (Обычно на контекстной диаграмме ре-
комендуется рисовать не более шести стрелок каждого типа.)

4.4.2.4. Связь между диаграммой и ее родительским функциональным

блоком

Функциональный блок декомпозируется, если необходимо детально описать его ра-

боту. При декомпозиции блока полезно рассмотреть его жизненный цикл, это поможет оп-
ределить функциональные блоки получающейся "детской" диаграммы. Например, жиз-
ненный цикл блока "Поджарить бифштекс" может выглядеть как следующая последова-
тельность: "Подготовить продукты", "Отбить мясо", "Подогреть масло" и т.д.
При IDEF0-моделировании важно иметь в виду, что граница детской
диаграммы есть граница родительского функционального блока. Это означа-
ет, что вся работа выполняется блоками самого нижнего уровня. В отличие
от иерархии, применяемой в структурном программировании, блоки верхне-
го уровня не являются субъектами управления для блоков нижнего уровня.
Это означает, что в IDEF0 дети – это одни и те же объекты, что и их родите-
ли, только показанные с большей детализацией. Действия генерального ди-
ректора компании на IDEF0-диаграммах могут отражаться рядом с действия-
ми простых рабочих.
На концах граничных стрелок (начинающихся или заканчивающихся за
пределами диаграммы) детских диаграмм помещаются коды ICOM, чтобы
показать, где находится соответствующая стрелка на родительской диаграм-
ме (рис. 4.4.14). Они нужны для проверки целостности модели и могут быть
полезны, когда порядок расположения стрелок на детской диаграмме отлича-
ется от порядка их размещения на родительской диаграмме. Код ICOM со-
стоит из латинской буквы I, С, О или М и числа, показывающего расположе-
ние стрелки на родительской диаграмме в порядке сверху вниз или слева на-
право.

95
 96

Рис. 4.4.14. ICOM-коды на граничных стрелках

4.4.2.5. Два подхода к началу моделирования ("в ширину" и "в глуби-

ну")

Модели могут проектироваться как с использованием подхода "в ши-

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

4.4.2.6. Другие диаграммы IDEF0

В дополнение к контекстным диаграммам и диаграммам декомпозиции

при разработке и представлении моделей могут применяться Другие виды
IDEF0-диаграмм.
Дерево модели. Дерево модели – обзорная диаграмма, показывающая
структуру всей модели. На рис. 4.4.14 приведен фрагмент такой диаграммы.
Обычно вершина дерева соответствует контекстному блоку, под вершиной
выстраивается вся иерархия блоков модели.

96
 97

Рис. 4.4.14. Фрагмент дерева модели

Однако не запрещается назначать вершиной произвольный блок, по-
мещая под ним все его детские блоки. Из-за высокой итеративности функ-
ционального моделирования можно ожидать, что дерево модели будет неод-
нократно изменяться существенным образом до тех пор, пока не будет полу-
чена его стабильная версия. Обзор модели с использованием дерева помогает
сконцентрироваться на функциональной декомпозиции модели.
Презентационные диаграммы.Презентационные диаграммы (ForEx-
positionOnlydiagrams – FEOdiagrams) часто включают в модели, чтобы про-
иллюстрировать другие точки зрения или детали, выходящие за рамки тра-
диционного синтаксиса IDEF0. Диаграммы FEO допускают нарушение лю-
бых правил построения диаграмм IDEF0 в целях выделения важных с точки
зрения аналитика частей модели. Естественно, если диаграмма FEO включе-
на в модель исключительно для отображения другой точки зрения на систе-
му, она, скорее всего, внешне будет выглядеть как обыкновенная IDEF0-
диаграмма, удовлетворяя всем ограничениям IDEF0.
Один из способов использования FEO-диаграмм состоит в отделении
функционального блока от его окружения посредством создания диаграммы
с единственным блоком и всеми относящимися к нему стрелками наподобие
контекстной диаграммы (рис.4.4.15). Это может оказаться полезным в ситуа-
циях, когда необходимо быстро получить информацию об интерфейсе
(стрелках) функционального блока, а соответствующая диаграмма декомпо-
зиции содержит слишком много объектов.
Кроме того, встречаются следующие виды презентационных диаграмм:
• копия IDEF0-диаграммы, которая содержит все функциональные бло-
ки и стрелки, относящиеся только к одному из функциональных блоков, – это
позволяет отразить взаимодействие между этим блоком и другими объектами
диаграммы;
• копия IDEF0-диаграммы, которая содержит все функциональные бло-
ки и стрелки, непосредственно относящиеся только ко входу и/или выходу
родительского блока;
• различные точки зрения, как правило, на глубину одного уровня де-
композиции.

97
 98

Рис. 4.4.15.. Диаграмма FEO для выделения функционального блока и

его стрелок

98
 99

Разработанная модель IDEF00 со всеми уровнями структурной декомпози-

декомпоз
цией может быть представлена на единственной диаграмме в виде дерева узлов,
99
 100

дополняющего перечень узлов. Для изображения этого дерева нет стандартного

формата. Единственное требование состоит в том, что вся иерархия узлов мо-
дели должна быть представлена наглядно и понятно. Пример дерева узлов по-
казан на рис.4.4.16.

Лекция 9.

4.4.3. Методология описания бизнес-процессов IDEF3

Методология IDEF3 – это способ описания процессов с использованием

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

100
 101

Рис.4.4.17.. Описание процесса в методологии IDEF3.3.

Также важным для системного аналитика является понимание цели мод моде-
лирования – набора вопросов, ответами на которые будет служить модель, гр гра-
ниц моделирования – какие части системы войдут, а какие не будут отображе-
отображ
ны в модели, и целевой аудитории –для
для кого разрабатывается модель.
Главной организационной единицей модели
моделиIDEF33 является
являетс диаграмма.
Взаимная организация диаграмм внутри модели IDEF33 особенно важна в том
случае, когда модель создается для последующего опубликования или реценз
рецензи-
рования. В этом случае системный аналитик должен позаботиться о таком и ин-
формационном наполнении диа диаграмм,
грамм, чтобы каждая из них была самодоста-
самодост
точной и в то же время понятной пользователю.
Другой важной компонентой в модели IDEF33 является действие, или
«единица работы» (Unitofwork
Unitofwork – UOW). Диаграммы IDEF3
IDEF отображают дейст-
вие в виде прямоугольников, причем действие именуется с использованием
глаголов и отглагольных существительных. Действию присваивается уникалуникаль-
ный идентифицированный номер, который не используется вновь даже в тех
случаях, когда в процессе построения модели действие удаляется. В диагра
диаграм-
мах IDEF33 номер действия обычно предваряется номером его родителя (см.
рис. 4.4.18).
Взаимоотношения между действиями определяются связями. Все связи в
IDEF33 являются однонаправленными, и хотя стрелка может начинаться или зза-
канчиваться на любой стороне блока, ообозначающего
бозначающего действие, диаграммы
IDEF3,
3, как правило, организуются слева направо таким образом, что стрелки
начинаются на правой, а заканчиваются на левой стороне блока. Возможные
типы связей между действиями сведены в табл.
табл.4.4.3.

101
 102

Рис. 4.4.18.. Изображение и нумерация действий в диаграмме IDEF3

Таблица 4.4.3.. Возможные типы связей между действиями

Изображение Название Назначение

Исходное дейст-
вие должно за-
Временное вершиться, преж-
предшествование(
предшествование(Temporalprecedence) де чем конечное
действие сможет
начаться
Выход исходного
действия является
входом конечного
действия. Из это-
го, в частности,
следует, что ис-
Объектный поток ((Objectflow)
ходное действие
должно завер-
шиться прежде,
чем конечное дей-
ствие сможет на-
чаться
Вид взаимодейст-
вия между исход-
ным и конечным
действиями зада-
Нечеткое отношение ((Relationship) ется аналитиком
отдельно для каж-
дого случая ис-
пользования тако-
го отношения

Связь типа «временное предшествование». Как видно из названия, св

свя-
зи этого типа показывают, что исходное действие должно полностью завер-
заве
102
 103

шиться, прежде чем начнется выполнение конечного действия. Связь должна

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

Принять рекомен-
Принять Внести исправле-
исправл
дации рецензентов исправления ния

1.1
1.2

Рис. 4.4.19
4.19.. Связь типа «временное предшествование» между
действиями 1.1 и 1.2
Связь типа «объектный поток»поток».. Одна из наиболее часто встречаю-
встреча
щихся причин использования связи типа «объектный поток» заключается в
том,, что некоторый объект, являющийся результатом выполнения исходного
действия, необходим для выполнения конечного действия. Обозначение тта-
кой связи отличается от связи временного предшествования двойной стре стрел-
кой. Наименования потоковых связей должны четко и идентифицировать
дентифицировать объ-
об
ект, который передается q их помощью. Временная семантика объектных
связей аналогична связям предшествования, это означает, что порождающее
объектную связь исходное действие должно завершиться, прежде чем коне конеч-
ное действие может начать ввыполняться,
ыполняться, как показано на рис. 4.4.20. В при-
веденном примере счет на оплату услуг является результатом выполнения
действия 1.1.

Рис. 4.4.20.. Объектная связь между действиями 1.1 и 1.2

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

103
 104

Рис.4.4.21.. Связь типа «нечеткое отношение»

Наиболее часто нечеткие отн отношения
ошения используются для описания спе-
сп
циальных случаев связей предшествования, например, для описания альте альтер-
нативных вариантов временного предшествования. На рис рис.4.4.22. вертикаль-
ные линии показывают начало и окончание действий 1.1 и 1.2, имеющих
предшественную ную связь. В соответствии с порядком действий, показанным на
рис. 4.4.19,, внесение исправлений в работу начинается после принятия всех
замечаний от рецензентов.

Рис. 4.4.22 Временная шкала выполнения действий для рис. 3.6.3.

Связь нечеткого отношения, ал альтернативная
ьтернативная предшествованной
предшеств связи
на рис. 4.4.19,, представлена на рис. 4.4.23.. В этом примере внесение исправ-
испра
лений начинается по мере получения замечаний от рецензентов, т.е. до неп непо-
средственного окончания действия по принятию замечаний.

Рис. 4.4.23. Альтернативная связь предшествования

На рис. 4.4.24 приведена соответствующая этой ситуации временная

шкала.

Рис. 4.4.24.. Альтернативная временная шкала

Отметим еще раз необходимость четкого документирования време

времен-
ных ограничений между действиями, соединенными нечетким отношением.

104
 105

В качестве примера рассмотрим еще одну временную шкалу для рис. 4.4.19
(рис. 4.4.25).

Начало А1.2 Окончание А1.2

Рис. 4.4.25.. Вариант альтернативной временной шкалы

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

105
 106

Таблица 4.4..4. Типы соединений

Графическое обо- Правила инициа-
Название Вид
значение ции
Каждое конечное
действие обяза-
Разворачивающее
тельно иниции-
руется
& Соединение «и»
Каждое исходное
действие обяза-
Сворачивающее
тельно должно
завершиться
Одно и только
одно конечное
Разворачивающее
действие ини-
Соединение «эк
«экс-
циируется
X клюзивное
Одно и только
“или”»
одно исходное
Сворачивающее
действие должно
завершиться
Одно или не-
сколько конеч-
Разворачивающее
ных действий
инициируются
Соединение
O Одно или не-
«или»
сколько исход-
Сворачивающее ных действий
должны завер-
шиться

Примеры разворачивающих и сворачивающих соединений приведены

на рис. 4.4.26.

Рис. 4.4.26.. Два вида соединений

«И»-соединения
соединения.. Соединения этого типа инициируют выполнение ко-
к
нечных действий. Все действия, присоединенные к сворачивающему «и»«и»-
соединению, должны
жны завершиться, прежде чем начнется выполнение слсле-
дующего действия. На рис. 4.4.27 после обнаружения пожара инициируются
106
 107

включение пожарной сигнализации, вызов пожарной охраны, и начинается

тушение пожара. Запись в журнал производится только тогда, когда все три
перечисленных действия завершены.
Соединение «эксклюзивное “или”». Вне зависимости от количества
действий, связанных со сворачивающим или разворачивающим соединением
«эксклюзивное “или”», инициировано будет только одно из них, и поэтому
только оно будет завершено перед тем, как любое действие, следующее за
сворачивающим соединением «эксклюзивное “или”», сможет начаться. Если
правила активации соединения известны, они обязательно должны быть ддо-
кументированы либо в его описании, либо пометкой стрелок, исходящих из
разворачивающего соединения, как показано на рис. 3.6.12.

Рис.4.4.27. «И»--соединения

Рис. 4.4.28.. Соединение «эксклюзивное “или”»

Соединение «или» предназначено для описания ситуаций, которые не
могут быть описаны двумя предыдущими типами соединений. Аналогично
связи нечеткого отношения соединение «или» в основном определяется и
описывается непосредственно системным аналитиком. На рис. 4.4.29
4 соеди-
нение J22 может активизировать проверку данных чека и/или проверку суммы
наличных. Проверка чека инициируется, если покупатель желает расплатит
расплатить-
ся чеком, проверка суммы наличных – при оплате наличными. И то, и другое
107
 108

действие инициируются при частичной оплат

оплатее как чеком, так и наличными.

Рис. 4.4.29.. Соединение «или»

Синхронные и асинхронные соединения. В рассмотренных примерах
связей «и» и «или» мы не затрагивали отношения между началом и оконч
оконча-
нием действий, инициируемых разворачивающими соединениями. Все дей-
ствия в этих примерах выполнялись асинхронно, т.е. они не инициируются
одновременно. Однако есть случаи, когда время начала или окончания п
па-
раллельно выполняемых действий должно быть одинаковым, т.е. действия
должны выполняться синхронно. Для моделиров
моделирования
ания такого поведения сис-
си
темы используются различные виды синхронных соединений (табл. 4.4.5).
Синхронное соединение обозначается двумя вертикальными линиями
внутри прямоугольника.
Во многих спортивных состязаниях выстрел стартового пистолета, зза-
пуск секундомера
домера и начало состязания должны произойти одновременно. В
противном случае состязание будет нечестным. На рис. 3.6.14 представлена
модель этого примера, построенная с использованием синхронного соедин
соедине-
ния.
Заметим, что синхронное разворачивающее соединен
соединение не обязательно
должно иметь парное себе сворачивающее соединение. Действительно, нач
начи-
нающиеся одновременно действия вовсе не должны оканчиваться одновр
одновре-
менно, как это видно из примера с состязаниями. Также возможны ситуации
синхронного окончания асинхро
асинхронно
нно начавшихся действий.

108
 109

Таблица 4.4.5.. Виды синхронных соединений

Графическое
Тип Вид Правила инициации
обозначение
Разворачиваю- Все действия начнутся
Соединение щее одновременно
& «и» Сворачиваю- Все действия закончатся
щее одновременно
Может быть, несколько
Разворачиваю-
действий начнутся одно-
одн
щее
Соединение временно
О «или» Может быть, несколько
Сворачиваю-
действий закончатся од-
о
щее
новременно
Разворачиваю- Одновременное начало
Соединение щее действий невозможно
«эксклюзи
«эксклюзив- Одновременное оконча-
оконч
Х
ное «или»» Сворачиваю- ние действий невозмож-
невозмо
щее
но

Рис.4.4.30. Синхронное соединение

Парность соединений. Все соединения на диаграммах должны быть
парными, из чего следует, что любое разворачивающее соединение имеет
парное себе сворачивающее. Однако типы соединений не обязательно дол
долж-
ны совпадать. На рис. 4.4.31 разворачивающее «и»-соединение
соединение имеет парное
сворачивающее «или»
«или»-соединение.
соединение. Интерпретация соединения J1 аналогична
случаю, показанному на рис. 4.4.27. Соединение J22 интерпретируется
интер сле-
дующим образом: после включения пожарной сигнализации и/или вызова
пожарных, и/или начала тушения производится запись в журнал.
Комбинация соединений. Соединения могут комбинироваться для соз-со
дания более сложных ветвлений (рис. 4.4.32). Комбинации
нации соединений сле-
сл

109
 110

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

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

Рис.4.4.31 Пример комбинации двух типов соединений

Рис. 4.4.326.
6. Диаграмма IDEF33 с комбинацией соединений

Для ссылки на другие разделы описания процесса используют указат

указате-

ли – специальные символы. Они позволяют привлечь внимание пользователя

к каким-либо
либо важным аспектам модели.

Указатель изображается на диаграмме в виде прямоугольника, похож

похоже-

го на изображение действия. Имя указателя обычно включает его тип (н

(на-

пример, ОБЪЕКТ, UOB и т.п.) и идентификатор (табл. 4.44.6).

110
 111

Таблица 4.4.6. Указатели и их назначения

Тип указателя Назначение
Для описания того, что в действии принимает
ОБЪЕКТ(OBJECT) участие какой-либо заслуживающий отдельно-
го внимания объект
Для реализации цикличности выполнения дей-
ССЫЛКА(GOTO) ствий. Указатель ССЫЛКА может относиться
и к соединению
Для многократного отображения на диаграмме
одного т того же действия. Например, если
ЕДИНИЦАДЕЙСТВИЯ(Unit действие «Подсчет наличных» выполняется
of Behavior – UOB) несколько раз, в первый раз оно создается как
действие, а последующие его появления на
диаграмме оформляются указателями UOB
Для документирования любой важной инфор-
мации общего характера, относящейся к изо-
браженному на диаграммах. В этом смысле
ЗАМЕТКА(NOTE)
ССЫЛКА служит альтернативой методу по-
мещения текстовых заметок непосредственно
на диаграммах
Для уточнения или более подробного описа-
УТОЧНЕНИЕ(Elaboration – ния изображенного на диаграмме. Указатель
ELAB) УТОЧНЕНИЕ обычно используется для опи-
сания логики ветвления у соединений

На рис. 4.4.33 показан указатель типа ОБЪЕКТ.На рис. 4.4.34 показан

пример отображения важного для данной модели отношения между действи-
ем и объектом.
Действия в IDEF3 могут быть декомпозированы или разложены на со-
ставляющие для более детального анализа. Метод IDEF3 позволяет декомпо-
зировать действие несколько раз, что обеспечивает документирование аль-
тернативных потоков процесса в одной модели.
Для корректной идентификации действий в модели с множественными
декомпозициями схема нумерации действий расширяется и наряду с номера-
ми действия и его родителя включает в себя порядковый номер декомпози-
ции. Например, в номере действия 1.2.5: 1 –номер родительского действия, 2
– номер декомпозиции, 5 – номер действия.

111
 112

Рис. 4.4.33.. Указатель ОБЪЕКТ Рис.4.4.34.Указатель

.Указатель ОБЪЕКТ
ссылается на дей
действие

IDEF3-диаграмма
диаграмма может быть построена на основании описания про- пр
цесса, выраженного в текстовом виде. В таком построении диаграммы пр при-
нимают участие ее автор – системный аналитик и один или несколько экс- эк
пертов предметной области, представившие описание процесса.
Для экспертов пред
предметной
метной области, подготавливающих описание мо- м
делируемого процесса, должны быть документированы границы моделир моделиро-
вания, чтобы им была понятна необходимая глубина и полнота требуемого от
них описания. Кроме того, если точка зрения аналитика на процесс отличае
отличает-
ся от точки зрения эксперта, это должно быть ясно и подробно обосновано.
Вполне возможно, что эксперты не смогут сделать приемлемое опис описа-
ние без их формального опроса автором модели. В таком случае автор до дол-
жен заранее подготовить перечень вопросов таким ж жее образом, как журна-
журн
лист для интервью.
Результатом работы экспертов обычно является текстовый документ,
описывающий интересующий аналитика круг вопросов. В дополнение к нему
может прилагаться письменная документация, позволяющая определить пр при-
роду изучаемого го процесса. Вне зависимости от того, является ли информация
текстовой или вербальной, она анализируется и разделяется частями речи для
идентификации списка действий (глаголы или отглагольные существител
существитель-
ные), составляющих процесс, и объектов (имена сущестсуществительных), участ-
вующих в процессе.
В некоторых случаях возможно создание графической модели процесса
при участии экспертов. Такая модель может быть разработана после сбора
всей необходимой информации, что позволяет не отнимать время экспертов
на детали формирования
рмирования получающихся диаграмм.
Поскольку модели IDEF33 могут одновременно разрабатываться не- н
сколькими командами, IDEF33 поддерживает простую схему резервирования
номеров действий в модели. Каждому аналитику выделяется уникальный
диапазон номеров действий; что обеспечивает их независимость друг от дру-др
га. В табл. 4.4.7 номера действий выделяются каждому аналитику большими
блоками. В этом примере аналитик 1 полностью использовал данный ему
вначале диапазон номеров и дополнительно получил второй.
112
 113

Таблица 4.4.7. Резервирование номеров действий

Аналитик Диапазон номеров IDEF3
1 1–99
2 100–199
3 200–299
1 300–399
Если модель создается после проведения интервью, аналитик должен
принять решение по построению иерархии участвующих в модели диаграмм,
например, насколько подробно будет детализироваться каждая отдельно взя-
тая диаграмма. Если последовательность или параллельность выполнения
действий окончательно не ясна, эксперты могут быть опрошены вторично
(возможно, с использованием черновых вариантов незаконченных диаграмм)
для получения недостающей информации. Важно, однако, различать предпо-
лагаемую (появляющуюся из-за недостатка информации о связях) и явную
(указанную в описании эксперта) неясности.
Выводы.IDEF3 - это способ описания бизнес-процессов, который ну-
жен для описания положения вещей как упорядоченной последовательности
событий с одновременным описанием объектов, имеющих непосредственное
отношение к процессу.
IDEF3 хорошо приспособлен для сбора данных, требующихся для про-
ведения структурного анализа системы. Кроме того, IDEF3 применяется при
проведении стоимостного анализа поведения модели требуемой системы.
Лекция 8.
4.4.4. Структурный анализ потоков данных с помощью диаграмм DFD

Так же, как и диаграммы IDEF0, диаграммы потоков данных (DataF-

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

113
 114

Рис. 4.4.35. Пример DFDдиаграммы

В отличие от стрелок в IDEF0, которые иллюстрируют отношения,

стрелки в DFD показывают, как объекты (включая и данные) реально пере-
мещаются от одного действия к другому. Это представление потока обеспе-
114
 115

чивает отражение в DFD

DFD-моделях
моделях таких физических характеристик системы,
как движение объектов (потоки данных), хранение объектов (хранилища
данных), источники и потребители объектов (внешние сущности).
Построение DFD
DFD-диаграмм
диаграмм в основном ассоциируется с разработкой
программного обеспечения, поскольку нотация DFD изначально была разра-
разр
ботанаа для этих целей. В отличие от IDEF0,
0, рассматривающего систему как
множество взаимопересекающихся действий, в названиях объектов DFD-
диаграмм преобладают имена существительные; Контекстная DFD-
диаграмма часто состоит из одного функционального блока и неско
нескольких
внешних сущностей. Функциональный блок на этой диаграмме обычно имеет
имя, совпадающее с именем всей системы (рис. 4.4.36).

Рис. 4.4.36. Контекстная DFD-диаграмма

диаграмма

Добавление на диаграмму внешних ссылок не изменяет фундаментал

фундаменталь-
ного требования, что модель должна строиться с единственной точки зрения
и иметь четко определенные цель и границы.
Функциональный блок DFD моделирует некоторую функцию, которая
преобразует сырье в какую
какую-либо
либо продукцию (или, в терминах IDEF, вход в
выход). Хотя функциональные блоки DFD и изображаются в виде прямо-прям
угольников с закругленными углами, они почти идентичны функциональным
блокам IDEF00 и действиям IDEF3. Как и действия IDEF3,
IDEF функциональные
блоки DFD имеют входы и выходы, но не имеют управления и механизма
исполнения, как IDEF
IDEF0.
0. В некоторых интерпретациях нотации DFD Гейна-
Сарсона механизмы исполнения IDEF00 моделируются как ресурсы и изобра-
жаются в нижней части прямоугольника (рис. 4.4.37).

115
 116

Рис. 4.4.37.. Элемент DFD-диаграммы,

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

Рис. 4.4.38.. Обозначение внешней сущности

Стрелки описывают передвижение (поток) объектов от одной части системы к др

дру-
гой. Поскольку все стороны обозначающего функциональный блок DFD прямоугольника
равнозначны (в отличие от IDEF0),
0), стрелки могут начинаться и заканчиваться в любой час-
ча
ти блока. В DFD также используются двунаправленные стрелки, которые нужны для от
ото-
бражения взаимодействия между блоками (например, диалога типа «приказ
«приказ–результат вы-
полнения»).
На рис. 4.4.390 двунаправленная стрелка обозначает взаимный обмен информацией
между департаментом маркетинга и рекламы и департаментом пластиковых карт.

116
 117

Рис. 4.4.39.. Двунаправленный поток между блоком и внешней

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

Рис. 4.4.40.. Обозначение хранилища данных на DFD-диаграмме

DFD

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

Рис. 3.6.42. Разветвление стрелки, иллюстрирующее декомпозицию

данных

Стрелки могут соединяться между собой(объединяться) для формир

формиро-
вания так называемых комплексных объектов. Пример такого объединения
приведен на рис. 4.4.4
.42.

117
 118

Рис.4.4.42.. Объединение п
потоков в один

Диаграммы DFD можно строить с использованием подхода, аналогич-

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

Затем строится модель окружения, описывающая систему как объект,

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

На заключительном этапе создается модель поведения, показывающая,

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

118
 119

рощенных родительских диаграмм посредством объединения нескольких

функциональных блоков в один, так и, наоборот, декомпозиция некоторых
элементов для более легкого восприятия модели.
В DFD каждый номер функционального блока может включать в себя
префикс, номер родительской диаграммы и собственно номер объекта (рис.
4.4.43).). Номер объекта уникальным образом идентифицирует функциональ-
функционал
ный блок на диаграмме. Номер родительской диаграммы и номер объекта
всовокупности обеспечивают уникальную идентификацию каждого блока
модели.
Уникальные номера присваиваются также каждому хранилищу данных
и каждой внешней сущности вне зависимости от расположения объекта на
диаграмме. Каждый номер хранилища данных содержит префикс D (DataS-
tore)) и уникальный номер хранилища в модели (например, D3).

Рис. 4.4.43.. Компоненты номера функционального блока DFD

Аналогично, номер каждой внешней сущности содержит префикс Е

(Externalentity)) и уникальный номер сущности в модели (например, Е5).
Таким образом, диаграммы потоков данных ((DFD)) обеспечивают удоб-
удо
ный способ описания передаваемой информации, как между частями мод моде-
лируемой системы,
темы, так и между системой и внешним миром. Это качество
определяет область применения DFD – они используются для создания моде-мод
лей информационного обмена организации, например модели документооб
документообо-
рота. Кроме того, различные вариации DFD широко применяются при п по-
строении корпоративных информационных систем.
4.5.. Особенности разработки требований к программному обеспечению АС
4.5.1.
.1. Участники разработки и структура требований к ПО
В разработке требований к программному обеспечению (ПО) заинтер
заинтере-
сованы различные лица, такие как:
1. заказчики, которые финансируют проект или приобретают продукт
для решения каких-то то своих задач;
2. пользователи, которые взаимодействуют напрямую или не напрямую
с приложениями (подкласс заказчиков);
3. аналитики требований, которые пишут требования и передают их
разработчикам;
4. разработчики, которые создают, разворачивают и поддерживают
продукт;
119
 120

5. тестеры, которые определяют соответствие поведения ПО желаемо-

му;
6. технические писатели, которые отвечают за создание руководства
пользователей, тренировочные материалы и справочную систему;
7. менеджер по проекту, который планирует процесс и руководит ко-
мандой разработчиков вплоть до успешного выпуска продукта;
8. сотрудники правового отдела, которые следят, чтобы продукт не
противоречил всем действующим законам и постановлениям;
9. производственники, которые должны построить продукт, содержа-
щий данное ПО;
10. сотрудники отдела продаж и маркетинга, выездной службы под-
держки и другие, кому придется работать с продуктом и его пользователями.
Так как требования представляют собой основу для действий и разра-
ботчиков и менеджеров проекта, все заинтересованные в проекте лица долж-
ны быть вовлечены в создание этого документа.
Требование к ПО состоит из трех уровней:
– бизнес – требования,
- требования пользователей,
- функциональные требования.
Вдобавок каждая система имеет свои нефункциональные требования.
Модель на рис. 4.5.1 иллюстрирует способ представления этих типов
требований. Как и все модели, она не полная, но схематично показывает ор-
ганизацию требований. Овалы обозначают типы информации для требова-
ний, а прямоугольники – способ хранения информации в виде документов,
диаграмм, баз данных.

Рис. 4.5.1. Взаимосвязи нескольких типов информации для требований

120
 121

Бизнес-требования содержат высокоуровневые цели организации или

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

121
 122

В дополнение к функциональным требованиям спецификация содержит

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

Люди часто рассуждают о характеристиках продукта. Характеристика –

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

В качестве примеров характеристик продуктов можно привести из-

бранные страницы или закладки Web-браузера, контроль над орфографией,
запись макрокоманды, сервопривод стекла в автомобиле, онлайновое обнов-
ление или изменение налогового кодекса, ускоренный набор телефонного
номера или автоматическое определение вируса. Характеристики могут ох-
ватывать множество вариантов использования, и для каждого варианта необ-
ходимо, чтобы множество функциональных требований было реализовано
для выполнения пользователем его задач.
Чтобы лучше воспринять некоторые из различных видов требований,
рассмотрим простую программу подготовки текстов. Бизнес-требование мо-
жет выглядеть следующим образом: «Продукт позволит пользователю ис-
правлять орфографические ошибки в тексте эффективно». На коробке CD-
ROM указано, что проверка грамматики включена как характеристика, удов-
летворяющая бизнес-требованиям. Соответствующие требования пользова-
телей могут содержать задачи или варианты использования вроде такой:
«Найдите орфографическую ошибку» или «Добавьте слово в общий сло-
варь». Проверка грамматики имеет множество индивидуальных функцио-
нальных требований, которые связаны с такими операциями, как поиск и вы-
деление слова с ошибкой, отображение диалогового окна с фрагментом тек-
ста, где это слово находится, и замена слова с ошибкой корректным вариан-
том по всему тексту. Атрибут качества легкость и простота использования
как раз и определяет его значение посредством слова «эффективно» в бизнес-
требованиях.

122
 123

Менеджеры и сотрудники отдела маркетинга определяют бизнес-

требования для ПО, которые помогут их компании работать эффективнее
(для информационных систем) или успешно конкурировать на рынке (для
коммерческих продуктов). Каждое требование пользователя должно быть со-
поставлено бизнес-требованию. На основе требований пользователя аналити-
ки определяют функции, которые позволят пользователям выполнять их за-
дачи. Разработчикам необходимы функциональные и нефункциональные
требования, чтобы создавать решения с желаемой функциональностью, опре-
деленным качеством и требуемыми рабочими характеристиками, не выходя
за рамки налагаемых ограничений.
Хотя в модели на рис. 4.5.1 показан поток требований в направлении
сверху вниз, следует ожидать и циклов, и итераций между бизнес-
требованиями, требованиями пользователей и функциональными требова-
ниями. Кто бы когда бы ни предложил новые характеристики, варианты ис-
пользования или функциональные требования, аналитик должен спросить:
«Они попадают в указанные границы?» Если ответ «да», то они соответству-
ют спецификации. На «нет», как известно, и суда нет. А вот если ответ «нет,
но они должны там быть», то заказчик или тот, кто финансирует проект,
должен решить, готов ли он раздвинуть границы проекта, чтобы принять но-
вое требование.
Спецификация требований не содержит деталей дизайна или реализа-
ции (кроме известных ограничений), данных о планировании проекта или
сведений о тестировании. Эти элементы следует удалить из требований, что-
бы из этого документа было абсолютно ясно, что необходимо построить ко-
манде разработчиков. Дело в том, что для проекта в целом, как правило, соз-
даются требования других типов, такие как среда разработки, ограничения
бюджета, руководство пользователя, требования к выпуску продукта и про-
движения его в поддерживаемую среду.

4.5.2. Этапы разработки требований, риски возникновения ошибок

Понятие «требование к ПО» требует уточнения, для чего полезным яв-

ляется разделение этого понятия на собственно разработку требований к ПО

и на управление требованиями. Это показано на рис. 4.5.2.

123
 124

Рис. 4.5.2.
Лекция 9

3.3.2. Этапы разработки требований, риски возникновения ошибок

Как показано на рис. 4.5.2, разработку требований можно подразделить

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

124
 125

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

заться за создание этого продукта. К действиям по управлению требованиями
относятся:
- определение основной версии требований, т.е. моментальный срез
требований для конкретной версии продукта;
- просмотр предлагаемых изменений требований и оценка вероятности
воздействия каждого изменения до его принятия;
- включение одобренных изменений требований в проект установлен-
ным способом;
- согласование плана проекта с требованиями;
- обсуждение новых обязательств, основанных на оцененном влиянии
изменения требований;
- отслеживание отдельных требований до их дизайна, исходного кода и
вариантов тестирования;
- отслеживание статуса требований и действий по изменению на про-
тяжении всего проекта.
В связи со сказанным можно представить другой способ разделения
областей разработки требований и управления ими (см. рис. 4.5.3).
В заключение отметим, что основное следствие проблемы с требова-
ниями – переделка того, что как вы думаете, уже готово. На это расходуется
от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от
70 до 85% стоимости переделки. Следовательно, предотвращение ошибок в
требованиях и обнаружение их на ранних стадиях сильно уменьшает объем
переделки.
Рассмотрим наиболее общие риски возникновения ошибок в разрабо-
танных требованиях к ПО.

Рис. 4.5.3.
125
 126

Недостаточное вовлечение пользователей. Заказчики не понимают, по-

чему так важно тщательно собрать требования и обеспечить их качество. С
другой стороны, разработчики не всегда придают значение вовлечению поль-
зователей в процесс. Это объясняется тем, что среди разработчиков больше
фанатов написания кода, а не любителей возиться с клиентами. Кроме этого,
они считают, что все уже знают о потребностях пользователей. В любом слу-
чае трудно добраться до людей, которые непосредственно будут иметь дело с
продуктом, и выразители мнения пользователей не всегда понимают, что тем
нужно в реальности. Недостаточное вовлечение пользователей ведет к обна-
ружению ошибок в требованиях на поздних стадиях проекта, а значит к за-
держке завершения проекта.
«Разрастание» требований пользователей. Так как требования тщатель-
но прорабатываются, то их объем со временем увеличивается. Поэтому про-
ект часто выходит за установленные рамки, как по срокам, так и по бюджету.
Первоначально принятые планы не всегда основаны на реалистичном пони-
мании размера и сложности требований, ограничение же на модификацию
только усиливает проблемы. Эти проблемы частично кроются в частых за-
просах пользователей на изменения, а частично – в том, каким способом раз-
работчики отвечают на них.
Чтобы управлять границами требований, для начала необходимо уточ-
нить бизнес-цели проекта, основы его образа, рамки, ограничения, критерии
успеха и ожидаемую пользу. Необходимо также оценить, как предполагае-
мые характеристики или изменения требований отразятся на связанной с ни-
ми структуре. Эффективный процесс модификации заставляет активно рабо-
тать аналитиков, которые помогут всем заинтересованным лицам принять ра-
зумные бизнес-решения относительно того, какие изменения следует при-
нять, и увязать их стоимость со временем, ресурсами или возможными ком-
промиссами. Изменения критически важны для успеха проекта, однако они
всегда имеют определенную цену.
По мере того, как продукт модифицируется в процессе разработки, его
архитектура может медленно разрушаться. «Заплатки» кода затрудняют по-
нимание и поддержку продукта. Добавление кода может стать причиной на-
рушения твердых и взаимосвязанных принципов дизайна и разрыва связей.
Чтобы минимизировать возможность потери качества продукта в результате
проблем такого рода, вначале необходимо протестировать то, как возможные
изменения отразятся на архитектуре и дизайне, а уже потом реализовать их в
коде.
Двусмысленность требований. Двусмысленность – это одна из страши-
лок спецификации требований. Один из ее симптомов – это когда пользова-
тель имеет возможность интерпретировать одно и то же положение по-
разному. Другой симптом – это, когда у нескольких читателей требований
возникает разное представление о продукте. Двусмысленность часто проис-
текает из неточности и плохой детализации требований, в результате чего
разработчикам приходится заполнять возникающие пробелы собственными
силами.
126
 127

Двусмысленность ведет и к формированию различных ожиданий у за-

интересованных лиц. Впоследствии некоторые из них удивляются «Что же
это получилось?» Разработчики же впустую тратят время, занимаясь не теми
проблемами. Одновременно тестеры готовятся к проверке не тех особенно-
стей поведения системы.
Один из способов обнаружить двусмысленности – пригласить различ-
ных представителей пользователей для официальной экспертизы требований.
Другой способ вскрыть двусмысленность – это написать вариант тестирова-
ния для требования и построить прототип.
«Золочение» продукта. Под «золочение» продукта понимают такие си-
туации, когда разработчики добавляют функции, которых нет в специфика-
ции, но им кажется, что это понравится пользователям. Зачастую же клиен-
там не нужны такие избыточные возможности, но это может привести к то-
му, что время, отведенное на их реализацию, будет тратиться впустую. Пре-
жде чем просто вставлять новые функции, разработчики и аналитики должны
представить свои творческие идеи на суд заказчика. Задача команды – четко
соблюдать требования спецификации, а не действовать за спиной клиентов
без одобрения.
Пользователи иногда требуют функции или элементы интерфейса, ко-
торые выглядят отлично, но не представляют особой ценности для продукта.
Все, что будет добавлено, стоит времени и денег, поэтому следует осознать
ценность своевременного выпуска продукта. Чтобы уменьшить «золочение»,
необходимо отслеживать каждый элемент функциональности до его первоис-
точника, чтобы четко понимать, почему именно он включен в продукт.
Минимальная спецификация. Иногда сотрудников отдела маркетинга
или менеджеров охватывает искушение создать урезанный вариант специфи-
кации, как, например, набросок концепций продуктов на салфетке. Они ожи-
дают, что разработчики «нарастят мясо» на основе этих набросков, пока про-
ект развивается. Это пригодно для тесно сплоченной команды, которая зани-
мается небольшой системой, или когда выполняется проект-исследование,
или когда требования действительно гибкие.
Пропуск классов пользователей. Большинство программных продук-
тов предназначены для нескольких групп пользователей, которые могут при-
менять различные наборы функций с разной частотой, и имеют опыт работы
с ПО самого широкого диапазона. Поэтому если не определены важные клас-
сы пользователей для разрабатываемого продукта заранее, то некоторые по-
требности клиентов не будут учтены.
Небрежное планирование. Неопределенные, недетализированные тре-
бования порождают слишком оптимистические оценки. Это «выходит бо-
ком», когда возникает перерасход средств. При плохо просчитанной смете
проект больше всего страдает из-за затрат на частые изменения требований,
пропущенных требований, недостаточного взаимодействия с пользователя-
ми, недетализированной спецификации требований и плохого анализа. Если
высказывается некоторая оценка требования, то необходимо указать для нее
либо качественные показатели типа лучший вариант, наиболее вероятный
127
 128

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

мнения, например, «Я на 90% уверен, что мы сделаем это за три месяца».
Сформулируем некоторые характеристики, которым должны удовле-
творять хорошо составленные требования.
Полнота. Каждое требование должно полно описывать функциональ-
ность, которую следует реализовать в продукте. Другими словами, требова-
ние должно содержать всю информацию, необходимую для разработчиков,
чтобы тем удалось создать соответствующий фрагмент программы. Если вы-
яснено, что данных определенного рода не хватает, следует в требованиях
сделать отметку в виде флага для выделения такого места. Следует воспол-
нить все проблемы в каждом фрагменте требований, прежде чем приступать
к конструированию этой функции.
Корректность. Каждое требование должно точно описывать желаемую
функциональность. Для соблюдения корректности необходима связь с источ-
никами требований, например, с пожеланиями пользователей или высоко-
уровневыми системными пожеланиями. Требования к ПО, которые конфлик-
туют с родительскими требованиями, нельзя считать корректными. Основная
оценка при этом – за представителями пользователей. Поэтому им или их не-
посредственным заместителям необходимо предоставлять требования для
просмотра.
Осуществимость. Необходима возможность реализовать каждое требо-
вание при известных условиях и ограничениях системы и операционной сре-
ды. Чтобы не придумывать недостижимые положения, необходимо обеспе-
чить взаимодействие разработчиков с маркетологами и аналитиками требо-
ваний на период всего извлечения требований. Разработчики реально оценят,
что можно выполнить технически, а что нет, или что сделать можно, но при
дополнительном финансировании.
Необходимость. Каждое требование должно отражать возможность,
которая действительно необходима пользователям или которая нужна для
соответствия внешним системным требованиям и стандартам. Кроме этого,
оно должно исходить от лица, которое имеет полномочия на запись положе-
ния. Необходимо отслеживать каждое требование вплоть до стадии сбора
пользователей, когда выявлялись варианты использования, бизнес-правила
или другие источники.
Назначение приоритетов. Необходимо назначить приоритеты каждому
функциональному требованию, характеристике или варианту использования,
чтобы определить, что необходимо для каждой версии продукта. Если все
положения одинаково важны, то менеджеру проекта будет трудно справиться
с уменьшением бюджета, нарушением сроков, потерей персонала или добав-
лением новых требований в процессе разработки.
Недвусмысленность. Все читатели требований должны интерпретиро-
вать их одинаково, но естественный язык зачастую грешит многозначностью.
Поэтому документацию необходимо писать просто, кратко, точно, применяя
лексику, понятную пользователям. Следует занести все специальные и запу-
танные термины в словарь.
128
 129

Проверяемость. Необходимо попробовать разработать несколько тес-

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

4.5.3. Права и обязанности разработчиков и клиентов ПО

Как правило, отличные программные продукты – это результат пра-

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

129
 130

1) все участники процесса разработки ПО знают, что необходимо им

для успеха;
2) когда они понимают и уважают стремление их соратников к успеху.
В связи со сказанным интересным является перечень прав и обязанно-
стей клиентов и разработчиков ПО. Это перечень можно представить в виде
своеобразных документов, которые назовем «Билль о правах клиента ПО» и
«Билль об обязанностях клиента ПО».
Билль о правах клиента ПО содержит 10 положений, на выполнении
которых клиенты могут на вполне законных основаниях настаивать при об-
щении с аналитиками и разработчиками на этапе формулирования требова-
ний к проекту. Каждый пункт этого права описывает соответствующую от-
ветственность аналитиков и разработчиков ПО.
Билль об обязанностях клиента ПО, напротив, содержит 10 положений,
определяющих ответственность клиента перед аналитиком и разработчиком
на этапе формулирования требований. Возможно, его стоить назвать поэтому
«Билль о правах разработчика ПО».

Рассмотрим вначале «Билль о правах клиента ПО при формировании

требований».
Клиент имеет право:
1. Иметь дело с аналитиком, который разговаривает на языке клиента.
Это означает, что аналитик использует при формировании требований при-
нятую в данном бизнесе терминологию. Для этого ему, возможно, необходи-
мо предоставить небольшой словарь применяемых в бизнесе терминов и оп-
ределений.
2. Иметь дело с аналитиком, хорошо изучившим бизнес клиента и цели,
для которых создается система. Это означает, что аналитик понимает задачи
бизнеса и осознает, какое место уготовано создаваемому ПО в этом бизнесе.
Если создаваемая система должна заменить существующее приложение, сле-
дует предложить разработчикам поработать с ним.
3. Потребовать, чтобы аналитик преобразовал требования, предостав-
ленные устно, в письменную спецификацию требований к программному
продукту. Это предполагает, что аналитик должен отсортировать всю ин-
формацию, предоставленную ему пользователями и другими клиентами, и
выявить на основе бизнес-требований, бизнес-правил, функциональных тре-
бований, целей качества, возможных решений и прочих элементов область
применения создаваемого ПО. Конечный итог этого анализа – спецификация
требований к ПО. Эта спецификация должна представлять собой соглашение
между разработчиками и клиентами о функциях, качестве и ограничениях
создаваемого продукта. Она должна быть организована и написана так, что-
бы пользователь мог ее легко понять. Если пользователя что-то не устраива-
ет, необходимо высказать свое мнение, чтобы оно нашло отражение в специ-
фикации.
4. Получить от аналитика подробный отчет обо всех рабочих продук-
тах, созданных в процессе формулирования требований. Это означает, что
130
 131

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

дополняющих текст спецификации требований к ПО. Альтернативные пред-
ставления требований очень важны, так как иногда графики позволяют яснее
выразить некоторые особенности поведения системы. Поэтому следует по-
просить аналитика объяснить назначение каждой из диаграмм, смысл обо-
значений и процедуру проверки диаграмм на предмет ошибок.
5.На уважительное и профессиональное отношение со стороны анали-
тиков и разработчиков. Если клиенты и разработчики не понимают друг дру-
га, обсуждение требований может обернуться большим разочарованием. Со-
вместная работа позволяет открыть друг другу глаза на проблемы, с которы-
ми сталкивается каждая из этих групп. Клиенты, участвующие в процессе
выработки требований, имеют полное право требовать от аналитиков и раз-
работчиков уважительного отношения к себе и бережного отношения к за-
траченному времени. В свою очередь, и клиентам следует оказывать уваже-
ние разработчикам.
6. Знать о вариантах и альтернативах требований и их реализации. Что-
бы гарантировать, что новая система не будет автоматизировать неэффектив-
ные или устаревшие процессы, аналитик должен знать, почему существую-
щие системы не годятся для ваших бизнес-процессов. Аналитики, основа-
тельно разбирающиеся в предметной области бизнеса, иногда предлагают те
или иные усовершенствования ваших бизнес-процессов. Полезен и аналитик,
творчески подходящий к делу: он предлагает новые возможности програм-
мы, о которых пользователи даже и не мечтали.
7. Описать характеристики, упрощающие работу с продуктом. Очень
вероятно, что аналитики спросят пользователя о характеристиках ПО, выхо-
дящих за рамки функциональных потребностей пользователей. Благодаря
этим потребностям программный продукт становится более удобным в рабо-
те, что позволяет клиентам эффективнее выполнять их задачи. Иногда поль-
зователи просят, чтобы продукт был дружественным, надежным или эффек-
тивным. Эти термины слишком субъективны, чтобы помочь разработчикам.
Поэтому аналитик должен выяснить конкретные характеристики, означаю-
щие для пользователя дружественность, надежность или эффективность.
8. Изменить требования или разрешить использование имеющихся
программных компонент. Отношение к требованиям должно быть гибким.
При этом аналитику могут быть известны готовые программные компонен-
ты, которые практически полностью удовлетворят некоторые названные
пользователем потребности. В таком случае следует скорректировать от-
дельные требования, чтобы разработчики могли использовать имеющееся
ПО.
9. Получить исчерпывающие сведения о сумме затрат, ожидаемом эф-
фекте и необходимых компромиссах, которые возникают в связи с измене-
ниями в ПО. Зная, что один вариант дороже другого, разные люди делают
разный выбор. Для принятия правильных бизнес-решений необходимы дан-
ные об эффективности и стоимости предполагаемого изменения требований.

131
 132

Поэтому у пользователя есть право ожидать от аналитиков добросовестной

оценки эффекта, затрат и компромиссов.
10. Потребовать, чтобы система функциональностью и качеством
удовлетворяла требованиям заказчика. Такого завершения проекта желают
все, однако он возможен, только если пользователь сумел донести до разра-
ботчиков всю информацию, которая поможет им создать подходящий про-
дукт, и если разработчики четко изложат пользователям все варианты и огра-
ничения. Поэтому следует убедиться в том, что были высказаны все ожида-
ния и предположения.
Рассмотрим теперь «Билль об обязанностях клиента ПО при формиро-
вании требований».
Клиент обязан:
1. Ознакомить аналитиков и разработчиков с особенностями своего
бизнеса. Это не означает, что следует делать аналитиков экспертами в пред-
метной области, основная задача – помочь им понять проблемы и цели биз-
неса. Невысказанные предположения о таких знаниях могут вызвать пробле-
мы в дальнейшем.
2. Потратить столько времени, сколько необходимо, на объяснение
требований. Клиенты – занятые люди, но и те, кто участвует в формулирова-
нии требований – обычно еще более занятые люди. Тем не менее, клиент
обязан потратить время на участие в совещаниях, мозговых штурмах, интер-
вью и прочих процедурах, необходимых для выявления требований. Иногда
аналитик считает, что понял идею пользователя, но позже сообразит, что ему
необходимы дополнительные разъяснения. Поэтому необходимо терпеливо
относиться к такому поэтапному подходу к формулированию и прояснению
требований. Необходимо терпимо относиться к глупым на взгляд пользова-
теля вопросам аналитика.
3. Точно и конкретно описать требования к системе. Весьма заманчиво
оставить требования неопределенными и нечеткими, ведь прояснять подроб-
ности утомительно и долго. Тем не менее, на каком-то этапе разработки уча-
стникам проекта необходимо устранить все неоднозначности и неточности.
Это может сделать только клиент - пользователь. В противном случае угады-
вать, что же именно нужно клиенту будут аналитики и разработчики. В спе-
цификации требований к программному обеспечению рекомендуется исполь-
зовать пометки типа «TBD» (tobedetermined – необходимо определить). Эти
пометки указывают на необходимость дополнительных исследований, анали-
за и информации. Иногда такие маркеры используют в случаях, когда кон-
кретное требование трудно определить точно и никто не хочет с ним возить-
ся. В таких случаях можно применять метод, когда пользователь и аналитик
формулируют требования поэтапно и постепенно.
4. Принимать своевременные решения. Точно так же, как и подрядчик
при строительстве дома, аналитик может задать клиенту множество вопросов
и попросить выбрать нужный вариант, т.е. принять необходимое решение.
Это может быть согласование противоречивых запросов от разных клиентов,
выбор между конфликтующими атрибутами качества и оценки точности ин-
132
 133

формации. Клиенты, обладающие соответствующими полномочиями, долж-

ны своевременно принять эти решения, когда их об этом попросят. В про-
тивном случае работа над проектом может затянуться.
5. Уважать определенную разработчиком оценку стоимости и возмож-
ность реализации заданных требований. Все программные функции чего-то
стоят. Разработчики лучше всего способны оценить эту стоимость, хотя мно-
гие из них и не имеют опыта в этом деле. Может оказаться, что некоторые
необходимые пользователям функции технически неосуществимы или их
реализация слишком дорога, например недостижимая в рабочей среде произ-
водительность или доступ к данным, которые системе просто недоступны.
Даже если сведения об осуществимости и стоимости некоторых функций,
сообщенные разработчиком, не понравятся пользователям, следует уважать
эту оценку. Иногда требования можно изменить так, что они станут дешевле
и достижимее.
6. Определить приоритеты требований. Только при работе над ограни-
ченным кругом задач можно рассчитывать время и ресурсы для реализации
всей желаемой функциональности. Определить, какие возможности необхо-
димы, какие полезны и без каких пользователи обойдутся, - важная состав-
ляющая анализа требований. Именно пользователи определяют эти приори-
теты, так как разработчики не в состоянии расставить приоритеты. Чтобы
пользователям облегчить задачу, разработчики предоставляют информацию
о стоимости и рисках всех требований. Определив приоритеты, можно по-
мочь разработчикам вовремя и с минимальными затратами создать макси-
мально эффективный продукт.
7. Просматривать документы с требованиями и оценивать прототипы.
Просмотр требований – одна из наиболее значимых операций, обеспечиваю-
щих качество ПО. Участие клиентов в таких просмотрах – единственный
способ узнать, отражены ли потребности клиента наиболее полно и точно.
Если клиенты не уверены в точности задокументированных требований, им
следует, как можно раньше, сообщить об этом лицам, ответственным за реа-
лизацию требований, и предложить варианты усовершенствования. Чтобы
лучше понять потребности клиента и выявить оптимальные способы их
удовлетворения, разработчики иногда создают прототипы предполагаемого
продукта. Ответная реакция пользователя на эти предварительные, частич-
ные или пробные версии дает разработчикам необходимую информацию.
Однако, прототип не является рабочим продуктом, поэтому по нему нельзя
еще судить о самом продукте.
8. Своевременно сообщать об изменениях требований. Постоянное из-
менение требований – серьезная угроза для возможности своевременной сда-
чи проекта командой разработчиков. Изменение неизбежно, но чем позже в
ходе разработки о нем сообщается, тем более сильное влияние оно окажет.
Изменения могут стоить дорого, и сроки будут нарушены, если клиент поже-
лает реализовать в практически завершенном проекте новую функциональ-
ность.

133
 134

9. Поддерживать принятый в организации-разработчике порядок кон-

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

4.5.4. Обязанности аналитика требований

Рассмотрим теперь вопросы, касающиеся аналитика требований.

Аналитик требований – это основное лицо, отвечающее за сбор, анализ,
документирование и проверку требований к проекту. Это основной комму-
никативный канал между группой клиентов и командой разработчиков, что
можно изобразить в виде следующей схемы (см. рис. 4.5.4).

134
 135

Аналитик требований – это одна из ролей участников проекта, а не обя-

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

Рис. 4.5.4
Задача аналитика – прежде всего, выяснить, для чего нужна пользова-
телям новая система, и затем определить функциональные и качественные
требования, на основе которых менеджеры проекта смогут оценить, разра-
ботчики – спроектировать и создать, а специалисты по тестированию – про-
верить продукт.
Аналитик обязан:

1. Определить бизнес-требования, для чего надо поработать со спонсо-

ром, менеджером проекта или менеджером по маркетингу.
2. Определить заинтересованных лиц и классы пользователей.
3. Выявить требования. Для этого аналитик должен помочь пользова-
телям четко обрисовать функции системы, необходимые им для достижения
бизнес-целей, используя различные способы сбора информации:
- интервью, опросы и семинары;
135
 136

- анализ бизнес-процессов и посещение рабочих мест клиентов;

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

1. Введение
1.1.Назначение
1.2.Соглашения, принятые в документах
1.3.Предполагаемая аудитория и рекомендации по чтению
1.4.Границы проекта
1.5.Ссылки
2. Общее описание
2.1.Общий взгляд на продукт
2.2.Особенности продукта
2.3.Классы и характеристики пользователей
2.4.Операционная среда
2.5.Ограничения дизайна и реализации
2.6.Документация для пользователей
2.7.Предположения и зависимости
3. Функции системы
3.х. Функция системы
3.х.1. Описание и приоритеты
3.х.2. Последовательности «воздействие - реакция»
3.х.3. Функциональные требования
4. Требования к внешнему интерфейсу
4.1.Интерфейсы пользователя
4.2.Интерфейсы оборудования
4.3.Интерфейсы ПО
4.4.Интерфейсы передачи информации
5. Другие нефункциональные требования
5.1.Требования к производительности
5.2.Требования к охране труда
5.3.Требования к безопасности
5.4.Атрибуты качества
136
 137

6. Остальные требования
Приложение А. Словарь терминов
Приложение Б. Модели анализа
Приложение В. Список вопросов
Рис. 4.4.5. Шаблон для спецификации требований к ПО
6. Моделировать требования. Аналитик должен определить, полезно
или нет представлять требования нетекстовыми средствами, например, с по-
мощью разнообразных моделей графического анализа, таблиц, математиче-
ских уравнений и т.п.
7. Управлять проверкой требований. Аналитик должен гарантировать,
что формулировки требований отвечают всем характеристикам и что систе-
ма на основе этих требований устроит пользователей. Аналитики участвуют
в обзорах документов с требованиями. Им также следует изучить архитекту-
ру, код и варианты тестирования, спроектированные на основе спецификации
требований, и убедиться, что требования интерпретированы правильно.
8. Обеспечить расстановку приоритетов требований.
9. Управлять требованиями. Управление требованиями подразумевает
контроль над состоянием отдельных функциональных требований по мере
степени готовности продукта. Расспрашивая коллег, аналитик собирает ин-
формацию о связях требований, сопоставляет их с прочими элементами сис-
темы. Аналитик – ключевая фигура в управлении изменениями базовых тре-
бований, для этого он применяет средства контроля изменений.
Лекция 10.
4.5.5. Управление требованиями ПО
Рассмотрим упрощенную схему процесса управления требованиями.
Все действия по выявлению, анализу, спецификации и проверке требо-
ваний выполняются не последовательно и не за один проход. На практике
они выполняются попеременно, поэтапно и повторяются (Рисунок 1.4).
Этап «выявление требований» - работа с клиентами в качестве анали-
тика; клиентам задаются вопросы, выслушиваются ответы, ведутся наблюде-
ния за действиями клиентов.
Далее обрабатывается полученная информация, классифицируется по
различным категориям и соотносятся потребности клиентов с возможными
требованиями к ПО – это «анализ требований». Затем информация от клиен-
тов оформляется и вырабатываются требования в виде письменных докумен-
тов и диаграмм («спецификация»), представителям пользователей предлага-
ется подтвердить, что написанный текст точен и полон, они могут исправить
ошибки, если таковые есть («проверка»).
«Определение приоритетов реализации требований» – аналитики опре-
деляют на основе различных критериев степень важности каждого требования.
137
 138

Последующие этапы – «учет изменений и контроль версий требований»,

«анализ рисков реализации требований», «анализ трудозатрат реализации тре-
бований», «анализ длительности и стоимости разработки».

Рис. 4.5.5. Обобщенная схема процесса управления требованиями.

Этот итерационный процесс и есть процедура управления требования-

ми.
Рассмотрим конкретную проектную организацию, занимающуюся раз-
работкой ПО. Ее структура представлена на рис 4.5.6.

138
 139

Рис.4.5.6.Структура проектной организации

Любое лицо из данной структуры может выступать в роли аналитика, в
зависимости от вида задач, которые ставит заказчик.
Отдел разработки обеспечивает реализацию требований, а именно, раз-
работку ПО.
Начальник отдела разработки (впоследствии будем именовать его «ру-
ководитель») отвечает за разработку программных продуктов, то есть непо-
средственно за выполнение требований. Именно он решает, какое требование
отправляется на разработку следующим.
Отдел технической поддержки обеспечивает функционирование вве-
ренного ему комплекса средств автоматизации (автоматизированной систе-
мы) во всех режимах работы системы в соответствии с установленным по-
рядком. В том числе:
- функционирование программно-технических средств;
- функционирование локальной вычислительной сети;
- функционирование средств телекоммуникаций и связи;
- функционирование систем пожарно-охранной сигнализации;
- анализ и устранение (в пределах установленных полномочий) аварий-
ных ситуаций в работе комплекса средств автоматизации, системы видео-
наблюдения, систем пожарно-охранной сигнализации;
- формирование и ведение информационных массивов и баз данных;
- защиту информации от несанкционированного доступа;
- формирование и ведение архивов страховочных копий общесистем-
ного и специального программного обеспечения и данных.
Также в обязанности отдела технической поддержки входит:
139
 140

- обеспечение оперативного управления комплексом средств автомати-

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

Рис. 4.5.7. Сетевой график жизненного цикла требований к ПО

В начале работы заказчик описывает концепцию или потребность в за-

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

ния безопасности, защиты и другие критические требования наряду с требова-

ниями к проектированию, тестированию и соответствующим стандартам и
процедурам. Если заказчик поручает поставщику выполнение анализа требо-
ваний к системе, то заказчик должен согласовать требования, сформулирован-
ные в результате анализа. Заказчик может выполнить эту процедуру сам или
поручить решение этой задачи поставщику.
- «Запись требования в БД» - поставщик выполняет данную процедуру
для хранения и обработки данных требования.
- «Предварительный анализ требования, выбор аналитика для работы с
данным требованием». Руководитель организации поставщика ПО или отде-
ла, конкретно занимающегося разработкой ПО, принимает решение по выбо-
ру аналитика для работы с определенным требованием, учитывая специфику
работы.
- «Детальный анализ требования, определение подзадач» - на данном
этапе аналитик разбивает требование на подзадачи, разрабатывает предвари-
тельные проектные решения по подзадачам.
- «Ввод в БД проекта решения по требованию», «подзадач для удовле-
творения каждого требования», - эти процедуры аналитик выполняет при по-
мощи соответствующих инструментов.
- «Составление плана тестирования». От этого этапа во многом зависит
качество итогового программного продукта. Наличие подробно специфици-
рованных требований позволяет проверить разработанный программный
продукт на соответствие требованиям. Такая проверка осуществляется путем
составления вариантов тестирования – вместе все варианты тестирования
должны покрывать 100% требований.
- «Утверждение проекта решения и поступление заявки в очередь на вы-
полнение» осуществляется при согласовании с заказчиком; на этом этапе
должно быть подтверждено соответствие проекта решения потребностям за-
казчика.
- «Выбор и постановка на выполнение требования» производится руко-
водителем на основании относительной важности требований.
- «Выполнение подзадач» включает в себя непосредственное програм-
мирование и отладку.
- «Комплексное тестирование программного продукта» - осуществляет
оператор технической поддержки на основе плана тестирования, ранее со-
ставленного аналитиком.
- «Внедрение» и «Приемка продукта» завершают процесс создания ПО.
Разработчик должен создать план по внедрению программного продукта в
среде эксплуатации, укомплектовать и поставить программный продукт за-
казчику, соблюдая условия договора, а также обеспечить первоначальное и
непрерывное обучение и поддержку персонала заказчика.
В общем случае на каждом этапе жизненного пути требования на разра-
ботку, как правило, действуют применяемые средства автоматизации.
В рассматриваемой конкретной организации основным средством авто-
матизации разработки ПО является система JIRA, представляющая собой
141
 142

средство управления изменениями и багтрэкер (bug tracker – программа реги-

страции ошибок и дефектов ПО и их состояния). То есть все заявки, посту-
пающие в систему, есть ошибки и изменения в уже существующих про-
граммных продуктах.
При поступлении требования в систему оператор технической поддерж-
ки фиксирует это событие. Заявка заносится в базу данных, что вполне естест-
венно и удобно – система JIRA интегрируема с такими базами, как MS SQL,
Oracle, DB2, MySQL, Access. В базе хранятся все заявки, когда-либо поступив-
шие в систему. С помощью запросов можно найти любую заявку, узнать ее ста-
тус, атрибуты (о них речь пойдет в следующих разделах) и т.д.
Когда заявка занесена в базу, ее может посмотреть и проанализировать ру-
ководитель отдела разработчиков на своем рабочем месте (АРМ), сделав запрос
к БД. Тут же назначается аналитик для работы с данным требованием.
Аналитик должен детально изучить поставленное требование, разбить его
на подзадачи, если необходимо, а так же оценить необходимые для реализации
ресурсы.
Результаты такого анализа – проект решения и предполагаемые подзадачи,
поставленные для удовлетворения требования, тоже вносятся в БД.

Далее проект решения отправляется заказчику. И после того, как проект

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

142
 143

4.6. Построение макромодели АСОИУ на предпроектной стадии ее проекти-

рования

Одной из важнейших целей предпроектного анализа создаваемой АСО-

ИУ является построение ее макромодели. Такая макромодель состоит из 4-х
матриц следующего вида:
а) цели системы управления – (матрица Φ0),
б) цели системы управления – функции (матрица Φ1),
в) функции системы управления – задачи (матрица Φ2),
г) задачи – информационные потребности (матрица Φ3).
Для построения этих матриц может применяться экспертный метод.
Рассмотрим, как строятся эти матрицы, и какие результаты можно получить путем их
анализа.
Начинается построение макромодели с построения матрицы «цели - це-
ли» (Φ0).
Пусть путем экспертного опроса выявлены цели проектируемой АСО-
ИУ, представленные в виде таблицы 4.6.1:

Таблица 4.6.1

Обес-
Номер
Формулировка цели печива-
цели
ет цели
Увеличить выпуск _________________ продук-
1 2и7
ции до 10 тыс. шт.
2 Повысить рентабельность производства –
3 Обеспечить ритмичность работы производства 2
4 Повысить обоснованность планов 3
5 Обеспечить выполнение заказов в срок 3
6 Упорядочить потребление материалов 2
7 Повысить качество продукции 2

Полученные данные можно представить в виде графа целей G1 (см. рис.

4.6.1) и матрицы целей Φ0.

143
 144

1 g1 2 g2 3 g3 4 g4

5 6 7
g5 g6 g7

Рис. 4.6.1 Граф целей G1

Матрица целей Ф0
цель
цель 1 2 3 4 5 6 7
1 1 1
2
3 1
4 1
5 1
6 1
7 1

Исходный граф целей можно упорядочить, расположив вершины по

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

Уровень 3, ранг 0
2

Уровень 2, ранг 1
3 7

Уровень 1, ранг 2

1 4 5 6

Рис. 4.6.2. Граф взаимосвязи целей

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

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

основу этой оценки могут быть положены следующие соображения: значи-
мость цели определяется ее уровнем в иерархии целей, а также количеством
и уровнем целей, которые обеспечиваются достижением оцениваемой цели.
На основе этих положений предварительная оценка значимости целей может
быть представлена следующим простым соотношением
n
Pj (   js Ps  Pj )
j  n
s 1
n
,
 P ( 
i
i
s 1
is sP  Pi )

где Pj – уровень j-й цели,

1 , если j-я цель обеспечивает s-ю цель

δjs= 0 , если нет

Для нашего примера имеем:

g1 : P1(P2+P7+P1)=1(3+2=1)=6 α1=0,13
g2 : P2P2=3∙3=9 α2=0,20
g3 : P3(P2+P3)=2(3+2)=10 α3=0,22
g4 : P4(P3+P4)=1(2+1)=3 α4=0,07
g5 : P5(P3+P5)=1(2+1)=3 α5=0,07
g6 : P6(P2+P6)=1(3+1)=4 α6=0,09
g7 : P7(P2+P7)=2(3+2)=10 α7=0,22
7 7 7

 P ( J j js Pj  Pj )  45   1
j 1
j 1 s 1

Для обеспечения выявленных целей АС должна реализовывать определенные

функции управления. Пусть в результате опроса специалистов получена таблица (матрица

Ф1) вида «цели - функции» Φ1. Она показывает, какие функции обеспечивают достижение

целей. Для рассматриваемого примера эта матрица имеет следующий вид:

145
 146

Матрица «цели – функции» Ф1

Цели (j)
Уровень
Функции (i) Уровень 3 Уровень 1
2 γi
2 3 7 1 4 5 6
1. Перспективное планирование 1 1 1 0,06
2. Текущее планирование 1 1 1 0,08
3. Подготовка производства 1 1 1 0,13
4. Диспетчеризация 1 1 1 1 0,10
5. Материально-техническое обеспечение 1 1 1 1 1 1 0,18
6. Планирование загрузки производствен-
1 1 1 1 1 1 1 0,17
ных мощностей
7. Планирование и учет труда и зарплаты 1 1 1 1 1 0,2
8. Бухучет и финансы 1 0,04
9. Статистический учет 1 0,04
 4 6 3 5 6 6 3 1,0

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

мости, учитывая значимость и количество обеспечиваемых целей. Оценку значимости
функций  i можно представить в виде:
  ij j

i  j

  
i j
ij j

где  j – оценка значимости целей,

 1, если функция с номером i обеспечивает цель с номером j;
 ij  
0, если функция с номером i не обеспечивает цель с номером j.
Из матрицы Ф1 по коэффициенту значимости функций  i следует, какие функции
надо автоматизировать в первую очередь, вторую и т.д.
Матрица Ф1 позволяет также отметить такую особенность организации, как высокая
или низкая концентрация функций по отношению к поставленным целям. Так, в рассмот-
ренном примере достижение цели g3 связано с эффективным выполнением шести функций,
что требует определенных усилий по их координации.
Для обеспечения указанных функций в системе управления должны решаться опре-
деленные задачи управления. Для этого необходимо построить матрицу «функции - зада-
чи» Ф2. Она показывает, реализация какого набора задач обеспечивает выполнение вы-
бранных функций.
146
 147

Матрица «функции – задачи» Ф2

Функции (i)
Задачи (k)
1 2 3 4 5 6 7 8 9 μk
1. Повышение уровня расчетной обоснованности плано-
1 1 1 1 1 1 1 0,17
вых показателей
2. Упорядочение нормативов 1 1 1 1 1 1 1 0,15
3. Анализ ритмичности производства 1 1 1 0,08
4. Расчет динамики зарплаты 1 1 1 0,06
5. Анализ себестоимости 1 1 1 1 1 0,13
6. Экономическое обоснование конструкции изделия 1 1 0,08
7. Лимитирование отпуска материалов 1 1 1 0,09
8. Составление материальных балансов 1 1 1 1 1 0,10
9. Расчет рентабельности 1 1 0,03
10. Учет затрат на капстроительство 1 1 1 1 1 0,11
 4 4 4 3 7 4 5 5 6 1,0

Анализ этой матрицы может позволить определить важность задач. Для этого введем
коэффициент важности задачи k .
Коэффициент важности задач k определяют по формуле
  ki i
k  i
,
 
i k
ki i

где γi – значимость i-й функции

1, если k-я задача обеспечивает выполнение i-й функции,
δki= 0, в противном случае

Теперь представляется возможным построить полную матрицу смежности целей и

задач и уточнить оценки их значимости в организации и управлении. Эта матрица М имеет
вид, представленный на рис. 4.6.2. Эта матрица в виде графа представлена на рис 4.6.3.
Анализируя эту матрицу, можно получить разнообразную информацию о рассматри-
ваемой системе целей и задач. Итак, преобразования матрицы приводят к распределению

147
 148

~
задач по уровням p*, приведенным в верхней строке табл. M . При этом часть задач выдви-
гается на достаточно высокий уровень и становится равнозначной поставленным целям.

Уточненная оценка значений целей и задач α* основывается на принципах, положен-

ных в основу определения α.
~
Для упрощения последующих записей пронумеруем столбцы и строки матрицы М ,
положив номера строк i=j для gi и i=k+7 для ak и аналогично – номера столбцов s=j для gi и
s=k+7 для ak. Тогда в этих новых обозначениях формула для вычисления α*i имеет вид:
Pi * (  is s Ps*   i Pi* )
 i*  s
,
 P (  
i
i
*

s
P   i Pi* )
is s s
*

~
где νs = {α*i , μk}, δis – элементы матрицы M . Значения α*i приведены в таблице.
Если какая-то строка содержит лишь 0, это означает, что данная цель (задача) является
конечной (результирующей). Если же 0 содержит весь столбец, то соответствующую зада-
чу следует считать исходной. Нулевые строка и столбец одного и того же номера означают,
что данная задача одновременно и исходная, и результирующая, т.е. автономная. В этом
случае целесообразно более детально проанализировать ее содержание. Часто есть основа-
ние полагать, что задача надуманная и никому не нужна, редко – это некая особая цепь.
Сравнение состава задач с их распределением по подразделениям оргсистемы позво-
ляет выявить не решаемые задачи и установить, в какой мере квалификация и оплата ис-
полнителей совпадают с важностью решаемых ими задач.

Показатель α*i дает возможность выявить узловые задачи, решение которых имеет
наибольшее значение для успешного функционирования системы. В данном примере это
задачи а5 и а6.
После анализа матрицы цели – задачи можно переходить к построению матрицы Φ3
«задачи - информация». Ее анализ позволяет установить степень загруженности подразде-
лений, высказать рекомендации по их штатной численности, предпочтительной схеме рас-
пределения решаемых задач и целесообразном уровне автоматизации. Эта матрица форми-
руется следующим образом:
1) устанавливается информация, получаемая тем или иным функциональным или ли-
нейным подразделением;

2) устанавливается информация, формируемая в функциональных или линейных под-

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

Анализ полученной таблицы позволяет установить:

1)максимальное количество информации определенного вида в течение установ-
ленного периода Fkmax;
148
 149

2)суммарное количество информации, необходимое для решения каждой задачи Fi

3)вид информации, требуемой для решения соответствующей i-й задачи:
4)виды информации, которые не используются непосредственно в решении задач;
5)задачи, не обеспеченные информацией.

Полученные данные можно представить в виде таблицы Ф3 «задачи – информация »

Цели и задачи (i)

Вид информации Fkmax
1 2 … 16 17
1. цена готовой продукции 2 1 1
2. расчет трудоемкости 3 2 4
3. справки 5 6
4. спецификация 10 8
…

Общее количество информа-

ции, обеспечивающее решение
i-й задачи Fi [Т бит/сутки]

149
 150

Ps* 7 9 8 4 7 7 8 2 1 3 2 6 5 4 6 8 3
α; j; k 0,13 0,2 0,22 0,07 0,07 0,09 0,22 0,17 0,15 0,08 0,06 0,13 0,08 0,09 0,1 0,03 0,11
i s g1 g2 g3 g4 g5 g6 g7 a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 αi
g1 1 1 2 0,097
g2 0 0,05
g3 1 1 0,089

Цели
g4 1 1 0,025
g5 1 1 0,049
g6 1 1 0,053
g7 1 1 0,089
a1 1 1 1 1 4 0,028
a2 1 1 1 1 1 1 1 1 1 1 1 1 12 0,028
a3 1 1 1 1 4 0,028
a4 1 1 1 1 1 1 1 7 0,036
a5 1 1 1 1 1 5 0,114

Задачи
a6 1 1 1 1 1 1 6 0,107
a7 1 1 1 1 1 5 0,057
a8 1 1 1 1 4 0,077
a9 1 1 0,051
a10 1 1 2 0,022
3 11 6 3 4 4 6 1 0 1 1 4 2 2 3 4 2
~
Рис. 4.6.2. Матрица смежности «Цели - задачи» M
150
 151

g1 g2 g3

a10

g4

a9

g5

a8

g6

a7

g7
a6

a1
a5
a3
Рис. 4.6.3. Граф «Цели-задачи» a4 a2

151
 152

Если φ – количество информации, которую может обработать один человек в задан-

ный период, то φ=105106 (бит/сутки)
Пусть F0 – количество информации, циркулируемой в самой организационной систе-
ме, а Fвн – внешняя информация, которая вносится в процессе управления извне. Тогда
можно определить максимальную численность людей в организации
b Fi
N max  i
,

2 F0  Fвн
где b  .
F0  Fвн
Этот коэффициент b учитывает тот факт, что любая производственная информация
должна быть кем-то в организации использована, а используемая – кем-то произведена.
На основании матриц «цели - цели», «цели - функции», «функции – задачи», «задачи -
информация» можно построить обобщенную логико-информационную модель проекти-
руемой АСУ. Эту модель можно представить в виде трехдольного ориентированного графа
G0=(Z,W), где Z – множество вершин, состоящее из четырех подмножеств:
Z=ZцZфZзZи , Z1Z2Z3Z4=0,где Z1 – подмножество целей, Z2 – подмножество
функций, Z3 – подмножество задач, Z4 – подмножество информационных элементов; а W –
множество дуг, показывающих информационную взаимосвязь между элементами множе-
ства Z. Если дуги множества W отражают структуру информации, то граф G0 превращается
в мультиграф.
Для упрощения этого графа иногда выделяют из него подграф, относящийся к целям.
В результате получают логико-информационный граф, показывающий связь инфор-
мационных элементов, задач и функций управления. При этом функции управления ото-
ждествляют с функциональными подсистемами проектируемой АСОИУ. Пример такого
графа приведен на рис. 4.6.4.
Построение схемы информационно-логической взаимосвязи задач позволяет:
1) определить последовательность решения задач;
2) определить группы задач, решение которых может производиться параллельно;
3) уточнить объем нормативной информации;
4) определить необходимые сроки хранения исходных, промежуточных и результи-
рующих данных.
Построение информационной схемы задач производится на основе разбиения их на
классы.

152
 153

Цели
Функции
Задачи
(виды) первич-
Информация

ная

Рис. 4.6.4. Обобщенная логико-информационная модель проектируемой АСУ

Определение 1. Информация, поступающая для решения задач извне, называется

первичной.
Определение 2. Множество задач (ℓ+1)-го класса Lℓ+1 определяется как множество,
для решения которого необходимы и достаточны первичная информация и результаты ре-
шения задач L1, L2, … ,Lℓ. Среди задач класса (ℓ+1) нет ни одной задачи, результаты реше-
ния которой используются при решении других задач этого же класса.

153
 154

Определение 3. Для каждой задачи из множества Lℓ+1 существует хотя бы одна зада-
ча, во множестве Lℓ, результаты решения которой использовались бы для решения Lℓ+1.
Из предложенных определений следует, что к первому классу L1 относятся все те за-
дачи, для решения которых достаточна первичная информация. Если результаты решения i-
й задачи используются при решении какой-либо задачи ℓ-го класса, а сама i-я задача реша-
ется только на основе первичной информации, а также результатов решения задач первого
класса, то она относится непосредственно к (ℓ-1)-му классу.
Итак, пусть заданы неупорядоченное множество задач L={Li} и информационные
связи между ними U={Uk}, образующие исходный граф G={L,U}. Ставится задача: упоря-
дочить множество L задач Z на подмножество классов, в которых задачи не связаны между
собой смежной информацией.
Для решения поставленной задачи зададим граф G={L,U} в виде матрицы смежности
H=(L,U) размерности n×m, у которой номера строк соответствуют номерам задач (верши-
нам), а номера столбцов – номерам дуг, показывающих информационную связь между за-
дачами. Значения элементов Sij матрицы H следующие:
1, если задача (вершина) Li есть начало дуги Uj
Sij= 2, если задача (вершина) Li есть конец дуги Uj
0, если задача Li не принадлежит дуге Uj
Анализируя эту матрицу, можно осуществить формирование классов задач. Алгоритм
такого анализа состоит в последовательном просмотре строк матрицы и выявлении таких
строк, которые содержат только 0 и 1. На очередном k-ом шаге все выявленные строки от-
вечают задачам k-го класса (k=1, 2, …). После поиска таких строк и их исключения из мат-
рицы вместе с соответствующими столбцами, где стояли единицы, переходят к следующе-
му (k+1)-му шагу и процесс повторяется до получения нулевой матрицы.

4.7. Синтез технической структуры АСУТП на основе конденсации графовой

функциональной модели системы

(В.Я. Войтенко, А.В. Кузнецов «Приборы и системы управления», №4, 1991г.)

Рассмотрим синтез оптимальной по числу технических элементов структуры

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

154
 155

Техническую структуру локального уровня АСУТП, на которую возлагается решение

некоторого множества L предназначенных для автоматизированного выполнения задач
(функций), определим отображением d множества L={ℓj}, j=1,..,k на множество M={mi},
i=1,..,n технических документов (процессоров) АСУ, которые необходимо использовать для
построения технической структуры (ТС) локального уровня АСУТП, т.е.
d: L → M → {ℓj} → {mi} (1)
при условии экстремума некоторого критерия оптимальности Qопт ТС АСУТП, характери-
зующего степень рациональности выбора числа n технических элементов АСУТП с учетом
связности задач системы и удовлетворения следующих ограничений:
1. однородность элементов ТС АСУТП и равнозначности связей между задачами
одного уровня;
2. согласованности величин информационной емкости Ij задач ℓj локального уровня
управления с допустимыми объемами памяти Vj* устройств ЭВТ, реализующих
технические элементы АСУТП; при этом из-за предыдущего ограничения спра-
ведливо равенство V1*=V2*=…=Vn*=V*;
3. не превышения времени tj решения (обработки) задач ℓj некоторых пороговых (до-
пустимых) значений Ti*, определяемых динамикой технологического процесса
(ТП);
4. замкнутости (разомкнутости) межэлементного шинного интерфейса ТС АСУТП
одного уровня.
С учетом сделанных ограничений синтез оптимальной ТС АСУТП сводится к опре-
делению требуемого оптимального числа n однородных технических элементов АСУТП,
необходимых для решения задач локального уровня АСУТП, и распределению связей ме-
жду этими элементами. Другими словами, нужно определить минимальное число, а также
состав и взаимосвязи подмножеств сильно связанных задач, каждое из которых решается
своим техническим элементом mi; при этом число задач, входящих в состав таких подмно-
жеств, может принимать значения от 1 (тогда число подмножеств равно k) до k (число под-
множеств равно 1), а значит, и число n требуемых для их решения технических элементов
согласно выражению (1) может варьироваться от k до 1.
Сильно связными будем полагать взаимно связные, а слабо связными – односторон-
не связные задачи рассматриваемого уровня иерархии ТС АСУТП.
Формализацию поставленной задачи проведем на базе математического аппарата
теории графов.В этом случае она может быть сформулирована следующим образом:
найти минимальное значение величины n, равное минимальному числу сильно
связных компонент графа Gi; i=1,..n, информационного графа G:
G=(‹L, V, T›, ‹F, W›), где
L={ℓj}, j=1,..,k – множество автоматизируемых задач АСУТП локального уровня, со-
ответствующих вершинам графа G;
V={vj}, j=1,..,k – множество, каждый элемент которого определяет требуемый в про-
цессе решения j-й задачи объем памяти, непосредственно за-
висящий от значения информационной емкости Ij задачи ℓj, т.е.
vj=f(Ij);
155
 156

T={tj}, j=1,..k – множество, каждый элемент которого определяет время, требуемое для
решения j-й задачи;
F={fjs}, j=1,..,k; s=1,..,k – множество связей (дуг графа G) между задачами, причем ра-
венство индексов j=s допустимо, что соответствует связи каж-
дой вершины графа G с самой собой посредством дуги, назы-
ваемой петлей, изображение которой на графе, как правило,
опускается с целью упростить его схему;
W={wjs}, j=1,..k; s=1,..,k – множество весов соответствующих дуг графа G, соединяю-
щих его вершины; вследствие ограничения, сформулирован-
ного в п. 1) каждый элемент wjs множества W положим рав-
ным 1 (wjs=1),
причем таких сильных компонент, что
i : Gi≠0, Gi∩Gu=0, i,u=1,..,n; u≠i  Gi =G
i

и обеспечивается условие:
Qопт → max
при ограничениях
 v j  V * (объем памяти процессора)
jGi
(2)

t
jGi
j  Ti (время решения всех задач i-ым процессором) (3)
*

Рассмотрим на примере решение сформулированной задачи определения мини-

мального числа, а также состава и взаимосвязей подмножеств сильно связных задач управ-
ления, контроля и сигнализации локального уровня АСУТП, каждое из которых будет ре-
шаться своим техническим элементом mi.
Пусть в результате функционального анализа объекта управления (ТП) установлено
множество L={ℓj}, j=1,..,k задач, решение которых подлежит автоматизации. Описаны так-
же все условные и безусловные, непосредственные и косвенные, прямые, обратные и вза-
имные, а также другие связи между ними, на основе чего выстраивается информационный
граф G, вершинами которого являются сами задачи ℓj и их атрибуты (vj, tj), а ориентирован-
ными дугами – связи fjs между задачами. На рис. 4.6.1. дан пример такого графа G.

G1 ~ m1
ℓ1 v1 f31 G3 ~ m3
ℓ3
t
G2 ~ m2 f21 v3
f43 t
v2 f24
f15
t
ℓ2 v4 ℓ1 f36
f51 t
f64

v6 ℓ6
v5
ℓ5 f65 t
t

156
 157

Рис. 4.6.1. Пример графа G

Алгоритм решения задачи

Поставленная задача решается на основе реализации процедуры конденсации G* гра-

фа G путем отыскания его сильных компонент, число которых априорно неизвестно.
Граф G* называемый конденсацией графа G, определяется следующим образом: каж-
дая его вершина mi соответствует множеству вершин некоторой сильной компоненты Gi
графа G, т.е. mi~Gi= 
jGi
j (разным сильным компонентам из графа G отвечают разные

вершины в конденсации G*); дуга fiu* существует в конденсации G* тогда, когда в графе G
имеется такая дуга fjs, что вершина ℓj принадлежит сильной компоненте графа Gi, соответст-
вующей вершине mi в конденсации G*, а вершина ℓs – сильной компоненте графа Gu, отве-
чающей вершине mu в конденсации G*, т.е.
 j  G i ~ mi  G * , а  s  Gu ~ m u  G * .
Сильными компонентами графа Gi будем считать максимальные подграфы графа G,
обладающие заданным свойством. Поскольку в данном случае в качестве такого свойства
выступает сильная связность вершин графа G, его сильные компоненты будут представлять
собой подмножества (порожденные подграфы) взаимно связных вершин.
Требуется найти его сильные компоненты и построить конденсацию G*.
Эта процедура реализуется при использовании матриц достижимости RG и контрдос-
тижимости QG графа G.
Матрица достижимости RG=||rjs|| определяется следующим образом:

1, если вершина ℓs достижима из вершины ℓj (т.е. ℓj→ℓs)

rjs=
0, в противном случае, т.е. ℓj→ ℓs.

Вершина ℓs считается достижимой из вершины ℓj, если существует путь от вершины ℓj

к вершине ℓs.
Все диагональные элементы матрицы RG равны 1, т.к. каждая вершина достижима из
самой себя путем длиной 0. В качестве алгоритма построения матрицы достижимости RG
можно предложить следующий:
Вход: Матрица AG смежности графа G, состоящая из строк A1, A2,…, Aj,…, Ak;
Aj=(aj1,…, ajs,…, ajk)
Выход: Матрица достижимости RG, состоящая из строк R1, R2,..., Rj,…, Rk, где

Rj=(rj1,…, rjs,…, rjk)

Алгоритм запишем в виде, использующем псевдоалгол:

157
 158

Начало
1. для j от 1 до k шаг 1 цикл А
2. сформировать множество S индексов s таких, что ajs=1;
3. Rj := Aj; k:=0;
4. пока S≠0 цикл В
5. выбрать sєS;
6. Rj:=Rj  As;
7. S:=S\{s};
8. K:=K  {s};
9. Сформировать множество Ss индексов r таких, что asr=1;
10. S:=S  (Ss\K);
11. конец цикла В;
12. возврат Rj;
13. конец цикла А;
Конец

Для примера матрица смежности AG имеет вид:

ℓ1 ℓ2 ℓ3 ℓ4 ℓ5 ℓ6
ℓ1 0 0 0 0 1 0
ℓ2 1 0 0 1 0 0
AG= ℓ3 1 0 0 0 0 1
ℓ4 0 0 1 0 0 0
ℓ5 1 0 0 0 0 0
ℓ6 0 0 0 1 1 0

Применяя описанный выше алгоритм, получаем следующую матрицу достижимости

RG:

ℓ1 ℓ2 ℓ3 ℓ4 ℓ5 ℓ6
ℓ1 1 0 0 0 1 0
ℓ2 1 1 1 1 1 1
RG= ℓ3 1 0 1 1 1 1
ℓ4 1 0 1 1 1 1
ℓ5 1 0 0 0 1 0
ℓ6 1 0 1 1 1 1

Матрица контрдостижимости QG=║qjs║ определяется следующим образом:

1, если из вершины ℓs графа G достижима вершина ℓj (т.е. ℓj←ℓs)
qjs=
0, в противном случае, т.е. ℓj← ℓs.

158
 159

При этом qjs=1, если j=s.

Очевидно, что матрица QG есть транспонированная матрица RG.
Для нашего примера имеем:

ℓ1 ℓ2 ℓ3 ℓ4 ℓ5 ℓ6
ℓ1 1 1 1 1 1 1
ℓ2 0 1 0 0 0 0
QG= ℓ3 0 1 1 1 0 1
ℓ4 0 1 1 1 0 1
ℓ5 1 1 1 1 1 1
ℓ6 0 1 1 1 0 1

На следующем этапе алгоритма выполняется поэлементное умножение матриц RG и

QG графа G, в результате чего получаем RG QG:
ℓ1 ℓ2 ℓ3 ℓ4 ℓ5 ℓ6
ℓ1 1 0 0 0 1 0
ℓ2 0 1 0 0 0 0
RG  QG= ℓ3 0 0 1 1 0 1
ℓ4 0 0 1 1 0 1
ℓ5 1 0 0 0 1 0
ℓ6 0 0 1 1 0 1

При этом строка ℓj матрицы RG  QG содержит единицы только в тех столбцах ℓs, для
которых выполняется условие: вершины ℓj и ℓs взаимно достижимы. В других местах стро-
ки стоят нули. Таким образом, две вершины графа G находятся в одной и той же сильной
компоненте тогда, когда соответствующие им строки (или столбцы) в матрице RG  QG
идентичны.
Следующий шаг алгоритма – преобразование матрицы RG  QG путем транспониро-
вания ее строк и столбцов в блочно-диагональную матрицу (RG  QG)′, каждая из диаго-
нальных подматриц (блоков) которой соответствует сильной компоненте графа G и содер-
жит только единичные элементы, поскольку вершины, которым отвечают строки, имею-
щие единицу в столбце ℓs, образуют множество вершин сильной компоненты, содержащей
вершину ℓs. Все остальные блоки данной матрицы имеют нули. Для нашего примера име-
ем:

ℓ1 ℓ5 ℓ2 ℓ3 ℓ4 ℓ6
ℓ1 1 1 0 0 0 0
ℓ5 1 1 0 0 0 0
(RG  QG)′= ℓ2 0 0 1 0 0 0

159
 160

ℓ3 0 0 0 1 1 1
ℓ4 0 0 0 1 1 1
ℓ6 0 0 0 1 1 1

Анализ матрицы (RG  QG)′ позволяет получить число n и состав подмножеств сильно
связных задач локального уровня АСУТП, решаемых каждое своим mi-м техническим эле-
ментом i=1,..,n. В данном примере в состав G входит три сильные компоненты, следова-
тельно, число однородных технических элементов, которые могут быть использованы для
построения оптимальной ТС локального уровня АСУТП, равно 3, т.е. имеем:
G   Gi  G1  G 2  G3  i  1, n  n  3;
i

G1  0; G 2  0; G3  0; G1  G 2  G3  0, и при этом :
~ m 1  =G
G*
 
1  5 1

 2  G 2 ~ m2  G *

 3   4   6  G3 ~ m3  G * .

На основе блочно-диагональной матрицы (RG  QG)′, а также структуры самого ин-

формационного графа G (см. рис. 4.6.2) строится его конденсация – граф G*, определяющий
связи между mi-ми техническими элементами ТС АСУТП на локальном уровне, i=1,2,3 (см.
рис. 3.16).
m1
*
v 1

f * t 1*
21 f 31*

* *
v 1 v 1 m3
m2 * *
t 1 f *
23
t 1

Рис. 4.6. 2. Конденсация G* графа G

В соответствии с определением конденсации графа и его сильных компонент, а так-

же с учетом принятых ограничений (2) и (8) для элементов графа G* справедливы соотно-
шения:
vi*  v
jGi
j  V * ; t i*  t
jGi
j  Ti* ; I i*  I
jGi
j ,

160
 161

где i=1,2,3 для рассмотренного примера.

Кроме того, имеют место соответствия:
f21*~f21; f23*~f24; f31*~f31 f 65
Таким образом, для построения оптимальной по числу элементов n ТС АСУТП оп-
ределены все ее составные части: число n технических элементов, состав подмножеств
сильно связных задач, решаемых каждым из них, а также взаимосвязи между элементами
ТС локального уровня АСУТП.
Если в ограничении, сформулированном в п. 4, задана замкнутость межэлементного
шинного интерфейса данного уровня ТС АСУТП, то на основании результатов анализа
блочно-диагональной матрицы (RG  QG)′, а также полученных в конденсации G* (см. рис.
2) связей fiu* (ориентированных дугах графа G*)
Выстраивается искомая децентрализованная ТС АСУТП в целом с единственным
(локальным, первым, нижним) уровнем иерархии (см. рис. 4.6.3).

m1 m2 m3

ℓ1 ℓ2 ℓ3 ℓ4 ℓ5 ℓ6

Рис. 4.6.3. Децентрализованная одноуровневая оптимальная ТС АСУТП

Если в ограничении на ТС АСУТП определена разомкнутость соответствующего
интерфейса или требуется построение многоуровневой иерархической ТС АСУТП, то, с
учетом связей fiu* , составляется информационный граф G(2) задач второго уровня ТС. Этот
граф выстраивается по результатам функционального анализа множества задач (функций)
этого уровня, лежащих в плоскости среза локального уровня, но решаемых соответственно
на втором уровне иерархии ТС АСУТП. После этого относительно данного уровня ТС по-
вторяется вся ранее описанная процедура синтеза. Аналогично выстраивается и все после-
дующие уровни иерархической структуры АСУТП.
Физический эффект оптимизации обусловлен следующим:
во-первых, сокращением числа связей между задачами каждого уровня ТС (на ос-
нове их внутреннего представления в соответствующих технических элементах), требую-
щих взаимодействия различных элементов одного уровня, что увеличивает оперативность
обмена информацией при соблюдении ограничений, определяемых выражениями (2) и (3),
во-вторых, распараллеливанием решения только слабо связных задач фиксированно-
го уровня ТС АСУТП.
При этом сильно связные задачи, образующие свою сильную компоненту в инфор-
мационном графе задач соответствующего уровня, предлагается решать последовательно

161
 162

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

Лекция 1

МОДУЛЬ 2. АСОИУ КАК ОБЪЕКТ ПРОЕКТИРОВАНИЯ

(6-й весенний семестр, 3-й курс)

ГЛАВА 5. МОДУЛЬНЫЙ ПРИНЦИП ПРОЕКТИРОВАНИЯ АСОИУ

5.1 Общая постановка задачи

Проектирование АСОИУ с использованием модульного принципа связано с создани-

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

162
 163

— упрощается процесс разработки и отладки программного и информационного

обеспечения АСОИУ;
— упрощается последующая модификация системы, так как модульные программы
могут быть улучшены путем простой замены отдельных модулей, которые
функционально эквивалентны, но имеют лучшие системные характеристики;
— улучшается организация управляющих программ;
— появляются возможности внедрения передовых методов разработки и автомати-
зации проектирования АСОИУ.
Реализация модульного принципа проектирования АСОИУ предполагает, что каж-
дый модуль обладает следующими качествами:
– функциональность, т.е. модуль должен представлять собой функционально закон-
ченную максимально независимую совокупность операций по обработке данных;
обращение к модулю осуществляется как к единому целому, и значения вызывае-
мых параметров обычно отражает специфику функций модуля;
– связность, т.е. модуль реализует совокупность взаимосвязанных функций, тре-
бующих одних и тех же данных; часть этих данных обычно скрыта для системы в
целом;
– алгоритмичность, т.е. функции модуля группируются на алгоритмической основе;
– последовательность, т.е. модуль включает несколько функций, которые реализу-
ются последовательно, причем выходные результаты одной функции являются
входными для другой и т.д.; кроме того, функции модуля обычно являются взаи-
мосвязанными во времени;
– однородность, т.е. в модуле объединяются однородные по своему функциональ-
ному назначению процедуры.
Основой для формализованной постановки и решения задач анализа и синтеза мо-
дульных АСОИУ является определение модулей системы и межмодульного интерфейса.
Могут быть выделены различные способы разбиения информационного и программ-
ного обеспечения АСОИУ на отдельные модули:
функциональный – по числу информационных и управляющих связей между моду-
лями;
ресурсный – по имеющимся возможностям технического и программного обеспече-
ния разработки;
элементный – по использованию типовых и стандартных элементов решений;
смешанный – обеспечивающий выше перечисленные.
Перейдем к формализации.
Пусть А={a1, a2, …, am} – множество задач, выявленных на предпроектной стадии.
Каждое ai в общем случае характеризуется n – мерным вектором показателей xi, которыми
являются время выполнения, число входных и выходных переменных, требуемый объем
памяти и т.д.
Все задачи информационно взаимосвязаны. Это можно задать орграфом Г=(A,D), у
которого вершины А={a1, a2, …, am} – это задачи, а ребра D – информационные связи между
задачами (процедурами).
163
 164

Пусть граф Г задан матрицей смежности ║dij║, причем dij=1, если существует инфор-
мационная дуга из задачи ai в задачу aj, и dij=0 в противном случае. Каждая дуга между эле-
ментами ai и aj характеризуется некоторым параметром ρij, который может быть и вектором.
Будем считать, что ρij=0, если dij=0.
Обозначим через Е={θ} – множество всех возможных разбиений множества А на
отдельные подмножества, т.е. каждое θ таково, что
L ( )
Θ=(А1θ, …, Аℓθ, …, АL(θ)θ),  A   A , Ai  Aj  0 , i,j=1,..,L(θ), i≠j.
 1

Рассмотрим некоторое разбиение θ. Подмножество Аℓθєθ будем в дальнейшем назы-

вать модулем.
Для данного разбиения θ множество дуг исходного графа Г распадается на L(θ)+1 по-
парно не пересекающихся подмножеств: а) подмножество внутреннее Gℓθ дуг, соединяю-
щих вершины из Аℓθ; б) подмножество внешнее Dθ дуг, концы которых лежат в разных мо-
дулях. Внешние дуги, входящие в какой-либо элемент модуля Аℓθ называют его входом, а
выходящие из какого-либо элемента – выходом.
Разбиению θ можно сопоставить агрегированный граф Гθ, получающийся из исходно-
го графа Г в результате объединения всех вершин подмножества Аℓθ в одну для каждого
ℓ=1,..,L(θ). Из вершины Аrθ в вершину Аkθ идет дуга тогда и только тогда, когда в графе Г
имеется дуга, направленная от некоторой вершины aiє Аrθ в вершину ajє Аkθ. Дугам графа Гθ
сопоставим параметры qrk    ij , r≠k,

( i , j )C rk

где Crkθ={(i, j): aiєArθ, ajєAkθ, dij=1}.

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

5.2. Постановка и модель решения задачи разбиения ИЛМ АСОИУ на

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

Данная задача возникает на этапе технического проектирования, в процессе которо-

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

164
 165

Отношение, т.е. оператор отображения множества процедур к множеству информа-

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

1 1
Информационные

Процедуры обработки (зада-

элементы

2 2

3
3

чи)
4
4

Рис. 4.5.1. Двудольный граф связи процедур и информационных элементов

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

А={a1, a2, …, aj, …, am} – множество задач, далее процедур системы обработки данных
R={r1, r2,…, rℓ,…, rL} – множество информационных элементов

1, если информационный элемент rℓ используется для выполнения

d j  процедуры аj
0, в противном случае

Введем в рассмотрение следующие переменные:

1, если процедура аjвходит в модуль Аi, j=1,..,m; i=1,..,M=2m-1

xij 
0, в противном случае

и связанные с ней переменные:

165
 166

1, если  d j  xij  1 ; i=1,..,M; ℓ=1,..,L

j 1

yℓi=
m

0, если  d j  xij  0
j 1

т.е. yℓi=1, если rℓ - й информационный элемент используется процедурой aj, которая

размещается в модуле Аi.
При этих обозначения суммарное число различных информационных элементов, яв-
ляющихся общими для различных модулей Аi, i=1,..,M равно
L M M
Z   y i  yi   min (1)
 1 i 1 i   i 1

При ограничениях:
1. На число выделяемых модулей M0≤M (2)
Каждая процедура хотя бы в одном модуле должна находиться:
M0

xi 1
ij  1, j=1,..,m (3)
3. Число процедур в одном модуле может быть ограничено некоторой величиной N:
m

xj 1
ij  N , i=1,..,M0 (4)
4. Некоторые процедуры j и j` должны быть разнесены по разным модулям, т.е.
xij+xij`≤1 , i=1,..,M0 (5)
5. Число информационных элементов, с которыми связан модуль, может быть ограничено,
т.е.
L

y  1
i  k , i=1,..,M0 (6)
6. Ограничения на сложность взаимодействия информационных элементов и процедур
внутри модулей, т.е.
L m

 d 1 j 1
j  xij  G, i=1,..,M0 (7)
7. Ограничения на количество сложных связей между информационными элемента-
ми и некоторой парой i и i` модулей, т.е.
L

y 1
i  y i   R (8)
Задача (1)-(8) является задачей квадратичного целочисленного программирования.
Для удобства решения она может быть сведена к линейной форме путем линеариза-
ции выражений (1) и (8).

166
 167

Введем переменную
1, если ℓ-й информационный элемент необходим для модулей Аi и Ai`
Zℓii`=
0, в противном случае
Тогда критерий (1) может быть записан так:
L M M

 Z
 1 i 1 i 1
 ii   min (9)
Ограничение (8) при этом будет иметь вид:
m

Z
 1
 ii  R

для заданных i и i` (10)

Задача разбиения, представленная выражениями (9), (2)-(7), (10) имеет линейный вид
и может быть решена с использованием стандартных методов.
Рассмотрим следующий пример решения задачи разбиения программного и инфор-
мационного обеспечения АСОИУ на функциональные модули, имеющие минимальное
число информационных связей .
Пусть граф задачи содержит пять процедур и шесть информационных элементов (см.
рис. 4.5.2).
dℓ ar
1 1
Информационные элементы

2 2
Процедуры

3
3

4
4

5
5

Рис. 4.5.2. Граф взаимосвязи процедур с информационными элементами

Матричная форма соотношений между процедурами и информационными элемен-

тами приведена в таблице 4.5.1.

167
 168

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

щих минимальное число общих информационных элементов, причем разбиение необхо-
димо провести таким образом, чтобы модули включали только соседние процедуры.
Рассмотрим решение задачи при следующих ограничениях:
1) общее число модулей V=2;
2) общее число информационных элементов в каждом из модулей Lv≤6, v=1,2;
3) общее число процедур в каждом модуле Mv≤4, v=1,2.
Таблица 4.5.1. Матричная форма соотношений

Ar dℓ
1 2 3 4 5 6
1 + + + + +
2 + +
3 + + + +
4 + + +
5 + + +

Находим матрицу взаимосвязи процедур обработки с информационными элемента-

ми:
111011 
010010 
 
║djℓ║= 110011 
 
101101 
011100 

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

I [ a1], [ a2, a3, a4, a5 ]
II [ a1, a2], [ a3, a4, a5 ]
III [ a1, a2, a3 ], [ a4, a5 ]
IV [ a1, a2, a3, a4], [ a5 ]

Для каждого варианта разбиения определяем матрицы Xji и Yℓi и значение критерия S:

168
 169

11 
10  11 
01  
  11 
I. X Tji  01 ; Yi    ; SI=5
  01
01 11 
01  
11 
11 
10 11 
10  
  11 
II. X Tji  01 ; Yi    ; SII=5
  01
01 11 
01  
11 
11
10 11
10  
  11
III. X Tji  10 ; Yi    ; SIII=3
  01
01 10
01  
10
10
10 11
10  
  11
IY. X Tji  10 ; Yi    ; SIV=3
  11
10 10
01  
10
L V V
По критерию S    Yli  Yli  min оптимальным является IV вариант разбиения.
l 1 i 1 i i 1

5.3. Постановка и модель решения задачи разбиения ИЛМ АСОИУ на функ-

циональные модули с минимальным временем обмена с
внешней памятью ЭВМ (базой данных)

В отличие от предыдущей постановки задачи разбиения ИЛМ АСОИУ на функцио-

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

169
 170

Определим вначале те исходные данные, которые являются известными к началу по-

становки и дальнейшей формализации поставленной задачи.
Предполагается известными количество функциональных модулей, на которые раз-
бивается множество процедур обработки данных V. Но какие процедуры и в каком количе-
стве они размещены в том или ином модуле неизвестно.
Кроме того, известно количество информационных массивов F, в которых размеще-
ны информационные элементы, но в каких массивах и в каком количестве их находится в
том или ином массиве неизвестно.
Известными являются также следующие данные:
- А={аj; j=1,..,m} – множество последовательно выполняемых процедур в проекти-
руемой системе обработки данных;
- R={rℓ; ℓ=1,..,L} – множество информационных элементов, обрабатываемых проце-
дурами множества А;
- = – матрица взаимосвязей информационных элементов с соответст-
вующими процедурами обработки данных при считывании этих элементов из соответст-
вующих массивов. Элемент этой матрицы определен следующим образом:
=
1 , если информационный элемент считывается из массива процедурой , 
=
0 , если информационный элемент не связан с процедурой .
з
− з= – матрицы взаимосвязей информационных элементов с соответст-
вующими процедурами обработки данных при их записи в соответствующий массив.
Элемент этой матрицы з определен следующим образом:
з
=
1 , если информационный элемент записывается в массив процедурой ,  
=
0 , если информационный элемент не связан с процедурой .
− – среднее время считывания i-го модуля из внешней памяти в оперативную па-
мять ЭВМ, = 1, ⋯ , ;
- tfс – среднее время считывания f-го массива из внешней памяти в оперативную па-
мять ЭВМ, = 1, ⋯ , ;
- tfз – среднее время записи результатов в f-й массив, находящийся в в оперативной
памяти ЭВМ, = 1, ⋯ , .

Введем теперь следующие переменные, нахождение значений которых и будет ре-

зультатом решения поставленной задачи.

1, если j-я по порядку выполнения процедура включается в состав i-го модуля;

xij =
0, в противном случае;

i=1,..,V; V- возможное число модулей; = 1, ⋯ , .

170
 171

1, если ℓ-й информационный элемент включается в f-й массив;

zlf =
0, в противном случае;

f=1,..,F; F≤L; = 1, ⋯ , .

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

1, × ≥ 1; = 1, ⋯ , ; = 1, ⋯ , ;

=  

0, × = 0; = 1, ⋯ , ; = 1, ⋯ , .

з
1, × ≥ 1; = 1, ⋯ , ; = 1, ⋯ , ;
з
=  

з
0, × = 0; = 1, ⋯ , ; = 1, ⋯ , .

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

171
 172

1, × ≥ 1;

=  

0, × = 0.

з
1, × ≥ 1;
з
=  

з
0, × = 0.

Другими словами, ( з ) = 1, если массив с номером f содержит хотя бы один ин-

формационный элемент, необходимый для выполнения хотя бы одной процедуры из моду-
ля с номером i.
с(з) с(з)
Таким образом, переменные yiℓ и zif служат для формализации взаимосвязи систе-
мы разрабатываемых модулей с отдельными информационными элементами и массивами
при считывании и записи в процессе обмена с внешней памятью ЭВМ.
Задачу разбиения ИЛМ АСОИУ на функциональные модули с минимальным
временем обмена с внешней памятью ЭВМ (базой данных) можно теперь
формализовать формулируется следующим образом.
Запишем вначале критерий оптимизации, т.е. время обработки инфор-
мации в системе, которое минимизируется. Оно складывается из времени
считывания модулей, где содержатся соответствующие процедуры обработки
данных, и времени вызова соответствующих массивов, где содержатся соот-
ветствующие информационные элементы. Этот критерий, с учетом ранее
введенных обозначений, можно записать следующим образом:

з з
min 1− , × + + .
,

В этом выражении 1-е слагаемое – условие обработки информации

всеми процедурами модуля, причем одновременно 2 модуля не обрабатыва-

172
 173

ются и учет времени считывания модулей, причем процедуры выполняется

последовательно; 2-е и 3-е слагаемые – учет времени считывания (записи)
информационных массивов.
Рассмотрим теперь систему ограничений, без которой критерий не имеет смысла,
так как он принимает минимальное значение, если всем переменным присвоить значения,
равные нулю.
Такими ограничениями являются следующие ограничения, которые во многом оп-
ределяются или содержательным анализом проектируемой системы, или возможностями
технических средств, на которые будут возложена задача обработки данных в системе:
 на общее число процедур в составе каждого модуля:
m

x
j 1
ij  M i , i  1, V , где M i - допустимое число процедур в i-ом модуле;

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

дуля:
L

y
 1
i  Li , i  1, V ,

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

мых i-ым модулем;
 на сложность интерфейса между всеми модулями системы обработки данных:
L V V

  y
 1 i 1 ii 1
i yi  S ,

где S - максимально допустимый межмодульный интерфейс между модулями СОД,

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

y
 1
i  yi  S ii , для заданных i и i′,

где S ii - максимальное число общих переменных (информационных элементов),

обрабатываемых модулями i и i′;
 на однократность включения процедур в программные модули:
V

x
i 1
ij  1, j  1, m ;

 на включениеотдельных процедур в состав одного модуля:

xij+xij′≤1, для заданных j и j′, i=1,..,V;
 на передачу управления из модуля до завершения обработки информации всеми проце-
дурами модуля:

173
 174

x
j 1
ij  (1  xij 1 )  1, i  1, V ;

 на дублирование информационных элементов в массивах:

F

z
f 1
f  k ,   1, L; k  1, K , где k - допустимая степень дублирования информаци-

онных элементов в массивах системы;

 на размер записи каждого массива:
L

z
 1
f  Nf; f  1, F , где N f - максимально допустимое число информационных

элементов в f-ом массиве.

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

5.4. Синтез информационного обеспечения АСОИУ модульного типа

5.4.1. Постановка задачи

Модульное построение проектируемой АСОИУ накладывает ряд условий на синтез

информационного обеспечения. Основными из них являются необходимость учета дина-
мики реализации модулей и вызова в оперативную память ЭВМ соответствующих инфор-
мационных массивов в целом либо их частей.
Синтез информационного обеспечения проектируемой по модульному принципу
АСОИУ может быть осуществлен в три этапа.
На первом этапе определяются число и состав информационных массивов при задан-
ном составе и частоте использования каждого модуля. Критерием оптимизации при реше-
нии этой задачи является минимизация общего числа обменов проектируемой системы с
внешней памятью ЭВМ.
На втором этапе решается задача выбора оптимальных методов организации данных
в полученной на первом этапе системе информационных массивов и их размещение во
внешней памяти ЭВМ. Критериями решения этих задач могут быть
1) минимизация времени обмена с внешней памятью,
2) минимизация суммарных затрат на хранение и использование полученной систе-
мы информационных массивов,
3) минимизация времени решения одной какой-либо, обычно наиболее важной, за-
дачи.
На третьем этапе решается задача определения оптимальной величины блока данных,
при которой минимизируется общее время считывания, поиска и передачи данных в опера-
тивную память.

174
 175

Схема постановки и последовательности решения задач синтеза ИО АСОИУ мо-

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

5.4.2. Задача и модель определения числа и состава информационных

массивов

Пусть в результате диагностического анализа проектируемой АС для заданного ком-

плекса задач управления определено множество программных модулей M={m1, m2,…,
mv,…, mV}, где V – число таких модулей. Для каждого модуля mv установлена средняя час-
тота его функционирования Qv (v=1,..,V) в заданный интервал времени, например, в сутки.
Известно также множество информационных элементов D={d1, d2,…, dℓ,…, dL}, где L –
число таких элементов, с которыми связаны модули множества M.

Рис. 5.4.1. Схема постановки и последовательности решения задачи синтеза ИО

АСОИУ

Каждый информационный элемент dℓ характеризуется длиной записи, например, в

байтах λℓ. Величины λℓ (ℓ=1,..,L) образуют вектор Λ={λ1, λ2,…, λℓ,…, λL}.
Для каждого модуля mv (v=1,..,V) информационный элемент dℓ (ℓ=1,..,L) может быть
входом, выходом или модуль mv никак не связан с информационным элементом dℓ. В пер-

175
 176

вом случае будем говорить, что модуль mv считывает элемент dℓ,а во втором – модуль mv
записывает элемент dℓ.
Связь между модулями и информационными элементами может быть задана в виде
двух матриц. Bс=║bvℓc║ и Bз=║ bvℓз ║, где bvℓc(bvℓз) равен единице, если ℓ-й информационный
элемент (ℓ=1,..,L) считывается (записывается) v-м модулем (v=1,..,V) и равен нулю в про-
тивном случае.
Обозначим через F возможное число информационных массивов, по которым рас-
пределяются информационные элементы. Очевидно, что F≤L.
Введем следующие булевы переменные:

1, если ℓ-й информационный элемент размещен в f-й массив

xlf = 0, в противном случае.

L
1, если  bvс  xf  1;
 1

z =
c
vf (1)
L
0, если  bvс  xf  0 ;
 1

L
1, если  bvз  xf  1;
 1

z =
з
vf (2)
L
0, если  bvз  xf  0 .
 1

Другими словами zvfc ( 3) принимает значение 1, если модуль mv связан с информацион-

ным элементом dℓ, который находится в массиве f.
Переменные xℓf (ℓ=1,..,L; f=1,..,F) образуют матрицу X=║ xℓf ║, определяющую рас-
пределение информационных элементов по информационным массивам. Матрицы
Z c  zvfc и Z 3  zvf3 размерности V*F каждая определяют связь программных модулей с
информационными массивами.
Сформулированную задачу определения числа и состава информационных массивов
можно теперь формально представить в виде следующей модели:
V F
R   Qv   ( z vfс  z vfз )  min . (3)
v 1 f 1

при ограничениях

176
 177

x
 1
f  Nf ( f  1, F ) (общее число информацио нных
(4)
элементов в массиве )
L

   xf  N~ f ( f  1, F ) (длина записи в массиве ) (5)

 1
F

x
f 1
f  1 (  1, L ) (дублирован ие элементов
(6)
в разных массивах )
где zℓfс и zℓfз определяются выражениями (1) и (2);
Nf – ограничения на общее число информационных элементов в f-м массиве;
N~ - ограничения на длину записи в f-м массиве.
f

Значения величин N~ f , Nf, f=1,..,F определяются разработчиком АСУ исходя из огра-

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

m1 m2 … mv … mV Модули

d1 d2 dℓ dL-1 dL Информационные
… …
элементы

b1 … bf … bF Массивы

m1 m2 … mv … mV

Двудольный
~
граф G

b1 … bf … bF

177
 178

Рис. 5.4.2. Графовая модель задачи

Необходимо синтезировать двудольный граф G~  ( M , B, Z с ( з ) ) , имеющий минималь-

ное число дуг при ограничениях на размеры и сложность информационных массивов, воз-
можности дублирования и распределения информационных элементов по массивам, где:
M – множество модулей: M={mv; v=1,..,V};
B – множество определяемых информационных массивов: B={bf; f=1,..,F};
Zс(з) – множество дуг, связывающих множество модулей с множеством массивов:
Zс(з)=║zvfс(з)║.
Рассмотрим следующий пример. Пусть после исследования проектируемой АСУ
было выяснено, что необходимы 3 модуля, связанные с 6 информационными элементами.
Эта связь и частота использования модулей в процессе функционирования АСОИУ приве-
дены в таблице 5.4.1.
Таблица 5.4.1
Номер Информационные элемен- Информационные элемен- Средняя частота ис-
модуля ты, считываемые модулями ты, записываемые модуля- пользования модуля
из БД ми в БД в
единицу времени
1 2, 3, 4, 5 1, 4 10
2 1, 2, 6 5 12
3 4, 5, 6 3 8

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

таблице 5.4.2.

Таблица 5.4.2
Информационный элемент 1 2 3 4 5 6
Длина элемента, (КБ) 20 30 20 20 40 50

Представим исходные данные в виде направленного двудольного графа

G  G ( M , D , B ) , где M  m1 , m2 , m3  - множество модулей системы,

D  d1 , d 2 , d 3 , d 4 , d 5 , d 6  - множество информационных элементов, B  B c  B з - мат-

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

ми и имеющая следующий вид (см. табл. 1):

178
 179

 0 1 1 1 1 0  1 0 0 1 0 0  1 1 1 2 1 0
     
В   1 1 0 0 0 1   0 0 0 0 1 0   1 1 0 0 1 1 .
 0 0 0 1 1 1  0 0 1 0 0 0  0 0 1 1 1 1
     

Граф G  G ( M , D, B ) изображен на рис. 1, где m1 , m2 , m3 - модули; d1 ,  , d 6 -

информационные элементы; a1 , a 2 , a3 - массивы. Дуга направлена от модуля к элемен-
ту, если этот элемент записывается модулем, и от элемента к модулю, если элемент
считывается модулем.
Один из вариантов построения двудольного графа G  изображен на рис. 2. Он по-
лучен при условии, что информационные элементы d1 , d 2 , d 3 , d 4 , d 5 , d 6 размещены в
массивах a1 , a 2 , a3 так, как показано на рис. 5.4.3.

Рис. 5.4.3.
Среднее число обменов системы программных модулей с внешней па-
мятью (базой данных) при размещении информационных элементов по мас-
сивам так, как показано на рис. 1, равно 100. Если, однако, в массив а1 по-
местить элементы d1 , d 2 , d 3 , в массив a2 - элементы d 4 , d 5 , а в массив a3 - эле-
мент d 6 , то среднее число обменов сократится до 90. Таким образом, имеет
место улучшение ранее составленного варианта размещения элементов по
массивам.
Рассматриваемая задача относится к классу задач нелинейного про-
граммирования с булевыми переменными.
Если число информационных элементов L относительно невелико, то
ее решение можно получить методом прямого перебора всех вариантов рас-
пределения информационных элементов по информационным массивам. Для
этого строят дерево вариантов по следующей схеме: первый информацион-
ный элемент помещают в первый информационный массив; второй – в пер-

179
 180

вый массив или во второй; третий – в первый, второй или третий массив и
т.д.
Очевидно, что число слоев такого дерева равно L , а число вершин в
к  ом слое ( к - номер информационного элемента) рано к  ( к  1) .
После построения L -го слоя дерева вариантов для каждого из них про-
веряются условия (4), (5) и (6) и среди им удовлетворяющих выбирается ва-
риант с минимальным значением функционала (3).
При большом числе информационных элементов L более рациональ-
ным является использование метода «ветвей и границ».
Точная нижняя оценка множества решений RН достигается в том слу-
чае, если все информационные элементы распределены в один информаци-
онный массив. Учитывая, что каждый считываемый или записываемый ин-
формационный элемент, по крайней мере, один раз должен быть использован
хотя бы в одном программном модуле, то из выражения (3) непосредственно
следует, что для вычисления RН справедлива следующая формула:
V
RН  2 Qv . (7)
v 1

Точная верхняя граница (оценка) множества решений RВ достигается,

если для каждого информационного элемента выделен свой информацион-
ный массив. В этом случае из выражения (3) непосредственно следует, что
для вычисления RВ справедлива следующая формула:
L V
RВ   Qv (bvlc  bvlз ) . (8)
l 1 v 1

Оценку Rn любого подмножества решений в n  й вершине дерева

ветвления можно определить по формуле:
Rn  RH  Rn , (9)
где Rn - приращение оценки в n  й вершине дерева ветвления.
Величина оценки Rn любого подмножества решений в n  й вершине
ветвления зависит от множества значений xlf  переменных, зафиксирован-
ных в этой n  й вершине в процессе ветвления, и может быть вычислена по
следующей формуле:
Rn   Qv Pvc  Pvз  .
V
(10)
v 1

Величины Pvc и Pvc в выражении (10) определяются по следующим

формулам:

180
 181

 Fn c Fn

 z vf  1,  z vf  1;
c


Pvc   f 1 f 1
Fn (11)
 0,


f 1
z c
vf  1;

 Fn з Fn

 z vf  1,  z vf  1;
з


Pvз   f 1 f 1
Fn (12)
 0,


f 1
z vf  1.
з

В выражениях (11) и (12) величина Fn - это число образуемых массивов

в n  й вершине дерева ветвления, а zvfc и zvfз - булевы переменные, опреде-
ляемые по формулам (1) и (2) соответственно при условии, что информаци-
онные элементы распределены по информационным массивам согласно n  й
вершине дерева ветвления.
Алгоритм решения задачи определения числа и состава информацион-
ных массивов можно теперь представить в виде следующей последователь-
ности шагов.
1. Вводят исходные данные задачи в виде массивов M , D,  и матриц
BC и BЗ .
2. По формулам (7) и (8) вычисляют верхнюю и нижнюю границы RВ и
RН .
3. Распределяют информационный элемент d1 в информационный
массив a1 (строят первый слой дерева вариантов).
4. Полагая i  1,2 , помещают элемент d 2 последовательно в информа-
ционный массив с номером i (строят второй слой дерева вариантов).
5. Для каждой вершины k  го слоя (варианта распределения рассмат-
риваемых информационных элементов по информационным масси-
вам) последовательно проверяют выполнимость условий (4) и (6),
полагая F  Fn , где n - номер рассматриваемой вершины. Для тех
вершин, у которых условия (4) и (6) не выполняются, полагают
Rn  RB , для остальных вершин значения Rn вычисляют по формулам
(9) – (12).

181
 182

6. Находят вершину рассматриваемого k  го слоя с номером n * таким,

что имеет место равенство Rn  min
*
nS
Rn , где S k - множество номеров
k

построенных вершин этого слоя.

7. Проверяют, все ли слои дерева вариантов построены. Если да, то
выполняют п. 9, в противном случае выполняют пункт 8.
8. Запоминают номер вершины n * рассматриваемого k  го слоя и
строят вершины (k  1) -го слоя, взяв в качестве исходной вершину с
номером n * . После построения всех вершин (k  1) -го слоя переходят
к п. 5.
9. Находят решение задачи определения числа и состава информаци-
онных массивов, выбирая в каждом слое построенного дерева вари-
антов вершины с соответствующими номерами n * .
Дерево вариантов применительно к рассмотренной выше задаче рас-
пределения 6 информационных элементов по информационным масси-
вам приведены на рис. 5.4.4.

Рис. 5.4.4.
Точное решение этой задачи состоит в следующем: 1-й, 2-й и 3-й
информационные элементы помещают в 1-й информационный массив;
4-й и 5-й информационные элементы помещают во 2-й информацион-
ный массив; 6-й информационный элемент составляет 3-й информаци-
онный массив. Общее время считывания, поиска и передачи требуемых
данных при этом равно 90.

182
 183

Лекция 2

5.4.3. Задача выбора оптимальных методов организации полученных

массивов иразмещения программных модулей и массивов во внешней
памяти ЭВМ
Как об этом уже говорилось, критериями, используемыми для решения данных задач,
являются: 1) минимизация суммарных затрат на создание, хранение и эксплуатацию ин-
формационных массивов и программных модулей СОД либо 2) минимизация общего вре-
мени обработки данных или времени решения одной из задач обработки данных.
Введем необходимые обозначения:
I={1, 2,…, i,…, I0} – множество задач обработки данных;
N=║niv║ - матрица принадлежности модуля к задаче, т.е.

1, если модуль v используется для решения задачи i;

niv=
0 в противном случае.

Mс(з)=║mvfс(з)║ - матрица принадлежности массива к модулю,

т.е.
1, если f-й массив считывается (записывается) v-м модулем
с(з)
mvf =
0 в противном случае.
Pi – частота решения i-й задачи в АСОИУ;
qvi – частота использования v-го модуля при решении i-й задачи;
Nf – количество информационных элементов в одной записи f-го массива;
Lf – число записей в f-ом массиве;
Rf=Nf*Lf – объем (размер) информационного массива f (общее число информацион-
ных элементов в массиве);
C0 – стоимость единицы рабочего времени процессора для решения вычислительных
задач;
Cυ – приведенная стоимость единицы рабочего времени носителя информации υ-го
типа с внешней памятью ЭВМ;
Sυ – стоимость блока управления υ-го типа носителя информации; υ=1,..,υ0
τvυ– время считывания v-го модуля, размещенного на υ-м типе носителя;
tfμυ(с), tfμυ(з) – время считывания (записи) f-го массива, организованного с использованием μ-го
способа (можно использовать разные способы доступа к данным: прямой, произвольный по
ключам и т.п., можно по-разному организовывать саму структуру данных: реляционная, ие-
рархическая, сетевая и смешанная) и размещенного на υ-м типе носителя информации;
183
 184

Tv– процессорное время реализации v-го модуля;

dυ – объем запоминающего устройства υ-го типа носителя информации;
av – размер v-го модуля;
Δτv – время работы процессора при поиске v-го модуля;
Δτfс(Δτfз) – время работы процессора при считывании (записи) f-го массива.
Введем переменные:
1, если f-й массив организован μ-м методом и размещен на υ-м типе носителя
информации
υ
xfμ =
0 в противном случае.

1, если v-й модуль размещен на υ-м типе носителя информации

yvυ=
0 в противном случае.
1) Рассмотрим вначале постановку задачи выбора оптимальных методов организации
информационных массивов, размещения массивов и модулей во внешней памяти, миними-
зирующих суммарные затраты на создание, хранение и эксплуатацию модульной АСОИУ.
Полные приведенные затраты C на решение задач АСОИУ являются суммой капи-
тальных Ск и эксплуатационных затрат Сэ, т.е. С=Ск+Сэ.
Капитальные затраты Ск определяются выбором типа носителя информации, т.е. вы-
бором технических средств и могут быть определены следующим выражением:
 
0  V F 0 
Ck  
 1
S    (  a v  y v    R f  x f  )  d  1  (1)
 v 
1 f 1  1 
      
 объем информации на   ом носителе 
  - наименьшая целая часть, большая или равная α, где α – число носителей памяти
типа υ=1,..,υ0.
Эксплуатационные затраты, в общем случае, содержат следующие составляющие:
 Стоимость непосредственной вычислительной работы процессора Сэобр; при ре-
шении задач i=1,..,I0;
 Стоимость процессорного времени при формировании адресов СэФА; для поиска
нужных модулей и информационных элементов в соответствующих массивах;
 Стоимость записи и считывания массивов и модулей, т.е. стоимость обмена между
оперативной и внешней памятью Сэобм. -важно только это слагаемое
Для вычисления этих составляющих могут быть использованы следующие формулы:
I0 V V I V
C  С0  Pi  niv  qvi Tv  C0  Tv  Pi  niv  qvi  C0  Tv  Qv
обр
э (2)
i1 v1 v1 i1 v1

184
 185

0  I0  F 0 
 
V
Cэобм  C Pi  niv  qvi  v  yv  xf  mvfc  tf(с)  mvfз  tf( з)  
1  i1 v1  f 1 1 
 V    F 0   (3)
( з) 
0
с (c) з

 C  Qv  v  yv  x f  mvf  t f  mvf  t f  
1 v1  f 1 1 
 I0 
Cэ  С0  Pi  niv  qv  v  Pi  niv  qv mvfc  vfс  mvfз  vfз  (4)
V I0 V F
ФА i i

 i1 v1 i1 v1 f 1 

Так как выражения (2) и (4) не содержат введенных переменных, то задача выбора
способов организации и размещения модулей и массивов во внешней памяти формализует-
ся следующим образом:
найти min Ck  CЭОбм ,
y , x 
v f

где Ск и Сэобм определяются формулами (1) и (3),

при следующих ограничениях:
 на время Ti обмена с внешней памятью ЭВМ при решении i-й задачи:
0
   F 0   ( з) 
 
V

 niv  Pi  q v   v  yv   x f  mvf  t f  mvf  t f

i

 1 
c  (с) з
  Ti (5)
v 1 f 1  1 
 на используемый объем носителя информации υ-го типа:
V F 0

 av  yv   R f  xf  G ,   1,0

v 1 f 1  1
(6)

 на совместное размещение модулей и массивов в одном блоке носителя υ-го типа:

yvυ+xfμυ≤1 для заданных υ и (f, μ); (7)

 на размещение модулей на различных носителях:

V

 y  1,
v 1
v v  1,V (8)
 на размещение массивов на различных носителях:
0 0


 
1
x  1,
1
f f  1, F (9)

 на размещение модулей и массивов на носителях определенного типа:

0



y  1,
1
v для заданного υ (10)
F 0



x  1,
f 1 1
f для заданного υ. (11)

185
 186

2) Рассмотрим постановку и решение задачи выбора оптимальных методов организа-

ции массивов и модулей во внешней памяти, минимизирующих: 1) общее время обработки
данных; 2) время решения одной из задач управления.
В первом случае критерий имеет вид:
0
   F 0   ( з) 
 
V
min 
xf , yv  v 1  1
Qv   v  yv   x f  mc
vf  t  (с)
f  m з
vf  t f  (12)
 f 1  1 
Во втором – зафиксировав некоторое i:
0
   F 0   ( з) 
 
V

  iv v  v  yv  x f  mvf  t f  mvf  t f 

 (с )
min n  P  qi
 c з
(13)
xf , yv  v1
 i
1  f 1 1 
В этих задачах кроме ограничений (5) – (11) учитывается дополнительное ограниче-
ние на суммарные затраты П на создание и эксплуатацию АСУ:
Ск+Сэобм≤П (14),
обм
где Ск и Сэ определяются формулами (1) и (3).
Сформулированные задачи являются задачами целочисленного линейного програм-
мирования с булевыми переменными.

5.4.4. Задача определения оптимальной величины блока данных

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

дульной АСУ получены следующие исходные данные, необходимые для определения оп-
тимальной величины блока обмена данными с внешней памятью:
 система модулей программного обеспечения;
 множества информационных массивов и их связей с системой модулей;
 способы и характеристики размещения массивов и программных модулей на уст-
ройствах внешней памяти.
Введем необходимые переменные и обозначения:
Lfυ – число записей f-го массива, размещенного на υ-м типе запоминающего устройст-
ва;
M=║mvf║, v=1,..,V ; f=1,..,F – матрица связи массивов с модулями системы:
2, если f-й массив считывается и записывается v-м модулем,
mvf= 1, если f-й массив только считывается v-м модулем,
0, если f-й массив не используется v-м модулем;
Xfυ – целочисленная переменная, определяющая число записей в блоке при считыва-
нии и записи в f-й массив, размещенный на υ-м типе запоминающего устрой-
ства;
Требуется выбрать множество переменных {xfυ} таким образом, чтобы минимизиро-
вать общее число обращений к внешней памяти с учетом технологических ограничений.
Эта задача формулируется следующим образом:

186
 187

 m 
F 0 V

  
min
x vf  L f  x 1
f (15)
f
 f 1 1 v 1

при ограничениях:
 на объем оперативной памяти Dv, доступной для данного v-го модуля:
F  0

 

f 1 1
m vf x f  Dv, v  1, V (16)

 на допустимый минимальный dυ и максимальный d объема блока, размещенно-

го в υ-м типе запоминающего устройства:
dυ≤ xfυ≤ d , f=1,..,F ; υ=1,..,υ0 (17)
 на целочисленность величины блока:
xfυ ≥ 1, где xfυ – целое , f=1,..,F ; υ=1,..,υ0 (18)
Данная задача является задачей дискретного программирования с нелинейной целе-
вой функцией и линейными ограничениями и может быть решена алгоритмом, основан-
ным на схеме «ветвей и границ».

ГЛАВА 6. МОДЕЛИ СИНТЕЗА СТРУКТУРЫ АСОИУ

6.1. Формализация общей задачи синтеза структуры АС

В зависимости от задачи исследования в понятие структуры системы вкладывают

различный смысл. Так, при разработке структуры АС в это понятие входит, например, оп-
ределение множества элементов системы и связей между ними, распределение задач, возла-
гаемых на технические средства АС, по уровням и элементам системы и выбор комплекса
технических средств, обеспечивающего их своевременное решение.
Основными проблемами, возникающими при разработке структуры АС, являются:
1) определение необходимого числа уровней иерархии;
2) установление между уровнями правильных взаимоотношений, что связано с зада-
чами согласования целей элементов различных уровней и оптимальным стимулированием
их работы;
3) распределение ответственности;
4) выбор конкретных схем обработки информации и создание контуров принятия
решений;
5) организация информационных потоков;
6) выбор соответствующих технических средств.
Для формализации задачи синтеза структуры АС в самом общем виде введем сле-
дующие обозначения:
P - множество возможных принципов построения системы или ее элементов. Воз-
можные принципы бывают обычно заданы и выбираются при синтезе системы;

187
 188

 - выбранные принципы построения системы или ее элементов. Очевидно, что

 Р;
F - множество взаимосвязанных функций (операций), выполняемых системой. Каж-
дому набору принципов  построения системы соответствует некоторое множество функ-
ций F ( ) , из которого при проектировании системы необходимо выбрать подмножество
f  F ( ) , достаточное для реализации выбранных принципов  ;
А - множество возможных взаимосвязанных элементов системы. Подобными эле-
ментами, например, могут быть узлы системы, технические средства, пункты обслужива-
ния, отдельные исполнители, коллективы и т.п.;
а - выбранные взаимосвязанные элементы системы. Введем также операцию ото-
бражения W элементов множества F на элементы множества А . Оптимальное отобра-
жение должно обеспечивать экстремум некоторой (или некоторых) целевой функции при
выполнении заданных ограничений.
В общем случае задача синтеза оптимальной структуры состоит в определении :
  Р ; (1)

f  F ( ) ; (2)

a  A; (3)

 f  F ( )W a  A. (4)

Если заданы принципы построения системы, то синтез оптимальной структуры со-

стоит в определении (2), (3), (4). Если заданы принципы построения системы и выполняе-
мые системой функции, то синтез оптимальной структуры состоит в определении (4) и (3).
Если заданы принципы построения системы, выполняемые системой функции и элементы
системы, то синтез оптимальной структуры состоит в определении (4), т.е. в нахождении
оптимального отображения множества выполняемых функций на множестве взаимосвя-
занных элементов.
Задача анализа состоит в определении характеристик системы при заданных услови-
ях (1) – (4). Если для некоторых элементов возникает проблема большой нагрузки, то усло-
вия с (1) по (4) должны учитывать правила функционирования элементов. В ряде случаев
эти правила определяются при синтезе, так как от них может зависеть распределение функ-
ций и взаимосвязей в системе.

6.2. Частные задачи синтеза оптимальной структуры АСОИУ

188
 189

6.2.1. Общая постановка задачи

Рассмотрим некоторые частные постановки задач формализованного распределения
множества решаемых задач между узлами АСОИУ при различных критериях и ограниче-
ниях.
Выясним вначале возможные критерии оптимизации.
А) Минимизация затрат на реализацию задач в АС.
I J
min Wij xij , (1)
i 1 j 1

где i  1, I - множество функциональных задач, реализуемых в АС, j  1, J - множество

обслуживаемых узлов системы, Wij - затраты на реализацию задачи с номером i в узле с
1
номером j . Кроме того, пусть xij   ; xij  1 , если задача с номером i выполняется в узле
0 
с номером j и xij  0 - в противном случае.
Б) минимизация общего времени решения всех задач АС.
I J
min  tij xij , (2)
i 1 j 1

где tij - время решения задачи с номером i , если она выполняется в узле с номером j .
В) Минимизация максимального времени решения задач АС.
 I J 
min max  tij xij  . (3)
 i 1 j 1 
Возможна оптимизация по более сложным критериям, включающим (1) – (3), а так-
же использование критериев такого общего типа, как получение максимальной прибыли,
обеспечение требуемого времени готовности системы и т.д.
В качестве ограничений в частных задачах синтеза могут выступать следующие ог-
раничения:
а) на связи между задачами, т.е. задан граф задач в виде матрицы
ii . (4)
б) на связи между узлами, т.е. задана матрица вида
 jj  (5)
в) на общие затраты на реализацию задач в АС
I J

W x
i 1 j 1
ij ij  Wдоп (6)
г) на затраты на реализацию задач в узлах
I

W x
i 1
ij ij  W jдоп , j  1, J , (7)
д) на загрузку каждого узла
I

 t
i 1
ij ij ij x   j , j  1, J , (8)

189
 190

где ij - интенсивность поступления задачи с номером i в узле с номером j .

е) на общее время решения всех задач

I J

 t x
i 1 j 1
ij ij  T, (9)
ж) на время решения отдельных задач
J

t x
j 1
ij ij   i , i  1, I . (10)
Рассмотрим теперь некоторые частные задачи синтеза оптимальной структуры АС.

6.2.2. Первая частная задача синтеза

Необходимо так распределить задачиi  1, I между узлами j  1, J , чтобы обеспечить

минимум общих затрат (1) или минимум общего времени решения (2) при исполнении
ограничений на загрузку каждого из узлов (8) , или затраты в каждом узле j , то есть огра-
ничение (7).
Математическая модель этой задачи может быть записана следующим образом:
I J

 a x
i 1 j 1
ij ij  min (11)
при следующих ограничениях:
I J

 a x
i 1 j 1
ij ij  b j , j  1, J , (12)
J

x ij  1, i  1, I , xij  1,0. (13)

j 1

В этих соотношениях приняты следующие обозначения:

aij - затраты (время решения) задачи с номером i в узле с номером j ;
b j - допустимые затраты (загрузка) в узле с номером j ;
xij - переменная, равная 1, если задача с номером i решается в узле с номером j , и
равная 0 – в противном случае.
Условие (13) означает, что каждая задача должна решаться только в одном узле.
Наиболее удобным для решения данного класса задач является метод «ветвей и гра-
ниц». Применительно к данной задаче он заключается в направленном движении по вер-
шине дерева, полученного путем фиксирования части переменных xij , xij  0,1.
Вершины первого уровня получают, поочередно закрепляя первую задачу за пер-
вым узлом, вторым и т. д., т.е. фиксируя xij  1 для узлов j  1,2,, J при i  1.

190
 191

Вершины второго уровня получают, фиксируя xij  1ij для j  1,2,, J при i  2 и
т. д. Д.ля каждой вершины находят оценку, вычисляемую по формуле

a  a ij ij , (14)
i i* i i *

где i * - число рассмотренных уровней ветвления; aij  min aij .

j

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

свойств рассматриваемой задачи, что существенно при решении задач большой размерно-
сти.
Вначале из матрицы коэффициентов aij системы (11) исключаем все элементы,
для которых выполняется условие aij  b j , i  1, I , j  1, J . При этом для любой строчки
возможны следующие варианты:
- исключены все элементы a ij , тогда решение отсутствует;
- остался лишь один элемент a ij , он обязательно входит в оптимальное решение,
если оно существует. Значение b j заменяется величиной (b j  aij ) , и этот элемент в
дальнейшем поиске не участвует;
- осталось несколько элементов, они участвуют в дальнейшем поиске оптимального
решения.

6.2.2. Вторая частная задача синтеза

Необходимо так распределить задачи i  1, I между узлами j  1, J , чтобы обеспе-

чить минимум общих затрат ( критерий 1) или минимум общего времени решения (кри-
терий 2) при выполнении ограничений на общее время решения (9) или общие затраты
(6) соответственно.
Математическая модель этой задачи может быть записана следующим образом:
I J

 a
i 1 j 1
ij xij  min (15)
при следующих ограничениях:
I J

 b x
i 1 j 1
ij ij  B, (16)
J

x ij  1, xij  1,0, i  1,2,, I . (17)

j 1

В соотношениях (15) - (17) приняты следующие обозначения:

a ij - затраты (время решения) задачи i  1, I , расположенной в узле j  1, J ,
bij - время решения (затраты) на задачу i  1, I , расположенную в узле j  1, J ,

191
 192

B - общее время решения (затраты) всех задач.

Для решения этой задачи, прежде всего, берутся минимальные элементы в ка-
ждой строке матрицы коэффициентов aij и проверяется выполнение условия (16) для
соответствующих элементов матрицы коэффициентов bij .
Если условие (16) выполняется, то это и будет оптимальным решением. Если оно не
выполняется, то из матрицы коэффициентов aij и bij исключают те элементы, которые
не могут войти ни в одно допустимое решение. Для этого последовательно рассматривают-
ся все элементы матрицы aij и проверяют следующее условие:
l 1 I

 bij  blj 
i 1
b
i  l 1
ij  B, l  1, I , j  1, J , (18)
где bij - минимальный элемент в соответствующей строке;
blj - рассматриваемый элемент, j  l .
Другими словами, каждая задача последовательно закрепляется за каждым из узлов
и проверяется выполнение условия (16) в лучшем случае.
Если условие (18) нарушается, то соответствующий элемент blj не входит в допус-
тимое решение и исключается из матрицы bij . Из матрицы aij исключается соответст-
вующий элемент aij .
Из условия (17) следует, что в каждой строке может быть только один элемент. По-
I J I J
этому min  aij xij без учета выражения (14) равен  min  aij xij . Отсюда следует, что
i 1 j 1 i 1 j 1

если для элементов одновременно выполняются условия aij  alj и bij  blj , ( j  l ) , то эти
элементы могут быть исключены из рассмотрения.
Хотя исключение элементов не всегда приводит к оптимальному решению, однако
объем вычислений резко сокращается.
Далее используется метод «ветвей и границ». В отличие от предыдущей задачи,
ветвление осуществляется с учетом ограничения (16), что существенно сокращает число
рассматриваемых вариантов. Оценка для каждой вершины находится по элементам матри-
цы (15) аналогично предыдущей задаче (14). Ограничение при этом имеет следующий вид:

b  b ij ij  В, (19)
i i* i i *

где i * - уровень ветвления;

bij  min bij .
j

6.2.4. Третья частная задача синтеза

192
 193

Необходимо так распределить задачи i  1, I между узлами j  1, J , чтобы обеспечить

минимум общих затрат ( критерий 1) или минимум общего времени решения (критерий
2) при выполнении ограничений на общее время решения (критерий 9) и загрузку узлов
(критерий 8), либо на общие затраты (критерий 6) и загрузку узлов (критерий 8) соответст-
венно.
Математическая модель этой задачи может быть записана в следующем виде:
I J

 a x
i 1 j 1
ij ij  min (20)
при следующих ограничениях:
I J

 b x
i 1 j 1
ij ij  B, (21)
I

c x
i 1
ij ij  c j , j  1, J , (22)
J

x ij  1, xij  0,1. (23)

j 1

Для решения этой задачи, прежде всего из матриц коэффициентов aij , bij , cij
исключаются элементы, которые заведомо не могут войти в оптимальное решение. Исклю-
чение элементов bij и cij из матриц систем (21) и (22) осуществляется аналогично тому, как
это делалось рассмотренному выше, т.е. исключаются все элементы, для которых не вы-
полняется условие (18). Оценка для матрицы коэффициентов (20) находится аналогично
оценке системы (14) в первой задаче.
Лекция 3

6.2.5.Примеры решения рассмотренных задач

Пример 1. Этот пример рассматривается для того, чтобы показать, как осуществля-
ется процедура ветвления. Итак, пусть необходимо решить следующую задачу:
4 4

 a x
i 1 j 1
ij ij  min (24)
при следующих ограничениях:
4


i 1
xij  1, (25)
4


j 1
xij  1, (26)

xij  0,1, (27)

193
 194

8 5 6 4
 
5 3 2 2
aij   . (28)
1 7 3 4
 
2 3 8 5 
Условие (25) означает, что каждый узел может решать только одну задачу. Условие
(26) означает, что каждая задача может решаться только в одном узле.
Будем изображать множество вариантов кружками, в верхней части которых про-
ставлен номер множества, а в нижней – значение нижней границы (см. рис. 6.3.1).
Для вычисления нижней границы используется следующее соотношение:
a  a ij ij , (29)
i i* i i *

где aij  min aij , i * - число рассмотренных уровней ветвления.

j

Для исходного множества (обозначим его через «0») соотношение (29) имеет вид
4

 aij   min aij  4  2  1  2  9 , т.е. из матрицы (28) выбираются минимальные числа

i 0 i 1 j 1, 2 , 3, 4

по строкам и эти числа складываются. При этом условие (25) может нарушаться.

Вершины первого уровня получим, поочередно закрепляя первую задачу за первым,

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

194
 195

Рис. 6.3.1. Процедура ветвления

Таблица 6.3.1

j a ij a ij
i i * i  i*

1 8 +2+3+3 16
2 5 +2+1+2 10
3 6 +2+1+2 11
4 4 +2+1+2 9

Вершины второго уровня получим, закрепив первую задачу за четвертым узлом.

Соответствующие значения нижней границы представлены в таблице 6.3.2.
Таблица 6.3.2

j a ij a ij
i i * i  i*

1 4+5 +3+3 15
2 4+3 +1+2 10
3 4+2 +1+2 9

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

Вершины третьего уровня получим, закрепив первую задачу за четвертым узлом, а

вторую задачу за третьим. Соответствующие значения нижней границы представлены в
таблице 6.3.3.
Таблица 6.3.3

j a ij a ij
i i * i  i*

1 4+2+1 +3 10
2 4+2+7 +2 15

Из таблицы 6.3.3 следует, что третья задача должна быть закреплена за узлом номер
один. Тогда четвертая задача однозначно закрепляется за узлом номер два.
Окончательный ответ представлен в матрице следующего вида:

195
 196

0 0 0 1
 
0 0 1 0
xij   .
1 0 0 0
 
0 1 0 0 
Значение целевой функции равно 10.

Пример 2. Рассмотрим решение первой частной задачи синтеза оптимальной струк-

4 4
туры. Необходимо найти min  aij xij при следующих ограничениях:
i 1 j 1

8 5 6 4
 
4
5 3 2 2

i 1
aij xij  b j ; aij  
1 7 3 4
;
 
2 3 8 5 
4

x ij  1; xij  0,1; b j  3 1 5 3 .
i 1

В соответствии с ранее рассмотренным алгоритмом выполним упрощение матрицы

aij , для чего исключим элементы, для которых выполняется условие aij  b j . Первая
строчка после исключения не содержит ни одного элемента, т.е. первая задача не может
быть решена: решение отсутствует.
Пусть b j  3 6 5 3 . Тогда после исключения из матрицы aij элементов, для
которых выполняется условие aij  b j , эта матрица примет следующий вид:
 5  
 
 3 2 2
aij   .
1  3 
 
2 3   
Первая строчка содержит только один элемент a12  5 , следовательно, он обязатель-
но войдет в решение. В отличие от рассмотренного ранее примера, в данном случае снято
условие, согласно которому один узел может быть загружен только одной задачей. Ресурс
на второй узел равен 6, следовательно, остается резерв в количестве 6  5  1 .
Далее процедура аналогична процедуре, рассмотренной выше, но каждый раз ищут-
ся минимальные элементы в столбцах, и проверяется, не нагружен ли данный узел.
Таким образом, x12  1 . Поэтому имеем:
 3 2 2
 
aij   1  3  , b j  3 1 5 3 , i  2, 3, 4.
 2 3  
 

196
 197

Выбираем минимальные элементы в каждой строке. Загрузка не превышает задан-

ную величину. Окончательно имеем:
0 1 0 0 0 1 0 0
   
0 0 1 0 0 0 0 1
xij   или x /
 1 0 .
0 0
ij
1 0 0 0
   
1 0 0 
1 0 0 0  0
Значение целевой функции в первом случае 5  2  1  2  10 , а во втором случае
5  2  1  2  10 . Варианты равнозначны.
Пример 3. Рассмотрим числовое решение второй частной задачи, а именно задачи
минимизации общих затрат при ограничении на общее время решения всех задач, т.е. бу-
дем искать
4 4
min  aij xij (30)
i 1 j 1

при следующих ограничениях:

I J

 b x
i 1 j
ij ij  B; (31)
J

x
j 1
ij  1; (32)

xij  0,1. (33)

Пусть
3 7 2 4 1,5 3 2 9
   
4 8 1 3 2 6 5 10 
aij   6 9 6 2 , bij   3
 7 6 11 , B  20.
   
 6 10 7 1 4 8 7 12 
7 5 3 
1 4 9 8 5 
 
Сначала находим минимальные элементы в каждой строке матрицы aij и проверя-
ем, удовлетворяется ли условие (31) по одноименным элементам матрицы bij :
5

b
i 1
ij  2  5  11  12  5  35  20 .

Условие (31) не выполняется, и задачу «в лоб» решить не удается. Приступим к уп-

рощению матриц коэффициентов aij и bij . Для матрицы bij последовательно для всех

элементов проверяется условие (18), т.е. условие

l 1 I

b
i 1
ij  blj  b
i  l 1
ij  B, l  1, I , j  1, J , (34)

197
 198

где bij - минимальный элемент в соответствующей строке;

blj - рассматриваемый элемент, j  l .
1,5  2  3  4  4  14,5,
3  2  3  4  4  16,
Для l  1 :
2  2  3  4  4  15,
9  2  3  4  4  22.
Элемент b14 не удовлетворяет условию (34), он исключается из матрицы bij , и од-
ноименный элемент a14 исключается из матрицы aij . Аналогично для l  2 имеем:
2  1,5  3  4  4  14,5,
6  1,5  3  4  4  18,5,
5  1,5  3  4  4  17,5,
10  1,5  3  4  4  22,5.
3  1,5  2  4  4  14,5,
7  1,5  2  4  4  18,5,
Для l  3 :
6  1,5  2  4  4  17,5,
11  1,5  2  4  4  22,5.

4  1,5  2  3  4  14,5,
8  1,5  2  3  4  18,5,
Для l  4 :
7  1,5  2  3  4  17,5,
12  1,5  2  3  4  22,5.

1,5  2  3  4  4  14,5
1,5  2  3  4  9  19,5
Для = 5:
1,5  2  3  4  8  18,5
1,5  2  3  4  5  15,5
Легко видно, что для l  5 все элементы удовлетворяют условию (34).
Поскольку в каждой строчке может быть только один элемент и в обеих матрицах
aij и bij осуществляется минимизации, то, очевидно, что при одновременном выполне-

нии условий aij  alj , bij  blj , соответствующие элементы в матрицах aij и bij могут

быть исключены из рассмотрения одновременно.

Например, рассматривая первую строку в матрицах aij и bij , можно сделать сле-

дующее заключение, рассматривая следующие пары элементов этой строки:

198
 199

- (3 и 7) и (1,5 и 3) – условие aij  alj , bij  blj выполняется и, следовательно, можно убрать
элементы и ;
- (2 и 4) и (2 и 9) - условие aij  alj , bij  blj снова выполняется и, следовательно, можно уб-
рать элементы = 4и = 9.
Таким образом, первая строка матрицы aij запишется как ( 3 – 2 - ), а последняя
строка как ( 7 - - 1).
После соответствующих упрощений матрицы aij и bij принимают следующий
вид:
3  2  1,5  2 
   
4  1  2  5 
aij  6    , bij   3
    .
   
6    4   
7   
1 4   5 
 
Из матрицы aij в каждой строке выбираем минимальные элементы и получаем
следующее решение:
0 0 1 0
 
0 0 1 0
xij   1 0 0 0 .
 
1 0 0 0
0 0 0 1 


Подсчитываем время решения: 2+5+3+4+5=19<20. Оно не превышает допустимой

величины. Задача решена.
Если бы это не удалось, пришлось бы вести ветвление, и каждый минимальный ва-
риант проверять на условие (31).

6.3. Обобщенная математическая модель определения рациональной структуры рас-

пределенной АСОИУ

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

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

199
 200

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

Под определением структуры АСОИУ будем понимать следующие операции:

1. Выбор задач управления, возлагаемых на технические средства АСОИУ.
2. Выбор алгоритмов их реализации в АСОИУ.
3. Распределение выбранных задач по узлам (уровням) системы.
4. Определение КТС в узлах АСОИУ.
Выбранная структура считается рациональной, если общая эффективность разраба-
тываемой АСОИУ максимальна.
Для формализации задачи введем ряд обозначений.
Пусть Е – это множество задач управления. Каждой задаче припишем номер (индекс)
= 1, ⋯ , . Обозначим через множество алгоритмов решения -ой задачи в АСOИУ,
включая решение задачи без применения технических средств, = ⁄ = 1, ⋯ , .
/
Через ║∝ / ║ обозначим матрицу связи между задачами. Задачи и считают-
/

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

ной для -й задачи, при этом ∝ / имеет смысл среднего потока информации от -й за-
/

дачи к / -й. Если задачи не связаны, то полагают, что∝ / = 0.

/

Пусть – множество номеров узлов (уровней) АСОИУ, = ⁄ = 1, ⋯ , , а

Ɣ= ║  jj  ║ - матрица удельных затрат на передачу информации из -го узла вузел / .Для не
связных узлов полагаем / = ∞, а =0).
Обозначим через множество номеров технических средств, которые могут быть
применены при проектировании АОИУ, т.е. = ⁄ = 1, ⋯ , , и пусть - величина,
характеризующая ресурсы -го технического средства.
Пусть, кроме введенных параметров, – эффективность решения -й задачи k-м
способом, если она размещена в j-м узле.
Пусть, также – потребность в ресурсах технических средств -й задачи, решаемой
k-м способом (например, в машинном времени, памяти и т.п.); – затраты на эксплуата-

200
 201

цию ℓ-го технического средства в j-м узле, K l - капитальные затраты на технические сред-
ства, – затраты на разработку и внедрение i-й задачи в k-м вариантеее реализации.
Напомню, что под термином «задача» понимается комплекс взаимосвязанных опе-
раций по обработке информации и принятию решений. Выбор этих задач может осуществ-
ляться, например, экспертным методом, о чем уже говорилось ранее. Также экспертным
методом может быть определена эффективность решения задач аikj и другие необходимые
для анализа данные.
Таким образом, задача состоит в максимизации эффекта от разрабатываемой струк-
туры АСОИУ, который определяется эффективностью решения задач управления в соот-
ветствующих узлах системы, т.е. зависит от выбора уровня и алгоритма решения задач
управления с учетом затрат на обмен информацией между задачами, решаемыми на раз-
личных уровнях, и затрат на эксплуатацию системы.

Введем следующие переменные:

1, если i-я задача решается в j-м узле k-м способом

xikj =
0 в противном случае

1, если j-й узел оборудуется ℓ-м техническим средством

xlj =
0 в противном случае.

Задача может быть теперь записана в следующем виде:

 
  bikjik j  xikj  xik j   clj  x lj   max , (1)
i ,k , j ,i,k , j l , j   xikj , xlj
/
, , , = , = /, = /
 
где , , , /, /, / = − / ×
(2)
, , /, / ,

Величина , , , / , / , / равна эффективности решения k-го варианта i-й задачи в j-м узле, т.е.
′
aikj , если ikj=i′k′j′ и равна затратам на передачу информации из j-го узла в j-й в противном

случае.
В качестве ограничений здесь выступают следующие:

201
 202

1) x
{k , j}
ikj  1 (i  1, I ) , (3)
т.е. каждая задача должна быть решена, причем только в одном каком-либо узле и только
одним каким-либо способом;

2) k
{ , j }
  xj   k ik xikj  K ,
ikj
(4)
т.е. общие затраты на разработку АСУ, состоящие из стоимости на капитальные затраты на
технические средства и на разработку и внедрение задач не должны превышать заданной
величины K;
3)  mik  xikj   m  xj , ( j  1, J ), (5)
{i , k } { }

т.е. используемые технические средства имеют определенные ресурсные ограниче-

ния.
Рассмотренная задача является нелинейной задачей математического программиро-
вания.
Если заранее произведен выбор технических средств и известно, что задачи независи-
мы, то выражение (1) примет вид:
max  aikj  xikj (6)
ikj 

при ограничениях:
x
{k , j}
ikj  1 (i  1, I ) (7)

k
{i , k , j }
ik xikj  K1 , где K1  K   k   xj
{ , j }
(8)

m
{i , k }
ik xikj  m j , где m j   m  xj .

(9)

Задачу (6) - (9) можно свести к двухиндексной, если ввести переменную x fj . Взаимно
однозначное соответствие между множествами индексов {f} и {ik} устанавливается сле-
дующим соотношением:

= +∑ , где = 1, ⋯ , ; = 1, ⋯ , .

В этом случае задача будет иметь вид:

max  a fj  x fj (10)
{ fj}
bi 1

x
f bi
fj  1 (i  1, I ) (11)

202
 203

k
{ f , j}
f x fj  K1 (12)

m
{f}
f x fj  m j , j  1, J (13)

Если задачи зависимы, то вместо (10) следует записать

max  b fjf j   x fj  x f j  (14)

{ fjf j }

ГЛАВА 7. ОЦЕНКА НАДЕЖНОСТИ ПО АСОИУ

7.1. Постановка задачи

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

203
 204

мостоятельную программу и вводится, исходя из представлений исследова-

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

7.2. Постановка и модель решения прямой задачи

Рассмотрим вначале первую задачу. Итак, дан программный комплекс,

состоящий из M отдельных модулей, соединенных между собой. По структу-
ре программного комплекса можно построить стохастический граф, содер-
жащий M  2 вершин. Вершина 0 означает исток – начало программного
комплекса, а вершина M  1 - сток графа, т.е. завершение работы этого ком-
плекса. Каждый программный модуль вызывается на решение с заданной ве-
роятностью, исходя из цели функционирования программного комплекса или
значений исходных данных. Задача заключается в нахождении вероятности
безошибочных решений задачи программного комплекса, если известны ве-
роятности безошибочных решений задач всех программных модулей.
Рассмотрим матрицу G  G (t ), t  (t0 , t1 ,, t M 1 ) .
Элементами этой матрицы являются произведения
pij  Pi ( ti ), i, j  (0,1, , M  1) , где pij - вероятность перехода от программного
модуля с номером i к программному модулю с номером j , а Pi (ti ) - вероят-
ность безошибочного функционирования программного модуля с номером i
в течение времени ti .
Согласно [1 и 2] вероятность безошибочной работы модуля программного
обеспечения можно вычислить по следующей формуле:

204
 205

 i  ti  e  i  i ,
P(ti , i )  e (1)
где  i - интенсивность проявления ошибки модуля с номером i , а  i - интен-
сивность отладки модуля с номером i ; ti и  i - время вычислений и отладки
модуля с номером i . Обычно i  1 / Ti , Ti  начальное среднее время безоши-
бочной работы модуля с номером i ;  i  K i /( N ошиб
i
 Ti ), K i  коэффициент сжа-
тия времени отладки (тестирования) по сравнению со временем вычислений,
i
N ошиб  первоначальное предполагаемое число ошибок в модуле с номером i .
([1] Mysa J. A theory of software reliability and its application.// IEEE Trans. On-
softwareEng., vol. SE-1, sept. 1975. – P.312-327.
[2] КузнецовВ.В, СмагинВ.А.
Прямаяиобратнаязадачинадёжностисложныхпрограммныхкомплексов.// На-
дёжность и контроль качества. – 1997. – № 10. – С. 56-62.)
Так как вершины стохастического графа с номерами 0 и M  1 - это
фиктивные вершины, то полагаем, что время нахождения в них равно нулю, а
вероятность безошибочной работы равна единице.
Введем понятие шага, подразумевая под ним единичный переход от
одного программного модуля к другому. Чтобы найти вероятности безоши-
бочной работы за два шага, нужно просуммировать с соответствующими ве-
роятностями произведения вероятностей по всем путям, содержащим две
вершины (одна из них нулевая). Это достигается возведением матрицы G в
квадрат. При возведении матрицы G в куб получаем вероятности безоши-
бочного функционирования за три шага и т.д.
Построим следующую матрицу T :
T  I  G (t )  G 2 (t )    I ( I  G (t )) 1 , (2)
где I - единичная матрица.
Элемент матрицы T с номером (0, M  1) представляет собой выражение
для вероятности безошибочной работы всего программного комплекса с уче-
том всех возможных последовательностей вызовов отдельных программных
модулей.
В соответствии с правилами вычисления значений элементов обратной
матрицы, выражение для вероятности безошибочной работы программного
комплекса можно представит в следующем виде:
Q (t )
Y (t )  , (3)
R (t )

205
 206

где Q (t ) - алгебраическое дополнение элемента с номером ( M  1, 0) матрицы

( I  G ( t )) , а R (t ) - главный определитель матрицы ( I  G ( t )) .

Выполнив указанные преобразования, получим искомое выражение

для вероятности безошибочного функционирования программного комплек-
са с учетом задействования всех возможных маршрутов вычислений.
Рассмотрим следующий пример 1.
Пусть задан следующий стохастический граф, отображающий работу
программного комплекса из трех программных модулей (рис.1).
Для данного программного комплекса известны следующие его пара-
метры:
- коэффициенты сжатия времени отладки (тестирования) по сравнению
со временем вычислений К1  К 2  К 3  1 ;
- время вычислений программными модулями t1  1c; t2  7c; t3  10c ;
- первоначальное (предполагаемое) число ошибок в модулях N ошиб
1
 10;
2
N ошиб  5; N ошиб
3
 3;
-интенсивности проявления ошибки в модулях 1  0,01 1 / c; 2  0,02 1 / c;
3  0,03 1 / c ;

- вероятности перехода от одного модуля к другому

p01  1; p12  0,7; p13  0,3; p23  0,6; p24  0,4; p31  0,8; p34  0,2;
- вероятности безошибочной работы программных модулей вычислим
по формуле (1), полагая, что время отладки модуля с номером i  1, 2, 3 для
простоты вычислений равно нулю:
P1 (t1  1, 1  0)  e 0, 011  e 0,01  0,9901;

206
 207

P2 (t2  7, 2  0)  e 0,027  e 0,14  0,8694;

P3 ( t3  10, 2  0)  e 0,0310  e 0, 3  0,7408 .
Матрица G (t ) размерности 5  5 для данного примера имеет следующий
вид:

0 1 0 0 0  0 1 0 0 0 
   
0 0 p12 P1 p13 P1 0  0 0 0,69307 0,29703 0 
G (t )   0 0 0 p23 P2 p24 P2    0 0 0 0,52164 0,34776 .
   
0 p31P3 0 0 p34 P3   0 0,59264 0 0 0,14816 
0 0 0 0 0   0 0 0 0 0 


Построим вначале матрицу T 1  ( I  G (t )) :

1 1 0 0 0  1 1 0 0 0 
   
0 1  p12 P1  p13 P1 0  0 1  0,69307  0,29703 0 
T  0
1
0 1  p23 P2  
 p24 P2  0 0 1  0,52164  0,34776 .
   
 0  p31P3 0 1  p34 P3   0  0,59264 0 1  0,14816 
0 0 0 0 1   0 0 0 0 1 
 

Элемент матрицы T  ( I  G (t )) 1 с номером (0, 4) согласно формуле (3)

равен отношению алгебраического дополнения элемента (4, 0) матрицы
( I  G ( t )) и главного определителя этой матрицы. Раскрывая эти определители,
получим следующее выражение:

p12 P1 p23 P2 p34 P3  p12 P1 p24 P2  p13 P1 p34 P3

Y (t )  P(t ,0)  
1  p13 P1 p31P3  p12 P1 p23 P2 p31P3
0,7  0,9901  0,6  0,8694  0,2  0,7408  0,9901  0,4  0,8694  0,3  0,9901  0,2  0,7408
  0,56.
1  0,3  0,9901  0,8  0,7408  0,7  0,9901  0,6  0,8694  0,8  0,7408
(4)
Таким образом, для данного примера вероятность безошибочного ре-
шения задачи рассматриваемым программным комплексом равна 0,56, т.е.
чуть больше половины.

7.3. Постановка и модель решения обратной задачи

Рассмотрим теперь вторую, обратную задачу. Найдем минимальное

M 1
время отладки программного комплекса    i , при котором вероятность
i 0

безошибочного решения задачи P(t , )  Pзад . При этом будем предполагать,

207
 208

что вероятность безошибочного решения задачи можно определить по фор-

муле (1). Для нахождения решения воспользуемся методом неопределенных
множителей Лагранжа.
Функция Лагранжа для данного примера имеет следующий вид:
M 1
F ( t , ,  )  
i 0
i   ( P (t , )  Pзад ) , (5)
где  - множитель Лагранжа.
Дифференцируя выражение (5) по аргументам  i и  , получим сле-
дующую систему уравнений:
 F (t , ,  )
  0, i  0,1,2,, M  1;
  i (6)
 P(t , 1 , 2 ,, M ,  )  Pзад  0. .

M 1
Решив систему уравнений (6) относительно  i   i0 , получим  0   i0 .
i 0

Рассмотрим еще одну обратную задачу. Необходимо найти максималь-

ное значение вероятности безошибочного функционирования программного
комплекса при заданном времени его отладки. Для этого будем искать мак-
симум функции P(t , ) при заданном времени отладки  зад . Функция Лагранжа
в данном случае имеет следующий вид:
M 1
F (t , ,  )  P (t ,  )   (  i   зад ) . (7)
i 0

Дифференцируя выражение (7) по переменным  i , i  0,1,2,, M  1 и  и

приравняв их нулю, получим следующую систему уравнений:

 F (t , ,  )
   0, i  0,1,2,, M  1;
 M 1
i
(8)
  i   зад  0.
 i 0

Решив систему уравнений (8), можно найти искомые значения  i0 , а

подставляя их в выражение для P(t , ) , можно найти максимальное значение
вероятности безошибочного функционирования программного комплекса.
Рассмотрим следующий пример 2. Пусть задано значение вероятности
для программного комплекса Рзад  0,999 . Требуется найти времена отладок
каждого модуля и суммарное минимальное время отладки программного
комплекса.

208
 209

Поступая, как описано в п. «Обратная задача», находим

  3460 с;   1871 с;   848 с . Отсюда следует, что время отладки всего
0
1
0
2
0
3

программного комплекса равно   3460  1871  848  6179 с .

Рассмотрим следующий пример 3. Пусть задано время отладки про-
граммного комплекса  зад  6000 с . Требуется найти времена отладок каждого
модуля  i0 , i  1,2,3 и максимальное значение вероятности его безошибочного
функционирования при тех же данных задачи 1. В результате получим:
 1  3327 с;  2  1838 с;  3  835 с; max P (t , )  0,999 .
Приведенные числовые примеры иллюстрируют возможности исполь-
зования рассмотренных методов в решении прикладных задач, связанных с
анализом надежности программных комплексов и обеспечением требуемых
значений показателей их надежности при отладке.

ГЛАВА 8. ПРИМЕРЫ МАТЕМАТИЧЕСКИХ МОДЕЛЕЙ ДЛЯ

АСОИУ РАЗРАБАТЫВАЮЩЕГО ПРЕДПРИЯТИЯ
8.1. Классификация рассматриваемых моделей
Объектом автоматизации, для которого будут рассмотрены математиче-
ские модели для поиска оптимальных решений, является ОКБ, НИИ, опытный
завод. Такое предприятие часто называют разрабатывающим предприятием
(РП).
Конечной продукцией разрабатывающего предприятия является техни-
ческая документация, необходимая для изготовления образцов новой техни-
ки. Это изготовление может быть осуществлено либо на заводе, который
входит в состав РП, либо на специализированных заводах, относящихся к за-
водам с серийным или массовым характером производства.
Одна из специфических особенностей РП – выполнение ими как ОКР,
так и НИР. ОКР включаются в тематический план РП или директивно по
указанию вышестоящей организации, или по предложению самого предпри-
ятия.
Источниками возникновения предложений на ОКР, включаемые в тема-
тический план по предложению самого предприятия, являются другие РП
отрасли, серийные заводы, организации-потребители. Предложения на их
проведение могут поступать также от специалистов самого РП. В дальней-
шем такие ОКР, в отличие от директивных, будем называть инициативными.
НИР выполняются для того, чтобы можно было создавать новые образцы

209
 210

техники, которые превосходят или не хуже лучших уже созданных аналогич-

ных или подобных изделий.
Можно выделить следующие задачи управления РП, обеспечивающие его
эффективно функционирование:
- задачи стратегического планирования, определяющие будущее развитие
РП на период более пяти лет;
- задачи тактического планирования, определяющие работу РП на период
от года до пяти лет;
- задачи оперативного управления РП в текущем году, квартале, месяце,
как правило, ходом выполнения НИР и ОКР, включенным в годовой план ра-
боты РП.
Для оптимального решения этих задач в АСОИУ необходимо использо-
вать комплекс математических моделей, которые связаны между собой инфор-
мационно и функционально. Эта связь показана на рис. 8. 1..

Рис. 8.1.
8.2. Агрегированные модели распределения ресурсов РП между НИР и ОКР

8.2.1 Общая постановка задачи

ОКР включаются в тематический план РП или директивно по указанию

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

нем случае содержанием ОКР является модификация ранее разработанных

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

211
 212

мые темпы научно-технического прогресса РП, с другой – не будет непроиз-

водительного расходования ресурсов на НИР, что позволит в конечном итоге
ускорить проведение ОКР.
Эффект от проведения НИР обычно сказывается не непосредственно в
планируемом периоде, а спустя некоторый промежуток времени, определяе-
мый конкретными особенностями процесса выполнения НИР в ОКР на пред-
приятии. Поэтому решение поставленной задачи требует рассмотрения не
одного, а нескольких плановых периодов.
Значительная часть РП обладает следующими особенностями:
- большое число одновременно проводимых НИР и ОКР;
- конструктивно-технологическая однородность разрабатываемых изде-
лий;
- использование результатов НИР при выполнении нескольких ОКР;
- относительно небольшая продолжительность отдельных НИР (2-3 го-
да) и ОКР (до 5 лет);
- выполнение НИР и ОКР в одних и тех же конструкторских н экспери-
ментальных подразделениях предприятия.
Эти особенности позволяют, во-первых, рассматривать данную задачу на
агрегированном уровне в целом по РП без учета специфических особенностей
конкретных разработок, во-вторых, учитывать только один вид ресурсов, а не
вектор ресурсов, Е наконец, в-третьих, что очень важно, они позволяют огра-
ничиться при построении моделей только ресурсным аспектом, считая, что
непосредственное увеличение технического уровня разрабатываемых при вы-
полнении конкретных ОКР изделий авиационной техники происходит посто-
янно с некоторым темпом, определяемым требованиями заказчиков, особен-
ностями РП, качеством отбора и выполнения НИР и ОКР. Последнее обстоя-
тельство дает возможность в качестве критерия оптимальности при решении
данной задачи взять среднее количество ОКР, которые выполняются втечение
рассматриваемого планового интервала времени.

Рассмотрим две модели для решения поставленной задачи.

Лекция 5

8.2.2. Модель на основе введенной меры

научно-технического задела
Пусть для каждого интервала времени t планового периода Т на осно-

212
 213

вании статистического анализа результатов предшествующей деятельности

предприятия и прогнозных исследований определены количества директив-
ных ОКР Dt а также максимально возможные количества выполняемых
инициативных ОКР U t0 и НИР H t0 (t  1, T ) .
Известно количество ресурсов, идущих на проведение одной дирек-
тивной ОКР, имеющей задел rD и не имеющей задела rD .
Известны также соответствующие значения ресурсов ru и ru , необхо-
димых для выполнения инициативных ОКР. Очевидно, что rD  rD и ru  ru ,
т.е. научно-технический задел снижает количество ресурсов, требуемых для
выполнения ОКР.
Пусть известно также количество ресурсов rH , необходимое для вы-
полнения одной НИР.
Обозначим через Dt (U t ) количество директивных (инициативных)
ОКР, имеющих задел, а через Dt (U t) - соответственно, не имеющих задела.
Обозначим через Rt количество ресурсов, которыми располагает
предприятие в период t (t  1, T ) .
При принятых обозначениях задачу оптимизации структуры затрат
ресурсов РП можно сформулировать следующим образом.
Требуется при заданных ограничениях на ресурсы РП Rt (t  1, T ) вы-
брать в каждом плановом периоде t такое количество НИР H t , при котором
за время T было бы выполнено максимально возможное количество ОКР.
При этом уровень научно—технического задела на начало следующего (Т
+1)-го планового периода должен быть бы не ниже некоторого заданного
уровня.
Математическая постановка задачи имеет следующий вид:
T
W  max
H 1 , H 2 ,..., H t
 (D
t 1
t Ut ) (1)
при следующих ограничениях:
Dt/ rD/  Dt// rD//  U t/ rU/  U t// rU//  rH H t  Rt ;
U t  U t/  U t//  U t0 ; Dt/  Dt//  Dt ; H t  H t0 ; (2)
Z 1  A; Z T 1  B; t  1, T ,
где Z1 и ZT+1 - уровни научно-технического задела, имеющиеся на предпри-
ятии, на начало и на конец планового горизонта соответственно.
В качестве количественной меры научно—технического задела,
имеющегося на предприятии по данному техническому направлению к нача-
лу t-го планового периода, используем величину Pt (0  Pt  1) , представляю-
щую собой вероятность того, что случайно выбранная ОКР из числа дирек-

213
 214

тивных Dt или инициативных U t имеет научно—технический задел.

При большом количестве одновременно выполняемых ОКР эту вели-
чину можно интерпретировать как долю директивных или инициативных
ОКР t -го планового периода, для которых ранее были выполнены соответст-
вующие НИР.
Отражая свойства научно-технического задела, величина Рtзависит от:
- уровня задела к началу (t -1)-го периода;
- является возрастающей функцией количества ресурсов, выделенных в
( t - 1)-м плановом периоде на НИР;
- является убывающей функцией времени ввиду морального старения
неиспользованного задела;
- является убывающей функцией количества выполненных ОКР в (t-1)-
м периоде с заделом.
Представим величину Ptследующим образом:

0, если t< 0,
Pt = t, если 0 t 1, (3)
1, если t> 1,
где  t  Pt 1     (U t/1  Dt/1 )  H t 1 ,
 - величина, характеризующая старение научно-технического задела за
один плановый период;
 - коэффициент, отражающий эффект расходования научно-технического
задела при выполнении одной ОКР;
- коэффициент, отражающий средний вклад одной НИР в создание науч-
но-технического задела.
Пусть на начале t - го планового периода создан задел, ха-
рактеризующийся величиной Pt, и, значит, для выполнения директивных
ОКР в этом периоде потребуется среднее количество ресурса, равное
Dt ( Pt rD/  (1  Pt ) rD// ) .
Будем считать, что директивные ОКР всегда можно выполнить даже при
полном отсутствии научно-технического задела. Тогда, возможно, еще оста-
нется неиспользованной часть ресурса Rt , которую можно направить или на
инициативные ОКР, или на НИР, или на те и другие вместе. Пусть в период
tвыполняются НИР в количестве H t (0  H t  H t0 ) и, значит, остается неисполь-
зованным количество ресурса t:
 t  Rt  Dt ( Pt rD/  (1  Pt ) rD// )  rH H t . (4)
214
 215

Это количество ресурсов можно израсходовать на инициативные ОКР,

среднее количество которых в период t будет равно:
 PtU t0 , если  t  PtU t0 rU/ ;

U t/    t ( 5 )
, если  t  PtU t0 rU/ ;
 rU/


 0 , если  t  PtU t0 rU/ ;


U t   t  PtU t0 rU/
//

 , если  t  PtU t0 rU/ . (5 )
 rU//

На конец t -го периода, или, что то же самое, на начало t + 1-го перио-

да будет создан при этом научно-технический задел, измеряемый величиной
Pt 1 , определяемый следующей формулой:
Pt 1  Pt     (U t/  Pt Dt )  H t . (6)
Так как no сделанному выше предположению директивные темы всегда
выполняются, то, с учетом формул (3) - (6) задачу (1) - (2) можносформулиро-
вать следующим образом:
W  max  (U /t  U //t ) (7)
H1 , H 2 ,...,H t

при условиях (4), (5), (6) и

U t/  U t//  U t0 ; H t  H t0 ; P1  P НАЧ ; PT 1  P KOH . (8)
Для решения задачи (7) при условиях (4), (5), (6), (8) выведем необхо-
димое рекуррентное соотношение.
Перенумеруем интервалы времени в обратном порядке, т.е. конечный ин-
тервал T получит номер 1, а начальный - номер T .
Обозначим через f j ( Pj ) максимально возможное (оптимальное) количест-
во директивных и инициативных ОКР, включенных в план с j-го до 1-го (в
новой нумерации) периода при условии, что на начало j-го периода уровень
научно-технического задела равен Pj .
Для j=1 функция f1 ( P1 ) имеет вид:
 
f 1 ( P1 )  max 0 D1  U 1/ ( P1 , H 1 )  U 1// ( P1 , H 1 ) ,
0  H1  H1
(9)
где U 1/ ( P1 , H 1 ) и U 1// ( P1 , H 1 ) определяются формулами (5) и (5) .
Taк как уровень задела на конец 1-го периода известен и равен
P0  P KOH , то при построении функции f1 ( P1 ) , варьируя H1, надо проверять вы-
полнимость неравенства
P1     (U 1/ ( P1 , H 1 )  PD1 )  H 1  P KOH . (10)
215
 216

Это неравенство ограничивает снизу величину Н 1 .

Пусть функция f 1 ( P 1 ) построена. Найдем выражение для величины
f 2 ( P2 ) , т.е. максимальное количество ОКР, которое можно выполнить за два
периода, считая от конца планового горизонта, при уровне задела на начало
2-го периода, равном P2 :
f 2 ( P2 )  max 0 D2  U 2/ ( P2 , H 2 )  U 2// ( P2 , H 2 )  D1  U 1/ ( P1 , H 1 )  U 1// ( P1 , H 1 ), (11)
0 H1  H 1
0 H 2  H 20

причем между величинами P2 и P1 существует следующая связь:

P1 ( P2 , H 2 )  P2     (U 2/ ( P2 , H 2 )  P2 D2 )  H 2 . (12)
В выражении (11) с ростом H 2 первая группа слагаемых уменьшается, а
вторая - увеличивается. С уменьшением Н2происходит обратное явление.
Нетрудно заметить, что выражение (11) можно переписать следующим
образом:
f 2 ( P2 )  max D2  U 2/ ( P2 , H 2 )  U 2// ( P2 , H 2 )  f1 ( P1 ( P2 , H 2 )), (13)
0 H 2  H 20

где функция P1 ( P2 , H 2 ) определяется выражением (12).

Рассуждая аналогично, можно построить следующие рекуррентные
формулы для решения поставленной задачи:
 
f j ( Pj )  max 0 D j  U /j ( Pj , H j )  U //j ( Pj , H j )  f j 1 ( Pj 1 ( Pj , H j )) ,
0 H j  H j
(14)

Pj 1 ( Pj , H j )  Pj     (U /j ( Pj , H j )  Pj D j )  H j . (15)

Пусть для всех j  1,2,  , T построены функции f j ( Pj ) , причем наряду

с построением этих функций строятся и функции H *j ( Pj ) , т.е. фиксируются те
количества НИР в каждом плановом периоде, при которых достигается мак-
симум выражения (14).
Оптимальные пропорции между затратами ресурсов на НИР и ОКР
могут быть теперь определены следующим образом.
По известной величине РНАЧ — уровню задела на начало рас-
сматриваемого планового горизонта в таблице функций H t* (t  1, T ) находим
оптимальное значение числа НИР, выполняемых в первом (возвращаясь
опять к исходной нумерации периодов) периоде H 1 .
Умножив эту величину на rH , находим средние затраты на НИР в этом
периоде. Остальные ( R1  H 1r1 ) ресурсы идут на ОКР, причем
216
 217

D1 ( P1 rD/  (1  P1 )rD// ) ресурса расходуется на

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

8.2.3. Модель на основе временной зависимости затрат ресурсов на НИР и

ОКР

Пусть в период tв подразделении выполняются НИР в объеме H t rt H , где

Ht - число выполняемых НИР, rt H - средние затраты на одну НИР. Тогда на
ОКР в этом же периоде остается Rt  H t rt H ресурсов, где Rt – ресурсы подраз-
деления в период t. Если rt 0 - средние затраты на одну ОКР в единицу време-
ни, то в период t в подразделении могут выполняться работы в среднем по
Rt  H t rt H
ОКР.
rto
Если в одном и том же подразделении предприятия выполняются и
НИР и ОКР, то, очевидно, что чем больше было затрачено ресурсов на отра-
ботку макетных и экспериментальных образцов в процессе НИР, тем меньше
потребуется ресурсов на отработку опытных образцов при выполнении ОКР.
Это влияние НИР на ОКР может проявляться, вообще говоря, не сразу, а
спустя некоторый период, определяемый продолжительностью выполнения
соответствующих этапов ОКР в других подразделениях - соисполнителях
этих ОКР.
Таким образом, величина rt 0 есть некоторая функция затрат ресурсов, вы-
деленных на НИР k периодов назад, т.е.
rt 0  f t  k 1 ( H t  k 1 rt H k 1 ). (1)
Исходя из характера принимаемого во внимание влияния НИР на ОКР,
можно предположить, что эта функция представляет собой перевернутую S-
образную кривую. С достаточной для практики точностью можно аппрокси-
мировать эту функцию перевернутой логистической кривой (рис. 8.2).

217
 218

Рис. 8.2.
Считая, что число выполняемых в каждом периоде НИР известно (оно
обычно мало меняется от периода к периоду), задачу распределения ресурсов
между НИР и ОКР можно теперь сформулировать следующим образом:
T
Rt  H t rt H
W max
H 1r1H ,..., H T rTH

t 1 f t  k 1 ( H t  k 1 rt H k 1 )
; (2)
0  H t rt H  Rt , t  1, T (3)
1
0
r  f  k 1 ( H r )  B1 ;...; r  f  k ( H r )  Bk 1 ;
H
 k  R 1 k 1
0
(4)
k 1
H
1 1

rT 1  1 ;...; rT  k 1   k 1 .
0 0
(5)
Максимизируемый функционал (2) представляет собой среднее коли-
чество ОКР, выполненных за Т периодов, где Т- рассматриваемый плановый
горизонт. В качестве управляемых переменных выступают затраты на НИР
H t rt H в периоды t=1,2, ..., Т. Условие (3) означает, что в любой период
tсуммарные затраты на НИР не могут превзойти ресурсные возможности
подразделения. Условие (4) означает, что известны затраты ресурсов на НИР
в периоды, отстоящие от исходного (t=l) на 1,2,..., (k+1) интервалов времени
назад. Наконец, условие (5) означает, что известны средние затраты ресурсов
на одну ОКР в периоды T+1, Т+2, T+k+1. Знание их необходимо для того,
чтобы ограничить нижний предел величины НtrtHдля t= T-k, ..., T. Из (2) не-
посредственно следует, что при отсутствии условий (5) значения НtrtHдля t
=T-k, …, Т, оптимизирующие (2), равны 0, т.е. в эти периоды не будут совсем
проводиться НИР.
Для заданного планового горизонта можно произвольно выбирать значения

218
 219

НtrtH только для первых ( Т - k - 1) периодов, так как значения НtrtHдля осталь-
ных ( k+1) периодов определены условиями (5). Эти НtrtHизменяют значения
средних затрат на одну ОКР для последних (T - k - 1) периодов, так как значе-
ния средних затрат на одну ОКР для первых ( k+1) периодов определены усло-
виями (4). Поэтому задача (2)-(5) имеет нетривиальное решение только для Т
>k+1.
При построении рекуррентного соотношения используем метод математиче-
ской индукции. Для этого обозначим через  t (rt01 ,..., rt0 k 1 ) максимально возмож-
ное среднее количество ОКР, которое можно выполнить за tпериодов при ус-
ловии, что в (t+ l), (t+ 2), …, (t + k+ 1) периодах будет создан научно-
технический задел, обеспечивающий возможность выполнения ОКР в эти пе-
риоды со средними затратами ресурсов, соответственно равными rt01 ,..., rt0 k 1 .
Очевидно, что для t=k+1 функция  t (rt01 ,..., rt0 k 1 ) определяется следующим
образом:
R1   1 (rk0 2 ) R2   2 (rk03 ) R   k 1 (r20k  2 )
 k 1 (rk0 2 ,..., r20k  2 )    ...  k 1 , (6)
B1 B2 Bk 1
где k+1(…) - функция, обратная (1).
Для t=k+2 эта функция имеет вид
 R1  H1r1H R2   2 ( rk03 ) R   k 1 ( r20k 2 )
 k 2 ( rk03 ,..., r20k 3 )  max    ...  k 1 
0 H r  R11
H
1
 B1 B 2 Bk 1

Rk  2   k  2 (r20k 3 ) 
 . (7)
f1 ( H1r1H ) 
Сравнивая выражения (6) и (7), замечаем, что в них второе, третье и т.д.
до (k+1)-го слагаемые совпадают. Если в (6) положить rk0 2  f 1 ( H 1r1H ) , то и
первые слагаемые в (6) и (7) совпадут, так как  1 (rk  2  f 1 ( H 1 r1H ))  H 1 .
Отсюда следует, что
 Rk  2   k  2 (r20k  3 ) 
 k  2 (r ,..., r
0
k 3
0
2k 3 )  max  k 1 (rk  2  f 1 ( H 1 r1 ), rk  3 ,..., r2 k  2 )
H 0 0
.
0 H 1r1H  R1 
 f 1 ( H 1 r1H ) 
(8)
Рассуждая аналогично, по методу математической индукции можно дока-
зать, что для любого t (k+1<t Т) справедливо следующее рекуррентное со-
отношение:
 Rt   t ( rt0 k 1 ) 
 t ( rt01 ,..., rt0 k 1 )  max  t 1 ( rt0  f t k 1 ( H t k 1rt Hk 1 ), rt01 ,..., rt0 k )  (9)
H
0 H t  k 1rt  k 1  Rt  k 1
 f t k 1 ( H t k 1rt Hk 1 ) 
Задачу (2) - (5) можно решить теперь следующим образом. Используя
формулу (6), вычисляем функции  k 1 (rk0 2 ,..., r20k  2 ) для всех значений

219
 220

0
rmin  rk01 j  rmax
0
, j  1,..., k  1 , определенных с заданной дискретностью. После
этого, используя формулу (8), а затем последовательно формулу (9), вычисля-
ем значения функций  t (rt01 ,..., rt0 k 1 ) , полагая t=k+2,…,T-1,T. Для каждого на-
^ ^H
бора переменных (r ,..., r ) фиксируем значение H t k 1 r t  k 1 , прикотором
0
t 1
0
t  k 1

достигается максимум в выражении (9). Полагая в функции  T (rT01 ,..., rT0 k 1 )

значения переменных равными соответственно 1 ,..., k 1 , находим решение за-
~ ~H
дачи (2) - (5) и искомое значение H T  k 1 r t  k 1 , при котором достигается мак-
~0 ~ ~H
симум выражения (9). После этого вычисляем значение r T  f T  k 1 ( H t  k 1 r t  k 1 ) .
^0
По набору переменных (r T , 1 ,...,  k ) в таблице, определяющей функцию
~ ~H
 T 1 ( r ,..., r ) , находим соответствующее значение H T k  2 r t k 2 . Затем вычис-
T
0 0
T k
~0 ~ ~H
ляем r T 1  f T  k  2 ( H t  k  2 r t  k  2 ) и в таблице, определяющей функцию
~ ~H
 T  2 ( rT01 ,..., rT0 k 1 ) , находим соответствующее значение H T  k 2 r T k  2 , и т.д. до тех
~
пор, пока не дойдем до  k 2 (...) и не получим значение H r . 1 1
H

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

~ ~ ~ ~
H 1 r1H ,..., H T k 1 rTHk 1 для первых (T-k-1) периодов. Остальные значения
~
H T  k 1 j , j  1, k  1 вычисляются путем решения уравнений
~ ~H
H T  k 1 j r T  k 1 j   j ( j ), j  1, k  1 , где j определяются условием (5).

8.3. Модели этапа исходного планирования разработок

8.3.1. Модель оценки технического уровня предстоящей разработки

Технический уровень изделия – это относительная характеристика ка-

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

220
 221

Перечень таких параметров, как правило, устанавливает разработчик

изделия, возможно совестно с другими заинтересованными организациями.
При этом, очевидно, каждый параметр следует выбирать таким образом, что-
бы с его увеличением значение критерия увеличивалось бы.
Всю совокупность выбранных параметров рассматриваемого изделия
представим в виде вектора
Yu   y1u , y 2 u ,  , y nu  ,
T
(1)
где yiu - значения параметра i, (i  1, n ) для изделия u .
Составим следующую матрицу значений параметров группы из m ана-
логичных изделий, которая характеризует достигнутый отечественный или
мировой уровень аналогичных изделий:

 y11 y12  y1m 

 
y y 22  y2m 
Y   21 . (2)
   
 
 y n1 yn 2  y nm 
Переходя к лучшим значениям параметров в выражении (2), получим
вектор
Y 0   y10 , y 20 ,  , y n0  ,
T
(3)
где yi0  maxyij , i  1, n .
j 1,m

Вектор Y0 характеризует технический уровень некоторого идеального,

эталонного изделия.
Обобщенный показатель технического уровня исследуемого изделия
K TY можно теперь определить следующим образом:
u

n
yiu  yi0
u
K TY   ai , (4)
i 1 i
где:
 i - предельное отклонение i -го параметра, т.е. разность между наи-
большим и наименьшим значениями i -го параметра, взятыми по всей сово-
купности параметров изделий, включая и рассматриваемое изделие. Если
yiu  y i0
y iu  yi0  0,  i  0 , то  0;
i
ai - весовой коэффициент, отражающий неравнозначность вклада от-
дельных параметров в оценку технического уровня изделия. Полагают, что
n

a
i 1
i  1.

Если подсчитанный по формуле (4) показатель K TYu  0 , то это означает,

221
 222

что технический уровень оцениваемого изделия выше технического уровня

аналогичных изделий взятых для сравнения. Если же KTYu  0 , то это означает,
что технический уровень оцениваемого изделия ниже технического уровня
аналогов.

В формуле (4) неизвестными являются численные значения весовых

коэффициентов ai , i  1, n .
Для их определения может быть применен метод парных сравнений.
Его сущность состоит в том, что каждому эксперту, выбранному для опреде-
ления важности отдельных показателей в итоговой оценке технического
уровня изделия, предлагается сравнивать относительную важность пар раз-
личных параметров. Для этого составляют квадратные матрицы парных
сравнений, в которых все параметры записываются в одном и том же порядке
дважды: в верхней строке и в крайнем левом столбце каждой матрицы. В
клетках на пересечении i  й строки и j -го столбца (i, j  1, n ) каждый эксперт
проставляет числа x ij по следующим правилам:
 1, если параметр i , более предпочтителен, чем параметр j;

xij  0,5, если оба параметра i и j равноценны;

 0, если параметр j более предпочтителен, чем параметр i.

Каждая пара параметров может сравниваться дважды или только один

раз. Последний вариант встречается на практике, поэтому его и рассмотрим.
Он предполагает, что справедливо следующее очевидное равенство:
xij  x ji  1 .
Полученную от эксперта с номером l , l  1, L матрицу парных сравне-
ний обозначим X l  xijl .
Значения весовых коэффициентов ail , i  1, n параметров в формуле (4)
для эксперта с номером l найдем на основе обработки полученной матрицы
X l  xijl , воспользовавшись решением так называемой задачи о лидере.
Обозначим Atl  ( a1lt , a 2l t ,  , a ntl ) вектор весовых коэффициентов парамет-
ров для эксперта с номером l , полученный на шаге вычислений t  1,2, .
Для вычисления компонент этого вектора воспользуемся следующей
формулой:
1
Atl  X l  Atl1 , (5)
 l
t

222
 223

где величина lt определяется по следующей формуле:

n n
lt   xijl  ail( t 1) . (6)
i 1 j 1

На первом шаге вычислений полагают все элементы вектора A0l равны-

ми единице.
По определению, матрица X l  xijl неотрицательная. Поэтому согласно
теореме Перрона – Фробениуса при стремлении числа шагов вычислений t к
бесконечности, величина lt стремится к собственному числу l0 матрицы X l ,
а вектор весовых коэффициентов Atl  ( a1lt , a 2l t ,  , a ntl ) стремится к собственному
вектору этой матрицы, соответствующему максимальному собственному
числу l0 , т.е. можно записать:
n
Al  lim Atl ,
t 
a
i 1
l
i  1, (7)
где Al  a1l , a 2l ,  , a nl  .
Таким образом, последовательно применяя формулы (5) и (6), находим
L векторов A1 , A2 ,  , AL , компонентами которых являются весовые коэффи-
циенты параметров в формуле (4).
Необходимо теперь установить степень согласованности мнений экспертов относи-
тельно полученных значений компонент векторов A1 , A2 , , AL .
Одним из возможных подходов для определения степени согласованности мнений
экспертов является подход, основанный на использовании метода ранговой корреляции и
вычислении так называемого коэффициента конкордации W.
Для его вычисления перейдем от значений коэффициентов относительной важности
a1 , a2 ,  , a nl  к рангам этих критериев ril . При этом ранг, равный единице, присваивается
l l

параметру, у которого соответствующий ему весовой коэффициент наибольший. Ранги

1,2,  , n присваиваются параметрам по мере уменьшения их весовых коэффициентов. Ранг
n присваивается параметру, имеющему наименьший весовой коэффициент.
Коэффициент конкордации Wрассчитывается по следующей формуле, которую
предложил Кендалл:
12  S
W  , (8)
L (n 3  n)
2

где
n L
S   (  ri l  A) 2 , (9)
i 1 l 1
n L
1
A   ril ;
n i 1 l 1
(10)
L – количество экспертов,
n – количество локальных критериев,

223
 224

ril - ранг локального критерия с номером i (i  1,2,  , n ) согласно мнению эксперта с

номером l (l  1,2,  L ) .
Коэффициент конкордации W меняется от 0 до 1, причем, если он равен 1, то оценки
всех экспертов полностью совпадают; если же он равен 0, то связь между оценками отсут-
ствует.
Если W  0.2 , то согласованность оценивается как низкая; если 0.2  W  0.3 -
удовлетворительная и , если W  0.3 - высокая.
Низкий коэффициент согласованности указывает либо на неудачный выбор ранжи-
руемых факторов, либо на то, что мнения экспертов по данному вопросу резко расходятся.
В этом случае необходимо провести новый экспертный опрос, возможно изменив состав
экспертов.
Если гипотеза о согласии экспертов принимается, то вычисляются обобщенные ито-
говые значения весовых коэффициентов относительной важности параметров.
Вначале находим вектор A  (a1 , a2 ,, an ) усредненных по всем экспер-
там значений весовых коэффициентов параметров в формуле (4).
Величины ai , i  1, n можно вычислить по следующим формулам:
L

a l
i
ai  l 1
, i  1, n . (11)
L
Формулы (11) предполагает, что все эксперты по своему уровню рав-
ноценны, т.е. их мнения равнозначны. Если это не так, т.е. среди экспертов
есть специалисты различной квалификации, то вместо формул (11) более це-
лесообразно применить формулы
L

 a l
l
i
ai  l 1
, i  1, n , (12)
L
где  l - коэффициент, отражающий степень подготовленности эксперта с но-
L
мером l , (l  1, L) , причем 
l 1
l  1. Для определения значений коэффициентов
 l , (l  1, L ) можно применить методику, изложенную выше.
Полученные по формулам (11) или (12) весовые коэффициенты не от-
n
вечают условию нормировки, так как в общем случае a
i 1
i  1. Поэтому для
получения условия нормировки следует перейти от вектора A к требуемому
вектору параметров A  (a1 , a2 , , an ) , вычислив значения компонент этого
вектора по формулам:
ai
ai  n
, i  1, n . (13)
a
i 1
i

224
 225

Лекция 6

8.3.2. Модель распределения ресурсов по этапам выполнения

разработки

Пусть в результате предварительного исследования технической сущ-

ности предстоящей разработки определены основные этапы ее выполнения,
число которых обозначим N .
Нормативную продолжительность выполнения каждого n  го этапа
( n  1, N ) обозначим a n .
За счет привлечения дополнительных ресурсов продолжительность
этапа a n может быть уменьшена на величину не более чем An , причем, оче-
видно, 0  An  an .
Если нормативная продолжительность этапа a n уменьшена на величи-
ну zn (0  zn  An ) , то его стоимость увеличивается на величину Cn ( zn ) , где
Cn ( zn ) - известная возрастающая функция аргумента. Таким образом, стои-
мость выполнения n  го этапа ( n  1, N ) равна C n0  C n ( z n ) , где Cn0 - стоимость
этапа при его нормативной продолжительности a n .
Превышение заданного срока выполнения разработки на величину x
может привести к экономическим санкциям в виде штрафа в размере P ( x ) .
Одновременно, досрочное выполнение разработки может быть связано
с сокращением продолжительности выполнения отдельных этапов и, значит,
их удорожанием, а, кроме того, может привести к экономическим потерям
из-за необходимости хранения готовой продукции на складе, отвлечения раз-
работчиков от выполнения других разработок и т.п. Эти потери обозначим
K (x ) , где x - время «пролеживания» результатов выполнения разработки.
Исходя из сказанного, ожидаемая стоимость выполнения разработки R
может быть определена следующим образом:
N
R (t , z1 , z 2 ,  , z N )   (C n0  C n ( z n ))   ( t , z1 , z 2 ,  , z N ) , (1)
n 1

 K ( x ), x  0;

где  (t , z1 , z 2 ,  , z N )   0, x  0;
 P ( x ), x  0,


225
 226

N
x  t   (an  zn ) - величина запаздывания или опережения заданного срока
n 1

выполнения разработки;
t - интервал времени между началом выполнения разработки и требуемым
(директивным) сроком ее завершения.
Задача состоит в том, чтобы при заданном t найти такие значения ве-
личин z1 , z2 , , z N , которые минимизировали бы ожидаемую стоимость вы-
полнения разработки.
Решение поставленной задачи можно найти, построив динамическую
оптимизационную модель.
Занумеруем все этапы разработки в обратном порядке, так что номер
N получит первый этап, номер ( N  1) - второй этап и т.д.
Пусть после завершения (n  1) -го этапа осталось t единиц времени до
установленного срока окончания разработки. Тогда величина
t  (a1  a2    an ) - это время, которое можно потратить на устранение раз-
личного рода задержек в выполнении оставшихся этапов. Обозначим эту ве-
личину x n .
Перед началом выполнения n -го этапа величина x n может быть увели-
чена на 0  zn  An , а в процессе выполнения за счет различных случайных
факторов уменьшена в среднем на величину d n . Поэтому соотношение меж-
ду величинами x n и xn1 может быть записано в следующем виде:
x n 1  xn  z n  d n , n  1, N . (2)
Очевидно, что при этих обозначениях величина x 0 равна неиспользо-
ванному резерву времени, если x0  0 , и нарушению срока выполнения разра-
ботки, если x0  0 .
Предположим, что осталось выполнить самый последний этап с номе-
ром 1 и пусть:
- x - величина резерва времени (возможно, и отрицательного);
- a1 - нормальная продолжительность выполнения этого этапа;
- d1 - величина, на которую в среднем удлиняется продолжительность
этапа за счет случайных факторов;
- z1 - выбираемая величина, на которую сокращается продолжитель-
ность выполнения этапа.
При этих обозначениях величина запаздывания или опережения задан-
ного срока выполнения разработки x 0 определяется, согласно формуле (2)
следующим образом:
226
 227

x0  x  a1  d1  z1 .
Найдем минимальные дополнительные затраты на выполнение данного
этапа при известном значении величины x . Они определяются величиной z1
и тем, какого значения при заданных величинах x, a1 , d1 достигла величина x 0 .
Эти затраты можно вычислить по следующей формуле:
f 1 ( x )  min C1 ( z1 )   ( x0 ) , (3)
0 Z1  A1

 P ( x0 ), x0  0,

где  ( x0 )   0, x0  0,
 K ( x ), x 0  0.

В фигурных скобках выражения (3) первое слагаемое – это затраты на
сокращение продолжительности выполнения этапа на величину z1 , причем
0  z1  A1 , где A1 - максимально возможное сокращение продолжительности
выполнения этого этапа. Второе слагаемое в фигурных скобках выражения
(3) – возможные потери за счет запаздывания срока выполнения разработки,
если x0  0 , или за счет слишком раннего ее окончания, если x0  0 .
Пусть теперь осталось выполнить два последних этапа, т.е. первый и
второй, причем перед их выполнением имеется резерв времени x , возможно,
и отрицательный. В этом случае величина запаздывания определяется сле-
дующим выражением:
x0  x  a2  d 2  z2  a1  d1  z1 . (4)

Найдем минимальные дополнительные затраты на выполнение этих

двух этапов при известном значении x . Они определяются следующей оче-
видной формулой:
f 2 ( x )  min C1 ( z1 )  C2 ( z 2 )   ( x0 ). (5)
0 Z  A 1 1
0 Z 2  A2

В выражении (5) величина x 0 вычисляется уже по формуле (4).

Перепишем выражение (5) в следующем виде:
f 2 ( x )  min C1 ( z1 )  C2 ( z 2 )   ( x0  x  a 2  d 2  z 2  a1  d1  z1 ) 
0 Z1  A1

 
0 Z 2  A2

 min C2 ( z2 )  min C1 ( z1 )   ( x  a 2  d 2  z 2  a1  d1  z1 )  (6)

 min C ( z )  min C ( z )   ( y  a  d  z ),
0 Z 2  A2 0 Z1  A1

2 2 1 1 1 1 1
0 Z 2  A2 0 Z1  A1

где y  x  a 2  d 2  z 2 .
Из выражений (6) и (3) следует, что выражение (6) можно записать в
следующем образом:
f 2 ( x )  min C 2 ( z 2 )  f 1 ( x  a 2  d 2  z 2 ). (7)
0 Z 2  A2

227
 228

Рассуждая аналогично, можно получить следующее выражение для

минимальных дополнительных затрат на выполнение трех, четырех и т.д.
этапов при условии, что перед началом их выполнения имеется положитель-
ный или отрицательный резерв времени x :
f n ( x )  min C n ( z n )  f n 1 ( x  a n  d n  z n ). (8)
0 Z n  An

При построении рекуррентных функций (8) для n  1,2,  , N необходи-

мо фиксировать для каждого значения x то значение z n* ( x ), n  1, N , при кото-
ром функционал, стоящий в фигурных скобках в выражении (8), достигает
минимального значения. Полученные по рекуррентным формулам (8) функ-
ции f n (x) и z n* ( x ), n  1, N позволяют получить решение поставленной задачи
определения значений z1* , z 2* ,  , z *N , которые минимизируют ожидаемые затра-
ты на выполнение разработки при заданной директивной продолжительности
ее выполнения t .

8.3.3. Сетевые модели выполнения разработок

Одним из широко известных в свое время моделей хода выполнения

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

228
 229

Рис. 8.3. Фрагмент сетевого графика изготовления агрегата А некото-

рого изделия

8.4. Модели формирования тематического плана РП

8.4.1. Общая постановка задачи формирования тематического плана

Пусть к началу формирования тематического плана предприятия для

всех разработок, предполагаемых к выполнению в планируемом периоде,
выполнен этан исходного планирования. Это означает, что для каждой разра-
ботки получена оценка технического уровня разрабатываемого изделия или
какая-либо другая количественная оценка, отражающая ее вклад в достиже-
ние целей РП, Определены также нормативные (планируемые) затраты ре-
сурсов по каждому этапу выполнения разработки, их предварительные (же-
лательные) сроки завершения, а также принадлежность разработки к той или
иной приоритетной группе. Кроме того, известны ресурсы основных подраз-
делений РП, которыми оно располагает в каждом планируемом периоде рас-
сматриваемого планового горизонта. В этих условиях задача формирования
тематического плана РП формулируется как задача нахождения таких сроков
выполнения разработок, чтобы за рассматриваемый плановый горизонт, с
одной стороны, максимизировать суммарную ценность включенных в тема-
тический план работ, а с другой - обеспечить наиболее полную загрузку всех
основных подразделений РП.
Для ее формализации введем следующие обозначения: xijt- переменная,
равная 1, если в период t, t=1, T , длявыполнения выбран j-й вариант i-й разра-
ботки (НИР или ОКР), и равная 0 в противном случае; Cijt- количественная
оценка (важность) j-го варианта i-й разработки (например, оценка техниче-
ского уровня) при условии начала ее выполнения в период t; N- число рас-

229
 230

сматриваемых разработок; ni-число альтернативных вариантов i-и разработ-

ки; Т- плановый горизонт, на котором решается задача определения сроков
начала выполнения рассматриваемых работ. Будем считать, что продолжи-
тельности выполнения всех вариантов выполнения разработок одинаковы и
равны , где   max  ij ;  ij - продолжительность выполнения j-го варианта i-й
i, j

разработки. Заметим, что в постановке задачи количественная оценка ценно-

сти j-го варианта i-й разработки зависит от времени начала его выполнения.
Пусть, наконец, rijk- количество ресурсов k- говида (k=1, K ), необходимое в 
-й (   1,  ) период выполнения j-го варианта i-й разработки.
В условиях РП перегрузку одних подразделений в ряде случаев можно
устранить путем передачи части запланированных им работ другим родст-
венным подразделениям.
Пусть A   lkt - квадратная матрица, элемент которой  lkt равен 1, если ре-
сурс l-го подразделения РП может быть использован в период tдля возмеще-
ния дефицита ресурса в k-м подразделении, и равен 0 в противном случае.
Обозначим через Yklt количество ресурсов k-го подразделения, которое мо-
жет быть передано в l-е подразделение в период t, а через Yklt- количество
ресурса l-го подразделения, идущее на покрытие дефицита ресурса в k-м
подразделении. Тогда в t-й период имеющийся ресурс k-го подразделения
K K
может быть увеличен на   lkt y lkt и уменьшен на величину
i 1

i 1
klt y klt , т.е. мо-
K K
жет составлять R kt  R kt    lkt y lkt    klt y klt , где Rkt- имеющиеся производст-
l 1 l 1

венные возможности k-го подразделения в период t; К - число подразделений

разрабатывающего предприятия.
Из k-го подразделения в l-е подразделение могут быть переданы не все
ресурсы этого k-го подразделения, а только некоторая часть. Поэтому
yklt  Bklt , где Bklt  Rkt -максимально возможное количество ресурса k-го под-
разделения, которое может быть передано в l-е подразделение.
Задачу формирования тематического плана можно теперь формализовать
следующим образом (с учетом вышесказанного):
N ni T

 x
i 1 j 1 t 1
ijt C ijt  max (1)
при ограничениях по ресурсным возможностям К подразделений РП в пе-
риоды t=1,2, ..., Т:

230
 231

для первого планового периода:

N ni K K

  xijl rijkl  Rkl   lkt ylkt   klt y klt , k  1, K ;

i 1 j 1 l 1 l 1
(2)

для второго периода с учетом затрат ресурсов на отобранные в этом вто-

ром периоде разработки, а также ресурсы, необходимые на выполнение тех
разработок, которые были отобраны на предыдущем, т.е. первом периоде,
N ni K K

  ( xij 2 rijk1  xij1rijk 2 )  Rk 2   l 2 ylk 2    l 2 y kl 2 , k  1, K ;

i 1 j 1 l 1 l 1
(3)

Для третьего планового периода с учетом затрат ресурсов на отобранные

в этом уже третьем периоде разработки, а также ресурсы, необходимые на
выполнение разработок, отобранных на предыдущих, т.е. первом и втором
периодах,
N n3 K K

 ( xij 3 rijk1  xij 2 rijk 2  xij1rijk 3 )  Rk 3  lk 3 ylk 3   kl 3 y kl 3 , k  1, K ;

i 1 j 1 l 1 l 3
(4)

для (-1)-го периода с учетом аналогичных рассуждений

N n3 K K

 ( xij1rijk 1  xij2 rijk 2  ...  xij1rijk1 )  Rk1  lk1 ylk1   kl1 y kl1 , k  1, K ;
i 1 j 1 l 1 l 3

(4.3.5)
для периода t=,…,Т
N n3 K K

 ( x
i 1 j 1
r
ijt ijk 1  xijt 1 rijk 2  ...  x ijt   1 rijk )  Rkt    lkt y lkt    kt y klt , k  1, K ;
l 1
(6)

Полученную систему неравенств необходимо еще дополнить следующими

неравенствами:
y klt  Bklt ; k  1, k ; l  1, K ; t=1,T. (7)
Система (7) отражает тот факт, что количество ресурсов, передаваемых
из k-го подразделения в l-е, ограничено некоторым заданным значением.
Кроме того, следует ввести систему неравенств, отражающих необходи-
мость выполнения только одного варианта разработки, причем этот вариант
может быть начат только один раз. Это условие записывается следующим
образом:
T ni

 x
t 1 j 1
ijt  1, i  1, N . (8)

Наконец, может оказаться, что для некоторых разработок время начала

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

231
 232

множество таких разработок через W , а соответствующие крайние перио-

ды начала выполнения – через i. Тогда дополнительная система ограничений
примет вид
ni

x
t 1
ijt  1,1  t  i , i  W . (9)

Задача (1) – (9) относится к задаче линейного программирования с буле-

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

8.4.2. Двухуровневое распределение ресурсов между разработками методом

динамического программирования

Процесс решения задачи распределения ресурсов между разработками

можно представить как двухуровневую систему принятия решений. Причем
на первом уровне мы решаем задачу оптимального распределения ресурсов
между отдельными работами данной разработки с целью обеспечения max
вероятности ее выполнения, а на следующем уровне решаем аналогичную
задачу, но уже для всего множества разработок.
На первом этапе для каждой разработки i=1,2,…,m используется:
1) сетевой график работ по разработке, отражающий последовательность и
взаимосвязь выполняемых работ.
2) выделенный обобщенный ресурс:
ni
q   qi j
i
0 (14)
j 1

где j=1,2,…,ni– число работ i-й разработки

i=1,2,…,m - число разработок.
1) fij(qij) – вероятность выполнения каждой отдельной работы j разра-
ботки i в зависимости от количества выделенного на нее ресурса qij.
Необходимо определить max общую вероятность выполнения всех
работ разработки в заданное время и соответствующее ей распреде-
ление обобщенного ресурса между работами, т.е. необходимо решить
следующую оптимизационную задачу:

232
 233

 ni 
Pi (q i0 )  max  f ij (qij ) (15)
qi 1 , qi 2 ,...,qin i
 j 1 

При условии, что

ni

q
i 1
ij  qi0 (16)
 bij qij
Обычно: f ij (qij )  f ij0 (1  e ) (17)
Для решения задачи (15)-( 16) воспользуемся методом динамического про-
граммирования.
Пусть Fik (q i0 ) – максимальная вероятность выполнения в срок k первых
работ i–й разработки при условии, что на нее выделено q i0 ресурсов.
k=1,2,…,ni :
Fi1 (q i0 )  max 0  f i1 (q i1 )
0  qi 1  qi


Fi 2 (q i0 )  max 0 f i 2 (q i 2 )  Fi1 (q i0  qi 2 )
0  qi 2  qi

…………………………………………

Fik (qi0 )  max0 f ik (qik )  Fik 1 (qi0  qik )
0 qik  qi
 (18)

…………………………………………

Fini (qi0 )  max0 f ini (qin )  Fini 1 (qi0  qin )
0 qin  qi

После построения функций Fin (qi0 ) для всех i=1,2,…,m и разных значе-
i

ний q i0 решаем задачу второго уровня с целью получения максимальной ве-

роятности выполнения в срок всех разработок тематического плана. Для это-
го решают задачу:
m 0 
P(Q)  0max
q1 , q 20 ,...,q m0

 i 1
Pi ( q i )

(19)

При ограничении:
m

q
i 1
0
i Q (20)

В выражении (19): Pi (qi0 )  Fin (qi0 ), i  1, m . i

Формально задачи (19)-( 20) ничем не отличаются от (15)- (16) и может

быть также решения методом динамического программирования. Для этого
пусть  l (Q) есть максимальная вероятность выполнения первых lразработок
, l=1,2,…,m.

233
 234

Тогда имеем:
 1 (Q )  max
0
 
P1 (qi0 )
0 qi  Q

2 (Q )  max P (q )   (Q  q )
2
0
2 1
0
2
0 q 20 Q

…………………………………….…..
 l (Q)  max
0

Pl (ql0 )   l 1 (Q  ql0 )
0 ql  Q

………………………………………...
 m (Q)  max
0

Pm (q m0 )   m1 (Q  q m0 )
0 q m  Q


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

с учетом взаимозаменяемости ресурсов

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

может оказаться, что еще остались ресурсы в количестве Rkt , где k - номер
вида ресурса, k  1, K , K - число различных видов ресурсов, t - номер перио-
да, t  1, T , T - плановый горизонт, на котором решается задача формирования
тематического плана.
Пусть N - число инициативных разработок портфеля заказов. Для ка-
ждой такой разработки определены количественная оценка эффективности
(важности) C i i  1, N  , требуемое количество ресурсов rikt (i  1, N ; k  1, K ;
t  1,  ) , где K - число различных видов ресурсов,  - продолжительность вы-
полнения всех инициативных разработок.
Необходимо определить, какие разработки из числа инициативных
следует включить в тематический план, обеспечив при этом максимальную
суммарную важность всех выбранных разработок с учетом возможности за-
мены одного вида ресурсов другим. Эту задачу можно решить следующим
образом.
Назовем вариантом включения разработок в тематический план любое
сочетание их из общего списка N конкурирующих разработок. Так как коли-
чество вариантов N1  2 N , то для представления любого номера n (1  n  N 1 ) в
двоичном коде необходимо N двоичных цифр.
Условимся, что каждый разряд двоичного числа соответствует одной
разработке, и тогда, если в этом разряде находится 1, то разработка включа-
ется в план, если 0 – нет. Таким образом, зная номер варианта, легко опреде-
лить номера входящих в него разработок, их общую ценность и требуемые
234
 235

ресурсы.
Для осуществления варианта необходимо, чтобы на каждом периоде
планирования существовало распределение взаимозаменяемых ресурсов
предприятия, удовлетворяющее запросы всех разработок этого варианта. Для
определения требований варианта по всем типам ресурсов на каждом перио-
де планирования просуммируем запросы всех ресурсов.
Для грубой оценки осуществимости варианта можно сравнить сумму
его запросов по типам ресурсов на каждом плановом периоде t  1, T с сум-
мой запасов всех ресурсов предприятия на этом периоде.
Рассмотрим более детально распределение ресурсов на некотором пе-
риоде планирования t  1, T . Пусть имеется всего K типов ресурсов; Ak - сум-
марный запрос всех тем варианта n (1  n  N 1 ) на использование k - го типа
ресурса ( k  1, K ) ; Bl - величина запасов предприятия по l  му типу ресурсов
l  1, K  ; xlk - объемы l -го типа ресурсов, идущие на удовлетворение потреб-
ностей варианта в ресурсах k - го типа; Clk - затраты на использование l  го
типа ресурсов вместо k - го типа; Elk - эффективность замены k - го типа ре-
сурса l  м типом, т.е. количество k - го типа ресурса, эквивалентное единице
l  го типа ресурса.
При этих обозначениях задача распределения ресурсов состоит в оты-
скании неотрицательных значений переменных xlk , обеспечивающих мини-
мальные затраты на реализацию варианта при следующих условиях:
- удовлетворение запросов варианта по всем типам ресурсов, т.е.
K

x
l 1
lk E lk  Ak , k  1, K ; (1)

- ограниченность ресурсов предприятия, т.е.

K

x
k 1
lk  Bl , l  1, K . (2)

Кроме того, по смыслу задачи

xlk  0, l , k  1, K . (3)
Критериальная функция модели, минимизирующей общие затраты,
имеет следующий вид:
K K

C
k 1 l 1
lk  x lk  min . (4)

Задача (1) – (4) является задачей линейного программирования, и, в ча-

стности, при Elk  1 (l , k  1, K ) относится к классу открытых транспортных за-

235
 236

дач. Ее можно решить известными методами линейного рограммирования.

В практике тематического планирования РП после включения в план
директивных разработок число конкурирующих инициативных разработок
обычно невелико, в пределах 10 -12. При большом числе их можно разделить
на приоритетные группы важности, актуальности. Поэтому число возможных
вариантов включения разработок в тематический план N1  212 , и все эти ва-
рианты можно рассмотреть непосредственно и сравнить с помощью ЭВМ.
На этом основан следующий алгоритм направленного перебора форми-
рования тематического плана РП.
1. Для каждого варианта определяется суммарная важность вхо-
дящих в него вариантов.
2. Все варианты сортируются в порядке убывания их важности.
Если все варианты уже просмотрены, то алгоритм заканчивает
работу.
3. Последовательно просматриваются все варианты, начиная с
первого. Производится грубая оценка осуществимости вариан-
та, затем с помощью решения модели (1) – (4) определяется
распределение ограниченных ресурсов РП, удовлетворяющее
запросы всех разработок этого варианта. Если такое распреде-
ление найдено для всех периодов t  1,2,  , T , то вариант счита-
ется оптимальным и входящие в него разработки включаются в
тематический план. Если же такого распределения нет или ва-
риант оказывается неосуществимым даже при грубой оценке,
то рассматривается следующий вариант из проранжированного
по важности списка. Если все варианты просмотрены, то вы-
полняется следующий пункт.
4. В соответствии с ранее рассмотренной в разделе 4.3.1. методи-
кой сроки начала выполнения инициативных разработок, не
включенных в план, увеличиваются на один интервал плани-
руемого горизонта, после чего выполняется пункт 2.

236
 237

Лекция 7
8.5. Модели оперативного управления разработками

8.5.1. Модель определения начала выполнения новой разработки

Одной из особенностей большинства РП является поступление заданий

на новые разработки в течение нового года. Это определяет необходимость
оперативной корректировки годового тематического плана при составлении
квартальных тематических планов, учитывая в них вновь поступившие на
предприятие работы.
При поступлении новой разработки, прежде всего, составляется исход-
ный план ее выполнения. Он содержит желаемые сроки выполнения этапов и
всей разработки в целом и требуемые для этого ресурсы без учета реальных
возможностей подразделений предприятия , которые м.б. в это же самое вре-
мя заняты работами, ранее включенными в тематический план. Поэтому воз-
никают две взаимосвязанные задачи. Первая задача- определение возможно-
сти выполнения новой разработки в сроки, указанные в исходном плане. Ес-
ли ее решение дает отрицательный результат, то рассматривают вторую за-
дачу - назначают наиболее ранний срок начала выполнения разработки, ко-
торый определяется, во-первых, занятостью подразделений выполнением ра-
бот, ранее включенных в план, а во-вторых, объемом и видом ресурсов, по-
требных для выполнения новой разработки.
Особенностью процесса каждой разработки является его стохастич-
ность, выражающаяся в неопределенности сроков ее выполнения и требуе-
мых объемов ресурсов. Поэтому модель рассматриваемой задачи должна
быть стохастичной.
По смыслу задачи срок начала выполнения новой разработки д.б. по
возможности наиболее ранним. Поэтому в качестве критерия оптимизации
решения задачи естественно взять следующий критерий:
НАЧ
t НОВ  min, (1)
где t НОВ
НАЧ
– срок начала новой разработки, отсчитываемый от данного те-
кущего момента времени решения задачи. Возможные значения искомой ве-
личины t НОВ
НАЧ
лежат в пределах от 1 до Т, где Т- плановый горизонт. Так как на
всем интервале времени от t НОВ
НАЧ
до t НОВ
НАЧ
+-1, где – продолжительность вы-
полнения новой работы, превышение требуемого количества ресурсов над
имеющимися может быть только с некоторой заданной вероятностью, то в

237
 238

качестве ограничения задачи естественно взять следующее:

PYk (t )  Rk (t )  Pkd , t  t нов
нач нач
, t нов  1,..., t нов
нач
   1, (2)
где:
Rk(t)-ресурсные возможности предприятия по k-му виду ресурса
( k  1, K ) в t-й дискретный интервал времени (t  1, T ) ;
Yk(t)-суммарный объем работ, необходимый для выполнения всех
разработок данного технического направления, в том числе и новой, в t-м
интервале времени;
Pkd - допустимая вероятность того, что количество ресурсов k-го вида,
необходимое для выполнения всех работ данного технического направления,
не превысит имеющихся ресурсов в распоряжении предприятия.
Поставленную задачу можно решить, если использовать следующий
алгоритм:
1. Значение t НОВ
НАЧ
полагается равным 1.
2. Для всех t  t нов
нач нач
, t нов  1,..., (t нов
нач
   1), и k=1,2,…,К проверяется выполне-
ние условия (2). Если оно не выполняется хотя бы для одного t или k,
то переходим к выполнению п.3. В противном случае переходим к п.4.
3. Значение t НОВ
НАЧ
увеличивается на единицу. Если оно превысило величи-
ну Т, то разработка не может быть начата в заданном плановом гори-
зонте. Если новое значение t НОВ
НАЧ
не превосходит Т, то переходим к п.2.
4. Проверяется возможность выполнения новой работы в установленные
сроки. Для этого проверяется выполнение неравенства
P(t нов