소프트웨어 개발 프로세스의 전통적인 모델

프로세스 모델은 개발 단계를 단순화하여 표현한 것이다.

지금까지 소프트웨어 개발에 사용된

여러 가지 프로세스 모델이 있지만

전통적인 방법 모델에 대해 먼저 알아보자.

 

[전통적 모델 6가지]

- 폭포수 모델

- 프로토타이핑 모델

- 점증적 모델과 진화적 모델

- 나선형 모델

- 컴포넌트 기반 모델

- Unified Process

---

1. 폭포수 모델 (Waterfall Model)

전통적 모델 중에서도 가장 오래되고, 널리 사용된 프로세스다.
계획 단계에서 운영 및 유지보수까지 각 프로세스를

모두 위에서부터 순서대로 수행하기 때문에 이전 작업으로

돌아가는 재작업이 없는 것이 특징이다.

 

장점

• 단계가 명확하고 이해하기 쉬움
• 대규모 프로젝트에 적합

단점

• 문제 발견이 늦으면 재작업 비용 큼
• 유연성 부족

V-모델

• 폭포수 모델의 확장형 모델
• 각 개발 단계에 대응하는 테스트 단계 존재
• 단위 → 통합 → 시스템 → 인수 테스트

---

2. 프로토타이핑 모델 (Prototyping Model)

요구 사항에 대한 피드백을 받기 위해 시스템을

실험적으로 만들어 사용자에게 보여주고 평가하는 방법이다.

시제품(Prototype) 제작 → 사용자 피드백 → 요구 반영

과정을 거치며, 사용자의 요구를 정확히 파악하고

빠지거나 잘못 이해하는 것을 방지할 수 있다.

 

장점

• 요구사항 명확화 가능
• 고객 만족도 상승

단점

• 제작 비용 증가 가능
• 프로토타입을 실제 제품으로 오해할 수 있음

---

3. 점증적 모델 (Incremental Model)
& 진화적 모델 (Evolutionary Model)

여러 번의 사이클에 나누어 개발하는 방법으로 시스템을

개발하기 위한 사이클(요구 분석→설계→구현→테스트)을 반복하여

기능을 점증적으로 추가하거나 시스템을 진화시키는 모델이다.

하지만 두 모델은 접근 방식에 차이가 있다.

 

[점증적 모델]

초기 요구를 모두 정의한 뒤 기능을 여러 개의
하위 시스템(릴리즈)으로 나눠 기능을 점차 추가하며 개발

 

예)
릴리즈1 – 입력 기능
릴리즈2 – 편집 기능
릴리즈3 – 서식 기능 추가

 

[진화적 모델]

요구사항이 처음부터 명확하지 않을 때 적합

전체 개발 사이클을 반복하면서 기능을 개선하고 진화시키는 방식

변수 많은 프로젝트, 새로운 기술 적용 시 유리

 

공통 장점

• 사용자 요구를 빠르게 반영
• 시장 출시를 앞당기고 문제를 조기에 발견 가능
• 여러 버전을 내면서 기능 개선이 용이

공통 단점

• 버전 증가 시 관리 복잡
• 구조가 점점 복잡해질 위험
• 끝없이 반복되어 일정 지연 가능

---

4. 나선형 모델 (Spiral Model)

전통적 모델 중에서도 위험 관리(Risk Analysis) 를

최우선으로 고려한 방식으로 폭포수 모델과

프로토타이핑 모델을 결합해 만든 확장 모델이다.

 

개발을 위한 계획 및 요구 분석 후에 위험 요소와

차선책에 대하여 검토하는 단계가 있다는 점이 특징이다.

 

특징

• 계획 → 위험 분석 → 개발 → 평가의 반복
• 각 반복이 나선을 그리듯 확대되며 완성도 증가

장점

• 위험을 조기에 식별 및 감소
• 복잡한 대규모 시스템에 적합
• 변경사항에 유연함

단점

• 리스크 분석 실패 시 프로젝트 전체 위험 증가
• 비용이 많이 들고 관리 난이도 높음

---

5. 컴포넌트 기반 모델 (Component-Based Model)

소프트웨어를 재사용 가능한 컴포넌트(부품) 조립 방식으로 개발하는 모델.

실제 자동차 제조처럼, 미리 만들어진 부품을

(상용 소프트웨어, 객체, 웹 서비스 등) 조합해 시스템을 만든다.

상용 소프트웨어(COTS)
- 독립된 응용 시스템이지만 특정 환경에 융합될 수 있음

객체
- 컴포넌트 프레임워크에 통합될 수 있는 객체지향 패러다임의 독립 단위

웹 서비스
- 서비스 표준으로 원격 호출 가능

 

장점

• 개발 비용과 리스크 감소
• 재사용된 컴포넌트 덕분에 신뢰도 상승
• 배포 및 설치 속도 향상

단점

• 컴포넌트 특성에 따라 사용자 요구가 완전히 반영되지 않을 수 있음
• 사용된 컴포넌트의 버전 및 진화를 계속 관리해야 함

---

6. Unified Process (UP)

객체지향 모델링을 표준화한 OMG의 통합 프로세스 모델.

여러 개의 사이클로 구성되며 각 사이클은

시스템을 출시함으로 종결된다. 

 

하나의 반복(iteration) 과정은 4단계로 구성되어 있고

각 단계는 중요한 점검 일정(milestone)으로 종료된다.

 

UP의 4단계

- 도입 inception

- 정련 elaboration

- 구축 construction

- 전환 transition

1) 도입(Inception)
1-2회 정도 반복, 유스케이스 개략 작성, 프로젝트 계획 수립

 

2) 정련(Elaboration)
여러 번의 반복 과정을 거침, 핵심 유스케이스 상세화, 아키텍처 설계

대부분의 유스케이스가 작성되며, UML 다이어그램을 그린다.

3) 구축(Construction)
나머지 기능 구현 및 통합하며

시스템을 목표 환경에 점증적으로 설치한다.

4) 전환(Transition)
시스템을 배치하는 작업 실행

베타 테스트, 사용자 교육, 결함 수정 및 개선

유스케이스란?
어떤 시스템이 개발될 것인지를 나타내기 위하여
비즈니스 프로세스를 모델링한 것이라 할 수 있다
예)
현금인출기를 위한 유스케이스는 입금, 출금, 잔고조회 등이다.

 

장점

• 문서화 및 교육이 잘 되어 있음
• 요구 변경에 유연하게 대응 가능
• 반복적 통합으로 리스크 감소

단점

• 구조가 복잡해 적용 난이도가 높음
• 협업 방식에 대한 세부 가이드 부족
• 잘못 적용하면 혼란스러운 개발 방식이 될 위험

---