Теория и практика бизнес-анализа в ИТ. В 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) для описания данных. Нотации приводятся в соответствии с оригинальными документами Object 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