Инкрементальная модель

Инкрементальная модель – (инкреция – (in – внутри, (se)cretus – выделенный))

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

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

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

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

• лучше всего, если следующая стадия n+1 начинается по возможности после того, как обновление всех модулей на стадии n закончено,

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

Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

Развитие инкрементального подхода. Технология использования xp-процессов.

Развитием инкрементального подхода явилось создание некоторых новых технологий, пользующихся в настоящее время достаточным успехом:

- экстремальное программирование XP (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

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

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

Потом идёт кодирование, которое заканчивается в тот момент, когда все тесты проходят, и программисты не могут придумать новых тестов.

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

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

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

Данный подход используется в проектах с большим риском, в основном в больших контрактах для системы обороны.

- технология быстрой разработки приложений RAD (Rapid Application Development). RAD - технология обеспечивает экстремально короткий цикл разработки. Быстрая разработка достигается за счет использования компонентно ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD- процесс позволяет проектной группе создать полностью функциональную систему за 60-90 дней.

В данном случае выделяют следующие этапы:

- бизнес-моделирование. Моделируются информационные потоки между бизнес-функциями;

- моделирование данных. Информационный поток отображается в набор объектов данных;

- моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций;

- генерация приложения. Используются языки программирования 4-го поколения, готовые компоненты, для конструирования - утилиты автоматизации;

- тестирование и объединение. Применение повторно используемых компонентов уменьшает время тестирования.

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

Недостатки применения RAD - технологии:

1. Для больших проектов требуются значительные людские ресурсы для создания групп.

2. Модель применима только для тех систем, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.

3. Не применима в условиях высоких технических рисков, т.е. при использовании новой технологии.

В современной программной инженерии выделяют два семейства процессов разработки:

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

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

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

На всем протяжении итерационного цикла требования постоянно меняются, причем цикл состоит из очень коротких итераций.

Базовые действия на каждой итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

Динамизм обеспечивается следующими характеристиками:

• непрерывная связь с заказчиком;

• простота (всегда выбирается минимальное решение)

• быстрая обратная связь (модульное и функциональное тестирование)

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

Базис XP образуют 12 методов:

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

2. Частая смена версий - новые версии каждые 2 недели.

3. Метафора - вся разработка проводится на основе простой общедоступной истории о том, как работает система. Истории обеспечивают заказчики.

4. Простое проектирование.

5. Тестирование - непрерывное написание тестов для модулей. Входным критерием для написания кода является отказавший тестовый вариант. Заказчики участвуют в тестировании.

6. Реорганизация - система реструктуризируется, но ее поведение не меняется. Цель упростить систему, улучшить взаимодействие или добавить в нее гибкость.

7. Парное программирование - весь код пишется двумя программистами, работающими на одном компьютере. Оно приводит к повышению качества и уменьшению времени цикла на 40-50%, при увеличении затрат на ресурсы на 15%

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

9. Непрерывная интеграция - интегрирование системы несколько раз в день по мере завершения каждой задачи.

10. 40-часовая неделя - нельзя работать сверхурочно.

11. Локальный заказчик - в группе все время должен находиться компетентный представитель заказчика, готовый отвечать на все вопросы.

12. Стандарты кодирования - правила, обеспечивающие одинаковое представление программного кода.