Тема: методы верификации по.

Верификация:

1. Экспертиза.

2. Статический анализ.

3. Формальные методы.

4. Динамические методы.

5. Синтетические методы.

Экспертиза:

• Общая

• техническая экспертиза;

• сплошной контроль;

• инспекция;

• аудит.

• Специализированная

  • организационная экспертиза;

  • экспертиза удобства использования;

  • экспертиза защищенности;

  • анализ свойств архитектуры.

Статистический анализ:

• проверка правил корректности;

• поиск дефектов по шаблонам.

Формальные методы:

• дедуктивный анализ;

• проверка моделей;

• проверка согласованности.

Динамические методы:

• мониторинг;

• тестирование;

• имитационное тестирование.

Синтетические методы:

• тестирование на основе моделей;

• мониторинг формальных свойств;

• статический анализ формальных свойств;

• синтетические методы структурного тестирования.

Техническая экспертиза – систематический анализ артефактов проекта квалифицированными специалистами для оценки их внутренней согласованности, точности, полноты, соответствия стандартам и принятым в организации процессам, а также соответствия друг другу и общим задачам проекта.

Сплошной контроль – метод экспертизы, в рамках которого один из членов команды проверки предоставляет её участникам последовательно все характеристики проверяемого артефакта.

Инспекция – последовательное изучение характеристик артефакта, обычно следующее некоторому плану, с целью обнаружения в нем ошибок и дефектов.

Аудит – анализ артефактов и процессов жизненного цикла, выполняемый людьми, не входящими в команду проекта, для оценки соответствия этих артефактов и процессов задачам проекта, заключенному контракту, общим стандартам, друг другу и пр.

Оценка ПО по Фагану:

Вид деятельности	Первичные документы	Вторичные документы
Анализ требований	Модели предметной области, концепция системы, составленные заказчиками и пользователями требования	Описание требований к ПО
Проектирование	Требования к ПО	Описание архитектуры, проектная документация
Кодирование	Проектная документация	Код, проектная документация на отдельные компоненты
Тестирование	Требования к ПО, проектная документация, код	Тестовые планы и наборы тестовых документаций, код вариантов

Роли участников:

• ведущий;

• автор;

• интерпретатор;

• оценщик.

Шаги экспертизы:

• планирование;

• обзор;

• подготовка;

• совместная оценка;

• доработка;

• контроль результатов.

Другие виды экспертиз: отличия от экспертизы по Фагану.

• выделяемый набор ролей;

• выделяемый набор шагов;

• размер команды;

• количество сессий проверки;

• необходимость проведения и количество общих собраний;

Выделяемый набор ролей.

Часть техник определяет дополнительные роли к перечисленным выше, например, разделяют автора первичного документа и докладчика.

Выделяемый набор шагов.

Планирование не считается во многих работах отдельным шагом. Обзорное собрание также часто не рассматривается как обязательное. Некоторые техники считают необходимым проведение ещё одного собрания по окончании.

Размер команды.

В целом, рекомендуется составлять небольшие команды, не более 6 человек.

Количество сессий проверки.

Иногда проводят несколько сессий анализа, в ходе каждой сессии проверяя артефакт полностью снова. Такой подход позволяет выявить упущенные ошибки.

Необходимость проведения и количество общих собраний.

Коммуникативные проблемы при проведении собраний включают следующие:

• наличие «безбилетников», участников, не вносящих никакого вклада в обсуждение;

• следование за мнением большинства

- боязнь высказать "глупое" мнение

- перенесение внимания на одни вопросы в ущерб другим

- доминирование одного из участников

Техника работы с документами

Большинство работ считают необходимым использование специальных техник чтения

документов, повышающую эффективность их анализа

Инструментальная поддержка

- предоставление доступа к тексту документов

- предоставление удобного доступа к вопросникам и сценариям работы, обычно

располагаемым на одном экране с анализируемыми документами

- поддержка определенных ролей участников

- поддержка обмена сообщениями и информацией

Специализированная экспертиза

Организационная экспертиза

Систематический анализ процессов жизненного цикла и видов деятельности организационных артефактов проекта выполняемый руководством проекта или от его имени

Экспертиза удобства использования

Эвристическая оценка (инспектирование) пользовательского интерфейса, нацеленная на оценку удобства использования ПО.

Экспертиза защищенности

Используется база данных известных уязвимостей и дефектов защиты, которые могут быть специальны для области применения проверяемого ПО и его типа (сетевое приложение, приложение на основе БД и пр.)

Методы анализа архитекруры по

- SAAM

- другие методы

- сопостовляемые методы

SAAM

1) определить набор сценариев взаимодействия пользователями внешних систем с анализируемой

2) определить архитектуру

3) классифицировать сценарии

4) оценить сценарии

5) выявить взаимодействие сценариев

6) оценить архитектуру в целом (или сравнить несколько заданных архитектур)

II Статический анализ

Требования к идеальному статическому анализатору кода

1) 100% обнаружение всех типов программных ошибок

2) 0% ложных срабатываний

3) высокая производительность

4) интеграция с IDE, работа под любой операционной системой, анализ кода на языке программирования

5) Бесплатная и качественная поддержка

0% ложных срабатываний:

- отках от правил, которые уже не актуальны

- наличие удобных инструментов для работы с ложными срабатываниями

Задачи, решаемые статическими анализаторами кода:

1) виды ошибок, выявленных статическим анализатором кода

- выход индекса за грани массива

- деление на ноль, извлечение корня из отрицательного числа

- разыменование нулевого указателя

- выход за границы отведенной памяти

- отсуствие инициальзации переменной

- неиспользуемое значение

- неправильное привидение динамического типа

- недостижимая ветвь

- переполнение при арифметических операциях и при приведении типа

- нулевое число повторений цикла, бесконечные циклы и рекурсии

- выделение памяти размером меньшим либо равном нулю

2) Анализ метрик

Метрика - мера позволяющая получить численное значение некоторого свойства в программном обеспечении или его спецификации

- порядок роста (анализ алгоритмов в терминах *асимптотического* анализа и О-нотации

- количество строк кода

- цикломатическая сложенность

- количество ошибок на 1000 строк кода

- степень покрытия кода тестированием

- покрытие требований

- количество классоа и интерфейсов

- связность

3) форматирование кода, приведение его к стандартному виду

Примеры статических анализаторов кода

- Poly Spice Verifier

наличие *сертификатов* и отчетов по стандарту встроенных программынх продуктов

Редактируемые шаблоны для подготовки документации

- Certuficate

- Report

- ...

- Coventry Prevent

- Klocwork Insight

ориентирован на windows, ориентирован на работу с интегрированными средами разработки

- Surrey of Tools: PC - Lint

План: ТРЕБОВАНИЯ

Определение понятния требование

Классификация требований

Методологии и стандарты, регламентирующие работу с требованиями

I. Определение понятия требования

Требование - это условие или возможность которой должна соотвествовать система

(Л. Новиков)

Требование:

1) условия или возможности, необходимые пользователю для решения проблем или достижения целей

2) условия или возможности, которыми должна оьладать система или системные компоненты, чтобы сыполнить контракт или удовлетворять стандартам, спецификациям или другим нормальным документам

3) документация

Требовния - это исходные данные, на основании которых проектируются и создаются автоматизированные ИС

II. Классфикация требований

- требования к продукту и процессу

В своей основе требования - это то, что формтирует заказчик. цель,

которую он преследует - получить хороший продукт

- требования к *про*

основные мероприятия по контролю и снижению риска:

Степень регламентации требований к проекту:

- регламентация процесса заказчиком позволяет снизить его риски

- мероприятия заказчика по регламентации

Жесткие требования:

1) разработчик представляет заказчику согласованный план работ с детализацией (WorkBreakdown Structure - WBS) с точностью дл конкретных исполнителей\

2) разработчик осуществляет ежедневные сборкиЮ регрессионное тестирование компонентов разрабатываемого продукта и тестирование продукта в целом