Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 [ 6 ] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

Начало

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

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

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

Исследование

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

Мы собираемся создать систему следующего поколения для заказчиков компании Watts Galore Utility Company и намерены использовать объектно-ориентированную технологию для построения более гибкой системы, которая будет в большей степени ориентирована на пользователей, в частности такую, которая будет поддерживать их консолидированные счета.

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

В этот момент желательно попытаться лучше понять суть проблемы:

Что вы на самом деле собираетесь создать?

Как вы собираетесь это сделать?

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

Исходя из моего опыта, риски полезно классифицировать на четыре категории:

1. Риски, связанные с требованиями. Каковы требования к системе? Большая опасность заключается в том, что вы построите совсем не ту систему, которая будет выполнять вовсе не то, что нужно пользователям.

2. Технологические риски. С какими технологическими рисками вам придется столкнуться? Действительно ли позволяет выбранная вами технология реализовать ваш проект? Каким образом следует интегрировать различные части проекта?

3. Риски, связанные с квалификацией персонала. Сможете ли вы подобрать штат сотрудников с необходимым опытом и квалификацией?

4. Политические риски. Существуют ли политические силы, которые могут оказаться на вашем пути и серьезно повлиять на выполнение вашего проекта?

В вашем случае рисков может быть и больше. Но те риски, которые попадают в эти четыре категории, присутствуют почти всегда.

Риски, связанные с требованиями

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

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

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

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

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

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

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

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

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

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

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

Заметим, что Рациональный унифицированный процесс определяет термин модель предметной области более тщательно. Эта тема детально изложена в книге Джекобсона, Буча и Рамбо, 1999 [23]. Я придерживаюсь точки зрения большинства известных мне разработчиков из объектного сообщества.

1 2 3 4 5 [ 6 ] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.

Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы.