Методы и средства проектирования информационных систем и технологий

Изложены модели, методы и устоявшие практики программной инженерии. Рассмотрено понятие программного проекта, обобщающее процессы разработки и управления жизненным циклом 
программного обеспечения. Освещены неотъемлемые мероприятия предпроектного и проектного 
управления. Описаны ключевые этапы создания 
программных систем, основанные на обобщении 
этапов разработки, в частности процессы выявления и анализа требований, проектирования, конструирования и тестирования.
Даны методические и практические рекомендации по разработке прикладных информационных систем в контексте частичной и комплексной 
автоматизации в разных отраслях деятельности.

Р. В. Брежнев
МЕТОДЫ  И  СРЕДСТВА 
ПРОЕКТИРОВАНИЯ 
ИНФОРМАЦИОННЫХ  СИСТЕМ 
И  ТЕХНОЛОГИЙ

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

ИНСТИТУТ КОСМИЧЕСКИХ И ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

   Р. В. Брежнев  Методы и средства проектирования информационных систем и технологий 

Оглавление 

1 

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

Оглавление 
 

2 

УДК 004.415.2(07) 
ББК 32.973.202я73 
        Б877 
 
 
 
Р е ц е н з е н т ы: 
Ю. А. Маглинец, кандидат технических наук, доцент, руководитель 
НУЛ информационной поддержки космического мониторинга СФУ; 
Д. А. Коченов, кандидат физико-математических наук, заместитель 
директора ООО «Объемный мир» 
 
 
 
 
 
 
Брежнев, Р. В. 
Б877       Методы и средства проектирования информационных систем 
и технологий : учеб. пособие / Р. В. Брежнев. – Красноярск : Сиб.  
федер. ун-т, 2021. – 216 с. 
ISBN 978-5-7638-4416-0 
 
Изложены модели, методы и устоявшие практики программной инженерии. Рассмотрено понятие программного проекта, обобщающее процессы разработки и управления жизненным циклом программного обеспечения. Освещены 
неотъемлемые мероприятия предпроектного и проектного управления. Описаны 
ключевые этапы создания программных систем, основанные на обобщении этапов разработки, в частности процессы выявления и анализа требований, проектирования, конструирования и тестирования. 
Даны методические и практические рекомендации по разработке прикладных информационных систем в контексте частичной и комплексной автоматизации в разных отраслях деятельности. 
Предназначено для студентов направлений подготовки 27.03.03 «Системный анализ и управление», 09.03.02, 09.04.02 «Информационные системы 
и технологии», 09.03.03, 09.04.03 «Прикладная информатика», 09.03.04, 09.04.04 
«Программная инженерия». 
 
 
Электронный вариант издания см.: 
http://catalog.sfu-kras.ru 
УДК 004.415.2(07)  
ББК 32.973.202я73 
 
ISBN 978-5-7638-4416-0                                                           © Сибирский федеральный  
                                                                                                         университет, 2021 

Оглавление 

3 

 
ОГЛАВЛЕНИЕ 
 
ВВЕДЕНИЕ .......................................................................................................... 5 
 
Г л а в а  1.  ОСНОВЫ   УПРАВЛЕНИЯ  
ПРОГРАММНЫМ  ПРОЕКТОМ ................................................. 7 
1.1. Управление рисками ............................................................... 8 
1.2. Управление требованиями ................................................... 11 
1.2.1. Уровни требований ..................................................... 12 
1.2.2. Стратегии выявления требований ............................. 14 
1.3. Управление изменениями ..................................................... 27 
1.3.1. Факторы изменений .................................................... 27 
1.3.2. Процесс управления изменениями ........................... 31 
1.3.3. Трассируемость требований ...................................... 38 
1.4. Управление конфигурацией ................................................. 42 
1.4.1. Задачи управления конфигурацией проекта ............ 45 
1.4.2. Организация среды управления  
конфигурацией проектов ........................................... 50 
1.4.3. Системы контроля версий ......................................... 59 
Контрольные вопросы и задания ................................................ 72 
 
Г л а в а  2.  ОСНОВЫ  ПРОЦЕССА  РАЗРАБОТКИ  
ПРОГРАММНОГО  ОБЕСПЕЧЕНИЯ ....................................... 73 
2.1. Свод знаний по программной инженерии .......................... 77 
2.2. Требования. Стандарты документирования ....................... 79 
2.2.1. Документирование требований  
в соответствии с ГОСТ 34.602–89 ............................ 79 
2.2.2. Документирование требований в RUP...................... 84 
2.2.3. Графическое представление  
функциональных требований .................................... 93 
2.2.4. Корпоративные стандарты  
описания требований ................................................ 112 
2.3. Проектирование ................................................................... 115 
2.3.1. Концепции проектирования ..................................... 117 
2.3.2. Стратегии проектирования ...................................... 128 
2.3.3. Архитектурные стили ............................................... 139 
2.3.4. Шаблоны проектирования ....................................... 149 

Оглавление 
 

4 

2.4. Конструирование ................................................................. 156 
2.4.1. Управление конструированием ............................... 158 
2.4.2. Языки конструирования ........................................... 161 
2.4.3. Объектно-ориентированная модель ........................ 163 
2.4.4. Моделирование взаимодействия  
программных объектов ............................................ 172 
2.4.5. Моделирование состояний  
программных объектов ............................................ 178 
2.5. Тестирование ....................................................................... 187 
2.5.1. Уровни тестирования ................................................ 190 
2.5.2. Виды тестирования ................................................... 191 
2.5.3. Техники тестирования .............................................. 195 
Контрольные вопросы и задания .............................................. 206 
 
ЗАКЛЮЧЕНИЕ ............................................................................................... 208 
 
БИБЛИОГРАФИЧЕСКИЙ СПИСОК ........................................................... 210

Введение 

5 

 
ВВЕДЕНИЕ 
 
 
Инженерия программного обеспечения (или программная инженерия) сформировалась с 1960-х годов как область инженерно-технической 
деятельности, направленной на организацию систематического, измеримого подхода к реализации жизненного цикла программного обеспечения, 
включающего ряд основных этапов. Это выявление и анализ требований, 
проектирование, конструирование, тестирование, внедрение, эксплуатация, 
а также поддержка и сопровождение программных систем. 
Программная инженерия – мультидисциплинарная область деятельности, объединяющая целый ряд специализированных областей и дисциплин, 
призванных воплотить в практическом приложении в виде информационных систем передовые научные, технические, технологические и иные 
достижения и практические знания. 
Изначально инженерный процесс разработки был нацелен на создание 
качественных программных продуктов, автоматизирующих деятельность 
предприятия, отдела или потребностей определенных категорий пользователей, и на структурирование этого процесса на конкретные этапы, называемые фазами. По мере развития информационных технологий и изменения темпов и масштабов спроса, трансформировались и цели инженерного 
процесса. Помимо качества на передний план стали выходить доступность, 
быстрота разработки и легкость поддержки программного обеспечения 
и конечных пользователей. Специфика названных целей, естественно, отразилась и на содержании жизненного цикла разработки, который адаптировался к условиям проектов и софтверных компаний. Это привело к появлению большого числа практик разработки, представленных различными 
моделями и методологиями, многие из которых доказали свою эффективность и получили широкую популярность во всем мире, став стандартами. 
Жизненный цикл разработки, безусловно, сложный, разносторонний, 
но контролируемый и управляемый процесс, поэтому программную инженерию нельзя рассматривать в отрыве от методов управления. Деятельность по управлению процессом разработки направлена на планирование 
процесса, в том числе планирование сроков, стоимости, коммуникаций 
с заказчиками, ресурсов, качества, формирование команды разработчиков, 
распределение ответственностей, организацию и координацию взаимодействия между всеми членами команды, непрерывный контроль и измерение 

Введение 
 

6 

результатов работы на каждом этапе. Корректное построение и соблюдение комплекса управленческих мероприятий вносит весомый вклад в успешное завершение проектов. 
Данная книга вводит в круг вопросов, связанных с моделями и методами программной инженерии, и предназначена для формирования общего 
и целостного представления об устройстве инженерного процесса разработки программных продуктов. Состоит из двух глав, первая посвящена 
основам управления программным проектом, а вторая – основам процесса 
разработки программного обеспечения.  
В первой главе описаны области знаний управления рисками, требованиями, изменениями и конфигурацией. Приведены современные специализированные программные среды, позволяющие представить проект в виде 
множества взаимосвязанных артефактов, составляющих основу управления от формирования концепции до ее воплощения в программном коде. 
Раскрыты основные термины и приведены примеры использования программных инструментов управления проектом. 
Во второй главе рассматриваются основные этапы жизненного цикла 
разработки программного обеспечения, согласованные со сводом знаний 
по программной инженерии (SWEBOK). В частности, внимание уделено 
вопросам стандартизации документирования требований, проектирования, 
конструирования и тестирования. Значительное внимание уделяется построению визуальных моделей, позволяющих представить проектируемую 
предметную область в виде иерархической совокупности взаимосвязанных 
диаграмм. Приводятся подробные примеры. 
В заключении кратко обобщен рассмотренный материал, представлено виденье дальнейшего расширения знаний в данной области. Предложен 
список рекомендованной технической литературы. 
Основные аспекты разработки и эффективные практики, рассмотренные в предлагаемом пособии, будут полезны студентам бакалавриата 
и магистратуры, обучающимся по специальностям, связанным с информационными системами и технологиями, а также с разработкой программного 
обеспечения.

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

7 

 
Г л а в а  1 

 
ОСНОВЫ  УПРАВЛЕНИЯ  
ПРОГРАММНЫМ  ПРОЕКТОМ 
 
 
Разработка программного обеспечения представляет собой ряд 
сложных и многогранных процессов, развивающихся как последовательно, 
так и параллельно, которые, безусловно, требуют непрерывного контроля 
и координации. К ключевым процессам разработки относятся выявление 
и анализ требований, проектирование, конструирование, тестирование, отладка, внедрение, сопровождение, управление коллективом, рисками, финансами, временем и т. д. Совокупность перечисленных процессов, объединенных контекстом автоматизируемой деятельности, а также взаимосвязей между ними называется программным проектом. 
Каждый процесс, по сути, является самостоятельным видом деятельности (дисциплиной), в рамках которой формулируются свои цели, задачи, 
применяются соответствующие модели, методы, нотации, формируются 
промежуточные результаты. Это требует привлечения в коллектив специалистов разных направленностей (например архитектора, программиста, дизайнера, тестировщика) и выстраивания структуры взаимодействия между 
ними на всем протяжении жизненного цикла программного проекта. Кроме того, порядок взаимодействия в коллективе сопровождается процессами планирования, контроля исполнения планов, координации взаимодействия и выбором оптимальной для коллектива стратегии разработки. Все 
это объединяет понятие управления программным проектом. 
Отметим важность определения стратегии разработки и следование 
ее правилам, поскольку нередко неудачное завершение проектов связано 
не с финансовыми ограничениями, а именно со слабым управлением, в результате которого возникают неясно сформулированные цели, невыполнимые требования, некорректный расчет требуемых ресурсов, в том числе 
временных, финансовых, технических, технологических и др. В исследованиях, проведенных в [27], также отмечается фактор неуправляемых рисков, неосведомленности менеджера проекта об актуальном состоянии работ, слабое взаимодействие между заказчиком, исполнителем и непосредственным пользователем, применение новых нестабильных технологий. 
Устоявшиеся и хорошо зарекомендовавшие себя в управлении проектами 
стратегии сформулированы в методологиях RUP, MSF, XP, SCRUM, Agile, 
которые широко применяются в мировой практике. 

Г л а в а  1.  Основы управления программным проектом 
 

8 

По мере развития IT-индустрии, расширения сфер и масштабов        
автоматизации, усложнялись и процессы разработки программных продуктов. При такой тенденции возникла острая необходимость выработки унифицированного подхода к организации процесса разработки и управления 
им. Так, с начала 1970-х годов стали появляться такие модели процесса 
разработки программного обеспечения, как каскадная, итеративная и спиральная, содержание которых будет рассмотрено в гл. 2. 
В контексте управления программным проектом кратко рассматриваются подпроцессы управления рисками, требованиями, изменениями 
и конфигурацией. 
 
 
1.1. Управление рисками 
 
Управление рисками (risk management) представляет собой деятельность руководителя проекта, направленную на снижение вероятности возникновения неуспешного результата, а также на минимизацию потерь, связанных с реализацией проекта. Понятие риск главным образом связано 
с неопределенностью – будут ли достигнуты цели, поставленные в рамках 
проекта. Причем необходимо учитывать не только конечные цели всего 
проекта, но и цели его отдельных этапов. 
Процесс управления рисками регламентируется такими стандартами, 
как ГОСТ Р ИСО 31000–2010 «Менеджмент риска. Принципы и руководство» [6], ГОСТ Р ИСО/МЭК 31010–2011 «Менеджмент риска. Методы 
оценки риска» [8], ГОСТ Р 51897–2011 «Менеджмент риска. Термины 
и определения» [4]. 
Структура процесса управления рисками [6] включает этапы, рассмотренные далее (рис. 1.1). 
Определение ситуации. Ситуации, при которых возможны риски 
или порождающие риски, носят внешний и внутренний характер. Внешние 
риски связаны с ограничениями внешней среды, где функционирует коллектив разработчиков (IT-организация). Примерами таких ограничений 
могут быть действующие финансовые, временные, экономические, технологические, правовые, политические и прочие условия. Кроме того, значимыми факторами, вызывающими риски, являются установленные взаимоотношения между заинтересованными сторонами проекта, а именно их  
индивидуальные предпочтения, различия в виденьи процесса разработки 
и конечных целей, что в свою очередь порождает различные несогласованные требования. 
Внутренние риски связаны с внутренним устройством IT-организации, 
которая реализует проект, особенностями управления, распределения ролей, 
обязанностей. К внутренним рискам относится:  

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

9 

● оценка ресурсов и знаний, в частности, коллектива, финансов, времени, процессов, используемых технологий; 
● стратегии, выбранные для достижения целей проекта; 
● стандарты, модели, методологии, принятые в организации; 
● взаимоотношения внутренних заинтересованных сторон (stakeholder) 
и участников проекта, их индивидуальные предпочтения и ценности; 
● корпоративная культура. 
 

 
Рис. 1.1. Процесс управления рисками 
 
Идентификация риска. Работа по идентификации риска направлена 
на поиск потенциального источника риска, области его воздействия, прогнозирование возможных последствий при наступлении риска. Результат 
идентификации рисков – это перечень всевозможных рисков, основанных 
на внутренних и внешних факторах, которые могут создавать, повышать, 
предотвращать, снижать, ускорять или задерживать достижение целей. 
Идентификацию можно осуществлять на основе описания сценариев процессов, взаимодействий и прочих аспектов жизненного цикла разработки 
ПО. Сценарии позволяют обнаружить причины и последствия рисков, 
масштаб их влияния, определить неявные риски. 

Мониторинг  
и пересмотр 

Г л а в а  1.  Основы управления программным проектом 
 

10 

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

1.2. Управление требованиями 

11 

● Разделение или передача риска подразумевает частичную или полную передачу управления риском третьей стороне, например субподрядчику. Риск при этом не снижается и не устраняется. Передачу риска можно 
осуществить в рамках договорных условий и обязательств, в результате 
которых субподрядчик будет иметь финансовое вознаграждение. Также 
среди способов передачи риска отмечают страхование, гарантийные обязательства, поручительства и прочее.  
Типичный пример передачи риска – договор между Заказчиком 
и Исполнителем, в котором прописана оплата фактических издержек. Если 
стоимость разработки ПО сложно оценить на начальных этапах, например 
потому, что в стоимость проекта включено приобретение Исполнителем 
оборудования (терминала оплаты, датчиков или сервера и т. д.), а при этом 
заранее не известна стоимость оборудования, зависящая от технических 
характеристик оборудования и курса валют. 
Отметим, что управление рисками – это итеративный процесс и каждая итерация может заканчиваться выявлением новых рисков, а это значит, 
что каждый раз необходимо пересматривать возможные последствия, их 
влияние на цели проекта. Таким образом, процесс управления рисками регулируется периодическим мониторингом и пересмотром.  
В рамках мероприятий по мониторингу назначается ответственное 
лицо или группа лиц, которые взаимодействуют с внутренними и внешними 
заинтересованными лицами, обмениваются информацией, проводят консультации с целью выбора наиболее эффективных мер воздействия на риски, поиска возможных выгод от реализации рисков и пр. При этом информация может касаться источников рисков, вероятности их реализации, 
причин и последствий, важности, приемлемости, мер по воздействию и т. д. 
Таким образом, консультирование есть двусторонний или многосторонний 
процесс поиска компромиссных решений по управлению рисками. 
 
 
1.2. Управление требованиями 
 
Управление требованиями (software requirements management) – процесс, который направлен на выявление потребностей и требований, предъявляемых заказчиком к программному обеспечению. Управление требованиями включает такие этапы, как идентификация требований, выявление, 
документирование, согласование с заинтересованными лицами, внесение 
изменений и управление этими изменениями. 
Прежде чем перейти к рассмотрению основных аспектов работы 
с требованиями, дадим определение понятию «требование». Существуют 
разные трактовки данного понятия. В стандарте IEEE Standard Glossary of