不只是在一本書中提到，軟體架構師其實和建築師在某些地方的確存在著異曲同工之妙，在我看來也的確如此，在之前由於沒有真正了解過建築師的工作，所以我對這一觀念理解的還不夠深刻，但是經過本次課堂**《夢想改造家》這一節目，通過節目的**、老師的指引、個人對王平仲老師設計的分析以及題目的解答，我突然認識到，無論是調查需求、發現問題，還是說進行架構，交付工程，建築設計師的工作如此，軟體架構師也是這樣，工作流程一般無二。
我認為可以按下面從三個過程對軟體架構師的工作流程進行分析與總結，分別是：調研需求、實施工程、交付工程。
一、調研需求
軟體架構師受邀來到客戶處，客戶提出當前出現的問題，架構師分析問題所在，總結出客戶的需求根本，尋求解決方案。同時，還要多方面徵求意見，了解軟體的不同客戶層對軟體的不同期望與要求，對它們依次進行記錄、總結。實地考察客戶的工作現場，親身體驗軟體所要進行的整個工作流程，發現那些客戶不曾注意到的，但是確實會對整個軟體起著重要作用的關鍵，並就這些問題與客戶進行交流，共同商討，尋求最佳的解決方案。最後要與客戶就軟體交付時間、交付質量進行商議，**出兩方都能夠接受的規則。待調研完畢後，彙總客戶的問題，對整個需求進行總結，構思出乙個具有合適的軟體架構的整體實施方案。
二、實施工程
在總結出了合適的實施方案後，尋找製作軟體的有關人員，分配工作給不同的人員，讓每個人員都能做適合他的任務，人員找的要得當，不能太多，也不能太少，做到每個人都有一些事做，這樣既能在期限內完成，又不會讓人員承擔過多或過少的工作。在工作分配結束後，軟體開始進入開發階段。在這時候，軟體架構師也不能停下，或者說任務更多，一方面，他作為軟體開發的主管者，要監督軟體的開發進度，督促軟體開發的每一方面都能夠保持進度，保證每天的工作量，以使軟體能夠保質保量的按時完成，另一方面，軟體架構師還需要繼續和使用者進行交流，時時審視工程是否有所遺漏，是否能夠符合使用者的預期，在出現差錯時，即時把開發引上正路，同時，架構師自身也要多多對各個方面的問題思考，對那些難以解決的問題進行考慮，為工程貢獻自己的力量。
三、交付工程
在工程完成後，對整個工程進行質量把關，檢查軟體是否真正符合使用者的期望，能否投入到實際的工作中去，以幫助使用者解決問題。如若還存在瑕疵，則檢視問題原因，試**決問題，並向使用者說明情況，保證在下次公升級中能夠完成預期；如果沒有問題，則將軟體的最終成果完美的展示給使用者，先讓使用者體驗整個軟體的使用過程，對於使用者在使用時出現的問題給出解答，讓使用者對使用的流程進行評價，提出使用者仍然遺留的問題，對問題進行檢視，如果能及時解決，則當場完成修改，否則及時對軟體進行公升級，以保證軟體能夠符合使用者的使用。
在這個過程中，我認為能學習的不僅僅是和建築設計相似的軟體架構流程，建築設計師王平仲的所作所為也值得我學習。他認真傾聽客戶的問題，引領客戶更多關於房間的需求，善解人意，和客戶打成一片，和善待人，他的確稱得上是一位好的設計師，而我想，應用到軟體工作流程中這樣做的話，軟體需求徵集與架構也不會成為難事。
軟體體系架構課下作業05
題目 撰寫一篇部落格全面闡述實現 xx重大技術需求徵集 系統所設計時所實現的質量屬性技術，並說明原因。在設計系統時所用到的質量屬性戰術共有六種，他們分別是 可用性 可修改性 效能 安全性 易用性 可測試性，下面依次是對各個戰術的使用 1.可用性 錯誤檢測對於乙個系統十分重要，在使用者對資料庫操作時，...
軟體體系架構課下作業04
作業要求 閱讀 大型 技術架構 核心原理與案例分析 第 五 六 七章，結合 某大型需求徵集 分析如何增加相應功能，提高系統的可用性和易用性，撰寫一篇1500字左右的部落格闡述你的觀點。的可用性描述了 可正常訪問的特性，相比於其他的五種特性，的可用性十分基礎，但卻更為關鍵，稱得上是乙個 的立身之本。可...
軟體體系架構課下作業03
作業要求 以 網 為例，描繪質量屬性的六個常見屬性場景，將上述整理為一篇部落格發表。描繪質量屬性的六個常見屬性分別是 可用性 可修改性 效能 安全性 可測試性 易用性。下面對 網進行這六方面的分析 效能 網能夠應對雙十 一 雙十二這種 節日，平時情況下，面對極大的同時訪問量也不會出現宕機的情況。安全...