Верификация и валидация; классификация методов верификации

Теория верификации и валидации параллельных и распределенных программных систем Лекция 1 Вид деятельности, артефакт, роль. Верификация и валидация. Классификация методов верификации Подготовил: Гущин А.Н. доцент каф. И5 БГТУ «Военмех», к.т.н., доц. Жизненный цикл (life cycle):life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. (ГОСТ Р ИСО/МЭК12207—2010) Жизненный цикл (life cycle):life cycle) – комментарий: ● ● Под жизненным циклом программного обеспечения обычно понимают весь интервал времени от момента зарождения идеи о том, чтобы создать или приобрести программную систему для решения определенных задач, до момента полного прекращения использования последней ее версии. Жизненным циклом этот период назван по аналогии с циклом жизни растения или животного, которое рождается, проходит определенные фазы роста и развития и в итоге погибает, давая жизнь новым существам, проходящим через те же стадии. Модель жизненного цикла (life cycle):life cycle model): Структура процессов и действий, связанных с жизненным циклом, организуемых в стадии, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон. (ГОСТ Р ИСО/МЭК12207—2010) Стадия (life cycle):stage): Период в пределах жизненного цикла некоторого объекта, который относится к состоянию его описания или реализации. ● ● Примечание 1 — В настоящем стандарте принято, что стадии относятся к основному развитию и достижению контрольных точек этим объектом в течение его жизненного цикла. Примечание 2 — Стадии могут быть взаимно перекрывающимися. (ГОСТ Р ИСО/МЭК12207—2010) Процесс (life cycle):process): Совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы. (ГОСТ Р ИСО/МЭК12207—2010, [ИСО 9000:2005]) Деятельность (life cycle):activity) и задача (life cycle):task)) ● ● Деятельность (activity)activity)): Совокупность согласованных задач процесса. Задача (activity)task)): Требование, рекомендация или разрешенное действие, предназначенное для содействия достижению одного или более выходов процесса. (ГОСТ Р ИСО/МЭК12207—2010) Деятельность (life cycle):activity) – комментарий: ● ● Вид деятельности в жизненном цикле ПО — это набор действий, направленных на решение одной задачи или группы тесно связанных задач в рамках разработки и сопровождения ПО. Примерами видов деятельности являются анализ предметной области, выделение и описание требований, проектирование, разработка текстов программ, тестирование, управление конфигурациями, развертывание и т.п. Цель процесса (life cycle):process purpose): Цель высокого уровня выполнения процесса и вероятные выходы эффективной реализации процесса. Примечание — Необходимо, чтобы реализация процесса обеспечивала ощутимую пользу правообладателям. (ГОСТ Р ИСО/МЭК12207—2010) Выход процесса (life cycle):process outcome): Наблюдаемый результат успешного достижения цели процесса. Примечание — Формулировка выхода процесса описывает один из следующих результатов: ● изготовление какого-либо артефакта; ● существенное изменение состояния; ● удовлетворение заданных ограничений, например требований, конечных целей и т. п. (ГОСТ Р ИСО/МЭК12207—2010) Выход процесса (life cycle):process outcome) – комментарий: ● ● Артефактами жизненного цикла ПО называются различные информационные сущности, документы и модели, создаваемые или используемые в ходе разработки и сопровождения ПО. Так, артефактами являются техническое задание, описание архитектуры, модель предметной области на каком-либо графическом языке, исходные тексты программ, пользовательская документация и т.д. Различные модели, используемые отдельными разработчиками при создании и анализе ПО, но не зафиксированные в виде доступных другим людям документов, не могут считаться артефактами. Продукт (life cycle):product) и услуга (life cycle):service) ● Продукт (activity)product): Результат процесса. [ИСО 9000:2005] ● Задача (activity)task)): Требование, рекомендация или разрешенное действие, предназначенное для содействия достижению одного или более выходов процесса. (ГОСТ Р ИСО/МЭК12207—2010) Продукт (life cycle):product), услуга (life cycle):service), ресурс (life cycle):resource) ● ● ● Продукт (activity)product): Результат процесса. [ИСО 9000:2005] Услуга (activity)service): Выполнение действий, работы или обязанностей, связанных с продуктом. Ресурс (activity)resource): Актив, который используется или потребляется в ходе выполнения процесса. (ГОСТ Р ИСО/МЭК12207—2010) Проект (life cycle):project): Попытка действий с определенными начальными и конечными сроками, предпринимаемая для создания продукта или услуги в соответствии с заданными ресурсами и требованиями. ● ● Примечание 1 — Адаптировано из ИСО 9000:2005. Примечание 2 — Проект может рассматриваться как уникальный процесс, включающий в себя скоординированные и управляемые виды деятельности, а также может быть комбинацией видов деятельности из процессов проекта и технических процессов, определенных в настоящем стандарте. (ГОСТ Р ИСО/МЭК12207—2010) Система (life cycle):system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. ● ● Примечание 1 — Система может рассматриваться как продукт или предоставляемые им услуги. Примечание 2 — На практике интерпретация данного термина зачастую уточняется с помощью ассоциативного существительного, например, «система самолета». В некоторых случаях слово «система» может заменяться контекстно-зависимым синонимом, например, «самолет», хотя это может впоследствии затруднить восприятие системных принципов. (ГОСТ Р ИСО/МЭК12207—2010) Системный элемент (life cycle):system element): Представитель совокупности элементов, образующих систему Примечание — Системный элемент является отдельной частью системы, которая может быть создана для полного выполнения заданных требований. Системный элемент может представлять собой технические и программные средства, данные, людей, процессы (life cycle):например, процессы для обеспечения услуг пользователям), процедуры (life cycle):например, инструкции оператору), средства, материалы и природные объекты (life cycle):например, вода, живые организмы, минералы) или любые их сочетания. (ГОСТ Р ИСО/МЭК12207—2010) Программный продукт (life cycle):software product), программная составная часть (life cycle):software item), программный блок (life cycle):software unit): ● ● Программный продукт (activity)software product): Совокупность компьютерных программ, процедур и, возможно, связанных с ними документации и данных. Программная составная часть (activity)software item)): Исходный текст программы, программа в объектном коде (life cycle):объектный текст программы, программа в исполнимом виде), контрольный код, контрольные данные или совокупность этих составных частей. Примечание — Программная составная часть может рассматриваться как системный элемент ● Программный блок (activity)software unit): Отдельная компилируемая часть текста программы, часть текста программы пригодная к самостоятельному использованию в составе других программ. (На основе ГОСТ Р ИСО/МЭК12207—2010) Организация (life cycle):organization): Лицо или группа лиц и необходимых средств с распределением обязанностей, полномочий и взаимоотношений. ● ● ● ● Примечание 1 — Адаптировано из ИСО 9000:2005. Примечание 2 — Объединение лиц, организованных для некоторой конкретной цели, такое как клуб, союз, корпорация или общество, являются организацией. Примечание 3 — Определенная часть организации (life cycle):даже такая небольшая, как конкретное лицо) или определенная группа организаций может рассматриваться как организация, если она имеет обязанности, полномочия и определенные отношения. Примечание 4 — Отдельная форма организационного объекта часто называется «предприятием», поэтому организационные аспекты настоящего стандарта следует применять также и к «предприятию». (ГОСТ Р ИСО/МЭК12207—2010) Правообладатель (life cycle):stak)eholder) и приобретающая сторона (life cycle):acquirer): ● ● Правообладатель (activity)stak)eholder): Лицо или организация, имеющие право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими ее потребности и ожидания. Приобретающая сторона (activity)acquirer): Правообладатель, который приобретает или получает продукт или услугу от поставщика. Примечание — Приобретающей стороной может быть: покупатель, заказчик, владелец, оптовый покупатель. (ГОСТ Р ИСО/МЭК12207—2010) Заказчик (life cycle):customer) и поставщик (life cycle):supplier): ● Заказчик (activity)custom)er): Организация или лицо, получающие продукт или услугу. Примечание 1 — Заказчик может быть внутренним или внешним по отношению к организации. Примечание 2 — Адаптировано из ИСО 9000:2005. Примечание 3 — Другие термины, используемые для термина «заказчик»: «приобретающая сторона», «розничный покупатель», «оптовый покупатель». ● Поставщик (activity)supplier): Организация или лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги. Примечание 1 — «Поставщиком» может быть подрядчик, производитель, торговец или продавец. Примечание 2 — Иногда приобретающая сторона и поставщик являются частью одной и той же организации. (ГОСТ Р ИСО/МЭК12207—2010) Разработчик (life cycle):developer) и исполнитель (life cycle):implementer): ● Разработчик (activity)developer): Организация, которая выполняет разработку задач (life cycle):в том числе анализ требований, проектирование, приемочные испытания) в процессе жизненного цикла. Примечание — В настоящем стандарте термины «разработчик» и «исполнитель» являются синонимами. ● Исполнитель (activity)im)plem)enter): Организация, которая выполняет реализацию задач. Примечание — В настоящем стандарте, термины «разработчик» и «исполнитель» являются синонимами. (ГОСТ Р ИСО/МЭК12207—2010) Оператор (life cycle):operator) и пользователь (life cycle):user): ● Оператор (activity)operator): Какое-либо лицо или организация, осуществляющее работу системы. Примечание — Роль оператора и роль пользователя могут возлагаться одновременно или последовательно на одно и то же лицо или организацию. ● Пользователь (activity)user): Лицо или группа лиц, извлекающих пользу из системы в процессе ее применения. Примечание — Роль пользователя и роль оператора могут выполняться одновременно или последовательно одним и тем же человеком или организацией. (На основе ГОСТ Р ИСО/МЭК12207—2010) Роль в жизненном цикле ПО – комментарий: ● ● Роль в жизненном цикле ПО — это профессиональная специализация людей, участвующих в работах по созданию или сопровождению ПО (life cycle):или затрагиваемых ими) и имеющих одинаковые интересы или решающих одни и те же задачи по отношению к этому ПО. Примеры ролей: бизнес-аналитик, инженер по требованиям, архитектор, проектировщик пользовательского интерфейса, программист-кодировщик, технический писатель, тестировщик, руководитель проекта, пользователь, администратор системы. Валидация (life cycle):validation): Подтверждение (life cycle):на основе представления объективных свидетельств) того, что требования, предназначенные для конкретного использования или применения, выполнены. Примечание — Валидация в контексте жизненного цикла представляет собой совокупность действий, гарантирующих и обеспечивающих уверенность в том, что система способна реализовать свое предназначение, текущие и перспективные цели. (ГОСТ Р ИСО/МЭК12207—2010) Валидация (life cycle):validation) – комментарий: ● ● Валидация проверяет соответствие любых создаваемых или используемых в ходе разработки и сопровождения ПО артефактов нуждам и потребностям пользователей и заказчиков этого ПО, с учетом законов предметной области и ограничений контекста использования ПО. Эти нужды и потребности чаще всего не зафиксированы документально — при фиксации они превращаются в описание требований, один из артефактов процесса разработки ПО. Валидация является менее формализованной деятельностью, чем верификация. Она всегда проводится с участием представителей заказчиков, пользователей, бизнесаналитиков или экспертов в предметной области — тех, чье мнение можно считать достаточно хорошим выражением реальных нужд и потребностей пользователей, заказчиков и других заинтересованных лиц. Методы ее выполнения часто используют специфические техники выявления знаний и действительных потребностей участников. Верификация (life cycle):verification): Подтверждение (life cycle):на основе представления объективных свидетельств) того, что заданные требования полностью выполнены. ● Примечание — Верификация в контексте жизненного цикла представляет собой совокупность действий по сравнению полученного результата жизненного цикла с требуемыми характеристиками для этого результата. Результатами жизненного цикла могут являться (life cycle):но не ограничиваться ими): заданные требования, описание проекта и непосредственно система. (ГОСТ Р ИСО/МЭК12207—2010) Верификация (life cycle):verification) – комментарий: ● ● ● Верификация проверяет соответствие одних создаваемых в ходе разработки и сопровождения ПО артефактов другим, ранее созданным или используемым в качестве исходных данных, а также соответствие этих артефактов и процессов их разработки правилам и стандартам. В частности, верификация проверяет соответствие между нормами стандартов, описанием требований (life cycle):техническим заданием) к ПО, проектными решениями, исходным текстам программ, пользовательской документацией и функционированием самого ПО. Также в процессе верификации проверяется, что требования, проектные решения, документация и код оформлены в соответствии с нормами и стандартами, принятыми в данной стране, отрасли и организации при разработке ПО, а также — что при их создании выполнялись все указанные в стандартах операции, в нужной последовательности. Обнаруживаемые при верификации ошибки и дефекты являются расхождениями или противоречиями между несколькими из перечисленных документов, между документами и реальной работой программы, между нормами стандартов и реальным процессами разработки и сопровождения ПО. При этом принятие решения о том, какой именно документ подлежит исправлению (life cycle):может быть, и оба) является отдельной задачей. Метафора B. Boehm’а:а: «Верификация отвечает на вопрос "Делаем ли мы продукт правильно?", а валидация — на вопрос "Делаем ли мы правильный продукт?"» Группы методов верификации ● Экспертиза ● Статический анализ ● Формальные методы ● Динамические методы ● Синтетические методы Виды экспертиз Общие: ● Технические экспертизы (life cycle):technical review) ● Сквозной контроль (life cycle):walk)through) ● Инспекции (life cycle):inspection) ● Аудиты (life cycle):audit) Специализированные: ● Организационные экспертизы (life cycle):management review) ● Экспертиза удобства использования ● Экспертиза защищенности ● Анализ свойств архитектуры Свойства экспертиз Достоинства: ● ● ● ● ● Возможность выполнения используя только сами артефакты жизненного цикла, а не их модели (life cycle):как в формальных методах) или результаты работы (life cycle):как в динамических). Применимость к любым свойствам ПО и любым артефактам жизненного цикла и на любом этапе проекта, хотя для разных целей могут использоваться разные виды экспертиз. Позволяет выявлять практически любые виды ошибок, причем делать это на этапе подготовки соответствующего артефакта, тем самым минимизируя время существования дефекта и его последствия для качества производных артефактов. Эффективность в терминах отношения количества обнаруживаемых дефектов к затрачиваемым на это ресурсам несколько выше, чем для других методов верификации. Регулярное участие в экспертизах является важным фактором в обучении сотрудников и способствует повышению качества результатов их работы. Недостатки: ● ● Не может быть автоматизирована и требует активного участия людей. Эффективность экспертизы существенно зависит от опыта и мотивации ее участников, организации процесса, а также от обеспечения корректного взаимодействия между различными участниками. Виды статического анализа ● Проверка правил корректности ● Поиск дефектов по шаблонам Статический анализ свойств артефактов жизненного цикла ПО используется для проверки формализованных правил корректного построения этих артефактов и поиска часто встречающихся дефектов по некоторым шаблонам. Свойства статического анализа Достоинства: ● ● Хорошо автоматизируется и может быть практически полностью возложен на инструменты, хотя иногда необходимо вручную определить, например, принятые в проекте стандарты кодирования. Инструменты автоматической верификации на основе статического анализа применяются достаточно широко, поскольку не требуют специальной подготовки и достаточно удобны в использовании. Большинство техник статической проверки корректности программ, доказавших свою эффективность на практике, рано или поздно становятся частью компиляторов или даже преобразуются в семантические правила языков программирования. Недостатки: ● ● Применим он лишь к текстам программ или к определенным форматам представления проектных артефактов, и способен обнаруживать только ограниченный набор типов ошибок. Дилемма: либо используются строгие методы анализа, не допускающие пропуска ошибок (life cycle):тех типов, что ищутся), но приводящие к большому количеству сообщений о возможных ошибках, которые таковыми не являются, либо точным является набор сообщений об ошибках, но возникает возможность пропустить ошибку. Виды формальных методов ● Дедуктивный анализ ● Проверка моделей ● Проверка согласованности Формальные методы верификации используют для анализа свойств ПО формальные модели требований, поведения ПО и его окружения. Анализ формальных моделей выполняется с помощью специфических техник, таких как дедуктивный анализ (life cycle):theorem proving), проверка моделей (life cycle):model check)ing) или абстрактная интерпретация (life cycle):abstract interpretation). Формальные методы верификации активно используются в ряде областей, где последствия ошибки в системе могут оказаться чрезвычайно дорогими. Свойства формальных методов Достоинства: ● ● ● Способны обнаруживать сложные ошибки, практически не выявляемые с помощью экспертиз или тестирования. Формализация требований и проектных решений возможна только при их глубоком понимании, и поэтому вынуждает провести тщательнейший анализ этих артефактов, для чего часто необходима совместная работа специалистов по формальным методам и экспертов в предметной области. Существуют основанные на формальных методах инструменты, решающие достаточно ограниченные задачи верификации ПО из определенного класса, но зато способные эффективно работать в промышленных проектах и требующие для применения минимальных специальных навыков и знаний. Недостатки: ● ● ● Применимы только к тем свойствам, которые выражены формально в рамках некоторой математической модели, а также к тем артефактам, для которых можно построить адекватную формальную модель. Для использования таких методов в проекте необходимо затратить значительные усилия на построение формальных моделей. Построение формальных моделей нельзя автоматизировать, для этого всегда необходим человек. Анализ их свойств в значительной мере может быть автоматизирован, и сейчас уже есть инструменты, способные анализировать формальные модели промышленного уровня сложности, однако чтобы эффективно пользоваться ими часто тоже требуется очень специфический набор навыков и знаний. Виды динамических методов ● Тестирование ● Имитационное тестирование ● Мониторинг ● Профилирование В рамках динамических методов верификации, анализ и оценка свойств программной системы делаются по результатам ее реальной работы или работы некоторых ее моделей и прототипов. Свойства динамических методов Достоинства: ● ● ● Можно контролировать характеристики работы системы в ее реальном окружении, которые иногда невозможно аккуратно проанализировать с помощью других подходов. Системы тестирования, профилирования или мониторинга могут быть сделаны один раз и использоваться многократно для широких классов ПО, лишь сами тесты необходимо готовить заново для каждой проверяемой системы. Подготовка тестов на ранних этапах создания ПО позволяет обнаружить множество дефектов в описании требований и проектных документах — фактически, разработчики тестов вынуждены в ходе своей деятельности выполнять экспертизу артефактов, служащих основой для тестов. Недостатки: ● ● ● Для применения необходимо иметь работающую систему или хотя бы некоторые ее компоненты, или же их прототипы, поэтому нельзя использовать их на первых стадиях разработки Позволяют обнаруживать в ПО только ошибки, проявляющиеся при его работе, а, например, дефекты удобства сопровождения найти не помогут, однако, обнаруживаемые ими ошибки обычно считаются более серьезными. Для применения обычно требуется дополнительная подготовка — создание тестов, разработка тестовой системы, позволяющей их выполнять или системы мониторинга, позволяющей контролировать определенные характеристики поведения проверяемой системы. Свойства динамических методов Внимание! Создание набора тестов, позволяющих получить адекватную оценку качества сложной системы, является довольно трудоемкой задачей. Однако среди разработчиков промышленного ПО сложилось не вполне верное мнение, что тестирование является наименее ресурсоемким методом верификации, поэтому на практике оно используется для оценки свойств ПО очень широко. При этом чаще всего применяются не слишком надежные, но достаточно дешевые техники, такие как (life cycle):нестрогое) вероятностное тестирование, при котором тестовые данные генерируются случайным образом, или же тестирование на основе простейших сценариев использования, проверяющие лишь наиболее простые ситуации. Виды синтетических методов ● Тестирование на основе моделей (life cycle):model-based testing, model driven testing) ● Мониторинг формальных свойств (life cycle):runtime verification, passive testing) ● Статический анализ формальных свойств ● Синтетические методы структурного тестирования Общая идея таких методов — попытаться сочетать преимущества основных подходов к верификации, купировав их недостатки. Ряд инструментов построения тестов существенно использует как формализацию некоторых свойств ПО, так и статический анализ текстов программ.