Раздел 9 организация проектирования и разработки программного обеспечения

1.Методологии разработки программного обеспечения – каскадная, спиральная, инкрементальная. Их сущность и области применения.

Каскадная (водопад)

Данная модель также носит название «водопад». Классическими представителями реализации данной методологии являются стандарты ISO и CMM.

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

Модель предполагает следующие свойства взаимодействия этапов:

• модель состоит из последовательно расположенных этапов;

• каждый этап полностью заканчивается до того, как начнется следующий;

• этапы не перекрываются во времени: следующий этап не начинается до тех пор, пока не завершится предыдущий;

• возврат к предыдущим этапам не предусмотрен либо всячески ограничен;

• исправление ошибок происходит лишь на стадии тестирования;

• результат появляется только в конце разработки.

Критерием появления результата является отсутствие ошибок и точное соответствие продукта первоначальной спецификации.

Н едостатки

a) требования к объектам определены недостаточно четко;

b) система обычно слишком велика, чтобы все работы по ее созданию выполнять однократно;

c) предполагаемые скорые изменения в технологиях работ;

Преимущества

a) однократное представление всех возможностей (характеристик) системы;

b) необходимость только единственной фазы перехода от старой системы к новой.

Инкрементальная (итеративная)

Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации,продукт развивается инкрементально.

С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).

Недостатки

а) требования к объектам определены недостаточно четко;

b) предусмотрены сразу все возможности системы;

c) предполагаемые скорые изменения в технологиях работ;

d) возможные текущие изменения требований к системе;

е) привлечение ресурсов (средств или персонала) на длительный период ограничено.

Преимущества

a) необходимость изначального использования характеристик системы;

b) пригодность для использования промежуточного продукта;

c) естественное разделение системы на наращиваемые компонент (инкременты);

d) возможности наращивания привлекаемого персонала и средств.

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

Спиральная модель была впервые сформулирована Барри Боэмом. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков:

Дефицит специалистов. 

Нереалистичные сроки и бюджет.

Реализация несоответствующей функциональности.

Разработка неправильного пользовательского интерфейса.

“Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток изменений.

Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

Недостаточная производительность получаемой системы.

“Разрыв” в квалификации специалистов разных областей знаний.

Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

Коммерческими представителями данной методологии являются RUP (Rational Unified Process), MSF (Microsoft Consulting Services). Результат появляется фактически на каждом витке спирали. Этот результат, который является промежуточным, анализируется, а затем выявленные недостатки продукта становятся поводом для инициирования следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в итоге выбирается обоснованный вариант, который доводится до реализации. Спираль завершается тогда, когда клиент и разработчик приходят к согласию относительно результата.

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

оценка и разрешение рисков,

определение целей,

разработка и тестирование,

планирование.

На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:

н ебольшую команду программистов (от 2 до 10 человек);

короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);

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

Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости, имеет смысл применение Spiral Architecture Driven Development. Данная методология, включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет существенно снизить архитектурные риски, что является немаловажным фактором успеха при разработке крупных систем.