전통적인 폭포수 모델

전통적인 폭포수 모델

전통적인 폭포수 모델은 기본적인 소프트웨어 개발 수명 주기 모델이다. 폭포수 모델은 매우 간단하지만 이상적이다. 이전에 이 모델은 매우 인기가 있었지만 요즘은 사용되지 않는다. 그러나 다른 모든 소프트웨어 개발 수명 주기 모델은 전통적인 폭포수 모델을 기반으로 하기 때문에 매우 중요하다.

전통적인 폭포수 모델은 수명 주기를 일련의 단계로 나눈다. 폭포수 모델은 이전 단계가 완료된 후 다음 단계를 시작할 수 있다고 간주한다. 즉, 한 단계의 산출물이 다음 단계의 입력이 된다. 따라서 개발 과정은 폭포의 순차적 흐름으로 간주될 수 있다. 여기서 각 단계는 서로 겹치지 않는다.

전통적인 폭포수 모델의 다양한 순차적 단계는 아래 그림과 같다.

전통적인 폭포수 모델

각 단계는 다음과 같다.

1. 타당성 조사

이 단계에서는 소프트웨어를 개발하는 것이 재정적, 기술적으로 실현 가능한지 여부를 결정하는 것이다.
타당성 조사는 문제를 이해한 후 문제를 해결하기 위해 가능한 다양한 전략을 결정하는 것을 포함한다. 이러한 다양한 식별된 솔루션은 장점과 단점을 기반으로 분석한다. 최상의 솔루션이 선택되고 다른 모든 단계는 이 솔루션 전략에 따라 수행된다.

2. 요구사항 분석 및 명세

요구사항 분석 및 명세 단계의 목표는 고객의 정확한 요구사항을 이해하고 적절히 문서화하는 것이다. 이 단계는 두 가지 다른 활동으로 구성됩니다.

• 요구사항 수집 및 분석: 먼저 고객으로부터 소프트웨어와 관련된 모든 요구 사항을 수집한 다음 수집된 요구 사항을 분석한다. 분석의 목적은 불완전성(불완전한 요구사항은 실제 요구사항의 일부가 누락된 요구사항)과 불일치성(불일치한 요구사항은 요구사항의 일부가 다른 일부와 모순되는 요구사항)을 제거하는 것이다.
• 요구 사항 명세: 분석된 요구사항은 SRS(소프트웨어 요구사항 사양) 문서에 문서화되어 있다. SRS(Software Requirement Specification) 문서는 개발 팀과 고객 간의 계약서 역할을 한다. 고객과 개발 팀 간의 향후 분쟁은 SRS 문서를 검토하여 해결할 수 있다.

3. 설계

이 단계의 목표는 SRS에서 획득한 요구 사항을 프로그래밍 언어로 코딩할 수 있는 형식으로 변환하는 것이다. 전체 소프트웨어 아키텍처뿐만 아니라 높은 수준의 상세 설계도 포함한다. 소프트웨어 설계 문서는 이러한 모든 작업을 문서화하는 데 사용된다(SDD - Software Design Document)

4. 코딩 및 단위 테스트

코딩 단계에서 소프트웨어 설계는 임의의 적절한 프로그래밍 언어를 사용하여 소스 코드로 구현된다. 따라서 설계된 각 모듈은 코드로 구현 된다. 단위 테스트 단계의 목적은 각 모듈이 제대로 작동하는지 확인하는 것이다.

5. 통합 및 시스템 테스트

서로 다른 모듈의 통합은 코드화되고 단위 테스트한 직후에 수행된다. 다양한 모듈의 통합은 여러 단계에 걸쳐 점진적으로 수행된다. 각 통합 단계 동안, 이전에 계획된 모듈이 부분적으로 통합된 시스템에 추가되고 결과 시스템이 테스트된다. 마지막으로, 모든 모듈이 성공적으로 통합되고 테스트된 후, 전체 작동 시스템이 확보되고 이에 대한 시스템 테스트가 수행된다.
시스템 테스트는 아래에 설명된 바와 같이 세 가지 종류의 테스트 활동으로 구성된다.

• 알파 테스트: 알파 테스트는 개발팀이 수행하는 시스템 테스트
• 베타 테스트: 베타 테스트는 고객이 수행하는 시스템 테스트
• 인수 테스트: 소프트웨어가 제공된 후 고객은 인수 테스트를 수행해 소프트웨어를 승인할지 아니면 거부할지 결정

6. 유지보수

유지보수는 소프트웨어 수명 주기의 가장 중요한 단계이다. 유지보수에 소요되는 노력은 전체 소프트웨어 개발에 소요되는 총 노력의 60%에 해당한다.

기본적으로 세 가지 유형의 유지보수가 있다.

• 교정 유지보수: 이러한 유형의 유지보수는 제품 개발 단계에서 발견되지 않은 오류를 수정하기 위해 수행된다.
• 완벽한 유지보수: 이러한 유형의 유지보수는 고객의 요청에 따라 시스템의 기능을 향상시키기 위해 수행된다.
• 어댑티브 유지보수: 적응형 유지보수는 일반적으로 소프트웨어를 새로운 컴퓨터 플랫폼이나 새로운 운영 체제와 같은 새로운 환경에서 작동하도록 이식하는 데 필요하다.

전통적 폭포수 모델의 장점

고전적인 폭포수 모델은 소프트웨어 개발을 위한 이상적인 모델이다. 이는 매우 간단하기 때문에 다른 소프트웨어 개발 수명 주기 모델의 기초로 간주할 수 있다. 다음은 이 SDLC 모델의 주요 이점 중 일부이다.

• 매우 간단하고 이해하기 쉽다.
• 모델의 각 단계는 한 번에 하나씩 처리된다.
• 모델의 각 단계는 명확하게 정의된다.
• 매우 명확하고 잘 정리된 이정표를 가지고 있다.
• 프로세스, 작업 및 결과에 대한 문서화가 잘 되어 있다.
• 이 모델은 요구 사항이 잘 정의된 프로제트나 소규모 프로젝트에 적합하다.

전통적 폭포수 모델의 단점

전통적인 폭포수 모델은 다양한 단점으로 어려움을 겪고 있는데, 기본적으로 실제 프로젝트에서는 사용할 수 없지만 전통적인 폭포수 모델을 기반으로 하는 다른 소프트웨어 개발 라이프사이클 모델을 사용한다.

다음은 이 모델의 몇 가지 주요 단점이다.

• 피드백 경로 없음: 전통적인 폭포수 모델에서 소프트웨어가 한 단계에서 다른 단계로 진화하는 것은 폭포와 같다. 어떤 단계에서도 개발자가 오류를 범하지 않는다고 가정한다. 따라서 오류 수정을 위한 메커니즘을 포함하지 않는다.
• 변경 요청을 수용하기 어려움: 전통적인 폭포수 모델은 프로젝트를 시작할 때 모든 고객 요구사항을 완벽하고 정확하게 정의할 수 있다고 가정하지만, 실제로 고객의 요구사항은 시간이 지남에 따라 계속해서 변경된다. 요구사항 지정 단계가 완료된 후에는 변경 요청을 수용하기가 어렵다.
• 단계 중복 없음: 전통적인 폭포수 모델은 이전 단계가 완료된 후에만 다음 단계를 시작할 수 있도록 권장한다. 하지만 실제 프로젝트에서는 이것은 유지되기 어렵다. 효율성을 높이고 비용을 절감하기 위해 단계가 중복될 수 있다.