| 000 | 01169camccc200373 k 4500 | |
| 001 | 000045534335 | |
| 005 | 20100807034800 | |
| 007 | ta | |
| 008 | 090527s2009 ggka b 001a kor | |
| 020 | ▼a 9788960770782 | |
| 035 | ▼a (KERIS)BIB000011662066 | |
| 040 | ▼a 211006 ▼c 211006 ▼d 211009 | |
| 041 | 1 | ▼a kor ▼h eng |
| 082 | 0 4 | ▼a 005.1 ▼2 22 |
| 090 | ▼a 005.1 ▼b 2009z8 | |
| 100 | 1 | ▼a Clements, Paul , ▼d 1955- |
| 245 | 1 0 | ▼a 소프트웨어 아키텍처 평가 / ▼d 폴 클레멘츠 , ▼e 릭 캐즈먼 , ▼e 마크 클라인 지음 ; ▼e 이석준 , ▼e 백창현 , ▼e 박인수 옮김. |
| 246 | 1 9 | ▼a Evaluating software architectures : methods and case studies |
| 260 | ▼a 의왕 : ▼b 에이콘 , ▼c 2009. | |
| 300 | ▼a 340 p. : ▼b 삽도 ; ▼c 26 cm. | |
| 440 | 0 0 | ▼a 에이콘 소프트웨어 아키텍처 시리즈 ; ▼v 4 |
| 504 | ▼a 참고문헌(p. 331-335)및 색인수록 | |
| 650 | 0 | ▼a Computer software ▼x Evaluation. |
| 650 | 0 | ▼a Computer architecture ▼x Evaluation. |
| 700 | 1 | ▼a Kazman, Rick |
| 700 | 1 | ▼a Klein, Mark |
| 700 | 1 | ▼a 이석준 , ▼e 역 |
| 700 | 1 | ▼a 백창현 , ▼e 역 |
| 700 | 1 | ▼a 박인수 , ▼e 역 |
| 900 | 1 1 | ▼a 클레멘츠, 폴 |
| 900 | 1 1 | ▼a 캐즈먼, 릭 |
| 900 | 1 1 | ▼a 클라인, 마크 |
| 945 | ▼a KINS |
소장정보
| No. | 소장처 | 청구기호 | 등록번호 | 도서상태 | 반납예정일 | 예약 | 서비스 |
|---|---|---|---|---|---|---|---|
| No. 1 | 소장처 과학도서관/Sci-Info(1층서고)/ | 청구기호 005.1 2009z8 | 등록번호 121184235 (8회 대출) | 도서상태 대출가능 | 반납예정일 | 예약 | 서비스 |
컨텐츠정보
책소개
올바른 아키텍처를 선택하거나 수립했는지를 평가하는 데 활용할 수 있는 ATAM 등 평가 기법을 소개하고 이를 기반으로 아키텍처 평가를 수행하는 데 실질적인 절차와 지침을 제공하는 책이다.
이 책에서는 아키텍처 설계 의사결정과 그 결과인 소프트웨어 자산 간에 명확하게 파악된 연결관계를 그려내기 위해 소프트웨어 아키텍처 평가방법과 이를 실제 적용한 사례를 설명한다. 이 방법은 아키텍처 평가에 개발 일정(대개 며칠 이내)을 좀더 늘리거나 비용을 추가하는 것만으로도 실제로 위험을 감소시킬 수 있다는 사실을 보여준다.
이 책은 아키텍처 평가에 대한 개념적인 배경 소개와 많은 정부기관과 업계에서 실제 수행됐던 내용을 기반한 단계적 가이드를 제공한다. 이 책에서 다룬 상세한 사례연구를 통해 평가방법을 실제 시스템에 적용했을 때의 가치를 보여주며, 보충 설명을 통해 이 책의 전반에 걸쳐 어려운 상황에서 도출된 실제 팁과 흥미로운 배경 이야기를 제공한다.
이 책에서는 아키텍처 설계 의사결정과 그 결과인 소프트웨어 자산 간에 명확하게 파악된 연결관계를 그려내기 위해 소프트웨어 아키텍처 평가방법과 이를 실제 적용한 사례를 설명한다. 이 방법은 아키텍처 평가에 개발 일정(대개 며칠 이내)을 좀 더 늘리거나 비용을 추가하는 것만으로도 실제로 위험을 감소시킬 수 있다는 사실을 보여준다. 또한 아키텍처 평가에 대한 개념적인 배경 소개와 많은 정부기관과 업계에서 실제 수행됐던 내용을 기반으로 한 단계적 가이드도 제공한다.
특히 다음 세 가지 주요 평가방법을 설명한다.
■ 아키텍처 트레이드오프 분석방법 (ATAM)
■ 소프트웨어 아키텍처 분석방법 (SAAM)
■ 중간설계에 대한 능동적 검토 (ARID)
이 책에서 다룬 상세한 사례연구를 통해 평가방법을 실제 시스템에 적용했을 때의 가치를 보여주며, 보충설명을 통해 이 책의 전반에 걸쳐 어려운 상황에서 도출된 실제 팁과 흥미로운 뒷이야기를 제공한다.
소프트웨어 엔지니어라면 어떻게 소프트웨어 아키텍처 평가를 수행하는지를 반드시 알아야 한다. 이 책을 읽으면 아키텍처 평가에 대해 정리된 경험담을 통해 좀 더 쉽게 익힐 수 있을 것이다.
★ 이 책의 구성 ★
이 책을 읽는 독자는 아키텍처 이슈에는 능통하지만 아키텍처 평가는 실무 경험이 없다고 가정한다. 이 책은 다음과 같은 주제를 다룬다.
● 1장은 이 책에서 사용되는 공통적인 개념의 시작점을 잡고 용어를 정립하기 위해 소프트웨어 아키텍처의 주제를 간단히 소개한다.
● 2장은 소프트웨어 아키텍처 평가를 설명할 수 있는 기반을 마련한다. 아키텍처 평가를 하는 이유와 시점, 참여자, 비용과 이점 및 평가에서 어떤 실질적인 결과를 기대할 수 있을지를 논의한다.
● 3장은 이 책에서 설명할 방법 중 첫 번째며 가장 자세하게 다룬 아키텍처 트레이드오프 분석방법(ATAM)을 소개한다. 또한 ATAM의 주요단계와 세부단계를 설명한다.
● 4장은 ATAM을 실제 시스템에 적용한 짧은 사례연구로서, 이를 통해 앞 장에서 배운 세부단계가 적용된 모습을 간략히 볼 수 있다.
● 5장은 ATAM에 깔린 기본 개념과 관련된 소프트웨어 아키텍처 평가방법을 소개한다. 여기에는 품질속성 특징화와 분석 질문과의 관계, 그리고 속성 기반의 아키텍처 스타일(ABAS) 등이 있다.
● 6장은 미 항공 우주국(NASA)에서 운영되는 시스템에 적용된 ATAM을 자세하고 심층적으로 소개한다. 이 사례연구는 4장에서 설명한 방법의 세부단계와 유사하지만, 실무적이고 상세한 내용에 집중하고 있으며 경험 기반의 지침(즉 계획대로 진행되지 않을 때 무엇을 할지 등)을 제공한다.
● 7장은 변경용이성(그리고 이에 관련된 이식용이성, 확장용이성, 유지보수성 등)과 기능성 면에서 아키텍처를 평가하는 데 특화된 방법인 소프트웨어 아키텍처 분석방법(SAAM)을 소개한다. SAAM을 적용한 검증된 사례연구도 살펴본다.
● 8장은 아키텍처의 한 부분으로 제공되는 실행가능성과 적합성을 시험하는 방법인 중간설계에 대한 능동적 검토(ARID)를 제공한다. ARID는 부분적인 설계를 평가하는 데 유용하다. 여기에도 ARID를 적용한 사례연구를 담았다.
● 9장은 ATAM, SAAM, ARID와 그 밖의 여러 아키텍처 평가방법을 광범위하게 비교해본다.
● 10장은 조직 차원에서 제도화된 아키텍처 기반 소프트웨어 개발로 변화해가는 데 중요한 단계인 지속적인 아키텍처 평가 역량의 증대에 대해 이야기한다.
● 11장은 결론과 마무리 부분으로서 내용을 정리한다.
★ 이 책의 대상 독자 ★
이 책은 아키텍처 평가자에게 직접 이야기하는 형식으로 썼지만 고객과 프로젝트 대표자(특히 아키텍트)도 이 책을 읽음으로써 아키텍처 평가 프로세스가 무엇인지를 배울 수 있다. 특히 이 책은 다음과 같은 네 종류의 독자를 염두에 뒀다.
● 평가자: 아키텍처 평가팀을 이끌거나 팀에 지원할 예정인 사람. 신입 평가자는 모든 장을 주의 깊게 읽어야 한다. 경력을 쌓은 평가자는 평가방법(3장, 7장, 8장)을 설명한 장과 품질속성에 깔린 개념(5장)에 집중해야 한다.
● 고객: 아키텍처 평가를 의뢰할 예정이어서 아키텍처 평가에 어떤 내용이 포함되는지를 배우고자 하는 사람. 고객은 1장과 2장을 중점적으로 읽는다. 고객 입장에서 어떤 방법이 프로젝트에 가장 적합한지에 대한 확신이 없다면 평가방법을 소개하는 3장, 7장, 8장은 대략 훑으면 된다. 평가방법을 선택하는 데 도움이 되는 9장을 먼저 읽고 적합한 방법을 다루는 이전 장을 주의 깊게 다시 읽는 것도 한 방법이다.
● 프로젝트 구성원: 아키텍처 평가를 받아야 하는 프로젝트 대표자(아키텍트, 관리자, 기타 프로젝트 구성원)는 평가를 통해 무엇을 기대할지를 배우기 바랄 것이다. 프로젝트 구성원은 1장과 2장을 가볍게라도 읽어야 한다. 다음에는 프로젝트에 사용될 방법을 정의하는 장(3장, 7장, 8장)을 읽어야 한다. 그 다음에는 해당 방법을 적용한 사례연구를 담은 장을 읽는다. 4장, 6장에 ATAM에 대한 사례연구가 포함돼 있다. 아키텍트는 자신이 만든 창작물이 평가를 받게 되는 특별한 프로젝트 구성원이다. ATAM을 사용한다면 아키텍트는 앞에 언급한 장에 덧붙여 5장도 읽어야 한다.
● 평가부서 관리자: 조직 내에 아키텍처 평가 역량을 키우고 싶은 사람은 전체 장의 내용을 잘 알아야 하지만 특히 10장을 잘 알아야 한다. 4장, 6장, 7장, 8장에 있는 사례연구는 팀에서 시범으로 평가를 수행하는 데 참조 자료로 사용할 수 있다.
정보제공 :
저자소개
폴 클레멘츠(지은이)
빅레버 소프트웨어(BigLever Software Inc.)의 고객 성공 부서 부사장이다. 이전에는 워싱턴 DC의 미해군 연구소(The U.S. Naval Research Laboratory)에서 컴퓨터 과학자로 일하면서 고급 소프트웨어 엔지니어링 원칙들을 실시간 임베디드 시스템에 적용하는 업무를 수행했다. 그 후에 카네기 멜론 대학교 SEI의 기술 부서 수석 구성원으로서 소프트웨어 제품 라인 엔지니어링과 소프트웨어 아키텍처 설계, 문서화, 분석에 관한 프로젝트를 이끌었다. 이 책 외에도 『소프트웨어 아키텍처 문서화』(에이콘, 2016)와, 『소프트웨어 아키텍처 평가』(에이콘, 2009)을 공저했다. 까다로운 소프트웨어 시스템의 설계와 명세화에 대한 오랜 관심을 두고 있으며, 소프트웨어 엔지니어링에 관한 100여 개의 논문을 썼다.
이석준(옮긴이)
뉴사우스웨일스 대학원에서 정보공학을 전공했으며 삼성 SDS 아키텍처팀에서 소프트웨어 아키텍트로 활동하고 있다. SEI에서 소프트웨어 아키텍처 전문가 자격과 ATAM 평가자 자격을 수료했다. 참여한 다수 프로젝트에서 소프트웨어 아키텍처 수립 및 절차를 반영하는 데 많은 노력을 하고 있으며 이와 관련한 사내 과정의 집필과 강의를 맡고 있다. 『소프트웨어 아키텍처: 이론과 실제』(에이콘출판사, 2007)를 번역했다.
목차
목차 이 책에 쏟아진 찬사 = 4 저자 소개 = 7 한국어판 특별 서문 = 8 저자 서문 = 9 감사의 글 = 12 옮긴이 소개 = 14 옮긴이의 말 = 16 들어가며 = 30 1장 소프트웨어 아키텍처 1.1 이해관계자 간 의사소통 수단으로서의 아키텍처 = 35 1.1.1 아키텍처와 이해관계자에게 미치는 영향 = 35 1.1.2 아키텍처 뷰 = 36 1.1.3 아키텍처 설명 언어 = 42 1.2 초기 설계 의사결정에 대한 방향선언으로서의 아키텍처 = 43 1.2.1 아키텍처 스타일 = 44 1.3 재사용가능하고 이전할 수 있는, 시스템 추상화로서의 아키텍처 = 46 1.4 정리 = 47 1.5 더 읽을거리 = 47 1.6 생각해볼 문제 = 49 2장 소프트웨어 아키텍처 평가 2.1 아키텍처 평가 이유 = 55 2.2 아키텍처 평가 시점 = 56 2.3 아키텍처 평가 참여자 = 57 2.4 아키텍처 평가의 예상 결과 = 58 2.5 아키텍처 평가대상 품질속성 = 62 2.6 품질속성 분석의 모호성 = 64 2.7 아키텍처 평가의 결과물 = 66 2.7.1 ATAM, SAAM, ARID의 결과물 = 66 2.7.2 ATAM만의 결과물 = 67 2.8 아키텍처 평가 수행의 이점과 비용 = 69 2.9 더 읽을거리 = 73 2.10 생각해볼 문제 = 74 3장 ATAM - 아키텍처 평가방법 3.1 ATAM 스텝의 요약 = 76 3.2 ATAM 스텝 상세 설명 = 77 3.2.1 스텝 1: ATAM 프리젠테이션 = 77 3.2.2 스텝 2: 비즈니스 동인 프리젠테이션 = 78 3.2.3 스텝 3: 아키텍처 프리젠테이션 = 79 3.2.4 스텝 4: 아키텍처 접근방법 식별 = 79 3.2.5 스텝 5: 품질속성 유틸리티 트리 작성 = 82 3.2.6 스텝 6: 아키텍처 접근방법 분석 = 88 3.2.7 스텝 7: 시나리오 브레인스토밍과 우선순위 결정 = 91 3.2.8 스텝 8: 아키텍처 접근방법 분석 = 99 3.2.9 스텝 9: 결과 프리젠테이션 = 100 3.3 ATAM의 단계 = 103 3.3.1 0단계 활동 = 103 3.3.2 1단계 활동 = 107 3.3.3 2단계 활동 = 108 3.3.4 3단계 활동 = 111 3.4 더 읽을거리 = 115 3.5 생각해볼 문제 = 116 4장 전장통제 시스템 - ATAM을 적용한 첫 사례연구 4.1 준비 = 118 4.2 1단계 = 119 4.2.1 스텝 1: ATAM 프리젠테이션 = 119 4.2.2 스텝 2: 비즈니스 동인 프리젠테이션 = 119 4.2.3 스텝 3: 아키텍처 프리젠테이션 = 119 4.2.4 스텝 4: 아키텍처 접근방법 식별 = 120 4.2.5 스텝 5: 품질속성 유틸리티 트리 작성 = 122 4.2.6 스텝 6: 아키텍처 접근방법 분석 = 123 4.3 2단계 = 130 4.3.1 스텝 7: 시나리오 브레인스토밍과 우선순위 결정 = 130 4.3.2 스텝 8: 아키텍처 접근방법 분석 = 131 4.3.3 스텝 9: 결과 프리젠테이션 = 132 4.4 BCS 평가의 결과 = 133 4.4.1 문서화 = 133 4.4.2 요구사항 = 135 4.4.3 민감점과 절충점 = 135 4.4.4 아키텍처 위험요소 = 136 4.5 정리 = 136 4.6 생각해볼 문제 = 137 5장 품질속성 이해 5.1 품질속성 특징화 = 140 5.1.1 성능 = 141 5.1.2 가용성 = 145 5.1.3 변경용이성 = 148 5.1.4 품질속성 특징화 질문 = 150 5.2 ATAM에서의 품질속성 특징화 사용 = 151 5.3 속성 기반 아키텍처 스타일 = 154 5.4 정리 = 155 5.5 더 읽을거리 = 156 5.6 생각해볼 문제 = 156 6장 ATAM 적용 사례연구 6.1 배경 = 158 6.2 0단계: 제휴와 준비 = 159 6.2.1 0단계, 스텝 1: ATAM 프리젠테이션 = 160 6.2.2 0단계, 스텝 2: 후보 시스템 설명 = 162 6.2.3 0단계, 스텝 3: ATAM의 진행 여부 결정 = 164 6.2.4 0단계, 스텝 4: 업무내용 협의 = 165 6.2.5 0단계, 스텝 5: 핵심 평가팀 구성 = 167 6.2.6 0단계, 스텝 6: 평가팀 착수회의 개최 = 170 6.2.7 0단계, 스텝 7: 1단계 준비 = 172 6.2.8 0단계, 스텝 8: 아키텍처 검토 = 177 6.3 1단계: 초기평가 = 178 6.3.1 1단계, 스텝 1: ATAM 프리젠테이션 = 179 6.3.2 1단계, 스텝 2: 비즈니스 동인 프리젠테이션 = 182 6.3.3 1단계, 스텝 3: 아키텍처 프리젠테이션 = 187 6.3.4 1단계, 스텝 4: 아키텍처 접근방법 식별 = 192 6.3.5 1단계, 스텝 5: 품질속성 유틸리티 트리 작성 = 194 6.3.6 1단계, 스텝 6: 아키텍처 접근방법 분석 = 203 6.4 1단계와 2단계 사이의 공백기간 = 214 6.5 2단계: 평가 완성 = 214 6.5.1 2단계, 스텝 0: 2단계 준비 = 215 6.5.2 2단계, 스텝 1∼6 = 217 6.5.3 2단계, 스텝 7: 시나리오 브레인스토밍과 우선순위 결정 = 218 6.5.4 2단계, 스텝 8: 아키텍처 접근방법 분석 = 226 6.5.5 2단계, 스텝 9: 결과 프리젠테이션 = 229 6.6 3단계: 후속조치 = 232 6.6.1 3단계, 스텝 1: 최종보고서 작성 = 233 6.6.2 3단계, 스텝 2: 사후 개선회의 개최 = 234 6.6.3 3단계, 스텝 3: 포트폴리오 구축과 산출물 저장소 갱신 = 237 6.7 더 읽을거리 = 239 6.8 생각해볼 문제 = 240 7장 SAAM을 이용한 예제 아키텍처 평가 7.1 SAAM 개요 = 242 7.1.1 SAAM 평가를 위한 입력물 = 242 7.1.2 SAAM 평가의 결과물 = 243 7.2 SAAM 평가의 스텝 = 244 7.2.1 스텝 1: 시나리오 개발 = 244 7.2.2 스텝 2: 아키텍처 설명 = 247 7.2.3 스텝 3: 시나리오 분류와 우선순위 결정 = 247 7.2.4 스텝 4: 간접 시나리오의 개별적인 평가 = 248 7.2.5 스텝 5: 시나리오 상호작용 평가 = 249 7.2.6 스텝 6: 평가 총괄 정리 = 250 7.3 SAAM 의제 예시 = 251 7.4 SAAM 사례연구 = 252 7.4.1 ATAT 시스템 개요 = 252 7.4.2 스텝 1: 시나리오 개발, 첫 번째 반복 = 253 7.4.3 스텝 2: 아키텍처 설명, 첫 번째 반복 = 255 7.4.4 스텝 1: 시나리오 개발, 두 번째 반복 = 256 7.4.5 스텝 2: 아키텍처 설명, 두 번째 반복 = 257 7.4.6 스텝 3: 시나리오 분류와 우선순위 결정 = 259 7.4.7 스텝 4: 간접 시나리오의 개별적인 평가 = 261 7.4.8 스텝 5: 시나리오 상호작용 확인 = 264 7.4.9 스텝 6: 평가 총괄 정리 - 결과와 권고사항 = 265 7.5 정리 = 267 7.6 더 읽을거리 = 268 7.7 생각해볼 문제 = 268 8장 ARID - 부분적 아키텍처 평가방법 8.1 능동적 설계검토 = 270 8.2 ARID: ARD/ATAM 하이브리드 = 273 8.3 ARID의 스텝 = 274 8.3.1 1단계: 예행연습 = 274 8.3.2 2단계: 검토 = 275 8.4 ARID를 적용한 사례연구 = 277 8.4.1 스텝의 수행 = 277 8.4.2 활동 결과 = 279 8.5 정리 = 281 8.6 더 읽을거리 = 281 8.7 생각해볼 문제 = 281 9장 소프트웨어 아키텍처 평가방법 비교 9.1 질의기법 = 285 9.1.1 설문지와 체크리스트 = 287 9.1.2 시나리오와 시나리오 기반 방법 = 289 9.2 측정기법 = 291 9.2.1 측정지표 = 292 9.2.2 시뮬레이션, 프로토타입, 실험 = 293 9.2.3 비율단조 분석 = 293 9.2.4 자동화 도구와 아키텍처 설명 언어 = 294 9.3 하이브리드 기법 = 295 9.3.1 소프트웨어 성능 엔지니어링 = 295 9.3.2 ATAM = 296 9.4 정리 = 299 9.5 더 읽을거리 = 301 9.6 생각해볼 문제 = 301 10장 조직 차원에서 아키텍처 평가역량의 증대 10.1 조직적인 합의 구축 = 304 10.2 평가자 후보군의 확대 = 304 10.3 조직 차원 기억 수립 = 306 10.3.1 비용과 이득 데이터 = 306 10.3.2 평가방법 지침 = 309 10.3.3 재사용 산출물 = 311 10.4 정리 = 313 10.5 생각해볼 문제 = 313 11장 결론 11.1 이제 준비완료! = 315 11.2 앞서 살펴본 방법 = 316 11.3 아키텍처를 평가해야 하는 이유 = 317 11.4 ATAM의 효과 = 322 11.5 마치면서 = 324 부록 A 속성 기반 아키텍처 스타일의 사례 A.1 문제 서술 = 325 A.2 자극/응답 = 326 A.3 아키텍처 스타일 = 326 A.4 분석 = 327 A.4.1 추론 = 327 A.4.2 우선순위 지정 = 328 A.4.3 우선순위 반전 = 329 A.4.4 중단시간 = 329 A.5 더 읽을거리 = 330 참고문헌 = 331 찾아보기 = 337
