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

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

Жизненный цикл разработки программного обеспечения или SDLC определяет способ реализации и поддержки продукта. Это поможет вам превратить творческие идеи и требования рынка в функциональность и особенности продукта.

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

Содержание:

1. Модели SDLC
2. Модель водопада
3. V-образная модель
4. Модель большого взрыва
5. Модель прототипирования
6. Итеративная и инкрементальная модель
7. Модель RAD
8. Модель спирального развития
9. Гибкая модель

Модели SDLC

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

Модель водопада

Waterfall - первая модель SDLC в истории разработки программного обеспечения. В модели Waterfall процесс разработки линейный. Задачи и этапы выполняются по очереди в строгом порядке. Прогресс неуклонно течет вниз, как вода над водопадом.

Традиционные фазы в модели водопада:

1. Сбор требований
2. Дизайн
3. Реализация
4. Интеграция и тестирование
5. Развертывание
6. Обслуживание

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

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

• Легко объяснить клиенту и легко понять команде
• Очевидная структура с четко определенными этапами и действиями
• Простое планирование и составление графиков с четкими вехами
• Фазы завершены по очереди
• Ошибки и неудобства легко проверить на каждом этапе
• Каждый этап легко анализировать и оценивать
• Хорошо документированные процессы

Недостатки:

• Работает только с негибкими требованиями
• Невозможно вернуться к завершенным этапам
• Трудно отрегулировать
• Стоимость разработки обычно высока
• Высокий риск ошибок и других неудобств
• Трудно измерить прогресс на этапах

Лучше всего для проектов с:

• Стабильные, однозначные требования
• Четкое определение и видение продукта
• Известные технологии и стабильный стек технологий
• Достаточно ресурсов для внедрения и поддержки
• Короткие сроки

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

V-образная модель, также известная как V-модель или модель проверки и проверки , является расширением подхода Waterfall SDLC. С V-моделью прогресс не движется по прямой линии, а поднимается вверх после реализации и кодирования.

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

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

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

Недостатки:

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

Фазы проекта в V-модели такие же, как и в Waterfall, но с проверкой и валидацией для каждой фазы посредством тестирования . Таким образом, V-модель хороша для проектов, подобных Waterfall.

Модель большого взрыва

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

Ключевая идея модели Big Bang SDLC состоит в том, чтобы направить все доступные ресурсы на разработку самого продукта, в основном с точки зрения кодирования, не беспокоясь о выполнении планов.

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

• Драматически простая модель
• Практически не требуется планирование
• Легко управлять
• Не требует много ресурсов
• Гибкость для команды разработчиков

Недостатки:

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

Подходит для:

• Небольшие команды или отдельные разработчики
• Академические проекты
• Проекты без определенных требований или ожидаемой даты выпуска
• Повторяющиеся и небольшие проекты с низким уровнем риска

Модель прототипирования

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

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

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

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

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

В модели прототипирования отзывы пользователей играют решающую роль в планировании дальнейшего развития.

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

Каждый прототип в этой модели SDLC обычно воплощается в жизнь на следующих этапах :

• Определите требования
• Разработать начальный прототип
• Рассмотрение
• Пересмотреть и улучшить

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

Также существует ряд традиционных видов прототипирования:

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

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

• Поэтапное прототипирование - команда создает различные прототипы и в конечном итоге объединяет их в единый дизайн.

• Экстремальное прототипирование - команда создает прототип из трех частей: статический прототип, прототип симуляции функциональности и прототип реализованных сервисов. Этот тип прототипирования в основном используется при разработке веб-приложений.

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

• Повышенное участие пользователей перед внедрением продукта
• Шанс сократить время и затраты на разработку (в случае удачного прототипа)
• Лучшее понимание функциональности пользователями, участвующими в процессе разработки.
• Раннее обнаружение дефектов
• Быстрая обратная связь
• Простая и ценная аналитика

Недостатки:

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

Подходит для:

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

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

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

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

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

Итеративная и инкрементная модель SDLC может выглядеть как набор мини-моделей Waterfall или V-образных мини-моделей.

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

• Быстро создает ценность для бизнеса, так как рабочий продукт доставляется с каждым приращением
• Можно сделать, используя ограниченные ресурсы
• Предоставляет пространство для гибкости
• Позволяет больше сосредоточиться на ценности для пользователя
• Хорошо работает с параллельной разработкой
• Обнаруживает проблемы на ранних стадиях
• Легко оценить прогресс разработки
• Использует множество отзывов клиентов

Недостатки:

• Требуется тяжелая документация
• Следует заранее определенному набору фаз
• Приращения определяются зависимостями функций и функций.
• Требует большего участия пользователей со стороны разработчиков, чем Waterfall или другие линейные SDLC.
• Может быть сложно интегрировать функции между итерациями, если они не запланированы заранее
• Проблемы с архитектурой или дизайном могут возникнуть из-за неполных требований на ранних этапах
• Сложно управлять
• Трудно предсказать конец проекта

Подходит для:

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

Модель RAD

Модель быстрой разработки приложений (RAD) основана на прототипировании и итеративной разработке без особого планирования. В этой модели планирование отходит на второй план по сравнению с быстрым прототипированием.

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

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

Модель RAD распределяет фазы анализа, проектирования, сборки и тестирования на серию коротких итеративных циклов разработки.

Фазы модели RAD:

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

• Моделирование данных - данные с предыдущего этапа обрабатываются для формирования необходимых наборов данных с идентифицированными и установленными атрибутами.

• Моделирование процессов - наборы данных с предыдущего этапа преобразуются в модели процессов для достижения бизнес-целей и получают описания процессов для добавления, удаления, извлечения или изменения каждого объекта данных.

• Создание приложений - система создается, и кодирование выполняется с использованием средств автоматизации для преобразования моделей процессов и данных в реальные прототипы.

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

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

• Может соответствовать меняющимся требованиям
• Легко измерить прогресс
• Возможность сократить время итераций с помощью мощных инструментов RAD
• Лучшая производительность с меньшим количеством участников команды по сравнению с другими SDLC
• Более быстрое развитие
• Лучшая возможность повторного использования компонентов
• Предыдущие первоначальные обзоры
• Больше шансов получить обратную связь от клиентов

Недостатки:

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

Подходит для:

• Модульные системы, поставляемые поэтапно
• Дизайн-проекты с большим количеством сильного моделирования
• Проекты с функцией автоматической генерации кода
• Проекты с динамически меняющимися требованиями, для которых необходимо представлять небольшие итерации каждые 2–3 месяца.

Модель спирального развития

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

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

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

Недостатки:

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

Подходит для:

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

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

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

Требования и решения в Agile-проектах могут меняться в процессе разработки.

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

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

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

• Меньше времени, необходимого для реализации конкретных функций
• Не оставляет места для догадок благодаря личному общению и постоянному участию клиента
• Качественный результат в кратчайшие сроки
• Ценность бизнеса может быть доставлена ​​и продемонстрирована быстро
• Требует минимум ресурсов
• Высокая адаптивность к меняющимся требованиям

Недостатки:

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

Подходит для:

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

Почему Agile?

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

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

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

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

Подробнее: Как управлять рисками при разработке программного обеспечения .

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

Скрам и Канбан

Существует множество устоявшихся подходов к жизненному циклу гибкой разработки программного обеспечения. Двумя самыми популярными являются Scrum и Kanban .

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

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

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

Вот типичные элементы спринта:

• Планирование спринта , когда команда планирует объем работы, которая должна быть выполнена в данном спринте.

• The Daily Scrum Meeting - короткая ежедневная встреча команды для обсуждения того, что было сделано, что они планируют делать сегодня, и какие проблемы возникли с момента последней встречи.

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

• Ретроспектива спринта проводится прямо перед началом нового спринта. Во время ретроспективы команда Scrum завершает работу и создает планы улучшений для будущих спринтов на основе своего опыта из прошлых спринтов.

Канбан - это метод визуализации управления, широко используемый в модели Agile SDLC. Это помогает улучшить и поддерживать высокий уровень производительности в команде разработчиков. Канбан работает с короткими итерациями: если Scrum длится около недель, то Kanban составляет около часов. Скрам нацелен на завершение спринта, а Канбан - на завершение задачи. Канбан - это анти-многозадачность.

Ключевые практики Канбана:

• Визуализация рабочего процесса
• Ограничение незавершенных задач
• Управление рабочим процессом

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

DevOps

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

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

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

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

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

• Более частые выпуски для более быстрой доставки на рынок
• Больше внимания уделяется улучшению продукта и большему реагированию на потребности бизнеса
• Лучшее сотрудничество между членами команды
• Лучшее качество конечного продукта и более довольные клиенты

Недостатки:

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

Заключение

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

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