4. Сравнение технологий msf, rup и xp

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

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

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

Технология	Оптимальная команда	Соответствие стандартам	Допустимые технологии и инструменты	Удобство модификации и сопровождения
Rational Unified Process	10 – 40 чел.	стандарты Rational	UML и продукты Rational	Удобно(RUP)
Microsoft Solutions Framework	3 – 20 чел.	адаптируема	любые	Удобно(MSF+MOF)
XP	2 – 10 чел.	стандарты отсутствуют	любые	Сложно (зависимость от конкретных участников коллектива)

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).

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

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

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

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