ЧАСТЬ еляционных систем баз данных

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

После того как обозначены все цели проекта, можно приступать к определению критериев разработки. Как правило, сохранить строгую последовательности 1анированную изначально, не удается и критерии разработки частично будут определяться еше на этане определение ей. Но мы, для простоты, договоримся, что у вас есть готовый список целей проекта, и теперь необходимо составить список критериев.

Критерии разработки указывают, достигнуты ли поставленные цели. Все критерии должны соответствовать одной или целям проекта. Если вдруг обнаруживается, что это не так - вы, возможно, упустили из виду какую-нибудь важную цель.

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

Как правило, критерии разработки формулируются в одной из следующих форм.

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

определяемые внешним окружением, например Система

должна работать в существующей компьютерной сети .

Основные направления разработки, например Предоставление

пользователю контекстно-зависимой справки .

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

ПРИМЕЧАНИЕ В какой бы форме ни выражались определяемые вами критерии, следует остановиться, как только они будут выполнены -проект закончен, можно отдохнуть. На первый взгляд, совет тривиален. Но давайте рассмотрим конкретный пример. Представим себе, что вы оптимизируете фрагмент программного кода. Чтобы вынолня-лись критерии разработки, некоторая функция должна вычислять определенное значение за время, не превышающее секунд. Вам уда-

лось добиться того, что значение вычисляется за время, не превышающее 9 секунд, но вы уверены, что стоит приложить еше немного усилий - и вы сократите время вычисления вдвое. Не делайте этого. Или же, если в этом лействительни возникнет необходимость, сделайте это позже. Как только система начала всем определенным

критериям, все работы должны прекратиться, иначе вы никогда не завершите проект.

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

образом, вы будете продолжать исследования до бесконечности или, точнее, пока не выйдете за рамки бюджета.

На этой стадии проекта очень важно ываться к определенному решению или архитектуре. Возможно, вы уверены, что будете использовать Microsoft Transaction Server для обеспечения масштабируемости системы, но это архитектурное решение, а не критерий

разработки. Критерием разработки является то, что система должна

поддерживать х пользователей одновременно.

Если у вас возникают какие-либо сомнения в правильности определения критериев разработки спросите себя, например, можно ли считать систему полностью завершенной, если вы будете использовать Microsoft Transaction Server? Может быть и , но о том, что система полностью завершена, вы едва ли будете судить на основании того факта, что она реализована при помоши Microsoft Transaction Server. Скорее всего, решение об окончании работ будет зависеть от ответа на другой вопроса сли система успешно поддерживает одновременную работу х можно ли считать, что она завершена? Положительный ответ на этот вопрос, скорее всего, будет означать, что для данной системы выполняются и остальные критерии

разработки.

Критерии, выражаемые в измеряемых единицах

Я уже упоминала, насколько важно определить критерии, выражаемые в измеряемых единицах. Если вы успешно справитесь с этой задачей, многие оставшиеся критерии определятся сами собой. Например, если цель - сократить время вычисления в два раза, и на данный момент время вычисления составляет 10 минут, очевидно, что

ЧАСТЬ 2 тте реляционных систем баз данных

критерий разработки будет формулироваться так: Обеспечить время

вычисления, не превышающее 5

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

При определении критериев разработки в измеряемых единицах не следует слишком углубляться в детали, относящиеся непосредственно к реализации. Например, может оказаться, что для завершения некоего процесса за время, не превышающее 1 минуты, необходимо, чтобы время выполнения одного из запросов не превышало 10 секунд. Но ограничение, налагаемое на время выполнения запроса, относится к реализации, а не к критериям разработки, и на данной стадии вы еще не настолько четко представляете себе все детали проекта, чтобы принимать решения, относящиеся к реализации.

Критерии, определяемые внешним окружением

Большинство ограничений, налагаемых внешним окружением, связаны с вычислительными средами - операционными и другими системами, с которыми придется взаимодействовать разрабатываемой системе. Случаи, когда приходится начинать проектирование с чистого листа, весьма редки. Вероятнее всего, у вашего клиента уже есть установленное и налаженное оборудование и программное обеспечение, и предполагается, что ваша система будет работать в этой среде.

Очень важно правильно оценить объем обрабатываемых данных. Однажды, работая независимым консультантом в региональном представительстве компании, занимавшейся продажей компьютеров и комплектующих к ним, я допустила серьезнейшую ошибку. Требовалось составить техническое предложение для разработки системы регистрации и учета числа продаж. Обсудив с заказчиком требования к системе, я составила предложение с описанием системы на основе Microsoft Access 2.0, позволяющей регистрировать число продаж в региональном представительстве. Но затем выяснилось, что нужно было разработать систему, позволяющую вести учет продаж в рамках всей компании, к тому времени насчитывавшей более 500 региональ-