Practical Application Life cycle Management (ALM) Table of contents 2009-02-18 조대협 (http://bcho.tistory.com) Overview... 2 문제점... 4 실용주의 ALM... 4 End to end use case ( 시나리오 )... 4 개발자시나리오... 5 PM의작업지시시나리오... 6 PM의현황관리시나리오... 6 실용주의 ALM 구성... 6 Task Management (Task 기반의프로젝트관리 )... 6 Build Environment ( 빌드환경 )... 7 Test Automation ( 테스트자동화 )... 8 Collaboration ( 협업 )... 9 실용주의 ALM 의구현... 10 성공적인 ALM 구현전략... 10
Overview ALM의정의를 wikipedia에서찾아보면다음과같다. Application lifecycle management (ALM) is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.[1] 해석해보자면, 기존의애플리케이션개발은기술적인관점에서많이접근이되어왔으나, 비즈니스요건관리부분과실제소프트웨어개발프로세스를융합하고이에대한관리를자동화된툴을이용하도록하는것이 ALM의개념이며, 이부분에는요구사항관리, 아키텍쳐, 코딩, 테스팅, 그리고이슈추적과릴리즈관리등을포함한다. 한마디로이야기하면비즈니스와실제소프트웨어개발간의괴리를없애고, 소프트웨어개 발의요구사항분석에서부터릴리즈까지의모든과정을툴을도입함으로써관리하겠다는개 념이다. 기존에소프트웨어개발프로세스는요구사항관리에대한문서나시스템, 아키텍쳐나디자인에대한 Case tool과산출물, 코드관리, 일정관리등등이각기다른제품과다른프로세스다른템플릿으로구현이되어왔고이로인해서소프트웨어개발과정에대한개념이실제로구현되었을때는단계별로추적성과실용성이떨어졌다. ALM의의미는이런현실과괴리된부분을좀더통합되고현실적으로전문화된도구를이용하여현실화시키고궁극적으로소프트웨어개발프로세스를개선하는데목적을두고있다고말할수있다. ALM 이실제커버하는범위를보면아래그림과같이요구사항관리에서부터프로젝트관 리, 릴리즈관리까지소프트웨어개발의거의전영역을커버하는것을볼수있다.
( 위키피디아 ALM Concepnt 그림인용 : http://en.wikipedia.org/wiki/application_lifecycle_management) 요즘들어서많은업체들이이 ALM 이라는개념을사용하고있다. H* 의경우버그추적시 스템을기반으로이슈관리, 테스트자동화도구를가지고 ALM 이라고이야기하고있으며 Mc* 라는업체의경우테스팅툴하나만을가지고 ALM 업체라고이야기하고있다. ALM이가져야할최소한의요건은요구사항관리, 프로젝트스케쥴관리를위한 Task 관리, 빌드환경자동화및형상관리, 테스트자동화부분이핵심이라고본다. 그외에 Deployment의경우주로운영 (SM : System Management) 조직이담당하며, Design 이나아키텍쳐링의경우 ALM 사상내에포함되는것이이론적으로는맞지만, 사실 Design의경우프로세스를정형화시키기어려울뿐더러, 실제프로젝트에서는 Design이프로젝트가진행되어감에따라변화하고완성되어가기때문에, Design을포함시키는것은쉽지않다고생각한다. 사람들은프로젝트를하면서똑똑해지고시스템은프로젝트진행됨에따라명확해진다. Agile 사상에서도 Design은선행작업이아니라, 주로프로젝트진행과같이가는 On going 작업으로정의하고있다. Design을 ALM의구현체내에포함시키기위해서는말단개발자까지상당수준의성숙도가필요하다.
문제점 ALM의사상적인출발은툴을이용한소프트웨어개발사이클의현실화인데, 시장에있는툴의경우그성숙도가매우높아서프로젝트에적용하는데상당한경험과지식을필요로한다. 실용적인면에서생각했을때 ALM의적용범위는일반말단개발자수준에까지적용이되어야하기때문에난이도가높을때는실제프로젝트에적용하기가어려운점이많다. 또한 ALM Company를자칭하는많은회사들이 ALM에대한 Full set을가지고있지않은상태에서마케팅적인메시지로 Drive 하는경우가많아서사용자의혼란을초래하고있다. 그리고무엇보다중요한것은 ALM 을시스템으로구축하기위한제품이아니라 ALM 을조 직에적용하기위한프로세스와방법론즉, 컨설팅과같은인적지원면인데, 적어도국내의 벤더들에서는실용적으로 ALM 을프로젝트에적용할수있는업체가있는지는의문이다. 실용주의 ALM 실용주의 ALM은이런문제점을바탕으로좀더실용적이고실무적인 ALM을개발하여실무에사용하고자하는데목적을두고있으며아래와같은특징을갖는다. 주로오픈소스나저비용의제품을조합하여 ALM의핵심범위를커버한다. Agile과 Kent Beck, Erich Gamma, Joel Spolsky 등에의해서주장되고있는실용주의방법론 (Practical methodology) 를바탕으로하여, 튼튼한이론적인바탕을가지고현실에맞는실용적인프로세스를구축한다. 구현팀을위주로프로세스를정의한다. 품질향상 End to end use case ( 시나리오 ) 이해를돕고자이제부터소개하고자하는실용주의 ALM 프레임웍의가상시나리오를살펴 보도록하자
개발자시나리오 1) 개발자 D씨는아침에출근해서이클립스 IDE를오픈한다. 2) 이클립스 IDE는이슈추적툴로부터 D씨에게할당된작업들이리스트업되고, 그중에서오늘해야할작업을선택하여 PROGRESS로상태를변경한다. 3) SCM으로부터최신코드를 UPDATE받고코딩을시작한다. 4) 코드를만들고테스트케이스를작성하여코드가제대로작동함을확인하고, 커버러지분석을통해서금일코딩한내용이테스트에서모두확인되었는지체크한다. 5) 오늘코딩한내용을 INSPECTION툴을통해서잠재적인문제가있는지없는지검증받고 NAMING RULE등이문제없는지확인한다. 6) 완료된내용을 SCM에작업번호와함께 COMMIT한다. 7) 자동빌드머신에서 COMMIT된소스코드를감지하고모든소스를내려받아서빌드를완료한후에개발서버에자동으로배포하고테스트를수행한다. 8) 테스트가실패한경우이전버전으로개발서버를원복시키고모든개발원과 PM 에게이메일로테스트실패사실을통보한다. 9) PM은테스트실패사실을이메일로통지받고, 이번빌드에서변경된부분을빌드자동화시스템을통해서확인하고빌드자동화시스템에의해서리포트된내용에따라누가어느모듈을수정했는지를찾아서해당개발자에게수정을지시한다. 10) 개발자는수정을마친후에다시 SCM에소스를반영하고빌드자동화시스템은빌드, 테스트, 커버러지분석, 코드복잡도분석,INSPECTION작업을수행한다. 11) PM은빌드가완료된결과를통보받고, 복잡도가높은클래스모듈 10개에대해서제대로테스트가커버하는지확인하후에미비한부분에대해서담당개발자에게테스트보강을지시한다.
PM 의작업지시시나리오 1) PM P씨는아침에출근하여고객으로부터새로운요건을받았다. 2) P씨는요건을정리하여내용을이슈트랙킹시스템에등록하고심각도와우선순위를지정해서개발 PL에게 ASSIGN하였다. 3) 개발 PL은요건의우선순위와긴급도를보고누구에게작업을지정할것인지고민한다. 이슈트랙킹시스템에서개발원별로진행중인이슈사항을보고개발난이도에맞는사람중에서가장할당된이슈가적은사람에게이슈를 ASSIGN하였다. 4) 개발자는해당 ISSUE를받아서처리한후 PL에게다시 ASSIGN한다. 5) 이때작업에관련된메일, 전화통화내용기타관련내용들을시스템에모두 LOGGING한다. 6) PL은작업이완료된내용을검토한후해당 ISSUE를 CLOSE한다. 7) PM은자신이지시한내용에대해서누가진행하고있으며진행현황이어떻게되었는지를이슈를통해서추적할수있다. PM 의현황관리시나리오 1) PM P씨는 1차오픈때까지해결되어야할이슈를이슈관리시스템에서검색한다. 2) 심각도가높은이슈와오픈된지오래된이슈를확인하여진행이안되고있는이유는무엇인지 RISK는무엇인지를조사하고, RISK에대한대비책을세운다. 3) 만약에날짜에비해서해결되어야할이슈가많을경우심각도와우선순위를고려하여 2차오픈으로이슈를연기한다. 실용주의 ALM 구성 실용주의 ALM 은크게 4 가지모듈로구성된다. Task Management (Task 기반의프로젝트관리 ) 프로젝트에서진행되는작업에대한진행상황과스케쥴링그리고리소스에대한관리방법론을제공한다. 기본적인사상은 Agile 방법론의프로젝트관리방안을기반으로하고있다. Task Management 모듈은다음과같은서브모듈을포함하고있다.
Process 1) Task Management Process : Agile Scrum 기반의 Task 관리프로세스 2) SOA or Open API Service Lifecycle Management Process (Optional) : SOA나 WEB 2.0에서 Service Lifecycle ( 서비스신청에서부터배포까지 ) 관리프로세스와시스템 3) Requirement Analysis Process (TBD) : 요구사항추출프로세스 Reference Architecture 1) Task Management System Reference Architecture : 프로세스를구현한 Task 관리시스템 2) Task Management Dash board Reference Architecture : 프로젝트의진행상태를한눈에알수있는 Dash board 3) Requirement Analysis Management Reference Architecture (TBD) 요구사항관리시스템 Build Environment ( 빌드환경 ) Implementation 단계에서사용되는개발환경을제공한다. 기본적인사상은 Pragmatic( 실용주의 ) 방법론으로 Kent beck이나 Joel Spolsky에의해서소개된방법론을기초로하며, 일일빌드와점진적 / 반복적통합론을중심으로개발환경구성에대한가이드를제공한다. 다음과같은서브모듈을포함하고있다. Process 1) SCM branch guide : 소스형상관리에대한브렌치관리전략소스코드관리에있어서브렌치에대한관리방법을기술한다. 브렌치는잘못쓰면전체소스코드관리를하는데있어서엄청난혼란을초래할수있는만큼적절한브렌치관리정책이정해져야한다. 2) Contiguous Integration Process : 점진적통합방법에대한프로세스자동빌드시스템을구축하여, 개발자의소스코드변화를자동으로인지하고매일자동빌드를통해서코드의통합을빅뱅방식이아니라매일점진적인방식으로진행함으로써통합으로인해발생할수있는문제를조기에발견하고해결할수있도록하며, 빌드과정내에테스팅을포함시켜서결함을조기에발견하여전체소프트웨어품질향상을유도한다. Reference Architecture 1) Standard IDE : 개발자를위한표준개발환경가이드프로젝트에서개발자별로선호하는개발도구들이다르다. ( 이클립스, NetBeans, VI 등 ) 다른개발도구는구현된코드에도영향을주며, 특히새로운팀원이합류했을때보통
1~2일을개발환경을셋업하는데시간을소요하게된다. 표준개발환경은 ZIP으로개발에필요한모든환경을만들어서개발자가 ZIP 파일만풀면, IDE에서테스트프레임웍, 테스트용서버환경까지일괄로셋업이되서모든개발자가빠른시간내에동일한개발환경에서소프트웨어를구현할수있도록한다. 2) Contiguous Integration Reference Architecture 실제 CI 환경을구축하는데필요한아키텍쳐에대해서설명한다. 3) Standard Build Script : 표준빌드스크립트구축가이드표준개발환경과마찬가지로빌드스크립트역시표준화되어야한다. LIB 위치나버전, 빌드스크립트내의 TARGET 정의, 빌드순서등을통합하고표준화된형태로제공하여개발자가빌드스크립트작성에소요되는시간을절약하고, 비표준화된빌드스크립트사용에서오는오류를예방한다. Test Automation ( 테스트자동화 ) 일반적으로테스팅은 QA팀의역할로인식이되어왔고, 시스템개발이완료된후에 QA팀에의해서테스팅이되는것이일반적이었다. 여기서는소프트웨어개발중에개발팀에의해서수행되는단위테스트와통합테스트에도비중을두고, 테스트자동화와회귀테스트 ( 테스트마다지난번테스트했던내용을포함하여테스트하여, 변경사항이기존기능에영향을줬는지여부를검증함 ) 를중점적으로다룬다. 테스팅모델은전통적은 Waterfall 방식을확장한 V-Model을기반으로한다. Process 1) Testing Process ( 테스트프로세스 ) 소프트웨어개발단계에서부터의단계별테스팅프로세스에대해서정의한다. V-Model에기초하여 Unit Test,Integration Test, System Test, User Acceptance Test 4단계로나누어서정의한다. 2) Defect Management Process ( 결함관리프로세스 )
테스트결과발견되는결함에대한관리프로세스를정의한다. Reference Architecture 1) Unit Test Framework Reference Architecture 특히단위테스트의경우소프트웨어의안쪽을테스트하기때문에, 일반적인테스팅도구보다는소프트웨어컴포넌트에따라더정밀한테스팅도구가필요하다. 단위테스트를수행하는데필요한테스팅프레임웍에대해정리한다. 2) Static Testing Reference Architecture 소프트웨어테스팅기법중에서, 소프트웨어의동작상태가아니라코드검증을통해서결함을찾아내는방법을 Static Test라고한다. 이테스트에서는코드의 Naming Convention이나특정패턴에따른잠재적인결함 ( 메모리누수, Null Pointer Exception) 을찾아낼수있다. 이 Static Test를수행할수있는도구에대해서설명한다. 3) System Test Reference Architecture 테스팅중에서주로성능과비기능 ( 확장성, 가용성등 ) 에대한테스팅수행도구에대해서설명한다. Collaboration ( 협업 ) 협업모듈은팀이프로젝트를진행하는데있어서의사소통과공동작업을돕기위한몇가지기법과시스템에대해서소개한다. Process 1) Code Review 코드리뷰는실제로코드를검토하여예측되는결함을찾아내고서로개선방향을찾아내는행위이다. 코드리뷰의방식은여러가지가있으나비형식적인코드리뷰라도투자대비소프트웨어품질에많은효과를줄수있기때문에, 협업의기법중의하나로소개한다. Reference Architecture 1) Wiki Based Document Management Reference Architecture ALM을이용해구축된표준이나프레임웍, 프로세스등많은내용들이 Architect 레벨에서일반개발자들에게전달되어야한다. 이런지식을전달하는방법이문서등여러가지방법이있겠지만, 문서등은여러버전관리나변경관리가어렵고, 표현의한계가있다. Wiki의경우내용을하나의장소에서계속업데이트가가능하고, 검색이가능하며, TEXT와이미지뿐만아니라멀티미디어데이터를넣을수있기때문에직관적인정보전달이가능하다. 또한링크를이용하여정보간의연관관계를정의할수있다. MS-WORD 등으로만들어진문서는공유폴더에서사장되거나또는이쁘게바인딩되어
서책장이라는무덤속으로사라질수있는데, Wiki 를이용하는이유중의하나는꼭필 요한문서만, 필요할때사용할수있도록하여, 프로젝트에서의정보공유를가속화하 는데그목적이있다. 2) Communication with Forum Reference Architecture Wiki의경우대부분위의조직에서아래조직으로의하향성을가진단방향커뮤니케이션이다. 이를보안하기위해서 Forum은좋은양방향커뮤니케이션도구로사용될수있는데, Wiki를통한단방향정보전달의 Feedback으로사용할수있다. 이러한협업도구들은전체협업의생산성을높혀줄수있는일부만을권장하는것이며조직의수준과구조에맞춰서별도의협업프레임웍을구축하기를권장한다 실용주의 ALM 의구현 ALM 을프로젝트에적용하기위해서는아래와같이 3 가지관점에서의접근이필요하다. 프로세스 ALM은전체소프트웨어개발프로세스를커버하기때문에, 각모듈을프로젝트에적용되는프로세스에대한정의가필요하다. Reference Architecture 프로세스를실제로시스템으로구현하기위해서, 어떤형태의시스템아키텍쳐를이용하여프로세스를현실화할수있는지에대한가이드를제공한다. 조직시스템과프로세스를가지고프로젝트에적용할때, 적용하는주체의역할과책임에대해서정의한다. 성공적인 ALM 구현전략 간략하게실용주의 ALM 에대해서살펴보았다. 이실용주의 ALM 을성공적으로적용하기위
해서몇가지전략이필요한데, 다음과같다. 1) Liquid 전체프로세스가모난부분이없이물흐르듯이하나의프로세스로연결되어야한다. 프로세스가넘어가는단계가매끄럽지못하면전체개발프로세스에병목이생기게되고, 프로세스흐름에문제가생긴다. 2) Seamless 앞에서소개한실용주의 ALM의모듈구성을보면알겠지만, 상당히많은부분을많은기술로커버하고있다. 이러한기술들이유기적으로결합되어마치하나의통일된프레임웍과같은형태를취하여사용자입장에서하나의프레임웍을쓰는듯한느낌을줘서, 사용자관점에서올수있는혼돈을미연에방지해야한다. 3) Process Oriented ALM의가장중요한요소는프로세스이다. ALM은소프트웨어개발프로세스를시스템화하는것이기때문에, 프로세스자체가중요하며자칫잘못하면시스템구현에이끌려서프로세스가망가지는경우가있다. 4) Step by Step 실용주의 ALM이다른 ALM에비해서경량이고현실적이라고는하지만, 커버하는영역이상당히넓다. 한번에전체개발프로세스를변경하는것은구성원들에게큰혼란을초래할수있기때문에, 난이도별로단계적으로적용하는것을권장한다. 5) 팀의수준에맞춰서팀의성숙도에맞춰서실용주의 ALM을 Customization해서적용해야한다. 성숙도가낮은팀에실용주의 ALM을적용할경우, 마치기존의중량의방법론을적용할때와마찬가지로형식지키기에만급급해지고실제생산성은오히려더떨어질수도있다. 6) Be Simple 모든기능을커버하려하지말고, 목표가 100일때 80만커버하더라도단순성을우선시해야한다. 복잡도가높아질수록실용주의 ALM 사용으로의진입장벽과 Learning Curve가급격하게올라가고이는또다른형식적인방법론으로전락할수있다.