Построение (Construction)

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

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

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

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

Рекомендуется очень серьезно относиться к тестированию. Объем написанного разработчиком кода тестов должен быть по меньшей мере равен объему кода самого программного продукта. Тестирование должно быть непрерывным процессом. Не рекомендуется писать программный код до тех пор, пока не известно, как его тестировать. Как только написан код, сразу же пишите для него тесты. Пока все тесты не отработают, нельзя утверждать, что написание кода завершено [81].

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

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

Итерации на стадии конструирования являются одновременно инкрементными (наращиваемыми) и повторяющимися.

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

- Они являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода заново переписывается с целью сделать его более гибким. В этом процессе очень часто используется метод реорганизации (см. далее). Рекомендуется внимательно наблюдать за тем, какой объем кода оказывается ненужным после каждой итерации. Если каждый раз выбрасывается менее 10% предыдущего кода, то это должно вызывать подозрение.

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

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

На стадии построения полезными являются все методы UML.

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

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

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

Рекомендуется ограничить документацию теми случаями, когда она действительно помогает. Если обнаруживается, что от документации нет никакого толку, это верный признак, что что-то идет не так. Документация в нормальном случае должна содержать три основных элемента:

- одну или две страницы с описанием нескольких классов, присутствующих на диаграмме классов;

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

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

Важнейшие цели:

- Завершить анализ, проектирование, кодирование и тестирование всех вариантов использования (функциональных возможностей).

- Создать готовый к использованию продукт.

- Добиться надлежащего качества и полезности версий.

- Оценить готовность к развертыванию.

- Уменьшить затраты на разработку, оптимизируя продукт и используемые ресурсы.

Важнейшие действия:

- Управление ресурсами.

- Контроль качества и оптимизация.