Мифический Waterfall

Тимофеев А.Н

«Как ИТ-профессионал и преподаватель я в течение более чем 40 лет слышал много мифов об ИТ-индустрии. Но что продолжает удивлять меня, так это то, почему слово «Waterfall» до сих пор используется для описания методологии, которая не существует и почему создатели методов разработки систем используют его в качестве источника сравнения»[1].

David Dischave,
профессор школы информационных технологий университета Сиракузы, США

Скачать pdf-версию статьиИтак, профессор школы информационных технологий, входящей в тройку лучших информационных школ в США, профессионал, который работал в крупных ИТ-компаниях из списка 100 журнала Fortune, говорит нам, что такой методологии создания программных систем как Waterfall не существует. Не правда ли, весьма интересное мнение практика!

Но возможно он ошибается или пребывает в счастливом неведении и Waterfall, о котором столько написано в учебниках и в СМИ и который является отправной точкой при оценке новых методологий, все же существует? А если он прав, то тогда откуда все эти люди, с воодушевлением критикующие Waterfall, черпают информацию о её существовании?

Мой коллега из США в ответ на этот вопрос прислал мне ссылку на статью из Wikipedia [2]. Изучение статьи показало, что информация в ней — это смесь правды со сказкой, – наиболее опасная форма распространения информационной инфекции. Однако она совершенно точно указывает на документы, которые фигурируют в учебниках по ИТ, научных статьях и в СМИ в качестве первоисточников Waterfall. Вот они:

  • статья Герберта Бенингтона (Herbert D. Benington) «Production of Large Computer Programs»  1956 года;
  • статья доктора наук Уинстона Ройса (Dr. Winston W. Royce) «Managing the development of large software systems» 1970 года;
  • стандарты министерства обороны США на разработку программного обеспечения: DOD-STD-2167. «Defense System. Software Development» 1985 года и DOD-STD-2167A. «Defense System. Software Development» 1988 года.

Уже сама неопределённость во времени появления Waterfall и в авторстве заставляет задуматься.

И все же, чтобы понять, не ошибается ли профессор Дишейв, который  далеко не одинок в своём мнении в том, что Waterfall это миф [22-29], обратимся к оригиналам этих и других документов. Но сперва определим, что стоит за словом «Waterfall» в области разработки ПО.

Что же такое этот Waterfall? 

Та же самая статья из Wikipedia говорит, что Waterfall «представляет собой последовательный (не итеративный) процесс» создания ПО, «текущий непрерывно вниз через фазы концепции, инициирования, анализа, проектирования, разработки, тестирования, производства / внедрения и обслуживания» [2].

Определение Waterfall  на ресурсе Techopedia гласит: « … waterfall модель обеспечивает соблюдение перехода к следующей фазе только после завершения предыдущей фазы. Возвращение к предыдущей фазе не приветствуется, если не существует явная необходимость сделать это». [3]

Популярный учебный портал Tutorials Point подчёркивает: «В Waterfall модели, каждая фаза должна быть завершена до того, как может быть начата следующая фаза и фазы не перекрываются» [4].

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

Исходя из данных определений основными характеристиками Waterfall являются:

  • отсутствие итераций в процессе создания ПО;
  • переход от одной фазы процесса к следующей выполняется только после полного завершения работ на предыдущей фазе, т.е. фазы не перекрываются.

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

Герберт Бенингтон предостерегает разработчиков ПО

В июне 1956 года в США на симпозиуме по передовым методам программирования для цифровых вычислительных машин был представлен доклад Герберта Бенингтона (Herbert D. Benington) из MIT Lincoln Laboratory: «Production of Large Computer Programs» [5].

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

benington

Эта модель создания ПО действительно чем-то напоминает каскадную (top-down) модель производства, которая применяется в промышленности, например, в строительстве — проектная документация, фундамент, этажи, крыша. Именно этот рисунок часть современного ИТ-сообщества считает точкой отсчёта появления Waterfall в индустрии разработки ПО.

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

В опубликованных Бенингтоном в 1983 году  пояснениях к докладу он пишет: «top-down подход был бы чуждым для нас». 

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

«…мы взялись за программирование только после того, как собрали экспериментальный прототип с 35000 инструкций кода, который выполнял все основные функции системы ПВО» [5].  

В своих пояснениях к докладу, Герберт Бенингтон, указывал на то, что природа создания ПО «далека от методов, которыми создают космические аппараты или ботинки» и предостерегал разработчиков ПО об опасности применения каскадного подхода в программировании.

Итак, с этим источником всё ясно — он не имеет никакого отношения к так называемой Waterfall методологии.

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

Программная инженерия и нелинейный SDLC

В 1968 году в немецком городе Гармиш под эгидой научного комитета NATO была проведена первая, а затем в 1969 году в Риме вторая конференция по программной инженерии [6,7]. На обеих конференциях присутствовало более 50 ведущих учёных-практиков из 11 стан мира, среди которых были такие звезды мировой науки, как  Edsger W. Dijkstra (Эдсгер Вибе Дейкстра) и Charles Antony Richard Hoare (Чарльз Энтони Ричард Хоар).

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

Знаменательным событием обеих конференций был впервые представленный миру жизненный цикл разработки программной системы — System development life cycle (SDLC или SLC) [6,7]:

sdlc

Эта модель была разработана на основании практических разработок IBM, System Development Corporation и ряда иных материалов. В пояснении к ней написано:

«Жизненный цикл показывает мероприятия, которые должны иметь место при разработке системы и уровень трудовых ресурсов, необходимых для выполнения этой работы. Диаграмма усекается на обоих концах, опуская формулировку концепции в начале и техническое обслуживание и усовершенствования в конце. Наклон границ в верхней половине диаграммы представляет тот факт, что деятельности перекрываются; некоторые программы могут начаться, прежде чем все пакеты будут разработаны или некоторые испытания и интеграция может начаться до того, как последний блок отлажен»[7].

Таким образом, на двух международных конференциях известные учёные-практики из 11 стран мира зафиксировали два принципиальных свойства  процесса создания ПО:

  • Процесс создания ПО зависит от процесса создания системы в целом и вложен в него.
  • Жизненный цикл разработки ПО нелинеен, его фазы перекрывают друг друга в разные моменты времени.

Мы видим, что ещё в 1969 году основатели сообщества программной инженерии отвергли возможность разработки ПО методом, который мы называем Waterfall. А теперь посмотрим, что произошло дальше.

Пять шагов доктора Уинстона Ройса  

В августе 1970 года в США в журнале IEEE директор центра по технологии программного обеспечения компании Lockheed доктор Уинстон Ройс (Dr. Winston W. Royce) опубликовал статью «Управление разработкой крупных программных систем» [8]. В истории программной инженерии эта статья считается эпохальной. Это самый цитируемый источник, претендующий на авторство в создании и описании Waterfall. Ссылки на него есть в фолиантах по программной инженерии [11], книгах по методам Agile [12,13], в выпускных работах университетов [14,15], в сертификационных экзаменах[16], в статьях и постах в Интернете [17-20], которых сотни тысяч.

Однако, первое же прочтение оригинала вызывает недоумение. А читали его те, кто считает доктора Ройса автором Waterfall методологии? Ведь в этой статье доктор Ройс шаг за шагом, методично и доходчиво показывает несостоятельность применения подхода к разработке ПО, который он не называет, но иллюстрирует двумя рисунками [8]:

royce1  royce2

Эти рисунки хорошо известны, как описывающие варианты методологии Waterfall. Но в его работе нет ни такого слова как «Waterfall», ни даже близкого к нему по смыслу.

Дав краткое описание иллюстрируемого рисунками подхода, доктор Ройс пишет:

«Я верю в эту идею, но реализация, описанная выше, является рискованной и способствует провалу» [8].

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

«Требуемые изменения дизайна, вероятно, будут настолько разрушительными, что требования к программному обеспечению, на которых проект основан и которые обеспечивают логическое обоснование для всего, нарушатся. Либо потребуется изменение требований, либо существенное изменение в дизайне. Фактически процесс разработки возвращается к началу координат и можно ожидать до l00% перерасхода в графике работ и /или расходов» [8].

Показав несостоятельность этого подхода к разработке ПО доктор Унстон Ройс на этом не останавливается. Он даёт пять практических рекомендаций — пять выверенных шагов, которые могут привести к успеху в разработке ПО. Вот основные тезисы.

Шаг 1. Проектирование программ важнее всего

Основная идея первого шага — это сконцентрироваться на проектировании программ, вставив «предварительный этап проектирования программы ​​между фазами генерации требований к программному обеспечению и фазой анализа» несмотря на то, «что проектировщик вынужден проектировать в относительном вакууме первоначальных требований программного обеспечения» [8].

«Как реализуется эта процедура? Необходимы следующие шаги:

  • Начните процесс проектирования с проектировщиками, а не с аналитиками или программистами (здесь имеются в виду аналитики предметной области, например, специалисты по расчёту орбит).
  • Проектирование: определите и выделите режимы обработки данных, даже рискуя ошибиться.
  • Напишите обзорный документ, понятный, информативный и действующий. Каждый работник должен иметь элементарное понимание системы. По крайней мере, один человек должен иметь глубокое понимание системы, которое частично наступает от того, что он должен был написать обзорный документ» [8].

«Обеспечьте, чтобы предварительное проектирование программы было завершено до начала анализа» [8].

Шаг 2. Документируйте разработку  

На втором шаге доктор Ройс пишет, что прежде чем двигаться дальше нужно решить вопрос с документацией [8]:

 «Первым правилом управления разработкой ПО является безжалостное соблюдение требований  к документации».

«Если документация находится в тяжёлом дефолте, то первая моя рекомендация  проста. Заменить руководство проектом. Остановите все виды деятельности, не связанные с документацией. Доведите документацию до приемлемых стандартов. Управление программным обеспечением просто невозможно без очень высокого уровня документации».

«Почему так много документации?

  • Каждый проектировщик должен поддерживать связь со смежными проектировщиками, со своим руководством и, возможно, с заказчиком. Слова слишком неосязаемы, чтобы обеспечить адекватную основу для интерфейса или управленческих решений. Приемлемое письменное описание заставляет проектировщика занять однозначную позицию и предоставить весомые доказательства завершения (работ). Это уберегает от синдрома проектировщика «Я завершил работу на 90%» — из месяца в месяц.
  • Если документация плохая, то дизайн плохой. Если документация ещё не существует, не существует ещё никакого дизайна, только люди, думающие и говорящие о дизайне, что имеет некоторое значение, но не такое большое.
  • Реальная стоимость в денежном выражении документации начинает проявляться на этапах разработки, тестирования и редизайна (перепроектирования):
    1. На этапе тестирования, с хорошей документацией, менеджер может сосредоточить персонал на ошибках в программе. Без хорошей документации каждая ошибка, большая или малая, анализируется одним человеком, который, вероятно, совершил ошибку и в первую очередь потому, что он единственный человек, который понимает эту программу.
    2. На этапе эксплуатации, с хорошей документацией, менеджер может использовать операционно-ориентированный персонал для работы программы и сделать работу лучше, дешевле. Без хорошей документации с программным обеспечением должны работать те, кто его создал.
    3. Вслед за начальными операциями, когда заказаны усовершенствования системы, хорошая документация позволяет проводить эффективный редизайн, обновление и модернизацию. Если документации не существует, то как правило, весь существующий рабочий пакет операционного программного обеспечения должен быть выброшен за ненадобностью, даже при относительно скромных изменениях.»

Шаг 3. Сделать дважды  

Следующим действием для впервые разрабатываемого ПО Уинстон Ройс предлагает перейти к раннему прототипированию и моделированию [8]:

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

«Если работа простирается на  30 месяцев, то сделайте пилот за 10, а если 12, то объем работ по пилоту может быть сжат до 3 месяцев».

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

«Без такого моделирования менеджер проекта оказывается во власти человеческого суждения. При моделировании же он может выполнить экспериментальную проверку некоторых  основных гипотез и ограничений…».

Шаг 4. Планировать, управлять и контролировать испытания  

Считая испытания одним важнейших этапов на пути создания ПО, доктор Ройс предлагает [8]:

«Испытания – стадия крупнейшего потребления всех ресурсов проекта (люди, время, средства). Чтобы провести этот процесс наиболее эффективно:

  • Протестируйте специалистов, которые не вносили большой вклад в проектирование, на предмет их возможности провести тестирование. Если они утверждают, что наиболее эффективно это тестирование проведёт непосредственный разработчик, потому, что только он понимает, в том, что он спроектировал, то это верный признак неспособности должным образом документировать. Лучше чтобы тестирование проводили не те, кто разрабатывали.
  • Большинство ошибок имеют очевидный характер, которые можно лего обнаружить при визуальном осмотре. Каждый бит результатов анализа и каждый бит кода должен быть подвергнут простому визуальному сканированию той стороной, которая не выполняла этот анализ или не разрабатывала этот код, но которая заметит такие вещи как пропущенный знак минуса, переходы к неправильным адресам и т.д.. Не используйте компьютер на этом этапе – это дорого.
  • Проверяйте логические переходы в программе, по крайней мере, один раз с численными проверками. Этот шаг выявит большинство ошибок кодирования.
  • После устранения простых ошибок (которые заслоняют более сложные ошибки) переходите к поиску и устранению сложных ошибок, используя компьютер, который сам по себе является отличным инструментом для этого».

Шаг 5. Вовлеките заказчика 

Необходимость привлечения заказчика к созданию системы ещё задолго до её сдачи Уинстон Ройс обосновывает так [8]:

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

Не правда ли интересные предложения по организации разработки ПО? Вы не находите их весьма современными и близкими к некоторым идеям Agile? Какой уж тут Waterfall! Как раз наоборот — безжалостная критика каскадного подхода к разработке ПО, который в этой индустрии просто не работает.

Так благодаря чему или кому это работа доктора Уинстона Ройса стала наиболее цитируемым источником, претендующим на авторство в создании и описании Waterfall? А «благодарить» за это мы должны Белла и Тайера — авторов статьи «Software Requirements: Are They Really a Problem?», вышедшей в 1976 году [21].  Именно в ней утверждается, что доктор Ройс в этой работе «ввёл понятие waterfall»]. Вот так 40 лет назад доктору Уинстону Ройсу приписали авторство в том, к чему он не имел никакого отношения и против чего  выступал в своей статье.

Министерство обороны одобряет инкрементальное построение

Стандарт министерства обороны США DOD-STD-2167 «Defense System. Software Development» вышел в свет в 4 июня 1985 года [9].

Рисунок на странице 2 стандарта вводит невнимательных читателей в заблуждение — изображённый на нем жизненный цикл разработки ПО встроенный в цикл создания системы опять сильно похож на пресловутый Waterfall.

dod

Но возникшие эмоции быстро гасит текст стандарта и не даёт никаких шансов отнести его авторов к создателям Waterfall. Тест раздела 4.1.2 гласит [9]:

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

По-военному лаконично и ясно — никакого Waterfall.

В 1988 этот стандарт был заменён на США DOD-STD-2167А «Defense System. Software Development». В разделе 4.1.1 «Software development process» этого стандарта, опять же чётко прописано [10]:

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

Кроме этого в разделе «Введение» этого стандарта сказано [10]:

«Настоящий стандарт не предназначен для указания или воспрепятствования использования какого-либо конкретного способа разработки программного обеспечения. Подрядчик несёт ответственность за выбор методов разработки программного обеспечения (например, быстрое прототипирование), которые наилучшим образом поддержат достижение требований контракта».

И тут нечего искать источник Waterfall методологии.

Так существует ли Waterfall в разработке ПО?

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

Но как заметил Conrad Weisert — президент компании Information Disciplines: «Waterfall существует только в умах тех, кто его осуждает» [25]. И потому  сегодня, когда речь заходит о преимуществах новых методов создания ПО, они всегда рассматриваются в сравнении с Waterfall. Так происходит на протяжении уже более 40 лет. Более 40 лет мир ИТ пытается найти достойную замену этой проблемной «методологии»! На фоне гигантских изменений информационных технологий за эти 40 лет такое постоянство цели говорит либо об огромной силе одной методологии и слабостях других, либо о том, что враг искусно выдуман и поднятая пыль скрывает иные цели.

Врождённые недостатки мифического Waterfall идеальный объект для беспроигрышной критики. На его фоне любые иные методологии воспринимаются, как «пули из серебра, которые могут волшебным образом уложить» этого «монстра» [30].

Вот что пишет профессор Дишейв в своей заметке, цитатой из которой начинается эта статья [1]:

«Моя первая встреча с мифической методологией «Waterfall» произошла в начале 1980-х годов. Как директор департамента разработки системы компании из 100 Fortune, я удостоился визита торгового представителя от Coopers & Lybrand (C & L). Торговый представитель C & L, пытась продать мне методику под названием Summit-D, спросил меня, какой метод разработки систем мы использовали. … «Вы знаете, мы присоединяемся к работе Уинстона Ройса». Прежде чем я успел закончить моё описание, торговый представитель C & L  тут же съязвил: «Аааа, вы используете эту старую вышедшую из употребления Waterfall-модель. О, кстати, кто это Уинстон Ройс?» Не дожидаясь ответа, он добавил, что никто не должен больше использовать Waterfall-модель.

Торговый представитель C & L сказал, что это метод использует почти каждая компания, в нем фазы выполняются последовательно, т.е. фаза блокировалась и не могла начаться, пока предыдущая не была завершена…. «Смотрите, это называется водопад, потому что вода просто не может течь в гору».

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

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

Тимофеев А.Н. Мифический Waterfall! //Практика проектирования систем.-2016. [электронный ресурс] — Режим доступа: http://reqcenter.pro/waterfall-myths/, свободный. — Загл. с экрана

Литература

  1. David Dischave. A Waterfall System Development Methodology… Seriously? https://web.archive.org/web/20140702113551/http://get.syr.edu/news_alt.aspx?recid=401. – 2012.
  2. Waterfall model. https://en.wikipedia.org/wiki/Waterfall_model
  3. Waterfall Model. https://www.techopedia.com/definition/14025/waterfall-model
  4. SDLC — Waterfall Model. http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
  5. Herbert D. Benington Production of Large Computer Programs, Annals of the History of Computing, Volume 5, Number 4, October 1983.
  6. Peter Naur, Brian Randell. Software Engineering. Report on a conference sponsored by the NATO Science Committee. Garmisch, Germany, 7th to 11th October 1968.
  7. N.Buxton, B. Randell. Software Engineering Techniques. Report on a conference sponsored by the NATO Science Committee. Rome, Italy, 27th to 31st October 1969.
  8. Winston W. Royce. Managing the development of large software systems./Proc. IEEE WESCON, Aug 1970.
  9. DOD-STD-2167 «Defense System. Sofivvare Development». —
  10. DOD-STD-2167А «Defense System. Sofivvare Development». —
  11. Robert T. Futrell, Donald F. Shafer, Linda Shafer. Quality Software Project Management./ Prentice Hall Professional­­. —
  12. Chris Sims, Hillary Louise Johnson, The Elements of Scrum./Dymaxicon. —
  13. Scott Ambler. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process./ John Wiley & Sons, Inc., New York, . —
  14. Denis Mitrovic, Senad Mustafa Analysis, design and implementation of a user friendly global advertisement engine and portal./ LTH School of Engineering, Lund University. —
  15. Mark Harwardt. Wasserfallmodell versus Scrum. Ist der gute Ruf der agilen Methode gerechtfertigt./ Fernuniversität Hagen. ehrgebiet Programmiersysteme. Prof. Dr. Friedrich Steimann. —
  16. ISTQB Exam Certification. /http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/
  17. Wiredify Blogging for IT engineers. The Foundation of Today’s Software Development. http://wiredify.com/menahemzen/logs/The-Foundation-of-Today’s-Software-Development. —
  18. The Waterfall Model of Software Development. http://www.seowebsitedesign.com/the-waterfall-model-of-software-development. —
  19. University of Munich. Classic Waterfall Model in Software Engineering https://www.medien.ifi.lmu.de/lehre/ws0607/mmi1/essays/Anette-Grimm. — 2007.
  20. James Thorne. Using Rackspace Private Cloud to Support Your Software Development Lifecycle. https://developer.rackspace.com/blog/using-rpc-software-dev-lifecycle. —
  21. E. Bell and T.A. Thayer, «Software Requirements: Are They Really a Problem?», Proc. ICSE-2: 2nd Intrnational Conference on Software Enginering, San Francisco, 1976, 61-68.
  22. Is the Waterfall software development methodology still viable? http://programmers.stackexchange.com/questions/139013/is-the-waterfall-software-development-methodology-still-viable. —
  23. The Perennial Waterfall Strawman/Myth. https://postagilist.wordpress.com/2012/06/13/the-perennial-waterfall-strawmanmyth. — 2012.
  24. Erik Dietrich. There is No Such Thing as Waterfall. http://www.daedtech.com/there-is-no-such-thing-as-waterfall. —
  25. Conrad Weisert. There’s no such thing as the Waterfall Approach! (and there never was). http://www.idinews.com/waterfall.html. —
  26. Alexander Schley. Scrum introduction at the HP EMEA PPS LSS Community. 2013
  27. Tobias Pfeiffer. Why Waterfall was a big misunderstanding from the beginning – reading the original paper. https://pragtob.wordpress.com/2012/03/02/why-waterfall-was-a-big-misunderstanding-from-the-beginning-reading-the-original-paper/
  28. Waterfall model probably the most costly mistake in the world. http://valueatwork.se/waterfall-model-probably-the-most-costly-mistake-in-the-world/?lang=en. —
  29. Frederick P. Brooks, Jr. The Design of Design : Essays from a Computer Scientist. —
  30. Frederick P. Brooks, Jr. No Silver Bullet — Essence and Accident in Software Engineering. Proceedings of the IFIP Tenth World Computing Conference, Amsterdam. — 1986