책 소개
아키텍처 평가를 수행하는 데 유용한 세 가지 최신 평가방법에 대한 실질적인 지침을 제공하는 책으로서, 실무자에게 유용할 뿐만 아니라 아키텍처 평가 발전의 기반으로도 그 가치를 인정받을 것이다. - 리치 힐리어드, 콘센트캐시 주식회사 CTO 성공적인 제품의 개발과 발전은 올바른 아키텍처를 선택하느냐에 달렸다. 아키텍처 선택이 이렇게 중요하다는 사실을 안다면 아키텍처를 제대로 파악하거나 평가해야겠다는 생각이 절로 들 것이다. - 알렉산더 랜, 노키아의 소프트웨어 아키텍처 수석 과학자 소프트웨어 엔지니어의 책장에 꼭 있어야 할 필독서 - 조 마란자노, 前 벨연구소 소프트웨어 기술 센터장 이 책에서는 아키텍처 설계 의사결정과 그 결과인 소프트웨어 자산 간에 명확하게 파악된 연결관계를 그려내기 위해 소프트웨어 아키텍처 평가방법과 이를 실제 적용한 사례를 설명한다. 이 방법은 아키텍처 평가에 개발 일정(대개 며칠 이내)을 좀 더 늘리거나 비용을 추가하는 것만으로도 실제로 위험을 감소시킬 수 있다는 사실을 보여준다. 또한 아키텍처 평가에 대한 개념적인 배경 소개와 많은 정부기관과 업계에서 실제 수행됐던 내용을 기반으로 한 단계적 가이드도 제공한다. 특히 다음 세 가지 주요 평가방법을 설명한다. ■ 아키텍처 트레이드오프 분석방법 (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장에 있는 사례연구는 팀에서 시범으로 평가를 수행하는 데 참조 자료로 사용할 수 있다. ★ 이 책에 쏟아진 찬사 ★ 복잡한 소프트웨어나 시스템 아키텍처는 변경하는 데 고비용이 소요될 수 있는 어려운 의사결정의 총체다. 성공적인 제품의 개발과 발전은 올바른 아키텍처를 선택하느냐에 달렸다. 아키텍처 선택이 이렇게 중요하다는 사실을 안다면 아키텍처를 제대로 파악하거나 평가해야겠다는 생각이 절로 들 것이다. 저자들은 소프트웨어 아키텍처와 소프트웨어 아키텍처 평가에 대한 전문가들이다. 그들의 풍부한 아이디어와 경험을 잘 정리한 이 책을 통해 아키텍처 평가에 접근할 수 있다. 복잡한 시스템이나 소프트웨어 개발에 참여하는 사람이라면 누구나 실제 아키텍처 평가를 수립하고 향상하는 데 필요한 매우 귀중한 가이드를 이 책에서 찾을 수 있을 것이다. - 알렉산더 랜, 노키아의 소프트웨어 아키텍처 수석 과학자 소프트웨어 엔지니어의 책장에 꼭 있어야 할 필독서다. 이 책은 소프트웨어 아키텍처를 평가하는 절차에 대해 잘 정리된 가이드다. 저자들은 소프트웨어 개발 생명주기의 표준에 아키텍처 평가와 검토를 포함해야 한다고 주장한다. 이 책은 확장용이성, 이식용이성, 신뢰성 같은 중요한 아키텍처 특성을 분석하는 새롭고 혁신적인 방법을 소개한다. 이와 같은 아키텍처 평가방법이 훌륭한 소프트웨어 시스템을 만드는 데 새로운 엔지니어링 초석이 되리라 믿는다. - 조 마란자노, AT&T 벨연구소의 소프트웨어 아키텍처 펠로우(1990), 전 벨연구소 소프트웨어 기술 센터장 제품을 빠르고 저렴하게 개발하면서도 고객을 만족시킬 수 있는 내가 아는 유일한 방법은 경험과 팀워크다. 저자들의 첫 번째 책인 『소프트웨어 아키텍처: 이론과 실제』에서 폴과 릭, 베스는 내가 쌓은 경험을 이론적으로 설명할 수 있도록 도와줬다. 저자들의 귀중한 경험과 사례연구를 통해 나는 시스템 설계와 소프트웨어 아키텍처를 진행하는 방법을 바꿀 수 있었다. 마크도 참여한 이 두 번째 책은 내가 아키텍처에 만족하기 전에 살펴보고자 하는 부분까지도 포함…
목차펼치기접기
1장 소프트웨어 아키텍처 1.1 이해관계자 간 의사소통 수단으로서의 아키텍처 1.1.1 | 아키텍처와 이해관계자에게 미치는 영향 1.1.2 | 아키텍처 뷰 1.1.3 | 아키텍처 설명 언어 1.2 초기 설계 의사결정에 대한 방향선언으로서의 아키텍처 1.2.1 | 아키텍처 스타일 1.3 재사용가능하고 이전할 수 있는, 시스템 추상화로서의 아키텍처 1.4 정리 1.5 더 읽을거리 1.6 생각해볼 문제 2장 소프트웨어 아키텍처 평가 2.1 아키텍처 평가 이유 2.2 아키텍처 평가 시점 2.3 아키텍처 평가 참여자 2.4 아키텍처 평가의 예상 결과 2.5 아키텍처 평가대상 품질속성 2.6 품질속성 분석의 모호성 2.7 아키텍처 평가의 결과물 2.7.1 | ATAM, SAAM, ARID의 결과물 2.7.2 | ATAM만의 결과물 2.8 아키텍처 평가 수행의 이점과 비용 2.9 더 읽을거리 2.10 생각해볼 문제 3장 ATAM - 아키텍처 평가방법 3.1 ATAM 스텝의 요약 3.2 ATAM 스텝 상세 설명 3.2.1 | 스텝 1: ATAM 프리젠테이션 3.2.2 | 스텝 2: 비즈니스 동인 프리젠테이션 3.2.3 | 스텝 3: 아키텍처 프리젠테이션 3.2.4 | 스텝 4: 아키텍처 접근방법 식별 3.2.5 | 스텝 5: 품질속성 유틸리티 트리 작성 3.2.6 | 스텝 6: 아키텍처 접근방법 분석 3.2.7 | 스텝 7: 시나리오 브레인스토밍과 우선순위 결정 3.2.8 | 스텝 8: 아키텍처 접근방법 분석 3.2.9 | 스텝 9: 결과 프리젠테이션 3.3 ATAM의 단계 3.3.1 | 0단계 활동 3.3.2 | 1단계 활동 3.3.3 | 2단계 활동 3.3.4 | 3단계 활동 3.4 더 읽을거리 3.5 생각해볼 문제 4장 전장통제 시스템 - ATAM을 적용한 첫 사례연구 4.1 준비 4.2 1단계 4.2.1 | 스텝 1: ATAM 프리젠테이션 4.2.2 | 스텝 2: 비즈니스 동인 프리젠테이션 4.2.3 | 스텝 3: 아키텍처 프리젠테이션 4.2.4 | 스텝 4: 아키텍처 접근방법 식별 4.2.5 | 스텝 5: 품질속성 유틸리티 트리 작성 4.2.6 | 스텝 6: 아키텍처 접근방법 분석 4.3 2단계 4.3.1 | 스텝 7: 시나리오 브레인스토밍과 우선순위 결정 4.3.2 | 스텝 8: 아키텍처 접근방법 분석 4.3.3 | 스텝 9: 결과 프리젠테이션 4.4 BCS 평가의 결과 4.4.1 | 문서화 4.4.2 | 요구사항 4.4.3 | 민감점과 절충점 4.4.4 | 아키텍처 위험요소 4.5 정리 4.6 생각해볼 문제 5장 품질속성 이해 5.1 품질속성 특징화 5.1.1 | 성능 5.1.2 | 가용성 5.1.3 | 변경용이성 5.1.4 | 품질속성 특징화 질문 5.2 ATAM에서의 품질속성 특징화 사용 5.3 속성 기반 아키텍처 스타일 5.4 정리 5.5 더 읽을거리 5.6 생각해볼 문제 6장 ATAM 적용 사례연구 6.1 배경 6.2 0단계: 제휴와 준비 6.2.1 | 0단계, 스텝 1: ATAM 프리젠테이션 6.2.2 | 0단계, 스텝 2: 후보 시스템 설명 6.2.3 | 0단계, 스텝 3: ATAM의 진행 여부 결정 6.2.4 | 0단계, 스텝 4: 업무내용 협의 6.2.5 | 0단계, 스텝 5: 핵심 평가팀 구성 6.2.6 | 0단계, 스텝 6: 평가팀 착수회의 개최 6.2.7 | 0단계, 스텝 7: 1단계 준비 6.2.8 | 0단계, 스텝 8: 아키텍처 검토 6.3 1단계: 초기평가 6.3.1 | 1단계, 스텝 1: ATAM 프리젠테이션 6.3.2 | 1단계, 스텝 2: 비즈니스 동인 프리젠테이션 6.3.3 | 1단계, 스텝 3: 아키텍처 프리젠테이션 6.3.4 | 1단계, 스텝 4: 아키텍처 접근방법 식별 6.3.5 | 1단계, 스텝 5: 품질속성 유틸리티 트리 작성 6.3.6 | 1단계, 스텝 6: 아키텍처 접근방법 분석 6.4 1단계와 2단계 사이의 공백기간 6.5 2단계: 평가 완성 6.5.1 | 2단계, 스텝 0: 2단계 준비 6.5.2 | 2단계, 스텝 1~6 6.5.3 | 2단계, 스텝 7: 시나리오 브레인스토밍과 우선순위 결정 6.5.4 | 2단계, 스텝 8: 아키텍처 접근방법 분석 6.5.5 | 2단계, 스텝 9: 결과 프리젠테이션 6.6 3단계: 후속조치 6.6.1 | 3단계, 스텝 1: 최종보고서 작성 6.6.2 | 3단계, 스텝 2: 사후 개선회의 개최 6.6.3 | 3단계, 스텝 3: 포트폴리오 구축과 산출물 저장소 갱신 6.7 더 읽을거리 6.8 생각해볼 문제 7장 SAAM을 이용한 예제 아키텍처 평가 7.1 SAAM 개요 7.1.1 | SAAM 평가를 위한 입력물 7.1.2 | SAAM 평가의 결과물 7.2 SAAM 평가의 스텝 7.2.1 | 스텝 1: 시나리오 개발 7.2.2 | 스텝 2: 아키텍처 설명 7.2.3 | 스텝 3: 시나리오 분류와 우선순위 결정 7.2.4 | 스텝 4: 간접 시나리오의 개별적인 평가 7.2.5 | 스텝 5: 시나리오 상호작용 평가 7.2.6 | 스텝 6: 평가 총괄 정리 7.3 SAAM 의제 예시 7.4 SAAM 사례연구 7.4.1 | ATAT 시스템 개요 7.4.2 | 스텝 1: 시나리오 개발, 첫 번째 반복 7.4.3 | 스텝 2: 아키텍처 설명, 첫 번째 반복 7.4.4 | 스텝 1: 시나리오 개발, 두 번째 반복 7.4.5 | 스텝 2: 아키텍처 설명, 두 번째 반복 7.4.6 | 스텝 3: 시나리오 분류와 우선순위 결정 7.4.7 | 스텝 4: 간접 시나리오의 개별적인 평가 7.4.8 | 스텝 5: 시나리오 상호작용 확인 7.4.9 | 스텝 6: 평가 총괄 정리 - 결과와 권고사항 7.5 정리 7.6 더 읽을거리 7.7 생각해볼 문제 8장 ARID - 부분적 아키텍처 평가방법 8.1 능동적 설계검토 8.2 ARID: ARD/ATAM 하이브리드 8.3 ARID의 스텝 8.3.1 | 1단계: 예행연습 8.3.2 | 2단계: 검토 8.4 ARID를 적용한 사례연구 8.4.1 | 스텝의 수행 8.4.2 | 활동 결과 8.5 정리 8.6 더 읽을거리 8.7 생각해볼 문제 9장 소프트웨어 아키텍처 평가방법 비교 9.1 질의기법 9.1.1 | 설문지와 체크리스트 9.1.2 | 시나리오와 시나리오 기반 방법 9.2 측정기법 9.2.1 | 측정지표 9.2.2 | 시뮬레이션, 프로토타입, 실험 9.2.3 | 비율단조 분석 9.2.4 | 자동화 도구와 아키텍처 설명 언어 9.3 하이브리드 기법 9.3.1 | 소프트웨어 성능 엔지니어링 9.3.2 | ATAM 9.4 정리 9.5 더 읽을거리 9.6 생각해볼 문제 10장 조직 차원에서 아키텍처 평가역량의 증대 10.1 조직적인 합의 구축 10.2 평가자 후보군의 확대 10.3 조직 차원 기억 수립 10.3.1 | 비용과 이득 데이터 10.3.2 | 평가방법 지침 10.3.3 | 재사용 산출물 10.4 정리 10.5 생각해볼 문제 11장 결론 11.1 이제 준비완료! 11.2 앞서 살펴본 방법 11.3 아키텍처를 평가해야 하는 이유 11.4 ATAM의 효과 11.5 마치면서 부록 A 속성 기반 아키텍처 스타일의 사례 A.1 문제 서술 A.2…
출처: 국립중앙도서관 서지정보
리뷰 남기기
로그인하면 리뷰를 남길 수 있어요.
리뷰 0개
아직 리뷰가 없어요.