[펌] [안영회의 UML 강좌12] - Iterative Development

##########0*0 반복적인 개발에 대한 이해

2 .0 Waterfall Development와 Iterative Development

3 .0 요약

##########1*

##########2*
이번 장은 Behavior와 Structure를 배울 차례인데 순서대로 강좌를 따라오신 분이라면 상당히 머리가 복잡할 수 있을 것 같아서요. 저도 그랬고, 사실 아직도 혼란스럽거든요. 방법론에 대해 거의 언급함이 없이 UML 자체만 배우다 보니 도대체 이걸 왜 하는가 하는 의문을 가지게 되는 독자님들도 계실 듯 합니다. 그래서 이때쯤 객체지향 방법론의 가장 특징적인 점인 Iterative Development 즉, 반복적인 개발에 대해 언급하고자 합니다.

반복적인 개발에 대한 이해

객체 지향적인 개발은 대체로 반복적인 방법을 채택합니다. 폭포수 모형 혹은 Waterfall Model이란 것을 들어보셨나요? 분석을 다 하고 나서, 설계를 하고, 그리고 구현을 하는 식으로 일목요연하게 단순하게 개발을 해나가는 방법을 모형화 것입니다.

이러한 방법은 이해하기에는 수월하지만 많은 문제점을 드러냈습니다. 그 중 하나가 고객의 요구를 제대로 파악하지 못해서 생기는 점이죠. 고객이 실제 프로그램을 보지 않은 상태에서 프로그램이 어떻게 동작했으면 좋겠다고 상상하는 일은 쉽지 않습니다.

결국 다 만들고 나서 보니 고객이 자신이 원하는 어떤 기능이 빠져있는 것을 발견하고는 이를 요청할 수 있습니다. 그런데 대부분의 경우 그러한 기능을 추가하려면 상당부분 수정이 필요한 경우가 비일비재합니다.

그래도 고객의 요구에는 맞춰야 하니 임시방편으로 해당 기능을 추가해주고, 또 그렇게 되면 자연히 처음의 설계 의도와 달라져서 유지보수가 어렵게 되는 것이죠. 아래의 그림은 강좌 초반에 보여드렸던 RUP의 개발 공정에 관한 그림입니다.

##########3*
그림 12-1. RUP의 개발 공정

전에도 말씀 드린 것처럼 RUP는 대표적인 객체지향 개발 방법론입니다. RUP에 대해서 잠시 살펴보겠습니다. RUP 자체에 대해 배우고자 함이 아니라, 이를 통해서 반복적인 개발이 왜 필요하고, 어떤 흐름으로 진행되는지를 살펴보자는 것이죠.

우선 왼쪽의 Workflows 구분을 봅시다. 상단은 Process Workflows라고 이름이 붙여져 있고, 아래쪽은 Supporting Workflows라고 명명되어 있네요. Process Workflows는 또 다른 말로 Core Workflows라고도 합니다. 실제 프로젝트 수행의 핵심적이 부분이 되는 일들이죠.

Supporting Workflows는 프로젝트 수행 과정에서 환경적인 측면을 관리하는 일들입니다. 가령, Management라는 workflow는 프로젝트 관리를 의미하는 것이구요. Configuration Management는 최근 부각되고 있는 형상관리 이고, Environment라면 개발자들의 작업공간이나 개발 중간의 결과물에 대한 저장공간과 같은 제반 사항들에 대한 지원을 의미하죠.

Supporting Workflows는 본 강좌와는 크게 관계가 없으니 차치하도록 하구요. Process Workflows 부분을 살펴보죠. 그림 12-2는 RUP에서 Process Workflows만을 보여줍니다.

##########4*
그림 12-2. RUP의 개발 공정

우선 반복적인 개발에 대해 이해하기에 앞서서 무성한 용어들에 대해 간단히 알아야 할 것 같습니다. Business Modeling이란 것은 업무를 명확히 하는 것입니다. 고객이 무엇을 하는지 명확해야 만들고자 하는 프로그램이 무엇을 할지 알 수 있는 것이니까요.

Requirements는 요구사항을 파악하는 것이죠. Analysis & Design은 말 그대로 분석 및 설계이고, Implements는 구현, Test가 있고, 마지막으로 Deployment는 설치 혹은 배포하는 과정입니다.

 

1 .0 반복적인 개발에 대한 이해

##########5*0 Waterfall Development와 Iterative Development

3 .0 요약

##########6*

##########7*
Waterfall Development와 Iterative Development

이해를 돕기 위해 Waterfall Model을 잠시 살펴 보죠. 그림 12-3은 Waterfall Model입니다.

##########8*
그림 12-3. Waterfall Model

RUP의 Process Workflows를 위에서 아래로 본 것과 상당히 유사하다는 것을 눈치 채셨나요? 그러나 RUP에서는 시간의 흐름을 표현한 것이 위에서 아래가 아니라 좌에서 우로 가는 방향의 Phases입니다. Inception -> Elaboration -> Construction -> Transition의 순서로 개발이 진행되어 가는 것이죠.

Waterfall 방식에서는 순서대로 했던 것을 RUP와 같은 반복적인 개발에서는 섞어서 하게 됩니다. 이러한 것이 어떤 의미를 갖을까요? 다음 그림을 볼까요?

##########9*
그림 12-4. Iterative Development의 특징

그래프의 두께는 일의 양을 표현합니다. Requirements와 Analysis & Design은 거의 유사한 시기에 행해지는 것을 볼 수 있습니다. 과거 Waterfall 방식에서 고객의 요구사항을 먼저 다 수집해놓고 분석과 설계를 하게 되어 수집하지 않았던 요구사항은 고려할 수 없었습니다.

그러나, Iterative Development를 하게 되면 요구사항을 토대로 분석과 설계를 하다가 미처 고객이 생각하지 못했던 요구사항을 고려해 볼 수 있죠.

그러한 분석 및 설계한 내용을 토대로 다시 요구사항을 수정하면서 좀더 완전하게 요구사항을 수집할 수 있게 된 것입니다. 또한, 요구사항 수집, 분석 및 설계가 끝나기도 전에 이미 구현을 합니다. 구현된 결과를 보면서 고객의 요구사항과 분석, 설계한 내용이 제대로 실현되어 가는지를 검증할 수 있고, 문제가 발생하면 이를 적용하여 구현 초기에 수정이 가능하게 되는 것이죠.

이렇게 유연하고 반복적인 개발을 통해서 실패에 대한 위험을 줄이는 것입니다. 또한, 고객과 의사소통이 중요하게 되고, 중간 결과가 일찍 나오기 때문에 고객과의 신뢰 측면에서도 매우 좋다고 할 수 있습니다.

이제 정리를 해야겠군요. RUP의 경우도 시간의 흐름과 일의 비중을 잘 보면 대체로 Waterfall 형태를 완전히 벗어나지는 않은 것을 볼 수 있습니다. 결국 완전히 새로운 개발 방법론이 아니라, 과거의 경험을 토대로 새로운 것을 추구해 놓은 것이라고 할 수 있습니다. 그림 12-5의 대각선으로 그어진 화살표를 보면 Waterfall과 같음을 알 수 있습니다.

##########10*
그림 12-5. RUP 와 Waterfall

 

 

##########11*

1 .0 반복적인 개발에 대한 이해

2 .0 Waterfall Development와 Iterative Development

##########12*0 요약

##########13*

##########14*
요약

왜 반복적인 개발을 하는지 이해하셨나요? 정 이해가 안가셨으면 한마디로 요약을 해드리죠. Waterfall(폭포)는 꺼꾸로 흐르지 않습니다. 한방에 모든 것을 거는 것이죠. 극단적으로 말씀 드리면 ‘모 아니면 도’가 될 수도 있습니다. 실패의 위험이 많다는 것이죠.

반대로 반복적인 개발은 중간중간 잘 되어 가고 있는 점검을 해보면서 조심스럽게 전진해 나가는 방식입니다. 이제는 다들 이해하셨겠죠? 이보다 더 쉬울 순 없다!

갑작스레 방법론을 언급한 것은 강좌의 순서가 혼란스럽다는 느낌을 받으시는 분들이 많을 것입니다. 대체로 개발 순서에 맞춘 것이라 그렇습니다. 클래스를 할 요량이면 클래스를 쭉 하고, 객체에 대해서 하려면 객체에 대한 얘기를 다 하고 넘어가야지 마구 왔다 갔다 하는 거 아니냐 하는 느낌을 받으신 분도 있을 것입니다.

중도에 포기하고 읽기를 그만 두신 독자님들이 더 많다고 생각이 됩니다. 그래서 방법론을 언급했습니다. 이러한 개발 하에서 UML도 여러 개의 다이어그램이 병렬적으로 서로 도와 가면서 진행해 나가는 것입니다.

유스케이스 따로, 클래스 다이어그램 따로, 객체의 상호작용을 보여주는 다이어그램이 독립적으로 그려지는 것이 아니라, 이렇듯 다른 다이어그램을 그려나가는 과정에서 미처 알지 못했던 것들을 알아 가고, 그러면서 서로 하나의 시스템 혹은 프로그램을 구체화 시켜 나가는 과정입니다.