Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Архитектура и проектирование программных систем

Проверка правильности внешних спецификаций

Рассмотренные до сих пор вопросы касались интерфейса «пользователь - программная система». Дальнейшие действия по проектированию должны быть сосредоточены на разработке архитектуры системы. По этой причине и вследствие трудностей, обсуждавшихся при разработке качественной внешней спецификации, проверка полноты и точности внешней спецификации проекта является крайне важной.

На этом этапе должна быть занята активная позиция в отношении ошибок. Цель всякой проверки правильности или тестирования - найти как можно больше ошибок, а не показать, что спецификации не содержат ошибок. Очень важно понимать это тонкое различие [18]. Необходимо проверять спецификации, когда они находятся в черновой форме, так как может возникнуть психологический барьер при проверке документа, имеющего «законченную» печатную форму.

В [18] предлагается шесть методов проверки правильности, применяемых к внешним спецификациям. Эти методы не исключают друг друга и рекомендуются для последовательного применения.

  • 1. Контроль по правилу «К плюс - минус один» и групповой контроль специалистами. Специалисты уровня Ы- 1 ищут ошибки перевода, а специалисты уровня N + 1 — ошибки, которые могут привести к ошибкам в последующих процессах. Спецификации должны сверяться с целями путем рассмотрения каждой из них и последующего определения адекватности отражения цели в спецификациях. Подробную внешнюю спецификацию должны оценивать люди, отвечающие за разработку первоначального внешнего проекта, проектирование структуры программ и баз данных, и люди, отвечающие за подготовку документации пользователя.
  • 2. Контроль со стороны пользователя. Крайне важно получить обзор и одобрение первоначальной и подробной спецификации со стороны организации пользователя. Если разрабатывается проект, не зависящий от пользователя, то контрольная группа создается из специалистов проектирующей организации с теми же целями. В ее задачу будет входить оценка спецификаций с точки зрения пользователя.
  • 3. Контроль по таблицам решений. Если в спецификациях используются таблицы решений, тогда для проверки на полноту (поиск всех пропущенных условий) и неоднозначность (идентичные условия приводят к разным выходным данным или преобразованиям) могут быть применены «механические» методы.
  • 4. Ручная имитация (прокрутка спецификаций). Эффективный прием проверки детальных внешних спецификаций - подготовка тестов и последующее использование детальных спецификаций для имитации поведения системы. Этот процесс оценки проектного документа методом его выполнения на тестовых данных часто называется сквозным контролем.

Для проверки отдельных внешних функций должны быть выполнены следующие действия. Кто-то (не автор спецификации) должен сначала построить тесты на бумаге для этой функции, т.е. список конкретных входных данных (допустимых и недопустимых). Вместе с автором спецификаций он потом имитирует ввод данных в систему, используя спецификации как описание поведения системы. Всякий раз, когда оказывается, что спецификация описывает выходные данные или преобразование недостаточно полно и правильно, это означает, что обнаружена ошибка. Эту последовательность проверки внешних функций можно представить следующей схемой (рис. 5.37).

Прежде чем начать сквозной контроль, обычно бывает необходимо установить исходное состояние системы, например описать начальные состояния всех файлов, а затем обновлять это состояние по мере использования тестов. Подобным образом можно тестировать и комбинации функций, строя тесты, представляющие собой сложные сценарии. Важно отметить, что цель всякого такого сеанса сквозного контроля -обнаруживать ошибки, но не исправлять их с лету. Исправление ошибок нужно отложить до тех пор, пока не будут обнаружены по возможности все ошибки. Также важно, чтобы строил тесты и интерпретировал спецификации кто-то другой, не автор, так как последний будет «читать между строк».

Последовательность проверки внешних функций

Рис. 5.38. Последовательность проверки внешних функций

5. Имитация за терминалом. В этом случае вместо того чтобы просто читать список тестов, как при ручной имитации, один из проверяющих садится за терминал (персональный компьютер), вводит тестовые данные и получает результаты так, как если бы терминал был подключен к настоящей программной системе (рис. 5.38).

Для имитации еще один участник проверки, вооружившись спецификациями, садится за другой компьютер. Небольшая программа, специально разработанная для такой проверки, связывает эти компьютеры, передавая входные данные с терминала «пользователя» на терминал «имитатора», а выходные данные - обратно по командам «имитатора» (рис. 5.38).

6. Функциональные диаграммы. Этот метод заимствован из проектирования переключательных схем и позволяет проектировщику представить спецификации булевской логической диаграммой (функциональной диаграммой), которая затем преобразуется в таблицу решений.

Пользователь с тестами

Имитатор системы со спецификациями

Рис. 5.39. Схема имитации

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ   След >
 

Популярные страницы