Клочков / lek_rista_ob3

прототипе, и проверенных В боль ших проектах таких выпусков может быть несколько; мы дуем выпускать по крайней мере альфа и бета версию во всех проектах, кроме самых незначительных . Альфа версия отвечает на вопрос: «Вот так технология и интерфейс выглядят вместе. Есть ли какие то серьезные а «Мы решили все основные проблемы и большинство мелких. Мы ничего не упусти Эта фаза разработки созданием «золотой» версии.

• «Золотая» версия — на именно эта версия передается ограниченному кругу для тестирования. По мере выявления и устранения ошибок и проблем, связанных с производительностью, следом за ней развертываются следующие выпуски. «золотая» версия, которая появляется в конце стадии «Стабилизация», сигнализирует о завершении про екта и передаче результатов заказчику.

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

Роли членов группы в модели процесса разработки

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

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

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

Артефакты и результаты

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

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

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

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

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

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

* И чтобы при не потерялась. — Прим. ред.

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

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

ализации в проекте главной цели, выпуска стабильного полнофун кционального продукта в срок.

Связь моделей

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

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

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

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

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

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

Резюме

Разработка программного обеспечения — непростая работа. Как пи шет Джим Маккарти, несложную вовремя непро сто. Создать сложное приложение — достижение. Выпус тить сложное приложение, уложившись в график невероятная ред

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

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