계획단계에서 개발 프로세스 모델을 정해야한다. 개발 프로세스 모델이란 개발 조직의 구성을 나타낸다. 한마디로 팀이 어떻게 구성되는지를 나타낸 것이라고 할 수 있다. 이러한 모델 선택의 중요성은 각 프로세스 모델에 따라 들어가는 비용은 크게 차이가 나며 상황에 따라 유불리가 존재하기 때문에 팀에 주어진 여러 요소들을 종합적으로 판단한뒤 알맞는 모델을 선택하는것이 좋다. 예를 들면 게임에서 공격형 진형과 수비형 진형같은것이 있는 것처럼 말이다.

개발 프로세스 모델을 선택할 때 고려해야될 요소는 다음과 같다.

• 요구명확성 : 시스템이 어떤 기능을 할지
• 기술숙련도 : 시스템에 적용할 기술이 어려운지 아닌지 또는 작업하는 코더가 프로그래밍을 잘하는지 아닌지.
• 시스템 복잡도 : 시스템이 복잡한지 아닌지
• 시스템 신뢰도 : 언제나 어떤 상황에서도 지정한 기능을 사용하면 바로 그 기능이 동작하는지 못하는지
• 개발 일정 : 개발 일정이 짧은지
• 일정 투명성 : 스케쥴이 정상적으로 짜여졌는지 아닌지

시스템 개발 환경	개발 생명주기 모형
	폭포수	병렬 개발	프로토타이핑	쓰고 버리는 프로토 타이핑	단계적 개발	애자일
불명확한 요구	하	하	상	상	중	상
생소한 기술	하	하	하	상	중	하
복잡한 시스템	중	중	하	상	중	하
신뢰도 높은 시스템	중	중	하	상	중	중
짧은 일정	하	중	상	중	상	상
일정 투명성	하	하	상	중	상	중

위는 프로세스 모델 대표적인 6가지를 정리한 것이다. 이제 자세히 알아보자.

1. 짜보고 고치기

이 모델은 프로그래밍 초보나 규모가 매우 작은 작업에서 통요되는 방법이다. 그러나 조금만 시스템이 복잡하거나 스폰서의 요구가 확실지 않은면 사용되기 어려운 방법이다. 그때 그때 코딩하고 버그가 있으면 고치는 방법은 개발 팀의 멤버들 사이에 무엇을 하여야 하는지 어떻게 완성시킬 것인가가 불투명하기 때문이다.

2. 폭포수 모형

이 모델은 한 단계의 작업이 끝난 뒤 다음 단계로 넘어가는 순차적인 개발 프로세스를 가진다. 각 단계가 끝날때마다 발표를 하여 시스템 개발 상태를 점검할 수 있다.
때문에 폭포수 모형의 모든 작업은 문서 중심으로 이루어진다.
그러나 오늘날 비즈니스 환경을 급변하고 있기 때문에 고전적인 폭포수 모델은 다른 모델에 비해 불리한 경우가 많다.

-장점 : 프로그래밍이 시작되기 이전에 요구에 대해 충분히 파악하고 문서화가 가능 프로젝트가 진행되면서 스폰서의 요구 변경을 최소화 할 수 있음(개발자 입장에서는 좋음)

-단점 : 프로그래밍 이전 모든 설계가 완벽히 명시되어야함 다른 모델에 비해 시간이 많이 걸림

3. 프로토타이핑 모형


프로토타이핑 모형은 프로토 타입 즉 시험제품을 빠르게 만들어 보는 것을 목표로하는 모델링이다. 여기서 중요한것은 시험제품을 빨리 만들어 보기 위해 분석 설계 구현의 단계가 병렬적으로 수행된다는 점이다. 빠르게 시험제품을 완성하여 스폰서나 사용자에게 보여주어 수정 사항을 피드백받아 다시 고치는 것을 주로하며 이렇게 반복하다보면 언젠간 스폰서나 사용자가 만족할 만한 시스템이 완성되는 것이다.


장점 : 스폰서나 사용자가 빠르게 체험해 볼 수 있음 스폰서나 사용자의 수정 사항이나 추가적인 요구 사항을 빠르게 피드백할 수 있음 스폰서나 사용자가 시스템 개발팀이 열심히 일하고 있다는 확실을 줄 수 있음

단점 : 대단히 복잡한 시스템을 설계할 때는 애초부터 뭘 구현해야 할지 갈피를 잡는데 오래걸림 사용자나 스폰서의 요구를 중점으로 수정 및 보완을 하다보니 전반적인 시스템의 신뢰도(안정성)이 부실함

4. 쓰고 버리는 프로토타이핑 모형


프로토타이핑 모형에서 진화한 이 모형은 시험제품을 기반으로 최종 시스템을 구축하지 않고 단지 사용자의 피드백을 받기 위하여 즉 프로토타입은 사용자나 스폰서의 의견이나 수정사항 듣기용으로만 사용하며 사용하지 않는 모델이다. 따라서 결과물은 별도로 작업하고 있으며 프로토 타입과는 많이 다를 수가 있다. 주로 신기술에 대해서 프로토 타입에 적용하고 사용자나 스폰서에게 보여주어 반응을 살피는 쪽으로 많이 쓰인다.

5. 단계적 모형

단계적 개발 모형은 전체 시스템을 여러 개의 버전으로 나누고 각 버전을 순차적으로 개발하는 모형이다. 분석에서 전체 시스템의 컨셉을 정하고 프로젝트 팀과 사용자들이 요구를 여러 개의 버전으로 나눈다. 마치 덜만든 게임을 내놓는것과 같다 게임을 내놓은 후에 그 게임을 계속 개발하면서 나중에 패치로 새 버전을 푸는 것이다. 따라서 중요한 기능은 첫번째 버전을 내놓을때 대부분 포함하는것이 좋다.


장점 : 빠른 기간 내에 사용자나 스폰서가 시스템을 사용할 수 있음 스폰서나 사용자의 수정 사항이나 추가적인 요구 사항을 빠르게 피드백할 수 있음


단점 : 사용자나 스폰서는 미완성된 시스템으로 작업을 해야됨