프로젝트 성공의 지름길 ‘요구사항 정의’
소프트웨어 개발 프로세스 속도를 증가… 광범위한 절감 효과 부수익
소프트웨어 개발 프로젝트 진행단계 중에서도 요구분석 단계에서 작업지연이나 소프트웨어 리비전 변경 및 재 작업이 중첩되어 발생하는 경우에 가장 많은 어려움을 겪게 된다. 요구사항 정립을 위하여 기존에 존재하던 프로세스들은 임시방편적이며 비능률적이기에, 의사소통의 오류나 불충분하게 정의된 요구사항을 유발시킨다. 요구사항의 도출, 분석, 명세화 및 검증을 포함하는 프로젝트 초기 단계에서의 효율적인 요구사항 정의(Requirement Definition: RD)는 프로젝트 진행 중의 재 작업을 감소시켜주고 개발 작업의 속도를 증가시켜주며, 괄목할만한 비용 및 시간 절약 효과를 가져오도록 도와준다.
성공적인 기업은 비즈니스 상태의 변경이나 고객의 요구에 민첩하고 빠르게 대응해간다. 이러한 기업은 효율성과 자원 이용의 최대화를 목표로 하여 안전한 데이터센터 관리에서부터 CRM에 이르기까지 모든 사항에 베스트 프랙티스를 적용해오고 있다.
이들은 또한 애플리케이션 개발을 위하여 대량의 비용을 투자해 오고 있는데 이는 비즈니스 분석가와 밀접하게 작업하는 프로그래머에 의한 소프트웨어 커스터마이징이 기업의 요구와 소프트웨어 기능을 매치 시킬 수 있는 최적의 길임을 인식하고 있기 때문이다. 그러나 베스트 프랙티스 및 효율성에 관하여, 개발 프로젝트는 종종 성공에 이르지 못하게 된다. 스탠디쉬 그룹(Standish Group)의 조사결과에 따르면, 많은 프로젝트들은 시간 지연, 구현된 기능 집합의 축소, 예산 초과 및 프로젝트 취소 등의 다양한 요소들로 구성된 원인으로 인하여 고통을 겪고 있다.
실제로 프로젝트의 계획 그리고 착수는 복잡한 작업일 수 있다. 비즈니스 분석가, 코더, 품질 엔지니어, 법적 및 관리적 구성원, 최종 사용자 그리고 IT 관리자를 포함하는 모든 프로젝트 이해관계자들은 프로젝트 초기의 요구사항 집합에서부터 서로 상호 협동해야 하며, 애플리케이션이 발전되어감에 따라 이들 모두는 이러한 요구사항을 평가하고 참여해야 한다. 프로세스 진행의 다양한 관점에서 볼 때 이들 관련자들 모두가 워크플로우의 변경을 가져올 수 있으며, 이런 불확실성은 불가피하게 우리가 위에서 언급한 문제들을 유발시킨다.
요구사항 변경과 비용 손실
많은 요소들이 개발 프로세스에 영향을 줄 수 있으면 이러한 요소들에는 예상치 못한 예산 감소, 상위 관리자로부터의 압박, 작업자의 교체 그리고 코드내의 결함 등이 포함된다. 그러나 이러한 요소들 중에서도 요구사항 변경은 분열을 일으키거나 문제를 발생시키고 비용 소모를 일으키는 가장 중요한 요소로 작용한다.
프로젝트가 문제없이 이미 진행되고 있는 상태에서 주요 관리자가 초기 요구사항 명세서가 부정확하다고 지적하는 경우를 상상해 보자. 기업이 업그레이드되고 좀더 다양한 구조를 갖는 데이터베이스와의 연계를 위하여 그들의 영업 지원 애플리케이션을 업그레이드하기로 결정하고, 개발 팀이 이미 업그레이드 작업을 시작한 상태라고 가정해 보자. 작업이 이미 시작되어 진행되는 중에 CIO가 백엔드 단과의 적절한 인터페이스 이외에도 새로이 업그레이드 되는 애플리케이션은 고객 데이터의 보안 전송 그리고 데이터마이닝 및 CRM(Customer Relationship Management) 제품과도 매끄럽게 연동될 것을 반드시 보장해야 한다고 지적한다. 이 시점에서 기존에 이미 완료된 작업들은 새로운 요구사항을 반영하기 위하여 반드시 변경되고 재 작업돼야 한다. 프로세스 후반에 발생하는 변경은 상대적으로 과중한 혼란을 유발시키며 또한 이를 적용하기 위하여 좀더 많은 시간과 비용을 필요로 한다
프로세스 후반에 발생하는 변경과 비교했을 때 요구정의 단계에서 문제를 확인하고 보완하는 것은 최종 소프트웨어 제품에 주목할만하게 커다란 향상을 가져다준다.
HP에 의해 실시된 ‘Applications of Software Measurement Conference’연구에 따르면, 이론적으로 요구사항 분석 단계에서 발견된 문제를 해결하는데 필요한 비용이 1달러인 경우에, 설계 단계에서는 2∼3달러로 증가하게 되고, 코딩 단계에서는 5∼6달러로, 테스트 단계에서는 18∼20달러로 증가하게 되며, 일단 애플리케이션이 릴리즈된 이후에 변경이 발생하면 비용이 100∼110달러로 증가된다고 한다.
여러 가지 연구결과에서 다음과 같은 사실을 증거하고 있다. 일반적으로 소프트웨어 프로젝트에서 전체 노력 중 40% 또는 그 이상을 재작업에 소모하게 된다. 이 말은 즉 프로젝트 초기 단계에서 정확하게 정의된 요구사항은 전반적인 개발 시간 및 자원 절약에 많은 영향을 주게 된다는 것이다.
요구정의 프로세스에 집중함으로써 명확하고 협력적으로 요구사항을 정의 할 수 있다. 프로젝트 초기 단계에서 요구사항이 명확하고 협력적으로 정의된다면 개발 프로젝트와 연관된 다수의 시간 지연, 재 작업 및 낭비 등의 위험 요소들이 회피 될 수 있다. 많은 기업 내에서 애플리케이션의 비전을 정의하고 의사 소통 업무를 담당하는 비즈니스 분석가들이 텍스트 기반의 문서, 스프레드시트, 프레젠테이션 슬라이드 또는 이메일 메시지 등을 이용하여 그들의 입·출력 자료를 정의하고 의사소통하고 있다.
<그림 1>능력의 확장을 통한 향상
초반의 정확한 분석
불행히도 대부분의 기업에서 요구정의 프로세스의 중요성을 간과하고 있으며 이러한 비즈니스 분석가들이 요구사항 관련 프로세스를 주도하도록 한다. 이러한 프로젝트에는 프로세스를 진단하기 위한 중앙 모니터링 장치나 중앙 집중화된 파일 저장소를 보유하고 있지 않다. 특히 프로젝트의 모든 작업자들이 다양한 요구사항 관련 문서를 읽어보고, 문서 내부에 직접 의견을 첨부하거나 수정을 가하도록 기대되며, 그러기에 요구사항은 많은 혼란에서부터 생성되게 된다. 좀더 복잡한 문제에 대하여 언급하자면, 대부분의 요구사항 관리 소프트웨어 툴들은 요구사항 정의 기능을 포함하지 않고 있다. 이러한 툴들은 일단 프로젝트가 시작된 이후의 변경만을 추적하며 프로젝트 진행 단계(설계, 테스트, 품질 보증 및 운영) 를 통하여 코드 상황만을 확인한다.
<그림 2>요구정의 프로세스 흐름
사용자들이 필요로 하는 요구사항은, 완벽하고 사용이 간편한 요구사항 정의 프로세스와 기술로써, 기업이 기존에 보유하고 있는 애플리케이션 라이프사이클 관리(Application Lifecycle Management: ALM) 자원과 유연하게 연동되어야 한다. 신뢰성 있고 일관성 있는 요구정의 프로세스를 구현함으로써, 작업그룹들은 모든 작업 활동에서 서로 상호 협동하여, 프로젝트 요구사항이 올바른 그룹에 의하여 정의되고 확립되며, 관련된 모든 이해관계자들에 의하여 승인되는 것을 보장한다.
도출 : 가장 첫 번째 단계로, 요구정의에 관련된 모든 개별 관련자들은 그들의 요구에 관련된 가시적인 윤곽을 그려나간다. 관련 그룹은 어떤 비즈니스 업무 흐름을 위하여 애플리케이션이 이용 될 것인지, 사용자는 누가 될 것인지 그리고 그들이 소프트웨어를 어떻게 활용할 것인지 등을 결정한다.
분석 : 일단 비즈니스 업무 흐름이 취합되면, 개발팀과 IT 팀은 현실성에 대한 체크를 실행하여야 한다; 그들이 자유롭게 사용할 수 있는 자원을 기반으로 하여 어떤 사항들이 필요로 되는지, 무엇이 개발되어 제공되는지를 확실히 하여야 한다. 이러한 활동은 수립된 계획에 대한 실현 가능성을 검증하며 또한 초기 단계의 모순들로 인한 심각한 문제를 빠르게 발견하도록 도와준다.
효과적인 요구정의는 소프트웨어 설계 그리고 요구 관리가 매끄럽게 이루어지도록 도와준다.
1)분석 : 분석은 요구사항에 대한 우선순위 단계를 포함한다, 이 단계는 중요도에 대한 순서를 정하기 위하여 애플리케이션의 다양한 기능이나 특징에 순위를 부여함으로써 시간을 절약하고 또한 프로젝트 사이클 후반에 유연하게 적용하도록 한다. 이러한 방식은 높은 우선순위를 갖는 작업은 빨리 빌드 되고, 중간 또는 낮은 우선순위를 갖는 기능은 시간이나 비용의 가용성을 고려해가며 추가해 가는 것이다. 만약에 어떤 변경 사항이 발생한다거나 그리고 모든 요구사항이 즉각적으로 만족될 수는 없을지라도, 개발된 애플리케이션 시스템의 핵심 기능이 구현되어 제공되며 대부분 최종 사용자의 요구사항을 만족 시켜 줄 것이다.
2)명세화 : 요구사항이 형태를 잡아감에 따라, 모든 이해관계자들이 유즈케이스, 비즈니스 규칙, 비즈니스 모델 그리고 프로토타입 등을 통하여 요구사항에 상세함을 더하는 단계이다. 이 단계는 또한 요구사항의 문서화, 뒤따라야 되는 관리 프로토콜을 포함하며 기존에 존재하던 애플리케이션 및 프로세스와 해당 프로젝트의 연계 방안을 결정하여야 한다.
3)검증 : 일단 모든 요구사항이 명세화 된 이후에, 관련된 이해관계자들은 그들의 초기 비전이 실제 흐름상에 반영되어 있는지 그리고 추가된 상세함이 정확하고 완전한지 검증하여야 한다. 검증 단계에서, 비즈니스 분석가들은 완성된 시나리오를 상호 검토하는 작업을 통하여, 그들이 원하는 결과를 제공할 수 있도록 보장하는지 그리고 최종사용자들은 정의된 흐름이 그들의 필요사항과 작업환경을 효율적으로 연동시켜주는 가장 효과적인 방식이 될 것인지를 검증한다. 테스트 케이스 및 릴리즈에 대한 기준은 이러한 요구사항을 기반으로 하여 확립된다.
요구정의를 위한 앞의 세 단계 프로세스에 뒤따라서, 기업의 작업 그룹들은 간편하고 효과적으로 비즈니스 단의 구성원들과 IT 구성원들 간의 빈 공백을 없애기 위하여 다양한 공동작업을 진행하며 그들의 비전에 대한 틀을 구체와 하기 위한 공동 플랫폼을 생성한다.
도출과 분석을 위하여, 이해관계자들은 비주얼한 비즈니스 스타일의 모델링 툴을 공유하여야 한다, 이러한 툴을 이용하여 시나리오, 단계, 의사결정 그리고 가변 변수를 생성 할 수 있다. 요구정의 프로세스에 포함된 각 개별 그룹들은 그들이 이해하기 가장 적합한 형태로(텍스트, 플로우차트 또는 코드 등) 구성된 요구사항을 접근하고 조회 할 수 있어야 하며 이를 통하여 검토 및 승인 작업을 용이하게 진행 할 수 있다.
애플리케이션 라이프사이클 관리(ALM)에 대한 의존성을 인식하는 효율적인 요구정의 솔루션은 요구사항에 대한 세밀한 조율 및 문서화를 가능하도록 하는 유즈케이스를 생성하며, 이러한 솔루션은 문서나 파일 형태의 다른 자원을 첨부 할 수 있도록 지원한다. 앞에서 이미 언급하였듯이, 요구사항 우선순위 작업은 프로젝트 개발 전반의 라이프사이클에 걸쳐서 주목할만한 시간이나 문제 거리를 감소시켜주며, 훌륭한 요구정의 프랙티스는 가장 필요로 하는 기능에 대한 요구가 개발자들의 우선순위 리스트의 최 상단에 위치하도록 보장한다.
<그림 3>실행을 스토리보드(Story Board) 형태로 표현
비주얼한 표현은 모든 이해관계자들이 소프트웨어 요구사항에 대한 공동작업을 도와준다
추가적으로 요구정의 툴에 의하여 생성된 테스트 케이스는 사용자 및 분석가에 의하여 생성된 비즈니스 프로세스 흐름을 반영하여야 하며, 이를 통하여 테스트 및 QA 팀원들은 근본 요구사항과 직접적으로 관련되지 않은 사용자 시나리오나 모델을 이용하여 애플리케이션을 실행 함으로써 발생 할 수 있는 상황을 예측하거나 또는 작업의 중복 현상을 제거할 수 있다.
이익의 연속적 상호작용
개발 팀이 작업을 시작하기 전에 모든 요구사항이 정확하게 정의되고 관련된 모든 이해관계자들에 의하여 승인된다면, 프로젝트 전체 라이프사이클에 걸친 능률이 자연히 증가하게 된다.
·설계 및 코딩 작업은 사전에 비즈니스 분석가, 사용자 그리고 IT 구성원들에 의하여 상호 동의된 모델을 따르게 되며, 이는 잘못된 이해 그리고 잘못된 의사소통을 상당한 수준으로 감소 시켜준다.
·프로젝트 후반의 추가사항이나 조정 작업이 감소하기 때문에, 재 작업도 감소하게 된다.
·요구사항의 우선순위에 따라 애플리케이션 기능들이 개발되기 때문에, 불필요하거나 쓸데없는 요소들의 개발은 프로젝트 진행 전반에서 수면으로 가라앉게 된다.
·테스트 및 QA 작업은 정확한 요구사항에 따라서 실행되기에, 품질 팀이 잘못된 테스트 케이스에 집중하여 자원을 낭비하는 경우가 없다.
·테스트 및 QA 작업은 좀더 빠르고 능률적으로 실행된다. 프로젝트 라이프사이클 초반에 그리고 개발 작업이 진행 중에 요구사항에 대한 코드 개발이 완료된 후에 테스트를 진행하는 기존의 전통적인 테스트 방식에 대비하여 많은 시간과 비용을 절약해준다.
·개발이 완료된 제품은 최종 사용자의 기대와 요구에 부응하기에 최종 사용자의 만족은 증가하게 된다.
요구정의 그리고 요구관리 툴이 이론적으로만 능률을 증가시켜주는 것이 아니다. 많은 주요 개발 조직들이 요구정의 솔루션을 구현하였으며 괄목할 만한 결과를 보고 있다.
예를 들어 세계적인 컨설팅 기업인 캡제미니(CapGemini)는 매년 200개 가량의 고객 프로젝트를 위하여 오라클 애플리케이션을 빌드 하고 있다. 요구정의 솔루션을 구축하기 이전에 캡제미니는 애플리케이션 설계 작업을 위하여 전체 프로젝트 시간의 20% 가량을 소비했다. 이해관계자를 위한 프로세스 흐름을 처음 배포하는 시점부터, 최종 워크숍을 진행하기까지, 프로세스 흐름의 파악 및 수정 그리고 테스트 스크립트의 생성 및 검증 작업을 실행했다.
이와 더불어 이러한 프로세스 절차는 파워포인트 슬라이드로 표현되었으며 필요한 경우에는 워드 문서가 함께 첨부되어 필요한 절차의 윤곽 및 요구사항의 단계를 표현하였다. 워드 문서 내의 텍스트는 파워포인트 내의 그래픽에 적절하게 의미 있는 링크를 생성하지 못하였다. 요구사항 문서 크기나 기타 관리하기 어려운 여러 가지 특징들은 실시간 토의나 협동 작업을 불가능하도록 만들었다.
요구정의 툴을 적용한 후 설계 단계와 연동함으로써, 캡제미니는 요구사항을 파악, 정의 그리고 검증하기 위하여 필요로 되는 시간의 40∼66%까지 감소시켰다고 보고한다. 사용자들이 그들이 이용할 프로세스를 설명하며 제품을 기다리는 동안에 설계 팀은 실제 상황의 비즈니스 프로세스 흐름을 문서화하기 위하여 툴을 사용한다
볼랜드의 비전은 소프트웨어 프로젝트에서 애플리케이션 라이프사이클을 비즈니스 프로세스 구조처럼 처리하는 것으로, 생산성의 최대화 및 자원이나 비용 낭비의 최소화를 위하여 애플리케이션 라이프사이클을 다른 비즈니스 목표나 프랙티스들과 일직선상에 놓고 처리하는 것이다. 볼랜드는 오픈 애플리케이션 라이프사이클 관리(오픈 ALM)라는 이니셔티브를 통하여 다양한 툴들이 서로 유연하게 상호작용 할 수 있는 프레임워크를 제공하여 주며, 이를 통하여 다양한 워크플로우 스타일 및 기존에 기업이 보유하고 있는 다양한 프로세스를 지원한다. 그리고 기업이 기존에 사용하는 관리 솔루션(상업용이나 오픈 소스 툴에 관계없이)과도 이음새 없이 연동한다.
오픈 ALM은 고객들이 라이프사이클 툴들과 연동하고 관리 레이어를 추가함으로써 기존에 이용하던 프로세스의 효율성을 증대시키고 향상시키도록 도와준다. 이러한 특징은 모든 컴포넌트로부터 정보를 취합하고 보고서 작업과 자산 추적 관리를 위한 통합 플랫폼을 제공해 준다.
