https://yqfile.alicdn.com/6ec696e3acab5ead903c7f9a25ac9ef090aeb814.png
" >
前 言
designing the requirements: building applications that the user wants and needs
在對it應用程式開發思考了大約15年之後，我終于寫出了這本書。20世紀90年代後期，我開始做it架構，當時寫了一本名叫《it architecture and middleware: strategies for building large, scalable systems》的書（那本書的第2版是與peter bye合寫的，于2004年出版，現在還可以買到）。那本書講的是建構內建應用程式（integrated application）所需的技術，以及怎樣確定應用程式的可擴充性、高可用性以及安全性。那時還有其他一些人也持有類似想法，由于我們的基本思路是向開發者提供一些可複用的服務，使其能夠通過內建技術來迅速拼裝應用程式，是以，業界把peter與我所提出的那種解決方案稱為面向服務的架構（service oriented architecture，soa）。soa顯然有很多優勢，但實際上并沒有發揮太大作用，因為其中好像缺了點什麼。我從一開始就懷疑，缺少的那個東西，應該是應用程式的開發。換句話說，我們沒辦法很好地回答“怎樣開發soa應用程式”這個問題。此問題也可以表述為：“有人向我提出了一些要求，我該怎樣確定最後得到的是一套soa解決方案，而不是一個單獨的應用程式呢？”接下來的幾年裡，我對于架構問題想得少了一些，而對應用程式的開發問題，則想得比較多。
我剛開始編寫應用程式，是在20世紀70年代後期。從那以後，我主要是在系統與環境軟體的領域中進行bug修複及設計工作，我花了很多時間去修整資料管理軟體，偶爾也會修複幾個編譯器或作業系統的bug。在這個過程中，我對系統軟體的設計與程式設計有所接觸。其後，我開始從事資料庫和資源庫的設計工作（對于版本控制問題，我有很多話要講，但奇怪的是，沒幾個人願意聽）。到2000年的時候，我對計算機技術的很多方面都已經有了一些經驗，但由于自己并沒有直接從事大量的應用程式設計與程式設計工作，是以我還無法坦然地走到應用程式開發者面前，指出他們的做法是徹底錯誤的。
那時的程式開發專家對架構并沒有多少興趣，而是在開發方法上面彼此較勁。有些人崇尚bduf（big design up front，大設計先行），他們提倡根據uml（unified modeling language，統一模組化語言）來做設計，提倡要安排好設計的結構，要用良好的文檔描述這套設計，并且要在品質控制流程的監督之下完成整個設計。還有一些人崇尚靈活（agile），他們認為應該盡快傳遞軟體，然後通過一系列短期的疊代來對軟體進行完善，使其滿足利益相關者的需求。這兩派的關鍵分歧，在于開發者與利益相關者之間究竟是什麼關系。bduf派認為兩者是契約關系，認為軟體開發項目應該有一個正規的需求收集環節，而靈活派則認為應該把軟體的功能分成小塊，隻有在準備實作某個小塊的時候，才需要去制定詳細的需求，而且認為應該在目前這一小塊完工之後，就盡快把可用的軟體拿給利益相關者去看。他們希望能夠從利益相關者那裡不斷地獲得回報意見，并據此對軟體開發的走向持續進行微調，以便最終實作出正确的産品。筆者試着把這種靈活開發方法講給it領域之外的人聽，那些人覺得這不太可靠，然而靈活派對bduf派的批評，則确實引起了共鳴。因為利益相關者在沒有看到實際運作的軟體之前，确實不太了解他們當時提出的那個程式到底會做成什麼樣。合約并沒有一種神奇的能力，可以保證做出來的it程式一定會讨人喜歡。
前言
[第1章 情境驅動設計入門
[1.2 什麼是設計
1.2.1 專項的設計
1.2.2 有計劃的設計
1.2.3 工程化的設計
<a href="https://yq.aliyun.com/articles/109076">1.3 像工程學那樣來開發it應用程式</a>
<a href="https://yq.aliyun.com/articles/109078">1.4 重視it架構</a>
<a href="https://yq.aliyun.com/articles/109081">1.5 小結</a>
[第2章 設計體系
[2.2 情境設計
2.2.1 任務
2.2.2 使用者組
2.2.3 資料表
2.2.4 任務之間的消息
2.2.5 任務之間的依賴關系
2.2.6 把所有元素統合起來
<a href="https://yq.aliyun.com/articles/109302">2.3 內建設計</a>
<a href="https://yq.aliyun.com/articles/109305">2.4 技術設計</a>
<a href="https://yq.aliyun.com/articles/109307">2.5 使用者界面設計</a>
<a href="https://yq.aliyun.com/articles/109310">2.6 資料庫設計</a>
<a href="https://yq.aliyun.com/articles/109313">2.7 實作</a>
<a href="https://yq.aliyun.com/articles/109316">2.8 這樣做真的是工程化的設計嗎</a>
<a href="https://yq.aliyun.com/articles/109317">2.9 小結</a>
[第3章 複用現有的方法及做法
3.1 靈活
3.1.1 個體與互動勝過流程與工具
3.1.2 可行的軟體勝過繁雜的文檔
3.1.3 客戶協作勝過合同談判
3.1.4 響應變化勝過遵循計劃
<a href="https://yq.aliyun.com/articles/109323">3.2 逆向設計</a>
[3.3 用例
3.3.1 原子性
3.3.2 設計層次不明确
3.3.3 用例本身比較模糊
3.3.4 大型的用例文檔難以了解
3.3.5 用例對工程化的設計起不到幫助作用
<a href="https://yq.aliyun.com/articles/109328">3.4 成本估算問題</a>
<a href="https://yq.aliyun.com/articles/109331">3.5 bduf為什麼如此笨重</a>
<a href="https://yq.aliyun.com/articles/109334">3.6 疊代</a>
<a href="https://yq.aliyun.com/articles/109336">3.7 品質</a>
<a href="https://yq.aliyun.com/articles/109340">3.8 測試與檢驗</a>
<a href="https://yq.aliyun.com/articles/109345">3.9 把現有的做法運用到情境驅動設計之中</a>
<a href="https://yq.aliyun.com/articles/109347">3.10 學習型的組織</a>
<a href="https://yq.aliyun.com/articles/109352">3.11 小結</a>
第4章 大型應用程式所面臨的問題
4.1 應用程式的大小展現在多個次元上
4.2 大型項目所面臨的問題
4.2.1 需求問題
4.2.2 缺乏終端使用者的支援
4.2.3 技術設計有問題
4.2.4 采購與外包
4.3 能夠避免大型的項目嗎
4.4 小結
第5章 應用程式與業務的關系
5.1 了解業務流程
5.2 不能表示為流程的應該怎麼辦
5.2.1 業務服務
5.2.2 資源管理
5.2.3 評審與監測
5.3 用更廣闊的視角來觀察
5.4 将商業政策運用到應用程式的開發中
5.4.1 開發速度
5.4.2 在成本、性能、可用性之間權衡
5.4.3 試驗性的商業計劃
5.4.4 利益要等多久才能變現
5.4.5 安全需求
5.4.6 針對現有的企業文化來做設計
5.4.7 為公司所追求的文化氣氛而做設計
5.4.8 為計劃的變更留出餘地
5.4.9 為打造學習型的組織提供支援
5.4.10 非商務型的應用程式
5.5 分析
5.5.1 流程的格式是否正确
5.5.2 對依賴關系進行分析
5.5.3 目标分析
5.6 小結
第6章 應用程式與使用者的關系
6.1 添加詳情
6.1.1 任務細節
6.1.2 任務片段
6.1.3 共同目标組
6.1.4 資料表
6.1.5 消息
6.1.6 非功能型的需求
6.1.7 使用情境設計的人
6.2 确定各類使用者
6.2.1 辦理業務流程的使用者
6.2.2 對工作進行監控的管理型使用者
6.2.3 使用本程式資料的其他應用程式的使用者
6.2.4 執行資料分析的使用者
6.2.5 執行應用程式管理工作的使用者
6.3 對情境設計進行分析
6.3.1 流程層面的分析
6.3.2 任務細節分析
6.3.3 資料表詳情分析
6.3.4 使用者組詳情分析
6.3.5 消息詳情分析
6.4 對情境設計進行評審
6.5 小結
第7章 應用程式與其他it項目的關系
7.1 內建設計
7.1.1 應用程式
7.1.2 服務
7.1.3 資料庫
7.2 服務接口設計
7.2.1 定義服務接口
7.2.2 設計可複用的服務
7.3 現有的應用程式
7.3.1 确定現有的應用程式
7.3.2 替換現有的應用程式
7.3.3 用現有的應用程式來制作服務
7.4 回顧設計流程
7.5 小結
第8章 使用者界面設計與易用性
8.1 邏輯使用者界面
8.2 把任務描述轉化為單擊操作
8.3 易用性
8.3.1 功能
8.3.2 資訊
8.3.3 導航
8.3.4 文本
8.3.5 幫助
8.3.6 直覺而親切的應用程式
8.3.7 針對易用性進行設計
8.3.8 監測易用性
8.4 事務與任務完整性
8.5 使用者界面設計與其他細節設計之間的關系
8.6 小結
第9章 資料庫設計
9.1 資料庫設計
9.2 資料庫設計理論
9.3 程式員與資料庫設計者之間的關系
9.4 資料通路服務
9.5 nosql
9.6 小結
第10章 技術設計的原則
10.1 單伺服器環境下的高性能原則
10.1.1 緩存
10.1.2 多線程與多元處理
10.2 多伺服器環境下的高性能原則
10.2.1 前端并行
10.2.2 後端并行
10.3 高彈性原則
10.4 測試與性能評估的必要性
10.5 技術設計的流程
10.6 小結
第11章 技術設計的結構
11.1 程式結構
11.2 什麼是架構
11.3 各種程式設計語言
11.4 選擇程式設計語言及架構
11.4.1 選擇與公司的技能組合相比對的語言
11.4.2 選擇可以滿足應用程式性能目标的語言
11.4.3 選擇可以滿足內建需求的語言
11.4.4 如果需要進行小組合作，請選擇有利于小組合作的語言
11.4.5 在選擇程式設計語言的同時，選擇相應的版本控制軟體及項目管理軟體
11.4.6 選擇與自己的開發方法相協調的語言
11.5 對架構進行擴充
11.6 實作通用的功能
11.7 小結
第12章 安全設計
12.1 it應用程式的安全原則
12.1.1 認證
12.1.2 通路控制
12.1.3 使用者管理
12.1.4 安全保護
12.1.5 安全監控
12.2 每一種設計之中的安全因素
12.2.1 情境設計
12.2.2 內建設計
12.2.3 使用者界面設計
12.2.4 資料庫設計
12.2.5 技術設計
12.3 安全程式設計
12.4 小結
第13章 應用程式開發展望
13.1 情境驅動設計如何改變應用程式開發
13.2 情境驅動設計的機遇
13.2.1 新工具
13.2.2 情境設計與驅動設計
13.2.3 使用者界面設計與資料庫設計
13.2.4 技術設計
13.3 應用程式開發所面對的挑戰
13.3.1 靈活性
13.3.2 營運
13.3.3 正确性
13.3.4 品質
13.3.5 職業精神
13.4 小結
附錄a 情境設計核對表
參考資料