Валерий Комсков – Введение в профессию бизнес-аналитика. Отправная точка для приобретения опыта (страница 6)

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

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

• модель состоит из последовательно расположенных этапов (точно так же, как и «Водопад»);

• каждый этап имеет обратную связь с предыдущими;

• исправление ошибок происходит на каждом из этапов сразу при выявлении проблемы – производится промежуточный контроль;

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

• результат появляется только в конце разработки, как и в модели «Водопад».

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

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

Мы получаем несколько циклов разработки – своеобразный «мультиводопад». Каждый цикл делится на модули, а каждый модуль – на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

Когда можно использовать инкрементную модель:

• для проектов, в которых точное техническое задание прописано уже на старте, а продукт должен быстро выйти на рынок.

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

В этом случае создание начинается с реализации части функционала и становится базой для определения дальнейших требований, иными словами, мы получаем так называемый минимально жизнеспособный продукт (Minimum Viable Product). Этот процесс повторяется снова и снова. Версия может быть неидеальной, главное, чтобы она работала. Понимая конечную цель, мы стремимся идти к ней так, чтобы каждый шаг был результативным, а каждая версия – работоспособной.

Когда можно использовать итеративную модель:

• когда важен анализ рисков и затрат;

• в крупных долгосрочных проектах с отсутствием четких требований или вероятностью их динамического изменения;

• при разработке новой линейки продуктов.

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

Еще она называется Verification and Validation model – модель верификации и валидации. Это усовершенствованная каскадная модель, в которой заказчик и команда программистов одновременно составляют требования к системе и описывают, как будут тестировать ее на каждом этапе. V-модель разработки унаследовала структуру «шаг за шагом» от каскадной модели.

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

Ее начали использовать в 1988 году. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее включен анализ рисков и предусмотрена разработка проекта посредством прототипирования.

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

Главные фазы:

1. определение целей, альтернатив, ограничений;

2. анализ, определение и разрешение рисков;

3. фаза разработки и тестирования;

4. планирование новой итерации.

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.