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

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

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

Табл 1 Ожидаемый эффект от внедрения различных функций

Прибыль, $ Сэкономлен- Нематериаль- Сумма Сумма Среднее Среднее

(коэф- ные средства ные выгоды с учетом знэчение значение

фициеит 4) (коэф- (коэф- коэффн- с учетом

фициент 1) фициенг 2) циентов коэффициентов!

Функция! 3 6 2 И 22 3.6 7.3

Функция 2 Й 2 1 И 32 ;1.б. 10.6

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

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

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

это всего лишь инструмент, сделать соответству-

ющие и цифры, полученные в результате подобных

ни в коем случае нельзя принимать за непреложную истину и при проектировании системы руководствоваться только ими. Даже если в процессе стоимостного анализа обнаружится, что для функции X отношение прибылей и затрат окажется равным 12, для функции Y - 2, может быть принята ен не реализовать функцию Y в, первую очередь, а функцию X - во вторую.

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

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

Итоги

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

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

Определение рабочих процессов

ГЛАВА

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

телефонного номера клиента совместно образуют рабочий процесс,

хотя существенно различаются по степени сложности.

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

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

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