창조아카데미(Chap2.프로젝트준비와계획)

Size: px

Start display at page:

Download "창조아카데미(Chap2.프로젝트준비와계획)"

재영 공
5 years ago
Views:

1 프로젝트에서 SW 아키텍트의역할 I. What is software architecture? II. III. IV. SW architecture process SW 아키텍처요구사항 SW 아키텍트의역할과역량

2 정의 I. What is software architecture? 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) 하에서만아키텍처를평가할수있다

3 Books in software architecture I. What is software architecture? 2010/ / /2003/ ~

아키텍처 interact 정보기술 interact 데이터아키텍처 interact 기술아키텍처 데이터아키텍처 EA (Enterprise Architecture) 정보시스템아키텍처 비즈니스아키텍처 어플리케이션아키텍처 기술아키텍처 계획 아키텍처거버넌스,

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

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

SW 아키텍처주요활동 II. SW architecture process 아키텍처수립주기 (ABC - Architecture Business Cycle) 소프트웨어아키텍처는설계를위하여아키텍처를구축하고, 목표시스템또는어플리케이션을구축하고관리하는것을포함한다. SW 아키텍처수립의주요활동 Architect Influence Cycle 1.

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

7 아키텍처설계방법 - ADD II. SW architecture process 핵심아키텍처설계방법 Decomposition, ASR 에따른설계, Generate and test Generate and test process of architecture design Generate Initial Hypothesis Test Hypothesis Generate Next Hypothesis ADD (Attribute-Driven Design) Method 1 설계할시스템요소선택 Breadth-first, depth-first, mixed 2 선택된요소에대한 ASRs 파악 3 선택된요소에대한설계솔루션생성 설계 collateral (existing systems, frameworks, patterns, tactics, design checklists) 활용 4 잔여요구사항검증 / 정련과다음반복을위한투입물선택 5 모든 ASRs을충족할때까지 1~4단계반복 - 7 -

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

9 SW architecture framework II. SW architecture process Methods used in SW Architecture QAW PALM Utility Tree ADD ATAM Lightweight Architecture Evaluation CBAM ASRs 기능 (Functionality) 요구사항정의 SW 아키텍처 상세설계 / 개발 요구사항기능품질속성 ASRs 시나리오 1 원천 2 자극 3 Artifact 4 환경 5 응답 6 응답측정시나리오 가용성상호운영성변경용이성성능보안테스트용이성사용성 전술 품질속성 패턴 체크리스트책임할당조정모델데이터모델아키텍처요소간매핑자원관리바인딩시간결정기술선택체크리스트 SW 아키텍처 모듈뷰 C&C 뷰할당뷰설계가이드개발가이드 Prototype 적용 적용 설계서 설계사양서 화면설계서 구현 SW System 소스코드 Framework 실행코드 제약조정? 제약 조정? 제약사항 H/W 시스템 SW COTS Compliance 납기비용기타 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

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

11 아키텍처평가 - LAE II. SW architecture process 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 시간 보고서는작성하지않고, 회의록만작성한다

12 Tradeoff II. SW architecture process 품질속성간상관관계 (tradeoff) 가용성 효율성 유연성 통합성 호환성 유지보수 이식성 신뢰성 재사용 견고성 테스트 사용성 가용성 (availability) 효율성 (efficiency) 유연성 (flexibility) 통합성 (integrity) 호환성 (interoperability) 유지보수성 (maintainability) 이식성 (portability) 신뢰성 (reliability) 재사용성 (reusability) 견고성 (robustness) 테스트가능성 (testability) 사용성 (usability) Software Requirements, Karl E. Wiegers, 1999,Microsoft Press

13 SW 아키텍처요소간관계 II. SW architecture process SW 에서요구하는기능과품질속성을만족시키기위해다양한아키텍처뷰에속한 SW 구조를결정한다 요구사항정의 / 분석 요구사항과 4+1 뷰아키텍처 Conceptual Usecase Realization Physical Requirement Logical View ( 분석 / 설계 ) Implementation View Needs Functional Class, Object, Package, Composite Structure, State Machine Component Non- Functional Usecase View Quality Attribute Quality Attribute Scenario Sequence, Communication, Activity, Timing, Interaction Overview Process View View Allocation Architecture Styles/Patterns Deployment View Deployment Tactics

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

15 Lessons Learned (1/3) II. SW architecture process 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 배치 ) 사람이우선이다. 사람은믿어라. 그러나사람의작업결과는반드시확인하라. 읽거나들은지식보다는경험이훨씬값지다. 그러나패러다임변화를고려하라. 검증되지않은기술은반드시확인한다. 모든조건이동일하지않으면이전에사용한기술도문제가발생할수있다. configuration management 항상최악의경우를전제로아키텍처를검증한다. 최선을다하되완벽한아키텍처는좋은아키텍처의적일수도있다. 차선을고려하라. 대부분의조직에서기술보다는관리가더중요하다. 표준, 가이드, 프로세스, 재사용은관리를통해이루어진다. 좋은아키텍처는아키텍처변경으로인한 rework 을최소화하는것이다

16 Lessons Learned (2/3) II. SW architecture process 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 일경우처리

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

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

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

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

21 아키텍처요구사항 III. SW 아키텍처요구사항 Architecturally Significant Requirement (ASR) 아키텍처에중요한영향을미치는요구사항으로그런요구사항이없으면아키텍처는아주달라질수있다. ASR 은종종품질속성요구사항형태로문서화되지않는다. 첫단계는중요한이해당사자와의사소통하는것이다. 요구사항정의가끝날때까지기다리지말고아키텍트는작업을시작한다. 요구사항명세서에있는모든요구사항이아키텍처에영향을미치지않는다. ASRs 은개발조직의사업목적에서종종도출된다. ASRs 도출기법 요구사항문서 Stakeholder Interview QAW (Quality Attribute Workshop) PALM (Pedigreed Attribute elicitation Method) Utility Tree

22 비즈니스목표와아키텍처 III. SW 아키텍처요구사항 비즈니스목표는시스템을만드는이유이다. 요구사항에는포함되어있지않더라도비즈니스목표달성은성공적인아키텍처설계를의미한다. 비지니스목표는종종 ASRs 를직접적으로주도한다. 비즈니스목표와아키텍처의관계 1. 비즈니스목표는종종품질속성요구사항을이끈다. 2. 비즈니스목표는품질속성요구사항으로전혀나타나지않지만아키텍처에직접적으로영향을미칠수있다.. 3. 비즈니스목표가아키텍처에전혀영향을미치지못한다. Business Goals 1 Quality Attributes 3 2 Nonarchitectural Solutions Architecture

23 ASR 도출 - QAW III. SW 아키텍처요구사항 QAW (quality attribute workshop) SW 아키텍처완성전에이해당사자참여를통하여 QA 시나리오를찾고, 우선순위를부여하고, 정련 / 중재하는방법 시스템이해당사자의참여에많은영향을받는다. QAW 수행단계 (1/2) 1. QAW 발표 2. 업무 / 미션발표 3. 아키텍처계획발표 4. 아키텍처동인파악 5. 시나리오브레인스토밍 6. 시나리오통합 7. 시나리오우선순위부여 8. 시나리오정련

24 ASR 도출 PALM III. SW 아키텍처요구사항 PALM (Pedigreed Attribute elicitation Method) 비즈니스목표를파악하고문서화하는방법이다. 조직의비즈니스목표를말할수있는이해당사자와아키텍트가참여하는통상 1.5 일워크샵을실시한다. 다음 3 가지목적으로사용한다. 프로젝트초기에찾지못한요구사항을발견하기위해 발견한요구사항에대한추가정보를얻기위해 특히어려운품질속성요구사항을검증하기위하여 PALM 비즈니스목표파악방법 1. PALM 개요발표 2. 비즈니스동인발표 3. 아키텍처동인발표 4. 비즈니스목표파악 5. 비즈니스목표로부터잠재품질속성파악 6. 기정의된품질속성동인에혈통부여 7. 결론도출

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

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

27 아키텍트의역할 (3/3) IV. SW 아키텍트의역할과역량 아키텍트의업무구성 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% 아키텍처업무의일반적인실수 요구사항을모르고아키텍처구축 불필요한요구사항 (goldplating) 어려워서구현불가또는완벽한아키텍처구현 상아탑에서아키텍처구축 자질과경험을보유한아키텍트부재등

28 아키텍처역량 (1/3) IV. SW 아키텍트의역할과역량 개인의역량 Duty 아키텍처설계 Skills 추상적으로생각하는능력 Patterns and Tactics Body of Knowledge Duties Skills Knowledge 아키텍처역량확보를위해서는 업무수행하면서경험축적 비기술적인스킬향상 지식기반습득 (body of knowledge)

29 아키텍처역량 (2/3) IV. SW 아키텍트의역할과역량 SW 아키텍트의업무 구분 일반업무 세부업무 기술영역 Architecting 아키텍처개발아키텍처평가와분석아키텍처문서화현행시스템유지보수기타아키텍처업무수행요구사항관리 아키텍처이외의업무 제품개발제품테스팅신기술평가도구와기술선정 관리 프로젝트관리인력관리프로젝트관리지원 조직과비지니스관련업무 조직지원비즈니스지원 기술적리더십발휘리더십과팀빌딩비기술영역팀빌딩 의사소통스킬 Outward/Inward 대인스킬 Within team/with other people 리더십 작업스킬 작업량관리정보관리 위기대응능력

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

31 Questions? 김영온

UML

UML Introduction to UML Team. 5 2014/03/14 원스타 200611494 김성원 200810047 허태경 200811466 - Index - 1. UML이란? - 3 2. UML Diagram - 4 3. UML 표기법 - 17 4. GRAPPLE에 따른 UML 작성 과정 - 21 5. UML Tool Star UML - 32 6. 참조문헌