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

提供了為開發軟件在技術上需要“如何做”。方法涵蓋了一系列的任務：需求分析、設計、編程、測試和維護。軟件工程方法依賴于一組原則，這些原則控制了每一個技術區域，且包含建模活動和其他描述技術。軟件過程過程：為實現一個給定目標而進行的一系列運作步驟。過程具有一系列的性質：時間性、并發性、嵌套性和度量性等。軟件過程：開發和維護軟件及其相關產品所設及的一系列活動。過程是活動的集合；活動是任務的集合；任務是把輸入轉換為輸出的操作。軟件過程

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

軟件過程管理軟件能力成熟度模型（CapabilityMaturityModel，CMM）軟件能力成熟度模型提美國大學CarnegieMellonUniversity軟件工程研究所出的一套系統、規范的對軟件生產過程進行管理的模型，其有效性已為大量實踐所證實，并已成為對一個軟件企業的生產能力和產品質量進行衡量的事實標準。軟件過程管理軟件能力成熟度模型（CMM）CMM被用來確定一個機構的軟件過程的成熟程度以及指明如何提高該成熟度的參考模型。CMM描述了軟件過程從無序到有序、從特殊到一般、從定性管理到定量管理、最終到達可動態優化的成熟過程，給出了該過程中五個成熟階段的基本特征和應遵循的原則、采取的行動，以幫助軟件機構改進其軟件過程。軟件過程管理CMM的主要作用

CMM可以指導軟件機構如何控制軟件產品的開發和維護過程，以及如何向成熟的軟件工程體系演化，并形成一套良性循環的管理文化。具體說來，一個企業要想改進其生產過程，應該采取如下策略和步驟：確定軟件企業當前所處的過程成熟級別；了解對改進軟件生產質量和加強生產過程控制起關鍵作用的因素；將工作重點集中在有限幾個關鍵目標上，有效達到改進機構軟件生產過程的效果，進而可持續地改進其軟件生產能力。

軟件過程管理CMM的基本前提軟件質量在很大程度上取決于產生軟件的軟件過程的質量和能力；軟件過程是一個可管理、可度量并不斷改進的過程；軟件過程的質量受到用以支撐它的技術和設施的影響；企業在軟件過程中所采用的技術層次應適應于軟件過程的成熟度。軟件過程管理CMM的基本原理CMM強調連續的軟件過程改進。該連續的改進基于多個演化步驟。CMM將這些演化步驟劃分成五個級別。這種分級結構的理論依據是軟件質量原理。每一級別都包括若干目標。當滿足某一目標后，軟件過程的相應部分便確定下來。五級成熟度定義了一個標準，用以度量機構的軟件過程成熟度和評價其軟件過程能力。

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

可重復級的主要特點在于確定了基本的軟件生產管理和控制，具體來講有：結合已有項目的經驗和新項目的特點來確定本項目的責任和承諾；軟件生產成本、時間表和實現的功能被有效跟蹤；識別實現承諾所需解決的關鍵問題；定義軟件項目過程標準，機構要確保其被遵守。

軟件過程管理CMM的可重復級（第二級）概括來說，第二級的主要特點是項目計劃和跟蹤是確定且有效的，項目的軟件過程是可控的，以及已有的成功經驗是可重復的。軟件過程管理CMM的定義級（第三級）有一個機構范圍內標準的軟件過程，軟件工程活動和管理活動被集成為一個有機的整體。標準化的目的是使高層管理者和軟件技術人員能夠有效合作。有一個組例如軟件工程組（SEPG）專門負責訂立機構的標準軟件過程，并且在機構中制定培訓計劃來確保相關人員和管理者有足夠的知識和技能完成標準過程所賦予的角色。標準的軟件過程結合具體項目的特點經過裁剪即形成項目定義軟件過程，它是一組集成的完善定義的軟件工程和管理過程。

軟件過程管理CMM的定義級（第三級）一個完善定義的軟件過程應包括就緒準則、輸入、工作過程、驗證機制、輸出和完成準則。對于已建立的產品生產線，其成本、時間表和實現功能均可跟蹤和控制，軟件產品的質量可以得到保證。軟件過程能力的實現主要基于在機構范圍內對一個定義軟件過程的活動、角色和責任的共同理解。

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

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

軟件質量保證（SQA）是一種應用于整個軟件過程的保護性活動。SQA包括：一種質量管理方法有效的軟件工程技術（方法和工具）在整個軟件過程中采用的正式技術復審一種多層次的測試策略對軟件文檔及其修改的控制保證遵從軟件開發標準的規程度量和報告機制SQA小組在一個組織中有多個機構負有保證軟件質量的責任，包括軟件工程師、項目管理者、客戶、銷售人員和SQA小組成員。SQA小組負責質量保證的計劃、監督、記錄、分析及報告工作。SQA小組充當客戶在公司內部的代表。這就是說，SQA小組的成員必須以客戶的觀點看待軟件。SQA計劃

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

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

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

在SCI變成基線以前，只需要進行非正式的變化控制。配置對象（SCI）的開發者可以進行任何被管理和技術需求證明是合適的修改（只要修改不會影響到在開發者工作范圍之外的更廣的系統需求），一旦對象已經經過正式的技術復審并已被認可，則創建了一個基線。SCM中的變化控制項目級變化控制：

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

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

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

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

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

潛在的預算、進度、人力、資源、客戶及需求等方面的問題以及它們對軟件項目的影響。技術風險

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

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

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

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

在風險評估過程中，進一步審查在風險預測階段所做的估算的精確度，為所發現的風險排除優先次序，并開始考慮如何控制和/或避免可能發生的風險。風險評估

風險評估的依據是如下形式的三元組：

[r,l,x]

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