일반적인 소프트웨어 개발 모델은 무엇입니까?

일반적인 소프트웨어 개발 모델에는 다음이 포함됩니다. 1. 모델 수행 중 수정 3. 신속한 프로토타이핑 모델 5. 나선형 모델 7. 하이브리드 모델 9. RUP 모델 10. IPD 모델.

이 튜토리얼의 운영 환경: Windows 10 시스템, Dell G3 컴퓨터.

일반적인 소프트웨어 개발 모델은 다음과 같습니다.

1. Build-and-Fix 모델

불행히도 많은 제품이 "Build-and-Fix" 모델을 사용하여 개발됩니다. 이 모델에는 사양도 디자인도 없고 고객이 필요로 할 때마다 소프트웨어가 계속해서 수정됩니다. 이 모델에서는 개발자가 프로젝트를 받고 요구 사항에 따라 즉시 프로그램을 작성하며, 디버깅 후 소프트웨어의 첫 번째 버전이 생성됩니다. 사용자에게 제공된 후 프로그램에 오류가 발생하거나 사용자가 새로운 요구사항을 제시하는 경우 개발자는 사용자가 만족할 때까지 코드를 다시 수정합니다. 이는 워크샵과 같은 개발 방법으로 수백 줄의 작은 프로그램을 작성하는 데는 적합하지만 어떤 규모의 개발에도 이 방법은 만족스럽지 않습니다. 주요 문제는 다음과 같습니다.

( 1) 계획 및 설계 링크가 부족합니다. 지속적인 수정으로 인해 소프트웨어 구조가 악화되어 계속 수정이 불가능합니다.

(2) 수요 링크를 무시하면 소프트웨어 개발에 큰 위험이 발생합니다.

(3) 테스트 및 프로그램의 유지 관리 가능성을 고려하지 않고, 문서가 없으면 소프트웨어 유지 관리가 매우 어렵습니다.

2. 폭포수 모델

1970년에 윈스턴 로이스는 유명한 "폭포수 모델"을 제안했는데, 이는 1980년대 초반까지 널리 채택된 유일한 소프트웨어 개발 모델이었습니다. 폭포수 모델에서는 그림과 같이 소프트웨어 수명주기를 기획, 수요분석, 소프트웨어 설계, 프로그램 작성, 소프트웨어 테스트, 운영 및 유지보수 등 6가지 기본 활동으로 구분하고, 이들의 하향식 및 상호 연결된 활동은 다음과 같다. 폭포처럼 일정한 순서로 단계별로 떨어지는 것입니다. 폭포수 모델에서는 소프트웨어 개발의 다양한 활동이 엄격하게 선형 방식으로 수행됩니다. 현재 활동은 이전 활동의 작업 결과를 수용하고 필요한 작업 내용을 구현합니다. 현재 활동의 작업 결과를 검증해야 하며, 검증에 통과하면 그 결과는 다음 활동의 입력으로 사용되고 그렇지 않으면 수정을 위해 반환됩니다. 폭포수 모델은 문서화의 역할을 강조하며 각 단계에서 세심한 검증이 필요합니다. 그러나 이 모델의 선형 프로세스는 너무 이상적이며 더 이상 최신 소프트웨어 개발 모델에 적합하지 않습니다. 업계에서 거의 폐기되었습니다. 주요 문제점은 다음과 같습니다.

(1) 각 단계의 구분이 완전히 고정되어 있습니다. 그리고 단계 사이에 많은 문제가 발생하여 작업량이 크게 증가합니다.

(2) 개발 모델이 선형이므로 사용자는 전체 프로세스가 끝날 때까지만 개발 결과를 볼 수 있으므로 개발 위험이 높아집니다. ;

(3) 초기 오류가 발생할 수 있습니다. 개발 후반 단계의 테스트 단계까지는 발견할 수 없으며 이는 심각한 결과를 초래할 수 있습니다.

우리는 "선형"이 사람들이 능숙하게 숙달하고 적용할 수 있는 가장 쉬운 사고 방식이라는 것을 깨달아야 합니다. 사람들은 복잡한 '비선형' 문제에 직면할 때 항상 최선을 다해 이를 일련의 간단한 선형 문제로 분해하거나 변환한 다음 하나씩 해결하려고 노력합니다. 소프트웨어 시스템 전체는 복잡할 수 있지만 단일 서브루틴은 항상 단순하고 선형 방식으로 구현될 수 있습니다. 그렇지 않으면 작업이 너무 피곤해집니다. 선형성은 일종의 단순함이며 단순성은 아름다움입니다. 선형성의 정신을 이해할 때 우리는 더 이상 선형 모델의 외형을 엄격하게 적용할 것이 아니라 이를 활용해야 합니다. 예를 들어, 증분형 모델은 본질적으로 분할된 선형 모델인 반면 나선형 모델은 연속적인 곡선형 선형 모델입니다. 선형 모델의 그림자는 다른 모델에서도 찾을 수 있습니다.

3. 신속한 프로토타입 모델

신속한 프로토타입 제작 모델의 첫 번째 단계는 고객이나 미래의 사용자가 시스템과 상호 작용할 수 있도록 프로토타입을 평가하고 요구 사항을 자세히 설명하는 것입니다. 소프트웨어가 개발되려면. 고객의 요구 사항에 맞게 프로토타입을 점진적으로 조정함으로써 개발자는 고객의 실제 요구 사항이 무엇인지 결정할 수 있으며, 두 번째 단계는 고객을 만족시키는 소프트웨어 제품을 개발하는 첫 번째 단계를 기반으로 합니다. 분명히 신속한 프로토타이핑 방법은 폭포 모델의 단점을 극복하고 불분명한 소프트웨어 요구 사항으로 인한 개발 위험을 줄일 수 있으며 상당한 효과를 가지고 있습니다. 신속한 프로토타입 제작의 핵심은 가능한 한 빨리 소프트웨어 프로토타입을 구축한 다음 고객의 실제 요구 사항이 결정되면 해당 프로토타입을 폐기하는 것입니다. 따라서 프로토타입 시스템의 내부 구조는 중요하지 않습니다. 중요한 것은 고객의 요구 사항을 반영하여 신속하게 프로토타입을 제작하고 수정해야 한다는 것입니다.

4. 증분 모델

증분 모델은 진화 모델이라고도 합니다. 건물을 짓는 것처럼 소프트웨어도 단계별로 만들어집니다. 증분 모델에서 소프트웨어는 일련의 증분 구성 요소로 설계, 구현, 통합 및 테스트됩니다. 각 구성 요소는 여러 상호 작용 모듈로 구성된 특정 기능을 제공하는 코드 조각으로 구성됩니다. 증분 모델은 각 단계에서 실행 가능한 완전한 제품을 제공하는 것이 아니라 고객 요구 사항을 충족하는 실행 가능한 제품의 하위 집합을 제공합니다. 전체 제품이 여러 개의 구성요소로 분해되어 개발자가 구성요소별로 제품 구성요소를 전달하는 방식의 장점은 소프트웨어 개발이 변화에 더 잘 적응할 수 있고, 고객이 개발된 소프트웨어를 지속적으로 볼 수 있어 개발 위험이 줄어든다는 점입니다. 그러나 증분 모델에는 다음과 같은 결함도 있습니다.

(1) 각 구성 요소는 기존 소프트웨어 아키텍처에 점진적으로 통합되므로 구성 요소를 추가해도 이미 구성된 시스템 부분을 파괴해서는 안 되며, 이를 위해서는 소프트웨어가 개방형 아키텍처여야 합니다.

(2) 개발 과정에서 요구 사항의 변경은 불가피합니다. 증분 모델의 유연성으로 인해 폭포 모델 및 신속한 프로토타이핑 모델보다 이러한 변화에 훨씬 더 잘 적응할 수 있지만, 이를 수행하는 동안 수정되는 모델로 쉽게 변질될 수 있으므로 소프트웨어 프로세스의 제어가 불가능합니다. 성실성을 잃습니다. 증분 모델을 사용할 때 첫 번째 증분은 기본 요구 사항을 충족하는 핵심 제품인 경우가 많습니다. 핵심 제품이 사용자에게 전달된 후 평가를 거쳐 다음 증분 개발 계획이 형성됩니다. 여기에는 핵심 제품 수정 및 일부 새로운 기능 출시가 포함됩니다. 이 프로세스는 최종 광택 제품이 생산될 때까지 각 증분 출시 이후 반복됩니다. 예를 들어 증분 모델을 사용하여 워드 프로세싱 소프트웨어를 개발합니다. 첫 번째 증분은 기본 파일 관리, 편집 및 문서 생성 기능을 출시하고, 두 번째 증분은 보다 완전한 편집 및 문서 생성 기능을 출시하며, 세 번째 증분은 맞춤법 및 문법 검사 기능을 구현하고, 네 번째 증분은 맞춤법 및 문법 검사 기능을 구현한다고 볼 수 있습니다. 기능을 점진적으로 완성하는 고급 페이지 레이아웃 기능입니다.

5. 나선형 모델

1988년 Barry Boehm은 폭포 모델과 신속한 프로토타이핑 모델을 결합하여 다른 모델에서 무시되는 위험을 강조하는 소프트웨어 시스템 개발의 "나선형 모델"을 공식 발표했습니다. 크고 복잡한 시스템. 그림에 표시된 것처럼 나선형 모델은 나선형을 따라 여러 번의 반복을 거칩니다. 그림의 4개 사분면은 다음 활동을 나타냅니다.

(1) 계획 수립: 소프트웨어 목표 결정, 구현 계획 선택 및 제한 사항 명확화

(2) 위험 분석: 선택한 옵션을 분석 및 평가하고, 위험을 식별하고 제거하는 방법을 고려합니다.

(3) 구현 엔지니어링: 소프트웨어 개발 및 검증을 구현합니다. 개발 작업을 평가하고, 제안을 수정하고, 다음 단계를 공식화합니다. 나선형 모델은 위험 중심적이며, 소프트웨어 재사용을 지원하기 위한 대안과 제약 조건을 강조하고, 소프트웨어 품질을 특별한 목표로 제품 개발에 통합하는 데 도움이 됩니다. 그러나 나선형 모델에는 다음과 같은 몇 가지 제한 사항이 있습니다.

(1) 나선형 모델은 위험 분석을 강조하지만 많은 고객이 이 분석을 받아들이고 믿고 적절한 대응을 하는 것이 쉽지 않습니다. 따라서 이 모델은 종종 채택됩니다. 내부 대규모 소프트웨어 개발에

(2) 위험 분석 수행이 프로젝트 수익에 큰 영향을 미치는 경우 위험 분석 수행은 의미가 없습니다. 따라서 나선형 모델은 대규모 소프트웨어 프로젝트에만 적합합니다.

(3) 소프트웨어 개발자는 가능한 위험을 찾아내고 위험을 정확하게 분석하는 데 능숙해야 합니다. 그렇지 않으면 더 큰 위험이 초래됩니다. 단계에서는 먼저 단계의 목표, 이러한 목표를 완료하기 위한 옵션 및 제약 조건을 결정한 다음 위험 관점에서 프로그램의 개발 전략을 분석하고 때로는 프로토타입을 구축하여 다양한 잠재적 위험을 제거하려고 노력합니다. 특정 위험을 제거할 수 없는 경우 프로그램이 즉시 종료되고, 그렇지 않은 경우 다음 개발 단계가 시작됩니다. 마지막으로 이 단계의 결과를 평가하고 다음 단계를 설계합니다.

6. 분수 모델(fountain model)

분수 모델(객체 지향 수명 모델, OO 모델이라고도 함) 전통적인 구조의 수명에 비해 분수 모델은 더 많은 증분과 반복 특성을 가지며 수명의 다양한 단계를 수행합니다. 수명주기는 여러 번 중복되고 반복될 수 있으며, 하위 수명 기간도 프로젝트 수명주기 전반에 걸쳐 포함될 수 있습니다. 물이 위로 솟아올랐다가 다시 아래로 떨어지는 것처럼, 가운데로 떨어질 수도 있고 바닥으로 떨어질 수도 있습니다.

7. 지능형 모델(4세대 기술(4GL))

지능형 모델에는 일련의 도구(예: 데이터 쿼리, 보고서 생성, 데이터 처리, 화면 정의, 코드 생성, 고급 그래픽 기능 및 스프레드시트 등)가 있습니다. 각 도구를 사용하면 개발자가 소프트웨어의 특정 측면을 정의할 수 있습니다. 높은 수준에서 기능을 제공하고 개발자가 정의한 소프트웨어에 대한 소스 코드를 자동으로 생성합니다. 이 접근 방식에는 4GL(4세대 언어) 지원이 필요합니다. 4GL은 3세대 언어와는 달리 사용자 인터페이스가 매우 친숙하며, 훈련을 받지 않은 비전문 프로그래머도 이를 사용하여 프로그램을 작성할 수 있다는 점입니다. 4GL은 또한 효율적인 프로그램 코드, 지능형 기본 가정, 완전한 데이터베이스 및 애플리케이션 생성기를 갖추고 있습니다. 현재 시장에 나와 있는 인기 있는 4GL(예: Foxpro 등)은 모두 위의 특성을 다양한 수준으로 가지고 있습니다. 그러나 현재 4GL은 거래 정보 시스템을 위한 중소 규모 애플리케이션 개발에만 주로 제한되어 있습니다.

8. 하이브리드 모델

하이브리드 모델(하이브리드 모델) 프로세스 개발 모델은 하이브리드 모델(하이브리드 모델) 또는 여러 가지 모델을 하나로 결합한 메타 모델(메타 모델)이라고도 합니다. 프로젝트가 가장 효율적인 경로를 따라 개발될 수 있도록 하는 것이 프로세스 개발 모델(또는 하이브리드 모델)입니다. 실제로 일부 소프트웨어 개발 조직에서는 여러 가지 개발 방법을 사용하여 자체 하이브리드 모델을 형성합니다. 다양한 모델의 비교 각 소프트웨어 개발 조직은 조직에 적합한 소프트웨어 개발 모델을 선택해야 하며, 선택한 모델의 단점을 줄이고 장점을 최대한 활용하기 위해 현재 개발 중인 특정 제품 기능에 맞게 변경해야 합니다. 표에는 여러 일반적인 모델의 장점과 단점이 나열되어 있습니다. 다양한 모델의 장단점: 모델 장점 단점 폭포수 모델 문서 중심 시스템은 고객 요구 사항을 충족하지 못할 수 있음 신속한 프로토타입 모델 고객 요구 사항 충족에 초점을 맞추면 시스템 설계가 불량해지고 비효율성이 높아지며 유지 관리가 어려워짐 증분 모델 개발 초기 피드백이 시의적절하고 시기적절함 유지 관리가 쉬움 개방형 아키텍처가 필요하며 잘못 설계되고 비효율적일 수 있습니다. 나선형 모델 위험 중심 위험 분석가는 경험이 풍부하고 충분한 교육을 받아야 합니다

9. RUP 모델(반복 모델)

RUP(Rational Unified Process) ) 모델은 Rational 회사에서 제안하는 일련의 개발 프로세스 모델로, 객체지향 소프트웨어 엔지니어링을 위한 일반적인 비즈니스 프로세스입니다. 동일한 구조, 즉 동일한 프로세스 아키텍처를 갖는 일련의 관련 소프트웨어 엔지니어링 프로세스를 설명합니다. RUP는 최종 사용자 요구 사항을 충족하는 고품질 소프트웨어가 예측 가능한 일정과 예산 내에서 개발되도록 보장하기 위해 개발 조직 내에서 작업과 책임을 할당하기 위한 표준화된 방법을 제공합니다. RUP에는 두 개의 축이 있는데, 그 중 하나는 동적 타임라인입니다. 다른 축은 정적 워크플로우 축입니다. 타임라인에서 RUP는 초기 단계, 개선 단계, 구성 단계 및 릴리스 단계의 네 단계로 나뉩니다. 반복의 개념은 각 단계에서 사용됩니다. 워크플로 축에서 RUP는 6개의 핵심 워크플로와 3개의 핵심 지원 워크플로를 설계했습니다. 핵심 워크플로 축에는 비즈니스 모델링 워크플로, 요구 사항 워크플로, 분석 및 설계 워크플로, 구현 워크플로, 테스트 워크플로 및 게시 워크플로가 포함됩니다. 핵심 지원 워크플로에는 환경 워크플로, 프로젝트 관리 워크플로, 구성 및 변경 관리 워크플로가 포함됩니다. RUP는 현대 소프트웨어 개발의 모범 사례를 통합하고 다양한 프로젝트 및 조직의 요구에 맞는 유연한 형식을 제공합니다. 비즈니스 모델로서 매우 상세한 프로세스 지침과 템플릿이 있습니다. 그러나 모델이 상대적으로 복잡하기 때문에 모델을 마스터하는 데 상대적으로 많은 비용이 필요합니다. 특히 프로젝트 관리자에 대한 요구가 상대적으로 높습니다.

(1) 증분 반복, 각 반복은 초기 단계에서 위험을 제어하고 해결하기 위해 폭포수 모델을 따릅니다.

(2) 모델의 복잡성으로 인해 프로젝트 관리자는 강력한 관리 능력이 필요합니다.

10.IPD 모델

IPD(통합 제품 개발) 프로세스는 IBM이 제안한 통합 제품 개발 프로세스 집합으로, 특히 소프트웨어와 하드웨어가 결합된 프로젝트에 매우 적합합니다. . IPD는 제품 전체의 관점에서 시작하여 시스템 엔지니어링, 연구개발(하드웨어, 소프트웨어, 구조산업설계, 테스팅, 데이터 개발 등), 제조, 금융, 마케팅, 조달, 구매 등 모든 프로세스를 종합적으로 고려하는 프로세스입니다. 기술지원 등 이는 엔드투엔드 프로세스입니다. IPD 프로세스는 6단계(개념 단계, 기획 단계, 개발 단계, 검증 단계, 릴리스 단계, 라이프사이클 단계)로 구분되며, 4개의 결정 검토 지점(개념 단계 결정 검토 지점, 계획 단계 결정 검토 지점, 가용성 결정 검토 지점) 포인트 및 수명 종료 결정 검토 포인트) 및 6개의 기술 검토 포인트를 제공합니다. IPD 프로세스는 폭포 모델의 그림자가 있는 단계적 모델입니다. 이 모델은 포괄적이고 복잡한 프로세스를 사용하여 크고 복잡한 시스템을 세분화하고 위험을 줄입니다. 이 모델은 어느 정도 전체 제품의 품질을 개선하고 시장 점유율을 높이기 위해 공정 비용을 사용합니다. 이 프로세스는 프로세스 롤백을 위한 메커니즘을 정의하지 않으므로 요구 사항이 자주 변경되는 프로젝트에는 적합하지 않습니다. 그리고 일부 소규모 프로젝트의 경우 이 프로세스는 그다지 적합하지 않습니다.

추천 학습: PHP 중국어 웹사이트

위 내용은 일반적인 소프트웨어 개발 모델은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!