• 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학론
• 대학교재 > 공학계열
• 대학교재 > 공학계열 > 컴퓨터공학

0/0 종합 1468위 | 2010/10 컴퓨터/IT 7위 | 현재 종합 1468위 | 현재 컴퓨터/IT 21위 | Top100 : 1주

반디앤루니스 리뷰

IT 프로젝트의 복잡성이 증가하면서 프로젝트 관리 역시 하나의 공학으로 자리잡아, 많은 경험과 체계적인 학습, 그리고 개인의 노력을 요하는 고도의 전문가 역할로 자리 잡고 있다. 이 책에서 이야기하는 아키텍트는 사용자 지향적인 사고로 소프트웨어를 기획하고, 이에 대한 전체적인 틀을 세울 수 있는 사람을 지칭한다. 저자는 가상의 아키텍트를 등장시켜, 아키텍트가 프로젝트의 작업흐름에 따라 어떠한 역할을 하는지를 보다 쉽게 보여준다. 이를 통해 독자는 아키텍트가 각 단계에서 어떤 노력을 해야 하는지, 다양한 난관을 어떻게 극복해 나가야 하는지에 대해 구체적으로 알수 있을 것이다.

출판사 리뷰

출판사 서평 개발자 정년 35세를 운운하는 시대에 더욱 절실한 존재, 아키텍트. 아키텍트는 누구이고, 어떤 일을 하는가? 아키텍트는 기술적 관점에서 시스템을 바라보고 설계와 구현 전체를 책임져, 개발팀을 이끄는 이를 뜻한다. 개발에 관한 기본 방침, 즉 아키텍처를 정하고 이를 바탕으로 프레임워크를 설계하고 구현을 총괄하는 것이 주 업무라 할 수 있다. 또한 복잡하게 얽힌 프로젝트 이해당사자 즉 사용자, 발주자, 개발자들 사이에서 각각의 요구를 기술적인 관점에서 비용, 개발 범위, 품질 그리고 일정의 균형을 맞춰 나... [... 개발자 정년 35세를 운운하는 시대에 더욱 절실한 존재, 아키텍트. 아키텍트는 누구이고, 어떤 일을 하는가? 아키텍트는 기술적 관점에서 시스템을 바라보고 설계와 구현 전체를 책임져, 개발팀을 이끄는 이를 뜻한다. 개발에 관한 기본 방침, 즉 아키텍처를 정하고 이를 바탕으로 프레임워크를 설계하고 구현을 총괄하는 것이 주 업무라 할 수 있다. 또한 복잡하게 얽힌 프로젝트 이해당사자 즉 사용자, 발주자, 개발자들 사이에서 각각의 요구를 기술적인 관점에서 비용, 개발 범위, 품질 그리고 일정의 균형을 맞춰 나... [ 출판사 서평 더보기 ] 개발자 정년 35세를 운운하는 시대에 더욱 절실한 존재, 아키텍트. 아키텍트는 누구이고, 어떤 일을 하는가? 아키텍트는 기술적 관점에서 시스템을 바라보고 설계와 구현 전체를 책임져, 개발팀을 이끄는 이를 뜻한다. 개발에 관한 기본 방침, 즉 아키텍처를 정하고 이를 바탕으로 프레임워크를 설계하고 구현을 총괄하는 것이 주 업무라 할 수 있다. 또한 복잡하게 얽힌 프로젝트 이해당사자 즉 사용자, 발주자, 개발자들 사이에서 각각의 요구를 기술적인 관점에서 비용, 개발 범위, 품질 그리고 일정의 균형을 맞춰 나가는 사람이라고도 할 수 있다. 이 책은 가상의 아키텍트를 등장시켜, 아키텍트가 프로젝트의 작업흐름에 따라 어떠한 역할을 하는지 쉽게 보여준다. 이를 통해 아키텍트가 어떻게 시스템 개발 프로젝트의 문제를 해결하고, 프로젝트 성공에 기여하는지에 대한 궁금증을 해소시킨다. 그동안 아키텍트가 뭘 하는지 대략 알지만 명확하게 파악되지 않았던 사람들에게 쉽고 현실감 있게 설명하는 아키텍트 소개서가 될 것이다. 이 책은 무언가를 창조해내는 것에 기쁨을 느끼는 개발자의 속성을 지적하고, 어느 정도 경력이 차면 관리자나 영업 전선으로 배치되는 현실과 다른 길이 있음을 제시해 준다. 진정 개발자가 원하는 것이 무엇인가 다시 한 번 생각하도록 해주는 것이다. 그리고 그 희망이 결코 현실과 동떨어져 있지 않음을 확인할 수 있도록 해준다.

목차
감수자의 글
머리말
1장. 개발자의 다음 단계
프로그래머의 소망
시스템 전체를 바라보는 재미
프로젝트에서 아키텍트의 역할
아키텍트와 다른 업무 담당자의 관계
아키텍트의 주요 업무
10년 후에도 기술자로 활약하기 위해
2장. 요구사항 정의에 참여
요구사항 정의에 대한 기술적 지원
아키텍트의 요구분석 단계 업무
사용자 중심의 명세 설계
플랫폼 선정의 현실
팀원을 고려하여 개발 계획을 세운다
아키텍트가 있다면 당연히 순조롭게 진행되는가?
3장. 아키텍처 설계
아키텍처는 초기에 설계한다
아키텍처는 요구사항에서 만들어진다
기술 문제를 정리하자
항상 누가 아키텍처 설계서를 읽을지 고려한다
아키텍처 설계서를 써 본다
앞으로 어떤 작업이 이루어질지를 그려낸다
개요를 확실히 이해해야 한다
기술 요소를 정확하게 설명한다
막히기 쉬운 부분은 상세하게 설명해 놓는다
의도를 전달하는 것이 중요하다
4장. 프레임워크를 준비한다
소프트웨어에 요구되는 품질
아키텍처를 프로젝트 팀에 침투시킨다
개발팀 킥 오프
아키텍트는 기술과 사람의 중개자
프레임워크를 준비하자
팀원들의 의견을 이끌어내다
적절한 리뷰로 설계를 제어한다
칼럼: 프레임워크로 편안하고 간단하게 개발한다
프레임워크는 아키텍처의 구체적인 실체
할리우드의 법칙
프로젝트의 프레임워크
프레임워크를 이용할 때의 장점과 단점
5장. 말썽 많은 프로젝트 되살리기
전화 벨소리
문제는 어디에 있는가?
문제는 아키텍처에도 있다
아키텍처에서 해결할 수 있는 부분을 확인한다
6장. 테스트를 즐기자
개발자와 테스트 담당자 사이의 깊은 골
빈틈없는 테스트로 품질을 향상시키는 것은 불가능하다
TDD로 공격적인 테스트를 한다
단위 테스트
테스트하기 쉬운 아키텍처
아키텍트의 도움이 필요한 테스트
다양한 테스트 방법을 이해하자
7장. 개발 현장 밖에서 활약한다
문제를 해결하기 위해 필요한 기술
기술로 이해할 수 없는 것들
비기술자가 기술적인 결정을 내린다
위험요소를 줄이기 위해
일의 영역을 넓혀 보자
어떤 시스템을 만들어야 하는가?
아키텍트에게 요구되는 것
기술을 몸에 익히기 위해
8장. 애자일 프로젝트의 아키텍트
뛰면서 생각한다
문서를 버리고 사람과 대화한다
사전 설계는 손해다
점진적인 설계
사전에 설계해야 하는 경우도 있다
프레임워크는 나중에 추출한다
Architectus Oryzus와 Architectus Reloadus
9장. 아키텍트가 되고 싶다!
해커와 아키텍트
아키텍트가 왜 돌파구인가?
비즈니스 애플리케이션 개발은 사회 활동
프로 개발자
맺음말
참고문헌
찾아보기