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

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

А. А. Цветков 

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

Том II 

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

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

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

Решением Ученого Совета Института программных систем  

им. А. К. Айламазяна РАН учебное пособие рекомендовано к печати 

Рецензенты: 
Александрова Ирина Алексеевна, кандидат технических наук; 

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

Цветков, А. А. 
Е 67      Теория и практика бизнес-анализа :  учебное  пособие.  В 2 т. 
  Т. II / А. А. Цветков. – Москва ; Берлин : Директ-Медиа, 2020. – 
  99 с. : ил. 
ISBN 978-5-4499-0006-7 

Настоящая книга «Теория и практика бизнес-анализа в ИТ. Том II» 
является продолжением описания особенностей работы бизнес-аналитика, 
изложенных в I-м томе. 
Приводится подробное описание инструментов бизнес-аналитика, 
которые не вошли в I-й том: нотация унифицированного языка моделирования (
UML) в объеме, который необходим бизнес-аналитику (модели «Варианты 
использования» и «Диаграмма последовательностей»), и описание 
особенностей моделирования пользовательского интерфейса. Нотации приводятся 
в соответствии с оригинальными документами Object Management 
Group (OMG), т. е. документами международного консорциума, на основе 
которых формируются международные стандарты ИСО/МЭК. 
Раздел книги, посвященный UML, снабжен заданиями для повторения 
и усвоения изученного материала. 
В приложении приводится справочник по нотации UML. 
В основу книги положен практический опыт разработки аналитических 
моделей автором и его коллегами, а также курс лекций, читавшийся 
студентам в рамках курса «Информационные системы». 
Настоящая книга рекомендована в качестве учебного и справочного 
пособия для студентов магистратур и аспирантов, которые обучаются по 
специальностям, связанным с информатикой и смежными дисциплинами, в 
соответствии с решением Ученого Совета Института программных систем 
им. А. К. Айламазяна РАН от «12» 2018 г. 

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

ISBN 978-5-4499-0006-7
© Цветков А. А., текст, 2020
© Издательство «Директ-Медиа», макет, оформление, 2020 

Оглавление 

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

ГЛАВА 1. Нотация унифицированного  языка 
моделирования (UML) .............................................................................. 8 

a. Введение в UML .................................................................. 8

b. Модель «Варианты использования»
(Use Case Diagram) ................................................................................12 

c. Модель «Последовательность»
(Sequence Diagram) ................................................................................29 

i. Элемент «Инициирующее сообщение» ......................33

ii. Элемент «Возвращаемое сообщение» ..........................35

iii. Элемент «Внутреннее сообщение» ...........................36

iv. Элемент «Рекурсивное сообщение» .........................37

v. Элемент «Порождающее сообщение» .....................39

vi. Элемент «Уничтожающее сообщение» ...................41

vii. Элемент «Длительное сообщение» ..........................42

viii. Элементы «Фрагменты последовательностей» ......43

1.
Альтернативные фрагменты
последовательностей (англ. Alternative Sequence Fragments) .44 

2.
Возможный фрагмент последовательностей
(англ. Optional Sequence Fragments) .............................................46 

3.
Параллельные фрагменты последовательностей
(англ. Parallel Sequence Fragments) ................................................48 

4.
Циклический фрагмент последовательностей
(англ. Loop Sequence Fragments) ...................................................49 

5.
Фрагмент последовательностей критического
участка (англ. Critical Region Sequence Fragments) .....................52 

3 

6.
Недопустимый фрагмент последовательностей
 (англ. Negative Sequence Fragments) ............................................ 53 

7.
Ссылка на фрагмент последовательностей
(англ. Reference Sequence Fragments) ........................................... 54 

8.
Диаграмма последовательностей
(англ. Sequence Diagram) .................................................................... 60 

ix. Элемент «Продолжение» (англ. Continuation) ........ 63

d. Выводы к ГЛАВЕ 1 .......................................................... 66

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

ГЛАВА 2. Взглянуть глазами пользователя. 
Прототипирование интерфейсов ....................................................... 69 

a. Определение экранных и печатных форм ................. 71

b. Выбор технологии реализации ..................................... 72

c. Компоновка экранных форм ......................................... 75

d. Презентация концепта
информационной системы ................................................................ 80 

e. Выводы к ГЛАВЕ 2 .......................................................... 83

Заключение к тому II ................................................................ 84 

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

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

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

Об АВТОРЕ ................................................................................ 98 

ПРЕДИСЛОВИЕ АВТОРА КО ВТОРОМУ ТОМУ 

В предыдущем томе были изложены основные понятия, 
описывающие бизнес-анализ (далее – БА), которые включали 
понимание того, для чего БА проводится, т. е. введение в разра-
ботку информационных систем (далее – ИС), а также описаны 
информационные бизнес-процессы (далее – ИБП), которые 
выполняются в процессе разработки ИС. В качестве плана дей-
ствий1, который используется при разработке, использовалась 
диаграмма Захмана, доказавшая на протяжении десятков лет 
свою корректность и эффективность. Основной упор делался 
на ИБП бизнес-аналитика, включая его взаимодействие с 
остальными участниками проектной группы и заказчиком ИС.  
Можно сказать, что бизнес-аналитик является двуликим 
Янусом: одно лицо обращено к заказчику, а другое – к проект-
ной группе, но мозг один, в задачи которого входит понять то, 
ЧТО хочет заказчик, решить, КАК должна выглядеть ИС, чтобы 
воплотить мечты заказчика (насколько это возможно) в дей-
ствительность, отразить свое решение в виде, который позво-
лит проектной группе реализовать эти «ЧТО» и «КАК». По 
сути, бизнес-аналитик – это внутренний заказчик, который по-
стоянно взаимодействует со своими коллегами в процессе раз-
работки 
ИС, 
но 
для 
заказчика – 
это 
представитель 
разработчика, который вместе с руководителем проекта получа-
ет за всю группу либо восторги, либо негатив. 
Для того, чтобы документы, которые разрабатывает биз-
нес-аналитик, были максимально прозрачны для понимания, 
они должны содержать два компонента: текстовый и графиче-
ский. При этом графический компонент – это не произвольная 
картинка, а модель, которая формируется в соответствии со 
стандартными нотациями, часть из которых была рассмотрена в 
предыдущем томе: нотация модели бизнес-процессов (далее – 
BPMN) и модель «Сущность-связь» (далее – ERD).  

1 Автор категорически против прямых калек с англоязычной литературы, кото-
рые засоряют и искажают русский язык. В частности, такое словосочетание, как «до-
рожная карта». Зачем? Чем не устраивает наш родной «план действий»? Давайте 
беречь родной язык. 

5 

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

2 Никто не мешает знать UML в полном объеме – приходится ограничиваться в 
данной книге, т. к. полное описание UML потребовало бы отдельной книги, а может 
и не одной… 

6 

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

ГЛАВА 1. 
 
НОТАЦИЯ УНИФИЦИРОВАННОГО 
 ЯЗЫКА МОДЕЛИРОВАНИЯ (UML) 

• 
Введение в UML 
• 
Модель «Вариант использования» (Use Case Diagram) 
• 
Модель «Последовательность» (Sequence Diagram) 
• 
Выводы 
 
 

A. Введение в UML 

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

8 

ботают нечто, что зачастую полностью расходится с проектом. 
А дальше… Из-за необходимости переделок срываются сроки 
разработок и начинаются авральные работы, нервотрепка и т. п. 
«прелести», как следствие невежества. Еще одна неприятная си-
туация – члены группы разработки «как бы» знают UML, но, 
как-то по-своему, т. е., например, в соответствии с нотацией 
стрелка показывает, что этот модуль входит в состав некоторого 
агрегата (элемент «включение» или, если по-английски «include» 
(см. описание элемента далее)), а интерпретация «грамотея» бу-
дет такой: агрегат передает данные или управление модулю. Но 
вся проблема в том, что модуль – это часть агрегата… Если об-
ратиться к машиностроению, то это будет равносильно декла-
рации, 
что 
шестеренка, 
входящая 
в 
механизм, 
живет 
собственной насыщенной жизнью. Без комментариев. 
Разработчики ИС рассматривают ее с разных сторон в со-
ответствии с их ролью в группе. Это могут быть, например: 
• аналитики; 
• дизайнеры; 
• программисты; 
• тестировщики; 
• специалисты по качеству; 
• технические писатели и др. 
Для выполнения своих функций, каждому из специалистов 
нужно свое представление моделей ИС. Существует известная 
шутка: у руководителя проекта спросили почему 
документация содержит двадцать комплектов моделей системы, 
неужели система настолько сложная; на что он ответил – все 
потому, что в группе работает двадцать аналитиков. 
Именно необходимость представления ИС в виде множества 
моделей, каждая из которых отражается специфический взгляд 
на систему, привела к тому, что в 1997 году появилась первая 
спецификация нотации UML, которая получила дальнейшее 
развитие и в настоящее время существует версия 2.5.1 (см. [3]). 
Парадигма «Представление ИС с разных сторон» в нотации 
UML реализована путем разбиения видов моделей на две большие 
группы: структурные модели (англ. «Structure diagrams»), 

9 

которые отражают статическую структуру ИС, и поведенческие 
модели (англ. «Behavior diagrams»), которые отражают динамику 
поведения объектов в ИС: 
• Структурные модели: 
o модель классов (англ. «Class Diagram»); 
o модель компонентов (англ. «Component Diagram»); 
o модель объектов (англ. «Object Diagram»); 
o модель развертывания (англ. «Deployment Diagram»); 
o модель пакетов (англ. «Package Diagram»); 
o модель композитной структуры (англ. «Composite 
Structure Diagram»); 
o модель профиля (англ. «Profile Diagram»); 
• 
Поведенческие модели: 
o модель вариантов использования (англ. «Use Case Dia-
gram»); 
o модель деятельности (англ. «Activity Diagram»); 
o модель конечного автомата (англ. «State Machine 
Diagram»); 
o модель последовательности (англ. «Sequence Dia-
gram»); 
o модель коммуникаций (англ. «Communication Dia-
gram»); 
o обзорная модель взаимодействий (англ. «Interaction 
Overview Diagram»); 
o временная модель (англ. «Timing Diagram»). 
Не все типы моделей, из перечисленных выше, требуются 
бизнес-аналитику для решения задач, стоящих перед ним. 
Напомним какие вопросы стоят перед бизнес-аналитиком в 
процессе взаимодействия с функциональным заказчиком и какую 
информацию необходимо передать системному аналитику3 

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

10 

                                                            

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

Ответ на вопрос «ЧТО» мы достаточно подробно рассмотрели 
в первом томе настоящего учебного пособия – это 
модели ERD. Т. е., согласно диаграмме Захмана, бизнес-
аналитиком 
должен 
быть 
подготовлен 
список 
бизнес-
сущностей и связей (или документ, который можно условно 
назвать «Учет представлений») в виде концептуальной модели в 
соответствии с нотацией ERD и соответствующим текстовым 
описанием, которое дополняет и однозначно интерпретирует 
модель данных. Согласно рекомендациям (или требованиям, 
если компания-разработчик твердо стоит на позиции соблюде-
ния ГОСТов) ГОСТ серии 34*, а именно документу РД 50–
34.698–90 «Методические указания. Информационная техноло-
гия. Комплекс стандартов и руководящих документов на авто-
матизированные 
системы. 
Автоматизированные 
системы. 
Требования к содержанию документов», список бизнес-
сущностей и связей или ссылка на документ, который содержит 
этот список, должен быть включен в документ «Пояснительная 
записка» в раздел «Основные технические решения».  

Ответы на вопросы «КАК», «ГДЕ», «КТО», «КО-

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

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

11 

                                                                                                                                    

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

B. Модель «Варианты использования»  
(Use Case Diagram) 

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

12