① 如何進行軟體架構設計
軟體架構設計的幾個步驟 1、分析需求和理解業務模型（或領域建模），並選定關鍵Use case。 軟體的需求，可以分為從用戶視角和開發人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認識需求並分析需求，理解業務模型。實踐表明，常常被我們忽視的非功能性需求常常會導致整個項目失敗。 理解業務需求最好的方式莫過於進行領域建模，領域建模與需求分析往往是交替穿叉進行的，領域建模主要有以下三個方面的作用： ◆探索復雜問題，弄清領域知識。Martin Fowler曾經說過，他採用面向對象方法最大的好處就是它有助於解決更為復雜的問題。領域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業務概念及其關繫上，使我們能夠不斷深入地，系統的對需求進行分析和認識。領域建模往往是一個從模糊到清晰，從零散到系統的過程。 ◆決定功能范圍，影響可擴展性。任何模型都是對現實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背後的結構，如果說定義功能相當於「拍照片」的話，那麼領域建模就相當於「做透視」，更加關注問題領域的內在結構，相當於對問題領域進行了一定的抽象，良好的領域模型不僅能很好的支持現有的功能，而且還可以在一定程度上支持未來可能出現的新需求，體現良好的可擴展性。 ◆提供交流基礎，促進有效溝通。領域建模通常會使用UML圖作為呈現的方式，這樣為我們的溝通提供了方便。當然，有時候文字在描述某些特定領域的問題時可能更適合，可以靈活運用。 在我們公司的實際軟體開發流程中，往往領域建模缺少這一環節，這可能是在以後的工作中需要進一步提高之處。 雖然我們總是期望架構設計師能全面掌握需求，但由於時間和精力的限制，擺在我們面前的現實就是架構設計師沒有時間對所有需求進行深入分析，所以我們的策略就是「把好鋼用在刀刃上」，即把大部分時間和精力花在對決定架構最重要的關鍵需求上。在選擇關鍵需求時要注意：高優先順序的需求往往是從用戶的角度來看的，可能並不是真正的關鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關鍵功能需求？A.作為應用程序的核心或實現了系統的主要介面的功能，B.必須被實現的功能，即如果這些功能不被實現，則開發出來的軟體就失去了價值，C.覆蓋了系統架構的一些方面，但沒有被其他重要的Use case覆蓋到的功能。 2、分別從各個視角來考慮軟體架構的方方面面。 軟體的架構設計必須考慮到各方面，根據前期工作確立的領域模型，關鍵需求，系統約束等進行設計，必須從系統用戶，開發人員，系統管理員，部署管理員，數據管理員等人員的角度去分析並解決問題。比如說，如果我們的運行架構採用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業務邏輯要求我們要操作多個資料庫時，就要考慮採用支持二階段事務提交的方式。 只有將這些方方面面的問題都考慮到了，這樣的架構設計才是完整的。至於每一個視圖中，我們應該設計到什麼細節這一問題，實際上與整個項目的過程定義有關。例如，如果我們有專門安排資料庫概要設計的活動，那我們在架構設計的過程中就可以只需要關注更高層次的資料庫特性及資料庫之間的關系，而每一張表的數據字典可以在後續的相關活動中進行設計，但如果沒有這樣的活動，那我們就要細化到每一張表的每一個欄位，以及表之間的關系。 3、解決技術面的重點問題和難題 在軟體架構設計的過程中，我們往往會需要攻克一些技術面的重點問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經驗支撐的工作。例如，我們如何提高整個系統的性能？如何能很好的導出極其復雜的「中國式報表」（一般比西方國家產出的報表要復雜很多，而且很多開源的BI類的框架並不能完全解決問題）？ 當遇到確實是很困難的問題，可以去網路一下或Google一下，也可以去請教公司的資深技術人員或專家，或者召開小范圍的技術專題討論會議，採用腦力激盪的方法試著找找答案，這樣才能提高工作的效率。 4、召開架構設計評審會議進行同行評審。 架構設計評審是極其重要的一環，我曾將其形容為「七種武器」中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，並做好記錄，正所謂「良葯苦口利於病，忠言逆耳利於行」。 在評審會議之前，我們要完成很多准備工作，最好是能准備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提高會議的效率。 5、針對關鍵Use case在設計的架構上實現功能來驗證架構。 對於架構設計的驗證也是一項十分重要的工作，其驗證技術有很多種，在我們公司通常會採用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產品角度出發來有效的驗證架構是否滿足要求，又可以比拋棄型原型驗證技術節省成本。 這個Sample絕不是我們在解決架構設計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規范的可交付的代碼及相關文檔。同時，這個Sample可以作為你在給大家講解或培訓架構時的教材，也可以作為開發人員使用此架構進行開發的藍本，甚至是只需要復制粘貼，加上簡單的修改即可。 6、交付給客戶Review。 這一環節，在很多公司可能並不存在，因為他們的軟體架構並不一定需要客戶Review，但像我們這種做服務的公司，最重要的就是客尊，落實到軟體架構設計這一活動，就是讓客戶理解並接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的作用。通常，我們的架構得到客戶的認可後，便可進入大規模的開發。 在交付給客戶Review時，通常
② 軟體開發的流程都有哪些步驟呢
軟體開發是指一個軟體項目的開發，如市場調查，需求分析，可行性分析，初步設計，詳細設計，形成文檔，建立初步模型，編寫詳細代碼，測試修改，發布等。
軟體是怎麼樣開發出來的
第一個步驟是市場調研，技術和市場要結合才能體現最大價值。
第二個步驟是需求分析，這個階段需要出三樣東西，用戶視圖，數據詞典和用戶操作手 冊。
用戶視圖 是該軟體用戶（包括終端用戶和管理用戶）所能看到的頁面樣式，這裡麵包含了 很多操作方面的流程和條件。
數據詞典 是指明數據邏輯關系並加以整理的東東，完成了數據詞典，資料庫的設計就完成了一半多。
用戶操作手冊是指明了操作流程的說明書。
請注意，用戶操作流程和用戶視圖是由需求決定的，因此應該在軟體設計之前完成，完成這些，就為程序研發提供了約束和准繩，很遺憾太多公司都不是這樣做的，因果顛倒，順序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。
需求分析，除了以上工作，筆者以為作為項目設計者應當完整的做出項目的性能需求說明 書，因為往往性能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或公司市場部門）能夠有真正的溝通和了解。
第三個步驟是概要設計，將系統功能模塊初步劃分，並給出合理的研發流程和資源要求。
作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常採用這種方法是因為涉及的研發任務屬於新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是 並不是說詳細設計說明書不重要，事實上快速原型法在完成原型代碼後，根據評測結果和 經驗教訓的總結，還要重新進行詳細設計的步驟。
第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把 具體的模塊以最』干凈』的方式(黑箱結構）提供給編碼者，使得系統整體模塊化達到最 大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低，實際上，嚴格的講詳細 設計說明書應當把每個函數的每個參數的定義都精精細細的提供出來，從需求分析到概要 設計到完成詳細設計說明書，一個軟體項目就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行代碼工作。
那些把作軟體的程序員簡單理解為寫代碼的，就從根子上犯了錯誤了。
第五個步驟是編碼，在規范化的研發流程中，編碼工作在整個項目流程里最多不會超過1/ 2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提 高，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在很多研發過程中都 出現過。
編碼時的相互溝通和應急的解決手段都是相當重要的，對於程序員而言，bug永 遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候 嗎？從來沒有！
第六個步驟是測試
測試有很多種：
按照測試執行方，可以分為內部測試和外部測試
按照測試范圍，可以分為模塊測試和整體聯調
按照測試條件，可以分為正常操作情況測試和異常情況測試
按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試
以上都很好理解，不再解釋。
總之，測試同樣是項目研發中一個相當重要的步驟，對於一個大型軟體，3個月到1年的外部測試都是正常的，因為永遠都會又不可預料的問題存在。
完成測試後，完成驗收並完成最後的一些幫助文檔，整體項目才算告一段落，當然日後少不了升級，修補等等工作，只要不是想通過一錘子買賣騙錢，就要不停的跟蹤軟體的運營 狀況並持續修補升級，直到這個軟體被徹底淘汰為止。
什麼是軟體開發的核心問題
按照軟體工程鼻祖，《人月神話》作者 Brooks 在「沒有銀彈——軟體工程中的根本和次要問題」一章中闡述的思想，軟體開發的核心問題就是如何從概念上對一個復雜的業務系統進行建模。這個建模是含義廣泛的，不僅僅包括對象建模，還包括數據建模、演算法建模等等一系列的內容。總而言之是要先找到解決復雜問題的突破口（先要搞明白需要做什麼，然後再考慮如何做）。至於採用什麼表示方法（簡單文本、UML 圖、E-R 圖）、採用什麼高級語言、是否一定要用面向對象、使用什麼開發工具都是次要的問題。
軟體開發方法
軟體開發方法(Software Development Method)是指軟體開發過程所遵循的辦法和步驟。
軟體開發活動的目的是有效地得到一些工作產物，也就是一個運行的系統及其支持文檔，並且滿足有關的質量要求。軟體開發是一種非常復雜的腦力勞動，所以經常更多討論的是軟體開發方法學，指的是規則、方法和工具的集成，既支持開發，也支持以後的演變過程(交付運行後，系統還會變化，或是為了改錯，或是為了功能的增減)。
關於組成軟體開發和系統演化的活動有著各種模型(參見軟體生存周期，軟體開發模型，軟體過程)，但是典型地都包含了以下的過程或活動：分析、設計、實現、確認(測試驗收)、演化(維護)。
有些軟體開發方法是專門針對某一開發階段的，屬於局部性的軟體開發方法。
特別是軟體開發的實踐表明，在開發的早期階段多做努力，在後來的測試和維護階段就會使費用較大地得以縮減。因此，針對分析和設計階段的軟體開發方法特別受到重視。其它階段的方法，從程序設計發展的初期起就是研究的重點，
已經發展得比較成熟(參見程序設計，維護過程)。除了分階段的局部性軟體開發方法之外，還有覆蓋開發全過程的全局性方法，尤為軟體開發方法學注意的重點。
對軟體開發方法的一般要求：當提出一種軟體開發方法時，應該考慮許多因素，包括：
①覆蓋開發全過程，並且便於在各階段間的過渡；
②便於在開發各階段中有關人員之間的通信；
③支持有效的解決問題的
④支持系統設計和開發的各種不同途徑；
⑤在開發過程中支持軟體正確性的校驗和驗證；
⑥便於在系統需求中列入設計、實際和性能的約束；
⑦支持設計師和其他技術人員的智力勞動；
⑧在系統的整個生存周期都支持它的演化；
⑨受自動化工具的支持。此外，在開發的所有階段，有關的軟體產物都應該是可見和可控的；軟體開發方法應該可教學、可轉移，還應該是開放的，即可以容納新的技術、管理方法和新工具，並且與已有的標准相適應。
參考：http://www.blog.e.cn/user5/280156/archives/2008/2090192.shtml
③ 軟體開發方法總結
在軟體開發的過程中,軟體開發方法是關繫到軟體開發成敗的重要因素。 軟體開發方法就是軟體開發所遵循的辦法和步驟,以保證所得到的運行系統和支持的文檔滿足質量要求，下面為大家分享了軟體開發方法，一起來看看吧！
1 結構化開發方法
結構指系統內各組成要素之間的相互聯系、相互作用的框架。結構化開發方法強調系統結構的合理性以及所開發的軟體的結構的合理性,主要是面向數據流的,因此也被稱為面向功能的軟體開發方法或面向數據流的軟體開發方法。結構化技術包括結構化分析、結構化設計和結構化程序設計三方面內容。
1.1 結構化分析的步驟
結構化分析是一種模型的確立活動,就是使用獨有的符號,來確立描繪信息(數據和控制)流和內容的模型,劃分系統的功能和行為,以及其他為確立模型不可缺少的描述。其基本步驟是:
(1)構造數據流模型:根據用戶當前需求,在創建實體—關系圖的基礎上,依據數據流圖構造數據流模型。
(2)構建控制流模型:一些應用系統除了要求用數據流建模外,通過構造控制流圖(CFD),構建控制流模型。
(3)生成數據字典:對所有數據元素的輸入、輸出、存儲結構,甚至是中間計算結果進行有組織的列表。目前一般採用CASE的「結構化分析和設計工具」來完成。
(4)生成可選方案,建立需求規約:確定各種方案的成本和風險等級,據此對各種方案進行分析,然後從中選擇一種方案,建立完整的需求規約。
1.2 結構化設計步驟
結構化設計是採用最佳的可能方法設計系統的各個組成部分以及各成分之間的內部聯系的技術,目的在於提出滿足系統需求的最佳軟體的結構,完成軟體層次圖或軟體結構圖。其基本步驟如下:
(1)研究、分析和審查數據流圖。從軟體的需求規格說明中弄清數據流加工的過程。
(2)然後根據數據流圖決定問題的類型。數據處理問題有兩種典型的類型:變換型和事務型。針對兩種不同的'類型分別進行分析處理。(3)由數據流圖推導出系統的初始結構圖。也就是把數據流圖映射到軟體模塊結構,設計出模塊結構的上層。
(4)利用一些試探性原則來改進系統的初始結構圖,直到得到符合要求的結構圖為止。即在數據流圖的基礎上逐步分解高層模塊,設計中下層模塊,並對軟體模塊結構進行優化,最終得到更為合理的軟體結構。
(5)描述模塊介面。
(6)修改和補充數據詞典。
(6)制定測試計劃。
結構化設計可以將用數據流圖表示的信息轉換成程序結構的設計描述。
2 模塊化開發方法
模塊化程序設計方法就是把一個待開發的軟體系統分解成若干可單獨命名和編址的較為簡單的部分,這些可單獨命名和編址的部分稱為模塊。每個模塊分別獨立地開發、測試,最後再組裝出整個軟體系統。這種方法不僅可以將軟體系統開發的復雜性在分解過程中降低,便於修改、維護,而且還容易實現同一個系統不同部分的並行開發,從而提高了軟體的生產效率。
一般,將用一個名字就可調用的一段程序稱為「模塊」。在考慮模塊化時,將模塊定義為多大較合適,模塊設計規則應如何制定成為關鍵,下面五條標准可供參考:
(1)模塊可分解性:如果一種設計方法提供了將問題分解成子問題的系統化機制,它就能降低整個系統的復雜性,從而實現一種有效的模塊化解決方案。
(2)模塊可組裝性:如果一種設計方法使現存的設計模塊能夠被組裝成新系統,它就能提供一種不用一切從頭開始的模塊化解決方案。
(3)模塊可理解性:如果一個模塊可以作為一個獨立的單位被理解,那麼它就易於構造和修改。(4)模塊連續性:如果對系統需求的微小修改只導致對單個模塊而不是對整個系統的修改,則修改引起的副作用就會被最小化。
一般來說,對模塊採用耦合和內聚兩個准則進行度量。如模塊內部具有高內聚和模塊間低耦合,那這樣的模塊就具有獨立性,模塊設計得比較好。
3 面向對象開發方法
面向對象開發方法是以面向對象程序設計語言作為基礎的,其核心思想是利用面向對象的概念和方法為軟體需求建立模型,進行系統設計,採用面向對象程序設計語言進行系統實現,對建成的系統進行面向對象的測試和維護。
如果一個軟體系統是使用這樣4個概念設計和實現的,則可以認為這個軟體系統是面向對象的。其基本要點可以概括為:
(1)數據的抽象,即類與子類的概念及相互關系。任何客觀的事物和實體都是對象,復雜對象可以由簡單對象組成
(2)數據及對它的操作的一體化,即封裝的概念和方法。具有相同數據和操作的對象可歸並為一個類,具有封裝性,形成一個包裝;對象是類的一個實例;一個類可以產生很多對象。
(3)屬性與操作由父類向子類傳遞,即繼承的概念與方法。類可以派生出子類,繼承能避免共同行為的重復。
(4)客觀事物之間的相互關系用統一的、消息傳遞的方法來描述。
目前廣泛使用的面向對象開發方法包括Booch方法、Rumbaugh方法、Coad和Yourdon方法、Jacobson方法、Wirfs-Brock方法和統一建模方法等。