Сравнение методологий 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
