Программирование >>  Реализация целостности данных 

1 ... 41 42 43 [ 44 ] 45 46 47 ... 124


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

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

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

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

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

По правде говоря, само понятие в применении к системе

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

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

Впрочем, я не предполагаю, что вы собираетесь ставить

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

се не обязательно знать, что начальник отдела фирмы, для которой вы

разрабатываете систему, активно пользуется Интернетом. Гораздо более важно следующее: чтобы система оправдывала себя, среднее время обработки одного заказа должно сократиться с 10 до 2 минут.

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



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

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

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

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

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



ЧАСТЬ 2 чттотых систем баз данных

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

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

работы во многом - ведь схожи и конечные цели, которым

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

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

они должны стать, когда система будет запущена в эксплуатацию?

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

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

программного продукта по розничной цене 2,5 тыс.

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



1 ... 41 42 43 [ 44 ] 45 46 47 ... 124

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика