Фактически каждый из программистов так или иначе применял этот подход. При использовании данного подхода затрачивается время лишь на кодирование и заказчику легко демонстрировать прогресс в разработке в строках кода.
Этот подход может быть рекомендован к использованию в двух случаях:
• для очень маленьких проектов, которые должны завершиться разработкой демонстрационного прототипа;
• для доказательства некоторой программной концепции.
3.3. КАСКАДНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
Каскадные технологические подходы задают некоторую последовательность выполнения видов работ, обычно изображаемую в виде каскада. Иногда их называют подходами на основе модели водопада.
Классический каскадный подход (от англ. pure waterfall — чистый водопад) считается "дедушкой" технологических подходов к ведению жизненного цикла. Его можно рассматривать как отправную точку для огромного количества других подходов. Сформировался классический каскадный подход в период с 1970 по 1985 г. Специфика "чистого" каскадного подхода такова, что переход к следующему виду работ осуществляется только после того, как завершена работа с текущим видом работы (рис. 3.1). Возвраты к уже пройденным видам работ не предусмотрены.
Рис. 3.1. Классический каскадный подход
Данный подход может быть рекомендован к применению в тех проектах, где в самом начале все требования могут быть сформулированы точно и полно, например, в задачах вычислительного характера. Достаточно легко при таком технологическом подходе вести планирование работ и формирование бюджета. Основным недостатком классического каскадного подхода является отсутствие гибкости.
Каскадно-возвратный подход преодолевает недостаток классического подхода благодаря возможности возврата к предыдущим стадиям и пересмотру или уточнению ранее принятых решений (рис. 3.2). Каскадно-возвратный подход отражает итерационный характер разработки программного обеспечения и в значительной степени реальный процесс создания программного обеспечения, в том числе и существенное запаздывание с достижением результата. На задержку оказывают существенное влияние корректировки при возвратах.
Каскадно-итерационный подход предусматривает последовательные итерации каждого вида работ до тех пор, пока не будет достигнут желанный результат (рис. 3.3). Каждая итерация является завершенным этапом, и ее итогом будет некоторый конкретный результат. Возможно, данный результат будет промежуточным, не реализующим всю ожидаемую функциональность.
Каскадный подход с перекрывающимися видами работ (англ. waterfall with overlapping), так же как и классический каскадный подход предполагает проведение работ отдельными группами разработчиков, но эти группы не меняют специализацию от разработки к разработке, что позволяет распараллелить работы и в определенной степени сократить объем передаваемой документации (рис. 3.4).
Рис. 3.2. Каскадно-возвратный технологический подход
Рис. 3.3. Каскадно-итерационный технологический подход
Рис. 3.4. Каскадный подход с перекрывающимися видами работ
Каскадный подход с подвидами работ (англ. waterfall with subprocesses) очень близок подходу с перекрывающимися видами работ. Особенность его в том, что с точки зрения структуры, проект достаточно часто может быть разделен на подпроекты, которые могут разрабатываться индивидуально (рис. 3.5). В данном подходе требуется дополнительная фаза тестирования подсистем до объединения их в единую систему. Следует особое внимание обращать на грамотное деление проекта на подпроекты, которое должно учесть все возможные зависимости между подсистемами.
Рис. 3.5. Каскадный подход с подвидами работ
Рис. 3.6. Спиральная модель
Спиральная модель (spiral model) была предложена Барри Боэмом (Barry Boehm) в середине 80-х годов XX в. с целью сократить возможный риск разработки. Фактически, это была первая реакция на устаревание каскадной модели. Спиральная модель использует понятие прототипа — программы, реализующей частичную функциональность создаваемого программного продукта. Создание прототипов осуществляется в несколько витков спирали, каждый из которых состоит из "анализа риска", "некоторого вида работ" и "верификации" (рис. 3.6). Обращение к каждому виду работы предваряет "анализ риска", причем если риск превышения сроков и стоимости проекта оказывается существенным, то разработка заканчивается. Это позволяет предотвратить более крупные денежные потери в будущем.
Особенность спиральной модели — в разработке итерациями. Причем каждый следующий итерационный прототип будет обладать большей функциональностью.
3.4. КАРКАСНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
Каркасные подходы представляют собой каркас для видов работ и включают их огромное количество.
Рациональный унифицированный подход к выполнению работ
(rational unified process-RUP), изложенный подробно в десятой главе данного учебника, вобрал в себя лучшее из технологических подходов каскадной группы. Весомое преимущество данного подхода состоит в созданном инструментарии его автоматизированной поддержки — программного продукта Rational Rose фирмы "Rational Software Corpation".
При использовании подхода выделяют четыре этапа: начало, исследование, построение, внедрение. В период прохождения этих этапов выполняются виды работ (например, анализ и проектирование), которые к тому же предусматривают итеративность их выполнения (рис. 3.7).
Основные особенности данного подхода:
• итеративность с присущей ей гибкостью;
• контроль качества с возможностью выявления и устранения рисков на самых ранних этапах;
• предпочтение отдается моделям, а не бумажным документам;
• основное внимание уделяется раннему определению архитектуры;
• возможность конфигурирования, настройки и масштабирования.
Рис. 3.7. Рациональный унифицированный подход к видам работ
3.5. ГЕНЕТИЧЕСКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ
Термин "генетический" в названии этой группы подходов связан с происхождением программы и дисциплиной ее создания.
Синтезирующее программирование предполагает синтез программы по ее спецификации. В отличие от программы, написанной на алгоритмическом языке и предназначенной для исполнения на вычислительной машине после трансляции в используемый код, документ на языке спецификаций является лишь базисом для последующей реализации. Для получения этой реализации необходимо решить следующие основные задачи:
— доопределить детали, которые нельзя выразить при помощи языка спецификации, но которые необходимы для получения исполняемого кода;
— выбрать язык реализации и аппаратно-программную платформу для реализации;
— зафиксировать отображение понятий языка спецификаций на язык реализации и аппаратно-программную платформу;
— осуществить трансформацию представления (из спецификации в исполняемую программу на языке реализации);
— отладить и протестировать исполняемую программу.
Автоматическая генерация программ по спецификациям возможна для многих языков спецификаций, особенно для SDL, ASN.1, LOTOS, Estelle, UML (Rational Rose).