폭포수(Waterfall) 모델 VS 애자일(Agile) 모델

1. 폭포수

배경

소프트웨어 위기와 소프트웨어 공학

소프트웨어가 겪고 있는 복잡도, 고객의 기대치와 요구사항 변경 등의 원인으로 인해 개발된 소프트웨어에서 발생하는 예산 초과, 일정 지연, 낮은 품질, 고객 요구사항 불만족, 프로젝트의 관리 불가능과 유지보수를 위한 코딩 어려움의 결과를 나타내는 현상을 소프트웨어 위기라 표현한다.
소프트웨어 위기가 인식되자, 소프트웨어를 체계적으로 개발하려는 움직임에 따라 다양한 소프트웨어 개발 기법이 나타나기 시작하였으며, 그 중 하나로 폭포수 모델이 제안되었다.

Royce의 폭포수 모델

1970년 Royce에 의해 제안된 폭포수 모델은 개발 과정을 분명하게 나타내는 수단으로써 프로젝트를 관리하는데 효과적이었다. 한 단계를 완전히 끝내고 다음 단계로 넘어가는 방법으로 소프트웨어 생명주기의 각 단계를 정의하였으며, 이해하기 쉽고, 사용하기도 쉽다. 현재는 ISO/IEC/IEEE 12207:2017 표준의 소프트웨어 생명주기 모델의 하나로 자리잡고 있다.

---

모델

검증 후 앞 단계로 회귀하는 것이 가능하지만, 일단 한 단계가 진행되면 이전 단계로 되돌아가는 데에 어려움이 많은 것이 특징이다. 폭포수 모델은 계획 → 분석 → 설계 → 구현 → 테스트* → 유지보수 의 단계로 이루어져 있다.

* 테스트는 ▲코딩 직후 최소 단위인 모듈이나 컴포넌트를 점검하는 단위 테스트, ▲개발된 모듈 및 컴포넌트를 결합하여 발생하는 상호작용을 점검하는 통합 테스트, ▲컴퓨터 시스템에서 완벽하게 수행되는지를 점검하는 시스템 테스트, ▲시스템이 요구사항을 만족하는가를 테스트하는 인수 테스트로 이루어져 있다.

---

장단점

폭포수 모델은 다음과 같은 장점이 있다. ▲각 단계의 문서와 구조적 설계로 새로운 개발자가 팀에 합류하였을 때 쉽게 적응할 수 있다. ▲결과를 예측하기 쉽고 평가 프로세스가 분명하다. ▲각 단계는 순차적으로 한 번에 하나씩 수행된다. ▲요구사항이 분명한 적은 규모의 프로젝트에 적합하다.

폭포수 모델은 다음과 같은 단점이 있다. ▲요구사항 분석 단계 이후에 발생하는 추가 요구사항은 프로젝트 진행에 부정적인 영향을 준다. ▲한 단계에서 확인 된 문제가 그 단계에서 완전하게 해결되지 않는 경우도 있다. ▲고객의 추가 요구사항은 추가 비용이 발생할 수 있다. ▲테스트 단계에서 문제가 발견되었을 때 설계 단계로 되돌아가기가 어렵다. ▲리스크가 높고 불확실성이 많다.

---

대안

점증형 모델

점증형 모델은 초기 개발과 여러 단계의 증분 개발로 구성된다. 초기 개발 단계에 초기 계획, 요구사항 분석, 아키텍처 정의 등 초기 활동을 수행하고, 연속되는 증분 개발 단계에서 설계, 구현 및 검증 등의 활동을 수행한다. 필요 시 일부 기능이나 요구사항들을 다음 증분에서 개발하는 것으로 조정할 수 있으며, 최종 증분 개발이 완료되면 전체 목표가 모두 구현된다.이러한 방식을 통해 부정확한 비용 혹은 일정에 유연하게 대응할 수 있다.

나선형 모델

나선형 모델은 점증형 모델의 변형이며 개발 위험을 평가하여 개발 위험이 가장 높은 기능을 초기 증분에 개발하는 전략을 활용한다. 따라서 개발 말기에 갑자기 증가하는 비용 등의 리스크를 예방할 수 있다.

반복적 모델

반복적 모델은 초기 계획을 한 번 수립한 후 개발 프로세스를 반복적으로 수행한다. 이 프로세스에는 프로토타입 개발, 시험, 분석, 개선 활동 들을 포함한다. 생명주기 프로세스를 반복적으로 수행하며, 시스템 기능은 개발 우선순위에 따라 프로세스 반복을 통해 개발한다.

진화적 모델

진화적 모델은 요구사항에 대한 정보가 부족하거나 불완전한 경우에 적용한다. 초기 인도품에서 사용자 필요를 충족시키지 못한 기능이 있으면, 이를 보완하여 다음 인도 시점에 인도한다.

---

2. 애자일

배경

2001년 계획을 수립하고 계획에 따라 개발과 문서작업을 수행하는 중량 개발 방법론의 단점을 극복하기 위해 나타난 경량 개발 방법론의 핵심가치가 후에 애자일 방법론의 모태가 된다. 경량 개발 방법론의 핵심가치를 기준으로 작성된 선언문(Manifesto for Agile software development, Beck et al. 2001)이 작성되며 애자일 방법론이 시작되었다.

Manifesto for Agile software development

1. 개인과 상호작용이 프로세스와 도구보다 우선한다.
2. 작동하는 소프트웨어가 포괄적인 문서보다 우선한다.
3. 고객과의 협력이 계약 조정보다 우선한다.
4. 변경에 대한 대응이 계획의 이행보다 우선한다.

Twelve Principles of Agile Software

1. 가치 있는 소프트웨어를 초기에 그리고 지속적으로 제공하여 고객을 만족시키는 것을 최우선으로 한다.
2. 개발 후반부에서도 요구사항의 변경을 환영하라. 애자일 프로세스는 변화를 통해 고객의 경쟁력이 향상되도록 지원한다.
3. 2주에서 2개월까지의 주기로, 가능하면 짧은 주기로 동작하는 소프트웨어를 전달하라.
4. 사업 담당자와 개발자는 프로젝트 내내 함께 일해야 한다.
5. 동기 부여된 사람들로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 제공하고, 그들이 작업을 완수할 것이라는 것을 믿어라.
6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화이다.
7. 동작하는 소프트웨어가 진행률을 측정하는 가장 좋은 척도이다.
8. 애자일 프로세스는 지속 가능한 개발을 촉진한다. 개발자와 사용자들은 계속해서 일정한 속도를 유지할 수 있어야 한다.
9. 기술적 탁월함과 좋은 설계를 위한 지속적인 관심은 유연성을 좋게 한다.
10. 단순함이 중요하다.
11. 최상의 구조, 요구사항, 설계는 자기 주도형 조직에서 나타난다.
12. 주기적으로 팀은 더 효과적인 행동으로 조율하고 조정한다.

---

애자일 방법론의 종류

소프트웨어 산업에 애자일 방법론의 보급과 확산을 위하여 애자일 방법론에 대한 많은 연구가 이루어지고 있으며, 여러 종류가 있지만 개발 실무 방법론 중심의 익스트림 프로그래밍(XP)과 프로젝트 관리 방법론인 스크럼(Scrum), 기능주도 개발 방법론, 애자일 통합 프로세스 등이 대표적인 방법론들이다.

스크럼(Scrum)

스크럼 방법론은 프로세스를 반복적이고 점진적으로 수행하는 것을 기본으로 하고 있다. 개발 작업의 반복 주기가 약 4주간 지속되는 동안 매일 약 15분간 한 일, 할 일, 장애요인 등에 대해 공유하기 위한 "일일 스크럼 미팅"을 수행하며 점진적으로 프로세스를 진행해나가는 방법론이다.

익스트림 프로그래밍(XP)

익스트림 프로그래밍은 요구사항이 모호하고 빠르게 변화하는 상황에서 소프트웨어 개발을 하는 중소 규모의 팀을 위한 경량 개발 방법론이라고 정의한다. XP 방법론은 '필수적인 사항만 수행한다'는 것을 강조한다. 설계를 단순화하여 짧은 주기로 결과물을 배포하고, 짝을 이루어 개발하며, 항상 단위테스트를 수행하여 오류를 줄이고 효율을 향상시키는 방법론이다.

---

3. 폭포수 VS 애자일

구분	폭포수	애자일
기본가정	시스템을 전체적으로 정의, 예측 가능하고 세부계획에 따라 개발	지속적인 설계 개선과 테스트, 빠른 피드백, 변경을 통해 개발
관리유형	명령과 통제	리더십과 협력
지식관리	분명함	암묵적
의사소통	공식적	비공식적
조직구조	관료적, 대규모 조직	유연하고 참여적 조직, 중소 규모의 조직
품질관리	계획 수립이 어려움, 엄격한 통제, 어렵고 오래 걸리는 테스트	지속적 통제, 요구사항, 설계, 해결, 테스트
사용자 요구사항	수행 전에 상세하게 정의	상호작용에 따라 정의
재시작비용	높음	낮음
개발 방향	고정됨	쉽게 변경 가능
테스트	개발이 완료된 후	매 반복 주기
고객의 참여	낮음	높음
구조	현재, 미래의 요구사항 설계	현재의 요구사항 설계
주 목적	높은 안정성	빠른 가치 생성

 

 

 

참고자료

1. KS X ISO/IEC/IEEE 12207:2017, 시스템 및 소프트웨어 엔지니어링 - 소프트웨어 생명주기 프로세스
2. 김정수, "SW 개발 프로젝트에서 프로젝트 팀의 애자일 준비도가 프로젝트 성과에 미치는 영향", 국내박사학위논문 한양대학교 대학원, 2016
3. Manifesto for Agile software development, https://agilemanifesto.org/iso/ko/manifesto.html