전통문화대전망 - 전통 미덕 - 폭포 모델이란 무엇입니까?
폭포 모델이란 무엇입니까?
소프트웨어 개발 모델은 소프트웨어 개발의 전 과정을 명확하고 직관적으로 표현하고, 완료할 주요 활동과 작업을 명확하게 정의하며, 소프트웨어 프로젝트 작업의 기초로 사용할 수 있습니다.
가장 초기의 소프트웨어 개발 모델은 1970 에서 W Royce 가 제안한 폭포 모델입니다. 모델은 고정된 순서를 제공합니다. 라이프 사이클 활동은 흐르는 물처럼 이전 단계에서 다음 단계로 점진적으로 전환되어 결국 개발된 소프트웨어 제품을 얻어서 사용할 수 있게 됩니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 그러나 계산이 통계 분석, 비즈니스 등으로 확장될 때 대부분의 프로그램은 고급 언어 (예: FORTRAN, COBOL) 로 작성됩니다. 폭포수 모형에도 유연성이 부족하여 동시활동을 통해 정확하지 않은 수요를 설명할 수 없는 단점이 있다. (윌리엄 셰익스피어, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포)
전형적인 개발 모델은 다음과 같습니다. ① 폭포 모델; ② 증분 모델/진화/반복; (3) 프로토 타입 모델; ④ 나선형 모델; ⑤ 분수 모델; ⑥ 지능형 모델; 7. 혼합 모델
1. 모델을 만들고 복구합니다.
불행히도, 많은 제품들은' 하면서 고치는' 모델을 이용하여 개발되었다. 이 모드에서는 사양도 설계도 없고, 고객의 요구에 따라 소프트웨어가 끊임없이 수정됩니다.
이 모드에서는 개발자가 프로젝트를 받은 직후 필요에 따라 프로그램을 작성하고 디버깅 후 소프트웨어의 첫 번째 버전을 생성합니다. 사용자에게 제공한 후 프로그램에 오류가 발생하거나 사용자가 새로운 요구를 하면 개발자는 사용자가 만족할 때까지 코드를 다시 수정합니다.
이것은 수백 줄의 작은 프로그램을 쓰는 데는 괜찮지만, 어떤 규모의 개발에도 만족스럽지 못한 개발 방법이다. (윌리엄 셰익스피어, 윈스턴, 과학명언) 주요 문제는 다음과 같습니다.
(1) 계획 설계 단계가 부족하여 소프트웨어의 구조가 끊임없이 수정됨에 따라 더 이상 수정할 수 없습니다.
(2) 수요 링크를 무시하면 소프트웨어 개발에 큰 위험을 초래합니다.
(3) 테스트 및 프로그램의 서비스 가능성에 관계없이 문서가 없으면 소프트웨어를 유지 관리하기가 매우 어렵습니다.
2. 폭포 모델
윈스턴 로이스 (WinSTon Royce) 는 1970 에서 유명한 폭포 모델을 제시했고, 1980 년대 초까지만 해도 널리 사용되는 유일한 소프트웨어 개발 모델이었다.
폭포수 모델은 소프트웨어 수명주기를 계획, 수요 분석, 소프트웨어 설계, 프로그래밍, 소프트웨어 테스트 및 운영 차원의 6 가지 기본 활동으로 나누고 폭포처럼 단계적으로 떨어지는 고정 순서를 하향식으로 지정합니다.
폭포수형 모델에서는 소프트웨어 개발의 모든 활동이 엄격하게 선형적으로 진행되며, 현재 활동은 이전 활동의 작업 결과를 받아들이고 필요한 작업 내용을 달성합니다. 현재 활성 작업 결과를 확인해야 합니다. 검증을 통과하면 결과는 다음 활동에 대한 입력으로 다음 활동을 계속합니다. 그렇지 않으면 수정됩니다.
폭포수 모델은 문서의 역할을 강조하며 각 단계에서 세심한 검증이 필요합니다. 하지만 이 모델의 선형 과정은 지나치게 이상화되어 현대 소프트웨어 개발 모델에 적합하지 않아 업계에 거의 버려지고 있다. 주요 문제는 다음과 같습니다.
(1) 각 단계의 분할은 완전히 고정되어 있으며 단계 간에 대량의 문서가 생성되어 작업량이 크게 증가합니다.
(2) 개발 모델이 선형이기 때문에 사용자는 전체 프로세스가 끝날 때까지 개발 결과를 볼 수 없으며 개발 위험이 증가합니다.
(3) 초기 오류는 개발 후기의 테스트 단계까지 발견되지 않을 수 있어 심각한 결과를 초래할 수 있다.
"선형" 이 가장 쉽게 익히고 능숙하게 운용할 수 있는 사고방식이라는 것을 깨달아야 한다. 사람들이 복잡한 "비선형" 문제에 직면했을 때, 항상 그것을 분해하거나 일련의 간단한 선형 문제로 변환한 다음 하나씩 해결하려고 노력한다. 소프트웨어 시스템의 전체는 복잡할 수 있지만, 단일 서브루틴은 항상 간단하며 선형으로 구현할 수 있습니다. 그렇지 않으면 피곤해서 작동하지 않을 수 있습니다. 선형은 간단하고, 단순함은 아름다움이다. 선형 정신을 이해할 때 선형 모델의 모양을 기계적으로 적용하는 대신 생동감 있게 사용합니다. 예를 들어 증분 모델은 본질적으로 세그먼트 선형 모델이고 나선형 모델은 연속 곡선 선형 모델이며 다른 모델에서도 선형 모델의 그림자를 찾을 수 있습니다.
3. rapid prototyping 모델 (rapid prototyping 모델)
Rapid Prototype 모델 (Rapid prototype model) 의 첫 번째 단계는 빠른 프로토타입을 구축하여 고객 또는 향후 사용자와 시스템 간의 상호 작용을 가능하게 하는 것입니다. 사용자 또는 고객은 프로토타입을 평가하여 개발할 소프트웨어의 요구를 더욱 구체화합니다. 개발자는 고객의 요구 사항에 맞게 프로토타입을 점진적으로 조정하여 고객의 실제 요구 사항이 무엇인지 결정할 수 있습니다. 두 번째 단계는 첫 번째 단계를 기반으로 고객이 만족하는 소프트웨어 제품을 개발하는 것입니다.
분명히, 신속한 프로토타입법은 폭포 모델의 단점을 극복하고, 소프트웨어 요구 사항이 명확하지 않은 개발 위험을 줄이며, 그 효과가 현저하다.
신속한 프로토타입 제작의 관건은 가능한 한 빨리 소프트웨어 프로토타입을 구축하는 것이다. 고객의 실제 요구 사항이 확인되면 제작된 프로토타입은 폐기됩니다. 따라서 프로토타입 시스템의 내부 구조는 중요하지 않습니다. 고객의 요구를 반영하기 위해 프로토타입을 신속하게 작성한 다음 신속하게 수정해야 합니다.
4. 증가 모델
건물을 짓는 것처럼, 소프트웨어는 차근차근 건설되었다. 증분 모델에서 소프트웨어는 다양한 상호 작용 모듈로 구성된 특정 기능을 제공하는 코드 조각으로 구성된 일련의 증분 구성 요소로 설계, 구현, 통합 및 테스트됩니다.
증분 모델은 각 단계에서 실행할 수 있는 전체 제품을 제공하는 것이 아니라 고객의 요구를 충족시킬 수 있는 제품의 하위 세트를 제공합니다. 전체 제품은 여러 구성 요소로 나뉘는데, 개발자는 하나씩 제품을 납품한다. 이렇게 하면 소프트웨어 개발이 변화에 더 잘 적응할 수 있고, 고객은 개발된 소프트웨어를 지속적으로 볼 수 있어 개발 위험을 줄일 수 있다는 장점이 있습니다. 그러나 증가 모델에도 다음과 같은 결함이 있습니다.
(1) 각 구성 요소가 기존 소프트웨어 아키텍처에 점진적으로 통합되므로 구성 요소를 추가해도 이미 구축된 시스템 부분을 파괴해서는 안 되므로 소프트웨어에 개방형 아키텍처가 필요합니다.
(2) 발전 과정에서 수요의 변화는 불가피하다. 증분 모델의 유연성을 통해 폭포수형 및 신속한 프로토타입 모델보다 이러한 변화에 적응하는 것이 훨씬 더 좋지만, 소프트웨어 프로세스 제어의 무결성을 잃기 위해 가장자리로 쉽게 퇴화할 수 있습니다. (존 F. 케네디, Northern Exposure (미국 TV 드라마), 스포츠명언)
증분 모델을 사용할 때 첫 번째 증분은 종종 기본 요구 사항을 충족하는 핵심 제품입니다. 핵심 제품이 사용자에게 제공되면 평가를 거쳐 핵심 제품 수정 및 몇 가지 새로운 기능 출시를 포함한 다음 단계의 증분 개발 계획을 수립합니다. 이 프로세스는 각 증분 출시 후 최종 완벽한 제품이 생산될 때까지 반복됩니다.
예를 들어 증분 모델을 사용하여 워드 프로세싱 소프트웨어를 개발합니다. 첫 번째 증분 게시 기본 파일 관리, 편집 및 문서 생성 기능, 두 번째 증분 게시 보다 정교한 편집 및 문서 생성 기능, 세 번째 증분은 맞춤법 및 구문 확인 기능, 네 번째 증분은 고급 페이지 레이아웃 기능을 완료합니다.
5. 나선형 모델
1988 년 Barry Boehm 은 폭포수 모델과 신속한 프로토타입 모델을 결합한 소프트웨어 시스템 개발의' 나선형 모델' 을 공식 발표했습니다. 특히 대규모 복잡한 시스템에 적합한 다른 모델에서 간과되는 위험 분석을 강조했습니다.
나선 모델은 나선을 따라 여러 번 반복되며 그림의 네 사분면은 다음 활동을 나타냅니다.
(1) 계획: 소프트웨어 목표 결정, 구현 시나리오 선택, 프로젝트 개발 제약 사항 파악
(2) 위험 분석: 선택한 시나리오를 분석하고 평가하여 위험을 식별하고 제거하는 방법을 고려합니다.
(3) 구현 프로젝트: 소프트웨어 개발 및 검증 구현
(4) 고객 평가: 개발 작업 평가, 수정 제안, 다음 계획 수립
나선형 모델은 위험 지향적이며 소프트웨어 재사용을 지원하는 대안과 제약을 강조하며 소프트웨어 품질을 제품 개발에 특수한 목표로 통합하는 데 도움이 됩니다. 그러나 나선형 모형에는 다음과 같은 몇 가지 제한 사항이 있습니다.
(1) 나선형 모델은 위험 분석을 강조하지만 많은 고객이 이러한 분석을 받아들이고 믿고 관련 반응을 보이는 것은 쉽지 않습니다. 따라서 이 모델은 일반적으로 내부의 대규모 소프트웨어 개발에 적합합니다.
(2) 위험 분석의 실행이 프로젝트의 이익에 큰 영향을 미칠 경우 위험 분석을 수행하는 것은 의미가 없습니다. 따라서 나선형 모델은 대형 소프트웨어 프로젝트에만 사용할 수 있습니다.
(3) 소프트웨어 개발자는 가능한 위험을 잘 파악하고 위험을 정확하게 분석해야 합니다. 그렇지 않으면 더 큰 위험을 초래할 수 있습니다.
첫 번째 단계는 단계의 목표를 결정하고, 이러한 목표의 선택 시나리오와 제약 조건을 달성한 다음, 위험의 관점에서 시나리오의 발전 전략을 분석하여 다양한 잠재적 위험을 최소화하는 것입니다. 때로는 프로토타입을 구축하는 것입니다. 일부 위험을 제거할 수 없는 경우 즉시 종료됩니다. 그렇지 않으면 다음 개발이 시작됩니다. 마지막으로 이 단계의 성과를 평가하고 다음 단계를 설계합니다.
6. 진화 모델
요구 사항을 미리 완전히 정의할 수 없는 소프트웨어 개발을 위한 것입니다. 사용자는 개발 중인 시스템의 핵심 요구 사항을 제공할 수 있으며 핵심 요구 사항의 구현을 볼 때 시스템의 최종 설계 및 구현을 지원하기 위해 피드백을 효과적으로 제공할 수 있습니다. 소프트웨어 개발자는 사용자의 요구에 따라 핵심 시스템을 먼저 개발합니다. 핵심 시스템이 가동된 후, 사용자가 시험해 보고, 작업을 완료하고, 시스템을 구체화하고, 시스템 기능을 향상시킬 필요성을 제시합니다. 소프트웨어 개발자는 사용자의 피드백을 기반으로 개발된 반복 프로세스를 구현합니다. 첫 번째 반복 프로세스는 요구 사항, 설계, 코딩, 테스트, 통합 등의 단계로 구성되며 전체 시스템에 정의 가능하고 관리 가능한 하위 집합을 추가합니다.
개발 모델에서는 대량 순환 개발 방법을 사용하여 각 순환 개발의 일부 기능을 해당 제품 원형의 새로운 기능으로 사용할 수 있습니다. 그래서 디자인은 새로운 시스템으로 진화하고 있습니다. 실제로 이 모델은 반복되는 여러 "폭포 모델" 으로 볼 수 있습니다.
진화 모델은 개발자가 프로젝트의 제품 요구 사항을 여러 그룹으로 분할하여 대량 재활용 개발을 수행할 수 있도록 해야 합니다. 이러한 그룹화는 절대적으로 무작위가 아니며 기능의 중요성과 전반적인 설계 인프라에 미치는 영향에 따라 판단해야 합니다. 경험에 따르면 각 개발 주기의 적절한 길이는 6 주에서 8 주입니다.
7. 분수 모델 (OO 모델))
분수 모형은 기존의 구조화된 수명 주기보다 더 많은 증분과 반복 특성을 가지고 있으며, 수명 주기의 각 단계는 여러 번 겹치고 반복될 수 있으며, 하위 수명 주기는 프로젝트의 전체 수명 주기에 포함될 수 있습니다. 위에 뿌려진 물이 떨어지는 것처럼 중간에 떨어지거나 바닥에 떨어질 수 있습니다.
8. 지능형 모델 (4 세대 기술 (4GL))
지능형 모델에는 데이터 쿼리, 보고서 생성, 데이터 처리, 화면 정의, 코드 생성, 고급 그래픽 기능 및 스프레드시트와 같은 도구 세트가 있습니다. ) 또한 각 도구를 통해 개발자는 소프트웨어의 일부 기능을 높은 수준에서 정의할 수 있으며, 이러한 개발자가 정의한 소프트웨어를 소스 코드로 자동 생성할 수 있습니다. 이 방법에는 4 세대 언어 지원 (4GL) 이 필요합니다. 4GL 은 3 세대 언어와 달리 사용자 인터페이스가 매우 친숙하기 때문에 숙련된 비전문가 프로그래머가 없어도 프로그램을 작성하는 데 사용할 수 있습니다. 선언적, 대화식 및 비절차적 프로그래밍 언어입니다. 4GL 에는 효율적인 프로그램 코드, 지능형 기본 가정, 전체 데이터베이스 및 응용 프로그램 생성기도 있습니다. 현재 4GL (FoXPro 등) 입니다. ) 시장에서 유행하는 것은 모두 다양한 정도로 이런 특징을 가지고 있다. 그러나 4GL 은 현재 주로 거래 정보 시스템의 중소형 애플리케이션 개발에 국한되어 있다.
9. 혼합 모델
프로세스 개발 모델은 혼합 모델 또는 메타 모델이라고도 합니다. 여러 개의 서로 다른 모델을 하나의 혼합 모델로 결합하여 프로젝트가 가장 효과적인 경로를 따라 발전할 수 있도록 합니다. 이것이 프로세스 개발 모델 (또는 혼합 모델) 입니다. 실제로 일부 소프트웨어 개발 회사는 여러 가지 다른 개발 방법을 사용하여 자체 혼합 모델을 형성합니다.
다양한 모델의 비교
각 소프트웨어 개발 조직은 해당 조직에 적합한 소프트웨어 개발 모델을 선택해야 하며, 현재 개발 중인 특정 제품 특성에 따라 변경되어야 선택한 모델의 단점을 줄이고 장점을 최대한 활용할 수 있습니다. 다음 표에는 몇 가지 일반적인 모델의 장점과 단점이 나열되어 있습니다.
모형
우세
열세
폭포수 모델 문서 중심 시스템은 고객의 요구를 충족하지 못할 수 있습니다.
신속한 원형 모델의 고객 요구 사항 충족에 대한 관심은 시스템 설계 불량, 비효율성 및 유지 관리에 어려움을 초래할 수 있습니다.
증분 모델 개발에 대한 초기 피드백은 시기적절하고 유지 관리가 용이하며 개방형 아키텍처가 필요합니다. 이로 인해 설계가 잘못되고 비효율적일 수 있습니다.
나선형 모델 위험 중심의 위험 분석가는 경험과 훈련이 필요합니다.