나선 모형

Spiral model
나선 모형(Boehm, 1988).많은 오해가 이 널리 퍼진 다이어그램의 지나친 단순화에서 비롯됩니다(이 [1]다이어그램에는 오류가 있습니다).
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

나선형 모델은 위험 주도의 소프트웨어 개발 프로세스 모델입니다.나선 모형은 주어진 프로젝트의 고유한 위험 패턴을 기반으로 팀이 증분, 폭포 또는 진화적 프로토타이핑과 같은 하나 이상의 프로세스 모델의 요소를 채택하도록 안내합니다.

역사

이 모델은 Barry Boehm에 의해 1986년 논문 "A Spiral Model of Software Development and Enhancement"[2]에서 처음 설명되었습니다.1988년 Boehm은 비슷한 논문을[3] 더 많은 독자들에게 발표했다.이 논문들은 나선형 모델에 대해 논의하는 많은 후속 출판물에서 재현된 도표를 소개한다.

이러한 초기 문서에서는 "공정 모델"이라는 용어를 사용하여 나선형 모델뿐만 아니라 증분, 폭포형, 프로토타이핑 및 기타 접근 방식을 나타냅니다.그러나 다른 공정 모형의 특징적인 위험 중심 혼합은 이미 존재합니다.

나선형 모델 단계의 [R]isk-driven subseting을 통해 모델은 사양 지향, 프로토타입 지향, 시뮬레이션 지향, 자동 변환 지향 또는 소프트웨어 [3]개발에 대한 기타 접근법의 적절한 혼합을 수용할 수 있습니다.

이후 출판물에서 Boehm은 나선형 모델을 "프로세스 모델 생성기"로 설명하고 있으며, 이 [1]경우 프로젝트의 리스크에 기초한 선택이 프로젝트에 적합한 프로세스 모델을 생성합니다.따라서 증분 모형, 폭포 모형, 프로토타이핑 모형 및 기타 공정 모형은 특정 프로젝트의 위험 패턴에 적합한 나선 모형의 특수한 경우입니다.

Boehm은 또한 원래 나선형 모델 다이어그램의 과도한 단순화에서 발생하는 많은 오해도 식별한다.그는 이러한 오해 중 가장 위험한 것은 다음과 같다고 말합니다.

  • 나선형이 단순히 폭포 증가의 연속이라는 것.
  • 모든 프로젝트 활동이 단일 나선형 시퀀스를 따르는지 여부
  • 다이어그램의 모든 액티비티가 표시된 순서대로 수행되어야 합니다.

이러한 오해는 일부 프로젝트의 리스크 패턴에 부합할 수 있지만 대부분의 프로젝트에서는 해당되지 않습니다.

국가 연구 위원회[4] 보고서에서 이 모델은 인간 사용자와 관련된 위험을 포함하도록 확장되었다.

Boehm은 "위험한 나선형 외관"과 더 잘 구별하기 위해 나선형 [citation needed]모델의 모든 실제 애플리케이션에 공통되는 6가지 특성을 나열합니다.

나선 모형의 여섯 가지 불변량

나선형 모델의 실제 애플리케이션은 항상 6가지 특성을 표시하는 주기에 의해 구동됩니다.Boehm은 [1]불변성을 위반하는 "위험한 나선형 외관"의 예를 들어 각 항목을 설명합니다.

아티팩트 동시 정의

프로젝트의 주요 아티팩트를 순차적으로 정의하면 이해관계자 "승리 조건"(목표 및 제약 조건)을 충족하는 시스템을 개발할 가능성이 높아집니다.

이 불변성은 폭포 모델의 기본 가정이 적용되지 않는 환경에서 일련의 증분 폭포 통과를 사용하는 "위험 나선형 유사" 프로세스를 제외한다.Boehm은 이러한 전제조건을 다음과 같이 나타냅니다.

  1. 요건은 구현 전에 이미 알고 있습니다.
  2. 요건에는 비용, 스케줄, 퍼포먼스, 안전성, 사용자 인터페이스, 조직에 미치는 영향 등에 의한 리스크 등 해결되지 않은 고위험의 영향이 없습니다.
  3. 요구사항의 성격은 개발 또는 진화 과정에서 크게 변하지 않습니다.
  4. 이 요건은 사용자, 고객, 개발자, 유지관리자 및 투자자를 포함한 모든 주요 시스템 이해관계자의 기대와 호환됩니다.
  5. 요건을 실장하기 위한 적절한 아키텍처는 충분히 이해되고 있습니다.
  6. 순차적으로 진행하기에 충분한 일정 시간이 있습니다.

이러한 전제조건이 적용되는 상황에서는 요건을 특정하지 않고 순차적으로 진행하는 것은 프로젝트의 리스크입니다.따라서 폭포수 모델은 나선형 모델의 위험 주도형 특수 사례가 됩니다.

    사이클마다 4개의 기본 활동을 수행합니다.

    이 불변성은 완화곡선 모델의 각 사이클에서 발생해야 하는 네 가지 활동을 식별합니다.

    1. 성공이 중요한 모든 이해관계자의 성공 조건을 고려합니다.
    2. 성공 조건 충족을 위한 대체 접근 방식을 식별하고 평가합니다.
    3. 선택된 접근법에 기인하는 리스크를 특정하고 해결한다.
    4. 성공이 중요한 모든 이해관계자의 승인을 얻고 다음 사이클을 추진하기 위한 커밋을 받습니다.

    이러한 활동을 생략하거나 단축하는 프로젝트 사이클은 주요 이해관계자가 수용할 수 없거나 너무 위험한 옵션을 추구하여 노력을 낭비할 위험이 있습니다.

    일부 "위험한 나선형 유사" 프로세스는 특정 순차적 단계 또는 주기에서 주요 이해당사자를 제외함으로써 이 불변성을 위반한다.예를 들어 시스템 유지관리자와 관리자는 시스템의 정의 및 개발에 참여할 수 없습니다.그 결과, 시스템은 당첨 조건을 만족시키지 못할 위험이 있습니다.

    리스크에 따라 작업 수준 결정

    프로젝트 활동(예: 요구사항 분석, 설계, 프로토타이핑, 테스트)에 대해 프로젝트 팀은 어느 정도의 노력이 충분한지 결정해야 합니다.진정한 나선형 프로세스 사이클에서는 이러한 결정은 전체적인 위험을 최소화함으로써 이루어집니다.

    예를 들어, 소프트웨어 제품을 테스트하는 데 추가 시간을 투자하면 종종 시장에서 조잡한 제품을 거부하기 때문에 발생하는 위험을 줄일 수 있습니다.그러나 경쟁사의 초기 시장 진입으로 인해 추가 테스트 시간은 위험을 증가시킬 수 있습니다.나선형 모델의 관점에서, 테스트는 총 위험이 최소화될 때까지 수행되어야 하며,[citation needed] 그 이상은 수행해서는 안 됩니다.

    이 불변성을 위반하는 "위험한 나선형 외관"에는 확장성 문제로 인한 위험을 무시하는 진화 프로세스와 미래의 제품 증대에 맞춰 재설계 또는 교체해야 하는 기술 아키텍처에 크게 투자하는 증분 프로세스가 포함됩니다.

    리스크가 세부 사항의 정도를 결정합니다.

    프로젝트 아티팩트(요건 사양, 설계 문서, 테스트 계획 등)에 대해 프로젝트 팀은 어느 정도의 세부 정보가 충분한지 결정해야 합니다.진정한 나선형 프로세스 사이클에서는 이러한 결정은 전체적인 위험을 최소화함으로써 이루어집니다.

    요건 사양을 예로 들어, 프로젝트는 정확한 사양(하드웨어와 소프트웨어 간의 인터페이스, 주요 하청업체와 하청업체 간의 인터페이스 등)을 통해 위험을 줄일 수 있는 기능을 정확하게 지정해야 한다.반대로, 프로젝트는 정확한 사양이 위험을 증가시키는 기능(예: 그래픽 화면 레이아웃, 기성 부품의 동작)을 정확하게 명시해서는 안 된다.

    앵커 포인트 마일스톤 사용

    Boehm의 스파이럴 모델에 대한 원래 설명에는 어떤 공정 이정표도 포함되어 있지 않았습니다.이후 개선사항에서는 진척지표와 약속의 포인트로 기능하는 3가지 주요 마일스톤을 소개합니다.이러한 앵커 포인트 마일스톤은 주요 질문으로 특징지을 수 있습니다.

    1. 라이프 사이클 목표모두의 성공 조건을 만족시키기 위한 기술 및 관리 접근법에 대한 충분한 정의가 있습니까?이해관계자가 "예"라고 대답한 경우, 프로젝트는 이 LCO 마일스톤을 클리어한 것입니다.그렇지 않으면 프로젝트를 포기하거나 이해관계자가 다른 주기에 전념하여 "예"에 도달할 수 있습니다.
    2. 라이프 사이클 아키텍처모든 사람의 성공 조건을 만족시키기 위한 바람직한 접근법에 대한 충분한 정의가 있는가?또한 중요한 리스크는 모두 제거 또는 경감되고 있는가?이해관계자가 "예"라고 대답한 경우 프로젝트는 이 LCA 마일스톤을 클리어한 것입니다.그렇지 않으면 프로젝트를 포기하거나 이해관계자가 다른 주기에 전념하여 "예"에 도달할 수 있습니다.
    3. 초기 운용 능력소프트웨어, 사이트, 사용자, 오퍼레이터, 유지보수의 준비는 시스템을 기동함으로써 모두의 윈 조건을 만족시킬 수 있는 충분한가?이해관계자가 "예"라고 대답할 경우 IOC 마일스톤을 통과하고 프로젝트가 시작됩니다.그렇지 않으면 프로젝트를 포기하거나 이해관계자가 다른 주기에 전념하여 "예"에 도달할 수 있습니다.

    이 불변성을 위반하는 "위험한 나선형"에는 제대로 정의되지 않은 [clarification needed]아키텍처로 솔루션을 구현하기 위해 상당한 자원을 투입하는 진화 및 증분 프로세스가 포함됩니다.

    LCO는 RUP의 시작 단계와 상세 단계 사이의 경계를, LCA는 상세 단계와 시공 단계 간의 경계를, IOC는 건설 단계와 전환 단계 간의 경계를 표시하여 3개의 앵커 포인트 이정표는 Rational Unified Process(RUP)에 쉽게 들어맞는다.

    시스템과 그 라이프 사이클에 초점을 맞춘다.

    이 불변성은 전체 시스템의 중요성과 전체 라이프 사이클에 걸친 장기적인 우려를 강조합니다.소프트웨어 코드 초기 개발에 지나치게 집중하는 "위험한 스파이럴 룩 유사"는 제외됩니다.이러한 프로세스는 프로젝트 프로세스 요구의 다른 측면은 무시한 채 객체 지향 또는 구조화된 소프트웨어 분석 및 설계에 대한 공개된 접근법에 따라 발생할 수 있습니다.

    레퍼런스

    1. ^ a b c Boehm, B (July 2000). "Spiral Development: Experience, Principles, and Refinements" (PDF). Special Report. Software Engineering Institute. CMU/SEI-2000-SR-008.
    2. ^ Boehm, B (August 1986). "A Spiral Model of Software Development and Enhancement". ACM SIGSOFT Software Engineering Notes. 11 (4): 14–24. doi:10.1145/12944.12948. S2CID 207165409.
    3. ^ a b Boehm, B (May 1988). "A Spiral Model of Software Development and Enhancement" (PDF). IEEE Computer. 21 (5): 61–72. doi:10.1109/2.59. S2CID 1781829.
    4. ^ Pew, R.W.; Mavor, A.S., eds. (2007). Human-system integration in the system development process: A new look. Washington, D.C.: National Academy Press. ISBN 978-0-309-10720-4.