소프트웨어공학 - 5. Iterative, Evolutionary, Agile

- 소프트웨어 개발 프로세스는 소프트웨어 개발 과정에서의 activity와 relationship이다.

- 이전 시간에 다양한 software development process model들도 살펴봤다.

- 이번장에서는 Unified Process를 포함한 반복적 개발 프로세스에 대해 자세히 알아보자.

1. iterative, evolutionary development

- "requirement를 한번에 다 수집 -> 구현 -> 테스트" 하는 것이 아니라 "일부 requirement 파악 -> design(설계) -> implementation(구현) -> test(검증) -> integration(통합)" 의 cycle을 계속 반복하며 진화하듯이 소프트웨어를 완성하는 것을 말한다.

 

- 예를들어 만약 총 개발기간이 30주라면 왼쪽에 표시된 3주 어치의 task를 10번을 반복하는 것이다.

 

- 기존 waterfall 방식에서는 프로젝트 막바지에 발생하는 risk의 경우 대응이 상당히 어려웠다.

- 즉 요구사항 파악 단계를 이미 지났다면 더 이상의 요구사항 변화에 대응하거나 추가 반영이 어려웠다.

- 만약 초기에 요구사항을 잘못 파악했다면 이를 깨달았을때는 이미 출시에 임박한 상황일 수 있는 것이다.

 

- 그래서 제안된 방식이 build - feedback - adapt의 cycle을 계속 반복하면서 완성하는 방식이다.

- 더 자주 feedback, testing이 반영되기 때문에 소프트웨어의 성공 확률이 점점 높아질 수 있다.

- 일련의 프로세스가 반복되기 때문에 risk파악과 대응에도 유리하다.

 

- 이미 UP를 포함한 이런 반복적 개발 프로세스는 현업에서 많은 효과가 입증되었다.

- 보통은 각 iteration의 기간을 대략 2주로 잡는다.너무 길지 않도록 적당히 짧은 기간이 좋다.

- 만약 requirement가 너무 많아서 2주를 넘길것 같다면 2주라는 기간을 늘리지 말고 requirement를 줄여서 다음 iteration에 맡기도록한다. (기간은 fix시키도록 한다.)

2. Risk-driven

- requirement를 쪼개서 반복된 cycle로 하나씩 해결하기로 했다. 

- risk-driven이란 requirement중에서 risk가 높다고 판단되거나 중요한 것들에 우선순위를 부여하는 개념이다.

- 프로젝트 초기에 결정되어야 하는 architecture 설계 작업 혹은 지금 결정하지 않으면 후에 작업이 불가능한 일들을 먼저 수행하는 것이다.

- 그래서 보통 iteration-1이 중요한 architecture centric 또는 risk driven 작업을 수행한다.

3. client-driven

- 사용자가 원하는, 중요하다고 생각하는 요구사항들을 우선적으로 고려하는 방식이다.

4 Iterative, Evolutionary Analysis & Design example

1. 본격적인 Iteration이 시작되기 전에 한 며칠정도 requirements workshop을 갖는다. high level view로 requirements들을 파악한다. 그중에서 risk가 높다고 판단되는 일들을 고른다. architecture 구성, 핵심 기능 등의 작업이 이에 해당할 것이다.
2.  그렇게 선택한 high risk requirement들에 대해서만 깊은 분석을 수행한다.
3.  이제 본격적인 iteration-1 (3주)이 시작된다. 앞서 결정된 사항에 따라 requirement들을 차례로 반복적으로 구현해 나간다.
   1. iteration이 만족해야 하는 goal을 설정
   2. modeling, uml design, sketching
   3. coding 시작
   4. test
   5. 그동한 한 작업들 integration
   6. test
   7. demo출시, feedback
4. 이제 다음 requirment를 가지고 와서 iteration - 2를 시작한다.
5. 다음 requirment를 가지고 와서 iteration - n을 수행한다.

- 이렇게 중요한 요구사항들을 빠르게 반영하면서 최종 software의 완성도가 높아진다.

5. UP

- up에도 큰 틀의 phases들은 존재한다.

- inception : 프로젝트의 장기적 목표, 비용, business 중요성 등을 파악하는 단계이다. 프로젝트의 feasibility를 결정한다. 보통은 반복되지 않는 작업으로 짧은 기간 안에 수행된다.

- elaboration : 본격적으로 iteration들이 수행되는 단계이다. Risk, business value등 우선순위가 높은 requirement들을 먼저 수행한다. ex) architecture 설계, 이 단계의 끝에서 대부분(80퍼센트)의 requirements define이 완료된다.

- construction : risk가 낮고 상대적으로 중요도가 낮은 작업들이 iteration으로 수행된다.

- transition : 베타테스트, 배포 단계

 

- up에서 자주 사용되는 용어 두개를 소개한다.

- artifact : 작업 산출물, 코드, db스키마, diagram, model 등

- discipline : requirement를 구현하기 위한 모든 활동들과 그 결과를 말한다. writing a use case 활동과 결과물인 use case / implement module과 결과물인 module등.

- discipline들을 정의하고 시간이 지남에 따라 각 discipline의 비중이 어느정도 되는지 나타낸 도표이다.

- 프로젝트 초반에는 요구사항 분석, 환경세팅, management의 비중이 크다.

- 프로젝트가 중반 이상으로 가면 implementation, test의 비중이 더 높아진다.

- 이런식으로 프로젝트 초기에 discipline과 수행할 활동, 그에 따른 artifact를 표로 정리할수도 있다.

- 그 다음 각 phase에서 discipline의 비중등을 표시한다.

- 프로젝트의 성격에 따라 적절하게 define해서 사용하면 된다.

6. UP Artifacts

- glossary : 용어 정리

- vision : 요구사항의 목적, 범위 등의 high level 개념들

- use case : functional 기능들 표현

- supplementary specification : non-functional한 내용들이 담긴다. (기능의 사용성, 신뢰성, 성능, 제약 등의 성격)

- 위의 예시를 보면 POS 시스템 디자인에 대한 supplementary specification이다. 글자 크기, 화면의 크기 같은 non-functional한 내용이 주로 담겨있다.

 

- 위의 나온 내용 밖에도 다양한 artifacts들이 나올 수 있다.

- artifact들이 Iterative 개발 프로세스의 어느 단계에서 만들어지고 refine되는지 나타내는 표이다.

7. 애자일 방법론 소개 및 UP와의 차이점

- 애자일이란 소프트웨어 개발 단계를 일련의 선형적 순서로 구성하는 Waterfall 방식의 문제점에 대응하기 위해 고안된 소프트웨어 개발 방법론이다. 즉 실제 작동 가능한 소프트웨어를 개발하고 지속적으로 제공하기 위한 새로운 접근 방식을 담고 있다. 

 - 핵심은 작동하는 소프트웨어의 작은 구성 요소를 신속하게 제공하여 고객의 만족도를 높이는데 있다. 경량화된 소프트웨어 documentation을 선호하며 전체 소프트웨어 개발 life cycle을 정기적인 반복된 sequence들로 구성한다. 

 - 반복되는 각 sequence는 요구사항 파악, 개발, 테스트 등의 단계를 포함한다. waterfall 방식에 기반한 프로젝트들이 뒤늦게 risk를 파악했을 때 대응의 어려움, 심지어 소비자에게 product가 인도되기 전에 폐기되는 등의 문제점에 대응할 수 있도록 애자일은 작은 sequence들의 반복으로 더 잦은 검증과 고객의 요구사항 파악 및 반영을 수행한다. 

- 1. 변화에 대응하는 것이 계획을 따르는 것보다 우선  : 애자일은 long-term planning cycle을 포함하지 않는다. 반복된 planning, implementation 단계를 통해 변화에 쉽게 대응하도록 한다. 

- 2. 사용자의 요구사항이 명확하지 않다면? : 반복된 검증과 요구사항 파악의 기회가 매 cycle마다 반복되기 때문에 최종 결과물의 성공 가능성이 점점 높아진다. 

- 3. 높은 품질과 빠른 제품 인도 : 각 작업 cycle은 비교적 짧은 주기로 반복되기 때문에 구현 기능의 빠른 integration이 가능하다. 매번 반복되는 testing과 사용자로부터의 피드백도 더 빠르게 듣고 다음 iteration에 반영할 수 있기 때문에 제품은 더 높은 품질을 갖추게된다. 

 애자일 프로세스의 한 cycle은 보통 아래 단계들을 포함한다. 

• Planning - 작업을 작은 부분들로 쪼개고 우선순위를 부여하여 앞으로 반복될 iteration에 할당. 
• Analysis - 소비자의 requirements를 파악한다. 
• Design - 본격적 개발 시작 
• Testing - 결과물 검증 및 사용자 피드백을 통한 점검 

 

- up도 애자일이 추구하는 목적과 반복적 접근을 따른다는 점에서 비슷한 점이 많다. 

- 1. 반복적이고 점진적인 개발 : 여러번 반복되는 iteration마다 프로젝트는 점점 정제되고 확장된다. 

- 2. architecture centric : architecture 설계는 프로젝트 전반에 걸쳐서 앞으로의 iteration들에게 영향을 줄 가능성이 아주 높은 작업이다. 이 작업에 높은 risk를 부여하여 가장 먼저 수행하도록 한다. 즉 초기 architecture을 설계하고 그 중심으로 개발을 수행하도록 한다. 

- 3. risk focused : 많은 iteration중에서도 앞으로 발생할 수 있는, risk가 높은 작업들을 우선적으로 수행하도록 한다. 

- 4. use-case driven : 각 iteraton마다 client의 requirements를 파악하도록 한다. 그 단계의 artifact로 use case model 등이 생산될 수 있다. 

- up는 아래 큰 네 단계가 존재하고 각 단계안에서 iteration이 수행된다.

• Inception - 프로젝트의 장기적 목표, 비용, business 중요성 등을 파악하는 단계이다. 프로젝트의 feasibility를 결정한다. 보통은 반복되지 않는 작업으로 짧은 기간 안에 수행된다.
• Elaboration - 본격적으로 iteration들이 수행되는 단계이다. Risk, business value등 우선순위가 높은 requirement들을 먼저 수행한다. ex) architecture 설계 
• Construction - risk가 낮고 상대적으로 중요도가 낮은 작업들이 iteration으로 수행된다. 
• Transition - 소비자에게 완성된 제품을 인도

- 시간이 지나면서 새로운 phase로 진입하지만 각 phase안에서 좌측 세로로 나열된 작업들의 iteration들이 이루어진다.  

좌측에 나열된 각 discipline의 비중을 살펴보자. 프로젝트 초반에는 요구사항 분석, 환경세팅, management의 비중이 크다. 하지만 프로젝트가 중반 이상으로 가면 implementation, test의 비중이 더 높아진다.