ГОСТ Р ИСО/МЭК 25040—2014
Приложение В
(справочное)
Методы оценки
В настоящем приложении приведены примеры методов оценки, которые допускается использовать для
оценки качества программного продукта.
В.1 Анализ пользовательской и технической документации по продукту (включая и онлайн-докумен
тацию)
Документация по продукту может предоставить всю необходимую информацию чтобы сделать оценку тре
бований функциональности и удобства пользования, а также других аспектов, таких как мобильность и пригод
ность к обслуживанию. В некоторых случаях есть возможность получить доступ к необходимой документации
программного продукта, не прибегая к фактической его покупке, а взяв документацию взаймы или купив только
комплект документации. Несмотря на то. что анализ документации программного продукта может оказаться не
столь же эффективным, как обучение на курсах или прохождение тренинга, анализ может оказаться самым
экономичным способом, если оценщик обладает соответствующими знаниями и опытом.
В.2 Оценка на основе курсов и обучения от поставщика
Для многих программных продуктов или через поставщика, или через третью сторону предлагаются курсы
по продукту. Если для программного продукта нет никаких курсов, то в отдельных случаях возможно организовать
специальное обучение силами опытных пользователей или разработчиков программного продукта. Преимуще
ством курсов или тренинга по продукту является то. что они позволяют оценщику сосредоточиться на конкретных
аспектах и получить конкретную информацию по функциональности и удобству использования программного
продукта за короткий период времени. Вероятно, что ту же информацию возможно получить и посредством
анализа документации программного продукта, но такой вариант может оказаться бопее трудоемким. Дополни
тельные расходы на курсы или обучение должны быть сопоставлены с эффективностью получения информации
и общности учебного материала.
В.З Оценка процесса программной инженерии
Оценка процессов программной инженерии является средством определения качества программного про
дукта путем изучения промежуточных продуктов процессов, таких как план качества продукта, спецификации
требований, описания архитектуры, описания детального проектирования, листинги кода, протоколы верифика ции
и подтверждения правильности, протоколы проверки кода и тестирования, и т. д. Для достижения этой цели
необходимо определить состав приемлемого базового уровня документации для разработки программного обес
печения, который обеспечит достаточную гарантию качества конченой программной продукции.
Чтобы специфицировать необходимые действия разработки и связанной с ним поддержки, приемлемый
базовый уровень должен быть определен путем адаптации требований ИСО/МЭК 12207 для соответствия целе
вому уровню целостности. Для этого определяются:
a) требуемые процессы:
b
) требуемую выходную документацию процессов;
c) требования к процессам и выходной документации процессов.
Такая оценка может быть увязана с определением уровня возможностей процессов поставщика, как опре
делено в ИСО/МЭК 15504-2. Для определения процессов и ожидаемых результатов, которые следует применять
всоответствии с требованиями уровня целостности программного продукта, можно использовать ИСО/МЭК 12207.
П р и м е ч а н и е — Большинство процессов программной инженерии описано в ИСО/МЭК 12207. Процес
сы жизненного цикла программного обеспечения.
Для систем с высокими требованиями целостности должны быть дополнительные требования к процессам
и продуктам из отраслевых стандартов, например, МЭК 880, МЭК 1508. DOA-167A. MOD 55. и т. д.
Далее план «качество/разработка» поставщика и связанные методологические процедуры можно исполь
зовать для оценки соответствия поставщика данному целевому базовому уровню. В этом случавуровеньсоответ
ствия может быть определен путем выявления основных недостатков и оценки их потенциального влияния на
качество программного продукта. Влияние недостатков может быть определено с помощью дополнительной
оценки или обходных решений.
Следует признать, что существует множество процессов программной инженерии, которые эффективны
для конкретных организаций и различных типов программных продуктов. Процесс оценки должен обладать гиб
костью. позволяющей согласованно использовать различные практичные процессы и методы программной ин
женерии.
Анализ программной инженерии рекомендуется проводить поэтапно. Если обнаруживается, что уровень
целостности программного обеспечения не требует полной оценки процесса программной инженерии, то ана лиз
может быть завершен после 1-го или 2-го этапа.
21