프로젝트 수행 - 기법 편

카페 > 뉴딜코리아 홈페이지 | 뉴딜코리아
http://cafe.naver.com/rapid7/2187

프로젝트 수행 - 기법 편

프로젝트 성공의 가장 큰 조건은 풍부한 경험을 가진 팀원이 프로젝트를 이끌어 나가는 것이지만 모든 프로젝트에 우수한 경험자를 투입하는 것은 어려운 것이 현실이다. 경험이 많은 회사에서는 다른 프로젝트에서도 공유할 수 있도록 축적한 경험을 체계적 기법으로 정리하여 전파하고 관리한다. 기법의 종류와 깊이가 회사의 역량으로 간주될 정도로 기법의 중요도는 시간이 흐를수록 높아졌고, 기법의 자산화는 프로젝트 종료의 필수 프로세스가 되었다. 

기법은 다양한 형태로 정리된다. 프로젝트 산출물을 정리하여 재사용이 가능한 자산으로 활용하기도 하고, 소프트웨어 개발 로직을 체계화하여 프레임워크로 발전시키기도 한다. 액티비티(Activity)나 태스크(Task)의 수행 방법을 정리해 놓은 개발방법론, 가이드, 툴 등도 있다. 효율적인 프로젝트 수행을 위해서는 이러한 기법 활용이 필수적이다. 

SI(System Integration) 중심에서 애자일과 UI/UX를 강조하는 솔루션 형 소프트웨어로 변화하고 있는 요즘에는 새로운 기법들이 주목을 받고 있다. 고객(사용자)의 요구사항을 개발자 관점으로 정리하던 SI와 달리 고객의 관점으로 정리하는 것과 소프트웨어를 시스템 관점이 아닌 비즈니스 관점으로 설계하는 것이 그것이다. 이번 회에서는 고객의 관점으로 요구사항을 정리하는 기법과 소프트웨어를 비즈니스 관점으로 설계하는 기법에 대해 살펴보고자 한다.

고객 관점의 요구사항 정리 기법 

SI와 솔루션에서 개발 방법은 크게 다른 점은 없다. 기획 단계나 완성 후에 릴리이즈 하는 방법이 다르기 때문에 개발방법론 혹은 프로세스에서 다소 차이가 있다고 볼 수 있다. 하지만, 개발자가 고객의 요구사항을 정리하는 방법은 SI와 많은 차이를 보이고 있다. 이번 절에서는 개발자가 고객 관점으로 요구사항을 정리하는 기법에 대해 살펴보도록 한다. 전통적인 소프트웨어 개발 프로젝트는 SI가 많다. 고객의 요구사항에 맞춰 약속된 일정에 개발해야 하기 때문에 요구사항을 어떻게 정리하고 관리할 것인지가 매우 중요한 포인트였다(그림 1 참조). 

<그림 1> 고객 요구사항의 흐름 

<그림 1>를 살펴보자. RFP(Request for Proposal 혹은 Reference for Proposal)는 제안을 받기 위한 고객 요구사항을 명시한 문서다. 제안서는 RFP를 참고해서 작성하는 것이 정석이고, RFP에 포함된 요구사항을 제안서에 모두 반영해야 한다. 고객의 지식으로 RFP를 작성하기 어려울 경우 더 쉽게 기술된 RFI(Request for Information)를 작성한다. 

개발자는 고객의 요구사항을 구두나 문서로 확인하고 제안서를 작성한다. 고객은 개발자에게 “난 잘 모르니까 알아서 잘 만들어 주세요!”라고 하면, 개발자는 경험과 상상에 의존하여 제안서을 제출한다. 바로 여기서 문제가 발생한다. 고객이 원하는 것이 무엇인지 확인하면서 정리해야 하는데 이 과정이 간과되는 것이다. 

사용자스토리 워크샵

최근에는 소프트웨어를 기획하는 단계부터 고객과 함께 고객의 용어로 정리하는 사용자스토리 워크샵이 확산되는 추세다. 고객과 함께 의사소통하며 기획하기 때문에 요구사항에 대한 명확한 정리가 가능하다. 커뮤니케이션을 중요시하는 애자일 기반 프로젝트에서 처음 알려진 사용자스토리 워크샵은 소프트웨어 기획 단계부터 고객을 참여시켜 고객이 원하는 바를 체계적으로 정리하는데 목적이 있다. 

<참조사이트 소개>

●	공학 트렌드 137호: 프로젝트의 새로운 의사소통 채널, User Story Workshop⑴
●	공학 트렌드 138호: 프로젝트의 새로운 의사소통 채널, User Story Workshop⑵

사용자스토리 워크샵은 고객의 요구사항을 정확히 이해하고 명확히 소프트웨어에 반영하기 위한 도구라고 할 수 있다. 개발자는 소프트웨어를 개발하기 위해 요소기술만 알아서는 품질이 높고 사용자가 편한 소프트웨어를 개발할 수 없다는 것을 명심해야 한다. 사용자스토리 워크샵을 통해 고객의 요구사항을 잘 정리해도 소프트웨어에 잘 반영하지 못하면 소프트웨어의 품질과 고객의 만족도는 떨어질 것이다. SI에서도 많이 활용되던 요구사항추적표는 정리된 요구사항이 언제, 어떻게 반영되었는지 확인할 수 있게 한다. 

요구사항추적표

소프트웨어를 개발하면서 가장 많은 논란을 일으키는 질문이 “고객의 요구사항을 제대로 반영했는가?”일 것이다. 구두나 회의록을 통해 해결되었다고 기대하는 경우가 많지만 소프트웨어를 잘 모르는 고객은 프로젝트 도중에 많은 시행착오를 겪게 된다. 개발자는 이러한 문제를 고객의 변심이라고 해석한다. 

고객 입장에서 보면, 개발자는 기술용어가 가득한 분석서, 설계서 등만 보여주기 때문에 요구사항이 어떻게 반영되었는지 알아보기 어렵다. 요구사항이 분석과 설계 등에 어떻게 반영되는지 고객 입장에서 알아볼 수 있게 해주는 것이 요구사항추적표 이다(그림 2 참조). 

<그림 2> 요구사항추적표 예시 

자료: 라이언즈소프트 

<그림 2>를 살펴보면, 요구사항추적표는 요구사항이 유즈케이스다이어그램에는 어디에 반영되었고, 다시 클래스다이어그램과 시퀀스다이어그램에는 어디에 반영되었다 라는 것을 보여준다. 테스트케이스나 개발 프로그램까지도 맵핑 한다. 요구사항이 합쳐지거나 삭제된 경우에도 사유를 작성하여 해당 시점에 표시한다. 

요구사항추적표가 제대로 관리되면 고객과 개발자의 의사소통이 매우 원활해지고 요구사항의 변화가 있을 경우에도 추적하기가 쉬워진다. 고객과 개발자의 계약 관계를 살펴보기 위한 RFP나 제안서도 요구사항추적표에 맵핑 할 수 있다. 

프로젝트에서는 고객의 요구사항이 불분명한 상태에서 시작하는 경우가 많이 발생한다. 사용자스토리 워크샵은 사용자 중심으로 요구사항을 명확히 정리하고, 소프트웨어에 잘 반영되는지 요구사항추적표를 통해 확인할 수 있다. 최근의 요구사항 정리 기법은 고객이 알아보기 힘든 개발자 중심에서 고객이 직접 참여하는 고객 중심으로 옮겨가고 있다. 소프트웨어는 개발자가 아닌 고객이 사용하는 것이기 때문에 사용자 관점에서 요구사항을 정리해 가면 프로젝트 성공률은 더욱 향상될 것이다. 

소프트웨어를 비즈니스 관점으로 설계하는 기법

소프트웨어는 요구사항에 따라 분석, 설계를 하고 설계서에 맞춰 개발을 한다. 고객이 많이 참여하는 요구분석에는 비즈니스 전문가가 참여하고 설계에는 ICT 경험이 풍부한 기술 전문가가 참여한다. 분석은 비즈니스와 ICT기술을 연결해야 하는 영역이기 때문에 양쪽 분야를 모두 아는 전문가가 필요하다. 전통적인 프로젝트에서는 ICT기술 전문가가 분석도 함께 수행하기 때문에 비즈니스보다는 ICT기술에 치중하는 경우가 많이 나타난다.

소프트웨어를 설계하는데는 전체를 한눈에 볼 수 있는 소프트웨어아키텍처라는 큰 그림이 반드시 필요하지만, 일반적으로 시스템이나 네트워크 관련 아키텍처만 설계하는 경우가 많다. 소프트웨어아키텍처는 소프트웨어의 전체 설계도이기 때문에 고객과 개발자 간의 의사소통에 가장 많이 활용되기 때문에 프로젝트 시작부터 가장 많이 준비되어야 한다. 

소프트웨어아키텍처 설계

소프트웨어아키텍처는 2개 이상의 컴포넌트로 구성된 소프트웨어들을 어떻게 구성하는지를 나타내며, 요구분석을 바탕으로 분석에는 개념 모델(Conceptual Model)과 논리 모델(Logical Model)을 만들고, 설계에는 물리 모델(Physical Model)을 만든다. 소프트웨어아키텍처를 통해 컴포넌트의 수준을 정할 수 있고, 각 컴포넌트 간의 통신과 동기화에 관한 이슈도 해결할 수 있다. 이 외에도 데이터 액세스, 컴포넌트의 배분, 성능, 설계 대안 등을 살펴볼 수 있지만 시스템에 사용되는 소프트웨어의 전체 그림을 볼 수 있는 것이 가장 큰 장점이다. 

소프트웨어아키텍처는 어떻게 설계하냐에 따라 프로젝트의 성패가 좌우될 정도로 매우 중요한 활동이다. 효율적인 소프트웨어아키텍처를 설계하기 위해서는 유사한 시스템을 많이 만들어본 아키텍처 전문가가 필요하지만, 그들의 숫자는 매우 적기 때문에 대신 기법이 많이 활용되고 있다. 소프트웨어아키텍처는 툴킷, 프레임워크, 다양한 설계 패턴들로 구성되어 있으며, 시스템의 뼈대를 이루기 때문에 예외사항이나 임기응변 식의 방법을 배제하는 것이 좋다. 

<참조사이트 소개>

소프트웨어아키텍처 설계 지침

소프트웨어아키텍처는 재사용에 가장 큰 목표가 있다. 소프트웨어아키텍처는 충분한 재사용과 사례 학습이 될 수 있도록 가급적 공개하는 것이 좋으며, 구성 당시에 적용했던 방법을 가이드로 정리하여 함께 공유하면 더 좋다. 소프트웨어아키텍처가 그림으로 고객이 원하는 것을 표현하는 것이라면 고객이 직접 소프트웨어를 볼 수 있도록 표현하는 프로토타이핑이 있다. SI에서 다양한 형태로 프로토타이핑을 했지만, 최근에는 고객의 관점을 UI/UX에 적극 반영한 프로토타이핑이 많이 사용되고 있다. 

프로토타이핑

프로토타이핑은 요구분석을 마친 후 아파트의 모델하우스처럼 고객이 원하는 것을 가상으로 만드는 것으로 프로토타이핑은 고객과 개발자가 서로 이해한 것이 맞는지를 확인하는 작업이다. 전통적인 개발방법론에서는 요구분석 단계를 마친 후 프로토타이핑 액티비티가 존재했었다. 웹 기반 시스템의 경우에는 HTML로 소프트웨어의 윤곽을 만들어 고객과 개발자가 최종 모습을 예측해보는데 목적이 있었다. 

최근의 프로토타이핑은 초기 요구사항을 받아 프로토타이핑을 디자인하고, 고객의 평가와 협의를 통해 프로토타이핑을 반복한다. 고객과 합의된 프로토타이핑을 참조하여 분석, 설계, 개발을 수행한다(그림 3 참조). 

<그림 3> 프로토타이핑 프로세스 

전통적인 프로토타입은 요구분석 후 단 한번으로 완료했지만, 최근에는 짧게 반복해서 프로토타입을 수행하고 있다(표 1 참조). 

<표 1> 프로토타입 수행 방법

전통적인 프로토타입은 개발자가 소프트웨어의 최종 모습을 그려보는 성격이 강했지만, 최근의 프로토타입은 고객의 관점에서 원하는 형태로 소프트웨어가 만들어지는지 확인하는 성격이 강하다. 최근에 주목받는 UI/UX도 고객이 소프트웨어를 어떻게 사용하는지에 집중하고 있다. 프로토타입을 UI/UX 관점으로 정리하는 것이 고객과의 거리를 더 줄여줄 것이다. 

소프트웨어는 최신 기술을 사용해서 개발하는 것도 중요하지만 고객의 요구사항을 명확히 파악하여 큰 그림을 그리는 것이 매우 중요하다. 프로젝트 중간에 기술은 변경될 수 있으나 큰 그림이 바뀌어서는 안 된다는 것을 기억해야 한다. 

이번 회에서는 프로젝트 수행에 필요한 기법 중 고객의 요구사항을 명확히 파악해서 큰 그림을 그릴 수 있는 기법들을 살펴보았다. 이 밖에도 소프트웨어 개발에는 다양한 기법들이 있다. 이러한 기법들의 최신 트렌드는 빠르게 소통하는 것을 목적으로 한다. 하나의 프로세스를 짧게 반복 수행하면서 고객과 개발자 간의 합의를 유도하는 다양한 방법을 기법으로 정리하는 습관을 만들어 보면 ICT 전문가로서 역량 개발에 매우 큰 도움이 될 것이다.

출처 : 소프트웨어공학센터