유스 케이스를 이용한 반복 개발 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  제안 및 의견 피드백

난이도 : 초급

Kurt Bittner, Communities of Practice Architect, IBM

2006 년 7 월 28 일

유스 케이스 기반 방식을 사용하여 IBM Rational Unified Process(RUP) 기반 프로젝트를 계획하는 방법을 설명합니다. 프로젝트의 각 단계(phase)에서 반복(iteration)을 계획하는 패턴이 제시되는데 프로젝트 작업을 구성하는데 있어 쉽고 실용적인 접근방법을 제공할 것입니다.

반복적인 소프트웨어 개발 개요

모든 사람들은 유스 케이스를 찾고 작성하는 방법, 이들을 개발하는 방법, 자세히 설명하는 방법 때문에 고민한다. 일단 이러한 기술을 마스터하면 다음과 같은 질문에 직면하게 된다.

• 언제 수행하는가?
• Rational Unified Process® (RUP®)의 단계, 즉 개념화, 상세화, 구축, 전이 단계는 언제 발생하는가?
• 반복 1에 유스 케이스 A를 작업하고, 반복 2에 유스 케이스 B 에 대해 작업하는가?

이 글에서는 반복 개발에 대한 일반적인 개요를 설명하고 유스 케이스를 사용하여 반복을 실행하는 방법과 서로 다른 반복(iteration)과정에서 유스케이스의 일부분을 갖고 작업하는 방법을 설명한다.다양한 RUP 단계에서 어떤 것을 해야 할 것인지에 대해서도 이야기 하겠다. (이를테면, 개념화 단계에서 해야 할 일, 상세화 해야 할 일 등)

전체 프로젝트의 플래닝 lifecycle. 그 전에 RUP의 단계를 이해해야 하고 반복들이 단계로 그룹핑 되는 방법에 대한 개념을 정립해야 한다. 특히 RUP의 단계들은 오해의 소지가 많다. 사람들은 개념화(Inception)를 요구 사항(Requirement)으로, 상세화(Elaboration)를 분석과 디자인(Analysis and Design)으로, 구축(Construction)을 구현(Implementation)으로, 전이(Transition)를 전개(Deployment)로 동일시하고 있는데, 이는 잘못된 것이다. 마지막은 거의 맞지만 다른 정의들은 틀렸다. 우선 전체적인 프로젝트의 플래닝 라이프사이클에 대해 알아보도록 하자.

위로

전체 프로젝트의 플래닝

"폭포(Waterfall)형" 프로세스 라이프사이클을 따르는 프로젝트의 전형적인 방식은 다음과 같다.

1. 모든 요구 사항들을 파악한다.
2. 요구 사항들을 분석한다.
3. 디자인을 정의한다.
4. 솔루션의 컴포넌트를 코딩한다.
5. 컴포넌트들을 통합한다.
6. 통합 솔루션을 테스트한다.

이러한 단계들 간 피드백 루프가 있을 수 있지만 일반적인 관례에서는 다음 단계로 옮겨가기 전에 특정 단계가 거의 완료되어야 한다는 것이다. 반대로, 반복 프로세스를 사용하면, 반복할 때 마다 어느 정도의 RUP 단계(요구 사항, 분석, 디자인, 구현, 테스팅)을 수행하게 된다. 하지만 이 프로세스를 구현하려고 할 때 개념화 단계에서 갑작스러운 난관에 직면하게 된다. 무엇을 (어느 정도) 해야 하는지, 언제 해야 하는지, 유스 케이스를 사용하여 프로세스를 어떻게 실행하는지 등이 명확하지 않기 때문이다. RUP 단계를 잘 이해하는 것 만이 이러한 난관을 극복하는데 도움이 된다.

그림 1: 기존 (폭포형) 소프트웨어 개발 vs. 반복 소프트웨어 개발

반복 개발 프로세스의 가장 긍정적인 측면들 중 하나는 이 방법을 사용하지 않았을 경우에는 프로젝트 수행과정에서 자신이 어떤 위치에 있는지를 프로젝트의 부분들을 통합하려고 할 때에서야 비로소 파악할 수 있고 심지어 파트를 통합하는 과정에서 예상과 달리 각 파트들이 서로 맞지 않아 파트의 통합자체가 어렵게 되는 경우가 있는데 반복개발을 통하여 이러한 문제를 사전에 다룰 수 있게 된다는 것이다. 반복 접근 방식은 프로세스 초반에 위험성 컴포넌트들을 구현 및 통합하여 특정 종류의 리스크들을 초기에 다루게 된다. 이렇게 초반에 리스크를 다루는 것이 리스크를 감소시키게 되는 이유는 리스크는 실제로 직접 어떤 것을 만들고 각 부분들을 조립해 본 이후에야 리스크의 완화 여부를 알 수 있기 때문이다. 그림 2는 두 개의 접근 방식에서의 중요한 차이이다.

그림 2: 라이프사이클

유스 케이스와 함께 반복 접근 방식을 사용하여 리스크에 직면하는 방식은 처음에는 리스크를 규명한 다음, 그러한 리스크를 사용하여 유스 케이스 시나리오를 만들어서 그러한 리스크를 대응하도록 하는 것이다. 그런 다음, 주어진 반복 상황에서 그러한 시나리오들을 분석, 디자인, 구현, 테스트 한다. 프로젝트 초반기에 너무 많은 시스템을 너무 일찍 구현하지 않도록 시스템의 어떤 부분이 아키텍쳐적으로 덜 중요한지 또한 시간에 덜 민감한지 결정한다. 그런 다음 초기 반복(iteration)에서는 그러한 부분은 실제 구현하지는 않고 테스트만 가능한 stub 상태로 둔다. ¹ 이런 방법으로 리스크 감소하는데 별 도움이 되지 않는 시스템 부분을 구현하느라 시간을 허비하지 않아도 된다. 이러한 방식의 순전한 효과는 시스템의 위험성 부분들을 먼저 구현함으로서 프로젝트 초반에 위험성을 완화시키면서 프로그레스를 객관적으로 평가할 수 있다는 점이다.

RUP 단계

RUP는 프로젝트를 네 가지 단계들로 나눈다. 이들 각 단계들은 특정 리스크에 집중되어 있다. 그림 3은 각 단계들을 요약한 것이다.

그림 3: RUP 단계의 초점

각 단계의 작업들은 주로 리스크를 줄이고 프로젝트를 앞으로 진행시키는데 초점을 맞추고 있다. 각 단계의 결과는 마일스톤을 나타낸다. 마일스톤은 결과를 평가하고 결정을 재 평가하여 프로젝트를 앞으로 진행시키는 포인트가 된다.

그림 4: 메이저 마일스톤

다음 섹션에서는 각 단계에서 수행되는 액티비티의 초점에 대해 설명하기로 하겠다.

개념화 단계(Inception Phase)

개념화 단계의 목적은 비즈니스 리스크를 제어하는 것이다. 다시 말해서, 우리는 다음 사항을 확인해야 한다.

• 우리가 해결하고 있는 문제들을 이해하기
• 솔루션을 만들어내기 위해 경제적으로나 기술적으로 가능한 방식을 사용하고 있다는 자신감

문제에 대한 솔루션을 설명하기 위해 시스템이 수행하는 것을 표현할 방식이 필요하다. 주로 시스템이 지원해야 하는 유스 케이스를 규명(자세히는 아니고 대략적으로 설명)한다. 더욱이 시스템의 기술적 가능성을 평가하려면 솔루션을 연구 및 정량화 하여 이것이 가능한지의 여부와 비용(시간과 돈)은 얼마나 드는지를 이해해야 한다. 그런 다음에야 우리는 프로젝트를 수행할 가치가 있는지를 알 수 있다.

개념화 단계가 끝나기 전까지, 프로젝트가 가능한지에 대해 합리적인 이론적 근거가 있어야 한다.

• 우리는 시스템을 구현할 수 있다.
• 미래의 문제를 해결한다.
• 목표 날짜와 예산 내에서 수행할 수 있다.

우리가 무엇을 해야 하고 어떻게 해야 하는지에 대해서는 자세히 모른다. 하지만 우리의 프로젝트가 실현 가능하다는 것은 알고 있다.

상세화 단계(Elaboration Phase)

상세화 단계의 목적은 아키텍처와 기술적 리스크를 제어하는 것이다.

• 개념화 단계에서 제안했던 솔루션을 신중히 검토한다.
• 이것이 실제로 실현 가능한지를 검토한다.

기본적인 방식은 복잡하거나, 기술적으로 고급이거나, 위험성이 많은 솔루션의 일부를 구현하는 것이다. 솔루션이 먹힐 것이라는 지나친 낙천주의를 경계하기 위해서이다. 여기에서 중요한 것은 디자인과 플랜을 단순히 리뷰 하는 것이 아닌 시스템의 일부를 실제로 구현하여 테스팅 하는 것이다. 상세화 단계가 끝나기 전에 우리는 다음과 같은 문제에 직면하게 될 것이다.

• 퍼포먼스
• 확장성
• 신뢰성
• 기타 기술적 문제들

이러한 방식으로 우리는 제안된 솔루션이 실제로 작용한다는 것을 확신하게 된다.

솔루션이 비슷한 문제들을 푸는데 사용되었기 때문이든 또는 사전 정의된 아키텍처를 갖고 있는 미들웨어를 사용하여 솔루션을 구현하기 때문이든 우리가 이미 입증된 아키텍처 방식을 갖고 있다고 믿더라도 상세화 단계는 중요하다. 이러한 상황에서 우리는 제안된(또는 후보) 아키텍처가 우리가 규명했던 기술적 리스크들을 완화할 수 있는지 여부를 평가해야 한다. 주어진 방식이 기술적으로 가능하다는 것을 입증하기 전 까지는 우리는 아직 상세화 단계에 있는 것이다. (스케줄은 상관 없다.)

구축 단계(Construction Phase)

구축 단계에서 우리는 프로젝트의 논리적 리스크를 관리해야 한다. 우리에게는 많은 작업들이 기다리고 있지만 비즈니스와 기술적 리스크가 제어된다면 모든 작업을 다음과 같은 조건 하에 수행할 수 있는지가 문제로 남는다.

• 할당된 시간 안에
• 지정된 예산으로
• 할당된 리소스를 사용하여

여러분은 범위 관리를 해야 하지만 일반적으로 구축 단계의 포커스는 작업을 분해하는 것이다. 유사한 작업을 하는 팀들을 활용하고, 브랜칭을 통해서, 그리고 변화 관리 시스템을 사용하여 변경 사항들을 합병하여 큰 규모의 프로젝트를 관리할 수 있다. 통합 구현, 브랜칭, 변경 관리 시스템을 사용하여 변경들을 합병할 수 있다. 구축의 끝에 가서는 사용할 수 있는 솔루션을 갖게 되지만 이것은 사용자에게는 완전히 전개할 수는 없다.

전이 단계(Transition Phase)

전이 단계의 목적은 솔루션을 목표 사용자 커뮤니티에 전개하는 것이다. 전이 단계에서는,

• 사용자를 교육해야 한다.
• 백업 및 복구 정책을 확립해야 한다.
• 데이터 센터에 솔루션을 인스턴스로 만든다.
• 데이터를 변환한다.

다시 말해서, 솔루션이 구현되기 전에 발생하는 모든 실질적이고 중요한 작업들을 관리해야 한다.

단계 별 작업 분포

그림 5: 단계별 작업 분포

앞서 언급했지만 개념화 단계(Inception phase)는 요구 사항으로, 상세화 단계(Elaboration phase)는 디자인으로, 구축 단계(Construction phase)는 구현으로, 전이 단계(Transition phase)는 전개로 그릇 인식되고 있다. 그림 5는 각 반복 단계(phase) 마다 각각의 디서플린(RUP의 요구사항(Requirement), 설계(Design), 구현(Implemention), 전개(Deployment)) 이 역할을 수행한다는 사실을 나타내고 있다.예를 들어, 개념화 단계에서 요구 사항의 40% 또는 50%를 수행하는 동안, 디자인 및 구현, 전개, 관리 오버헤드(플래닝, 평가, 측정)도 수행한다. 개념화 단계에서 디자인과 구현의 초점은 제안된 솔루션의 비즈니스 가능성을 가늠하는 개념의 입증이다.

상세화(엔지니어링 단계) 단계에서 작업 요구 사항의 60%에서 70% 정도를, 디자인의 반 정도를 전체 관리의 반 정도를 끝마치게 된다. 구축 단계에서 요구 사항들은 대부분 완성되고 솔루션을 베타 릴리스 형태로 배포할 준비가 되지만 남아있는 문제들이 있다. 전이 단계를 끝낼 때 그 작업은 완성된다.

각 단계는 특정 종류의 리스크가 완화되는 것에 상응하는 주요 마일스톤으로 끝을 맺는다. 각 반복의 끝에는 마이너 마일스톤이 생긴다. (그림 6) 마이너 마일스톤에서는 그 반복을 통해서 성취한 결과를 평가한다. 반복 평가를 통해 새로운 작업이 규명되기 때문에 후속 반복에 대한 플랜을 만들 시점을 생각해야 한다.

그림 6: 단계와 반복

단계와 반복 마일스톤은 우리가 정해진 바대로 잘 가고 있는지 확인하는 평가 포인트로 사용되며 프로젝트를 수행하면서 발생하는 변경을 조정하고 새로운 정보를 유연하게 받아들일 수 있게 한다.

그림 7: 반복이란 무엇인가?

각 반복 시 몇 가지 시나리오를 취하고 각각의 RUP 단계들을 진행한다. 요구 사항, 분석&디자인, 구현, 테스트(그림 7 참조) 개념화 단계에서 전개가 무엇을 의미하는지를 생각해보자. 우리는 개념 입증 (POC : Proof-of-concept) 프로토타입을 수행하고, 이것을 몇몇 사람들에게 보여주고, 이것이 그들이 원하는 것인지를 묻는다. 그렇다고 해서 개념화 단계의 반복을 통해 제품에 필적하는 코드를 작성하고 있다는 것을 말하는 것은 아니다. 또한 릴리스 테스팅을 수행한다는 의미도 아니다. 다만 우리가 해야 하는 다른 작업 외에 구현과 테스팅 작업을 수행한다는 의미이다. 상세화 단계를 거쳐 구축 단계로 진입하면서 우리는 점점 더 많은 코드를 만들게 된다.

그림 8: 유스 케이스 중심 개발

그림 8은 유스 케이스가 시스템의 작동을 구동하는 방법을 나타내는 모델이다. "Use Cases"라는 레이블이 달린 박스에 보이는 디스크립션의 크기는 디스크립션을 생성하는 것이 유스 케이스를 만드는 일의 대부분을 차지한다는 것을 상징하고 있다. 그 문서의 테스트 주위의 작은 흰 박스는 시나리오를 상징한다. 시나리오는 유스 케이스의 일부이다. 기본 흐름과 0 또는 그 이상의 대안 플로우이다.

우측 상단에 시퀀스 다이어그램이 보인다. 그림에서 이 부분은 일부는 각 시나리오가 그 시나리오를 이행하거나 실현하기 위해 여러 컴포넌트간 연결되고 협업하고 있다는 것을 보여주고 있다. 이러한 협업에 참여하는 컴포넌트들은 서로 인터랙팅 하여 유스 케이스에서 지정된 작동을 실현 또는 제공한다. 우측 하단에는 시나리오(유스 케이스 실현에 기반한 화이트 박스 테스트) 또는 유스 케이스 자체(유스 케이스 디스크립션에 기반한 블랙 박스 테스트)를 테스트 하는 테스트 케이스가 있다. 이 그림 어디에서나 문서와 UI 디자인을 유스 케이스에서 가져올 수 있다.

이것은 반복 개발과 이것의 주요 개념에 대한 개요에 불과하다. 실제 프로젝트 작업을 성공시킬 수 있는 방법을 자세히 이해하려면 이러한 개념들을 이해해야 한다.

위로

프로젝트 플래닝

그림 9: 플랜 레벨

플래닝은 여러 레벨에서 발생한다. 가장 높은 레벨은 프로그램 플랜이다. 프로그램은 여러 프로젝트들을 조정한다. 프로그램이 언제 유용한지를 이해하려면 현금을 인출하고, 영화표를 끊고, 사용자가 주차 티켓 비용을 지불할 수 있는 새로운 유형의 ATM을 구현하는 것을 생각해 보라. 이 제품을 전국적인(또는 전 세계적인) 은행 네트워크에 전개하려고 한다면 많은 고급 태스크들을 수행해야 한다.

• 다양한 많은 시스템과 로케일 간 작업을 조정해야 한다.
• 금융 기관에서 현재 구동되는 소프트웨어를 바꾼다.
• ATM 소프트웨어와 하드웨어의 롤아웃으로 변경 사항을 조정한다.
• 모든 시스템들의 변경 사항들을 마케팅 프로그램으로 조정하여 새로운 제품 오퍼링에 대해 고객을 교육시킨다.

모든 프로젝트들 간 작업의 조정에는 프로그램이 필요하다. 간단히, 우리는 하나의 프로젝트에 집중하기로 한다.

프로젝트 플랜은 전체 프로젝트를 위한 성취 지향의 플랜이다.

• 프로젝트의 메이저 마일스톤(단계 종료)의 날짜를 정의한다.
• 리스크들을 리스크가 다루어질 단계에 매핑한다.
• 시나리오들을 시나리오가 다루어질 단계로 매핑한다.
• 각 단계에 필요한 리소스의 고급 개요를 제공한다. (이것은 각 단계 플랜에서 조정될 것이다.)

전체 프로젝트 플랜은 상세를 저급 플랜-단계와 반복 플랜에 위임한다. 프로젝트 플랜과 단계 플랜들을 결합하는 것은 자연스러운 현상이다.

프로젝트 플랜 외에도 반복 시 수행 될 작업을 기술하는 각 단계별 상세 플랜이 있다. 반복 플랜은,

• 집중 할 시나리오를 규명한다.
• 비기능적 요구 사항들을 규명한다.
• 시나리오의 타당성을 검사하기 위해 실행할 테스트 케이스를 규명한다.

반복 플랜을 만들기 위해서는 반복에 매핑된 리스크를 고려한 다음 시나리오와 보완(전형적으로 비 기능적) 요구 사항들을 선택한다. 일련의 액티비티들을 나누어서 이전에 설명했던 RUP 디서플린(요구 사항, 분석, 디자인, 구현, 테스트, 전개)을 통해 이러한 시나리오와 보완 요구 사항들을 취한다.

그림 9는 (다중 프로젝트들로 구성된 프로그램의) 고급 플랜에서 프로젝트 플랜, 단계 플랜, 반복 플랜으로 옮겨 가면서, 플랜들 간 관계를 보여주고 있다.

위로

플래닝, 평가, 리스크

대부분의 프로젝트 관리 방식은 리스크를 고려하여 리스크 리스트를 만든다. 이러한 기존 방식과 반복 방식의 차이점은 리스크 리스트가 전체 프로젝트 작업을 움직이는 정도이다. RUP에서 리스크 리스트는 플래닝의 주요 드라이버이고 전채 프로젝트 목표 다음에 해당하는 것이다. 적극적으로 리스크에 대응하는 것은 RUP에서의 플래닝의 핵심 개념이다. 리스크 감소는 모든 것을 움직인다. 유스 케이스를 사용 하는 방법뿐만 아니라 유스 케이스 디스크립션에 어느 정도의 상세를 표현할지를 결정하는 요인이다.

그림 10: 프로젝트 프로그레스로서 정확성 증가 평가하기2

많은 사람들은 프로젝트 초기에 상세한 프로젝트 플랜을 만들고 이 상세한 플랜에 맞춰 프로젝트를 관리하려고 한다. 이 방식을 사용하면 대부분의 프로젝트는 예산이 초과되거나 늦어지게 된다. 작업이 형편없어서가 아니라 원래 플랜과 예산이 잘못된 것이다. 그림 10은 프로젝트의 과정 중 다양한 평가를 보여준다. 대부분의 초기 프로젝트 플랜들은 추측에 불과하다. 정보도 빈약하고, 많은 것을 모르고 있고 우리가 알고 있다고 생각하는 것이 다 그르다. 프로젝트에 더 진입할수록 더 많은 정보를 얻게 되고 변화가 줄어든다. 게다가 평가할 작업도 줄어들고 에러도 줄어든다.

우리는 다양한 방식을 사용하여 평가를 내릴 수 있고, 사실 다양한 평가 모델이 프로젝트의 다양한 포인트에서 유용하다. (한 두 개의 솔루션에 대한 대강의 비전만 있을 뿐인) 프로젝트의 초기에, 우리가 할 수 있는 일이란 예감에 기인한 기본적인 평가를 내리는 것이다. 비슷한 프로젝트들을 비교하기도 한다. 개념화 단계를 조금 지나고 초기 상세화 단계로 진입하면(솔루션의 요구 사항에 대한 정보를 얻게 된다) 기능 포인트 분석 기술 또는 유스 케이스 포인트 분석을 통해 전체 작업에 대한 생각들을 갖출 수 있다. 상세화 단계에 잘 진입하면 작업할 아키텍처가 생기게 되고 CoCoMo II3 같은 고급 평가 모델도 사용할 수 있다. 전이 단계는 완전히 다른 요소에 의해 움직인다. 솔루션이 전개 될 많은 사이트와 많은 사용자들이 바로 그것이다. 우리가 매번 반복할 때 마다. 주기적으로 평가를 수정하여 우리가 기대하는 것들이 아직도 실현 가능한 것인지를 확인한다.

반복 시 적업을 구성하는 패턴

그림 7에서 소개했던 것처럼, 일반적인 반복 패턴은 반복 시 할당된 리스크와 관련된 요구 사항들을 기술하고, 반복 시 발생하는 리스크와 연관된 시나리오를 지원하는데 필요한 시스템의 일부를 분석, 디자인, 구현, 테스트한다. 그림 7은 액티비티의 엄격한 순서를 나타내지만 현실에서는 보다 유연하다. 게다가 많은 것들이 동시에 발생한다.

많은 프로젝트 관리 방식은 표준 작업 브레이크다운 구조를 지정한다. 위에 설명했던 반복 시 수행되었던 작업의 패턴에서 우리는 반복을 계획하는 기본 구현 블록을 볼 수 있다. 간단히 표현하면, 반복 작업은 그림 11과 같다.

그림 11: 반복 시 동시에 발생하는 디서플린 관련 작업

단계 및 반복 결과 평가하기

각 반복의 끝에서 우리가 성취했던 것이 무엇인지를 따져봐야 한다.

• 우리가 다루고자 했던 리스크들을 완화시켰는가?
• 반복 시 선택했던 시나리오를 지원하는데 필요한 솔루션의 부분들을 구현했는가?
• 우리가 생각했던 것 만큼 성취하지 못했다면 그 플랜을 어떻게 조정할 것인가?
• 여전히 모든 작업을 수행할 수 있는가, 아니면 프로젝트 범위를 줄여야 하는가?

결과를 평가하고 향후 플랜을 조정할 때 지나간 징후들을 무시해서는 안된다. 리스크를 완화하는데 실패했다면 나중에 해결한다는 식으로 넘기기 쉽다. 물론 우리가 그렇게 한다면 심각한 문제는 불 보듯 뻔하다. 반복 시 의도했던 결과가 나오지 않는다면 프로젝트의 범위를 신중하게 검토해야 한다.

각 단계에 우리가 목표했던 것을 성취하지 못했지만 계속 진행한다면 더욱 심각한 문제들이 시작된다. 단계들은 성취 기반이다. 각 단계에 할당된 리스크들을 해결하기 전에는 결코 움직여서는 안된다. 경고 신호를 무시할 때 가장 큰 문제가 생긴다.

위로

개념화 단계의 플래닝 및 관리

어떤 사람들은 개념화 단계의 목적을 혼란스럽게 생각한다. 개념화 단계는 비즈니스 리스크를 완화하는데 목적을 둔다고 했던 우리의 초기 사명은 혼란스럽다. 개발 팀은 비즈니스 스테이크홀더들이 비즈니스 결정과 리스크들을 핸들링 한다고 생각하기 때문이다. ⁴누군가가 비즈니스 문제를 찾고 개발자가 비즈니스 목표와 리스크에 대한 교육에 투자를 하면 더 나은 솔루션 결정으로 이어진다. 일반적으로 비즈니스 이슈와 기술적 이슈 사이에 많은 문제들이 생긴다. 가용성, 보안, 퍼포먼스, 쓰루풋 등이 그것이다. 이 경우 이슈의 양 측면을 인지하는 것이 더 나은 결과를 이끈다. 개념화 단계는 비즈니스와 기술적 관점에서 이러한 문제들을 위해 협업을 할 수 있는 프레임웍을 제공한다.

전체적인 프로젝트 플랜은 각 단계의 기본적인 시간표를 구축하고 그 단계에서 다루어질 특정 리스크들을 규명한다. 개념화 단계는 비즈니스 리스크를 완화하는 것이 목표이기 때문에 개념화 단계는 나머지 프로젝트가 기업에 중요한 기치를 남길 수 있다는 것을 확신하는 단계이다. 프로젝트는 긍정적인 투자 회수를 만들고 의무적인 요구 사항들을 만족시키거나 time-to-market 요구 사항들을 충족시킨다. 개념화 단계에서 문제와 근본 원인들을 규명하고 솔루션에 대한 비전을 만든다.

개념화 단계에서의 작업은 세 가지 유형의 작업들에 기반한 트랙들로 구성된다.

• 문제 트랙: 문제를 이해하기
• 솔루션 트랙: 잠재적 솔루션을 규명하기
• 프로젝트 트랙: 솔루션을 구현 할 프로젝트를 구성하기

이러한 트랙들은 동시에 움직이며 서로 상호 작용한다. 해결될 문제들은 잠재적인 솔루션 범위에 영향을 주고 솔루션을 전달하기 위해 구성된 프로젝트가 실행되는 방식에 영향을 미친다. 프로젝트가 구성되고 자금이 조달되는 방식은 우리가 구현할 수 있는 솔루션을 제약한다.

문제 트랙

문제 트랙에서 우리는 문제의 근본 원인에 다다르려고 한다. 예를 들어, 대부분의 프로젝트의 시작점은 어떤 문제의 증상이 드러날 때이다. 비용이 너무 높거나 고객이 만족을 못하거나 고객의 필요가 채워지지 않을 때이다. 우리는 진짜 문제들이 무엇인지를 이해해야 한다. 이것은 솔루션을 제시하는 것 보다 선행되어야 할 문제이다. 다양한 기술들이 적용될 수 있는데, 문제를 찾게 되면, "왜 이런 문제가 생기지?"라는 것을 지속적으로 묻게 된다. 더 이상 "왜" 라는 질문이 나오지 않을 때 우리는 올바른 솔루션을 찾을 준비가 된 것이다.

문제를 보다 완벽히 이해하기 위해 누가 이것을 겪게 될 것인지를 알아야 한다. 누가 이 문제로 인해 영향을 받을 것인지를 생각함으로서 문제를 보다 잘 이해할 수 있다. 이를 효과적으로 수행하려면 스테이크홀더와 면담을 하여 그들이 문제에 어떤 영향을 받는지를 이해하고 어떤 솔루션을 기대하는지를 파악해야 한다.

게다가 규명된 문제들을 해결할 때의 이점을 인식하여 다양한 솔루션의 비용 효과를 평가할 수 있다. 문제를 해결하는 것의 이점은 물론 잠재적 솔루션의 비용과는 무관하다. 그럼에도 불구하고, 문제를 해결하는 것의 가치를 이해한다면 문제를 해결하는데 어느 정도를 투자해야 하는지도 계산이 나온다. 잠재적 솔루션을 기술하느라 많은 시간을 허비하기 전에 규명 과정의 초기에 일부 솔루션들을 제거할 수 있다.

문제 트랙에서 한 가지 잠재적인 함정은 솔루션을 "문제화"하는 것이다. 다시 말해서, 팀의 누군가가 이미 솔루션을 생각해 놓았고 이를 문제로 바꿔 말하는 것이다. 우리는 단순이 솔루션을 예상하는 것이 아니라 실제 문제를 이해해야 한다. 이것은 생각 보다 어렵다. 문제에 대한 결론을 쉽게 내리기 때문이다.

솔루션 트랙

솔루션 트랙에서 문제 트랙에서 규명된 문제에 대한 대안 솔루션을 연구한다. 이 순서에서 충분히 창조적이지 않으면 프로젝트는 실패한다. 충분한 대안 솔루션을 연구하지 않고, 하나의 대안 솔루션의 상세를 너무 일찍 정의하는데 초점을 맞춘다면 그렇게 된다. 다양한 브레인스토밍 기술을 활용하여 많은 솔루션들을 규명할 수 있다. (어떤 판단 없이) 솔루션을 규명하는데 우선 초점이 맞춰져야 하고, 문제 해결에 비용이 많이 드는 솔루션만 배제하도록 한다.

솔루션을 규명할 때 그 솔루션이 문제에 영향을 받는 각 유형의 사용자들을 도울 수 있는지를 확인해야 한다. 문제에 영향을 받는 사람들은 솔루션의 스테이크홀더가 된다. 기타 스테이크홀더로는 솔루션에 영향을 받는 사람들(솔루션을 지원하지만 사용하지는 않는 사람들)과 프로젝트 팀이다.

유스 케이스는 스테이크홀더를 위해 무엇을 해야 할지를 기술하게 하여 잠재적 솔루션을 정의하는데 도움이 된다. 솔루션의 작동을 연구하고 정의하는데도 도움이 된다. 유스 케이스 모델은 잠재적 솔루션을 기술한다는 것을 기억하라. 결국, 여러 개별 유스 케이스 모델을 개발하여 대안 솔루션들을 비교하는 것이 유용하다. 이 모델은 다양한 솔루션들을 시각화하고 다른 제안들에 대해 스테이크홀더로부터 피드백을 받도록 한다. 이 모두가 대안들 중 한 가지로 진행할 지의 여부를 결정하는데 도움을 준다.

이러한 유스 케이스 모델을 개발할 때 우리는 최소한 주요 액터를 구분하고 대안 흐름들을 간단히 그려야 한다. 시나리오를 정의하고 솔루션의 전체적인 스케줄과 비용에 대한 대략적인 평가를 내리려면 많은 정보가 필요할 것이다. 그런 다음, 솔루션을 진행할지의 여부를 결정할 수 있다. 유스 케이스를 사용하여 솔루션을 기술할 때 우리가 정확히 문제를 이해하고 있다는 것을 확인하고 솔루션이 스테이크홀더의 필요를 충족시키는지를 판단하기 위해 핵심 스테이크홀더와 이 모델을 경험해야 한다. 그들의 피드백을 통해서, 어떤 누구도 원하지 않고 실제 문제도 해결하지 못하는 솔루션을 개발하느라 많은 시간을 허비하는 위험을 줄일 수 있다. 슬프게도 이러한 현상은 여러 번 발생한다.

유스 케이스 모델에 더하여 작은 기능 프로토타입이 솔루션에 대한 피드백을 모으는데 유용하게 사용된다. 예를 들어, 스크린 모형을 사용하여 스테이크홀더가 시나리오를 경험하도록 하여 제안 솔루션에 대한 피드백을 받도록 한다. 투자는 적게 유연성은 높게 유지하면서 구현에 대한 아이디어는 계속 진화시키는 것이 중요하다.

비전 문서에는 특정 솔루션의 요약과 해결된 문제들이 제시되어 있다. 우리가 믿을 수 있는 많은 솔루션을 갖고 있다면 각각에 대한 개별 비전 문서를 개발해야 한다. 개별적인 비전 문서는 대안 방식들 사이에서 공식적인 선택을 할 경우 매우 유용하다. 대부분의 프로젝트는 대안들을 비공식적으로 검토한 다음 한 가지 방식을 채택한다.

프로젝트 트랙

개발팀은 개념화 단계에서 제 삼의 활동을 수행한다. 프로젝트를 계획하고 시작하는 것과 관련이 있다. 솔루션 트랙 액티비티들이 잠재적 솔루션들을 규명하고 정의하는 반면 프로젝트 트랙의 역할은 프로젝트의 비용, 리소스, 고급 스케줄을 평가하여 솔루션이 현실적으로 가능한지를 결정한다.

개념화 단계를 시작할 때 정의된 솔루션이 부족하다는 사실은 딜레마를 만든다. 이 단계를 시작할 때 프로젝트가 얼마나 오래 걸릴지, 비용은 어느 정도가 될지 등에 대해 아무런 단서가 없다. 이것은 초기에 매우 상세한 계획을 세우고 나머지 프로젝트 기간 동안 계획을 실행하고 싶어하는 사람들에게는 치명적인 결함으로 다가온다.⁵ 우리가 앞으로 나아가기 위해서는 개념화 단계의 불확실성을 인정해야 한다.

일단 잠재적인 솔루션을 선택하지만 프로젝트 트랙에서의 작업은 나머지 프로젝트 동안 플랜을 만드는 것이다.

• 각 단계의 기간과 목표를 정한다.
• 각 단계의 반복 구조를 계획한다.
• 예비 리스크와 시나리오들을 반복 과정 속에 매핑한다.
• 프로젝트용 리소스 플랜을 만든다.
• 단계에 필요한 기술과 인력의 수준을 규명한다.
• 전체적인 프로젝트를 평가한다.

가끔, 개념화 단계에 많은 반복이 필요한가 라는 의문이 생긴다. “가끔은” 그렇다. 다음과 같은 경우 특정 솔루션이 정말로 알맞은 것인지를 결정하기 위해 한 번 이상의 반복이 필요하다.

• 비즈니스 문제들이 진단하기 어려울 경우
• 솔루션의 적합을 이해하기 힘든 경우
• 솔루션이 기수적으로 입증되지 않은 경우
• 다중 솔루션 중에서 선택하기 힘든 경우

개념화 단계의 초기에 이것을 예견하는 것은 거의 불가능 하기 때문에 첫 번째 반복을 완료한 후에 결정을 내린다. 이 시점에서 상세화 단계로 진행하기 전에 제안된 한 개 이상의 솔루션의 가능성을 평가하는데 시간이 더 필요한지의 여부를 결정할 수 있다.

ACME Super ATM을 위한 개념화 단계

예제로 돌아가서, 자바 기반, 모듈식, 저렴한 개발 비용으로, 그래서 모든 종류의 다양한 자동 판매기를(우편, 이벤트 티켓, 주차 티켓)를 설정할 수 있는 새롭고 놀라운 ATM(그림 12)를 구현하려고 한다면 프로젝트를 계획 할 프레임웍이 필요하다.

개념화 단계의 목적은 비즈니스 리스크를 제어하는 것이기 때문에 시장의 필요를 평가해야 한다. 아마도 이러한 필요를 펀드에 유연한 액세스를 제공하고 그들이 이러한 자금을 다양한 방식으로 사용할 수 있도록 할 것이다. 우리는 이 ATM을 금융 기관용으로 구현하기 때문에 목표 시장은 규명한 것이다. 문제 트랙에서 작업을 완수하기 위해서, 그러한 기관들에서 스테이크홀더들을 모아 그들의 필요를 파악해야 한다. 또한 다른 스테이크홀더들에게는 우리가 그들이 원하는 문제들을 해결할 수 있다는 것을 확신시켜야 한다.

그림 12: ACME Super ATM

솔루션 트랙에서 이러한 문제 디스크립션 정보를 취해서 문제를 푸는 방식을 공식화한다. 사실, 생각 속에만 있던 솔루션(새로운 유형의 ATM)을 시작했기 때문에 약간 앞으로 도약한 것이지만 실제로는 다소 일반적인 것이다. 이 솔루션은 머리로만 구상한 것이기 때문에 이것이 실제로 시장의 필요인지를 규명해야 한다. 한 가지 방법은 스테이크홀더들이 겪는 문제들을 시장의 기존 솔루션들과 비교하는 것이다. 비교할 것이 없다면 태스크는 좀더 쉬워진다. 다른 경쟁 솔루션이 문제에 대한 일부 솔루션을 갖고 있다면 솔루션을 달리해야 한다. 비전 문서에 이 모든 분석을 파악해 놓는다.

이 새로운 ATM을 구현하는 리스크들 중 하나는 시장이 포화상태라는 점이다. 이것을 누가 사려고 하겠는가? 시장에 나와있는 기존 제품들과 현격히 다르지 않는데 이것을 살 이유가 있겠는가?

우리의 잠재적 솔루션에는 다양한 "만약에…" 시나리오들이 들어있다. 예를 들어,

• 제품의 가격을 공격적으로 매길 수 없다면 놀라운 ATM을 구현해야 한다.
• 우리의 새로운 ATM이 기존 제품들 보다 네 배나 비싸고 금융 기관은 트랜잭션 달러 당 1 센트의 수수료를 부과한다면 어떤 누구도 사고 싶지 않은 놀라운 솔루션을 가지게 된다.

우리는 총 개발 비용을 평가하고 이를 선적할 단위의 수 대로 나누고 단위 당 개발 비용을 산정한다. 그런 다음, 제품을 유지(기술 지원, 마케팅, 관련 오버헤드)하기 위한 모든 비용을 감당할 마진을 얼마로 해야 할 것인지를 결정해야 한다.

비용과 프라이싱 정보 외에도 실제 시장의 필요를 평가해야 한다. 과연 고객들은 ACME Super ATM에서 제공하는 서비스를 진정 원하는가? 사람들이 ATM을 사용하여 비용을 지불하고 영화 티켓을 끊고 기존의 것과 다른 ATM 서비스를 수행할 것인가? 결국 ATM이 처음 도입되었을 때 대중이 이를 기꺼이 수락하기 까지 많은 시간이 걸렸다.

이러한 질문들에 대한 답을 내리기 위해 잠재적 솔루션에 대한 작은 프로토타입을 구현해야 한다. 예를 들어, 새로운 ATM의 모형을 만들어 여기에 마케팅 테스트를 수행하거나 제한된 기능을 가진 ATM을 구현하여 가용성 연구실로 가져가서 그 서비스를 기꺼이 사용하고 싶은지를 실험하는 것이다. 사람들이 구매하고 싶어하지 않는 서비스에 대한 완벽한 비즈니스 모델을 만들기 위해 많은 돈을 들이기 전에 이러한 유형의 분석을 수행하여 몇 년 전의 "신 경제" 기업이 얼마나 많은 돈을 절약했는지를 생각해 보라.

이러한 프로토타입을 구현하면 가외의 이점도 있다. 잠재적인 솔루션 비용도 알 수 있다. 앞서 언급했던 것처럼, 이러한 정보는 솔루션의 금전적 가치를 평가하는 자료가 된다.

개념화 단계 끝내기

개념화 단계를 끝맺기 위해 몇 가지 할 일이 있다. 앞으로 가져갈 하나의 솔루션 제안을 확립해야 한다. 이를 위해서는 솔루션이,

• 해당 문제를 해결해야 한다.
• (적어도 지금 현재) 기술적으로 가능해야 한다.
• 경제적으로 가능해야 한다.

모든 스테이크홀더들이 이러한 세 가지 포인트에 동의해야 한다. 적어도 프로젝트를 다음 단계로 진입시킬 때 기술적 가능성을 평가하고 이 방식의 "아키텍처"를 개발해야 한다.

그런 다음, 프로젝트 플랜을 만들어야 하고, 단계를 구성하며, 메이저 마일스톤을 기술하고, 리스크와 시나리오를 반복 과정에 매핑해야 한다. 이를 통해서 경제적 가능성도 평가해야 하고 프로젝트를 다음 단계로 진행시켜야 한다.

마지막으로, 나머지 프로젝트를 위해 팀을 모아야 한다. 프로젝트를 진행하려면 특정 기술력을 갖춘 사람들이 리소스 플랜을 수행해야 하고 적임자를 찾는데 시간이 걸린다.

가장 바람직한 개념화 단계의 결과라고 한다면 프로젝트를 진행하지 않겠다는 결정일 것이다. 기업이 감당할 수 있는 투자로는 어떤 문제를 해결할 수 없고, 또 어떤 문제들은 전혀 해결될 수 없다. 가끔은 불확실하거나 값비싼 솔루션이 필요한 문제를 해결하느라 시간을 낭비하기 보다 다른 문제들을 해결하는 것이 더 낫다. 개념화 단계 말미에 프로젝트를 취소하는 것이 종종 최상의 솔루션이 될 수 있다. 성공에 대한 희망이 거의 희박한데도 프로젝트를 진행시키는 것이 가장 큰(값비싼) 실수이다.

위로

상세화 단계의 플래닝과 관리

개념화 단계를 결론지으면서 중요한 두 가지를 얻었다. 다음 사항들에 합의를 이루었다.

• 해결되어야 하는 문제들
• 그러한 문제들에 대한 임시적인 솔루션
• 솔루션 비용

상세화 단계로 옮겨가면서 솔루션의 기술적 상세를 평가하는데 주목하게 된다. 이 솔루션이 정말로 기술적으로 가능한지를 확인하면서 솔루션에 대한 중요하고 취소할 수 없는⁶기술적 결정을 내리게 된다. 이를 위해서는 요구 사항에 대해 보다 자세히 이해해야 하며 솔루션의 중요한 부분들을 구현 및 테스트하여 우리의 추측이 올바른지를 확인해야 한다.

이미 언급했지만, 반복 플래닝의 기본적인 패턴은 (프로젝트 플랜에서 정의된) 해당 반복 시 다루어야 할 리스크를 사용하는 (관련 보안 요구 사항들과 함께) 시나리오 세트를 선택하는 것이다. 상세화 단계에서 언급된 리스크들은 기술적 리스크 또는 솔루션의 기술적 부분들과 관련된 리스크이다. 기술적 측면들은 종종 퍼포먼스, 신뢰성, 보안, 이식성 같은 다양한 시스템 품질과 관련이 있다. 상세화 단계는 아키텍처 문제에 집중한다. 이러한 "아키텍처" 적인 도전 과제들을 해결하려면 일관성 있고 체계적인 결정과 액션이 필요하기 때문이다. 이미 시스템의 개발이 진행 중일 때 이러한 결정들을 나중에 변경하면 스케줄과 예산 모두에 큰 금전적 손해를 입힌다.

상세화 단계와 시나리오 선택 기술

상세화 단계를 플래닝 하는 일은 많은 통찰력이 필요한 작업이다. 특정 시나리오를 분석, 디자인, 개발, 테스트 할 때 팀이 맞닥뜨리게 될 기술적 도전에 관한 통찰력이 있어야 한다. 하나의 시나리오는 유스 케이스의 기본적 흐름과 대안 플로우들로 구성된다. 구조적으로 중요한 시나리오들은 솔루션이 제한된다. 통찰력은 플래닝을 수행할 때 중요한 힘을 발휘한다. 왜냐하면 그 시기에는 작업에 대한 정의도 부실하고 시나리오도 엉성하게 규명되었고, 유스 케이스와 (시나리오가 기반하고 있는) 플로우들도 아직 완전히 기수되지 않았기 때문이다. 더욱이 유스 케이스의 상세를 아직 모르기 때문에 시스템이 그러한 유스 케이스들을 어떻게 실현할지도 확실하지 않다.

구조적으로 중요한 시나리오를 선택하는 기술은 특정 시나리오가 특별히 어려운 기술적 문제를 일으킬 것이라는 것을 시각화 하고 예견하는 데에 달려있다. 예견은 비슷한 문제들을 경험하면서 연마되고 다양한 문제 해결 방식에 통찰력이 필요하다. 만물 박사의 기술이든 전문가의 기술이든 모두 필요하다. 특정 방식에 대해 이론을 정립할 수 있는 기술과 함께 광범위한 방식들을 이해할 수 있어야 한다.

상세화 단계에 맞는 시나리오를 선택할 때 다음 항목들 간 균형을 맞춰야 한다.

• 시나리오의 수
• 기술적 리스크 정도
• 사용할 수 있는 시간과 리소스의 양

대부분의 기술적 리스크를 다루는 모든 시나리오를 선택한다면 프로젝트에 쓸 수 있는 모든 시간을 사용해 버릴 것이다. 몇 가지 시나리오만 선택한다면 몇 가지 중요한 문제를 빠트릴 위험이 있다. 시나리오 선택하는 핵심은 가장 적은 시나리오에서 가장 많은 리스크들을 다루는 것이다. 이로서 어떤 중요한 것을 잃을 위험성이 적어진다.

중요하게 고려해야 하지만 잊기 쉬운 한 가지 시나리오는 솔루션의, 설치, 설정, 관리에 관한 것이다. 오늘날 이러한 문제들은 많은 솔루션들의 복잡한 측면을 나타낸다. 24*7 시스템을 중지할 기회는 절대 없기 때문이다. 결국, 우리는 시스템을 중지 하지 않고도 변경 또는 업그레이드 할 수 있는 기능들을 사용해야 한다. 이러한 기능들은 예견, 플래닝, 생산성을 필요로 하고 그러한 문제들을 상세화 단계에서 다루어야 한다.

이러한 균형을 유지하는 최상의 방법은 숙련된 솔루션 아키텍처를 고용하는 것이다. 대안 방식을 이해하고 있고 그러한 방식들에 내재한 리스크들을 이해할 수 있는 사람이어야 한다. 역할에 맞는 적임자를 찾는 일은 프로젝트 매니저의 가장 중요한 일일 것이다.

• 구조적으로 중요한 총 시나리오의 수
• 동시에 작업할 수 있는 시나리오의 수
• 시나리오가 사용될 때 다루어야 할 문제들 간 의존성

상세화 단계에 있는 팀은 통신 오버헤드를 낮추려고 하는 경향이 있기 때문에 솔루션의 가능성을 입증하기 위해 여러 반복이 취해진다.

기술적 가능성과 아키텍처 안정성 평가하기

아키텍팅에 대한 중요한 개념은 우리가 만족스러운 솔루션을 갖고 있다는 것을 확인시키기 위해 시스템의 일부를 구현 및 테스트하는 것이다. 과학 실험과 마찬가지로 제안 솔루션은 우리가 입증해야 할 일종의 이론이다. 과학자들과 마찬가지로 실험을 통해 솔루션의 적합성에 대한 우리의 이론이 올바른 것인지를 확인해야 한다. 시스템의 일부를 구현하고 테스트를 수행해 본다. 전체 시스템을 구현하여 테스트 할 필요는 없다. 솔루션의 특정 측면의 안정성에 대한 가설을 테스트 할 수 있을 정도로만 구현해도 된다. 상세화 단계를 개념화 하는 또 다른 방법은 R&D로 간주하는 것이다. 이것은 제조하는 것과 흡사한 구축 단계와는 반대되는 개념이다.

제안 솔루션의 기술적 가능성을 평가한다는 것의 의미는 퍼포먼스와 확장성을 평가한다는 것이다. 확장성을 평가하기 위해 많은 솔루션을 구현해야 하는 것처럼 보이지만 사실은 많은 시스템에서 확장성 영역에 해당하는 부분들은 비교적 적다. 결국 다양한 기술적 문제(구조적 리스크)에 영향을 받게 될 시스템의 일부를 선택하고 이것을 아키텍처 프로토타입에 구현하여 가상 워크로드를 부여해보는 것이 핵심 도전 과제이다.

ACME Super ATM의 상세화 단계

먼저 ACME Super ATM의 기본 유스 케이스의 모든 것을 규명하여 기능에 대한 합의를 도출해야 한다. 실제로 고객이 현금을 인출하고, 돈을 맡기고, 이체하고, 기존 ATM에서 할 수 있는 모든 것을 수행하고 청구서를 지불하고 영화 티켓을 구매할 수 있다는 것에 모든 사람들이 동의해야 한다. 모델의 구조나 추가 또는 배제, 또는 유스 케이스나 액터의 일반화를 고려하지 않아도 된다. 간단히 시스템이 수행해야 하는 중요한 것들만 이해하면 된다. 게다가 기본적 흐름을 구상하고 각 유스 케이스의 대안 흐름들을 규명하여 이 범위에 대해 일반적인 이해를 하면 된다.

다음에 해야 할 일은 구조적으로 중요한 시나리오를 규명하는 것이다. ACME Super ATM의 경우, 구조적으로 중요한 시나리오는 ATM의 기능적 측면에서 발생하지 않는다. 오히려 시스템 오류, 보안과 복구, ATM 네트워크에서 많은 트랜잭션을 동시에 실행해야 하는 필요성 등과 관련된 대안 흐름들에서 발생한다.

제안 솔루션의 확장성을 평가하기 위해서 1,000 개의 동시 현금 인출을 시뮬레이션 할 것이다. 또한 솔루션이 제안하는 아키텍처의 보안도 평가할 것이다. ATM을 훔치는 등의 물리적 시험도 해 볼 것이다. 또한 캐시 인출 시 네트워크 연결을 끊을 것이고, 트랜잭션 중간에 ATM의 전원을 차단하여 오류 내구성과 오류 복구 기능을 테스트 할 것이다. 예를 들어, 특정 금액을 인출하려고 했는데 돈이 지급되기 전에 전원이 나간다면 트랜잭션이 롤백 될 수 있을까? 돈을 인출할 때 트랜잭션이 완료되기 전에 전원이 나간다면, 전원이 돌아온 후에 그 작업이 완료될 수 있을지를 확인할 것이다.

또한 새로운 유형의 트랜잭션을 설정하여 현금 지급 외에 다른 것들을 수행할 수 있는지도 확인할 것이다. 이것을 평가하기 위해 현금을 지급하는 대신 영화 티켓을 프린트하는 시나리오를 디자인, 구현, 테스트 할 것이다.

이들 각각의 시나리오의 경우 유스 케이스를 만든다. 이것은 기본적으로 시퀀스나 인터랙션 다이어그램으로서 우리가 사용하고자 하는 컴포넌트를 규명하여 시나리오에서 지정된 작동을 수행하도록 한다. 동시에 테스트 케이스도 개발할 것이다. 이것은 시나리오를 검사하여 원하는 작동이 무엇인지를 알 수 있도록 해준다.

상세화 단계에서 테스팅을 통해 우리가 의도하는 것이 무엇인지를 고민해 보는 것도 좋다. 기존의 사고방식에서는 테스팅(주로 후반 단계에서 수행됨)은 밸리데이션에 집중한다. 시스템이 지정된 대로 작동하는지 검사한다. 상세화 단계에서 테스트를 하면 작동이 올바른지를 확인하는 대신 문제 영역을 발견하게 된다. 따라서 부하 테스팅, 퍼포먼스, 쓰루풋에 초점을 맞추게 되고 안정성과 결함은 신경을 쓰지 않게 된다. 게다가 이 시점에서는 사용자 인터페이스의 테스팅에 많은 시간을 보내고 싶어하지 않는다. 이들은 나머지 프로젝트 동안 많이 바뀔 것이기 때문이다.

단계에서 범위 변경 관리하기

우리는 일반적으로 상세화 단계에서 시작할 때 보다 더 많은 작업을 규명해 놓고 끝내게 된다. 이유는 간단하다. 문제를 풀기 위해 정말로 무엇이 필요한지를 알아내기 위해 요구 사항들을 검사하는데 시간을 많이 들이기 때문이고 처음 생각했던 것 보다 많은 작업이 있기 때문이다. 플래닝의 관점에서 볼 때, 이것이 의미하는 바는 프로젝트가 면밀히 스케줄링 되고 예산도 빡빡하게 잡혀있다면 다음과 같은 일들이 수반된다는 의미이다.

• 스케줄을 확장한다.
• 예산을 늘린다.
• 스케줄과 예산 모두를 늘린다.
• 솔루션의 범위를 조정한다.

스케줄 또는 예산 아니면 그 두 가지 모두를 확장하는 것은 올바른 일이다. 어떤 문제가 해결 해야 할 가치가 충분하거나 꼭 해결해야 할 경우, 그리고 이러한 평가가 공신력이 있을 경우 추가 시간이나 예산을 요청하게 된다. 지금까지 우리가 수행했던 작업이 여기에서 도움이 된다. 우리는 기술적으로 복잡한 솔루션 부분들을 구현 및 테스트 했기 때문에 솔루션을 구현할 수 있다는 확신은 매우 커진다. 게다가 솔루션의 일부를 구현하면 남아있는 작업도 줄어들게 되고 에러도 줄어들게 된다. 앞으로 진행할 프로젝트는 이제껏 해왔던 프로젝트 보다 평가하기가 훨씬 더 쉽다.

여전히, 이 시점에서도 프로젝트를 취소해야 할 수도 있다. 제안된 솔루션이 불가능하다면 프로젝트를 지속시켜서는 안된다. 가끔 이런 일이 발생하는데, 대게는 원래 계획했던 것 보다 비용이 많이 드는 경우이다. 이 시점에서는 프로젝트 자금을 늘려서 지속할 것인지 여부를 결정하는 것이다. 최대 프로젝트 펀딩의 임계치에 따라야 한다. 그 임계치는 개념화 단계에서 확립된 것이고 문제를 해결하기 위해 우리가 정한 최대 값에 가깝다. ⁷

문제를 해결하는 비용이 문제를 해결했을 때의 이점을 초과한다면 우리가 선택할 수 있는 것은 솔루션의 범위를 줄이는 것이다. 프로젝트 매니저와 스테이크홀더 대표들(문제나 솔루션에 영향을 받는 그룹들)간 협상을 통해 어떤 부분을 없애야 할지를 결정한다. 협상 프로세스 역시 반복적이다. 요구 사항들을 없앤다면 비용과 스케줄 평가에 예기치 않은 영향을 준다. 게다가 특정 요구 사항을 제거하면 충분한 검토 작업을 수행하지 않고는 비용 효과를 결정하기 힘들다.

범위 감소와 비슷한 것으로는 대안 유스 케이스 플로우가 있다. 전체 유스 케이스를 줄일 수 없지만 필요하지 않거나 지원할 필요가 없는 대안들이 무엇인지를 결정할 수 있다. 많은 팀들이 "기능"⁸레벨에서 범위를 관리하지만 기능에 대한 명확한 정의가 부족하고 기능이 유스 케이스 범위에 어긋난다면 범위 관리에도 쓸모가 없다.

상세화 단계 끝내기

상세화 단계 끝에서는 기술적 리스크를 완화시키는 문제를 보다 확고히 해야 한다. 이들을 완화시키는데 성공했다면 구축 단계로 갈 준비가 된 것이다. 그렇지 않다면 다음 단계로 진입할 수 있다고 자신을 속여서는 안된다. 일단 구축 단계에 진입하면 쉽게 되돌아 갈 수 없다. 그렇게 할 경우 스케줄과 비용에 미치는 영향력은 프로젝트 전체에 미칠 수 있다. 상세화 단계를 가볍게 끝낼 생각을 해서는 안된다.

ACME ATM 예제로 돌아가 보자. 상세화 단계 말미에는 앞서 규명된 기술적 리스크들을 다룰 수 있는 안정적이고 입증된 아키텍처가 갖춰져야 한다. 또한 상세화 단계 동안 발견된 어떤 새로운 리스크라도 다룰 수 있어야 한다. 다시 말해서 이 정도기 되려면 시스템 고장 테스트도 수행하고 네트워크도 단절 시켜보고 전원을 차단시키며 수 천명의 동시 사용자의 트랜잭션도 수행해 봤다는 것을 의미한다. 이 모든 것을 성공적으로 수행했다면 프로젝트의 성공 가능성도 밝아진다.

게다가, 솔루션에 대해 많은 것을 알고 있기 때문에 더 큰 확신도 생겼다. 믿을 수 있는 구체적인 정보를 가졌을 뿐만 아니라 실제 코드의 형태로 된 더 많은 정보도 있기 때문이다. 더욱이 모든 유스 케이스들을 규명했고, 주요 아키텍처 시나리오도 상세화 했다. 또한 구조적으로 중요한 보완 스팩들도 문서화 되었다. 이러한 요구 사항과 시나리오에 대한 테스트 플랜을 완료했고 디자인 모델, 테스트 케이스, 실행 코드를 완성했다. 간단히 말해서, 많은 중요한 작업들을 다 수행했다. 프로젝트의 나머지 부분도 매우 안정적인 기반으로 진행할 수 있다는 것을 의미한다.

그림 13은 날짜 별 전체 진행 과정이다.

그림 13: 날짜 별 진행 상황

위로

구축 단계의 플래닝과 관리

구축 단계의 초점은 할당된 시간 안에 나머지 작업들을 수행하는 것과 관련하여 논리적 상세들을 관리하는 것에 맞춰진다. 상세화 단계 후에 솔루션 아키텍처를 정비해 놓고 프로젝트 팀의 크기를 늘려 더 많은 작업을 동시에 수행할 지를 가늠하게 된다.⁹ 나머지 작업은 상세화 단계의 그것과 비슷하다. 남아있는 시나리오가 상세화, 분석, 디자인, 구현, 테스트된다. 구축 단계에서는 모든 기능을 구현해야 하고 상세화 단계에서 없앴던 기술적으로 간단한 코드로 돌아갈 수도 있다. 나머지 기능을 구현하기 때문에 상세화 단계에서 아키텍처 지향의 테스트 케이스를 계속 실행하여 새로운 작업이 강등되거나 아키텍처의 안정화를 방해하지 않는지를 검사한다.

구축 단계에 진입하면서 테스팅 작업은 성격을 변화시킨다. 이전까지는 안정성(개념화 단계)과 기술적 가능성(상세화 단계)를 입증하는 것에 초점을 맞추었다. 확장된 가용성 디자인 작업을 수행하여 애플리케이션에 사용된 시각적 스타일과 메타포가 안정화 되었는지를 확인했지만 사용자 인터페이스는 실제로 테스트하지 않았다. 이러한 테스트들을 수행하는데 드는 비용을 줄이기 위해 GUI 테스트를 자동화 하여 모든 구현 뒤에 이들이 실행되도록 한다.

이러한 개발 작업 외에도 문서와 지원 문서를 작성해야 하고 솔루션의 롤아웃을 계획해야 한다. 실제 롤아웃은 전이 단계에서 발생하지만 플래닝은 지금 시작해야 한다.

구축 단계에서 범위 관리하기

상세화 단계에서 언급했던 범위 관리 전략 외에도 너무 많은 작업이 남아있다면 다른 일들도 수행해야 한다. 리스크를 늘리지 않으면서 작업량을 줄일 수 있는 한 가지 전략은 간단한 시나리오와 관련된 작업을 줄이는 것이다. 다시 말해서 모델링 기술을 사용하여 공식적인 분석과 디자인을 수행하지 않고 대신 빠른 프로토타이핑 툴을 사용하여 단순한 시스템 일부를 구현한다. 이 전략의 가장 좋은 후보는 간단한 데이터 관리이다.

• 추가, 수정, 삭제
• 단순한 메뉴와 네비게이션
• 간단한 비즈니스 규칙에 의해 관리되는 작동

이러한 방식을 사용하면 잘못된 결정의 대가가 매우 큰 복잡한 비즈니스 트랜잭션을 구현하는 시나리오에 귀중한 시간을 절약할 수 있다.

변경 관리 전략

프로젝트의 범위가 상세화 단계를 거처 구축 단계에서 증가하는 것은 일반적인 현상이다. 이것이 반드시 나쁜 것은 아니다. 실제 문제를 더 잘 이해하고 있고 솔루션에 드는 비용도 이해하고 있다는 결과이다. 프로젝트 예산과 스케줄이 범위에 비례하여 늘어나지 않기 때문에 문제는 발생한다. 게다가 올바른 예상을 할 수 없으면 범위의 증가에 적응할 수 없다. 따라서 스테이크홀더의 동의를 얻지 못하고 추가 작업을 고려하기 때문에 많은 프로젝트가 실패한다. 프로젝트 팀이 올바른 일을 해왔다고 생각하더라도 예산과 스케줄을 맞추지 못해 실패했다고 인식된다.

그런데 이러한 문제는 생각보다 쉽거나 어려울 수 있다. 쉬운 부분은 문제를 해결하는 것은 스테이크홀더가 일단 중요하다고 생각하는 것에 동의를 하면 간단한 문제가 된다. 어려운 부분은 프로젝트는 언제나 늘 같은 목적만을 공유하는 것이 아닌 다양한 스테이크홀더들로 구성되어 있다는 점이다.

두 가지 해결 방안이 있다. 첫 번째는 프로젝트의 범위가 바뀔 것이고 범위, 스케줄, 예산 문제를 해결해야 한다는 인식을 심어준다. 두 번째는 모든 스테이크홀더가 이러한 문제들에 대한 의사 결정 과정에 동의하도록 하는 것이다. 이 부분을 초기에 동의하면 후에도 쉬워지기 마련이다.

구축 단계 끝내기

이 단계의 말미에는 모든 기능을 구현하고 애플리케이션을 사용자에게 전달 할 준비가 된다. 앞서 설명했지만 우리가 다 끝났다고 생각한다고 해서 끝나는 것이 아니라는 점이다. 리스크와 범위 관리에 성공했다면 정해진 시간과 예산 내에 올바른 솔루션을 전달할 준비가 된 것이다.

"충분한 " 솔루션이라는 목표를 이루었다면 언제 중지해야 할지를 아는 것도 중요하다. “한 가지 기능만 더”라는 유혹이 들지만 그러한 유혹과 싸워야 한다. 지금 어떤 것을 추가한다면 프로젝트는 지연되고 솔루션 인도도 불확실 하다. 더욱이 대부분의 시스템들은 이미 너무 복잡하고 많은 기능들을 갖추었다. 많은 경우, 이러한 기능들을 줄여주는 것이 더 낫다. 필요한 시나리오는 잘 작동하게 하면서 시스템을 사용하기 쉽도록 하는데 초점을 맞춘다.

위로

전이 단계의 플래닝과 관리

이전 단계에서 작업을 끝마쳤다면 전이 단계에서는 그 솔루션을 해당 사용자에게 전달해야 한다. 몇 가지 작업이 남아있지만 대게는 전개와 오류 픽스에 초점을 맞춘다. 더욱이 이 시점에서 새로운 요구 사항을 구현할 계획을 세워서는 안되지만 발견, 분석, 디자인, 구현, 테스트되는 요구 사항들이 불가피하게 있을 수 있다. 오류들도 정정해야 한다.

하지만 이 시점에서 모든 것이 개발에 관련되어 있는 것만은 아니다. 중요한 시스템의 경우, 프로젝트 전반에 걸쳐 유지되어야 하는 부분이다. 이제 애플리케이션을 개발 환경에서 제품 지원 환경으로 옮겨야 할 때이다. 솔루션이 완성되었다고 생각하기에 앞서 지원 사원을 교육하고 운영 절차를 확립하고 제품 데이터를 변환해야 한다.

더욱이 몇몇 시스템들은 트레이닝이 필요 없다. 사실 오늘날 많은 솔루션에는 새로운 소프트웨어와 하드웨어 뿐만 아니라 비즈니스 프로세스에 대한 변경 사항들도 포함되어 있다. 초기 단계 동안 이러한 비즈니스 프로세스 변경들을 계획, 디자인, 테스트 해야 하고 이제는 새로운 비즈니스 모델을 지원해야 한다. 유스 케이스에 따라 적절한 훈련과 문서화를 수행하고 이 작업을 활용할 수 있어야 한다.

ACME Super ATM의 전이 단계

ACME Super ATM 예제에서 우리가 해야 할 일은 소프트웨어를 ATM에 설치하고, 머신을 알맞은 장소에 배치하고, 이들을 설정하여 ATM 네트워크 상에서 실행되도록 해야 한다. 시스템의 실제 롤아웃은 수년 동안 지속될 것이고 모든 프로그램들을 나타내야 한다. 따라서 전개할 때 앞으로의 전개 작업을 무리 없이 수행할 수 있는지를 확인해야 한다.

전이 단계 끝내기

이제 모든 단계를 끝마치면서 전이 단계에서 결과를 평가해야 한다. 이 프로젝트의 끝 단계에 와 있기 때문에 전체 프로젝트를 평가해야 한다. 프로젝트가 그 목표에 미치지 못했더라도 무엇이 잘 되었고 앞으로의 프로젝트에서 어떤 일을 해야 하는지를 이해해야 한다. 프로젝트가 성공할 경우 이 시점에서 프로젝트를 끝낸다.

위로

요약

프로젝트의 각 단계에 대해 살펴보았다. 각 단계 마다 다루어져야 하는 리스크들을 설명했고 이러한 리스크를 처리하는 전략에 대해서도 이야기 했다. 프로젝트 전반에 걸쳐 유스 케이스가 프로젝트를 어떻게 연결시키는 지를 보았다.

또한 프로젝트를 계획하고 관리하는 다양한 평가 방식에 대해서도 살펴보았다. 모든 단계에서 평가를 내려야 하고 리소스와 리스크를 관리해야 한다. 각 단계는 다른 리스크를 지니고 있기 때문에 작업은 약간 다르다. 반복과 단계 후반의 마일스톤으로 프로그레스를 평가하고 프로젝트를 진행하는 방법에 대해서도 설명했다.

솔루션을 개발할 때 반복 방식을 사용한다면 솔루션 개발에 있어 매우 유용하다. 예견이 가능하며 응답성도 충분하기 때문이다. 이러한 툴을 사용한다면 스테이크홀더가 기대하는 솔루션을 정해진 시간에 효과적으로 전달 할 수 있을 것이다.

위로

Footnotes

¹ 기술적으로 단순한 시스템의 일부를 구현하는데 사용되는 기술. 함수 호출에 대한 기본적인 응답을 하드 코딩 한다. 예를 들어 isValid(someObject) 함수는 실제로 밸리데이션을 수행하는 대신 ‘true’ 값을 리턴한다. 함수의 구현이 시스템의 아키텍처에 영향을 미치지 않을 때 이 기술을 사용한다. 이 기능의 구현을 연기하여 시스템 아키텍처의 보다 중요한 부분들에 집중할 수 있다.

² Adapted from Walker Royce, Software Project Management: A Unified Framework, p. 276.

³ "Constructive Cost Model", (http://sunset.usc.edu/research/COCOMOII/)참조

⁴ eXtreme 프로그래밍 같은 접근 방식들의 원칙 중 하나이다. “사용자 대표”는 비즈니스 문제와 목적과 관련하여 커뮤니케이션의 책임을 지고 개발 팀은 순전히 개발 문제에만 집중하도록 하는 것이다. 실제로, 개발 팀이 비즈니스 문제를 이해하여 창조적인 솔루션을 찾도록 하는 것이 중요하다. 이 방식은 가격-기술 팀이 보다 적극적으로 비즈니스에 참여하도록 하고 있다.

⁵ 한 명의 고객은 문제와 잠재적 솔루션을 이해하기도 전에 프로젝트의 스케줄과 비용을 고정시켜서 심각한 문제를 만드는 경향이 있다. 프로젝트 매니저가 정해진 비용과 스케줄을 맞추지 못하면 위험을 떠안게 된다. 거의 모든 프로젝트가 제 시간, 정해진 예산 내에 이루어져야 한다. 하지만 프로젝트는 매우 작은 아이디어로 만들어졌기 때문에 전개된 솔루션은 중요한 비즈니스 결과를 만들어 내지 못한다. 이 경우 프로젝트 펀딩과 퍼포먼스 평가 모델이 형편없는 솔루션 결과에 중요한 요소로 작동한다.

⁶ 어떤 것도 되돌릴 수 없지만 여기서 말하는 것은 조금 다르다. 프로젝트의 가능성을 위협한다면 변경이든 유지든 결정을 내려야 한다. 다시 말해서 이러한 결정이 옳은지를 확인해야 한다.

⁷ 문제를 해결하기 위해 우리가 기꺼이 지불하는 최대 비용은 프로젝트의 회수 비율을 고려한 것이고, 문제 해결 비용을 뺀 순 이득이다.

⁸ 한 가지 기능은 어떤 일관성 있는 정의를 갖고 있지 않다. 사람들의 이해관계에 달려있다. 기능에 대한 명확한 정의가 부족하기 때문에 기능들이 범위 관리에 유용하지 않게 된다.

⁹ 프로젝트 후반에 사람들을 투입하면 프로젝트는 더 지연된다. 아키텍처가 안정되지 않고 작업이 독립적인 단위로 효과적으로 나뉠 수 없을 경우에는 더욱 그렇다. 이 경우 서로 충돌을 방지하기 위해 지속적으로 통신해야 하기 때문에 작업이 느려지고 더 많은 사람들이 하나의 프로젝트에 작업하더라도 실제 작업은 줄어들게 된다.

기사의 원문보기

• Driving Iterative Development With Use Casesb

필자소개

		Kurt Bittner는 10년 전에 Rational Software에 입사했고 소프트웨어 업계에는 20년 이상을 몸담았다. 소프트웨어 엔지니어링 관리와 프로세스 변화를 통해 소프트웨어 개발 기업의 효과를 증대시키는 것의 그의 주된 목표이다. 원조 IBM Rational Unified Process(RUP) 개발 팀의 멤버이기도 했고, 후에는 IBM 내 RUP 개발 조직과 기타 제품 개발 조직을 관리했다. Use Case Modeling (Addison-Wesley, 2002)을 공저했고 여러 다양한 책들과 기술자료들을 집필하고 있다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로