Теория и практика бизнес-анализа в ИТ. В 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 Diagram»); 
o модель деятельности (англ. «Activity Diagram»); 
o модель конечного автомата (англ. «State Machine 
Diagram»); 
o модель последовательности (англ. «Sequence Diagram»); 
o модель коммуникаций (англ. «Communication Diagram»); 
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