Модели проектных групп

Курсовая работа

на тему: «Модели проектных групп»

1. Модель Microsoft Solutions Framework (MSF)

1.1 Принципы, концепции и методики MSF

1.2 Жизненный цикл MSF

1.3 Обзор модели команды MSF

2. Модель Rational Unified Process (RUP)

2.1 Предназначение RUP

2.2 Жизненный цикл RUP

2.3 Методология RUP

3. Модель Extreme Programming (XP)

3.1 Ориентация, принципы и практика XP

3.2 Методология XP

3.3 Жизненный цикл XP

4. Сравнение технологий MSF, RUP и XP

Заключение

Список использованной литературы

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

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

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

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

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

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

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

Объектом исследования являются модели проектных групп, а предметом — сравнение современных методологий проектных групп.

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

1. Модель Microsoft Solutions Framework (MSF)

1.1 Принципы, концепции и методики MSF

Существует две основные модели организации коллектива при разработке ПО:

1) иерархическая модель

2) модель группы

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

Недостатки иерархической модели:

· нехватка информации;

· невозможность учесть все особенности проекта;

· отсутствие полноценной связи между всеми участниками проекта, так как вся информация идет в одном направлении — вверх по иерархии, к главному менеджеру;

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

· сложность расстановки приоритетов.

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

Поэтому для анализа современных решений необходимо использовать модель (рис. 1), представляющую собой иерархию уровней управления процессом разработки ПО.

Рис. 1. Иерархия уровней управления процессом разработки ПО

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

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

Далее в курсовой работе поочередно будут рассмотрены современные модели проектных групп: Microsoft Solutions Framework (MSF), Rational Unified Process (RUP) и Extreme Programming (XP).

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

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

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

Основные принципы:

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

· наделение членов команды необходимым для работы уровнем полномочий;

· концентрация на бизнес-приоритетах — необходимость принятия решений проектной группой на основе полного понимания бизнеса заказчика и при активном его участии в реализации проекта;

· единое видение проекта, формирующего целостный подход проектной группы к разработке IT-решения;

· гибкость, переменчивость - присутствие всех командных ролей и их вовлеченность в процесс принятия решений, обусловленных происходящими переменами;

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

Ключевые принципы:

· команда соратников — равноправное положение каждой из ролей в команде;

· сфокусированность на нуждах заказчика — обязательное понимание его бизнес-задач и стремление к их решению со стороны команды;

· нацеленность на конечный результат;

· установка на отсутствие дефектов;

· стремление к самосовершенствованию;

· создание заинтересованности и высокого морального духа команды;

Испытанные методики:

· создание малых многопрофильных проектных групп — большая оперативность действий в сравнении с крупными коллективами;

· коллективная работа — меньше препятствий для эффективного обмена информацией;

· всеобщее участие в проектировании.

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

Внедрение модели проектной группы MSF уже помогло компании Damgaard выпустить в срок новую систему управления предприятием АХАРТА, используемого более чем в 20 странах мира, компании Navision — увеличить штат разработчиков в несколько раз без дополнительных затрат на обучение, группе разработчиков из Unitied Airline — создать крупнейшую в мире систему резервирования авиабилетов в срок и без перерасхода выделенного бюджета.

Внедрение модели MSF необходимо для любой растущей компании. В частности Damgaard и Navision внедрили MSF Team model именно в тот момент, когда начался интенсивный рост численности разработчиков. В соответствии с данной модель были четко определены обязанности каждого члена команды.

1.2 Жизненный цикл MSF

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

Рис. 2. Модель жизненного цикла MSF

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

Основными фазами модели MSF являются:

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

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

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

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

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

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

Рис.3. Треугольник приоритетов в MSF

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

1.3 Обзор модели команды MSF

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

* Управление программой (program management)

* Разработка (development)

* Тестирование (test)

* Управление выпуском (release management)

* Удовлетворение потребителя (user experience)

* Управление продуктом (product management)

Эти задачи обуславливают модель проектной группы. Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Поскольку каждая из целей одинаково необходима для успешности проекта, все роли находятся в равноправных партнерских взаимоотношениях с равной значимостью при принятии решений. Чаще всего роли распределяются среди различных подразделений одной организации, но иногда часть их отводится сообществу потребителей или внешним по отношению к организации консультантам и партнерам. Ключевым моментом является четкое определение работников, ответственных за каждый ролевой кластер, их функций, ответственности и ожидаемого вклада в конечный результат.

Цели, области компетенции, а также функции ролевых кластеров представлены в таблице 1.

Таблица 1

А взаимодействие ролевых кластеров представлено на рис. 4.

Рис. 4. Ролевые кластеры модели проектной группы MSF

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

При этом должны соблюдаться два принципа.

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

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

2. Модель Rational Unified Process (RUP)

2.1 Предназначение RUP

Rational Unified Process — это модель создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой.

Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов.

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

RUP способствует повышению производительности коллективной разработки и предоставляет лучшее из накопленного опыта по созданию ПО, посредством руководств, шаблонов и наставлений по пользованию инструментальными средствами для всех критически важных работ, в течение жизненного цикла создания и сопровождения ПО. Обеспечивая каждому члену группы доступ к той же самой базе знаний, вне зависимости от того, разрабатывает ли он требования, проектирует, выполняет тестирование или управляет проектом — RUP гарантирует, что все члены группы используют общий язык моделирования, процесс, имеют согласованное видение того, как создавать ПО. В качестве языка моделирования в общей базе знаний используется Unified Modeling Language (UML), являющийся международным стандартом.

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

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

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

RUP описывает, как эффективно применять коммерчески обоснованные и практически опробованные подходы к разработке ПО для коллективов разработчиков, где каждый из членов получает преимущества от использования передового опыта в:

* итерационной разработке ПО,

* управлении требованиями,

* использовании компонентной архитектуры,

* визуальном моделировании,

* тестировании качества ПО,

* контроле за изменениями в ПО.

RUP организует работу над проектом в терминах последовательности действий (workflows), продуктов деятельности, исполнителей и других статических аспектов процесса с одной стороны, и в терминах циклов, фаз, итераций и временных отметок завершения определенных этапов в создании ПО (milestones), т. е. в терминах динамических аспектов процесса, с другой.

2.2 Жизненный цикл RUP

Модель жизненного цикла RUP является довольно сложной, детально проработанной итеративно — инкрементной моделью с элементами каскадной модели. В модели RUP выделяются 4 основные фазы, 9 видов деятельности (процессов). Кроме того, в модели описывается ряд практик, которые следует применять или руководствоваться для успешного выполнения проекта. RUP ориентирован на поэтапное моделирование создаваемого продукта с помощью языка UML (Рис.5).

Рис.5. Жизненный цикл RUP

Основными фазами RUP являются:

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

2. Фаза проработки (Elaboration). Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используются как основа разработки системы.

3. Фаза построения (Construction). Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры.

4. Фаза передачи (Transition). Цель фазы — сделать систему полностью доступной конечным пользователям. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей.

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

Деятельности (основные процессы) RUP делятся на 5 рабочих и 4 поддерживающие. К рабочим деятельностям относятся:

1. Моделирование предметной области (бизнес — моделирование, Business Modeling). Цели этой деятельности — понять бизнес — контекст, в котором должна будет работать система (и убедиться, что все заинтересованные лица понимают их одинаково), понять возможные проблемы, оценить возможные их решения и их последствия для бизнеса организации, в которой будет работать система.

2. Определение требований (Requirements). Цели — понять, что должна делать система, определить границы системы и основу для планирования проекта и оценок ресурсозатрат в нем.

3. Анализ и проектирование (Analysis and Design). Выработка архитектуры системы на основе ключевых требований, создание проектной модели, представленной в виде диаграмм UML, описывающих продукт с различных точек зрения.

4. Реализация (Implementation). Разработка исходного кода, компонент системы, тестирование и интегрирование компонент.

5. Тестирование (Test). Общая оценка дефектов продукта, его качество в целом; оценка степени соответствия исходным требованиям.

Поддерживающими деятельностями являются:

1. Развертывание (Deployment). Цели — развернуть систему в ее рабочем окружении и оценить ее работоспособность.

2. Управление конфигурациями (Configuration and Change Management). Определение элементов, подлежащих хранению и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений.

3. Управление проектом (Project Management). Включает планирование, управление персоналом, обеспечения связей с другими заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта.

4. Управление средой проекта (Environment). Настройка процесса под конкретный проект, выбор и смена технологий и инструментов, используемых в проекте.

2.3 Методология RUP

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

Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (то есть с официальным назначением рецензента, с предоставлением рецензентом достаточно полной рецензии в виде электронного или бумажного документа и т. д.) проводить все рецензирования, RUP представляет собой крайне формальную, тяжеловесную методологию. С другой стороны, RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности. Можно требовать детальной проработки и тщательного оформления каждого документа. Можно требовать предоставления столь же тщательно выполненной и оформленной рецензии. А можно ограничиться электронным письмом или наброском на бумаге. А, кроме того, всегда остается еще одна возможность — сформировать документ «в голове»: продумать соответствующий вопрос и принять соответствующее решение.

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

3. Модель Extreme Programming (XP)

3.1 Ориентация, принципы и практика XP

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

XP ориентирована на:

· командную работу с тесными связями внутри команды и с заказчиком;

· разработку наиболее простых работающих решений;

· гибкое адаптивное планирование;

· оперативную обратную связь (путем модульного и функционального тестирования).

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

Основными практиками XP являются:

Планирование процесса; частые релизы; метафора системы; простая архитектура; тестирование; рефакторинг; парное программирование; коллективное владение кодом; частая интеграция; 40-часовая рабочая неделя; стандарты кодирования; тесное взаимодействие с заказчиком.3.2 Методология XP

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

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

Экстремальное программирование, как процесс, даёт новое дыхание давно придуманным подходам к разработке программного обеспечения. Это такие подходы как Модульное тестирование (Unit testing), Переработка кода (Refactoring), Парное программирование (Pair programming), Нормированный рабочий день (40-hour week).

По результатам исследования, проведенного независимой компанией Spikes Cavell в Великобритании в финансовом секторе, основной причиной неудачи программных проектов является срыв сроков сдачи (75%). Так экстремальное программирование представляет возможности для гарантирования успеваемости и контроля сроков. Это достигается посредством эффективного планирования, автоматического контроля качества и формирования быстрых обратных связей, в том числе и с заказчиком.

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

3.3 Жизненный цикл XP

Модель жизненного цикла XP является итерационно-инкрементной моделью быстрого создания (и модификации) протопопов продукта, удовлетворяющих очередному требованию (user story). Жизненный цикл XP представлен на рис. 6.

Рис.6. Жизненный цикл XP

Особенности этой модели представлены на схеме. Основными фазами модели можно считать:

1. «Вброс» архитектуры — начальный этап проекта, на котором создается видение продукта, принимаются основные решения по архитектуре и применяемым технологиям. Результатом начального этапа является метафора (metaphor) системы, которая в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.

2. Истории использования (User Story) — этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. User Story являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.

3. Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования — получение оценок того, что и как можно сделать за 1−3 недели создания следующей версии продукта.

4. Разработка проводится в соответствии с планом и включает только те функции, которые были отобраны на этапе планирования.

5. Тестирование проводится с участием заказчика, который участвует в составлении тестов.

6. Выпуск релиза — разработанная версия передается заказчику для использования или бета-тестирования.

По завершению цикла делается переход на следующую итерацию разработки.

Особенности модели жизненного цикла XP проясняют следующие принципы этого метода. Прежде всего, это принципы «живой» разработки ПО, зафиксированные в манифесте «живой» разработки:

· Люди и их общение более важны, чем процессы и инструменты

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

· Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта

· Отработка изменений более важна, чем следование планам

Кроме того, как было выше сказано, в XP есть несколько правил (техник), характеризующих особенности модели его жизненного цикла:

1. Живое планирование (planning game) — как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в первую очередь, бизнес-приоритетов заказчика и, во-вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.

2. Частая смена версий (small releases) — первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.

3. Простые проектные решения (simple design) — в каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Новые функции добавляются только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

4. Разработка на основе тестирования (test-driven development) — сначала пишутся тесты, потом реализуются модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.

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

6. Программирование парами (pair programming) — весь код пишется двумя программистами на одном компьютере, что повышает его качество (отсутствие ошибок, понятность, читаемость,…).

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

8. 40-часоваярабочаянеделя — сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.

4. Сравнение технологий MSF, RUP и XP

Основные особенности MSF, RUP и XP можно свести в небольшую таблицу (Таблица 2). По ней можно судить, что Rational Unified Process является хорошо сбалансированным решением для средних по размерам коллективов разработчиков, работающих с применением продуктов и технологий компании Rational. Сопровождение разработки системы и самой системы регламентируется самой методологией RUP, однако данная технология достаточно сильно ориентирована на внутрифирменные инструментальные средства.

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

Таблица 2. Технологии MSF, RUP и XP

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

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

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

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

Преимуществами XP являются:

· простота в использовании, адаптации, обучении;

· устойчивость к внешним факторам, таким как текучесть кадров, нехватка денег, внезапное завершение финансирования;

· учёт изменчивости требований и кардинального пересмотра всей системы;

· равномерная загруженность всех членов коллектива;

· быстрое включение в работу новичков с минимальным уровнем риска;

· эффективный контроль работоспособности разрабатываемых систем;

· увеличение производительности разработчиков;

· предоставление дополнительных благ членам коллектива;

· естественный профотбор членов команды;

· низкая степень бюрократизма;

· широкая известность и популярность.

От других известных методологий разработки его также отличает простота, низкая стоимость внедрения и общедоступность. По сравнению с известным процессом разработки Rational Unified Process (RUP), время интенсивного внедрения его в несколько раз меньше. Если внедрение RUP может занять от полугода до двух лет, то внедрение XP может быть выполнено в течение одного-двух месяцев. При этом сама технология RUP стоит около 600 $. И это не считая сопутствующих программ, обучающего материала и повышенного требования к персоналу.

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

RUP:

Заказчик должен подготовить документы, необходимые для внесения изменения и предоставить руководителю группы разработчиков на рассмотрение. При этом язык изложения требования должен быть строго формализованным, например Диаграмма прецедентов (Use-case diagram). После первоначального рассмотрения передать запрос менеджерам, которые в свою очередь передадут его аналитикам.

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

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

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

Тестирование моделей.

Отдел тестирования должен внести соответствующие изменения в тест-план. После подготовки всех необходимых документов, программисты приступают к кодированию, при этом отсутствие любого члена команды грозит срывом сроков сдачи. Этот этап является самым непродолжительным, примерно 10% от всего времени на изменение.

Уточнение моделей. Тестирование изменившейся части. Тестирование системы в целом

XP:

Заказчик тесно общается с разработчиками и знает, что изменения могут быть внесены достаточно просто. Поэтому он не боится предлагать внести изменения, когда это действительно необходимо. Он формирует запрос на изменение в виде истории пользователя (User story), на понятном человеческом языке.

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

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

Один из программистов (или пара) берёт на себя ответственность за выполнение данной истории и приступает к работе. Это может быть не тот человек, который разрабатывал эту область ранее, за счёт коллективного владения кодом.

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

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

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

Так, при работе по XP основное внимание сосредоточенно вокруг заказчика и разработчика. Это позволяет избежать неточностей понимания и постановки задачи. Мелочи и неточности, а также несвоевременно внесённые изменения, в совокупности, представляют почву для провала проекта. Программист уверен в своих действиях и работоспособности системы за счёт постоянной обратной связи с системой (автоматические тесты) и с заказчиком (быстрые релизы). Минимизироавнное число сопутствующих документов позволяет не только съэкономить время, но и сократить штат задействованных специалистов.

Ролей в XP также не так много, и здесь нет ограничений на совместимость их в рамках одного человека. Так, если следовать учению Microsoft Solution Framework (MSF), то программист не может быть одновременно менеджером, тестировщиком или техническим писателем. Хотя опыт показывает обратное, что, в свою очередь, является оправданной и довольно успешной практикой. В экстремальном программировании это даже приветствуется. Так, например, опытный программист может достойно совмещать, помимо своих основных обязанностей, роль тренера, наблюдателя и менеджера. Да, действительно, в Microsoft произвели ряд дорогостоящих исследований, которые показали определённую несовместимость ролей. Разработчики же экстремального программирования, глядя глубоко в корень, постарались устранить причину этой несовместимости. Это стало возможным за счёт усиления обратных связей, неявного автоматизированного и мануального контроля.

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

Заключение

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