Некоторые конкретные технологии жизненного цикла. Методология Rational Unified Process

определяет некоторые этапы движения и точки возврата для улучшения и изменения продукта:

•  прогнозирование (envisioning);

•  планирование (planning);

•  разработка (developing);

•  стабилизация (stabilizing);           развертывание (deploying).

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

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

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

Экстремальное программирование

Экстремальное программирование (Extreme Programming — ХР) — не столько очередная модель ЖЦ ПО/АИС, сколько одна из гибких методологий разработки программного обеспечения.

ХР-технология имеет следующие составляющие: ценности (values), практики (practices), принципы (principles), действия (activities). Остановимся на первых двух.

                Ценности.      В      ХР      определены      следующие      ценности:          коммуникация

(communication); простота (simplicity); обратная связь (feedback); уверенность, стойкость (courage); взаимоуважение (respect).

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

Простота. ХР требует, чтобы разработки начинались с простейших решений, а дополнительная функциональность может быть добавлена в дальнейшем — «Do the simplest thing that could possibly work» («Ищите самое простое решение, которое может сработать»). Разница между этим и традиционными подходами заключается в разработке продукта, ориентированного на сегодняшние нужды, а не на те, которые возникнут завтра или через неделю (месяц). Сторонники ХР признают недостаток этого подхода, поскольку порой это может повлечь за собой дополнительные затраты в будущем, но их позиция состоит в утверждении, что эти затраты вполне компенсируются сегодняшней экономией. Разработка, рассчитанная на требования неопределенного будущего, подразумевает риск потратить средства на то, что, возможно, не понадобится — YAGNI («You Aren't Going to Need It» — «В этом не будет необходимости»). Простота в проектировании и кодировании должна улучшить качество ценности «коммуникация». Простая структура ПО с очень простым кодом будет легко понятной для большинства программистов в команде.

Обратная связь относится к различным аспектам разработки системы:

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

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

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

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

•  всегда писать код для сегодняшнего, а не завтрашнего дня, отказываться от заманчивой перспективы написать «красивый», но излишний код. Это необходимо, чтобы не погрязнуть в разработке того, что не понадобится;

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

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

Взаимоуважение. Эта ценность тесно связана со всеми вышеописанными, направлена