ЖУРНАЛ СТА 2/2015

mercial Off-The-Shelf – COTS) сертифи- цированных (или сертифицируемых – о разнице между этими понятиями уже го- ворилось ранее) программных компо- нентов. Смысл этого подхода в том, что неко- торые части программного стека (на- пример, ОС и связующее ПО) остаются неизменными достаточно долгое время, и вместо того чтобы разрабатывать и со- провождать их (а также сопутствующую сертификационную документацию) са- мостоятельно, может оказаться гораздо дешевле (а главное, быстрее) приобре- сти готовый коммерческий продукт, уже имеющий необходимый сертифи- кат или снабжённый сертификацион- ным пакетом. Это не отменит необхо- димости в подготовке сертификацион- ной документации для остальных ком- понентов (например, BSP и прикладно- го ПО), но существенная часть работы будет сделана – по статистике компа- нии Wind River, применение сертифи- цируемой ОС в сочетании с коммерче- ским сертификационным пакетом спо- собно сократить трудозатраты на 2 чело- веко-года и более . У этого подхода, правда, есть три тон- кости. Во-первых , поскольку требования безопасности налагают ограничения на архитектуру ПО, а стоимость сертифи- кации напрямую зависит от объёма подлежащего сертификации кода, дале- ко не любой программный продукт яв- ляется в принципе пригодным для сер- тификации. Чтобы пройти сертифика- цию, продукт должен быть разработан определённым образом, иметь опреде- лённое внутреннее устройство (в соот- ветствии с требованиями нормативной базы, о чём говорилось ранее) и быть по возможности более компактным (что- бы стоимость сертификации не получи- лась неоправданно высокой). Этим, кстати, объясняется чрезвычайно низ- кий уровень присутствия ОС Linux в си- стемах с высокими требованиями к функциональной безопасности – Linux без существенных доработок не прохо- дит ни по требованиям стандартов, ни по стоимости сертификационных работ. Во-вторых , не всякий пригодный к сертификации программный продукт имеет сертификаты (или сертифика- ционные пакеты) по всем возможным стандартам функциональной и инфор- мационной безопасности – это было бы слишком дорого. Производители про- дуктов обычно сами решают, на каких рынках фокусироваться, и затем уже обеспечивают своим продуктам необхо- димую базу для отраслевой сертифика- ции. Если продолжать говорить об ОС, то абсолютный чемпион в этом смысле из представленных в России – ОС Vx- Works компании Wind River, имеющая сертификационные пакеты DO-178B/C до уровня А включительно и МЭК 15408 до уровня EAL 6+ (согласно [5] версии 1.3), а также сертификат МЭК 61508 до уровня SIL 3 включительно. На базе сертификационного пакета МЭК 61508 для VxWorks в последние годы компанией Wind River был также вы- полнен ряд железнодорожных проектов с сертификацией по EN 50128 вплоть до уровня SIL 4. Почти аналогичный на- бор (за исключением DO-178B/C) есть у широко распространённой в России ОС QNX Neutrino, кроме того, её защи- щённая версия (ЗОСРВ КПДА 10964-01 «Нейтрино») также имеет отечествен- ные сертификаты информационной безопасности в системах сертификации ФСТЭК и МО. Сертифицированные ОС на базе Linux (например, россий- ская Astra Linux Special Edition) пред- ставляют собой противоположный экс- тремум – сертификаты информацион- ной безопасности у них есть, а функ- циональной – нет. В-третьих , применение коммерче- ских сертифицированных и сертифи- цируемых программных компонентов всегда сопряжено с оговорками, так как сертификация «сферического компо- нента в вакууме» – это одно, а интегра- ция его в сложную многокомпонент- ную систему – совсем другое. Также важен вопрос взаимного доверия оцен- щиков: стандарты функциональной и информационной безопасности гово- рят об этом разными словами, но прак- тический смысл очень схож: наличие сертификата у коммерческого про- граммного компонента ещё не гаранти- рует положительный вердикт оценщи- ка, и может потребоваться повторная оценка. Хорошая новость, правда, за- ключается в том, что если есть серти- фикат, то есть и сертификационная до- кументация, то есть повторную оценку безопасности не придётся делать с ну- ля, а значит, она обойдётся дешевле. Ну и, естественно, данный подход ра- ботает только для компонентов про- граммного стека, не подверженных ча- стым изменениям (читай – ОС и свя- зующего ПО). Для остальных компо- нентов приходится искать другие спо- собы сокращения сертификационных трудозатрат. А ВТОМАТИЗИРУЙ ЭТО : ИНСТРУМЕНТАРИЙ ВЕРИФИКАЦИИ И ВАЛИДАЦИИ Большинство методик обеспечения качества ПО, описанных в статье, яв- ляются в той или иной степени автома- тизируемыми. То есть понятно, что не- льзя автоматизировать процесс, ска- жем, написания тестов, но процесс ге- нерации «обёртки» (test harness) и вход- ных данных для тестирования автома- тизировать можно. Также можно авто- матизировать процесс статического анализа, а его выходные результаты, в свою очередь, автоматически подать на вход процесса анализа структурного покрытия, и так далее. Потом по ре- зультатам выполнения всех необходи- мых задач можно автоматически сгене- рировать отчёт, оформленный в соот- ветствии с требованиями нужного стандарта, и подшить его к сертифика- ционной документации. Основная ценность такого подхода в том, что он позволяет, однажды настроив процесс генерации документов, повторять его по необходимости в автоматическом режиме. Это обеспечивает непрерыв- ную целостность сертификационного пакета и предохраняет от человеческих ошибок. В литературе, посвящённой качеству ПО, постоянно фигурируют два терми- на – « верификация » (verification) и « ва- лидация » (validation). Их часто путают друг с другом, в основном благодаря то- му, что их классические определения безобразно неоднозначны, и поэтому разные источники относят к ним раз- личные конкретные действия (напри- мер, в терминах DO-178B почти все описанные в настоящей статье методи- ки относятся к верификации). Впро- чем, хорошая новость заключается в том, что эти термины почти всегда упо- требляют вместе (видимо, чтобы не по- пасть впросак), поэтому достаточно сказать «верификация и валидация» (V&V) – и точно не ошибёшься. Так вот, существует целый класс про- граммных продуктов, автоматизирую- щих задачи V&V, их так и называют – инструменты верификации и валида- ции (verification and validation tools). К таким инструментам относятся сред- ства статического анализа, анализа по- крытия (ряд производителей встраивае- мых ОС даже включает их в дистрибу- тив комплекта разработчика), автома- тизированного тестирования и т.п. Ко- личество таких инструментов на рынке исчисляется десятками; однако каждый 62 СТА 2/2015 ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ www.cta.ru