[Software Engineering] Waterfall Model | 폭포수 모델

Waterfall Model

 

폭포수 모델

 

 

 

- Plan-Driven Model에 속하는 모델로, Specification과 Development 과정들이 서로 명확히 분리되어 있는 형태이다.

- 이전 단계가 완전히 끝나야 다음 단계로 넘어갈 수 있다. (Each step is sequential)

 

* 본 포스트는 Software Process Model (소프트웨어 프로세스 모델) (URL)의 하위 문서이다.

[Software Engineering] Software Process Model | 소프트웨어 프로세스 모델

---

Waterfall Model Phases (폭포수 모델의 단계)

 

 

Phases	Description
1. Requirements Definition (= Specification)	- 요구사항을 정의한다.
2. System and Software Design	- 요구사항을 바탕으로 소프트웨어를 설계한다.   (Function, Class, Component의 Prototype을 정의한다.)
3.Implementation and Unit Testing	- 설계를 바탕으로 구현한다.   (Prototype으로 정의된 Function, Class, Component의   내용을 구현한다.) - 구현 후 개발자 본인이 유닛 테스트를 수행한다.
4. Integration and System Testing	- 개발된 Function, Class, Component를 통합하여   전체 시스템을 구성한다. - 통합 후 시스템 테스트를 수행한다.
5. Operation and Maintenance	- 시스템을 작동시키고, 유지보수한다.   (5개의 Phase 중 가장 오랜 시간이 소요된다.)

 

---

Advantages of Waterfall Model (폭포수 모델의 장점)

 

Advantages	Description
각 Phase에서의 Documentation 으로 인해 시스템 구조 파악이 쉬워 Maintenance하기에 용이하다.	- 각 Phase에서 Document들이 생성되기 때문에   개발 도중에 개발 인원이 교체되어도   인수인계가 쉽게 이루어질 수 있다.

 

---

Drawback of Waterfall Model (폭포수 모델의 한계)

 

Drawbacks	Description
개발 도중에 바뀌는 Specification에 대처하기 어렵다.	- 프로젝트 규모가 크거나, 관련기술이 변하면   Requirement는 수정될 수 밖에 없는데,   폭포수 모델은 이전 Phase로 회귀할 수 없기 때문에   이러한 변화에 유연하게 대처하기 어렵다.

 

---

Appropriate Field of Water fall Model (폭포수 모델을 적용하기에 적합한 경우)

 

Appropriate Field	Description
Requirement가 명확한 경우	- Specification의 수정이 적거나,   예측 가능한 범위 내에서의 수정이 이루어 질 것이기   때문에 폭포수 모델을 적용하기에 적합하다.
Requirement가 수정되는 경우가 극히 제한적인 경우	- Specification의 수정이 적거나,   예측 가능한 범위 내에서의 수정이 이루어 질 것이기   때문에 폭포수 모델을 적용하기에 적합하다.
대규모 시스템을 개발하는데, 개발팀이 각기 다른 공간에서 작업하는 경우	- 처음부터 끝까지 모든 계획을 수립해놓기 때문에   개발자들이 서로 모여 작업해야 할 이유가 적다.
Critical System을 개발하는 경우	- Critical System의 경우 Specification과 Design에   매우 신중해야 하며   Poorly Structure는 허용되지 않는다.

 

---

Reference: Software Engineering 10th Edition
(Ian Sommerville 저, Pearson, 2016)