Цель - инженерия программ

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

увеличить изображение
Рис. 9.4. Спиральная модель

В своей книге (Software Engineering Economics Prentice Hall, 1988) Барри Боем предложил модель, которая смягчает жесткость, применяя итеративный подход, основанный на успешных прототипах. Эта модель известна под именем спиральной модели и показана на следующем рисунке.

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

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

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

Кластерная модель

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

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

Рис. 9.5. Кластерная модель

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

Разработка каждого кластера выполняется непрерывно, а не в виде последовательности независимых шагов, как в модели водопада. Эта идея бесшовной разработки, в частности, важна в подходе Eiffel, где анализ, проектирование и реализация — все используют единую нотацию и построены на едином базисе, начиная с отложенных классов высокого уровня, которые описывают проблему. Фазы проектирования и реализации состоят из уточнений и обогащений этих классов. Это облегчает возврат (символизируемый стрелкой возврата на рисунке) к предыдущим фазам для улучшения или корректировки несовершенной предыдущей версии.

Agile - гибкая методология разработки

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

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

Появление в девяностые годы этой гибкой методологии вызвало ожесточенные споры. Это воспринималось как социологический феномен — революция программистов против засилья менеджеров. Теперь все понемногу успокоилось, и многие практики, такие как непрерывная интеграция, широко приняты. Другие, такие как "тесты предпочтительнее спецификаций", остаются под вопросом. Но становится ясно, что процесс разработки ПО может быть как структурированным, так и гибким (agile).