1. Process
소프트웨어 제품을 생산하기 위해 적용되는 과정과 활동 그리고 산출물들
1-1.Plan-driven process
각 프로세스마다 필요한 활동을 미리 계획하고, 각 프로세스를 이 계획을 바탕으로 평가하는 것
1-2.Agile process
고객의 요구사항을 꾸준히 반영하는 개발 방법론
→Plan-driven process와 Agile process는 조직마다 섞여 있는 형태로 존재한다.
2. Software Process Models_Plan-driven process
2-1. Code-and-Fix Model
![](https://static.wixstatic.com/media/40a56b_7da421debd164b5cb8e5b82a63114f8f~mv2.png/v1/fill/w_448,h_325,al_c,q_85,enc_auto/40a56b_7da421debd164b5cb8e5b82a63114f8f~mv2.png)
소프트웨어 구현 전의 사전작업(계획, 설계 등)을 전혀 거치지 않고, 바로 구현하는 것이다.
일반적으로 간단한 과제를 하는 것과 비슷하다. 간단한 과제를 할 때 설계도를 세세히 그리지 않고 일단 코드를 작성한다.
위와 같은 process model의 단점은 유지보수가 힘들다는 점이다.
2-2. Waterfall Model(Linear Model)
![](https://static.wixstatic.com/media/40a56b_128491d56fcb4a8aa186cce1b0b7a406~mv2.png/v1/fill/w_612,h_497,al_c,q_85,enc_auto/40a56b_128491d56fcb4a8aa186cce1b0b7a406~mv2.png)
Waterfall process model은 매 개발단계(요구사항 정의, 요구사항 분석, 설계, 구현 및 테스팅, 유지보수)를 충실하게 지킨다. 매 개발단계를 충실하게 지킨다는 것의 의미는 전 개발단계가 완료되어야 그 다음 개발단계로 넘어갈 수 있음을 뜻한다.
Waterfall process model은 이미 구현단계로 들어갔다면 고객의 요구사항 변경을 빠르게 반영하기 힘들다. Waterfall process model은 하드웨어 개발단계에서 유래하였기 때문이다. 하지만 하드웨어와 소프트웨어의 특성은 다르다. 소프트웨어는 하드웨어와 달리 고정된 형태가 아니라 지속적으로 개선되어야 하는 특성을 가진다. 또한, Waterfall 모델은 많은 문서를 요구한다. 고객입장에서는 Prototype이 없기 때문에 완성된 소프트웨어를 확인하기까지 오랜시간이 걸린다.
이와 같은 이유로 소프트웨어 개발시에 Waterfall process model은 대부분 적절하지 않다. 하지만 많은 process model이 waterfall 모델을 기반으로 만들어졌기 때문에 적절한 이해가 필요하다.
2-3. Prototype Model
![](https://static.wixstatic.com/media/40a56b_884f44b2d3e04668b80a65bffedf7a4d~mv2.png/v1/fill/w_980,h_455,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/40a56b_884f44b2d3e04668b80a65bffedf7a4d~mv2.png)
고객은 Prototype을 통해 완성된 제품은 아니지만 유사한 제품을 미리 확인할 수 있다. 고객은 Prototype을 기반으로 하여 요구사항 변화를 요청할 수 있고, 개발자는 이를 반영하여 소프트웨어 제품을 완성한다.
Prototype 종류
-Throw-away 시제품: 일단 시제품을 만들어보는 것으로, 시스템의 요구사항을 잘 이해하지 못했을 때, 요구사항에 대한 이해를 초점에 두는 것이다.
-Evolutionary prototyping: 사용자와 함께 요구사항을 지속적으로 찾아가면서 명확한 부분부터 개발을 점진적으로 진행하는 것이다.
2-4. Spiral Model
![](https://static.wixstatic.com/media/40a56b_b4aa869675fd4cf2a469fe03262ac471~mv2.png/v1/fill/w_980,h_604,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/40a56b_b4aa869675fd4cf2a469fe03262ac471~mv2.png)
시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델이다. 이를 통해 실패의 위험을 줄이고 테스트에 용이하게 만들면서 피드백이 가능하다.
Sprial model은 지속적인 테스팅, 평가에 의한 개발 방식을 통해 사용자의 요구가 충분히 반영된 제품을 만들 수 있다. 하지만 반복적 개발과 테스팅을 통해 테스팅 시간을 비롯해 개발 시간이 증가할 수 있다.
2-5. RAD Model, Rapid Application Development Model
![](https://static.wixstatic.com/media/40a56b_fd449771366e4a178af5f812a0e7c1e5~mv2.png/v1/fill/w_980,h_644,al_c,q_90,usm_0.66_1.00_0.01,enc_auto/40a56b_fd449771366e4a178af5f812a0e7c1e5~mv2.png)
모든 경우에 RAD model을 적용할 수 있는 것은 아니다.
*RAD model 적용 가능
가. 요구사항을 명확히 정의되어야 한다.
나. 프로젝트의 범위가 제한적이어야 한다.
다. 충분히 능력 있는 개발인력이 필요하다.
*RAD model 적용 불가
가. 고도의 모듈화 작업이 되어 있지 않은 경우
나. component간의 많은 상호작용을 필요로 한다.
다. 기술적 위험이 요구되는 상황(새로운 기술 도입 등)
일반적으로 RAD model에서는 소프트웨어의 재사용이 이루어진다. 이미 개발된 모델을 많이 사용하므로 빨리 구축이 가능한 것인데, 따라서 새로운 기술 도입과 같은 기술적 위험성이 존재하는 경우 RAD model을 적용할 수 없다. 일반적으로 RAD model은 비슷하고 반복적인 작업의 반복이 이루어지는 대형 기업에서 많이 사용된다.
2-6. Formal Method
Formal Method는 사람마다 다른 해석을 하는 것을 허용하지 않는다. UML과 같은 Informal language의 경우에는 사람마다 다른 해석을 내릴 수 있다. 이를 위해 Formal method에서는 주로 수학적인 기호(기법)을 사용해서 명세서를 작성한다.
Formal Method는 주로 높은 안정성을 요구하는 어플리케이션 개발 시 이용된다. 예를 들어, 우주선 소프트웨어 개발과 같이 높은 안정성이 요구되는 경우에 사용된다. Formal Method는정확한 해석을 제공하지만 사용하기도 어렵고 이해하기도 힘들다. 이처럼 개발 비용이 많이 들지만 확실한 소프트웨어를 개발할 수 있다는 점에서 특수한 분야에서 많이 사용된다.
Comentarios