【軟體工程】軟體工程知識點提綱8

• ​​1. 軟體規模的度量和估算​​

• ​​1.1 代碼行技術​​
• ​​1.2 功能點技術​​

• ​​2. 軟體工作量估算​​

• ​​2.1 分解技術​​
• ​​2.2 經驗模型​​

• ​​3. 工作量估算​​
• ​​4. 進度計劃​​

• ​​4.1 估算開發時間​​
• ​​4.2 Gantt圖​​
• ​​4.3 工程網絡​​
• ​​4.4 估算工程進度​​
• ​​4.5 關鍵路徑​​
• ​​4.6 機動時間​​

• ​​5. 軟體人員組織​​
• ​​6. 軟體品質保證​​
• ​​7. 軟體配置管理​​

1. 軟體規模的度量和估算

代碼行技術、功能點技術

1.1 代碼行技術

為了使得對程式規模的估計值更接近實際值,可以由多名有經驗的軟體工程師分别做出估計。

每個人都估計程式的最小規模（a）、最大規模（b）和最可能的規模（m），分别算出這3種規模的平均值a ̅、b ̅、和m ̅之後，再用下式計算程式規模的估計值：

L=(a ̅+b ̅+4m ̅)/6

1.2 功能點技術

• 資訊域特點

• 輸入項數（Inp）：使用者向軟體輸入的項數，這些輸入給軟體提供面向應用的資料。
• 輸出項數（Out）：軟體向使用者輸出的項數，它們向使用者提供面向應用的資訊。
• 查詢數（Inq）：查詢即是一次聯機輸入，它導緻軟體以聯機輸出方式産生某種即時響應。
• 主檔案數（Maf）：邏輯主檔案的數目。
• 外部接口數（Inf）：機器可讀的全部接口的數量，用這些接口把資訊傳送給另一個系統。

• 估算功能點的步驟

• 計算未調整的功能點數UFP

  首先，把産品資訊域的上述五個特性（Inp、Out、Inq、Maf和Inf）都分類為簡單級、平均級或複雜級，并根據其等級為每個特性配置設定一個功能點數（例如，一個簡單級的輸入項配置設定3個功能點，一個平均級的輸入項配置設定4個功能點，而一個複雜級的輸入項配置設定6個功能點）。

  UFP=a_1×Inp+a_2×Out+a_3×Inq+a_4×Maf+a_5×Inf



• 計算技術複雜性因子TCF

  影響因素的确定：根據軟體的特點，為每個因素配置設定一個從0（不存在或對軟體規模無影響）到5（有很大影響）的值。然後，用下式計算技術因素對軟體規模的綜合影響程度DI（其中F_i表示該技術因素的影響因素）：



• 技術複雜性因子TCF由下式計算：

  TCF=0.65+0.01×DI

  因為DI的值在0～70之間,是以TCF的值在0.65～1.35之間。

• 計算功能點數FP

  FP=UFP×TCF

2. 軟體工作量估算

分解技術、經驗模型

2.1 分解技術

縱向為分解子產品

橫向為交流、計劃、風險分析、設計、程式設計、測試等子產品，機關為人月

2.2 經驗模型

公式給出再進行計算

3. 工作量估算

• 靜态單變量模型

  E=A+B×（ev）^C

  A、B、C經驗資料導出的常數

  E以人月為機關的工作量

  ev估算變量（KLOC或FP）

  KLOC千行代碼數

• 面向KLOC的估算模型

• Walston_Felix模型

  E=5.2×（KLOC）^0.91

• Bailey_Basili模型

  E=5.5+0.73×（KLOC）^1.16

• Boehm簡單模型

  E=3.2×（KLOC）^1.05

• Doty模型（在KLOC>9時使用）

  E=5.288×（KLOC）^1.047

• 面向FP的估算模型

• Albrecht&Gaffney模型

  E=-13.39+0.0545EP

• Maston，Barnett和Mellichamp模型

  E=585.7+15.12EP

• 動态多變量模型

  E=（LOC×B0.333/P）3×（1/t）^4

  E以人月或人年為機關的工作量

  t以月或年為機關的項目持續時間

  B特殊技術因子：對于較小的程式KLOC=5~15，B=0.16；對于超過70KLOC的程式，B=0.39

  P是生産率參數：開發實時嵌入式軟體P=2000；開發電信系統和系統軟體P=10000；對于商用應用系統來說P=28000

• COCOMO2模型



• E開發工作量（以人月為機關）

  a是參數模型

  KLOC是估計的源代碼行數（以千行為機關）

  b是模型指數

  f_i （i=1~17）是成本因素

為了确定工作量方程中模型指數b的值，原始的COCOMO模型把軟體開發項目劃分成組織式、半獨立式和嵌入式這樣3種類型，并指定每種項目類型所對應的b值（分别是1.05，1.12和1.20）。COCOMO2采用了更加精細得多的b分級模型，這個模型使用5個分級因素W_i(1≤i≤5),其中每個因素都劃分成從甚低（W_i=5）到特高（W_i=0）的6個級别，然後用下式計算b的數值：

是以，b的取值範圍為1.01～1.26。

4. 進度計劃

4.1 估算開發時間

• Walston_Felix模型

  T=2.5E^0.35

• 原始的COCOMO模型

  T=2.5E^0.38

• COCOMO2模型

  T=3.0E^(0.33+0.2×（b-1.01）)

• Putnam模型

  T=2.4E^(1/3)

  E是開發工作量（以人月為機關）

  T是開發時間（以月為機關）

4.2 Gantt圖

例子：油漆工刷牆

首先刮掉舊漆，然後刷上新漆，最後清除濺在窗戶上的油漆。一共配置設定了15名勞工去完成這項工作，然而工具卻很有限：隻有5把刮舊漆用的刮闆，5把刷漆用的刷子，5把清除濺在窗戶上的油漆用的小刮刀。

思路：由5名勞工用刮闆刮掉第1面牆上的舊漆（這時其餘10名勞工休息），當第1面牆刮淨後，另外5名勞工立即用刷子給這面牆重新整理漆（與此同時拿刮闆的5名勞工轉去刮第2面牆上的舊漆），一旦刮舊漆的勞工轉到第3面牆而且重新整理漆的勞工轉到第2面牆以後，餘下的5名勞工立即拿起刮刀去清除濺在第1面牆窗戶上的油漆……。這樣安排使每個勞工都有活幹，是以能夠在較短的時間内完成任務。

假設木闆房的第2、4面牆的長度比第1、3面牆的長度長一倍，此外，不同工作需要用的時間長短也不同，重新整理漆最費時間，其次是刮舊漆，清理油漆需要的時間最少。下表列出了估計每道工序需要用的時間。可以使用Gantt圖描繪上述流水作業過程：

在時間為零時開始刮第1面牆上的舊漆，兩小時後刮舊漆的勞工轉去刮第2面牆，同時另5名勞工開始給，1面牆重新整理漆，每當給一面牆刷完新漆之後，第3組的5名勞工立即清除濺在這面牆窗戶上的漆。從下圖可以看出，12小時後刮完所有舊漆，20小時後完成所有牆壁的刷漆工作，再過2小時後清理工作結束。是以全部工程在22小時後結束，如果用前述的第一種做法，則需要36小時。

4.3 工程網絡

上圖事件2既是作業1—2（刮第1面牆上的舊漆）的結束，又是作業2—3（刮第2面牆上舊漆）和作業2—4（給第1面牆重新整理漆）的開始。也就是說，隻有第1面牆上的舊漆刮完之後，才能開始刮第2面牆上舊漆和給第1面牆重新整理漆這兩個作業。工程網絡顯式地表示了作業之間的依賴關系。

上圖中還有一些虛線箭頭，它們表示虛拟作業，也就是事實上并不存在的作業。例如，事件4既是給第1面牆重新整理漆結束，又是給第2面牆重新整理漆開始（作業4—6）。但是，在開始給第2面牆重新整理漆之前，不僅必須已經給第1面牆刷完了新漆，而且第2面牆上的舊漆也必須已經刮淨（事件3）。也就是說，在事件3和事件4之間有依賴關系，或者說在作業2—3（刮第2面牆上舊漆）和作業4—6（給第2面牆重新整理漆）之間有依賴關系，虛拟作業3—4明确地表示了這種依賴關系。注意，虛拟作業既不消耗資源也不需要時間。

4.4 估算工程進度

先将每個作業分成開始和結束，連接配接關系，以最大值依賴關系順序計算最早時刻，以最小值依賴關系逆序計算最遲時刻）

例：事件4的最早時刻：EET=max{2+3，6+0}=6

事件10的最遲時刻：LET=23-2=21

事件9的最遲時刻：LET=21-1=20

事件8的最遲時刻：LET=min{21-6，20-0}=15

4.5 關鍵路徑

事件的最早時刻和最遲時刻相同

4.6 機動時間

動機時間=（LET）_結束-（EET）_開始-持續時間

5. 軟體人員組織

• 民主制程式員組（非正式的組織方式）

  小組成員完全平等，享有充分民主，通過協商做出技術決策。小組成員之間的通信是平行的，若小組内有n個成員﹐則可能的通信信道共有n（n-1）/2條。程式設計小組的人數不能太多，否則組員間彼此通信的時間将多于程式設計時間。優點：組員們對發現程式錯誤持積極的态度，這種态度有助于更快速地發現錯誤，進而導緻高品質的代碼；組員們享有充分民主，小組有高度凝聚力，組内學術空氣濃厚，有利于攻克技術難關。

• 主程式員組

  因為軟體開發人員多數比較缺乏經驗；程式設計過程中有許多事務性的工作，例如，大量資訊的存儲和更新；多管道通信很費時間，将降低程式員的生産率。

• 現代程式員

6. 軟體品質保證

• 軟體品質：與軟體産品滿足規定的和隐含的需求的能力有關的特征或特性的全體。

• 功能與性能方面：軟體應該能夠按照既定的要求進行工作，與明确規定的功能和性能需求一緻；軟體要保證能夠可靠的工作，合法的輸入下正确運作，非法輸入和意外事件可安全處理。
• 軟體結構方面：

• 要求系統内部結構清晰，易于軟體人員閱讀和了解，友善對軟體的修改和維護
• 要求系統具備良好的人機互動界面，友善使用者使用

• 開發标準與文檔方面：軟體開發應該與明确成文的開發标準相一緻，而且要遵循一些軟體開發準則，軟體文檔資料也必須齊全。

• 軟體品質保證

• 應用技術手段：軟體品質保證活動開始于幫助分析員獲得高品質的規格說明書，幫助設計員應用高效的技術方法和工具，并且始終貫穿整個開發過程。
• 組織技術評審：在軟體開發過程的每個階段結束後，都需要組織技術評審，可以及早發現軟體開發過程中可能引起的潛在錯誤，并對品質進行評價。
• 加強軟體測試：軟體測試是軟體品質保證的重要手段，可以發現軟體中大多數隐蔽的錯誤。
• 推行軟體工程标準：一旦标準确定，就應該重視标準，并在軟體開發中統一遵循。
• 控制軟體變更：軟體品質的一個主要威脅來自于對軟體的修改和變更。在修改的過程中常常會引起一些新的潛在錯誤。是以，應嚴格控制軟體的修改和變更。
• 對軟體品質進行度量：軟體品質保證的一個重要目标也是對軟體品質進行跟蹤，這就需要對軟體品質進行度量，并對軟體品質情況及時記錄和報告。

7. 軟體配置管理

• 軟體配置

• 軟體配置項
• 基線

• 軟體配置管理過程

• 辨別軟體配置中的對象
• 版本控制
• 變化控制
• 配置審計
• 狀态報告