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