ВИДЫ ИСПЫТАНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Критерии отнесения ПО к эталонному условны и при проведении аттестации ПО СИ являются предметом соглашения между заказчиками аттестации и ее исполнителями. В качестве эталонного может быть использовано аттестованное ПО.

К основным источниками погрешностей ПО относятся:

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

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

- применение неустойчивых алгоритмов при решении плохо обусловленных* измерительных задач;

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

- ошибки округления и др.

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

- анализ ПО и его алгоритмов, выбор контролируемых параметров, характеристик и свойств;

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

- определение критериев оценки погрешности, характеристик и параметров ПО;

- выбор (или разработка) эталонного ПО;

- выбор (определение) исходных данных и/или их получение методом генерации или какими-либо другими методами;

- получение результатов u1086 обработки исходных данных в испытываемом (тестируемом) ПО (получение тестовых результатов);

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

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

Основными методами, применяемыми при оценке погрешности ПО, являются:

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

- сравнительные испытания с применением эталонного (аттестованного) ПО;

- в отсутствие эталонного (аттестованного) ПО сравнительные испытания с использованием моделей исходных данных или с

применением метода генерации эталонных данных;

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

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

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

При высокой жесткости испытания проводятся на основе исходного кода ПО.

Сравнительные испытания с применением эталонного (аттестованного) ПО.

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

ПО при оценке погрешности ПО может быть применено:

- аттестованное ПО СИ аналогичного функционального u1085 назначения;

- специально разработанное ПО с функциями, идентичными тестируемому;

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

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

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

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

Сравнительные испытания с использованием моделей исходных данных.

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

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

Генерация эталонных наборов данных

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

тельного процесса.

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

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

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

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

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

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

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

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

Испытания на основе исходного кода ПО

При испытаниях на основе исходного кода ПО проверяется:

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

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

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

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

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

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

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

Обработка результатов испытаний (тестирования) ПО.

На основе полученных результатов испытаний (тестирования) рассчитывают характеристики точности тестируемых алгоритмов: относительную погрешность алгоритма и его исполнительную характеристику.

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

Относительная погрешность алгоритма. Вычисление относительной погрешности алгоритма производится по формуле:

Исполнительная характеристика алгоритма .

Исполнительная характеристика алгоритма вычисляется по формуле:

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

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

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

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

Большинство процессов разработки программного обеспече­ния — это процессы решения некоторых задач. Внешнее проек­тирование сводится к решению такой задачи: «Переведите мно­жество целей системы во внешние спецификации», где цели — данные, а внешние спецификации — неизвестные. В задаче про­ектирования логики модуля даны внешние спецификации моду­ля, а неизвестное — текст его программы. Отладка — это задача на построение исправления ошибки (неизвестное) по описанию

ее симптомов (данные).

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

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

Стандартизация осуществляется на разных уровнях. Уровень стандартизации зависит от того, участники какого географичес­кого, экономического, политического региона мира принимают стандарт. Если участие в стандартизации открыто для соответ­ствующих органов любой страны, то это международная стан­дартизация. Региональная стандартизация — деятельность, от­крытая только для соответствующих органов государств одного географического, политического или экономического региона. Региональная и международная стандартизация осуществляется специалистами стран, представленных в соответствующих реги­ональных и международных организациях (рис. 1.1).

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

ПРИНЦИПЫ РАЗРАБОТКИ ПО.

Процесс приобретения(acquisition process) состоит из действий и задач заказчика, приобретающего программное средство (рис. 2.2). Инициирование приобретениявключает следующие задачи:

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

• анализ требований к системе;

• принятие решения относительно приобретения, разработки или усовершенствования существующего ПС;

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

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

Заявочные предложениядолжны содержать:

• требования к системе;

• перечень программных продуктов;

• условия и соглашения;

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

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

Подготовкаи корректировка договоравключают следующие задачи:

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

• выбор конкретного поставщика на основе анализа предложений;

• подготовку и заключение договора с поставщиком;

• внесение изменений (при необходимости) в договор в процессе
его выполнения.

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

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

Процесс поставки (supply process) охватывает действия и за­дачи, выполняемые поставщиком, который снабжает заказчика программным продуктом или услугой (рис. 2.3).

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

Планирование включает следующие задачи:

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

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

Процесс разработки (development process) предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПС и его компонентов в соответствии с за данными требованиями, включая оформление проектной и экс­плуатационной документации; подготовку материалов, необхо­димых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т. д. (рис. 2.4).

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

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

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

Анализ требований к ПС предполагает определение следую­щих характеристик для каждого компонента ПС:

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

• внешних интерфейсов;

• спецификаций надежности и безопасности;

• эргономических требований;

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

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

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

• требований к эксплуатации и сопровождению.

Требования к ПС оцениваются исходя из критериев соответ­ствия требованиям к системе, реализуемости и возможности про­верки при тестировании.

Проектирование архитектуры ПС включает следующие зада­чи (для каждого компонента ПС):

• трансформацию требований к ПС в архитектуру, определяю­щую на высоком уровне структуру ПС и состав его компо­нентов;

• разработку и документирование программных интерфейсов ПС и баз данных;

• разработку предварительной версии пользовательской докумен­тации;

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

Архитектура компонентов ПС должна соответствовать тре­бованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.

Детальное проектирование ПС включает следующие задачи:

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

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

• обновление (при необходимости) пользовательской докумен­тации;

• разработку и документирование требований к тестам и плана
тестирования компонентов ПС;

• обновление плана интеграции ПС.

Кодирование и тестирование ПС охватывают следующие за­дачи:

• разработку (кодирование) и документирование каждого ком­
понента ПС и базы данных, а также совокупности тестовых
процедур и данных для их тестирования;

• тестирование каждого компонента ПС и базы данных на соот­
ветствие предъявляемым к ним требованиям. Результаты тес­
тирования компонентов должны быть документированы;

• обновление (при необходимости) пользовательской докумен­
тации;

• обновление плана интеграции ПС.

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

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

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

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

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

Процесс эксплуатации (operation process) охватывает действия и задачи оператора — организации, эксплуатирующей систему (рис. 2.5).

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

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

• определение процедур локализации и разрешения проблем, воз­никающих в процессе эксплуатации.

Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она пе­редается в эксплуатацию.

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

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

Процесс сопровождения (maintenance process) предусматрива­ет действия и задачи, выполняемые сопровождающей организа­цией (службой сопровождения). Данный процесс активизируется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблема­ми или потребностями в модернизации либо адаптации ПС. В соответствии со стандартом IEEE-90 под сопровождением пони­мается внесение изменений в ПС в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.

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

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

• планирование действий и работ, выполняемых в процессе со­
провождения;

• определение процедур локализации и разрешения проблем, воз­никающих в процессе сопровождения.

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

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

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

• утверждение выбранного варианта модификации.

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

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

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

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

Стандартизация ПО.

В процессе стандартизации вырабатываются нормы, прави­ла, требования, характеристики, касающиеся объекта стандар­тизации, которые оформляются в виде нормативного документа. Рассмотрим разновидности нормативных документов, кото­рые рекомендуются руководством 2-й Международной органи­зации по стандартизации и Международной электротехнической комиссии (ИСО/МЭК), а также принятые в государственной системе стандартизации Российской Федерации (РФ). Руководство ИСО/МЭК рекомендует: стандарты, документы технических ус­ловий, своды правил, регламенты (технические регламенты), по­ложения (рис. 1.2).

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

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

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

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

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

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

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

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

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

Кроме стандартов нормативными документами являются так­же ПР — правила по стандартизации, Р — рекомендации по стан­дартизации и ТУ — технические условия. Особое требование предъявляется к нормативным документам на продукцию, кото­рая согласно российскому законодательству подлежит обязатель­ной сертификации. В них должны быть указаны те требования к продукции (услуге), которые подтверждаются посредством серти­фикации, а также методы контроля (испытаний), которые следует применять для установления соответствия, правила маркировки такой продукции и виды сопроводительной документации.

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

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

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

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

• правила, касающиеся организации работ по отраслевой стан­
дартизации;

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

• правила метрологического обеспечения в отрасли.

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

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

Закон РФ «О стандартизации» рекомендует использовать стан­дартизацию на предприятии для освоения данным конкретным пред­приятием государственных, международных, региональных стандар­тов, а также для регламентирования требований к сырью, полуфаб­рикатам и т.п., закупаемым у других организаций. Эта категория стандартов обязательна для предприятия, принявшего этот стан­дарт. Но если в договоре на разработку, производство, поставку продукта или предоставление услуг имеется ссылка на стандарт пред­приятия, он становится обязательным для всех субъектов хозяйствен­ной деятельности — участников такого договора.

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

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