基于UML的軟件項目的過程質(zhì)量保障

定　價：￥49.00

作　者：	（美國）恩海爾克著、曹學軍等譯
出版社：	電子工業(yè)出版社
叢編項：	軟件工程叢書
標　簽：	UML

購買這本書可以去

ISBN：	9787120000837	出版時間：	2004-07-01	包裝：	平裝
開本：		頁數(shù)：	320	字數(shù)：

內(nèi)容簡介

　　本書是一本專注于過程的探討基于UML的軟件項目的質(zhì)量保障的圖書，它簡明扼要地闡述了UML的歷史背景，UML定義，以及UML和實際的建模技術的相關性，通過一系列的對基于UML的CASE工具和開發(fā)過程的講座來加深讀者對采用UML進行直接和實際建模的理解。本書還特別地強調(diào)對要從事每個開發(fā)過程活動的角色的定義，重視系統(tǒng)開發(fā)中社會特征的重要性。本書適合于IT業(yè)的質(zhì)量經(jīng)理、項目經(jīng)理、過程工程師、測試人員、系統(tǒng)設計師、開發(fā)人員、業(yè)務分析員、系統(tǒng)架構師、學術研究人員等人閱讀，也可作為大中院校的教材。前言質(zhì)量是主觀判斷1本書探討在基于UML的軟件項目中，實施質(zhì)量保障中的過程這方面的問題。過程是軟件質(zhì)量保障的兩個主要領域之一，另一個是建模。鑒于基于UML的軟件項目的質(zhì)量保障的，尤其是專注于過程這一方面的文獻缺乏的現(xiàn)狀，本書應運而生了。這是因為，盡管UML的文獻資料現(xiàn)在非常流行，但還是需要一些討論UML在項目中的應用的質(zhì)量和實踐問題的圖書。雖然我們現(xiàn)在已經(jīng)有了一些非常優(yōu)秀的論述軟件開發(fā)過程的文獻（其中包括由Jacobson等人創(chuàng)作的最為著名的《TheUnifiedProcess》，以及由IanGraham等人撰寫的《TheOPENProcessSpecification》），但是看起來還是缺乏單獨的針對質(zhì)量做探討的圖書。另一方面，像Binder的《TestingObjectOrientedSoftware》這樣的作品，關注的是采用UML表示法進行的技術層面的測試內(nèi)容。當然，我們不能責備上述提到的文獻缺少對質(zhì)量方面問題的討論，因為這些作品并不是專門致力于討論質(zhì)量的。這些讓人尊敬和受到廣泛歡迎的作品的關注焦點要么是開發(fā)，要么是測試。而在您手中的這本書就填補了在UML領域對質(zhì)量問題的關注空缺。好的質(zhì)量包括了所有能夠滿足用戶需要的各個方面的內(nèi)容。不過，“好”是一個主觀色彩非常濃厚的詞。對質(zhì)量做出判定的參考點取決于時間、地點和形勢，而所有這些都隨時會發(fā)生變化！因此，能夠產(chǎn)生好質(zhì)量的基本要素是：一個能夠滿足用戶不斷變化的需求的產(chǎn)品；一個能夠使創(chuàng)建、驗證、確認這樣一個產(chǎn)品成為可能的開發(fā)過程；一套能夠建立良好溝通的通用機制；對生產(chǎn)產(chǎn)品的開發(fā)過程的連續(xù)不斷的改進。當這些要素應用到軟件開發(fā)領域中時，這些質(zhì)量上的需求就變成了生產(chǎn)的軟件產(chǎn)品必須能夠在規(guī)劃、擴展和變更等各方面滿足客戶的需求——主要是業(yè)務方面的。我們不僅需要能夠生產(chǎn)出這樣的軟件產(chǎn)品的開發(fā)過程，而且需要能夠對這些用來構建軟件產(chǎn)品的模型和過程做有效檢查和交叉查證。我們同樣也需要建立、遵循和查證所有的過程步驟，以期能夠建立一套可以生產(chǎn)高質(zhì)量軟件產(chǎn)品的成熟過程體系。這些過程步驟必須以一種迭代式的、漸增的、充分的方式進行。過程步驟必須足夠靈活，以適應不同的開發(fā)環(huán)境和不同類型與規(guī)模大小的軟件項目。這些都是專門化的與過程質(zhì)量相關的工作領域的內(nèi)容，這些內(nèi)容對于本書所探討的在項目中實施UML技術而言是必需的。這些質(zhì)量方面的工作包括如何組織整個質(zhì)量職能體系，還包括驗證和確認這些UML框圖所需的步驟，以及什么時候實施這樣的驗證，如何理解質(zhì)量工作的結果數(shù)據(jù)，應該由誰來負責創(chuàng)建和確認UML框圖，如何建立質(zhì)量控制（測試）策略。這些過程步驟將促成高質(zhì)量的模型產(chǎn)生。通過對軟件模型實施質(zhì)量檢查也能夠進一步提升質(zhì)量，從而確保它們句法正確、語義一致和美學上和諧。如果希望了解對于UML框圖的模型質(zhì)量的詳細分析和討論，我推薦讀者閱讀《ModelQualityAssuranceofUML-BasedProject》。本書分為6章，內(nèi)容概述如下表所示。章說明1．質(zhì)量競賽建立背景理論和有關質(zhì)量方面的論點2．質(zhì)量環(huán)境：質(zhì)量職能管理質(zhì)量管理，團隊組建，高質(zhì)量團隊的社會學和心理學特性；過程的重要性3．質(zhì)量過程體系架構過程組件由能夠組成一個質(zhì)量軟件過程體系的活動、任務、交付品和角色構成4．實施質(zhì)量軟件過程實踐中的質(zhì)量過程、迭代、漸增和并行的軟件開發(fā)5．基于UML的項目估算和度量一些針對實際的基于UML的軟件項目的時間、預算和人員的估算建議6．軟件產(chǎn)品的質(zhì)量控制針對質(zhì)量控制和測試策略做詳盡的討論第1章質(zhì)量競賽本章是有關質(zhì)量保障的背景介紹。我們討論了在軟件開發(fā)背景條件下質(zhì)量的不確定特性。而建模，尤其是采用UML技術的建模，作為一種能夠改進溝通和質(zhì)量的手段，在分別是問題、解決方案和背景的三個彼此相關的建?？臻g中得以實施。我們將在技術（做什么）、方法（如何做）和社會學（誰來做）三個維度的背景條件下討論軟件過程。這以后我們會討論不同類型的檢查（語法方面、語義方面和美學方面），這些檢查是我們確認和驗證基于UML的模型的手段。我們還將討論高質(zhì)量過程體系所必需的必要性、充分性和可塑性等內(nèi)容的一些檢查。在本章中，我們也將討論質(zhì)量職能的組織，以及如何應用到不同類型（包括開發(fā)、集成、工具包實現(xiàn)、外包、數(shù)據(jù)倉庫和教育類項目）和不同規(guī)模大?。ㄐ⌒?、中型和大型）的軟件項目中去。第2章質(zhì)量環(huán)境：質(zhì)量職能管理質(zhì)量在軟件過程方面的內(nèi)容包括建立和管理一個質(zhì)量環(huán)境的管理職能。這是因為，質(zhì)量并不只是驗證和確認生產(chǎn)出了什么東西，同時它也要求我們努力遵循一種生產(chǎn)模型和軟件的規(guī)程體系。這套規(guī)程包括與生產(chǎn)出高質(zhì)量模型或軟件相關的所有軟件過程和相關步驟。本書的這一部分將全面考察質(zhì)量職能機構的組織和執(zhí)行，其中將仔細強調(diào)基于UML的軟件開發(fā)過程方面的內(nèi)容。換句話說，我們將討論在基于UML的軟件項目中，質(zhì)量職能體系將“如何”得到組織和貫徹。至于人員方面的問題（“誰來做”），我們在本章的適當?shù)胤揭矔o予足夠的關注。第3章質(zhì)量過程體系架構在本章中，我們將討論這樣一個軟件過程是由什么組成的，以及這樣的過程在基于UML的軟件項目中是如何改進質(zhì)量的。這一章并沒有提出什么新的軟件過程，而是討論了一個一般意義上的軟件過程，我們將從技術、方法和社會學三個維度來討論一個開發(fā)過程的組成，以及它在各主要維度中的內(nèi)容。開發(fā)過程的技術維度主要關注的是“做什么”的問題，方法維度考慮的是“如何做”的問題，社會學維度主要考慮整個過程中“誰來做”的問題。我們將采用普通工作日的例子來說明這些維度中的內(nèi)容。這個通用過程會進一步地描述一些最常見的活動和任務，這些活動和任務在任何一個開發(fā)過程中都應該被提到。我們討論這些活動和任務及它們相關的角色和交付品的目的在于，希望能夠改進這樣一個開發(fā)過程的具體規(guī)程，從而提升基于UML的交付品的質(zhì)量，最終提高軟件產(chǎn)品的質(zhì)量。第4章實施質(zhì)量軟件過程在本章中，我們將討論如何運轉一個實例軟件過程，這個實例涵蓋了在配置一個迭代、漸增、并行的（IIP）項目的計劃過程中會遇到的種種實際問題。我們將基于在前一章中討論的過程組件來分析。我們也會討論到一些跟蹤項目進展的實際問題，以及基于跟蹤到的情況來修改項目計劃的內(nèi)容。與順序式的項目計劃相比，迭代的、漸增的項目計劃更容易處理各種變化情況。從軟件過程的可塑性出發(fā)，我們也會討論如何建立和管理這樣一個可變化的項目計劃。我們還會應用軟件過程的術語來討論當“輪胎撞到路面”時會發(fā)生什么事情。第5章基于UML的項目估算和度量在本章中，我們將討論的重要問題是在基于UML的軟件項目中如何實施估算和度量。首先我們會論述實施好的項目估算的必要性，以及一個好的項目度量體系是如何幫助實現(xiàn)好的項目估算的，這一章我們會深入探討這些度量指標和估算對于改進項目中的模型和過程質(zhì)量的重要意義。有關UML成品和框圖的大小及復雜性在內(nèi)的技術方面的度量指標也會被談及。我們會以一個采用UML的項目為例來討論如何做項目估算，通過這個例子我們希望能夠讓大家了解到，在實際的項目中是如何應用度量指標并發(fā)揮其關鍵作用的。第6章軟件產(chǎn)品的質(zhì)量控制本章我們將詳細討論在質(zhì)量生命周期中，如何進行質(zhì)量控制和測試。我們在上一章中討論過程質(zhì)量的時候，已經(jīng)把質(zhì)量控制（測試）作為一個主要的過程組件了。它會幫助我們在創(chuàng)建模型時和隨后的開發(fā)過程中驗證和確認我們的努力成果。好的質(zhì)量控制本身就是從負面來看問題，因為它的目標在于打破系統(tǒng)中的所有事物，包括邏輯組成、執(zhí)行過程和性能。因此，盡管質(zhì)量控制是質(zhì)量保障的不可分割的一部分，然而它并不是和質(zhì)量保障同步進行的。在本書的這個獨立章節(jié)中，我們已經(jīng)對這種控制和保障的分離現(xiàn)象給予了應有的重視。光盤和Web支持本書附帶的只讀光盤中包含了各章內(nèi)容的一些詳細資料、框圖和一套模板文件（包括成品、項目計劃等），這些模板可以在具體的項目中做個性化定制。光盤中還包括了一些為改進質(zhì)量而推薦的度量指標（例如實例的數(shù)量，以及在類的創(chuàng)建中所花費的工作量等）。經(jīng)過工具廠商的許可，光盤中還包括了一些和質(zhì)量過程有關的過程工具的評估版軟件。讀者指南現(xiàn)在有不少專門討論UML和討論軟件過程的圖書。這些書涵蓋的內(nèi)容既包括學術研究，也包括實際應用。本書試圖將質(zhì)量過程應用到基于UML的軟件項目中。由于本書的關注點在于軟件過程，因此我們期望讀者已經(jīng)熟悉了UML和基于UML的建模技術，本書不打算討論UML的建模技術，請參考相關資料。不過，任何一名負責質(zhì)量保障的讀者都會發(fā)現(xiàn)本書的內(nèi)容是相對獨立的，讀完本書后，應該可以拓展對UML的理解。下面是一個圖書分類的交叉引用表，通過這個表，讀者應該可以了解自己對每一章內(nèi)容感興趣的程度。興趣強度值是通過星號“*”的個數(shù)表示的（三顆星代表最強烈）。章質(zhì)量經(jīng)理項目經(jīng)理測試人員過程工程師系統(tǒng)設計師開發(fā)人員業(yè)務分析員系統(tǒng)架構師學術研究人員主管1．質(zhì)量競賽**********2．質(zhì)量環(huán)境：質(zhì)量管理職能**********3．質(zhì)量過程體系架構**********4．實施軟件質(zhì)量過程**********5．項目估算和基于UML的項目度量指標*******6．軟件產(chǎn)品的質(zhì)量控制***********語義說明我非常信任中性詞匯，因此我將盡可能地使用人這樣的中性詞。不過，為了便于閱讀，我也會使用他。除非特別聲明，程序員及質(zhì)量經(jīng)理這樣的術語都是指充當特定角色的人。這些詞指的并不是如你我這樣的真實人物，因此他們完全可以在很短的時間內(nèi)從程序員的角色跳到質(zhì)量經(jīng)理或者主管之類的角色。讀者也應該意識到，人們可以同時充當一個以上的角色。例如，一個業(yè)務分析員也可能是一個兼職的學術或者研究人員。我們一詞貫穿全書，指的都是讀者和作者，也就是你和我。偶爾，我們也會指代一般意義上的信息技術（IT）人員全體，當然作者也是其中的一員。我們還可能指代作者本人所工作的團隊。因此，盡管這是一本由一個作者寫成的書，你會發(fā)現(xiàn)我們指的既可能是作者自己，也可能是IT人員全體。正如你和我從本書中看到的情況一樣，現(xiàn)實的話語往往不能按靜態(tài)的方式來理解。和研討班的內(nèi)容對應本書表述的UML和質(zhì)量實踐方面的內(nèi)容在很多的研討和會議上非常熱門。在基于本書內(nèi)容所做的多次演講的講稿中，特別值得一提的是，它們在加拿大多倫多舉行的UML21大會上被接納作為教程，另外它們在印度孟買、班加羅爾和德里舉行的為期兩天的系列2研討會上被作為研究資料。在本書寫作時，還有不少額外的研討班也被安排進了日程。下面的表格列出了基于本書內(nèi)容而做的兩天研討班中的一天的內(nèi)容大綱。針對學生或者學術工作者，本書的每一章內(nèi)容都對應一個三小時的主題介紹，兩天討論班第一天的內(nèi)容主要集中在采用案例分析的方式來建立基于UML的模型。本書各章和兩天研討班中的一天內(nèi)容的對應時間段討論和介紹的主題內(nèi)容對應的章節(jié)說明9：-1：3質(zhì)量方面的壓力；在UML項目中的意義1，2概述質(zhì)量不確定的特性；提出解決質(zhì)量問題的必要性和方法11：-12：3質(zhì)量管理；質(zhì)量過程體系架構3，4如何組建質(zhì)量職能部門；質(zhì)量管理和質(zhì)量過程1：3-3：過程的運轉；項目估算和度量；UML成品的質(zhì)量控制（測試）5，6關于數(shù)字的實踐研討?；赨ML的軟件項目的人員、時間和預算3：3-5：案例分析光盤案例討論；在實踐中運行檢查列表

作者簡介

　　BhuvanUnhelkar博士，是MethodScience.com的負責人，廣受尊敬的咨詢家、培訓老師、作家和演講家，計算機世界對象開發(fā)者的“跨機構的面向對象方法最佳使用獎”獎項的獲得者，著有4本著作及大量論文、出版作品和演示作品。

圖書目錄

第1章  質(zhì)量競賽
1.1  不確定的軟件質(zhì)量
1.1.1  給質(zhì)量下定義
1.1.2  質(zhì)量和客觀努力
1.1.3  軟件的特性
1.1.4  質(zhì)量保障：一項獨特的工作
1.2  施加到質(zhì)量上的各種壓力
1.2.1  預算
1.2.2  時間
1.2.3  功能
1.2.4  質(zhì)量
1.3  質(zhì)量層次
1.3.1  數(shù)據(jù)質(zhì)量
1.3.2  代碼質(zhì)量
1.3.3  模型質(zhì)量
1.3.4  過程質(zhì)量
1.3.5  管理質(zhì)量
1.3.6  質(zhì)量環(huán)境
1.4  質(zhì)量軟件過程
1.4.1  過程的組成
1.4.2  例子——一個烤糕點過程
1.4.3  過程關系的正交性
1.4.4  軟件背景下的過程
1.4.5  軟件過程
1.4.6  質(zhì)量過程
1.4.7  質(zhì)量保障和測試：請不要混淆它們
1.5  建模與質(zhì)量
1.5.1  建模的目的
1.5.2  有關建模的警示
1.5.3  理解軟件中的建模空間
1.5.4  問題空間
1.5.5  解決方案空間
1.5.6  背景空間
1.6  UML和質(zhì)量
1.6.1  UML簡史
1.6.2  UML的質(zhì)量與采用UML的質(zhì)量
1.6.3  元模型和質(zhì)量
1.6.4  采用UML的質(zhì)量
1.6.5  可視化呈現(xiàn)的質(zhì)量
1.6.6  規(guī)格說明的質(zhì)量
1.6.7  構建的質(zhì)量
1.6.8  文檔的質(zhì)量
1.6.9  UML圖和它們在建?？臻g中的重要性的總結
1.7  語法、語義和美學上的質(zhì)量保障技術
1.7.1  模型語法質(zhì)量
1.7.2  模型語義質(zhì)量
1.7.3  模型美學質(zhì)量
1.8  軟件過程的質(zhì)量保障：必要性，充分性和可塑性
1.8.1  過程質(zhì)量的必要性
1.8.2  過程質(zhì)量的充分性
1.8.3  過程質(zhì)量的可塑性
1.9  復用，模式和質(zhì)量
1.9.1  通過復用來提高產(chǎn)能
1.9.2  復用專家知識和經(jīng)驗
1.9.3  標準的應用
1.10  質(zhì)量和易用性
1.10.1  易用性原則
1.10.2  界面的易導航性
1.10.3  GUI設計和質(zhì)量
1.11  基于UML的項目類型
1.11.1  開發(fā)類項目
1.11.2  （和傳統(tǒng)應用）集成類項目
1.11.3  軟件包實施類項目（ERP，CRMS）
1.11.4  外包類項目
1.11.5  數(shù)據(jù)倉庫和轉換類項目
1.11.6  教育類項目
1.12  基于UML的項目——大小和可擴展性
1.12.1  小型項目
1.12.2  中型項目
1.12.3  大型項目
1.13  本章關鍵點回顧
1.14  文獻注解
1.15  常見問題解答（FAQs）
1.16  練習
1.17  參考資料
第Ⅱ部分  為質(zhì)量組織和制定軟件過程
第2章  質(zhì)量環(huán)境：質(zhì)量職能管理
2.1  質(zhì)量管理
2.1.1  質(zhì)量環(huán)境
2.1.2  非技術管理
2.1.3  過程和質(zhì)量
2.2  團隊組織
2.2.1  問題空間的角色構成
2.2.2  業(yè)務分析員
2.2.3  用戶
2.2.4  最終用戶
2.2.5  行業(yè)專家
2.2.6  問題空間中的原型創(chuàng)建者
2.2.7  解決方案空間中的角色構成
2.2.8  系統(tǒng)設計師
2.2.9  數(shù)據(jù)建模員
2.2.10  界面設計師
2.2.11  程序員
2.2.12  測試人員
2.2.13  解決方案空間中的原型創(chuàng)建者
2.2.14  背景空間中的角色構成
2.2.15  系統(tǒng)架構師
2.2.16  背景空間中的原型創(chuàng)建者
2.2.17  數(shù)據(jù)庫管理員
2.2.18  公共角色
2.2.19  項目經(jīng)理
2.2.20  指導委員會
2.2.21  業(yè)務主辦方
2.2.22  質(zhì)量團隊的角色構成
2.2.23  質(zhì)量經(jīng)理
2.2.24  質(zhì)量分析員
2.2.25  過程工程師
2.2.26  用戶
2.2.27  測試人員
2.3  質(zhì)量環(huán)境
2.3.1  E化因素和質(zhì)量
2.3.2  基于UML的項目所特有的軟因素問題
2.3.3  質(zhì)量環(huán)境中的溝通
2.3.4  遠程工作
2.4  項目社會學
2.4.1  四種項目團隊模型
2.4.2  創(chuàng)建同源團隊的最好方式
2.4.3  扁平化金字塔
2.4.4  人員和可復用性
2.4.5  并行開發(fā)的團隊
2.5  軟件項目中的相互影響分析
2.5.1  相互影響分析的簡史
2.5.2  父母型、大人型和小孩型的自我狀態(tài)
2.5.3  生活定位
2.5.4  游戲
2.5.5  面向對象項目中的游戲
2.5.6  用之還是棄之
2.5.7  牛仔式編程
2.5.8  和面粉
2.5.9  會議癥
2.5.10  最后期限
2.6  流行的質(zhì)量技術
2.6.1  走查
2.6.2  檢查
2.6.3  評審
2.6.4  審計
2.6.5  檢查清單
2.6.6  交談
2.6.7  研討會
2.7  標準和質(zhì)量
2.7.1  標準的應用場合
2.7.2  項目、機構和業(yè)界標準
2.8  過程成熟度：CMM標準
2.8.1  能力成熟度模型
2.8.2  個人軟件過程成熟度
2.8.3  在基于UML的項目中應用CMM
2.9  過程檢查
2.9.1  必要性檢查
2.9.2  充分性檢查
2.9.3  過程的可塑性檢查
2.10  計劃類交付品
2.10.1  項目組織計劃
2.10.2  質(zhì)量計劃
2.10.3  測試計劃
2.11  文獻注解
2.12  常見問題解答（FAQs）
2.13  練習
2.14  參考資料
第3章  質(zhì)量過程體系架構
3.1  過程中樞
3.1.1  過程的三個維度
3.1.2  過程的技術維度
3.1.3  過程的方法維度
3.1.4  過程的社會學維度
3.2  過程元模型
3.2.1  描述過程元模型
3.2.2  過程要素
3.2.3  過程中的角色元素
3.2.4  過程中的活動元素
3.2.5  過程中的任務元素
3.2.6  過程中的交付品元素
3.2.7  過程組件
3.2.8  迭代
3.2.9  將過程組件的元素放在一起：一個烤制過程
3.3  質(zhì)量軟件過程
3.3.1  軟件過程
3.3.2  質(zhì)量過程
3.3.3  過程的嚴格程度
3.3.4  過程成熟度
3.3.5  過程的可塑性
3.3.6  過程的時間要求
3.4  軟件過程
3.4.1  業(yè)務評估過程組件
3.4.2  業(yè)務評估中的角色
3.4.3  業(yè)務評估中的活動和任務
3.4.4  業(yè)務評估的交付品
3.4.5  有關業(yè)務評估的提示和建議
3.4.6  項目管理過程組件
3.4.7  項目管理中的角色
3.4.8  項目管理中的活動和任務
3.4.9  項目管理中的交付品
3.4.10  項目管理的提示和建議
3.4.11  過程配置組件
3.4.12  過程配置中的角色
3.4.13  過程配置中的活動和任務
3.4.14  過程配置中的交付品
3.4.15  過程配置的提示和建議
3.4.16  需求建模過程組件
3.4.17  需求建模中的角色
3.4.18  需求建模中的活動和任務
3.4.19  需求建模的交付品
3.4.20  需求建模的提示和建議
3.4.21  接口建模與設計過程組件
3.4.22  接口建模中的角色
3.4.23  接口建模中的活動和任務
3.4.24  接口建模中的交付品
3.4.25  接口建模的提示和建議
3.4.26  系統(tǒng)設計過程組件
3.4.27  系統(tǒng)設計中的角色
3.4.28  系統(tǒng)設計中的活動和任務
3.4.29  系統(tǒng)設計中的交付品
3.4.30  系統(tǒng)設計的提示和建議
3.4.31  持久化設計過程組件
3.4.32  持久化設計中的角色
3.4.33  持久化設計中的活動和任務
3.4.34  持久化設計中的交付品
3.4.35  持久化設計的提示和建議
3.4.36  實現(xiàn)過程組件
3.4.37  實現(xiàn)中的角色
3.4.38  實現(xiàn)中的活動和任務
3.4.39  實現(xiàn)中的交付品
3.4.40  實現(xiàn)的提示和建議
3.4.41  原型創(chuàng)建過程組件
3.4.42  原型創(chuàng)建中的角色
3.4.43  原型創(chuàng)建中的活動和任務
3.4.44  原型創(chuàng)建中的交付品
3.4.45  原型創(chuàng)建的提示和建議
3.4.46  變更管理過程組件
3.4.47  變更管理中的角色
3.4.48  變更管理中的活動和任務
3.4.49  變更管理的交付品
3.4.50  變更管理的提示和建議
3.4.51  企業(yè)架構過程組件
3.4.52  企業(yè)架構中的角色
3.4.53  企業(yè)架構中的活動和任務
3.4.54  企業(yè)架構中的交付品
3.4.55  企業(yè)架構的提示和建議
3.4.56  系統(tǒng)架構過程組件
3.4.57  系統(tǒng)架構中的角色
3.4.58  系統(tǒng)架構中的活動和任務
3.4.59  系統(tǒng)架構中的交付品
3.4.60  系統(tǒng)架構的提示和建議
3.4.61  部署過程組件
3.4.62  部署中的角色
3.4.63  部署中的活動和任務
3.4.64  部署中的交付品
3.4.65  部署的提示和建議
3.4.66  培訓過程組件
3.4.67  培訓中的角色
3.4.68  培訓中的活動和任務
3.4.69  培訓中的交付品
3.4.70  培訓的提示和建議
3.4.71  復用過程組件
3.4.72  復用中的角色
3.4.73  復用的活動和任務
3.4.74  復用的交付品
3.4.75  復用的提示和建議
3.5  質(zhì)量過程
3.5.1  質(zhì)量管理過程組件
3.5.2  質(zhì)量管理中的角色
3.5.3  質(zhì)量管理中的活動和任務
3.5.4  質(zhì)量管理的交付品
3.5.5  質(zhì)量管理的提示和建議
3.5.6  質(zhì)量保障過程組件
3.5.7  質(zhì)量保障中的角色
3.5.8  質(zhì)量保障中的活動和任務
3.5.9  質(zhì)量保障的交付品
3.5.10  質(zhì)量保障的提示和建議
3.5.11  質(zhì)量控制過程組件
3.5.12  質(zhì)量控制中的角色
3.5.13  質(zhì)量控制中的活動和任務
3.5.14  質(zhì)量控制中的交付品
3.5.15  質(zhì)量控制的提示和建議
3.6  文獻注解
3.7  常見問題解答（FAQs）
3.8  練習
3.9  參考資料
第4章  實施質(zhì)量軟件過程
4.1  過程的配置
4.1.1  瀑布式SDLC
4.1.2  螺旋式SDLC
4.1.3  噴泉式SDLC
4.2  迭代、漸增和并行的開發(fā)過程
4.2.1  為什么需要迭代和漸增
4.2.2  初始迭代
4.2.3  主要迭代
4.2.4  最終迭代
4.2.5  生命周期中的并行開發(fā)
4.2.6  維護和持續(xù)進行的迭代工作
4.3  軟件過程的采納
4.3.1  查清楚當前的過程狀態(tài)
4.3.2  關鍵的指導型項目
4.3.3  采納點
4.3.4  將UML從過程中剝離開來
4.3.5  保持所有的CASE工具實現(xiàn)的獨立性
4.3.6  培訓和指導
4.3.7  過程的訪問
4.4  實施質(zhì)量過程
4.4.1  在Lucky保險公司系統(tǒng)開發(fā)中創(chuàng)建迭代和漸增階段
4.4.2  迭代式的項目任務計劃
4.4.3  迭代式的項目管理工具
4.5  貫穿過程始終的質(zhì)量跟蹤
4.5.1  過程實施中的路線因素的重要性
4.5.2  初始迭代結束時的質(zhì)量活動
4.5.3  主要迭代結束時的質(zhì)量活動
4.5.4  最終迭代結束時的質(zhì)量活動
4.6  常見問題解答(FAQs)
4.7  練習
4.8  參考資料
第5章  基于UML的項目估算和度量
5.1  軟件項目中的估算和度量
5.1.1  和質(zhì)量有關的估算
5.1.2  度量和估算
5.1.3  技術維度的度量
5.1.4  方法維度的度量
5.1.5  社會學維度的度量
5.2  項目度量和估算
5.2.1  項目大小和類型
5.2.2  項目時間、預算和人員要求
5.2.3  項目估算中的注意事項
5.3  過程的度量
5.3.1  為什么要度量過程
5.3.2  在部署工作中度量過程組件
5.3.3  實施中的過程組件度量
5.3.4  在每次迭代結束時修訂項目估算
5.4  質(zhì)量度量
5.5  度量軟件的大小
5.5.1  傳統(tǒng)的軟件度量
5.5.2  另外一些軟件度量
5.5.3  面向對象的軟件度量
5.6  UML交付品、圖表和模型的度量
5.6.1  用例和用例圖的大小和復雜性度量
5.6.2  類的大小和復雜性度量
5.6.3  組件的度量
5.6.4  測試度量指標
5.7  將度量指標和估算用于Lucky保險系統(tǒng)項目
5.7.1  考慮專門針對Lucky保險系統(tǒng)項目的度量和估算
5.7.2  實施中的項目和過程度量
5.7.3  為實施度量過程組件
5.7.4  在Lucky保險系統(tǒng)中應用過程和項目度量
5.7.5  計算Lucky保險系統(tǒng)的產(chǎn)能因子
5.7.6  基于產(chǎn)能因子對后續(xù)的迭代估算做調(diào)整
5.8  有關估算和度量的預言性陳述
5.9  文獻注解
5.10  常見問題解答（FAQs）
5.11  練習
5.12  參考文獻
第Ⅲ部分  產(chǎn)品測試：質(zhì)量控制
第6章  軟件產(chǎn)品的質(zhì)量控制
6.1  不同背景中的測試
6.2  基于UML的項目中的測試方法
6.2.1  黑盒測試
6.2.2  白盒測試
6.2.3  人工測試
6.2.4  自動測試
6.2.5  垂直測試
6.2.6  水平測試
6.2.7  等價分割方法
6.2.8  邊界值方法
6.3  測試架構
6.3.1  單元測試
6.3.2  組件測試
6.3.3  系統(tǒng)測試
6.3.4  驗收測試
6.3.5  回歸測試
6.3.6  運行測試
6.3.7  性能（壓力和容量）測試
6.3.8  安全性測試
6.3.9  可擴展性測試
6.4  測試計劃制訂
6.4.1  好的測試計劃
6.4.2  分析測試中的風險
6.4.3  測試環(huán)境
6.4.4  測試資源
6.4.5  開發(fā)環(huán)境
6.4.6  測試環(huán)境
6.4.7  測試日程
6.4.8  測試輪次
6.4.9  測試中的可復用性
6.5  測試設計
6.5.1  測試設計的說明
6.5.2  測試設計的來源
6.5.3  測試設計的格式
6.6  測試用例
6.6.1  測試用例的描述
6.6.2  測試用例的設計
6.6.3  測試用例的格式
6.6.4  測試用例示例
6.6.5  驗證測試用例
6.6.6  修改測試用例
6.7  測試執(zhí)行
6.7.1  準備工作
6.7.2  驗收標準
6.7.3  執(zhí)行測試套具
6.7.4  記錄測試結果
6.8  記錄和分析測試結果
6.8.1  軟件測試結果分類
6.8.2  記錄測試結果
6.8.3  結果分析
6.8.4  報告
6.9  文獻注解
6.10  常見問題解答(FAQs)
6.11  練習
6.12  參考文獻
縮略語和重要術語
UML輔助軟件工程工具
使用UML的過程工具
光盤內(nèi)容
后記