Проектирование информационных систем. Системная и бизнес-аналитика

Министерство образования и науки Российской Федерации 

НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ 
__________________________________________________________________________ 
 
 
 
 
 
А.В. КУГАЕВСКИХ 
 
 
ПРОЕКТИРОВАНИЕ  
ИНФОРМАЦИОННЫХ СИСТЕМ 
СИСТЕМНАЯ  
И БИЗНЕС-АНАЛИТИКА 
 
 
Утверждено Редакционно-издательским советом университета 
в качестве учебного пособия 
 
 
 
 
 
 
 
 
 
 
 
 
 
НОВОСИБИРСК 
2018 

ББК 65.291.216с51я73 
К 886 
 
 
Рецензенты:  
д-р физ.-мат. наук, директор ИСИ СО РАН А.Г. Марчук 
канд. техн. наук, зав. кафедрой ИТ НГУЭУ «НИНХ» А.Л. Осипов 
 
 
 
 
 
Кугаевских А.В. 
К 886       Проектирование информационных систем. Системная и бизнес-аналитика: учебное пособие / А.В. Кугаевских. – Новосибирск: Изд-во НГТУ, 2018. – 256 с. 

ISBN 978-5-7782-3608-0 

Пособие посвящено методам проведения системного и бизнесанализа при разработке ПО. Грамотно составленное описание предметной области и техническое задание – одна из составляющих обеспечения качества ПО. Но бизнес-аналитика не ограничивается только 
документированием бизнес-процессов, поэтому здесь рассмотрен 
процесс бизнес-анализа, приведены описания некоторых техник, позволяющих провести реинжиниринг. Приведены такие методики, как 
IDEF0, DFD, BPMN, ARIS eEPC, UML и IDEF1X. Представлены техники управления требованиями и техники написания ТЗ по шаблонам 
документа видения, спецификации требований к ПО и по ГОСТ 34. 
Для ГОСТ 19 и ГОСТ 34 приведены рекомендации по содержанию ТЗ 
применительно к современной классификации требований. 
Учебное пособие соответствует профессиональному стандарту 
«Системный аналитик». 
 
 
 
 
ББК 65.291.216с51я73 
 
ISBN 978-5-7782-3608-0 
© Кугаевских А.В., 2018 
 
© Новосибирский государственный
  
технический университет, 2018     

ОГЛАВЛЕНИЕ 
 
Предисловие ............................................................................................................ 5 
Глава 1. Аналитическое мышление .................................................................. 7 
Глава 2. Бизнес-анализ ...................................................................................... 13 
2.1. Процесс бизнес-анализа ............................................................................ 13 
2.2. Некоторые инструменты бизнес-анализа ................................................ 23 
Глава 3. Моделирование процессов ................................................................. 39 
3.1. Структурно-функциональное  моделирование и нотация IDEF0 ......... 39 
3.2. Диаграмма потоков данных (DFD) .......................................................... 45 
3.3. Процессное моделирование  и нотация BPMN ....................................... 48 
3.4. ARIS eEPC .................................................................................................. 72 
3.5. Практические задания ............................................................................... 77 
Глава 4. Процесс разработки ПО ..................................................................... 79 
4.1. Жизненный цикл ПО ................................................................................. 79 
4.2. Модели жизненного цикла ....................................................................... 82 
4.3. Методологии разработки ПО ................................................................... 97 
4.4. Унифицированный процесс .................................................................... 114 
4.5. Сопровождение ПО ................................................................................. 121 
4.6. Качество ПО............................................................................................. 122 
4.7. Практические задания ............................................................................. 128 
Глава 5. Требования ......................................................................................... 129 
5.1. Классификация требований .................................................................... 129 
5.2. Разработка требований ............................................................................ 134 
5.3. Управление требованиями ...................................................................... 150 
5.4. Практические задания ............................................................................. 152 
Глава 6. UML ..................................................................................................... 153 
6.1 Структура UML  и представление архитектуры ПО ............................. 153 
6.2. Диаграмма прецедентов .......................................................................... 162 
6.3. Диаграмма классов .................................................................................. 169 
6.4. Диаграмма объектов ................................................................................ 182 
6.5. Диаграмма пакетов .................................................................................. 183 
6.6. Диаграмма профилей .............................................................................. 185 
6.7. Диаграмма составных структур ............................................................. 186 

6.8. Диаграмма деятельности ........................................................................ 186 
6.9. Диаграмма состояний .............................................................................. 192 
6.10. Диаграммы взаимодействия ................................................................. 195 
6.11. Диаграмма компонентов ....................................................................... 204 
6.12. Диаграмма развертывания .................................................................... 207 
6.13. Кооперация ............................................................................................ 210 
6.14. Практические задания ........................................................................... 212 
Глава 7. Проектирование баз данных ........................................................... 213 
7.1. Методология проектирования базы данных ......................................... 213 
7.2. Нотация IDEF1X ...................................................................................... 222 
7.3. Практические задания ............................................................................. 228 
Глава 8. Техническое задание на разработку ПО ....................................... 229 
8.1. Содержание ТЗ и нюансы применения ................................................. 229 
8.2. Практическое задание ............................................................................. 240 
Словарь ................................................................................................................ 241 
Библиографический список ............................................................................... 247 
Приложения ......................................................................................................... 252 
Приложение 1. Примерные темы курсовых проектов ..................................... 253 
Приложение 2. Список контрольных вопросов ............................................... 254 
 
 

ПРЕДИСЛОВИЕ 
 
Заказчики не всегда бывают довольны разработанным ПО не из-за 
низкой квалификации программистов, хотя и это случается, а из-за иного 
видения командой разработки того, что нужно заказчику. Программисты 
очень ценят точные и полные технические задания, но совершенно не 
любят их писать. Для решения этих проблем сформировалась отдельная 
категория людей – системных аналитиков.  
Чем же занимается системный аналитик? Это посредник между заказчиком и разработчиком и членами команды разработки (тестировщики 
тоже не всегда едины в понимании с разработчиками). Его задача – проанализировать потребности заказчика, его предметную область, выделить 
требования к будущей программе и написать ТЗ. Архитектуру будущего 
ПО из требований, как правило, формируют архитекторы программного 
обеспечения, но аналитик также должен знать эту работу, поскольку, возможно, ему придется ее выполнять. При этом системному аналитику требуется совершенно особый набор навыков и инструментов. В 2014 году 
был принят профессиональный стандарт [1], установивший четыре уровня квалификации системного аналитика и описывающий основные навыки и компетенции для каждого из них. 
Помимо таких навыков, как умение работать с требованиями, моделировать предметную область, писать ТЗ, аналитик должен обладать еще 
целым рядом других навыков. Можно порекомендовать книгу Ивановой и 
Перерва «Путь аналитика» [2], в которой авторы разделяют навыки аналитика на профессиональные (управление требованиями, анализ предметной области, проектирование ПО, знание процесса разработки, моделирование бизнес-процессов), коммуникативные (умение слушать собеседника, вести переговоры, контролировать эмоции, терпимо относиться 
к собеседникам) и личностные (умение аналитически мыслить, работать в 
условиях неопределенности, наблюдательность). Для системного аналитика важно также понимать управление проектами, а начиная с позиции 
руководителя аналитиками – еще и практические навыки управления. Рекомендаций по управлению проектом в нашем пособии не будет, для этого есть PMBOK [3] и книга Рейнвотера «Как пасти котов» [4]. 
Часто системные аналитики, набравшись опыта в работе с командой, 
становятся менеджерами проектов. Также часто они, изучив большое множество предметных областей заказчиков, уходят в бизнес-аналитики. В конечном итоге этот путь может привести к позиции Директора по ИТ (CIO). 
Бизнес-анализ – это следующая ступень для системного аналитика. 
Если в системном анализе анализировалась предметная область, потребности заказчика и под это разрабатывалось ПО, то в бизнес-анализе анализируется либо бизнес в целом, либо его некоторая часть с целью его 

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

Системный 
анализ

Бизнесанализ

Архитектура 
ПО

Управление 
проектами

Управление 
рисками

Менеджмент

Маркетинг

 
Место системной и бизнес-аналитики 

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

Г Л А В А  1  

АНАЛИТИЧЕСКОЕ МЫШЛЕНИЕ 
 
Системный и бизнес-анализ предполагают не только особый инструментарий, но и особое состояние сознания аналитика. Очень хорошо аналитическое мышление показано в цикле произведений о 
Шерлоке Холмсе Конан Дойла [5]. Системные аналитики применяют, 
по сути, те же приемы, что и этот литературный персонаж. Хорошо 
развитая наблюдательность, логический вывод (индукция и дедукция), 
абстрагирование и конкретизация, классификация и кластеризация, 
композиция и декомпозиция, выбор наиболее вероятных гипотез максимально правдоподобно описывающих имеющиеся факты, воображение – все эти качества жизненно необходимы и при анализе бизнеса, и 
в системном анализе. 
Аналитический стиль мышления – умение обрабатывать и анализировать информацию, выявлять и отслеживать причинно-следственные связи между событиями и их воздействием на выявленные сущности; умение структурировать информацию; способность понять, кто и 
в какой информации нуждается и как он ее использует в своей деятельности; умение выделять главное; способность вычленить из всей 
собранной информации только нужную и важную часть для каждого 
заинтересованного лица, чтобы обсудить, уточнить и согласовать; 
умение предвидеть, какая информация подвержена изменениям со стороны заинтересованных лиц и/или под влиянием объективной реальности бизнеса. 
Внимательный аналитик запомнит высказанные мимоходом комментарии, которые могут оказаться важными. Наблюдая за тем, как 
пользователь выполняет свои обязанности или работает с имеющимся 
приложением, опытный аналитик выявит моменты, о которых пользователь даже не вспомнил. Наблюдательность иногда помогает направить дискуссию в новое русло, чтобы определить дополнительные  
требования, о которых никто не упоминал. В силу разных причин  

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

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

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

бывают мгновенными, им присуща инерция. Это может как создавать 
проблемы, так и способствовать стабильности. Инерция систем дает 
нам время для маневра по ее изменению. Если вы имеете представление о скорости изменений, то не будете ожидать быстрых результатов 
там, где они в принципе не могут быть быстрыми.  
По системному мышлению можно порекомендовать книги 
О’Коннора и Макдермотта «Искусство системного мышления» [6] и 
Лоусона «Путешествие по системному ландшафту» [7]. 
Многие авторы кратко характеризуют системное мышление как 
способность видеть дополняющие друг друга тенденции в прямо противоположных явлениях и создавать одно целое из несоединимых частей. 
Невозможно сформировать обобщенную последовательность этапов системного анализа, фактически методология системного анализа 
должна разрабатываться под каждую предметную область. Наиболее 
близко к реалиям бизнес-анализа и проектирования ПО расположена 
методология прикладного системного анализа по Р.П. Тарасенко. Опираясь на его учебное пособие [8], проследим этапы анализа, за редким 
исключением некоторых, слабо относящихся к нашей предметной области. 
1. Формулировка проблемы. Сформулированная заказчиком проблема может рассматриваться только как ее первоначальный рабочий 
вариант, поскольку заказчик может за проблему выдать ее симптомы 
или может выясниться, что для ее устранения необходимо решить другую, стороннюю, проблему, которая приводит к возникновению проблемы заказчика. 
2. Составление списка заинтересованных сторон. 
3. Выявление проблемного пула. Получение перечня субъективных 
оценок проблемной ситуации заинтересованными сторонами. Ядром в 
этом пуле выступает проблема заказчика. Иногда советуют для выявления пула применять метод номинальных групп. 
4. Выявление целей всех заинтересованных сторон. 
5. Определение критериев оценки альтернатив. 
6. Исследование системы. Изучение структуры системы, анализ ее 
компонентов, выявление взаимосвязей между отдельными элементами. 
Сбор данных о функционировании системы, исследование информационных потоков, наблюдения и эксперименты над анализируемой 
системой. 
 

7. Построение и усовершенствование моделей. При этом важно 
проверять построенные модели на адекватность (насколько хорошо 
модель описывает реальные процессы, насколько качественно она будет прогнозировать развитие процессов), непротиворечивость, полноту 
и точность описания системы. 
8. Генерирование альтернатив. 
а) Метод мозгового штурма (может комбинироваться с техникой 
шести шляп мышления). 
б) Метод Дельфи в варианте для генерирования альтернатив, отличается от мозгового штурма анонимностью идей, как следствие, снимается запрет на критику. Таким образом, любые идеи порождают 
бурные обсуждения. 
в) Диаграммы сходства. 
г) Семинар экспертов с участием модератора. 
д) Идеализированное проектирование. Разработанный Акоффом 
метод направлен на формирование идеального решения проблемы при 
полном отсутствии ограничений, кроме технической реализуемости, 
жизнеспособности и быстрой и эффективной адаптации. Процесс идеализированного проектирования позволяет снять многие ограничения 
мышления, результат при этом не является утопией. 
е) Поиск уже известных кому-либо альтернатив. 
ж) Увеличение числа альтернатив за счет их комбинаций, образования промежуточных вариантов между уже предложенными альтернативами. 
з) Модификация имеющейся альтернативы. 
и) Включение альтернатив, противоположных предложенным. 
к) Включение даже самых невероятных альтернатив. 
л) Формирование альтернатив, рассчитанных на различные интервалы времени (долгосрочные, среднесрочные, краткосрочные, экстренные). 
9. Выбор альтернативы, принятие решения. Оценка альтернатив по 
критериям с учетом допущений и ограничений и выбор оптимальной 
для реализации 
10. Планирование ресурсов, учет рисков и реализация улучшающего 
вмешательства.