11 методологий разработки программного обеспечения и как выбрать одну из них
12 августа 2021 г.
В разработке программного обеспечения существует несколько методологий, которые разработчики могут использовать для разработки, планирования, производства и тестирования программного обеспечения. Решение о том, какой из них лучше для вас, может зависеть от ваших конкретных потребностей и уникальных требований вашего проекта. Если вы работаете с программным обеспечением, важно знать, каковы общие методологии и как они используются, чтобы вы могли решить, какую из них использовать. В этой статье мы определяем методологии разработки программного обеспечения, перечисляем и описываем распространенные методологии и даем советы по их выбору.
Что такое методологии разработки программного обеспечения?
Методология разработки программного обеспечения представляет собой структурированный подход к проекту разработки программного обеспечения. Эффективные методологии часто сочетают в себе четко определенные шаги с философией дизайна или процесса. Выбор правильной методологии для вашего проекта может принести пользу как клиенту, так и команде разработчиков, поскольку позволяет установить точный график проекта, повысить эффективность и привести к более качественным результатам с соблюдением сроков.
Общие методологии разработки программного обеспечения
Вот 11 наиболее распространенных методологий разработки программного обеспечения:
1. Проворный
Agile — это набор убеждений, которые разработчики могут применять к своим решениям в процессе разработки программного обеспечения. Хотя это не совсем методология, в agile есть несколько принципов, на которых разработчики сосредоточились для стандартизации методов, и эти принципы привели к разработке связанных фреймворков, таких как бережливое производство и схватка. Эти принципы включают в себя:
Разделение проекта на управляемые этапы
Инкрементальная разработка и поставка программного обеспечения, а не единовременная поставка при полном завершении
Разработка деталей в короткие сроки или итерации, обычно в течение недель или месяцев.
Постоянное взаимодействие и обратная связь с клиентом
2. DevOps
DevOps получил свое название от сочетания «разработки» и «эксплуатации», двух отделов, которые обычно работают независимо друг от друга. В качестве методологии DevOps фокусируется на установлении сотрудничества между этими традиционно разделенными командами на протяжении всего жизненного цикла разработки программного обеспечения. Объединение их методов может привести к повышению эффективности, ускорению разработки программного обеспечения и повышению качества продукции.
3. Водопад
В этой методологии разработчики полностью завершают один этап, прежде чем приступить к следующему. Каждый этап имеет свои собственные требования и план и зависит от исходных данных предыдущего этапа. Таким образом, развитие переходит от одного этапа к другому. Там нет перекрытия работы между любыми двумя этапами.
Шесть этапов методологии водопада:
Требования: это этап концептуализации, на котором разработчики определяют ожидания от проекта и функции разрабатываемого продукта.
Дизайн системы: на этом этапе разработчики определяют архитектуру программного обеспечения и другие требования к системе.
Реализация: Разработчики разрабатывают программное обеспечение отдельными модулями, тестируя каждый на предмет изолированной функциональности.
Интеграция и тестирование: разработчики объединяют блоки и проверяют интегрированную систему на наличие недостатков или ошибок.
Развертывание: Программное обеспечение становится доступным на рынке или для использования клиентами.
Техническое обслуживание: разработчики устраняют или устраняют проблемы, которые становятся известными во время фактического использования.
4. Спираль
В спиральной методологии процесс разработки состоит из четырех фаз. Разработчики постоянно проходят эти этапы по спирали или циклу. После каждого прохода они переходят к новой итерации разработки с целью постепенного улучшения продукта с каждой итерацией.
Четыре этапа спиральной методологии:
Планирование: разработчики определяют свои цели на данном этапе разработки.
Анализ рисков. Разработчики прогнозируют риски и пытаются разработать для них решения.
Инжиниринг: разработчики проектируют и разрабатывают продукт на основе предыдущих этапов.
Оценка: разработчики оценивают состояние проекта и строят планы на следующую итерацию.
5. Быстрое применение
Основными целями быстрой разработки приложений, или RAD, являются быстрые итерации и быстрый выпуск прототипов. Меньше внимания уделяется следованию жесткому плану и больше сбору и реализации отзывов от пользователей. RAD обеспечивает повышенную гибкость, поскольку разработчики могут корректировать свои требования в ответ на отзывы, а совместный характер методологии может привести к большей удовлетворенности клиентов.
РАД состоит из четырех этапов:
Планирование требований: разработчики определяют требования и спецификации проекта.
Пользовательский дизайн: разработчики и клиент работают вместе в повторяющемся процессе, в ходе которого они разрабатывают прототип, тестируют его и обсуждают его успехи и неудачи. Они продолжают этот циклический процесс, пока не достигнут приемлемого уровня детализации.
Конструкция: На основе прототипов разработчики создают рабочую версию конечного программного приложения.
Переход: это заключительный этап подготовки программного обеспечения к запуску. Он включает в себя преобразование данных, тестирование продукта и обучение пользователей.
6. Метод разработки динамических систем
Метод разработки динамических систем, или DSDM, является разновидностью RAD. DSDM делает упор на сотрудничество с клиентом или пользователем и следует итеративному процессу. Он инкрементный, то есть разработчики сначала создают прототип, демонстрирующий базовые функции приложения, а затем предоставляют остальные функции.
В жизненном цикле DSDM есть четыре фазы:
Технико-экономическое обоснование и бизнес-исследование: разработчики определяют требования и определяют подходящий метод для проекта.
Функциональная модель и итерация прототипа: разработчики создают прототипы, демонстрирующие функциональность.
Итерация проектирования и сборки: разработчики совершенствуют прототипы, пока не создадут приемлемую функциональную модель.
Внедрение: пользователи проходят обучение, и программное обеспечение входит в операционную среду.
7. Прототип
Методология прототипа сочетает в себе итеративную систему с методом проб и ошибок. В этой методологии разработчики создают прототип, тестируют его и совершенствуют до тех пор, пока он не достигнет приемлемого уровня функциональности для демонстрации клиенту. Затем, основываясь на отзывах, они могут внести необходимые изменения при создании фактического программного приложения.
В методологии прототипа есть шесть этапов:
Сбор и анализ требований: разработчики определяют ожидания пользователей и определяют требования к приложениям.
Быстрый дизайн: разработчики создают быстрый дизайн приложения, чтобы дать представление о его возможностях и создать основу для прототипов.
Создание прототипа: разработчики создают рабочую модель приложения на основе быстрого дизайна.
Оценка пользователей: разработчики представляют прототип клиенту или представителям пользователей, которые оставляют отзывы.
Уточнение: разработчики улучшают прототип до тех пор, пока он не удовлетворит ожидания клиента или пользователей.
Внедрение и обслуживание: Разработчики тестируют приложение, запускают его и выполняют плановое обслуживание.
8. Экстремальное программирование
Экстремальное программирование, или XP, ориентировано на частые выпуски версий программного обеспечения в короткие сроки, что позволяет разработчикам включать новые требования по мере необходимости в каждую версию. Эта методология опирается на регулярную обратную связь и открытое общение с клиентом для установления этих требований. Преимущество XP заключается в том, что он помогает гарантировать, что все члены команды разработчиков знают о целях проекта и могут координировать свои усилия.
XP — это итеративная методология, каждая итерация которой состоит из четырех этапов:
Планирование: разработчики и клиент обсуждают видение и цели продукта.
Проектирование: разработчики определяют код перед его написанием, стремясь к простоте.
Кодирование: разработчики пишут код и переделывают его структуру, чтобы добиться простоты, влияя на функциональность.
Тестирование: разработчики проверяют код на функциональность. Часто эта фаза происходит одновременно с фазой кодирования.
Слушание: разработчики получают обратную связь от клиента и вносят соответствующие изменения.
9. Разработка, ориентированная на функции
Разработка, управляемая функциями, или FDD, представляет собой структуру, основанную на гибких принципах, которые организуют свои задачи разработки вокруг основных функций программного обеспечения. В состав FDD входят:
Менеджер проекта: курирует общий проект
Главный архитектор: Проектирует программную систему
Менеджер по развитию: курирует деятельность команды разработчиков
Главный программист: помогает с проектированием системы
Владелец класса: отвечает за кодирование и тестирование функций программного обеспечения.
Эксперт предметной области: помогает убедиться, что команда разработчиков соответствует ожиданиям клиента.
FDD придерживается пяти шагов при разработке наборов функций в короткие сроки. Эти:
Разработайте общую модель: разработчики определяют проблему или потребность, которую они хотят решить с помощью приложения.
Создайте список функций: разработчики определяют необходимые функции для приложения на основе требований клиента.
Планирование по функциям: разработчики планируют порядок разработки функций. Они также пытаются прогнозировать риски и препятствия для развития.
Дизайн по функциям: главный программист определяет приоритеты функций и распределяет роли.
Сборка по функциям: разработчики создают и тестируют функцию, а утвержденные версии добавляются в окончательную сборку.
10. Совместная разработка приложений
Совместная разработка приложений, или JAD, предполагает участие клиента и пользователей в проектировании и разработке приложения. Разработчики, клиент и конечные пользователи посещают структурированные, целенаправленные семинары, чтобы достичь консенсуса в отношении требований к программному обеспечению. В состав этих сессий входят следующие участники:
Исполнительный спонсор: руководитель, принимающий решения, который может поделиться подробностями о ресурсах.
Менеджер проекта: отвечает за особенности проекта, такие как координация и планирование.
Клиент и конечные пользователи: предоставление информации о потребностях и ожиданиях
Фасилитатор: модерирует сессию, улаживает споры и гарантирует, что участники решают все вопросы.
Scribe: Записывает детали сеанса.
11. Рациональный унифицированный процесс
Rational Unified Process, или RUP, — это гибкая методология, которая делит разработку на четыре фазы:
Начало: Разработчики определяют осуществимость проекта и ресурсы, которые им могут понадобиться для его реализации.
Разработка: разработчики прогнозируют стоимость проекта и определяют потенциальное использование программного обеспечения.
Конструкция: разработчики проектируют, создают и тестируют программное обеспечение.
Переход: Программное обеспечение входит в рабочую среду. На основе любых отзывов разработчики вносят коррективы.
На каждом этапе разработчики также выполняют пять инженерных дисциплин, хотя и с разной степенью внимания в зависимости от этапа. Эти:
Бизнес-моделирование: описание процесса и ролей
Анализ и дизайн: объяснение того, как реализовать цели
Реализация: определение и выполнение задач
Тестирование: оценка осуществимости или функциональности
Развертывание: Запуск усилий или продукта
Советы по выбору методологии разработки программного обеспечения
Вот несколько советов по выбору правильной методологии разработки программного обеспечения для вашего проекта:
Понимание потребностей клиента или пользователя
Знание того, чего ожидает клиент или пользователь и могут ли измениться их потребности, может стать прочной основой для выбора методологии. Если ваша целевая аудитория имеет фиксированные или довольно устойчивые потребности, скорее всего, подойдет непоследовательный подход. Однако, если ваша аудитория разнообразна и имеет разные потребности, вы можете ожидать значительного количества отзывов и можете рассмотреть более совместную методологию.
Учитывайте характеристики проекта
Такие характеристики, как размер проекта и временные рамки, также могут помочь определить, какую методологию использовать. Небольшие проекты обычно требуют меньшего количества людей, ресурсов и корректировок, и в этом случае может подойти линейная модель, такая как метод водопада. Напротив, крупный проект с относительно сжатыми сроками может выиграть от гибкой структуры.
Определите, насколько гибкими вы можете быть
Гибкость означает вашу способность адаптироваться к новым требованиям. Если ваша команда может управлять меняющимися ожиданиями клиентов на протяжении всего процесса разработки, вам может подойти адаптивная методология, такая как экстремальное программирование. Если вашей команде требуется предсказуемость для производства высококачественного продукта, идеальным может быть стабильный процесс, такой как методология водопада.