5.3. Координация работы с внешними группами

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

Процесс разработки приложений MSF

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

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

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

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

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

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

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

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

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

Ряд недостатков:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как и модель водопада, спиральная модель порождает множество проблем - недостатки:

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

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

Это ведет к утрате ориентации и

резкому снижению полезности проекта.

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

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

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

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

новых версий продукта на компьютеры пользователей.