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

Список вопросов к Python собеседованию

Жизненный цикл ПО

Software Development Life Cycle, SDLC - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации

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

Этапы жизненного цикла ПО:

• Анализ (подготовка)
• Проектирование
• Создание (программирование)
• Тестирование
• Внедрение
• Сопровождение

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

В реальности жизнь продукта редко соответствует какой-либо модели.

Парадигмы и модели разработки ПО

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

Code and Fix

Являлась первой моделью разработки ПО.

Этапы модели:

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

Повторяем цикл до полного удовлетворения заказчика (или пока у него не кончатся деньги или терпение)

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

Waterfall Model или «водопад»

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

Преимущества:

• Линейность модели облегчает ее понимание;
• Все спецификации и результаты изложены до начала разработки;
• Строгость этапов позволяет планировать сроки завершения всех работ и соответствующие ресурсы
• Хорошо работает для небольших проектов;
• Стоимость проекта определяется на начальном этапе;

Недостатки:

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

V-образная модель

V-Model (разработка через тестирование)

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

Преимущества:

• Этапы строго определены;
• Минимизация рисков и устранение потенциальных проблем за счет раннего тестирования;
• Усовершенствованный тайм-менеджмент.

Недостатки:

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

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

Iterative Model - Итерационная (итеративная) модель

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

Преимущества:

• Быстрый выпуск минимального продукта даёт возможность оперативно получать обратную связь от заказчика и пользователей;
• Фокус на наиболее важных функциях ПО и улучшение их в соответствии с требованиями рынка и пожеланиями клиента.
• Постоянное тестирование пользователями позволяет быстро обнаруживать и устранять ошибки.

Недостатки:

• Вероятность того, что на определенной итерации придётся переписывать большую часть приложения.
• Отсутствие фиксированного бюджета и сроков.

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

Incremental Model

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

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

Преимущества:

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

Недостатки:

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

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

Spiral Model

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

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

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Преимущества:

• Управлению рисками уделяется особое внимание;
• Дополнительные функции могут быть добавлены на поздних этапах;
• Есть возможность гибкого проектирования.

Недостатки:

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

Модель хаоса

Chaos model

Её создатель Л.Б.С.Ракун отмечает, что такие модели управления проектами, как спиральная модель и каскадная модель, хотя и хороши в управлении расписаниями и персоналом, не обеспечивают методами устранения ошибок и решениями других технических задач, не помогают ни в управлении конечными сроками, ни в реагировании на запросы клиентов. Модель хаоса — это инструмент пытающийся помочь понять эти ограничения и восполнить пробелы.

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

Гибкая (Agile) модель

Agile Model - гибкая модель разработки, по которой сегодня работает большинство ИТ-проектов.Представляет собой совокупность различных подходов к разработке ПО.

Основные идеи Agile:

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

Преимущества:

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

Недостатки:

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

Гибкие методологии разработки ПО

• SCRUM
• Kanban (看板)
• RUP (Rational Unified Process)
• OpenUP
• DSDM (Dynamic Systems Development Model)
• RAD (Rapid Application Development)
• XP (Extreme Programming)
• FDD (Feature Driven Development)
• ASD (Adaptive Software Development)
• DevOps (Development and Operations)
• DAD (Disciplined Agile Delivery)
• Lean SD (Lean Software Development)
• MDD (Model-Driven Development)
• MSF (Microsoft Solutions Framework)
• PSP (Personal Software Process)
• SAFe (Scaled Agile Framework)
• UP (Unified Process)

Источники¹²³⁴