Сколько будет стоить система?

Как оценить риски для данного проекта?

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

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

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

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

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

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

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

но, никто не может дать гарантии, что проектная

группа не умрет в результате эпидемии какой-либо опасной болезни

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

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

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

либо работ, обязательно надо. Обзор системы

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

не включили в начало документа формальное краткое

введение, поместите общую информацию в обзор системы, осветив

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

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

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

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

Если вы провели анализ цена тво>, включите в документ его результаты (не обязательно в раздел истемь! ). Я стараюсь не перегружать основной документ множеством ии. Поместите все подробности в приложения к документу - его станет значительно приятнее читать. Но конечно, вопрос вкуса.

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

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

Рабочие процессы

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

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

них множество мелких ошибок.

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

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

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

вашими соображениями, укажут вам на это.

Описание рабочих процессов - потенциальное поле битвы pai-личных групп читателей вашего документа. Разработчики при обсуждении рабочих процессов будут оперировать техническими терминами, вроде: транзакции были завершены, и данные С другой стороны, заказчики хотят увидеть описание процесса в привычных им терминах. Эти термины порой совпадают с техническими, а порой - сильно отличаются от них. Когда такая ситуация возникает, то правда всегда на стороне заказчика. Разработчики могут принять терминологию клиента, но не наоборот. Если в документе приходится использовать чисто технические термины, обязательно приведите тут же их подробное разъяснение.

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