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 не затрагивая логику обработки и базу данных. Вертикальные прототипы — проверка архитектурных решений. Одноразовые прототипы — для быстрой разработки. Эволюционные прототипы — первое приближение эволюционной системы.
- Университет им. М.Акмуллы
- Учебное пособие
- Введение
- Глава 1. Элементы программной инженерии
- 1.1. Стандарты, стадии и этапы разработок
- 1. Предпроектная стадия - так называемая стадия формирования требований к автоматизированной системе.
- 2. Стадия проектирования
- 3. Стадия внедрения.
- 4. Период сопровождения или пользовательский период.
- 1.2. Стратегии разработки программного продукта
- 1.2.1. Водопадная или каскадная стратегия конструирования
- 1.2.2. Инкрементная стратегия конструирования
- 1.2.3. Эволюционная стратегия конструирования
- 1.3. Примеры оформления технических заданий
- 1.3.1. Техническое задание на создание асутп
- 1.3.2. Техническое задание на разработку компьютерной модели
- 1.4. Инструментальные средства проектирования
- Глава 2. Основные подходы к разработке программ для компьютерного моделирования
- 2.1. Принципы разработки программного продукта
- 2.2. Направления и походы к разработке компьютерных
- 2.2.1. Разработка интерактивных компьютерных моделей для
- 2.2.2. Подходы и инструментарии разработки
- 2.2.3. Разработка сетевых компьютерных систем и
- 2.2.4. Разработка компьютерных вычислительных
- 1. Назначение еспд
- 2. Область распространения и состав еспд
- 3. Классификация и обозначение стандартов еспд
- Информационная технология
- Гост 34.602-89
- Государственный стандарт союза сср
- 1. Общие положения
- 2. Состав и содержание
- 3. Правила оформления
- Порядок разработки, согласования и утверждения тз на ас
- Форма титульного листа тз на ас
- Техническое задание
- Форма последнего листа тз на ас
- Информационные данные
- 2. Утвержден и введен в действие Постановлением Государственного комитета ссср по стандартам от 24.03.89 № 661
- 3. Взамен гост 24.201-85
- 4. Ссылочные нормативно-технические документы