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

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

76 Глава 2

Таблица 2.1. Классификация инструментов по SWEBOK

Класс Типы Описание назначения и примечания

Средства модели-

рования

Управление программными требованиями – из-

влечение, анализ, специфицирование и проверка

Инструменты

работы с тре-

бованиями

Средства трасси-

ровки

Отслеживание проекций требований на всех эта-

пах ЖЦ

Инструменты

проектирова-

ния

В SWEBOK не

классифицированы

Можно классифицировать по базовым нотациям

(SADT, UML, DSL…), по целевым задачам (биз-

нес-проектирование, проектирование БД…)

Редакторы про-

грамм

Создание и модификация исходного кода и, воз-

можно, документации (в IDE – интегрир. средах)

Компиляторы и

генераторы кода

Трансляторы с командной строкой. Однако есть

тенденция интеграции с редакторами в IDE

Интерпретаторы Исполнение программ посредством эмуляции

Инструменты

конструирова-

ния

Отладчики

Генераторы тестов Разработка сценариев тестирования

Средства выпол-

нения тестов

Исполнение тестовых сценариев в контролируе-

мом окружении

Инструменты

оценки тестов

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

Средства управле-

ния тестами

Поддержка всех аспектов процесса тестирования

Инструменты

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

Инструменты ана-

лиза производи-

тельности

(как инструменты

целевого анализа)

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

производительности. Другие инструменты целе-

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

ния, тестирования безопасности, тестирования

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

тестирования и др.

Средства визуали-

зации

Инструменты, облегчающие понимание Инструменты

сопровожде-

ния

Инструменты ре-

инженерии

Восстановление спецификации и архитектуры

ПО по коду

Инструменты от-

слеживания

Отслеживание дефектов, расширений и проблем

Инструменты уп-

равления версиями

Инструменты

управления

конфигурацией

Инструменты

сборки и выпуска

Управление задачами сборки и выпуска продук-

тов, включая инсталляцию

Инструменты пла-

нирования и от-

слеживания работ

Календарное планирование работ по проекту,

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

мости

Инструменты уп-

равления рисками

Идентификация рисков, оценка последствий,

мониторинг рисков

Управление

инженерией

Средства количе-

ственной оценки

Ведение измерений, поддержка Программы из-

мерений

Инструменты мо-

делирования про-

цессов

Более широкий класс инструментов моделирова-

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

разработки модели процессов

Инструменты

поддержки

процессов

Средства управле-

ния процессами

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

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

Глава 2 77

Класс Типы Описание назначения и примечания

Интегрированные

CASE-среды и

ролевые платфор-

мы разработки

Охват многих фаз ЖЦ и поддержка «смежных»

работ по управлению требованиями, управлению

конфигурациями и изменениями, тестированию

и оценке качества

Инструменты

поддержки

процессов

Процессо-

ориентированные

среды разработки

Ведение всей информации по процессам ЖЦ,

предоставление ее (а также сопутствующих ре-

комендаций) пользователю

Инструменты ин-

спектирования

Поддержка обзоров и аудитов Инструменты

обеспечения

качества

Инструменты ста-

тического анализа

Анализ программных артефактов, данных, пото-

ков работ и зависимостей и проверка соответст-

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

Приемы (виды)

интеграции инст-

рументов

Интегрированные среды разработки (IDE), биб-

лиотеки программ/компонентов, программные

платформы (Java, J2EE и Microsoft .NET), плат-

формы распределенных вычислений (CORBA и

WebServices)

Метаинструменты Средства генерации других инструментов (ком-

пилятор компиляторов и др.)

Дополнитель-

ные аспекты

Приемы оценки

инструментов

Подходы к оценке ввиду эволюционирования

инструментов программной инженерии

2.2.11. Область знаний «Качество программного обеспечения»

Качество ПО (Software Quality) – совокупность свойств программного про-

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

полагаемым требованиям заказчика (пользователя). В это определение понятия

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

рассмотрения. Можно различать, например, рыночное качество ПО (market-driven

quality), потребительское качество (customer-driven quality); качество ПО с позиций

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

и эксплуатационное. Залог повышения качества при процессном подходе – приме-

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

на своевременное обнаружение и устранение дефектов в ПО и изъянов в самих

процессах ЖЦ. Даная область знаний SWEBOK охватывает вопросы статической

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

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

Область знаний включает следующие разделы:

• основы качества ПО (Software Quality Fundamentals),

• процессы управления качеством (Software Quality Management Processes),

• практические соображения (Practical Considerations).

В разделе Основы качества ПО подчеркивается, что все вопросы качества

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

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

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

Инженеры по программному обеспечению должны воспринимать вопросы

качества как часть своей профессиональной культуры. Требования к характеристи-

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

78 Глава 2

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

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

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

сбоев и внешних потерь. Большинство альтернативных компромиссных решений

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

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

ЖЦ ПО и в рамках любых процессов ЖЦ.

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

графические образы и т.п. Базовый стандарт по качеству ISO/IEC 9126-1:2001

«Software Engineering - Product Quality, Part 1: Quality Model» предлагает рассмат-

ривать качество на трех уровнях его обеспечения в артефактах проекта (внутреннее

качество, внешнее качество и качество ПО в эксплуатации) и рекомендует иерар-

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

соответствии со стандартом ISO/IEC 14598:1999 «Information Technology - Software

Product Evaluation».

Непосредственное отношение к качеству создаваемого продукта имеет управ-

ление качеством (SQM, от Software Quality Management) и качество процессов про-

граммной инженерии. В области управления (менеджмента) качества важнейшими

являются стандарты TickIT и ISO 90003:2004 «Software and Systems Engineering -

Guidelines for the Application of ISO 9001:2000 to Computer Software», а в области

качества (мощности, зрелости) процессов ЖЦ – стандарты CMMI и ISO/IEC

15504:2004 «Information Technology - Software Process Assessment» (модель SPICE,

от Software Process Improvement and Capability dEtermination). Эти стандарты вза-

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

в достижении старших уровней зрелости по CMMI.

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

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

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

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

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

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

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

фактического достижения. Это дает возможность оценивать соответствие заданным

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

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

Качество ПО может повышаться в ходе итеративного процесса его постоян-

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

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

нения и предотвращения дефектов, а также совершенствования процессов ЖЦ.

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

процессы обеспечения гарантии качества (SQA, от Software Quality Assurance),

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

ственно процесс управления качеством (SQM), обеспечивающий функции контроля

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

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

SQA, как отмечается в руководстве к SWEBOK, концентрируется на процес-

сах. Роль SQA состоит в том, чтобы обеспечить планирование процессов, дальней-

Глава 2 79

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

измерений процессов. Верификация и валидация (V&V, от Verification and Valida-

tion) применяется к артефактам проекта в его контрольных точках с целью про-

верки и подтверждения их правильности. Действия по V&V регламентируются ба-

зовыми стандартами IEEE 1012:1998 «Software Verification and Validation» и IEEE

1059:1993 «IEEE Guide for Software Verification and Validation Plans». Деятельность

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

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

тируется стандартом IEEE 1028:1997 «IEEE Standard for Software Reviews».

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

ределения факторов, влияющих на выбор стратегии SQM. Один из них – критич-

ность области применения ПО. Комплексной характеристикой качества такого ПО

является гарантоспособность (dependability) - совокупность свойств ПО, обеспе-

чивающих его отказоустойчивость (fault tolerance), безопасность эксплуатации

(safety), защищенность информации (security), а также удобство и простоту исполь-

зования (usability). Другой важный фактор – уровень необходимой целостности

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

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

за опасностей окружению и угроз целостности информации.

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

но описания характеристик дефектов (рекомендуемый стандарт IEEE 1044:1993

«IEEE Standard for the Classification of Software Anomalies»), сбора и регистрации

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

Дается классификация приемов SQM, включая статические и динамические,

коллективные и индивидуальные, а также аналитические (формальные и нефор-

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

для решения таких задач SQM:

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

ISO/IEC 14102:1995 «Information Technology - Guideline for the Evaluation and Selec-

tion of CASE Tools»),

• тестирование соответствия компонентов ПО и COTS-продуктов (от com-

mercial of-the-shelf, готовый к использованию продукт, продукт «с полки») потреб-

ностям их использования в создаваемом продукте (согласно ISO/IEC 12119: 1994

«Information Technology–Software Packages - Quality Requirements and Testing»).

Эта область знаний охватывает также такие аспекты, как количественная

оценка качества ПО с использованием метрик и оценка стоимости процесса SQM.

2.3. Ядро знаний по управлению проектами (PMBOK)

2.3.1. Структура руководства по PMBOK

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

тами PMBOK (от Project Management Body of Knowledge) – стандарт по управлению

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

проектами (PMI, Project Management Institute, www.pmi.org) [15]. Первый вариант

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

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

управления проектами в промышленности. Как и SWEBOK, руководство PMBOK

80 Глава 2

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

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

Версия PMBOK 2000 года оформлена как стандарт IEEE Std. 1490: 2003

«IEEE Guide Adoption of PMI Standard A Guide to the Project Management Body of

Knowledge» и представляет собой описание базовой лексики и согласованной

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

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

промышленности, но и создания ПО. Текущая третья версия PMBOK (2004 года)

принята как национальный стандарт США ANSI/PMI 99-001-2004 и рассматривает-

ся как проект нового международного стандарта по управлению проектами [16].

Основное отличие текущей версии PMBOK от предыдущих – четкое декларирова-

ние «процессного» подхода и реструктуризация всего материала руководства по

отдельным областям знаний в соответствии с этим подходом [17].

PMBOK определяет 39 процессов ЖЦ проекта, объединенных в 5 базовых

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

проектов. Группы процессов таковы: 1. Инициация. 2. Планирование. 3. Исполне-

ние. 4. Мониторинг и управление. 5. Завершение.

Ключевые области знаний:

1. Управление интеграцией проекта.

2. Управление содержанием (рамками) проекта.

3. Управление продолжительностью (сроками) проекта.

4. Управление стоимостью проекта.

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

6. Управление человеческими ресурсами.

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

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

9. Управление закупками (поставками) проекта.

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

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

или все процессы той или иной группы (таблица 2.2).

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

показано на рисунке 2.3 применительно к группам процессов.

Инициация Планирование

Реализация

Контроль и

мониторинг

Завершение

Рис. 2.3. Схема взаимодействия групп процессов

Русский перевод PMBOK 2004 года можно найти в Интернет по адресу

http://petukhov.zaklad.ru/pmbok2004_rus.pdf (ссылка актуальна на 01.08.2006)

Таблица 2.2. Процессы по направлениям деятельности (по областям знаний) в PMBOK

Группы

Области знаний

Иници-

ация

Планирование Исполнение Мониторинг и управление Завер-

шение

Управление

интеграцией

проекта

Разработка

Устава про-

екта

Разработка плана управления проектом Руководство ис-

полнением про-

екта

Мониторинг и управление

работами. Управление изме-

нениями

Закры-

тие

проекта

Определение

содержания

проекта

Планирование содержания (рамок)

Определение содержания (рамок) про-

екта

Подтверждение содержания

Управление содержанием

(изменениями)

Управление

продолжитель-

ностью проекта

Определение состава операций

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

Оценка ресурсов операций

Оценка длительности операций

Разработка плана-графика

Управление планом-

графиком

Управление

стоимостью

проекта

Стоимостная оценка

Разработка сметы затрат (бюджета рас-

ходов)

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

Управление ка-

чеством проекта

Планирование качества Процесс обеспе-

чения качества

Процесс контроля качества

Управление

людскими ре-

сурсами

Планирование человеческих ресурсов

Набор команды

Развитие коман-

ды

Управление командой проек-

та

Управление ко-

ммуникациями

Планирование коммуникаций Распространение

информации

Отчетность по исполнению.

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

Управление

рисками проек-

та

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

Идентификация рисков

Качественный анализ рисков

Количественный анализ рисков

Планирование реагирования на риски

Мониторинг и управление

рисками

Управление по-

ставками про-

екта

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

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

Анализ предло-

жений

Выбор продавцов

Администрирование

контрактов

Закры-

тие кон-

тракта

82 Глава 2

Процессы в PMBOK детально описаны в терминах Входов, Выходов, приме-

няемых Методологий и Инструментов.

Далее приводится аннотированное описание областей знаний PMBOK.

2.3.2. Области знаний PMBOK

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

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

нации всех других процессов и операций по управлению проектами. В контексте

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

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

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

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

следующие процессы:

• разработка Устава проекта, формально авторизующего проект или фазу;

• разработка предварительного (общего) описания содержания проекта;

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

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

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

• руководство и управление исполнением проекта – выполнение работы по

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

ных в описании содержания проекта;

• мониторинг и управление работами проекта – мониторинг и управление

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

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

проектом;

• общее управление изменениями – обработка всех запросов на изменения,

утверждение этих изменений и управление ими с целью оптимизации результатов

поставки и активов организационного процесса;

• закрытие проекта – завершение всех операций по всем группам процессов

проекта в целях формального завершения проекта.

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

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

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

бованиям, границам, ограничениям, критериям приемки и др.). Это такие процессы:

• планирование содержания – создание плана управления содержанием

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

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

туры работ (ИСР);

• определение содержания – разработка подробного описания содержания

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

• создание ИСР – разбивка крупных результатов поставки проекта и про-

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

• подтверждение содержания – формальное принятие завершенных резуль-

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

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

Глава 2 83

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

цессы, обеспечивающие своевременное завершение проекта:

• определение состава операций – конкретных плановых операций, кото-

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

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

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

• оценка ресурсов операции – оценка типов и количества ресурсов, необхо-

димых для выполнения каждой плановой операции;

• оценка длительности операций — оценка количества периодов, необхо-

димых для выполнения отдельных операций;

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

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

срокам;

• управление графиком – управления изменениями графика.

Область знаний Управление стоимостью проекта объединяет следующие

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

и обеспечивающие завершение проекта в рамках утвержденного бюджета:

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

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

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

операций или пакетов работ с целью формирования базового плана по стоимости;

• управление стоимостью – воздействие на факторы, вызывающие откло-

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

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

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

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

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

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

(СМК) при помощи правил и процедур, а также действий, направленных на посто-

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

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

• планирование качества – определение стандартов качества, которые соот-

ветствуют проекту, и способов их соблюдения;

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

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

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

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

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

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

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

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

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

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

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

скими ресурсами проекта таковы: