Привет Друзья! Для того чтоб разработать качественное программное обеспечение, нужно следовать некой последовательности, стратегии и принципам. Все данные пункты можно назвать одним словом - Методология.
Методология разработки ПО – это процесс описания того, как определенный продукт будет разрабатываться, то есть один из способов организации коллективной разработки. Существует множество разных моделей такого процесса, каждая из которых описывает свой подход и нельзя сказать, что среди них выделяется одна, которую нужно использовать в каждом проекте, всё сугубо ситуативно.
Я хочу выделить 3 основных методологии, это:
Водопадная модель
Водопадная модель - каждый этап разработки последовательного цикла продолжает предыдущий. По факту это наш Жизненный цикл разработки программного продукта – SDLC, который мы обсуждали с вами ранее.
Она включает в себя следующие этапы: требования-проектирование-разработка-тестирование-релиз-поддержка
Данная модель подходит под долголетние проекты в крупных компаниях, когда есть возможность первоначально составить требования, полноценные, включить в них все и на протяжении всего процесса разработки их не менять, подготовить дизайн-проект, написать полностью код проекта и только потом его протестировать. Это очень важно, тестирование идет не параллельно с разработкой, а только после ее полнейшего завершения. Далее идет релиз, всего продукта, а не поэтапно и поддержка.
Плюсы данной методологии:
+ полное документирование каждого этапа, всегда доступно требование;
+возможность распланировать сроки и затраты;
Минусы данной методологии:
- необходимо утвердить полный объем требований к системе, в случае необходимости внести новые требования, мы не можем вернуться к старым и нам необходимо переделать все заново;
-увеличение затрат времени и средств, при необходимости внесения новых требований;
Пример такого проекта: крупный банк решил создать внутренний чат для своих сотрудников, он может позволить потратить на это длительный промежуток времени, пока его сотрудники пользуются общедоступными приложениями, например Jabber.
V-образная модель
V-образная модель - это модифицированная версия каскадной – тестирование начинается со стадии написания требований и происходит на каждом этапе.
Плюсы данной методологии:
+есть строгие этапы;
+раннее тестирование;
+промежуточное тестирование;
Минусы данной методологии:
-отсутствие гибкости модели;
-отсутствие возможности внесения динамических изменений;
-написание кода происходит только в середине процесса;
Когда использовать V-модель?
- Если требуется тщательное тестирование продукта;
- Для малых и средних проектов, где требования четко определены и фиксированы;
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков;
Итерационная модель
Итерационная модель – жизненный цикл создания продуктов разбит на ряд мини циклов. И самая популярная из них это Agile.
Итерация - разработка отдельного компонента системы, после чего добавляется к ранее разработанным компонентам.
Минусы данной методологии:
+раннее создание работающего ПО;
+очень гибкие, готовы к изменениям на любом этапе разработки;
Минусы данной методологии:
-каждая фаза самостоятельна;
-не все требования известны;
Используется на Крупных проекты, когда известны частичные требования и будут меняться во время разработки
Agile – набор методов и принципов гибкого управления проектами
Выделяют 4 основных принципа Agile методологии:
- люди и взаимодействия важнее процессов и инструментов (если есть принципы, которые мешают нашей работе, то от них нужно избавиться. Люди должны сами выбирать инструменты и процессы);
- работающий продукт важнее исчерпывающей документации (большая часть времени должна уходить на функционал продукта, а не на документацию);
- сотрудничество с заказчиком важнее согласований условий контракта (не должно быть избыточной привязанности с контрактом, который регулирует наши взаимоотношения с заказчиком);
- готовность к изменениям важнее следования первоначальному плану (мы в любом случае будем вносить изменения);
Основная составляющая данной методологии это - Спринт (итерация) – временной отрезок в 2-4 недели, в течении которого у нас создается часть продукта, которая соответствует тем требованиям, которые мы берем в начале спринта. В начале каждого спринта мы набираем часть задач которые должны реализовать за этот промежуток времени,
Agile включает в себя две вариации: Kanban и Scrum
Kanban – это конвейерная схема. У нас имеется backlog, где хранятся задачи по приоритету и где они берутся и выполняются поочередно. Мы переносим задачу в разработку, тестируем ее и отправляем в релиз и пока она не будет выполнена, мы не берем следующую.
Отдельно необходимо отметить, что Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой.
Scrum– это так же конвейерная схема, но в ней возможно производство одновременно нескольких задач. У нас имеется общий backlog задач, мы выбрали на этот спринт 10 штук ( к примеру), они могут параллельно или последовательно, в зависимости от численности нашей команды разрабатываться, проходить через следующие этапы:
Анализ-разработка-разработка завершена-тестирование-релиз.
После "Анализа" задача попала в "Разработку", как только она завершилась она попадает в стадию "Разработка завершена", где ее тестируют, и если мы обнаружили баг, то мы возвращаем ее на этап "Разработки", если нет то отправляем в "Релиз". В конце спринта подводятся итоги и остатки переносятся на следующий спринт и так далее.
Допустим наш проект состоит из 10 блоков. На разработку каждого блока нам требуется 1месяц. Мы разрабатываем первый блок, запускаем его в релиз и наш пользователь уже может пользоваться данным продуктом, далее второй блок и т.д.
Теперь сравним все 3 методологии:
На разработку 1 блока уходит месяц, следовательно если мы используем схему Водопадной модели или V-образную, то наш продукт будет готов через 10 месяцев и только после этого у нас начнут появляться пользователи, отзывы и пожелания от них, и на исправление или если Мы захотим внести что-то новое, то на это уйдет очень много времени. А если мы используем Agile, то наш продукт начнет функционировать уже со второго месяца, и к концу разработки проекта, Мы будем иметь большое количество пользователей нашего продукта и иметь обратную связь от них, так же мы сможем в любой момент изменить направление нашего продукта, в ту которая будет нам выгоднее.
Друзья, вот мы и рассмотрели такую важную тему как виды методологии разработки программного продукта, обязательно выучите ее, ведь это основы разработки программного продукта. Пришло время прощаться, подписываетесь на канал, ставьте лайк и до новых встреч!
