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

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

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

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

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

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

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

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

Я рекомендую нащупать брод, прежде чем переправляться через реку. Если заказчик упорно не желает отвечать на ваши вопросы, объясните ему, что ваша работа принесет пользу только в том случае, если вы вникнете в бизнес-процессы компании. Если же и это не поможет, придется либо реализовать систему так, как того желает заказчик, либо отказаться от проекта (последнее, не всегда Самое большее, на что вы можете рассчитывать - это пересмотр готового которое вам предложили. Если вы обнаружите в нем серьезные обсудите их с заказчиком. Скажите, например: Я не могу этого сделать; однако я могу сделать то-то

или то-то. Какой вариант вам больше подойдет?

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

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

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

Безусловно, я отнюдь не предлагаю создавать централизованное хранилище данных, охватывающее все предприя-

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

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

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

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

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

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

ГЛАВА 7 т& параметров системы

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

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

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

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

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

реализации. Это может быть обусловлено многими объективными

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

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

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