ЧАСТЬ еЛйЦИОННЫХ систем баз данн1х

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

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

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

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

Задача 1. Проверить, все ли пункты заявки заполнены.

Задача 2. Обработать заказ.

Этап 1. Запросить данные о покупателе.

Этап 2. Записать информацию о поставке. 5таи J. Внестисвсдения о заказе.

Задача 3. Проверить кредит, которым располагает покупатель.

Этап 1. Навести справки о покупателе.

Этап 2. Проверить кредит.

Этап 3. Присвоить покупателю порядковый номер.

Задача 4. Завершить обработку заказа,

Этап 1. Проверить наличие товара.

Этап 2. Отправить заказ в отдел доставки.

Задачу 3 выполняет бухгалтерия, которая возвращает заказ в отдел продаж, только если покупатель располагает достаточным кредитом. Разумеется, остается проблема: первоначальные данные уже внесены. Дело не только в том, что, если у покупателя не было средств на счете, ранее выполнялась лишняя работа. Возникала также необходимость периодически удалять лишние заказы. это вело к что персонал, занятый вводом данных, постоянно разрывался между бухгалтерией и отделом продаж, которым требовалось заполнить заявки (и получить комиссионные). Изменение порядка выполнения

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

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

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

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

ГЛАВА 8 рабочих

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

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

эффективно организовать работу, то пересмотр рабочих процессов -

один из способов достичь этой цели.

Документирование рабочих процессов

Как и любые другие процесса проектирования, про-

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

телефонов потребуется не более часа на обсуждение и составление

кратких заметок для внутреннего

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

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

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

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

ЧАСТЬ 2 трепятотг систем данных

событие (например, начало и конец задачи). Мои собственные обозначения показаны на рис.

Задача

Докумек!

(Элемент данных) совыте Ри Символы рабочих процессов

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

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

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

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

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

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