Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы

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

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

К несчастью, каскадная модель, это преобладавшее в 1975 году представление о программных проектах, была включена в DOD-STD-2167 — спецификацию Министерства обороны для любого военного программного обеспечения. По этой причине она просуществовала долгое время после того, как большая часть думающих практиков осознала ее неадекватность и отказалась от нее. К счастью, в МО позднее поняли истину. [9]

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

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

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

Модель пошагового создания лучше: последовательное уточнение

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

Рис. 19.2

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

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

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

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

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

В течение 22 лет я преподавал в лаборатории программной инженерии Университета штата Северная Каролина, иногда вместе с Дэвидом Парнасом. На этих занятиях бригады, обычно состоявшие из четырех человек, в течение одного семестра должны были построить некоторую реальную прикладную программную систему. Примерно посередине этого срока я стал преподавать инкрементную разработку. Я был поражен, какой возбуждающий эффект на моральный дух группы оказывает первая картинка на экране, первая работающая система.

Семейства Парнаса. Дэвид Парнас был главным властителем дум в программотехнике в течение всего этого 20-летнего периода. Всем известна его идея скрытия информации. Менее известна очень важная идея Парнаса о проектировании программного продукта как семейства взаимосвязанных продуктов. [11] Он требует, чтобы проектировщик имел в виду как дальнейшее развитие, так и новые версии продукта и определял их функциональные или межплатформенные различия так, чтобы строить дерево родственных продуктов (рис. 19.3).