В. М.

ВЕЙЦМАН

ПРОЕКТИРОВАНИЕ
ИНФОРМАЦИОННЫХ
СИСТЕМ
Учебное пособие

САНКТПЕТЕРБУРГ
МОСКВА
КРАСНОДАР
2022
УДК 004.415.2:33
ББК 32.973018.2я73

В 26 Вейцман В. М. Проектирование информационных систем :

учебное пособие / В. М. Вейцман. — СанктПетербург : Лань,
2022. — 316 с. : ил. — (Учебники для вузов. Специальная
литература). — Текст : непосредственный.

ISBN 9785811437139

Учебное пособие по дисциплине «Проектирование информационных

систем» предназначено для студентов, обучающихся по направлению
«Прикладная информатика».
В пособии раскрываются основы проектирования экономических
информационных систем на различных стадиях жизненного цикла.
Рассматриваются методы и средства канонического проектирования
экономических информационных систем и их развитие в современных
условиях, а также организация и управление процессом проектирования.
В учебном пособии также отражены теоретические основы построения
корпоративных информационных систем (КИС), описана методология
структурного анализа и проектирования корпоративных информационных
систем, рассмотрены стандарты моделирования КИС (SADT, UML). Также
пособие содержит классификацию промышленных корпоративных
информационных систем. Ключевым моментом является описание CASE
технологии проектирования КИС и методы автоматизации проектирования
КИС.
УДК 004.415.2:33
ББК 32.973018.2я73

Рецензент
Д. О. БЫТЕВ — доктор технических наук, профессор, зав. кафедрой
прикладной математики и вычислительной техники Ярославского
государственного технического университета.

Îáëîæêà
Е. А. ВЛАСОВА

© Издательство «Лань», 2022

© В. М. Вейцман, 2022
© Издательство «Лань»,
художественное оформление, 2022
 ВВЕДЕНИЕ
Учебное пособие «Проектирование информационных систем» предназна-
чено для студентов, обучающихся по направлению 09.03.03 «Прикладная ин-
форматика».
Цель написания учебного пособия — ознакомить студентов с возможно-
стями проектирования информационных систем как в классическом варианте,
так и на базе применения современных CASE-технологий.
Изучение материалов пособия позволит студентам получить знания:
— об архитектуре различных классов ИС;
— о содержании стадий и этапов проектирования ИС и их особенностях
при использовании различных технологий проектирования;
— о методах и инструментальных средствах проектирования отдельных
компонентов ИС, включая классификаторы экономической информации, фор-
мы первичных и результативных документов, внемашинную и внутримашин-
ную технологию обработки информации;
— о содержании функций организации, планирования и управления про-
ектными работами;
— по вопросам применения различных CASE-средств для создания как
баз данных, так и программных приложений.
Материал пособия изложен в форме, доступной для самостоятельного
изучения студентами.
При написании учебного пособия использовались лекции прочитанные
студентам Академии «МУБиНТ», материалы, приведенные в списке литературы.

3
 ТЕМА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ
ПРОЕКТИРОВАНИЯ ЭКОНОМИЧЕСКИХ
ИНФОРМАЦИОННЫХ СИСТЕМ
1.1. Основные понятия предметной области
Информационные системы существовали с момента появления общества,
поскольку на любой стадии развития общество требует для своего управления
систематизированной, предварительно подготовленной информации.
В соответствии с кибернетическим подходом система управления пред-
ставляет собой совокупность объекта управления, например, предприятия, и
субъекта управления — управленческого аппарата (рис. 1.1). Управленческий
аппарат объединяет в себе сотрудников, формирующих цели, разрабатывающих
планы, вырабатывающих требования к принимаемым решениям, а также кон-
тролирующих их выполнение.
В задачу же объекта управления входит выполнение планов, выработан-
ных управленческим аппаратом, т. е. реализация той деятельности, для которой
создавалась система управления.

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

4
 Таким образом, внешняя среда влияет не только на объект управления,
она поставляет информацию и управленческому аппарату, решения которого
зависят от внешних факторов (состояния рынка, наличия конкуренции, величи-
ны процентных ставок, уровня инфляции, налоговой и таможенной политики).
Взаимосвязь информационных потоков (П и О), средств обработки, пере-
дачи и хранения данных, а также сотрудников управленческого аппарата, вы-
полняющих операции по переработке данных, и составляет информационную
систему экономического объекта.
Для любой системы характерны следующие основные свойства:
 сложность;
 делимость;
 целостность;
 многообразие элементов и различие их природы;
 структурированность.
Сложность системы зависит от множества входящих в нее компонентов,
их структурного взаимодействия, а также от сложности внутренних и внешних
связей и их динамичности.
Делимость системы означает, что она состоит из ряда подсистем или
элементов, выделенных по определенному признаку, отвечающему конкретным
целям и задачам.
Целостность системы означает, что функционирование множества эле-
ментов системы подчинено единой цели.
Многообразие элементов системы и различие их природы связано с их
функциональной специфичностью и автономностью. Например, в материаль-
ной системе объекта, связанной с преобразованием вещественно-
энергетических ресурсов, могут быть выделены такие элементы, как сырье, ос-
новные и вспомогательные материалы, топливо, полуфабрикаты, запасные ча-
сти, готовая продукция, трудовые и денежные ресурсы.
Структурированность системы определяет наличие установленных свя-
зей и отношений между элементами внутри системы, распределение элементов
системы по уровням иерархии.
Управление — важнейшая функция, без которой немыслима целенаправ-
ленная деятельность любой социально-экономической, организационно-
производственной системы (предприятия, организации, территории).
Систему, реализующую функции управления, называют системой
управления. Важнейшими ее функциями являются:
 прогнозирование;
 планирование;
 учет;
 анализ;
 контроль;
 регулирование.
Вся деятельность человека и любых групп людей связана с управлением.
Человек управляет своими действиями, руководит коллективом, создает меха-

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

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

7
которым анализ поведения системы и влияние на нее в целом проводятся через
входы системы на основе информации, получаемой с выходов.
При таком способе исследования экономические объекты наиболее часто
описываются статистическими моделями с использованием корреляционного,
регрессивного или факторного анализа. По мере изучения внутренней структу-
ры объекта управления необходимость в применении принципа «черного ящи-
ка» отпадает.
Этот метод широко применяется при изучении пакетов прикладных про-
грамм (ППП), по которым отсутствует описание.
Возрастание объемов информации в контуре информации и в контуре
управления, усложнение ее обработки повлекло за собой сначала внедрение
компьютеров на отдельных операциях, а затем расширение их применения.
Традиционная информационная система стала качественно меняться.
В управленческом аппарате появилось новое структурное подразделение, един-
ственной функцией которого стало обеспечение процесса управления досто-
верной информацией на основе применения средств вычислительной техники.
В связи с этим в контуре управления появились новые информационные пото-
ки, а старые потоки частично изменили свое направление. Часть традиционной
информационной системы стала постепенно, но неуклонно трансформировать-
ся в направлении все большей автоматизации обработки информации.
С учетом сферы применения выделяются:
 технические информационные системы;
 экономические информационные системы;
 информационные системы в гуманитарных областях и др.
Так как далее речь будет идти исключительно об информационных си-
стемах экономического характера, необходимо ввести понятие экономической
информационной системы (ЭИС). Под ней будем понимать систему, предна-
значенную для хранения, поиска и выдачи экономической информации по за-
просам пользователей. С помощью ЭИС, к сожалению, может перерабатывать-
ся далеко не вся информация, используемая для управления объектом, посколь-
ку на любом предприятии циркулируют огромные информационные потоки,
играющие важную роль в принятии решений, но обработка которых с помощью
компьютеров невозможна. Причина этого заключается в сложности структури-
зации информации и формализации процессов ее переработки.
В ЭИС от объекта управления направляется только та часть информации
(рис. 1.3) — О2, которую можно систематизировать и обрабатывать с помощью
компьютера.
Аналогично от управленческого аппарата передается в ЭИС лишь часть
директивной информации — П2, которая может быть соответствующим обра-
зом переработана и передана объекту управления. Доля информации, обраба-
тываемой в ЭИС, для различных уровней управления колеблется по отношению
к общему объему от 10 до 20%.

8
 Рис. 1.3
Место ЭИС в контуре системы управления:
П1, П2 — неформализуемая и формализуемая часть директивной информации (прямая связь);
О1, О2 — неформализуемая и формализуемая часть информации обратной связи.
В соответствии с характером обработки информации в ЭИС на различных
уровнях управления экономической системой (оперативном, тактическом и
стратегическом) выделяются следующие типы информационных систем:
 системы обработки данных (EDP — electronic data processing);
 информационные системы управления (MIS — management informati-
on system);
 системы поддержки принятия решений (DSS — decision support
system).
Системы обработки данных (СОД) предназначены для учета и оператив-
ного регулирования хозяйственных операций, подготовки стандартных доку-
ментов для внешней среды (счетов, накладных, платежных поручений). Эти за-
дачи имеют итеративный, регулярный характер, выполняются непосредствен-
ными исполнителями хозяйственных процессов (рабочими, кладовщиками, ад-
министраторами и т. д.) и связаны с оформлением и пересылкой документов в
соответствии с четко определенными алгоритмами. Результаты выполнения хо-
зяйственных операций через экранные формы вводятся в базу данных.
Информационные системы управления (ИСУ) ориентированы на тактиче-
ский уровень управления: среднесрочное планирование, анализ и организацию
работ в течение нескольких недель (месяцев). Например, анализ и планирование
поставок, сбыта, составление производственных программ. Для данного класса
задач характерны регламентированность (периодическая повторяемость) форми-
рования результатных документов и четко определенный алгоритм решения за-
дач. Например, свод заказов для формирования производственной программы и
определение потребности в комплектующих деталях и материалах на основе
спецификации изделий. Решение подобных задач на основе накопленной базы

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

1.2. Архитектура ЭИС

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

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

Рис. 1.4
Графическое представление процесса управления объектом:
t — время; xпл(t) — программное, планируемое значение параметра; xф(t) — фактическое зна-
чение параметра.
Блок-схема реализации этого процесса представлена на рисунке 1.5.
Планирование заключается в выработке плановой «траектории» процесса
Х(t) на период планирования {t0, tпл}. Учет, т. е. измерение, в производственных
системах состоит в определении в заданные моменты времени истинного со-
стояния процесса Xф(t).
11
 Рис. 1.5
Блок-схема реализации процесса управления объектом
Контроль позволяет определить отклонение Xф(t) от Xпл(t), а регулирова-
ние состоит в определении скорректированного плана Xр(t), т. е. по существу
является решением задачи планирования при равных начальных условиях.
Схема управления, показанная на рисунке 1.5, является универсальной и
применима ко всем процессам производственных систем.
Компонентами вектора-функции Х(t) могут быть показатели, характери-
зующие ход производства, состояние доходов, расходов, кадров и т. д. Это за-
висит от декомпозиции функции Х(t).
В ходе декомпозиции функциональная часть разбивается на подсистемы,
конкретный состав которых определяется признаком декомпозиции. Но по-
скольку сложная система всегда многофункциональна, ЭИС может быть де-
композирована по разным признакам:
 предметному;
 функциональному;
 проблемному;
 смешанному (предметно-функциональному).
С учетом предметной направленности использования ЭИС в хозяйствен-
ных процессах промышленного предприятия выделяют подсистемы, соответ-
ствующие управлению отдельными ресурсами:
 управление сбытом готовой продукции;
 управление производством;
 управление материально-техническим снабжением;
 управление финансами;
 управление персоналом.
Для реализации функций управления выделяют следующие подсистемы:
 планирование;
 регулирование (оперативное управление);
 учет;
 анализ.
Проблемный принцип формирования подсистем отражает необходимость
гибкого и оперативного принятия управленческих решений по отдельным про-
блемам в рамках СППР. Например, решение задач бизнес-планирования,
12
управления проектами. Такие подсистемы могут реализовываться в виде ло-
кальных информационных систем, импортирующих данные из корпоративной
информационной системы (например, система бизнес-планирования на основе
Project-Expert) или в виде специальных подсистем в рамках корпоративной ИС
(например, информационной системы руководителя).
На практике чаще всего применяется смешанный предметно-функцио-
нальный подход, согласно которому построение функциональной структуры
ИС — это разделение ее на подсистемы по характеру хозяйственной деятельно-
сти, которое должно соответствовать структуре объекта и системе управления,
а также характеру выполняемых функций управления. Используя этот подход,
можно выделить следующий типовой набор функциональных подсистем в об-
щей структуре ЭИС предприятия.
Функциональный принцип:
 перспективное развитие (ПР);
 технико-экономическое планирование (ТЭП);
 бухгалтерский учет и анализ хозяйственной деятельности (БУ и АХД).
Предметный принцип (подсистемы управления ресурсами):
 техническая подготовка производства (ТПП);
 управление основным производством (УОП);
 управление вспомогательным производством (УВП);
 управление качеством продукции (УКП);
 управление материально-техническим снабжением (УМТС);
 управление реализацией и сбытом готовой продукции (УС);
 управление кадрами (УК).
Подсистемы, построенные по функциональному принципу, охватывают
все виды хозяйственной деятельности предприятия (производство, снабжение,
сбыт, персонал, финансы). Подсистемы, построенные по предметному принци-
пу, относятся в основном к оперативному уровню управления ресурсами.
Выбор признаков декомпозиции ЭИС зависит от специфики объекта
управления и целей ее создания.
Трансформация целей управления в функции, а функций — в подсистемы
ЭИС позволяет проводить дальнейшую декомпозицию. Если подсистемы ЭИС
реализуют некоторые отделенные друг от друга функции управления, то каж-
дую из них можно делить на более детальные функции, или, как их еще назы-
вают, задачи (или комплексы задач).
Состав задач ЭИС определяется следующими факторами:
 важностью той или иной функций управления;
 возможностью формализации управленческих процедур;
 уровнем подготовки персонала управления к использованию компь-
ютеров;
 наличием информационной базы и технических средств.
Их распределение между участниками процесса управления может про-
исходить по-разному, поскольку некоторые задачи могут быть целиком решены
на одном рабочем месте, а другие требуют участия многих управленческих ра-
13
ботников. Но каким бы ни было такое разделение, оно не должно сказаться на
содержательной части задачи.
Обеспечивающие подсистемы ЭИС
Обеспечивающие подсистемы ЭИС являются общими для всей ЭИС,
независимо от конкретных функциональных подсистем, в которых применяют-
ся те или иные виды обеспечения. Состав обеспечивающих подсистем не зави-
сит от выбранной предметной области. В состав обеспечивающих подсистем
входят подсистемы организационного, информационного, лингвистического и
технологического обеспечения.
Информационное обеспечение
Информация столь же необходима управленческому аппарату, как объекту
управления — сырье и ресурсы. Она формируется в результате обработки спе-
цифического сырья, известного под названием «данные». Последние отражают
конкретные финансово-хозяйственные факты, состояние или процессы и имеют
собственный материальный носитель (бухгалтерские и финансовые документы,
сигналы, поступающие от датчиков, дисплеи, магнитные носители и т. д.).
Информационная база состоит из двух взаимосвязанных частей: внема-
шинной и внутримашинной.
К внемашинной относится та часть, которая обслуживает систему управления
в виде, воспринимаемом человеком без каких-либо технических средств, например,
документы (наряды, акты, накладные, счета или регистры, ведомости и т. д.).
Внутримашинная информационная база содержится на машинных носи-
телях и состоит из файлов. Она может быть создана либо как множество ло-
кальных, т. е. независимых файлов, каждый из которых отражает некоторое
множество однородных управленческих документов (например, накладных),
либо как база данных.
Разница состоит в том, что при создании базы данных файлы не являются
независимыми, ибо структура одних файлов (состав полей) зависит от структу-
ры других. Это служит причиной несоответствия структуры файлов базы дан-
ных структуре управленческих документов, на основе которых эти файлы со-
здаются. Файлы базы данных разрабатываются с соблюдением определенных
принципов и ориентацией на одну из моделей базы данных (реляционную,
иерархическую, сетевую).
Файлы обрабатываются с помощью специального программного обеспе-
чения систем управления базами данных (СУБД).
Состав внутримашинной базы определяется исходя из информационных
потребностей каждого уровня управленческого аппарата.
Техническое обеспечение
Технические возможности ЭИС определяются рядом обеспечивающих
подсистем, к которым относятся подсистемы технического, организационного
обеспечения и др.

14
 Технические средства служат основой построения ЭИС. Мощность этих
средств в значительной мере определяет состав решаемых задач управления.
К техническим средствам ЭИС — техническое обеспечение — относятся ком-
пьютеры, средства коммуникации и оргтехника.
Весь компьютерный парк условно можно разделить на два класса: персо-
нальные и высокопроизводительные компьютеры (Mainframe System).
Последние необходимы для создания больших хранилищ данных и обес-
печения доступа к ним. К таким компьютерам предъявляются высокие требова-
ния к надежности при круглосуточной работе, к защите данных и производи-
тельности. Одна из наиболее известных фирм, выпускающая машины такого
класса, — «Tandem Computers» — ориентируется на безостановочную обработ-
ку данных высокой степени важности в реальном масштабе времени.
Компьютеры могут объединяться в вычислительные сети. В локальных
вычислительных сетях (ЛВС) известно несколько режимов работы. Наиболее
простой режим не предполагает специально выделенного компьютера, ресурсы
которого распределяются между другими машинами. Каждая ЭВМ имеет свои
собственные ресурсы, предоставляемые другим компьютерам.
Второй режим предусматривает выделение отдельного компьютера для
обслуживания сетевых программ и других компьютеров. Только такой компью-
тер называется файл-сервером.
Третий режим также предполагает выделение отдельного компьютера и
известен под названием «клиент-сервер». В отличие от предыдущего в данном
случае находятся не только общие базы данных, но и программы поиска и запи-
си, что позволяет клиентам (другим программам, расположенным на удаленных
компьютерах) запрашивать не всю информацию из базы данных, а только ча-
стично или полностью обработанную сервером. При этом снижается загружен-
ность каналов передачи данных.
ЛВС могут объединяться между собой таким образом, что абоненты од-
ной сети пользуются ресурсами другой.
Перечисленные классы машин и сети ЭВМ могут функционировать толь-
ко с помощью общесистемного программного обеспечения.
Программное обеспечение
«Оживить» техническое обеспечение, т. е. заставить его выполнять опе-
рации по обработке информации, — задача программного обеспечения (ПО).
ПО — совокупность программ системы обработки данных и программных до-
кументов, необходимых для эксплуатации этих программ. Различают общее и
прикладное ПО. В общее ПО включают операционные системы, системы про-
граммирования, сервисные программы.
Операционная система — это программа, которая автоматически загру-
жается при включении компьютера и представляет пользователю базовый
набор команд, с помощью которых можно общаться с компьютером: запустить
программу, отформатировать диск, скопировать файл и т. д.
Системы программирования представляют собой инструментальные
средства для квалифицированных пользователей — программистов и непро-
15
граммистов. Инструментальные средства программиста определяют информа-
ционные технологии, предназначенные для проектирования функционального
программного обеспечения. Функциональное ПО — это программная реализа-
ция конкретных функций информационного работника с использованием раз-
личных информационных технологий. То есть это настройка автоматизирован-
ного рабочего места (АРМ), СУБД, гипертекстов, мультимедиа, экспертных си-
стем, программного комплекса задач и подсистем ЭИС, построенных с помо-
щью других средств проектирования, под конкретного информационного ра-
ботника конкретного предприятия, учитывающая специфику сложившейся там
системы обработки данных.
Инструментальные средства пользователя определяют информационные
технологии, доступные пользователю с любой квалификацией в области вы-
числительной техники и программирования.
Сервисные программы представляют ряд услуг по обеспечению эксплуа-
тации ЭВМ и программного обеспечения.
Организационное обеспечение
Является одной из важнейших подсистем ЭИС, от которой зависит
успешная реализация целей и функций системы. В составе организационного
обеспечения можно выделить четыре группы компонентов.
Первая группа включает важнейшие методические материалы, регламен-
тирующие процесс создания и функционирования системы:
 общеотраслевые руководящие методические материалы по созданию
ЭИС;
 типовые проектные решения;
 методические материалы по организации и проведению предпроект-
ного обследования на предприятии;
 методические материалы по вопросам создания и внедрения проект-
ной документации.
Вторым компонентом в структуре организационного обеспечения ЭИС
является совокупность средств, необходимых для эффективного проектирова-
ния и функционирования ЭИС (комплексы задач управления, включая типовые
пакеты прикладных программ, типовые структуры управления предприятием,
унифицированные системы документов, общесистемные и отраслевые класси-
фикаторы и т. п.).
Третьим компонентом подсистемы организационного обеспечения явля-
ется техническая документация, получаемая в процессе обследования, проекти-
рования и внедрения системы: технико-экономическое обоснование, техниче-
ское задание, технический и рабочий проекты и документы, оформляющие по-
этапную сдачу системы в эксплуатацию.
Четвертым компонентом подсистемы организационного обеспечения
является персонал, где представлена организационно-штатная структура проек-
та, определяющая, в частности, состав главных конструкторов системы и спе-
циалистов по функциональным подсистемам управления.

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

1.3. Общие принципы, определяющие

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

17
 Внедрение любого нового элемента затрагивает какие-то элементы си-
стемы, поэтому системный подход должен учитываться не только при проекти-
ровании, но и при функционировании системы (например, изменение кода де-
тали).
Другим важнейшим проявлением системного подхода является межси-
стемная и внутрисистемная совместимость. Имеется в виду как совмести-
мость различных систем между собой (от ОГАС до АСУТП), так и совмести-
мость задач, подсистем, массивов внутри одной системы. Это очевидное требо-
вание не всегда удовлетворяется в настоящее время, что резко снижает эффек-
тивность автоматизации.
Совместимость требует методологического, информационного, организа-
ционного, технического, программного и лингвистического единства систем и
их частей.
Методологическое единство базируется на выборе согласованных крите-
риев оптимальности, на непротиворечивых ограничениях, на использовании
взаимосвязанных экономико-математических методов.
Информационное единство систем требует согласования документов по
форме и содержанию, согласованной системы классификации и кодирования,
взаимоувязки выходных данных другой системы.
Организационная совместимость требует согласования организационных
структур управления, режимов работы системы, ее подразделений и других
форм организации.
Техническое единство требует такого согласования технических средств,
чтобы они могли работать в единой вычислительной системе, иметь «общий
язык», использовать единую систему связи и передачи данных.
Программное единство базируется на возможности использования про-
грамм работы ЭВМ в различных системах.
Неотъемлемой частью информационного и программного единства явля-
ется лингвистическое единство систем, т. е. базирование различных систем на
единой терминологической основе, на совместимых информационных и алго-
ритмических языках (Fox, Clapion, Clipper).
Другим важным общесистемным принципом является адаптация. Любая
система, чтобы быть жизнеспособной, должна иметь возможность учитывать
изменяющиеся внешние и внутренние условия. Она должна быть гибкой, адап-
тивной. Адаптация — способность системы обнаружить целенаправленное
приспособляющееся поведение.
С принципом адаптации тесно связан принцип непрерывного развития.
Он обусловлен тем, что процесс совершенствования управления неисчерпаем,
как и сами объекты. Любая система в процессе эксплуатации должна совершен-
ствоваться. Непрерывно совершенствуется экономика, формы и методы управ-
ления, вычислительная техника и технология обработки информации. Поэтому
при создании систем необходимо обеспечить такие условия, в которых можно
осуществлять последующее ее развитие.
ЭИС должна создаваться с учетом возможности пополнения и обновле-
ния функций и состава системы без нарушения ее функционирования.
18
 Есть два источника требований к непрерывному развитию:
 внешний (среда, законы);
 внутренний (уточнение целей, саморазвитие, совершенствование пер-
сонала).
При проектировании систем приходится учитывать также принцип пре-
емственности. Он опирается на общефилософское положение об эволюцион-
ности развития. Новая система должна учитывать все лучшее, чем располагает
старая система, но в то же время она должна быть свободна от недостатков,
присущих действующей системе. Система, как правило, создается не на пустом
месте.
Организационные принципы
Принцип первого руководителя
Разработка и внедрение системы должны проводиться под непосред-
ственным руководством первого руководителя соответствующего объекта (ми-
нистра, директора и т. д.). Отечественная и зарубежная практика свидетель-
ствует, что всяческая попытка передоверить дело создания систем второсте-
пенным лицам неизбежно приводит к тому, что система ориентируется на ру-
тинные задачи управления и не дает ожидаемого эффекта.
Кроме того, вычислительная техника вносит существенные изменения в
систему и методы работы, перераспределение обязанностей и ответственности
большинства работников. Руководитель отвечает за планирование работы, вы-
бор ЭВМ и ее установку. Только полнота определения потребностей объекта и
возможность их удовлетворения, имеющаяся у первого руководителя, обеспе-
чивают решение всего комплекса вопросов, возникающих в процессе создания
и функционирования ЭИС.
Принцип обязательного участия заказчика в работах
Заказчик должен принимать непосредственное участие в создании ин-
формационной базы системы и осуществлять организационные мероприятия
(изменение структуры, функциональных обязанностей управленческого аппа-
рата и его обучение), чтобы к моменту ввода отдельных частей системы работ-
ники аппарата полностью владели бы методами машинного решения задач
управления. Без непосредственного участия заказчика на всех стадиях создания
системы невозможно создать систему, отвечающую всем требованиям данного
объекта. Только заказчик знает все нюансы объекта.
Подготовка персонала к работе в условиях ЭИС
В процессе разработки должно осуществляться:
 обучение работников аппарата управления новым методам решения
задач и ознакомление с возможностями и особенностями новых средств;
 непрерывное информирование работников аппарата управления о
ходе, трудностях и результатах обработки информации при решении новых за-
дач;
 совместное экспериментальное решение задач управления работни-
ками организации-разработчика и аппарата управления заказчика;
 изменение структуры — обучение на новых рабочих местах.
19
 Процесс подготовки персонала должен сопровождать весь ход разработок
ЭИС.
Принцип совершенствования структуры означает:
 такое выделение структурных звеньев, чтобы они работали на до-
стижение конечной цели;
 обеспечение координации и синхронизации деятельности всех
служб.
Принцип конверсии или переходного периода
Внедрение системы требует большого количества подготовительных ра-
бот. Важно, чтобы эти работы тщательно планировались. При внедрении пред-
приятие встречается с трудной задачей перехода от старого процесса к новому.
Переходный период имеет следующие особенности:
 сверка результатов процессов, выполненных старыми и новыми мето-
дами;
 координация фактического перехода;
 планирование параллельного процесса;
 проверка полноты и точности информации.
Основной целью переходного периода является проведение испытаний
нового процесса. Иногда процессы не могут идти параллельно, и тогда возни-
кают существенные трудности.
Принципы экономического (экономико-математического) характера
Одним из принципов, которым необходимо руководствоваться при по-
строении АСУ и ЭИС, является принцип новых задач. Суть его состоит в том,
что наибольший эффект получается от использования ЭВМ при создании но-
вых задач. Но понятие «новые задачи» нельзя воспринимать узко, как только те
задачи, которые раньше не решались и не были поставлены. Таких, абсолютно
новых задач можно найти очень немного. Правильное толкование этого терми-
на предусматривает решение и традиционных задач, но новыми методами, на
основе новой информации и т. д.
Принцип приоритетности отдельных задач состоит в том, что для каж-
дой конкретной системы оценивается важность решения отдельных задач и в
соответствии с этим определяется очередность их разработки и внедрения в
рамках общего плана создания системы.

1.4. Основы методологии проектирования ЭИС

Жизненный цикл ИС
Одним из базовых понятий методологии проектирования ИС является
понятие жизненного цикла ИС (ЖЦ ИС). ЖЦ ИС — это непрерывный процесс,
который начинается с момента принятия решения о необходимости его созда-
ния и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ИС, явля-
ется международный стандарт ISO/IEC 12207 (ISO — International Organization
of Standardization — Международная организация по стандартизации, IEC —
20
Iternational Electrotechnical Commission — Международная комиссия по элек-
тротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и
задачи, которые должны быть выполнены во время создания ЭИС.
Структура ЖЦ ИС по стандарту ISO/IEC 12207 базируется на трех груп-
пах процессов:
 основные процессы ЖЦ ИС (приобретение, поставка, разработка, экс-
плуатация, сопровождение);
 вспомогательные процессы, обеспечивающие выполнение основных
процессов (документирование, управление конфигурацией, обеспечение каче-
ства, верификация, аттестация, оценка, аудит, решение проблем);
 организационные процессы (управление проектами, создание инфра-
структуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка включает в себя все работы по созданию ЭИС и ее компо-
нентов (рис. 1.6).

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

21
 Создание логического проекта, включающего алгоритмы сбора, обработ-
ки и выдачи информации, описание информационных потребностей пользова-
телей на уровне имен документов и показателей. Этот этап соответствует в ка-
кой-то степени техническому проекту.
Составление программного проекта, заключающееся в программной ре-
ализации логического проекта. Этот этап соответствует рабочему проекту.
Внедрение проекта ЭИС.
Функционирование, сопровождение и модернизация ЭИС. Эти процессы
протекают параллельно.
Эксплуатация включает в себя работы по внедрению компонентов ПО в
эксплуатацию, в том числе конфигурирование базы данных и рабочих мест
пользователей, обеспечение эксплуатационной документацией, проведение
обучения персонала и т. д. и непосредственно эксплуатацию, в том числе лока-
лизацию проблем и устранение причин их возникновения, модификацию ИС в
рамках установленного регламента, подготовку предложений по совершенство-
ванию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации
работ, создания коллективов разработчиков и контроля за сроками и качеством
выполняемых работ. Техническое и организационное обеспечение проекта
включает выбор методов и инструментальных средств для реализации проекта,
определения методов описания промежуточных состояний разработки, разра-
ботку методов и средств испытаний ИС, обучение персонала и т. п.
Обеспечение качества проекта связано с проблемами верификации, про-
верки и тестирования ИС.
Верификация — это процесс определения того, отвечает ли текущее со-
стояние разработки, достигнутое на данном этапе, требованиям этого этапа.
Проверка позволяет оценить соответствие параметров разработки с исходными
требованиями. Проверка частично совпадает с тестированием, которое связано
с идентификацией различий между действительными и ожидаемыми результа-
тами и оценкой соответствия характеристик ИС исходным требованиям.
В процессе реализации проекта важное место занимают вопросы идентифика-
ции, описания и контроля конфигурации отдельных компонентов и всей систе-
мы в целом.
Управление конфигурацией является одним из вспомогательных процес-
сов, поддерживающих основные процессы жизненного цикла ИС, прежде всего
процессы разработки и сопровождения ИС. При создании проектов сложных
ИС, состоящих из многих компонентов, каждый из которых может иметь раз-
новидности или версии, возникает проблема учета их связей и функций, созда-
ния унифицированной структуры и обеспечения развития всей системы. Управ-
ление конфигурацией позволяет организовать, систематически учитывать и
контролировать внесение изменений в ИС на всех стадиях ЖЦ. Общие принци-
пы и рекомендации конфигурационного учета, планирования и управления
конфигурациями ИС отражены в проекте стандарта ISO 12207-2.
Каждый процесс характеризуется определенными задачами и методами
их решения, исходными данными, полученными на предыдущем этапе, и ре-
22
зультатами. Результатами анализа, в частности, являются функциональные мо-
дели, информационные модели и соответствующие диаграммы. ЖЦ ИС носит
итерационный характер: результаты очередного этапа часто вызывают измене-
ния в проектных решениях, выработанных на более ранних этапах.
Модели жизненного цикла ИС
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы
разработки ИС. Под моделью ЖЦ понимается структура, определяющая после-
довательность выполнения и взаимосвязи процессов, действий и задач, выпол-
няемых на протяжении ЖЦ.
Модель ЖЦ зависит от специфики ИС и специфики условий, в которых
последняя создается и функционирует.
Регламенты этого стандарта являются общими для любых моделей ЖЦ,
методологий и технологий разработки.
Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ИС, но не
конкретизирует в деталях, как реализовать или выполнить действия и задачи,
включенные в эти процессы.
К настоящему времени наибольшее распространение получили следую-
щие две основные модели ЖЦ:
 каскадная модель (1970–1985 гг.);
 спиральная модель (1986–1990 гг.).
В изначально существовавших однородных ИС каждое приложение пред-
ставляло собой единое целое.
Для разработки такого типа приложений применялся каскадный способ.
Его основной характеристикой является разбиение всей разработки на этапы,
причем переход с одного этапа на следующий происходит только после того,
как будет полностью завершена работа на текущем (рис. 1.7).

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

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

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

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

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

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

Рис. 1.10
Параллельная разработка задач
Преимущества метода «шахт».
1. Кажущаяся простота.
2. Задачи могут разрабатываться и внедряться, не приводя к глубоким
структурным изменениям.
3. Системы и подсистемы можно делить на столько частей, сколько
нужно для лучшего выполнения поставленных задач. Но нельзя увлекаться, так
как вся система станет «тяжеловесной».
4. Разработка каждой задачи ведется практически отдельно, а значит,
процесс упрощается (кодирование только под задачу). При этом могут работать
несколько коллективов разработчиков, каждый со своими методами и инстру-
ментами.
5. Изменения в уже реализованные задачи легче вносить из-за слабой
связи «шахт».
Таким образом, метод «шахт» позволяет реализовать задачи, относящиеся
к четко разграниченным видам деятельности, благодаря чему уменьшаются
трудности их разработки, а впоследствии и сопровождения.

26
 Недостатки метода «шахт».
1. Основной недостаток метода заключается в том, что сопряжение раз-
рабатываемых по отдельности задач, налаживание взаимного обмена между
ними и координация работ представляют большие трудности.
2. При изменении функции или структуры организации требуется разра-
ботка новых «шахт».
3. Дублирование информации, которое неизбежно при чистом методе
«шахт», может свести на нет все преимущества информатизации.
Метод «пласта»
В общем случае метод «пласта» заключается в осуществлении автомати-
зации функционирования ИС предприятия в целом.
Для этого требуется:
 описать ИС организации (по результатам обследования);
 исследовать автоматизированные информационные подсистемы с уче-
том связей между ними;
 связать между собой и собрать в одно целое автоматизированные ин-
формационные подсистемы, чтобы в результате получилась автоматизирован-
ная информационная система.
Преимущества метода «пласта».
1. Возможность обеспечения интегрированного управления предприятием.
2. Создание благоприятных условий для пересмотра структуры органи-
зации.
3. Однократная регистрация (ввод) данных, используемых несколькими
информационными подсистемами.
Недостатки метода «пласта».
1. Слишком затяжной и трудный процесс реализации метода, а впослед-
ствии и внесения изменений, так как между элементами ИС много связей.
2. Необходимость почти во всех случаях затрагивать структуру органи-
зации.
3. Невозможность независимого рассмотрения задач управления, что
влечет за собой, прежде всего, проблемы координации труда разработчиков.
4. Сложность внедрения, так как надо практически единовременно
начать внедрение всех подсистем.
5. Велика вероятность прагматических ошибок, так как система очень
сложная, а их исправление затруднено.
Совмещение методов
Учитывая преимущества метода «пласта» и сложность его практической
реализации, на практике совмещают интегрированность подхода к проектиро-
ванию этим методом с гибкостью и практической реализуемостью метода
«шахт».
Для этого:
1) проводится полное обследование предприятия или организации;
2) разрабатываются схемы основных информационных потоков, выде-
ляются подсистемы и задачи;

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

1.5. Классификация основных методов проектирования

Приведем принятую в настоящее время классификацию методов проекти-
рования ЭИС (рис. 1.11).

Рис. 1.11
Классификация основных методов проектирования
Оригинальное проектирование
Является традиционным. В свое время ЭИС разрабатывались только этим
методом. Он охватывает все стадии и этапы проектирования, другие методы
отличаются от него степенью их автоматизации.
Прототипное проектирование
Данная технология обеспечивает создание на ранней стадии реализации
действующей интерактивной модели системы, так называемой системы-
прототипа, позволяющей наглядно продемонстрировать пользователю буду-
щую систему, уточнить его требования, оперативно модифицировать интер-
фейсные элементы: формы ввода сообщений, меню, выходные документы,
структуру диалога, состав реализуемых функций.
В процессе работы с системой-прототипом пользователь реально осознает
возможности будущей системы и определяет наиболее удобный для него режим
обработки данных, что значительно повышает качество создаваемых систем.
Осуществляется проверка принципиальных проектных решений по составу и
структуре ЭИС и оценка основных ее эксплуатационных характеристик.
Типовое проектирование
Методы типового проектирования предполагают разбиение создаваемой
системы на множество составляющих компонентов (подсистем, алгоритмов
и т. д.) и создание для каждого из них законченного проектного решения, кото-
28
рые затем с некоторыми модификациями, если они необходимы, будут исполь-
зоваться при проектировании. В зависимости от уровня декомпозиции системы
на составляющие компоненты различают элементный, подсистемный и объект-
ный методы проектирования.
Сущность элементного проектирования заключается в том, что деком-
позиция ЭИС осуществляется на уровне задач и отдельных проектных решений
по информационному, техническому, программному и математическому видам
обеспечения. Для каждого такого элемента создаются типовые проектные ре-
шения (ТПР). Применение ТПР при создании ЭИС обеспечивает сокращение
трудовых затрат примерно на 30% по сравнению с оригинальным проектирова-
нием.
ТПР-задача включает постановку задачи и соответствующие программы
ее решения. Программы строятся по модульному принципу.
ТПР-техника содержит решения по созданию вычислительных центров и
применению периферийных технических средств. Модульная структура рас-
пространяется и на ТПР-технику, что позволяет учитывать требования проек-
тируемой ЭИС как в период ее создания, так и при наращивании комплекса
технических средств в процессе функционирования ЭИС без существенной пе-
ределки технической документации.
ТПР-персонал включает методические материалы по работе персонала
при функционировании ЭИС.
Отличительной особенностью подсистемного проектирования является
более высокая степень интеграции типовых элементов ЭИС. Декомпозиция си-
стемы осуществляется на уровне подсистем, которые и выступают здесь в каче-
стве типизируемого элемента. При этом должны быть достигнуты функцио-
нальная полнота подсистемы, минимализация внешних информационных свя-
зей, параметрическая настраиваемость, альтернативность схем в пределах зна-
чений входных параметров. После того как подсистемы выделены, для каждой
из них создается проектное решение.
Наиболее часто используемыми средствами подсистемного метода проек-
тирования являются пакеты прикладных программ. Каждый ППП, как правило,
охватывает соответствующую подсистему управления объектом. Результатом
проектирования в этом случае является индивидуальный проект с типовыми
элементами в виде ППП. При создании ЭИС конкретного объекта применяется
сразу несколько совместимых ППП, объединяемых в некоторую подсистему.
Объектным методом называется использование готового проекта, кото-
рый настраивается (адаптируется) на весь объект целиком («Галактика», 1:С
УПП и др.), и охватывает практически все подсистемы.
Автоматизированное проектирование — это проектирование с исполь-
зованием современных инструментальных средств, так называемых CASE-
технологий (Computer Aided Software Engineering).
CASE-технология представляет собой методологию проектирования ИС,
а также набор инструментальных средств, позволяющих в наглядной форме
моделировать предметную область и разрабатывать приложения в соответствии
с информационными потребностями пользователя.
29
 1.6. Вопросы для самопроверки
1. Какие принципы системного подхода к созданию ЭИС вы знаете?
2. Какова структура экономической системы?
3. Что такое экономическая информационная система?
4. Какие виды ЭИС существуют?
5. Как можно определить понятия СОД, ИСУ, СППР?
6. Как можно определить понятия «локальная» и «корпоративная» ЭИС?
7. Дайте определения функциональной и обеспечивающей подсистем
ЭИС.
8. Зачем создаются функциональные и обеспечивающие подсистемы?
9. Чем отличаются функциональные и обеспечивающие подсистемы?
10. Назовите принципы выделения функциональных подсистем.
11. Каков состав типовых функциональных подсистем для ЭИС про-
мышленного предприятия?
12. Каков состав обеспечивающих подсистем ЭИС, какова их взаимо-
связь между собой и с функциональными подсистемами?
13. Что такое методология проектирования ЭИС?
14. Что понимается под организацией проектирования ЭИС?
15. Как классифицируются методы проектирования ЭИС?
16. Какие признаки характеризуют каноническое проектирование ЭИС?
17. Какие признаки характеризуют автоматизированное проектирование
ЭИС?
18. Какие признаки характеризуют типовое проектирование ЭИС?
19. Какие стадии входят в жизненный цикл ЭИС?
20. Какие существуют модели жизненного цикла ЭИС?

30
 ТЕМА 2. ОРГАНИЗАЦИЯ КАНОНИЧЕСКОГО
ПРОЕКТИРОВАНИЯ ЭИС
Каноническим проектированием будем называть такую его методику, ко-
торая отражает процесс проектирования ЭИС для конкретного класса объектов
управления, однако все операции, зафиксированные в ней, выполняются вруч-
ную. Такая методика является как бы исходной, отображающей процесс созда-
ния системы на самом низком уровне декомпозиции. Являясь подробным отоб-
ражением процесса проектирования ЭИС, канонический метод может служить
базой для обоснования разработки различных автоматизированных средств
проектирования.
Метод канонического проектирования может служить основой для срав-
нения двух и более альтернативных технологий.
Проектирование ЭИС — длительный, трудоемкий и динамический про-
цесс, в котором на разных этапах принимают участие специалисты разных спе-
циальностей и квалификации. Одной из основных задач управления разработ-
ками является четкое распределение и координация работ по группам специа-
листов во времени для успешного завершения проектных работ в директивно
установленные сроки.
Организации, участвующие в создании ЭИС, по своим юридическим пол-
номочиям разделяются на две категории: заказчиков и разработчиков.
В качестве заказчика может выступать любая хозяйственная организация, для
которой необходимо разработать ЭИС. Разработчиком, как правило, выступа-
ют специализированные проектные организации (научно-исследовательские и
проектные институты, проектные бюро и т. д.), связанные с заказчиком дого-
ворными обязательствами по созданию ЭИС. Однако возможна ситуация, когда
функции заказчика и разработчика совмещаются — система обработки инфор-
мации проектируется собственными силами.
Процесс проектирования ЭИС в соответствии с нормативными докумен-
тами — общеотраслевыми руководящими методическими материалами по со-
зданию многоуровневых интегрированных автоматизированных систем управ-
ления производственными объединениями (предприятиями) и ГОСТами — де-
лится на следующие стадии:
 предпроектную;
 стадию технического проектирования;
 стадию рабочего проектирования;
 стадию ввода в действие.
Более детально стадии и этапы процесса канонического проектирования ИС
приведены в ГОСТ 34.601-90 (см. Приложение 2) и сокращенно в таблице 2.1.
Допускается исключать стадию «Эскизный проект» и отдельные этапы
работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая
документация» в одну стадию «Технорабочий проект». В зависимости от спе-
цифики создаваемых АС и условий их создания допускается выполнение от-

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

2.1. Состав проектной документации

Результатом проведения проектных работ, завершающим каждый этап
проектирования ЭИС, является техническая документация (рис. 2.1). Ее состав,
содержание и форма представления оговаривается нормативными документа-
ми — Общеотраслевыми руководящими методическими материалами (ОРММ),
ГОСТ (РД 50-34.698-90. С. 2).

32
 На предпроектной стадии создания ЭИС формируются:
 технико-экономическое обоснование (ТЭО) разработки ЭИС;
 техническое задание на проектирование ЭИС.
В технико-экономическом обосновании выявляются узкие места суще-
ствующей системы управления, обосновывается необходимость и определяют-
ся пути ее совершенствования.

Рис. 2.1
Документация ЭИС
Технико-экономическое обоснование включает следующие разделы:
 введение;
 характеристику объекта и существующей системы управления;
 цели, критерии и ограничения создания ЭИС;
 функции и задачи создаваемой ЭИС;
 ожидаемые технико-экономические результаты создания ЭИС;
 выводы и предложения.
В ТЭО представлены материалы, содержащие:
 характеристики организационной и производственной структуры объ-
екта управления, его основные технико-экономические показатели;
 методы организации планирования, учета, анализа и отчетности;
 основные направления совершенствования управления в целом;
 критерии эффективности для оценки и выбора вариантов автоматиза-
ции;
 оценку конкретных технико-экономических показателей повышения
эффективности производства и управления за счет ЭИС;
 обоснование перечня автоматизируемых функций управления, приме-
няемых проектных решений, в том числе типовых, по организационному, тех-
33
ническому, информационному, программному и математическому обеспече-
нию;
 оценку затрат на создание ЭИС и экономического эффекта от ее
внедрения;
 определение возможных источников финансирования;
 рекомендации по совершенствованию системы управления.
Техническое задание (ТЗ) на проектирование является основным доку-
ментом, оформляемым на предпроектной стадии разработки ЭИС. ТЗ разраба-
тывают на основании результатов работ, проводимых на предпроектной стадии,
с учетом технико-экономического обследования и требований, изложенных в
РД 50-34.698-90.
Техническое задание отражает требования, предъявляемые пользователя-
ми-заказчиками к разрабатываемой системе.
ТЗ представляет собой описание совокупности характеристик, которым
должна удовлетворять создаваемая ЭИС, в том числе по программному, мате-
матическому, техническому, информационному, функциональному и организа-
ционному обеспечению, по срокам завершения стадий проектирования.
Таким образом, техническое задание отвечает на вопросы, какой должна
быть ЭИС и что должно дать ее внедрение для улучшения работы экономиче-
ского объекта.
Техническое задание на проектирование ЭИС включает семь разделов:
 введение;
 характеристика объекта управления;
 назначение ЭИС;
 основные требования к ЭИС;
 технико-экономические показатели ЭИС;
 состав, содержание и организация работ по созданию ЭИС;
 порядок приемки ЭИС.
Проектная документация формируется на проектных стадиях создания
ЭИС и включается либо в технический, либо в рабочий проект системы обра-
ботки.
Стадия технического проектирования завершается составлением техниче-
ского проекта ЭИС, представляющего собой подробное описание создаваемой
системы обработки. Технический проект состоит из взаимосвязанной совокуп-
ности общесистемной документации и документации по функциональной и
обеспечивающим частям.
Общесистемная документация технического проекта включает следую-
щие документы: пояснительную записку к проекту, смету затрат, расчет эконо-
мической эффективности, план мероприятий по подготовке объекта к вводу
ЭИС в эксплуатацию, ведомость документов технического проекта. В этих до-
кументах дается общее описание и обоснование общесистемных проектных
решений; определяются материальные затраты и рассчитываются показатели
ожидаемой экономической эффективности от внедрения ЭИС; указываются ме-

34
роприятия, выполнение которых необходимо для ввода ЭИС в эксплуатацию;
приводится перечень документов технического проекта ЭИС.
Документация функциональной части ЭИС содержит решения по авто-
матизированным функциям управления объектом, функциональной структуре
ЭИС и постановкам задач (комплексов задач). В постановках задач приводятся
описания характеристик задач (цели решения, технико-экономической сущно-
сти, периодичность решения и т. д.), входной и выходной информации (либо
даются ссылки на документы обеспечивающей части, где эта информация
находится), алгоритмов их решения. Причем в полном объеме данный раздел
разрабатывается для оригинальных задач, не имеющих аналогов. Если при ре-
шении задач будут использованы стандартные программы, то в соответствую-
щих разделах постановок задач должны быть ссылки на них.
Документация обеспечивающей части технического проекта содержит
описание проектных решений по информационному, техническому, математи-
ческому, программному и организационному видам обеспечения ЭИС.
Документация информационного обеспечения включает чертежи доку-
ментов (видеограмм), а также описание:
 информационного обеспечения ЭИС;
 организации информационной базы (внемашинной и внутримашин-
ной);
 системы классификации и кодирования;
 массивов информации.
В этих документах описываются основные принципы построения инфор-
мационного обеспечения, состав и структура информационной базы ЭИС, ис-
пользуемые системы классификации и кодирования, формы документов (видео-
грамм), приводятся характеристики массивов информации, информационные
связи задач на уровне показателей, требования к обеспечению достоверности
данных и совместимости с другими ЭИС.
Документация технического обеспечения, входящая в технический про-
ект, содержит проектные решения по комплексу технических средств (КТС),
контроля и обработки данных, количественные и качественные характеристики
ЭВМ и периферийной техники, структуру ВЦ и служб, обеспечивающих функ-
ционирование ЭИС, требования к помещениям, а также требования пожарной
безопасности, сигнализации и экранирования.
Документация математического обеспечения входит только в состав
технического проекта и содержит описание используемых экономико-
математических моделей и алгоритмов, общих для нескольких задач.
Документация программного обеспечения на стадии технического проек-
та включает описание программного обеспечения ЭИС, в котором приводятся
общие принципы построения программного обеспечения, его структура, функ-
ции основных частей, характеристика операционной системы и средства ее
расширения.
Документация организационного обеспечения включает схему и описание
организационной структуры объекта управления в связи с внедрением ЭИС (со-
здание новых подразделений, регламент их работы и упразднение существую-
35
щих) и требования ЭИС к подразделениям объекта по сбору первичной и ис-
пользованию результатной информации.
Результатом выполнения рабочего проектирования (РП) является рабочий
проект ЭИС, представляющий собой описание практической реализации ос-
новных положений технического проекта (РП) (включает общесистемные до-
кументы и документы обеспечивающей части, в основном программного обес-
печения).
К общесистемным документам РП относятся:
 общее описание ЭИС;
 ведомость держателей подлинников ЭИС;
 формуляр системы;
 ведомость документов рабочего проекта;
 ведомость эксплуатационных документов.
В этих документах содержатся общая характеристика ЭИС (назначение,
структура, назначение частей и т. д.) и справочные данные, например, перечень
держателей подлинников.
Документация обеспечивающей части рабочего проекта содержит:
 описание технологии обработки данных и ведения информационной
базы;
 чертежи и планы по созданию комплекса технических средств (его
размещению, монтажу и т. д.).
Описание программного обеспечения включает:
 описание общесистемного программного обеспечения в составе опе-
рационных систем, трансляторов, утилит, систем управления базами данных,
описание оригинальных программ, а также параметров и порядка настройки и
генерации применяемых пакетов прикладных программ;
 должностные и технологические инструкции, регламентирующие дея-
тельность персонала на объекте управления в условиях ЭИС.
Отметим, что на каждую оригинальную программу (программное сред-
ство) составляются следующие документы:
 техническое задание;
 спецификация;
 текст программы;
 описание программы;
 общее описание;
 руководство программиста;
 руководство оператора;
 методика испытаний;
 пояснительная записка;
 описание контрольного примера.
В случае объединения стадий технического и рабочего проектирования
формируется технорабочий проект.
Проектная документация, в зависимости от назначения, может представ-
ляться либо разработчику, либо пользователю, либо тому и другому.
36
 Опытная эксплуатация и приемо-сдаточные испытания ЭИС, проводи-
мые на стадии внедрения проекта системы, оформляются соответствующими
актами приемки, которые подтверждают работоспособность созданной системы
обработки.

2.2. Взаимодействие пользователя и разработчиков ЭИС

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

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

2.3. Вопросы для самопроверки

1. Что такое каноническое проектирование ЭИС и каковы особенности
его содержания?
2. Какие стадии составляют процесс канонического проектирования?
3. Каков состав документов, предназначенных для формализованного
описания?

38
 ТЕМА 3. СОДЕРЖАНИЕ РАБОТ НА СТАДИИ
ИССЛЕДОВАНИЯ ПРЕДМЕТНОЙ ОБЛАСТИ
И ОБОСНОВАНИЯ ПРОЕКТНЫХ РЕШЕНИЙ
ПО СОЗДАНИЮ ЭИС
Предпроектная стадия является одним из важнейших этапов создания
ЭИС. От качества изучения и анализа исходной системы в большой степени за-
висит и качество результата. А ошибки, допущенные на этой стадии, зачастую
могут привести к повторной переработке (доработке) проекта, так как это в ос-
новном семантические и прагматические ошибки. Это усугубляется тем, что на
предпроектной стадии, особенно в операциях сбора информации, практически
невозможно использование автоматизированных средств. При этом резко воз-
растают требования к уровню специалистов, проводящих исследование объекта.
Они должны обладать:
 знаниями современных информационных технологий, знаниями со-
временных методов и техник управления;
 опытом исследования объектов и разработки систем в данной кон-
кретной области или в смежных областях;
 коммуникабельностью — для успешного общения со специалистами
исследуемой организации;
 практическим опытом и теоретическими знаниями методов проведе-
ния обследования и обработки их результатов (в том числе и CASE-
технологиями).

3.1. Цели и задачи предпроектной стадии создания ЭИС

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

39
  требования к программным и информационным компонентам;
 системы, необходимые аппаратные ресурсы, требования к базе дан-
ных;
 физические характеристики компонентов системы, их интерфейсы.
Качество дальнейшего проектирования решающим образом зависит от
правильного выбора методов анализа, сформулированных требований к вновь
создаваемой технологии. Эти методы служат для проведения изучения и иссле-
дования, разработки и оценки проектных решений, закладываемых при созда-
нии ИС, а также для обеспечения экономии затрат и сокращения сроков проек-
тирования и внедрения системы.
Прежде всего, необходимо определить метод организации проведения
обследования.
Все методы организации можно объединить в группы по следующим
признакам.
1. По цели обследования выделяют метод организации локального про-
ведения обследования, используемый для разработки проекта отдельной задачи
или для комплекса задач, и метод системного обследования объекта, применяе-
мый для изучения всего объекта с целью разработки для него проекта ЭИС в
целом.
2. По числу исполнителей, проводящих обследование: применяется ин-
дивидуальное обследование, осуществляемое одним проектировщиком, и бри-
гадное, с выделением ряда бригад — исполнителей, изучающих все подразде-
ления предприятия, и одной координирующей бригады.
3. По степени охвата предметной области применяют метод сплошного
обследования, охватывающего все подразделения экономической системы, и
выборочного, применяемого при наличии типовых по структуре подразделений
(например, цехов или складов).
4. По степени одновременности выполнения работ первого и второго
этапов предпроектной стадии выделяют метод последовательного проведения
работ, при котором проектировщики сначала собирают данные о предметной
области, а затем их изучают (часто применяют при отсутствии опыта в выпол-
нении такого рода работ), и метод параллельного выполнения работ, когда од-
новременно со сбором происходит изучение полученных материалов обследо-
вания, что значительно сокращает время на проведение работ на предпроектной
стадии и повышает качество получаемых результатов.
Методы сбора и анализа информации, используемые на стадии предпро-
ектного обследования, подразделяются на методы изучения и анализа фактиче-
ского состояния объекта (технологии), методы формирования заданного состо-
яния, методы графического представления фактического и заданного состояний
(рис. 3.1).
Методы изучения и анализа фактического состояния
экономического объекта или технологии
Эти методы позволяют выявить узкие места в исследуемых процессах и
включают:
40
  устный или письменный опрос;
 письменное анкетирование;
 наблюдение, измерение и оценку;
 групповое обсуждение;
 анализ задач;
 анализ процесса.
Устный или письменный опрос
Опрос проводится по заранее составленному вопроснику на рабочем ме-
сте специалиста с записью ответов и позволяет в форме несложной беседы по-
нять технологию работы и опыт опрашиваемого. Затруднения психологическо-
го порядка легко преодолеваются, и можно приступить к подготовке нового
решения уже на стадии анализа. Недостатком этого метода является разнород-
ность результатов опроса.

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

41
работка на ЭВМ. Чтобы повысить качество анкетирования, целесообразно вве-
сти подсказку ответов: «да — нет», «малый — средний — большой» и т. д.
Существенное влияние на качество результатов оказывают четкость, не-
двусмысленность вопросов, поэтому разработка перечня вопросов предполагает
знание принципиальной проблемной ситуации.
Необходимо отметить, что каждый из участвующих в проекте системных
аналитиков должен обследовать не более 2–3 видов деятельности предприятия
(таких как, например, учет кадров, бухгалтерия, маркетинг, ремонт оборудова-
ния, перевозки и т. п.) для того, чтобы тщательно в них разобраться. Современ-
ное предприятие является сложной системой, состоящей из крупных взаимо-
увязанных подсистем (деятельностей), а возможности человека в одновремен-
ном охвате большого количества таких подсистем ограничены, поэтому здесь в
полной мере должен использоваться принцип «разделяй и властвуй».
В качестве исходной информации при проведении обследования и вы-
полнении дальнейших этапов служат:
 данные по оргштатной структуре предприятия;
 информация о принятых технологиях деятельности;
 стратегические цели и перспективы развития;
 результаты интервьюирования сотрудников (от руководителей до ис-
полнителей нижнего звена);
 предложения сотрудников по усовершенствованию бизнес-процессов
предприятия;
 нормативно-справочная документация;
 данные по имеющимся на предприятии средствам и системам автома-
тизации;
 опыт системных аналитиков в части наличия типовых решений.
При проведении обследования целесообразно применять следующие ме-
тоды:
 анкетирование;
 сбор документов;
 интервьюирование.
Анкетирование является начальным этапом обследования и предваряет
выезд группы системных аналитиков на предприятие, что позволит спланиро-
вать первоначальное распределение работ группы аналитиков. Анкеты должны
рассылаться руководителям структурных подразделений и содержать графы
для идентификации фамилии и должности анкетируемого, отдельно излагается
просьба приложить шаблоны документов, с которыми работают сотрудники со-
ответствующего подразделения.
Список вопросов должен быть ограничен (не более 15–20) с тем, чтобы
вся анкета не занимала более двух листов. Автору приходилось видеть анкеты
размером в 50 страниц, содержащие до 500 тщательно продуманных вопросов,
но не встречался ни один человек, добровольно (следовательно, также тщатель-
но и с пользой для дела) на них ответивший.

42
 Примерный вариант анкеты приведен ниже.
1. Ф.И.О. руководителя подразделения, телефон.
2. Координаты контактного лица (к кому в отсутствие или при занятости
руководителя можно обращаться).
3. Каковы (с позиции вашего подразделения) должны быть цели созда-
ния интегрированной системы управления предприятием?
4. Основные функции подразделения.
5. Какая информация поступает из других подразделений (заявки, запро-
сы, отчеты и т. п.)?
6. Какая информация передается в другие подразделения?
7. Какая информация формируется («рождается») в подразделении?
8. С какими внешними предприятиями (банк, заказчик, поставщик
и т. п.) взаимодействует подразделение и какой информацией обменивается?
9. Физическое представление информационных потоков и хранилищ
(документ, дискета, сеть, журнал, картотека и т. п.).
10. Время хранения информации. Документ «от» и «для» руководства.
11. Штатная структура и квалификация кадров.
12. Техническое оснащение подразделения (компьютеры, сеть, модем
и т. п.).
13. Используемые программные продукты.
14. Подпись.
Анкета сопровождается просьбой приложить:
 положение о подразделении;
 набор документальных форм без внутреннего наполнения, т. е. ис-
пользуемые формы, бланки и др. (например, карточка складского учета, отчет
по форме №, наряд-задание, товарно-транспортная накладная).
Сбор документов должен осуществляться на всех этапах проведения об-
следования, соответствующие формы, бланки и т. п. в дальнейшем сослужат не-
оценимую службу при разработке информационной модели предприятия (выяв-
лении сущностей информационной модели и наполнении их атрибутикой).
В дальнейшем целесообразно подготовить альбом форм с разбивкой их по дея-
тельностям предприятия. Такой альбом будет являться хорошим вспомогатель-
ным результатом консалтинга для предприятия — своими силами подобная ра-
бота обычно не производится (за исключением уровня отдельных исполнителей).
Интервьюирование является важнейшим и необходимым методом обсле-
дования, только с его помощью можно разобраться во всех тонкостях применя-
емых на предприятии технологий. Современное предприятие является слож-
нейшей системой: как оно функционирует не знает ни один человек. Конечно,
руководство представляет ситуацию в целом, с другой стороны, клерк доско-
нально знает свою деятельность, но полной картины не имеет никто. И только
интервьюирование представителей всех звеньев — оргштатной структуры —
позволит выявить и в дальнейшем формализовать эту картину.
С другой стороны, интервьюирование является и наиболее сложной зада-
чей: необходимо найти контакт с сотрудником и направить беседу в необходи-
мое для аналитика русло.
43
 Ниже предлагается несколько общих рекомендаций, касающихся линии
поведения аналитика при интервьюировании.
Тезис в начале беседы — я ничего (или почти ничего) не знаю о вашей
работе, расскажите как можно подробнее, чем вы занимаетесь.
Правило 1 — если вам начали подробно рассказывать технологию работы,
ни в коем случае не перебивайте, необходимые уточнения можно сделать и в
конце беседы.
Правило 2 — если в беседе участвуют несколько аналитиков, вести беседу
и задавать уточняющие вопросы должен один из них, неясные для других во-
просы проясняются в конце беседы.
Правило 3 — даже если вы прекрасно знаете предметную область, не го-
ворите много сами и не учите интервьюируемого: в любом случае выявляются
тонкости и детали, специфичные для данного предприятия и, естественно, вам
неизвестные.
В принципе, этих и подобных им правил достаточно для выявления в хо-
де беседы необходимой аналитику информации приблизительно у 90% интер-
вьюируемых, а это более чем достаточно в соответствии с законом «20 на 80»
(сравните: 20% людей выпивают 80% пива). Тем не менее, постараемся соста-
вить основанную на опыте типизацию остальных 10% и предложить возможные
действия по выходу из тупика.
«Отказник» — как правило, квалифицированный специалист, осознаю-
щий свою незаменимость. Обычно руководству известен его характер, поэтому
необходимы жесткие меры: либо данная деятельность не будет включена в мо-
дель, либо она будет промоделирована на основании опыта и соображений
здравого смысла.
«Говорун» — как правило, руководитель среднего звена, понимающий,
что по-старому работать нельзя и хватающийся за любую возможность улуч-
шить ситуацию. Очень полезный для поддержки проекта человек, тем не менее,
в беседе готов бесконечно обсуждать свои трудности и проблемы, получить от
него необходимую для построения модели информацию практически невоз-
можно. Единственный способ работы с ним — обсуждение уже построенной
(пусть примитивной и во многом ошибочной) модели с целью ее доводки.
«Балласт» — человек, давно работающий на предприятии и непонятно
чем занимающийся. На вопросы типа: «Какие функции вы выполняете?»,
«С какими документами вы работаете?» — агрессивно повторяет, как попугай:
«Я делаю все!», «Со всеми документами», «Все документы ко мне приходят и
все уходят». Какой-либо информации получить не удается по причине ее отсут-
ствия. Естественно, никакого отражения подобной «деятельности» в модели не
производится.
Человек, занимающий экзотическую и малопонятную должность типа
«главный обогатитель». Представляет собой модификацию варианта 3 с той
лишь разницей, что реально деятельность по обогащению руды существует и,
следовательно, должна быть отражена в модели.
«Мелкая сошка» — человек, не привыкший к проявлению интереса к себе
и своей работе и занимающий низшую должность. При должном терпении ре-
44
ально получение того небольшого куска информации, которым он владеет. При
обследовании диспетчерской службы одного из северных предприятий на од-
ной из удаленных точек автор имел неосторожность во время кратковременной
беседы включить микрофон. Беседа была тут же прервана, и автору пришлось
ждать минут сорок, пока интервьюируемая приводила себя в порядок — накла-
дывала косметику и делала прическу!
Какую же информацию нужно выявлять прежде всего во время интервь-
юирования?
Во-первых, необходимо ограничить контекст системы — с этой целью
должны быть выявлены все излишние объекты, с которыми моделируемое
предприятие взаимодействует, технологии взаимодействия со стороны пред-
приятия, а также информационные (и, возможно, материальные) потоки, обес-
печивающие эти взаимодействия.
Во-вторых, должны быть детально выявлены реальные технологии рабо-
ты предприятия — нормативно-справочная документация (если она имеется)
описывает их неполно.
В-третьих, должны быть определены реальные функции подразделений
и их взаимосвязи и взаимозависимости, поскольку положения о подразделениях
такую информацию не содержат.
В-четвертых, должны быть выявлены и специфицированы все информа-
ционные хранилища (в том числе и бумажные: картотеки, архивы и т. п.).
В-пятых, должна быть оценена аппаратно-техническая база предприятия,
а также исследовано работающее на ней программное обеспечение.
Наконец, в-шестых, должны быть собраны статистические данные по
бизнес-процессам предприятия. Остановимся на последнем более подробно.
Статистические данные при проведении обследования необходимо соби-
рать по каждому объекту будущей модели: потоку данных, элементу данных,
процессу, хранилищу данных, внешней сущности и т. п., — все они со време-
нем сослужат хорошую службу. Так, на этапе анализа моделей наличие по-
дробной статистики обеспечит их адекватную верификацию на полноту и не-
противоречивость и позволит на начальных этапах выявлять ошибки и узкие
места в построенных моделях. В следующих пунктах будет показано, как эти
статические данные работают на дальнейших этапах, начиная с этапа выработ-
ки предложений по автоматизации и заканчивая собственно разработкой или
внедрением выбранной системы.
Составные данные. Для составных данных статистика собирается, как
правило, лишь для итеративных (повторяющихся) компонентов — необходимо
точно знать количество итераций для каждого из них. Например, заказ на книги
включает в себя перечень заказанных книг с их атрибутами. Поэтому для фор-
мирования требований к функции распечатки соответствующего бланка необ-
ходимо знать, сколько книг обычно заказывается, как часто производится нети-
пичный заказ и каковы его размеры, сколько авторов обычно бывает у книги.
Статистика по итеративным компонентам внутри составных данных в
дальнейшем будет использоваться для проектирования экранов, отчетов и,
естественно, при проектировании баз данных.
45
 Элементы данных. О каждом элементе данных необходимо знать формат
данных и допустимые значения этого элемента. Формат (включая тип) и физи-
ческая длина очень полезны при проектировании экранных форм и определе-
нии размеров баз данных.
Потоки данных. Такие характеристики потока, как скорость и интенсив-
ность, являются необходимыми при определении требований к аппаратным
(техническим) средствам. Кроме того, для любого составного потока данных
полезно знать существующее внутри него распределение компонентов, данная
статистика может использоваться для определения пиковых нагрузок на соот-
ветствующие обрабатывающие процессы.
Процессы. Важнейшими характеристиками процессов являются частота и
время выполнения. Именно здесь и лежит ключ к улучшению их функциониро-
вания. Кроме того, такие сведения являются необходимыми при определении
требований к аппаратным средствам.
Хранилища данных. По хранилищам данных обычно собирается следую-
щая информация: среднее количество записей в каждом хранилище данных, ко-
личество чтений, добавлений, изменений и удалений записей по каждому из
процессов, включающих перечисленные действия. Проектировщик баз данных
может использовать эту статистику для нескольких целей — например, решить
вопрос, какой ключ считать первичным, сортировать ли хранилище и по какому
ключу, решить, нужно ли завести дополнительную таблицу с целью обеспече-
ния скорости доступа и т. д. Более того, к этой информации потребуется обра-
титься и при выборе подходящей СУБД, которая сможет обеспечить необходи-
мую частоту и/или гибкость доступа к данным.
Ценной информацией является и хронология доступа. Так, запись о кон-
кретном заказе, как правило, однажды создается и однажды удаляется. Но
обычно доступ к этой записи осуществляется очень часто в начале ее существо-
вания (запросы о покупателе, счета, платежи, накладные) и крайне редко в
дальнейшем (месячные и квартальные отчеты), что позволяет своевременно
осуществлять ее архивацию.
Внешние объекты. Наконец, необходимо собрать определенную стати-
стику об окружении, в котором система должна работать («ограничения окру-
жения»). Наиболее важным здесь является количество пользователей, их спосо-
бы использования системы и географическое распределение. По этой статисти-
ке можно будет сделать заключения о стоимости периферии, о типе системы и
телекоммуникаций и даже о том, как данные должны быть физически распре-
делены для обеспечения удаленного доступа. Другие данные об окружении мо-
гут включать температуру, уровень шума, существенную отделку помещения,
уровень радиации и т. п.
Следует отметить, что часто возникает необходимость в проведении до-
полнительного обследования: какие-то моменты были не до конца выяснены,
где-то возникли нестыковки, что-то было просто упущено.
Обычно дополнительное обследование занимает 2–3 дня, и при его про-
ведении очень полезно обсудить с интервьюированными уже наработанные мо-
дели.
46
 Наблюдение, измерение и оценка. С помощью этих методов собираются
сведения о параметрах, признаках и объектах в соответствующей сфере иссле-
дования. Важные для изучения параметры, признаки и объекты точно оценива-
ются сотрудниками и регистрируются в карточках или в формулярах (напри-
мер, по частоте, количеству, продолжительности, затратам). Накопление сведе-
ний и анализ результатов при достаточно большом количестве наблюдений вы-
полняется на ЭВМ.
Групповое обсуждение проводится проектировщиками, программистами
совместно с пользователями или заказчиками с целью обобщения и обсуждения
всех важных для решения проблем вопросов и определения необходимых за-
дач.
Анализ задач. Суть этого метода состоит в вертикальной и горизонталь-
ной структуризации задач и их распределении между исполнителями (долж-
ностными инструкциями) на основе заданной структуры объекта. Задачи рас-
членяются до такой степени, чтобы имелась возможность определить результа-
ты, решения, полномочия, алгоритмы, входную и выходную информацию. Ана-
лиз задач — это первый этап и предпосылка описания задач, которые являются
основой для построения технологии получения результатов, разработки долж-
ностных инструкций и планов распределения функций при работе в новых тех-
нологических условиях. Отправным пунктом анализа служат требования к объ-
екту и его информационной системе.
Анализ производственных, управленческих и информационных процессов
используется для подготовки решений, касающихся реорганизации технологии
информационных процессов. С помощью анализа процесса решения задач раз-
рабатываются необходимые изменения, которые должны быть внесены в ин-
формационную технологию. Одновременно уточняются целевые установки ре-
шаемых задач.
Анализ производственных, управленческих и информационных процес-
сов должен охватывать в первую очередь следующее:
 обследуемый объект;
 цель и результат решения управленческих задач;
 составляющие технологического процесса (решения, операции и алго-
ритмы);
 объем и качество информации;
 средства обработки информации;
 требования к управленческому персоналу и рабочему месту;
 методы работы;
 узкие места, помехи, трудности;
 требования рациональной организации техпроцесса.
В целом методы изучения и анализа фактического состояния управленче-
ской деятельности и существующей технологии решения задач предназначены
для установления и оценки процессов, функций, предъявляемых к работникам
требований, последовательности выполнения технологических операций и

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

48
 Конструирование систем «черных ящиков» существенно упрощается.
Намного легче разработать магнитофон или проигрыватель, если не беспоко-
иться о создании встроенного усилительного блока.
Облегчается тестирование таких систем. Если появляется плохой звук од-
ной из колонок, можно поменять колонки местами. Если неисправность пере-
местилась с колонкой, то именно она подлежит ремонту; если нет, тогда про-
блема в усилителе, магнитофоне или местах их соединения.
Имеется возможность простого реконфигурирования системы «черных
ящиков». Если колонка неисправна, то вы можете отправить ее в ремонтную
мастерскую, а сами пока продолжать слушать свои записи в монорежиме.
Облегчается доступ для понимания и освоения. Можно стать специали-
стом по магнитофонам без углубленных знаний о колонках.
Увеличивается удобство при модификации. Вы можете приобрести ко-
лонки более высокого качества и более мощный усилитель, но это совсем не
означает, что вам необходим больших размеров проигрыватель.
Таким образом, первым шагом упрощения сложной системы является ее
разбиение на «черные ящики», при этом такое разбиение должно удовлетворять
следующим критериям:
 каждый «черный ящик» должен реализовывать единственную функ-
цию системы;
 функция каждого «черного ящика» должна быть легко понимаема
независимо от сложности ее реализации (например, в системе управления раке-
той может быть «черный ящик» для расчета места ее приземления: несмотря на
сложность алгоритма, функция «черного ящика» очевидна — расчет точки при-
земления);
 связь между «черными ящиками» должна вводиться только при
наличии связи между соответствующими функциями системы (например, в
бухгалтерии один «черный ящик» необходим для расчета общей заработной
платы служащего, а другой — для расчета налогов; необходима связь между
этими «черными ящиками», так как размер заработной платы требуется для
расчета налогов);
 связи между «черными ящиками» должны быть простыми, насколько
это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является
идея иерархии. Для понимаемости сложной системы недостаточно разбиения ее
на части, необходимо эти части организовать определенным образом, а именно
в виде иерархических структур. Все сложные системы Вселенной организованы
в иерархии. Да и сама она включает галактики, звездные системы, планеты, мо-
лекулы, атомы, элементарные частицы.
Человек при создании сложных систем также подражает природе. Любая
организация имеет директора, заместителей по направлениям, иерархию руко-
водителей подразделений, рядовых служащих.
Наконец, третий момент: структурные методы широко используют гра-
фические нотации, также служащие для облегчения понимаемости сложных
систем. Известно, что «одна картинка стоит тысячи слов».
49
 На рисунке 3.2 изображен черноволосый мужчина, одетый в серый ко-
стюм. Он носит очки и т. д. Вообще говоря, нет необходимости комментиро-
вать это: читатель впитывает вышеизложенное описание с первого взгляда.

Рис. 3.2
Пример графического объекта
Однако можно добавить дополнительные подробности, которые не видны
из рисунка. Например, мужчину зовут Борис Борисович, ему 35 лет.
Структурные методы также позволяют дополнить «картинки» любой ин-
формацией, которая не может быть отражена при использовании соответству-
ющей графической нотации.
О преимуществе «картинок» свидетельствует и следующий факт. Едва ли
найдется человек, не читавший рассказ А. П. Чехова «Толстый и тонкий». Тем
не менее, практически никто не обращал внимания на любопытное противоре-
чие в тексте рассказа: «Нафанаил немного подумал и снял шапку … Нафанаил
шаркнул ногой и уронил фуражку». С другой стороны, имея иллюстрации этих
двух сцен, легко обнаружить несоответствие.
Метод декомпозиции модулей предусматривает дальнейшее разбиение
подкомплексов задач на отдельные задачи, показатели. Подход к разбиению
всей совокупности задач по принципу «сверху вниз» особенно удобен для раз-
работки принципиальных организационно-технических решений, внесения в
них, при необходимости, изменений, а также увязки при проектировании хо-
зяйственных и организационно-управленческих целевых установок с конкрет-
ными задачами и показателями.
Анализ и моделирование информационных процессов предназначен для
выявления и представления в каждом случае взаимосвязи между результатом,
процессом обработки и вводом данных. Он используется также для анализа и
формирования информационных связей между рабочими местами работников
управления, специалистов, технического персонала и информационными тех-
нологиями. С этой целью описываются входная и выходная информация, а так-
же алгоритм обработки информации применительно к каждому рабочему ме-
сту. Путем обнаружения и последовательного соединения многочисленных це-
почек обработки и передачи данных формируются сложные информационные
процессы и осуществляется учет потребности в информации отдельных пользо-
вателей.

50
Методы графического представления фактического и заданного
состояний
Методы графического представления фактического и заданного состоя-
ния предусматривают использование для наглядного представления процессов
обработки информации в форме блок-схем, графиков прохождения документов
и т. д. Графические методы являются составной частью любого проекта и необ-
ходимы для практической работы, поскольку играют роль вспомогательного
средства при описании внедрения новых технологий.
К наиболее известным из них относят:
 блок-схемный метод;
 метод стрелочных диаграмм;
 метод сетевых графиков;
 метод таблиц последовательности операций прохождения процессов.
Различия методов выражаются в степени их реализации на ПЭВМ, нагляд-
ности, глубине отражаемых процессов. Некоторые из них мы рассмотрим ниже.

3.2. Разработка технико-экономического обоснования

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

51
ных и количественных характеристик, раскрывающих взаимодействие ее ком-
понентов в процессе функционирования.
В разделе «Описание недостатков существующей информационной си-
стемы» приводят результаты диагностического анализа, при котором оценива-
ют качество функционирования и организационно-технологический уровень
системы, выявляют недостатки в организации и технологии функционирования
информационных процессов и определяют степень их влияния на качество
функционирования системы.
В разделе «Обоснование необходимости совершенствования информаци-
онной системы объекта», при анализе соответствия показателей функциониро-
вания объекта предъявляемым требованиям, оценивают степень соответствия
прогнозируемых показателей требуемым и выявляют необходимость совершен-
ствования информационной системы путем создания АС.
Раздел «Цели, критерии и ограничения создания АС» содержит:
 формулировку производственно-хозяйственных, научно-технических
и экономических целей и критериев создания АС;
 характеристику ограничений по созданию АС.
Раздел «Функции и задачи создаваемой АС» содержит:
 обоснование выбора перечня автоматизированных функций и ком-
плексов задач с указанием очередности внедрения;
 требования к характеристикам реализации функций и задач в соот-
ветствии с действующими нормативно-техническими документами, определя-
ющими общие технические требования к АС конкретного вида;
 дополнительные требования к АС в целом и ее частям, учитывающие
специфику создаваемой АС.
Раздел «Ожидаемые технико-экономические результаты создания АС»
содержит:
 перечень основных источников экономической эффективности полу-
чаемых результатов создания АС (в том числе — экономия производственных
ресурсов, улучшение качества продукции, повышение производительности
труда и т. д.) и оценку ожидаемых изменений основных технико-экономиче-
ских и социальных показателей производственно-хозяйственной деятельности
объекта (например, показателей по номенклатуре и объемам производства, се-
бестоимости продукции, рентабельности, отчислениям в фонды экономическо-
го стимулирования, уровню социального развития);
 оценку ожидаемых затрат на создание и эксплуатацию АС с распреде-
лением их по очередям создания АС.
Раздел «Выводы и предложения» рекомендуется разделять на подразделы:
 выводы о производственно-хозяйственной необходимости и технико-
экономической целесообразности создания АС;
 предложения по совершенствованию организации и технологии про-
цесса деятельности;
 рекомендации по созданию АС.

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

3.3. Разработка технического задания на создание ИС

(ГОСТ 34.602-89)
Техническое задание (ТЗ) — это документ, определяющий задание на
проектирование, создание и внедрение ИС, т. е. все последующие стадии ЖЦ.
Кроме того, ТЗ определяет и устанавливает основные контуры будущей ИС.
Это единственный документ, имеющий две «утверждающие» подписи — За-
казчика и Исполнителя, и он имеет юридическую силу — т. е. на основании не-
го могут вестись рассмотрения в суде и других юридических инстанциях.
Согласно ГОСТ 34.602-89 «Техническое задание на создание автоматизи-
рованной системы», в ТЗ входят следующие основные разделы.
В разделе «Общие сведения о проекте» указывают:
 полное наименование системы;
 код системы;
 код договора;
 наименование предприятия-разработчика и предприятия-заказчика;
 перечень документов, на основе которых создается система;
 плановые сроки начала и окончания работ по созданию системы;
 сведения об источниках финансирования;
 порядок оформления и предъявления заказчику результатов работ по
созданию системы (ее частей).
Раздел описания «Назначение, цели создания системы» состоит из двух
подразделов:
 в подразделе «Назначение системы» даются вид автоматизируемой
деятельности и перечень объектов автоматизации, на которых предполагается
ее использовать;
 в подразделе «Цели создания системы» указываются наименования и
требуемые значения технических, технологических, производственно-
экономических и других показателей объекта автоматизации, которые будут
достигнуты в результате внедрения ЭИС.
В разделе «Характеристика объекта автоматизации» приводятся:
 краткие сведения об объекте автоматизации;
 сведения об условиях эксплуатации объекта и характеристиках окру-
жающей среды.
Раздел «Требования к системе» состоит из следующих подразделов:
 требования к системе в целом;
 требования к функциям (задачам), выполняемым системой;
 требования к видам обеспечения.
В подразделе «Требования к системе в целом» указывают требования:
 к структуре и функционированию системы;
 к численности квалифицированных работников;

54
  к надежности и безопасности работы системы;
 к эргономике и технической эстетике, эксплуатации, техническому
обслуживанию, ремонту системы;
 к защите информации от несанкционированного доступа; к защите от
внешней среды;
 к патентной чистоте проектных решений;
 по сохранности информации при авариях;
 по унификации и стандартизации.
В подразделе «Требования к функциям (задачам), выполняемым систе-
мой», комплексам задач и отдельным задачам приводят по каждой подсистеме:
 перечень функций, задач или их комплексов, подлежащих автомати-
зации;
 их распределение по очередям создания;
 временной регламент реализации каждой функции, задачи или ком-
плекса;
 требования к качеству реализации каждой функции, задачи, комплек-
са, к форме представления выходной информации;
 характеристики необходимой точности и времени выполнения, досто-
верности выдачи результата.
В подразделе «Требования к видам обеспечения» содержатся требования
к математическому, программному, техническому, лингвистическому, инфор-
мационному и методическому обеспечению ЭИС.
Раздел «Состав и содержание работ по созданию системы» должен со-
держать:
 перечень стадий и этапов работ по созданию системы в соответствии с
ГОСТ 34.601-90;
 сроки выполнения;
 перечень организаций-исполнителей;
 перечень документов по ГОСТ 34.201-89 «Виды, комплектность и
обозначение документов при создании автоматизированных систем», предъяв-
ляемых по окончании работ;
 вид и порядок проведения экспертизы технической документации и др.
В разделе «Порядок контроля приемки системы» указывают:
 состав, методы испытания системы и ее частей;
 общие требования к приемке работ по стадиям;
 порядок утверждения приемных документов;
 статус приемочной комиссии.
В разделе «Требования к составу и содержанию работ по подготовке объ-
екта автоматизации к вводу системы в действие» приводится перечень необхо-
димых мероприятий и их исполнителей. К числу мероприятий, которые следует
выполнить при подготовке объекта к вводу ЭИС в действие, относятся:
 приведение информации, поступающей в систему, к виду, пригодному
для ввода в ЭВМ;

55
  создание условий функционирования объекта, при которых гаранти-
руется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
 создание необходимых для функционирования системы подразделе-
ний и служб;
 сроки и порядок комплектования штатов и обучения персонала.
В разделе «Требования к документированию» приводят перечень подле-
жащих разработке комплектов и видов документов, соответствующих требова-
ниям ГОСТ 34.201-89 и научно-технической документации отрасли заказчика.
В разделе «Источники разработки» должны быть перечислены документы
и информационные материалы (ТЭО, отчеты о законченных научно-исследова-
тельских разработках, информационные материалы на отечественные, зарубеж-
ные системы-аналоги и др.).
В состав ТЗ, при наличии утвержденных методик, могут быть также
включены приложения, содержащие расчеты экономической эффективности
системы; оценку научно-технического уровня системы.

3.4. Вопросы для самопроверки

1. Каков состав и содержание методов организации проведения обследования?
2. Какие используются методы сбора материалов обследования и для ка-
ких целей?
3. Перечислите состав вопросов в программе обследования при систем-
ном и локальном подходе к проектированию ЭИС.
4. Каков состав методов формализации материалов обследования?
5. Каков состав документов, предназначенных для формализованного
описания материалов обследования?
6. Каково назначение и каков состав разделов технико-экономического
обоснования?
7. Каково назначение и содержание технического задания?

56
 ТЕМА 4. ПРОЕКТИРОВАНИЕ
ФУНКЦИОНАЛЬНОЙ ЧАСТИ ЭИС
Даже относительно небольшие предприятия являются сложными систе-
мами, поскольку обладают непростой иерархической структурой с многочис-
ленными взаимосвязями между объектом управления и управляющей системой.
В свою очередь, участники процесса управления обычно ставят перед собой
свои цели, которые могут не совпадать с целью системы в целом.
Процесс управления характеризуется многофункциональностью, которая
проявляется в особенностях реализации основных функций управления: учета,
анализа, планирования и регулирования.
Предприятие, как система, в условиях изменения среды сохраняет свой-
ство целостности и обладает такой характеристикой, как эмерджентность.
А управление ориентировано на сохранение своего основного качества, по-
скольку утеря целостности влечет за собой разрушение системы.
В экономических системах управление строится на основе экономико-
организационных моделей, так как управляющая система должна иметь пред-
ставление об образе объекта. И поскольку модель в некоторой форме отражает
реально протекающие процессы, возникает проблема ее адекватности. Модель
всегда отличается деталями от самого объекта, но обязательно имеет с ним не-
что общее. Сравнительно простыми являются функциональные модели, описы-
вающие зависимость выхода от входа, более сложными — структурные модели,
включающие и функциональный, и структурный аспект.
Модели, как системы, могут быть вероятностными и детерминированны-
ми. ЭИС обычно представляет собой детерминированную модель управления,
отражая происходящие процессы через призму своих технологий. Обилие и
разнообразие экономических систем порождает большое количество вариантов
ЭИС: ведь, отражая систему управления, ЭИС таким образом впитывает в себя
особенности структуры управления, схемы декомпозиции управленческих це-
лей, предметных технологий.
Структура ЭИС, как правило, повторяет структуру предприятия, органи-
зации, а функции ЭИС автоматизируют функциональную структуру.

4.1. Декомпозиция функций ЭИС

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

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

58
 Простота проведения испытаний и отладка программ. Прежде чем пла-
нировать испытания и отладку системы в целом, будут проводиться испытания
и отладка отдельных задач. И опять существует проблема сопряжения.
Простота сопровождения. Когда система уже будет эксплуатироваться в
реальных условиях и потребуются ее изменения (принцип постоянного совер-
шенствования), то достаточно изменить лишь те модули, которые имеют отно-
шение к этим изменениям.
Простота эксплуатации. Персоналу, эксплуатирующему систему, проще
представить только ту часть, с которой он связан, и в общем виде — остальное
(например, бухгалтерия: УМЦ и Баланс).
Критерии разбиения системы многочисленны. Однако всегда должны
учитываться следующие:
 размер задачи;
 территориальная распределенность обработки;
 интенсивность изменения данных;
 число сопряжений между задачами;
 функциональная общность.
К сожалению, не существует ни правил, ни универсального метода, кото-
рые позволили бы формально выполнять декомпозицию. Можно сказать: «Не
существует в общем случае разбиения, которое было бы наилучшим, но суще-
ствует несколько разбиений, которые могут быть вполне обоснованными и счи-
таться такими же приемлемыми, как и другие».
Все сказанное относится к проектируемым системам. Если же мы имеем де-
ло с тиражируемыми системами, то здесь проблем функциональной декомпозиции
не существует, так как она уже произведена на этапе разработки системы. И оста-
нется проблема структурно-функционального определения рабочих мест (АРМ).

4.2. Описание постановки задач

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

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

60
 Рис. 4.1
Схема структуры «Постановка задачи»
Организационная сущность задачи — это описание порядка решения зада-
чи; организационной формы, применяемой для ее решения; режима решения; со-
става файлов с постоянной и переменной информацией; способа получения и
ввода первичной информации в ЭВМ; формы выдачи результативной информа-
ции: на печать, на экран, на магнитный носитель или передача по каналам связи.
Описание алгоритма решения задачи включает формализованное описа-
ние входных и результатных показателей, перечень формул расчета результат-
ных показателей в случае решения задачи прямым методом счета или описание
математической модели, экономико-математического метода, применяемого
для ее реализации, и перечня последовательных шагов выполнения расчетов.
Далее указывают периодичность решения задачи и регламент выдачи ре-
зультатных документов, требования к организации сбора исходных данных,
т. е. к способу и техническим средствам съема, регистрации, сбора и передачи
данных для обработки.

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

62
 ТЕМА 5. МЕТОДЫ И СРЕДСТВА
СОВЕРШЕНСТВОВАНИЯ ТЕХНОЛОГИИ
ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ
Главная особенность разработки ИС состоит в концентрации сложности
на начальных этапах ЖЦ (анализ и проектирование). Нерешенные вопросы и
ошибки, допущенные на этапах анализа и проектирования, порождают на по-
следующих этапах трудные, часто неразрешимые проблемы. Как известно,
ошибки на этих этапах в 100–1000 раз дороже исправлять, чем ошибки на этапе
реализации.
Важным моментом является и четкая документированность результатов
первых этапов, так как эта документация (модель) используется на всех этапах
ЖЦ и при создании ИС следующего поколения.
Сложность и трудоемкость этапов анализа и проектирования во многом
связана с взаимопониманием между проектировщиками и представителями за-
казчика.
Системный аналитик (проектировщик), как правило, сталкивается со сле-
дующими взаимосвязанными проблемами (и это является одной из главных
причин их трудоемкости):
 аналитик не всегда располагает исчерпывающей информацией для
оценки требований к системе с точки зрения заказчика;
 заказчик, в свою очередь, не имеет достаточной информации о про-
блеме обработки данных для того, чтобы судить, что выполнимо, а что нет;
 аналитик сталкивается с чрезмерным количеством подробных сведе-
ний как о предметной области, так и о новой системе;
 традиционная (текстовая) спецификация системы из-за объема техни-
ческих терминов часто непонятна заказчику;
 если такая спецификация понятна заказчику, она будет недостаточной
для проектировщиков и программистов, создающих или адаптирующих систему.
Конечно, применение известных аналитических методов снимает отдель-
ные проблемы анализа, однако приемлемое решение совокупности этих про-
блем может быть найдено только путем применения современных методик си-
стемной и программной инженерии, ключевое место среди которых занимают
методологии структурного и объектно-ориентированного анализа.

5.1. Методология структурного анализа

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

63
возможностям человеческого мозга воспринимать определенное количество вза-
имоувязанных объектов, а нижняя выбрана из соображений здравого смысла);
 ограниченный контекст, включающий лишь существенные на каждом
уровне детали;
 использование строгих формальных правил записи;
 последовательное приближение к конечному результату.
Методы структурного анализа позволяют преодолеть сложность больших
систем путем расчленения их на части («черные ящики») и иерархической ор-
ганизации этих «черных ящиков».
Преимущество использования «черных ящиков» заключается в том, что
их пользователю не требуется знать, как они работают, необходимо знать лишь
его входы и выходы, а также его назначение (т. е. функцию, которую он выпол-
няет). В окружающем нас мире «черные ящики» встречаются в большом коли-
честве: магнитофон и телевизор на бытовом уровне, предприятие с позиций
клиента и т. п. (см. описание на с. 63–65).
Соблюдение указанных принципов необходимо при организации работ на
начальных этапах ЖЦ независимо от типа разрабатываемой системы и исполь-
зуемых при этом методологий. Руководство всеми принципами в комплексе
позволяет на более ранних стадиях разработки понять, что будет представлять
собой создаваемая система, обнаружить промахи и недоработки, что, в свою
очередь, облегчит работы на последующих этапах ЖЦ и понизит стоимость
разработки.
Для целей структурного анализа традиционно используются три группы
средств, иллюстрирующих:
 функции, которые система должна выполнять;
 отношения между данными;
 зависящее от времени поведение системы (аспекты реального времени).
Среди многообразия графических нотаций, используемых для решения
перечисленных задач, в методологиях структурного анализа наиболее часто и
эффективно применяются следующие:
 DFD (Data Flow Diagrams) — диаграммы потоков данных совместно
со словарями данных и спецификациями процессов (мини-спецификациями);
 ERD (Entity-Relationship Diagrams) — диаграммы «сущность —
связь»;
 STD (State Transition Diagrams) — диаграммы переходов состояний.
Все они содержат графические и текстовые средства моделирования: пер-
вые — для удобства отображения основных компонент модели, вторые — для
обеспечения точного определения ее компонент и связей.
Классическая DFD показывает внешние по отношению к системе источ-
ники и стоки (адресаты) данных, идентифицирует логические функции (про-
цессы) и группы элементов данных, связывающие одну функцию с другой (по-
токи), а также идентифицирует хранилища (накопители) данных, к которым
осуществляется доступ. Структура потоков данных и определение их компо-
нент хранятся и анализируются в словаре данных. Каждая логическая функция

64
(процесс) может быть детализирована с помощью DFD нижнего уровня; когда
дальнейшая детализация перестает быть полезной, переходят к выражению ло-
гики функции при помощи спецификации процесса (мини-спецификации).
Содержимое каждого хранилища также сохраняют в словаре данных, мо-
дель данных хранилища раскрывается с помощью ERD. В случае наличия ре-
ального времени DFD дополняется средствами описания зависящего от време-
ни поведения системы, раскрывающимися с помощью STD. Эти взаимосвязи
показаны на рисунке 5.1.

Рис. 5.1
Взаимосвязи составляющих модели DFD
Необходимо отметить, что для функционального моделирования наряду с
DFD достаточно часто применяется и другая нотация — SADT (точнее, ее стан-
дартизированное подмножество IDEF0). Сравнительный анализ этих двух под-
ходов к моделированию функций системы будет приведен ниже.
Таким образом, перечисленные средства позволяют сделать полное опи-
сание системы независимо от того, является ли она существующей или разраба-
тываемой с нуля. Такое подробное описание того, что должна делать система,
освобожденное насколько это возможно от рассмотрения путей реализации,
получило название спецификации требований, дающей проектировщику, реа-
лизующему следующий этап ЖЦ, четкое представление о конечных результа-
тах, которые должны быть достигнуты.
Диаграммы потоков данных
Диаграммы потоков данных известны очень давно. В фольклоре упоми-
нается следующий пример использования DFD для организации переполненно-
го клерками офиса, относящийся к 1920-м гг. Осуществляющий реорганизацию
консультант обозначил кружком каждого клерка, а стрелкой — каждый доку-
мент, передаваемый между ними. Используя такую диаграмму, он предложил
схему реорганизации, в соответствии с которой двое клерков, обменивающиеся
множеством документов, были посажены рядом, а клерки с малым взаимодей-

65
ствием были посажены на большом расстоянии. Так родилась первая модель,
представляющая собой потоковую диаграмму — предвестник DFD.
Для изображения DFD традиционно используются две различные нота-
ции: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении
примеров мы будем использовать нотацию Йодана, все исключения будут
предварительно оговариваться.
Основные символы DFD изображены на рисунке 5.2. Опишем их назна-
чение. На диаграммах функциональные требования представляются с помощью
процессов и хранилищ, связанных потоками данных.
Потоки данных являются механизмами, использующимися для моделиро-
вания передачи информации (или даже физических компонент) из одной части
системы в другую. Важность этого объекта очевидна: он дает название целому
инструменту. Потоки на диаграммах обычно изображаются именованными
стрелками, ориентация которых указывает направление движения информации.
Иногда информация может двигаться в одном направлении, обрабатываться и
возвращаться назад в ее источник. Такая ситуация может моделироваться либо
двумя различными потоками, либо одним — двунаправленным.

Рис. 5.2
Основные символы DFD
Назначение процесса состоит в продуцировании выходных потоков из
входных в соответствии с действием, задаваемым именем процесса. Это имя
должно содержать глагол в неопределенной форме с последующим дополнени-

66
ем (например, вычислить максимальную высоту). Кроме того, каждый процесс
должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот
номер может использоваться совместно с номером диаграммы для получения
уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на определенных участках
определять данные, которые будут сохраняться в памяти между процессами.
Фактически хранилище представляет «срезы» потоков данных во времени. Ин-
формация, которую оно содержит, может использоваться в любое время после
ее определения, при этом данные могут выбираться в любом порядке. Имя хра-
нилища должно идентифицировать его содержимое и быть существительным.
В случае, когда поток данных входит или выходит в/из хранилища и его струк-
тура соответствует структуре хранилища, он должен иметь то же самое имя, ко-
торое нет необходимости отражать на диаграмме.
Внешняя сущность (или терминатор) представляет сущность вне контек-
ста системы, являющуюся источником или приемником системы данных. Ее
имя должно содержать существительное, например склад товаров. Предполага-
ется, что объекты, представленные такими узлами, не должны участвовать ни в
какой обработке.
Контекстная диаграмма и детализация процессов
Декомпозиция DFD осуществляется на основе процессов: каждый про-
цесс может раскрываться с помощью DFD нижнего уровня.
Важную специфическую роль в модели играет специальный вид DFD —
контекстная диаграмма, моделирующая систему наиболее общим образом.
Контекстная диаграмма отражает интерфейс системы с внешним миром, а
именно информационные потоки между системой и внешними сущностями, с
которыми она должна быть связана. Она идентифицирует эти внешние сущно-
сти, а также, как правило, единственный процесс, отражающий главную цель
или природу системы насколько это возможно. И хотя контекстная диаграмма
выглядит тривиальной, несомненная ее полезность заключается в том, что она
устанавливает границы анализируемой системы. Каждый процесс должен
иметь ровно одну контекстную диаграмму, при этом нет необходимости в ну-
мерации единственного ее процесса.
DFD первого уровня строится как декомпозиция процесса, который при-
сутствует на контекстной диаграмме.
Построенная диаграмма первого уровня также имеет множество процес-
сов, которые в свою очередь могут быть декомпозированы в DFD нижнего
уровня. Таким образом, строится иерархия DFD с контекстной диаграммой в
корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока про-
цессы могут быть эффективно описаны с помощью коротких (до одной страни-
цы) мини-спецификаций обработки (спецификаций процессов).
При таком построении иерархии DFD каждый процесс более низкого
уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой
цели используются структурированные номера процессов. Так, например, если
мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его
67
с помощью DFD, содержащей три процесса, то их номера будут иметь следую-
щий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уро-
вень, т. е. для процесса 2.2 получим 2.2.1, и т. д.
Пример банковской задачи
В качестве примера создания модели рассмотрим фрагмент проекта си-
стемы, организующей работу банкомата по обслуживанию клиента по его кре-
дитной карте. Этот пример будет строиться поэтапно, на нем мы продемон-
стрируем базовые техники структурного анализа и проектирования по мере их
определения.
На рисунке 5.3 приведена контекстная диаграмма системы с единствен-
ным процессом ОБСЛУЖИТЬ, идентифицирующая внешние сущности КЛИ-
ЕНТ и КОМПЬЮТЕР БАНКА, хранящий информацию о счетах всех клиентов.
Опишем потоки данных, которыми обменивается проектируемая система с
внешними объектами.

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

68
 Контекстный процесс и компьютер банка должны обмениваться следую-
щей информацией:
 данные по счету клиента в банке;
 протокол обслуживания, включающий информацию об обработан-
ной документации, изымаемой денежной сумме и данные по истории запроса.
Контекстный процесс может быть детализирован DFD первого уровня,
как показано на рисунке 5.4.

Рис. 5.4
Первый уровень детализации процесса
Эта диаграмма содержит 4 процесса и хранилище данные кредитной
карты, которое изображено дважды на диаграмме с целью избежания пересе-
чений линий потоков данных.
Процесс 1.1 (получить пароль) осуществляет прием и проверку пароля
клиента и имеет на входе/выходе следующие потоки:
 внешний выходной поток сообщение для информирования клиента о
своей готовности принять пароль;
 входной поток введенный пароль как элемент внешнего потока ключе-
вые данные;
 входной поток пароль из хранилища, данные кредитной карты для
проверки вводимого клиентом пароля.
Процесс 1.2 (получить запрос на обслуживание) осуществляет прием и
проверку запроса клиента на проведение необходимой ему банковской опера-
ции и имеет на входе/выходе следующие потоки:
 внешний выходной поток сообщение для информирования клиента о
своей готовности принять запрос на обслуживание;

69
  входной поток запрос на обслуживание как элемент внешнего потока
ключевые данные;
 входной поток лимит денег из хранилища, данные кредитной карты
для контроля наличия денег на счете клиента.
Процесс 1.3 (обработать запрос на обслуживание) имеет внешний вход-
ной поток данные по счету (из внешней сущности компьютер банка), входной
поток детали клиента (из хранилища), а также внешние выходные потоки вы-
писка, деньги и протокол обслуживания.
Процесс 1.4 (обработать кредитную карту) осуществляет считывание ин-
формации с кредитной карты и имеет на входе внешний поток кредитная кар-
та, а на выходе поток данные кредитной карты. Отметим, что нет необходи-
мости в идентификации последнего потока, так как идентифицировано соответ-
ствующее хранилище.
Процессы 1.1, 1.2 и 1.4 являются элементарными, поэтому нет необходи-
мости в их детализации с помощью DFD уровня 2. Процесс 1.3 может быть де-
тализирован с помощью DFD второго уровня, как показано на рисунке 5.5. Эта
диаграмма содержит 4 элементарных процесса.
Процесс 1.3.1 (обработать документацию банка) осуществляет обработку
внутренней банковской документации по клиенту и имеет входной поток дета-
ли клиента и выходной поток обработанная документация (часть внешнего
потока протокол обслуживания).
Процесс 1.3.2 (распечатать баланс клиента) выдает справку по истории
счета клиента и по балансу клиента. Входные данные — детали клиента и дан-
ные по балансу (часть внешнего потока данные по счету), выходные потоки —
выписка по балансу (часть внешнего потока выписка) и данные по истории за-
проса (часть внешнего потока протокол обслуживания).
Процесс 1.3.3 (приготовить деньги клиенту) обеспечивает выдачу налич-
ных денег и информирование компьютера банка об изъятии из банка денег. Он
имеет входные потоки денежная сумма и детали клиента и выходные потоки
деньги и денежная сумма (часть потока протокол обслуживания).
Процесс 1.3.4 (распечатать операцию клиента) выдает справку по истории
счета и уведомление по проведенной операции. Входные потоки — данные по
счету и детали клиента, выходные потоки — выписка по операции (часть по-
тока выписка) и данные по истории запроса (часть потока протокол обслужи-
вания).
Расширения реального времени
Расширения реального времени используются для дополнения модели
функционирования данных (иерархия DFD) средствами описания управляющих
аспектов в системах реального времени. Для этих целей применяются следую-
щие символы (рис. 5.6).
Управляющий процесс. Представляет собой интерфейс между DFD и
спецификациями управления, собственно моделирующими и документирую-
щими аспекты реального времени. Его имя указывает на тип управляющей дея-
тельности, вырабатываемой спецификацией. Фактически управляющий процесс
70
представляет собой преобразователь входных управляющих потоков в выход-
ные управляющие потоки. При этом точное описание этого преобразования
должно задаваться в спецификации управления.

Рис. 5.5
Второй уровень детализации процесса

Компонента Нотация Йодана Нотация Гейна-Сарсона

Управляющий поток имя имя

Управляющий процесс
имя номер

номер имя

Управляющее хранилище
имя
имя
имя

Рис. 5.6
Компоненты управляющего процесса
Управляющее хранилище. Представляет «срез» управляющего потока во
времени. Содержащаяся в нем управляющая информация может использоваться
в любое время после занесения ее в хранилище, при этом соответствующие
данные могут быть использованы в произвольном порядке. Имя управляющего
71
хранилища должно идентифицировать его содержимое и быть существитель-
ным. Управляющее хранилище отличается от традиционного тем, что может
содержать только управляющие потоки; все другие их характеристики иден-
тичны.
Управляющий поток. Представляет собой «трубопровод», через кото-
рый проходит управляющая информация. Его имя не должно содержать глаго-
лов, только существительные и прилагательные. Обычно управляющий поток
имеет дискретное, а не непрерывное значение. Это может быть, например, сиг-
нал, представляющий состояние или вид операции.
Логически управляющий процесс есть некий командный пункт, реагиру-
ющий на изменения внешних условий, передаваемые ему с помощью управля-
ющих потоков, и продуцирующий в соответствии со своей внутренней логикой
выполняемые процессами команды. При этом режим выполнения процесса за-
висит от типа управляющего потока.
Имеются следующие типы управляющих потоков.
а) Т-поток (trigger flow). Является потоком управления процессом, кото-
рый может вызвать выполнение процесса. При этом процесс как бы включается
одной короткой операцией. Это аналог выключателя света, единственным
нажатием которого «запускается» процесс горения лампы;
б) А-поток (activator flow). Является потоком управления процессом, ко-
торый может изменять выполнение отдельного процесса. Используется для
обеспечения непрерывности выполнения до тех пор, пока поток «включен»
(то есть течет непрерывно), с «выключением» потока выполнение процесса за-
вершается. Это — аналог переключателя лампы, которая может быть как вклю-
чена, так и выключена;
в) E/D-поток (enable/disable flow). Является потоком управления процес-
сом, который может переключать выполнение отдельного процесса. Течение по
Е-линии вызывает выполнение процесса, которое продолжается до тех пор, по-
ка не возбуждается течение по D-линии. Это аналог выключателя с двумя
кнопками: одна — для включения света, другая — для его выключения. Отме-
тим, что можно использовать 3 типа таких потоков: Е-поток, D-поток, E/D-
поток.
Иногда возникает необходимость в представлении одного и того же
фрагмента данных потоками различных типов. Например, поток данных ско-
рость машины в отдельных случаях может использоваться как управляющий
для контроля критического значения. Для обеспечения этого используется узел
изменения типа (рис. 5.7), поток данных является входным для этого узла, а
управляющий поток — выходным.
Дополним модель банковской системы, введя в диаграммы управляющий
процесс и управляющие потоки, позволяющие описать ее функционирование в
реальном времени. После такого расширения DFD будут выглядеть следующим
образом (рис. 5.8).
Управляющий процесс 1.5 (управление обслуживанием), получив инфор-
мацию о том, что кредитная карта введена (поток введенная кредитная карта),
вызывает выполнение процесса 1.1 (поток А получить пароль). Получив ин-
72
формацию о введенном пароле (поток корректный пароль), процесс 1.5 инфор-
мирует процесс 1.4 о необходимости удаления кредитной карты (поток удален-
ная кредитная карта) и с помощью потока Т обеспечить требуемое обслужи-
вание вызывает выполнение процесса 1.2, затем процесса 1.3 (поток требуемое
обслуживание).

Рис. 5.7
Узел изменения типа

Рис. 5.8
Расширение диаграммы, детализирующей контекстный процесс
Словарь данных
Для описания деталей компонент диаграммы потоков данных, а именно:
какая информация преобразуется процессами — используется словарь данных.
Он представляет собой определенным образом организованный список
всех элементов данных системы с их точными определениями.
Например,
@ имя = введенная кредитная карта;
@ тип = управляющий поток и т. д.
Методы задания спецификаций процессов
Спецификация процесса (СП) используется для описания функциониро-
вания процесса в случае отсутствия необходимости детализировать его с по-

73
мощью DFD (т. е. если он достаточно невелик, и его описание может занимать
до одной страницы текста). Фактически СП представляет собой алгоритмы
описания задач, выполняемых процессами: множество всех СП является полной
спецификацией системы. СП содержит номер и/или имя процесса, списки вход-
ных и выходных данных и тело (описание) процесса, являющееся специфика-
цией алгоритма или операции, трансформирующей потоки данных в выходные.
Известно большое число разнообразных методов, позволяющих задать
тело процесса, соответствующий язык может варьироваться от структуриро-
ванного естественного языка или псевдокода до визуальных языков проектиро-
вания (типа FLOW-форм и диаграмм Насси-Шнейдермана) и формальных ком-
пьютерных языков.
Методология функционального моделирования SADT
Методология SADT разработана Дугласом Россом. На ее основе разрабо-
тана, в частности, известная методология IDEF0 (Icam DEFinition), которая яв-
ляется основной частью программы ICAM (Интеграция компьютерных и про-
мышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и
процедур, предназначенных для построения функциональной модели объекта
какой-либо предметной области. Функциональная модель SADT отображает
функциональную структуру объекта, т. е. производимые им действия и связи
между этими действиями. Основные элементы этой методологии основываются
на следующих концепциях.
Графическое представление блочного моделирования. Графика блоков и
дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы вхо-
да/выхода представляются дугами, соответственно входящими в блок и выходя-
щими из него. Взаимодействие блоков друг с другом описываются посредством
интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, опре-
деляют, когда и каким образом функции выполняются и управляются.
Строгость и точность. Выполнение правил SADT требует достаточной
строгости и точности, не накладывая в то же время чрезмерных ограничений на
действия аналитика.
Правила SADT включают:
 ограничение количества блоков на каждом уровне декомпозиции
(правило 3–6 блоков);
 связность диаграмм (номера блоков);
 уникальность меток и наименований (отсутствие повторяющихся
имен);
 синтаксические правила для графики (блоков и дуг);
 разделение входов и управлений (правило определения роли данных);
 отделение организации от функции, т. е. исключение влияния органи-
зационной структуры на функциональную модель.
Состав функциональной модели
Результатом применения методологии SADT является модель, которая
состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг
74
на друга. Диаграммы — главные компоненты модели, все функции ИС и ин-
терфейсы на них представлены как блоки и дуги. Место соединения дуги с бло-
ком определяет тип интерфейса. Управляющая информация входит в блок
сверху, в то время как информация, которая подвергается обработке, показана с
левой стороны блока, а результаты выхода — с правой стороны. Механизм (че-
ловек или автоматизированная система), который осуществляет операцию,
представляется дугой, входящей в блок снизу (рис. 5.9).

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

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

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

Рис. 5.11
Одновременное выполнение

Рис. 5.12
Соответствие родительской и детализующей диаграмм
Как было отмечено, механизмы (дуги с нижней стороны) показывают
средства, с помощью которых осуществляется выполнение функций. Механизм
может быть человеком, компьютером или любым другим устройством, которое
помогает выполнять данную функцию (рис. 5.14).
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы
может быть далее описан диаграммой нижнего уровня, которая, в свою оче-
редь, может быть далее детализирована с помощью необходимого числа диа-
грамм. Таким образом, формируется иерархия диаграмм.
Для того чтобы указать положение любой диаграммы или блока в иерар-
хии, используются номера диаграмм. Например, А12 является диаграммой, ко-
торая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует
77
блок 2 на диаграмме А0, которая является самой верхней диаграммой модели.
На рисунке 5.15 показано типичное дерево диаграмм.

Рис. 5.13
Пример обратной связи

Рис. 5.14
Пример механизма
Дальнейшее развитие методология SADT получила в структурах ВВС
США, которые достаточно широко используются разработчиками ИС в других
областях. Кроме IDEF0, это IDEF1, IDEF1Х и IDEF3.
Стандарт IDEF1 был разработан как инструмент для анализа и изучения
взаимосвязей между информационными потоками в рамках коммерческой дея-
тельности предприятия. Целью подобного исследования является дополнение и
структуризация существующей информации и обеспечение качественного ме-
неджмента информационными потоками. Необходимость в подобной реоргани-
зации информационной области, как правило, возникает на начальном этапе по-
строения корпоративной информационной системы, и методология IDEF1 как
инструмент построения наглядной модели информационной структуры пред-
приятия по принципу «как должно быть» позволяет решить следующие задачи:
 выяснить структуру и содержание существующих потоков информа-
ции на предприятии;
 определить, какие проблемы, выявленные в результате функциональ-
ного анализа и анализа потребностей, вызваны недостатком управления соот-
ветствующей информацией;
78
  выявить информационные потоки, требующие дополнительного управ-
ления для эффективной реализации модели.

Рис. 5.15
Иерархия диаграмм
С помощью IDEF1 происходит изучение существующей информации о
различных объектах в области деятельности предприятия. Характерно то, что
IDEF1-модель включает в рассмотрение не только автоматизированные компо-
ненты, базы данных и соответствующую им информацию, но и реальные объ-
екты, такие как сами сотрудники, кабинеты, телефоны и т. д.
Миссия методологии IDEF1 состоит в том, чтобы выявить и четко посту-
лировать потребности в информационном менеджменте в рамках коммерческой
деятельности предприятия. В отличие от методов разработки структур баз дан-
ных (например, IDEF1Х), IDEF1 является аналитическим методом и использу-
ется преимущественно для выполнения следующих действий:
 определение самой информации и структуры ее потоков, имеющей
отношение к деятельности предприятия;
 определение существующих правил и законов, по которым осуществ-
ляется движение информационных потоков, а также принципов управления ими;
 выяснение взаимосвязей между существующими информационными
потоками в рамках предприятия;
 выявление проблем, возникающих вследствие недостатка качествен-
ного информационного менеджмента.
Результаты анализа информационных потоков могут быть использованы
для стратегического и тактического планирования деятельности предприятия и
улучшения информационного менеджмента.
Предназначение IDEF1Х
IDEF1Х является методом для разработки баз данных и использует
условный синтаксис, специально разработанный для удобного построения кон-

79
цептуальной схемы. Концептуальной схемой мы называем универсальное пред-
ставление структуры данных в рамках коммерческого предприятия, независи-
мое от конечной реализации базы данных и аппаратной платформы. Будучи
статическим методом разработки, IDEF1Х изначально не предназначен для ди-
намического анализа по принципу «AS IS», тем не менее, он иногда применяет-
ся в этом качестве, как альтернатива методу IDEF1. Использование метода
IDEF1Х наиболее целесообразно для построения логической структуры базы
данных после того, как все информационные ресурсы исследованы (скажем, с
помощью метода IDEF1) и решение о внедрении реляционной базы данных как
части корпоративной информационной системы было принято.
Хотя терминология IDEF1Х практически совпадает с терминологией
IDEF1, существует ряд фундаментальных отличий в теоретических концепциях
этих методологий. Сущность IDEF1Х описывает собой совокупность или набор
экземпляров, похожих по свойствам, но однозначно отличаемых друг от друга
по одному или нескольким признакам. Каждый экземпляр является реализаци-
ей сущности. Таким образом, сущность IDEF1Х описывает конкретный набор
экземпляров реального мира, в отличие от сущности IDEF1, которая представ-
ляет собой абстрактный набор информационных отображений реального мира.
Примером сущности IDEF1Х может быть сущность СОТРУДНИК, кото-
рая представляет собой всех сотрудников предприятия, а один из них, скажем,
Иванов Петр Сергеевич, является конкретной реализацией этой сущности.
В примере, приведенном на рисунке 5.16, каждый экземпляр сущности
СОТРУДНИК содержит следующую информацию: ID сотрудника, имя сотруд-
ника, адрес сотрудника и т. п. В IDEF1Х-модели эти свойства называются атри-
бутами сущности. Каждый атрибут содержит только часть информации о сущ-
ности.

Рис. 5.16
Пример связи «Сотрудник — отдел»
Связи в IDEF1Х представляют собой ссылки, соединения и ассоциации
между сущностями. Связи — это глаголы, которые показывают, как соотносят-
ся сущности между собой.
80
 Основным преимуществом IDEF1Х, по сравнению с другими многочис-
ленными методами разработки реляционных баз данных, такими как ER и
ENALIM, является жесткая и строгая стандартизация моделирования. Установ-
ленные стандарты позволяют избежать различной трактовки построенной мо-
дели, которая, несомненно, является значительным недостатком ER.
Предназначение IDEF3
IDEF3 является стандартом документирования технологических процес-
сов, происходящих на предприятии, и предоставляет инструментарий для
наглядного исследования и моделирования их сценариев. Сценарием (Scenario)
называется описание последовательности изменения свойств объекта в рамках
рассматриваемого процесса (например, описание последовательности этапов
обработки детали в цехе и изменение ее свойств после прохождения каждого
этапа). Исследование каждого сценария сопровождается соответствующим до-
кументооборотом, который состоит из двух основных потоков: документов,
определяющих структуру и последовательность процесса (технологических
указаний, описаний стандартов и т. д.), и документов, отображающих ход его
выполнения (результатов тестов и экспертиз, отчетов о браке и т. д.).
Для эффективного управления любым процессом необходимо иметь де-
тальное представление о его сценарии и структуре сопутствующего документо-
оборота.
Средства документирования и моделирования IDEF3 позволяют выпол-
нять следующие задачи:
 документировать имеющиеся данные о технологии процесса, выяв-
ленные, скажем, в процессе опроса компетентных сотрудников, ответственных
за организацию рассматриваемого процесса;
 определять и анализировать точки влияния потоков сопутствующего
документооборота на сценарий технологических процессов;
 определять ситуации, в которых требуется принятие решения, влия-
ющего на жизненный цикл процесса, например, изменение конструктивных,
технологических или эксплуатационных свойств конечного продукта;
 содействовать принятию оптимальных решений при реорганизации
технологических процессов;
 разрабатывать имитационные модели технологических процессов по
принципу «как будет, если…».
На следующем примере опишем, как графические средства IDEF3 позво-
ляют документировать процесс окраски детали. В целом этот процесс состоит,
непосредственно, из самой окраски, производимой на специальном оборудова-
нии, и этапа контроля ее качества, который определяет, нужно ли деталь окра-
сить заново (в случае несоответствия стандартам и выявления брака) или от-
править ее в дальнейшую обработку.
На рисунке 5.17 изображена диаграмма, являющаяся графическим отоб-
ражением сценария обработки детали.
Прямоугольники на диаграмме называются функциональными элемента-
ми, или элементами поведения (Unit of Behavior, UOB), и обозначают событие,

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

Рис. 5.17
Пример модели в IDEF3
Сценарий, отображаемый на диаграмме, можно описать в следующем ви-
де: деталь поступает в окрасочный цех, подготовленный к окраске. В процессе
окраски наносится один слой эмали при высокой температуре. После этого
производится сушка детали, после которой начинается этап проверки качества
нанесенного слоя. Если тест подтверждает недостаточное качество нанесенного
слоя (недостаточную толщину, неоднородность и т. д.), то деталь заново про-
пускается через цех окраски. Если деталь успешно проходит контроль качества,
то она отправляется в следующий цех для дальнейшей обработки.
Сравнительный анализ методологий DFD и SADT
Методы структурного анализа могут быть разбиты на две группы: приме-
няющие методы и технологии DFD (в различных нотациях) и использующие
SADT-методологию. По материалам наиболее авторитетной в рассматриваемой
области исследовательской компании CASE Consulting Group соотношение
применения этих двух разновидностей структурного анализа на практике со-
ставляет 90% для DFD и 10% для SADT.
Предваряя сравнительный анализ DFD- и SADT-подходов, в качестве
примера рассмотрим верхний уровень модели требований к системе автомати-
зации управления компанией, занимающейся распределением товаров по зака-
зам (рис. 5.19 и 5.18 соответственно).
Заказы подвергаются входному контролю и сортировке. Если заказ не от-
вечает номенклатуре товаров или оформлен неправильно, то он аннулируется с
соответствующим уведомлением заказчика. Если заказ не аннулируется, то
определяется, имеется ли на складе соответствующий товар. В случае положи-
тельного ответа выписывается и предъявляется заказчику счет к оплате. Если
заказ не обеспечен складскими запасами, то производителю отправляется заяв-
ка на товар. После поступления требуемого товара на склад компании заказ
становится обеспеченным, и повторяется вышеописанный маршрут.
Сравнительный анализ этих двух разновидностей методологий проводит-
ся по следующим параметрам:

82
  адекватность средств рассматриваемой проблеме;
 согласованность с другими средствами структурного анализа;
 интеграция с последующими этапами разработки (и прежде всего с
этапом проектирования).
Адекватность. Выбор той или иной структурной методологии напрямую
зависит от предметной области, для которой создается модель. В нашем случае
методологии применяются к автоматизированным системам управления пред-
приятием, а не к системам вообще, как это предполагается в SADT. Для рас-
сматриваемых задач DFD вне конкуренции.
Во-первых, SADT-диаграммы значительно менее выразительны и удобны
для моделирования ИС (сравните рис. 5.19 и 5.18). Так, дуги в SADT жестко
типизированы (вход, выход, управление, механизм). В то же время примени-
тельно к ИС стирается смысловое различие между входами и выходами, с од-
ной стороны, и управлениями и механизмами, с другой: входы, выходы, меха-
низмы и управления являются потоками данных и/или управления и правилами
их трансформации. Анализ системы при помощи потоков данных и процессов,
их преобразующих, является более прозрачным и недвусмысленным.

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

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

Рис. 5.19
Модель работы с клиентами в DFD
Согласованность. Главным достоинством любых моделей является воз-
можность их интеграции с моделями других типов. В данном случае речь идет
о согласованности функциональных моделей со средствами информационного
и событийного (временного) моделирования.
Согласование SADT-модели с ERD и/или STD практически невозможно
или носит тривиальный характер. В свою очередь, DFD, ERD и STD взаимно
дополняют друг друга и, по сути, являются согласованными представлениями
различных аспектов одной и той же модели.
В таблице 5.1 отражена возможность такой интеграции для DFD- и
SADT-моделей.
Отметим, что интеграция DFD-STD осуществляется за счет расширения
классической DFD специальными средствами проектирования систем реально-
го времени (управляющими процессами, потоками, хранилищами данных), и
STD является детализацией управляющего процесса, согласованной по управ-
84
ляющим потокам и хранилищам. Интеграция DFD-ERD осуществляется с ис-
пользованием отсутствующего в SADT объекта — хранилища данных, структу-
ра которого описывается с помощью ERD и согласуется по соответствующим
потокам и другим хранилищам на DFD.
Таблица 5.1
Интеграция DFD- и SADT-моделей с ERD STD
Название ERD STD
DFD + +
SADT + –
Необходимо отметить, что рассмотренные разновидности структурного
анализа, по сути, — два приблизительно одинаковых по мощности языка для
передачи понимания. И одним из основных критериев выбора является следу-
ющий: насколько хорошо каждым их этих языков владеет консультант или ана-
литик.
Характеристика хорошей модели реализации
Один из фундаментальных принципов структурного проектирования за-
ключается в том, что большая система должна быть расчленена на обозримые
модули. При этом существенным является то, что это расчленение должно быть
выполнено таким образом, чтобы модули были как можно более независимы
(критерий сцепления — coupling), и чтобы каждый модуль выполнял един-
ственную (связанную с общей задачей) функцию (критерий связности —
cohesion). Кроме этих двух взаимно дополняющих друг друга критериев в
структурном проектировании существует целый ряд других руководящих
принципов, которые могут применяться для оценки и улучшения качества про-
екта на основании структурных карт.
Сцепление
Одним из способов оценки качества модели реализации является анализ
сцепления модулей. Сцепление — это мера взаимозависимости модулей.
В хорошем проекте сцепления должны быть минимизированы, т. е. модули
должны быть слабозависимыми (независимыми) настолько, насколько это воз-
можно.
Слабое сцепление между модулями служит признаком хорошо спроекти-
рованной системы по следующим причинам:
 уменьшается количество соединений между двумя модулями, что
приводит к уменьшению вероятности появления «волнового эффекта» (ошибка
в одном модуле влияет на работу других моделей);
 минимизируется риск появления «эффекта ряби» (внесение измене-
ний, например, при исправлении ошибки, приводит к появлению новых оши-
бок), так как изменение влияет на минимальное количество модулей;
 при сопровождении модуля отпадает необходимость беспокоиться о
внутренних деталях других модулей;
 система упрощается для понимания настолько, насколько это возможно.

85
 На практике существуют три основных типа сцепления, используемых
системными проектировщиками для связи модулей:
 нормальное сцепление;
 сцепление по общей области;
 сцепление по содержимому.
С позиций структурного проектирования эти типы являются соответ-
ственно приемлемыми, неприемлемыми и запрещенными.
Два модуля A и B нормально сцеплены, если:
 А вызывает В;
 В возвращает управление А;
 вся информация, передаваемая между А и В, представляется значени-
ями параметров при вызове.
1. Нормальное сцепление, в свою очередь, делится на три типа:
 сцепление по данным;
 сцепление по образцу;
 сцепление по управлению.
На практике наиболее часто используется сцепление по данным.
Два модуля сцеплены по данным, если они взаимодействуют через пере-
дачу параметров и при этом каждый параметр является элементарным инфор-
мационным объектом. Отметим, что в случае небольшого количества передава-
емых параметров сцепление по данным обладает наилучшими характеристи-
ками.
Два модуля сцеплены по образцу, если один посылает другому составной
информационный объект, т. е. объект, имеющий внутреннюю структуру. При-
мером составного объекта может быть объект Данные о клиенте, включающий
поля: Название организации, Почтовый адрес, Номер счета и т. д.
Два модуля сцеплены по управлению, если один посылает другому ин-
формационный объект — флаг, предназначенный для управления его внутрен-
ней логикой. Существует два типа флагов — описательный и управляющий.
Описательный флаг обычно описывает ситуацию, которая произошла, и имену-
ется с использованием существительных и прилагательных: Конец файла, Вве-
денная кредитная карта. Управляющий флаг используется для декларирования
определенных действий в вызываемом модуле и именуется с использованием
глаголов: Читать следующую запись, Установить в начало. В общем случае
управляющие флаги усиливают сцепление и, следовательно, ухудшают каче-
ство проекта.
2. Два модуля сцеплены по общей области, если они ссылаются к одной
и той же области глобальных данных. Сцепление по общей области является
плохим по следующим причинам. Во-первых, ошибка в одном модуле, исполь-
зующем глобальную область, может неожиданно проявить себя в любом дру-
гом модуле, также использующем эту глобальную область, поскольку эти гло-
бальные данные не находятся «под защитой» модуля. Во-вторых, модули, ссы-
лающиеся к глобальным данным, обычно используют точные имена (в отличие
от модулей, которые вызываются с использованием параметров). Следователь-

86
но, гибкость модулей, сцепленных по области глобальных данных, намного
хуже, чем гибкость нормально сцепленных модулей. В-третьих, программы с
большим количеством глобальных данных чрезвычайно трудны для понимания
сопровождающим программистом, поскольку сложно определить, какие дан-
ные используются отдельным модулем.
3. Два модуля сцеплены по содержимому, если один ссылается внутрь
другого любым способом, например, если один модуль передает управление или
выполняет переход в другой модуль, если один модуль ссылается или изменяет
значения информационных объектов в другом модуле или если один модуль из-
меняет код другого модуля. Такое сцепление делает абсурдным концепцию мо-
дулей как черных ящиков, поскольку оно вынуждает один модуль знать о точ-
ном содержании и реализации другого модуля. Вообще говоря, только ассемблер
позволяет проектировщикам применять данный вид сцепления.
В таблице 5.2 приведены сравнительные характеристики по каждому ти-
пу сцепления.
Таблица 5.2
Сравнительные характеристики по типам сцепления
Устойчивость Используе-
Тип Модифициру-
к волновому Понятность мость в других
сцепления емость
эффекту системах
По данным * хорошая хорошая хорошая
По образцу * средняя средняя средняя
По управлению средняя плохая плохая плохая
По общей области плохая средняя плохая плохая
По содержимому плохая плохая плохая плохая
Примечание. * зависит от количества параметров интерфейса.
Связанность
Другим критерием оценки качества разбиения системы на части является
критерий связанности, который контролирует, как действия в одном модуле
связаны друг с другом. Фактически сцепление и связанность являются двумя
взаимозависимыми способами измерения расчленения системы на части: свя-
занность модуля часто определяет качество его сцепления с другими модулями.
Связанность — это мера прочности соединения функциональных и ин-
формационных объектов внутри одного модуля. Размещение сильно связанных
объектов в одном и том же модуле уменьшает межмодульные взаимосвязи и
взаимовлияния.
Выделяются следующие связанности: функциональная, последователь-
ная, информационная, процедурная, временная, логическая, случайная.
а) функционально связанный модуль содержит объекты, предназначенные
для выполнения одной и только одной задачи, например: Расчет заработной
платы, Считывание данных кредитной карты. Каждый из таких модулей име-
ет одну четко определенную цель, при его вызове выполняется только одна за-
дача (при этом она выполняется полностью без исполнения любого другого до-
полнительного действия);

87
 б) последовательно связанный модуль содержит объекты, охватывающие
подзадачи, для которых выходные данные предыдущей подзадачи служат
входными данными для последующей, например: Открыть файл — Прочи-
тать запись — Закрыть файл;
в) информационно связанный модуль содержит объекты, использующие
одни и те же входные или выходные данные. Предположим, что мы хотим вы-
яснить некоторые сведения о книге, зная ее ISBN: название книги, автора и це-
ну. Эти три подзадачи являются связанными потому, что все они работают с
одним и тем же входным информационным объектом — ISBN, который и дела-
ет этот модуль информационно связным;
г) процедурно связанный модуль содержит объекты, которые включены в
различные (возможно, несвязанные) подзадачи, в которых управление перехо-
дит от каждой подзадачи к последующей (отметим, что в последовательно свя-
занном модуле данные, а не управление, переходили от одной подзадачи к по-
следующей);
д) временно связанный модуль содержит объекты, которые включены в
подзадачи, связанные временем исполнения;
е) логически связанный модуль содержит объекты, содействующие реше-
нию одной общей подзадачи, для которой эти объекты отобраны во внешнем по
отношению к модулю мире. Таким образом, логически связный модуль содер-
жит некоторое количество подзадач (действий) одного и того же общего вида.
Чтобы его использовать, необходимо выбрать именно ту часть (части), которая
требуется. Эти различные подзадачи должны обладать одним и только одним
интерфейсом с внешним миром. При этом семантика каждого параметра зави-
сит от используемой подзадачи;
ж) случайно связанный модуль содержит объекты, соответствующие под-
задачам, незначительно связанным друг с другом. Случайно связный модуль
подобен логически связному модулю, его объекты не связаны ни потоками
данных, ни потоками управления. Однако подзадачи в логически связном мо-
дуле являются, по крайней мере, одной категории; для случайно связного моду-
ля даже это неверно.
В таблице 5.3 приведены сравнительные характеристики для каждого
уровня связанности.
Таблица 5.3
Сравнительные характеристики для каждого уровня связанности
Модифицируе- Сопровожда-
Связности Сцепление Понятность
мость емость
Функциональная хорошее хорошая хорошая хорошая
Последовательная хорошее хорошая близкая к хорошей хорошая
Информационная среднее средняя средняя средняя
Процедурная переменное переменная переменная плохая
Временная плохое средняя средняя плохая
Логическая плохое плохая плохая плохая
Случайная плохое плохая плохая плохая

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

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

90
  включает в себя условия о месте и способе его использования.
Противоположна крайность ограниченному модулю — сверхобобщенный
модуль, обладающий по крайней мере одной из следующих характеристик:
 выполняет слишком завышенный объем работы, результаты которой
не используются в большинстве ситуаций. Примером является модуль, форми-
рующий расписание игр чемпионата по футболу как по григорианскому, так и
по юлианскому календарю;
 имеет дело со слишком избыточным типом данных, их значениями и
структурами. Например, использование числа типа REAL вместо INTEGER для
того, чтобы следить за количеством болтов на складе, было бы чрезмерным
обобщением;
 принимает в качестве параметров данные, которые никогда не изме-
няются. Так, модуль, которому передается количество дней в неделю, является
определенно сверхобобщенным, а также до смешного нелепым.
Минимизация избыточности, т. е. устранение дублирования. Если любой
факт, условие или реализационное решение явно проявляются более чем в од-
ном модуле, то усилия по сопровождению, состоящие из нахождения всех слу-
чаев этого факта и их изменения, увеличиваются. Также возникает риск, что
человек, сопровождающий такую систему, забудет изменить один из дублей.
Нагрузка по входу и выходу. Под нагрузкой модуля по входу понимается
количество непосредственных вызывающих его модулей. Соответственно,
нагрузка модуля по выходу — это количество непосредственно подчиненных
ему модулей. По уже упоминавшимся выше причинам нагрузка по выходу не
должна превышать 6–7 модулей. Высокая нагрузка по входу требует от модуля
хорошей связности.
В заключение отметим, что при использовании структурного подхода
обеспечивается естественный переход от этапа анализа к этапу проектирования
за счет комбинирования транзакционных и трансформационных алгоритмов
преобразования модели функциональных требований (иерархии диаграмм по-
токов данных) в структурные карты.

5.2. Методология объектно-ориентированного подхода

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

91
зовать их снова и снова. Точно так же, как одни и те же строительные блоки
многократно используются при строительстве замка, дома или космического
корабля, основные элементы объектно-ориентированного проекта и кода можно
многократно применять для создания инвентарной системы, бухгалтерской си-
стемы или системы обработки заказов.
Итак, чем же объектно-ориентированный подход отличается от традици-
онного подхода к разработке приложений? В соответствии с традиционным
подходом основное внимание должно уделяться информации, с которой рабо-
тает система. Мы спрашиваем пользователей, какая информация им нужна,
проектируем базы данных для хранения этой информации, создаем экраны для
ее вывода и встраиваем возможность распечатывать отчеты. Иначе говоря, мы
фокусируемся на самой информации, а тому, что с ней делать, т. е. поведению
системы, уделяем меньше внимания. Такой подход называется ориентирован-
ным на данные (data-centric).
Ориентированный на данные подход неоценим при проектировании баз
данных и систем сбора информации, но при разработке бизнес-приложений
возникают проблемы. Одной из главных является то, что требования к системе
могут со временем меняться. Система, ориентированная на данные, легко при-
спосабливается к изменениям базы данных, однако изменить деловые правила
или поведение такой системы значительно труднее.
Для решения этой проблемы и был создан объектно-ориентированный
подход. При этом подходе внимание уделяется как информации, так и поведе-
нию, что позволяет создавать гибкие системы, допускающие изменение их по-
ведения и/или содержащейся в них информации.
Указанные преимущества могут быть реализованы только при правильном
проектировании систем. Это требует знания нескольких принципов объектно-
ориентированного подхода: инкапсуляции, наследования и полиморфизма.
Инкапсуляция
В объектно-ориентированных системах данные комбинируются с кон-
кретным поведением, т. е. с действиями, осуществляемыми над ними. Все это
объединяется в объект. Данный процесс называется инкапсуляцией. По-
другому ее можно описать, сказав, что мы разделяем приложение на небольшие
фрагменты связанной функциональности. Допустим, что у нас имеется инфор-
мация, касающаяся банковского счета: номер счета, баланс, имя и адрес вла-
дельца, тип счета, начисляемые на него проценты и дата открытия. Со счетом
также связаны определенные действия: открыть, закрыть счет, положить или
снять некоторую сумму денег, изменить тип, владельца или адрес. Вся эта ин-
формация и действия (поведение) совместно инкапсулируются в объект account
(счет). В результате все изменения банковской системы, связанные со счетами,
могут быть реализованы в одном только объекте account.
Еще одним преимуществом инкапсуляции является то, что она ограничи-
вает последствия изменений, вносимых в систему. Представьте себе, что систе-
ма — это водоем, а изменения в требованиях к ней — большой камень. Вы бро-
саете камень в воду, и огромные волны немедленно начинают распространяться
92
во всех направлениях. Они проходят по всему озеру, разбиваются о его берега,
отражаются от них и сталкиваются с другими волнами. Часть воды может даже
выйти на берег. Иначе говоря, падение камня в воду вызывает рябь. Теперь мы
инкапсулируем озеро, разделив его на небольшие «фрагменты», разделенные
барьерами. Опять изменения в требованиях ударяют по системе. Бах!!! Во все
стороны начинают расходиться волны. Но теперь они не могут пройти за барь-
еры и останавливаются там. Таким образом, инкапсулировав озеро, мы ограни-
чили эффект ряби от падения камня.
Теперь применим идею инкапсуляции к банковской системе. Допустим,
управление банка постановило, что если клиент имеет кредитный счет, этот
кредит может быть использован как овердрафт на его счете «до востребова-
ния». В неинкапсулированной системе мы начинаем с узконаправленного ана-
лиза изменений, которые необходимо внести в систему. Как правило, мы не
знаем, где в системе находятся все обращения к функции снятия со счета, по-
этому приходится искать их везде. После того как они найдены, мы должны
внести в них некоторые изменения, чтобы реализовать новые требования. Если
мы работаем тщательно, то, вероятно, сможем обнаружить около 80% случаев
использования данной функции. В инкапсулированной системе не требуется
проводить такой детальный анализ. Мы смотрим на модель системы и выявля-
ем, где инкапсулировано соответствующее поведение (действие снятия со сче-
та). После его локализации остается внести требуемые поправки один раз толь-
ко в этом объекте, и наша задача выполнена!
Как видно на рисунке 5.20, в модификации нуждается только класс Ac-
count (Счет).

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

Рис. 5.21
Пример наследования
Одним из основных преимуществ механизма наследования является про-
стота его поддержки. Когда происходит событие, влияющее на всех млекопи-
тающих, изменение надо внести только в родительский объект, а все потомки
автоматически его наследуют. Если млекопитающие, например, внезапно ста-
нут холоднокровными, достаточно будет изменить объект «млекопитающие».
Кошка, собака, человек, кит и все другие объекты-потомки автоматически
наследуют новую характеристику.

94
 В качестве примера наследования в объектно-ориентированных системах
можно привести окна. Допустим, имеется большая система, содержащая
125 окон. Однажды потребовалось вывести во всех окнах сообщение. В системе
без наследования придется внести изменение в каждое из этих 125 окон — до-
вольно трудоемкая задача. В объектно-ориентированной системе окна являются
потомками какого-то общего предка. Все, что требуется сделать в таком слу-
чае, — внести изменение в родителе. Остальные окна автоматически наследуют
его (рис. 5.22).

Рис. 5.22
Наследование: модель окон
В банковской системе наследование можно применять для работы с раз-
личными типами счетов. Наш гипотетический банк обслуживает четыре типа
счетов: до востребования (checking), сберегательный (savings), кредитный
(credit) и депозитный сертификат. Эти различные типы счетов имеют сходные
черты, к которым относятся номер счета, ставка процента и владелец.
Итак, можно создать родительский объект account (счет) с общими харак-
теристиками всех счетов. Объекты-потомки будут иметь наследуемые и свои
собственные уникальные характеристики. Например, кредитный счет будет со-
держать лимит кредита и размер минимального взноса, а депозитный сертифи-
кат — срок платежа. Изменения в родительском объекте повлияют на всех по-
томков, но потомки могут адаптироваться и самостоятельно, не влияя друг на
друга и на своего предка.
Полиморфизм
Третий принцип объектной ориентации — это полиморфизм. В словаре
данный термин определен как проявление различных форм, стадий или типов.
Полиморфизм означает наличие множества форм или реализации конкретной
функциональности.
Как и в случае наследования, полиморфизм можно наблюдать в природе.
Получив команду или реализуя функцию «Говорить», человек может ответить:
«Как дела?», собака скажет: «Гав», кошка: «Мяу» или, скорее всего, просто
проигнорирует вас.
В терминах объектно-ориентированных систем это означает, что кон-
кретные функциональные возможности могут иметь множество реализаций.
95
Иными словами, полиморфизмом называется возможность взаимодействия с
объектом, не зная, к какому конкретному классу он относится. Посылая сооб-
щение любому счету, мы используем полиморфизм всех счетов.
В данном случае полиморфизм является ограниченным. Если сообщение
«снять» будет послано, например, клиенту, он не сможет его обработать, т. е.
нам не важно, какой конкретно счет обрабатывает сообщение, но, тем не менее,
это должен быть счет, объект одного из классов, выведенных из базового клас-
са «Счет».
В большинстве случаев используется именно ограниченный полимор-
физм. Тем не менее, иногда любой объект системы может обработать некоторое
сообщение. Например, в языке Java у всех объектов имеется метод toString,
приводящий значение объекта к строковому виду, соответственно любому объ-
екту независимо от его класса можно послать сообщение toString.
При использовании полиморфизма используется знание интерфейса объ-
екта, однако поведение конкретного объекта в ответ на полученное сообщение
может быть различно в зависимости от конкретного класса этого объекта. Со-
ответственно, посылающий объект точно не знает, что произойдет при вызове
метода. Разные типы счетов реализуют одни и те же операции по-разному. По-
этому, например, вполне возможно, что депозитный счет откажется выдавать
деньги, несмотря на то, что на балансе они имеются.
Наличие механизмов наследования и полиморфизма в объектной модели
позволяет эффективно решать многие задачи разработки систем. Механизм аб-
страктных классов и полиморфизма позволяет решать многие задачи в терми-
нах базовых классов, не заботясь о том, какие конкретно классы участвуют в
той или иной операции. Представим себе класс фигур, которые можно изобра-
жать на экране терминала в графическом редакторе. Из этого класса выведены
конкретные классы квадрата, эллипса, треугольника, трехмерного шара и т. д.
Базовый класс задает те действия, которые можно производить с фигурами:
сдвинуть, повернуть, масштабировать, закрасить и т. д.
Большинство действий графического редактора можно запрограммиро-
вать в терминах действий над базовым классом. Например, при нажатии опре-
деленной клавиши сдвинуть фигуру к левому краю страницы. Полиморфизм
обеспечит правильное выполнение конкретных действий, а добавление новых
типов фигур путем выведения нового конкретного класса из класса «Фигура»
не нарушит алгоритмов работы редактора.
Метод Буча, ОМТ и UML
Важный вопрос визуального моделирования — выбор графической нота-
ции для описания различных аспектов системы. Нотация должна быть понятна
всем заинтересованным сторонам, иначе модель не будет полезна. Множество
разработчиков предлагали свои варианты решения этого вопроса. Из них
наибольшее распространение получили метод Буча, технология объектного мо-
делирования (ОМТ, Оb Modeling Technology) и унифицированный язык моде-
лирования (UML, Unified Modeling Language).

96
 Однако большинством производителей и такими комитетами по стандар-
там, как ANSI и Object Management Group (OMG), был принят стандарт UML.
Метод Буча назван по имени его изобретателя Гради Буча (Grady Booch),
работающего в корпорации Rational Software руководителем по науке (Chief
Scientist). Он написал несколько книг, в которых обсуждаются необходимость и
преимущества визуального моделирования, и разработал нотацию графических
символов для описания различных аспектов модели. Так, объекты в этой моде-
ли представляются в виде облаков, иллюстрируя то, что они могут быть почти
чем угодно. Нотация Буча предусматривает также различного вида стрелки для
отображения разных типов отношений между объектами.
На рисунке 5.23 показаны примеры объектов и отношений между ними в
соответствии с нотацией Буча.

Рис. 5.23
Примеры символов в нотации Буча
Унифицированный язык моделирования (UML) является результатом
совместных усилий Гради Буча, Джеймса Рамбо, Ивара Якобсона (Ivar Jacob-
son), Ребекки Вирс-Брок (Rebecca Wirfs-Brock), Питера Йордона (Peter Yourdon)

97
и многих других. Якобсон первым описал процесс выявления и фиксации тре-
бований к системе в виде совокупностей транзакций, называемых вариантами
использования (use case). Якобсон также разработал метод проектирования си-
стем под названием «Объектно-ориентированное проектирование программно-
го обеспечения» (Object Oriented Software Engineering, OOSE), концентрирую-
щий внимание на анализе.
Буч, Рамбо и Якобсон, о которых обычно говорят как о «трех друзьях»
(three amigos), работают в корпорации Rational Software. Их деятельность свя-
зана в основном со стандартизацией и усовершенствованием языка UML. Сим-
волы UML сильно напоминают нотации Буча и ОМТ, но содержат также эле-
менты из других нотаций. На рисунке 5.24 показан пример нотации UML.

Рис. 5.24
Примеры символов в нотации UML
Процесс консолидации методов, вошедших в состав UML, начался в
1993 г. Каждый из трех авторов этого языка — Буч, Рамбо и Якобсон — начал
внедрять в свои разработки идеи остальных двух авторов. Такая унификация
методологий продолжалась до 1995 г., когда появилась версия Унифицирован-

98
ного Метода (Unified Method). В 1996 г. Унифицированный Метод был обнов-
лен и преобразован в UML. В 1997 г. UML 1.0 был ратифицирован и передан в
группу Object Technology Group, после чего его начали адаптировать у себя
многие основные производители программного обеспечения. Наконец, 14 нояб-
ря 1997 г. группа OMG объявила язык UML 1.1 промышленным стандартом.
Средства UML
Унифицированный язык моделирования UML (Unified Modeling Langua-
ge) представляет собой язык для определения, представления, проектирования
и документирования программных систем, организационно-экономических си-
стем, технических систем и других систем различной природы. UML содержит
стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт
UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диа-
грамм для моделирования:
 диаграммы вариантов использования (use case diagrams) — моделиро-
вание бизнес-процессов организации и требований к задаваемой системе;
 диаграммы классов (class diagrams) — для моделирования тематиче-
ской структуры классов систем и связей между ними;
 диаграммы поведения системы (behavior diagrams);
 диаграммы взаимодействия (interaction diagrams);
 диаграммы последовательности (sequence diagrams);
 кооперативные диаграммы (collaboration diagrams) — для моделиро-
вания процесса обмена сообщениями между объектами;
 диаграммы состояний (statechart diagrams) — для моделирования по-
ведения объектов системы при переходе из одного состояния в другое;
 диаграммы реализации (implementation diagrams);
 диаграммы компонентов (component diagrams) — для моделирования
иерархии компонентов (подсистем) системы;
 диаграммы размещения (deploymеnt diagrams) — для моделирования
физической архитектуры системы.
Мы будем рассматривать только наиболее важные для нас диаграммы.
Диаграммы вариантов использования
Вариант использования представляет собой последовательность действий
(транзакций), выполняемых системой в ответ на событие, инициируемое неко-
торым внешним объектом (действующим лицом). Вариант использования опи-
сывает типичное взаимодействие между пользователем и системой.
В простейшем случае вариант использования определяется в процессе обсуж-
дения с пользователем тех функций, которые он хотел бы реализовать.
Действующее лицо — это роль, которую пользователь играет по отноше-
нию к системе. Действующие лица представляют собой роли, а не конкретных
людей или наименования работ. Несмотря на то, что на диаграммах вариантов
использования они изображаются в виде стилизованных человеческих фигурок,
действующее лицо может также быть внешней системой, которой необходима

99
информация от данной системы. Показывать на диаграмме действующих лиц
следует только в том случае, когда им действительно необходимы некоторые
варианты использования.
Действующие лица делятся на три основных типа:
 пользователи системы,
 другие системы, взаимодействующие с данной;
 время. Время становится действующим лицом, если от него зависит
запуск каких-либо событий в системе.
Пример диаграммы вариантов использования для банковского автомата
(Automated Teller Machine, ATM) показан на рисунке 5.25.

Рис. 5.25
Диаграмма вариантов использования для АТМ
На диаграмме представлено взаимодействие между вариантами использо-
вания и действующими лицами. Она отражает требования к системе с точки
зрения пользователя.
Таким образом, варианты использования — это функции, выполняемые
системой, а действующие лица — это заинтересованные лица (stakeholders) по
отношению к создаваемой системе. Диаграммы показывают, какие действую-
щие лица инициируют варианты использования. Из них также видно, когда
действующее лицо получает информацию от варианта использования.
В сущности, диаграмма вариантов использования может иллюстрировать
требования к системе. В нашем примере клиент банка инициирует различные
варианты использования: снять деньги со счета, перевести деньги, положить
деньги на счет, показать баланс, изменить идентификационный номер, произве-
сти оплату. Банковский служащий может инициировать вариант использования
«Изменить идентификационный номер».

100
 От варианта использования «Произвести оплату» идет стрелка к Кредит-
ной системе. Действующими лицами могут быть и внешние системы, в данном
случае Кредитная система показана именно как действующее лицо — она явля-
ется внешней для системы ATM.
Стрелка, направленная от варианта использования к действующему лицу,
показывает, что вариант использования предоставляет некоторую информацию
действующему лицу. В данном случае вариант использования «Произвести
оплату» предоставляет Кредитной системе информацию об оплате по кредит-
ной карточке.
Из диаграмм вариантов использования можно получить довольно много
информации о системе. Этот тип диаграмм описывает общую функциональ-
ность системы. Пользователи, менеджеры проектов, аналитики, разработчики,
специалисты по контролю качества и все, кого интересует система в целом, мо-
гут, изучая диаграммы вариантов использования, понять, что система должна
делать.
Все варианты использования так или иначе связаны с внешними требова-
ниями к функциональности системы. Варианты использования всегда следует
анализировать вместе с действующими лицами системы, определяя при этом
реальные задачи пользователей и рассматривая альтернативные способы реше-
ния этих задач.
Действующие лица могут играть различные роли по отношению к вари-
анту использования. Они могут пользоваться его результатами или могут сами
непосредственно в нем участвовать. Значимость различных ролей действующе-
го лица зависит от того, каким образом используются его связи.
Конкретная цель диаграммы вариантов использования — это документи-
рование вариантов использования (все входящие в сферу применения системы),
действующих лиц (все вне этой сферы) и связей между ними.
Разрабатывая диаграммы вариантов использования, старайтесь придер-
живаться следующих правил:
 не моделируйте связи между действующими лицами. По определению
действующие лица находятся вне сферы действия системы. Это означает, что
связи между ними также не относятся к ее компетенции;
 не соединяйте стрелками два варианта использования непосредствен-
но. Диаграммы данного типа описывают только то, какие варианты использо-
вания доступны системе, а не порядок их выполнения. Для отображения поряд-
ка выполнения вариантов использования применяют диаграммы деятельностей;
 каждый вариант использования должен быть инициирован действую-
щим лицом. Это означает, что всегда имеется стрелка, начинающаяся на дей-
ствующем лице и заканчивающаяся на варианте использования.
Хорошим источником для идентификации вариантов использования слу-
жат внешние события. Следует начинать с перечисления всех событий, проис-
ходящих во внешнем мире, на которые система должна каким-то образом реа-
гировать. Какое-либо конкретное событие может повлечь за собой реакцию си-
стемы, не требующую вмешательства пользователей, или наоборот, вызвать чи-

101
сто пользовательскую реакцию. Идентификация событий, на которые необхо-
димо реагировать, помогает идентифицировать варианты использования.
Связи между вариантами использования и действующими лицами
В языке UML для вариантов использования и действующих лиц поддер-
живается несколько типов связей. Это связи коммуникации (communication),
включения (include), расширения (extend) и обобщения (generalization).
Связь коммуникации — это связь между вариантами использования и
действующим лицом. На языке UML связи коммуникации показывают с помо-
щью однонаправленной ассоциации (линии со стрелкой). Направление стрелки
позволяет понять, кто инициирует коммуникацию.
Связь включения применяется в тех ситуациях, когда имеется какой-либо
фрагмент поведения системы, который повторяется более чем в одном варианте
использования. С помощью таких связей обычно моделируют многократно ис-
пользуемую функциональность. В примере банковской системы варианты ис-
пользования «Снять деньги со счета» и «Сделать вклад» должны опознать
(аутентифицировать) клиента и его PIN-код перед осуществлением самой тран-
закции. Вместо того чтобы подробно описывать процесс аутентификации для
каждого из них, можно поместить эту функциональность в свой собственный
вариант использования под названием «Аутентифицировать клиента».
Связь расширения применяется при описании изменений в нормальном
поведении системы. Она позволяет варианту использования только при необхо-
димости применять функциональные возможности другого.
На языке UML связи включения и расширения показывают в виде зави-
симостей с соответствующими стереотипами (рис. 5.26).

Рис. 5.26
Связи включения и расширения
С помощью связи обобщения показывают, что у нескольких действующих
лиц имеются общие черты. Например, клиенты могут быть двух типов: корпо-
ративные и индивидуальные. Эту связь можно моделировать с помощью нота-
ции, показанной на рисунке 5.27.
Нет необходимости всегда создавать связи этого типа.
В общем случае они не нужны, если поведение действующего лица одно-
го типа отличается от поведения другого постольку, поскольку это затрагивает
систему. Если оба подтипа применяют одни и те же варианты использования,
показывать обобщение действующего лица не требуется.
102
 Рис. 5.27
Обобщение действующего лица
Варианты использования являются необходимым средством на стадии
формирования требований к ПО. Каждый вариант использования — это потен-
циальное требование к системе, и пока оно не выявлено, невозможно заплани-
ровать его реализацию.
Диаграммы взаимодействия
Диаграммы взаимодействия (interaction diagrams) описывают поведение
взаимодействующих групп объектов.
Как правило, диаграмма взаимодействия охватывает поведение объектов
в рамках только одного варианта использования. На такой диаграмме отобра-
жаются ряд объектов и те сообщения, которыми они обмениваются между со-
бой.
Сообщение (message) — средство, с помощью которого объект-
отправитель запрашивает у объекта-получателя выполнение одной из операций.
Сообщение-запрос (interrogative) — сообщение, запрашивающее выдачу
информации об объекте-получателе.
Императивное (imperative) сообщение — сообщение, запрашивающее у
объекта-получателя выполнение действий.
Существуют два вида диаграмм взаимодействия: диаграммы последова-
тельности (sequence diagrams) и кооперативные диаграммы (collaboration
diagrams).
Диаграммы последовательности отражают поток событий, происходя-
щих в рамках варианта использования. Например, вариант использования
«Снять деньги» предусматривает несколько возможных последовательностей:
снятие денег, попытка снять деньги при отсутствии их достаточного количества
на счету, попытка снять деньги по неправильному идентификационному номе-
ру и некоторые другие.
Нормальный сценарий снятия $20 со счета (при отсутствии таких про-
блем, как неправильный идентификационный номер или недостаток денег на
счету) показан на рисунке 5.28.

103
 Рис. 5.28
Диаграмма последовательности для снятия клиентом Джо $20 со счета
Эта диаграмма последовательности отображает поток событий в рамках
варианта использования «Снять деньги». В верхней части диаграммы показаны
все действующие лица и объекты, требуемые системе для выполнения варианта
использования «Снять деньги». Стрелки соответствуют сообщениям, передава-
емым между действующим лицом и объектом или между объектами для вы-
полнения требуемых функций. Следует отметить также, что на диаграмме по-
следовательности показаны именно объекты, а не классы. Классы представляют
собой типы объектов. Объекты конкретны; вместо класса Клиент на диаграмме
последовательности представлен конкретный клиент Джо.
Вариант использования начинается, когда клиент вставляет свою карточ-
ку в устройство для чтения — этот объект показан в прямоугольнике в верхней
части диаграммы. Он считывает номер карточки, открывает объект «счет Джо»
(account) и инициализирует экран ATM. Экран запрашивает у Джо его реги-
страционный номер. Клиент вводит число 1234. Экран проверяет номер у объ-
екта «счет Джо» и обнаруживает, что он правильный. Затем экран предоставля-
ет Джо меню для выбора, и тот выбирает пункт «Снять деньги». Экран запра-
шивает, сколько он хочет снять, и Джо указывает $20. Экран снимает деньги со
счета. При этом он инициирует серию процессов, выполняемых объектом «счет
Джо». Во-первых, осуществляется проверка, что на этом счету лежат, по край-
ней мере, $20. Во-вторых, из счета вычитается требуемая сумма. Затем кассо-

104
вый аппарат получает инструкцию выдать чек и $20 наличными. Наконец, все
тот же объект «счет Джо» дает устройству для чтения карточек инструкцию
вернуть карточку.
Итак, данная диаграмма последовательности иллюстрирует последова-
тельность действий, реализующих вариант использования «Снять деньги со
счета» на конкретном примере снятия клиентом Джо $20.
Глядя на эту диаграмму, пользователи знакомятся со спецификой своей
работы. Аналитики видят последовательность (поток) действий, разработчики —
объекты, которые надо создать, и их операции. Специалисты по контролю каче-
ства поймут детали процесса и смогут разработать тесты для их проверки. Таким
образом, диаграммы последовательности полезны всем участникам проекта.
Кооперативные диаграммы отражают ту же самую информацию, что и
диаграммы последовательности. Однако делают они это по-другому и с други-
ми целями. Показанная на рисунке 5.28 диаграмма последовательности пред-
ставлена на рисунке 5.29 в виде кооперативной диаграммы

Рис. 5.29
Кооперативная диаграмма, описывающая процесс снятия Джо со своего счета $20
Как и раньше, объекты изображены в виде прямоугольников, а действу-
ющие лица в виде фигур. Если диаграмма последовательности показывает вза-
имодействие между действующими лицами и объектами во времени, то на ко-
оперативной диаграмме связь со временем отсутствует. Так, можно видеть, что
устройство для чтения карточки выдает счету Джо инструкцию открыться, а
счет Джо заставляет это устройство вернуть карточку владельцу. Непосред-
105
ственно взаимодействующие объекты соединены линиями. Если, например,
устройство для чтения карточки общается непосредственно с экраном ATM,
между ними следует провести линию. Отсутствие линии означает, что непо-
средственное сообщение между объектами отсутствует.
Итак, на кооперативной диаграмме отображается та же информация, что
и на диаграмме последовательности, но нужна она для других целей. Специали-
сты по контролю качества и архитекторы системы смогут понять распределе-
ние процессов между объектами. Допустим, что какая-то кооперативная диа-
грамма напоминает звезду, где несколько объектов связаны с одним централь-
ным объектом. Архитектор системы может сделать вывод, что система слиш-
ком сильно зависит от центрального объекта, и перепроектировать ее для более
равномерного распределения процессов. На диаграмме последовательности та-
кой тип взаимодействия было бы трудно увидеть.
Диаграммы классов отражают взаимодействие между классами системы.
Классы можно рассматривать как типы объектов. Например, счет Джо — это
объект. Типом такого объекта можно считать счет вообще, т. е. «Счет»
(Account) — это класс. Классы содержат данные и поведение (действия), влия-
ющее на эти данные. Так, класс Account содержит идентификационный номер
клиента и проверяющие его действия. На диаграмме классов класс создается
для каждого типа объектов из диаграмм последовательности или кооператив-
ных диаграмм.
Диаграмма классов для варианта использования «Снять деньги» показана
на рисунке 5.30.

Рис. 5.30
Диаграмма классов для варианта использования «Снять деньги» системы АТМ

106
 На диаграмме показаны связи между классами, реализующими вариант
использования «Снять деньги». В этом процессе задействованы четыре класса:
Card Reader (устройство для чтения карточек), Account (счет), ATM Screen
(экран ATM) и Cash Dispenser (кассовый аппарат).
Каждый класс на диаграмме классов изображается в виде прямоугольни-
ка, разделенного на три части. В первой части указывается имя класса, во вто-
рой его атрибуты. Атрибут — это некоторая информация, характеризующая
класс. Например, класс Account (счет) имеет три атрибута: Account Number
(номер счета), PIN (идентификационный номер) и Balance (баланс).
В последней части содержатся операции класса, отражающие его поведе-
ние (действия, выполняемые классом). Для класса Account определены четыре
операции: Open (открыть), Withdraw Funds (снять деньги), Deduct Funds (вы-
честь сумму денег из счета) и Verify Funds (проверить наличие денег).
Связывающие классы линии показывают взаимодействие между класса-
ми. Так, класс Account (счет) связан с классом ATM Screen (экран ATM), пото-
му что они непосредственно взаимодействуют друг с другом. Класс Card Reader
(устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый
аппарат), поскольку они не общаются друг с другом непосредственно. Обратите
внимание, что слева от некоторых атрибутов и операций имеются маленькие
значки в виде висячего замка. Они указывают, что атрибут или операция класса
закрыта (private). Доступ к закрытым атрибутам или операциям возможен толь-
ко из содержащего их класса. Account Number, PIN и Balance — закрытые атри-
буты класса Account. Кроме того, закрытыми являются операции Deduct Funds
и Verify Funds.
Стереотипы классов
Стереотипы — это механизм, позволяющий разделять классы на катего-
рии. В языке UML основными стереотипами являются Boundary (граница),
Entity (сущность) и Control (управление).
Граничные классы (boundary classes) — это классы, которые расположены
на границе системы и окружающей среды. Они включают все формы, отчеты,
интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с
другими системами. Для того чтобы найти граничные классы, надо исследовать
диаграммы вариантов использования. Каждому взаимодействию между дей-
ствующим лицом и вариантом использования должен соответствовать, по
крайней мере, один граничный класс. Именно такой класс позволяет действу-
ющему лицу взаимодействовать с системой.
Классы-сущности (entity classes) отражают основные понятия (абстрак-
ции) предметной области и, как правило, содержат хранимую информацию.
Обычно для каждого класса-сущности создают таблицу в базе данных.
Управляющие классы (control classes) отвечают за координацию действий
других классов. Обычно у каждого варианта использования имеется один
управляющий класс, контролирующий последовательность событий этого ва-
рианта использования. Управляющий класс отвечает за координацию, но сам не
несет в себе никакой функциональности — остальные классы не посылают ему
107
большого количества сообщений. Управляющий класс просто делегирует от-
ветственность другим классам, по этой причине его часто называют классом-
менеджером.
Механизм пакетов
Пакеты применяют, чтобы сгруппировать классы, обладающие некоторой
общностью. Существует несколько наиболее распространенных подходов к
группировке.
Во-первых, можно группировать их по стереотипу. В таком случае полу-
чается один пакет с классами-сущностями, один с граничными классами, один с
управляющими классами и т. д. Этот подход может быть полезен с точки зре-
ния размещения готовой системы, поскольку все находящиеся на клиентских
машинах компоненты с граничными классами уже оказываются в одном пакете.
Другой подход заключается в объединении классов по их функциональ-
ности. Например, в пакете Security (безопасность) содержатся все классы, отве-
чающие за безопасность приложения. В таком случае другие пакеты могут
называться Employee Maintenance (Работа с сотрудниками), Reporting (Подго-
товка отчетов) и Error Handling (Обработка ошибок). Преимущество этого под-
хода заключается в возможности повторного использования.
Механизм пакетов применим к любым элементам модели, а не только к
классам. Если для группировки классов не применять некоторые эвристики, то
она становится весьма произвольной.
Одна из них, которая в основном используется в UML, — это зависи-
мость. Зависимость между двумя пакетами существует в том случае, если меж-
ду любыми двумя классами пакетов существует любая зависимость.
Таким образом, диаграмма пакетов (рис. 5.31) представляет собой диа-
грамму, содержащую пакеты классов и зависимости между ними. Строго гово-
ря, пакеты и зависимости являются элементами диаграммы классов, т. е. диа-
грамма пакетов — это форма диаграммы классов.

Рис. 5.31
Диаграмма пакетов
Пакеты не дают ответа на вопрос, каким образом можно уменьшить ко-
личество зависимостей в вашей системе, однако они помогают выделить эти за-
висимости, а после того поработать над снижением их количества. Диаграммы
пакетов можно считать основным средством управления общей структуры си-
стемы.
108
 Пакеты являются жизненно необходимым средством для больших проек-
тов. Их следует использовать в тех случаях, когда диаграмма классов, охваты-
вающая всю систему в целом и размещенная на единственном листе бумаги
формата А4, становится читаемой.
Атрибут — это элемент информации, связанный с классом. Например, у
класса Company (Компания) могут быть атрибут Name (Название), Address (Ад-
рес) и NumberOfEmployees (Число служащих).
Атрибуты содержатся внутри класса, поэтому они скрыты от других
классов. В связи с этим иногда требуется указать, какие классы имеют право
читать и изменять атрибуты. Это свойство называется видимостью атрибута
(attribute visibility).
У атрибута можно определить четыре возможных значения этого пара-
метра. Рассмотрим каждый из них в контексте примера (рис. 5.32).
Employee
–Employee ID : Integer = 0
#SSN : String
#Salary : float
+Address : String
+City : String
+State : String
+Zip Code : Long
+Departament : String
+Hire()
+Fire()
+Promote()
+Demote()
+Transfer()
Рис. 5.32
Видимость атрибутов
Пусть у нас имеется класс Employee с атрибутом Address и класс Company.
Public (общий, открытый). Это значение видимости предполагает, что
атрибут будет виден всеми остальными классами. Любой класс может просмот-
реть или изменить значение атрибута. В таком случае класс Company может
изменить значение атрибута Address класса Employee. В соответствии с нотаци-
ей UML общему атрибуту предшествует знак «+».
Private (закрытый, секретный). Соответствующий атрибут не виден ни-
каким другим классам. Класс Employee будет знать значение атрибута Address
и сможет изменять его, но класс Company не сможет его ни увидеть, ни редак-
тировать. Если это понадобится, он должен попросить класс Employee про-
смотреть или изменить значение этого атрибута, что обычно делается с помо-
щью общих операций. Закрытый атрибут обозначается знаком «–» в соответ-
ствии с нотацией UML.
Protected (защищенный). Такой атрибут доступен только самому классу и
его потомкам. Допустим, что у нас имеются два типа сотрудников с почасовой
оплатой и на окладе. Таким образом, мы получаем два других класса
HourlyEmp и SalariedEmp, являющихся потомками класса Employee. Защищен-
109
ный атрибут Address можно просмотреть или изменить из классов Employee,
HourlyEmp и SalariedEmp, но не из класса Company. Нотация UML для защи-
щенного атрибута — это знак «#».
Package or Implementation (пакетный). Предполагает, что данный атрибут
является общим, но только в пределах его пакета. Допустим, что атрибут
Address имеет пакетную видимость. В таком случае он может быть изменен из
класса Company, только если этот класс находится в том же пакете. Этот тип
видимости не обозначается никаким специальным значком.
В общем случае атрибуты рекомендуется делать закрытыми или защи-
щенными. Это позволяет лучше контролировать сам атрибут и код, а также из-
бежать ситуации, когда значение атрибута изменяется всеми классами системы.
Вместо этого логика изменения атрибута будет заключена в том же классе, что
и сам этот атрибут. Задаваемые параметры видимости повлияют на генерируе-
мый код.

Операции
Операции реализуют связанное с классом поведение. Операция включает
три части — имя, параметры и тип возвращаемого значения. Параметры — это
аргументы, получаемые операцией на «входе». Тип возвращаемого значения
относится к результату действия операции.
На диаграмме классов можно показывать как имена операций, так и име-
на операций вместе с их параметрами и типом возвращаемого значения. Для то-
го чтобы уменьшить загруженность диаграммы, полезно бывает на некоторых
из них показывать только имена операций, а на других — их полную сигнатуру.
В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент 1 : тип данных аргумента 1, аргумент 2 : тип
данных аргумента 2,…) : тип возвращаемого значения
Рассмотрим четыре различных типа операций.
Операции реализации (implementor operations) реализуют некоторые
бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимо-
действия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое
сообщение диаграммы, скорее всего, можно соотнести с операцией реализации.
Каждая операция реализации должна быть легко прослеживаема до соот-
ветствующего требования. Это достигается на различных этапах моделирова-
ния. Операция выводится из сообщения на диаграмме взаимодействия, сообще-
ния исходят из подробного описания потока событий, который создается на ос-
нове варианта использования, а последний — на основе требований. Возмож-
ность проследить всю эту цепочку позволяет гарантировать, что каждое требо-
вание будет реализовано в коде, а каждый фрагмент кода реализует какое-либо
требование.
Операции управления (manager operations) управляют созданием и уни-
чтожением объектов. В эту категорию попадают конструкторы и деструкторы
классов.

110
 Операции доступа (access operation) существуют для того, чтобы про-
сматривать или изменять значения атрибутов других классов.
Пусть, например, у нас имеется атрибут Salary класса Employee. Мы не
хотим, чтобы все остальные классы могли изменять этот атрибут. Вместо этого
к классу Employee мы добавляем две операции доступа — GetSalary и SetSalary.
К первой из них, являющейся общей, могут обращаться и другие классы. Она
просто получает значения атрибута Salary и возвращает его вызвавшему ее
классу. Операция SetSalary также является общей, она помогает вызвавшему ее
классу установить новое значение атрибута Salary. Эта операция может содер-
жать любые правила и условия проверки, которые необходимо выполнить, что-
бы зарплата могла быть изменена.
Такой подход дает возможность безопасно инкапсулировать атрибуты
внутри класса, защитив их от других классов, но все же позволяет осуществить
к ним контролируемый доступ. Создание операций Get и Set (получение и из-
менения значения) для каждого атрибута класса является стандартом.
Вспомогательные операции (helper operations) — это такие операции
класса, которые необходимы ему для выполнения его ответственностей, но о
которых другие классы не должны ничего знать. Это закрытые и защищенные
операции класса.
Чтобы идентифицировать операции, выполните следующие действия:
 изучите диаграммы последовательности и кооперативные диаграм-
мы. Большая часть сообщений на этих диаграммах является операциями реали-
зации. Рефлексивные сообщения будут вспомогательными операциями;
 рассмотрите управляющие операции. Может потребоваться добавить
конструкторы и деструкторы;
 рассмотрите операции доступа. Для каждого атрибута класса, с кото-
рым должны будут работать другие классы, надо создать операции Get и Set.
Связь представляет собой семантическую взаимосвязь между классами.
Она дает классу возможность узнавать об атрибутах, операциях и связях друго-
го класса. Иными словами, чтобы один класс мог послать сообщение другому
на диаграмме последовательности или кооперативной диаграмме, между ними
должна существовать связь.
Имеются четыре типа связей, которые могут быть установлены между
классами: ассоциации, зависимости, агрегации и обобщения.
Ассоциации (association) — это семантическая связь между классами. Ее
рисуют на диаграмме классов в виде обыкновенной линии (рис. 5.33).
New Class New Class 2

Рис. 5.33
Ассоциация
Ассоциации могут быть двунаправленными, как в примере, или однона-
правленными. На языке UML двунаправленные ассоциации рисуют в виде про-
стой линии без стрелок или со стрелками с обеих ее сторон. На однонаправлен-

111
ной ассоциации изображают только одну стрелку, показывающую ее направле-
ние.
Направление ассоциации можно определить, изучая диаграммы последо-
вательности и кооперативные диаграммы. Если все сообщения на них отправ-
ляются только одним классом и принимаются только другим классом, а не
наоборот, между этими классами имеет место однонаправленная связь. Если
хотя бы одно сообщение отправляется в обратную сторону, ассоциация должна
быть двунаправленной.
Ассоциации могут быть рефлексивными. Рефлексивная ассоциация пред-
полагает, что один экземпляр класса взаимодействует с другим экземпляром
этого же класса.
Зависимости (dependency) также отражают связь между классами, но они
всегда однонаправлены и показывают, что один класс зависит от определений,
сделанных в другом. Зависимости изображаются в виде стрелки, проведенной
пунктирной линией.
Агрегации (aggregations) представляют собой более тесную форму ассо-
циации. Агрегация — это связь между целыми и его частью. Например, у вас
может быть класс Автомобиль, а также классы Двигатель, Покрышки и классы
для других частей автомобиля. В результате объект класса Автомобиль будет
состоять из объекта класса Двигатель, четырех объектов Покрышки и т. д. Аг-
регации визуализируют в виде линии с ромбиком у класса, являющегося целым.
Обобщения (generalization) показывают связи наследования между двумя
классами. Большинство объектно-ориентированных языков непосредственно
поддерживают концепцию наследования. Она позволяет одному классу насле-
довать все атрибуты, операции и связи другого. На языке UML связи наследо-
вания называют обобщениями и изображают в виде стрелок от класса-потомка
к классу-предку.
Помимо наследуемых, каждый подкласс имеет собственные уникальные
атрибуты, операции и связи.
Множественность (multiplicity) показывает, сколько экземпляров одного
класса взаимодействуют с помощью этой связи с одним экземпляром другого
класса в данный момент времени.
Например, при разработке системы регистрации курсов в университет
можно определить классы Course (Курс) и Student (Студент). Между ними
установлена связь: у курсов могут быть студенты, а у студентов — курсы. Во-
просы, на которые должен ответить параметр множественности: «Сколько кур-
сов студент может посещать в данный момент?» и «Сколько студентов могут за
раз посещать один курс?».
Так как множественность дает ответ на оба эти вопроса, ее индикаторы
устанавливаются на обоих концах линии связи. В примере регистрации курсов
мы решили, что один студент может посещать от 0 до 4 курсов, а один курс мо-
гут слушать от 10 до 20 студентов.
На диаграмме классов это можно изобразить следующим образом
(рис. 5.34).

112
 Course Student

0..4 10..20

Рис. 5.34
Множественность
Цифры 0…4 обозначают, что один студент может посещать от 0 до 4 кур-
сов, а цифры 10…20 — что на одном курсе могут заниматься от 10 до 20 сту-
дентов.
В языке UML приняты следующие нотации для обозначения множе-
ственности (табл. 5.4).
Таблица 5.4
Значения множественности
Множественность Значение
* Много
0 Нуль
1. Один
0..* Нуль или больше
1..* Один или больше
0..1 Нуль или один
1..1 Ровно один

Имена связей
Связи можно уточнить с помощью имен связей или ролевых имен. Имя
связи — это обычно глагол или глагольная фраза, описывающая, зачем она
нужна. Например, между классом Person (Человек) и классом Company (Компа-
ния) может существовать ассоциация. В связи с этим возникает вопрос, являет-
ся ли объект класса Person клиентом компании, ее сотрудником или владель-
цем? Для того чтобы определить это, ассоциацию можно назвать «employs»
(нанимает).
Имена у связей определять необязательно. Обычно это делают, если при-
чина создания связи не очевидна. Имя показывают около линии соответствую-
щей связи.
Разработчики используют диаграммы классов для реального создания
классов. Такие инструменты, как Rose, генерируют основу кода классов, кото-
рую программисты заполняют деталями на выбранном ими языке. С помощью
этих диаграмм аналитики могут показать детали системы, а архитекторы — по-
нять ее проект. Если, например, какой-либо класс несет слишком большую
функциональную нагрузку, это будет видно на диаграмме классов, и архитектор
сможет перераспределить ее между другими классами.
С помощью диаграммы можно также выявить случаи, когда между сооб-
щающимися классами не определено никаких связей. Диаграммы классов сле-
дует создавать, чтобы показать взаимодействующие классы в каждом варианте
использования. Можно строить также более общие диаграммы, охватывающие
все системы или подсистемы.

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

114
относительно небольших подсистем. Процесс интеграции системы растягивает-
ся на все время разработки, а не превращается в единовременное событие.
3. Объектная модель вполне естественна, поскольку, в первую очередь,
ориентирована на человеческое восприятие мира, а не на компьютерную реали-
зацию.
4. Объектная модель позволяет в полной мере использовать выразитель-
ные возможности объектных и объектно-ориентированных языков программи-
рования.
К недостаткам объектно-ориентированного подхода относят некоторое
снижение производительности функционирования ПО и высокие начальные за-
траты. Объектная декомпозиция существенно отличается от функциональной,
поэтому переход на новую технологию связан как с преодолением психологи-
ческих трудностей, так и с дополнительными финансовыми затратами. Без-
условно, объектно-ориентированная модель наиболее адекватно отражает ре-
альный мир, представляющий собой совокупность взаимодействующих (по-
средством обмена сообщениями) объектов.
Но на практике в настоящий момент продолжается формирование стан-
дарта языка объектно-ориентированного моделирования UML, и количество
CASE-средств, поддерживающих объектно-ориентированный подход, невелико
по сравнению с поддерживающими структурный подход. Кроме того, отража-
ющие специфику объектного подхода диаграммы классов и т. п. гораздо менее
наглядны и плохо понимаемы непрофессионалами. Поэтому одна из главных
целей внедрения CASE-технологии — снабжение всех участников проекта
(в том числе и заказчика) общим языком «для передачи понимания» — обеспе-
чивается на сегодняшний день только структурными методами.
При переходе от структурного подхода к объектному, как при всякой
смене технологии, необходимо вкладывать деньги в приобретение новых ин-
струментальных средств. Здесь следует учесть и расходы на обучение (овладение
методом, инструментальными средствами и языком программирования). Для не-
которых организаций эти обстоятельства могут стать серьезным препятствием.
Объектно-ориентированный подход не дает немедленной отдачи. Эффект
от его применения начинает сказываться после разработки двух-трех проектов
и накопления повторно используемых компонентов, отражающих типовые про-
ектные решения в данной области. Переход организации на объектно-
ориентированную технологию — это смена мировоззрения, а не просто изуче-
ние новых CASE-средств и языков программирования.
Таким образом, структурный подход по-прежнему сохраняет свою зна-
чимость и достаточно широко используется на практике. На примере языка
UML хорошо видно, что его авторы заимствовали то рациональное, что можно
было взять из структурного подхода: элементы функциональной декомпозиции
в диаграммах вариантов использования, диаграммы состояний, диаграммы дея-
тельностей и др. Однако очевидно, что в конкретном проекте декомпозировать
сложную систему одновременно двумя способами невозможно. Можно начать
декомпозицию каким-либо одним способом, а затем, используя полученные ре-
зультаты, попытаться рассмотреть систему с другой точки зрения.
115
 Теперь перейдем к рассмотрению взаимосвязи между структурным и объ-
ектно-ориентированным подходами. Основой взаимосвязи является общность
ряда категорий и понятий обоих подходов (процесс и вариант использования,
сущность и класс и др.). Эта взаимосвязь может проявляться в различных фор-
мах. Так, одним из возможных подходов является использование структурного
анализа как основы для объектно-ориентированного проектирования. Такой
подход целесообразен ввиду широкого распространения CASE-средств, под-
держивающих структурный анализ. Его можно считать слишком прагматиче-
ским, но в некоторых ситуациях иной подход невозможен. При этом структур-
ный анализ следует прекращать, как только диаграммы потоков данных начнут
отражать не только деятельность организации (предметную область), а и систе-
му ПО. После выполнения структурного анализа и построения диаграмм пото-
ков данных вместе со структурами данных и другими продуктами анализа
можно различными способами приступить к определению классов и объектов.
Так, если взять какую-либо отдельную диаграмму, то кандидатами в объекты
могут быть внешние сущности и накопители данных, а кандидатами в клас-
сы — потоки данных.
Другой формой проявления взаимосвязи можно считать интеграцию объ-
ектной и реляционной технологий. Реляционные СУБД являются на сегодняш-
ний день основным средством реализации крупномасштабных баз данных и
хранилищ данных. Причины этого очевидны: реляционная технология исполь-
зуется достаточно долго, освоена огромным количеством пользователей и раз-
работчиков, стала промышленным стандартом, в нее вложены значительные
средства и создано множество корпоративных БД в самых различных отраслях,
реляционная модель проста и имеет строгое математическое основание; суще-
ствует большое разнообразие промышленных средств проектирования, реали-
зации и эксплуатации реляционных БД. Вследствие этого реляционные БД в
основном используются для хранения и поиска объектов в так называемых объ-
ектно-реляционных системах.
Объектно-ориентированное проектирование имеет точки соприкоснове-
ния с реляционным проектированием. Например, как было отмечено выше,
классы в объектной модели могут некоторым образом соответствовать сущно-
стям (в качестве упражнения можно предположить детально проанализировать
все сходства и различия диаграмм «сущность — связь» и диаграмм классов).
Как правило, такое соответствие имеет место только на ранней стадии разра-
ботки системы — стадии формирования требований. В дальнейшем, разумеет-
ся, цели объектно-ориентированного проектирования (адекватное моделирова-
ние предметной области в терминах взаимодействия объектов) и разработки
реляционной БД (нормализация данных) расходятся.
Таким образом, единственно возможным средством преодоления данного
разрыва является построение отображения между объектно-ориентированной и
реляционной технологиями, которое в основном сводится к отображению меж-
ду диаграммами классов и реляционной моделью.
Одним из примеров практической реализации взаимосвязи между струк-
турным и объектно-ориентированным подходом является программный интер-
116
фейс (мост) между структурными CASE-средством Silverrun и объектно-
ориентированным CASE-средством Rational Rose, разработанный российской
компанией «Аргуссофт». Этот мост создает диаграммы классов Rational Rose на
основе RDM-модели (Relation Data Model — реляционная модель данных)
Silverrun, и наоборот. Аналогичные интерфейсы существуют также между
CASE-средствами Erwin (с одной стороны), Rational Rose и Paradigm Plus
(с другой стороны).

117
 ТЕМА 6. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОГО
ОБЕСПЕЧЕНИЯ ЭИС
6.1. Состав, содержание и принципы организации
информационного обеспечения ЭИС
Информация столь же необходима управленческому аппарату, как объек-
ту управления — сырье и ресурсы. Она формируется в результате обработки
специфического сырья, известного под названием «данные».
Данные отражают конкретные финансово-хозяйственные факторы, состо-
яние или процессы и имеют собственный материальный носитель (бухгалтер-
ские и финансовые документы, сигналы, поступающие от датчиков, дисплеи,
магнитные носители и т. д.). Согласно рисунку 1.1, любая система управления
имеет дело с двумя видами информации: внешней (информация о внешней сре-
де) и внутренней (циркулирующей между управленческим аппаратом и объек-
том управления).
Для внешней информации характерны приблизительность, неточность,
обрывистость, противоречивость. В основном она касается состояния рынка и
конкурентов, прогнозов процентных ставок и цен, налоговой политики и поли-
тической ситуации. По своей природе такая информация носит вероятностный
характер, и поэтому ее обработка стандартными программными средствами за-
труднена. Это потребовало создания особых информационных систем, полу-
чивших название экспертных. Такие системы способны давать точные выводы
на основе недетерминированной информации.
Внутренняя информация возникает в самой системе управления и отра-
жает развитие объекта управления в различные временные интервалы, его фи-
нансово-хозяйственное состояние и директивные цели на случай отклонений от
установленных параметров. Как правило, эти данные измеряются, и в управ-
ленческих документах фиксируется точная информация.
В зависимости от уровня управления используются различные виды ин-
формации. Так, для высшего руководства, разрабатывающего стратегию дея-
тельности, применяется в основном внешняя и, в меньшем объеме, внутренняя
информация. На оперативном уровне используется только внутренняя, а на
среднем — большей частью внутренняя и, частично, внешняя. Эти виды ин-
формации хранятся на своих носителях, составляя информационную базу, на
основе которой функционирует ЭИС.
Информационная база состоит из двух взаимосвязанных частей: внема-
шинной и внутримашинной.
Внемашинное информационное обеспечение
К внемашинной относится та часть, которая обслуживает систему управ-
ления в виде, воспринимаемом человеком без каких-либо технических средств,
например, документы (наряды, акты, накладные, счета или регистры, ведомости
и т. д.).

118
 Внемашинное информационное обеспечение содержит:
 систему классификации и кодирования информации;
 систему технологической и производственной документации;
 систему документооборота.
Система — это правила организации, ведения, хранения, заполнения,
внесения изменений и т. п.
Классификатор — это систематизированный свод наименований кодиру-
емых объектов, их классификационных признаков и кодовых обозначений.
Они используются для однозначной идентификации объектов, обеспече-
ния возможности группировки информации по ряду признаков, поиска и обме-
на информацией между системами различных уровней.
Под классификацией понимается результат упорядоченного распределе-
ния объектов заданного множества на классы, подклассы и т. д. по ряду призна-
ков.
Система технологической и производственной документации включает в
себя правила эксплуатации ЭИС.
Она должна содержать инструкции для каждого рабочего места системы,
описание общей технологии обработки информации и поэтапной технологии.
Например: Расчет заработной платы (примерный перечень инструкций):
— описание применения;
— описание постановки;
— установка ИС;
— общие правила работы и права доступа;
— этап внедрения;
— технология ежемесячных расчетов (в том числе описание типичных
ошибок);
— технология разовых расчетов;
— переход на новый месяц;
— переход на новый год;
— правила работы с архивом, его виды хранения (75 лет):
— подклейка лицевых счетов;
— правила внесения изменений в НСИ (изменение начислений — удер-
жаний, № табл. и т. д.).
Система документооборота содержит все формы входных, выходных и
нормативно-справочных документов, правила их обработки, потоки и маршру-
ты движения и т. д.
По каждой из форм входных документов разрабатывается инструкция по
заполнению, в которой отражаются характерные особенности, влияющие на ал-
горитм решения задач, и даются указания по подготовке и передаче документа,
по его приему и контролю, по хранению.
Для выходных документов составляются инструкции по их использова-
нию. Эти инструкции разрабатываются по каждой задаче. По всем формам
входных и выходных документов составляются маршруты их движения, в ко-
торых приводятся места формирования документов, количество экземпляров,
последовательность прохождения каждого экземпляра и место его хранения.
119
 Например:
ТТН — 5 экз. 1. Бух.
2. Склад.
3. Экономисты
4. Заказчик.
5. Экспедиция и п/л.
Все, что говорилось о документах, относится и к экранам, только с экрана
нет твердой копии, поэтому может работать один человек. В этом случае также
есть маршрут и в сетях, но не надо твердых копий для внутренних документов.
Внутримашинное информационное обеспечение
Внутримашинное информационное обеспечение состоит из программ ор-
ганизации, накопления, ведения и доступа к данным, а также из файлов на маг-
нитных носителях, т. е. из всего, что касается обработки, хранения и представ-
ления информации внутри ЭВМ.
Оно может быть создано либо как множество локальных, т. е. независимых
файлов, каждый из которых отражает некоторое множество однородных управ-
ленческих документов (например, накладных), либо как база данных. Разница
состоит в том, что при создании базы данных файлы не являются независимыми,
ибо структура одних файлов (состав полей) зависит от структуры других. Это
служит причиной несоответствия структуры файлов базы данных структуре
управленческих документов, на основе которых эти файлы создаются.
Файлы базы данных разрабатываются с соблюдением определенных
принципов и с ориентацией на одну из моделей базы данных (реляционную,
иерархическую, сетевую).
Файлы обрабатываются с помощью специального программного обеспе-
чения — систем управления базами данных (СУБД).

6.2. Классификаторы и коды: проектирование

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

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

121
 Целью разработки классификаторов является установление соответствия
между значениями справочных или описательных признаков какого-либо эле-
мента или процесса и значениями группировочных признаков, например, меж-
ду значением реквизита «Фамилия И. О. рабочего» и значением «Табельный
номер» рабочего или между значениями «Наименование материала» и «Код ма-
териала».
Составление классификаторов выполняется в два этапа: первый этап —
классификация информации, второй — кодирование.
Классификация осуществляется в такой последовательности.
Сначала выявляются номенклатуры, подлежащие кодированию. К ним
относятся те реквизиты-признаки, которые используются для составления
группировок. Затем по каждой номенклатуре составляется полный перечень
всех позиций, подлежащих кодированию. При этом соблюдается логическая за-
висимость различных признаков в рассматриваемой номенклатуре. Например,
при кодировании территорий районы располагаются по областям. Такой упоря-
доченный список, т. е. полный перечень однородных наименований, состоящий
из отдельных строк (позиций), называется номенклатурой. В каждой номенкла-
туре предусматривается некоторое количество резервных позиций на случай
появления новых объектов. Таким образом, можно отметить, что классифика-
ция заключается в распределении элементов множества на подмножества на
основании признаков и зависимости внутри признаков.
После составления классификации выполняется следующий этап — ко-
дирование — процесс присвоения условного обозначения различным позициям
номенклатуры. Код — условное обозначение объекта знаком или группой зна-
ков по определенным правилам, установленным системой кодирования. Коды
могут быть цифровыми, буквенными, буквенно-цифровыми и могут состоять из
одного или нескольких знаков. При машинной обработке предпочтение отдает-
ся информации, закодированной в цифровой форме, как наиболее удобной для
автоматической группировки.
После присвоения кодов создается классификатор — систематизирован-
ный свод однородных наименований и их кодовых обозначений.
Приведем некоторые определения, нужные для дальнейшего изложения
материала. Классифицирование — это процесс распределения объектов данного
множества на подмножества. Классификация представляет собой результат
упорядоченного распределения объектов заданного множества. Система клас-
сификации — совокупность правил распределения объектов множества на под-
множества.
Классифицирование информации помогает успешному изучению внут-
ренних и внешних свойств объектов, связей и отношений, возникающих между
объектами, выявлению закономерностей существования и развития объектов,
построению моделей. Классифицирование обязательно при реализации боль-
шинства способов машинной обработки данных и, как правило, предшествует
кодированию данных.
Для проведения классификации требуется, прежде всего, множество объ-
ектов, обладающих совокупностью некоторых свойств. Свойство (характери-
122
стика) объекта классификации, позволяющее установить его сходство или раз-
личие с другими объектами классификации, называется признаком классифика-
ции.
В результате классифицирования образуются подмножества — класси-
фикационные группировки, объединяющие часть объектов классификации по
одному или нескольким признакам.
Классификации делятся на содержательные и формальные.
Содержательная классификация отражает существенные внутренние и
внешние свойства и взаимосвязи объектов классификации, а формальная —
случайные, несущественные свойства и взаимосвязи объектов классификации,
установленные для удобства работы и идентификации элементов заданного
множества.
Системы классификации характеризуются гибкостью, емкостью и степе-
нью заполненности.
Гибкость системы классификации означает возможность включения в
классификацию новых классификационных группировок или объектов класси-
фикации без нарушения ее структуры.
Емкость системы классификации (Р) определяется числом, характери-
зующим наибольшее количество группировок в данной системе классифика-
ции.
Степень заполненности системы классификации (R) представляет собой
отношение фактического числа квалификационных группировок (K) в данной
классификации к емкости используемой в ней системы классификации (Р):
K
R .
P
Различают иерархическую и многоаспектную системы классификации.
Иерархическая система классификации предполагает разбиение множе-
ства на подмножества, между которыми установлены отношения соподчинен-
ности (иерархии).
Графически данную систему можно представить в виде графа (рис. 6.1),
узлами которого будут классификационные группировки, а корнем — исходное
классифицируемое множество.
Алгоритм построения классификации по иерархической системе сводится
к следующему.
Исходное классифицируемое множество некоторых объектов M  {xi ,i  1, I }
сначала на основании признака классификации P1 разбивается на подмножества
M j  M ( j  1, J ).
Далее каждое подмножество по следующему признаку классификации Р2
разбивается на ряд более мелких подмножеств M jkj  M j ( j  1, J ; kj  1, Kj ), со-
ставляющих соответствующую ступень классификации (в данном случае вто-
рую).
Аналогичным образом получают последующие ступени классификации.
Причем совокупность классификационных группировок, расположенных на

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

Рис. 6.1
Схема иерархической системы классификации
При построении иерархической системы классификации подмножества на
каждой ступени классификации не должны пересекаться, т. е. любой конкрет-
ный объект классификации на каждой ступени должен быть отнесен только к
одной классификационной группировке.
Кроме того, должны соблюдаться следующие правила:
 каждое подмножество должно разбиваться только по одному признаку
классификации при условии, что такой признак может быть составным;
 объединение всех подмножеств на любом уровне классификации
должно составлять исходное множество:
J KJ

M  M j M j  M
j 1 kj 1

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

ляются простота ее построения и хорошая приспособляемость для ручной об-
работки.
Однако данная система отличается жесткостью структуры, так как при-
знаки классификации и порядок их следования строго фиксированы. Есте-
ственно, что изменение хотя бы одного признака ведет к изменению всех клас-
сификационных группировок. Кроме того, данная система классификации не
позволяет объединять объекты в классификационные группировки по любому,
ранее не предусмотренному признаку или группе признаков. Это ухудшает
124
адаптивные свойства ЭИС, использующих иерархическую систему классифи-
кации.
Многоаспектные системы классификации компенсируют указанные не-
достатки иерархической системы. В них применяется параллельно несколько
независимых признаков в качестве классификационных, то есть исходное мно-
жество рассматривается одновременно в разных аспектах.
Одной из основных систем, относящихся к этому классу, является фа-
сетная система классификации. При ее использовании исходное классифици-
руемое множество объектов на основании некоторого признака классификации
разбивается сначала на подмножества Mj1 ⊂ M. Признак классификации назы-
вается фасетой, обозначим его Ф1. Затем это же множество разбивается на ос-
новании фасеты Ф2 на подмножества Mj2 ⊂ M. Аналогичным образом происхо-
дит разбиение исходного множества M по всем фасетам Ф = Ф1, …, ФR, в ре-
зультате получается R независимых классификаций исходного множества M.
Затем строится структурная формула группировки Г из одной или не-
скольких фасет Фr:
Г = Фr1, Фr2…, Фrk.
Любой фасете Фr соответствует допустимая совокупность значений Zr.
Каждой фасете Фr ≠ Г присваивается значение из соответствующей допустимой
совокупности значений Zr. Полученный таким образом составной признак бу-
дет выступать в качестве признака классификации.
Все объекты из исходного множества, удовлетворяющие полученному
значению признака классификации, образуют подмножество, являющееся ком-
понентом классификационной группировки Xm (рис. 6.2). Множество группиро-
вок получается как декартово произведение совокупностей Zr.
Следовательно, классификационные группировки при данной системе
классификации получаются путем комбинирования значений признаков, взятых
из соответствующих фасет. Последовательность расположения фасет в струк-
турной формуле группировки важна при организации машинной обработки
данных, например, при сортировке.

Рис. 6.2
Схема построения фасетной системы классификации

125
 При построении фасетной системы классификации необходимо, чтобы
признаки, используемые в различных фасетах, не повторялись и чтобы из все-
возможных признаков, характеризующих объекты классификации, выбирались
только существенные.
Фасетная система классификации отличается большой гибкостью и удоб-
ством использования. Она дает возможность строить группировки по любому
сочетанию выбранных признаков. Причем при построении классификационных
группировок из разных фасет ненужные фасеты можно пропускать, что недопу-
стимо для иерархической системы. К недостаткам данной системы классифика-
ции следует отнести сложность ее построения и большую длину кода.
Классификаторы имеют двоякое применение: первое — для ручного про-
ставления кодов в документах. В этом случае классификаторы оформляются в
виде справочников и используются экономистами для подготовки первичных и
сводных документов к машинной обработке.
Во втором случае применения кодов предусматривается хранение всех
классификаторов в памяти машины, на машинных носителях в банке данных в
качестве условно-постоянной информации.
Рассмотренные выше системы классификации хорошо приспособлены
для организации поиска с целью последующей логической и арифметической
обработки информации на ЭВМ и лишь частично решают проблему содержа-
тельного поиска экономической информации при принятии управленческих
решений. Это объясняется далеко не полным охватом этими системами всех
понятий и терминов, используемых для выражения смысла экономических по-
казателей и документов. Помимо этого в этих системах не решается проблема
обеспечения однозначности используемой терминологии, идентификации роли
отдельных терминов в их общей последовательности при формировании
наименований экономических показателей.
К недостаткам этих систем классификации можно отнести также и то, что
в них не отражаются все отношения между терминами, необходимые для фор-
мализации содержания показателей и документов и установления взаимосвязей
между показателями и документами, которые используются на этапе принятия
управленческих решений.
Для поиска показателей и документов по набору содержательных призна-
ков используется информационный язык дескрипторного типа, который харак-
теризуется совокупностью терминов, дескрипторов или лексикой и набором
отношений между терминами. Эти отношения могут быть двух типов:
 постоянные логические отношения между терминами, вытекающие из
отношений между отображаемыми объектами, которые называются парадиг-
матическими отношениями;
 переменные отношения между понятиями, возникающие в процессе
построения конкретного высказывания, например показателя, называемые син-
тагматическими отношениями.
Парадигматические отношения между терминами отражают статику
языка. К ним относятся, например, родовидовые отношения. При этом родовым
называется термин или понятие, выражающие существенные признаки класса
126
предметов, в состав которого входят предметы, являющиеся видами этого рода.
Видовое понятие выражает существенные признаки подкласса предметов, яв-
ляющегося видом какого-либо другого класса предметов и входящего в состав
этого класса. Например, понятие «машинный носитель» является родовым по
отношению к понятиям «жесткий магнитный диск», «гибкий диск», «магнитная
лента» и т. д. Отношения этого типа отражаются в классификаторах экономиче-
ской информации.
Синтагматические отношения составляют грамматику этого языка, т. е.
правила построения высказываний из набора терминов или понятий. Такие от-
ношения используются в динамике при вводе данных и формулировании запро-
сов.
В зависимости от того, на каком этапе фиксируются все возможные вы-
ражения, языки делятся на предкоординированные и посткоординируемые.
Предкоординированными называются языки, в которых на стадии разработки
выделяются все высказывания в терминах этих языков, и тем самым заранее
определяются постоянные отношения между терминами. Для посткоординиру-
емых языков характерна предварительная фиксация лишь постоянных отноше-
ний.
Все высказывания образуются при использовании лексики данного языка
и его грамматики. Языки предкоординированного типа менее гибки при ис-
пользовании, так как с их помощью можно описывать только те выражения, ко-
торые были заранее зафиксированы. Использование посткоординированных
языков позволяет образовывать с их помощью значительно большее число вы-
сказываний.
Общим недостатком информационных языков классификационного типа
являются их слабая приспособленность к новым, заранее не предусмотренным
условиям функционирования систем, возможность составления запросов на
этих языках регламентированного содержания. Эти недостатки отсутствуют у
языков посткоординированного типа, к которым относятся дескрипторные язы-
ки, основанные на применении метода координатного, или ассоциативного, ин-
дексирования.
Согласно идее координатного индексирования предполагается, что со-
держание документов или показателей можно достаточно полно и точно отра-
зить с помощью списка ключевых слов — дескрипторов. Дескриптор — это
термин естественного языка (слово или словосочетание), используемый при
описании документов или показателей, который имеет самостоятельный смысл
и неделим без изменения своего значения. Например, показатель «Количество
продукции, выработанное фактически цехом за смену», записанный на есте-
ственном языке, при использовании метода координатного индексирования бу-
дет иметь вид: «количество, продукция, выработка, фактический, цех, смена».
Для того чтобы обеспечить точность и однозначность поиска с помощью
такого языка, необходимо предварительно определить все постоянные отноше-
ния между терминами: родовидовые, отношения синонимии, омонимии и поли-
семии, а также ассоциативные отношения. Характеристика родовидовых отно-
шений была дана выше.
127
 Особый вид парадигматических отношений представляют отношения си-
нонимии, омонимии и полисемии, всегда присутствующие в естественных язы-
ках.
Синонимия — это отношение между двумя и более различными ключе-
выми словами, когда они имеют одинаковое значение, обозначают один и тот
же предмет или понятие. Можно выделить синонимы с одним корнем, но с раз-
личным морфологическим составом (например, «производство» и «произведе-
но»), с различными корнями (например, «издержки» и «расходы»).
К синонимам относятся также термины, которые могут существовать как в
полном, так и в сокращенном виде, например, «научно-исследовательские ра-
боты» и «НИР», «кубические метры» и «куб. м».
Омонимия — это такое отношение между одинаковыми по звучанию и
написанию ключевыми словами, когда они имеют разное значение и обознача-
ют разные предметы и понятия. Можно выделить термины, обозначающие та-
кие разные понятия, объемы которых не пересекаются, и называемые полными
омонимами. Например, термин «прокат» используется в двух различных смыс-
лах: «прокат тонкой листовой стали» и «сдача предметов во временное пользо-
вание», поэтому он относится к числу полных омонимов.
Однако встречаются термины, обозначающие разные понятия, объемы
которых пересекаются. Такие термины называются частичными омонимами.
Явление частичной омонимии носит название полисемии.
Большое значение для построения дескрипторного языка имеют выявле-
ние и фиксирование ассоциативных отношений между терминами, которые
позволяют выдавать более точные ответы на запросы пользователей. К числу
ассоциативных отношений относят такие, как отношение части к целому
(например, «цех» — «участок»), причинно-следственные отношения (например,
«прогул» — «невыполнение»), связи предмета и процесса (например, «план» —
«планирование») и др.
Все выделенные отношения явно описываются в систематическом слова-
ре понятий — тезаурусе, который разрабатывается с целью проведения индек-
сирования документов, показателей и информационных запросов.
В свою очередь, дескрипторные языки различаются по семантической си-
ле, которая определяется тем, какой объем сведений может индексироваться с
их применением. Семантическая сила языка зависит от числа типов постоянных
отношений, фиксируемых в тезаурусе, а также от наличия средств грамматики
и степени их сложности. В соответствии с этим признаком дескрипторные язы-
ки подразделяются на языки без грамматики, языки с неполной грамматикой и
языки с развитой грамматикой. При этом языки первого вида содержат только
словари используемых ключевых слов и тезаурусы. В языках с неполной грам-
матикой, помимо словарей и тезаурусов, имеются правила взаимосвязи только
некоторых категорий терминов. Языки с развитой грамматикой позволяют опи-
сывать с помощью всех средств сложные высказывания.
В том случае, если объектом поиска в ЭИС является документ, для этих
целей используют информационные языки дескрипторного типа без граммати-
ки. При необходимости хранения и осуществления поиска экономических пока-
128
зателей проектировщики отдают предпочтение языкам второго и третьего ти-
пов.
Проектирование кодов технико-экономической информации
Кодированием называется присваивание кодового обозначения объектам
классификации и классификационным группировкам.
Кодовым обозначением (кодом) является обозначение объекта или клас-
сификационной группировки знаком или группой знаков по правилам, установ-
ленным соответствующей системой кодирования.
Система кодирования — это совокупность правил обозначения объектов
классификационных группировок.
Классификация информации служит основой ее кодирования.
К кодам предъявляется ряд требований, они должны:
 охватывать все номенклатуры, подлежащие кодированию;
 быть едиными для разных задач внутри одного экономического объ-
екта (например, коды материалов, подразделений должны быть едиными для
задач бухгалтерского учета и материально-технического снабжения);
 отличаться стабильностью;
 иметь резерв свободных номеров (но не излишний, так как это может
привести к увеличению значности кода);
 иметь минимальную длину кодового обозначения.
Значность кодов данной номенклатуры является одинаковой для всех по-
зиций. Иногда к основному коду через тире добавляют контрольный разряд, ко-
торый обеспечивает автоматическое нахождение ошибки машиной при неис-
правном проставлении экономистом какой-либо цифры в коде или при переста-
новке цифр. Как показывает практика, это наиболее частые ошибки, допускае-
мые при кодировании. Поэтому, например, при обработке банковской информа-
ции контрольный разряд имеет номер лицевого счета клиента и номер филиала.
Назначение кодов заключается в обеспечении группировки информации в
машине, подведении итогов по всем группировочным признакам и их печати в
сводных таблицах. Они находят широкое применение при выполнении таких
процедур обработки, как поиск, хранение, выборка информации; значительно
сокращают время ее передачи по каналам связи.
Кодирование информации производится по определенной системе — со-
вокупности правил, определяющих построение кода.
Кодовые обозначения могут включать цифры, буквы и вспомогательные
символы. Совокупность знаков, которые могут быть использованы для постро-
ения кода, составляет его алфавит. Количество знаков, входящих в алфавит ко-
да, определяет основание кода (например, для алфавита русского языка основа-
ние кода равно 33).
Кодовое обозначение характеризуется длиной, структурой и степенью
информативности.
Длина кодового обозначения измеряется количеством знаков в коде.
Структура кодового обозначения определяется порядком расположения
знаков в коде.
129
 Степень информативности кодового обозначения представляет собой
отношение числа закодированных признаков к длине кода.
В зависимости от того, предшествует ли кодированию классифицирова-
ние объектов, все известные системы кодирования разделяют на регистрацион-
ные и классификационные системы.
Регистрационная система кодирования. Кодовые обозначения, постро-
енные по регистрационным системам кодирования, используются для иденти-
фикации объектов. Они не требуют предварительной классификации и незави-
симы от существа решаемых задач. К регистрационным системам кодирования
относятся порядковая и серийно-порядковая системы.
При использовании порядковой системы кодирования объекты кодиру-
ются в соответствии с текущим номером. Данная система кодирования приме-
няется, когда кодируемых объектов немного и используется только один при-
знак. При этом код с постоянной длиной называется равномерным, а с пере-
менной — неравномерным. Несмотря на ряд достоинств (малую значность и
большую плотность кода), порядковая система не предусматривает группиров-
ки объектов по признакам и не обладает возможностями простой корректиров-
ки при добавлении новых объектов. Все это ограничивает использование по-
рядковой системы в рамках стабильных номенклатур (например, отрасли
народного хозяйства, категории работающих и т. п.).
Серийно-порядковая система кодирования предполагает предварительное
разбиение кодируемого множества объектов на подмножества по некоторому
признаку. Каждой группе объектов выделяется серия кодовых обозначений, в
пределах которой каждому объекту присваивается номер по порядку. Кодиро-
вание в данном случае производится не по классификационным признакам, а в
регистрационном порядке.
Размер каждой серии кодов определяется с расчетом на возможные до-
полнения объектов кодирования.
Серийно-порядковая система кодирования обладает теми же преимуще-
ствами и недостатками, что и порядковая система. Но в отличие от последней в
серийно-порядковой системе предусмотрена дополнительная информация, по-
лезная при решении задач обработки данных.
Классификационные системы кодирования разделяются на последова-
тельные и параллельные. Эти системы предполагают предварительное класси-
фицирование кодируемого множества объектов.
Последовательная система кодирования используется, как правило, при
иерархической системе классификации. В этом случае каждому признаку клас-
сификации в кодовом обозначении объекта отводится соответствующее коли-
чество разрядов. Таким образом, код нижестоящей группировки образуется пу-
тем добавления соответствующего кода к коду вышестоящей группировки.
Последовательная система кодирования обладает теми же преимуще-
ствами и недостатками, что и иерархическая система классификации. Кодовое
обозначение, построенное по данной системе, как правило, имеет большую
длину и сложную структуру.

130
 Параллельная система кодирования предназначена для обозначения объ-
ектов, характеризуемых несколькими независимыми признаками, она соответ-
ствует фасетной системе классификации. Каждой фасете из структурной фор-
мулы выделяется определенный разряд или группа разрядов кодового обозна-
чения. Причем значение признака, указанного в любом разряде кода, не зависит
от значений признаков, записанных в других разрядах. Это позволяет по кон-
кретному кодовому обозначению определить, набором каких признаков описы-
вается рассматриваемый объект.
Данная система кодирования хорошо отражает многоаспектную класси-
фикацию, позволяет строить коды с высокой гибкостью структуры. Можно лег-
ко увеличить число кодируемых признаков классификации и заменять отдель-
ные фасеты. Однако параллельная система дает избыточные коды со значи-
тельно меньшей степенью информативности, чем последовательная система.
Кроме последовательной и параллельной систем, для кодирования боль-
ших многопризнаковых номенклатур, одновременно характеризующихся и со-
подчиненностью, и независимостью отдельных классификационных признаков,
используется комбинированная система кодирования, базирующаяся на соче-
тании принципов кодирования рассмотренных систем.
Комбинированная система, так же как и позиционная, предусматривает
четкое выделение всех признаков номенклатуры. Но при этом каждый признак
может кодироваться по любой системе: порядковой, серийной или позицион-
ной. Комбинированная система более гибкая и широко применяется при реше-
нии экономических задач, поскольку обеспечивает автоматическое получение
всех необходимых итогов в соответствии с выделенными признаками.
Последовательность разработки позиционных и комбинированных систем
кодирования следующая:
 определяется число группировочных признаков и их соподчинен-
ность;
 устанавливается число позиций в каждом группировочном признаке;
 производится кодирование порядковыми номерами сначала старшего
признака, затем следующих признаков внутри старших, каждый раз, начиная с
1,01,001, в зависимости от значности младшего признака в пределах его стар-
шего признака;
 составляется классификатор.
Кроме названных систем кодирования, используется еще код повторения
и шахматная система, имеющие ограниченное применение. В качестве кода
повторения выступают номера каких-то номенклатур, например, гаражный но-
мер автомашины, номер склада и др. Шахматная система применяется для ко-
дирования двухпризнаковых номенклатур с устойчивой связью. Она строится в
виде таблицы и напоминает позиционную систему.
Рассмотрим практические примеры построения некоторых кодов, исполь-
зуемых при обработке учетной и банковской информации.
Коды счетов бухгалтерского учета широко применяются как при ручной
обработке, так и в условиях компьютеризации. При существующей системе
учета код счетов бухгалтерского учета составляет четыре знака: первых два —
131
балансовые счета, два вторых — субсчет, который устанавливается на пред-
приятии, в организации (фирме). Система балансовых счетов, используемых в
международном учете, предусматривает для выделения субсчетов четыре раз-
ряда. В проектах компьютерной обработки бухгалтерского учета встречаются
различные подходы к построению кода аналитического учета. Как правило,
структура кода отличается различным уровнем аналитичности и значностью.
Программы позволяют вести учет по разным вариантам, уровням аналитики
(разным признакам), которые устанавливаются на конкретном предприятии, в
организации (фирме).
Построение кода счетов бухгалтерского учета имеет большое значение в
тех программах, которые не предусматривают локальную обработку отдельных
участков учета, где весь учет выполняется на основании ведения журнала хо-
зяйственных операций, что характерно для небольших предприятий. Гибкая си-
стема построения кода позволяет при этом выполнять аналитические разработ-
ки с различной степенью детализации. Уровни аналитики — это те признаки,
по которым группируются данные.
Например, для счета 70 «Рабочие и служащие» можно выделить два
уровня: первый — для подразделения, второй — для табельных номеров.
В данном случае аналитические сводки будут составлены в разрезе подразделе-
ний и табельных номеров. Для счета 10 «Материалы», например, можно выде-
лить три уровня аналитики:
 первый — вид материальных ценностей (1 знак);
 второй — склад (1 знак);
 третий — номенклатурный номер материалов (2 знака).
Предположим, на предприятии имеются 7 видов материалов и 99 их
наименований, которые могут располагаться на трех складах.
Закодируем эти наименования.
Признак Кодовое обозначение
а) виды материалов:
сырье и материалы 1
полуфабрикаты 2
топливо 3
запасные части 4
прочие материалы 5
тара 6
строительные материалы 7
б) склады:
сырья и материалов 1
топлива 2
строительных материалов 3
в) материалы
краска масляная 01
белила цинковые 02
гвозди отбойные 03
и т. д.

132
 Приведем пример построения кода краски масляной с учетом зависимо-
сти всех выделенных признаков:
Балансовый счет 10
Строительные материалы 7
Склад строительных материалов 3
Номенклатурный номер масляной краски 01
Общий вид кода 107301
Код многозначный, с выделением четырех признаков, построен по пози-
ционной системе.
При оприходовании и отпуске материалов в первичном документе долж-
ны быть проставлены все эти коды. В этом случае при компьютерной обработке
будет обеспечено получение различных сводок синтетического и аналитическо-
го учета в разрезе балансовых счетов, складов, номенклатурных номеров мате-
риалов и их видов.
Система автоматизированной обработки банковской информации также
предусматривает использование большого количества обозначений номенкла-
тур кодовыми знаками. Наиболее сложным является код лицевого счета. Струк-
тура этого кода с 1998 г. строится в соответствии с новым планом счетов и
международным стандартом.
Указаниями Центробанка России рекомендуется сложная структура лице-
вого счета, построенная по комбинированной системе и включающая до 11 раз-
личных признаков (табл. 6.1). Значимость кода составляет 20 знаков, но может
быть расширена и до 25 разрядов.
Таблица 6.1
Структура кода лицевого счета
Количество раз- Номер
№ Признак
рядов признака позиции
1 1 1 Номер балансового раздела
2 2 2–3 Номер счета первого порядка
3 2 4–5 Номер счета второго порядка
4 3 6–8 Код валюты
5 1 9 Защитный ключ
6 2 10–11 Номер филиала
7 2 12–13 Номер подразделения
8 5 14–18 Номер счета (порядковый)
9 2 19–20 Аналитический код
10 2 21–22 Код внутренней аналитической группы
11 3 23–25 Код внутренней группы
Понятие единой системы классификации и кодирования
С помощью описанных выше систем классификации и кодирования стро-
ятся классификаторы технико-экономической информации.
Для обеспечения взаимодействия между организациями существует не-
сколько методов информационной увязки применяемых классификаторов.
Первый метод характерен для систем с равноправными неприоритетны-
ми классификаторами. В этом случае на объектах используются локальные
133
классификаторы. При получении информации извне для каждого объекта
должна применяться своя система перекодирования.
Второй метод используется, когда во взаимодействующих системах упо-
требляются неравноправные, приоритетные классификаторы. Обработка ин-
формации ведется на базе локальных классификаторов, а обмен данными орга-
низуется в кодах классификаторов с большим приоритетом.
Третий метод предполагает, что для обработки информации в каждой
ЭИС используются локальные классификаторы, а для обмена — единый клас-
сификатор-посредник.
Четвертый метод характеризуется тем, что при обработке информации в
разных ЭИС используются единые классификаторы. При этом обмен информа-
цией не требует дополнительных работ по перекодированию.
Эталоном классификатора называется официальное издание классифика-
тора, удобное для его ведения (издается на соответствующих уровнях).
На различных уровнях народного хозяйства и даже на предприятиях од-
ного уровня могут использоваться различные классификаторы. Классификато-
ры, применяемые в рамках всего народного хозяйства, называются общесоюз-
ными (общероссийские — Постановление Правительства РФ от 01.11.99
№ 1212), в отдельной отрасли или организации — отраслевыми или локальны-
ми соответственно.
Общегосударственные классификаторы (ОК) начали создаваться в стране
по постановлению правительства в 1970-х гг., и в настоящее время их создано
около четырех десятков (Постановление Правительства РФ от 01.11.99 № 1212
«О развитии единой системы классификации и кодирования технико-
экономической и социальной информации»). Условно общегосударственные
классификаторы делятся на 4 группы.
1. Классификаторы общетрудовых и природных ресурсов, например, ОК
профессий рабочих, должностей служащих и тарифных разрядов (ОКПДТР).
2. Классификаторы структуры отраслей (ОК отраслей народного хозяй-
ства — ОКОНХ), органов управления (система обозначений органов государ-
ственного управления — СООГУ), административно-территориального деления
(система обозначений административно-территориальных объектов — СОАТО),
предприятий и организаций (ОКПО), форм собственности (ОКФС).
3. Классификаторы продукции (ОК промышленной и сельскохозяй-
ственной продукции — ОКП, ОК строительной продукции).
4. Классификаторы технико-экономических показателей (ОКТЭП),
управленческой документации (ОКУД), системы обозначений единиц измере-
ния и др.
Перечень общегосударственных классификаторов представлен на сайте
ГМЦ Росстата [18].
Рассмотрим построение некоторых из них.
Так, например, отраслевой идентификационный номер налогоплательщи-
ка (ИНН) — десятизначный; первый и второй знак означают территорию, тре-
тий и четвертый — номер государственной налоговой инспекции, остальные —
номер налогоплательщика и контрольный разряд (7604005043).
134
 ОК отрасли (ОКОНХ) предназначен для анализа структуры отраслей.
Код — пятизначный, построен по комбинированной системе и включает пять
группировочных признаков: отрасль, подотрасль, вид, группа, подгруппа.
ОК предприятий и организаций присваивается органами государственной
статистики предприятиям, организациям, фирмам любой формы собственности.
Состоит из трех блоков: 1 — регистрационный номер, 2 — наименование орга-
низации, 3 — ведомственная, территориальная и отраслевая принадлежность
предприятия, организации, фирмы. Регистрационный номер предоставляется
предприятиями и организациями в формах финансовой отчетности. Два других
блока используются органами государственной статистики для автоматическо-
го ведения ОКПО в электронно-вычислительной машине. Регистрационный
номер состоит из 7 знаков, построен по комбинированной системе, первые два
знака означают принадлежность к отрасли, последние — порядковый номер
предприятия, организации. Например, отрасли промышленности присвоен код
01, лесному хозяйству — 05 и т. д.
Для обеспечения информационной совместимости ЭИС разных уровней
разработана Единая система классификации и кодирования (ЕСКК).
Схема структуры ЕСКК приведена на рисунке 6.3.

Рис. 6.3
Схема структуры ЕСКК
ЕСКК предназначена для выполнения следующих функций:
 централизованной разработки общесистемных (общегосударствен-
ных) классификаторов;
135
  пополнения и обновления, своевременного и систематического опо-
вещения организаций обо всех изменениях, внесенных в классификаторы;
 ответов на разовые запросы;
 оптимизации структуры классификаторов;
 проведения работы по созданию информационно-поисковых языков.
В состав ЕСКК входят три составные части.
Первая ее часть — «Комплекс нормативно-технических и методологиче-
ских материалов» — включает в себя документы, которые регламентируют:
 состав системы, цели системы, задачи и всю используемую термино-
логию системы;
 принципы и методы классификации и кодирования;
 категории и сферы действия классификаторов;
 принципы сопряжения и взаимодействия классификаторов;
 структуру работ по созданию и внедрению системы.
Второй частью является «Комплекс общесистемных классификаторов
(ОК)», в который входят следующие группы классификаторов.
Классификаторы о природных и трудовых ресурсах:
 профессий рабочих;
 должностей служащих;
 кадров;
 специальностей;
 полезных ископаемых и т. д.
Классификаторы о продуктах труда и производственной деятельности:
 промышленной и сельскохозяйственной продукции; строительной
продукции;
 деталей;
 услуг: в промышленности, строительстве, сельском хозяйстве,
транспорте, материально-техническом снабжении;
 услуг населению.
Классификаторы структуры народного хозяйства и объектов админи-
стративно-территориального деления:
 предприятий и организаций;
 отраслей народного хозяйства;
 стран;
 органов государственного управления;
 объектов административно-территориального деления; пунктов по-
грузки и разгрузки.
Классификаторы управленческой информации и документации:
 единиц измерения;
 технико-экономических показателей; управленческой документации;
 технической документации, обозначений стандартных и технических
условий;

136
  технологической документации;
 операций и деталей.
Перечень ОК приведен в Приложении 3.
Все общесистемные классификаторы, в зависимости от используемой си-
стемы классификации в процессе их проектирования, построены по двум прин-
ципам.
Первый принцип основывается на идентификации объектов внутри клас-
сификационных группировок. Для примера рассмотрим структуру Общесистем-
ного классификатора промышленной и сельскохозяйственной продукции (ОКП),
который основывается на использовании иерархической системы классификации
и состоит из двух блоков: блока наименований и блока идентификации.
Блок идентификации состоит из классификационной, регистрационной и
контрольной части кода (рис. 6.4).

Рис. 6.4
Схема структуры ОКП
Классификационная часть включает группировки по следующим призна-
кам:
 класс;
 подкласс;
 группа;
 подгруппа;
 вид.
Второй принцип основан на применении раздельной идентификации и
классификации и фасетной системе классификации, что отражается в структур-
ной формуле классификатора, которая включает три блока: идентификации,
классификации и наименования.
Для примера рассмотрим структуру Общесистемного классификатора
предприятий и организаций (ОКПО). Этот классификатор основан на использо-
вании фасетной системы классификации.
137
 Он состоит из трех блоков (рис. 6.5):
1) блока идентификации, включающего в себя код отрасли, регистраци-
онный номер предприятия и контрольную часть кода;
2) блока наименований;
3) блока классификации, состоящего из следующих фасетов:
⎯ фасета подчиненности — Ф1, в котором можно выделить признаки:
код министерства, код управления, код треста;
⎯ фасета административно-территориальной принадлежности — Ф2;
⎯ фасета отраслевой принадлежности — Ф3.

Рис. 6.5
Схема структуры ОКПО
Для успешного внедрения и использования общесоюзных классификато-
ров в нашей стране создана система служб, призванная обеспечить адекват-
ность классификаторов состоянию народного хозяйства и их распространению
потребителям. Система ведения общесоюзных классификаторов включает три
уровня. Общее руководство работами по ведению общероссийских классифи-
каторов осуществляет Федеральное агентство по техническому регулированию
и метрологии (Росстандарт). Оно также координирует деятельность учрежде-
ний, ответственных за ведение общероссийских классификаторов, обеспечивает
их экспертизу, утверждение вносимых изменений и их представление в Россий-
ское статистическое агентство.
Российское статистическое агентство (Росстат) обеспечивает ведение об-
щероссийских классификаторов, в том числе в рамках автоматизированного
банка общероссийских классификаторов с использованием информационно-
вычислительной сети агентства.
Учреждения, ответственные за ведение общероссийских классификаторов
(Росстат, Минэкономики России, Минобрнауки России, Минтруд России, Банк
России, Госстрой России, Минюст России и др.), обеспечивают ведение закреп-
ленных за ними классификаторов, подготавливают предложения о внесении в
них изменений и представляют их в Федеральное агентство по техническому
регулированию и метрологии (см. также п. 12, 13, 14, 15 «Положения о проведе-
нии работ…», утвержденного Постановлением Правительства РФ от 01.11.1999
№ 1212, с. 4).
138
Технология и области применения штрихового кодирования
Штриховое кодирование является одним из типов автоматической иден-
тификации, использующим метод оптического считывания информации. Оно
основывается на принципе двоичной системы счисления: информация запоми-
нается как последовательность 0 и 1. Широким линиям и широким промежут-
кам присваивается логическое значение 1, узким — 0.
В связи с этим штриховое кодирование — это способ построения кода с
помощью чередования широких и узких, темных и светлых полос.
Существуют следующие виды штриховых кодов.
UPC — универсальный товарный код; разработан в США и применяется в
странах Америки.
EAN — товарный код; создан в Европе на базе UPC; соответствует назва-
нию Европейской ассоциации товарной нумерации, получившей в настоящее
время статус Международной организации (EAN International).
UCC/EAN — единый стандартизованный штриховой код; создан объеди-
ненными усилиями организаций США и EAN International.
EAN и UCC/EAN находят применение во многих странах мира, в том
числе и в Российской Федерации.
В соответствии с видами различаются следующие штриховые коды: UPC-
12 (рис. 6.6 и 6.7), EAN-13 (рис. 6.8 и 6.9), EAN-14, EAN-8 (рис. 6.10 и 6.11),
UCC/EAN-128 (Code 39).

Рис. 6.6
Структура двенадцатиразрядного кода UPC-12

Рис. 6.7
Пример кода UPC-12
В приведенном примере:
3 — код лекарственных препаратов США;
00025 — код производителя;
00234 — код продукта;
9 — контрольное число.

139
 Рис. 6.8
Структура тринадцатиразрядного кода EAN-13,
используемого для кодирования продукции

Рис. 6.9
Пример кода EAN-13
В приведенном примере:
460 — код страны;
0023 — код производителя;
10012 — код продукта;
9 — контрольное число.

Рис. 6.10
Структура восьмиразрядного кода EAN-8,
который используется для кодирования малогабаритных упаковок

Рис. 6.11
Пример кода EAN-8
EAN-14 — четырнадцатиразрядный код с прямоугольным контуром. Он
состоит из 13 разрядов, которые располагаются по значению в той же последо-
вательности, что и EAN-13, и одного дополнительного разряда. Этот дополни-
тельный разряд указывается первым и отражает специфику упаковки цифрами
от 1 до 8. Например, 1 — групповая упаковка, 2 — упаковка партий в контей-
нер и т. д.

140
 Основное назначение EAN-14 — идентификация транспортной упаковки
(рис. 6.12).

Рис. 6.12
Пример кода EAN-14
Code 39 получил свое название по сочетаемости элементов — три из де-
вяти. В каждом знаке три элемента являются широкими, остальные шесть —
узкими. Для отображения кода используются 43 символа, включая все пропис-
ные буквы, цифры от 0 до 9 и семь особых знаков (- . $ / + % пробел). Code 39
также не имеет фиксированной длины, может варьироваться до 40 разрядов.
Современной версией кода Code 39 является UCC/EAN-128, что позволя-
ет сэкономить много места (рис. 6.13).

Рис. 6.13
Пример кода UCC/EAN-128
В приведенном примере:
(01) — идентификатор применения кода EAN-14;
14600023100126 — код EAN-14;
(3101) — идентификатор применения веса нетто;
вес нетто — 35,5 кг;
(10) — идентификатор применения номера партии;
АВС-123 — номер партии.
Идентификатор применения представляет собой цифровое стандартизи-
рованное обозначение наименования реквизита, например (01) — цифровое
стандартизированное обозначение кода EAN-14, (3101) — обозначение веса
нетто (в кг) с указанием количества знаков после запятой; (10) — обозначение
номера партии.
Применение штриховых кодов UPC-12, EAN-13, EAN-14, EAN-8 регули-
руется международными и национальными организациями. В частности, в Рос-
сийской Федерации такой организацией является Ассоциация автоматической
идентификации, насчитывающая в настоящее время свыше 2000 членов. Эта
организация устанавливает номера предприятий в кодах EAN-13 и EAN-8. Код
страны присваивается EAN International. Использование кодов UCC/EAN-128
(Code 39) регулируется соответствующими международными и национальными
стандартами.

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

142
 Товары поступают на склад магазина обычно в виде крупной партии в
контейнерах, в деревянной, картонной или какой-либо другой таре, на которые
наклеена сопроводительная этикетка. При этом различаются два случая оформ-
ления этикеток: с наличием или отсутствием штрихового кода EAN-14. По-
ступление товара также сопровождается накладной.
Принятый товар оформляется товароведом, который оперативно вносит
информацию с накладных в компьютер. При поступлении товара с нанесенным
на этикетку штриховым кодом, последний считывается сканером, и информа-
ция с этикетки дополнительно к информации с накладных передается на ком-
пьютер. В компьютере производятся сравнение на соответствие штрихового
кода требованиям, предъявляемым к EAN-14 стандартами Российской Федера-
ции, а также предварительная обработка данных. Этой операцией подтвержда-
ется поступление товара на склад магазина.
Если штриховой код на этикетке отсутствует, с помощью специализиро-
ванной программы товаровед кодирует товары и печатает этикетки со штрихо-
выми кодами. Для этого рабочее место товароведа оснащено техническими
устройствами для маркировки товаров: термотрансферным принтером для пе-
чати этикеток, соединенным с персональным компьютером, и этикет-
пистолетом для наклеивания этикеток на упаковку товара.
Складирование и хранение товара на складах. Кладовщик размещает
принятый к реализации товар для хранения его на складе. Стеллажи, на кото-
рые укладывается товар с этикетками, также оснащены соответствующими
бирками со штриховыми кодами. Это позволяет автоматически определить ме-
сто нахождения товара. Штриховые коды на товаре в местах хранения считы-
ваются сканером для того, чтобы получить подтверждение о правильности ме-
стонахождения товара, и информация об этом передается в компьютер.
Подготовка товара к реализации. В процессе подготовки к реализации
могут возникнуть случаи, когда товар может содержаться в единичной упаков-
ке внутри контейнера или тары либо находиться в россыпи. Если товар имеет
единичную упаковку, то на нее необязательно может быть нанесен штриховой
код EAN-13. В случае необходимости с помощью технических устройств кла-
довщик осуществляет маркировку товаров.
При поступлении товара в россыпи он фасуется в мелкие партии, взвеши-
вается и упаковывается с нанесением кода EAN-13. Подготовленный таким об-
разом товар подается в торговый зал.
Торговый зал. В торговом зале покупатель набирает необходимые про-
дукты в тележки и подходит для оплаты к кассиру-контролеру. Рабочее место
кассира-контролера оснащено сканером для считывания штриховых кодов, со-
единенным с кассовым аппаратом. Кассовый аппарат, в свою очередь, соединен
с компьютером, в память которого занесены штриховые коды всех имеющихся
товаров и соответствующие им цены, устанавливаемые магазином, кассир про-
веряет на кассовом аппарате стоимость покупки, используя сканирующее
устройство.
Рабочее место кассира-контролера представлено на рисунке 6.14.

143
 Рис. 6.14
Рабочее место кассира-контролера
Оперативный контроль наличия товаров в торговом зале и на складе.
При поступлении заказов на продукцию компьютер идентифицирует предмет
поставки и его местонахождение. Штриховые коды считываются и сверяются с
каждым заказом. Выявляются дефициты и расхождения, а затем выдается в ав-
томатическом режиме соответствующая заказу накладная на перемещение то-
вара со склада в торговый зал. Оперативный контроль позволяет получать ин-
формацию об объеме продаж, запасах продукции на складах и их наличии в
торговом зале, изменениях цен реализации в соответствии с рыночной ситуаци-
ей. Рабочие места товароведов, кладовщиков, кассиров-контролеров и руково-
дящего персонала магазина (директора, бухгалтера, менеджера) объединяются
в единую вычислительную сеть.
Применение штрихового кодирования в супермаркете дает большой эф-
фект за счет уменьшения трудоемкости и затрат на поиск и хранение, доставку,
инвентаризацию продукции и координацию деятельности многих специали-
стов; приводит к сокращению управленческого персонала, занятого подготов-
кой и оформлением документации; способствует увеличению объема реализа-
ции продукции и товарооборота на основе уменьшения времени прохождения
товара на всех операциях движения продукции.
Кроме супермаркетов, в Российской Федерации штриховые коды начали
использоваться в библиотеках для идентификации читательских билетов и
книг, в медицине на станциях переливания крови для идентификации доноров и
характеристик крови. В перспективе применение штриховых кодов будет при-
ближаться к международному уровню.
На международном уровне штриховые коды внедрены не только в сферу
торговли. В официальном электронном справочнике ООН (по состоянию на ян-
варь 1997 г.) определены следующие области использования штрихового коди-
рования: учет, таможенный контроль, пенсионное обеспечение, здравоохране-
ние, социальное страхование, судебная практика, трудоустройство, статистика,
строительство, финансы, промышленность, туризм, торговые сделки и др.

144
В настоящее время штриховые коды нашли применение в сельском хозяйстве и
рыбной промышленности (Нидерланды), в охране окружающей среды (Синга-
пур), в идентификации упаковок монет и банкнот (Дания), при предоставлении
телефонных счетов к оплате (Коста-Рика), в грузовых перевозках для отслежи-
вания движения грузов по железным дорогам (Новая Зеландия).
Возможности развития системы штрихового кодирования далеко не ис-
черпаны.
Система оперативного сбора данных может развиваться как по пути уве-
личения количества точек сбора данных, так и в направлении использования
усовершенствованных систем считывания штриховых кодов. Например, могут
быть использованы лазерные сканеры со встроенным миниатюрным радиопе-
редатчиком с радиусом действия до 12–15 метров.
В перспективе предусматривается использование спутниковых каналов
связи для электронного обмена данными (ЭОД) с установкой контрольных ин-
формационных пунктов на сортировочных станциях железной дороги, на авто-
мобильном, воздушном, морском и речном видах транспорта.
Баркоды
В последнее время все больше и большее распространение получили мат-
ричные коды, они же 2D баркоды (2D barcode), QR коды, Datamatrix коды,
и т. п. QR-код (от англ. quick response — быстрый отклик) — матричный код
(двумерный штрихкод), разработанный и представленный японской компанией
Denso-Wave в 1994 г.
От обычных штрихкодов 2D-коды отличаются тем, что информация за-
писывается сразу в двух измерениях, т. е. если в штрихкоде считываются тол-
щина вертикальных полос и расстояние между ними, то в 2D-коде информация
записывается и по горизонтали, и по вертикали.
Таким образом, двухмерные баркоды позволяют хранить гораздо больше
информации, чем привычный нам штрихкод. Кроме того, когда информация
кодируется в матричный код, к ней добавляется информация для восстановле-
ния, что позволяет прочитать зашифрованную в коде информацию даже при ча-
стичном повреждении баркода (рис. 6.15).

Рис. 6.15
Пример баркода

145
 Для чего же можно использовать матричные коды? С торговлей и логи-
стикой понятно, но какую пользу может извлечь из этого простой обыватель?
Снова приведем пример. Человек протягивает вам визитку, на которой его имя,
фамилия, телефон, e-mail, адрес сайта, адрес компании и т. п. Наверняка вам
хотелось бы поместить контактные данные этого человека к себе в телефон.
Представляете, сколько времени у вас уйдет на добавление контакта? Допу-
стим, вы довольно быстро умеете обращаться со своим телефоном и уложитесь
в 2 минуты. Теперь представьте себе, что на обратной стороне визитки напеча-
тан 2D-баркод и, чтобы добавить контакт со всей информацией в телефон, вам
нужно запустить на нем приложение для считывания баркодов, навести камеру
телефона на баркод и подтвердить добавление контакта, нажав одну кнопку. На
все манипуляции у вас уйдет не больше 10 с.
Для сканирования QR-кодов и других баркодов используют мобильный
телефон с камерой. Сейчас существует большое количество мобильных прило-
жений, позволяющих распознать QR-код. Для этого достаточно лишь запустить
такое приложение на своем телефоне, навести камеру телефона на изображение
QR-кода и получить расшифрованную информацию. Наиболее часто с помо-
щью QR-кодов зашифровывают тексты, ссылки на сайты, контактную инфор-
мацию, номера телефонов, GPS-координаты.
Это только один из возможных вариантов применения QR-кодов. Основ-
ной особенностью кодов является высокая скорость передачи информации с
напечатанного кода в мобильное устройство. Это открывает большие возмож-
ности, в частности для рекламы, т. е. внедрив QR-код в рекламный щит, постер
или объявление и даже в рекламный ролик, можно в итоге получить больше
клиентов. Потому что многие отсканируют код и автоматом добавят контакт-
ную информацию компании к себе в телефон или перейдут по закодированной
интернет-ссылке на сайт рекламодателя.
Помимо этого сейчас QR-коды используются как электронные билеты.
Вы оплачиваете билет с кредитной карты через Интернет, и вам на телефон
присылается изображение QR-кода. Затем, приложив телефон с QR-кодом на
экране к считывателю кодов, вы можете пройти на мероприятие. Такие билеты,
например, использует всем известный аэроэкспресс.
Примеров использования QR-кодов можно придумать великое множе-
ство, если приложить фантазию. Это всевозможные акции, игры, передача ин-
формации о товарах и услугах, сувенирная продукция и многое другое.
Существующие на данный момент приложения для считывания баркодов
позволяют передавать ссылки, контакты, SMS, e-mail, GPS-координаты и, соб-
ственно, просто текст. Поскольку популярность баркодов растет, а это показы-
вает постоянно растущая активность обсуждений этой темы в Интернете, ло-
гично предположить, что это подтолкнет создателей софта для мобильных те-
лефонов к воплощению новых идей по использованию баркодов, что еще
больше повысит к ним интерес.

146
 6.3. Системы документации
Выше уже говорилось о том, что ЭИС объединяет в себе все бизнес-про-
цессы предприятия. Каждое предприятие имеет свою сферу деятельности, спе-
цифику работы, и поэтому набор бизнес-процессов и их содержание, как пра-
вило, различны для разных предприятий. Но можно смело утверждать, что лю-
бые предприятия и организации имеют бизнес-функцию, называемую докумен-
тооборотом.
Начнем с того, что деятельность любого предприятия похожа на фабрику
по обработке документов, так как все его производственные процессы докумен-
тируются. До эпохи компьютерной автоматизации существовали письма, фор-
мы, фотографии, докладные записки, счета и другие документы, на основе ко-
торых строился тот или иной бизнес-процесс, т. е. с каждым из них производи-
лись определенные операции. Все эти документы собирали в папки (дела), к ко-
торым прикрепляли маршрутный лист, а затем посылали по почте или с курье-
ром от специалиста к специалисту.
Мониторинг статуса отдельных пунктов бизнес-процесса (работы) произ-
водили менеджеры, извлекая на свет папки и просматривая написанные от руки
аннотации на маршрутной карте. Они росчерком пера в маршрутной карте мог-
ли изменить порядок прохождения той или иной «бумажки».
С появлением на предприятиях компьютеров документы (или часть их)
стали хранить уже в двух видах: бумажные, или, как мы их будем называть,
«твердые копии», и «электронные», т. е. документы, представляемые на ма-
шинных носителях информации (RAM, Hard disk, Floppy disk и т. д.). При этом
доля электронных документов все время возрастает.
Унифицированная система документов (УСД)
Развитие систем автоматизированной обработки информации, предусмат-
ривающих обмен информацией, потребовало унификации и стандартизации
всей документации, предназначенной для отражения экономической информа-
ции. Унификация документации была проведена в государственном масштабе в
1970-х гг. Так, постановлением «Унифицированные системы документации,
используемые в АСУ» определены требования к унифицированной документа-
ции (УСД), используемой в АСУ.
Унифицированная система документации включает комплекс взаимосвя-
занных документов, отвечающих единым правилам и требованиям построения.
Под документом понимается информационное сообщение на естествен-
ном языке, зафиксированное ручным или печатным способом на бланке уста-
новленной формы и имеющее юридическую силу.
Унификация документов, как известно, направлена, прежде всего, на:
 повышение эффективности управленческого труда;
 создание единой системы унифицированной документации, охватываю-
щей систему управления в целом, а не только ее автоматизированную часть (АСУ);
 обеспечение сопряжения систем документации и отдельных форм до-
кументов.

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

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

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

ются в класс. Так, первичная учетная документация объединена в класс 03, до-
кументация по материально-техническому снабжению и сбыту — в класс 08.
Код проставляется в форме документа в специально отведенной зоне, что
позволяет легко отличать унифицированную форму документа от неунифици-
рованной.
ОКУД позволяет классифицировать не только межотраслевые, но и от-
раслевые формы документов. Для них предусматривается семизначное кодовое
обозначение.

149
 Для отраслевых форм документов выделяется класс с цифрой «8» на пя-
том разряде, а для унифицированных форм документов предприятий (организа-
ций) — с цифрой «9». Если в ОКУД отсутствует класс или подкласс форм до-
кументов, необходимых министерству или республике, то используются ре-
зервные коды ОКУД, начиная с «51».
Отраслевые унифицированные формы документов и формы документов
предприятий должны сосредоточиваться соответственно в отраслевом класси-
фикаторе управленческой документации или классификаторе управленческой
документации предприятия (организации).
Типовые комплексы документов
Для обеспечения существования форм и содержания документов в соот-
ветствии с постановлением Правительства РФ (08.07.1997 г. № 835 и др.) раз-
работан «Альбом форм и первичной учетной документации».
Таблица 6.2
Перечень унифицированных систем документации
Сокращенное
Наименование Примечание
обозначение
Унифицированная система документации стандартов и
–
технических условий
Единая система конструкторской документации ЕСКД
Единая система технологической документации ЕСТД
Унифицированная система проектной документации по
УСПДС
капитальному строительству
Унифицированная система плановой документации УСПД
Унифицированная система отчетно-статистической до-
УСОСД
кументации
Унифицированная система первичной учетной докумен-
УСПУД
тации
Унифицированная система финансовой, первичной и от-
четной бухгалтерской документации бюджетных учре- УСФБД
ждений и организаций
Унифицированная система организационно-
УСОРД
распорядительной документации
Унифицированная система документации по материаль-
УСДМТС
но-техническому снабжению и сбыту
Унифицированная система документации по ценообра-
УСДЦ
зованию
Унифицированная система документации по внешней
УСДВТ
торговле
Унифицированная система расчетно-денежной докумен-
УСРД
тации
Унифицированная система документации по торговле УСДТ
Унифицированная система документации по социально- В стадии раз-
УСДСО
му обеспечению работки
Унифицированная система документации по изобрете- В стадии раз-
УСДИО
ниям и открытиям работки

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

151
 5. Осуществление размещения реквизитов по выбранной форме в соот-
ветствии с проведенной классификацией.
6. Выполнение расчета размеров документов по вертикали и горизон-
тали с учетом размера полей.
7. Выбор формата бумажного носителя.
8. Построение эскиза документа соответствующей формы.
9. Выделение толстой линией реквизитов, переносимых на машинный
носитель.
10. Редактирование шапок документов в соответствии со словарем-
тезаурусом.
Как правило, используют ряд типовых форм документов (рис. 6.16).
Например, линейная форма (а) отличается тем, что в ней каждому типу
реквизитов соответствует только одно значение этого реквизита, и они распола-
гаются по горизонтали.
Анкетная форма (б) используется также для однозначных реквизитов, но
этот набор реквизитов располагается по вертикали.
Табличная форма (в) используется для многозначных реквизитов, при этом
в ней столбцы содержат типы реквизитов, а строки отражают значения типов.
Наименование типов x(1) … x(i) … x(n)
реквизитов
Значения x(1, 1) … x(i, 1) … x(n, 1)
реквизитов
а) линейная форма документа
Наименование типов реквизитов Значения реквизитов
x(1) x(1, 1)
… …
x(i) x(i, 1)
… …
x(n) x(n, 1)
б) анкетная форма документа
Наименование типов реквизитов
x(1) … x(i) … x(n)
… …
Значения реквизитов
x(1, j) … x(i, j) … x(n, j)
… …
x(1, m) … x(i, m) … x(n, m)
в) табличная форма документа (для многозначных реквизитов)
Рис. 6.16
Схемы основных форм первичных документов
Как правило, для первичных документов, имеющих однозначные и мно-
гозначные реквизиты, применяют комбинированную форму, состоящую из трех
зон (рис. 6.17).

152
 I — заголовочная зона, предназначенная для однозначных реквизитов,
включающая группу справочных и группировочных признаков, используемых
при машинной обработке.
II — содержательная зона, включающая группу многозначных реквизи-
тов, предназначенных для пользователя и для машинной обработки, и включа-
ющая группу справочных признаков (1), совокупность группировочных при-
знаков (2) и группу реквизитов-оснований (3).
III — оформительная зона, в которой, как правило, располагаются подпи-
си должностных лиц.
Код формы

Наименование предприятия Код реквизита 1.1 Код реквизита Код реквизита

1.i 1.n
Наименование документа №
_______________

Наименование реквизита I
1.1 _____________________ зона

Наименование реквизита
1.2 _____________________

Наименование реквизита
1.3 _____________________
Наименова- Наименова-
ние реквизи- ние реквизи-
Наименование реквизита 2.j

та-основания та-основания
Наименование реквизита
Наименование реквизита

Наименование реквизита

2.(m-1) 2.m
Код реквизита 2.3

Код реквизита 2.j

II
зона
2.1

2.2

2.3

Подпись III
зона

Рис. 6.17
Макет первичного документа комбинированной формы
Особенности проектирования форм документов результативной
информации
В результате решения задачи рассчитываются результативные показате-
ли, которые требуется выдать на материальный носитель в виде, удобном для
153
пользователя. Так как результативный документ используется для осуществле-
ния процессов управления, то он должен отвечать следующим требованиям:
 полнота информации, т. е. результативные документы должны содер-
жать в себе первичные (исходные) и результативные показатели;
 количество результативных показателей должно соответствовать ко-
личеству группировочных признаков (количество итогов должно быть равно
количеству ключей сортировки);
 своевременность предоставления информации управленческому пер-
соналу;
 достоверность представляемой информации;
 хорошая читаемость (логичность построения форм и наличие хорошо
отредактированного текста шапок документов);
 отсутствие показателей, рассчитываемых вручную.
Можно выделить следующие принципы построения результативных до-
кументов (рис. 6.18):
 выделение трех зон в документе;
 разделение реквизитов на однозначные, т. е. имеющие одно значение
на документ, и многозначные реквизиты, имеющие несколько значений в доку-
менте;
 выделение группировочных реквизитов, помещаемых во вторую зо-
ну документа, и размещение этих реквизитов в порядке убывания старшинства;
Наименование предприятия Количество
листов _________
Наименование документа Номер листа

Наименование подразделения Количество экзем-

пляров____
(период времени) Номер экз. ______
Наименование

Наименование

Наименование
1-го признака

1-го признака

2-го признака

2-го признака

3-го признака

3-го признака

Коли- Сумма
Код

Код

Код

чество

Итоги по 3-му признаку . .

Итоги по 2-му признаку ..

Итоги по 1-му признаку …
Подпись Дата ____________

Рис. 6.18
Схема структуры результативного документа

154
  выделение реквизитов-оснований и размещение их в последователь-
ности, противоположной той, в какой выстраиваются группировочные реквизи-
ты, по которым рассчитываются итоги (т. е. от первичных оснований — к ре-
зультативным, а среди результативных — размещение их в порядке возраста-
ния старшинства итога);
 если документ не размещается на одном стандартном листе, то вы-
полнение разрыва строк и переноса оставшихся строк документа второй зоны
вместе с реквизитами третьей зоны на другой лист, сохраняя размеры листов
стандартными (при таком перенесении строк заголовки таблиц не переносятся,
а переносятся только номера колонок).
Построение результативных документов должно выполняться в следую-
щей последовательности.
1. Определение полного реквизитного состава документов.
2. Классификация реквизитов-признаков на справочные и группиро-
вочные; реквизитов-оснований — на первичные и результатные, а результат-
ных оснований — по степеням итогов.
3. Выбор формы документа (с одной или несколькими таблицами в со-
держательной части документа).
4. Размещение реквизитов в форме согласно их логической соподчи-
ненности.
Если длина строки документа, т. е. его ширина, больше ширины каретки
печатающего устройства (с учетом возможного уменьшения размеров шрифта),
то перегруппировка реквизитов таблицы осуществляется с использованием
следующих методов:
 вынос итоговых колонок в итоговые строки;
 перенос не уместившихся в листе колонок на новый лист с продол-
жением нумерации колонок (такие документы затем склеиваются).
При этом осуществляется выделение в правой части первой зоны специ-
альной области для служебных реквизитов (количество листов в документе,
номер текущего листа, количество экземпляров, номер экземпляра).
Унификация типов носителей и форматов документов
При унификации документации на бумажном носителе устанавливаются
допустимые форматы.
В соответствии с ГОСТ 9327-60 «Бумага. Потребительские форматы»
приняты три ряда потребительских форматов бумаги: А, В и С.
Для управленческой документации установлен ряд А. Он строится деле-
нием предшествующего большого формата на две равные части, параллельно
меньшей его стороне (рис. 6.19).
Все форматы геометрически подобны и имеют одинаковое отношение
сторон:
x/y= 1 : 2 (рис. 6.20).
Основным форматом является формат А0, площадь которого равна одно-
му квадратному метру:
x  y = 1 м2, где x = 0,841 м; y = 1,189 м.
155
 Рис. 6.19
Пример деления
Каждый формат обозначается двумя символами: буквой А, указывающей
на принадлежность ряду А, и цифрой, обозначающей сколько раз разделен ис-
ходный формат А0. Ряд А содержит 14 форматов: А0–А13, но для управленче-
ской унифицированной документации установлены лишь 4 размера: А3, А4,
А5, А6. Допускается расположение реквизитов параллельно как длинной, так и
короткой стороне листа.

Рис. 6.20
Геометрическое подобие форматов ряда А
Размеры этих форматов, а также их обозначение по ЕСКД приведены в
таблице 6.3.
Таблица 6.3
Размеры форматов документов
Обозначение Размеры, Обозначение
по ГОСТ мм по ЕСКД ГОСТ 2.301-68
А3 297 × 420 12
А4 210 × 297 11
А5 148 × 210 –
А6 105 × 148 –

156
 Допуски на форматы не превышают 1,5 мм при размерах до 150 мм и
2 мм при размерах не более 600 мм. Для ЕСКД в соответствии с ГОСТ 2.301-68
«ЕСКД. Форматы» допускается дополнительное применение форматов А0, А1,
А2, а также построение дополнительных форматов путем увеличения сторон
форматов ряда А на величины, кратные размерам формата А4. При этом коэф-
фициент кратности должен быть целым числом.
Установлены единые размеры полей для выбранных форматов:
 левое — не менее 20 мм;
 верхнее — не менее 10 мм;
 правое и нижнее — не менее 7 мм.

6.4. Внутримашинное информационное обеспечение

Интегрированные БД, распределенные БД
Внутримашинное информационное обеспечение (ИО) включает все виды
организованной информации, представленной в виде, удобном для восприятия
техническими средствами. Это файлы (массивы), базы и банки данных, базы
знаний, а также их системы. Информационное обеспечение должно быстро и в
полном объеме удовлетворять информационные потребности всех пользовате-
лей информационных технологий. К нему предъявляются требования эффек-
тивного поиска и выдачи данных в виде, необходимом для решения каждой
конкретной задачи, наличия возможности поддержания данных в состоянии по-
стоянного обновления и работоспособности.
По содержанию внутримашинное обеспечение представляет собой сово-
купность фактических сведений, используемых в хозяйственной деятельности
объекта. Состав и структура внутримашинного информационного обеспечения
определяются способами организации файлов, баз и банков данных, взаимодей-
ствием между ними, развитием их во времени.
Пофайловая организация ИО состоит в формировании различных масси-
вов. Классифицировать их можно по различным признакам: по смысловому со-
держанию, способам использования, назначению, методу организации.
Файл — это совокупность однородной по составу и последовательности
полей информации, записанной на магнитном диске с присвоением имени.
Терминологически понятия «массив» и «файл» близки по содержанию.
И тот, и другой представляют собой совокупность однородной жестко органи-
зованной и поименованной информации. Однако для файла точно определено
место его расположения — магнитный диск, а массив информации может быть
расположен в памяти ЭВМ, может быть представлен совокупностью однород-
ных бумажных документов.
По смысловому (семантическому) содержанию выделяют массивы и про-
граммные массивы. Программные массивы описывают процессы работы с дан-
ными и входят в подсистему программного обеспечения. Массивы данных яв-
ляются основной частью внутримашинного информационного обеспечения.
Назначение массивов зависит от задач, стоящих перед информационными
технологиями, и отражает их специфику.
157
 По роли в машинной обработке и технологии использования массивы
классифицируются следующим образом.
Постоянные массивы относятся к категории нормативно-справочных, со-
ставляют информационный базис ЭИС и содержат сравнительно редко меняю-
щиеся сведения. В их состав включаются массивы классификаторов, справоч-
ников, каталогов и прочей условно-постоянной информации. В массивах клас-
сификаторов хранятся коды и тексты показателей хозяйствующего субъекта.
Формируются они до начала эксплуатации системы. В процессе работы они об-
новляются и изменяются по мере надобности.
Текущие (переменные) массивы включают переменную информацию, по-
ступающую в систему от управляемого объекта и характеризующую состояние
внешней среды, а также сам процесс управления объектом. Чаще всего они обра-
зуются на основе первичных документов. Примеры текущих массивов: массив
отчетных авизо, массив расчета проекта плана поступления налога с оборота.
Промежуточные массивы возникают на этапах решения задач и играют
роль механизма, передающего информацию от задачи к задаче или внутри за-
дач. Формирование этих массивов связано с потребностью в промежуточной
информации, не имеющей самостоятельного значения для целей управления.
Выходные массивы хранят информацию, полученную в результате обра-
ботки исходной информации. Они содержат совокупность показателей, необхо-
димых для анализа и принятия управленческих решений на уровне руководите-
ля подразделений (данные по лицевым счетам, численности работающих, фон-
ду заработной платы и т. д.).
Хранимые массивы чаще всего формируются на основе выходных и со-
держат информацию, необходимую для обработки в будущих отчетных перио-
дах, для сравнения, сопоставления данных за разные отчетные периоды, для
расчета нарастающим итогом.
Поисковые (информационные) массивы представляют собой совокупность
показателей, записей, ключей поиска, характеризующих либо содержание опре-
деленных документов, либо конкретный объект, систему, организацию и т. д.
Служебные массивы содержат вспомогательную информацию, необхо-
димую для обработки всех остальных видов массивов.
Все виды массивов составляют информационный фонд компьютерной си-
стемы, представляющий собой динамическую совокупность взаимосвязанных
элементов информации. Создание единого информационного фонда обеспечи-
вает систематизацию и унификацию показателей, позволяет установить терми-
нологическое единство, однозначность описаний и связей между показателями
во внутримашинном ИО.
По внутренней организации файлы данных представляют собой совокуп-
ность записей (аналогично строкам документа) одинаковой структуры. Струк-
тура записи файла состоит из заданной последовательности полей определен-
ного типа данных и длины. Такая структура файла определяется на этапе по-
становки задачи.
При увеличении объемов информации для многоцелевого применения и
эффективного удовлетворения информационных потребностей различных
158
пользователей используется интегрированный подход к созданию внутрима-
шинного ИО. При этом данные рассматриваются как информационные ресурсы
для разноаспектного и многократного использования. Внутримашинное ин-
формационное обеспечение в настоящее время проектируется на принципе ин-
теграции в виде базы и банка данных.
База данных (БД) — это специальным образом организованное хранение
информационных ресурсов в виде интегрированной совокупности файлов,
обеспечивающей удобное взаимодействие между ними и быстрый доступ к
данным.
Банк данных (БнД) — это автоматизированная система, представляющая
совокупность информационных, программных, технологических средств и пер-
сонала, обеспечивающих хранение, накопление, обновление, поиск и выдачу
данных. Главными составляющими банка данных являются база данных и про-
граммный продукт, называемый системой управления базой данных (СУБД).
Использование принципов базы и банка данных предполагает организа-
цию хранения информации в виде базы данных, где все данные собраны в еди-
ном интегрированном хранилище и к информации как важнейшему ресурсу
обеспечен широкий доступ разнообразных пользователей.
Такая организация данных решает целый ряд проблем:
⎯ отпадает необходимость в каждой прикладной программе детально
решать вопросы организации файлов;
⎯ устраняется многократный ввод и дублирование одних и тех же дан-
ных;
⎯ не возникает проблем изменения прикладных программ в связи с за-
меной физических устройств или изменения структуры данных;
⎯ повышается уровень надежности и защищенности информации;
⎯ уменьшается избыточность данных.
Перечисленные достоинства обеспечиваются способами логической и
физической организации данных, закладываемыми на стадии проектирования
внутримашинного информационного обеспечения.
Оценка и выбор альтернативных вариантов организации БД
Существуют следующие способы организации информационной базы
(ИБ): совокупность локальных файлов, поддерживаемых функциональными па-
кетами прикладных программ, и интегрированная база данных, основывающая-
ся на использовании универсальных программных средств загрузки, хранения,
поиска и ведения данных, т. е. системы управления базами данных (СУБД).
Локальные файлы вследствие специализации структуры данных под зада-
чи обеспечивают, как правило, более быстрое время обработки данных. Однако
недостатки организации локальных файлов, связанные с большим дублирова-
нием данных в информационной системе и, как следствие, с несогласованно-
стью данных в разных приложениях, а также негибкостью доступа к информа-
ции, перекрывают указанные преимущества. Поэтому организация локальных
файлов может применяться только в специализированных приложениях, тре-
бующих очень высокой скорости реакции при импорте необходимых данных.
159
 Интегрированная ИБ, т. е. база данных (БД) — это совокупность взаимо-
связанных, хранящихся вместе данных при такой минимальной избыточности,
которая допускает их использование оптимальным образом для множества
приложений.
Централизация управления данными с помощью СУБД обеспечивает
совместимость этих данных, уменьшение синтаксической и семантической из-
быточности, соответствие данных реальному состоянию объекта, разделение
хранения данных между пользователями и возможность подключения новых
пользователей. Но централизация управления и интеграция данных приводит к
проблемам другого характера: необходимости усиления контроля вводимых
данных, необходимости обеспечения соглашения между пользователями по по-
воду состава и структуры данных, разграничения доступа и секретности дан-
ных.
Основными способами организации БД являются создание централизо-
ванных и распределенных БД. Основным критерием выбора способа организа-
ции ИБ является достижение минимальных трудовых и стоимостных затрат на
проектирование структуры ИБ, программного обеспечения системы ведения
файлов, а также на перепроектирование ИБ при возникновении новых задач.
Формализация концептуальной схемы данных повлекла за собой возмож-
ность классификации моделей представления данных на иерархические, сетевые
и реляционные. Это отразилось в понятии архитектуры систем управления база-
ми данных и технологии обработки. Архитектура СУБД описывает ее функцио-
нирование как взаимодействие процессов двух типов: клиента и сервера.
Распределенная обработка и распределенная база данных — не синони-
мы. Если при распределенной обработке производится работа с базой, то под-
разумевается, что представление данных, их содержательная обработка, работа
с базой на логическом уровне выполняется на персональном компьютере кли-
ента, а поддержание базы в актуальном состоянии — на файл-сервере. В случае
распределенной базы данных она размещается на нескольких серверах. Работа с
ней осуществляется на тех же персональных компьютерах или на других, и для
доступа к удаленным данным надо использовать сетевую СУБД.
В системе распределенной обработки клиент может послать запрос к соб-
ственной локальной базе или удаленной. Удаленный запрос — это единичный
запрос к одному серверу. Несколько удаленных запросов к одному серверу объ-
единяются в удаленную транзакцию. Если отдельные запросы транзакции об-
рабатываются различными серверами, то транзакция называется распределен-
ной. При этом один запрос транзакции обрабатывается одним сервером. Рас-
пределенная СУБД позволяет обрабатывать один запрос несколькими сервера-
ми. Такой запрос называется распределенным. Только обработка распределен-
ного запроса поддерживает концепцию распределенной базы данных.
База данных — это автоматизированные хранилища оперативно обновля-
емой информации. Если в 70-е гг. шла торговля сырой информацией, т. е. дан-
ными, то в наше время созданы автоматизированные аналитические комплексы,
торгующие результатами анализа сырой информации.

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

Рис. 6.21
Централизованное распределение
При распределении данных на основе расчленения база данных размеща-
ется на нескольких серверах (рис. 6.22). Существование копий отдельных ча-
стей недопустимо.
Достоинства: увеличивается объем базы данных; большинство запросов
удовлетворяется локальными базами, что сокращает время ответа; увеличива-
ются доступность и надежность; стоимость запросов на выборку и обновление
снижается по сравнению с централизованным распределением; если выйдет из
строя один сервер, система останется частично работоспособной.
Недостатки: часть удаленных запросов или транзакций могут потребо-
вать доступа ко всем серверам, что увеличивает время ожидания и цену; необ-
ходимо иметь сведения о размещении данных в БД.
161
 Однако доступность и надежность увеличиваются. Расчлененные базы
данных наиболее подходят к случаю совместного использования локальных и
глобальных сетей ЭВМ.

Рис. 6.22
Метод расчленения
При использовании метода дублирования (рис. 6.23) в каждом сервере
сети ЭВМ размещается полная база данных. Этот метод дает наиболее надеж-
ный способ хранения данных.

Рис. 6.23
Метод дублирования

162
 Недостатки: повышенные требования к объему внешней памяти; услож-
нение корректировки баз, так как требуется синхронизация с целью согласова-
ния копий.
Достоинства: все запросы выполняются локально, что обеспечивает
быстрый доступ.
Этот метод используется, когда фактор надежности является критиче-
ским, база — небольшой, а интенсивность обновления невелика.
В методе смешанного распределения объединены два способа распреде-
ления данных: дублирование и расчленение (рис. 6.24). При этом приобретены
как преимущества, так и недостатки обоих способов. Появилась необходимость
хранить информацию о том, где находятся данные в сети.
Главное преимущество — гибкость этой системы, так как можно устано-
вить компромисс между объемом памяти под базу в целом и под базу в каждом
сервере, чтобы обеспечить надежность и эффективность работы. В этой страте-
гии легко реализуется параллельная обработка, т. е. обслуживание распреде-
ленного запроса или транзакции.
Недостатки: остается проблема взаимозависимости факторов, влияющих
на производительность системы, ее надежность, повышаются требования к па-
мяти. Смешанную стратегию используют при наличии сетевой СУБД, которая
обеспечивает реализацию распределенной базы данных.
Первые три метода поддерживают распределенную обработку данных.

Рис. 6.24
Метод смешанного распределения
В базах данных коллективного пользования центральным технологиче-
ским звеном становятся серверы баз данных. Программные средства серверов
баз данных обеспечивают реализацию многопользовательских систем, центра-
лизованное хранение, поиск и обработку, целостность и безопасность данных.
Производительность серверов баз данных на порядок выше производительно-

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

164
 Рост объемов распределенных баз данных выявил следующие проблемы
их использования:
 управление распределенными системами очень сложно, и инструмен-
тов для него катастрофически не хватает;
 сложные распределенные решения обходятся дороже, чем планирова-
лось;
 производительность многих приложений в распределенных системах
недостаточна;
 усложнилось решение проблем безопасности данных.
Решением этих проблем становится возврат к централизованной обработ-
ке на больших ЭВМ, называемых мэйнфреймами третьего поколения. Новое
семейство CMOS-мэйнфреймов IBM S390 Parallel Enterprise Server —
Generation 3 с воздушным охлаждением конкурентно по цене и производитель-
ности Unix/RISC-сервером. Оперативная память мэйнфреймов от 512 Мбайтов
до 8 Гбайт. Они имеют от 3 до 25 каналов. Внутреннее дисковое устройство
может иметь суммарную емкость от 18 до 288 Гбайт. Операционная система
OS/390 версия 2 поддерживает реляционную СУБД ДВ2, систему обеспечения
транзакций CICS и серверы безопасности, отвечающие стандартам DCE
Security Server OSF LI и RACF V2R2. Посредством Web-сервера можно под-
ключаться к сети Internet и вести коммерческую деятельность. OS/390 имеет
средства работы с Java-приложениями.
Проектирование структур БД. Диаграммы «Сущность — связь»
Диаграммы «Сущность — связь» (ERD) предназначены для разработки
моделей данных и обеспечивают стандартный способ определения данных и
отношений между ними. Фактически с помощью ERD осуществляется детали-
зация хранилищ данных проектируемой системы, а также документируются
сущности системы и способы их взаимодействия, включая идентификацию
объектов, важных для предметной области (сущностей), свойств этих объектов
(атрибутов) и их отношений с другими объектами (связей).
Данная нотация была введена Ченом (Chen) и получила дальнейшее раз-
витие в работах Баркера (Barker). Нотация Чена предоставляет богатый набор
средств моделирования данных, включая собственно ERD, а также диаграммы
атрибутов и диаграммы декомпозиции. Эти диаграммные техники используют-
ся, прежде всего, для проектирования реляционных баз данных (хотя также мо-
гут с успехом применяться и для моделирования как иерархических, так и сете-
вых баз данных).
Сущности, отношения и связи в нотации Чена
Сущность представляет собой множество экземпляров реальных и аб-
страктных объектов (людей, событий, состояний, идей, предметов и т. п.), об-
ладающих общими атрибутами или характеристиками. Любой объект системы
может быть представлен только одной сущностью, которая должна быть уни-
кально идентифицирована. При этом имя сущности должно отражать тип или

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

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

166
 Для идентификации требований, в соответствии с которыми сущности
вовлекаются в отношения, используются связи. Каждая связь соединяет сущ-
ность и отношение и может быть направлена только от отношения к сущности.
Значение связи характеризует ее тип и, как правило, выбирается из сле-
дующего множества: {«0 или 1», «0 или более», «1», «1 или более», «p:q» (диа-
пазон)}.
Пара значений связей, принадлежащих одному и тому же отношению,
определяет тип этого отношения. Практика показала, что для большинства при-
ложений достаточно использовать следующие типы отношений:
1. 1 × 1 (один к одному). Отношения данного типа используются, как
правило, на верхних уровнях иерархии модели данных, а на нижних уровнях
встречаются сравнительно редко.
2. 1 × n (один ко многим). Отношения данного типа являются наиболее
часто используемыми.
3. n × m (многие ко многим). Отношения данного типа обычно исполь-
зуются на ранних этапах проектирования с целью прояснения ситуации.
В дальнейшем каждое из таких отношений должно быть преобразовано в ком-
бинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных
сущностей и с введением новых отношений).
На рисунке 6.26 приведена диаграмма «сущность — связь», демонстри-
рующая отношения между объектами банковской системы. Согласно этой диа-
грамме каждый банк имеет один или более банковских счетов. Кроме того,
каждый клиент может владеть (одновременно) одной или более кредитной кар-
той и одним или более банковским счетом, каждый из которых определяет в
точности одну кредитную карту (отметим, что у клиента может и не быть ни
счета, ни кредитной карты).
Каждая кредитная карта имеет ровно один зависимый от нее пароль кар-
ты, а каждый клиент знает (но может и забыть) пароль карты.

Рис. 6.26
Диаграмма «сущность — связь»

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

Рис. 6.27
Диаграмма атрибутов
Нотация Баркера
Дальнейшее развитие ER-подход получил в работах Баркера, предложив-
шего оригинальную нотацию, которая позволила на верхнем уровне интегриро-
вать предложенные Ченом средства описания моделей.
В нотации Баркера используется только один тип диаграмм ERD. Сущ-
ность ERD представляется прямоугольником любого размера, содержащим
внутри себя имя сущности, список имен атрибутов (возможно, неполный) и
указатели ключевых атрибутов (знак «#» перед именем атрибута).
Все связи являются бинарными и представляются линиями с двумя кон-
цами (соединяющими сущность), для которых должно быть определено имя,
степень множественности (один или много объектов участвуют в связи) и сте-
пень обязательности (т. е. обязательная или необязательная связь между сущ-
ностями). Для множественной связи линия присоединяется к прямоугольнику
сущности в трех точках, а для одиночной связи — в одной точке. При обяза-
тельной связи рисуется непрерывная линия до середины связи, при необяза-
тельной — пунктирная линия.

168
 На рисунке 6.28 приведен фрагмент ERD для банковской задачи в нота-
ции Баркера.

Рис. 6.28
Сущности и связи в нотации Баркера
Читается связь отдельно для каждого конца, показывая, как сущность
клиент связывается с сущностью кредитная карта, и наоборот. При этом
необходимо учитывать степень обязательности выбранного конца связи. Для
этой цели используются слова «должен (быть)» или «может (быть)».
Так, диаграмма, приведенная на рисунке 6.28, читается следующим обра-
зом:
«Каждый клиент может владеть одной или более кредитной картой»
или
«Каждая кредитная карта должна принадлежать ровно одному клиенту».
В заключение отметим, что понятия «категория» и «общая сущность» за-
меняются Баркером на эквивалентные понятия подтипа и супертипа соответ-
ственно.
Построение модели
Разработка ERD включает следующие основные этапы.
1. Идентификация сущностей, их атрибутов, а также первичных и аль-
тернативных ключей.
2. Идентификация отношений между сущностями и указание типов от-
ношений.
3. Разрешение неспецифических отношений (отношений nхm).
Этап 1 является определяющим при построении модели, его исходной
информацией служит содержимое хранилищ данных, определяемое входящими
и выходящими в/из него потоками данных.
На рисунке 6.29 приведен фрагмент диаграммы потоков данных, модели-
рующий деятельность бухгалтерии предприятия. Его единственное хранилище
ДАННЫЕ О ПЕРСОНАЛЕ должно содержать информацию обо всех сотрудни-
ках: их имена, адреса, должности, оклады и т. п.
Первоначально осуществляется анализ хранилища, включающий сравне-
ние содержимого входных и выходных потоков и создание на основе этого
сравнения варианта схемы хранилища.

169
 Рис. 6.29
Деятельность бухгалтерии
Перечислим структуру данных, которые содержатся во входных и выход-
ных потоках.
ВХОДНЫЕ СТРУКТУРЫ ДАННЫХ ВЫХОДНЫЕ СТРУКТУРЫ ДАННЫХ
вновь_нанятые адрес_служащего
дата_найма фамилия
фамилия адрес
таб_номер подробности з/пл
адрес фамилия
должность таб_номер
начальная_з/пл текущая з/пл
уволенные история занятости
фамилия фамилия
таб_номер таб_номер
изменение_адреса дата найма
фамилия история карьеры*
таб_номер должность
старый_адрес дата изменения
новый_адрес история з/пл *
изменение_з/пл з/пл
фамилия
таб_номер
старая_з/пл
новая_з/пл
дата_изменения
Сравнивая входные и выходные структуры, отметим следующие моменты.
1. Поле АДРЕС хранит текущий адрес сотрудника, а структура ИЗМЕ-
НЕНИЕ_АДРЕСА хранит и старый адрес, что не является необходимым, исхо-
дя из выходных потоков.

170
 2. ИСТОРИЯ_З/ПЛ, наоборот, требует перечень всех окладов сотрудника,
поэтому необходимо иметь набор, состоящий из пар (З/ПЛ, ДАТА), а не просто
СТАРАЯ_З/ПЛ и НОВАЯ_З/ПЛ (как во входном потоке).
3. Аналогичная ситуация и с ИСТОРИЕЙ_КАРЬЕРЫ. Отметим, что на
диаграмме вообще отсутствует поток, определяющий изменения в должности,
т. е. обнаружено серьезное упущение в функциональной модели!
4. Отметим, что изменения в ДОЛЖНОСТИ обычно (но не всегда) соот-
ветствуют изменению в З/ПЛ.
С учетом этих моментов первый вариант схемы может выглядеть следу-
ющим образом:
фамилия
таб_номер
адрес
текущая_з/пл
дата_найма
история_карьеры
должность
дата_изменения
история_з/пл
з/пл
дата_изменения
На следующем шаге осуществляется упрощение схемы за счет устране-
ния избыточности. Действительно, ТЕКУЩАЯ_З/ПЛ всегда является последней
записью в ИСТОРИИ_З/ПЛ, а ДАТА_НАЙМА содержится в разделах ИСТО-
РИЯ_З/ПЛ и ИСТОРИЯ_КАРЬЕРЫ. Кроме того, несколько дат в последних
разделах одни и те же, поэтому целесообразно создать на их основе структуру
ИСТОРИИ_З/ПЛ_КАРЬЕРЫ и вводить в нее данные при изменении ДОЛЖ-
НОСТИ и/или З/ПЛ.
фамилия
таб_номер
адрес
история_з/пл_карьеры
з/пл
должность
дата_изменения
Следующий шаг — упрощение схемы при помощи нормализации (уда-
ления повторяющихся групп). Единственным способом нормализации является
расщепление данной схемы на две, являющиеся более простыми.
Первая схема содержит ФАМИЛИЮ и АДРЕС (которые, как правило, не
меняются), вторая — каждое изменение З/ПЛ и ДОЛЖНОСТИ. Кроме того,
каждая схема должна содержать ТАБ_НОМЕР — единственный элемент дан-
ных, уникально идентифицирующий каждого сотрудника.
Для идентификации сущностей осталось определить ключевые атрибуты.
Для первой схемы ключевым атрибутом является ТАБ_НОМЕР, для вто-
рой — ключом является конкатенация атрибутов ТАБ_НОМЕР и ДАТА_ИЗМЕ-
171
НЕНИЯ (рис. 6.30), так как для каждого сотрудника возможно несколько запи-
сей в схеме ИСТОРИЯ_З/ПЛ_КАРЬЕРЫ.

Рис. 6.30
Сущность модели
Концепции и методы нормализации были разработаны Коддом (Codd),
установившим существование трех типов нормализованных схем, названных в
порядке уменьшения сложности первой, второй и третьей нормальной формой
(соответственно, 1НФ, 2НФ и 3НФ).
Рассмотрим, как преобразовывать схемы к наиболее простой 3НФ. При
этом будем представлять схемы в общепринятом виде, например, для сущно-
стей, приведенных на рисунке 6.30, имеем:
история_з/пл_карьеры (таб_номер, дата_изменения, должность, з/пл)
сотрудник (таб_номер, фамилия, адрес).
Для примера построения 3НФ рассмотрим следующую схему, ключ к ко-
торой выбран в предположении, что заказчик не заказывает одну и ту же книгу
дважды в один и тот же день:
заказ_на_книгу (имя_заказчика, дата_заказа, ISBN, название, автор, ко-
личество, цена, сумма_заказа).
Согласно Кодду, любая нормализованная схема (схема без повторяющих-
ся групп) автоматически находится в 1НФ, независимо от того, насколько сло-
жен ее ключ и какая взаимосвязь может существовать между ее элементами.
Отметим, что в последней схеме атрибуты НАЗВАНИЕ, АВТОР, ЦЕНА
могут быть идентифицированы частью ключа (а именно, ISBN), тогда атрибут
КОЛИЧЕСТВО зависит от всего ключа (соответственно полная и частичная
функциональная зависимость от ключа). По определению схема находится в
2НФ, если все ее неключевые атрибуты полностью функционально зависят от
ключа. После избавления от частичной функциональной зависимости послед-
няя схема будет выглядеть следующим образом:
заказ_на_книгу (имя_заказчика, дата_заказа, ISBN, количество, цена,
сумма_заказа)
книга (ISBN, автор, название, цена)
Заметим, что возможно упростить ситуацию и дальше: атрибуты КОЛИ-
ЧЕСТВО и СУММА_ЗАКАЗА являются взаимозависимыми. По определению
схема находится в 3НФ, если она находится в 2НФ и никакой из ключевых ат-
рибутов не является зависимым ни от какого другого неключевого атрибута.
Поскольку в нашем примере атрибут СУММА_ЗАКАЗА фактически является
избыточным, для получения 3НФ его можно просто удалить.

172
 Иногда для построения 3НФ необходимо выразить зависимость между
неключевыми атрибутами в виде отдельной схемы. Так для сотрудников, рабо-
тающих по различным проектам, возможна следующая схема:
сотрудник (таб_номер, телефон, почасовая_оплата, №_проекта, да-
та_окончания).
Очевидно, что данная схема находится в 2НФ. Однако, №_ПРОЕКТА и
ДАТА_ОКОНЧАНИЯ являются зависимыми атрибутами. После расщепления
схемы получим 3НФ:
участник_проекта (таб_номер, телефон, почасовая_оплата, №_проекта)
проект (№_проекта, дата_окончания)
На практике отношения 1НФ и 2НФ имеют тенденцию возникать при по-
пытке описания нескольких реальных сущностей в одной схеме (заказ и книга,
проект и сотрудник). 3НФ является наиболее простым способом представления
данных, отражающим здравый смысл. Построив 3НФ, мы фактически выделяем
базовые сущности предметной области.
В заключение зафиксируем алгоритм приведения ненормализованных
схем в третью нормальную форму (рис. 6.31).

Рис. 6.31
Алгоритм приведения 1НФ в 3НФ

173
 Этап 2 служит для выявления и определения отношений между сущно-
стями, а также для идентификации типов отношений. На данном этапе некото-
рые отношения могут быть неспецифическими (nхm — многие ко многим). Та-
кие отношения потребуют дальнейшей детализации на этапе 3.
Определение отношений включает выявление связей, для этого отноше-
ние должно быть проверено в обоих направлениях следующим образом: выби-
рается экземпляр одной из сущностей и определяется, сколько различных эк-
земпляров второй сущности может быть с ним связано, и наоборот.
Для примера на рисунке 6.30 рассмотрим отношение между сущностями
СОТРУДНИК и ИСТОРИЯ_З/ПЛ_КАРЬЕРА. У отдельного сотрудника долж-
ность и/или зарплата может меняться ноль, один или много раз, порождая соот-
ветствующее число экземпляров сущности ИСТОРИЯ_З/ПЛ_КАРЬЕРА.
Анализируя в другом направлении, видим, что каждый экземпляр сущно-
сти ИСТОРИЯ_З/ПЛ_КАРЬЕРА соответствует ровно одному конкретному со-
труднику. Поэтому между этими двумя сущностями имеется отношение типа
1 × n (один ко многим) со связью «один» на конце отношения СОТРУДНИК и
со связью «ноль, один или много» на конце сущности ИСТО-
РИЯ_З/ПЛ_КАРЬЕРА.
Этап 3 предназначен для разрешения неспецифических (многие ко мно-
гим) отношений.
Например:

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

6.5. Вопросы для самопроверки

1. С какой целью разрабатываются классификаторы?
2. Какие бывают классификаторы?

174
 3. Чем отличается иерархическая система классификации от фасетной?
4. В каких случаях используются регистрационные системы кодирова-
ния и какие системы относятся к этому классу?
5. Для чего используются классификационные системы кодирования?
Какие системы входят в эту группу?
6. Что включается в систему ведения классификаторов?
7. Что такое ЕСКК и какова его структура?
8. Каково назначение штрихового кодирования?
9. Какие функции выполняет документ в ЭИС?
10. Какие виды документов можно выделить в системе документации?
11. Что такое «Унифицированная система документации» и каким тре-
бованиям она должна отвечать?
12. Какие существуют виды УСД?
13. Каковы принципы и требования к построению первичных докумен-
тов?
14. Каковы принципы и требования к построению форм результатных
документов?
15. Каковы особенности построения форм первичных документов?

175
 ТЕМА 7. ПРОЕКТИРОВАНИЕ ТЕХНОЛОГИЧЕСКИХ
ПРОЦЕССОВ ОБРАБОТКИ ИНФОРМАЦИИ В ЭИС
7.1. Основные понятия и классификация технологических
процессов обработки экономической информации
Под технологическим процессом обработки экономической информации
понимается определенный комплекс операций, выполняемых в строго регла-
ментированной последовательности с использованием определенных методов
обработки и инструментальных средств, охватывающих все этапы обработки
данных, начиная с регистрации первичных данных и заканчивая передачей ре-
зультативной информации пользователю для выполнения функций управления.
Обработка информации, или информационная технология, появились од-
новременно с самой информацией. Первая информационная технология заклю-
чалась в передаче знаний устно по наследству. Появились первые хранители
знаний — жрецы, духовенство. Профессиональные навыки передавались лич-
ным примером. Доступ к знаниям и информации был ограничен, и знания не
могли существенно влиять на производственный процесс. Уровень технологии
обработки данных был ручным, производство — ремесленным, уникальным,
мелкосерийным, темпы роста производства и номенклатуры изделий невелики.
Появление первого печатного станка и книгопечатания (1445 г.) произве-
ло первую информационную революцию, которая длилась примерно 500 лет.
Знания стали тиражироваться. Они уже могли влиять на производство. Появи-
лись станки, паровые машины, фотография, телеграф, радио.
Если до конца XIX века примерно 95% трудового населения работало в
сфере материального производства и только 5% — в сфере обработки инфор-
мации, то к середине XX столетия примерно 30% трудового населения разви-
тых стран занималось обработкой информации.
С момента появления первой ЭВМ информационная технология прошла в
своем развитии ряд этапов. В 1946 г. появилась первая машина ЭНИАК. На
начало 1950-х гг. в мире насчитывалось около 100 ЭВМ. Первыми производи-
телями ЭВМ были СССР, США, ФРГ, Франция и Англия.
Сейчас суммарная мощность всех ЭВМ приближается к суммарной мощ-
ности мозга всего человечества, поэтому компьютерные технологии оказывают
значительное влияние на развитие цивилизации.
Первый этап продолжался до начала 1960-х гг. Эксплуатировались ЭВМ
первого и второго поколений (ламповые и полупроводниковые). Основным
критерием являлась тогда экономия машинных ресурсов. Цель — максималь-
ная загрузка оборудования.
Характерные черты этого этапа: программирование в символьных адре-
сах, разработка библиотек стандартных программ, автокодов, машинно-ориен-
тированных языков и Ассемблера. В конце 1950-х гг. А. А. Ляпуновым был
разработан операторный метод. Он послужил основой для разработки алгорит-
мических языков и управляющих программ (АЛГОЛ, КОБОЛ, ФОРТРАН). До-

176
стижением в технологии программирования являлась разработка оптимизиру-
ющих трансляторов.
В это же время возникло второе направление автоматизации: автомати-
зация прохождения программ через ЭВМ. Были разработаны первые управля-
ющие программы реального времени и пакетного режима. Управляющие про-
граммы реального времени следили за появлением сигнала прерывания, прихо-
дящего по каналам связи (от спутника, датчиков и т. п.), и сразу же включали
программу его обработки. В остальное время работали программы в пакетном
режиме.
Программы, обрабатываемые ими данные и управляющая информация
объединялись в задание, а задания — в пакет. Управляющая информация
оформлялась в виде языка управления заданиями и содержала сведения об име-
нах задания, программ данных, их местонахождении, порядке следования и др.
Задания автоматически вызывались на выполнение в порядке очередности или
по приоритету. Пакетный режим резко повысил производительность использо-
вания ЭВМ, но затруднил процесс отладки программ и создания новых про-
граммных продуктов.
Второй этап длился до начала 1980-х гг. Появились мини-ЭВМ и ЭВМ
третьего поколения на больших интегральных схемах. Основным критерием
стала экономия труда программиста. Цель этого этапа — разработка инстру-
ментальных средств программиста. Были разработаны операционные системы
второго поколения, работающие в трех режимах: реального времени, разделен-
ного времени и в пакетном режиме. Системы разделения времени позволили
пользователю работать в диалоговом режиме, так как ему выделялся квант вре-
мени, в течение которого он имел доступ ко всем ресурсам системы. Появились
языки высокого уровня (PL, PASKAL и др.), пакеты прикладных программ, си-
стемы управления базами данных (СУБД), системы автоматизации проектиро-
вания (САПР), диалоговые средства общения с ЭВМ, новые технологии про-
граммирования (структурное и модульное), появились глобальные сети ЭВМ.
Третий этап продолжался до начала 1990-х гг. В конце 1970-х гг. Стив
Джобс и Стив Возняк сконструировали первый персональный компьютер. Пер-
сональный компьютер — это инструмент, позволяющий формализовать и сде-
лать широко доступными для автоматизации многие из трудно формализуемых
процессов человеческой деятельности. Критерий этапа — формализация зна-
ний. Цель — проникновение информационных технологий во все сферы чело-
веческой деятельности. Появились автоматизированные рабочие места (АРМ),
экспертные системы, базы знаний, локальные вычислительные сети, гибкие ав-
томатизированные производства, распределенная обработка данных, электрон-
ная почта и безбумажная технология.
Четвертый этап — с 1990-х гг. Критерий этапа — автоформализация
знаний, цель — информатизация общества.
Классификация технологических процессов обработки данных
Технологические процессы можно классифицировать по различным при-
знакам.
177
 По типу обрабатываемой информации можно выделить процессы обра-
ботки цифровой, графической, текстовой, мультимедийной информации, зна-
ний для экспертных систем.
По типу используемой аппаратной платформы — технологические про-
цессы выполняются на персональных ЭВМ, в локальных, региональных, гло-
бальных вычислительных сетях.
По типу режима обработки выделяют технологические процессы обра-
ботки данных, выполняемые в пакетном режиме, интерактивной (диалоговой)
обработке и технологии со смешанным режимом.
По типу организации информационного обеспечения выделяют техноло-
гические процессы, обрабатывающие локальные файлы, локальные и распреде-
ленные БД.
Технологический процесс состоит из совокупности технологических опе-
раций.
Под технологической операцией будем понимать совокупность функцио-
нально связанных действий по преобразованию данных, выполняемых непре-
рывно на одном рабочем месте.
Этап — это совокупность, взаимосвязанных операций, которые реализуют
определенную функцию обработки данных.
В технологическом процессе можно выделить следующие этапы: первич-
ный, предварительный, основной и заключительный (рис. 7.1).

Рис. 7.1
Этапы технологического процесса обработки данных

178
 На первичном этапе производится сбор, регистрация и передача инфор-
мации на обработку.
Основной этап содержит операции ввода данных в ЭВМ, программного
контроля, сортировки, корректировки, группировки, анализа, расчета, форми-
рования результатов и вывода их. Так как все операции выполняются ЭВМ, то
этот этап называют внутримашинным.
Свойства экономической информации позволяют использовать на внут-
римашинном этапе все информационные технологии. При обработке больших
объемов данных формализованных задач ЭИС, возможно использование пакет-
ной технологии. Для частично формализованных задач используется диалого-
вая технология. Для обмена данными с удаленными партнерами или базой ис-
пользуется сетевая технология.
Заключительный этап содержит операции по визуальному контролю ре-
зультатов, размножению, подписи и передаче их заказчику. Этот этап также
называют послемашинным. Он сформировался для больших ЭВМ. Установлен-
ный на рабочее место информационного работника компьютер может содер-
жать только операции контроля: четкость вывода, непротиворечивость резуль-
татов и т. д. Все остальные операции могут выполняться на машинном этапе,
так как уже существует система электронной подписи, а заказчиком является
сам информационный работник. Результаты либо передаются по сети, либо за-
писываются в базу.
На практике технология обработки почти никогда не бывает линейной.
Часто ЭИС является вложенной (элементом) ЭИС более высокого порядка, а
этапы обработки могут выполняться в разнообразных сочетаниях.
Рассмотрим эти этапы более детально.
Операции получения первичной информации
В состав операций, выполняемых при получении первичной информации,
входят съем, регистрация, сбор и передача информации.
Съем информации, или измерение, — это процесс получения количе-
ственного значения показателя, характеризующего объекты и процессы хозяй-
ственной деятельности, и по степени автоматизации его можно подразделить на
следующие виды:
 ручной съем (подсчет);
 полуавтоматический (например, с помощью весов-автоматов);
 автоматический (например, с использованием счетчиков или датчиков
единичных сигналов).
К современным средствам измерения и счета относятся, например, элек-
тронные весы модели CAS LP-15, которые предназначены для использования в
расфасовочных отделах продовольственных магазинов. С помощью весов мож-
но выполнить операции: взвешивание упаковки с товаром; перемножение веса
на цену, печать этикетки со стоимостью упакованного товара; передача сооб-
щений компьютеру, который осуществляет учет движения товаров; прием от
компьютера сведений об изменениях номенклатуры товаров и цен; накопление

179
данных о выполненных взвешиваниях. Такие весы могут использоваться как
автономно, так и в составе системы учета движения товаров в магазине.
Другие устройства — измерители потоков (расходомеры) используются,
когда объектами измерения являются жидкость или газ. Примером может слу-
жить топливомер на автоматизированной АЗС, используемый для измерения
отпуска количества горючего. К подобным устройствам относятся также ма-
шинка для счета банкнот, средства безналичного денежного обращения с ис-
пользованием пластиковых карт и др.
Машинка для счета банкнот используется для пересчета различных ку-
пюр в пачках до 999 листов и вычисления суммы, установления числа листов,
которое необходимо отсчитать, выбрасывания мятых и поврежденных купюр.
Средства организации безналичного денежного обращения на основе
кредитных карт (КК) позволяют оплачивать, не пользуясь наличными деньга-
ми, различные товары и услуги (телефонные разговоры, проезд в метрополи-
тене и др.). В настоящее время наиболее употребительны три вида КК: с маг-
нитными полосками, с памятью на микросхемах, содержащие микропроцессор,
полупостоянную и оперативную память, схему защиты (так называемые интел-
лектуальные карты).
Следующей операцией, выполняемой при получении первичной инфор-
мации, является операция регистрации первичной информации, т. е. нанесения
всех реквизитов-оснований (количественных характеристик) и признаков на ка-
кой-либо носитель.
Регистрация информации может выполняться следующими способами:
 ручным — заполнение бланков первичных документов на бумажном
носителе вручную;
 механическим, при вводе информации с клавиатуры в экранные фор-
мы ЭВМ или при использовании машинок с занесением информации в первич-
ные документы и одновременной записью ее на магнитные носители или ма-
шиночитаемые документы;
 полуавтоматическим, когда часть информации автоматически зано-
сится с магнитных носителей или из оперативной памяти устройства (напри-
мер, при использовании кассовых аппаратов, регистраторов производства или
бухгалтерских фактурных машин).
Для обеспечения достоверности информации при выполнении операции
регистрации применяют несколько методов контроля, набор которых наиболее
широко представлен при полуавтоматическом способе регистрации информа-
ции, где можно выделить следующие методы:
 визуальный контроль на экране регистратора;
 двойной ввод информации;
 контроль идентификатора по списку;
 контроль вводимой информации;
 контроль идентификатора по модулю (11, 10);
 контроль по сумме сообщений;

180
  контрольные суммы по каждому сообщению;
 общий аппаратный контроль по модулю 2.
Сбор первичной информации — это операция получения пакета сообще-
ний, «пачки» первичных документов или файла на машинных носителях для
последующей их передачи и обработки. Эта операция также может быть осу-
ществлена ручным, полуавтоматическим или автоматическим способами с цен-
трализованной или децентрализованной организацией работ.
Полуавтоматический и автоматический способы сбора информации при-
меняются для получения массовой информации в производственных цехах.
Для централизованной организации работ характерны периодический
опрос удаленных пунктов регистрации первичной информации, находящихся
на рабочих местах, выполняемых автоматически, передача этой информации на
центральную ЭВМ вычислительного комплекса для учета, контроля выработки
продукции и выдачи нового задания.
Децентрализованный метод сбора — это метод, при котором передача
информации осуществляется с удаленных пунктов по мере накопления инфор-
мации или по окончании некоторого периода времени, например, смены.
Операция передачи информации на расстояние осуществляется двумя
способами: неэлектрическим (например, с помощью экспедиторов, курьеров),
для которого характерны высокая надежность и низкая скорость передачи, и
электрическим, требующим системы защиты от искажений и несанкциониро-
ванного доступа.
Передачу информации электрическим способом можно осуществлять с
использованием следующих средств: телеграфа общего пользования, для кото-
рого характерны низкая скорость передачи информации и низкая достоверность
передачи; абонентских телеграфных устройств и специальной аппаратуры пе-
редачи данных компьютерных сетей.
Основным средством передачи данных в ЭИС в настоящее время служат
компьютерные сети, подразделяемые на низкоскоростные, среднескоростные с
использованием передачи данных по коммутируемому либо по специально вы-
деленным каналам связи.
По способу установления соединений между абонентами сети делятся на
несколько видов.
Сети с коммутацией каналов характеризуются установлением прямой
связи с абонентом на некоторое время в пределах общей очереди. Поэтому ос-
новным недостатком такой связи является ожидание соединения в общей оче-
реди. Положительным качеством такой передачи является тот факт, что переда-
ча не может быть осуществлена вне очереди (произвольно), что повышает до-
стоверность передачи информации в целом.
Ко второму виду относятся сети с коммутацией сообщений, которые ха-
рактеризуются наличием узлов коммутации сообщений. Для таких узлов необ-
ходимо обеспечить наличие технических средств получения и хранения сооб-
щений. Задача ЭВМ, используемых для этих целей, — получить сообщение, за-
помнить его и, в случае освобождения канала связи с абонентом, по определен-
ному адресу передать это сообщение. Положительной стороной такой передачи
181
является минимальное время ожидания, отрицательной — то, что сеть полу-
чается более дорогой (необходимо разработать специальное программное обес-
печение узла коммутации), а при передаче большого объема информации
(1 млн байт) канал может быть занят несколько часов.
Третьей разновидностью являются сети с коммутацией пакетов, позво-
ляющие длинное сообщение на передающем пункте разбивать на пакеты сооб-
щений. Информация передается пакетами. Положительная сторона такого спо-
соба передачи — сокращается время ожидания передачи, отрицательная —
необходимость иметь программное обеспечение, позволяющее разбивать на пе-
редающем пункте сообщение на пакеты с заголовками, адресом и контрольным
числом, а на принимающем пункте — сборку сообщения по идентификатору.
Основной этап (загрузка и ведение информационной базы)
Под системой загрузки и ведения информационной базы понимают неко-
торый комплекс программной, методической и технической документации, с
помощью которой пользователь может осуществить своевременную загрузку и
актуализацию данных, хранение достоверных данных, обеспечивать секрет-
ность данных, защиту от сбоев ЭВМ и своевременное восстановление утрачен-
ной информации.
Проектирование системы загрузки и ведения информационной базы
означает проектирование и получение программной и технологической доку-
ментации по следующим процедурам:
 загрузка и актуализация данных;
 обеспечение достоверности вводимых данных;
 обеспечение защиты данных;
 обеспечение надежности хранения данных.
Достоверность хранения данных в информационной базе подразумевает
отсутствие ошибок, своевременность внесения изменений и непротиворечи-
вость информации. Для обеспечения достоверности вводимых и хранимых дан-
ных необходимо выполнить следующие работы:
 обеспечить контроль вводимой информации при выполнении проце-
дур загрузки и актуализации информации;
 обеспечить защиту хранимых данных от несанкционированного доступа;
 обеспечить одновременность актуализации одних и тех же данных,
находящихся в разных файлах.
В процессе создания (загрузки) и актуализации информационной базы
используются интерактивный и пакетный режимы.
Интерактивный режим создания и актуализации информационной базы
предполагает ввод или обновление отдельных записей файлов по мере необхо-
димости. Режим интерактивного ввода или обновления данных в основном
применяется при создании и ведении файлов оперативной информации, когда
происходит получение и оформление отдельных документов первичной ин-
формации. Файлы оперативной информации создаются в режиме добавления
записей по мере получения документов первичной информации. В этом смысле

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

7.2. Автоматизация ввода бумажных документов

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

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

184
 Получение изображения документа включает в себя выполнение таких
операций, как сканирование; контроль качества отсканированных изображений
и возможное повторное сканирование.
Сканирование — это очень ответственная операция, и, следовательно, к
выбору конкретной модели сканера необходимо подходить достаточно ответ-
ственно. При выборе следует учитывать следующие факторы: размеры доку-
ментов, их состояние, является ли документ односторонним или двухсторон-
ним, производительность сканеров, необходимое разрешение изображения,
надежность получаемых изображений и др.
В настоящее время на рынке технических средств предлагается большое
количество различных моделей сканеров, которые можно классифицировать по
производительности на следующие виды:
 персональные — низкоскоростные (например, Fujitsu Scan Partner 10,
HP ScanJet и др.);
 настольные офисные — среднескоростные (например, BancTec 2610
Bell&Howell 6338, Fujitsu 3099, Kodak ImageLink 500 и др.);
 высокопроизводительные потоковые (90–185 страниц/мин например,
BancTec S-series, Photomatrix 5000, Kodak ImageLink 900 и др.).
По качеству сканирования, зависящего от разрешающей способности, их
можно разделить на следующие группы:
 с низкой разрешающей способностью (200–400 точек на дюйм);
 со средней разрешающей способностью (600–800 точек на дюйм);
 с высокой разрешающей способностью (1600–2800 точек на дюйм);
 специального назначения.
Распознавание и ввод данных, содержащихся в документе, в информа-
ционную базу предполагает выполнение следующих основных операций:
 предварительная обработка изображений;
 нахождение полей (сегментация документа и чтение текста);
 проверка распознанной информации;
 ввод данных в информационную базу.
Предварительная обработка изображения документов использует сле-
дующие специальные функции:
 очищение изображения применяется для снятия с изображений от-
дельных элементов (например, точки, пятна);
 снятие фона и выделений (например, с ценных бумаг); выравнивание
изображения для последующей его обработки с целью улучшения качества рас-
познавания, чтобы документ показать в строго вертикальном положении в про-
цедуре распознавания без перекосов;
 снятие элементов форм (для того, чтобы эффективно обрабатывать
форму, необходимо удалять с изображения элементы формы: линии, разграфки,
таблицы и т. д.);
 определение идентификатора форм (так как приходится вводить в
систему самые разнообразные формы, отличные как по содержанию, так и по
структуре; для того, чтобы система могла работать со множеством форм, она
185
должна определять, какая форма поступила на обработку, и загружать соответ-
ственно заранее настроенное и подготовленное описание формы);
 восстановление букв и символов, если они оказываются пересечен-
ными элементами формы, например, линией (для последующего распознавания
символа необходимо удалить линию таким образом, чтобы буква не пострадала).
Кроме того, к предварительной обработке изображения относятся следу-
ющие функции, повышающие надежность распознавания:
 вращение изображения на произвольный угол;
 масштабирование изображения;
 регулирование уровня серого цвета;
 компрессия и декомпрессия изображения.
Процессы нахождения полей (сегментация документа) и чтения текста
могут быть выполнены последовательно и независимо, если поля полностью
определены своими визуальными характеристиками. Такая ситуация характер-
на для машиночитаемых форм и документов с явными разделителями полей в
виде линий или больших промежутков.
В документах, не имеющих строго определенного положения полей и яв-
ных разделителей между ними, нет принципиально иного способа, как прочи-
тать текст и по его содержанию скорректировать результаты предварительной
сегментации.
Как правило, задачи обработки разных форм документов, таких как пла-
тежные документы, налоговые декларации и т. д., решаются индивидуальным
путем программирования с использованием общих приемов.

7.3. Технология обеспечения достоверности данных

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

186
 Синтаксический контроль обеспечивает проверку информации безотно-
сительно к ее содержанию, это:
⎯ проверка алфавита;
⎯ проверка типа данных;
⎯ проверка порядка следования реквизитов;
⎯ контрольные суммы;
⎯ контроль по методу избыточных цифр;
⎯ «дубль перфорация».
По реализации различают визуальные и программные методы контроля.
Визуальный контроль выполняется на домашинном и заключительном этапах.
Программный — на внутримашинном этапе.
Проверка алфавита — контроль на наличие недопустимых символов в
реквизите, сообщение и т. д.
В ходе проверки типа данных различают символьные данные, числовые с
фиксированной и плавающей запятой, логические, данные типа «дата», «время»
и т. п.
Проверка порядка следования реквизитов важна при передаче данных по
каналам связи.
В ходе контрольного суммирования производится суммирование группы
реквизитов без учета их смысловой нагрузки. Контрольная сумма вводится с
группой реквизитов, в ЭВМ повторяется ее расчет и производится сравнение
контрольных сумм. Искажения при вводе любого символа или группы симво-
лов приведет к несовпадению контрольных сумм (КС). Этот метод использует-
ся в бухгалтерских документах и документах статотчетности. Иногда применя-
ются также балансовые методы контроля, когда КС рассчитываются по строкам
и столбцам документа.
Контроль по методу избыточных цифр применяют для кодов классифи-
каторов при длине кода более 7 разрядов. Наиболее распространенный метод —
«контроль по mod 11». Он заключается в том, что каждой позиции в коде при-
сваивается свой вес. Затем рассчитывается сумма произведений весов на значе-
ния цифр в соответствующих позициях и находится остаток от деления этой
суммы на 11. Это и есть контрольное число (КЧ). При вводе в ЭВМ всего ко-
да — основной плюс КЧ, ЭВМ повторяет расчет КЧ и сравнивает его с введен-
ным в состав кода. При совпадении считается, что код введен верно. При не-
совпадении КЧ выдается сигнал об искажении кода.
Рассмотрим этот алгоритм более подробно. Как уже говорилось, каждому
значению разряда идентификационного кода присваивается вес, соответствую-
щий определенному числу натурального ряда от 1 до 7, таким образом:
Разряд идентификационного кода R1 R2 R3 R4 R5 R6 R7
Ri
Вес разряда 1 2 3 4 5 6 7
Wi
Затем производится вычисление КЧ для конкретного идентификационно-
го кода. С этой целью каждая цифра, стоящая в определенном разряде данного

187
кода, умножается на вес разряда и вычисляется сумма произведений по следу-
ющей формуле:
7

WiRi = 1× R + 2 × R
i =1
1 2 + 3 × R3 + 4 × R4 + 5 × R5 + 6 × R6 + 7 × R7 .

КЧ идентификационного кода представляет собой остаток от деления по-

лученной суммы на 11 и выражается следующим образом:
7

7 WiRi
КЧ = WiRi − 11 × i =1

i =1 11

WiRi
i =1
где — целая часть частного от деления.
11

При использовании данного метода расчета получаются значения КЧ от

0 до 9. Если при расчете КЧ получается остаток, равный 10, то для обеспечения
одноразрядности производится повторный счет, при этом применяется следу-
ющая последовательность весов, сдвинутая на два разряда влево:
Разряд идентификацинного кода R1 R2 R3 R4 R5 R6 R7
Ri
Вес разряда 3 4 5 6 7 8 9
Wi
Этот метод используется во всех республиканских классификаторах с
длиной кода более 6–7 разрядов.
Метод «дубль перфорация» получил свое название от двойного переноса
данных на перфоносители в середине 1960-х гг. В настоящее время этот метод
используется при необходимости ввода большого объема информации, которая
не может быть проконтролирована другими методами. Например, данные пере-
писи населения, данные о голосовании на выборах и т. п. Суть его состоит в
том, что информация вводится в ЭВМ два раза (желательно разными операто-
рами) и затем познаково или побайтно сравнивается. Если знаки в одинаковых
позициях сообщений не совпадают, ввод либо сообщения, либо его части про-
изводится еще раз. И так до тех пор, пока не достигнут совпадения хотя бы
двух блоков ввода.
Семантический контроль использует содержательную составляющую
информации. Разновидностей семантического контроля можно предусмотреть
огромное количество. Но эти методы формализуются и реализуются значитель-
но сложнее.
Ограничение диапазона изменения показателя. Например, дата ДД.ММ.ГГ,
температура окружающего воздуха –30 ...+40°С и т. п. Разновидностью этого
метода является контроль по списку допустимых значений. Отдельно создается
список значений реквизита и, когда реквизит вводится, то его значение сравни-

188
вается со списком (месяц: январь, февраль, март и т. п.). Это же может отно-
ситься и к кодовым значениям реквизитов-признаков.
Недостатком этого метода является необходимость хранить и актуализи-
ровать список допустимых значений реквизита.
Методы смысловых проверок используются там, где можно написать
формулу для проверки.
Например,
 NiCi = "сумма ",
где Ni и Ci — соответственно количество и стоимость i-й детали, а «сумма» —
суммарная стоимость всех деталей по данному документу.
Прагматический контроль. Он, как правило, связан с проверкой полноты
и своевременности обработки и выдачи или получения информации. Соответ-
ственно, и методы контроля основываются на этом. Устанавливаются времен-
ные границы для получения сообщений. Причем либо абсолютные (астрономи-
ческое время) — «отчет в ГНИ сдается до 20 числа месяца, следующего за от-
четным периодом», либо относительные — «путевые листы сдаются не позднее
24 ч после выполнения работы».
Для проверки на полноту поступления документов, например, если они
поступают из различных частей ЭИС, создается матрица, состоящая из одной
или нескольких строк.
Элемент матрицы двоичный Xij = 1, 0, и означает: «1» — приход инфор-
мации от j-й части ЭИС для i-й задачи. Пока вся строка i не будет заполнена
единицами, считается, что решать i-ю задачу (выдавать i-ю сводку) нельзя, так
как нет полной информации на входе.
Мы рассмотрели методы контроля информации, но в понятие обеспече-
ния достоверности входит и обеспечение сохранности данных при сбоях и от-
казах как технических средств, так и ПО, и человеческого фактора. Отказы и
сбои могут вызываться множеством причин: техническими, выключением элек-
тропитания, появлением вируса, несанкционированным доступом и т. п. Защита
же от этих факторов обеспечивается копированием и восстановлением как про-
грамм, так и данных при наступлении одного из перечисленных событий.
Сохранение и восстановление ПО, как правило, не вызывает трудностей,
так как в процессе работы ЭИС программы не меняются. У специалистов по
эксплуатации ЭИС всегда должны быть копии или инсталляционные версии
как системного, так и прикладного ПО на внешнем носителе.
Копирование данных должно проводиться с определенной, заданной в
проекте на ЭИС, периодичностью персоналом, эксплуатирующим систему. Но-
сители, на которые копируются данные, должны храниться в определенном ме-
сте, и на них, как правило, ведутся журналы.
В больших системах иногда предусматривается копирование на НДД
(«зеркало», «горячий резерв»), но и при этом необходимо (хотя и значительно
реже) копировать информацию на внешние носители.

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

Рис. 7.2
Определение частоты копирования данных в ЭИС

190
Технологии обеспечения безопасности компьютерных систем
«По-настоящему безопасной можно считать лишь систему, которая
выключена, замурована в бетонный корпус, заперта в помещении со свинцовы-
ми стенами и охраняется вооруженным караулом, но и в этом случае сомнения
не оставляют меня»
Ю. Х. Спаффорд
Безопасность обработки данных зависит от безопасности использования
компьютерных систем. Компьютерной системой называется совокупность ап-
паратных и программных средств, различного рода физических носителей ин-
формации, собственно данных, а также персонала, обслуживающего перечис-
ленные выше компоненты.
Кража результатов, их порча, взлом защиты программных систем, приве-
дение в негодность программных продуктов, использование служебной инфор-
мации в личных целях появились одновременно с возникновением компьютер-
ных технологий обработки данных. Однако наибольшее внимание к этим во-
просам привлек запуск в октябре 1988 г. Робертом Моррисом вируса в компью-
терную сеть Arpanet. В результате был полностью или частично заблокирован
ряд общенациональных компьютерных сетей, в частности Internet, Csnet,
BITnet, Arpanet и несекретная военная сеть MILnet. Общий ущерб оценивался
специалистами в 100 млн долларов.
Поэтому вопросами безопасности компьютерных систем с момента воз-
никновения последних сначала занимались ведомства по охране государствен-
ных и военных тайн, а в настоящее время — государственные законодательные
службы и институты.
В США в 1981 г. создан центр оценки компьютерной безопасности с це-
лью определения пригодности программного обеспечения для нужд обороны.
Вскоре он перерос в национальный центр. В настоящее время центр оценивает
техническое и программное обеспечение с точки зрения безопасности исполь-
зования этих систем в любых фирмах.
Анализ угроз информационным системам является первым этапом в раз-
работке методов и средств их защиты.
Специальная команда по обеспечению безопасности информации в ин-
формационной войне Министерства обороны США, организованная в 1995 г.,
выделила следующие виды угроз — по возрастанию степени их опасности:
 некомпетентные служащие;
 хакеры и крэкеры;
 неудовлетворенные своим статусом служащие;
 нечестные служащие;
 инициативный шпионаж;
 организованная преступность;
 политические диссиденты;
 террористические группы;
 шпионаж экономический, политический, военный;

191
  тактические удары и стратегические операции противника по разру-
шению информационного пространства государства в ходе информационной
войны.
Угроза, исходящая от некомпетентных служащих, по мнению экспертов,
основывается на алгоритмической уязвимости информационной системы, кото-
рая не исключает возможности некомпетентных действий и может приводить к
сбоям системы. Эта угроза исходит, в основном, от слабо подготовленных ад-
министраторов информационных систем, которые незаслуженно достигли при-
вилегированного положения и способны на нечестные поступки для достиже-
ния еще больших привилегий.
Хакеры и крэкеры являются гораздо более технически грамотными лич-
ностями. Они отличаются высокой степенью понимания процессов в информа-
ционных системах, но их устремления направлены на разрушение систем защи-
ты информации и на нелегальное пользование информацией. Хакеры весьма
многообразны и многочисленны, среди них встречаются просто «шутники» и
настоящие вандалы. Хакерство — распространенное явление в компьютерной
среде в настоящее время. Здесь отметим, что крэкеры — это те же хакеры, но
специализирующиеся на «взломе» коммерческих программных продуктов с це-
лью их подпольного распространения.
Неудовлетворенные служащие представляют внутреннюю угрозу. Они
опасны тем, что имеют легальный доступ. То же можно сказать и про нечест-
ных служащих. В данном случае трудно определить, какая из этих категорий
служащих может нанести большой урон. Обычно действия этих служащих вы-
ливаются в закладку «логической бомбы», которая «взрывается» через некото-
рое время после увольнения недовольного сотрудника или по истечении неко-
торых, заранее им запланированных обстоятельств. Так, бывший программист
издательской фирмы в г. Форт-Уэрт Д. Барлесон был пойман на выращивании
вируса, который стер 168 000 важных записей через два дня после его увольне-
ния.
Другой случай произошел в Сан-Диего, когда программист заложил «ло-
гическую бомбу» в сверхмощный компьютер фирмы «Дженерал Дайнемикс» —
одного из крупнейших подрядчиков Пентагона. Как заявил агент Криминаль-
ной службы МО США В. Лэндрет, это была самая опасная попытка саботажа,
так как этому сотруднику доверяли. Эта «бомба» могла бы нанести ущерб бо-
лее чем в 1 000 000 долларов и могла бы разрушить невосполнимые данные
фирмы, включая программу по ракетам «Атлас». К счастью, «бомбу» вовремя
обнаружили.
Инициативный шпионаж непосредственно примыкает к двум вышепри-
веденным угрозам, исходящим от служащих. В целом, он менее опасен, чем це-
ленаправленный шпионаж иностранных государств, но может принести массу
крупных неприятностей.
Угроза, исходящая от организованной преступности, основывается на
том, что информация является основой мировой экономики. Информация —
это деньги! Только 10% времени деньги существуют в своем физическом виде,
в остальное время они существуют в виде информации. Так как информацион-
192
ные системы все шире используются для финансовых операций на всех уров-
нях, то естественно ожидать, что на всех уровнях криминальные элементы и
группы будут атаковать их с тем, чтобы получить незаконные доходы.
Международный характер информационных систем привлекает полити-
ческих диссидентов. Их интересы состоят в распространении призывов к раз-
личным акциям, например, к демонстрациям, гражданскому неповиновению и
восстанию, срыву государственного управления. Так, один политический дис-
сидент призывал всех, кто имеет такую возможность, закладывать информаци-
онные «бомбы» в электронную почту Белого дома.
Террористические группы с помощью информационных систем старают-
ся придать своим акциям большое значение, запугать население, шантажиро-
вать противодействующие им органы, посеять панику.
Зарубежные агенты пытаются использовать информацию для достиже-
ния экономических, политических, военных целей с тем, чтобы оказывать вли-
яние на политику. При этом они небезуспешно используют хакеров. Так, в
1986 г., когда американцы не догадывались обо всех возможностях созданных
ими компьютеров, программ и информационных сетей, агенты КГБ создали в
Гамбурге группу из трех хакеров. Это были молодые талантливые программи-
сты, мастерство которых росло не по дням, а по часам. Только в 1989 г. удалось
обнаружить их проникновение в системы информационного обмена Пентагона,
NASA, ядерных лабораторий в Беркли и Лос-Аламосе. К этому времени агенты
КГБ добыли огромное количество секретных данных. Это событие стало клас-
сическим примером шпионажа, по эффективности сопоставимым с деятельно-
стью Джона Уолкера, Джонатана Полларда или Джеймса Холла, хотя методы и
средства были другими.
Самой серьезной угрозой не только информационным системам, но и
государству и обществу в целом является информационная война, результаты
которой могут быть сопоставимы с результатами ядерной войны. В ходе ин-
формационной войны противник может проводить стратегические наступа-
тельные операции по разрушению информационного пространства государства.
Эти операции могут вызвать полное разрушение систем управления государ-
ством, экономикой и войсками. На начальном этапе информационной войны
противник может также наносить оборонительные или наступательные такти-
ческие информационные удары, цель которых — разрушить системы управле-
ния войсками и оружием. При этом используются вирусы и «логические управ-
ляемые мины».
Специалисты по компьютерной безопасности, анализируя проникновение
вирусов в компьютеры военных систем, пришли к выводу о возможности суще-
ствования боевых вирусов, которые оказывают непосредственное воздействие
на ход боевых действий. Такие вирусы могут передаваться по радиосвязи во
время тактических действий и иметь форму «троянского коня» — информаци-
онной дистанционно-управляемой мины.
По заявлению американских специалистов, особо восприимчивой к тако-
го рода вирусам оказалась система управления маневрами, используемая ко-

193
мандирами для планирования и координации танковых атак и огневой под-
держки в ходе боя.
Эта угроза стала реальной в апреле 1990 г. Перед проведением операции
«Буря в пустыне» было обнаружено, что несколько тысяч армейских компью-
теров инфицировано вирусами «Иерусалим», «Иерусалим-В» и «Булыжник».
Эти вирусы, очевидно, были внедрены при использовании полевых компьюте-
ров для таких игр как «Solitaire». Операция «Буря в пустыне» продемонстриро-
вала многим, насколько важно вовремя выявить компьютерный вирус. Во вре-
мя проведения боевых операций эти вирусы могли бы серьезно повлиять на
боеспособность войск и их выживаемость на поле боя.
Во время эксплуатации ЭИС наибольший вред и убытки приносят виру-
сы. Почему стало возможным их проникновение? На больших ЭВМ команды
обработки прерываний были привилегированными, т. е. недоступными про-
граммисту. Поэтому на больших ЭВМ вирусы не приносили существенных
убытков. Прерывания на персональном компьютере обрабатываются неприви-
легированными командами и могут быть доступны как операционной системе,
так и прикладным программам. Прикладные программы могут перехватить
прерывание, выполнить любые действия и вернуть управление. Так создают
вирусы.
Некоторые термины из мира вирусов
Загрузочный вирус. Вирусов этого типа больше всего; они передаются с
компьютера на компьютер через внешние носители и поражают загрузочный
сектор жесткого диска. Внимательно следите за тем, чтобы не оставить случай-
но диск в дисководе А: при перезагрузке, именно в такой момент загрузочные
вирусы чаще всего попадают в машину.
Файловый вирус. Внедряется, как правило, в исполняемые exe- или com-
файлы; грамотно написанный вирус размножается и выполняет другие дей-
ствия, не нарушая работу зараженной им программы и никак себя не проявляя.
В свободном состоянии. Точно так же, как одни звери живут в диких ле-
сах, а другие заперты в клетках в зоопарке, некоторые вирусы могут существо-
вать только в исследовательских лабораториях, никогда не распространяясь за
их пределы, в то время как другие будут разгуливать по джунглям Интернета.
Макровирус. Квазивирус, написанный на макроязыке, который может
распространяться через документы. Заражению такими вирусами подвержены
файлы Microsoft Word и Excel.
Файлово-загрузочный вирус. Помесь файлового и загрузочного вирусов,
способен поражать и файлы, и загрузочные секторы дисков.
Полиморфный вирус. Меняющийся зашифрованный вирус, который по-
стоянно мутирует, избегая таким путем антивирусных сканеров, опознающих
вирусы по так называемой сигнатуре — неизменному фрагменту кода.
Стелс-вирус. Вирус, использующий специальные приемы, чтобы скрыть-
ся от антивирусных программ (например, он может временно выгружаться из
памяти).

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

196
 7.4. Проектирование технологических процессов
обработки данных
Содержание работ по проектированию процессов обработки экономиче-
ской информации определяется особенностями, присущими экономической за-
даче как основной единице обработки данных локальных ЭИС. Под экономиче-
ской задачей принято понимать взаимосвязанную последовательность операций
или действий, выполняемых над одним или несколькими файлами с целью по-
лучения хотя бы одного экономического показателя, выдаваемого в форме до-
кумента на бумажный носитель ли записываемого на машинный носитель.
Можно выделить следующие специфические особенности, свойственные
экономическим задачам:
 реализация с помощью решения экономических задач функций управ-
ления;
 разрешимость задач (для любой задачи существует некоторое реше-
ние);
 алгоритмизируемость задач (с этой точки зрения выделяются хорошо
и слабо формализованные задачи);
 структурированность алгоритма решения задачи и возможность раз-
биения его на блоки и модули;
 преобладание последовательной обработки файлов с исходными дан-
ными;
 невысокая степень использования математических методов (только
25% задач используют математические методы);
 форматированность входных и выходных данных в виде документов
строго определенной формы и содержания;
 связанность экономических задач через общую информационную базу;
 упорядоченность используемых данных по ключевым признакам;
 регулярность решения (повторяемость);
 выдача результатов решения задач к определенным срокам.
В состав задач ЭИС могут входить задачи, решаемые в различных режи-
мах: пакетном, диалоговом, удаленного доступа.
Проектирование технологических процессов обработки данных
в пакетном режиме
К задачам, решаемым в пакетном режиме (запускаемым, как правило, в
виде фоновых заданий), относятся задачи, характеризующиеся следующими
признаками: слабой разветвленностью алгоритма, отсутствием необходимости
вмешательства пользователя в ход решения и выбора варианта решения, боль-
шими объемами обрабатываемых данных и длительным временем решения и
получения результатной информации. К таким задачам относятся, например,
задачи статистической обработки данных, планирования производственной
программы, расчета заработной платы и др.

197
 При построении современных ИС пакетный режим используется там, где
нужен большой объем ввода однотипной информации.
Рассмотрим пример технологии обработки большого объема однотипной
информации. Задача — создание БД «Физические лица» (рис. 7.3).

Рис. 7.3
Пример — обработка данных о физических лицах города
Данные для наполнения базы брались из ведомостей (тетрадей) выдачи
ваучеров. Ваучеры выдавались всем жителям, включая младенцев, родившихся
к 01 сентября. Тетради заполнялись вручную и не всегда читаемо.
Технология обработки состояла в следующем.
1. Операторы (параллельно, две независимые бригады) вводили инфор-
мацию на диски (объем информации составлял примерно 700 000 записей-чело-
век).
2. Затем эта информация сравнивалась по знакам (каждая запись, так как
информация текстовая).
3. Записи, совпавшие с точностью до знака, заносились на диск.
4. Для неидентичных записей ввод повторялся заново (3-й ввод), прово-
дилось сравнение с 1-м и 2-м вариантом ввода, при совпадении запись заноси-
лась в массив верных, при несовпадении процесс повторялся.
В результате обработки было получено около 80% верных записей.
Остальные пришлось обрабатывать практически вручную.
Проектирование технологических процессов обработки данных
в диалоговом режиме
Диалоговый режим взаимодействия пользователя и ЭВМ обеспечивает
возможность оперативного вмешательства человека в процесс обработки ин-
формации на ЭВМ. На практике часто можно наблюдать совместное использо-

198
вание режимов, помогающее за счет их частных преимуществ организовать бо-
лее эффективную технологию решения задач на ЭВМ.
При коллективном диалоге с вычислительной системой управленческий
персонал организации (фирмы) может использовать в автоматизированном
процессе решения производственно-хозяйственных задач большой набор слабо
формализуемых факторов в соответствии со своим опытом и знаниями реаль-
ной экономической ситуации. Особенно это касается экспертных систем.
Диалог представляет собой обмен информационными сообщениями меж-
ду участниками процесса, когда прием, обработка и выдача сообщений проис-
ходят в реальном масштабе времени. Он может быть парным, когда число его
участников равно двум, и множественным — при большем числе участников.
В основе машинной диалоговой технологии обработки информации ле-
жит взаимодействие человека и ЭВМ во время решения задачи посредством пе-
редачи и приема сообщений через терминальные устройства. При диалоге типа
«человек — ЭВМ» целью пользователя является получение результатных дан-
ных в процессе решения задачи. Цель использования ЭВМ — оказание помощи
пользователю при выполнении рутинных операций.
Понимание при диалоге достигается наличием единой системы языковых
знаков или кодов, из которых формируются сообщения. Общие знания и уме-
ния у партнеров диалога обеспечивают эффективное понимание друг друга.
Если роли участников диалога заданы жестко, то такой диалог называется
жестким, например, режим работы «вопрос-ответ» с указанием того, кому из
партнеров принадлежит инициатива. Структура, альтернативная жесткой, зада-
ет множество предписанных вариантов диалога, представляемых пользователю
в виде меню, как правило, иерархической структуры, из которого он выбирает
направление решения задачи. Такой диалог называется гибким. Наконец, сво-
бодным называется диалог, позволяющий участникам общения обмениваться
информацией произвольным образом.
Эксплуатационные характеристики диалоговых систем должны удовле-
творять следующим требования:
 легкая адаптация пользователя к системе;
 единообразие вычислительных, логических процедур и терминологии;
 снабжение пользователя справочной информацией и необходимыми
инструкциями, выводимыми на экран видеотерминала или печатающее устрой-
ство с указанием моментов получения помощи от ЭВМ или необходимости
проведения ответных действий;
 использование кратких форм диалога;
 наличие защитных средств информации в системе, реализуемых опе-
рационными системами и специальными программами.
Технология обработки данных в диалоговом режиме на ЭВМ предполагает:
 организацию в реальном времени непосредственного диалога пользо-
вателя и машины, в ходе которого ЭВМ информирует человека о состоянии
решаемой задачи и предоставляет ему возможность активно воздействовать на
ход ее решения;

199
  обеспечение реактивности, т. е. оперативной циркуляции сообщений
как между функциональными задачами (программами), так и между задачами и
пользователем;
 создание для конечных пользователей-специалистов управления до-
статочно прозрачной диалоговой системы, требующей от них лишь выполнения
привычных служебных действий.
Для решения практических задач структура диалога включает различные
возможные способы обмена информацией между пользователем и ЭВМ, т. е.
диалоговая система содержит множество запросов и соответствующих им от-
ветных сообщений. Каждому запросу соответствует несколько альтернативных
ответных сообщений. Схема диалога разрабатывается обычно сразу на весь
комплект решаемых задач. Каждому пользователю выделяются отдельные ча-
сти схемы диалога с целью автоматического контроля его полномочий и для
предотвращения несанкционированного доступа.
Наиболее распространенными типами организации диалога являются ме-
ню, шаблон, команда, естественный язык.
Меню как тип диалога очень удобен для конечного пользователя. Реали-
зация диалога типа «меню» возможна через вывод на экран видеотерминала
определенных функций системы.
Выбор конкретной функции пользователем может осуществляться:
 набором на клавиатуре требуемой директивы или ее сокращенного
обозначения;
 набором на клавиатуре номера необходимой функции;
 подведением курсора в строку экрана с нужной пользователю функ-
цией;
 нажатием функциональных клавиш, запрограммированных на реали-
зацию данной функции.
При наличии различных вариантов ответов на ввод функций пользовате-
лем в последующих шагах производится детализация или уточнение действий,
например, какая информация должна вводиться, в каком виде или на какое
устройство желательно осуществить вывод и т. д.
Частным случаем диалога типа «меню» является режим ответа ДА/НЕТ,
то есть пользователю предлагаются два альтернативных варианта ответа: ДА
или НЕТ.
Шаблон — это такой режим взаимодействия конечного пользователя и
ЭВМ, на каждом шаге которого система воспринимает только синтаксически
ограниченное по формату входное сообщение пользователя. Варианты ответа
пользователя ограничиваются форматами, предъявляемыми ему на экране ви-
деотерминала. Диалог может быть реализован через:
 указание системой на экране дисплея формата вводимого пользова-
телем сообщения;
 резервирование места для сообщения пользователя в тексте сообще-
ния системы на экране терминала.

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

7.5. Вопросы для самопроверки

1. Что такое технологический процесс и по каким признакам классифи-
цируются технологические процессы?
2. Что такое технологическая операция и каковы виды технологических
операций?
3. Каковы принципы и методы организации контроля достоверности
обработки данных?
4. Каковы требования, предъявляемые к технологическим процессам?
5. Каково содержание основных операций технологического процесса
получения первичной информации?
6. Каковы методы и средства выполнения операции съема первичной
информации и ее контроля?
7. Каковы методы и средства выполнения операций регистрации и сбо-
ра первичной информации и контроля правильности их выполнения?
8. Каковы методы, технические и программные средства обеспечения
передачи первичной информации в ЭИС?
9. Какие методы семантического и синтаксического контроля первич-
ной информации, используемые при загрузке данных, вы знаете?
10. Что такое «диалоговая система», и какие способы организации диа-
лога вы знаете?
11. Какие типы вирусов вам известны?
12. Что такое «угроза безопасности»? Какие основные виды угроз вы
знаете?
13. Что понимается под «несанкционированным доступом» и каковы ос-
новные пути предотвращения несанкционированного доступа?

203
 ТЕМА 8. АВТОМАТИЗАЦИЯ ДЕЯТЕЛЬНОСТИ
ПРЕДПРИЯТИЙ И ОРГАНИЗАЦИЙ
В предыдущих главах мы рассмотрели основы проектирования ЭИС.
В этом разделе остановимся на некоторых особенностях ИС различного типа и
уровня.

8.1. Классификация систем автоматизации управления

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

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

Рис. 8.2
Основные классы АС по масштабам применения
1. Настольные — для работы одного человека. К ним следует отнести
автоматизированное рабочее место (АРМ) бухгалтера, АРМ кассира, АРМ рас-
четчика заработной платы и т. д. Внедрение таких программ не вызывает осо-
бых трудностей и для хороших систем может исчисляться днями. Основные
205
проблемы возникают при объединении информации с разных участков учета —
так как рабочие данные специалистов хранятся на разных компьютерах и воз-
никает много рассогласований. Например, один и тот же объект (материал, то-
вар, изделие) на разных АРМах может иметь разные коды.
2. Офисные — для работы отдела. К такого рода системам следует отне-
сти сетевые бухгалтерские программы, программы автоматизации торгового
зала, сетевые складские программы и т. д. Сотрудники всего отдела могут од-
новременно работать с единой базой данных, выполняя отдельную функцию
управления предприятием. Внедрение систем этого класса значительно сложнее
настольных: требует упорядочения планов счетов, составления общего спра-
вочника поставщиков и потребителей, настройки на учетную политику пред-
приятия, обучения персонала и т. д. Но настоящие проблемы возникают при
попытках обеспечения информационного безбумажного взаимодействия между
сбытом, бухгалтерией, снабжением и производством.
3. Корпоративные — для работы целого предприятия или даже несколь-
ких предприятий. Корпоративные системы охватывают, как правило, всю фи-
нансово-хозяйственную и производственную деятельность предприятия, в том
числе имеющего филиалы и дочерние фирмы, входящие в холдинговые компа-
нии и концерны.
По сложности АИС можно разбить на три большие группы.
1. Простые, так называемые «коробочные», продукты, реализующие не-
большое число бизнес-процессов организации. Обычно они рассчитаны либо на
локальное (на одном компьютере) использование, либо на использование в не-
большой (5–8 ПЭВМ) сети. За рубежом такие системы носят название систем
класса low end. Типичным примером систем подобного рода являются бухгал-
терские, складские или небольшие торговые системы, наиболее широко пред-
ставленные на российском рынке. Примером таких систем являются продукты
фирм «1С» или «Инфин». Отличительной особенностью таких продуктов явля-
ется относительная легкость в освоении, что в сочетании с низкой ценой, соот-
ветствием российскому законодательству и возможностью выбрать систему на
свой вкус приносит им широкую популярность не только в сфере малого бизне-
са, но и во многих достаточно крупных организациях.
2. Системы среднего класса (middle end), которые отличаются большей
глубиной и широтой охвата функций. Данные системы на нашем рынке предла-
гают не только российские, но и западные компании. Как правило, это учетные
системы, которые позволяют вести учет деятельности предприятия по многим
или некоторым направлениям: финансы, логистика, персонал, сбыт. Они нуж-
даются в настройке, которую, в большинстве случаев, осуществляют специали-
сты фирмы-разработчика, а также в обучении пользователей. Эти системы
больше всего подходят для средних и некоторых крупных предприятий в силу
своей функциональности и более высокой, по сравнению с первым классом,
стоимости. Из российских систем данного класса можно выделить продукцию
компаний «АйТи» и «Галактика», системы управления предприятием которых в
настоящее время занимают промежуточное положение между системами сред-
него и высшего класса.
206
 3. К высшему классу, по аналогии с предыдущими, называемому high
end, относятся системы, которые отличаются высоким уровнем детализации хо-
зяйственной деятельности предприятия. Современные версии таких систем
обеспечивают планирование и управление всеми ресурсами организации и по-
этому получили название ERP-систем (Enterprise Resource Planning). Как пра-
вило, при внедрении таких систем производится моделирование существующих
на предприятии бизнес-процессов и настройка параметров системы под требо-
вание бизнеса. Однако значительная избыточность и большое количество
настраиваемых параметров системы обуславливают длительный срок ее внед-
рения, а также необходимость наличия на предприятии специального подразде-
ления или группы специалистов, которые будут осуществлять перенастройку
системы в соответствии с изменениями бизнес-процессов.
В настоящее время на российском рынке имеется большой выбор систем
высшего класса, и их число растет с каждым днем. Вряд ли какую-либо отече-
ственную разработку можно назвать ERP-системой, поэтому речь идет только о
зарубежных программных продуктах. Признанными мировыми лидерами в
этой области и, несомненно, лидерами в России являются продукты R/3 компа-
нии SAP, Baan IV компании Baan и Oracle Application компании Oracle. Все они
достаточно корректно локализованы и внедрены либо успешно внедряются в
некоторых отечественных компаниях.
По видам обрабатываемой информации системы можно разделить на
документальные, фактографические и интегральные.
На предприятии вращается, как правило, три вида информации: факто-
графическая, служебная и аналитическая.
Фактографическая информация — это данные, отображающие факт
функционирования предприятия (содержание счетов, накладных, платежных
поручений и т. д.).
Служебная информация призвана обеспечивать среду и технологию дви-
жения фактографической информации; к ней также относится информация, со-
ставляющая документооборот.
Аналитическая информация поддерживает принятие решений и выработ-
ку служебных данных на основе анализа ситуации (служебной и фактографиче-
ской информации). Как правило, аналитическая информация, являясь результа-
том обработки служебной и фактографической информации, служит основой
для построения специализированных АИС и присутствует в большинстве из
них.
Для обработки служебной информации разработано значительное коли-
чество АИС, так называемых «документальных», или систем автоматизации
документооборота. Например, системы учетов кадров, системы документообо-
рота администраций Exchange и т. п. АИС, обрабатывающие фактографическую
информацию, в той или иной степени обрабатывают и служебную (счета,
накладные и т. п.).
При построении информационных систем предприятий, как правило,
строятся две системы, предназначенные для обработки и документооборота, и

207
фактографической информации («Галактика»). В этом случае обе системы бу-
дут относиться к числу интегрированных.

8.2. Требования к обработке

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

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

Рис. 8.3
Бизнес-процесс получения товаров по накладной
Этому сопутствует оформление и подписание определенного набора доку-
ментов. На разных предприятиях реализация этого бизнес-процесса может быть
выполнена по-разному. В одном случае выписка счета и накладной осуществля-
ется в бухгалтерии, в другом — накладная выписывается сразу на складе.
В то же время можно смело утверждать, что все предприятия имеют биз-
нес-функцию или набор бизнес-функций, называемый документооборотом.
Здесь необходимо определиться с терминологией, так как много путани-
цы происходит при использовании таких терминов, как «делопроизводство»,
«документооборот», «документирование» и т. п.
209
 Мы в дальнейшем будем придерживаться следующих понятий.
Документирование — это создание документов, т. е. их составление,
оформление, согласование и изготовление.
Делопроизводство — комплекс мероприятий по обеспечению докумен-
тального обслуживания управления (ДОУ). ДОУ охватывает вопросы докумен-
тирования, организации работы с документами в процессе осуществления
управления и систематизации их архивного хранения.
Организация работы с документами заключается в обеспечении движе-
ния, поиска, хранения и использования документов.
Документооборот — движение документов в рамках ДОУ.
Рассмотрим пример работы канцелярии.
Практически на всех предприятиях и в организациях существуют канце-
лярии. Их названия варьируются — либо общий отдел, либо управление дело-
производством и т. д., но суть данного подразделения от этого не меняется. Ос-
новная задача, которую оно выполняет, — регистрация всех входящих доку-
ментов и контроль их исполнения. Рассмотрим основные типы документов, ат-
рибутику, потоки документов и работы, выполняемые в данных отделах. Кроме
центрального документооборота крупного предприятия есть специализирован-
ный — различных структурных подразделений компании.
Типы документов, классификация и их взаимосвязь
Типов документов, которые используются в работе предприятия, доста-
точно много (порой их число доходит до 500–600). В то же время, с точки зре-
ния канцелярии, их бывает немного, всего-навсего три.
Входящие. Это документы, которые поступили на предприятие от внеш-
них партнеров. Большинство из них порождают соответствующие исходящие,
причем в заранее установленные сроки, которые определяются либо норматив-
ными актами, предписывающими то или иное время ответа на соответствую-
щий входящий документ, либо сроком исполнения, указанным непосредствен-
но во входящем документе.
Исходящие. Обычно являются ответом организации на соответствующие
входящие документы, хотя некоторые из них готовятся на основе внутренних
документов предприятия. Небольшое число исходящих документов может тре-
бовать поступления входящих, например, запросы в сторонние организации ти-
па: «Прошу дать справку по вопросу…, в срок до…».
Внутренние. Используются для организации работы предприятия. Через
канцелярию проходят не все внутренние документы, а только переписка наибо-
лее крупных структурных подразделений предприятия (особенно, если они тер-
риториально распределены) и приказы руководства. Также через канцелярию
проходят внутренние документы, порождающие исходящие. В частности, по
общим правилам делопроизводства единственный способ отправить запрос,
письмо или материалы во внешнюю организацию — это направить внутренний
документ в канцелярию, где его преобразуют в исходящий и отправят по назна-
чению.

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

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

Рис. 8.4
Взаимосвязи документов в канцелярии
Типовые процессы канцелярии
Теперь от рассмотрения типов документов перейдем к процессу их обра-
ботки. Основная задача канцелярии — обеспечение маршрутизации входных
документов по всему предприятию. Канцелярия отвечает за сроки исполнения
входных документов, точнее, выполняет «фискальные» функции: кто и когда
задержал выполнение документа.
При этом существует два основных маршрута прохождения документа
(существующий документооборот):
 непосредственно исполнителю (рис. 8.5);
 на принятие решения в центральный аппарат (рис. 8.6).

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

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

Рис. 8.6
Схема обработки входящего документа с контролем директора

213
 Значительная часть проблем канцелярии возникает из-за того, что она
обязана контролировать только ответственных исполнителей, а не всю цепочку
обработки документа, контроль за которой осуществляется на уровне систем
организации документооборота отдела или специального делопроизводства.
Именно полный контроль обеспечивает устойчивое управление организа-
цией. Создание такой системы сквозного контроля исполнительской дисципли-
ны невозможно без использования средств автоматизации обработки докумен-
тов и контроля исполнения.
На входе этого процесса — входящий документ. В момент прохождения
через директорат выбирается исполнитель документа. На выходе — исходя-
щий.
Какие же требования мы можем сформулировать к системе автоматиза-
ции документооборота?
1. Возможность групповой работы над документами.
2. Наличие электронной почты для пересылки электронных документов
между исполнителями.
3. Наличие средств считывания документов и их распознавания.
4. Документирование всех протоколов и пересылок (чтобы можно было
разобраться с исполнительской дисциплиной).
5. Наличие средств контроля в системе:
 контроль доставки;
 контроль прочтения;
 контроль исполнения;
 извещения о нарушении сроков исполнения;
 мониторинг, который позволяет инициатору посмотреть, кто и что
сейчас делает с его заданием и задать последовательность действий;
 хранение истории выполнения задания.
6. Наличие средств планирования групповой работы РГ.
7. Наличие средств хранения, поиска и обработки информации.
Автоматизация документооборота на примере производственной
деятельности (бизнес-процесса)
Рассмотрим в качестве примера производственной деятельности (бизнес-
процесса) фирму, торгующую готовым программным обеспечением. Рассмот-
рим рисунок 8.7, на котором изображены структура фирмы (упрощенная) и ин-
формационные потоки, характеризующие взаимодействие с клиентом. Есть еще
потоки получения программного обеспечения (ПО), его разработка и совершен-
ствование.
На рисунке отмечены информационные потоки на различных стадиях ра-
боты с клиентом и документы, относящиеся к фактографической и служебной
информации до автоматизации процесса.
При автоматизации данного конкретного бизнес-процесса фактографиче-
ская информация хранится в базах данных, что:

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

Рис. 8.7
Технология обработки информации бизнес-процесса до его автоматизации
Служебная информация представляет формы договоров, счетов, актов
и т. п. и неразрывно связана с фактографической. Отпадает необходимость
иметь внутреннюю службу информации (извещения об оплате, извещения о
выписке счета и т. п.). Эта информация становится доступной через сеть.
На рисунке 8.8 представлена блок-схема технологии обработки информа-
ции данного бизнес-процесса после его автоматизации.
Рассмотрим теперь, какие же требования выдвигаются к системам авто-
матизации офиса.
Одновременность доступа к общей информации
Например, к перечню счетов с пометкой об оплате, для:
 выписки договоров и актов (менеджер);
 подготовки ПО к передаче (менеджер);
 анализа производственной деятельности.
Одновременность обеспечивается наличием ЛВС, а при удаленности —
системами телекоммуникации и специальными средствами выделения ресурсов
группового доступа.
215
 Рис. 8.8
Технология обработки информации бизнес-процесса после его автоматизации
Наличие системы маршрутизации
Это обеспечивает правильность прохождения документами всех этапов
требуемой обработки. Например, акт о выполнении работ может быть выписан
только после заключения договора и выписки счета-фактуры.
Модульность и технологичность
Внедрение системы на предприятии не должно сбивать его работу с
налаженного ритма. Сначала, возможно, система внедряется в одном подразде-
лении, а затем постепенно в остальных.
Это позволяет:
 экономить средства, приобретая не всю ВТ сразу;
 экономить труд людей, так как при внедрении часто используется па-
раллельная обработка;
 обеспечить устойчивость работы предприятия при сбоях и выявлении
ошибок.
Масштабируемость
Это означает, что вне зависимости от повышения количественных требо-
ваний к системе она должна продолжать функционировать так же, как и преж-
де, и не требовать затрат на изменение принципов построения и конфигурации.
Открытость
Мы должны гарантировать, что система аккуратно впишется в уже суще-
ствующие или новые приложения, например, будет обеспечена связь с систе-
мой автоматизированного бухгалтерского учета, приложением по учету работы
менеджеров и курьеров и т. п.

216
 8.3. Современные модели построения систем управления
предприятием. Концепция MRP, MRP II, ERP
В данном разделе представлено описание концепций современных систем
управления предприятием и базовых систем. Главная цель — помочь сориенти-
роваться в базовых автоматизированных системах, имеющихся на российском
рынке.
Первые работы по практическому применению ЭВМ в управлении произ-
водством были направлены на решение наиболее трудоемких задач, которые
являлись «узким местом» в системе переработки информации.
Одной из них, особенно на крупных предприятиях со сложным многоно-
менклатурным производством, была задача расчета материальных потребно-
стей на производственную программу. Решение задачи состоит в определении и
передаче в производство и службы материально-технического снабжения ин-
формации о потребностях предприятия во всех материальных ресурсах (деталях
и сборочных единицах собственного производства, полуфабрикатах, материа-
лах, покупных изделиях, оснастке и приспособлениях и т. д.), необходимых для
выполнения производственной программы.
Особую сложность задаче придает ее календарный характер. Все потреб-
ности необходимо привязать к требуемым датам выполнения заказов. Ранние
системы, решавшие эту задачу, получили название MRP (Material Requirements
Planning — «Планирование материальных потребностей»). Постепенно был со-
вершен переход от автоматизации управления производством на уровне ло-
кальных задач к интегрированным системам, охватывающим выполнение всех
функций управления производством. Итогом этого процесса явились системы,
получившие название MRP II (Manufacturing Requirements Planning — «Плани-
рование производством ресурсов»).
MRP II представляет собой методологию, направленную на эффективное
управление всеми производственными ресурсами предприятия. Она обеспечи-
вает решение задач планирования деятельности предприятия в натуральном и
денежном выражении, моделирование возможностей предприятия, отвечая на
вопросы типа «Что будет, если..?». Эта методология базируется на ряде круп-
ных взаимосвязанных функциональностей, среди которых:
 бизнес-планирование (Business Planning — BP);
 планирование продаж и деятельности предприятия в целом (Sales and
Operations Planning — S&OP);
 разработка графика выпуска продукции (Master Production
Scheduling — MPS);
 планирование производственных мощностей (Capacity Requirements
Planning — CRP);
 различные системы оперативного управления производством.
Среди них системы, основанные на составлении расписаний работ на це-
ховом уровне (Shop Floor Control — SFC) и системы поточного производства
типа «точно в срок» (Just-in-Time — JIT).
Схема MRP II представлена на рисунке 8.9.
217
 Рис. 8.9
Схема MRP II
Структура MRP II охватывает все основные функции планирования про-
изводства сверху вниз. Состав функциональных модулей и их взаимосвязи
имеют глубокое обоснование с позиции теории управления. Они обеспечивают
интеграцию функций планирования, в том числе согласование их при различи-
ях времени и пространства. Важно отметить, что представленный набор моду-
лей является не избыточным, именно поэтому он, в основном, сохраняется и в
системах следующих поколений. Более того, многие понятия, методы и алго-
ритмы, заложенные в функциональные модули MRP II, остаются неизменными
в течение длительного времени и входят в качестве элементов в системы сле-
дующих поколений.
Для каждого уровня планирования MRP II характерны такие параметры,
как степень детализации плана, горизонт планирования, вид условий и ограни-
чений. Для одного и того же уровня планирования MRP II эти параметры могут
изменяться в широком диапазоне в зависимости от характера производственно-
го процесса, возможно также применение на каждом отдельном предприятии
определенного набора функциональных модулей MRP II.
Ниже приводится краткая характеристика функциональных модулей
MRP II.
Бизнес-планирование. Процесс формирования плана предприятия наибо-
лее высокого уровня. Планирование долгосрочное, план составляется в стои-
мостном выражении. Наименее формализованный процесс выработки решения.
Планирование продаж и деятельности. Бизнес-план преобразуется в
планы продаж основных видов продукции (как правило, от 5 до 10). При этом
производственные мощности могут не учитываться или учитываться укрупнен-
но. План носит среднесрочный характер.

218
 Планирование производства. План продаж по видам продукции преобра-
зуется в объемный или объемно-календарный план производства видов про-
дукции. Под видом здесь понимаются семейства однородной продукции.
В этом плане впервые в качестве планово-учетных единиц выступают изделия,
но представления о них носят усредненный характер. Например, речь может
идти обо всех легковых переднеприводных автомобилях, выпускаемых на заво-
де, без уточнения моделей. Часто этот модуль объединяют с предыдущим.
Формирование графика выпуска продукции. План производства преобра-
зуется в график выпуска продукции. Как правило, это среднесрочный объемно-
календарный план, задающий количество конкретных изделий (или партий) со
сроками их изготовления.
Планирование потребностей в материальных ресурсах. В ходе планиро-
вания на этом уровне определяются, в количественном выражении и по срокам,
потребности в материальных ресурсах, необходимых для обеспечения графика
выпуска продукции.
Планирование производственных мощностей. Как правило, в этом модуле
выполняются расчеты по определению и сравнению располагаемых и потреб-
ных производственных мощностей. С небольшими изменениями этот модуль
может применяться не только для производственных мощностей, но и для дру-
гих видов производственных ресурсов, способных повлиять на пропускную
способность предприятия. Подобные расчеты, как правило, производятся после
формирования планов практически всех предыдущих уровней с целью повы-
шения надежности систем планирования. Иногда решение данной задачи вклю-
чают в модуль соответствующего уровня.
Оперативное управление производством. Здесь формируются оператив-
ные планы-графики. В качестве планово-учетных единиц могут выступать де-
тали (партии), сборочные единицы глубокого уровня, деталей (партий) опера-
ции и т. п. Период, охватываемый планированием, невелик — от нескольких
дней до месяца.
Связь между уровнями в MRP II обеспечивается с помощью универсаль-
ной формулы: задача планирования на каждом уровне реализуется как ответ на
три вопроса:
1. Что необходимо выполнить?
2. Что необходимо для этого?
3. Что имеется в настоящее время?
В качестве ответа на первый вопрос всегда выступает план более высоко-
го уровня. Этим и обеспечивается связь между уровнями. Структура ответов на
последующие вопросы зависит от решаемой задачи.
Дальнейшее развитие MRP II связано с появлением систем управления
предприятием в замкнутом контуре, т. е. с обратной связью (Closed-loop MRP).
В этих системах появляются такие функциональные возможности, как плани-
рование и учет запуска-выпуска, составление оперативных расписаний, реше-
ние задач первичного учета. Перечисленные функциональные возможности не
только углубили систему планирования, но и создали условия для эффективно-
го регулирования хода производства, что в конечном итоге способствовало по-
219
вышению устойчивости планов верхнего уровня. Сегодня под системами типа
MRP II, как правило, подразумевают именно системы с обратной связью.
Длительный процесс внедрения MRP II позволил, с одной стороны, до-
стичь роста эффективности предприятий, а с другой стороны, выявил ряд при-
сущих этой системе недостатков, в том числе:
 ориентация системы управления предприятием исключительно на
имеющиеся заказы, что затрудняет принятие решений на длительную, средне-
срочную, а в ряде случаев и на краткосрочную перспективу;
 слабая интеграция с системами проектирования и конструирования
продукции, что особенно важно для предприятий, производящих сложную про-
дукцию;
 слабая интеграция с системами проектирования технологических про-
цессов и автоматизации производства;
 недостаточное насыщение системы управления функциями управле-
ния затратами;
 отсутствие интеграции с процессами управления финансами и кадрами.
Необходимость устранить перечисленные недостатки побудила транс-
формировать системы MRP II в системы нового класса — «Планирование ре-
сурсов предприятия» (Enterprise Resource Planning — ERP). Системы этого
класса, в большей степени, ориентированы на работу с финансовой информа-
цией для решения задач управления крупными корпорациями с разнесенными
территориальными ресурсами. Сюда включается все, что необходимо для полу-
чения ресурсов, изготовления продукции, ее транспортировки и расчетов по за-
казам клиентов.
Помимо перечисленных функциональных требований, в ERP воплощены
новые подходы к применению графики, использованию реляционных баз дан-
ных, CASE-технологий для их развития, архитектуры вычислительных систем
типа «клиент-сервер» и реализации их как открытых систем.
Системы типа ERP выполняются следующими функциональными моду-
лями: прогнозирование спроса, управление проектами, управление затратами,
управление составом продукции, ведение технологической информации. В них
прямо или через системы обмена данными встраиваются модули управления
кадрами и финансовой деятельностью предприятия.
Укрупненно структура управления в ERP показана на рисунке 8.10. Ниже
поясняются элементы структуры управления ERP, добавленные к системе MRP II.
Прогнозирование. Оценка будущего состояния или поведения внешней
среды или элементов производственного процесса. Цель — оценить требуемые
параметры в условиях неопределенности. Недостаток информации связан, как
правило, с временным фактором. Прогнозирование может носить как самостоя-
тельный характер, так и, предшествуя планированию, представлять собой пер-
вый шаг в решении задачи планирования.
Управление проектами и программами. В производственных системах,
предназначенных для выпуска сложной продукции, собственно производство
является одним из этапов полного производственного цикла. Ему предшествует

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

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

221
 Ведение информации о технологических маршрутах. Для решения задач
оперативного управления производством необходима информация о последова-
тельности операций, входящих в технологические маршруты, о длительности
операций и количестве исполнителей или рабочих мест, требуемых для их вы-
полнения.
Управление затратами. Этот фрагмент системы оценивает работу произ-
водственных и других подразделений с точки зрения затрат. Роль данной под-
системы — обеспечить связь между управлением производством и управлени-
ем финансовой деятельностью путем решения задач планирования, учета, кон-
троля и регулирования затрат. Задача, как правило, решается в различных раз-
резах — по подразделениям, проектам, типам и видам продукции, изделиям
и т. п. Данная информация используется для выработки управляющих решений,
оптимизирующих экономические показатели предприятия.
Управление финансами. В этой подсистеме решаются задачи управления
финансовой деятельностью. Практически во всех зарубежных системах в нее
входят четыре подсистемы более глубокого уровня: «Главная бухгалтерская
книга», «Расчеты с заказчиками», «Расчеты с поставщиками», «Управление ос-
новными средствами».
Автоматизация управления финансами на предприятии позволяет:
 усилить финансовый контроль путем обобщения всей финансовой де-
ятельности;
 улучшить оборот денежных средств путем обеспечения полного
управления кредитами и счетами дебиторов;
 оптимизировать управление денежными средствами путем автомати-
зации расчетов с поставщиками;
 максимизировать отдачу от капитальных вложений путем обеспече-
ния более эффективного управления основными средствами, арендованной соб-
ственностью, ремонтной базой, незавершенным капитальным строительством.
Управление кадрами. В данной подсистеме решаются задачи управления
кадровыми ресурсами предприятия. Задачи, решаемые в системе управления
кадрами, связаны с набором, штатным расписанием, переподготовкой, продви-
жением по службе, оплатой и т. п.
ERP, таким образом, является улучшенной модификацией MRP II. Ее
цель — интегрировать управление всеми ресурсами предприятия, а не только
материальными, как это было в MRP II.
Такое расширение системы, повышая эффективность управления, вместе
с тем увеличивает и масштабы формальной системы, что усложняет характер
работ по созданию АСУП.
Еще одной особенностью ERP является, по существу, сохранение подхо-
дов к планированию производства, принятых в MRP II. Основная причина со-
стояла в том, что на первоначальном этапе перехода от MRP II к ERP мощность
вычислительных систем была недостаточна для того, чтобы обеспечить широ-
кое применение методов моделирования и оптимизации. Ограничения вычис-
лительного характера привели к тому, например, что плановые решения фор-
мируются путем циклического повторения двух шагов. На первом шаге форми-
222
руется план без учета ограничений на производственные мощности. На втором
шаге он проверяется на допустимость. Процесс повторяется до тех пор, пока
план, полученный на очередной итерации, не будет допустимым.
В ERP решение о включении изделия в график выпуска продукции может
приниматься не только на основе реально имеющегося спроса, но и на основе
прогноза спроса и в связи с выполнением больших проектов и программ. Это,
безусловно, расширяет диапазон применения системы управления и делает ее
более гибкой и оперативной к изменениям внешней среды.
Концепции MRP II/ERP постоянно эволюционируют и совершенствуют-
ся. В каждый момент времени в них можно выделить, условно говоря, три слоя.
В первом слое находятся те методы и средства, которые проверены прак-
тикой и закреплены в виде стандартов. В США существует система стандартов,
которая поддерживается государством, в частности Министерством обороны.
В этих стандартах сформулированы требования к информационным системам
фирм, выполняющих государственные заказы. В результате на стадии заключе-
ния контракта повышается уверенность государства в разумном расходовании
бюджетных средств, а на стадии его выполнения осуществляется всесторонний
контроль за сроками выполнения и фактическими затратами. В качестве приме-
ра можно упомянуть правительственный документ «Требования к системам
управления материальными процессами» (Material Management and Accounting
System — MMAS).
Стандарты, в первую очередь, определяют требования к функциональной
насыщенности систем управления, методам и результатам получения отчетно-
сти о финансовом состоянии контрактов. Фирмы-производители базовых си-
стем тщательно следуют этим стандартам. Именно по этой причине сравни-
тельный анализ различных базовых систем (особенно крупномасштабных) мо-
жет потребовать значительных усилий, поскольку на первый взгляд функцио-
нальные возможности практически не отличаются.
Второй слой составляют достаточно устойчивые, часто применяемые ме-
тоды и приемы, которые, однако, не носят обязательного характера. Эти мето-
ды и приемы можно обнаружить при более глубоком анализе функциональных
структур. В качестве примеров можно привести методологию скользящего пла-
нирования в MPS/MRP, алгоритмы образования партий в MRP, правила прио-
ритетов в SFC и многое другое.
К третьему слою идей и методов MRP II/ ERP следует отнести то новое,
что вносят в свои базовые системы фирмы-производители программных про-
дуктов. Реализованные на их основе новые информационные технологии пред-
ставляют собой «know-how» фирм-разработчиков. Как правило, именно в этом
слое можно обнаружить значительные отличия продуктов различных фирм.
Некоторые из новых технологий в состоянии оказывать серьезное влияние на
эффективность построения крупных информационных систем. К ним относят-
ся, например, «Система динамического моделирования» (Dynamic Enterprise
Modeling — DEM) фирмы BAAN, которая представляет собой проблемно-
ориентированную CASE-технологию проектирования систем управления пред-
приятием.
223
 Видное место среди идей и методов систем MRP II/ERP принадлежит
специально разработанным методикам внедрения систем. Анализ литературы и
опыт общения со специалистами различных фирм показывают, что на сего-
дняшний день сложилось устойчивое представление о том, в какой последова-
тельности и какими методами следует внедрять системы типа MRP II/ERP.
Тщательное планирование проектов по внедрению, организация деятельности
коллективов, упор на переподготовку персонала всех уровней (особенно выс-
шего уровня) — вот далеко не полный перечень условий достижения положи-
тельных результатов.
Наличие мощной структуры и методологии построения систем способ-
ствует достижению высокого уровня эффективности при внедрении систем
управления типа MRP II/ERP на промышленных предприятиях. По некоторым
оценкам, внедрение подобных систем способно привести к сокращению запасов
до 30%, росту производительности труда до 25%, возрастанию количества зака-
зов, выполненных в срок, до 20%.

8.4. Автоматизированные рабочие места (АРМ)

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

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

225
ку не нужна информация о прибыли, финансовому директору — остатки на
складе).
Общим принципом построения АРМ как рабочего места пользователя яв-
ляется принцип дружественности.
Как уже отмечалось выше, ЭИС подразделяются на настольные (локаль-
ные), офисные (ЛВС) и корпоративные.
Особенностью локальных АРМ является их «самодостаточность». Вся
обработка информации от ввода до получения результата осуществляется на
одном АРМ.
Особенностью обработки информации в ЛВС является наличие единых
БД, доступных из многих точек. При этом технология работы с этой информа-
цией, как правило, не зависит от конфигурации сети (шина, звезда, кольцо).
Офисные ЭИС строятся по технологии распределенной обработки данных.
Рассмотрим подробнее, какие технологии распределенной обработки су-
ществуют и в чем их преимущества и недостатки для построения ЭИС.
Персональные компьютеры стоят на рабочих местах, т. е. на местах воз-
никновения и использования информации. Они соединены каналами связи. Это
дает возможность распределить их ресурсы по отдельным функциональным
сферам деятельности и изменить технологию обработки данных в направлении
децентрализации. Распределенная обработка данных позволила повысить эф-
фективность удовлетворения изменяющейся информационной потребности ин-
формационного работника и, тем самым, обеспечить гибкость принимаемых им
решений.
Преимущества распределенной обработки данных: большое число взаи-
модействующих пользователей, выполняющих функции сбора, регистрации,
хранения, передачи и выдачи информации; снятие пиковых нагрузок с центра-
лизованной базы путем распределения обработки и хранения локальных баз
данных на разных ЭВМ; обеспечение доступа информационному работнику к
вычислительным ресурсам сети ЭВМ; обеспечение симметричного обмена дан-
ными между удаленными пользователями.
Формализация концептуальной схемы данных повлекла за собой возмож-
ность классификации моделей представления данных на иерархические, сетевые
и реляционные. Это отразилось в понятии архитектуры систем управления база-
ми данных и технологии обработки. Архитектура СУБД описывает ее функцио-
нирование как взаимодействие процессов двух типов: клиента и сервера.

8.5. Корпоративные информационные системы

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

226
ся (при использовании в КИС) Intranet. Intranet можно определить как совокуп-
ность ЛВС, удовлетворяющих протоколу TCP/IP, которая имеет общее адрес-
ное пространство, где у каждого компьютера есть свой уникальный IP-адрес.
При создании корпоративных ЭИС возникает много проблем. Рассмотрим
возможные варианты их решения.
Одна из проблем — это значительная удаленность офисов корпорации
(фирма IBM имеет офисы на всех континентах). Предполагается, что каждый
офис имеет свою ЛВС. Офисы объединены через Интернет. При этом каждое
рабочее место или каждый сервер, имея свой IP-адрес, может быть доступен из
любой части Intranet.
Другой проблемой КИС является неодновременность разработки про-
граммного прикладного обеспечения для различных подразделений и бизнес-
процессов (например, бухгалтерский учет и управление кадрами). А поскольку
инструментальные средства разработки ППП развиваются очень быстро, то
вновь разработанные приложения не всегда совместимы по данным с уже су-
ществующими. То же происходит при использовании ППП различных фирм.
Таким образом, возникает проблема органического «сопряжения» отдельных
компонентов (ППП) в единую КИС (см. тему 8).
Простейшее стандартное средство взаимодействия отдельных программ-
ных систем — экспорт-импорт данных в текстовом формате. Однако при таком
способе общения обычно нет возможности передать связи между данными
(необходимо преобразование объектов БД в линейные файлы). К тому же не
существует единого общепринятого способа передачи информации в текстовом
формате. В этом случае вряд ли возможно достичь приемлемого времени син-
хронизации работы компонентов по данным.
Для обеспечения информационного взаимодействия между организация-
ми путем обмена объектами БД существует несколько методов информацион-
ной увязки применяемых классификаторов.
Первый метод характерен для систем с равноправными неприоритетны-
ми классификаторами. В этом случае на объектах используются локальные
классификаторы. При получении информации извне для каждого объекта
должна применяться своя система перекодирования.
Второй метод используется, когда во взаимодействующих системах упо-
требляются неравноправные, приоритетные классификаторы. Обработка ин-
формации ведется на базе локальных классификаторов, а обмен данными орга-
низуется в кодах классификаторов с большим приоритетом.
Третий метод предполагает, что для обработки информации в каждой
ЭИС используются локальные классификаторы, а для обмена — единый клас-
сификатор-посредник.
Четвертый метод характеризуется тем, что при обработке информации в
разных ЭИС используются единые классификаторы. При этом обмен информа-
цией не требует дополнительных работ по перекодированию.
Интеграция систем подразумевает, прежде всего, создание общих, «кор-
поративных» информационных ресурсов и обеспечение совместной работы
пользователей с этими ресурсами.
227
 К числу технологий, позволяющих решить эти задачи, относятся:
а) универсальные механизмы динамического обмена данными — DDE
(Dynamic Data Exchange);
б) универсальные механизмы объектной связности баз данных — ODBC
(Object Data Base Connectivity);
в) универсальные механизмы связывания и встраивания объектов — OLE
(Object Linking and Embedding).
Специализированные API — это наборы функций, внешних по отноше-
нию к создаваемой системе и доступных для вызова из нее. API обычно решает
какую-то частную задачу, относится к конкретному набору (подмножеству)
функций приложения или операционной системы (например, MAPI — интер-
фейс для электронной почты). Для интеграции одного из приложений с API
необходимо обеспечить поддержку этого приложения. Среди проблем, возни-
кающих при решении задачи интеграции, — отсутствие описаний для некото-
рых API. Не опубликованы, в частности, описания многих API MS Windows, а
ведь их число достигает нескольких сотен.
а) DDE — протокол обмена данными между Windows-приложениями на
основе сообщений между окнами сервера и клиента. Как показала практика,
этот механизм не позволяет создавать достаточно гибкие и, что самое главное,
устойчивые в среде MS Windows приложения. Это обязывает разработчиков
использовать специальные средства контроля стабильности приложения вкупе
с другими механизмами интеграции;
б) ODBC — API, введенный в 1991 г. компанией Microsoft. Он основан на
SQL-спецификациях и позволяет приложениям «общаться» с разными СУБД.
ODBC — достаточно универсальный механизм, который в значительной мере
решает проблему организации взаимодействия различных баз данных на основе
открытых интерфейсов. В принципе этот механизм способен решить проблему
интеграции. Однако его универсальность приводит к появлению других про-
блем: снижению быстродействия системы (зачастую до неприемлемых значе-
ний), сужению спектра ее возможностей, ослаблению защищенности данных;
в) OLE — надстройка над DDE для создания «составных» документов,
т. е. документов, разные части которых обрабатываются разными приложения-
ми. Это фактический стандарт, определяющий способ предоставления возмож-
ности одному приложению управлять другим приложением. С самого начала
механизм предназначался для разработчиков в качестве средства интеграции
компонентов ПО. Упрощенно «связывание» можно трактовать как отношение
«один документ — много объектов». В основе стандарта лежит Component
Object Model — модель составных объектов.
OLE 2.0 automation представляет набор команд (функций), доступных
внутри одного компонента из другого компонента ПО. Механизм реализует
«внешнее» встраивание, но при этом остается проблема с оперативным обме-
ном данными между приложениями, которые продолжают «жить и работать» в
разных сегментах памяти и являются слабо связанными.
Современным требованиям отвечает интеграция приложений с помощью
механизма управляющих элементов OLE 2.0 OCX (Object Control eXchange) и
228
ActiveX в виде специальных динамических библиотек. Они предназначены для
расширения функциональности приложений. В OLE 2.0 OCX реализуется свое-
образное «внутреннее» встраивание, при котором осуществляется прямое
управление интегрированным компонентом со стороны основной прикладной
системы. Но пока разработчики компонента, который предполагается интегри-
ровать в приложение, не обеспечат поддержку функций OLE 2.0 OCX, исполь-
зовать все перечисленные преимущества невозможно.
Совместное использование согласованных структур данных (Joint Data
Base Structure Using) является на сегодня одним из наиболее надежных спосо-
бов интеграции приложений, разработанных разными компаниями. Для реали-
зации такого подхода требуется тесная координация и весьма высокая квали-
фикация разработчиков.
Примеры КИС
«Комплексная информационная система управления учебным заведе-
нием (КИС УЗ)»
КИС УЗ была разработана Академией МУБиНТ совместно с ЗАО «Ин-
формационные системы» в период с 1999 по 2001 г. Она получила медали и ди-
плом ВВЦ в 2001 г. и зарегистрирована в ОФАП РФ № 50200100251. В ней
осуществляется распределенная обработка информации и интегрированное ее
представление для принятия управленческих решений.
КИС УЗ предназначена для управления работой всего учебного заведе-
ния. Она автоматизирует работу ректората, приемной комиссии, кафедры, де-
каната, планово-экономической службы, бухгалтерии, вахтера, технической
службы. Каждый работник учебного заведения, находясь на своем рабочем ме-
сте, пользуется единой базой данных студентов, учебных планов, преподавате-
лей, аудиторий. Система прослеживает успеваемость и оплаты студентов от
абитуриента до выпускника; преподавателя — от плана до заработной платы.
Система осуществляет распределенную обработку информации и инте-
грированное представление данных для принятия управленческих решений.
КИС УЗ позволяет:
 индивидуализировать образовательную траекторию учащегося;
 обеспечить «гибкость» учебного процесса;
 добиться эффективности использования ресурсов образовательного
учреждения;
 вести постоянный мониторинг качества образовательного процесса.
Архитектура КИС УЗ представлена на рисунке 8.11.
Функции подсистем
Подсистема «Учебные планы»
1. Формирование учебных планов по специальности (3-х видов: для ву-
зов по семестрам; для средних профессиональных учебных заведений по се-
местрам; индивидуальный учебный план).
2. Построение структурно-логической схемы (СЛС) прохождения дис-
циплин по специальности.
3. Формирование учебного плана на основе СЛС.
229
 4. Анализ на соответствие государственным стандартам.
5. Формирование рабочих планов по семестрам с подсчетом нагрузки на
семестр и в неделю.
6. Формирование распределения нагрузки по кафедрам.
7. Формирование индивидуальных планов преподавателей.
8. Генератор оформления учебных планов для печати.
9. Анализ распределения нагрузки по кафедрам.
10. Сводные ведомости по анализу нагрузки.
11. Анализ эффективности планирования по специальностям для учебно-
го заведения.
12. Закрепление рабочих планов за группами.
13. Закрепление рабочих планов за студентами.
14. Планирование структуры учебной нагрузки на следующий учебный
год.
15. Планирование учебной нагрузки вуза.
16. Обмен учебными планами и СЛС между системами КИС УЗ (вузами).

Рис. 8.11
Архитектура КИС УЗ
Подсистема «Расписание»
1. Ввод и корректировка расписания (текущего и на семестр).
2. Оперативный анализ расписания по:
 выполнению плана по преподавателям;
 выполнению плана по группам;
 индивидуальному плану преподавателя.
3. Ведение БД аудиторного фонда с учетом технического оснащения и
программных средств обучения.

230
 4. Ведение БД изменения расписания с анализом изменений в виде ве-
домости и графика.
5. Ведение БД установки дополнительного оборудования в аудитории.
6. Печать расписания (в разных разрезах: по группе, по дате, за период,
по преподавателю, по направлению; текущего и на семестр).
7. Анализ использования аудиторного фонда (в графике).
8. Фактически отработанное время преподавателя.
9. БД пройденных курсов.
10. Нагрузка на группу.
11. Вывод расписания в Интернет для ограниченного доступа.
Подсистема «Студенты»
1. Отдел кадров студентов:
 личная карточка студента;
 несколько личных дел на одного студента (дополнительное образо-
вание);
 генератор произвольных приказов;
 генератор произвольных запросов;
 генератор произвольных документов (документатор).
2. Обучение студента:
 дополнительное образование;
 учет успеваемости (по закрепленным учебным планам);
 организация сессии;
 работа с недопуском;
 печать экзаменационных групповых, индивидуальных и сводных ве-
домостей;
 печать экзаменационных и сводных ведомостей;
 печать ведомости по задолжникам;
 журнал работы с родителями;
 анализ успеваемости (диаграммы по предмету, по группе, по курсу,
по специальности, по количеству задолженностей);
 обучение по индивидуальному плану (согласно СЛС);
 выдача учебных пособий;
 фотография студента;
 рейтинг студентов.
Подсистема «Абитуриенты»
1. Организация вступительных испытаний.
2. Подсчет средних и проходных баллов.
3. Генератор отчетных форм.
4. Перевод в студенты абитуриентов, прошедших испытание.
5. Перевод в резерв абитуриентов, не прошедших испытание.
6. Расчеты за обучение:
 учет платы студентов за обучение;
 начисление платы за обучение;

231
  долг/переплата;
 анализ начислений и оплат.
7. Подготовка и проведение итоговой аттестации:
 утверждение тем дипломных работ;
 формирование приказа о допуске;
 итоги ГАК;
 формирование и печать вкладыша в диплом.
Подсистема «Преподаватели»
1. Отдел кадров преподавателей:
 личные карточки преподавателей;
 генератор произвольных приказов;
 генератор произвольных запросов.
2. Научная работа.
3. Учебно-методическая работа.
4. Индивидуальный план преподавателя.
5. Анализ выполнения индивидуального плана.
6. Подготовка и проведение расчетов по заработной плате.
7. Сертификация преподавателей.
8. Обмен данными по преподавателям между системам КИС УЗ (вузами).
КИС УЗ предполагает наличие значительного числа рабочих мест, зача-
стую удаленных на большие расстояния, поэтому она реализована в технологии
«клиент-сервер» на базе платформенных решений фирмы Microsoft (MS SQL-
сервер и т. п.).
Необходимо отметить, что права доступа — это один из ключевых мо-
ментов формирования рабочих мест (АРМ). Система доступа определяет уро-
вень решаемых задач, полномочий и ответственности за ввод и обработку ин-
формации и принятие управленческих решений. Максимальные права — у ад-
министратора БД, минимальные — у класс-менеджера, выдающего ключи от
аудиторий, и у студентов — они могут только с помощью барузера просматри-
вать расписание. Вид экрана для формирования прав доступа конкретного ра-
бочего места (АРМ) представлен на рисунке 8.12.
Из рассмотрения рисунка видно, что предоставление прав осуществляется
вплоть до реквизитов (редактирование или только чтение, или «невидимость»).
Например, в Академии МУБиНТ реально функционирует более 200 АРМ
КИС УЗ.
Другие КИС
Корпоративная информационная система «Галактика». Ознакомить-
ся с ней можно на сайте www.galaktika.ru.

Корпоративная информационная система «Парус». Ознакомиться с

ней можно на сайте www.parus.ru
Электронные адреса других КИС можно найти в списке электронных ре-
сурсов.

232
 Рис. 8.12
Администрирование АРМ

8.6. Вопросы для самопроверки

1. По каким признакам классифицируются ЭИС?
2. Каковы признаки классификации ЭИС по масштабам применения?
3. Какие виды обрабатываемой информации вы знаете?
4. В чем разница в обработке различных видов информации?
5. Какие виды документов участвуют в документообороте?
6. Какие типовые технологические процессы канцелярии вы знаете?
7. В чем различие между системами управления предприятиями MRP,
MRP II, ERP?
8. Что такое АРМ и каковы его характеристики?

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

9.1. Типовое проектирование

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

234
 Достоинства элементного метода типового проектирования ЭИС связа-
ны с применением модульного подхода к проектированию и документирова-
нию ЭИС.
К недостаткам применения метода относятся большие затраты времени
на сопряжение разнородных элементов вследствие информационной, про-
граммной и технической несовместимости ТПР, а также плохая адаптивность
(настраиваемость) элементов к особенностям предприятия (см. также метод
«шахт»).
При использовании подсистемного метода типового проектирования
ЭИС в качестве элементов типизации выступают отдельные подсистемы, кото-
рые обеспечивают функциональную полноту, минимизацию внешних инфор-
мационных связей, параметрическую настраиваемость, альтернативность схем
в пределах значений входных параметров. При этом достигается более высокая
степень интеграции типовых элементов ЭИС. Типовые проектные решения для
функциональных подсистем реализуются в виде пакетов прикладных программ
(ППП).
Вместе с тем, адаптивность типовых проектных решений в виде функци-
ональных ППП недостаточна с позиции непрерывного инжиниринга деловых
процессов. Также возникают проблемы в комплексировании ППП разных
функциональных подсистем, особенно в случае использования ППП несколь-
ких производителей программного обеспечения, для которых, как правило, ха-
рактерна их информационная, программная и техническая несовместимость
между собой при построении единой, корпоративной ЭИС.
В качестве примера можно рассмотреть ЭИС Академии МУБиНТ, кото-
рая включает следующие подсистемы:
 Управление учебным процессом КИС УЗ (MS SQL, C++).
 Бухгалтерский учет «1С УПП».
 Документооборот MS Outlook.
Совместная работа этих ППП достигается большими усилиями. Так, связь
КИС УЗ и 1С осуществляется через текстовые файлы экспорта импорта 1С, что
не позволяет осуществлять оперативное взаимодействие. MS Outlook вообще не
связан с другими подсистемами.
При объектном методе типового проектирования ЭИС в качестве типо-
вого элемента используется типовой проект для объектов управления опреде-
ленной отрасли, который включает полный набор функциональных и обеспечи-
вающих подсистем ЭИС.
Несомненное преимущество объектного метода типового проектирования
ЭИС перед подсистемным методом заключается в комплексируемости всех
компонентов за счет методологического единства и информационной, про-
граммной и технической совместимости компонентов.
Адаптивность объектного метода проектирования зависит от используе-
мого подхода. При параметрической настройке типовых информационных си-
стем, таких, например, как КИС «Галактика», «Парус», «БОСС» и другие, воз-
никают проблемы привязки типового проекта к конкретному объекту управле-
ния так же, как и при подсистемном подходе. Обычным способом решения
235
проблемы адаптации является изменение структуры организационно-экономи-
ческой системы объекта внедрения в соответствии с требованиями типового
проекта либо существенная доработка типового проекта с помощью специаль-
ных инструментальных средств типовой системы.
В настоящее время развивается модельно-ориентированный подход реа-
лизации объектного метода типового проектирования ЭИС, известный по при-
менению типовых информационных систем R/3 (SAP) и BAAN IV (BAAN).
Особенность этого подхода заключается в настройке типового проекта на осо-
бенности объекта управления путем привязки модели проблемной области к
модели типовой системы. Поддержание при этом модели проблемной области в
репозитории системы сближает метод типового проектирования с методом ав-
томатизированного проектирования как в части более точного определения и
модификации требований к информационной системе, так и в части корректно-
сти параметрической настройки и автоматизированной доработки проектных
решений.

9.2. Прототипное проектирование ЭИС (RAD-технология)

Основное желание заказчика ЭИС — получить готовое приложение вы-
сокого качества быстро и при минимальных затратах на его разработку. Кроме
того, вкладывая значительные средства на создание системы, заказчики желают
контролировать процесс разработки. Критерием качества должно быть наибо-
лее полное удовлетворение требований заказчиков на момент введения системы
в эксплуатацию.
Одним из условий обеспечения высокого качества создаваемых ЭИС яв-
ляется активное вовлечение конечных пользователей в процесс разработки
предназначенных для них интерактивных систем, что нашло отражение в мето-
дологии прототипного проектирования. Ядром этой методологии является
быстрая разработка приложений RAD (Rapid Application Development).
При создании сложных корпоративных ЭИС пользователям необходимо
работать совместно с проектировщиками на протяжении всего периода разра-
ботки. Одним из путей повышения качества и эффективности создаваемых та-
ким образом систем является применение технологии прототипного проектиро-
вания.
Данная технология обеспечивает создание на ранней стадии реализации
действующей интерактивной модели системы, так называемой системы-
прототипа, позволяющей наглядно продемонстрировать пользователю буду-
щую систему, уточнить его требования, оперативно модифицировать интер-
фейсные элементы: меню, выходные документы, структуру диалога, состав ре-
ализуемых функций.
В процессе работы с системой-прототипом пользователь реально осознает
возможности будущей системы и определяет наиболее удобный для него режим
обработки данных, что значительно повышает качество создаваемых систем.
Осуществляются проверка принципиальных проектных решений по составу и
структуре ЭИС и оценка основных ее эксплуатационных характеристик.

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

Рис. 9.1
Жизненный цикл создания ЭИС на основе RAD-технологии

237
 9.3. Вопросы для самопроверки
1. Какие типы адаптивных систем вы знаете?
2. Какие методы типового проектирования существуют?
3. Приведите пример элементного проектирования системы.
4. Приведите пример подсистемного проектирования системы.
5. Какие тиражируемые ЭИС вам известны?
6. Что такое прототипное проектирование и в чем его сущность?

238
 ТЕМА 10. ВЫБОР И РАЗВИТИЕ ЭИС
ПРЕДПРИЯТИЯ ИЛИ ОРГАНИЗАЦИИ
Для построения уникальной ИС необходимо выбрать метод адаптации и
саму систему, которая будет изменяться, настраиваться и т. д. От правильного
выбора системы будут зависеть не только трудозатраты и стоимость адаптации,
но и эффективность деятельности предприятия.

10.1. Основные критерии выбора системы

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

239
 Таблица 10.1
Цели внедрения информационных технологий (с точки зрения бизнеса)
Респонденты, использую-
Критерии щие критерии для оценки
отдачи от внедрения ИС
Сокращение операционных расходов 71
Способность сохранить конкурентоспособность или вы- 62
рваться вперед
Возможность повысить доходность текущих операций 44
Возможность увеличить свою долю рынка 40
Сокращение длительности основных производственных 39
циклов
Улучшение внутреннего контроля 36
Соответствие предварительно установленным финансовым 19
показателям
Возможность ввести новые направления бизнеса 17
Поэтому при выборе системы потребности бизнеса, сформулированные в
терминах бизнеса, должны быть конвертированы в технические и экономиче-
ские требования к системе, сформулированные в соответствующих терминах:
 функциональные возможности;
 совокупная стоимость владения;
 перспективы развития, поддержки и интеграции;
 технические характеристики.
Рассмотрим некоторые из этих критериев подробнее.
Функциональные возможности. Под функциональными возможностями
следует понимать соответствие автоматизированной системы тем основным
бизнес-функциям, которые существуют или планируются к внедрению в орга-
низации. Иногда говорят о функциональной полноте предлагаемых решений.
Так, если целью организации является минимизация финансовых потерь за счет
оптимизации и упрощения бухгалтерского учета, то выбранная система должна
обеспечивать автоматизацию процесса ведения бухгалтерского учета. Если тре-
буется достичь конкурентного преимущества за счет сокращения сроков разра-
ботки новых видов продукции, то одно из решений может заключаться в выбо-
ре системы CAD/CAM (САПР).
Для того чтобы определить достаточность функциональных возможно-
стей системы, необходимы два компонента:
1) стратегия развития бизнеса и контекстное описание бизнеса;
2) формализованное описание деятельности предприятия.
Лучше всего, если это будут модели деятельности предприятия, выпол-
ненные согласно методикам структурного анализа: диаграммы согласно стан-
дартам IDEFO или IDEF3; диаграммы потоков данных или модели бизнес-
процессов.
В идеальном случае стратегия развития бизнеса и контекстное описание
бизнеса должны содержаться в стратегическом плане автоматизации предприя-
тия. Если исходные данные для выбора системы отсутствуют, то в план выбора

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

241
 10.2. Совокупная стоимость владения
Совокупная стоимость владения (ТСО — Total Cost of Ownership) ин-
формационной системой — сравнительно новое понятие, которому в последнее
время уделяется самое пристальное внимание в литературе. Под совокупной
стоимостью владения понимается сумма прямых и косвенных затрат, которые
несет владелец системы за период жизненного цикла последней.
При анализе ТСО рассматривают жизненный цикл, включающий в себя
время жизни существующей на предприятии системы, время, необходимое для
проектирования нового альтернативного решения, срок эксплуатации альтерна-
тивной системы с учетом амортизации ее элементов и ориентировочного срока
ожидания.
Под сроком ожидания понимают время, необходимое для выхода систе-
мы на уровень доходности, при котором ее эксплуатация позволяет получить
частичный (до 90%) возврат инвестиций, вложенных в систему.
При выборе новой информационной системы между альтернативными
существующему решению вариантами необходимо оценить совокупную стои-
мость владения для каждого предлагаемого варианта.
При этом жизненный цикл, на котором оцениваются прямые и косвенные
затраты, должен включать:
 время жизни существующей на предприятии системы;
 время проектирования новой системы;
 время на закупку и внедрение элементов новой системы;
 время эксплуатации новой системы, которое необходимо ограничить
сроком возврата 90% вложенных инвестиций за счет прибыли от эксплуатации
этой системы.
Вариант информационной системы с более коротким жизненным циклом
предпочтителен для дальнейшего использования. На рисунке 10.1 самым рацио-
нальным является вариант А.
Точка выбора новой системы для каждого предприятия индивидуальна.
Предприятие может начать этот процесс в различных случаях, например:
 при появлении необходимости дополнить или изменить функции су-
ществующей информационной системы, чтобы они соответствовали изменив-
шимся потребностям бизнеса и не приводили к неоправданным финансовым
потерям;
 при достижении доходов от эксплуатации существующей системы
порядка 90% вложенных в нее инвестиций;
 при превышении эксплуатационных затрат на систему над доходами
от ее использования и др.
Прямые и косвенные затраты могут включать следующие составляющие.
Прямые затраты
Основные затраты:
 создание информационной системы;
 оборудование — серверы, клиентские места, периферия, сетевые ком-
поненты;
242
  программное обеспечение (ПО);
 приложения, утилиты, управляющее ПО;
 обновление (модернизация).

Рис. 10.1
Варианты выбора информационной системы
1 — точка завершения проектирования существующей системы; 2 — точка завершения
внедрения существующей системы; 3 — точка ввода в эксплуатацию новой системы; Х —
точка выбора новой системы; А — точка возврата 90% инвестиций в новую информацион-
ную систему (вариант А); В — точка возврата 90% инвестиций в новую информационную
систему (вариант В); С — точка возврата 90% инвестиций в новую информационную систе-
му (вариант С).
Эксплуатационные затраты:
 управление задачами (сетью, системой, массивами памяти);
 поддержка работоспособности системы, персонал, функционирова-
ние справочной службы, обучение, закупки, подготовка контрактов на под-
держку системы;
 разработка инфраструктуры, бизнес-приложений.
Прочие затраты:
 создание коммуникаций — глобальные сети, взаимодействие с по-
ставщиками сервиса, удаленный доступ, Интернет, доступ клиента;
 управление и поддержка — аутсорсинг, сопровождение, справочная
система.
Все затраты на создание информационной системы, которые ассоцииру-
ются с установкой оборудования и его подготовкой к эксплуатации, должны
оцениваться как часть инвестиций. Эти разовые затраты могут включать в себя
такие составляющие, как проектирование системы, программирование, тести-
рование системы, ревизию системы, приобретение оборудования, разработку и
изменение руководств, обучение и передвижения в связи с установкой, тести-
рованием и параллельным запуском системы.
243
 Затраты на оборудование включают в себя стоимость компонентов си-
стемы, затраты в течение жизненного цикла, такие как смена оборудования, ко-
торое заменяется до истечения жизненного цикла. Затраты на оборудование мо-
гут включать и такие разовые расходы, как сопутствующая мебель для перифе-
рийных устройств.
Оценки подготовительных работ должны основываться на масштабах ре-
новаций и включать в себя изменение расположения при перемещении, добав-
лении или удалении оборудования.
Кроме того, в эти затраты необходимо включать и изменения в электро-
питании, освещении и кондиционировании воздуха. Если часть оборудования
берется в лизинг, то суммарные затраты на это оборудование выделяются в от-
дельную категорию.
В таблице 10.2 перечислены основные виды затрат и их составляющие,
которые необходимо учитывать при определении совокупной стоимости владе-
ния.
Перспективы развития, поддержки и интеграции в основном определя-
ются поставщиком решения и тем комплексом стандартов, который заложен в
систему и составляющие ее компоненты.
Устойчивость поставщика решения и поставщиков отдельных компонен-
тов определяется, в первую очередь, временем существования их на рынке и
долей рынка (как мирового, так и российского), которую они занимают. Важ-
ным фактором является форма, в которой осуществляется присутствие на рос-
сийском рынке: наличие сети сертифицированных центров технической под-
держки, авторизованных учебных центров, «горячих линий» для консультаций.
Таблица 10.2
Эксплуатационные затраты (затраты на обслуживание и работу системы)
Вид затрат Характеристика затрат
Прямые затраты
1. Затраты на сетевое Затраты на определение причины неисправности и решение про-
управление — расхо- блемы (ремонт), после того как поступило сообщение о неисправ-
ды административно- ности в сети;
го персонала на ре- регулярные затраты на измерение сетевого трафика и планирова-
шение задач, ассоци- ние его оптимизации;
ируемых с управле- регулярные затраты на настройку производительности сетевых
нием сетью и клиен- компонентов и межкомпонентных соединений;
тами временные затраты, связанные с добавлением, перемещением,
удалением пользователей и изменением прав доступа к сети;
затраты на поддержку сетевых и клиентских операционных си-
стем, включая установку, настройку и инсталляцию драйверов;
затраты на поддержание работоспособности сети и клиентов,
наподобие диагностики, проверок и прочих задач, которые не по-
падают в категории, указанные выше;
затраты на поддержку пользователя, поддержки производителей,
не попадающие в перечисленные выше категории

244
 Продолжение табл. 10.2
Вид затрат Характеристика затрат
2. Затраты на управ- Затраты, связанные с исследованием и планированием проекта но-
ление системой — вых компьютерных систем, сетевых и коммуникационных компо-
расходы на управле- нентов, затраты на выбор различных стратегий и конфигураций;
ние приложениями, затраты, связанные с оценкой и покупкой новых компьютеров, се-
имуществом и мигра- тевых компонентов, коммуникационных устройств и программного
циями обеспечения, определение поставщика, модели и получение фи-
нансов;
затраты, связанные с управлением, контролем за лицензиями, дис-
трибуцией и конфигурированием программного обеспечения по
сети;
затраты, связанные со сбором информации, относящейся к имуще-
ству, и включающие в себя инвентаризацию, контроль закупок и
отслеживание конфигураций имущества;
затраты на управление программным обеспечением сети, включа-
ющее в себя контроль версий, доступа и запуска;
затраты, связанные с контролем за системой с целью обнаружения
и предотвращения нарушений правил безопасности, вирусных атак
и с мероприятиями по восстановлению после нарушений;
затраты, связанные с конфигурированием новых решений или пе-
ренастройкой существующих решений (решение включает в себя
компоненты системы, топологию, местоположение, а также любые
физические или логические замену и инсталляцию);
затраты, связанные с установкой дополнительного оборудования
или модернизацией (за исключением программной модернизации)
3. Затраты на управ- Затраты, связанные с организацией, оптимизацией и восстановле-
ление устройствами нием файлов в сети;
хранения данных, рас- затраты, связанные с контролем и проверкой оптимизации храня-
ходы на задачи, свя- щихся данных;
занные с управлением затраты, связанные с обеспечением доступа к данным и устрой-
и контролем за дан- ствам хранения информации;
ными и их хранением затраты по конфигурированию, управлению, оптимизации и под-
в сети держке систем архивирования и резервного копирования;
затраты на создание, испытание, управление и поддержку планов
прогнозирования и восстановления неисправностей;
затраты по управлению средствами хранения данных и репозито-
рием в реальном времени
Косвенные затраты
Затраты, связанные с Контроль, отправка и получение почты, телефонные разговоры,
оплатой действий, ввод информации, переводы, расходы на помещение, потери от
напрямую не являю- плановых и внеплановых простоев, коммунальные услуги и под-
щихся рабочими держка административного и конторского персонала
функциями
Немаловажным фактором риска могут стать такие показатели, как гаран-
тированное время доставки запасных частей, которое формулируется в терми-
нах: «время доставки не превосходит такого-то». Это относится и к сопровож-
дению программного обеспечения системы. При определении системы сопро-
вождения необходимо оговаривать время исправления обнаруженных ошибок,
совершенствования системы и внесения незначительных усовершенствований.

245
 Технические характеристики формулируются в соответствующих терми-
нах:
 время отклика;
 трафик в сети;
 объем оперативной памяти;
 объем памяти на жестких дисках;
 система внешней памяти и т. д.

246
 ТЕМА 11. CASE-ТЕХНОЛОГИИ
ПРОЕКТИРОВАНИЯ КИС
Традиционная (каноническая) технология создания ИС предъявляет осо-
бые требования к методикам реализации, а именно:
1. Реализацию проектов по созданию ИС принято разбивать на стадии
анализа (прежде чем создавать ИС, необходимо понять и описать бизнес-логику
предметной области), проектирования (необходимо определить модули и архи-
тектуру будущей системы), непосредственного кодирования, тестирования и
сопровождения. Известно, что исправление ошибок, допущенных на предыду-
щей стадии, обходится примерно в 10 раз дороже, чем на текущей, откуда сле-
дует, что наиболее критическими являются первые стадии проекта. Поэтому
крайне важно иметь эффективные средства автоматизации ранних этапов реа-
лизации проекта.
2. Проект по созданию сложной ИС невозможно реализовать в одиноч-
ку. Коллективная работа существенно отличается от индивидуальной, поэтому
при реализации крупных проектов необходимо иметь средства координации и
управления коллективом разработчиков.
3. Жизненный цикл создания сложной ИС сопоставим с ожидаемым
временем ее эксплуатации. Другими словами, в современных условиях компа-
нии перестраивают свои бизнес-процессы примерно раз в два года, столько же
требуется (если работать в традиционной технологии) для создания ИС. Может
оказаться, что к моменту сдачи ИС она уже никому не нужна, поскольку ком-
пания, ее заказавшая, вынуждена перейти на новую технологию работы. Следо-
вательно, для создания ИС жизненно необходим инструмент, значительно
(в несколько раз) уменьшающий время разработки и переработки ИС.
4. Вследствие значительного жизненного цикла может оказаться, что в
процессе создания системы внешние условия изменились. Обычно внесение
изменений в проект на поздних этапах создания ИС — весьма трудоемкий и
дорогостоящий процесс. Поэтому для успешной реализации крупного проекта
необходимо, чтобы инструментальные средства, на которых он реализуется,
были достаточно гибкими к изменяющимся требованиям.
Выполнить эти требования или обеспечить разработку больших и слож-
ных систем немыслимо без использования средств автоматизации проектирова-
ния CASE (Computer Aided Software Engineering).

11.1. CASE-модель жизненного цикла ИС

CASE-технологии предлагают новый, основанный на автоматизации
подход к концепции ЖЦ ПО. При использовании CASE изменяются все фазы
ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования.
На рисунке 11.1 приводится простейшая модель ЖЦ (А) и соответствую-
щая CASE-модель (Б), в которой фаза прототипирования заменяет традицион-
ную фазу системного анализа. Необходимо отметить, что наиболее автоматизи-

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

Рис. 11.1
Модели жизненного цикла ПО
В таблице 11.1 приведены оценки трудозатрат по фазам ЖЦ. Первая
строка таблицы соответствует традиционной разработке, вторая — разработке с
использованием структурных методологий проектирования, третья — разра-
ботке с использованием CASE-технологий.
В таблицу 11.2 сведены основные изменения в ЖЦ при использовании
CASE-технологий по сравнению с традиционной разработкой.
Таблица 11.1
Оценки трудозатрат по фазам ЖЦ
Проектиро- Тестирова-
Способ разработки Анализ Кодирование
вание ние
Традиционная разработка 20% 15% 20% 45%
Использование структурных 30% 30% 15% 25%
методологий проектирования
Использование CASE- 40% 40% 5% 15%
технологий

248
 Таблица 11.2
Сравнение трудоемкости этапов жизненного цикла традиционной технологии
и CASE-технологии
Традиционная разработка CASE
Основные усилия — на кодирование и Основные усилия — на анализ и проектирова-
тестирование ние
«Бумажные» спецификации Быстрое итеративное прототипирование
Ручное кодирование Автоматическая кодогенерация
Ручное документирование Автоматическая генерация документации
Тестирование кодов Автоматический контроль проекта
Сопровождение кодов Сопровождение спецификаций проектирования
На рисунке 11.2 представлены результаты сравнения традиционной раз-
работки программных проектов и разработки с применением CASE-технологий.

Рис. 11.2
Уменьшение затрат на проектирование программных систем за счет CASE-технологий
Их анализ показывает, что наиболее эффективно использование CASE-
технологий для ИС, начиная с объема в 1000 п/программ, т. е. для больших си-
стем.

249
 11.2. Состав, структура и функциональные особенности
CASE-средств
CASE-средства служат инструментарием для поддержки и усиления ме-
тодов анализа и проектирования. Эти инструменты поддерживают работу поль-
зователей при создании и редактировании графического проекта в интерактив-
ном режиме, они способствуют организации проекта в виде иерархии уровней
абстракции, выполняют проверки соответствия компонентов. Фактически
CASE-средства представляют собой новый тип графически-ориентированных
инструментов, восходящих к системе поддержки ЖЦ ИС. Обычно к ним отно-
сят любое программное средство, обеспечивающее автоматическую помощь
при разработке ПО, его сопровождении или деятельности по управлению про-
ектом и проявляющее следующие дополнительные черты:
 мощная графика для описания и документирования систем ИС, а так-
же для улучшения интерфейса с пользователем, развивающая творческие воз-
можности специалистов и не отвлекающая их от процесса проектирования на
решение второстепенных вопросов;
 интеграция, обеспечивающая легкость передачи данных между сред-
ствами и позволяющая управлять всем процессом проектирования и разработки
ИС непосредственно через процесс планирования проекта;
 использование компьютерного хранилища (репозитория) для всей ин-
формации о проекте, которая может разделяться между разработчиками и ис-
полнителями как основа для автоматического продуцирования ПО и повторно-
го его использования в будущих системах.
CASE-технология в рамках методологии включает в себя методы, кото-
рые с помощью графической нотации строят диаграммы и поддерживаются ин-
струментальной средой.
Методология определяет шаги и этапность реализации проекта, а также
правила распределения методов, с помощью которых разрабатывается проект.
Метод — это процедура или техника генерации описаний компонент
ЭИС (например, проектирование потоков и структур данных).
Нотация — отображение структуры системы, элементов данных, этапов
обработки с помощью специальных графических символов диаграмм, а также
описание проекта системы на формальных и естественных языках.
Инструментальные средства CASE — специальные программы, которые
поддерживают одну или несколько методологий анализа и проектирования ИС.
Рассмотрим архитектуру CASE-средства, которая представлена на рисун-
ке 11.3.
Ядром системы является база данных проекта — репозиторий. Он пред-
ставляет собой специализированную базу данных, предназначенную для отобра-
жения состояния проектируемой ЭИС в каждый момент времени. Объекты всех
диаграмм синхронизированы на основе общей информации словаря данных.
Интегрированный CASE-пакет содержит 4 основных компонента.
Средства централизованного хранения всей информации о проектиру-
емом ПО в течение всего ЖЦ (репозиторий) являются основой CASE-пакета.
250
Соответствующая БД должна иметь возможность поддерживать большую си-
стему описаний и характеристик и предусматривать надежные меры по защите
от ошибок и потерь информации.

Рис. 11.3
Архитектура CASE-средства
Репозиторий должен обеспечивать:
 инкрементный режим при вводе описаний объектов;
 распространение действия нового или скорректированного описания
на информационное пространство всего проекта;
 синхронизацию поступления информации от различных пользовате-
лей;
 хранение версий проекта и его отдельных компонент;
 сборку любой запрошенной версии;
 контроль информации на корректность, полноту и состоятельность.
Средства ввода предназначены для ввода данных в репозиторий, а также
для организации взаимодействия с CASE-пакетом. Эти средства должны под-
держивать различные методологии и использоваться на всем ЖЦ разными кате-
гориями разработчиков: аналитиками, проектировщиками, инженерами, адми-
нистраторами и т. д.
Средства анализа, проектирования и разработки предназначены для
того, чтобы обеспечить планирование и анализ различных описаний, а также их
преобразование в процессе разработки.
Средства вывода служат для документирования, управления проектом и
кодовой генерации.
Все перечисленные компоненты в совокупности должны:
 поддерживать графические модели;
 контролировать ошибки;
 организовывать и поддерживать репозиторий;
 поддерживать процесс проектирования и разработки.

251
Поддержка графических моделей
Графическая ориентация CASE заключается в том, что программы явля-
ются схематическими проектами и формами, которые много проще в использо-
вании, чем многостраничные описания.
Для представления программ применяются структурные диаграммы раз-
личных типов, дополнительное достоинство которых заключается в их исполь-
зовании в качестве наглядной «двумерной» документации по проекту.
Для CASE существенны 4 типа диаграмм:
 диаграммы функционального проектирования (для этих целей
наиболее часто употребляются DFD-диаграммы потоков данных);
 диаграммы моделирования данных (как правило, ERD-диаграммы
«сущность — связь»);
 диаграммы моделирования поведения (как правило, STD-диаграммы
переходов состояний);
 структурные диаграммы (карты), применяющиеся на этапе проекти-
рования и описывающие отношения между модулями и внутримодульную
структуру.
Существуют и другие диаграммы, но они являются, как правило, вспомо-
гательными. Создание и модификация подобных диаграмм осуществляется с
помощью специальных графических редакторов (диаграммеров), являющихся
сервисными средствами на этапах анализа требований и проектирования спе-
цификаций.
Современные диаграммеры обеспечивают:
 создание иерархически связанных диаграмм, в которых комбиниру-
ются графические и текстовые объекты;
 создание и редактирование объектов в любом месте диаграммы;
 создание, перемещение и выравнивание групп объектов, изменение их
размеров, масштабирование;
 сохранение связей между объектами при их перемещении и измене-
нии размеров;
 автоматический контроль ошибок и др.
Реализация подобных возможностей позволяет пользователю целиком со-
средоточиться на собственно проектировании, не отвлекаясь на решение второ-
степенных вопросов, связанных с размещением элементов диаграмм, их компо-
новкой и т. п.
Контроль ошибок
Важность контроля ошибок на этапах анализа требований и проектирова-
ния спецификаций обуславливается возможностью их автоматического обна-
ружения на ранних этапах ЖЦ. CASE обеспечивает автоматическую верифика-
цию и контроль проекта на полноту и состоятельность на ранних этапах ЖЦ,
что влияет на успех разработки в целом.
В подтверждение этого можно привести следующие статистические дан-
ные, основанные на отчетах фирмы TRW по анализу 5 крупных проектов:

252
  при традиционной организации работ ошибки проектирования и ко-
дирования составляют соответственно 64% и 32% от общего числа ошибок;
 ошибки проектирования в 100 раз труднее обнаружить на этапе со-
провождения ПО, чем на этапах анализа требований и проектирования специ-
фикаций.
В CASE диаграммеры и верификаторы способны осуществлять следую-
щие типы контроля.
Контроль синтаксиса диаграмм и типов их элементов обычно осу-
ществляется при вводе и редактировании элементов диаграмм.
Примеры контролируемых ситуаций.
По синтаксису: любой функциональный элемент диаграммы должен
иметь, по крайней мере, один входной и один выходной поток; два элемента
данных могут быть непосредственно связаны.
По типам: функциональный элемент должен всегда использоваться для
представления процедурной компоненты; поток данных всегда должен быть
представлен компонентой данных.
Контроль полноты и состоятельности диаграмм: все элементы диа-
грамм должны быть идентифицированы и отражены в репозитории. Например,
для DFD контролируются неименованные или несвязанные потоки данных,
процессы и хранилища данных; источники и стоки данных (внешние сущности)
вне контекстной диаграммы; хранилища данных на контекстной диаграмме
и т. п. При анализе словаря данных необходимо выявлять циклические опреде-
ления, эквивалентные определения, неопределенные объекты.
Контроль декомпозиции функций включает оценку качества на основе
различных метрик ПО и частичный семантический контроль.
Сквозной контроль диаграмм одного или различных типов на предмет
их состоятельности по уровням — вертикальное и горизонтальное балансиро-
вание диаграмм. При вертикальном балансировании (диаграммы одного типа)
выявляются несбалансированные потоки данных между детализируемой и де-
тализирующей диаграммами. Горизонтальное балансирование определяет не-
корректности между DFD, ERD, STD, словарями данных и мини-
спецификациями процессов. Так, при балансировании DFD-ERD контролирует-
ся соответствие каждого хранилища данных на DFD сущности или отношение
на ERD. Контроль DFD-STD осуществляется по следующим правилам: каждый
управляющий процесс на DFD детализируется спецификацией управления STD
и, наоборот, каждой STD должен соответствовать управляющий процесс; каж-
дое условие (действие) в STD должно соответствовать входному (выходному)
управляющему потоку на DFD и, наоборот, каждому управляющему потоку в
зависимости от его направленности должно соответствовать условие/действие
на STD.
При балансировании DFD словарь данных и мини-спецификация должны
проверяться на следующие правила:
 каждый поток и хранилище данных должны быть определены в сло-
варе данных (контроль неопределенных значений) и, наоборот, каждое опреде-

253
ление в словаре должно быть отражено на диаграмме, в мини-спецификации
или другом определении (контроль неиспользуемых значений);
 каждый процесс на DFD должен детализироваться с помощью DFD
или мини-спецификации (но не тем и другим одновременно) и, наоборот, каж-
дая мини-спецификация должна соответствовать единственному процессу;
 ссылки к данным в мини-спецификациях должны соответствовать
объектам на диаграммах в словаре данных;
 по возможности, должна контролироваться семантика мини-
спецификации: например, если входные и/или выходные потоки связаны с хра-
нилищем данных, то это должно быть отражено в мини-спецификации (опера-
торами READ, GET, WRITE, PUT и т. п.).
Документатор проекта позволяет получать информацию о состоянии
проекта в виде различных отчетов. Отчеты могут строиться по нескольким при-
знакам, например по времени, автору, элементам диаграмм; по диаграмме или
проекту в целом.
Администратор проекта представляет собой инструменты, необходи-
мые для выполнения следующих административных функций:
 инициализация проекта;
 задание начальных параметров проекта;
 назначение и изменение прав доступа к элементам проекта;
 мониторинг выполнения проекта.
Сервис представляет собой набор системных утилит по обслуживанию
репозитория. Данные утилиты выполняют следующие функции:
 архивации данных;
 восстановления данных;
 создания нового репозитория.
Организация и поддержка репозитория
Основные функции средства организации и поддержки репозитория —
хранение, доступ, обновление, анализ и визуализация всей информации по про-
екту ИС. Содержимое репозитория включает не только информационные объ-
екты различных типов, но и отношения между их компонентами, а также пра-
вила использования или обработки этих компонент (рис. 11.4). Репозиторий
может хранить свыше 100 типов объектов, примерами которых являются струк-
турные диаграммы, определения экранов и меню, проекты отчетов, описания
данных, логика обработки, модели данных, модели организации, модели обра-
ботки, исходные коды, элементы данных и т. п.
Каждый информационный объект в репозитории описывается перечисле-
нием его свойств: идентификатор, имена-синонимы, тип, текстовое описание,
компоненты, файл-хранилище, область значений. Кроме того, хранятся все от-
ношения с другими объектами (например, все объекты, в которых данный объ-
ект используется; все перекрестные ссылки), правила формирования и редакти-
рования объекта, а также контрольная информация о времени порождения объ-

254
екта, времени его последнего обновления, кем и в каком проекте он был по-
рожден, номер версии, возможности обновления и т. п.

Рис. 11.4
Содержимое репозитория
На основе репозитория осуществляется интеграция CASE-средств и раз-
деление системной информации между разработчиками. При этом возможности
репозитория обеспечивают несколько уровней интеграции: общий пользова-
тельский интерфейс по всем средствам, передачу данных между средствами,
интеграцию этапов разработки через единую систему представлений фаз ЖЦ,
передачу данных и средств между аппаратурными платформами.
Репозиторий является базой для стандартизации документации по проек-
ту и контроля состоятельности проектных спецификаций. Все отчеты строятся
автоматически по репозиторию.
Важные функции управления и контроля проекта также реализуются на
основе репозитория. В частности, через репозиторий может осуществляться
контроль безопасности (ограничения доступа, привилегии доступа), контроль
версий, контроль изменений и др.

11.3. Классификация и выбор CASE-средств

Классификация CASE-средств
Рассматривая современные CASE-системы, следует остановиться на их
классификации. Будем классифицировать эти системы по следующим призна-
кам:
 по поддерживаемым методологиям проектирования: структурно-
ориентированные, объектно-ориентированные и комплексно-ориентированные
(набор методологий проектирования);
 по поддерживаемым графическим нотациям построения диаграмм: с
фиксированной нотацией, с отдельными нотациями и наиболее распространен-
ными нотациями;
 по степени интегрированности: tools (отдельные локальные сред-
ства), toolkit (набор неинтегрированных средств, охватывающих большинство

255
этапов разработки ЭИС) и workbench (полностью интегрированные средства,
связанные общей базой проектных данных — репозиторием);
 по типу и архитектуре вычислительной техники: ориентированные
на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориен-
тированные на глобальную вычислительную сеть (ГВС) и смешанного типа;
 по режиму коллективной разработки проекта: не поддерживающие
коллективную разработку, ориентированные на режим реального времени раз-
работки проекта, ориентированные на режим объединения подпроектов.
Кроме того, CASE-средства можно разделить на типы, категории и уровни.
Классификация по типам отражает функциональную ориентацию CASE-
средств в технологическом процессе.
Анализ и проектирование. Средства данной группы используются для
создания спецификаций системы и ее проектирования, они поддерживают ши-
роко известные методологии проектирования. К таким средствам относятся
CASE Аналитик (Эйтекс), The Developer (ASYST Technologies), POSE (Comput-
er Systems Advisers), ProKit*Workbench (McDonnell Douglas), Excelerator (Index
Technology), Design-Aid (Nastec), Design Machine (Optima), MicroStep (Meta Sys-
tems), vsDesigner (Visual Software), Analist\Designer (Yourdon), Design/IDEF
(Meta Software), BPWin (Logic Works), SELECT (Select Software Tools), System
Architect (Popkin Software & Systems), Westmount I-CASE Yourdon (Westmount
Technology&CADRE Technologies), CASE\4|0 (microTOOL GmbH). Их целью
является определение системных требований и свойств, которыми система
должна обладать, а также создание проекта системы, удовлетворяющей этим
требованиям и обладающей соответствующими свойствами. На выходе проду-
цируются спецификации компонент системы и интерфейсов, связывающих эти
компоненты, а также «калька» архитектуры системы и детальная «калька» про-
екта, включающая алгоритмы и определения структур данных.
Проектирование баз данных и файлов. Средства данной группы обеспе-
чивают логическое моделирование данных, автоматическое преобразование
моделей данных в Третью Нормальную Форму, автоматическую генерацию
схем БД и описаний форматов файлов на уровне программного кода: ERWin
(Logic Works), Chen Toolkit (Chen & Associates), S-Designor (SDP), Designer2000
(Oracle), Silverrun (Computer Systems Advisers).
Программирование. Средства этой группы поддерживают этапы програм-
мирования и тестирования, а также автоматическую кодогенерацию из специфи-
каций, получая полностью документированную выполняемую программу:
COBOL 2/Workbench (Mikro Focus), DECASE (DEC), NETRON/CAP (Netron),
APS (Sage Software). Помимо диаграммеров различного назначения и средств
поддержки работы с репозиторием, в эту группу средств включены и традицион-
ные генераторы кодов, анализаторы кодов (как в статике, так и в динамике), ге-
нераторы наборов тестов, анализаторы покрытия тестами, отладчики.
Сопровождение и реинжиниринг. К таким средствам относятся доку-
ментаторы, анализаторы программ, средства реструктурирования и реинжини-
ринга: Adpac CASE Tools (Adpac), Scan/COBOL SuperStructure (Computer Data
Systems), Inspector/Recoder (Language Nechnology). Их целью является коррек-
256
тировка, изменение, анализ, преобразование и реинжиниринг существующей
системы. Средства позволяют осуществлять поддержку всей системной доку-
ментации, включая коды, спецификации, наборы тестов; контролировать по-
крытие тестами для оценки полноты тестируемости; управлять функциониро-
ванием системы и т. п. Особый интерес представляют средства обеспечения
мобильности (в CASE они получили название средств миграции) и реинжини-
ринга. К средствам миграции относятся трансляторы, конверторы, макрогене-
раторы и др., позволяющие обеспечить перенос существующей системы в но-
вое операционное или аппаратурное окружение.
Средства реинжиниринга включают:
 статические анализаторы для продуцирования схем системы ПО из ее
кодов, оценки влияния модификаций (например, «эффект ряби» — внесение
изменений с целью исправления ошибок порождает новые ошибки);
 динамические анализаторы (обычно компиляторы и интерпретаторы с
встроенными отладочными возможностями);
 документаторы, позволяющие автоматически получать обновленную
документацию при изменении кода;
 редакторы кодов, автоматически изменяющие при редактировании, и
все предшествующие коду структуры (например, спецификации);
 средства доступа к спецификациям, их модификации и генерации но-
вого (модифицированного) кода;
 средства реверсного инжиниринга, транслирующие коды в специфи-
кации.
Окружение. Средства поддержки платформ для интеграции, создания и
придания товарного вида CASE-средствам: Multi/Cam (AGS Management
Systems), Design/OA (Meta Software).
Управление проектом. Средства, поддерживающие планирование, кон-
троль, руководство, взаимодействие, т. е. функции, необходимые в процессе
разработки и сопровождения проектов: Project Workbench (Applied Business
Technology).
Классификация по интегрированности определяет уровень интегрирован-
ности по выполняемым функциям и включает вспомогательные программы
(tools), пакеты разработчика (toolkit) и инструментальные средства (workbench).
Категория tools обозначает вспомогательный пакет, решающий небольшую ав-
тономную задачу, принадлежащую проблеме более широкого масштаба. Кате-
гория toolkit представляет совокупность интегрированных программных
средств, обеспечивающих помощь для одного из классов программных задач;
использует репозиторий для всей технической и управляющей информации о
проекте, концентрируясь при этом на поддержке, как правило, одной фазы или
одного этапа разработки ПО.
Категория workbench представляет собой интеграцию программных
средств, которые поддерживают системный анализ, проектирование и разра-
ботку ПО; используют репозиторий, содержащий всю техническую и управля-
ющую информацию о проекте; обеспечивают автоматическую передачу си-

257
стемной информации между разработчиками и этапами разработки; организуют
поддержку практически полного ЖЦ (от анализа требований и проектирования
ПО до получения документированной выполняемой программы). Workbench,
по сравнению с toolkit, обладает более высокой степенью интеграции выполня-
емых функций, большей самостоятельностью и автономностью использования,
а также наличием тесной связи с системными и техническими средствами аппа-
ратно-вычислительной среды, на которой workbench функционирует. По суще-
ству, workbench может рассматриваться как автоматизированная рабочая стан-
ция, используемая как инструментарий для автоматизации всех или отдельных
совокупностей работ по созданию ПО.
Критерии оценки и выбора CASE-средств
Стратегия выбора CASE-систем для конкретного применения зависит как
от целей и потребностей самого проекта, так и от квалификации вовлеченных в
процесс проектирования специалистов. В большинстве случаев одно средство
не может обеспечить все потребности проекта. Разработчики, как правило,
применяют набор средств. Например, одно средство наилучшим образом под-
ходит для анализа, а другое — для проектирования систем. В общем случае при
выборе CASE-системы необходимо учитывать различные критерии.
Критерии формируют базис для процессов оценки и выбора и могут при-
нимать различные формы:
 числовые меры в широком диапазоне значений, например, объем тре-
буемой памяти;
 числовые меры в ограниченном диапазоне значений, например, про-
стота освоения, выраженная в баллах от 1 до 5;
 двоичные меры (истина/ложь, да/нет), например, способность генера-
ции документации в формате Postscript;
 меры, которые могут принимать одно значение или более из конечных
множеств значений, например, платформы, для которых поддерживается
CASE-средство.
Типичный процесс оценки и/или выбора может включать набор критери-
ев различных типов.
Структура набора критериев приведена на рисунке 11.5. Каждый крите-
рий должен быть выбран и адаптирован экспертом с учетом особенностей кон-
кретного процесса. В большинстве случаев только некоторые из множества
описанных ниже критериев оказываются приемлемыми для использования, при
этом также добавляются дополнительные критерии. Выбор и уточнение набора
используемых критериев являются критическим шагом в процессе оценки
и/или выбора.
Функциональные характеристики
Данные критерии предназначены для определения функциональных ха-
рактеристик CASE-средства. Они, в свою очередь, подразделяются на ряд групп
и подгрупп.

258
 Рис. 11.5
Структура набора критериев
Среда функционирования
1. Проектная среда:
⎯ поддержка процессов жизненного цикла определяет набор процессов
и действий ЖЦ ПО, которые поддерживает CASE-средство. Примерами таких
процессов и действий являются анализ требований, проектирование, кодирова-
ние;
⎯ тестирование, оценка, сопровождение, обеспечение качества, управ-
ление конфигурацией и управление проектом, причем они зависят от принятой
пользователем модели ЖЦ;
⎯ область применения — система обработки транзакций, системы ре-
ального времени, информационные системы и, помимо прочего, системы с по-
вышенными требованиями к безопасности;
⎯ размер поддерживаемых приложений определяет ограничения на та-
кие величины, как количество строк кода, уровней вложенности, размер базы
данных, количество элементов данных, количество объектов конфигурационно-
го управления.

259
 2. ПО/технические средства:
 требуемые технические средства — оборудование, необходимое для
функционирования CASE-средства, включая тип процессора, объем оператив-
ной памяти и дисковой памяти;
 поддерживаемые технические средства — элементы оборудования,
которые могут использоваться CASE-средством, например, устройства ввода-
вывода;
 требуемое ПО — ПО, необходимое для функционирования CASE-
средства, включая операционные системы и графические оболочки;
 поддерживаемое ПО — программные продукты, которые могут ис-
пользоваться CASE-средством.
3. Технологическая среда:
 соответствие стандартам технологической среды, касающимся языка,
базы данных, репозитория, коммуникаций, графического интерфейса пользова-
теля, документации, разработки, управления конфигурацией, безопасности,
стандартов обмена информацией и интеграции по данным, по управлению и по
пользовательскому интерфейсу;
 совместимость с другими средствами — способность к взаимодей-
ствию с другими средствами, включая непосредственный обмен данными (при-
мерами таких средств являются текстовые процессоры и другие средства доку-
ментирования, базы данных и другие CASE-средства) и возможность преобра-
зования репозитория или его части в стандартный формат для обработки дру-
гими средствами;
 поддерживаемые методы — набор методов и методик, поддерживае-
мых CASE-средством. Примерами являются структурный или объектно-
ориентированный анализ и проектирование;
 поддерживаемые языки — все языки, используемые CASE-
средством: языки программирования (Ада, С, С++), языки баз данных и языки
запросов (DDL, SQL), графические языки (Postscript, HPGL), языки специфика-
ции проектных требований и интерфейсы операционных систем (языки управ-
ления заданиями).
Функции, ориентированные на фазы жизненного цикла ПО
1. Моделирование:
 построение диаграмм — возможность создания и редактирования диа-
грамм различных типов, представляющих интерес для пользователя;
 графический анализ — возможность анализа графических объектов, а
также хранения и представления проектной информации в графическом виде.
В большинстве случаев графические анализаторы интегрированы со средства-
ми построения диаграмм;
 ввод и редактирование спецификаций требований и проектных спе-
цификаций, к которым относятся описания функций, данных, интерфейсов,
структуры, качества, производительности, технических средств, затрат и гра-
фиков;

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

261
гут включать обычный программный код, схему базы данных, запросы, экра-
ны/меню;
 компиляция кода;
 конвертирование исходного кода — возможность преобразования ко-
да из одного языка в другой;
 анализ надежности — возможность количественно оценивать пара-
метры надежности ПО, такие как количество ошибок и др.;
 реверсный инжиниринг — возможность анализа существующих ис-
ходных кодов и формирования на их основе проектных спецификаций;
 реструктуризация исходного кода — возможность модификации фор-
мата и/или структуры существующего исходного кода;
 анализ исходного кода — определение размера кода, вычисление по-
казателей сложности, генерация перекрестных ссылок и проверка на соответ-
ствие стандартам;
 отладка — трассировка программ, выделение узких мест и наиболее
часто используемых фрагментов кода и т. д.
Реализация затрагивает функции, связанные с созданием исполняемых
элементов системы (программных кодов) или с модификацией существующей
системы. Многие из перечисленных критериев зависят от конкретных языков.
3. Тестирование:
 описание тестов — генерация тестовых данных, алгоритмов тестиро-
вания, требуемых результатов и т. д.;
 фиксация и построение действий оператора — возможность фикси-
ровать данные, вводимые оператором с помощью клавиатуры, мыши т. д., ре-
дактировать их и воспроизводить в тестовых примерах;
 автоматический запуск тестовых примеров;
 регрессионное тестирование — возможность повторения и модифи-
кации ранее выполненных тестов для определения различий в системе и/или
среде;
 автоматизированный анализ результатов тестирования — сравнение
ожидаемых и реальных результатов, сравнение файлов, статистический анализ
результатов и др.;
 анализ тестового покрытия — оснащенность средствами контроля
исходного кода и анализ тестового покрытия. Проверяются, в частности, ис-
полняемые и вызываемые (или нет) операторы, процедуры и переменные;
 анализ производительности — возможность анализа производитель-
ности программ. Анализируемые параметры производительности могут вклю-
чать степень использования ресурсов центрального процессора и памяти, коли-
чество обращений к определенным данным и/или сегментам кода, временные
характеристики и т. д.;
 анализ исключительных ситуаций в процессе тестирования;
 динамическое моделирование среды, в частности, возможность ав-
томатически генерировать моделируемые входные данные системы.

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

263
нируемых процедур, фиксация и запись результатов тестирования, генерация
отчетов и т. д.;
 управление качеством — ввод соответствующих данных, их анализ и
генерация отчетов;
 корректирующие действия — поддержка управления корректирую-
щими действиями, включая обработку сообщений о проблемных ситуациях.
Приведенные критерии определяют функции CASE-средств, охватываю-
щие всю совокупность процессов и стадий ЖЦ ПО. Поддержка всех этих функ-
ций осуществляется посредством репозитория.
Надежность:
 администрирование репозитория — контроль и обеспечение целост-
ности проектных данных;
 автоматическое резервирование (определяемое поставщиком или пла-
нируемое пользователем);
 безопасность — защита от несанкционированного доступа;
 обработка ошибок — обнаружение ошибок в работе системы, извеще-
ние пользователя, корректное завершение работы или сохранение состояния к
моменту прерывания;
 анализ отказов в критических приложениях.
Простота использования:
 удобство пользовательского интерфейса — удобство расположения и
представления часто используемых элементов экрана, способов ввода данных и др.;
 локализация (в соответствии с требованиями данной страны);
 простота освоения (трудовые и временные затраты на освоение
средств);
 адаптируемость к конкретным требованиям пользователя (различ-
ным алфавитам, режимам текстового и графического представления (слева
направо, сверху вниз), различным форматам даты, способам ввода-вывода
(экранным формам и форматам), изменениям в методологии (изменениям гра-
фических нотаций, правил, свойств и состава предопределенных объектов)
и др.;
 качество документации — полнота, понятность, удобочитаемость,
полезность и др.;
 доступность и качество учебных материалов (компьютерные учеб-
ные материалы, учебные пособия, курсы);
 требования к уровню знаний — квалификация и опыт, необходимые
для эффективного использования CASE-средств;
 простота работы с CASE-средством (как для начинающих, так и для
опытных пользователей);
 унифицированность пользовательского интерфейса (по отношению к
другим средствам, использующимся в данной организации);
 онлайновые подсказки (полнота и качество);

264
  качество диагностики — понятность и полезность диагностических
сообщений для пользователя;
 допустимое время реакции на действия пользователя (в зависимости
от среды);
 простота установки и обновления версий.
Эффективность:
 требования к оптимальному размеру внешней и оперативной памяти,
типу и производительности процессора, обеспечивающим приемлемый уровень
производительности;
 эффективность рабочей нагрузки — эффективность выполнения
CASE-средством своих функций в зависимости от интенсивности работы поль-
зователя (например, количество нажатий клавиш или кнопки мыши, требуемое
для выполнения определенных функций);
 производительность — время, затрачиваемое CASE-средством для
выполнения конкретных задач (например, время ответа на запрос, время анали-
за 10 тыс. строк кода). В некоторых случаях данные оценки производительно-
сти можно получить из внешних источников.
Сопровождаемость:
 уровень поддержки со стороны поставщика — скорость разрешения
проблем, поставки новых версий, обеспечения дополнительных возможностей;
 трассируемость обновлений — простота освоения отличий новых
версий от существующих;
 совместимость обновлений — совместимость новых версий с суще-
ствующими, включая, например, совместимость по входным или выходным
данным;
 сопровождаемость конечного продукта — простота внесения изме-
нений в ПО и документацию.
Переносимость:
 совместимость с версиями ОС — возможность работы в среде различ-
ных версий одной и той же ОС, простота модификации CASE-средства для ра-
боты с новыми версиями ОС;
 переносимость данных между различными версиями CASE-средства;
 соответствие стандартам переносимости, включающим документа-
цию, коммуникации и пользовательский интерфейс, оконный интерфейс, языки
программирования, языки запросов и др.
Общие критерии:
 затраты на CASE-средство, включающие стоимость приобретения,
установки, начального сопровождения и обучения. Следует учитывать цену для
всех необходимых конфигураций, включая единственную копию, много копий,
локальную лицензию, лицензию для предприятия, сетевую лицензию;

265
  оценочный эффект от внедрения CASE-средства — уровень продук-
тивности, качества и т. д. Такая оценка может потребовать экономического
анализа;
 профиль дистрибьютора — общие показатели возможностей дистри-
бьютора. Профиль дистрибьютора может включать масштаб его организации,
стаж в бизнесе, финансовое положение, список любых дополнительных про-
дуктов, деловые связи (в частности, с другими дистрибьюторами средства),
планируемую стратегию развития;
 сертификация поставщика — сертификаты, полученные от специали-
зированных организаций в области создания ПО. Например, SEI (Software
Engineering Institute) и ISO (International Organization for Standardization), удо-
стоверяющие, что квалификация поставщика в области создания и сопровожде-
ния ПО удовлетворяет некоторым минимально необходимым или вполне опре-
деленным требованиям. Сертификация может быть неформальной, например,
на основе анализа качества работы поставщика;
 лицензионная политика — доступные возможности лицензирования,
право копирования (носителей и документации), любые ограничения и/или
штрафные санкции за вторичное использование (подразумевается продажа
пользователем CASE-средства продуктов, в состав которых входят некоторые
компоненты CASE-средства, использовавшиеся при разработке продуктов);
 экспортные ограничения;
 профиль продукта — общая информация о продукте, включая срок его
существования, количество проданных копий, система отчетов о проблемах,
программу развития продукта, совокупность применений, наличие ошибок и др.;
 поддержка поставщика — доступность, реактивность и качество
услуг, предоставляемых поставщиком для пользователей CASE-средств. Такие
услуги могут включать телефонную «горячую линию», местную техническую
поддержку, поддержку в самой организации;
 доступность и качество обучения (обучение может проводиться на
площади поставщика, пользователя или где-либо в другом месте);
 адаптация, требуемая для внедрения CASE-средств в организации
пользователя. Примером может быть определение способа использования цен-
трализованного CASE-средства с единой, общей БД в распределенной среде.

11.4. CASE-средства Platinum Technology

Эти средства ERWin и BPWin были разработаны фирмой Logic Works.
После слияния в 1998 г. Logic Works с Platinum technology они выпускаются
под логотипом Platinum technology.
Для проведения анализа и реорганизации бизнес-процессов Platinum
technology предлагает CASE-средство верхнего уровня BPWin, поддерживаю-
щее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram)
и DFD (DataFlow Diagram). Функциональная модель предназначена для описа-
ния существующих бизнес-процессов на предприятии (так называемая модель

266
AS-SI) и идеального положения вещей — того, к чему нужно стремиться (мо-
дель TO-BE).
Методология IDEF0 предписывает построение иерархической системы
диаграмм — единичных описаний фрагментов системы. Сначала проводится
описание системы в целом и ее взаимодействие с окружающим миром (кон-
текстная диаграмма), после чего проводится функциональная декомпозиция —
система разбивается на подсистемы и каждая подсистема описывается отдельно
(диаграммы декомпозиции).
Затем каждая подсистема разбивается на более мелкие и так далее до до-
стижения нужной степени подробности. После каждого сеанса декомпозиции
проводится сеанс экспертизы: каждая диаграмма проверяется экспертами пред-
метной области, представителями заказчика, людьми, непосредственно участ-
вующими в бизнес-процессе. Такая технология создания модели позволяет по-
строить модель, адекватную предметной области на всех уровнях абстрагиро-
вания.
Если в процессе моделирования нужно осветить специфические стороны
технологии предприятия, BPWin позволяет переключиться на любой ветви мо-
дели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD
включает такие понятия, как внешняя ссылка и хранилище данных, что делает
ее более удобной (по сравнению с IDEF0) для моделирования документооборо-
та. Методология IDEF3 включает элемент «перекресток», что позволяет опи-
сать логику взаимодействия компонентов системы.
На основе модели BPWin можно построить модель данных. Для построе-
ния модели данных Platinum technology предлагает мощный и удобный инстру-
мент — ERWin. Хотя процесс преобразования модели BPWin в модель данных
плохо формализуется и поэтому полностью не автоматизирован, Platinum
technology предлагает удобный инструмент для облегчения построения модели
данных на основе функциональной модели — механизм двунаправленной связи
BPWin — ERWin (стрелка 1 на рис. 11.6).
ERWin имеет два уровня представления модели — логический и физиче-
ский. На логическом уровне данные не связаны с конкретной СУБД, поэтому
могут быть наглядно представлены даже для неспециалистов. Физический уро-
вень данных — это, по существу, отображение системного каталога, который
зависит от конкретной реализации СУБД. ERWin позволяет проводить процес-
сы прямого и обратного проектирования БД (стрелка 2 на рис. 11.6). Это озна-
чает, что по модели данных можно сгенерировать схему БД или автоматически
создать модель на основе информации системного каталога.
Кроме того, ERWin позволяет выравнивать модель и содержимое систем-
ного каталога после редактирования того либо другого. ERWin интегрируется с
популярными средствами разработки клиентской части — PowerBuilder, Visual
Basic, Delphi (стрелка 3 на рис. 11.6), что позволяет автоматически генериро-
вать код приложения, который полностью готов к компиляции и выполнению
(стрелка 4 на рис. 11.6).

267
 Рис. 11.6
Общая схема взаимодействия инструментальных средств Platinum technology
и Rational Rose
Для разных сред разработки реализована различная техника кодогенера-
ции. Код для PowerBuilder генерируется непосредственно в среде ERWin, код
для Visual Basic — с помощью add-in компонентов и библиотек, подключаемых
в проект Visual Basic. ERWin не поддерживает непосредственно кодогенерацию
для Delphi. Код клиентского приложения для Delphi на основе модели данных
ERWin можно сгенерировать с помощью MetaBASE — продукта фирмы gs-soft
(http://www.gs-soft.com).
BPWin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая
их которых решает свои специфические задачи. В BPWin возможно построение
смешанных моделей, т. е. модель может содержать одновременно как диаграм-
мы IDEF0, так и IDEF3 и DFD.

Рис. 11.7
Контекстная диаграмма IDEF0
268
 Вход (Input) — материал или информация, которые используются или
преобразуются работой для получения результата (выхода). Допускается, что
работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит
к определенной стороне прямоугольника, изображающего работу, или выходит
из нее. Стрелка входа рисуется как входящая в левую грань работы. При описа-
нии технологических процессов (для этого и был придуман IDEF0) не возника-
ет проблем определения входов. Действительно, «Сырье» на рисунке 11.8 —
это нечто, что перерабатывается в процессе «Изготовление изделия» для полу-
чения результата. При моделировании ИС, когда стрелками являются не физи-
ческие объекты, а данные, не все так очевидно.
Например, при «Приеме пациента» карта пациента может быть и на входе
и на выходе, между тем качество этих данных меняется. Другими словами, в
нашем примере для того, чтобы оправдать свое назначение, стрелки входа и
выхода должны быть точно определены с тем, чтобы указать на то, что данные
действительно были переработаны (например, на выходе — «Заполненная кар-
та пациента»).
Очень часто сложно определить, являются ли данные входом или управ-
лением. В этом случае подсказкой может служить то, перерабатывают-
ся/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего,
это вход, если нет — управление.

Рис. 11.8
Диаграмма процесса изготовления изделия
Управление (Control) — правила, стратегии, процедуры или стандарты,
которыми руководствуется работа. Каждая работа должна иметь хотя бы одну
стрелку управления. Стрелка управления рисуется как входящая в верхнюю
грань работы. На рисунке 11.8 стрелки «Задание» и «Чертеж» — управление
для работы «Изготовление изделия». Управление влияет на работу, но не пре-
образуется работой. Если цель работы — изменить процедуру или стратегию,
то такая процедура или стратегия будет для работы входом. В случае возникно-
вения неопределенности в статусе стрелки (управление или вход) рекомендует-
ся рисовать стрелку управления.
Выход (Output) — материал или информация, которые производятся ра-
ботой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа баз
результата не имеет смысла и не должна моделироваться. Стрелка выхода рису-
269
ется как исходящая из правой грани работы. На рисунке стрелка «Готовое изде-
лие» является выходом для работы «Изготовление изделия».
Механизм (Mechanism) — ресурсы, которые выполняют работу, напри-
мер, персонал предприятия, станки, устройства и т. д. На рисунке 11.8 стрелка
«Персонал предприятия» является механизмом для работы «Изготовление из-
делия». По усмотрению аналитика стрелки механизма могут не изображаться в
модели.
Вызов (Cаll) — специальная стрелка, указывающая на другую модель ра-
боты. Стрелка вызова рисуется как исходящая из нижней грани работы. Стрел-
ка вызова используется для указания того, что некоторая работа выполняется за
пределами моделируемой системы. В BPWin стрелки вызова используются в
механизме слияния и разделения моделей.
Граничные стрелки. Стрелки на контекстной диаграмме служат для опи-
сания взаимодействия системы с окружающим миром. Они могут начинаться у
границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки
называются граничными.
Диаграммы дерева узлов и FE0
Диаграмма дерева узлов показывает иерархию работ в модели и позволя-
ет рассмотреть всю модель целиком, но не показывает взаимосвязи между ра-
ботами (стрелки). Процесс создания модели работ является итерационным, сле-
довательно, работы могут менять свое расположение в дереве узлов многократ-
но. Чтобы не запутаться и проверить способ декомпозиции, следует после каж-
дого изменения создавать диаграмму дерева узлов. Впрочем, BPWin имеет
мощный инструмент навигации по модели Model Explorer, который позволяет
представить иерархию работ и диаграмм в удобном и компактном виде, однако
этот инструмент не является составляющим стандарта IDEF.
Для создания диаграммы дерева узлов следует выбрать в меню пункт
Insert/Node Tree. Возникает диалог формирования диаграммы дерева узлов
Node Tree Definition.
Дополнение созданной модели процессов диаграмм DFD
Диаграммы потоков данных используются для описания документообо-
рота и обработки информации. Подобно IDEF0, DFD представляет модельную
систему как сеть связанных между собой работ. Их можно использовать как
дополнение к модели IDEF0 для более наглядного отображения текущих опе-
раций документооборота в корпоративных системах обработки информации.
DFD описывает:
 функции обработки информации (работы);
 документы (стрелки, arrow), объекты, сотрудников или отделы, кото-
рые участвуют в обработке информации;
 внешние ссылки, которые обеспечивают интерфейс с внешними объ-
ектами, находящимися за границами моделируемой системы;
 таблицы для хранения документов (хранилище данных, dataStore).

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

Рис. 11.9
Пример диаграммы DFD
В отличие от IDEF0, где система рассматривается как взаимосвязанные
работы, DFD рассматривает систему как совокупность предметов. Контекстная
диаграмма часто включает работы и внешние ссылки. Работы обычно именуют-
ся по названию системы, например, «Система обработки информации». Вклю-
чение внешних ссылок в контекстную диаграмму не отменяет требования мето-
дологии четко определить цель, область и единую точку зрения на моделируе-
мую систему.
Работы. В DFD работы представляют собой функции системы, преобра-
зующие входы и выходы. Хотя работы изображаются прямоугольниками со
скругленными углами, смысл их совпадает со смыслом работ IDEF0.
Внешние сущности. Внешние сущности изображают входы в систему
и/или выходы из системы. Внешние сущности изображаются в виде прямо-
угольника с тенью и обычно располагаются по краям диаграммы. Одна внеш-
няя сущность может быть использована многократно на одной или нескольких
диаграммах. Обычно такой прием используется, чтобы не рисовать слишком
длинных и запутанных стрелок.
Стрелки (потоки данных). Стрелки описывают движение объектов из
одной части системы в другую. Поскольку в DFD каждая сторона работы не
имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из
любой грани прямоугольника работы. В DFD также применяются двунаправ-
ленные стрелки для описания диалогового типа «команда-ответ» между рабо-
271
тами, между работой и внешней сущностью и между внешними сущностями
(рис. 11.10).

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

Рис. 11.11
Хранилища данных
Слияние и разветвление стрелок. В DFD стрелки могут сливаться и раз-
ветвляться, что позволяет описать декомпозицию стрелок. Каждый новый сег-
мент сливающейся или разветвляющейся стрелки может иметь собственное
имя.
Построение диаграмм DFD. Диаграммы DFD могут быть построены с
использованием традиционного структурного анализа, подобно тому, как стро-
ятся диаграммы IDEF0. Сначала строится физическая модель, отображающая
текущее состояние дел. Затем эта модель преобразуется в логическую модель,
которая отображает требования к существующей системе. После этого строится
модель, отображающая требования к будущей системе. И, наконец, строится
физическая модель, на основе которой должна быть построена новая система.
Затем модель окружения (environment model) описывает систему как объ-
ект, взаимодействующий с событиями из внешних сущностей. Модель окруже-
ния обычно содержит описание цели системы, одну контекстную диаграмму и
список событий. Контекстная диаграмма содержит один прямоугольник рабо-
ты, изображающий систему в целом, и внешние сущности, с которыми система
взаимодействует.
Наконец, модель поведения показывает, как система обрабатывает собы-
тия. Эта модель состоит из одной диаграммы, в которой каждый прямоугольник
изображает каждое событие из модели окружения. Хранилища могут быть до-
бавлены для моделирования данных, которые необходимо запоминать между
событиями. Потоки добавляются для связи с другими элементами, и диаграмма
проверяется с точки зрения соответствия модели окружения.

272
 Полученные диаграммы могут быть преобразованы с целью более
наглядного представления системы, в частности, работы на диаграммах могут
быть декомпозированы.
Нумерация объектов. В DFD номер каждой работы может включать
префикс, номер родительской работы (А) и номер объекта. Номер объекта —
это уникальный номер работы на диаграмме. Например, работа может иметь
номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущно-
сти независимо от их расположения на диаграмме. Каждое хранилище данных
имеет префикс О и уникальный номер, например О5. Каждая сущность имеет
префикс Е и уникальный номер, например Е5.

11.5. CASE-средства Rational Rose

Rational Rose — семейство объектно-ориентированных CASE-средств
фирмы Rational Software Corporation, предназначено для автоматизации процес-
сов анализа и проектирования ПО, а также для генерации кодов на различных
языках и выпуска проектной документации. Rational Rose использует метод
объектно-ориентированного анализа и проектирования, основанный на языке
UML. Текущая версия Rational Rose реализует генерацию кодов программ для
С++, Visual Basic, Java, PowerBuilder, COBRA Interface Definition Language
(IDL), генерацию описаний баз данных для ANSI SQL, Oracle, MS SQL Server,
IBM DB2, Sybase, а также позволяет разрабатывать проектную документацию в
виде диаграмм и спецификаций. Кроме того, Rational Rose содержит средства
реверсного инжиниринга программ и баз данных, обеспечивающие повторное
использование программных компонентов в новых проектах.
Структура и функции. В основе работы Rational Rose лежит построение
диаграмм и спецификаций UML, определяющих архитектуру системы, ее ста-
тические и динамические аспекты. В составе Rational Rose можно выделить
шесть основных структурных компонентов: репозиторий, графический интер-
фейс пользователя, средства просмотра проекта (браузер), средства контроля
проекта, средства обработки статистики и генератор документов. К ним добав-
ляются генератор кодов (индивидуальный для каждого языка) и анализатор для
С++, обеспечивающий реверсный инжиниринг.
Репозиторий представляет собой базу данных проекта. Браузер обеспечи-
вает «навигацию» по проекту, в том числе перемещение по иерархиям классов
и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства
контроля и сбора статистики дают возможность находить и устранять ошибки
по мере развития проекта, а не после завершения его описания. Генератор отче-
тов формирует тексты выходных документов на основе содержащейся в репо-
зитории информации.
Средства автоматической генерации кодов программ на языке С++, ис-
пользуя информацию, содержащуюся в диаграммах классов и компонентов,
формируют файлы заголовков и файлы описаний объектов. Создаваемый таким
образом «скелет» программы может быть уточнен путем прямого программи-
рования на языке С++.

273
 Одно из неоспоримых преимуществ Rational Rose — обратное проектиро-
вание, поскольку разработчику и проектировщику важно увидеть перед изме-
нениями уже работающую систему в нормальном графическом представлении.
Как правило, визуально-графический ряд оказывает куда как большее воздей-
ствие, нежели перелистывание технических заданий и программных текстов.
Тем более что проект, подвергшийся обратному проектированию, может быть
доработан и вновь сгенерирован (а впоследствии и скомпилирован). Rational
Rose предоставляет для этого все необходимые средства.
Для осуществления обратного проектирования в Rational Rose преду-
смотрен мощный модуль — Analyze, чье основное предназначение, вытекаю-
щее из названия, — анализ программ, написанных на С и С++. Данный модуль
способен проанализировать имеющийся файл на одном из вышеупомянутых
языков и преобразовать его в визуальную модель, присвоив выходному файл
расширение mdl. Далее файл можно спокойно открыть для модификации из
Rational Rose уже в визуальном режиме.
Analyze представляет собой отдельный программный файл, вызываемый
как из самой системы, так и обычным способом. Модуль входит не во все по-
ставки Rational Rose, а только в Enterprise, Professional и RealTime. В поставку
Data Modeler данный модуль не входит, поскольку специфика поставки не
предусматривает генерации кода и обратного проектирования.
В результате разработки проекта с помощью CASE-средства Rational Rose
формируются следующие документы:
 диаграммы UML, в совокупности представляющие собой модель раз-
рабатываемой программной системы;
 спецификации классов, объектов, атрибутов и операций;
 заготовки текстовых программ.
Тексты программ являются заготовками для последующей работы про-
граммистов. Состав информации, включаемой в программные файлы, опреде-
ляется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем
эти исходные тексты развиваются программистами в полноценные программы.
Работа в среде Rational Rose
Элементы экрана интерфейса Rose — это браузер, окно документации,
панели инструментов, окно диаграммы и журнал. Их назначение заключается в
следующем:
 браузер (browse) используется для быстрой навигации по модели;
 окно документации (documentation window) применяется для работы с
текстовым описанием элементов модели;
 панели инструментов (toolbars) применяются для быстрого доступа к
наиболее распространенным командам;
 окно диаграммы (diagram window) используется для просмотра и ре-
дактирования одной или нескольких диаграмм UML;
 журнал (log) применяется для просмотра ошибок и отчетов о выпол-
нении различных команд.

274
 На рисунке 11.12 показаны различные части интерфейса Rose.

Рис. 11.12
Части интерфейса Rose
Браузер — это иерархическая структура, позволяющая осуществлять
навигацию по модели. Все, что добавляется к ней, — действующие лица, вари-
анты использования, классы, компоненты — будет показано в окне браузера.
С помощью браузера можно:
 добавлять к модели элементы;
 просматривать существующие элементы модели;
 просматривать существующие связи между элементами модели;
 перемещать элементы модели;
 переименовывать эти элементы;
 добавлять элементы модели к диаграмме;
 связывать элемент с файлом или адресом Интернета;
 группировать элементы в пакеты;
 работать с детализированной спецификацией элемента;
 открывать диаграмму.
Браузер поддерживает четыре представления (view): представление вари-
антов использования, компонентов, размещения и логическое представление.
Все они и содержащиеся в них элементы модели описаны ниже.
Организация браузера представляет собой древовидную структуру. Каж-
дый элемент модели может содержать другие элементы, находящиеся ниже его
в иерархии. Знак «–» около элемента означает, что его ветвь полностью рас-
крыта. Знак «+» — что его ветвь свернута.

275
 Окно документации. С его помощью можно документировать элементы
модели Rose. Например, можно сделать краткое описание каждого действую-
щего лица. При документации класса все, что будет написано в окне докумен-
тации, появится затем как комментарий в сгенерированном коде, что избавляет
от необходимости впоследствии вносить эти комментарии вручную. Докумен-
тация будет выводиться в отчетах, создаваемых среде Rose.
Панели инструментов Rose обеспечивают быстрый доступ к наиболее
распространенным командам. В этой среде существуют два типа панелей ин-
струментов: стандартная панель и панель диаграммы. Стандартная панель вид-
на всегда, ее кнопки соответствуют командам, которые могут использоваться
для работы с любой диаграммой. Панель диаграммы своя для каждого типа
диаграмм UML.
Журнал. По мере работы над вашей моделью определенная информация
будет направляться в окно журнала. Например, туда помещаются сообщения об
ошибках, возникающих при генерации кода. Не существует способа закрыть
журнал совсем, но его окно может быть минимизировано.
Четыре представления модели Rose
В модели Rose поддерживаются четыре представления — это представле-
ние вариантов использования, логическое представление, представление ком-
понентов и представление размещения. Каждое из них предназначено для своих
целей и для соответствующей аудитории.
Представление вариантов использования содержит всех действующих
лиц, все варианты использования и их диаграммы для конкретной системы. Оно
может также содержать некоторые диаграммы последовательности и коопера-
тивные диаграммы. На рисунке 11.13 изображено представление вариантов ис-
пользования в браузере Rose.

Рис. 11.13
Представление вариантов использования

276
 Представление вариантов использования содержит:
 действующих лиц;
 варианты использования;
 документацию по вариантам использования, детализирующую проис-
ходящие в них процессы (потоки событий), включая обработку ошибок. Эта
пиктограмма соответствует внешнему файлу, прикрепленному к модели Rose.
Вид пиктограммы зависит от приложения, используемого для документирова-
ния потока событий;
 диаграммы вариантов использования. Обычно у системы бывает не-
сколько таких диаграмм, каждая из которых показывает подмножество дей-
ствующих лиц и/или вариантов использования;
 пакеты, являющиеся группами вариантов использования и/или дей-
ствующих лиц.
Логическое представление (рис. 11.14) концентрируется на том, как си-
стема будет реализовывать поведение, описанное в вариантах использования.
Оно дает подробную картину составных частей системы и описывает взаимо-
действие этих частей. Логическое представление включает, помимо прочего,
конкретные требуемые классы, диаграммы классов и диаграммы состояний.
С их помощью конструируется детальный проект создаваемой системы.

Рис. 11.14
Логическое представление системы
Логическое представление содержит:
 классы;
 диаграммы классов. Как правило, для описания системы используется
несколько диаграмм классов, каждая из которых отображает некоторое под-
множество всех классов системы;
277
  диаграммы взаимодействия, применяемые для отображения объектов,
участвующих в одном потоке событий варианта использования;
 диаграммы состояний;
 пакеты, являющиеся группами взаимосвязанных классов.
Представление компонентов содержит:
 компоненты, являющиеся физическими модулями кода;
 диаграммы компонентов;
 пакеты, являющиеся группами связанных компонентов.
Представление размещения — это последнее представление Rose. Оно
соответствует физическому размещению системы, которое может отличаться от
ее логической структуры.
В представление размещения входят:
 процессы, являющиеся потоками (threads), исполняемыми в отве-
денной для них области памяти;
 процессы, включающие любые компьютеры, способные обрабаты-
вать данные. Любой процесс выполняется на одном или нескольких процессо-
рах;
 устройства, т. е. любая аппаратура, не способная обрабатывать дан-
ные (например, терминалы ввода-вывода и принтеры);
 диаграммы размещения.
Параметры настройки отображения (изображение атрибутов
и операций на диаграммах классов)
В Rose имеется возможность настроить диаграммы классов так, чтобы:
 показывать все атрибуты и операции;
 скрыть операции;
 скрыть атрибуты;
 показывать только некоторые атрибуты или операции;
 показывать операции вместе с их полными сигнатурами или только
их именами;
 показывать или не показывать видимость атрибутов и операций;
 показывать или не показывать стереотипы атрибутов и операций.

278
 ТЕМА 12. МЕТОДЫ АВТОМАТИЗАЦИИ
ПРОЕКТИРОВАНИЯ КИС
Мы рассмотрели CASE-технологии проектирования. Но это только один из
подходов к проектированию ЭИС. Существуют и другие подходы. Часть из них
мы рассматривали в предыдущем курсе, некоторые вы изучали на практике.
Классификация систем автоматизации проектирования ЭИС представлена
на рисунке 12.1.

Рис. 12.1
Классы систем автоматизации проектирования ЭИС
К CASE-технологиям относятся рассмотренные ранее технологии IDEF,
Platinum Plus и Rational Rose. Эти технологии позволяют проектировать систе-
мы и поддерживать их весь жизненный цикл. Использование этих технологий
ориентировано на профессионально обученных специалистов с подключением
на разных этапах и в разной степени специалистов клиента.
Настраиваемые системы — это готовый программный продукт, кото-
рый имеет широкий спектр настроек для учета специфики конкретного клиента.
При этом интерфейс программы и другие элементы системы не изменяются.
К системам данного типа относятся «Парус», «Галактика», 1С, КИС УЗ. Из за-
рубежных — R/3 (SAP AG), Oracle Corporation (Oracle Application) и Baan Com-
pany (Baan IV).
Системы — «трансформеры», или конструкторы, приведены в табли-
це 12.1.
Таблица 12.1
Примеры систем «Трансформеров»
Фирма-разработчик
Система-конструктор
или поставщик)
«1С» (www.1c.ru) «1С: Предприятие»
«Цефей» (www.cefey.ru) «Эталон»
«Интел Групп» (www.tekton.ru) «Тектон»
«Алеф Консалтинг & Софт» (www.alef.ru) «Алеф»
«ТБ Софт» (www.tbsoft.ru) «ТБ: Корпорация»
Columbus IT Partner (www.columbus.ru) (условно) Navision Axapta
Рассмотрим теперь некоторые особенности систем второго и третьего типа.

279
 12.1. Настраиваемые системы
К ним относятся «Галактика», «Парус», «1С» и ряд других.
Система «Парус»
Комплексная система «Парус» обеспечивает автоматизацию четырех ос-
новных бизнес-направлений (бизнес-сфер) финансово-хозяйственной деятель-
ности предприятия: управления финансами, логистики, управления производ-
ством, управления персоналом, а также страхования.

Рис. 12.2
Архитектура системы «Парус»
Для каждого из направлений на схеме указаны соответствующие прило-
жения системы. В состав системы входит также приложение «Клиенты», не
указанное на рисунке.
Система «Парус» полностью поддерживает классическую модель управ-
ления предприятием и на макроуровне характеризуется обеспечением следую-
щих факторов бизнес-логики управления:
 финансовое и материальное планирование ресурсов предприятия с
перспективным развитием до поддержки календарного планирования. Каче-
280
ственное решение этой задачи определяет основы ритмичной и согласованной
работы всех подразделений предприятия;
 четкая фиксация всех фактов финансово-хозяйственной деятельности,
происходящих в процессе функционирования предприятия;
 план-факт-анализ исполнения планов с возможностью детализации
обнаруженных отклонений до первичных документов, объясняющих их причи-
ну, с целью облегчения принятия управленческого решения;
 контроль и управление показателями эффективности деятельности
предприятия.
Конкретная комплектация системы «Парус» зависит от потребностей.
Например, для автоматизации корпоративной структуры обобщенная функцио-
нальная схема системы может выглядеть следующим образом (рис. 12.3).

Рис. 12.3
Пример функциональной схемы «Парус»
Для единственной локально размещенной организации (рис. 12.4).

281
 Рис. 12.4
Пример функциональной схемы «Парус» для локального размещения

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

282
 В основу корпоративной информационной системы «Парус» заложены
следующие базовые принципы.
Архитектура «клиент-сервер»
Важнейшим параметром крупной информационной системы является
быстродействие при значительном количестве пользователей, а также надеж-
ность, масштабируемость и безопасность. Все это обеспечивает архитектура
«клиент-сервер». Такая архитектура позволяет оптимально распределить рабо-
ту между клиентскими и серверной частями системы: теперь приложение, ра-
ботающее на рабочей станции, не читает записи базы данных «напрямую», а
посылает запросы на сервер, где они принимаются и последовательно отраба-
тываются специальными программами. В результате на рабочую станцию по-
ступают только обработанные данные, что радикально сокращает информаци-
онные потоки в ЛВС.
Масштабируемость
Масштабируемость решений системы «Парус» базируется:
 на многоплатформенности наших технологий, что предполагает оп-
тимальный подбор используемого программного обеспечения в зависимости от
конкретной ситуации и допускает, наряду с достижением целей построения
корпоративной системы управления, применение на отдельных автоматизируе-
мых участках относительно дешевых и легко сопровождаемых решений на
СУБД FoxPro или Btrieve, сопрягаемых с информационным ядром системы, ре-
ализованным на СУБД Oracle;
 на принципе построения продуктов системы «Парус» в единую пре-
емственную линию. Так, начав с относительно простой и дешевой системы 7-й
версии, использующей СУБД FoxPro, вы сможете впоследствии перейти на бо-
лее мощную систему управления «Парус» на базе Oracle.
Модульность
Система «Парус» является модульной. Многие ее компоненты успешно
функционируют автономно. Однако такая работа может быть более или менее
оправдана только для некрупных фирм. Для больших предприятий целесооб-
разнее приобретать сразу пакет приложений. В любом случае вы можете начи-
нать с минимальных комплектаций, добавляя отдельные компоненты системы
по мере надобности и оптимально по вашим финансовым возможностям.
Интеграция с Web-технологиями
ПАРУС-ON-LINE — новое решение, объединяющее учетные и управлен-
ческие возможности КИС ПАРУС с коммуникационными возможностями Web-
технологий, позволит нашим клиентам по-новому взглянуть на свой бизнес.
В основе ПАРУС-ON-LINE лежит трехуровневая схема, включающая
следующие компоненты:
 корпоративный сервер управления данными и соответствующими ме-
тодами их обработки;
 корпоративный сервер приложений (Web-сервер), отвечающий за вза-
имодействие с сервером управления данными и обеспечивающий подготовку
требуемой информации для визуализации;

283
  универсальная программа просмотра содержимого web-узлов (web-
браузер).
На сервере управления данными хранится корпоративная база данных и
бизнес-логика, реализованная в КИС ПАРУС.
На сервере приложений хранятся ASP-сценарии (Active Server Pages),
позволяющие отображать в html-формате данные из корпоративной базы дан-
ных и заносить в эту базу информацию, введенную пользователями через web-
интерфейс.
Благодаря специализированным функциям модуля «Администратор»,
входящего в состав КИС ПАРУС, пользователь получает возможность интерак-
тивной настройки web-интерфейсов для любого раздела системы определять
состав, названия и порядок следования отображаемых полей, указывать обяза-
тельные для заполнения поля, значения по умолчанию и т. п. Генерация web-
интерфейсов выполняется автоматически на основании пользовательских
настроек и asp-сценариев.
Открытость
Открытость системы «Парус» обеспечивается следующими факторами.
Вместе с системой может поставляться описание структур баз данных,
что позволяет формировать самые разнообразные отчеты на базе шаблонов,
разрабатываемых вами при помощи генератора отчетов Seagate Crystal
Reports — как при работе с системой, так и в среде самого генератора.
При необходимости в поставку системы могут входить информационные
модели IDEF и даже исходные тексты программного продукта. Эти меры при-
званы облегчить специалистам вашего предприятия развитие и адаптацию си-
стемы своими силами.
Возможность использования открытых API-интерфейсов позволяет инте-
грировать систему с программами, созданными силами специалистов вашего
предприятия.
Структура записи (в частности, записи о документе), регистрируемой в
системе, может быть дополнена произвольным количеством характеристик, тип
и назначение которых определяется самим пользователем. Благодаря этому вы
сможете проводить отбор и обобщение информации на основании характери-
стик, учитывающих ваши специфические требования.
Документооборот
Документооборот в системе основан на следующих принципах:
 по отношению к зарегистрированному в системе документу может
быть предпринят ряд действий, которые составляют этапы документооборота.
Результатом выполнения одного такого этапа может быть модификация данных
самого документа, снабжение его дополнительной информацией, регистрация
других документов и объектов учета системы (например, хозяйственных опера-
ций бухгалтерского учета);
 однажды выполненный этап документооборота можно отменить, т. е.
удалить из базы данных все следы его выполнения, в частности, снять с самого
документа отметку о выполнении этапа;

284
  возможность выполнения и отмены каждого этапа можно поставить
в зависимость от состояния других этапов (выполнен или нет) для этого же до-
кумента. Право выполнять этап может предоставляться ограниченному кругу
пользователей;
 для каждого документа система ведет «Журнал документооборота»,
куда автоматически записывает всю историю: кто, когда и с какими особенно-
стями проводил этапы. Для каждого документа можно оперативно просмотреть
список «родительских» и «дочерних» документов.
Защита данных
В такой ответственной сфере, как финансово-хозяйственная деятельность,
велика опасность как злоупотреблений, так и неумышленной порчи данных.
И эта опасность особенно актуальна, когда в одной компьютерной сети с одной
базой данных одновременно работает много людей. Поэтому в системе «Парус»
большое внимание уделено вопросу разграничения прав пользователей. Каж-
дому сотруднику могут быть назначены индивидуальные права доступа как к
разделам информации, так и к функциям системы.
Так, оператор, занимающийся вводом первичных документов, не сможет
получить доступ к обобщенной информации о деятельности фирмы. Сотрудни-
ки одного подразделения будут работать только со своими документами, не
имея доступа к документам других подразделений, и т. д. И только администра-
тор системы может делать все, в том числе распределять права между пользо-
вателями и отслеживать действия, произведенные ими.
Система «Галактика»
Корпорация «Галактика» предлагает современные информационные тех-
нологии для автоматизации управления предприятием. Продукты корпорации
«Галактика» могут быть применены на предприятиях различных отраслей и
масштабов деятельности.
Таблица 12.2
Перечень подсистем
Решаемая задача Продукт
Управление производством Система «Галактика»
(Контур управления производством)
Управление финансами Система «Галактика»
(Контур управления финансами)
Управление персоналом Система «Галактика»
(Контур управления персоналом)
Логистика Система «Галактика»
(Контур логистики)
Поиск и анализ неструктурированной ин- Поисково-аналитическая система
формации «Галактика-ZOOM»
Информационная Информационная система
поддержка руководителя руководителя
Продукты корпорации могут быть адаптированы для предприятия любой
отрасли.

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

Рис. 12.6
Структура типового предприятия и функциональные элементы системы «Галактика»

286
 Таблица 12.3
Основные функциональные элементы системы «Галактика»
Название Состав Автоматизирует
Контур управления Модуль «Планирование производства» Производство (цеха),
производством Модуль «Корпоративное планово-диспетчерский
планирование» отдел;
Модуль «Учет в производстве» планово-экономический
Модуль «Управление заказами» отдел;
Модуль «МТО» службу гл. механика;
Модуль «Спецификации продуктов» службу гл. энергетика;
Модуль «Контроллинг» службу гл. метролога;
Модуль «Управление ремонтами» проектно-конструктор-
ский отдел,
заводскую лабораторию
Финансовый кон- Модуль «Управление бюджетом» Финансовый отдел
тур Модуль «Платежный календарь»
Модуль «Финансовый анализ»
Контур бухгалтер- Модуль «Налоговые регистры» Бухгалтерию,
ского учета Модуль «Ведение налоговых расчетов» финансовый отдел
Модуль «Касса»
Модуль «Финансово-расчетные операции»
Модуль «Матценности»
Модули «Основные средства» и «Нема-
териальные активы»
Модуль «Хозоперации»
Модуль «Бухгалтерская отчетность»
Модуль «Консолидация»
Модуль «Векселя и кредиты»
Модуль «Фактические затраты»
Контур логистики Модуль «Управление договорами» Складские службы, экс-
Модуль «Управление снабжением» педицию, договорный
Модуль «Управление сбытом» отдел, отдел снабжения,
Модуль «Складской учет» отдел сбыта
Модуль «Поставщики, получатели»
Контур управления Модуль «Клиент» Отдел маркетинга, отдел
взаимоотношения- Модуль «Рекламные кампании» сбыта, отдел техниче-
ми с клиентами ской поддержки
Контур управления Модуль «Управление персоналом» Отдел труда и зарплаты,
персоналом Модуль «Заработная плата» отдел кадров
Специализирован- Модуль «Розничная торговля» Службы предприятия
ные решения Модуль «Управление транспортом»
Модуль «Сервисное обслуживание»
Модуль «Консигнация»
Модуль «Учет спецодежды»
Модуль «Давальческое сырье»
Модуль «Юрист»
Модуль «Капитальное строительство»
Контур системного Утилиты Настройку и управление
администрирования системой «Галактика»

287
Зарубежные компании, представленные на отечественном рынке
На российском рынке автоматизированных систем управления в сегменте
крупных интегрированных автоматизированных систем, являющихся пол-
нофункциональными ИАСУП мирового класса, представлены продукты трех
компаний, удовлетворяющих вышеперечисленным требованиям:
 SAP AG (система ERP);
 Oracle Corporation (Oracle Application);
 Baan Company (Baan IV).
В таблице 3.4 представлены функциональные модули систем, рассматри-
ваемых поставщиками, а также дополнительные продукты, используемые при
подготовке к внедрению и внедрении систем.
Функциональность всех рассматриваемых систем позволяет осуществлять
стандартный набор функций управления предприятием. При этом каждая из си-
стем обладает некоторыми особенностями построения, внедрения и эксплуата-
ции, которые и будут рассмотрены ниже.
Таблица 12.4
Сравнение систем
Baan IV Oracle Application SAP ERP
Финансы Финансы и финансо- Финансовая бухгалтерия и контроллинг
вый анализатор
Производство Производство Планирование производства и управление
материальными потоками
– Кадры Управление персоналом
Проект Проекты Система проектов
Сбыт, снабжение, склады Снабжение и сбыт Сбыт
Сервис Маркетинг Техобслуживание и ремонт оборудования
Процесс – –
Транспорт – –
Организатор (Orgware) Designer 2000 Business Engineer & ASAP

Система SAP ERP компании SAP AG

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

288
 Продукт Business Engineer (BE) фирмы SAP позволяет моделировать дея-
тельность предприятия и изменять конфигурацию системы SAP ERP. Как пока-
зало исследование, проведенное специалистами консалтинговой компании
Aberdeen Group, он состоит из несколько запутанного набора взаимосвязанных
данных, корпоративных моделей, моделей объектов и процессов, вариантов
развития ситуаций и структур, и в своем окончательном варианте снабжен «Ру-
ководством по внедрению системы». Это руководство фактически представляет
собой множество определений, взятых из таблиц SAP ERP, которые определя-
ют функции системы, таким образом, фирма SAP смогла оказывать влияние на
выполняемую операционную среду с помощью средств моделирования. Однако
существуют некоторые ограничения данной системы, делающие ее негибкой.
Не все модели BE в настоящее время интегрированы в данный продукт. Новые
процессы или методы не могут создаваться независимо от предлагаемых про-
цессов системы R/3. Отсутствует поддержка модифицирования и настройки
предлагаемых процессов системы SAP ERP. Если процесс выходит за рамки
среды SAP ERP, он не может быть включен в бизнес-модель предприятия.
Система Baan IV компании Baan Company
Система Baan IV компании Baan до последнего времени не обеспечивала
поддержки выполнения функций «Управление кадрами» и «Заработная плата».
В настоящее время эта проблема решена путем интеграции модулей указанного
назначения, разработанных партнером компании Baan в России, компанией
«Ланит». Конечно, профессиональный уровень данных разработок и объем за-
траченных на них человеко-часов несколько ниже, чем у «родных» модулей си-
стемы Baan IV, но поскольку данная функциональность сейчас редко запраши-
вается заказчиками в России, это не является большим недостатком системы.
В следующей версии продукта Baan IV — Baan Series — данные модули уже
входят в его состав.
Система Oracle Application компании Oracle Corporation
Система Oracle Application, поставляемая на рынок компанией Oracle
Corporation, на российском рынке программных средств для предприятий появи-
лась совсем недавно, чуть более года назад. Некоторые участники рынка связы-
вают это с тем, что для компании Oracle данный сегмент рынка не является основ-
ным, особенно в России, где доля рынка Oracle составляет всего около 3–5%.
Как показали результаты анализа, проведенного компанией Aberdeen, го-
товые решения, предлагаемые фирмами Baan и SAP, имеют программно-
ориентированную базу. Это означает, что данные средства разработаны с уче-
том возможности переноса между различными платформами реляционных баз
данных при сохранении согласованной информационной модели, предусмот-
ренной для данного программного средства. Средства фирмы Oracle основаны
на модели, ориентированной на базу данных, которая работает только на одной
реляционной платформе самой фирмы и использует базу данных для реализа-
ции функций программного средства или моделируемого процесса (т. е. ис-
пользует заложенные процедуры и средства запуска).

289
 Программное обеспечение фирмы Oracle в значительной степени про-
должает работать по принципу ориентации на функциональный информацион-
ный модуль, в котором механизмы перемещения между функциями или пере-
дачи данных запускаются с помощью какого-либо события в работе базы дан-
ных. В системах Baan IV и SAP ERP процессы, связанные с деятельностью
предприятия, являются неотъемлемой частью всей архитектуры программного
средства, а в системе фирмы Oracle они конструируются и моделируются вруч-
ную.

12.2. Системы-трансформеры
Конструктор — это коммерческий программный продукт (т. е. отчуждае-
мый от разработчика и отдельно продаваемый), включающий в себя:
 ядро (изменяемое или неизменяемое в зависимости от желания фир-
мы-разработчика разрешить или не разрешить клиентам доступ к нему);
 модель предметной области (достаточно абстрактную), содержащую
основные понятия предметной области, связанной с финансово-хозяйственной
деятельностью предприятия (например, документ, контрагент, справочник,
проводка и др.);
 среду разработки высокого уровня (CASE-средства, мастера по созда-
нию справочников и входных форм, дизайнеры, визарды и т. п.), которая не
требует от пользователя программистских навыков, а позволяет оперировать
понятиями предметной области.
Следствия:
 конструктор не должен работать с физической базой данных напря-
мую;
 конструктор должен обеспечивать совместимость снизу вверх гото-
вых программных решений и ядра (т. е. в нем должны быть предусмотрены
специальные средства интеграции предыдущих изменений с новой базовой вер-
сией ядра);
 фирма-производитель должна разрабатывать и развивать не КИС
плюс какое-то средство конфигурирования, а именно сам конструктор (при
этом конечное решение должны создавать обученные партнеры или клиенты).
С технологической (архитектурной) точки зрения конструктор — это
программный продукт, включающий:
 ядро, в котором определена принципиальная модель предметной об-
ласти, а также базовый набор классов (максимально абстрактных) и основных
методов работы с ними;
 конфигурацию (для общности назовем это так), которая представляет
собой реализацию информационной системы, построенной из классов и мето-
дов ядра;
 инструментарий, позволяющий пользователю строить свой соб-
ственный вариант конфигурации.
По сути дела, первыми конструкторами можно назвать такие системы
программирования, как FoxPro или MS Access, однако их ядро не содержит мо-
290
дели предметной области. Данные системы являются универсальными и при-
годными для создания практически любых программных продуктов, но они
требуют высокого уровня подготовки разработчиков и значительных затрат
времени.
Требования рынка сегодня звучат примерно так: «Клиенты желают со-
кращать сроки создания, внедрения и, что особенно важно, внесения изменений
в сложные ИС, предназначенные для управления деятельностью предприятий».
Это диктуется необходимостью адаптации систем управления к непрерывно
меняющемуся объекту управления и его системному окружению.
С другой стороны, клиентов волнует качество получаемых систем, под
которыми понимается адекватность управляемым процессам, надежность,
внутренняя непротиворечивость, интегрированность данных, соответствие со-
временному техническому уровню, быстродействие и другие параметры.
Понятно, что создавать системы, соответствующие всем перечисленным
требованиям, очень сложно, а на уровне пользователей — практически невоз-
можно. Эта сложность проявляется в увеличении размеров программ и расши-
рении функциональности систем, в множественности участвующих субъектов
управления, усложнении связности, в проблемах поддержания понятийной це-
лостности и т. д.
Поиск подхода, который позволил бы совместить достаточно высокую
скорость создания ИС и внесения изменений в нее с разумными экономически-
ми затратами, собственно, и привел программистское сообщество к разработке
систем-конструкторов, занявших (или стремящихся занять) особое место среди
систем других категорий. Отсюда и вытекают их специфические потребитель-
ские свойства: возможность внесения изменений в систему собственными си-
лами потребителя для ее адаптации к специфическим и уникальным задачам
управления.
Тут мнения разработчиков сильно различаются. Одни однозначно против,
другие более лояльны, но ответственность за внесенные изменения четко раз-
деляют с клиентом.
У первых ядро — это святая святых. Это исполняемый модуль, исходные
тексты которого недоступны для конечного пользователя («1С», «Алеф»).
В системе «Алеф» ядерные понятия, такие как документ, регистр, недоступны
для изменений. В то же время понятия предметного уровня (контрагент,
накладная) не входят в ядро и могут быть модифицированы с помощью дизай-
неров и программной оболочки.
В Navision Axapta ядро тоже недоступно, все изменения конфигурации
системы и индивидуальные настройки хранятся в отдельном пользовательском
слое.
Другие разработчики предоставляют пользователям полную свободу дей-
ствий, передавая им (если нужно) все исходные тексты («ИнтелГрупп»).
Третьи подходят гибко: что разрешается, а что запрещается изменять,
определяется условиями договора («Цефей»).

291
 Одним из наиболее важных моментов для клиента является возможность
внесения типовых изменений в систему с сохранением свойств адаптируемости
к специфическим и уникальным задачам управления.
Это требование основано на том, что потребители не хотят полностью от-
вечать за конечную систему, предпочитая, чтобы часть ответственности была
переложена на плечи фирм-разработчиков. Как упоминалось выше, все органи-
зации уникальны. Но уникальность не отменяет типичности отдельных аспек-
тов их деятельности, таких как необходимость соблюдать законодательство в
области учета, своевременно начислять зарплату сотрудникам, управлять дви-
жением финансовых средств и множество других общих задач. Для конечных
пользователей будет неэкономично расходовать свои ресурсы на доработку ИС
под задачи, одинаковые для всех.
Разработчики ЭИС фирмы «Цефей» утверждают следующее. При исполь-
зовании базовой информационной модели увеличивается скорость проектиро-
вания ИС, т. е. стоимость создания индивидуального решения для предприятия,
«подгонки данного костюмчика (базовой системы) под данного заказчика». Ре-
ально примерно от 40 до 60% бизнес-функций сохраняется на предприятии лю-
бой формы собственности и любых сфер деятельности. Различия не так уж ве-
лики, и если доделывать только этот отличающийся слой, то время настройки и
внедрения системы управления сокращается в разы.
Получается, что задачу «кооперации» должна решать фирма-разработчик,
поставляющая пользователям как первоначальную систему, так и ее новые вер-
сии.
Эта задача конструкторов распадается на две:
 разработка типовых конфигураций (типовых отраслевых решений,
решений для определенных аспектов бизнеса и т. п.);
 выпуск новых версий ядра и среды разработки.
Обозначим качества, выделяющие эти системы среди ИС разных классов.
В первую очередь, это возможность относительно недорого получить ра-
ботающую информационную систему, позволяющую на основе типовых кон-
фигураций собственными силами непрерывно адаптировать ее к уникальным
задачам управления своей компании при помощи несложного инструментария
(и при этом разделяя ответственность за систему с ее разработчиками).
Кроме того, системы-конструкторы перспективны тем, что являются
промежуточным звеном между системами класса полностью «сделай сам» и
жесткими коробочными системами.
Система «Алеф»
Система «Алеф» предназначена для автоматизации хозяйственной дея-
тельности предприятий различных отраслей. Программа представляет собой
конструктор финансовых приложений, с помощью которого на предприятиях
своими силами или с помощью третьих фирм осуществляется построение фи-
нансово-учетной системы, соответствующей специфике предприятия. Система
«Алеф» не является готовой системой и требует дополнительной настройки для
работы в конкретной компании или группе компаний.
292
 Среди задач, решаемых с помощью системы «Алеф», — ведение опера-
тивного, бухгалтерского и управленческого учета, оперативного планирования
и контроля исполнения бюджетов, составление различного рода отчетности для
всех групп пользователей: бухгалтеров, управляющих, внешних заинтересован-
ных сторон и др.
Программа может быть настроена для ведения учета как в РСБУ, так и в
МСФО, таких как GAAP, IAS. Программа позволяет вести учет для нескольких
предприятий в единой базе данных. Возможно ведение учета для одного пред-
приятия одновременно в нескольких стандартах, например в РСБУ, МСФО и в
соответствии с внутренними стандартами управленческой отчетности.
Программа обладает широкими возможностями для организации плани-
рования, бюджетирования и финансового анализа и прогнозирования, имеет
большой набор встроенных отчетов и богатый выбор инструментов для созда-
ния специализированных отчетов и произвольного представления информации.
Операции можно регистрировать в различных валютах с автоматическим
подсчетом эквивалентных сумм в нескольких валютах эквивалентного пред-
ставления одновременно.
Система «Алеф» имеет два основных хранилища данных — архив доку-
ментов и архив изменения аналитических учетных регистров (проводок). Архив
документов содержит все введенные пользователями документы, на основании
(или с помощью) которых регистрируются проводки, которые сохраняются в
архиве проводок.
При этом система позволяет обеспечить:
 ведение полноценного мультивалютного суммового и количественно-
го оперативного бухгалтерского и управленческого аналитического учета;
 автоматизацию финансовых служб, служб анализа, планирования и
контроля исполнения бюджетов;
 ведение централизованного учета одновременно на нескольких пред-
приятиях;
 организацию центрального звена для построения учетной системы
предприятия, которое способно стать центром для обработки и отражения ин-
формации всех существующих звеньев;
 интеграцию с другими программными системами;
 гибкую настройку на специфику предприятия с возможностью встра-
ивания различных функций, например, функций финансового анализа и плани-
рования;
 совместную работу большого количества пользователей с различной
степенью доступа к информации.
Программа построена с использованием технологии «клиент/сервер», ко-
торая обеспечивает надежное хранение и оперативное использование большого
объема данных. Эта технология обеспечивает доступ к данным большого коли-
чества пользователей со строго регламентированным доступом к информации и
проведением тех или иных операций.

293
 В основу проекта наряду со старыми и проверенными приемами построе-
ния учетных систем были положены оригинальные решения, реализация кото-
рых стала возможна благодаря применению высоконадежных серверов баз дан-
ных.
Вследствие этого система «Алеф» при соответствующей первичной
настройке позволяет полноценно решать задачи автоматизации таких участков
учета, как:
 оперативный учет заявок клиентов и формирование заказов на закупку;
 производственный учет;
 складской учет;
 учет кредиторской и дебиторской задолженности, материалов, МБП;
 учет основных средств и нематериальных активов;
 учет портфелей ценных бумаг;
 бюджетирование и планирование;
 учет затрат по местам возникновения затрат (МВЗ) и др.
Если для построения учетной системы предприятия требуется интеграция
дополнительных специализированных приложений, то система «Алеф» предо-
ставляет для этого интерфейсы межпрограммного взаимодействия.
Достоинствами системы «Алеф-Бухгалтерия 4.0» являются:
 система предназначена для мелких и средних предприятий;
 система «Алеф» является интегрированной, что позволяет настраивать
ее для конкретного предприятия;
 наличие настраиваемого пользовательского интерфейса;
 возможность создания документов и различных форм отчетов, кото-
рое использует предприятие;
 программа предоставляется бесплатно.
«1С: Предприятие»
Система программ «1С: Предприятие» предоставляет широкие возможно-
сти ведения автоматизированного учета на предприятиях, в организациях и
учреждениях, независимо от их вида деятельности и формы собственности, с
различным уровнем сложности учета.
«1С: Предприятие» является универсальной системой автоматизации дея-
тельности предприятия. Поэтому может быть использована для автоматизации
самых разных участков экономической деятельности предприятия: учета то-
варных и материальных средств, взаиморасчетов с контрагентами, расчета за-
работной платы, расчета амортизации основных средств, бухгалтерского учета
по любым разделам и т. д.
Система «1С: Предприятие» имеет компонентную структуру и занимает
промежуточное положение между настраиваемыми системами и системами-
трансформерами. Часть возможностей, предоставляемых системой для решения
задач автоматизации, являются базовыми, т. е. поддерживаются в любом вари-
анте поставки системы.

294
 В комплексную поставку входят основные компоненты системы про-
грамм «1С: Предприятие»:
 «Бухгалтерский учет»;
 «Оперативный учет»;
 «Расчет»;
а также основные конфигурации:
 «Бухгалтерский учет»;
 «Торговля + Склад»;
 «Зарплата + Кадры»;
 «Производство + Услуги + Бухгалтерия»;
 «Бухгалтерия + Торговля + Склад + Зарплата + Кадры».
Пользователи могут применять конфигурации, входящие в новую ком-
плексную поставку как по отдельности, так и совместно, подобрав для себя
подходящий вариант работы с системой. Выбор конфигурации зависит, прежде
всего, от решаемых задач, от типа деятельности и структуры конкретного пред-
приятия, уровня сложности ведения учета и других условий.
Пользователи могут вести учет в комплексной конфигурации или решать
разные задачи учета в отдельных конфигурациях, пользуясь средствами обмена
данных, или же начать с автоматизации одного из направлений учета, исполь-
зуя отдельную конфигурацию.
Сохраняя возможности основных конфигураций «Бухгалтерский учет»,
«Торговля + Склад» и «Зарплата + Кадры», комплексная конфигурация обеспе-
чивает интегрированное ведение учета:
 единую систему нормативно-справочной информации;
 автоматическое отражение торгово-складских операций и расчета за-
работной платы в бухгалтерском учете;
 финансовый учет по нескольким юридическим лицам;
 консолидированный управленческий учет.
Интеграция системы «1С: Предприятие» с внешними приложениями
Система программ «1С: Предприятие» является открытой системой.
Предоставляется возможность для интеграции практически с любыми внешни-
ми программами и оборудованием на основе общепризнанных открытых стан-
дартов и протоколов передачи данных.
В системе программ «1С: Предприятие» имеется целый набор средств, с
помощью которых можно:
 создавать, обрабатывать и обмениваться данными различных форма-
тов;
 осуществлять доступ ко всем объектам «1С: Предприятия», реализу-
ющим ее функциональные возможности;
 поддерживать различные протоколы обмена;
 поддерживать стандарты взаимодействия с другими подсистемами;
 разрабатывать собственные интернет-решения.
Фирма «1С» постоянно расширяет функциональные возможности для ин-
теграции своей системы программ «1С: Предприятие» путем разработки новых
295
решений и технологий, базирующихся на применении современных средств ин-
теграции, достижений в области Интернет-технологий и новых форматов пред-
ставления данных.
За счет своей открытости и большого выбора средств сопряжения с
внешними приложениями, а также дополнительных решений партнеров фирмы
«1С» система программ «1С: Предприятие» предоставляет легкий и удобный
сервис «конечным» пользователям (управленцам, бухгалтерам, работникам
торговых организаций и т. д.), IT-специалистам, внедряющим интегрированные
решения, а также всем разработчикам тиражных решений для интеграции с
«1С: Предприятием».
Navision Axapta
Международная система управления предприятием Axapta создана для
средних и крупных предприятий различных отраслей хозяйствования. Незави-
симо от того, собираетесь ли вы оптимизировать бизнес-процессы, минимизи-
ровать затраты, увеличить долю на рынке или открыть проект по созданию
электронного магазина, Axapta будет способствовать осуществлению каждого
вашего шага.
Основными модулями системы Axapta являются:
 финансы;
 торговля и логистика;
 производство;
 электронная коммерция;
 управление персоналом;
 проекты;
 управление взаимоотношениями с клиентами (CRM — Customer
Relationship Management);
 управлением знанием (KM — Knowledge Management);
 управление логистическими цепочками (SCM — Supply Chain Mana-
gement) и другие.
Большой набор функциональных возможностей системы Axapta позволя-
ет получить ряд определенных преимуществ:
 более низкие затраты на создание и поддержку системы;
 легкость в обновлении приложений;
 баланс избыточной информации;
 полная интеграция бизнес-процессов.
Силами специалистов Columbus IT Partner могут быть созданы любые не-
обходимые программные модули в системе Axapta.
Надежность и открытость
Основой надежности системы Axapta служат заложенные при ее разра-
ботке технологии. Axapta использует синтаксис SQL (Structured Query Langua-
ge — язык структурированных запросов). При этом выбор конкретной СУБД
остается за вами: вы можете использовать как Microsoft SQL Server, так и СУБД
Oracle.

296
 Взаимодействие Axapta с внешними приложениями осуществляется с по-
мощью механизма COM/DCOM. Из системы Axapta можно создавать любые
COM-объекты, посредством которых осуществляется работа с внешними при-
ложениями.
Существует и обратный механизм, позволяющий работать внешним при-
ложениям с внутренними объектами системы Axapta через механизм
COM/DCOM. Для этого используется специальная библиотека Axapta COM
Connector, которая позволяет внешнему приложению рассматривать Axapta как
COM-объект и дает возможность непосредственного доступа к данным Axapta,
управления транзакциями и использования бизнес-логики системы для их об-
работки через COM/DCOM интерфейс. Это гарантирует полную интеграцию
Axapta в принятую на фирме технологию документооборота.
Удобство работы
Для освоения Axapta требуется минимум усилий и консультаций, по-
скольку по своему интерфейсу она аналогична программам Microsoft. Axapta
использует систему меточных файлов, т. е. в ядре системы и ее приложениях
присутствуют ссылки на метки — тексты названий пунктов меню, кнопок,
строк диалогов, помощи и других. Переход с одного языка интерфейса к друго-
му заключается в смене ссылок на меточные файлы, что делается одной опцией
в конфигурационной утилите Axapta. Для каждого сотрудника предприятия
можно настроить как простые принципы фильтрации записей, так и задать
сложные условия и формулы выборки.
Администрирование системы
Настройка конкретных прав доступа пользователя осуществляется по
технологии функциональных ключей, разрешая или запрещая доступ пользова-
телей к различным частям прикладной программы. Эти средства позволяют
скрывать, добавлять или удалять функциональные элементы на уровне всего
предприятия и отдельных пользователей. То же самое касается отчетов, систе-
мы меню и пунктов меню.
Технология Axapta Web Deployment Client (AWDC) позволяет легко уста-
новить клиентские приложения. В дистрибутив системы включен специальный
ActiveX-компонент (AWDC), обеспечивающий удаленное администрирование
клиентской части системы через web-браузер. Используя AWDC и конфигура-
ционную утилиту системы Navision Axapta, администратор может централизо-
ванно настроить конфигурацию системы и немедленно распространить ее на
все последующие подключения пользователей. Такой подход позволяет значи-
тельно упростить процесс установки клиентской части Navision Axapta.
Поддержка удаленных офисов
ERP-система Axapta создана для средних и крупных предприятий с рас-
пределенной структурой, в том числе для холдингов, многофилиальных пред-
приятий, дистрибьюторских компаний, международных корпораций и пр. Ар-
хитектура системы позволяет организовать одновременную работу с сервером
приложений десятков удаленных пользователей с настраиваемыми правами до-
ступа.

297
 Использование в качестве коммуникационного протокола Axapta Object
Communication Protocol, основанного на стандарте TCP/IP, дает возможность
оптимального выбора способа связи: ISDN, Frame Relay, сотовая связь, WAP,
доступ в Интернет. Axapta позволяет выбрать эффективную конфигурацию,
учитывающую характеристики каналов связи, архитектуру серверов и рабочих
станций: двухуровневую конфигурацию, трехуровневую конфигурацию, работу
через Интернет или по протоколу WAP. Правильно организовав работу с уда-
ленными подразделениями вашей компании, вы приобретаете важные преиму-
щества: централизованную базу данных, возможность оперативного обновле-
ния информации, контроль, учет и планирование на всех уровнях холдинга.
Уникальность Axapta
Уникальные возможности Axapta обусловлены применением в системе
новейших средств разработки. Так, язык X++ создан специально для разработки
корпоративных информационных систем. Он оптимизирован на описание тех
процессов, которые призвана поддерживать система Axapta. Язык X++ вобрал в
себя лучшее от существующих систем программирования: удобный синтаксис
Java, мощь языка C++, гибкие средства доступа к данным SQL. Интегрирован-
ная среда разработки MorphX существенно упрощает внедрение, масштабиро-
вание и обновление системы. Использование стандарта XML позволяет реали-
зовать эффективный документооборот между участниками бизнес-процессов
как внутри вашего предприятия, так и с вашими партнерами и контрагентами.
Создание web-приложения в Axapta
Axapta, являясь интегрированной ERP-системой нового поколения, обес-
печивает создание единого бизнес-пространства. Модули интернет- и WAP-
приложений системы Axapta позволяют на основе «Мастера web-приложений»
и шаблонов легко создавать свои интернет- или WAP-приложения. Средства
публикации Axapta позволяют автоматически отслеживать изменения в базе
данных и немедленно публиковать обновленные данные на web-странице. Вхо-
дящий в систему модуль дистанционного обслуживания клиентов (CSS) обес-
печивает организацию электронной торговли с открытием полноценного элек-
тронного магазина и автоматической обработкой заказов клиентов.
Технологические особенности
Решение новых функциональных возможностей, лежащих в основе кон-
цепции e-Sphere, потребовало применения в Navision Axapta самых современ-
ных разработок и технологий, многие из которых являются уникальными.
Доступные для изменений объекты системы
Дерево объектов, построенное в соответствии со стандартами Microsoft,
обеспечивает разработчикам мгновенный доступ к различным объектам систе-
мы: таблицам, расширенным типам данных, функциональным ключам, макро-
сам, отчетам, запросам и пр.
Большой набор функциональных возможностей системы Navision Axapta
позволяет получить ряд определенных преимуществ.
Открытый характер системы
Система является полностью открытой, т. е. предоставляет доступ ко
всем объектам, реализующим ее функциональные возможности. Любой объект
298
системы можно представить как дерево подобъектов. По каждому объек-
ту/подобъекту разработчик может определить все необходимые свойства. На
основе существующих объектов можно строить новые, модифицировать их или
создавать «с нуля».
При реализации объектов пользовательского интерфейса можно сформи-
ровать дерево подобъектов, в котором будут собраны элементы системы, груп-
пы элементов, пункты меню, объекты системы, содержащие источники данных,
и т. д. При обращении пользователя к соответствующим объектам IntelliMorph
автоматически сформирует требуемую экранную форму или отчет.
Разработчик может применять также графический редактор отчетов, гра-
фический редактор форм и редактор исполняемого кода, написанного на языке
X++. Для формирования модификаций системы и/или анализа существующей
иерархии объектов можно использовать встроенный CASE-инструментарий.
Архитектура слоев
В систему введены специальные средства, поддерживающие концепцию
так называемых слоев, с помощью которых отслеживаются изменения ее эле-
ментов. Это существенно облегчает процесс обновления системы при выходе
новой версии. Например, класс LedgerVoucher содержит методы, созданные по-
ставщиком (в слое Sys), откорректированные производителем (в слое Syp) и ре-
ализованные пользователем (в слое Usr). Всего таких слоев в системе 16. Нали-
чие этих слоев, а также особого инструментария для выявления различий меж-
ду ними создает возможность для вычленения модификаций системы и их пе-
реноса в новую версию.
Связь с другими подсистемами
Поддержка открытых стандартов Microsoft
При организации взаимодействия системы с другими приложениями раз-
работчику предоставляется богатый выбор средств.
В частности, он может воспользоваться:
 ODBC-доступом к данным;
 механизмом DDE для обмена с приложениями Microsoft Office (на
этом и основана встроенная система документооборота, позволяющая, напри-
мер, с помощью заданных шаблонов MS Word и данных из Navision Axapta
формировать готовые документы и связывать их с данными в системе);
 элементами ActiveX (именно так реализованы графические инстру-
менты — статистический анализ, графики Ганта, дерево спецификации и т. д.);
 интерфейсом COM/DCOM;
 функциями операционной системы WinAPI.
Средства для профессиональных разработчиков
Профессиональным разработчикам система предлагает ряд специальных
инструментов:
 средства ведения проектов по разработке системы, которые могут
включать любое количество системных элементов (последние могут быть за-
блокированы от модификаций другими разработчиками);

299
  инструмент, отслеживающий перекрестные ссылки всех объектов в
системе;
 средства отладки с возможностью установки точек прерывания, поша-
гового прохода и анализа значений данных.
Средства для рядовых пользователей
Для того чтобы система была максимально доступна рядовому (начина-
ющему) пользователю, в нее введен набор «Мастеров», которые путем диалога
могут помочь ему создать отчет, настроить публикацию данных для Интернета
(в формате HTML) и т. д. Кроме того, рядовой пользователь может полностью
настроить меню для своего рабочего места, создав новую панель и перетащив в
нее с помощью мыши все те функции из стандартного меню системы, которые
он реально использует.
Визуальная подстройка экранных форм и отчетов
Одна из ключевых концепций, лежащих в основе построения системы,
предполагает применение технологии IntelliMorph. Это означает, что экранные
формы и отчеты в системе визуализируются «на лету» — в зависимости от ее
текущих характеристик (набора подключенных модулей и функциональных
ключей, свойств типов данных). Сбросив, например, функциональный ключ
«Скидка по оплате», пользователь может определить для системы, что все вхо-
дящие в нее объекты, связанные с этим ключом, не должны использоваться, и
тогда при запуске соответствующих экранных форм он не увидит «лишних»
полей. Аналогично, если изменить длину свойства базового типа
ExternalAccount с 10 символов на 20 символов и перезапустить систему, то во
всех таблицах, экранных формах и отчетах, где задействованы коды клиентов и
поставщиков, можно будет работать с 20-символьными кодами.
Язык программирования X++
Рассмотренный в разделе IntelliMorph пример основан также на том, что
система Navision Axapta построена полностью по объектно-ориентированной
технологии. Встроенный язык программирования X++ аналогичен языкам Java
и C++, так что инструментарий системы базируется на иерархической структу-
ре классов и типов данных.
Важно отметить, что в языке X++ предусмотрена возможность прямого
использования SQL-выражений. Для ускорения работы в редактор компилятора
встроена мощная система контекстной помощи при вводе — набрав, скажем,
имя таблицы и поставив точку-разделитель, пользователь автоматически полу-
чит от системы список входящих объектов (полей и методов), из которого он
сможет выбрать необходимый вариант.
Организация контекстно-зависимой помощи
Немаловажным достоинством системы является то, что вся встроенная по-
мощь по реализации функциональных возможностей (online help) базируется на
языке HTML. При этом разработчики могут редактировать тексты помощи или
создавать новые для нового инструментария. В таких текстах можно задейство-
вать весь потенциал гипертекстового редактора — для редактирования шрифтов,
выбора различных стилей, задания ссылок на конкретные формы, поля данных,
классы, методы, помощь в формате WinHelp, использования графических объек-
300
тов и т. д. Помимо помощи для пользователей, в Navision Axapta встроена мощ-
ная контекстная система формата WinHelp для разработчиков, которая содержит
детальное описание ее свойств, примеры кода, рекомендации и т. д.
Система «Эталон»
Основные характеристики системы
Информационная система «Эталон» предназначена для эффективного
управления ресурсами холдингов, корпораций, крупных предприятий, средних
предприятий сложной структуры всех сфер деятельности.
Заложенный в систему принцип масштабирования позволяет системе
«Эталон» быстро и эффективно реагировать на структурные изменения пред-
приятия или холдинга, освоение ими новых видов деятельности и применение
новых технологий, на укрупнение бизнеса и возрастающие объемы обрабаты-
ваемой информации, на увеличение числа и сложности решаемых задач, а так-
же изменение географии предприятия.
Система поддерживает международные стандарты управленческого учета:
MRP II, ERP, CSRP. Бухгалтерский учет ведется по российским и международ-
ным стандартам (IAS, GAAP) в режиме реального времени в полном объеме.
Мультивалютный режим обеспечивает получение информации как в
национальной валюте, так и в нескольких произвольно выбранных валютах од-
новременно.
В системе реализована многоязыковая сетевая поддержка, которая позво-
ляет использовать различные языки в интерфейсах рабочих станций, одновре-
менно работающих в комплексе «Эталон».
Версии 5 и 6 системы реализованы в архитектуре клиент-сервер для
СУБД Oracle и MS-SQL Server.
Интерфейс системы удовлетворит вкус самого взыскательного пользова-
теля универсальным системным подходом и в то же время разнообразием
настраиваемых экранов, документов, отчетов, изменяемых в соответствии с
требованиями действующего законодательства, реализованного бизнес-
процесса, желаемого уровня аналитичности и методиками управления предпри-
ятием.
Удобство в работе с «Эталоном» обеспечено продуманным подходом
специалистов фирмы к созданию объектно-ориентированных CASE-средств,
включающих уникальный инструментарий: редактор классов, редактор форм,
редактор отчетов, редактор документов, редактор методов, графический ввод и
встроенный объектно-ориентированный язык «Эталон».
Многооконный режим работы в сочетании с единой панелью инструмен-
тов и универсальностью принципов управления окнами, реализованные совре-
менные технологии, первичный контроль вводимой информации, удобная си-
стема помощи и подробная документация на русском языке — все это сводит к
минимуму проблемы в обучении и облегчает каждодневную работу пользова-
теля любого уровня.
В комплексе разработана и успешно реализована технология быстрого
ввода больших объемов информации.
301
 Комплекс учитывает и представляет информацию для пользователя лю-
бого уровня: собственника предприятия, администрации, контролирующих ор-
ганов предприятия и государства, контрагентов и т. д.
Новые технологии, реализованные в системе
Система управления ресурсами предприятия «Эталон» удовлетворяет
требованиям универсальности, функциональности, оперативности и простоты
использования благодаря реализации следующих новых технологий и ориги-
нальных решений.
На основе объектно ориентированной Эталон-CASE-технологии форми-
руется единое информационное и функциональное пространство, которое обра-
батывается единым программным кодом вне зависимости от состава, структуры
и динамики изменений этого пространства.
Единое информационное и функциональное пространство состоит из
унифицированных формализованных элементов — классов, которыми описы-
ваются данные и методы их обработки. На основе классов создается информа-
ционная модель системы управления предприятием. Основные принципы объ-
ектно-ориентированного проектирования — наследование, инкапсуляция и по-
лиморфизм — позволяют успешно реализовать технологию единого простран-
ства.
Классы пространства обладают следующими основными свойствами:
 состоят из данных и метаданных, последние, в свою очередь, объ-
единяют описание данных, их функциональные возможности и пользователь-
ский интерфейс для работы с ними, т. е. элемент пространства представляет со-
бой структурированные данные и методы их обработки;
 сохраняют свою сущность и целостность на протяжении всего вре-
мени жизни системы (проектирование, генерация, эксплуатация, модифика-
ция/перепроектирование и новая генерация). Таким образом, на основе создан-
ного класса можно, по мере необходимости, получать производные классы с
расширением их функциональных возможностей; изменения, внесенные в ро-
дительский класс, автоматически переносятся во все производные классы;
классы обрабатываются процедурами, написанными, согласно правилам внут-
реннего языка Эталон;
 могут участвовать в любых методах обработки и отображения ин-
формации; способы визуализации и внешнего представления данных также
описываются при помощи классов (экранные формы, документы, отчеты);
 введенные один раз и хранимые в одном месте, данные могут ис-
пользоваться любой логической ветвью единого программного кода, т. е. для
любого вида учета (бухгалтерского, финансового, управленческого и пр.) дан-
ные хранятся в едином информационном пространстве, которое обрабатывается
единой программой.
Методология интеграции управленческого, финансового, бухгалтерского,
статистического учета и финансово-экономического анализа лежит в основе
выделения и формализованного описания базовых классов объектно-ориенти-
рованного проектирования, что является know-how компании.

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

303
 ПРИЛОЖЕНИЕ 1
АВТОРСКОЕ ПРАВО.
ГРАЖДАНСКИЙ КОДЕКС, ЧАСТЬ 4.
Правовые основы информатики
До последнего времени связанные с интеллектуальной собственностью
правоотношения регламентировались целым пакетом специальных законов об
охране авторского права. С принятием Федерального закона от 18.12.2006
№ 231-ФЗ «О введении в действие части четвертой Гражданского кодекса Рос-
сийской Федерации» (далее — Закон № 231-ФЗ) с 1 января 2008 г. эти законы
утратили силу, а указанные правоотношения регулируются гражданским зако-
нодательством (ст. 1225–1551 ГК РФ).
Часть четвертая ГК РФ применяется к правоотношениям, возникшим по-
сле введения ее в действие.
Статья 1225 ГК РФ «Охраняемые результаты интеллектуальной деятель-
ности и средства индивидуализации» содержит перечень объектов, получаю-
щих правовую охрану. В этот перечень включены программы для ЭВМ и базы
данных.
Согласно ст. 1226 ГК РФ, на результаты интеллектуальной деятельности
и средства индивидуализации признаются интеллектуальные права, которые
включают с себя исключительное право, являющееся имущественным правом.
Автором результата интеллектуальной деятельности признается гражда-
нин, творческим трудом которого создан такой результат (п. 1 ст. 1228 ГК РФ).
Гражданин или юридическое лицо, обладающие исключительным правом
на результат интеллектуальной деятельности (правообладатель), вправе исполь-
зовать такой результат или такое средство по своему усмотрению любым не
противоречащим закону способом, а другие лица не вправе без согласия право-
обладателя использовать охраняемый законом объект (п. 1. ст. 1229 ГК РФ).
Программы для ЭВМ
Программы для ЭВМ по своей правовой природе относятся к объектам ав-
торских прав и охраняются как литературные произведения (п. 1. ст. 1259, 1261
ГК РФ).
Программа для ЭВМ — это «представленная в объективной форме сово-
купность данных и команд, предназначенных для функционирования ЭВМ и
других компьютерных устройств в целях получения определенного результата,
включая подготовительные материалы, полученные в ходе разработки про-
граммы для ЭВМ, и порождаемые ею аудиовизуальные отображения» (ст. 1261
ГК РФ).
Что касается государственной регистрации программы для ЭВМ, то пра-
вообладатель в течение срока действия исключительного права на данную про-
грамму может по своему желанию зарегистрировать такую программу в феде-
ральном органе исполнительной власти по интеллектуальной собственности
(п. 1. ст. 1262 ГК РФ).

304
 Исключительное право на произведение действует в течение всей жизни
автора и 70 лет, считая с 1 января года, следующего за годом смерти автора
(п. 1. ст. 1281 ГК РФ). Представляется, что государственную регистрацию про-
граммы для ЭВМ может произвести и наследник (наследники) автора, к кото-
рому исключительное право на программу для ЭВМ переходит в порядке уни-
версального правопреемства (ст. 1241 ГК РФ), а также правообладатель —
юридическое лицо.
В случае государственной регистрации программ для ЭВМ правооблада-
телем наступают правовые последствия: при отчуждении по договору, залоге
этого права и предоставления по договору — все эти действия необходимо под-
вергать государственной регистрации с помощью госрегистрации соответству-
ющего договора. Несоблюдение этого требования влечет недействительность
соответствующего договора. Основанием для внедоговорного перехода прав
является соответствующее решение суда или свидетельство о праве на наслед-
ство (п.п. 4., 5. ст. 1232 ГК РФ).
Распоряжение исключительным правом на программу для ЭВМ
Часть четвертая ГК РФ вводит два основных вида договоров по распоря-
жению исключительным правом:
 договор об отчуждении исключительного права;
 договор о предоставлении другому лицу права использования соот-
ветствующего результата интеллектуальной деятельности в установленных до-
говором пределах (лицензионный договор). При этом заключение лицензион-
ного договора не влечет за собой переход исключительного права к лицензиату
(п. 1. ст. 1233 ГК РФ).
Права пользователя программой для ЭВМ
Лицо, правомерно владеющим экземпляром программы для ЭВМ (поль-
зователь), вправе без разрешения автора или иного правообладателя и без вы-
платы дополнительного вознаграждения:
 внести в программу для ЭВМ изменения исключительно в целях ее
функционирования на технических средствах пользователя и осуществлять
действия, необходимые для функционирования такой программы в соответ-
ствии с ее назначением, в том числе запись и хранение в памяти ЭВМ (одной
ЭВМ или одного пользователя сети), а также осуществить исправление явных
ошибок, если иное не предусмотрено договором с правообладателем;
 изготовить копию программы для ЭВМ при условии, что эта копия
предназначена только для архивных целей или для замены правомерно приоб-
ретенного экземпляра в случаях, когда такой экземпляр утерян, уничтожен или
стал непригоден для использования. При этом копия программы для ЭВМ не
может быть использована в иных целях.

305
 ПРИЛОЖЕНИЕ 2
СПРАВОЧНО. ВЫДЕРЖКИ ИЗ ГОСТ 34.601-90
Содержание работ
На этапе 1.1 «Обследование объекта и обследование необходимости со-
здания АС» в общем случае проводят:
 сбор данных об объекте автоматизации и осуществляемых видах де-
ятельности. Количество методов сбора данных достаточно велико. Условно их
можно разделить на два класса: методы, предусматривающие участие проекти-
ровщиков, и методы сбора материала без их непосредственного участия. Кон-
кретный метод выбирается с учетом особенностей объекта управления;
 оценку качества функционирования объекта и осуществляемых видов
деятельности, выявление проблем, решение которых возможно средствами ав-
томатизации;
 оценку (технико-экономической, социальной и т. п.) целесообразности
создания АС.
На этапе 1.2 «Формирование требований пользователя к АС» проводят:
 подготовку исходных данных для формирования требований к АС (ха-
рактеристика объекта автоматизации, описание требований к системе, ограни-
чения допустимых затрат на разработку, ввод в действие и эксплуатацию, эф-
фект, ожидаемый от системы, условия создания и функционирования системы);
 формулировку и оформление требований пользователя к АС.
На этапе 1.3 «Оформление отчета о выполненной работе и заявки на раз-
работку АС (тактико-технического задания)» проводят оформление отчета о
выполненных работах на данной стадии и оформление заявки на разработку АС
(тактико-технического задания) или другого заменяющего ее документа с ана-
логичным содержанием.
На этапах 2.1 «Изучение объекта» и 2.2 «Проведение необходимых науч-
но-исследовательских работ» организация-разработчик проводит детальное
изучение объекта автоматизации и необходимые научно-исследовательские ра-
боты (НИР), связанные с поиском путей и оценкой возможности реализации
требований пользователя, оформляют и утверждают отчеты о НИР.
На этапе 2.3 «Разработка вариантов концепции АС и выбор варианта кон-
цепции АС, удовлетворяющего требованиям пользователя» в общем случае про-
водят разработку альтернативных вариантов концепции создаваемой АС и пла-
нов их реализации; оценку необходимых ресурсов на их реализацию и обеспече-
ние функционирования; оценку преимуществ и недостатков каждого варианта;
сопоставление требований пользователя и характеристик предполагаемой систе-
мы и выбор оптимального варианта; определение порядка оценки качества и
условий приемки системы; оценку эффектов, получаемых от системы.
На этапе 2.4 «Оформление отчета о выполненной работе» подготавлива-
ют и оформляют отчет, содержащий описание выполненных работ на стадии,
описание и обоснование предполагаемого варианта концепции системы.

306
 На этапе 3.1 «Разработка и утверждение технического задания на создание
АС» проводят разработку, оформление, согласование и утверждение техническо-
го задания на АС и, при необходимости, технических заданий на части АС.
На этапе 4.1 «Разработка предварительных проектных решений по систе-
ме и ее частям» определяются: функции АС; функции подсистем, их цели и эф-
фекты; состав комплексов задач и отдельных задач; концепции информацион-
ной базы, ее укрупненная структура; функции системы управления базой дан-
ных; состав вычислительной системы; функции и параметры основных про-
граммных средств.
На этапе 5.1 «Разработка проектных решений по системе и ее частям»
обеспечивают разработку общих решений по системе и ее частям, функцио-
нально-алгоритмической структуре системы, по функциям персонала и органи-
зационной структуре, по структуре технических средств, по алгоритмам реше-
ния задач и применяемым языкам, по организации и ведению информационной
базы системе классификации и кодирования информации, по программному
обеспечению.
На этапах 4.2 и 5.2 «Разработка документации на АС и ее части» проводят
разработку, оформление, согласование и утверждение документации в объеме,
необходимом для описания полной совокупности принятых проектных реше-
ний и достаточном для дальнейшего выполнения работ по созданию АС. Виды
документов — по ГОСТ 34.201.
На этапе 5.3 «Разработка и оформление документации на поставку изде-
лий для комплектования АС и (или) технических требований (технических за-
даний) на их разработку» проводят: подготовку и оформление документации на
поставку изделий для комплектования АС; определение технических требова-
ний и составление ТЗ на разработку изделий, не изготавливаемых серийно.
На этапе 5.4 «Разработка заданий на проектирование в смежных частях
проекта объекта автоматизации» осуществляют разработку, оформление и
утверждение заданий на проектирование в смежных частях проекта объекта ав-
томатизации для проведения строительных, электротехнических, санитарно-
технических и других подготовительных работ, связанных с созданием АС.
На этапе 6.1 «Разработка рабочей документации на систему и ее части»
осуществляют разработку рабочей документации, содержащей все необходи-
мые и достаточные сведения для обеспечения выполнения работ по вводу АС в
действие и ее эксплуатации, а также для поддержания уровня эксплуатацион-
ных характеристик (качества) системы в соответствии с принятыми проектны-
ми решениями, ее оформление, согласование и утверждение. Виды докумен-
тов — по ГОСТ 34.201.
На этапе 6.2 «Разработка или адаптация программ» проводят разработку
программ и программных средств системы, выбор, адаптацию и (или) привязку
приобретаемых программных средств, разработку программной документации
в соответствии с ГОСТ 19.101.
На этапе 7.1 «Подготовка объекта автоматизации к вводу АС в действие»
проводят работы по организационной подготовке объекта автоматизации к вво-
ду АС в действие, в том числе: реализацию проектных решений по организаци-
307
онной структуре АС; обеспечение подразделений объекта управления инструк-
тивно-методическими материалами; внедрение классификаторов информации.
На этапе 7.2 «Подготовка персонала» проводят обучение персонала и
проверку его способности обеспечить функционирование АС.
На этапе 7.3 «Комплектация АС поставляемыми изделиями» обеспечива-
ют получение комплектующих изделий серийного и единичного производства,
материалов и монтажных изделий. Проводят входной контроль их качества.
На этапе 7.4 «Строительно-монтажные работы» проводят: выполнение
работ по строительству специализированных зданий (помещений) для разме-
щения технических средств персонала АС; сооружение кабельных каналов; вы-
полнение работ по монтажу технических средств и линий связи; испытание
смонтированных технических средств; сдачу технических средств для проведе-
ния пусконаладочных работ.
На этапе 7.5 «Пусконаладочные работы» проводят автономную наладку
технических и программных средств, загрузку информации в базу данных и
проверку системы ее ведения; комплексную наладку всех средств системы.
На этапе 7.6 «Проведение предварительных испытаний» осуществляют:
испытания АС на работоспособность и соответствие техническому заданию в
соответствии с программой и методикой предварительных испытаний; устране-
ние неисправностей и внесение изменений в документацию на АС, в том числе
эксплуатационную в соответствии с протоколом испытаний; оформление акта о
приемке АС в эксплуатацию.
На этапе 7.7 «Проведение опытной эксплуатации» проводят: опытную
эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку
(при необходимости) программного обеспечения АС; дополнительную наладку
(при необходимости) технических средств АС; оформление акта о завершении
опытной эксплуатации.
На этапе 7.8 «Проведение приемочных испытаний» проводят:
 испытания на соответствие техническому заданию в соответствии с
программой и методикой приемочных испытаний;
 анализ результатов испытаний АС и устранение недостатков, выяв-
ленных при испытаниях;
 оформление акта о приемке АС в постоянную эксплуатацию.
На этапе 8.1 «Выполнение работ в соответствии с гарантийными обяза-
тельствами» осуществляют работы по устранению недостатков, выявленных
при эксплуатации АС в течение установленных гарантийных сроков, внесению
необходимых изменений в документацию на АС.
На этапе 8.2 «Послегарантийное обслуживание» осуществляют работы по:
 анализу функционирования системы;
 выявлению отклонений фактических эксплуатационных характери-
стик АС от проектных значений;
 установлению причины этих отклонений;

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

309
 ПРИЛОЖЕНИЕ 3
ПРИМЕР ПЕРЕЧНЯ ПЕРВИЧНЫХ ДОКУМЕНТОВ
Унифицированные формы первичных учетных документов
Перечень форм документов класса 03 Общероссийского классификатора
управленческой документации (ОКУД) «Унифицированная система первичной
учетной документации»
№ Код формы Наименование формы документа
1 0306001 Акт о приеме-передаче объекта основных средств (кроме зданий,
сооружений)
2 0306002 Акт о приеме-сдаче отремонтированных, реконструированных,
модернизированных объектов основных средств
3 0306003 Акт о списании объекта основных средств (кроме автотранспорт-
ных средств)
4 0306004 Акт о списании автотранспортных средств

5 0306030 Акт о приеме-передаче здания (сооружения)

6 0306031 Акт о приеме-передаче групп объектов основных средств (кроме

зданий, сооружений)
7 0306032 Накладная на внутреннее перемещение объектов основных
средств
8 0306033 Акт о списании групп объектов основных средств (кроме авто-
транспортных средств)
9 0310001 Приходный кассовый ордер

10 0310002 Расходный кассовый ордер

11 0310003 Журнал регистрации приходных и расходных кассовых ордеров

12 0315004 Акт о приемке материалов

13 0315006 Требование-накладная

14 0315007 Накладная на отпуск материалов на сторону

15 0340002 Путевой лист строительной машины

16 0345001 Путевой лист легкового автомобиля

17 0345002 Путевой лист специального автомобиля

18 0345004 Путевой лист грузового автомобиля

19 0345005 Путевой лист грузового автомобиля

20 0345007 Путевой лист автобуса необщего пользования

310
 Перечень форм документов класса 05 ОКУД «Унифицированная система
финансовой, учетной и отчетной бухгалтерской документации бюджетных
учреждений и организаций»
№ Кодформы Наименование формы документа
1 0504143 Акт о списании мягкого и хозяйственного инвентаря

2 0504144 Акт о списании исключенной из библиотеки литературы

3 0504202 Меню-требование на выдачу продуктов питания

4 0504203 Ведомость на выдачу кормов и фуража

5 0504210 Ведомость выдачи материальных ценностей на нужды учрежде-

ния
6 0504230 Акт о списании материальных запасов

7 0504401 Расчетно-платежная ведомость

8 0504403 Платежная ведомость

9 0504417 Карточка-справка

10 0504421 Табель учета использования рабочего времени и расчета заработ-

ной платы
11 0504425 Записка-расчет об исчислении среднего заработка при предостав-
лении отпуска, увольнении и других случаях
12 0504501 Ведомость на выдачу денег из кассы подотчетным лицам

13 0504510 Квитанция

14 0504514 Кассовая книга

15 0504608 Табель учета посещаемости детей

16 0504805 Извещение

17 0504816 Акт о списании бланков строгой отчетности

18 0504817 Уведомление по расчетам между бюджетами

19 0504822 Уведомление о лимитах бюджетных обязательств

20 0504833 Справка

311
 СПИСОК ЛИТЕРАТУРЫ
Основная
1. Автоматизация управления предприятием / В. В. Баронов [и др.]. —
М. : ИНФРА-М, 2000. — 239 с. — (Cерия «Секреты менеджмента»).
2. Автоматизированные информационные технологии в экономике /
под ред. Г. А. Титоренко. — М. : Компьютер ; ЮНИТИ, 1998. — 400 с.
3. Авторское право: вебинар по правовым основам [Электронный ре-
сурс] // Интегрированная образовательная среда Adobe Connect Pro. — Режим
доступа: http://connect.mubint.ru/p43385458/.
4. Александров, А. А. Техническое нормирование труда на автомобиль-
ном транспорте. — М. : Транспорт, 1976. — 152 с.
5. Вейцман, В. М. Информационные системы в экономике : учеб. посо-
бие. — Ярославль : МУБиНТ, 1999. — 120 c.
6. Вейцман, В. М. Моделирование и разработка баз данных экономиче-
ских информационных систем : монография / В. М. Вейцман, Т. П. Никитина //
Международная академия бизнеса и новых технологий (МУБиНТ). — Яро-
славль : РИО Академии МУБиНТ, 2010. — 204 с.
7. Вендров, А. М. CASE-технологии. Современные методы и средства
проектирования информационных систем. — М. : Финансы и статистика,
1998. — 170 с.
8. ГОСТ 34.201-89. Государственный стандарт Союза ССР. Информа-
ционная технология. Комплекс стандартов и руководящих документов на авто-
матизированные системы. Виды, комплектность и обозначение документов при
создании автоматизированных систем (утв. Постановлением Госстандарта
СССР от 24.03.1989 № 664) (ред. от 01.12.1990). — М. : Издательство стандар-
тов, 1991.
9. Информационная технология: комплекс стандартов на автоматизи-
рованные системы (ГОСТ 34.201-89, ГОСТ 34.602-89, РД 50-682-89, РД 50-680-
88, ГОСТ 34.601-90, ГОСТ 34.401-90, РД 50-34.698-90, ГОСТ 34.003-90 и др.).
10. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Про-
цессы жизненного цикла программных средств.
11. Информационные системы в экономике / под ред. В. В. Дика. — М. :
Финансы и статистика, 1996. — 272 с.
12. Кастеллани, К. Автоматизация решения задач управления. — М. :
Мир, 1982. — 472 с.
13. Колянов, Г. Н. Консалтинг при автоматизации предприятий: подхо-
ды, методы, средства. — М. : СИНТЕГ, 1997. — 316 с. — (Серия «Информати-
зация России на пороге XXI века»).
14. Марка, Д. А. Методология структурного анализа и проектирования :
пер. с англ. / Д. А. Марка, К. МакГоуэн. — М. : МетаТехнология, 1993. — 240 с.
15. Мельников, В. В. Защита информации в компьютерных системах. —
М. : Финансы и статистика, 1997. — 368 с.

312
 16. Мишенин, А. И. Теория экономических информационных систем :
учебник. — 4-е изд., перераб. и доп. — М. : Финансы и статистика, 1999. —
240 с.
17. Саков, А. А. Унификация управленческой документации и общесо-
юзные классификаторы. — М. : Экономика, 1982. — 168 с.
18. Смирнова, Г. Н. Проектирование экономических информационных
систем : учеб. пособие / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. — М. :
Финансы и статистика, 2001. — 512 с.
19. Федеральное государственное унитарное предприятие Главный меж-
региональный центр обработки и распространения статистической информации
Федеральной службы государственной статистики (ГМЦ Росстата) : официаль-
ный сайт [Электронный ресурс]. — Режим доступа: www.gmcgks.ru/.
20. Федорова, Г. С. Проектирование информационных систем : учеб. по-
собие. — М. : МЭСИ, 2001. — 142 с.
21. Хотяшов, Э. Н. Проектирование машинной обработки экономиче-
ской информации. — М. : Финансы и статистика, 1987. — 246 с.
22. Шуремов, Е. Л. Информационные системы управления предприятия-
ми / Е. Л. Шуремов, Д. В. Чистов, Г. В. Лямова. — М. : Изд-во «Бухгалтерский
учет», 2006. — 112 с.
Дополнительная
23. Аверин, С. Финансовый анализ деятельности предприятий // PC
Week/Re. — 2001. — № 11. — 27 марта.
24. Вейцман, В. М. Автоматизация и организация образовательного про-
цесса на базе корпоративной информационной системы / В. М. Вейцман,
В. С. Иванов // Образование в информационную эпоху : сб. материалов Между-
нар. конф., Москва, 13 июня 2001 г. — М., 2001. — С. 14–17.
25. Вейцман, В. М. Некоторые аспекты управления образовательным
учреждением в информационную эпоху / В. М. Вейцман, В. С. Иванов // Обра-
зование в информационную эпоху : сб. материалов Междунар. конф., Москва,
13 июня 2001 г. — М., 2001. — С. 18–20.
26. Йордон, Э. О важности переоценки // Computerworld Россия — Ди-
ректору информационной службы. — 2000. — Июнь. — С. 31.
27. Колесников, С. Н. Как организовать проект внедрения [Электронный
ресурс] // CITFORUM. — Режим доступа: http://citforum.amursu.ru/cfin/articles/
organize.shtml.
28. Либерзон, В. Основные понятия и процессы управления проектами //
Computerworld Россия — Директору информационной службы. — 2000. —
Март. — С. 24–29.
29. Манцевич, Н. Проекты, инструменты и управление организацией /
Н. Манцевич, Д. Тимченко // Computerworld Россия — Директору информаци-
онной службы. — 2000. — Июнь. — С. 10–12.

313
 ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ .............................................................................................................. 3
ТЕМА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ
ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ ..................................... 4
1.1. Основные понятия предметной области ...................................................... 4
1.2. Архитектура ЭИС ........................................................................................ 10
1.3. Общие принципы, определяющие идеологию построения ЭИС .............. 17
1.4. Основы методологии проектирования ЭИС .............................................. 20
1.5. Классификация основных методов проектирования ................................. 28
1.6. Вопросы для самопроверки ........................................................................ 30
ТЕМА 2. ОРГАНИЗАЦИЯ КАНОНИЧЕСКОГО ПРОЕКТИРОВАНИЯ
ЭИС ......................................................................................................................... 31
2.1. Состав проектной документации................................................................ 32
2.2. Взаимодействие пользователя и разработчиков ЭИС на стадиях
и этапах процесса проектирования ................................................................... 37
2.3. Вопросы для самопроверки ........................................................................ 38
ТЕМА 3. СОДЕРЖАНИЕ РАБОТ НА СТАДИИ ИССЛЕДОВАНИЯ
ПРЕДМЕТНОЙ ОБЛАСТИ И ОБОСНОВАНИЯ ПРОЕКТНЫХ РЕШЕНИЙ
ПО СОЗДАНИЮ ЭИС ........................................................................................... 39
3.1. Цели и задачи предпроектной стадии создания ЭИС ............................... 39
3.2. Разработка технико-экономического обоснования создания ЭИС .......... 51
3.3. Разработка технического задания на создание ИС (ГОСТ 34.602-89) ..... 54
3.4. Вопросы для самопроверки ........................................................................ 56
ТЕМА 4. ПРОЕКТИРОВАНИЕ ФУНКЦИОНАЛЬНОЙ ЧАСТИ ЭИС .............. 57
4.1. Декомпозиция функций ЭИС ..................................................................... 57
4.2. Описание постановки задач ........................................................................ 59
ТЕМА 5. МЕТОДЫ И СРЕДСТВА СОВЕРШЕНСТВОВАНИЯ
ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ....... 63
5.1. Методология структурного анализа и проектирования ЭИС ................... 63
5.2. Методология объектно-ориентированного подхода к анализу и
проектированию КИС ........................................................................................ 91
Операции .......................................................................................................... 110
5.3. Сопоставление и взаимосвязь структурного и объектно-
ориентированного подходов ............................................................................ 114
ТЕМА 6. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ
ЭИС ....................................................................................................................... 118
6.1. Состав, содержание и принципы организации информационного
обеспечения ЭИС ............................................................................................. 118
6.2. Классификаторы и коды: проектирование и технология
применения ....................................................................................................... 120
6.3. Системы документации............................................................................. 147
6.4. Внутримашинное информационное обеспечение ................................... 157
6.5. Вопросы для самопроверки ...................................................................... 174

314
ТЕМА 7. ПРОЕКТИРОВАНИЕ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ
ОБРАБОТКИ ИНФОРМАЦИИ В ЭИС .............................................................. 176
7.1. Основные понятия и классификация технологических процессов
обработки экономической информации ......................................................... 176
7.2. Автоматизация ввода бумажных документов ......................................... 183
7.3. Технология обеспечения достоверности данных и безопасности
компьютерных систем ..................................................................................... 186
7.4. Проектирование технологических процессов обработки данных .......... 197
7.5. Вопросы для самопроверки ...................................................................... 203
ТЕМА 8. АВТОМАТИЗАЦИЯ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЙ И
ОРГАНИЗАЦИЙ .................................................................................................. 204
8.1. Классификация систем автоматизации управления ................................ 204
8.2. Требования к обработке различных видов информации в ЭИС ............. 208
8.3. Современные модели построения систем управления предприятием.
Концепция MRP, MRP II, ERP ........................................................................ 217
8.4. Автоматизированные рабочие места (АРМ) ............................................ 224
8.5. Корпоративные информационные системы............................................. 226
8.6. Вопросы для самопроверки ...................................................................... 233
ТЕМА 9. ТИПОВОЕ И ПРОТОТИПНОЕ ПРОЕКТИРОВАНИЕ ЭИС ............ 234
9.1. Типовое проектирование .......................................................................... 234
9.2. Прототипное проектирование ЭИС (RAD-технология) .......................... 236
9.3. Вопросы для самопроверки ...................................................................... 238
ТЕМА 10. ВЫБОР И РАЗВИТИЕ ЭИС ПРЕДПРИЯТИЯ
ИЛИ ОРГАНИЗАЦИИ ......................................................................................... 239
10.1. Основные критерии выбора системы ..................................................... 239
10.2. Совокупная стоимость владения ............................................................ 242
ТЕМА 11. CASE-ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ КИС ......................... 247
11.1. CASE-модель жизненного цикла ИС ..................................................... 247
11.2. Состав, структура и функциональные особенности CASE-средств ..... 250
11.3. Классификация и выбор CASE-средств ................................................. 255
11.4. CASE-средства Platinum Technology ...................................................... 266
11.5. CASE-средства Rational Rose .................................................................. 273
ТЕМА 12. МЕТОДЫ АВТОМАТИЗАЦИИ ПРОЕКТИРОВАНИЯ КИС ......... 279
12.1. Настраиваемые системы ......................................................................... 280
12.2. Системы-трансформеры .......................................................................... 290
ПРИЛОЖЕНИЕ 1 АВТОРСКОЕ ПРАВО. ГРАЖДАНСКИЙ КОДЕКС,
ЧАСТЬ 4. .............................................................................................................. 304
ПРИЛОЖЕНИЕ 2 СПРАВОЧНО. ВЫДЕРЖКИ ИЗ ГОСТ 34.601-90 .............. 306
ПРИЛОЖЕНИЕ 3 ПРИМЕР ПЕРЕЧНЯ ПЕРВИЧНЫХ ДОКУМЕНТОВ ........ 310
СПИСОК ЛИТЕРАТУРЫ .................................................................................... 312

315
 Владимир Моисеевич ВЕЙЦМАН
ПРОЕКТИРОВАНИЕ
ИНФОРМАЦИОННЫХ СИСТЕМ
Учебное пособие

Зав. редакцией
литературы по информационным технологиям
и системам связи О. Е. Гайнутдинова
Ответственный редактор Т. С. Спирина
Подготовка макета Э. Я. Юзеев
Корректор А. В. Финкельштейн
Выпускающий Н. А. Крылова

ЛР № 065466 от 21.10.97
Гигиенический сертификат 78.01.10.953.П.1028
от 14.04.2016 г., выдан ЦГСЭН в СПб
Издательство «ЛАНЬ»
lan@lanbook.ru; www.lanbook.com
196105, СанктПетербург, пр. Юрия Гагарина, д. 1, лит. А
Тел./факс: (812) 3362509, 4129272
Бесплатный звонок по России: 88007004071

ГДЕ КУПИТЬ
ДЛЯ ОРГАНИЗАЦИЙ:
Для того, чтобы заказать необходимые Вам книги, достаточно обратиться
в любую из торговых компаний Издательского Дома «ЛАНЬ»:
по России и зарубежью
«ЛАНЬТРЕЙД». 196105, СанктПетербург, пр. Юрия Гагарина, д. 1, лит. А
тел.: (812) 4128578, 4121445, 4128582; тел./факс: (812) 4125493
email: trade@lanbook.ru; ICQ: 446869967
www.lanbook.com
пункт меню «Где купить»
раздел «Прайслисты, каталоги»
в Москве и в Московской области
«ЛАНЬПРЕСС». 109387, Москва, ул. Летняя, д. 6
тел.: (499) 7227230, (495) 6474077; email: lanpress@lanbook.ru
в Краснодаре и в Краснодарском крае
«ЛАНЬЮГ». 350901, Краснодар, ул. Жлобы, д. 1/1
тел.: (861) 2741035; email: lankrd98@mail.ru
ДЛЯ РОЗНИЧНЫХ ПОКУПАТЕЛЕЙ:
интернет6магазин
Издательство «Лань»: http://www.lanbook.com
магазин электронных книг
Global F5: http://globalf5.com/
Подписано в печать 26.06.19.
Бумага офсетная. Гарнитура Школьная. Формат 70×100 1/16.
Печать офсетная. Усл. п. л. 25,68. Тираж 100 экз.

Заказ № 45219.
Отпечатано в полном соответствии с качеством
предоставленного оригиналмакета в АО «Т8 Издательские Технологии».
109316, г. Москва, Волгоградский пр., д. 42, к. 5.