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

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

184 Глава 4

ниже примерное содержание плана (эталон). Даже при наличии альтернативных

структур плана, его содержание должно удовлетворять эталону (т.е. включать все

указанные аспекты измерений).

ПЛАН ИЗМЕРЕНИЯ

(эталон)

1. Цели измерения

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

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

рения.

2. Описание

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

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

действиями. Включает подразделы.

2.1. Обоснование

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

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

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

по измерению в организации (если они проводились ранее).

2.2. Цели

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

действия. Включается три вида целей: (а) деловые цели, (б) цели измерения и (в) цели это-

го плана.

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

торая обеспечивается высшим руководством.

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

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

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

ми целями.

Цели данного плана ориентированы на выполнение определенных операций. Они кон-

кретизируют результаты, которые должны быть достигнуты, и признаки достижения. Часто

наиболее эффективный способ представления этих целей – это установление критериев

завершения или критериев успеха.

2.3. Сфера применения

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

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

только новые проекты, только определенные подразделения, только соисполнители). Ука-

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

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

2.4. Связь с другими действиями по усовершенствованию процесса

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

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

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

по методологии СММ) или сертификации (по ISO 9000). Описывают, как действия по из-

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

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

рантии качества.

Глава 4 185

3. Выполнение

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

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

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

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

др. Включает подразделы.

3.1. Действия, продукты и задачи

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

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

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

продукта или задачи устанавливают ориентиры (нормативы). Определяют все ограничения

и зависимости, которые воздействуют либо на график, либо на выделение ресурсов. Там,

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

завершение задачи.

3.2. График

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

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

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

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

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

3.3. Ресурсы

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

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

3.4. Ответственности

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

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

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

баз данных.

3.5. Измерение и мониторинг (контроль)

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

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

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

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

существенные изменения в нем или пересмотр объемов финансирования.

3.6. Допущения

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

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

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

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

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

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

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

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

несоответствия допущениям.

4. Действия по поддержке процесса

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

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

3. Указывают ресурсы и ответственных лиц за обеспечение непрерывной эволюции процес-

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

эффективности измерений и оценивания их значимости для деятельности организации.

186 Глава 4

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

4.3.1. Измерения и деловые цели организации

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

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

тавлять эффективную лаконичную информацию для принятия решений. Деловые

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

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

и собственно разработка ПС (выполнение процессов в рамках проектов).

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

ренностей с заказчиком относительно стоимости, плана графика и качества постав-

ляемого программного продукта. Ключевые проблемы управления – это те про-

блемы, появление которых подвергает опасности эти договоренности. Руководство

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

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

перед заказчиком обязательств.

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

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

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

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

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

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

Цели собственно разработки (инженерии) программного продукта - гаранти-

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

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

Рисунок 4.15 иллюстрирует взаимосвязи между задачами управления про-

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

нию связаны с решением этих задач.

Улучшение

процесса

Определение

процесса

Планирование

измерений

Контроль

процесса

Выполнение

измерений

Выполнение

процесса

Выполнение

плана проекта

Требова-

ния

Планирование

измерений

Определение

плана

Люди, ресурсы,

действия, рабочие

продукты

Разработка

продукта

Продукты

Цели организации

Выполнение

измерений

Корректиров-

ка плана

Рис. 4.15. Место измерений в управлении проектом и процессом

Глава 4 187

Как показывает рисунок, участники проекта разрабатывают программные

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

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

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

• идентификации и спецификации требований,

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

• выполнения плана,

• отслеживания состояния и продвижения проекта по отношению к целям,

указанным в плане проекта.

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

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

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

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

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

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

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

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

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

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

контролируя эффективность мер, метрик и действий по измерению.

4.3.2. Подходы к измерениям, базирующиеся на парадигме GQM

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

используется в практике измерений, ей присущ ряд недостатков [10]. Во-первых,

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

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

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

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

вопросы нужно искать вне рамок организации-разработчика ПС.

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

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

белы. Одна из них, лежащая в основе 10 шагового процесса измерений, была пред-

ставлена в разделе 4.2.

Другой пример развития GQM – методология V-GQM (от Validation GQM)

[11]. В отличие от оригинальной парадигмы GQM, в V-GQM процесс не заверша-

ется после анализа собранных данных. Методология предлагает три дополнитель-

ных шага – валидацию (проверку и утверждение метрик), анализ ответов на по-

ставленные вопросы и уточнение целей. Модель измерения по методологии V-

GQM представлена на рисунке 4.16.

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

классификации (с точки зрения пригодности для ответа на вопросы) на категории:

«достаточные», «мало значащие», «шире необходимого», «обобщаемые». На осно-

ве этой классификации выполняется последующий анализ метрик. Например, если

метрика классифицирована как «шире необходимого», может возникнуть вопрос,

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

измерений?

188 Глава 4

Опреледение

цели

Формулирова-

ние вопроса

Разработка

метрики

Сбор данных

Проверка

метрики

Анализ ответа

на вопрос

Уточнение

цели

Рис. 4.16. Шаги процесса измерения в методологии V-GQM

Цель второго шага - анализ вопросов – их переосмысление в свете получен-

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

от несущественных). Во внимание принимается также трудоемкость ответа на

вопросы и польза от сбора данных.

Уточнение целей - последний шаг в V-GQM и первый в следующем цикле

GQM. Могут быть поставлены новые цели, если установлены любые новые факты,

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

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

В работе [12] представлена модель обобщенного процесса измерения-

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

процессов (проектов) в организации (рисунок 4.17).

Возможные

причины

Возможные

решения

Анализ

Улучшение Измерение

Реализация

Анализ

Реализация

Цель

Программа

измерений

Рис. 4.17. «Петельная» модель «улучшений, основанных на измерении»

Процесс начинается с самой левой точки «петли» - определения целей со-

вершенствования процессов, доходит по дуге «анализ целей» до центральной точки

– принятия решения. Если информации для принятия решения достаточно, проис-

ходит возврат по дуге «реализация целей» в исходную точку. В противном случае –

выполняется цикл «реализация измерений» (по правой нижней дуге) и «анализ ре-

зультатов измерений». Этот цикл (выполняемый по GQM) может повторяться не-

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

ции.

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

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

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

К.Деккерс, например, сообщает, что около 80 % программ измерений, проанализи-

Глава 4 189

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

употребления измерениями [13].

Тем не менее, есть и обширный положительный опыт выполнения программ

измерений [14]. Его анализ позволяет дать такие рекомендации по их внедрению:

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

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

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

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

мерений (в соответствии с требованиями стандарта ДСТУ ISO/IEC 15504-7 [15]);

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

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

ректные данные;

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

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

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

участвующих в программе измерений.

4.3.3. Моделирование качества системы с использованием GQM

Несмотря на разнообразие существующих моделей качества (см. главу 3),

они не находят широкого применения, потому что не отвечают трем важным тре-

бованиям:

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

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

пользователей, стадий ЖЦ) и многократное (повторное) использование,

– пригодность для измерений.

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

ISO/IEC 9126) определяют постоянный набор характеристик качества, не учитывая

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

рии пользователей (заказчиков, менеджеров, разработчиков). Возможность их по-

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

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

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

но не о процессах и ресурсах. Кроме того, они не прозрачны, логика структурной

декомпозиции характеристик качества не очевидна.

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

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

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

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

связывать результаты оценивания одних и тех же характеристик разных объектов?

Например, каким образом подхарактеристика «анализируемость» для документа-

ции (на проектных стадиях) связана с этой же подхарактеристикой для кода (на

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

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

Недостатком прозрачности и гибкости страдают и математические регресси-

онные модели (например, упомянутая в главе 3 модель COQUALMO). Их также

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

ляющих коэффициенты регрессии.

190 Глава 4

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

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

GQM или Squid [16]). В таких подходах обеспечивается возможность сочетания

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

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

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

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

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

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

ся каждый раз «с нуля», что является существенным ограничением для быстро эво-

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

ных продуктов (так называемых product lines).

Сочетание количественных и качественных данных и распространение (про-

движение) оценок по сети обеспечивают байесовские модели (см. главу 3). Однако

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

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

ва, является поиск ответа на два вопроса:

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

качества, относительно спектра и взаимосвязи характеристик качества?

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

личных проектах и организациях?

Подход к решению проблемы (под названием Prometheus) предложили

Т.Пантер, А.Трендович и П.Кайзер в работе [17]. Этот подход объединяет метод

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

методы спецификации целей, вопросов и мер в парадигме GQM. Он сочетает коли-

чественные (основанные на измерении) и качественные (основанные на мнении

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

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

мых объектов (процессов, продуктов, ресурсов).

Применение подхода включает три стадии работ: спецификацию модели ка-

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

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

зования модели.

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

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

ственных и качественных) применяются байесовские сети.

Литература к главе 4

1. Fenton N., Whitty R. Software Quality Assurance and Measurement. A Worldwide Perspec-

tive. // London: International Thomson Computer Press. - 1995.

2. Fenton N. Software Metrics: A Rigorous Approach. // London: Chapman & Hall. - 1991.

3. Armitage J.W., Kellner M. A Conceptual Schema for Process Definitions and Models // Pro-

ceedings of the 3rd International Conference on the Software Process, Reston, Va., Oct. 10-

11, 1994. - IEEE Computer Society Press. -1994. P. 53 – 165.

4. ISO/IEC 15939:2002. Software Engineering - Software Measurement Process.

5. Goal-Question-Metric // sel.gsfc.nasa.gov/website/exp-factory/gqm.htm

Глава 4 191

6. Park R.E., Goethert W.B., Florac W.A. Goal-Driven Software Measurement - A Guidebook //

Technical Report CMU/SEI-96-HB-002 – Software Eng. Inst., Pittsburgh, PA 15213. -1996. -

189 p.

7. Basili V.R., Rombach H.D. The TAME Project: Towards Improvement-Oriented Software

Environments // IEEE Trans. on Softw. Eng. - Vol. 14. - No. - June 1988. – P. 758-773.

8. Basili V.R. Using Measurement for Quality Control and Process Improvement // Second An-

nual SEPG Workshop, Software Engineering Institute, Carnegie Mellon University, Pitts-

burgh, Pa. -June 21-22. - 1989.

9. Rombach H.D., Ulery B.T. Improving Software Maintenance Through Measurement // Pro-

ceedings of the IEEE. - Vol. 77. - No. 4, April 1989. – P. 581 - 595.

10. Fuggetta A. et al. Applying GQM in an industrial software factory, ACM Transactions on

Software Engineering and Methodologies, 1997.

11. Olsson T., Runeson P. V-GQM: A Feed-Back Approach to Validation of a GQM Study, Met-

rics ’01 - International Software Metrics Symposium, 2001.

12. Niessink F., van Vliet H. A Pastry Cook’s View on Software Measurement // In: Software

Measurement - Research and Practice of Software Metrics, Reiner Dumke and Alain Abran

(ed.), Deutscher Universitaetsverlag, Wiesbaden, Germany. – 1999. - P. 109-125.

13. Dekkers C. A. et al. The Dangers of Using Software Metrics to (Mis)manage, -IT Pro. - March

– April, 2002.

14. Iversen J., Mathiassen L. Lessons from Implementing a Software Metrics Program // Proceed-

ings of the 33

Hawaii International Conference on System Sciences. – 2000.

15. ДСТУ ISO/IEC TR 15504-7:2002. Інформаційні технології – Оцінювання процесів жит-

тєвого циклу програмних засобів - Частина 7: Настанови з удосконалення процесу.

16. Kitchenham S., Linkman A.,Pasquini, V. Nanni. The SQUID approach to defining quality

model // Software Quality Journal.- №6.-1997. – P. 211-233.

17. Punter T., Trendowicz A., Kaiser P. Evaluating Evolutionary Software Systems // PROFES

2002 (4th International Conference on Product Focused Software Process Improvement).

192

Глава 5. КОНТРОЛЬ И ГАРАНТИЯ КАЧЕСТВА

5.1. Обеспечение гарантии качества в жизненном цикле

5.1.1. Процесс SQA в архитектуре процессов жизненного цикла

В архитектуре процессов ЖЦ ПС представлены два процесса, в наименова-

нии которых содержится термин «качество» - это поддерживающий процесс «обес-

печение гарантии качества» (SQA) и организационный процесс «управление каче-

ством» (или «менеджмент качества» (от «quality management»)).

Первый из процессов связан с двумя видами деятельности – внедрением

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

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

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

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

печения, вышедших в 80-е и 90-е годы за рубежом (например, стандарты IEEE Std.

730 [1], NASA Std. 2201 [2], MIL Std. 498 [3] и др.). С 1995 года деятельность по

SQA регламентируется международным стандартом ISO/IEC 12207 [4] и оформлена

в виде отдельного процесса в архитектуре процессов ЖЦ.

Второй из процессов – «управления качеством» - включен в состав процессов

ЖЦ с 1998 года (проекты стандартов ISO/IEC 12207 (1998 – 2001 годы), ISO/IEC

TR 15504 (1998 – 2002 годы)). Включение этого процесса в архитектуру (наряду с

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

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

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

(иными словами, преодолен барьер 2-го уровня зрелости по модели СММ). Хотя

процесс SQA остается основополагающим процессом гарантирования качества

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

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

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

требителя к качеству ПС.

Исходя из положений стандарта ISO/IEC 12207, цели процесса гарантирова-

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

том, что продукты ПС и процессы, применяемые для получения этих продуктов,

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

ным планам. «В результате успешного осуществления процесса:

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

ках процесса SQA

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

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

• сведения о действиях и задачах по обеспечению качества будут фиксиро-

ваться и сопровождаться.

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

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

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

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

Глава 5 193

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

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

ствия в процессах ЖЦ и порождаемые ими рабочие продукты отвечают установленным стандартам;

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

договора.

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

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

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

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

цессами поддержки, такими как Верификация, Валидация, Совместный просмотр,

Аудит и Управление решением проблем, и может использовать их результаты».

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

лям - удовлетворения требований потребителя к качеству ПС. Контроль соответ-

ствия целей процесса SQA высшим целям качества ПС осуществляет процесс

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

Согласно ISO/IEC 12207 назначение процесса управления качеством состоит

в мониторинге качества ПС и гарантировании того, что ПС будет удовлетворять

потребителя. «В результате успешного осуществления процесса:

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

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

ЖЦ.

Устанавливаются цели эксплуатационного, внешнего и внутреннего качества ПС. Их достиже-

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

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

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

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

• будет разработана общая стратегия достижения установленных требова-

ний.

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

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

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

ли соответствующие цели качества достигнуты;

• идентифицированные действия относительно контроля и обеспечения ка-

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

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

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

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

вающих качество, тестирования ПС и др.), так и в поддерживающие процессы (SQA, V&V и др.) на

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

• если цели не будут достигаться, будут приниматься надлежащие меры.

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

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

вующие «промежуточные» цели по качеству. Если определенные цели по качеству не достигаются,

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

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

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

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

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

Таким образом, в современной модели процессов ЖЦ процесс SQA: