К сожалению, большая часть программных проектов в настоящее время не удовлетворяет критериям для использования каскадного подхода. Требования постоянно изменяются; проекты часто выходят в неисследованные области, пытаясь решить новые проблемы и испытывая новые технологии и т.д. Итерационный процесс разработки, основанный на спиральной модели Бема (Boehm), призван помочь в решении прежде всего этих проблем. Его суть состоит в том, чтобы с самого начала уменьшить риск неопределенности в проекте путем прохождения установленной последовательности действий (выработка требований, анализ, проектирование и т.д.) несколько раз и запланированного повторения каждого из основных действий. Каждая итерация заканчивается созданием исполняемой программы. Кроме прочих преимуществ, этот подход позволяет на ранней стадии идентифицировать проблемы, связанные с непостоянством требований, допускает вовлечение в разработку конечного пользователя и, следовательно, создание обратной связи, дает более высокий уровень информированности о состоянии проекта и т.д. На рис. 5.2 итерационный процесс показан графически.
Более подробно итерационный подход рассматривается в контексте других подходов, изучаемых в этой главе.
Рациональный унифицированный процесс (Rational Unified Process — RUP) — это результат развития процесса Objectory(права на него были недавно приобретены компанией Rational Software), объединенного с процессом RationalApproachЧерез какое-то время он был расширен за счет включения других аспектов и оптимальных методов разработки программ, принятых в индустрии ПО уже многие годы.
В основе RUP лежат следующие признанные методы.
· Итеративная разработка программы. Главная проблема при традиционной (т.е. каскадной) разработке — слишком позднее обнаружение дефектов проекта и неприемлемые затраты на их устранение на этом этапе. Итерационная разработка идет по более непрерывному и цикличному пути, что упрощает корректирование движения. Таким образом, можно заблаговременно выявить потенциально опасные вопросы и устранить риск на ранней стадии. Проблемы выявляются непрерывно и решаются с меньшими затратами, чем если бы они обнаруживались при самом завершении разработки, где они угрожали бы результату всего проекта.
· Управление требованиями. Часто возможность изменения заложена в самой природе требований. Иначе говоря, никогда не бывает, чтобы в начале проекта все требования уже были зафиксированы и очерчены. Напротив, в ходе проекта происходит постепенная идентификация, осмысление и уточнение требований. Таким образом, требованиями надо внимательно управлять, чтобы обеспечить успех проекта.
· Применение компонентной архитектуры. Компонентное программное обеспечение дает преимущество истинно модульного характера разработки. Модульность улучшает общую архитектуру. Кроме того, компоненты, разработанные на месте или приобретенные, способствуют повторному использованию как в исходной, так и в адаптированной форме.
· Визуальное моделирование ПО. Как говорит Гради Буч, "модель— это упрощение действительности, которое полностью описывает систему с определенной точки зрения" Построение моделей позволяет лучше понять проблему и облегчает обмен мыслями о ней, благодаря чему создание сложных систем становится более управляемым. Визуальное моделирование — это наилучший способ моделирования, так как оно позволяет работать на более высоком уровне абстракции.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.