ГОСТ Р ИСО/МЭК 25041-2014. Национальный стандарт Российской Федерации. Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Руководство по оценке для разработчиков, приобретателей и независимых оценщиков

(утв. и введен в действие Приказом Росстандарта от 11.06.2014 № 556-ст)

от 11 июня 2014 г. № 556-ст

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО «ИАВЦ») на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 11 июня 2014 г. № 556-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25041:2012 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Руководство по оценке для разработчиков, приобретателей и независимых оценщиков» (ISO/IEC 25041:2012 «Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation guide for developers, acquirers and independent evaluators»)

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ 1.5 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА.

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Октябрь 2016 г.

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в годовом (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

Введение

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

Оценка — это систематическое определение степени, с которой объект соответствует заданным критериям. Оценка качества программной продукции жизненно важна, как при ее приобретении, так и при разработке. Относительная важность различных характеристик качества программного обеспечения зависит от предполагаемого использования или задач системы, частью которой программное обеспечение является. Для того чтобы решить, удовлетворяют ли соответствующие характеристики качества требованиям системы, необходимо произвести оценку программной продукции.

Настоящий стандарт — составная часть серии стандартов SQuaRE ИСО/МЭК 250.... Стандарт ИСО/МЭК 25040 содержит общие требования и рекомендации для оценки качества продукции, а также связанные с этим общие понятия. Настоящий стандарт отвечает на конкретные вопросы, связанные с разработчиками, приобретателями и независимыми оценщиками на основе ИСО/МЭК 25040.

Общая цель создания серии стандартов SQuaRE — построить логически организованную, обогащенную и объединенную серию стандартов, покрывающую два основных процесса: спецификацию требований к качеству программного обеспечения и оценку качества программного обеспечения с поддержкой процесса измерения качества. Цель серии стандартов SQuaRE — помочь разработчикам и приобретателям программных продуктов в спецификации и оценке требований к качеству. При этом определяются критерии для спецификации требований к качеству программного продукта, их измерения и оценку. Предлагаемая модель качества предназначена для того, чтобы согласовать потребительские определения качества с атрибутами процесса разработки. Кроме того, серия стандартов предоставляет рекомендуемые показатели атрибутов качества программной продукции, которые могут использоваться разработчиками, приобретателями и оценщиками.

SQuaRE обеспечивает:

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

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

Серия SQuaRE замещает текущие серии стандартов ИСО/МЭК 9126 и ИСО/МЭК 14598.

Серия стандартов SQuaRE состоит из следующих разделов под общим названием: «Требования и оценка качества систем и программных продуктов»:

• ИСО/МЭК 2500n — Раздел «Менеджмент качества»,
• ИСО/МЭК 2501n — Раздел «Модель качества»,
• ИСО/МЭК 2502n — Раздел «Измерения качества»,
• ИСО/МЭК 2503n — Раздел «Требования к качеству» и
• ИСО/МЭК 2504n — Раздел «Оценка качества».

Настоящий стандарт предназначен для использования в сочетании с другими стандартами серии SQuaRE, с серией ИСО/МЭК 14598 и серией ИСО/МЭК 9126 до тех пор, пока они не будут заменены серией стандартов ИСО/МЭК 250...

Настоящий стандарт основан, главным образом, на международных стандартах ИСО/МЭК 14598-3, ИСО/МЭК 14598-4 и ИСО/МЭК 14598-5. Их заменой и будет настоящий стандарт.

Рисунок 1 иллюстрирует организацию серии стандартов SQuaRE, в которую входят семейства стандартов, далее называемые разделами.

В модель SQuaRE входят следующие разделы:

• ИСО/МЭК 2500n — Раздел «Менеджмент качества». Международные стандарты, входящие в этот раздел, определяют все общие модели, термины и определения, используемые всеми другими стандартами серии SQuaRE. Направляющие ссылки, используемые во всех документах SQuaRE, и высокоуровневые практические предложения по применению соответствующих стандартов в случаях конкретных приложений помогут всем потребителям. В разделе также представлены требования и методические материалы по поддерживающей функции, отвечающей за менеджмент требований к программной продукции, спецификацию и оценку;
• ИСО/МЭК 2501n — Раздел «Модель качества». Международные стандарты, которые входят в этот раздел, представляют детализированные модели качества программного обеспечения, качества при использовании и качества данных. Кроме того, представлено практическое руководство по использованию модели качества;
• ИСО/МЭК 2502n — Раздел «Измерение качества». Международные стандарты, входящие в этот раздел, включают в себя эталонную модель измерения качества программной продукции, математические определения показателей качества и практическое руководство по их использованию. В этом разделе представлены показатели внутреннего качества программного обеспечения, показатели внешнего качества программного обеспечения и показатели качества при использовании. Кроме того, определены и представлены элементы показателей качества (ЭПК), формирующие основу для вышеперечисленных показателей;
• ИСО/МЭК 2503n — Раздел «Требования к качеству». Международные стандарты, которые входят в этот раздел, помогают задать требования к качеству. Такие требования к качеству могут использоваться в процессе формирования требований к качеству, при сборе информации перед разработкой программной продукции или как вход для процесса оценки. Процесс определения требований отнесен к техническим процессам, определенным в ИСО/МЭК 15288;
• ИСО/МЭК 2504n — Раздел «Оценка качества». Международные стандарты, которые входят в этот раздел, формулируют требования, рекомендации и методические материалы для оценки программного продукта, выполняемой как независимыми оценщиками, так и приобретателями или разработчиками. Кроме того, там представлена поддержка документирования измерения, как модуля оценки.

Номера ИСО/МЭК 25050 — ИСО/МЭК 25099 зарезервированы с тем, чтобы быть использованными для расширения международных стандартов SQuaRE и/или технических отчетов.

Настоящий стандарт — это составная часть ряда стандартов 2504n из раздела оценки качества, который в настоящее время состоит из следующих международных стандартов:

• ИСО/МЭК 25040 — «Процесс оценки». В нем содержатся общие требования к спецификации и оценке качества программного обеспечения, а кроме того и общие понятия. Содержится описание процесса оценки качества программного продукта и устанавливаются требования для использования этого процесса. Процесс оценки является основой оценки качества программной продукции для различных целей и подходов. Поэтому процесс можно использовать для оценки показателей качества при использовании внешнего и внутреннего качества программного обеспечения. Кроме того, процесс может быть применен для оценки качества как уже разработанного программного обеспечения, так и заказанного программного обеспечения в процессе его разработки. Оценка качества программного продукта может быть произведена, например, приобретателем, организацией разработчика или независимым оценщиком;
• ИСО/МЭК 25041 — Методические материалы по оценке для разработчиков, приобретателей и оценщиков содержат специальные требования и рекомендации для разработчиков, приобретателей и оценщиков;
• ИСО/МЭК 25042 — «Модули оценки». Стандарт определяет структуру и содержание документации, которую следует использовать для описания модуля оценки. Эти модули оценки содержат спецификацию модели качества (т.е. характеристики, подхарактеристики и соответствующие показатели внутреннего, внешнего качества или показатели качества при использовании), соответствующие данные, а также информацию о планируемом использовании модели и информацию о ее фактическом применении. Для каждой оценки выбирают соответствующие модули оценки. В некоторых случаях, возможно, потребуется разработка новых модулей оценки. Руководство по разработке новых модулей оценки можно найти в ИСО/МЭК 25042. Этот международный стандарт также могут использовать организации, разрабатывающие новые модули оценки;
• ИСО/МЭК 25045 — «Модуль оценки восстанавливаемости». В стандарте приведена спецификация оценки подхарактеристики восстанавливаемости, определенной как подмножество характеристики надежности из модели качества. Стандарт определяет показатели отказоустойчивости и автономного восстановления, относящиеся к внешнему качеству программного обеспечения, когда информационная система, выполняющая операции одного или более программных продуктов, подвергается серии угрожающих воздействий. Подобное воздействие может быть функциональной ошибкой (например, внезапное завершение работы процесса операционной системы, которое переводит систему в нерабочее состояние), или другим событием (например, существенное увеличение пользователей системы).

ИСО/МЭК 25040 является исправленной версией и заменяет ИСО/МЭК 14598-1.

Настоящий стандарт ИСО/МЭК 25041 является исправленной версией и заменяет ИСО/МЭК 14598-3, ИСО/МЭК 14598-4 и ИСО/МЭК 14598-5.

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

В настоящем стандарте термин «процесс оценки» используется как упрощенный термин для термина «процесс оценки качества продукции».

В настоящем стандарте термин «отчет об оценке» используется как упрощенный термин для термина «отчет об оценке качества продукции», а термин «план оценки» — для термина «план оценки качества продукции».

1 Область применения

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

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

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

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

2 Соответствие

Оценка качества продукции соответствует настоящему стандарту, если для разработчиков выполняются требования разделов 6 и 7, для приобретателей выполняются требования разделов 6 и 8 и для независимых оценщиков выполняются требования разделов 6 и 9.

3 Нормативные ссылки

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

ИСО/МЭК 25000 Системная и Программная инженерия. Требования и оценка качества программной продукции (SQuaRE). Руководство по SQuaRE (ISO/IEC 25000 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE)

ИСО/МЭК 25001 Системная и программная инженерия. Требования и оценка качества программной продукции (SQuaRE). Планирование и менеджмент (ISO/IEC 25001, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Planning and management)

ИСО/МЭК 25030 Программная инженерия. Требования и оценка качества программной продукции (SQuaRE). Требования к качеству (ISO/IEC 25030, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements)

ИСО/МЭК 25040 Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки (ISO/IEC 25040, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation process)

4 Термины и определения

В настоящем стандарте применены термины по ИСО/МЭК 25000.

4.1 поставляемая продукция (deliverable product): Любая уникальная и поддающаяся проверке система или программная продукция для выполнения услуг, подлежащая одобрению спонсором проекта или потребителем.

4.2 динамическая продукция (dynamic product): Система или программная продукция, на которой можно проводить измерения в течение выполнения в тестовой и/или функциональной среде.

4.3 оценка (оценивание) (evaluation): Систематическое определение степени, с которой некоторый объект удовлетворяет установленным критериям (ИСО/МЭК 12207).

4.4 уровень оценки (evaluation level): Строгость оценки, которая определяет глубину или тщательность оценки с точки зрения применяемых методик и результатов оценки, которые будут получены.

4.5 записи оценки, протокол (evaluation records): Задокументированные объективные свидетельства о всех выполняемых действиях и всех полученных в процессе оценки результатах.

4.6 сторона, запрашивающая оценку (evaluation requester): Человек или организация, которые запрашивают оценку.

4.7 инструмент оценки (evaluation tool): Инструмент, который может использоваться во время оценки для сбора данных, интерпретации данных или автоматического выполнения части оценки.

Примечание - Примеры таких инструментов — это анализаторы показателей исходного кода, CASE-инструментарии, подготавливающие формализованные модели, тестовые среды для прогона исполняемых программ, контрольные списки для сбора проверочных данных или электронные таблицы для получения показателей.

4.8 строгость оценки (evaluation stringency): Степень, требуемая от характеристик и подхарактеристик качества программной продукции для ожидаемой критичности использования программной продукции.

4.9 независимый оценщик (independent evaluator): Человек или организация, которые выполняют оценку независимо от разработчиков и приобретателей.

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

4.10 промежуточный продукт (intermediate product): Система или программный продукт процесса разработки, которые используются в качестве входного для другой стадии процесса разработки.

4.11 качество продукции (product quality): Степень, с которой продукция удовлетворяет заявленным и подразумеваемым потребностям при использования в заданных условиях.

Примечания

1 Данное определение отличается от определения качества ИСО 9000, потому что здесь определение качества программного обеспечения относится к удовлетворению установленных и подразумеваемых потребностей, в то время как определение качества ИСО 9000 относится к удовлетворению требований.

2 Адаптировано из ИСО/МЭК 25000, изменено перефразированием «степень, с которой».

4.12 статическая продукция (static product): Неисполняемые система или программная продукция для анализа.

5 Понятие оценки с точки зрения каждой роли

5.1 Структура оценки качества продукции с точки зрения каждой роли

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

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

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

Рисунок 2 — Общая структура процесса оценки качества

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

Входной информацией для процесса оценки являются:

• потребности оценки разработчиков, приобретателей и независимых оценщиков;
• целевые объекты оценки, такие как статические и динамические продукты.

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

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

На этом рисунке стандарты серии SQuaRE (ИСО/МЭК 25010, ИСО/МЭК 25020, ИСО/МЭК 2502..., ИСО/МЭК 25030, ИСО/МЭК 2504...) входят в состав ресурсов для оценки.

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

a) конкретные потребности оценки пользователя;

b) график проекта оценки;

c) бюджет проекта оценки;

d) условия среды проекта оценки;

e) инструменты и методы, используемые в проекте оценки;

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

В ресурсы процесса оценки качества продукции могут входить:

a) применимые инструменты и методы измерения;

b) применимые международные стандарты из серии SQuaRE;

c) человеческие ресурсы, используемые для оценки;

d) финансовые ресурсы, необходимые для оценки;

e) информационные системы, используемые для оценки;

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

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

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

5.2 Целевая сущность оценки качества программной продукции

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

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

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

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

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

К динамическим продуктам можно отнести:

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

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

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

Примечание - Целевыми объектами оценки с точки зрения разработчика являются статические и динамические промежуточные и/или конечные продукты.

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

Приобретатели тестируют динамический продукт на этапе приемочных испытаний или испытаний в реальных условиях.

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

Примечание - Целевыми объектами оценки с точки зрения приобретателя являются статические и динамические промежуточные и/или конечные продукты.

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

Примечание - Целевыми объектами оценки с точки зрения независимого оценщика являются на основании между оценщиком и запрашивающей стороной статистические и динамические промежуточные и/или конечные продукты.

Таблица 1

Пример целевого объекта для каждой роли

Роль	Целевой объект оценки
	Статический продукт	Динамический продукт
Разработчики	Промежуточные и конечные продукты для анализа	Промежуточные и конечные продукты для анализа
Приобретатели	Требования к качеству и документы проекта для анализа конечного продукции	Конечные продукты для выбора и приемки
Независимые оценщики	Промежуточные или конечные продукты для анализа	Промежуточные или конечные продукты для анализа

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

5.3 Роли и ответственности

5.3.1 Роли и ответственности разработчиков

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

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

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

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

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

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

5.3.2 Роли и ответственности приобретателей

Персонал заказчика, ответственный за оценку качества, отвечает за то, чтобы:

• принятие заказных коммерческих продуктов, удовлетворяющих требованиям к качеству;
• выбор продукта готового массового программного обеспечения приемлемого качества;
• повышение эффективности динамических продуктов, включенных в функциональную целевую систему;
• повышение производительности процесса приобретения;
• обучение персонала для оценки качества.

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

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

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

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

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

Оценку при приобретении готовой программной продукции можно использовать для сравнения альтернативных продуктов, чтобы обеспечить удовлетворение выбранным продуктом требований к уровню качества. Возможные действия при этом включают в себя следующее:

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

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

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

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

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

Примечания

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

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

5.3.3 Роли и ответственности независимых оценщиков

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

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

В ответственность независимых оценщиков относительно оценки качества может быть включено следующее:

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

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

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

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

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

6.1 Общие требования и рекомендации

Эталонная модель процесса оценки качества программной продукции определяет процесс и детали действий и задач, необходимых для достижения цели, а также предоставляет дополнительную информацию, которая может быть использована для выполнения оценки качества продукции (см. ИСО/МЭК 25040).

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

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

Эталонная модель процесса оценки качества программной продукции требует, чтобы оценка базировалась на спецификации требований к качеству продукции с использованием ИСО/МЭК 25030 перед оценкой и определением четких целей и критериев оценок. Требования к качеству продукции выражают потребности пользователя в рассматриваемой продукции и определены перед разработкой (см. ИСО/МЭК 25030).

ИСО/МЭК 25001 применим к группе оценки, которая обеспечивает поддержку в рамках всей организации всех проектов оценки качества продукции, выполняемых независимыми оценщиками в процессе разработки программного обеспечения или приобретения программного обеспечения.

ИСО/МЭК 25001 устанавливает требования и рекомендации для организации, ответственной за реализацию и управление спецификацией требований к качеству продукции, а также за действия по оценке качества программного обеспечения на основе предоставления технологии, инструментов, опыта и управленческих навыков.

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

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

Качество программной продукции в рамках определенной структуры качества может быть оценено на всех этапах жизненного цикла, относящихся к процессу внедрения, как это определено в ИСО/МЭК 12207 и ИСО/МЭК 15288.

6.2 Документация оценки качества программной продукции

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

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

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

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

Решения, принятые в процессе оценки, также должны быть включены в протокол оценки, как это определено в плане оценки.

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

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

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

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

Примечания

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

• результаты анализа спецификации проекта (статической промежуточной или конечной продукции);
• результаты тестирования (тест модуля программы, комплексное испытание системы, тест в рабочих условиях перед выпуском продукции);
• спецификация любой прогнозирующей модели, которая будет использоваться в качестве индикатора качества продукции;

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

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

• результаты анализа спецификации проекта (статическая, промежуточная или конечная продукция);
• результаты тестирования (тестирование системы в эксплуатационном режиме, тестирование демонстрационной системы перед выбором самой подходящей продукции);
• спецификация любой прогнозирующей модели, которая будет использована в качестве индикатора качества продукции;
• идентификация любых субподрядных организаций разработчиков или тестеров и продукции или любых артефактов, произведенных такими организациями.

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

• результаты анализа спецификации проекта (статическая, промежуточная или конечная продукция);
• результаты тестирования (тест модуля программы, комплексное испытание системы, тест в рабочих условиях перед выпуском продукции, тестирование системы в эксплуатационном режиме, тестирование демонстрационной системы перед выбором самой подходящей продукции);
• спецификация любой прогнозирующей модели, которая будет использована в качестве индикатора качества продукции.

6.3 Требования и рекомендации организационного уровня для поддержки каждой роли

6.3.1 Общие требования

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

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

Любая организация, включающая в себя группу оценки качества, должна:

• проявлять организационный подход в целях поддержки индивидуальных проектов разработки и совершенствования эффективности процесса оценки;
• установить общую систему управления качеством и вспомогательные информационные системы для управления и поддержки конкретных проектов оценки с точки зрения общей оптимизации;
• определить ресурсы и инфраструктуру для процесса оценки;
• определить ограничения оценки с точки зрения общей структуры оценки, показанной в рисунке 2;
• обеспечить общий промышленный формат для создания плана и отчета оценки для контроля и поддержки конкретных проектов оценки;
• определить общую политику, правила и инструкции для контроля конкретных проектов по оценке;
• установить и обслуживать вспомогательные системы, стандарты и методические материалы, включая инструменты и методы управления и выполнения оценки для использования проектами организации.

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

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

6.3.2 Рекомендации организационного уровня для разработчиков

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

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

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

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

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

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

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

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

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

• обеспечивать стандартизированные общие методы оценки для принятия конечной продукции;
• обеспечивать стандартизированные общие методы оценки для контроля поставщиков продуктов;
• оценивать эффективность и качество динамических рабочих продуктов;
• проявлять организационные подходы в целях поддержки отдельных проектов оценки для обеспечения качества принятой продукции и совершенствования эффективности процесса приобретения;
• обеспечивать список или базу данных продуктов готового массового программного обеспечения и стандартизированный общий метод сравнения для выбора лучшего с точки зрения качества продукции.

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

• качество динамических рабочих продуктов, которые будут включены в фактический состав эксплуатируемой системы;
• эффективность или производительность фактически используемых продуктов;
• качество принятых продуктов;
• технический уровень поставщиков;
• уровень завершенности разработки программной продукции;
• уровень завершенности обслуживания программной продукции;

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

6.3.4 Требования организационного уровня для независимых оценщиков

Организация независимого оценщика должна:

• для достижения своих целей создать независимую группу оценки для поддержки отдельных проектов в рамках организации;
• проявлять организационные подходы в целях поддержки отдельных проектов оценки для обеспечения качества полученных результатов и совершенствования эффективности процесса оценки;
• создать инфраструктуру и ресурсы организации для поддержки отдельных конкретных проектов оценки на основе потребностей запрашивающей оценку стороны;
• обеспечить инфраструктуру с точки зрения разработчиков, приобретателей или независимых оценщиков на основании договора и опыта отдельных прошлых подобных проектов оценки.

Примечания

1 В целях обеспечения эффективности и надежной оценки с точки зрения опытного, знающего эксперта независимая группа оценки для выполнения оценки качества продукции обеспечивает адаптацию лучших методов и инструментов.

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

7 Требования и рекомендации для процесса оценки разработчиками

7.1 Общие требования

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

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

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

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

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

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

Примечания

1 Соответствующие процессы жизненного цикла определены в ИСО/МЭК 12207. Входящие в их состав действия описаны в 6.4 и 7.1.

2 Общие понятия процесса оценки качества программной продукции можно найти в ИСО/МЭК 25040. Разработчики должны согласовывать действия по оценке с поддержкой процессов и действий.

3 Процессы поддержки программного обеспечения определены в ИСО/МЭК 12207, включая, в частности, процесс обеспечения качества (см. 7.2.3), процесс проверки программного обеспечения (см. 7.2.4), процесс проверки допустимости программного обеспечения (см. 7.2.5) и процесс аудита программного обеспечения (см. 7.2.7).

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

7.2 Установите требования к оценке

7.2.1 Входы и выходы процесса

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

a) потребности оценки качества продукции;

b) спецификация требований к качеству продукции;

c) применимые инструменты и методология измерений;

d) продукт, который будет оценен, включая промежуточные и конечные продукты.

Результатами должны быть:

a) спецификация целей оценки качества продукции;

b) спецификация требований к оценке качества продукции;

c) высокоуровневый план оценки качества продукции.

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

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

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

Определение требований к оценке состоит из следующих задач.

7.2.2 Установите цели оценки

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

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

Цель оценки статического и динамического промежуточного качества продукции может включать в себя следующее:

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

Цель оценки качества конечной статической и динамической продукции может охватывать следующее:

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

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

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

Перед оценкой качества программной продукции требования к качеству должны быть определены с точки зрения характеристик и подхарактеристик качества (см. ИСО/МЭК 25010). Спецификации требований к качеству продукции должны предусматривать следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показатели внутреннего качества программной продукции можно использовать в качестве показателей внешних свойств.

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

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

7.2.4 Идентифицируйте части продукции, подлежащие оценке

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

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

• техническая спецификация изделия;
• исходные тексты программы;
• производственные руководства;
• описание конечной продукции;
• результаты тестов (комплексное испытание системы, рабочее тестирование перед выпуском продукции);
• исполнимая программа тестирования.

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

• проектная документация;

- спецификация продуктов;

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

7.2.5 Определите строгость оценки

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

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

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

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

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

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

7.3 Задайте оценку

7.3.1 Входы и выходы процесса

Входными данными для определения оценки должны быть:

a) спецификация требований к оценке качества продукции;

b) спецификация требований к качеству продукции;

c) высокоуровневый план оценки качества продукции.

Результатами этого действия должны быть:

a) спецификация выбранных показателей качества;

b) спецификация критериев решения для показателей качества продукции;

c) спецификация критериев решения по оценке качества продукции;

d) пересмотренный высокоуровневый план оценки качества продукции.

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

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

Это действие состоит из следующих задач.

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

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

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

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

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

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

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

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

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

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

Такая идентификация должна включать в себя, по крайней мере, название инструмента, идентификацию его версии и источников (например, поставщиков, разработчиков).

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

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

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

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

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

Спецификация оценки должна включать в себя следующее:

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

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

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

В частности, показатели внутренних свойств программного обеспечения зачастую используются, как показатели качества конечной продукции; однако какая-либо общая или непосредственная связь между измеренными значениями показателей внутреннего качества и значениями показателей внешнего качества не подтверждается.

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

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

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

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

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

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

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

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

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

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

Примерами таких показателей тенденции являются: «Количество тестирования завершенных модулей», «Количество разрешенных проблем», «Количество измененных требований», в течение каждой недели и т.д.

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

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

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

ИСО/МЭК 2502... можно использовать в качестве руководства для выбора показателей (мер) качества.

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

Индикатор не требует жесткой один к одному связи со свойствами, которые он призван измерить. Тем не менее, связь между индикатором(ами) и соответствующим свойством(ами) должна быть четко определена.

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

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

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

7.3.3 Определите критерии решения для показателей качества

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

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

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

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

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

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

7.3.4 Определите критерии решения для оценки

Критерии решения по оценке целевой продукции путем обобщения результата оценки (показателей качества) должны быть определены на основании требований к качеству целевой продукции.

Оценщики должны подготовить процедуру последующего обобщения результатов с отдельными критериями для различных характеристик качества. Каждый из критериев может относиться либо к отдельным подхарактеристикам и показателям качества, либо к взвешенной комбинации подхарактеристик и показателей качества.

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

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

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

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

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

7.4 Спроектируйте оценку

7.4.1 Входы и выходы процесса

Входные данные для разработки процесса оценки:

a) спецификация требований к оценке качества продукции;

b) спецификация требований к качеству продукции;

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

d) спецификация критериев решения для показателей качества продукции;

e) спецификация критериев решения по оценке качества продукции;

f) высокоуровневый план оценки качества продукции.

Результатами этого действия должны быть:

a) подробный план оценки качества продукции;

b) методы оценки качества продукции.

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

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

• спецификация продукции;
• исходные коды программы;
• производственные руководства;
• описания продукции.

Разработка оценки состоит из следующих действий.

7.4.2 Спланируйте деятельность по оценке

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

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

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

План оценки качества для каждой стадии разработки должен включать 5W3H (Why (почему), What (что), When (когда), Who (кто), Where (где), How to (как), How much (сколько стоит) and How many (сколько)), т.е. следующее:

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

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

В случае, когда целевым объектом является динамический продукт, метод оценки — это тестирование (поблочное тестирование, комплексное тестирование системы) на основе показателей внешнего качества программной продукции и показателей качества использования.

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

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

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

План оценки не должен содержать дублирующих действий.

План оценки должен включать в себя моменты принятия решения в процессе оценки, которые определяют, когда и почему оценка может быть завершена и/или остановлена (т.е. принятие или отклонение по критериям).

Вышесказанное должно быть сделано для уменьшения риска ошибок и сокращения запланированных трудозатрат по оценке при рассмотрении следующих аспектов:

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

В план оценки обязательно должна входить цель оценки. План оценки должен обязательно учитывать контекст оценки в рамках организации [см. роль группы поддержки оценки в ИСО/МЭК 25001 и шаблон плана проекта оценки качества в приложении A ИСО/МЭК 25001].

План оценки должен включать следующее:

• цель оценки качества продукции;
• организации, включенные в оценку, такие как независимая организация оценки, разработчики продукции и организационные единицы заказчика;
• бюджет оценки;
• информационные продукты, ожидаемые от оценки;
• график основных этапов оценки;
• обязанности сторон, участвующих в оценке;
• условия для оценки;
• методы и инструменты оценки;
• критерии решения для показателей качества продукции;

- критерии решения по оценке качества продукции;

• принятые стандарты;
• действия по оценке.

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

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

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

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

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

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

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

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

7.5 Выполните оценку

7.5.1 Входы и выходы процесса

Для выполнения оценки необходимы следующие входные данные:

a) подробный план оценки качества продукции;

b) спецификация требований к оценке качества продукции;

c) спецификация требований к качеству продукции;

d) спецификация выбранных показателей качества;

e) спецификация критериев решения для измерения качества продукции;

f) спецификация критериев решения по оценке качества продукции;

g) спецификация методов оценки качества продукции;

h) продукт, подлежащий оценке, включая промежуточные продукты.

Результатами этого действия должны быть:

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

b) анализ и оценка продукции.

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

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

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

7.5.2 Выполните измерения

Оценщики на основе плана оценки должны измерить качество статической и динамической продукции (например, спецификации требований, проектные схемы и документация по тестированию, исполняемый продукт).

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

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

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

• список обнаруженных проблем;
• используемый контрольный список анализа проекта, в который включены критерии решения для показателей (мер).

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

Значение измерения должно быть документировано на основе результата тестирования в соответствии с планом оценки качества продукции. Дополнительная информация о тестировании должна включать в себя:

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

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

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

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

Для достижения эффективного повышения качества продукции и производительности разработки обнаруженные проблемы качества продукции должны быть разрешены на самых ранних этапах разработки во избежание переноса проблем на следующие этапы разработки.

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

В процессе разработки осуществляют контроль и управление качеством. Собирают фактические значения внутренних свойств. В случае нежелательных результатов анализируют причину, что позволяет разработчикам понять проблемы и реагировать на них.

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

7.5.3 Примените критерии решения для показателей качества

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

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

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

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

Примечания

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

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

7.5.4 Примените критерии решения для оценки

Для оценки статических и динамических продуктов (например, спецификации требований, проектных схем, документации по тестированию и исполняемой продукции) в процессах жизненного цикла разработки программного обеспечения критерии решения по оценке качества продукции на основании требований к качеству должны быть применены к результату, обобщенному по характеристикам и подхарактеристикам качества.

Примечания

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

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

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

Результаты оценки должны:

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

2 выявить любые конкретные недостатки в отношении требований оценки и какие-либо дополнительные оценки, необходимые для определения сферы влияния этих недостатков;

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

4 определить все слабые места или недостатки в самой оценке и любой необходимой дополнительной оценке;

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

В процессе разработки программного обеспечения, как правило, выполняют несколько оценок согласно этапам, установленным в плане оценки. Результаты оценки важны для поддержки организаторских решений по следующим этапам жизненного цикла разработки программного обеспечения. Например, должны ли быть изменены требования или необходимо ли больше ресурсов для процесса разработки.

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

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

Оценку качества продукции производят по завершении разработки. Собирают фактические значения свойств продукции. Когда это возможно, измерения компонентов продукции производят до завершения разработки.

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

7.6 Завершите оценку

7.6.1 Входы и выходы процесса

Входные данные для этого действия следующие:

a) спецификация требований к оценке качества продукции;

b) фактические результаты выполнения плана оценки качества продукции;

c) спецификация методов оценки качества продукции;

d) результаты оценки.

Результатом этого действия является:

a) отчет об оценке качества продукции.

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

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

Завершение оценки состоит из следующих задач.

7.6.2 Проанализируйте результаты оценки

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

Группа оценщиков должна рассмотреть результаты оценки статических конечных продуктов (например, спецификации требований, проектных схем и документации по тестированию).

Целевым объектом анализа являются результаты статических промежуточных или конечных продуктов (например, спецификация требований, проектные схемы и документация по тестированию).

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

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

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

Для анализа должен быть назначен надлежащий специалист.

Анализ результатов оценки качества статической продукции должен быть выполнен, основываясь на плане оценки качества и отчете об оценке. Может потребоваться следующая дополнительная информация об анализе:

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

Анализ результатов оценки качества динамической продукции должен быть выполнен на основе плана оценки качества и отчета об оценке. Необходима следующая дополнительная информация об анализе:

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

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

Отчет об анализе должен быть предоставлен до начала следующего этапа разработки.

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

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

Группа оценщиков должна проанализировать результаты оценки и обоснованность процесса оценки, индикаторов и используемых показателей. Обратная связь анализа должна использоваться для совершенствования процесса и методов оценки (модулей оценки).

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

7.6.3 Создайте отчет об оценке

Оценщики должны подготовить отчет об оценке качества на основе плана оценки качества и окончательных результатов оценки статических и динамических продуктов (например, спецификации требований, проектных схем, документации по тестированию, исполнимой программы).

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

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

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

Отчет об оценке качества будет разным в зависимости от целевого объекта оценки.

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

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

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

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

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

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

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

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

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

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

1 требования к оценке качества продукции;

2 требования к качеству продукции;

3 план оценки качества продукции;

4 результаты измерений и выполненного анализа;

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

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

7 оценщиков и их квалификацию;

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

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

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

11 результаты оценки.

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

1 каждый недостаток, любой соответствующий анализ и как каждый недостаток был разрешен. В исправление недостатков могут быть включены следующие факты:

• один из методов оценки установил, что недостаток не является существенным,
• можно найти удовлетворительное (обходное решение), которое смягчает влияние недостатка, например, изменение продукции, отключение или удаление ненужной функциональности, восстановление недостающих конструктивных требований с использованием реверсивного проектирования,
• исходное требование не является обязательным, и недостаток можно проигнорировать,
• недостаток приемлем при условии, что продукт будет использоваться под контролем особых условий или ограничений,
• чтобы разрешить недостаток или пробелы в оценке необходимы дополнительные действия по оценке;

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

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

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

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

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

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

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

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

7.6.4 Проанализируйте оценку качества и обеспечьте обратную связь организации

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

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

Для повторного использования и поддержки следующих проектов оценки оценщики должны владеть информацией о фактических результатах проекта оценки, в том числе, такой информацией, как ноу-хау, профиль персонала и пр.

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

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

Обратную связь анализа следует использовать для совершенствования процесса и методов оценки (модулей оценки).

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

Примечания

1 Анализ оценки качества и обратная связь описаны в стандарте ИСО/МЭК 25001.

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

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

Оценщики должны проанализировать и упорядочить окончательные результаты оценки качества статических и динамических продуктов (например, спецификации требований, проектных схем и документации по тестированию) с тем, чтобы повторно использовать их в следующем проекте разработки или оценки.

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

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

Это возможно посредством одного из следующих способов:

• документы, подвергнутые оценке, должны быть либо возвращены запрашивающей стороне, либо заархивированы на указанный срок, либо уничтожены безопасным способом;
• отчет об оценке и протокол оценки должны быть заархивированы на указанный срок;
• все другие данные должны быть заархивированы на указанный срок или уничтожены безопасным способом.

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

8 Требования и рекомендации для процесса оценки приобретателями

8.1 Общие требования

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

Этот процесс используют организации, которые планируют заказать или повторно использовать существующий или предварительно разработанный продукт. Он может быть применен с целью принятия решения о приемке продукции, или для того, чтобы выбрать продукт из числа альтернативных продуктов (продукт может быть автономным, а может быть частью системы или частью большой продукции).

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

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

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

• улучшить требования к качеству приобретения продукции;
• обеспечить перед приобретением соответствие приобретаемой продукции спецификации проекта.

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

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

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

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

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

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

Требования к качеству продукции, выражающие потребности пользователей рассматриваемой продукции, должны быть определены до приобретения (см. ИСО/МЭК 25030).

8.2 Установите требования к оценке

8.2.1 Входы и выходы процесса

Входы и выходы этого процесса описаны в разделе 7.2.1.

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

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

При этом необходимы следующие действия.

8.2.2 Установите цели оценки

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

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

Цель оценки статического промежуточного качества продукции может включать в себя следующее:

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

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

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

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

С точки зрения приобретателя процесс оценки в общем случае является частью процесса приобретения, как это определено в ИСО/МЭК 12207:2008. В таком случае цель оценки должна быть определена в следующем виде:

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

Примечание — Примеры объединенного процесса оценки и приобретения приведены на рисунках 3 и 4.

Рисунок 4 — Пример процесса оценки/приобретения или модификации заказной программной продукции

Процесс оценки может быть объединен с процессом приобретения, определенным в ИСО/МЭК 1220, краткое описание которого представлено ниже. Таким образом, результаты оценки могут способствовать достижению конечной цели — приобретению:

• инициирование — определение требований к программному продукту, который будет приобретен, план приобретения, стратегия и критерии приемки;
• подготовка запроса на предложения (тендер) — спецификация и документация требований для приобретения;
• подготовка и обновление контракта — выбор поставщика, подготовка и согласование контракта, контроль за изменениями контракта;
• мониторинг поставщика — действия по оценке, выполняемые в процессе выполнения контракта, результатом которого будут приемка и поставка продукции;
• приемка и завершение — действия, выполняемые в процессе приемки продукции и поставки конечного продукции.

Для удовлетворения требований к оценке в процессе приобретения заказчик должен определить оба процесса: процесс оценки и процесс приобретения. В случае разработки больших систем соответствующие действия по приобретению и оценке необходимо объединить с другими действиями по разработке и интеграции, как это определено в плане измерений проекта, в соответствии с ИСО/МЭК 25001, т.е. конкретные соображения по реализации приобретения включают в себя для оценки следующие аспекты:

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

Процесс оценки должен учитывать:

• все ограничения управления проектами, т.е. доступность ресурсов и опыта выполнения действий по оценке, сроки и доступность бюджета, возможные взаимозависимости или риски, ключевые допущения или предположения о трудоемкости самой оценки;
• процесс приобретения и информацию, требуемую от поставщиков в процессе тендера; другие оценки, которые выполняет вторая или третья сторона и которые можно было бы использовать для сокращения трудозатрат на оценку продукции (например, если другие приобретатели оценивают продукт, предоставленный поставщиком);
• будет ли продукт повторно использован в будущих приложениях и имеется ли документация, необходимая для поддержки любых будущих оценок продукции;

• другие предоставления оценки с точки зрения приобретения, как показано на рисунке 5.

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

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

Процесс описан в 7.2.3.

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

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

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

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

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

8.2.4 Идентифицируйте части продукции, подлежащие оценке

Процесс описан в 7.2.4.

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

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

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

Примечания

1 С точки зрения заказчика, информация о продукте включает в себя также статические артефакты, такие как:

• план оценки качества;
• отчет об оценке качества.

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

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

a) готовые коммерческие продукты;

b) существующие продукты, разработанные или приобретенные для других приложений или для широкого круга общих приложений;

c) заказные продукты или модификации существующих продуктов.

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

Аппаратные элементы конфигурации, которая будет приобретена, могут содержать программное обеспечение, такое как действующая система, размещенная во встроенном микропрограммном обеспечении (т.е. ROM, PROM). В таком случае, если применяемое программное обеспечение составляет неотъемлемую часть аппаратных средств, то оно, как правило, должно быть оценено вместе с аппаратными элементами конфигурации.

Кроме того, следует учитывать:

a) хотят ли и могут ли поставщики или приобретатели обеспечить доступ к требуемой документации, оборудованию, инструментам, программному обеспечению, курсам и/или обучению и какие затраты связаны с этим;

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

c) хотят ли и могут ли поставщики или третья сторона привлекать специалистов с соответствующим опытом для ответов на вопросы, предусмотрено ли финансирование возникающих при этом затрат, включая транспортные расходы;

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

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

8.2.5 Определите строгость оценки

Процесс описан в 7.2.5.

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

Объем работ по проведению оценки может быть сокращен за счет организации доступа к результатам действий по оценке, выполняемых третьей стороной, при условии достоверности результатов. Среди таких действий по оценке могут быть осуществленные ранее сертификации, оценки качества продукции и/или обработки оценок. Например:

• процессы программной инженерии для разработки продукции могут быть стандартизированы, чтобы соответствовать требованиям ИСО/МЭК 12207, ИСО/МЭК 90003 или других отраслевых стандартов;
• система качества поставщика, под которой разработано программное обеспечение, может быть сертифицирована третьей стороной по требованиям ИСО 9001;
• продукт может быть оценен третьей стороной на соответствие ИСО/МЭК 25040 или ИСО/МЭК 25051;
• возможности программных процессов поставщика приемлемой разработки продукции могут быть оценены третьей стороной в соответствии с ИСО/МЭК 15504;
• с функциональной точки зрения программное обеспечение может быть оценено как часть более крупной стадии разработки системы;
• продукты, возможно, были оценены ранее для другого приложения с различными требованиями к целостности;
• уровень охвата относительно требований к оценке, необходимый после анализа всех предыдущих оценок, выполненных другими;
• оценки продукции, возможно, были выполнены другой стороной в организации путем неофициальных или официальных действий по оценке.

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

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

• приобретатели пакетов программного обеспечения могут захотеть оценить пакет программного обеспечения, используя только ИСО/МЭК 25051;
• приобретатели продуктов могут использовать ИСО/МЭК 25040 и независимую оценку;
• небольшие приобретатели или одиночки могут потребовать менее формального процесса оценки с минимальной документацией оценки;
• для потребительского программного обеспечения целью процесса оценки может быть просто выбор, возможно, тестирование и приобретение одного продукта из числа других подобных продуктов. Формальный процесс приобретения в этом случае может быть сокращен до прямой покупки и не включает в себя подготовку к контракту.

Процесс приобретения также может быть адаптирован в качестве процесса оценки с использованием рекомендаций по настройке, представленных в ИСО/МЭК 12207, и на требуемом уровне целостности для конкретной определенной продукции, которая будет приобретена. Приобретение полных систем программного обеспечения с высокими требованиями к целостности будет, как правило, требовать выполнения полного комплекта действий и задач по приобретению наряду с соответствующими действиями и задачами процесса поставки, как это определено в ИСО/МЭК 12207. Как правило, по мере возрастания уровня целостности, увеличивается строгость и количество действий и задач, связанных с приобретением и процессом оценки.

8.3 Задайте оценку

8.3.1 Входы и выходы процесса

Входы и выходы этого процесса описаны в 7.3.1.

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

• список кандидатов продуктов и поставщиков;
• общее фактическое число установок (инсталляций);
• демонстрация целевой системы.

Это действие состоит из следующих задач.

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

Выбор показателей качества (модулей оценки) описан в 7.3.2.

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

• пользовательская и техническая документация продукции (включая онлайн-документацию);
• оценка качества продукции на основе курсов и обучения поставщика;
• процесс разработки программного обеспечения, включая промежуточные продукты;
• операционная история продукции от поставщика;
• операционная история продукции от клиентов;
• возможности поставщика, поддержка и система качества [см. ИСО/МЭК 25040 (Приложение B.6)];
• анализ прототипа или другие методы оценки [см. ИСО/МЭК 25040 (Приложение B.7)];
• списки недостатков продукции и соответствующая информация (как правило, размещены на веб-сайтах).

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

a) являются ли некоторые из решений противоречащими друг другу (например, «Вписываются затраты на выбранные методы в бюджет?» может быть не совместим с «Существуют методы, комплексно удовлетворяющие всем требованиям к оценке?». В этом случае оценщикам необходимо найти компромисс на основе определения приоритетов требований к оценке.

Примечание - В ИСО/МЭК 25040 (приложение C) показан пример ранжирования методов оценки для характеристики качества программного обеспечения по стоимости и эффективности;

b) обеспечивает ли оценка надлежащий охват или область применения в комбинации выбранных методов с учетом:

• того, как показать, что программное обеспечение соответствует своим спецификациям,
• перекрытия охвата методов для обеспечения дополнительной уверенности,
• того, обеспечивает ли совокупность действий в целом приемлемый уровень уверенности в том, что обеспечивается полный охват важных характеристик качества программного обеспечения,
• степени, в которой методы дополняют друг друга,
• эффективности и объективности каждого метода для различных характеристик,
• разнообразия различных подходов методов оценки (например, некое изучение, некий анализ и некое тестирование на основе отдельных методов),
• принятия ответственности за любые действия по оценке приложения, которые будут в конечном счете проводиться как часть всего жизненного цикла разработки систем,
• доверия оценкам, выполненным другими;

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

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

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

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

c) определены ли в отчете об оценке какие-либо недостатки в продукции или процессе разработки программного обеспечения, рекомендуются ли какие-либо действия по устранению этих недостатков и были ли предприняты корректирующие действия;

d) имели ли оценщики надлежащий профиль, включая:

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

8.3.3 Определите критерии решения для показателей качества

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

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

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

8.3.4 Определите критерии решения для оценки

Определение критериев принятия решения для оценки описано в 7.3.4.

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

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

8.4 Спроектируйте оценку

8.4.1 Входы и выходы процесса

Входы и выходы процесса приведены в 7.4.1.

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

• техническая характеристика изделия;
• описания продукции;
• список кандидатов продуктов и поставщиков;
• результат фактического числа установок (инсталляций);
• демонстрация целевой системы.

Это действие состоит из следующих задач.

8.4.2 Спланируйте деятельность по оценке

Планирование действий по оценке приведено в 7.4.2.

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

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

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

План оценки качества для каждой стадии разработки должен включать в себя 5W3H (Why (почему), What (что), When (когда), Who (кто), Where (где), How to (как), How much (сколько стоит) and How many (сколько)), т.е. следующее:

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

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

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

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

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

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

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

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

c) любое ограничение или недостаток метода оценки в обеспечении гарантии качества, устраняются ли эти ограничения или недостаток в других разделах плана. Например, метод оценки не в состоянии охватить все подхарактеристики для конкретной характеристики качества;

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

e) необходимые ресурсы и стоимость для оценки в целом и для каждого метода оценки;

f) точки соприкосновения действий оценки и действий приобретения (см. примеры объединенных процессов оценки и приобретения на рисунках 3 и 4);

g) моменты принятия решения в процессе оценки, которые определяют, когда и почему оценку нужно считать полной (т.е. принятие или критерии отклонения) и когда она должна быть остановлена;

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

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

8.5 Выполните оценку

8.5.1 Входы и выходы процесса

Входы и выходы этого процесса описаны в 7.5.1.

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

• техническая характеристика изделия;
• описания продукции;
• список кандидатов продуктов и поставщиков;
• результат фактического числа установок (инсталляций);
• демонстрация целевой системы.

Данное действие состоит из следующих задач.

8.5.2 Выполните измерения

Выполнение измерений описано в 7.5.2.

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

Отчет об оценке должен быть предоставлен до начала следующего этапа приобретения.

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

В процессе разработки осуществляют контроль и управление качеством. Собирают фактические значения внутренних свойств. В случае нежелательных значений причину анализируют, позволяя таким образом заказчикам понять проблемы и реагировать на них.

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

8.5.3 Примените критерии решения для показателей качества

Описано в 7.5.3.

8.5.4 Примените критерии решения для оценки

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

Примечания

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

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

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

Результаты оценки должны:

• установить соответствующую степень уверенности, что продукт в состоянии удовлетворить требованиям оценки;
• выявить любые конкретные недостатки в отношении требований оценки и какие-либо дополнительные оценки, необходимые для определения сферы влияния этих недостатков;
• определить все специальные ограничения или условия, накладываемые на использование продукции;
• определить все слабые места или недостатки в самой оценке и любой необходимой дополнительной оценке;
• определить все варианты использования продукции, раскрытые оценкой.

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

Выводы можно формализовать, используя «Декларацию о соответствии требованиям», в которой для каждого из конкретных требований определены объекты, функции или услуги продукции, используемые для удовлетворения этого требования, а также методы оценки, которые обеспечивают достаточную уверенность в том, что требование удовлетворяется. Современные стратегии проектирования, такие как диверсификация проектных решений, избыточность в конфигурации, проверка целостности интерфейса и методы восстановления, могут компенсировать недостатки или потенциальные отказы оборудования.

Вполне возможно, что оценка может привести к решению не принимать продукт для использования или к решению не пытаться соответствовать требованиям оценки, что приводит к рекомендации повторной оценки посредством альтернативного подхода. Окончательное решение сводится к ответу на вопрос: «Купить или не купить?».

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

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

8.6 Завершите оценку

8.6.1 Входы и выходы процесса

Входы и выходы этого процесса рассмотрены в 7.6.1.

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

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

Это действие состоит из следующих задач.

8.6.2 Проанализируйте результаты оценки

Анализ результатов оценки описан в 7.6.2.

8.6.3 Создайте отчет об оценке

Подготовка отчета об оценке приведена в 7.6.3.

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

8.6.4 Проанализируйте оценку качества и обеспечьте обратную связь с организацией

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

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

Упорядочивание данных оценки предоставлено в 7.6.5.

9 Требования и рекомендации для процесса оценки независимыми оценщиками

9.1 Общие требования

Процесс оценки качества продукции при независимом подходе оценщиков обеспечивает требования и рекомендации для практической реализации оценки качества продукции в случаях, когда результаты оценки должны быть поняты, приняты несколькими сторонами, которые должны также и доверять им. Данный процесс используют оценщики при выполнении независимой оценки продукции. Эта оценка может быть выполнена по требованию разработчиков, приобретателей или некоторой другой стороны. Настоящий раздел предназначен для тех, кто выполняет независимую оценку. Зачастую они работают в сторонних организациях.

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

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

Независимые оценщики должны выполнить действия по оценке качества в рамках контракта с запрашивающей стороной.

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

Примечания

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

2 В случае, когда запрашивающая сторона оценки — приобретатели, независимые оценщики должны выполнить действия по оценке на основе точки зрения стороны заказчика.

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

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

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

Таблица 2

Целевой объект	Статический продукт	Динамический продукт
Промежуточный продукт	Проектная документация Исходные коды	Исполняемый продукт в составе тестовой среды
Конечный продукт	Производственное руководство Отчет об оценке	Исполняемый продукт в составе операционной среды

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

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

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

В обязанности независимых оценщиков может входить следующее:

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

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

Запрашивающая оценку сторона должна:

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

Потенциальными запрашивающими сторонами независимой оценки, например, могут быть:

• разработчики программного обеспечения;
• специалисты по обслуживанию программного обеспечения;
• поставщики программного обеспечения;
• приобретатели программного обеспечения;
• пользователи программного обеспечения;
• системные интеграторы в роли приобретателей программного обеспечения.

Обязанности независимых оценщиков должны включать в себя следующее:

• проверять, обладает ли запрашивающая сторона достаточными юридическими правами на продукт для выполняемой оценки; для этого независимые оценщики могут потребовать аттестацию запрашивающей стороны;
• обеспечивать требуемую запрашивающей стороной конфиденциальность всей информации, включая, например, продукт для оценки, протоколы оценки и отчет об оценке;
• предоставить квалифицированному и обученному персоналу возможность проведения оценки;
• обеспечивать инструментами и технологией оценки;
• проводить оценку в соответствии с требованиями к оценке;
• вести учет любых работ, выполняемых в процессе оценки и влияющих на результаты оценки;
• обеспечивать своевременное предоставление отчета об оценке запрашивающей стороне;
• обеспечивать прозрачность проведения оценки в мере, требуемой запрашивающей стороной.

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

• независимые испытательные лаборатории;

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

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

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

9.2 Установите требования к оценке

9.2.1 Входы и выходы процесса

Входы и выходы этого процесса описаны в 7.2.1.

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

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

Это действие состоит из следующих задач.

9.2.2 Установите цели оценки

Определение цели оценки описано в 7.2.2.

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

Определение требований к качеству программной продукции приведено в 7.2.3.

9.2.4 Идентифицируйте части продукции, подлежащие оценке

Определение частей продукции, подлежащих оценке, описано в 7.2.4.

Запрашивающие стороны оценки должны предоставить описание продукции, подлежащей оценке. Цель этого описания включает аспекты, которые должны:

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

Примечания

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

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

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

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

• описание природы компонента;
• информацию о формализме, используемом в компоненте;
• информацию о размере компонента;
• отношения с другими компонентами;
• информацию о доступности для оценщиков компонента продукции.

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

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

Независимые оценщики должны проанализировать предоставленное обоснование, а также описание компонентов с целью выявления их отношений с компонентами, идентифицированными в требованиях оценки.

Примечания

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

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

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

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

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

Регистрационная информация должна, по меньшей мере, содержать:

• уникальный идентификатор компонента или документа;
• наименование компонента или название документа;
• состояние документа (включая в особых случаях аномальные или физические условия);
• версию, конфигурацию и информацию о дате, как это предоставлено запрашивающей стороной;
• дату получения.

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

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

9.2.5 Определите строгость оценки

Определение строгости оценки описано в 7.2.5.

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

9.3 Задайте оценку

9.3.1 Входы и выходы процесса

Входы и выходы этого процесса описаны в 7.3.1.

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

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

Это действие состоит из следующих задач.

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

Выбор показателей качества (модулей оценки) предоставлен в 7.3.2.

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

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

Результатом первой проверки может быть идентификация недостающей информации для компонентов, перечисленных в описании продукции. Возможны следующие способы разрешения подобной ситуации:

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

Вторая проверка предназначена для подтверждения того, что измерения и проверки, предложенные в спецификации оценки, согласуются с уровнем технического развития. Это может быть сделано одним из следующих способов:

• идентифицируя соответствующие стандарты измерения;
• предоставляя подробное обоснование со ссылками на соответствующие авторитетные источники в данной области. Такое обоснование должно быть включено в спецификацию оценки.

Спецификация оценки должна содержать:

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

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

9.3.3 Определите критерии решения для показателей качества

Определение критериев для показателей качества описано в 7.3.3.

9.3.4 Определите критерии решения для оценки

Определение критериев решения по оценке приведено в 7.3.4.

9.4 Спроектируйте оценку

9.4.1 Входы и выходы процесса

Входные действия и результаты этого процесса описаны в 7.4.1.

Это действие состоит из следующих задач.

9.4.2 Спланируйте деятельность по оценке

Планирование действий по оценке приведено в 7.4.2.

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

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

Должны быть определены требования для встреч в ходе оценки. Если запрашивающая сторона не является разработчиком продукции, то должны быть определены отношения между независимыми оценщиками и разработчиками. В частности, должна быть определена поддержка, требуемая от разработчика. Такая поддержка может включать в себя, например, обучение, неформальные обсуждения или использование служебных помещений.

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

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

В отдельных случаях вместо документации метода оценки в плане оценки может быть ссылка на личные материалы независимого оценщика. В этом случае независимые оценщики должны обосновать уместность применения метода к соответствующему элементу спецификации оценки и свою собственную компетентность в применении этого метода.

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

9.5 Выполните оценку

9.5.1 Входы и выходы процесса

Входы и выходы этого процесса описаны в 7.5.1.

Это действие состоит из следующих задач.

9.5.2 Выполните измерения

Выполнение измерений рассмотрено в 7.5.2.

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

9.5.3 Примените критерии решения для показателей качества

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

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

9.5.4 Примените критерии решения для оценки

Применение критериев решения по оценке описано в 7.5.4.

9.6 Завершите оценку

9.6.1 Входы и выходы процесса

Входы и выходы этого процесса рассмотрены в 7.6.1.

Это действие состоит из следующих задач.

9.6.2 Проанализируйте результаты оценки

Анализ результатов оценки описан в 7.6.2.

Все результаты оценки качества продукции должны быть проанализированы. Цель анализа зависит от характера действий по рассматриваемой оценке. В анализе должен принимать участие по меньшей мере один человек, не имеющий непосредственного отношения к действиям по оценке. Отчет об анализе должен быть включен в протокол оценки.

9.6.3 Создайте отчет об оценке

Подготовка отчета об оценке рассмотрена в 7.6.3.

9.6.4 Проанализируйте оценку качества и обеспечьте обратную связь с организацией

Анализ оценки качества и обеспечение обратной связи с организацией описан в 7.6.4.

Черновой вариант отчета об оценке должен быть предоставлен запрашивающей стороне.

Необходимо организовать совместное рассмотрение чернового варианта отчета об оценке запрашивающей стороной и независимыми оценщиками.

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

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

Упорядочивание данных оценки описано в 7.6.5.

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

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

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ИСО/МЭК 25000	-	<*>
ИСО/МЭК 25001	-	<*>
ИСО/МЭК 25030	-	<*>
ИСО/МЭК 25040	IDT	ГОСТ Р ИСО/МЭК 25040-2014 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки»
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: - IDT — идентичный стандарт.

БИБЛИОГРАФИЯ

1. ИСО/МЭК 12207:2008, Systems and software engineering — Software life cycle processes (Системная и программная инженерия. Процессы жизненного цикла программного обеспечения)

2. ИСО/МЭК 15288:2008, Systems and software engineering — Systems life cycle processes (Системная и программная инженерия. Процессы жизненного цикла систем)

3. ИСО/МЭК 25010, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models (Системная и программная инженерия. Требования и оценка систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения)

4. ИСО/МЭК 25020, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Measurement reference model and guide (Программная инженерия. Требования и оценка качества программной продукции (SQuaRE). Эталонная модель измерений и рекомендации)

5. ИСО/МЭК 25051, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing (Программная инженерия. Требования и оценка качества программной продукции (SQuaRE). Требования к качеству готовой коммерческой программной продукции (COTS) и инструкции по тестированию

УДК 004.05:006.354

ОКС 35.080

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

------------------------------------------------------------------