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

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 아키텍트의 역할과 역량

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

Books in software architecture
- 3 -
1994
2012/2003/1997
1994
1996 ~ 2007
2001
2010/2002
2011/2005
2002
2000

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 -

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

아키텍처 수립 주기 (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

 핵심 아키텍처 설계 방법
 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

분석(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

- 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

- 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 프로세스

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 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

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

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

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을 최소화하는 것이다.

• 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)

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

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

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

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

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

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

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

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

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

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 아키텍트의 역할과 역량

아키텍처 업무의 일반적인 실수
 요구사항을 모르고 아키텍처 구축
 불필요한 요구사항 (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%
아키텍트의 업무 구성

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

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

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

Questions?
yokim31@daum.net 김 영온
- 31 -

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

Similar to 프로젝트에서 Sw아키텍트의 역할 20140717 (20)

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