맨위로가기

나선 모형

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

나선 모형은 소프트웨어 개발 방법론 중 하나로, 1986년 배리 뵘에 의해 처음 소개되었다. 이 모형은 반복적인 개발 방식을 통해 각 단계마다 위험 요소를 파악하고 제거하는 데 중점을 둔다. 주요 특징으로는 위험 관리를 통한 점진적인 시스템 완성, 프로토타입을 활용한 클라이언트와의 소통, 그리고 잦은 반복을 통한 문제 해결의 용이성이 있다. 나선 모형은 프로그램 규모와 일정 예측에 유리하며, 요구사항 변경에 유연하게 대처할 수 있다는 장점이 있으나, 반복 횟수 증가에 따른 비용 증가, 고객과의 소통 문제, 사양 리뷰의 느슨함 등의 단점도 존재한다.

더 읽어볼만한 페이지

  • 소프트웨어 개발 프로세스 - 버전 관리
    버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다.
  • 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
    소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
나선 모형
개요
스파이럴 모델
스파이럴 모델의 다이어그램
개발 방식소프트웨어 개발 프로세스 모델
상세 내용
설계 방식톱다운 설계와 보텀업 설계의 장점을 활용
특징위험 분석을 중요하게 고려
단계
1단계계획 (Plan)
2단계위험 분석 (Risk Analysis)
3단계개발 (Engineering)
4단계고객 평가 (Customer Evaluation)
장점
위험 관리개발 과정에서 발생할 수 있는 위험을 체계적으로 관리 가능
융통성변화하는 요구사항에 유연하게 대처 가능
사용자 참여사용자 피드백을 적극적으로 반영 가능
반복적 개선프로토타입을 통해 점진적인 개선 가능
단점
복잡성모델 자체가 복잡하여 관리 및 이해가 어려울 수 있음
높은 비용위험 분석 및 관리, 반복적인 개발 과정으로 인해 비용 증가 가능
시간 소모각 단계를 반복적으로 수행하므로 개발 기간이 길어질 수 있음
숙련된 인력 필요위험 분석 및 관리에 대한 전문 지식을 가진 인력 필요

2. 역사

이 모형은 1986년 배리 뵘이 발표한 논문 "소프트웨어 개발 및 향상의 나선형 모형"에서 처음 설명되었다.[2] 1988년 뵘은 더 많은 독자를 대상으로 유사한 논문을 발표했다.[3] 이 논문들은 나선형 모형을 설명하는 많은 후속 출판물에서 재현된 다이어그램을 소개한다.

초기 논문들은 나선형 모형뿐만 아니라 점진적, 폭포수, 프로토타이핑 및 기타 접근 방식에도 "프로세스 모형"이라는 용어를 사용했다. 그러나 다른 프로세스 모형의 특징을 위험 기반으로 혼합하는 나선형 모형의 특징은 이미 존재했다.

The risk-driven subsetting of the spiral model steps allows the model to accommodate any appropriate mixture of a specification-oriented, prototype-oriented, simulation-oriented, automatic transformation-oriented, or other approach to software development.영어[3]

후속 출판물에서,[1] 뵘은 나선형 모형을 프로젝트의 위험을 기반으로 선택 사항이 프로젝트에 적합한 프로세스 모형을 생성하는 "프로세스 모형 생성기"로 설명한다. 따라서 점진적, 폭포수, 프로토타이핑 및 기타 프로세스 모형은 특정 프로젝트의 위험 패턴에 맞는 나선형 모형의 특수한 경우이다.

뵘은 또한 원래 나선형 모형 다이어그램의 단순화로 인해 발생하는 여러 가지 오해를 식별한다. 그는 이러한 오해 중 가장 위험한 것은 다음과 같다고 말한다.


  • 나선형이 단순히 폭포수 증가의 시퀀스라는 것
  • 모든 프로젝트 활동이 단일 나선형 시퀀스를 따른다는 것
  • 다이어그램의 모든 활동이 표시된 순서대로 수행되어야 한다는 것


이러한 오해는 소수의 프로젝트의 위험 패턴에 맞을 수 있지만 대부분의 프로젝트에는 해당되지 않는다.

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

1988년, 배리 벰은 ''A Spiral Model of Software Development and Enhancement''(소프트웨어 개발 및 개선의 나선형 모델)라는 논문에서 나선형 모델을 제안했다. 반복적 개발 모델이 이것이 처음은 아니었지만, 반복의 중요성을 제기한 것은 이 모델이 처음이다. 원래 예상으로는, 한 번의 루프는 6개월에서 2년으로 설정되었다. 먼저, 설계 목표를 정하고, 한 번의 루프 완료 시점에서 사용자(개발 내부인 경우도 있다)가 그 시점까지의 진척을 평가한다. 공학적 분석을 매번 수행함과 동시에, 최종 목표를 바라보며 개발 루프를 반복해 나간다.

구체적으로, 대상 시스템을 기능 단위로 분할하고, 설계~프로그래밍·테스트라는 일련의 개발 공정을 여러 번 반복하면서 개발 공정의 규모를 점차 확대(기능의 개량·추가)해 나가는 개발 모델이다.

3. 특징

이 모형은 1986년 배리 뵘이 발표한 논문 "소프트웨어 개발 및 향상의 나선형 모형"에서 처음 설명되었고,[2] 1988년 더 많은 독자를 대상으로 유사한 논문을 발표했다.[3] 이 논문들은 나선형 모형을 설명하는 많은 후속 출판물에서 재현된 다이어그램을 소개한다.

초기 논문에서 뵘은 나선형 모형뿐만 아니라 점진적, 폭포수, 프로토타이핑 및 기타 접근 방식에도 "프로세스 모형"이라는 용어를 사용했다. 그러나 나선형 모형은 다른 프로세스 모형의 특징을 위험 기반으로 혼합한다는 특징이 있다. 뵘은 후속 출판물에서 나선형 모형을 프로젝트의 위험을 기반으로 선택 사항이 프로젝트에 적합한 프로세스 모형을 생성하는 "프로세스 모형 생성기"로 설명한다.[1] 따라서 점진적, 폭포수, 프로토타이핑 및 기타 프로세스 모형은 특정 프로젝트의 위험 패턴에 맞는 나선형 모형의 특수한 경우이다.

뵘은 또한 원래 나선형 모형 다이어그램의 단순화로 인해 발생하는 여러 가지 오해를 식별하고, 가장 위험한 오해는 다음과 같다고 말한다.


  • 나선형이 단순히 폭포수 증가의 시퀀스라는 것
  • 모든 프로젝트 활동이 단일 나선형 시퀀스를 따른다는 것
  • 다이어그램의 모든 활동이 표시된 순서대로 수행되어야 한다는 것


이러한 오해는 소수의 프로젝트 위험 패턴에는 맞을 수 있지만, 대부분의 프로젝트에는 해당되지 않는다.

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

뵘은 "위험한 나선형 유사품"과 구별하기 위해 나선형 모형의 모든 정통 응용 프로그램에 공통되는 여섯 가지 특성을 나열하고, 각 특징을 위반하는 "위험한 나선 모형 짝퉁"의 예시와 함께 설명한다.[1]

나선형 모델은 반복적 개발을 통해 시스템을 점진적으로 완성해 나가는 방식을 사용하며, 매 반복 전에 위험 요소를 관리하여 개발을 안정적으로 수행하는 특징을 가진다.

3. 1. 반복적 개발

나선 모형에서 중요한 점은 매번 반복하기 전에 위험 요소를 알아내고 사전에 제거하는 데 있다. 매번 다음 단계의 반복을 진행할 때마다 기능적, 성능적 측면에서 가장 위험 요소가 높은 부분을 먼저 진행하고 없앤다. 즉, 가장 위험 요소가 큰 부분 혹은 버그가 발생하기 쉬운 측면을 절대로 개발의 마지막 단계까지 미루지 않는 것이 핵심이다.

반복적 개발의 장점은 다음과 같다. 첫째, 클라이언트가 완성된 프로젝트는 아니지만 최소한 프로토타입을 미리 볼 수 있다. 이를 통해 개발자와의 소통, 즉 피드백이 가능하다. 또한 반복에서 오는 장점을 극대화하기 위해서는 자주 반복을 실시해야 한다. 반복적 개발 단계에서 문제가 발생했다면, 그것은 가장 최근에 변경한 작업 혹은 추가된 작업일 확률이 높다. 따라서 잦은 반복을 통해 어디서부터 잘못되었는지를 쉽게 파악할 수 있으므로 버그로 인한 시간 낭비를 줄일 수 있다.

1988년, 배리 벰은 ''A Spiral Model of Software Development and Enhancement''(소프트웨어 개발 및 개선의 나선형 모델)라는 논문에서 나선형 모델을 제안했다. 반복적 개발 모델이 이것이 처음은 아니었지만, 반복의 중요성을 제기한 것은 이 모델이 처음이다. 원래 예상으로는, 한 번의 루프는 6개월에서 2년으로 설정되었다. 먼저, 설계 목표를 정하고, 한 번의 루프 완료 시점에서 사용자(개발 내부인 경우도 있다)가 그 시점까지의 진척을 평가한다. 공학적 분석을 매번 수행함과 동시에, 최종 목표를 바라보며 개발 루프를 반복해 나간다.[1]

구체적으로는, 대상 시스템을 기능 단위로 분할하고, 설계~프로그래밍·테스트라는 일련의 개발 공정을 여러 번 반복하면서 개발 공정의 규모를 점차 확대(기능의 개량·추가)해 나가는 개발 모델이다.[1]

3. 2. 위험 관리

나선 모형에서 중요한 점은 매번 반복하기 전에 위험 요소를 파악하고 사전에 제거하는 것이다. 매번 다음 단계의 반복을 진행할 때마다 기능적, 성능적 측면에서 가장 위험 요소가 높은 부분을 먼저 진행하고 없앤다. 즉, 가장 위험 요소가 큰 부분 혹은 버그가 발생하기 쉬운 부분을 절대로 개발의 마지막 단계까지 미루지 않는 것이 핵심이다.[2]

반복적으로 개발하면 다음과 같은 장점이 있다. 첫째, 고객이 완성된 프로젝트는 아니지만 최소한 프로토타입을 미리 볼 수 있다. 이를 통해 개발자와의 소통, 즉 피드백이 가능하다. 또한, 반복에서 오는 장점을 극대화하기 위해서는 자주 반복을 실시해야 한다. 반복적 개발 단계에서 문제가 발생했다면, 그것은 가장 최근에 변경하거나 추가된 작업일 확률이 높다. 따라서 잦은 반복을 통해 어디서부터 잘못되었는지를 쉽게 파악하여 버그로 인한 시간 낭비를 줄일 수 있다.

배리 뵘은 1986년 "소프트웨어 개발 및 향상의 나선형 모형"이라는 논문에서 나선 모형을 처음 설명했고,[2] 1988년에는 더 많은 독자를 대상으로 유사한 논문을 발표했다.[3] 뵘은 나선형 모형을 프로젝트의 위험을 기반으로 선택 사항이 프로젝트에 적합한 프로세스 모형을 생성하는 "프로세스 모형 생성기"로 설명한다.[1] 따라서 점진적, 폭포수, 프로토타이핑 및 기타 프로세스 모형은 특정 프로젝트의 위험 패턴에 맞는 나선형 모형의 특수한 경우이다.

미국 국립 연구 위원회 보고서[4]에서는 이 모형을 인간 사용자와 관련된 위험을 포함하도록 확장했다.

1988년, 배리 벰은 ''A Spiral Model of Software Development and Enhancement''(소프트웨어 개발 및 개선의 나선형 모델)라는 논문에서 나선형 모델을 제안했다. 반복적 개발 모델이 이것이 처음은 아니었지만, 반복의 중요성을 제기한 것은 이 모델이 처음이다. 원래 예상으로는 한 번의 루프는 6개월에서 2년으로 설정되었다. 먼저 설계 목표를 정하고, 한 번의 루프 완료 시점에서 사용자(개발 내부인 경우도 있다)가 그 시점까지의 진척을 평가한다. 공학적 분석을 매번 수행함과 동시에, 최종 목표를 바라보며 개발 루프를 반복해 나간다.

구체적으로, 대상 시스템을 기능 단위로 분할하고, 설계~프로그래밍·테스트라는 일련의 개발 공정을 여러 번 반복하면서 개발 공정의 규모를 점차 확대(기능의 개량·추가)해 나가는 개발 모델이다.

3. 3. 점진적인 시스템 완성

나선 모형에서 중요한 점은 매번 반복하기 전에 위험 요소를 알아내고 사전에 제거하는 데 있다. 매번 다음 단계의 반복을 진행할 때마다 기능적, 성능적 측면에서 가장 위험 요소가 높은 부분을 먼저 진행하고 없앤다. 즉, 가장 위험 요소가 큰 부분 혹은 버그가 발생하기 쉬운 부분을 절대로 개발의 마지막 단계까지 미루지 않는 것이 핵심이다.

반복적으로 개발하면 다음과 같은 장점이 있다. 첫째, 클라이언트가 완성된 소프트웨어는 아니지만 최소한 프로토타입을 미리 볼 수 있다. 이를 통해 개발자와의 소통, 즉 피드백이 가능하다. 또한 반복에서 오는 장점을 극대화하려면 자주 반복을 실시해야 한다. 반복적 개발 단계에서 문제가 생겼다면, 그것은 가장 최근에 변경하거나 추가된 작업일 확률이 높다. 따라서 잦은 반복을 통해 어디에서부터 잘못되었는지를 쉽게 알아낼 수 있으므로 버그로 인한 시간 낭비를 줄일 수 있다.

구체적으로, 대상 시스템을 기능 단위로 분할하고, 설계, 프로그래밍, 테스트와 같은 일련의 개발 공정을 여러 번 반복하면서 개발 공정의 규모를 점차 확대(기능의 개량·추가)해 나가는 개발 모델이다.[1]

3. 4. 상세 설명(한국어 위키백과 내용)

나선 모형은 1988년 배리 벰이 ''A Spiral Model of Software Development and Enhancement''(소프트웨어 개발 및 개선의 나선형 모델)라는 논문에서 제안했다. 반복적 개발 모델이 이것이 처음은 아니었지만, 반복의 중요성을 제기한 것은 이 모델이 처음이다. 원래 예상으로는, 한 번의 루프는 6개월에서 2년으로 설정되었다. 먼저, 설계 목표를 정하고, 한 번의 루프 완료 시점에서 사용자(개발 내부인 경우도 있다)가 그 시점까지의 진척을 평가한다. 공학적 분석을 매번 수행함과 동시에, 최종 목표를 바라보며 개발 루프를 반복해 나간다.

구체적으로, 대상 시스템을 기능 단위로 분할하고, 설계, 프로그래밍, 테스트라는 일련의 개발 공정을 여러 번 반복하면서 개발 공정의 규모를 점차 확대(기능의 개량·추가)해 나가는 개발 모델이다.

나선 모형에서 중요한 점은 매번 반복하기 전에 위험 요소를 알아내고 사전에 제거하는 데에 있다. 매번 다음 단계의 반복을 진행할 때마다 기능적, 성능적 측면에서 가장 위험 요소가 높은 부분을 먼저 진행하고 없앤다. 즉, 가장 위험 요소가 큰 부분 혹은 버그가 발생하기 쉬운 측면을 절대로 개발의 마지막 단계까지 미루지 않는다는 것이 핵심이다.

반복적 개발에서 오는 장점으로는 첫째, 클라이언트가 완성된 프로젝트는 아니지만 최소한 프로토타입을 미리 볼 수 있다는 점이다. 그리고 이를 통해서 개발자와의 소통, 즉 피드백이 가능하다는 것이다. 또한 반복에서 오는 장점을 극대화하기 위해서는 자주 반복을 실시해야 한다. 그 이유는, 반복적 개발 단계에서 어떠한 문제가 생겼다면 그것은 가장 최근에 변경한 작업 혹은 추가된 작업일 확률이 높기 때문이다. 그렇기 때문에 잦은 반복을 통해서 어디에서부터 잘못되었는지를 쉽게 알아낼 수 있으므로 버그로 인한 시간 낭비를 줄일 수 있다.

4. 나선형 모델의 6가지 불변성 (영어 위키백과)

배리 뵘은 1986년 "소프트웨어 개발 및 향상의 나선형 모형"이라는 논문에서 나선형 모형을 처음 설명했고,[2] 1988년에는 더 많은 독자를 대상으로 유사한 논문을 발표했다.[3] 초기 논문들에서는 점진적, 폭포수, 프로토타이핑 등 다른 프로세스 모형의 특징을 위험 기반으로 혼합하는 나선형 모형의 특징을 이미 제시했다. 뵘은 나선형 모형을 프로젝트의 위험을 기반으로 선택 사항이 프로젝트에 적합한 프로세스 모형을 생성하는 "프로세스 모형 생성기"로 설명한다.[1] 따라서 점진적, 폭포수, 프로토타이핑 및 기타 프로세스 모형은 특정 프로젝트의 위험 패턴에 맞는 나선형 모형의 특수한 경우이다.

뵘은 또한 원래 나선형 모형 다이어그램의 단순화로 인해 발생하는 여러 가지 오해를 식별하고, 그 중 가장 위험한 것은 다음과 같다고 말한다.


  • 나선형이 단순히 폭포수 증가의 시퀀스라는 것
  • 모든 프로젝트 활동이 단일 나선형 시퀀스를 따른다는 것
  • 다이어그램의 모든 활동이 표시된 순서대로 수행되어야 한다는 것


이러한 오해는 소수의 프로젝트에는 맞을 수 있지만, 대부분의 프로젝트에는 해당되지 않는다.

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

뵘은 "위험한 나선형 유사품"과 구별하기 위해 나선형 모형의 모든 정통 응용 프로그램에 공통되는 여섯 가지 불변성을 나열했다.[1] 이 여섯 가지 불변성은 다음과 같다.

  • 주요 산출물의 동시적 정의
  • 주기마다 4가지 기본 활동 수행
  • 위험 기반 노력 수준 결정
  • 위험 기반 세부 수준 결정
  • 앵커 포인트 마일스톤 사용
  • 시스템 및 수명 주기에 집중

4. 1. 주요 산출물의 동시적 정의

프로젝트의 주요 산출물을 순차적으로 정의하면 이해 관계자들의 "성공 조건"(목표와 제약 조건)을 충족하는 시스템을 개발할 가능성이 높아지는 경우가 많다.

이러한 불변성은 폭포수 모델의 기본 가정이 적용되지 않는 환경에서 점증적인 폭포수 단계를 순차적으로 사용하는 "위험한 나선형 유사" 프로세스를 배제한다. 뵘(Boehm)은 이러한 가정을 다음과 같이 나열한다.

  • 요구 사항은 구현 전에 알려져 있다.
  • 요구 사항에는 비용, 일정, 성능, 안전, 사용자 인터페이스, 조직적 영향 등으로 인한 위험과 같이 해결되지 않은, 위험성이 높은 영향이 없다.
  • 요구 사항의 특성은 개발 또는 진화 과정에서 크게 변경되지 않는다.
  • 요구 사항은 사용자, 고객, 개발자, 유지 보수 담당자 및 투자자를 포함한 모든 주요 시스템 이해 관계자의 기대와 호환된다.
  • 요구 사항을 구현하기 위한 올바른 아키텍처는 잘 이해되고 있다.
  • 순차적으로 진행할 수 있는 충분한 시간이 있다.


이러한 가정이 실제로 적용되는 상황에서는 요구 사항을 지정하고 순차적으로 진행하지 않는 것이 프로젝트 위험이다. 따라서 폭포수 모델은 나선형 모델의 위험 기반 특수한 경우가 된다.

4. 2. 주기마다 4가지 기본 활동 수행

나선 모형은 각 주기마다 다음 네 가지 기본 활동을 반드시 수행해야 한다.

# 성공에 중요한 모든 이해 관계자의 성공 조건을 고려한다.

# 성공 조건을 충족하기 위한 대체 접근 방식을 식별하고 평가한다.

# 선택된 접근 방식에서 비롯된 위험을 식별하고 해결한다.

# 모든 성공에 중요한 이해 관계자로부터 승인을 얻고, 다음 주기를 추진하기 위한 약속을 받는다.

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

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

1988년, 배리 벰은 ''A Spiral Model of Software Development and Enhancement''(소프트웨어 개발 및 개선의 나선형 모델)라는 논문에서 나선형 모델을 제안했다. 반복적 개발 모델이 이것이 처음은 아니었지만, 반복의 중요성을 제기한 것은 이 모델이 처음이다. 원래 예상으로는, 한 번의 루프는 6개월에서 2년으로 설정되었다. 먼저, 설계 목표를 정하고, 한 번의 루프 완료 시점에서 사용자(개발 내부인 경우도 있다)가 그 시점까지의 진척을 평가한다. 공학적 분석을 매번 수행함과 동시에, 최종 목표를 바라보며 개발 루프를 반복해 나간다.

구체적으로, 대상 시스템을 기능 단위로 분할하고, 설계~프로그래밍·테스트라는 일련의 개발 공정을 여러 번 반복하면서 개발 공정의 규모를 점차 확대(기능의 개량·추가)해 나가는 개발 모델이다.

4. 3. 위험 기반 노력 수준 결정

나선 모형에서 중요한 점은 매번 반복하기 전에 위험 요소를 파악하고 사전에 제거하는 것이다. 나선 모형에서는 다음 단계의 반복을 진행할 때마다 기능적, 성능적 측면에서 가장 위험 요소가 높은 부분을 먼저 진행하고 제거한다. 즉, 가장 위험 요소가 크거나 버그가 발생하기 쉬운 부분을 개발 마지막 단계까지 미루지 않는 것이 핵심이다.

반복적 개발의 장점으로는 첫째, 고객이 완성된 프로젝트는 아니지만 최소한 프로토타입을 미리 보고 개발자와 소통하여 피드백을 할 수 있다는 점이다. 또한 반복의 장점을 극대화하기 위해서는 자주 반복을 실시해야 한다. 반복적 개발 단계에서 문제가 발생하면, 가장 최근에 변경하거나 추가된 작업일 확률이 높기 때문이다. 따라서 잦은 반복을 통해 문제 발생 지점을 쉽게 파악하여 버그로 인한 시간 낭비를 줄일 수 있다.

모든 프로젝트 활동(요구사항 분석, 설계, 프로토타입 제작, 테스트 등)에 대해, 프로젝트 팀은 얼마나 많은 노력이 충분한지 결정해야 한다. 진정한 나선형 프로세스에서는 이러한 결정이 전체 위험을 최소화하는 방식으로 이루어진다.

예를 들어, 소프트웨어 제품 테스트에 추가 시간을 투자하면 조잡한 제품에 대한 시장 거부로 인한 위험이 줄어들 수 있다. 그러나 추가 테스트 시간은 경쟁사의 조기 시장 진입으로 인한 위험을 증가시킬 수 있다. 벰은 나선형 모델 관점에서 총 위험이 최소화될 때까지 더 이상 테스트를 수행해서는 안 된다고 하였다.

4. 4. 위험 기반 세부 수준 결정

나선 모형에서 중요한 점은 매번 반복하기 전에 위험 요소를 알아내고 사전에 제거하는 것이다. 매번 다음 단계의 반복을 진행할 때마다 기능적, 성능적 측면에서 가장 위험 요소가 높은 부분을 먼저 진행하고 없앤다. 즉, 가장 위험 요소가 큰 부분 혹은 버그가 발생하기 쉬운 측면을 개발 마지막 단계까지 미루지 않는 것이 핵심이다.

반복적 개발의 장점은 다음과 같다. 첫째, 클라이언트가 완성된 프로젝트는 아니지만 최소한 프로토타입을 미리 보고 개발자와 소통, 즉 피드백을 할 수 있다. 둘째, 반복의 장점을 극대화하기 위해 자주 반복을 실시하면, 문제 발생 시 가장 최근에 변경 또는 추가된 작업에서 비롯되었을 확률이 높아 버그로 인한 시간 낭비를 줄일 수 있다.

모든 프로젝트 산출물(예: 요구사항 명세서, 설계 문서, 테스트 계획)에 대해, 프로젝트 팀은 어느 정도의 세부 수준이 적절한지 결정해야 한다. 실제 나선형 프로세스 사이클에서는 이러한 결정이 전체 위험을 최소화하여 이루어진다.

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

4. 5. 앵커 포인트 마일스톤 사용

보엠은 나선형 모델에 대한 최초 설명에는 어떠한 프로세스 마일스톤도 포함하지 않았지만, 이후 개선 과정에서 진행 상황 지표이자 약속의 지점 역할을 하는 세 가지 앵커 포인트 마일스톤을 도입했다. 이러한 앵커 포인트 마일스톤은 핵심 질문으로 특징지을 수 있다.

  • 생명 주기 목표 (Life Cycle Objectives): 모든 사람의 윈 컨디션을 충족시키기 위한 기술 및 관리 접근 방식에 대한 충분한 정의가 있는가? 이해 관계자들이 이에 대해 "예"라고 답한다면, 프로젝트는 이 LCO 마일스톤을 통과한 것이다. 그렇지 않다면, 프로젝트는 포기하거나 이해 관계자들이 "예"에 도달하기 위해 다른 사이클을 시도할 수 있다.
  • 생명 주기 아키텍처 (Life Cycle Architecture): 모든 사람의 윈 컨디션을 충족시키기 위한 선호하는 접근 방식에 대한 충분한 정의가 있고, 모든 중요한 위험이 제거되거나 완화되었는가? 이해 관계자들이 이에 대해 "예"라고 답한다면, 프로젝트는 이 LCA 마일스톤을 통과한 것이다. 그렇지 않다면, 프로젝트는 포기하거나 이해 관계자들이 "예"에 도달하기 위해 다른 사이클을 시도할 수 있다.
  • 초기 운영 역량 (Initial Operational Capability): 시스템 출시를 통해 모든 사람의 윈 컨디션을 충족시키기 위한 소프트웨어, 사이트, 사용자, 운영자 및 유지 관리자에 대한 충분한 준비가 되어 있는가? 이해 관계자들이 이에 대해 "예"라고 답한다면, 프로젝트는 IOC 마일스톤을 통과하고 출시된다. 그렇지 않다면, 프로젝트는 포기하거나 이해 관계자들이 "예"에 도달하기 위해 다른 사이클을 시도할 수 있다.


이러한 세 가지 앵커 포인트 마일스톤은 래쇼널 통합 프로세스(RUP)에 쉽게 들어맞으며, LCO는 RUP의 시작 단계와 상세화 단계 사이의 경계를, LCA는 상세화 단계와 구축 단계 사이의 경계를, IOC는 구축 단계와 전환 단계 사이의 경계를 표시한다.

4. 6. 시스템 및 수명 주기에 집중

이 모델은 전체 시스템과 전체 수명 주기에 걸친 장기적인 문제의 중요성을 강조한다. 이는 소프트웨어 코드의 초기 개발에만 지나치게 집중하는 "위험한 나선형 유사 방식"을 배제한다. 이러한 방식은 객체 지향 또는 구조적 소프트웨어 분석 및 설계를 위한 공개된 접근 방식을 따르면서 프로젝트 프로세스 요구 사항의 다른 측면을 무시한 결과로 나타날 수 있다.[1]

1988년, 배리 벰은 ''A Spiral Model of Software Development and Enhancement''(소프트웨어 개발 및 개선의 나선형 모델)라는 논문에서 나선형 모델을 제안했다.[1] 반복적 개발 모델이 이것이 처음은 아니었지만, 반복의 중요성을 제기한 것은 이 모델이 처음이다. 원래 예상으로는 한 번의 루프는 6개월에서 2년으로 설정되었다. 먼저 설계 목표를 정하고, 한 번의 루프 완료 시점에서 사용자(개발 내부인 경우도 있다)가 그 시점까지의 진척을 평가한다. 공학적 분석을 매번 수행함과 동시에, 최종 목표를 바라보며 개발 루프를 반복해 나간다.[1]

구체적으로, 대상 시스템을 기능 단위로 분할하고, 설계~프로그래밍·테스트라는 일련의 개발 공정을 여러 번 반복하면서 개발 공정의 규모를 점차 확대(기능의 개량·추가)해 나가는 개발 모델이다.[1]

5. 응용

미국군은 미래 전투 시스템 개발에 나선 모형을 적용하고 있다.

5. 1. 대한민국 국방 분야

주어진 원본 소스에는 '대한민국 국방 분야'에 대한 내용이 직접적으로 언급되어 있지 않다. 따라서 해당 섹션에 내용을 추가할 수 없다.

5. 2. 해외 사례

미국군은 미래 전투 시스템(Future Combat Systems) 개발에 나선 모형을 적용하고 있다.

6. 장단점

나선 모형은 반복적인 개발을 통해 위험 관리에 중점을 둔 소프트웨어 개발 프로세스이다. 위험 요소 조기 발견 및 해결, 고객과의 지속적인 소통을 통한 요구사항 반영, 유연한 개발 방식 등이 주요 장점이다.

반면 반복 횟수가 늘어날수록 비용이 증가하고, 단순 재작업의 위험이 있으며, 고객의 요구사항 정리가 미흡할 수 있고, 개발 측 부담 증가 및 느슨한 사양 리뷰 등의 단점도 존재한다.

6. 1. 장점

나선 모형은 반복적인 개발을 통해 프로젝트를 발전시키는 소프트웨어 개발 프로세스이다. 이러한 반복적 개발 방식은 다음과 같은 장점을 제공한다.

  • 위험 관리: 매 반복 단계 전에 위험 요소를 분석하고 제거한다. 기능적, 성능적 측면에서 가장 위험도가 높은 부분을 우선적으로 처리하여 개발 마지막 단계까지 미루지 않는다.
  • 프로토타입 시연: 고객은 완성된 프로젝트는 아니지만 프로토타입을 통해 개발 진행 상황을 확인할 수 있다. 이를 통해 개발자와의 소통 및 피드백이 가능하다.
  • 문제점 조기 발견: 반복 주기를 짧게 가져감으로써, 문제 발생 시 최근 변경/추가된 작업에서 원인을 쉽게 찾을 수 있다. 이는 버그 수정에 드는 시간 낭비를 줄여준다.


맞춤형 소프트웨어를 개발하는 경우, 폭포수 모델과 비교했을 때 나선 모형은 다음과 같은 장점을 가진다.

  • 프로그램 규모 및 일정 예측이 용이하다.
  • 소프트웨어 개발 중 발생하는 요구 사항 변경에 유연하게 대처 가능하다.
  • 설계 과정 증가로 인해 구현 기간이 단축되는 문제를 방지할 수 있다.

6. 2. 단점

나선 모형은 반복적인 개발을 통해 프로젝트를 발전시키지만, 다음과 같은 단점들이 존재한다.

  • 비용 증가: 반복 횟수가 늘어날수록 개발 비용이 증가할 수 있다.
  • 단순 재작업 가능성: 현장의 이해를 충분히 얻지 못하면, 이전 반복에서 만든 프로토타입을 단순 재사용하는 것에 그칠 수 있다.
  • 고객의 요구사항 정리 미흡: 고객은 계약 후 무료 수정이 가능하다고 생각하여 요구사항을 명확하게 정리하지 않는 경향이 있을 수 있다.
  • 개발 측 부담 증가: 고객과 개발 측 간의 소통 창구가 여러 개가 되면 개발 측의 부담이 커질 수 있다.
  • 느슨한 사양 리뷰: 다음 반복이 있다는 생각에 사양 리뷰가 꼼꼼하게 이루어지지 않을 수 있다.

7. 다른 모델과의 비교

나선 모형은 매번 반복하기 전에 위험 요소를 파악하고 제거하는 데 중점을 둔다. 기능적, 성능적 측면에서 위험 요소가 높은 부분을 우선적으로 처리하여 개발 마지막 단계까지 미루지 않는다.

반복적 개발의 장점은 다음과 같다.


  • 클라이언트는 완성된 프로젝트는 아니지만 프로토타입을 미리 보고 개발팀과 소통하며 피드백을 줄 수 있다.
  • 반복적 개발 단계에서 문제가 발생하면, 가장 최근에 변경하거나 추가된 작업일 확률이 높다. 따라서 잦은 반복을 통해 문제 발생 지점을 쉽게 파악하여 버그로 인한 시간 낭비를 줄일 수 있다.


맞춤형 소프트웨어를 개발하는 경우, 폭포수 모델과 비교했을 때의 장단점은 다음과 같다.

참조

[1] 간행물 Spiral Development: Experience, Principles, and Refinements https://resources.se[...] Software Engineering Institute 2000-07
[2] 간행물 A Spiral Model of Software Development and Enhancement 1986-08
[3] 간행물 A Spiral Model of Software Development and Enhancement http://www-scf.usc.e[...] 1988-05
[4] 서적 Human-system integration in the system development process: A new look http://books.nap.edu[...] National Academy Press 2007


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com