Key Questions Why can t SI business improve product based solution? What have to do for build commercial SW product first? What is SW Architecture Eva

Size: px

Start display at page:

Download "Key Questions Why can t SI business improve product based solution? What have to do for build commercial SW product first? What is SW Architecture Eva"

상순 사
5 years ago
Views:

1 SW Architecture Evaluation (SA 를통해 SW 비즈니스를지속적으로성장시키는방법 ) 나희동기술사 품질혁신센터장 / CyberLogitec 1

2 Key Questions Why can t SI business improve product based solution? What have to do for build commercial SW product first? What is SW Architecture Evaluation? How adopted SA Evaluation in Korea? When and Where Technical Dept occur? How to avoid technical debt without Rebuild? 2

3 Software Architecture Lack of Visibility Evaluation Not Rating But Classifying Not Auditing Not Validating vs But Communicating But Aligning 3

4 State of practice: Techniques for architecture evaluation Experience 83% Prototyping 70% Scenarios 54% Checklists 40% Simulation 17% Questionnaires 16% Metrics 15% Others 11% Math. models 5% [Source: AliBabar & Gorton 2009, survey with 88 architects] 4

5 ATAM : Architecture Tradeoff Analysis Method 정의 비즈니스목표 (Business Goal) 를감안하여소프트웨어아키텍쳐디자인결정사항을도출하고이를보안, 성능, 가용성, 유지보수성등과같은품질속성에비추어아키텍쳐를분석평가하는방법 특징 소프트웨어아키텍쳐평가를위한체계적방법제시아키텍쳐평가를통한시스템개발초기단계부터위험관리가능 소프트웨어시스템에대한상위수준의요구사항을명확하게정의할수있음. 5

6 ATAM 세부절차 6

7 ATAM 적용시기 7

8 마르미 III- 아키텍처설계방법 아키텍처단계작업계획 유즈케이스분석유즈케이스모형분석 UI흐름정의객체모형작성사용자화면정의보고서설계 아키텍처정의소프트웨어아키텍처정의설계전략정의시스템아키텍처정의개념DB설계 시스템아키텍쳐정의서 ( 초기 ) 아키텍처프로토타이핑 아키텍처프로토타이핑계획 컴포넌트명세작성 아키텍쳐프로토타입개발 비즈니스컴포넌트설계 아키텍처프로토타입점검 개발범위선정미니프로젝트작업계획 아키텍처단계말검토 전환계획 테스트계획 8

9 아키텍쳐스타일 비즈니스목표시스템요구사항 아키텍쳐요구사항 & 디자인패턴설계자의경험 대안아키텍쳐 개발조직 / 고객설계자의경험 품질속성식별 아키텍쳐요구사항품질속성 정의 품질시나리오 S/W 아키텍쳐 위험 / 비위험트레이드오프포인트최종아키텍쳐대안아키텍쳐 도출 유틸리티트리 상세설계 결정 평가 대안아키텍쳐 ( 장단점, 제약사항 ) S/W 아키텍쳐 정의서 ATAM 적용한아키텍처설계방법 9

10 Another SW Business Product based Solution Business Hire First Sales Staff Build Sales Organization Concept/ Seed Development Alpha/ Beta Tests Launch & Ramp-up Create Mkt. Materials Create Positioning Hire PR Agency Early Buzz Create Demand Launch Event Branding Software is not visible 10

11 Another SW Business Product based Solution Business Customer Discovery Customer Validation Customer Creation Company Building Iterate, if needed 11

12 What is Technical Debt? The term Technical Debt was created by Ward Cunningham to describe the engineering trade-off s that software developers and business stakeholders must often make in order to meet schedules and customer expectations. In short, the business has decided that it can afford to delay release 2 in order to accelerate release 1. Is this wise? Businesses make this kind of trade-off all the time; and there s nothing inherently unwise about it. If the early release of 1.0 drives the business that pays for the development of 2.0 then the business has won. So this kind of reasoned technical debt may indeed be appropriate. A Mess is not a Technical Debt. 12

13 $3.1/LOC $1M/System 3.1$/LOC, 550M$/App 13

Technical Debt: Strategies & Tactics for

14 Technical Debt: Strategies & Tactics for Avoiding & Removing it Strategy 1: Evolving a Mature Definition of Done Strategy 2: Preventing Unacceptable Technical Debt Strategy 3: Prioritizing & Quantifying Existing Technical Debt Strategy 4: Tactics for Fixing Technical Debt 14

15 논리아키텍처와현행아키텍처를분석한후아키텍처 Restructuring 을수행한다. 2 Feature 식별및정제 3 논리아키텍처정의 입력산출물1 모듈식별 모듈관계정립 모듈관계정립 업무지식및마케팅정보 현행시스템이슈목록 제안정보 품질시나리오작성 아키텍처재설계 Code Smelling 아키텍처 Restructuring Trade-off 분석 패턴식별 Refactoring Point 식별 아키텍처평가 아키텍처 Upgrade 솔루션 Upgrade 계획작성 8 솔루션 아키텍처정의서 개선된솔루션 4 현행아키텍처정의 패키지식별 현행시스템설계서작성 현행아키텍처정의 15

16 Case 1 Top-Down Approach로 아키텍처 모듈을 식별한다. Context Diagram 작성 - 솔루션과 연계되는 외부 시스템을 함께 그린다. - 외부 시스템과의 연계 메커니즘에 대해 설명한다. 논리 아키텍처 작성 - 솔루션의 모듈과 모듈 간의 관계를 작성한다. - 모듈 간의 관계는 모듈 상호작용 메커니즘을 설명한다. 패턴 및 tactics 추가 - 각 모듈의 설계 및 구현 방식에 대한 패턴 및 tactics를 추가한다. - 모듈 명은 모듈의 하는 역할이 명확히 드러나도록 패턴을 참고하여 작성한다. 25th Sep,

17 Case 2 설계방안의적용절차 사례프로젝트의소프트웨어아키텍쳐를설계하기위하여앞에서제안한설계방법을적용하고각단계별로필요한활동을수행하였음. 1. 아키텍쳐요구사항및품질속성식별 아키텍쳐에대한요구사항을도출하고품질속성을식별고객정보의중요성에따라 보안 (Security) 이가장중요한품질속성으로식별되었으며 비즈니스환경변화에따른신속한개발및품질보장을위하여재사용성과유지보수성이중요한품질속성으로제시됨. 예 ) 아키텍쳐품질속성 ( 발췌 ) 보안 재사용성 고객정보는은행의중요정보자원으로사용자그룹에따라엄격한보안을제공하여야한다. 업무및요구사항변경에따라모듈또는비즈니스로직을변경해야하는경우기존에작성한컴포넌트또는모듈을재사용할수있어야한다. 17

18 Case 2 설계방안의적용절차 ( 계속 ) 2. 대안아키텍쳐정의 WAS 를도입활용함으로써기본적인성능및보안요구사항을수용 재사용성, 확장성, 유지보수성및대체성을만족시키기위하여보다구조화된아키텍쳐에대한필요성이제시됨 => 계층형아키텍쳐 어플리케이션에서의불필요한객체간의호출로인한성능저하문제발생 => 변형된계층형아키텍쳐정의 ( 인접하지않은계층의컴포넌트호출허용 ) 계층별컴포넌트구성및컴포넌트역할 ( 발췌 ) Application UI Business Component 고객곤리시스템의사용자인터페이스를담당하는패키지로서어플리케이션 UI 계층으로분리하여관리. JSP 및 Servlet 으로구현됨 비즈니스컴포넌트로서데이터중심의컴포넌트로구성된계층. 세션빈으로구성되어 WAS 위에서운영됨 18

19 Case 2 설계방안의적용절차 ( 계속 ) 3. 품질시나리오도출 ( 유틸리티트리생성 ) 1 레벨 2 레벨 3 레벨 데이터보안 (H,L) 사내인트라넷접근은반드시통제 보안성 사용자보안 (M,L) 사용자수준에대한보안관리를통합적으로관리함 (H,L) 자유로운새로운사용자등급구성이가능 품질속성 유지보수성통합성 컴포넌트변경문서화시스템연동데이터일원화 (H,L) 제도변경에의한모듈또는업무로직시기존컴포넌트변경추가, 확장, 재사용용이 (H,L) 프로그램문서화가잘되어있어프로그램수정이용이 (M,L) 한번의로그인으로모든시스템을사용 (H,L) 고객중심의통합구성화면제공 (H,M ) 타시스템및업무시스템과의연동 성능 데이터대기시간 (M,L) 평균접속량증가시에도별도의성능저하가있으면안됨 (H,L) 각종실적및통계자료처리로인한업무지연발생있으면안됨 데이터처리량 (H,M ) 홍보관리에서의트랜젝션은 3 초이내처리고객정보관리, 대외협력관리의트랜젝션은 1 초이내처리 정제레벨 낮음 정제레벨 높음 19

20 Case 2 설계방안의적용절차 ( 계속 ) 4. 대안아키텍쳐평가 2 단계에서제시한변형된계층형아키텍쳐에대하여품질속성별로평가를실시하고장단점을분석 대안아키텍쳐에대한품질속성평가 ( 발췌 ) 보안 Business Component 비즈니스컴포넌트를통해사용자인증을획득하고인증되지않은빈은호출되지않는등의사용자접근보안을 WAS 와 Foundation 에서제공하는컴포넌트를통해제공한다. 계층형구조에서는특정계층에서보안을집중관리하게되므로안정적이고유연한보안성능을가질수있다. 모든시스템의호출이단편적이고비즈니스컴포넌트는독립적으로수행될수있도록설계하여재사용성을유지할수있다. 또한모든컴포넌트는잘정의된문서화된인터페이스를가지고있으므로하나의계층이다수의 context 를재사용할수있다. 20

21 Case 2 설계방안의적용절차 ( 계속 ) 5. 최종소프트웨어아키텍쳐정의 아키텍쳐평가결과에따라최종소프트웨어아키텍쳐를결정 컴포넌트모형, 클래스모형등을포함하여소프트웨어아키텍쳐를기술 21

22 Case 2 설계방안의적용절차 ( 계속 ) 6. 소프트웨어아키텍쳐상세설계 정의된소프트웨어아키텍쳐를구현하기위한지속성구현방법및가변성구현방법을설계 Broker 1: call session Bean 2: call 4: 13: GeneralException(String) session DAO : GeneralException 6: getconnection( ) 3: DBManager(String) 8: select(exim.foundation.db.sqlstatement) 12: close(java.sql.connection) : DBManager 7: DBException(String) : DBException 5: SQLStatement(String) 10: getrowcount( ) 11: get(int, int) 9: RecordSet(java.sql.ResultSet) <<control>> JndiManager verbose : boolean = true JndiManager() getinstance() init() main() SQLStatement : SQLStatement <<control>> MessageManager verbose : boolean = true MessageManager() getinstance() init() getmessage() geterrmsg() load() getmsgs() convertproperty() -$m_instance dbconvertproperty() strtokorean() main() : RecordSet <<control>> PropertyManager verbose : boolean = true CONF_FILE_DIR : String = "c:/bea/wlserver6.1/config/mydomain/applications/defaultwebapp/web-inf/classes/exim/property" CONF_FILE : String = "/exim.properties" PropertyManager() getinstance() getinstance() init() init() main() -$m_instance 22

23 Case 2 적용사례분석및평가 장점 체계적이고전략적인아키텍쳐설계방법제공 아키텍쳐품질속성식별 품질시나리오작성 우선순위부여 아키텍쳐분석 평가 최종아키텍쳐결정 요구변화에유연한아키텍쳐설계가능 품질속성및품질시나리오작성시비즈니스목표및향후시스템에대한변경요건을반영할수있음 지식의체계적관리를위한리파지토리구축토대마련 비즈니스전략및시스템요구사항에대한아키텍쳐상기술적의사결정요소의연계사항을축적관리할수있음. 아키텍쳐관련위험관리및품질관리 소프트웨어개발초기단계에서부터아키텍쳐를설계함으로써조기에위험요인을도출하고완화할수있음. 23

24 What do architects really do? RA RA Product Strategy Architecting Architecture Restructuring Design Legacy Code Digging Refactoring Implement Implement 24

No Title

No Title 2001 - Focused on the Finance Domain - 2002 7 3 .,....,. 2002 7 - i - - ii - - iii - Abstract - iv - - v - IT IT.,,.,. (Bottom-Up)..., ATAM (Architecture Trade-off Analysis Method).. - vi - - 1 - - 2 -