증분 접근법은 일련의 단계 번호를 사용 및 개발 진행의 선형 경로에 처음부터 끝까지 간다.
증분 개발은 설계, 구현, 테스트 / 검증, 유지 보수 단계에서 수행됩니다. 이것들은 하위 단계로 더 나눌 수 있지만 대부분의 증분 모델은 동일한 패턴을 따릅니다. 폭포 모델은 기존의 점진적 개발 방식이다.
반복 접근이 단계의 정해진 번호가없고, 오히려 개발 사이클에서 수행된다.
반복 개발은 개별 기능의 진행 상황을 추적하는 데 덜 관심이 있습니다. 대신, 작업 프로토 타입을 먼저 작성하고 모든주기마다 증분 개발 단계가 수행되는 개발주기에 기능을 추가하는 데 중점을 둡니다. 애자일 모델링 은 일반적인 반복 접근 방식입니다.
증분 모델은 원래 공장에서 사용 된 기존의 조립 라인 모델을 따르도록 개발되었습니다. 불행히도 소프트웨어 설계 및 개발은 실제 제품 제조와 거의 관련이 없습니다. 코드는 개발의 완제품이 아닌 청사진입니다. 좋은 디자인 선택은 종종 개발 과정에서 '발견'됩니다. 적절한 상황없이 개발자를 일련의 가정으로 잠그면 최선의 경우 설계가 불량하거나 최악의 경우 개발이 완전히 탈선 될 수 있습니다.
반복적 인 접근 방식은 이제 소프트웨어 개발의 자연스러운 진행 경로에 더 잘 맞기 때문에 일반적인 관행이되고 있습니다. 가정을 기반으로 '완벽한 디자인'을 추구하기 위해 많은 시간과 노력을 투자하는 대신 반복적 인 접근 방식은 사용자의 요구에 맞게 시작하고 발전하기에 '충분한'무언가를 만드는 것입니다.
tl; dr-증분 모델로 에세이를 작성하는 경우 한 번에 한 문장 씩 완성하기 위해 완벽하게 글을 쓰려고합니다. 반복 모델로 작성했다면, 대략적인 초안을 작성하고 일련의 개정 단계를 통해 개선하기 위해 노력할 것입니다.
최신 정보:
보다 실용적인 예에 맞게 '증분 접근법'에 대한 정의를 수정했습니다.
증분 접근법을 처리해야한다면 대부분의 계약이 수행되는 방식입니다 (특히 군대). 전형적인 'Waterfall Model'의 많은 미묘한 변형에도 불구하고 대부분 / 모두 실제로 동일한 방식으로 적용됩니다.
단계는 다음과 같습니다.
- 계약 상
- 예비 설계 검토
- 중요한 디자인 검토
- 사양 동결
- 개발
- 수비 / 통합
- 확인
- 신뢰성 테스트
PDR 및 CDR은 사양이 생성되고 수정되는 곳입니다. 사양이 완료되면 스코프 크리프를 방지하기 위해 사양을 동결 해야 합니다. 소프트웨어가 기존 시스템을 확장하는 데 사용되는 경우 통합이 발생합니다. 확인은 응용 프로그램이 사양과 일치하는지 확인하기위한 것입니다. 신뢰성은 장기간에 걸쳐 응용 프로그램이 신뢰할 수 있음을 입증하기위한 테스트로, 시스템이 특정 가동 시간 비율 (예 : 3 개월 동안 99 % 가동 시간)을 유지해야하는 SLA (서비스 수준 계약)와 유사하게 지정할 수 있습니다. ).
이 모델은 용지에 직접 지정하기는 쉽지만 생산하기 어려운 시스템에 적합합니다. 소프트웨어는 종이에 어느 정도의 세부적인 정도 (예 : UML)로 지정하기가 매우 어렵습니다. 관리 / 계약을 담당하는 대부분의 '비즈니스 유형'은 소프트웨어 개발과 관련하여 코드 자체 가 사양 이라는 것을 인식하지 못합니다 . 용지 사양은 종종 코드 자체만큼 작성하는 데 많은 시간 / 노력이 걸리며 실제로는 불완전하거나 열등한 것으로 판명됩니다.
증분 방식은 코드 자체를 사양으로 처리하여 낭비되는 시간 / 자원에 대한 시도입니다. 여러 수정 단계를 통해 용지 사양을 실행하는 대신 코드 자체가 여러 번의 수정주기를 거칩니다.