[소프트웨어공학론] Process Activity evolution - Reducing the Cost

* Prototype

  

 - prototype방식은 Change avoidance유형의 진화 방법이다.
 - 보고 제품에 대한 느낌을 느낄 수 있는 시연 가능한 겉 껍데기를 만든다.
 - 프로토타입을 사용하는 때
  > 요구사항을 이끌어 낼때
  > UI를 만들 때
  > 모듈 실험시 다른 모듈에서 오는 값을 생성할 때
 - 프로토타입 사용시 장점
  > 사용성이 높아진다.
  > 고객과 밀접해 개발을 진행 할 수 있다. 
  > 개발에 대한 노력 비용이 줄어든다.
  > 디자인 퀄리트가 상승하며, 유지하기가 좋아진다.
  > 몰랐던 것에 대한 이해가 높아진다.
 - 프로토 타입을 만 들 수 있는 도구를 배울 필요가 있다.
 - Throw-away Prototypes
  > 프로토 타입은 버리려고 만드는 것이다.
  > 프로토 타입은 만들 프로그램의 기본이 되는 것이다.
  > 프로토 타입을 기본으로 하여 프로그램을 생성하면 다음과 같은 문제가 발생한다.
   a. 비기능적 요구사항을 만족 시키지 못한다.
   b. 프로토타입에 대한 문서는 존재하지 않는다.
   c. 구조가 안정적이지가 않다.
   d. 품질 검토가 되지 않았다.
 
* Incremental delivery

  

 
 - Incremental delivery방법은 change tolerance 방식이다.

 - 시스템을 한번에 개발하는 것이 아니라, increment 단위로 나눠서 개발하고, 전달하는 방식
 - 하나의 시스템은 Increment들의 합이다.

   ex)
   

 - Increment별로 개발 실시를 하여 변화에 대한 대응이 쉬워진다.
 - Increment는 사용자 요구사항의 우선순위를 나눈후, 우선순위가 높은 것부터 실행을 한다.
  > 개발단계의 Increment는 변경이 되면 안되고, 개발단계 이전의 Increment는 변경이 가능하다.
  > 개발이 진행됨에 따라 변경 범위가 줄어든다.
 - Increment Test Plan : Increment 개발과 통합과정.
  ex)
 

  > 우선순위가 높은 Increment는 하위 Increment가 개발 될때마다 테스트를 반복실행한다.
  > 이로 인해 신뢰도가 높아지게 된다. 
 - 장점
  > 고객이 빠르게 자신이 원하는 기능을 접할 수 있다.(Increment 우선순위에 의해서) 
  > 실체화된 Increment가 고객에게 Prototype으로 작용하여, 다른 Increment가 더 완벽해진다.
     (완벽해진다 = 고객이 원하는 방향으로 간다)
  > 시스템의 핵심을 먼저 개발(Increment 우선순위에 의해서)하므로, 프로젝트 실패율이 낮아진다.
     (프로젝트가 중간에 fail되도, fail순간에도 이미 핵심적인 기능은 개발 되 있을 것이다.) 
  > 우선순위가 높은 Increment부터 개발하고, 항상 통합 Test를 거치기 때문에 우선순위가 높은 Increment는
     테스트 수가 많아진다. 즉, 신뢰성이 높아진다.
 - 단점
  > Increment를 나누기가 힘들다. 각각의 Increment에는 중복되는 부분이 존재할 것이다.
  > 반복적인 개발로 요구사항도 점진적으로 일어난다. 이는 현재 존재하는 사업모델과 상의하다.
     (사업모델 = 모든 요구사항을 완벽하게 하면, 그때서 계약이 일어난다.)