1 / 64

Software Project Estimation

Software Project Estimation. 為什麼要做軟體估計 ?. 低估了軟體開發及導入的成本。 不同的估算法所得結果差異非常大。 低價搶標策略使得軟體成本的問題更加嚴重。 影響軟體成本的因素很多，精確的估算並不容易. Five levels of CMM. Initial (1) Managed (2) Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management

dotty
Télécharger la présentation

Software Project Estimation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Project Estimation

  2. 為什麼要做軟體估計? • 低估了軟體開發及導入的成本。 • 不同的估算法所得結果差異非常大。 • 低價搶標策略使得軟體成本的問題更加嚴重。 • 影響軟體成本的因素很多，精確的估算並不容易

  3. Five levels of CMM • Initial (1) • Managed (2) • Requirements Management • Project Planning • Project Monitoring and Control • Supplier Agreement Management • Measurement and Analysis • Process and Product Quality Assurance • Configuration Management • Defined (3) • Quantitatively Managed (4) • Optimizing (5)

  4. Project Planning • SG1 Establish Estimates • SP 1.1 Estimate the Scope of the Project • SP 1.2 Establish Estimates of Work Product and Task Attributes • SP 1.3 Define Project Life Cycle • SP 1.4 Determine Estimates of Effort and Cost • SG 2 Develop a Project Plan • SP 2.1 Establish the Budget and Schedule • SP 2.2 Identify Project Risks • SP 2.3 Plan for Data Management • SP 2.4 Plan for Project Resources • SP 2.5 Plan for Needed Knowledge and Skills • SP 2.6 Plan Stakeholder Involvement • SP 2.7 Establish the Project Plan

  5. 軟體成本影響因素 • 影響軟體開發成本的因素稱為成本因子。這些因子可以歸納成七類屬性，有助於思考成本的來源與模式的建立 • 規模屬性 • 產品屬性 • 資訊科技屬性 • 人員屬性 • 專案屬性 • 環境屬性 • 管理屬性 (林信惠, 1993)

  6. 規模屬性 • 原始碼的行數 • 子程式的數目 • 功能點 • 資料項目的數目 • 文件的頁數

  7. 產品屬性 • 軟體類型 • 軟體複雜度 • 使用的程式語言 • 要求的品質與可靠度 • 再用碼的數量 • 處理時間的限制

  8. 資訊科技屬性 • 硬體架構 • 網路架構 • 軟體平台 • 中央處理器、記憶體及通訊的限制 • 使用資訊科技的成熟度

  9. 人員屬性 • 開發者的一般能力與學習能力 • 開發者的經驗 • 類似專案與開發環境的經驗 • 專案經理的經驗

  10. 專案屬性 • 使用方法與工具 • 需求明確的程度 • 和顧客的溝通與關係 • 開發時程的緊迫性 • 專案組織的大小 • 預算充裕的程度

  11. 環境屬性 • 行政複雜度 • 使用者參與程度 • 需求變更的頻繁程度 • 市場競爭的程度

  12. 管理屬性 • 專案管理者的領導能力與經驗 • 團隊合作 • 資源分配 • 時程安排與控制 • 訓練 • 品質保證

  13. 軟體成本的分類 • 生命週期成本分類 • 成本會計分類

  14. 生命週期成本分類 • 生命週期成本分為開發成本和維護成本。依Putnam (1978)模式，開發成本約占45%；維護成本約占55%。 • 更詳細的分類則可依生命週期的需求分析、設計、編碼、整合測試及維護各階段所占的成本百分比 • 除了開發與維護成本外，一些重要的作業也應細估其成本： • 轉換成本。 • 裝置成本。 • 訓練成本。 • 其他成本。

  15. 成本會計分類 • 直接成本 • 系統開發人員的成本，包括系統分析師、程式設計師、專案經理及其他直接參與專案開發的人員。 • 設備成本 • 硬體、軟體、辦公設備及其他設施的成本。 • 費用 • 旅費、顧問費、訓練費用等。 • 分攤費用 • 行政人員費用、水電費、辦公用品費用、保險費、管理費等。

  16. 軟體成本估計的過程 • 軟體成本估計是一個估計的過程，由一開始非常粗略的估計慢慢深入，直到對所估計的系統有相當信心為止。

  17. 提出構想 • 粗略的成本估計與資料蒐集 • 專家判斷法 • 由上往下法 管理者依經驗與判斷評估可行性及成本效益 方案可行且 效益大於成本？ N 取消構想 Y 由專家小組分析需求並分解系統功能 • 正式估計成本 • 由下往上法 • 參數法 • 類比法 軟體成本估計過程

  18. 專案核准？ N 取消專案 細部設計、編碼、測試 Y 調整及控制成本 進行詳細的需求分析 與初步設計 Y 修改估計的成本 結束 N N 成本太高？ 取消專案？ Y 調整預算或調整專案功能 軟體成本估計過程

  19. 軟體成本估計的方法 • Boehm(1984) • 演算模式 • 專家判斷法 • 類比法 • 由上往下法 • 由下往上法 • 巴金森法(Parkinson Method) –多少預算做多少事 • 勝算價格法 (Price-to-Win Method) –以可獲得合約的價格為基礎 • Mohanty(1981) • 歷史資料模式 • 統計分析模式 • 理論模式 • 多種方法相互驗證

  20. 專家判斷法 • 專家判斷法是依賴一個或多個專家的經驗來做估計。 • 專家判斷適用於專案的早期，當需求仍不甚明確時。在引進新科技或新方法時，因為沒有歷史資料，所以也要借助於專家判斷。 • 專家判斷法仍是目前最廣為應用的方法。

  21. 專家群體決策判斷法 • 多估計值的綜合方法： • 平均法 • 去除極值平均法 • 中位數法 • 三點估計法(每位專家分別估計三個值) • 德菲法 - Delphi method (無經驗時) • 群體決策用來達成共識的方法，使用匿名會議，經過數回合評估，每回合評估將彙總資料公佈，希望去除極值並減少估計者受權威人士的影響。

  22. 找一個已完成且類似的專案 將目標專案及已完成專案的 功能分解成子功能 找出要修改、刪除及新增的模組 估計修改、刪除及新增模組 所需的成本 依環境的改變、技術、需求、人事成本及風險等加以調整 類比法 看起來相似可能存在大的誤差

  23. 參數模式 • 參數模式(Parametric Models) • 參數模式又稱演算法則模式或統計模式，這些模式的基本概念是軟體的開發成本為軟體規模和調整因子的函數。 • 軟體規模的單位為原始碼的行數或功能點；調整因子則是影響軟體開發成本的因素。函數的型式可為線性或非線性。參數估計模式可為下列的型式。

  24. 參數模式 成本＝常數＋軟體規模之成本函數 × 調整因子 　或 成本＝常數＋軟體規模之成本函數＋調整因子 若以數學式表示則為： C：估計成本；以人-月或人-天為單位 s：軟體規模；以程式行數或功能點為單位 f：規模函數 x：調整因子的向量；x=(x1, x2, …, xn) g：調整函數 C0：常數

  25. 規模函數 • 規模函數 f 可為線性規模函數或非線性規模函數式中的係數 a 和 b 為統計迴歸分析所得的結果。 • f(s)＝a．s　 （線性規劃函數） • f(s)＝aSb（非線性規劃函數）

  26. 調整函數 • 調整函數 g(x) 則為個別調整因子函數值 gi(xi)的總和或乘績，亦即：

  27. 參數模式 - Farr and Zagorski模式 • Farr and Zagorski 模式 (1965) • 此模式為一簡單的加法模式，可以寫成： • 其中C0 ＝－188，a＝2.68 • 成本因子及其係數如下表

  28. 值 成本因子 單位 2.68 2.3 33 －17 10 1 指令數 旅行哩數 文件數 系統程式師經歷 螢幕畫面數 新碼的百分比 千行 千哩 實際數 年 實際數 百分比 Farr 與 Zagorski 的成本因子及係數

  29. COCOMO 模式 • COCOMO模式 • 此模式為一非線性的模式，其型式如下： • COCOMO模式可分為三個估計的詳細程度： • 基本模式：是一種粗略的估計。 • 中級模式：考慮15項的成本調整因子。 • 詳細模式：將成本因子的權重依開發階段來劃分。 Note: C (effort) 單位為 人月 S 單位為 KDSI - Thousands (K) of Deliverable Source Instructions (KDSI).

  30. COCOMO 模式 • 軟體複雜度的分類 • 簡單型 • 小型、簡單、低複雜度、低風險，開發團隊對所開發之專案有豐富的經驗且需求定義明確。 • 中間形 • 中等規模、中等複雜度的專案。 • 複雜型 • 高複雜度、限制嚴格的專案。例如整合性系統、高品質、高可靠度要求、及重要任務系統。

  31. 基本模式 中級模式 詳細模式 模式 類型 a b a b a b 簡單型 2.4 1.05 3.2 1.05 3.2 1.05 中間型 3.0 1.12 3.0 1.12 3.0 1.12 複雜型 3.6 1.20 2.8 1.20 2.8 1.20 COCOMO基本模式 • 基本模式 • 基本模式依下列公式估計成本： • a 和 b 的係數如下表所示

  32. Total Development time months

  33. COCOMO中級模式 • 中級模式 • 中級模式依下列公式估計成本： • 和基本模式不同的是它考慮了十五個調整因子。

  34. 等　　　　級 成本因子 很低 低 中等 高 很高 超高 產品屬性 .75 .88 1.00 1.15 1.40 軟體可靠度的需求 .94 1.00 1.08 1.16 資料庫大小 .70 .85 1.00 1.15 1.30 1.65 產品複雜度 電腦屬性 1.00 1.11 1.30 1.66 執行時間的限制 1.00 1.06 1.21 1.56 主記憶體的限制 .87 1.00 1.15 1.30 系統軟體 (OS 、 DBMS 等 ) 的更換 .87 1.00 1.07 1.15 電腦停機時間 人員屬性 1.46 1.19 1.00 .86 .71 分析師的能力 1.29 1.13 1.00 .91 .82 工作經驗 1.42 1.17 1.00 .86 .70 程式設計師的能力 1.21 1.10 1.00 .90 相關系統軟體的經驗 1.14 1.07 1.00 .95 程式語言的經驗 專案屬性 1.24 1.1 0 1.00 .91 .82 使用新的規劃方法 1.24 1.10 1.00 .91 .83 使用軟體工具 1.23 1.08 1.00 1.04 1.10 開發時程的需求 COCOMO 調整因子乘數

  35. COCOMO 詳細模式 • 詳細模式 • 詳細模式將調整乘數再分配到各個不同的開發階段，例如，程式設計師的能力若被評為非常低時，依上表其調整乘數為1.42，將此乘數分配到四個開發階段的結果如下：

  36. Phase Effort Distribution Note: KDSI - Thousands (K) of Deliverable Source Instructions (KDSI).

  37. Reference for COCOMO 模式 • Software Estimating - Basic Time & Cost, CASG Journal, Allen (1995)

  38. COCOMO II • 以調整指數 E 取代簡單、中間、及複雜型等軟體複雜程度 Note: 調整因子分別代表 (1) 先前經驗 (2) 需求與時程的彈性 (3) 系統架構與風險 (4) 團隊凝聚力 (5) 成熟度 (CMMI)

  39. COCOMO II • 三階段法取代基本、中級、以及詳細模式 • 第一階段-Application Composition Model: • 以 object-point 估計軟體規模 • 以軟體規模轉換為人-月為單位成本 • 適用於物件組成軟體，如多媒體應用 • 第二階段-Early Design Model: • 以功能點來估計軟體規模 • 依功能點轉換位為原始碼行數(S) • 七個調整因子修正

  40. COCOMO II • 第三階段-Post Architecture Model: • 同第二階段資料 • 七個調整因子變為十七個

  41. 功能點分析法(Function Point Analysis) • 不論導入CMM或CMMI制度Leve l，2 中皆有一項重要的工作為專案預估(Project Estimation)。目前國際上常使用的方法為IFPUG(Internal Function Point User Group)所發展之功能點分析法(Function Point Analysis)，此方法能有效度量軟體專案規模(SIZE)進而估算出軟體專案所需成本，可以有效協助專案估價、成本監控、度量分析等專案後續作業。 • 功能點分析法為一種系統化分析與度量專案開發階段之成本，且能依據組織之專案特性持續改善預估準確度的一種方法。

  42. 功能點分析方法之演進 • 功能點分析法（Function Point Analysis）最早是在1970 年代，由IBM 一位工程師Allan Albrecht 開始發展度量軟體專案規模之觀念。經過了數年的研究，Albrecht 發展出最初的Function Point 版本提供給IBM 內部使用，並於1984 年發表IBM CIS & A Guideline 313 AD/M Productivity Measurement and Estimate Validation 概念文件。直到1988 年由於使用者眾多而產生了一個非營利的IFPUG (The International Function Point Users Group）組織的成立，並逐年成長，發展成為目前世界上最大的軟體預估相關機構組織之一。目前最新的版本為IFPUG 在2000 年4 月發表的Function Point Counting Practice Manual Release 4.1.1。 • ISO/IEC 20926:2003 Software engineering

  43. 功能點分析方法之演進

  44. 使用者觀點(User View) 與功能分類 • 功能點分析方法強調由使用者觀點(User View)估算所開發之軟體系統功能性並量化成功能點數(Function Points)，而並不是由技術觀點(Technical View)分析系統之功能。 • 所謂使用觀點為採用使用者的語言來描述使用者的功能需求，而系統開發人員依據使用者功能需求提供解決方案並使用資訊技術翻譯使用者功能需求，不是站在開發人員角度與使用技術觀點分析量化系統規模大小。 • 實務上導入初期時許多人員因觀念不清處而以技術觀點使用本分析方法，所以會對本方法產生許多質疑，如系統中有多複雜之特殊模組、副程式或使用最新之語言技術皆為由技術觀點估算系統規模。

  45. 使用者觀點的功能型態 • 資料功能類(Data Function Type) • 內部邏輯檔案(Internal Logical File) • 外部介面檔案(External Interface File) • 交易功能類(Transaction Function Type) • 外部輸入檔案(External Input File) • 外部輸出檔案(External Output File) • 外部查詢檔案(External Inquire File)

  46. Internal Logical Files • The first data function allows users to utilize data they are responsible for maintaining. For example, a pilot may enter navigational data through a display in the cockpit prior to departure. The data is stored in a file for use and can be modified during the mission. Therefore the pilot is responsible for maintaining the file that contains the navigational information. Logical groupings of data in a system, maintained by an end user, are referred to as Internal Logical Files (ILF).

  47. External Interface Files • The second Data Function a system provides an end user is also related to logical groupings of data. In this case the user is not responsible for maintaining the data. The data resides in another system and is maintained by another user or system. The user of the system being counted requires this data for reference purposes only. For example, it may be necessary for a pilot to reference position data from a satellite or ground-based facility during flight. The pilot does not have the responsibility for updating data at these sites but must reference it during the flight. Groupings of data from another system that are used only for reference purposes are defined as External Interface Files (EIF).

  48. External Input • The first Transactional Function allows a user to maintain Internal Logical Files (ILFs) through the ability to add, change and delete the data. For example, a pilot can add, change and delete navigational information prior to and during the mission. In this case the pilot is utilizing a transaction referred to as an External Input (EI). An External Input gives the user the capability to maintain the data in ILF's through adding, changing and deleting its contents.

  49. External Output • The next Transactional Function gives the user the ability to produce outputs. For example a pilot has the ability to separately display ground speed, true air speed and calibrated air speed. The results displayed are derived using data that is maintained and data that is referenced. In function point terminology the resulting display is called an External Output (EO).

  50. External Inquiries • The final capability provided to users through a computerized system addresses the requirement to select and display specific data from files. To accomplish this a user inputs selection information that is used to retrieve data that meets the specific criteria. In this situation there is no manipulation of the data. It is a direct retrieval of information contained on the files. For example if a pilot displays terrain clearance data that was previously set, the resulting output is the direct retrieval of stored information. These transactions are referred to as External Inquiries (EQ).

More Related