[ISSUE] 소프트웨어 개발 방법론, WaterFall 방법론

1. 소프트웨어 개발 방법론이란?

소프트웨어 개발 방법론이란, 소프트웨어를 개발하는데 있어 필요한 프로그래밍 개발 과정들을 정리하고 표준화하여 프로그래머들이 프로그래밍 개발과정에서 각 개인이 개발과정에서 일관성을 유지하여 프로젝트의 분야별 프로그래머들간의 효과적인 협업이 이루어 질 수 있도록 돕는 방법론을 말한다.

소프트웨어 개발 방법론에서 가장 중요한 내용은 프로그래머들간의 효과적인 협업이라고 볼 수 있으며 WaterFall 방법론, Agile 방법론, Scrum 방법론, DevOps 방법론 등이 있다.

이 포스팅은 대기업(Samsung, 현대모비스)에서 아직도 많이 쓰이고 있는 WaterFall 방법론을 말할 예정이다.

2. WaterFall 방법론?

WaterFall 방법론은 폭포수방법론이라고도 부르며 말 그대로 폭포가 위에서 밑으로 흐르는 것을 빗대어 표현하였으며 각 단계별 순차적인 진행을 강조하는 방법론이다.

< WaterFall 방법론 구조도 >

요구사항 분석(Requirements)은 사용자들의 요구사항을 듣고 정확히 기능적, 비기능적 요구 사항을 도출합니다. 요구사항 분석을 완료하면 다음 단계인 설계로 넘어갑니다.

---

설계(Design)는 요구사항 명세를 준수한 설계를 말한다. WaterFall 방법론의 가장 중요한 점이 순차적인 진행이기 때문이다. 여기서 '요구사항 명세를 준수한' 이라는 문장에 대해서 쉽게 말하자면

발주 업체에서 원하는 기능이 3개였는데 소프트웨어 계발 업체가 1개의 기능을 구현하지 못했다면 요구사항에 준수하지 못하였기 때문에 애초 초기설계부터 잘못 되었기 때문.

즉 요구사항 명세에 따라 소프트웨어의 전체 구조와 구조간의 관계, 상세 알고리즘을 설계하게 되고 전체적인 구조를 설계하는 것을 기본설계, 상세 알고리즘을 설계하는 것을 상세 설계 라고 합니다.

---

구현(Implement)는 앞의 단계인 요구사항 분석, 설계과정의 단계를 모두 완벽하게 진행 되었을 경우 진행되는데 말 그대로 소프트웨어 프로그래밍에 들어가는 작업입니다.

구현단계에서는 일반적인 앞에서말한 요구사항과 설계과정에 적절한 코드를 작성을 하는게 기본단계입니다.

또한 이러한 코딩부분만을 구현이라고 하지않고 Unit Test, Code Inspection 등 코드에 대한 검증 부분도 포함하여 진행되는데 여기서 Unit Test는 한국말로 단위테스트라고 하며 코딩부분에서 작성된 소스 코드들이 적절한 모듈과 연결되어 정확히 작동하는지 확인 하는 부분입니다. 쉽게 말해서 과학실험에서 사용하는 오차를 줄이기 위한 실험과 비슷하다고 볼 수 있습니다. 또한 Code Inspection은 코드 검증이며 소프트웨어가 자잘한 디버그 또는 에러 등에 대해서 문제가 없는지 확인하는 과정이고 쉽게말해 디버깅을 하는 단계라고 볼 수 있습니다.

 

---

확인(verification)은 간단히 말해서 테스트를 한다는 말이다. 앞부분에서 말했던 구현 부분의 Code Inspection, Unit Test 부분과 비슷한 맥락으로 볼 수 있다. 하지만 세부적인 부분에서 차이가 있습니다.

확인부분에서는 여러가지 테스트를 같이 진행하게 되는데 그것은 아래와 같습니다.

1. 완성된 모듈들 간의 상호작용을 위한 통합 테스트

2. 전체 시스템 동작에 대한 검증을 위한 시스템 테스트

3. 사용자의 입장을 통하여 확인하는 인수 테스트

통합 테스트 같은 경우 앞에서 말한 Unit Test들의 집합체로 볼 수 있습니다.

모듈 1에 대한 테스트만을 확인하는 것이 Unit Test라면 모듈 1 ~ 10까지의 상호작용이 제대로 이루어 지는지에 대한 테스트가 통합테스트입니다.

시스템 테스트 같은 경우 시스템들이 제대로 작동하는가? 보다 성능에 대한 테스트가 위주가 됩니다. (WaterFall 방법론은 단계적 진행을 원칙으로 하기에 모든 것이 제대로 진행되었을 때 다음 단계로 넘어간다는 것을 알아두면 당연한 말이라고 생각이 됩니다.)  시스템의 속도, 오차에 대한 범위확인, 추가적인 문제 확인 등입니다.

인수 테스트 같은 경우 앞에서 말한 사용자의 요구사항이 모두 구현되었는가?에 대한 테스트이며 사용자가 요구한 기능들이 정확하게 목적에 맞게 실행되는가에 대한 과정입니다. 

---

유지보수(Maintenance)는 사실상 앞에서 말한 확인과정까지 모든 것이 문제없이 종료될 경우 사용자에게 배포가 되어 직접적으로 사용자드이 소프트웨어를 사용하게 된 후의 과정입니다. 소프트웨어가 사용자들에게 배포된 후 발생되는 오류와 서비스적인 문제에 대하여 소프트웨어 개발사는 일정기간의 보증기간을 가지는데 그때 이루어 지는 것이 유지보수이다. 

유지보수 기간에 개발자가 알지 못했던 오류(error)가 발생하면 다시 수정하여 사용자들에게 추가적으로 서비스를 제공해야하며 이는 유지보수기간이 끝나기 전까지 이루어져야하며 지속적인 사용자와의 관계가 유지된다면 다음 버젼이나 다른 대체 소프트웨어가 개발되고 기존의 소프트웨어가 파기될때까지 유효합니다.

쉽게 이야기하면 물건의 품질보증기간에 이루어져야할 여러가지 서비스들을 의미합니다.

3. WaterFall 방법론의 장단점

WaterFall 방법론은 최근에 Agile 방법론과 같은 다른 방법론보다 꽤 오랜 기간동안 쓰여져 왔으며 상대적으로 고전적인 방법론으로 소개됩니다.

아직까지 국내의 대기업에서도 채택되어 사용 중 일만큼 큰 장점들이 존재하지만 단점도 존재한다.

---

장점으로는 아래의 것들을 예로 들 수 있다.

(1) 역사가 오래된 만큼 많은 사람들이 사용하고 단점 보완에 대한 예시들이 풍부하다.

(2) 수직적인 방법론이므로 각각의 과정에 대한 이해가 용이하다.

(3) 결과물에 대한 관리가 편하다.

단점으로는 아래의 것들을 예로 들 수 있다. 

(1) 각 단계별 수직적인 관계를 가지므로 각 단계를 병행할 수가 없다.

(2) 단계별 발생한 오류들에 대한 즉각적인 피드백을 하기 어렵다.(결과물을 바로 받을 수 없기 때문)

(3) 개발이 완료되기 전까지 사용자의 의견을 100% 담아내기 힘들다.

---

주로 이러한 구조는 하드웨어와 소프트웨어를 모두 다루는 기업에서 자주 사용하는 방법이며 많은 프로젝트를 기획하는 큰 기업 일수록 이러한 방법론을 적용하기 용이합니다.

4. WaterFall 방법론을 적용이 유리한 경우

위의 내용을 잘 종합해보면 WaterFall 방법론이 정말 완벽한 방법론이라고 말하기 어렵다. 하지만 이러한 방법론을 적용하기에 적절한 환경이 조성되어 장점을 부각할 수 있다면 단순하고 편한 방법론이 될 수 있다.

아래는 WaterFall 방법론이 적용되기 유리한 환경에 대한 설명이다.

(1) 요구사항이 단순하며 쉽게 변경이 가능한가?

(2) 프로젝트 진행자들의 특별분야의 전문성이 확실한가?

(3) 프로젝트의 결과물의 구조와 내용이 명확한가?

등이다.