캐스케이드 모델 장치
Waterfall이라고도 하는 Waterfall 모델은 소프트웨어 개발에 대한 가장 잘 알려진 접근 방식 중 하나입니다. 모델의 저자는 Winston Royce입니다. 1970년에 그는 장단점을 자세히 설명하는 기사에서 자신의 혁신의 본질을 설명했습니다. 같은 곳에서 그는 이 모델을 반복 모델로 정제할 수 있는 방법을 설명했습니다. 처음에는 폭포수 모델에서 개발 단계가 다음 순서로 진행됩니다.
- 요구 사항의 정의 및 조정
- 프로젝트 승인
- 코딩;
- 소프트웨어 제품의 작동 버전 생성
- 테스트 및 디버깅
- 소프트웨어 설치;
- 지원하다.
폭포수 모델에 따르면 개발자의 작업 실행은 순차적으로 발생합니다. 우선, 완료할 목록의 형태로 소프트웨어 요구 사항을 결정하고 합의하는 작업이 완료되고 있습니다.
그 후 이전에 합의된 소프트웨어 요구 사항을 구현하는 방법을 설명하는 문서가 작성되는 결과로 프로젝트 생성 및 승인으로 전환됩니다.
설계가 완료되면 개발자가 구현을 맡습니다. 다음은 다양한 팀원이 작업한 프로젝트의 개별 부분을 통합하는 코드 병합입니다.
다음 단계는 제품을 테스트하고 디버깅하는 것입니다. 이전에 발견된 오류는 여기에서 수정됩니다.
마지막으로 프로그램이 설치되고 지원됩니다. 필요한 경우 기능을 변경하고 발견된 오류를 제거하는 작업이 포함됩니다.
캐스케이드 모델은 이전 작업이 완료된 후에만 엄격하게 순차적으로 다음 개발 단계로 이동할 수 있다고 가정합니다. 단계의 롤백 또는 불일치 가능성은 제공되지 않습니다.
장점과 단점
때때로 폭포수 모델은 유연성이 부족하다는 비판을 받습니다. 많은 사람들은 프로젝트 관리의 목표가 우세하고 기한, 비용 및 개발 품질이 훨씬 더 중요하기 때문에 그것을 좋아하지 않습니다.
그러나 대규모 프로젝트의 경우 프로젝트의 위험을 줄이고 작업의 투명성을 향상시키기 때문에 관리가 더 중요한 경우가 많습니다.
단점에도 불구하고 PMBOK 3차 버전은 공식적으로 "캐스케이드 모델" 방법론만 지정합니다. 반복 프로젝트 관리를 포함한 다른 옵션은 제공되지 않습니다.
폭포수 모델의 장점:
- 팀 개발을 제어하기가 더 쉽습니다. 고객은 프로그래머가 현재 작업 중인 내용을 잘 알고 있으므로 프로젝트의 기한과 예산을 변경할 수 있습니다.
- 개발 비용은 첫 번째 단계에서 승인됩니다. 구현의 모든 단계에 동의한 후 소프트웨어 제품이 지속적으로 작성됩니다.
- 숙련된 테스터는 필요하지 않습니다. 테스트 단계에서는 프로그램 설명서를 사용할 수 있습니다.
폭포수 모델의 단점:
- 테스트는 개발 완료 단계에서 시작하기 때문에 버그가 발견되면 초기 단계보다 수정하는 데 더 많은 비용이 듭니다. 결국 테스터는 개발자가 이미 코드 작성을 완료하고 카피라이터 - 문서 작성을 완료한 경우에만 오류를 발견합니다.
- 고객은 개발이 완료된 후 완제품에 대해 알게 됩니다. 따라서 제품이 거의 완벽하게 준비되었을 때만 제품을 평가할 수 있습니다. 결과가 마음에 들지 않으면 수정의 필요성으로 인해 프로젝트 예산 비용이 크게 증가합니다.
- 기술 문서가 많을수록 작업을 완료하는 데 더 오래 걸립니다. 그러한 문서화에는 더 많은 변경과 승인이 필요합니다.
"Waterfall"은 새로운 소프트웨어에 대한 요구 사항을 작성할 수 있는 기반이 되는 광범위한 문서가 이미 있는 의료 및 항공 우주 산업의 프로젝트에서 자주 사용됩니다.
폭포수 모델을 사용할 때 가장 중요한 것은 세부 요구 사항을 작성하는 것입니다. 테스트 중에 전체 프로젝트에 해로운 영향을 미치는 버그가 어딘가에 있다는 사실이 밝혀져서는 안 됩니다.