프로젝트에서 Sw아키텍트의 역할 20140717

1. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) 프로젝트에서 SW아키텍트의 역할 2014. 7. 17 I. What is software architecture? II. SW architecture process III. SW 아키텍처 요구사항 IV. SW 아키텍트의 역할과 역량

2. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) SW요소와 요소간의 관계 그리고 각각의 속성으로 구성된 시스템에 필요한 구조 의 집합이다. • 아키텍처는 SW 구조의 집합이다. SW시스템은 많은 구조로 이루어진다.  Module view, Component and connector view, Allocation view • 모든 SW 시스템은 SW아키텍처를 가지고 있다. ISO/IEC 42010: 2007 아키텍처 정의: • 컴포넌트와 컴포넌트 상호간 그리고 환경과의 관계, 설계와 개선 시 지켜야 하는 원 칙을 포함하는 시스템의 기본적인 구조 (fundamental organization of a system) TOGAF 아키텍처 정의 • 컴포넌트의 구조와 컴포넌트의 상호 관계 그리고 시간에 걸쳐 설계와 개선 (evolution) 시 지켜야 하는 원칙과 가이드라인 좋은 아키텍처는? • 본질적으로 좋은 아키텍처나 나쁜 아키텍처는 없다. • 어떤 목적에 더 적합한 아키텍처와 더 적합하지 않은 아키텍처가 있을 뿐이다. • 특정 업무 컨텍스트 (context) 하에서만 아키텍처를 평가할 수 있다. 정의 I. What is software architecture? - 2 - Software architecture in practice, 3rd edition

3. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) Books in software architecture - 3 - 1994 2012/2003/1997 1994 1996 ~ 2007 2001 2010/2002 2011/2005 2002 2000 I. What is software architecture?

4. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) ADM (Architecture Development Method) 시스템 구현 (System Realization) 시스템 구현 (System Realization) 시스템 엔터프라이즈 아키텍처 정보기술 비즈니스 아키텍처 App. 아키텍처 데이터 아키텍처 기술 아키텍처 분석 As-is App. Data 기술 To-be App. Data 기술 설계 App. Data 기술 개발, 테스트, 이행 App. Data 기술 interact interact interact interact 통제 (govern) 피드백 요건 제약 요건 상세 요구사항 피드백 설계서 피드백 아 키 텍 처 개 발 계 획 아 키 텍 처 거 버 넌 스 , 아 키 텍 처 역 량 BPR/PI? EA vs. Software Architecture 성공적인 소프트웨어 아키텍처 구축을 위해서는 전사 또는 조직 차원의 IT 거버넌 스가 중요함 TOGAF 9.1 ADM & EA EA vs. Projects 정보시스템 아키텍처 비즈니스 아키텍처 어플리케이션 아키텍처 데이터 아키텍처 기술 아키텍처 EA (Enterprise Architecture) - 4 - I. What is software architecture?

5. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) Applied Software Architecture, C. Hofmeister, Addison Wesley, 2000 SW 아키텍처 설계 도메인 분석, 요구사항 분석, 위험 분석 상세 설계, 코딩, 통합 테스트 요구사항, 요구 속성 요구사항 변경요청 기술 아키텍처 기술아키텍처 변경요청 이행 고려사항 SW 아키텍처 유형별 아키텍처간 상관 관계 소프트웨어 아키텍처는 비즈니스 요구사항에 따라 개발한 기술과 데이터 아키텍 처와 상호 영향을 미치면서 개발함 Relation to architectures 기술 아키텍처 설계 비지니스 아키텍처 (비즈니스 요구사항) 개발 타스크 feedforward feedback 이행 고려사항 Biz. 아키텍처 정보시스템 아키텍처 어플리케이션 아키텍처 데이터 아키텍처 정보시스템 - 5 - I. What is software architecture?

6. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) 아키텍처 수립 주기 (ABC - Architecture Business Cycle) 소프트웨어 아키텍처는 설계를 위하여 아키텍처를 구축하고, 목표 시스템 또는 어플리케이 션을 구축하고 관리하는 것을 포함한다. - 6 - Architect Influence Cycle Business Technical Project Professional Stakeholders 아키텍처 시스템 Architect Architect’s Influence 1. 시스템 타당성 수립 (Making a business case for the system) 2. 중요한 아키텍처 요구사항 이해 (Understanding the architecturally significant requirements) 3. 아키텍처 생성 또는 선택 (Creating or selecting the architecture) 4. 아키텍처 문서화와 의사소통 (Documenting and communicating the architecture) 5. 아키텍처 분석 또는 평가 (Analyzing or evaluating the architecture) 6. 아키텍처 기반 시스템 구축과 테스트 (Implementing and testing the system based on the architecture) 7. 아키텍처에 따라 구축되었는지 확인 (Ensuring that the implementation conforms to the architecture) SW 아키텍처 수립의 주요 활동 SW 아키텍처 주요 활동 II. SW architecture process Software architecture in practice, 3rd edition

7. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net)  핵심 아키텍처 설계 방법  Decomposition, ASR에 따른 설계, Generate and test  ADD (Attribute-Driven Design) Method ① 설계할 시스템 요소 선택  Breadth-first, depth-first, mixed ② 선택된 요소에 대한 ASRs 파악 ③ 선택된 요소에 대한 설계 솔루션 생성  설계 collateral (existing systems, frameworks, patterns, tactics, design checklists) 활용 ④ 잔여 요구사항 검증/정련과 다음 반복을 위한 투입물 선택 ⑤ 모든 ASRs을 충족할 때까지 1~4단계 반복 - 7 - 아키텍처 설계 방법 - ADD Generate Initial Hypothesis Test Hypothesis Generate Next Hypothesis Generate and test process of architecture design II. SW architecture process Software architecture in practice, 3rd edition

8. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) 분석(Inception) 설계(Elaboration) 개발(Construction) 테스트 (Transition) Production구분 아키텍처 일정 마일스톤 기술 선정 및 검증 PrototypeTest 환경 개발 환경 개발 표준 분석 교육 설계 교육 개발 교육 Test 교육 운영 교육 요구사항 확정 기술/표준 확정 지원 및 시스템 테스트 테스트, 이행 준비 운영 환경 개발자 지원, 트러블 슈팅 성능 및 시스템 테스트 이 행 UAT 안정화  아키텍처 검증 - Prototype 개발 • 어플리케이션 구조 • Framework • 표준, 코드, 명명규칙 • 가이드, 템플릿 등  예제 중심 가이드 개발  교육  멘토링  시스템 설치 및 점검  품질점검, 모니터링 강화 • Log 데이터 활용  성능 튜닝  트러블 슈팅  소스 코드 변경 통제Arch. Architecture TA SA DA 최 적 화 실행 아키텍처 개발 지원 테스트 지원 및 이행 준비 조직 이행 준비 추진 단계별 SA의 역할 개발 단계에서의 SA - 8 - 화면 EAI Framework & COTS 서버, O/S N/W 스토리지 DBMS Backup II. SW architecture process

9. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) - 9 - 제약 사항 H/W 시스템 SW COTS Compliance 납기 비용 기타 전술시나리오 체크리스트 품질속성 패턴 모듈 뷰 C&C 뷰 SW 아키텍처 할당 뷰 설계 가이드 개발 가이드 Prototype Framework SW 아키텍처 기능 품질 속성 요구사항 요구사항 정의 설계사양서 실행코드 설계서 소스코드 상세설계/개발 SW System 화면설계서 ATAM Lightweight Architecture Evaluation CBAM QAW PALM Utility Tree Methods used in SW Architecture ADD 제약 조정? ASRs 조정 ?제약 적용 적용 구현 ASRs 기능 (Functionality) QAW: Quality Attribute Workshop PALM: Pedigree Attribute eLicitation Method ADD: Attribute Driven Design ASR: Architecturally Significant Requirement ATAM: Architecture Tradeoff Analysis Method CBAM: Cost Benefit Analysis Method COTS: Commercial Off The Shelf 체크리스트 ① 책임할당 ② 조정모델 ③ 데이터모델 ④ 아키텍처 요소간 매핑 ⑤ 자원관리 ⑥ 바인딩 시간 결정 ⑦ 기술 선택 시나리오 ① 원천 ② 자극 ③ Artifact ④ 환경 ⑤ 응답 ⑥ 응답 측정 ① 가용성 ② 상호 운영성 ③ 변경 용이성 ④ 성능 ⑤ 보안 ⑥ 테스트 용이성 ⑦ 사용성 II. SW architecture processSW architecture framework Software architecture in practice, 3rd edition

10. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) - 10 - ATAM (Architecture Tradeoff Analysis Method)  소프트웨어 아키텍처를 체계적이고 종합적으로 평가하는 방법  아키텍처가 품질 목표를 만족시키는지 평가  그리고 품질 목적이 어떻게 상호작용하는지를 평가 아키텍처 평가 - ATAM 1 단 계 발표 (presentation) step1 - ATAM 소개 평가 리더가 ATAM 설명. 지켜야 할 프로세스 설명, 질의 응답, 범위와 기대 수준 설정 step2 - 사업 동인 설명 PM 또는 고객인 프로젝트 대표자가 비즈니스 관점에서 시스템 개요 설명 step3 - 아키텍처 설명 선임 아키텍트 또는 아키텍처팀이 적절한 수준으로 상세화된 아케텍처 설명 조사와 분석 (investigation and analysis) step4 - 아키텍처 접근법 파악 아키텍처 접근법 이해를 통하여 아키텍처 분석 step5 - 품질 속성 유틸리티 트리 생성 유틸리티 트리 기법을 이용하여 품질 속성 목표를 정교화 step6 - 아키텍처 접근법 분석 높은 우선순위를 가진 시나리오 분석. 의사결정 문서화 (위험, 위험아님, 민감도, tradeoffs) 2 단 계 우선순위 부여 및 접근법 확정 (priority and analysis) step7 - 브레인스토밍과 우선순위 부여 이해당사자와 시나리오를 공유하고, 브레인스토밍을 통하여 시나리오 우선순위 결정 step8 - 아키텍처 접근법 분석/확정 선정된 시나리오에 대하여 아키텍트가 아키텍처 의사결정을 통하여 어떻게 구현할지를 설명 보고 (reporting) step9 - 결과 발표 이해 당사자에게 설명 ATAM 프로세스 II. SW architecture process Software architecture in practice, 3rd edition

11. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) LAE (Lightweight Architecture Evaluation) • ATAM은 효율적이나 평가팀 20 ~ 30 man/days, 아키텍트와 이해당사자는 그 이상 의 공수가 필요함 • Lightweight Architecture Evaluation (전체 4 ~ 6 시간) 1. ATAM 소개 : 0 시간 2. 비즈니스 동인(動因) 소개 : 15분 3. 아키텍처 소개 : 30분 4. 아키텍처 접근법 식별 : 15분 5. 품질속성 유틸리티 트리 작성 : 30분 ~ 1시간 30분 6. 아키텍처 접근법 분석 : 2 ~ 3시간 7. 브레인스토밍과 시나리오 우선순위 결정 : 0시간 8. 아키텍처 접근법 분석 반복 : 0시간 9. 결과 발표 순서로 이루어진다. : 0시간 • 보고서는 작성하지 않고, 회의록만 작성한다. - 11 - 아키텍처 평가 - LAE II. SW architecture process Software architecture in practice, 3rd edition

12. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) Software Requirements, Karl E. Wiegers, 1999,Microsoft Press 가 용 성 효 율 성 유 연 성 통 합 성 호 환 성 유 지 보 수 이 식 성 신 뢰 성 재 사 용 견 고 성 테 스 트 사 용 성 가용성 (availability) 효율성 (efficiency) - - - - - - - - 유연성 (flexibility) - - + + + + 통합성 (integrity) - - - - - 호환성 (interoperability) - + - + 유지보수성 (maintainability) + - + + + 이식성 (portability) - + + - + + - 신뢰성 (reliability) + - + + + + + 재사용성 (reusability) - + - + + + - + 견고성 (robustness) + - + + 테스트 가능성 (testability) + - + + + + 사용성 (usability) - + - 품질속성간 상관 관계 (tradeoff) - 12 - Tradeoff II. SW architecture process

13. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) SW에서 요구하는 기능과 품질속성을 만족시키기 위해 다양한 아키텍처 뷰에 속 한 SW 구조를 결정한다 - 13 - Sequence, Communication, Activity, Timing, Interaction Overview Deployment ComponentClass, Object, Package, Composite Structure, State Machine Requirement Functional Non- Functional Usecase View Logical View (분석/설계) Usecase Realization Needs Quality Attribute Quality Attribute Scenario Tactics Implementation View Deployment ViewProcess View View Allocation Architecture Styles/Patterns Conceptual Physical 요구사항과 4+1 뷰 아키텍처 요구사항 정의/분석 SW 아키텍처 요소간 관계 II. SW architecture process

14. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) • 아키텍처 프로토타입 (executable) • 설계 가이드라인  아키텍처 설계 가이드라인  DB 설계 가이드라인  프로그래밍 가이드라인  …… • 프로그래밍 가이드라인  소스 코드의 일관성 유지, 개발자의 불필요한 창의성 제한 및 유연성 제고 • 테스팅 가이드라인  개별 컴포넌트 테스팅 – Testing harnesses. Stubs  시스템 품질 속성 테스팅 – 성능, 신뢰성, 가용성, 보안, … • 변경 가이드라인  DB. 인터페이스, 컴포넌트, 컴포넌트, 프레임워크 변경 • SW 형상 관리 계획 • Framework  시스템의 App. 도메인에 적합한 재사용 가능한 라이브러리 또는 클래스의 집합  아키텍처와 구현이 만나는 장소로 F/W은 아키텍처를 내재하고 있음 Architecture 산출물 - 14 - II. SW architecture process

15. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) SA, TA, DA는 밀접한 영향을 미친다. • System architecture  Hardware – Server, Storage, N/W, 기타 devices, Appliance, ….  COTS – Web server, WAS, DBMS, EAI, Security, UI, Log, Data Grid …..  Solutions packages • Data architecture  As-is data 전환  To-be architecture – Data access policy (security) – 데이터 중복 (기준 데이터 관리 및 동기화) – Backup (실시간 vs 배치) - 15 - Lessons Learned (1/3)  사람이 우선이다. 사람은 믿어라. 그러나 사람의 작업 결과는 반드시 확인하라.  읽거나 들은 지식보다는 경험이 훨씬 값 지다. 그러나 패러다임 변화를 고려하라.  검증 되지 않은 기술은 반드시 확인한다.  모든 조건이 동일하지 않으면 이전에 사 용한 기술도 문제가 발생할 수 있다. – configuration management  항상 최악의 경우를 전제로 아키텍처를 검증한다.  최선을 다하되 완벽한 아키텍처는 좋은 아키텍처의 적일 수도 있다. 차선을 고려 하라.  대부분의 조직에서 기술 보다는 관리가 더 중요하다. 표준, 가이드, 프로세스, 재 사용은 관리를 통해 이루어진다.  좋은 아키텍처는 아키텍처 변경으로 인한 rework을 최소화하는 것이다. II. SW architecture process

16. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) • Context, 도메인을 고려하지 못한 SW아키텍처는 무의미하다.  검증되지 않은 기술과 업무는 PoC, Prototyping을 통하여 검증한다. (Agile, 반복/점진적)  온라인, 화면 스타일/스크립트, Batch, UNIX shell, SQL 등 모든 요소를 포함한다. • 개발 방법론 Ownership?  설계, 개발, 테스트, 이행 표준 및 가이드는 프로젝트 차원에서 점검, 개발 또는 보완한다. • OO/CBD 프로젝트에서 Class Ownership  개발 및 테스트  SQL in Entity class  Object Relation Mapping – Entity와 Entity Class가 n:m일 경우 처리 - 16 - II. SW architecture processLessons Learned (2/3)

17. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) • 프레임워크  통합 개발 환경과 다양한 기술 공통 기능을 제공한다.  상용제품을 프로젝트의 요구에 따른 변경은 신중한 검토가 필요하다. – 적용사례가 있는 경우에는 적용사례에 준하여 적용하는 것이 바람직하다. – 결함을 제외한 프레임워크의 기능은 있는 그대로 사용한다.  상용 프레임워크 기능에 공통 기능을 포함하는 것은 신중한 검토가 필요하다. • 검토 및 모니터링  목록, 설계서, 소스코드 일관성 유지  실행 로그를 통한 검토 및 모니터링 (개발 단계부터) – Compile 여부, 정상 수행 여부, 처리 시간, Test 횟수, Test 커버리지 등 • 아키텍처 고려 사항  원칙적으로 로직은 어플리케이션 서버에만 구현한다.  시스템 간 데이터를 직접 공유하지 않는다.  데이터를 복제할 경우에는 기준정보를 관리 (MDM – Master Data Management) 한다.  보안에 대한 요구사항은 분석 단계부터 반영한다.  프로그램 실행 메시지는 정상과 비정상 (결함, 장애 등) 상태로 구분하여 코드를 설계한다. - 17 - II. SW architecture processLessons Learned (3/3)

18. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) 기능 요구사항 (functional requirements) • “시스템이 해야 할 것”, “시스템이 어떻게 작동할지?” “실행시간 자극에 어떻게 반응 할지?”를 기술한다. • 기능 요구사항은 설계에서 적절한 순서로 책임을 할당하여 만족시키는데, 아키텍처 요소에 책임을 할당하는 것은 중요한 아키텍처 설계 결정이다. 품질 속성 요구사항 (quality attribute requirements) • 기능 요구사항 또는 전체 제품의 자격요건 (qualification)이다.  응답속도, 오류 input 처리 유연성, 제품 전개 시간, 운영 비용 등등. • 품질 속성 요구사항은 아키텍처로 설계된 다양한 구조와 구조에 내재된 요소의 행 위와 상호작용에 의해 충족된다. 제약사항 (constraints) • 선택의 여지가 없는 설계 결정 사항이다.  프로그래밍 언어, Legacy 재사용, H/Ws, COTS, ….. • 제약사항은 설계에서 받아들이고, 다른 영향받는 설계 결정과 조화를 이루어야 한다 - 18 - SW 아키텍처 제약사항 품질 속성기능 요구사항 요구사항, 제약사항 & SA III. SW 아키텍처 요구사항 Software architecture in practice, 3rd edition

19. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) • 품질 속성은 시스템이 이해당사자의 요구를 얼마나 잘 만족시키는지를 나타내는 측 정가능하고, 테스트 가능한 시스템의 특성이다. • 품질 속성은 시스템 기능과 함께 아키텍처에 영향을 준다. • 시스템이 변경되는 이유는 대부분 기능 때문이 아니고 비기능 요구사항과 관련된다. • 구체적인 품질 속성을 분석하는 것은 아키텍트로서 가져야 할 핵심 스킬이다. - 19 - 품질 속성 (quality attributes) ISO 25010 품질 속성 기능성 효율성 호환성 사용성 신뢰성 보안 유지보수성 이식성 Software architecture in practice 가용성 변경용이성 성능 보안 테스트 가능성 사용성 비지니스 품질 Time to market 비용과 수익 Projected lifetime of the system Targeted market 납기 Legacy 통합 Quality Attributes 상호운영성 III. SW 아키텍처 요구사항 Software architecture in practice, 3rd edition

20. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net)  품질 속성 달성은 설계, 구축, 전개 전 단계에서 고려되어야 한다.  어떤 품질 속성도 설계에만 의존적이지 않고, 마찬가지로 구현이나 전개에만 의존적이지 않다.  만족스러운 결과는 큰 그림인 아키텍처와 상세 내역인 구축을 제대로 구축하여 얻는다.  아키텍처 그 자체로는 품질을 달성할 수 없다. 품질을 달성하는 기반을 제공하지만, 상세 구현에 주의하지 않으 면 원하는 품질을 얻을 수 없다.  복잡한 시스템에서 품질 속성은 독립적으로 달성되지 않는다. 어떤 품질 속성의 달성은 다른 품질 속성의 달성 에 긍정 또는 부정적인 영향을 미친다 (tradeoffs - ATAM) 아키텍처적인 비아키텍처적인 사용성  작업을 취소하는 기능 (cancel)  작업을 원위치하는 기능 (undo)  이전에 입력한 데이터 재사용  UI를 명확하고, 사용하기 쉽게 개발  라디오 버튼 또는 체크 박스 제공  직관적인 화면 Layout  보기 좋은 활자체 변경 용이성  기능을 어떻게 나눌 것인가?  모듈 내 코딩 기법 성능  컴포넌트 간 어느 정도 통신할 것인지?  각 컴포넌트에 어떤 기능을 할당할 것인 지?  공유 자원을 어떻게 할당할 것인지?  기능 구현을 위한 알고리즘의 선택  알고리즘을 어떻게 코딩할 것인지? 아키텍처와 품질속성 - 20 - 요구사항 (requirements) III. SW 아키텍처 요구사항 Software architecture in practice, 3rd edition

21. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net)  Architecturally Significant Requirement (ASR)  아키텍처에 중요한 영향을 미치는 요구사항으로 그런 요구사항이 없으면 아키텍처 는 아주 달라질 수 있다.  ASR은 종종 품질 속성 요구사항 형태로 문서화되지 않는다.  첫 단계는 중요한 이해당사자와 의사 소통하는 것이다.  요구사항 정의가 끝날 때까지 기다리지 말고 아키텍트는 작업을 시작한다.  요구사항 명세서에 있는 모든 요구사항이 아키텍처에 영향을 미치지 않는다.  ASRs은 개발 조직의 사업 목적에서 종종 도출된다.  ASRs 도출 기법  요구사항 문서  Stakeholder Interview  QAW (Quality Attribute Workshop)  PALM (Pedigreed Attribute eLicitation Method)  Utility Tree - 21 - 아키텍처 요구사항 III. SW 아키텍처 요구사항 Software architecture in practice, 3rd edition

22. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net)  비즈니스 목표는 시스템을 만드는 이유이다. 요구사항에는 포함되어 있지 않더 라도 비즈니스 목표 달성은 성공적인 아키텍처 설계를 의미한다. 비지니스 목표 는 종종 ASRs를 직접적으로 주도한다.  비즈니스 목표와 아키텍처의 관계 1. 비즈니스 목표는 종종 품질 속성 요구사항을 이끈다. 2. 비즈니스 목표는 품질 속성 요구사항으로 전혀 나타나지 않지만 아키텍처에 직접적 으로 영향을 미칠 수 있다.. 3. 비즈니스 목표가 아키텍처에 전혀 영향을 미치지 못한다. - 22 - 비즈니스 목표와 아키텍처 Quality AttributesBusiness Goals Nonarchitectural Solutions Architecture 1 2 3 III. SW 아키텍처 요구사항 Software architecture in practice, 3rd edition

23. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net)  QAW (quality attribute workshop)  SW아키텍처 완성 전에 이해당사자 참여를 통하여 QA 시나리오를 찾고, 우선순위를 부여하고, 정련/중재하는 방법  시스템 이해당사자의 참여에 많은 영향을 받는다.  QAW 수행 단계 (1/2) 1. QAW 발표 2. 업무/미션 발표 3. 아키텍처 계획 발표 4. 아키텍처 동인 파악 5. 시나리오 브레인스토밍 6. 시나리오 통합 7. 시나리오 우선순위 부여 8. 시나리오 정련 - 23 - ASR 도출 - QAW III. SW 아키텍처 요구사항 Software architecture in practice, 3rd edition

24. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net)  PALM (Pedigreed Attribute eLicitation Method) 비즈니스 목표를 파악하고 문서화하는 방법이다. 조직의 비즈니스 목표를 말할 수 있는 이해당사자와 아키텍트가 참여하는 통상 1.5일 워크샵을 실시한다. 다음 3가지 목적으로 사용한다.  프로젝트 초기에 찾지 못한 요구사항을 발견하기 위해  발견한 요구사항에 대한 추가 정보를 얻기 위해  특히 어려운 품질 속성 요구사항을 검증하기 위하여  PALM – 비즈니스 목표 파악 방법 1. PALM 개요 발표 2. 비즈니스 동인 발표 3. 아키텍처 동인 발표 4. 비즈니스 목표 파악 5. 비즈니스 목표로 부터 잠재 품질 속성 파악 6. 기 정의된 품질 속성 동인에 혈통 부여 7. 결론 도출 - 24 - ASR 도출 – PALM III. SW 아키텍처 요구사항 Software architecture in practice, 3rd edition

25. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) Inception Elaboration Construction Transition 아키텍처 프로토타이핑 개발/구매 여부 결정 초기 시나리오 정의 아키텍처 평가 기준 정의 아키텍처 베이스라인 초기 시나리오 데모 개발/구매 베이스라인 아키텍처 유지보수 Multiple-component 이슈 해결 성능 튜닝 품질 개선 아키텍처 유지보수 Multiple-component 이슈 해결 성능 튜닝 품질 개선 Software architecture team activities Software Architecture 산출물  아키텍처 명세서  요구사항 세트  설계 세트  릴리즈 명세서 책임  요구사항 대안 선택  설계 대안 선택  컴포넌트 선정  초기 통합  기술적 위험 해결 데모 Use case 모델러 설계 모델러 성능 분석가 라이프 싸이클 중점 아키텍트의 역할 (1/3) • 시스템의 아키텍처 정의 및 정합성 유지  SW 아키텍처  설계, 개발, 테스트 표준 및 가이드 • 기술 위험 평가  위험 완화 전략 수립 및 조치 • 프로젝트 계획 참여 • 설계, 이행, 테스트 지원 • 아키텍처 준수 모니터링 - 25 - IV. SW 아키텍트의 역할과 역량 Software Project Management: A Unified Framework, Walker Royce, 1998

26. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) Discipline Breadth role Depth role Business Modeling Business Process Analyst Business Designer Discovers all business use cases. Details a single set of business use cases. Requirements Systems Analyst Requirements Specifier Discovers all requirement use cases. Details a single set of requirement use cases. Analysis and Design Software Architect Designer Decides on technologies for the whole solution. Details the analysis and design for a single set of use cases. Implementation Integrator Implementer Owns the build plan that shows what classes will integrate with one another. Codes a single set of classes or a single set of class operations. Test Test Manager Test Designer Ensures that testing is complete and conducted for the right motivators. Implements automated portions of the test design for the iteration. Test Analyst Tester Selects what to test based on the motivators. Runs a specific test. Test Designer Decides what tests should be automated vs. manual and creates automations. Deployment Deployment Manager Tech Writer, Course Developer, Graphic Artist Oversees deployment for all deployment units. Create detailed materials to ensure a successful deployment. Project Management Project Manager Project Manager Creates the business case and a coarse-grained plan; makes go / no go decisions. Plans, tracks, and manages risk for a single iteration. Environment Process Engineer Tool Specialist Owns the process for the project. Creates guidelines for using a specific tool. Configuration and Change Mgt Configuration Manager Configuration Manager Sets up the CM environment, policies, and plan. Creates a deployment unit, reports on configuration status, performs audits, and so forth. Change Control Manager Change Control Manager Establishes a change control process. Reviews and manages change requests. Breadth and depth roles in RUP disciplines - 26 - [IBM] 아키텍트의 역할 (2/3) IV. SW 아키텍트의 역할과 역량

27. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) 아키텍처 업무의 일반적인 실수  요구사항을 모르고 아키텍처 구축  불필요한 요구사항 (goldplating)  어려워서 구현 불가 또는 완벽한 아키텍처 구현  상아탑에서 아키텍처 구축  자질과 경험을 보유한 아키텍트 부재 등 아키텍트의 역할 (3/3) - 27 - Architecting Getting input Providing info Recommendation 50% 25% 25% Goldplating 60% 30% 10% Ivory tower 70% 15% 15% Absent Architect 30% 40% 30% Just consultant 25% 25% 50% 아키텍트의 업무 구성 IV. SW 아키텍트의 역할과 역량

28. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) 개인의 역량 • Duty – 아키텍처 설계 • Skills – 추상적으로 생각하는 능력 • Patterns and Tactics – Body of Knowledge 아키텍처 역량 확보를 위해서는 • 업무 수행하면서 경험 축적 • 비기술적인 스킬 향상 • 지식 기반 습득 (body of knowledge) - 28 - Skills Duties Knowledge 아키텍처 역량 (1/3) IV. SW 아키텍트의 역할과 역량 Software architecture in practice, 3rd edition

29. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) - 29 - SW 아키텍트의 업무 아키텍처 역량 (2/3) 구분 일반 업무 세부 업무 기술 영역 Architecting 아키텍처 개발 아키텍처 평가와 분석 아키텍처 문서화 현행 시스템 유지 보수 기타 아키텍처 업무 수행 아키텍처 이외의 업무 요구사항관리 제품 개발 제품 테스팅 신기술 평가 도구와 기술 선정 비기술 영역 관리 프로젝트 관리 인력 관리 프로젝트 관리 지원 조직과 비지니스관련 업무 조직 지원 비즈니스 지원 리더십과 팀 빌딩 기술적 리더십 발휘 팀 빌딩 의사소통 스킬 Outward/Inward 대인 스킬 Within team/With other people 작업 스킬 리더십 작업량 관리 정보 관리 위기 대응 능력 IV. SW 아키텍트의 역할과 역량 Software architecture in practice, 3rd edition

30. All Rights reserved and only usage for the authorized person. Developed by Young On, Kim (yokim31@daum.net) - 30 - 프랙티스 영역 세부 항목 SW공학 프랙티스 품질 속성 수집 도구와 기술 선정 모델링과 프로토타이핑 아키텍처 설계 아키텍처 문서화 아키텍처 평가 아키텍처 이행 아키텍처 검증 아키텍처 재구조화 기술관리 프랙티스 비즈니스 또는 미션 목표 제품 또는 시스템 정의 자원 배분 프로젝트 관리 Process Discipline 관리자와 협업 조직관리 프랙티스 유능한 기술자 채용 전문 역량 개발 조직 계획 수립 기술 계획 및 예측 아키텍트 역량 프레임워크 아키텍처 역량 (3/3) 일반 지식 영역 세부 지식 영역 컴퓨터 과학 아키텍처 개념 SW공학 설계 프로그래밍 기술과 플랫폼 기술과 플랫폼 조직과 관리 도메인 산업 회사 리더십과 관리 SW 아키텍트의 지식 영역 IV. SW 아키텍트의 역할과 역량 Software architecture in practice, 3rd edition

프로젝트에서 Sw아키텍트의 역할 20140717

Young On Kim

프로젝트에서 Sw아키텍트의 역할 20140717