20171128-構建之法：現代軟件工程-閱讀筆記

第九章-項目經理

　　PM：Product Manager-產品經理，正確地作產品；

　　　　　 Project Manager-項目經理，正確地作流程；

　　　　　 Program Manager-微軟的職位名稱，負責除產品開發和測試以外的全部事情；

　　Program Manager - Project Manager:

                                     

　　Keep the Balance: Time / Resource / Feature     大部分優秀團隊：多，快，但不省；多，省，但不快；快，省，但很少；

　　PM和風險管理：

　　　　風險的類別　　　　　　　　風險的來源

　　　　　人員　　　　　　　　　　　客戶，最終用戶，利益關係人，項目成員，合做夥伴

　　　　　流程　　　　　　　　　　　項目的預算，成本，需求

　　　　　技術　　　　　　　　　　　開發和測試工具，平臺，安全性，發佈產品的技術，與咱們產品相關的技術

　　　　　環境　　　　　　　　　　　法律，法規，市場競爭環境，經濟狀況，技術大趨勢，商業模式，天然界

　　風險管理的水平層次：

　　　　第一層次：啊呀！大問題（Crisis）；

　　　　第二層次：緩和（Mitigation）並防止問題（Prevention）；

　　　　第三層次：預計（Anticipation）；

　　　　第四層次：把問題變爲機會（Opportunity）；

　　PM的能力要求和任務：

　　　　1.觀察、理解和快速學習能力；

　　　　2.分析管理能力----四種狀況：重要且緊急，重要但不緊急，不重要但緊急，不重要也不緊急；

　　　　3.必定的專業能力；

　　　　4.自省的能力；

　　PM在項目中具體任務：

　　　　1.帶領團隊造成團隊的目標/遠景，把抽象的目標轉化爲可執行的、具體的、優美的設計；

　　　　2.管理軟件的具體功能的生命週期（需求 / 設想 / 設計 / 實現 / 測試 / 修改 / 發佈 / 升級 / 遷移 / 淘汰）；

　　　　3.建立並維護軟件的規格說明書，讓它成爲開發 / 測試人員及時準確的指導，而不是障礙；

　　　　4.表明客戶和用戶的利益，主動收集用戶反饋，預期用戶新的需求。協調並決定各類需求的優先級；

　　　　5.分析並帶領其餘成員對缺陷 / 變動需求造成的一致意見，並確保實施；

　　　　6.帶領其餘成員確保項目保持功能 / 時間 / 資源的合理平衡，跟蹤項目進展，確保團隊發佈令客戶滿意的軟件；

　　　　7.收集團隊項目管理和軟件工程的各類數據，客觀分析項目實施過程當中的優缺點，推進項目成員的持續改進，從而提振士氣；

　　著名用戶體驗專家比爾·巴克斯頓在總結本身幾十年的經驗時說：

　　　　　過程創新可能超越產品創新，但兩個創新並駕齊驅則勝於任何一個；

 

第十章-典型用戶和場景

　　典型用戶（Persona）：特徵--每每描述了一組用戶的典型技巧、能力、須要、想法、工做習慣和工做環境；

　　定義典型用戶：定義用戶的角色，若用戶有不一樣的安全需求，切記要定義不一樣的角色來適應這些需求；

　　　　　　受歡迎的典型用戶----指那些按設計者的指望使用系統的用戶；

　　　　　　不受歡迎的典型用戶----指那些有不正當目的的用戶（這些用戶也許在別的系統中是受歡迎的）；

　　典型用戶的模板能夠包括：名字、年齡和收入、表明的用戶在市場上的比例和重要性（比例大不等同於重要性高）、使用這個軟件的典型場景（Scenario）、使用本軟件 / 服務的環境、生活 / 工做的狀況、知識層次和能力、用戶的動機、目的和困難、用戶的偏好； 

　　　　　　eg：咱們的軟件並非爲全部人服務的；

　　用例（Use Case）：經常使用的需求分析工具；

　　　　基本元素：標題--描述這個用例要達到的目標；

　　　　　　　　　角色（Actor）--和軟件系統交互的角色；

　　　　　　　　　主要成功場景（Main Success Scenario）-- 一系列步驟描述角色是怎樣和系統交互，從而達到目標的；

　　　　　　　　　　　步驟--描述每一步的交互

　　　　　　　　　擴展場景（Extension）--描述一些擴展的交互；

　　使用Use Case的原則：

　　　　1.經過講簡單的故事來傳遞信息；

　　　　2.保持對全系統的理解；

　　　　3.關注用戶的價值；

　　　　4.逐步構建整個系統，一次完成一個用例；

　　　　5.增量開發，逐步構建整個系統；

　　　　6.適應團隊不斷變化的需求；

　　Use Case方法論的理念和敏捷、MSF大體相仿；它對細節的要求和典型人物、場景有不少類似之處，這些方法也有其侷限性：

　　　　1.故事 / 人物 / 場景很是適合交互式的系統，可是對於其餘類型的需求（算法，速度，擴展性，安全性，以及和系統技術相關的需求）則不適用；

　　　　2.故事的粒度沒有統一的標準，和每一個具體項目有關。初學者比較難以掌控。

　　　　3.若是軟件的關鍵在於用戶體驗的細節，那麼把這些UI的細節嵌入到每一個故事中並仍然保持故事的簡明性是一個難題；有的團隊把目前的技術擴展爲Use Case Storyboard，當一個簡明的故事加上不少附加說明和圖畫的時候，這事實上就成爲了功能說明書（Functional Specification），以及各類幫助建模的圖形工具；

　　規格說明書（Specification）： 簡稱Spec分爲如下兩種

　　　　1.軟件功能說明書（Functional Spec），主要用來講明軟件的外部功能和用戶的交互狀況【把軟件當作一個黑盒子】；

　　　　2.軟件技術說明書（Technical Spec），又叫設計文檔（Design Doc），主要用來講明軟件內部的設計規範（把軟件看成一個透明的箱子）；

　　功能說明書：從用戶的角度描述軟件產品的功能、輸入、輸出、界面、功能的邊界問題、功能的效率（對用戶而言）、國際化、本地化、異常狀況等，不涉及軟件內部的實現細節；

　　　　第一，定義好相關的概念；

　　　　第二，規範好一些假設（Assumptions）；

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

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

　　　　第五，一些好的功能還會有反作用；

　　　　第六，服務質量的說明；

　　寫好Spec的祕訣----實踐，實踐，再實踐；Spec的最大敵人----乏味；Spec的另外一個敵人----時間；

　　功能說明書的模板：

　　　　1.Spec的目標是什麼，Spec的目標不包括什麼？

　　　　2.Spec的用戶和典型場景是什麼？

　　　　3.Spec用到了哪些術語，它們的定義是什麼？

　　　　4.用戶是如何使用軟件的功能的？

　　　　5.各類邊界條件是什麼？

　　　　6.功能有什麼反作用，對於其餘功能有什麼顯性或隱性的依賴關係？

　　　　7.什麼叫「好」，什麼叫「這個功能測試完了，能夠交付了」？

　　　　8.軟件發佈出去以後，有哪些和項目目標相關的數據可採集？怎麼在實現階段就能把數據收集的工做準備好？

　　技術說明書：又稱設計文檔

　　　　應該說明工程師的設計是如何體現下列原則的：

　　　　　　1.抽象（Abstraction）；

　　　　　　2.內聚 / 耦合 / 模塊化（Cohesion，Coupling，Modularization）；

　　　　　　3.信息隱藏和封裝（Information Hiding，Encapsulation）；

　　　　　　4.界面和實現的分離（Separation of Interface and Implementation）；

　　　　　　5.如何處理錯誤狀況（Error Handling）；

　　　　　　6.程序模塊對於運行環境、相關模塊、輸入輸出參數有什麼假設？這些假設和相關的人員驗證過麼？

　　　　　　7.應對變化的靈活性（Adapt to Change）；

　　　　　　8.對大量數據的處理能力（Scalability）；

　　功能驅動的設計（Feature Driven Design FDD）----構成步驟：

　　　　1.構造整體模型（Develop an Overall Model）；

　　　　2.構造功能列表（Build a Feature List）；

　　　　3.制定開發計劃（Plan by Feature）；

　　　　4.功能設計階段（Design by Feature）；

　　　　5.實現具體功能（Build by Feature）；

第十一章-軟件設計與實現

　　在「需求分析」階段，咱們要搞清楚----在問題領域中的現實世界裏，都有哪些實體，如何抽象出咱們真正關心的屬性，實體之間的關係是什麼，在這個基礎上，用戶的需求是什麼，軟件如何解決用戶的需求；

　　在「設計與實現」階段，咱們要搞清楚----軟件是怎麼解決這些需求的；

　　在「測試」和「發佈」階段，咱們要搞清楚----軟件真的解決了這些需求了麼？

　　表達實體和實體之間的關係：

　　　　思惟導圖（Mind Map）；

　　　　實體關係圖（Entity Relationship Diagram）；

　　　　Use Case Diagram（UCD）--用例圖：

　　　　　　1.參與者（Actor）：表示參與系統運做的外部因素，一般是一個簡筆畫的小人；

　　　　　　2.系統：一般用一個方框來表示系統的邊界。有時也可忽略；

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

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

　　其餘設計方法：

　　　　形式化的方法（Formal Method）、文學化編程（Literate Programming）；

　　開發人員的標準工做流程：

　

　　開發階段的平常管理：

　　　　1.閉門造車（Leave Me Alone）；

　　　　2.每日構建（Daily Build）；

　　　　3.構建大師（Build Master）：

　　　　　　a.負責管理構建服務器；

　　　　　　b.調試構建，負責找錯，並分析出錯的緣由；

　　　　　　c.負責把「構建大師」稱號和責任交給下一個致使構建失敗的成員；

　　　　　　d.「構建大師」同時向團隊的「腐敗基金」存入50元，以供你們未來「腐敗」之用（此條可選）；

　　　　4.寬嚴皆誤；

　　　　5.小強地獄（Bug Hell）；

第十二章-用戶體驗

　　用戶界面（User Interface UI）、用戶體驗（User eXperience UX）

　　用戶體驗的要素：

　　　　1.用戶的第一印象：5W1H方法

　　　　　　　　Who：誰是你的目標用戶；

　　　　　　　　When：他們會在什麼時間使用你的產品；

　　　　　　　　Where：目標用戶會在哪裏和你的產品交互；

　　　　　　　　What：你的產品是什麼？而用戶的期待是什麼；

　　　　　　　　Why：用戶爲何要使用你的產品，他們的動機是什麼，在衆多競爭產品中，用戶爲什麼選擇你的產品；

　　　　　　　　How：用戶是如何與你的產品發生交互的；

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

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

　　　　4.短時間刺激和長期影響；

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

　　　　6.用戶體驗和質量；

　　　　7.情感設計

　　　　　　三個層次：

　　　　　　　　本能【Visceral】層次的設計----外形；

　　　　　　　　行爲【Behavior】層次的設計----使用的樂趣和效率；

　　　　　　　　反思【Reflective】層次的設計----自我形象、我的知足感、回憶；

　　評價標準：

　　　　對於一個軟件的用戶界面的評價標準，可參考費茨法則、Nielsen啓發式評估十條院子以及其餘經驗；

　　　　　　1.儘快提供可感觸的反饋；

　　　　　　2.系統界面符合用戶的現實慣例【Familiarity，Avoid Surprise】；

　　　　　　3.用戶有控制權；

　　　　　　4.一致性和標準化；

　　　　　　5.適合各類類型的用戶；

　　　　　　6.幫助用戶識別、診斷並修復錯誤；

　　　　　　7.有必要的提示和幫助文檔；

第十三章-軟件測試

　　基本名詞解釋及分類：

　　　　Bug：軟件的缺陷；

　　　　Test Case：測試用例；

　　　　Test Suite：測試用例集；

　　Bug可分解爲：症狀【Symptom】：即從用戶的角度看，軟件出了什麼問題；

　　　　　　　　  程序錯誤【Fault】：即從代碼的角度看，代碼的什麼錯誤致使了軟件的問題；

　　　　　　　　  根本緣由【Root Cause】：錯誤根源，即致使代碼錯誤的根本緣由；

　　按測試設計的方法分類：

　　　　黑箱【Black Box】：指的是在設計測試的過程當中，把軟件系統看成一個「黑箱」，沒法瞭解或使用系統的內部結構及知識；

　　　　白箱【White Box】：指的是在設計測試的過程當中，設計者能夠「看到」軟件系統的內部結構，並使用軟件的內部結構和知識來選擇測試數據及具體的測試方法；

　　按測試的目的分類：

　　　　功能測試：

　　　　　　Unit Test：單元測試----在最基本的功能 / 參數上驗證程序的正確性；

　　　　　　Functional Test：功能測試----驗證模塊的功能；

　　　　　　Integration Test：集成測試----驗證幾個互相有依賴關係的模塊的功能；

　　　　　　Scenario Test：場景測試----驗證幾個模塊可否完成一個用戶場景；

　　　　　　System Test：系統測試----對於整個系統功能的測試；

　　　　　　Alpha / Beta Test：外部軟件測試人員（Alpha / Beta測試員）在實際用戶環境中對軟件進行全面的測試；

　　　　非功能測試【Non-functional Requirement】（服務質量需求【Quality of Service Requirement】）：

　　　　　　Stress / Load Test：眼力測試----測試軟件在負載狀況下可否正常工做；

　　　　　　Performance Test：效能測試----測試軟件的效能；

　　　　　　Accessibility Test：可訪問性測試----測試軟件是否向殘疾用戶提供了足夠的輔助功能；

　　　　　　Lcalization / Globalization Test：本地化 / 全球化測試；

　　　　　　Compatibility Test：兼容性測試；

　　　　　　Configuration Test：配置測試----測試軟件在各類配置下可否正常工做；

　　　　　　Usability Test：易用性測試----測試軟件是否好用；

　　　　　　Security Test：軟件安全性測試；

　　按測試的時機和做用分類：

　　　　測試「烽火臺」、不一樣的測試方法；

　　各類測試方法：

　　　　1.單元測試和代碼覆蓋率測試；

　　　　2.構建驗證測試【Build Verification Test， BVT】：基本功能可否使用；

　　　　3.驗收測試【Acceptance Test】；

　　　　4.「探索式」的測試【Ad hoc Test】；

　　　　5.迴歸測試【Regression Test】：驗證修復的Bug有沒有再次出現；

　　　　6.場景 / 集成 / 系統測試：各模塊鏈接是否正常；

　　　　7.夥伴測試【Buddy Test】；

　　　　8.效能測試【Performance Test】：軟件在設計負載內可否提供令用戶滿意的服務質量；

　　　　　　涉及兩個概念：1.設計負載；2.令用戶滿意的服務質量；

　　　　　　現實的環境兩方面：1.現實的靜態數據；2.現實的動態數據；

　　　　9.壓力測試：增長負載的兩個方面----1.沿着用戶軸延長；2.沿着時間軸延長

　　　　10.內部 / 外部公開測試；

　　　　11.易用性測試；

　　　　12.「小強」大掃蕩【Bug Bash】；

第十四章-質量保障

　　軟件的質量：

　　　　軟件=程序+軟件工程；

　　　　軟件_質量 = 程序_質量 + 軟件工程_質量；

　　　　程序的質量：體如今軟件外在功能的質量；

　　　　軟件工程的質量：

　　　　　　軟件開發過程的可見性【Visibility】;

　　　　　　軟件開發過程的風險控制【Risk Management】；

　　　　　　軟件內部模塊，項目中間階段的交付質量，項目管理工具的因素；

　　　　　　軟件開發成本的控制【Cost Control】；

　　　　　　內部質量指標的完成狀況【Internal Benchmarks】；

　　CMMI【Capacity Maturity Model Integrated】：

　　　　一級：初始級（完成級）； 二級：管理級； 三級：明確（定義）級； 四級：量化管理級； 五級：優化級；

　　質量的成本：

　　　　預防【Prevention】；評審【Appraisal】；內部故障【Internal Failure】；外部故障【External Failure】；流程分析改進【Process Enhancement】；提升職業技能【Enhance Professional Skills】；投資軟件工具【Invest in Software Tools】；

第十五章-穩定和發佈階段

　　經常使用名詞：

　　　　Alpha：指集成了主要功能的第一個試用版本；

　　　　Beta：功能基本完備，穩定性較Alpha版本高，用戶能夠在實際工做中小範圍使用，能夠有多個Beta版本；

　　　　ZBB【Zero Bug Build】：某天的版本要把以前（規定時間內）記錄的Bug都解決掉；

　　　　RC【Release Candidate】：發佈候選版本，版本間隔時間較短；

　　　　RTM【Release To Manufacturer】：最終發佈版本；

　　　　RTW【Release To Web】：和RTM相似；

　　發佈以後----過後諸葛亮會議；