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

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

Проект создания

программного

обеспечения

Программная

система

Организация-

разработчик

ПО

Эксплуата-

ционное

качество

Внешнее

качество

Внутрен-

нее

качество

Мощность

Зрелость

И з м е р е н и е и о ц е н и в а н и е

Риск проекта

Срок Стоимость Качество

Пользователь

Разработчики

Менеджер проекта

Независимые группы

(качества, тестирования,

конфигурации, риска...)

Высшее руководство

разрабатывается в

рамках

основывается на

внедряет

обладают

обладает

определяет

предъявляет требования и оценивает

вырабатывает

использует

имеет

Свойства

характеризуют

обеспечиваю т

(встраивают)

зависит от

руководит

управляет

принимает

решение

контролируют

контролирую т

оценивает

инициирует

повышение

представляют

проводят V&V

Трудо-

емкость

обладает

оценивает

Заказчик

Рабочие

продукты

Свойства

открывает

Уровень проекта Уровень организацииПродукты разработки

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

Процессы

жизненного

цикла

Внутрен-

ние

ресурсы

Внешние

ограни-

чения

Глава 1 41

Процесс SQA обеспечивает гарантии (от assurance – давать заверения, га-

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

соответствуют предъявляемым к ним требованиям. Эти гарантии основаны на том,

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

сти по проекту, которая непосредственно связана со «встраиванием» в программ-

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

ты, отвечающие передовой практике программной инженерии (нормы, правила,

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

в ходе ЖЦ. SQA гарантирует, что проблемы, неизбежно возникающие в любой

комплексной деятельности (каковой является совместное выполнение процессов

ЖЦ), своевременно идентифицируются и устраняются, что запланированные про-

цессы пригодны для применения и надлежащим образом выполняются в соответст-

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

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

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

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

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

быть обеспечено.

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

дукты) предназначены процессы верификации и валидации [10].

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

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

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

в начале этапа, а также в начале процесса. Задача верификации и валидации – про-

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

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

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

причин появления этих ошибок.

Цель верификации – исследуя трансформации одних (входных) рабочих

продуктов в другие (выходные) рабочие продукты проверить, правильно ли разра-

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

модуля по отношению к спецификации проекта этого модуля).

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

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

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

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

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

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

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

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

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

определяются одним термином «верификация и валидация», которому соответству-

ет термин «Verification and Validation» (V&V), используемый в зарубежной литера-

туре.

Нужно отметить, что контроль процессов SQA и V&V осуществляет руково-

дство проекта или организации (для независимого SQA или независимой верифи-

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

42 Глава 1

рабочих продуктов и других процессов. Схематически соотношение подходов к

контролю качества ПС представлено на рисунке 1.5.

Этап 1

процесса

разработки

Этап 2

процесса

разработки

РП1

Исход-

ные тре-

бования

РП2

Этап N

процесса

разработки

ПC

Процесс SQA

Процесс верификации

...

РП

N-1

Процесс валидации

Стандарты Нормативы ЭталоныКоординация с V&V

Контроль руководством проекта

SQA

Основные

процессы

V&V

Рис. 1.5. Взаимосвязь SQA и V&V

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

SQA, так и в целях V&V. Один из видов их классификации – деление на статиче-

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

пьютере, соответственно.

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

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

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

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

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

поддерживающие процессы ЖЦ.

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

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

анализ деревьев событий и деревьев отказов, анализ сложности алгоритмов, фор-

мальное доказательство корректности и др.).

К динамическим методам обычно относят тестирование, имитационное мо-

делирование и символическое выполнение.

Примечательно, что тестированию, с одной стороны, отводится место среди

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

V&V [11]. На наш взгляд тестирование, как процесс, недостаточно четко определе-

но в действующих стандартах, поскольку эффективное осуществление процесса

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

стадиях ЖЦ проекта и во многих процессах, например, в процессах определения

требований, SQA и V&V. Парадигма тестирования сформулирована в главе 7.

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

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

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

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

продуктов и усовершенствованию процессов.

Глава 1 43

1.2.2. Использование прогнозирования при управлении проектом

Прогнозирование (от греческого prognosis – знание наперед, предвидение) за-

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

техническое прогнозирование – один из ключевых этапов управления. Осуществля-

ется методами экстраполяции, интерполяции, моделирования, обобщения мнений

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

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

мое нормативное прогнозирование. Оно сводится к определению возможных путей

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

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

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

обобщении экспериментальных данных и знании объективных закономерностей

развития наблюдаемых явлений в проекте.

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

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

ществующих объектов.

Оценивание обычно предполагает получение численных оценок или экс-

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

екты, например, объем программного кода, вычисленный в единицах KSLOC (ты-

сяч строк исходного кода), или существующий уровень зрелости организации, оце-

ненный в баллах от 2 до 5.

Прогнозирование предполагает предсказание значений определенных вели-

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

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

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

ный в единицах KSLOC), если известно число функций, которые она должна будет

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

батываться при выполнении каждой функции?

Таким образом, основа прогнозирования – измерение и оценивание.

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

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

(см. раздел 1.1), однако отрасль прогнозирования в программной инженерии (на

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

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

отсутствует в отечественной практике разработки ПС.

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

вых величин – уровня дефектов в ПС (как одной из основных характеристик ее ка-

чества) [12], размера ПС (как базовой величины для определения надежности, объ-

ема тестирования ПС, сроков завершения разработки ПС и др.) [13] и трудоемко-

сти (стоимости) создания ПС [14]. Очевидно, что уровень дефектов, размер и тру-

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

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

ров проектов.

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

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

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

44 Глава 1

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

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

Риск проекта ПС можно определить как возможность снижения качества

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

разработки или срыва проекта (то есть, отказа от проекта) из-за неэффективности,

несовершенства процессов ЖЦ ПС. Несовершенные процессы характеризуются

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

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

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

боткой, несогласованной деятельностью заказчика и разработчика ПС. Все это вме-

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

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

нежелательного события в проекте и вероятности наступления этого события.

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

ного события на характеристики качества ПС – надежность, удобство применения,

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

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

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

Секрет эффективного управления риском состоит в принятии (по каждому

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

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

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

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

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

ние проекта в будущем.

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

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

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

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

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

мой информацией для своевременной идентификации и устранения риска проекта.

Современное управление риском основано на измерении, оценивании и прогнози-

ровании [15].

В новой версии стандарта ISO/IEC 12207 управление риском представлено

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

разработки высококачественных программных систем.

1.2.4. Совершенствование процессов жизненного цикла

Усовершенствование действующих в организации процессов - одна из основ-

ных задач инженерии процессов разработки ПС.

Цели и приоритеты внесения усовершенствований всегда устанавливаются

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

чего нужны усовершенствования. Перед проведением усовершенствований фор-

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

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

вышения эффективности (например, повысить производительность на одну треть).

Эффективность процесса (выраженная в установленных показателях) должна изме-

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

Глава 1 45

ют идентифицировать и определить приоритеты действий по усовершенствова-

нию.

Усовершенствование процесса - непрерывный процесс, представляющий со-

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

усовершенствований.

Цели усовершенствования, определенные количественно и согласованные

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

ствования процесса. Действия по усовершенствованию, установленные в про-

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

нию процесса.

Для отслеживания процесса усовершенствования используются метрики, что

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

мые корректировки в проекте усовершенствований.

Один из элементов программы усовершенствования процесса - снижение

риска, причем риск оценивается с двух точек зрения:

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

дены, но общая цель организации не достигнута);

• риск не осуществить усовершенствования (риск потерпеть неудачу при

попытке усовершенствовать процесс).

Стандарт ДСТУ ISO/IEC TR 15504-7 определяет следующие шаги усовершен-

ствования процессов ЖЦ [16]:

•

инициация усовершенствования процесса. Ключевая фигура в усовер-

шенствовании процессов – инициатор, лицо из руководства организации, которое

утверждает программу усовершенствования процесса, предоставляет для этого ре-

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

•

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

может дать выгоду;

•

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

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

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

•

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

ствования;

•

подтверждение усовершенствования;

•

поддержка нового, усовершенствованного уровня выполнения, пока не

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

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

усовершенствования процесса.

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

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

даже часть проекта.

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

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

позволяют осуществить выбор направлений усовершенствования процессов. Мощ-

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

ганизации.

Стандарт ДСТУ ISO/IEC TR 15504-2 предлагает двумерную модель оценива-

ния мощности процессов [17].

46 Глава 1

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

вого, в соответствии с эталонной моделью (определением) процесса – процесс дол-

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

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

цесса.

После того как получены подтверждения существования процесса, определя-

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

сложившаяся руководящая практика способствует его выполнению. Руководящая

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

которой руководящую практику можно считать совершенной. Чем с большим коли-

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

вень мощности процесса. Каждый атрибут процесса описывает определенный ас-

пект общей возможности управления и совершенствования эффективности процес-

са в достижении целей процесса и высших целей организации.

Таким образом, в двумерной модели оценивания процесса одно измерение –

это измерение процессов (по их действиям и конкретным наработкам), а второе –

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

дящей практике). Чем выше расхождение в целевой и оцененной мощности процес-

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

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

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

и чем больше величина расхождения целевой и ожидаемой мощности, тем боль-

шими могут быть потери, больше риск того, что процесс не будет эффективен в

достижении тех целей, для которых он выбран.

Термин мощность (синонимы – зрелость, совершенство, потенциал) процесса

– в данном случае возможно наиболее удачный перевод термина «process

capability» (возможности процесса), применяемого в упомянутом стандарте, по-

скольку уместна аналогия с математическим понятием - мощность множества (ко-

личество элементов множества).

Подробно процедура оценивания мощности процессов ЖЦ рассматривается в

главе 12.

1.2.5. Повышение зрелости организации

Концепция зрелости организаций-разработчиков ПС стала популярной бла-

годаря работам Уотса Хамфри из института SEI (Software Engineering Institute)

(США), хотя ее истоки – в 60 годах (работы Р. Лайкерта).

У. Хамфри разработал пятиуровневую модель зрелости - СММ (от Capability

Maturity Model), которая определяет характеристики общего процесса программной

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

зывает эволюционный путь его улучшения [4].

Зрелость организации можно охарактеризовать как степень четкости (ясно-

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

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

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

ни их применимости (адаптируемости) к конкретным проектам организации. Зна-

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

проекта в достижении поставленных перед ним целей.

Глава 1 47

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

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

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

процесса программной инженерии. Такая структура СММ определяет приоритет-

ность действий в направлении повышения зрелости процесса.

Пять уровней зрелости по модели СММ таковы:

• уровень 1 - начальный. Он включен в модель только с целью образования

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

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

структурирован и хаотичен, а бюджет, график и качество разработки непредска-

зуемы;

• уровень 2 - повторяемый. На этом уровне управление проектом нацелено

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

нальности разработки. Дисциплина разработки позволяет применять отработанные

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

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

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

• уровень 3 - фиксированный. Процесс программной инженерии (охваты-

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

но разработки) институциализирован в организации (утвержден, стандартизован и

документирован). Внедрена программа обучения штата разработчиков ПС и ме-

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

в организации и настраивают его для достижения целей конкретного проекта;

• уровень 4 - управляемый. Достигается цель количественной оценки каче-

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

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

ность управлять риском проекта и, при необходимости, “возвращать” процесс в

установленные рамки;

• уровень 5 - оптимизируемый. Обеспечивается непрерывное улучшение

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

сторон. Данные об эффективности процесса разработки используются для проведе-

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

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

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

следственный анализ ошибок в проектах.

Таким образом, уровни зрелости в СММ описывают характеристики органи-

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

мы, которые преобладают на уровне, и образует фундамент для эффективной реа-

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

тественен.

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

лений процесса программной инженерии. Каждое направление, в свою очередь,

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

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

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

вующему ключевому направлению процесса.