通過課堂上**夢想改造家這個節目，我想到了軟體架構師的工作流程，在夢想改造家中，王仲平這個建築師首先是了解使用者需求，然後根據使用者需求制定相應的方案和改造計畫，其中考慮到了使用者的方便性，安全性，重用性，空間利用性。對於我們軟體架構師來說，同樣如此，非常相似。
軟體架構師在需求分析階段介入。在這一階段軟體體系架構師與軟體需求人員一起將所有的需求從不同的級別分層數理列表歸納總結建立跟蹤矩陣，並劃分為不同的型別進行數理列表歸納總結建立影響分析表，找出不同需求型別之間的相互支援、相互制約關係的影響。並同需求分析人員共同建立需求規格說明書。
第二步是確定對架構關鍵的需求，軟體架構師將所有的需求進行篩選，在深思熟慮之後做出合適的需求權衡和取捨，最終確定對軟體架構其關鍵作用的子集，控制架構設計時需要詳細分析的用例個數，找到架構的重點非功能需求。要根據需求確定架構目標（即是組成設計過程、確定使用範圍並確定什麼時候該結束的因素）。並且要了解架構的消費者。要確定架構是否會被其他設計師、開發人員、測試人員、業務人員或管理人員使用。確定架構涉眾的需求，以讓架構更為成功、更有影響力。了解條件限制。了解技術限制、使用限制、和部署限制。從一開始就要了解這些限制，這樣你才不會在將來遇到一些意想不到的麻煩。為後面的工作打下堅實的基礎。
第三步進行概念性架構設計，首先分析關鍵用例和有用例規約，運用魯棒圖（檢查用例規約是否正確和完善）等方法構造系統理想化的職責模型（如分層），然後明確架構模式（如mvc），確定互動機制，形成初步的概念性架構，最後通過質量屬性分析，制定出滿足非功能性需求的高層設計決策，並根據這些決策對之前的工作成果進行增強、調整，以保證概念性架構體現這些設計決策。設計架構的時候還應該對應用進行一定的了解，因為了解應用在完成的時候的大概情況。這將會使架構更實際，並與具體的條件限制和決定有更密切的聯絡。建立應用的大概檢視應該包括以下步驟：決定應用的型別。了解部署限制。確定重要的架構特點。確定相關的技術。還要確定出主要的危險區域即容易出錯的區域，可以可以通過質量屬性和交叉問題對危險區域進行整理。然後找出對於應用和場景很重要的質量屬性。
第四步是細化軟體架構，考慮具體技術的運用，設計出實際架構。概念性架構所關注的關鍵設計要素、互動機制、高層設計決策與具體技術無關，而最終的軟體架構設計方案必須和具體技術結合，為開發人員提供足夠的指導和限制。必須從系統如何規劃、如何開發、如何執行等角度揭示軟體系統的結構和機制。一般分別從邏輯架構、開發架構、執行架構、物理架構、資料架構等不同架構檢視進行設計。在設計的時候可以使用質量屬性幫助設計。
第五步是驗證軟體構架。不管軟體體系架構師有多優秀，都不能保證軟體架構是完全符合要求符合標準的，所以要驗證軟體架構。進行驗證的時候要根據架構框架來計畫並整理構架測試。利用不同的測試方法來驗證構架的各種質量屬性。
最後，由於軟體專案的不同、開發組織結構的不同、開發團隊情況的不同，軟體架構的設計粒度是不一定的。比如，航天航空領域中的軟體系統對系統的可靠性等質量屬性要求非常高甚至可以認為是荷刻，這種情況下對架構的設計詳細程度的要求也會比較高；象大的團隊中又有小的團隊共同開發，架構的設計粒度到子系統級就足夠了，各個小團隊精通的技術各不相同，可以讓其對子系統採用敏捷開發，對縮短工期、人盡其材有好處；有類似專案經驗或專案團隊所有成員整體技術水平較高的團隊架構粒度可適當粗獷，而分布團隊或涉及外包的情況則更強調架構的明確性。總之，架構設計對軟體的不同部分的設計程度不應是整齊劃一的，特別是具體的業務功能模組在架構設計中往往設計程度不深。
軟體架構師工作流程
軟體架構師類似於建築的工程師，都是站在總體的角度考慮問題，樓房是建築師的產品，建築師在設計樓房的時候要考慮樓房的高度，地基的大小，建造的材料，樓房的用途等因素 同樣的，軟體架構師也要考慮各個方面的因素，例如 執行環境，軟體功能，核心技術，適用人群等。我們在課堂上 了 夢想改造家 這個節目，這期節目主...
軟體架構師如何工作
通過閱讀構架漫談，軟體架構師工作需要了解一下幾個方面 首先要理解什麼是架構，為什麼需要架構 架構是規劃 設計和建造建築物和其他物理結構的過程和產物。人們完成一項任務，因為每個人的能力不同，所擅長的方向不同，所以如果自己去完成一項任務一般要花費很長的時間，效率很低，但是人們對目標有更高的要求，所以需要...
軟體架構師如何工作
要理解軟體架構師如何工作，在閱讀了架構漫談九篇部落格後，不妨先來看看架構是什麼。內容如下 1.根據要解決的問題，對目標系統的邊界進行界定。2.並對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或序列開展工作，一般並行才能減少時間。3.並對這些切分出來的部分，設立溝...