8. В чем суть итеративной (пошаговой) разработки?

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

На следующем шаге мы навешиваем модуль ввода (возможно, примитивный) и

модуль вывода. Работающая система, делающая нечто, возможно,

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

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

Поскольку в любой момент времени у нас есть работающая система:

• можно очень рано начать тестирование пользователями;

• можно принять стратегию разработки в соответствии с бюджетом, полностью защищающую от перерасхода времени или средств (возможно, за счет сокращения функциональности).

8. В чем психологическое преимущество итеративной разработки?

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

8. Почему принцип “планируйте на выброс” был признан устаревшим в 80-е?

Самой большой ошибкой этой концепции является косвенное принятие классической последовательности — в виде каскада — модели создания программы.

В классической статье 1970 года Винтон Ройс усовершенствовал последовательную модель путем:

• добавления некоторой обратной связи с предшествующими этапами;

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

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

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

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

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

пользователей.

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

Каскадная модель:

• На каждом этапе формируется законченный набор проектной документации – полный и согласованный

• Выполняемая в логической последовательности этапы работ позволяет планировать сроки завершения

• Каскадная модель исходит из того, что большая часть ошибок будет сосредоточена в реализации, а потому их устранение проходит равномерно по мере их возникновения

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