Табл. 3-2. {окончание)

Тип ПО

от которых зависит

Бизнес-системы

назначения

Встроенные системы, Системы целевого

жизнь людей

Проектирование

Комбинация проектирования и кодирования.

Проектирование архитектуры. Неформальное детальное проектирование. Обзоры проекта по мере надобности.

Проектирование архитектуры. Формальные инспекции архитектуры. Формальное детальное проектирование. Формальные инспекции детального проекта.

Конструирование

Парное или индивидуальное программирование.

Неформальная процедура регистрации кода или ее отсутствие.

Парное или индивидуальное программирование.

Неформальная процедура регистрации кода. Обзоры кода по мере надобности.

Парное или индивидуальное программирование.

Формальная процедура регистрации кода. Формальные инспекции кода.

Тестирование и гарантия качества

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

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

Разработчики тестируют собственный код.

Предварительная разработка тестов. Отдельная группа тестирования. Отдельная группа гарантии качества.

Внедрение Неформальная проце- Формальная процедура Формальная процеду-

приложения дура внедрения. внедрения. ра внедрения.

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

Влияние итеративных подходов на предварительные условия

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

тивные подходы ослабляют следствия неадекватной подготовки, но не устраняют их. Давайте изучим табл. 3-3, в которой приведены данные о проектах, в начале которых не были выполнены предварительные условия. Первый проект выполняется последовательно, при этом дефекты обнаруживаются только на этапе тестирования; второй выполняется итеративно, и разработчики находят дефекты по мере работы. В первом случае основной объем работы по исправлению дефектов откладывается на конец проекта, что приводит к росту расходов (табл. 3-1). При итеративном подходе дефекты исправляются по мере развития проекта, что позволяет снизить общие расходы. Табл. 3-3 и 3-4 приведены исключительно в иллюстративных целях, однако соотношение затрат при этих двух общих подходах хорошо подтверждается исследованием, описанным выше.

Табл. 3-3. Влияние невыполнения предварительных условий на последовательный и итеративный проекты

Подход 1: последовательный подход без выполнения предварительных условий

Подход 2: итеративный подход без выполнения

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

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

Адекватное внимание к выполнению предварительных условий позволяет снизить затраты независимо от типа используемого подхода (табл. 3-4). Итеративные подходы обычно по многим параметрам лучше последовательных, однако итеративный подход, при котором пренебрегают предварительными условиями, может в итоге оказаться гораздо дороже, чем должным образом подготовленный последовательный проект.

Табл. 3-4. Влияние выполнения предварительных условий на последовательный и итеративный проекты

Подход 3: последовательный подход с выполнением

Подход 4: итеративный подход с выполнением

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

Одно популярное практическое правило состоит в том, чтобы заблаговременно определить около 80% требований, предусмотреть время для более позднего определения дополнительных требований и выполнять по мере работы систематичный контроль изменений, принимая только самые важные требования. Возможен и другой вариант: вы можете определить заранее 20% только самых важных требований и разрабатывать оставшуюся часть ПО небольшими фрагментами, определяя дополнительные требования и дорабатывая проект приложения по мере прогресса (рис. 3-2 и 3-3).

I ссылка Об адзггга-

цни ттШ разработки к программам разных размеров см. главу 27,