실제로 많은 제품이 '빌드 후 수정' 모델을 사용하여 개발되며, 특히 제품 주기가 너무 짧은 소규모 회사에서 많이 사용됩니다. 이 모델에서는 사양이나 설계가 없으며 고객이 필요에 따라 소프트웨어를 계속 수정합니다.

이 모델에서는 개발자가 프로젝트를 받아 요구 사항에 따라 즉시 프로그램을 작성하고 디버깅하여 소프트웨어의 첫 번째 버전을 생성합니다. 사용자에게 제공한 후 프로그램에 버그가 있거나 사용자가 새로운 요구 사항을 제시하면 개발자는 사용자와 테스트가 모두 만족할 때까지 코드를 다시 수정합니다.

이것은 워크샵과 같은 개발 방식입니다. 진행하면서 모델을 수정하는 방식의 장점은 빠른 결과를 미리 확인할 수 있다는 것입니다.

너무 엄격한 로직이 필요하지 않은 소규모 프로그램에서는 처리할 수 있지만, 이 접근 방식은 모든 규모의 개발에는 만족스럽지 못합니다. 주요 문제점은 다음과 같습니다.

계획 및 설계 프로세스가 부족하고, 지속적인 수정으로 소프트웨어의 구조가 점점 더 나빠지고 계속 수정할 수 없으며,

요구 사항 프로세스를 무시하고 소프트웨어 개발에 많은 위험을 초래하며,

프로그램의 테스트 및 유지 보수성에 대한 고려가 없고 문서화가 전혀 없으며 소프트웨어의 유지 관리가 매우 어렵다는 점입니다.

2. 폭포수 모델

폭포수 모델은 1970년 윈스턴 로이스에 의해 제안된 오래된 소프트웨어 개발 모델로, 1980년대까지 널리 사용되던 모델입니다.

폭포수 모델은 소프트웨어 라이프사이클을 계획, 요구사항 분석, 소프트웨어 설계, 프로그래밍, 소프트웨어 테스트, 운영 및 유지관리의 6가지 기본 활동으로 나누고, 이러한 활동들이 폭포수처럼 단계적으로 떨어지는 고정된 순서를 위에서 아래로 제시합니다.

폭포수 모델에서는 소프트웨어 개발의 모든 활동이 엄격하게 선형적인 방식으로 수행되며, 현재 활동은 이전 활동의 작업 결과를 수용하고 필요한 것을 실현합니다. 현재 활동의 작업 결과는 검증을 거쳐야 합니다. 유효성 검사를 통과하면 그 결과가 다음 활동의 입력으로 사용되어 다음 활동으로 이어지고, 그렇지 않으면 수정됩니다.

폭포수 모델의 장점은 사전에 계획된 엄격한 단계 순서를 따르고 모든 것이 단계별로 더 엄격하게 진행된다는 것입니다.

폭포수 모델은 각 단계에서 신중하게 검증해야 하는 문서의 역할을 강조합니다. 그러나 이 모델의 선형적 프로세스는 현대 소프트웨어 개발 패러다임에 적합하지 않을 정도로 이상화되어 있으며 업계에서 거의 폐기되었습니다. 주요 문제점은 다음과 같습니다.

각 단계의 구분이 완전히 고정되어 있어 단계 간에 많은 양의 문서가 생성되어 작업량이 크게 증가하고,

개발 모델이 선형적이므로 사용자는 전체 프로세스가 끝날 때까지 개발 결과를 볼 수 없어 개발의 위험이 증가하며,

테스트 단계에서 개발 후반까지 초기 오류가 감지되지 않을 수 있습니다. 심각한 결과를 초래할 수 있습니다.

각 소프트웨어 라이프사이클을 통합하는 데 시간이 오래 걸리고 팀원들이 소통하는 데 비용이 많이 듭니다.

폭포수 접근 방식은 기본적으로 요구 사항을 알 수 없고 프로젝트 진행 중에 변경될 수 있는 경우 실현 불가능합니다.

3. 단계적 모델

단계적 모델(반복적 점진적 개발 또는 반복적 진화적 개발이라고도 함)은 전통적인 워터폴 개발과 비교되는 소프트웨어 개발 프로세스입니다. 기존 개발 방법의 몇 가지 약점을 보완하여 성공률과 생산성을 높입니다.

반복적 개발 접근 방식에서는 전체 개발 노력이 일련의 반복이라고 하는 일련의 짧은 고정 길이의 미니 프로젝트(예: 3주)로 구성됩니다. 각 반복에는 요구 사항 분석, 디자인, 구현 및 테스트가 포함됩니다. 이 접근 방식을 사용하면 요구 사항이 완전히 정의되기 전에 개발 작업을 시작할 수 있으며, 시스템 기능이나 비즈니스 로직의 일부를 한 번의 반복으로 개발할 수 있습니다. 그런 다음 고객의 피드백을 통해 요구 사항을 개선하고 새로운 반복을 시작합니다.

교육에서 반복과 버전의 차이는 다음과 같이 이해할 수 있습니다. 반복은 일반적으로 요구 사항 분석부터 테스트 완료까지를 포함한 버전의 생산 과정을 의미하며, 버전은 일반적으로 소프트웨어 개발의 특정 단계의 결과물인 인도 가능한 제품을 의미합니다.

반복 프로세스는 기존 워터폴 모델에 비해 다음과 같은 장점이 있습니다.

증분 지출의 위험을 줄입니다. 개발자가 반복을 반복할 경우 손실되는 것은 제대로 개발되지 않은 반복에 대한 비용뿐입니다.

제품이 정해진 일정에 따라 시장에 출시되지 못할 위험을 줄입니다. 개발 초기에 위험을 파악하면 개발 후반에 서두르지 않고 조기에 해결할 수 있습니다.

전체 개발 작업의 속도를 높입니다. 개발자는 문제의 핵심을 알기 때문에 생산성이 향상됩니다.

사용자 요구사항은 처음부터 완전히 정의할 수 없기 때문에 일반적으로 후속 단계에서 구체화됩니다. 따라서 이 반복적인 프로세스는 요구 사항의 변화에 더 잘 적응할 수 있도록 모델링됩니다. 따라서 재사용 가능성이 더 높습니다.

4. 신속 프로토타입 모델(신속 프로토타입 모델)

신속 프로토타입 모델(RPM)의 첫 단계는 고객 또는 미래의 사용자가 시스템과 상호작용할 수 있는 신속한 프로토타입을 구축하고, 사용자 또는 고객이 프로토타입을 평가하여 개발할 소프트웨어의 요구사항을 더욱 구체화하는 것입니다. 개발자는 고객의 요구 사항을 충족하도록 프로토타입을 점진적으로 조정함으로써 고객의 실제 요구 사항이 무엇인지 파악할 수 있으며, 두 번째 단계는 첫 번째 단계를 기반으로 고객이 만족할 수 있는 소프트웨어 제품을 개발하는 것입니다.

분명한 것은 래피드 프로토타이핑 방법은 워터폴 모델의 단점을 극복하고 불명확한 소프트웨어 요구 사항과 관련된 개발 위험을 줄이며 상당한 성과를 거둘 수 있다는 것입니다.

신속 프로토타이핑의 핵심은 가능한 한 빨리 소프트웨어 프로토타입을 구축하는 것입니다. 고객의 실제 요구 사항이 결정되면 구축된 프로토타입은 폐기됩니다. 따라서 프로토타이핑 시스템의 내부 구조는 중요하지 않습니다. 중요한 것은 프로토타입을 신속하게 구축한 다음 고객의 요구 사항을 반영하여 신속하게 수정해야 한다는 것입니다.

신속 프로토타이핑 모델은 '즉석 제작' 모델과 '폭포수' 모델의 장점을 결합한 것입니다.

5, 점진적 모델(증분 모델)

건물을 짓는 것처럼 소프트웨어는 단계적으로 구축됩니다. 점진적 모델에서 소프트웨어는 일련의 점진적 구성 요소로 설계, 구현, 통합 및 테스트되며, 각 구성 요소는 다양한 상호 작용 모듈로 구성된 특정 기능을 제공하는 코드 스니펫으로 구성됩니다.

증분 모델은 모든 단계에서 실행할 수 있는 완전한 제품을 제공하는 것이 아니라 고객의 요구 사항을 충족하는 데 사용할 수 있는 제품의 하위 집합을 제공합니다. 전체 제품을 구성 요소로 나누고 개발자가 하나씩 제품을 제공하는 방식입니다. 이 모델의 장점은 소프트웨어 개발이 변화에 더 잘 적응할 수 있고, 고객은 개발 중인 소프트웨어를 지속적으로 확인할 수 있어 개발 위험을 줄일 수 있다는 것입니다. 그러나 점진적 모델에는 다음과 같은 단점도 있습니다.

각 구성 요소가 기존 소프트웨어 아키텍처에 점진적으로 통합되기 때문에 이미 구축된 시스템의 일부를 방해하지 않는 구성 요소를 추가하는 것이 중요하므로 소프트웨어가 개방형 아키텍처를 가져야 합니다.

개발 과정에서 요구사항의 변경은 불가피합니다. 점진적 모델의 유연성으로 인해 워터폴 및 신속한 프로토타이핑 모델보다 이러한 변경 사항을 더 잘 수용할 수 있지만, 소프트웨어 프로세스 제어의 무결성을 잃는 즉석 제작 모델로 변질되는 경향도 있습니다.

증분 모델을 사용할 때 첫 번째 증분은 기본 요구 사항을 구현하는 핵심 제품인 경우가 많습니다. 핵심 제품이 사용자에게 전달된 후에는 핵심 제품의 수정 및 일부 새로운 기능 릴리스를 포함하여 다음 증분 개발 계획을 수립하기 위해 평가됩니다. 이 프로세스는 최종적으로 완벽한 제품이 생산될 때까지 각 점진적 릴리스 후에 반복됩니다.

예를 들어, 점진적 모델을 사용한 워드 프로세싱 소프트웨어 개발을 생각해 보겠습니다. 첫 번째 증분 릴리스는 기본적인 파일 관리, 편집 및 문서 생성 기능, 두 번째 증분 릴리스는 보다 정교한 편집 및 문서 생성 기능, 세 번째는 맞춤법 및 문법 검사 기능의 증분 구현, 네 번째는 고급 페이지 레이아웃 기능의 증분 완성이라고 생각할 수 있습니다.

6. 나선형 모델

1988년, 배리 뵘은 소프트웨어 시스템 개발을 위한 '나선형 모델'을 공식 발표했는데, 이는 폭포수 모델과 신속한 프로토타이핑 모델을 결합하고 다른 모델에서 무시된 위험 분석을 강조하며 특히 크고 복잡한 시스템에 적합합니다.

나선형 모델은 여러 번 반복되는 나선형을 따르며 다이어그램의 네 사분면은 다음 활동을 나타냅니다.

계획: 소프트웨어 목표 정의, 구현 계획 선택, 프로젝트 개발의 제약 조건 정의,

위험 분석: 선택한 솔루션을 분석 및 평가하고 위험을 식별 및 제거하는 방법 고려,

프로젝트 수행: 소프트웨어의 개발 수행과 및 검증

고객 평가: 개발 작업을 평가하고, 변경 사항을 제안하며, 다음 단계를 공식화합니다.

나선형 모델은 위험 중심적이며 소프트웨어 재사용을 지원하는 대안과 제약 조건을 강조하고 소프트웨어 품질을 특별한 목표로 제품 개발에 통합하는 데 도움이 됩니다. 그러나 나선형 모델에는 다음과 같은 몇 가지 한계가 있습니다.

나선형 모델은 위험 분석을 강조하지만 많은 고객이 이 분석을 수용하고 믿고 이에 반응하도록 하는 것은 쉽지 않습니다. 따라서 이 모델은 일반적으로 사내에서 대규모 소프트웨어를 개발할 때 적합합니다.

위험 분석을 수행하면 프로젝트의 수익성에 큰 영향을 미칠 수 있는 경우에는 위험 분석을 수행하는 것이 합리적이지 않습니다. 따라서 나선형 모델은 대규모 소프트웨어 프로젝트에만 적합합니다.

소프트웨어 개발자는 발생 가능한 위험을 식별하고 정확하게 분석하는 데 능숙해야 하며, 그렇지 않으면 더 큰 위험을 초래할 수 있습니다.

단계는 해당 단계의 목표, 목표 달성을 위한 옵션 및 제약 조건을 정의한 다음 위험 관점에서 프로그램의 개발 전략을 분석하여 가능한 한 많은 잠재적 위험을 제거하기 위해 노력하고 때로는 프로토타입을 구축하는 것으로 시작됩니다. 일부 위험을 제거할 수 없는 경우 프로그램을 즉시 종료하고, 그렇지 않은 경우 다음 개발 단계를 시작합니다. 마지막으로 이 단계의 결과를 평가하고 다음 단계를 설계합니다.

7. 애자일 소프트웨어 개발(애자일 개발)

애자일 개발은 인간 중심의 반복적인 단계별 개발 접근 방식입니다. 애자일 개발에서는 소프트웨어 프로젝트의 구성이 하위 프로젝트로 나뉘며, 각 프로젝트는 테스트되고 통합되며 실행 가능한 기능으로 구성됩니다. 즉, 대규모 프로젝트는 상호 연관성이 있지만 독립적으로 운영될 수 있는 여러 개의 작은 프로젝트로 나뉘며, 소프트웨어는 프로세스 중에 항상 사용할 수 있습니다.

애자일 개발 팀의 주요 작업 방식은 다음과 같이 요약할 수 있습니다. 총체적으로 작업하기, 짧은 반복 주기로 작업하기, 각 반복에서 일부 결과 제공, 비즈니스 우선순위에 집중하기, 점검 및 조정하기.

애자일 소프트웨어 개발은 프로젝트 규모, 성장 규모, 팀 커뮤니케이션 비용에주의를 기울여야하므로 애자일 소프트웨어 개발은 일시적으로 팀 규모에 적합하며 특히 대규모 팀 개발이 아니며 팀 그룹에 더 적합합니다.

8. 진화 모델

주로 요구 사항을 사전에 완전히 정의할 수 없는 소프트웨어 개발에 적합합니다. 사용자는 개발할 시스템의 핵심 요구 사항을 제공하고, 핵심 요구 사항의 구현을 확인하면 시스템의 최종 설계 및 구현을 지원하기 위해 효과적으로 피드백을 제공 할 수 있습니다. 소프트웨어 개발자는 먼저 사용자의 요구 사항을 기반으로 핵심 시스템을 개발합니다. 핵심 시스템이 가동된 후 사용자는 이를 사용해보고 작업을 완료한 후 시스템을 개선하고 기능을 향상시킬 필요성을 제시합니다. 소프트웨어 개발자는 사용자 피드백을 기반으로 반복적인 개발 프로세스를 구현합니다. 첫 번째 반복 프로세스는 전체 시스템의 정의 가능하고 관리 가능한 하위 집합을 추가하는 요구 사항, 디자인, 코딩, 테스트 및 통합 단계로 구성됩니다.

개발 모델에서는 배치 주기 개발 접근 방식이 사용되며, 각 주기는 해당 제품 프로토타입의 새로운 기능이 되는 기능의 일부를 개발합니다. 결과적으로 설계는 지속적으로 새로운 시스템으로 진화합니다. 사실상 이 모델은 반복적으로 실행되는 여러 개의 "폭포수 모델"로 생각할 수 있습니다.

"진화 모델"을 사용하려면 개발자가 프로젝트의 제품 요구 사항을 일괄 재활용을 위해 그룹으로 분해할 수 있는 능력이 있어야 합니다. 이 그룹화는 절대적으로 무작위적인 것이 아니며 기능의 중요도와 전체 디자인 인프라에 미치는 영향을 기준으로 판단해야 합니다. 각 개발 주기마다 6~8주 정도의 적절한 기간이 필요합니다.

9. 분수 모델(객체 지향 라이프사이클 모델, 객체 지향(OO) 모델))

분수 모델은 기존의 구조화된 라이프사이클보다 점진적이고 반복적이며, 라이프사이클의 각 단계가 겹치고 여러 번 반복될 수 있고 하위 라이프가 프로젝트의 전체 라이프사이클에 포함될 수 있는 특징이 있습니다. 위에 뿌린 물이 떨어질 수 있는 것처럼 중간이나 바닥에 떨어질 수 있습니다.

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

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

11. 하이브리드 모델

프로세스 개발 모델은 하이브리드 모델 또는 메타 모델이라고도 합니다. 여러 가지 다른 모델을 하이브리드 모델로 결합하여 프로젝트가 가장 효율적인 경로를 따라 개발될 수 있도록 합니다. 이것이 바로 프로세스 개발 모델(또는 하이브리드 모델)입니다. 실제로 일부 소프트웨어 개발 회사에서는 여러 가지 개발 방법을 사용하여 자체적인 하이브리드 모델을 구성하기도 합니다.