프로세스 모형 |
개요 |
장점 |
단점 |
Waterfall Model |
- 순차적 모델(Sequential Model) 또는 고전적 생명주기 라고도 함 – 계획, 분석, 설계, 코딩(구현), 시험, 유지보수의 순으로 관리되는 모형으로 이 전 단계의 완벽한 작업 종류를 전제로 하는 모델임 |
– 가장 널리 많이 사용 – 단계별로 정형화된 접근방식 – 체계적인 문서화, 단계별 산출물 체크를 통한 프로젝트 진행의 명확화 – 기술적인 위험이 없고 유사한 프로젝트를 해 본 경험이 있어서 비교적 정확한 비용 예측과 – 일정계획 하에 프로젝트를 추진 할 경우 적합 |
– 문서 중심의 개발 접근 방식으로 인한 개발자의 문서화에 대한 부담과 가중 – 고객의 요구사항과 불일치 가능성 – 피드백 과정이 없어 변경이 어려움 – 완벽한 분석이 요구됨 – 대기 상태 발생으로 인한 일정 지연 가능성 |
Evolutionary Development Model |
– 반복적 개발 모델의 한 형태 – 시스템이 가지는 여러 구성요소의 핵심부분을 개발한 후 각 구성요소를 개선 발전시켜 나가는 방법 |
- 고객의 즉각적인 요구를 반영 |
- 프로세스가 보이지 않는다. - 계속적인 변경에 의하여 구조가 훼손되어 시스템이 종종 제대로 구조화되지 못한다. |
Prototyping Model |
- 반복적인 시제품 개발로 사용자 요구사항 또는 기술적 타당성을 확인 후 본격적으로 개발하는 모델 |
– 결과가 가시적이고 이해가 쉬워서 관리가 용이 – 사용자의 요구사항을 빠르게 수용가능 – 사용자의 요구사항을 확인 가능 – 정적인 요구명세 및 문서화 방법대신 실질적으로 수행되는 물리적 모형 확인 |
– 최종 소프트웨어 제품을 완성하기 전에 시제품을 완제품으로 발전하게 할 가능성 – 사용자의 과도한 요구 – 시제품 폐기의 비경제성 – 반복적인 시제품 개발의 종료 시기 문제 |
Spiral Model |
– 진화적인 소프트웨어 프로세스 모델로써, 시제품화 모델의 반복적인 개발이라는 특성과 폭포수 모델의 체계적인 관점지원 이라는 특성을 결합 – 대규모 시스템 개발에 대한 효율적인 접근으로 위험 분석 추가함 |
– 기존의 소프트웨어 생명주기 모형의 장점들의 선택적 수용을 허용 – 위험관리(Risk Management) 위주의 접근 방식 – 대규모 시스템 구축에 적합 |
– 모델 자체가 복잡하여 프로젝트 관리가 어렵고 고객을 설득시키기 어렵다 – 많은 고객을 상대로 하는 상업용 제품에 적용하기 힘들다. – 상대적으로 새로운 접근 방법이며 많이 사용되지 않아 충분한 검증을 거치지 못함 – 많은 위험 평가 전문가 필요 – 주된 위험이 발견되지 않을 때 문제 발생
|
Incremental Development Model |
– 폭포수 모델에 반복적 수행 개념을 결합 - 전반적인 프로젝트 요구사항을 리스크에 따라 우선순위를 정하여 ‘증분(increments)’으로 나누고, 이를 점진적으로 개발하여 순차적으로 기능의 일부를 릴리즈하는 개발 수명주기(life cycle) 모델 |
– 여러 개의 팀이 나누어 개발 하고자 할 때 유용 - 고객 서비스의 신속한 인도 - 사용자가 시스템 개발에 참여 |
- 완전한 시스템 명세서가 최종 산출물이 지정될 때까지 존재하지 않아 완전한 시스템 명세서가 시스템 개발 계약의 일부분인 경우 적용 불가능 |
Rapid Application Development Model |
– 짧은 개발주기 동안 소프트웨어를 개발하기 위한 모델 – 불필요한 활동 작업을 제거하여 프로세스를 간결화 함 |
- 짧은 기간 동안에 개발 가능 - 테스트 기간이 짧음 - 검증된 컴포넌트의 재사용 - 4세대 언어 또는 비주얼 툴 사용 |
- 대규모 프로젝트의 경우 충분한 인적자원 및 경영진의 지원요구 - 긴급한 활동을 위해 간부급의 위원회 조직 필요 - 기술적 위험이 크고 고성능이 요구되는 시스템에 부적합 |
V-Model |
- 일반 폭포수 모델의 한 사례로 시험 계획이 시스템 명세서와 설계로부터 유도되어야 한다는 것을 보여주는 모델 - 실행 작업과 그 작업결과의 검증에 초점을 둔 프로세스 모델 |
- 단계적 검증 절차를 갖기 때문에 Safety-critical System에 적용 가능 - 테스트 단계의 오류 발견 시 요구명세, 분석, 설계, 구현으로 되돌아 갈 수 있는 추적성 (Traceability)을 보장 |
- 시험 계획 수립에 시간과 비용이 많이 소모됨
|
'게임개발공부 > 프로그래밍의 의견들' 카테고리의 다른 글
사용자 스토리 & 유즈 케이스 (0) | 2014.07.30 |
---|---|
프로그래밍 설계상의 부채 (0) | 2014.07.29 |
밸런싱 관련 의견. (0) | 2014.01.11 |
의견 1 (0) | 2013.11.27 |