Опасность – Водопад – Шаг Назад
В 1960-е, когда разработка ПО была относительно новой индустрией, еще рано было говорить о формальных процессах. Программисты просто старались угадать, сколько времени займет процесс, и начинали писать программы. Часто их предположения оказывались ошибочны и они катастрофически не вписывались в бюджет. В 1970-е, с целью привнести немного порядка в эту непредсказуемую сферу, многие разработчики (обычно по распоряжению менеджеров, не имеющих отношения к технологиям) пытались принять “модель водопада” в разработке ПО, которая была упорядоченным алгоритмом создания ПО продукта, состоящим из семи шагов. Обычно эта модель выглядела как вот эта:
Рис. 7.1
И это на самом деле выглядит убедительно. Модель состоит из семи упорядоченных шагов, и когда вы выполняете один шаг, не остается больше ничего, кроме как приступить к следующему шагу – само название “водопад” не предусматривает повторения, потому что водопады обычно не текут вверх по течению.
Подобная модель все же имеет одно серьезное преимущество: она мотивирует разработчиков посвящать больше времени планированию и дизайну до того, как они приступают непосредственно к кодингу. Но в остальном это полная ерунда, потому что подобный подход нарушает Правило Цикла. Менеджеры находят модель привлекательной, но программисты знают, что это абсурд – в применении к таким сложным сферам как разработка ПО, подобные линейные процессы никогда не будут работать. Даже Винстон Ройс (Winston Royce), чья работа послужила фундаментом для создания всего этого, не признает эффективность модели водопада в ее общепринятом виде. Интересно, что в своей работе он сам писал о важности повторения и способности вернуться на несколько шагов назад, если ситуация того требует. Он даже никогда не использовал слово “водопад”! Но люди в университетах и корпорациях изучали именно этот линейный подход. Это можно объяснить лишь тем, что люди, которые никогда в жизни не имели дело с разработкой программных систем, принимали желаемое за действительное.
Барри Бим любит тебя
Позже, в 1986, Барри Бим представил другую модель, которая имела больше общего с реальным процессом разработки ПО. Обычно она выглядит как что-то наподобие диаграммы, в которой разработка начинается с середины и раскручивается по часовой стрелке, проходя через окружность снова и снова (рис. 7.2).
Его модель состоит из множества сложных деталей, но все они нам не нужны. В основном, здесь есть три замечательные идеи: оценка риска, прототипы и цикличность. Согласно спиральной модели, вам нужно сделать следующее:
1 Определиться с основой дизайна.
2 Высчитать самые большие риски вашего дизайна.
3 Создать прототипы, которые уменьшат эти риски.
4 Протестировать прототипы.
5 Определиться с более детальным дизайном, основываясь на информации, которую вы получили.
6 Вернуться к пункту 2.
В целом, вы просто повторяете этот цикл, пока все не станет на свои места. При таком раскладе модель водопада сдается без боя, потому что в данном цикле все основывается на Правиле Петли. Также это позволяет нам ответить на вопросы, которые мы задавали ранее:
● Вопрос Цикла 1: Как сделать каждый цикл эффективным?
Ответ Спиральной Модели: Оцените ваши риски и уменьшите их.
● Вопрос Цикла 2: Как можно максимально ускорить циклы?
Ответ спиральной модели: Создавайте больше “черновых” прототипов.
Существует много ответвлений от спиральной модели, с которыми вы, возможно, захотите ознакомиться. Несмотря на то, что они разные, основой всех спиральных моделей является оценка рисков и создание прототипов.
Рис. 7.2
Спиральная модель разработки ПО
