
정답요구사항 변경이 많은 경우에 적합하다는 설명은 틀렸습니다. 폭포수 모델은 요구사항이 명확하고 변경이 적을 때 적합합니다.
핵심 개념
폭포수(Waterfall) 모델의 특징과 한계
폭포수 모델은 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 순서로 각 단계를 순차적으로 진행하는 가장 고전적인 소프트웨어 개발 프로세스 모델입니다. 이전 단계가 완전히 끝나고 산출물이 확정되어야 다음 단계로 넘어가는 선형·하향식 방식이라, 단계마다 명확한 문서 산출물이 남고 진행 상황 관리가 쉽다는 장점이 있습니다. 반면 실행 가능한 소프트웨어는 개발 후반부인 구현 단계에 가서야 나오므로 고객이 결과물을 늦게 확인하게 되고, 앞 단계로 되돌아가는 비용이 매우 크다는 것이 결정적 한계입니다. 따라서 요구사항이 초기에 명확하고 변경이 적은 프로젝트에 적합하며, 변경이 잦은 프로젝트에는 프로토타이핑·나선형·애자일 같은 반복적 모델이 더 적합합니다.
선지별 해설
①폭포수 모델은 각 단계를 완료한 뒤 다음 단계로 진행하는 순차적 모델이므로, 요구사항 분석을 완료한 후에야 설계 작업을 시작할 수 있습니다.
②구현 단계가 후반부에 배치되어 있어 실행 가능한 소프트웨어는 개발 후반부에야 산출됩니다. 이것이 고객 피드백이 늦어지는 폭포수 모델의 대표적 단점입니다.
③단계마다 요구사항 명세서, 설계서, 테스트 계획서 등 정형화된 산출물을 만들고 검토 후 다음 단계로 넘어가므로 체계적인 문서화가 가능합니다.
④폭포수 모델은 앞 단계로 되돌아가는 비용이 매우 커서 변경에 취약합니다. 요구사항 변경이 많은 경우에는 프로토타이핑·나선형·애자일 같은 반복적 모델이 적합하므로 이 선지가 정답입니다.

정답사용자 환경에서의 인수 테스트 수행은 구체화 단계가 아니라 전이(transition) 단계의 활동입니다.
핵심 개념
통합 프로세스(UP)의 4단계와 구체화(elaboration) 단계
통합 프로세스(Unified Process)는 유스케이스 주도, 아키텍처 중심, 반복적·점진적 개발을 특징으로 하는 프로세스 모델로 도입(inception) → 구체화(elaboration) → 구축(construction) → 전이(transition)의 4단계로 구성됩니다. 도입 단계는 프로젝트 범위와 타당성을 개략적으로 정하고, 구체화 단계는 요구사항 대부분을 상세화하고 실행 가능한 아키텍처 기준선(baseline)을 확정하며 프로젝트의 중대한 위험 요소를 식별·해결하는 단계입니다. 구축 단계에서 나머지 컴포넌트를 본격적으로 개발·통합하고, 전이 단계에서 베타 테스트와 사용자 환경에서의 인수 테스트, 사용자 교육, 실 배포를 수행합니다. 즉 '인수 테스트'는 구체화가 아니라 전이 단계의 활동이라는 점이 핵심입니다.
선지별 해설
①사용자 환경에서의 인수 테스트, 베타 테스트, 사용자 교육, 실제 배포는 마지막 전이(transition) 단계의 활동입니다. 구체화 단계 활동이 아니므로 이 선지가 정답입니다.
②구체화 단계의 가장 핵심적인 목표가 실행 가능한 아키텍처 기준선을 확정하는 것이므로, 아키텍처 설계는 대표적인 구체화 단계 활동입니다.
③도입 단계에서 개략적으로 잡은 요구사항을 구체화 단계에서 대부분 상세 분석하여 유스케이스 모델을 완성하므로 맞는 설명입니다.
④구체화 단계는 아키텍처를 확정하면서 기술적으로 중대한 위험 요소를 미리 식별하고 해결하여 이후 단계의 불확실성을 줄이는 것을 목표로 합니다.