представительств и имевшей оборот в несколько десятков миллионов долларов - такую систему, очевидно, было невозможно реализовать при помощи Microsoft Access 2.0. Я ошиблась, предположив, что заказчику требовалось лишь регистрировать и учитывать объемы региональных продаж. Полагаю, излишне говорить, что после этого фирма расторгла контракт со мной.

При оценке объема обрабатываемых данных следует обращать

внимание на два основных фактора. Первый - это чистый объем

данных, а второй - объема данных и его динамика. На-

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

При планировании системы важно учитывать, что ресурсы, выделяемые на поддержку зависят от объема данных, хранимых в системе. Здесь главное - не ошибиться в меньшую сторону. При оценке объема, который предполагается выделить для хранения данных, я рекомендую взять за основу цифру, на 10% превышающую максимум, полученный при проведении предварительного анализа. Эти 10% будут использоваться для выполнения различных служебных операций по поддержке данных. Для систем меньшего масштаба следует предусмотреть резерв в от основного объема данных. Чем больше масштаб системы, тем меньшую роль, как правило, играет объем данных. Хорошо спланированная клиент-серверная система может поддерживать объемы и в 10 тыс., и в ЮОтыс. записей без заметного изменения производительности. А вот распределенная многопользовательская система, реализованная на Access, рассчитана на поддержку лишь нескольких десятков тысяч записей, и, вероятнее всего, вам не удастся масштабировать ее до нескольких миллионов записей, вне зависимости от того, насколько хорошо она спланирована.

Основной фактор оценки критериев, определяемых внешним окружением - число пользователей системы. Для большинства систем

важны несколько различных категорий пользователей, и очевид-

ЧАСТЬ 2 баз данных

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

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

другие - запрашивать систему о статусах заказов и обновлять хранимые в системе данные, и третья группа пользователей

будет генерировать отчеты с использованием всех данных, хранимых

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

разработки.

Число пользователей, подключенных к системе, и число пользователей, активно работающих с ней, как правило, существенно различаются, Например, механизм баз данных Microsoft Jet может нод-держивать не более 255 пользователей, одновременно подключенных к базе данных, то есть база данных может быть открыта не более чем 255 пользователями одновременно. Однако это не

что все 255 человек смогут одновременно обновлять эту базу данных.

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

Некоторые цели проекта совсем не просто перевести на язык чисел и измеряемых величин. такую цель как точно-

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

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

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

собности клиента, - будут определяться на более поздних стадиях проектирования системы, когда станут ясней требования к ней.

При определении основных направлений избегайте пустых фраз.

Конечно, сложно спорить с утверждением, что Система должна быть разработана с учетом требований пользователя и предоставлять дружественный интерфейс - в кон не концов, вряд ли пользователи будут рады получить систему с враждебным для них интерфейсом. Но эта фраза не содержит абсолютно никакой полезной информации. В то же время критерий Систем:! должна быть разработана с учетом требований, изложенных в руководстве Windows Interface Guidelines for Software Design ( Руководство no разработке интерфейса для

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

Цель же вашей работы по формулированию критериев - не увеличивать, а уменьшать число разногласий и спорных моментов.

Определение масштаба и границ системы

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

быть реализованы в ней, а какие - нет. Как и критерии разработки,

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

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

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

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

С другой стороны, переопределение целей - процесс,

множество опасностей. Намеченный масштаб системы не подходит

для определения всех целей. Искушение расширить границы систе-