Экспертные методы верификации и валидации в жизненном цикле программных систем

Лекция 4. Экспертные методы верификации и валидации в жизненном цикле программных систем Экспертизой ПО (software review, переводится также как критический анализ, рецензирование, просмотр, обзор, оценка и просто анализ) называют все методы верификации, в которых оценка артефактов жизненного цикла ПО выполняется людьми, непосредственно анализирующими эти артефакты. Традиционно выделяют следующие виды экспертиз. – Техническая экспертиза (technical review) – систематический анализ артефактов проекта квалифицированными специалистами для оценки их внутренней согласованности, точности, полноты, соответствия стандартам и принятым в организации процессам, а также соответствия друг другу и общим задачам проекта. – Сквозной контроль (walkthrough) – метод экспертизы, в рамках которого один из членов команды проверки представляет ее участникам последовательно все характеристики проверяемого артефакта, а они анализируют его, задавая вопросы, внося замечания, отмечая возможные ошибки, нарушения стандартов и другие дефекты. – Инспекция (software inspection) – последовательное изучение характеристик артефакта, обычно следующее некоторому плану, с целью обнаружения в нем ошибок и дефектов. – Аудит (audit) – анализ артефактов и процессов жизненного цикла, выполняемый людьми, не входящими в команду проекта, для оценки соответствия этих артефактов и процессов задачам проекта, заключенному контракту, общим стандартам, друг другу и пр. Термины «экспертиза» (review) и «инспекция» (inspection) часто употребляются для описания всех перечисленных методов верификации, четкого различия между ними в большинстве случаях не проводят. Далее будем считать инспекцией более формализованную и поверхностную проверку, нацеленную на обнаружение формальных дефектов – обычно в ее ходе по некоторому контрольному списку проверяется формальное наличие определенных свойств и отсутствие определенных видов дефектов. Рассмотрим некоторые техники проведения экспертиз. Оценка ПО по Фагану Исторически первой техникой экспертиз стала оценка ПО по Фагану (Fagan software inspection), использованная M. Fagan’ом в одном из проектов разработки ПО в IBM в 1972 году. Фактически, она представляет собой образец организации работ (organizational pattern или process pattern), используемый для решения типовой задачи оценки соответствия друг другу двух артефактов жизненного цикла ПО. Она определяет 4 роли участников и 6 шагов выполнения оценки. В ходе оценки сопоставляются первичный документ и вторичный документ, для создания которого первичный является входным. Список возможных комбинаций (не исчерпывающий) первичного и вторичного документов указан в таблице 1. Таблица 1. Первичные и вторичные документы в рамках разных деятельностей Вид деятельности Первичные документы Вторичные документы Анализ требований Модели предметной области, Описание требований к ПО концепция системы, составленные заказчиками и пользователями требования Проектирование Требования к ПО Описание архитектуры, проектная документация Кодирование Проектная документация Код, проектная документация на отдельные компоненты Тестирование Требования к ПО, проектная Тестовые планы и наборы документация, код тестовых вариантов Роли участников таковы. – Ведущий (moderator). Он руководит подготовкой и проведением оценки, проведением собраний, назначает сроки выполнения работ, фиксирует обнаруженные дефекты, следит за готовностью входных данных для оценки и исправлением найденных ошибок после нее. В качестве ведущего должен использоваться компетентный разработчик или архитектор, не вовлеченный в проект, материалы которого оцениваются. – Автор (author). Это автор первичного документа или человек, имеющий достаточно полное представление о нем. Его обязанности – подготовить рассказ об основных положениях первичного документа и отвечать на вопросы, возникающие у членов команды оценки по его поводу – Интерпретатор (reader). Это автор вторичного документа, который разработан в соответствии с первичным. Его обязанности – объяснить участникам инспекции основные идеи, лежащие в основе его интерпретации первичного документа, и отвечать на их вопросы по поводу вторичного документа. – Оценщик (tester). В ходе всей оценки он анализирует вторичный документ, проверяя его на соответствие первичному и выявляя возможные несоответствия. Процесс выполнения оценки состоит из следующих шагов. 1. Планирование (planning). На этом шаге ведущий должен убедиться в том, что первичный и вторичный документы готовы к проведению оценки – они существуют, написаны достаточно понятно, с нужной степенью детализации. Кроме того, на этом шаге проводится планирование всего хода оценки – определяются участники, их роли, назначаются сроки проведения собраний и время, выделяемое на выполнение каждого шага. 2. Обзор (review). Проводится собрание, на котором автор представляет наиболее существенные положения первичного документа и отвечает на вопросы участников о нем. Первичный и вторичный документы выдаются на руки участникам оценки для дальнейшей работы. Ведущий объясняет задачи данной оценки, вопросы и моменты, на которые стоит обратить особое внимание, а также сообщает, какие ошибки были уже обнаружены в рассматриваемых документах, чтобы участники группы имели представление об их проблемных местах. 3. Подготовка (preparation). Каждый из участников тщательно изучает оба документа самостоятельно, пытаясь понять заложенные в них решения и проследить их реализацию, фиксируя свои замечания к документам, неясные места, возможные дефекты. 4. Совместная оценка (inspection meeting). Проводится совместное собрание, на котором интерпретатор рассказывает об основных идеях и техниках, использованных во вторичном документе, а также объясняет, почему были приняты те или иные решения и как реализованы положения первичного документа. Участники задают вопросы и акцентируют внимание на проблемных местах. Если кто-то по ходу собрания замечает ошибку, ведущий должен убедиться, что все участники согласны считать ее ошибкой, т.е. несоответствием между первичным и вторичным документами. Каждая ошибка фиксируется, описывается ее положение, она классифицируется по некоторой схеме, например, критическая (приводящая к ошибке в работе системы) или некритическая (связанная с опечатками, излишней сложностью или неудобством интерфейса и пр.). 5. Доработка (rework). В ходе доработки интерпретатор исправляет обнаруженные ошибки. 6. Контроль результатов (follow-up). Результаты доработки проверяются ведущим. Он проверяет, что все найденные ошибки были исправлены и что не было внесено новых ошибок. Если по результатам инспекции было переработано более 5-10% вторичного документа, следует провести полную инспекцию вновь, иначе ведущий сам определяет, насколько документ подготовлен к дальнейшему использованию. Кроме того, ведущий подготавливает отчет обо всех обнаруженных ошибках для последующего использования в других оценках и при контроле качества результатов разработки. Оценка ПО по Фагану является разновидностью сквозного контроля (хотя по-английски она называется Fagan software inspection) – она более четко структурирована, чем техническая экспертиза, и выполняет систематическую проверку характеристик вторичного документа. Другие виды общих экспертиз Многочисленные техники проведения экспертиз, созданные после оценки ПО по Фагану, часто повторяют ее основные элементы. Отличия возникают по следующим параметрам. – Выделяемый набор ролей. Часть техник определяет дополнительные роли к перечисленным выше, например, разделяют автора первичного документа и докладчика, представляющего его содержание. Иногда вводится секретарь, выполняющий вместо ведущего фиксацию обнаруженных дефектов. – Выделяемый набор шагов. Планирование не считается во многих работах отдельным шагом. Обзорное собрание также часто не рассматривается как обязательное, хотя иногда оно необходимо для более глубокого знакомства участников с целями проводимой проверки. Некоторые техники считают необходимым проведение еще одного собрания по окончании доработки для анализа причин возникновения дефектов. – Размер команды. В целом, рекомендуется составлять небольшие команды, не более 6 человек (см. «Мифический человеко-месяц», принципы управляемости малых групп и т. п.). Отмечено, что увеличение количества участников более 5 приводит к большим затратам на обеспечение взаимодействия и адекватную передачу информации. Для оценки по Фагану оптимальной считается команда из 4 человек. Часть техник рекомендует ограничиваться 2-мя людьми, некоторые рассчитаны только на индивидуальную работу. – Количество сессий проверки. Иногда проводят несколько сессий анализа, в ходе каждой проверяя артефакт полностью снова. Такой подход позволяет выявить упущенные в ходе однократной проверки дефекты. – Необходимость проведения и количество общих собраний. Фаган настаивал на необходимости общего собрания, указывая на его синергетический эффект при поиске дефектов. Многие авторы, однако, считают общие собрания необязательными, и, более того, повышающими затраты на проведение оценки без значимого эффекта для выявления дефектов. Отмечаемые коммуникативные проблемы при проведении собраний включают следующие: наличие «безбилетников», участников, не вносящих никакого вклада в обсуждение; следование за мнением большинства; боязнь высказать «глупое» мнение; перенесение внимания на одни вопросы в ущерб другим; доминирование одного из участников. – Техника работы с документом и использование вспомогательных материалов при анализе. Большинство работ считают необходимым документов, повышающих использование специальных техник чтения эффективность их Часто используются анализа. контрольные списки возможных (наиболее важных) видов дефектов и списки аспектов корректности, подлежащих проверке, иногда они оформляются в виде наборов вопросов, на которые необходимо дать ответ (checklists). Отмечается, что вопросы (описания дефектов) должны быть сформулированы максимально точно, а весь список должен размещаться на одной странице, чтобы быть обозримым для оценщика. Водном их методов экспертизы предложена техника чтения кода, названная чтением с постепенным обобщением (reading by stepwise abstraction). При ее использовании для анализируемой последовательности инструкций кода строится функция, которую они вычисляют. При наращивании последовательности эта функция постепенно уточняется и трансформируется. Еще одна возможная техника чтения – анализ по сценариям (scenario-based reading), в ходе работы по которой оценщик следует заранее сформулированным рекомендациям по выявлению дефектов или пытается ответить на последовательность связанных вопросов. – Инструментальная поддержка. Наиболее существенными факторами эффективности экспертиз являются опыт и мотивация участвующих в них людей, и чаще всего экспертиза проводится без использования инструментов, однако есть ряд программных средств, поддерживающих ее выполнение, решая вспомогательные задачи. Основные функции инструментов поддержки общих экспертиз следующие. – Предоставление доступа к тексту документов (или диаграммам графических моделей) и возможности записывать замечания и вопросы, привязывая их к определенным элементам документа. – Предоставление удобного доступа к вопросникам и сценариям работы, обычно располагаемым на одном экране с анализируемыми документами. – Поддержка определения ролей участников, планирования работ и собраний для ведущего. – Поддержка обмена сообщениями и информацией о дефектах между участниками группы оценки. – Сбор и хранение информации о найденных дефектах. Можно отметить, что многие из указанных функций в настоящее время могут быть реализованы программными средствами коммуникации поддержки управления организационными процессами общего назначения. Пример сопоставления ряда методов экспертиз приведен в таблице 2. Таблица 2. Характеристики некоторых методов проведения экспертиз Метод Размер команды Сессии проверки Техника чтения Общие собрания Постанализ Fagan 3-5 1 – 1-2 – Gilb, Graham 4-6 1 вопросники 2-3 Есть Bisant, Lyle 2 1 – 1 – 1 – Нет, есть – встречи двух участников Оценка собраний [ без Индивидуальная работа Активная 2 оценка проекта (active design review) >1 сценарии на 1 одна сессия для основе каждой части вопросов артефакта – Britcher 1-2 4, параллельно – Фазированные инспекции 1-2 > 1, вопросники 1 последовательно сценарии 1-2 – и N-кратная оценка 3 в каждой > 1, команде, параллельно несколько команд – 1 – Специализированные методы экспертиз Рассматривавшиеся до сих пор методы экспертиз являются общими – они применимы практически к любым артефактам жизненного цикла ПО. Однако, помимо таких методов, разработано довольно значительное число специализированных методов экспертиз. Одним из традиционных таких методов является организационная экспертиза. Организационная экспертиза (management review) – это систематический анализ процессов жизненного цикла и видов деятельности, а также организационных артефактов проекта, выполняемый руководством проекта или от его имени для контроля текущего состояния проекта и оценки выполняемой в его рамках организационной деятельности на соответствие основным целям проекта. Другим примером специализированного метода является эвристическая оценка (инспектирование) пользовательского интерфейса, нацеленная на оценку удобства использования ПО. Она организуется как систематическая оценка различных элементов и аспектов интерфейса с точки зрения определенных эвристик. В качестве таких эвристик можно использовать определенный набор правил и принципов построения удобных в использовании интерфейсов, или любую достаточно полную систему эвристик, приводимых в руководствах по удобству использования ПО. В рамках одного сеанса оценка интерфейса проводится несколькими специалистами, имеющими опыт в деятельности такого рода. Число оценщиков – 3-5. Их результаты объединяются в общую картину. В процессе инспектирования разработчики должны отвечать на вопросы, касающиеся различных аспектов как предметной области, так и работы проверяемой программы. Оценка проводится в два этапа. На первом исследуется архитектура интерфейса в целом, на втором – отдельные контексты взаимодействия и элементы интерфейса. В целом оценка занимает 1-3 часа, после чего проводится анализ полученных результатов, во время которого оценщики описывают обнаруженные ими проблемы и предлагают способы их устранения. При других видах оценки удобства использования могут использоваться различные роли в группе оценщиков (оценщики, ведущий, секретарь, пользователи, разработчики, эксперты в предметной области), различные шкалы серьезности обнаруженных дефектов (не более 3-4-х уровней), метрики для оценки целостности, согласованности, адекватности интерфейса решаемым задачам. Специализированным видом экспертизы является также экспертиза или аудит защищенности программных систем. При проведении экспертиз защищенности используются базы данных известных уязвимостей и дефектов защиты, которые могут быть специфичны для области применения проверяемого ПО и его типа (сетевое приложение, приложение на основе базы данных, компилятор, операционная система и пр.). Важную роль играют также возможные сценарии атак с учетом их вероятностей, стоимости для взломщиков и возможного ущерба для системы. Необходимо отметить, что защищенность информации обеспечивается не только ПО, но и административными процедурами в организациях, где оно используется, и использующими ее людьми, и систематический анализ защищенности системы должен включать анализ и этих аспектов. Методы анализа архитектуры ПО Особое место среди специализированных методов экспертиз занимают систематические методы анализа архитектуры ПО. Первым таким методом, разработанным в 1993 году, стал SAAM (Software Architecture Analysis Method). Оценка или сравнение архитектур по этому методу выполняется следующим образом. 1. Определить набор сценариев взаимодействия пользователей или внешних систем с анализируемой. Каждый такой сценарий может использовать возможности, которые уже есть в системе, планируются для реализации или являются новыми. Сценарии должны быть значимы для заинтересованных лиц – пользователей, разработчиков, конкретных представителей заказчика или контролирующей организации, инженеров по сопровождению, и пр. Чем полнее набор сценариев, тем выше будет качество анализа. 2. Определить архитектуру (или несколько сравниваемых архитектур). Это должно быть сделано в форме, понятной всем участникам оценки. Обычно для этого применяются общеупотребительные графические языки, например, UML, однако можно использовать специализированные нотации. 3. Классифицировать сценарии. Для каждого сценария из набора должно быть определено, поддерживается ли он уже данной архитектурой (-ами) или для его поддержки нужно вносить в нее (них) изменения. Сценарий может поддерживаться, т.е. его выполнение не потребует внесения изменений ни в один из компонентов, или же не поддерживаться, если его выполнение требует изменений в описании поведения одного или нескольких компонентов или изменений в их интерфейсах. Поддержка сценария означает, что лицо, заинтересованное в его выполнении, оценивает степень поддержки как достаточную, а необходимые при этом действия – как достаточно удобные. 4. Оценить сценарии. Определить, какие из сценариев полностью поддерживаются рассматриваемыми архитектурами. Для каждого неподдерживаемого сценария надо определить необходимые изменения в архитектуре – внесение новых компонентов, изменения в существующих, изменения связей и способов взаимодействия. Если есть возможность, стоит оценить трудоемкость внесения таких изменений. 5. Выявить взаимодействие сценариев. Определить, какие компоненты требуется изменять для неподдерживаемых сценариев; если требуется изменять один компонент для поддержки нескольких сценариев, эти сценарии называют взаимодействующими. Нужно оценить смысловые связи между взаимодействующими сценариями. Малая связанность по смыслу между взаимодействующими сценариями означает, что компоненты, в которых они взаимодействуют, выполняют слабо связанные между собой задачи и их стоит декомпозировать. Компоненты, в которых взаимодействуют много (> 2-х) сценариев, также являются возможными проблемными местами. 6. Оценить архитектуру в целом (или сравнить несколько заданных архитектур). Для этого надо использовать оценки важности сценариев и степень их поддержки архитектурой. Чем больше сценариев поддерживается, чем меньше трудоемкость изменения архитектуры для поддержки остальных сценариев, тем лучше эта архитектура. SAAM нацелен, прежде всего, на оценку модифицируемости архитектуры и ее соответствия требованиям, представленным в виде сценариев. Другие методы анализа архитектуры пытаются учитывать и другие характеристики качества ПО, а также предоставить четкие критерии полноты набора используемых сценариев, которых В SAAM не хватает. Наиболее зрелыми на сегодняшний день являются методы SAAM и ATAM (Architecture Tradeoff Analysis Method), оба разработаны в Институте программной инженерии (SEI) университета Карнеги-Меллон. Они оба апробированы во многих проектах, в отличие от большинства других предложенных методов. Кроме того, ATAM позволяет оценивать практически любые атрибуты качества ПО за счет привлечения вспомогательных техник на этапе анализа сценариев. Информация о ряде методов анализа архитектуры ПО представлена в таблице 3. Инструментальная поддержка таких методов пока достаточна слаба. Описано лишь два-три инструмента, поддерживающих работу по методам SAAM и ATAM [101], которые используются в исследовательских целях. Информация о ряде методов анализа архитектуры ПО представлена в таблице 3. Инструментальная поддержка таких методов пока достаточна слаба. Таблица 3. Характеристики некоторых методов анализа архитектуры ПО. Метод Техника оценки Оцениваемые Доп. характеристик результаты и Используемые Возможности описания многократног архитектуры о использовани я информации SAAM Сценарии Модифицируе Проблемные мость, места соответствие требованиям Статическое – представление ATAM Сценарии, метрики, спец. техники для каждого атрибута качества Любые, для оценки каждой характеристик и привлекаются эксперты Точки увязки – элементы архитектуры, влияющие на несколько характеристик Статические и динамические представлени я SBAR Сценарии, Любые мат. модели, симуляция – Детальные – представлени я всех проектных решений ALMA Сценарии CBAM Сценарии, Любые сравнительны е оценки, спец. техники для каждого атрибута Модифицируе Последствия – мость изменений, оценка затрат на поддержку Явные оценки выгод и стоимости проектных решений Статические и динамические представлени я Техники анализа отдельных атрибутов качества – Техники анализа отдельных атрибутов качества