瀑布式做法系统完成分析设计建置测试.PPT

本章學習重點 資料倉儲系統的兩種作法 資料倉儲團隊身分 專案團隊的組成 兩種作法 FIG. 3.1, P. 3-2 (Traditional vs. DWing) 系統建置有兩種作法： 瀑布式（Waterfall Methodology） 旋轉式（Spiral Methodology） 瀑布式做法 在瀑布式的做法中，每一個階段都需要結束後下一個階段才開始。 瀑布式做法 這種方法的目的是建製一個完美的系統。 一般來説，以瀑布式作法來建置資料倉儲系統需要花上十八到二十四個月的時間。 瀑布式的缺點如下： 需要的時間太長。 忘記需求、需求不那麼重要…user不在…等不下去… 一次花費過大。 旋轉式做法 在旋轉式的做法中，我們在每一個階段花的時間比較少，而且整個系統的建置是一直不斷地在進行的。 旋轉式做法步驟 和使用者討論需求。 對所有的需求做一個評估來決定資料倉儲第一期要先滿足那一些需求。 In general: increase sales amount/dec. cost 與使用者對每一期的範圍達到共識。 建置及測試第一期的系統。 第一期系統上線後再開始第二期的建置。 In practice, each stage = one data mart 旋轉式做法 在第一期的建置上，資料倉儲團隊應該將重點放在系統架構的建立，而需求範圍則應挑選一個重要性高且易完成的主題。 這目的是能讓使用者很快地看到成果，並且讓以後的建置行動不必顧慮到架構上的問題。 如果可能的話，資料倉儲團隊應該計劃每一期不要超過三個月去完成。 旋轉式與瀑布式做法比較 和瀑布式的做法比較，旋轉式的做法有下列的好處： 系統能迅速地上線。 一次花費不會太大。 使用者的意見可以很快地被反應在系統的設計上。 資料倉儲團隊身份 通常資料倉儲團隊身份有兩種：第一種是外請顧問，第二種是內部員工。 不同的身份代表負責的事情、價錢、以及能力都不一樣。 How to find a good team? (p. 3-9) 外請顧問特性 專案團隊可能完全是由外請顧問組成，或是依角色的需求來請顧問。 外請專案團隊的唯一目的就是建製資料倉儲系統。他們有以下的特性： 已經有好幾個資料倉儲專案的建置經驗，也已經從這些經驗中找出了最佳做法(best practice)。 Best practice: 見招拆招！ 價錢一般來說都不便宜。 對客戶的專業領域不一定熟悉，可是對於系統建製過程與工具的使用會非常瞭解。 外請顧問常擔任的角色 以下的角色較常請顧問： 專案經理。 業界專家。 技術專家。 內部員工 建製資料倉儲系統並非是他們唯一的工作。他們通常也需要負責回答一些其他資料方面的問題。 對組織的專業領域熟悉。 一般比較缺乏資料倉儲系統的建置經驗。 外請顧問及內部員工的比較 建議做法 組織在專案剛開始時應對內部的員工技能做一個全盤的瞭解。 如果組織內部缺乏對資料倉儲有經驗的人員，那就應該考慮請一個顧問團來進行這個專案。 如果組織內部已經具有一些專業能力的話，那就應該考慮由內部員工負責專案，而在需要的地方延請外面的顧問。 專案團隊的組成 資料倉儲系統是一個複雜的系統，因此資料倉儲專案團隊內需要有許多不同的角色，而這些角色必須要發揮團隊精神才能使專案成功。 在一個資料倉儲專案團隊中專案經理是處於領導整個專案的地位。 其他的角色可以分為兩大部份：資料方面以及架構方面。資料方面是由資料設計師來領導，而架構方面是由資料倉儲建築師來領導。 專案團隊的組織 角色與人力的對應 角色與人力並不一定是一對一的關係。一個人可能會擔當好幾個角色，或是好幾個人都是擔當同一個角色。 實際上的人力分配需要視專案本身的情況而定。 專案經理 專案經理的職責 專案經理的稱職與否會直接影響專案的成敗。 一位稱職的專案經理必須： 確認專案能照預計的進度進行。 (推銷proj) 明白並減低各種會影響專案的風險，尤其是專案範圍漸移動（scope creep）。 Allow/same-timeline, allow/new-timeline, reject 是一個優良的談判專家。(多單位協調、優先序) 做一位資料倉儲系統的大使。 專案經理必須是一個專職的角色。 專案經理所需的能力 專案經理所需要擁有的能力最重要的有以下幾點： 擁有良好的組織能力，能仔細注意細節部份。 口齒清晰 ，擁有良好的表達能力。(推銷…) 擁有良好的外交能力 。(協調不同部門) 瞭解公司的運作方式及內部政治環境。 對突發的情況能冷靜地處理。 大致上來説，專案經理不需要瞭解所有技術方面上的細節。