Software & Systems

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

Гибкая разработка ПС – это концептуальный каркас для реализации проектов программной инженерии. Она устанавливает первостепенной ценностью непосредственно разработку ПС, а все остальные активности (написание проектной документации, поддержание моделей архитектуры ПС и т.п.) являются второстепенными. Гибкие методы ставят своей целью разработку ПС в срок, в рамках установленного бюджета и, самое важное, они стремятся создать ПС именно таким, каким его хочет видеть заказчик. Два первых постулата манифеста методологии гибкой разработки ПС гласят [1]:

- наивысший приоритет отводится удовлетворению заказчика;

- приветствуется изменение требований.

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

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

Таблица

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

Гибкие методы разработки делают акцент непосредственно на разработке ПС. Для эффективного ведения разработки необходим набор определенных принципов и практических приемов. Именно поэтому всегда необходимо рассматривать и считаться с идеями XP. В основе XP лежат следующие четыре принципа: коммуникация, предельная простота, обратная связь, требовательность к команде разработчиков-профессионалов.

Эти принципы привели к следующим идеям, составляющим основу XP:

- парное программирование;

- всегда оставаться на связи с заказчиком;

- тестирование упреждает разработку;

- короткие итерации;

- все должно быть максимально простым;

- не разрабатывать ничего лишнего без непосредственного требования заказчика;

- коллективное владение проектом.

Безусловно, гибкое моделирование и XP способствуют эффективной разработке ПС. Существует даже такой метод, как XP масштаба предприятия (EXP – Enterprise XP), суть которого и состоит в объединении XP и гибкого моделирования [1]. Однако ни XP, ни гибкое моделирование не касаются планирования проекта. Но для заказчика важно не только качество ПС, но также время его разработки и бюджет. Без хорошего планирования вероятность успеха любого проекта снижается многократно. Разработка, ведомая функциями (FDD), добавляет необходимый элемент контроля.

Согласно FDD, функция – это такое требование, реализация которого запланирована и связана с определенной активностью по его реализации. То есть функции связывают требования с планированием. FDD предполагает наличие жестко определенных временных рамок, которые отводятся на реализацию набора функции. Эти временные рамки, набор функций (запланированных к реализации требований), их приоритеты и определяют итерацию в FDD [2].

Суммируя сказанное, предлагаем метод разработки ПС на основе:

1) метода гибкого моделирования, что позволяет создать архитектуру ПС;

2) принципов XP, что позволяет эффективно разрабатывать ПС;

3) метода FDD, что дает управление проектом.

Предлагаемый метод предполагает наличие следующих этапов реализации ПС:

- инициация – создание общей картины решаемой задачи, проектирование и планирование;

- этап итераций – процесс реализации и поставки работающего ПС, при котором на каждой итерации реализуются новые требования и, возможно, изменяются старые;

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

На рисунке 1 приведена взаимосвязь предлагаемых этапов разработки.

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

На рисунке 2 пояснена итеративность предлагаемого метода разработки ПС.

Описание процесса разработки ПС предполагает определение ролей команды разработчиков. Как показывает анализ литературы, для работы с гибкими методами необходимо наличие команды профессионалов [3]. Именно люди, а не технологии или методы, определяют успех проекта. Предлагаемая данным методом модель ролей команды разработчиков приведена на рисунке 3.

Модель основана на ролях команды MSF, а также на ролях команды DSDM. Следует рассмотреть каждую из предлагаемых ролей в отдельности.

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

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

Целью программиста является разработка ПС согласно спецификации. В его обязанности входит: оценка времени и сложности каждой задачи; разработка (программирование) ПС; подготовка ПС к поставке.

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

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

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

Следует отметить, что приведенная модель не содержит роли архитектора ПС. Это объясняется тем, что при постоянно изменяющихся требованиях архитектуру ПС предлагается получать исходя исключительно из требований. Определять программную архитектуру должны сами программисты и менеджер проекта. При этом должен использоваться метод гибкого моделирования. Причем на его основе должны быть созданы модели, лишь поясняющие архитектуру ПС. Детальная же архитектура должна строиться на основе требований автоматически. Тогда задача получения программной архитектуры будет сведена к получению отображения требований в компоненты программной архитектуры [4]. Требования могут быть заданы в виде множества R: , где nR – количество требований; – i-е требование; – множество значений j-го атрибута; nA – количество атрибутов.

Для задания связей между требованиями используются матрицы трассируемости, или списки трассируемости. Трассируемость требований документирует зависимости и логические связи отдельных требований и других элементов ПС [5]. Матрица трассируемости может быть представлена как квадратная матрица размерностью nR× nR:

,

где

– требования; R – множество требований; nR – количество требований.

Отдельное требование или группа логически связанных требований реализуется в виде отдельного компонента ПС. Пусть C – множество таких компонентов: , где ci – i-й компонент ПС; nC – количество компонентов ПС.

Необходимо задать отображение множества требований R во множество компонентов ПС C:

или ,

где .

Приведенные рассуждения показывают возможность получения программной архитектуры на основе требований. Более того, существует возможность автоматизировать этот процесс, и автоматически получать программную архитектуру на основе требований [4]. Такой подход гарантирует целостность (согласованность) требований и их реализации.

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

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

Список литературы

1. Hunt J. Agile Software Construction – Springer-Verlag London Limited, 2006, 254 p.

2. Palmer S.R., Felsing J.M. A Practical Guide to Feature-Driven Development – Prentice Hall, 2002, 304 p.

3. Boehm B. Get Ready for Agile Methods, with Care // IEEE Software Development – Jan 2002, p. 64 – 69.

4. Бахтизин В.В., Неборский С.Н. Создание управляемой программной архитектуры // Программные продукты и системы – № 3. - 2006. – С. 2 – 5.

5. Вигерс К. Разработка требований к программному обеспечению. - Издат.-торг.дом «Русская Редакция», 2004.