1.
架構不是一維的概念，要根據受眾情況從多個方面解構。經典的檢視包括4+1+2
2.各種檢視的實現方式（描繪方式）是沒有定規的，但有些具體的實現細節可以採用標準的，如uml。
3.邏輯檢視可以用動畫，開發檢視中可以沒有uml，而是一些框架元件的壘砌和他們之間的關係（如weblogic，spring等）。資料檢視（資料架構）
可分為資料複製與分布，資料流的處理和安全性。
4.架構檢視的設計方式：結合實際可增加和減少檢視；多檢視可以組合；多個檢視可以並行設計，由首席架構師領銜總體。
5.本次架構課程所講的架構設計所存在的軟體工程模型接近於瀑布模型，需求分析階段和架構設計階段是並行進行的，然後才是high level design
—> low level design
6.架構技術要求對行業有深刻的理解（電信，銀行，網際網路）。架構師是一種經驗工種
7.目前瀑布模型還是有生命力的，原因包括政策因素（軟體各個階段需要驗收），大型專案需要（特別是電信銀行等行業）。但是可能正在趨向於迭代模型，扭曲原來
的process來盡可能的適應變化。
8. 架構設計的考慮因素：功能，質量屬性，約束。後兩個合稱非功能性需求，非功能性需求更重要
9. 質量屬性 （包括效能、可擴充套件性、可用性等等）驅動著架構的設計
（類似於變化驅動著敏捷軟體的設計），而質量屬性的各個方面經常是衝突的，此消彼長，因此需要通盤權衡。
10.架構師必須腳踏實地，最佳實踐是: 質量屬性——場景——決策
11. 軟體架構 <=> 程式設計 <=> 質量屬性中每個因素的考慮 =》
都可以應用方**：原則、模式、最佳實踐。大師從最佳實踐總結出實用的模式，再提煉出原則，而我們站在巨人肩膀上是先了解原則，再學習模式，然後再用於實
踐。12. 推薦書：軟體構架實踐（卡內基·梅隆大學軟體工程研究所(cmu／sei)）、面向模式的軟體體系架構（卷1，2，3，4）
13.真正做專案的時候，對技術的盲目追求反而是制約專案成功的乙個因素，因為乙個專案要從各個方面進行考慮，哪方面也不能過於偏重。（如易用性、可靠性、甚至
是政策法規）
14. 80% + 20%
15.架構起碼與兩個東西密切相關：行業和應用型別。行業有電信，銀行，網際網路等，不同行業中的架構方式也是相差極大的。應用型別太多了，如聯機資料處理型別，
聯機資料分析型別，批處理型別等等，不同的應用型別也有不同架構設計方法。因此恪守乙個行業，做精做專是王道。
16. 架構設計師的metrix： 行業+技術+softskill。
行業是最重要的，需要深入而且廣泛的積累（在本行業內部）；業務諮詢師比較滋潤，因為不怎麼改變。
技術是需要的，但不可痴迷，因為技術不可避免會拋棄你的，不斷追尋新技術是疲於奔命的。
softskill，是什麼？有點虛。
17.hao123,初中生，500w；ucweb，修改開源，1000萬美元投資
18. 架構師的工作流程 （講的太快了此處，需要進一步修煉）：
功能分解（系統邊界確定、子系統劃分、介面定義） =>
邏輯檢視
立方圖（分層+分割槽+質量屬性） => 開發檢視
《軟體需求最佳實踐》閱讀筆記06
第7章 需求描述最佳實踐 在描述需求時，我們首先確定以什麼風格來表述，另外還應該選擇與專案 團隊特點相符合的風格模板。常見的描述風格與選用標準 在描述需求時，最常見的描述風格個可以分成自然語言 圖形化模型和形式化規格描述3種 自然語言，也就是使用結構合理的自然語言來描述需求，這種形式不管對於寫的人還...
《軟體需求最佳實踐》閱讀筆記01
第3章 軟體需求與需求工程 什麼是軟體需求 需求的三個層次 業務需求 業務需求是反映企業組織對軟體系統的高層次目標要求，就是軟體系統的建設目標 使用者需求 值描述的時使用者使用軟體需要完成什麼任務，怎麼完成的需求，通常是在業務定義的基礎上進行使用者訪談 調查，對使用者使用的場景進行整理，從而建立使用...
《軟體需求最佳實踐》閱讀筆記二
本書第二章講述了 不同軟體專案的需求檢視 開篇便告訴讀者現在正在執行的軟體分為 聯機事務處理系統，管理資訊系統 mis 主管資訊系統 eis 決策支援系統 dss 專家系統，辦公自動化系統 oa 等 然後分別從這幾類系統之間的聯絡入手進行了清晰的講述，是我收穫頗豐，漲了不少知識。下面是這些系統的乙個...