[PM] Waterfall Model

윤주호·2023년 3월 4일

[PM]

목록 보기

6/10

프로젝트와 클라이언트의 니즈와 주어진 상황에 따라, 적합한 프로젝트 방법론을 택할 수 있는 능력은 매우 중요하다고 할 수 있습니다. 소프트웨어마다 성향이 다르기 때문에, 모두 똑같은 개발 모형으로 설계하기란 쉽지 않습니다. 점점 상황이 다양해지는 시점에서, PM은 올바르고 명확한 방법론을 제시할 수 있어야 합니다. 이번 시간에는 다양한 소프트웨어 개발 모델 중 하나인 Waterfall 모델에 대해서 알아보도록 하겠습니다.

🌊 Waterfall 모델 (폭포수)

참고자료

한 번 떨어지면, 거슬러 올라갈 수 없는 폭포수처럼, 소프트웨어 개발 과정도 한 단계를 확실히 끝낸 후에 다음 단계로 넘어간다는 의미에서 붙여진 명칭입니다. Waterfall 모델은 가장 오래된 접근 방식 중 하나이며, 여전히 많은 상황에서 사용됩니다.

Waterfall 모델은 Linear Sequential Model로, 전 단계로 돌아가는 것이 허용되지 않는 선형 모델입니다. 그렇기 때문에 완전히 순차적으로 한 단계, 한 단계를 진행해야 하며, 다시 돌아갈 수 없기 때문에 해당 단계에서 많은 노력을 들여야 합니다.
또한, 각 단계가 끝날 때 산출물이 나오는 Document-Driven 방법입니다. + 최초로 개발 단계를 나눈 방법론.

📖 과정

1. Requirements / 산출물 : 요구분석서

시스템이나 소프트웨어에 대한 요구사항을 수집하고 분석합니다. + 요구사항을 분석하고 타당성을 검토합니다.

2. Design / 산출물 : 설계서

요구사항을 기반으로 시스템 아키텍처와 소프트웨어 디자인을 개발합니다.
이 단계에서는 1단계의 요구사항을 만족시킬 수 있는 제품을 설계합니다.

3. Implementation / 산출물 : 원시코드

설계된 시스템과 소프트웨어를 개발하고 코딩합니다. 시뮬레이션과 mock-up test, 각종 부품의 테스트를 거쳐 시제품을 만듭니다.

4. Verification / 산출물 : 실행파일 테스트 보고서

구현된 소프트웨어를 테스트하고 검증합니다. 시제품의 시험과 재설계를 반복하여 설계가 완성됩니다.

5. Maintenance

소프트웨어가 출시된 이후에도 유지보수를 수행하여 문제를 해결하고 새로운 요구사항을 수용합니다. 제품을 대량 생산할 수 있는 공장을 짓고 유지관리를 도울 수 있는 서비스 체계를 완성합니다.

☘️ 장점과 단점, 그리고 사용

PM은 Waterfall Model을 좋아합니다. Process Visibility가 좋으며, Seperation of Tasks 용이, 각 단계의 컨트롤, 모니터링 등 관리가 용이하기 때문입니다. 큰 단점은 "Blocking States"와 전 단계로 돌아가지 못한다는 것입니다.

장점 - 안정적인 가이드라인, 리스크 낮음

Waterfall 모델은 매우 정형화되어 있어, 각 단계에서 어떠한 일을 수행해야 하는지가 매우 명확하게 정의되어 있습니다.
이 모델은 각 단계별로 개발 작업을 할당하고 추적하기 쉽기 때문에 프로젝트 일정과 예산을 관리하기 쉽다는 장점이 있습니다.
제품을 고객에게 인도하는 (Delivery) 시점이 명확하다는 점이 있습니다. 이 것은 기능, 품질, 운영관리에 대한 요구조건이 분명하기 때문입니다.

단점 - 낮은 유연성, Blocking States

요구사항이나 디자인이 변경되었을 때 유연하게 대처하기 어렵다는 단점이 있습니다.
각 단계가 진행된 뒤에 설계에 변경이 생기면 큰 문제가 발생할 수 있습니다.
이전 단계로 돌아가서 수정을 하는 것이 불가능하기 때문에, 초기에 요구사항을 정확하게 수집해야 하며, 그렇지 않으면 개발 프로젝트의 일정과 예산에 부정적인 영향을 미칠 수 있습니다.
"Blocking States" : 해당 단계 이외에는 아무 단계도 수행하지 못하는 단점

사용 - 사전 예산 확정이 필요한 팀, 요구사항이 간단한 팀

Waterfall 모델은 간단한 소프트웨어 개발 프로젝트에는 적합하지만, 크고 복잡한 프로젝트에는 적합하지 않을 수 있습니다. 이런 경우에는 Agile 모델과 같은 유연한 접근 방식이 더 적합할 수 있습니다.

1. SW가 HW 시스템과 인터페이스해야 하는 임베디드 시스템.

– 하드웨어의 유연성이 없기 때문에 소프트웨어의 기능에 대한 결정을 구현될 때까지 미루는 것은 일반적으로 불가능하다.

2. SW 사양 및 설계에 대한 광범위한 안전 및 보안 분석이 필요한 시스템.

– 이러한 시스템에서는 이러한 분석이 가능하도록 사양 및 설계 문서가 완전해야 합니다. 규격 및 설계의 안전 관련 문제는 일반적으로 구현 단계에서 수정하는 데 매우 비용이 많이 필요합니다.

3. 여러 협력업체가 개발한 광범위한 시스템의 일부인 대형 SW 시스템.

– 시스템의 하드웨어는 유사한 모델을 사용하여 개발될 수 있으며, 기업들은 하드웨어와 소프트웨어에 공통된 모델을 사용하는 것이 더 쉽다는 것을 알게 됩니다. 여러 회사가 참여하는 경우에는 서로 다른 하위 시스템의 독립적인 개발을 허용하기 위해 완전한 규격이 필요할 수 있습니다.