개발 프로세스 모델 소개 (폭포수, V, 통합 프로세스 모델 등)

 

개발 과정의 생명 주기

 

계획 단계에서 유지보수 단계에 이르기까지 일어나는 일련의 과정이다.

생명주기는 몇 달, 몇 년이 걸릴 수도 있다.

그냥 만든다고 끝나는 것이 아니라, 유지보수가 끝나서 소프트웨어를 사용하지 않을 때까지를 생명주기라고 한다.

 

 

 

생명주기를 사용하면 단계별로 내가 구체적으로 무엇을 개발해야 하는지를 알 수 있다.

이러면 문제점이 발생했을 때 쉽게 해결할 수 있다.

결국? 생명주기가 없으면 결정이 뒤죽박죽이 된다..

 

 

 

게다가 한번 만들어지면 유지보수가 힘들어진다.

소프트웨어를 만들면 오류가 나올 수 밖에 없다. 어찌됐든 유지보수는 필수다.

그래서 우리는 앞으로 유지보수 비용을 줄이기 위해 가장 비용이 낮은 요구사항 분석 방법을 배운다.

 

 

 

 

 

 

 

개발 방법들

 

위에서 봤던 개발 단계들이다.

1. 계획
2. 요구분석
3. 설계
4. 구현
5. 테스트
6. 유지보수

 

1. 계획 단계는 why단계로 불린다.

비용이 얼마나, 인력은 얼마나, 그리고 리스크 분석이나 컨셉은 무엇으로 할 지 정립한다.

 

 

2. 요구분석 단계는 사용자가 요구하는 시스템이 가져야 할 능력이나 조건을 분석하는 단계이다.

이 단계에서 우리가 어떤 개발방법론을 쓸 것인지, 우리 목표가 뭔지에 대한 최종 산출물인 요구 분석 명세서에 전부 나온다.

요구 분석 명세서는 아무것도 주어진 것 없이 바로 설계단계를 시작할 수 있을 정도로 명확해야 한다. 모든 세부 사항을 적으며 러프한 계획 마저 전부 적는다.

 

 

3. 설계 단계는 how단계로 불린다.

아키텍쳐, 데이터베이스, UI, 상세 설계를 한다.

이것들 전부 요구 분석 명세서로 만들기 때문에 전 단계가 아주 중요하다.

이 단계는 분할과 정복, 추상화, 단계적 분해, 모듈화, 정보은닉 등등의 설계 원리를 잘 알고 있어야 한다.

https://guhonga.tistory.com/99

소프트웨어 설계를 하는 방법 (분할 정복, 추상화)

 

 

 

 

4. 구현 단계는 주로 코딩과 단위 테스트다.

이 단계에서 혹시 문제가 발생한다면 다시 설계 단계로 넘어가서 고칠 수 있다.

 

 

5. 테스트 단계이다.

구현한 모듈별로 통합해서 테스트가 이뤄지고, 완성된 모듈을 추가한다. 통합은 개발자가 담당한다.

 

 

6. 마지막인 유지보수 단계이다.

테스트가 끝나고 제품이 완성되었으니, 어떤 결함이 있는지 사용하면서 문제점을 고치는 단계이다.

 

 

 

 

아무튼 이렇게 프로젝트를 관리하게 된다.

프로세스를 전반적으로 관리할 수 있어야 하는데, 개발 전체 단계에 걸쳐 나오는 문서나 산출물을 갖고서 어떤 문제점이 발생하면 추적할 수 있어야 한다.

 

 

 

하지만 단순하게 이런 단계들을 따라가기만 한다고 끝나지 않는다.

만들게 되는 규모, 개발 특성, 의뢰 사용자 능력, 요구상황 등에 따라 개발 프로세스가 바뀔 수 있다.

어떤 소프트웨어인지~ 어떤 특징이 있는지~ 등 모든 요소를 고려하여 어떤 방법론을 선택할 것인지 까지가 설계이다.

 

 

 

 

 

 

 

주먹구구식 모델

 

build and fix, code and fix 등 즉흥적 소프트웨어 개발 모델이 포함된다.

이름 그대로 생각없이 개발 먼저 한 후, 나중에 유지 보수를 생각하는 방식이다. 

 

 

일단 코드로 제품을 만든다. 만약 문제가 있으면 다시 코딩하고 제품을 만든다.

무한 반복하다가 문제가 없으면 사용한다.

이런 방식은 주로 개인사업자가 사용한다. 실제로 사용하는 방식이다.

 

일단 내놓고, 사람들이 욕하면 바로 다시 수정하고. 딱히 나쁘게 볼 것만은 아니다.

하지만 역시 개발 순서 단계별로 산출 문서도 없다. 그래서 문제가 생기면 유지보수가 어렵다.

 

 

 

 

 

선형 순차적 (폭포수) 모델

 

개발생명주기, 계획 등등을 단계별로 하나씩 지켜나가는 모델이다.

위 그림과 같이 단계별로 내려오는 모습 때문에 폭포수 모델 waterfall 이라고 부른다.

 

 

이 모델은 개발계획서를 만들고 요구분석해서 정의하고, 명세서를 만들고...~~ 문서들을 엄청 많이 만든다.

심지어 단계별로 시간을 엄청 들여서 검증을 다 한다. 그래서 뒤로 갈수록 문제점이 적어진다.
(비록 시간은 엄청 걸릴지라도.)

 

 

이런 모델은 사람 목숨과 직결되는 소프트웨어에 적합하다. 국방이라던지..

문서도 잘 만들었으니, code fix방식과 다르게 중간에 사람이 나가도 상관없다.

 

 

 

 

하지만 큰 문제가 있다..

폭포수 모델이라 하는 이유 중 하나가 폭포수는 거꾸로 올라가기가 힘들다.

마찬가지로, 한 단계에서 문제가 발생하면 이전단계로 돌아가는게 거의 불가능하다.

그래서 각 단계가 완벽에 가까울 정도로 마무리 되어야 다음 단계로 넘어갈 수 있다.

그리고 완전히 끝날때까지 결과를 확인하지 못한다는 것이 단점이다.

 

 

그래도 역시 체계적인 문서화로 관리가 잘 되어있으니 오케이 아닐까?

이런건 요구사항이 적은 모델에 적합하다. 중간에 변경을 할 수 없으니까..

 

 

 

 

 

V모델

 

방금 배운 폭포수 모델에 테스트 단계를 추가한 모델이다.

폭포수 모델의 각 단계를 진행하면서 테스트도 같이 하는 것이다.

 

폭포수 모델의 완전히 끝날때까지 결과를 확인하지 못한다는 단점을 극복하기 위해 나온 모델이다.

처음부터 테스트를 다 하기 때문에 신뢰성 있는 모델에 적합하다.

그래서 문제 발생 확률이 적다. 즉, 오류가 발생하면 안되는 모델에 적합하다.

 

 

 

 

 

 

진화적 프로세스 모델

 

진화적이란 이름을 쓰는 이유가 말 그대로 제품이 진화한다. 프로토타입을 만들어서 계속 수정하는 방식이다.

이런 모델들은 요구분석을 더 강조한 모델이다.

 

사용자랑 열심히 대화해서 이것저것 다 따졌다. 일단 따져서 프로토타입을 만들어놨다. 근데 마음에 안들어? 그럼 다시 프로토타입을 만들고... 무한반복한다. 이렇게 최종 제품을 만든다.

간단하게 요구분석을 하는 주먹구구식 모델이라고 보면 될것같다.

 

 

 

시중 반응을 빨리 파악하고 적용하고 싶은 제품에 적합하다. 예를들어 무료앱 배포 후 최종 제품에 돈을 내는 등..

 

 

프로토타입 모델을 사용하는 이유는 사용자모델이 명확하지 않을 경우 사용한다.

사용자가 잘 모르겠는데 하면 일단 한번 만들어주고 수정하는 것이다.

요구사항이 자꾸 변할지라도, 어차피 프로토타입은 완제품이 아니니까 쉽게 바꿀 수 있다.

 

비용이 많이 필요한 대규모 시스템이나 새로운 기술을 사용할 때 개발 전 프로토타입으로 실현 가능한지 판단한다.

 

 

이렇게 요구를 분석하고 빠르게 설계해서 만드는 프로토타입 모델은 최종 프로토타입을 버리지 않고 지속적으로 발전시켜 개발한다. (무한평가..)

 

 

 

 

 

프로토타입 모델의 개발은 우선

1. 사용자와 대화할 수 있을 정도로 대략적인 설계를 한다.

어느정도로 대략적이냐면 이미지로 대충 입출력과 사용자 인터페이스 구현한다. 하지만 기능구현은 당연히 안되어있다.

 

 

2. 평가를 하고 나서 수정 요구사항이 있으면 프로토타입을 개발하고, 또 반복하고, 결국 구현한다.

 

 

이 모델의 장점으론 의사소통 도구로 이용되는 것이다.

반복된 요구사항 정의로 충분히 요구사항이 반영된 요구분석명세서를 작성할 수 있다.

품질관리를 할 때에도 요구사항 분석명세서를 쓰고나서, (제품을)끝까지 쓰기 때문에 장점이다.

 

단점으론, 만족할 때 까지 계속 반복하느라 비용이랑 기간이 많이 들어간다.

 

 

 

 

 

 

 

나선형 모델

 

진화적 프로토타입에서 위험분석을 추가한 모델이다.

 

그럼 위험분석이 왜 필요한가.

 

고객의 요구사항은 계속 변경된다.

팀원의 결속력이나 팀워크도 변수이고.. 변경되면 이 소프트웨어가 값어치를 하는지 무섭고..

그냥 이런 것들을 체크해보는 것이다.

 

위험분석을 할 때마다 각 분야의 전문가들을 불러서 법률적으로 문제는 없는지 확인한다.

물론 전문가 초청 비용이 많이 들긴 하지만 반드시 필요한 과정이다...

 

 

그래서 결국 장점은 사전위험분석이 가능하다는 것이다. 갑자기 돌출되는 위험도 적을 뿐더러 대처가 가능하다.

 

단점은 점진적 반복이라 프로젝트의 연장 가능성이 있다.

그리고 회수가 반복될수록 관리가 어려워지고, 전문가 초청 비용이 부담된다.

 

 

 

 

 

 

단계적 개발 모델

 

기본적으로는 단계를 나눠서 출시하는것인데, 이 그림만 봐서는 확 와닿지 않는다.

 

 

메뉴가 나오면 먹고, 다먹으면 그 다음요리. 먹고 다음. 먹고 다음요리... 이렇게 하나씩 개발 범위를 늘려가는 것이다.

 

 

 

이 모델은 점증적과 반복적 두 가지로 나눠진다.

 

점증적은 하나씩 추가하는 방법이다.

예를들어 건물을 지을 때, 1층을 완성하고 사용. 그 다음 2층을 증축하고 사용. 이런식이다.

아니면 책을 쓸 때, 1권을 완벽하게 다 쓰고, 그 다음 2권, 3권..

 

 

반복적은 하나 끝나면 하나 늘리는 방식이다.

예를 들자면 한식 코스요리에서 상차림 푸짐하게 나왔는데, 거기에서 한번은 이 접시에서 한점, 한번은 다른접시 먹어보고.. 이런 식이다.

 

 

 

 

 

 

통합 프로세스 모델 UPM

 

폭포수 모델의 문제점을 보안하고자 한 방식으로, 그냥 폭포수 모델을 여러번 반복하여 각 프로세스가 같이 이뤄진다.

 

 

하지만 비중의 차이는 있다.

도입 단계에선 비즈니스 모델링을 좀 더 집중적으로 하고, 구체화 단계는 설계를 중점적으로, 구축 단계에선 구현이 이뤄진다.

 

물론 다른 것도 다 같이 하는데 비중을 유연하게 바꾸자는 것이다.

전이 단계에선 배치를 중점적으로 하고, 다시 모든 각 단계들을 n차 반복한다.

 

 

 

간단하게 말하자면, 초기계획을 잡고 형상관리를 같이 하면서 요구사항 정의, 분석 설계, 평가를 반복적으로 하는 것이다.