Сравнение методологий SDLC и Agile
Комментариев нет

Сравнение методологий SDLC и Agile

Методология SDLC (водопад)

Методология SDLC (или «водопад») для разработки программного обеспечения имеет жесткую структуру и обычно содержит следующие этапы, которые являются последовательными и проходят только в одном направлении (Balaji & Murugaiyan, 2012; Bourgeois et al., 2019):

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

SDLC предполагает точное знание того, что вы хотите, чтобы новое программное обеспечение выполняло, прежде чем приступить к процессу, и его практически невозможно изменить после его начала. Тестирование программной системы проводится только после того, как код полностью разработан, что делает невозможным обнаружение дополнительных ошибок на ранних этапах процесса (Balaji & Murugaiyan, 2012).

Гибкие методологии

Мышление Agile было создано как ответ на SDLC, и поэтому его можно определить по тому, чем оно отличается от SDLC. Гибкие методологии гораздо менее жестко структурированы, чем SDLC, и носят итеративный характер (в отличие от последовательных шагов SDLC). Они подчеркивают быстрое производство работающего программного обеспечения, которое можно постоянно улучшать (вместо затянувшегося процесса SDLC по созданию одной версии программного обеспечения) (Balaji & Murugaiyan, 2012; Bourgeois et al., 2019).

 

Фундаментальные различия между методологиями Agile и SDLC

 

Ценности AgileЦенности SDLC
Люди и взаимодействияПроцессы и инструменты
Рабочее программное обеспечениеОбширная документация
Сотрудничество с клиентомКонтрактные переговоры
Реагирование на измененияСледование плану

Когда реализовать каждый?

SDLC лучше всего использовать, когда:Agile лучше всего использовать, когда:
Проект очень большойЭто меньший проект
У вас есть четкое представление о том, что именно вы хотите, чтобы программное обеспечение выполнялоТребования к программному обеспечению часто меняются
Вам не нужно, чтобы проект был завершен быстроВам нужно программное обеспечение быстро

Недостатки/проблемы Agile (Баладжи и Муругайян, 2012; Хадждиаб и Талеб, 2011)

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

Баладжи, С. и Муругаян, М.С (2012). Waterfall, V-Model и Agile: сравнительное исследование SDLC. Международный журнал информационных технологий и управления бизнесом, 2(1), 26-29.

Бидл М., ван Беннекум А., Кокберн А., Каннингем В., Фаулер М., Хайсмит Дж., Хант А., Джеффрис Р., Керн Дж., Марик Б., Мартин Р.С., Швабер К., Сазерленд Дж., Томас Д (2001). Манифест гибкой разработки программного обеспечения.

Буржуа, Д.Т., Смит, Дж.Л., Ван, С., и Мортати, Дж (2019). Информационные системы для бизнеса и не только (2019). Фонд Сэйлора.

Хадждиаб, Х. и Талеб, А.С (2011). Внедрение гибкой разработки программного обеспечения: проблемы и проблемы. Международный журнал управления стоимостью и цепочками поставок, 2(3), 1–10. DOI: 10.5121/ijmvsc.2011.2301

 

SDLCвнедрениеводопадГибкие методологииитеративный подходметодология AgileМетодология РойсаобслуживаниепрограммированиепроектированиеПроектный подходРазработка ПОсистемный анализтестирование

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Заполните поле
Заполните поле
Пожалуйста, введите корректный адрес email.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

<