Сообщений 29 
Оценка 90
[+1/-1]
Оценить 
| Сообщений 29 Оценка 90
[+1/-1]
Оценить
|
При выборе того или иного промышленного товара мы, помимо цены, прежде всего обращаем внимание на торговую марку, под которой этот продукт продается. Торговая марка продукта в большинстве случаев может дать нам некоторое представление о его качестве. Ставя на продукте свое имя, или имя принадлежащего ей бренда, компания декларирует то, что этот продукт был создан в соответствии с некоторым технологическим процессом, используемым данной компанией. Чем больше усилий и средств компания вкладывает в совершенствование этого процесса, тем больше у компании конкурентных преимуществ на рынке, поскольку это позволяет ей не только уменьшить стоимость продукта, но и улучшить его качество, а это напрямую влияет на репутацию компании. Таким образом, можно утверждать, что качество продукта напрямую зависит от совершенства процесса, его создавшего. Выбирая продукт определенной марки, мы по сути делаем выбор в пользу того или иного технологического процесса, в результате которого этот продукт был произведен.
В индустрии программного обеспечения (ПО) давно уже заметили, что хаотичное и бессистемное производство никогда не позволяет выпустить продукт, который будет пользоваться большой популярностью. И прежде всего это связано с проблемами качества и надежности такого продукта. Поэтому было предложено множество подходов к производству программного обеспечения, регламентирующих все аспекты его создания. Все эти подходы были реализованы в большом количестве различных стандартов. На данный момент существует множество стандартов, как общих, так и отраслевых, напрямую касающихся разработки качественного и надежного программного обеспечения. Но возникает вопрос: действительно ли все эти стандарты работают? Судя по тому, что на рынке сейчас много некачественного программного обеспечения, и тем не менее декларирующего приверженность тому или иному стандарту, можно с уверенностью сказать, что точно не все. Тогда возникает другой вопрос: если я хочу разрабатывать надежное и качественное программное обеспечение, как из всего многообразия существующих стандартов выбрать тот, следуя рекомендациям которого мне это действительно удастся?
Наверно, наилучшим решением при выборе подхода для разработки надежного и качественного программного обеспечения было бы обращение к опыту индустрии, где надежность и безопасность являются основными критериями оценки продукта. Это, прежде всего, авиация. В ней накоплен большой опыт разработки, сертификации и использования критического программного обеспечения, от правильной работы которого часто зависит жизнь людей.
В этой индустрии есть единый стандарт программного обеспечения, без соответствия которому ни одна программа не может быть установлена на борту летательного аппарата. Это стандарт RTCA DO178B и его новая редакция – DO178С, вышедшая в начале 2012. Появление в авиации стандарта для безопасности программного обеспечения связано с изменением в понимании его важности. На определенном этапе развития авиационной индустрии программное обеспечение перестало быть чем-то несущественным и второстепенным по отношению к аппаратному обеспечению. Выход этого стандарта сопровождался большими трудностями, поскольку не все в авиационной индустрии поддержали его. И, тем не менее, он произвел революционные изменения в понимании того, что такое безопасное ПО и как его нужно разрабатывать.
Целью данной статьи не является подробное описание стандартов DO178B/DO178С или же процесса сертификации программного обеспечения на соответствие этим стандартам (материалы по этой теме можно найти на сайте RTCA [1] или [2]). Сам процесс сертификации программного обеспечения согласно этим стандартам – это достаточно сложная, трудоемкая и дорогостоящая процедура, и ее разбор и описание выходит за рамки данной работы, тем более что вряд ли она понадобится разработчикам, которые не собираются создавать критическое программное обеспечение. Целью же данной статьи является попытка обобщения некоторых принципов, заложенных в стандартах DO178B/DO178С, которые можно использовать для разработки обычного (некритического) программного обеспечения, чтобы улучшить его качество и надежность.
Когда первый раз сталкиваешься со стандартами DO178B/DO178С, возникает недоумение – как вообще можно разработать надежное и безопасное программное обеспечение, исходя из достаточно общих рекомендаций, сведенных в большое количество различных списков и таблиц. У многих людей впервые знакомящимися с этими стандартами возникает такое непонимание.
И, тем не менее, основная их идея достаточно проста: невозможно проверить каждый байт кода, невозможно со стопроцентной уверенностью утверждать, что взаимодействие отдельных частей ПО не приведет к катастрофе. Но, опираясь на свой предыдущий опыт, мы можем предложить вам некоторый процесс создания программного обеспечения, который, как мы предполагаем, позволит вам сделать безопасный код. Этот процесс состоит из определенного набора подпроцессов, каждый из которых имеет свои установленные процедуры и цели, и если вы следуете этим процедурам, то надежность вашего ПО повысится настолько, что его можно будет использовать в критических системах, связанных с жизнью людей. Но гарантии того, что даже если вы соблюдаете все эти рекомендации, вы получите абсолютно безопасный код – нет. Разработчики DO178B/DO178С утверждают лишь, что безопасность кода должна существенно возрасти.
В качестве хорошей метафоры, объясняющей этот подход, чаще всего приводят метафору вождения автомобиля: если вы водите машину, не превышая установленной скорости и соблюдая базовые правила движения, если вы пристегнуты и не находитесь в состоянии опьянения, то ваш уровень безопасности соответствует базовому уровню. Но стопроцентной гарантии того, что, даже следуя всем этим требованиям, вы не попадете в аварию – нет. Единственный способ обеспечения такой безопасности – это отказ от вождения автомобиля.
То же самое и для программного обеспечения: мы устанавливаем некоторые уровни контроля, мы доказываем, что следуем им, и надеемся, что безопасность нашего программного в связи с этим улучшится.
Стандарты DO178B/DO178С не описывают детально весь процесс разработки. Они просто определяют некоторый набор процессов, которые обязательно должны в него войти, и устанавливают их цели и решаемые задачи. Да и вообще не очень ясно, как можно написать документ, учитывающий все возможные варианты процесса разработки, которые бы подходил для любой компании. Фирмы разные, процессы разработки у них тоже разные, и если опираться только на один вариант, то фирмы будут вынуждены либо полностью перестраивать свой процесс создания ПО, а это многомиллионные затраты, либо заказывать ПО только у ограниченного круга компаний, а это может привести к монополии на авиационное ПО. Поэтому стандарты DO178B/DO178С содержат только минимально необходимый набор процессов, без которых нельзя создать безопасное ПО.
Опираясь на опыт использования DO178B, можно с уверенность сказать, что этот подход работает. Он доказал свою эффективность для авиационного программного обеспечения, и последовавшие за ним стандарты, уже относящиеся к аппаратному обеспечению (например стандарты сертификации сложной авионики), также стали его использовать.
Прежде всего необходимо сказать, что в данной работе подразумевается под термином «надежное программное обеспечение». Надежное ПО – это программное обеспечение, способное с высокой вероятностью выполнять свою целевую функцию в заданных условиях. Под условиями понимаются программно-аппаратное окружение ПО, заданное время работы, различные ограничения и требования, накладываемые на работу ПО. Надежное программное обеспечение должно обладать свойствами: безотказности, работоспособности, устойчивости к ошибкам.
Если к надежному программному обеспечению предъявляется еще одно требование – безопасная работа, под которым понимается невозможность ПО быть причиной или участвовать в причинении человеку физического вреда, то такое программное обеспечение будем называть «безопасным» или «критическим», а программно-аппаратные системы, в которых оно работает – «критическими системами». Рекомендации стандартов DO178B/DO178С непосредственно относятся к этому программному обеспечению. Для критического программного обеспечения также задаются определенные значения вероятности возникновения отказов, которые оно обязано соблюдать. Любое другое программное обеспечение, для которого требование безопасности не выдвигается, будем назвать «обычным ПО» или «некритическим ПО».
Далее будет часто использоваться термин "жизненный цикл разработки программного обеспечения". Под ним подразумевается часть жизненного цикла программного обеспечения, которая не включает в себя этапы поддержки и обслуживания.
Набор приведенных ниже принципов описывает черты процесса создания ПО, без которых, по мнению автора, нельзя обойтись при разработке надежного ПО. Все они построены на базе рекомендаций, приведенных в авиационных стандартах DO178B/DO178С, и опыта автора по сертификации ПО, согласно этим стандартам. В отличие от принципов разработки критического ПО, приведенные ниже принципы, как правило, гораздо менее жесткие, чем те, что устанавливают авиационные стандарты, поскольку речь идет о надежном ПО, а не о том, которое может причинить вред здоровью человека. Для каждого принципа дается пояснение что под ним подразумевается и то как его можно применить для разработки надежного программного обеспечения.
Невозможно разработать качественный программный продукт, если процесс его создания является неупорядоченным и бессистемным. Только в результате строго регламентированного процесса можно создать что-то по-настоящему стоящее – утверждают авиационные стандарты. Создание такого процесса является первым шагом в сторону качественного программного обеспечения.
Любая разработка ПО должна начинаться с определения того, что из себя будет представлять весь процесс разработки, какой модели жизненного цикла он будет придерживаться, какие основные процессы должны в него входить. Выбранная модель жизненного цикла позволит упорядочить разработку путем установки всех его основных этапов. Для каждого этапа разработки необходимо наметить цели, а также установить способы их достижения. Выбранную модель жизненного цикла нужно строго соблюдать, и она не может быть изменена в процессе разработки. Смена модели разработки отбрасывает проект к самому его началу.
На сегодняшний день существует множество различных моделей жизненного цикла и, в принципе, почти все они подходят для разработки надежного и качественного ПО. Нельзя со строгой определенностью сказать, что в результате следования вот этой модели программный продукт получается более надежным, нежели в результате разработки согласно той. Для разработки надежного ПО главное – это выполнение установленных целей и задач по обеспечению надежности и строгое соблюдение всех правил, диктуемых моделью. Поэтому нет особого смысла для получения более надежного ПО переходить на другую модель, если есть хороший опыт использования определенного типа модели.
Авиационные стандарты не требуют использования какой-то определенной модели жизненного цикла разработки, но они устанавливают набор процессов, которые обязательно должны в него входить. Для каждого из этих процессов они определяют цели и задачи, которые должны быть выполнены, а также виды деятельности, которые должны быть осуществлены. Для разработки бортового программного обеспечения часто используют V-модель жизненного цикла, спиральную модель разработки или их гибридные варианты.
Ключевым отличием разработки критического программного обеспечения от разработки обычного (не связанного с безопасностью) является частичное смещение приоритетов. Для некритического программного обеспечения главными являются требования, установленные его заказчиком или требования, диктуемые его намеченной функцией. Для критического программного обеспечения его безопасная работа более важна, чем функциональность. Поэтому любые действия каждого из процессов, участвующих в работе программного обеспечения, должны быть оценены с точки зрения безопасности.
Для надежного программного обеспечения требования надежности должны быть, по крайней мере, на одном уровне с требованиями к его функциональности. Если мы хотим, чтобы наше программное обеспечение было надежным, даже если мы не разрабатываем критическое ПО, то об этом поздно вспоминать в момент, когда уже начато тестирование. Каждый разработанный план, каждый вид деятельности любого из процессов, входящих в жизненный цикл разработки, каждое функциональное требование и тестовая функция, должны быть рассмотрены через призму надежности. Мы постоянно должны задаваться вопросами: наши действия повышают или понижают надежность ПО; если понижают, то как этого избежать, как сделать так, чтобы надежность не пострадала, что еще можно сделать для стабильной работы, достаточно ли мы приложили усилий, чтобы это правильно работало.
Если во время процесса разработки надежного ПО возникла необходимость изменить или дополнить функциональные возможности программного обеспечения, то должна быть произведена оценка того, как эти изменения повлияет на надежность работы всего программного продукта. Если такое влияние обнаруживается, все действия по обеспечению надежности, в том числе планы, требования, тесты, должны быть пересмотрены, чтобы учесть это влияние. Было бы хорошей идеей во время процесса планирования описать, какие функциональные требования к программному обеспечению являются жестко фиксированными, так что при их смене процесс разработки должен будет начаться сначала, а какие могут быть изменены без рестарта этого процесса.
Ничего не берется на веру – все нужно доказать. Этот принцип – один из основополагающих при разработке надежного и безопасного программного обеспечения. Стандарты DO178B/DO178С однозначно говорят, что если мы не можем доказать, что наше программное обеспечение безопасно – значит оно не является таковым, и его нельзя использовать в критических системах. То же в полной мере относится и к надежному программному обеспечению – без доказательств надежности ПО к нему не должно быть доверия.
Авиационные стандарты требуют, чтобы для доказательства правильности любых действий были представлены артефакты, которые создаются в процессе осуществления этих действий. К артефактам относятся различные документы, данные, результаты тестирования, исходный код и другое – все, что производят процессы, входящие в жизненный цикл разработки. По ним судят о том, насколько успешно проходит или проходил тот или иной процесс, какие возникли проблемы, какие действия были предприняты по их устранению, как в результате эти проблемы были разрешены.
Стандарты DO178B/DO178С устанавливают определенные требования к артефактам жизненного цикла. Каждый артефакт должен принадлежать к одной из двух категорий в зависимости от их важности. Артефакты, принадлежащие к первой категории, должны иметь конфигурационную идентификацию, должно быть понятно, кто их создал и с каким другими артефактами они связаны, они должны быть закрыты от несанкционированного доступа и должна быть возможность их восстановления. К артефактам, принадлежащим ко второй категории, предъявляются более жесткие требования. Эти требования включают все требования первой категории, плюс дополнительные действия по мониторингу и ревизии их изменений, а также устанавливаются определенные требования к физическому носителю информации, на котором они располагаются.
Требования к артефактам, создаваемым в процессе разработки надежного ПО, и требования к операциям с ними должны быть определены в самом начале разработки. Сами разработчики должны решить, что необходимо включить в список этих требований. Базовыми требованиями для артефактов надежного ПО должно быть соответствие определенному стандарту и нахождение их под конфигурационным контролем.
Говоря о планировании, вспоминаются достаточно верные слова персонажа Хита Леджера из кинофильма Кристофера Нолана “Темный рыцарь”: “Никто не паникует, если все идет согласно плану, если даже план чудовищен”.
Опыт разработки критического программного обеспечения утверждает, что невозможно создать надежного ПО, если нет детального плана действий. Планирование – это ключевой этап жизненного цикла разработки безопасного и надежно ПО.
Суть процесса разработки безопасного программного обеспечения можно выразить одной фразой: сначала мы создаем план, затем мы действуем в соответствии с этим планом, постоянно проверяя, что мы делаем именно то, что запланировали. Шаг в сторону – и мы теряем безопасность. Планы могут быть скорректированы, но и процедура изменения также должна проводиться по определенному плану.
Процесс планирования также является критически важным этапом разработки надежного программного обеспечения, и он должен быть обязательно включен в жизненный цикл разработки. Целями процесса планирования являются: определение всех составляющих жизненного цикла разработки ПО, выбор программного и аппаратного окружения, включая инструменты разработки, описание всех видов деятельности и создание планов для каждого из процесса, входящего в жизненный цикл, определение используемых стандартов, а также решение вопросов о том, как будут проходить ревизии и обновления всех созданных документов. Важное место в процессе планирования надежного ПО должно быть уделено анализу возможного возникновения ошибок и нештатных ситуаций, которые могут привести к аварийной ситуации, и должны быть предложены пути их устранения.
Стандарты DO178B/DO178С требуют, чтобы перед началом разработки были созданы следующие планы:
План разработки содержит:
План верификации содержит в себе все, что касается процедур верификации: какие методы верификации должны быть произведены, как и когда они должны проходить, кто в них должен принимать участие.
Главным вопрос, на который отвечает план обеспечения качества – это то, какие действия будут проводиться для обеспечения качества. К этим действиям относятся различные аудиты, инспекции и мониторинги качества.
План управления конфигурации говорит о том, как будут идентифицироваться, храниться и контролироваться все данные, создаваемые за время жизненного цикла разработки ПО, какие инструменты будут для этого использоваться.
Для сертификации ПО согласно DO178B/DO178С, кроме перечисленных выше планов, сертификационному органу нужно еще представить План Программных Аспектов Сертификации (Plan for Software Aspects of Certification). Этот план, по сути, является контрактом между заявителем и сертификационным органом, и он должен быть согласован перед началом всего процесса. План содержит информацию о том, как будет проходить весь процесс разработки и взаимодействия с сертификационной властью. План также включает в себя обзор системы, где будет использоваться ПО, обзор самого разрабатываемого ПО, информацию о том, какие действия для безопасной работы ПО будут предприняты, описание жизненного цикла разработки, список создаваемых артефактов, производственный график и другое.
Из требований авиационных стандартов можно заключить, что если вы используете методологии разработки, не включающие процесса планирования, например, Гибкие Методологии Разработки, такие как Экстремальное Программирование, DSDM и другие, вы не можете создать ПО, которое годится для использования в критических системах. На данный момент существует множество различных предложений о том, как адаптировать Гибкие Методологии Разработки так, чтобы они удовлетворяли требованиям безопасного программного обеспечения. Но какие-либо реальные воплощения этих идей на практике для разработки и сертификации авиационного программного обеспечения автору этой статьи неизвестны. Процесс сертификации ПО в авиации требует больших затрат, и кажется маловероятным, что какая-нибудь компания рискнет своими ресурсами, отойдя от принятой практики разработки ПО, чтобы проверить, работают ли Гибкие Методологии Разработки в ее индустрии.
Вопрос о том можно ли создать надежное ПО, используя Гибкие Методологии Разработки, для систем, не связанных с безопасностью, также требует дополнительного исследования.
Чем большее число стандартов используется в процессе разработки программного обеспечения, тем лучше. Стандарты концентрируют в себе лучший практический опыт. Стандартизация документов может сделать эти документы более понятными и лучше воспринимаемыми другими людьми, а также позволяет избежать некоторых типов ошибок.
Согласно требованиям авиационной сертификации, в процессе разработки ПО должны быть использованы как минимум три стандарта:
Стандарт требований должен описывать методы, правила и инструменты, применяемые для разработки требований, их формат и нотацию.
В стандарте дизайна содержатся правила, регламентирующие архитектуру программного обеспечения, указываются приемлемые и неприемлемые методы дизайна, описываются принимаемые ограничения, например, запрет на использование рекурсии или максимальная вложенность вызовов и другое.
Стандарт кода регламентирует все, что касается исходного кода: ссылки на описания используемого языка программирования и его синтаксиса, описание ограничений, накладываемых на этот язык, описание желательных и нежелательных конструкций языка, соглашение о наименовании переменных и функций, соглашение о том, как должен выглядеть код и любые другие правила, напрямую касающиеся написания кода.
Какие стандарты использовать, определяется в процессе планирования. Могут применяться как самостоятельно разработанные, так и общеизвестные, широко используемые стандарты. Они задают правила, которые должны действовать на всем протяжении жизненного цикла. Например, если в стандарте кодирования написано, что нельзя вставлять комментарии в код, а все комментарии должны быть сконцентрированы в определенном документе, то, хотя это правило можно считать спорным, все комментарии из кода должны быть удалены. Несоответствие стандарту является серьезной ошибкой: либо оно должно быть устранено, либо необходимо поменять сам стандарт.
Разработка надежного ПО также не может обойтись без использования стандартов кодирования, требований и дизайна. То, какие будут использованы стандарты, и что они в себя будут включать, должно быть решено в процессе планирования.
Без требований к выполняемой функции нельзя создать ПО, неясные и размытые требования никогда не позволят создать качественное ПО. Требования – это фундамент разработки. От того, насколько хорошо они написаны, зависит то, насколько надежным будет программное обеспечение. Процесс непосредственной разработки ПО должен начинаться с процесса создания требований и вестись в соответствии с планом, определенным в процессе планирования.
При разработке критического ПО требования принято разделять на два типа – высокоуровневые и низкоуровневые требования. Требования, относящиеся к первому типу, отвечают на вопрос "что мы собираемся делать", а требования ко второму типу отвечают на вопрос "как мы это будем делать". Высокоуровневые требования создаются непосредственно из системных требований и закладываемой функциональности ПО. На основании этих требованный строится дизайн и архитектура ПО. Уже на основе планируемого дизайна создаются низкоуровневые требования. Они адресуются непосредственно к коду. На основе низкоуровневых требований создается исходный код.
Требования считаются качественными, если они конкретны и корректны, соответствуют функциональности ПО, если их можно верифицировать, если они уникальны, последовательны и непротиворечивы. Требования могут разбиваться на подуровни для удобства внесения в них изменений и трассировки.
Для автоматизации и унификации процесса создания и отслеживания требований существует большое количество различных платных и бесплатных программ. Использование инструментов для работы с требованиями, как правило, положительно сказывается на качестве разрабатываемого ПО.
Для создания критического ПО проверка на правильность должна быть разделена на две независимые проверки – верификацию и валидацию. Несмотря на схожесть терминов, процесс верификации (verification) и процесс валидации (validation) имеют совсем разные смыслы. Верификация относятся к процессу контроля качества, она проверяет то, что мы разрабатываем ПО правильно, в соответствии с установленными планами и нормами. Валидация относится к процессу обеспечения качества, она проверяет, что разрабатываемое нами ПО выполняет свою намеченную функцию. Другими словами, валидация задает вопрос: "Мы делаем правильную вещь?", а верификация: "Мы делаем ее правильно?". Во время верификации для нас неважно, какой программный продукт мы создаем, и какие функции он выполняет, важно, что мы делаем его правильно. А все, что относится к проверке функциональности ПО, ложится на валидацию.
И валидация, и верификация необходимы при создании надежного ПО. Нарушение любого из этих принципов может привести к потере надежности. Они не должны проходить одновременно. Сначала необходимо убедиться, что мы делаем то, что нам нужно, а уже затем проверять, что процесс создания программного обеспечения идет в соответствии с намеченными планами и целями.
Ничего не создается само по себе: ни требование, ни код, ни тестовая процедура – это один из базовых принципов разработки надежного и безопасного кода, называемый трассировкой.
Трассировка – это доказательство связи между элементами. Она показывает связь между различными процессами, между результатами и их порождающим процессом, между требованием и его реализацией, между рапортом об ошибке и самой ошибкой, и так далее. Трассировка позволяет понять, что из чего вышло и куда в результате пришло.
Авиационные стандарты говорят: вы должны суметь проследить цепочку от результатов тестирования к самим тестам, от тестов к бинарному коду, от бинарного кода к исходному коду, от исходного кода к низкоуровневым требованиям, от низкоуровневых требований к дизайну и архитектуре, от дизайна и архитектуры к высокоуровневым требованиям, от высокоуровневых требований к системным требованиям и в обратную сторону. Трассировка должна быть двухсторонней.
Стандарты не определяют метода показа трассировки, нужно только чтобы трассировка была продемонстрирована каким-либо образом. Например, с помощью различных ссылок одних документов на другие. Поэтому очень важно, чтобы все документы имели уникальную идентификацию, включающую, помимо прочего, и версию документа.
Разработка надежного ПО также не может обойтись без трассировки.
Процессы, входящие в жизненный цикл разработки, могут использовать результаты работы одних процессов и передавать результаты своей работы другим процессам. Если не определить правила, когда каждый из процессов может считаться завершенным, и результаты его работы могут быть использованы другими процессами, то можно нарушить описанный выше принцип трассировки. Например, мы не можем перейти к процессу созданию низкоуровневых требований, если мы еще не создали соответствующие им высокоуровневые требования. Для того чтобы понять, когда следует завершать один процесс и переходить к другому, служат критерии перехода между процессами.
Критерии перехода устанавливают, что должно быть сделано соответствующим процессом и какие минимально-достаточные условия должны быть выполнены, чтобы считать процесс завершенным, и чтобы можно было переходить к другому процессу. Например, если все изменения кода выполнены, то можно переходить к тестированию. Процесс обеспечения качества надежного ПО должен использовать эти критерии для оценки успешного завершения каждого из процессов, входящих в жизненный цикл разработки.
Наверно, есть разработчики, которые, создавая программное обеспечение, не допускают ни одной ошибки, и их программы работают правильно во всех возможных ситуациях. Если вы не относитесь к такому типу разработчиков, без процесса верификации вам не обойтись.
Процесс верификации как раз и занимается выявлением и информированием об ошибках, которые могут появиться на всем протяжении жизненного цикла ПО. Для надежного ПО этот процесс должен проверять не только программный код, но и результаты работы других процессов жизненного цикла, в том числе он должен отслеживать ошибки в требованиях, дизайне, тестирующих примерах, процедурах и результатах тестирования.
При создании надежного программного обеспечения этот процесс, кроме тестирования, должен использовать такие методы верификации, как ревизия и анализ. Под ревизией понимается инспекция выходной информации исследуемого процесса в соответствии с контрольным перечнем, который должен быть составлен заранее. Анализ экзаменует функциональность, производительность, источники требований, полноту тестирования, безопасность компонента ПО, а также его взаимоотношения с другими компонентами ПО. Анализ может выявить противоречия и несоответствия в спецификации, стандартах, требованиях, дизайне и коде.
Как проходит и какие цели выполняет процесс верификации, должно быть определено в соответствующем плане. Стандарты разработки критического ПО требуют, чтобы план верификации включал описания:
Бесконтрольный доступ и изменение данных жизненного цикла ПО может привести к полной его остановке или потере всех созданных артефактов. Поэтому в любой жизненный цикл разработки надежного ПО обязательно должен входить процесс управления конфигурацией, контролирующий все то, что создается на всем протяжении жизненного цикла разработки ПО.
Процесс управления конфигурации занимается идентификацией всех конфигурационных элементов, контролем их изменений и доступа, созданием базовых линий для отслеживания последующих модификаций; он осуществляет действия по оповещению, трассировке и коррекции проблем. Он также отвечает за архивацию и восстановление всех конфигурационных элементов, включая программное обеспечение.
Процесс управления конфигурации начинается в тот момент, когда принято решение, что накопленные материалы, такие как чертежи, схемы, требования, любые другие документы, достаточны для начала процесса планирования. Этот процесс действует на всем протяжении жизненного цикла ПО в соответствии с разработанным планом. Стандарты DO178B/DO178С требуют, чтобы план управления конфигурации описывал:
При разработке программного обеспечения всегда есть вероятность, что что-то идет не так, что какой-то из процессов, входящих в жизненный цикл, работает неправильно, и что есть расхождения с установленным планом. Процесс обеспечения качества занимается выявлением таких проблем. Надежное программное обеспечение нельзя создать, если в жизненный цикл его разработки не включен этот процесс.
Процесс обеспечения качества должен отслеживать, что все процессы идут в соответствии с намеченными планами, что они выполняют все установленные цели, что требования стандартов соблюдаются, переходы между процессами осуществляются в соответствии с установленными критериями, все артефакты соответствуют установленной спецификации. При возникновении проблем во время жизненного цикла разработки процесс обеспечения качества должен гарантировать, что они будут рассмотрены и по ним будут приняты соответствующие решения, и в конечном итоге они будут разрешены.
Процесс верификации оценивает деятельность всех процессов, входящих в жизненный цикл разработки, с помощь различных аудитов и ревизий. Результатами работы процесса являются его записи. Они содержат информацию об проведенных аудитах, записи о санкционированных отклонениях и записи, подтверждающие проведение ревизий. Процесс верификации проводится в соответствии с разработанным планом, который для критического ПО должен включать следующие описания:
Любые действия, проводимые на всем протяжении жизненного цикла разработки ПО, должны быть отражены в соответствующих документах. Необходимо также хранить информацию, кем они были совершены, и результаты этих действий. Все артефакты, произведенные за время ЖЦ разработки, составляют ее историю. История продукта должна показать, как поэтапно было создано программное обеспечение, что это за программное обеспечение, зачем оно нужно, какие системные и функциональные требования были в нее заложены, как осуществлялся процесс ее создания, контроля и проверки, почему данная система является надежной, как это было доказано.
Для критического программного обеспечения история создания ПО имеет очень важное значение, поскольку она может быть использована для расследования инцидентов, произошедших на системах, где это ПО было использовано. Может возникнуть ситуация, когда в суде нам придется рассказывать поэтапную работу над созданием нашего ПО и доказывать, что все что мы сделали, является правильным. Поэтому если задать вопрос авиационному сертифицирующему органу, какую информацию, какие данные и какие документы нужно хранить для сертификации программного обеспечения, они отвечают: все, что касается проекта и любых действий, проводимых в его рамках, включая даже и неформальную информацию, такую как мнения, обсуждения, записи переговоров и так далее.
Для надежного ПО требование по хранению всей созданной за время разработки информации является чрезмерными. Но все, что непосредственно касается проекта, должно быть сохранено.
Для сертификации критического программного обеспечения стандарты DO178B/DO178С устанавливают 5 различных уровней безопасности ПО, от катастрофического, когда ошибочная работа программного обеспечения может привести к гибели людей, до уровня, когда ПО никак не может повлиять на безопасность полета. Сертификации ПО для разных уровней существенно отличается, и одним из основных отличий является то, как проходят процессы верификация и валидация. Чем выше уровень критичности ПО, тем выше требования к тому, чтобы процессы верификации и валидации на различных этапах разработки проводили люди, не имеющие прямого отношения к процессу разработки проверяемого ПО. Для сертификации на самые критические уровни безопасности требуется, чтобы всю верификацию и валидацию проводили только независимые от разработчика данного ПО люди.
Для создания надежного программного обеспечения принцип независимости также имеет существенное значение. Необходимо, чтобы процедуру верификации и валидации результатов работы различных процессов (в том числе и тестирование) проводили люди, непосредственно не участвующие в их создании. Это не обязательно должны быть люди со стороны, из другой организации или компании. Это могут быть люди, входящие в команду разработки данного программного обеспечения, но не принимающие участие в создании того, что они проверяют.
Процесс верификации включает в себя процесс тестирования. Этот процесс является наиболее интенсивной частью процесса разработки. Тестирование, в свою очередь, делится на два процесса: определение теста, когда решается, что собой будет представлять тест, и выполнение теста. Обычно тестирование можно разделить на две части: неформальное тестирование, когда тестирование проводится самими разработчиками во время написания кода, и формальный процесс тестирования. Как правило, трудностей при создании неформальных тестов не возникает, поскольку сам программист знает, что и как нужно тестировать, но могут возникнуть сложности в определении тестовых процедур для формального тестирования.
Стандарты DO178B/DO178С рекомендуют, чтобы тестовые процедуры были сфокусированы на требованиях. Каждая тестовая процедура должна адресоваться к определенному требованию или набору требований. Поэтому нельзя просто так добавить или убрать тестовую процедуру. В зависимости от того, на каких требованиях базируется тестирование, принято различить:
Как и какое тестирование проводить, должно быть описано в плане верификации.
Для разработки надежного ПО можно ограничится только тестовыми процедурами, проверяющими высокоуровневые требования. Но если возникает необходимость поднять уровень надежности, то нужно создать и тесты, базирующиеся на низкоуровневых требованиях. Так же, как и для критического ПО, процесс тестирования должен проходить в соответствии с разработанным планом.
Для безопасного и надежного программного обеспечения тестирования с использованием тестов, которые проверяют работу программы только в нормальных условиях, недостаточно. Необходимо также использовать тесты, которые проверяют программу на устойчивость, или так называемые робастные тесты. Основная цель этих тестов – убедиться, что ПО работает корректно:
Обязательно должна быть проведена проверка корректности работы механизма защиты и работа ПО в переходных состояниях, если о них указано в требованиях.
Хорошая восприимчивость к сбоям является одной из важнейших характеристик надежного программного обеспечения.
Надежное и безопасное программное обеспечение должно быть спроектировано так, чтобы при возникновении критической ситуации оно ломалось ”правильно”. Это означает не только, что компьютер не должен зависать или выдавать ошибку операционной системы, если в прогрммном обеспечении возник сбой. Гораздо важнее, чтобы при возникновении сбоя пользователь знал, что ПО перестало работать. Если ПО выдает некоторые значения, то очень важно, чтобы разница между сбойным значением и реальным была большой, чтобы можно было легко заметить, что это ПО сломалось и не работает.
Например, пусть у вас есть программа, которая в соответствующем приборе участвует в измерении давления у человека. Если эта программа сломается, то какое значение она должна показывать: нулевое, последнее измеренное давление, выше или ниже реального давления? Надежное и безопасное ПО должно выдавать такое значение, чтобы человек, измеряющий давление, мог однозначно понять, что прибор сломан. Если в приведенном примере прибор покажет ноль, то становится понятно, что он сломан и никакой большой проблемы здесь нет. Нужно просто использовать другой прибор. Серьезная проблема может возникнуть, если прибор при сбое покажет значение, близкое к реальному, но все же от него отличающееся. Это может привести к неправильным и даже опасным действиям, например к медикаментозному увеличению или уменьшению давления.
Анализ тестового покрытия является еще одним инструментом, помимо трассировки, базирующимся на требованиях к тестированию и позволяющим проверить, что код полностью соответствует заданным требованиям.
Для критического ПО анализ тестового покрытия состоит из двух этапов: анализа покрытия тестов и анализа структурного покрытия. Первый из анализов проверяет, что для каждого требования, высокоуровневого или низкоуровневого, существуют свои нормальные и робастные тесты. В задачу анализа структурного покрытия входит нахождение кода, который не был протестирован ни одним из тестовых примеров. Как правило, для этого необходимо использовать специальные инструменты. Считается хорошим результатом, если структурное покрытие составляет 80%. То, что нельзя проверить инструментами, должно быть проверено анализом кода вручную.
Если структуры кода не покрыты тестами, то это может происходить из-за:
Для каждой ситуации должен быть план, что и как нужно делать. Обычно, если есть проблемы в тестовых процедурах или в требованиях, то их переделывают, мертвый код удаляют, а деактивированный код анализируют вручную.
Для надежного ПО анализ тестового покрытия может производиться только для высокоуровневых требований. Можно также понизить требуемый процент покрытия кода или вообще не проводить структурное покрытие. Методика проведения анализа тестового покрытия должна быть оговорена на этапе планирования.
При обнаружении ошибки в документе, требовании, коде или тестовой процедуре нельзя просто исправить ее. Неконтролируемое исправление может привести к еще большим проблемам, нежели первоначальная ошибка. Поэтом стандарты DO178B/DO178С требуют, чтобы все исправления осуществлялись только по запросу. Человек, обнаруживший ошибку, должен составить специальный рапорт на ошибку. Этот рапорт должен включать: уникальный идентификатор рапорта, чтобы за ним можно было проследить, описание проблемы, ее приоритет и возможные действия по ее устранению. Должно быть установлено, кто будет исправлять ошибку, и за какой срок. После исправления ошибки рапорт закрывается и проводится повторная верификация. Может оказаться так, что ошибся сам верификатор. В этом случае для закрытия рапорта нужно дать подробное объяснение, почему заявленная проблема не является ошибкой.
Процесс сертификации может выйти на свою финальную стадию только если все рапорты об ошибках являются закрытыми. Весь механизм исправления ошибок прописывается в плане верификации.
При разработке надежного ПО также очень важно, чтобы исправление ошибок во всех артефактах жизненного цикла было под контролем. Во время процесса планирования необходимо определить приемлемый механизм исправления ошибок.
Если программный продукт может быть воспроизведен только один раз или только определенной группой людей, то этот продукт не может считаться ни надежным, ни тем более безопасным. Весь процесс разработки необходимо организовать так, чтобы создаваемое ПО могло быть воспроизведено другими людьми. Прежде всего это касается качества документации. Документация разрабатываемого ПО должна быть такой, чтобы люди, не имеющие отношения к вашему проекту, могли понять, какие функции и как выполняет ваше ПО, что представляет собой весь процесс его разработки, какое программно-аппаратное окружение для него используется и как его можно заново воспроизвести.
Для надежного и безопасного ПО должны быть созданы документы, в которых содержится:
Следует также иметь в виду и человеческий фактор. Может возникнуть ситуация, когда какой-то ключевой разработчик заболеет, по той или иной причине уйдет из команды разработчиков или вообще покинет компанию. Нужно организовать процесс разработки таким образом, чтобы это не повлияло или незначительно повлияло на весь процесс разработки и сроки его выполнения. Для этого рекомендуется весь процесс делать более формальным и менее зависимым от конкретных людей.
Наверно, у каждого, кто прочел эти принципы, возникли вопросы типа: "Гарантирует ли выполнение этих принципов получение надежного кода?" "Если я реализую все эти принципы, то получу ли я со 100% вероятностью качественный и надежный код?" Или "Полон ли это список, нет ли в нем пропусков?". К сожалению, на все эти вопросы ответ будет отрицательный. Если бы можно было описать пусть не 20 принципами, но хотя бы несколькими сотнями весь процесс создания стопроцентно надежного кода, то это давно было бы сделано и у нас не возникало бы столько проблем с программным обеспечением. Более того, даже если ничего из того, что изложено в этой статье, вы не будете использовать, вы все же можете создать надежный код. Все дело в вероятности. Если вы последуете описанным выше принципам, то вероятность создания вами надежного кода будет достаточно высокой. По крайней мере, так считает автор этой статьи, поскольку изложенные выше принципы базируются не на каких-то теоретических предположениях, а взяты из опыта разработки и сертификации авиационного программного обеспечения.
| Сообщений 29 Оценка 90
[+1/-1]
Оценить
|