1、 Software EngineeringCCUTSE2021軟件工程導論第4篇 軟件工程管理1.估算軟件規模2.任務量估算3.進度方案4.人員組織5.質量保證6.才干成熟度模型7.軟件配置管理8.才干成熟度模型主要內容導言俗話說“三分技術，七分管理俗話說“吃不窮穿不窮算計不到就受窮俗話說“巧婦難為無米之炊軟件工程 包括技術和管理兩方面的內容，是技術與管理嚴密結合所構成的工程學科。導言軟件工程目的技術管理俗話說“三分技術，七分管理工程與工程 工程：是類，是總稱， 工程：是對象，是實例，是一個詳細的工程。導言工程工程軟件工程管理貫穿于軟件的整個生命周期導言軟件工程管理什么是管理managemen

2、t? 管理就是經過方案、組織和控制等一系列活動，合理地配置和運用資源，到達既定目的的過程。導言方案組織控制過程資源合理運用與配置效率質量軟件工程管理的內容導言時間管理人員管理配置管理質量管理工程的時間管理導言估算任務量軟件需求KLOCFP估算規模人月估算進度GanttPert模型模型模型工程的人員管理導言民主制程序員組主程序員組現代程序員組工程的質量管理導言產品轉移產品運轉產品修正SQA小組方案監視記錄分析報告活動措施基于非執行的測試基于執行的測試程序正確性證明軟件的配置管理導言數據程序文檔軟件配置項變化管理標識變化版本控制變化控制報告配置審計才干成熟度模型：評價軟件機構的軟件過程才干成熟度的

3、模型。導言才干成熟度模型：評價軟件機構的軟件過程才干成熟度的模型。導言才干成熟度模型：評價軟件機構的軟件過程才干成熟度的模型。導言才干成熟度模型：評價軟件機構的軟件過程才干成熟度的模型。導言才干成熟度模型：評價軟件機構的軟件過程才干成熟度的模型。導言1.代碼行KLOC/LOC技術11.1 估計軟件規模出發點：根據以往開發類似產品的閱歷和歷史數據。L=6a + 4m + b-加權平均法：多名有閱歷的軟件工程師每人都估計程序的最小規模(a、最大規模b和最能夠的規模(m)，分別計算出這3中規模的平均值a,b和m之后，計算L。-1.代碼行KLOC/LOC技術11.1 估計軟件規模L=6a + 4m +

4、 b-工程師abm唐 僧111312孫悟空101311沙 僧91210豬八戒131714白龍馬121513均值111412=611+414+12=13.171.代碼行KLOC/LOC技術11.1 估計軟件規模優點：代碼是一切軟件工程的產品，且代碼行易于計算。缺陷：1代碼僅是軟件配置的成分之一，用代碼行表示軟件規模不盡合理； 2用不同言語實現一致軟件，代碼行數并不一樣。2.功能點FP技術11.1 估計軟件規模抑制代碼行技術的缺陷；根據軟件信息域特性和軟件復雜性的評測結果。用功能點FP為單位度量軟件規模。2.功能點FP技術11.1 估計軟件規模1信息域特性輸入項數Inp輸出項數Out查詢數Inq主

5、文件數Maf外部接口數Maf信息域2.功能點FP技術11.1 估計軟件規模1信息域特性輸入項數(Inp):用戶向軟件輸入的項數，這些輸入給軟件提供面向運用的數據,不包括查詢。輸出項數(Out):查詢數主文件數外部接口數2.功能點FP技術11.1 估計軟件規模2估算功能點的步驟計算未調整的功能點UFP計算技術復雜性因子TCF計算功能點數FP2.功能點FP技術11.1 估計軟件規模2估算功能點的步驟計算未調整的功能點UFPUFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf 復雜級別 特性系數簡單平均復雜輸入系數a1346輸出系數a2457查詢系數a3346文件系數a471015接口

6、系數a557102.功能點FP技術13.1 估計軟件規模2估算功能點的步驟計算技術復雜性因子TCF確定技術要素對軟件規模的影響值F1F14； 0Fi 5計算技術要素對軟件規模的綜合影響程度DI；DI= Fi計算技術復雜性因子TCF。 TCF=0.65+0.01DIi=1142.功能點FP技術11.1 估計軟件規模2估算功能點的步驟序號Fi技術因素1F1數據通信2F2分布式數據處理3F3性能標準4F4高負荷的硬件5F5高處理率6F6聯機數據輸入7F7終端用戶效率序號Fi技術因素8F8聯機更新9F9復雜的計算10F10可重用性11F11安裝方便12F12操作方便13F13可移植性14F14可維護性

7、技術要素計算技術復雜性因子TCF2.功能點FP技術11.1 估計軟件規模2估算功能點的步驟計算功能點數FPFP=UFPTCF2.功能點FP技術11.1 估計軟件規模3FP技術的優缺陷 優點：與編程言語無關，比代碼行技術更加合理； 缺陷：在判別信息與特性復雜級別和技術要素的影響度 時，客觀性較大。11.2 任務量估計任務量單位：人月pm。任務量估算：是估算而不是計算，由于是事先而不是事后。任務量模型:是閱歷公式，是KLOC或FP的函數。 模型類別:靜態模型 動態模型 構造模型11.2 任務量估計1.靜態單變量模型 E=A+B(ev)C其中：E:任務量A,B,C：閱歷常數ev:估算變量KLOC或F

8、P總體構造方式11.2 任務量估計1.靜態單變量模型Walston_Felix模型： E=5.2(KLOC)0.911面向KLOC的估算模型Bailey_Basili模型： E=5.5+0.73(KLOC)1.16Boehm簡單模型： E=3.2(KLOC)1.05 Doty模型(KLOC9時)：E=5.288(KLOC)1.04711.2 任務量估計1.靜態單變量模型Albrecht&Gaffney模型： E=-13.39+0.0545FP2面向FP的估算模型Maston,Barnett和Mellichamp模型： E=5.587+15.12FP11.2 任務量估計1.靜態單變量模型 對于一

9、樣的KLOC或FP用不同的模型得到的結果不同，這是由于模型閱歷來自于有限領域和有限工程，進而適用范圍有限，因此實踐運用時應適當調整模型如，修正常數。3靜態單變量模型的評價11.2 任務量估計2.動態多變量模型 E=(LOCB0.333/P)3(1/t)4 其中E是任務量；t是工程繼續時間；B是特殊技術因子，當KLOC=515時B=0.16，當KLOC70時B=0.39；P是消費率參數，P=2000嵌入式軟件，P=10000電信系統/系統軟件，P=28000商業運用系統。1總體構造方式11.2 任務量估計2.動態多變量模型是軟件規模和開發時間的函數；開發一致軟件時，延伸工程繼續時間可降低完成工程

10、所需的任務量。2模型評價11.2 任務量估計3.構造性本錢模型：COCOMO2模型運用系統組成模型：估算構建原型的任務量；早期設計模型：適用于體系構造設計階段；后體系構造模型：適用于體系構造設計之后的開發階段。1模型層次11.2 任務量估計3.構造性本錢模型：COCOMO2模型2后體系構造模型其中：E是任務量a是模型系數b是模型指數fi是本錢要素 E=aKLOCbfii=11711.3 進度方案1.估算開發時間2.Gantt圖3.工程網絡4.估算工程進度5.關鍵途徑6.機動時間12 人員組織1.民主制程序員組2.主程序員組3.現代程序員組民主制程序員組主程序員組現代程序員組12人員組織1.民主

11、制程序員組特點：位置平等，充分民主，協商決策。通訊途徑：n(n-1)/2規模：較小，2-8人為宜優點：積極面對程序錯誤，質量較高； 充分民主，凝聚力高，利于攻關； 適用于成員閱歷均豐富時。缺陷：成員閱歷均不豐富，缺乏協調，導 致失敗。12 人員組織2.主程序員組主程序員編程秘書后備程序員程序員程序員程序員12 人員組織2.主程序員組主程序員編程秘書后備程序員程序員程序員程序員產生背景：IBM公司20世紀70年代初期發明。1軟件開發人員多數比較缺乏閱歷；2程序設計過程中有許多事物性任務，如信息存儲和更新；3多渠道通訊很費時間，將降低程序員的消費率。12 人員組織2.主程序員組主程序員編程秘書后備

12、程序員程序員程序員程序員特性：(1)專業化：該組每名成員僅完成他們受過專業訓練的哪些任務。(2)層次化：主程序員指揮沒命組員任務，并對任務全面擔任。12人員組織2.主程序員組主程序員編程秘書后備程序員程序員程序員程序員分工：(1)主程序員：體系構造設計、關鍵部分詳細設計，技術指點。(2)后備程序員：協助主程序員，必要時接替主程序員。(3)編程秘書：擔任事務性任務。12 人員組織2.主程序員組主程序員編程秘書后備程序員程序員程序員程序員缺陷：(1)主程序員：是高級程序員和優秀管理者的結合體，難找。(2)后備程序員：期望與主程序員一樣優秀，難找。(3)編程秘書：專業人員膩煩事務任務，難找。12 人

13、員組織3.現代程序員組技術組長行政組長程序員程序員程序員1現代程序員組的構造技術管理非技術管理12 人員組織3.現代程序員組程序員程序員程序員2大型工程的技術管理組織構造技術管理組長程序員程序員程序員程序員程序員組長組長工程經理12 人員組織3.現代程序員組程序員程序員程序員3包含分散決策的組織方式技術管理組長程序員程序員程序員程序員程序員組長組長工程經理工程的質量管理12 質量保證產品轉移產品運轉產品修正SQA小組方案監視記錄分析報告活動措施基于非執行的測試基于執行的測試程序正確性證明12 質量保證1.何謂軟件質量？定義：軟件與明確地和隱含地定義的需求相一致的程度。明確地表達的功能和性能需求

14、、文檔中明確描畫的開發規范。任何專業開發的軟件產品都應該具有的隱含特征。12 質量保證1.何謂軟件質量？定義：軟件與明確地和隱含地定義的需求相一致的程度。要點：1與需求不一致就是質量不高。 2沒有遵守開發準那么會導致質量不高。 3不滿足隱含的需求，質量依然是值得疑心的。13質量保證1.何謂軟件質量？軟件質量要素與產品活動的關系產品轉移產品運轉產品修正正確性它按我的需求任務嗎？強壯性對不測環境它能適當地呼應嗎？效率 完成預定功能時它需求的計算機資源多嗎？完好性它是平安的嗎？可用性我能運用它嗎？風險 能按方案完成它嗎？可了解性我能了解它嗎？可維修性我能修復它嗎？靈敏性 我能改動它嗎？可測試性我能測

15、試它嗎？可移植性(我能在另一臺機器上運用它嗎？)可再用性(我能再用它的某些部分嗎？互運轉性(我能把它和另一個系統結合嗎？)13 質量保證2.軟件質量保證措施產品轉移產品運轉產品修正措施基于非執行的測試 也稱為復審或評審：用來保證在編碼之前各階段產生的文檔的質量。基于執行的測試 在程序編寫出來之后保證軟件質量的最后一道防線。程序正確性證明 運用數學方法嚴厲驗證程序能否與它闡明的完全一致。13 質量保證2.軟件質量保證措施(人員)產品轉移產品運轉產品修正軟件工程師 采用先進的方法和度量，進展正式的技術復審以及完成方案縝密的軟件測試來保證軟件質量。SQA小組 經過方案、監視、記錄、分析和報告等活動，

16、輔助軟件工程師，經過確保軟件過程的質量來保證軟件產品的質量。軟件工程師SQA小組13質量保證2.軟件質量保證措施(技術復審)(1)技術復審=走查(walkthrough)+審查(inspection)(2)技術復審的必要性 可以較早發現軟件錯誤，從而防止錯誤傳播到軟件過程的后續階段。4030%其它錯誤6070%規格闡明或設計錯誤復審發現規格闡明或設計錯誤的75%13 質量保證2.軟件質量保證措施(技術復審)(3)走查小組：46人組成走查方式：參與驅動法：參與者按照事先預備好的列表，提出他們不了解的術語和以為不正確的術語。文檔編寫組的代表必需回答每個質疑，要么成認確實有錯誤，要么對質疑作出解釋。

17、 文檔驅動法。文檔編寫者向走查組成員仔細解釋文檔。走查組成員在此過程中針對問題進展質疑。這是更有效的方法13 質量保證2.軟件質量保證措施(技術復審)(4)審查 小組：4人組成綜述預備審查返工跟蹤文檔編寫者綜述文檔評審員仔細閱讀文檔評審組仔細走查文檔確保問題處理文檔作者處理問題13 質量保證2.軟件質量保證措施(技術復審)(5)程序正確性證明 測試只能證明程序中有錯誤，不能證明程序中沒有錯誤。 假設在程序中的假設干點上，設計者可以提出關于程序變量及它們的關系的斷言，那么在每一點上的斷言都應該永遠是真的。13 質量保證2.軟件質量保證措施(技術復審)(5)程序正確性證明P1P2PiPnPi+1a

18、1a2ai+1anai語句斷言輸出斷言輸入斷言aiai+1假設a1和an都是正確的且那么PiPi+1是正確的從而一切語句是正確的13軟件配置管理變化容易失控，一旦失控呵斥混亂或嚴重錯誤管理整個生命周期的變化在軟件開發的過程中，變化或稱變動既是必要的，又是不可防止的軟件配置管理 軟件配置管理是在軟件的整個生命周期內管理變化的一組活動。詳細地說這組活動用來：1標識變化2控制變化3確保適當地實現了變化4想需求知道這類信息的人報告變化。軟件配置管理貫穿于軟件的整個生命周期13.6 軟件配置管理軟件配置管理軟件配置管理的目的 使變化更正確且更容易被順應，在必需變化時減少所需破費的任務量。13.6 軟件配置管理軟件的配置項13.6 軟件配置管理數據程序文檔軟件配置項計算機程序源代碼和可執行程序描畫計算機程序的文檔供技術人員或用戶運用數據程序內包含的或在程序外的基線Base line13.6 軟件配置管理數據程序文檔軟件配置項數據程序文檔軟件配置項基線正式復審可以迅速而非正式修正 必需用特定的、正式的過程來 評價、實現和驗證每個變化軟件配置管理過程13.6 軟件配置管理標識變化版