소프트웨어 개발 생명주기 모델의 4가지 종류
소프트웨어 개발 생명주기 모델의 4가지 종류
1. 주먹구구식 개발 모델
2. 폭포수 모델
3. 원형 모델
4. 나선형 모델
소프트웨어 개발 생명주기란?
소프트웨어를 어떻게 개발할 것인가에 대한 전체적인 큰 흐름을 나타내는 추상적 표현으로,
순차적 또는 방법적인 단계로 구성된다.
생명주기는 개발 생명주기의 각 단계에 관련된 여러 활동들이 정의되어 있다.
이 활동들을 통해 다음 단계에 활용될 수 있는 산출물이 만들어진다.
소프트웨어 개발 생명주기는 근거가 되어 가능하게 만든다.
1. 전체 프로젝트의 비용을 미리 산정할 수 있는 근거가 된다.
2. 개발 계획을 수립할 수 있는 기본 골격 (어떤 방법론을 통해서, 어떤 인력이 필요한지) 제시할 수 있는 근거가 된다.
3. 참여자들 간에 의사소통의 기준과 용어의 표준화를 가능하게 한다. 생명주기를 통해 어떤 일을 할 것인지 나타나있기 때문에 가능하다.
4. 각 단계별로 그 단계의 완성을 나타내는 산출물을 정의함으로써 문서화가 충실한 프로젝트 관리를 가능하게 한다.
문서화되어 있기 때문에 나중에 이해도가 상충되었을 경우 근거가 된다. 그렇기 때문에 문서화로 남겨놓는다는 것은
프로젝트 관리에 중요한 부분이 된다.
1. 주먹구구식 개발 모델 (Build-Fix Model)
가장 단순한 형태의 모델이다.
요구사항 분석, 설계 단계 없이 진행
일단 개발. 코딩을 통해 구현에 들어간 후 만족할 때까지 수정작업을 수행한다.
적용할 수 있는 분야가 매우 한정
초창기 1945년대 , 1950년대 등등의 소프트웨어 개발방법으로 그 당시에는 소프트웨어 규모가 작았기 때문에 적용된 방법으로써 주먹구구식 개발 모델은 크기가 매우 작은 규모의 소프트웨어 개발에 적용된다.
장점
1. 특별한 형식이 필요하지 않아 언제 어디서든 쉽게 작업에 접근할 수 있어, 쉽게 수정이 가능하다.
2. 적은 인원, 저비용, 적은 시간으로 개발할 수 있다.
단점
1. 정해진 개발 순서가 없기 때문에 계획이 정확하지 않다.
2. 관리자는 프로젝트 진행 상황 파악이 어렵다.
3. 개발 문서가 없기 때문에 개발 및 유지보수에 어려움이 따른다.
개발절차가 다 무시가 되기 때문에 구성원들 간의 이해도가 상충하여 서로 간에 충돌이 일어날 수 있다.
사용자와도 이해도가 상충될 수도 있다.
Feedback을 통해 제품 수정이 이루어진다.
사용자가 문제제기를 할 수 도있고, 개발자 자체에서 주먹구구식으로 개발했기 때문에
성능이라던가, 오류가 발생했을 때 수정을 한다.
운영모드
제품을 수정했다고 해서 끝난 것이 아니라 운영모드로 들어간다.
전체적인 환경이 바뀌거나 성능이 저하되거나, 고객이 원하는 것이 바뀔 경우 유지보수가 발생될 수 있다.
점선으로 표시한 것은
실선으로 표시한 것보다는 중요도는 떨어지지만 얼마든지 가능하다는 말이다.
2. 폭포수 모델(Waterfall Model)
순차적으로 소프트웨어를 개발하는 전형적인 개발 모델
그렇기 때문에 한편으로는 순차 모델이라고 부르기도 한다.
대부분의 소프트웨어 개발 프로젝트의 기본적 모델
가장 많이 사용되는 모델이다.
체계적이고 순차적으로 접근하는 방법
소프트웨어 개발의 전 과정을 나누었다.
장점
1. 프로세스가 단순하여 초보자도 쉽게 적용이 가능하다.
2. 중간 산출물이 명확하여 프로젝트 관리가 좋다.
3. 코드 생성 전 충분한 연구와 분석이 가능하다.
단점
1. 앞 단계가 완료될 때까지 다음 단계들은 대기 상태여야 한다.
2. 실제 작동되는 시스템을 개발 후반부에 확인 가능하기 때문에 고객이 요구사항을 확인하는데 많은 시간이 걸린다.
3. 제품이 완료되었는데 고객의 요구사항과 상이할 때 그동안 많은 시간과 비용을 쏟았기 때문에 이전단계로 돌아가는 것이
비용적, 시간적으로 힘들 수 있다.
적용가능한 프로젝트
단순하거나 이미 잘 알고 있는 문제에 적합하며, 변화가 적은 프로젝트에 적합하다.
개발 과정 (하나의 단계가 다 완료가 되어야지 그다음 단계로 갈 수 있다.)
1. 요구사항 분석
2. 설계
3. 구현
4. 테스팅
5. 유지보수
위 모든 단계는 말로 진행되는 것이 아닌 일정한 형식이 존재한다.
수정 시 모든 단계로 갈 수 있다.
아래쪽 회색 화살표는 수정으로 갈 수 있는 것을 나타내며
모든 단계로 바로 갈 수 있다.
해당 폭포수 모델은 수정시 전단계로만 갈 수 있다.
유지보수에서 테스팅으로 갈 수는 있지만 유지보수에서 구현으로 바로 갈 수는 없다.
유지보수에서 테스팅으로 가고, 테스팅에서 문제가 생기면 구현단계로 가고, 구현단계에서 문제가 발생되면
설계로 가고, 설계에서 문제가 생기면 요구사항분석으로 간다.
1단계. 요구사항 분석 (What(무엇)의 단계)
사용자 자신이 무엇을 요구하는지, 무엇을 필요로 하는지 정확하게 제시할 필요가 있다.
즉, 사용자 요구나 주어진 문제를 정확히 분석 이해하는 과정으로 구현 시스템의 기능, 목표, 제약사항 등을 정확히 파악한다. 발주자와 개발자가 요구분석 사항에 동의하여야 다음 단계(설계)로 진입한다.
요구사항 명세서 (Requirement Specification)
요구 분석 단계의 결과물
사용자와 개발자의 의사소통 수단으로 사용
개발자와 사용자가 정확한 형식을 정해서 형식에 맞게 작성한다.
2단계. 설계 (How(어떻게)의 단계)
분석된 결과를 어떻게 프로그램으로 구성할 것인가. 절차에 관한 단계이므로 주로 솔루션에 집중한다.
설계 명세서
설계 단계의 결과물
소프트웨어 구조를 기술한 것으로 모듈의 기능과 모듈 사이의 관계를 기술한 것
설계 과정 크게 3가지로 분류
1. 시스템 구조 설계
전체적인 기능을 어떻게 분류할 것인가?
시스템을 구성하는 모듈과 모듈사이의 상관관계 (A모듈을 끝낸 뒤 B모듈로 갈 수 있는.. 등)와 구조를 설계한다.
2. 프로그램 설계
시스템 구조 설계에서 추상적으로 된 부분을 조금 더 구체적으로 각 모듈 내에서의 알고리즘(방법과 절차)을 설계한다.
3. 사용자 인터페이스 설계
사용자에게 보이는 부분을 설계한다.
3단계. 구현 (DO it 단계)
이전 단계의 모듈 설계를 기준으로 프로그래밍을 한다.
소스코드
구현단계의 결과물
4단계. 테스트 (Test)
프로그램이 입력에 따라 요구되는 결과대로 작동하는지, 내부적 이상 여부 및 오류 발견을 위해 수행
테스트 계획을 세운 후 문서화한다.
다양한 상황들을 만들어서 데이터를 넣었을 때 올바른 답이 나오나 확인한다.
또는 사용자가 엉뚱한 답을 넣었을때 어떻게 대처를 하는지에도 테스트한다.
5단계. 유지보수
출시가 된, 개발된 소프트웨어의 변경사항을 수정하는 것
수정 유지보수, 적응 유지보수, 기능 추가 유지보수 등이 있다.
3. 원형 모델 (Prototyping Model)
폭포수 모델의 (결과를 보기까지 시간이 소요되고, 결과가 사용자에 맘에 안 들면 여태까지 들어간 시간과 비용이 무력화된다는) 단점을 보완한 모델이다.
원형을 만들어 고객과 사용자가 함께 평가한 후
개발될 소프트웨어의 요구사항을 정제하여 보다 완전한 요구사항 명세서를 완성한다.
원형(Prototype)이라는 말은 학술적인 용어여서 시제품, 가제품으로 이해하면 쉽다.
즉, 시제품, 가제품을 만들어 사용자가 원하면 진행을 하고 원하지 않으면 이전단계로 돌아가서 수정을 가한다.
사용자 입장에서는 결과를 미리 볼 수 있으며
제품이 완성되기 전에 문제를 발견할 수 있다.
목적
소프트웨어 개발 초기에 고객의 요구사항을 완전히 파악하기 어려울 때 원형을 가능한 한 빨리 개발하여 고객과 검증하는 것
방법
1. 고객으로부터 피드백을 받은 후 원형을 폐기한다. (원형은 완제품이 아니기 때문에 언제든지 폐기, 수정이 가능하다.)
2. 시스템 기능 중 중요한 부분만 구현하여 피드백을 얻은 후 지속적으로 발전시켜 완제품을 제작한다.
1단계. 요구사항 정의 (Requirement Gathering and Refinement)
고객의 일부 요구사항 또는 불완전한 요구 사항으로부터 제품의 윤곽을 잡는다.
2단계. 원형 설계 (Quick Design)
주어진 요구사항을 기반으로 빠른 설계를 한다.
주로 제품의 사용자 인터페이스에 초점을 맞춘다. (사용자가 어떤 식으로 만족을 하고, 어떤식으로 반응하는가)
3단계. 원형 개발(Building Prototype)
프로그램의 신뢰도나 품질이 아니라 가능한 한 빨리 원형을 구현하는 것이 목적으로 하였기 때문에
설계된 원형을 RAD (Rapid Application Development) 도구(사용자 편의를 위해 제공된) 등을 사용하여 빠르게 구현한다.
즉, 고객이 요구하는 기능을 구현하고 필요한 요소를 파악하는데 중점을 둔 것이다.
4단계. 고객 평가 (Customer Evaluation of Prototype)
고객과 개발자가 함께하는 가장 중요한 단계이다.
고객 요구사항을 정확하게 규명하기 위해 원형에 대한 사용 및 평가시간을 충분히 제공한다.
고객 평가는 개발될 소프트웨어의 요구사항 정제에 중요한 정보로 활용된다.
5단계. 원형 정제 (Refining Prototype)
원형이 어떻게 수정되어야 할지를 결정한다.
원형 개발과 검증, 요구사항 정제의 순환을 반복하여 추가적인 정보를 통해 요구사항을 완성해 나간다.
장점
1. 사용자의 의견 반영이 잘 된다.
2. 사용자가 더 관심을 가지고 참여할 수 있고 개발자는 요구를 더 정확히 도출할 수 있다.
단점
1. 프로토타입이 최종 결과라고 믿고 소프트웨어 개발이 곧 완성되리라는 사용자의 오해, 기대심리를 유발한다.
2. 중간 산출물 정의가 난해해 개발자 입장에서는 관리가 어렵다.
-중간 산출물이 거의 완제품과 가까워 큰 차이가 없을 때,
-해당 산출물이 첫 번째 산출물인지 두 번째 산출물인지 정하기 애매할 때,
이런 중간 산출물을 어떻게 보느냐에 사용자와 개발자의 입장차이가 발생할 수도 있다.
적용가능한 프로젝트
1. 개발 착수 시점에 사용자 요구가 불투명할 때
2. 실험적으로 실현 가능성을 타진해 보고 싶을 때
3. 혁신적인 기술을 사용해 보고 싶을 때
4. 나선형 모델 (Spiral Model)
폭포수 모형과 원형 모형의 장점을 수용하고 위험 분석 (Risk Analysis)을 추가한 점증적 개발 모델이다.
(단계가 있는 측면에서는 폭포수 모형 : 안정적
반복한다는 측면에서는 원형 모형 : 빠른 피드백 수용)
목적
프로젝트 수행 시 발생하는 위험을 관리하고 최소화하려는 것이 목적이다.
특징
1. 여러 개의 작업 영역으로 구분한다.
2. 나선상의 각 원은 소프트웨어 개발의 점증적 주기를 표현한다.
3. 가장 안쪽 타원부터 개념 개발 프로젝트, 실제 제품 개발 프로젝트, 제품 향상 프로젝트, 유지 보수 프로젝트로
진행된다.
4. 단계가 명확히 구분되지 않고, 엔지니어가 프로젝트 성격이나 진행상황에 따라 단계를 구분할 수 있다.
단계를 4가지로 구분할 수 있다.
1. 계획 및 정의
2. 위험 분석
3. 개발
4. 고객 평가
1단계. 계획 및 정의 단계
1. 개발자는 고객으로부터 요구사항을 수집한다.
2. 개발자는 시스템의 성능, 기능을 비롯한 시스템의 목표를 규명하고 제약 조건을 파악한다.
3. 목표와 제약 조건에 대한 여러 대안들을 고려하고 평가함으로써 프로젝트 위험의 원인을 규명하기에 가능하다.
2단계. 위험 분석 단계
1. 초기의 요구 사항을 토대로 위험 규명한다.
2. 위험에 대한 평가가 이루어지면 프로젝트를 계속 진행할 것인지 아니면 중단할 것인지를 결정
3단계. 개발 단계
시스템에 대한 생명주기 모델을 선택하거나 원형 또는 최종적인 제품을 만드는 단계이다.
4단계. 고객 평가 단계
1. 구현된 소프트웨어(시뮬레이션 모형, 원형 또는 실제 시스템)를 고객이나 사용자가 평가한다
2. 다음 단계에서 고객의 평가를 반영할 수 있는 자료 획득이 가능하기에
고객의 피드백을 얻는데 필요한 작업이 포함된 단계라고 생각하면 된다.
적용 가능한 프로젝트
시간과 비용, 인력이 많이 들기 때문에
고비용의 시스템을 개발하거나, 시간이 많이 소요되는 큰 시스템 구축 시 유용하다.
장점
프로젝트의 모든 단계에서 위험 분석이 들어가기 때문에
1. 기술적인 위험을 직접 고려할 수 있어 사전에 위험을 감소시킬 수 있다.
2. 신중한 판단으로 인해 테스트 비용을 감소시키고 시간도 감소시켜 제품 개발 지연 등의 문제 해결이 가능하다.
3. 고품질의 소프트웨어를 사용자에게 제공할 수 있다.
단점
1. 개발자가 정확하지 않은 위험 분석을 했을 경우 심각한 문제가 발생한다.
위험 분석은 다음 단계를 진행하는 판단근거가 되기 때문에 엉뚱한 것을 분석하면 판단이 엉뚱하게 갈 수 있다.
2. 폭포수, 원형 모델에 비해 상대적으로 복잡하여 프로젝트 관리 자체가 어려울 수 있다.
참고사이트 - 메가존아이티평생교육원 | 소프트웨어 공학 | 전우천