В.А. АНТИПОВ

А.А. БУБНОВ
А.Н. ПЫЛЬКИН
В.К. СТОЛЧНЕВ

ВВЕДЕНИЕ
В ПРОГРАММНУЮ
ИНЖЕНЕРИЮ

УЧЕБНИК

Рекомендовано

Научно-методическим советом «РГРТУ» в качестве учебника
для студентов выаиих учебных заведений, обучающихся
по направлению подготовки 2.09.03.04
«Программная инженерия» (квалификация «бакалавр»)

Москва
КУРС
ИНФРА-М
2026
ФЗ Издание не подлежит маркировке
№ 436-ФЗ в соответствии с п. 1 ч. 4 ст. 11

УДК 004.41(075.8)

ББК 32.973я73

А72

Рецензенты:

В. В. Золотарев — д-р техн, наук, профессор Института космических
исследований РАН, г. Москва;

А.Е. Кузнецов — д-р техн, наук, профессор, зам. директора Института
обработки аэрокосмических изображений «Фотон», г. Рязань

Антипов В.А.

Л72 Введение в программную инженерию : учебник / В.А. Анти-
пов, А.А. Бубнов, А.Н. Пылькин, В.К. Столчнев. — Москва :
КУРС: ИНФРА-М.2026 - 336 с.

ISBN 978-5-906923-22-6 (КУРС)

ISBN 978-5-16-012731-6 (ИНФРА-М, print)

ISBN 978-5-16-103172-8 (ИНФРА-М, online)

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

Рассматриваются задачи, стоящие перед программным инженером,
излагаются этапы и виды работ, связанные с созданием программного
продукта и его дальнейшим сопровождением: сбор и управление требова-
ниями, управление проектом (финансами, процессами, ресурсами), про-
ектирование, конструирование, тестирование, поддержка и эксплуатация;
описываются различные модели жизненного цикла программного продук-
та; раскрывается понятие качества программ; описываются инструменты,
поддерживающие те или иные виды работ в рамках всего жизненного цикла
программного продукта. При изложении особое внимание уделяется стан-
дартам, которым должны отвечать как рассматриваемые работы, так и их
результаты.

Для студентов учреждений высшего образования.

УДК 004.41(075.8)

ББК 32.973я73

ISBN 978-5-906923-22-6 (КУРС)

ISBN 978-5-16-012731-6 (ИНФРА-М, print)

ISBN 978-5-16-103172-8 (ИНФРА-М, online)

© Коллектив авторов,
2017,2019

© КУРС, 2017, 2019
ВВЕДЕНИЕ

Современный подход к разработке программного обеспечения в
корне отличается от того, который был десять и более лет назад.
Первые программы писались на бумаге и переносились в компьютер
напрямую в машинных кодах. Затем появились языки программи-
рования, которые упростили и ускорили процесс разработки. Стали
усложняться задачи, которые решали программы, и к этим прог-
раммам стали предъявляться повышенные требования (по надеж-
ности, отказоустойчивости, производительности). Параллельно
совершенствовались и вычислительные системы. Увеличивалась
производительность процессоров, объем используемой памяти, но-
менклатура внешних устройств и т.д.

Изменялись и организационные подходы к программированию:
если в начале 80-х гг. прошлого века на написание большинства
программ могло хватить сил одного человека, то в дальнейшем по-
ставленные задачи приходилось решать командам разработчиков.
Появилась необходимость в координировании процесса разработки
и распределении зон ответственности. Более сложные системы по-
требовали дополнительного тестирования и качественно другой до-
кументации, необходимой как для обучения пользователей, так и для
описания самого исходного кода, элементов системы и ее архитек-
туры. Чтобы разработчики работали продуктивней, возникла необ-
ходимость в более четкой постановке задач, в более тщательном их
анализе и более тесном взаимодействии с заказчиками.

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

В современном языке разработчиков программного обеспечения
используется понятие «проект» для описания процесса разработки
программной системы. Ввод этого понятия означает, что для напи-
сания программ недостаточно знания языка программирования
и умения писать код программы, не меньшее значение имеет орга-
низационная составляющая процесса.

Данный учебник позволяет разобраться во всех аспектах приме-
нения инженерных подходов к разработке современного программ-
ного обеспечения. За основу взят свод знаний, предложенный Все-
мирным компьютерным сообществом IEEE (Computer Society of the
Institute for Electrical and Electronic Engineers) и называемый
SWEBOK.

Содержание учебника охватывает все основные области знаний
программной инженерии.

В главе 1 введены основные понятия программной инженерии,
термины и определения.

В главе 2 достаточно подробно рассмотрено понятие жизненного
цикла программного продукта, наиболее общие подходы к процес-
сам его разработки, эксплуатации, сопровождения и вывода из экс-
плуатации.

Глава 3 посвящена вопросам управления процессом разработки
программного обеспечения, в ней рассматриваются процессы управ-
ления программным проектом, инициации, планирования и мони-
торинга, исполнения и завершения проекта, управления рисками,
а также основные существую]цие методики оценки стоимости про-
екта.

В главе 4 изложены общие вопросы, касающиеся определения
и разработки требований к программным системам, а также во-
просы работы с требованиями, формализации и управления требо-
ваниями.

Глава 5 посвящена проектированию программного обеспечения,
в ней рассматриваются ключевые вопросы проектирования, основ-
ные архитектурные стили проектирования, используемые графиче-
ские и программные средства, вопросы создания модели программ-
ного обеспечения с применением языка UML, приведен анализ ка-
чества и оценки программного дизайна.

Предметом рассмотрения главы 6 (конструирование программ-
ного обеспечения) являются вопросы реализации программного
продукта в соответствии с проектной документацией, а также шаб-
лоны проектирования, позволяющие использовать готовые прог-
раммные конструкции и механизмы повторного использования
кода.

В главе 7 излагаются основы тестирования программного обеспе-
чения, рассматриваются различные виды тестирования, методики
и программные средства идентификации и работы с ошибками.

В главе 8 рассматриваются важнейшие аспекты сопровождения
программного обеспечения, в том числе базовые понятия и основы
организации процессов, виды работ по сопровождению, методики
оценки запроса на сопровождение.

Глава 9 посвящена основам качества программного обеспечения,
в ней рассмотрены метрики и атрибуты качества, вопросы управ-
ления качеством программного обеспечения и основы надежности
программного обеспечения как главной составляющей качества.

Излагаемый материал сопровождается примерами, способству-
ющими лучшему пониманию и более качественному его усвоению.
В конце каждой главы приведены вопросы для самоконтроля.

Изучение каждой из описанных выше областей знаний и их взаи-
мосвязей поможет студенту сделать первый шаг, чтобы в будущем
стать грамотным программным инженером. Для более детального
ознакомления изложенного материала для каждой главы даны
ссылки на дополнительную литературу, где более подробно раскры-
ваются вопросы, рассмотренные в данном учебнике.
Глава 1

ОСНОВНЫЕ ПОНЯТИЯ

1.1. Программная инженерия
и программные инженеры

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

Разработка программного обеспечения является достаточно мо-
лодой отраслью инженерной науки. С 90-х гг. XX в. Британское со-
общество вычислительной техники (British Computer Society) стало
присваивать разработчикам протрамм звание инженера, в США по-
добное звание появилось с 1998 г. И сегодня имеет смысл вести речь
об инженерии программного обеспечения, или программной инже-
нерии (научной дисциплине, охватывающей все аспекты жизненного
цикла программного продукта), а также о специалистах в этой об-
ласти — программных инженерах.

С развитием языков программирования развивались и методики,
применяемые для создания программного обеспечения, в результате
чего в конце 90-х гг. XX в. появилось направление «программная ин-
женерия» (Software Engineering). Компьютерное сообщество IEEE
(Computer Society of the Institute for Electrical and Electronic Engineers)
к 2004 г. сформировало Руководство к своду знаний ио программной
инженерии (Guide to the Software Engineering Body of Knowledge,
SWEBOK).

Согласно SWEBOK программная инженерия включает в себя сле-
дующие десять областей знаний:
1)	требования (software requirements);

2)	проектирование (software design);

3)	конструирование (software construction);

4)	тестирование (software testing);

5)	поддержка и эксплуатация (software maintenance);

6)	конфигурационное управление (software configuration manage-
ment);

7)	управление инженерной деятельностью (software engineering
management);

8)	процессы инженерной деятельности (software engineering pro-
cess);

9)	инженерные инструменты и методы (software engineering tools
and methods);

10)	качество (software quality).

Следует отметить, что принятые разграничения между областями
знаний, их компонентами (subareas) и другими элементами во мно-
гом условны.

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

Для обеспечения требуемого уровня качества программного про-
дукта используются следующие методы.

Инспектирование — команда разработчиков работает в направле-
нии достижения качества на протяжении всего периода реализации
проекта посредством коллективного рассмотрения разрабатываемого
программного обеспечения и его составляющих на предмет соответ-
ствия заданным требованиям или показателям качества.

Формальные методы — математические методики доказательства
адекватности созданной программы установленным требованиям,
применяемые выборочно.

Тестирование — проверка соответствия функциональных возмож-
ностей программы заявленным требованиям, осуществляемая
на уровне модуля и целого приложения, а также проверка кор-
ректной работы программы в различных условиях. Количественные
характеристики качества отражаются в метриках, приведенных в со-
ответствующих стандартах.

Специальные методы управления проектом — методы, использу-
емые в процессе разработки для контроля стоимость и сроков реа-
лизации проекта, а также для грамотного управления версиями, до-
кументацией, конфигурациями и прочими артефактами.

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

Инженеры по программному обеспечению воспринимают во-
просы качества программного обеспечения как часть своей профес-
сиональной культуры. Этические аспекты играют значительную роль
при достижении качества программного обеспечения. IEEE Com-
puter Society и ACM (Association for Computing Machinery — Ассо-
циация по вычислительной технике) разработали кодекс этики (мо-
ральный кодекс — code of ethics) и профессиональной практики, осно-
ванный на восьми принципах, помогающих инженерам отстаивать
свою независимую позицию в решении вопросов обеспечения дос-
тойного качества создаваемых программных продуктов.

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

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

Сформулированные принципы декларируют здоровье, безопас-
ность и благосостояние общества как главные факторы, которые
необходимо принимать во внимание при принятии решений в про-
фессиональной деятельности программного инженера.
Моральный кодекс программного инженера декларирует'.

1)	согласование профессиональной деятельности с интересами
общества;

2)	определение взаимоотношений между клиентом, работодате-
лем и исполнителем разработки;

3)	достижение соответствия качества продукта лучшим профес-
сиональным стандартам;

4)	соблюдение честности и независимости при профессио-
нальных опенках;

5)	соблюдение этических норм в менеджменте и в сопровожде-
нии разработок;

6)	поддержка становления профессии в соответствии с кодексом
этики;

7)	соблюдение этических норм во взаимоотношениях между кол-
легами;

8)	усовершенствование специальности.

1.2. Программный продукт

При разработке программного обеспечения под программным про-
дуктом понимают не только программное приложение, но и все его
артефакты (конфигурационные данные, планы, отчеты, диаграммы
и прочую документацию). Примеры артефактов соответствующих
составляющих приложения приведены в табл. 1.1.

Таблица 11

Артефакты программного продукта

Составляющие программного продукта	Артефакты
Требования	Спецификация требований к про- граммному обеспечению
Программная архитектура	Проектная модель
Детальное проектирование	Исходный и объектный коды
Реализация	
Тестирование	Тестовые процедуры и тестовые ва- рианты

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

Можно выделить две категории программных продуктов.

1.	Программные продукты общего назначения (так называемое
тиражное, «коробочное программное обеспечение») — автономные
программные системы, созданные соответствующими компаниями
для распространения на открытом рынке программных продуктов
любому потребителю.

2.	Программные продукты, созданные на заказ. Такие прог-
раммные системы создаются по заказу конкретного потребителя или
целевой категории; они весьма специфичны и обладают узконаправ-
ленной функциональностью.

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

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

Маркетинговые исследования важны, так как необходимо создать
нужный конечному пользователю программный продукт, который
позиционируется в определенной нише программного обеспечения,
обладая при этом очевидными преимуществами перед аналогами.
Это очень важно, поскольку данный продукт подлежит дальнейшей
продаже (в большинстве случаев — массовой).

Оценка стоимости разрабатываемого программного продукта
также важна, поскольку она позволяет определить затраты, связан-
ные со всеми этапами его жизненного цикла. Следует отметить, что
это могут сделать на должном уровне только крупные компании.
Программный продукт является интеллектуальной собствен-
ностью его создателей, поэтому необходимы правовые гарантии ее
защиты, отраженные в соответствующих законах. Среди правовых
аспектов защиты программных продуктов выделяют следующие со-
ставляющие:
• авторское право;

•	патентную защиту;

•	закон о производственных секретах;

•	лицензионное соглашение и контракты.

Патентная защита устанавливает приоритет в разработке и ис-
пользовании нового подхода или метода, примененного при разра-
ботке программ, удостоверяет их оригинальность (в российском
законодательстве патентная защита не распространяется на прог-
раммное обеспечение).

Статус производственного секрета для программы ограничивает
круг лиц, допущенных к ее эксплуатации, а также определяет меру
их ответственности за разглашение секретов.

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

•	знак авторского права (обычно: ©), название разработчика, год
выпуска программы в свет;

•	знак патентной защиты или производственного секрета;

•	торговые марки, соответствующие использованным в программе
другим программным продуктам (обычно: ™ и название фирмы —
разработчика программного продукта);

•	символ зарегистрированного права на распространение прог-
раммного продукта (обычно: ®).

Существует несколько типов лицензий на программные про-
дукты.

Исключительная лицензия — продажа всех имущественных прав
на программный продукт или базу данных. Покупателю лицензии
предоставляется исключительное право на их использование, а автор
или владелец программного продукта отказывается от самостоятель-
ного их применения или предоставления другим лицам. Это самый
дорогой вид лицензии, к нему прибегают для монопольного владе-
ния с целью извлечения дополнительной прибыли либо с целью пре-
кращения существования на рынке программных средств данного
программного продукта.

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

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

1.3. Понятие проекта

Проект можно определить как протяженное во времени пред-
приятие, направленное на создание уникальных продуктов, услуг
или достижение иных результатов. Каждый проект имеет начальную
и конечную точки, а также характеризуется ограниченностью ис-
пользуемых ресурсов при его реализации. Проект завершается в том
случае, когда достигнуты его цели или есть основания прекратить
процесс их достижения.

Цель проекта определяет задачи, решаемые в результате реали-
зации проекта, содержание — что является результатом проекта.
Управление проектом определяет, как будет достигнута цель и создан
необходимый результат. Управление проектом есть постоянная дея-
тельность, осуществляемая на всем его протяжении по определенной
методике. Достижение результата проекта и достижение его цели —
разные вещи. Например, результат проекта — разработка информа-
ционной системы, цель — автоматизация определенной деятель-
ности. Можно создать информационную систему, не обладающую
нужной функциональностью, и цель проекта достигнута не будет,
в отличие от результата. Успешным проект будет лишь тогда, когда
результат соответствует заданному содержанию и его целям.

Часто связанные проекты объединяются в проектные программы.
Если же проекты характеризуются единым или пересекающимся на-
бором ресурсов и единым центром управления, то они объединяются
в портфели проектов

Масштаб проекта оценивается по количеству людей, в нем задей-
ствованных, и по конечной стоимости. Любой проект, как правило,
имеет руководителя (проектного менеджера), который несет ответ-
ственность за проект в целом. Успешный проект должен уложиться
в рамки так называемого тройственного ограничения (рис. 1.1).

Рис. 1.1. «Тройственное ограничение»

Важны следующие аспекты управ пения проектами'.

•	ограничения являются следствием приоритетов, расставленных
заказчиком с учетом имеющихся ресурсов,

•	приоритеты заказчика и исполнителя в общем случае могут не со-
впадать (противоречить);

•	анализ компромиссов определяет баланс приоритетов сторон,
заинтересованных в проекте;

•	ограничения являются неотъемлемой частью проекта;

•	ограничения порождают риски;

•	ограничения рассматриваются в контексте уровня детализации
проекта.

Детализация проекта заключается в разбиении (декомпозиции)
его на отдельные работы (задачи); она необходима для адекватной
оценки его длительности и стоимости при имеющихся требованиях
к функциональности и уровню качества.

В области управления проектами существует ряд нормативов и ре-
комендаций, среди которых можно выделить результаты деятель-
ности следующих организаций:
•	PM! — Project Management Institute, Inc. — американский Ин-
ститут управления проектами;

•	IPMA — International Project Management Association — Междуна-
родная ассоциация управления проектами;

•	АРМ — Association of Project Management — одна из крупнейших
независимых профессиональных ассоциаций по проектному ме-
неджменту в Европе;

•	Ассоциация по управлению проектами СОВНЕТ

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

Стоимость

Возможности

Цель - 100%

Факт — 100%

Текущий
проект

Факт — 1 дефект
на тыс. строк кода
Цель — 3 дефекта
на тыс. строк кода

Факт — 130 тыс. руб.

Цель — 100 тыс. руб.

Длительность

Факт — 25 недель

Цель — 20 недель

Предполагаемый
проект

Плотность дефектов

Рис. 1.2. Пример лепестковой диаграммы параметров проекта

Особенностью IT-проекта является еще и то, что все этапы его
реализации должны сопровождаться специальными документами,
перечень которых в соответствии с требованиями IEEE представлен
на рис. 1.3, где слева от названия каждого документа указано наиме-
нование соответствующей работы.

STD (Документация

по тестированию программного
обеспечения)

Тестирование

Использование

Руководство пользователя

Рис. 1.3. Документация проекта в соответствии с требованиями IEEE

Краткая характеристика каждого документа приведена ниже.

SWP (Software Verification and Validation Plan) — план экспертизы
программного обеспечения, определяющий, каким образом и в ка-
кой последовательности должны проверяться стадии проекта и сам
продукт на соответствие поставленным требованиям (верификация —
проверка правильности сборки приложения; валидация — проверка
на соответствие требованиям).

SQAP (Software Quality Assurance Plan) — план контроля качества
программного обеспечения, определяющий, каким образом проект
должен достигнуть соответствия установленному уровню каче-
ства.

SCMP (Software Configuration Management Plan) — план управления
конфигурациями программного обеспечения, который определяет,
как и где должны храниться документы, программный код и их вер-
сии, устанавливает их взаимное соответствие.

SPMP (Software Project Management Plan) — план управления прог-
раммным проектом, который определяет, каким образом следует
управлять проектом.

SRS (Software Requirements Plan) — спецификация требований
к программному обеспечению, которая определяет требования
к приложению, утверждается совместно заказчиком и разработчиком
и служит отправной точкой для реализации функциональности прог-
раммного продукта.

SDD (Software Design Document) — проектная документация прог-
раммного обеспечения, которая представляет архитектуру и детали
проектирования приложения с использованием диаграмм.

STD (Software Test Documentation) — документация по тестирова-
нию программного обеспечения, в которой указывается, каким обра-
зом должно проводиться тестирование приложения и его компонен-
тов.

При реализации IT-проекта важно следующее:

1)	грамотное управление персоналом', адекватный подбор участ-
ников проекта с обозначением для каждого его должностных обя-
занностей, указанием круга взаимодействия с коллегами и зоны от-
ветственности;

2)	умение управлять рисками', все риски должны быть как можно
раньше идентифицированы; устранимые риски необходимо предот-
вратить, например модифицируя требования, а неустранимые — пре-
одолеть, применяя определенные технологии программирования
и/или проектирования.

1.4.	Технологии программирования

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

Структурное программирование. Основная идея структурного прог-
раммирования основана на применении метода пошаговой детали-
зации, заключающегося в следующем:

•	определяется общая структура программы в виде одного из трех
вариантов (последовательности подзадач, альтернативы подзадач,
повторения подзадач);

•	каждая подзадача разбивается на подзадачи с применением тех же
структур;

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

Каждая часть, как правило, реализуется в виде подпрограммы/
процедуры из 40—50 операторов, и поэтому этот метод получил на-
звание процедурной декомпозиции. Таким образом, исходная задача
разбивается на ряд вложенных подзадач. Например, алгоритмиче-
ская декомпозиция системы «Записная книжка» представлена
на рис. 1.4.

Рис. 1.4. Декомпозиция программной системы «Записная книжка»

Модульное программирование. Структурное программирование
не смогло обеспечить должный уровень процесса создания крупного
программного обеспечения, поскольку возникла необходимость бо-
лее жесткого разграничения доступа к глобальным данным.

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

Считается, что модульное программирование позволяет аде-
кватно реализовывать программы, содержащие до 100000 операто-
ров, поскольку при большем их количестве возрастает сложность
межмодульных интерфейсов и предусмотреть взаимовлияние от-
дельных частей программы становится практически невозможно

Объектно-ориентированное программирование (ООП) позволило
уменьшить количество связей между отдельными частями прог-
раммы. При объектном подходе программа представляется в виде
совокупности объектов — экземпляров определенных классов. По-
следние образуют иерархию с наследованием свойств, а взаимодей-
ствие объектов осуществляется посредством сообщений.

Важным является тот факт, что объектно-ориентированный под-
ход снабдил программистов новыми средствами разработки: насле-
дованием, полиморфизмом, композицией и наполнением, позволя-
ющими конструировать из простых объектов более сложные. При
этом класс объединяет как декларативные, так и процедуральные
знания: имеет поля (данные, атрибуты) и методы (функции, опера-
ции). Методы служат для работы с полями, поэтому появилось более
жесткое разграничение доступа к данным внутри классов. Процесс
разработки программного обеспечения стал более эффективным,
поскольку в объектном подходе уже на этапе проектирования осу-
ществляется оперирование объектами, соответствующими реальной
действительности, что облегчает взаимодействие заказчика и разра-
ботчика.

Объектно-ориентированный подход характеризуется следу-
ющими основными принципами.

Абстрагирование — выделение существенных характеристик не-
которого объекта в контексте решаемой задачи. Все свойства аб-
стракции объединяются в единую программную единицу, именуемую
классом, которая характеризует как состояние, так и поведение объ-
екта.

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

Модульность — данный принцип унаследован от модульного
программирования.
Иерархия — ранжированная (упорядоченная) система абстракций.

Типизация — объявление типа объекта, определяет множество до-
пустимых значений данного типа и применимых к ним операций/
функций, препятствует взаимозаменяемости абстракций различных
типов.

Параллелизм — свойство нескольких абстракций одновременно
находиться в активном состоянии.

Устойчивость — свойство абстракций существовать во времени
независимо от процесса, их пооодившего, или в пространстве, пере-
мещаясь из одного адресного пространства в другое.

При разработке программного обеспечения с использованием
объектного подхода имеет место объектная декомпозиция (рис. 1.5).
На рисунке под формой понимается диалоговое окно, появляющееся
после выбора соответствующего пункта меню.

Рис. 1.5. Пример диаграммы объектов системы «Записная книжка»

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

В рамках компонентного подхода программное обеспечение стро-
ится из отдельных компонентов, физически отдельно существующих
программных частей, которые распространяются в двоичном виде
(в отличие от класса), взаимодействуют между собой посредством
стандартизированных интерфейсов и могут быть используемы в раз-
личных языках программирования (рис. 1.6).

Рис. 1.6. Взаимодействие программных компонентов различных типов

В качестве примеров компонентного подхода можно выделить
следующие технологии.

1.	DCOM (Distributed Component Object Model) — распределен-
ная компонентная модель объектов, созданная «Microsoft».

2.	CORBA (Common Object Request Broker Architecture) — общая
архитектура с посредником обработки запросов объектов — создана
OMG (Object Management Group — группа внедрения объектной тех-
нологии программирования)

Система CORBA представляет собой промышленный стандарт
распределенных систем, архитектурно реализованных в виде набора
клиентов и серверов. Использование языка определения интерфей-
сов IDL (Interface Definition Language) наделяет ее преимуществами
переносимости. Концептуально CORBA представляет собой стан-
дартную платформу' промежуточного уровня, предназначенную для
совместной работы приложений от различных производителей.

Система DCOM также состоит из набора серверов и клиентов,
успешно работает в операционных системах семейства Windows, отли-
чается от технологии COM (Component Object Model) возможностью
обращения к компонентам, расположенным на друтой машине, и рас-
полагает двоичным интерфейсом, сформированным с помощью языка
MIDL (Microsoft IDL). В отличие от CORBA система DCOM не требует
каждый раз при поддержке нового языка программирования отобра-
жения описания IDL на конструкции этого языка.

1.5. Термины и определения

Приведем наиболее важные термины и определения, встреча-
ющиеся в данной главе.

Артефакт — неотъемлемая часть результата и процесса выполне-
ния программного проекта, реализованная в виде документации,
программного кода (исходного или скомпилированного) или его
части (например, модуля).

Архитектура программного обеспечения — модель программного
обеспечения на самом высоком уровне, формализованная теми или
иными средствами.

Двоичный код — переведенный на понятный ЭВМ язык (машин-
ный язык) исходный код программы.

Детальное проектирование — создание подробной модели разра-
батываемой программной системы (с применением псевдокода,
блок-схем и др.), достаточной для написания программного кода.

Инспектирование — коллективное исследование артефактов про-
екта, направленное на выявление дефектов, осуществляемое, как
правило, лицами (разработчиками или их группами), не участвовав-
шими в их создании.

Исходный код — программный код, написанный на каком-либо
языке программирования.

Качество программного обеспечения — совокупность наиболее важ-
ных характеристике программного продукта (например, надеж-
ность), а также характеристики самого процесса разработки (напри-
мер, количество дефектов на тысячу строк кода), измеряемые коли-
чественно по тем или иным методикам, на основе которых можно
сделать заключение о соответствии продукта и/или процесса заранее
определенным показателям.

Класс — структура, описывающая группу объектов с одинаковыми
свойствами (атрибутами), одинаковым поведением (операциями),
типами отношений (относительно объектов других классов) и семан-
тикой.

Модуль — программная единица, обладающая открытой (интер-
фейс) и закрытой (реализация) частями, выполняющая ряд функций
и подключаемая в основной программе в процессе написания кода.
Объектный код — переведенный на машинный язык исходный
код, еще не подверженный особой упаковке, характерной для кон-
кретной операционной системы.

Приложение — готовый программный продукт; как правило, при-
ложением называют программный продукт, разработанный для опе-
рационной системы Windows.

Программный проект — процесс реализации комплекса меро-
приятий, направленных на создание программного продукта.

Программный продукт — результат реализации программного про-
екта, обладающий заявленной функциональностью и потребитель-
скими характеристиками.

Проектирование программного обеспечения — создание модели
программного обеспечения с применением тех или иных средств,
языков и стандартов, уровень детализации которой находится между
архитектурой программного обеспечения и детальным проектом.

Прототип — программный продукт, по ряду ключевых на данный
момент характеристик близкий к разрабатываемому. Прототип пред-
назначен для демонстрации проекта заказчику с целью определения
его мнения относительно интерфейса или части реализованной
функциональности. Большей частью прототипы используют для
своевременной корректировки требований к программному про-
дукту в процессе разработки.

Сопровождение программного обеспечения — комплекс работ, вы-
полняемых после поставки программного продукта заказчику, на-
правленный, главным образом, на исправление обнаруженных в про-
цессе эксплуатации дефектов и расширение возможностей прог-
раммного обеспечения.

Тестирование — комплекс мероприятий, направленный на выяв-
ление дефектов в готовом программном обеспечении и/или его со-
ставляющих.

Требования к программному обеспечению — документ, отражающий,
что должно делать разрабатываемое программное обеспечение.

Управление конфигурациями программного обеспечения — поддер-
жание соответствия версий всех артефактов создаваемого программ-
ного продукта в процессе разработки.

Контро71ьные вопросы

1.	Что такое программная инженерия?

2.	Чем отличается процесс промышленной разработки программного
обеспечения от других производственных процессов?
3.	Каков состав документации, сопровождающей процесс разработки
и сопровождения программного продукта согласно стандарту IEEE?
Кратко охарактеризуйте каждый документ.

4.	Что такое артефакт?

5.	Какие этапы определяют развитие процесса разработки программного
продукта?

6.	Чем характеризуется стихийный подход к разработке ПО?

7.	Охарактеризуйте структурный подход к разработке ПО.

8.	Каковы основные положения объектного подхода к разработке ПО?

9.	Чем характеризуется компонентный подход к разработке ПО.

10.	Перечислите основные моменты компонентного подхода.

Литература

1.	Архипенков С. Лекции по управлению программными проектами
[Электронный ресурс] // С1Т Forum: сайт. — URL: http://citforum.ru/
SE/project/arkhipenkov_lectures/3 .shtml

2.	Батоврин В.К. Толковый словарь по системной и программной инже-
нерии. — ДМК Пресс, 2012. — 280 с.

3.	Брауде Э. Технология разработки программного обеспечения. — СПб.:
Питер, 2004. — 655 с.

4.	Гагарина Л.Г., Кокорева Е.В , Виснадул Б.Д. Технология разработки прог-
раммного обеспечения/ ред. Л Е Гагарина. — М.: ФОРУМ: ИНФРА-М,
2008. - 400 с.

5.	Иванова ГС, Ничушкина Т.Н., Пугачев Е.К. Объектно-ориентированное
программирование / под ред. ГС. Иванова. — М.: МГТУ им. Н. Э. Ба-
умана, 2001. — 320 с.

6.	Липаев В В Отечественная программная инженерия: фрагменты исто-
рии и проблемы. СИНТЕГ, 2007. — 312 с.

7.	Орлик С. Программная инженерия и SWEBOK [Электронный ресурс] //
Основы программной инженерии по SWEBOK: сайт. — URL: http://
swebok.sorlik.ru.

8.	Орлов С.А. Программная инженерия. Технология разработки программ-
ного обеспечения: учебник для вузов — 5-е изд., перераб. и доп. —
СПб.: Питер, 2017 -640 с.

9.	Саммервилл И. Инженерия программного обеспечения: 6-е изд. — М.:
Вильямс, 2002. — 624 с.

10.	Танненбаум Э., Ван Стеен М. Распределенные системы. Принципы и па-
радигмы. — СПб.: Питер, 2003. — 878 с.
Глава 2

ЖИЗНЕННЫЙ цикл

ПРОГРАММНОГО ПРОДУКТА

2.1.	Понятие жизненного цикла
программного продукта

Появление понятия жизненного цикла (ЖЦ) программного про-
дукта (ПП) было связано с кризисом программирования, который
наметился в конце 60-х — начале 70-х гг. прошлого века. Суть кри-
зиса состояла в том, что программные проекты все чаще стали вы-
ходить из-под контроля: нарушались сроки, превышались заплани-
рованные объемы финансирования, результаты не соответствовали
требуемым. Многие проекты вообще не доводились до завершения.
Ситуация была вызвана ростом сложности проектов, и масштабы ее
нарастали, необходимо было принимать меры для радикального
усовершенствования принципов и методов разработки П О с учетом
его развития и сопровождения. Заговорили о том, что надо обра-
титься к опыту промышленного проектирования и производства,
где был накоплен опыт успешной разработки не менее сложных
проектов.

Методологическую основу промышленной инженерии составляет
понятие жизненного цикла изделия (продукта) как совокупности
всех действий, которые надо выполнить на протяжении всей
«жизни» изделия.

Каждая программная система (ПС) на протяжении своего суще-
ствования проходит определенную последовательность процессов
(этапов), начиная от постановки задачи до ее воплощения в готовую
программу, а затем через эксплуатацию — к изъятию. Такая после-
довательность этапов называется жизненным циклом разработки ПС.
На каждом этапе ЖЦ выполняется определенная совокупность про-
цессов и/или подпроцессов, каждый из которых порождает соответ-
ствующий промежуточный продукт, используя результаты предыду-
щего.

Организация промышленного производства с позиции жизнен-
ного цикла позволяет рассматривать все его этапы во взаимосвязи,
что ведет к сокращению сроков, стоимости и трудозатрат.
Впервые о жизненном цикле ПО заговорили в 1968 г. в Лондоне,
где состоялась встреча 22 руководителей проектов по разработке ПС
На встрече анализировались проблемы и перспективы проектирова-
ния, разработки, распространения и поддержки программ. Приме-
няющиеся принципы и методы разработки ПО требовали постоян-
ного усовершенствования Именно на этой встрече была предложена
концепция жизненного цикла ПО (SLC — Software Lifetime Cycle)
как последовательности шагов-стадий, которые необходимо выпол-
нить в процессе создания и эксплуатации ПО.

В 1970 г. У.У. Ройс (W.W. Royce) произвел идентификацию не-
скольких стадий в типичном цикле и было высказано предположе-
ние, что контроль выполнения стадий приведет к повышению каче-
ства ПО и сокращению стоимости разработки.

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

Главными ресурсами разработки ПС в программной инженерии яв-
ляются сроки, время и стоимость. Правильное использование этих ре-
сурсов на процессах ЖЦ определяет эффективность этой разработки.

Существует общее соглашение о выделении четырех обобщенных
фаз жизненного цикла (в скобках приведены используемые в различ-
ных источниках альтернативные термины):

1)	концепция (инициация, идентификация, отбор);

2)	определение (анализ);

3)	выполнение (практическая реализация или внедрение, произ-
водство и развертывание, проектирование или конструирование,
сдача в эксплуатацию, инсталляция, тестирование и т.п.);

4)	закрытие (завершение, включая оценивание после заверше-
ния).

Однако эти фазы столь широко определены, что необходимы бо-
лее конкретные определения, может быть выделение пяти — десяти
основных фаз для каждой категории и подкатегории проекта, воз-
можно с выделением внутри каждой фазы нескольких подфаз.

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

Методология (метод) жизненного цикла задает комплекс работ, их
детальное содержание и ролевую ответственность специалистов
на всех этапах выбранной модели ЖЦ, обычно определяет и саму
модель, а также рекомендует практики (best practices), позволяющие
максимально эффективно воспользоваться соответствующей мето-
дологией и ее моделью.

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

В определенном контексте «модель» и «методология» могут ис-
пользоваться взаимозаменяемым образом, например при обсуж-
дении разграничения фаз проекта. Говоря «жизненный цикл», мы
в первую очередь подразумеваем «модель жизненного цикла». Не-
смотря на данное в стандартах определение модели жизненного
цикла, все же при употреблении слова «модель» чаще подразумева-
ется именно общий принцип организации ЖЦ, чем детализация со-
ответствующих работ. Соответственно, при определении и выборе
модели в первую очередь приходится решать вопросы определен-
ности и стабильности требований, жесткости и детализированности
плана работ, а также частоты сборки работающих версий создаваемой
программной системы.

2.2.	Определение жизненного цикла
программного продукта

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

Как уже отмечалось, понятие ЖЦ ПП возникло в конце 1960-х гг.,
когда разработкой ПО занималось много фирм, и различными раз-
работчиками трактовалось по-разному. Путаница в терминологии
порождала много проблем во взаимопонимании между разработчи-
ками, а также между разработчиками и заказчиками. Необходим был
стандарт на представление терминов, понятий и составных элемен-
тов жизненного цикла ПП.

При разработке стандартов ЖЦ и их практическом применении
возник целый ряд проблем:

•	внедрение стандартов требовало вложения значительных средств,
что не всегда окупалось;

•	было неясно, все ли требуемые процессы надо выполнять и в ка-
кой мере;
•	различным типам ПО (ИС реального времени, бизнес-системы),
соответствовали различные требования;

•	высокая динамика отрасли вела к быстрому устареванию стандар-
тов;

•	терминологическая неоднозначность различных корпоративных
стандартов

Во многих случаях применение стандартов было вызвано требо-
ваниями заказчиков, хотя на практике только мешало выполнению
проектов.

Разрешением проблем стандартизации ЖЦ ПП явилась разра-
ботка и принятие в 1995 г. стандарта ISO/IEC12207. В России он был
принят в 2000 г. под названием «ГОСТ Р ИСО/МЭК 12207 Процессы
жизненного цикла программных средств».

Стандарт ISO/IEC12207. Жизненный цикл ПП: структура и орга-
низация. Этот стандарт разрабатывался с учетом лучшего мирового
опыта на основе ранее разработанных стандартов. Его основная идея
состоит в том, что разработка и сопровождение ПП должны осуще-
ствляться так, как этого требует инженерная дисциплина. Следуя
этой идее, был разработан каркас (framework), имеющий четкие
связи с окружением системной инженерии — программным и тех-
ническим обеспечением, исполнителями и деловой практикой.

Основными результатами разработки ISO 12207являются: единая
терминология по разработке и применению ПП; разделение понятий
ЖЦ ПП и модели ЖЦ ПП; описание организации ЖЦ и его струк-
туры (процессов); адаптация стандарта для построения конкретных
моделей ЖЦ.

Введение единой терминологии по разработке и применению ПО
связано с тем, что стандарт предназначен для формирования общего
понимания ЖЦ ПП всеми заинтересованными сторонами, т.е. участ-
никами процесса разработки, приобретения, поставки, эксплуа-
тации, поддержки и сопровождения программных систем, а также
для расширения возможностей управления, контроля и совершен-
ствования процессов жизненного цикла.

В стандарте ISO 12207 даются определения: программного про-
дукта как набора компьютерных программ, процедур и связанной
с ними документации и данных; жизненного цикла программного
продукта как непрерывного процесса, который начинается с мо-
мента принятия решения о необходимости его создания и заканчи-
вается в момент его полного изъятия из эксплуатации; процесса как
набора взаимосвязанных работ, которые преобразуют исходные дан-
ные в выходные результаты.
В стандарте разделяются понятия ЖЦ ПП и модели ЖЦ ПП: жиз-
ненный никл ПП — полная совокупность всех процессов и действий
по созданию и применению программного обеспечения; модель
ЖЦ — конкретный вариант организации ЖЦ, обоснованно (раз-
умно) выбранный для каждого конкретного случая.

Стандарт не обязывает использовать определенную модель ЖП
ПП или конкретную методологию разработки ПП и не предъявляет
требования к формату и содержанию создаваемых документов, по-
этому организации/пользователю потребуются для своей работы
дополнительные стандарты или процедуры, определяющие различ-
ные детали процесса (ISO выпускает руководства и процедуры, до-
полняющие стандарт 12207).

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

Структура жизненного цикла определяется перечнем его процес-
сов. Для каждого процесса дается описание действий этого процесса.
Так, действиями процесса разработки являются подготовка процесса,
анализ требований, проектирование системной архитектуры, анализ
требований к программным средствам и т.д. Для каждого действия
дается подробное описание его задач. Это множество действий и за-
дач, представленных в процессах ЖЦ ПП и отображенных в стан-
дарте, содержательно связано с областями знаний программной ин-
женерии.

По принципу ответственности субъекта (заказчика, поставщика,
разработчика и т.д.), реализующего конкретный процесс, можно вы-
делить 17 процессов жизненного цикла. В свою очередь, каждый
из процессов состоит из ряда работ и решаемых при выполнении
соответствующей работы задач. С точки зрения соподчиненности
и важности данных процессов они разбиты на три группы, основные,
вспомогательные и организационные (рис. 2 1).

Основными процессами являются процесс приобретения, процесс
поставки, процесс разработки, процесс эксплуатации, процесс со-
провождения.

Процесс приобретения инициирует ЖЦ ПП и определяет действия
организации-покупателя (или заказчика), которая приобретает ав-
томатизированную систему, программный продукт или сервис. Этот
процесс включает в себя следующие виды деятельности: инициацию;
подготовку запроса, контракта и его актуализацию; мониторинг по-
ставщиков; приемку и завершение
Рис. 2.1. Процессы жизненного цикла ПП (стандарт ISO/TEC12207)

Проиесс поставки регламентирует действия предприятия-постав-
щика, которое снабжает покупателя системой, программным про-
дуктом или сервисом. Данный процесс состоит из инициации и под-
готовки предложений (ответа на запрос), контракта, планирования,
выполнения и контроля, анализа и оценки, поставки и завершения.

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

Процесс разработки определяет действия предприятия-разработ-
чика ПП, к которым относятся внедрение процесса (implementation),
анализ требований к системе, проектирование архитектуры системы,
анализ требований к ПО, проектирование архитектуры ПО, деталь-
ное проектирование, кодирование и тестирование, интеграция ПО,
интеграция системы, квалификационное тестирование, установка
системы и обеспечение приемки.

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

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

К вспомогательным (обеспечивающим) процессам создания ПС от-
носятся: документирование, управление версиями, верификация
(проверка правильности сборки ПС) и валидация (проверка ПС
на адекватность требованиям заказчика), просмотры, аудиты, оце-
нивание продукта и др.

Процессы управления версиями соответствуют управлению конфи-
гурацией системы, которая, также как и продукты процесса, должна
проверяться на правильность реализации целей проекта и соответ-
ствия требованиям заказчика. Задачи проверки рекомендуется вы-
полнять специальным контролерам, обладающим знаниями методов
и процессов.

К организационным процессам относятся процессы управления
проектом (менеджмент разработки), управления качеством, управ-
ления рисками и др.
Эти процессы организационно поддерживаются специальными
службами: контроля процессов, измерения продуктов, проверки каче-
ства, соблюдения стандартных положений и др. Предполагается про-
ведение обучения персонала, определение набора задач и ответствен-
ности каждого участника в реализации задач на процессах ЖЦ и др.

Процессы, определенные в стандарте, образуют полное множе-
ство (все возможные виды процессов). Пользователь стандарта мо-
жет выбрать соответствующее подмножество для достижения своей
конкретной цели. Процессы, действия и задачи приведены в стан-
дарте в наиболее общей естественной последовательности. В зави-
симости от целей конкретного проекта процессы, действия и задачи
выбираются, упорядочиваются и применяются итерационно или
рекурсивно. Разработчик должен определить или выбрать модель
ЖЦ ПП в зависимости от сложности, стоимости и ресурсов прог-
раммного проекта. Отдельно представлен процесс адаптации стан-
дарта, содержащий описание основных работ, которые должны быть
выполнены при адаптации настоящего стандарта к условиям кон-
кретного программного проекта.

Адаптация стандарта ISO 12207. Адаптация стандарта подразуме-
вает применение требований стандарта к конкретному проекту или
проектам, например в рамках создания внутрикорпоративных регла-
ментов ведения проектов ПО.

Адаптация включает в себя следующие виды работ: определение
исходной информации для адаптации стандарта; определение
условий выполнения проекта; отбор процессов, работ и задач, ис-
пользуемых в проекте или соответствующих регламентах; докумен-
тирование требований, решений и процессов, связанных с адапта-
цией и полученных в результате ее проведения.

Адаптация также подразумевает выбор модели (или комбинации
моделей) ЖЦ и применение соответствующих методологий, детали-
зирующих процедуры выполнения процессов, работ и задач в рамках
заданных границ (содержания) ЖЦ ПО с учетом организационной
структуры и ролевой ответственности в конкретной организации
(ее подразделениях) и/или в проектной группе.

Необходимо отметить, что существует еще один стандарт жизнен-
ного цикла — ISO/IEC15288 (выпущен в 2002 г.), освещающий во-
просы организации процессов ЖЦ системного уровня (Life Cycle
Processes — System) и включающий специальный процесс «Tailoring»,
т.е настройку, адаптацию ЖЦ к конкретным требованиям и ограни-
чениям, существующим или принятым в конкретной организации
(подразделении) или для заданного проекта.
Не бывает двух одинаковых проектов, поскольку вариации в ор-
ганизационных службах и процедурах, методах и стратегиях при-
обретения, размере и сложности проекта, требованиях системы и ме-
тодах разработки влияют на способ создания, применения и сопро-
вождения ПП. Используемые реально в фирмах жизненные циклы
часто отличаются от приведенных в стандартах в связи с развитием
и внедрением объектно-ориентированного анализа и проектирова-
ния, методов быстрой разработки прикладных программ и систем,
поддерживающих многие этапы ЖЦ. а также новых языков прог-
раммирования. В современных технологиях сокращаются стадии
непосредственного создания программных и информационных ком-
понентов и детализируются процессы системного анализа и проек-
тирования программной системы в целом. Кроме того, возрастают
роль и степень конкретизации работ по технологической поддержке
и графической визуализации проектирования, а также по стандар-
тизации интерфейсов компонентов в создаваемых приложениях.

Особое внимание уделяется детализации процессов ЖЦ, обеспе-
чивающих высокое качество создаваемых ПП, и возможности их
эффективного итерационного развития на протяжении длительного
времени в многочисленных версиях. Отечественные разработчики
и пользователи современных инструментальных средств создания
программ, как правило, не знают и не учитывают опыт, формализо-
ванный и отраженный в зарубежных стандартах на ЖЦ ПП. Техно-
логические комплексы собираются из отдельных, слабо связанных
инструментальных пакетов прикладных программ, решающих
частные задачи автоматизации без анализа и учета всего ЖЦ ПП.
В результате технология и процессы разработки формируются не си-
стемно — с позиции достижения наивысших показателей эффектив-
ности и качества всего ЖЦ конкретного ПП, а с позиции скорейшего
достижения видимых для заказчика результатов проекта. В случае
критических ПС это отрицательно сказывается впоследствии на их
надежности функционирования и безопасности применения, а также
затрудняет модернизацию и развитие версий.

Альтернативой является формирование комплекса инструмен-
тальных средств под технологию, формализованную на базе одного
из адаптированных стандартов ЖЦ ПП. Для снижения затрат и обес-
печения качества выбранный стандарт ЖЦ следует адаптировать
к индивидуальному проекту ПС. Должны быть определены характе-
ристики окружения проекта, которые могут воздействовать на адап-
тацию. Этими характеристиками могут быть: функции ЖЦ инфор-
мационной системы; требования системы и ПО, организационные
основы коллективов специалистов, процедуры и стратегии их ра-
боты; размер, критичность и типы системы; число задействованного
персонала и сторон-участников.

Применение требований ГОСТ Р ИСО/МЭК 12207 к конкрет-
ному проекту — адаптация стандарта — состоит из следующего вида
работ:

•	определение условий выполнения проекта;

•	запрос исходных данных для адаптации;

•	выбор процессов, работ и задач;

•	документирование решений по адаптации и их обоснований.

При определении условий выполнения проекта должны быть заданы
характеристики условий выполнения проекта, влияющие на адапта-
цию (например, модель ЖЦ, требования к системе, организацион-
ные подходы, процедуры и цели, размер, критичность и тип сис-
темы, ПО продукта или услуги, количество задействованного персо-
нала и участвующих в проекте сторон).

При запросе исходных данных для адаптации от участвующих
в проекте субъектов должны быть запрошены и получены исходные
данные, которые могут повлиять на решения по адаптации. В работы
по адаптации должны быть вовлечены пользователи, персонал со-
провождения, заказчик и потенциальные поставщики.

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

При проведении работ по адаптации следует руководствоваться
также рекомендациями в части классификации ПС и в части выбора
и построения модели ЖЦ ПП. Так, построение модели ЖЦ ПП должно
базироваться на концептуальной идее системы, охватывать разработку
(создание), эксплуатацию и сопровождение и оканчиваться снятием
(утилизацией). Модель ЖЦ обычно разбивается на периоды реали-
зации, например стадии или этапы. Каждое такое разбиение должно
охватывать отдельные работы и задачи, реализуемые в данном периоде
(стадии, этапе), и при их завершении может потребоваться разрешение
сторон на переход к следующему периоду модели.

Вопросы адаптации общей структуры ЖЦ ПП, описанной
в ГОСТ Р ИСО/МЭК 12207, являются ключевыми при выборе (по-
строении) модели ЖЦ ПП (автономной или входящей в состав об-
щей модели ЖЦ создаваемой системы) в условиях реализации кон-
кретного проекта. Процессы адаптации общей структуры ЖЦ ПП
по ГОСТ Р ИСО/МЭК 12207 строятся на двух исходных принципах:
модульности и ответственности.

Принцип модульности основан на следующих положениях. Каж-
дый процесс сильно связан, т.е. организован таким образом, что все
части процесса (работы, задачи) строго взаимосвязаны. Процессы
свободно соединены между собой. Количество интерфейсов между
процессами сведено к минимуму. Каждый процесс предназначен для
реализации уникальной функции в ЖЦ и может привлекать другой
процесс для выполнения специализированной функции.

При определении области применения и структурирования про-
цессов должны использоваться следующие правила.

1.	Процесс должен быть своего рода модулем ЖЦ, т.е. каждый
процесс должен выполнять только собственную функцию в ЖЦ,
а интерфейсы между двумя любыми процессами должны быть ми-
нимальны.

2.	Каждый процесс должен быть привязан к архитектуре сис-
темы.

3.	Если процесс А вызван процессом В и только процессом В,
тогда А принадлежит к В.

4.	Если работа или задача вызвана более чем одним процессом,
тогда она сама становится процессом.

5.	Должна быть возможность для проверки любого процесса, ра-
боты и задачи в модели ЖЦ.

6.	Каждый процесс должен иметь внутреннюю структуру, уста-
новленную в соответствии с тем, что должно выполняться.

Принцип ответственности базируется на определенных обязан-
ностях каждого субъекта, вовлеченного в ЖЦ. Субъект может выпол-
нять один или несколько процессов. Процесс может быть выполнен
одним или несколькими субъектами, при этом один из субъектов
должен быть определен ответственным за процесс. Субъект, выпол-
няющий процесс, несет ответственность за зесь данный процесс,
даже если выполнение отдельных работ (задач) поручено другим
субъектам. Ответственность является особенностью структуры ЖЦ
применительно к условиям проекта, в который закономерно может
быть вовлечено множество субъектов.

Применение ГОСТ Р ИСО/МЭК 12207 безусловно требует от со-
ответствующих субъектов определенных усилий по его адаптации
к условиям реализации конкретных проектов. Кроме того, необхо-
дима его увязка с конкретными методиками разработки систем
и другими стандартами. Тем не менее можно полагать, что внедрение
данного стандарта в практическую деятельность должно облегчить
и упорядочить взаимоотношения между субъектами, вовлеченными
вЖЦПП.

В стандартах на ЖЦ ПП отражено содержание этапов работ и ре-
зультирующих документов на методологическом и концептуальном
уровнях. Методы и средства реализации каждой работы в этих стан-
дартах не раскрываются и адресуются к специальным, детализиру-
ющим нормативным документам различного уровня. Однако ряд
характерных особенностей этапов принципиально не позволяет со-
здать полную гамму международных стандартов, поддерживающих
все этапы и процессы ЖЦ ПП. Например, быстро оснащающиеся
различными методами и инструментальными средствами этапы си-
стемного анализа, моделирования и предварительного проектирова-
ния не позволяют стабилизировать основу этих процессов, достаточ-
ную для формализации на уровне международных стандартов, под-
готовка которых может длиться несколько лет. Для этих этапов
создаются нормативные документы на уровне стандартов «де-
факто», руководства фирм или сопровождающей документации
на конкретные инструментальные средства.

ISO 15504. Процессы ЖЦ ПП. Стандарт ISO 12207 разрабаты-
вался девять лет и достаточно быстро устарел. В 1998 г. вышел новый
стандарт ISO/1EC TR15504: Information Technology — Software Process
Assessment (Оценка процессов разработки ПО) В этом документе
рассматриваются вопросы аттестации, определения зрелости и усо-
вершенствования процессов жизненного цикла ПП. Один из разде-
лов документа содержит новую классификацию процессов ЖЦ ПП,
являющуюся развитием стандарта ISO 12207.

Все процессы стандарта ISO 15504 принадлежат к одному из сле-
дующих типов:

•	основной (процесс из 12207);

•	расширенный (расширение процесса из 12207);

•	новый (процесс, не описанный в 12207);

•	составляющий (часть процесса из 12207);

•	расширенный составляющий (расширенная часть процесса
из 12207).

В соответствии с новой классификацией вводятся пять категорий
процессов. В группу основных процессов введены две категории:

•	потребитель-поставщик (категория CUS);

•	инженерная (категория ENG).
Группа вспомогательных процессов представлена одной категорией:

•	вспомогательная (категория SUP).

В группу организационных процессов введены две категории:

•	управленческая (категория MAN);

•	организационная (категория GRG).

Категория потребитель-поставщик состоит из процессов, непо-
средственно влияющих на потребителя, поддерживающих разра-
ботку программного средства и его передачу потребителю, обеспе-
чивающих возможность корректного использования программного
средства или услуги.

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

Вспомогательная категория содержит процессы, которыми могут
пользоваться любые другие процессы (включая другие вспомогатель-
ные процессы) в различные моменты ЖЦ ПП.

В управленческую категорию входят процессы, содержащие прак-
тики общего характера, которые могут быть использованы при
управлении проектом или процессом в ходе ЖП ПП.

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

Организационные процессы создают и поддерживают инфра-
структуру организации, используют передовой опыт — все лучшее
из того, что имеется во всех подразделениях организации (эффек-
тивные процессы, лучшие навыки, качественный программный код,
хорошие средства поддержки), делают это общедоступным в рамках
всей организации и, наконец, создают базу для постоянного совер-
шенствования всей организации в целом.
2.3.	Модели жизненного цикла
программного продукта

За десятилетия опыта построения программных систем был на-
работан ряд типичных схем выполнения работ при проектировании
и разработке. Такие схемы получили название моделей ЖЦ. Модель
жизненного цикла — это схема выполнения работ и задач на процес-
сах, обеспечивающих разработку, эксплуатацию и сопровождение
программного продукта, отражающая жизнь ПП, начиная от форму-
лировки требований к нему до прекращения его использования. Ис-
торически модель жизненного цикда включает в себя

1)	разработку требований или технического задания;

2)	разработку системы или технического проекта;

3)	программирование или рабочее проектирование;

4)	пробную эксплуатацию;

5)	сопровождение и улучшение;

6)	снятие с эксплуатации.

Выбор и построение модели ЖЦ ПП базируется на концептуаль-
ной идее проектируемой системы, с учетом ее сложности и в соот-
ветствии со стандартами, позволяющих формировать схему выпол-
нения работ по усмотрению разработчика и заказчика.

Модель ЖЦ разбивается на процессы реализации, которые
должны включать отдельные работы и задачи, реализуемые в данном
процессе, и при их завершении осуществлять переход к следующему
процессу.

При выборе общей схемы модели ЖЦ для конкретной предметной
области решаются вопросы включения или невключения отдельных
работ, очень важных для создаваемого вида продукта. В настоящее
время основой формирования новой модели ЖЦ для конкретной
прикладной системы является стандарт ISO/IEC12207, который опи-
сывает полный набор процессов (более 40), охватывающий все воз-
можные виды работ и задач, связанных с построением ПС.

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

Процессы, включенные в модель ЖЦ, предназначены для реали-
зации уникальной функции ЖЦ и могут привлекать другие процессы
для выполнения специализированных возможностей системы (на-
пример, защиты данных). Интерфейсы между двумя любыми про-
цессами ЖЦ должны быть минимальными и каждый из них привя-
зан к архитектуре системы.

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

Процессы модели ЖЦ ориентированы на разработчика системы.
Он может выполнять один или несколько процессов. В свою очередь,
процесс может быть выполнен одним или несколькими разработчи-
ками, при этом кто-то из них назначается ответственным за один
процесс или за все процессы модели.

Создаваемая модель ЖЦ увязывается с конкретными методиками
разработки систем и соответствующими стандартами в области про-
граммной инженерии. Иными словами, каждый процесс ЖЦ под-
крепляется выбранными для реализации его задач средствами и ме-
тодами

Важную роль при формировании модели ЖЦ имеют организаци-
онные аспекты: планирование последовательности работ и сроков
их исполнения; подбор и подготовка ресурсов (людских, прог-
раммных и технических) для выполнения работ; оценка возможно-
стей реализации проекта в заданные сроки и с заданной стоимостью
и др.

Внедрение модели ЖЦ в практическую деятельность по созданию
программного продукта позволяет упорядочить взаимоотношения
между субъектами процесса и максимально учитывать динамику мо-
дификации требований к проекту и системе.

Эти и другие не менее важные вопросы послужили источником
формирования различных видов моделей ЖЦ, основанных на про-
цессном подходе к разработке программных проектов. Основными
среди них, положительно зарекомендовавшими себя в практике
программирования, являются каскадная, спиральная, инкрементная,
эволюционная и стандартизованная модели.
Каскадная модель. Каскадная {водопадная — waterfall) модель вклю-
чает б себя выполнение следующих фаз (рис. 2.2):

1)	исследование концепции: происходит исследование требова-
ний, разрабатывается видение продукта и оценивается возможность
его реализации;

2)	выработка требований: определяются программные требования
для информационной предметной области системы, а также предна-
значение, линия поведения, производительность и интерфейсы;

3)	проектирование: разрабатывается и формулируется логически
последовательная техническая характеристика программной сис-
темы, включая структуру данных, архитектуру ПО, интерфейсные
представления и процессуальную (алгоритмическую) детализацию;

4)	реализация: эскизное описание ПС превращается в полноцен-
ный программный продукт, результатом является исходный код, база
данных и документация; в реализации обычно выделяют два этапа:
реализацию компонентов ПО и интеграцию компонент в готовый
продукт; на обоих этапах выполняется кодирование и тестирование,
которые тоже иногда рассматривают как два подэтапа;

5)	эксплуатация и поддержка: подразумевает запуск и текущее
обеспечение, включая предоставление технической помощи, обсуж-
дение возникших вопросов с пользователем, регистрацию запросов
пользователя на модернизацию и внесение изменений, а также кор-
ректирование и/или устранение ошибок;

6)	сопровождение: устранение программных ошибок, неисправ-
ностей, сбоев, модернизация и внесение изменений, что обычно
приводит к повторению или итерации отдельных этапов разработки.

Рис. 2.2. Каскадная модель Ж Ц ПП
Основной принцип построения каскадной модели заключается
в строго последовательном выполнении фаз, те. каждая последую-
щая фаза начинается лишь тогда, когда полностью завершено вы-
полнение предыдущей фазы.

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

Основой модели служат сформулированные в техническом зада-
нии (ТЗ) требования, которые меняться не должны. Критерием ка-
чества результата является соответствие продукта установленным
требованиям.

Преимущества каскадной модели состоят в следующем. Модель
проста, удобна в применении и понятна заказчикам, так как часто
используется другими организациями для отслеживания проектов,
не связанных с разработкой ПО. Процесс разработки выполняется
поэтапно, и ее структурой может руководствоваться даже слабо под-
готовленный в техническом плане или неопытный персонал. Она
способствует осуществлению строгого контроля менеджмента про-
екта, каждую стадию могут выполнять независимые команды, все
документировано, что позволяет достаточно точно планировать
сроки и затраты.

При использовании каскадной модели для «неподходящего» про-
екта могут проявляться следующие ее недостатки'.

•	попытка вернуться на одну или две фазы назад, чтобы исправить
какую-либо проблему или недостаток, приведет к значительному
увеличению затрат и сбою в графике;

•	интеграция компонентов, на которой обычно выявляется боль-
шая часть ошибок, выполняется в конце разработки, что сильно
увеличивает стоимость устранения ошибок;

•	запаздывание с получением результатов (если в процессе выпол-
нения проекта требования изменились, то получится устаревший
результат).

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

Каскадная модель была впервые четко сформулирована в 1970 г.
У. Ройсом. На начальном периоде она сыграла ведущую роль как
метод регулярной разработки сложного ПО. В 70—80-х гг. XX в. мо-
дель была принята как стандарт министерства обороны США.
Со временем недостатки каскадной модели стали проявляться все
чаще и возникло мнение, что она безнадежно устарела. Между тем
каскадная модель не утратила своей актуальности при решении опре-
деленного типа задач, когда требования и их реализация макси-
мально четко определены и понятны или используется неизменяемое
определение продукта и вполне понятные технические методики,
например при решении задач научно-вычислительного характера
(разработка пакетов и библиотек научных программ); при разработке
операционных систем и компиляторов, систем реального времени
управления конкретными объектами; при повторной разработке ти-
пового продукта (автоматизированного бухгалтерского учета, начи-
сления зарплаты); при выпуске новой версии уже существующего
продукта, если вносимые изменения вполне определены и управля-
емы (перенос уже существующего продукта на новую платформу);
и наконец, принципы каскадной модели находят применение в эле-
ментах моделей других типов

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

Циклический характер разработки ПО отражается в спиральной
модели ЖП, описанной Б. Боэмом в 1988 г. Эта модель, учитыва-
ющая повторяющийся характер разработки ПО (рис 2.3), была пред-
ложена как альтернатива каскадной модели

Основные принципы спиральной модели можно сформулировать
следующим образом.

1.	Разработка нескольких вариантов продукта, соответствую]цих
различным вариантам требований, с возможностью вернуться к бо-
лее ранним вариантам.

2.	Создание прототипов ПО как средства общения с заказчиком
для уточнения и выявления требований.
Определение целей,
альтернатив,
ограничений "

Суммарная
стоимость

Оценка альтернатив
выявить и решить риски

Рабочий
.прототип

Треб
. ЖЦ

Концеп-/Требо-

вания

Проверка
гребовани]

Проект
ПО

етальныи

проект

Коди-
рова-

Проверка
проекта

Стадии
разработки

Планирование
следующих фаз

Внедрение!

уровня

Рис. 2.3. Спиральная модель ЖЦ ПП:
АР — анализ рисков; П — прототип

3.	Планирование следующих вариантов с оценкой альтернатив
и анализом рисков, связанных с переходом к следующему варианту.

4,	Переход к разработке следующего варианта до завершения
предыдущего в случае, когда риск завершения очередного варианта/
прототипа становится неоправданно высок.

5.	Использование каскадной модели как схемы разработки оче-
редного варианта продукта.

6	Активное привлечение заказчика к работе над проектом. За-
казчик участвует в оценке очередного прототипа, уточнении требо-
ваний при переходе к следующему, оценке предложенных альтерна-
тив очередного варианта и опенке рисков

Разработка вариантов продукта в спиральной модели представля-
ется как набор циклов раскручивающейся спирали (см. рис. 2.3).
Каждому циклу соответствует такое же количество стадий, как и в ка-
скадной модели. При этом начальные стадии, связанные с анализом
и планированием, представлены более подробно с добавлением но-
вых элементов. В каждом цикле выделяются четыре базовые фазы:

1)	определение целей, альтернативных вариантов и ограничений;

2)	оценка альтернативных вариантов, идентификация и разреше-
ние рисков;

3)	разработка продукта следующего уровня;

4)	планирование следующей фазы.

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

Следующий цикл начинается с планирования требований и дета-
лей ЖЦ продукта для оценки затрат. На фазе определения целей
устанавливаются альтернативные варианты требований, связанные
с ранжированием требований по важности и стоимости их выполне-
ния. На фазе оценки устанавливаются риски вариантов требований.
На фазе разработки — спецификация требований (с указанием
рисков и стоимости), готовится демоверсия ПО для анализа требо-
ваний заказчиком

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

Цикл реализации также начинается с планирования. Альтерна-
тивными вариантами реализации могут быть применяемые техноло-
гии реализации, привлекаемые ресурсы. Оценка альтернатив и свя-
занных с ними рисков определяется степенью «отработанности»
технологий и «качеством» имеющихся ресурсов. Фаза разработки
выполняется по каскадной модели с выходом в виде действующего
варианта/прототипа продукта

Следует отметить некоторые особенности спиральной модели.
До начала разработки ПП есть несколько полных циклов анализа
требований и проектирования. Количество циклов (в части анализа,
проектирования и реализации) не ограничено и определяется слож-
ностью и объемом задачи. В модели предполагаются возвраты
на оставленные варианты при изменении стоимости рисков.

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

Основные недостатки спиральной модели связаны с такими фак-
торами, как.

•	сложность анализа и оценки рисков при выборе вариантов;

•	сложность поддержания версий продукта (хранение версий, воз-
врат к ранним версиям, комбинация версий);

•	сложность оценки точки перехода на следующий цикл;

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

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

Каскадная и спиральная модели устанавливают определенные
принципы организации ЖЦ создания программного продукта.
Каждая из них имеет преимущества, недостатки и области примени-
мости. Каскадная модель проста, но применима в случае, когда тре-
бования известны и меняться не будут. Спиральная модель учитывает
такие важные показатели проекта, как изменяемость требований,
невозможность оценить заранее объем финансирования, риски вы-
полнения проекта. Нс спиральная модель сложна и требует больших
затрат на сопровождение.

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

Рис. 2.4. Итерационная модель ЖЦ ПП

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

V-образная модель. Данная модель также была предложена как ите-
рационная разновидность каскадной модели (рис. 2.5). Целью итера-
ций в этой модели является обеспечение процесса тестирования.
Тестирование продукта обсуждается, проектируется и планируется
на ранних этапах ЖЦ разработки. План испытания приемки заказ-
чиком разрабатывается на этапе планирования, а компоновочного
испытания системы — на фазах анализа, разработки проекта и т.д.
Рис. 2.5. V-образная модель ЖЦ ПП

Этот процесс разработки планов испытания на рисунке обозначен
пунктирной линией между прямоугольниками V-образной модели.
Помимо планов, на ранних этапах разрабатываются также и тесты,
которые будут выполняться при завершении параллельных этапов.

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

Рис. 2.6. Инкрементная модель ЖЦ ПП
требований и выполняется полный «проход» по каскадной модели.
После того как первый вариант системы, выполняющий первую
группу требований, сдан заказчику, разработчики переходят к следу-
ющему шагу (инкременту 2) по разработке варианта, выполняющего
вторую группу требований, и т.д.

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

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

2.4.	Модели процесса разработки
программного продукта

В настоящее время широкое применение получают промышлен-
ные технологии создания ПП. Это разработки фирм, накопивших
большой опыт создания ПО. Такие технологии представлены описа-
ниями принципов, методов, применяемых процессов и операций
и, как правило, поддерживаются набором CASE-средств (Computer-
Aided Software Engineering), охватывают все этапы ЖЦ ПП и успешно
применяются для решения практических задач. Рассмотрим особен-
ности моделей жизненного цикла трех наиболее известных промыш-
ленных технологий.

1.	Microsoft Solution Framework (MSF) — методология разработ-
кипрограммного обеспечения фирмы «Microsoft», предназначенная
для решения широкого круга задач. Технология масштабируема,
т.е. настраиваема на решение задач любой сложности коллективом
любой численности.

2.	Rational Unified Process (RUP) — разработка фирмы «Rational»,
долгое время успешно занимавшейся созданием CASE-средств, при-
меняемых на различных этапах жизненного цикла продукта от ана-
лиза до тестирования и документирования. Аналогично MSF техно-
логия RUP универсальна, масштабируема и настраиваема на приме-
нение в конкретных условиях.

3.	Extreme Programming (ХР) — методология экстремального
программирования, активно развивающаяся в последнее время
и предназначенная для решения относительно небольших задач от-
носительно небольшими коллективами профессиональных разра-
ботчиков в условиях жестко ограниченного времени.

Модель Microsoft Solution Framework. Одна из особенностей тех-
нологии MSF состоит в том, что она ориентирована не просто на со-
здание ПП, удовлетворяющего перечисленным требованиям,
а на поиск решения проблем, стоящих перед заказчиком Как пра-
вило, предъявляемые заказчиком требования направлены на устра-
нение некоторых глубоких проблем; и неточность, неполнота,
а также изменение требований в процессе разработки — следствие
их недопонимания. Поэтому в технологии MSF большое внимание
уделяется анализу проблем заказчика и разработке вариантов сис-
темы для поиска их решения.

Модель жизненного цикла MSF является некоторым гибридом
каскадной и спиральной моделей, сочетая простоту управления ка-
скадной модели с гибкостью спиральной. Схема модели MSF (мо-
дели процессов) представлена на рис. 2.7. Модель жизненного цикла
MSF ориентирована на «вехи» (milestones), т.е. ключевые точки про-
екта, характеризующие достижение какого-либо существенного ре-
зультата. Этот результат может быть оценен и проанализирован, что
подразумевает ответ на вопрос: «А достигли ли мы целей, постав-
ленных на этом шаге?». В модели предусматривается наличие ос-
новных вех (завершение главных фаз модели) и промежуточных,
отражающих внутренние этапы главных фаз.

Развертывание
(Deploying)

Стабилизация
(Stabilizing)

Подтверждение
готовности проекта
к выпуску

Разработка (Developing)

Утверждение
проектных планов

Планирование
(Planning)

Утверждение документа
общей картины

Рис. 2.7. Модель жизненного цикла MSF

Окончательное утверждение
области действия проекта

Создание общей
картины (Envisioning)
Основные фазы модели MSF.

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

2.	Планирование (Panning). Включает планирование и проектиро-
вание продукта. На основе анализа требований разрабатывается про-
ект и основные архитектурные решения, функциональные специфи-
кации системы, планы и календарные графики; выбираются среды
разработки, тестирования и пилотной эксплуатации. Этап состоит
из трех стадий: концептуальное, логическое и физическое проекти-
рование. На стадии концептуального проектирования задача рассмат-
ривается с точки зрения пользовательских и бизнес-требований и за-
канчивается определением набора сценариев использования сис-
темы. При логическом проектировании задача рассматривается
с точки зрения проектной команды, решение представляется в виде
набора сервисов. И уже на стадии физического проектирования задача
рассматривается с точки зрения программистов, уточняются исполь-
зуемые технологии и интерфейсы.

3.	Разработка (Developing). Создается вариант решения проб-
лемы в виде кода и документации очередного прототипа, включая
спецификации и сценарии тестирования. Основная веха этапа —
«Окончательное утверждение области действия проекта». Продукт
готов к внешнему тестированию и стабилизации. Кроме того, заказ-
чики, пользователи, сотрудники службы поддержки и сопровож-
дения, а также ключевые участники проекта могут предварительно
оценить продукт и указать все недостатки, которые нужно устранить
до его поставки.

4.	Стабилизация (Stabilizing). Подготовка к выпуску окончатель-
ной версии продукта, доводка его до заданного уровня качества.
Здесь выполняется комплекс работ по тестированию (обнаружение
и устранение дефектов), проверяется сценарий развертывания сис-
темы.

5.	Развертывание (Deploying). Выполняется установка продукта
и необходимых компонентов окружения, проводится его стабилиза-
ция в промышленных условиях и передача проекта в группу сопро-
вождения, которая анализирует проект в целом на предмет уровня
удовлетворенности заказчика.
Модель Rational Unified Process является довольно сложной, де-
тально проработанной итеративно-инкрементной моделью с элемен-
тами каскадной модели. В модели RUP выделяются четыре основные
фазы, а также девять видов деятельности (процессов). Кроме того,
в модели описывается ряд практик, которые следует применять или
руководствоваться для успешного выполнения проекта. RUP ориен-
тирована на поэтапное моделирование создаваемого продукта с по-
мощью UML (Unified Modeling Language — унифицированный язык
моделирования).

Основными фазами модели RUPявляются следующие (рис. 2.8).

1.	Начало проекта (Inception). Определяются основные цели про-
екта, его бюджет, основные средства его выполнения: технологии,
инструменты, ключевой персонал; составляются предварительные
планы проекта. Основная цель этой фазы — достичь компромисса
между всеми заинтересованными лицами относительно задач проекта.

2.	Проработка (Elaboration). Основная цель этой фазы — на базе
основных, наиболее существенных требований разработать стабиль-
ную базовую архитектуру продукта, которая позволит решать постав-
ленные перед системой задачи и в дальнейшем будет использована
как основа для разработки системы.

3.	Построение (Construction). Основная цель этой фазы — деталь-
ное прояснение требований и разработка системы, удовлетворяющей
им, на основе спроектированной ранее архитектуры.

4.	Передача (Transition). Цель фазы — сделать систему полностью
доступной конечным пользователям. Здесь происходит окончатель-
ное развертывание системы в ее рабочей среде, подгонка мелких де-
талей под нужды пользователей.

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

Основные процессы {деятельности) RUP делятся на пять рабочих
и четыре поддерживающих.

К рабочим процессам относятся следующие.

1.	Моделирование предметной области (Business Modeling — биз-
нес-моделирование). Цель этой деятельности — понять бизнес-кон-
текст, в котором должна будет работать система (и убедиться, что все
заинтересованные лица понимают его одинаково), предвидеть воз-
можные проблемы, оценить их возможные решения и последствия
для бизнеса организации, в которой будет работать система.

2.	Определение требований (Requirements). Цель — понять, что
должна делать система, определить границы системы, основу для
планирования проекта и оценок ресурсозатрат в нем.

3.	Анализ и проектирование (Analysis and Design). Выработка ар-
хитектуры системы на основе ключевых требований, создание про-
ектной модели, представленной в виде UML-диаграмм, описыва-
ющих программный продукт с различных точек зрения.

4.	Реализация (Implementation). Разработка исходного кода ком-
понентов системы, тестирование и интегрирование компонент.

5.	Тестирование (Test). Общая оценка дефектов продукта и его
качества в целом, оценка степени соответствия разработанного про-
дукта исходным требованиям.

Поддерживающими процессами являются следующие четыре про-
цесса.

1.	Развертывание (Deployment). Цель — развернуть систему в ее
рабочем окружении и оценить ее работоспособность.

2	Управление конфигурациями и изменениями (Configuration and
Change Management). Определение элементов, подлежащих хране-
нию, и правил построения из них согласованных конфигураций,
поддержание целостности текущего состояния системы, проверка
согласованности вносимых изменений.

3.	Управление проектом (Project Management). Включает плани-
рование, управление персоналом, обеспечение связей с другими за-
интересованными лицами, управление рисками, отслеживание те-
кущего состояния проекта.

4.	Управление средой проекта (Environment). Настройка процесса
под конкретный проект, выбор и смена технологий и инструментов,
используемых в данном проекте.
Модель Extreme Programming является итерационно-инкремент-
ной моделью быстрого создания и модификации протопопов прог-
раммного продукта, которые должны удовлетворять очередному
требованию (user story). Модель ХР представлена на рис. 2 9.

Модель ХР включает в себя выполнение следующих основных фаз.

1.	< Вброс» архитектуры — начальный этап проекта, на котором
создается видение продукта, принимаются основные решения по ар-
хитектуре и применяемым технологиям. Результатом начального
этапа является метафора (metaphor) системы, которая в достаточно
простом и понятном команде виде должна описывать основной ме-
ханизм работы системы.

2.	Истории использования (User Story) — этап сбора требований,
записываемых на специальных карточках в виде сценариев выпол-
нения отдельных функций. Истории использования являются тре-
бованиями для планирования очередной версии и разработки при-
емочных тестов (Acceptance tests) для ее проверки.

3.	Планирование версии (релиза). Проводится на собрании с учас-
тием заказчика путем выбора User Stories, которые войдут в следу-
ющую версию. Одновременно принимаются решения, связанные
с реализацией версии. Цель планирования — получение оценок того,
что и как можно сделать за 1—3 недели создания следующей версии
продукта.

4.	Разработка версии (релиза) проводится в соответствии с пла-
ном и включает только те функции, которые были отобраны на этапе
планирования.

5.	Тестирование версии (релиза) проводится с участием заказчика,
который ранее участвовал в составлении тестов.

6.	Выпуск релиза — разработанная версия передается заказчику
для использования или бета-тестирования.

По завершении цикла делается переход на следующую итерацию
разработки.

Особенности модели жизненного цикла ХР проясняют основные
принципы этого метода, и прежде всего это принципы «живой» раз-
работки ПО, отраженные в манифесте «живой» разработки ПО'. люди
и их общение более важны, чем процессы и инструменты; работа-
ющая программа более важна, чем исчерпывающая документация;
сотрудничество с заказчиком более важно, чем обсуждение деталей
контракта; отработка изменений более важна, чем следование пла-
нам.

Основные правила модели ХР также характеризуют ее особенности
и основные техники применения:
Рис. 2.9. Модель жизненного цикла ХР
•	живое планирование (planning game), направленное на то, чтобы
как можно быстрее определить объем работ, который нужно сде-
лать до разработки следующей версии ПО; решение принимается
на основе, в первую очередь, бизнес-приоритетов заказчика
и, во-вторую. технических оценок; при этом планы изменяются,
как только они начинают расходиться с действительностью или
пожеланиями заказчика;

•	частая смена версий (small releases): первая работающая версия
должна появиться как можно быстрее и тут же должна использо-
ваться, следующие версии подготавливаются через достаточно
короткие промежутки времени;

•	простые проектные решения (simple design) в каждый момент
времени система конструируется так просто, насколько это воз-
можно, новые функции добавляются только после ясной и обос-
нованной просьбы, вся лишняя сложность удаляется, как только
обнаруживается;

•	разработка на основе тестирования (test-driven development) озна-
чает, что сначала пишутся тесты, демонстрирующие основные
возможности системы, чтобы можно было увидеть, что система
действительно заработала, а потом уже реализуются модули сис-
темы и таким образом, чтобы тесты срабатывали; при этом тесты
пишутся заказчиками (заранее);

•	постоянная переработка (refactoring) системы для устранения из-
лишней сложности, увеличения понятности кода, повышения его
гибкости, при этом предпочтение отдается более элегантным
и гибким решениям по сравнению с просто дающими нужный
результат;

•	программирование парами (pair programming): весь код пишется
двумя программистами на одном компьютере, что повышает его
качество (отсутствие ошибок, понятность, читаемость);

•	постоянная интеграция (continuous integration): система собира-
ется и проходит интеграционное тестирование как можно чаще,
по несколько раз в день, каждый раз, когда заканчивается реали-
зация очередной функции.

Контрольные вопросы

1.	Что понимают под понятиями ЖЦ ПП, модели и методологии ЖЦ?
Охарактеризуйте основные проблемы практического применения мо-
дели ЖЦ.

2.	Определите структуру и организацию стандарта ЖЦ ISO 12207 Назо-
вите основные результаты разработки этого стандарта.
3.	Охарактеризуйте стандарт ЖЦ ISO 15504 и его отличие от ISO 12207.

4.	Что подразумевается под адаптацией стандарта?

5.	Каковы основные особенности каскадной модели ЖЦ?

6.	В чем состоит главная особенность спиральной модели? Каковы сход-
ства и различия спиральной модели и классического ЖЦ?

7.	Каковы основные особенности итерационной модели ЖЦ?

8.	Каковы достоинства и недостатки инкрементной модели Ж11?

9.	Каковы основные промышленные модели процесса разработки ПП?

J 0. Каковы основные фазы модели MSF?

11.	Дайте характеристику модели RUP и ее основное отличие от модели
MSF.

12.	Каковы особенности модели ЖЦ ХР экстремального программиро-
вания?

Литература

1.	Брукс Ф Мифический человеко-месяц, или Как создаются прог-
раммные комплексы. — СПб.: Символ-Плюс, 2000. — 304 с.

2.	Вендров А.М. Проектирование программного обеспечения экономиче-
ских информационных систем: учебник. — М.: Финансы и статистика,
2006. - 544 с.

3.	ГОСТ 34.003-90: Информационная технология. Комплекс стандартов
и руководящих документов на автоматизированные системы. Термины
и определения. Госстандарт России, Москва, 1990.

4.	ГОСТ Р ИСО/МЭК 12207-99, Государственный стандарт Российской
Федерации, 1999. Госстандарт России, Москва, 2000.

5.	Кон М. Scram: гибкая разработка ПО. — М.: Вильямс, 2011 — 576 с.

6.	Мерри Кантор. Управление программными проектами. Практическое
руководство по разработке успешного программного обеспечения. —
М.: Вильямс, 2002. — 176 с.

7.	Орлов С.А. Технологии разработки программного обеспечения- учебник
для вузов. — СПб.: Питер, 2002. — 463 с.

8.	Основы инженерии качества программных систем / Ф.И. Андон,
ГИ. Коваль, ТМ. Коротун, В.Ю. Суслов. — Киев: Академпериодика,
2002. - 502 с.

9.	Скотт Амблер. Гибкие технологии: экстремальное программирование
и унифицированный процесс разработки. — СПб.: Питер, 2005. — 416 с.

10.	Соммервил Иан. Инженерия программного обеспечения. — 6-е изд. —
М.: Вильямс, 2002. — 624 с.

11.	Guide to Software Engineering Base of Knowledge (SWEBOK). IEEE Com-
puter Society, 2004. http://www.swebok.org/.

12.	ISO/IEC TR 15504, Information Technology—Software Process Assessment.
Part 1—9.

13.	ISO\IEC 12207: 1995-0801: Informational Technology — Software life cycle
processes.
14.	ISO-IEC 15288, System Life Cycle Processes. 2002.

15.	ISO/IEC 12207:2008 «System and software engineering — Software life cycle
processes» (российский аналог — ГОСТ P ИСО/МЭК 12207-2010: Ин-
формационная технология. Системная и программная инженерия.
Процессы жизненного цикла программных средств).

16.	Software Engineering (SE). Curriculum Guidelines for Undergraduate Degree
Programs in Software Engineering. A Volume of the Computing Curricula
Series. The Joint Task Force on Computing Curricula, IEEE Computer So-
ciety, Association for Computing Machinery, August 23, 2004. http://sites.
computer.org/ccse/.

17.	Sommerville lan. Software Engineering, 9th Edition, Addison-Wesley, 2011. —
773 c.
Глава 3

МОДЕЛИ И ПРОЦЕССЫ УПРАВЛЕНИЯ
ПРОГРАММНЫМ ПРОЕКТОМ

3.1. Общие вопросы

Перед тем как обсуждать собственно управление программным
проектом, необходимо более подробно рассмотреть, что такое проект
и что такое управление (понятие проекта см. в гл. 1).

Управление — изменение состояния объекта, системы или про-
цесса, ведущее к достижению поставленной цели. С точки зрения
данного определения существенными являются такие факторы, как
наличие цели управления, осуществимость управляющего воздей-
ствия, возможность измерений состояния объекта или процесса,
ограниченность управления.

Проект — протяженное во времени предприятие, направленное
на создание уникальных продуктов, услуг или иных результатов,
с определенной датой начала и окончания действия, отличающееся
от продолжающихся, повторных действий и требующее прогрессив-
ного совершенствования характеристик (в документах Project Man-
agement Institute — РМ1). В этом определении в той или иной сте-
пени отражаются следующие существенные характеристики про-
екта.

Цель проекта — наличие четко выраженного конечного резуль-
тата, выхода, продукции, определяемых в терминах затрат, качества
и времени реализации.

Уникальность. Проект — это разовое начинание, которое не будет
повторяться. Даже «повторяющиеся» проекты, например по строи-
тельству еще одного предприятия по той же проектной документа-
ции, значительно отличаются друг от друга использующимися ресур-
сами и средой реализации.

Ограниченность во времени. Проект имеет начало и конец. Для его
реализации необходима временная концентрация ресурсов. По окон-
чании надобности ресурсы используются на другие цели.

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

Неопределенность. Возможность достижения цели в указанные
сроки с выделенными ресурсами может быть заранее не гарантиро-
вана.

Предсказуемость. По мере реализации проекта изменяется по-
требность в тех или иных ресурсах. Это изменение идет в некоторой
предсказуемой последовательности, определяемой жизненным ци-
клом проекта. Иными словами, проект — это достаточно сложный
вид деятельности, которым сложно управлять в силу его уникально-
сти и ограниченности ресурсов и времени. Это обстоятельство вно-
сит в проект элемент неопределенности, но правильно организован-
ное управление делает результаты предсказуемыми, однако не всегда
успешными, т.е. проект может быть или вовремя завершенным
(успешным), или вовремя прекращенным (неуспешным).

Управление проектом. Известны несколько определений управ-
ления проектами, но наиболее полным можно считать определение,
сформулированное PMI в Своде знаний по управлению проектами
(Project Management Body of Knowledge — PMBOK): «Управление
проектом (Project Management — PM) — это наука и искусство руко-
водства и координации людских и материальных ресурсов на протя-
жении жизненного цикла проекта путем применения современных
методов и техники управления для достижения определенных в про-
екте результатов по составу и объему работ, стоимости, времени, ка-
честву и удовлетворению участников проекта».

Управление проектом основано на двух принципах. Во-первых,
умение, знание принципов и методов управления проектом (плани-
рование, организация, составление графиков, контроль, управление
и отслеживание). Во-вторых, навыки, опыт в области управления
(применение умения для достижения целей в конкретных условиях).

Разработка методов и приемов управления была начата еще в на-
чале прошлого века, но как дисциплина управление проектами на-
чало складываться в 1950-х гг., что было вызвано необходимостью
координации работ в крупных проектах по разработке вооружений
и освоению космоса. Стали разрабатываться методы управления
крупными проектами, среди которых наиболее известными явля-
ются: метод критического пути (Critical Path Method — СРМ); метод
анализа и оценки программ (Program Evaluation and Review Tech-
nique — PERT). В 1960—80 гг. широкое распространение получили
методы управления проектами и создания компьютерных программ
на базе СРМ, PERT, а также разработка новых методов и программ
управления проектами. С 1990-х гг., главным образом благодаря уси-
лиям PMI, управление проектами становится профессией и областью
знаний. В настоящее время в США почти не осталось компаний,
которые не применяют формальные методы управления проектами.
В России формальные методы в проектах использует незначительное
число достаточно крупных предприятий, большинство из которых
работает на рынке информационных технологий.

Категории управления проектом. В области управления проектами
существуют категории, отражающие основные понятия этой области.
В общем случае выделяют следующие группы категорий'.

•	цели, определяемые ожидаемыми результатами проекта;

•	критерии успеха и ограничения', стоимость, сроки, качество;

•	основные рычаги управления', ресурсы (являющиеся также ограни-
чением) и технологии;

•	вспомогательные рычаги управления', контракты, организация,
взаимодействие, персонал;

•	неопределенность, связанная с рисками выполнения проекта;

•	треугольник ограничений проекта.

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

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

Наиболее важной причиной провала реализации проекта является
неправильное управление, которое может быть обусловлено мало-
Рис. 3.1. «Железный треугольник» с фиксированной функциональностью
вразумительными целями, плохим планированием, необходимостью
использования новых малознакомых технологий, отсутствием мето-
дологии управления проектом, недостаточной численностью персо-
нала. Первые три фактора связаны непосредственно с управлением
проектом, последние два определяют риски проекта, которыми не-
обходимо управлять в ходе управления проектом.

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

3 2. Управление проектами и СММ

Как только мы согласились с тем, что использование эффектив-
ных процессов может помочь успешно выполнить проект, возникает
вопрос: каковы желательные характеристики этих процессов? Отве-
том может служить CM М (Capability Maturity Model) для ПО — сис-
тема понятий, разработанная в Институте программной инженерии
(Software Engineering Institute, SE1) при Университете Карнеги—Мел-
лона (Carnegie Mellon University) на основе объединения лучших тех-
ник, используемых как в программных компаниях, так и в других
организациях. СММ отражает коллективный опыт создания процес-
сов. Эта модель определяет желательные характеристики процессов,
не предписывая никаких конкретных процессов, поэтому требова-
ниям СММ могут удовлетворять разные процессы. СММ может ис-
пользоваться для оценки процесса разработки ПО в организации
и для определения его недостатков

СММ — одна из наиболее популярных систем понятий, предна-
значенных для усовершенствования процесса разработки ПО (другой
широко распространенной рабочей средой является ISO 9001).
Основы СММ заложены в книге Уоттса Хемфри Managing the Software
Process, а сама система понятий полностью описана в труде SET The
Capability Maturity Model. Guidelines for Improving the Software Process.

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

Диапазон результатов, которые можно ожидать от проекта, когда
он выполняется с использованием процесса, есть устойчивость его
процесса (process capability). Фактический результат, достигнутый
в проекте, выполнявшемся с использованием процесса, — это про-
изводительность его процесса (process performance). Очевидно, что
производительность процесса зависит от его устойчивости. Чтобы
последовательно улучшать производительность процесса, необхо-
димо повышать устойчивость процесса, а сам процесс должен стано-
виться более зрелым.

Путь к более высокой зрелости процесса включает несколько
точно определенных стадий (или плато), которые в СММ называ-
ются уровнями зрелости (maturity levels). Каждый уровень зрелости
определяет конкретные характеристики процесса, и более высокие
уровни зрелости обладают более развитыми характеристиками, свой-
ственными более зрелым процессам разработки ПО Таким образом,
в системе понятий СММ описываются ключевые элементы процес-
сов разработки ПО на разных уровнях зрелости. Следовательно,
определяется путь, которым должен следовать процесс разработки
ПО, перемещаясь от незрелых процессов к более зрелым. Как пока-
зано на рис. 3.2, этот путь включает пять уровней зрелости.

На начальном уровне (уровень 1) проект выполняется так, как счи-
тают нужным команда разработчиков и менеджер проекта Повто-
Рис. 3.2, Уровни зрелости СММ
ряемый уровень (уровень 2) означает, что используется установленный
порядок управления проектом, хотя процессы на уровне всей орга-
низации могут отсутствовать. На определяющем уровне (уровень 3)
выявлены и регулярно выполняются процессы, действующие для
всей организации. На управляющем уровне (уровень 4) количе-
ственное понимание устойчивости процесса делает возможным ко-
личественное предсказание и контроль производительности про-
цесса для проекта. На оптимизирующем уровне (уровень 5) улучшение
устойчивости процесса контролируется и оценивается количе-
ственно.

Каждый уровень зрелости (кроме уровня 1) характеризуется клю-
чевыми областями процесса (key process areas, КРА). Ключевые об-
ласти процесса — это области, на которые организация должна об-
ращать особое внимание, чтобы поднять свои процессы до данного
уровня зрелости. На рисунке приведены КРА для разных уровней.
Чтобы организация достигла определенного уровня зрелости, она
должна удовлетворять всем КРА этого уровня и всем КРА всех более
низких уровней.

Поддержание процессов на более высоком уровне зрелости —
трудная задача, требующая от организации принятия и выполнения
определенных обязательств и должной культуры работы. Из 900 ор-
ганизаций, обследованных с 1996 г. по июнь 2015 г., результаты оце-
нивания которых были представлены в SEI, лишь 3% достигли
уровня 5, и еще 5% находились на уровне 4. Остальные организации
находились на третьем и более низких уровнях, из них 38% —
на уровне 2 и 18% — на уровне 3.

Ключевые области процесса (КРА) для управления проектами.

Каждая КРА задает цели, которым процессы организации должны
соответствовать, чтобы удовлетворять этой области процесса. Кроме
того, каждая КРА задает группу действий, называемую ключевыми
практиками (key practices), которые вместе удовлетворяют целям
этой КРА. Во многих отношениях цели КРА фиксируют ее сущность:
цели, установленные СММ для процессов этой ключевой области.
Для иллюстрации КРА, связанных с управлением проектами, мы
вкратце обсудим их цели. Эти цели взяты из СММ с незначитель-
ными изменениями в формулировках

В табл. 3.1 перечислены все цели для КРА уровня 2. На этом
уровне почти все внимание уделяется управлению проектом. Исходя
из этих целей, создается и документируется план проекта, оценива-
ются, согласно плану, характеристики выполняемого проекта и, если
фактические характеристики значительно расходятся с планом, при-
Цели КРА уровня 2 (повторяемый уровень)

КРА	Цели
Управление требованиями	Для определения базовой линии разработки П О и управления разработкой требования к ПО контроли- руются.  В соответствии с требованиями поддерживаются планы разработки ПО, продукты и действия
Планирование программного проекта	Для использования в процессах планирования и отсле- живания проекта оценки документируются. Планируются и документируются действия и обяза- тельства по проекту.  Участвующие группы и отдельные лица принимают на себя обязательства, связанные с проектом
Отслеживание и надзор за программным проектом	Фактические результаты и характеристики сравнива- ются с планами разработки ПО.  Если фактические результаты существенно отклоня- ются от планов разработки, вносятся поправки, и управление этим процессом не прекращается до его закрытия.  Изменения в обязательствах согласовываются с заинте- ресованными группами и отдельными лицами
Управление субподрядами на разработку ПО	Главный подрядчик и субподрядчик договариваются о взаимных обязательствах.  Главный подрядчик отслеживает фактические резуль- таты деятельности субподрядчика в соответствии с его обязательствами.  Главный подрядчик и субподрядчик поддерживают по- стоянное взаимодействие.  Главный подрядчик отслеживает фактическую продук- тивность субподрядчика в соответствии с его обязатель- ствами
Обеспечение качества ПО	Планируются действия, обеспечивающие качество ПО. Проверяется строгое соответствие программных про- дуктов и действий применяемым стандартам, процеду- рам и требованиям.  Заинтересованные группы и отдельные лица информи- руются о действиях и результатах, обеспечивающих качество ПО  Вопросы несоответствия, которые не могут быть разре- шены внутри проекта, направляются старшим менед- жерам
КРА	Цели
Управление кон- фигурацией ПО	Планируется деятельность по управлению конфигура- цией ПО.  Определяются, контролируются и делаются доступ- ными избранные программные рабочие продукты. Контролируются изменения в определенных прог- раммных рабочих продуктах.  Заинтересованные группы и отдельные лица информи- руются о состоянии и содержании базовых линий ПО

Таблица 3.2

Цели трех КРА уровня 3 (определенный уровень)

КРА	Цели
Интегральное управление раз- работкой ПО	Определенный для проекта процесс разработки ПО является специализированной версией стандартного процесса разработки ПО в организации.  Проект планируется и управляется в соответствии с определенным для него процессом разработки ПО
Межгрупповая координация	Требования заказчика согласовываются всеми заинте- ресованными группами.  Все группы согласовывают взаимные обязательства. Группы определяют, отслеживают и разрешают межгрупповыс вопросы
Экспертизы спе- циалистов	Планируется проведение экспертиз.  Определяются и устраняются ошибки в программных рабочих продуктах

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

В табл 3.2 приведены цели трех из семи КРА уровня 3. Другие
КРА нацелены на организационные вопросы и управление процес-
сом. В проекте, выполняемом на уровне 3, применяется специали-
зированная версия стандартного процесса, повторно используются
имущество, данные и опыт планирования из прошлых проектов.
Самые разные группы, которые вносят свой вклад в проект, без по-
мех взаимодействуют посредством определенных интерфейсов и ме-
ханизмов. Для определения ошибок в рабочих продуктах выполня-
ются экспертизы, проведение экспертиз и доработок обеспечивается
достаточной поддержкой.

В табл. 3.3 показаны цели для двух КРА на уровне 4. На этом
уровне устойчивость процесса организации понимается в количе-
ственном выражении. Устойчивость процесса используется для уста-
новки количественных целей проекта. Данные по производитель-
ности процесса постоянно собираются и сравниваются со статисти-
ческими данными по производительности в завершенных проектах.
При значительных отклонениях применяются корректирующие
действия, которые позволяют восстановить контроль над проектом.
Ключевой аспект уровня 4 — это постоянное применение приемов
статистического контроля процесса, поэтому можно оценить каждое
действие и при необходимости откорректировать его.

Таблица 3.3

Цели КРА уровня 4 (управляющий уровень)

КРА	Цели
Количественное управление про- цессом	Планируются действия по количественному управ- лению процессом.  Производительность процесса, определенного для про- екта, контролируется в количественном отношении. Устойчивость стандартного процесса в организации известна в количественном выражении
Управление качеством ПО	Планируются действия по управлению качеством ПО в проекте.  Определяются измеряемые цели качества программ- ного продукта и их приоритеты.  Измеряется фактическое достижение целей качества для программных продуктов и предпринимаются регу- лирующие действия

Три ключевые области процесса на уровне 5 нацелены на улучше-
ние устойчивости процесса. Из них именно предупреждение ошибок
в наибольшей степени затрагивает управление проектом. Эта клю-
чевая область требует от организации предупреждения возникнове-
ния ошибок путем систематического анализа причин ошибок и их
последующего устранения. Возможность предупредить появление
ошибок в ПО позволяет сократить усилия, затрачиваемые на их
устранение, и, следовательно, повысить качество и продуктивность.
3.3.	Процессы программного проекта

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

Менеджеры проектов используют процессы управления проек-
том, но только в том случае, если эти процессы построены рацио-
нально и помогают им лучше выполнять проект. Однако их возму-
щают излишне бюрократизированные процессы, не слишком полез-
ные в работе. Поэтому необходимо создавать облегченные процессы,
которые помогают лучше и легче планировать и контролировать
проект и могут быть гибко использованы в различных ситуациях.

Менеджеры проектов должны стремиться придерживаться про-
иессного подхода, поскольку процессы представляют коллективное
знание. Их использование повышает шансы на успех. Процесс может
включать несколько дополнительных шагов, но никогда нельзя знать
заранее, каким путем будет развиваться ситуация, поэтому исполь-
зование коротких путей повышает риски при выполнении проекта.
Не прибегая к процессам, нельзя предсказать результаты проекта'.
Кроме того, работники организации не смогут успешно обучаться,
если не будут пользоваться предопределенными процессами. Про-
цессы снижают уровень опасений. Контрольные перечни неизбежно
охватывают 80% того, что необходимо сделать. Вам остается прора-
ботать только оставшиеся 20%.

Процессы управления проектом. Каждый проект разработки ПО
имеет свой собственный жизненный цикл, который состоит из че-
тырех основных фаз (рис. 3.3). На фазе инициации проекта необхо-
димо понять, что и зачем необходимо делать, т.е. разработать кон-
цепцию проекта. Фаза планирования определяет, как это надо делать.

Протоколы
и акт ПСИ

Требования
к системе

Рабочее
расписание

План
управления

Отчет
о состоянии

Итоговый
отчет

Архив проекта

Документы
проекта

Исходные коды

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

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

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

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

Сочетание итеративности и инкрементальности обеспечивает
эффективность разработки и существенное снижение рисков в раз-
работке проекта.

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

Рассмотрим эти фазы подробнее.

3.4.	Инициация проекта

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

Группа процессов инициации (рис. 3.5) состоит из процесса разра-
ботки устава проекта и процесса определения заинтересованных лиц.

( Группа инициирования^

Разработка
Устава проекта

(-----------------------'

Определение
заинтересованных лиц

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

Устав проекта. Это документ, выпущенный инициатором (спон-
сором) проекта, который формально узаконивает существование
проекта и предоставляет менеджеру проекта полномочия использо-
вать организационные ресурсы в операциях проекта. В отече-
ственной практике данный документ чаще называется Концепция
проекта. Концепция (от лат. conceptio — понимание, система) есть
система взглядов на «понимание» или трактовку какого-либо пред-
мета, явления или процесса, основная точка зрения или руководя-
щая идея для их систематического освещения.

В компании, которая принимает решение о старте того или иного
проекта разработки ПО. должна существовать единая система кри-
териев для оценки его значимости. Система критериев должна по-
зволять из множества возможных для реализации проектов выбрать
наиболее приоритетные для компании.

Приоритет любого проекта должен определяться на основе
оценки трех его характеристик: финансовой ценности, стратегиче-
ской ценности и уровня рисков.

Шкала оценки финансовой ценности проекта может выглядеть сле-
дующим образом.

Высокая — ожидаемая окупаемость до 1 года. Ожидаемые доходы
от проекта не менее чем в 1,5 раза превышают расходы. Все допуще-
ния при проведении этих оценок четко обоснованы.

Выше среднего — ожидаемая окупаемость проекта от 1 года
до 3 лет. Ожидаемые доходы от проекта не менее чем в 1,3 раза пре-
вышают расходы. Большинство допущений при проведении этих
оценок имеют под собой определенные основания.

Средняя — проект позволяет улучшить эффективность производ-
ства в компании и потенциально может снизить расходы компании
не менее чем на 30%. Проект может иметь информационную цен-
ность или помочь лучше контролировать бизнес.

Низкая — проект немного снижает расходы компании, не менее
чем на 10%, и способствует некоторому повышению производитель-
ности производства.

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

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

Шкала оценки стратегической ценности проекта может иметь сле-
дующие градации.

Высокая — обеспечивает стратегическое преимущество, дает
устойчивое увеличение цынка или позволяет выйти на новый рынок,
решает значительные проблемы, общие для большинства важных
клиентов, повторение конкурентами затруднено или потребует от 1
до 2 лет.

Выше среднего — создает временные конкурентные преимущества,
способствует выполнению обязательств перед многими важными
клиентами, конкурентное преимущество может быть удержано в те-
чение 1 года.

Средняя — поддерживает доверие рынка к компании, повышает
мнение клиентов о качестве предоставляемых услуг или способствует
выполнению обязательств перед несколькими клиентами, конку-
ренты уже имеют или способны повторить новые возможности
в пределах года

Низкая — стратегическое воздействие отсутствует или незначи-
тельно, влияние на клиентов несущественно, конкуренты могут
легко повторить результаты проекта.

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

Шкала оценки уровня рисков проекта может быть представлена
следующим образом.

Низкий — цели проекта и требования хорошо поняты и докумен-
тированы. Масштаб и рамки проекта заданы четко. Ресурсы требу-
емой квалификации доступны в полном объеме. Разрабатываемые
системы не потребуют новой технологической платформы.

Средний — цели проекта определены относительно четко. Хоро-
шее понимание требований к системе. Масштаб и рамки проекта
заданы достаточно хорошо. Ресурсы требуемой квалификации
в основном доступны. Системы создаются на новой, но стабильной
технологической платформе.

Выше среднего — цели проекта сформулированы недостаточно
четки Задачи системы или бизнес-приложения определены недо-
статочно полно. Масштаб и рамки проекта не совсем понятны. Ре-
сурсы требуемой квалификации сильно ограничены. Системы созда-
ются на новой технологической платформе, есть сомнения в рыноч-
ной стабильности платформы.

Высокий — цели проекта нечетки. Основные функциональные
компоненты системы не определены. Масштаб и рамки проекта не-
понятны. Ресурсы требуемой квалификации практически отсут-
ствуют. Системы создаются на новой технологической платформе,
в отношении которой крайне мало ясности. Технологии имеют не-
подтвержденную стабильность.

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

У каждого проекта должна быть концепция проекта. Если проект
небольшой, то для изложения концепции часто достаточно не-
сколько абзацев. Однако давать старт проекту без концепции — это
все равно, что отправлять корабль в плавание, не определив для него
пункт назначения.

Концепция проекта разрабатывается на основе анализа потреб-
ностей бизнеса. Главной функцией документа является подтверж-
дение и согласование единого видения целей, задач и результатов
всеми участниками проекта. Концепция определяет, что и зачем де-
лается в проекте. Она служит ключевым документом, который ис-
пользуется для принятия решений в ходе всего проекта, а также
на фазе приемки для подтверждения результата.

Концепция проекта содержит, как правило, следующие разделы.

1.	Название проекта.

2.	П,ели проекта.

3.	Результаты проекта.

4.	Допущения и ограничения.

5.	Ключевые участники и заинтересованные стороны.

6.	Ресурсы проекта.

7.	Сроки.

8.	Риски.

9.	Критерии приемки.

10.	Обоснование полезности проекта.
Цели проекта должны отвечать на вопрос, зачем данный проект
нужен и какие задачи будут решены в результате исполнения про-
екта, а также должны содержать описание бизнес-потребностей.

В качестве целей проекта могут выступать следующие устрем-
ления.

Изменения в компании — например, автоматизация ряда бизнес-
процессов для повышения эффективности основной производ-
ственной деятельности.

Реализация стратегических планов — например, завоевание значи-
тельной доли растущего рынка за счет вывода на него нового продукта.

Выполнение контрактов — например, разработка ПО по заказу.

Разрешение специфических проблем — например, доработка прог-
раммного продукта в целях приведения его в соответствие с измене-
ниями в законодательстве.

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

Результаты проекта отвечают на вопрос, что должно быть полу-
чено после его завершения, например какие именно бизнес-выгоды
получит заказчик и какие конкурентные продукты или услуги будут
представлены заказчику (что конкретно будет произведено по окон-
чании проекта).

Также должны быть сформулированы высокоуровневые требова-
ния, содержащие краткое описание, и при необходимости, ключевые
свойства и/или характеристики продукта (услуги).

Следует помнить, что результаты проекта должны быть измери-
мыми. Это означает, что по итогам их оценки можно будет сделать
заключение: достигнуты оговоренные в концепции результаты или
нет.

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

Уместно сформулировать также те требования к системе, которые
могут ожидаться заказчиком по умолчанию, но не включаются
в рамки данного проекта. Например, в данный раздел может быть
включен пункт о том, что разработка программного интерфейса
(API) для будущей интеграции с другими системами заказчика
не входит в задачи данного проекта.

Участники проекта. Одна из задач фазы инициации проекта — это
выявить и описать всех его участников. К ним относятся все заинте-
ресованные стороны (stakeholders), лица и организации (например,
заказчики, спонсоры, исполняющая организация), которые активно
участвуют в проекте или чьи интересы могут быть затронуты при
исполнении или завершении проекта. Участники также могут влиять
на ход проекта и его результаты.

К ключевым участникам программного проекта относятся:

•	спонсор проекта — лицо или группа лиц, предоставляющие фи-
нансовые ресурсы для проекта в любом виде;

•	заказчик проекта — лицо или организация, которые будут исполь-
зовать продукт, услугу или результат проекта (следует учитывать,
что заказчик и спонсор проекта не всегда совпадают);

•	пользователи результатов проекта',

•	куратор проекта — представитель исполнителя, уполномоченный
принимать решения о выделении ресурсов и изменениях в про-
екте;

•	руководитель проекта — представитель исполнителя, ответ-
ственный за реализацию проекта в срок, в пределах бюджета
и с заданным качеством;

•	соисполнители проекта — субподрядчики и поставщики.

Для того чтобы понять, сколько будет стоить реализация прог-
раммного проекта, требуется определить и оценить ресурсы проекта,
необходимые для его выполнения: людские ресурсы и требования
к квалификации персонала; оборудование, расходные материалы,
лицензии на ПО, критические компьютерные ресурсы; бюджет про-
екта — план расходов и, при необходимости, предполагаемых дохо-
дов проекта с разбивкой по статьям и фазам/этапам проекта.
Специфика программного проекта заключается в том, что люд-
ские ресурсы вносят основной вклад в его стоимость. Все остальные
затраты, как правило, незначительны по сравнению с этим расхо-
дами. На фазе инициации хорошей считается оценка трудозатрат
с точностью от -50% до +100%.

Необходимо помнить, что помимо непосредственно программи-
рования в проекте разработки ПО есть много других процессов, для
реализации которых требуются ресурсы соответствующей квалифи-
кации, а само программирование составляет лишь четверть всех за-
трат. Распределение трудозатрат по основным производственным
процессам при современном процессе разработки ПО выглядит
в среднем в соответствии с рис. 3.7

Рис. 3.7. Распределение трудозатрат по основным производственным
процессам при разработке ПО

Поэтому если по предварительной оценке для реализации требу-
емой функциональности в проекте необходимо написать 10 тыс.
строк исходного программного кода, а программисты пишут в сред-
нем по 100 строк исходного программного кода в день, то общие
трудозатраты на проект будут не 100 чел.-дней, а не менее чем
400 чел.-дней. Остальные ресурсы потребуются на анализ и уточне-
ние требований, проектирование, документирование, тестирование
и другие проектные работы.

Ф Брукс писал: «Чтобы родить ребенка, требуется девять месяцев
независимо от того, сколько женщин привлечено к решению данной
задачи. Многие задачи программирования относятся к этому тину,
поскольку отладка по своей сути носит последовательный характер».
Брукс также приводит исключительно полезную, эмпирическую фор-
мулу оценки срока проекта по его трудоемкости, которая была выве-
дена Б. Боэмом (Barry Boehm) на основе анализа результатов 63 про-
ектов разработки ПО, в основном в аэрокосмической области. Со-
гласно этой формуле для проекта, общая трудоемкость которого
составляет Nчел.-мес., можно утверждать, что существует оптималь-
ное с точки зрения затрат время выполнения графика для первой
поставки:

T=2,5W1/3,

т.е. оптимальное время в месяцах пропорционально кубическому
корню предполагаемого объема работ в чел.-мес. Кривая, представ-
ляющая оптимальную численность проектной команды, представ-
лена на рис. 3.8. Кривая стоимости медленно растет, если заплани-
рованный график длиннее оптимального. Работа занимает все отве-
денное для нее время. Кривая стоимости резко возрастает, если
запланированный график короче оптимального. Практически
ни один проект невозможно завершить быстрее, чем з< /4 расчетного
времени оптимального графика, вне зависимости от количества за-
нятых в нем работников (рис. 3.9). Этот примечательный результат
дает менеджеру программного проекта солидное подкрепление,
когда высшее руководство требует принятия невозможного графика.

Для серьезного программного проекта недостаточно установить
срок его завершения, необходимо определить некоторые его этапы —

Зависимость длительности проекта
и численности команды от суммарной трудоемкост и

20 д	г25

>>>>>

Трудоемкость, чел.-мес.

---Опт. длит. --Мин. длит. — Опт. числ.

Рис. 3.8. Закон Б Боэма
контрольные точки, в которых будет происходить переоценка про-
екта на основе реально достигнутых показателей. Контрольная
точка — важный момент (событие) в расписании проекта, отмеча-
ющий достижение заданного результата и/или начало (завершение)
определенного объема работы. Каждая контрольная точка характе-
ризуется датой и объективными критериями ее достижения.

Современный проект разработки ПО должен реализовываться
с применением инкрементального процесса, тогда контрольные
точки должны соответствовать выпуску каждой промежуточной вер-
сии продукта, в которой будет реализована и протестирована опре-
деленная часть конечной функциональности ПП. В зависимости
от сложности и масштаба проекта продолжительность одной итера-
ции может составлять от 2 до 8 недель.

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

Риск — эго неопределенное событие или условие, наступление
которого отрицательно/положительно сказывается на целях проекта.
В случае возникновения негативного риска почти всегда стоимость
проекта увеличивается и происходит задержка в выполнении меро-
приятий, предусмотренных расписанием проекта.
Критерии приемки должны определять числовые значения харак-
теристик системы, которые должны быть получены в результате при-
емо-сдаточных испытаний или опытной эксплуатации и однозначно
свидетельствовать о достижении целей проекта.

3.5. Планирование проекта

Планирование представляет собой процесс распределения и на-
значения ресурсов (материальных и людских) с учетом стоимости
и времени выполнения проекта. Планирование относится к наиболее
важным процессам для проекта, так как результатом его реализации
обычно является уникальный объект, товар или услуга.

Основные функции планирования приведены далее.

Преобразование потребностей в управляемые задачи. Изначально
проект выступает в виде требований, разработанных и согласован-
ных с заказчиком. Цель планирования — представить эти требования
в виде совокупности отдельных задач, выполнение которых можно
контролировать.

Определение необходимых ресурсов. Детальные планы позволят
определить количество людей, необходимого оборудования и рабо-
чие условия, которые понадобятся для выполнения проекта.

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

Оценка потенциальных рисков. Хотя некоторые риски могут быть
выявлены во время формулировки требований, гораздо больше их
обнаруживается после осуществления детального планирования.
Знание о существовании этих рисков позволит раньше их заметить
(если они осуществились) и приготовиться к их адресации.

Сигнализация о возникновении проблем. Отклонение от плана слу-
жит сигналом о возникновении проблем. Планы не являются до-
гмой, которой необходимо безоговорочно следовать. Для менеджера
проекта они скорее являются предположениями и основой для срав-
нения. Если выполнение проекта не оправдывает ожиданий, то не-
обходимо провести соответствующую корректировку плана.

Группа процессов планирования представлена на рис. 3.10. Эти про-
цессы могут повторяться и входить в состав итерационной про-
цедуры, выполняемой до достижения определенного результата.
Например, если первоначальная дата завершения проекта неприем-
лема, то требуемые ресурсы, стоимость, а иногда и содержание про-
Группа процессов
планирования

Группы процессов
правления проектом

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

Планирование
управления
риском

Определение
рисков

Проведение
качественнного
анализа рисков

Проведение
количественного
анализа рисков

Планирование
ответов на риски

Рис. 3.10. Процессы планирования

екта должны быть изменены. Результатом в этом случае будут согла-
сованные сроки, объемы, номенклатура ресурсов, бюджет и содер-
жание проекта, соответствующие его целям.

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

Планирование в том или ином виде выполняется в течение всего
срока реализации проекта. В начале ЖЦ проекта обычно разрабаты-
вается неофициальный первоначальный план — грубое представле-
ние о том, что потребуется выполнить в случае реализации проекта.
Решение о выборе проекта в значительной мере базируется на оцен-
ках этого первоначального плана. Формальное и детальное плани-
рование проекта начинается после принятия решения о его реали-
зации

Планирование заключается в составлении следующих планов'.

•	выполнения работ, включая оценку их трудоемкости и сроков вы-
полнения;

•	управления содержанием и составом работ;

•	организационной структуры;

•	управления конфигурациями;

•	управления качеством;

•	управления рисками;

•	управления закупками;

•	аттестации результатов проектирования и деятельности исполни-
телей.

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

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

Сетевые планы укрупняют из-за того, что общий сетевой план
состоит из множества частных сетевых планов. В каждом из таких
частных планов определяют самый длинный путь. Эти пути затем
ставят на место отдельных частей сети. При помощи такого посте-
пенного агрегирования получают многоуровневые сетевые планы
(рис. 3.11). Обычно выделяют концептуальный план, стратегический
план реализации проекта, тактические (детальные, оперативные)
планы.
Уровень 1

Уровень 2

Уровень 3

Детальный
сетевой план

Сетевой план
с ключевыми
этапами (вехами)

Сетевой план
с несколькими проектами
(для высшего руководства)

Рис. 3.11. Многоуровневые сетевые планы

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

Стратегическое планирование представляет собой процесс разра-
ботки стратегических, укрупненных, долгосрочных планов.

Детальное (оперативное, тактическое) планирование связано с раз-
работкой тактических, детальных планов (графиков) на основе ие-
рархической структуры работ (ИСР) для оперативного управления
на уровне ответственных исполнителей.

Планирование управления содержанием. Одна из распространен-
ных «болезней» программных проектов называется «ползучий фиче-
ризм», когда к изначально спроектированной будке для любимой
собаки сначала пристраивают сарайчик для хранения садового ин-
вентаря, а потом и домик в несколько этажей для ее хозяина. И все
это пытаются построить на одном и том же фундаменте и из тех же
самых материалов. Такой подход стал причиной летального исхода
многих проектов разработки ПО Поэтому сразу, как только удалось
стабилизировать и согласовать ИСР — иерархическую структуру ра-
бот, необходимо разработать план управления содержанием проекта,
для чего следует:

•	определить источники запросов на изменение;

•	установить порядок анализа, оценки и утверждения/отклонения
изменения содержания;

•	определить порядок документирования изменений содержания;

•	определить порядок информирования об изменении содержания.

Первая задача, которую необходимо решить при анализе запроса
на изменения, — выявить объекты изменений: требования, архитек-
туру, структуры данных, исходные коды, сценарии тестирования,
пользовательскую документацию и пр. Затем требуется спроектиро-
вать и детально описать изменения во всех выявленных объектах.
И наконец, следует оценить затраты на внесение этих изменений,
тестирование изменений и их влияние на сроки проекта. Эта работа
потребует затрат рабочего времени, и порой значительных, разных
специалистов: аналитиков, проектировщиков, разработчиков, тести-
ровщиков, а также менеджера проекта, и поэтому она обязательно
должна быть учтена в плане

Планирование организационной структуры. Организационная струк-
тура — это согласованное и утвержденное распределение ролей,
обязанностей и целей деятельности ключевых участников проекта.
Она в обязательном порядке должна включать в себя следующее:

•	систему рабочих взаимоотношений между рабочими группами
проекта;

•	систему отчетности;

•	оценки хода выполнения проекта;

•	систему принятия решений.

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

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

•	работы по обеспечению единого хранилища всей проектной до-
кументации и разрабатываемого программного кода, обеспече-
нию сохранности и восстановления проектной информации
после сбоя;

•	работы по настройке рабочих станций и серверов, используемых
участниками проектной команды;

•	работы, необходимые для организации сборки промежуточных
выпусков системы, а также ее конечного варианта

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

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

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

При планировании этой работы необходимо понимать, что про-
дукт проекта не должен обладать наивысшим возможным качеством,
которое недостижимо за конечное время. Необходимое качество
продукта определяется требованиями к нему. Основная задача обес-
печения качества — это не поиск ошибок в готовом продукте (вы-
ходной контроль), а их предупреждение в процессе производства.
План управления качеством должен включать в себя следующие
работы:

•	объективную проверку соответствия программных продуктов
и технологических операций применяемым стандартам, проце-
дурам и требованиям;

•	определение отклонений по качеству, выявление их причин, при-
менение мер по их устранению, а также контроль исполнения
принятых мер и их эффективности;

•	предоставление высшему руководству независимой информации
о несоответствиях, не устраняемых на уровне проекта.

Уточнение содержания и состава работ. Уточнение содержания (де-
композиция) проекта — одна из важнейших составных частей дис-
циплины управления проектами. Детализация позволяет оценить,
например, общую стоимость проекта через совокупность стоимости
отдельных его работ. Результат детализации содержания проекта есть
структура декомпозиции работ (Work Breakdown Structure — WBS).
В большинстве случаев такая структура является иерархической. При
этом сам процесс детализации — это структурная декомпозиция ра-
бот, т.е. деятельность по созданию детализированной структуры ра-
бот или задач проекта.

Иерархическая структура работ (ИСР) — это ориентированная
на результат декомпозиция работ, выполняемых командой проекта для
достижения целей проекта и необходимых результатов. С ее помощью
структурируется и определяется все содержание проекта. Каждый сле-
дующий уровень иерархии отражает более детальное определение эле-
ментов проекта. Основой для разработки ИСР служит концепция
проекта, определяющая продукты проекта и их основные характерис-
тики ИСР обеспечивает выявление всех работ, необходимых для до-
стижения целей проекта. Многие проекты проваливаются не оттого,
что у них нет плана, а оттого, что в этом плане забыты такие важные
работы, как тестирование и исправление ошибок, а также продукты
проекта, например пользовательская документация. Поэтому если
ИСР составлена корректно, то любая работа, которая в нее не вошла,
не может считаться работой по проекту. ИСР делит проект на субпро-
екты, пакеты работ, субпакеты. Каждый следующий уровень деком-
позиции обеспечивает последовательную детализацию содержания
проекта, что позволяет производить оценку сроков и объемов работ.
ИСР должна включать все промежуточные и конечные продукты.

Выполнять декомпозицию работ проекта можно по-разному. На-
пример, ГОСТ 19.102-77 предусматривает каскадный подход и опре-
деляет следующие стадии разработки программной системы'.
1)	техническое задание;

2)	эскизный проект;

3)	технический проект;

4)	рабочий проект;

5)	внедрение.

Если следовать этому стандарту, то на первом уровне ИСР
должны находиться именно эти проектные продукты. Если бы при-
шлось разрабатывать АСУ для управления ядерным реактором или
пилотируемым космическим аппаратом, то именно так и следовало
поступать. Однако в коммерческой разработке ПО такой подход не-
эффективен.

Современный процесс разработки коммерческого ПО должен
быть инкрементальным. Это означает, что на верхнем уровне деком-
позиции проекта должны находиться продукты проекта, а на следу-
ющем уровне — компоненты, из которых эти продукты состоят. Ком-
поненты далее могут быть декомпозированы на «фичи» — функции,
которые они должны реализовывать.

Выделение компонентов, составляющих программный продукт, —
это элемент высокоуровневого проектирования, которое должно вы-
полняться на фазе планирования проекта, не дожидаясь проработки
всех функциональных требований к разрабатываемому ПО. Компо-
нентами могут быть как прикладные подсистемы, так и инфраструк-
турные или ядерные, например подсистема аутентификации, безопас-
ности, библиотека визуальных компонентов графического интерфейса
(GUI). При составлении базового плана работ не стоит стремиться
максимально детализировать все работы ИСР, достаточно 3—5 уровней.

В контексте детализации часто используются термины «задачи»
и «работы» как взаимозаменяемые. Все же корректнее говорить, что
задача определяет достижение промежуточного результата, а работы
являются комплексами действий для достижения этих результатов.
Так как любая задача требует проведения определенных работ при
заданных ограничениях, безусловно, можно говорить о несомненном
«отображении» (mapping) задач на работы и наоборот. Это и есть
причина взаимозаменяемости терминов в повседневной жизни.
В то же время понимание отличий между этими понятиями позво-
ляет почувствовать нюансы процессного взгляда на создание про-
дукта, а следовательно, и на жизненный цикл проектов, в том числе
и проектов программных систем.

В общем случае можно говорить о детализации: «программа — про-
ект — задача — операция». На рис. 3.12 представлен пример такой
детализации (показаны только операции Задачи Л1).
Рис, 3.12. Пример применения терминов:
программа, проект, задача, операция

С каждым элементом такой структуры связаны ограничения
и другие значимые характеристики и данные. Под значимостью под-
разумевается их необходимость или полезность для принятия реше-
ний. Глубина же детализации и уровень применения тех или иных
терминов зависят от конкретного проекта, культуры управления,
стандартов ЖЦ, специфики и масштабов проекта, а также других
факторов, уникальных как для конкретной организации, так и для
конкретного проекта.

За все части проекта (субпроекты и пакеты работ) должна быть
установлена персональная ответственность. Для каждого пакета ра-
бот должен быть четко определен результат на выходе. Работы
и оценки проекта должны быть согласованы с ключевыми участни-
ками команды, руководством компании-исполнителя и, при необ-
ходимости, с заказчиком. В результате согласования члены команды
принимают на себя обязательства по реализации проекта, а руковод-
ство берет на себя ответственность за обеспечение проекта необхо-
димыми ресурсами.

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

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

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

Алгоритмические модели определения стоимости проекта ис-
пользуются для управления программными проектами, поскольку
они поддерживают количественный анализ параметров. Эти модели
позволяют оценить вклад каждого отдельного параметра в общую
стоимость проекта и провести объективное (хотя и не застрахованное
от ошибок) сравнение этих параметров.

Оценка стоимости проекта — одна из наиболее важных работ
на проекте, которая определяется исходя из стоимости отдельных
частей проекта, условий выполнения работ, фактического штата ис-
полнителей, используемых методов и инструментов. В стоимость
проекта также входят расходы на ведение проекта, т.е. компьютеры,
ПО, площади, мебель, телефоны, модемы и многое другое. Кроме
того, иногда должны быть учтены дополнительные затраты (напри-
мер, на обеспечение безопасности). К дополнительным расходам
на проект относится и приобретение системы тестирования, CASE-
системы и др. Главной оценкой в проекте является оценка затрат
на ведение проекта, выражаемая в человеко-днях работы исполните-
лей на проекте. Эту оценку проводят на ранней стадии ведения и со-
ставления плана.

Общая стоимость проекта определяется опытными специалис-
тами с погрешностью до 10%. Опенка затрат может выполняться
«сверху вниз», «снизу вверх» или исходить из стоимости ранее изго-
товленного проекта. Эксперты проводят пессимистическую, опти-
мистическую и реальную оценку путем опроса всех членов рабочей
группы и коррекции каждой оценки для получения наиболее прав-
доподобной. В некоторых рабочих группах пессимистическая и оп-
тимистическая сценки могут сильно отличаться.

Алгоритмические методы оценки стоимости проекта отображают
связи между затратами на проект и факторами, которые на них
влияют.

Существуют различные эмпирические подходы к оценке стои-
мости проекта, например стоимость проекта предлагается опреде-
лять по формуле

СТОИМОСТЬ = (а + Ь^)т(Х),

где S — некая оценка размера системы; а,Ь,с — эмпирические кон-
станты; X — вектор факторов стоимости размерностью л; т — регу-
лирующий множитель, основанный на затратных факторах.

Более упрощенная оценка, полученная экспериментальным пу-
тем, выражается в следующем виде:

СТОИМОСТЬ = 5,2550’91.

Эти оценки были получены на основе анализа проектов, где прог-
раммы имели размер от 4000 до 467000 строк кода и были написаны
на 28 различных языках программирования для 66 компьютеров.
На разработку было затрачено ог 12 до 11 758 чсл.-мес Известны
и другие техники эмпирического моделирования

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

Базовой моделью экспериментальной оценки стоимости проекта
на сегодняшний день служит следующее уравнение:

СТОИМОСТЬ = bS'm(X),

где bSc — первичная оценка, которая корректируется с помощью
вектора стоимости т(Х) и учета числа старых и новых объектов;
с — параметр, который изменяется от нуля до единицы для первой
стадии ведения проекта и от 1,01 до 1,26 — для остальных стадий.

При формализованном подходе выполнение оценки проекта
основывается на использовании LOC- и FP-метрик.

Конструктивная модель стоимости (СОСОМО — Constructive cost
model), предложенная Б. Боэмом, объединила в себе наиболее из-
вестные формализованные техники оценки проекта — LOC-оценки
(LOC — Lines of Code), которые базируются на числе строк прог-
раммного кода. В процессе применения этой модели формируются
предварительные оценки, позволяющие предъявить заказчику кор-
ректные требования по стоимости и затратам на разработку ПП,
а также обеспечивается возможность составления плана ПП.

Функционально-ориентированные FP-метрики вместо подсчета
LOC-оценки косвенно измеряют программный продукт. Рассмат-
ривается не размер, а функциональность или полезность продукта.
Автором этой метрики является А. Албрехт. Определение функцио-
нального размера состоит из нескольких шагов и начинается
с идентификации функций, которые должно иметь приложение.
Международная группа пользователей функционального измерения
(1FPUG — International Function Point Osers Group) опубликовала
критерии, по которым определяются функции приложения. При
расчете FP-метрики используются пять информационных характе-
ристик: количество внешних вводов; количество внешних выводов
(выводы означают отчеты, экраны, распечатки, сообщения
об ошибках); количество внешних запросов; количество внут-
ренних логических файлов; количество внешних интерфейсных
файлов.

После сбора всей необходимой информации приступают к рас-
чету метрики — определяют количество функциональных указателей
FP (Function Points) по некой формуле, где значения входящих ко-
эффициентов регулировки сложности (каждый коэффициент может
принимать значения: 0 — нет влияния; 1 — случайное; 2 — неболь-
шое; 3 — среднее; 4 — важное; 5 — основное) выбираются эмпири-
чески в результате ответов на 14 вопросов, которые характеризуют
системные параметры приложения.

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

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

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

С помошью стандартных таблиц FP-оценки можно легко пере-
считать в LOC-оценки, т.е. по функциональному размеру вычислить
количество строк кода. Однако результаты пересчета зависят
от языка программирования, используемого для реализации ПО (на-
пример, на Java одна единица функционального размера равна
53 строкам исходного кода). В свою очередь, количество строк кода
позволяет определить общую трудоемкость, выраженную в чел.-мес.,
и сроки проекта.

При выполнении оценки возможны два варианта использования
LOC- и FP-данных: в качестве оценочных переменных, определя-
ющих размер каждого элемента продукта, или в качестве метрик,
собранных в ходе работ над прошлыми проектами и входящих в ме-
трический базис фирмы.

Пример 3.1. Рассмотрим порядок выполнения процедуры оценки
работ на основе LOC-метрики.

Этап 1. Область назначения проектируемого продукта разбива-
ется на ряд функций/!,/,, ^, ...,/, каждую из которых можно
оценить индивидуально

Этап 2. Для каждой функции ft планировщик формирует лучшую
ЮСЛ, худшую LOCX и вероятную LOCB оценки. В процессе форми-
рования оценок используются опытные данные из метрического
базиса или интуитивные представления планировщика. Диапазон
возможных значений оценок соответствует степени предусмот-
ренной неопределенности.

Этап 3. Для каждой функции/ определяется ожидаемое значение
оценки:
LOCo^

LOCn + LOC^ + 4L0CB
6

Этап 4. Вычисляется значение LOC-производительности разра-
ботки функции в соответствии с одним из трех правил.

Правило А. Для всех функций принимается одно и то же значение,
равное средней производительности ПРср, взятое из метрического
базиса, т.е.

ПР, = ПР1П; i = 1, 2, ..., п.

Правило Б. Для z-й функции на основе метрики средней произво-
дительности вычисляется настраиваемая величина производитель-
ности:

ПР, = ПРСР

LOCcv
LOCox

где LOC^ — средняя LOC-оценка, взятая из метрического базиса
(соответствует средней производительности).

Правило В. Для /-й функции настраиваемая величина производи-
тельности вычисляется по выбранному аналогу (взятому из метри-
ческого базиса):

ПР, = ПРаш

LOCaw

LOCo^

Использование в дальнейших этапах правила А обеспечивает ми-
нимальную точность при максимальной простоте вычислений. Пра-
вило В позволяет достичь максимальной точности при максималь-
ной сложности вычислений.

Этап 5. Вычисляется общая опенка затрат (чел.-мес.) на проект,
если используется правило А:

ЗАТР = ——У LOC;

ттр ^—1 ОЖ1 ’
11гср ,^1

если используется правило Б или В.

ЗАТР = £

S=1

ПР,



Этап 6. Вычисляется общая
если используется правило А или Б:

оценка стоимости проекта,
СТОИМОСТЬ = УДСТспУ ЛОСож,;

(=1

если используется правиле В:

СТОИМОСТЬ = УДСТан,У LOC™,,

1=1

где УДСТср — метрика средней стоимости одной строки программ-
ного кода; УДСТан; — метрика стоимости одной строки аналога (обе
метрики берутся из метрического базиса).

Разработка расписания проекта. После определения трудоемкости
работ необходимо определить график их выполнения и общие сроки
реализации проекта, т.е составить расписание работ по проекту. Ба-
зовое расписание представляет собой утвержденный план-график
с указанными временными фазами проекта, контрольными точками
и элементами иерархической структуры работ.

Базовое расписание в большинстве случаев является элементом
контракта с заказчиком. Контрольные точки (вехи) служат точками
анализа состояния проекта и принятия решения в формате «go или
not go», поэтому они должны зримо демонстрировать статус проекта.
Предъявляются определенные требования к выбору и формирова-
нию контрольных точек, например контрольная точка «Проектиро-
вание завершено» является малоинформативной, более эффектив-
ным подходом считается метод последовательных поставок' выше-
названная контрольная точка формулируется в форме «Завершено
тестирование требований 1, 3, 5, и 7».

Если работы не связаны между собой, то любую из них можно на-
чинать и завершать, когда нам удобно; все работы можно делать па-
раллельно, и в этом случае минимальная длительность проекта равна
длительности самой долгой работы Однако на практике обычно
между работами существуют зависимости, которые могут быть «жест-
кими», например «анализ — проектирование — кодирование — тес-
тирование — документирование» конкретной функции, или «нежест-
кими», которые могут пересматриваться или смягчаться, например
последовательное выполнение задач конкретным исполнителем
можно перепланировать на другого исполнителя, а вместо разработки
базового ПО, которое должно предшествовать разработке приклад-
ного ПО, можно создать «заглушки», эмулирующие его работу.

Разработка плана работ со сроками их выполнения может осуще-
ствляться по методу критического пути СРМ или методу анализа
и оценки программ PERT, План проекта при этом приводится в тер-
минах этапов: «Планирование», «Проектирование», «Кодирование»,
«Тестирование» и «Сопровождение». Планирование затрагивает
определение спецификаций, бюджета и расписания, а также разви-
тие плана проекта в целом.

В методе критического пути проекта (Critical path) используется
самая длинная цепочка работ в проекте. Увеличение длительности
любой работы в этой цепочке приводит к увеличению длительности
всего проекта. В проекте всегда существует хотя бы один критиче-
ский путь, но их может быть и несколько Критический путь может
меняться во время исполнения проекта.

При исполнении проекта руководитель в первую очередь должен
обращать внимание на исполнение задач по критическому пути
и следить за появлением других критических путей. Существует
практическая рекомендация: на критическом пути должны стоять
работы с нежесткими связями, которые всегда можно перепланиро-
вать, если возникает угроза срыва сроков. График работ составляется
по схеме, показанной на рис. 3.13.

Требования	График

к проекту

Рис. 3.13. Шаги составления графика работ на проекте

При планировании по методу анализа и оценки программ PERT
событие или дата в плане является некоторой вехой (контрольной
точкой) на пути осуществления отдельных работ проекта и исполь-
зуется для отображения/отметки состояния завершения тех или иных
работ. В контексте проекта менеджеры используют вехи для того,
чтобы обозначить важные промежуточные результаты, которые
должны быть достигнуты в процессе реализации проекта.

Последовательность точек-вех, определенных менеджером, часто
называется планом по вехам (по событиям). Определение плана до-
стижения соответствующих вех образует календарный план на ос-
нове вех.

На этапе планирования могут использоваться также сетевая раз-
бивка работ и диаграмма Ганта.
Сетевая разбивка работ (СРР) — это иерархическая структура де-
композиции задач проекта на подзадачи. На нижнем уровне распо-
лагаются работы, детализированные на элементы деятельности в се-
тевой модели СРР.

Сетевая модель позволяет осуществить разбиение работ на основ-
ные компоненты и подкомпоненты, определить направления дея-
тельности, направленные на достижение комплексных целей, рас-
пределить ответственных за выполнение отдельных работ на проекте
и выполнить оформление отчетности с обобщением информации
по результатам выполнения проекта.

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

План работ в виде графа СРР содержит фазы (этапы), шаги и дея-
тельность, включая начальную и конечную деятельность на процессе
(рис. 3.14).

Деятельность 1.1

Деятельность 1.2

Деятельность 2.1

Деятельность 2.2

Рис. 3.14. Пошаговый граф плана проекта

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

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

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

Наиболее наглядно базовое расписание может быть представлено
диаграммой Ганта — линейной диаграммой, где задачи проекта пред-
ставляются отрезками времени, включая даты начала и окончания
их выполнения с учетом возможных задержек. На этой диаграмме
плановые операции (элементы иерархической структуры работ) пе-
речислены с левой стороны, даты отображаются сверху, а длитель-
ность операций показана горизонтальными полосками от даты на-
чала данной операции до даты ее завершения (рис. 3 16).
Фев	. 2016	Март 2016				Апрель 2016				Май 2016				Июнь 2016		
7	8	9	10	И	12	13	14	15	16	17	18	19	20	21	22	23

План проекта		1 Эльвест К., Горичева Р , Иванчикова О., Плотникова О.					
Спецификация требований		41	’					
2.1. Первичный список требований		Горичева Р					
2 2. Модели требований			| Плотникова О.					
2 3. Высокоуровневая архитектура системы			1		Сорокина О., Эльвест К.			
2 4. Критерии аттестации системы			1		Иванчикова О.			
2.5. Мифологическая модель базы данных			1		Счетчикова А.			
2.6. Глоссарий			1		Горичева Р., Плотникова О.			
Документация проектирования				1 ’			
3.1. Проект архитектуры			>{_	к Эльвест К					
3 2. Проект интерфейса пользователя		Счетчикова А., Плотникова О					
3.3. Проект подсистем		Сорокина О.					
3.4. Модель базы данных			>|	| Иванчикова О.					
3.5. План тестирования			d	h		Горичева Р.		
Документ реализации			1		1 ’		
4 1. Обзор реализации			[			1	Счетчикова А., Сорок!	ша О., Ива
4.2. Руководство пользователя						Эльвест К., Горичева	>.
Документ о выполнении тестирования							
5 1. Тестирование методом белого ящика				Счетчикова А.,				Сорокина
5.2. Интеграционное тестирование	Эльвест К						, Плотник
5.3. Аттестационное тестирование	1	fyfopi						чева Р., Иг
Завершение и сдача проекта							Счетчико

Гис. 3.16. Диаграмма Ганта
Современные программные средства управления проектами обес-
печивают визуализацию структуры графа проекта и процессов вы-
полнения работ, например широко известная и достаточно часто
применяемая на практике система Project Management. Это дает воз-
можность разработчику или менеджеру проекта видеть, как выпол-
няются различные виды деятельности — последовательно или парал-
лельно, находятся ли они на критическом пути.

3.6.	Исполнение и завершение проекта

План проекта реализуется за счет выполнения процессов, пред-
ставленных в плане. Следование плану на протяжении выполнения
проекта связано с ожиданиями, что соблюдение корректно состав-
ленного плана приводит к успешному удовлетворению требований
заинтересованных лиц и достижению целей проекта. Основой для
успешного выполнения проекта является управленческая деятель-
ность по ведению оценок и измерений, мониторинга, контроля и от-
четности. На рис. 3.17 представлена группа процессов исполнения
проекта.

Рис. 3.17. Группа процессов исполнения проекта
Руководство и управление исполнением проекта — это процесс ис-
полнения работ, определенных в плане управления проектом, для
достижения целей проекта, который включает в себя:

•	осуществление действий для выполнения требований проекта;

•	создание результатов проекта;

•	подбор, подготовку и управление членами команды проекта;

•	получение, управление и использование ресурсов, включая мате-
риалы, инструменты, оборудование и сооружения;

•	применение запланированных методов и стандартов;

•	налаживание и управление каналами коммуникаций проекта, как
внешними, так и внутренними по отношению к команде проекта;

•	выработку данных проекта, таких как стоимость, расписание, тех-
ническое или качественное исполнение и статус, для облегчения
прогнозирования;

•	выпуск запросов на изменение и адаптацию одобренных измене-
ний к содержанию, планам и среде проекта;

•	управление рисками и выполнение действий по реагированию
на риски;

•	управление продавцами и поставщиками;

•	сбор и документирование накопленных знаний, а также выпол-
нение одобренных действий по усовершенствованию процессов.
Менеджер проекта вместе с командой управления проектом ру-
ководит выполнением запланированных операций и управляет раз-
нообразными техническими и организационными связями, которые
существуют в рамках проекта.

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

Руководство и управление исполнением проекта требует также
реализации одобренных изменений, включая следующие действия.

1.	Корректирующее воздействие — документированное указание
по исполнению работ по проекту с целью приведения в соответствие
ожидаемого будущего исполнения работ по проекту с планом управ-
ления проектом.
2.	Предупреждающее действие — Документированное указание
по осуществлению действия, которое может снизить вероятность
негативных последствий, связанных с рисками проекта.

3.	Исправление дефекта — формально документированное выяв-
ление дефекта в элементе проекта, содержащее рекомендации либо
об исправлении дефекта, либо о полной замене элемента.

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

Базовое расписание, составленное на этапе планирования проекта,
служит ориентиром для мониторинга состояния дел на макроуровне.
Для оперативного управления проектом используется рабочий план.
Рабочее планирование рекомендуется выполнять методом «набега-
ющей волны», когда работа, которую надо выполнить в ближайшее
время, подробно планируется на низшем уровне ИСР, а далеко от-
стоящая работа планируется на сравнительно высоком уровне ИСР.

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

Для рабочего планирования целесообразно использовать систему
управления задачами, поскольку она позволяет задавать последова-
тельность переходов при исполнении задачи от исполнителя к ис-
полнителю, управлять приоритетами работ и адекватно отслеживать
их статус: анализ, проектирование, кодирование, тестирование, до-
кументирование. Работа должна считаться законченной только
тогда, когда реализация требования протестирована и документиро-
вана.

В зависимости от уровня профессионализма и зрелости команды
проекта распределение работ может осуществляться либо дирек-
тивно с жесткой постановкой срока и контролем исполнения каждой
задачи, либо эти полномочия делегируются исполнителям. В этом
случае они сами выбирают задачи последовательно в соответствии
с приоритетами, а их выполнение анализируется периодически
на статуе-митинге. Можно рекомендовать еженедельные собрания
по статусу проекта всей команды или, если проект достаточно боль-
шой, ключевых его участников: руководителей подпроектов и лиде-
ров команд. Обсуждаются, как правило, три вопроса: угрозы и проб-
лемы; анализ результатов за неделю; уточнение приоритетов задач
на новую неделю. Как правило, нет смысла оценивать процент реа-
лизации работы в промежуточном состоянии, поскольку если задача
передана на тестирование, то это вовсе не означает, что 70% работы
сделано. На этапе тестирования может быть выявлена ошибка про-
ектирования, и вся работа начнется заново. Рекомендуется исполь-
зовать правило «50/100». Если работа по задаче начата, то следует
учитывать ее как выполненную на 50%, а 100% получает только про-
тестированная и документированная работа.

Принципы количественного управления. Есть известное изречение:
«Тем, что нельзя измерить, нельзя управлять». Измерения по проекту
необходимо выполнять регулярно, не реже одного раза в 1—2 недели,
при этом для каждого измеряемого показателя должны быть опреде-
лены его плановые значения. Для каждого планового значения должны
быть определены три области критичности отклонений', допустимые
отклонения, когда предполагается, что никаких управляющих воз-
действий не требуется; критичные отклонения — требуется тщатель-
ный анализ причин отклонения и при необходимости применение
корректирующих действий; недопустимые отклонения — необходим
срочный анализ причин отклонения и обязательное применение
корректирующих действий.

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

Все измерения необходимо сохранять в репозитарии проекта. Из-
мерения, накопленные в ходе проекта, являются наиболее достовер-
ной основой при детальной оценке и планировании работ на следу-
ющих итерациях проекта.

Поскольку главная задача менеджера заключается в том, чтобы
удержать проект в пределах «железного» треугольника, то в первую
очередь необходимо анализировать отклонения проекта по срокам
и затратам. Делается это при помощи метода освоенного объема.
Приходилось сталкиваться с мнением, что этот метод неприменим
в управлении программными проектами. Это действительно так,
если используется «водопадная» модель процесса разработки. Б слу-
чае же ориентации ИСР проекта на инкрементальную разработку,
когда на верхних уровнях декомпозиции находятся компоненты про-
ектного продукта и их функционал, а не производственные про-
цессы, то, если в проекте реализованы, протестированы и докумен-
тированы 50% функциональных требований, есть все основания
полагать, что осталась приблизительно половина проектных работ.

Суть метода оценки проекта по освоенному объему заключается
в следующем. Сначала оценивается отклонение от графика SV(Shed-
ule Variance) в денежных единицах:

5Е= EV- PV,

где EV (Earned Value) — освоенный объем (плановая стоимость вы-
полненных работ, т.е. объем выполненных работ, выраженный в тер-
минах одобренного бюджета, выделенного на эти работы для плано-
вой операции и элемента ИСР); PV (Planned Value) — плановый
объем (плановая стоимость запланированных работ, т.е. утверж-
денный бюджет, выделенный на плановые работы, выполняемые
в рамках плановой операции или элемента ИСР).

Пример 3.2. Пусть на текущий момент реализовано (протестиро-
вано и документировано) 20 функциональных требований, на каждое
из которых было запланировано затратить по 40 чел.-ч по 1000 руб.,
тогда освоенный объем будет

EV= 20 • 40 • 1000 = 800000 руб.

Если на текущий момент планировалось реализовать только
15 требований, то плановый объем будет

PV= 15-401000 = 600000 руб.

Следовательно, мы опережаем график (отклонение от графика
положительное) на величину

SV- EV- РИ- 800 000 - 600 000 = 200 000 руб.

Изменение отклонения от графика, выраженное в денежных еди-
ницах, при сокращении сроков проекта иллюстрируется на рис. 3 18

Если существует опережение графика, то это не обязательно озна-
чает, что проект идет успешно Хорошо это или плохо, зависит
от значения другого показателя, используемого в методе освоенного
объема: CV(Cost Variance) — отклонения по затратам, которое оце-
нивается по формуле

СИ= EV-AC,
Рис. 3.18. Оценка и прогноз показателей по методу освоенного объема
где AC (Actual Cost) — фактические затраты (фактическая стоимость
выполненных работ, т.е. фактические затраты на работы за опреде-
ленный период в рамках плановой операции или элемента ИСР).

Например, если мы, для того чтобы сократить время работ по
проекту, работали 25% времени сверхурочно или в выходные дни
с двойной оплатой, то фактические трудозатраты составили

АС = 20(30 • 1000 + 10 • 2000) = 1000000 руб.

Отклонения по затратам в нашем случае будет

CV= EV- AC = 800 000 - 1000 000 = -200 000 руб.

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

Отклонения от бюджета по срокам в абсолютных денежных еди-
ницах недостаточно для характеристики проектов разных масштабов.
Более наглядными являются относительные показатели- индекс вы-
полнения сроков SPI (Schedule Performance Index)

SPI=EV/PV

и индекс выполнения стоимости СР/(Cost Performance Index)

CPI = EV/AC.
Эти показатели характеризуют проект независимо от его размера.
Если значения обоих индексов больше единицы, то это свидетель-
ствует о благополучном состоянии проекта. Какие еще измеримые
показатели целесообразно применять в управлении программным
проектом? В первую очередь это показатель прогресса проекта —
доля реализованных и проверенных высокоуровневых требований
к проекту, например отношение числа завершенных сценариев ис-
пользования продукта к их общему числу. Другой показатель — ста-
бильность проекта — общее количество принятых (утвержденных
спонсором или заказчиком) изменений в плане управления проек-
том. Чем выше нестабильность в проекте, тем больше сложность
в управлении работами и ниже производительность участников.

Часто считается, что разработанный код программы — это реше-
ние проблемы, что далеко не так. Код является новым источником
проблем. Поэтому всегда следует измерять текущий размер про-
екта — количество строк исходного кода, добавленных, измененных
и удаленных в ходе выполнения проекта по разработке ПО. Чем
больше объем исходного кода, тем больше времени потребуется
на внесение изменений и исправление ошибок. При увеличении
объема проектного продукта трудозатраты на каждую новую строку
исходного кода увеличиваются. Если за номинал взять производи-
тельность проектной команды при производстве продукта в 10 KLOC
(KLOC — 1 тысяча строк исходного программного кода), то эта же
команда на проекте в 100 KLOC покажет производительность в 1,3—
1,7 раза меньшую, а на проекте в 1000 KLOC производительность
снизится в 1,6—3,0 раза.

Большой объем кода также потребует большего количества людей
на его сопровождение, поскольку даже если будет выявляться только
несколько критических ошибок в год, то один программист не смо-
жет их исправить в приемлемые сроки (например, за 24 ч в продукте
общим объемом в 1000 KLOC). Это связано с тем, что, для того чтобы
исправить ошибку в ограниченные сроки, необходимо оперативно
выявить и устранить ее причину, а для этого надо хорошо знать ар-
хитектуру и код программного продукта. Чтобы эффективно сопро-
вождать продукт подобного объема, необходимо иметь в «горячем»
резерве примерно 20 разработчиков, потому считается, что
50 KLOC — это предельный объем кода, который может удерживать
в голове и эффективно сопровождать один человек. При этом воз-
никает еще одна проблема: чем этих людей занимать в свободное
от исправлений ошибок время, если нет новых проектов по развитию
продукта.
Еще одним важным показателем состояния проекта является
средняя производительность — отношение текущего размера проекта
к фактическим затратам по проекту. С. Макконнелл приводит сле-
дующие показатели (минимальное, максимальное и среднее значе-
ния) производительности в KLOC на 1 чел.-мес. фактических затрат
для стандартных типов проектов объемом в 100 KLOC (табл. 3.4).

Таблица 3.4

Средняя чрои шодител^ность проекта

Тип проекта	Производительность, KLOC на 1 чел.-мес.		
	минимальная	средняя	максимальная
Интранет-система	300	800	7000
Бизнес-система	200	600	7000
Интернет-система	100	300	2000
Системное ПО, телекомму- никации	50	100	600
Системы реального времени	20	50	300

Высокая производительность в проекте не всегда является хоро-
шим признаком. В некоторых проектах вследствие активного при-
менения метода «сору + past» средняя производительность в разра-
ботке бизнес-системы достигала 2000 LOC чел.-мес., однако для
реализации требуемого функционала было написано в 3—4 раза
больше кода, чем это могло бы потребоваться при адекватной про-
работке архитектуры.

Рассмотрим еще одну группу количественных показателей, кото-
рые следует контролировать в ходе реализации проекта. Эти показа-
тели характеризуют качество программного продукта:

•	дефектность продукта — количество выявленных дефектов
на единицу объема продукта (например, KLOC)',

•	доля неустраненных дефектов — отношение количества незакры-
тых максимально критичных и критичных дефектов к количеству
выявленных несоответствий;

•	средние затраты на сопровождение — средние трудозатраты на ис-
правление одного дефекта (высокое значение этого показателя
может свидетельствовать о некачественной архитектуре ПП);

•	документированность кода — процент строк исходного кода прог-
раммы и комментарии по отношению к общему количеству строк
кода.

Следует подчеркнуть, что наблюдать надо за средними значе-
ниями показателей, а не пытаться измерять индивидуальные харак-
теристики производительности и качества, поскольку, во-первых,
вместо слаженной командной работы можно получить личную кон-
куренцию, а во-вторых, наиболее «продвинутые» разработчики ста-
нут работать на формальные показатели, а не на достижение целей
проекта. Если команда действительно состоялась, то для нее харак-
терна коллективная ответственность за достижение общих целей.
И как отмечает Т. Демарко, «менеджер проекта должен занимать
очередь, чтобы покритиковать сотрудника, не выполняющего свои
обещания», поскольку в «правильной» команде для этого всегда най-
дется масса желающих.

Завершение проекта. Главная цель фазы завершения проекта со-
стоит в проверке и передаче заказчику результатов проекта. Для этого
необходимо выполнить приемо-сдаточные работы в соответствии
с процедурой приемки, которая должна быть определена заранее
на самой ранней стадии проекта. Группа процессов завершения про-
екта представлена на рис. 3.19.

Группа процессов
завершения

Группы процессов

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

Управление
интеграцией проекта

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

Завершение
проекта или фазы

Закрытие закупок

Рис. 3.19. Группа процессов завершения проекта

Результаты проекта должны быть переданы на внедрение или
сопровождение или должным образом законсервированы для даль-
нейшего использования. Не должно оставаться «зависших» работ
по проекту. Все линейные руководители должны быть извещены
о завершении работ по проекту и освобождении сотрудников.

Важная задача, которая должна быть решена на данной фазе, —
это реализация обратной связи по проекту, целью которой является
сохранение результатов, знаний и опыта, полученных в проекте, для
более эффективного и качественного выполнения аналогичных про-
ектов в будущем. С этой же целью необходимо архивировать все по-
лученные результаты, документировать любой приобретенный опыт,
уроки по проекту и предложения по улучшению технологии выпол-
нения работ и управления проектами.
Все проекты, и в особенности «провальные», должны завершаться
итоговым отчетом, если компания не хочет «наступать на одни
и те же грабли». Всегда надо помнить о том, что «вчерашние проб-
лемы — это сегодняшние риски». Итоговый отчет должен содержать
следующую информацию.

1.	Итоги проекта.

1.1.	Достижение целей проекта.

1.2.	Дополнительные полезные результаты

1.3.	Фактические сроки.

1.4.	Фактические расходы.

1.5.	Обоснование отклонения от целей.

1.6.	Отклонения результатов от требований.

2.	Уроки проекта.

2.1.	Проблемы проекта и способы их решения.

2.2.	Материалы по программным компонентам для их после-
дующего использования.

2.3.	Предложения по изменению технологий или стандартов
компании.

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

3.7.	Мониторинг и управление
проектом

Мониторинг и управление работами проекта — это процесс отсле-
живания, проверки и регулирования исполнения проекта для дости-
жения целей, определенных в плане управления проектом.

Мониторинг является аспектом управления, осуществляемым
на протяжении всего проекта. Мониторинг включает в себя сбор,
измерение и распространение информации об исполнении, а также
оценку измерений и тенденций для оказания влияния на улучшение
процесса. Постоянный мониторинг дает команде управления про-
ектом возможность понимать общее состояние проекта и выявлять
области, на которые следует обратить особое внимание. Управление
включает в себя определение корректирующих или предупрежда-
ющих действий либо повторное планирование и отслеживание пла-
нов с целью установления, удалось ли решить проблему с помощью
предпринятых действий.

Процесс мониторинга и управления работами проекта направлен
на выполнение следующих действий:
•	сравнение фактического исполнения проекта с планом управ-
ления;

•	оценка исполнения в целях определения, требуются ли какие-
либо корректирующие или предупреждающие действия, с после-
дующей рекомендацией данных действий к исполнению;

•	выявление новых рисков и анализ, отслеживание и мониторинг
существующих рисков проекта с целью подтверждения того, что
все риски выявлены, об их статусе сообщено и соответствующие
планы реагирования исполняются;

•	поддержание точной, своевременно обновляемой информацион-
ной базы относительно продукта(ов) проекта и сопутствующей
документации на всем протяжении выполнения проекта;

•	предоставление информации, помогающей в составлении отчетов
о статусах, проведении измерений, исполнении и прогнозирова-
нии;

•	предоставление прогнозов, позволяющих корректировать инфор-
мацию о текущей стоимости и текущем расписании;

•	мониторинг реализации одобренных изменений по мере их по-
явления.

На рис. 3 20 представлена группа процессов мониторинга
и управления проектом. Рассмотрим их более подробно.

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

Управление сроками (расписанием) проекта представляет собой
процесс мониторинга статуса проекта для оценки его исполнения
и управления изменениями базового расписания. Базовое расписа-
ние — это особая версия расписания проекта, разработанная с по-
мощью анализа сети. Оно принимается и утверждается командой
управления проектом как базовое расписание с базовыми датами
старта и финиша. Базовое расписание является элементом плана
управления проектом.
Группа процессов
мониторинга и управления

Группы процессов
управления проектом

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

Подтверждение
содержания

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

Управление

расписанием

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

-

Управление

стоимостью

Управление
содержанием

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

Управление
интеграцией проекта

Контроль качества

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

Управление
закупочной
деятельностью

Мониторинг
и управление
работами проекта

Управление

рисками проекта

Мониторинг
и управление рисками

Осуществление
общего управления
изменениями

Управление
коммуникациями

проекта

П одготовка
отчетов об исполнении

Рис. 3.20. Группа процессов мониторинга и управления проектом

Управление расписанием связано с определением текущего со-
стояния расписания проекта, влиянием на факторы, вызывающие
изменения расписания, определением фактов изменения расписания
проекта, управлением фактическими изменениями по мере их воз-
никновения.

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

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

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

•	реакция на риски внедрена в соответствии с планом, необходимы
изменения;

•	изменение рисков по сравнению с предыдущими значениями;

•	определение влияния рисков и принятие необходимых мер;

•	реакция на риски является запланированным или случайным
процессом.

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

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

Тренды в процессе выполнения проекта подлежат проверке с ис-
пользованием данных о выполнении. Для мониторинга выполнения
всего проекта могут использоваться анализ освоенного объема и дру-
гие методы анализа отклонений проекта и трендов. На основании этих
анализов можно прогнозировать потенциальные отклонения проекта
на момент его завершения по показателям стоимости и расписания.
Отклонения от базового плана могут указывать на последствия, вы-
званные как угрозами, так и благоприятными возможностями.

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

Управление стоимостью проекта включает в себя процессы, необ-
ходимые для обеспечения гарантии того, что проект будет выполнен
в рамках утвержденного бюджета. Целью системы управления стои-
мостью (затратами) является разработка политики, процедур и ме-
тодов, позволяющих осуществлять планирование и своевременный
контроль затрат. Управление стоимостью выполняется на протяже-
нии всего ЖЦ проекта, при этом процессы управления реализуются
по-разному на различных этапах проектного цикла. Это находит от-
ражение в современной концепции управления стоимостью проекта
на протяжении всего проекта life-cycle costing — LCC (рис. 3.21).

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

Контроль стоимости проекта включает в себя: мониторинг стои-
мостных показателей реализации проекта с целью обнаружения от-
клонений от бюджета; управление изменениями в бюджете с целью
обеспечения выполнения бюджета; предотвращение ранее заплани-
рованных ошибочных решений; информирование всех заинтересо-
ванных лиц о ходе выполнения проекта.

Контроль стоимости проекта имеет две составляющие: во-пер-
вых, учетную, т.е. оценку фактической стоимости выполненных ра-
бот и затраченных ресурсов; во-вторых, прогнозную — оценку буду-
щей стоимости проекта.
Концепция
проекта

Обоснование
проекта

Планирование
проекта

Реализация
проекта

Завершение
проекта

Укрупненная
опенка
стоимости

Детальная
оценка
стоимости

Стоимостное планирование
или бюджетирование

Контроль стоимости проекта

Завершающая
оценка проекта

Рис. 3.21. Управление стоимостью на протяжении ЖЦ проекта

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

Под управлением качеством (Software Quality Management — SQM)
понимается совокупность организационной структуры и ответ-
ственных лиц, а также процедур, процессов и ресурсов для планиро-
вания и управления достижением качества ПС. Управление каче-
ством базируется на применении стандартных положений по гаран-
тии качества (Software Quality Assurance — SQA).

Цель процесса SQA состоит в гарантировании того, что продукты
и процессы соответствуют требованиям и планам. Процесс SQA
включает следующие виды деятельности', внедрение стандартов и со-
ответствующих процедур разработки 1IC на всех этапах ЖЦ; оценку
соблюдения положений этих стандартов и процедур.

Действия по обеспечению гарантии качества состоят в следу-
ющем:
•	проверка непротиворечивости и выполнимости планов;

•	согласование промежуточных рабочих продуктов с плановыми
показателями;

•	проверка соответствия изготовленных продуктов заданным тре-
бованиям;

•	анализ применяемых процессов на соответствие договору и пла-
нам;

•	согласование с заказчиком среды и методов разработки продукта;

•	проверка принятых метрик продуктов, процессов и приемов их
измерения на соответствие утвержденным стандартам и процеду-
рам измерения.

Целью процесса управления SQM является мониторинг (систе-
матический контроль) качества для получения гарантии того, что
продукт будет удовлетворять потребителя. При этом предполагается
определение количественных свойств качества, основанных на вы-
явленных и предусмотренных потребностях пользователей, а также
управление реализацией поставленных целей для достижения каче-
ства.

Процесс SQM основывается на гарантии того, что установлены
цели достижения требуемого качества в контрольных точках для всех
рабочих продуктов и определены стратегия достижения качества,
метрики, критерии, приемы, требования к процессу измерения и др.
Кроме того, определены и выполняются действия, связанные с пре-
доставлением продуктам свойств качества, а также проводится кон-
троль качества (SQA, верификация и валидация) и целей, выполня-
ются процессы измерения и оценивания конечного продукта на сте-
пень достижения требуемого качества.

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

Результаты измерений в процессе контроля качества являются
документированными результатами действий по контролю качества
в формате, определенном во время планирования качества. Результат
измерения — это фактическая величина, для которой используются
определенные метрики качества. Метрики качества описывают
в конкретных терминах параметры проекта или продукта с учетом
способа измерения этих параметров. Допуск определяет допустимые
отклонения метрики, например при измерении стоимости каждого
бюджетируемого результата отклонение определяется в процентах
от планового бюджета: «остаться в рамках одобренного бюджета
±10%». Метрики качества используются в процессах обеспечения
качества и управления качеством. Некоторыми примерами метрик
качества являются: производительность на момент времени; показа-
тели бюджета; частота дефектов, доля отказов; доступность, надеж-
ность и регулярность проведения испытаний.

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

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

Предоставление табельной карты в днях (в идеале — ноль)

Рис. 3.22. Диаграмма разброса

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

Гистограмма или столбиковая диаграмма отражает зависимость
частоты попадания элементов некоторой выборки в соответству-
ющие интервалы их группировки (категории). Каждый столбик
представляет параметр или свойство проблемы/ситуации. Высота
столбика означает частоту возникновения этого свойства. Количе-
ство и относительная высота столбиков могут иллюстрировать при-
чины возникновения проблемы.

Диаграмма Парето является особым типом гистограммы, отража-
ющей зависимость распределения определенных ресурсов или ре-
зультатов от большой совокупности причин. Например, на рис. 3.23
показано, какое количество обнаруженных дефектов является след-
ствием причин, относящихся к определенному типу или категории.
Порядок ранжирования элементов в диаграмме Парето может ис-
пользоваться при принятии решений о проведении корректирующих
воздействий. Команда проекта в первую очередь должна принимать
решения по тем проблемам, которые являются причиной наиболь-
шего количества дефектов.

Диаграмма Парето по причинам позднего ввода времени

| | Частота ----- Кумулятивный процент

Рис. 3.23. Диаграмма Парето
Диаграмма Парето концептуально связана с законом Парето, ко-
торый утверждает, что относительно малое число причин обычно
вызывает большинство проблем или дефектов. Этот закон также из-
вестен как принцип «80/20», согласно которому 80% проблем вы-
звано 20% причин. Диаграммы Парето очень удобно использовать
для подобного анализа.

Причинно-следственная диаграмма, называемая также диаграммой
Ишикавы или диаграммой «рыбий скелет», иллюстрирует связь раз-
личных факторов с возможными проблемами и следствиями
(рис. 3 24). Возможную первопричину проблемы можно выявить,
постоянно задавая вопросы «почему?» или «как?» по мере движения
вдоль одной из линий. При анализе первопричин могут быть исполь-
зованы диаграммы «почему—почему» и «как—как». Причинно-след-
ственные диаграммы часто используются при анализе рисков.

Возможные причины

Эффект

Рис. 3.24. Причинно-следственная диаграмма

Контрольные вопросы

1.	Каково содержание понятий проекта и процесса управления проектом?
Назовите процессы управления проектом.

2.	Что понимается под инициацией проекта? Определите процессы ини-
циации.

3.	Кто относится к возможным ключевым участникам и заинтересован-
ным сторонам проекта7

4.	В чем состоит стоимостная оценка проекта? Проанализируйте влияние
стоимости необходимых ресурсов на стоимость реализации проекта.

5.	Как определить сроки реализации проекта?

6.	В чем заключается планирование проекта? Перечислите основные про-
цессы планирования проекта.

7.	Что понимается под планированием управления содержанием проекта?

8.	Что понимается под планированием организационной структуры про-
екта?

9.	Что понимается под управлением конфигурацией проекта?

10.	Что понимается под планированием управления качеством проекта?
11.	Для чего необходимо создание иерархической структуры работ?

12.	Как создается расписание проекта?

13.	В чем заключается руководство и управление исполнением проекта?
Перечислите основные процессы исполнения и завершения проекта.

14.	Чем отличается общее планирование проекта от рабочего планирова-
ния?

15.	Сформулируйте принципы количественного управления проектом.

16.	В чем заключается мониторинг и управление работами проекта? Пере-
числите основные процессы мониторинга и управления проектом.

17.	В чем заключается мониторинг и контроль рисков?

18.	В чем заключается контроль стоимости проекта?

19.	В чем заключается контроль и управление качеством проекта?

20.	Какие диаграммные техники используются при контроле и монито-
ринге состояния проекта? Охарактеризуйте их.

Литература

1.	Афонин А.М., Царегородцев Ю.Н., Петрова С.А. Управление проектами:
учеб, пособие. — М.: Форум, 2010. — 184 с.

2.	Бабенко Л. II., Лаврищева Е.М. Основы программной инженерии: учеб-
ник. — Киев: Знание, 2001. — 269 с.

3.	Брукс Ф. Мифический человеко-месяц, или Как создаются прог-
раммные комплексы. — СПб.: Символ-Плюс, 2000. — 304 с.

4.	Гонтарева И.В., Нижегородцев Р.М., Новиков Д.А. Управление проек-
тами: учебное пособие. — М.: ЛИЕРОКОМ, 2013. — 384 с.

5.	Джалота П. Управление программными проектами на практике. —
Лори, 2005. — 223 с.

6.	Коваленко С П. Управление проектами: практическое пособие. —
Минск: Тетралит, 2013. — 192 с.

7.	Ларсон Э.У., Греи К.Ф. Управление проектами: учебник. — М.: ДиС,
2013. - 784 с.

8.	Лич Л. Вовремя и в рамках бюджета: Управление проектами по методу
критической цепи. — М.: Альпина Пабл., 2010. — 354 с.

9.	Макконнелл С. Сколько стоит программный проект. — СПб.: Питер,
2007. - 297 с.

10.	Мазур И.И., Шапиро В.Д., Ольдерогге Н.Г. Управление проектами: учеб
пособие для студентов / под общ. ред. И.И. Мазур. — М.: Омега-Л,
2013.-960 с.

11.	Ньютон Р. Управление проектами от А до Я. С. — М.: Альпина Пабл.,
2013. - 180 с.

12.	Нъюэл М.В. Управление проектами для профессионалов. Руководство
по подготовке к сдаче сертификационного экзамена РМР. — М.:
КУДИЦ-Образ, 2006. - 416 с.

13.	Перевощиков Ю С. Управление проектами в машиностроении: учебное
пособие. - М.: ИНФРА-М, 2014. - 233 с.
14.	Полковников А.В., Дубовик М.Ф. Управление проектами. Полный курс
МВА. — М.: Олимп-Бизнес, 2013. — 552 с.

15.	Попов Ю. И., Яковенко О.В. Управление проектами: учебное пособие. —
М.: НИЦ ИНФРА-М, 2013. - 208 с.

16.	Романова М.В. Управление проектами: учеб, пособие. — М.: ФОРУМ:
ИНФРА-М, 2013. - 256 с.

17.	Сооляттэ А.Ю. Управление проектами в компании: методология, тех-
нологии. практика: учебник. — М.: МФПУ Синергия, 2012. — 816 с.

18.	Товб А.С., Ципес Г.Л. Управление проектами: стандарты, методы,
опыт. — М.: Олимп-Бизнес, 2005. — 240 с.

19.	Том Демарко, Тимоти Листер. Человеческий фактор: успешные проекты
и команды. — СПб.: Символ-Плюс, 2005. — 256 с.

20.	Фатрелл Р.Т., Шафер Д.Ф., Шафер Л.И. Управление программными
проектами. Достижение оптимального качества при минимуме за-
трат. — М.: Вильямс, 2004. — 1136 с.

21.	Харпер-Смит П. Управление проектами. — М.: ДиС, 2011. — 240 с.

22.	Шафер Д., Фатрел Р., Шафер Л. Управление программными проектами:
достижение оптимального качества при минимуме затрат. — М.:
Вильямс, 2003. — 1136 с.

23.	Barry Boehm et al. Software cost estimation with COCOMO JI. Englewood
Cliffs, NJ: Prentice-Hall, 2000.

24.	Glib T. Principles of software engineering management. — Wokingham, Eng-
land: Addison-Wesley, 1998 — 396 p.

25.	IEEE Std 1058-1998. IEEE Standard for Software Project Management
Plans.

26.	Microsoft Solutions Framework. Дисциплина управления рисками MSF,
вер. 1.1, 2002.

27.	Thayer R.H. ed., Software Engineering Project Managment, 2nd.ed., IEEE
CS Press, Los Alamitos, Calif. 1997. — 391 p.
Глава 4

РАЗРАБОТКА ТРЕБОВАНИЙ

4.1.	Определение программных требований

Проблемы, которые приходится решать специалистам в процессе
создания программного обеспечения, обычно очень сложны. При-
рода этих проблем нс всегда ясна, особенно если разрабатываемая
программная система инновационная. В частности, трудно четко
сформулировать тс действия, которые должна выполнять система.
Описание функциональных возможностей и ограничений, наклады-
ваемых на программную систему, называется требованиями к сис-
теме, а сам процесс формирования, анализа, документирования
и проверки этих функциональных возможностей и ограничений —
разработкой требований (requirements engineering).

Согласно стандарту РМВОК требования — это:

•	условия или возможности, которыми должна обладать система
или системные компоненты, чтобы выполнить контракт или удо-
влетворять стандартам, спецификациям или другим формальным
документам;

•	структурированные (уточненные) и задокументированные по-
требности, пожелания и ожидания заказчика, пользователя и дру-
гих заинтересованных сторон.

Согласно IEEE Standard требование — это:

•	возможность, необходимая пользователю для решения проблем
или достижения целей;

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

Таким образом, программные требования (Software Require-
ments) — свойства ПО, которые должны быть надлежащим образом
представлены для решения конкретных практических задач. Данная
глава касается вопросов извлечения/сбора, анализа, специфициро-
вания и утверждения требований. Опыт индустрии информационных
технологий показывает, что вопросы, связанные с управлением тре-
бованиями, оказывают критически важное влияние на программные
проекты и, в определенной степени, на сам факт возможности
успешного их завершения. Только систематичная работа с требова-
ниями позволяет корректным образом обеспечить моделирование
задач реального мира и формулирование необходимых приемочных
тестов для того, чтобы убедиться в соответствии создаваемых прог-
раммных систем критериям, заданным реальными практическими
потребностями.

На практике обычно применяется подход, базирующийся
на определении групп требований к программному продукту. Чаще
всего используются следующие группы (типы, категории) требова-
ний'. системные, программные, функциональные, нефункциональные
(в частности, атрибуты качества) и т.п. Классический пример высо-
коуровневого структурирования групп требований к программному
продукту описан в работах одного из классиков дисциплины управ-
ления требованиями К. Вигерса (рис. 4.1).

Рис. 4.1. Группы требований, предъявляемых к ПП

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

В общем случае под требованиями к программной системе пони-
мают свойства, которыми она должна обладать для адекватного вы-
полнения предписанных ей функций. Примерами таких функций
могут быть бизнес-функции, документооборот, управление данными
и структурой информации, необходимой для принятия системных
решений, и др. В SWEBOK изложены основные концепции и осо-
бенности инженерии требований (рис. 4.2).

Модель процессов ЖЦ		Техника обсуждения		Специфи- кация требований		Просмотр требований		Управление изменениями
								
Длительность исполнителей (актеров)		Извлечение требований		Системати- зация требований		Трассиро- вание требований		Связь с процессами
								
Управление требованиями на процессах ЖЦ		Анализ требований		Описание документа		Валидация требований		Проверка и верифи- кация
								
Улучшение качества		Сбор требований		Согласование документа		Прото- типирование		Оценка качества

Приемка
требований

Рис, 4.2. Основные разделы разработки требований

Структура обсуждаемой области знаний в большой степени со-
вместима со стандартами IEEE12207.X, 1SO/1EC, ГОСТ Р ИСО/МЭК
12207.

Классификация программных требований. Некоторые проблемы,
возникающие в процессе разработки требований, порождены отсут-
ствием четкого понимания различия между разными уровнями тре-
бований. Чтобы различить требования разных уровней, используют
термины: пользовательские требования (user requirements) — для
обозначения высокоуровневых обобщенных требований и систем-
ные требования (system requirements) — для детализированного опи-
сания выполняемых системой функций. Кроме требований этих двух
уровней, на практике обычно применяется еще более детализиро-
ванное описание программной системы — проектная системная спе-
цификация (software design specification), которая может служить
мостом между этапом разработки требований и этапом проектиро-
вания системы. Три перечисленных вида требований можно опреде-
лить следующим образом.

Пользовательские требования — описание на естественном языке
(с использованием поясняющих диаграмм) функций, выполняемых
системой, и ограничений, накладываемых на нее.

Системные требования — детальное описание системных функций
и ограничений, которое иногда называют функциональной специфи-
кацией. Она служит основой для заключения контракта между поку-
пателем системы и разработчиками ПО.

Проектная системная спецификация — обобщенное описание
структуры программной системы, которое будет основой для более
детализированного проектирования системы и ее последующей реа-
лизации. Эта спецификация дополняет и детализирует специфика-
цию системных требований.

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

Функциональные требования включают в себя перечень сервисов,
которые должна выполнять система, причем должно быть указано, как
система реагирует на те или иные входные данные, как она ведет себя
в определенных ситуациях и т.д. В некоторых случаях указывается, что
система не должна делать (так называемые обратные требования).

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

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

Бизнес-правила. Представляют собой определенные корпоратив-
ные политики, промышленные стандарты, законы и иные норматив-
ные документы и контролирующие принципы, которые отражают
объективные условия, в которых предполагается эксплуатация прог-
раммного продукта. Выделяют следующие категории бизнес-правил:
факты (некие истинные утверждения относительно предметной об-
ласти); ограничения (перечень недопустимых операций программ-
ной системы); активаторы операций (инициируют выполнение не-
которой последовательности действий); выводы (формируют новый
факт на основе имеющихся); вычисления (формулы для вычисления
определенных атрибутов предметной области, например скидки при
покупке товара). Бизнес-правила иногда хранятся отдельно от тре-
бований, в другом документе. Кроме того, часто бизнес-правила спе-
циально составляются для какой-либо предметной области, хранятся
отдельно от бизнес-правил других предметных областей и могут по-
вторно использоваться в схожих проектах, т.е. управление бизнес-
правилами следует осуществлять на корпоративном уровне.

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

Рассмотрим перечисленные категории требований более по-
дробно.

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

Нефункциональные требования. Как следует из названия, нефунк-
циональные требования не связаны непосредственно с функциями,
выполняемыми системой. Они связаны с такими интеграционными
свойствами системы, как надежность, время ответа или размер сис-
темы. Кроме того, нефункциональные требования могут определять
ограничения на систему, например на пропускную способность
устройств ввода-вывода или форматы данных, используемых в сис-
темном интерфейсе.
Многие нефункциональные требования относятся к системе в це-
лом, а не к отдельным ее средствам. Это означает, что они более зна-
чимы и критичны, чем отдельные функциональные требования.
Ошибка, допущенная в функциональном требовании, может снизить
качество системы; ошибка в нефункциональных требованиях может
сделать систему неработоспособной.

Вместе с тем нефункциональные требования могут относиться
не только к самой программной системе, например одни из них мо-
гут относиться к технологическому процессу создания ПО, другие —
содержать перечень стандартов качества, используемых в процессе
разработки. Кроме того, в спецификации нефункциональных требо-
ваний может быть указано, что проектирование системы должно
выполняться только определенными CASE-средствами, и приведено
описание процесса проектирования, которому необходимо следо-
вать.

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

Все нефункциональные требования могут быть разбиты на три
группы.

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

Организационные требования отображают политику и организаци-
онные процедуры заказчика и разработчика ПО. включают стан-
дарты разработки программного продукта, требования к реализации
ПО (к языку программирования и методам проектирования), выход-
ные требования, которые определяют сроки изготовления программ-
ного продукта, и сопутствующую документацию.

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

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

В табл. 4 1 приведены показатели, с помощью которых можно
специфицировать нефункциональные системные свойства.

Таблица 4.1

Количественные показатели нефункциональных требований

Показатель	Единицы измерения
Скорость	Число выполненных транзакций в секунду; время реак- ции на действия пользователя; время обновления экрана
Размер	Килобайты; количество модулей памяти
Простота эксплуатации	Время обучения персонала; количество статей в справоч- ной системе
Надежность	Средняя продолжительность времени между двумя по- следовательными проявлениями ошибок в системе; ве- роятность выхода системы из строя; коэффициент готов- ности системы
Устойчивость к сбоям	Время восстановления системы после сбоя; процент со- бытий, приводящих к сбоям; вероятность порчи данных при сбоях
Переносимость	Процент машинно зависимых операторов; количество машинно зависимых подсистем

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

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

Пользовательские требования. Пользовательские требования
к системе должны описывать функциональные и нефункциональные
системные требования так, чтобы они были понятны даже пользо-
вателю, не имеющему специальных технических знаний. Эти требо-
вания должны определять только внешнее поведение системы, из-
бегая по возможности определения структурных характеристик сис-
темы. Пользовательские требования должны быть написаны
естественным языком с использованием простых таблиц, а также
наглядных и понятных диаграмм.

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

Системные требования. Системные требования представляют со-
бой более детальное описание пользовательских требований
и обычно служат основой для заключения контракта на разработку
ПС. Спецификации системных требований часто пишутся на есте-
ственном языке, что порождает определенные проблемы при их на-
писании. Применение естественного языка подразумевает, что те,
кто пишет спецификацию, и те, кто ее читает, одни и те же слова
и выражения понимают одинаково, что на самом деле не так. Есте-
ственному языку присуща определенная размытость понятий, вслед-
ствие чего одно и то же требование может трактоваться разными
людьми по-разному. Во избежание подобных проблем разработаны
методы описания требований, которые структурируют специфика-
ции и уменьшают размытость определений (табл. 4 2).

На практике выразить некоторые нефункциональные требования
с помощью количественных показателей весьма затруднительно. Часто
заказчик ПО не может оформить свое видение будущей системы по-
средством требований, выраженных количественными показателями.
Некоторые системные требования, например удобство сопровождения,
вообще нельзя сформулировать через количественные показатели.
Кроме того, затраты на объективное измерение количественных не-
функциональных требований могут оказаться крайне высокими.
Таблица 4.2

Методы описания требсваний

Система записи	Описание
Структурированный естественный язык	Использование стандартных форм и шаблонов для написания спецификаций
Языки описания требований	Специальные структурированные языки (подобно языкам программирования), где спецификация тре- бований строится на основе выбранной операцион- ной модели системы
Графические нотации	Использование диаграмм и блок-схемы, дополнен- ных текстовыми пояснениями. Наиболее известные примеры такого описания: диаграммы структурного анализа и проектирования, метод описания вариан- тов использования
Математические нотации	Системы нотаций на основе математических кон- цепций, таких как теория конечных автоматов или теория множеств. Формализованная однозначная запись системных требований. Однако многие за- казчики не понимают формальных спецификаций, вследствие чего возникают определенные проблемы при заключении контрактов на разработку ПП

4.2.	Разработка требований

Разработка требований — это процесс, включающий в себя меро-
приятия, необходимые для создания и утверждения документа, со-
держащего спецификацию системных требований. Различают четыре
основных этапа процесса разработки требований', анализ технической
осуществимости создания системы; формирование и анализ требо-
ваний; специфицирование требований и создание соответствующей
документации; аттестация этих требований. На рис. 4.4 показаны
взаимосвязи между этими этапами и документы, сопровождающие
каждый этап процесса разработки системных требований.

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

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

Рис. 4.4. Процесс разработки требований
моделей системы, которые затем используются для ее подробного
специфицирования. Хотя структурные методы играют существенную
роль в процессе разработки требований, многие аспекты этого про-
цесса не могут быть охвачены данными методами. Они неэффек-
тивны на ранних стадиях процесса разработки, например таких, как
формирование требований.

Анализ осуществимости требований. Для новых программных
систем процесс разработки требований должен начинаться с анализа
их осуществимости. Началом такого анализа является общее описа-
ние системы и ее назначения, а результатом анализа — отчет, в ко-
тором должна быть четкая рекомендация, продолжать или нет про-
цесс разработки требований проектируемой системы. Другими сло-
вами, анализ осуществимости должен дать ответы на следующие
вопросы: отвечает ли система общим бизнес-целям организации-
заказчика и организации-разработчика; можно ли реализовать сис-
тему, используя существующие на данный момент технологии
и не выходя за пределы заданной стоимости; можно ли обьединить
систему с другими системами, которые уже эксплуатируются орга-
низацией.

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

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

Как только будут сформулированы подобные вопросы, необхо-
димо определить источники информации. Это могут быть менед-
жеры отделов, где система будет использоваться, разработчики ПО,
знакомые с типом будущей системы, технологи, конечные пользо-
ватели и т.д. После обработки собранной информации готовится
отчет по анализу осуществимости создания системы. В нем должны
быть даны рекомендации относительно продолжения разработки
системы. Могут быть предложены изменения бюджета и графика
работ по созданию системы или предъявлены более высокие требо-
вания к системе.

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

Один из ключевых принципов программной инженерии заклю-
чается в обеспечении взаимодействия между пользователями и ин-
женерами. Прежде чем начинается разработка ПО, именно специа-
листы «по требованиям», аналитики, перекидывают тот самый «мо-
стик» между заказчиками и исполнителями, задающий такой уровень
коммуникаций и взаимопонимания между ними, который необхо-
дим для решения задач проекта.

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

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

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

Существует множество практик и подходов к извлечению требова-
ний, позволяющих добиться действительно стройной системы тре-
бований, отвечающей реальным потребностям и приоритетам заказ-
чиков. Среди них можно выделить следующие.

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

Сценарии — контекст для сбора пользовательских требований,
определяющий ответы на вопросы «что если» и «как это делается»
в отношении бизнес-процессов, реализуемых пользователями

Прототипы являются отличным инструментом для уточнения
и/или детализации требований. Существуют разные подходы к про-
тотипированию — от «бумажных» моделей до пилотных подсистем,
реализуемых как самостоятельные (в терминах управления ресур-
сами) проекты или бета-версии продуктов Часто прототипы посте-
пенно трансформируются в результаты проекта и используются для
проверки и утверждения требований.

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

Наблюдение (observation) подразумевает непосредственное при-
сутствие аналитиков и инженеров рядом с пользователем в процессе
выполнения последним его работ по обеспечению функциониро-
вания бизнес-процессов. В определенной степени можно провести
аналогию с практикой присутствия представителя заказчика в про-
ектной группе исполнителя (типовая практика в extreme Program-
ming «on-site customer» — «присутствующий заказчик»). Данная тех-
ника является достаточно затратной, но в то же время очень эффек-
тивной, а иногда просто незаменимой, особенно если речь идет
о достаточно сложных и взаимосвязанных бизнес-процессах.

Существуют и другие достаточно эффективные практики, описа-
ние которых можно найти в литературе, например Requirements
Workshop, Role Playing, Storyboarding и т.п.

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

В процесс формирования требований могут быть вовлечены люди
разных профессий. В нем принимают участие конечные пользова-
тели, которые будут работать с системой, инженеры, которые разра-
батывают и эксплуатируют подобные системы, бизнес-менеджеры,
специалисты по предметной области, где будет эксплуатироваться
система, и даже представители профсоюзов.
Процесс формирования и анализа требований достаточно сложен
по ряду причин. Лица, участвующие в формировании требований,
часто не знают конкретно, чего они хотят от компьютерной системы,
за исключением наиболее общих положений; им трудно сформули-
ровать, что они ожидают от системы, они могут предъявлять нере-
альные требования, так как не подозревают, какова стоимость их
реализации. Лица, участвующие в формировании требований, выра-
жают в этих требованиях собственные точки зрения, основываясь
на личном опыте работы. Кроме того, они имеют различные пред-
почтения и могут выражать их разными способами. Разработчики
должны определить все потенциальные источники требований и вы-
делить общие и противоречивые требования.

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

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

Обобщенная модель процесса формирования и анализа требова-
ний показана на рис. 4.5. Каждая организация использует соб-
ственный вариант этой модели, зависящий от «местных» факторов:

Рис. 4.5. Процесс формирования и анализа требований
опыта работы коллектива разработчиков; типа разрабатываемой сис-
темы; используемых стандартов и т.д.

В общем случае процесс формирования и анализа требований состоит
из нескольких этапов.

1.	Анализ предметной области. Аналитики должны изучить пред-
метную область, где будет эксплуатироваться система.

2.	Сбор требований. Это процесс взаимодействия с лицами, фор-
мирующими требования. Вс время этого процесса продолжается
анализ предметной области.

3.	Классификация требований. На этом этапе бесформенный на-
бор требований преобразуется в логически связанные группы требо-
ваний.

4.	Разрешение противоречий. Без сомнения, требования много-
численных лиц, занятых в процессе формирования требований, бу-
дут противоречивыми. На этом этапе определяются и разрешаются
противоречия такого рода.

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

6.	Проверка требований. На этом этапе определяется их полнота,
последовательность и непротиворечивость.

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

Анализ требований включает в себя проверку требований по сле-
дующим показателям:

•	корректность — отсутствие ошибок в формулировке требования;

•	недвусмысленность — отсутствие неоднозначности в толковании
требования;

•	полнота набора требований — весь набор требований должен пол-
ностью описывать разрабатываемую систему;

•	непротиворечивость набора требований — отсутствие во всей со-
вокупности требований, противоречащих друг другу;

•	проверяемость — необходимо, чтобы каждое требование можно
было в дальнейшем протестировать;
•	трассируемость — наличие связи с требованиями, стоящими
выше и ниже в общей иерархии (там, где указанные элементы
иерархии существуют);

•	понимаемость — требование должно быть описано на понятном
для всех участников процесса разработки языке.

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

Известны следующие способы представления требований'.

•	документация, в которой используется четко структурированный
и аккуратно используемый естественный язык;

•	графические модели, иллюстрирующие процессы трансформации
состояний системы и их изменения, взаимодействия данных,
а также логические потоки, классы объектов и отношения между
ними;

•	формальные спецификации, где требования определены с по-
мощью математически точных, формальных языков; обеспечи-
вают наивысшую степень точности, однако немногие разработ-
чики, и еще меньше клиенты, знакомы с ними, поэтому они
не могут, используя этот способ, проверить спецификации на на-
личие ошибок.

В терминологии ряда методологий устоялся термин «специфика-
ция программных требований» («software requirements specification» —
SRS). На самом деле для сложных систем существует целый ком-
плекс спецификаций, т.е. доку moi нов, которые являются результатом
сбора и анализа требований, их моделирования и архитектурного
проектирования. Эти документы систематически анализируются,
в них вносятся изменения, они пересматриваются и утверждаются.
Чаще всего для описания требований проектов используется три
основных документа (спецификации): определение системы (system
definition), системные требования (system requirements) и программные
требования (software requirements). Таким образом, определены три
уровня спецификации ПО:
•	пользовательские требования,

•	системные требования;

•	спецификация структуры программной системы.

Пользовательские требования наиболее обобщенные, специфи-
кация структуры наиболее детальна. Формальные математические
спецификации находятся где-то между системными требованиями
и спецификацией структуры. Они не содержат деталей реализации
системы, но должны представлять ее полную математическую мо-
дель.

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

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

Увеличение участия подрядчиков

Уменьшение участия заказчиков

Разработка спецификации

Проектирование

Рис. 4.6. Этапы разработки спецификации

Создание формальной спецификации требует детального анализа
системы, который позволяет обнаружить ошибки и несоответствия
в спецификации неформальных требований. Эта возможность обна-
ружения ошибок — наиболее важный аргумент для использования
формальной спецификации. Проблемы в требованиях, которые оста-
Рис. 4.7. Разработка формальной спецификации
ются необнаруженными до последних стадий процесса разработки
ПО, обычно требуют больших затрат на исправление.

Разработка и анализ формальной спецификации требуют допол-
нительных расходов На рис. 4.8 приведены диаграммы, иллюстри-
рующие стоимость создания ПО при разработке формальной специ-
фикации и без нее. При обычном процессе разработки ПО стоимость
аттестации системы составляет около 50% всей стоимости разра-
ботки, а стоимость проектирования и реализации системы в два раза
больше стоимости разработки спецификации. При использовании
формальной спецификации стоимости разработки спецификации
и реализации системы соизмеримы, а стоимость аттестации значи-
тельно снижается, поскольку в процессе разработки формальной
спецификации обнаруживаются и устраняются недоработки в тре-
бованиях, тем самым исключается переделка системы на последних
стадиях ее создания

Существует два основных подхода к разработке формальной спе-
цификации, которые используются для написания детализирован-
ных спецификаций нетривиальных программных систем:

•	алгебраический подход, когда система описывается в терминах
операций и их отношений;

•	подход, ориентированный на моделирование, при котором модель
системы строится с использованием математических нотаций, та-
ких как множества и последовательности, а системные операции
определяются тем, как они изменяют состояния системы.

Для разработки формальных спецификаций последовательных
и параллельных систем в настоящее время создано несколько язы-
ков, представленных в табл. 4.3.

Таблица 4.3

Языки разработки формальных спецификаций

Тип языка	Последовательные системы	Параллельные системы
Алгебраический	Larch	Lotos
Основанный на моделях	O8J, Z, VDM, Б	CSP, сети Петри

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

Аттестация требований. Определение требований напрямую свя-
зано с процедурами проверки (verification) и утверждения/аттестации
(validation), как это сформулировано в ГОСТ Р и ISO/IEC12207. При-
нято считать, что требования описаны неполностью, если для них
не заданы правила V&V (verification & validation — проверка и атте-
стация), т.е. не определены способы проверки и утверждения. Про-
цедуры проверки являются отправной течкой для инженеров-тести-
ровщиков и специалистов по качеству, непосредственно отвечающих
за соответствие получаемого программного продукта предъявляемым
к нему требованиям.

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

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

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

Проверка на непротиворечивость. Спецификация требований
не должна содержать противоречий. Это означает, что в требованиях
не должно быть противоречащих друг другу ограничений или раз-
личных описаний одной и той же системной функции.

Проверка на полноту. Спецификация требований должна содер-
жать требования, которые определяют все системные функции
и ограничения, налагаемые на систему.

Проверка на выполнимость. На основе знания существующих тех-
нологий требования должны быть проверены на возможность их
реального выполнения. Здесь также проверяются возможности фи-
нансирования и график разработки системы.

Существует ряд методов аттестации требований, которые можно
использовать совместно или каждый в отдельности.

Обзор требований — один из распространенных методов проверки
требований — инспектирование или обзор требований (Requirements
Review), системный анализ рецензентами. Суть его заключается
в том, что ряд лиц, вовлеченных в проект (для крупных проектов —
специально выделенные специалисты), «вычитывают» требования
в поисках необоснованных предположений или описаний, допуска-
ющих множественные интерпретации, а также наличия в тексте про-
тиворечий, несогласованности, недостаточной степени детализации
или отклонений от принятых стандартов.

Прототипирование. В общем случае прототипирование (Prototyp-
ing) подразумевает проверку инженерной интерпретации прог-
раммных требований и извлечение новых требований, не опреде-
ленных или неясных на ранних итерациях их сбора. На этом этапе
прототип системы демонстрируется конечным пользователям и за-
казчику, которые могут экспериментировать с этим прототипом,
чтобы убедиться, что он отвечает их потребностям.

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

Среди возможных негативных последствий прототипирования
стоит выделить следующие:

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

•	превращение прототипа в реальную систему за счет постоянного
добавления новых свойств и функциональности «для проверки»,
в результате часто бывает нарушена архитектурная целостность,
не обеспечивается необходимая масштабируемость и качество
получаемого программного продукта.

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

Конечно, эти факторы можно превратить и в положительные сто-
роны прототипа. Кроме того, не стоит считать, что прототип — это
всегда нечто, воплощенное в код. Прототипом пользовательского
интерфейса может быть, например, просто «прорисованный» на бу-
маге или в электронной форме набор переходов между экранами
(диалоговыми окнами) системы. Этот подход часто используется
в Agile-практиках (Agile — методология «гибкого» подхода к разра-
ботке, когда требования уточняются заказчиком в процессе разра-
ботки системы, в том числе и с использованием прототипов).
Так или иначе, выбор того или иного метода прототипирования,
да и сам факт такого способа проверки требований или технологи-
ческих идей должны основываться на временных и других име-
ющихся ресурсах, опыте в прототипировании и, конечно, степени
сложности создаваемой программной системы.

Приемочные тесты (Acceptance Tests) служат для проверки и ат-
тестации требований. Требования должны быть верифицируемы,
а те из них, которые не могут быть проверены и аттестованы (утверж-
дены), — это всего лишь «пожелания». Именно так они будут вос-
приниматься разработчиками даже в случае их высокой значимости
для пользователей. Если описанное требование не сопровождается
процедурами проверки — в большинстве случаев говорят о недоста-
точной детализации или неполном описании требования и, соответ-
ственно, спецификация требований должна быть отправлена на до-
работку и в случае необходимости должны быть предприняты допол-
нительные усилия, направленные на сбор требований.

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

Можно говорить о том, что процедура анализа требований счита-
ется выполненной только тогда, когда все требования, включенные
в спецификацию, имеют оценку соответствия создаваемому про-
граммному продукту. Чаще всего столь строгое ограничение на степень
законченности спецификации накладывается на функциональные
требования и атрибуты качества (например, время отклика системы).

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

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

4.3. Работа с требованиями

Работа с требованиями имеет итеративную природу. В большин-
стве случаев понимание и интерпретация требований продолжают
эволюционировать в процессе проектирования и разработки ПО.
Кроме того, требования часто меняются в силу изменений бизнес-
контекста, для которого создается и в котором эксплуатируется ПО.
Необходимо понимать неизбежность изменений и планировать шаги
по уменьшению проблем, связанных с изменениями. В то же самое
время современные практики гибкой разработки говорят о том, что
необходимо концентрироваться только на том, что требует внимания
«прямо сейчас», не отвлекаясь на предупреждение всех возможных
рисков, в том числе связанных с изменениями, включая изменения
требований. Трудно определить, какой подход — предупреждение
или реагирование — гарантированно приводит к успеху. Более того,
если кто-то однозначно настаивает только на одной из идей и пол-
ностью отвергает другую — это профанация. Восприятие изменений
и возможность их своевременной обработки — вопрос способности
проектной команды работать в условиях постоянно меняющихся
условий, принимаемых архитектурных решений и многих других
культурных, технологических и организационных факторов. Гак или
иначе, понимание меняющейся природы требований — один из фак-
торов адекватного реагирования на сами изменения, а следова-
тельно, и возможность успешного завершения проекта.

Итерационный процесс работы с требованиями. На практике все
действия по выявлению, анализу, спецификации и проверке требо-
ваний не удается выполнить последовательно и за один проход. Эти
действия выполняются попеременно, поэтапно и повторяются
(рис. 4.10). Работая с клиентами в качестве аналитика, необходимо
задавать вопросы, выслушивать ответы и наблюдать за действиями
клиентов (этап выявления требований). Далее на этапе анализа по-
Повторная оценка

Рис. 4.10. Итерационный процесс выявления, анализа, специфицирования
и проверки требований

лученную информацию обрабатывают, классифицируют по различ-
ным категориям и соотносят потребности клиентов с возможными
требованиями к ПО. Затем оформляют информацию от клиентов
и выработанные требования в виде письменных документов и диа-
грамм (этап спецификации) и предлагают представителям пользова-
телей подтвердить, что написанный текст точен и полон, или испра-
вить возможные ошибки (этап проверки). Этот итерационный про-
цесс и есть процедура работы с требованиями.

Из-за разнообразия проектов по разработке ПО и организацион-
ных культур единою, шаблонного подхода к работе с требованиями
не существует. На рис. 4 11 показана схема работы с требованиями,
которая с разумными исправлениями подойдет для большинства
проектов.

Как правило, действия выполняются в основном по порядку, од-
нако сам процесс не является строго последовательным. Первые семь
действий обычно однократно выполняются на ранних стадиях работы
над проектом (однако команде разработчиков, скорее всего, придется
периодически изменять приоритеты), остальные необходимы для
каждого очередного выпуска или этапа работы над проектом. Оценив
доступные способы общения с представителями пользователей,
нужно выбрать подходящие приемы выявления требований (круглые
столы, исследования, опросы и т.д.) и спланировать время и ресурсы,
необходимые для сбора информации (этап 5 на рис. 4.11).

Многие системы создаются поэтапно, и поэтому любой команде,
работающей над проектом, необходимо определить приоритеты ва-
риантов использования пользовательских требований (этап 7). Рас-
ставив приоритеты, вы решите, на каком этапе следует реализовать
те или иные варианты использования. В случае новых систем и зна-
чительных усовершенствований на этапе 14 нужно определить или
уточнить архитектуру, а на этапе 15 распределить функциональные
требования по конкретным подсистемам. Этапы 12 и 17 — это опе-
рации по контролю качества, в результате которых, возможно, при-
Рис. 4.11. Общая схема работы с требованиями

дется вернуться, чтобы исправить ошибки, улучшить модели анализа
или выявить упущенные ранее требования. Прототипы, создаваемые
на этапе 13, зачастую выявляют необходимость усовершенствования
и модификации определенных ранее требований. Завершив для ка-
кой-либо части требований этап 17, можно приступать к реализации
соответствующей части системы. Повторите этапы 8—17 для следу-
ющих наборов вариантов использования, которые могут войти в бо-
лее позднюю версию продукта.

Управление изменениями требований. Управление изменениями
является одной из ключевых тем управления требованиями. Опре-
деление процедур для обработки изменений требований отличается
от их детальной формализации. Необходимы специальные про-
цедуры управления изменениями в приложении к требованиям.
В то же время нельзя рассматривать изменение требований в отрыве
от других процессов. Данный вопрос является составной частью
управления изменениями и конфигурациями программного обеспе-
чения (Software Configuration and Change Management — SCCM), ко-
торое сегодня принято называть просто конфигурационным управ-
лением (Software Configuration Management — SCM), подразумевая
при этом, что это не только вопросы контроля версий, но и управ-
ление всеми активами проекта, включая код, требования, запросы
на изменения — change requests (в том числе отчеты об ошибках —
defect или bug reports), задачи (в терминах проектного менеджмента)
и т.п.

Требования к большим программным системам неизбежно изме-
нятся в процессе их разработки. Причины этого многочисленны
и разнообразны. Одной из них является то, что во время создания
ПО понимание разработчиками поставленных перед ними задач бу-
дет неизбежно меняться, что вызывает необходимость возвращения
к требованиям. Кроме того, для больших систем, которые приходят
на смену действующим, должна быть обеспечена преемственность.
Хотя проблемы в работе со старой системой известны, трудно пред-
сказать, какой эффект «улучшенная» система даст для организации.
При этом, даже если конечные пользователи имеют опыт работы
с подобной системой, новые требования неизбежно появятся.

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

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

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

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

Постоянные и изменяемые требования. При формировании требо-
ваний основное внимание обычно сосредоточено на возможностях
создаваемого ПО, бизнес-целях и бизнес-системах организации.
После формирования требований достигается более глубокое пони-
мание потребностей пользователей, вследствие чего может возник-
нуть необходимость в изменении ранее сформулированных требова-
ний. Измененные требования отсылаются заказчику с объяснением
причины сделанных изменений (рис. 4.12).

Время

Рис, 4.12. Эволюция требований

Создание большой системы может занять несколько лет. За это
время окружение и бизнес-требования к системе, несомненно, из-
менятся, что должно найти отражение в измененных требованиях.

С точки зрения процесса разработки требования можно разделить
на два класса.

1.	Постоянные требования — это относительно стабильные тре-
бования, которые исходят из основной деятельности организации
и касаются непосредственно предметной области, где будет эксплуа-
тироваться система.

2.	Изменяемые требования, которые отображают изменения, сде-
ланные во время разработки системы или после ввода ее в эксплуа-
тацию. Изменяемые требования можно разделить на четыре группы,
представленные в табл. 4.4.
Изменяемые требования

Таблица 4.4

Тип требований	Описание
Непостоянные	Изменяются из-за изменений в окружении системы
Неожиданно возникающие	Появляются во время проектирования и раз- работки системы
Непрямые	Являются результатом внедрения системы, способной изменить организационные про- цессы и показать новые способы работы, приводящие к новым системным требова- ниям
Вторичные	Зависят от особенностей данной системы, от бизнес-проблем организации

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

•	идентификация требований — каждое требование должно быть
однозначно определено, так как оно может пересекаться с дру-
гими требованиями, это пересечение можно обнаружить с по-
мощью оперативного контроля;

•	управление процессом внесения изменений — это ряд операций,
которые оценивают воздействие на систему вносимых измене-
ний, а также стоимость изменений;

•	стратегия оперативного контроля — определяет отношения между
требованиями, а также между требованиями и проектированием
системы;

•	использование CASE-средств — управление требованиями пред-
полагает обработку большого объема информации о требова-
ниях, в этом процессе могут использоваться разнообразные ин-
струментальные средства, в том числе и достаточно простые
(например, электронные таблицы или простые системы баз дан-
ных).

Существует много зависимостей между требованиями, а также
между требованиями и структурой системы. Существует связь между
требованиями и причинами, по которым эти требования были пред-
ложены. Поэтому если необходимо внести в требования изменения,
го в процессе управления нужно проследить влияние этих изменений
на другие требования и систему в целом.

Оперативный контроль позволяет обнаружить связанные требо-
вания и отследить влияние одних требований на другие. Существует
три типа информации, используемой в оперативном контроле.

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

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

3.	Информация о структуре системы связывает требования с си-
стемными модулями, которые реализуют требования. Эта информа-
ция используется для оценки влияния предложенных изменений
на систему и ее реализацию.

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

Таблица 4.5

Матрица зависимое! ей между требованиями

Требования	1.1	1.2	1.3	2.1	2.2	2.3	3.1	3.2
1.1		и	R			и		и
1.2			и			R		
1.3	R			R				и
2.1			R		и			и
2.2								и
2.3		R		и				
3.1								R
3.2							R	

Символ U (от use — использование) на пересечении строки
и столбца показывает, что требование в строке использует средства,
определенные в требовании, представленном в столбце. Символ R
(от relation — связь, зависимость) означает, что существует некоторая
взаимосвязь между требованиями, например оба требования опре-
деляют один и тот же системный модуль. Матрицы оперативного
контроля используются для управления небольшим набором требо-
ваний, они становятся громоздкими и неудобными для больших
систем со многими требованиями, для которых информацию опера-
тивного контроля хранят обычно в базе данных, где каждое требова-
ние связано явным образом с другими требованиями. Влияние из-
менений в требованиях можно проследить, используя средства про-
смотра базы данных.

Автоматизированная поддержка управления требованиями необ-
ходима, для чего можно использовать разнообразные CASE-
средства, с помощью которых можно выполнять следующие опера-
ции:

•	хранение требований — информация о требованиях должна быть
защищена, процесс хранения должен быть управляем, требования
должны быть доступны для каждого участника процесса разра-
ботки требований;

•	управление изменениями требований — процесс управления из-
менениями упрощается, если есть эффективные средства под-
держки;

•	управление оперативным контролем — средства поддержки опе-
ративного контроля позволяют обнаруживать взаимосвязанные
требования.

Для небольших программных систем нет необходимости исполь-
зовать специализированные средства управления требованиями,
здесь для поддержки процесса управления можно обратиться к тек-
стовым процессорам, электронным таблицам и компьютерным базам
данных. Однако для больших систем требуются специализированные
средства поддержки, такие как DOORS и Requisite Pro.

Управление изменениями требований должно применяться ко всем
предложенным изменениям требований (рис. 4.13). Преимущество
использования формального процесса управления изменениями со-
стоит в том, что все предложенные изменения обрабатываются по-
следовательно, при этом можно управлять и отслеживать внесение
изменений в системную спецификацию.

Процесс управления изменениями состоит из трех основных эта-
пов.

1.	Анализ проблем изменения спецификации. Процесс начинается
с определения проблем в требованиях или с прямого предложения
Опреде-

ление

проблем	Пересмот-

Рис. 4.13. Управление изменениями требований
внесения изменений. На этой стадии проблема или предложенные
изменения анализируются для проверки их обоснованности. Затем
могут быть сделаны более определенные предложения относительно
изменений в требованиях.

2.	Анализ изменений и расчет их стоимости. Эффект от внесения
предложенного изменения оценивается с использованием оператив-
ного контроля. Стоимость изменений оценивается двумя показате-
лями: стоимостью внесения изменения в спецификацию и стои-
мостью внесения изменений в структуру системы и непосредственно
в программный код.

3.	Реализация изменений. По окончании предыдущих этапов при-
нимается решение, продолжать или нет внесение изменений в сис-
тему, и осуществляется реализация изменений.

Атрибуты требований. Требования должны состоять не только
из описания того, что необходимо сделать, но и содержать информа-
цию, необходимую для интерпретации требований и управления
ими, — атрибуты требований (Requirements Attributes). Например,
с функциональными требованиями часто ассоциируют сценарии Use
Case (как в текстовом, так и в графическом представлении), и в то же
время функциональные требования часто трансформируются в за-
дачи в терминах проектного управления, с которыми связаны пара-
метры законченности (например, в процентах), ответственности
(например, кто является «владельцем» требования, кто из инженеров
назначается исполнителем и принимает на себя обязанности, свя-
занные с реализацией заданной функциональности). Примеров су-
ществует много, и в зависимости от применяемых практик и мето-
дов, сложившейся проектной и организационной культуры спектр
атрибутов может меняться достаточно широко.

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

Трассировка требований Трассировка является фундаментальной
основой проведения анализа влияния (impact analysis) изменения
требований на конечный продукт, помогая предсказывать эффект
от внесения таких изменений. Трассировка требований отслеживает
связи между требованиями и источниками требований.

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

Одной из главных проблем сбора требований является проблема
их изменения. Требования создаются итерационно, при постоянном
общении представителей заказчиков с аналитиками и разработчи-
ками системы. На момент заключения договора состав требований
и их свойства становятся более полными, т.е. соответствуют взглядам
заказчика на создаваемую систему. Одним из инструментов установ-
ления зависимости между сформулированными требованиями и их
возможными изменениями является трассировка, при этом поддер-
живается развитие и обработка требований с прослеживанием иден-
тифицированных связей, которые должны быть зафиксированы
по двум направлениям — от источника требований к реализации
и наоборот (рис. 4.14).

В направлении	В направлении

от требований	к требованиям

Рис. 4.14. Направления трассируемости требований

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

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

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

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

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

В основе трассировки лежат следующие составляющие:

•	требования, которые изменяются в ходе формирования;

•	некоторые детали выполнения функций в рабочем продукте, ко-
торые не предусматривались, но появились в связи с возникшей
практической ситуацией;

•	связи между различными моделями процесса проектирования
системы в течение ЖЦ программного продукта и принятые реше-
ния о необходимости изменения требований в связи с появивши-
мися недостатками в промежуточном продукте;

•	информация о согласованных атрибутах требований на разных
уровнях рассмотренной схемы трассирования и сохранение ее
в матрице трассирования;

•	специальные системные требования, касающиеся повторного ис-
пользования готовых компонентов или частей системы;

•	результаты тестирования, по которым можно определить наи-
более вероятные части кода, требующие проверки на наличие
в них дефектов.
Процедура трассирования включает в себя следующие этапы.

1.	Выбирается элемент (функция, фрагмент или некоторая часть)
из матрицы трассирования требований, который прослеживается
на всех этапах ЖЦ.

2.	Составляется список вопросов, по которым на каждом этапе
проверяются связи при реализации требований в продукте; и если
изменяется какое-то звено в цепочке требований (см. рис. 4.14),
то может модифицироваться процедура разработки этого элемента
на последующем этапе ЖЦ.

3.	Проводится мониторинг статуса каждого требования на соот-
ветствие выполнения принятому плану.

4.	Осуществляется уточнение ресурсов, которые необходимы для
выполнения проекта при изменениях в требованиях и в элементах
проекта.

Условием принятия решения о возможных модификациях требо-
ваний и результатов промежуточного проектирования является по-
лученная в результате трассирования обновленная информация
о связях между различными частями системы и первоначально за-
данными к ним требованиями.

Таким образом, трассировка обеспечивает ввод более сложных
отношений вместо простых связей или ввод специфических отноше-
ний, отслеживание разных путей трассировки (между моделями или
иерархическими связями), ведение базы данных объектов трасси-
ровки и отношений между ними

Трассировка может быть выборочной для отдельных объектов или
связанной с другими объектами, а также с возможными переходами
от одной модели проектирования к другой путем проверки транс-
формации одних объектов в другие

Измерение требований. С практической точки зрения обычно по-
лезно иметь нечто, позволяющее определить «объем» требований для
создаваемого программного продукта. Такие числовые значения
можно использовать для исследования масштабов изменений в тре-
бованиях, оценки стоимостных характеристик (cost estimation) раз-
работки и поддержки программной системы, а опосредованно — для
оценки продуктивности разработки и эффективности ее поддержки
на этапах реализации требований и внесения изменений и т.п.

В настоящее время широко применяется измерение объема функ-
циональности (Functional Size Measurement — FSM) — техника чис-
ленной оценки, определенная на концептуальном уровне в стандарте
IEEE14143.1. Стандарты ISO/IEC и другие источники описывают
частные методы FSM; например, модель COCOMO II для оценки
стоимости программного проекта может использоваться в тесной
связи с методами функциональных точек (functional points) для
оценки масштабов функциональности, т.е. требований, предъявля-
емых заданной программной системе.

В дополнение к практическим соображениям, представленным
в SWEBOK, на фоне обшей тенденции разработки моделей оценки
зрелости компании-разработчика стоит отметить, что существуют
определенные работы и по созданию различных моделей зрелости
требований. Такие работы, в частности, связаны с известной про-
мышленной методологией RUP (Rational Unified Process — методо-
логия разработки программного обеспечения фирмы «IBM»). Наи-
более популярная модель зрелости в индустрии программного обес-
печения — модель CMMI также содержит некоторые работы
по определению и управлению требованиями, а также по определе-
нию их уровня зрелости.

Контрольные вопросы

1.	Почему необходимо определение требований к разрабатываемым ПП7
Приведите схему структурирования уровней требований.

2.	Каковы основные разделы разработки требований в соответствии
с ядром знаний SWEBOK? Дайте классификацию требований.

3.	Каково назначение функциональных и нефункциональных требова-
ний?

4.	Какие нефункциональные требования вы знаете? Перечислите коли-
чественные показатели нефункциональных требований.

5.	Какие способы записи спецификаций требований вам известны?

6.	Охарактеризуйте процесс разработки требований.

7.	Что такое анализ осуществимости требований?

8.	Каким образом осуществляется извлечение требований?

9.	Охарактеризуйте процесс формирования и анализа требований.

10.	Определите этапы разработки спецификаций требований.

11.	Что такое аттестация требований?

12.	Что понимается под итеративной природой работы с требованиями?

13.	Охарактеризуйте процесс управления изменениями требований.

14	Приведите классификацию изменяемых требований.

15.	Что предполагает трассировка требований?

Литература

1.	Вигерс К., Битти Д. Разработка требований к программному обеспече-
нию. — 3-е изд., доп. — М.; Русская редакция; СПб • БХВ-Петербург,
2014.- 736 с.
2.	Коллинз Г., Блей Д. Структурные методы разработки систем: от страте-
гического планирования до тестирования. — М.: Финансы и статис-
тика, 1986. — 264 с.

3.	Лефингвел Д., УидригД. Принципы работы с требования ми к программному
обеспечению. Унифицированный подход. — М.: Вильяме, 2002. — 448 с.

4.	Липаев В. В. Документирование и управление конфигурацией прог-
раммных средств. Методы и стандарты. — М.: СИНТЕГ, 1998. — 212 с.

5.	Мацяшек Л.А Анализ требований и разработка информационных

систем с использованием UML. — М.: Вильямс, 2002. — 432 с.

6.	Alford М. И4 A requirements engineering methodology for real time processing

requirements // IEEE Trans, on Software Engineering. — J 977. — SE-3( 1). —
P. 60-69.

7.	Alford M. W. SREM at the age of eight: the distributed computing design sys-
tem /I IEEE Computer. - 1985. - 18(4). - P. 36-82.

8.	Bell T.E., Bixler D.C. An extendable approach to computer aided software
requirements engineering // IEEE Trans, on Software Engineering. —
1977. - SE-3(1). - P. 49-109.

9.	Bolognesi T., Brinksma E. Introduction to the ISO specification language
LOTOS I I Computer Networks. - 1987. - 14(1). - P. 25 - 84.

10.	Booch G. Obiect-oriented Analysis and Design with Applications. — Redwood
City, CA: Benjamin Cummings, 1994. (Русский перевод 2-го издания:
Буч Г. Объектно-ориентированный анализ и проектирование с приме-
рами приложений на C++. — М.: Бином; СПб.: Невский проспект,
1999. -412 с.)

11.	Futatsugi К., Goguen J.A. Principles of OBJ2. — In: 12th ACM Symp. on
Principles of Programming Languages. — New Orleans, 1985.

12.	Guttag J.V., Horning J J. The Larch family of specification languages // IEEE
Software. - 1985. - 2(5). - P. 24-70.

13.	Guttag J., Horning J. Larch'. Languages and Tools for Formal Specification. —
Heidelberg: Springer-Verlag, 1993

14.	Hoare C.A.R. Communicating Sequential Processes. — London: Prentice-
Hall, 1985.

15.	Jones C.B. Software Development: A Rigorous Approach. — London: Pren-
tice-Hall, 1980.

16.	Peterson J.L. Petri Net Theory and the Modeling of Systems. — New York:
McGraw-Hill, 1981. (Русский перевод: Питерсон Д. Теория сетей Петри
и моделирование систем. — М.: Мир, 1984. — 264 с.)

17.	Rumbaugh J.. Blaha М. Object-oriented Modeling and Design. — Englewood
Cliffs, NJ: Prentice-Hall, 1991.

18.	Seven myths of formal methods // IEEE Software — 1990. — 7 (5). — P. 11—31.

19.	SpiveyJ.M. The Z Notation: A Reference Manual, 2nd edn. — London: Pren-
tice-Hall, 1992.

20.	Warren I. The Renaissance of Legacy Systems. — London: Springer, 1998.

21.	Wirfs-Brock R.J., Johnson R.E. Surveying current research in object-oriented
design // Comm. ACM. - 1990. - 33(9). - P. 104-128.
Глава 5

ПРОЕКТИРОВАНИЕ

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

5.1.	Основы проектирования

Проектирование программной системы. Этот процесс можно опре-
делить как процесс создания проекта программной системы (ПС) —
набора схем, диаграмм, технических заданий и другой документации,
содержащих описание разрабатываемого ПП в объеме, достаточном
для его конструирования. Проект необходим для того, чтобы все его
участники понимали цель разработки, какой продукт и с какими ха-
рактеристиками будет создан в результате их деятельности.

Целью проектирования является определение внутренних свойств
системы и детализации ее внешних (видимых) свойств на основе вы-
данных заказчиком требований к ПС (исходных условий задачи).
Процесс проектирования — инженерная деятельность в рамках ЖЦ
ПП, в рамках которой анализируются требования и создается опи-
сание внутренней структуры ПС, которое является основой для его
дальнейшего конструирования.

В зависимости от сложности создаваемого ПП процесс проекти-
рования может обеспечиваться как «ручным» проектированием, так
и различными средствами его автоматизации. В процессе проекти-
рования ПС также могут использоваться различные графические
средства: блок-схемы, ER-диаграммы, UML-диаграммы, а также
макеты.

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

ER-диаграммы используются при высокоуровневом проектирова-
нии БД.

UML-диаграммы (UML, Unified Modeling Language — унифици-
рованный язык моделирования) — графическое описание процесса
моделирования в области разработки П О
Проектированию обычно подлежат архитектура ПО, устройство
компонентов ПО, пользовательские интерфейсы. Первоначально
программа рассматривается как черный ящик. Ход процесса проек-
тирования и его результаты зависят не только от состава требований,
но и от выбранной модели процесса, опыта проектировщика. Про-
ектирование является сложным и, как правило, трудоемким процес-
сом, требующим большого опыта и знаний, которые позволяют на-
ходить компромиссные решения при разработке требуемого прог-
раммного обеспечения.

Роли участников процесса проектирования. При проектировании
должны быть задействованы определенные люди, которые примут
участие в анализе и разработке программного проекта. Участникам
проекта принято назначать роли — функции, которые они будут вы-
полнять в проекте. В зависимости от квалификации и величины про-
ектной команды один человек может совмещать различные роли
(например, если программу пишет один разработчик, то он может
совместить их все). Для осуществления процесса проектирования
выделяют следующие основные роли:
• заказчик;

•	руководитель проекта;

•	системный администратор;

•	администратор базы данных;

•	системный архитектор;

•	архитектор базы данных;

•	бизнес-аналитик;

•	аналитик (системный аналитик);

•	тестировщик.

Заказчикам является лицо, которому нужно разрабатываемое ПО.
В качестве заказчика может выступать один человек, группа людей
либо какое-либо предприятие, юридическое лицо. Заказчик опреде-
ляет требования к разрабатываемому программному продукту, кото-
рые влияют на то, каким будет конечный результат разработки.

Руководитель проекта управляет процессом разработки ПП. Он
отвечает за выполнение всех задач в срок перед заказчиком, обеспе-
чивает взаимодействие всех участников программного проекта, кон-
тролирует процесс выполнения.

Системный администратор создает условия для непрерывной ра-
боты над разрабатываемым программным продуктом, следит за ра-
ботоспособностью серверов, выявляет и устраняет неполадки. При
проектировании он выступает в качестве консультанта по требова-
ниям к аппаратному обеспечению (серверам, рабочим компьютерам.
мощности процессоров, необходимых для работы, объему оператив-
ной памяти и т.д.), необходимому для нормального функциониро-
вания программного продукта.

Администратор базы данных обеспечивает непрерывность работы
сервера базы данных, контролирует его работу. При проектировании
выступает в качестве консультанта по требованию к серверу базы
данных, а также к системе управления базой данных, необходимой
для программного продукта.

Системный архитектор проектирует архитектуру всего программ-
ного продукта в целом и более детально производит проектирование
самого приложения, не вдаваясь в подробности проектирования
базы данных

Архитектор базы данных проектирует укрупненную структуру
базы данных. Более детальная проработка архитектуры базы данных
производится на этапе конструирования ПО.

Бизнес-аналитик описывает требуемое поведение системы с точки
зрения конечных пользователей. Например, с точки зрения пользо-
вателя, покупка выбранного товара будет заключаться в щелчке ле-
вой кнопкой мыши по кнопке «Купить» и заполнении данных бан-
ковской карты. С точки зрения разработчика, данное действие будет
заключаться в получении события щелчка левой кнопкой мыши
по кнопке «btnBuy», вызове формы «frmBuy» и проверке заполнен-
ных полей.

Аналитик (системный аналитик) пишет технические задания для
разработчиков. В зависимости от проекта технические задания могут
быть различной степени детализации — от подробных, по которым
разработчикам остается только закодировать написанное ТЗ на вы-
бранном языке программирования, до общих, которые требуют до-
полнительного проектирования (проработки структуры таблиц,
классов, методов и пр.).

Тестировщик производит тестирование ПП. При проектировании
его необходимо ознакомить с подготовленной документацией
по программному продукту для подготовки к процессу тестирования.
В настоящее время существуют определенные технологии разра-
ботки программных проектов, которые основываются на тестах. При
проектировании пишутся тесты для разрабатываемого функционала,
а при разработке систему конструируют в соответствии с написан-
ными тестами.

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

5.2.	Ключевые вопросы проектирования

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

Параллелизм. Параллельные вычисления — способ организации
компьютерных вычислений, при котором программы разрабатыва-
ются как набор взаимодействующих вычислительных процессов,
работающих параллельно (воспринимаемых пользователем как од-
новременные).

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

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

1)	формирование и выдача страниц по запросам пользователей
(обеспечивается на уровне архитектуры Web-сервера);

2)	выдача запросов базой данных (обеспечивается на уровне ар-
хитектуры базы данных).

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

Основным принципом для взаимодействия данных процессов
является асинхронный обмен сообщениями. В случае с графическим
интерфейсом данный подход является наиболее предпочтительным,
так как работа графического интерфейса основана на сообщениях.

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

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

Обеспечение отказоустойчивости. Одной из задач проектирования
является обеспечение корректной обработки ошибок. В частности,
при проектировании необходимо описать, как обеспечить коррект-
ную работу системы, даже если произошел сбой.

Существует два наиболее распространенных метода контроля
ошибок.

1.	Исключения — метод, позволяющий разработчикам получить
наиболее подробную информацию по ошибкам и достаточно легко
их локализовать, классифицировать и обрабатывать централизо-
ванно. Недостатком этого способа является невысокая скорость об-
работки ошибок, поскольку, чтобы собрать необходимые для исклю-
чения данные, необходимо проделать значительный объем вычис-
лений. Поэтому данный метод не рекомендуется использовать при
обработке больших потоков информации, когда выдвигаются требо-
вания к скорости.

2.	Коды ошибок — метод, широко использующийся при обработке
большого потока данных, когда приоритетом ставится скорость об-
работки информации. При появлении ошибки функции возвращают
лишь ее код, «надеясь» на то, что в вызывающих процедурах есть
логика по их обработке. Это менее надежный, но более производи-
тельный метод.

Не все языки программирования поддерживают обе возможности
работы с ошибками. Например, часть языков баз данных имеют воз-
можность работы только с кодами ошибок.

5.3.	Архитектура программного
обеспечения

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

Для разработки архитектуры системы привлекаются специалисты
со следующими ролями: системный архитектор (проектирует сис-
тему в целом, а также отдельные ее компоненты), архитектор базы
данных (занимается проектированием БД и ее структуры), системный
аналитик (участвует в проектировании, подготавливает документа-
цию), администраторы (участвуют в проектировании аппаратной
части системы).

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

Улучшение и повышение продуктивности процессов Типичными
ожиданиями заказчика от внедрения приложения являются: умень-
шение времени, затрачиваемого на выполнение различных действий;
ускорение выполнения различных операций; автоматизация процес-
сов; различные улучшения, получаемые за счет масштабируемости —
способности системы, сети или процесса справляться с увеличением
рабочей нагрузки (увеличивать свою производительность) при до-
бавлении ресурсов, обычно аппаратных.

Уменьшение затрат. Одной из целей разработки может стать
уменьшение затрат, необходимых при совершении каких-либо дей-
ствий. Это может осуществляться как за счет повышения продук-
тивности процессов, так и за счет ускорения выполнения опера-
ций.

Улучшение операционной деятельности. Операционная деятель-
ность обычно связана с выполнением рутинных типовых операций
(например, работа кассира в магазине, прием коммунальных плате-
жей и т.д.). Автоматизируя (упрощая, ускоряя) такую операционную
деятельность, можно снижать затраты либо увеличивать производи-
тельность системы.

Повышение эффективности управления. Архитектурное решение
может иметь целью повышение эффективности управления, напри-
мер, за счет автоматизации документооборота на предприятии (пе-
реход от бумажных документов к электронным с отслеживанием
истории изменения, уведомлениями и пр.).

Уменьшение рисков. Любая деятельность связана с определенными
рисками. Одной из целей разработки приложения может быть их
снижение. Например, правило двойной подписи для финансовых
операций (когда финансовую операцию, созданную одним сотруд-
ником, обязательно должен проверить другой сотрудник и поставить
свою подпись).

Повышение эффективности ГГ-подразделений. Этот результат до-
стигается за счет автоматизации различных процессов.

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

Уменьшение стоимости «поддержки» жизненного цикла. Процессы,
связанные с ЖЦ ПП, также могут быть целью автоматизации, так
как снижение затрат, осуществляемых в процессе ЖЦ ПП, приведет
к дополнительной прибыли.

Улучшение характеристик безопасности. Безопасность приложе-
ний с каждым годом становится все более актуальной. Более «без-
опасные» приложения обладают большей конкурентоспособностью
по сравнению с аналогами.

Повышение управляемости. Под управляемостью понимается
влияние на различные процессы, происходящие в приложении без
вмешательства разработчика.

Пример 5.1. Рассмотрим цели, которые должны быть учтены при
создании архитектуры ПО для интернет-магазина по продаже сото-
вых телефонов.

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

•	уменьшение затрат (на обслуживание интернет-магазина необхо-
димо меньше сотрудников, нет необходимости арендовать поме-
щение);

•	улучшение операционной деятельности (рабочее время сотруд-
ников не будет тратиться на объяснение покупателям досто-
инств той или иной модели, объяснения, как настроить телефон,
и пр.);

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

•	уменьшение рисков (например, исключается возможность кражи
товара покупателями);

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

•	улучшение характеристик безопасности (использование защи-
щенных протоколов обмена данными позволит снизить риск
кражи информации и взлома системы злоумышленниками).

Создание архитектуры программного обеспечения. В процессе про-
ектирования и формализации требований и ограничений, которые
должна реализовать создаваемая архитектура, используют следу-
ющие исходные данные для проектирования: варианты использова-
ния и сценарии поведения пользователя; функциональные и не-
функциональные требования (включая параметры качества, такие
как производительность, безопасность, надежность и др.); техноло-
гические требования; целевая среда развертывания и другие ограни-
чения.

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

Общей техникой постепенной доработки архитектуры является
итеративная методика (пока не будут удовлетворены все требования
и ограничения), включающая пять основных этапов (рис. 5.1).

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

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

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

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

Рис. 5.1. Процесс создания архитектуры ПО

5.	Определение вариантов решений. В каждой итерации должен
быть создан «пилот» или прототип архитектуры, являющийся разви-
тием и доработкой предыдущего решения. Прежде чем переходить
к следующей итерации, необходимо убедиться в соответствии этого
прототипа основным сценариям, проблемам и ограничениям раз-
вертывания.

Такой процесс создания архитектуры предполагает итеративный
и инкрементный подходы, в соответствии с которыми сначала созда-
ется возможный вариант архитектуры ПО — обобщенный дизайн,
который может тестироваться по основным сценариям, требова-
ниям, известным ограничениям и параметрам качества. В ходе дора-
ботки очередного варианта архитектуры выявляются дополнитель-
ные детали и сведения о дизайне, результатом чего становится рас-
ширение основных сценариев, корректировка обшего представления
приложения и подхода к решению проблем.

Определение целей архитектуры. Цели архитектуры — это задачи
и ограничения, очерчивающие архитектуру и процесс проектирования
ПС, определяющие объем работ и помогающие понять, когда, соб-
ственно, пора завершить процесс доработки (см. рис. 5.1). К ключевым
моментам при определении целей архитектуры относятся следующие.
Начальное определение задач архитектуры. От этих задач будет зави-
сеть время, затрачиваемое на каждую фазу проектирования архитек-
туры. Необходимо решить, что вы делаете: создаете прототип, прово-
дите тестирование возможных вариантов реализации или выполняете
длительный процесс разработки архитектуры для нового приложения.

Определение потребителей архитектуры. Будет ли разрабатыва-
емая архитектура использоваться другими архитекторами, либо она
предназначается для разработчиков и тестировщиков, IT-
специалистов и руководителей. Следует учесть нужды и подготов-
ленность целевой аудитории, чтобы сделать разрабатываемую струк-
туру максимально удобной для них.

Определение ограничений. Изучите все опции и ограничения при-
меняемой технологии, ограничения использования и развертывания.
Полностью разберитесь со всеми ограничениями в начале работы,
чтобы не тратить время или не сталкиваться с сюрпризами в про-
цессе разработки приложения.

Пример 5.2. Рассмотрим процесс определения целей архитектуры
при разработке интернет-магазина по продаже сотовых телефонов:
• задачей архитектуры будет являться разработка архитектуры но-
вого приложения по продаже сотовых телефонов через Интернет;

•	потребителями будут разработчики, тестировщики и другие IT-
специалисты; архитектура будет представлена заказчику на одо-
брение, но ему может быть достаточно общей сметы затрат, чтобы
утвердить или предложить переработать архитектуру, если пред-
лагаемое решение получится слишком дорогим для него;

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

Выявление основных (ключевых) сценариев. Ключевые сценарии —
это описание способа взаимодействия между разрабатываемой сис-
темой и одним или более действующим лицом (либо ее пользовате-
лями, либо другими системами). Главной целью при продумывании
архитектуры системы должно быть выявление нескольких возмож-
ных ключевых сценариев, что поможет в принятии решений по ар-
хитектуре, причем основная задача состоит в нахождении баланса
между требованиями, предъявляемыми заказчиком.

Чтобы более точно понять, как должна работать система, исполь-
зуется описание функциональности системы через варианты исполь-
зования {прецеденты) — описание действий, которые может осуще-
ствлять система в ответ на внешние воздействия пользователей или
других программных систем. Варианты использования отражают
функциональность системы с точки зрения получения значимого
результата для пользователя.

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

Любой
пользователь сети

Зарегистрированный
пользователь

Только менеджер
может изменять
статус заказа

Интернет-магазин
по продаже сотовых телефонов

Рис. 5.2. Диаграмма вариантов использования для интернет-магазина
по продаже сотовых телефонов
«include»). Диаграмма используется при проектировании архитек-
туры приложения.

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

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

Консольные приложения. Консоль подразумевает отображение
только текстовых данных. Одним из представителей подобного при-
ложения можно назвать файловый менеджер FAR, который является
«наследником» аналогичных программ, используемых в операцион-
ной системе DOS.

Классические desktop-приложения. Такие приложения также назы-
вают «оконными». В них используется графический интерфейс
и ввод информации осуществляется при помощи клавиатуры
и мыши. Данные приложения позволяют создавать практически лю-
бые по сложности решения Основным минусом является сложность
обновления приложений у конечных пользователей.

Web-приложения. Данный класс приложений появился с разви-
тием интернет-технологий, их очень удобно использовать в часто
изменяемых системах с большим числом пользователей. Для обнов-
ления ПО достаточно сделать изменения на сервере, и они сразу по-
явятся в браузерах конечных пользователей.

Мобильные приложения. После того как мобильные телефоны
стали поддерживать язык Java, начался этап создания приложений
для мобильных телефонов В настоящее время существуют различ-
ные платформы для их разработки. Особенностью приложений для
мобильных телефонов является небольшое разрешение экрана, где
необходимо отображать информацию. Также для мобильных теле-
фонов существует только одно устройство ввода — клавиатура. Для
смартфонов можно дополнительно осуществлять ввод информации
при помощи «стилуса».
Игровые приложения Большинство игровых приложений отличает
полноэкранный режим, поэтому для них приходится разрабатывать
собственную систему меню и пр.

Пример 5.4. Для создания интернет-магазина по продаже сотовых
телефонов должно использоваться Web-приложение; и это решение,
как правило, является требованием заказчика к разрабатываемому
программному продукту

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

Ограничения по аппаратным требованиям. Например, необходимо
использовать процессоры, поддерживающие определенные техно-
логии.

Ограничения по программным требованиям. Например, использо-
вание конкретной операционной системы.

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

Повышенные требования безопасности. Данные требования могут
ограничить возможные места расположения серверов, либо потре-
буется использование дополнительных аппаратных (программных)
средств для обеспечения требуемого уровня надежности системы.

Пример 5.5. Для рассмотренного ранее интернет-магазина следует
ввести следующие ограничения развертывания, заданные заказчи-
ком: Web-сервер должен находиться на одном физическом сервере
с базой данных, где будет храниться информация по заказам; необ-
ходимо использовать сервер на базе операционной системы Linux
или Unix.
5.4. Архитектурные стили проектирования

Архитектурный стиль (парадигма) может рассматриваться как об-
общенный шаблон для проектирования архитектуры ПО, опира-
ющийся на некий набор принципов и обеспечивающий абстрактную
базу для определенного семейства систем. Каждый стиль определяет
набор правил, которые задают типы компонентов, используемых для
компоновки системы, и типы отношений, применяемых при компо-
новке, а также ограничения по способам компоновки и допущения
о ее семантике.

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

Сочетание архитектурных стилей крайне полезно при построении
Web-приложений, где можно достичь эффективного разделения
функциональности за счет применения многослойного архитектур-
ного стиля. Таким образом, можно отделить логику представления
от бизнес-логики и логики доступа к данным Требования безопас-
ности организации Moiyr обусловливать либо 3-уровнсвос разверты-
вание приложения, либо развертывание более чем с тремя уровнями.
Уровень представления может развертываться в пограничной сети,
располагающейся между внутренней сетью организации и внешней
сетью. В качестве модели взаимодействия на уровне представления
может применяться шаблон представления с отделением (разновид-
ность многослойного стиля), такой как Modcl-View-Cor.trollcr
(MVC). Также можно выбрать архитектурный стиль SOA и реализо-
вать связь между Wcb-сервером и сервером приложений посредством
обмена сообщениями.

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

Клиент-серверная архитектура. Вычислительная (сетевая) клиент-
серверная архитектура предполагает, что задания или сетевая нагрузка
распределены между поставщиками услуг (сервисов) — серверами
и заказчиками услуг — клиентами (рис. 5.3). Нередко клиенты и сер-
веры взаимодействуют через компьютерную сеть и могут быть как
различными физическими устройствами, так и различным ПО.
Таблица 5.1

Типовые архитектурные стили

Архитектурный стиль (парадигма)	Описание
Клиент-серверная архитектура	Система разделяется на клиентскую и сер- верную части, где клиент посылает за- просы к серверу. Во многих случаях в роли сервера выступает сервер БД, а логика приложения представлена процедурами хранения
Компонентная архитектура	Дизайн приложения разлагается на функ- циональные (логические) компоненты, предоставляющие тщательно проработан- ные интерфейсы связи, с возможностью их повторного использования
П роблемно-ориентированное проектирование (дизайн на основе предметной об- ласти)	Объектно-ориентированный стиль, ори- ентированный на моделирование сферы деловой активности и определяющий биз- нес-объекты на основании сущностей данной предметной области
Многослойная архитектура	Функциональные области приложения разделяются на многослойные группы (уровни)
Архитектура на основе канала сообщений	Стиль, предписывающий использование ПС, которая может принимать и отправ- лять сообщения по одному или более ка- налу связи. Приложения получают воз- можность взаимодействия, не располагая конкретными сведениями друг о друге
JV-уровневая/З-уровневая архитектура	Функциональность выделяется в от- дельные сегменты во многом аналогично многослойному стилю, но сегменты физи- чески располагаются на разных компьюте- рах (уровнях)
Объектно - ориентированная архитектура	Парадигма проектирования, основанная на распределении ответственности прило- жения (системы) между отдельными, мно- гократно используемыми и самостоятель- ными объектами, содержащими данные и правила поведения
Сервисно-ориентированная архитектура (SOA)	Описывает приложения, предоставля- ющие и потребляющие функциональность в виде сервисов с помощью контрактов и сообщений
Рис. 5.3. Архитектурный стиль «Клиент—сервер»

Типичным упрощенным примером реализации архитектуры
«Клиент—сервер» можно назвать различные Web-сайты, которые
содержат страницы с данными, а также логику их отображения. Кли-
енты передают на сайты запросы на предоставление информации,
а в ответ получают содержимое запрошенных страниц.

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

Все данные хранятся на сервере, который, как правило, защищен
гораздо лучше большинства клиентов. На сервере проще обеспечить
контроль полномочий и разрешать дос гул к данным только клиентам
с соответствующими правами доступа. Можно объединить различ-
ных клиентов Ресурсы одного сервера могут использовать клиенты
с разными аппаратными платформами, ОС и т.п

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

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

Компонент

Компонент

Компонент

Рис. 5.4. Пример использования компонентов в интерфейсе пользователя

Данный архитектурный стиль обладает следующими преимуще-
ствами'.

•	простотой развертывания — существующие версии компонентов
могут заменяться новыми совместимыми версиями, не оказывая
влияния на другие компоненты или систему в целом,

•	небольшой стоимостью — использование компонентов сторонних
производителей позволяет уменьшить затраты на разработку и об-
служивание;

•	простотой разработки — для обеспечения заданной функцио-
нальности компоненты реализуют широко известные интер-
фейсы, что позволяет вести разработку различных частей системы
без влияния их друг на друга;

•	возможностью повторного использования компонентов и, как след-
ствие, возможностью распределения затрат на разработку и обслу-
живание между несколькими приложениями или системами;
•	возможностью упрощения технической реализации системы — до-
стигается через использование контейнера компонентов и его
сервисов; в качестве примера сервисов, предоставляемых контей-
нером, можно привести активацию компонентов, управление
ЖЦ, организацию очереди вызовов методов, обработку событий
и транзакции.

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

Проблемно-ориентированное проектирование — подход к проекти-
рованию ПО, основанный на предметной области, ее элементах, их
поведении и отношениях между ними. Целью является создание
программных систем, реализующих модель предметной области, вы-
раженной на языке специалистов в этой области. Модель предмет-
ной области может рассматриваться как каркас, на основе которого
будут реализовываться программные решения.

Для применения данного стиля необходимо детальное понимание
моделируемой предметной области. При создании модели предмет-
ной области группа разработки обычно сотрудничает со специалис-
тами в данной области. Архитекторы, разработчики и предметные
специалисты обладают разной подготовкой и во многих ситуациях
используют разные языки для описания своих целей, пожеланий
и требований. В рамках проблемно-ориентированного подхода вся
группа договаривается использовать один общий язык, ориентиро-
ванный на предметную область, исключающий технические термины
и понятный любому участнику проекта

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

Преимущества данного архитектурного стиля состоят в следу-
ющем:

•	свободный обмен информацией — все участники разработки могут
свободно обмениваться информацией, используя модель пред-
метной области и описываемые ею сущности, с помощью общего
языка, не прибегая к технической терминологии;
Рис. 5.5. Модель предметной области «Финансовые документы»

•	расширяемость системы — модель предметной области обычно
является модульной и гибкой, что упрощает обновление и расши-
рение системы при изменении внешних условий и требований;

•	объекты модели предметной области характеризуются слабой свя-
занностью, что облегчает их тестирование.

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

Многослойная архитектура. Данная архитектура обеспечивает
группировку связной функциональности приложения в разных
слоях, выстраиваемых вертикально, «поверх» друг друга. Функцио-
нальность каждого слоя объединена общей ролью или ответственно-
стью. Слои слабо связаны, и между ними осуществляется явный
обмен данными. Правильное разделение приложения на слои помо-
гает поддерживать строгое разделение функциональности, что,
в свою очередь, обеспечивает гибкость, а также удобство и простоту
обслуживания.

При строгом разделении на слои компоненты одного слоя могут
взаимодействовать только с компонентами этого же слоя или ком-
понентами слоя, расположенного «ниже». Более свободное разделе-
ние на слои позволяет компонентам взаимодействовать с компонен-
тами того же слоя и всех «нижележащих» слоев.

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

На рис. 5.6 представлен пример трехслойной архитектуры прило-
жения, где в качестве слоя данных (хранения информации) может
выступать БД, модуль по хранению и чтению данных с диска. Этот
слой может располагаться и на отдельном сервере (выделенный
файл-сервер, сервер БД), и совместно с другим слоем (например,
простое Web-приложение, где сервер и БД располагаются на одном
компьютере). Для Web-приложений под слой логики (обработки ин-
формации) можно выделить Web-сервер либо, для более сложных
проектов, сервер приложений, а в качестве слоя представления
(отображения информации) выступает браузер, где пользователь
просматривает информацию.

Рис. 5.6. Пример трехслойной архитектуры

К преимуществам данного архитектурного стиля можно отнести
следующие его характеристики:

•	абстракцию — обеспечивается возможность внесения изменений
на абстрактном уровне; используемый уровень абстракции каж-
дого слоя может быть повышен или понижен;

•	изоляцию — обновления технологий могуч быть изолированы в от -
дельных слоях, что поможет сократить риск и минимизировать
воздействие на всю систему;
•	управляемость — разделение основных функций помогает иден-
тифицировать зависимости и структурировать код программы
в секции, что повышает управляемость ПП;

•	производительность — распределение слоев по нескольким физи-
ческим уровням может улучшить масштабируемость, отказоустой-
чивость и производительность;

•	возможность повторного использования — роли повышают воз-
можность повторного использования;

•	тестируемость — улучшение тестируемости является результатом
наличия строго определенных интерфейсов слоев, а также воз-
можности переключения между разными их реализациями.

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

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

На рис. 5.7 приведен пример работы с шиной данных, где часть
клиентов работает через Web-сервер с корпоративными сервисами
(каждый из которых установлен на отдельный сервер): получение
данных из базы данных, работа с почтой, работа с файлами. Доступ
к сервисам напрямую имеют клиенты, которые, например, подклю-
чены к корпоративной сети компании. Весь обмен информации про-
изводится через шину данных. Программы отсылают в ней запросы,
шина данных определяет получателя (сервер/сервис), к которому
адресован запрос, и направляет его к нему, а затем возвращает резуль-
тат отправителю. Следует отметить, что в настоящее время существует
Рис. 5.7. Архитектурный стиль с использованием шины данных

довольно большое количество коммерческих реализаций данной ар-
хитектуры, что упрощает разработку приложений на ее основе.

Основные преимущества данного архитектурного стиля:

•	расширяемость — возможность добавлять или удалять приложе-
ния с шины без влияния на существующие приложения;

•	невысокая сложность — приложения упрощаются, потому что
каждому из них необходимо знать лишь, как обмениваться дан-
ными с шиной;

•	гибкость — приведение набора приложений, составляющих слож-
ный процесс, или схем связи между ними в соответствие изменя-
ющимся бизнес-требованиям или требованиям пользователя
возможно просто путем внесения изменений в конфигурацию или
параметры, управляющие маршрутизацией;

•	слабое связывание — кроме предоставляемого приложением ин-
терфейса для связи с шиной, нет никаких других зависимостей
с самим приложением, что обеспечивает возможность изменения,
обновления и замены его другим приложением, предоставля-
ющим такой же интерфейс;

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

А-уровневая/З-уровневая архитектура. При использовании этой
архитектуры предполагается разделение функциональности на сег-
менты, во многом аналогично многослойной архитектуре, но в дан-
ном случае эти сегменты (их называют уровнями) могут физически
размешаться на разных компьютерах Данный архитектурный стиль
был создан на базе компонентно-ориентированного подхода, где для
связи используют методы определенной платформы (DCOM,
CORBA и др.), а не сообщения.

Характеристиками А-уровневой архитектуры являются функцио-
нальная декомпозиция приложения, сервисные компоненты и их
распределенное развертывание, что обеспечивает высокую масшта-
бируемость, доступность, управляемость и эффективность исполь-
зования ресурсов. Каждый уровень абсолютно независим от всех
остальных, кроме тех, с которыми он непосредственно соседствует:
w-му уровню требуется лишь знать, как обрабатывать запрос
от (п + 1)-го уровня, как передавать этот запрос на (и - 1)-й уровень
(если таковой имеется) и как обрабатывать результаты запроса. Связь
между уровнями, как правило, асинхронная для обеспечения более
высокой масштабируемости.

А-уровневая архитектура обычно имеет не менее трех отдельных
логических уровней, которые физически размещаются на разных сер-
верах. Каждый уровень отвечает за определенную функциональность.
При использовании многослойного подхода слой развертывается
на уровне, если предоставляемая этим слоем функциональность ис-
пользуется более чем одним сервисом или приложением уровня. При-
мером трехуровневого архитектурного стиля может служить типовое
финансовое Web-приложение с высокими требованиями к безопас-
ности. Бизнес-слой в этом случае должен быть развернут за межсете-
вым экраном, из-за чего приходится развертывать слой представле-
ния на отдельном сервере в пограничной сети (рис. 5.8).

Данный архитектурный стиль обладает рядом преимуществ'.

•	удобство поддержки — уровни не зависят друг от друга, что позво-
ляет выполнять их обновление или изменение без влияния

на приложение в целом;

•	масштабируемость — уровни организовываются на основании
развертывания слоев, поэтому масштабировать приложение до-
вольно просто;
Рис. 5.8- Пример трехуровневой архитектуры

•	гибкость — управление и масштабирование каждого уровня мо-
гут выполняться независимо, что обеспечивает высокую гиб-
кость;

•	доступность — приложения могут использовать модульную струк-
туру, что позволяет легко масштабировать компоненты и повы-
шает их доступность.

Объектно-ориентированная архитектура — это парадигма проек-
тирования, основанная на разделении ответственностей приложения
или системы на самостоятельные пригодные для повторного исполь-
зования объекты, каждый из которых содержит данные и поведение
(методы), относящиеся к этому объекту. При объектно-ориентиро-
ванном проектировании система рассматривается не как набор под-
программ и процедурных команд, а как наборы взаимодействующих
объектов. Объекты обособлены, независимы и слабо связаны. Обмен
данными между ними происходит через интерфейсы путем вызова
методов (свойств) других объектов и отправки (приема) сообщений.

Основными принципами объектно-ориентированного архитек-
турного стиля являются: абстракция, композиция, наследование,
инкапсуляция, полиморфизм, отделение.

Абстракция. Преобразование сложной операции в некое обоб-
щение (класс), сохраняющее основные ее характеристики. Напри-
мер, абстрактный интерфейс может быть широко известным описа-
нием, поддерживающим операции доступа к данным через исполь-
зование простых методов, таких, например, как Get (получить)
и Update (обновить). Другая форма абстракции — метаданные, ис-
пользуемые для обеспечения сопоставления двух форматов структу-
рированных данных.
Композиция. Объекты могут быть образованы другими объектами
и по желанию могут скрывать эти внутренние объекты от других
классов или предоставлять их как простые интерфейсы.

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

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

Полиморфизм. Позволяет для конкретных объектов переопреде-
лять поведение базового типа (поддерживающее основные операции
в приложении) путем реализации в них новых взаимозаменяемых
типов.

Отделение. Объекты могут быть отделены от потребителя путем
определения абстрактного интерфейса, реализуемого объектом и по-
нятного потребителю Это позволяет обеспечивать альтернативные
реализации без влияния на потребителей интерфейса.

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

Обычно объектная модель представляется в виде диаграммы клас-
сов. На рис. 5.9 приведен упрощенный пример такой диаграммы, где
изображены три класса, причем классы «Teacher» и «Student» насле-
дуют свое поведение и данные от класса «Persona».

К преимуществам данного архитектурного стиля относят:

•	понятность — обеспечивается более близкое соответствие прило-
жения реальным объектам, что и делает его более понятным;

•	возможность повторного использования — реализуется через поли-
морфизм и абстракцию;

•	тестируемость — улучшение тестируемости обеспечивается через
инкапсуляцию;
Рис. 5.9. Пример диаграммы классов

•	расширяемость — инкапсуляци я, поли морфизм и абстрак пия гаран-
тируют, что изменения в представлении данных не повлияют на ин-
терфейсы, предоставляемые объектами, что могло бы ограничить
возможности связи и взаимодействия с другими объектами;

•	высокая связность — размещая в объекте только функционально
близкие методы (функции) и используя для разных наборов
функций разные объекты, можно достичь высокого уровня связ-
ности.

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

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

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

Основные принципы данного архитектурного стиля:

•	сервисы автономны — обслуживание, разработка, развертывание
и контроль версий каждого сервиса происходит независимо
от других;
•	сервисы могут быть распределены — сервисы могут размещаться
з любом месте сети, локально или удаленно, если сеть поддержи-
вает необходимые протоколы связи;

•	сервисы слабо связаны — каждый сервис совершенно не зависит
от остальных и может быть заменен или обновлен без влияния
на приложения, его использующие, при условии предоставления
совместимого интерфейса;

•	при обмене данными сервисы совместно используют контракты
и схемы, но не внутренние классы,

•	совместимость основана на политике (политика в данном случае
означает описание характеристик, таких как транспорт, протокол
и безопасность).

Типовые сервисно-ориентированные приложения обеспечи-
вают совместное использование информации, выполнение много-
этапных процессов (системы резервирования и онлайн-магазины),
предоставление организациям специальных отраслевых данных
или сервисов, создание составных приложений, которые объеди-
няют данные из многих источников. В настоящее время практи-
чески все современные языки программирования поддерживают
формат SOAP (Simple Object Access Protocol) сервисов, которые
позволяют различным системам обмениваться информацией вне
зависимости от языка программирования, на котором она была
написана.

На рис. 5.10 изображен пример предоставления некоторой фи-
нансовой системой открытого сервиса для получения информации
о курсах валют. К данному сервису могут обращаться любые прог-
раммные продукты, в которых реализован программный код по по-
лучению этих данных. В рассматриваемом примере информацию
получают: другой Web-сервер (возможно, для отображения курсов
валют на своих страницах); сервер по работе с мобильными устрой-
ствами (возможно, для предоставления курсов на мобильные устрой-
ства по запросу клиентов); программа на персональном компьютере
(ПК); программа на карманном ПК.

Преимущества данного архитектурного стиля:

•	согласование предметных областей — повторное использование
общих сервисов со стандартными интерфейсами расширяет тех-
нологические и бизнес-возможности, а также сокращает стои-
мость;

•	абстракция — сервисы являются автономными, доступ к ним осу-
ществляется по формальному контракту, что обеспечивает слабое
связывание и абстракцию;
Рис. 5,10. Пример обмена информацией
для сервис-ориентированных систем

•	возможность обнаружения — сервисы могут предоставлять опи-
сания, что позволяет другим приложениям и сервисам обнаружи-
вать их и автоматически определять их интерфейс;

•	возможность взаимодействия — поскольку протоколы и форматы
данных основываются на отраслевых стандартах, поставщик и по-
требитель сервиса могут создаваться и развертываться на разных
платформах;

•	рационализация — сервисы обеспечивают определенную функцио-
нальность, устраняя необходимость ее дублирования в приложе-
ниях.

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

5.5.	Графическое представление архитектуры

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

Любая система может рассматриваться с разных точек зрения: по-
веденческой (динамической); структурной (статической); логической
(соответствие функциональным требованиям); физической (распре-
деленность, локальность); реализации (как детали архитектуры пред-
ставляются в коде) и т.п. В результате получаются различные архитек-
турные представления (View). Архитектурное представление может
быть определено как частные аспекты программной архитектуры,
рассматривающие специфические свойства программной системы.
В свою очередь, дизайн системы — комплекс архитектурных представ-
лений, достаточный для реализации системы и удовлетворения предъ-
являемых к ней требований. Для изображения большинства видов
дизайна систем используются UML-диаграммы. Рассмотрим основ-
ные виды (точки зрения) представления архитектуры приложений
и диаграммы, которые можно использовать при их проектировании.

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

Рис. 5.11. Пример функционального вида архитектуры приложения
Физический вид, или вид развертывания, описывает (в произволь-
ном виде) физическую структуру приложения (серверы, физические
устройства, связи между ними). На рис. 5.12 приведен пример физи-
ческого вида архитектуры интернет-магазина по продаже сотовых
телефонов. Web-сервер и сервер БД физически располагаются на од-
ном компьютере. Доступ к страницам осуществляется как по откры-
тому (HTTP), так и по закрытому соединению (HTTPS). При этом
у пользователей магазина и сотрудников компании разный доступ
к магазину (пользователи работают через личный кабинет, а сотруд-
ники — через специальный Web-интерфейс управления магазином).
Прямой доступ к серверу имеют только администраторы системы.

Рис. 5.12. Пример физического вида архитектуры

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

начальное состояние:

конечное состояние'

состояние -действие:

условие:

параллельное выполнение:

Начальное состояние может быть только одним, это начало диа-
граммы. Конечное состояние может быть только одним, на нем закан-
чивается диаграмма. Состояние-действие определяет любое возмож-
ное в данном состоянии действие (внутри данного блока пишется
производимое действие). Условие позволяет изменять ход выполне-
ние диаграммы по различным причинам; причины ветвления пи-
шутся над линиями, исходящими из блока. Допускается параллельное
выполнение процессов: либо в блок входит одна стрелка, а выходит
несколько, каждая из которых означает начало параллельного вы-
полнения процессов, либо в блок входит несколько стрелок, а выхо-
дит одна, что означает окончание параллельного выполнения про-
цессов. Область построения диаграммы может разделяться верти-
кальными линиями; прямоугольник, который они образуют,
выделяется как отдельная подсистема или пользователь, их названия
пишутся в верхней части прямоугольника.

На рис. 5.13 показана диаграмма активности запроса клиентом
списка товаров интернет-магазина. Клиент запрашивает список то-
варов. Если Web-сервер недоступен, то он может либо еще раз запро-
ситв список товаров, либо отказаться от просмотра страницы. Если
Web-сервер доступен, то он параллельно делает запрос данных из БД
и информирует браузер клиента о том, что данные запрошены. Здесь
целесообразно применение «асинхронного агента» для показа того,
что ожидаются данные клиенту. Если время получения запрошенной
информации будет большим, то клиент будет видеть, что его запрос
обрабатывается. После получения данных Web-сервер формирует
HTML-страницу и отправляет ее браузеру клиента. Браузер клиента
отображает полученную страницу.

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

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

5.6.	Анализ качества
и оценка программного дизайна

Параметры качества — это общие свойства архитектуры, которые
оказывают влияние на дизайн системы, ее поведение во время ра-
боты и взаимодействие с пользователем, такие как удобство и про-
стота использования, производительность, надежность и безопас-
ность и др. Обеспечение приложением требуемого сочетания пара-
метров качества определяет успешность его дизайна и общее
качество программного продукта. В ходе проектирования приложе-
ния, отвечающего любому из этих параметров, необходимо учесть
влияние и других требований; кроме того, при этом должны быть
проанализированы плюсы и минусы по отношению к другим пара-
метрам качества.

Атрибуты качества дизайна. Существует целый спектр различных
атрибутов, помогающих оценить разработку и добиться качествен-
ного дизайна. Эти атрибуты могут описывать многие характеристики
системы и элементов дизайна: «тестируемость», «переносимость»,
«модифицируемость», «производительность», «безопасность» и т.п.
Важно понимать, что обсуждаемые атрибуты касаются только ди-
зайна (как результата), но не проектирования (как процесса). Все эти
атрибуты принято объединять в следующие группы'.

•	применимые к run-time, т.е. ко времени выполнения системы; на-
пример, среднее время отклика системы, позволяющее оценить
качество дизайна с точки зрения производительности;

•	ориентированные на design-time, т.е. позволяющие оценивать ка-
чество получаемого дизайна еще на этапе проектирования и, в об-
щем случае, вплоть до тестирования включительно; например,
средняя нагруженность классов бизнес-методами (в каждом
классе бизнес-методов «в среднем» или «много»);

•	атрибуты качества архитектурного дизайна как такового — кон-
цептуальная целостность дизайна, непротиворечивость, полнота,
завершенность; например, любой определенный бизнес-метод
является вызываемым, т.е. создан не потому, что может понадо-
биться в будущем, а определен в соответствии с требованиями или
необходим для реализации дизайна в выбранном архитектурном
стиле.

Существуют атрибуты, которые сложно измерить, например пор-
тируемость (переносимость на другие платформы/операционные
системы и т.д.) или безопасность Измеряемые атрибуты качества
описываются определенными метриками. Метрика позволяет коли-
чественно оценить атрибут качества, например «модифицируемость»
и «сложность» системы

Не надо путать атрибуты качества дизайна с атрибутами качества,
используемыми в ряде требований, предъявляемых к системе. Часть
из них может отображаться друг на друга и нести эквивалентную
смысловую нагрузку, некоторые могут быть связаны, однако большая
часть атрибутов качества дизайна является специфичной именно для
дизайна и не связана с требованиями. Например, если используется
платформа J2EE (Java 2 Enterprise Edition) и компонентная модель
EJB (Enterprise JavaBeans), существуют признаки хорошего дизайна,
специфичные для данной платформы и компонентной модели,
но абсолютно никак не связанные с какими-либо требованиями
к создаваемой на этой платформе программной системе.

Анализ качества и техники оценки. В индустрии разработки ПО
распространены многие инструменты, техники и практики, помога-
ющие добиться качественного дизайна:

•	обзор дизайна {software design review), например неформальный об-
зор архитектуры членами проектной команды;

•	статический анализ (static analysis), например трассировка с тре-
бованиями;

•	симуляция и прототипирование (simulation and prototyping) — дина-
мические техники проверки дизайна в целом или отдельных его
атрибутов качества, например, для оценки производительности
используемых архитектурных решений при симуляции нагрузки,
близкой к прогнозируемым пиковым.
5.7.	Программные средства

При проектировании ПС можно пользоваться различными про-
граммными средствами, которые позволяют рисовать различные
типы диаграмм. Из наиболее востребованных можно выделить сле-
дующие.

Microsoft Visio — платный программный продукт, позволяющий
рисовать любые тины диаграмм, а также схемы интерфейсов поль-
зователя.

Plant UML — бесплатный программный продукт, позволяющий
автоматически рисовать диаграммы по написанным на специальном
языке сценариям.

Balsamiq Mockups — платный программный продукт, позволя-
ющий проектировать Web-интерфейсы

Контрольные вопросы

1.	Для чего необходим проект программной системы? Дайте определение
проектирования ПС.

2.	Каковы основные цели проектирования? Что такое процесс проекти-
рования?

3.	Каковы роли, которые могут участвовать в процессе проектирования?
Назовите их основные задачи.

4.	Дайте определение архитектуры программного обеспечения.

5.	Какие задачи решает разработка архитектуры приложения?

6.	Как определяются исходные данные для проектирования архитектуры
приложения?

7.	Какие задачи и ограничения определяют цели архитектуры приложе-
ния?

8.	Каковы основные типы разрабатываемых приложений?

9.	Перечислите и опишите основные ограничения развертывания.

10.	Дайте краткую характеристику архитектурным стилям проектирования.

11.	Какие из архитектурных стилей можно совмещать в одном архитектур-
ном решении и какие нельзя? Почему?

12.	На какие ключевые вопросы следует обращать внимание при проекти-
ровании? Почему?

13.	Какие методы обеспечения отказоустойчивости используют наиболее
часто? Перечислите достоинства и недостатки каждого из них.

J 4. Как можно графически отобразить архитектуру ПС? Опишите основ-
ные средства отображения архитектуры ПС.

15. Каковы основные атрибуты анализа качества программного дизайна?
Литература

1.	Аллен Э. Типичные ошибки проектирования. — СПб.: Питер, 2003. —
224 с.

2	Ахтырченко К. В., Сорокваша Т.П Методы и технологии реинжиниринга
ИС. CIT Forum. — 2003. [Электронный ресурс] — URL: http://citforum
ru/SE/project/isr/.

3	Бек К. Шаблоны реализации корпоративных приложений. — М.:
Вильямс, 2008. — 176 с.

4.	Гарланд Д., Шоу М. Архитектурный стиль Введение в архитектуру
ПО — 1994 — 529 с. [Электронный ресурс] Системные требования:
Adobe Acrobat Reader. — URL http://download.microsoft.com/documents/
rus/nisdn/ры приложений полная книга.pdf'.

5	Гринфилд Д. и др. Фабрики разработки программ. — М.: Диалектика,
2006. - 592 с.

6	Кратчен Ф , Оббник X., Стаффорд Д. Ретроспектива программных архи-
текгур. Открытые системы, 2006. — С 23 — 29. [Электронный ресурс] —
URL: http://www.osp.ru/os/2006/03/! 156577/.

7.	Майкл Нейгард. Проектирование и дизайн ПО для тех, кому не все
равно. — СПб  Питер, 2016. — 320 с.

8.	Орлик С. Основы программной инженерии (по SWEBOK) // Проекти-
рование. — 2016. [Электронный ресурс] — http://swebok.sorlik.ru/pdf/2-
software_engineerir.g_design.pdf

9.	Соммервилл И. Инженерия программного обеспечения. — М. Вильямс,
2002. - 624 с

10	Фаулер М. Архитектура корпоративных программных приложений. —
М.: Вильямс, 2008 — 544 с.

11	Хоп Г., Вульф Б Шаблоны интеграции корпоративных приложений. —
М.: Вильямс, — 2007. — 672 с.

12.	Carnegie Mellon University. Software Architecture. Software Engineering
Institute [Электронный ресурс] — URL: http://www.sei.cmu.edu/archi-
tecture/start/glossary/.

13.	Len Bass. Paul Clements, Rick Kazman Software Architecture in Practice,
Third Edition. Addison Wesley, 2012, ISBN 978-0321815736.

14.	Len Bass. Paul Clements, Rick Kazman. Software Architecture in Practice (3rd
Edition) (SEI Series in Software Engineering). — 3 edition (October 5,
2012). - 2012. - 640 c. - ISBN 978-0321815736.

15.	RSDN.NET User Group. Проектирование ПО. RSDN [Электронный
ресурс] — http://rsdn.ru/summary/752.xml.

16.	Simon Brown. Software Architecture for Developers Pub Date: 2015. —
https://leanpub.com/software-architecture-for-developers.

17.	Сайт, посвященный сервис-ориентированной архитектуре. — http://
serviceorientation.com/index.php/serviceorientation/index.
Глава 6

КОНСТРУИРОВАНИЕ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6.1.	Основы конструирования

Процесс конструирования — это процесс разработки программного
обеспечения, включающий в себя низкоуровневое проектирование
и кодирование.

Низкоуровневое проектирование — это более детальная проработка
архитектуры ПО: проектирование классов в ООП (объектно-ориен-
тированное программирование), проработка структуры базы данных
в СУБД (система управления базами данных), организация Web-
приложения и компонентов и т.д.

Кодирование — процедура написания программного кода. Это реа-
лизация в виде программы разработанной высокоуровневой и низ-
коуровневой архитектуры проекта.

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

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

Разработка приложений на базе структурного программирования.
Структурное программирование используется в ряде языков прог-
раммирования для определенного класса приложений: драйверы
устройств, операционные системы и пр.

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

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

6.2.	Разработка баз данных

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

Базы данных можно классифицировать следующим образом.

Иерархическая база данных может быть представлена как дерево,
состоящее из объектов различных уровней. Самый верхний уровень
(корень) занимает один объект, далее идут объекты второго уровня
и т.д. Между объектами существуют определенные связи. Каждый
объект может включать в себя несколько объектов более низкого
уровня. Такие объекты находятся в отношении предка (объект, более
близкий к корню) к потомку (объект более низкого уровня); при
этом возможна ситуация, когда объект-предок не имеет потомков
или имеет их несколько, тогда как у объекта-потомка обязательно
должен быть только один предок. Объекты, имеющие общего предка,
называются близнецами.

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

Объектно-ориентированная база данных — база данных, в которой
данные моделируются в виде объектов, их атрибутов, методов и клас-
сов.

Объектно-реляционная база данных — реляционная база данных,
поддерживающая некоторые технологии, реализующие объектно-
ориентированный подход.

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

Основы конструирования реляционных баз данных. Реляционная
база данных основывается на реляционной модели данных, которая
включает в себя следующие аспекты:

•	структурный аспект — данные в БД представляют собой набор
отношений (таблиц);

•	аспект целостности — отношения отвечают определенным усло-
виям целостности (реляционная модель данных поддерживает
декларативные ограничения целостности уровня домена (типа
данных), уровня отношения и уровня БД);

•	аспект обработки {манипулирования) — поддержка операторов
манипулирования отношениями (реляционная алгебра, реляци-
онное исчисление).

Для описания структуры базы данных необходимо ввести ряд
основополагающих понятий.

Тип данных. Понятие «тип данных» в реляционной модели данных
полностью соответствует понятию типа данных в языках программи-
рования.
Домен. Определяется заданием некоторого базового типа данных,
к которому относятся элементы домена, и произвольного логиче-
ского выражения, применяемого к элементам этого типа. Если вы-
числение логического выражения применительно к данному эле-
менту дает результат «истина», то элемент данных является элемен-
том домена. Например, домен «Возраст» определен на базовом типе
«Целые числа», но в его число могут входить только значения, на-
пример, от 0 до 120 (рис. 6 1). Таким образом, домен позволяет со-
здать пользовательский тип данных с возможностью задания необ-
ходимых ограничений допустимых значений.

Типы данных

Рис. 6.1. Базовые понятия реляционных баз данных

Атрибут. Атрибутом называют элемент отношения (свойство),
который входит в уникальный набор состава отношения. Атрибут
состоит из наименования атрибута и домена/типа данных. В таблич-
ном представлении под атрибутами принято понимать столбцы
таблиц — поля в структуре БД.

Структура отношения — это множество пар имя атрибута (уни-
кальное для данного отношения) и имя домена или типа, если кон-
цепция домена не поддерживается. Степень или «арность» отноше-
ния — мощность этого множества (количество атрибутов). Например,
степень отношения «Клиенты» (рис. 6.2) равна трем, т.е оно явля-
ется 3-арным. Если все атрибуты одного отношения определены
на разных доменах, имеет смысл использовать для именования атри-
бутов имена соответствующих доменов (не забывая о том, что это
Рис. 6.2. Концептуальная модель данных для интернет-магазина
является всего лишь удобным способом именования и не устраняет
различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) — это набор именованных от-
ношений и взаимосвязей между ними В табличном представлении
под структурой отношения понимают структуру таблицы базы дан-
ных, а схема базы данных состоит из набора таблиц и отношений
между ними.

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

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

Основные этапы проектирования баз данных. В процессе проекти-
рования БД решается ряд задач: обеспечение хранения в БД всей
необходимой информации; обеспечение возможности получения
данных по всем необходимым запросам; сокращение избыточности
и дублирования данных; обеспечение целостности данных (правиль-
ности их содержания), т.е. исключение противоречий в содержании
данных, исключение их потери и т.д.

Процесс проектирования включает в себя следующие основные
этапы', концептуальное (инфологическое) проектирование, логиче-
ское (даталогическое) проектирование, физическое проектирование.
Рассмотрим их подробнее.

Концептуальное (инфологическое) проектирование — построение
семантической модели предметной области, т.е. информационной
модели наиболее высокого уровня абстракции. Такая модель созда-
ется без ориентации на какую-либо конкретную СУБД и модель дан-
ных. Термины «семантическая модель», «концептуальная модель»
и «инфологическая модель» являются синонимами. Кроме того, в этом
контексте равноправно могут использоваться слова «модель базы дан-
ных» и «модель предметной области», например «концептуальная мо-
дель базы данных» и «концептуальная модель предметной области»,
поскольку такая модель является как образом реальности, так и обра-
зом проектируемой БД для этой реальности.

Чаще всего концептуальная модель БД включает в себя:
•	описание информационных объектов, или понятий предметной
области и связей между ними;

•	описание ограничений целостности, т.е. требований к допусти-
мым значениям данных и к связям между ними.

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

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

Пример 6.1. Построим упрощенную концептуальную модель для
хранения данных интернет-магазина по продаже сотовых телефонов
Сначала необходимо определиться с тем, какие сущности потребу-
ются для работы интернет-магазина: список моделей сотовых теле-
фонов; список заказов; информация о клиентах; информация о со-
трудниках, которые обрабатывают заказы.

Для создания ER-диаграмм можно воспользоваться различными
инструментальными средствами, в частности, можно использовать
Microsoft Visio. На рис. 6.2 приведена ER-диаграмма для рассматри-
ваемого примера

На диаграмме используются следующие обозначения.

•	прямоугольниками обозначаются сущности, которые затем будут
преобразованы в таблицы данных;

•	ромбы обозначают отношения между сущностями, текстом в них
помечаются краткие наименования отношений;

•	соединительные линии обозначают связи между сущностями
и отношениями;

•	цифры показывают, сколько экземпляров сущности или отноше-
ния может содержать данная связь; если указывается буква «и»,
то это означает множество экземпляров;

•	показаны атрибуты или поля сущностей, которые видятся
на этапе концептуального моделирования; при дальнейшей дета-
лизации количество и состав атрибутов могут измениться.

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

Наиболее распространенным видом диаграмм для даталогиче-
ского (и последующего физического) проектирования является ER-
модель. При проектировании желательно использовать специализи-
рованные программные продукты, которые позволяют рисовать
логические схемы баз данных, а затем переходить от них к физиче-
скому проектированию. Одним из таких средств проектирования
является «AllFusion ERWm Data Modeler». Логическая модель данных
для рассматриваемого примера, построенная с использованием этого
программного продукта, представлена в виде ER-диаграммы
на рис. 6.3.

Для построения ER-модели даталогической структуры данных
используются определенные стандартные элементы:

•	прямоугольники со списком полей — обозначают таблицы, логи-
ческие имена которых написаны сверху;

•	первичный ключ таблицы — однозначно идентифицирует каждую
запись с ее данными, отделяется от прочих полей горизонтальной
чертой (например, поле 1D клиента); в большинстве случаев пер-
вичные ключи вводятся искусственно (например, как последова-
тельно выделяемый номер); если между таблицами существует
связь, то первичный ключ родительской таблицы прописывается
среди полей дочерней (например, поле «ID клиента» в таблице
заказов); для связи «многие-ко-многим» создаются дополнитель-
ные таблицы (например, таблица «Телефоны заказа»); если дан-
ная таблица является дочерней для другой таблицы, то в нее вхо-
дит первичный ключ родительской таблицы, такие поля называ-
ются «внешний ключ», на диаграмме они помечены символами
«FK»;

•	закругленные прямоугольники — обозначают таблицы, которые
имеют связь с другими таблицами «к одному», их часто называют
таблицами-расширениями (справочниками). В данном примере
две таблицы «Телефоны заказа» и «Обработавшие заказ сотруд-
ники» являются дополнительными; они необходимы, так как
между таблицей «Телефоны» и таблицей «Заказы», а также между
202

Телефоны__________________

ID телефона______________

ID фирмы-изготовителя (FK)
Название модели

Описание

Количество на складе

Цена

Телефоны заказа
JD телефона (FK)
ID заказа (FK)
Количество

Обработавшие заказ сотрудники
-----------------------------

ID сотрудника (FK)

ID заказа (FK)

Сотрудники_______

ID сотрудника

1D должности (FK)
ФИО

Заказы, в которые входит телефон

Телефоны данной фирмы/
Фирма телефона

Фирмы-изготовители
ID фирмы-изготовителя
Код(АК1.1)
Наименование

^Заказы._________________

обработанные сотрудником

_	Кто обработал заказ

I елефоны, входящие в заказ

Заказы_______________

ID заказа___________

ID клиента (FK)

Номер заказа (АК1.1) —

Дата заказа
Дата доставки

Сотрудники,
занимающие должность/
Должность сотрудника

Должности_____

1D должности

Код(АК1.1)
Наименование

Заказы клиента/

Клиент, сделавший заказ

Клиенг ы__________

ID клиента________

ФИО

Контактный телефон

Адрес доставки

Рис. 6.3. Логическая модель данных для интернет-магазина
таблицами «Заказы» и «Сотрудники» возможна связь «многие-ко-
многим»;

•	линиями показываются связи между таблицами, для пояснения
сути связей возможно задание поясняющих текстов;

•	точки на конце линии обозначают, что данная таблица является
дочерней для связи (обычно на одну запись родительской таб-
лицы могут ссылаться несколько записей из дочерней таблицы);

•	пунктирные линии обозначают, что дочерняя таблица не обяза-
тельно должна ссылаться на родительскую (поле может иметь
пустое значение).

Физическое проектирование — этап создания схемы базы данных
для конкретной СУБД. Специфика конкретной СУБД может вклю-
чать в себя ограничения на поименование объектов БД, на поддер-
живаемые типы данных и т.п. Кроме того, специфика конкретной
СУБД при физическом проектировании включает выбор решений,
связанных с физической средой хранения данных (выбор методов
управления дисковой памятью, разделение БД по файлам и устрой-
ствам, методов доступа к данным), создание индексов и т.д. Б каче-
стве примера на рис. 6.4 показано, как будет выглядеть разработан-
ная выше даталогическая модель данных для СУБД MS SQL Server.

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

Сама диаграмма в точности повторяет даталогическую, но в ней
уже присутствует информация, специфическая для конкретной БД,
например названия типов. Автоматизированные средства проекти-
рования баз данных позволяют по построенной физической схеме
БД сформировать скрипты на создание всех необходимых в базе дан-
ных объектов. В листинге 6.1 показан скрипт, который генерирует
ERWin для таблицы телефонов.

Листинг 6.1

Пример автоматической генерации скрипта на создание таблицы

CREATE TABLE Phones
(

PhonelD integer IDENTITY (1,1),

Koael varchar(20) NULL,

Description varchar(20) NULL,

Count integer NULL,
Phones

PhonelD: integer_____________

Manufacturer] D: integer (FK)
Model: varchar(20)

Description: varchar(20)
Count' integer

Price: integer

ManufacturersPbonesRel

Manufacturers___________

ManufacturerlD: integer
Code: varchar(20) (AK1.1)
Title: varchar(20)

PhonesOrdcrsRel

Employees

ClientsOrdersRel

Clients

ClientlD: char(18)__________

FullNamc: varchar(20)

ContactPhone: varchar(20)

DeliveryAddress: varchar(20)

Рис. 6.4. Физическая модель данных для интернет-магазина
Price money NULL,

ManufacturerlD integer NOT NULL

)
go
ALTER TABLE Phones

ADD CONSTRAINT XPKPhones PRIMARY KEY CLUSTERED (PhonelD ASC)
go

ALTER TABLE Phones

ADD CONSTRAINT Man.ufaccurersPhon.esRel FOREIGN KEY (ManufacturerlD)
REFERENCES Manufacturers(ManufacturerlD)

ON DELETE NO ACTION

ON UPDATE NO ACTION
go

Конструирование логики работы с данными. Под конструированием
логики работы с данными понимается разработка процедур
и функций, которые позволяют осуществлять как обработку, так
и контроль хранимой информации средствами СУБД.

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

Более безопасным считается подход, когда доступ к таблицам
данных имеют только процедуры СУБД, которые вызываются при-
ложением. Это позволяет в самих процедурах контролировать це-
лостность данных и не выполнять некорректные действия. При этом
доступ приложения непосредственно к таблицам полностью запре-
щается. В данном случае необходимо для каждой таблицы создавать
как минимум четыре процедуры:

1)	процедуру на чтение данных (процедуры на чтение данных
не обязательно должны работать с одной таблицей, они могут ис-
пользовать сложные запросы, которые получают данные из несколь-
ких таблиц, а также иметь дополнительные параметры, которые бу-
дут управлять процессом отбора записей/фильтровать);

2)	процедуру добавления данных;

3)	процедуру изменения данных;

4)	процедуру удаления данных.
Подход к работе с данными через процедуры требует программи-
рования на уровне баз данных. Дальнейшим развитием данного под-
хода является программирование всей логики обработки данных
в БД, а приложение должно только отображать информацию, осу-
ществлять первичную проверку корректности вводимых данных
и вызывать соответствующие процедуры в СУБД. Такой тип прило-
жений называется «с тонким клиентом».

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

Вопросы безопасности баз данных. Безопасность напрямую свя-
зана с хранимой информацией. Любая организация, создающая или
заказывающая программный продукт, напрямую заинтересована
в том, чтобы информация, с которой она будет работать, не попала
к злоумышленникам. Безопасность базы данных складывается из не-
скольких составляющих.

Безопасность на уровне прав доступа. Все современные СУБД под-
держивают выдачу прав доступа практически на любой объект БД.
Любое приложение, которое подключается к данным, должно
пройти процедуру авторизации (в параметрах подключения необхо-
димо указать логин и пароль). После авторизации оно получает до-
ступ к тем объектам БД, которые прописаны в его правах. Причем
права на объекты состоят не только из вариантов «Есть доступ», «Нет
доступа». Для каждого объекта БД сушествует свой набор прав. На-
пример, для таблицы возможны следующие права: «На чтение дан-
ных», «На добавление данных», «На изменение данных», «На удале-
ние данных», «На чтение данных из конкретных полей таблицы».

Совмещенная безопасность на уровне разработанной архитектуры
БД и прав доступа. Данный вариант подразумевает запрет любых об-
ращений к таблицам для учетных записей приложений, которые с ней
работают. Приложения должны вызывать соответствующие про-
цедуры СУБД, которые имеют права на работу с таблицами данных.

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

Обеспечение безопасности при разработке. Обеспечение безопас-
ности на уровне прав доступа не защищает от ошибок программиро-
вания, которые могут дать возможность злоумышленникам получить
доступ к данным либо испортить их. Одним из наиболее распростра-
ненных вариантов являются SQL-инъекции. В случае когда запросы
к БД формируются динамическим образом (прямо в приложении
создается строка запроса), злоумышленник может изменить или даже
заменить существующий запрос к БД и получить доступ к недоступ-
ной ранее информации. Например, в программе динамически фор-
мируется следующий запрос:

SELECT id, папе FROM products WHERE manufacturer = «©price»,
где вместо ключевого слова «eprice» динамически подставляется
значение поля с названием производителя, которое заполняет поль-
зователь. Если злоумышленник в качестве наименования произво-
дителя введет следую] ций текст (корректность синтаксиса зависит
от используемой СУБД):

фыаыва': delete from products; commit;

то запрос выполнится корректно, но также удалятся все данные
о продуктах.

6.3. Структурное программирование

Структурное программирование — это определенные общие прин-
ципы и правила проектирования, разработки и оформления прог-
рамм с целью облегчения процессов их создания и тестирования,
повышения производите]гьности труда программистов и улучшения
читабельности результирующей программы. Структура программы
и алгоритм решения задачи должны быть легкими для понимания,
простыми для доказательства правильности и удобными для моди-
фикации. По своей сути структурный подход есть отказ от беспоря-
дочного стиля в алгоритмизации и программировании (в частности,
отказ от оператора goto) и определение ограниченного числа стан-
дартных приемов построения легко читаемых алгоритмов и прог-
рамм с ясно выраженной структурой, что особенно важно при раз-
работке больших программных систем

Опыт применения методов структурного программирования при
разработке, например, ряда сложных операционных систем показы-
вает, что правильность логической структуры системы в этом случае
легко поддается доказательству, а сама система допускает достаточно
полное тестирование. Уменьшение трудностей отладки и тестирова-
ния программ приводит к увеличению производительности труда
программистов, поскольку на тестирование программы тратится
от трети до половины времени ее разработки. Производительность
труда программиста обычно измеряется числом отлаженных опера-
торов, которые он может написать за день. Приближенные оценки
показывают, что применение методов структурного программиро-
вания позволяет увеличить это число в 5—6 раз. Также нужно сказать,
что структурное программирование предполагает определенную ор-
ганизацию самого процесса программирования и определенную тех-
нологию проектирования программ, что также положительно влияет
на производительность труда программистов

Основы структурного программирования. Теоретическим фунда-
ментом структурного программирования является теорема о струк-
турировании, из которой следует, что алгоритм (программа) решения
любой практически вычислимой задачи может быть представлен
с использованием трех элементарных базисных управляющих струк-
тур: структуры следования (последовательности); структуры ветвле-
ния, структуры цикла, изображенных на рис. 6.5—6.7 соответственно,
где Р — условие, S — оператор.

Структура следования представляет собой естественный ход вы-
полнения алгоритма — любую последовательность операторов, вы-
полняющихся друг за другом (см. рис. 6.5). В языке программиро-
вания это соответствует последовательности операторов ввода, вы-
вода и операторов присваивания.

Структура ветвления представляет фактор принятия решения,
включает проверку некоторого логического условия Р и, в зависи-
мости от результатов этой проверки, выполнение оператора S1 либо
оператора S2. В языках программирования (например, Pascal) реа-
лизуется оператором if Р then SI else S2 (см. рис. 6.6).

Структура цикла (цикла с предусловием) представляет фактор по-
вторяемости вычислений, обеспечивает многократное повторение
выполнения оператора S, пока выполняется (истинно) логическое
Рис. 6.5. Структура следования

Рис. 6.6. Структура ветвления

Рис. 6.7. Структура цикла с предусловием
условие Р. В языках программирования (например, Pascal) реализу-
ется оператором while Р do S (см. рис. 6.7).

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

Любая программа может быть построена посредством компози-
ции базисных структур: либо путем их последовательного соеди-
нения — образования последовательных конструкций, либо путем
их вложения друг в друга — образования вложенных конструкций.

Каждая из структур может рассматриваться как один функцио-
нальный блок с одним входом и одним выходом Блоки S, S1, S2,
входящие в состав базисных управляющих структур, сами могут быть
одной из них, поэтому возможны вложенные конструкции. Однако,
какова бы ни была степень и глубина «вложенности», важно, что лю-
бая конструкция в конечном итоге имеет один вход и один выход.
Следовательно, любую сложную структуру можно рассматривать как
«черный ящик» с одним входом и одним выходом. Таким образом,
можно ввести преобразование любой структуры в функциональный
блок. Тогда всякий алгоритм, составленный из стандартных структур,
поддается последовательному преобразованию к единственному
функциональному блоку, и эта последовательность преобразований
может быть использована как средство понимания алгоритма и до-
казательства его правильности. Обратная последовательность пре-
образований может быть использована в процессе проектирования
алгоритма с постепенным раскрытием единственного функциональ-
ного блока в сложную структуру основных элементов.

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

Методика разработки программ. Распространены две методики
(стратегии) разработки программ, относящиеся к структурному про-
граммированию: программирование «сверху вниз»; программиро-
вание «снизу вверх».

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

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

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

Общие принципы разработки программных проектов. Использова-
ние технологии структурного программирования при разработке
серьезных программных проектов основано на следующих прин-
ципах:

•	программирование должно осуществляться «сверху вниз»;

•	весь проект должен быть разбит на модули/подпрограммы с од-
ним входом и одним выходом;

•	любая подпрограмма должна допускать только три основные
структуры: последовательное выполнение операторов, ветвление
и цикл;

•	недопустим оператор безусловной передачи управления goto;

•	документация должна создаваться одновременно с программиро-
ванием, частично в виде комментариев к программе.

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

6.4.	Объектно-ориентированное программирование

Объектно-ориентированное или объектное программирование
(ООП) — парадигма программирования, в которой основными кон-
цепциями являются понятия объектов и классов. Под парадигмой
программирования понимается система идей и понятий, определя-
ющая стиль написания компьютерных программ, а также образ
мышления программиста.

В настоящее время количество языков программирования, ис-
пользуемых для создания различных приложений и реализующих
объектно-ориентированную парадигму, достаточно много. В области
системного программирования общепринятым языком являлся язык
С, в котором применяется парадигма процедурного программиро-
вания. В настоящее время при взаимодействии системного и при-
кладного уровней операционных систем заметное влияние оказывают
языки объектно-ориентированного программирования; например,
одной из наиболее распространенных библиотек мультиплатформен-
ного программирования является объектно-ориентированная биб-
лиотека Qt, написанная на языке C++.

Основные понятия. Абстракция данных — подход к обработке дан-
ных по принципу «черного ящика». Данные обрабатываются функ-
цией высокого уровня с помощью вызова функций более низкого
уровня Это позволяет работать с объектами, не вдаваясь в особен-
ности их реализации.

Пример задания абстрактной функции (без ее реализации в дан-
ном классе) приведен в листинге 6.2 (синтаксис зависит от языка
программирования). Функция уже известна, но ее конкретная реа-
лизация будет выполнена на более низком уровне — в классах-по-
томках

Листинг 6.2

Пример объявления абстрактного метода

int Calculated;

Класс — это тип, описывающий структуру объектов-экземпляров.
Под классом подразумевается некая сущность, которая задает общее
поведение объектов этого класса (через методы), а также позволяет
хранить состояние объекта (используя поля класса). Класс можно
сравнить со схемой, согласно которой создаются объекты этого
класса. Обычно классы разрабатывают таким образом, чтобы их объ-
екты соответствовали объектам предметной области.

Пример определения класса приведен в листинге 6.3 (синтаксис
зависит от языка программирования).

Листинг 6.3

Пример объявления класса

class Client
{
}

Члены класса. Класс определяется как список членов своего
класса. К членам класса относятся его поля (свойства) и функции (ме-
тоды). Для каждого члена класса можно установить соответству-
ющую область доступа (access control level). Область доступа члена
класса определяет участки кода, из которых к этому члену будет воз-
можно обращение.

В большинстве объектно-ориентированных языков программи-
рования поддерживаются следующие области доступа:

•	private (закрытый, внутренний член класса) — обращения допу-
скаются только из методов класса, в котором этот член определен;
наследники класса уже не смогут получить доступ к этому члену;

•	protected (защищенный, внутренний член иерархии классов) — об-
ращения допускаются из методов класса, в котором этот член
определен, или из любых его классов-наследников;

•	public (открытый член класса) — обращения допускаются из лю-
бого кода.

Пример задания членов класса приведен в листинге 6.4 (синтак-
сис зависит от языка программирования).

Листинг 6.4

Пример задания членов класса

class Client
{

private string firstName;

private string lastName;

private DateTime birthday;

public Client(string parFirstName, string par LastName,
EateTime parBirthday'

{

firstName parFirstName;

lastName = parLastName;

birthday parBirthday;

)

public int CalculateAge(DateTime parDate)

{
return iparDate - birthday).Year;

}
)

Интерфейс класса — это набор публичных полей и методов
класса, к которым можно обращаться из других классов, частей прог-
раммы. Для примера в листинге 6.4 в интерфейс класса будут входить
конструктор класса: Client (string parFirstName, string par LastName,
DateTime parBirthday) и метод вычисления возраста: public int Calcu-
lateAge (DateTime parDate)

В некоторых языках программирования появились интерфейсы,
объявляемые как типы данных; например, в C# можно объявить ин-
терфейс класса, который будет содержать объявления методов, обя-
зательных для реализации в классах, наследующих данный интер-
фейс.

Прототип — это объект-образец, по образу и подобию которого
создаются другие объекты. Если в класс, описанный в предыдущем
примере, добавить метод Clone, который будет возвращать эк-
земпляр объекта, инициированный текущими значениями полей,
то можно сказать, что класс является прототипом (листинг 6.5).

Листинг 6.5

Пример создания класса-прототипа

class Client
{

public Client Cloned

{
return new Client(this.firstName, this.lastName, this.birthday);

}

}

Абстрактный класс — класс, содержащий хотя бы один аб-
страктный метод. Абстрактный метод не реализуется для класса,
в котором описан, однако должен быть реализован для его неаб-
страктных потомков.

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

Абстрактный класс можно рассматривать в качестве интерфейса
к семейству классов, порожденному им, но в отличие от классиче-
ского интерфейса абстрактный класс может иметь определенные
методы, а также свойства.

Абстрактные методы часто являются и виртуальными (переопре-
деляемыми в потомках), в связи с чем понятия «абстрактный»
и «виртуальный» иногда путают.

Пример объявления абстрактного класса представлен в лис-
тинге 6.6.
Листинг 6.6

Пример объявления абстрактного класса

abstract class Client
{

private string tirstName;

private string lastName;

private DateTime birthday;

public Client(string parFirstName, string par LastName,
DateTime parBirthday)
{

firstName = parFirstName;

lastName = parLastName;

birthday = parBirthday;

}

public abstract int CalculateAge(DateTime parDate);

Объект, наряду с понятием «класс», является основополагающим
понятием объектно-ориентированного подхода. Под объектом под-
разумевается некоторая сущность, обладающая состоянием и пове-
дением. Объекты могут принадлежать одному или нескольким клас-
сам, которые, в свою очередь, определяют поведение объекта. Время
с момента создания объекта до его уничтожения называется временем
жизни объекта.

Инстанцирование — создание экземпляра класса; в отличие
от слова «создание» применяется не к объекту, а к классу: говорят
«создать экземпляр класса» или «инстанцировать класс».

Экземпляр класса — это конкретный описанный объект (суще-
ствующий в памяти). Класс описывает свойства и методы, которые
будут доступны объекту, относящемуся к этому классу Экземпляры
используют для представления конкретных сущностей реального
мира Создание экземпляра класса может осуществляться операцией
new (листинг 6.7).

Листинг 6.7

Пример объявления экземпляра класса

Client client = new Client(“Иван’, “Иванов’, DateTime.
Parse("10.C4.1983"));

Концепции объектно-ориентированною программирования.
В центре ООП находится понятие объекта. Объект — это сущность,
которой можно посылать сообщения (вызывать методы) и которая
может на них реагировать, используя свои данные. Данные объекта
скрыты от остальной программы. Сокрытие данных (объявление для
них области видимости «protected» или «private»') называется инкапсу-
ляцией. Однако наличие инкапсуляции еще не означает объектной
ориентированности языка, для этого требуется наличие наследования.
Но в полной мере преимущества ООП проявляются только в том
случае, когда в языке программирования реализован полиморфизм —
возможность объектов с одинаковой спецификацией иметь различ-
ную реализацию.

Кратко суть концепции объектно-ориентированного программи-
рования можно выразить следующими тезисами. Система состоит
из объектов Объекты некоторым образом взаимодействуют между
собой. Каждый объект характеризуется своим состоянием и поведе-
нием. Состояние объекта задается значением полей данных Пове-
дение объекта задается методами.

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

Класс, от которого произошло наследование, называется базовым
или родительским. Классы, которые произошли от базового, назы-
ваются потомками, наследниками или производными классами (лис-
тинг 6.8).

Листинг 6.8
Простейший пример наследования

class Classi

{

}

class Class2: Classi

{
}

Инкапсуляция — свойство языка программирования, позволя-
ющее объединить данные и код в объект и скрыть реализацию объ-
екта от пользователя. При этом пользователю предоставляется
только спецификация (интерфейс) объекта. Пользователь может взаи-
модействовать с объектом только через этот интерфейс. Инкапсуля-
ция может быть достигнута простейшими организационными ме-
рами. Знание того, что «вот так делать нельзя», иногда является са-
мым эффективным средством инкапсуляции (листинги 6.9 и 6 10).

Листинг 6.9

Класс реализации комплексного числа

// Класс комплексного числа

class Complex

{

// Целая часть числа
private double re;
// Мнимая часть числа
private double im;

// Конструктор с инициализацией

public Complex(double i_re, double i_im)

{

re i_re;

im = i_im;

}

// Сложение комплексных чисел

// parCcmplexl - Первое комплексное число

// parComplex2 - Второе комплексное число

public static Complex operacort(Complex parComplexl,

Complex parComplex2)

{

return new Complex(parComplexl.re + parComplex2,re,
parComplexl.im + parCcmplex2,im);

}

}

		Листинг 6.10
	Использование класса комплексного числа	
Complex complexl  Complex complex2  Complex complex3	= new Complex(1,1);  = new Complex(2,2);  = complexl + complex2;	

Следует особо отметить, что одна из наиболее распространенных
ошибок заключается в попытке делать сокрытие реализации только
ради сокрытия. Целями, достойными усилий, являются: достижение
предельной локализации изменений при их необходимости; прогно-
зируемость изменений (какие изменения в коде надо сделать для
заданного изменения функциональности); прогнозируемость по-
следствий изменений.
Полиморфизм — взаимозаменяемость объектов с одинаковым ин-
терфейсом. Язык программирования поддерживает полиморфизм,
если классы с одинаковой спецификацией могут иметь различную
реализацию, например реализация класса может быть изменена
в процессе наследования. Кратко смысл полиморфизма можно вы-
разить фразой: «один интерфейс, множество методов».

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

Возможность приписывать разную функциональность одному
методу (функции, операции) называется перегрузкой метода (лис-
тинг 6.11).

Листинг 6.11

Пример перегрузки метода для арифметической операции

// Класс для определения произвольной арифметической операции
//с использованием двух переменных
class Operation

{

// Вь'числение произвольной операции с участием двух переменных

public virtual float Calculate(float parArgumentl,
float parArgument2);

}

// Сложение двух переменных
class Add: Operation

{

// Сложение с использованием двух переменных

public override float Calculate(float parArgumentl,
float parArguments)

{

return parArgumentl + parArgument2;

}

}

// Сложение двух переменных

class Sub: Operation

{
// Сложение с использованием двух переменных

public override float Calculate (float parArgumer.tl,

float parArgumert2)

{

return parArgtmei tl - parArgumert2;

}
}

В приведенном примере листинга 6.11 класс «Operation» опреде-
ляет виртуальный метод, который подразумевает какое-то арифме-
тическое вычисление с использованием двух переменных и возвра-
щение результата. Класс «Add» является наследником «Operaion»
и перегружает метод «Calculate» как операцию сложения двух пере-
менных. Класс «Sub» также является наследником «Operation» и пе-
регружает метод «Calculate» как операцию вычитания.

Листинг 6.12

Простейший пример использования полиморфизма

Operation operation = new Add();

float resultl = operation.Calculated.Of, l.Cf),
operation = new Sub();

float result2 = operation.Calculated.Of, l.Cf);

В листинге 6.12 представлен простейший пример использования
полиморфизма. В примере объявляется локальная переменная «op-
eration» с типом родительского класса «Operation» и ей присваивается
экземпляр класса «Add». Данное присвоение разрешается и является
одним из свойств наследования: переменным с типом родительского
класса можно присваивать экземпляры классов-наследников,
но не наоборот. В результате вызова метода «Calculate» переменная
«resultl» примет значение 2.Of, так как в данный момент переменная
«operation» является экземпляром класса «Add», где вычисление
определено как сложение. Далее переменной «operation» присваива-
ется значение экземпляра «Sub» и вызов метода «Calculate» возвратит
значение O.Of, как результат вызова метода из класса «Sub».

Конструктор — специальный метод в объектно-ориентированном
программировании, служащий для инициализации объекта при его
создании (например, выделения памяти). В языках программиро-
вания C++, C# или Java конструктором класса называется функция,
имеющая то же имя, что и сам класс, и не возвращающая никакого
значения. Можно сказать, что конструктором называется тот метод
класса, который вызывается автоматически при создании экзем-
пляра класса. В зависимости от варианта объявления конструктора
различают следующие их виды (листинг 6.13):

•	конструктор по умолчанию — конструктор, не имеющий обяза-
тельных аргументов: в отсутствие явно заданного конструктора
по умолчанию его код генерируется компилятором автоматически
при компиляции;

•	конструктор копирования — конструктор, аргументом которого
является ссылка на объект того же класса; используется для со-
здания экземпляра класса со значениями полей, аналогичными
копируемому объекту;

•	обычный конструктор — объявляется с произвольным количе-
ством параметров, необходимых для инициализации класса.

Листинг 6.13
Пример объявления конструкторов различного вида

// Класс комплексного числа

class Complex

{

double re;

double im;

// Конструктор по умолчанию

public Complex()

{

re - 0.0;

im = 0.0;

}

// Конструктор копирования

public Complex(Complex obj)

{

re obj.re;

im = obj.im;

}

// Конструктор с инициализацией (обычный конструктор)
public Complex(double i_re, double i_im)
{

re i_re;

im = i_im;

}

Деструктор — специальный метод класса, служащий для деини-
циализации объекта (например, освобождения памяти). Имя де-
структора должно совпадать с именем класса и иметь префикс ~.
У класса может быть только один деструктор. Деструктор не имеет
модификатора доступа и параметров (листинг 6.14).

Листинг 6.14

Пример объявления деструктора

// Класс комплексного числа
class Complex

{

double re;

double im;

// Конструктор с инициализацией (обычный конструктор)

public Complex(double i_re, double i_im)

{

re i_re;

im = i_im;

)

// Деструктор

-Complex()

{

)
)

Виртуальный метод — метод/функция класса, который может
быть переопределен в классах-наследниках так, что конкретная реа-
лизация метода будет определяться во время исполнения (лис-
тинг 6.15).

Листинг 6.15

Пример объявления виртуальных и невиртуальных функций

class Ancestor
{

public virtual void functionl ()

{

Console.WriteLlne(«Ancestor.functionl()»);

}

public void function2 ()

{

Console.WriteLlne («Ancestor. functlor.2 () ») ;

}
}
class Descendant: Ancestor
{

public override void functionl ()
{
Console.WriteLine(«Descendant.functionl()»);
}
public void functions ()
{

Console.WriteLine(«Descendant.functions()»);

}
}

Descendant descendant = new Descendant();

Ancestor ancestor = descendant;

descendant.Functionl();

descendant.Function^ ();

ancestor.Functionl();

ancestor.Function.2 ();

Программисту необязательно знать тип объекта для работы с ним
через виртуальные методы, достаточно лишь знать, что объект при-
надлежит классу или наследнику класса, в котором метод объявлен.
Базовый класс может и не предоставлять реализации виртуального
метода, а только декларировать его существование. Такие методы без
реализации называются «чисто виртуальными» (англ, pure virtual)
или «абстрактными». Класс, содержащий хотя бы один такой метод,
тоже будет абстрактным. Объект такого класса создать нельзя (в не-
которых языках допускается, но вызов абстрактного метода приведет
к ошибке). Наследники абстрактного класса должны предоставить
реализацию для всех его абстрактных методов, иначе они, в свою
очередь, будут абстрактными классами.

В примере листинга 6.15 класс «Ancestor» определяет две
функции, одна из них виртуальная, другая — нет. Класс «Descendant»
переопределяет обе функции, но одинаковое обращение к функциям
дает разные результаты. Результат, получаемый на выходе, представ-
лен листингом 6.16.

Листинг 6.16

Пример вызова виртуальных и невиртуальных функции

Descendant.Functionl

Descendant.Functions

Descendant.Functionl

Ancestor.FunctionS
В случае виртуальной функции для определения реализации
функции используется информация о типе объекта и вызывается
«правильная» реализация независимо от типа указателя. При вызове
невиртуальной функции компилятор руководствуется типом пере-
менной, поэтому вызываются две разные реализации «function2()»,
несмотря на то что используется один и тот же объект.

6.5.	Шаблоны проектирования

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

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

1.	Имя. Сославшись на него, можно сразу описать проблему про-
ектирования, ее решения и их последствия. Присваивание шаблонам
имен позволяет проектировать на более высоком уровне абстракции.
С помощью словаря шаблонов можно вести обсуждение с коллегами,
упоминать шаблоны в документации, в тонкостях представлять ди-
зайн системы. Нахождение хороших имен было одной из самых труд-
ных задач при составлении каталога шаблонов.

2.	Задача. Описание того, когда следует применять шаблон. Не-
обходимо сформулировать задачу и ее контекст. Может описываться
конкретная проблема проектирования, например способ представ-
ления алгоритмов в виде объектов. Иногда отмечается, какие струк-
туры классов или объектов свидетельствуют о негибком дизайне.
Также может включаться перечень условий, при выполнении кото-
рых имеет смысл применять данный шаблон.

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

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

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

Принципы работы с шаблонами проектирования. В распоряжение
проектировщика предоставлен каталог более чем из 20 шаблонов,
и поэтому трудно решить, какой шаблон лучше всего подходит для
конкретной задачи.

В качестве примера можно привести следующие подходы к вы-
бору подходящего шаблона: следует обдумать, как шаблоны решают
проблему проектирования; проанализировать назначение шаблонов;
изучить взаимосвязи шаблонов; проанализировать шаблоны со сход-
ными целями; разобраться в причинах, вызывающих перепроекти-
рование; посмотреть, что в вашем дизайне должно изменяться.

Работа с шаблонами состоит из следующих этапов.

1.	Прочитайте описание шаблона, чтобы получить о нем общее
представление.

2.	Убедитесь, что понимаете упоминаемые в шаблоне классы
и объекты и то, как они взаимодействуют друг с другом.

3.	Выберите для участников шаблона подходящие имена. Имена
участников шаблона обычно слишком абстрактны, чтобы употреб-
лять их непосредственно в коде. Тем не менее бывает полезно вклю-
чить имя участника как имя в программе. Например, если вы поль-
зуетесь шаблоном «стратегия в алгоритме размещения текста»,
то классы могли бы называться «SimpleLayoutStrategy» или «TeXLay-
outSirategy».
4.	Определите классы, объявите их интерфейсы, установите от-
ношения наследования и определите переменные экземпляра, кото-
рыми будут представлены данные объекты и ссылки на другие объ-
екты Выявите имеющиеся в вашем приложении классы, на которые
шаблон оказывает влияние, и соответствующим образом модифици-
руйте их.

5.	Определите имена операций, встречающихся в шаблоне. Здесь,
как и в предыдущем случае, имена обычно зависят от приложения.
Руководствуйтесь теми функциями и взаимодействиями, которые
ассоциированы с каждой операцией Кроме того, будьте последова-
тельны при выборе имен. Например, для обозначения фабричного
метода можно было бы всюду использовать префикс «Create».

6.	Реализуйте операции, которые выполняют обязанности и от-
вечают за отношения, определенные в шаблоне.

Основные типы шаблонов проектирования Приведем краткий об-
зор шаблонов проектирования (табл. 6.1). Для более детального озна-
комления рекомендуется воспользоваться приведенным списком
специализированной литературы В конце будет показан пример
реализации шаблона «Синглетон».

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

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

Структурные шаблоны позволяют рассматривать вопрос, как
из классов и объектов образуются более крупные структуры. Струк-
турные шаблоны уровня класса используют наследование для со-
ставления композиций из интерфейсов и реализаций. В качестве
Таблица 6.1

Шаблоны проектирования и их краткое описание

Порождающие шаблоны	Абстрактная фабрика	Семейства порождаемых объектов
	Одиночка	Единственный экземпляр класса
	Прототип	Класс, из которого инстанцируется объект
	Строитель	Способ создания составного объ- екта
	Фабричный метод	Инстанцируемый подкласс объекта
Структурные шаблоны	Адаптер	Интерфейс к объекту
	Декоратор	Обязанности объекта без порож- дения подкласса
	Заместитель	Способ доступа к объекту, его ме- стоположение
	Компоновщик	Структура и состав объекта
	Мост	Реализация объекта
	Приспособленец	Накладные расходы при хранении объектов
	Фасад	Интерфейс к подсистеме
Шаблоны поведения	Интерпретатор	Грамматика и интерпретация языка
	Итератор	Способ обхода элементов агрегата
	Команда	Время и способ выполнения за- проса
	Наблюдатель	Множество объектов, зависящих от другого объекта.  Способ, которым зависимые объ- екты поддерживают себя в актуаль- ном состоянии
	Посетитель	Операции, которые можно приме- нить к объекту или объектам, не меняя класса
	Посредник	Объекты, взаимодействующие между собой, и способ их коопе- рации
	Состояние	Состояние объекта
	Стратегия	Алгоритм
	Хранитель	Закрытая информация, хранящаяся вне объекта, и время ее сохранения
	Цепочка обязанно- стей	Объект, выполняющий запрос
	Шаблонный метод	Шаги алгоритма
простого примера можно привести использование множественного
наследования для объединения нескольких классов в один. В ре-
зультате получается класс, обладающий свойствами всех своих ро-
дителей. Вместо композиции интерфейсов или реализаций струк-
турные шаблоны уровня объекта компонуют объекты для получе-
ния новой функциональности. Дополнительная гибкость в этом
случае связана с возможностью изменить композицию объектов
во время выполнения, что недопустимо для статической компози-
ции классов.

Примером структурного шаблона уровня объектов является
«Компоновщик». Он описывает построение иерархии классов для
двух видов объектов: примитивных и составных. Последние позво-
ляют создавать произвольно сложные структуры из примитивных
и других составных объектов. В шаблоне «Заместитель» объект берет
на себя функции другого объекта. У «Заместителя» есть много при-
менений. Он может действовать как локальный представитель объ-
екта, находящегося в удаленном адресном пространстве, или пред-
ставлять большой объект, загружаемый по требованию, или ограни-
чивать доступ к критически важному объекту «Заместитель» вводит
дополнительный косвенный уровень доступа к отдельным свойствам
объекта, поэтому он может ограничивать, расширять или изменять
эти свойства. Шаблон «Приспособленец» определяет структуру для
совместного использования объектов. Он акцентирует внимание
на эффективности использования памяти. В приложениях, где участ-
вует много объектов, должны снижаться накладные расходы на их
хранение (примером может служить программа, которая реализует
текстовый редактор, поддерживающий произвольное форматирова-
ние любых участков текста). Шаблон «Фасад» представляет набор
объектов и выполняет свои функции, перенаправляя сообщения
объектам, которые он представляет. Шаблон «Мост» отделяет аб-
стракцию объекта от его реализации, так что их можно изменять не-
зависимо.

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

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

Пример 6.2. Рассмотрим пример реализации шаблона «Оди-
ночка».

Название и классификация шаблона. «Одиночка» (Singleton) — ша-
блон, порождающий объекты.

Назначение. Гарантирует, что у класса есть только один экземпляр,
и предоставляет к нему глобальную точку доступа.

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

Как гарантировать, что у класса есть единственный экземпляр
и чтобы этот экземпляр был легко доступен? Глобальная переменная
дает доступ к объекту, но не запрещает создавать несколько экзем-
пляров класса. Более удачное решение — сам класс контролирует то,
что у него есть только один экземпляр, и может запретить создание
дополнительных экземпляров, перехватывая запросы на создание
новых объектов; он же способен предоставить доступ к своему эк-
земпляру Это и есть назначение шаблона «Одиночка».

Применимость. Используйте паттерн «Одиночка», когда должен
быть ровно один экземпляр некоторого класса, доступный всем кли-
ентам, или единственный экземпляр должен расширяться путем по-
рождения подклассов и клиентам нужно иметь возможность работать
с расширенным экземпляром без модификации своего кода. Струк-
тура паттерна «Одиночка» представлена на рис. 6.8.

Singleton

C1»ss

□	Fields

-Instance

□	Methods

Instance

Singleton

Рис. 6.8. Структура шаблона «Одиночка»

Участники. «Singleton» — одиночка: определяет операцию In-
stance, которая позволяет клиентам получать доступ к единственному
экземпляру (Instance — это статический метод класса); может нести
ответственность за создание собственного уникального экземпляра.

Отношения. Клиенты получают доступ к экземпляру класса Sin-
gleton только через его операцию Instance.

Результаты. У шаблона «Одиночка» есть следующие достоинства.

1)	контролируемый доступ к единственному экземпляру. Поскольку
класс «Singleton» инкапсулирует свой единственный экземпляр, он пол-
ностью контролирует то, как и когда клиенты получают доступ к нему;

2)	уменьшение числа имен. Шаблон позволяет избежать засорения
пространства имен глобальными переменными, в которых хранятся
уникальные экземпляры;

3)	допускает уточнение операций и представления. От класса «Sin-
gleton» можно порождать подклассы, а приложение легко настроить
экземпляром расширенного класса. Можно конкретизировать при-
ложение экземпляром того класса, который необходим во время вы-
полнения;

4)	допускает переменное число экземпляров. Шаблон позволяет
легко изменить решение и разрешить появление более одного экзем-
пляра класса «Singleton». Можно применять один и тот же подход для
управления числом экземпляров, используемых в приложении. Из-
менить нужно будет лишь операцию, дающую доступ к экземпляру
класса «Singleton».

Реализация шаблона представлена листингом 6.17.

При использовании шаблона «Одиночка» предусмотрено следу-
ющее. Гарантирована единственность экземпляра. Шаблон устроен
так, что больше одного экземпляра создать нельзя; для этого прячут
операцию, создающую экземпляры, за статической функцией-чле-
ном или методом класса, которые гарантируют создание не более
одного экземпляра. Данная операция имеет доступ к статическому
полю класса, где хранится уникальный экземпляр, и гарантирует
инициализацию переменной этим экземпляром перед возвратом ее
клиенту. При таком подходе «Одиночка» будет создан и инициали-
зирован перед первым использованием.

Листинг 6.17

Пример реализации шаблона «Одиночка»

class Singleton

{

// Статический экземпляр класса

private static Singleton _Instar.ce = null;

// Конструктор

private Singleton()

{

}

// Получение экземпляра класса

public static Singleton Instanced

{

if (_Instance == null)

_Instance new Singleton));

return _Instance;

}

Клиенты осуществляют доступ к «Одиночке» исключительно че-
рез статический метод «Instance». Переменная —Instance инициали-
зируется пустым значением Null, а статический метод «Instance»
возвращает ее значение, инициализируя ее уникальным экземпля-
ром, если в текущий момент оно равно Null. Метод «Instance» ис-
пользует отложенную инициализацию: возвращаемое ей значение
не создается и не хранится вплоть до момента первого обращения.

Необходимо отметить, что конструктор защищенный (private).
Клиент, который попытается создать экземпляр класса «Singleton»
непосредственно, получит ошибку на этапе компиляции. Это дает
гарантию, что будет создан только один экземпляр. Поскольку пере-
менная Instance — указатель на объект класса «Singleton», то функ-
ция-член Instance может присвоить этой переменной указатель
на любой подкласс данного класса.
6.6.	Система управления версиями

Система управления версиями (от англ. Version Control System —
VCS, или Revision Control System) — специальное программное обес-
печение для работы с часто изменяющейся информацией, позволяет
хранить несколько версий одного и того же документа и при необ-
ходимости возвращаться к более ранним версиям, определять, кто
и когда сделал то или иное изменение, а также многое другое.

Такие системы наиболее широко используются при разработке
программного обеспечения для хранения файлов разрабатываемой
программы.

Часто бывает, что над одним проектом одновременно работают
несколько человек, и если два человека изменяют один и тот же
файл, то один из них может случайно отменить изменения, сделан-
ные другим. Системы управления версиями отслеживают такие кон-
фликты и предлагают средства их решения Большинство таких
систем может автоматически объединить (слить) изменения, сделан-
ные разными разработчиками. Однако такое автоматическое объеди-
нение изменений обычно возможно только для текстовых файлов
и при условии, что изменялись разные (непсрссекающисся) части
этого файла. Это ограничение связано с тем, что большинство систем
управления версиями ориентированы на поддержку процесса разра-
ботки программного обеспечения, а исходные коды программ хра-
нятся в текстовых файлах. Если автоматическое объединение выпол-
нить не удалось, система может предложить решить проблему вруч-
ную.

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

Большинство систем управления версиями предоставляют следу-
ющие возможности:

•	позволяют создавать разные варианты одного документа (ветки)
с общей историей изменений до точки ветвления и с разными —
после нее;

•	дают возможность узнать, кто и когда добавил или изменил кон-
кретный набор строк в файле;

•	ведут журнал изменений, в который пользователи могут записы-
вать пояснения о том, что и почему они изменили в данной версии;
•	контролируют права доступа пользователей, разрешая или запре-
щая чтение или изменение данных, в зависимости от того, кто
запрашивает это действие.

Каждая система управления версиями имеет свои специфические
особенности в наборе команд, порядке работы пользователей и ад-
министрировании. Тем не менее общий порядок работы для боль-
шинства VCS совершенно стереотипен. Здесь предполагается, что
проект, каким бы он ни был, уже существует и на сервере размещен
его репозиторий, к которому разработчик получает доступ.

Начало работы с системой. Первым действием, которое должен
выполнить разработчик, является извлечение рабочей копии проекта
или той его части, с которой предстоит работать. Это действие вы-
полняется с помощью стандартной команды извлечения версии
(checkout или clone) либо с помощью специальной команды, факти-
чески выполняющей то же самое действие. Разработчик задает вер-
сию, которая должна быть скопирована, по умолчанию обычно ко-
пируется последняя (или выбранная администратором в качестве
основной) версия.

Ежедневный цикл работы. Обычный цикл работы разработчика
в течение рабочего дня выглядит следующим образом:

•	обновление рабочей копии’, по мере внесения изменений в основ-
ную версию проекта рабочая копия на компьютере разработчика
стареет и расхождение ее с основной версией проекта увеличива-
ется, это повышает риск возникновения конфликтных изменений
(см. ниже), и возникает необходимость поддерживать рабочую
копию в состоянии, максимально близком к текущей основной
версии, поэтому разработчик выполняет операцию обновления
рабочей копии (update) насколько возможно часто, что определя-
ется частотой внесения изменений, зависящей от активности раз-
работки, числа разработчиков, а также от времени, затраченного
на каждое обновление;

•	модификация проекта’ разработчик модифицирует проект, изме-
няя входящие в него файлы в рабочей копии в соответствии
с проектным заданием, эта работа производится локально
и не требует обращений к серверу VCS;

•	фиксация изменений’, завершив очередной этап работы над зада-
нием, разработчик фиксирует (commit) свои изменения, переда-
вая их на сервер (либо в основную ветвь, если работа над зада-
нием полностью завершена, либо в отдельную ветвь разработки
данного задания).
6.7.	Программные средства

При конструировании ПО обычно используют так называемые
среды разработки, т.е. системы программных средств для разработки
программного обеспечения.

Существуют и широко используются следующие интегрирован-
ные среды разработки, предназначенные для нескольких языков
программирования.

Eclipse — свободно распространяемая интегрированная среда раз-
работки модульных кроссплатформенных приложений, поддержи-
вает разработку на следующих языках: Java, C/C++, Fortran, Perl,
PHP, JavaScript, Python. Ruby.

NetBeans — интегрированная среда разработки приложений, под-
держивает разработку на языках: Java, JavaFX, Python, PHP, JavaS-
cript, C++, Ada.

Embarcadero RAD Studio — среда быстрой разработки приложений
для Microsoft Windows фирмы «Embarcadero Technologies». Текущая
версия Embarcadero RAD Studio ХЕЗ объединяет Delphi ХЕЗ и C++
Builder XE3. Delphi Prism ХЕЗ и HTML5 Builder в единую интегриро-
ванную среду разработки.

Qt Creator — свободно распространяемая среда разработки для
языков С, С+т и QML.

Microsoft Visual Studio — интегрированная среда разработки компа-
нии «Microsoft», позволяет создавать приложения на языках C/C++,
Visual Basic, С#, J#, F# и проекты для баз данных Microsoft SQL
Server, включает в себя множество дополнительных инструментов,
а также функционал для командной разработки и создания тестов.

Не менее популярны и среды разработки, предназначенные для
одного определенного языка программирования.

Visual Basic — среда разработки на одноименном языке.

Borland Delphi — среда разработки на языке Object Pascal.

Borland C++ Budder — среда разработки на C++.

Dev-C+т — среда разработки на C++

Наиболее распространенными системами контроля версий явля-
ются:

Git — поддерживает быстрое разделение и слияние версий, вклю-
чает инструменты для визуализации и навигации по нелинейной
истории разработки;

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

Для работы с хранилищами можно пользоваться как командной
строкой, так и графическими инструментами. В большинстве сред
разработки также существует встроенная поддержка.

Контрольные вопросы

1.	Что включает в себя процесс конструирования ПО? Перечислите ос-
новные категории ПО и объясните особенности процесса конструиро-
вания для каждой из них.

2.	Дайте определение БД, а также определение иерархической, сетевой,
реляционной, объектно-ориентированной, объектно-реляционной БД.

3.	В чем отличие «толстого» клиента от «тонкого»?

4.	Какие понятия входят в модель реляционной БД? Перечислите компо-
ненты реляционной модели данных.

5.	Какие задачи решает проектирование БД?

6	Дайте определение концептуального (инфологического) проектирова-
ния. Опишите принцип построения ER-диаграммы для концептуаль-
ной модели данных.

7	Дайте определение даталогического проектирования. Опишите прин-
ципы построения ER-диаграммы для даталогической модели данных.

8.	Дайте определение физического проектирования БД.

9.	Каковы особенности конструирования логики работы с данными для
СУБД?

10.	Расскажите о безопасности БД. Каковы основные варианты обеспече-
ния защиты данных?

11	Что такое SQL-инъекции, как можно защитить от них приложение?

12.	Каковы основные преимущества структурного программирования?

13.	Перечислите основные конструкции структурного программирования.

В чем их особенность? Расскажите о методике разработки программ
с использованием структурного программирования.

14.	Дайте определение объектно-ориентированного программирования
Какие основные понятия положены в основу объектно-ориентирован-
ного программирования?

15.	Какими тезисами можно кратко выразить концепции объектно-ориен-
тированного программирования?

16.	Дайте определение наследования, инкапсуляции, полиморфизма. По-
ясните смысл их использования.

17.	Дайте определение конструктора класса. Какие основные виды кон-
структоров бывают? Дайте определение деструктора.

18.	Дайте определение виртуальной функции. Чем переопределение вир-
туальной функции в дочернем классе отличается от переопределения
невиртуальной?
19.	Дайте определение шаблона проектирования. Как в общем виде опи-
сываются шаблоны? Опишите принципы работы с шаблонами.

20.	Опишите типы шаблонов проектирования, чем они отличаются и для
чего служат.

21.	Дайте определение системы управления версиями. Зачем они нужны?

22.	Перечислите основные возможности систем контроля версий.

23.	Как начать работу с системой управления версиями?

24.	Опишите ежедневный цикл работы с системой управления версиями.

Литература

1.	Алгоритмы Построение и анализ / Т Кормен и др — М.: Вильямс,
2011.-893 с.

2.	Бек К. Шаблоны реализации корпоративных приложений. — М.:
Вильямс, 2008. — 176 с

3.	Брауде Э. Технология разработки программного обеспечения. — СПб.:
Питер, 2004 — 655 с.

4	Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки прог-
раммного обеспечения / под ред. Л. Г. Гагариной. — М.. ФОРУМ:
ИНФРА-М, 2008 -400 с.

5	Грэхем И Объектно-ориентированные методы. Принципы и прак-
тика. — М.: Вильямс, 2004. — 880 с.

6.	Дал У., Дейкстра Э., Хоор К. Структурное программирование. — М.:
Мир, 1975 - 247 с.

7.	Дейкстра Э. Дисциплина программирования. — 1978. — 276 с.

8.	Иванова Г.С., Ничушкина Т.Н-, Пугачев Е.К. Объектно-ориентированное
программирование / под ред. Г. С. Иванова. — М МГТУ им. Н.Э. Ба-
умана, 2001. — 320 с.

9.	Кейт К.Дж. Введение в системы баз данных. — М.: Вильямс, 2006. —
1328 с.

10.	Кнут Д. Искусство программирования. Т. 1. Основные алгоритмы. —
М.: Вильямс, 2010. — 720 с.

11.	Кнут Д. Искусство программирования. Т. 2. Получисленные алго-
ритмы. — М.: Вильямс, 2011. — 768 с.

12.	КнутД. Искусство программирования. Т. 3. Сортировка и поиск. — М :
Вильямс, 2012 — 832 с.

13.	Кузнецов С.Д. Основы современных баз данных // CIT Forum. [Элект-
ронный ресурс] — http://citforum.ra/database/osbd/contents.shtml.

14.	Лунин С.А., Посыпкин МА. Технологии параллельного программиро-
вания. — М.: Форум: ИНФРА-М. 2011 — 208 с.

15.	Макдоннелл С. Совершенный код. — М/ Русская редакция, 2010. —
896 с.

16.	Мартин Р Чистый код. Создание, анализ и рефакторинг. — СПб.: Пи-
тер, 2011 — 464 с.
17.	Орлик С. Конструирование программного обеспечения // Основы про-
граммной инженерии (SWEBOK). [Электронный ресурс] — URL: http://
swebok.sorlik.ru/3_software_construction.html.

18.	Пименов М. Программирование на основе прототипов: понятие и
смысл. — 2009. [Электронный ресурс] — URL: http://b.onchallenge.
ru/2009/05/prototype.html.

19.	Приемы объектно-ориентированного проектирования. Паттерны про-
ектирования / [Э. Гамма и др.]. — СПб.: Питер, 2007. — 366 с.

20.	Симан Марк. Внедрение зависимостей в .NET. — Питер, 2014. —
464 с. - ISBN: 978-5-496-00657-6.

21.	Фаулер М Рефакторинг. Улучшение существующего кода. — М.: Сим-
вол-Плюс, 2008. — 432 с.

22.	Хант Э., Томас Д. Программист-прагматик. Путь от подмастерья к мас-
теру. — М.: Лори, 2009. — 270 с.

23.	Хьюз Дж., Мичтом Дж. Структурный подход к программированию. —
М.: Мир, 1980.- 280 с.

24.	Joseph М. Firestone Dimensional Modeling and E-R Modeling In The Data
Warehouse., 1998 r. — 9 с. [Электронный ресурс]. — URL: http://www.
dkms.com/papers/dmerdw.pdf.

25.	Scott Millett, Nick Tune. Patterns, Principles, and Practices of Domain-Driven
Design, 2015, Wrox. - ISBN: 978-1-118-71465-2.
Глава 7

ТЕСТИРОВАНИЕ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

7.1.	Основы тестирования

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

Процесс разработки П П с точки зрения тестирования выглядит
следующим образом (рис 7.1). Отдел разработки бизнес-требований
предоставляет группе тестирования и отделу разработки два доку-
мента: описание бизнес-логики выпускаемого продукта и описание
функционального дизайна.

Бизнес-логика выпускаемого продукта описывает процессы, кото-
рые должен обрабатывать проектируемый продукт, с точки зрения
конечного пользователя.

Функциональный дизайн в общем виде описывает функции, кото-
рые должен выполнять проектируемый продукт, а также может со-
держать описание интерфейса и требования к нему пользователя.

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

Тест план — документ, описывающий весь объем работ по тести-
рованию, начиная с описания объекта, стратегии, расписания, кри-
териев начала и окончания тестирования, до необходимого в про-
цессе работы оборудования, специальных знаний, а также оценки
рисков с вариантами их разрешения.

Тестовые сценарии — описание начальных условий, входных дан-
ных, действий пользователя и ожидаемого результата.

Тест-кейсы — описание совокупности шагов, конкретных
условий и параметров, необходимых для проверки реализации тести-
руемой функции или ее части.

Эти документы служат основой для дальнейшего тестирования
продукта. Одновременно с работой группы тестирования програм-
мисты пишут код ПП. Когда код становится относительно стабиль-
ным, тестировщикам выдается версия ПП. В ходе выполнения тестов
обнаруживаются дефекты, программисты их исправляют, выпускают
новую версию ПП и выдают ее на тестирование. Так продолжается
до тех пор, пока ПП не приобретает должный уровень качества или
не подходит срок окончательного релиза.

Процесс тестирования системы включает в себя выполнение че-
тырех стадий.

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

3.	«Позитивное» тестирование. На этой стадии необходимо про-
верить результат работы приложения при получении им «правиль-
ных» входных данных

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

Рассмотрим эти стадии более подробно.

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

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

Далее осуществляется процесс тестирования, который можно опи-
сать как следующую пошаговою процедуру:

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

3)	далее проверьте работу приложения при вводе данных, кото-
рые не входят в область допустимых значений (проверка обработки
некорректных входных значений).

В первых двух пунктах описан процесс, который называется «по-
зитивным» тестированием.

«Позитивное» тестирование — это тестирование на данных или
сценариях, которые соответствуют нормальному (штатному, ожида-
емому) поведению проверяемой системы. Основной целью «пози-
тивного» тестирования является проверка того, что при помоши
системы можно делать то, для чего она создавалась.

Последний пункт описывает процесс «негативного» тестирование.

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

Предшествовать «позитивному» и «негативному» тестированию
должны работы по выполнению «дымового» тестирования.

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

Как нужно расставлять приоритеты при тестировании? «Пози-
тивное» тестирование считается на порядок более важным, чем «не-
гативное». Предположим, что система не слишком устойчива к «пло-
хим» вводимым данным. Это страшно? Зачастую не слишком. Поль-
зователи могут научиться обходить «подводные камни», не будут
делать «опасные» или «неразрешенные» действия, служба техниче-
ской поддержки скоро запомнит, какие проблемы обычно возникают
у пользователей, и будет давать советы типа «ни в коем случае
не оставляйте это поле пустым, а то,,.». Но если система не выпол-
няет свое основное предназначение, если пользователи (заказчики)
не могут решить свои бизнес-задачи, если они все делают правильно,
вводят хорошие дачные, но не получают результата, то с такой сис-
темой никто работать не захочет. Такая система не выполняет своего
основного предназначения. Поэтому «позитивное» тестирование
гораздо важнее «негативного».

7.2.	Виды тестирования

В настоящее время существует множество видов тестирования,
ниже описаны наиболее распространенные.

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

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

Пример 7.1. Для работы интернет-магазина по продаже сотовых
телефонов можно сформировать следующий вариант нагрузочного
тестирования.

Интернет-магазин рассчитан на одновременную работу 100 поль-
зователей Система нагрузочного тестирования должна эмулировать
работу этих пользователей по следующим сценариям: 25 пользова-
телей просматривают товары и выходят из системы; 25 пользователей
добавляют товар в корзину и выходят из системы; 25 пользователей
используют функцию возврата товара и выходят из системы; 25 поль-
зователей входят в систему и не проявляют никакой активности. На-
грузочное тестирование должно эмулировать одновременную работу
всех этих пользователей по заданному сценарию. При работе теста
необходимо замерять параметры производительности сервера, кото-
рые покажут, как он справляется с нагрузкой, и позволят выявить
причины ее снижения, если оно будет замечено.

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

Стресс-тестирование — вид тестирования ПО, которое оценивает
надежность и устойчивость системы в условиях превышения преде-
лов нормального функционирования. Стресс-тестирование особенно
необходимо для «критически важного» ПО. Стресс-тестирование
обычно лучше обнаруживает такие качества, как устойчивость, до-
ступность и способность к обработке исключений системой под
большей нагрузкой, чем та, что считается корректным поведением
в нормальных условиях. В общем случае стресс-тестирование осно-
вано на снятии и анализе показателей производительности прило-
жения при нагрузках, значительно превышающих ожидаемые на ста-
дии сопровождения, и его целью является определение выносливо-
сти или устойчивости приложения в случае всплеска активности его
использования.

Пример 7.2. Для интернет-магазина по продаже сотовых телефо-
нов, если он рассчитан на 100 одновременно работающих пользова-
телей, запускается нагрузочный тест, который эмулирует одновре-
менную работу' двухсот пользователей.

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

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

Тестирование безопасности направлено на оценку уязвимости
ПО к различным атакам. Компьютерные системы очень часто яв-
ляются мишенью незаконного проникновения, под которым пони-
мают широкий диапазон действий: попытки хакеров проникнуть
в систему из спортивного интереса; месть рассерженных служащих;
взлом мошенниками для незаконной наживы и т.д. Тестирование
безопасности проверяет фактическую реакцию защитных механиз-
мов, встроенных в систему, на деструктивные действия. В ходе те-
стирования безопасности испытатель играет роль взломщика
и предпринимает различные действия незаконного характера: по-
пытки узнать пароль с помощью внешних средств; атаку на систему
с помощью специальных утилит, анализирующих степень ее за-
щиты; подавление, ошеломление системы (в надежде, что она от-
кажется обслуживать других клиентов); целенаправленное введение
ошибок в надежде проникнуть в систему в ходе восстановления;
просмотр несекретных данных в надежде найти ключ для входа
в систему и пр.

При неограниченном времени и ресурсах тестирование безопас-
ности может взломать любую систему. Задача проектировщика сис-
темы — сделать цену проникновения более высокой, чем цена полу-
чаемой в результате информации.

Проверка совместимости. Основной целью данного тестирования
является проверка корректной работы ПП в определенном окруже-
нии, в качестве которого может выступать, например, аппаратная
платформа, сетевые устройства, периферийные устройства (прин-
теры, CD/DVD-приводы, Web-камеры и пр.), операционная система
(Windows, Unix, MacOS и т.д.), базы данных (Oracle, MS SQL, MySQL
и т.д.), системное программное обеспечение (Web-сервер, фаервол,
антивирус и т.д.), браузеры (Internet Explorer, Firefox, Opera, Chrome,
Safari и т.д.).

Автоматизированное тестирование является частью общего про-
цесса тестирования, которое использует программные средства для
выполнения тестов и проверки результатов выполнения, что помогает
сократить время тестирования и упростить его процесс. Существует
два основных подхода к автоматизации тестирования: тестирование
на уровне кода и тестирование пользовательского интерфейса. К пер-
вому типу относится, в частности, модульное тестирование. Ко вто-
рому — имитация действий пользователя с помощью специальных
систем тестирования.

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

Одной из главных проблем автоматизированного тестирования
является его трудоемкость: несмотря на то что оно позволяет устра-
нить часть рутинных операций и ускорить выполнение тестов, боль-
шие ресурсы могут тратиться на обновление самих тестов, и это от-
носится к обоим видам автоматизации. Автоматизация всех испыта-
ний — очень дорогой процесс, и потому автоматическое
тестирование является лишь дополнением ручного тестирования.
Автоматические тесты не могут полностью заменить ручное тести-
рование.

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

Модульное тестирование не позволяет отловить все ошибки
в программе. Это следует из практической невозможности трасси-
ровки всех возможных путей выполнения программы, за исключе-
нием простейших случаев. Кроме того, происходит тестирование
каждого из модулей по отдельности. Это означает, что ошибки ин-
теграции, системного уровня, функций, исполняемых в нескольких
модулях, не будут определены. Кроме того, данная технология бес-
полезна для проведения тестов на производительность. Таким обра-
зом, модульное тестирование более эффективно в сочетании с дру-
гими методиками. Необходимо отметить, что для написания тестов
может понадобиться написать больше кода, чем будет в самой прог-
рамме. Например, каждое возможное значение логической перемен-
ной потребует двух тестов: один на вариант true; другой — на вариант
false. В результате на каждую строку исходного кода потребуется
3—5 строк тестового кода.

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

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

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

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

Считается хорошей практикой при исправлении ошибки создать
тест на нее и регулярно прогонять его при последующих изменениях
программы. Хотя регрессионное тестирование может быть выпол-
нено и вручную, но чаще всего это делается с помощью специализи-
рованных программ, позволяющих выполнять все регрессионные
тесты автоматически.

7.3.	Работа с ошибками

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

Главный компонент такой системы отслеживания ошибок — база
данных, содержащая сведения об обнаруженных дефектах.

В общем случае состав информации об ошибке, хранимой в базе
данных, включает в себя следующие параметры:

•	номер (идентификатор) дефекта;

•	кто сообщил о дефекте;

•	дату и время, когда был обнаружен дефект;

•	версию продукта, в которой обнаружен дефект;

•	серьезность (критичность) дефекта и приоритет решения;

•	описание шагов для выявления дефекта (воспроизведения непра-
вильною поведения программы);

•	кто ответственен за устранение дефекта;

•	обсуждение возможных решений и их последствий;

•	текущее состояние (статус) дефекта;

•	версию продукта, в которой дефект исправлен.

Развитые системы также предоставляют возможность прикреп-
лять файлы, помогающие описать проблему.

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

Рис. 7.2. Жизненный цикл ошибки

Статус «Новый» определяет, что дефект зарегистрирован тести-
ровщиком.

После назначения ответственного за исправление дефекта
ошибка переходит в статус «Назначен».

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

Далее тестировщик проводит проверку исправлений, в результате
которой дефект либо снова переходит в статус «Назначен» (если он
описан как исправленный, по не исправлен), либо в статус «Закрыт».

Статус «Открыт повторно» свидетельствует о том, что дефект
вновь найден в другой версии.

В корпоративной среде система отслеживания ошибок может ис-
пользоваться для получения отчетов, показывающих продуктивность
программистов при исправлении ошибок. Однако часто такой под-
ход не дает достаточно точных результатов, из-за того что разные
ошибки имеют различную степень серьезности и сложности. При
этом серьезность проблемы не имеет прямого отношения к сложно-
сти устранения ошибки.
7.4.	Тестирование с использованием
тест-комплектов

Тест-комплект или «тест-кейс» является наиболее простым
и распространенным вариантом тестирования ПО.

Пример 7.3. Принцип работы с «тест-кейсами» можно объяснить
на следующем примере. Пусть для того, чтобы купить товар в интер-
нет-магазине по продаже сотовых телефонов, нужно выполнить сле-
дующие действия.

1.	Зайти на сайт магазина.

2.	Найти товар через поиск.

3.	Нажать кнопку «Добавить в корзину».

4.	Перейти в «Корзину».

5.	Произвести оплату товара.

6.	Получить по электронной почте письмо с подтверждением по-
купки и описанием условий доставки.

Каждая из этих шести строк списка входит в состав «тест-кейса».
Сам список является тест-комплекгом. Процесс придумывания и на-
писания каждой строки списка называется созданием «тест-кейса».
Процесс проверки действий, описанных в «тест-кейсе», называется
исполнением «тест-кейса». Главной и неотъемлемой частью «тест-
кейса» является ожидаемый результат, например: «При нажатии
на ссылку с товаром должна открыться Web-страница с его описа-
нием». Тест-комплект может полностью состоять из ожидаемого ре-
зультата.

Структура тест-комплекта включает в себя следующие эле-
менты.

Шаги — это инструкция по выполнению теста.

Исполнение шагов — пошаговое выполнение инструкции.

Ожидаемый результат — описание того, что должно случиться
после выполнения каждого шага инструкции.

Фактический результат — это то, что реально произошло после
выполнения проверяемого шага.

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

Пример 7.4. Предыдущий пример «тест-кейса» для интернет-ма-
газина по продаже сотовых телефонов можно расширить следующим
образом.
1.	Открыть в браузере www.lcstshop.ru.

2.	Ввести в поле поиска: «iphone 4s».

3.	Нажать на ссылку с названием телефона в результатах по-
иска.

4.	Нажать на кнопку «Купить» на странице описания телефона.

5.	Нажать на ссылку «Корзина».

6.	Нажать на кнопку «Оплатить».

7.	Ввести в поле «Адрес электронной почты»: «test@testmail.ru».

8.	Выбрать из выпадающего списка «Вид карты»: «VISA».

9.	Ввести в поле «Номер карты»: «9999-1234-5678-8888».

10.	Ввести в поле «Действительна до»: «11.15».

11.	Ввести в поле «Проверочный код»: «222».

12.	Нажать на кнопку «Оплатить».

13.	Проверить свою электронную почту на предмет получения
письма с информацией о заказе.

14	Проверить свой банковский счет на предмет списания суммы
стоимости телефона.

В данном «тест-кейсе» ожидаемые результаты описаны неявно,
но они есть. Например, на втором шаге предлагается ввести в поле
поиска название телефона. Если после ввода адреса сайта страница
не откроется, то второй шаг и весь оставшийся тест выполнить уже
не удастся. Следовательно, тест будет не выполнен по причине
ошибки. Либо может возникнуть другая ситуация: после ввода адреса
сайта успешно откроется его главная страница, но поля для поиска
там не будет, что тоже является ошибкой.

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

Также может возникнуть ситуация, когда тестировщик окажется
заблокированным, так как не сможет выполнить все шаги теста, на-
пример если на странице работы с содержимым корзины не будет
кнопки «Оплатить». В этом случае фиксируется ошибка — отсутствие
кнопки «Оплатить» и исполнения «тест-кейса» откладывается до ис-
правления этой ошибки.

7.5.	Программные срецства

В заключение в качестве справочного материала перечислим
программные средства отслеживания ошибок, автоматизации про-
цесса тестирования и системы непрерывной интеграции (табл. 7.1).
Таблица 7.1

Программные средства для тестирования ПО

Системы отслеживания ошибок	
свободно распространяемые	требующие оплаты лицензии
Redmine, BUGS — the Bug Genie  Bugzilla, eTraxis  GNATS, Mantis bug tracking system  Trac, Em Forge  Picket; Flyspray, DEVPROM  YouTrack	Atlassian J IRA  Bontq  PVCS Tracker  Project Kaiser TrackStudio Enterprise
Приложения для автоматизации тестирования	
HP LoadRunner, HP QuickTest Professional, HP Quality Center  Segue SilkPcrfoimcr  IBM Rational FunctionalTester, IBM Rational PerformanceTester IBM Rational TestStudio  SmartBear Software TestComplete	
Системы непрерывной интеграции	
BuildBot, Hudson или Jerikins, FinalBuilder, TeamCity	

Контрольные вопросы

1.	Какова структура процесса разработки ПП с точки зрения тестирова-
ния? Поясните каждый этап.

2.	Какая ос] юва для тестирован ия 11родукта закладывается на начальном
этапе?

3.	Что такое «дымовое» тестирование?

4	Что такое позитивное тестирование?

5.	Что такое негативное тестирование?

6.	Дайте определение функциональному, нагрузочному, стресс-тестиро-
ванию и тестированию стабильности.

7.	В чем заключается проверка эргономичности?

8.	В чем цель тестирования безопасности?

9.	Зачем нужна проверка совместимости?

10.	В чем достоинства и недостатки автоматизированного тестирова-
ния?

11.	Для чего предназначено модульное тестирование, какие у него досто-
инства и недостатки?

12.	В чем заключается системное тестирование?

13.	В чем закл ючается pei рессион ное тест ирование?

14.	Что такое «тест-кейс»? Опишите структуру «тест-кейса».

15.	Какие результаты могут быть после выполнения «тест-кейса»?
Литература

1.	Бейзер Б. Тестирование черного ящика. Технологии функционального
тестирования программного обеспечения и систем. — СПб.: Питер,
2004. - 320 с.

2.	Винниченко И.В. Автоматизация процессов тестирования. — СПб.: Пи-
тер, 2005. — 203 с.

3	Искусство тестирования программ / Гленфорд Майерс, Том Баджетт
и др. - М.: Вильямс, 2012. - 272 с. - ISBN 978-5-8459-1796-6, 978-1-
118-03196-4.

4	Кабертсон Р., Браун К., Кобб Г. Быстрое тестирование. — М. Вильямс,
2002.- 384 с.

5.	Канер С., ФолкД., Кек Нгуен Енг. Тестирование программного обеспе-
чения. Фундаментальные концепции менеджмента бизнес-приложе-
ний. — Киев: ДиаСофт, 2001. — 544 с.

6.	Каспин Л., Джанет Г. Гибкое тестирование: практическое руководство
для тестировщиков ПО и гибких команд. — М Вильямс, 2010. — 464 с.

7.	Котляров В П. Основы тестирования программного обеспечения. — М.:
Бином, 2006 — 285 с.

8	Лиза Криспин, Джанет Грегори. Гибкое тестирование. Практическое
руководство для тестировщиков ПО и гибких команд. — М.. Вильямс,
2016. - 464 с - ISBN 978-5-8459-1625-9, 978-0-321-53446-0.

9	Майерс Г., Баджетт Т., Сандлер К Исскусство тестирования прог-
рамм. — М.: Диалектика, 2012. — 272 с.

10.	Орлик С. Основы программной инженерии (по SWEBOK) // Тестиро-
вание. — 2016. [Электронный ресурс] — URL: http://swebok.sorlik.ra/4_
software_testing.html.

И Ошераув Рой. Искусство автономного тестирования с примерами на
С#. - ДМК Пресс, 2014. - 360 с. - ISBN 978-5-94074-945-5, 978-1-
61729-089-3.

12.	Портал об автоматизированном тестировании программного обеспе-
чения. [Электронный ресурс] — URL: http://automated-testing.info.

13.	Савин Р. Тестирование Дот Ком, или Пособие по жесткому обращению
с багами в интернет-стартапах. — М.: Дело, 2007. — 312 с.

14.	Синицын С В , Налютин Н Ю. Верификация программного обеспече-
ния. - М.: БИНОМ, 2008. - 157 с.

15.	Тестирование программного обеспечения: модульные тесты // Ореп-
Qualiiy га [Электронный ресурс] — URL: http://openquality.ru/software-
testing/unit-tests.php.

16.	Georgia Weidman. Penetration Testing: A Hands-On Introduction to Hacking,
No Starch Press, 2014, 531 p. - ISBN: 978-1-59327-564-8.
Глава 8

СОПРОВОЖДЕНИЕ
ПРОГРАММНЫХ СИСТЕМ

8.1. Базовые понятия

Сданный в эксплуатацию программный продукт в подавляющем
большинстве случаев будет изменяться, поскольку в нем не исклю-
чены дефекты, у его пользователей могут возникнуть новые требо-
вания, изменятся условия его эксплуатации и т.д. Весь спектр дея-
тельности, направленный на обеспечение эффективной (с позиции
затрат) поддержки программных систем, называется сопровождением
программного обеспечения (software maintenance).

Стандарт IEEE 1219 определяет сопровождение как модификацию
ПП после передачи в эксплуатацию для устранения сбоев, улучше-
ния показателей производительности и/или других характеристик
(атрибутов) продукта или его адаптацию для использования в моди-
фицированном окружении.

Стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р
ИСО/МЭК) определяет сопровождение как один из важных процес-
сов ЖЦ, направленный на модификацию ПП в части кода и доку-
ментации для решения возникающих в процессе эксплуатации
проблем или реализации потребностей в улучшениях характеристик
продукта.

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

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

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

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

При работе с заказчиком в обязанности инженеров службы со-
провождения входит: проверка пользовательского сценария, приво-
дящего к сбою; идентификация причин сбоя; устранение причин
сбоя или их обход (workaround); документирование всех работ и опе-
раций; внесение описания проблемы и ее решения в базу знаний
службы сопровождения; передача всей информации разработчикам;
информирование пользователя о статусе запроса на сопровождение.
Перечень этих работ может варьироваться в зависимости от корпо-
ративных стандартов.

В обязанности персонала входит выполнение следующих дей-
ствий:

•	поддержка контроля (управляемости) программной системы в те-
чение всего цикла ее эксплуатации;

•	поддержка модификации программной системы;

•	совершенствование существующих функций сопровождения;

•	предотвращение уменьшения производительности программной
системы до неприемлемого уровня.

Выполнение запросов на сопровождение ПП можно рассматри-
вать как его совершенствование (эволюцию). В результате ПП ста-
новится все более сложным в эксплуатации и сопровождении. Этот
процесс может продолжаться до тех пор, пока не будут разработаны
специальные мероприятия по уменьшению сложности ПП.

В этом контексте особый интерес представляют наследуемые сис-
темы (legacy systems), которые представляют собой ПП, созданные
однажды для какой-либо компании, используемые ею на протяже-
нии длительного времени (десятилетиями) и подвергающиеся неод-
нократной модификации в соответствии с операционным окруже-
нием и реальными бизнес-процессами.

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

Бизнес-процессы

Прикладное программное
обеспечение

Программные средства
поддержки

Аппаратные средства

Рис. 8.1. Многоуровневая модель наследуемой системы

С точки зрения сопровождения с унаследованными приложениями
возможны два действия: сопровождение продолжать и сопровож-
дение прекратить. Последнее действие может быть детализировано
следующим образом: заменить на новый ПП (купленный или разра-
ботанный самостоятельно); присоединить к новому приложению;
инкапсулировать и использовать как сервер (с использованием
образца проектирования Adapter).

Очевидно, что проектирование наследуемой системы будет отли-
чаться от системы, которая не предусматривает подобный механизм
модификации. Здесь можно использовать уже готовые решения
(если проектирование осуществляется на основе объектного под-
хода), например можно воспользоваться образцом проектирования
Adapter для получения нового приложения из исходного путем рас-
ширения или модификации последнего (метка z на рис. 8.2). Воз-
можно также использование инкапсуляции, в этом случае исходное
приложение практически не изменяется, новое приложение созда-
ется полностью независимо, но в процессе его выполнения вызы-
вается функциональность унаследованного приложения. Это может
256

Рис. 8.2. Использование унаследованных приложений
осуществляться как напрямую (метка ed), так и через класс-обертку
(метка ем).

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

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

С помощью javadoc можно внести в исходный код и получить сле-
дующую информацию о классах, переменных или методах:

•	сведения об авторе;

•	сведения о версии;

•	информацию о том, что возвращает метод;

•	информацию о параметрах метода;
Мое D-требование

Рис. 8.3. Прослеживание требований в различных частях проекта

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

•	сведения о том, что класс или член класса является устаревшим;

•	сведения о том, в каком выпуске было внесено определенное из-
менение.

Пример использования javadoc приведен в листинге 8.1.

Листинг 8.1

Пример использования средств javadoc

import java.io.* *;

/**

*Этот класс демонстрирует применение комментариев документации,

*@author Герберт Иилдт (Herbert Schiidt)
*0version 1.2

*/

public class SquareNum {
/**

*Этот метод возвращает квадрат числа.

*Это многострочное описание, используйте столько строк, сколько
необходимо.

*0param num Значение, которое необходимо возвести в квадрат.

*0return num Значение, возведенное в квадрат.

*/

public double square (double num) {
return num * num;

}

/**

*	Этот метод вводит число, полученное от пользователя.

*	0return. Введенное значение в виде double.

*	0exception В случае ошибки ввода генерируется исключение
lOException.

*	0see lOException

*/public double getNumber() throws lOException {

//Создает BufferReader с помощью System.in

InputStreamReader isr = new InputStreamReader (System, in.);

BufferedReader ii.Data = new BufferReader(isr);

String str;

}

/**

*	Этот метод цемонлстрирует square().

*	0param args He используется.

*	0exception В случае ошибки ввода ганенрируется исключение
lOException.

*	0see lOException

*/

public static void main(Strir.g args[])

throws lOException

{

SquareNum ob = new SquareNum();

double val;

System.out.printin(«Введите значение для возведения в квадрат; »);
val = ob.getNumber();
val = ob.square(val);

System.out.printin(«Значение в квадрате равно» + val);

}

}
8.2.	Организация и управление
процессом сопровождения

Организация процесса сопровождения подразумевает выполнение
следующих действий:

•	определение цели и состава процессов сопровождения;

•	определение причин и видов изменения программного средства
в процессе его сопровождения;

•	организация процессов и передача на сопровождение разработан-
ного программного средства;

•	заключение договора между заказчиком и исполнителем на со-
провождение программного средства;

•	разработка концепции методов и процессов сопровождения ПП;

•	разработка спецификации требований на модификации при со-
провождении программного средства;

•	утверждение заказчиком концепции, договора и технического
задания на сопровождение ПП;

•	организация контроля реализации концепции и договора на со-
провождение программного средства.

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

Существует несколько подходов к организации процесса сопровож-
дения. Один из них можно представить в виде схемы, изображенной
на рис. 8.4.

Здесь пп. 1.1—1.4 фактически относятся к этапу разработки и под-
разумевают под собой попытку предугадать направления будущих
изменений требований к ПП и учесть их в плане. Пункт 1.1 можно
реализовать посредством применения соответствующих образцов
проектирования. Пункт 1.2 легко реализуется через подробные ком-
ментарии и должное форматирование кода, облегчающее сопровож-
дение.

Пункт 2 предназначен для оценки объема и классификации работ
на сопровождение. Пункт 3 соответствует выбору с лужбы поддержки:
это может быть своя собственная служба или специальная сторонняя
компания. План сопровождения (п. 4) регламентирует поток запро-
сов на сопровождение внутри организации. Типичный план сопро-
вождения приведен на рис. 8.5.

Жирной линией отмечена номинальная последовательность об-
работки запросов. Отдел сопровождения получает от пользователей
Рис. 8.4. Организация процесса сопровождения

Стандартная	формал

ьные

ио^^лъ^^довательность	запросы ни ---Отдел маркетинга

,	сопровождение

Служба поддержки

Предлагаемые
запросы

Руководитель
службы
сопровождения

П о дтвержд енные

Совет

по контролю
изменений

Инженер
службы
сопровождения

Текущий исходный
код и документация

Отклоненные

Измененный код
и документация

Рис. 8.5. Типичная последовательность работ по сопровождению
или заказчиков предложения и жалобы, которые оформляются как
запросы на сопровождение. В дальнейшем разработчик принимает
решение о последующей реализации запросов и присваивает каж-
дому из них приоритет. Затем запросы обслуживаются техническим
персоналом службы сопровождения. Тонкие линии означают другие
последовательности появления и исчезновения запросов.

В общем случае порядок и длительность работ определяются мас-
штабами проекта, а сам процесс реализации запросов сопряжен
с двумя проблемами: доставкой готового кода пользователям и борьбой
с дефектами. Для устранения дефектов можно применять так называ-
емые исправления или заплатки (patch), суть которых заключается в из-
менениях кода, позволяющих либо устранить дефект, либо обойти его.
Возможный вариант работы с исправлениями представлен на рис.8.6.

Преимущества и недостатки исправлений представлены
в табл. 8.1. Исправления должны иметь временный характер: они

Рис. 8.6. Сопровождение и исправление
Таблица 8.1

Преимущества и недостатки исправлений

Преимущества	Недостатки
Быстрая удовлетворенность заказчиков	Дублирование работ: необходима реа- лизация как временного, так и постоян- ного исправления
Возможность непрерывной ра- боты и тестирования без широ- кого распространения дефектов	Иногда patch не заменяется соответ- ствующей версией программного про- дукта
Исключено скрытие других дефектов	Затруднен выпуск постоянного исправ- ления, предназначенного для устра- нения временного
Возможность тестировать ис- правление	Затруднен процесс документирования

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

Оценка затрат (см. п. 5 на рис. 8.5) более подробно будет рассмот-
рена далее.

Обработка запросов на сопровождение (соответствует п. 6
на рис. 8.5) включает в себя все стадии разработки ПО, однако ста-
новится необходимым процесс анализа влияния изменений на арте-
факты системы. Согласно проведенным исследованиям 19% дефек-
тов в приложении возникают на этапе определения требований,
52% — на стадии проектирования и 7% — в процессе программиро-
вания. Влияние устранения дефекта на артефакты иллюстрирует
рис. 8.7.

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

Работы по сопровождению рассмотрим в контексте некоторых
стандартов. В частности, стандарт IEEE1219 определяет следующие
работы' корректировка, адаптация и совершенствование, состоящие
из семи стадий, которые приблизительно соответствуют стадиям
процесса разработки. Это определение задачи, анализ, проектирова-
ние, реализация, системное тестирование, приемо-сдаточное тести-
рование и поставка. Каждая из стадий оперирует шестью одинако-
выми артефактами (рис. 8.8).
Рис. 8.7. Примеры влияния дефектов на процесс сопровождения
Стадия

Шесть атрибутов

1 Определение задачи

3. Проектирование

а.	Входные артефакты жизненного
цикла для данной стадии

б.	Процесс обработки входных данных

в.	Способы контроля обработки
входных данных

г.	Выходные артефакты жизненного
цикла

д.	Показатели качества выполнения
обработки

е.	Метрики для данной стадии

2. Анализ

4. Реализация

6. Приемка

5. Системное тестирование

7. Поставка

Рис. 8.8. Работы по сопровождению согласно стандарту IEEE1219
и их атрибуты

Стандарт ISO/IEC14764 {Standardfor Software Engineering) опери-
рует четырьмя составляющими:

1)	корректирующее сопровождение — «реактивная» модификация
ПП, выполняемая после передачи в эксплуатацию для устранения сбоев;

2)	адаптирующее сопровождение — модификация ПП на этапе
эксплуатации для обеспечения продолжения его использования с за-
данной эффективностью в условиях изменений бизнес-окружения,
порождающих новые требования к системе;

3)	совершенствующее сопровождение — модификация ПП на этапе
эксплуатации с целью повышения характеристик производитель-
ности и удобства сопровождения;

4)	профилактическое сопровождение — модификация ПП на этапе
эксплуатации для идентификации и предотвращения скрытых де-
фектов до их проявления в реальных сбоях.

Стандарт ISO/IEC14764 классифицирует адаптивное и совершен-
ствующее сопровождение как работы по расширению функциональ-
ности продукта, а корректирующую и профилактическую деятель-
ности — как корректировку системы. Таким образом, согласно ISO/
IEC14764 все работы по сопровождению можно разбить на катего-
рии, реализующие «проактивный» и «реактивный» подходы
(табл. 8.2). Исследования показали, что 60—80% объема работ отно-
сятся к усовершенствованию приложения.

Стандарт ISO/IEC14764 уточняет положения по сопровождению
ПП стандарта ЖЦ ПП ISO/IEC12207, а в отличие от IEEE1219 ра-
боты в нем сгруппированы несколько иначе (рис. 8.9).
Виды сопровождения

Таблица 8.2

Рис. 8.9. Процесс сопровождения по стандарту 1SO/1EC14764

Технические вопросы процесса солровсждения. Особое внимание
следует уделить ряду технических вопросов, касающихся процесса
сопровождения, которые можно разделить на следующие группы:
ограниченное понимание ПС, тестирование, анализ влияния, воз-
можность сопровождения. Рассмотрим их подробнее.

Ограниченное понимание ПС связано в первую очередь с тем, что
специалисты по сопровождению, как правило, не занимались разра-
боткой сопровождаемого ПО. Поэтому до 60% усилий может быть
потрачено на анализ и понимание сопровождаемого ПП. На данном
этапе определяющим фактором является наличие качественной
(в плане соответствия реальному состоянию кода и полноте содер-
жания) документации к ПП. Затраченные на понимание программ-
ной системы усилия можно уменьшить, если использовать соответ-
ствующие методологии (например, UML 2.0) или инструменты (на-
пример, обеспечивающие обратный инжиниринг для полного
соответствия модели и программного кода) Важно также приводить
в согласованность документацию с изменениями, внесенными при
реализации запросов на сопровождение
При работах по сопровождению возможно распространение так
называемой ряби, когда многочисленные незначителвные изменения
различных частей ПП при определенных условиях приводят к неаде-
кватной работе системы в целом. В этом случае есть смысл провести
выборочное регрессионное тестирование.

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

Цели анализа влияния можно сформулировать следующим обра-
зом:

•	определение содержания изменений для работ по планированию
и реализации;

•	получение максимально возможной оценки ресурсов, необходи-
мых для проведения соответствующих работ;

•	анализ стоимости и выгоды от внесения запрошенных изменений
(обычно касается пожеланий в запросах на расширение системы);

•	обсуждение сложности вопросов, связанных с внесением соот-
ветствующих изменений.

Сложность реализации соответствующего запроса на сопровож-
дение часто является основным фактором, определяющим сроки
и способы решения проблемы. Если система изначально разрабаты-
валась с учетом дальнейшей поддержки (например, использовались
соответствующие образцы проектирования), то осуществить анализ
влияния значительно легче.

Возможность сопровождения в IEEE (стандарт 610.12-90, обнов-
ленный в 2002 г.) определяется как легкость сопровождения, расши-
рения, адаптации и корректировки для удовлетворения заданных
требований. Стандарт ISO/IEC9126-01 определяет возможность со-
провождения как одну из характеристик качества.

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

Управление процессом сопровождения. Управленческие вопросы
можно разделить на следующие группы: согласование с ооганизаци-
онными целями, кадровое обеспечение, организация процесса со-
провождения, организационные аспекты сопровождения, аутсор-
синг.

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

Проблемы кадрового обеспечения связаны с тем, что инженеры
по сопровождению, как правило, считаются в компаниях-разработ-
чиках специалистами «второго класса», поэтому часто возникают
проблемы с удержанием квалифицированного персонала в отделах
сопровождения.

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

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

Аутсорсинг подразумевает полную передачу непрофильных работ
сторонним организациям. Лишь незначительная часть крупных кор-
пораций использует аутсорсинг и только для некритичных компо-
нентов, выполняющих не очень важные бизнес-функции, поскольку
они не хотят терять контроль над ассоциированными с этими систе-
мами данными или функциональностью. К тому же сама процедура
передачи системы на внешнее сопровождение не отражена в стан-
дартах, что затрудняет документальное определение предоставля-
емых аутсорсером сервисов.
Поскольку реализация запроса на сопровождение есть процесс,
охватывающий практически все аспекты разработки, то применение
общих (для всего ЖЦ ПП) метрик, разработанных SEI CMU (Soft-
ware Engineering Institute, Carnegie-Mellon University), считается адек-
ватным. Эти метрики охватывают такие аспекты, как размер, усилия,
расписание и качество.

Инструменты процесса сопровождения. Важным моментом при
организации процесса сопровождения является выбор инструментов,
поддерживающих работы по сопровождению.

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

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

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

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

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

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

Существует следующие подходы к определению реинжиниринга.

1.	Реинжиниринг — это повторная реализация наследуемой сис-
темы с целью повышения удобства ее эксплуатации и сопровож-
дения.

2.	Реинжиниринг — это детальная оценка и перестройка ПО для
формирования понимания, воссоздания (на уровне модели и, в ряде
случаев, требований) и дальнейшей реализации его функциональ-
ности в новой форме. Сам реинжиниринг проводится не столько для
улучшения возможностей сопровождения, сколько для замены ста-
рого ПО новыми версиями.

3	Реинжиниринг ПО в ряде случаев связывается с реинжини-
рингом какого-либо бизнес-процесса (BPR — Buisness Process Reen-
gineering). Последний характеризуется совершенствованием внут-
ренних процессов, протекающих внутри фирмы или ее структурных
подразделений, что обязательно приведет к модификации обслужи-
вающего их ПО.

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

Значительными плюсами реинжиниринга являются снижение
рисков (система не разрабатывается заново, поэтому все крупные
риски уже учтены) и снижение затрат (ренжиниринг обходится де-
шевле разработки новой системы примерно в 4 раза). Основное раз-
личие между инжинирингом и разработкой новой системы связано
со стартовой точкой начала работ (рис. 8.10).

Один из возможных вариантов организации реинжиниринга пред-
ставлен на рис. 8.11, где выделены следующие основные этапы:
Традиционная
разработка ПО

Реинжиниринг ПО

Рис. 8,10. Традипионная разработка и реинжиниринг

Рис. 8.11. Процесс реинжиниринга

перевод исходного кода — конвертирование программы со ста-
рого языка программирования на его новую версию или другой
язык;

анализ программ — документирование структуры и функцио-
нальных возможностей npoipaMM на основе их анализа;
•	модификация структуры программ — изменение управляющей
структуры программ для их упрощения и лучшего понимания;

•	разбиение программ на модули — группировка взаимосвязанных
частей программ в модули для устранения избыточности и опти-
мизации их структуры, функциональности и интерфейса;

•	изменение системных данных — приведение данных, с которыми
работает программа, в соответствие с нововведениями, например
изменением типа БД, с которой работает система.

Второй подход характеризуется перепланированием приложения,
когда программные продукты, взятые за базу, перепроектируются
в соответствии с изменившимися требованиями, например адапти-
рованная ролевая игра может являться частью системы для обучения
менеджменту, выполняющей моделирование взаимодействия обуча-
емых в рамках тестовых примеров (рис. 8.12).

Рис. 8.12. Реинжиниринг ролевой видеоигры для обучения менеджменту

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

Пример 8.1. Рассмотрим пример анализа задачи по сопровож-
дению программной системы, предназначенной для интернет-мага-
зина.

Пусть это будет запрос на сопровождение под номером 155, суть
которого заключается в следующем. Пользователю (покупателю) не-
обходимо знать стадию выполнения заказа, чтобы сориентироваться
в сроках его выполнения. Эта информация нужна также группе ана-
литиков, занимающихся исследованием. Кроме того, им нужна ин-
формация о скорости обработки заказов для выявления узких мест
и совершенствования бизнес-процессов.

Средством контролирования заказов является использование ста-
туса заказов в следующем порядке (градации).

1.	Условно принят — статус присваивается оформленным по пре-
доплате заказам и сохраняется до момента поступления денежных
средств.

2.	Ожидает начала обработки — заказ принят и ожидает под-
тверждения со стороны сотрудника магазина.

3	В обработке — заказ обрабатывается и находится в состояниях,
описываемых следующими статусами.

3.1.	Ждем поставку со склада.

3.2.	На складе.

3.3.	Отправление — заказ упаковывается в посылку; в свою оче-
редь, имеет статусы:

•	комплектуется;

•	передано на упаковку;

•	ожидает отправки в службу доставки;

•	доставляется;

•	доставлено, получено;

•	аннулировано.

4.	Все отправления доставляются — все товары (кроме аннули-
рованных; отправлены.

5.	Выполнен — обработка заказа завершена.

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

В метриках IEEE запрос на сопровождение номер 155 можно оха-
рактеризовать следующим образом

1.	Изменения затронут следующие составляющие: требуется мо-
дификация только одного класса, в нем следует добавить 14 методов.

2.	Оценочная величина трудозатрат по запросу 155: от 3 до
5 чел.-мес.

3.	Оценка фактической продолжительности по запросу 155: осуще-
ствляется по фактическим данным аналогично иным трудозатратам.

8.3.	Ресурсы, необходимые для сопровождения

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

Прогнозирование ресурсов, необходимых для сопровождения
(а именно: труда, времени, количества специалистов), осложняется
тем, что затраты на изменения состоят из двух принципиально раз-
личных частей. Первая часть (обычно наименьшая) — затраты на об-
наружение и устранение дефектов и ошибок в поставленной про-
граммной системе — имеет вероятностный характер, поскольку на-
личие подобных изъянов зависит от трудноучитываемых факторов
(квалификации разработчиков, инструментария и пр.). Вторая часть
изменений регламентирована целеустремленным совершенствова-
нием и упорядоченными модификациями версий ПП, масштаб ко-
торых можно прогнозировать.

Стоимость сопровождения определяется усилиями, затраченными
на понимание существующего кода системы и на разработку нового
в рамках запроса на сопровождение, стоимость которого можно оце-
нить по известной методике (например, СОСОМО 2). На стоимость
сопровождения в целом могут оказать влияние следующие факторы:
• тип приложения;

•	новизна программного обеспечения;

•	наличие и квалификация персонала по сопровождению;

•	длительность использования программной системы;

•	характеристики и специфика аппаратной части, телекоммуника-
ционной инфраструктуры;
•	качество дизайна (например, модульность или масштабиру-
емость), кода, документации и соответствующих работ по тести-
рованию системы.

На стоимость сопровождения влияет также сложность системы
и ее компонентов, чем сложнее система, тем дороже ее сопровож-
дение. Поэтому важно также осуществить прогнозирование количе-
ства запросов на изменение системы при ее разработке. При этом
следует учитывать связь системы с внешним окружением — для
систем, находящихся в сложной взаимозависимости с внешним
окружением, изменение последнего обязательно повлияет на сис-
тему. Для адекватной оценки этой взаимозависимости необходимо
оценить следующие показатели:

•	количество и сложность системных интерфейсов (чем больше
системных интерфейсов и чем более сложными они являются,
тем выше вероятность изменений в будущем);

•	количество изменяемых системных требований;

•	бизнес-процессы, в которых используется данная система
(по мере развития бизнес-процессов появляются изменения
в требованиях).

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

Для оценки трудозатрат на сопровождение (и стоимости сопро-
вождения) может служить доля комментариев в общем числе строк
сопровождаемого кода. Вычислить долю комментариев можно либо
с помощью специальной программы, либо взяв произвольный
участок кода сопровождаемого модуля. Пример оценки трудозатрат
на сопровождение на основе комментариев представлен на рис. 8.13.

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

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

Многие проекты завершились неудачей из-за недооценки стои-
мости сопровождения. Наиболее известны две методики оценки
стоимости сопровождения', на основе параметрических моделей (ме-
тод функциональных точек, см. стандарт IEEE 14143.1-00) и на ос-
□ Размер модуля в процентах от общего числа строк
□ Доля строк без комментариев в модуле

Рис. S.13. Пример оценки трудозатрат на сопровождение
на основе комментариев

нове опыта (привлекается экспертное мнение для уточнения оценки,
сделанной по предыдущей методике).

Можно осуществить оценку стоимости запроса на сопровождение
на основе специальной таблицы, пример которой представлен
в табл. 8.3, где отражены все этапы его выполнения и затрачиваемые
на их реализацию человеко-дни. Если стоимость одного человеко-
часа составляют 50—100 руб., то затраты на изменение программы
составят 5600—28 000 руб.

Таблица 8.3

Длительность операций сопровождения

Операция	Длительность (чел.-дн.)	Операция	Длительность (чел.-дн.)
1 Уточнение проб- лемы и выявление функций,подлежа- щих изменению или добавлению	2-5	6. Компиляция и интеграция	2-3
2. Разработка необхо- димых изменений	1—4	7. Тестирование функциональности измененных компо- нентов	2-4
Окончание табл. 8.3

Операция	Длительность (чел.-дн.)	Операция	Длительность (чел.-дн.)
3. Анализ влияния факторов	1-4	8. Регрессионное тестирование	2-4
4. Внесение измене- ний в исходный код	1-4	9. Выпуск новой вер- сии и отчет о резуль- татах	1
5. Изменение SRS, SDD, STP, сведений о конфигурации	2-7	Итого	14-36

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

Контрольные вопросы

1.	Что такое сопровождение ПО?

2.	Какие виды работ выполняются при сопровождении?

3.	Какие основные стандарты используются при организации сопровож-
дения?

4.	Как влияет полнота документации на трудоемкость сопровождения?

5.	Как влияет качество управления конфигурациями на трудоемкость про-
цесса сопровождения?

6.	Какие виды работ выполняются при осуществлении сопровождения?

7.	Какие ресурсы необходимы для сопровождения?

8.	Возможно ли осуществлять сопровождение ПО силами сторонних ор-
ганизаций, не принимавших участия в его создании?

9.	Чем реинжиниринг отличается от обычного процесса разработки?

10	Как можно оценить трудозатраты на сопровождение?

Литература

1.	Брауде Э. Технология разработки программного обеспечения. — СПб.:
Питер, 2004. — 655 с.

2.	Кагарлицкий Ю.В. Разработка документации пользователя программ-
ного продукта. Методика и стиль изложения: 2-е изд. — Философт сер-
висы, 2012. — 228 с.

3.	Липаев В В. Программная инженерия сложных заказных продуктов:
учебное пособие. — М.: МАКС Пресс, 2014 — 312 с.
4.	Орлик С. Сопровождение программного обеспечения // Основы прог-
раммного обеспечения по SWEBOK- сайт. [Электронный ресурс] —
URL: http://swebok.sorlik.ru/5_software_majntenance.htmJ.

5.	Саммервилл И. Инженерия программного обеспечения: 6-е изд. — М.:
Вильямс, 2002. — 624 с.

6.	Шилдт Г. Java 2. Наиболее полное руководство. — СПб.: БХВ-Петер-
бург, 2009. — 1102 с.

7.	Glass R. Maintenance: Less is Not More. — IEEE Software, 1998.

8.	Pigoski Thomas. Practical Software Maintenance: Best practices for managing
your software investment. — New York : John Wiley & Sons, 1996.

9.	Weiss D.M. Evaluating software development by analysis of change data. —
NASA Software Engineering laboratory, 1981. — SEL-80-011.
Глава 9

КАЧЕСТВО

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

9.1.	Основы качества программного обеспечения

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

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

Качество ПО является предметом стандартизации. Согласно
ГОСТ 2844-94 качество ПО есть совокупность свойств (показателей
качества) ПО, которые обеспечивают его способность удовлетворять
потребности заказчика в соответствии с его назначением. Этот стан-
дарт регламентирует базовую модель качества и показатели, главным
среди которых является надежность. Стандарт ISO/IЕС 12207 опре-
Рис. 9.1. Область знаний «Качество программного обеспечения»

делил не только основные процессы ЖЦ разработки ПО, но и орга-
низационные и дополнительные процессы, которые регламентируют
инженерию, планирование и управление качеством ПО.

Согласно этому стандарту на всех этапах ЖЦ разработки ПО дол-
жен проводиться следующий контроль качества ПО.

•	проверка соответствия требований проектируемому программ-
ному продукту и критериев их достижения;

•	верификация и аттестация (валидация) промежуточных резуль-
татов ПО на этапах ЖЦ и измерение степени удовлетворения до-
стигаемых показателей;

•	тестирование готового ПО, сбор данных об отказах, дефектах
и других ошибках, обнаруженных в системе;

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

•	оценка показателей качества, заданных в требованиях на разра-
ботку ПО.
Инспектирование качества — это процесс проверки качества, ори-
ентированный на команду разработчиков. Он применяется на всех
этапах разработки ПП,

Доказательство правильности — это математическая или логиче-
ская методика, используемая для убеждения себя и других в том, что
программа делает то, что должна делать. Такое доказательство явля-
ется формальным (строгим) методом.

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

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

Качество ПО является относительным понятием, имеющим
смысл только при учете реальных условий его применения, и требо-
вания, предъявляемые к качеству, должны соотноситься с этими
условиями и конкретной областью их применения.
Качество ПО характеризуется тремя аспектами: качеством ПП,
качеством процессов ЖЦ и качеством сопровождения или внедрения
(рис. 9.2).

Качество	Качество	Качество

процесса	продукта	сопровождения

Рис. 9.2. Основные аспекты качества ПО

Аспект, связанный с процессами Ж И ПО, определяет степень фор-
мализации, достоверности самих процессов ЖЦ разработки ПО,
а также верификацию и валидацию (кратко — V&V) промежуточных
результатов этих процессов Поиск и устранение ошибок в готовом
ПО проводится методами тестирования, которые снижают количе-
ство ошибок и повышают качество этого продукта.

Качество /7/7 достигается за счет использования процедур конт-
роля промежуточных продуктов на всех этапах их ЖЦ, проверкой их
на достижение необходимого качества, а также использованием ме-
тодов сопровождения П П. Эффект от внедрения программного сред-
ства в значительной степени зависит от знаний обслуживающего
персонала функций продукта и правил их выполнения

Модель качества ПО имеет четыре уровня представления.

Первый уровень соответствует определению характеристик (пока-
зателей) качества ПО, каждая из которых отражает отдельную точку
зрения пользователя на качество. Согласно существующим стандар-
там (ISO/IEC9126, ДСТУ 2844-1994, ДСТУ 2850-1994, ДСТУ 3230-
1995) в модель качества входит шесть характеристик или шесть пока-
зателей качества (рис. 9.3) функциональность (functionality), надеж-
ность (realibility), удобство (usability), эффективность (efficiency),
сопровождаемость (maitainnability), переносимость (portability).

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

Третий уровень предназначен для измерения качества с помощью
метрик, каждая из которых, согласно стандарту ISO/IEC9126, опре-
деляется как комбинация метода измерения атрибута и шкалы изме-
рения его значений. Для оценки атрибутов качества на этапах ЖЦ
ПО (при просмотре документации и программ, а также результатов
тестирования программ) используются метрики с заданным оценоч-
Показатели-характеристики

О
С



Атрибуты

			Полнота функций
			Точность
Функциональность			Интероперабельность
			Защищенность
			Согласованность
			Завершенность
Надежность			Отказоустойчивость
			Восстанавливаемость
			Согласованность
			Понимаемость
Удобство применения			Обучаемость
			Привлекательность
			Согласованность
			Анализируемость
			Изменяемость
Сопровождаемость			Стабильность
			Тестируемость
			С огласованность
			Реактивность
Эффективность			Используемость ресурсов
			Согласованность
			Адаптируемость
			Простота настройки
Переносимость			Совместимость
			Заменяемость
			Согласованность

Рис. 9.3. Модель характеристик качества
ним весом для нивелирования результатов метрического анализа
совокупных атрибутов конкретного показателя и качества в целом.
Атрибут качества определяется с помощью одной или нескольких
методик оценки на этапах ЖЦ ПО и на завершающем этапе его раз-
работки.

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

Выбранные атрибуты и их приоритеты отражаются в требованиях
на разработку системы, либо используются соответствующие прио-
ритеты эталона класса ПО, к которому это ПО относится.

Рассмотрим более подробно показатели качества ПО.

Функциональность. Это совокупность свойств, определяющих
способность ПО выполнять перечень функций в заданной среде в со-
ответствии с требованиями к обработке и требованиями к общесис-
темным средствам. Под функцией понимается некоторая упорядо-
ченная последовательность действий для удовлетворения потреби-
тельских свойств ПО Функции бывают целевые (основные)
и вспомогательные. Приведем атрибуты, которые относятся к функ-
циональности.

Функциональная полнота — свойство компонента ПО, которое
показывает степень достаточности основных функций для решения
задач в соответствии с назначением ПО.

Правильность (точность) — атрибут, который показывает степень
достижения правильных результатов.

Интероперабельность — атрибут, который показывает возмож-
ность взаимодействия компонентов ПО на специальных системах
и средах (ОС, сети и пр.).

Защищенность — атрибут, определяющий способность ПО пред-
отвращать несанкционированный доступ (случайный или умышлен-
ный) к программам и данным.

Надежность. Это совокупность атрибутов, которые определяют спо-
собность ПО преобоазовывать исходные данные в результаты при усло-
виях, зависящих от периода времени жизни ПО (износ и его старение
не учитываются). Снижение надежности ПО происходит из-за ошибок
в требованиях, проектировании и выполнении. Отказы и ошибки
в программах появляются на заданном промежутке времени.

К подхарактеристикам (субхарактеристикам) надежности ПО от-
носятся следующие.
Безотказность — атрибут, который определяет способность ПС
функционировать без отказов (как программы, так и оборудова-
ния).

Устойчивость к ошибкам — атрибут, который показывает способ-
ность ПО выполнять функции при аномальных условиях (сбой ап-
паратуры, ошибки з данных и интерфейсах, нарушение в действиях
оператора и др.).

Восстанавливаемость — атрибут, который показывает способ-
ность ПО к перезапуску для повторного выполнения и восстановле-
ния данных после отказов.

К некоторым типам «критических систем» (реального времени,
радарных, систем безопасности, коммуникаций и др.) предъявля-
ются требования по обеспечению высокой надежности (недопусти-
мость ошибок, точность, достоверность, удобство применения
и др.). Надежность ПО в значительной степени зависит от числа
оставшихся и неустраненных ошибок в процессе его разработки
на этапах ЖЦ. В ходе эксплуатации ошибки обнаруживаются
и устраняются. Если при исправлении ошибок не вносятся новые
или, по крайней мере, новых ошибок вносится меньше, чем устра-
няется, то в ходе эксплуатации надежность ПО непрерывно возрас-
тает. Чем интенсивнее проводится эксплуатация, тем интенсивнее
выявляются ошибки и быстрее растет надежность ПО

На надежность ПО влияют следующие факторы:

•	совокупность угроз, приводящих к неблагоприятным послед-
ствиям и к ущербу системы или среды ее функционирования;

•	угроза как проявление нарушения безопасности системы;

•	целостность как способность системы сохранять устойчивость
работы и не иметь риска.

Обнаруженные ошибки могут быть результатом угрозы извне или
отказов, они повышают риск и уменьшают некоторые свойства на-
дежности системы.

Надежность — одна из ключевых проблем современных прог-
раммных систем, и ее роль будет постоянно возрастать, поскольку
постоянно повышаются требования к качеству компьютерных
систем. Новое направление — инженерия программной надежности
(Software reliability engineering) — ориентировано на количественное
изучение операционного поведения компонентов системы по отно-
шению к пользователю, ожидающему надежную работу системы,
и включает следующие аспекты:

•	измерение надежности, т.е. проведение ее количественной оценки
с помощью предсказаний, сбора данных о поведении системы
в процессе эксплуатации, а также современных моделей надеж-
ности;

•	стратегии и метрики конструирования и выбора готовых компо-
нентов, процесса разработки компонентной системы, а также
среды функционирования, влияющей на надежность работы сис-
темы;

•	применение современных методов инспектирования, верификации,
валидации и тестирования при разработке системы, а также при
ее эксплуатации.

Верификация применяется для определения соответствия готового
ПО установленным спецификациям, а валидация — для установления
соответствия системы требованиям пользователя, которые были
предъявлены заказчиком.

В инженерии надежности термин пригодноспособность (depend-
ability) обозначает способность системы иметь свойства, желатель-
ные для пользователя, который уверен в качественном выполнении
функций, заданных в требованиях. Данный термин определяется
дополнительным количеством атрибутов, которыми должна обладать
система:

•	готовностью к использованию (availability);

•	готовностью к непрерывному функционированию (reliability);

•	безопасностью для окружающей среды, т.е. способностью сис-
темы не вызывать катастрофических последствий в случае отказа
(safety);

•	секретностью и сохранностью информации (confidential);

•	способностью к сохранению системы и устойчивости к самопро-
извольному ее изменению (integrity);

•	способностью к эксплуатации ПО, простотой выполнения опе-
раций обслуживания, а также устранения ошибок, восстановле-
нием системы после их устранения (maintainability);

•	готовностью и сохранностью информации (security) и др.

Достижение надежности системы обеспечивается предотвраще-
нием отказа (fault prevention) или его устранением (removal fault),
а также оценкой возможности появления новых отказов и мер
борьбы с ними.

Для численной оценки надежности используются методы теории
вероятностей. Каждый программный компонент, его операции
и данные обрабатываются в дискретные моменты времени, напри-
мер 5, 25,..., и5.

Пусть за время Тпосле первого неудачно обработанного компо-
нента системы появился отказ, для которого справедливо выражение
Р{Т> м8} = (1 - q,)n, где qs — вероятность отказа, при этом среднее
<	гг 8

время ожидания будет равно 1 = —.

Положим, что значение 5 уменьшается, а время Т остается фик-
сированным, тогда имеем

z <. х-	t

A{r>Z}=|l-|j8 = е?,

где t — время до отказа, в данном случае — непрерывная величина,
распределенная экспоненциально.

Таким образом, обеспечение надежности ПО — это трудоемкий
процесс, требующий создания устойчивой работы системы по отно-
шению к отказам ПО, т.е. обеспечения достаточно высокой вероят-
ности того, что система восстановится самопроизвольно в некоторой
точке после возникновения в ней отказа (fault).

Удобство применения Этот показатель характеризуется множе-
ством атрибутов, определяющих необходимые пригодные условия
использования ПО (например, диалоговое, недиалоговое) задан-
ным кругом пользователей для получения соответствующих резуль-
татов. В стандарте ДСТУ 2850-1994 удобство применения опреде-
лено как множество атрибутов ПП, характеризующих его эргоно-
мичность:

•	понимаемость — атрибут, который определяет усилия, затрачива-
емые на распознавание логических концепций и условий приме-
нения ПО;

•	изучаемость (легкость изучения) — атрибут, который определяет
усилия пользователей, затрачиваемые на определение примени-
мости ПО путем использования операционного контроля, ди-
агностики, а также установленных процедур, правил, изложенных
в документации;

•	оперативность — атрибут, который определяет реакцию системы
при выполнении операций и операционного контроля;

•	согласованность — атрибут, который показывает соответствие раз-
работки требованиям стандартов, соглашений, правил, законов
и предписаний.

Эффективность. Это множество атрибутов, которые определяют
взаимосвязь уровней выполнения ПО, степень использования ре-
сурсов (средств, аппаратуры, материалов — бумаги для печатающего
устройства и др.) и услуг, выполняемых штатным обслуживающим
персоналом. К атрибутам эффективности ПО относятся:
•	реактивность — атрибут, который показывает время отклика, об-
работки и выполнения функций;

•	эффективность ресурсов — атрибут, показывающий количество
и продолжительность используемых ресурсов при выполнении
функций ПО;

•	согласованность — атрибут, который показывает соответствие дан-
ного атрибута заданным стандартам, правилам и предписаниям.
Сопровождаемость. Это множество свойств, определяющих уси-
лия, которые надо затратить на проведение модификаций, включа-
ющих корректировку, усовершенствование и адаптацию ПО при
изменении среды, требований или функциональных спецификаций.
Сопровождаемость определяется следующими атрибутами:

•	анализируемость — атрибут, определяющий необходимые усилия
для диагностики отказов или идентификации частей, которые
будут модифицироваться;

•	изменяемость — атрибут, который определяет возможность уда-
ления ошибок в ПО или внесение изменений для их устранения,
а также введение новых возможностей в ПО или в среду функцио-
нирования;

•	стабильность — атрибут, указывающий на постоянство структуры
и риск ее модификации;

•	тестируемость — атрибут, определяющий усилия при проведении
валидации и верификации ПО с целью обнаружения несоответ-
ствий требованиям, а также необходимость проведения модифи-
кации ПО и его сертификации:

•	согласованность — атрибут, который показывает соответствие дан-
ного атрибута соглашениям, правилам и предписаниям стандарта.
Переносимость. Это множество показателей, определяющих спо-
собность ПО адаптироваться к работе в новых условиях среды вы-
полнения. Среда может быть организационной, аппаратной и про-
граммной. Перенос ПО в новую среду выполнения может быть свя-
зан с некоторой совокупностью действий, направленных
на обеспечение его функционирования в среде, отличной от той,
в которой оно создавалось, с учетом новых программных, организа-
ционных и технических возможностей. Переносимость включает
в себя следующие атрибуты:

•	адаптивность — атрибут, определяющий усилия, затрачиваемые
на адаптацию к различным средам;

•	настраиваемость (простота инсталляции) — атрибут, который
определяет необходимые усилия для запуска данного ПО в спе-
циальной среде;
•	сосуществование — атрибут, который определяет возможность ис-
пользования специального ПО в среде действующей системы;

•	заменяемость — атрибут, который обеспечивает возможность ин-
тероперабельности при совместной работе с другими програм-
мами с необходимой инсталляцией или адаптацией ПО;

•	согласованность — атрибут, который определяет соответствие
стандартам или соглашениям по обеспечению переноса ПО.

9.2.	Метрики и атрибуты качества

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

При определении требований к ПО задаются соответствующие
им внешние характеристики и их атрибуты (субхарактеристики),
определяющие разные стороны управления продуктом в заданной
среде. Для набора характеристик качества ПО, приведенных в тре-
бованиях, определяются соответствующие метрики, модели их
оценки и диапазоны их значений для измерения отдельных атрибу-
тов качества

Согласно стандарту ISO 14598 метрики определяются по модели
измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внут-
ренняя метрика), и особенно на этапе тестирования или функцио-
нирования (внешние метрики) продукта. Остановимся на классифи-
кации существующих метрик ПО, правилах проведения метриче-
ского анализа и процессах их измерения.

Существует три типа метрик: метрики программного продукта,
которые используются при измерении его характеристик или
свойств; метрики процесса, которые используются при измерении
свойств процесса ЖЦ создания продукта; метрики использования

Метрики программного продукта. Эти метрики используют
внешние метрики, обозначающие свойства продукта, видимые поль-
зователю, и внутренние метрики, обозначающие свойства, видимые
только команде разработчиков.

Внешние метрики программного продукта:

•	метрики надежности, которые служат для определения числа де-
фектов;

•	метрики функциональности, с помощью которых устанавлива-
ются наличие и правильность реализации функций в продукте;
•	метрики сопровождения, с помощью которых измеряются ре-
сурсы продукта (скорость, память, среда);

•	метрики применимости продукта, которые способствуют опреде-
лению степени доступности для изучения и использования;

•	метрики стоимости, которыми определяется стоимость создан-
ного продукта.

Внутренние метрики программного продукта:

•	метрики размера, необходимые для измерения продукта с по-
мощью его внутренних характеристик;

•	метрики сложности, необходимые для определения сложности
продукта;

•	метрики стиля, которые служат для определения подходов и тех-
нологий создания отдельных компонентов продукта и его доку-
ментов.

Существует также некая общая мера — степень трассируемости
ПП, которая определяется числом трасс, прослеживаемых с по-
мощью моделей сценариев типа UML, и оценкой количества требо-
ваний, сценариев и действующих лиц, объектов, включенных в сце-
нарий.

Внутренние метрики позволяют определить производительность
продукта и являются релевантными по отношению к внешним ме-
трикам.

Внешние и внутренние метрики задаются на этапе формирования
требований к ПО и являются предметом планирования и управления
в процессе достижения качества конечного ПП.

Метрики продукта часто описываются комплексом моделей для
установки различных свойств, значений модели качества или про-
гнозирования. Измерения проводятся, как правило, после кали-
бровки метрик на ранних этапах проекта.

Стандарт ISO/IEC9126-2 рекомендует следующие меры (метрики)
ПП:

•	мера размера ПО в разных единицах измерения (число функций,
строк в программе, размер дисковой памяти и др.);

•	мера времени (функционирования системы, выполнения компо-
нента и др.);

•	мера усилий (производительность труда, трудоемкость и др.);

•	мера учета (количество ошибок, число отказов, ответов системы
и др.)

Специальной мерой может служить уровень повторного использо-
вания компонентов программной системы, измеряемый как отноше-
ние размера продукта, изготовленного из готовых компонентов,
к размеру системы в целом. Данная мера используется также при
определении стоимости и качества ПО В качестве примеров таких
метрик можно привести следующие характеристики: общее число
объектов и число повторно используемых; общее число повторно
используемых и новых операций; число классов, наследующих спе-
цифические операции, число классов, от которых зависит данный
класс; число пользователей класса/операций и др.

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

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

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

•	общее время разработки и отдельно время для каждой стадии;

•	время модификации моделей;

•	время выполнения работ на процессе;

•	число найденных ошибок при инспектировании;

•	стоимость проверки качества;

•	стоимость процесса разработки.

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

По определению стандарта ISO/IES9126-2 метрика качества ПО
представляет собой «модель измерения атрибута, связываемого с по-
казателем его качества». При измерении показателей качества ПО
стандарт JSO/IES9126-2 рекомендует использовать следующие типы
мер:

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

•	меры времени, периоды реального, процессорного или календар-
ного времени (время функционирования системы, время выпол-
нения компонента, время использования и др.);

•	меры усилий, продуктивное время, затраченное на реализацию
проекта (производительность труда отдельных участников про-
екта, коллективная трудоемкость и др.);

•	меры интервалов между событиями, например время между по-
следовательными отказами;

•	счетные меры, счетчики для определения количества обнаружен-
ных ошибок, структурной сложности программы, числа несовме-
стимых элементов, числа изменений (например, число обнару-
женных отказов и др.).

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

При тестировании наиболее важным показателем является нара-
ботка на отказ, который как атрибут надежности определяет среднее
время между появлением угроз, нарушающих безопасность, и обес-
печивает трудноизмеримую оценку ущерба, которая наносится со-
ответствующими угрозами.

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

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

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

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

Согласно стандарту ДСТУ 3230-1995 для оценки значений пока-
зателей качества используются следующие методы: измерительный,
регистрационный, расчетный и экспертный (а также комбинации
этих методов).

Измерительный метод основан на использовании измерительных
и специальных программных средств для получения информации
о характеристиках ПО, например определения объема, числа строк
кода, операторов, количества ветвей в программе, числа точек входа/
выхода, реактивности и др.

Регистрационный метод используется при подсчете времени,
числа сбоев или отказов, начала и конца работы ПО в процессе его
выполнения

Расчетный метод базируется на статистических данных, со-
бранных при проведении испытаний, эксплуатации и сопровожде-
нии ПО. Расчетными методами оцениваются показатели надеж-
ности, точности, устойчивости, реактивности и др.

Экспертный метод осуществляется группой экспертов — специа-
листов, компетентных в решении данной задачи или используемом
ПО. Их оценка базируется на опыте и интуиции, а не на результатах
расчетов и экспериментов. Такая экспертиза обычно проводится пу-
тем просмотра программ и сопроводительных документов; для этого
устанавливаются контролируемые признаки, которые коррелиро-
ваны с одним или несколькими показателями качества и включены
в опросные карты экспертов. Метод применяется при оценке таких
показателей, как анализируемость, документируемость, структури-
рованность ПО, и способствует всесторонней и качественной оценке
созданного продукта.

При оценке значений показателей качества в зависимости от осо-
бенностей используемых ими свойств, способов их определения
и назначения для каждой метрики качества применяется опреде-
ленная шкала измерений'.

•	шкала метрическая (абсолютная, относительная, интегральная);

•	шкала порядковая (ранговая), позволяющая ранжировать харак-
теристики путем сравнения с опорными значениями;

•	классификационная шкала, характеризующая наличие или отсут-
ствие рассматриваемого свойства у оцениваемого ПО.

Показатели, которые вычисляются с помощью метрических
шкал, называются количественными, а показатели, определяемые
с помощью порядковых и классификационных шкал, — качествен-
ными.

Стандарт ISO/IES9126-2 рекомендует к применению пять видов
шкал измерения и порядок их использования от менее строгой
оценки к более строгой.

1.	Поминальная шкала отражает категории свойств оцениваемого
объекта без их упорядочения.

2.	Порядковая шкала служит для упорядочения характеристики
по возрастанию или убыванию путем сравнения их с базовыми зна-
чениями.

3.	Интервальная шкала задает существенные свойства объекта
(например, календарная дата).

4.	Относительная шкала задает некоторое значение относительно
выбранной единицы.

5.	Абсолютная шкала указывает на фактическое значение вели-
чины (например, число ошибок в программе равно 10).
9.3.	Управление качеством

Под управлением качеством понимается совокупность организа-
ционной структуры и ответственных лиц, а также процедур, процес-
сов и ресурсов для планирования и управления достижением каче-
ства ПС. Управление качеством — Software Quality Management (SQM)
базируется на применении стандартных положений по гарантии
качества — Software Quality Assurance (SQA).

Цель процесса SQA состоит в обеспечении гарантии того, что про-
дукты и процессы согласуются с предъявляемыми к ним требова-
ниями и соответствуют планам. Этот процесс включает в себя внед-
рение стандартов и процедур разработки программной системы
на всех этапах ЖЦ, а также оценку соблюдения положений этих
стандартов и процедур.

Гарантию качества обеспечивают следующие процедуры процесса
SQA:

•	проверка непротиворечивости и выполнимости планов;

•	согласование получаемых промежуточных рабочих продуктов
с плановыми показателями;

•	проверка изготовленных продуктов на соответствие заданным
требованиям;

•	анализ применяемых процессов на соответствие договору и пла-
нам;

•	согласование с заказчиком среды и методов разработки продукта;

•	проверка принятых метрик продуктов, процессов и приемов их
измерения на соответствие утвержденным стандартам и процеду-
рам измерения.

Проиесс SQM предполагает выполнение следующих действий:
определение количественных свойств качества, основанных на вы-
явленных потребностях пользователей, и управление реализацией
поставленных целей для достижения качества

При выполнении процесса SQM предполагается, что:

•	цели достижения требуемого качества установлены для всех ра-
бочих продуктов в контрольных точках продукта;

•	определена стратегия достижения качества, а также метрики, кри-
терии, приемы, требования к процессу измерения и пр.;

•	определены и выполняются действия, связанные с предоставле-
нием продуктам свойств качества;

•	проводится контроль качества (SQA, верификация и валидация);

•	выполняются процессы измерения и оценивания конечного про-
дукта на достижение требуемого качества.
Анализ основных стандартных положений (ISO/IEC9126, ДСТУ
2844-1994, ДСТУ 2850-1994, ДСТУ 3230-1995, NASA-STD-2201)
по созданию качественного продукта и оценки достигнутого уровня
качества позволяют выделить два процесса достижения качества
на этапах ЖЦ ПП'.

1)	гарантия/подтверждение качества ПП как результат опреде-
ленной деятельности на каждом этапе ЖЦ с проверкой соответствия
создаваемой системы стандартам и процедурам, ориентированным
на достижение качества;

2)	инженерия качества как процесс предоставления ПП свойств
функциональности, надежности, сопровождения и других характе-
ристик качества.

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

Выполнение указанных процессов включает следующие действия:
• оценку стандартов и процедур, которые выполняются при разра-
ботке ПП;

•	ревизию управления, разработки и обеспечение гарантии каче-
ства ПП, а также проектной документации (отчетов, графиков
разработки и др.);

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

•	анализ и контроль проведения приемочного тестирования/испы-
тания ПП.

Для организации, которая занимается разработкой ПС, инжене-
рия качества должна поддерживаться системой управления каче-
ством (вкдючая планирование, учет и контроль).

Инженерия качества включает определенный набор методов и ме-
роприятий, с помощью которых ПП проверяются на выполнение
требований к качеству и характеристикам, предусмотренным в тре-
бованиях на ПО.

Система управления качеством (Quality systems (QS) — NASA-STD-
2201) — это набор организационных структур, методик, мероприятий,
процессов и ресурсов для осуществления управления качеством

Для обеспечения требуемого уровня качества ПО применяются
два подхода: один из них ориентирован на конечный программный
продукт, а второй — на процесс создания продукта.
При подходе, ориентированном на конечный программный продукт,
оценка качества проводится после испытания ПС. Этот подход осно-
ван на предположении, что чем больше обнаружено и устранено
ошибок в продукте при испытаниях, тем выше его качество

При подходе, ориентированном на процесс создания продукта, пре-
дусматриваются и принимаются меры по предотвращению, опера-
тивному выявлению и устранению ошибок, начиная с начальных
этапов его ЖЦ в соответствии с планом и процедурами обеспечения
качества разрабатываемой ПС. Этот подход представлен в серии
стандартов ISO 9000 и 9000-1, 2, 3, которые дают рекомендации ор-
ганизациям-разработчикам по созданию системы качества (рис. 9.4).

Показатели-характеристики

Атрибуты

Рис. 9.4. Требования стандарта к организации системы качества

Важное место в инженерии качества отводится процессу измере-
ния характеристик процессов ЖЦ, ресурсов и создаваемых рабочих
продуктов. Этот процесс реализуется группой качества, верификации
и тестирования. В ее функции входит планирование, оперативное
управление и обеспечение качества.

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

Оперативное управление включает методы и виды деятельности
оперативного характера для текущего управления процессом проек-
тирования и устранения причин плохого или неудовлетворительного
функционирования ПС

Обеспечение качества заключается в проверке того, что объект
разработки удовлетворяет указанным требованиям к качеству. Цели
обеспечения качества могут быть внутренние и внешние:

•	внутренние цели — это создание уверенности у руководителя про-
екта, что требуемое качество обеспечивается;

•	внешние цели — это создание уверенности у пользователя, что
требуемое качество достигнуто и получено необходимое каче-
ственное ПО.

Примеры требований к количественным и качественным харак-
теристикам качества программного средства приведены в табл. 9.1
и 9.2.

Таблица 9.1

Количественные характеристики качества ПС

Характеристика качества	Мера	Требуемое значение
Надежность  Завершенность:  наработка на отказ при отсутствии рестарта  Устойчивость'  наработка на отказ при наличии автомати-  ческого рестарта  относительные ресурсы на обеспечение на-  дежности и рестарта  Восстанавливаемость:  длительность восстановления  Доступность-готовность:  относительное время работоспособного  функционирования	час  час  процент минута  вероятность	10  50  10  5  0,998
Эффективность  Временная эффективность:		
Окончание табл. 9.1

Характеристика качества	Мера	Требуемое значение
время отклика, получения результатов на типовое задание  пропускная способность, число типовых заданий, исполняемых в единицу времени  Используемость ресурсов:  относительная величина использования ре- сурсов ЭВМ при нормальном функциониро- вании ПО	секунда  число в минуту  вероятность	5  20  0,8

Таблица 9.2

Качественные характеристики качества ПС

Характеристика качества	Мера	Требуемое значение
Практичность  Простота использования: среднее время ввода заданий	секунда	10
среднее время отклика на задание	секунда	5
Изучаемость:  трудоемкость изучения применения ПО	человеко-час	200
продолжительность изучения	час	50
обьем эксплуатационной документации	страница	1000
Сопровождаемость  Изменяемость:  трудоемкость подготовки изменений	человеко-час	10
длительность подготовки изменений	час	5
Тестируемость:  трудоемкость тестирования изменений	человеко-час	20
длительность тестирования изменений	час	5
Мобильность  Адаптируемость:  трудоемкость адаптации	человеко-час	50
длительность адаптации	час	10
Простота установки: трудоемкость инсталляции	человеко-час	10
длительность инсталляции	час	5
Защищаемость:  трудоемкость замены компонентов	человеко-час	50
длительность замены компонентов	час	10
Как показывает опыт, ряд фирм, выпускающих программную
продукцию, имеют системы качества, что обеспечивает им произ-
водство конкурентоспособной продукции, так как система качества
включает в себя мониторинг спроса на выпускаемый новый вид про-
дукции и контроль всех звеньев его производства, в том числе подбор
и поставку готовых компонентов для системы.

При отсутствии соответствующих служб качества разработчики
ПО должны применять собственные нормативные и методические
документы, регламентирующие процесс управления качеством для
всех категорий разработчиков и пользователей программной продук-
ции.

9.4. Надежность как главная составляющая
качества

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

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

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

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

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

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

К факторам, влияющим на надежность ПС, относятся:

•	риск как совокупность угроз, приводящих к неблагоприятным
последствиям и ущербу системы или среды;

•	угроза как проявление неустойчивости, нарушающей безопас-
ность системы;

•	анализ риска, т.е. изучение угрозы или риска, их частоты и по-
следствий;
•	целостность, т.е. способность системы сохранять устойчивость
работы и не иметь риска.

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

Базовыми понятиями, которые используются в моделях надеж-
ности ПС, являются следующие.

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

Дефект (fault) в ПС — это последствие использования элемента
программы, которое может привести к некоторому событию, напри-
мер результат неверной интерпретации этого элемента компьютером
(ошибка в программе — fault) или человеком (ошибка исполни-
теля — error) Дефект является следствием ошибок разработчика
на любом из процессов разработки: в описании спецификаций тре-
бований; начальных или проектных спецификациях; эксплуатаци-
онной документации и т.п. Дефекты, не выявленные в программе
в результате проверок, являются источником потенциальных ошибок
и отказов ПС. Проявление дефекта в виде отказа зависит от того,
какой путь будет выполнять специалист, чтобы найти ошибку в коде
или во входных данных. Однако не каждый дефект ПС может вы-
звать отказ вследствие сложных взаимосвязей между дефектами в П С
и вычислительной средой.

Ошибка (error) может быть следствием принятия неверных реше-
ний или недостатков в одном из процессов разработки ПС, которые
приводят к неправильной интерпретации промежуточной информа-
ции, заданной разработчиком.

Интенсивность отказов — это частота появления отказов или де-
фектов в ПС при тестировании или эксплуатации.

При выявлении отклонения результатов выполнения от ожида-
емых во время тестирования или сопровождения осуществляется
поиск, выяснение причин отклонений и исправление связанных
с этим ошибок.
Модели оценки надежности ПС в качестве входных параметров
исполвзуют сведения об ошибках, отказах и их интенсивности, со-
бранные в процессе тестирования и эксплуатации ПС.

Классификация моделей надежности. На сегодняшний денв разра-
ботано болвшое количество моделей надежности ПС и их модифи-
каций. Каждая из этих моделей определяет некую функцию надеж-
ности, которую можно вычислить при задании соответствующих
даннв1Х, собраннв1х во время функционирования ПС. Основными
данными являются отказы и их временные характеристики. Другие
дополнителвные параметры связаны с типом ПС, условиями среды
и типом используемв1х данных.

Существуют различные классификаций моделей надежности ПС.
Приведем достаточно известную классификацию моделей надежности
ПС по критерию имеющихся входных статистик, получаемых на раз-
личных этапахжппп.

1	Модели полноты тестирования, позволяющие получитв
оценки показателей доверия к процессу оценки соответствия ПО
заданным требованиям.

2.	Модели сложности ПО, позволяющие оценить метрики слож-
ности ПО и связанные с ними показатели качества и безопасности
ПО.

3.	Временные модели роста надежности (reliability growth model),
позволяющие оценить показатели технологической безопасности
ПО в зависимости от времени их испытаний.

4.	Отладочные модели, позволяющие оценить показатели техно-
логической безопасности ПО в зависимости от прогонов на заданных
областях входных данных и последующих доработок ПО.

Рассмотрим кратко каждую группу.

Модели оценки полноты тестирования ПО основаны на методах
независимого внесения и выявления тестовых ошибок и методах
проведения независимых экспертиз.

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

Модель учета внесения ошибок в разные модули ПС. Программный
продукт разбивается на две части с индивидуальным (определяемым
экспериментатором тем или иным способом) количеством ошибок.
Определяется вероятность обнаружения ошибки на заданном интер-
вале времени тестирования при условии, что их обнаружение равно-
вероятно и что в заданный интервал времени обнаруживается только
одна ошибка, которая сразу же исправляется.

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

Модель испытания независимыми группами предполагает, что тес-
тирование ПО осуществляется двумя независимыми группами или
экспертами. На основе количества ошибок, обнаруженных каждой
группой в отдельности, и количества совместно обнаруженных оши-
бок делается заключение об общем количестве ошибок, содержа-
щемся в тестируемом ПО.

Модели сложности ПО базируются на гипотезе о том, что уровень
безошибочности ПО может быть предсказан с помощью показателей
сложности П О (чем сложнее программа, тем вероятнее ошибка про-
граммиста).

Метрическая модель ошибок Холстеда. Оценка ошибок осуще-
ствляется на основе эмпирических соотношений, определяющих
сложность ПО, причем сложность зависит от количества операторов
и операндов используемого языка программирования и количества
используемых операторов и операндов в конкретных реализациях
ПО, а также от некоторого числа умственных операций (интеллек-
туальных усилий) в единицу времени — числа Страуда, которое Хол-
стед принял равным 18.

Многофакторная модель сложности представляет собой линейную
модель (фирмы «TRW*) оценки показателей сложности ПО по пяти
эмпирическим характеристикам: логической сложности ПП, слож-
ности взаимосвязей, сложности вычислений, сложности вывода
и понятности. Перечисленные показатели участвуют в линейном
уравнении, определяющем количество ошибок в ПО.
Модели роста надежности во времени — вероятностные динами-
ческие модели дискретных систем с непрерывным или дискретным
временем, которые сводятся к ряду известных моделей массового
обслуживания в классической теории надежности.

Экспоненциальная модель роста надежности (модель Джелински—
Моранды, модель JM) основана на допущении, что в процессе тести-
рования ПО длительность интервалов времени между обнаружением
двух ошибок имеет экспоненциальное распределение с интенсивно-
стью отказов, пропорциональной числу необнаруженных ошибок;
все ошибки равновероятны, обнаруженная ошибка мгновенно устра-
няется, а их число уменьшается на единицу. Полученная при указан-
ных предположениях модель позволяет определить вероятности без-
ошибочной работы, устранения всех ошибок за заданное время,
средней наработки на ошибку, среднего времени устранения всех
ошибок и т.д К подобным моделям относят также модель Липова,
Xui-модель, Shathikumar-модель, Bucchianico-модель.

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

S-образная NHPP-модель роста надежности программ предпола-
гает, что количество ошибок, проявляющихся в единицу времени,
является независимой случайной величиной, распределенной по за-
кону Пуассона с интенсивностью потока, пропорциональной ожи-
даемому числу оставшихся в программе ошибок на заданный момент
времени (модель Ямады); причем количество ошибок представляет
собой S-образную зависимость от времени тестирования (поскольку
на начальной стадии тестирования осуществляется изучение ПО экс-
пертом). Модель позволяет определить интенсивность возникнове-
ния ошибки, а также вероятности того, что за заданное время будет
выявлено и локализовано (или нет) то или иное количество ошибок.
К моделям этого типа относят Duane-модель, модель Гомпертца,
Goel-Okumoto-модель, Schneidewind-модель, модель Вейбулла,
S-образную модель Рэлея, S-образную модель с задержкой, S-образ-
ную модель с точкой перегиба, параметризованную S-изогнутую
модель, Dohiya-модель, модель Парето, гиперэкспоненциальную
модель, Littlewood-модель, параболическую модель, логистическую
модель, Pham-модель, Zhang-модель, Xie-логарифмическую модель,
Musa-Okumoto-логарифмическую модель.

Отладочные модели надежности базируются на предположении,
что свойство безошибочности ПО меняется только при его доработ-
ках и измеряется посредством прогона ПО на заданных входных дан-
ных.

Структурная модель Нельсона. Область входных данных ПО зада-
ется в виде нескольких непересекающихся областей, которым одно-
значно соответствуют множество вероятностей того, что соответству-
ющий набор данных будет выбран при очередном прогоне ПО.
На основе обозначенных показателей, а также с использованием
общего количества прогонов ПО и количества прогонов, завершив-
шихся отказом, определяется степень надежности ПО.

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

Рассмотренные модели надежности ПС основаны на времени
функционирования ПС и/или количестве отказов (ошибок), полу-
ченных в программах в процессе их тестирования или эксплуатации.
Модели надежности, как правило, строятся на предположении либо
о марковском, либо пуассоновском характере процессов обнаруже-
ния ошибок в программах и интенсивности отказов.

Контрольные вопросы

1.	Что включает в себя понятие качества ПО?

2.	Каковы основные цели и задачи системы управления качеством?

3.	Какие стандарты существуют в области качества ПО?

4	В чем суть инженерии качества?

5.	Каковы основные аспекты и уровни модели качества ПО?

6.	Определите характеристики качества ПО и их назначение.

7.	Какие методы используются при определении показателей качества?

8.	Определите метрики программного продукта и их составляющие.

9.	Какие модели надежности вы знаете?

10.	Какие данные необходимы для оценивания надежности ПО?
Литература

1.	Барлоу Р., Прошан Ф. Математическая теория надежности. — М.: Мир,
1969.-483 с

2	Гласс Г. Руководство по надежному программированию. — М.: Фи-
нансы и статистика, 1982. — 256 с.

3.	ДСТУ 2844 Программные средства ЭВМ. Обеспечение качества. Тер-
мины и определения. — 1994.

4.	ДСТУ 2850. Программные средства ЭВМ Обеспечение качества. По-
казатели и методы оценки качества программного обеспечения. — 1994

5	ДСТУ 3230 Управление качества и обеспечение качества. Термины и
определения. — 1995.

6.	Коваль Г.И- Подход к прогнозированию надежности ПО при управ-
лении проектом // Проблемы программирования. — 2002. — № 1—2. —
С 282-290.

7	Кулаков АЮ. Оценка качества программ ЭВМ. — Киев: Техшка. —
1984.- 167 с.

8.	Лапаев В.В. Методы обеспечения качества крупномасштабных прог-
раммных систем. — М : СИНТЕГ. — 2003. — 510 с.

9	Лапаев В.В. Надежность программного обеспечения АСУ — М : Сов.
радио, 1977. — 400 с.

10	Майерс Г. Надежность программного обеспечения — М : Мир, 1980. —
360 с.

11.	Марков А.С. Модели оценки и планирования испытаний программных
средств по требованиям безопасности информации // Вестник МГТУ
им. Н.Э. Баумана. Сер. «Приборостроение», 2011 Специальный выпуск
«Технические средства и системы защиты информации». — С. 90 — 103.

12.	Мороз Г.Б., Лаврищева Е.М Модели роста надежности программного
обеспечения — Киев: Препринт, 1992. — 23 с

13.	Оррам Э., Уилсон Г. Идеальная разработка ПО Рецепты лучших про-
граммистов. — СПб.: Питер, 2012. — 592 с.

14.	Основы инженерии качества программных систем /ФИ. Андон,
Г.И. Коваль, Т.М. Коротун, В.Ю Суслов. — Киев: Академпериодика,
2002. - 502 с.

15	Тейер Т., Липов Р, Нельсон Э. Надежность программного обеспече-
ния. — М.: Мир, 1981. — 325 с.

16.	Черников Б В Управление качеством программного обеспечения: учеб-
ник. - М . ФОРУМ: ИНФРА-М, 2012. - 240 с. - ISBN 978-5-8199-
0499-2

17.	Goel A. L. Software reliability models Assumptions, Limitations and Applica-
bility// IEEE Trans. - N2 - P. 1411-1423.

18.	Haag S., Raja H.K., Sekade L.L. Quality Function Deployment. Usage in
Software Development // Comm, of ACM. — 1998. — 39. — N1

19	ISO 14598. Information Technology — Software product evolution — Parti:
General overview. — 1996.
20.	ISO/IEC 9126. Information Technology. — Software Quality Characteristics
and metrics. — 1997.

21.	Jelinski Z., Moranda P. Software reliability research // Statistical computer
performance evaluation W. Freiberger, Ed. Academic Press. — 1972. —
P. 465—484.

22.	John D. Musa, Anthony lannino, and Kazuhira Okumoto Software Reliability:
Measurement, Prediction, Application. Whippany, NJ: McGraw — Hill,
1987.

23.	Jotterbam D., Miller K., Rogerson S. Software Engineering Code of Ethies is
Approved /1 Communications of the ACM. — v.42. — № 10. — 1999. —
P. 102-107.

24.	Meyer В. The role of Object — Oriented Metrics. — Computer, 1998. —
№11.-P. 23-125.

25.	Musa J.D. Okumoto K.A. Logarithmic Poisson Time Model for Software Reli-
ability Measurement // Proc. Sevent International Conference on Software
Engineering. — Orlando, Florida. — 1984. — P 230—238.

26.	NASA-STD-2 201 /I Software Assurance Standart, 1993.

27.	Schneidewind N.F. Software Reliability Model with Optimal Selection of Fail-
ure Data // IEEE Trans on Software Eng. — 1993. — № 11. — P. 1095—1104.

28.	Shanthikumar J.G. Software reliability models: A Review // Microelectron.
Rehab. - 1983. - V. 23. - № 5 - P. 903-943.

29.	Yamada S., Ohba M., Osaki S. S-shaped software reliability grows modeling
for software error detection // IEEE Trans. Reliability. — 1983. — № 5. —
P. 475-478.
СПИСОК ИСПОЛЬЗУЕМЫХ
СОКРАЩЕНИЙ, ОБОЗНАЧЕНИЙ
И ИНОСТРАННЫХ ТЕРМИНОВ

ACM (Association for Computing Machinery) — ассоциация по вы-
числительной технике.

API (Application Programming Interface) — программный интерфейс.

АРМ (Association of Project Management) — ассоциация по про-
ектному менеджменту.

BPR (Buisness Process Reengineering) — реинжиниринг бизнес-
процесса — знак авторского права.

CASE (Computer-Aided Software Engineering) — набор инстру-
ментов и методов программной инженерии для проектирования
программного обеспечения.

СММ (Capability Maturity Model) — система понятий, предназна-
ченных для усовершенствования процесса разработки ПО.

COCOMO (Constructive cost model) — конструктивная модель
стоимости, предложенная Б. Боэмом.

COM (Component Object Model) — компонентная модель объек-
тов, созданная фирмой «Microsoft».

CORBA (Common Object Request Broker Architecture) — общая
архитектура с посредником обработки запросов объектов, создана
группой OMG.

СРМ (Critical Path Method) — метод критического пути.

DCOM (Distributed Component Object Model) — распределенная
компонентная модель объектов, созданная фирмой «Microsoft».

FP-метрики (Function Points) — функционально-ориентирован-
ные метрики.

FSM (Functional Size Measurement) — техника численной оценки
или измерения объема функциональности программного обеспе-
чения.

GUI (Graphical User Interface) — графический [пользовательский]
интерфейс.

IDL (Interface Definition Language) — язык определения интер-
фейсов.

IEEE (Institute of Electrical and Electronics Engineers) — институт
инженеров по электротехнике и электронике.

IFPUG (International Function Point Users Group) — междуна-
родная группа пользователей функционального измерения.
IPMA (International Project Management Association) — Междуна-
родная ассоциация управления проектами.

ISO (International Standardizing Organization) — MOC (междуна-
родная организация стандартов).

IT (Information Technology) — информационные технологии.

KLOC — тысяча строк исходного программного кода.

LOC — строка исходного программного кода.

LOC-метрики (Lines of Code) — метрики, ориентированные
на количество строк программного кода.

LOC-оценка (Lines of Code) — количество строк программного
кода.

MIDL (Microsoft IDL) — язык определения интерфейсов фирмы
«Microsoft».

MSF (Microsoft Solution Framework) — методология разработки
программного обеспечения фирмы «Microsoft».

MVC (Model-View-Controller) — модель/шаблон проектирования
классов.

OMG (Object Management Group) — группа внедрения объектной
технологии программирования.

PERT (Program Evaluation and Review Technique) — метод анализа
и оценки программ.

PM (Project Management) — управление проектом.

РМВОК (Project Management Body of Knowledge) — свод знаний
по управлению проектами.

PMI (Project Management Institute) — американский институт
управления проектами; ® — символ зарегистрированного права
на распространение программного продукта.

RUP (Rational Unified Process) — методология разработки прог-
раммного обеспечения фирмы «Rational/IBM».

SCCM (Software Configuration and Change Management) — управ-
ление изменениями и конфигурациями программного обеспе-
чения.

SCM (Software Configuration Management) — конфигурационное
управление программным обеспечением.

SCMP (Software Configuration Management Plan) — план управ-
ления конфигурациями программного обеспечения.

SDD (Software Design Document) — проектная документация
программного обеспечения.

SEI CMU (Software Engineering Institute, Carnegie Mellon Univer-
sity) — Институт программной инженерии в Университете Карнеги
Меллон.
SLC (Software Lifetime Cycle) — концепция жизненного цикла
программного обеспечения.

SOA (Service-Oriented Architecture) — сервисно-ориентированная
архитектура.

SQA (Software Quality Assurance) — гарантии качества программ-
ного обеспечения.

SQAP (Software Quality Assurance Plan) — план контроля качества
программного обеспечения

SQL (Structured Query Language) — язык структурированных за-
просов к реляционным базам данных.

SQM (Software Quality Management) — управление качеством
программного обеспечения

SRS (Software Requirements Specification) — спецификация требо-
ваний к программному обеспечению.

STD (Software Test Documentation) — документация по тестиро-
ванию программного обеспечения.

STMP (Software Project Management Plan) — план управления
программным проектом.

SWP (Software Verification and Validation Plan) — план экспертизы
программного обеспечения

SWEBOK (Software Engineering Body of Knowledge) — свод знаний
по программной инженерии.

UML (Unified Modeling Language) — унифицированный язык мо-
делирования

V&V (Verification & Validation) — верификация и валидация/про-
верка и аттестация.

WBS (Work Breakdown Structure) — структура декомпозиции работ.

Windows — операционная система фирмы «Microsoft»

ХР (eXtreme Programming) — методология экстремалвного прог-
раммирования

АСУ — автоматизированная система управления.

БД — база данных.

ВЗУ — внешнее запоминающее устройство.

ЖЦ — жизненный цикл.

ИС — информационная система.

ИСР — иерархическая структура работ.

ИТ — информационные технологии.

ООП — объектно-ориентированное программирование.

ОС — операционная система.

ПК — персональный компьютер.
ПО — программное обеспечение.

ПП — программный продукт.

ппп — пакет прикладных программ.

ПС — программная система.

СРР — сетевая разбивка работ.

СУБД — система управления базами данных.

ТЗ — техническое задание.

ЭВМ — электронная вычислительная машина.

ЯВУ — язык [программирования] высокого уровня.
Приложение

ИНСТРУМЕНТЫ И МЕТОДЫ,
ИСПОЛЬЗУЕМЫЕ
ПРИ РАЗРАБОТКЕ
ПРОГРАММНЫХ СИСТЕМ

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

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

Среди разработчиков таких инструментов можно выделить сле-
дующие компании: «1ВМ» (продукт Rational Suite), «Oracle» (продукт
CDM Advantage), «Borland» (продукт ALM), «Computer Associates»
(ряд продуктов, каждый из которых предназначен для поддержки
одного или нескольких этапов жизненного цикла). Среди перечи-
сленных продуктов все поддерживают полный жизненный цикл раз-
работки программного обеспечения в той или иной мере в соответ-
ствии со своей моделью разработки

Инструменты работы с требованиями. Эти инструменты подразде-
ляют на две категории: средства моделирования и средства трасси-
ровки.

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

Инструменты трассировки требований используются главным
образом для анализа требований, особенно для анализа влияний тре-
бований и изменений. С повышением уровня сложности разрабаты-
ваемого продукта значимость этой категории инструментов возрас-
тает.
Для работы с требованиями компанией IBM выпускаются следу-
ющие компоненты.

Rational Suite AnalystSludio — используется для определения
и управления полным набором требований к разрабатываемой сис-
теме.

Rational Requisite Pro — средство управления требованиями при
совместной работе группы разработчиков. Позволяет команде раз-
работчиков создавать, структурировать, устанавливать приоритеты,
а также отслеживать, контролировать изменения требований, воз-
никающие на любом этапе разработки компонентов приложения.

Также фирма Borland производит:

CaliberRM — система хранения требований в базе данных, которая
поддерживает различные методы визуализации зависимостей между
требованиями. В этой системе управления требованиями имеется
модуль, позволяющий на основе имеющихся требований оценить
трудозатраты, риски и расходы, связанные с их реализацией.

Кроме того, при работе с требованиями могут использоваться сле-
дующие инструменты: Active'. Focus (фирма «Xapware Technologies»);
C.A.R.E. («Sophist Group»); RMTrak («RBC, Inc»); RTMWorkshop («In-
tegrated Chipware, Inc»); State («EDS»); Vital Link («Compliance Auto-
mation, Inc»); DOORS («Telelogic»).

При работе с требованиями инструментальные средства помогают
решать следующие задачи:

•	управление версиями и изменениями — при работе над системой
должна существовать базовая версия требований, гибкое управ-
ление которой можно осуществлять с помощью соответству-
ющего инструмента; некоторые средства позволяют сохранять
историю изменений каждого требования, хранить информацию
об обосновании изменений каждого требования, осуществлять
переход к предыдущим версиям требований, устанавливать связи
между предложениями об изменениях требований и самими из-
менениями;

•	хранение атрибутов требований — система, реализующая эту
функцию, генерирует ряд системных атрибутов для каждого тре-
бования (например, дата и время создания требования), позво-
ляет вносить свои атрибуты и получать список требований, отве-
чающих указанным атрибутам;

•	облегчение анализа воздействия — трассирований требований —
определение связей между различными типами требований,
между требованиями в отдельных подсистемах и между отдель-
ными требованиями и связанными системными компонентами;
эти связи помогают анализировать воздействие, которое предла-
гаемое изменение скажет на конкретное требование, выявляя
другие элементы системы, которые оно затронет;

•	трассирование статусов требований — позволяет осуществить об-
щее трассирование статуса проекта;

•	создание групп пользователей для работы с требованиями — раз-
личные группы пользователей при работе над требованиями могут
иметь различные права доступа к имеющимся требованиям —
от чтения до удаления.

Инструменты проектирования. Данная группа инструментов вклю-
чает в себя средства для создания и проверки программного дизайна.

Можно выделить следующие инструменты проектирования

Rational Suite Development Studio («IBM») — используется для про-
ектирования и реализации программного обеспечения.

Rational Rose («IBM») — средство визуального моделирования
(анализа и проектирования) на основе UML.

Rational XDE («IBM») — средство анализа и проектирования, ин-
тегрируемое с платформами MS Visual Studio,.NET, IBM WebSphere
Studio Application Developer При работе c Rational XDE прог-
раммный код генерируется автоматически, обеспечивая синхрони-
зацию между кодом и моделью (и наоборот), возможно отображение
элементов кода Java и C# в UML.

Oracle Designer («Oracle») — средство моделирования и генерации
приложений, представляющее собой семейство методов и поддер-
живающих их программных продуктов. Приложения создаются
на основе UML-моделей, которые хранятся в общем репозитории,
что позволяет поддерживать работу больших коллективов разработ-
чиков, реализуя многопользовательский режим работы и параллель-
ное обновление. Физическая среда хранения — база данных «Oracle».
В состав Oracle Designer входят следующие компоненты:

•	Repository Administrator — средства управления репозиторием (со-
здание и удаление приложений, управление доступом к данным
со стороны различных пользователей, экспорт и импорт данных);

•	Repository Object Navigator — средство доступа к репозиторию,
обеспечивающее многооконный объектно-ориентированный ин-
терфейс доступа ко всем элементам репозитория;

•	Process Modeler — средство анализа и моделирования бизнес-про-
цессов;

•	Systems Modeler — набор средств построения функциональных
и информационных моделей проектируемой системы, включая
средства для построения диаграммы «сущность—связь», диаграмм
функциональных иерархий, диаграмм потоков данных и средство
анализа и модификации связей объектов репозитория различных
типов;

•	System Designer — набор средств проектирования ПО, включа-
ющий средство построения структуры реляционной базы данных,
средства построения диаграмм, отображающих взаимодействие
с данными, иерархию, структуру и логику приложений, реализу-
емую хранимыми процедурами на языке PL/SQL;

•	Server Generator — генератор описаний объектов базы данных
«Oracle» (таблиц, индексов, ключей, последовательностей и т.д.);

•	Forms Generator — генератор приложений для Oracle Forms, в числе
которых различные экранные формы, средства контроля данных,
проверка ограничений целостности и автоматические подсказки;

•	Repository Reports — генератор стандартных отчетов, интегриро-
ванный с Oracle Reports.

Together Control Center («Borland») — средство анализа и проекти-
рования приложений, в основе которого лежит один из вариантов
похода «Быстрой разработки программного обеспечения» Feature
Driven Development (FDD). Среда поддерживает визуальное модели-
рование на 11 ML, впоследствии код генерируется на Java, С, С#,
C++, Visual Basic; кроме того, поддерживаются платформы J2EE,.
NET. Имеются также варианты для поддержки работы небольшого
коллектива разработчиков Together Solo и редакции для платформы
IBM WebSphere и среды разработки Jbuilder.

AllFusion Modeling Suite («Computer Associates») — интегрирован-
ный комплекс CASE-средств, имеющий следующие инструменты
проектирования:

•	AllFusion Process Modeler (BPWin) — средство функционального
моделирования (моделирования бизнес-процессов), реализующее
метод IDEF0, поддерживающее диаграммы потоков данных DFD
и стандарт IDEF3;

•	AllFusion ERWin Data Modeler (ERWin) — набор средств концепту-
ального моделирования данных на основе метода IDEF1X, реа-
лизующих проектирование схемы базы данных и генерацию ее
описания на языке целевой базы данных (Oracle, Sybase, DB2,
Microsoft SQL Server и др.);

•	Model Mart — средство, обеспечивающее многопользовательский
доступ к моделям, построенным с использованием BPWin и ER-
Win; удовлетворяет таким требованиям, предъявляемым к сред-
ствам управления разработкой крупных систем, как совместное
моделирование (при совместной работе используются три ре-
жима: незащищенный, защищенный и режим просмотра), созда-
ние библиотек стандартных решений и восстановление моделей
(реверсный инжиниринг, на основе существующих БД с помощью
ERwin), управление доступом (можно определять и управлять
правами доступа участников проекта к библиотекам, моделям
и даже к специфическим областям модели).

Инструменты конструирования. Инструменты конструирования
используются для производства и трансляции программного пред-
ставления (например, исходного кода), достаточно детального и яв-
ного для машинного выполнения. Выделяют несколько видов ука-
занных инструментов.

Редакторы — используются для создания и модификации исход-
ного кода программ и, возможно, ассоциированной с ними доку-
ментации (например, javadoc). Это могут быть редакторы «общего
назначения» (что на протяжении многих лет наблюдается в UNIX
и unix-подобных средах) или специализированные редакторы с под-
держкой специфики целевого языка программирования (что явля-
ется в большинстве случаев прерогативой интегрированных сред
разработки — IDE). Однако документирование все же является
не только и не столько частью редактора, сколько самостоятельной
функциональностью, пусть часто и тесно интегрированной с редак-
тором.

Компиляторы и генераторы кода. Традиционно компиляторы яв-
лялись неинтерактивными (командными) трансляторами исходного
кода. Однако существует тенденция интеграции компиляторов и ре-
дакторов в интегрированные среды программирования К этому
классу также относятся препроцессоры, линковщики (загрузчики),
а также генераторы кода (за исключением, может быть, объектно-
ориентированных средств проектирования, поддерживающих связь
с исходным кодом и имеющих тенденцию быть тесно интегрирован-
ными с новым поколением IDE).

Интерпретаторы — обеспечивают исполнение программ посред-
ством эмуляции. Они могут поддерживать действия по конструиро-
ванию ПО. предоставляя для исполнения программ окружение, бо-
лее контролируемое и поддающееся наблюдению, чем это обычно
способна сделать та или иная операционная система. Следует отме-
тить определенную интеграцию компиляторов и интерпретаторов.
Ярким тому свидетельством является использование так называемой
just-in-time компиляции — компиляции «на лету», когда промежу-
точный программный код по мере исполнения или с опережением
(например, в процессе запуска/загрузки программы) преобразуется
в набор инструкций, исполняемых непосредственно средствами ОС,
но под контролем среды исполнения, в первую очередь с точки зре-
ния безопасности. Такого рода подход стал родоначальником ряда
современных программных платформ, например Java и.NET.

Отладчики — выделены в самостоятельную категорию, так как
они поддерживают процесс конструирования ПО, хотя функцио-
нально отличаются от редакторов и компиляторов. Любая совре-
менная среда имеет встроенный отладчик, основные задачи которого
заключаются в трассировке (пошаговом выполнении) программы,
отслеживании, установке или изменении значений переменных
в процессе выполнения кода, установке или удалении контрольных
точек или условий остановки выполнения и т.д. Существуют также
отладчики, не являющиеся частью среды разработки, наиболее по-
пулярные из них приведены ниже:

•	AQtime — коммерческий отладчик для приложений, созданных
для.NET Framework версии 1.0, 1.1, 2.0, 3.0, 3.5 (включая ASP.NET
приложения), а также для Windows 32- и 64-битных приложений;

•	DBX— стандартный отладчик уровня исходного кода для языков
С, C++, Fortran и Java, доступный для операционных систем So-
laris, ALX, IRIX, Tru64 UNIX, GNU/Linux и BSD;

•	DDD — графический фронтэнд к отладчикам DBX и GDB, ис-
пользующий библиотеку виджетов Motif;

•	DTrace — фреймворк динамической трассировки для Solaris, Open
Solaris, FreBSD, MacOS X и QNX;

•	Electric Fence — отладчик памяти;

•	GNU Debugger — портабельный отладчик уровня исходного кода
и дизассемблер из системы программирования GNU, работа-
ющий со многими языками программирования, операционными
системами и системными архитектурами;

•	IDA — дизассемблер и отладчик уровня машинного кода для опе-
рационных систем семейств GNU/Linux и Windows;

•	MDB — универсальный модульный отладчик уровня исходного
кода для Solaris, может использоваться как локальный отладчик
ядра;

•	Microsoft Visual Studio — среда разработки программного обеспе-
чения корпорации «Microsoft», включающая средства отладки
уровня исходного кода;

•	OllyDbg — бесплатный отладчик уровня машинного кода для опе-
рационных систем семейства Windows;

•	SofilCE — отладчик уровня машинного кода для операционных
систем семейства Windows;
•	DR. Watson — стандартный отладчик Windows, позволяет создавать
дампы памяти;

•	TotalView — коммерческий отладчик для Unix;

•	Win Dbg — бесплатный отладчик от корпорации «Microsoft»;

•	FlexTracer — коммерческий отладчик SQL-запросов для различ-
ных СУБД.

Кроме того, на рынке давно присутствуют такие инструменты,
как интегрированные средства разработки (IDE — integrated develop-
ers environment), а также программные библиотеки (библиотеки ком-
понентов), без которых невозможно представить сегодняшний про-
цесс разработки и рынок программных средств.

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

Генераторы тестов — помогают в разработке сценариев тестиро-
вания.

Средства выполнения тестов — обеспечивают среду исполнения
тестовых сценариев в контролируемом окружении, позволяющем
отслеживать поведение объекта, подвергаемого тестированию.

Инструменты оценки тестов — поддерживают оценку результатов
выполнения тестов, помогая определить, в какой степени и где
именно обнаруженное поведение тестируемого объекта соответствует
ожидаемому поведению.

Средства управления тестами — обеспечивают поддержку всех
аспектов процесса тестирования ПО.

Инструменты анализа производительности — используются для
количественной оценки и анализа производительности ПО, являю-
щегося специализированным видом тестирования, цель которого —
оценка поведения программ в части производительности, в отличие
от тестирования корректности функционального поведения.

Рассмотрим некоторые средства, поддерживающие тестирование.

Один из вариантов Rational Suite («IBM») называется Rational Suite
TestStudio, представляет собой целый набор продуктов и предна-
значен для автоматического тестирования приложений.

Компания «Rational» поставляет на рынок следующие прог-
раммные средства.

Quantify — собирает полную статистику о количестве вызовов
функций в тестируемой программе, позволяя тем самым узнавать
временные характеристики отдельных частей приложения. Реализует
следующую функциональность: выдает точную и детальную инфор-
мацию о производительности приложения; указывает на все узкие
места в приложении (как в пользовательском коде, так и в системных
вызовах); представляет комплексный дополнительный обзор данных
по производительности (построение дерева вызовов, списка
функций, вызов исходных текстов тестируемых функций (при раз-
работке в Visual Studio)); имеет гибкую настройку по желаниям и по-
требностям пользователя; позволяет многократно тестировать при-
ложение (по ходу разработки), позволяя отслеживать изменения
в количестве вызываемых функций; предоставляет возможность
интеграции с Visual C++ с возможностью вызова исходных текстов
функций тестируемого приложения; интегрируется с Rational Robot,
ClearQuest и Visual Test; поддерживает Visual C++, Visual Basic- и Vi-
sual Java-приложения.

Pure Coverage — позволяет быстро найти участки кода, пропущен-
ные при тестировании. Обеспечивает: подсчет количества вызовов
функций; указание областей кода в них, не прошедших процедуру
тестирования; интеграцию с Visual Studio; импортирование резуль-
татов в MS Excel или Word

Purify — отлавливает все ошибки, связанные с утечкой памяти,
а также некоторые Run-time-ошибки. Располагает следующими воз-
можностями: отслеживание ошибок доступа к памяти; сбор и вывод
статистики по исполвзованию памяти; использование комплексного
подхода к тщательному тестированию; поддержка технологии OCI —
Object Code Insertion, которая позволяет детально отследить и выло-
вить ошибку не только в контролируемом модуле, но и в модулях
DLL сторонних разработчиков; тестирование ActiveX, COM/DCOM,
ODBC, DLL; настраиваемый, двухуровневый способ тестирования
приложений; интеграция с Visual Studio; открытое API, которое по-
зволяет дописывать разработчикам собственные модули и присоеди-
нять их; совместная работа с любым отладчиком; тестирование сис-
темных вызовов.

Rational Test Manager — средство планирования функционального
и нагрузочного тестирования.

Rational Robot — средство записи и воспроизведения тестовых сце-
нариев.

Rational Test Factory — средство тестирования надежности.

Rational Quality Architect — средство генерации кода для тестиро-
вания.

Optimizeit Suite, Optimizeit Profiler for.NET (корпорация «Borland»)
позволяют выявить потенциальные проблемы использования аппа-
ратных ресурсов — памяти и процессорных мощностей на платфор-
мах J2EE H.Net соответственно.

Optimized ServerTrace — предназначена для управления произво-
дительностью серверных 12ЕЕ-приложений с точки зрения дости-
жения заданного уровня обслуживания и сбора контрольных данных
по виртуальным Java-машинам.

Инструменты сопровождения. Рассмотрим две категории инстру-
ментов сопровождения.

Инструменты облегчения понимания — помогают человеку в пони-
мании программ. Примерами могут служить различные средства
визуализации.

Инструменты реинжиниринга — поддерживают деятельность
по реинжинирингу.

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

Среди компаний, выпускающих CASE-средства, поддержива-
ющих сопровождение, выделяют «Gemini Consulting» с методологией
Construct и Andersen Consulting (продукт Eagle). Особенностью инстру-
ментов реинжиниринга является сочетание в одной среде инстру-
ментов для специалистов двух областей:

1)	непосредственно реинжиниринга бизнес-процессов;

2)	разработчиков ПО, поддерживающего модифицируемый биз-
нес-процесс.

Среда Clear Quest от компании «Rational» представляет собой сред-
ство управления запросами на изменение, используется для контроля
изменений в рамках всего ЖЦ ПО, а также может быть использовано
для поддержки процесса реализации запроса на сопровождение, по-
скольку и устранение дефектов, и расширение функциональности
связаны с изменением многих артефактов продукта. Основные воз-
можности: управление изменениями, возникающими в ходе про-
цесса разработки ПО; оптимизация пути прохождения запросов
на изменения, а также связанных с ним форм и процедур; поддержка
через WWW связи внутри команд, распределенных территориально;
внедрение надежного и проверенного процесса CRM (Change Re-
quest Management — управление запросами на изменение) либо из-
менение уже существующего процесса для удовлетворения специ-
фическим требованиям; визуальный анализ прогресса проекта с по-
мощью возможностей графического представления информации
и отчетов; интеграция со средствами конфигурационного управ-
ления, такими как Rational ClearCase, позволяющая создавать связи
между запросами на изменение и развитием кода; поддержка ос-
новных СУБД от производителей «Sybase», «Oracle», «Microsoft»;
тесная интеграция со всеми средствами тестирования «Rational»,
такими как TeamTest, VisualTest, Purify, PureCoverage, Quantify и Ro-
bot; построение профессиональных отчетов на базе Crystal Reports
(входящего в состав поставки в конфигурации Professional); интег-
рация через СОМ с MS Word и MS Excel; наличие системы настраи-
ваемых триггеров для расширения возможностей.

В общем случае любой из рассмотренных в предыдущих разделах
продуктов , поддерживающих процесс «понимания» программных
систем и контроля изменений, можно использовать как инструмент
сопровождения.

Инструменты конфигурационного управления. Конфигурацион-
ное управление весьма трудозатратно, поскольку приходится
содержать в актуальном состоянии одновременно множество ар-
тефактов ПП; поддержка процесса управлением конфигура-
циями — важный аспект, касающийся инструментов программной
инженерии.

В рамках системы Together ControJCenter (визуальная среда про-
ектирования от «Borland») реализована технология LiveSource, кото-
рая обеспечивает синхронизацию между проектом приложения и из-
менениями. Контроль версий осуществляется благодаря функцио-
нальной интеграции Together и системы StarTeam. Поддерживается
также интеграция с системой управления конфигурацией Rational
ClearCase Выпускаются следующие версии StarTeam.

StarTeam Express Edition — поддерживает работу небольших кол-
лективов разработчиков (до десяти человек).

StarTeam Enterprise Edition — предназначен для команд разработ-
чиков среднего размера.
StarTeam Enterprise Advantage Edition — поддерживает работу боль-
ших коллективов разработчиков, в том числе географически распо-
ложенных в различных местах.

В процессе работы над проектом все артефакты ПП располага-
ются в едином репозитории, что обеспечивает доступ к ним всем
участникам проекта.

Компания «1ВМ» выпустила Rational ClearCase — инструмент, ко-
торый упрощает ведение процесса управления версиями и конфигу-
рациями.

Он помогает наладить эффективный контроль за любыми артефак-
тами проекта: документами, исходными текстами, моделями, целыми
репозиториями проекта, дополнительными файлами и т.д. С помощью
Rational ClearCase можно организовать версионный контроль
не только отдельных файлов, но и целых каталогов. Можно создавать
новые версии целых рабочих пространств и окружений. Для каждого
артефакта, поставленного на контроль, ведется история изменений.
К любой версии можно вернуться в любой момент времени. Для лю-
бых двух разных версий одного и того же артефакта можно посмотреть
отличия, если, конечно, эти артефакты принадлежат стандартным
типам документов, таким как текстовые файлы, документы MS Word
и модели Rational Rose. Возможности Rational ClearCase в области
конфигурационного управления позволяют организовать параллель-
ную работу над отдельными конфигурациями и версиями одного
и того же продукта или его части (ветвления версий). Всегда можно
провести интеграцию нескольких ветвей в основную версию. Для
этого существует удобный графический инструментарий. Данные,
поставленные на версионный и конфигурационный контроль под
управлением Rational ClearCase, хранятся в БД специального формата,
так азываемой Version Object Bases (VOB). Участники проекта имеют
доступ к любой из этих VOB через представления (Views), каждое
из которых отображает некоторый срез проектных данных из VOB.
Таким срезом может быть, например, набор артефактов, относящихся
к некоторой версии или конфигурации разрабатываемого продукта.

Представления бывают двух типов: динамические и статические.
Динамическое представление (dynamic view) отображает артефакты,
актуальность которых гарантируется в любой момент времени,
т.е. если один из участников проекта изменил один из артефактов,
то любой другой участник проекта будет работать всегда с последним
вариантом этого артефакта. Но для работы с динамическими пред-
ставлениями требуется постоянное подключение к серверной части
Rational ClearCase. Статическое представление (snapshot view) — это
своеобразный снимок набора артефактов, который позволяет рабо-
тать с ними без постоянного подключения к серверу

Можно выделить следующие версии Rational ClearCase:

•	Rational ClearCase LT— продукт, предназначенный для небольших
рабочих групп, отличается от полнофункционального ClearCase
отсутствием динамических представлений, работой в однодомен-
ном окружении и отсутствием поддержки ClearCase Multisite. Ra-
tional ClearCase LT предоставляет основные средства контроля
версий компонентов разработки, идеально подходит для неболь-
ших и средних коллективов разработчиков, расположенных в од-
ном месте, входит в состав платформы «IBM» Rational Team Uni-
fying Platform и пакета WebSphere Studio Application Developer;

•	IBM Rational ClearCase MultiSite — дополнительная система для
Rational ClearCase, предназначенная для управления географиче-
ски распределенными программными ресурсами, задействован-
ными в средних и крупных проектах; обеспечивает автоматиче-
скую безошибочную репликацию для географически удаленных
помещений, легко масштабируется и способна обеспечить под-
держку проектов любого размера, обеспечивает эффективное об-
новление информации, передавая разработчикам толвко инкре-
ментные изменения, произошедшие в репозиториях проектов
Rational ClearCase, обеспечивает удобные средства автоматиче-
ского резервного копирования и восстановления.

Rational ClearCase интегрируется в следующие рабочие среды:
Microsoft Visual Studio, IBM VisualAge for Java, IBM WebSphere Studio,
Sybase PowerBuilder, Microsoft Word и др. Специальные настройки
графического интерфейса позволяют разработчикам в большей сте-
пени концентрироваться на решении конкретных задач, не отвлека-
ясь на рутинные процедуры.

Объединение процессов конфигурационного управления и управ-
ления изменениями с помощью механизмов Unified Change Manage-
ment (UCM) значительно повышает возможности проекта в области
контроля изменений для отдельных артефактов, являясь функцио-
нальной надстройкой над Rational ClearCase; механизм UCM авто-
матизирует многие операции, обеспечивая параллельную работу
с артефактами и их наборами.

Инструменты управления инженерной деятельностью. Эти средства
подразделяются на следующие категории.

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

Инструменты количественной оценки — используются при выпол-
нении работ, связанных с программой количественной оценки, про-
водимой в отношении проектов ПО.

Инструменты для упрощенного доступа к проектным данным.

Инструменты для организации коммуникаций.

Инструменты для интеграции с другими приложениями.

Можно привести следующих производителей вышеперечислен-
ных инструментов: «Primavera Systems» (продукт SureTrak Project
Manager)', «Microsoft» (продукт MS Project)', «Project Management Tech-
nologies» (продукт Spider).

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

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

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

Во всех трех системах возможно планирование затрат: предостав-
ляется возможность поддержания учета стоимости отдельных работ,
времени работы исполнителей, использования единицы материаль-
ного ресурса или часа эксплуатации оборудования, а также статьи
фиксированных затрат. К тому же инструменты от «Pnmavera» и «Mi-
crosoft», в отличие от Spider, позволяют учитывать отдельно стои-
мость урочной и сверхурочной работы исполнителей. Одновременно
Spider допускает использование фиксированных затрат, не связанных
с длительностью и объемом работы.

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

Программный модуль проектной оптимизации разработки Spider,
функционируя в мультипользовательском режиме, создает набор
файлов, который рассылается по FTP всем менеджерам проекта;
и таким образом, каждый из участников работ постоянно находится
в курсе выполненного объема задач. Аналогично действуют и про-
дукты Primavera и MS Project, но используя СУБД Доступ к по-
следним осуществляется через глобальные и локальные сети (пра-
вила доступа четко регламентируются). Дополнительное достоинство
MS Project — способность поддерживать интегрированный докумен-
тооборот в проектной группе благодаря тесной интеграции с сервер-
ными продуктами компании.

Инструменты поддержки процессов. Существует несколько типов
инструментов, имеющих особое значение в поддержке процессов
программной инженерии.

Инструменты моделирования, позволяющие, в частности, описать
и модель процессов как таковую.

Инструменты управления проектами.

Инструменты конфигурационного управления, поддерживающие
работу с актуальными версиями всего комплекса артефактов проекта
и позволяющие задать поведенческие характеристики (в упрощен-
ном понимании — workflow) и атрибуты этих артефактов в форме
элементов конфигураций.

Ролевые платформы разработки ПО, охватывающие все стадии
ЖЦ и являющиеся развитием интегрированных средств разработки
и CASE-инструментов в направлении поддержки «смежной» функ-
циональности — управления требованиями, работ по конфигураци-
онному управлению с поддержкой управления изменениями, тести-
рования и оценки качества.

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

Инструменты обеспечения качества. Средства обеспечения каче-
ства делятся на две категории.

1.	Инструменты инспектирования — используются для поддержки
обзора (review) и аудита.

2.	Инструменты (статического) анализа — используются для ана-
лиза программных артефактов, данных, потоков работ и зависимо-
стей. Такие инструменты предназначены для проверки определенных
свойств или артефактов в целом на соответствие заданным характе-
ристикам. Например, можно использовать средство выявления не-
протестированных участков кода для определения качества тестиро-
вания.

Литература

1	Андрейчиков А.В , Андрейчикова О Н Интеллектуальные информацион-
ные системы — М.: Финансы и статистика, 2004. — 424 с.

2.	Брауде Э. Технология разработки программного обеспечения. — СПб/
Питер, 2004. — 665 с.

3.	Вигерс К.И. Разработка требований к ПО. — М/ Русская редакция,
2004 - 575 с.

4.	Соммервилл И. Инженерия программного обеспечения: 6-е изд.— М :
Вильямс, 2002. — 624 с.

5.	Вендров А.М. Современные технологии создания программного обес-
печения // CIT FORUM. — http://citforum ru/programming/application/
program/3.shtml.

6.	Гнатуш А. Реинжиниринг: малое во многом // CIT FORUM. — http://
citforum.ru/programming/case/gnatush/lot.shtml.

7.	Новичков А.Н. Средства тестирования от компании Rational // CIT FO-
RUM. — http://citforum.ru/programming/rational/rationaltest.shtml.

8.	Новичков А.Н. Управление изменениями, тестированием и документи-
рованием с использованием технологий Rational // CIT FORUM. —
http://citfon.im ru/programmir.g/digest/ucm_rational.shtml.

9.	Орлик С. Программная инженерия и SWEBOK // Инструменты и ме-
тоды программной инженерии. — http://swebok.sorlik.ru / software engi-
neering/ Tools and methods html.

10.	Borland DATA SHEET STARTEAM 2009 R2. - http://www.borland.com/
resources/en/pdf/products/starteam/starteam-datasheet.pdf.

11.	Interface IBM Rational ClcarCase//lNTERFACE (INTERNET & SOFT-
WARE COMPANY). — http://www.interface.ru/fset.asp?Url=/rational/cc/
caseh.htm.
ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ....................................................3

Глава!
ОСНОВНЫЕ ПОНЯТИЯ ...........................................б

1.1.	Программная инженерия и программные инженеры...........б

1.2.	Программный продукт....................................9

1.3.	Понятие проекта.......................................12

1.4.	Технологии программирования	..........................16

1.5.	Термины и определения................................ 21

Контрольные вопросы........................................22

Литература.................................................23

Глава 2
ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ПРОДУКТА	24

2.1.	Понятие жизненного цикла программного продукта........24

2.2.	Определение жизненного цикла программного продукта....26

2.3.	Модели жизненного цикла программного продукта.........37

2.4.	Модели пооцесса разработки программного продукта....  47

Контрольные вопросы........................................54

Литература.................................................55

Глава 3
МОДЕЛИ И ПРОЦЕССЫ УПРАВЛЕНИЯ

ПРОГРАММНЫМ ПРОЕКТОМ ......................................57

3L1. Общие вопросы............................      ..	57

3.2.	Управление проектами и СМ.М...........................60

3.3.	Процессы программного проекта ................67

3.4.	Инициация проекта ....................................70

3.5.	Планирование проекта..............................    80

3.6.	Исполнение и завершение проекта.......................99

3.7.	Мониторинг и управгение проектом.....................108

Контрольные вопросы.........................................117

Литература........................................        118
Глава 4
РАЗРАБОТКА ТРЕБОВАНИЙ.........................................120

4.1.	Определение программных	1ребэваний.....................120

4.2.	Разработка требований....................................129

4.3.	Работа с требованиями................................... 143

Контрольные вопросы.......................................... 155

Литература....................................................155

Глава 5
ПРОЕКТИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ ............................157

5.1.	Основы проектиэования....................................157

5.2.	Ключевые вопросы проектирования..........................160

5.3.	Архитектура пэсраммного обеспечения......................162

5.4.	Архитектурные стили проектирования ......................171

5.5.	Графическое представление архитектуры....................185

5.6.	Анализ качестза и оценка программного дизайна............190

5.7.	Программные средс~ва.....................................192

Контрольные вопросы...........................................192

Литература....................................................193

Глава 6
КОНСТРУИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	194

6.1.	Основы конструиоования...................................194

6 2.	Разработка баз данных....................................195

6.3.	Стиуктурное прогдаммиоование ............................207

б4.	Обьектно-ориенгированнос npoi раммировачие ..............212

6.5,	Шаблоны проектирования...................................224

6.6.	Система управления версиями .............................232

6.7.	Про! раммные средства................................... 234

Контрольные вопросы............................................235

Литература..... .............           .....................236

Глава 7
ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ........................238

7.1.	Основы тестирования.......„....................          238

7.2.	Виды тестирования........................................242

7.3.	Работа с ошибками........................................247
7 А. Тестирование с использованием тест-комплектсв.......249

7.5. Программные средства......................._........250

Контрольные вопросы .....................................251

Литература...............................................252

Глава 8
СОПРОВОЖДЕНИЕ ПРОГРАММНЫХ СИСТЕМ.........................253

8.1.	Базовые понятия.....................................253

8.2.	Организация и управление процессом сопровождения....260

8.3.	Ресурсы, необходимые дла сопровождения..............274

Контрольные вопросы......................................277

Литература...............................................277

Глава 9

КАЧЕСТВО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ	279

9.1. Основы качества программного обеспечения ...........279

9 2. Метрики и атрибуты качества.........................289

9.3. Управление качеством................................295

9.4. Надежность как главная составляющая качества _______300

Контрольные вопросы......................................306

Литература...............................................307

СПИСОК ИСПОЛЬЗУЕМЫХ СОКРАЩЕНИЙ, ОБОЗНАЧЕНИЙ
И ИНОСТРАННЫХ ТЕРМИНОВ...................................309

Пиипожение

ИНСТРУМЕНТЫ И МЕТОДЫ, ИСПОЛЬЗУЕМЫЕ
ПРИ РАЗРАБОТКЕ ПРОГРАММНЫХ СИСТЕМ........................313

Литература ...........................                   327
Учебное издание

Владимир Анатольевич Антипов
Алексей Алексеевич Бубнов
Александр Николаевич Пылькин
Вячеслав Константинович Столчнев

ВВЕДЕНИЕ

В ПРОГРАММНУЮ
ИНЖЕНЕРИЮ

Учебник

Оригинал-макет подготовлен в Издательстве «КУРС»

Подписано в печать 05.04.2019.

Формат 60x90/16. Бумага офсетная. Гарнитура Newton,
Печать цифровая. Усл. печ. л. 21,0.

Доп. тираж 100 экз. Заказ №

ТК 656041-850951-261017

ООО Издательство «КУРС»

127273, Москва, ул. Олонецкая, д. 17А, офис 104.
Тел.: (495) 203-57-83.

E-mail: kursizdat@gmail.com http://www.kursizdat.ru

ООО «Научно-издательский центр ИНФРА-М»

127282, Москва, ул. Полярная, д. 31В, стр. 1
Тел,- (495) 280-15-96, 280-33-86. Факс: (495) 280-36-29
E-mail: books@infra-m.ru http://www.infra-m.ru
Дия заметок
Для заметок
Дия заметок
Для заметок
Дия заметок