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

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

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

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

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

расходу бюджета.

Второй случай - когда заказчик настаивает на реализации данной

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

Стоимостный анализ

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

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

ГЛАВА деление параметров системы

позволяет окупить затраты на системы в кратчайший срок.

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

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

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

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

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

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

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

видно, что единицы измерения затрат и выгод могут не совпадать.

ЧАСТЬ 2 систем баз

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

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

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

затрат в некоторых производных величинах, например в единицах работ1 . Таким образом, стоимостный анализ не превратится в смету проекта или в план внедрения системы.

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

ленте. Однако экономический эффект, ожидаемый от повышения точности ввода данных, в денежном эквиваленте не так лег-

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

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

функций назначить более высокий приоритет: той, для которой отношения нриб1лей и затрат - 3/6/2 или той, для которой соответствующие показатели составляют 6/2/3. Избежать такой ситуации можно, если привести все к некоему общему знаменателю,

чтобы для каждой однозначную оценку ее полез-

ности.

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