К вопросу о стандартизации и сертификации программного

К вопросу о стандартизации и сертификации программного
обеспечения
В.В. Бочаров, руководитель Службы
качества ФГУП «ГосНИИАС», доктор
технических наук, процессор.
А.В. Морозов, заместитель руководителя
органа по сертификации продукции ФГУП
«ГосНИИАС»
В настоящее время программное обеспечение является важной составной
частью многих технических устройств и систем. Эти устройства очень
разнообразны как по назначению, так и по требованию к надежности их работы. К
таким устройствам могут быть отнесены как mp3-плейеры, сотовые телефоны,
стиральные машинки, так и бортовые системы управления летательных
аппаратов, системы управления и контроля атомных электростанций,
информационные системы государственного управления. Надежность работы
таких систем во многом зависит от надежности работы программного обеспечения.
Надежность самого программного обеспечения определяется теми технологиями,
в соответствии с которыми разрабатывается программное обеспечение. Вместе с
тем, при разработке программного обеспечения многие предприятия продолжают
в качестве основных руководящих документов использовать стандарты серии
ЕСПД. Разработанные в 70-х годах прошлого века, эти стандарты сыграли
большую роль при создании технических систем предыдущего поколения. Но в
настоящее время руководствоваться стандартами ЕСПД для создания сложного и
надежного программного обеспечения недостаточно. Впрочем, название данной
серии ГОСТов говорит само за себя: «Единая система программной
документации». То есть, данные ГОСТЫ в большей степени определяют, как
оформить документацию на разработанное программное обеспечение, а не как
правильно разработать и испытать программное обеспечение.
Чтобы понять, а есть ли альтернатива ЕСПД, попробуем проанализировать
отечественные стандарты по программному обеспечению. За последние двадцать
лет их появилось довольно много: ГОСТ 24402-88, ГОСТ 28806-90, ГОСТ 19781-90,
ГОСТ Р ИСО/МЭК 9126-93, ГОСТ Р 51189-1998, ГОСТ Р ИСО/МЭК12207-99, ГОСТ
Р ИСО/МЭК 12199-2000, ГОСТ Р 51904-2002, ГОСТ Р ИСО/МЭК ТО 2382-23-2004,
ГОСТ Р МЭК 61508-2007, ГОСТ Р ИСО/МЭК 15408-2008 и т.д. И это далеко не
полный перечень. Но здесь прослеживается наметившаяся тенденция:
отечественные ГОСТы по программному обеспечению все в большей степени
разрабатываются на основе международных стандартов.
В этой связи показательной является иллюстрация (рисунок 1) множества
международных, национальных и отраслевых стандартов по программному
обеспечению, составленная компанией Adjust Media (www.adj.ru) еще в 2002 году,
дополненная современными стандартами требований к документированию,
менеджмента качества, управления проектами и конфигурацией.
Рис. 1 Международные, национальные и отраслевые стандарты
по программному обеспечению
Для последующего анализа ГОСТы по программному обеспечению (ПО) надо
как-то сгруппировать по требованиям, которые в них содержатся. И здесь можно
выделить следующие группы стандартов:
1. Стандарты, определяющие требования к качеству ПО (ГОСТ Р ИСО/МЭК
9126-93, ГОСТ 28195-89, ГОСТ Р ИСО/МЭК 12199-2000).
2. Стандарты, определяющие требования к функциональной безопасности ПО
(ГОСТ Р МЭК 61508-2007) .
3. Стандарты, определяющие требования к информационной безопасности
ПО (ГОСТ Р ИСО/МЭК 15408-2008, ГОСТ Р 50739-95).
4. Стандарты, определяющие требования к документации ПО (ГОСТ Р ИСО
9127-94, ГОСТ Р ИСО/МЭК ТО 9294-93).
5. Стандарты, определяющие термины по программному обеспечению (ГОСТ
Р ИСО/МЭК 2382-23-2004, ГОСТ 28806-90, ГОСТ 20886-85, ГОСТ 24402-88, ГОСТ
15971-90, ГОСТ 19781-90).
6. Стандарты на процессы жизненного цикла программного обеспечения
(ГОСТ Р ИСО/МЭК 12207-99, ГОСТ Р 51904-2002, ГОСТ Р 51189-98, ГОСТ Р
ИСО/МЭК 15504-2009, а также отнесем сюда КТ-178В).
7. Обучающие стандарты (ГОСТ Р ИСО/МЭК ТО 12182-2002, ГОСТ Р
ИСО/МЭК 15026-2002).
В качестве следующего шага рассмотрим из группы «обучающих стандартов»
ГОСТ Р ИСО/МЭК 15026-2002 «Информационная технология. Уровни целостности
систем и программных средств». По результатам рассмотрения данного стандарта
можно сделать вывод, что разработку как системы, так и ее программного
обеспечения, необходимо начинать с оценки риска, возникающего в случае отказа
или неправильного функционирования системы или программного обеспечения. В
зависимости от оценки риска программному обеспечению устанавливается
соответствующий уровень целостности, то есть указание диапазона значений
свойств объекта, необходимых для удержания риска в допустимых пределах. В
стандарте приведено следующее соотношение класса риска с уровнем
целостности системы:
Класс риска
Уровень целостности системы
Высокий
А
Средний
B
Низкий
C
Обычный
D
Класс риска, в свою очередь, зависит от опасности последствий
(катастрофическая, главная, опасная, незначительная) и характерной частоты
повторения. Чем выше уровень целостности программного обеспечения, тем
более высокие требования предъявляются к технологии его разработки и
проверки. Иными словами, не может быть одинакового подхода и одинакового
комплекта документации при разработке, к примеру, программного обеспечения
бортовой системы самолета и программного обеспечения стиральной машинки.
Хотя при разработке по ЕСПД комплект документации для приведенных вариантов
будет одинаковым.
Подобный подход прослеживается и в других стандартах по программному
обеспечению.
ГОСТ Р МЭК 61508-2007 «Функциональная безопасность систем
электрических, электронных, программируемых электронных, связанных с
безопасностью» выделяет четыре уровня полноты безопасности (SIL4, SIL3, SIL2,
SIL1) в зависимости от тяжести последствий опасных отказов. Для этих уровней
формируются разные требования к надежности ПО и методам ее достижения.
ГОСТ Р ИСО/МЭК 15408-2008 «Информационная технология. Методы и
средства
обеспечения
безопасности.
Критерии
оценки
безопасности
информационных технологий» выделяет семь оценочных уровней доверия (ОУД1
– ОУД7). Чем выше уровень доверия необходим для программного обеспечения,
тем более жесткие требования разработчик должен выполнить в процессе
разработки и оценки ПО.
Причем оба приведенных выше ГОСТа указывают, что обеспечить
выполнение требований необходимых уровней полноты безопасности или
оценочных уровней доверия можно только при процессном подходе к разработке
программного обеспечения, то есть при применении стандартов на процессы
жизненного цикла программного обеспечения.
Это положение приводит нас к схеме разработки программного обеспечения,
показанной на рисунке 2.
Рисунок 2. Схема порядка разработки программного обеспечения для систем
ответственного применения.
То есть, получив задание на разработку программного обеспечения (или
решив разработать ПО для коммерческих целей), разработчик должен выполнить
следующие действия:
1. Провести анализ рисков при отказах ПО, для чего могут быть использованы
стандарты серии «Менеджмент риска». При анализе определиться с
необходимостью выполнения требований стандартов по функциональной
безопасности и информационной безопасности, а также определить стандарт по
процессам жизненного цикла ПО, в соответствии с которым будет вестись
разработка.
2. Провести разработку ПО в соответствии со стандартом на процессы
жизненного цикла, обеспечив при этом выполнение требований стандартов на
обеспечение функциональной и информационной безопасности.
3. Провести после завершения разработки итоговую оценку качества ПО.
Кроме того, если организация ставит перед собой амбиционные планы по
продвижению своего продукта на международные рынки (пример для
аэрокосмической отрасли), то в рамках системы менеджмента качества при
сертификации на соответствие AS9100 организация должна обеспечить
выполнение требований стандарта AS9115 «Аэрокосмический стандарт. Система
управления качеством. Требования для организаций аэрокосмической и
оборонной промышленности. Требования к поставляемому программному
обеспечению».
Разработать программное обеспечение по представленной выше схеме
является очень непростой задачей. Кроме того, на этапе планирования может
возникнуть много вопросов, например:
− Если разработка ПО проводится в соответствии с КТ-178В или ГОСТ Р
51904-2002, в которых установлены уровни ПО и требования к программному
обеспечению для достижения этих уровней, то надо ли еще проводить оценку
программного обеспечения на требования ГОСТ Р МЭК 61508-2007 по
функциональной безопасности?
− Надо ли проводить оценку программного обеспечения встроенных систем
на информационную безопасность по ГОСТ Р ИСО/МЭК 15408-2008, если после
установки контакт данного ПО с «внешним» ПО будет исключён?
− Какой ГОСТ выбрать для оценки надежности ПО? и т.д.
Наверное отдельно взятому разработчику будет трудно ответить на ряд таких
вопросов. Не всегда правильной также является позиция, что все требования к
созданию программного обеспечения пропишет Заказчик в своём техническом
задании. Ведь Заказчик в конечном итоге заинтересован в качестве поставляемой
продукции, а технология производства этого качественного продукта является
задачей разработчика.
Вариантом решения проблемы может стать поиск правильных подходов к
разработке программного обеспечения в «клубах по интересам» для различных
отраслей промышленности. Для авиационной отрасли такой площадкой может
стать, к примеру, Некоммерческое партнерство «Союз авиапроизводителей».
После определения рациональных подходов по разработке программного
обеспечения, устраивающих большинство разработчиков, вполне возможно, для
внедрения передовых технологий, задействовать и административный ресурс в
лице Департамента авиационной промышленности Минпромторга РФ.
Необходимо коснуться еще одного очень важного вопроса. Заказчик или
покупатель
всегда хотят получить доказательства качества и надежности
программного обеспечения. И если у Заказчика есть возможность провести
испытания программного обеспечения (автономно или в составе системы), то у
покупателя есть только заверения разработчика, чего не всегда бывает
достаточно. И здесь на помощь может прийти сертификация программного
обеспечения.
Сертификация
программного
обеспечения
является
широко
распространенной
международной
практикой
для
продвижения
программного обеспечения на рынке.
Для подтверждения этого приведем следующий пример. Различные версии
операционных систем реального времени QNX, VxWorks, LynxOS-178, широко
применяемые во встроенных системах, имеют сертификаты (по данным сайтов
http//www.swd.ru/,
http//www.windriver.com/,
http//www.lynuxworks.com/) на
соответствие:
− IEC 61508 – функциональная безопасность;
− ISO/IEC 15408 – информационная безопасность;
− RTCA DO-178B – квалификационные требования, определяющие
процессный подход при разработке программного обеспечения для
применения в авиационных комплексах;
− POSIX – соответствие интерфейсу прикладного программирования;
− ARING653 – стандартный интерфейс прикладного программирования для
авиации;
− FDA – для применения в медицине и пищевой промышленности и т.д.
На базе операционной системы QNX создана защищенная операционная
система реального времени (изделие КПДА), которая к настоящему времени имеет
и российские сертификаты ФСТЭК России и Минобороны России (см.
http//www.swd.ru/).
Из приведенного примера можно сделать вывод, что вывести коммерческое
программное обеспечение на международный рынок, а в недалеком будущем и на
российский, без сертификатов соответствия будет проблематично.
В настоящее время в России хорошо обстоит дело с сертификацией
программного обеспечения на информационную безопасность, которую проводят
ФСТЭК России, Минобороны и ФСБ. Для авиационной отрасли широко
применяется сертификация программного обеспечения на соответствие КТ-178В в
Международном авиационном комитете. Но все это подпадает под обязательную
сертификацию. Добровольная сертификация на соответствие иным стандартам,
отмеченным в данной статье, в России востребована слабо. И этот вопрос тоже
надо решать: или создавать условия для сертификации программного
обеспечения в России, или идти на сертификацию программного обеспечения в
иностранные органы по сертификации.
Для сертификации программного обеспечения в России есть ещё одна очень
важная проблема. Многие ГОСТы, принятые на основании международных
стандартов, сильно отстают по срокам ввода в действие от своих международных
аналогов. Поясним это на примерах:
1. ГОСТ Р ИСО/МЭК 12207-99 разработан на основе стандарта ISO/IEC
12207:1995, то есть стандарта, принятого еще в 1995 году. Но после этого к
стандарту ISO/IEC 12207:1995 было дополнение № 1 в 2002 году и дополнение №
2 в 2004 году, которые остались «незамеченными» в России. А в 2008 году вышла
новая редакция стандарта – ISO/IEC 12207:2008, аналог которого в России вступил
в действие только 1 марта 2012 года.
2. ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология. Оценка
программной продукции. Характеристики качества и руководства по их
применению» разработан на основе ISO/IEC 9126:91, который был пересмотрен в
2001 г. и издан уже в четырех частях. Но и эти части сейчас отменяются в связи с
введением новой серии стандартов по качеству программного обеспечения:
ISO/IEC 25000:2005, ISO/IEC 25001:2007, ISO/IEC 25010:2011 и т.д.
Не нужно в настоящее время, наверно, иметь и 5 стандартов на термины по
программному обеспечению.
Представляется, что навести порядок в ГОСТах по программному
обеспечению – это актуальная задача для Технологической платформы
«Национальная программная платформа» при координирующей роли технического
комитета по стандартизации № 22 «Информационные технологии».
Представляется важным также рассмотреть вопрос, а нужно ли
сертифицировать
программное
обеспечение,
создаваемое
по
заказам
Государственных заказчиков, например, Министерства обороны. На первый взгляд
ответ
отрицательный,
ведь
Министерство
обороны
самостоятельно
организовывает
приемку
заказанной
продукции
силами
военных
представительств, научно-исследовательских институтов и испытательных
центров.
Но есть и аргументы в пользу сертификации.
Во-первых, такая практика уже есть на примере сертификатов на
информационную безопасность. Включение в техническое задание требования
сертификации на информационную безопасность зачастую является для
Заказчика более простым решением, чем попытка учесть в техническом задании и
сформулировать
все
требования
по
информационной
безопасности
самостоятельно.
Во-вторых, в условиях сокращения Вооруженных Сил у Заказчика может
просто не оказаться нужных специалистов, к примеру, которые могли бы провести
оценку качества программного обеспечения по международным стандартам.
В-третьих, сертификация программного обеспечения на соответствие
стандартам, определяющим процессы создания программного обеспечения,
является, в первую очередь, оценкой соблюдения разработчиком технологии
разработки программного обеспечения. Это то, что Заказчик не может принять и
на что не может повлиять, но при этом информация о соблюдении необходимой
технологии разработчиком важна для Заказчика для повышения доверия к такому
программному обеспечению.
Важным моментом здесь является и время, когда должен быть предъявлен
разработчиком сертификат на программное обеспечение. По-видимому, такой
сертификат должен быть представлен разработчиком после завершения
конструкторских испытаний при предъявлении системы, содержащей программное
обеспечение, на государственные испытания.
И здесь встает еще один очень важный вопрос. Большинство схем
сертификации предусматривают сертификацию или серии, или партии продукции,
то есть уже разработанных и изготовленных изделий. Для программного
обеспечения такая схема может быть применима только при сертификации на
соответствие ГОСТам по качеству программного обеспечения. Если речь идет о
стандартах по функциональной безопасности или процессам жизненного цикла, то
сертификацию и взаимодействие с органом по сертификации надо начинать на
ранних стадиях разработки, буквально на этапе планирования, поскольку
повторить процесс разработки программного обеспечения в случае серьезных
нарушений требований ГОСТов будет проблематично. То есть взаимодействие с
органом по сертификации с момента начала разработки программного
обеспечения позволяет избежать серьезных технологических ошибок, что
особенно важно при недостаточном опыте разработки программного обеспечения
по новым ГОСТам.
Организация, которая готова заняться сертификацией программного
обеспечения для Министерства обороны, в России есть – это СДС «Военный
Регистр». И в данном случае важна только заинтересованность Министерства
обороны в такой сертификации.
На основании изложенного выше можно сделать вывод, что состояние по
стандартизации и сертификации программного обеспечения в России нельзя
считать удовлетворительным. Ситуацию можно исправить только коллективными
усилиями заинтересованных в этом разработчиков программного обеспечения и
государственных органов власти.