Существуют несколько подходов, но наиболее распространены иерархический и операционный подходы.

Иерархический подход.

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

Используя иерархический подход, не нужно забывать о двух вещах:

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

- слепое следование поуровневому подходу приводит к реализации основной массы модулей в конце проекта.

Операционный подход.

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

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

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

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

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

- обеспечить готовность вспомогательных модулей в первую очередь;

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

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

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

Пример планирования для схемы на рисунке 1.

Последовательность разрабатываемых модулей.

1. «Обработать запрос» – головной модуль.

2. «Вывести ответ» – необходим при тестировании.

3. «Подготовить ответ», «Анализ», «Получение информации» – как наиболее сложные.

4. «Ввести запрос», «Признать», «Проверить» – как наиболее простые.

Планирование тестов.

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

- устраняется возможность подгонки тестов к уже написанной программе (уменьшается возможность внесения одних и тех же ошибок в программу и тест);

- лучше понимаются ограничения на входные данные (сопряжение модулей зависит от передаваемых данных);

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

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

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

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