장바구니 담기 close

장바구니에 상품을 담았습니다.

장바구니로 계속쇼핑하기
소프트웨어 아키텍처 이론과 실제
미리보기

소프트웨어 아키텍처 이론과 실제

  • 렌 베스
  • |
  • 에이콘출판
  • |
  • 2015-08-28 출간
  • |
  • 648페이지
  • |
  • 188 X 250 X 32 mm /1265g
  • |
  • ISBN 9788960777507
판매가

45,000원

즉시할인가

40,500 원

배송비

무료배송

(제주/도서산간 배송 추가비용:3,000원)

추가상품
상품선택
독서대 7,900원 독서대 선택안함 0원
수량
+ -
총주문금액
40,500원
장바구니 구매하기

※ 스프링제본 상품은 반품/교환/환불이 불가능하므로 신중하게 선택하여 주시기 바랍니다.

북스크린영상으로 만나보는 한 권의 책 이야기

출판사서평

★ 요약 ★

소프트웨어 아키텍트가 되고자 하는 사람과 이미 소프트웨어 아키텍트로서 역할을 수행 중인 사람 모두가 읽어야 하는 소프트웨어 아키텍처 교과서다. 2판이 출간된 이후로 10여 년 동안 소프트웨어 분야의 발전을 반영하여 이번 3판은 전면 개정되었다. 소프트웨어 아키텍처의 이론적 기반을 좀 더 견고하게 설명하고 있으며, 실무 적용 사례는 좀 더 이해하기 쉽게 제시했다. 대규모 시스템의 소프트웨어 아키텍처 설계와 분석은 물론이고, 특별히 애자일 방식의 시스템을 개발할 때 소프트웨어 아키텍처의 역할과 적용에 대해서도 명확하게 설명한다.

★ 이 책에서 다루는 내용 ★

■ 소프트웨어 아키텍처 컨텍스트: 기술적, 프로젝트, 비즈니스, 전문성
■ 아키텍처 역량: 개인과 조직에게 아키텍처가 의미하는 것
■ 비즈니스 목표의 근원과 이것이 아키텍처에 미치는 영향
■ 아키텍처적으로 중요한 요구와 이들을 결정하는 방법
■ 라이프사이클에서의 아키텍처: 설계 철학으로서 생성과 테스트, 구현 단계에서의 아키텍처 준수, 아키텍처와 테스팅, 아키텍처와 애자일 개발
■ 아키텍처와 현재 기술: 클라우드, 소셜 네트워킹, 최종 사용자 디바이스

★ 이 책의 대상 독자 ★

소프트웨어 공학에 지식과 경험이 있는 소프트웨어 전문가나 학생을 대상으로 한다.

■ 아키텍처에 대한 기술적인 배경과 함께 거기에 작용하는 업무적, 조직적 상황과 요구사항, 영향력에 대해 이해하고자 하는 소프트웨어 공학 교육생
■ 소프트웨어 아키텍처를 통해 시스템 구축 업무를 좀더 효과적으로 감독하고 조직을 개선시킬 수 있는 방법을 배우고자 하는 기술 관리자들
■ 학부나 대학원의 소프트웨어 공학 과정에서 이 책을 학습 자료로 활용하고자 하는 전산과나 소프트웨어 공학과 학생

★ 이 책의 구성 ★

이 책은 5개 부로 구성된다.
1부는 아키텍처와 아키텍처를 들여다보는 다양한 컨텍스트적인 렌즈에 대해 개관한다. 이들 컨텍스트는 다음과 같다.
? 기술적(technical): 시스템에서 소프트웨어 아키텍처의 기술적인 역할은 무엇인가?
? 프로젝트 라이프사이클(project lifecycle): 소프트웨어 아키텍처는 소프트웨어 개발 라이프사이클의 어떤 단계와 관련을 갖는가?
? 비즈니스(business): 소프트웨어 아키텍처가 조직의 비즈니스 환경에 어떤 영향을 미치는가?
? 전문성(professional): 조직이나 개발 프로젝트에서 소프트웨어 아키텍트의 역할은 무엇인가?
2부에서는 기술적인 배경에 집중한다. 2부는 결정이 이루어지는 방법을 설명한다. 결정은 시스템의 바람직한 품질 속성을 기반으로 한다. 5장에서 11장까지는 7개의 품질 속성과 이들을 달성하는 데 사용되는 기법을 설명한다. 7개의 품질 속성은 가용성, 상호운영성, 변경용 이성, 성능, 보안, 테스트 용이성, 사용편의성이다. 12장은 7개 품질 속성에 다른 품질 속성을 추가하는 방법을 설명하며, 13장은 패턴과 전술을 논의하고, 14장은 가능한 다양한 유형의 모델링과 분석을 논의한다.
3부는 소프트웨어 아키텍처가 라이프사이클의 다른 부분과 관련된 사항을 다룬다. 특별히 애자일 프로젝트에서 아키텍처가 어떻게 사용되는지를 설명한다. 라이프사이클의 다른 관점 즉, 요구와 설계, 구현 및 테스팅, 재구성과 순응, 평가를 개별적으로 논의한다.
4부에서는 경제적인 관점과 조직적인 관점, 그리고 일련의 유사한 시스템을 구축하는 관점에서의 아키텍팅 작업을 다룬다.
5부에서는 몇 가지 뜨고 있는 기술과 이들 기술과 아키텍처의 관련성에 대해 논의한다.

목차

1부 개요
1장. 소프트웨어 아키텍처의 의미
__1.1 무엇이 소프트웨어 아키텍처이고, 무엇이 아닌가?
__1.2 아키텍처 구조와 뷰
__1.3 아키텍처 패턴
__1.4 좋은 아키텍처를 만드는 법
__1.5 정리
__1.6 참고 문헌
__1.7 생각해볼 문제

2장. 소프트웨어 아키텍처가 중요한 이유
__2.1 시스템의 품질 속성 억제 또는 가능
__2.2 변경 근거와 관리
__2.3 시스템 품질 예측
__2.4 이해당사자 의사소통 향상
__2.5 초기 설계 결정 수용
__2.6 구현 제약사항 정의
__2.7 조직 구조 영향
__2.8 발전적 프로토타이핑
__2.9 비용과 일정 산정 향상
__2.10 이전 가능한 재사용모델 공급
__2.11 독립적으로 개발된 컴포넌트 통합 허용
__2.12 설계 선택 대상 제한
__2.13 훈련 기초 제공
__2.14 정리
__2.15 참고 문헌
__2.16 생각해볼 문제

3장. 소프트웨어 아키텍처 컨텍스트
__3.1 기술적 컨텍스트에서의 아키텍처
__3.2 프로젝트 라이프사이클 컨텍스트에서의 아키텍처
__3.3 비즈니스 컨텍스트에서의 아키텍처
__3.4 전문성 컨텍스트에서의 아키텍처
__3.5 이해당사자
__3.6 아키텍처는 어떻게 영향을 받는가
__3.7 아키텍처가 무엇에게 영향을 주는가
__3.8 정리
__3.9 참고 문헌
__3.10 생각해볼 문제

2부 품질 속성
4장. 품질 속성의 이해
__4.1 아키텍처와 요구
__4.2 기능성
__4.3 품질 속성 고려사항
__4.4 품질 속성 요구 명세
__4.5 전술을 통한 품질 속성 달성
__4.6 품질 설계 결정 가이드
__4.7 정리
__4.8 참고 문헌
__4.9 생각해볼 문제

5장. 가용성
__5.1 가용성 일반 시나리오
__5.2 가용성 전술
__5.3 가용성 설계 체크리스트
__5.4 정리
__5.5 참고 문헌
__5.6 생각해볼 문제

6장. 상호운영성
__6.1 상호운영성 일반 시나리오
__6.2 상호운영성 전술
__6.3 상호운영성 설계 체크리스트
__6.4 정리
__6.5 참고 문헌
__6.6 생각해볼 문제

7장. 변경용이성
__7.1 변경용이성 일반 시나리오
__7.2 변경용이성 전술
__7.3 변경용이성 설계 체크리스트
__7.4 정리
__7.5 참고 문헌
__7.6 생각해볼 문제

8장. 성능
__8.1 성능 일반 시나리오
__8.2 성능 전술
__8.3 성능 설계 체크리스트
__8.4 정리
__8.5 참고 문헌
__8.6 생각해볼 문제

9장. 보안
__9.1 보안 일반 시나리오
__9.2 보안 전술
__9.3 보안 설계 체크리스트
__9.4 정리
__9.5 참고 문헌
__9.6 생각해볼 문제

10장. 테스트 용이성
__10.1 테스트 용이성 일반 시나리오
__10.2 테스트 용이성 전술
__10.3 테스트 용이성 설계 체크리스트
__10.4 정리
__10.5 참고 문헌
__10.6 생각해볼 문제

11장. 사용편의성
__11.1 사용편의성 일반 시나리오
__11.2 사용편의성 전술
__11.3 사용편의성 설계 체크리스트
__11.4 정리
__11.5 참고 문헌
__11.6 생각해볼 문제

12장. 기타 품질 속성
__12.1 기타 중요한 품질 속성
__12.2 기타 품질 속성 카테고리
__12.3 소프트웨어 품질 속성과 시스템 품질 속성
__12.4 품질 속성 표준 목록 사용
__12.5 ‘-성’ 다루기: 새로운 품질 속성 도입
__12.6 참고 문헌
__12.7 생각해볼 문제

13장. 아키텍처 전술과 패턴
__13.1 아키텍처 패턴
__13.2 패턴 목록 개요
__13.3 전술과 패턴 사이의 관계
__13.4 전술 종합 사용
__13.5 정리
__13.6 참고 문헌
__13.7 생각해볼 문제

14장. 품질 속성 모델링과 분석
__14.1 품질 속성 분석을 가능하게 하는 아키텍처 모델링
__14.2 품질 속성 체크리스트
__14.3 사고 실험과 대략 분석
__14.4 실험, 시뮬레이션 및 프로토타입
__14.5 라이프사이클 단계에서의 분석
__14.6 정리
__14.7 참고 문헌
__14.8 생각해볼 문제

3부 라이프사이클에서의 아키텍처
15장 애자일 프로젝트에서의 아키텍처
__15.1 어느 정도의 아키텍처일까?
__15.2 애자일과 아키텍처 방법론
__15.3 애자일 아키텍팅의 간단한 사례
__15.4 애자일 아키텍트 가이드라인
__15.5 정리
__15.6 참고 문헌
__15.7 생각해볼 문제

16장 아키텍처와 요구
__16.1 요구 문서로부터 ASR 수집
__16.2 이해당사자 인터뷰로 ASR 수집
__16.3 비즈니스 목표 이해에 의한 ASR 수집
__16.4 유틸리티 트리 ASR 수집
__16.5 방법론 결합
__16.6 정리
__16.7 참고 문헌
__16.8 생각해볼 문제

17장 아키텍처 설계
__17.1 설계 전략
__17.2 속성 주도 설계 방법론
__17.3 ADD 단계
__17.4 정리
__17.5 참고 문헌
__17.6 생각해볼 문제

18장 소프트웨어 아키텍처 문서화
__18.1 아키텍처 문서 사용과 독자
__18.2 아키텍처 문서 표기법
__18.3 뷰
__18.4 뷰 선택
__18.5 뷰 결합
__18.6 문서 패키지 구축
__18.7 행위 문서화
__18.8 아키텍처 문서와 품질 속성
__18.9 문서화보다 빨리 변경되는 아키텍처의 문서화
__18.10 애자일 개발 프로젝트에서 아키텍처 문서화
__18.11 정리
__18.12 참고 문헌
__18.13 생각해볼 문제

19장 아키텍처, 구현과 테스팅
__19.1 아키텍처와 구현
__19.2 아키텍처와 테스팅
__19.3 정리
__19.4 참고 문헌
__19.5 생각해볼 문제

20장 아키텍처 재구성과 순응
__20.1 아키텍처 재구성 프로세스
__20.2 원시 뷰 추출
__20.3 데이터베이스 구축
__20.4 뷰 융합
__20.5 아키텍처 분석: 위반 사항 찾기
__20.6 가이드라인
__20.7 정리
__20.8 참고 문헌
__20.9 생각해볼 문제

21장 아키텍처 평가
__21.1 평가 요인
__21.2 아키텍처 트레이드오프 분석 방법론
__21.3 경량 아키텍처 평가
__21.4 정리
__21.5 참고 문헌
__21.6 생각해볼 문제

22장 관리와 거버넌스
__22.1 계획
__22.2 조직
__22.3 구현
__22.4 측정
__22.5 거버넌스
__22.6 정리
__22.7 참고 문헌
__22.8 생각해볼 문제

4부 아키텍처와 비즈니스
23장 아키텍처 경제적 분석
__23.1 의사 결정 배경
__23.2 경제적 분석 기초
__23.3 이론에서 실제로: CBAM
__23.4 사례 연구
__23.5 정리
__23.6 참고 문헌
__23.7 생각해볼 문제

24장 아키텍처 역량
__24.1 개인 역량: 아키텍트의 의무, 기능, 지식
__24.2 소프트웨어 아키텍처 조직 역량
__24.3 정리
__24.4 참고 문헌
__24.5 생각해볼 문제

25장 아키텍처와 소프트웨어 제품 라인
__25.1 제품 라인 가변성 사례
__25.2 소프트웨어 제품 라인 작동 원리
__25.3 제품 라인 범위
__25.4 가변성 품질 속성
__25.5 제품 라인 아키텍처의 역할
__25.6 가변 메커니즘
__25.7 제품 라인 아키텍처 평가
__25.8 주요 소프트웨어 제품 라인 이슈
__25.9 정리
__25.10 참고 문헌
__25.11 생각해볼 문제

5부 멋진 신세계
26장 클라우드 아키텍처
__26.1 기본적인 클라우드 정의
__26.2 서비스 모델과 배포 선택
__26.3 경제적 타당성
__26.4 기반 메커니즘
__26.5 기술의 예
__26.6 클라우드 환경에서의 아키텍팅
__26.7 정리
__26.8 참고 문헌
__26.9 생각해볼 문제

27장 엣지 아키텍처
__27.1 엣지 지배적 시스템의 생태계
__27.2 소프트웨어 개발 라이프사이클 변화
__27.3 아키텍처 의미
__27.4 메트로폴리스 모델 의미
__27.5 정리
__27.6 참고 문헌
__27.7 생각해볼 문제

28장 에필로그

저자소개

저자 렌 베스(Len Bass)는 NICTA(National ICT Australia Ltd) 사의 수석 연구원이다. 2011년에 NICTA에 입사하기 전에 카네기 멜론(Carnegie Mellon) 대학의 SEI(Software Engineering Institute)에서 25년간 재직했다. 『Software Architecture: Views and Beyond, Second edition』(Addison-Wesley, 2011)을 포함하여 2권의 수상 경력을 보유한 책의 공동 저자이며, 컴퓨터 과학과 소프트웨어 공학에 관련된 다양한 주제에 관한 여러 권의 책과 다수의 논문이 있다. 과학 분석 시스템, 임베드 시스템과 정보 시스템과 같은 여러 도메인에서 소프트웨어 개발과 연구를 50년간 해왔다.

도서소개

『소프트웨어 아키텍처 이론과 실제』는 소프트웨어 아키텍트가 되고자 하는 사람과 이미 소프트웨어 아키텍트로서 역할을 수행 중인 사람 모두가 읽어야 하는 소프트웨어 아키텍처 교과서로 이번 3판은 전면 개정되었다. 소프트웨어 아키텍처의 이론적 기반을 좀 더 견고하게 설명하고 있으며, 실무 적용 사례는 좀 더 이해하기 쉽게 제시하고 있다.
추천포스트

교환 및 환불안내

도서교환 및 환불
  • ㆍ배송기간은 평일 기준 1~3일 정도 소요됩니다.(스프링 분철은 1일 정도 시간이 더 소요됩니다.)
  • ㆍ상품불량 및 오배송등의 이유로 반품하실 경우, 반품배송비는 무료입니다.
  • ㆍ고객님의 변심에 의한 반품,환불,교환시 택배비는 본인 부담입니다.
  • ㆍ상담원과의 상담없이 교환 및 반품으로 반송된 물품은 책임지지 않습니다.
  • ㆍ이미 발송된 상품의 취소 및 반품, 교환요청시 배송비가 발생할 수 있습니다.
  • ㆍ반품신청시 반송된 상품의 수령후 환불처리됩니다.(카드사 사정에 따라 카드취소는 시일이 3~5일이 소요될 수 있습니다.)
  • ㆍ주문하신 상품의 반품,교환은 상품수령일로 부터 7일이내에 신청하실 수 있습니다.
  • ㆍ상품이 훼손된 경우 반품 및 교환,환불이 불가능합니다.
  • ㆍ반품/교환시 고객님 귀책사유로 인해 수거가 지연될 경우에는 반품이 제한될 수 있습니다.
  • ㆍ스프링제본 상품은 교환 및 환불이 불가능 합니다.
  • ㆍ군부대(사서함) 및 해외배송은 불가능합니다.
  • ㆍ오후 3시 이후 상담원과 통화되지 않은 취소건에 대해서는 고객 반품비용이 발생할 수 있습니다.
반품안내
  • 마이페이지 > 나의상담 > 1 : 1 문의하기 게시판 또는 고객센터 1800-7327
교환/반품주소
  • 경기도 파주시 문발로 211 1층 / (주)북채널 / 전화 : 1800-7327
  • 택배안내 : CJ대한통운(1588-1255)
  • 고객님 변심으로 인한 교환 또는 반품시 왕복 배송비 5,000원을 부담하셔야 하며, 제품 불량 또는 오 배송시에는 전액을 당사에서부담 합니다.