Проектирование АИС

На основе разработанных принципов, положений, моделей, методов и средств построения АИС, полученных на стадии исследования, проводится проектирование системы [9,34]. Эта стадия имеет свои общие и специфические признаки.

1) ПРО существующей (традиционной) ИС;

2) разработка технического задания на создание системы;

3) разработка технического проекта на создание системы;

4) разработка рабочего проекта на создание системы.

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

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

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

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

1) определение необходимого состава показателей.

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

3) разработка схемы размещения реквизитов документа на плоскости бланка. Бланки документов должны строго соответствовать площади (формату), определяемой ГОСТом.

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

• цель, задачи, функции АИС, рассматриваются также внешние условия функционирования системы, распределение функций между ее компонентами;

• системные параметры АИС — интерфейсы и распределение функций между оператором и системой;

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

• структура и система управления БД, лингвистические средства, состав ИПЯ, классификаторов и кодификаторов, методик индексирования документов и запросов;

• ведомость конфигурации комплекса технических средств АИС и их спецификация;

• состав и характеристика математических моделей, алгоритмов и программ АИС;

• схема функционирования АИС, технологического процесса обработки данных и др.;

• должностные и рабочие инструкции для персонала АИС;

• уточненное технико-экономическое обоснование проекта.

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

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

Один из принципиальных вопросов — разработка алгоритмов программ обработки и контроля данных. В качестве примера приведем описание алгоритма программы, концепция и модель которого показаны в разд. 13.2.2. При разработке алгоритма учитывались требования, которые были определены в разделе 13.1. На рис.13.12 представлена структура программы. В блоках 6—10 происходит обработка ошибок по их модификациям, номера которых указаны внутри блоков.

Рис. 13.12. Структура программы «Автоматическое обнаружение ошибок и восстановление достоверности показателей документов табличного вида»

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

Блок контроля документов (БКД) служит для выработки пятиразрядного кода завершения, в дальнейшем код завершения используется как номер подпрограммы обслуживания, максимальное значение которого может быть 2⁵, т.е. 32. Блок контроля документов получает от СПД адрес документа и число строк в этом документе. Графа с номером строки в контроле не участвует и используется при выдаче диагностических сообщений. Остальные графы образуют матрицу, в которой графа КС содержит контрольные суммы по каждой строке.

Рис. 13.13. Блок-схема алгоритма программы «Автоматическое обнаружение ошибок и восстановление достоверности значений показателей документов табличного вида» (окончание см. на с. 399)

Рис. 13.13. Окончание (начало см. на с. 398)

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

При вводе строки 01 производится сравнение накопленных сумм по графам и соответствующим значениям, записанным в строке 01 (графы с 1-й по 15-ю). При несовпадении заносится признак ошибки в графу ECG. При несовпадении накопленной суммы по графе КС заносится признак ошибки SKC.

Если вычисленная сумма по строке 01 не равна заданной, то вводится признак S01. Если сумма не равна вычисленной сумме по графе КС, то вводится признак S0^C При отсутствии признаков ошибок программа переходит к контролю следующего документа.

Если обнаружена одна ошибка, выдается сообщение: «В документе ХХХХХ УУ обнаружена ошибка». При этом с помощью кода завершения выбирается соответствующая подпрограмма обслуживания. Если обнаружено более одной ошибки, выдается сообщение: «В документе ХХХХХ УУ обнаружено более одной ошибки».

Подпрограмма печати адресов получает управление каждый раз, когда в документе обнаружено более одной ошибки. При этом каждая строка с ошибкой сопровождается сообщением: «Строка ХХХХХХ содержит ошибку» и соответственно каждая графа с ошибкой сопровождается сообщением «графа ХХ содержит ошибку».

Подпрограмма СС06 получает управление, когда вычисленная контрольная сумма по строке 01 равна вычисленной контрольной сумме по графе КС и не равна заданной контрольной сумме, т.е. оператор допустил ошибку в подсчете контрольной суммы. Подпрограмма заменяет ошибочное число на вычисленное достоверное и выдает сообщение «строка 01, графа КС значение ХХХХ скорректировано на УУУУ».

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

Подпрограмма СС21 получает управление, если есть ошибка в контрольной сумме одной из строк. Производится замена ошибочного реквизита-основания на вычисленное достоверное с последующей выдачей сообщения «строка ХХХХХХ, графа КС, значение ХХХХ скорректировано на УУУУ».

Подпрограмма СС24 получает управление при наличии ошибки в одной из строк и в одной из граф. Ошибочное число, расположенное на пересечении ошибочной строки с ошибочной графой заменяется на вычисленное достоверное. При этом выдается сообщение «строка ХХХХХХ, графа УУ, значение ХХХХ скорректировано на УУУУ».

Блок переходов осуществляет передачу управления на соответствующую подпрограмму обслуживания, используя код завершения в байте FLAG. В случае если для какого-либо кода завершения нет подпрограммы обслуживания, управление передается на печать кода завершения. Подпрограмма печати кода завершения получает управление, если для кода завершения, выработанного блоком БКД, нет соответствующей подпрограммы обработки. При этом полученный код распечатывается в двоичном виде «Некорректируемая ошибка с кодом ХХХХХ», где: IXXXX-ECL — признак ошибки в строке,

XIXXX-ECG — признак ошибки в графе,

XXIXX-SKC — ошибочная контрольная сумма по графе КС, XXXIX-SOI — ошибочная контрольная сумма по строке 0I, XXXXI-SOIKC — сумма по графе КС не равна сумме по строке 0I. Для вызова и загрузки программы необходимо выполнить трансляцию, редактирование и включение программы посредством стандартной процедуры ASMFGL. Входная точка в программу совпадает с обозначением программы IGN ЗНК. Объем программы составляет 586 операторов на языке АССЕМБЛЕР и занимает 4 килобайта оперативной памяти. Программа не накладывает ограничений на способы ввода документов в ЭВМ. Документы в ЭВМ могут быть введены через клавиатуру, магнитные носители — диски, каналы передачи данных, сканирующие устройства в зависимости от конкретных условий обработки и характера решаемых задач.

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

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

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

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

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

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

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

Последующий анализ протоколов ввода показывает, что одиночные ошибки автоматически обнаруживаются, вычисляются достоверные значения, затем последние заменяют ошибочные значения и оператору для контроля правильности работы программы выдаются сообщения типа: «В документе ХХХХХ УУ обнаружена ошибка, строка ХХХХХХ-графа ХХ, значение ХХ скорректировано на значение УУУУ (табл. 13.17, позиции 1, 5, 7, 12, 14, 15, 17). По двум и более ошибкам программа обнаруживала ошибки, однозначно идентифицируя их адреса, и выдавала сообщения типа: «В документе ХХХХХ УУ обнаружено более одной ошибки, строка ХХХХХХ, содержит ошибку, строка ХХХХХХ, графа ХХ содержит ошибку» (табл. 13.17, позиция 18). Ошибочное значение показывается пересечением номеров соответствующих строк и (или) граф. При случайной механической перестановке значений показателей по строкам и отсутствия нарушения контрольной суммы по графе (в строке 01) выдается сообщение типа: «В документе ХХХХХ УУ обнаружено более одной ошибки, строка ХХХХХ содержит ошибку, строка ХХХХХХ содержит ошибку, графа ХХ содержит ошибку» (табл. 13.17, позиция 19). Точно также идентифицируется перестановка значений показателей по графам. Например, в процессе экспериментального исследования оператором подготовки данных была внесена непреднамеренная ошибка в отчет предприятия «Магнитогорский». Так, в строке 180100, графа 10, в значении показателя 890 цифра 9 была ошибочно заменена на цифру 0, т.е., получено ошибочное значение 800. Поскольку в этот отчет ранее была внесена ситуационная ошибка, то программа выдала сообщение о двух ошибках и их адресах (табл. 13.17, позиция 6). В отчет предприятия «Ульяновский» ситуационные ошибки не вносили, при подготовке данных также не было ошибок, поэтому программа идентифицировала указанный отчет как безошибочный.

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

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

При рассмотрении количественных параметров оценки программы необходимо отметить следующее. Эксперименты показали, что общее время работы программы, как с включением программы в СПД, так и без включения, одинаково и составило 2 мин на обработку 20 отчетов. Однако время работы процессора ЭВМ по реализации операций входного контроля отчетов не равнозначно относительно указанных вариантов контроля. Так, например, время работы процессора с включением программы в СПД по данным протокола ввода и контроля документов составило 38,02 с. Процессорное время контроля без применения рассматриваемой программы (только средствами СПД) составило 44,98 с. Таким образом, применение программы сократило время работы процессора на 6,96 с, т.е. на 15,5 %. Вместе с тем, взаимодействуя с СПД, программа освобождает от необходимости объемной распечатки диагностики ошибок. В любом случае посредством рассматриваемой программы на принтер выдаются более краткие и вместе с тем более информативные сообщения об адресе, исправлении и модификации ошибок. Так, например, распечатка диагностики ошибок по протоколу ввода и контроля 20 отчетов при условии включения рассматриваемой программы в СПД заняла 8 листов бумаги формата 207Η210 мм. Распечатка диагностики указанных отчетов без включения программы, т.е. только средствами СПД, заняла 14 листов бумаги указанного формата. Таким образом, применение программы уменьшает расход бумаги при выполнении этапа ввода и контроля документации ориентировочно до 40 %.

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

Очевидно, что наиболее обоснованным представляется подсчет контрольных сумм поручить составителям документов на предприятиях. Это позволит, с одной стороны, повысить ответственность работников предприятий за достоверность документов, а с другой — в определенной мере освободить систему централизованной обработки ИВЦ от выполнения технических функций по подсчету контрольных сумм, перераспределить и увеличить тем самым объем ресурсов, используемых на интеллектуальные виды работ.

Следует отметить, что включение программы в СПД увеличило объем занимаемой СПД памяти на 3 килобайта. Если общий объем СПД составляет 114 килобайт, то включение в него рассматриваемой программы обусловило увеличение его физического объема всего на 2,6 %, что представляется вполне приемлемым.

Методы и средства проектирования АИС. Проектирование АИС может выполняться:

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

• силами штатных специалистов фирмы-заказчика.

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

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

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

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

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

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

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

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

• устный или письменный опрос;

• письменное анкетирование;

• наблюдение, измерение и оценка;

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

• анализ задач;

• анализ производственных, управленческих и информационных процессов.

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

• моделирование процессов обработки данных;

• структурное проектирование;

• декомпозиция;

• анализ информационной технологии.

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

13.4.