【文章內(nèi)容簡介】 靠程度之后再開始 β 測試 ：β測試是由軟件的多個用戶在 實際使用環(huán)境 下進行的測試，這些用戶返回有關(guān)錯誤信息給開發(fā)者，β測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現(xiàn)場應(yīng)用。 β 測試著重于產(chǎn)品的支持性，包括文檔、客戶培訓(xùn)和支持產(chǎn)品。只有當(dāng) α測試達到一定的可靠程度時，才開始β測試。它處在整個測試的最后階段。 軟件維護 (1)更正性維護 ：軟件產(chǎn)品交付后進行的修改，以更正發(fā)現(xiàn)的問題。 (2)適應(yīng)性維護 ：軟件產(chǎn)品交付后進行的修改，以保持軟件產(chǎn) 品能在變化后或變化中的環(huán)境中可以繼續(xù)使用。 (3)完善性維護 ：軟件產(chǎn)品交付后進行的修改，以改進性能和 可 維護性。 (4)預(yù)防性維護 ：軟件產(chǎn)品交付后進行的修改，以在軟件產(chǎn)品中的潛在錯誤成為實際錯誤前，檢測和更正它們。 ● 軟件質(zhì)量保證及質(zhì)量評價 軟件質(zhì)量：軟件特性的總合，軟件滿足規(guī)定或潛在用戶需求的能力。 11/87 “軟件滿足規(guī)定或潛在用戶需求的能力”要從軟件在內(nèi)部、外部和使用中的表現(xiàn)來衡量。 軟件質(zhì)量管理過程包括：質(zhì)量保證過程、驗證過程、確認(rèn)過程、評審過程、審計過程等。 1． 軟件質(zhì)量保證 軟件質(zhì)量保證過程通過 計劃制訂、實施和完成一組活動提供保證，這些活動保證項目生命周期中的軟件產(chǎn)品和過程符合其規(guī)定的需求。軟件質(zhì)量保證計劃定義了用于保證為特定產(chǎn)品開發(fā)的軟件滿足用戶需求并在項目的約束內(nèi)具有最高的質(zhì)量的手段。 2． 驗證與確認(rèn) 驗證與確認(rèn)過程使用能夠定位缺陷并便于以后改正的測試技術(shù)直接處理軟件產(chǎn)品質(zhì)量問題。驗證與確認(rèn)過程確定某一開發(fā)和維護 活動 的產(chǎn)品是否符合活動的需求， 最 終的軟件產(chǎn)品是否達到其意圖并滿足用戶需求。 驗證過程 試圖確保活動的輸出產(chǎn)品已經(jīng)被正確制造，即活動的輸出產(chǎn)品滿足前面活動施加的規(guī)范說明； 確認(rèn)過程 則試圖確保 建造了正確的產(chǎn)品，即產(chǎn)品滿足其特定的目的。 3． 評審與審計 評審與審計過程包括：管理評審、技術(shù)評審、檢查、走查、審計等。 管理評審 的目的是監(jiān)控進展，決定計劃和進度的狀態(tài)，確認(rèn)需求及其系統(tǒng)分配，或評價用于達到目標(biāo)適應(yīng)性的管理方法的有效性。它們支持有關(guān)軟件項目期間需求的變更和其他變更活動。 技術(shù)評審 的目的是評價軟件產(chǎn)品。以確定其對使用意圖的適合性，目標(biāo)是識別規(guī)范說明和標(biāo)準(zhǔn)的差異，并向管理提供證據(jù)，以表明產(chǎn)品是否滿足規(guī)范說明并遵從標(biāo)準(zhǔn)，而且可以控制變更。 檢查 的目的是檢測和識別軟件產(chǎn)品異常。一次檢查通常針對產(chǎn)品的 一個相對小的部分。發(fā)現(xiàn)的任何異常都要記錄到文檔中，并提交。 走查 的目的是評價軟件產(chǎn)品，走查也可以用于培訓(xùn)軟件產(chǎn)品的聽眾，主要目標(biāo)是： 發(fā)現(xiàn)異常、改進軟件產(chǎn)品、 考 慮其他實現(xiàn)、評價是否遵從標(biāo)準(zhǔn)和規(guī)范說明。走查類似于檢查，但通常不那么正式。走查通常主要由同事評審其工作，以作為一種保障技術(shù)。 軟件審計 的目的是提供軟件產(chǎn)品和過程對于可應(yīng)用的規(guī)則、標(biāo)準(zhǔn)、指南、計劃和流程的遵從性的獨立評價。審計是正式組織的活動，識別違例情況，并產(chǎn)生一個報告，采取更正性行動。 CMMI:軟件能力成熟度模型集成模型。 一級，已執(zhí)行 級 。 過程不 可預(yù)知，不能很好地被控制且是被動的。 12/87 二級， 已 管理級 。 項目級別定義了過程且經(jīng)常是被動的。 ? 需求管理：管理項目產(chǎn)品和產(chǎn)品組件的需求，識別需求與項目計劃和工作產(chǎn)品間的不一致性。 ? 項目策劃：建立和維護定義項目活動的計劃。 ? 項目監(jiān)督和控制：了解項目進展，以便當(dāng)項目性能明顯偏離計劃時采取適當(dāng)?shù)募m正措施。 ? 供應(yīng)商協(xié)議管理：管理來自供應(yīng)商的產(chǎn)品和服務(wù)的采購。 ? 度量分析：開發(fā)和保持測量能力，以支持管理信息的需要。 ? 配置管理：利用配置標(biāo)識、配置控制、配置狀態(tài)記錄和配置審計建立和維護工作產(chǎn)品的完整性。 ? 產(chǎn)品和過程質(zhì)量保證：使員 工和管理者對過程和相關(guān)的工作產(chǎn)品能有客觀洞察。 三級， 已 定義級 。 組織定義了過程且能起到積極主動的作用。 ? 需求開發(fā)：引導(dǎo)、分析及建立客戶、產(chǎn)品和產(chǎn)品部件的需求。 ? 技術(shù)方案：設(shè)計、開發(fā)和實現(xiàn)對需求的解決方案。 ? 產(chǎn)品集成：將產(chǎn)品組件組裝成產(chǎn)品，確保組裝后的產(chǎn)品能正常地運行并交付產(chǎn)品。 ? 驗證： 確保所選擇的工作產(chǎn)品滿足指定的需求。 ? 確認(rèn)： 證實產(chǎn)品或產(chǎn)品部件被置于其預(yù)定的環(huán)境中時，可以滿足預(yù)期的使用需求。 ? 組織過程焦點： 基于組織過程和過程資產(chǎn)的現(xiàn)有強項和弱項的深入理解，策劃、實施和部署組織的過程改進。 ? 組織過程定義 ：建 立和維護可用的組織過程資產(chǎn)集，工作環(huán)境標(biāo)志，以及對團隊的規(guī)則和指南。 ? 組織培訓(xùn)： 開發(fā)人員的技能和知識，以便他們能有效且高效地履行其角色。 ? 集成項目管理： 是根據(jù)由組織的標(biāo)準(zhǔn)過程集剪裁所得的集成的、已定義的過程，建立并管理項目以及利益相關(guān)方的參與。 ? 風(fēng)險管理： 在風(fēng)險發(fā)生前，標(biāo)識出潛在的問題，以便在產(chǎn)品或項目的整個生存周期中規(guī)劃風(fēng)險處理活動，并于必要時啟動這些活動，以緩解對目標(biāo)實現(xiàn)的不利影響。 ? 決策分析和方案： 使用正式的評價過程分析可能的決策，此評價過程按所建立的準(zhǔn)則評價所標(biāo)識的備選方案。 四級， 已定 量管理級 。 過 程度量和控制。 13/87 ? 組織過程性能： 建立并維護對組織的標(biāo)準(zhǔn)過程集合的定量了解，并且為定量管理組織的各個項目提供過程性能數(shù)據(jù)、基線和模型。 ? 定量項目管理： 對項目已定義過程實施定量管理，以便使項目實現(xiàn)所確定的質(zhì)量和過程性能目標(biāo)。 五級，優(yōu)化級 。 注重過程改進。 ? 組織性能管理： 對選擇并部署漸進式的改進項目和革新式的改進項目，對組織的過程和技術(shù)實施可度量的改進。 ? 原因分析和決策： 識別導(dǎo)致缺陷和其他問題的原因，并采取措施，防止將來再次發(fā)生這些問題。 ● 軟件配置管理 配置管理員根據(jù)《項目計劃文檔》、《配置管理計劃》、《配置 項管理表》等文檔，創(chuàng)建 構(gòu)造或發(fā)行基線 ，供內(nèi)部使用或交付給顧客。 軟件配置管理是通過在軟件生命周期的不同的時間點上對軟件配置進行標(biāo)志并對這些被標(biāo)志的軟件配置項的更改進行系統(tǒng)控制，從而達到保證軟件產(chǎn)品的 完整性 和 可追溯性 的過程。 軟件配置管理的四個功能： 配置 標(biāo)識 、 配置控制 、 配置狀態(tài)發(fā)布 、 配置的評審 。 接受軟件配置管理過程控制的軟件受控配置項應(yīng)包括一切可能對軟件產(chǎn)品的完整性和一致性造成影響的組成要素。比如項目文檔、產(chǎn)品文檔、代碼、支撐數(shù)據(jù)、項目編譯建立環(huán)境、項目運行環(huán)境等。 配置項 是邏輯上組成軟件系統(tǒng)的各組成部分， 是軟件配置管理的基礎(chǔ)和前提。 基線 是一個配置項或一組配置項在其生命周期的不同時間點通過正式評審而進入正式受控的一種狀態(tài)，這個過程被稱為基線化。每一個基線都是其下一步開發(fā)的出發(fā)點和參考點。上一個基線加上增加和修改的基線內(nèi)容形成下一個基線。這就是基線管理， 基線具有以下屬性： 通過正式的評審過程建立 基線存在于基線庫中，對基線的變更接受更高權(quán)限的控制。 基線是進一步開發(fā)和修改的基準(zhǔn)和出發(fā)點 配置 標(biāo)識 是軟件生命周期里選擇定義各類配置項，建立各類基線、描述相關(guān)軟件配置項及其文檔的過程。配置 標(biāo)識 分為三 個步驟： 將軟件分組成一系列軟件配置項 14/87 定義對配置項命名規(guī)則 對配置項的描述文檔（功能，性能，物理特性等） 配置控制 是對配置項的變更申請進行初始化、評估、協(xié)調(diào)、實現(xiàn)，包括將通過和實現(xiàn)的變更加入到基線中的更改控制過程。 變更控制 變更分為兩種類型： 功能變更 和 錯誤修復(fù)變更 功能變更：根據(jù)客戶的需要增加或刪除某些功能，或者修改實現(xiàn)功能的方法所引起的變更 錯誤修改變更是為了修改漏洞的需要而產(chǎn)生的變更 變更申請 成本 /效益分析 決定是否進行變更 實施變更 審查 檢入 配置狀態(tài)報告 是跟 蹤對軟件的更改的過程，它保證對正在進行和已完成的變更進行記錄、監(jiān)視并通報。用以跟蹤對已建立基線的需求、源代碼、數(shù)據(jù)，以及相關(guān)文檔的更改。 配置狀態(tài)記錄 編制配置狀態(tài)報告：軟件配置項的狀態(tài)、變更申請和已批準(zhǔn)的變更實現(xiàn)情況 配置狀態(tài)發(fā)布：通知相關(guān)管理人員和軟件工程師 配置庫 收集所有與配置有關(guān)的信息，評價系統(tǒng)變更的效果，為配置管理過程提供管理信息 開發(fā)庫：專供給開發(fā)人員使用，內(nèi)容可由開發(fā)人員決定是否修改 受控庫：也稱為軟件配置管理庫 產(chǎn)品庫：存放最終產(chǎn)品、等待交付用戶或現(xiàn)場安裝的產(chǎn)品 配置評審 15/87 是驗證一個可發(fā)布的軟件基線是否包含了它應(yīng)包括的所有內(nèi)容。包括功能配置評審和物理配置評審。 功能配置評審：確認(rèn)軟件已通過測試并滿足基線規(guī)定的需求說明，保證正確性 。 物理配置評審：確認(rèn)將發(fā)布的軟件包含了所有必需的組成部分（代碼、文檔、數(shù)據(jù)）保證完整性 判斷變更是否正確完成，需進行正式技術(shù)評審和軟件配置審核 正式技術(shù)評審：檢查已完成修改的軟件配置對象的技術(shù)正確性 軟件配置審核：各項產(chǎn)品在技術(shù)上和管理上的完整性。 ● 軟件開發(fā)環(huán)境 軟件開發(fā)環(huán)境的結(jié)構(gòu)為層次性結(jié)構(gòu)，分為四層 宿主層 ：包括基本宿主硬件和基本宿主軟件 核心層：包括工具組、環(huán)境數(shù)據(jù)庫和會話系統(tǒng) 基本層：包括至少一組工具，如編譯工具、調(diào)試工具等 應(yīng)用層：以基本層為基礎(chǔ)補充某些工具，以適應(yīng)應(yīng)用軟件的要求。 ● 軟件過程管理 軟件過程改進 SPI： 幫助軟件企業(yè)對其軟件（制作）過程的改變（進）進行計劃、（措施）制定以及實施 的過程，一般從 問題分析 開始。五條核心原則：注重問題；強調(diào)知識創(chuàng)新；鼓勵參與；領(lǐng)導(dǎo)層的統(tǒng)一；計劃不斷地改進。 ● 構(gòu)件及其在信息系統(tǒng)項目中的重要性 ● 常用構(gòu)件標(biāo)準(zhǔn)（ COM/DCOM/COM+、 CORBA和 EJB） ● 軟件體系結(jié)構(gòu)定義 ● 典型體系結(jié)構(gòu) ● 軟件體系結(jié)構(gòu)設(shè)計方法 ● 軟件體系結(jié)構(gòu)分析與評估 軟件體系結(jié)構(gòu)評估的主要方式：基于調(diào)查問卷或檢查表的評估方式；基于場景的評估方式；基于度量的評估方式。 ● 軟件中間件 ● 面向?qū)ο蟮幕靖拍? 面向?qū)ο?=對象 +類 +繼承 +消息通信 16/87 面向?qū)ο蟮幕靖拍钣袑ο?、類、抽象、封裝、繼承、多態(tài)、接口、消息、組件、模式和復(fù)用等 。 對象 是是用來描述客觀事物的一個封裝，是構(gòu)成系統(tǒng)的基本單位。 對 象包含三個基本要素，對象 標(biāo)識 、對象 屬性 和對象 服務(wù) 。每一個對象必須有一個名字以區(qū)別于其他對象，這就是對象標(biāo)識； 屬性 用來描述對象的某些特征 （靜態(tài)） ； 服務(wù) 用來封裝對象所擁有的業(yè)務(wù)操作 （動態(tài)） 。 類 是 對象的抽象定義，是一組具有相同數(shù)據(jù)結(jié)構(gòu)和相同操作的對象的集合 。對象是類的實際例子 。 封裝 是將數(shù)據(jù)和基于數(shù)據(jù)的操作封裝成一個整體對象，對數(shù)據(jù)的訪問或修改只能通過對象對外提供的接口進行。 繼承 表示類之間的層次關(guān)系，這種關(guān)系使得某類對象可以繼承另外一類對象的特征（ attributes）和能力（ operations），繼承又可分為單繼承和多繼承，單繼承是子類只從一個父類繼承，而多繼承中的子類可以從多于一個的父類繼承， Java是單繼承的語言，而 C++允許多繼承。 假設(shè)類 B繼承類 A，即類 B中的對象具有類 A的一切特征（包括屬性和操作）。 類 A稱為基類或父類或超類，類 B稱為 類 A的派生類或子類，類 B在類A的基礎(chǔ)上還可以有一些 擴展。 如圖 32所示， Dog和 Cat類都是從 Mammal繼承而來，具有父類的eyeColor屬性特征，因此在子類中就下用重復(fù)指定 eyeColor這個屬性。 17/87 多態(tài) 使得一個屬性或變量在不同的時期可以表示不同類的 對象。 如圖 33所示， Rectangle和 Circle都繼承于 Shape，對于 Shape而言，會有 getArea0的操作。但顯而易見， Rectangle和 Circle的 getArea()方法的實現(xiàn)是完全不一樣的，這就體現(xiàn)了多態(tài)的特征。 接口 就是對操作規(guī)范的說明。接口只是說明操作應(yīng)該 做什么 ( What)，但沒有定義操作如何做 ( How)。接口可以理解成為類的一個特例，它只規(guī)定實現(xiàn)此接口的類的操作方法，而把真正的實現(xiàn)細節(jié)交由實現(xiàn)該接口的類去完成。 接口在面向?qū)ο蠓治龊驮O(shè)計過程中起到了至關(guān)重要的橋梁作用，系統(tǒng)分析員通常先把有待實現(xiàn)的功能封裝并定義成接口，而后期程序員依據(jù)此接口進行編碼實現(xiàn)。 消息 （ Message）是對象間的交互手段，其形式如下： Message: [,para] 其中 dest指目標(biāo)對象 Destination Object， op指操作 Operation， para指操作需要的參數(shù) Parameters。 ● 統(tǒng)一建模語言 UML UML是一種可視化建模語言。 UML標(biāo)準(zhǔn)并沒有定義一種標(biāo)準(zhǔn)的開發(fā)過程，但它比較適用于 迭代式 的開發(fā)過程，是為支持大部分現(xiàn)存的面向?qū)ο箝_發(fā)過程而設(shè)計的。 ● 可視化建模 UML提供了如下 9種主要的圖來對待建系統(tǒng)進行建模。 1） 用例圖 ：用例模型描述的是外部執(zhí)行者（ Actor）所理解的系統(tǒng)功能