1.2.2. Инкрементная стратегия конструирования

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

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

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

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

• отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;

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

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

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

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

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

Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Каждая линейная последовательность здесь вырабатывает поставляемый инкремент программного обеспечения.

Рис.1.3. Инкрементная модель

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

Примерами инкрементной стратегии разработки являются практически все системы компьютерного моделирования (Derive, Maple, MathCAD, Mathematica, MATLAB и его приложения SIMULINK и др.), системы обработки графической информации (Corel, Adobe Photoshop, Microcal Origin и др.) и многие другие программные продукты разработанные по технологии разработки версий (инкрементов);

Модель экстремального программирования (разработка через тестирование). Одно из современных реализаций инкрементного подхода - экстремальное программирование ХР. Оно ориентировано на очень малые приращения функциональности.

Данная модель имеет наиболее приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.

Экстремальное программирование (eXtreme Programming, XP) – облегченный (подвижный) процесс (или методология), главный автор которого Кент Бек (1999). ХР – процесс ориентирована группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении.

Основная идея ХР – устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов и реляционных баз данных. Поэтому ХР-процесс должен быть высоко динамичным процессом. ХР-группа имеет дело с изменениями требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в ХР-цикле являются: кодирование, тестирование, выслушивание заказчика и проектирование. Динамизм обеспечивается с помощью четырех характеристик: непрерывной связи с заказчиком (и в пределах группы), простоты (всегда выбирается минимальное решение), быстрой обратной связи (с помощью модульного и функционального тестирования), смелости в проведении профилактики возможных проблем.

Рис. 1.4. Модель экстремального программирования V модель

Модель на основе разработки прототипа. Данная модель основывается на разработки прототипов и прототипирования продукта. Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:

• прояснить не ясные требования (прототип UI);

• выбрать одно из ряда концептуальных решений (реализация сценариев);

• проанализировать осуществимость проекта.

Классификация прототипов:

• горизонтальные и вертикальные;

• одноразовые и эволюционные;

• бумажные и раскадровки.

Горизонтальные прототипы — моделирует исключительно UI не затрагивая логику обработки и базу данных. Вертикальные прототипы — проверка архитектурных решений. Одноразовые прототипы — для быстрой разработки. Эволюционные прототипы — первое приближение эволюционной системы.