Фредерик П. Брукс
| Вид материала | Документы |
- Французский писатель, журналист и критик Фредерик Бегбедер, 1495.8kb.
- Фредерик Коплстон История философии. XX век Номер страницы указан в конце страницы, 2537.19kb.
- Gold Circle Films представляют фильм компании Integrated Films. О фильме история США, 1307.29kb.
- Брукс Кубик "Тренинг Динозавров. Забытые секреты силы и развития тела", 3174.72kb.
- 2. Во всем мире родоначальником научных основ организации производства признан: ◙ Фредерик, 992.99kb.
- Фредерик Бегбедер, 2049.29kb.
- Фредерик Бегбедер. 99 франков, 2045.96kb.
- Фредерик К. Хэтфилд всестороннее руководство по развитию силы , 4595.97kb.
- Фредерик Бегбедер. 99 Франков, 2399.26kb.
- Практикум по гештальттерапии петербург, 5899.47kb.
Не разрабатывайте программ на выброс, каскадная модель неверна!
В главе 11 дается радикальный совет: "планируйте выбросить первуюпрограмму, вам все равно придется это сделать". Сейчас я считаю этоошибочным - не в силу чрезмерного радикализма, но в силу чрезмернойупрощенности.
Самой большой ошибкой этой концепции является косвенное принятиеклассической последовательности - в виде каскада - модели созданияпрограммы. Эта модель происходит от структуры диаграммы Гранта дляпоэтапного процесса, которую часто изображают, как на рисунке 19.1. Вклассической статье 1970 года Винтон Ройс (Winton Royce) усовершенствовалпоследовательную модель путем:
- добавления некоторой обратной связи с предшествующими этапами;
- ограничения
обратной
связи
только непосредственнымипредшественниками, чтобы исключить вызываемые ими издержки и задержки ввыполнении графика.
Он предвосхитил "МЧ-М", рекомендовав разработчикам "делать работудважды"8. Глава 11 - не единственная, на которую повлияла каскадная модель.Она проходит через всю книгу, начиная с правила планирования в главе 2. Этопрактическое правило отводит 1/3 времени на планирование, 1/6 - на написаниепрограмм, 1/4 - на тестирование компонентов и 1/4 - на системноетестирование.
Рис. 19.1 Каскадная модель создания программы
Основное заблуждение каскадной модели состоит в предположениях, чтопроект проходит через весь процесс один раз, архитектура хороша и проста виспользовании, проект осуществления разумен, а ошибки в реализацииустраняются по мере тестирования. Иными словами, каскадная модель исходит изтого, что все ошибки будут сосредоточены в реализации, а потому ихустранение происходит равномерно во время тестирования компонентов исистемы.
"Планируйте на выброс" действительно резко нападает на это заблуждение.Ошибка не в диагнозе, а в лекарстве. Сейчас я предположил, что первуюсистему можно отбросить или перепроектировать не всю целиком, а по частям.Хорошо, если это так, но при этом не затрагивается корень проблемы. Вкаскадной модели системное тестирование, а следовательно и тестированиепользователем, отодвигается в конец процесса создания программы. Поэтомуесть шанс обнаружить крайние неудобства для пользователя, или неприемлемыетехнические характеристики, или опасную уязвимость к ошибкам илизлонамеренным действиям пользователя лишь в самом конце разработки. Изучениеспецификаций при альфа-тестировании нацелено на раннее обнаружение такихошибок, но ничто не может заменить непосредственных пользователей.
Вторым недостатком каскадной модели является предположение, что системастроится сразу вся целиком для тестирования с начала до конца после того,как завершены все проектные разработки, большая часть написания программ изначительная часть тестирования компонентов.
К несчастью, каскадная модель, это преобладавшее в 1975 годупредставление о программных проектах, была включена в DOD-STD-2167 -спецификацию Министерства обороны для любого военного программногообеспечения. По этой причине она просуществовала долгое время после того,как большая часть думающих практиков осознала ее неадекватность и отказаласьот нее. К счастью, в МО позднее поняли истину.9
Необходимо двигаться против течения. Опыт и идеи из каждойрасположенной ниже по течению части процесса создания программы, какэнергичный лосось, должны прыгать вверх по течению, иногда сразу черезнесколько этапов, и воздействовать на деятельность наверху.
Проектные разработки покажут, что некоторые предусмотренныеархитектурой возможности ухудшают технические характеристики, и потомуархитектура должна быть переработана. Программирование при реализациивыявит, что некоторые функции непомерно увеличивают требования к памяти,поэтому нужно внести изменения в архитектуру и разработку.
Поэтому вполне может потребоваться осуществить несколько итераций циклаархитектура-разработка, прежде чем начать какую-либо программную реализацию.
Модель пошагового создания лучше: последовательное уточнение
Построение каркаса с начала до конца. Гарлан Миллз (Harlan Mills),работающий в системе с разделением времени, давно уже рекомендует строитьосновной цикл опроса системы реального времени с вызовами подпрограмм(заглушками) для всех функций (рис. 19.2), но пустыми подпрограммами.Откомпилируйте его, протестируйте, и он будет идти цикл за циклом, буквальноничего не делая, но делая это без ошибок.10
Рис. 19.2
На следующем шаге мы навешиваем модуль ввода (возможно, примитивный) имодуль вывода. Voila! Работающая система, делающая нечто, возможно,неинтересное. Теперь, функция за функцией, мы строим и добавляем модули. Накаждом шаге мы имеем работающую систему. При достаточном трудолюбии накаждом шаге мы имеем отлаженную, протестированную систему. (По мере ростасистемы растет и тяжесть повторного тестирования всех новых модулей по всемпрежним контрольным примерам.)
После того как на примитивном уровне каждая функция работает, мыулучшаем или переписываем один модуль за другим, пошагово наращивая систему.Иногда для надежности мы переписываем исходный движущий цикл, а возможно, иего интерфейсы с модулями.
Поскольку в любой момент времени у нас есть работающая система:
- можно очень рано начать тестирование пользователями;
- можно принять стратегию разработки в соответствии с бюджетом,полностью защищающую от перерасхода времени или средств (возможно, за счетсокращения функциональности).
В течение 22 лет я преподавал в лаборатории программной инженерииУниверситета штата Северная Каролина, иногда вместе с Дэвидом Парнасом. Наэтих занятиях бригады, обычно состоявшие из четырех человек, в течениеодного семестра должны были построить некоторую реальную прикладнуюпрограммную систему. Примерно посередине этого срока я стал преподаватьинкрементную разработку. Я был поражен, какой возбуждающий эффект наморальный дух группы оказывает первая картинка на экране, первая работающаясистема.
Семейства Парнаса. Дэвид Парнас был главным властителем дум впрограммотехнике в течение всего этого 20-летнего периода. Всем известна егоидея скрытия информации. Менее известна очень важная идея Парнаса опроектировании программного продукта как семейства взаимосвязанныхпродуктов.11 Он требует, чтобы проектировщик имел в виду как дальнейшееразвитие, так и новые версии продукта и определял их функциональные илимежплатформенные различия так, чтобы строить дерево родственных продуктов(рис. 19.3).
Рис. 19.3
Фокус при проектировании такого дерева состоит в том, чтобы ближе ккорню поместить те решения, изменение которых наименее вероятно.
Такая стратегия проектирования повышает повторную используемостьмодулей. Еще важнее, что ее можно расширить, включая не только поставляемыепродукты, но и последовательные промежуточные версии, созданные по стратегииинкрементируемых сборок. В этом случае продукт развивается черезпромежуточные стадии с минимумом возврата назад.
Подход Microsoft: "ежевечерняя сборка". Джеймс Маккарти (JamesMcCarthy) описал мне процесс, использовавшийся им и другими в Microsoft. Этопошаговое наращивание, доведенное до логического конца. Он пишет:
Сделав первую поставку, новые версии мы поставляем с дополнительнымифункциями, по сравнению с существующим работающим продуктом. Почему долженбыть иным процесс первоначальной сборки? С момента достижения нами первойвехи (у первой поставки три промежуточных вехи) мы каждый вечер зановособираем разрабатываемую систему (и прогоняем контрольные примеры). Циклсборки становится ритмом жизни проекта. Каждый вечер одна или более бригадпрограммистов, проводящих тестирование, регистрируют модули с новымифункциями. После каждой сборки у нас есть работающая система. Если сборкаоказывается неудачной, мы останавливаем весь процесс, пока ошибка не будетнайдена и исправлена. В любой момент все в группе знают положение дел.
Это действительно тяжело. Требуется выделение больших ресурсов, но этоуправляемый процесс, прослеживаемый и понятный. Он вызывает у командыдоверие к себе. А доверие определяет мораль, эмоциональное состояние.
Такой процесс удивляет и даже шокирует разработчиков в другихорганизациях. Один из них говорит: "Я взял себе за правило делать сборкукаждую неделю, но ежедневная сборка, я думаю, потребует слишком многотруда." И это, возможно, верно. Например, в Bell Northern Research собираютсистему, состоящую из 12 миллионов строк, раз в неделю.
Инкрементная сборка и быстрое макетирование. Поскольку инкрементнаяразработка позволяет рано начать тестирование реальными пользователями, вчем ее отличие от быстрого макетирования? Мне кажется, что они связаны, норазличаются. Одним можно пользоваться без другого.
Харел дает полезное определение макета: (версия программы, которая) отражает только проектные решения, принятыев процессе подготовки концептуальной модели, а не решения, вызванныесоображениями реализации.12
Можно построить макет, который вовсе не является частью продукта,развивающегося в направлении поставки. Например, можно создать макетинтерфейса, за которым стоит не реально работающая программа, а лишьконечный автомат, заставляющий его имитировать прохождение состояний. Можнодаже макетировать и тестировать интерфейсы методом волшебника изумрудногогорода, когда спрятанный человек имитирует отклик системы. Такоемакетирование может быть весьма полезным для быстрого получения обратнойсвязи от пользователя, но оно находится совершенно в стороне от тестированияпродукта, который готовится к поставке.
Аналогично, разработчики могут попробовать построить вертикальный срезпродукта, в котором полностью реализован весьма ограниченный набор функций,чтобы заранее пролить свет на те места, где могут таиться опасности дляпроизводительности продукта. В чем состоит различие между сборкой на первойвехе в процедуре Microsoft и быстрым макетом? В функциях. Продукт с первойвехи может иметь такую ограниченную функциональность, что ни для кого небудет представлять интереса. Готовность продукта к поставке определяетсязавершенностью в предоставлении полезного набора функций и своим качеством,уверенностью в надежной работе.