ЛЕКЦИЯ 10. СИСТЕМЫ СЕРТИФИКАЦИИ

1.  Система сертификации

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

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

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

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

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

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

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

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

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

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

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

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

(ЖЦ) программного продукта.

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

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

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

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

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

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

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

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

Качество при проектировании и производстве программных продуктов можно обеспечивать двумя методами (рис. 1):

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее полно в России стандартизирована сертификация производства продукции различных видов. Она поддержана стандар- тами: Временный порядок сертификации производств с учетом тре- бований ГОСТ Р ИСО 9001:2001; ГОСТ Р 40.003: 2005 и ГОСТ Р

ИСО 19011: 2003 (см. Приложение). Их концепции акцентированы на Системе менеджмента качества производства (СМКП) (Сис- тема менеджмента для руководства и управления производством применительно к качеству продукции) и представлены в Лекции 6.

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

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

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

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

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

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

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

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

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

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

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

Результатом положительных испытаний является сертификат соответствия.

Сертификат соответствия — документ, выданный по правилам системы сертификации для подтверждения соответствия сертифицированной продукции установленным требованиям. Сертификация программных средств и систем является элементом общей системы сертификации продукции в Российской Федерации.

Система сертификации — система, располагающая собственными пра- вилами процедуры и управления для проведения сертификации.

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

Испытательная лаборатория — лаборатория (центр), который прово- дит испытания в процессе сертификации.

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

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

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

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

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

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

Национальным органом по сертификации продукции в Российской Феде- рации является Госстандарт России.

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

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

«О защите прав потребителей» устанавливает обязательную сертифика- цию по требованиям безопасности всей продукции, продаваемой на территории РФ для личных нужд потребителя;

«О поставках продукции для федеральных государственных нужд» уста- навливает обязательность требований для продукции, поставляемой по госу- дарственному контракту;

«Об информации, информатизации и защите информации», который ре- гулирует отношения, возникающие при формировании и использовании ин- формационных ресурсов и применения информационных технологий;

«О сертификации продукции и услуг» устанавливает права и обязанности участников сертификации. Этим законом установлена обязательная и добро- вольная сертификация.

Общие правовые основы сертификации продукции и услуг в Российской Федерации установлены Федеральным законом от 27.12.2002 № 184-ФЗ «О техническом регулировании».

В этом законе регламентированы следующие вопросы. Глава 1. Общие положения.

Глава 2. Технические регламенты. Глава 3. Стандартизация.

Глава 4. Подтверждение соответствия.

Глава 5. Аккредитация органов по сертификации и испытательных лабо- раторий (центров).

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

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

Глава 8. Информация о технических регламентах и документах по стан- дартизации.

Глава 9. Финансирование в области технического регулирования. Глава 10. Заключительные и переходные положения.

Настоящий Федеральный закон регулирует отношения, возникающие при: – разработке, принятии, применении и исполнении обязательных требо-

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

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

–  оценке соответствия.

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

–  создания условий для деятельности предприятий, учреждений, органи- заций и предпринимателей на едином товарном рынке РФ, а также для участия в международном экономическом, научно-техническом сотрудничестве и меж- дународной торговле;

–  содействия потребителям в компетентном выборе продукции;

–  защиты потребителя от недобросовестности изготовителя (продавца,

исполнителя);

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

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

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

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

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

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

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

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

–  содействие созданию условий для вхождения России в мировое инфор- мационное пространство.

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

Кроме того, существует другой нормативный документ — ГОСТ Р. Система сертификации. Этой системой, в частности, определяются правила соз- дания и регистрации ведомственных систем сертификации для конкретных классов продукции.

Цели и основные принципы сертификации программных продуктов:

·        стандартное определение понятий и компонентов процессов сертификации;

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

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

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

·        исходные данные для сертификации программных средств;

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

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

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

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

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

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

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

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

·        обоснование и совершенствование технологий производства программных продуктов на основе квалифицированной экспер- тизы и сертификационных испытаний технологий и продуктов.

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

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

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

·         определения соответствия или несоответствия элементов системы качества установленным требованиям производства;

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

·         обеспечения возможности предприятию улучшить свою сис- тему качества;

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

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

• цели сертификации – правовые, экономические, формальные;

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

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

• характеристики и классификацию продуктов и/или процессов сертификации и их показатели качества;

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

Сертификация программного обеспечения — это подтверждение соот- ветствия показателей надежности, мобильности, эффективности, корректности и других его характеристик, а также заявленных свойств требованиям норма- тивных документов (например, в соответствии с ГОСТ 28195-89 или ГОСТ Р ИСО/МЭК 9126-93).

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

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

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

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

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

Общие правовые основы сертификации продукции и услуг в Российской Федерации установлены Законом «О сертификации продукции и услуг», Феде- ральным законом от 27.12.2002 № 184-ФЗ «О техническом регулировании», где определены права и ответственность в области сертификации органов государ- ственного управления, а также изготовителей (продавцов, исполнителей) и дру- гих участников сертификации.

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

Система сертификации — система, располагающая собственными пра- вилами процедуры и управления для проведения сертификации.

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

Типовая структура системы сертификации, как видно из рисунка 16,

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

Рис. 16

Типовая структура системы сертификации

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

Организационная структура системы сертификации в России включает:

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

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

3)  испытательные центры (лаборатории).

Национальным органом по сертификации продукции в Российской Феде- рации является Госстандарт России, который осуществляет следующие функции:

–  организует ведение обязательной сертификации продукции по поруче- нию органов законодательной или исполнительной власти;

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

–  утверждает документы, устанавливающие порядок сертификации кон- кретных видов продукции;

–  проводит аккредитацию испытательных центров (лабораторий) совме- стно с ведомственными органами по сертификации и выдает аттестат аккреди- тации;

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

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

–  организует периодическую публикацию информации по сертификации. Основой сертификации продукции в Российской Федерации является

Система сертификации ГОСТ Р Госстандарта России.

2.  Виды сертификации

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

Различают системы обязательной и добровольной сертификации (рис. 17).

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

Рис. 17

Виды сертификации

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

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

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

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

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

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

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

В соответствии с действующими законодательными и нормативными до- кументами сертификация средств информатизации проводится в Российской Федерации в следующих основных направлениях:

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

–  обязательная сертификация средств защиты информации;

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

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

В сфере информатизации создан эффективный инструмент оценки уровня качества приобретаемых средств информатизации в виде Системы доброволь- ной сертификации средств и систем информатизации «Росинфосерт». Система сертификации «Росинфосерт» создана в 1994 г. Комитетом при Президенте Российской Федерации по политике информатизации (РОСКОМИНФОРМ) и внесена в Государственный реестр систем сертификации, действующих в Российской Федерации.

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

Сертификация программ может быть проведена для таких видов продук-

ции:

–  сетевое программное обеспечение;

–  системы управления базой данных;

–  операционные системы и средства расширения;

–  программное обеспечение для моделирования;

–  программное обеспечение для электронных сделок;

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

–  программное обеспечение для автоматизации управления объединения

и отраслями;

–  информационно-справочные системы и базы данных;

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

–  утилиты и системы программирования;

–  системы автоматизированного проектирования;

–  аукционы, лотереи, игры, развлечения и др.;

–  электронные издания;

–  приложения мультимедиа;

–  педагогическое программное обеспечение;

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

3.  Процедура сертификации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8) 

9)   

Рис. 18

Схема сертификации

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

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

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

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

–  «Техническое задание» по ГОСТ 19.201-78;

–  «Спецификация» по ГОСТ 19.202-78;

–  «Описание программы» по ГОСТ 19.402-78;

–  «Описание применения» по ГОСТ 19.502-78;

–  «Руководство пользователя» по РД 50-34.698-90;

–  «Программа и методика испытаний» по ГОСТ 19.301-79;

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

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

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

Сертификационные испытания ПС осуществляются в два этапа.

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

2.  Оценка, проводимая экспертами.

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

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

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

3.  Экспертиза программной документации на соответствие требованиям Государственных стандартов ГОСТ Р ИСО/МЭК 12119-2000 (п. 3.2), ГОСТ Р ИСО 9127-94 (п. 5, 6.1, 6.3–6.5).

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

–  изменения организации или технологии разработки и производства;

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

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

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

–  выявления причин несоответствия и их устранения;

–  представления в орган по сертификации отчета о проделанной работе по улучшению и обеспечения качества продукции;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В процессе производства программных продуктов потенциаль- ными угрозами качеству являются [3, 4, 11]:

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

·         недостаточно эффективные средства защиты информацион- ных и программных ресурсов;

·         несоответствие реальных и декларируемых функциональных характеристик разрабатываемых компонентов и комплексов про- грамм;

·         несоответствие требованиям стандартов, влекущее за собой невозможность взаимодействия, совершенствования и развития сис- тем;

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

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

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

·         ухудшения реальных вероятностно-временных характеристик функционирования систем и средств;

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

·         несанкционированный доступ пользователей к системе, ее информационным и программным ресурсам;

·         проникновения и активизации компьютерной вирусной ин- фекции;

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

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

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

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

·         отказ от адекватного выполнения функции согласно штатно- му режиму функционирования комплексом программ;

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

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

·         недопустимое ухудшение вероятностно-временных характе- ристик функционирования ПС;

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

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

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

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

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

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

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

продуктов. Широкому их применению сопутствует проблема обеспе- чения защиты на уровне, гарантирующем национальную безопас- ность России [3, 11]. В результате техническая проблема защиты систем, комплексов программ и данных вырастает до уровня нацио- нальных, государственных проблем, для решения которых необходи- мы законодательные, организационные, технологические и стандар- тизационные мероприятия при сертификации.

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

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

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

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

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ

1. Что такое сертификация (в общем смысле)?

2. Дайте определение сертификации программы или программного комплекса.

3. Что такое сертификат соответствия?

4. Что представляет собой система сертификации?

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

6. Какой орган в Российской Федерации является национальным по сертификации продукции?

7. Назовите три основных элемента организационной структуры системы сертификации в России.

8. Каковы основные функции национального органа по сертификации (Госстандарта России)?

9. Что такое аккредитация применительно к испытательной лаборатории или органу по сертификации?

10. Какую роль выполняет испытательная лаборатория (центр) в процессе сертификации?

11. Какой федеральный закон устанавливает общие правовые основы сертификации в РФ и регулирует отношения в области технического регулирования?

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

13. Какой закон регулирует отношения при формировании и использовании информационных ресурсов?

14. На что указывает знак соответствия в области сертификации?

15. Каковы основные цели проведения сертификации согласно Федеральному закону «О техническом регулировании»?

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

17. Какие два основных вида сертификации существуют?

18. В чем заключается ключевое отличие обязательной сертификации от добровольной?

19. Приведите пример направления, в котором проводится обязательная сертификация средств информатизации.

20. В какой системе (обязательной или добровольной) проводится сертификация программного обеспечения в соответствии с действующим законодательством РФ?

21. Как называется одна из известных систем добровольной сертификации средств и систем информатизации в России?

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

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

24. Какие два основных этапа включают в себя сертификационные испытания программного средства?

25. Что такое инспекционный контроль и в какой форме он проводится?

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

27. Что происходит с сертификатом соответствия в случае, если в процессе инспекционного контроля выявляется несоответствие продукции установленным требованиям?

28. Какой документ оформляется по результатам инспекционного контроля?

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

30. Каков минимальный установленный срок хранения протоколов испытаний?

ЗАДАНИЯ К ЛЕКЦИИ:

Задание 1.

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

Задание 2.

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

Задание 3.

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

Задание 4.

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

Задание 5.

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

Задание 6.

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

Задание 7.

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

Задание 8.

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

Задание 9.

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

Задание 10.

На основании каких двух основных законодательных актов Российской Федерации выстраивается вся работа по подтверждению соответствия продукции и услуг?

Задание 11.

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

Задание 12.

Какая федеральная служба в России наделена полномочиями высшего органа по подтверждению соответствия продукции?

Задание 13.

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

Задание 14.

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

Задание 15.

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

Задание 16.

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

Задание 17.

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

Задание 18.

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

Задание 19.

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

Задание 20.

За что именно отвечает разработчик в течение всего срока действия разрешительного документа, и в какой форме осуществляется этот надзор?

Задание 21.

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

Задание 22.

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

Задание 23.

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

Задание 24.

На какие три типа нормативно-технической документации опираются эксперты при планировании и проведении оценочных мероприятий?

Задание 25.

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

Задание 26.

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

Задание 27.

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

Задание 28.

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

Задание 29.

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

Задание 30.

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

31. Ответственность и гарантии при сертификации

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

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

32. Легализация иностранного ПО для госсектора РФ

Ситуация: Международная IT-компания планирует поставку ПО российскому оборонному предприятию. Продукт имеет иностранные сертификаты (IEC).

Задание: Составьте пошаговый алгоритм легализации данного ПО для использования в РФ. Укажите, с какими основными процедурными и нормативными препятствиями (коллизиями) компания столкнется на каждом этапе.

33. Контроль соответствия документации

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

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

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

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

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

35. Формальный и содержательный подход при несоответствии

Ситуация: При испытаниях CRM-системы замеренное время отклика (210 мс) превысило требование ТЗ (200 мс). Разработчик оспаривает результат, ссылаясь на незначительность отклонения.

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

36. Правомерность требования сертификации системы

Ситуация: Компания-интегратор поставила госзаказчику информационную систему, собранную из сертифицированной СУБД и собственных разработок. Заказчик требует сертификат на всю систему.

Задание: Дайте правовую оценку требованию заказчика. Обоснуйте свой ответ, четко разграничив правовые последствия сертификации компонента (СУБД) и сертификации системы в сборе.

37. Переход сертификатов при реорганизации

Ситуация: В результате слияния компаний «А» и «Б» создана новая компания «В». Компания «В» хочет использовать сертификаты, выданные ранее компании «А».

Задание: Определите, возможно ли это. Если да, то опишите официальную процедуру, которую должна инициировать компания «В» для легитимного переоформления прав на сертификаты.

38. Основания для отказа в сертификации

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

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

39. Принятие решения по некритичному дефекту

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

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

40. Сравнительный анализ видов сертификации

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

o    Основная цель:

o    Интересы потребителя:

o    Интересы государства:

o    Интересы разработчика:

o    Синергетический эффект для рынка (выгода от одновременного существования двух систем):

o