개발프로세스 모델 별 특징 [소프트웨어공학]

이전 글에서 설명했다시피  차례대로 개발프로세스의 특징을 소개해보려고 한다.

 

 

 

---

 

 

 

1. 폭포수(water fall) 모델

보는 것과 같이 위에서 아래로 물이 흐르는 듯한 모양을 가지고 있다.

 

 

특징으로는

 

 각 단계가 다음 단계 시작 전에 끝나야함

 각 단계 사이에 중복이나 상호작용이 없다.

 각 단계의 결과는 다음 단계의 시작 전에 점검한다.

 결과가 만족되지 않으면 바로 전 단계로 돌아가 다시 수행한다.

 

각 단계가 순차적이라 직능 중심의 프로젝트 조직화가 가능하다 (pipeline)

ex) 요구 분석팀, 구현팀 등등

 

 

이 모델은 단순하거나 응용 분야를 잘 알고 있는 경우 적합하다.

모델 자체가 단순해서 비전문가도 개발과정을 이해하기 쉽다.

 

 즉 요구사항이 명확하고 변경이 거의 없는 경우에 활용한다.

크고 복잡한 오래 지속되는 프로젝트에 적합하다. 

ex) 공장제어시스템, 우편물 정리 분류

 

 

단점으로는

 

설계와 코딩 및 테스팅 지연 가능성이 있다.

이는 초기 단계들이 지나치게 강조되어 불필요한 문서들의 작성을 가져올 수 있다는 것이다.

 

또한 요구 변경을 수용하기 어렵다. 이미 구현단계로 넘어갔다면 요구 변경이 힘들다.

그래서 개발 기간동안 환경이나 표준이 바뀌면서 요구가 바뀌는 작업이라면 폭포수 모델로는 힘들 수 있다.

 

또한 프로토타입이 없으므로 최종 결과가 나오기 전까지는 어떤 결과물이 나올지 알 수 없다.

이는 중간에 프로젝트를 취소해버린다면 크나큰 손실이 따른다는 이야기이다.

 

 

 

*** 단 각 단계가 끝난 후에 나오는 결과물에 대하여 명확히 정의하여야 할 것이다.

순차적인 만큼 에러가 늦게 나오면 수정비용이 커지는 것과 같이 정확히 정의하는 것이 필요하다.

 

 

 

---

 

 

2. 프로토타이핑 모델

 

 

 

 

요구분석 단계에서 비전문가 입장으로서는 입력, 출력에 대해 정확히 요구하기가 어렵다. 또한 이 프로젝트가 정말 실현가능한지 알 수 없다. 그런 경우 프로토타이핑 모델을 채택하여 프로젝트가 실현 가능성이 있는지 보장받을 수 있고 보다 정확한 요구사항을 제시할 수 있다.

 

 

요구된 소프트웨어의 일부를 보여주기 위해서는 프로토 타이핑 도구를 쓴다

ex)화면 생성기, 비주얼 프로그래밍, 4세대 언어 등

 

프로토 타이핑 모델의 목적은 폭포수 모델의 단점을 보완하기 위해 쓴다.

 사용자와 개발자 간의 의사소통을 돕는다

(설계 이전에 요구를 동결하고 요구의 이해를 시킨다. 따라서 요구가 거의 변경되지 않아 비용 절감 가능하다)

 

 

프로토 타이핑 모델은

개발 착수 시점에 요구가 불투명할 때
실험적으로 실현 가능성을 타진해 보고 싶을 때
혁신적인 기술을 사용해 보고 싶을 때

쓰는 모델들이다. 

 

대규모의 자본 투입 전 실현가능성을 보는데에 흔히 쓰인다.

 

 

단점으로는

 

 
 프로토타입이 최종결과라고 믿어서 곧 개발이 완료될 것이라 생각한다.

그러한 오해와 기대심리는 기간 단축을 요구하고 그것이 소프트웨어의 품질을 저하시킬 수 있다.

 요구사항 과다 위험이 있고  관리가 어려움(중간 산출물 정의가 난해 >> 중간 과정을 점검 못함)

 

 

 

 

 

++

** 프로토 타이핑에는 2가지 개발방식이 있다.

1. evolutionary

2. throwaway

 

프로토 타입을 만들고 그것을 바탕으로 피드백 받아가며 수정해나가는 방식이 있고

요구분석만을 위해 이해되지 않는 요구사항을 바탕으로 프로토타입을 만들고 버리는 방식이 있다.

 

 

여기서 진화적 모델에 대해 더 알아보자면

 

개발 기간이 긴 것을 허용하지 않는 최근에 알맞은 모델이라고도 볼 수 있다.

 

 

릴리스 구성 방법은 2가지 정도가 있다.

하나는 그림처럼 시스템의 일부를 경험하게 하고 점증적(increments)으로 개발하는 것이다.(기능별로 릴리스한다)

릴리스를 반복하면서 시스템이 완전히 구현될 때까지 설계 조정, 확장 등 유용한 피드백을 이용할 수 있다.

 

다른 하나는 반복적(iterative) 개발이다. 처음부터 시스템 전체 기능을 대상으로 릴리스하는 것으로

릴리스마다 기능을 향상시키는 것이 목표이다. 

 

사실 2가지는 구분할 필요는 없다. 거의 병행적으로 쓰이기 때문이다.

 

 

 

최근에 알맞은 모델이라고 할만한 장점들이 있는데

4가지 정도가 있다.

 

1.기능이 부족하더라도 초기에 사용 교육 가능, 부족한 부분 피드백 반영

2.처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음
3.자주 릴리스 하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 꾸준히 고쳐나갈
수 있음. //유지 보수
4.개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음.  // 기능의 향상 목적 릴리스이므로

 

 

**일정이 정확하게 예측되어야 하는 프로젝트에는 적합하지 않다.

 

 

 

 

---

 

 

3. 나선형 모델 (spiral)

 

 

 

 

이것 또한 소프트웨어의 기능을 나누어 점증적으로 개발한다.

하지만 거기에 + 위험분석을 한다.

그래서 실패의 위험을 줄이고, 피드백, 테스트에 용이한 모델이다.

 

어떤 식으로 개발하냐면

1.계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정
2.위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석
3.개발(engineering): 선택된 기능의 개발
4. 평가(evaluation): 개발 결과의 평가

 

위험 분석이 있는 만큼 

이 모델은 위험 요소가 많은 프로젝트에 어울리는 모델이다.

변수가 많은 대규모 시스템의 경우 나선형 모델로 많이 작업된다.

또한 성능 문제, 기술 문제 등으로 실패할 수 있는 시스템의 개발
재정적 또는 기술적으로 위험 부담이 큰 경우
요구 사항이나 아키텍처 이해에 어려운 경우

 

나선형 모델은 비선형적이며 반복적인 개발로 소프트웨어의 품질 중 "강인성" 을 높일 수 있는 방법이고

요구 사항을 사이클마다 반영하여 요구를 만족시킬 수 있다.

 

단점으로는

위험분석 자체가 비용이 많이드는 작업이다. 그래서 위험 분석을 어떻게 하느냐에 따라 프로젝트의 성패가 달려있다.

 

 

 

---

 

 

4. V 모델

 

 V 모델은 폭포수 모델에서 시스템 검증과 테스트 작업을 강조한 모델이다.

모양만 봐도 내려갔다 올라오는게 뭔가 폭포랑 비슷하면서 다른 모양을 가지고 있다.

 

그림에서 검증이라 써있는 부분은 테스트 단계에서 오류가 생겼을 때 돌아갈 단계를 이어놓은 것이다.

 

V모델의 장점은

모든 단계에 검증과 확인이 있어서 오류를 줄일 수 있다. 오류가 거의 없다는 것은

신뢰도가 높다는 것으로 높은 신뢰도를 요구하는 프로젝트( ex. 의료 산업, 원전 제어) 에 적합한 모델이다.

 

단점으로는 

이미 작업이 끝나버리면 변경이 쉽지 않다는 것이다.  그래서 V 모델을 사용할 때에는

요구 명세가 아주 상세하고 확실해서 개발 기간 동안 변경이 경우에나 적합하다고 볼 수 있다.

 

 

---

 

 

 

 

5. Unified 프로세스

 

 

 

이렇게 여러 사이클로 구성되어있는데

마치 병렬작업하는 듯한 느낌... ㅎㅎ

 

iter #1, #2 ... 반복작업을 하는 것이다. 이러한 반복은 프로젝트의 완성과 함께 끝난다.

 

4가지 단계: 도입, 정련, 구축, 전환이 있다. 

 

① 도입(inception)
 1, 2회 정도 반복으로 도입 단계를 진행
 간단한 유스케이스 모델과 소프트웨어 구조, 프로젝트 계획을 작성

 

*유스케이스란 어떤 시스템이 개발될 것인지 나타내기 위하여 비즈니스 프로세스를 모델링 한 것이라 보면 된다

간단히 말하면 유저와 시스템의 상호작용이랄까?

ex) 현금인출기를 위한 유스케이스: 입금, 출금, 잔액조회 등이 있다.

② 정련(elaboration) 
 여러 번의 반복 과정으로 이루어짐
 대부분의 유스케이스를 작성
 아키텍처 설계(UML 다이어그램)

③ 구축(construction) 
 남아 있는 유스케이스에 대하여 구현하고 통합
 시스템을 목표 환경에 점증적으로 설치

④ 전환(transition) 
 시스템을 배치, 사용자를 교육  
 베타 테스팅, 결함 수정, 기능 개선

 

이 모델의 특징은 유스케이스를 식별하여 시스템 개발 계획에 활용하는데 있다.

다시 말해서, 유스케이스 중심 프로세스가 된다.

 

또한 아키텍쳐와 전체적인 구조를 개발 초기에 확정하고 개발의 가이드로 활용한다.

이는 아키텍쳐 중심의 프로세스라는 것을 뜻한다.

 

반복 과정을 통해 개발하는 것이 진화적 모델과 유사하지만 release는 하지 않는다는 차이가 있다.

 

 

장점으로는
 방법론과 프로세스가 잘 문서화 되어 있어 교육받기 좋음
 고객의 요구 변경과 관련된 리스크를 적극적으로 해결
 통합을 위한 노력과 시간을 줄일 수 있음
 쉽고 빠르게 코드를 재사용

 

 

 단점으로는 

 프로세스가 너무 복잡, 이해하기 어렵고 정확히 적용하기가 어려움
 소프트웨어 프로젝트 참여자들의 협동, 의사소통에 대한 가이드가 없음

 

 

---

 

 

 

6. 애자일 프로세스(agile)

폭포수 프로세스의 단점 ( 요구사항 변경에 많은 시간과 비용을 초래하는 것) 을 해결한 모델

팀워크, 사용자와 협력개발, 변경을 위한 설계, 짧은 개발 사이클(2-6주) 의 특징을 가지고 있다.

 

애자일 프로세스에는 4가지 철학이 있는데

 

1. 절차와 도구보다 개인과 소통을 중요시

 

계획위주의 절차가 프로젝트 성공이라고 생각하지 않는다. 즉 프로세스에 의하여 소프트웨어의 품질이 좌우되는 것이 아니라 팀워크와 팀원의 능력이 더 중요하다고 생각한다. 이는 최근의 소프트웨어 개발에 알맞은 접근이 되었다.

 

 

2. 문서보다는 실행되는 소프트웨어에 더 가치를 둔다.

 

소프트웨어의 개발은 분석과 설계 문서를 준비하는 데 많은 시간을 쏟아왔다. 그러나 경험적으로 설계를 아무리 잘해도 실제 구현에서 작동이 되는지는 구현해봐야 알 수 있어서 실질적인 도움은 실행되는 소프트웨어라고 생각한다.

 

 

3. 계약 절충보다는 고객 협력이 중요하다.

 

고객의 요구를 분석하고 그것을 절충하는 과정이 있고 그 이후의 고객과는 소통을 하지 않았다. 그러나 지금은 고객과 함께 의견을 교환하고 상호 이해하는 것이 프로젝트의 실패율을 줄일 수 있다고 생각한다.

 

4. 계획을 따라 하는 것보다 변경에 잘 대응하는 것이 중요하다

 

프로세스는 변경을 제어한다. 변경이 비용을 초래하기 때문이다. 그러나 지금은 변경 요구가 변하는 것이 당연해졌고 이러한 변경을 잘 대처하는 것이 성패를 가르는 요소가 되었다. 따라서 계획 중심의 프로세스는 최근의 흐름과 맞지 않기에 애자일 프로세스가 등장했다.

 

 

**애자일 프로세스는 이는 유스케이스, 사용자 스토리나 피처(feature) 단위, 테스트 중심 개발이라는 방향성을 가지고 있다.

 

 

 

++

 

 

** 익스트림 프로그래밍

 사용자 스토리 //모듈 개발
 매일 빌드와 통합 // 모듈 통합
 테스트 주도 개발(Test-Driven Development)
 페어 프로그래밍 (pair) // 한 사람은 개발하고 다른 한사람은 테스팅하고