Клочков / lek_rista_ob3

4

Процесс разработки

В этой главе

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

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

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

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

•Microsoft Solutions Framework;

•Уокер Ройс (Walker Royce) «Software Project Management: A Unified Framework» (Addison Wesley,

•Грэйди Буч (Grady Джеймс Рамбо (James Ивар Джекобсон Jacobson) «The Unified Modeling Language User (Addison Wesley. 1998);

•Ивар Джекобсон (Ivar Jacobson), Грэйди Буч (Grady Booch), Джеймс

Рамбо (James «The Unified Software Development (Addison Wesley,

Изучив материал этой сможете:

модель модель и их недостатки; перечислить процесса;

описать модели универсального охарактеризовать фазы модели разработки

в рамках модели процесса описать взаимосвязь переменных и

и достижения

проект для этапов:

проекты разработки ПО для целей проекта.

Модели разработки приложений

Любой проект разработки программного обеспечения в своем разви тии проходит определенный жизненный цикл —

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

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

Модель водопада

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

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

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

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

Сбор

Анализ

Проектирование

Кодирование и тестирование модулей

Интеграция системы

Интегральное

тестирование

Рис. 4.1. Модель водопада

•Выявление причин, необходимо проект на по здних стадиях — при использовании модели водопада это обычное

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

•Неадекватное управление рисками — риски, связанные с проектом, выявляются на поздних стадиях выполнения проекта.

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

•Ограниченные возможности обмена — традиционная практика предусматривает однократное рецензирование по окон чании каждой стадии проекта. Отсутствие постоянного обмена информацией ведет к излишнему вниманию к деталям и может вылиться в непонимание между участниками проекта.

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

4

проекта не проверяются, а правильность их решения принимает ся за аксиому.

Спиральная модель

Применение более современных методов привело к появлению ите подхода к управлению разработки — так на зываемой спиральной модели, проиллюстрированной на рис. 4.2. Эта

модель подразделяется на следующие стадии:

•исследование — анализ требований и предварительное планирова

ние;

•проработка — проектирование приложений;

•переходный оценка и стабилизация приложения;

• реализация приложения.

Уокер Ройс в своей книге «Software Project Management: A Framework» отмечает, что каждая из этих стадий обычно подразделя ется на пять фаз: сбор требований, проектирование, реализация, раз вертывание и В рамках спиральной модели процесс раз работки состоит из упомянутых выше четырех стадий, на каждой из которых эти пять фаз выполняются многократно. Например, на ста дии исследования может понадобиться четыре итерации, то есть че тырехкратное выполнение цикла. Цель итерационного подхода — до биться последовательного уточнения характеристик и архитектуры продукта, которое обеспечивает его постоянное приближение к окон чательному виду.

Оценка и стабилизация

Рис. 4.2. Спиральная модель

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

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

•Никогда не проекты — проекты, реализуемые по спиральной модели, часто начинают жить собственной жизнью,

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

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

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

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

процесс

Этот раздел основан на материале книг Уокера Ройса «Software Project Management: A Unified и Ивара Джекобсона, Грэйди Буча и Джеймса «The Unified Software Development Process», но с учетом нашего собственного опыта разработки. Если вас интересует точное и детальное обсуждение универсального процес са, обратитесь к перечисленным книгам.

процесс (Unified Process, UP) — широко распро страненный метод анализа, проектирования и разработки приложе ний масштаба предприятия. Основные характеристики этого процес са, базирующегося на универсальном языке моделирования, таковы:

•сценарии использования как основа проекта;

•приоритет архитектуры;

•итерационный и инкрементальный процесс разработки;

•прогнозирование рисков;

•объектно и сервисно ориентированное проектирование;

•активное накопление и повторное использование объектно ори ентированных шаблонов, объектов и кола.

Этапы

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

• — сбор технических и прикладных требова ний к проекту.

• — бизнес и прикладное моделирование на основе собран ных требований.

•Проектирование — создание архитектуры на основе объектно ори

ентированного подхода.

•Реализация — разработка спроектированного приложения (на ран них стадиях — разработка прототипов).

•Тестирование — проверка сделанной работы.

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

Требования

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

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

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

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

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

Схемы использования должны быть понятны заказчику и пользователю.

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

• (или модель предметной области), задающая кон текст проектируемой системы;

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

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

•набор набросков пользовательского интерфейса и прототипов для

каждого актера, проект пользовательского ин терфейса

• список дополнительных требований, не относящихся к конкрет ным схемам использования.

Анализ

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

Уточнение и абстрагирование требований на этом этапе служит ос новой проектирования. Ивар Джекобсон и его соавторы характери зуют этап «Анализ» и его результаты следующим образом:

•уточнение требований, сформулированных на предыдущем включая уточнение модели сценариев использования;

•аналитическая формулируется на языке разработчиков, и поэтому на этапе «Анализ» появляется формализм, позволяющий судить о внутренней структуре системы:

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

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

Основной результат этапа «Анализ» — архитектурное представле ние аналитической модели. Это представление включает следующее:

•Анализ в том числе пограничные, элементные и управля ющие классы. Пограничные классы располагаются между пользо

вательскими ролями (актерами в терминологии универсального языка моделирования) и внутренними структурами приложения; они, как правило, являются идеальными кандидатами на роль сер висов представления или сервисов. Элементные

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

циями и т. д.

•Анализ реализации схем использования — Джекобсон и др. опреде

ляют это как аналити ческой описывающее конкретной схемы исполь зования в терминах классов и объектов, выделенных на стадии ана

лиза».

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

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

Проектирование

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

На этапе выполняются следующие работы:

•определяются структуры подсистем (проектная модель);

подсистемы распределяются между уровнями (проектная модель);

определяются интерфейсы классов и объектов (проектная

• активные классы связываются с узлами развертывания (модель развертывания).

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

Реализация

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

Этап «Реализация» состоит из:

•реализации прототипа архитектуры;

•реализации компонентов (классов и объектов);

•тестирования компонентов;

•интеграции компонентов;

•сборки приложения:

•создания тестов на основе схем использования;

•проверки архитектуры;

•планирования следующей сборки;

•переходу к следующей итерации.

Тестирование

Цель этого сверка достигнутых результатов с ожидаемыми. Тестирование начинается по окончании этапа «Реализация» незави симо от того, выпуском какого типа — внутренним, промежуточным или внешним завершается этот этап. На каждой итерации тестовая модель уточняется: из нее изымаются тесты, утратившие

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

Фазы

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

•фаза «Исследование» предназначена для создания модели пред метной области;

•итерации фазы «Проработка» ставят своей целью создание базо вой архитектуры;

•итерации фазы «Создание» преследуют цель создания продукта пу

тем последовательного выпуска версий с постепенно расширяю

•переходный период необходим для проверки готовности продукта

кэксплуатации.

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

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

Число итераций этой фазы трудно предсказать заранее, однако обыч но оно не превосходит двух, а основное внимание уделяется этапу «Сбор требований». Задачи фазы «Исследование» четко определены ее целями: описание основных характеристик ние вероятности реализации основных рисков и подготовка обосно

вания проекта с точки зрения его связи с основными задачами биз неса. На этой стадии:

• выделяется область действия системы, то есть опреде ляются границы применения приложения и его взаимоотношения с другими системами;

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

• выявляются основные риски, а также составляется план ния рисками, направленный на снижение вероятности их возни кновения и адекватную реакцию в случае реализации риска;

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

Фаза завершается формулировкой целей проекта.

Проработка Как и фаза «Исследование», фаза обычно ограничива

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

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

•выявление основных рисков, включая план, стоимость и график управления ими на следующих стадиях;

•разработка методов оценки (метрик) включая надежность, число ошибок и производительность (скажем, время отклика);

•сбор схем использования, минимум 80% функцио нальных возможностей приложения;

•подготовка заявки на выполнение включая график, состав группы и стоимость проекта.

Фаза «Проработка» завершается созданием архитектуры прило жения.

Создание

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

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

На стадии «Создание»:

•расширяется список схем включая уточнение, дета лизацию и описание всех схем;

• выполнение первых трех этапов;

•начинается тестирование на этой фазе при мерно 15% этапа

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

• ведется управление рисками, выявленными на предыдущих стадиях.

Фаза «Создание» завершается этапом «Готовность к опытной экс плуатации».

Переходный период

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

В переходный период проводится:

•подготовка развертывания, включая подготовку инфраструктуры организации и узлов развертывания, а также информирование за

казчика о необходимых изменениях;

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

•оптимизация приложения для работы в эксплуатационных условиях;

•устранение проблем, выявленных при бета тестировании;

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

Итерации

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

Рис. 4.3. Распределение этапов на разных стадиях проекта

Кроме того, фазы «Исследование» и «Проработка» требуют повы шенного внимания к управлению проектом и к организации среды разработки.

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

Джекобсон также приводит несколько важных последствий ите рационной и инкрементальной природы универсального процесса.

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

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

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

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

•Единственная возможность избежать выпуска которые устарели еше до выпуска, — перестать игнорировать изменения.

Итерационный подход, включающий разные фазы, позволяет учи тывать изменения по мере выполнения проекта.

Модель процесса разработки MSF

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

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

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

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

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

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

Одобрение

концепции

Одобрение плана проекта

Рис. 4.5. Модель процесса разработки

Модель процесса разработки MSF имеет три отличительные осо бенности:

•разбиение на фазы (рис. 4.5);

•контроль выполнения работ на каждой фазе;

•итеративность (стрелка на рис. 4.5 возвращает процесс к первой фазе).

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

Фазы

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

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

•Анализ, цель которого — выработать единую концепцию проекта.

•Проектирование, результаты которого — подробный план проек та и архитектура приложения.

•Разработка, цель которой — создание полнофункционального

продукта.

• задача которой — создание стабильного продукта, готового к

Этапы

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

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

ектная группа может считать этап пройденным.

Основные этапы

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

— момент, когда все участники проектной группы могут и должны со гласовать результаты своей работы. Кроме того, именно тогда внешние (по отношению к проектной группе) участники (заказчик, пользовате

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

Промежуточные этапы

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

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

Итеративность

Одна из важнейших особенностей модели процесса разработки

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

Фазы процесса разработки и их основные результаты

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

Фаза

Цель фазы «Анализ» — выработать единую проекта для всех его участников. Единая концепция предполагает наличие следу ющих составляющих.

•Согласованное всеми сторонами понимание бизнес проблемы, на ре шение которой направлен проект — не раз случалось, что, только

закончив разработку понимала, что приложе ние решает не ту проблему, которую ставил заказчик. У подобно

го финала могут быть разные однако чаще всего это недостаточно тесное взаимодействие с заказчиком, особенно на ран

них стадиях проекта. Избежать этого можно только одним способом

— убедиться, что проектная группа правильно представляет себе биз нес проблему, прежде чем она приступит к созданию продукта.

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

себе технологии, чем прежде. Вполне возможно, что у заказ чика есть свое мнение о будущем продукте и связанные с этим ожидания. Важная часть фазы «Анализ» — выяснение мнения за казчика и его связанных с продуктом, на ранней ста дии проекта. Мы уже говорили в главе 3, что взаимодействие с за казчиком и согласование точек зрения на продукт — обязанность менеджера продукта.

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

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

•более полным осознанием требований заказчика;

•изменением бизнес требований;

•выявлением технических проблем или рисков;

•необходимостью привести в соответствие сроки выполнения про екта, нужные ресурсы и характеристики продукта.

Концептуальное видение проекта, создаваемое на стадии «Ана лиз», позволяет очертить его рамки и готовит почву для более деталь ного и формального планирования, которое выполняется на следую щей стадии.

Этап «Одобрение концепции»

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

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

Перечислим результаты, которые необходимы для достижения

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

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

Одобрение концепции означает, что проектная группа, заказчик и другие основные участники проекта согласовали:

• на решение которых направлен проект;

• продукта;

•цели проектирования;

•риски, связанные с запуском проекта;

•базовую концепцию бизнес решения;

•принципы управления проектом и состав проектной группы.

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

Фаза

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

Почему планирование столь важно? Причина проста: чем раньше обнаружены недостатки проекта, тем дешевле обходится их устране ние. Относительная стоимость проектных ошибок, выявленных на разных стадиях выполнения проекта, проиллюстрирована рис. 4.6. Диаграмма ясно показывает, что планирование приносит плоды, снижая расходы времени и ресурсов на устранение проблем на заключительных стадиях проекта.