반복 및 증분 개발

Iterative and incremental development

반복증분 개발반복 설계 또는 반복 방법개발위한 증분 빌드 모델의 조합입니다.

이 용어의 사용은 소프트웨어 개발에서 시작되었으며, 대규모 개발 노력에 대해 반복적 용어[1] 증분적 용어의 오랜 조합이 널리 제안되어 왔다.예를 들어 1985년[2] DOD-STD-2167에서는 (섹션 4.1.2에서) "소프트웨어 개발 중에 여러 소프트웨어 개발 주기가 동시에 진행 중일 수 있습니다." 및 "이 프로세스는 '진화적 획득' 또는 '증강적 빌드' 접근법으로 설명할 수 있습니다."라고 언급하고 있습니다.소프트웨어에서 반복과 증가 간의 관계는 전체 소프트웨어 개발 프로세스에 의해 결정됩니다.

반복 개발 모델

개요

신속한 변화를 위한 프로젝트 관리에서 일반적인 반복 주기를 단순화한 버전

이 방법의 기본 개념은 반복 사이클(반복)을 통해 한 번에 더 작은 부분(증분)으로 시스템을 개발함으로써 소프트웨어 개발자가 시스템의 이전 부품 또는 버전을 개발하는 동안 학습한 내용을 활용할 수 있도록 하는 것입니다.학습은 시스템의 개발과 사용 모두에서 이루어집니다.여기서 프로세스의 가능한 주요 단계는 소프트웨어 요구사항의 서브셋의 단순한 구현에서 시작하여 전체 시스템이 구현될 때까지 진화하는 버전을 반복적으로 강화합니다.반복할 때마다 설계가 변경되고 새로운 기능 기능이 추가됩니다.[3]

절차 자체는 초기화 단계, 반복 단계 및 프로젝트 제어 목록으로 구성됩니다.초기화 단계에서는 시스템의 기본 버전이 생성됩니다.이 초기 구현의 목표는 사용자가 반응할 수 있는 제품을 만드는 것입니다.문제의 주요 측면을 샘플링하여 쉽게 이해하고 구현할 수 있는 솔루션을 제공해야 합니다.반복 프로세스를 안내하기 위해 수행해야 하는 모든 작업의 레코드를 포함하는 프로젝트 제어 목록이 생성됩니다.여기에는 구현해야 할 새로운 기능 및 기존 솔루션의 재설계 영역과 같은 항목이 포함됩니다.분석 단계 결과 지속적으로 관리 목록을 수정하고 있습니다.

반복에는 반복의 재설계와 구현이 포함되며, 단순하고 단순하며 모듈식이어야 하며, 해당 단계에서 또는 프로젝트 관리 [clarification needed]목록에 추가된 작업으로 재설계를 지원해야 합니다.설계 세부사항의 수준은 반복적 접근법에 의해 결정되지 않습니다.경량 반복 프로젝트에서는 코드가 시스템의 주요 문서 출처를 나타낼 수 있지만, 중요한 반복 프로젝트에서는 정식 소프트웨어 설계 문서를 사용할 수 있습니다.반복 분석은 사용자의 피드백과 이용 가능한 프로그램 분석 기능을 기반으로 합니다.여기에는 구조, 모듈화, 사용성, 신뢰성, 효율성 및 목표 달성의 분석이 포함됩니다.분석결과에 따라 프로젝트 관리목록을 수정합니다.

반복적인 개발

단계

증분 개발은 시스템 기능을 증분(비례)으로 슬라이스합니다.각 증가분에서는, 요건으로부터 도입에 이르기까지, 부문간의 작업을 통해서 기능의 슬라이스가 제공됩니다.통합 프로세스 그룹은 단계별로 증가/반복합니다. 즉, 시작, 상세, 구축 및 전환입니다.

  • Inception은 프로젝트 범위, 요건(기능적 및 비기능적) 및 리스크를 대략적으로 파악하지만 작업을 추정할 수 있을 만큼 상세하게 파악합니다.
  • 정교화는 주요 위험을 완화하고 비기능적 요구사항을 충족하는 작동 아키텍처를 제공합니다.
  • 구축은 기능 요구사항의 분석, 설계, 구현 및 테스트에서 생성된 즉시 가동 가능한 코드로 아키텍처를 점진적으로 채웁니다.
  • 이행은 시스템을 실제 가동 환경으로 전달합니다.

각 단계는 1개 이상의 반복으로 분할할 수 있습니다.이 반복은 보통 피처박스가 아닌 타임박스로 표시됩니다.설계자와 분석가는 개발자 및 테스터보다 한 번 더 먼저 작업하여 작업 제품의 밀린 작업을 계속합니다.

사용방법/이력

초기 사용의 많은 예는 크레이그 라먼과 빅터 바실리의 기사 "반복적이고 증분적인 발전: A Brief History"[4]에 나와 있으며, 가장 초기의 것 중 하나는 NASA의 1960년대 Project Mercury이다.

머큐리 엔지니어들 중 일부는 나중에 IBM에 새로운 부서를 설립했는데, "그곳에서는 1977년부터 1980년까지 개발된 NASA의 우주왕복선 소프트웨어, 즉 주요 항전 소프트웨어 시스템의 핵심이었습니다.연구팀은 IID를 31개월 동안 17회 연속으로 적용했으며, 1회당 평균 약 8주 동안 적용했습니다.이 회사가 폭포의 라이프 사이클을 회피한 동기는 소프트웨어 [4]개발 과정에서 셔틀 프로그램의 요건이 변경되었기 때문입니다.

미국 국방부와 같은 일부 조직은 MIL-STD-498 "확실히 진화적 획득과 IID를 장려하는" 것으로 시작하는 반복적인 방법론을 선호한다.

2000년에 발표된 DoD Instruction 5000.2에서는 IID에 대한 명확한 선호가 명시되어 있습니다.

완전한 기능을 실현하기 위해서는 진화적 접근과 단일 단계[물 건너가기]의 두 가지 접근법이 있습니다.진화적 접근법이 선호된다.… [이] 접근법에서는 사용자에게 제공되는 궁극적인 기능은 두 개 이상의 블록으로 나뉘며, 기능이 증가합니다.소프트웨어 개발은 소프트웨어 버전이 지속적으로 확장되는 반복적인 나선형 개발 프로세스를 따라야 하며, 이 프로세스는 이전 개발에서 얻은 학습에 기초해야 한다.단계별로 실행할 수도 있습니다.

최근의 DoDI 5000.02 개정에서는, 「스파이럴 개발」이 아니고, 소프트웨어 집약적인 개발/[5]조달 프로그램의 베이스로서 일반적인 어프로치를 제창하고 있습니다.또한 미국 국제개발청(USAID)은 프로그래밍 사이클에 대해 반복적이고 증분적인 개발 접근방식을 채택하여 협업, 학습 및 적응에 중점을 둔 프로젝트 관리 접근방식을 사용하여 국제 개발 프로젝트를 설계, 감시, 평가, 학습 및 적응합니다.프로그래밍을 [6]반복하고 적응시키는 전략에 대해 설명합니다.

폭포 개발과의 대비

소프트웨어 개발 프로젝트의 실패의 주된 원인은 모델의 선택이기 때문에 신중하게 [vague][7]해야 합니다.

를 들어 Waterpol 개발 패러다임은 다음 단계로 넘어가기 전에 각 분야의 프로젝트 전체 작업 산출물을 한 단계로 완성합니다.비즈니스 가치는 프로젝트의 맨 마지막에 한 번에 제공되지만, 반복적인 접근 방식에서는[clarification needed] 역추적이 가능합니다.두 가지 접근 방식을 비교하면 몇 가지 패턴이 [citation needed]나타나기 시작합니다.

  • 사용자 참여:폭포수 모델에서 사용자는 모델의 두 단계, 즉 요건과 승인 테스트와 사용자 교육 자료의 작성에 관여합니다.한편 증분 모델에서는 클라이언트는 각 단계에서 관여합니다.
  • 가변성:소프트웨어는 라이프 사이클의 빌드 단계가 완료된 후에만 사용자에게 전달되며 사용자 승인 테스트를 수행합니다.한편, 모든 인크리먼트는 사용자에게 전달되며, 사용자의 승인 후 개발자는 다음 모듈로 이동할 수 있습니다.
  • 인적 자원:증분 모델에서는 워터폴 모델에 비해 필요한 직원이 더 적습니다.
  • 시간 제한:운영 중인 제품은 몇 개월 후 제공되며 증분 모델에서는 몇 주 이내에 제품이 사용자에게 제공됩니다.
  • 프로젝트 크기:워터폴 모델은 소규모 프로젝트에는 적합하지 않지만 증분 모델은 대규모 프로젝트뿐만 아니라 소규모 프로젝트에도 적합합니다.

구현 가이드라인

소프트웨어 구현 및 분석을 촉진하는 가이드라인은 다음과 같습니다.[citation needed]

  • 수정사항의 설계, 코딩 및 테스트에 어려움이 있으면 재설계 또는 재코딩의 필요성을 알려야 한다.
  • 수정은 격리된 찾기 쉬운 모듈에 쉽게 들어갈 수 있어야 합니다.그렇지 않으면 재설계가 필요할 수 있습니다.
  • 표를 수정하는 것은 특히 쉬워야 합니다.표를 빠르고 쉽게 수정하지 못할 경우 재설계를 해야 합니다.
  • 반복이 진행됨에 따라 수정이 쉬워져야 합니다.그렇지 않으면 설계상의 결함이나 패치의 확산과 같은 기본적인 문제가 있습니다.
  • 패치는 보통 1~2회만 허용해야 합니다.구현 단계에서 재설계를 피하기 위해 패치가 필요할 수 있습니다.
  • 기존 구현을 자주 분석하여 프로젝트 목표에 얼마나 부합하는지 판단해야 합니다.
  • 프로그램 분석 설비는 부분 구현 분석에 도움이 될 수 있는 경우 항상 사용해야 한다.
  • 현재 구현에 결함이 있는지 사용자 반응을 요청하고 분석해야 합니다.

하드웨어 및 임베디드 시스템에서 사용

소프트웨어 산업에서 반복 및 증분 개발이라는 용어가 시작되었지만, 많은 하드웨어임베디드 소프트웨어 개발 노력이 반복 및 증분 기술을 사용하고 있습니다.

이러한 예는 여러 산업에서 볼 수 있습니다.이러한 사고방식의 변화에 의해 최근 상당한 영향을 받고 있는 부문은 우주발사 산업으로, 우주발사를 추구하는 민간기업의 형성에 의해 보다 빠르고 광범위한 기술혁신이 초래된 실질적인 새로운 경쟁력이 작용하고 있다.SpaceX와[8] Rocket [9]Lab과 같은 이 회사들은 모두 지난 10년 동안 상업적인 궤도 발사 서비스를 제공하고 있는데, 이는 10년[10] 전에는 6개국만이 해왔던 것이다.기술 개발 접근 방식, 가격 책정 및 서비스 제공에 대한 새로운 혁신(예: 2016년 이후부터 사용 가능한) 부스터 스테이지를 통해 우주로 날아갈 수 있는 기능을 포함)[11][8]으로 인해 우주 액세스 비용이 더욱 절감됩니다.

SpaceX는 우주 산업에 반복적인 디자인 관행을 도입하기 위한 노력을 분명히 했으며 우주선, 발사체, 전자 및 항전 장치, 운영 비행 하드웨어 운용에 [12]이 기술을 사용하고 있습니다.

업계의 변화가 시작되면서 다른 출시 경쟁사들도 정부 기관과의 장기적인 개발 관행을 바꾸기 시작했습니다.예를 들어, 미국의 대형 론치 서비스 프로바이더인 United Launch Alliance(ULA)는 향후 [13]10년 동안 부분적으로 재사용 가능하고 훨씬 저렴한 론치 시스템을 구축하기 위해 반복적이고 증분적인 접근방식을 사용하여 론치 비즈니스를 재구성하는 10년 간의 프로젝트를 시작했습니다.

「 」를 참조해 주세요.

메모들

  1. ^ Larman, Craig (June 2003). "Iterative and Incremental Development: A Brief History" (PDF). Computer. 36 (6): 47–56. doi:10.1109/MC.2003.1204375. ISSN 0018-9162. S2CID 9240477. We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ...'
  2. ^ DOD-STD-2167 Defense Systems 소프트웨어 개발 ( 1985년 6월 4일) everyspec.com
  3. ^ Farcic, Viktor (January 21, 2014). "Software Development Models: Iterative and Incremental Development". Technology Conversations.
  4. ^ a b 반복증분 개발: A Brief History, Craig Larman and Victor Basili, IEEE Computer, 2003년 6월
  5. ^ Kendall, Frank; Gilmore, J. Michael; Halvorsen, Terry (2017-02-02). "Operation of the Defense Acquisition System" (PDF). DoD Issuances. Under Secretary of Defense for Acquisition, Technology, and Logistics. pp. 12–14. Archived from the original (PDF) on 2017-08-09. Retrieved 2017-08-09.
  6. ^ USAID. "ADS Chapter 201 Program Cycle Operation Policy."2017년 4월 19일 취득
  7. ^ "Difference between Waterfall and Incremental Model". May 19, 2016.[영구 데드링크]
  8. ^ a b Belfiore, Michael (9 December 2013). "The Rocketeer". Foreign Policy. Retrieved 11 November 2018.
  9. ^ "Exclusive Inside Look at Rocket Lab's Previously-secret new Mega Factory!". Everyday Astronaut. 11 October 2018. Retrieved 11 November 2018.
  10. ^ Clark, Stephen (28 September 2008). "Sweet Success at Last for Falcon 1 Rocket". Spaceflight Now. Retrieved 11 November 2018. the first privately developed liquid-fueled rocket to successfully reach orbit.
  11. ^ Berger, Eric (2018-06-25). "Russia's Proton rocket, which predates Apollo, will finally stop flying Technical problems, rise of SpaceX are contributing factors". arsTechica. Retrieved 2018-06-26. the rapid rise of low-cost alternatives such as SpaceX's Falcon 9 rocket, have caused the number of Proton launches in a given year to dwindle from eight or so to just one or two.
  12. ^ Fernholz, Tim (21 October 2014). "What it took for Elon Musk's SpaceX to disrupt Boeing, leapfrog NASA, and become a serious space company". Quartz. Retrieved 11 November 2018. But SpaceX always thought of itself as a tech firm, and its clashes with NASA often took a form computer developers—or anyone familiar with the troubled roll-out of healthcare.gov—would recognize as generational. SpaceX followed an iterative design process, continually improving prototypes in response to testing. Traditional product management calls for a robust plan executed to completion, a recipe for cost overruns.
  13. ^ Gruss, Mike (2015-04-24). "Evolution of a Plan : ULA Execs Spell Out Logic Behind Vulcan Design Choices". Space News. Retrieved 25 April 2015. ULA’s April 13 announcement that it would develop a rocket dubbed Vulcan using an incremental approach whose first iteration essentially is an Atlas 5 outfitted with a new first stage.

레퍼런스