Главная идея ХР состоит в том, чтобы сделать работу с минимальной степенью сложности. Вся работа в ХР сосредоточена в четырех основных операциях: планировании, проектировании, кодировании и тестировании.
Планирование организовано в форме "плановой игры". Требования собираются в виде "рассказов пользователей", которые можно обсуждать с заказчиками и которые дают достаточно информации для оценки и согласования планов. Требования записываются на карточках. Затем определяется "метафора" всей системы, что позволяет всем участникам группы использовать одни и те же термины для выражения понятий. Требования делятся на меньшие задачи, каждую из которых можно решить за очень короткое время (несколько недель).
Так как требования могут быстро изменяться, в ХР не принято тратить время на предварительный анализ. Проектирование и кодирование начинаются сразу же. В ХР код и проект — это одно и то же, следовательно, стадия проектирования заключается в обсуждении функций с заказчиком, определении контрольных задач для успешной реализации, а затем осуществлении самого простого решения, которое будет отвечать требованиям. Разработчики всегда работают в парах и пытаются решить задачи, в максимальной степени используя любой существующий код, как это требуется по ходу дела. Несколько раз в день может проводиться интеграция с другими частями системы.
Первичное тестирование выполняется прежде всего над модулями, а функциональное тестирование проводится по требованию заказчика, чтобы узнать, приемлем ли полученный программный продукт.
Метод разработки по функциям (Feature-Driven Development — FDD), созданный Джефом де Люка (Jeff de Luca) и Питером Коудом (Peter Coad), базируется на ХР. Он отличается от экстремального программирования прежде всего тем, что включает требование разработки модели предметной области на ранней стадии проектирования. Эта модель должна скомпенсировать отсутствие общей архитектуры и проекта. Кроме того, в FDD по сравнению с ХР задачи ограничиваются потребляемыми пользователем функциями, а в процессе разработки значение функций повышается вплоть до центральной идеи системы.
Подход, используемый в данной книге
Из внимания, которое до сих пор уделялось описанию разных процессов, вы, вероятно, уже заключили, что в дальнейшем в этой книге будет применен подход, в значительной степени базирующийся на процессе RUP.
Это решение было принято по следующим причинам.
· Процесс RUP уже проверен на практике и успешно применяется во множестве проектов.
· Мы уверены, что для долгосрочного успеха проекта необходимы разработка архитектуры, анализ и проектирование. Процесс RUP, в отличие от других процессов,таких как FDD и ХР, процессами (например, ICONIX) есть достаточно схожих черт, чтобы материал, представленный в этой книге, был полезен, даже если при разработке программной системы процесс RUP принят не в чистом виде.
· Процесс RUP можно ада уделяет достаточное внимание этим ключевым аспектам.
· Между RUP и другими птировать к специфическим потребностям.
Конечно, это решение никоим образом не базируется на исчерпывающем сравнении различных подходов; оно было принято, несомненно, под влиянием нашего знакомства с RUP.
Следует указать, что в данной книге применяется адаптированная версия RUP, специализированная для изложения конкретного материала и практических исследований. Мы не пытались рассматривать все возможные артефакты, узлы или элементы, которые можно описать в RUP. Это связано прежде всего с диктуемыми книгой ограничениями места и времени.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.