第15講軟件項目管理

1、第15講軟件項目管理六 軟件配置管理 v任何軟件開發(fā)都是迭代過程，也就是說，在設(shè)計過程會發(fā)現(xiàn)需求說明書中的問題，在實現(xiàn)過程又會暴露出設(shè)計中的錯 誤，。此外，隨著時間推移客戶的需求也會或多或少發(fā)生變化。因此，在開發(fā)軟件的過程中，變化（或稱為變動）既是必要的，又是不可避免的。但是，變化也 很容易失去控制，如果不能適當?shù)乜刂坪凸芾碜兓?，勢必造成混亂并產(chǎn)生許多嚴重的錯誤。v軟件配置管理是在軟件的整個生命期內(nèi)管理變化的一組活動。具體地說，這組活動用來： 標識變化； 控制變化； 確保適當?shù)貙崿F(xiàn)了變化； 向需要知道這類信息的人報告變化。軟件配置 v1. 軟件配置項軟件配置項v軟件過程的輸出信息可以分為3類：

2、 計算機程序（源代碼和可執(zhí)行程序）； 描述計算機程序的文檔（供技術(shù)人員或用戶使用）； 數(shù)據(jù)（程序內(nèi)包含的或在程序外的）。 v上述這些項組成了在軟件過程中產(chǎn)生的全部信息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟件配置項。2. 基線基線 v基線是一個軟件配置管理概念，它有助于我們在不嚴重妨礙合理變化的前提下來控制變化。IEEE把基線定義為： 已經(jīng)通過了正式復(fù)審的規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基礎(chǔ)，并且只有通過正式的變化控制過程才能改變它。v簡而言之，基線就是通過了正式復(fù)審的軟件配置項。在軟件配置項變成基線之前，可以迅速而非正式地修改它。一旦建立了基線之后，雖然仍然可以實現(xiàn)變化，但是，必

3、須應(yīng)用特定的、正式的過程（稱為規(guī)程）來評估、實現(xiàn)和驗證每個變化。v除了軟件配置項之外，許多軟件工程組織也把軟件工具置于配置管理之下，也就是說，把特定版本的編輯器、編譯器和其 他CASE工具，作為軟件配置的一部分“固定”下來。因為當修改軟件配置項時必然要用到這些工具，為防止不同版本的工具產(chǎn)生的結(jié)果不同，應(yīng)該把軟件工具也 基線化，并且列入到綜合的配置管理過程之中。軟件配置管理過程軟件配置管理過程 v軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它的主要任務(wù)是控制變化，同時也負責各個軟件配置項和軟件各種版本的標識、軟件配置審計以及對軟件配置發(fā)生的任何變化的報告。v具體來說，軟件配置管理主要有5項任務(wù)： 標識

4、、版本控制、變化控制、配置審計和報告。1. 標識軟件配置中的對標識軟件配置中的對象 v可以標識出兩類對象： 基本對象和聚集對象（可以把聚集對象作為代表軟件配置完整版本的一種機制）?；緦ο笫擒浖こ處熢诜治觥⒃O(shè)計、編碼或測試過程中創(chuàng)建出來的“文本單 元”，例如，需求規(guī)格說明的一個段落、一個模塊的源程序清單或一組測試用例。聚集對象是基本對象和其他聚集對象的集合。v每個對象都有一組能惟一地標識它的特征： 名字、描述、資源表和“實現(xiàn)”。其中，對象名是無二義性地標識該對象的一個字符串。v在設(shè)計標識軟件對象的模式時，必須認識到對象在整個生命周期中一直都在演化，因此，所設(shè)計的標識模式必須能無歧義地標識每個

5、對象的不同版本。2. 版本控制版本控制 v版本控制聯(lián)合使用規(guī)程和工具，以管理在軟件工程過程中所創(chuàng)建的配置對象的不同版本。借助于版本控制技術(shù)，用戶能夠通過選擇適當?shù)陌姹緛碇付ㄜ浖到y(tǒng)的配置。實現(xiàn)這個目標的方法是，把屬性和軟件的每個版本關(guān)聯(lián)起來，然后通過描述一組所期望的屬性來指定和構(gòu)造所需要的配置。v上面提到的“屬性”，既可以簡單到僅是賦給每個配置對象的具體版本號，也可以復(fù)雜到是一個布爾變量串，其指明了施加到系統(tǒng)上的功能變化的具體類型。3. 變化控制變化控制 v對于大型軟件開發(fā)項目來說，無控制的變化將迅速導(dǎo)致混亂。變化控制把人的規(guī)程和自動工具結(jié)合起來，以提供一個控制變化的機制。v典型的變化控制過程

6、如下： 接到變化請求之后，首先評估該變化在技術(shù)方面的得失、可能產(chǎn)生的副作用、對其他配置對象和系統(tǒng)功能的整體影響以及估算出的修改成本。評估的結(jié)果形成“變化 報告”，該報告供“變化控制審批者”審閱。所謂變化控制審批者既可以是一個人也可以由一組人組成，其對變化的狀態(tài)和優(yōu)先級做最終決策。為每個被批準的變化都生成一個“工程變化命令”，其描述將要實現(xiàn)的變化，必須遵守的約束以及復(fù)審和審計的標準。把要修改的對象從項目數(shù)據(jù)庫中“提取 （check out）”出來，進行修改并應(yīng)用適當?shù)腟QA活動。最后，把修改后的對象“提交（check in）”進數(shù)據(jù)庫，并用適當?shù)陌姹究刂茩C制創(chuàng)建該軟件的下一個版本。 3. 變化控

7、制變化控制 v“提交”和“提取”過程實現(xiàn)了變化控制的兩個主要功能訪問控制和同步控制。訪問控制決定哪個軟件工程師有權(quán)訪問和修改一個特定的配置對象，同步控制有助于保證由兩名不同的軟件工程師完成的并行修改不會相互覆蓋。 v在一個軟件配置項變成基線之前，僅需應(yīng)用非正式的變化控制。該配置對象的開發(fā)者可以對它進行任何合理的修改（只要修改不會影響到開發(fā)者工作范圍之外的系統(tǒng) 需求）。一旦該對象經(jīng)過了正式技術(shù)復(fù)審并獲得批準，就創(chuàng)建了一個基線。而一旦一個軟件配置項變成了基線，就開始實施項目級的變化控制?，F(xiàn)在，為了進行修改 開發(fā)者必須獲得項目管理者的批準（如果變化是“局部的”），如果變化影響到其他軟件配置項，還必須

8、得到變化控制審批者的批準。在某些情況下，可以省略正式 的變化請求、變化報告和工程變化命令，但是，必須評估每個變化并且跟蹤和復(fù)審所有變化。 4. 配置審計配置審計 v為了確保適當?shù)貙崿F(xiàn)了所需要的變化，通常從下述兩方面采取措施： 正式的技術(shù)復(fù)審； 軟件配置審計。 v正式的技術(shù)復(fù)審關(guān)注被修改后的配置對象的技術(shù)正確性。復(fù)審者審查該對象以確定它與其他軟件配置項的一致性，并檢查是否有遺漏或副作用。v軟件配置審計通過評估配置對象的那些通常不在復(fù)審過程中考慮的特征（例如，修改時是否遵循了軟件工程標準，是否在 該配置項中顯著地標明了所做的修改，是否注明了修改日期和修改者，是否適當?shù)馗铝怂邢嚓P(guān)的軟件配置項，是

9、否遵循了標注變化、記錄變化和報告變化的規(guī) 程），而成為對正式技術(shù)復(fù)審的補充。5. 狀態(tài)報告狀態(tài)報告 v書寫配置狀態(tài)報告是軟件配置管理的一項任務(wù)，它回答下述問題： 發(fā)生了什么事？ 誰做的這件事？這件事是什么時候發(fā)生的？它將影響哪些其他事物？v配置狀態(tài)變化對大型軟件開發(fā)項目的成功有重大影響。當大量人員在一 起工作時，可能一個人并不知道另一個人在做什么。兩名開發(fā)人員可能試圖按照相互沖突的想法去修改同一個軟件配置項；軟件工程隊伍可能耗費幾個人月的工作量 根據(jù)過時的硬件規(guī)格說明開發(fā)軟件；察覺到所建議的修改有嚴重副作用的人可能還不知道該項修改正在進行。配置狀態(tài)報告通過改善所有相關(guān)人員之間的通信，幫助 消除

10、這些問題。能力成熟度模型 v美國卡內(nèi)基梅隆大學(xué)軟件工程研究所在美國國防部資助下于20世紀80年代末建立的能力成熟度模型（capability maturity model，CMM)，是用于評價軟件機構(gòu)的軟件過程能力成熟度的模型。v最初，建立此模型的目的主要是，為大型軟件項目的招投標活動提供一種全面而客觀的 評審依據(jù)，發(fā)展到后來，此模型又同時被應(yīng)用于許多軟件機構(gòu)內(nèi)部的過程改進活動中。 能力成熟度模型的基本思想v能力成熟度模型的基本思想是，由于問題是由我們管理軟件過程的方法不當引起的，所以新軟件技術(shù)的運用并不會自動提高軟件的生產(chǎn)率和質(zhì)量。能力成熟度模型有 助于軟件開發(fā)機構(gòu)建立一個有規(guī)律的、成熟的軟

11、件過程。改進后的軟件過程將開發(fā)出質(zhì)量更好的軟件，使更多的軟件項目免受時間和費用超支之苦。v軟件過程包括各種活動、技術(shù)和工具，因此，它實際上既包括了軟件開發(fā)的技術(shù)方面又包括了管理方面。CMM的策略是，力圖改進對軟件過程的管理，而在技術(shù)方面的改進是其必然的結(jié)果。 CMM在改進軟件過程中所起的作用vCMM在改進軟件過程中所起的作用主要是，指導(dǎo)軟件機構(gòu)通過確定當前的過程成熟度并識別出對過程改進起關(guān)鍵作用的問題，從而明確過程改進的方向和策略。v通 過集中開展與過程改進的方向和策略相一致的一組過程改進活動，軟件機構(gòu)便能穩(wěn)步而有效地改進其軟件過程，使其軟件過程能力得到循序漸進的提高。 成熟度等級v對軟件過程

12、的改進，是在完成一個又一個小的改進步驟基礎(chǔ)上不斷進行的漸進過程，而不是一蹴而就的徹底革命。CMM把軟件過程從無序到有序的進化過程分成5 個階段，并把這些階段排序，形成5個逐層提高的等級。這5個成熟度等級定義了一個有序的尺度，用以測量軟件機構(gòu)的軟件過程成熟度和評價其軟件過程能力，這 些等級還能幫助軟件機構(gòu)把應(yīng)做的改進工作排出優(yōu)先次序。v成熟度等級是妥善定義的向成熟軟件機構(gòu)前進途中的平臺，每個成熟度等級都為軟件過程的繼續(xù)改進提供 了一個臺階。 成熟度等級vCMM對5個成熟度級別特性的描述，說明了不同級別之間軟件過程的主要變化。從“1級”到“5級”，反映出一個軟 件機構(gòu)為了達到從一個無序的、混亂的軟

13、件過程進化到一種有序的、有紀律的且成熟的軟件過程的目的，必須經(jīng)歷的過程改進活動的途徑。每一個成熟度級別都是該 軟件機構(gòu)沿著改進其過程的途徑前進途中的一個臺階，后一個成熟度級別是前一個級別的軟件過程的進化目標。vCMM的每個成熟度級別中都 包含一組過程改進的目標，滿足這些目標后一個機構(gòu)的軟件過程就從當前級別進化到下一個成熟度級別；每達到成熟度級別框架的下一個級別，該機構(gòu)的軟件過程都 得到一定程度的完善和優(yōu)化，也使得過程能力得到提高；隨著成熟度級別的不斷提高，該機構(gòu)的過程改進活動取得了更加顯著的成效，從而使軟件過程得到進一步的 完善和優(yōu)化。CMM就是以上述方式支持軟件機構(gòu)改進其軟件過程的活動。1.

14、 初始級初始級 v軟件過程的特征是無序的，有時甚至是混亂的。幾乎沒有什么過程是經(jīng)過定義的（即沒有一個定型的過程模型），項目能否成功完全取決于開發(fā)人員的個人能力。v處于這個最低成熟度等級的軟 件機構(gòu)，基本上沒有健全的軟件工程管理制度，其軟件過程完全取決于項目組的人員配備，所以具有不可預(yù)測性，人員變了過程也隨之改變。如果一個項目碰巧由一 個杰出的管理者和一支有經(jīng)驗、有能力的開發(fā)隊伍承擔，則這個項目可能是成功的。但是，更常見的情況是，由于缺乏健全的管理和周密的計劃，延期交付和費用超 支的情況經(jīng)常發(fā)生，結(jié)果，大多數(shù)行動只是應(yīng)付危機，而不是完成事先計劃好的任務(wù)。v總之，處于1級成熟度的軟件機構(gòu)，其過程能

15、力是不可預(yù)測的，其軟件過程是不穩(wěn)定的，產(chǎn)品質(zhì)量只能根據(jù)相關(guān)人員的個人工作能力而不是軟件機構(gòu)的過程能力來預(yù)測。2. 可重復(fù)級可重復(fù)級 v軟件機構(gòu)建立了基本的項目管理過程(過程模型),可跟蹤成本、進度、功能和質(zhì)量。已經(jīng)建立起必要的過程規(guī)范，對新 項目的策劃和管理過程是基于以前類似項目的實踐經(jīng)驗，使得有類似應(yīng)用經(jīng)驗的軟件項目能夠再次取得成功。達到2級的一個目標是使項目管理過程穩(wěn)定，從而使得 軟件機構(gòu)能重復(fù)以前在成功項目中所進行過的軟件項目工程實踐。v處于2級成熟度的軟件機構(gòu)， 針對所承擔的軟件項目已建立了基本的軟件管理控制制度。通過對以前項目的觀察和分析，可以提出針對現(xiàn)行項目的約束條件。項目負責人跟

16、蹤軟件產(chǎn)品開發(fā)的成本 和進度以及產(chǎn)品的功能和質(zhì)量，并且識別出為滿足約束條件所應(yīng)解決的問題。已經(jīng)做到軟件需求條理化，而且其完整性是受控制的。已經(jīng)制定了項目標準，并且軟件 機構(gòu)能確保嚴格執(zhí)行這些標準。項目組與客戶及承包商已經(jīng)建立起一個穩(wěn)定的、可管理的工作環(huán)境。v處于2級成熟度的軟件機構(gòu)的過程能力可以概括為，軟件項目的策劃和跟蹤是穩(wěn)定的，已經(jīng)為一個有紀律的管理過程提供了可重復(fù)以前成功實踐的項目環(huán)境。軟件項目工程活動處于項目管理體系的有效控制之下，執(zhí)行著基于以前項目的準則且合乎現(xiàn)實的計劃。3. 已定義級已定義級v軟件機構(gòu)已經(jīng)定義了完整的軟件過程（過程模型），軟件過程已經(jīng)文檔化和標準化。所有項目組都使用

17、文檔化的、經(jīng)過批準的過程來開發(fā)和維護軟件。這一級包含了第2級的全部特征。v在第3級成熟度的軟件機構(gòu) 中，有一個固定的過程小組從事軟件過程工程活動。當需要時，過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟件項目的過程實例， 并投入過程運作而開展有效的軟件項目工程實踐。同時，過程小組還可以推進軟件機構(gòu)的過程改進活動。在該軟件機構(gòu)內(nèi)實施了培訓(xùn)計劃，能夠保證全體項目負責人 和項目開發(fā)人員具有完成承擔的任務(wù)所要求的知識和技能。v處于3級成熟度的軟件機構(gòu)的過程能力可以概括為，無論是管理活動還是工程活動都是穩(wěn)定的。軟件開發(fā)的成本和進度以及產(chǎn)品的功能和質(zhì)量都受到控制，而且軟件產(chǎn)品的質(zhì)量

18、具有可追溯性。這種能力是基于在軟件機構(gòu)中對已定義的過程模型的活動、人員和職責都有共同的理解。4. 已管理級已管理級v軟件機構(gòu)對軟件過程（過程模 型和過程實例）和軟件產(chǎn)品都建立了定量的質(zhì)量目標，所有項目的重要的過程活動都是可度量的。該軟件機構(gòu)收集了過程度量和產(chǎn)品度量的方法并加以運用，可以定 量地了解和控制軟件過程和軟件產(chǎn)品，并為評定項目的過程質(zhì)量和產(chǎn)品質(zhì)量奠定了基礎(chǔ)。這一級包含了第3級的全部特征。v處于4級成熟度的軟件機構(gòu)的過程能力可以概括為，軟件過程是可度量的，軟件過程在可度量的范圍內(nèi)運行。這一級的過程能力允許軟件機構(gòu)在定量的范圍內(nèi)預(yù)測過程和產(chǎn)品質(zhì)量趨勢，在發(fā)生偏離時可以及時采取措施予以糾正，

19、并且可以預(yù)期軟件產(chǎn)品是高質(zhì)量的。5. 優(yōu)化級優(yōu)化級v軟件機構(gòu)集中精力持續(xù)不斷地 改進軟件過程。這一級的軟件機構(gòu)是一個以防止出現(xiàn)缺陷為目標的機構(gòu)，它有能力識別軟件過程要素的薄弱環(huán)節(jié)，并有足夠的手段改進它們。在這樣的機構(gòu)中，可以 獲得關(guān)于軟件過程有效性的統(tǒng)計數(shù)據(jù)，利用這些數(shù)據(jù)可以對新技術(shù)進行成本/效益分析，并可以優(yōu)化出在軟件工程實踐中能夠采用的最佳新技術(shù)。這一級包含了第4 級的全部特征。v這一級的軟件機構(gòu)可以通過對 過程實例性能的分析和確定產(chǎn)生某一缺陷的原因，來防止再次出現(xiàn)這種類型的缺陷；通過對任何一個過程實例的分析所獲得的經(jīng)驗教訓(xùn)都可以成為該軟件機構(gòu)優(yōu)化其 過程模型的有效依據(jù)，從而使其他項目的過

20、程實例得到優(yōu)化。這樣的軟件機構(gòu)可以通過從過程實施中獲得的定量的反饋信息，在采用新思想和新技術(shù)的同時測試它 們，以不斷地改進和優(yōu)化軟件過程。v處于5級成熟度的軟件機構(gòu)的過程能力可以概括為，軟件過程是可優(yōu)化的。這一級的軟件機構(gòu)能夠持續(xù)不斷地改進其過程能力，既對現(xiàn)行的過程實例不斷地改進和優(yōu)化，又借助于所采用的新技術(shù)和新方法來實現(xiàn)未來的過程改進。CMMv一些統(tǒng)計數(shù)字表明，提高一個完整的成熟度等級大約需要花18個月到3年的時間，但是從第1級上升到第2級有時要花3年甚至5年時間。這說明要向一個迄今仍處于混亂的和被動的行動方式的軟件機構(gòu)灌輸系統(tǒng)化的方式，將多么困難。CMM評估中存在的若干問題評估中存在的若干

21、問題v前言: 本文部分內(nèi)容參考了2000年2月IEEE雜志上的一篇文章。該文作者從采購方和軟件企業(yè)方分析了SCE中存 在的若干問題，最后發(fā)問：“CMM評估還可信嗎？” 中國軟件企業(yè)的CMM評估，一開始就充滿了浮躁、做秀和功利的氣息。整個CMM評估的過程，我們看到的是好大喜功的政府行業(yè)主管部門、一貫愛湊熱鬧的新聞 媒體、有賺白不賺的中介機構(gòu)、證書隨身帶的主任評估師和愿意花錢買吆喝的軟件企業(yè)。CMM評估的這種濃厚的功利性，使得“Gaming the Assessment”成為軟件企業(yè)上上下下的共識和“不宣之秘”。希望本文對國內(nèi)軟件業(yè)界正確對待CMM起到應(yīng)有作用，不要像某些軟件企業(yè)一樣找個“證 書隨

22、身帶”、“一手交錢，一手交證”的主任評估師。畢竟，提高企業(yè)的核心競爭力是最重要的。 1 評估人員的資質(zhì)評估人員的資質(zhì)vSEI對主任評估師的資質(zhì)要求比較嚴格，但是評估是由一個評估小組來進行的。問題1：評估組員的資質(zhì)很難滿足。通常，評估組員很難達到SEI所要求的軟件工程的技術(shù)和管理背景。v問題2：評估人員多是管理人員，技術(shù)素質(zhì)普遍較弱。這 個問題也包括主任評估師，由于多年脫離軟件開發(fā)實踐工作，主任評估師甚至在提問時有意回避技術(shù)問題，而是反復(fù)詢問管理問題。因為評估人員的技術(shù)素質(zhì)普遍較 弱，因此對于CMM中涉及工程部分的關(guān)鍵實踐解釋能力很差。甚至在對企業(yè)員工面試時，當員工提到技術(shù)方面問題時，評估人員會將話題岔開，又轉(zhuǎn)到管理問題 上。 2 評估的時間壓力評估的時間壓力 v一般評估的時間都在一周左右，要執(zhí)行的工作相當多，時間壓力很大。原來的評估方法中要求單個面試的方式，后來迫于時間壓力，新版本中增加了“Group Interview”（團體面試）。v問題3：團體面試本來是為了節(jié)省時間，實際上往往掩蓋了問題，不能