실제 소프트웨어 개발 프로젝트에서 고전적인 폭포 모델은 사용하기가 어렵습니다. 따라서 반복적 인 폭포 모델은 실제 소프트웨어 개발 프로젝트에서 사용할 수 있도록 클래식 폭포 모델에 필요한 변경 사항을 통합하는 것으로 생각할 수 있습니다. 소프트웨어 개발의 효율성을 높이기 위해 일부 변경 사항을 제외하고는 고전적인 폭포 모델과 거의 동일합니다.
반복 폭포 모델은 모든 단계에서 이전 단계까지의 피드백 경로를 제공합니다.
반복 폭포 모델에 의해 도입 된 피드백 경로는 아래 그림에 나와 있습니다.
이후 단계에서 오류가 감지되면 이러한 피드백 경로를 통해 일부 단계에서 프로그래머가 저지른 오류를 수정할 수 있습니다. 피드백 경로를 사용하면 오류가 커밋되고 이러한 변경 사항이 이후 단계에 반영되는 단계를 다시 작업할 수 있습니다. 프로젝트가 촬영 된 후,쉽게 프로젝트를 포기하지 않기 때문에,타당성 조사–하지만,단계에 대한 피드백 경로가 없습니다.
커밋된 동일한 단계에서 오류를 감지하는 것이 좋습니다. 이 오류를 수정하는 데 필요한 노력과 시간을 줄일 수 있습니다.
오류의 위상 억제:가능한 한 약속 지점에 가까운 오류를 감지하는 원리를 오류의 위상 억제라고 합니다.
반복 폭포 모델의 장점
- 피드백 경로: 클래식 폭포 모델에서는 피드백 경로가 없으므로 오류 정정을 위한 메커니즘이 없습니다. 그러나 반복 폭포 모델 피드백 경로에서 이전 단계로 한 단계에서 커밋 된 오류를 수정할 수 있으며 이러한 변경 사항은 이후 단계에 반영됩니다.
- 단순:반복 폭포 모델은 이해하고 사용하기 매우 간단합니다. 그것이 가장 널리 사용되는 소프트웨어 개발 모델 중 하나 인 이유입니다.
반복 폭포 모델의 단점
- 변경 요청을 통합하기 어려운: 반복 폭포 모델의 주요 단점은 개발 단계를 시작하기 전에 모든 요구 사항을 명확하게 명시해야한다는 것입니다. 고객은 일정 시간이 지나면 요구 사항을 변경할 수 있지만 반복 폭포 모델은 개발 단계가 시작된 후 만들어진 변경 요청을 통합 할 수있는 범위를 벗어나지 않습니다.
- 증분 전달 지원되지 않음:반복 폭포 모델에서 전체 소프트웨어는 고객에게 전달하기 전에 완전히 개발 및 테스트됩니다. 중간 배달에 대한 범위는 없습니다. 따라서 고객은 소프트웨어를 얻기 위해 오래 기다려야합니다.
- 단계의 중복 지원되지 않음:반복 폭포 모델은 한 단계가 이전 단계의 완료 후 시작할 수 있다고 가정하지만,실제 프로젝트에서 단계는 프로젝트를 완료하는 데 필요한 노력과 시간을 줄이기 위해 중복 될 수 있습니다.
- 위험 처리 지원되지 않음:프로젝트는 다양한 유형의 위험을 겪을 수 있습니다. 그러나 반복적 인 폭포 모델에는 위험 처리 메커니즘이 없습니다.
- 제한된 고객 상호 작용: 고객 상호 작용은 요구 사항 수집 시 프로젝트 시작 시 및 소프트웨어 제공 시 프로젝트 완료 시 발생합니다. 최종적으로 개발 된 소프트웨어는 고객의 실제 요구 사항과 다를 수 있으므로 고객과의 이러한 상호 작용이 줄어들면 많은 문제가 발생할 수 있습니다.
문서 태그:
