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

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

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

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25040:2011 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки» (ISO/IEC 25040:2011 «Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation process»).

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

В приложении B приведены примеры методов оценки.

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

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

В приложении E в качестве примера приведен шаблон отчета об оценке.

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

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

стандартов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИСО/МЭК 25010 Системная и программная инженерия. Требования и оценка качества программного обеспечения (SQuaRE). Модель качества систем и программного обеспечения [ISO/IEC 25010, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Systems and software quality model].

ИСО/МЭК 25020 Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Эталонная модель измерения и рекомендации [ISO/IEC 25020, Software engineering — Software product quality Requirements and Evaluation (SQuaRE) — Measurement reference model and guide].

ИСО/МЭК ТО 25021:2007 Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Элементы показателей качества [ISO/IEC TR 25021:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality measure elements].

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

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

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

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

4.1 приобретающая сторона (acquirer): Правообладатель, который приобретает или получает продукт или услугу от поставщика.

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

4.2 модель для анализа (analysis model): Алгоритм или вычисление, связывающие один или более базовых и/или производных показателей с соответствующим критерием решения.

4.3 атрибут (attribute): Неотъемлемое свойство или характеристика объекта или сущности, которая может быть различима количественно или качественно человеком или автоматическими средствами.

Примечания

1 Адаптирован из ИСО/МЭК 15939.

2 В ИСО 9000 определено два различных типа атрибутов: присущая характеристика, существующая по сути сама по себе и присвоенная характеристика продукции, процесса или системы (например, цена продукции, владелец продукции). Назначенная характеристика не является неотъемлемой характеристикой качества продукции, процесса или системы.

4.4 атрибут для показателя качества (attribute for quality measure): Атрибут, который относится к самой программной продукции, ее использованию или к процессу ее разработки.

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

4.5 базовый показатель (base measure): Показатель, определенный с точки зрения атрибута и метода его количественного определения.

Примечания

1 Базовый показатель функционально независим от других показателей.

2 Адаптировано из Международного словаря основных и общих терминов метрологии, 1993.

4.6 готовая к использованию программная продукция (commercial-off-the-shelf software product): Программная продукция, определяемая потребностью рынка, коммерчески готовая, пригодность использования которой доказано широким спектром коммерческих пользователей.

4.7 условия использования (контекст использования) (context of use:) Пользователи, задачи, оборудование (аппаратные средства, программное обеспечение и материалы), физическая и социальная среда, в которых(ые) используют продукцию. (ИСО 9241-11).

4.8 программное обеспечение по заказу (custom software): Программная продукция, разработанная для задаваемого применения по спецификации требований пользователя.

4.9 данные (data): Набор значений, присвоенный базовым показателям, производным показателям и/или индикаторам (ИСО/МЭК 15939).

4.10 критерии решения (decision criteria): Пороговые значения, цели или образцы, используемые для определения потребности в действии или дальнейшем исследовании, или же для описания степени доверия данному результату (ИСО/МЭК 15939).

4.11 производный показатель (derived measure): Показатель, который определена как функция двух или более значений базовых показателей (ИСО/МЭК 15939).

Примечания

1 Адаптировано из Международного словаря основных и общих терминов метрологии, 1993.

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

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

Примечание - Взято из определения в ИСО/МЭК 12207.

4.13 раздел стандартов (division of standards): Раздел, в который входит семейство стандартов, служащих определенным целям.

4.14 конечный пользователь (end user): Индивидуум, который в конечном счете получает выгоду от результатов работы системы.

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

4.15 объект, сущность (entity): Нечто, реально существующее, что необходимо характеризовать, измеряя его атрибуты.

Пример - Этим может быть процесс, продукт, проект или ресурс. (ИСО/МЭК 15939:2007).

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

4.17 покрытие оценки (evaluation coverage): Степень, с которой оценка покрывает заданные требования к качеству программной продукции.

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

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

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

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

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

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

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

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

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

4.25 оценщик (evaluator): Человек или организация, которые выполняют оценку.

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

Примечание - Взято из IEEE 610.12.

4.27 дефект, неисправность (fault): Некорректный шаг, процесс или определение данных в компьютерной программе. (IEEE 610.12).

4.28 функциональное требование (functional requirement): Требование, которое определяет функцию, которую система или системный компонент должны быть способны выполнять (IEEE 610.12).

Примечание - Характеристика качества программного обеспечения «функциональность» можно использовать, чтобы задать или оценить пригодность, точность, интероперабельность, безопасность и нормосоответствие функции.

4.29 подразумеваемые потребности (implied needs): Потребности, которые могли быть не сформулированы, однако являются фактическими потребностями.

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

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

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

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

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

Примечание - В ИСО/МЭК 14598-1 это было определено как «показатель, который можно использовать для прогноза или оценки другого показателя».

4.32 информационная потребность (information need): Понимание, необходимое для управления целями, задачами, рисками и проблемами (ИСО/МЭК 15939).

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

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

4.34 потребности информационной системы (information system needs): Потребности, которые могут быть определены как требования к показателям внешнего, а иногда и внутреннего качества.

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

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

4.36 потребности промежуточного программного продукта (intermediate software product needs): Потребности, которые могут быть определены как требования к показателям внутреннего качества.

4.37 сопровождающая сторона (maintainer): Человек или организация, которые осуществляет деятельность по сопровождению.

Примечание - Адаптировано из ИСО/МЭК 12207.

4.38 показатель, существительное (measure, noun): Переменная, значению которой присвоено значение результата измерения.

Примечания

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

2 Адаптировано из ИСО/МЭК 14598-1.

4.39 измерять, глагол (measure, verb): Проводить измерение (ИСО/МЭК 14598-1).

4.40 измерение (measurement): Набор операций, целью которых является определение значения показателя (ИСО/МЭК 15939).

Примечания

1 Адаптировано из Международного словаря основных и общих терминов метрологии, 1993.

2 Измерения могут представлять собой присвоение качественной категории, такой как язык исходной программы (ADA, C, КОБОЛ, и т.д.).

4.41 измерительная функция (measurement function): Алгоритм или вычисление, выполняемое для объединения двух или более базовых показателей (ИСО/МЭК 15939).

4.42 метод измерения (measurement method): Логическая последовательность операций, описанных для общего случая, используемая при количественном определении атрибута с учетом заданной шкалы ИСО/МЭК 15939).

Примечание - Адаптировано из Международного словаря основных и общих терминов метрологии, 1993.

4.43 процедура измерения (measurement procedure): Набор операций, описанных для конкретного случая, используемых при выполнении определенного измерения в соответствии с данным методом (ИСО/МЭК 15939).

Примечание - Адаптировано из Международного словаря основных и общих терминов метрологии, 1993.

4.44 процесс измерения (measurement process): Процесс установления, планирования, выполнения и оценочного измерения программного обеспечения в рамках общего проекта или организационной структуры измерения.

Примечание - Адаптировано из ИСО/МЭК 15939.

4.45 наблюдение (observation): Случай применения процедуры измерения для получения значения базового показателя (ИСО/МЭК 15939).

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

Примечание - Адаптировано из ИСО/МЭК 12207.

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

Примечание - Адаптировано из ИСО 9000.

4.48 качество при использовании, потребительское качество (показатель) (quality in use (measure): Степень, с которой продукция, используемая конкретными пользователями, соответствует потребностям пользователей для достижения определенной эффективности, производительности, безопасности удовлетворенности в заданных условиях использования.

4.49 элемент показателя качества (ЭПК) (quality measure element): Показатель, который является либо базовым, либо производным и который используют для построения показателей качества программного обеспечения.

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

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

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

4.52 уровень рейтинга (rating level): Точка на порядковой шкале, которую используют для категорирования шкалы измерений.

Примечания

1 Уровень рейтинга позволяет классифицировать (нормировать) программный продукт в соответствии с установленными или подразумеваемыми потребностями.

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

4.53 требования (requirements): Выражение осознанной необходимости того, что кое-что должно быть достигнуто или реализовано.

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

4.54 шкала (scale): Упорядоченный набор непрерывных или дискретных значений или ряд категорий, на которые отображен атрибут (ИСО/МЭК 15939).

Примечание - Адаптировано из Международного словаря основных и общих терминов метрологии, 1993.

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

4.55 программный продукт (software product): Совокупность компьютерных программ, процедур и, возможно, связанных с ними документации и данных (ИСО/МЭК 12207).

Примечания

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

2 В стандартах SQuaRE понятия «качество программного обеспечения» и «качество программной продукции» идентичны.

4.56 оценка программной продукции (software product evaluation): Техническая работа, которая заключается в получении оценки одной или более характеристик программной продукции согласно указанной процедуре.

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

Примечания

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

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

4.58 характеристика качества программного обеспечения (software quality characteristic): Категория атрибутов качества программного обеспечения, которая опирается на качество программного обеспечения.

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

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

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

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

4.61 показатель качества программного обеспечения (software quality measure): Показатель внутреннего качества, показатель внешнего качества программного обеспечения или показатель качества программного обеспечения при использовании.

Примечание - Показатель внутреннего качества, показатель внешнего качества программного обеспечения или показатель качества программного обеспечения при использовании определены в модели качества в ИСО/МЭК 25010.

4.62 правообладатель, заинтересованное лицо (stakeholder): Сторона, имеющая право, долю или требование в системе или в обладании ее характеристиками, удовлетворяющими их потребности и ожидания.

Примечания

1 Адаптировано из ИСО/МЭК 15288.

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

4.63 поставщик (supplier): Организация или лицо, которые вступают в соглашение с приобретающей стороной на поставку продукта или услуги.

Примечание - Адаптировано из ИСО/МЭК 12207.

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

Примечания

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

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

4.65 цель процесса (target of process): Программная продукция или задача, выполняемая программной продукцией, к которой применяется процесс измерения или оценивания.

4.66 единица измерения (unit of measurement): Некое условно определенное количество, принятое по соглашению, с помощью которого сравниваются количественные величины того же вида (ИСО/МЭК 15939).

Примечание - Адаптировано из Международного словаря основных и общих терминов метрологии, 1993.

4.67 пользователь (user): Лицо или группа лиц, извлекающих пользу из системы в процессе ее применения.

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

4.68 валидация (validation): Подтверждение посредством представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены.

Примечания

1 Термин «валидирован», используют для обозначения соответствующего статуса (ИСО 9000)

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

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

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

4.69 значение (value): Число или категория, присвоенные атрибуту объекта (сущности) на основе проведения измерения.

4.70 верификация (verification): Подтверждение посредством представления объективных свидетельств того, что установленные требования были выполнены.

Примечания

1 Термин «верифицирован» используется для обозначения соответствующего статуса (ИСО 9000:2005).

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

5 Эталонные модели оценки качества программного продукта

5.1 Эталонная модель — общие положения

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

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

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

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

b) ресурсы;

c) расписание;

e) среду;

g) создание отчетов.

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

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

b) применимые документы SQuaRE (ИСО/МЭК 25001, ИСО/МЭК 25010, ИСО/МЭК 2502n, ИСО/МЭК 25030, ИСО/МЭК 25041, ИСО/МЭК 25042);

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

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

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

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

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

Эталонная модель оценки качества программного продукта подразумевает, что оценка должна основываться на спецификации требований к качеству программного продукта с использованием перед оценкой стандарта ИСО/МЭК 25030 и разъяснением целей и критериев оценки. Стандарт ИСО/МЭК 25030 обеспечивает требования и рекомендации для спецификации требований к качеству программного продукта. При этом применимы и другие стандарты SQuaRE, такие как ИСО/МЭК 25010 и ИСО/МЭК 2502n.

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

5.2 Эталонная модель — процессы оценки

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

Разработка требований к оценке: 1 сформулировать цель оценки; 2 получить требования к качеству программного обеспечения; 3 идентифицировать части продукта, подлежащие оценке; 4 определить строгость оценки.
Спецификация оценки: 1 выбрать показатели качества (модули оценки); 2 определить критерий принятия решения для показателей качества; 3 определить критерий принятия решения для оценки.
Разработка проекта оценки: 1 разработать план действий по оценке.
Выполнение оценки: 1 провести измерения; 2 применить критерий для показателей качества; 3 применить критерий для оценки.
Заключение об оценке: 1 проанализировать результаты оценки; 2 создать отчет об оценке; 3 проанализировать оценку и информировать организацию; 4 распространить результаты оценки.

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

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

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

5.3 Роли

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

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

5.4 Качество в жизненном цикле

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

5.5 Поддержка оценки

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

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

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

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

6 Процесс оценки качества программного продукта

Цель — провести оценку качества программного продукта.

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

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

Примечания

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

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

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

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

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

6.2 Документация

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

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

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

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

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

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

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

Примечание — В приложении E представлен шаблон отчета об оценке. Можно использовать другой формат отчета об оценке из другого стандарта, такой как общий промышленный формат (например, ИСО/МЭК 25062), или же формат, который может быть создан оценщиками.

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

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

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

Входной информацией для этого действия должно быть следующее:

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

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

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

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

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

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

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

Это действие состоит из задач, перечисленных ниже.

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

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

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

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

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

• обеспечить качество продукта;

- принять решение о приемке промежуточного программного продукта от субподрядчика;

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

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

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

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

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

Примечания

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

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

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

3 ИСО/МЭК 25010 определяет модель качества с точки зрения характеристик и подхарактеристик качества.

4 ИСО/МЭК 25030 определяет требования и рекомендации для спецификации требований к качеству программного продукта.

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

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

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

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

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

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

6.3.4 Определить жесткость оценки

Необходимо определить жесткость оценки.

Примечания

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

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

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

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

• Функциональное тестирование или тестирование методом «черного ящика»;
• Контроль документации на основании контрольных списков;

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

6.4 Определить оценку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

6 В технических отчетах ИСО/МЭК 25022, ИСО/МЭК 25023 и ИСО/МЭК 25024 приведены примеры показателей (мер), которые могут использоваться, как они определены, или могут быть адаптированы к конкретным потребностям.

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

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

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

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

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

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

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

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

Примечания

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

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

3 В ИСО/МЭК 25020 показана взаимосвязь между характеристиками качества, подхарактеристиками качества и показателями качества в эталонной модели измерения качества программного продукта.

6.5 Разработать оценку

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

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

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

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

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

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

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

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

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

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

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

6.5.1 Плановые мероприятия оценки

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.6.1 Провести измерения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.7.1 Анализ результатов оценки

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

6.7.2 Создать отчет об оценке

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

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

b) требования к качеству программного продукта;

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

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

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

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

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

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

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

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

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

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

a) для каждого недостатка — полный соответствующий анализ и как недостаток был разрешен. Устранение недостатков может включать в себя следующее:

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

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

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

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

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

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

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

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

Примечание - Обширная операционная история может восполнить несовершенный процесс программной инженерии.

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

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

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

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

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

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

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

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

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

Приложение A (справочное)

УРОВНИ ОЦЕНКИ

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

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

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

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

В настоящем приложении предложены четыре уровня A, B, C и D. Уровни составляют иерархию с высшим уровнем A и низшим — D. На уровне A — самые строгие методы оценки с максимальным уровнем доверия (с учетом разумных усилий и масштаба времени). Снижаясь к уровню D, используются все менее строгие методы, а следовательно, как правило, на оценку затрачивается и меньше усилий.

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

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

A.1 Выбор уровней оценки

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

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

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

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

Уровень оценки	Последствие
Уровень D	Небольшой имущественный ущерб; никакого риска для людей
Уровень C	Имущественный ущерб; угроза поражения людей
Уровень B	Угроза для жизни человека
Уровень A	Угроза гибели многих людей

Таблица A.2

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

Уровень оценки	Последствие
Уровень D	Незначительная экономическая потеря
Уровень C	Существенная экономическая потеря (влияет на компанию)
Уровень B	Крупная экономическая потеря (компания в опасности)
Уровень A	Финансовое бедствие (компания не выживет)

Таблица A.3

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

Уровень оценки	Последствие
Уровень D	Никаких конкретных рисков не определено
Уровень C	Защита от риска ошибок
Уровень B	Защита критических данных и служб
Уровень A	Защита стратегических данных и служб

Таблица A.4

Пример уровня оценки аспектов окружающей среды

Уровень оценки	Последствие
Уровень D	Никаких экологических рисков
Уровень C	Локальное загрязнение
Уровень B	Восстанавливаемый вред для окружающей среды
Уровень A	Непоправимый вред для окружающей среды

A.2 Выбор методов оценки в зависимости от уровня оценки

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

Функциональность:

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

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

Удобство пользования:

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

Эффективность:

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

Пригодность к обслуживанию:

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

Мобильность:

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

Приложение B (справочное)

МЕТОДЫ ОЦЕНКИ

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

B.1 Анализ пользовательской и технической документации по продукту (включая и онлайн-документацию)

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

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

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

B.3 Оценка процесса программной инженерии

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

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

a) требуемые процессы;

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

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

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

Примечание - Большинство процессов программной инженерии описано в ИСО/МЭК 12207. Процессы жизненного цикла программного обеспечения.

Для систем с высокими требованиями целостности должны быть дополнительные требования к процессам и продуктам из отраслевых стандартов, например, МЭК 880, МЭК 1508, DOA-167A, MOD 55, и т.д.

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

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

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

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

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

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

B.4.2 Анализ операционной истории

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

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

b) число единиц-лет (unit-years) для программного продукта, которое вычисляют посредством следующих шагов:

1. вычисляют Год продаж (Sales Year) = (начальные продажи [общий объем продаж за первый год] + кумулятивное конечное общее число до 6 мес. от текущего момента [Предполагается задержка в 6 мес прежде чем продукт станет рабочим]) * (число лет, когда программный продукт находится на рынке)/2;

2. вычисляют единицы-годы (unit-years) работы = (год продаж * рабочий цикл [процент времени, когда программное обеспечение в работающем состоянии * процент единиц фактически в работе [это уместно, например, для прошивок, когда многие единицы аппаратных средств узла находятся в состоянии резерва]);

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

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

e) число единиц — лет (unit-years) работы для каждой версии программного обеспечения и для каждой специальной опции программного продукта;

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

g) имеются ли документальные свидетельства поддержки данных операционной истории;

h) как контролируются и отслеживаются обновления программного продукта и обновления любых связанных с ним аппаратных средств;

i) возможно ли заказать определенную версию программного продукта и последствия заказа версии, которая не является текущей;

j) процесс приема и обработки поставщиком отчетов о недостатках полученных от клиентов;

k) сообщают ли клиентам о недостатках;

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

B.5 Анализ операционной истории клиентов

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

Оценщик, проводящий анализ операционной истории клиентов, должен:

a) установить степень подобия приложения(й) с рассматриваемым приложением;

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

c) расспросить клиента о форме и качестве поддержки, предоставленной поставщиком;

d) определить суммарную продолжительность безотказной работы.

B.6 Анализ возможностей поставщика, поддержки и системы качества

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

a) финансовую стабильность, опыт и возможности;

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

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

d) условные участия третьей стороны;

e) достаточную обеспеченность ресурсами для поддержки продукта;

f) достаточную клиентскую базу для обеспечения постоянной поддержки;

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

h) соответствующие рекомендации на базе установок;

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

j) формализованное регрессионное тестирование и формальную оценку конструктивных изменений;

k) документированные и работающие процедуры устранения неполадок;

l) систему качества на месте;

m) стандарты, используемые для аппаратного и программного обеспечения;

n) планы будущих разработок, т.е., стратегию на месте по текущему положению на рынке;

o) гарантию на продукт.

B.7 Анализ прототипа и другие методы оценки

B.7.1 Анализ прототипа

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

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

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

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

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

c) использовать, где это возможно, предысторию — данные предыдущих случаев, подходящие для рассматриваемого приложения.

B.7.2 Другие методы оценки

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

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

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

c) тестирование программного продукта на базе случайного статистического использования (надежность);

d) динамический анализ кода для проверки правильности синтаксиса и семантики (надежности);

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

f) анализ спецификации требований к программному обеспечению (функциональность);

g) проверку кода (функциональность);

h) тестирование программного обеспечения методом «черного ящика» (функциональность);

i) тестирование производительности (эффективность);

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

k) моделирование отказов в интерфейсах между компонентами (надежность).

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

Приложение C (справочное)

ПРИМЕР РАНЖИРОВАНИЯ РЕНТАБЕЛЬНОСТИ МЕТОДОВ ОЦЕНКИ

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

Таблица C.1

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

Целевые исходные данные	Метод оценки	Ранг стоимости	Ранжирование эффективности <1> методов оценки для характеристик качества программного обеспечения
			Функциональность	Надежность	Удобство пользования	Эффективность	Пригодность к обслуживанию	Мобильность
Документы конечного продукта	Оценка на основе курсов и обучения от поставщика	Низкая	Высокая	Низкая	Высокая	Средняя	Низкая	Высокая
Документы промежуточного продукта	Оценка процессов программной инженерии	Высокая	Низкая	Средняя	Низкая	Средняя	Высокая	Высокая
Операционная история — поставщика	Анализ операционной истории поставщика	Средняя	Средняя	Высокая	Низкая	Низкая	Средняя	Средняя
Операционная история — клиента	Анализ операционной истории клиента	Средняя	Высокая	Средняя	Высокая	Средняя	Высокая	Высокая

---

<1> Стоимость и показанное ранжирование эффективности относительно степени проводимой.

(справочное)

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

Действия и задачи эталонной модели оценки программного продукта в ИСО/МЭК 25040	Типовые связанные процессы в ИСО/МЭК 12207	Типовые связанные процессы в ИСО/МЭК 15288
6.3 Установить требования к оценке	-	-
6.3.1 Установить цель оценки	-	-
6.3.2 Определить требования к качеству программного продукта	6.1.1 Процесс приобретения	6.1.1 Процесс приобретения
6.3.3 Определить части продукта, которые будут включены в оценку	6.2.2 Процесс поставки	6.2.2 Процесс поставки
6.3.4 Определить строгость оценки	6.2.5 Процесс менеджмента качества	6.2.5 Процесс менеджмента качества
6.4 Определить оценку	-	-
6.4.1 Выбрать показатели качества	6.4.1 Процесс определения требований правообладателей	6.4.1 Процесс определения требований правообладателей
6.4.2 Определить критерии решения для показателей качества	-	-
6.4.3 Установить критерии решения для оценки	7.1.2 Процесс анализа требований программных средств	7.1.2 Процесс анализа требований к системе
6.5 Разработать оценку	-	-
6.5.1 План мероприятий по оценке	-	-
6.6 Выполнить оценку	-	-
6.6.1 Сделать измерения	6.3.7 Процесс измерений	6.3.7 Процесс измерений
6.6.2 Применить критерии решения для показателей	6.4.5 Процесс комплексирования системы	6.4.5 Процесс комплексирования системы
6.6.3 Применить критерии решения для оценки	6.4.6 Процесс квалификационного тестирования системы	6.4.6 Процесс квалификационного тестирования системы
6.7 Завершить оценку	-	-
6.7.1 Проанализировать результаты оценки	7.1.6 Процесс комплексирования программных средств	-
6.7.2 Создать отчет об оценке	7.2.4 Процесс верификации программных средств	-
6.7.3 Проанализировать оценку качества анализа и обеспечить обратную связь с организацией	-	-
6.7.3 Разослать данные оценки -
-		Пример возможных ассоциативных действий по оценке продукта:

Установить требования для оценки:

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

Разработать спецификацию оценки:

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

Разработать проект оценки:

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

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

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

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

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

Приложение E (справочное)

ШАБЛОН ОТЧЕТА ОБ ОЦЕНКЕ

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

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

E.1 Раздел 1 — Идентификация

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

Идентификация оценщика содержит следующую информацию об оценщике:

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

Идентификация отчета об оценке содержит идентификацию отчета:

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

Идентификация запрашивающей стороны и поставщика содержит информацию о запрашивающей стороне оценки и поставщике оцененного программного продукта:

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

E.2 Раздел 2 — Требования к оценке

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

• общее описание предметной области продукта;

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

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

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

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

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

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

(справочное)

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

F.1 Определить требования к оценке

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

F.2 Определить оценку

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

программного продукта

F.3 Разработать оценку

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

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

Рисунок F.4 — Выполнение оценки в процессе оценки качества программного продукта

F.5 Завершить оценку

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

Приложение ДА

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ИСО/МЭК 25001	-	<*>
ИСО/МЭК 25010	-	<*>
ИСО/МЭК 25020	-	<*>
ИСО/МЭК ТО 25021:2007	-	<*>
ИСО/МЭК 25030	-	<*>
ИСО/МЭК 25041	IDT	ГОСТ Р ИСО/МЭК 25041-2014 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Руководство по оценке для разработчиков, приобретателей и независимых оценщиков»
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Перевод данного международного стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичный стандарт.

БИБЛИОГРАФИЯ

[1]	ISO 9000:2005, Quality management systems — Fundamentals and vocabulary (ИСО 9000:2005 Системы менеджмента качества — Основные принципы и словарь)
[2]	TR ISO/IEC 9126-2, Software engineering — Product quality — Part 2: External metrics (ТО ИСО/МЭК 9126-2 Программная инженерия — Качество продукции — Часть 2: Внешние показатели [Технический отчет])
[3]	TR ISO/IEC 9126-3, Software engineering — Product quality — Part 3: Internal metrics (ТО ИСО/МЭК 9126-3 Программная инженерия — Качество продукции — Часть 3: Внутренние показатели [Технический отчет])
[4]	TR ISO/IEC 9126-4, Software engineering — Product quality — Part 4: Quality in use metrics (ТО ИСО/МЭК 9126-4 Программная инженерия — Качество продукции — Часть 4: Показатели качества при использовании [Технический отчет])
[5]	ISO 9241-11:1998, Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability (ИСО 9241-11:1998 Эргономические требования, связанные с использованием видеотерминалов для учрежденческих работ. Часть 11. Руководство по определению и измерению используемости)
[6]	ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes (ИСО/МЭК 12207:2008 Системная и программная инженерия — Процессы жизненного цикла программного обеспечения)
[7]	ISO/IEC 13407:1999 <1>, Human-centred design processes for interactive systems (ИСО/МЭК 13407:1999 Процессы проектирования для интерактивных систем, ориентированные на человека)
[8]	ISO/IEC 14598-1:1999, Information technology — Software product evaluation — Part 1: General overview (ИСО/МЭК 14598-1:1999 Информационные технологии — Оценка программного продукта — Часть 1: Общий обзор)
[9]	ISO/IEC 14598-2:2000, Software engineering — Product evaluation — Part 2: Planning and management (ИСО/МЭК 14598-2:2000 Программная инженерия — Оценка продукта — Часть 2: Планирование и руководство)
[10]	ISO/IEC 14598-3:2000, Software engineering — Product evaluation — Part 3: Process for developers (ИСО/МЭК 14598-3:2000 Программная инженерия — Оценка продукта — Часть 3: Процесс для разработчиков)
[11]	ISO/IEC 14598-4:1999, Software engineering — Product evaluation — Part 4: Process for acquirers (ИСО/МЭК 14598-4:1999 Программная инженерия — Оценка продукта — Часть 4: Процесс для приобретателей)
[12]	ISO/IEC 14598-5:1998, Information technology — Software product evaluation — Part 5: Process for evaluators (ИСО/МЭК 14598-5:1998 Информационные технологии — Оценка программного продукта — Часть 5: Процесс для оценщиков)
[13]	ISO/IEC 14598-6:2001, Software engineering — Product evaluation — Part 6: Documentation of evaluation modules (ИСО/МЭК 14598-6:2001 Программная инженерия — Оценка продукта — Часть 6: Документация модулей оценки)
[14]	ISO/IEC 15026, Information technology — System and software integrity levels (ИСО/МЭК 15026 Информационные технологии — Уровни целостности систем и программного обеспечения)
[15]	ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes (ИСО/МЭК 15288:2008 Системная и программная инженерия — Процессы жизненного цикла систем)
[16]	ISO/IEC 15504-2, Software engineering — Process assessment — Part 2: Performing an assessment (ИСО/МЭК 15504-2 Программная инженерия — Оценка процессов — Часть 2: Выполнение оценки)
[17]	ISO/IEC 15939:2007, Systems and software engineering — Measurement process (ИСО/МЭК 15939:2007 Системная и программная инженерия — Измерительный процесс)
[18]	ISO/IEC 25000:2005, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE (ИСО/МЭК 25000:2005 Программная инженерия — Требования и оценка качества программного продукта (SQuaRE) — Руководство по SQuaRE)
[19]	ISO/IEC 25001, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Planning and management (ИСО/МЭК 25001 Программная инженерия — Требования и оценка качества программного продукта (SQuaRE) — Планирование и управление)
[20]	ISO/IEC 25010 <2>, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Systems and software quality model (ИСО/МЭК 25010 Системная и программная инженерия — Требования и оценка качества программного обеспечения (SQuaRE) — Модель качества систем и программного обеспечения)
[21]	ISO/IEC 25020, Software engineering — Software product quality Requirements and Evaluation (SQuaRE) — Measurement reference model and guide (ИСО/МЭК 25020 Программная инженерия — Требования и оценка качества программного продукта (SQuaRE) — Эталонная модель измерения и рекомендации)
[22]	ISO/IEC TR 25021:2007, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality measure elements (ИСО/МЭК ТО 25021:2007 Программная инженерия — Требования и оценка качества программного продукта (SQuaRE) — Элементы показателей качества)

---

<1> ИСО/МЭК 13407:1999 был отменен и заменен на ИСО 9241-210:2010.

<2> В разработке.

[23]	ISO/IEC 25030, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements (ИСО/МЭК 25030 Программная инженерия — Требования и оценка качества программного продукта (SQuaRE) — Требования к качеству)
[24]	ISO/IEC 25041 <1>, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation modules (ИСО/МЭК 25041 Системная и программная инженерия — Требования и оценка качества программного обеспечения (SQuaRE) — Модули оценки)
[25]	ISO/IEC 25051:2006, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing (ИСО/МЭК 25051:2006 Программная инженерия — Требования и оценка качества программного продукта (SQuaRE) — Требования для качества готового коммерческого программного продукта (COTS) и инструкции по тестированию)
[26]	ISO/IEC 25062:2006, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability test reports (ИСО/МЭК 25062:2006 Программная инженерия — Требования и оценка качества программного продукта (SQuaRE) — Общий промышленный формат (CIF) для тестирования удобства использования)
[27]	Руководство ISO Guide 99:1993, International vocabulary of basic and general terms in metrology (VIM) Международный словарь основных и общих терминов в метрологии (VIM)
[28]	IEEE 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology — Description (Глоссарий стандартной терминологии программной инженерии — Описание)

---

УДК 004.05:006.354	ОКС 35.080
Ключевые слова: оценка качества программной продукции, модели качества, требования безопасности, критические компьютерные системы, измерение качества, процесс оценки

---