3. Построение (Конструирование)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности. Веха включает в себя 1 вопрос: готова ли система для выпуска во внешнюю среду?

4. Внедрение

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

Ответить надо на:

1. Система работает в наиболее типичных вариантах среды пользователя

2. Систему легко приспособить для нетипичной среды.

Конструирование и внедрение могут повторяться много раз (если веха не достигнута).

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

9. Парадигмы проектирования программных систем. Экстремальное программирование.

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

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

Учитывая особенности современного заказчика имеет место частое изменение требований. Для тяжеловесных процессов изменение требований подобно смерти. В легковесных процессах достаточно легко происходит адаптация к изменяемым требованиям и часто она даже прописана в методологии.

Если большая команда и большой объем документации – тяжеловесный.Если команда небольшая и требования изменяются – легковесный.

Экстремальное программирование – одна из гибких методологий (Кент Берт, Уорд Каннингем, Мартин Фаулер).

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

Разделяются на 4 группы.

1. короткий цикл обратной связи (разработка через тестирование, игра в планирование, принцип «заказчик всегда рядом», парное программирование).

2. непрерывный процесс (непрерывная интеграция, рефакторинг, частые небольшие релизы)

3. понимание, разделяемое всеми (простота, метафора системы, коллективное владение кодом или выбранный шаблон проекта, стандарты кодирования)

4. социальная защищенность программиста (40-часовая рабочая неделя (не более)).

Тестирование.

В XP особое внимание уделяется 2 разновидностям тестирования:

1. модульное тестирование

2. приемочное тестирование

Игра в планирование

Быстро сформировать план работы и постоянно обновлять его после того, как задача становится более четкой.

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

Заказчик всегда рядом

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

Парное программирование.

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

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

Непрерывная интеграция.

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

Рефакторинг.

- методика улучшения кода без изменения его функциональности. В XP подразумевается, что написанный код будет неоднократно переделан. Разработчики безжалостно переписывают код. Безболезненному проведению рефакторинга способствует достаточно полное покрытие тестами и использование системы управления версиями.

Частые и небольшие релизы.

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

Простота дизайна.

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

Метафора системы.

- аналог «архитектуры» в большинстве систем. Соответственно:

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

Стандарты кодирования.

При работе все члены команды должны соблюдать требования стандартов кодирования:

1. они не тратят время на споры при кодировании

2. обеспечивается эффективное применение стандартных приемов.

Коллективное владение

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