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

All Rights reserved and only usage for the authorized person. Developed by Young On, Kim ([email protected])

프로젝트에서 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

Software architecture in practice, 3rd edition


핵심 아키텍처 설계 방법

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

아키텍처 일정

마일스톤

기술 선정 및 검증

Prototype Test 환경

개발 환경

개발 표준

분석 교육

설계 교육

개발 교육

Test 교육

운영 교육

요구사항 확정 기술/표준 확정 지원 및 시스템 테스트 테스트, 이행 준비

운영 환경

개발자 지원, 트러블 슈팅

성능 및 시스템 테스트

이

행

UAT

안정화

아키텍처 검증 - Prototype 개발

• 어플리케이션 구조 • Framework • 표준, 코드, 명명규칙 • 가이드, 템플릿 등 예제 중심 가이드 개발

교육

멘토링

시스템 설치 및 점검

품질점검, 모니터링 강화

• Log 데이터 활용

성능 튜닝

트러블 슈팅

소스 코드 변경 통제 Arch.

Architecture

TA SA DA

최 적 화

실행 아키텍처 개발 지원 테스트 지원 및 이행 준비 조직

이행 준비

추진 단계별 SA의 역할

개발 단계에서의 SA

- 8 -

화면 EAI Framework & COTS

서버, O/S N/W 스토리지 DBMS Backup


All Rights reserved and only usage for the authorized person. Developed by Young On, Kim ([email protected]) - 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 process SW architecture framework



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

Component Class, 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 View Process 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 process Lessons Learned (2/3)


• 프레임워크

통합 개발 환경과 다양한 기술 공통 기능을 제공한다.

상용제품을 프로젝트의 요구에 따른 변경은 신중한 검토가 필요하다.

– 적용사례가 있는 경우에는 적용사례에 준하여 적용하는 것이 바람직하다.

– 결함을 제외한 프레임워크의 기능은 있는 그대로 사용한다.

상용 프레임워크 기능에 공통 기능을 포함하는 것은 신중한 검토가 필요하다.

• 검토 및 모니터링

목록, 설계서, 소스코드 일관성 유지

실행 로그를 통한 검토 및 모니터링 (개발 단계부터)

– Compile 여부, 정상 수행 여부, 처리 시간, Test 횟수, Test 커버리지 등

• 아키텍처 고려 사항

원칙적으로 로직은 어플리케이션 서버에만 구현한다.

시스템 간 데이터를 직접 공유하지 않는다.

데이터를 복제할 경우에는 기준정보를 관리 (MDM – Master Data Management) 한다.

보안에 대한 요구사항은 분석 단계부터 반영한다.

프로그램 실행 메시지는 정상과 비정상 (결함, 장애 등) 상태로 구분하여 코드를 설계한다.

- 17 -

II. SW architecture process Lessons 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 Attributes Business 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 아키텍트의 역할과 역량



SW 아키텍트의 업무

아키텍처 역량 (2/3)

구분 일반 업무 세부 업무

기술 영역

Architecting

아키텍처 개발

아키텍처 평가와 분석

아키텍처 문서화

현행 시스템 유지 보수

기타 아키텍처 업무 수행

아키텍처 이외의 업무

요구사항관리

제품 개발

제품 테스팅

신기술 평가

도구와 기술 선정

비기술 영역

관리

프로젝트 관리

인력 관리

프로젝트 관리 지원

조직과 비지니스관련 업무 조직 지원

비즈니스 지원

리더십과 팀 빌딩 기술적 리더십 발휘

팀 빌딩

의사소통 스킬 Outward/Inward

대인 스킬 Within team/With other people

작업 스킬

리더십

작업량 관리

정보 관리

위기 대응 능력




프랙티스 영역 세부 항목

SW공학 프랙티스 품질 속성 수집

도구와 기술 선정

모델링과 프로토타이핑

아키텍처 설계

아키텍처 문서화

아키텍처 평가

아키텍처 이행

아키텍처 검증

아키텍처 재구조화

기술관리 프랙티스 비즈니스 또는 미션 목표

제품 또는 시스템 정의

자원 배분

프로젝트 관리

Process Discipline

관리자와 협업

조직관리 프랙티스 유능한 기술자 채용

전문 역량 개발

조직 계획 수립

기술 계획 및 예측

아키텍트 역량 프레임워크

아키텍처 역량 (3/3)

일반 지식 영역 세부 지식 영역

컴퓨터 과학

아키텍처 개념

SW공학

설계

프로그래밍

기술과 플랫폼 기술과 플랫폼

조직과 관리

도메인

산업

회사

리더십과 관리

SW 아키텍트의 지식 영역




Questions?

[email protected] 김 영온

- 31 -