第七章

1. 第七章 資訊系統開發(一)－專案管理策略 Ren-JieWang,王 仁 傑, Ph.D. rjwang@ntit.edu.tw 課程網頁: http://home.scs.ntit.edu.tw/rjwang/ 資料來源 : 資訊管理導論 范錚強教授 著 國立澎湖科技大學 資管系 林永清教授 整理

2. 學習目標 • 認識軟體危機 • 認識軟體開發的迷思 • 瞭解影響軟體開發的因素 • 認識軟體衡量指標 • 熟悉軟體專案規劃的步驟 • 瞭解專案負責人的工作內容 • 瞭解軟體構型管理的重要性 第七章 資訊系統開發(一) 專案管理策略

3. 軟體危機 • 軟體人才缺乏 • 軟體人工作繁重，力不從心 • 未依循標準作業程序 • 軟體品質？ 第七章 資訊系統開發(一) 專案管理策略

4. 軟體危機 第七章 資訊系統開發(一) 專案管理策略

5. 硬體系統的錯誤率曲線 第七章 資訊系統開發(一) 專案管理策略

6. 軟體系統的錯誤率曲線 第七章 資訊系統開發(一) 專案管理策略

7. 管理者的迷思 • 最新、最先進的的電腦＋標準的作業程序和規範手冊＝軟體系統的開發成功？ • 軟體系統的進度落後時→增加程式人員就可以趕上進度？ • 付錢外包就可以解決問題？ 第七章 資訊系統開發(一) 專案管理策略

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

9. 系統開發者的迷思 • 一旦我的程式寫完了、上線運轉了，我的工作也就完成了 • 交付的產品主要就是這些程式碼和簡單的操作手冊而已 • 軟體的品質事前無法評估，要等到系統上線以後才能見分曉 • 標準作業程序和規範要求我們要建立大量的開發文件，只會延緩我們的開發進度，並沒有太大的意義和價值 第七章 資訊系統開發(一) 專案管理策略

10. 系統開發的成敗因素 p.7-9 • 系統的大小 • 越大越不好掌握 • 系統上線的時程 • 越趕越容易出錯 • 預算的多寡 • 一分錢一分貨 • 問題的應用領域 • 越多人做的領域越容易成功 • 使用技術的難度 • 技術難度越高越不好做 • 系統的限制 • 限制越多越難做 • 使用者的需求 • 有特殊需求？ • 可以使用資源的多寡 • 資源越充裕越容易做 第七章 資訊系統開發(一) 專案管理策略

11. 系統危機的10項指標 p7-10 • 以下指標超過７項，就代表軟體專案陷入了危機： • 軟體人員無法了解使用者的需求 • 軟體系統的範圍沒有清楚的定義 • 軟體的變更沒有妥善的管理 • 所選用的技術需要改變 • 商業的需求發生重大改變 • 訂定了不合理的系統上線時程 • 使用者發生抗拒的行為 • 失去管理階層的支持 • 系統開發人員缺乏相關的技術能力和經驗 • 管理階層(或系統開發者)試圖去規避標準作業程序的規範或歷史經驗的教訓 第七章 資訊系統開發(一) 專案管理策略

12. 如何防止軟體專案陷入系統危機 • J.S. Rell 提出避免軟體專案陷入系統危機的方法： • 從正確的步驟開始 • 維持整個開發團隊的士氣 • 追蹤、管考專案的進展 • 做出對的決策 • 執行事後的分析 第七章 資訊系統開發(一) 專案管理策略

13. 軟體開發的90-90 法則 • 軟體系統開發的前90%的工作，花掉了全部專案90%的資源與時間，剩下10%的工作，也要花掉全部專案90%的資源與時間 • 可能的原因為：see p.7-12 • 專案進度的評估不夠確實 • 低估收尾工作的複雜度 • 沒有作好風險評估和風險控管 • 整個時程的安排不合理 第七章 資訊系統開發(一) 專案管理策略

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

15. 衡量指標的分類 • 通常分為兩大類： • 以程式碼 (lines of code, LOC) 為衡量的基礎 • 平均每一千行指令所發生的錯誤數 • 平均每一行指令的成本 • 平均每一千行指令所能產生的文件頁數 • 平均每一個人月所發生的錯誤數 • 平均每一個人月所能生產的指令行數 • 平均每一頁文件的成本 • 以功能的複雜度 (function point, FP) 為衡量的基礎 (較佳） • 平均每一個功能點所發生的錯誤數 • 平均每一個功能點的成本 • 平均每一個功能點所能產生的文件頁數 第七章 資訊系統開發(一) 專案管理策略

16. 衡量指標的分類 • 以功能複雜度的計點方式來衡量軟體指標，要比以程式碼行數為單位的計算方式來得好，主要的理由有下列四點： • 以程式碼計算，常常會受到所使用的開發語言影響 • 以程式碼為衡量基礎的結果會對於較長的程式碼有利 • 功能點的計算是以問題領域 (information domain) 的功能為基準 • 以功能點作為軟體指標衡量的基礎，有助於程式的模組化 第七章 資訊系統開發(一) 專案管理策略

17. 如何衡量軟體的品質 • Gilb T. 建議如下四項指標： • 正確性 (correctness) • 可維護性 (maintainability) • 完整性 (integrity) • 可使用性 (usability) 第七章 資訊系統開發(一) 專案管理策略

18. 軟體專案規劃的五個步驟 第七章 資訊系統開發(一) 專案管理策略

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

20. 預估時程、經費和所需的資源 2/5 • 預估的不確定性受到下列三個因素的影響： • 軟體專案的複雜度 • 軟體專案的大小 • 軟體專案需求上的不確定性 第七章 資訊系統開發(一) 專案管理策略

21. 預估時程、經費和所需的資源 2/5 • 想要達成比較準確的預估，可以採用下列的三種方式： • 依據過去類似的軟體專案計畫的數據，來估計這個軟體專案所需要的時程、經費和資源 • 利用功能分解的方式，將一個大的功能切割成一個個小小的功能，一個小的、單純的功能所需要的資源比較容易估計，彙總後，自然就可以比較準確的估計整個軟體專案所需要的時程、經費和資源 • 利用一些依據經驗模型的套裝軟體，來推估整個軟體專案所需要的時程、經費和資源 第七章 資訊系統開發(一) 專案管理策略

22. 評估風險以及預防的對策 3/5 • 在做風險評估時應該考慮的因素有： • 什麼地方可能出錯？ • 它發生的機率有多高？ • 它造成的損害會有多大？ • 我們怎麼樣可以避免它的發生？ • 如果它真的發生了，我們有什麼樣的對策？ 第七章 資訊系統開發(一) 專案管理策略

23. 造成進度落後的原因 • 不合理的專案時程 • 使用者的需求改變 • 資源不足 • 沒有做好風險評估 • 技術上的難度超過了事前的預期 • 人事方面的問題 • 專案人員之間溝通不良 • 沒有做好專案管理的工作 第七章 資訊系統開發(一) 專案管理策略

24. 訂定計畫進度和查核點 4/5 • 界定每一個獨立的工作項目 • 界定這些工作之間的關連性，排定它們之間的先後順序 • 排定每一項工作的時程 • 分配給每一項工作所需要的資源 • 分派每一個專案人員的職責，也就是界定哪一些工作是由哪一些人來負責 • 定義每一項工作所需要交付的成果 • 定義查核點的位置和需要查核的項目，以確保軟體的品質並確實掌握專案的進度 第七章 資訊系統開發(一) 專案管理策略

25. 訂定控管的策略　5/5 • 正規技術評審會議 • 收集專案軟體品質指標 第七章 資訊系統開發(一) 專案管理策略

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

27. 收集專案軟體品質指標 第七章 資訊系統開發(一) 專案管理策略

28. 軟體專案負責人的工作 • 維繫軟體專案的品質 • 作好風險評估的工作 • 建立軟體衡量指標 • 經費的預估與管控 • 工作時程的預估與管控 • 帶領軟體專案人員 • 尋求適當的資源 • 專案的監督工作 • 與使用者的溝通 第七章 資訊系統開發(一) 專案管理策略

29. 軟體構型管理Software Configuration Management, SCM • 不論我們在事前多麼用心的規劃，軟體專案在進行的過程中，還是難免有修改需求與設計的可能 • 通常一個大的軟體專案都是由很多人員共同來完成，如果你變更了設計、變更了規格，卻沒有能夠讓每個人都知道，將來系統要整合時，就一定會發生介面不合、牛頭不對馬嘴的事情 • 因此，既然變更設計的需求是一件無法避免的事情，那我們就需要設計一套機制，透過一連串的控管和核可的過程，來 防止任意變更軟體的需求和設計，並且將改變公告周知 • 此外，有些軟體可能開發了非常多的版本，這個時候更需要一套機制來分別記錄哪一個版本中有哪些軟體元件，萬一日後系統需要維護時，才知道要將系統還原到什麼樣的樣子 第七章 資訊系統開發(一) 專案管理策略

30. 軟體構型管理的核心議題 • 如何辨識有哪些軟體構型元件？ • 如何管理眾多版本的程式和相關文件？ • 要如何作好軟體元件的變更管控？ • 誰負責核准和安排變更的優先順序？ • 如何保證所有的變更作業都已經被妥善的處理好了？ • 有什麼樣的機制可以將變更的工作公告周知？ 第七章 資訊系統開發(一) 專案管理策略

31. 軟體構型管理的工作內容 • 確認組成軟體構型的元件 • 版本控制 • 變更控制 • 軟體構型審核 • 軟體構型狀態報告書 第七章 資訊系統開發(一) 專案管理策略

32. 確認組成軟體構型的元件 • 程式碼： • 包括原始程式碼和相關的執行檔 • 技術文件： • 包括可行性分析、系統需求規格書、系統分析文件、設計 規格、測試計畫 ... 等 • 資料： • 包括正規技術評審會議紀錄、測試資料 ... 等 第七章 資訊系統開發(一) 專案管理策略

33. 變更控制 第七章 資訊系統開發(一) 專案管理策略

34. 軟體構型審核 • 是否在變更報告中所有的需求都已經完成？有沒有掛一漏萬？ • 變更的軟體元件是否有經過正規技術評審會議的審查？ • 在變更的過程中是否有依循標準作業規範的規定？ • 與軟體元件相關的屬性資料是否有一併修正？如果沒有一併修正，就會有彼此不一致的狀況發生，時間一久，就弄不清楚誰是誰了 • 是否有將修改的過程記錄下來，並公告周知？ • 軟體元件間的關係錯綜複雜，修改這個元件時，是否也一併修正了相關的軟體構型元件？ 第七章 資訊系統開發(一) 專案管理策略

35. 軟體構型狀態報告書 • 日後可以由報告中追蹤到下列的資訊： • 發生什麼樣的改變？ • 由誰負責這項變更的工作？ • 在什麼時候做的改變？ • 這項變更會引發什麼其他的影響？ 第七章 資訊系統開發(一) 專案管理策略

36. 軟體構型管理 第七章 資訊系統開發(一) 專案管理策略