ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 296
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
, что наше программное обеспечение безопасно – значит оно не является таковым, и его нельзя использовать в критических системах. То же в полной мере относится и к надежному программному обеспечению – без доказательств надежности ПО к нему не должно быть доверия.
Авиационные стандарты требуют, чтобы для доказательства правильности любых действий были представлены артефакты, которые создаются в процессе осуществления этих действий. К артефактам относятся различные документы, данные, результаты тестирования, исходный код и другое – все, что производят процессы, входящие в жизненный цикл разработки. По ним судят о том, насколько успешно проходит или проходил тот или иной процесс, какие возникли проблемы, какие действия были предприняты по их устранению, как в результате эти проблемы были разрешены.
Стандарты DO178B/DO178С устанавливают определенные требования к артефактам жизненного цикла. Каждый артефакт должен принадлежать к одной из двух категорий в зависимости от их важности. Артефакты, принадлежащие к первой категории, должны иметь конфигурационную идентификацию, должно быть понятно, кто их создал и с каким другими артефактами они связаны, они должны быть закрыты от несанкционированного доступа и должна быть возможность их восстановления. К артефактам, принадлежащим ко второй категории, предъявляются более жесткие требования. Эти требования включают все требования первой категории, плюс дополнительные действия по мониторингу и ревизии их изменений, а также устанавливаются определенные требования к физическому носителю информации, на котором они располагаются.
Требования к артефактам, создаваемым в процессе разработки надежного ПО, и требования к операциям с ними должны быть определены в самом начале разработки. Сами разработчики должны решить, что необходимо включить в список этих требований. Базовыми требованиями для артефактов надежного ПО должно быть соответствие определенному стандарту и нахождение их под конфигурационным контролем.
Планирование
Говоря о планировании, вспоминаются достаточно верные слова персонажа Хита Леджера из кинофильма Кристофера Нолана “Темный рыцарь”: “Никто не паникует, если все идет согласно плану, если даже план чудовищен”.
Опыт разработки критического программного обеспечения утверждает, что невозможно создать надежного ПО, если нет детального плана действий. Планирование – это ключевой этап жизненного цикла разработки безопасного и надежно ПО.
Суть процесса разработки безопасного программного обеспечения можно выразить одной фразой: сначала мы создаем план, затем мы действуем в соответствии с этим планом, постоянно проверяя, что мы делаем именно то, что запланировали. Шаг в сторону – и мы теряем безопасность. Планы могут быть скорректированы, но и процедура изменения также должна проводиться по определенному плану.
Процесс планирования также является критически важным этапом разработки надежного программного обеспечения, и он должен быть обязательно включен в жизненный цикл разработки. Целями процесса планирования являются: определение всех составляющих жизненного цикла разработки ПО, выбор программного и аппаратного окружения, включая инструменты разработки, описание всех видов деятельности и создание планов для каждого из процесса, входящего в жизненный цикл, определение используемых стандартов, а также решение вопросов о том, как будут проходить ревизии и обновления всех созданных документов. Важное место в процессе планирования надежного ПО должно быть уделено анализу возможного возникновения ошибок и нештатных ситуаций, которые могут привести к аварийной ситуации, и должны быть предложены пути их устранения.
Стандарты DO178B/DO178С требуют, чтобы перед началом разработки были созданы следующие планы:
План разработки содержит:
План верификации содержит в себе все, что касается процедур верификации: какие методы верификации должны быть произведены, как и когда они должны проходить, кто в них должен принимать участие.
Главным вопрос, на который отвечает план обеспечения качества – это то, какие действия будут проводиться для обеспечения качества. К этим действиям относятся различные аудиты, инспекции и мониторинги качества.
План управления конфигурации говорит о том, как будут идентифицироваться, храниться и контролироваться все данные, создаваемые за время жизненного цикла разработки ПО, какие инструменты будут для этого использоваться.
Для сертификации ПО согласно DO178B/DO178С, кроме перечисленных выше планов, сертификационному органу нужно еще представить План Программных Аспектов Сертификации (Plan for Software Aspects of Certification). Этот план, по сути, является контрактом между заявителем и сертификационным органом, и он должен быть согласован перед началом всего процесса. План содержит информацию о том, как будет проходить весь процесс разработки и взаимодействия с сертификационной властью. План также включает в себя обзор системы, где будет использоваться ПО, обзор самого разрабатываемого ПО, информацию о том, какие действия для безопасной работы ПО будут предприняты, описание жизненного цикла разработки, список создаваемых артефактов, производственный график и другое.
Из требований авиационных стандартов можно заключить, что если вы используете методологии разработки, не включающие процесса планирования, например, Гибкие Методологии Разработки, такие как Экстремальное Программирование, DSDM и другие, вы не можете создать ПО, которое годится для использования в критических системах. На данный момент существует множество различных предложений о том, как адаптировать Гибкие Методологии Разработки так, чтобы они удовлетворяли требованиям безопасного программного обеспечения. Но какие-либо реальные воплощения этих идей на практике для разработки и сертификации авиационного программного обеспечения автору этой статьи неизвестны. Процесс сертификации ПО в авиации требует больших затрат, и кажется маловероятным, что какая-нибудь компания рискнет своими ресурсами, отойдя от принятой практики разработки ПО, чтобы проверить, работают ли Гибкие Методологии Разработки в ее индустрии.
Вопрос о том можно ли создать надежное ПО, используя Гибкие Методологии Разработки, для систем, не связанных с безопасностью, также требует дополнительного исследования.
Использование стандартов
Чем большее число стандартов используется в процессе разработки программного обеспечения, тем лучше. Стандарты концентрируют в себе лучший практический опыт. Стандартизация документов может сделать эти документы более понятными и лучше воспринимаемыми другими людьми, а также позволяет избежать некоторых типов ошибок.
Согласно требованиям авиационной сертификации, в процессе разработки ПО должны быть использованы как минимум три стандарта:
Стандарт требований должен описывать методы, правила и инструменты, применяемые для разработки требований, их формат и нотацию.
В стандарте дизайна содержатся правила, регламентирующие архитектуру программного обеспечения, указываются приемлемые и неприемлемые методы дизайна, описываются принимаемые ограничения, например, запрет на использование рекурсии или максимальная вложенность вызовов и другое.
Стандарт кода регламентирует все, что касается исходного кода: ссылки на описания используемого языка программирования и его синтаксиса, описание ограничений, накладываемых на этот язык, описание желательных и нежелательных конструкций языка, соглашение о наименовании переменных и функций, соглашение о том, как должен выглядеть код и любые другие правила, напрямую касающиеся написания кода.
Какие стандарты использовать, определяется в процессе планирования. Могут применяться как самостоятельно разработанные, так и общеизвестные, широко используемые стандарты. Они задают правила, которые должны действовать на всем протяжении жизненного цикла. Например, если в стандарте кодирования написано, что нельзя вставлять комментарии в код, а все комментарии должны быть сконцентрированы в определенном документе, то, хотя это правило можно считать спорным, все комментарии из кода должны быть удалены. Несоответствие стандарту является серьезной ошибкой: либо оно должно быть устранено, либо необходимо поменять сам стандарт.
Разработка надежного ПО также не может обойтись без использования стандартов кодирования, требований и дизайна. То, какие будут использованы стандарты, и что они в себя будут включать, должно быть решено в процессе планирования.
Создание качественных требований
Без требований к выполняемой функции нельзя создать ПО, неясные и размытые требования никогда не позволят создать качественное ПО. Требования – это фундамент разработки. От того, насколько хорошо они написаны, зависит то, насколько надежным будет программное обеспечение. Процесс непосредственной разработки ПО должен начинаться с процесса создания требований и вестись в соответствии с планом, определенным в процессе планирования.
При разработке критического ПО требования принято разделять на два типа – высокоуровневые и низкоуровневые требования. Требования, относящиеся к первому типу, отвечают на вопрос "что мы собираемся делать", а требования ко второму типу отвечают на вопрос "как мы это будем делать". Высокоуровневые требования создаются непосредственно из системных требований и закладываемой функциональности ПО. На основании этих требованный строится дизайн и архитектура ПО. Уже на основе планируемого дизайна создаются низкоуровневые требования. Они адресуются непосредственно к коду. На основе низкоуровневых требований создается исходный код.
Требования считаются качественными, если они конкретны и корректны, соответствуют функциональности ПО, если их можно верифицировать, если они уникальны, последовательны и непротиворечивы. Требования могут разбиваться на подуровни для удобства внесения в них изменений и трассировки.
Для автоматизации и унификации процесса создания и отслеживания требований существует большое количество различных платных и бесплатных программ. Использование инструментов для работы с требованиями, как правило, положительно сказывается на качестве разрабатываемого ПО.
Разделение процедуры проверки на два независимых процесса
Для создания критического ПО проверка на правильность должна быть разделена на две независимые проверки – верификацию и валидацию. Несмотря на схожесть терминов, процесс верификации (verification) и процесс валидации (validation) имеют совсем разные смыслы. Верификация относятся к процессу контроля качества, она проверяет то, что мы разрабатываем ПО правильно, в соответствии с установленными планами и нормами. Валидация относится к процессу обеспечения качества, она проверяет, что разрабатываемое нами ПО выполняет свою намеченную функцию. Другими словами, валидация задает вопрос: "Мы делаем правильную вещь?", а верификация: "Мы делаем ее правильно?". Во время верификации для нас неважно, какой программный продукт мы создаем, и какие функции он выполняет, важно, что мы делаем его правильно. А все, что относится к проверке функциональности ПО, ложится на валидацию.
И валидация, и верификация необходимы при создании надежного ПО. Нарушение любого из этих принципов может привести к потере надежности. Они не должны проходить одновременно. Сначала необходимо убедиться, что мы делаем то, что нам нужно, а уже затем проверять, что процесс создания программного обеспечения идет в соответствии с намеченными планами и целями.
Трассировка
Ничего не создается само по себе: ни требование, ни код, ни тестовая процедура – это один из базовых принципов разработки надежного и безопасного кода, называемый трассировкой.
Трассировка – это доказательство связи между элементами. Она показывает связь между различными процессами, между результатами и их порождающим процессом, между требованием и его реализацией, между рапортом об ошибке и самой ошибкой, и так далее. Трассировка позволяет понять, что из чего вышло и куда в результате пришло.
Авиационные стандарты говорят: вы должны суметь проследить цепочку от результатов тестирования к самим тестам, от тестов к бинарному коду, от бинарного кода к исходному коду, от исходного кода к низкоуровневым требованиям, от низкоуровневых требований к дизайну и архитектуре, от дизайна и архитектуры к высокоуровневым требованиям, от высокоуровневых требований к системным требованиям и в обратную сторону. Трассировка должна быть двухсторонней.
Авиационные стандарты требуют, чтобы для доказательства правильности любых действий были представлены артефакты, которые создаются в процессе осуществления этих действий. К артефактам относятся различные документы, данные, результаты тестирования, исходный код и другое – все, что производят процессы, входящие в жизненный цикл разработки. По ним судят о том, насколько успешно проходит или проходил тот или иной процесс, какие возникли проблемы, какие действия были предприняты по их устранению, как в результате эти проблемы были разрешены.
Стандарты DO178B/DO178С устанавливают определенные требования к артефактам жизненного цикла. Каждый артефакт должен принадлежать к одной из двух категорий в зависимости от их важности. Артефакты, принадлежащие к первой категории, должны иметь конфигурационную идентификацию, должно быть понятно, кто их создал и с каким другими артефактами они связаны, они должны быть закрыты от несанкционированного доступа и должна быть возможность их восстановления. К артефактам, принадлежащим ко второй категории, предъявляются более жесткие требования. Эти требования включают все требования первой категории, плюс дополнительные действия по мониторингу и ревизии их изменений, а также устанавливаются определенные требования к физическому носителю информации, на котором они располагаются.
Требования к артефактам, создаваемым в процессе разработки надежного ПО, и требования к операциям с ними должны быть определены в самом начале разработки. Сами разработчики должны решить, что необходимо включить в список этих требований. Базовыми требованиями для артефактов надежного ПО должно быть соответствие определенному стандарту и нахождение их под конфигурационным контролем.
Планирование
Говоря о планировании, вспоминаются достаточно верные слова персонажа Хита Леджера из кинофильма Кристофера Нолана “Темный рыцарь”: “Никто не паникует, если все идет согласно плану, если даже план чудовищен”.
Опыт разработки критического программного обеспечения утверждает, что невозможно создать надежного ПО, если нет детального плана действий. Планирование – это ключевой этап жизненного цикла разработки безопасного и надежно ПО.
Суть процесса разработки безопасного программного обеспечения можно выразить одной фразой: сначала мы создаем план, затем мы действуем в соответствии с этим планом, постоянно проверяя, что мы делаем именно то, что запланировали. Шаг в сторону – и мы теряем безопасность. Планы могут быть скорректированы, но и процедура изменения также должна проводиться по определенному плану.
Процесс планирования также является критически важным этапом разработки надежного программного обеспечения, и он должен быть обязательно включен в жизненный цикл разработки. Целями процесса планирования являются: определение всех составляющих жизненного цикла разработки ПО, выбор программного и аппаратного окружения, включая инструменты разработки, описание всех видов деятельности и создание планов для каждого из процесса, входящего в жизненный цикл, определение используемых стандартов, а также решение вопросов о том, как будут проходить ревизии и обновления всех созданных документов. Важное место в процессе планирования надежного ПО должно быть уделено анализу возможного возникновения ошибок и нештатных ситуаций, которые могут привести к аварийной ситуации, и должны быть предложены пути их устранения.
Стандарты DO178B/DO178С требуют, чтобы перед началом разработки были созданы следующие планы:
-
План разработки. -
План верификации. -
План обеспечения качества. -
План управления конфигурации.
План разработки содержит:
-
описание всего жизненного цикла разработки ПО, -
ссылки на все используемые стандарты, -
полное описание производственного окружения, такого как аппаратное обеспечение, компилятор, компоновщик, инструменты разработки и дизайна.
План верификации содержит в себе все, что касается процедур верификации: какие методы верификации должны быть произведены, как и когда они должны проходить, кто в них должен принимать участие.
Главным вопрос, на который отвечает план обеспечения качества – это то, какие действия будут проводиться для обеспечения качества. К этим действиям относятся различные аудиты, инспекции и мониторинги качества.
План управления конфигурации говорит о том, как будут идентифицироваться, храниться и контролироваться все данные, создаваемые за время жизненного цикла разработки ПО, какие инструменты будут для этого использоваться.
Для сертификации ПО согласно DO178B/DO178С, кроме перечисленных выше планов, сертификационному органу нужно еще представить План Программных Аспектов Сертификации (Plan for Software Aspects of Certification). Этот план, по сути, является контрактом между заявителем и сертификационным органом, и он должен быть согласован перед началом всего процесса. План содержит информацию о том, как будет проходить весь процесс разработки и взаимодействия с сертификационной властью. План также включает в себя обзор системы, где будет использоваться ПО, обзор самого разрабатываемого ПО, информацию о том, какие действия для безопасной работы ПО будут предприняты, описание жизненного цикла разработки, список создаваемых артефактов, производственный график и другое.
Из требований авиационных стандартов можно заключить, что если вы используете методологии разработки, не включающие процесса планирования, например, Гибкие Методологии Разработки, такие как Экстремальное Программирование, DSDM и другие, вы не можете создать ПО, которое годится для использования в критических системах. На данный момент существует множество различных предложений о том, как адаптировать Гибкие Методологии Разработки так, чтобы они удовлетворяли требованиям безопасного программного обеспечения. Но какие-либо реальные воплощения этих идей на практике для разработки и сертификации авиационного программного обеспечения автору этой статьи неизвестны. Процесс сертификации ПО в авиации требует больших затрат, и кажется маловероятным, что какая-нибудь компания рискнет своими ресурсами, отойдя от принятой практики разработки ПО, чтобы проверить, работают ли Гибкие Методологии Разработки в ее индустрии.
Вопрос о том можно ли создать надежное ПО, используя Гибкие Методологии Разработки, для систем, не связанных с безопасностью, также требует дополнительного исследования.
Использование стандартов
Чем большее число стандартов используется в процессе разработки программного обеспечения, тем лучше. Стандарты концентрируют в себе лучший практический опыт. Стандартизация документов может сделать эти документы более понятными и лучше воспринимаемыми другими людьми, а также позволяет избежать некоторых типов ошибок.
Согласно требованиям авиационной сертификации, в процессе разработки ПО должны быть использованы как минимум три стандарта:
-
Стандарт требований. -
Стандарт дизайна. -
Стандарт кодирования.
Стандарт требований должен описывать методы, правила и инструменты, применяемые для разработки требований, их формат и нотацию.
В стандарте дизайна содержатся правила, регламентирующие архитектуру программного обеспечения, указываются приемлемые и неприемлемые методы дизайна, описываются принимаемые ограничения, например, запрет на использование рекурсии или максимальная вложенность вызовов и другое.
Стандарт кода регламентирует все, что касается исходного кода: ссылки на описания используемого языка программирования и его синтаксиса, описание ограничений, накладываемых на этот язык, описание желательных и нежелательных конструкций языка, соглашение о наименовании переменных и функций, соглашение о том, как должен выглядеть код и любые другие правила, напрямую касающиеся написания кода.
Какие стандарты использовать, определяется в процессе планирования. Могут применяться как самостоятельно разработанные, так и общеизвестные, широко используемые стандарты. Они задают правила, которые должны действовать на всем протяжении жизненного цикла. Например, если в стандарте кодирования написано, что нельзя вставлять комментарии в код, а все комментарии должны быть сконцентрированы в определенном документе, то, хотя это правило можно считать спорным, все комментарии из кода должны быть удалены. Несоответствие стандарту является серьезной ошибкой: либо оно должно быть устранено, либо необходимо поменять сам стандарт.
Разработка надежного ПО также не может обойтись без использования стандартов кодирования, требований и дизайна. То, какие будут использованы стандарты, и что они в себя будут включать, должно быть решено в процессе планирования.
Создание качественных требований
Без требований к выполняемой функции нельзя создать ПО, неясные и размытые требования никогда не позволят создать качественное ПО. Требования – это фундамент разработки. От того, насколько хорошо они написаны, зависит то, насколько надежным будет программное обеспечение. Процесс непосредственной разработки ПО должен начинаться с процесса создания требований и вестись в соответствии с планом, определенным в процессе планирования.
При разработке критического ПО требования принято разделять на два типа – высокоуровневые и низкоуровневые требования. Требования, относящиеся к первому типу, отвечают на вопрос "что мы собираемся делать", а требования ко второму типу отвечают на вопрос "как мы это будем делать". Высокоуровневые требования создаются непосредственно из системных требований и закладываемой функциональности ПО. На основании этих требованный строится дизайн и архитектура ПО. Уже на основе планируемого дизайна создаются низкоуровневые требования. Они адресуются непосредственно к коду. На основе низкоуровневых требований создается исходный код.
Требования считаются качественными, если они конкретны и корректны, соответствуют функциональности ПО, если их можно верифицировать, если они уникальны, последовательны и непротиворечивы. Требования могут разбиваться на подуровни для удобства внесения в них изменений и трассировки.
Для автоматизации и унификации процесса создания и отслеживания требований существует большое количество различных платных и бесплатных программ. Использование инструментов для работы с требованиями, как правило, положительно сказывается на качестве разрабатываемого ПО.
Разделение процедуры проверки на два независимых процесса
Для создания критического ПО проверка на правильность должна быть разделена на две независимые проверки – верификацию и валидацию. Несмотря на схожесть терминов, процесс верификации (verification) и процесс валидации (validation) имеют совсем разные смыслы. Верификация относятся к процессу контроля качества, она проверяет то, что мы разрабатываем ПО правильно, в соответствии с установленными планами и нормами. Валидация относится к процессу обеспечения качества, она проверяет, что разрабатываемое нами ПО выполняет свою намеченную функцию. Другими словами, валидация задает вопрос: "Мы делаем правильную вещь?", а верификация: "Мы делаем ее правильно?". Во время верификации для нас неважно, какой программный продукт мы создаем, и какие функции он выполняет, важно, что мы делаем его правильно. А все, что относится к проверке функциональности ПО, ложится на валидацию.
И валидация, и верификация необходимы при создании надежного ПО. Нарушение любого из этих принципов может привести к потере надежности. Они не должны проходить одновременно. Сначала необходимо убедиться, что мы делаем то, что нам нужно, а уже затем проверять, что процесс создания программного обеспечения идет в соответствии с намеченными планами и целями.
Трассировка
Ничего не создается само по себе: ни требование, ни код, ни тестовая процедура – это один из базовых принципов разработки надежного и безопасного кода, называемый трассировкой.
Трассировка – это доказательство связи между элементами. Она показывает связь между различными процессами, между результатами и их порождающим процессом, между требованием и его реализацией, между рапортом об ошибке и самой ошибкой, и так далее. Трассировка позволяет понять, что из чего вышло и куда в результате пришло.
Авиационные стандарты говорят: вы должны суметь проследить цепочку от результатов тестирования к самим тестам, от тестов к бинарному коду, от бинарного кода к исходному коду, от исходного кода к низкоуровневым требованиям, от низкоуровневых требований к дизайну и архитектуре, от дизайна и архитектуры к высокоуровневым требованиям, от высокоуровневых требований к системным требованиям и в обратную сторону. Трассировка должна быть двухсторонней.