p.22
요구분석 담당자
무엇을 만들지가 잘못 정의되어 있으면 애써 개발한 시스템도 아무런 소용이 없다. 프로젝트의 성공을 위해서는 옳은 계획과 방법을 찾고, 그것을 제대로 수행해야 한다. 여기서 옳은
계획과 방법이 무엇인지 결정하는 것이 요구분석 담당자의 중요한 역할이다.
- 요구사항 담당자는 '무엇을, 어떤 계획과 방법으로 만드는 것이 옳은가'를 결정한다.
p.23
인프라 담당자
성능(performance, 정지시간(downtime), 백업 같이 시스템이 직접 수행하는 기능이라고 보기 어려운 구조적이고 관리적인 요구사항, 즉 비기능 요구사항을 수집해서 정리하고 이것을 만
족시키는 인프라를 구축하기 위해서 어떤 제품을 써야 할지도 결정한다.
- 인프라 담당자는 개발 환경과 운용 환경을 정비한다.
p.25
프로그래머
프로그래밍이야말로 시스템 개발의 근간이라 할 수 있다.
프로그래머는 아키텍트가 작성한 아키텍처 설계서와 프레임워크에 대해 피드백하면서, 아키텍트의 업무를 배울 수도 있다.
p.27
운용 담당자
시스템을 개발할 때 운용 담당자는 일상 업무가 안정적이고 효율적으로 이뤄지도록 해야 할 뿐 아니라, 장애 발생에 따른 대책 역시 수립해야 하는 것이다.
여러분이 프로그래머임에도 운용 업무에 대해 폭 넓게 인식하고 있다면, 시스템 설정을 변경하거나, 부팅과 재부팅을 쉽게 하고, 장애가 발생할 경우 원인을 쉽게 판단할 수 있도록 로
그를 적절하게 출력하는 등, 운용 목적에 맞게 시스템을 개발할 수 있을 것이다. 또한 시스템을 보는 시야가 넓어지므로 적용 기술 역시 다양해질 것이다.
- 운용 담당자는 매일매일 시스템을 안정적으로 가동하는 업무를 담당한다.
p.29
아키텍트의 주요 업무
1.개발에 쓰일 다양한 템플릿을 만드는 일 (시스템 개발의 중심은 설계와 프로그래밍)
용어나 개념의 이해는 개인에 따라 다르므로, 아키텍트가 템플릿을 정리해 제공한다.
2. 설계 지침 제공
사전에 설계와 구현 단계에서 개발자가 내려야 할 판단에 대한 지침을 제시한다. 예컨대 '비즈니스 로직 레이어는 무상태 세션빈(Stateless SessionBean) 으로 구현하고, 원격 메소드의
크기는 시스템 수준의 유스케이스(Use Cases) 단위로 한다. 클라이언트가 되는 웹 단의 컴포넌트는, Context나 Home 인터페이스를 캐시해 성능 향상을 도모한다. 리모트 호출에 따른 실
행 시 예외에 대해서 로그를 출력한다.
- 개발자마다 판단 기준이 다르지 않도록, 아키텍처로 지침을 제공한다.
아키텍처: 소프트웨어 전체에 영향을 미치는 여러 요소를 지침으로 정리한 것
아키텍트: 아키텍처를 결정하는 사람으로 소프트웨어 전체, 프로젝트 전체에 밀접하게 연관된 역할
프레임워크: 추상적인 지침인 아키텍처에 비해 더 실제적으로 개발자에게 도움이 되도록 구현해 제공하는 부분
아키텍트는 아키텍처와 프레임워크를 이용해서 기술 수준이나 경험이 제각각인 개발자들이 협조하여 일할 수 있도록 이끄는 역할을 한다.
- 추상적인 방침인 아키텍처의 핵심 기능 중 공통으로 이용할 수 있는 기능을 구현해 프레임워크로 제공한다.
p. 32
개발자로서 아키텍트
1. 아키텍트는 아키텍처와 프레임워크로 프로젝트를 이끄는 위치이므로 문제점의 근원을 해소한다.
2. 장래 계획으로 아키텍트라는 구체적인 모델을 그릴 수 있어 진로를 명확하게 할 수 있다.
p.37
요구사항 분석은 시스템이 어떠한 기능을 요구하는지 비즈니스 관점에서 파악하고 정리하는 것
명세 설계는 분석 결과로 나온 각종 요구 조건을 판단 근거로 삼아, 화면 설계와 데이터베이스 테이블 설계, 기능 요구사항, 성능과 장애에 대한 내구성과 같은 구조적이고 관리적인 요
구사항을 정리
p. 43
요구분석 단계에서는 예산의 범위나 투자 대비 효과 등 비즈니스상의 제약조건에 영향을 받는다. 그러므로 목표를 실현하기 위한 기술적인 아이디어를 내는 것이 중요하다. 아이디어를
내기 위해 요구분석 담당자와 아키텍트를 중심으로 브레인스토밍을 해보는 것이 좋은데, 최종적으로 그 아이디어를 이용하는 경우에 발생할 기술 제약에 대핸 검토하는 것도 잊지 말아
야 한다.
- 프로젝트 전반부의 담당자는 비즈니스 마인드로 프로젝트를 바라보는 능력이 있어야 하며, 그러한 능력은 아키텍트에게도 요구된다.
- 요구사항 정의 단계에서 아키텍트는 기술 전문가의 입장에서 조언한다.
p. 46
기술적인 위험요소는 간단한 것이라도 나중까지 남겨두지 않는 것이 중요하다. 설계를 변경하거나 요구사항을 조정하는 방식으로 해결하지 못한 경우에는, 위험요소의 원인이 되는 요구
사항을 개발 초기에 구현하고 검토하는 반복형 개발을 선택하여, 개발 후반부까지 위험요소가 남지 않도록 프로젝트 계획을 수정해야 한다.
- 기술 관련 위험요소는 개발 초기에 해결한다. 그것이 어렵다면 위험요소 해결을 위한 계획을 수립한다.
p. 48
- 비기능 요구사항은 최종사용자에게서 도출되는 것이 아니므로, 기술자가 적극적으로 제안한다.
p.49
아키텍트가 제안하는 명세는 개발하기 쉬운 쪽으로 치우치기 쉽다.
아키텍트는 실제 구현 상황을 우선하고, 사용자의 편의성을 그 다음으로 생각하는 경향이 있다. 아키텍트가 충분히 이해하지 못해서 실제 사용자에게는 매우 중요한 기능을 무시하는 경
우도 있다. 아키텍트는 구현단계에서도 그래야겠지만 분석, 설계 단계에서는 특히 사용자를 중심으로 상황을 인식하는 것이 바람직한다.
p. 59
아키텍처 정의: 애플리케이션 설계와 구현의 기본지침
p. 180
개발자가 납득할 수 없는 업무는 다른 사람들에게도 좋지 않으며 비즈니스에도 문제를 일으킬 가능성이 많다.
- 개발자가 납득할 수 없는 시스템은 비즈니스에도 문제가 된다.
P.185
시스템 개발 방정식
변수: 비용, 품질, 범위, 기간
(품질 * 범위) / 기간 = 비용
