軟件工程管理課件

第9章軟件工程管理軟件工程管理概述軟件規(guī)模估算進度計劃人員組織軟件配置管理軟件質量保證軟件工程標準與軟件文檔第9章軟件工程管理1軟件工程管理概述1.軟件產品的特點軟件是邏輯產品，具有高度的抽象性同一功能的軟件可以有多樣性軟件生產過程復雜，具有易錯性軟件開發(fā)與維護主要是根據(jù)用戶需求“定制”的，其過程具有復雜性和易變性軟件的開發(fā)和運行經(jīng)常受到計算機系統(tǒng)環(huán)境的限制，因而軟件有安全性和可移植性等問題軟件生產有許多新技術需要軟件工程師進一步研究和實踐軟件工程管理概述1.軟件產品的特點22.軟件工程管理的重要性分階段管理策略涉及多學科軟件規(guī)模不斷增大，管理難度增加，管理不善的后果嚴重2.軟件工程管理的重要性33.軟件工程管理的內容包括對軟件開發(fā)成本、控制、開發(fā)人員、組織機構、用戶、軟件開發(fā)文檔、軟件質量等方面的管理。3.軟件工程管理的內容4軟件規(guī)模和開發(fā)工作量估算面向規(guī)模的度量（代碼行技術）面向功能的度量（功能點技術）CoCoMo模型軟件規(guī)模和開發(fā)工作量估算5軟件項目估算估算涉及到人、技術、環(huán)境、政策等多種因素，很難精確地估算出項目的開銷。常用四種估算方法參照已有類似項目估計待開發(fā)項目成本和工作量將大的項目分解成若干子項目，分別估算出子項目成本和工作量，再估算整個項目按軟件的生命期分別估算各階段的工作量和成本，再匯總，從而估算出整個項目根據(jù)實驗或歷史數(shù)據(jù)給出軟件項目工作量或成本的經(jīng)驗公式軟件項目代碼行和功能點估算是成本和工作量估算的基礎。（規(guī)模）LOC或FP的期望值：e=（a+4m+b)/6軟件項目估算估算涉及到人、技術、環(huán)境、政策等多種因素，很難精6代碼行技術用軟件項目的代碼行（LOC）數(shù)表示軟件項目的規(guī)模生產率P=L/E，E是軟件項目的工作量，用人月（PM）度量，L用千行代碼kLOC度量每行代碼的平均成本C=S/L，S是軟件項目總的開銷文檔與代碼比D=Pd/L，Pd是軟件項目的文檔頁數(shù)代碼出錯率EQR=Ne/L，Ne是軟件項目的代碼錯誤數(shù)代碼行技術7例：下表提供了一個國外典型的軟件項目記錄利用這些數(shù)據(jù)，可以求出：P=12.1kLOC/24PM=504LOC/PMC=168000美元/12.1kLOC=13.88美元/LOCD=365Pd/12.1kLOC=30.16Pd/kLOCEQR=29個/12.1kLOC=2.4個/kLOC例：下表提供了一個國外典型的軟件項目記錄8用代碼行數(shù)估計軟件規(guī)模簡單易行缺點：代碼行數(shù)的估算依賴于程序設計語言的功能和表達能力；采用代碼行估算方法會對設計精巧的軟件項目產生不利影響；在軟件項目開發(fā)前或開發(fā)初期估算它的代碼行數(shù)十分困難；代碼行估算只適用于過程式程序設計語言，對非過程式的程序設計語言不太適用等用代碼行數(shù)估計軟件規(guī)模簡單易行9功能點技術

依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算軟件規(guī)模

5個信息域特性為：用戶輸入數(shù)：各個用戶輸入是面向不同應用的輸入數(shù)據(jù)（參數(shù)，不含查詢數(shù)）個數(shù)。用戶輸出數(shù)：各個用戶輸出是面向應用的輸出信息個數(shù)，包括報告，屏幕信息，錯誤信息等。用戶查詢數(shù)：查詢是一種聯(lián)機的交互操作，統(tǒng)計查詢/響應的總計數(shù)。文件數(shù)：每一個邏輯主文件都應計數(shù)。邏輯主文件是指邏輯上的一組數(shù)據(jù)，可以是一個大數(shù)據(jù)庫的一部分，可以是一個單獨的文件。外部接口數(shù)：與系統(tǒng)中其他設備通過外部接口讀寫信息次數(shù)均應計數(shù)。功能點技術

依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算10

功能點FP(FunctionPoint)。

FP＝UFP×(0.65＋0.01×SUM(Fi))

估算功能點的步驟

1.計算未調整的功能點數(shù)UFP

UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf

其中，ai（1≤i≤5）是信息域特性系數(shù)，值由相應特性的復雜級別決定。

功能點FP(FunctionPoint)。

112.計算技術復雜因子TCF

14種技術因素：技術因素、數(shù)據(jù)通信、分布式數(shù)據(jù)處理、性能標準、高負荷的硬件、高處理率、聯(lián)機數(shù)據(jù)輸入、終端用戶效率、聯(lián)機更新、復雜的計算、可重用性、安裝方便、操作方便、可移植性、可維護性。2.計算技術復雜因子TCF

14種技術因素：技術因素、數(shù)據(jù)12復雜性校正值Fi1.

系統(tǒng)是否需要可靠的備份和恢復？2.

是否需要數(shù)據(jù)通信？3.

是否有分布處理的功能？4.

是否性能成為關鍵？5.

系統(tǒng)是否運行在既存的高度實用化的操作環(huán)境中？6.

系統(tǒng)是否需要聯(lián)機數(shù)據(jù)項？7.

聯(lián)機數(shù)據(jù)項是否需要建立多重窗口顯示和操作，以處理輸入處理。8.

主文件是否聯(lián)機更新？9.

輸入、輸出、文件、查詢是否復雜？10.

內部處理過程是否復雜？11.

程序代碼是否可復用？12.

設計中是否包括了轉移和安裝？13.

系統(tǒng)是否設計成可以重復安裝在不同機構中14.

系統(tǒng)是否設計成易修改和易使用？復雜性校正值Fi13計算技術因子對軟件規(guī)模的綜合影響程度DI：技術復雜性因子TCP由下式計算：TCP=0.65+0.01×DI計算功能點數(shù)FP

FP=UFP×TCP計算技術因子對軟件規(guī)模的綜合影響程度DI：14一旦計算出功能點，就可仿照LOC的方式度量軟件的生產率、質量和其它屬性：生產率＝FP／PM（人月）質量＝錯誤數(shù)／FP

成本＝元／FP文檔＝文檔頁數(shù)／FP功能點度量是為了商用信息系統(tǒng)應用而設計的。一旦計算出功能點，就可仿照LOC的方式度量軟件的生產率、質量15代碼行度量與功能點度量的比較代碼行度量（依賴開發(fā)語言）與功能點度量（不依賴開發(fā)語言）的比較

LOC/FP（平均）：匯編語言=300FORTRAN=100pascal=90Ada=70面向對象語言=30四代語言4GL=20代碼生成器=15一行Ada語言代碼的“功能”平均是一行FORTRAN語言代碼“功能”的1.4倍，一行四代語言代碼的“功能”平均是一行傳統(tǒng)程序設計語言代碼“功能”的3~5倍 代碼行度量與功能點度量的比較代碼行度量（依賴開發(fā)語言）與功能16CoCoMo模型1981年Boehm提出“構造性成本模型”（ConstructiveCostModel）該成本估算模型是一種精確、易于使用的成本估算方法COCOMO模型的分類（按其詳細程度，分三級）基本模型、中間模型、詳細模型基本模型是靜態(tài)單變量模型，用源代碼行數(shù)(LOC)為自變量的經(jīng)驗函數(shù)計算軟件開發(fā)工作量。中間模型在用LOC為自變量的函數(shù)計算軟件開發(fā)工作量（稱為名義工作量）的基礎上，用涉及產品、硬件、人員、項目等方面的影響因素調整工作量估算。詳細COCOMO模型包括中間模型的所有特性，但用上述各種影響因素調整工作量估算時，還要考慮對軟件工程過程中每一步驟（分析、設計等）的影響。CoCoMo模型1981年Boehm提出“構造性成本模型”17基本的CoCoMo模型公式其中：

E表示工作量（人月PM）

D表示開發(fā)時間（月）

L是項目的代碼行估計值（千行代碼）基本的CoCoMo模型公式18基本的CoCoMo模型參數(shù)a,b,c,d常數(shù)取值軟件類型abcd適用范圍組織型2.41.052.50.38各類應用程序半獨立型3.01.122.50.35各類實用程序、編譯程序等嵌入型3.61.202.50.32實時處理、控制程序、操作系統(tǒng)基本的CoCoMo模型參數(shù)a,b,c,d常數(shù)取值軟件類型a19中間的CoCoMo模型以基本的CoCoMo模型為基礎，工作量估計公式中乘以調節(jié)因子EAFE表示工作量（人月PM）

L是項目的代碼行估進一步考慮15種影響軟件工作量的因素軟件類型ab組織型3.21.05半獨立型3.01.12嵌入型2.81.20中間的CoCoMo模型以基本的CoCoMo模型為基礎，工作量2015種影響軟件工作量的因素

fi產品因素：軟件可靠性、數(shù)據(jù)庫規(guī)模、產品復雜性；硬件因素：執(zhí)行時間限制、存儲限制、虛擬機易變性、環(huán)境周轉時間；人的因素：分析員能力、應用領域實際經(jīng)驗、程序員能力、虛擬機使用經(jīng)驗、程序語言使用經(jīng)驗；項目因素：現(xiàn)代程序設計技術、軟件工具的使用、開發(fā)進度限制。15種影響軟件工作量的因素fi產品因素：21軟件工程管理課件22例一個規(guī)模為10KLOC的商用微機遠程通信的嵌入型軟件，使用中間COCOMO模型進行成本估算。名義工作量E1＝2.8×(10)1.20

＝44.38實際工作量E＝44.38×1.17＝51.9例一個規(guī)模為10KLOC的商用微機遠程通信的嵌入型軟件，使23中間CoCoMo模型與各種開發(fā)方案對工作量的影響建議參加項目的人數(shù)N為人數(shù)，D為開發(fā)時間（月）,E為工作量（人月）一般來說，由N個程序員組成的小組，實現(xiàn)相同的規(guī)模的程序，相互通信數(shù),

設每次通信和交換意見的平均的工作量，則增加的通信開銷為中間CoCoMo模型與各種開發(fā)方案對工作量的影響建議參加項目24一般情況下，由N個程序員組成的小組共同開發(fā)一個程序的工作量，滿足：程序員小組的生產率：單個程序員與程序員小組生產率的比為事實：盲目增加程序員人數(shù)會推遲軟件完成的日期

一般情況下，由N個程序員組成的小組共同開發(fā)一個程序的工作量25CoCoMo2模型1997年Boehm對CoCoMo模型進行了擴充，稱為CoCoMo2.COCOMO2模型分成三個層次應用系統(tǒng)組成模型：用于估算構建原型的工作量，這種模型考慮到大量使用已有構件的情況早期設計模型：用于軟件結構設計階段后期設計模型：用于軟件開發(fā)階段CoCoMo2模型1997年Boehm對CoCoMo模型進行26COCOMO2模型把軟件開發(fā)工作量表示成代碼行（KLOC）的非線性函數(shù)：其中，α是模型系數(shù)，典型值為3.0，b是模型指數(shù)，fi是成本因素。COCOMO2模型使用了5個分級因素Wi（1≤i≤5），分別是：項目先例性、開發(fā)靈活性、風險排除度、項目組凝聚力和過程成熟度。其中每個成本因素劃分為6個級別，每個級別的分級因素Wi取值如下：甚低Wi=5，低Wi=4,正常Wi=3，高Wi=2，甚高Wi=1，特高Wi=0。b的值：COCOMO2模型把軟件開發(fā)工作量表示成代碼行（KLOC）的27進度計劃可以把用于一般開發(fā)項目的進度安排的技術和工具應用于軟件項目。為監(jiān)控軟件項目的進度計劃和工作的實際進展情況，為表現(xiàn)各項任務之間進度的相互依賴關系，需要采用圖示的方法。在圖示方法中，必須明確標明：各個任務的計劃開始時間，完成時間；各個任務完成標志（即○文檔編寫和△評審）；各個任務與參與工作的人數(shù)，各個任務與工作量之間的銜接情況；完成各個任務所需的物理資源和數(shù)據(jù)資源進度計劃可以把用于一般開發(fā)項目的進度安排的技術和工具應用于軟28甘特圖GanttChart甘特圖GanttChart29在甘特圖中，每一任務完成的標準，不是以能否繼續(xù)下一階段任務為標準，而是以必須交付應交付的文檔與通過評審為標準。因此在甘特圖中，文檔編制與評審是軟件開發(fā)進度的里程碑。在甘特圖中，每一任務完成的標準，不是以能否繼續(xù)下一階段任務為30軟件工程管理課件31工程網(wǎng)絡技術工程網(wǎng)絡技術PERT技術(ProgramEvaluationandReviewTechnique)叫做程序評估與審查技術，CPM方法叫做關鍵路徑法，它們都是安排開發(fā)進度，制定軟件開發(fā)計劃的最常用的方法。它們都采用網(wǎng)絡圖來描述一個項目的任務網(wǎng)絡，也就是從一個項目的開始到結束，把應當完成的任務用圖或表的形式表示出來。1.計算最早時刻2.計算最遲時刻3.關鍵路徑4.機動時間工程網(wǎng)絡技術32軟件工程管理課件33通常用兩張表來定義網(wǎng)絡圖。一張表給出與一特定軟件項目有關的所有任務（也稱為任務分解結構WorkBreakdownStructure）;另一張表給出應當按照什么樣的次序來完成這些任務（有時稱為限制表RestrictionList）。

PERT技術和CPM方法都為項目計劃人員提供了一些定量的工具。

確定關鍵路徑，即決定項目開發(fā)時間的任務鏈。在關鍵路徑上的各個任務都是時間余量為零的關鍵任務，不能有任何時間延誤。

應用統(tǒng)計模型，對每一個單獨的任務確定最可能的開發(fā)持續(xù)時間的估算值。

計算邊界時間，以便為具體的任務定義時間窗口。通常用兩張表來定義網(wǎng)絡圖。34軟件工程管理課件35上述示例工程中各項任務的進度安排，可用Gantt圖畫出：（先安排關鍵路徑上的任務）

路徑優(yōu)化上述示例工程中各項任務的進度安排，可用Gantt圖畫出：（先36人員組織

1.開發(fā)人員2.組織機構三種組織結構模式按課題劃分的模式（ProjectFormat）按職能劃分的模式（FunctionalFormat）矩陣形模式（MatrixFormat）程序設計小組的組織形式有3種：主程序員組、民主制程序員組及層次式小組3.用戶用戶的阻力和干擾：不積極配合、求全求快、功能的變化人員組織

1.開發(fā)人員37軟件項目組織的建立開發(fā)組織采用什么形式，要針對軟件項目的特點來決定，同時也與參與人員的素質有關。組織原則

(1)盡早落實責任：在軟件項目工作開始時，要盡早指定專人負責，使他有權進行管理，并對任務的完成負全責。

（2）減少接口：一個組織的生產率隨完成任務中存在的通信路徑數(shù)目增加而降低。要有合理的人員分工、好的組織結構、有效的通信，減少不必要的生產率的損失。

（3）責權均衡：軟件經(jīng)理人員所負的責任不應比委任給他的權力還大。軟件項目組織的建立38組織結構的模式1）按課題劃分的模式

把軟件開發(fā)人員按課題組成小組，小組成員自始至終參加所承擔課題的各項任務。他們應負責完成軟件產品的定義、設計、實現(xiàn)、測試、復查、文檔編制、甚至包括維護在內的全過程。2）按職能劃分的模式

把參加開發(fā)項目的軟件人員按任務的工作階段劃分成若干個專業(yè)小組。要開發(fā)的軟件產品在每個專業(yè)小組完成階段加工（即工序）以后，沿工序流水線向下傳遞。例如，分別建立計劃組、需求分析組、設計組、實現(xiàn)組、系統(tǒng)測試組、質量保證組、維護組等。各種文檔資料按工序在各組之間傳遞。組織結構的模式393）矩陣形模式這種模式實際上是以上兩種模式的復合。一方面，按工作性質，成立一些專門組，如開發(fā)組、業(yè)務組、測試組等；另一方面，每一個項目又有它的經(jīng)理人員負責管理。每個軟件人員屬于某一個專門組，又參加某一項目的工作。3）矩陣形模式40軟件工程管理課件41程序設計小組的組織形式小組內部人員的組織形式對生產率也有影響?，F(xiàn)有的組織形式有三種。

（1）主程序員制小組

小組的核心由一位主程序員(高級工程師)、二至五位技術員、一位后援工程師組成。主程序員負責小組全部技術活動的計劃、協(xié)調與審查，設計和實現(xiàn)項目中的關鍵部分。程序設計小組的組織形式42技術員負責項目的具體分析與開發(fā)，文檔資料的編寫工作。后援工程師支持主程序員的工作，為主程序員提供咨詢，也做部分分析、設計和實現(xiàn)的工作。并在必要時能代替主程序員工作。

主程序員制小組還可以由一些專家(如通信專家或數(shù)據(jù)庫設計專家)、輔助人員(如打字員和秘書)、軟件資料員協(xié)助工作。

（2）民主制小組在民主制小組中，遇到問題，組內成員之間可以平等地交換意見。工作目標的制定及做出決定都由全體成員參加。雖然也有一位成員當組長，但工作的討論、成果的檢驗都公開進行。這種組織形式強調發(fā)揮小組每個成員的積極性。有人認為這種組織形式適合于研制時間長、開發(fā)難度大的項目。技術員負責項目的具體分析與開發(fā)，文檔資料的編寫工作。后援工43

（3）層次式小組在層次式小組中，組內人員分為三級：組長（項目負責人）一人負責全組工作，包括任務分配、技術評審和走查、掌握工作量和參加技術活動。他直接領導二至三名高級程序員，每位高級程序員通過基層小組，管理若干位程序員。這種組織結構只允許必要的人際通信。比較適用于項目本身就是層次結構的課題。因為這樣可以把項目按功能劃分成若干個子項目，把子項目分配給基層小組，由基層小組完成。這種組織方式比較適合于大型軟件項目的開發(fā)。（3）層次式小組44軟件工程管理課件45人員配備如何合理地配備人員，也是成功地完成軟件項目的切實保證。所謂合理地配備人員應包括：按不同階段適時任用人員恰當掌握用人標準。項目開發(fā)各階段所需人員一個項目完成的快慢，取決于參與開發(fā)人員的多少在開發(fā)過程中，多數(shù)軟件項目是以恒定人力配備的。實際人力需求與開發(fā)進度的關系如下圖中的曲線所示。按此曲線，需要的人力隨開發(fā)進展逐漸增加，在編碼與單元測試階段達到高峰，以后又逐漸減少。如果恒定地配備人力，在開發(fā)初期將會有部分人力資源用不上而浪費掉。在開發(fā)中期，需要人力不夠，造成進度的延誤。在開發(fā)后期就需要增加人力以趕進度。恒定地配備人力將浪費人力資源。人員配備46配備人員的原則重質量軟件項目是技術性很強的工作，要任用少量有實踐經(jīng)驗、有能力的人員去完成關鍵性的任務。重培訓

培養(yǎng)所需技術人員和管理人員是有效解決人員問題的好方法。雙階梯提升人員提升應分別按技術職務和管理職務進行，不能混在一起。配備人員的原則47對項目經(jīng)理人員的要求軟件經(jīng)理人員是工作的組織者，他的管理能力的強弱是項目成敗的關鍵。他應具有以下能力：

把用戶提出的非技術性要求加以整理提煉,以技術說明書的形式轉告給分析員和測試員。

能說服用戶放棄一些不切實際的要求,以保證合理的要求得以滿足。

能夠把表面上似乎無關的要求集中在一起,歸結為“需要什么”,“要解決什么問題”。這是一種綜合問題的能力。

要懂得心理學,能說服上級領導和用戶，讓他們理解什么是不合理的要求。但又要使他們毫不勉強,樂于接受，并受到啟發(fā)。對項目經(jīng)理人員的要求48評價人員的條件軟件項目中人的因素越來越受重視。在評價和任用軟件人員時，必須掌握一定的標準。人員素質的優(yōu)劣常常影響到項目的成敗。

牢固掌握計算機軟件的基本知識和技能。

善于分析和綜合問題，具有嚴密的邏輯思維能力。

工作踏實、細致,不靠碰運氣，遵循標準和規(guī)范，具有嚴格的科學作風。

工作中表現(xiàn)出有耐心、有毅力、有責任心。

善于聽取別人的意見，善于與周圍人員團結協(xié)作，建立良好的人際關系。

具有良好的書面和口頭表達能力。評價人員的條件49軟件配置管理

軟件配置（SoftwareConfiguration）是軟件產品在軟件開發(fā)或運行過程中產生的全部信息。軟件配置管理（SoftwareConfigurationManagement）簡稱SCM，是在軟件的整個生存周期內管理變更的一組活動。軟件配置管理(SoftwareConfigurationManagement，簡稱SCM)的四項任務:(１)標識變更(２)控制變更(３)配置審計(４)配置狀態(tài)報告軟件配置管理

軟件配置（SoftwareConfigura50軟件配置管理概念

軟件開發(fā)過程的最終結果包括三類信息：計算機程序（源程序和目標程序）；描述程序的文檔（面向技術人員和面向用戶）；數(shù)據(jù)結構（包括程序內部和外部定義兩部分）。組成上述信息的所有項目構成一個軟件配置，其中每一項稱為一個軟件配置項（SoftwareConfigurationItem，簡稱SCI），它是配置管理的基本單位。一個SC中最早的SCI是系統(tǒng)規(guī)格說明書。SCM要解決的主要問題就是保證軟件的質量。

軟件配置管理概念軟件開發(fā)過程的最終結果包括三類信息：51基線技術

基線（baseline）的原意是棒球場的邊線，在軟件開發(fā)過程中，為了有效地控制變動，軟件配置管理引入基線的概念。IEEE組織對于基線的定義——“已經(jīng)通過正式復審和批準的某規(guī)約或產品，它因此可以作為進一步開發(fā)的基礎，并且只能遵循正式的變化控制過程得到改變”。根據(jù)這個定義，基線標志軟件開發(fā)過程的各個里程碑，任一SCI，一旦形成文檔并復審通過，即成為一個基線，它標志開發(fā)過程中一個階段的結束。對于已成為基線的SCI，雖然可以修改，但必須按照一個特殊的、正式的過程進行評估，確認每一處修改。相反，對于未成為基線的SCI，可以進行非正式修改。某個SCI一旦成為基線，隨即被放入項目數(shù)據(jù)庫（projectdatabase）。此后，若開發(fā)小組中某位成員希望改動SCI，首先要將它拷貝到私有工作區(qū)并在項目數(shù)據(jù)庫中鎖住，不允許他人使用。在私有工作區(qū)中完成修改控制過程并復審通過之后，再把修改后的SCI推出并回送到項目數(shù)據(jù)庫，同時解鎖。基線技術基線（baseline）的原意是棒球場的邊線，在軟52一般軟件配置需包括下列SCI：1．系統(tǒng)規(guī)格說明書2．軟件項目規(guī)劃3．需求分析結果

1）軟件需求規(guī)格說明書

2）可執(zhí)行的或“紙樣”原型4．初步用戶手冊5．設計規(guī)格說明書

1）數(shù)據(jù)設計描述

2）總體結構設計描述

3）模塊設計描述

4）界面設計描述

5）對象描述（若采用面向對象技術）一般軟件配置需包括下列SCI：536．源代碼清單7．測試規(guī)格說明書

1）測試計劃和過程

2）測試用例和實驗結果8．操作和安裝手冊9．可執(zhí)行程序

1）每個模塊的可執(zhí)行代碼

2）連接到一起的代碼10．數(shù)據(jù)庫描述

1）數(shù)據(jù)模型和文件結構

2）初始化映象11．聯(lián)機用戶手冊12．維護文檔

1）軟件問題報告單

2）維護申請單

3）預計變動的順序13．軟件工程的標準和過程6．源代碼清單54軟件配置管理任務

軟件配置管理主要任務是控制軟件的修改，主要包括：標識軟件配置中各種對象；管理軟件的各種版本；控制對軟件的修改；審計配置；報告配置情況。軟件配置管理任務軟件配置管理主要任務是控制軟件的修改，主要55標識配置對象

所有SCI都應按面向對象的方式命名并組織起來。對象命名是為了能夠根據(jù)名稱提取對象；而通過組織對象并描述其間的關系則著眼于在對象變更時能夠清楚地了解變更的影響范圍。基本對象——在分析、設計、編碼或測試階段由開發(fā)人員創(chuàng)建的某個“文本單元”（unitoftext）。例如，需求說明書中某一節(jié)，某個模塊的源代碼，或按等價分類法制定的一套測試用例復合對象——由若干基本對象和復合對象組合而成的對象，是一個遞歸的概念。例如，“設計規(guī)格說明書”是復合對象，它由“數(shù)據(jù)模塊”和“模塊N”等基本對象組合而成。

標識配置對象所有SCI都應按面向對象的方式命名并組織起來。56每個配置對象都擁有名字、描述、資源列表和實際存在體四個部分：1.對象名一般為無二義字符串；2.對象描述包括若干數(shù)據(jù)項，它們指明對象的類型（例如，文檔、程序還是數(shù)據(jù)）、所屬工程項目的標志及變動和版本的有關信息；3.資源列表給出該對象要求、引用、處理和提供的所有實體，如數(shù)據(jù)類型、特殊函數(shù)等，有時變量也被看作資源；4.只有基本對象才有實際存在體，它是指向該對象“單元正文描述”的一個指針；對于復合對象，此項取null值。每個配置對象都擁有名字、描述、資源列表和實際存在體四個部分：57除了標識配置對象外，還必須指明對象之間的關系，一個對象可標識為另一個復合對象的一部分，即此兩對象之間存在一個<part?of>關系。若干<part?of>關系可定義出對象之間的分層結構。例如：“E?R圖”<part?of>“數(shù)據(jù)模型”“數(shù)據(jù)模型”<part?of>“設計規(guī)格說明書”因一個配置對象可能與其他多個對象有關系，所以SCI的分層結構不一定是簡單的樹狀結構，而是更一般的網(wǎng)狀結構。除了標識配置對象外，還必須指明對象之間的關系，一個對象可標識58版本控制

為了適應不同環(huán)境特點和滿足不同用戶的個性需求，往往一個項目保存多個版本。配置管理的版本控制主要解決下列問題：1）根據(jù)不同用戶的需要配置不同的系統(tǒng)；2）保存系統(tǒng)老版本，為以后調查問題使用；3）建立一個系統(tǒng)新版本，使它包含某些決策而拋棄另一些；4）支持兩位以上工程師同時在一個項目中工作；5）高效存儲項目的多個版本。版本控制為了適應不同環(huán)境特點和滿足不同用戶的個性需求，往往59版本控制系統(tǒng)都為配置對象的每個版本設置一組屬性，這組屬性既可以是簡單的版本號，也可以是一串復雜的布爾變量（即開關值），用以說明該版本功能上的變化。進化圖可用于描述一個軟件系統(tǒng)的不同版本。圖中每個結點都是軟件的一個完整版本，它由所有協(xié)調一致的軟件配置項組成（源代碼，文檔和數(shù)據(jù)）。此外，一個版本還允許有多種變形（Variant）。 例如，一個程序的某個版本由A、B、C、D、E五個部件組成，部件D僅在系統(tǒng)配有彩色顯示器時使用，部件E則適用于單顯，那么該版本就有兩種變形，一種由A、B、C、D四個部件組成，另一種由A、B、C、E四個部件組成。版本控制系統(tǒng)都為配置對象的每個版本設置一組屬性，這組屬性既可60軟件工程管理課件61修改控制

在大型軟件開發(fā)過程中，無控制地修改會迅速導致混亂。所謂修改控制，即把人的努力與自動工具結合起來，建立一套機制，有意識地控制軟件修改。當一個“修改申請”提出后，開發(fā)者依據(jù)技術指標和潛在的副作用，對其他配置對象和系統(tǒng)功能可能造成的影響以及項目成本等諸多因素進行評估。評估的結果將形成一個“修改報告單”，提交給修改控制機構(CCA)決策。CCA一旦同意修改，應立即提供一個“工程變動命令”ECO（EngineeringChangeOrder）。它指明修改任務、需遵守的限制和復審標準。然后從項目數(shù)據(jù)庫中“提出”待修改對象，經(jīng)修改后再“推出”更新版本。這一對動作是項目數(shù)據(jù)庫訪問控制和同步控制要求的。訪問控制決定哪些人員有權訪問或修改某個配置對象；而同步控制則保證并行修改時不因互相重寫而造成丟失修改。

修改控制在大型軟件開發(fā)過程中，無控制地修改會迅速導致混亂。62軟件工程管理課件63軟件開發(fā)人員根據(jù)ECO從項目數(shù)據(jù)庫中提出待修改對象，訪問控制機構，核實該開發(fā)人員是否有此特權，而同步控制機構則及時鎖住待修改對象，不允許其他開發(fā)人員再做修改，直至該對象的新版本推出。加鎖期間，其他工程人員仍可提取該對象的副本（稱為提取版本）使用。上圖所示的修改控制用于已交給用戶的軟件產品，稱為正式修改控制。若欲修改的SCI雖已為基線版本，但尚未交付用戶，此時修改控制稱為工程級的修改控制，它除了不涉及用戶外，其他步驟與正式的修改控制大致相同。若SCI并未成為基線版本，只需進行非正式的修改控制，則在不影響系統(tǒng)需求的前提下，該SCI的開發(fā)者可隨意改動軟件開發(fā)人員根據(jù)ECO從項目數(shù)據(jù)庫中提出待修改對象，訪問控制64變更控制過程來自用戶的CR工作量評估遞交CR表格CCA審查評估CR被否決同意CR，給人員分配任務SCM檢出配置項更改審計并檢入更改內容建立基線測試，執(zhí)行QA和測試活動提交改變到下一個Release通知用戶構造適當?shù)陌姹静徲嬎信渲庙椥掳姹局幸胱兓?，并發(fā)布該版本變更控制過程來自用戶的CR工作量評估遞交CR表格CCA審查評65配置審計

對于變更工作，必須通過正式的技術復審和軟件配置審計工作來驗證被核準進行變更的對象是否進行了必要的、正確的變更，并得到了重新的配置。正式的技術復審著重考慮所修改對象在技術上的正確性，復審人員應對該對象是否與其他SCI協(xié)調以及在修改中可能產生的疏忽和副作用進行全面的評估。軟件配置審計作為正式復審的一種補充措施，主要考慮下列在正式技術復審中未被考慮的因素：工程變動命令中指定的修改是否都已完成？有無進行未經(jīng)指定的其他附加變更？是否做過正式技術復審？是否嚴格遵守軟件工程標準？是否對修改過的SCI進行了強調說明？修改的日期和執(zhí)行修改的人員是否已經(jīng)注明？該SCI的屬性是否能夠反映本次修改的結果？是否遵循了標注變更、記錄變更和報告變更的SCM工作規(guī)程？所有相關的SCI是否已一并修改？配置審計對于變更工作，必須通過正式的技術復審和軟件配置審計66配置狀況報告

建立并發(fā)布配置狀況報告（ConfigurationStatusReporting，簡稱CSR）是軟件配置管理的一項任務.CSR主要概述下列問題：發(fā)生了什么事情；誰做的；何時發(fā)生的；有什么影響。CSR的時機與上圖所述過程緊密相關:

當某個SCI被賦予新標記或更新標記時;或修改控制機構CCA批準一項修改申請（產生一個工程變動命令ECO）時;或配置審計完成時。CSR的輸出可放在聯(lián)機數(shù)據(jù)庫中，供開發(fā)人員和維護人員隨時按關鍵字查詢配置狀況報告

建立并發(fā)布配置狀況報告（Configurat67軟件質量保證

計算機軟件質量是軟件的一些內部特性及其組合，質量不是在軟件產品中被測試出來的，而是在軟件開發(fā)和生產過程中形成的。軟件質量（Softwarequality）的定義為：（1）軟件產品中能滿足給定需要的性質和特性的總體。（2）軟件具有所期望的各種屬性的組合程度。（3）顧客和用戶覺得軟件滿足其綜合期望的程度。（4）確定軟件在使用中將滿足顧客預期要求的程度。為保證軟件充分滿足用戶要求而進行的有計劃、有組織的活動稱為軟件質量保證，其目的是生產高質量的軟件。軟件質量保證

計算機軟件質量是軟件的一些內部特性及其組合，質68軟件質量的特性

軟件質量是指軟件滿足明確規(guī)定或隱含定義的需求的程度。軟件質量的要點：軟件功能必須滿足用戶規(guī)定的需求；軟件應遵守規(guī)定標準所定義的一系列開發(fā)準則；軟件應滿足某些隱含的需求。如，可理解性、可維護性等。軟件質量的特性

軟件質量是指軟件滿足明確規(guī)定或隱含定義的需求69軟件質量的特性:功能性：軟件的功能達到它的設計規(guī)范和能滿足用戶需求的程度可靠性：在規(guī)定的時間和規(guī)定的條件下，軟件能夠實現(xiàn)所要求的功能的能力以及不引起系統(tǒng)失效的概率易使用性：用戶學習、操作、準備輸入和理解輸出的難易程度效率：軟件實現(xiàn)某種功能所需計算機資源的多少及執(zhí)行其功能時使用資源的持續(xù)時間的多少可維護性：進行必要修改的難易程度可移植性：軟件從一個計算機環(huán)境轉移到另一個計算機環(huán)境下的運行能力軟件質量的特性:70軟件質量保證措施

軟件質量保證是軟件工程管理的重要內容。包括以下措施：應用好的技術方法測試軟件進行正式的技術評審標準的實施控制變更程序正確性證明記錄、保存和報告軟件過程信息軟件質量保證措施

軟件質量保證是軟件工程管理的重要內容。71軟件工程標準與軟件文檔

軟件工程標準軟件工程標準化的定義對軟件生存期內的所有開發(fā)、維護和管理工作逐步建立起標準軟件工程標準化的意義提高軟件的可靠性、可維護性和可移植性；提高軟件的生產率和軟件人員的技術水平；提高軟件人員之間的通信效率，減少差錯和誤解；有利于軟件管理；有利于降低軟件產品的成本和運行維護成本；有利于縮短軟件開發(fā)周期。軟件工程標準與軟件文檔

軟件工程標準72軟件工程標準化的類型參照其它工程領域對工程標準劃分的方法，軟件工程標準主要有兩種：按標準的類型劃分和按標準的范圍劃分。(1)按標準的類型劃分主要有過程標準、產品標準、行業(yè)標準、記法標準等。過程標準與開發(fā)一個產品或從事一項服務的一系列活動或操作有關。過程標準使用一組方法、工具和技術，給出“誰來做”、“做什么”、“如何做”、“何時做”、“何地做”及在軟件工程活動中進行的不同層次工作的過程模型。產品標準則涉及軟件工程事務的格式和內容。軟件開發(fā)和維護活動文檔化的結果就是軟件產品，軟件文檔是軟件工程活動進一步開展的基礎。軟件開發(fā)作為一種行業(yè)，其行業(yè)標準涉及軟件工程的所有方面，如執(zhí)業(yè)認證、職業(yè)培訓、產品許可等。行業(yè)標準可以等同于行業(yè)行為規(guī)范。記法標準規(guī)定了在軟件工程行業(yè)范圍內，以唯一的方式進行交流的方法，如術語、表示法、語言等。(2)按標準的范圍劃分主要是根據(jù)軟件的任務功能和軟件生存期進行比較、判定、評價和確定軟件工程標準的范圍和內容。任務功能可以表示軟件工程過程，可以劃分為產品工程功能、驗證與確認功能以及技術管理功能3個部分。產品工程功能包括定義、生產和支持最終產品所必須的過程。驗證和確認功能是檢查產品質量的活動。技術管理功能是構造和控制產品工程的過程。這3個部分并不集中在單個的軟件生存周期里，而是并行進行的生產、檢查和控制活動。軟件工程標準化的類型73根據(jù)以上兩種分類方法，軟件工程標準可用一張二維表格來表示。標準范圍標準類型軟件生存期概念需求設計實現(xiàn)測試制造安裝與檢驗運行/維護引退過程方法技術度量產品需求GB/T9385-1988設計部件描述計劃報告行業(yè)職業(yè)道德準則認證特許課程記法術語表示法GB/T1526-1989語言根據(jù)以上兩種分類方法，軟件工程標準可用一張二維表格來74標準范圍標準類型過程管理產品管理資源管理評審與審計產品分析測試過程方法GB/T8566-1995技術度量產品需求設計部件描述計劃報告行業(yè)職業(yè)道德準則認證特許課程記法術語表示法語言標準范圍過程管理產品管理資源管理評審與審計產品分析75

上述兩表給出了二維表的大致格式。其中，給出了GB/T9385-1988、GB/T1526-1989、GB/T8566-1995這3個標準的例子，用于說明各個標準的類型及其作用。

1.GB/T9385-1988是原電子工業(yè)部批準的《計算機軟件需求說明編制指南》，用于指導軟件需求規(guī)格說明書的編寫。

2.GB/T1526-1989是國家標準總局批準的信息處理——數(shù)據(jù)流圖、程序流程圖、系統(tǒng)結構圖、程序網(wǎng)絡圖、系統(tǒng)資源圖的文件編制符號及約定。

3.GB/T8566-1995是國家標準總局批準的信息技術——軟件生存期過程標準，它規(guī)定了在獲取、供應、開發(fā)、操作、維護軟件和固件的軟件部分時，要實施的過程、活動和任務。目的是為用戶提供一個公共的框架，使軟件從業(yè)人員可以使用“相同的語言”創(chuàng)作和管理軟件。上述兩表給出了二維表的大致格式。其中，給出了GB/T76軟件工程標準編制的層次

根據(jù)軟件工程標準制定的機構和標準適用的范圍，可分為5個層次：國際標準、國家標準、行業(yè)標準、企業(yè)(機構)標準、項目(課題)標準。1.國際標準：由國際聯(lián)合機構制定和公布的標準，供各國參考。如ISO——國際標準化組織。2.國家標準：由政府或國家級的機構制定或批準，適用于全國范圍。如GB——中國國標、ANSI_美國國家標準協(xié)會、BS——英國國家標準、JIS——日本工業(yè)標準。3.行業(yè)標準：由行業(yè)機構、學術團體或國防等機構制定，適用于某個業(yè)務領域。如IEEE——美國電氣和電子工程師學會、GJB——中國國家軍用標準。4.企業(yè)規(guī)范：企業(yè)因軟件工程工作的需要制定的適用于本企業(yè)的規(guī)范。如IBM通用產品部于1984年制定的《程序設計開發(fā)指南》。5.項目規(guī)范：由某一科研生產項目組織制定，僅為該項目任務服務的軟件工程規(guī)范。如CIMS——計算機集成制造系統(tǒng)——軟件工程規(guī)范。軟件工程標準編制的層次77中國的軟件標準

1983年起，我國陸續(xù)制定和發(fā)布了20余項軟件工程國家標準。這些標準可以分為以下四類：1.基礎標準：規(guī)定了信息加工處理和軟件工程領域的術語、符號、表示、構造、分類級約定；2.開發(fā)標準：規(guī)定了軟件生存期過程、軟件支持環(huán)境、軟件記錄處理流程、軟件維護等的工作規(guī)范；3.文檔標準：規(guī)定了軟件產品、需求、測試、管理等文檔的編制規(guī)范；4.管理標準：規(guī)定了軟件配置管理計劃、質量保證計劃、產品質量特性、軟件可靠性和可維護性管理等的規(guī)范和工作要素。下表列出了我國部分軟件工程標準的名稱及其標準號：中國的軟件標準78類型標準名稱標準號基礎標準軟件工程術語GB/T11457-1989信息處理——數(shù)據(jù)流程、程序流程圖、系統(tǒng)結構圖、程序網(wǎng)絡圖、系統(tǒng)資源圖的文件編制符號及約定GB/T1526-1989軟件工程標準分類法GB/T15538-1995信息處理——程序構造及其表示法的約定GB/T13502-1992信息處理——單命中判定表規(guī)范GB/T15535-1995(ISO5806)信息處理系統(tǒng)——計算機系統(tǒng)配置圖符號及其約定GB/T14085-1993(ISO8790)開發(fā)標準信息技術——軟件生存期過程GB/T8566-1995軟件支持環(huán)境GB/T15853-1995信息處理——按記錄組處理順序文卷的程序流程GB/T15697-1995(ISO6593)軟件維護指南GB/T14079-1993文檔標準計算機軟件產品開發(fā)文檔編制指南GB/T8567-1988計算機軟件需求說明編制指南GB/T9385-1988計算機軟件測試文檔編制規(guī)范GB/T9386-1988軟件文檔管理指南GB/T16680-1996管理標準計算機軟件配置管理計劃規(guī)范GB/T12505-1990信息技術——軟件產品評價質量特性及其使用指南GB/T16260-1996計算機軟件質量保證計劃規(guī)范GB/T12504-1990計算機軟件可靠性和可維護性管理GB/T14394-1993類型標準名稱標準號軟件工程術語GB/T11457-198979軟件工程標準的制定與推行

軟件工程標準的制定與推行通常要經(jīng)歷一個環(huán)狀生命周期，如下圖所示。從最初的制定一項標準的初步設想，經(jīng)發(fā)起后，沿著環(huán)狀生命期，順時針經(jīng)歷以下步驟：審核修訂建議開發(fā)咨詢審批公布培訓實施發(fā)起撤銷軟件工程標準的制定與推行審核修訂建議開發(fā)咨詢審批公布培訓實施801.建議——擬定初步的建議方案2.開發(fā)——制定標準的具體內容3.咨詢——征求并吸收有關人員的意見4.審批——由管理部門決定能否推出5.公布——公布發(fā)布，使標準生效6.培訓——為推行標準準備人員條件7.實施——投入使用，需經(jīng)歷相當期限8.審核——檢驗實施效果，決定修改或撤銷9.修訂——修改其中不適當?shù)牟糠郑纬蓸藴实男掳姹?，進入新的周期事實上，幾乎所有的標準都有一個逐步的成熟，在環(huán)狀生命期上循環(huán)數(shù)次的經(jīng)歷，這就需要標準的制定者和使用者付出大量的勞動，來對標準加以完善。1.建議——擬定初步的建議方案81軟件文檔的分類國家標準局在1988年1月頒布了《計算機軟件開發(fā)規(guī)范》和《計算機軟件產品開發(fā)文件編制指南》，作為軟件開發(fā)和文檔編制工作的準則和規(guī)程。基于軟件生存期方法，可以從形式上將軟件文檔大致分成兩類：軟件開發(fā)過程中需要填寫的各種圖表，及應編制的各種技術文件或管理資料。軟件文檔根據(jù)其產生和使用的范圍，主要劃分為3大類：開發(fā)文檔、用戶文檔和管理文檔。軟件文檔開發(fā)文檔用戶文檔管理文檔可行性研究報告項目開發(fā)計劃軟件需求說明書數(shù)據(jù)庫設計說明書概要設計說明書詳細設計說明書用戶手冊操作手冊軟件需求說明書數(shù)據(jù)要求說明書項目開發(fā)計劃模塊開發(fā)卷宗開發(fā)進度月報測試計劃測試分析報告項目開發(fā)總結報告軟件文檔的分類軟件文檔開發(fā)文檔用戶文檔管理文檔可行性研究報告821.開發(fā)文檔

開發(fā)文檔主要負責對軟件開發(fā)過程進行描述和規(guī)范。開發(fā)文檔除了前面列表的內容，還包括軟件的詳細技術描述，如程序邏輯、程序間相互關系、數(shù)據(jù)格式、存儲等。開發(fā)文檔主要可以發(fā)揮以下幾個方面的作用：(1)作為軟件生存期個階段之間的通信工具，記錄生成軟件需求、設計、編碼、測試等的詳細規(guī)定和說明；(2)描述開發(fā)小組的工作職責。通過規(guī)定軟件規(guī)劃設計、主題腳本編制、文檔編制、質量保證等人員的角色，來定義“如何做”和“何時做”；(3)用作檢驗點，而允許管理者評估開發(fā)進度。如果開發(fā)文檔缺失或過時，管理者將失去跟蹤和控制軟件項目的重要工具；(4)形成系統(tǒng)維護人員所要求的基本的軟件支持文檔，并構成產品文檔的一部分；(5)記錄軟件開發(fā)的歷史。1.開發(fā)文檔832.用戶文檔用戶文檔主要負責對軟件產品的安裝、配置、使用、維護等信息進行描述。包括系統(tǒng)安裝配置手冊、用戶操作手冊、軟件需求說明書、數(shù)據(jù)要求說明書等。用戶文檔主要發(fā)揮以下作用：(1)為使用和運行軟件產品的用戶提供培訓和運行參考信息；(2)為產品維護工程師提供必要的信息；(3)促進和方便軟件產品的市場推廣。用戶文檔的提供通?？梢园ㄒ韵滦问剑寒a品的市場宣傳資料、適合管理者的產品指南和相關資料、提供給潛在用戶的較深入的產品技術資料、產品使用所需的完整的操作和技術資料等。用戶文檔的涉眾通常包括以下人員：一般潛在用戶、具有決策權的潛在用戶、最終用戶、產品維護人員等。最基本的用戶文檔通常包括以下幾類：產品培訓手冊、產品操作手冊、產品安裝配置手冊、產品支持手冊、產品信息廣告等。用戶文檔的分發(fā)按照涉眾的類型j進行。不同類型的涉眾可以獲得不同的用戶文檔。用戶文檔在分發(fā)前應該制定合適的分發(fā)策略和計劃。2.用戶文檔843.管理文檔

管理文檔主要是對軟件開發(fā)過程的管理信息進行描述。管理文檔除了前面列表內容，還應該包括被管理者的反饋信息，如各色表格、工作總結、開發(fā)體會、產品建議等。管理文檔主要有以下主要：(1)軟件初期定義、規(guī)劃、商務等與客戶互動結果的記錄；(2)開發(fā)過程每個階段的進度和進度變更的記錄；(3)軟件開發(fā)人員的組織、管理和變更的記錄；(4)軟件需求、規(guī)劃、設計等的變更控制的記錄；(5)開發(fā)過程發(fā)生的各種審查、審核、評估等情況的記錄；(6)驗收、培訓、移交、安裝等相關工作的實施記錄；(7)維護需求的提出、認定、計劃、實施等工作的記錄。3.管理文檔85軟件文檔與使用者的關系

軟件開發(fā)中產生的各類文檔面向不同的用戶，而軟件用戶應該得到的文檔也在商業(yè)合同中有明確規(guī)定。軟件文檔的使用對象開發(fā)人員維護人員管理人員用戶可行性研究報告項目開發(fā)計劃軟件需求說明書數(shù)據(jù)要求說明書概要設計說明書詳細設計說明書數(shù)據(jù)庫設計說明書測試計劃測試分析報告設計說明書測試分析報告模塊開發(fā)卷宗可行性研究報告項目開發(fā)計劃模塊開發(fā)卷宗開發(fā)進度月報項目開發(fā)總結報告用戶手冊操作手冊軟件文檔與使用者的關系軟件文檔的使用對象開發(fā)人員維護人員管理86軟件文檔編制與軟件生存期的關系軟件文檔的編制是隨著軟件生存期各個階段工作的開展而適時進行的。其中，有的僅反映某一階段的工作，有的則需要跨越多個階段的工作?？尚行匝芯颗c計劃需求分析軟件設計編碼與單元測試集成與測試運行與維護可行性研究報告√項目開發(fā)計劃√√軟件需求說明書√數(shù)據(jù)要求說明書√測試計劃√√概要設計說明書√詳細設計說明書√數(shù)據(jù)庫設計說明書√模塊開發(fā)卷宗√√用戶手冊√√√操作手冊√√測試分析報告√開發(fā)進度月報√√√√√項目總結報告√維護和修改建議√軟件文檔編制與軟件生存期的關系可行性研究與計劃需求分析軟件設87軟件文檔最終需要回答讀者關心的下列問題：1.為什么要開發(fā)、維護或修改這個軟件？(Why)2.工作目標要滿足哪些需求？(What)3.需求應如何實現(xiàn)？(How)4.開發(fā)、維護或修改的工作應由誰來完成？(Who)5.開發(fā)工作的時間如何安排？(When)6.開發(fā)工作在什么環(huán)境中實現(xiàn)，所需信息從何而來？(Where)軟件文檔最終需要回答讀者關心的下列問題：88為什么(Why)做什么(What)怎么做(How)誰來做(Who)何時做(When)何處做(Where)可行性研究報告√√項目開發(fā)計劃√√√軟件需求說明書√√數(shù)據(jù)要求說明書√√測試計劃√√√概要設計說明書√詳細設計說明書√數(shù)據(jù)庫設計說明書√模塊開發(fā)卷宗√用戶手冊√操作手冊√測試分析報告√開發(fā)進度月報√√項目總結報告√維護和修改建議√√√√√為什么做什么怎么做誰來做何時做何處做可行性研究報告√√項目開89演講完畢，謝謝觀看！演講完畢，謝謝觀看！90第9章軟件工程管理軟件工程管理概述軟件規(guī)模估算進度計劃人員組織軟件配置管理軟件質量保證軟件工程標準與軟件文檔第9章軟件工程管理91軟件工程管理概述1.軟件產品的特點軟件是邏輯產品，具有高度的抽象性同一功能的軟件可以有多樣性軟件生產過程復雜，具有易錯性軟件開發(fā)與維護主要是根據(jù)用戶需求“定制”的，其過程具有復雜性和易變性軟件的開發(fā)和運行經(jīng)常受到計算機系統(tǒng)環(huán)境的限制，因而軟件有安全性和可移植性等問題軟件生產有許多新技術需要軟件工程師進一步研究和實踐軟件工程管理概述1.軟件產品的特點922.軟件工程管理的重要性分階段管理策略涉及多學科軟件規(guī)模不斷增大，管理難度增加，管理不善的后果嚴重2.軟件工程管理的重要性933.軟件工程管理的內容包括對軟件開發(fā)成本、控制、開發(fā)人員、組織機構、用戶、軟件開發(fā)文檔、軟件質量等方面的管理。3.軟件工程管理的內容94軟件規(guī)模和開發(fā)工作量估算面向規(guī)模的度量（代碼行技術）面向功能的度量（功能點技術）CoCoMo模型軟件規(guī)模和開發(fā)工作量估算95軟件項目估算估算涉及到人、技術、環(huán)境、政策等多種因素，很難精確地估算出項目的開銷。常用四種估算方法參照已有類似項目估計待開發(fā)項目成本和工作量將大的項目分解成若干子項目，分別估算出子項目成本和工作量，再估算整個項目按軟件的生命期分別估算各階段的工作量和成本，再匯總，從而估算出整個項目根據(jù)實驗或歷史數(shù)據(jù)給出軟件項目工作量或成本的經(jīng)驗公式軟件項目代碼行和功能點估算是成本和工作量估算的基礎。（規(guī)模）LOC或FP的期望值：e=（a+4m+b)/6軟件項目估算估算涉及到人、技術、環(huán)境、政策等多種因素，很難精96代碼行技術用軟件項目的代碼行（LOC）數(shù)表示軟件項目的規(guī)模生產率P=L/E，E是軟件項目的工作量，用人月（PM）度量，L用千行代碼kLOC度量每行代碼的平均成本C=S/L，S是軟件項目總的開銷文檔與代碼比D=Pd/L，Pd是軟件項目的文檔頁數(shù)代碼出錯率EQR=Ne/L，Ne是軟件項目的代碼錯誤數(shù)代碼行技術97例：下表提供了一個國外典型的軟件項目記錄利用這些數(shù)據(jù)，可以求出：P=12.1kLOC/24PM=504LOC/PMC=168000美元/12.1kLOC=13.88美元/LOCD=365Pd/12.1kLOC=30.16Pd/kLOCEQR=29個/12.1kLOC=2.4個/kLOC例：下表提供了一個國外典型的軟件項目記錄98用代碼行數(shù)估計軟件規(guī)模簡單易行缺點：代碼行數(shù)的估算依賴于程序設計語言的功能和表達能力；采用代碼行估算方法會對設計精巧的軟件項目產生不利影響；在軟件項目開發(fā)前或開發(fā)初期估算它的代碼行數(shù)十分困難；代碼行估算只適用于過程式程序設計語言，對非過程式的程序設計語言不太適用等用代碼行數(shù)估計軟件規(guī)模簡單易行99功能點技術

依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算軟件規(guī)模

5個信息域特性為：用戶輸入數(shù)：各個用戶輸入是面向不同應用的輸入數(shù)據(jù)（參數(shù)，不含查詢數(shù)）個數(shù)。用戶輸出數(shù)：各個用戶輸出是面向應用的輸出信息個數(shù)，包括報告，屏幕信息，錯誤信息等。用戶查詢數(shù)：查詢是一種聯(lián)機的交互操作，統(tǒng)計查詢/響應的總計數(shù)。文件數(shù)：每一個邏輯主文件都應計數(shù)。邏輯主文件是指邏輯上的一組數(shù)據(jù)，可以是一個大數(shù)據(jù)庫的一部分，可以是一個單獨的文件。外部接口數(shù)：與系統(tǒng)中其他設備通過外部接口讀寫信息次數(shù)均應計數(shù)。功能點技術

依據(jù)對軟件信息域特性和軟件復雜性的評估結果，估算100

功能點FP(FunctionPoint)。

FP＝UFP×(0.65＋0.01×SUM(Fi))

估算功能點的步驟

1.計算未調整的功能點數(shù)UFP

UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf

其中，ai（1≤i≤5）是信息域特性系數(shù)，值由相應特性的復雜級別決定。

功能點FP(FunctionPoint)。

1012.計算技術復雜因子TCF

14種技術因素：技術因素、數(shù)據(jù)通信、分布式數(shù)據(jù)處理、性能標準、高負荷的硬件、高處理率、聯(lián)機數(shù)據(jù)輸入、終端用戶效率、聯(lián)機更新、復雜的計算、可重用性、安裝方便、操作方便、可移植性、可維護性。2.計算技術復雜因子TCF

14種技術因素：技術因素、數(shù)據(jù)102復雜性校正值Fi1.

系統(tǒng)是否需要可靠的備份和恢復？2.

是否需要數(shù)據(jù)通信？3.

是否有分布處理的功能？4.

是否性能成為關鍵？5.

系統(tǒng)是否運行在既存的高度實用化的操作環(huán)境中？6.

系統(tǒng)是否需要聯(lián)機數(shù)據(jù)項？7.

聯(lián)機數(shù)據(jù)項是否需要建立多重窗口顯示和操作，以處理輸入處理。8.

主文件是否聯(lián)機更新？9.

輸入、輸出、文件、查詢是否復雜？10.

內部處理過程是否復雜？11.

程序代碼是否可復用？12.

設計中是否包括了轉移和安裝？13.

系統(tǒng)是否設計成可以重復安裝在不同機構中14.

系統(tǒng)是否設計成易修改和易使用？復雜性校正值Fi103計算技術因子對軟件規(guī)模的綜合影響程度DI：技術復雜性因子TCP由下式計算：TCP=0.65+0.01×DI計算功能點數(shù)FP

FP=UFP×TCP計算技術因子對軟件規(guī)模的綜合影響程度DI：104一旦計算出功能點，就可仿照LOC的方式度量軟件的生產率、質量和其它屬性：生產率＝FP／PM（人月）質量＝錯誤數(shù)／FP

成本＝元／FP文檔＝文檔頁數(shù)／FP功能點度量是為了商用信息系統(tǒng)應用而設計的。一旦計算出功能點，就可仿照LOC的方式度量軟件的生產率、質量105代碼行度量與功能點度量的比較代碼行度量（依賴開發(fā)語言）與功能點度量（不依賴開發(fā)語言）的比較

LOC/FP（平均）：匯編語言=300FORTRAN=100pascal=90Ada=70面向對象語言=30四代語言4GL=20代碼生成器=15一行Ada語言代碼的“功能”平均是一行FORTRAN語言代碼“功能”的1.4倍，一行四代語言代碼的“功能”平均是一行傳統(tǒng)程序設計語言代碼“功能”的3~5倍 代碼行度量與功能點度量的比較代碼行度量（依賴開發(fā)語言）與功能106CoCoMo模型1981年Boehm提出“構造性成本模型”（ConstructiveCostModel）該成本估算模型是一種精確、易于使用的成本估算方法COCOMO模型的分類（按其詳細程度，分三級）基本模型、中間模型、詳細模型基本模型是靜態(tài)單變量模型，用源代碼行數(shù)(LOC)為自變量的經(jīng)驗函數(shù)計算軟件開發(fā)工作量。中間模型在用LOC為自變量的函數(shù)計算軟件開發(fā)工作量（稱為名義工作量）的基礎上，用涉及產品、硬件、人員、項目等方面的影響因素調整工作量估算。詳細COCOMO模型包括中間模型的所有特性，但用上述各種影響因素調整工作量估算時，還要考慮對軟件工程過程中每一步驟（分析、設計等）的影響。CoCoMo模型1981年Boehm提出“構造性成本模型”107基本的CoCoMo模型公式其中：

E表示工作量（人月PM）

D表示開發(fā)時間（月）

L是項目的代碼行估計值（千行代碼）基本的CoCoMo模型公式108基本的CoCoMo模型參數(shù)a,b,c,d常數(shù)取值軟件類型abcd適用范圍組織型2.41.052.50.38各類應用程序半獨立型3.01.122.50.35各類實用程序、編譯程序等嵌入型3.61.202.50.32實時處理、控制程序、操作系統(tǒng)基本的CoCoMo模型參數(shù)a,b,c,d常數(shù)取值軟件類型a109中間的CoCoMo模型以基本的CoCoMo模型為基礎，工作量估計公式中乘以調節(jié)因子EAFE表示工作量（人月PM）

L是項目的代碼行估進一步考慮15種影響軟件工作量的因素軟件類型ab組織型3.21.05半獨立型3.01.12嵌入型2.81.20中間的CoCoMo模型以基本的CoCoMo模型為基礎，工作量11015種影響軟件工作量的因素

fi產品因素：軟件可靠性、數(shù)據(jù)庫規(guī)模、產品復雜性；硬件因素：執(zhí)行時間限制、存儲限制、虛擬機易變性、環(huán)境周轉時間；人的因素：分析員能力、應用領域實際經(jīng)驗、程序員能力、虛擬機使用經(jīng)驗、程序語言使用經(jīng)驗；項目因素：現(xiàn)代程序設計技術、軟件工具的使用、開發(fā)進度限制。15種影響軟件工作量的因素fi產品因素：111軟件工程管理課件112例一個規(guī)模為10KLOC的商用微機遠程通信的嵌入型軟件，使用中間COCOMO模型進行成本估算。名義工作量E1＝2.8×(10)1.20

＝44.38實際工作量E＝44.38×1.17＝51.9例一個規(guī)模為10KLOC的商用微機遠程通信的嵌入型軟件，使113中間CoCoMo模型與各種開發(fā)方案對工作量的影響建議參加項目的人數(shù)N為人數(shù)，D為開發(fā)時間（月）,E為工作量（人月）一般來說，由N個程序員組成的小組，實現(xiàn)相同的規(guī)模的程序，相互通信數(shù),

設每次通信和交換意見的平均的工作量，則增加的通信開銷為中間CoCoMo模型與各種開發(fā)方案對工作量的影響建議參加項目114一般情況下，由N個程序員組成的小組共同開發(fā)一個程序的工作量，滿足：程序員小組的生產率：單個程序員與程序員小組生產率的比為事實：盲目增加程序員人數(shù)會推遲軟件完成的日期

一般情況下，由N個程序員組成的小組共同開發(fā)一個程序的工作量115CoCoMo2模型1997年Boehm對CoCoMo模型進行了擴充，稱為CoCoMo2.COCOMO2模型分成三個層次應用系統(tǒng)組成模型：用于估算構建原型的工作量，這種模型考慮到大量使用已有構件的情況早期設計模型：用于軟件結構設計階段后期設計模型：用于軟件開發(fā)階段CoCoMo2模型1997年Boehm對CoCoMo模型進行116COCOMO2模型把軟件開發(fā)工作量表示成代碼行（KLOC）的非線性函數(shù)：其中，α是模型系數(shù)，典型值為3.0，b是模型指數(shù)，fi是成本因素。COCOMO2模型使用了5個分級因素Wi（1≤i≤5），分別是：項目先例性、開發(fā)靈活性、風險排除度、項目組凝聚力和過程成熟度。其中每個成本因素劃分為6個級別，每個級別的分級因素Wi取值如下：甚低Wi=5，低Wi=4,正常Wi=3，高Wi=2，甚高Wi=1，特高Wi=0。b的值：COCOMO2模型把軟件開發(fā)工作量表示成代碼行（KLOC）的117進度計劃可以把用于一般開發(fā)項目的進度安排的技術和工具應用于軟件項目。為監(jiān)控軟件項目的進度計劃和工作的實際進展情況，為表現(xiàn)各項任務之間進度的相互依賴關系，需要采用圖示的方法。在圖示方法中，必須明確標明：各個任務的計劃開始時間，完成時間；各個任務完成標志（即○文檔編寫和△評審）；各個任務與參與工作的人數(shù)，各個任務與工作量之間的銜接情況；完成各個任務所需的物理資源和數(shù)據(jù)資源進度計劃可以把用于一般開發(fā)項目的進度安排的技術和工具應用于軟118甘特圖GanttChart甘特圖GanttChart119在甘特圖中，每一任務完成的標準，不是以能否繼續(xù)下一階段任務為標準，而是以必須交付應交付的文檔與通過評審為標準。因此在甘特圖中，文檔編制與評審是軟件開發(fā)進度的里程碑。在甘特圖中，每一任務完成的標準，不是以能否繼續(xù)下一階段任務為120軟件工程管理課件121工程網(wǎng)絡技術工程網(wǎng)絡技術PERT技術(ProgramEvaluationandReviewTechnique)叫做程序評估與審查技術，CPM方法叫做關鍵路徑法，它們都是安排開發(fā)進度，制定軟件開發(fā)計劃的最常用的方法。它們都采用網(wǎng)絡圖來描述一個項目的任務網(wǎng)絡，也就是從一個項目的開始到結束，把應當完成的任務用圖或表的形式表示出來。1.計算最早時刻2.計算最遲時刻3.關鍵路徑4.機動時間工程網(wǎng)絡技術122軟件工程管理課件123通常用兩張表來定義網(wǎng)絡圖。一張表給出與一特定軟件項目有關的所有任務（也稱為任務分解結構WorkBreakdownStructure）;另一張表給出應當按照什么樣的次序來完成這些任務（有時稱為限制表RestrictionList）。

PERT技術和CPM方法都為項目計劃人員提供了一些定量的工具。

確定關鍵路徑，即決定項目開發(fā)時間的任務鏈。在關鍵路徑上的各個任務都是時間余量為零的關鍵任務，不能有任何時間延誤。

應用統(tǒng)計模型，對每一個單獨的任務確定最可能的開發(fā)持續(xù)時間的估算值。

計算邊界時間，以便為具體的任務定義時間窗口。通常用兩張表來定義網(wǎng)絡圖。124軟件工程管理課件125上述示例工程中各項任務的進度安排，可用Gantt圖畫出：（先安排關鍵路徑上的任務）

路徑優(yōu)化上述示例工程中各項任務的進度安排，可用Gantt圖畫出：（先126人員組織

1.開發(fā)人員2.組織機構三種組織結構模式按課題劃分的模式（ProjectFormat）按職能劃分的模式（FunctionalFormat）矩陣形模式（MatrixFormat）程序設計小組的組織形式有3種：主程序員組、民主制程序員組及層次式小組3.用戶用戶的阻力和干擾：不積極配合、求全求快、功能的變化人員組織

1.開發(fā)人員127軟件項目組織的建立開發(fā)組織采用什么形式，要針對軟件項目的特點來決定，同時也與參與人員的素質有關。組織原則

(1)盡早落實責任：在軟件項目工作開始時，要盡早指定專人負責，使他有權進行管理，并對任務的完成負全責。

（2）減少接口：一個組織的生產率隨完成任務中存在的通信路徑數(shù)目增加而降低。要有合理的人員分工、好的組織結構、有效的通信，減少不必要的生產率的損失。

（3）責權均衡：軟件經(jīng)理人員所負的責任不應比委任給他的權力還大。軟件項目組織的建立128組織結構的模式1）按課題劃分的模式

把軟件開發(fā)人員按課題組成小組，小組成員自始至終參加所承擔課題的各項任務。他們應負責完成軟件產品的定義、設計、實現(xiàn)、測試、復查、文檔編制、甚至包括維護在內的全過程。2）按職能劃分的模式

把參加開發(fā)項目的軟件人員按任務的工作階段劃分成若干個專業(yè)小組。要開發(fā)的軟件產品在每個專業(yè)小組完成階段加工（即工序）以后，沿工序流水線向下傳遞。例如，分別建立計劃組、需求分析組、設計組、實現(xiàn)組、系統(tǒng)測試組、質量保證組、維護組等。各種文檔資料按工序在各組之間傳遞。組織結構的模式1293）矩陣形模式這種模式實際上是以上兩種模式的復合。一方面，按工作性質，成立一些專門組，如開發(fā)組、業(yè)務組、測試組等；另一方面，每一個項目又有它的經(jīng)理人員負責管理。每個軟件人員屬于某一個專門組，又參加某一項目的工作。3）矩陣形模式130軟件