一、軟件質(zhì)量特性

            商務(wù)印書館四角號碼新詞典（1978年版）中質(zhì)量的定義：（1）產(chǎn)品或工作好壞程度；（2）物體中所含物質(zhì)的多少。本文取第一個定義。

            SW-CMM對質(zhì)量的定義是：（1）一個系統(tǒng)、組件或過程符合特定需求的程度；（2）一個系統(tǒng)、組件或過程符合客戶或用戶的要求或期望的程度。

            1983年，ANSI/IEEE STD729給出了軟件質(zhì)量定義[92]：軟件產(chǎn)品滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性，它包括：(1) 軟件產(chǎn)品質(zhì)量滿足用戶要求的程度；(2) 軟件各種屬性的組合程度；(3) 用戶對軟件產(chǎn)品的綜合反映程度；(4) 軟件在使用過程中滿足用戶要求的程度。

            按照ISO/TC97/SC7/WG3/1985-1-30/N382，軟件質(zhì)量度量模型由三層組成。高層稱軟件質(zhì)量需求評價準則（SQRC），中層稱軟件質(zhì)量設(shè)計評價準則（SQDC），低層稱軟件質(zhì)量度量評價（SQMC）。ISO認為應(yīng)對高層和中層建立國際標準，以便在國際范圍內(nèi)推廣應(yīng)用軟件質(zhì)量管理，而低層可由各使用單位自行制定。ISO高層由8個要素組成、中層由23個評價準則組成，它們之間的關(guān)系如圖1-1所示。（圖中的◆符號代表某項下面各子項是必須的，缺一不可。例如，效率項由存儲效率和運行效率子項組成，兩者缺一不可，這是統(tǒng)一建模語言（Unified Modeling Language, UML）的組合的表示方法）。

            由于許多人紛紛提出意見，按1991年ISO發(fā)布的ISO/IEC9126質(zhì)量特性國際標準，SQRC已降為6個。在這個標準中，三層次中第一層稱為質(zhì)量特性，第二層稱為質(zhì)量子特性，第三層稱為度量。該標準定義了6個質(zhì)量特性，即為功能性(functionality)、可靠性(reliability)、可使用性(usability)、效率(efficiency)、可維護性(maintainability)、可移植性(portability) 。并推薦21個子特性，如適合性、準確性、互用性、依從性、安全性、成熟性、容錯性、可恢復(fù)性、可理解性、易學習性、操作性、時間特性、資源特性、可分析性、可變更性、穩(wěn)定性、可測試性、適應(yīng)性、可安裝性、一致性和可替換性，但不作為標準。

            Figure 1-2 Class Diagram of Software Quality

            表1-1 用戶要求與軟件質(zhì)量特性

            Table 1-1 The User Requirement and Software Quality Characteristic

            上述定義表明，軟件質(zhì)量依賴于軟件的內(nèi)部特性及其組合。為了對軟件質(zhì)量進行度量，首先必須對影響軟件質(zhì)量的要素進行度量，并建立實用的軟件質(zhì)量度量體系和模型。

            在進行軟件質(zhì)量設(shè)計時，必須考慮利弊，全面權(quán)衡，根據(jù)質(zhì)量需求，適當合理地選擇/設(shè)計質(zhì)量特性，并進行評價。

            圖1-2給出了上述軟件質(zhì)量特性構(gòu)成關(guān)系的一個扼要說明。軟件質(zhì)量是建筑在用戶要求基礎(chǔ)上的，所以必須掌握好用戶要求與開發(fā)過程中逐漸形成的質(zhì)量特性之間的關(guān)系。一般反映到需求規(guī)格上的用戶要求都屬于與功能及性能有關(guān)的運行特性，或與修改、變更、及管理有關(guān)的維護特性。表1-1表示了這些用戶要求與質(zhì)量特性的關(guān)系。經(jīng)過質(zhì)量管理的軟件開發(fā)過程也是逐步實現(xiàn)反映用戶所要求的質(zhì)量要求(quality requirement)的質(zhì)量特性的過程。圖1-3表示在如下的質(zhì)量管理體系下與軟件開發(fā)過程中實現(xiàn)質(zhì)量管理的過程[75]。

            第一步是在費用與期限的制約下將需求規(guī)格與質(zhì)量規(guī)格變換成設(shè)計書和程序的過程。在這個過程中將使用軟件開發(fā)技術(shù)和開發(fā)工具把用戶要求的質(zhì)量特性表現(xiàn)在設(shè)計書和程序里。

            第二步是對設(shè)計書和程序等各工程開發(fā)成果進行評審的過程。評審（review）采用質(zhì)量檢查會也稱質(zhì)量論證會（walkthrough）、質(zhì)量審查（inspection）等早期檢查手段，一般在各工程作業(yè)結(jié)束后立即進行。參加者是一些和項目有關(guān)的技術(shù)人員。目的在于盡可能在早期工程（上游工程）階段發(fā)現(xiàn)潛入的軟件缺陷，將有缺陷的設(shè)計書和程序變換成無缺陷軟件。在這一個過程中，如果發(fā)現(xiàn)設(shè)計書或程序中的缺陷就會導(dǎo)致再設(shè)計或再編碼的返工作業(yè)。

            第三步是對最終開發(fā)成果進行測試，將第二步的無缺陷軟件變換成既無缺陷又無差錯的軟件的過程。如果在測試中發(fā)現(xiàn)軟件差錯，和第二步一樣也會導(dǎo)致再設(shè)計和再編碼的返工作業(yè)。

            二、軟件過程分類

            過程定義：韋氏詞典將“過程”定義為“某物生產(chǎn)的操作體系……能導(dǎo)致結(jié)束或得到結(jié)果的一系列的活動、變革、或操作。”IEEE將“過程”定義為“為實現(xiàn)給定目標所執(zhí)行的一系列的步驟（IEEE-STD-610）?！?/p>

            過程模型的主要作用：過程模型不僅詳細規(guī)定了在每個階段的所有任務(wù)和活動﹑任務(wù)活動之間的層次時序關(guān)系，還制定了在軟件開發(fā)和演化中各個階段的時序和約束條件，建立了從一個階段進入下一個階段的過渡準則。同時，它還確定了軟件開發(fā)過程中所應(yīng)遵守的“策略”或限制。過程模型還有利于軟件開發(fā)中各類人員之間的有效通信和過程重用，支持過程演化，便于過程管理。

            軟件過程：軟件開發(fā)人員開發(fā)和維護軟件及相關(guān)產(chǎn)品(如項目計劃、設(shè)計文檔、代碼、測試用例和顧客手冊)的一套行為、方法、實踐和轉(zhuǎn)化過程。

            理想的過程模型的標準：(1) 能表示所有活動的組織方式；(2) 能表示各活動的工作方式；(3) 能表示各活動的先后﹑并發(fā)﹑同步﹑制約等關(guān)系；(4) 能表示過程的動態(tài)特性；(5) 能隨實際情況進行動態(tài)演化；(6) 易于被所有參與開發(fā)活動的人員理解；(7) 具有很強的靈活性，可以適應(yīng)不同的軟件項目；(8) 支持軟件開發(fā)環(huán)境的建立；(9) 易于對開發(fā)過程進行控制和管理。本文用圖2-1表示之（圖中的◇符號代表某項由下面各子項組成，但各子項不是缺一不可的，由于各種原因有可能缺若干子項，這是UML的聚集的概念）。顯然，若一個過程模型要完全符合這些標準幾乎是不可能的，應(yīng)根據(jù)實際需要選擇幾個最主要的標準即可。

            1985年正式發(fā)布了一項國際標準，即ISO/IEC 12207信息技術(shù)----軟件生存周期過程(見圖2-2)，這是軟件過程研究的一個重要成果。實踐表明，軟件過程需要不斷地完善。首先，從非工程化的軟件開發(fā)方式轉(zhuǎn)變?yōu)楣こ袒能浖_發(fā)方式，按照軟件工程的系統(tǒng)方法進行軟件的工程活動和管理活動，進而不斷地完善各個軟件過程，從而不斷提高軟件過程能力。隨著這種能力的提高，一個軟件組織完成軟件產(chǎn)品時在預(yù)算、進度，特別是產(chǎn)品質(zhì)量方面的風險就逐步降低。ISO/IEC 12207將軟件生存周期的各個過程分成三類：基本生存周期過程(見圖2-3)、支持生存周期過程(見圖2-4)和組織生存周期過程(見圖2-5)。

            例題1、填出MaCall給出的11個質(zhì)量要素特性的英文名稱，并解釋      部分。

            1.正確性（correctness）。程序滿足規(guī)格說明及完成用戶目標的程度。

            2.可靠性（reliability）。能夠防止因為概念、設(shè)計和結(jié)構(gòu)等方面的不完善造成的軟件系統(tǒng)失效，具有挽回因操作不當造成軟件系統(tǒng)失效的能力。

            3.有效性（efficiency）。軟件系統(tǒng)能最有效地利用計算機的時間資源和空間資源。

            4.完整性（integrity）?？刂莆幢皇跈?quán)人員訪問程序和數(shù)據(jù)的程度。

            5.可用性（usability）。學習使用軟件的難易程度。

            6.可維護性（maintainability）。軟件產(chǎn)品交付用戶使用后，能夠?qū)λM行修改，以便改正潛伏的錯誤，改進性能和其它的屬性，使軟件產(chǎn)品適應(yīng)環(huán)境的變化等。

            7.可測試性（testability）。測試程序使之具有預(yù)定功能所需的工作量。

            8.靈活性（flexibility）。改變一個操作程序所需的工作量。

            9.可移植性（portability）。軟件從一個計算機系統(tǒng)或環(huán)境搬到另一個計算機系統(tǒng)或環(huán)境的難易程度。

            10可重用性（reusebility）。概念或功能相對獨立的一個或一組相關(guān)模塊定義為一個軟部件，軟部件可以在多種場合應(yīng)用的程度。

            11.可互操作性（interoperability）。兩個或多個系統(tǒng)交換信息并相互使用已交換信息的能力

            例題2、PDCA循環(huán)用于軟件開發(fā)管理

            傳統(tǒng)的質(zhì)量管理思想和技術(shù)同樣可以應(yīng)用于軟件項目管理，由于現(xiàn)在中國處于工業(yè)化社會和信息化社會并存的情況，傳統(tǒng)的質(zhì)量管理思想和技術(shù)更容易為人們所接受，技術(shù)上也比較成熟，是廣大中國中小型軟件企業(yè)最實用和現(xiàn)實的選擇。

            在一定的資源、時間和費用條件下完成符合需求規(guī)格的高質(zhì)量軟件，就必須采用適當?shù)能浖芾砑夹g(shù)。管理技術(shù)包括管理實行前對開發(fā)規(guī)模、開發(fā)工時、開發(fā)費用的估算，以及以這個基本估算為依據(jù)所展開的各項管理技術(shù)。開發(fā)規(guī)模是對產(chǎn)品程序的大小的描述，用行數(shù)或語句數(shù)（step數(shù)）表示，分基本語句數(shù)（statement step數(shù)）和命令語句數(shù)（command step數(shù)）兩種表示方式。開發(fā)工時是對軟件工程技術(shù)人員工作時間的描述，用（人日）或（人月）等來表示。開發(fā)費用指開發(fā)所需要的各種費用，一般包括人工費（工時數(shù)×單價）、計算機機時費（計算機使用時間×單價）以及其它消耗。軟件開發(fā)管理也稱開發(fā)項目（project）管理。即將有關(guān)軟件開發(fā)的各項活動統(tǒng)一稱為“開發(fā)項目”，在一定的目標、計劃、進度和預(yù)算指導(dǎo)下推行開發(fā)項目內(nèi)容的實施。

            軟件開發(fā)管理的關(guān)鍵問題是如何在軟件生存周期內(nèi)對質(zhì)量、時間、費用三要素進行量化，如何通過質(zhì)量管理、工程管理和費用管理活動對這三要素進行分析和評價。

            表2-2 軟件開發(fā)管理技術(shù)及其評價內(nèi)容

            管理技術(shù) 評價內(nèi)容

            *SLM：軟件生命周期管理(software life-cycle management)

            SQAM： 軟件質(zhì)量評估和測量(software quality assessment and measurement)

            COCOMO： 構(gòu)造性成本模型(constructive cost model)

            表2-2是一個將傳統(tǒng)工業(yè)管理思想應(yīng)用于軟件開發(fā)管理的例子。為了有效地進行開發(fā)管理，一定的管理措施和標準化是很重要的。標準化（standardization）的目的是為了使軟件開發(fā)作業(yè)工廠化，從依賴開發(fā)人員個人能力的手工業(yè)式生產(chǎn)轉(zhuǎn)向軟件工程學指導(dǎo)下的工業(yè)化生產(chǎn)。軟件開發(fā)標準化分為作業(yè)本身標準化和管理活動標準化兩大類。前者指在軟件開發(fā)和維護的各個階段設(shè)定的有關(guān)作業(yè)內(nèi)容的標準（standard）；后者指在軟件開發(fā)管理中為使質(zhì)量管理、費用管理等各項管理業(yè)務(wù)都能有效的實施而設(shè)定的管理基線。

            質(zhì)量管理的目的在于保證開發(fā)成品的最終質(zhì)量滿足用戶對質(zhì)量的要求。為此，需要設(shè)定質(zhì)量目標，質(zhì)量保證基線，確立質(zhì)量管理制度和措施。特別要重視當然質(zhì)量（must-be quality），因為它是可靠性的重要保證因素。

            工程管理的主要工作包括確立日程計劃，規(guī)定各開發(fā)階段（工程）的定義和成品，設(shè)定工程管理重點——“里程碑（milestone）”，制作工程作業(yè)網(wǎng)絡(luò)圖，掌握各工程進度，及時發(fā)現(xiàn)工程延誤和提前并及時調(diào)整相關(guān)部署等等。在實際中，由于軟件產(chǎn)品是非直觀的，判斷其生產(chǎn)過程中的準確進度常常是很困難的。通常的辦法是事先將開發(fā)進度狀況繪制成圖表，在適當?shù)臅r機設(shè)定軟件工程管理點（里程碑）及相應(yīng)的評價項目。當執(zhí)行中進行到這些里程碑處時，對進度和相應(yīng)項目進行檢查和評價。

            費用管理有兩方面的工作，一是正確估計用于開發(fā)和維護的工時、人工費和計算機機時費等費用預(yù)算，一是按此預(yù)算管理生產(chǎn)過程中投入的費用。具體包括隨時掌握預(yù)算與支出的相對狀況，安排與調(diào)度人力，分析預(yù)算與實際的距離，制定標準單價，使費用內(nèi)容具體化，分析損益收支情況，設(shè)定生產(chǎn)指標和改善生產(chǎn)效益等等。圖2-6是軟件開發(fā)管理過程的活動圖。

            （1）目標(target)：以用戶要求和開發(fā)方針為依據(jù)，對質(zhì)量需求準則、質(zhì)量設(shè)計準則中的各質(zhì)量特性設(shè)定質(zhì)量目標。對各準則的重要程度可以設(shè)定“特別重要”、“重要”、“一般”3級。

            （2）計劃(plan)：設(shè)定適用于被開發(fā)軟件的評測檢查項目，與此同時還要研討實現(xiàn)質(zhì)量目標的方法和手段。

            （3）執(zhí)行(do)：在開發(fā)標準和質(zhì)量評價準則的指導(dǎo)下，制作高質(zhì)量的規(guī)格說明書。在接受質(zhì)量檢查之前要先做自我檢查。

            （4）檢查(check)：按計劃階段設(shè)定的質(zhì)量評價準則進行評價，算出得分，用質(zhì)量圖的形式表示出來。對比評價結(jié)果的質(zhì)量得分和質(zhì)量目標，看軟件是否合格。

            （5）改善(action)：對評價發(fā)現(xiàn)的問題進行改進，如果改進實現(xiàn)并達到了質(zhì)量目標，接轉(zhuǎn)入下一個工程階段。

            三、軟件過程管理國外發(fā)展情況

            ISO9000是質(zhì)量管理和質(zhì)量評價系列標準，目標在于開發(fā)過程，ISO9000只決定過程的要求是什么，而不管如何實現(xiàn)。ISO9000標準針對軟件部分的是ISO9001和ISO9000-3。其中ISO9001負責處理設(shè)計、開發(fā)、生產(chǎn)、安裝和服務(wù)產(chǎn)品，ISO9000-3負責處理設(shè)計、開發(fā)、生產(chǎn)、安裝和維護計算機軟件。

            開發(fā)詳細的質(zhì)量計劃和程序控制配置管理、產(chǎn)品檢驗和合法性檢查（測試）、不規(guī)范行為（軟件缺陷）和修正措施（修復(fù)）。準備和接受軟件開發(fā)計劃證實，包括項目定義、產(chǎn)品目錄清單、項目進度、產(chǎn)品說明書、如何組織項目的描述、風險和假設(shè)的討論，以及控制策略。使用客戶容易理解、測試時容易進行合法性檢查的用語來表達說明書。開發(fā)控制軟件設(shè)計隨產(chǎn)品的生命周期中而變化的程序，開發(fā)和編制軟件測試計劃，開發(fā)檢測軟件是否滿足客戶要求的方法，實施軟件合法性檢查和驗收測試，維護測試結(jié)果的記錄，控制調(diào)查研究和解決軟件缺陷的方式。證明產(chǎn)品在發(fā)布之前已經(jīng)就緒，開發(fā)控制產(chǎn)品發(fā)布過程的程序，明確指出和規(guī)定應(yīng)該收集何種質(zhì)量信息，使用統(tǒng)計技術(shù)分析軟件開發(fā)過程以及使用統(tǒng)計技術(shù)評估軟件產(chǎn)品。

            著名的軟件過程能力成熟度模型（Software Capability Maturity Model，SW-CMM）是SEI從1986年開始研究并完成的，它側(cè)重于對軟件開發(fā)過程和開發(fā)方法論的考察。CMM包括5級：初始級(Initial)，2級：可重復(fù)級(Repeatable)，3級：已定義級(Defined)，4級：已管理級(Managed)，5級：優(yōu)化級(Optimizing)。CMM還提供了一整套較為完善的軟件研發(fā)項目管理的方法論。在CMM模型獲得巨大成功的情況下，SEI又開發(fā)了一系列其它CMM模型，包括系統(tǒng)工程成熟度模型(Systems Engineering Capability Maturity Model 1994，SE-CMM)、軟件人員成熟度模型(People Capability Maturity Model, 1995, P-CMM)、軟件獲取成熟度模型(Software Acquisition Capability Maturity Model，1996，SA-CMM)等。美國先后在這上面投資了5億多美元，做了很多實踐工作來改進軟件研發(fā)項目管理，而且其內(nèi)容還在不斷地改進，SW-CMM 1.1版本推出后，又推出了SW-CMM 2.0草案。目前，取消了單獨的CMM，開發(fā)出集成能力成熟度模型（Capability Maturity Model Integration，CMMI），其模型包括CMMI-SW、CMMI-SE、CMMI-SE/SW、CMMI-SE/SW/IPPD]，模型有連續(xù)表示（Staged Representation）和分級表示（Continuous Representation）兩種。兩種表示方法各有不同的使用對象，熟悉SE-CMM模型者用連續(xù)表示更容易，而熟悉SW-CMM模型者用分級表示更容易。

            ISO9000產(chǎn)品質(zhì)量體系認證和CMM體系認證在軟件先進國家格外重視。印度軟件企業(yè)普遍開展ISO9000質(zhì)量體系認證，多數(shù)軟件企業(yè)發(fā)展遵循ISO9001的標準，到目前為止已有100多家取得了ISO9001的認證；而且有越來越多的印度軟件企業(yè)已經(jīng)開始認識到采用CMM評估體系的重要性，而且重點已經(jīng)開始轉(zhuǎn)移。印度的軟件企業(yè)是全球軟件業(yè)進行CMM評估實踐最早和最多的。據(jù)不完全統(tǒng)計，到2000年，全球有75家通過了CMM第4級和第5級認證，在世界9大軟件出口國中，印度的軟件出口規(guī)模和質(zhì)量均在世界前列。

            美國是世界軟件生產(chǎn)大國，不論在技術(shù)創(chuàng)新和管理手段上都代表著軟件發(fā)展的先進水平。據(jù)不完全統(tǒng)計，到2000年，全球已有近萬家軟件開發(fā)企業(yè)通過了CMM認證。其中絕大多數(shù)被認證的軟件開發(fā)企業(yè)處于CMM第2級，有75家通過了CMM的第4級和第5級。達到后兩個級別的軟件企業(yè)在不斷增加。美國企業(yè)所占比例約5%，十分重視標準化的日本企業(yè)所占比例約10%。在這些通過CMM認證的軟件企業(yè)中，不乏成功者。例如，Raytheon公司現(xiàn)在有近400名軟件開發(fā)人員，公司用近五年的時間，將其成熟度從第1級提高到第3級，已經(jīng)收到明顯的效果。為了提升到較高的級別，公司所花費的投資于五年來因成本降低所收到的效益之比為1:8，直接生產(chǎn)效率提高了大約14倍。該公司所開發(fā)的產(chǎn)品在成熟度提升前每千條指令出錯率約為0.31條，提升后僅為0.03條。

            國外主要軟件質(zhì)量/軟件過程研究組織和機構(gòu)：

            美國卡內(nèi)基?梅隆大學軟件工程研究所(Carnegie Mellon University/ Software Engineering Institution CMU/SEI) 成立于1984年，其長期目標是能夠更好、更快和更便宜地預(yù)測美國國防部軟件密集系統(tǒng)的獲取、開發(fā)和維護。SEI認為軟件學科的特點是可預(yù)測性：可預(yù)測的成本、可預(yù)測的進度、可預(yù)測的質(zhì)量和可預(yù)測的功能。SEI的義務(wù)是使軟件工程進化，使其從專門的、勞動密集的、個人英雄主義的活動中解脫出來?？傊?，SEI尋求的是依賴于軟件的系統(tǒng)能按可預(yù)測的方式獲取、開發(fā)和進化。Web站點www.sei.cmu.edu。

            軟件工程實驗室（Software engineering laboratory, SEL）在美國國家宇航局所屬的戈登空間飛行中心（National Aeronautics and Space Administration/ Goddard Space Flight Center，NASA/GSFC）支持下于1977年建立。的目的是研究開發(fā)應(yīng)用軟件有效的軟件工程技術(shù)，主要由NASA/GSFC的系統(tǒng)開發(fā)部，馬里蘭大學計算機科學系（University of Maryland）和計算機科學公司飛行動力技術(shù)組（Computer Sciences Corporation, Flight Dynamics）三部分組成，進行了長期的軟件工程實踐，包括：（1）理解GSFC環(huán)境下的軟件開發(fā)工程；（2）度量在這種過程下的方法論、工具和模型的效用（effect）; (3) 識別和應(yīng)用成功的開發(fā)實踐。Web站點sel.gfsc.nasa.gov。

            軟件技術(shù)支持中心(Software Technology Support Center, STSC)位于猶他州奧格登的Hill空軍基地。成立STSC旨在幫助空軍的組織機構(gòu)標識、評價和采用改善產(chǎn)品質(zhì)量、生產(chǎn)效率和可預(yù)測性的技術(shù)。采用術(shù)語技術(shù)(term technology)，從最廣泛的意義上包括提高人類能力的過程、方法、技術(shù)和工具，STSC關(guān)注對 DoD任務(wù)有益的領(lǐng)域已證實的技術(shù)。STSC除了提供支持和咨詢服務(wù)外，還出版CrossTalk  The Journal of Defense Software Engineering。Web站點www.stsc.hill.af.mil.org。

            軟件生產(chǎn)率集團(Software Productivity Consortium, SPC) 是一個包括產(chǎn)業(yè)界、政府部門和學術(shù)界在內(nèi)的非贏利的聯(lián)合體。因為有90多個會員公司，SPC提供了改善系統(tǒng)和軟件的質(zhì)量、可靠性和上市時間性能所需要的技術(shù)和專門知識。SPC的技術(shù)計劃適用于集成基于本質(zhì)過程的集成化系統(tǒng)和軟件開發(fā)活動。SPC提供了各種改善模型和方法的課程，包括軟件CMM和CMMI、度量和軟件工程技術(shù)、集成化系統(tǒng)和軟件過程開發(fā)。  SPC提供了評估和咨詢服務(wù)，還出版季刊時事通訊并發(fā)表其它與系統(tǒng)工程、軟件工程、系統(tǒng)和軟件集成以及過程改進有關(guān)的技術(shù)性文章。Web站點www.software.org。

            國際系統(tǒng)工程咨詢委員會(International Council on Systems Engineering, INCOSE) 是國際性的非贏利組織，目的是為多學科系統(tǒng)產(chǎn)品的開發(fā)制定、發(fā)展和完善系統(tǒng)工程方法。INCOSE成立于1990年，目前已擁有3900多名系統(tǒng)工程專業(yè)人士。INCOSE是EIA/IS 731的主要開發(fā)者，并為  CMMI項目提供系統(tǒng)工程專家。Web站點www.incose.org。

            電子工業(yè)聯(lián)盟（Electronic Industries Alliance, EIA）是電子與高技術(shù)協(xié)會和公司的聯(lián)合體，承擔著共享知識和影響的義務(wù)。EIA發(fā)表了許多標準和技術(shù)出版物來為公眾利益服務(wù)，減少制造商和采購商之間的誤會，促進產(chǎn)品的可交換性和改善，以及輔助采購商根據(jù)特定的需要快速選購并獲得合適的產(chǎn)品。EIA過渡標準，系統(tǒng)工程能力和EIA/IS 731就是CMMI的三個源模型之一。Web站點www.eia.org。

            例3．IBM OS/360總設(shè)計師布魯克斯(Brooks)博士將軟件中的難題分為本質(zhì)問題兩類和非本質(zhì)問題，他還進一步指出了哪四個本質(zhì)問題？并請簡單說明之。

            答：IBM OS/360總設(shè)計師布魯克斯(Brooks)博士將軟件中的難題分為兩類：本質(zhì)問題（essence，即由軟件本質(zhì)決定的固有的難題）和非本質(zhì)問題（accidents，即目前遇到的，但并非軟件產(chǎn)品固有的困難）。他指出了四個本質(zhì)問題：即復(fù)雜性（complexity）、一致性(conformity)、可變性(changeability)和不可見性(invisibility)。他在文章中使用的“復(fù)雜性”的含義是“令人費解的、復(fù)雜難懂的”（complicated or intricate）。

            復(fù)雜性：復(fù)雜性是軟件的固有的屬性。他認為如果將一套軟件簡化，則整個過程將是毫無用處的。數(shù)學和物理的簡化技術(shù)之所以有用，只是因為那些系統(tǒng)的復(fù)雜性是非本質(zhì)問題，而不是像在軟件產(chǎn)品中那樣，復(fù)雜性是本質(zhì)問題。這種本質(zhì)上的復(fù)雜性不僅影響軟件產(chǎn)品本身，而且也會影響軟件過程的管理。

            一致性：他提出第一類一致性是軟件必須和現(xiàn)有系統(tǒng)接口，從而使軟件的復(fù)雜性達到了不必要的程度；第二類一致性是人們錯誤地認為軟件是最容易調(diào)整的部分，使得軟件的復(fù)雜性達到了不必要的程度。

            可變性：系統(tǒng)的功能體現(xiàn)在它的軟件中，通過修改軟件，就可以收到改變系統(tǒng)功能的效果。他認為可變性是軟件的本質(zhì)屬性，是一個不可克服的固有的復(fù)雜性問題。

            不可見性：軟件無法形象化表示的結(jié)果，不僅使軟件難以理解，而且嚴重妨礙了軟件專業(yè)人員之間的聯(lián)系。

            例4．SW-CMM的提出者Watts S. Humphrey指出了哪六個軟件過程改進基本原理？并請簡單說明之。

            領(lǐng)導(dǎo)原理（HP1）：軟件過程的主要改變始于高層領(lǐng)導(dǎo)。高層領(lǐng)導(dǎo)需要發(fā)起改變并提供持續(xù)的資源及優(yōu)先級。

            團隊原理（HP2）：最終將涉及到每個人。軟件工程是團隊的努力，改進中任何人的缺席將失去好處，也可能阻礙進步。

            計劃原理（HP3）：有效地改變需要有當前過程的目標和知識。使用地圖時你必須知道當前你在哪兒。

            成熟度原理（HP4）：變化是持續(xù)的。軟件過程改進不是暫時的，涉及到持續(xù)地學習和不斷地強化。

            效果原理（HP5）：沒有明確地努力和定期地強化就不能保持軟件過程改變的效果。

            投資原理（HP6）：軟件過程改變需要投資。需要計劃，配備專職人員以及管理時間和資金投入。

            例5，填空題

            SW-CMM的五個成熟度等級是初始級(Initial Level)、可重復(fù)級(Repeatable Level)、已定義級(Defined Level)、已管理級(Managed Level)、優(yōu)化級(Optimizing Level)。

            SW-CMM的五個公共特征: (1)執(zhí)行約定(Commitment to Perform)、(2)執(zhí)行能力(Ability to Perform)、(3)執(zhí)行的活動(Activities Performed)、(4)測量活動(Measurement and Analysis)、(5)驗證實施(Verifying Implementation)。

            SW-CMM的可重復(fù)級的六個關(guān)鍵過程域是：需求管理(Requirements Management)、軟件項目策劃(Software Project Planning)、軟件項目跟蹤與監(jiān)控 (Software Project Tracking and Oversight) 、軟件子合同管理 (Software Subcontract Management) 、軟件質(zhì)量保證(Software Quality Assurance) 、軟件配置管理(Software Configuration Management)。

            四、統(tǒng)一軟件過程及其支持工具

            統(tǒng)一建模語言（Unified Modeling Language, UML）于1996年由Rational公司正式創(chuàng)立(該公司已經(jīng)被IBM 公司收購)。對象管理組織(OMG)于1997年11月采納了它。此后，UML繼續(xù)改進，目前最新的版本是UML2.0。UML的發(fā)明人G.Booch, J.Rumbaugh和I.Jacobson共同認為，提出一種統(tǒng)一的建模語言有以下3個理由：（1）他們各自提出的方法在演化中已經(jīng)有相互結(jié)合的趨勢；（2）走向統(tǒng)一將帶來市場方面的好處；（3）有助于改進他們各自的學習方法，以獲得更多的學習者并解決一些以往他們各自的方法不能很好解決的問題。該建模語言的作者們給出了一種推薦性的建模過程指導(dǎo)，即統(tǒng)一過程（Rational Unified Process，RUP）體現(xiàn)了適合于范圍廣泛的項目和組織的許多現(xiàn)代軟件開發(fā)最佳實踐。RUP是以用例為驅(qū)動、體系結(jié)構(gòu)為中心、迭代和增量的過程。RUP包括四個階段，每個階段又分為若干次迭代，每次迭代都有一個核心工作流。

            UML的定義有兩個主要組成部分:語義和表示法。UML的語義用自然語言描述,表示法定義了UML的可視化標準表示符號，這決定了UML是一種可視化的建模語言。這些圖形符號和文字用于建立應(yīng)用級的模型，在語義上，模型是元模型的實例。此外UML的定義還給出了語法結(jié)構(gòu)的精確規(guī)約。

            UML是一種可視化的建模語言,對其各建模元素可進行詳細說明，并能生成所建模型的文檔。使用UML時，要從不同的角度觀察系統(tǒng)，為此定義了一個概念"視圖"。視圖是對系統(tǒng)的模型在某方面的投影，注重于系統(tǒng)的某個方面。每個視圖是圖的協(xié)作，UML定義了9種圖。用況視圖由用況圖組成，描述可被最終用戶、分析人員和測試者看到的系統(tǒng)行為；設(shè)計視圖包含類圖、對象圖、交互圖、狀態(tài)圖和活動圖，主要反映系統(tǒng)的功能需求；進程視圖包含類圖、對象圖、交互圖、狀態(tài)圖和活動圖，主要描述形成系統(tǒng)并發(fā)與同步機制的線程和進程；實現(xiàn)視圖包含構(gòu)件圖、交互圖、狀態(tài)圖和活動圖，反映用于裝配與發(fā)布物理系統(tǒng)的構(gòu)件和文件，主要針對系統(tǒng)發(fā)布的配置管理,可以用各種方法裝配它們。部署視圖包含部署圖、交互圖、狀態(tài)圖和活動圖,主要描述對組成物理系統(tǒng)的部件的分布、交付和安裝。根據(jù)實際需要，可以組合使用這些視圖。

            由視圖可以定義模型，模型在語義上是閉合的,它從特定的角度(系統(tǒng)的規(guī)約或者設(shè)計)在一定抽象層次上描述目標系統(tǒng)?？梢园岩晥D組織成模型,開發(fā)人員可從各視角觀察使用模型。

            用以描述系統(tǒng)的模型可以是結(jié)構(gòu)性的，強調(diào)系統(tǒng)的組織，也可以是行為性的,強調(diào)系統(tǒng)的動態(tài)方面。例如，RUP有9種模型,分別是業(yè)務(wù)模型、領(lǐng)域模型、用況模型(也稱需求模型)、分析模型、設(shè)計模型、過程模型、部署模型、實現(xiàn)模型和測試模型，用于從不同的角度表示系統(tǒng)。

            系統(tǒng)是一組反映不同側(cè)面的子系統(tǒng)的集合，為了完成特定的目的要對這些子系統(tǒng)進行組織(在邏輯、功能和物理位置上是高內(nèi)聚、低耦合的)。

            子系統(tǒng)是一組元素的聚集，其中的元素還可以是子系統(tǒng)。它由一組模型從不同的角度進行描述。子系統(tǒng)本身幾乎應(yīng)是獨立的，有自己應(yīng)用的環(huán)境，相互間不重疊，它們之間用接口聯(lián)系。

            UML是一種建模語言，不是一種方法，它獨立于過程。利于它建模時，可遵循任何類型的建模過程。該建模語言的作者們給出了一種推薦性的建模過程指導(dǎo)，即RUP。下面說明RUP如何支持UML的應(yīng)用。

            RUP是以用況為驅(qū)動、體系結(jié)構(gòu)為中心、迭代和增量的過程。RUP包括四個階段,每個階段又分為若干次迭代,每次迭代都有一個核心工作流(包括5個活動)。

            用況驅(qū)動旨在為到最終產(chǎn)品為止的每個階段都可以回溯到用戶的真正需求。以體系結(jié)構(gòu)為中心是指關(guān)注體系結(jié)構(gòu)模式的開發(fā)，以引導(dǎo)后續(xù)系統(tǒng),保證系統(tǒng)的平滑演進。每一次迭代包括迭代計劃、迭代評價和一些具體活動。下面對RUP的四個階段要做的工作做一闡述。

            1. 初始階段

            本階段確定所設(shè)立的項目是否可行,具體要做如下工作:

            （1）對需求有一個大概的了解，確定系統(tǒng)中的大多數(shù)角色和用況，但此時的用況是簡要的。對給出的系統(tǒng)體系結(jié)構(gòu)的概貌,細化到主要子系統(tǒng)即可。

            （2）識別影響項目可行性的風險。

            （3）考慮時間、經(jīng)費、技術(shù)、項目規(guī)模和效益等因素。

            （4）關(guān)注業(yè)務(wù)情況,制訂出開發(fā)計劃。

            2. 細化階段

            （1）識別出剩余的大多數(shù)用況。對當前迭代的每個用況進行細化，分析用況的處理流程、狀態(tài)細節(jié)以及可能發(fā)生的狀態(tài)改變。細化流程時，可以使用程序框圖和合作圖，還可以使用活動圖、類圖分析用況。

            （2）對風險的處理。

            （a）需求風險：考慮項目的目標是否偏離了用戶的需求。為解決需求風險要充分了解用戶需求以及各需求的優(yōu)先度，還應(yīng)盡量列出所有的用況，至少列出重要的用況，并要建立領(lǐng)域的概念模型。

            （b）技術(shù)風險：考察所選的技術(shù)方案是否可行。建立原型是解決技術(shù)風險的一種有效方法。

            （c）技能風險：考慮實施項目的人員素質(zhì)能否勝任項目的要求。

            （d）政策風險：考慮政策性的因素對項目的影響。

            （3）進行高層分析和設(shè)計，并作出結(jié)構(gòu)性決策。

            所產(chǎn)生的基線體系結(jié)構(gòu)包括用況列表、領(lǐng)域概念模型和技術(shù)平臺等。以后的階段對細化階段建立的體系結(jié)構(gòu)不能進行過大的變動。

            （4）為構(gòu)造階段制訂計劃。

            細化階段完成，意味著已經(jīng)完成了如下的任務(wù)：用況完全細化并被用戶接受；完成概念驗證；完成類圖；開發(fā)人員能給出項目估算(可分為精確、人月和無法估算)；基于用況考慮了所有風險(可分為高風險、可能的風險和不可能的風險)，并制訂了相應(yīng)的對策和計劃；對用況標出優(yōu)先級(可分為必須先實現(xiàn)、短期內(nèi)實現(xiàn)和長期實現(xiàn))。

            3. 構(gòu)造階段

            識別出剩余的用況。每一次迭代開發(fā)都針對用況進行分析、設(shè)計、編碼(如類聲明、屬性聲明、范圍聲明、函數(shù)原型聲明和繼承的聲明等)、測試和集成過程，所得到產(chǎn)品滿足項目需求的一個子集。由于細化階段的軟件設(shè)計已經(jīng)完成，這樣各項目組可以并發(fā)開發(fā)。

            在代碼完成后，要保證其符合標準和設(shè)計規(guī)則，并要進行質(zhì)量檢查。對于新出現(xiàn)的變化，要通過逆向工具把代碼轉(zhuǎn)換為模型，對模型進行修改，再重新產(chǎn)生代碼，以保證軟件與模型同步。

            此階段要建立類圖、交互圖和配置圖；如一個類具有復(fù)雜的生命周期，可繪制狀態(tài)圖；如算法特別復(fù)雜，可繪制活動圖。

            4. 移交階段

            這一階段完成最后的軟件產(chǎn)品和最后的驗收測試，并完成用戶文檔編制以及用戶培訓(xùn)等工作。

            總之：可以說，UML對系統(tǒng)模型的表達能力超出了以往任何一種面向?qū)ο蟮姆治龊驮O(shè)計方法。隨之出現(xiàn)的問題是，它的復(fù)雜性也超出了以往任何一種方法。由于UML的復(fù)雜性,對它的掌握和使用確實不是一件輕松的事。

            例6，填空題

            UML規(guī)定了語言的四種公共機制：（1）說明(Specification);（2）裝飾(Adornment);（3）通用劃分(Common Division);（4）擴展機制(Extensibility)。

            UML語言的體系結(jié)構(gòu)建立在4層元模型結(jié)構(gòu)之上，這4層模型分別為：（1）元—元模型 (meta-metamodel); （2）元模型(metamodel);（3）模型(model);（4）用戶對象(user object)。

            UML語言從4個抽象層次對UML語言的：（1）概念 (conception)、（2）模型元素(model element)、（3）結(jié)構(gòu)(structure)、（4）機制(mechanism)等進行了全面的定義，并規(guī)定了相應(yīng)的（5）表示法(notation)和（6）圖形符號(graphic marker)。

            瑞理軟件工具對CMM實施的支持。一般來說,實施CMM需要以下主要工具:軟件開發(fā)過程框架、需求管理工具、面向?qū)ο蟮姆治鲈O(shè)計工具、配置管理工具、變更管理工具和軟件測試工具。

            1. 軟件開發(fā)過程框架

            CMM是一種軟件過程控制和評估框架，它列出了每個級別需要完成的目標以及判定條件，但并沒有敘述如何實現(xiàn)這些目標。軟件開發(fā)過程框架工具的目標就是為開發(fā)團隊建立一個清晰的、可重復(fù)執(zhí)行的流程，以幫助團隊成員按時完成項目各階段的工作。

            Rational公司的RUP(Rational Unified Process)就是這樣一個完整的軟件開發(fā)過程框架,它包括3000個HTML文檔、近一百萬字的流程指南,其中文版本RUP-C已經(jīng)在中國市場正式發(fā)布。

            RUP對CMM實施的主要幫助體現(xiàn)在以下方面：（1）凝結(jié)了全球軟件行業(yè)的最佳開發(fā)經(jīng)驗，以指南、模板和示例的形式為開發(fā)團隊提供流程指導(dǎo)；（2）建立統(tǒng)一的軟件開發(fā)標準,改善團隊成員之間的溝通；（3）降低軟件開發(fā)風險,增加軟件開發(fā)的可預(yù)測性；（4） 賦予項目經(jīng)理對進度和交付期限的控制能力。

            2. 需求管理

            需求是軟件客戶的要求,它決定了軟件系統(tǒng)的工作內(nèi)容,是整個開發(fā)活動的基本出發(fā)點和最終目標。在整個項目生命周期內(nèi),要想有效地協(xié)作,就需要對重要的需求信息提供訪問權(quán)限,使跨功能團隊的所有成員都能掌握必要的詳細信息。需求管理的目的是在客戶和相應(yīng)的軟件項目之間建立共同的理解,并最終形成估計、策劃和跟蹤整個軟件生命周期內(nèi)軟件項目活動的基礎(chǔ)。

            需求管理是CMM2級(可重復(fù)級)的關(guān)鍵過程領(lǐng)域之一，其主要工作包括兩點：其一,通過與利益相關(guān)者(Stakeholder)的交流來獲取需求，并進行有效的組織和記錄；其二，使客戶和項目團隊在系統(tǒng)變更需求上達成一致。

            一個優(yōu)秀的需求管理工具可以在保證有效管理需求的前提下提高需求管理工作流程的自動化程度，使需求管理可以真正在項目實施中得到有效的推行。Rational公司為需求管理提供了AnalystStudio需求工作包，它具有以下主要特點：（1）結(jié)合業(yè)界認可的RUP方法,提供完整的需求分析及管理流程；（2）以Web方式獲取反饋,加強團隊之間的有效溝通；（3）用追蹤圖直觀展現(xiàn)需求變化帶來的影響。

            AnalystStudio除了可用于CMM2級的：“需求管理”外,還可以對以下KPA提供幫助：“軟件項目規(guī)劃”、“軟件項目跟蹤與監(jiān)督”、“軟件子合同管理”、“軟件產(chǎn)品工程”、“組間協(xié)作”、“同級復(fù)審”和“定量過程管理”。

            3. 面向?qū)ο蟮姆治鲈O(shè)計工具

            在CMM3級的“軟件產(chǎn)品工程”(Software Product Engineering)KPA中，對軟件設(shè)計提出了明確的要求，要求軟件設(shè)計遵循一定的設(shè)計語言、采用面向?qū)ο蟮姆椒?、使設(shè)計結(jié)果可復(fù)用等。

            為什么要采用面向?qū)ο蟮姆治鲈O(shè)計方法?主要原因有3點：（1）通過分析和設(shè)計，使開發(fā)者可以先關(guān)注問題的領(lǐng)域，再關(guān)心具體的設(shè)計和編程問題，從而有利于降低整個過程的復(fù)雜性，提高分析模型和設(shè)計模型的質(zhì)量；（2）生成的分析模型和設(shè)計模型形成文檔的主體，從根本上解決“先寫代碼、再補文檔”的老問題，并能幫助團隊規(guī)避因人員流動帶來的不良影響；（3）分析模型和設(shè)計模型將成為團隊內(nèi)部以及團隊之間有效溝通的橋梁,消除誤解,進一步解決"系統(tǒng)集成難"的頑癥,同時也可以促進團隊之間的軟件復(fù)用。

            Rational Rose是Rational公司開發(fā)的可視化建模工具,它采用UML的表示方法，在同一個模型中實現(xiàn)業(yè)務(wù)建模、對象建模和數(shù)據(jù)建模，使所有參與項目的成員都可以在統(tǒng)一的語言環(huán)境中工作于同一個模型之上，有利于改善成員之間的溝通；其次，它支持多種語言的代碼生成及雙向工程，可實現(xiàn)代碼和模型的互相轉(zhuǎn)換，并且可以將遺留代碼引入模型中；第三，它帶有對設(shè)計元素進行測試的模塊工具(Quality Architect)，可以盡早發(fā)現(xiàn)設(shè)計中的問題，真正實現(xiàn)“質(zhì)量從頭抓起”。

            Rational Rose除了可幫助實施CMM3級的“軟件產(chǎn)品工程”外,還可以對“組間協(xié)作”和“同級復(fù)審”KPA提供幫助。

            4. 配置管理和變更管理

            軟件配置管理(SCM)是CMM2級中一個非常重要的KPA，它的目的是在軟件項目的生命周期內(nèi)建立并維護軟件項目產(chǎn)品的完整性。在CMM標準中，明確規(guī)定了軟件配置管理(SCM)以及變更請求管理(CRM)的相關(guān)工作，它包括以下兩方面：（1）配置管理的主要工作包括通過創(chuàng)建軟件配置管理庫、定義配置項(包括需求、分析設(shè)計模型、代碼、文檔、測試用例、測試數(shù)據(jù)等)以及建立和維護軟件的基線；（2）變更請求管理的主要工作包括控制和記錄配置項內(nèi)容的變更，建立和維護一個系統(tǒng)并使其追蹤和管理變更請求及問題報告。

            Rational的ClearCase和ClearQuest是相當成熟的配置管理和變更管理工具，它們已經(jīng)連續(xù)四年被IDC評為業(yè)界最佳的配置管理工具。ClearCase的主要作用體現(xiàn)在三個方面：其一，幫助項目組利用版本對象庫(VOB)完整地保存整個項目的開發(fā)歷史，實現(xiàn)對軟件資產(chǎn)的有效管理；其二,利用版本對象庫(VOB)的安全機制，靈活地控制不同人員對不同配置項的檢出和讀取的權(quán)利，有效地保護企業(yè)的核心機密；第三，幫助團隊實現(xiàn)并行開發(fā)，避免合并版本等工作阻礙其他開發(fā)工作，保證項目進度。

            ClearQuest的主要作用是加強開發(fā)團隊與外界的溝通，用戶、測試人員與市場銷售人員可以直接通過Web提交變更請求,包括缺陷或功能擴充請求。

            可以毫不夸張地說，配置管理和變更管理是軟件工程的基礎(chǔ)。ClearCase和ClearQuest除了對CMM2級的“軟件配置管理”KPA有幫助外，還可以對以下KPA提供幫助：“需求管理”、“軟件項目跟蹤與監(jiān)督”、“軟件質(zhì)量保證”、“軟件產(chǎn)品工程”以及“定量過程管理”。

            5. 測試工具

            “軟件質(zhì)量保證”是CMM2級中另一個重要的KPA，軟件測試水平的高低直接影響軟件產(chǎn)品質(zhì)量的好壞與開發(fā)周期的長短。綜觀現(xiàn)階段諸多軟件開發(fā)組織在軟件測試方面的狀況，不難發(fā)現(xiàn)，多數(shù)組織存在以下問題：（1）沒有進行單元測試，或單元測試不徹底；（2）由于需求不準確，導(dǎo)致測試缺乏計劃；（3）測試工作大多依賴手工進行，沒有有效的自動化測試工具，致使軟件測試效率低下,測試周期較長，不能在軟件開發(fā)的各個周期進行完整的測試；（4）缺乏有效的跟蹤機制跟蹤解決軟件測試中發(fā)現(xiàn)的缺陷,致使有的問題得不到及時、恰當?shù)慕鉀Q。

            針對這些問題,Rational提供了一系列測試工具，幫助用戶解決上述問題。這些工具包括用于單元測試的RQA(Rose Quality Architect)、Purify、Pure Coverage和Quantify 以及用于測試管理、回歸測試和性能管理的Rational TeamTest。

            特別需要說明的是回歸測試。目前，對大型軟件系統(tǒng)來說，迭代式開發(fā)已經(jīng)成為一種主流的開發(fā)模式，需要在開發(fā)的每個迭代周期內(nèi)對軟件功能進行確認,這就是回歸測試。如果依靠人工測試的辦法，這將是一個煩瑣、耗時的過程。Rational TeamTest采用面向?qū)ο蟮挠涗浖夹g(shù)，將對系統(tǒng)的功能測試動作記錄在測試腳本中，當系統(tǒng)進入下一個迭代周期時，只需回放這個測試腳本，就可以自動地進行軟件功能的確認，這種方法可以極大地提高軟件測試的效率，保證軟件功能測試的完整性。

            以上工具可以單獨使用，解決個別問題，但是對于一個想在CMM實施中獲得較高級別評估的軟件組織來說，則需要盡可能廣泛地進行有效的規(guī)劃與部署,將這些工具有機地結(jié)合起來,滿足企業(yè)在軟件質(zhì)量方面的較高要求。為此，Rational提供了一個完整的解決方案—TestStudio，它包括用于單元測試的PQC(Purify、Quantify、Pure Coverage)、提供全面功能測試和性能測試的TeamTest、進行差錯跟蹤的ClearQuest，以及一些對軟件開發(fā)管理提供支持的基礎(chǔ)工具,并將這些工具緊密地結(jié)合在一起。

            例7，填空題

            RUP是一種大多數(shù)軟件項目軟件開發(fā)組織都能適用的形式，它吸取了軟件開發(fā)中的最佳實踐（Best Practice），具有下面五個特性：（1）用例驅(qū)動（Use case driven）；（2）以架構(gòu)為中心（Architecture centric）；（3）迭代式軟件開發(fā)（Iterative）；（4）增量式軟件開發(fā)（Incremental）；（5）可控式軟件開發(fā)（Controlled）。

            從技術(shù)角度來講RUP規(guī)定了6個過程成分：（1）業(yè)務(wù)建模（business modeling）；（2）需求分析（requirement  analyse）；（3）系統(tǒng)分析與設(shè)計（system analysis and design）；（4）實現(xiàn)（implementation）；（5）測試（testing）；（6）系統(tǒng)配置（system configuration）。

            RUP把軟件項目開發(fā)過程劃為4個階段；（1）開端階段（inception）；（2）精化階段（elaboration）；（3）構(gòu)建階段（construction）；（4）過渡階段（transition）。

            五、IDEAL模型

            1、IDEAL模型概念

            軟件過程能力成熟度模型（Software Capability Maturity Model，SW-CMM）是美國卡內(nèi)基?梅隆大學軟件工程研究所SEI(Software Engineering Institution)從1986年開始研究并完成的，它側(cè)重于對軟件開發(fā)過程和開發(fā)方法論的考察。CMM包括5級：初始級(Initial)，2級：可重復(fù)級(Repeatable)，3級：已定義級(Defined)，4級：已管理級(Managed)，5級：優(yōu)化級(Optimizing)。CMM則提供了一整套較為完善的軟件研發(fā)項目管理的方法。美國先后在這上面投資了5億多美元，做了很多實踐工作來改進軟件研發(fā)項目管理，而且其內(nèi)容還在不斷地改進，SW-CMM 1.1版本推出后，又推出了SW-CMM 2.0草案。目前，已取消了單獨的CMM，正在開發(fā)CMMI，其模型包括CMMI-SW、CMMI-SE、CMMI-SE/SW、CMMI-SE/SW/IPPD。

            SEI又與HP公司合作，提出了實施SW-CMM的IDEAL模型。IDEAL模型是一個單位用于啟動、規(guī)劃和實現(xiàn)過程改善措施藍圖的模型，概括了建立一個成功的過程改善項目的必要步驟，其中I代表Initiating(啟動)、D代表Diagnosing(診斷)、E代表Establishing(建造)、A代表Acting(實施)、L代表Learning(學習)。圖5-1是詳細的IDEAL五階段模型。其中：啟動—獲得改進的支持和責任；診斷—確定改進范圍；建立—選擇和計劃特定的改進活動；實施—設(shè)計、指導(dǎo)、實現(xiàn)以及改進制度化；學習—確定基于IDEAL模型的改進活動。

            圖5-2說明了IDEAL模型的兩維結(jié)構(gòu)，它處理過程改進中的兩種不同操作級別：

            戰(zhàn)略級：這些過程主要是高層領(lǐng)導(dǎo)的責任。

            戰(zhàn)術(shù)級：這些過程主要由產(chǎn)品線經(jīng)理和參與者執(zhí)行。

            圖5-3說明支持軟件過程改進（Software Process Improvement, SPI）的因素。其中基礎(chǔ)設(shè)施能夠在需要時提供資源；對工作的方向、范圍和進度提供建議;為SPI程序順利前進排除障礙。其目的是維持SPI程序的可視性；方便和鼓勵信息共享；抓住和保存經(jīng)驗教訓(xùn)并發(fā)展改進；提供支持網(wǎng)絡(luò)。

            2、IDEAL模型各個階段

            2.1啟動階段

            啟動階段要學習過程改進，約定啟動資源并建立過程基礎(chǔ)設(shè)施。最主要的是建立管理操作組（Management  steering  group, MSG）,軟件工程過程組（Software Engineering  Process  Group, SEPG）。常常形成一個問題發(fā)現(xiàn)小組(Discovery Team)研究有關(guān)議題（Issues），并開發(fā)軟件過程(Software Process Improvement, SPI)改進建議給高層管理者。

            啟動階段任務(wù)如下：1）開始；2）識別改進的商業(yè)需要和推動者；3）建立SPI提議；4）教育和建立支持；5）獲得SPI提議的批準和啟動資源；6）建立軟件過程改進基礎(chǔ)設(shè)施；7）評估SPI的情況（Climate）；8）確定SPI總的目標；9) 確定SPI程序的指導(dǎo)原則；10)正式啟動。

            2.2 診斷階段

            診斷階段建立當前過程的成熟度，過程說明，度量等等，并啟動行動計劃的開發(fā)。

            診斷階段任務(wù)如下：1）確定需要的基準（Baselines）；2）基準計劃；3）指導(dǎo)（Conduct）基準；4）結(jié)果(Findings)展示；5）開發(fā)最終結(jié)果和建議報告；6）與組織就最終結(jié)果和建議報告進行溝通。

            2.3 建立階段

            建立階段建立目標和優(yōu)先權(quán)，完成行動計劃的開發(fā)。

            建立階段任務(wù)如下：1）選擇和得到戰(zhàn)略規(guī)劃過程的培訓(xùn)；2）評審組織愿景(Vision)；3）評審組織的商業(yè)計劃；4）確定關(guān)鍵商業(yè)議題；5）評審過去的改進工作；6）說明改進的動機；7）確定當前和將來的改進工作；8）確定不同基礎(chǔ)設(shè)施實體的角色和責任；9）確定改進活動和開發(fā)議題的優(yōu)先級；10)協(xié)調(diào)在基準結(jié)論和建議內(nèi)已有和計劃的改進工作；11)將一般的SPI目標變成特定的可度量的目標；12）建立和更新SPI戰(zhàn)略計劃；13）建立審計、評審，并批準SPI戰(zhàn)略計劃，約定行動的資源。14）形成技術(shù)工作組（Technical  Working  Group, TWG）。

            2.4 行動階段

            行動階段研究和開發(fā)過程問題的解決方案，并擴展成功的過程改進到整個組織。

            行動階段任務(wù)如下：1）完成TWG的具體計劃；2）開發(fā)解決方案；3）試驗有潛力的解決方案；4）選擇解決方案提供商；5）確定長期的支持需要；6）開發(fā)首次（Rollout）實行的戰(zhàn)略和計劃的模板；7）整理改進（模板）并交給SEPG；8）解散TWG；9) 首次實行解決方案；10)轉(zhuǎn)移到長期支持。

            2.5 學習階段

            學習階段準備再次通過IDEAL模型，應(yīng)用學到的經(jīng)驗教訓(xùn)完善SPI過程。

            學習階段任務(wù)如下：1）收集學到的經(jīng)驗教訓(xùn)；2）分析學到的經(jīng)驗教訓(xùn)；3）修改組織方法；4）評審保證人和約定；5）建立高級的目標；6）開發(fā)新的/修改的SPI提議；7）繼續(xù)進行SPI。

            2.6 管理軟件過程改進

            對改進過程提供監(jiān)督并解決相應(yīng)的問題。

            管理軟件過程改進任務(wù)如下：1）設(shè)置軟件過程改進的階段(SPI)；2）組織SPI程序；3）計劃SPI程序；4）SPI程序人員組織；5）監(jiān)督SPI程序；6）指導(dǎo)SPI程序。

            在大多數(shù)情況下由三個部分組成了SPI的組織基礎(chǔ)設(shè)施（見圖5-4）：

            1.軟件工程過程組（SEPG）；2.管理指導(dǎo)組（MSG）；3.技術(shù)工作組（TWG）。

            第一位并且最重要的是SEPG，有時叫作過程組。SEPG在SPI程序中為組織執(zhí)行許多功能。SEPG可以：有利于在環(huán)境變化時對SPI程序提供持續(xù)的支持；建立和加強與保證人的關(guān)系；培育和持續(xù)個人的改進活動；保證在全組織內(nèi)協(xié)調(diào)這些活動。

            由MSG任命SEPG。任命書作為管理層和SEPG的協(xié)議。提出任命書概括出SEPG的角色、責任和權(quán)威。任務(wù)是建立MSG；建立SEPG；開發(fā)SEPG（MSG）的任命書；向保證人演示改進活動；開發(fā)TWGs的任命書模板

            3、IDEAL模型與PDCA周期

            巴西電信公司（NEC do Brassil, NDB）在實施SPI時采用了PDCA周期[3]：其中P代表Plan(計劃)、D代表Do(行動)、C代表Check(檢查)、A代表Act(實施)。采用PDCA周期的理由是：（1）PDCA周期與客戶驅(qū)動質(zhì)量管理概念中建立的連續(xù)改進結(jié)構(gòu)一致；（2）PDCA周期實踐和術(shù)語已經(jīng)在NDB中制度化了；（3）PDCA周期包括了絕大多數(shù)IDEAL的目標需求。

            基于IDEAL模型與PDCA周期的分析和剪裁，SPI可以結(jié)構(gòu)化為如下階段（表5-1）

            表5-1  SPI的PDCA周期

            信息和數(shù)據(jù)輸入 信息和數(shù)據(jù)源應(yīng)該用于改進過程，也能夠用于SW-CMM評估過程或者客戶驅(qū)動管理過程

            改進計劃P 軟件工程質(zhì)量組（SEQT）和SEPG負責評審數(shù)據(jù)/信息，建立和記錄告訴的行動計劃已經(jīng)在各個領(lǐng)域展開

            改進執(zhí)行D SEQT和SEPG負責執(zhí)行、跟蹤和監(jiān)督行動計劃。該階段，要將必要的信息送去評審

            驗證和評審C 在涉及和綜合領(lǐng)導(dǎo)（公司和關(guān)鍵域質(zhì)量委員會）、SEQT及SEPG層次上進行評審

            實施A 實現(xiàn)系統(tǒng)變化和完成評審后的目標，為制度化和軟件質(zhì)量管理而標準化過程

            4、提高CMM的級別的ICASE模型

            ICASE是一個基本的系統(tǒng)開發(fā)過程改進模型，軟件開發(fā)組織可以用來達到其希望提高CMM的級別的目的。其中I代表Investigation(調(diào)查)：即調(diào)查組織的系統(tǒng)開發(fā)過程的現(xiàn)有狀態(tài)；C代表Construction建立：即在組織內(nèi)部建立一種意識，使開發(fā)人員和管理人員進入改進系統(tǒng)開發(fā)過程的概念中；A代表Action行動：即在組織中對必須要求的過程改進行動建立一張清單；S代表Selection選擇：即選擇一個計劃以達到要求的行動；E代表Execution執(zhí)行：即提交執(zhí)行的計劃必須的資源。

            最后，當開始不斷在CMM級別進行改進時，重復(fù)這一過程。

            5、CMM實施方法論的若干討論

            中國哲學講陰陽，講和諧，講平衡。講和諧講平衡不是不想前進，和諧就是有運動才能發(fā)出聲響的東西。平衡更是非同小可，在運動中需要格外講究。譬如滑冰，向前滑行了就必須尋找平衡，只講前進不找平衡，一定跌倒。要不斷前進就必須不斷尋找平衡，平衡與和諧就是前進的主旋律。

            軟件過程是關(guān)系錯綜復(fù)雜的各種活動的集合，各活動之間有時有嚴格的時序關(guān)系，有時是異步并行的，有時互為條件，有時互為反饋，因此實際的軟件過程中的活動存在一種復(fù)雜的網(wǎng)狀關(guān)系。軟件開發(fā)是一個高度動態(tài)的過程，動態(tài)變化滲透到了軟件過程的各個方面：需求說明、任務(wù)分配、調(diào)試、開發(fā)策略、工具集、支持環(huán)境等，這些變化的出現(xiàn)通常不可預(yù)料，造成的影響也無法確定。同時，軟件過程是一個面向人的系統(tǒng)，而軟件本身又是一種無形的產(chǎn)品，這就導(dǎo)致了工作進度難以控制，工作質(zhì)量難以評估，使整個過程有極大的模糊性。我們認為SW-CMM的對策是：無規(guī)矩不成方圓（按部就班寫文檔）；不積跬步無以至千里（積小成多，量變到質(zhì)變）；平衡與和諧（循序漸進，穩(wěn)中求變，有序和創(chuàng)造相統(tǒng)一），似乎應(yīng)該再加上適者生存（市場復(fù)雜多變，項目管理與戰(zhàn)略管理相結(jié)合，知識管理）。我們認為對我國軟件企業(yè)，技術(shù)和管理要一起抓，國外大學開設(shè)信息技術(shù)管理學院似乎較我國普遍采用的電子商務(wù)學院更有效和更實在。此外，CMM也不是全能的，我們從美國和印度的情況中發(fā)現(xiàn)它較適合用戶定制的大型軟件應(yīng)用系統(tǒng)和軟件出口，似乎不太適應(yīng)以軟件產(chǎn)品占領(lǐng)市場的軟件公司，例如金山和北大方正。微軟公司的哲理是追求高度靈活，企圖把一種松散（有時稱hacker）組織成的小組風格提升成正規(guī)的產(chǎn)品開發(fā)就是證明。因此，如何增強CMM靈活性也應(yīng)該認真研究，這對目前中國軟件企業(yè)也很重要。中國軟件企業(yè)現(xiàn)在最欠缺的就是管理以及有創(chuàng)新思維的人才。是否能夠像培養(yǎng)MBA那樣，采取大量培養(yǎng)IT技術(shù)管理的將才，讓這些將才在全球市場經(jīng)濟的競爭中自學成帥，以改變中國IT界“兵多將少沒有帥”的局面？

            我們在研究中初步發(fā)現(xiàn)能力形成過程中有兩點值得重視，現(xiàn)提出共同探討：其一是學習方式的變化，早期以農(nóng)業(yè)經(jīng)濟為主，人類知識總量也較少，學習主要是增加知識數(shù)量；隨著人類知識總量的增加和工業(yè)化的發(fā)展，有效地發(fā)揮所學的知識作用就顯得重要了，要學以致用；近年來，隨著信息技術(shù)和互聯(lián)網(wǎng)迅速發(fā)展，人類知識總量爆炸式地增加，為適應(yīng)經(jīng)濟全球化的復(fù)雜多變環(huán)境，就要求掌握知識發(fā)展學習能力和基礎(chǔ)素質(zhì)，基礎(chǔ)素質(zhì)又反過來發(fā)展學習能力，信息時代必須重視終身學習、實時學習、高效學習再加上組織學習，要溫故而創(chuàng)新。其二是通識能力的培養(yǎng)：就是要見多識廣，這就必須要打通古今中外、科學和文化、科技和經(jīng)濟以及各行業(yè)的隔閡和藩籬，以達“海闊憑魚躍，天高任鳥飛”的境界。

            例8，填空題

            SEI與惠普公司（Hewlett-Packard Corp.）合作，提出了實施SW-CMM的IDEAL模型。IDEAL模型是一個單位用于啟動、規(guī)劃和實現(xiàn)過程改善措施藍圖的模型，概括了建立一個成功的過程改善項目的必要步驟，其中I代表Initiating(啟動)、D代表Diagnosing(診斷)、E代表Establishing(建造)、A代表Acting(實施)、L代表Learning(學習)。IDEAL模型要求的支持軟件過程改進（Software Process Improvement, SPI）基礎(chǔ)設(shè)施的四個目的是：（1）維持SPI程序的可視性（Maintain Visibility）;（2）方便和鼓勵信息共享（Facilitate and Encourage Information Sharing）;（3）抓住和保存經(jīng)驗教訓(xùn)并發(fā)展改進（Capture and Retain Lessons Learned and Improvements Developed）;（4）提供支持網(wǎng)絡(luò)（Provide a Support Network）。

            IDEAL模型啟動階段任務(wù)如下：1）開始；2）識別改進的商業(yè)需要和推動者；3）建立SPI提議；4）教育和建立支持；5）獲得SPI提議的批準和啟動資源；6）建立軟件過程改進基礎(chǔ)設(shè)施；7）評估SPI的情況（Climate）；8）確定SPI總的目標；9) 確定SPI程序的指導(dǎo)原則；10) 正式啟動。