Достоинства и недостатки инкрементной модели кратко

Обновлено: 05.07.2024

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

функциональность продукта
Ускорение графика поставки

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

Такая модель хороша для применения в условиях часто меняющихся требований.

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

Incremental process model Инкрементальная модель разработки программного обеспечения

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

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

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

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

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

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

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

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

Модель поэтапной реализации — разработка только одной части проекта за раз.

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

Когда использовать инкрементальные модели?

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

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

Недостатки инкрементальной модели процесса разработки программного обеспечения.

Следует начать с определения, Жизненный цикл программного обеспечения (Software Life Cycle Model) — это период времени, который начинается с момента принятия решения о создании программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

Модели Жизненного цикла программного обеспечения

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

Каскадная модель

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

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

Жизненный цикл традиционно разделяют на следующие основные этапы :

Анализ требований,
Проектирование,
Кодирование (программирование),
Тестирование и отладка,
Эксплуатация и сопровождение.

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

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

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

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

Область применения Каскадной модели

Ограничение области применения каскадной модели определяется её недостатками. Её использование наиболее эффективно в следующих случаях:

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

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

(поэтапная модель с промежуточным контролем)

Инкрементная модель ( англ . increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.

Поэтапная модель с промежуточным контролем

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

В начале работы над проектом определяются все основные требования к системе, подразделяются на более и менее важные. После чего выполняется разработка системы по принципу приращений, так, чтобы разработчик мог использовать данные, полученные в ходе разработки ПО. Каждый инкремент должен добавлять системе определенную функциональность. При этом выпуск начинают с компонентов с наивысшим приоритетом. Когда части системы определены, берут первую часть и начинают её детализировать, используя для этого наиболее подходящий процесс. В то же время можно уточнять требования и для других частей, которые в текущей совокупности требований данной работы были заморожены. Если есть необходимость, можно вернуться позже к этой части. Если часть готова, она поставляется клиенту, который может использовать её в работе. Это позволит клиенту уточнить требования для следующих компонентов. Затем занимаются разработкой следующей части системы. Ключевые этапы этого процесса — простая реализация подмножества требований к программе и совершенствование модели в серии последовательных релизов до тех пор, пока не будет реализовано ПО во всей полноте.

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

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

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

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

менеджеры должны постоянно измерять прогресс процесса. в случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии;
структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям.

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

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

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

Спиральная модель жизненного цикла

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

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

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

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

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

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

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

получение функционального продукта после реализации каждого инкремента;

предотвращение формирования громоздких перечней требований;

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

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

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

Рисунок 2.12 – Инкрементная модель жизненного цикла

П/Т – программирование и тестирование

В/ПП – ввод в действие и обеспечениеприемки

Возможный информационный поток

исунок2.13 – Вариант инкрементной модели по ГОСТ Р ИСО/МЭК ТО 15271-2002

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

снижение риска неудачи и изменения требований;

распределение риска между несколькими небольшими инкрементами, что сокращает его общую величину;

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

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

ускорение начального графика поставки и графика всего проекта в целом;

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

упрощение работы над проектом при смене состава разработчиков.

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

постепенное привыкание заказчика к системе;

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

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

В ГОСТ Р ИСО/МЭК ТО 15271-2002 выделены следующие достоинства инкрементной модели:

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

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

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

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

Недостатки инкрементной модели жизненного цикла

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

непредусмотренность итераций в рамках каждого инкремента модели;

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

недостаточно чёткое определение требований;

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

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

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

отсутствие снижения общих затрат на выполнение проекта;

возможность изменений в технологиях работ, что может нарушить график работ;

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

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

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

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

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Читайте также: