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

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

66 Глава 2

for Software Test Documentation» по документированию планов тестирования, спе-

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

Существенным моментом в процессе тестирования является принятие реше-

ния о завершении тестирования (необходимом объеме тестирования). Тщательные

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

оценками стоимости тестирования, а также рисков отказов и стоимости устране-

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

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

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

шаблонов тестирования, а также отдельных работ по тестированию: планирования,

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

тестов, анализа результатов тестирования и отчетности.

2.2.6. Область знаний «Сопровождение программного обеспечения»

Сопровождение ПО (Software Maintenance) – совокупность действий по эф-

фективной (с точки зрения затрат) поддержке функционирования ПО в период

эксплуатации, включая внесение изменений при обнаружении ошибок в работе ПО,

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

Хотя фаза сопровождения в ЖЦ ПО обычно начинается сразу после прием-

ки/передачи продукта и действует в течение периода гарантии (или технической

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

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

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

обслуживающего персонала и модификация ПО, при условии сохранения целост-

ности продукта.

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

• основы сопровождения (Software Maintenance Fundamentals),

• ключевые вопросы сопровождения ПО (Key Issue in Software

Maintenance),

• процесс сопровождения (Maintenance Process),

• приемы сопровождения (Techniques for Maintenance).

В разделе Основы сопровождения представлены базовые концепции и тер-

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

провождению ПО, и сопоставлены положения стандартов IEEE Std. 1219:1998

«IEEE Standard for Software Maintenance», ISO/IEC 14764:1999 «Information technol-

ogy – Software maintenance» и ISO/IEC 12207.

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

щее, совершенствующее и профилактическое сопровождение.

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

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

шая часть ресурсов ЖЦ ПО, причем, более 80% усилий связаны не столько с устра-

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

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

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

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

кационной инфраструктуры и т.п. вплоть до вывода ПО из эксплуатации.

Глава 2 67

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

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

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

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

дение системы после ввода в эксплуатацию.

В разделе Ключевые вопросы сопровождения ПО рассматриваются техни-

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

«Техника» сопровождения охватывает вопросы быстрого изучения сопрово-

ждаемого ПО и локализации ошибок, использования тестирования, анализа послед-

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

печиваемого при разработке ПО).

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

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

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

ждающей организации, подборе персонала сопровождения, организации процесса

сопровождения и др.

Вопросы оценки стоимости сопровождения решаются путем применения па-

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

провождению ПО.

Для выполнения измерений при сопровождении SWEBOK рекомендует об-

щие метрики (для всего ЖЦ ПО): размер, усилия, график работы, характеристики

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

няемости, стабильности и тестируемости ПО - факторов, влияющих на уровень за-

трат по сопровождению ПО.

Процесс сопровождения должен определяться множеством выполняемых

действий, входов и выходов и соответствовать требованиям IEEE Std. 1219:1998

или ISO/IEC 14764:1999

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

– передача ПО от разработчика организации (службе) сопровождения;

– принятие/отклонение запросов на модификацию;

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

модификацию и отчетов об ошибках;

– анализ влияния - анализ возможных последствий изменений, вносимых в

существующую систему;

– поддержка ПО – консультационные услуги по запросам пользователей;

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

провождающей организацией.

Кроме того, дополнительно определяются действия по планированию сопро-

вождения, управлению конфигурацией, верификации и валидации ПО, оценке ка-

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

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

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

эволюции ПО, как реинженерия, реверсная инженерия и рефакторинг.

Реинженерия – тщательное изучение функций и последующая радикальная

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

модель процесса (порядок выполнения действий) в этих стандартах отличаются.

68 Глава 2

или настройки на другую платформу или среду. Цель реинженерии – не столько

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

Реверсная (обратная) инженерия –- восстановление спецификации (графов

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

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

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

ции (в частности, для обеспечения последующей реинженерии).

Рефакторинг - трансформация ПО с сохранением архитектурных и техноло-

гических решений и без изменения его поведения, предпринимаемая с целью

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

удобство сопровождения). Может рассматриваться как одна из форм реверсной

инженерии.

2.2.7. Область знаний «Управление конфигурацией программного обес-

печения»

Управление конфигурацией или конфигурационный менеджмент (Configura-

tion Management) – деятельность, связанная с контролем эволюции и целостности

программного продукта в ходе выполнения проекта ПО системы путем идентифи-

кации всех артефактов

, отслеживания их изменений и ведения отчетности о со-

стоянии конфигурации ПО системы.

Работы по управлению конфигурацией ПО (далее SCM, от Software Configu-

ration Management) включают тщательное планирование процесса SCM

, определе-

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

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

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

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

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

• управление процессом (Management of the SCM Process),

• идентификация конфигурации ПО (Software Configuration Identification),

• контроль конфигурации ПО (Software Configuration Control),

• учет состояния конфигурации (Software Configuration Status Accounting),

• аудит конфигурации ПО (Software Configuration Auditing),

• управление выпуском и поставка ПО (Software Release Management and

Delivery).

Управление процессом конфигурационного менеджмента осуществляется с

учетом организационного контекста

, особенностей и ограничений аппаратно-

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

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

по SCM (например, ISO/IEC 12207, ISO/IEC 15504, CMMI).

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

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

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

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

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

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

Глава 2 69

Планирование процесса SСM охватывает распределение обязанностей и пол-

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

бот; подбор (разработку) инструментов (для ведения SCM-библиотек, запросов на

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

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

IEEE Std.828:1998 «Standard for Software Configuration Management Plans»).

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

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

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

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

отвергнутых изменений, количество версий и др.).

Работы по идентификации конфигурации включают: определение контро-

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

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

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

рактеристик элементов; описание применяемых инструментов и приемов управле-

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

связей между элементами, версиями и др.

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

ЖЦ ПО. Включает анализ запросов на изменения и определение того, какие именно

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

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

рядок формального утверждения «отхода» от проектных требований. Принятые

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

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

или последовательно). «Закрытие» изменений предполагает аудит конфигурации.

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

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

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

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

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

сти процесса управления конфигурацией ПО.

Аудит конфигурации – это деятельность по оценке соответствия продуктов

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

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

ным функциональным и физическим характеристикам. Различают неформальный

аудит (в контрольных точках проекта) и формальный аудит двух типов: функцио-

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

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

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

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

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

внутренний аудит элементов базовых версий.

Управление выпуском версий и поставкой ПО включает отслеживание вер-

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

относительно элементов конфигурации и системы, к которым эти элементы отно-

сятся; сборку (объединение) компонентов; создание новых версий системы на ос-

70 Глава 2

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

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

цию, упаковку и передачу элементов продукта и документации заказчику.

2.2.8. Область знаний «Управление инженерией программного обеспече-

ния»

Управление (менеджмент) инженерией ПО (Software Engineering Manage-

ment) – приложение общих методов управления к инженерной деятельности по

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

цессами ЖЦ ПО

Как любое управление, менеджмент ПО подразумевает планирование, коор-

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

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

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

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

высокий уровень новизны и сложности разработок (не позволяющий в полной мере

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

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

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

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

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

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

ний, а также положениями ISO/IEC 12207, где управление проектом рассматрива-

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

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

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

• инициирование и определение рамок проекта (Initiation and Scope Defini-

tion),

• планирование проекта (Software Project Planning),

• выполнение проекта (Software Project Enactment),

• обзор и оценка (Review and Evaluation),

• закрытие (Closure),

• измерения в инженерии ПО (Software Engineering Measurement).

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

связанных с принятием решений о начале программного проекта. Это вопросы эф-

фективного выявления, анализа, специфицирования и проверки требований к ПО с

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

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

точек зрения (технической, технологической, финансовой, политической и др.);

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

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

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

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

ловий его осуществимости.

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

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

Глава 2 71

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

ной, эволюционной и т.п.) и применяемых процессов ЖЦ, а также методов и инст-

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

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

шения. Далее по каждой задаче специфицируются результаты выполнения (арте-

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

го-сопоставительных методов (по накопленным историческим данным) или экс-

пертным путем. Идентифицируются связи и зависимости между задачами и потен-

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

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

сроки выполнения и расписание (график) работ (например, в форме PERT-

диаграмм). Требования к ресурсам трансформируются в прогнозируемые затраты

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

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

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

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

финансовых ресурсов (с отражением, например, в диаграмме Ганта).

К данному разделу знаний SWEBOK отнесены также вопросы управления

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

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

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

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

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

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

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

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

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

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

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

и, при необходимости, восстанавливаться.

Основой успешного Выполнения проекта является следование плану проек-

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

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

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

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

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

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

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

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

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

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

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

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

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

базис для принятия решений и регулирования

проекта, т.е. выполнения корректи-

Используемый в Руководстве к SWEBOK термин control лучше переводить как ре-

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

72 Глава 2

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

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

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

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

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

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

достижении установленных целей и удовлетворении требований заинтересованных

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

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

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

тижения критериев завершения проекта наступает Закрытие проекта. На этой

стадии оценивается успешность проекта, принимается и утверждается решение о

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

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

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

Измерения в инженерии ПО направлены на получение количественных

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

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

же методы измерений, определены в стандарте ISO/IEC 15939:2002 «Software Engi-

neering - Software Measurement Process», который описывает информационную мо-

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

для реализации процесса измерений. В полном соответствии с этим стандартом в

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

ний в отношении измерений (уровень, цели и объекты измерений, потребители

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

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

процесса измерений и выделения ресурсов; организация измерений в подразделе-

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

полняемые процессы); анализ результатов измерений, составление отчета о полу-

ченном информационном продукте и его передача потребителю измерений; оценка

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

2.2.9. Область знаний «Процесс программной инженерии»

Процесс программной инженерии (Software Engineering Process, SEP), как об-

ласть знаний, представлен в Руководстве к SWEBOK на двух уровнях описания.

Прежде всего (на нижнем уровне), SEP – это множество взаимосвязанных ви-

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

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

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

инженерии рассматривается практически повсюду в Руководстве к SWEBOK.

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

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

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

рению, управлению и совершенствованию собственно процессов ЖЦ, формирую-

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

проектам). Именно этот аспект SEP имеется в виду при рассмотрении данной об-

ласти знаний SWEBOK.

Глава 2 73

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

• реализация и изменение процесса (Process Implementation and Change),

• определение процесса (Process Definition),

• оценивание процесса (Process Assessment),

• измерения процесса и продукта (Process and Product Measurement),

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

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

ложение вопросов раздела базируется на стандартах ISO/IEC 12207 и ISO/IEC

15504 «Information technology - Software process assessment».

Инфраструктура SEP может организовываться по типу Группы процесса про-

граммной инженерии SEPG (от Software Engineering Process Group) или по типу

экспериментальной фабрики EF (от Experience Factory)

. SEPG образуют специа-

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

там) входит внедрение и совершенствование процессов ЖЦ. В отличие от SEPG,

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

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

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

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

внедрения в проекты «пакетов опыта» (experience packages). Пакеты формируются

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

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

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

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

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

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

тивного цикла: 1) планирование внедрения нового процесса или совершенствования

существующего, а также разработку плана реализации или изменения процесса; 2)

собственно осуществление реализации или изменения процесса; и 3) оценку реали-

зации процесса и отдачи от его внедрения.

В SWEBOK упомянуты две распространенные модели реализации и измене-

ния SEP – модель QIP (от Quality Improvement Paradigm) и модель IDEAL (от Initiat-

ing-Diagnosing-Establishing-Acting-Learning)

, а также два подхода к оценке реали-

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

второй - в оценке результатов (наработок) процесса

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

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

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

ЖЦ и уровень зрелости самой организации.

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

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

. Определение про-

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

порядка выполнения работ во времени. Это определение может быть «выстроено»

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

Чаще говорят о SEPG, которая может быть или не быть организована по типу EF.

Механизмы работы EF, а также модели QIP и IDEAL рассматриваются в главе 11.

Эти подходы рассматриваются в главе 12.

Модели ЖЦ (каскадная, спиральная и другие) представлены в приложении 1.

74 Глава 2

Можно согласиться с С.Орликом [1], что совокупность модели ЖЦ, процес-

сов ЖЦ и приемов их выполнения определяют методологию поддержки ЖЦ ПО.

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

ISO/IEC 12207 (а также руководство к нему - ISO/IEC 15271:1998) и IEEE Std.

1074:1997 «IEEE Standard for Developing Software Life Cycle Processes» (стандарт по

разработке процессов ЖЦ). Кроме того, существуют стандарты по отдельным про-

цессам ЖЦ, например, IEEE Std. 1219:1998 «IEEE Standard for Software Mainte-

nance» или ISO/IEC 14764:1999 «Information technology - Software Maintenance»,

IEEE Std. 1540:2001 «IEEE Standard for Software Life Cycle Processes - Risk Manage-

ment», IEEE Std. 1517:1999 «Software Reuse Processes», ISO/IEC 15939:2002 «Soft-

ware Engineering - Software Measurement Process» и другие

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

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

цированной по стандарту ISO 9001:2001, который формулирует требования к про-

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

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

зованием различных нотаций: диаграмм потоков данных; перечислений целей и

результатов процессов (как, например, в ISO/IEC 15504); набора процессов и их

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

например, в ISO/IEC 12207); диаграмм переходов состояний, SADT, IDEF0 и др.

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

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

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

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

адаптации содержатся в ISO/IEC 12207 и ISO/IEC 15504.

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

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

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

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

лей и методов.

Типовая модель оценивания (SPICE) определена в стандарте ISO/IEC 15504.

Там же содержатся требования по соответствию других моделей (например, SW

CMM, CMMI, Bootstrap и др.) этой типовой модели. На практике используются две

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

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

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

ных параметров оцениваемого процесса, которые характеризуют мощность этого

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

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

Измерения процессов и продуктов этих процессов могут проводиться для

идентификации сильных и слабых сторон процессов (в определенном контексте их

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

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

Перечень действующих стандартов представлен в приложении 3.

Процессы ЖЦ, внедряемые в соответствии с ISO 9001, описаны в главе 12.

Модели и методы оценивания процессов описаны в главе 12.

Глава 2 75

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

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

туры и других характеристик программных продуктов, а также эффективности

применяемых технологий.

Ключевые понятия, термины и методы измерений в программной инженерии

определены в стандарте ISO/IEC 15939:2002 «Software Engineering - Software Meas-

urement Process» наряду с определением самого базового процесса измерения ха-

рактеристик процессов и продуктов

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

эталонные (benchmarking) и используются совместно, поскольку основываются на

различных типах взаимодополняющей информации.

Аналитические подходы включают экспериментальное исследование процес-

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

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

стандартом ISO/IEC 12207), ортогональную классификацию дефектов (изъянов в

процессе), анализ коренных причин (Root Case Analysis), статистический контроль

процесса.

Подходы «от эталонов» базируются на идентификации «совершенной» орга-

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

(например, наработок таких организаций, как SEI и PMI).

2.2.10. Область знаний «Инструменты и методы программной инжене-

рии»

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

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

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

симости от охватываемой области приложения) и применяются на отдельных фазах

жизненного цикла или в течение всего ЖЦ.

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

• инструменты программной инженерии (Software Engineering Tools),

• методы программной инженерии (Software Engineering Methods).

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

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

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

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

тов. Краткая характеристика инструментов в предложенной SWEBOK классифика-

ции представлена в таблице 2.1.

Методы программной инженерии классифицируются как:

– эвристические (неформальные) методы: структурные, объектно-

ориентированные, ориентированные на данные;

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

специфицирования, методы уточнения (трансформации), методы подтверждения/

доказательства,

– методы прототипирования: стили прототипирования, цели прототипи-

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

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