2016년 2월 23일 화요일

SW 고품질을 위한 Model 기반의 SW Visualization (하)



프로젝트 수행 기법

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

기법은 다양한 형태로 정리된다. 프로젝트 산출물을 정리하여 재사용이 가능한 자산으로 활용하기도 하고, 소프트웨어 개발 로직을 체계화하여 프레임워크로 발전시키기도 한다. 액티비티(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)를 작성한다. 

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

사용자스토리 워크샵

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

<참조사이트 소개>


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

품질향상을 위한 TCOE(Test Center Of Excellence) 구현방법

성공적인 비즈니스 운영을 위해, 기업은 효율적이고 안정적이면서 복잡한 비즈니스 프로세스를 지원할 수 있는 소프트웨어 시스템을 필요로 한다. 그러한 인프라를 바탕으로 기업들은 신속하게 새로운 기술/기능을 지원하는 애플리케이션을 제공해 시장에서 경쟁 우위를 얻고, 고객들로부터 좋은 평가를 받고자 하는 것이다.

하지만 이를 위해서는 기존의 품질관리 체계의 변화가 필요하다. 기존의 프로젝트 수준의 품질 보증(QA)은 더 이상 이러한 변화와 속도를 유지하는 데 필요한 추진력과 효율성을 제공하는 데 한계가 있기 때문이다. 이를 해결하기 위한 테스트 프로세스의 개선과 인력 확보 등을 위해 노력하고 있는 STA테스팅컨설팅의 조호행 수석을 통해, 테스트 역량을 높일 수 있는 방법에 대한 살펴본다.

<STA테스팅컨설팅 조호행 수석컨설턴트>

Q: 최근 소프트웨어 시장에서 나타나는 QA 문제점은 뭘까요? 개선 필요 사항이 있다면 어떤 것이 있나요?

오늘날의 많은 기업들은 그 어느 때보다 빠른 속도로 혁신적인 기술과 새로운 시스템을 도입하고 있습니다. 그리고 이러한 노력 이면에는 IT 팀으로 하여금 더 높은 시스템의 효율성을 강조하게 되는데요. 이러한 압박은 기술 변화가 도입될 때 비즈니스의 중단을 최소화하기 위해, QA팀에게 ‘엔드-투-엔드’ 관점의 비즈니스 프로세스 유효성을 검증할 것을 요구합니다.

이에 따라, 품질의 이슈와 운영상의 문제를 피하기 위해서 체계화된 테스트가 필요해진 것이죠. 이전에는 이와 같은 품질관리가 프로젝트 단위로 이뤄졌다면, 최근에는 좀 더 체계화된 형태의 ‘그 무엇’을 요구하게 된 것입니다.

많은 기업이 운영하는 시스템(서비스)에 대한 품질불만을 해결하느라 고심하고 있습니다. 기술변화는 급격하게 이뤄지는데, 테스트 역량은 부족하고 체계적이지 않으며, 품질에 대한 불만은 지속적으로 발생되고 있는 것이죠. 반면, 테스트를 위해 투입되는 돈은 적지 않은 상황입니다.

이를 해결하기 위해 테스트 프로세스를 개선하고, 테스터들의 역량 향상과 전문적인 역량을 갖춘 인력의 확보가 필요할 수 있으며, 때로는 테스트 업무(공정)의 분리와 전담운영을 통해 (도메인 별) 테스트 역량을 확보해야 할 수 있습니다. 그리고 정량적 결함 관리로 유사 결함 예방 체계를 운영하는 노력도 필요할텐데요. 그러한 고민의 결과로 ‘TCOE(Test Center Of Excellence)’가 만들어졌다고 볼 수 있습니다.