Основные модели и методологии разработки программного обеспечения
Список вопросов к Python собеседованию
Жизненный цикл ПО
Software Development Life Cycle, SDLC - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации
Создание и развитие любого продукта происходит постепенно, проходя ряд обязательных этапов, часть из которых может идти параллельно. Жизненный цикл проекта в IT – непрерывный процесс, который заканчивается, лишь когда его решают закрыть.
Этапы жизненного цикла ПО:
- Анализ (подготовка)
- Проектирование
- Создание (программирование)
- Тестирование
- Внедрение
- Сопровождение
Существует некая вариативность в прохождении этих этапов во время разработки и внедрения продукта. Для каждого продукта это происходит по-своему, но чтобы процессом как-то управлять были сформулированы модели жизненного цикла ПО – упрощенное и обобщенное представление о том, как развивается продукт.
В реальности жизнь продукта редко соответствует какой-либо модели.
Парадигмы и модели разработки ПО
По большому счету все модели можно разделить на две больших группы: последовательные и итерационные модели.
Code and Fix
Являлась первой моделью разработки ПО.
Этапы модели:
- выяснение потребностей заказчика;
- создание;
- внедрение
- исправления по итогам отзывов;
Повторяем цикл до полного удовлетворения заказчика (или пока у него не кончатся деньги или терпение)
Каскадная модель
Waterfall Model или «водопад»
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая.
Преимущества:
- Линейность модели облегчает ее понимание;
- Все спецификации и результаты изложены до начала разработки;
- Строгость этапов позволяет планировать сроки завершения всех работ и соответствующие ресурсы
- Хорошо работает для небольших проектов;
- Стоимость проекта определяется на начальном этапе;
Недостатки:
- Сложности при формулировке четких требований и невозможность их изменения;
- Модель водопада неприменима к проектам, требующим непрерывной доработки;
- Отсутствие работающего продукта до окончания последней стадии разработки;
- Тестирование начинается только с середины развития проекта;
- Много технической документации
V-образная модель
V-Model (разработка через тестирование)
Суть этой модели состоит в том, что процессы на всех этапах контролируются, чтобы убедиться в возможности перехода на следующий уровень. Уже на стадии написания требований начинается процесс тестирования. Частично устраняет недостатки каскадной модели.
Преимущества:
- Этапы строго определены;
- Минимизация рисков и устранение потенциальных проблем за счет раннего тестирования;
- Усовершенствованный тайм-менеджмент.
Недостатки:
- Нет возможности адаптироваться к измененным требованиям заказчика;
- Длительное время разработки (иногда до нескольких лет) приводит к тому, что продукт может быть уже не нужен заказчику, поскольку его потребности меняются;
- Нет действий, направленных на анализ рисков.
Итерационная модель
Iterative Model - Итерационная (итеративная) модель
Предполагает разбиение проекта на части (этапы, итерации) и прохождение этапов жизненного цикла на каждом их них. Каждый этап является законченным сам по себе, совокупность этапов формирует конечный результат.
Преимущества:
- Быстрый выпуск минимального продукта даёт возможность оперативно получать обратную связь от заказчика и пользователей;
- Фокус на наиболее важных функциях ПО и улучшение их в соответствии с требованиями рынка и пожеланиями клиента.
- Постоянное тестирование пользователями позволяет быстро обнаруживать и устранять ошибки.
Недостатки:
- Вероятность того, что на определенной итерации придётся переписывать большую часть приложения.
- Отсутствие фиксированного бюджета и сроков.
Инкрементная модель
Incremental Model
Эта модель разработки дает возможность делать продукт по частям — инкрементам. Каждая часть представляет собой готовый фрагмент итогового продукта, который в идеале не переделывается. Улучшение продукта проходит запланировано все время пока жизненный цикл разработки ПО не завершится.
Требования к системе определяются в самом начале работы, после чего процесс разработки проводится в виде последовательности версий, каждая из которых является законченным и работоспособным продуктом.
Преимущества:
- Заказчик может дать свой отзыв касательно каждой версии продукта;
- Есть возможность пересмотреть риски, которые связаны с затратами и соблюдением графика;
- Ошибка обходится дешевле.
Недостатки:
- Функциональная система должна быть полностью определена в начале жизненного цикла для выделения итераций;
- При постоянных изменениях структура системы может быть нарушена;
- Сроки сдачи системы могут быть затянуты из-за ограниченности ресурсов (исполнители, финансы).
Спиральная модель
Spiral Model
Эту модель начали использовать в 1988 году. В спиральной модели жизненный путь разрабатываемого продукта изображается в виде спирали, которая, начавшись на этапе планирования, раскручивается с прохождением каждого следующего шага. Таким образом, на выходе из очередного витка:
- получаем готовый протестированный прототип, который дополняет существующую сборку;
- принимается решение, продолжать ли проект.
Спиральная модель предполагает 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)