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

Опубликовано 06 March 2020

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

«Если вы не в состоянии планировать, вы планируете потерпеть неудачу». - Бенджамин Франклин


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


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


SDLC: Каков жизненный цикл разработки программного обеспечения и почему так важно иметь его?


7 этапов SDLC


1. Анализ и планирование

2. Требования

3. Дизайн и прототипирование

4. Разработка программного обеспечения

5. Тестирование

6. Развертывание

7. Техническое обслуживание и обновления


5 лучших моделей разработки программного обеспечения (и как выбрать подходящую для вас)

1. Waterfall

2. Agile и Scrum

3. Incremental and Iterative

4. V-Shaped

5. Spiral


SDLC: Каков жизненный цикл разработки программного обеспечения и почему так важно иметь его?


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


При этом программное обеспечение никогда не бывает «законченным». Даже выпуск вашей первой версии может рассматриваться как еще один шаг в жизненном цикле вашего программного обеспечения.


Нельзя недооценивать важность наличия четкого процесса и знания этапов разработки ПО.


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


Но, может быть, даже более того, использование формализованного SDLC имеет ряд других преимуществ:


  • Создает общий словарь для каждого шага по пути
  • Определяет каналы связи и ожидания между разработчиками и заинтересованными сторонами проекта
  • Устанавливает четкие роли и обязанности для всей вашей команды (разработчиков, дизайнеров, менеджеров проектов и т. Д.)
  • Предоставляет согласованное «определение выполненного» для каждого шага, чтобы остановить сползание области и помочь поддерживать движение проекта
  • Формализует, как обрабатывать ошибки, запросы функций и обновления

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

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


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


Я знаю, какой вариант я бы выбрал. Итак, давайте начнем с понимания основных «строительных блоков» SDLC, а затем посмотрим, как их оптимизировать, выбрав правильный процесс разработки программного обеспечения для вашей команды.


7 этапов разработки программного обеспечения (SDLC)


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


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


1. Анализ и планирование


Как только клиент или заинтересованная сторона запросили проект, планируется первый шаг разработки ПО.

Обычно это означает изучение:

Выравнивание: Как этот проект связан с более крупной миссией и целями вашей компании?

Наличие и распределение ресурсов: есть ли у вас люди и инструменты, необходимые для этого?

Планирование проекта: как этот проект соответствует целям вашей компании и другим задачам?

Оценка стоимости: сколько это будет стоить?

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


В конце фазы планирования у вас должно быть достаточно информации, чтобы составить общий объем работ (SOW) - план, который детализирует, что строится, почему и как, по вашему мнению, он собирается вместе.


2. Требования к программному обеспечению


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


Переходя от фазы планирования и продолжая заполнять SOW, задавайте вопросы об особенностях этого проекта, таких как:


Какую проблему это решает?

Кто будет использовать это и почему?

Какой тип ввода / вывода данных необходим?

Вам нужно будет интегрироваться с другими инструментами или API?

Как вы будете обращаться с безопасностью / конфиденциальностью?

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


3. Дизайн и прототипирование


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

Как сказал Стив Джобс: Дизайн - это не только то, как он выглядит и чувствуется. Дизайн - это то, как он работает.


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

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


4. Разработка программного обеспечения


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


Этот этап, очевидно, является самым сложным и потенциально рискованным этапом SDLC (и каждый из процессов разработки программного обеспечения, которые мы обсудим ниже, обрабатывает его по-разному). Однако, работаете ли вы в Agile-спринтах, создаете MVP или используете более традиционный метод waterfall, цель здесь состоит в том, чтобы придерживаться SOW, избегать ползучести и создавать чистое, эффективное программное обеспечение.


5. Тестирование программного обеспечения


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


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


6. Развертывание программного обеспечения


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

В большинстве компаний этот шаг должен быть в значительной степени автоматизирован с использованием модели непрерывного развертывания или инструмента Application Release Automation (ARA).


7. Техническое обслуживание и обновления ПО

SDLC не заканчивается после того, как ваше программное обеспечение запущено в работу. Это «жизненный цикл», помните? Окончание одного этапа - это только начало другого, и это касается и постзапуска.


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

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


5 лучших моделей разработки программного обеспечения (и как выбрать подходящий для вас).


Хотя SDLC, о котором мы говорили выше, может показаться пошаговым планом создания программного обеспечения, на самом деле это скорее руководство.


Да, вам необходимо установить флажки, чтобы убедиться, что вы поставляете и поддерживаете отличное программное обеспечение. Но как вы их проверяете, когда и в каком порядке зависит от вас. За прошедшие годы ряд различных моделей разработки программного обеспечения были формализованы для решения все более сложных проектов. Но какой из них подходит вам?


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


1. Waterfall

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

Что это:

Процесс разработки программного обеспечения Waterfall (также известный как «линейная последовательная модель» или «Классическая модель жизненного цикла») является одной из самых старых и традиционных моделей для создания программного обеспечения. В его самой основной форме вы можете думать о методе «Водопад» как о последовательном выполнении каждого шага SDLC - вы должны завершить каждый шаг последовательно, прежде чем двигаться дальше. Однако в большинстве практических приложений фазы слегка перекрываются, и между ними передается обратная связь и информация.


Некоторые люди также любят называть этот процесс «планомерным», так как для завершения проекта сначала нужно знать все, что нужно сделать и в каком порядке. Отсюда и название «Водопад», так как каждая часть течет в следующую.


Этапы разработки программного обеспечения:
  • Планирование
  • Требования
  • Разработка системы и программного обеспечения
  • Реализация
  • Тестирование
  • Развертывание
  • Обслуживание / Обновление
Для кого эта модель: Команды с жесткими конструкциями и необходимыми документами.


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


В более практическом плане модель «Waterfall» лучше всего подходит для более крупных организаций (например, государственных учреждений), которым требуются подтверждения и документация по всем требованиям и масштабам до начала проекта.


Кому не подойдет модель «Waterfall» :

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

Хотя эта модель проста, самый большой ее недостаток - отсутствие гибкости. Вы не будете создавать и тестировать MVP или прототипы и передумывать на этом пути. И из-за этого, если ваша область действия не написана строго, вы можете в конечном итоге принять неверный путь, не зная его до дня запуска.


2. Agile и Scrum

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

Что это:


Процесс разработки программного обеспечения Agile (и его самая популярная методология программирования, Scrum) выбирают итеративный и динамичный подход к разработке.


В отличие от строгой последовательной последовательности процесса Waterfall, в Agile межфункциональные команды работают в «Спринтах» от 2 недель до 2 месяцев, чтобы создать и выпустить полезное программное обеспечение для клиентов для обратной связи.


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


Agile - это гораздо больше, чем простая модель (о чем мы расскажем в этом руководстве по внедрению Agile и Scrum). Тем не менее, вот простой пример того, как это может выглядеть на практике. Допустим, вы создаете новую функцию для одного из ваших продуктов, которая может иметь функции X, Y и Z. Вместо того, чтобы тратить месяцы на создание всего, вы потратите 2-4 недели на то, чтобы создать минимум, который будет полезен и пригоден для использования (в так называемом «Agile Sprint»), а затем предоставите его своим клиентам.

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


Этапы разработки программного обеспечения:
  • Резерв продукта
  • Спринт отставание
  • Sprint (Дизайн и разработка)
  • Выпуск рабочего программного обеспечения
  • Обратная связь и проверка (добавить в бэклог)
  • Планировать следующий спринт
Для кого: Динамичные команды, которые постоянно обновляют продукты.


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


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


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


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


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


3. Постепенная и итеративная модель


Что это:

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

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

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


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


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


Однако в процессе итеративной разработки программного обеспечения каждая версия, которую вы выпускаете, включает в себя версию всех ваших запланированных функций. Думайте об этом, как о сборке v0.1 с самой простой версией каждой функции, а затем обновляете ее по всем направлениям в v0.2, v0.3 и так далее.


Постепенные фазы:
  • Планирование приращения
  • Характеристики
  • Развитие
  • Проверка
  • Повторение для каждой версии
Итерационные фазы:
  • Анализ
  • Дизайн
  • Развитие
  • Тестирование (повторяйте их, пока не будете готовы к выпуску)
Для кого это подойдет: Команды с четкими требованиями, которые хотят большей гибкости, чем метод Waterfall.


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


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

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


Для кого эта модель не подойдет: у команды, у которой нет четкого долгосрочного технологического плана.


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


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


В чем разница между инкрементным, итеративным и гибким?


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


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


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


4. V-Shaped


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


Что это:

V-образный процесс разработки программного обеспечения представляет собой классический метод Waterfall, который компенсирует самое большой его пробел: отсутствие тестирования.


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


Этапы разработки программного обеспечения:


  • Требования
  • Характеристики
  • Дизайн высокого уровня
  • Низкоуровневый дизайн
  • развитие
  • Модульное тестирование
  • Интеграционное тестирование
  • Тестирование системы
  • Приемочное тестирование
Для кого это: Команды, работающие над небольшими проектами с узким кругозором.


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


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


Даже самые продуманные планы часто сбиваются с пути. И недостатки этого процесса в основном обратны его положительным чертам.


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


5. Spiral


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


Что это:

Процесс разработки программного обеспечения Spiral сочетает в себе V-образный процесс, фокусирующийся на тестировании и оценке рисков, с инкрементным характером Итеративного, Инкрементного и Agile.


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


Этапы разработки программного обеспечения:


  • Планирование
  • Оценка риска
  • Разработка и проверка
  • Оцените результаты и спланируйте следующий «цикл»
Для кого это: команды, не склонные к риску, работающие над большими проектами.


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


Для кого это подойдет: Для большинства людей.


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


Процессы и планы - всего лишь догадки


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

1. Поймите это: знайте, что вы хотите построить и почему.

2. Построить это: Дизайн и разработка рабочего программного обеспечения.

3. Протестируйте это: дайте пользователям попробовать и собрать отзывы.

4. Развивайте его: используйте эту обратную связь, чтобы сделать ее лучше.


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