Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

30 Глава 1

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

чественного программного продукта.

В зависимости от стратегических целей усовершенствования БПО, а также

наличия соответствующей организационной структуры (например, групп качества,

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

для внедрения в БПО в полном объеме (все действия) или частично (не все дейст-

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

тегории процессов (основных, поддерживающих, организационных). Кроме того,

отдельные действия (или группы действий) поддерживающих процессов могут де-

легироваться основным или организационным процессам. Это возможно, напри-

мер, в организациях, разрабатывающих однотипные программные продукты в рам-

ках коротких проектов, где многие поддерживающие процессы (например, верифи-

кация, валидация, управление конфигурацией и др.) могут быть инкорпорированы в

процесс управления проектом. В минимальной конфигурации процессов ЖЦ,

кроме процесса управления проектом, в БПО обязательно должно найтись место

процессу проверки (интеграции процессов поддержки, направленных на проверку

правильности каждого рабочего продукта процесса), а также процессу управления

конфигурацией (рисунок 1.3).

РП1 для использования на

следующей стадии

Конфигурация

РП1

РП2

ПП

Заказчику

Планиро

-вание

Выпол-

нение

Проверка

план РП1

РП1

(до пров.)

РП1 (после

пров.)

Возврат на переделку

Контроль

проекта

Планиро

-вание

Выпол-

нение

Провер-

ка

план РП2

РП2

(до пров.)

РП2 (после

пров.)

Возврат на переделку

Контроль

проекта

Рис. 1.3. Жизненный цикл рабочих продуктов БПО

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

который вносит вклад в построение конечного программного продукта, должен

пройти стадии проверки (лучше независимой), утверждения и помещения под

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

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

Принцип интеграции процессов в БПО состоит в инкорпорации нужных на-

правлений деятельности в совершенствуемый процесс (в случае отсутствия и неце-

лесообразности формирования смежных процессов), или, наоборот, в делегирова-

нии ряда действий процесса другим, уже существующим, процессам ЖЦ.

Глава 1

В описании БПО определяются также требования к квалификации специали-

стов и их ролям в процессах ЖЦ. С понятием роли мы связываем перечень обязан-

ностей в процессе ЖЦ, используемых методов и средств, ответственности за рабо-

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

сах, а также возможное совмещение ролей.

Построенный БПО должен поддерживать использование моделей ЖЦ, при-

менение которых допускается в проектах организации. Для этого в описании БПО

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

(например, рабочие продукты и моменты их передачи от одного процесса другому

процессу), условия повторного выполнения процессов и методы выполнения работ,

обусловленные выбором той или иной модели ЖЦ.

Широко распространены следующие основные классы моделей ЖЦ:

 каскадные

 стандартная

 с обратной связью

 пилообразная

 итерационные

 с приращениями

 эволюционные

 спиральная

 быстрой разработки приложений (RAD)

Краткий обзор этих моделей можно найти в приложении 1.

Выбор модели ЖЦ существенно зависит от двух факторов (если не прини-

мать в расчет финансовые соображения):

А) можно ли изначально определить практически полный набор функций,

подлежащих реализации в программном продукте:

PP = {F

, F

,…F

}

Б) должны ли все затребованные функции F

, F

,…F

поставляться заказчику

одновременно.

Если выполняются условия А и Б (требования известны (А) и нужна одно-

временная поставка всех функций (Б)), - для применения в проекте рекомендуется

выбирать каскадные модели.

Если выполняются условия А и !Б (не Б) (требования известны (А) и согласо-

вана поставка итерациями (!Б)), - может быть выбрана итерационная модель с при-

ращениями.

Если выполняются условия !А и Б (не все требования известны (!А), но все

известные - должны быть реализованы и поставлены одновременно (Б)), а также

желательна разработка прототипов для моделирования требований - возможно

применение спиральной модели, при условии, что требования будут меняться не-

часто и будут выполняться оценки риска реализуемости и планирование разработ-

ки.

Если выполняются условия !А и !Б (не все требования известны (!А), а все

известные реализуются и поставляются итерациями (!Б), и желательна разработка

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

приложений (RAD), при условии, что прототипы будут охватывать каждый набор

требований и сроки разработки не будут четко установлены.

32 Глава 1

Методология экстремального программирования (XP) (которая получила за-

служенное признание программистов) безусловно пригодна для использования в

проектах с быстрой разработкой приложений, однако требует практически посто-

янного участия заказчика и не предполагает документирования проекта, а это – су-

щественная преграда для применения ХР в проектах, выполняемых по государст-

венным заказам. Подробнее об этой методологии – в главе 11.

Выбранная для проекта модель ЖЦ должна согласовываться с заказчиком и

фиксироваться в договорных документах. Кроме того, в них должны фиксировать-

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

Если модель – заведомо не каскадная, с заказчиком нужно оговаривать, ка-

ким образом будут появляться (исчезать) и расширяться функции ПС, установлен-

ные в требованиях (например, путем оформления дополнительных соглашений к

договору и переноса сроков)? Каким должен быть уровень поддерживаемой цело-

стности проекта, то есть, какие документы проекта должны переделываться и по-

вторно утверждаться при изменениях? То есть, какова высота уровня возвратов в

проекте – возврат на переделку постановок задач для приложений? Возврат на кор-

ректировку технического задания? и др.

Очевидно, что целостность проекта ПС должна поддерживаться на уровне

документа исходных требований к ПС. Это тот основной документ, с положе-

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

ния ПС, а также тот единственный документ, который используется тестировщика-

ми при проверке соответствия программного продукта исходным требованиям

(действительно, может ли, например, тестировщик определить полноту функций

приложения, если нигде не указано, какие именно функции приложение должно

выполнять?).

Практика показывает, что в крупных проектах систем исходные требования

достаточно четко формулируются только на уровне постановок задач для каждого

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

Это тот уровень разработки, на котором уже ясны (хотя и не всегда стабилизирова-

ны) функции приложений, информационные объекты и условия среды их функцио-

нирования, но еще не приняты окончательные решения относительно структуры

приложений, информационно-программной среды реализации и др.

После выбора модели ЖЦ для проекта, должна быть выполнена адаптация

БПО к условиям этого проекта и утвержденной модели ЖЦ. Описание БПО нужно

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

ствий, ролей, а также состава, структуры и содержания рабочих продуктов ПС.

Для выполнения адаптированного процесса в проекте разрабатывается план

управления проектом.

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

Применительно к программной инженерии виды деятельности по управле-

нию образуют двухуровневую структуру.

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

ствия на процессы разработки программных систем в организации, например, стра-

тегического, тактического и оперативного планирования работ, корпоративной

культуры и поведения коллектива организации, функционального и производст-

Глава 1

венного управления приобретением, снабжением, торговлей, сбытом и распреде-

лением продукции.

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

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

нию выполнением программных проектов: графиком разработки программной сис-

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

проекта, риском проекта, качеством программных продуктов и пр.

Управление проектами (в любой отрасли) – это область знаний, навыков,

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

согласованных параметров качества, бюджета, сроков и прочих ограничений [5].

Современная концепция управления проектом основана на принципе инфор-

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

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

ного, страдает недостаточной обоснованностью принимаемых решений, а измере-

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

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

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

оценивания результатов измерений и управления проектом в целом.

Управление проектом включает следующие шаги:

1. Инициация проекта и определение его границ. Предполагает определение

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

оценивания их осуществимости с различных точек зрения (технической, техноло-

гической, финансовой, социально-политической).

2. Планирование. Предполагает:

• выбор модели ЖЦ проекта и оценивание процессов ЖЦ в контексте при-

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

организации и их институциализацию в проекте;

• иерархическую декомпозицию задач проекта, их спецификацию наряду с

установленными требованиями, ассоциируемыми рабочими и поставляемыми про-

дуктами;

• оценки объемов работ, трудоемкости и стоимости реализации проекта;

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

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

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

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

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

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

также верификация и валидация (V&V) продуктов. Управление качеством и V&V

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

та;

• управление планом проекта. Необходимость управления планом проекта

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

ния проекта. Это делает процесс планирования проекта итеративным.

3. Ввод в действие. Предполагает выполнение выбранных процессов ЖЦ в

соответствии с планом наряду с измерениями, мониторингом и регулированием

процессов и составлением отчетов для заинтересованных сторон (руководства ор-

ганизации, заказчиков, соисполнителей).

34 Глава 1

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

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

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

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

ресурсов, соответствие требованиям и стандартам по качеству. Оцениваются от-

клонения измеренных значений величин от ожидаемых (в частности, стоимости,

сроков, качества). Пересматриваются величины и приоритеты рисков.

Результаты процесса мониторинга создают базис для принятия решения о ре-

гулировании процессов в проекте - повторном выполнении определенных действий

(например, повторном тестировании компонентов) или инкорпорации новых дейст-

вий в процесс (например, разработке прототипов компонентов с целью идентифи-

кации и утверждения требований к ним). В ходе регулирования возможны также

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

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

фигурацией ПС. Принимаемые решения документируются и доводятся до всех за-

интересованных лиц.

4. Обзор и оценка выполнения проекта. Предполагает выполнение всеобъем-

лющей проверки деятельности по проекту и оценки его продвижения к установлен-

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

ся не только результаты выполнения процессов, но и эффективность применяемых

методов и инструментов, а также продуктивность работы коллектива проекта и

возможные трудности (например, конфликты между членами проекта). При необ-

ходимости, осуществляется регулирование.

5. Закрытие проекта. Предполагает прекращение проекта по завершении

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

щих планах. Оценивается успешность проекта по отношению к установленным

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

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

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

знаний о процессах ЖЦ ПС и необходимого совершенствования базового процесса

организации. ПС передается в эксплуатацию.

1.1.7. Процесс измерения при управлении проектами

Современный уровень развития программной инженерии позволяет вывести

проблему качества ПС за рамки простого вопроса, «работает система или нет?»,

формулируя ее следующим образом: «насколько точно созданная система удовле-

творяет установленным измеримым требованиям к ее качеству?». Откладывать по-

иск ответа на этот вопрос до момента завершения разработки – слишком большой

риск как для заказчика, так и для разработчика, особенно в условиях все возрас-

тающей сложности и масштабов ПС. Очевидно, что цели по качеству ПС должны

определяться в таком виде, чтобы их достижение можно было своевременно про-

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

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

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

ЖЦ. Следовательно, измерения должны стать неотъемлемой частью ЖЦ проекта.

Измерение – получение объективных данных о состоянии продуктов, процес-

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

Глава 1

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

ганизации.

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

шаговый процесс, включающий следующие шаги:

1. Определение целей программы измерения. Несистематизированные подхо-

ды к измерению не способствуют проникновению в суть процессов, выполняемых в

организации, и дают результаты, которые невозможно оценить и обобщить. Все

измерения должны мотивироваться высшими целями организации и трансформиро-

ваться в частные цели улучшения тех процессов ЖЦ ПС, выполнение которых бу-

дет способствовать достижению высших целей.

2. Построение процесса измерений. Модель измерений является целеориен-

тированной, основанной на процессе декомпозиции целей и построении вопросов,

поиск ответов на которые способствует пониманию и достижению целей. Модель

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

тированных ответов на вопросы, подкрепленных количественными оценками, ос-

нованными на измеримых величинах в модели.

3. Выбор базовых мер. Базовые меры выбираются таким образом, чтобы ре-

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

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

направления и масштабы усовершенствований процессов программной инженерии

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

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

жет быть оценена трудоемкость и стоимость разработки;

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

в целом;

• меры измерения атрибутов качества;

4. Организация сбора данных для выполнения измерений. Собираемые данные

должны обеспечивать не только высокие предсказательные возможности измере-

ний, но и быть достаточно «дешевыми» с точки зрения их получения, а также до-

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

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

вопросники, графики, диаграммы и другие автоматизированные и ручные инстру-

менты, способные обеспечить минимальную трудоемкость сбора, обработки и ин-

терпретации данных. Тем не менее, сбор и обработка данных для измерений оста-

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

ганизации и дополнительных инвестиций в разработку ПС.

5. Применение моделей. Основная цель применения моделей измерений в

проектах – обеспечение адекватного управления проектами на всем протяжении их

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

оцениваются с позиций эффективности их применения. Основная цель применения

моделей на уровне организации в целом – совершенствование процессов про-

граммной инженерии.

1.1.8. Аспекты определения качества

Качество, по определению стандарта ДСТУ 2844, это совокупность свойств

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

ленные или предполагаемые потребности в соответствии с назначением [6].

36 Глава 1

При определении требований к качеству, обычно перечисляются внешние

характеристики качества, отражающие требования к функционирующему про-

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

цировать) критерии качества, по которым будет осуществляться проверка и под-

тверждение соответствия ПС предъявляемым к ней требованиям, специфицируют-

ся: подходящие внешние измеримые свойства (внешние атрибуты) ПС и связан-

ные с ними метрики (или показатели), представляющие собой модели оценивания

атрибутов; приемлемые диапазоны изменения значений (мер) соответствующих

атрибутов.

Метрики, определение и применение которых возможно только для рабо-

тающего на компьютере программного обеспечения, находящегося на стадии тес-

тирования или функционирования в составе системы, называются внешними мет-

риками.

После определения требований к внешним метрикам специфицируются

внутренние характеристики качества и внутренние атрибуты ПС. Они исполь-

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

конечного программного продукта и их встраивания в промежуточные (рабочие)

продукты ПС в ходе разработки. Далее специфицируются внутренние метрики для

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

ваться для проверки соответствия промежуточных продуктов спецификациям

внутренних требований к качеству на стадиях разработки.

Понятия внутренних характеристик качества, атрибутов и метрик связывает-

ся с не работающими на компьютере рабочими продуктами ПС (документами, тек-

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

тестированию (определение требований, проектирование, кодирование).

Нужно отметить, что внешние и внутренние характеристики качества каса-

ются свойств самой ПС (работающей или не работающей). Они отражают, в боль-

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

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

го эффекта от применения ПС - повышения продуктивности работы и общей удов-

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

ся термином «качество в использовании» или «эксплуатационное качество» ПС.

Качество ПС в использовании - совокупный эффект характеристик качества

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

не свойств самой программной системы. На качество в использовании может вли-

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

теристика (например, удобство применения или надежность).

Качество ПС должно оцениваться исходя из определенной модели качества.

В соответствии со стандартом ISO/IEC 9126 модель качества представляет

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

фикации требований к качеству и оценивания качества ПС [7].

На качество ПС, а также на выбор модели качества, множества внешних и

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

вания к качеству [8]:

1. Прикладная область и категории пользователей. Модель качества может

включать множество характеристик качества. Но, каждая из этих характеристик

имеет тот или иной вес (значимость) в определенной прикладной сфере и для соот-

Глава 1

ветствующего сообщества пользователей и отражает точку зрения на качество от-

дельных категорий пользователей.

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

творением требований к защищенности информации, безопасности функциониро-

вания, достоверности, производительности и др. Причем, атрибут производитель-

ность (реактивность) наиболее важен для жестких систем реального времени, дос-

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

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

вания важна с позиций анализа угроз и инженерии безопасных систем. Этот фактор

необходимо учитывать как один из основных при формировании модели качества

конкретной ПС.

2. Цель моделирования качества. В зависимости от цели моделирования ка-

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

тегорий участников процессов разработки и эксплуатации (сопровождения) ПС -

менеджеров, разработчиков, персонала сопровождения, пользователей, - и содер-

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

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

ваться на учете приоритета (по значимости, по времени удовлетворения) тех или

иных интересов.

В большинстве случаев приоритетным, с точки зрения участников проекта

ПС, является взгляд менеджера и его интересы в управлении риском проекта.

3. Стадия жизненного цикла. Для того чтобы должным образом управлять

качеством на каждой стадии ЖЦ ПС, необходимо рассматривать разнообразные

аспекты качества и учитывать изменение представлений о качестве с течением ЖЦ.

Стандарт ISO/IEC 9126 предлагает варьировать взгляды на качество продукта по

стадиям ЖЦ следующим образом:

• целевое качество - необходимое и достаточное качество, которое отража-

ет реальные потребности пользователя. Поскольку потребности, заявленные заказ-

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

программного продукта, и эти нужды могут изменяться после того, как заявлены

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

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

должна рассматриваться как ориентир. Требования к целевому качеству должны по

возможности включаться в спецификацию требований к качеству ПС и оцениваться

путем измерения эксплуатационного качества по завершении разработки про-

граммного продукта;

• затребованное (установленное) качество продукта - это тот уровень

значений характеристик внешнего качества, который фактически заявлен в специ-

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

ки. Требования ко всем или некоторым характеристикам качества указываются в

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

стик должны также указываться минимальные значения, что поможет заказчикам и

разработчикам избежать ненужного превышения стоимости и сроков разработки;

• качество программного проекта – внутреннее качество ПС, представ-

ленное в описании основных частей или всего проекта, например, архитектуры

программного обеспечения, структуры программ, стратегии проектирования ин-

терфейса пользователя и т.п. Качество проекта – основа качества программного

38 Глава 1

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

тестирования;

• оцененное (или прогнозируемое) качество продукта - качество, которое

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

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

проекта;

• качество поставляемого продукта - это качество готового к поставке

продукта, как правило, протестированного в моделируемой среде на моделируемых

данных.

• качество в использовании (эксплуатационное качество) - качество ПС,

измеряемое в терминах результатов ее использования, а не свойств. Качество ПС в

пользовательской среде может отличаться от качества в среде разработки из-за не-

доучета особенностей среды и сценариев применения ПС и, как следствие, неадек-

ватного тестирования. Пользователь оценивает только те атрибуты ПС, которые

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

4. Размер и сложность. За исключением очень простых проектов, различные

компоненты ПС обычно имеют совершенно разные требования к характеристикам

качества. Например, компоненты, обеспечивающие интерфейс с пользователем,

характеризуются высокими требованиями к удобству применения, а базы данных -

повышенными требованиями к целостности. Концептуальное разделение единого

программного продукта на компоненты, характеризующиеся однотипными требо-

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

5. Методология проектирования и наличие CASE-инструментов. В пределах

одной организации процессы разработки могут иметь различное наполнение и

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

рованных инструментов. Эти различия ограничивают возможность использования

одного и того же множества метрик по различным проектам. Очевидно, например,

что не имеет смысла сравнивать число строк кода, разработанного с применением

структурных методов, с числом строк, разработанных объектно-ориентированным

методом.

6. Уровень зрелости организации-разработчика. Существует множество мо-

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

ния мощности процессов и эффективности проектов разработки. Стремление орга-

низаций-разработчиков обеспечить конкурентоспособность выпускаемой про-

граммной продукции служит хорошим стимулом не только для повышения техни-

ческого и технологического уровня проектов, но и для постоянного совершенство-

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

лям зрелости и получения соответствующих сертификатов (например, сертифика-

тов системы качества). Очевидно, что чем выше уровень зрелости организации, тем

совершеннее процессы, связанные с обеспечением качества ПС.

7. Исторический опыт разработки. В достаточно зрелой организации-

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

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

гии проектирования и программирования, приемы сбора и регистрации всевозмож-

ных данных, методологии выполнения измерений ПС и т.д. Это дает им возмож-

ность использовать собственный опыт разработки программных систем со схожими

характеристиками, накапливать полезную историческую информацию по проектам,

Глава 1

относящуюся к качеству, и, таким образом, более точно строить модель качества,

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

рактеристик качества ПС и прогнозировать достижение основных характеристик

качества (например, надежности) уже на ранних стадиях разработки.

8. Конфликты требований. Множество функциональных и нефункциональ-

ных требований к программной системе (в том числе требований к качеству) могут

вступать в конфликты, которые должны разрешаться на всех стадиях ее разработки.

Очевидно, что высокие требования к качеству ПС в условиях ограниченных ресур-

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

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

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

ления риском.

1.1.9. Взаимосвязь понятий в парадигме качества

Для того чтобы завершить краткий обзор множества понятий в области про-

граммной инженерии и качества разрабатываемых программных систем, мы начер-

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

щего в основе современной парадигмы качества (рисунок 1.4).

На этой схеме закругленными прямоугольниками обозначены объекты (про-

дукты, процессы), по отношению к которым будут определяться концепции повы-

шения качества. Кружками (овалами) обозначены атрибуты (свойства) этих объ-

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

мых ПС. Бесцветными прямоугольниками обозначены роли субъектов процессов

разработки и эксплуатации ПС.

1.2. Подходы к повышению качества программных систем

1.2.1. Применение процессов контроля качества

Первый шаг к повышению качества ПС состоит во внедрении в повседнев-

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

поддерживающих процессов ЖЦ ПС, регламентируемых стандартом ISO/IEC 12207

(или ДСТУ 3918) по процессам жизненного цикла ПС, а именно процессов гаран-

тирования качества, верификации, валидации, совместного просмотра и аудита

[9]. Применение этих процессов обеспечивает руководство организации и проекта

методами и средствами контроля за соблюдением требований к процессам разра-

ботки и качеству рабочих продуктов на каждой стадии ЖЦ проекта.

Применяемый далее термин «гарантирование качества» соответствует обыч-

но используемому за рубежом термину «Software Quality Assurance» (SQA), полу-

чившему в издаваемой у нас переводной литературе по программной инженерии и

отечественных стандартах разные варианты перевода, например, «обеспечение ка-

чества», «контроль качества». Однако существующие переводы не в полной мере

отражают суть деятельности по SQA.

Может сложиться впечатление, что именно (и только) процесс SQA должен

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

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

ную группу – SQA. Без вовлечения в контроль качества других процессов ЖЦ дос-

тижение целей качества было бы невозможным.