나선형 모델 : 역사, 특성, 단계, 예 - 과학 기술 - 2025

나선형 모델은 애플리케이션 개발 프로세스의 원형이다. 이는 소프트웨어 개발이 설정된 목표가 달성 될 때까지 반복되는 반복적 인주기라는 가설을 기반으로합니다. 소프트웨어를 개발할 때 발생할 수있는 많은 위험을 처리 할 수있는 능력이 있습니다.

위험 관리를 지원하는 가장 중요한 모델 중 하나입니다. 이름에서 알 수 있듯이이 모델은 나선형으로 표시되며 모델의 여러 단계가 서로 다른 주기로 분포되어 있습니다. 모델의주기 수는 고정되어 있지 않으며 프로젝트마다 다를 수 있습니다.

분석, 평가, 계획 및 개발. 소프트웨어 개발 스파이럴 출처 : Beao commons.wikimedia.org

역사

창조

나선형 모델은 미국의 수학자이자 소프트웨어 공학 교수 인 Barry Boehm에 의해 정의되었습니다. 1986 년에 복잡한 애플리케이션 개발에 대한 개념을 발표 한 후 그는 1988 년 자신의 기사 "소프트웨어 개발 및 개선의 나선형 모델"에서보다 포괄적 인 프레임 워크로 모델을 발표했습니다.

이 1988 년 간행물의 일부는 나선형 모델을 그래픽으로 묘사하여 소프트웨어 개발 프로세스가 나선형 방식으로 보이고주기에 의해 지원되는 방식을 완전히 보여줍니다.

Boehm은 건설 비용 모델 (COCOMO), 소프트웨어 프로세스의 나선형 모델, 요구 사항 결정 및 관리에 대한 G- 이론 (윈-윈) 접근 방식과 같은 소프트웨어 엔지니어링에 대한 수많은 공헌으로 유명합니다. 소프트웨어의.

폭포 모델의 대안

그의 간행물에서 Boehm은 나선형 모델을 이전에 확립 된 폭포 모델의 가능한 대안으로 설명했으며, 이는 그의 연습의 기초로도 사용되었습니다.

나선형 모델은 주기적 개발을 논의한 최초의 모델은 아니지만 반복이 중요한 이유를 설명하는 최초의 모델이었습니다. 원래 계획대로 반복이 일반적으로 6 개월에서 2 년 사이 인 크고 복잡한 프로젝트를 대상으로했습니다.

이 모델은 소프트웨어 개발 작업이 폭포수 모델과 달리 선형 적으로 설계되었다고 가정하지 않고 오히려 반복 작업으로 간주합니다.

이 주기적 모델은 MBASE (Model Based Software Engineering Architecture) 및 익스트림 프로그래밍에 영향을 미쳤습니다.

나선형 모델의 특징

위험 관리

이 모델이 다른 소프트웨어 프로세스 모델과 크게 다른 점은 위험을 명시 적으로 인식한다는 것입니다. 따라서 위험을 반복적으로 평가하고 매번 개발중인 제품을 확인하여 대규모 소프트웨어 프로젝트의 실패를 크게 줄입니다.

이 컴퓨터 모델에는 폭포 모델, 프로토 타이핑 모델, 반복 모델, 진화 모델 등과 같은 소프트웨어 수명주기의 거의 모든 모델의 구성 요소가 포함되어 있습니다.

이로 인해 다른 모델이 일반적으로 처리하지 못하는 거의 모든 유형의 위험을 처리 할 수 ​​있습니다. 그러나 구성 요소가 너무 많기 때문에이 모델은 다른 소프트웨어 개발 모델보다 훨씬 더 복잡합니다.

나선형에 대한 설명

나선형의 각 회전은 모델의 4 단계를 나타내는 4 개의 사분면이 항상 통과하는 완전한주기를 나타냅니다.

나선의 크기가 증가함에 따라 진행도 증가합니다. 따라서 스테이지는 한 번만 실행되는 것이 아니라 여러 번 나선형으로 실행됩니다.

이러한 주기적 반복으로 인해 프로젝트가 설정된 목표에 천천히 접근하지만 개발 프로세스가 실패 할 위험은 크게 최소화됩니다.

일반적인

4 단계는주기의 기본 목표 만 구현하지만 각주기에서 명시 할 필요는 없습니다.

각주기의 순서도 엄격하게 결정되지 않습니다. 따라서 모델은 언제든지 다른 모델과 결합 될 수 있습니다.

융통성 있는

프로젝트의 각 단계에 대해 개별적으로 목표 정의, 위험 분석, 개발 및 계획 프로세스를 수행하므로 매우 유연합니다.

메타 모델

다른 모델을 포함하므로 메타 모델로 간주됩니다. 예를 들어 나선형이 단일 사이클 인 경우이 클래식 모델의 점진적 접근 방식을 통합하므로 폭포 모델을 나타냅니다.

그는 또한 각주기가 시작될 때 프로토 타입을 조립하여 위험을 관리하기 때문에 프로토 타이핑 모델 접근 방식을 사용합니다.

또한 나선형의 반복은 최종 시스템이 구축되는 진화 수준으로 간주 될 수 있기 때문에 진화 모델과 호환됩니다.

단계

목표, 대안 및 제약 결정

시스템 요구 사항은 성능, 하드웨어 / 소프트웨어 인터페이스, 성공의 핵심 지표 등을 포함하여 최대한 자세히 정의됩니다. 현재 개발주기와 관련되어야하는 목표가 고려됩니다.

또한 구현을위한 다양한 대안 (예 : 빌드 대 기존 부품 구매, 재사용 또는 아웃소싱 등

마찬가지로 비용, 일정 및 인터페이스, 시간 소비 등과 같은 제한 사항이 결정됩니다.

위험 평가

제안 된 모든 대안이 평가됩니다. 목표와 제약은 최상의 솔루션을 선택하기위한 결정 기준 역할을합니다.

또한 경험 부족, 신기술, 빡빡한 일정, 프로세스 부족 등 프로젝트의 성공을 방해 할 수있는 위험을 식별하여 가장 낮은 위험으로 가장 수익성있는 전략을 구현합니다.

마지막으로 프로토 타이핑, 시뮬레이션, 분석 모델 및 사용자 설문 조사와 같은 방법이 사용됩니다.

개발 및 테스트

필요한 모든 개발은 기술과 선택된 솔루션을 사용하여 수행됩니다. 반복 할 때마다 더 나은 버전의 애플리케이션이 생성됩니다.

실제 코드는 원하는 결과에 도달 할 때까지 여러 번 작성되고 테스트되며, 이는 향후 개발 단계의 기반이 될 것입니다.

다음주기 계획

한주기가 완료되면 다음주기에 대한 계획이 시작됩니다. 이 계획은 다음 목표의 정의를 고려하여주기의 목표에 도달 한 경우 정상적으로 프로젝트를 계속할 수 있습니다.

이전 개발 단계에서 결함이있는 것으로 판명되면 다른 솔루션을 찾는 것도 가능합니다. 기존 전략은 이전에 정의 된 대안 중 하나 또는 새 전략으로 대체 될 수 있습니다. 이를 통해 주어진 목표를 달성하려는 새로운 시도가 시작됩니다.

예

미군은 미래 전투 시스템 (SCF) 현대화 프로그램의 개발 및 업그레이드를 위해 나선형 모델을 채택했습니다.

2003 년에 공식적으로 출시 된 SCF는 전장의 매우 빠르고 유연한 네트워크에 실시간으로 연결된 차량을 군대에 제공하도록 구상되었습니다.

이 프로젝트는 각각 약 2 년에 걸친 4 개의 개발 나선형으로 나뉘어졌습니다. Spiral 1은 2008 년에 시작되어 사용 및 평가를위한 프로토 타입을 제공 할 예정입니다.

Spiral 1이 완료된 후 Spiral 2는 2010 년에 시작될 예정입니다. 최종 제품 개발은 2015 년에 제공 될 예정입니다.

2005 년 8 월, Boeing은 시스템의 기능 개편 인 프로젝트의 첫 번째 주요 이정표의 완료를 발표했습니다. Boeing과 Science Applications International Corporation은 프로젝트의 공동 리더였습니다.

그러나 2005 년 10 월 미 국방부는 이라크 전쟁으로 인한 비용과 허리케인 카트리나의 원조에 대한 높은 영향으로 프로젝트를 연기 할 것을 권고했습니다.

이 프로젝트는 예산 삭감이 발생한 후 2009 년에 취소 되었으나이 임무에서 나선형 모델의 이점을 입증 할 수 없었습니다.

이점

순환 구조

이러한 유형의 구조로 인해주기적인 점검 덕분에 소프트웨어의 설계와 기술 요구 사항 사이의 문제가 암묵적으로 제거됩니다.

위기 관리

계속 진행하기 전에 제품의 각 단계에서 위험을 분석합니다. 이는 잠재적 인 위험을 극복하거나 완화하는 데 도움이됩니다.

모든 직원은이 모델에서 위험 분석의 중요성이 매우 크며 다른 프로세스 모델에 비해 가장 큰 이점을 얻을 수 있습니다.

정기적 인 위험 평가는 경험적 값이 없기 때문에 일반적으로 특정 위험 가능성과 관련된 새로운 기술 환경을 사용할 때 유용합니다.

고객 참여 및 피드백

고객은 프로젝트가 완료 될 때까지 프로젝트의 각 단계에 참여합니다. 따라서 프로젝트의 다음 버전을 개선하기 위해 다양한 피드백을 수집 할 수 있습니다.

또한 나선 모양의 전진으로 인해 언제든지 피드백을 얻을 수 있습니다. 따라서 고객과 사용자는 개발 프로세스의 처음부터 통합 될 수 있습니다.

대규모 프로젝트에 이상적

예산 통제가 클라이언트와 개발자의 우선 순위 인 크고 복잡한 프로젝트에서 특히 유명하고 두드러집니다. 소프트웨어 프로젝트의 비용, 리소스 및 품질을 최대한 제어 할 수 있습니다.

단점

비싼

위험 분석을 위해 높은 수준의 전문 지식이 필요하기 때문에 비용이 많이들 수 있습니다. 또한 프로젝트를 개발하는 데 많은 시간이 걸리므로 오버 헤드가 증가 할 수 있습니다.

상당히 복잡함

프로젝트의 매우 적극적이고 복잡한 사전 관리가 필요하며, 각주기는 지속적이고 신중하게 제어되고 문서화됩니다.

각기 다른 단계를 거치는 많은주기가 있으므로 문서화 프로세스의 노력이 증가하기 때문에 다른 모델보다 비교적 복잡합니다.

종종 사용할 수없는 위험 분석 및 관리에 대한 지식이 필수적입니다.

시간 관리

사이클 수를 알 수 없기 때문에 시간을 관리하기가 어렵습니다. 또한 한주기 내에 중요한 결정을 내려야하거나 다음주기를 계획 할 때 추가 조치를 취해야하는 경우 개발 프로세스가 언제든지 지연 될 수 있습니다.

많은 단계

테스트의 다양성에도 불구하고 프로그램의 미완성 부분이 완성 된 시스템에 도달 할 수 있기 때문에 소프트웨어 개발에서 많은 단계를 수행하는 것이 항상 유리한 것은 아닙니다.

결과적으로 개념적 오류나 불일치가 최종 제품에 영향을 미칠 위험이 항상 있습니다.

참고 문헌

1. 빅터 폰트 주니어 (2019). 나선형 모델. SDLC에 대한 궁극적 인 가이드. 출처 : ultimatesdlc.com.
2. 이오 노스 (2019). 나선형 모델 : 위험 중심 소프트웨어 개발 프로세스 모델. 출처 : ionos.com.
3. Techuz (2018). 나선형 모델이란? 나선형 소프트웨어 개발 수명주기 (SDLC)에 대한 간단한 설명. 출처 : techuz.com.
4. 원 스톱 테스트 (2020). 나선형 모델. 출처 : onestoptesting.com.
5. Geeks for Geeks (2020). 소프트웨어 엔지니어링-나선형 모델. 출처 : geeksforgeeks.org.
6. 찬두 (2019). 소프트웨어 공학의 나선형 모델. 출처 : medium.com.