全面講解如何構建穩定可靠的軟件
《軟件工程入門經典》揭秘專業開發人員為設計和構建穩定、可靠、高效軟件所運用的軟件工程技術和方法。本書通俗易懂，在大量案例的引導下，演示適用于任何編程語言的重要概念和技術；即使你目前不具有編程、開發和管理經驗，同樣可以閱讀和學習本書。每章末尾附有精選習題，以測試你對知識的理解程度，引導你悟透主要概念。本書全面介紹了瀑布、生魚片、敏捷、RAD、Scrum、看板和極限編程等各種開發方法所涉及的基本任務。
主要內容
◆詳述軟件工程概念
◆闡釋參與軟件工程項目的團隊成員的角色和職責
◆指出軟件工程項目都必須經歷哪些重要階段才能開發出功能卓越的可靠應用程序
◆詳述主流軟件開發方法及其處理重要開發任務的不同方式
◆提供從每章主要知識點引申的習題
◆附有詳明的軟件工程術語表
◆詳述軟件工程概念
◆闡釋參與軟件工程項目的團隊成員的角色和職責
◆指出軟件工程項目都必須經歷哪些重要階段才能開發出功能卓越的可靠應用程序
◆詳述主流軟件開發方法及其處理重要開發任務的不同方式
◆提供從每章主要知識點引申的習題
◆附有詳明的軟件工程術語表
前 言
如今的編程是“程序員正努力創建一個更大更傻的程序”和“世界在嘗試創造更多更傻的人”之間的一種角逐。到目前為止，后者是贏家。
——Rick Cook
借助一些現代開發工具，不需要事先設計和計劃，坐在鍵盤旁就可以敲打出一個可以工作的程序。某些情況下，這還是可行的。我的VB Helper(www.vb-helper.com)和C# Helper(www. csharphelper.com)站點就包含了數以千計的Visual Basic和C#示例程序——這些程序正是通過這樣的方法進行創建的。每當我有一個想法(或是別人向我提出一個問題時)，我都會敲擊出一個簡單示例程序。
如果只有你自己使用而且只是短期使用這些程序，那么還好。如果只用于實驗，演示一些編程技巧，那么也還好。
如果是將這種草率粗糙的程序用于生產，其結果將是災難性的。即便作最樂觀的估計，使用這些程序的非編程員也將很快束手無策。最糟的情況下，它們可以破壞計算機，甚至嚴重影響你和朋友、同事之間的關系。
即使經驗最豐富的開發人員有時也會被這種不靠譜的程序弄得焦頭爛額。我知道有人(我不想指名道姓，但我絕不會干這種事情)編寫一些簡單的遞歸腳本來刪除某個目錄層次中的文件。遺憾的是，這樣的腳本將以遞歸方式爬行到目錄樹頂部，然后幸災樂禍地刪除系統中的每個文件。這種腳本在停止前僅運行大約5秒鐘，但它已經破壞了足夠多的文件，從而導致必須重新安裝操作系統(實際上，一些開發人員認為每隔一年左右重裝一次操作系統是在鍛煉意志力。如果認同這樣的看法，不妨嘗試一下)。
我還認識一位經驗豐富的開發人員。她在測試Windows系統設置時，曾設法把每種系統顏色都設置為黑色，結果卻導致黑色光標懸停在黑色的桌面上，顯示的是帶有黑色邊框、菜單以及文本的黑色窗口。此人(不是我)最終通過重啟的方式，通過另一臺色彩正常的計算機，僅通過鍵盤快捷鍵修復了顏色設置。這確實是明智的勝利，但我懷疑她寧愿沒有發生這件事，也不情愿白白浪費兩天的時間。
對于那些代碼量比較大或者是面向可信賴終端用戶的程序而言，這種自由散漫的開發方式并不適用。為編寫出安全、有效、可靠的應用程序，不能只坐下來敲敲鍵盤。你需要“軟件工程”。
本書主要介紹軟件工程。它將向我們闡釋軟件工程是什么以及如何借助它創建高效、靈活、健壯的應用程序。
本書不能使你成為專家級的系統分析師、軟件架構師、項目經理或程序員，卻向我們闡釋了這些人做什么，以及對于高質量的軟件開發而言，他們為什么是不可或缺的。本書介紹了一些入門級工具。你不用一個人去“戰斗”，或是帶領1000人給FAA開發一個航空交通管制系統，但它的確有助于在不同規模的開發項目中高效工作(當你的老板意味深長地說“是啊，我們主要使用的是深度結合了XP技術的敏捷開發”時，它也有助于你悟透這句話中的“玄機”)。
軟件工程的概念
軟件工程的比較正式的一個概念可能為：“設計、開發、使用、維護軟件的結構化分析方法。”
更直觀地講，軟件工程是成功的軟件開發所需要的一切，它包含將可能模糊不清、不成熟的想法轉變成為一個強大、直觀的應用程序需要的所有步驟，從而能夠更好地滿足用戶未來日益變化的需求。
當設計應用程序時，可能僅把軟件工程視為上述過程的開始部分。畢竟，一個航空工程師只是設計飛機但不建造它們，或者是當第一個客艙滿員后再添加一個(盡管這里我設想的是使用背負在747這類飛機上的航天飛機來達到上述目的)。
軟件工程和航天工程(或者是其他類型的工程)一個很大的區別在于：軟件不是物理的。它只存在于計算機虛擬的世界里。這意味著很容易就能對程序的任何部分進行修改，即使是在它徹底完成的情況下。相比之下，如果是等到一座橋梁建造完成后，才告訴結構工程師你決定另外添加兩個車道。他肯定會喋喋不休地提供各種富有創意但脫離實際的建議。
軟件的虛擬特性所帶來的靈活性是一把雙刃劍。有利之處是：能夠在開發的過程中精益求精，從而更好地滿足用戶的需求，如增加新特性、充分利用實現過程中所發現的一切有利之機、修改以適應不斷變化的業務需求，甚至允許一些應用程序讓用戶自己編寫腳本，執行連開發人員都意想不到的新任務。對于其他類型的工程而言，這種靈活性是不可能達到的。
遺憾的是：這種允許在軟件項目生命周期中進行修改的靈活性，也能夠在開發過程中的任何一點上把事情弄糟。增加一個新特性可能中斷現有的代碼，或者是把一個簡潔、優雅的設計變成一個無法收拾的亂攤子。在開發過程中，不停地添加、刪除以及修改一些功能也使得系統的不同部分不能夠協調一致的工作。一些情況下，甚至不可能知道軟件的具體完成時間。
由于軟件具有很好的可拓展性，因此直到項目結束的任何一點上，都可以進行設計決策。事實上，在最初的發行后，成功的應用程序通常會繼續演化很長時間。例如，微軟的Word已經演化了近30年的時間(有時會變得很好，有時則很糟。還記得微軟辦公系統中的那個大眼回形針助手嗎？它是變得更好還是更糟呢？反正我是有一段時間沒看見它了)。
隨時都可以進行修改的事實，意味著需要把整個開發過程視為單一、長期的復雜任務。不能只“策劃”一個宏偉的設計，讓程序員不辭辛苦地完成所有任務。最宏觀的那些設計決策可以提前制定，軟件開發當然要分階段，但是這些階段要相互銜接，要通盤考慮。
軟件工程之所以重要的原因
軟件開發在概念上相對比較簡單：有一個想法，然后將這個想法變成有用的程序。遺憾的是，對于具體的項目而言，一個簡單概念有無數種出錯的方式。程序員可能并不了解客戶的所想和所需，因此他們創建了錯誤的應用程序，其中充滿bug，使用起來令人沮喪，無法修改，也不能進一步完善。這樣的程序可能十分高效，但讓人迷惑不解，以至于需要解謎的博士學位才能使用它。一個絕對完美的應用程序甚至可能被內部業務策略或市場規律所扼殺。
軟件工程包含了很多可以用來避免陷阱的技術。否則，這些陷阱可能在將來的某個時候葬送你的項目。它能夠確保你的應用程序有效、可用、可維護。它有助于按照計劃完成整個項目各主要階段的任務，并且確保在預算內如期完成整個項目。也許最重要的是：軟件工程的這種靈活性，可以讓我們在沒有完全變更計劃和預算的前提下，對軟件進行修改，以滿足一些非預期的需求。
簡言之，軟件工程有助于控制軟件開發過程中所出現的一些意料不到的看似混亂不堪的局面。
本書讀者對象
參與軟件開發工作的每個人都應該對軟件工程有一個基本的了解，無論是確定軟件用途和功能的執行客戶(executive customer)，還是最后使用應用程序產品(以及報告bug)的終端客戶、監督其他開發人員(不要玩太多《彩球連線》)的首席開發者，或是為每周的會議準備甜甜圈的伙計——你要知道如何整合所有的參與者。這些人中的任何失誤(特別是提供甜甜圈的人)都將影響其他人，因此每個人都知道項目正轉向災難的警告標志是至關重要的。
本書主要面向那些沒有太多經驗的軟件工程人員。它并不需要你具備軟件開發、項目管理以及編程的任何經驗(我猜測大多數讀者都有一些制作甜甜圈的經驗，但這并非必要)。
即便對這些主題有一定的認識，特別是編程方面，也可以獲益于本書。如果一直關注的只是所在項目的部分主題，為有助于引導該項目走向成功，仍需要了解這些部分之間如何相互影響。
例如，在我把開發過程作為一個整體認真看待之前，我已從事過數年的程序員工作，甚至參與了一些較大規模項目的開發工作。我知道其他人在編寫用例和部署計劃，但我只關注我的那部分工作。直到后來，我在項目中擔任了一個較高層的角色，才真正了解該項目的整個過程。
本書與如何編程無關。它主要闡釋一些可用的編程技巧，例如，如何編寫足夠靈活的代碼，以處理不可避免的軟件變更請求；如何讓代碼更易于調試(至少你的代碼將是如此)；如何讓你的代碼能夠在以后更完善和易于維護(面向更多的軟件變更請求)。所有這些都是一些概要性內容，并不需要你知道如何編程。
如果你從事的并非程序員工作，如終端用戶或項目經理，即使不直接使用它，也將發現書中的內容非常有趣。同時，你將驚奇地發現：一些技巧也適用于一些非編程問題。例如，用于生成問題解決方案的方法同樣適用于所有類型的問題，并非只有編程決策(也可以這樣問開發人員：“你在單元測試前使用斷點和黑盒測試嗎?”看看他們是否理解你正在談論的話題)。基本上，你正在使用黑盒測試判斷這些開發人員是否了解黑盒測試，詳見第8章“測試”。
方法
本書分為兩個部分。第Ⅰ部分主要介紹軟件開發的一些基本任務，如設計、編碼、測試。本書的第Ⅱ部分主要介紹一些常見的軟件開發模型。
然而，在能夠開始從事軟件開發項目工作之前，還是需要準備一下。為了能夠在整個項目中保持對進度的跟蹤，你需要一些工具和技術。第1章“軟件工程概覽”主要介紹這些開始前的準備活動。
完成這些前期的準備后，可用來進行軟件開發的方法有很多。所有這些方法都有一個共同的目標——開發可用的軟件，因此它們必須處理近乎相同的任務，如需求收集、制定計劃、編寫實際代碼。本書的第Ⅰ部分主要介紹這些任務。第1章主要對這些任務進行概述；第2章～第11章將詳細介紹這些任務，同時將探討如何有效完成這些任務。
本書第Ⅱ部分介紹了一些目前較流行的軟件開發方法。所有這些模型都要解決本書前面章節所介紹的相同問題，只不過方式不同。其中的一些模型側重于可預測性，以便能夠了解到底需要提供何種軟件功能以及何時提供；而其他一些模型關注的是盡快構建大多數功能，即使這意味著與最初的設計相比有一些偏差。第12章～第14章主要介紹一些最常見的軟件開發模型。
上述就是本書針對軟件工程的基本學習路線。首先，要了解完成軟件開發的一些基本任務；然后，了解處理這些任務的一些基本模型。
然而，很多人都難以適應羅列式的枯燥學習，為讓書中的內容更易于掌握，本書也包含了其他一些元素。書中每一章的后面都附有練習，它們可用來檢測對每章內容的掌握程度。我并不喜歡那些只是讓人簡單復述每章內容的練習(快速問答：軟件“縹緲不定”的性質的一些優勢和不足是什么？)，大多數練習主要用來對每章的主要內容進行拓展。在學習每一章內容之后，希望大家能夠去思考一些新的方法。
部分練習是作為某部分內容的補充材料出現的，因此和測試題相比，附錄A中的那些問題更像拓展內容和思維實驗。
強烈推薦至少瀏覽并思考一下這些問題，然后琢磨一下自己是否理解。所有答案都包含在附錄A“習題答案”中。
本書主要內容(以及非本書主要內容)
本書主要介紹軟件工程，例如，完成一個成功的軟件項目必須執行的任務，以及用來實現我們目標的一些最常見的開發模型。雖然它并未涵蓋每一個細節，但的確對整個軟件開發過程進行了詳細探討。
本書并未囊括每一個可能的軟件模型。事實上，目前軟件行業使用的開發模型有數十種(可能數百種)。本書只是對其中最常見的一些開發方法進行了簡要介紹。
如果打算深入了解某種特殊的軟件開發方法，可以求助于很多與它有關的一些書籍和網站。很多開發模型都有自己的推廣機構(都有網站)，例如www.extremeprogramming.org、agilemanifesto.org以及www.scrum.org。
本書并不是一本有關軟件開發技巧和提示的百科全書。它僅介紹了和軟件開發有關的一些常見思想和理念，旨在幫助我們輕松地開發更高效、健壯的軟件產品。本書主要探討較高層次上的軟件工程問題，所以并未囊括使程序更加完善的所有“竅門”。本書的內容并非針對某種特定的編程語言，所以也不可能使用屬于某種特定編程語言的一些工具和技巧。
需要的一些工具
閱讀本書不需要任何工具，需要的是閱讀本書的能力(還有眼鏡，或者是文本-聲音轉換工具——如果有本書的電子版；或者是讓朋友讀給你聽；好吧，我猜你有好幾種選擇)。
為了能夠真正參與到某個項目的開發中，可能需要很多工具。如果是開發小型的個人項目，則可能只需要像Visual Studio、Eclipse、RAD Studio之類的編程環境。對于比較大型的團隊開發而言，還需要項目管理、文檔(文字處理)、修改跟蹤、軟件修訂跟蹤等其他工具。當然，還需要其他開發人員的幫助。本書將對這些工具一一介紹，但閱讀本書不需要這些工具。
本書約定
為有助于更好地閱讀本書，同時跟蹤軟件工程的一些最新技術，本書使用了以下約定：
側邊欄
類似這樣的側邊欄包含有一些其他方面的信息和主題。
警告
這種類型的文本框中的內容是和其周圍文本有直接關系的重要信息。一個軟件項目有多種失敗的可能，這些信息提醒你應該避免的一些“最差實踐”。
注意
這些文本框用來表示和當前內容有關的說明、提示、建議、技巧以及旁白。
至于文本中的樣式：
● 鍵盤敲擊的顯示方式是這樣的：Ctrl+A，這意味著在按下Ctrl(Control或CTL或你鍵盤上的其他標記方式 )鍵的同時按下A鍵。
● 本書幾乎沒有實際的程序代碼，因為我并不知道你所使用的編程語言(若有的話)。如果是代碼，其顯示方式如下：
//如果a和b互質，則返回ture
private bool AreRelativelyrime(int a, int b)
{
// Only 1 and -1 are relatively prime to 0.
if (a = 0) return ((b == 1) || (b == -1));
if (b = 0) return ((a == 1) || (a == -1));
int gcd = GCD(a, b);
return ((gcd == 1)) || (gcd == -1));
}
(不必擔心不理解上述代碼，正文中有解釋)。
● 文件名稱、URL以及文本中出現的少量代碼的顯示方式是這樣的：www.csharphelper.com。
勘誤
我已竭盡全力避免書中的一些錯誤。本書的文本已經通過了一支小規模的編輯隊伍和技術審閱們的審核。然而，正向書中介紹的那樣，任何重大的項目無一例外都曾出現過錯誤。我能期望的最好的結果是：剩下的都是小錯誤，它們還不至于影響對本書文字的理解。
如果在閱讀本書的過程發現有錯誤(像是拼寫錯誤、代碼碎片或是不能理解的任何地方)，那么我將非常感激你的反饋。我將通過本書的勘誤頁面登出你的反饋，這樣有利于其他讀者更好地理解本書，同時也能幫助我進一步完善此書。
如欲查閱本書的勘誤頁面，請訪問www.wrox.com/go/beginningsoftwareengineering，然后在本書詳細信息頁面上單擊Book Errata鏈接。可以在該頁面上查看已提交的和Wrox編輯們張貼的所有勘誤信息。你也可以訪問www.wrox.com/misc‐pages/booklist.shtml，查看Wrox已出版的所有書籍列表(包含每本書的勘誤信息)。
如果沒有在Book Errata頁面發現你提交的錯誤，請訪問www.wrox.com/contact/ techsupport.shtml，并在此頁面上完成表格的填寫，提交所發現的錯誤。經過嚴格訓練的編輯們將迅速檢查此信息(通過給我發送一封電子郵件)。如果必要，那么他們將馬上在本書的勘誤頁面上張貼勘誤信息，并在本書的后續版本中修訂相應錯誤。
p2p.wrox.com
通過P2P論壇p2p.wrox.com(P2P是指“Programmer to Programmer”，但因為本書并非只針對程序員，因此這里我特意用“Person to Person”進行表示)提交反饋、咨詢和本書有關的一些問題也是不錯的方法。
這些論壇都是基于Web的系統，可以在上面張貼和Wrox書籍以及相關技術有關的一些信息，同其他讀者、技術用戶以及作者(像是我)互動。這些論壇都提供有訂閱功能。每當論壇有新帖提交時，我們選擇的感興趣的話題，將通過電子郵件的形式發送給我們。這些論壇的活躍用戶包括Wrox的作者、編輯、其他行業專家以及讀者群體。
只需要完成以下步驟，就可以加入這些論壇：
(1) 訪問 p2p.wrox.com，單擊Register鏈接；
(2) 閱讀使用說明，然后單擊Agree；
(3) 填寫一些必要信息以及你打算提供的可選信息，然后單擊 Submit；
(4) 你將收到一封有關如何驗證賬戶以及完成加入過程的電子郵件。
快來加入論壇
不需要加入P2P，就可以閱讀論壇信息。但如果要發貼，那么就必須要加入。不用擔心Wrox給你的郵箱發送垃圾郵件(至少，他們過去從未如此)。他們這樣做的目的只是為了防止一些“網絡惡魔”不會冒充你的名字發帖。
加入后，就可以發帖，回復其他讀者的帖子，并且可以在任何時間閱讀網上的信息。如果打算接收某個特殊論壇的新郵件消息，則可以通過論壇列表里的論壇名稱，單擊Subscribe to this Forum圖標。
請務必要閱讀P2P FAQ上的有關論壇軟件如何工作的問答，以及針對P2P和Wrox書籍的一些問答。閱讀這些FAQ，請單擊P2P頁面上的FAQ鏈接。
這些P2P論壇讓其他讀者能夠從你的問題及其解答中受益。我也非常關注本書的論壇，只要能夠提供幫助，就一定會予以回應。
一些重要的URL
下面列舉和本書有關的一些重要URL：
● www.wrox.com/go/beginningsoftwareengineering——本書的網頁。
● p2p.wrox.com——Wrox P2P論壇。
● www.wrox.com——Wrox的網站，包含有勘誤和其他信息。可以通過書名或ISBN檢索。
● RodStephens@CSharpHelper.com——我的電子郵件地址。讓我們保持聯系吧！
● www.CSharpHelper.com——我的C#站點，包含有數以千計的針對C#開發人員的提示、技巧以及示例。
● www.vb-helper.com——我的Visual Basic站點，包含有數以千計的針對Visual Basic開發人員的提示、技巧以及示例。
聯系作者
如果有任何問題、意見或建議，都可以給我發送電子郵件(RodStephens@CSharpHelper.com)。我不敢保證能幫助你解決每一個問題，但我承諾將盡力幫助你。
免責聲明
軟件工程并非總是最激動人心的話題，所以為了能讓讀者保持頭腦清醒并且興趣盎然，書中所選擇的一些示例都極具幽默色彩。如果你將本書置于床頭，作為失眠治療的最后一劑良藥，那么我就失敗了。
那些極具才華的軟件工程師不必閱讀本書。我并沒有不尊重他們的意思，因為要為客戶開發高質量的應用程序，他們要長期工作(至于那些缺乏才干的軟件工程師，他們也不需要閱讀本書，因為他們的失敗工作經歷比我更有說服力)。
我也無意對書中所介紹的一些開發模型“大打折扣”。每一種開發模型都來之不易，無論過去或現在，它們都將在軟件工程領域占有一席之地。
由于本書篇幅有限，一些軟件開發方法和最佳編程實踐有所遺漏在所難免，即使是書中介紹的一些方法也未能覆蓋其全貌。
如果對書中的一些內容有異議，或者打算提供某個主題更詳細的信息，抑或是介紹自己正在使用的一些軟件技術或變體，那么請加入Wrox P2P論壇，與大家一起分享。論壇上的“小伙伴們”都試圖提高自己的開發技巧，所以我們拭目以待。事實上，學習和提高開發技術是許多敏捷方法的規定要求，因此加入論壇是必需的。
所以，請戴好眼鏡，喝一杯含咖啡因的飲料，準備步入軟件工程的殿堂吧！
Rod Stephens兒時夢想成為數學家，但當在麻省理工學院學習時，他發現編程非常有趣，從此便開始了專業的編程生涯。在其職業生涯中，他從事過很多不同領域的應用程序開發，如電話交換、計費、維修調度、稅務處理、污水處理、演唱會門票銷售、制圖以及專業足球運動員培訓。
十多年來，Rod 一直都是“微軟Visual Basic 有價值專家(MVP)”，曾教授過一些編程的入門課程。他撰寫過30 多本書，并且這些書籍還都被翻譯成不同的語言。他撰寫過250 多篇雜志文章，主要涉及Visual Basic、C#、Visual Basic for Applications、Delphi 以及Java。
Rod 廣受歡迎的VB Helper 站點(www.vb-helper.com)包含有數千個針對Visual Basic 程序開發人員的提示、技巧以及示例程序頁面。他的C# Helper 站點(www.csharphelper.com)包含類似的一些C#開發資源。
可以通過RodStephens@CSharpHelper.com 或RodStephens@vb-helper.com 和Rod 保持聯系。
第Ⅰ部分 進階
第1章 軟件工程概覽 3
1.1 需求收集 3
1.2 概要設計 4
1.3 詳細設計 5
1.4 開發 5
1.5 測試 6
1.6 部署 7
1.7 維護 8
1.8 總結和反思 8
1.9 一次性處理所有事項 8
1.10 本章小結 9
第2章 入手之前 13
2.1 文檔管理 13
2.2 歷史文檔 15
2.3 電子郵件 16
2.4 代碼 18
2.5 代碼文檔 18
2.6 應用程序文檔 21
2.7 本章小結 21
第3章 項目管理 25
3.1 管理支持 26
3.2 項目管理 27
3.2.1 PERT圖 28
3.2.2 關鍵路徑方法 33
3.2.3 甘特圖 35
3.2.4 軟件日程安排 36
3.2.5 估算時間 36
3.3 風險管理 41
3.4 本章小結 42
第4章 需求收集 45
4.1 需求定義 46
4.1.1 清晰 46
4.1.2 沒有歧義 46
4.1.3 一致 47
4.1.4 優先級排序 47
4.1.5 可驗證 50
4.1.6 應避免使用的詞 51
4.2 需求分類 51
4.2.1 受眾導向的需求 51
4.2.2 FURPS 54
4.2.3 FURPS+ 54
4.2.4 通用需求 56
4.3 收集需求 57
4.3.1 傾聽客戶(和用戶)的需要 57
4.3.2 使用5W(和一個H) 57
4.3.3 研究用戶 59
4.4 細化需求 60
4.4.1 復制現有系統 60
4.4.2 未卜先知 61
4.4.3 頭腦風暴 62
4.5 記錄需求 64
4.5.1 UML 64
4.5.2 用戶故事 65
4.5.3 用例 65
4.5.4 原型 66
4.5.5 需求說明 67
4.6 確認和驗證 67
4.7 更改需求 67
4.8 本章小結 68
第5章 概要設計 71
5.1 縱覽全局 72
5.2 指定的事項 73
5.2.1 安全性 73
5.2.2 硬件 74
5.2.3 用戶接口 75
5.2.4 內部接口 76
5.2.5 外部接口 76
5.2.6 架構 77
5.2.7 報表 83
5.2.8 其他輸出 83
5.2.9 數據庫 84
5.2.10 配置數據 86
5.2.11 數據流及狀態 86
5.2.12 培訓 87
5.3 UML 87
5.3.1 結構圖 88
5.3.2 行為圖 90
5.3.3 交互圖 93
5.4 本章小結 95
第6章 詳細設計 97
6.1 面向對象設計 98
6.1.1 識別類 99
6.1.2 創建繼承體系 99
6.1.3 對象組合 103
6.2 數據庫設計 104
6.2.1 關系數據庫 104
6.2.2 第一范式 106
6.2.3 第二范式 109
6.2.4 第三范式 111
6.2.5 更高級的規范化 112
6.3 本章小結 113
第7章 開發 117
7.1 使用正確的工具 118
7.1.1 硬件 118
7.1.2 網絡 119
7.1.3 開發環境 119
7.1.4 源代碼控制 120
7.1.5 分析器 120
7.1.6 靜態分析工具 120
7.1.7 測試工具 121
7.1.8 源代碼格式器 121
7.1.9 重構工具 121
7.1.10 培訓 121
7.2 選擇算法 121
7.2.1 有效果 122
7.2.2 有效率 122
7.2.3 可預測 124
7.2.4 簡潔 124
7.2.5 預包裝 125
7.3 自上而下的設計 125
7.4 編程提示和技巧 127
7.4.1 保持清醒 127
7.4.2 為人編寫代碼，并非計算機 127
7.4.3 注釋優先 128
7.4.4 編寫自文檔化的代碼 130
7.4.5 保持小巧 131
7.4.6 保持專注 132
7.4.7 避免副作用 132
7.4.8 驗證結果 133
7.4.9 實踐“進攻式”編程 135
7.4.10 使用異常 136
7.4.11 首先編寫異常處理程序 136
7.4.12 切勿重復代碼 137
7.4.13 推遲優化 137
7.5 本章小結 138
第8章 測試 141
8.1 測試的目的 142
8.2 永不消亡的bug 143
8.2.1 收益遞減 143
8.2.2 最后期限 143
8.2.3 影響 143
8.2.4 為時尚早 143
8.2.5 有用性 144
8.2.6 過時 144
8.2.7 這并非一個bug 144
8.2.8 沒有盡頭 145
8.2.9 有總比沒有好 145
8.2.10 修復 bug很危險 145
8.2.11 修復哪些bug 146
8.3 測試級別 146
8.3.1 單元測試 146
8.3.2 集成測試 148
8.3.3 自動化測試 148
8.3.4 組件接口測試 149
8.3.5 系統測試 150
8.3.6 驗收性測試 150
8.3.7 其他測試類型 151
8.4 測試技術 152
8.4.1 窮舉測試 152
8.4.2 黑盒測試 153
8.4.3 白盒測試 153
8.4.4 灰盒測試 153
8.5 測試習慣 154
8.5.1 清醒時再進行測試和調試 154
8.5.2 測試自己的代碼 154
8.5.3 讓其他人測試你的代碼 155
8.5.4 修復自己的bug 156
8.5.5 修改前請“三思” 157
8.5.6 不要相信魔法 157
8.5.7 查看改變之處 157
8.5.8 修復bug，并非癥狀 158
8.5.9 對測試用例進行測試 158
8.6 如何修復bug 158
8.7 估算bug的數量 159
8.7.1 跟蹤發現的bug 159
8.7.2 播種 160
8.7.3 林肯指數 161
8.8 本章小結 162
第9章 部署 165
9.1 范圍 166
9.2 計劃 166
9.3 切換 167
9.3.1 階段性部署 167
9.3.2 逐步切換 168
9.3.3 增量部署 169
9.3.4 并行測試 170
9.4 部署任務 170
9.5 部署錯誤 171
9.6 本章小結 172
第10章 度量 175
10.1 慶祝會 176
10.2 缺陷分析 176
10.2.1 bug的種類 176
10.2.2 石川圖 178
10.3 軟件度量 181
10.3.1 好的屬性和度量指標的一些特征 182
10.3.2 度量的用途 182
10.3.3 需要度量的對象 184
10.3.4 規模標準化 186
10.3.5 功能點標準化 188
10.4 本章小結 192
第11章 維護 195
11.1 維護成本 196
11.2 任務分類 197
11.2.1 完成性任務 197
11.2.2 適應性任務 200
11.2.3 糾正性任務 201
11.2.4 預防性任務 203
11.2.5 個別bug 207
11.2.6 “非我發明” 207
11.3 任務執行 208
11.4 本章小結 208
第Ⅱ部分 模型
第12章 預測模型 215
12.1 模型 215
12.2 預備知識 216
12.3 預測和自適應 216
12.3.1 成功和失敗的標志 217
12.3.2 利與弊 218
12.4 瀑布 219
12.5 帶有反饋的瀑布 220
12.6 生魚片 221
12.7 增量瀑布 222
12.8 V模型 224
12.9 系統開發生命周期 224
12.10 本章小結 227
第13章 迭代模型 229
13.1 迭代與預測 230
13.2 迭代與增量 231
13.3 原型 232
13.3.1 原型的類型 233
13.3.2 優缺點 234
13.4 螺旋模型 235
13.4.1 澄清 237
13.4.2 優勢和不足 238
13.5 統一過程 239
13.5.1 優勢和不足 240
13.5.2 RUP 241
13.6 潔凈室模型 241
13.7 本章小結 242
第14章 RAD 245
14.1 RAD的主要原則 246
14.2 James Martin RAD 249
14.3 敏捷開發 249
14.3.1 自組織團隊 252
14.3.2 敏捷方法 253
14.4 XP 256
14.4.1 XP的角色 257
14.4.2 XP的價值觀 257
14.4.3 XP實踐 258
14.5 Scrum 264
14.5.1 Scrum角色 264
14.5.2 Scrum沖刺 265
14.5.3 計劃撲克 266
14.5.4 燃盡圖 267
14.5.5 速率 268
14.6 精益軟件開發 268
14.7 水晶方法 269
14.7.1 透明水晶 271
14.7.2 黃色水晶 272
14.7.3 橙色水晶 272
14.8 功能驅動開發 274
14.8.1 FDD角色 274
14.8.2 FDD階段 275
14.8.3 FDD迭代里程碑 277
14.9 敏捷統一過程 278
14.10 規范敏捷交付 280
14.10.1 DAD原則 280
14.10.2 DAD角色 280
14.10.3 DAD階段 281
14.11 動態系統開發方法 282
14.11.1 DSDM階段 282
14.11.2 DSDM原則 283
14.11.3 DSDM角色 284
14.12 看板軟件開發方法 285
14.12.1 看板的一些原則 285
14.12.2 和看板有關的一些實踐 286
14.12.3 看板圖 286
14.13 本章小結 287
附錄A 習題答案 293
術語表 337
新書資訊