#title Kimball LifeCycle

==== Kimball LifeCycle Diagram ====
attachment:KimballLifeCycle/kimball_lifecycle.png
※ 신생팀이 가장 많이 실수하는 것 중의 하나가 구축 목적에 대한 명확한 이해없이 제품을 선정하는 것

==== 프로그램/프로젝트 계획과 관리 ====
준비 평가
 * 강력한 스폰서는 확보되었는가?
 * 강한 비즈니스 동기가 있는가?
 * 데이터에 대한 실행 가능성이 있는가? (데이터 품질에 문제가 있다면 상당 시간 클린징해야 함)

범위 산정
 * 비즈니스 조직에게 의미있고, IT조직이 관리 가능한 범위(비즈니스 조직과 IT조직의 공동 협업 필요)
 * 초기에는 하나의 비즈니스 프로세스로부터 추출한 데이터에 집중하는 프로젝트를 해야 함.
 * 비용 산정은 단기 성장을 고려한 여유 비용을 확실하게 확보한다.

타당성 검토
 * 단순히 비용 절감에 초점을 두면 안됨.
 * 'single view', '유연한 정보 접근'으로는 부족함.

인력구성
 * 비즈니스 스폰서, 비즈니스 드라이버, 비즈니스 리더, 비즈니스 사용자
 * 비즈니스 분석가, 데이터 담당자, BI 어플리케이션 설계/개발자
 * 프로젝트 관리자, 테크니컬 아키텍트, 데이터 아키텍트/모델러, DBA, 메타데이터 코디네이터, ETL 아키텍트/설계자, ETL 개발자

개발 및 유지보수 계획
 * 각 단계와 산출물들로 프로젝트가 정상적으로 진행될 수 있음을 확인되어야 함.
 * 수용 가능한 체크 포인트 식별
 * 요구사항 범위 변경 시 옵션
  * 범위 증가(시간, 자원, 예산)
  * 제로-썸(원래 범위를 유지하거나 다른 것을 포기)
  * No(개선 요건으로 처리)

==== 비즈니스 요구사항 정의 ====
요구사항 사전 계획
 * 그래뉼래러티와 차원수에 대해 질문하지 말 것
 * 무엇을 하려고 하는 지, 왜 그래야 하는지, 어떻게 결정을 내리는지, 미래에 어떻게 결정을 내리고 싶어하는지 등의 질문
 * 토론 방법의 선택
  * 경험상, 설문조사는 적적치 않음
  * 인터뷰를 통해 상세 요건을 수집 후, 그룹 미팅을 통해 요구사항에 대한 동의를 이끌어 냄
 * 공통 데이터와 비즈니스 어휘를 이해할 필요가 있음
 * 비즈니스 파워 분석가의 직관이 가치가 있을지라도, 중간 관리자나 고위 경영진을 무시할 수 없음. 안 그러면 전술부분만 강조됨.
 * 하루에 3~4개 이상의 회의를 잡는 것은 좋지 않다.
 * 친절, 친절, 친절

비즈니스 요구사항 수집
 * 회의 목적을 설명할 사람이 회의 전에 결정되어 있어야 함.
 * 비즈니스 중심의 언어를 사용. IT용어는 최대한 자제
 * 인터뷰의 목적은 비즈니스 부서가 무엇을 하는지, 왜 하는지를 말하게 하는 것
 * 비즈니스 관리자는 표준화된 분석 환경의 전달에 더 관심이 있다.
 * 비즈니스 지원 가능성을 평가하기 위해 원천 시스템 전문가나 주제 영역 전문가와의 회의를 중간중간에 배치하는 것도 도움이 된다.
 * 회의록은 바로 공유
 * 업무프로세스/이해관계자 메트릭스를 종종 공개
 * 잠재적인 비즈니스 영향력(y축), 실행가능성(x축)을 바탕으로 우선순위 정함