# Методологии разработки программного продукта

## Итерационные и инкрементные модели

**Итерационная модель разработки** программного обеспечения (Iterative model) - это модель разработки ПО, в которой процесс разработки разбивается на несколько итераций, каждая из которых проходит через все фазы разработки (анализ, проектирование, кодирование, тестирование и документирование). В конце каждой итерации выполняется анализ результатов и проводится корректировка плана следующей итерации. Таким образом, разработчики могут уточнить требования и функциональные возможности продукта на основе опыта предыдущих итераций, что повышает качество итогового продукта.

**Инкрементная модель разработки** программного обеспечения (Incremental model) - это модель разработки ПО, в которой функциональность продукта разбивается на наборы (инкременты), каждый из которых представляет собой полноценную версию продукта, содержащую новые функции и возможности. Каждый инкремент разрабатывается и тестируется независимо от других инкрементов, и в конце каждой итерации производится интеграция новых функций в общую систему. Таким образом, разработка продукта происходит постепенно, шаг за шагом, позволяя быстро получать обратную связь и быстро реагировать на изменения требований клиента.

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

## Методологии

### Waterfall Model (каскадная модель или «водопад»)

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

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

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

Итого:

<mark style="color:green;background-color:green;">+</mark> Подходит для небольших проектов, где требования четко определены и не будут изменяться.

<mark style="color:green;background-color:green;">+</mark> Подходит, если важен контроль над каждым этапом проекта

<mark style="color:red;background-color:red;">-</mark> Не предусматривает гибкости и возможности быстро адаптироваться к изменениям.&#x20;

### V-модель

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

Основная идея V-модели заключается в том, что качество продукта зависит от качества его тестирования. Каждый этап разработки имеет соответствующий этап тестирования, начиная с тестирования требований и заканчивая тестированием внедрения.

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

Однако, также как и каскадная модель, V-модель не предусматривает возможности быстро адаптироваться к изменениям в требованиях к продукту, что может ограничивать гибкость разработки в динамичных средах. В таких случаях лучше использовать более гибкие методологии, такие как Agile или Scrum.

Итого:

<mark style="color:green;background-color:green;">+</mark> Подходит для небольших и средних проектов, где требования четко определены и не будут изменяться.

<mark style="color:green;background-color:green;">+</mark> Обнаружение ошибок и дефектов на ранней стадии

<mark style="color:green;background-color:green;">+</mark> Контроль качества

<mark style="color:red;background-color:red;">-</mark> Не предусматривает гибкости и возможности быстро адаптироваться к изменениям.

### Agile (Scrum, Kanban, XP, FDD)

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

Методологии Agile, такие как Scrum, Kanban, Extreme Programming (XP), Feature Driven Development (FDD) и другие, позволяют командам быстро реагировать на изменения требований и перестраивать свой подход к разработке, чтобы достичь лучших результатов. В центре философии Agile лежит идея о том, что процесс разработки должен быть гибким и адаптивным, что позволяет командам быстро реагировать на изменения и принимать важные решения на основе обратной связи от пользователей и заказчиков.

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

<mark style="color:green;background-color:green;">+</mark> Гибкости и возможности быстро адаптироваться к изменениям

<mark style="color:green;background-color:green;">+</mark> Быстрый выпуск версий продукта

<mark style="color:green;background-color:green;">+</mark> Быстрое выявление и исправление ошибок

<mark style="color:green;background-color:green;">+</mark> Быстрая оценка продукта пользователями и работы команды

<mark style="color:red;background-color:red;">-</mark> Требуется высокий уровень коммуникаций и получения своевременной обратной связи по продукту и взаимодействия между командой и заказчиком, что может быть трудно организовать в некоторых условиях.

<mark style="color:red;background-color:red;">-</mark> Требуется высокий уровень вовлеченности заказчика: Agile методология требует активного участия заказчика в процессе разработки, что может быть трудно организовать, если заказчик не имеет достаточной экспертизы в области разработки ПО.

<mark style="color:red;background-color:red;">-</mark>  Может быть трудно оценить стоимость проекта на начальных стадиях разработки, что может привести к проблемам с бюджетом проекта.

### RAD Model

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

Плюсы RAD модели:

<mark style="color:green;background-color:green;">+</mark> Быстрое время разработки. RAD модель предполагает создание прототипов быстро и часто. Это позволяет снизить время, необходимое для разработки программного обеспечения, и ускорить процесс создания готового продукта.

<mark style="color:green;background-color:green;">+</mark> Улучшенное взаимодействие со стейкхолдерами. Частые проверки и обратная связь со стейкхолдерами позволяют своевременно реагировать на изменения в требованиях к продукту и внедрять их в процесс разработки.

<mark style="color:green;background-color:green;">+</mark> Снижение затрат на разработку. RAD модель позволяет избежать больших затрат на процесс разработки, поскольку прототипы могут быть быстро созданы и проверены до полной разработки конечного продукта.

Минусы RAD модели:

<mark style="color:red;background-color:red;">-</mark> Не подходит для больших проектов: RAD модель не является подходящей для больших проектов, которые могут потребовать длительного времени разработки и многих компонентов.

<mark style="color:red;background-color:red;">-</mark> Не подходит для сложных проектов: RAD модель не подходит для проектов, которые требуют высокой степени стандартизации, тщательного планирования, высокой степени надежности и безопасности.

<mark style="color:red;background-color:red;">-</mark> Риски согласования: при создании прототипов и быстрой разработке продукта возможны риски связанные с недостаточной проработкой требований и планирования, а также недостаточной валидацией результатов.

### Spiral Model

Модель Spiral (спиральная модель) - это гибкая методология разработки программного обеспечения, которая сочетает в себе итеративный подход с последовательностью шагов, основанных на рисках.

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

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

Плюсы Spiral модели:&#x20;

<mark style="color:green;background-color:green;">+</mark> Гибкость и адаптивность. Спиральная модель является гибкой и адаптивной, что позволяет ей лучше учитывать изменения и потребности заказчика в ходе разработки.

<mark style="color:green;background-color:green;">+</mark> Раннее выявление рисков. Спиральная модель включает в себя оценку рисков на каждой стадии проекта, что помогает снизить риски и улучшить качество продукта, который создается в процессе разработки.

<mark style="color:green;background-color:green;">+</mark> Промежуточные результаты. Спиральная модель предусматривает создание промежуточных результатов на каждой стадии, что позволяет клиенту видеть прогресс и вносить изменения в ходе проекта.

<mark style="color:green;background-color:green;">+</mark> Постоянное улучшение. Спиральная модель способствует постоянному улучшению и оптимизации процесса разработки, что позволяет улучшать качество продукта и повышать эффективность проекта.

Минусы Spiral модели:&#x20;

<mark style="color:red;background-color:red;">-</mark> Необходимость внимательного контроля. Спиральная модель требует более тщательного контроля и управления рисками на каждой стадии проекта, что может потребовать большего внимания и ресурсов.

<mark style="color:red;background-color:red;">-</mark> Сложность. Спиральная модель может быть сложной для понимания и использования, особенно для команд, не имеющих опыта работы с гибкими методологиями.

<mark style="color:red;background-color:red;">-</mark> Необходимость опытной команды. Для эффективного использования спиральной модели необходима опытная команда разработчиков, которая может быстро адаптироваться к изменениям и эффективно управлять рисками.