第七章 資訊系統開發 ( 一 ) － 專案管理策略

1. 第七章 資訊系統開發(一)－專案管理策略 資訊管理導論 范錚強教授 著 國立澎湖科技大學 資管系 林永清 整理

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

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

4. 軟體危機 使用者的抱怨： • 為什麼軟體系統總是無法如期完成？ • 為什麼軟體系統上線後，總是還有很多的錯誤 (bugs) 發生？ • 為什麼開發軟體的代價是如此的昂貴？ • 為什麼無法確實的衡量軟體開發的品質與進度？ 第七章 資訊系統開發(一) 專案管理策略

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

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

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

8. 軟體危機 • 1970年代中期所提出系統開發方法： • 生命週期法 • 快速雛型法 • 電腦輔助軟體工程 • 物件導向法 (將於下一章詳細介紹) 第七章 資訊系統開發(一) 專案管理策略

9. 系統開發方法 • 如何設計建置一個資訊系統的藍圖 • 系統開發方法 (SDM) • 從開發到維護一個資訊系統的過程 • 改善系統開發的程序 • 產出高品質的系統 【START OF SUPPLEMENT】 第七章 資訊系統開發(一) 專案管理策略

10. 傳統的系統開發生命週期(SDLC) • 七個階段 • (1)規劃 (2)系統分析 (3)系統設計 • (4)開發 (5)測試 (6)建置 • (7)維護 • 通常要完成前一個階段才能繼續下一個階段 • 在後面的階段發生了問題，可能就要回到先前的階段 第七章 資訊系統開發(一) 專案管理策略

11. 系統開發生命週期 (SDLC) 第七章 資訊系統開發(一) 專案管理策略

12. 規劃 • 可行性分析 • 技術上– 現有的技術是否可以決解目前的問題 ? • 經濟上– 公司是否能夠承擔系統的成本，和這個系統是否能夠提供相當的投資報酬 ? • 操作上– 評估人對系統的適應能力 • 抗拒改變 • 政策上的分歧 • 時程– 確認系統的開發時程是否實際可行? 第七章 資訊系統開發(一) 專案管理策略

13. 系統分析 • 系統分析師會與公司的員工一同工作來徹底瞭解問題，並提出新資訊系統解決方案的需求 • 工具和技術 • 資料流程圖(DFD) • 從最高層的觀點來看組織 • 逐漸往下仔細查看 • 電腦輔助工程(CASE) • 簡化系統開發流程的軟體 第七章 資訊系統開發(一) 專案管理策略

14. Roy’s Pizza 的資料流程圖 第七章 資訊系統開發(一) 專案管理策略

15. 詳細的資料流程圖 接受訂單的詳細資料流程圖 第七章 資訊系統開發(一) 專案管理策略

16. 系統設計 • 詳細描述如何建立新系統 • 邏輯系統設計 • 詳細描述系統的功能 • 結構圖 – 顯示組成整個系統的模組的概觀和細節 • 實體系統設計 • 描述將會用來達到這些功能的實際元件 • 設計凍結 • 範圍蔓延 • 功能蔓延 第七章 資訊系統開發(一) 專案管理策略

17. 開發 • 程式設計的過程通常是最困難且最耗時的 • 公司可能選擇購買軟體或將程式設計的工作委外 • 流程圖通常用來表達程式的邏輯 第七章 資訊系統開發(一) 專案管理策略

18. 訂單輸入流程圖 第七章 資訊系統開發(一) 專案管理策略

19. 測試 • 程式設計師測試模組 – 模塊測試 • 開發的團隊測試所有模組在一起時是否能夠正常運作 –單元測試 • 系統測試 • 驗證 ： 在一個模擬的環境運行系統 • 確認 ： 系統在真實的環境中運作 第七章 資訊系統開發(一) 專案管理策略

20. 建置 • 資料轉換 • 使用者訓練 • 建置策略(方法) • 直接導入:公司快速地將舊系統換成新系統 • 平行轉換:讓新系統與舊系統一起運作。 • 領航測試:只將新系統安裝在某個部門或區域，俟通過測試之後，再將系統安裝在整個公司。 • 分期轉換:先建置新系統的部分，俟通過測試在安裝另一部分，直到整個系統安裝完成。 第七章 資訊系統開發(一) 專案管理策略

21. 維護 • 維護佔一個資訊系統總成本的 80% • 工作 • 修正建置時發現的錯誤 • 系統加強 • 漸進升級 • 增加主要的新功能 第七章 資訊系統開發(一) 專案管理策略

22. 傳統 SDLC 的問題 • SDLC 耗時 • SDLC 成本高 • SDLC 沒有彈性 • SDLC 只有在系統分析和建置階段有使用者參與 第七章 資訊系統開發(一) 專案管理策略

23. 其他系統開發方法 • 原型法(prototyping) • 共同應用開發 (JAD) • 快速應用開發 (RAD) • 物件導向分析與設計 (OOAD) 第七章 資訊系統開發(一) 專案管理策略

24. 原型法(prototyping) • 開發團隊可以快速去收集有限的使用者需求並建立一個可以運作的系統模型，叫做原型 • 使用者可以操作這個原型並回饋給開發團隊 • 開發團隊根據使用者的回饋來修改原型 • 流程會一直持續，直到使用者對系統滿意，或使用者和開發團隊得到這個系統是不可行的結論 • 最終的系統是由原型發展而來 第七章 資訊系統開發(一) 專案管理策略

25. 圖11.7 原型法流程 第七章 資訊系統開發(一) 專案管理策略

26. 共同應用開發 (JAD) • 共同應用開發 (joint application development，JAD) • 使用者與開發團隊一起開會，用來定義系統的需求和開發原型 • 花的時間比SDLC少 • 以幫助解決不同的使用者之間需求衝突的問題 • 使用者的參與度愈高，最後系統的接受度愈高 第七章 資訊系統開發(一) 專案管理策略

27. 快速應用開發 (RAD) • 快速應用開發(rapid application development, RAD) • 結合JAD、原型法和整合CASE (integrated CASE，ICASE)工具來描述系統開發所需時間的方法 • ICASE – 提供了程式碼產生器的功能 • 這個工具可以根據系統分析師的設計圖產生完整的程式 第七章 資訊系統開發(一) 專案管理策略

28. 物件導向分析與設計 (OOAD) • 物件導向分析與設計(object-oriented analysis and design, OOAD) • 物件取代流程 • OOAD 確認每個物件，還有物件的屬性和對應的程序 • 優點 • 減少系統開發的時間 • 可以開發出高品質的系統 第七章 資訊系統開發(一) 專案管理策略

29. 購買軟體 • 商用軟體(Commercial off-the-shelf，COTS) • 比較便宜 • 也許沒有包含所有所需的功能 • 使用商用軟體的 SDLC • 系統規劃 • 系統需求 • 提案需求 • 提案審查 • 建置 • 維護 }這就是不同的地方 第七章 資訊系統開發(一) 專案管理策略

30. 提案需求 (RFP) • 詳述新系統的需求，並邀請廠商提交計劃書 • 一般的 RFP 會包含這些部分 • 現有系統的概述 • 說明新系統所應包含的功能 • 提案審查的標準 • 預算限制 • 完工時程表 • 其它雜項資訊 第七章 資訊系統開發(一) 專案管理策略

31. 提案審查 公司收到多家廠商的計畫書之後，就要進行審查，不同公司有不同的提案審查的方法： • 特定需求：確保每一個提案都符合RFP中特定 的需求 • 實地示範 ：可能在自己公司或客戶公司 • 積分測試 ：用樣本資料來執行系統看看他的 效能的程序 第七章 資訊系統開發(一) 專案管理策略

32. 委外 • 將一個特定資訊科技功能交由外面的廠商來負責 • 優點 • 專家可以用較低的價格提供服務 • 在那個領域吸引優秀的人才 • 讓公司可以專心在本業上，而不是 IT 上 • 關鍵元件是服務等級協議 (SLA) 【 END OF SUPPLEMENT 】 第七章 資訊系統開發(一) 專案管理策略

33. 管理者的迷思 • 我們已經購買了最新、最先進的的電腦，也制定了標準的作業程序和規範手冊，該有的都有了，開發一個軟體系統應該是水到渠成的事 • 如果軟體系統的進度還是落後時，就增加幾個程式人員來幫忙，應該就可以趕上進度 • 如果開發軟體系統這麼麻煩，乾脆就外包算了，我們只要付錢就行，那些麻煩的事就由別人去煩惱好了 第七章 資訊系統開發(一) 專案管理策略

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

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

36. 系統開發的成敗因素p.7-9 • 系統的大小 • 系統上線的時程 • 預算的多寡 • 問題的應用領域 • 使用技術的難度 • 系統的限制 • 使用者的需求 • 可以使用資源的多寡 第七章 資訊系統開發(一) 專案管理策略

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

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

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

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

41. 開發軟體專案衡量指標的注意事項 • 當解釋專案衡量指標所代表的意義時，只要據實呈現就好，千萬不可以擴大解釋；一定要有足夠的組織敏感度，以免引發一些政治上的聯想 • 週期性的提供專案衡量指標給專案開發小組，千萬不可有時有、有時沒有；也不可以只評估某些小組、不評估其他小組。這樣都會遭致「對人不對事」的反彈 • 不要運用專案衡量指標來稱讚某一個成員的貢獻 (這應該是全體成員的績效)；也不要運用專案衡量指標來恐嚇某一個成員或整個小組的表現 (這會引發內部鬥爭或秋後算帳的聯想) 第七章 資訊系統開發(一) 專案管理策略

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

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

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

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

46. 軟體專案規劃的五個步驟--(分別說明於後) 第七章 資訊系統開發(一) 專案管理策略

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

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

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

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