По завершению интеграционного тестирования все модули системы являются согласованными по интерфейсам и функциональности. Начиная с этого момента можно переходить к тестированию системы в целом как единого объекта тестирования - к системному тестированию. На уровне интеграционного тестирования тестировщика интересовали в основном структурные аспекты системы, на уровне системного тестирования интересуют поведенческие аспекты системы. Как правило, для системного тестирования применяется подход черного ящика, при этом в качестве входных и выходных данных используются реальные данные, с которыми работает система, или данные, подобные им.
Системное тестирование - один из самых сложных видов тестирования. На этом этапе проводится не только функциональное тестирование, но и оценка характеристик качества системы - ее устойчивости, надежности, безопасности и производительности. На этом этапе выявляются многие проблемы внешних интерфейсов системы, связанные с неверным взаимодействием с другими системами, аппаратным обеспечением, неверным распределением памяти, отсутствием корректного освобождения ресурсов и т.п.
После завершения системного тестирования разработка переходит в фазу приемо-сдаточных испытаний (для программных систем, разрабатываемых на заказ) или в фазу альфа- и бета-тестирования (для программных систем общего применения).
Поскольку системное тестирование - процесс, требующих значительных ресурсов, для его проведения часто выделяют отдельный коллектив тестировщиков, а зачастую системное тестирование выполняется организацией, которая не связана с коллективом разработчиков и тестировщиков, выполнявших работы на предыдущих этапах тестирования. При этом необходимо отметить, что при разработке некоторых типов программного обеспечения (например, авиационного бортового) требование независимого тестирования на всех этапах разработки является обязательным.
Системное тестирование проводится в несколько фаз, на каждой из которых проверяется один из аспектов поведения системы, т.е. проводится один из типов системного тестирования. Все эти фазы могут протекать одновременно или последовательно. Следующий раздел посвящен рассмотрению особенностей каждого из типов системного тестирования на каждой фазе.
Принято выделять следующие виды системного тестирования:
В ходе системного тестирования проводятся далеко не все из перечисленных видов тестирования - конкретный их набор зависит от тестируемой системы.
Исходной информацией для проведения перечисленных видов тестирования являются два класса требований: функциональные и нефункциональные. Функциональные требования явно описывают, что система должна делать и какие выполнять преобразования входных значений в выходные. Нефункциональные требования определяют свойства системы, напрямую не связанные с ее функциональностью. Примером таких свойств может служить время отклика на запрос пользователя (например, не более 2 секунд), время бесперебойной работы (например, не менее 10000 часов между двумя сбоями), количество ошибок, которые допускает начинающий пользователь за первую неделю работы (не более 100), и т.п.
Рассмотрим каждый вид тестирования подробнее.
Функциональное тестирование. Данный вид тестирования предназначен для доказательства того, что вся система в целом ведет себя в соответствии с ожиданиями пользователя, формализованными в виде системных требований. В ходе данного вида тестирования проверяются все функции системы с точки зрения ее пользователей (как пользователей-людей, так и "пользователей" - других программных систем). Система при функциональном тестировании рассматривается как черный ящик, поэтому в данном случае полезно использовать классы эквивалентности. Критерием полноты тестирования в данном случае будет полнота покрытия тестами системных функциональных требований (или системных тест-требований) и полнота тестирования классов эквивалентности, а именно:
Результаты системного тестирования протоколируются и анализируются совершенно аналогично тому, как это делается для модульного и интеграционного тестирования. Основная сложность здесь заключается в локализации дефектов в программном коде системы и определении зависимостей одних дефектов от других (эффект "четного числа ошибок").
Тестирование производительности. Данный вид тестирования направлен на определение того, что система обеспечивает должный уровень производительности при обработке пользовательских запросов. Тестирование производительности выполняется при различных уровнях нагрузки на систему, на различных конфигурациях оборудования. Выделяют три основных фактора, влияющие на производительность системы: количество поддерживаемых системой потоков (например, пользовательских сессий), количество свободных системных ресурсов, количество свободных аппаратных ресурсов.
Тестирование производительности позволяет выявлять узкие места в системе, которые проявляются в условиях повышенной нагрузки или нехватки системных ресурсов. В этом случае по результатам тестирования проводится доработка системы, изменяются алгоритмы выделения и распределения ресурсов системы.
Все требования, относящиеся к производительности системы, должны быть четко определены и обязательно должны включать в себя числовые оценки параметров производительности. Т.е., например, требование "Система должна иметь приемлемое время отклика на запрос пользователя" является непригодным для тестирования. Напротив, требование "Время отклика на запрос пользователя не должно превышать 2 секунды" может быть протестировано.
То же самое относится и к результатам тестирования производительности. В отчетах по данному виду тестирования сохраняют такие показатели, как загрузка аппаратного и системного программного обеспечения (количество циклов процессора, выделенной памяти, количество свободных системных ресурсов и т.п.). Также важны скоростные характеристики тестируемой системы (количество обработанных в единицу времени запросов, временные интервалы между началом обработки каждого последующего запроса, равномерность времени отклика в разные моменты времени и т.п.).
Для проведения тестирования производительности требуется наличие генератора запросов, который подает на вход системы поток данных, типичных для сеанса работы с ней. Тестовое окружение должно включать в себя кроме программной компоненты еще и аппаратную, причем на таком тестовом стенде должна существовать возможность моделирования различного уровня доступных ресурсов.
Стрессовое тестирование.
Тестирование конфигурации. Большинство программных систем массового назначения предназначено для использования на самом разном оборудовании. Несмотря на то, что в настоящее время особенности реализации периферийных устройств скрываются драйверами операционных систем, которые имеют унифицированный с точки зрения прикладных систем интерфейс, проблемы совместимости (как программной, так и аппаратной) все равно существуют.
В ходе тестирования конфигурации проверяется, что программная система корректно работает на всем поддерживаемом аппаратном обеспечении и совместно с другими программными системами. Необходимо также проверять, что система продолжает стабильно работать при горячей замене любого поддерживаемого устройства на аналогичное. При этом система не должна давать сбоев ни в момент замены устройства, ни после начала работы с новым устройством.
Также необходимо проверять, что система корректно обрабатывает проблемы, возникающие в оборудовании, как штатные (например, сигнал конца бумаги в принтере), так и нештатные (сбой питания).
Тестирование безопасности. Если программная система предназначена для хранения или обработки данных, содержимое которых представляет собой тайну определенного рода (личную, коммерческую, государственную и т.п.), то к свойствам системы, обеспечивающим сохранение этой тайны, будут предъявляться повышенные требования. Эти требования должны быть проверены при тестировании безопасности системы. В ходе этого тестирования проверяется, что информация не теряется, не повреждается, ее невозможно подменить, а также к ней невозможно получить несанкционированный доступ, в том числе при помощи использования уязвимостей в самой программной системе.
В отечественной практике принято проводить сертификацию программных систем, предназначенных для хранения данных для служебного пользования, секретных, совершенно секретных и совершенно секретных особой важности. Существует ряд отечественных стандартов Федеральной службы по техническому и экспортному контролю (ФСТЭК), регламентирующих свойства программных систем по обеспечению необходимого уровня безопасности [5] и по отсутствию недокументированных возможностей ("закладок") [4], которые могут быть использованы злоумышленником для несанкционированного доступа к данным. Кроме того, существует международный стандарт
Несмотря на то, что сертификация - процесс, следующий за верификацией, требования этих стандартов могут быть использованы и при тестировании системы. Так, стандарт [5] ФСТЭК, традиционно сокращенно называемый РД СВТ, выделяет следующие группы свойств программной системы, подлежащие проверке (некоторые группы свойств укрупнены для сокращения списка):
При разработке и верификации программной системы, которая будет подвергаться последующей сертификации, работы по сертификации должны включать в себя проверку всех перечисленных свойств.
Тестирование надежности и восстановления после сбоев. Для корректной работы системы в любой ситуации необходимо удостовериться в том, что она восстанавливает свою функциональность и продолжает корректно работать после любой проблемы, прервавшей ее работу. При тестировании восстановления после сбоев имитируются сбои оборудования или окружающего программного обеспечения либо сбои программной системы, вызванные внешними факторами. При анализе поведения системы в этом случае необходимо обращать внимание на два фактора - минимизацию потерь данных в результате сбоя и минимизацию времени между сбоем и продолжением нормального функционирования системы
Тестирование удобства использования. Отдельная группа нефункциональных требований - требования к удобству использования пользовательского интерфейса системы. Этот вид тестирования будет рассмотрен в следующей лекции.
В результате выполнения всех рассмотренных выше видов тестирования делается заключение о функциональности и свойствах системы, после чего узкие места системы дорабатываются до реализации необходимой функциональности или до достижения системой необходимых свойств.
При разработке массового ("коробочного",
При разработке заказного программного обеспечения фазу альфа- и бета-тестирования заменяют приемо-сдаточные испытания. Во время этих испытаний заказчик удостоверяется, что система работает в соответствии с его потребностями (как зафиксированными в техническом задании на систему, так и не зафиксированными). Заказчик может проводить такие испытания самостоятельно, выполняя заранее подготовленные тесты системы, либо проводить их совместно с представителями коллектива разработчиков. В этом случае тестовые примеры также готовятся разработчиками, например, на основе тестовых примеров, использовавшихся на этапе системного тестирования.
Завершаются приемо-сдаточные испытания либо подписанием акта приемки, либо выдачей заказчиком дополнительных требований к системе, которые должны быть исправлены до приемки системы. После устранения всех недостатков системы приемо-сдаточные испытания повторяются (возможно, по сокращенной программе). После успешного подписания акта система поступает в эксплуатацию заказчику.
Существует специальный вид программных систем, к свойствам которых предъявляются особые требованиями. Примером таких систем могут служить бортовые авиационные программные системы, для которых особое внимание уделяется вопросам безопасности, надежности и отказоустойчивости. Несмотря на то, что большая часть таких систем может быть отнесена к категории заказного программного обеспечения, для получения разрешения на установку системы на борт требуется получение сертификата на летную пригодность.
Таким образом, после проведения системного тестирования и приемо-сдаточных испытаний проводятся сертификационные испытания. Сертификация программного обеспечения - процесс установления и официального признания того, что разработка ПО проводилась в соответствии с определенными требованиями. В процессе сертификации происходит взаимодействие заявителя, сертифицирующего органа и наблюдательного органа.
Заявитель - это организация, подающая заявку в соответствующий сертифицирующий орган на получение сертификата (соответствия, качества, годности и т.п.) изделия.
Сертифицирующий орган - организация, которая рассматривает заявку заявителя о проведении сертификации ПО и либо самостоятельно, либо путем формирования специальной комиссии производит набор процедур, направленных на проведение процесса сертификации ПО заявителя.
Наблюдательный орган - комиссия специалистов, наблюдающих за процессами разработки заявителем сертифицируемой информационной системы и дающих заключение о соответствии данного процесса определенным требованиям, которое передается на рассмотрение в сертифицирующий орган. [34]
Основной объект проверки в ходе сертификационных испытаний - удовлетворяет ли процесс разработки программной системы регламенту и рекомендациям стандарта, на соответствие которому проводится сертификация. Такое соответствие определяется при помощи анализа жизненного цикла сертифицируемой системы и документов, создаваемых на ключевых его этапах. Весь процесс анализа и те свойства системы, которые подвергаются сертификации, описывается в плане сертификационных испытаний, который утверждается совместно заявителем и сертифицирующим органом.
В случае сертификации бортовой системы по стандарту DO-178B (или его аналогам КТ-178, JB-12 и т.п.) план дополнительно определяет уровень влияния отказа программной системы на безопасность полета (уровень отказобезопасности) по которому будет проводиться сертификация. Любые вопросы, которые возникают у сертифицирующего органа относительно содержания плана сертификационных испытаний, должны быть разрешены до начала самих испытаний.
Согласно требованиями DO-178B план сертификационных испытаний (план программных аспектов сертификации) должен включать:
В процессе самих сертификационных испытаний заявитель предоставляет свидетельства того, что процессы жизненного цикла программного обеспечения удовлетворяют планам программного обеспечения. Заявитель организует доступ сертифицирующего органа к данным жизненного цикла программного обеспечения. При этом минимальный перечень этих данных включает в себя:
Итоговое заключение по программному обеспечению является основным документом для демонстрации соответствия программного обеспечения Плану программных аспектов сертификации. Итоговое заключение должно включать:
Полный перечень данных жизненного цикла, которые могут понадобиться при сертификации, включает в себя:
Сертифицирующий орган устанавливает т.н. сертификационный базис для системы в ходе консультаций с заявителем. Сертификационный базис определяет конкретные правила вместе с любыми специальными условиями, которые могут дополнять опубликованные правила сертификации, регламентированные стандартом.
Для программного обеспечения установка базиса производится по рассмотрению итогового заключения о программном обеспечении и свидетельств соответствия.
В ходе сертификации сертифицирующий орган оценивает план программных аспектов сертификации на полноту и согласованность с критериями оценки отказобезопасности системы и другими данными жизненного цикла программного обеспечения. Если верны все данные жизненного цикла, являющиеся доказательством того, что в ходе проекта были активны все необходимые процессы разработки и верификации, то сертифицирующий орган выдает положительное решение о выдаче сертификата.
Сертификаты на программное обеспечение можно отнести к двум типам: сертификаты соответствия и сертификаты качества.
Сертификат на летную пригодность в рассматриваемом примере сочетает в себе свойства обоих типов сертификатов. С одной стороны, он удостоверяет, что разработанная система имеет определенный уровень качества реализации, а с другой - что процессы по ее разработке соответствуют международному авиационному отраслевому стандарту.
По завершению интеграционного тестирования все модули системы являются согласованными по интерфейсам и функциональности. Начиная с этого момента можно переходить к тестированию системы в целом как единого объекта тестирования - к системному тестированию. На уровне интеграционного тестирования тестировщика интересовали в основном структурные аспекты системы, на уровне системного тестирования интересуют поведенческие аспекты системы. Как правило, для системного тестирования применяется подход черного ящика, при этом в качестве входных и выходных данных используются реальные данные, с которыми работает система, или данные, подобные им.
Системное тестирование - один из самых сложных видов тестирования. На этом этапе проводится не только функциональное тестирование, но и оценка характеристик качества системы - ее устойчивости, надежности, безопасности и производительности. На этом этапе выявляются многие проблемы внешних интерфейсов системы, связанные с неверным взаимодействием с другими системами, аппаратным обеспечением, неверным распределением памяти, отсутствием корректного освобождения ресурсов и т.п.
После завершения системного тестирования разработка переходит в фазу приемо-сдаточных испытаний (для программных систем, разрабатываемых на заказ) или в фазу альфа- и бета-тестирования (для программных систем общего применения).
Поскольку системное тестирование - процесс, требующих значительных ресурсов, для его проведения часто выделяют отдельный коллектив тестировщиков, а зачастую системное тестирование выполняется организацией, которая не связана с коллективом разработчиков и тестировщиков, выполнявших работы на предыдущих этапах тестирования. При этом необходимо отметить, что при разработке некоторых типов программного обеспечения (например, авиационного бортового) требование независимого тестирования на всех этапах разработки является обязательным.
Системное тестирование проводится в несколько фаз, на каждой из которых проверяется один из аспектов поведения системы, т.е. проводится один из типов системного тестирования. Все эти фазы могут протекать одновременно или последовательно. Следующий раздел посвящен рассмотрению особенностей каждого из типов системного тестирования на каждой фазе.
Принято выделять следующие виды системного тестирования:
В ходе системного тестирования проводятся далеко не все из перечисленных видов тестирования - конкретный их набор зависит от тестируемой системы.
Исходной информацией для проведения перечисленных видов тестирования являются два класса требований: функциональные и нефункциональные. Функциональные требования явно описывают, что система должна делать и какие выполнять преобразования входных значений в выходные. Нефункциональные требования определяют свойства системы, напрямую не связанные с ее функциональностью. Примером таких свойств может служить время отклика на запрос пользователя (например, не более 2 секунд), время бесперебойной работы (например, не менее 10000 часов между двумя сбоями), количество ошибок, которые допускает начинающий пользователь за первую неделю работы (не более 100), и т.п.
Рассмотрим каждый вид тестирования подробнее.
Функциональное тестирование. Данный вид тестирования предназначен для доказательства того, что вся система в целом ведет себя в соответствии с ожиданиями пользователя, формализованными в виде системных требований. В ходе данного вида тестирования проверяются все функции системы с точки зрения ее пользователей (как пользователей-людей, так и "пользователей" - других программных систем). Система при функциональном тестировании рассматривается как черный ящик, поэтому в данном случае полезно использовать классы эквивалентности. Критерием полноты тестирования в данном случае будет полнота покрытия тестами системных функциональных требований (или системных тест-требований) и полнота тестирования классов эквивалентности, а именно:
Результаты системного тестирования протоколируются и анализируются совершенно аналогично тому, как это делается для модульного и интеграционного тестирования. Основная сложность здесь заключается в локализации дефектов в программном коде системы и определении зависимостей одних дефектов от других (эффект "четного числа ошибок").
Тестирование производительности. Данный вид тестирования направлен на определение того, что система обеспечивает должный уровень производительности при обработке пользовательских запросов. Тестирование производительности выполняется при различных уровнях нагрузки на систему, на различных конфигурациях оборудования. Выделяют три основных фактора, влияющие на производительность системы: количество поддерживаемых системой потоков (например, пользовательских сессий), количество свободных системных ресурсов, количество свободных аппаратных ресурсов.
Тестирование производительности позволяет выявлять узкие места в системе, которые проявляются в условиях повышенной нагрузки или нехватки системных ресурсов. В этом случае по результатам тестирования проводится доработка системы, изменяются алгоритмы выделения и распределения ресурсов системы.
Все требования, относящиеся к производительности системы, должны быть четко определены и обязательно должны включать в себя числовые оценки параметров производительности. Т.е., например, требование "Система должна иметь приемлемое время отклика на запрос пользователя" является непригодным для тестирования. Напротив, требование "Время отклика на запрос пользователя не должно превышать 2 секунды" может быть протестировано.
То же самое относится и к результатам тестирования производительности. В отчетах по данному виду тестирования сохраняют такие показатели, как загрузка аппаратного и системного программного обеспечения (количество циклов процессора, выделенной памяти, количество свободных системных ресурсов и т.п.). Также важны скоростные характеристики тестируемой системы (количество обработанных в единицу времени запросов, временные интервалы между началом обработки каждого последующего запроса, равномерность времени отклика в разные моменты времени и т.п.).
Для проведения тестирования производительности требуется наличие генератора запросов, который подает на вход системы поток данных, типичных для сеанса работы с ней. Тестовое окружение должно включать в себя кроме программной компоненты еще и аппаратную, причем на таком тестовом стенде должна существовать возможность моделирования различного уровня доступных ресурсов.
Стрессовое тестирование.
Тестирование конфигурации. Большинство программных систем массового назначения предназначено для использования на самом разном оборудовании. Несмотря на то, что в настоящее время особенности реализации периферийных устройств скрываются драйверами операционных систем, которые имеют унифицированный с точки зрения прикладных систем интерфейс, проблемы совместимости (как программной, так и аппаратной) все равно существуют.
В ходе тестирования конфигурации проверяется, что программная система корректно работает на всем поддерживаемом аппаратном обеспечении и совместно с другими программными системами. Необходимо также проверять, что система продолжает стабильно работать при горячей замене любого поддерживаемого устройства на аналогичное. При этом система не должна давать сбоев ни в момент замены устройства, ни после начала работы с новым устройством.
Также необходимо проверять, что система корректно обрабатывает проблемы, возникающие в оборудовании, как штатные (например, сигнал конца бумаги в принтере), так и нештатные (сбой питания).
Тестирование безопасности. Если программная система предназначена для хранения или обработки данных, содержимое которых представляет собой тайну определенного рода (личную, коммерческую, государственную и т.п.), то к свойствам системы, обеспечивающим сохранение этой тайны, будут предъявляться повышенные требования. Эти требования должны быть проверены при тестировании безопасности системы. В ходе этого тестирования проверяется, что информация не теряется, не повреждается, ее невозможно подменить, а также к ней невозможно получить несанкционированный доступ, в том числе при помощи использования уязвимостей в самой программной системе.
В отечественной практике принято проводить сертификацию программных систем, предназначенных для хранения данных для служебного пользования, секретных, совершенно секретных и совершенно секретных особой важности. Существует ряд отечественных стандартов Федеральной службы по техническому и экспортному контролю (ФСТЭК), регламентирующих свойства программных систем по обеспечению необходимого уровня безопасности [5] и по отсутствию недокументированных возможностей ("закладок") [4], которые могут быть использованы злоумышленником для несанкционированного доступа к данным. Кроме того, существует международный стандарт
Несмотря на то, что сертификация - процесс, следующий за верификацией, требования этих стандартов могут быть использованы и при тестировании системы. Так, стандарт [5] ФСТЭК, традиционно сокращенно называемый РД СВТ, выделяет следующие группы свойств программной системы, подлежащие проверке (некоторые группы свойств укрупнены для сокращения списка):
При разработке и верификации программной системы, которая будет подвергаться последующей сертификации, работы по сертификации должны включать в себя проверку всех перечисленных свойств.
Тестирование надежности и восстановления после сбоев. Для корректной работы системы в любой ситуации необходимо удостовериться в том, что она восстанавливает свою функциональность и продолжает корректно работать после любой проблемы, прервавшей ее работу. При тестировании восстановления после сбоев имитируются сбои оборудования или окружающего программного обеспечения либо сбои программной системы, вызванные внешними факторами. При анализе поведения системы в этом случае необходимо обращать внимание на два фактора - минимизацию потерь данных в результате сбоя и минимизацию времени между сбоем и продолжением нормального функционирования системы
Тестирование удобства использования. Отдельная группа нефункциональных требований - требования к удобству использования пользовательского интерфейса системы. Этот вид тестирования будет рассмотрен в следующей лекции.
В результате выполнения всех рассмотренных выше видов тестирования делается заключение о функциональности и свойствах системы, после чего узкие места системы дорабатываются до реализации необходимой функциональности или до достижения системой необходимых свойств.
При разработке массового ("коробочного",
При разработке заказного программного обеспечения фазу альфа- и бета-тестирования заменяют приемо-сдаточные испытания. Во время этих испытаний заказчик удостоверяется, что система работает в соответствии с его потребностями (как зафиксированными в техническом задании на систему, так и не зафиксированными). Заказчик может проводить такие испытания самостоятельно, выполняя заранее подготовленные тесты системы, либо проводить их совместно с представителями коллектива разработчиков. В этом случае тестовые примеры также готовятся разработчиками, например, на основе тестовых примеров, использовавшихся на этапе системного тестирования.
Завершаются приемо-сдаточные испытания либо подписанием акта приемки, либо выдачей заказчиком дополнительных требований к системе, которые должны быть исправлены до приемки системы. После устранения всех недостатков системы приемо-сдаточные испытания повторяются (возможно, по сокращенной программе). После успешного подписания акта система поступает в эксплуатацию заказчику.
Существует специальный вид программных систем, к свойствам которых предъявляются особые требованиями. Примером таких систем могут служить бортовые авиационные программные системы, для которых особое внимание уделяется вопросам безопасности, надежности и отказоустойчивости. Несмотря на то, что большая часть таких систем может быть отнесена к категории заказного программного обеспечения, для получения разрешения на установку системы на борт требуется получение сертификата на летную пригодность.
Таким образом, после проведения системного тестирования и приемо-сдаточных испытаний проводятся сертификационные испытания. Сертификация программного обеспечения - процесс установления и официального признания того, что разработка ПО проводилась в соответствии с определенными требованиями. В процессе сертификации происходит взаимодействие заявителя, сертифицирующего органа и наблюдательного органа.
Заявитель - это организация, подающая заявку в соответствующий сертифицирующий орган на получение сертификата (соответствия, качества, годности и т.п.) изделия.
Сертифицирующий орган - организация, которая рассматривает заявку заявителя о проведении сертификации ПО и либо самостоятельно, либо путем формирования специальной комиссии производит набор процедур, направленных на проведение процесса сертификации ПО заявителя.
Наблюдательный орган - комиссия специалистов, наблюдающих за процессами разработки заявителем сертифицируемой информационной системы и дающих заключение о соответствии данного процесса определенным требованиям, которое передается на рассмотрение в сертифицирующий орган. [34]
Основной объект проверки в ходе сертификационных испытаний - удовлетворяет ли процесс разработки программной системы регламенту и рекомендациям стандарта, на соответствие которому проводится сертификация. Такое соответствие определяется при помощи анализа жизненного цикла сертифицируемой системы и документов, создаваемых на ключевых его этапах. Весь процесс анализа и те свойства системы, которые подвергаются сертификации, описывается в плане сертификационных испытаний, который утверждается совместно заявителем и сертифицирующим органом.
В случае сертификации бортовой системы по стандарту DO-178B (или его аналогам КТ-178, JB-12 и т.п.) план дополнительно определяет уровень влияния отказа программной системы на безопасность полета (уровень отказобезопасности) по которому будет проводиться сертификация. Любые вопросы, которые возникают у сертифицирующего органа относительно содержания плана сертификационных испытаний, должны быть разрешены до начала самих испытаний.
Согласно требованиями DO-178B план сертификационных испытаний (план программных аспектов сертификации) должен включать:
В процессе самих сертификационных испытаний заявитель предоставляет свидетельства того, что процессы жизненного цикла программного обеспечения удовлетворяют планам программного обеспечения. Заявитель организует доступ сертифицирующего органа к данным жизненного цикла программного обеспечения. При этом минимальный перечень этих данных включает в себя:
Итоговое заключение по программному обеспечению является основным документом для демонстрации соответствия программного обеспечения Плану программных аспектов сертификации. Итоговое заключение должно включать:
Полный перечень данных жизненного цикла, которые могут понадобиться при сертификации, включает в себя:
Сертифицирующий орган устанавливает т.н. сертификационный базис для системы в ходе консультаций с заявителем. Сертификационный базис определяет конкретные правила вместе с любыми специальными условиями, которые могут дополнять опубликованные правила сертификации, регламентированные стандартом.
Для программного обеспечения установка базиса производится по рассмотрению итогового заключения о программном обеспечении и свидетельств соответствия.
В ходе сертификации сертифицирующий орган оценивает план программных аспектов сертификации на полноту и согласованность с критериями оценки отказобезопасности системы и другими данными жизненного цикла программного обеспечения. Если верны все данные жизненного цикла, являющиеся доказательством того, что в ходе проекта были активны все необходимые процессы разработки и верификации, то сертифицирующий орган выдает положительное решение о выдаче сертификата.
Сертификаты на программное обеспечение можно отнести к двум типам: сертификаты соответствия и сертификаты качества.
Сертификат на летную пригодность в рассматриваемом примере сочетает в себе свойства обоих типов сертификатов. С одной стороны, он удостоверяет, что разработанная система имеет определенный уровень качества реализации, а с другой - что процессы по ее разработке соответствуют международному авиационному отраслевому стандарту.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.