Теория и практика бизнес-анализа в ИТ. В 2 т. Т.1

ИНСТИТУТ ПРОГРАММНЫХ СИСТЕМ РАН 

А. А. Цветков 

Теория и практика  
бизнес-анализа в ИТ 

Том I 

Учебное пособие

Москва 
Берлин 
2019 

УДК 339.1:658(075)  
ББК 65.29я7 

Решением Ученого Совета Института программных систем  
им. А. К. Айламазяна РАН от 12 декабря 2018 г. 
учебное пособие рекомендовано к печати 

Рецензенты: 
Александрова Ирина Алексеевна, кандидат технических наук; 
Непейвода Николай Николаевич, доктор физико-математических наук, 
профессор 
В оформлении обложки использовалась гравюра А. Дюрера «Меланхолия».

Цветков, А. А. 

Е 67      Теория и практика бизнес-анализа :  учебное  пособие.  В 2 т. 
Т. I / А. А. Цветков. – Москва ; Берлин : Директ-Медиа, 2019. – 150 с. 
DOI: 10.23681/500835

ISBN 978-5-4475-8152-7 
Разработка информационных и автоматизированных систем является сложным технологическим 
процессом, который требует участия в нем группы специалистов, выполняющих 
различные роли, и, имеющих различные специализации. В настоящее время 
сложилась парадоксальная ситуация, при которой, несмотря на множество нормативно-
справочной информации, которая разбросана в разных документах ( законодательных, 
регламентирующих, рекомендующих), в каждой организации по-своему трактуют, чем 
именно должен заниматься тот или иной специалист, входящий в группу разработки. 

Настоящая книга «Теория и практика бизнес-анализа в ИТ» является первым из двух 
томов, в которой подробно описана роль бизнес-аналитика в группе разработки, включая 
описание того, ЧТО, КАК, ГДЕ, с КЕМ, КОГДА и ПОЧЕМУ он должен делать на 
протяжении жизненного цикла информационной или автоматизированной системы. 
Приводится подробное описание инструментов бизнес-аналитика: нотации описания 
модели бизнес-процессов (BPMN) и нотации моделей «Сущность-связь» (ERD) для описания 
данных. Нотации приводятся в соответствии с оригинальными документами Ob-
ject Management Group (OMG), т. е. документами международного консорциума, на 
основе которых формируются международные стандарты ИСО/МЭК. 

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

В приложении приводится справочник по полной нотации BPMN. 
В основу книги положен практический опыт разработки аналитических моделей автором 
и его коллегами, а также курс лекций, читавшийся студентам в рамках курса «Ин-
формационные системы». Учебное пособие публикуется  в авторской редакции.

УДК 339.1:658(075)  
ББК 65.29я7 

ISBN 978-5-4475-8152-7      © Цветков А. А., текст, 2019

© Издательство «Директ-Медиа», макет, оформление, 2019

Оглавление 

Предисловие автора ................................................................................ 5 

Как читать эту книгу ..............................................................................10 

Глава 1. Введение в разработку ИС ...................................................12 

a.
Понимание термина «Информационная система» ............12

b.
Классификация ИС ....................................................................17

c.
Нормативно-справочная информация ..................................18

d.
Выводы ...........................................................................................24

e.
Вопросы и задачи для повторения материала .....................24

Глава 2 Методики разработки ИС .....................................................25 

a.
Диаграмма Захмана .....................................................................25

b.
Модели жизненного цикла .......................................................34

c.
Выводы ...........................................................................................49

d.
Вопросы и задачи для повторения материала .....................51

Глава 3. Теоретические основы нотаций моделирования ...........53 

Глава 4. Нотация моделирования 
бизнес-процессов (BPMN) ..................................................................59 

a.
Введение в нотацию BPMN .....................................................59

b.
«Правильные слова» в BPMN ...................................................61

c.
Базовые элементы BPMN ..........................................................63

d.
Исполняемый частный (внутренний)
бизнес-процесс. Пример...................................................................68 

e.
Неисполняемый частный (внутренний)
бизнес-процесс. Пример...................................................................69 

f.
Публичный бизнес-процесс. Пример ...................................70

g.
Хореография. Пример ...............................................................71

3 

h.
Подмодель «Соглашения». Пример ....................................... 72

i.
Методика моделирования в нотации BPMN ....................... 75

j.
Выводы ........................................................................................ 103

k.
Вопросы и задачи для повторения материала ................... 104

Глава 5. Нотация моделей сущность-связь (ERD) ...................... 106 

a.
Краткое введение в теорию БД ............................................. 106

b.
Нотация модели «Сущность-связь» ...................................... 107

c.
Типы моделей ERD.................................................................. 118

d.
Выводы или «Как разработать ERD» ................................... 123

e.
Вопросы и задачи для повторения материала ................... 124

Заключение к Тому I .......................................................................... 126 

Приложение 1. Элементы нотации BPMN ................................... 127 

Список терминов и сокращений ..................................................... 145 

Список литературы ............................................................................. 146 

Об авторе ............................................................................................... 149 

ПРЕДИСЛОВИЕ АВТОРА 

Революцией во многих областях человеческой деятельности 
или, как скажет профессиональный бизнес-аналитик, в различных «
предметных областях» стало массовое появление персональных 
компьютеров. 
Автор еще помнит времена, когда для того, чтобы рассчитать 
свою задачу приходилось делать множество вещей, о которых 
многие современные пользователи даже не догадываются: 
нужно было математизировать свою задачу (самому, если умеешь, 
или обратиться к специалисту, как тогда говорили – постановщику), 
нужно было написать программный код (самому, 
если умеешь, или обратиться к программисту), нужно было 
написать задание для электронной вычислительной машины 
(далее – ЭВМ) (самому, если умеешь, или обратиться к специалисту – 
обычно с этим справлялись сами программисты, но были 
и отдельные специалисты – системщики), а еще записаться в 
очередь на машинное время, дождаться результатов, которые с 
первого раза были с ошибками, и опять пойти по всем кругам 
компьютерного ада… Т. е., если специалист был, например, 
биологом или статистиком, то ему приходилось найти доста-
точно убедительные аргументы, чтобы убедить себя и руковод-
ство – мне действительно необходимо в своих работах 
использовать компьютерные вычисления. 
Первые, действительно массовые персональные компьюте-
ры (далее – ПК) по нынешним меркам содержали не так много 
инструментов (простые текстовый редактор и электронная таб-
лица, система управления базой данных, редакторы кода и ком-
пиляторы для различных языков, которых тоже было не так 
много – C/C++, Pascal, …). Но это уже было настоящим чудом: 
прямо перед тобой устройство, которое заменяет большую 
ЭВМ, и … делай, что хочешь. 
Но ПК сыграли и плохую шутку с пользователями. Если 
раньше нужно было сто раз подумать о том, ЧТО и КАК ты 
будешь делать, то теперь можно было сразу переходить к увле-
кательнейшему занятию: писать код. Это действительно увлека-
тельно: изучить язык программирования сильно проще, чем, 
например, английский или китайский, написать несколько 

5 

строк кода и вот оно: на экране интерфейс пользователя, можно 
нажимать кнопки, что-то там происходит, … Начинаешь чув-
ствовать себя гением или даже Создателем: вот мир, который ты 
создал, и который живет по твоим законам. Но это было до по-
ры, пока задачки были простые и однопользовательские. 
А дальше стало веселее: стали доступны сети, появилась по-
требность делать распределенные приложения уровня отдела, 
предприятия, холдинга, … Нужна единая архитектура, бизнес-
модели, системные модели, … Одним словом – ДОКУМЕН-
ТАЦИЯ. И не просто документация, а реальный план того, что 
будет сделано или уже сделано. И документация, которая будет 
понятна всем специалистам, которые работают в области раз-
работки информационных систем (далее – ИС) и программного 
обеспечения (далее – ПО), входящего в состав ИС. Но господа 
специалисты по кодированию, которые никогда и не думали 
документировать свой код1, и, решившие, что они главные в 
процессе создании ПО, уже создали в голове потенциальных 
заказчиков устойчивый стереотип: разработчик ИС и ПО – это 
некто, который сидит за ПК и пишет код. А еще какие-то сотрудники, 
которые после кодировщика задокументируют его 
труды и издадут, в лучшем случае, руководство системного администратора 
и руководство пользователя. 
К чему это приводит отражено на известном многим поколениям 
программистов рисунке (см. ниже). Смеются, но … делают 
по-своему. 
Конечно, существуют документы, в которых написано, КАКИЕ 
документы нужно разрабатывать, чтобы разработка была 
успешной – это основные ГОСТы 34-й и 19-й серий. Но в 
настоящее время есть «маленькая» особенность. Если в СССР в 
ГОСТах писали «Несоблюдение преследуется по закону», то 
теперь ГОСТ «рекомендует», но разве, что за исключением 
ГОСТов, которые используют военные – там все строго: если в 
ГОСТ написано, то это обязательно к применению. Вот эту 
«маленькую» особенность и используют нынешние разработ-

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

6 

чики, как лазейку, чтобы делать не так, как надо, а как удобно 
тем, кто пишет код. 

Рисунок 1 – Процесс разработки [1]2 

2 Не хотел вставлять этот рисунок – он уже всем порядком надоел. Но… ничего не 
меняется. 

7 

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

8 

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

КАК ЧИТАТЬ ЭТУ КНИГУ 

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

10 

составляющих: графическое моделирование в одной из нота-
ций и формализованное описание этих моделей. Т. е. для 
выполнения заданий читателю понадобится какой-либо ин-
струмент, который позволяет выполнить моделирование. Автор 
не будет обсуждать достоинства и недостатки существующих 
инструментальных средств – главное это то, чтобы инструмент 
моделирования поддерживал в полном объеме те нотации, ко-
торые разработаны в Object Management Group, т. е. организа-
ции-авторе спецификаций BPMN, UML, ERD, и, которые 
являются де-факто международными стандартами (для части из 
нотаций, например, BPMN, разработан и стандарт ИСО/МЭК, 
который полностью повторяет спецификацию Object Manage-
ment Group). Могу только порекомендовать использовать 
для моделирования такой инструмент, как Visual Paradigm3 
(см. https://www.visual-paradigm.com/), на котором автор сделал 
большую часть иллюстративного материала книги. 
Моделирование в бизнес-аналитике держится на «трех сло-
нах» или нотациях: нотация бизнес-процессов и модели 
(BPMN), универсальный язык моделирования (UML), диаграм-
мы «сущность-связь» (ERD). Объем и сложность материала 
предопределили то, как построен материал настоящей книги: 
предполагается издание двух томов под общим названием 
«Теория и практика бизнес-анализа в ИТ». В настоящем томе 
читателю предстоит освоить следующие разделы: 
•
«Глава 1. Введение в разработку ИС»;
•
«Глава 2. Методики разработки ИС»;
•
«Глава 3. Теоретические основы нотаций моделирова-
ния»; 
•
«Глава 4. Нотация моделирования бизнес-процессов
(BPMN)»; 
•
«Глава 5. Нотация моделей сущность-связь (ERD)».
Второй том будет посвящен моделированию в нотации 
UML, формированию пользовательских сценариев и прототи-
пированию пользовательских интерфейсов. 

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

ГЛАВА 1 
ВВЕДЕНИЕ В РАЗРАБОТКУ ИС 

«Прежде чем спорить, давайте 
договоримся о терминах». 
Франсуа Мари Аруэ (Вольтер) 

•
Понимание термина «Информационная система»
•
Классификация ИС
•
Нормативно-справочная информация
•
Выводы

A. Понимание термина «Информационная система» 

Существует старая байка, когда некий философ начинает, 
как говорят в народе, «философствовать»: «Вы спрашиваете меня, 
что такое наука? А давайте разберемся в том, что такое 
«спрашиваете», что такое «Вы», что такое «Я», наконец, что такое 
«Что»….». Ну, так можно далеко уйти, подменяя пространными 
рассуждениями основную тему разговора. Основной темой книги 
является, если кто забыл, «Теория и практика бизнес-анализа 
в информационных технологиях», т. е. ключевыми понятиями 
для нас являются «бизнес-анализ» (далее – БА) и «информационные 
технологии» (далее – ИТ). И, конечно же, то, посредством 
чего ИТ могут быть реализованы – «информационная 
система». 
На пояснении того, что есть БА и кто такие специалисты, 
которые выполняют этот процесс, т. е. «бизнес-аналитики», мы 
остановимся ниже. Начнем с однозначного понимания терминов «
технология», «информация» и «система». 
Термин «Технология» происходит от древнегреческих слов: 
τέχνη – «искусство», «мастерство», «умение» и λόγος – «слово», 
«мысль», «смысл», «понятие». Можно было бы интерпретиро-

12