vjanuBjicHbi как по смете и кадрам, так и по срокам сдачи, то

планирование на данном этапе будет играть существенную роль в деле обеспечения выполнения проекта.

Перепланирование

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

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

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

Две стадии проектирования

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

34 Oracle

Задачи проектирования

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

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

Проектирование: ранние стадии

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

Рассмотрение и принятие результатов анализа

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

Как проектировщики, мы не можем проверить, охватывает ли анализ все бизнес-области системы. Нам просто приходится принять это на веру. Что мы можем проверить, так это некоторые общие концепции и аксиомы. Вот несколько примеров:

Имеет ли каждая сущность уникальный идентификатор и хотя бы один Неключевой атрибут?

Имеет ли каждая сущность хотя бы одну функцию, создающую ее экземпляры, и хотя бы одну функцию, которая ссылается на нее?

Глава 1 Пи

Имеет ли каждый атрибут создателя и читателя ?

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

В нашем приложении-примере анализ проводится средствами Designer/2000. Запуская некоторые из окончательных отчетов, мы обнаруживаем отсутствие функции, которая создавала бы новые экземпляры сущности Rental Car. Мы сообщаем об этом аналитику, и он создает новую функцию. Мы замечаем также, что в некоторых функциях реализованы наброски структуры экранных форм. Мы их не отклоняем, поскольку из них можно получить кое-какую полезную информацию, но даем понять, что не можем гарантировать, гго формы, которые мы спроектируем, будут похожи на эти оригиналы.

Семинары и проверка того, как проектировщика понимают результаты анализа

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

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

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

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

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