Водопадная и Спиральная методологии разработки программного обеспечения

Водопадная и Спиральная методологии разработки программного обеспечения

Constantine

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

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

Водопадная модель

Рисунок 1 AN/FSQ-7

Нисходящая модель, или как её позже назовут водопадная или каскадная, впервые была сформулирована в 1956 году и применялась при разработке SAGE, системы наведения для координации перехватчиков при возможной атаке на США. Это была одна из первых компьютерных сетей, которые через десять лет эволюционировала в ARPANET, предшественника современного интернета. Специально для этой системы компанией IBM был разработан самый мощный компьютер того времени AN/FSQ-7. Компьютер весил 250 тонн, занимал площадь в 20 тыс. кв. футов и потреблял более 1 МВт электроэнергии. Сама программа состояла из полумиллиона команд — беспрецедентный масштаб для того времени, если вспомнить что программа находилась на перфокартах, и каждая вмещала 24 слова.

Рисунок 2 перфокарта

Над разработкой программно-аппаратного комплекса трудились тысячи человек в течении полутора лет, а стоимость одной строки (!) исходного кода в сегодняшних ценах была более 600$ (шестисот долларов). Стоимость одного часа компьютерного времени была 6,500$ (шесть с половиной тысяч долларов). При этом было написано 15,000 страниц сопровождающей документации. Разрабатывали эту систему в Массачусетском Технологическом Институте ученые и инженеры, которые принесли инженерные практики в разработку.

Поскольку цена ошибки огромна и возрастает с каждым этапом, то необходимо максимально детально, проработать спецификацию не задействуя ресурсы компьютера, насколько это возможно. Этап кодирования в этом процессе — просто механический перенос алгоритма на перфокарту. Учитывая масштаб системы, можно представить, какой объем работы придется переделать, если ошибка будет обнаружена на поздних этапах. SAGE — это программно-аппаратный комплекс, который включал в себя оборудование, распределенное по стране, для работы с которым нужны тысячи страниц документации, и персонал, который необходимо было обучить. Напомню, что прародитель Интернета ARPANET появится только через десять лет, а персональные компьютеры через двадцать.

Водопадная модель состоит из последовательности этапов:

  1. Планирование
  2. Написание спецификаций системной, оборудования, модулей
  3. Кодирование
  4. Параметрическое тестирование
  5. Интеграционное тестирование
  6. Тестирование системы в целом
  7. Оценка системы

Каждый этап передает следующему артефакты в виде документации или кода.

Возвращаясь в современные реалии, каскадную модель можно встретить в глубоко инженерных областях, которые работают с реальным оборудованием, которое крайне сложно переделать после изготовления или цена ошибки — жизнь людей. Есть поговорка, что самолет можно считать безопасным для эксплуатации, если вес документации сопоставим с весом самолета. В России похожую модель можно встретить в ГОСТ 34-й серии.

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

Спиральная модель

В 1986-му году Барри Боэм опубликовал статью о разработке системы TRW Software Productivity System из 1,3 млн инструкций в окологосударственной компании. К этому времени стало очевидно, что классическая водопадная модель разработки даже с доработками в виде обратных связей, имеет весьма специфичную область применимости: например, в компиляторах или защищенных операционных системах — там где нужен большой объем документации и предсказуемость. Напротив, в системах с пользовательским интерфейсом, где пользователь не может сформулировать свои потребности, а говорит "покажите мне, и я скажу то это или нет" — жесткость водопадной модели гарантированно похоронит проект.

Рисунок 4 Улучшенная водопадная модель с обратными связями

Барри Боэм предложил разделить проект на итерации, которые состоят из последовательности этапов:

  • формулирование целей
  • анализ рисков
  • прототипирование
  • разработка

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

Рисунок 5 Спиральная модель

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

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

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

Заключительные мысли

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

Литература

  1. Benington, Herbert D. (1 October 1983). "Production of Large Computer Programs"
  2. Boehm, B (May 1988). "A Spiral Model of Software Development and Enhancement"
  3. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания

Report Page