軟件過程79課件

軟件過程、管理和質(zhì)量李宣東概要軟件過程軟件質(zhì)量保證軟件配置管理軟件項(xiàng)目管理概念軟件過程軟件過程是近十年來人們關(guān)注的焦點(diǎn)。軟件過程是為開發(fā)高質(zhì)量軟件所需要完成的任務(wù)的框架。軟件工程是有創(chuàng)造力、有知識(shí)的人在定義好的、成熟的軟件過程框架中進(jìn)行的。軟件過程軟件工程是一種層次化的技術(shù)任何工程方法（包括軟件工程）必須以有組織的質(zhì)量保證為基礎(chǔ)。全面的質(zhì)量管理和類似的理念刺激了不斷的過程改進(jìn)，正是這種改進(jìn)導(dǎo)致了更加成熟的軟件工程方法的不斷出現(xiàn)。支持軟件工程的根基就在于對(duì)質(zhì)量的關(guān)注。軟件過程軟件工程的基層是過程層軟件工程過程是將技術(shù)層結(jié)合在一起的凝聚力，使得軟件能夠被合理地和及時(shí)地開發(fā)出來。過程定義了一組關(guān)鍵過程區(qū)域的框架，這對(duì)于軟件工程技術(shù)的有效應(yīng)用是必須的。關(guān)鍵過程區(qū)域構(gòu)成了軟件項(xiàng)目管理控制的基礎(chǔ)，并且確定了上下各區(qū)域之間的關(guān)系，規(guī)定了技術(shù)方法的采用、工程產(chǎn)品（模型、文檔、數(shù)據(jù)、報(bào)告、表格等）的產(chǎn)生、里程碑的建立、質(zhì)量的保證及變化的適當(dāng)管理。軟件過程軟件工程的方法層

提供了為開發(fā)軟件在技術(shù)上需要“如何做”。方法涵蓋了一系列的任務(wù)：需求分析、設(shè)計(jì)、編程、測試和維護(hù)。軟件工程方法依賴于一組原則，這些原則控制了每一個(gè)技術(shù)區(qū)域，且包含建?；顒?dòng)和其他描述技術(shù)。軟件過程過程：為實(shí)現(xiàn)一個(gè)給定目標(biāo)而進(jìn)行的一系列運(yùn)作步驟。過程具有一系列的性質(zhì)：時(shí)間性、并發(fā)性、嵌套性和度量性等。軟件過程：開發(fā)和維護(hù)軟件及其相關(guān)產(chǎn)品所設(shè)及的一系列活動(dòng)。過程是活動(dòng)的集合；活動(dòng)是任務(wù)的集合；任務(wù)是把輸入轉(zhuǎn)換為輸出的操作。軟件過程

軟件過程提供了一個(gè)框架，在該框架下可以建立一個(gè)軟件開發(fā)的綜合計(jì)劃：若干框架活動(dòng)適用于所有軟件項(xiàng)目，而不在乎其規(guī)模和復(fù)雜性。若干不同任務(wù)的集合----每一個(gè)集合都由任務(wù)、里程碑、交付物以及質(zhì)量保證點(diǎn)組成----使得框架活動(dòng)適應(yīng)于不同軟件項(xiàng)目的特征和項(xiàng)目組的需求。若干保護(hù)性活動(dòng)----如軟件質(zhì)量保證、軟件配置管理、測試與度量----它們貫穿于整個(gè)過程模型之中。保護(hù)性活動(dòng)獨(dú)立于任何一個(gè)框架活動(dòng)，且貫穿于整個(gè)過程之中。軟件過程里程碑、交付物SQA點(diǎn)公共過程框架框架活動(dòng)保護(hù)性活動(dòng)任務(wù)集合工作任務(wù)軟件過程模型軟件過程模型是軟件開發(fā)的指導(dǎo)思想和全局性框架，軟件過程模型的提出和發(fā)展反映了人們對(duì)軟件過程的某種認(rèn)識(shí)觀，體現(xiàn)了人們對(duì)軟件過程認(rèn)識(shí)的提高和飛躍。軟件過程模型瀑布模型強(qiáng)調(diào)階段的劃分及其順序性、各階段工作及其文檔的完備性，是一種嚴(yán)格線性的、按階段順序的、逐步細(xì)化的開發(fā)模式。定義分析設(shè)計(jì)編碼測試維護(hù)軟件過程模型瀑布模型的特點(diǎn)：結(jié)構(gòu)簡單明了；歷史較長、應(yīng)用面廣泛、為廣大軟件工作者所熟悉；已有與之配套的一組十分成熟的開發(fā)方法和豐富的支撐工具。確定了需求分析的絕對(duì)重要性，但是在實(shí)踐中要想獲得完善的需求說明是非常困難的；反饋信息慢。軟件過程模型原型模型的特點(diǎn)：原型作為標(biāo)識(shí)軟件需求的一種機(jī)制，原型被建造僅是為了定義需求，之后就該被拋棄（或至少部分拋棄）；實(shí)際的軟件在充分考慮了質(zhì)量和可維護(hù)性之后才被開發(fā)。軟件過程模型演化軟件過程模型人們已經(jīng)越來越認(rèn)識(shí)到軟件就象所有復(fù)雜系統(tǒng)一樣要經(jīng)過一段時(shí)間的演化。業(yè)務(wù)和產(chǎn)品需求隨著開發(fā)的發(fā)展常常發(fā)生改變，想找到最終產(chǎn)品的一條直線路徑是不可能的。軟件過程模型演化軟件過程模型緊迫的市場期限使得難以完成一個(gè)完善的軟件產(chǎn)品，但可以先提交一個(gè)有限的版本以對(duì)付競爭或商業(yè)的壓力；只要核心產(chǎn)品或系統(tǒng)需求能夠很好地理解，而產(chǎn)品或系統(tǒng)的細(xì)節(jié)部分可以進(jìn)一步定義。軟件過程模型增量模型分析設(shè)計(jì)編碼測試分析設(shè)計(jì)編碼測試分析設(shè)計(jì)編碼測試增量1增量2增量3軟件過程模型增量模型的特點(diǎn)：以功能遞增的方式進(jìn)行軟件開發(fā)能較快地產(chǎn)生可操作的系統(tǒng)；在每一步遞增中，都可以把用戶/開發(fā)者的經(jīng)驗(yàn)結(jié)合到不斷求精的產(chǎn)品中；可改善測試效果和降低軟件開發(fā)總成本。軟件過程模型螺旋模型需求定義評(píng)審風(fēng)險(xiǎn)分析工程實(shí)現(xiàn)軟件過程模型螺旋模型的特點(diǎn)：緊密圍繞開發(fā)中的風(fēng)險(xiǎn)問題，用風(fēng)險(xiǎn)分析推動(dòng)軟件設(shè)計(jì)向深一層擴(kuò)展、求精；強(qiáng)調(diào)持續(xù)地判斷、確定和修改用戶任務(wù)目標(biāo)，并按成本、效益來分析候選的軟件產(chǎn)品性質(zhì)對(duì)任務(wù)目標(biāo)的貢獻(xiàn)；可結(jié)合采用多種軟件開發(fā)方法，但究竟結(jié)合哪一種方法仍由風(fēng)險(xiǎn)分析來決定。軟件過程模型形式化方法模型形式化方法的主要目的是要把軟件開發(fā)過程建立在嚴(yán)密可行的數(shù)學(xué)基礎(chǔ)之上，從而提高軟件質(zhì)量和軟件生產(chǎn)率。事后的或并行的一種輔助手段，用以對(duì)系統(tǒng)的性質(zhì)進(jìn)行嚴(yán)格的驗(yàn)證；集成到軟件開發(fā)過程中，希望在嚴(yán)格的形式系統(tǒng)的基礎(chǔ)上，實(shí)現(xiàn)從需求規(guī)約到程序代碼的轉(zhuǎn)換和過渡。軟件過程管理改進(jìn)軟件過程因此有必要建立一個(gè)軟件過程成熟度模型來對(duì)過程作出一個(gè)客觀、公正的評(píng)價(jià)，以促進(jìn)軟件開發(fā)組織改進(jìn)軟件過程。軟件過程管理軟件過程成熟度指一個(gè)特定的軟件過程被顯式定義、管理、度量、控制和能行的程度。成熟度可以用于指示企業(yè)加強(qiáng)其軟件過程能力的潛力。當(dāng)一個(gè)企業(yè)達(dá)到了一定的軟件過程成熟級(jí)別后，它將通過制定策略、建立標(biāo)準(zhǔn)和確立機(jī)構(gòu)結(jié)構(gòu)使它的軟件過程制度化。而制度化又促使企業(yè)通過建立基礎(chǔ)設(shè)施和公司文化來支持相關(guān)的方法、實(shí)踐和過程。從而使之可以持續(xù)并維持一個(gè)良性循環(huán)。軟件過程管理不成熟企業(yè)的標(biāo)志：缺乏確定的軟件過程和相應(yīng)的管理和控制；即使給出了軟件過程，也不嚴(yán)格的遵循和強(qiáng)制執(zhí)行；管理是完全被動(dòng)的，管理者采用的策略是救火式的，即出了事才去解決，解決的時(shí)候也難以縱觀全局，往往只顧眼前；軟件過程管理不成熟企業(yè)的標(biāo)志：由于缺乏有依據(jù)的估算，制訂軟件預(yù)算和生產(chǎn)計(jì)劃時(shí)往往跟著感覺走，實(shí)際生產(chǎn)時(shí)則常常超標(biāo)；如果強(qiáng)制在預(yù)定期限內(nèi)完成，那么軟件的功能和質(zhì)量肯定是得不到保證；缺乏評(píng)價(jià)軟件產(chǎn)品質(zhì)量和解決產(chǎn)品缺陷和過程問題的客觀基礎(chǔ)。軟件過程管理成熟企業(yè)的標(biāo)志：具有在企業(yè)范圍內(nèi)管理、控制軟件開發(fā)和維護(hù)過程的能力；現(xiàn)有人員和新進(jìn)人員均了解所遵循的軟件過程，且工作活動(dòng)均按照事先的計(jì)劃完成；在定義好的軟件過程中，所有項(xiàng)目和機(jī)構(gòu)中的角色和責(zé)任分明；軟件過程管理成熟企業(yè)的標(biāo)志：制定的計(jì)劃是有效的且與實(shí)際的工作進(jìn)展一致；軟件過程在必要時(shí)可按照一定規(guī)則和程序加以修改；軟件過程管理成熟企業(yè)的標(biāo)志：軟件產(chǎn)品和過程具有一定的可控性：1.管理者能夠監(jiān)督軟件產(chǎn)品的質(zhì)量和生產(chǎn)過程；2.具有客觀的和定量化的措施來判斷產(chǎn)品質(zhì)量并分析產(chǎn)品與生產(chǎn)過程中的問題；3.計(jì)劃和預(yù)算有章可循，它是基于歷史數(shù)據(jù)的，從而是實(shí)際可行的；4.預(yù)算的結(jié)果，包括成本、時(shí)間表、產(chǎn)品功能和質(zhì)量等，通常能夠達(dá)到；5.有關(guān)的參與者完全理解遵循軟件過程的價(jià)值并認(rèn)真地遵循之；6.具有支撐軟件過程的基礎(chǔ)設(shè)施，如標(biāo)準(zhǔn)過程庫、歷史數(shù)據(jù)庫等。

軟件過程管理軟件能力成熟度模型（CapabilityMaturityModel，CMM）軟件能力成熟度模型提美國大學(xué)CarnegieMellonUniversity軟件工程研究所出的一套系統(tǒng)、規(guī)范的對(duì)軟件生產(chǎn)過程進(jìn)行管理的模型，其有效性已為大量實(shí)踐所證實(shí)，并已成為對(duì)一個(gè)軟件企業(yè)的生產(chǎn)能力和產(chǎn)品質(zhì)量進(jìn)行衡量的事實(shí)標(biāo)準(zhǔn)。軟件過程管理軟件能力成熟度模型（CMM）CMM被用來確定一個(gè)機(jī)構(gòu)的軟件過程的成熟程度以及指明如何提高該成熟度的參考模型。CMM描述了軟件過程從無序到有序、從特殊到一般、從定性管理到定量管理、最終到達(dá)可動(dòng)態(tài)優(yōu)化的成熟過程，給出了該過程中五個(gè)成熟階段的基本特征和應(yīng)遵循的原則、采取的行動(dòng)，以幫助軟件機(jī)構(gòu)改進(jìn)其軟件過程。軟件過程管理CMM的主要作用

CMM可以指導(dǎo)軟件機(jī)構(gòu)如何控制軟件產(chǎn)品的開發(fā)和維護(hù)過程，以及如何向成熟的軟件工程體系演化，并形成一套良性循環(huán)的管理文化。具體說來，一個(gè)企業(yè)要想改進(jìn)其生產(chǎn)過程，應(yīng)該采取如下策略和步驟：確定軟件企業(yè)當(dāng)前所處的過程成熟級(jí)別；了解對(duì)改進(jìn)軟件生產(chǎn)質(zhì)量和加強(qiáng)生產(chǎn)過程控制起關(guān)鍵作用的因素；將工作重點(diǎn)集中在有限幾個(gè)關(guān)鍵目標(biāo)上，有效達(dá)到改進(jìn)機(jī)構(gòu)軟件生產(chǎn)過程的效果，進(jìn)而可持續(xù)地改進(jìn)其軟件生產(chǎn)能力。

軟件過程管理CMM的基本前提軟件質(zhì)量在很大程度上取決于產(chǎn)生軟件的軟件過程的質(zhì)量和能力；軟件過程是一個(gè)可管理、可度量并不斷改進(jìn)的過程；軟件過程的質(zhì)量受到用以支撐它的技術(shù)和設(shè)施的影響；企業(yè)在軟件過程中所采用的技術(shù)層次應(yīng)適應(yīng)于軟件過程的成熟度。軟件過程管理CMM的基本原理CMM強(qiáng)調(diào)連續(xù)的軟件過程改進(jìn)。該連續(xù)的改進(jìn)基于多個(gè)演化步驟。CMM將這些演化步驟劃分成五個(gè)級(jí)別。這種分級(jí)結(jié)構(gòu)的理論依據(jù)是軟件質(zhì)量原理。每一級(jí)別都包括若干目標(biāo)。當(dāng)滿足某一目標(biāo)后，軟件過程的相應(yīng)部分便確定下來。五級(jí)成熟度定義了一個(gè)標(biāo)準(zhǔn)，用以度量機(jī)構(gòu)的軟件過程成熟度和評(píng)價(jià)其軟件過程能力。

軟件過程管理CMM的基本內(nèi)容機(jī)構(gòu)和資源的管理：涉及機(jī)構(gòu)本身的責(zé)任，人員和其它資源設(shè)施。軟件工程過程及其管理：涉及軟件工程過程，即軟件過程的深度、范圍和完整性以及如何度量、管理和改進(jìn)這樣的過程。工具和技術(shù)：軟件工程過程中使用的開發(fā)工具和技術(shù)。軟件過程管理CMM的五個(gè)成熟度級(jí)別初始級(jí)可重復(fù)級(jí)：有規(guī)章的過程定義級(jí)：標(biāo)準(zhǔn)化、一致的過程管理級(jí)：可預(yù)測過程優(yōu)化級(jí)：可持續(xù)改進(jìn)的過程軟件過程管理CMM的初始級(jí)（第一級(jí)）成功來源于個(gè)人英雄主義而非機(jī)構(gòu)行為，因此它不可重復(fù)，更換人員后成功便難以維持。軟件過程管理CMM的可重復(fù)級(jí)（第二級(jí)）針對(duì)特定軟件項(xiàng)目建立管理該項(xiàng)目的策略和實(shí)現(xiàn)這些策略的過程。新項(xiàng)目的計(jì)劃和管理基于類似項(xiàng)目的經(jīng)驗(yàn)。軟件過程能力主要通過管理單個(gè)項(xiàng)目的軟件生產(chǎn)過程來得到提高和增強(qiáng)。不同的項(xiàng)目可有不同的軟件過程，機(jī)構(gòu)應(yīng)當(dāng)建立一定的方針和策略以針對(duì)具體的項(xiàng)目選擇合適的軟件生產(chǎn)過程并進(jìn)行管理。軟件過程管理CMM的可重復(fù)級(jí)（第二級(jí)）

可重復(fù)級(jí)的主要特點(diǎn)在于確定了基本的軟件生產(chǎn)管理和控制，具體來講有：結(jié)合已有項(xiàng)目的經(jīng)驗(yàn)和新項(xiàng)目的特點(diǎn)來確定本項(xiàng)目的責(zé)任和承諾；軟件生產(chǎn)成本、時(shí)間表和實(shí)現(xiàn)的功能被有效跟蹤；識(shí)別實(shí)現(xiàn)承諾所需解決的關(guān)鍵問題；定義軟件項(xiàng)目過程標(biāo)準(zhǔn)，機(jī)構(gòu)要確保其被遵守。

軟件過程管理CMM的可重復(fù)級(jí)（第二級(jí)）概括來說，第二級(jí)的主要特點(diǎn)是項(xiàng)目計(jì)劃和跟蹤是確定且有效的，項(xiàng)目的軟件過程是可控的，以及已有的成功經(jīng)驗(yàn)是可重復(fù)的。軟件過程管理CMM的定義級(jí)（第三級(jí)）有一個(gè)機(jī)構(gòu)范圍內(nèi)標(biāo)準(zhǔn)的軟件過程，軟件工程活動(dòng)和管理活動(dòng)被集成為一個(gè)有機(jī)的整體。標(biāo)準(zhǔn)化的目的是使高層管理者和軟件技術(shù)人員能夠有效合作。有一個(gè)組例如軟件工程組（SEPG）專門負(fù)責(zé)訂立機(jī)構(gòu)的標(biāo)準(zhǔn)軟件過程，并且在機(jī)構(gòu)中制定培訓(xùn)計(jì)劃來確保相關(guān)人員和管理者有足夠的知識(shí)和技能完成標(biāo)準(zhǔn)過程所賦予的角色。標(biāo)準(zhǔn)的軟件過程結(jié)合具體項(xiàng)目的特點(diǎn)經(jīng)過裁剪即形成項(xiàng)目定義軟件過程，它是一組集成的完善定義的軟件工程和管理過程。

軟件過程管理CMM的定義級(jí)（第三級(jí)）一個(gè)完善定義的軟件過程應(yīng)包括就緒準(zhǔn)則、輸入、工作過程、驗(yàn)證機(jī)制、輸出和完成準(zhǔn)則。對(duì)于已建立的產(chǎn)品生產(chǎn)線，其成本、時(shí)間表和實(shí)現(xiàn)功能均可跟蹤和控制，軟件產(chǎn)品的質(zhì)量可以得到保證。軟件過程能力的實(shí)現(xiàn)主要基于在機(jī)構(gòu)范圍內(nèi)對(duì)一個(gè)定義軟件過程的活動(dòng)、角色和責(zé)任的共同理解。

軟件過程管理CMM的定義級(jí)（第三級(jí)）概括來說，第三級(jí)的主要特征在于軟件過程已被提升成標(biāo)準(zhǔn)化過程，從而更加具有穩(wěn)定性、重復(fù)性和可控性。軟件過程管理CMM的管理級(jí)（第四級(jí)）軟件的過程和產(chǎn)品有定量的質(zhì)量指標(biāo)：重要的軟件過程活動(dòng)均配有生產(chǎn)率和質(zhì)量方面的度量指標(biāo)；應(yīng)用數(shù)據(jù)庫來收集和分析定義軟件過程中涉及的各種數(shù)據(jù)；對(duì)項(xiàng)目軟件過程和軟件質(zhì)量的評(píng)價(jià)有定量的基準(zhǔn)。軟件過程管理CMM的管理級(jí)（第四級(jí)）軟件項(xiàng)目的產(chǎn)品和生產(chǎn)過程的控制具有可預(yù)測性：將軟件過程效能可能出現(xiàn)的偏差控制在可接受的量化界限內(nèi)；具體區(qū)分影響過程效能發(fā)生偏差的有效因素和偶然因素；向新領(lǐng)域拓展的風(fēng)險(xiǎn)是可預(yù)知的并被仔細(xì)管理和權(quán)衡。軟件過程管理CMM的管理級(jí)（第四級(jí)）概括來說，第四級(jí)的主要特征是定量化、可預(yù)測、異常控制和高質(zhì)量。軟件過程管理CMM的優(yōu)化級(jí)（第五級(jí)）機(jī)構(gòu)集中于持續(xù)的過程改進(jìn)：具有標(biāo)識(shí)過程缺陷和增強(qiáng)過程能力的有效手段。利用試驗(yàn)數(shù)據(jù)分析使用新技術(shù)所需的代價(jià)和帶來的效益，然后再有選擇地采用。當(dāng)出現(xiàn)偏差時(shí)，軟件項(xiàng)目人員能夠分析出錯(cuò)原因并采取有效手段防止其再次出現(xiàn)。防止不必要的浪費(fèi)是第五級(jí)的重點(diǎn)。

軟件過程管理CMM的優(yōu)化級(jí)（第五級(jí)）改進(jìn)的途徑有兩個(gè)，一個(gè)是對(duì)已有過程的漸進(jìn)式改進(jìn)；另一個(gè)則是有選擇地使用新技術(shù)和新方法所帶來的革新。概括來說，第五級(jí)的主要特征是新技術(shù)的采用和軟件過程的改進(jìn)被作為日常的業(yè)務(wù)活動(dòng)來加以計(jì)劃和管理。軟件過程管理如何看待CMM：梯子鏡子牌子補(bǔ)藥軟件質(zhì)量軟件質(zhì)量定義明確聲明的功能和性能需求、明確文檔化過的開發(fā)標(biāo)準(zhǔn)、以及專業(yè)人員開發(fā)的軟件所應(yīng)具有的所有隱含特征都得到滿足。軟件質(zhì)量軟件質(zhì)量定義軟件需求是進(jìn)行“質(zhì)量”度量的基礎(chǔ)。與需求不符就是質(zhì)量不高。指定的標(biāo)準(zhǔn)定義了一組指導(dǎo)軟件開發(fā)的準(zhǔn)則。如果不能遵守這些準(zhǔn)則，就極有可能導(dǎo)致質(zhì)量不高。通常有一組“隱含需求”是不被提及的（如對(duì)維護(hù)性的需求）。如果軟件符合了明確的需求卻沒有滿足隱含需求，軟件質(zhì)量仍然值得懷疑。軟件質(zhì)量軟件質(zhì)量質(zhì)量要素質(zhì)量要素衡量標(biāo)準(zhǔn)衡量標(biāo)準(zhǔn)衡量標(biāo)準(zhǔn)衡量標(biāo)準(zhǔn)度量度量度量度量度量度量度量度量軟件質(zhì)量McCall模型中的軟件質(zhì)量要素產(chǎn)品修改產(chǎn)品變遷產(chǎn)品運(yùn)行易維護(hù)性靈活性易測試性易移植性易復(fù)用性互用性正確性可靠性高效率完整性易使用性軟件質(zhì)量保證

軟件質(zhì)量保證（SQA）是一種應(yīng)用于整個(gè)軟件過程的保護(hù)性活動(dòng)。SQA包括：一種質(zhì)量管理方法有效的軟件工程技術(shù)（方法和工具）在整個(gè)軟件過程中采用的正式技術(shù)復(fù)審一種多層次的測試策略對(duì)軟件文檔及其修改的控制保證遵從軟件開發(fā)標(biāo)準(zhǔn)的規(guī)程度量和報(bào)告機(jī)制SQA小組在一個(gè)組織中有多個(gè)機(jī)構(gòu)負(fù)有保證軟件質(zhì)量的責(zé)任，包括軟件工程師、項(xiàng)目管理者、客戶、銷售人員和SQA小組成員。SQA小組負(fù)責(zé)質(zhì)量保證的計(jì)劃、監(jiān)督、記錄、分析及報(bào)告工作。SQA小組充當(dāng)客戶在公司內(nèi)部的代表。這就是說，SQA小組的成員必須以客戶的觀點(diǎn)看待軟件。SQA計(jì)劃

SQA計(jì)劃為建立軟件質(zhì)量保證提供一張行路圖，其由SQA小組和項(xiàng)目組共同制定，充當(dāng)軟件項(xiàng)目中SQA活動(dòng)的模板。需要進(jìn)行的評(píng)價(jià)；需要進(jìn)行的審計(jì)和復(fù)審；項(xiàng)目可采用的標(biāo)準(zhǔn)；錯(cuò)誤報(bào)告和跟蹤過程；由SQA小組產(chǎn)生的文擋；為軟件項(xiàng)目組提供的反饋數(shù)量。SQA活動(dòng)為項(xiàng)目準(zhǔn)備SQA計(jì)劃；參與開發(fā)該項(xiàng)目的軟件過程描述；復(fù)審各項(xiàng)軟件工程活動(dòng)、對(duì)其是否符合定義好的軟件過程進(jìn)行核實(shí)；審計(jì)指定的軟件工作產(chǎn)品、對(duì)其是否符合定義好的軟件過程中的相應(yīng)部分進(jìn)行核實(shí)；確保軟件工作及工作產(chǎn)品產(chǎn)品中的偏差已被記錄在案，并根據(jù)預(yù)定規(guī)程進(jìn)行處理；記錄所有不符合的部分，并報(bào)告給高級(jí)管理者；協(xié)調(diào)變化的控制和管理，并幫助收集和分析軟件度量信息。軟件配置管理當(dāng)開發(fā)軟件系統(tǒng)的過程中，變化是不可避免的。這些變化使得在同一個(gè)項(xiàng)目中工作的軟件開發(fā)人員之間的彼此不理解程度更加增大。當(dāng)變化進(jìn)行前沒有經(jīng)過分析、變化實(shí)現(xiàn)前沒有被記錄、沒有向那些需要知道的人報(bào)告變化、或變化沒有以可以改善質(zhì)量及減少錯(cuò)誤的方式被控制時(shí)，大量的不理解問題將會(huì)產(chǎn)生。協(xié)調(diào)軟件開發(fā)以減少由變化帶來的不理解性到最小程度的技術(shù)稱為配置管理。軟件配置管理（SCM）是貫穿于整個(gè)軟件過程中的保護(hù)性活動(dòng)。軟件配置管理SCM活動(dòng)內(nèi)容：標(biāo)識(shí)變化控制變化保證變化被適當(dāng)?shù)貙?shí)現(xiàn)向其他可能感興趣的人報(bào)告變化。軟件配置管理明確地區(qū)分軟件維護(hù)和軟件配置管理是很重要的：維護(hù)是發(fā)生在軟件已經(jīng)被交付給客戶、并且投入運(yùn)行后的一系列軟件工程活動(dòng)。軟件配置管理則是當(dāng)軟件項(xiàng)目開始時(shí)就開始、并且僅僅當(dāng)軟件退出運(yùn)行后才終止的一組跟蹤和控制活動(dòng)。軟件配置軟件過程的輸出信息可以分為三個(gè)主要的類別：計(jì)算機(jī)程序（源代碼和可執(zhí)行程序）描述計(jì)算機(jī)程序的文檔（針對(duì)技術(shù)開發(fā)者和用戶）數(shù)據(jù)（包含在程序內(nèi)部和程序外部）。

它們包含了所有在軟件過程中產(chǎn)生的信息，總稱為軟件配置。變化的起源有四種基本的變化源：新的商業(yè)或市場條件，引起產(chǎn)品需求和業(yè)務(wù)規(guī)則的變化。新的客戶需要，要求修改信息系統(tǒng)產(chǎn)生的數(shù)據(jù)、產(chǎn)品提供的功能、或基于計(jì)算機(jī)的系統(tǒng)提供的服務(wù)。改組和/或企業(yè)規(guī)模減小，導(dǎo)致項(xiàng)目優(yōu)先級(jí)或軟件工程隊(duì)伍結(jié)構(gòu)的變化。預(yù)算或進(jìn)度的限制，導(dǎo)致系統(tǒng)或產(chǎn)品的重定義。軟件配置項(xiàng)軟件配置項(xiàng)（SoftwareConfigurationItems,SCI）定義為部分軟件工程過程中創(chuàng)建的信息，在極端情況下，一個(gè)SCI可被考慮為某個(gè)大的規(guī)約中的某個(gè)單獨(dú)段落，或在某個(gè)大的測試用例集中的某種測試用例，更實(shí)際地，一個(gè)SCI是一個(gè)文檔、一個(gè)全套的測試用例、或一個(gè)已命名的程序構(gòu)件（例如，C＋＋函數(shù)或Ada95軟件包）?；€基線是一個(gè)軟件配置管理的概念，它幫助我們?cè)诓粐?yán)重阻礙合理變化的情況下來控制變化。IEEE(IEEEStd.610.12-1990)定義基線如下：已經(jīng)通過正式復(fù)審審核批準(zhǔn)的某規(guī)約或產(chǎn)品，它因此可以作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只能通過正式的變化控制過程而改變?；€在軟件配置項(xiàng)變成基線前，變化可以迅速而非正式地進(jìn)行，然而，一旦基線已經(jīng)建立，我們就得象通過一個(gè)單向開的門那樣，變化可以進(jìn)行，但是，必須應(yīng)用特定的、正式的規(guī)程來評(píng)估和驗(yàn)證每個(gè)變化。在軟件工程的范圍內(nèi)，基線是軟件開發(fā)中的里程碑，其標(biāo)志是有一個(gè)或多個(gè)軟件配置項(xiàng)的交付，且這些SCI已經(jīng)經(jīng)過正式技術(shù)復(fù)審而獲得認(rèn)可。常見的軟件基線系統(tǒng)工程需求定義軟件設(shè)計(jì)編碼測試發(fā)布系統(tǒng)規(guī)約軟件需求規(guī)約設(shè)計(jì)規(guī)約源代碼測試計(jì)劃/過程/數(shù)據(jù)可操作的系統(tǒng)產(chǎn)生基線的流程SCIsSCIsSCIsSCIsSCIs正式技術(shù)復(fù)審SCM控制軟件工程任務(wù)修改認(rèn)可提取存儲(chǔ)項(xiàng)目數(shù)據(jù)庫成為基線的SCIs系統(tǒng)規(guī)約軟件項(xiàng)目計(jì)劃軟件需求規(guī)約圖形分析模型；處理規(guī)約；原型；數(shù)學(xué)規(guī)約初步的用戶手冊(cè)成為基線的SCIs設(shè)計(jì)規(guī)約

數(shù)據(jù)設(shè)計(jì)描述；體系結(jié)構(gòu)設(shè)計(jì)描述；模塊設(shè)計(jì)描述；界面設(shè)計(jì)描述；對(duì)象描述（如果使用面向?qū)ο蠹夹g(shù)）源代碼清單測試規(guī)約測試計(jì)劃和過程；測試用例和結(jié)果記錄操作和安裝手冊(cè)成為基線的SCIs可執(zhí)行程序模塊的可執(zhí)行代碼；鏈接的模塊數(shù)據(jù)庫描述模式和文件結(jié)構(gòu)；初始內(nèi)容聯(lián)機(jī)用戶手冊(cè)維護(hù)文檔軟件問題報(bào)告；維護(hù)請(qǐng)求；工程變化命令軟件工程的標(biāo)準(zhǔn)和規(guī)約成為基線的SCIs除了上面列出的SCI，很多軟件工程組織也將軟件工具列入配置管理之下，即，特定版本的編輯器、編譯器和其他CASE工具被“固定”作為軟件配置的一部分。因?yàn)檫@些工具被用于生成文檔。源代碼和數(shù)據(jù)，所以當(dāng)對(duì)軟件配置進(jìn)行改變時(shí)，必然要用到它們。雖然問題并不多見，但有可能某工具的新版本（如，編譯器）可能產(chǎn)生和原版本不同的結(jié)果。為此，工具就象它們輔助生產(chǎn)的軟件一樣，可以被基線化，并做為綜合的配置管理過程的一部分。SCM過程軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，其主要責(zé)任是控制變化。然而，SCM也負(fù)責(zé)個(gè)體SCI和軟件的各種版本的標(biāo)識(shí)、軟件配置的審計(jì)（以保證它已被適當(dāng)?shù)亻_發(fā)）、以及配置中所有變化的報(bào)告。SCM過程任何關(guān)于SCM的討論均涉及一系列復(fù)雜問題：一個(gè)組織如何標(biāo)識(shí)和管理程序（及其文檔）的很多現(xiàn)存版本，以使得變化可以高效地進(jìn)行？一個(gè)組織如何在軟件被發(fā)布給客戶之前和之后控制變化？誰負(fù)責(zé)批準(zhǔn)變化，并給變化確定優(yōu)先級(jí)？我們?nèi)绾伪ＷC變化已經(jīng)被恰當(dāng)?shù)剡M(jìn)行？采用什么機(jī)制去告知其他人員已經(jīng)實(shí)行的變化？SCM過程SCM五大任務(wù)：標(biāo)識(shí)版本控制變化控制配置審計(jì)報(bào)告。SCM中對(duì)象的標(biāo)識(shí)為了控制和管理軟件配置項(xiàng)，每個(gè)配置項(xiàng)必須被獨(dú)立命名，然后用面向?qū)ο蟮姆椒ńM織。有兩種類型的對(duì)象可以被標(biāo)識(shí)：基本對(duì)象和聚集對(duì)象。基本對(duì)象是軟件工程師在分析、設(shè)計(jì)、編碼或測試中創(chuàng)建的“文本單元（unitoftext）”，例如，一個(gè)基本對(duì)象可能是需求規(guī)約的一個(gè)段落、模塊的源程序清單或一組用于測試代碼的測試用例。一個(gè)聚集對(duì)象是基本對(duì)象和其他聚集對(duì)象的集合。SCM中對(duì)象的標(biāo)識(shí)每個(gè)對(duì)象均具有一組唯一地標(biāo)識(shí)它的、獨(dú)特的特征：名字、描述、資源表、以及“現(xiàn)實(shí)”。對(duì)象名是無二義性地標(biāo)識(shí)對(duì)象的一個(gè)字符串；對(duì)象描述是一個(gè)數(shù)據(jù)項(xiàng)的列表，它們標(biāo)識(shí)：該對(duì)象所表示的SCI類型（如，文檔、程序、數(shù)據(jù)）；項(xiàng)目標(biāo)識(shí)符；以及變化和/或版本信息；資源是由對(duì)象提供、處理、引用或需要的實(shí)體，例如，數(shù)據(jù)類型、特定函數(shù)、或甚至變量名也可以作為對(duì)象資源；現(xiàn)實(shí)是一個(gè)指針，對(duì)基本對(duì)象而言指向“文本單元”，對(duì)聚集對(duì)象而言則指向null。SCM中對(duì)象的標(biāo)識(shí)配置對(duì)象的標(biāo)識(shí)也必須考慮存在于命名對(duì)象之間的關(guān)系，一個(gè)對(duì)象可被標(biāo)識(shí)為某聚集對(duì)象的<part-of>，關(guān)系<part-of>定義了一個(gè)對(duì)象層次。對(duì)于軟件對(duì)象的標(biāo)識(shí)模式必須認(rèn)可對(duì)象在整個(gè)軟件過程中的演化，在一個(gè)對(duì)象被確定為基線前，它可能會(huì)變化很多次，甚至在基線已經(jīng)建立后，變化也可能經(jīng)常發(fā)生。有可能為任意對(duì)象創(chuàng)建一個(gè)演化圖，演化圖描速了對(duì)象的變化歷史。SCM中對(duì)象的標(biāo)識(shí)obj1.0obj1.1obj1.2obj1.3obj1.4obj2.0obj2.1obj1.1.1Obj1.1.2對(duì)象演化圖SCM中的版本控制版本控制結(jié)合了規(guī)程和工具以管理在軟件工程中所創(chuàng)建的配置對(duì)象的不同版本。SCM中的版本控制可以描述如下：配置管理使得用戶能夠通過對(duì)適當(dāng)版本的選擇來指定可選的軟件系統(tǒng)的配置，這一點(diǎn)的實(shí)現(xiàn)是通過將屬性關(guān)聯(lián)到每個(gè)軟件版本上，然后通過描述一組所期望的屬性來指定（和構(gòu)造）配置的。SCM中的變化控制對(duì)于大型的軟件開發(fā)項(xiàng)目，無控制的變化將迅速導(dǎo)致混亂，SCM變化控制結(jié)合人的規(guī)程和自動(dòng)化工具以提供一個(gè)變化控制的機(jī)制。SCM中的變化控制一個(gè)變化請(qǐng)求被提交和評(píng)估，以評(píng)價(jià)技術(shù)指標(biāo)、潛在副作用、對(duì)其他配置對(duì)象和系統(tǒng)功能的整體影響、以及對(duì)于變化的成本預(yù)測。評(píng)估的結(jié)果以變化報(bào)告的形式給出，該報(bào)告被變化控制審核者（changecontrolauthority,CCA）----對(duì)變化的狀態(tài)及優(yōu)先級(jí)作最終決策的人或小組----使用。對(duì)每個(gè)被批準(zhǔn)的變化生成一個(gè)過程變化命令（engineeringchangeorder,ECO），ECO描述了將要進(jìn)行的變化、必須注意的約束、以及復(fù)審和審計(jì)的標(biāo)準(zhǔn)。將被修改的對(duì)象從項(xiàng)目數(shù)據(jù)庫“提取（checkout）”出來，進(jìn)行修改，并應(yīng)用于合適的SQA活動(dòng)，然后，將對(duì)象“提交（checkin）”進(jìn)數(shù)據(jù)庫，并使用合適的版本控制機(jī)制去建立軟件的下一個(gè)版本。SCM中的變化控制“提交”和“提取”過程實(shí)現(xiàn)了兩個(gè)主要的變化控制要素----訪問控制和同步控制：訪問控制管理哪個(gè)軟件工程師有權(quán)限去訪問和修改某特定的配置對(duì)象。同步控制幫助保證由兩個(gè)不同人員完成的并行修改不會(huì)互相覆蓋。SCM中的變化控制基于一個(gè)被批準(zhǔn)的變化請(qǐng)求和ECO，軟件工程師提取出配置對(duì)象，訪問控制功能保證該軟件工程師有權(quán)限提取該對(duì)象，而同步控制對(duì)項(xiàng)目數(shù)據(jù)庫中的該對(duì)象加鎖，使得當(dāng)前提取出的版本在被放回以前不能對(duì)它作任何其他修改。注意，可以提取出其他的備份，但是，不能進(jìn)行其他修改。SCM中的變化控制非正式變化控制：

在SCI變成基線以前，只需要進(jìn)行非正式的變化控制。配置對(duì)象（SCI）的開發(fā)者可以進(jìn)行任何被管理和技術(shù)需求證明是合適的修改（只要修改不會(huì)影響到在開發(fā)者工作范圍之外的更廣的系統(tǒng)需求），一旦對(duì)象已經(jīng)經(jīng)過正式的技術(shù)復(fù)審并已被認(rèn)可，則創(chuàng)建了一個(gè)基線。SCM中的變化控制項(xiàng)目級(jí)變化控制：

一旦SCI變成基線，則項(xiàng)目級(jí)的變化控制就開始實(shí)施了。這時(shí)，為了進(jìn)行修改，開發(fā)者必須獲得項(xiàng)目管理者的批準(zhǔn)（如果變化是“局部的”），或CCA的批準(zhǔn)（如果該變化影響到其他SCI）。在某些情況下，變化需求、變化報(bào)告和ECO的正式生成可以省略，然而，需要管理對(duì)每個(gè)變化的評(píng)價(jià)，并對(duì)所有變化進(jìn)行跟蹤和復(fù)審。SCM中的變化控制正式的變化控制：

當(dāng)軟件產(chǎn)品發(fā)布給客戶時(shí)，正式的變化控制就開始實(shí)施了SCM中的變化控制變化控制審核者（CCA）在第二和第三層控制上扮演了活躍的角色，依賴于軟件項(xiàng)目的規(guī)模和性質(zhì)，CCA可能包含一個(gè)人----項(xiàng)目管理者----或一組人（如，來自軟件、硬件、數(shù)據(jù)庫工程、支持、市場等五方面的代表）。CCA的角色是從全局的觀點(diǎn)來評(píng)估變化對(duì)SCI之外的事務(wù)的影響：變化將如何影響硬件？變化將如何影響性能？變化將如何改變客戶對(duì)產(chǎn)品的感覺？變化將如何影響產(chǎn)品的質(zhì)量和可靠性？這些和很多其他的問題需被CCA處理。SCM中的配置審計(jì)標(biāo)識(shí)、版本控制和變化控制幫助軟件開發(fā)者維持秩序，否則情況可能將是混亂和不固定的。然而，即使最成功的控制機(jī)制也只能在ECO產(chǎn)生后才可以跟蹤變化。我們?nèi)绾螏椭兓缓线m的實(shí)現(xiàn)呢？回答是兩方面的：（1）正式的技術(shù)復(fù)審；（2）軟件配置審計(jì)。SCM中的配置審計(jì)正式的技術(shù)復(fù)審關(guān)注已經(jīng)被修改的配置對(duì)象的技術(shù)正確性，復(fù)審者評(píng)估SCI以確定它與其他SCI的一致性、遺漏、及潛在的副作用，正式的復(fù)審應(yīng)該對(duì)所有的變化進(jìn)行，除了那些最瑣碎的變化之外。SCM中的配置審計(jì)

軟件配置審計(jì)通過評(píng)估配置對(duì)象的通常不在復(fù)審中考慮的特征，而形成正式復(fù)審的補(bǔ)充。審計(jì)詢問并回答如下問題：在ECO中說明的變化已經(jīng)完成了嗎？加入了任意附加的修改嗎？是否已經(jīng)進(jìn)行了正式的技術(shù)復(fù)審，以評(píng)估技術(shù)的正確性？是否適當(dāng)?shù)刈裱塑浖こ虡?biāo)準(zhǔn)？變化在SCI中被“顯著地強(qiáng)調(diào)（highlighted）”了嗎？是否指出了變化的日期和變化的作者？配置對(duì)象的屬性反應(yīng)了變化嗎？是否遵循了標(biāo)注變化、記錄變化并報(bào)告變化的SCM規(guī)程？所有相關(guān)的SCI被適當(dāng)修改了嗎？在某些情況下，審計(jì)問題被作為正式的技術(shù)復(fù)審的一部分而詢問，然而，當(dāng)SCM是一個(gè)正式的活動(dòng)時(shí)，SCM審計(jì)由質(zhì)量保證組單獨(dú)進(jìn)行。SCM中的狀態(tài)報(bào)告配置狀態(tài)報(bào)告（Configurationstatusreporting,有時(shí)稱為statusaccounting）是一個(gè)SCM任務(wù)，它回答下列問題：發(fā)生了什么事？誰做的此事？此事是什么時(shí)候發(fā)生的？將影響別的什么嗎？SCM中的狀態(tài)報(bào)告配置狀態(tài)報(bào)告(CSR)的信息流如下：每次當(dāng)一個(gè)SCI被賦上新的和修改后的標(biāo)識(shí)時(shí)，則一個(gè)CSR條目被創(chuàng)建；每次當(dāng)一個(gè)變化被CCA批準(zhǔn)時(shí)（即，一個(gè)ECO產(chǎn)生），一個(gè)CSR條目被創(chuàng)建；每次當(dāng)配置審計(jì)進(jìn)行時(shí)，其結(jié)果作為CSR任務(wù)的一部分被報(bào)告。CSR的輸出可以放置到一個(gè)聯(lián)機(jī)數(shù)據(jù)庫中，使得軟件開發(fā)者或維護(hù)者可以通過關(guān)鍵詞分類訪問變化信息。此外，CSR報(bào)告被定期生成，并允許管理者和開發(fā)者評(píng)估重要的變化。SCM中的狀態(tài)報(bào)告配置狀況報(bào)告在大型軟件開發(fā)項(xiàng)目的成功中扮演了重要角色，當(dāng)涉及到很多人員時(shí)，有可能會(huì)發(fā)生“左手不知道右手在做什么”的綜合癥：兩個(gè)開發(fā)者可能試圖以不同的或沖突的意圖去修改同一個(gè)SCI；軟件工程隊(duì)伍可能花費(fèi)幾個(gè)月的工作量針對(duì)過時(shí)的硬件規(guī)約建造軟件；能認(rèn)識(shí)到被建議的修改有嚴(yán)重副作用的人并不知道該修改已經(jīng)進(jìn)行。CSR通過改善所有相關(guān)人員之間的通信，幫助排除這些問題。SCM標(biāo)準(zhǔn)在過去20年中，已經(jīng)提出了一系列的軟件配置管理標(biāo)準(zhǔn)。很多早期的SCM標(biāo)準(zhǔn)，如MIL-STD-483、DOD-STD-480A、和MIL-STD—1521A，主要用于為軍事用途而開發(fā)的軟件。然而，最近的ANSI/IEEE標(biāo)準(zhǔn)，如ANSI/IEEEStd.No.828-1983，No.1042-1987，和Std.No.1028-1988，可應(yīng)用于商業(yè)軟件，并被向大型的和小型的軟件工程組織推薦。軟件項(xiàng)目管理項(xiàng)目管理的基本概念軟件項(xiàng)目估算風(fēng)險(xiǎn)管理項(xiàng)目進(jìn)度安排及跟蹤軟件項(xiàng)目管理軟件項(xiàng)目管理是軟件工程的保護(hù)性活動(dòng)，它先于任何技術(shù)活動(dòng)之前開始，并且持續(xù)貫穿于整個(gè)計(jì)算機(jī)軟件的定義、開發(fā)和維護(hù)之中。項(xiàng)目管理的范圍有效的項(xiàng)目管理集中于三個(gè)P上：人員（people）問題（problem）過程（process）其順序不是任意的。任何管理者如果忘記了軟件工程是人的智力密集的勞動(dòng)，他就永遠(yuǎn)不可能在項(xiàng)目管理上取得成功；任何管理者如果在項(xiàng)目開發(fā)早期沒有支持有效的用戶通信，他有可能為錯(cuò)誤的問題構(gòu)造一個(gè)不錯(cuò)的解決方案。最后，對(duì)過程不在意的管理者可能冒把有效的技術(shù)和工具插入到真空中的危險(xiǎn)。項(xiàng)目管理的人員項(xiàng)目參與者項(xiàng)目負(fù)責(zé)人軟件項(xiàng)目組項(xiàng)目參與者高級(jí)管理者：負(fù)責(zé)確定商業(yè)問題，這些問題往往對(duì)項(xiàng)目產(chǎn)生很大影響。項(xiàng)目（技術(shù)）管理者：必須計(jì)劃、激勵(lì)、組織和控制軟件開發(fā)人員。開發(fā)人員：負(fù)責(zé)開發(fā)一個(gè)產(chǎn)品或應(yīng)用軟件所需的專門技術(shù)人員?？蛻簦贺?fù)責(zé)說明待開發(fā)軟件的需求的人員。最終用戶：一旦軟件發(fā)布成為產(chǎn)品，最終用戶是直接與軟件進(jìn)行交互的人。項(xiàng)目負(fù)責(zé)人解決問題：一個(gè)有效的軟件項(xiàng)目負(fù)責(zé)人應(yīng)該能夠準(zhǔn)確地診斷出技術(shù)的和管理的問題；系統(tǒng)地計(jì)劃解決方案；適當(dāng)?shù)丶?lì)其他開發(fā)人員實(shí)現(xiàn)解決方案；把從以前的項(xiàng)目中學(xué)到的經(jīng)驗(yàn)應(yīng)用到新的環(huán)境下；如果最初的解決方案沒有結(jié)果，能夠靈活地改變方向。管理能力：一個(gè)好的項(xiàng)目負(fù)責(zé)人必須掌管整個(gè)項(xiàng)目，他在必要時(shí)必須有信心進(jìn)行控制，必須保證讓優(yōu)秀的技術(shù)人員能夠按照他們的本性行事。項(xiàng)目負(fù)責(zé)人激勵(lì)能力：為了提高項(xiàng)目組的生產(chǎn)率，項(xiàng)目負(fù)責(zé)人必須獎(jiǎng)勵(lì)具有主動(dòng)性和作出成績的人。并通過自己的行為表明約束下的冒險(xiǎn)不會(huì)受到懲罰。理解和控制能力：一個(gè)有效的項(xiàng)目負(fù)責(zé)人必須能夠“讀懂”人；他必須能夠理解語言的和非語言的信號(hào)，并對(duì)發(fā)出這些信號(hào)的人的要求做出反應(yīng)。項(xiàng)目負(fù)責(zé)人必須在高壓力環(huán)境下保持良好的控制能力。軟件項(xiàng)目組項(xiàng)目分配人力資源的若干可選方案，設(shè)該項(xiàng)目需要n個(gè)人工作k年：n個(gè)人被分配來完成m個(gè)不同的功能任務(wù)，相對(duì)而言幾乎沒有合作的情況發(fā)生；協(xié)調(diào)是軟件管理者的責(zé)任，而他可能同時(shí)還有六個(gè)其他項(xiàng)目要管。n個(gè)人被分配來完成m個(gè)不同的功能任務(wù)（m<n），建立非正式的小組；指定一個(gè)專門的小組負(fù)責(zé)人；小組之間的協(xié)調(diào)由軟件管理者負(fù)責(zé)。n個(gè)人被分成t個(gè)小組；每一個(gè)小組完成一個(gè)或多個(gè)功能任務(wù)；每一個(gè)小組有一個(gè)特定的結(jié)構(gòu)，該結(jié)構(gòu)是為同一個(gè)項(xiàng)目的所有小組定義的；協(xié)調(diào)工作由小組和軟件項(xiàng)目管理者共同控制。軟件項(xiàng)目組軟件工程小組的組織方式：民主分權(quán)式（DemocraticDecentralized,DD）：這種軟件工程小組沒有固定的負(fù)責(zé)人。任務(wù)協(xié)調(diào)者是短期指定的，之后就由其他協(xié)調(diào)不同任務(wù)的人取代。問題和解決方法的確定是由小組討論決策的?？刂品謾?quán)式（ControlledDecentralized,CD）：這種軟件工程小組有一個(gè)固定的負(fù)責(zé)人，他協(xié)調(diào)特定的任務(wù)及負(fù)責(zé)子任務(wù)的二級(jí)負(fù)責(zé)人關(guān)系。問題解決仍是一個(gè)群體活動(dòng)，但解決方案的實(shí)現(xiàn)是有小組負(fù)責(zé)人在子組之間進(jìn)行劃分的。子組和個(gè)人間的通信是平行的，但也會(huì)發(fā)生沿著控制層產(chǎn)生的上下級(jí)的通信?？刂萍瘷?quán)式（ControlledCentralized,CC）：頂層的問題解決和內(nèi)部小組協(xié)調(diào)是由小組負(fù)責(zé)人管理的。負(fù)責(zé)人和小組成員之間的通信是上下級(jí)式的。軟件項(xiàng)目組計(jì)劃軟件工程小組結(jié)構(gòu)時(shí)應(yīng)該考慮的因素：待解決問題的困難程度；要生成的程序的規(guī)模，以代碼行或功能點(diǎn)來衡量；小組成員需要待在一起的時(shí)間（小組生命期）；問題能夠被模塊化的程度；待開發(fā)系統(tǒng)所要求的質(zhì)量和可靠性；交付日期的嚴(yán)格程度；項(xiàng)目所需要的社交性（通信）的程度。軟件項(xiàng)目組因?yàn)榧惺降慕Y(jié)構(gòu)能夠更快地完成任務(wù)，因此最適合處理簡單問題。而分散式的小組比起個(gè)人而言能夠產(chǎn)生更多更好的解決方案，因此這種小組在處理復(fù)雜問題時(shí)成功的可能性更大。因?yàn)镃D小組是集中式地解決問題，所以CD或CC小組結(jié)構(gòu)能夠成功地用來解決簡單的問題。而DD結(jié)構(gòu)則適合于解決難度較大的問題。因?yàn)樾〗M的性能與必須進(jìn)行的通信量成反比，所以如果子組很容易協(xié)調(diào)的話，很大的項(xiàng)目最好采用CC或CD結(jié)構(gòu)的小組組織方式。軟件項(xiàng)目組DD小組結(jié)構(gòu)最適合于解決模塊化程度較低的問題，因?yàn)樗枰嗟耐ㄐ?。如果有可能要較高的模塊化程度，則CC或CD結(jié)構(gòu)更加合適。CC和CD小組已被發(fā)現(xiàn)能夠產(chǎn)生比DD小組更少的缺陷，但這與小組所采用的質(zhì)量保證活動(dòng)密切相關(guān)。分散式結(jié)構(gòu)通常需要比集中式結(jié)構(gòu)更多的時(shí)間來完成一個(gè)項(xiàng)目，但是如果要求高社交性，它是最合適的。軟件項(xiàng)目組軟件工程小組的組織范型：封閉式范型：按照傳統(tǒng)的權(quán)利層次來組織小組（類似CC小組）。這種小組在開發(fā)與過去已經(jīng)做過的產(chǎn)品類似的軟件時(shí)十分有效，但這種封閉式范型下難以進(jìn)行創(chuàng)新式的工作。隨機(jī)式范型：松散地組織小組，并依賴于小組成員個(gè)人的主動(dòng)性。當(dāng)需要?jiǎng)?chuàng)新或技術(shù)上的突破時(shí)，按照這種隨機(jī)式范型組織的小組很有優(yōu)勢。但當(dāng)需要“有次序的執(zhí)行”才能完成工作時(shí)，這種小組組織范型就會(huì)陷入困境。軟件項(xiàng)目組軟件工程小組的組織范型：開放式范型：試圖以一種既具有封閉式范型的控制性、又包含隨機(jī)式范型的創(chuàng)新性的方式來組織小組。工作的執(zhí)行結(jié)合了大量的通信和基于小組一致意見的決策。開放式范型小組結(jié)構(gòu)特別適合于解決復(fù)雜問題，但可能不象其他類型小組那么效率高。同步式范型：依賴于問題的自然劃分，組織小組成員各自解決問題的片段，他們之間沒有什么主動(dòng)的通信需求。協(xié)調(diào)和通信問題有很多原因會(huì)使軟件項(xiàng)目陷入困境。許多開發(fā)項(xiàng)目規(guī)模宏大，以至于使小組成員間的關(guān)系復(fù)雜性高混亂、難以協(xié)調(diào)。不確定性是經(jīng)常存在的，它會(huì)引起困擾項(xiàng)目組的一連串的改變。軟件工程小組必須建立有效的方法，以協(xié)調(diào)參與工作的人員之間的關(guān)系。要完成這項(xiàng)任務(wù)，必須建立小組成員之間及多個(gè)小組之間的正式的和非正式的通信機(jī)制。正式的通信是通過文字、會(huì)議及其他相對(duì)而言非交互和非個(gè)人的通信渠道來實(shí)現(xiàn)。非正式的通信則更加個(gè)人化。軟件工程小組的成員在一個(gè)特別的基礎(chǔ)上共享想法，出現(xiàn)問題時(shí)相互幫助，且每天相互交流。項(xiàng)目協(xié)調(diào)技術(shù)正式的、非個(gè)人的方法：包括軟件工程文檔和交付物（如源程序）、技術(shù)備忘錄、項(xiàng)目里程碑、進(jìn)度和項(xiàng)目控制工具、修改請(qǐng)求及相關(guān)文檔、錯(cuò)誤跟蹤報(bào)告、中心庫數(shù)據(jù)。正式的、個(gè)人間的規(guī)程：集中表現(xiàn)于軟件工程工作中產(chǎn)品的質(zhì)量保證活動(dòng)中，包括狀態(tài)復(fù)審會(huì)議及設(shè)計(jì)和代碼檢查。非正式的、個(gè)人間的規(guī)程：包括信息傳播、問題解決的小組會(huì)議。電子通信：包括電子郵件、電子公告欄、Web站點(diǎn)以及基于視頻的會(huì)議系統(tǒng)。個(gè)人間的網(wǎng)絡(luò)：與項(xiàng)目組之外的人進(jìn)行的非正式的討論，這些人可能有足夠的經(jīng)驗(yàn)或見解，能夠幫助項(xiàng)目組成員。項(xiàng)目管理的問題

軟件項(xiàng)目管理者從軟件項(xiàng)目一開始就面臨著進(jìn)退兩難的局面。需要定量的估算成本和有組織的計(jì)劃項(xiàng)目的進(jìn)展，但卻沒有可靠的信息可以使用。對(duì)軟件需求的詳細(xì)分析可以提供必要的估算信息，但分析常常要花數(shù)周甚至數(shù)月的時(shí)間才能完成。更糟糕的是，隨著項(xiàng)目的進(jìn)展經(jīng)常發(fā)生改變，需求可能是不固定的。軟件范圍

軟件項(xiàng)目管理的第一個(gè)活動(dòng)是軟件范圍的確定。范圍是通過回答下列問題來定義的：背景：待開發(fā)的軟件如何適應(yīng)大型的系統(tǒng)、產(chǎn)品或商業(yè)的背景，在該背景下要加什么約束？信息目標(biāo)：軟件要產(chǎn)生什么樣的客戶可見的數(shù)據(jù)對(duì)象來作為輸出使用？需要什么樣的數(shù)據(jù)對(duì)象作為輸入？功能和性能：軟件要執(zhí)行什么樣的功能使得輸入數(shù)據(jù)才能變換為輸出數(shù)據(jù)？需要滿足什么特殊的性能特征嗎？軟件范圍軟件項(xiàng)目范圍在管理層和技術(shù)層都必須是無二義性的和可理解的。對(duì)軟件范圍的描述必須是確定的。即，明確給出定量的數(shù)據(jù)（如并發(fā)用戶數(shù)目、郵件列表的大小、允許的最大響應(yīng)時(shí)間）；說明約束和/或限制（如產(chǎn)品成本、內(nèi)存大?。?；描述其他的特殊因素（如要用的算法能夠很好地理解，并寫成C++程序）。問題分解問題分解，有時(shí)稱為劃分，是一個(gè)軟件需求分析的核心活動(dòng)。在確定軟件范圍的活動(dòng)中并沒有完全分解問題。分解一般用于兩個(gè)主要領(lǐng)域：（1）必須交付的功能；（2）交付所用的過程。面對(duì)復(fù)雜的問題人們常常采用分而治之的策略。簡單講，就是將一個(gè)復(fù)雜的問題劃分成若干較易處理的小問題。這是項(xiàng)目計(jì)劃開始時(shí)所采用的策略。在估算開始之前，范圍中所描述的軟件功能必須被評(píng)估和精化，以提供更多的細(xì)節(jié)。因?yàn)槌杀竞瓦M(jìn)度估算都是面向功能的，所以某種程度的分解是很有用的。項(xiàng)目管理的過程軟件過程的一般階段（定義、開發(fā)和維護(hù)）適用于所有軟件項(xiàng)目。問題在于如何選擇一個(gè)合適項(xiàng)目組要開發(fā)的軟件過程模型。項(xiàng)目管理者必須決定哪一個(gè)過程模型最適合待開發(fā)項(xiàng)目，然后基于公共過程框架活動(dòng)集合，定義一個(gè)初步的計(jì)劃，便可以開始進(jìn)行過程分解，即建立一個(gè)完整的計(jì)劃，以反映框架活動(dòng)中所需要的工作任務(wù)。合并問題和過程項(xiàng)目計(jì)劃開始于問題和過程的合并。軟件項(xiàng)目組要開發(fā)的每一個(gè)功能都必須通過為軟件組織定義的框架活動(dòng)集合來完成。項(xiàng)目疲憊不堪的產(chǎn)業(yè)專家們?cè)谟懻撎貏e困難的軟件項(xiàng)目時(shí)，常常提及90-90規(guī)則：一個(gè)系統(tǒng)的第一個(gè)90%花費(fèi)了所分配工作量和時(shí)間的90%，系統(tǒng)最后10%也會(huì)花費(fèi)所分配工作量和時(shí)間的90%。項(xiàng)目評(píng)估進(jìn)度所采用的方法是有缺陷的（很顯然，如果90-90規(guī)則是真的，90%的完成度就不是一個(gè)準(zhǔn)確的指標(biāo)）。沒有辦法測定進(jìn)度，因?yàn)闆]有可用的、量化的度量。項(xiàng)目計(jì)劃在項(xiàng)目結(jié)束時(shí)沒有考慮協(xié)調(diào)所需要的資源。沒有明確地考慮風(fēng)險(xiǎn)，沒有建立緩解、監(jiān)控和管理風(fēng)險(xiǎn)的計(jì)劃。進(jìn)度計(jì)劃是不現(xiàn)實(shí)或有缺陷的。為了克服這些問題，在項(xiàng)目開始時(shí)必須花時(shí)間建立一個(gè)現(xiàn)實(shí)的計(jì)劃，在項(xiàng)目進(jìn)行中監(jiān)控該計(jì)劃，并在項(xiàng)目整個(gè)過程中控制質(zhì)量和變化。軟件項(xiàng)目估算軟件項(xiàng)目管理過程從一組稱為項(xiàng)目計(jì)劃的活動(dòng)開始，這些活動(dòng)中的第一個(gè)就是估算。無論何時(shí)進(jìn)行估算，我們都是在預(yù)測未來，并會(huì)接受某種程度的不確定性。雖然估算是一門科學(xué)，但它更是一門藝術(shù)，但這個(gè)重要的活動(dòng)不能以隨意的方式進(jìn)行，因?yàn)楣浪闶撬衅渌?xiàng)目計(jì)劃活動(dòng)的基礎(chǔ)。軟件項(xiàng)目估算項(xiàng)目管理者應(yīng)該具備的素質(zhì)：具有在錯(cuò)誤真正發(fā)生之前就知道它的能力。在未來還是一團(tuán)迷霧的時(shí)候就有勇氣進(jìn)行估算。軟件項(xiàng)目估算估算一個(gè)軟件開發(fā)工作的資源、成本和進(jìn)度需要：經(jīng)驗(yàn)了解以前的有用信息當(dāng)僅存在定性的數(shù)據(jù)時(shí)進(jìn)行定量測量的勇氣估算具有與生俱來的風(fēng)險(xiǎn)，而正是這種風(fēng)險(xiǎn)導(dǎo)致了不確定性。軟件項(xiàng)目估算影響估算的因素：項(xiàng)目復(fù)雜性對(duì)計(jì)劃中固有的不確定性產(chǎn)生重大影響，復(fù)雜性是一個(gè)受到對(duì)以前工作的熟悉程度影響的相對(duì)的測量。項(xiàng)目規(guī)模影響估算準(zhǔn)確性，隨著規(guī)模的增長，軟件中各個(gè)元素之間的相互依賴性也迅速增加。項(xiàng)目規(guī)模的增長會(huì)對(duì)項(xiàng)目成本和進(jìn)度產(chǎn)生幾何級(jí)數(shù)的影響。結(jié)構(gòu)不確定性的程度也會(huì)對(duì)估算的風(fēng)險(xiǎn)產(chǎn)生影響。這里結(jié)構(gòu)是指：需求能被確定的程度，功能能被分解的容易程度，以及需要加工的信息的層次性。軟件項(xiàng)目估算影響估算的因素：歷史信息的可用程度也決定了估算的風(fēng)險(xiǎn)。當(dāng)存在大量可用的關(guān)于過去項(xiàng)目的軟件度量時(shí)，估算就會(huì)有更大的保證。風(fēng)險(xiǎn)是由為資源、成本及進(jìn)度建立的定性估算中存在的不確定性來測量的。如果對(duì)項(xiàng)目范圍理解很差或需求不斷變化，不確定性及風(fēng)險(xiǎn)就會(huì)很高。應(yīng)該滿足于事物的本性所能容許的精確度，當(dāng)只能近似于真理時(shí)，不要去尋求絕對(duì)的準(zhǔn)確。軟件項(xiàng)目估算軟件項(xiàng)目計(jì)劃的目標(biāo)是提供一個(gè)框架，使得管理者能夠?qū)Y源、成本及進(jìn)度進(jìn)行合理的估算。估算是在軟件項(xiàng)目開始時(shí)在一個(gè)限定的時(shí)間框架內(nèi)所做的，并且隨著項(xiàng)目的進(jìn)展不斷更新。估算應(yīng)該定義“最好的情況”和“最壞的情況”，使得項(xiàng)目的結(jié)果能夠限制在一定范圍內(nèi)。軟件項(xiàng)目估算軟件成本及工作量估算永遠(yuǎn)不會(huì)是一門精確的科學(xué)。太多的變化--人員、技術(shù)、環(huán)境、策略影響了軟件的最終成本及開發(fā)所需的工作量。軟件項(xiàng)目估算途徑將估算拖延到項(xiàng)目的最后階段（顯然，如果在項(xiàng)目完成之后進(jìn)行估算，能夠贏得100%的準(zhǔn)確率）?；谝呀?jīng)完成的類似的項(xiàng)目進(jìn)行估算。使用簡單的“分解技術(shù)”進(jìn)行項(xiàng)目成本和工作量估算。使用一個(gè)或多個(gè)經(jīng)驗(yàn)?zāi)Ｐ瓦M(jìn)行軟件成本和工作量的估算。軟件項(xiàng)目估算途徑分解技術(shù)采用“分而治之”的策略進(jìn)行軟件項(xiàng)目估算。將項(xiàng)目分解成若干主要的功能及相關(guān)的軟件工程活動(dòng)，通過逐步求精的方式進(jìn)行成本及工作量估算。經(jīng)驗(yàn)估算模型可用于補(bǔ)充分解技術(shù)，并提供一種潛在有價(jià)值的估算方法。該模型是基于經(jīng)驗(yàn)（歷史數(shù)據(jù)）來進(jìn)行的，可以用以下公式表示：d=f(v)其中d是要估算的值（如工作量、成本、項(xiàng)目持續(xù)時(shí)間），v是選擇出來的獨(dú)立參數(shù)（如被估算的代碼行或功能點(diǎn)）。軟件的估算參量取決于用于估算的歷史數(shù)據(jù)。若沒有歷史數(shù)據(jù)存在，成本估算也就建立在一個(gè)很不穩(wěn)定的基礎(chǔ)之上。風(fēng)險(xiǎn)管理風(fēng)險(xiǎn)關(guān)注未來將要發(fā)生的事情。風(fēng)險(xiǎn)涉及改變（如思想、觀念、行為或地點(diǎn)的改變）。風(fēng)險(xiǎn)涉及選擇及選擇本身所包含的不確定性。風(fēng)險(xiǎn)管理當(dāng)沒有辦法消除風(fēng)險(xiǎn)，甚至連試圖降低該風(fēng)險(xiǎn)也存在疑問時(shí)，這些風(fēng)險(xiǎn)就是真正的風(fēng)險(xiǎn)了。在能夠標(biāo)識(shí)出軟件項(xiàng)目中的“真正風(fēng)險(xiǎn)”之前，識(shí)別出所有對(duì)管理者及開發(fā)者而言均為明顯的風(fēng)險(xiǎn)是很重要的。被動(dòng)和主動(dòng)的風(fēng)險(xiǎn)策略被動(dòng)策略：風(fēng)險(xiǎn)變成現(xiàn)實(shí)后才處理，“救火模式”。主動(dòng)策略：預(yù)防為主。標(biāo)識(shí)出潛在風(fēng)險(xiǎn)，評(píng)估它們出現(xiàn)的概率和產(chǎn)生的影響，且按重要性加以排序。然后，軟件項(xiàng)目組建立一個(gè)計(jì)劃來管理風(fēng)險(xiǎn)。軟件風(fēng)險(xiǎn)不確定性：刻劃風(fēng)險(xiǎn)的事件可能發(fā)生也不可能發(fā)生。損失：如果風(fēng)險(xiǎn)變成了現(xiàn)實(shí)，就會(huì)產(chǎn)生惡性后果或損失。進(jìn)行風(fēng)險(xiǎn)分析時(shí)，重要的是量化不確定性的程度及與每個(gè)風(fēng)險(xiǎn)相關(guān)的損失的程度。軟件風(fēng)險(xiǎn)項(xiàng)目風(fēng)險(xiǎn)

潛在的預(yù)算、進(jìn)度、人力、資源、客戶及需求等方面的問題以及它們對(duì)軟件項(xiàng)目的影響。技術(shù)風(fēng)險(xiǎn)

潛在的設(shè)計(jì)、實(shí)現(xiàn)、接口、驗(yàn)證和維護(hù)等方面的問題，威脅待開發(fā)軟件的質(zhì)量和交付時(shí)間。軟件風(fēng)險(xiǎn)商業(yè)風(fēng)險(xiǎn)（威脅待開發(fā)軟件的生存能力）：開發(fā)了一個(gè)沒有人真正需要的優(yōu)秀產(chǎn)品或系統(tǒng)（市場風(fēng)險(xiǎn)）。開發(fā)的產(chǎn)品不再符合公司的整體商業(yè)策略（策略風(fēng)險(xiǎn)）。建造了一個(gè)銷售部門不知道如何去賣的產(chǎn)品。由于重點(diǎn)的轉(zhuǎn)移或人員的變動(dòng)而失去了高級(jí)管理層的支持（管理風(fēng)險(xiǎn)）。沒有得到預(yù)算或人力上的保證（預(yù)算風(fēng)險(xiǎn)）。軟件風(fēng)險(xiǎn)可預(yù)測風(fēng)險(xiǎn)能夠從過去項(xiàng)目的經(jīng)驗(yàn)中推斷出來。不可預(yù)測風(fēng)險(xiǎn)它們可能、也會(huì)真的出現(xiàn)，但很難實(shí)現(xiàn)識(shí)別。軟件風(fēng)險(xiǎn)一般性風(fēng)險(xiǎn)對(duì)每一個(gè)軟件項(xiàng)目而言都是一個(gè)潛在的威脅。特定產(chǎn)品的風(fēng)險(xiǎn)只有那些對(duì)當(dāng)前項(xiàng)目的技術(shù)、人員及環(huán)境非常了解的人才能識(shí)別出來。識(shí)別風(fēng)險(xiǎn)試圖系統(tǒng)化地確定風(fēng)險(xiǎn)對(duì)項(xiàng)目計(jì)劃（估算、進(jìn)度、資源分配）的威脅，在可能時(shí)避免風(fēng)險(xiǎn)，在必要時(shí)控制風(fēng)險(xiǎn)。識(shí)別風(fēng)險(xiǎn)識(shí)別下列常見子類型中的已知的及可預(yù)測的風(fēng)險(xiǎn)：產(chǎn)品規(guī)模：與要建造或要修改的軟件的總體規(guī)模相關(guān)的風(fēng)險(xiǎn)。商業(yè)影響：與管理或市場所加諸的約束相關(guān)的風(fēng)險(xiǎn)。客戶特性：與客戶的素質(zhì)以及開發(fā)者和客戶定期通信的能力相關(guān)的風(fēng)險(xiǎn)。過程定義：與軟件過程被定義的程度以及它們被開發(fā)組織所遵守的程度相關(guān)的風(fēng)險(xiǎn)。開發(fā)環(huán)境：與用以建造產(chǎn)品的工具的可用性及質(zhì)量相關(guān)的風(fēng)險(xiǎn)。建造的技術(shù)：與待開發(fā)軟件的復(fù)雜性及系統(tǒng)所包含技術(shù)的“新奇性”相關(guān)的風(fēng)險(xiǎn)。人員數(shù)目及經(jīng)驗(yàn)：與參與工作的軟件工程師的總體技術(shù)水平及項(xiàng)目經(jīng)驗(yàn)相關(guān)的風(fēng)險(xiǎn)。產(chǎn)品規(guī)模風(fēng)險(xiǎn)項(xiàng)目風(fēng)險(xiǎn)直接與產(chǎn)品規(guī)模成正比。以何種方法估算產(chǎn)品的規(guī)模？對(duì)于估算出的產(chǎn)品規(guī)模的信任程度如何？是否以程序、文件或事務(wù)處理的數(shù)目來估算產(chǎn)品規(guī)模？產(chǎn)品規(guī)模與以前產(chǎn)品規(guī)模的平均值的偏差百分比是多少？產(chǎn)品創(chuàng)建或使用的數(shù)據(jù)庫大小如何？產(chǎn)品的用戶數(shù)有多少？產(chǎn)品的需求改變多少？交付之前有多少？交付之后有多少？復(fù)用的軟件有多少？在每一種情況下，待開發(fā)產(chǎn)品的信息必須與過去的經(jīng)驗(yàn)加以比較。若出現(xiàn)了較大的百分比偏差，或如果數(shù)字相近但過去的結(jié)果很不令人滿意，則風(fēng)險(xiǎn)較高。商業(yè)影響風(fēng)險(xiǎn)銷售部門是受商業(yè)驅(qū)動(dòng)的，而商業(yè)考慮有時(shí)會(huì)直接與技術(shù)現(xiàn)實(shí)發(fā)生沖突。本產(chǎn)品對(duì)公司的收入有何影響？本產(chǎn)品是否得到公司高級(jí)管理層的重視？交付期限的合理性如何？將會(huì)使用本產(chǎn)品的用戶數(shù)及本產(chǎn)品是否與用戶的需要相符合？本產(chǎn)品必須能與之互操作的其它產(chǎn)品/系統(tǒng)的數(shù)目？最終用戶的水平如何？必須產(chǎn)生并交互給用戶的產(chǎn)品的量與質(zhì)如何？政府對(duì)本產(chǎn)品開發(fā)的約束？延遲交付所造成的成本消耗是多少？產(chǎn)品缺陷所造成的成本消耗是多少？客戶相關(guān)的風(fēng)險(xiǎn)并非所有客戶都是一樣的?？蛻粲胁煌男枰蛻粲胁煌膫€(gè)性客戶與他們的供應(yīng)商之間也有各種不同的通信方式?？蛻舫３Ｊ敲艿目蛻粝嚓P(guān)的風(fēng)險(xiǎn)你以前是否曾與這個(gè)客戶合作過？該客戶是否很清楚需要什么？他能否花時(shí)間把需求寫出來？該客戶是否同意花時(shí)間召開正式的需求收集會(huì)議以確定項(xiàng)目范圍？該客戶是否愿意建立與開發(fā)者之間的快速通信渠道？該客戶是否愿意參加復(fù)審工作？該客戶是否具有該產(chǎn)品領(lǐng)域的技術(shù)素養(yǎng)？該客戶是否愿意讓你的人來做他們的工作（當(dāng)你的人在做具體的技術(shù)工作時(shí)，該客戶是否會(huì)堅(jiān)持在旁邊監(jiān)視）？該客戶是否了解軟件過程？如果對(duì)于以上任何一個(gè)問題的答案是否定的，則需要進(jìn)行進(jìn)一步的調(diào)研，以評(píng)估潛在的風(fēng)險(xiǎn)。過程風(fēng)險(xiǎn)如果軟件過程定義得不清楚；如果分析、設(shè)計(jì)、測試以無序的方式進(jìn)行；如果質(zhì)量是每個(gè)人都認(rèn)為是很重要的概念，但沒有人切實(shí)地采取行動(dòng)來保證它，那么，這個(gè)項(xiàng)目就處于風(fēng)險(xiǎn)之中。過程風(fēng)險(xiǎn)

過程問題技術(shù)問題過程風(fēng)險(xiǎn)過程問題你的高級(jí)管理層是否支持一份已經(jīng)寫好的政策綜述，該綜述中強(qiáng)調(diào)了軟件開發(fā)標(biāo)準(zhǔn)過程的重要性嗎？你的組織是否已經(jīng)建立了一份已經(jīng)成文的、用于本項(xiàng)目的軟件過程的說明？開發(fā)人員是否“簽約”同意按照文檔所寫的軟件過程進(jìn)行開發(fā)工作，并自愿使用它？該軟件過程是否可用于其他項(xiàng)目？你的組織是否已經(jīng)為管理及技術(shù)人員開設(shè)了一系列的軟件工程培訓(xùn)課程？是否為每一個(gè)軟件開發(fā)者和管理者都提供了印好的軟件工程標(biāo)準(zhǔn)？是否為作為軟件過程一部分而定義的所有交付物建立了文檔概要及示例？過程風(fēng)險(xiǎn)過程問題是否定期對(duì)需求規(guī)約、設(shè)計(jì)和編碼進(jìn)行正式的技術(shù)復(fù)審？是否定期對(duì)測試過程和測試情況進(jìn)行復(fù)審？是否對(duì)每一次正式技術(shù)復(fù)審的結(jié)果要建立文檔，其中包括發(fā)現(xiàn)的錯(cuò)誤及使用的資源？是否有什么機(jī)制來保證軟件工程標(biāo)準(zhǔn)的方案指導(dǎo)的工作開展正常？是否使用配置管理來維護(hù)系統(tǒng)/軟件需求、設(shè)計(jì)、編碼及測試用例之間的一致性？是否使用一個(gè)機(jī)制來控制用戶需求的變化及其對(duì)軟件的影響？對(duì)于每一個(gè)承包出去的子合同，是否有一份文檔化的工作說明、一份軟件需求規(guī)約及一份軟件開發(fā)計(jì)劃？是否有一個(gè)可遵循的規(guī)程來跟蹤及復(fù)審子合同承包商的工作？過程風(fēng)險(xiǎn)技術(shù)問題是否使用方便易用的規(guī)格說明技術(shù)來輔助客戶與開發(fā)者之間的通信？是否使用特定的方法進(jìn)行軟件分析？是否使用特定的方法進(jìn)行數(shù)據(jù)和體系結(jié)構(gòu)的設(shè)計(jì)？是否90%以上的代碼都是采用高級(jí)語言編寫的？是否定義及使用特定的規(guī)則進(jìn)行代碼編寫？是否使用特定的方法進(jìn)行測試用例設(shè)計(jì)？是否使用軟件工具來支持計(jì)劃和跟蹤活動(dòng)？是否使用配置管理軟件工具來控制和跟蹤軟件過程中的變化活動(dòng)？是否使用軟件工具來支持軟件分析和設(shè)計(jì)過程？過程風(fēng)險(xiǎn)技術(shù)問題是否使用工具來創(chuàng)建軟件原型？是否使用軟件工具來支持測試過程？是否使用軟件工具來支持文檔的生成和管理？是否收集所有軟件項(xiàng)目的質(zhì)量度量值？是否收集所有軟件項(xiàng)目的生產(chǎn)率度量值？如果對(duì)于上述問題中大多數(shù)的答案是否定的，則軟件過程是薄弱的，且風(fēng)險(xiǎn)很高。技術(shù)風(fēng)險(xiǎn)該技術(shù)對(duì)于你的組織而言是新的嗎？客戶的需求是否需要?jiǎng)?chuàng)建新的的算法或輸入、輸出技術(shù)？軟件是否需要使用新的或未經(jīng)證實(shí)的硬件接口？待開發(fā)軟件是否需要與開發(fā)商提供的未經(jīng)證實(shí)的軟件產(chǎn)品接口？待開發(fā)軟件是否需要與其功能及性能均未在本領(lǐng)域中得到證實(shí)的數(shù)據(jù)庫系統(tǒng)接口？產(chǎn)品的需求中是否要求采用特定的用戶界面？技術(shù)風(fēng)險(xiǎn)產(chǎn)品的需求中是否要求開發(fā)某些程序構(gòu)件，這些構(gòu)件與你的組織以前所開發(fā)的構(gòu)件完全不同？需求中是否要求使用新的分析、設(shè)計(jì)、或測試方法？需求中是否要求使用非傳統(tǒng)的軟件開發(fā)方法，如形式化方法，基于AI的方法、以及人工神經(jīng)網(wǎng)絡(luò)？需求中是否有過分的對(duì)產(chǎn)品的性能約束？客戶能確定所要求的功能是“可行的”嗎？如果對(duì)于這些問題中任何一個(gè)的答案是肯定的，則需要進(jìn)一步的調(diào)研，來評(píng)估潛在的風(fēng)險(xiǎn)。開發(fā)環(huán)境風(fēng)險(xiǎn)是否有可用的軟件項(xiàng)目管理工具？是否有可用的軟件過程管理工具？是否有可用的分析和設(shè)計(jì)工具？分析和設(shè)計(jì)工具是否支持適用于待開發(fā)產(chǎn)品的方法？是否有可用的編譯器或代碼生成器，且適用于待建造產(chǎn)品？是否有可用的測試工具，且適用于待建造產(chǎn)品？開發(fā)環(huán)境風(fēng)險(xiǎn)是否有可用的軟件配置管理工具？環(huán)境是否利用了數(shù)據(jù)庫或倉庫？是否所用軟件工具都是彼此集成的？項(xiàng)目組的成員是否已經(jīng)接受過關(guān)于每個(gè)工具的培訓(xùn)？是否相關(guān)的專家能夠回答關(guān)于工具的問題？工具的聯(lián)機(jī)幫助及文檔是否適當(dāng)？

如果對(duì)于上述問題中大多數(shù)的答案是否定的，則軟件過程是薄弱的，且風(fēng)險(xiǎn)很高。與人員數(shù)目相關(guān)的風(fēng)險(xiǎn)是否有最優(yōu)秀的人員可用？人員在技術(shù)上是否配套？是否有足夠的人員可用？開發(fā)人員是否能夠自始自終地參加整個(gè)項(xiàng)目的工作？項(xiàng)目中是否有一些人員只能部分時(shí)間工作？開發(fā)人員對(duì)自己的工作是否有正確的期望？開發(fā)人員是否接受過必要的培訓(xùn)？開發(fā)人員的流動(dòng)是否仍能保證工作的連續(xù)性？如果對(duì)于這些問題中任何一個(gè)的答案是肯定的，則需要進(jìn)一步的調(diào)研，來評(píng)估潛在的風(fēng)險(xiǎn)。風(fēng)險(xiǎn)因素性能風(fēng)險(xiǎn)產(chǎn)品能夠滿足需求且符合于其使用目的的不確定的程度。成本風(fēng)險(xiǎn)項(xiàng)目預(yù)算能夠被維持的不確定的程度。支持風(fēng)險(xiǎn)軟件易于糾錯(cuò)、適應(yīng)及增強(qiáng)的不確定的程度。進(jìn)度風(fēng)險(xiǎn)項(xiàng)目進(jìn)度能夠被維持且產(chǎn)品能按時(shí)交付的不確定的程度。風(fēng)險(xiǎn)預(yù)測風(fēng)險(xiǎn)預(yù)測試圖從兩方面評(píng)估每一個(gè)風(fēng)險(xiǎn)：風(fēng)險(xiǎn)發(fā)生的可能性或概率；如果風(fēng)險(xiǎn)發(fā)生了，所產(chǎn)生的后果。風(fēng)險(xiǎn)預(yù)測活動(dòng)：建立一個(gè)尺度，以反映風(fēng)險(xiǎn)發(fā)生的可能性；描述風(fēng)險(xiǎn)的后果；估算風(fēng)險(xiǎn)對(duì)項(xiàng)目及產(chǎn)品的影響；標(biāo)注風(fēng)險(xiǎn)預(yù)測的整體精度，以免產(chǎn)生誤解。建立風(fēng)險(xiǎn)表規(guī)模估算可能非常低PS60%嚴(yán)重的用戶數(shù)量大大超出計(jì)劃PS30%輕微的復(fù)用程度低于計(jì)劃PS70%嚴(yán)重的最終用戶抵制該系統(tǒng)BU40%輕微的交付期限將被緊縮BU50%嚴(yán)重的資金將會(huì)流失CU40%災(zāi)難的用戶將改變需求PS80%嚴(yán)重的技術(shù)達(dá)不到預(yù)期的效果TE30%災(zāi)難的缺少對(duì)工具的培訓(xùn)DE80%輕微的人員缺少經(jīng)驗(yàn)ST30%嚴(yán)重的人員流動(dòng)比較頻繁ST60%嚴(yán)重的……可忽略的

風(fēng)險(xiǎn)類別概率影響RMMM建立風(fēng)險(xiǎn)表根據(jù)概率及影響對(duì)風(fēng)險(xiǎn)進(jìn)行排序。高發(fā)生概率、高影響的風(fēng)險(xiǎn)放在表的上方，低概率、低影響風(fēng)險(xiǎn)移到表的下方。在風(fēng)險(xiǎn)表上定義一條中止線：只有那些在線上的風(fēng)險(xiǎn)才會(huì)得到進(jìn)一步的關(guān)注，而在線下的風(fēng)險(xiǎn)則需要再評(píng)估以完成第二次排序。從管理的角度考慮風(fēng)險(xiǎn)影響及概率：一個(gè)具有高影響但發(fā)生概率很低的風(fēng)險(xiǎn)因素不應(yīng)該花太多的管理時(shí)間；而高影響且發(fā)生概率為中到高的風(fēng)險(xiǎn)，以及低影響且高概率的風(fēng)險(xiǎn)，應(yīng)該首先列入管理考慮之中。所有中止線之上的風(fēng)險(xiǎn)都必須進(jìn)行管理。風(fēng)險(xiǎn)表中標(biāo)有RMMM的列指向相應(yīng)的風(fēng)險(xiǎn)緩解、監(jiān)控和管理計(jì)劃。評(píng)估風(fēng)險(xiǎn)影響確定風(fēng)險(xiǎn)整體影響的步驟：確定每個(gè)風(fēng)險(xiǎn)元素發(fā)生的概率；確定每個(gè)風(fēng)險(xiǎn)元素的影響；完成風(fēng)險(xiǎn)表，并分析其結(jié)果。風(fēng)險(xiǎn)評(píng)估

在風(fēng)險(xiǎn)評(píng)估過程中，進(jìn)一步審查在風(fēng)險(xiǎn)預(yù)測階段所做的估算的精確度，為所發(fā)現(xiàn)的風(fēng)險(xiǎn)排除優(yōu)先次序，并開始考慮如何控制和/或避免可能發(fā)生的風(fēng)險(xiǎn)。風(fēng)險(xiǎn)評(píng)估

風(fēng)險(xiǎn)評(píng)估的依據(jù)是如下形式的三元組：

[r,l,x]

其中r表示風(fēng)險(xiǎn)，l表示風(fēng)險(xiǎn)發(fā)生的概率，x表示風(fēng)險(xiǎn)產(chǎn)生的影響。風(fēng)險(xiǎn)評(píng)估進(jìn)行風(fēng)險(xiǎn)評(píng)估必須定義一個(gè)風(fēng)險(xiǎn)參考水平值：對(duì)于大多數(shù)軟件項(xiàng)目而言，主要風(fēng)險(xiǎn)因素（性能、成本、支持、進(jìn)度）也代表了風(fēng)險(xiǎn)參考水平值。即，對(duì)于性能下降、成本超支、支持困難、進(jìn)度延遲（或這四種的組合），都有一個(gè)參考水平值的要求，超過參考水平值就會(huì)導(dǎo)致項(xiàng)目被迫終止。如果風(fēng)險(xiǎn)的組合所產(chǎn)生的問題引起一個(gè)或多個(gè)參考水平值被超過，則工作將會(huì)停止。風(fēng)險(xiǎn)評(píng)估成本超支進(jìn)度延遲臨界點(diǎn)（成本，時(shí)間）終止項(xiàng)目風(fēng)險(xiǎn)評(píng)估風(fēng)險(xiǎn)評(píng)估過程：定義項(xiàng)目的風(fēng)險(xiǎn)參考水平值。建立每一組[r,l,x]與每一個(gè)參考水平值之間的關(guān)系。預(yù)測一組臨界點(diǎn)以定義項(xiàng)目終止區(qū)域。預(yù)測什么樣的風(fēng)險(xiǎn)組合會(huì)影響參考水平值。風(fēng)險(xiǎn)緩解、監(jiān)控和管理處理風(fēng)險(xiǎn)的策略：風(fēng)險(xiǎn)避免風(fēng)險(xiǎn)監(jiān)控風(fēng)險(xiǎn)管理及意外事件計(jì)劃風(fēng)險(xiǎn)緩解、監(jiān)控和管理實(shí)例（三元組）項(xiàng)目風(fēng)險(xiǎn)：頻繁的人員流動(dòng)概率：70%影響：對(duì)項(xiàng)目成本和進(jìn)度有嚴(yán)重的影響風(fēng)險(xiǎn)緩解、監(jiān)控和管理實(shí)例（風(fēng)險(xiǎn)緩解策略）與現(xiàn)有人員一起探討人員流動(dòng)的原因（如，惡劣的工作條件，低報(bào)酬，競爭激烈的勞動(dòng)力市場）。在項(xiàng)目開始之前，采取行動(dòng)以緩解那些在管理控制之下的原因。一旦項(xiàng)目啟動(dòng)，假設(shè)會(huì)發(fā)生人員流動(dòng)，采取一些技術(shù)一保證但人員離開時(shí)的連續(xù)性。對(duì)項(xiàng)目組進(jìn)行良好組織，使得每一個(gè)開發(fā)活動(dòng)的信息能被廣泛傳播和交流。定義文檔的標(biāo)準(zhǔn)，并建立相應(yīng)的機(jī)制以確保文檔能被及時(shí)建立。對(duì)所有工作進(jìn)行詳細(xì)復(fù)審，使得不止一個(gè)人熟悉該項(xiàng)工作。對(duì)每一個(gè)關(guān)鍵的技術(shù)人員都指定一個(gè)后備人員。風(fēng)險(xiǎn)緩解、監(jiān)控和管理實(shí)例（風(fēng)險(xiǎn)監(jiān)控活動(dòng)，應(yīng)該監(jiān)控下列因素）項(xiàng)目組成員對(duì)項(xiàng)目壓力的一般態(tài)度。項(xiàng)目組的凝聚力。項(xiàng)目組成員彼此之間的關(guān)系。與報(bào)酬和利益相關(guān)的潛在問題。在公司內(nèi)及公司外工作的可能性。相應(yīng)風(fēng)險(xiǎn)緩解步驟（策略）的效力。風(fēng)險(xiǎn)緩解、監(jiān)控和管理實(shí)例（風(fēng)險(xiǎn)管理及意外事件計(jì)劃，假設(shè)緩解工作失敗，風(fēng)險(xiǎn)變成了現(xiàn)實(shí)）使用后備人員。調(diào)整項(xiàng)目進(jìn)度，使得新加入人員能夠“趕上”。要求那些要離開的人員停止工作，并在最后幾個(gè)星期進(jìn)入“知識(shí)交接模式”。風(fēng)險(xiǎn)緩解、監(jiān)控和管理值得注意的是，風(fēng)險(xiǎn)緩解、監(jiān)控和管理計(jì)劃將導(dǎo)致額外的項(xiàng)目開銷（例如，花費(fèi)時(shí)間去“備份”每一個(gè)關(guān)鍵的技術(shù)人員是需要花錢的）。因此，風(fēng)險(xiǎn)管理的部分任務(wù)是評(píng)估是否以及何時(shí)風(fēng)險(xiǎn)緩解、監(jiān)控和管理計(jì)劃所產(chǎn)生的效益低于它們所花費(fèi)的成本。風(fēng)險(xiǎn)緩解、監(jiān)控和管理對(duì)于一個(gè)大型項(xiàng)目，可能標(biāo)出30或40種風(fēng)險(xiǎn)。如果為每種風(fēng)險(xiǎn)定義3至7個(gè)風(fēng)險(xiǎn)管理步驟，則風(fēng)險(xiǎn)管理本身就可能變成一個(gè)“項(xiàng)目”！Pareto的80-20規(guī)則：整個(gè)軟件項(xiàng)目風(fēng)險(xiǎn)的80%（即，可能導(dǎo)致失敗的80%的潛在因素）能夠由僅僅20%的已標(biāo)出風(fēng)險(xiǎn)來說明。RMMM計(jì)劃風(fēng)險(xiǎn)管理策略可以包含在軟件項(xiàng)目計(jì)劃中，也可以組織成一個(gè)獨(dú)立的風(fēng)險(xiǎn)緩解、監(jiān)控和管理計(jì)劃（RMMM計(jì)劃）。一旦建立了RMMM計(jì)劃，且項(xiàng)目開始啟動(dòng)，則風(fēng)險(xiǎn)緩解及監(jiān)控步驟隨即開始。風(fēng)險(xiǎn)緩解是一種問題避免活動(dòng)，風(fēng)險(xiǎn)監(jiān)控是一種項(xiàng)目跟蹤活動(dòng)。RMMM計(jì)劃風(fēng)險(xiǎn)監(jiān)控的主要目的：評(píng)估一個(gè)被預(yù)測的風(fēng)險(xiǎn)是否真正發(fā)生了；保證為風(fēng)險(xiǎn)而定義的緩解步驟被正確地實(shí)施；收集能夠用于未來風(fēng)險(xiǎn)分析的信息；在很多情況下，項(xiàng)目中發(fā)生的問題可以追溯的不止一個(gè)風(fēng)險(xiǎn)，風(fēng)險(xiǎn)監(jiān)控應(yīng)該試圖在整個(gè)項(xiàng)目中確定“起源”（什么風(fēng)險(xiǎn)引起了什么問題）。RMMM計(jì)劃1.引言（1）文檔的范圍和目的（2）主要風(fēng)險(xiǎn)綜述（3）責(zé)任管理者技術(shù)人員2.項(xiàng)目風(fēng)險(xiǎn)表（1）中止線上的所有風(fēng)險(xiǎn)的描述（2）風(fēng)險(xiǎn)元素的概率及影響RMMM計(jì)劃3.風(fēng)險(xiǎn)緩解、監(jiān)控和管理對(duì)每一個(gè)風(fēng)險(xiǎn)元素：（1）緩解一般策略緩解風(fēng)險(xiǎn)的特定步驟（2）監(jiān)控被監(jiān)控的因素監(jiān)控方法（3）管理意外事件計(jì)劃特殊的考慮4.RMMM計(jì)劃的時(shí)間安排5.總結(jié)項(xiàng)目延遲交付的原因一個(gè)不現(xiàn)實(shí)的截止期限，有軟件工程組以外的人所設(shè)立并強(qiáng)加給軟件工程組內(nèi)的管理者和項(xiàng)目開發(fā)者。對(duì)工作量和/或完成該工作所需的資源的數(shù)量估計(jì)不足。在項(xiàng)目開始時(shí)，沒有將可以預(yù)測的和/或不可預(yù)測的風(fēng)險(xiǎn)考慮在內(nèi)。事先無法預(yù)計(jì)的技術(shù)困難。事先無法預(yù)計(jì)的人力困難。由于項(xiàng)目組成員之間的交流不暢而導(dǎo)致的延期。項(xiàng)目管理者未能發(fā)現(xiàn)進(jìn)度拖后，也未能采取行動(dòng)解決這一問題。預(yù)測項(xiàng)目延遲后的處理如果最樂觀的估算都表明截止期限是不現(xiàn)實(shí)的，一個(gè)勝任的管理者就應(yīng)該保護(hù)其隊(duì)伍免受不適當(dāng)?shù)倪M(jìn)度安排的壓力并將這種壓力給施加壓力的一方。實(shí)例：一個(gè)軟件開發(fā)小組的任務(wù)是構(gòu)造一個(gè)醫(yī)療診斷儀器的實(shí)時(shí)控制器，該控制器需要在9個(gè)月之內(nèi)推向市場。在進(jìn)行了仔細(xì)的估算和風(fēng)險(xiǎn)分析之后，軟件項(xiàng)目管理者得到的結(jié)論是在現(xiàn)有人員條件下，需要14個(gè)月的時(shí)間才能完成這個(gè)項(xiàng)目。怎么辦？預(yù)測項(xiàng)目延遲后的處理推薦處理步驟：使用從以前的項(xiàng)目中得到的數(shù)據(jù)，進(jìn)行詳細(xì)的估算，確定項(xiàng)目的估算工作量和持續(xù)時(shí)間。使用增量過程模型，制定一個(gè)軟件開發(fā)策略，以能夠在規(guī)定的交付日期提供關(guān)鍵功能，而將其他功能的實(shí)現(xiàn)推到以后，并將這一計(jì)劃做成文檔。與客戶會(huì)談并（用詳細(xì)的估算結(jié)果）解釋為什么規(guī)定的交付日期是不現(xiàn)實(shí)的，一定要指出所有這些估算都是基于以往的項(xiàng)目實(shí)踐，而且一定要指出為了在目前規(guī)定的交付期限完成項(xiàng)目，與以往相比在工作效率上必須提高的百分比。將增量開發(fā)策略作為可選計(jì)劃提交給客戶。項(xiàng)目進(jìn)度安排的基本原則劃分：項(xiàng)目必須被劃分成若干可以管理的活動(dòng)和任務(wù)。為了實(shí)現(xiàn)項(xiàng)目的劃分，對(duì)產(chǎn)品和過程都需要進(jìn)行分解。相互依賴性：各個(gè)被劃分的活動(dòng)或任務(wù)之間的相互關(guān)系必須是確定的。項(xiàng)目有些任務(wù)必須順序發(fā)生；而其他的則可以并發(fā)進(jìn)行。有些活動(dòng)只有在其他活動(dòng)產(chǎn)生的工作產(chǎn)品完成時(shí)才能夠開始，而其他的則可以獨(dú)立進(jìn)行。時(shí)間分配：必須為每個(gè)被調(diào)度的任務(wù)分配一定數(shù)量的工作單位。此外，必須為每個(gè)任務(wù)指定開始和結(jié)束日期，這些日期是與工作完成的方式相互依賴的，是工作方式的函數(shù)。項(xiàng)目進(jìn)度安排的基本原則工作量確認(rèn)：每個(gè)項(xiàng)目都有預(yù)定數(shù)量的人員參與。在進(jìn)行時(shí)間分配時(shí)，項(xiàng)目管理者必須確保在任意時(shí)段中分配給任務(wù)的人員數(shù)量不會(huì)超過項(xiàng)目組人員的數(shù)量。定義責(zé)任：每個(gè)被調(diào)度的任務(wù)都應(yīng)該指定某個(gè)特定的小組成員來負(fù)責(zé)。定義結(jié)果：每個(gè)被調(diào)度的任務(wù)都應(yīng)該有一個(gè)定義好的結(jié)果。定義里程碑：每個(gè)任務(wù)或任務(wù)組都應(yīng)該與一個(gè)項(xiàng)目里程碑相關(guān)聯(lián)。當(dāng)一個(gè)或多個(gè)工作產(chǎn)品經(jīng)過質(zhì)量復(fù)審并且得到認(rèn)可時(shí)，標(biāo)志著一個(gè)里程碑的完成。項(xiàng)目工作量分布“40-20-40”規(guī)則：40%或更多的工作量分配給前端的分析和設(shè)計(jì)任務(wù)；類似比例的工作量用于后端測試。項(xiàng)目計(jì)劃的工作量很少超過2%到3%，除非提交給組織的項(xiàng)目計(jì)劃費(fèi)用極大，而且具有高風(fēng)險(xiǎn)。需求分析大約占用10%到25%的工作量，用于分析或原型開發(fā)的工作量應(yīng)該與項(xiàng)目規(guī)模和復(fù)雜度成正比的增長。通常有20%到25%的工作量用于軟件設(shè)計(jì)。編碼工作一般占用15%到20%的工作量。測試和調(diào)試工作將占用30%到40%的軟件開發(fā)工作量。項(xiàng)目跟蹤的方式定期舉行項(xiàng)目狀態(tài)會(huì)議，有項(xiàng)目組的各個(gè)成員分別報(bào)告進(jìn)度和問題。評(píng)估所有在軟件工程過程中所進(jìn)行的復(fù)審的結(jié)果。確定正式的項(xiàng)目里程碑是否在預(yù)定日期內(nèi)完成。比較各項(xiàng)任務(wù)的實(shí)際開始日期與計(jì)劃開始日期。與開發(fā)者進(jìn)行非正式會(huì)談，獲取他們對(duì)項(xiàng)目進(jìn)展及可能出現(xiàn)的問題的客觀評(píng)估?？偨Y(jié)任何工程方法（包括軟件工程）必須以有組織的質(zhì)量保證為基礎(chǔ)。全面的質(zhì)量管理和類似的理念刺激了不斷的過程改進(jìn)，正是這種改進(jìn)導(dǎo)致了更加成熟的軟件工程方法的不斷出現(xiàn)。支持軟件工程的根基就在于對(duì)質(zhì)量的關(guān)注。s#oXlUiQfNcK8H5D2A+x*u$rZnWkShPeMaJ7G4C1z-w&t!pYmVjRgOdL9I6E3B0y(v%s#oXlTiQfNbK8H5D2A-x*u$qZnWkShPdMaJ7F4C1z)w&s!pYmUjRgOcL9H6E3B+y(v%r#oXlTiQeNbK8G5D2A-x*t$qZnVkShPdMaI7F4C0z)w&s!pXmUjRfOcL9H6E2B+y(u%r#oWlThQeNbJ8G5D1A-w*t$qYnVkSgPdLaI7F3C0z)v&s!pXmUiRfOcK9H6E2B+x(u%rZoWlThQeMbJ8G4D1A-w*t!qYnVjSgPdLaI6F3C0y)v&s#pXlUiRfNcK9H5E2A+x(u$rZoWkThQeMbJ7G4D1z-w*t!qYmVjSgOdLaI6F3B0y)v%s#pXlUiQfNcK8H5E2A+x*u$rZnWkThPeMaJ7G4C1z-w&t!pYmVjRgOdL9I6F3B0y(v%s#oXlUiQfNbK8H5D2A+x*u$qZnWkShPeMaJ7F4C1z)w&t!pYmUjRgOcL9I6E3B+y(v%r#oXlTiQeNbK8G5D2A-x*t$qZnVkShPdMaJ7F4C0z)w&s!pYmUjRfOcL9H6E3B+y(u%r#oWlTiQeNbJ8G5D1A-x*t$qYnVkSgPdMaI7F3C0z)v&s!pXmUiRfOcK9H6E2B+y(u%rZoWlThQeNbJ8G4D1A-w*t$qYnVjSgPdLaI