本周閱讀了第10～12章，進一步學習了在開發一個軟件時需要考慮並做到的幾個方面。

第10章 典型用戶和場景

作為軟件，目的是為了實現用戶的需求，所以，開發軟件最大的目的不是“軟件工程”，而是“用戶”。

1.典型用戶和典型場景

典型用戶就是互不相同的、最可能使用軟件的若幹類用戶；要作為“典型”，還要完善他們的使用訴求、習慣以及本身的軟件操作水平。以強迫我們考慮問題的時候從用戶的角度出發。

首先，定義典型用戶，從典型用戶到場景，從場景到任務，從任務到代碼。

典型用戶(Persona)的模板：

（1）名字（越自然越好）。

（2）年齡（不同年齡和收入的用戶有不同的需求）。

（3）收入。

（4）代表的用戶在市場上的比例和重要性（比例大不等同於重要性高，如付費的用戶比例較少，但是影響大，所以更重要）。

（5）使用這個軟件的典型場景。

（6）使用本軟件/服務的環境 (在辦公室/家裏/沙發/床上/公共汽車/地鐵…)。

（7）生活/工作情況。

（8）知識層次和能力（教育程度，對電腦、萬維網的熟悉程度）。

（9）用戶的動機、目的和困難（困難 = 需要解決的問題）。

（10）用戶的偏好。

有了典型用戶之後，我們還得決定每一個典型用戶的目標——他/她使用系統想要達到什麽目的（如：購物者，產品提供商，濫發廣告者……）對於每一個目標，列出達到目標所必須經歷的過程，這就是場景，也可以叫故事/Story。註意，有些場景描述了成功的結果，有些場景描述了失敗的結果。用戶和系統有成百上千種可能的交互情況，在寫場景的時候要有針對性。

2.規格說明書（spec）

規格說明書(Specification),簡稱Spec。有兩種:

a)軟件功能說明書（functional spec）：主要用來說明軟件的外部功能, 和用戶的交互情況 (把軟件當作一個黑盒子)

第一, 定義好相關的概念。

第二, 規範好一些假設 （assumptions）。

第三, 避免一些誤解， 界定一些邊界條件。

第四, 描述主流的用戶/軟件交互步驟。

第五，一些好的功能還會有副作用。我們要把這些副作用明明白白地寫出來。

第六，服務質量的說明。

b) 軟件技術說明書（technical spec）：又叫 design doc, 設計文檔, 主要用來說明軟件內部的設計 (把軟件當作一個透明的箱子)

3.功能驅動（feature driven design，FDD）的設計

將用戶需求變成團隊成員可以直接操作的開發工作

步驟：

(1)構造總體模型

(2)構造功能列表

(3)制定開發計劃

(4)功能設計階段

(5)實現具體功能

第11章 軟件設計與實現

本章主要是介紹開發的流程。

1、分析和設計方法

我們寫軟件就是要解決用戶的需求，我們需要搞清楚在“需求分析”階段、“設計與實現階段”、“測試”和“發布”階段個自該做些什麽及怎麽做。

2.圖形建模

表現實體和實體之間的關系：

思維導圖（mind map）

實體關系圖（entity relationship map）

用例圖 （Use Case Diagram，UCD )

用例圖主要有下列的元素：

參與者（Actor）: 表示參與系統運作的外部因素，例如用戶，管理員，外部模塊，設備，來自外部的信號等。 通常是一個簡筆畫的小人。

系統：通常用一個方框來表示系統的邊界。有時也可以忽略。

用例（Use Case）：表示系統和參與者交互的一次場景。它是一組動作的集成，而不是一個單獨的內部元素。

信息傳遞線：用帶箭頭的線用來表示參與者和系統通過相互發送信號或消息進行交互的關聯關系。

表達數據的流動 （Data Flow Diagram）：

當我們要關註數據在不同的實體之間依賴一定的規則流動的時候， DFD 是一個合適的工具。

表達控制流 （Flow Chart, Finite State Machine）

統一的表達方式（Unified Modeling Language, UML）

這些圖形建模方法各有特點，它們使用了不同的幾何圖形、標註規則、專有詞匯和顏色。

3、其他設計方法

在計算機軟件發展的過程中，科學家和工程師們還嘗試了很多其他方法， 它們在不同程度上解決了一些局部問題，從不同的方面推動了相關領域的發展。

形式化的方法 （Formal Method）

用無歧義的、形式化的語言描述我們要解決的問題，然後用嚴密的數學推理和變換一步一步把軟件實現出來，或者證明我們的實現的確完整和正確地解決了問題。在這個領域一個比較成熟和經過實踐考驗的方法是 Vienna Development Method （VDM）。

文學化編程 （Literate Programming）

它是 “寫文檔，時不時有些代碼”。 它使用了宏（Macro）來進行抽象和信息隱藏。 通過工具的支持，它的源代碼可以提取出讓計算機編譯執行的部分（叫 Tangle），以及文檔（叫 Weave）。

第12章 用戶體驗

講“用戶體驗”，其實就是為了能夠讓開發者能夠在“think on customers feet”與"think by themself"之間自如切換——體驗軟件的時候站在用戶角度，設計這些體驗的時候在設計者角度

計算機軟件的用戶界面（user interface，UI）&用戶體驗（user experience，UX）

無論軟件還是硬件,都有很多功能，各個部件還要有機地結合起來，才能夠滿足用戶的需求

1、用戶體驗的要素

一、用戶的第一印象

如何判斷一個是不是一個好的設計？

who：目標用戶

when：他們會在什麽時候使用你的產品

where：何處使用

why：為什麽要使用你的產品【個人認為這個問題很致命】

how：如何使用

2.從用戶的角度考慮問題

從用戶的角度考慮問題

用戶需要幫助，但是用戶沒有那麽笨

光吃狗食也不夠。dogfood的傳統可以幫助發現問題（自己使用自己開發的軟件）

3.軟件服務始終都要記住用戶的選擇

長期使用之後，軟件會變得好用嗎?

4.短期刺激和長期影響

在測試中，測試人員受到的大多數是短期刺激；而客戶在實際使用的時候受到的是長期影響（比如，一個飲料喝上一瓶和喝上5瓶是一樣的感受嗎？）

5.不讓用戶犯簡單的錯誤

界面設計上，比如把“submit”和“cancel”設計的距離很近，這樣用戶手一抖就會點錯

6.用戶體驗和質量

7.情感設計

二、用戶體驗設計的步驟和目標

1.用戶體驗的評價標準

盡快提供可感觸的反饋。

系統界面符合用戶的現實慣例。

(主要指的是使用用戶語言而不是開發者語言，讓用戶能理解。

用戶有控制權。

一致性和標準化

適合各種類型的用戶

幫助用戶識別，診斷並修復錯誤

有必要的提示和幫助文檔

[註] 如何評估用戶界面? 可以參考 Nielsen的啟發式十條原則：

01 可視性原則

系統狀態有反饋，等待時間要合適

02 系統界面符合現實慣例

使用用戶語言而不是開發者語言，貼近生活實際而不是學術概念或開發者的概念。

03 用戶有自由控制權

操作失誤可回退

04 一致性和標準化

同一事物和同類操作的表示用語要各處保持一致

05 預防用戶出錯

關鍵操作有確認提示，及早消除誤操作

06 減少記憶負擔

識別勝於回憶，提供必要的信息提示（可視&易取），減少記憶負擔

07 使用效率和靈活性

為新手和專家設計定制化的操作方式，快捷操作可調整。

08 易讀性

減少無關信息，體現簡潔美感

09 幫助用戶識別，診斷並修復錯誤

給用戶明確的錯誤信息，並協助用戶方便的從錯誤中恢復工作

10 提示和幫助文檔

無需文檔就能流暢應用當然更好，一般地文檔很必要，而且也提供便利的檢索功能，從用戶的角度出發描述具體步驟，並且不要太冗長。

《構建之法》（五）