第七章资讯系统开发(一)专案管理策略课件

1、第七章資訊系統開發(一)專案管理策略第七章資訊系統開發(一)專案管理策略第七章 資訊系統開發(一) 專案管理策略學習目標 認識軟體危機認識軟體開發的迷思瞭解影響軟體開發的因素認識軟體衡量指標熟悉軟體專案規劃的步驟瞭解專案負責人的工作內容瞭解軟體構型管理的重要性第七章 資訊系統開發(一) 專案管理策略學習目標 認識軟體危第七章 資訊系統開發(一) 專案管理策略軟體危機 為什麼軟體系統總是無法如期完成？ 為什麼軟體系統上線後，總是還有很多的錯誤 (bugs) 發生？為什麼開發軟體的代價是如此的昂貴？ 為什麼無法確實的衡量軟體開發的品質與進度？第七章 資訊系統開發(一) 專案管理策略軟體危機 為什麼

2、軟體第七章 資訊系統開發(一) 專案管理策略軟體危機第七章 資訊系統開發(一) 專案管理策略軟體危機第七章 資訊系統開發(一) 專案管理策略硬體系統的錯誤率曲線 第七章 資訊系統開發(一) 專案管理策略硬體系統的錯誤率曲線第七章 資訊系統開發(一) 專案管理策略軟體系統的錯誤率曲線 第七章 資訊系統開發(一) 專案管理策略軟體系統的錯誤率曲線第七章 資訊系統開發(一) 專案管理策略管理者的迷思 我們已經購買了最新、最先進的的電腦，也制定了標準的作業程序和規範手冊，該有的都有了，開發一個軟體系統應該是水到渠成的事如果軟體系統的進度還是落後時，就增加幾個程式人員來幫忙，應該就可以趕上進度如果開發軟

3、體系統這麼麻煩，乾脆就外包算了，我們只要付錢就行，那些麻煩的事就由別人去煩惱好了第七章 資訊系統開發(一) 專案管理策略管理者的迷思 我們已第七章 資訊系統開發(一) 專案管理策略使用者的迷思 我只要提出一些系統的主要功能和系統開發的大原則、大方向，就足以讓系統的開發者回去規劃系統、甚至開始先寫程式了。如有不足、或是更細節的部分，我們日後再設法補足軟體系統的需求常常會隨著時間變化，好在軟體很有彈性，修改程式也不需要什麼錢 (至少不需要花錢買材料)，就是麻煩你動動腦、動動手而已第七章 資訊系統開發(一) 專案管理策略使用者的迷思 我只要第七章 資訊系統開發(一) 專案管理策略系統開發者的迷思 一

4、旦我的程式寫完了、上線運轉了，我的工作也就完成了 交付的產品主要就是這些程式碼和簡單的操作手冊而已 軟體的品質事前無法評估，要等到系統上線以後才能見分曉 標準作業程序和規範要求我們要建立大量的開發文件，只會延緩我們的開發進度，並沒有太大的意義和價值 第七章 資訊系統開發(一) 專案管理策略系統開發者的迷思 一第七章 資訊系統開發(一) 專案管理策略系統開發的成敗因素 系統的大小 系統上線的時程 預算的多寡 問題的應用領域 使用技術的難度 系統的限制 使用者的需求可以使用資源的多寡 第七章 資訊系統開發(一) 專案管理策略系統開發的成敗因素 第七章 資訊系統開發(一) 專案管理策略系統危機的10

5、項指標 軟體人員無法了解使用者的需求軟體系統的範圍沒有清楚的定義軟體的變更沒有妥善的管理所選用的技術需要改變商業的需求發生重大改變訂定了不合理的系統上線時程使用者發生抗拒的行為失去管理階層的支持系統開發人員缺乏相關的技術能力和經驗管理階層(或系統開發者)試圖去規避標準作業程序的規範或歷史經驗的教訓第七章 資訊系統開發(一) 專案管理策略系統危機的10項指標第七章 資訊系統開發(一) 專案管理策略如何防止軟體專案陷入系統危機 從正確的步驟開始維持整個開發團隊的士氣追蹤、管考專案的進展做出對的決策執行事後的分析第七章 資訊系統開發(一) 專案管理策略如何防止軟體專案陷入第七章 資訊系統開發(一)

6、專案管理策略軟體開發的90-90 法則 軟體系統開發的前90%的工作，花掉了全部專案90%的資源與時間，剩下10%的工作，也要花 掉全部專案90%的資源與時間 (Zahniser, 1994)可能的原因為：專案進度的評估不夠確實低估收尾工作的複雜度沒有作好風險評估和風險控管整個時程的安排不合理第七章 資訊系統開發(一) 專案管理策略軟體開發的90-90第七章 資訊系統開發(一) 專案管理策略軟體專案衡量指標 (1/2) 軟體專案衡量指標依據軟體專案開發過程所收集到的一些數據，形成的一個量化性的指標用來衡量專案的軟體品質或是生產力的好壞發現專案開發上潛藏的問題提供預警的訊號管理階層或系統開發者採

7、取適當的步驟，修正錯誤增進軟體品質提升生產力第七章 資訊系統開發(一) 專案管理策略軟體專案衡量指標 (第七章 資訊系統開發(一) 專案管理策略軟體專案衡量指標 目標導向軟體衡量(Park et al, 1996)可以用來描述 (characterize) 軟體系統的實況，並且可以提供未來評比的標準可以用來評估 (evaluate) 軟體系統的現況，看看它與專案計畫間的差異，也可以用來評估軟體的品質和生產力的優劣可以用來找出軟體衡量指標與軟體屬性 (attributes) 之間的關係，因此可以使用軟體衡量指標來預測 (predict) 其他的軟體屬性可以用來幫助我們找出缺失、沒有效率的地方，以

8、增進 (improve) 軟體系統的品質和生產力第七章 資訊系統開發(一) 專案管理策略軟體專案衡量指標 目第七章 資訊系統開發(一) 專案管理策略開發軟體專案衡量指標的注意事項 (1/2)開發軟體專案衡量指標的注意事項 (Grady, 1992)當解釋專案衡量指標所代表的意義時，只要據實呈現就好，千萬不可以擴大解釋；一定要有足夠的組織敏感度，以免引發一些政治上的聯想週期性的提供專案衡量指標給專案開發小組，千萬不可有時有、有時沒有；也不可以只評估某些小組、不評估其他小組。這樣都會遭致對人不對事的反彈不要運用專案衡量指標來稱讚某一個成員的貢獻 (這應該是全體成員的績效)；也不要運用專案衡量指標來

9、恐嚇某一個成員或整個小組的表現 (這會引發內部鬥爭或秋後算帳的聯想)第七章 資訊系統開發(一) 專案管理策略開發軟體專案衡量指標第七章 資訊系統開發(一) 專案管理策略開發軟體專案衡量指標的注意事項 (2/2)設定衡量指標時，一定要就衡量的內容和成員們達成清楚的共識，日後也確實是這樣的去衡量他們，這樣大家才能心服口服衡量指標顯示出某項問題時，不應該被當成一定是負面的意義，正面的思考是：它們也可以被當成是指引有待努力的方向衡量的指標有很多種，不應該只強調或抨擊某一項負面的指標，而忽略讚美其他指標所代表的意義 第七章 資訊系統開發(一) 專案管理策略開發軟體專案衡量指標第七章 資訊系統開發(一)

10、專案管理策略衡量指標的分類 以程式碼 (lines of code, LOC) 為衡量的基礎平均每一千行指令所發生的錯誤數平均每一行指令的成本平均每一千行指令所能產生的文件頁數平均每一個人月所發生的錯誤數平均每一個人月所能生產的指令行數平均每一頁文件的成本以功能的複雜度 (function point, FP) 為衡量的基礎平均每一個功能點所發生的錯誤數平均每一個功能點的成本平均每一個功能點所能產生的文件頁數第七章 資訊系統開發(一) 專案管理策略衡量指標的分類 以程第七章 資訊系統開發(一) 專案管理策略衡量指標的分類 雖然計算程式碼的行數非常的簡單，估計功能點的工作比較麻煩，但是一般的學者

11、還是認為以功能複雜度的計點方式來衡量軟體指標，要比以程式碼行數為單位的計算方式來得好，主要的理由有下列四點：以程式碼計算，常常會受到所使用的開發語言影響以程式碼為衡量基礎的結果會對於較長的程式碼有利 功能點的計算是以問題領域 (information domain) 的功能為基準以功能點作為軟體指標衡量的基礎，有助於程式的模組化第七章 資訊系統開發(一) 專案管理策略衡量指標的分類 雖然第七章 資訊系統開發(一) 專案管理策略如何衡量軟體的品質 (1/2) 正確性 (correctness) 符合使用者需求平均一千行指令所發生的錯誤數可維護性 (maintainability) 系統容易被修改

12、的程度平均修改時間第七章 資訊系統開發(一) 專案管理策略如何衡量軟體的品質 第七章 資訊系統開發(一) 專案管理策略如何衡量軟體的品質 (2/2) 完整性 (integrity) 資訊系統免於受到外界攻擊的能力完整性=1-(threat*(1-security)可使用性 (usability)系統容易被使用的程度與親和度使用這個系統所需具備的技術學會使用這個系統所需花費的時間使用這個系統取代原來的作業方式後，所能增加的生產力使用者對這個系統的滿意程度第七章 資訊系統開發(一) 專案管理策略如何衡量軟體的品質 第七章 資訊系統開發(一) 專案管理策略軟體專案規劃的五個步驟 第七章 資訊系統開發

13、(一) 專案管理策略軟體專案規劃的五個步第七章 資訊系統開發(一) 專案管理策略界定軟體專案的範圍 透過與使用者的會談、觀察現有的系統、收集相關的表冊，就可以了解使用者的需求、問題的本質、軟體專案的範圍、使用者 的動機與參與度與專案最可能發生變更的地方了解需要建立哪些系統功能 (function)?使用者 對 於 系統的界面 (interface) 、 效能 (performance) 和可靠性 (reliability) 的要求是什麼?系統的限制條件有哪些?第七章 資訊系統開發(一) 專案管理策略界定軟體專案的範圍 第七章 資訊系統開發(一) 專案管理策略預估時程、經費和所需的資源 軟體專案

14、資源：硬體設備、開發工具，及專業人員預估的不確定性受到下列三個因素的影響：軟體專案的複雜度軟體專案的大小軟體專案需求上的不確定性第七章 資訊系統開發(一) 專案管理策略預估時程、經費和所需第七章 資訊系統開發(一) 專案管理策略預估時程、經費和所需的資源 想要達成比較準確的預估，可以採用下列的三種方式：依據過去類似的軟體專案計畫的數據，來估計這個軟體專案所需要的時程、經費和資源 利用功能分解的方式，將一個大的功能切割成一個個小小的功能，一個小的、單純的功能所需要的資源比較容易估計，彙總後，自然就可以比較準確的估計整個軟體專案所需要的時程、經費和資源利用一些依據經驗模型的套裝軟體，來推估整個軟體

15、專案所需要的時程、經費和資源第七章 資訊系統開發(一) 專案管理策略預估時程、經費和所需第七章 資訊系統開發(一) 專案管理策略評估風險以及預防的對策在做風險評估時應該考慮的因素有：什麼地方可能出錯？它發生的機率有多高？它造成的損害會有多大？我們怎麼樣可以避免它的發生？如果它真的發生了，我們有什麼樣的對策？第七章 資訊系統開發(一) 專案管理策略評估風險以及預防的對第七章 資訊系統開發(一) 專案管理策略造成進度落後的原因 管理階層訂定了不合理的專案時程使用者的需求改變，新增加了一些工作，但是時程表並沒有做對應的修正低估了工作量，或是所需要的資源，導致資源不足沒有做好風險評估，產生了預期中 /

16、 不可預期的風險技術上的難度超過了事前的預期人事方面的問題超過了事前的預期，例如：想要的人沒有要到、重要的人員突然離職 . 等等專案人員之間溝通不良沒有做好專案管理的工作，沒有發覺進度已經落後，或沒有採取補救的行動第七章 資訊系統開發(一) 專案管理策略造成進度落後的原因 第七章 資訊系統開發(一) 專案管理策略訂定計畫進度和查核點 界定每一個獨立的工作項目界定這些工作之間的關連性，排定它們之間的先後順序排定每一項工作的時程分配給每一項工作所需要的資源分派每一個專案人員的職責，也就是界定哪一些工作是由哪一些人來負責定義每一項工作所需要交付的成果定義查核點的位置和需要查核的項目，以確保軟體的品質

17、並確實掌握專案的進度第七章 資訊系統開發(一) 專案管理策略訂定計畫進度和查核點第七章 資訊系統開發(一) 專案管理策略正規技術評審會議正規技術評審是一個軟體品質保證的機制，它是由一群技術人員針 對另外一個技術人員所設計的軟體提供專業評審意見的會議它主要的目的 當然是希望發揮旁觀者清的效果，找出設計者的盲點和設計上的錯誤此外，透過這些會議，對於參與者也有一些教育訓練的功能 第七章 資訊系統開發(一) 專案管理策略正規技術評審會議正規第七章 資訊系統開發(一) 專案管理策略正規技術評審會議的注意事項 (1)要事先詳閱審核的的資料，這樣才能節省會議的時間，並且言之有物在評論問題時，要對事不對人。注

18、意你的用字遣詞，不要以控訴的口吻來責問，你只是提出問題而已遵守會議議程，不要離題太遠，節外生枝只是提出問題而已，不要爭論解決這個問題的方法，讓設計者帶回去再仔細考慮看看第七章 資訊系統開發(一) 專案管理策略正規技術評審會議的注第七章 資訊系統開發(一) 專案管理策略正規技術評審會議的注意事項 (2)不要去討論風格或偏好的問題，那是見仁見智的事，只討論技術上的正確與否就好將正規技術評審視為是專案計畫的例行工作，每一個設計都應該被評審，千萬不要做選擇性的評審，以免引發反彈要將所有的評審結果以書面的方式記錄下來，以便日後可以追蹤它的修改進度第七章 資訊系統開發(一) 專案管理策略正規技術評審會議的

19、注第七章 資訊系統開發(一) 專案管理策略收集專案軟體品質指標正規技術評審可以由評審的結果中收集到專案軟體品質的指標每一頁文件的平均審查時間每一千行程式碼或每一個功能點的平均審查時間平均每一小時的審查可以發現的錯誤數目平均每一小時的事前準備可以發現的錯誤數目每一項系統開發的工作所發生的錯誤數目 (例如：分析階段、設計階段.)發生輕微錯誤的數目發生重大錯誤的數目第七章 資訊系統開發(一) 專案管理策略收集專案軟體品質指標第七章 資訊系統開發(一) 專案管理策略收集專案軟體品質指標第七章 資訊系統開發(一) 專案管理策略收集專案軟體品質指標第七章 資訊系統開發(一) 專案管理策略軟體專案負責人的工

20、作 維繫軟體專案的品質作好風險評估的工作建立軟體衡量指標經費的預估與管控工作時程的預估與管控帶領軟體專案人員尋求適當的資源專案的監督工作與使用者的溝通第七章 資訊系統開發(一) 專案管理策略軟體專案負責人的工作第七章 資訊系統開發(一) 專案管理策略軟體構型管理 不論我們在事前多麼用心的規劃，軟體專案在進行的過程中，還是難免有修改需求與設計的可能通常一個大的軟體專案都是由很多人員共同來完成，如果你變更了設計、變更了規格，卻沒有能夠讓每個人都知道，將來系統要整合時，就一定會發生介面不合、牛頭不對馬嘴的事情因此，既然變更設計的需求是一件無法避免的事情，那我們就需要設計一套機制，透過一連串的控管和核

21、可的過程，來 防止任意變更軟體的需求和設計，並且將改變公告周知此外，有些軟體可能開發了非常多的版本，這個時候更需要一套機制來分別記錄哪一個版本中有哪些軟體元件，萬一日後系統需要維護時，才知道要將系統還原到什麼樣的樣子 第七章 資訊系統開發(一) 專案管理策略軟體構型管理 不論我第七章 資訊系統開發(一) 專案管理策略軟體構型管理的核心議題 如何辨識有哪些軟體構型元件？如何管理眾多版本的程式和相關文件？要如何作好軟體元件的變更管控？誰負責核准和安排變更的優先順序？如何保證所有的變更作業都已經被妥善的處理好了？有什麼樣的機制可以將變更的工作公告周知？第七章 資訊系統開發(一) 專案管理策略軟體構型管理的核心議第七章 資訊系統開發(一