內容簡介

本書由IT專傢親筆撰寫，詳細講解瞭情境驅動設計。全書共三部分，13章。第壹部分（第1-4章）引齣瞭情境驅動設計及設計的體係，以及這種設計方式與現有的設計方法的異同；第二部分（第5-11章）詳細講解瞭應用程序的設計，如何設計需求，如何確保應用程序與其他程序及數據庫協同動作，用戶界麵的設計與易用性，數據庫設計，以及技術設計的原則與結構；第三部分（第12-13章）是本書的收尾部分，其中第12章講解瞭程序設計中的安全問題，第13章總結瞭前麵各章的重點，並展望瞭應用程序開發的趨勢。

目錄

Designing the Requirements: Building Applications that the User Wants and Needs
齣版者的話
譯者序
前言
第1章　情境驅動設計入門1
1.1　對需求進行設計1
1.2　什麼是設計7
1.2.1　專項的設計9
1.2.2　有計劃的設計10
1.2.3　工程化的設計11
1.2.4　設計方法小結13
1.3　像工程學那樣來開發IT應用程序14
1.4　重視IT架構14
1.5　小結15
第2章　設計體係16
2.1　為什麼應該建立設計體係16
2.2　情境設計19
2.2.1　任務19
2.2.2　用戶組21
2.2.3　數據錶21
2.2.4　任務之間的消息21
2.2.5　任務之間的依賴關係22
2.2.6　把所有元素統閤起來23
2.2.7　對情境設計做分析24
2.3　集成設計25
2.4　技術設計29
2.5　用戶界麵設計31
2.6　數據庫設計32
2.7　實現33
2.8　這樣做真的是工程化的設計嗎34
2.9　小結37
第3章　復用現有的方法及做法38
3.1　敏捷38
3.1.1　個體與交互勝過流程與工具39
3.1.2　可行的軟件勝過繁雜的文檔40
3.1.3　客戶協作勝過閤同談判41
3.1.4　響應變化勝過遵循計劃42
3.1.5　小結43
3.2　逆嚮設計43
3.3　用例45
3.3.1　原子性45
3.3.2　設計層次不明確46
3.3.3　用例本身比較模糊47
3.3.4　大型的用例文檔難以理解48
3.3.5　用例對工程化的設計起不到幫助作用48
3.3.6　小結49
3.4　成本估算問題49
3.5　BDUF為什麼如此笨重52
3.6　迭代53
3.7　品質54
3.8　測試與檢驗55
3.9　把現有的做法運用到情境驅動設計之中56
3.10　學習型的組織57
3.11　小結58
第4章　大型應用程序所麵臨的問題60
4.1　應用程序的大小體現在多個維度上61
4.2　大型項目所麵臨的問題63
4.2.1　需求問題64
4.2.2　缺乏終端用戶的支持65
4.2.3　技術設計有問題67
4.2.4　采購與外包69
4.3　能夠避免大型的項目嗎72
4.4　小結75
第5章　應用程序與業務的關係76
5.1　理解業務流程76
5.2　不能錶示為流程的應該怎麼辦80
5.2.1　業務服務81
5.2.2　資源管理81
5.2.3　評審與監測82
5.3　用更廣闊的視角來觀察83
5.4　將商業策略運用到應用程序的開發中85
5.4.1　開發速度85
5.4.2　在成本、性能、可用性之間權衡86
5.4.3　試驗性的商業計劃86
5.4.4　利益要等多久纔能變現86
5.4.5　安全需求86
5.4.6　針對現有的企業文化來做設計86
5.4.7　為公司所追求的文化氣氛而做設計87
5.4.8　為計劃的變更留齣餘地87
5.4.9　為打造學習型的組織提供支持88
5.4.10　非商務型的應用程序88
5.5　分析88
5.5.1　流程的格式是否正確88
5.5.2　對依賴關係進行分析89
5.5.3　目標分析91
5.6　小結92
第6章　應用程序與用戶的關係93
6.1　添加詳情93
6.1.1　任務細節94
6.1.2　任務片段97
6.1.3　共同目標組98
6.1.4　數據錶98
6.1.5　消息99
6.1.6　非功能型的需求100
6.1.7　使用情境設計的人101
6.2　確定各類用戶102
6.2.1　辦理業務流程的用戶103
6.2.2　對工作進行監控的管理型用戶103
6.2.3　使用本程序數據的其他應用程序的用戶106
6.2.4　執行數據分析的用戶107
6.2.5　執行應用程序管理工作的用戶108
6.3　對情境設計進行分析109
6.3.1　流程層麵的分析109
6.3.2　任務細節分析110
6.3.3　數據錶詳情分析111
6.3.4　用戶組詳情分析112
6.3.5　消息詳情分析112
6.4　對情境設計進行評審112
6.5　小結114
第7章　應用程序與其他IT項目的關係115
7.1　集成設計116
7.1.1　應用程序116
7.1.2　服務117
7.1.3　數據庫119
7.2　服務接口設計122
7.2.1　定義服務接口123
7.2.2　設計可復用的服務127
7.3　現有的應用程序128
7.3.1　確定現有的應用程序128
7.3.2　替換現有的應用程序130
7.3.3　用現有的應用程序來製作服務133
7.4　迴顧設計流程134
7.5　小結135
第8章　用戶界麵設計與易用性137
8.1　邏輯用戶界麵138
8.2　把任務描述轉化為單擊操作141
8.3　易用性145
8.3.1　功能146
8.3.2　信息147
8.3.3　導航147
8.3.4　文本148
8.3.5　幫助148
8.3.6　直觀而親切的應用程序149
8.3.7　針對易用性進行設計150
8.3.8　監測易用性152
8.4　事務與任務完整性152
8.5　用戶界麵設計與其他細節設計之間的關係155
8.6　小結155
第9章　數據庫設計157
9.1　數據庫設計157
9.2　數據庫設計理論163
9.3　程序員與數據庫設計者之間的關係170
9.4　數據訪問服務172
9.5　NoSQL173
9.6　小結177
第10章　技術設計的原則178
10.1　單服務器環境下的高性能原則178
10.1.1　緩存179
10.1.2　多綫程與多元處理181
10.2　多服務器環境下的高性能原則184
10.2.1　前端並行184
10.2.2　後端並行187
10.3　高彈性原則190
10.4　測試與性能評估的必要性192
10.5　技術設計的流程193
10.6　小結196
第11章　技術設計的結構197
11.1　程序結構197
11.2　什麼是框架201
11.3　各種編程語言203
11.4　選擇編程語言及框架207
11.4.1　選擇與公司的技能組閤

前言/序言

　　前言DesigningtheRequirements:BuildingApplicationsthattheUserWantsandNeeds在對IT應用程序開發思考瞭大約15年之後，我終於寫齣瞭這本書。20世紀90年代後期，我開始做IT架構，當時寫瞭一本名叫《ITArchitectureandMiddleware:StrategiesforBuildingLarge,ScalableSystems》的書（那本書的第2版是與PeterBye閤寫的，於2004年齣版，現在還可以買到）。那本書講的是構建集成應用程序（integratedapplication）所需的技術，以及怎樣確保應用程序的可擴展性、高可用性以及安全性。那時還有其他一些人也持有類似想法，由於我們的基本思路是嚮開發者提供一些可復用的服務，使其能夠通過集成技術來迅速拼裝應用程序，因此，業界把Peter與我所提齣的那種解決方案稱為麵嚮服務的架構（ServiceOrientedArchitecture，SOA）。SOA顯然有很多優勢，但實際上並沒有發揮太大作用，因為其中好像缺瞭點什麼。我從一開始就懷疑，缺少的那個東西，應該是應用程序的開發。換句話說，我們沒辦法很好地迴答“怎樣開發SOA應用程序”這個問題。此問題也可以錶述為：“有人嚮我提齣瞭一些要求，我該怎樣確保最後得到的是一套SOA解決方案，而不是一個單獨的應用程序呢？”接下來的幾年裏，我對於架構問題想得少瞭一些，而對應用程序的開發問題，則想得比較多。

　　我剛開始編寫應用程序，是在20世紀70年代後期。從那以後，我主要是在係統與環境軟件的領域中進行bug修復及設計工作，我花瞭很多時間去修整數據管理軟件，偶爾也會修復幾個編譯器或操作係統的bug。在這個過程中，我對係統軟件的設計與編程有所接觸。其後，我開始從事數據庫和資源庫的設計工作（對於版本控製問題，我有很多話要講，但奇怪的是，沒幾個人願意聽）。到2000年的時候，我對計算機技術的很多方麵都已經有瞭一些經驗，但由於自己並沒有直接從事大量的應用程序設計與編程工作，因此我還無法坦然地走到應用程序開發者麵前，指齣他們的做法是徹底錯誤的。

　　那時的程序開發專傢對架構並沒有多少興趣，而是在開發方法上麵彼此較勁。有些人崇尚BDUF（bigdesignupfront，大設計先行），他們提倡根據UML（UnifiedModelingLanguage，統一建模語言）來做設計，提倡要安排好設計的結構，要用良好的文檔描述這套設計，並且要在質量控製流程的監督之下完成整個設計。還有一些人崇尚敏捷（agile），他們認為應該盡快交付軟件，然後通過一係列短期的迭代來對軟件進行完善，使其滿足利益相關者的需求。這兩派的關鍵分歧，在於開發者與利益相關者之間究竟是什麼關係。BDUF派認為兩者是契約關係，認為軟件開發項目應該有一個正規的需求收集環節，而敏捷派則認為應該把軟件的功能分成小塊，隻有在準備實現某個小塊的時候，纔需要去製定詳細的需求，而且認為應該在當前這一小塊完工之後，就盡快把可用的軟件拿給利益相關者去看。他們希望能夠從利益相關者那裏不斷地獲得反饋意見，並據此對軟件開發的走嚮持續進行微調，以便最終實現齣正確的産品。筆者試著把這種敏捷開發方法講給IT領域之外的人聽，那些人覺得這不太可靠，然而敏捷派對BDUF派的批評，則確實引起瞭共鳴。因為利益相關者在沒有看到實際運行的軟件之前，確實不太瞭解他們當時提齣的那個程序到底會做成什麼樣。閤約並沒有一種神奇的能力，可以保證做齣來的IT程序一定會討人喜歡。

　　這兩派都不能夠讓人瞭解SOA究竟為什麼開發不齣來。對於他們來說，這個問題似乎並不存在。

　　那麼，應用程序的開發為什麼會背離SOA呢？一個原因在於，很多IT項目無法在預算之內準時交工，而且也拿不齣利益相關者想要的産品。這就給IT開發者造成瞭壓力，而IT開發者在壓力之下的一個反應，則是嚴格劃定項目的範圍。他們想要控製項目範圍之內的所有事務，同時對範圍之外的事情不聞不問。這種應用程序開發項目所實現齣來的成果，是一個單獨的應用程序。如果隻做一個大項目，那就會得到一個大程序，如果分成很多小項目來做，那就會得到很多小程序。此外，由於大型IT項目特彆容易失敗，因此開發者總是願意把大項目分成多個小項目，從而做齣很多小的程序，而不是隻做齣一個大的程序。但是另一方麵，IT架構師卻總想勸說程序開發者不要去構建單獨的應用程序，而是應該構建一些服務，並且構建必要的機製，使這些服務能夠閤起來滿足項目的需求。架構師的這種想法，當時並沒有實現。在21世紀初，筆者開始認真地觀察應用程序的開發過程，這一觀察我纔發現，原來內嚮的開發項目會做到如此令人震驚的地步：就連程序員和數據庫設計者之間的關係都相當緊張。程序員對當前項目的目標太過專注瞭，他們沒心思去想這些數據應該如何在各種組織之間分享並管理。

　　於是，筆者打算對應用程序的開發做齣第一個變革，我要找齣一種對架構有利的方式，使得每個應用程序都能對整體的架構起到推進作用，而不是破壞作用。

　　如果項目變得內嚮，那麼其中一個原因就是需求變得內嚮，換句話說，這是因為開發者隻關注某

書不錯，買來學習一下需求分析。

書本不錯，買來主要是抽空閱讀。希望有所提高。

豁然開朗

六一八搞活動買的，書便宜還是挺劃算的。

豁然開朗

需要的書籍，閱讀中

需要的書籍，閱讀中

好東西，京東自營，就是靠譜，就是快

好書