Сравнительный анализ методологий разработки ПО Agile и Waterfall



Цель данной статьи — произвести сравнительный анализ методологий разработки программного обеспечения на примере Agile и WaterFall. Формирование критериев сравнения. Выявление преимуществ и недостатков.

Ключевые слова: agile, waterfall, гибкая методология разработки, жизненный цикл ПО, подходы к разработке ПО.

Введение

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

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

Подход waterfall

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

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

Создание программного обеспечения включает следующие этапы:

− Обсуждение идеи создания концепта

− Анализ и планирование требований

− дизайн

− Кодирование и реализация

− Тестирование

− Выпуск продукта

− Поддержка и сопровождение

Рис. 1. Этапы разработки ПО Waterfall

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

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

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

− Результат известен. Клиент с самого начала знает, как работает программа и как она будет выглядеть. Следовательно, также известны стоимость и сроки проекта. Такая уверенность всегда приятна, потому что можно заранее спланировать бюджет и даты выпуска.

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

Недостатки:

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

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

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

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

− Заключительное тестирование. Тщательное тестирование проводится только в конце. Если обнаруживаются серьезные ошибки, весь проект обречен.

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

Подход Agile

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

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

− Планирование — разделить концепцию на маленькие части

− Анализ требований — многочисленные встречи с клиентами и менеджерами проектов для сбора подробной информации

− Проектирование — создать дизайн по последним требованиям.

− Кодирование — для создания рабочего продукта

− Тестирование — для проверки готового программного обеспечения на наличие ошибок.

− Запуск — доставка готового продукта покупателям

Рис. 2. Agile-подход

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

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

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

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

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

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

− Участие клиента. Большая разница между Agile и Waterfall заключается в возможности для клиентов высказать свое мнение во время разработки, увидеть промежуточные результаты и повлиять на конечный продукт. Это способствует установлению доверительных отношений между клиентами и подрядчиками.

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

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

Недостатки:

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

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

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

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

Наиболее подходящие ситуации для использования этой методики:

− Клиенту нужны быстрые результаты

− Нет четкого видения конечного продукта

− Программное обеспечение разрабатывается для быстро меняющейся отрасли, и требуются постоянные улучшения.

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

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

Сравнительный анализ методологий

Для сравнения методологий разработки программного обеспечения были выявлены следующие критерии:

1) Развитие — критерий, отвечающий за протекания процесса на любом этапе разработки ПО. Варианты: жесткое/гибкое.

2) Процесс — критерий, описывающий подход разработки ПО. Варианты: последовательный/итеративный.

3) Первоначальный план — критерий, отвечающий за описание последовательности действий в реализации бизнес-процессов. Варианты: точное/приблизительное.

4) Документация — критерий, отвечающий за ведение документации. Варианты: строгое/не строгое.

5) Отношение к изменениям — возможность внесения изменений на любом этапе разработки. Варианты: возможны/невозможны.

6) Тестирование — критерий, отвечающий за проверку функционала на конкретном этапе. Варианты: в конце разработки/после каждого спринта.

7) Команды — тип команды. Варианты: отдельные/кросс-функциональные

8) Клиент — критерий, отвечающий за участие клиента в разработке. Варианты: участвует/ не участвует.

9) Рабочий софт — критерий, отвечающий за периодичности поставки рабочего продукта (части продукта). Варианты: в конце/после каждого спринта.

Сравнительная таблица Waterfall и Agile представлена ниже.

	Водопад	Agile
Развитие	Жесткий	Гибкий
Процесс	Последовательный	Итеративный
Первоначальный план	Точный	Приблизительный
Документация	Строгое	Не строгое
Отношение к изменениям	Возможны	Не возможны
Тестирование	Только конечный продукт	После каждого спринта
Команды	Отдельный	Кросс-функциональные
Клиент	Не участвует	Участвует
Рабочий софт	В конце	После каждого спринта

Заключение

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

Литература:

1. Ajah, I. A., & Ugah, J. O. Comparative Analysis of Software Development Methodologies. International Journal of Advanced Research in Computer Science and Software Engineering, 3(6), 2013.
2. Balaji, S., & Murugaiyan, M. S. WATEERFALLVs V-MODEL Vs AGILE: A COMPARATIVE STUDY ON SDLC. International Journal of Information Technology and Business Management, 2(1), 2012.
3. Boehm B., “A spiral model of software development and enhancement,” IEEE Computers, vol. 21, no. 5, pp. 61–72, 1988.
4. Budi, D. S., Siswa, T. A. Y., & Abijono, H. Analisis Pemilihan Penerapan Proyek Metodologi Pengembangan Rekayasa Perangkat Lunak. TEKNIKA, 5(1), 2016.
5. Klopper, R., Gruner, S., & Kourie, D. Assessment of a framework to compare software development methodologies. Paper presented at the The 2007 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists on IT Research in Developing Countries, 2007.
6. Laudon, K. C., & Laudon, J. P. Management Information Systems Managing The Digital Firm (13 ed.). Essex: Pearson Education Limited, 2014.
7. Munassar, N. M. A., & Govardhan, A. A Comparison Between Five Models Of Software Engineering. IJCSI International Journal of Computer Science Issues, 7(5), 2010.
8. Pressman, R. S. Software Engineering: A Practitioner's. Approach: McGraw-Hill Higher Education, 2001.
9. Rainer, R. K., Turban, E., & Potter, R. E. Introduction to information systems (2nd ed.): J. Wiley, 2009.
10. Sommerville, I.. Software Engineering (7th Edition): Pearson Addison Wesley, 2004.