반복적 폭포수 모델

반복적 폭포수 모델

실제 소프트웨어 개발 프로젝트에서 전통적인 폭포수 모델은 사용하기 어렵다. 따라서 반복적 폭포수 모델은 실제 소프트웨어 개발 프로젝트에서 사용할 수 있도록 전통적인 폭포수 모델에 필요한 변경 사항을 통합한 것으로 생각할 수 있다. 소프트웨어 개발의 효율성을 높이기 위해 일부 변경이 이루어진다는 점을 제외하면 전통적인 폭포수 모델과 거의 같다.

반복적 폭포수 모델은 모든 단계에서 이전 단계까지의 피드백 경로를 제공하는데, 이는 전통적인 폭포수 모델과의 주요 차이점이다.

반복적 폭포수 모델에 의해 도입된 피드백 경로는 아래 그림과 같다.

이후 단계에서 오류가 감지되면 이러한 피드백 경로를 통해 특정 단계에서 프로그래머가 저지르는 오류를 수정할 수 있다. 피드백 경로를 사용하면 오류가 커밋되고 이러한 변경사항이 이후 단계에 반영되는 단계를 재작업할 수 있다. 그러나 타당성 분석 단계는 일단 프로젝트를 수행하면 프로젝트를 쉽게 포기하지 않기 때문에 단계에 대한 피드백 경로가 없다.

동일한 단계에서 오류가 감지되면 수정 하는 것이 좋다. 오류를 수정하는 데 필요한 노력과 시간을 줄일 수 있다.

 

반복적 폭포수 모델은 전통적인 폭포수 모델의 순차적 단계와 반복 설계의 유연성을 결합한 소프트웨어 개발 접근법이다. 프로젝트가 끝날 때까지 기다리지 않고 개발 프로세스의 각 단계에서 개선 및 변경을 수행할 수 있다.

실제 사례로 반복적 폭포수 모델은 소규모 기업을 위한 새로운 웹 사이트를 구축할 수 있다. 프로세스는 다음과 같을 수 있다

• 요구사항 수집: 발주자와 개발자가 만나 웹사이트의 목표와 요구사항을 논의하는 첫 단계다.
• 설계: 이 단계에서 개발자는 1단계에서 수집된 요구사항을 기반으로 웹사이트의 예비 설계를 작성한다.
• 구현: 이 단계에서, 개발자들은 2단계에서 만들어진 설계를 기반으로 웹사이트를 구축하기 시작한다.
• 테스트: 웹 사이트가 구축되면 요구 사항과 기능을 제대로 충족하는지 테스트한다.
• 배포: 그런 다음 웹사이트가 배포되고 사용자에게 라이브로 제공된다.
• 검토 및 개선: 웹사이트가 잠시 활성화된 후, 발주자와 개발자는 웹사이트의 성능을 검토하고 필요한 개선을 수행한다.

이 프로세스는 웹 사이트가 비즈니스의 요구와 목표를 충족할 때까지 반복된다. 각 반복은 이전 반복을 기반으로 하여 최종 제품이 완성될 때까지 지속적인 개선과 반복 한다.

반응형

반복 폭포수 모형의 장점

피드백 경로

– 전통적인 폭포수 모델에서는 피드백 경로가 없어 오류 수정을 위한 메커니즘이 없다. 그러나 한 단계에서 이전 단계까지의 반복적 폭포수 모델은 피드백 경로를 통해 커밋된 오류를 수정할 수 있으며 이러한 변경 사항은 이후 단계에 반영된다.

단순함

– 반복적 폭포수 모델은 이해하고 사용하기 매우 간단하다. 단순함이 가장 널리 사용되는 소프트웨어 개발 모델 중 하나인 이유이다.

비용 효율적

– 모형에서 계획이나 요구 사항을 변경하는 것은 매우 비용 효율적이다. 또한 민첩한 조직에 가장 적합합니다.

잘 구조화 되어 있다.

– 이 모델에서는 문서화에 소요되는 시간이 줄어들고 팀은 개발 및 설계에 더 많은 시간을 할애할 수 있다.

 

반복 폭포수 모형의 단점

변경된 요청사항을 통합하기가 어려움

- 반복적 폭포수 모델의 주요 단점은 개발 단계를 시작하기 전에 모든 요구 사항을 명확하게 명시해야 한다는 것이다. 고객은 일정 시간 후에 요구사항을 변경할 수 있지만 반복적인 워터폴 모델은 개발 단계가 시작된 후에 이루어진 변경 요청을 통합할 수 있는 범위를 남기지 않는다.

 

증분 제공은 지원되지 않는다

– 반복적 폭포수 모델에서 전체 소프트웨어는 고객에게 제공하기 전에 완전히 개발되고 테스트된다. 프로젝트 진행중에  고객에게 배포되지 않는다. 그래서, 고객들은 그 소프트웨어를 얻기 위해 오랜 시간을 기다려야 한다.

 

단계 중복은 지원되지 않는다

– 반복적 폭포수 모델은 이전 단계가 완료된 후 다음 단계가 시작될 수 있다고 가정하지만, 실제 프로젝트에서는 프로젝트를 완료하는 데 필요한 노력과 시간을 줄이기 위해 단계가 중복될 수 있다.

 

위험 관리 수단이 지원되지 않는다

– 프로젝트는 다양한 유형의 위험으로 인해 어려움을 겪을 수 있다. 그러나 반복적 폭포수 모델에는 위험 처리를 위한 메커니즘이 없다.

 

제한된 고객 상호 작용

– 고객 상호 작용은 요구사항 수집 시점에 프로젝트를 시작하고 소프트웨어 제공 시점에 프로젝트를 완료할 때 발생한다. 최종 개발된 소프트웨어가 고객의 실제 요구 사항과 다를 수 있기 때문에 고객과의 상호 작용이 적으면 많은 문제가 발생할 수 있다.