論系統模型與軟體工程建模

1. 軟體工程 用來描述系統的是什麼模型

件工程中能「標識系統要解決的的問題」的模型是概念模型 概念模式也稱為模式或邏輯模式，概念模式是資料庫中全體數據的整體邏輯結構和特徵的描述，概念模式通常還包含有訪問控制、保密定義和完整性檢查等方面的內容，以及概念/物理之間的映射。

2. 系統建模與模擬是什麼樣的專業

系統建模應該屬於軟體工程

3. 系統開放與軟體工程的兩個質量模型是什麼

軟體工程(Software Engineering，簡稱為SE)是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及到程序設計語言，資料庫，軟體開發工具，系統平台，標准，設計模式等方面。

在現代社會中，軟體應用於多個方面。典型的軟體比如有電子郵件，嵌入式系統，人機界面，辦公套件，操作系統，編譯器，資料庫，游戲等。同時，各個行業幾乎都有計算機軟體的應用，比如工業，農業，銀行，航空，政府部門等。這些應用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量。

軟體工程師是對應用軟體創造軟體的人們的統稱，軟體工程師按照所處的領域不同可以分為系統分析員，軟體設計師，系統架構師，程序員，測試員等等。人們也常常用程序員來泛指各種軟體工程師。

軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。

(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。

(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。

(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

一、軟體工程概述

概念：應需而生

軟體工程是一類工程。工程是將理論和知識應用於實踐的科學。就軟體工程而言，它借鑒了傳統工程的原則和方法，以求高效地開發高質量軟體。其中應用了計算機科學、數學和管理科學。計算機科學和數學用於構造模型與演算法，工程科學用於制定規范、設計范型、評估成本及確定權衡，管理科學用於計劃、資源、質量和成本的管理。

軟體工程這一概念，主要是針對20世紀60年代「軟體危機」而提出的。它首次出現在1968年NATO（北大西洋公約組織）會議上。自這一概念提出以來，圍繞軟體項目，開展了有關開發模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，開發了一些結構化程序設計語言（例如PASCAL語言，Ada語言）、結構化方法等。並且圍繞項目管理提出了費用估算、文檔復審等方法和工具。綜觀60年代末至80年代初，其主要特徵是，前期著重研究系統實現技術，後期開始強調開發管理和軟體質量。

70年代初，自「軟體工廠」這一概念提出以來，主要圍繞軟體過程以及軟體復用，開展了有關軟體生產技術和軟體生產管理的研究與實踐。其主要成果有：提出了應用廣泛的面向對象語言以及相關的面向對象方法，大力開展了計算機輔助軟體工程的研究與實踐。尤其是近幾年來，針對軟體復用及軟體生產，軟體構件技術以及軟體質量控制技術、質量保證技術得到了廣泛的應用。目前各個軟體企業都十分重視資質認證，並想通過這些工作進行企業管理和技術的提升。軟體工程所涉及的要素可概括如下：

根據這一框架，可以看出：軟體工程涉及了軟體工程的目標、軟體工程原則和軟體工程活動。

目標：我的眼裡只有「產品」

軟體工程的主要目標是：生產具有正確性、可用性以及開銷合宜的產品。正確性意指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜性是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多問題有待解決，它們形成了對過程、過程模型及工程方法選取的約束。

軟體工程活動是「生產一個最終滿足需求且達到工程目標的軟體產品所需要的步驟」。主要包括需求、設計、實現、確認以及支持等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體體系結構，包括子系統、模塊以及相關層次的說明、每一模塊介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。支持活動包括修改和完善。伴隨以上活動，還有管理過程、支持過程、培訓過程等。

框架：四項基本原則是基石

軟體工程圍繞工程設計、工程支持以及工程管理，提出了以下四項基本原則：

第一，選取適宜開發范型。該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其他因素之間是相互制約、相互影響的，經常需要權衡。因此，必須認識需求定義的易變性，採用適宜的開發范型予以控制，以保證軟體產品滿足用戶的要求。

第二，採用合適的設計方法。在軟體設計中，通常要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。

第三，提供高質量的工程支持。「工欲善其事，必先利其器」。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

第四，重視開發過程的管理。軟體工程的管理，直接影響可用資源的有效利用，生產滿足目標的軟體產品，提高軟體組織的生產能力等問題。因此，僅當軟體過程得以有效管理時，才能實現有效的軟體工程。

這一軟體工程框架告訴我們，軟體工程的目標是可用性、正確性和合算性；實施一個軟體工程要選取適宜的開發范型，要採用合適的設計方法，要提供高質量的工程支撐，要實行開發過程的有效管理；軟體工程活動主要包括需求、設計、實現、確認和支持等活動，每一活動可根據特定的軟體工程，採用合適的開發范型、設計方法、支持過程以及過程管理。根據軟體工程這一框架，軟體工程學科的研究內容主要包括：軟體開發范型、軟體開發方法、軟體過程、軟體工具、軟體開發環境、計算機輔助軟體工程(CASE) 及軟體經濟學等。

作用：高效開發高質量軟體

自從軟體工程概念提出以來，經過30多年的研究與實踐,雖然「軟體危機」沒得到徹底解決，但在軟體開發方法和技術方面已經有了很大的進步。尤其應該指出的是，自80年代中期，美國工業界和政府部門開始認識到，在軟體開發中，最關鍵的問題是軟體開發組織不能很好地定義和管理其軟體過程，從而使一些好的開發方法和技術都起不到所期望的作用。也就是說，在沒有很好定義和管理軟體過程的軟體開發中，開發組織不可能在好的軟體方法和工具中獲益。

根據調查，中國的現狀幾乎和美國10多年前的情況一樣，軟體開發過程沒有明確規定，文檔不完整，也不規范，軟體項目的成功往往歸功於軟體開發組的一些傑出個人或小組的努力。這種依賴於個別人員上的成功並不能為全組織的軟體生產率和質量的提高奠定有效的基礎，只有通過建立全組織的過程改善，採用嚴格的軟體工程方法和管理，並且堅持不懈地付諸實踐，才能取得全組織的軟體過程能力的不斷提高。

這一事實告訴我們，只有堅持軟體工程的四條基本原則，既重視軟體技術的應用，又重視軟體工程的支持和管理，並在實踐中貫徹實施，才能高效地開發出高質量的軟體。

二、軟體工程的七條基本原理

自從1968年提出「軟體工程」這一術語以來，研究軟體工程的專家學者們陸續 提出了100多條關於軟體工程的准則或信條。 美國著名的軟體工程專家 Boehm 綜合這些專家的意見，並總結了TRW公司多年的開發軟體的經驗，於1983年提出了軟體工程的七條基本原理。

Boehm 認為，著七條原理是確保軟體產品質量和開發效率的原理的最小集合。
它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。

人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟體工程准則都可以有這七條原理的任意組合蘊含或派生。

下面簡要介紹軟體工程的七條原理：

1 用分階段的生命周期計劃嚴格管理
這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由於計劃不周而造成的。在軟體開發與維護的漫長生命周期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命周期分成若干階段，並相應制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發和維護進行管理。 Boehm 認為，在整個軟體生命周期中應指定並嚴格執行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產品控制計劃、驗證計劃、運行維護計劃。

2 堅持進行階段評審
統計結果顯示： 大部分錯誤是在編碼之前造成的，大約佔63%; <2> 錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。 因此，軟體的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便盡早發現錯誤。

3 實行嚴格的產品控制
開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟體的一致性。

4 採納現代程序設計技術
從六、七時年代的結構化軟體開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大似氣力。採用先進的技術即可以提高軟體開發的效率，又可以減少軟體維護的成本。

5 結果應能清楚地審查
軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限， 盡量明確地規定開發小組的責任和產品標准，從而使所得到的標准能清楚地審查。

6 開發小組的人員應少而精
開發人員的素質和數量是影響軟體質量和開發效率的重要因素，應該少而精。
這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高幾倍到幾十倍，開發工作中犯的錯誤也要少的多； 當開發小組為N人時，可能的通訊信道為N(N-1)/2, 可見隨著人數N的增大，通訊開銷將急劇增大。

7 承認不斷改進軟體工程實踐的必要性
遵從上述六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，Boehm提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條原理。根據這條原理，不僅要積極採納新的軟體開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的 軟體技術的效果，也可以用來指明必須著重注意的問題和應該優先進行研究的工具和技術。

面向方面的編程（Aspect Oriented Programming，簡稱AOP）被認為是近年來軟體工程的另外一個重要發展。這里的方面指的是完成一個功能的對象和函數的集合。在這一方面相關的內容有泛型編程（Generic Programming）和模板。

參考
胡崑山，《中國軟體產業發展現狀與人才需求》，2003年9月1日，

三、軟體工程的目標與常用模型

軟體工程的目標是提高軟體的質量與生產率，最終實現軟體的工業化生產。質量是軟體需求方最關心的問題，用戶即使不圖物美價廉，也要求個貨真價實。生產率是軟體供應方最關心的問題，老闆和員工都想用更少的時間掙更多的錢。質量與生產率之間有著內在的聯系，高生產率必須以質量合格為前提。如果質量不合格，對供需雙方都是壞事情。從短期效益看，追求高質量會延長軟體開發時間並且增大費用，似乎降低了生產率。從長期效益看，高質量將保證軟體開發的全過程更加規范流暢，大大降低了軟體的維護代價，實質上是提高了生產率，同時可獲得很好的信譽。質量與生產率之間不存在根本的對立，好的軟體工程方法可以同時提高質量與生產率。

軟體供需雙方的代表能在餐桌上談笑風生，歸功於第一線開發人員的辛勤工作。質量與生產率的提高就指望程序員與程序經理。對開發人員而言，如果非得在質量與生產率之間分個主次不可，那麼應該是質量第一，生產率第二。這是因為：（1）質量直接體現在軟體的每段程序中，高質量自然是開發人員的技術追求，也是職業道德的要求。（2）高質量對所有的用戶都有價值，而高生產率只對開發方有意義。（3）如果一開始就追求高生產率，容易使人急功近利，留下隱患。寧可進度慢些，也要保證每個環節的質量，以圖長遠利益。

軟體的質量因素很多，如正確性，性能、可靠性、容錯性、易用性、靈活性、可擴充性、可理解性、可維護性等等。有些因素相互重疊，有些則相抵觸，真要提高質量可不容易啊！

軟體工程的主要環節有：人員管理、項目管理、可行性與需求分析、系統設計、程序設計、測試、維護等，如圖1.1所示。

軟體工程模型建議用一定的流程將各個環節連接起來，並可用規范的方式操作全過程，如同工廠的生產線。常見的軟體工程模型有：線性模型（圖1.2），漸增式模型（圖1.3），螺旋模型，快速原型模型，形式化描述模型等等 [Pressmam 1999, Sommerville 1992]。

最早出現的軟體工程模型是線性模型（又稱瀑布模型）。線性模型太理想化，太單純，已不再適合現代的軟體開發模式，幾乎被業界拋棄。偶而被人提起，都屬於被貶對象，未被留一絲惋惜。但我們應該認識到，「線性」是人們最容易掌握並能熟練應用的思想方法。當人們碰到一個復雜的「非線性」問題時，總是千方百計地將其分解或轉化為一系列簡單的線性問題，然後逐個解決。一個軟體系統的整體可能是復雜的，而單個子程序總是簡單的，可以用線性的方式來實現，否則幹活就太累了。線性是一種簡潔，簡潔就是美。當我們領會了線性的精神，就不要再呆板地套用線性模型的外表，而應該用活它。例如漸增式模型實質就是分段的線性模型，如圖1.3所示。螺旋模型則是接連的彎曲了的線性模型。在其它模型中都能夠找到線性模型的影子。

套用固定的模型不是程序員的聰明之舉。比如「程序設計」與「測試」之間的關系，習慣上總以為程序設計在先，測試在後，如圖1.4（a）所示。而對於一些復雜的程序，將測試分為同步測試與總測試更有效，如圖1.4（b）所示。

不論是什麼軟體工程模型，總是少不了圖1.1中的各個環節。本書擗開具體的軟體工程模型，順序講述人員管理、項目管理、可行性與需求分析、系統設計、程序設計、測試，以及維護與再生工程。其中程序設計部分以C++/C語言為例。

四、軟體體系結構和工具的選擇

軟體體系結構表示了一個軟體系統的高層結構，主要特點有：1）軟體系統結構是一個高層次上的抽象，它並不涉及具體的系統結構（比如B/S還是C/S），也不關心具體的實現。2）軟體體系結構必須支持系統所要求的功能，在設計軟體體系結構的時候，必須考慮系統的動態行為。3）在設計軟體體系結構的時候，必須考慮有現有系統的兼容性、安全性和可靠性。同時還要考慮系統以後的擴展性和伸縮性。所以有時候必須在多個不同方向的目標中進行決策。

當前已經有一些關於規范化軟體體系結構，比如：ISO的開放系統互聯模型、X Window系統等等。軟體系統的結構通常被定義為兩個部分：一個是計算部件。另一個就是部件之間的交互。如果把軟體系統看成一幅圖的話，計算部件就是其中的節點，而部件之間的交互就是節點之間的弧線。部件之間的連接可以被認為是一種連接器，比如過程調用、事件廣播、資料庫查詢等等。正確的體系結構設計是軟體系統成功的關鍵。

我們理解了軟體工程的重要性以後，我們沒有相應的工具，我們也很難很好的完成一個系統。在需求分析和設計階段，我們需要什麼樣的工具呢？

當然最好是基於UML的CASE工具。當前比較流行的就是Rose，它是一個很好的分析和建立對象和對象關系的工具。在具體編碼的時候，我們需要版本控制工具，MS的SourceSafe就是一個很好的版本管理工具和項目管理工具。具體的開發工具當然很多，但是如果你是一個對VC侵淫了多年的程序員，你一定會選擇它，因為它會讓你感到什麼是真正的面向對象的編程，而你在用VB，PowerBuilder，Delphi時很少會有同樣的感受。至於資料庫模式構建，我一向是採用Sybase的S-Design，更好的工具就不知道了。

另外需要注意的是，我們需要建立文檔編寫的若干模板，以便開發人員按照這個模板編寫規范的技術和說明文檔。幫助文檔可以用微軟的HTML Help Workshop(hhw.exe)製作，你也可以編譯成.chm格式，它打包了文本和圖形，只有一個文件，使用和分發比較方便。最後，如果開發人員不是集中在一個地方的話，最好建立一個郵件列表，開發人員可以通過郵件系統討論開發中的各項事宜。

五、軟體開發方法綜述

國外大的軟體公司和機構一直在研究軟體開發方法這個概念性的東西，而且也提出了很多實際的開發方法，比如：生命周期法、原型化方法、面向對象方法等等。下面介紹幾種流行的開發方法：

1、結構化方法

結構化開發方法是由E.Yourdon 和 L.L.Constantine 提出的，即所謂的SASD 方 法， 也可稱為面向功能的軟體開發方法或面向數據流的軟體開發方法。Yourdon方法是80年代 使用最廣泛的軟體開發方法。它首先用結構化分析（SA）對軟體進行需求分析，然後用結構化設計（SD）方法進行總體設計，最後是結構化編程（SP）。它給出了兩類典型的軟體結構（變換型和事務型）使軟體開發的成功率大大提高。

2、面向數據結構的軟體開發方法

Jackson方法是最典型的面向數據結構的軟體開發方法，Jackson方法把問題分解為可由三種基本結構形式表示的各部分的層次結構。三種基本的結構形式就是順序、選擇和重復。三種數據結構可以進行組合，形成復雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業應用中的文件表格處理。該方法也可與其它方法結合，用於模塊的詳細設計。

3、 面向問題的分析法

PAM（Problem Analysis Method）是80年代末由日立公司提出的一種軟體開發方法。 它的基本思想是考慮到輸入、輸出數據結構，指導系統的分解，在系統分析指導下逐步綜 合。這一方法的具體步驟是：從輸入、輸出數據結構導出基本處理框；分析這些處理框之間的先後關系；按先後關系逐步綜合處理框，直到畫出整個系統的PAD圖。這一方法本質上是綜合的自底向上的方法，但在逐步綜合之前已進行了有目的的分解，這個目的就是充分考慮系統的輸入、輸出數據結構。PAM方法的另一個優點是使用PAD圖。這是一種二維樹形結構圖，是到目前為止最好的詳細設計表示方法之一。當然由於在輸入、輸出數據結構與整個系統之間同樣存在著鴻溝，這一方法仍只適用於中小型問題。

4、原型化方法

產生原型化方法的原因很多，主要隨著我們系統開發經驗的增多，我們也發現並非所有的需求都能夠預先定義而且反復修改是不可避免的。當然能夠採用原型化方法是因為開發工具的快速發展，比如用VB，DELPHI等工具我們可以迅速的開發出一個可以讓用戶看的見、摸的著的系統框架，這樣，對於計算機不是很熟悉的用戶就可以根據這個樣板提出自己的需求。

開發原型化系統一般由以下幾個階段：
（1） 確定用戶需求
（2） 開發原始模型
（3） 徵求用戶對初始原型的改進意見
（4） 修改原型。

原型化開發比較適合於用戶需求不清、業務理論不確定、需求經常變化的情況。當系統規模不是很大也不太復雜時採用該方法是比較好的。

5、面向對象的軟體開發方法

當前計算機業界最流行的幾個單詞就是分布式、並行和面向對象這幾個術語。由此可以看到面向對象這個概念在當前計算機業界的地位。比如當前流行的兩大面向對象技術DCOM和CORBA就是例子。當然我們實際用到的還是面向對象的編程語言，比如C++。不可否認，面向對象技術是軟體技術的一次革命，在軟體開發史上具有里程碑的意義。

隨著OOP（面向對象編程）向OOD（面向對象設計）和OOA（面向對象分析）的發展，最終形成面向對象的軟體開發方法OMT (Object Modeling Technique）。這是一種自底向上和自頂向下相結合的方法，而且它以對象建模為基礎，從而不僅考慮了輸入、輸出數據結構，實際上也包含了所有對象的數據結構。所以OMT徹底實現了PAM沒有完全實現的目標。不僅如此，OO技術在需求分析、可維護性和可靠性這三個軟體開發的關鍵環節和質量指標上有了實質性的突破，基本地解決了在這些方面存在的嚴重問題。

綜上所述，面向對象系統採用了自底向上的歸納、自頂向下的分解的方法，它通過對對象模型的建立，能夠真正建立基於用戶的需求，而且系統的可維護性大大改善。當前業界關於面向對象建模的標準是UML（Unified Modeling Language）。

這里我們需要談一下微軟的MSF（Microsoft Solutions Framework）的框架，它簡單的把系統設計分成三個階段：概念設計、邏輯設計和物理設計。概念設計階段就是從用戶的角度出發可以得到多少個對象，並且以對象為主體，畫出業務框架。邏輯設計階段就是對概念設計階段的對象進行再分析、細分、整合、刪除。並建立各個對象的方法屬性以及對象之間的關系。而物理設計實際上就是要確定我們實際需要的組件、服務和採用的框架結構、具體的編程語言等。MCF整個結構比較清楚是基於對象開發的一個比較好的可操作的框架系統。

6、可視化開發方法

其實可視化開發並不能單獨的作為一種開發方法，更加貼切的說可以認為它是一種輔助工具，比如用過SYBASE的S-Design的人都知道，用這個工具可以進行顯示的圖形化的資料庫模式的建立，並可以導入到不同的資料庫中去。當然用過S-Design的人不一定很多，但用過VB，DELPHI，C++ Builder等開發工具的人一定不少，實際上你就是在使用可視化開發工具。

當然，不可否認的是，你只是在編程這個環節上用了可視化，而不是在系統分析和系統設計這個高層次上用了可視化的方法。實際上，建立系統分析和系統設計的可視化工具是一個很好的賣點，國外有很多工具都致力於這方面產品的設計。比如Business Object就是一個非常好的資料庫可視化分析工具。

可視化開發使我們把注意力集中在業務邏輯和業務流程上，用戶界面可以用可視化工具方便的構成。通過操作界面元素，諸如菜單、按鈕、對話框、編輯框、單選框、復選框、 列表框和滾動條等，由可視開發工具自動生成應用軟體。

六、怎樣培養軟體工程的思維與方法

作為軟體開發人員的一個通病是在項目初期的時候，就喜歡談論實現的細節，並且樂此不疲。我們更喜歡討論如何用靈活而簡短的代碼來實現一個特定的功能，而忽略了對整個系統架構的考慮。所以作為一個開發人員，尤其是一個有經驗的開發人員，應該把自己從代碼中解脫出來，更多的時候在我們的腦子里甚至暫時要放棄去考慮如何實現的問題，而從項目或產品的總體去考慮一個軟體產品。

以下是我個人的一些經驗：

1．考慮整個項目或者產品的市場前景。作為一個真正的系統分析人員，不僅要從技術的角度來考慮問題，而且還要從市場的角度去考慮問題。也就是說我們同時需要考慮我們產品的用戶群是誰，當我們產品投放到市場上的時候，是否具有生命力。比如即使我們採用最好的技術實現了一個單進程的操作系統，其市場前景也一定是不容樂觀的。

2．從用戶的角度來考慮問題。比如一些操作對於開發人員來講是非常顯而易見的問題。但是對於一般的用戶來說可能就非常難於掌握，也就是說，有時候，我們不得不在靈活性和易用性方面進行折中。另外，在功能實現上，我們也需要進行綜合考慮，盡管一些功能十分強大，但是如果用戶幾乎不怎麼使用它的話，就不一定在產品的第一版的時候就推出。從用戶的角度考慮，也就是說用戶認可的才是好的，並不是開發人員覺的好才好。

3．從技術的角度考

4. 軟體開發模型有哪幾種各有什麼特點

軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。對於不同的軟體系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟體工具和不同的軟體工程環境。軟體工程的主要環節包括人員管理、項目管理、需求分析、系統設計、程序設計、測試、維護等，如圖所示。軟體開發模型是對軟體過程的建模，即用一定的流程將各個環節連接起來，並可用規范的方式操作全過程，好比工廠的生產線。

8.混合模型（hybrid model）過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。各種模型的比較每個軟體開發組織應該選擇適合於該組織的軟體開發模型，並且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點，下表列出了幾種常見模型的優缺點。各種模型的優點和缺點：模型優點缺點瀑布模型文檔驅動系統可能不滿足客戶的需求快速原型模型關注滿足客戶需求可能導致系統設計差、效率低，難於維護增量模型開發早期反饋及時，易於維護需要開放式體系結構，可能會設計差、效率低螺旋模型風險驅動風險分析人員需要有經驗且經過充分訓練

9.RUP模型（迭代模型）

RUP（Rational Unified Process）模型是Rational公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。RUP具有兩個軸，一個軸是時間軸，這是動態的。另一個軸是工作流軸，這是靜態的。在時間軸上，RUP劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。它具有如下特點：（1）增量迭代，每次迭代都遵循瀑布模型能夠在前期控制好和解決風險；（2）模型的復雜化，需要項目管理者具有較強的管理能力。

10.IPD模型

IPD（Integrated Proct Development）流程是由IBM提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。

IPD從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是一個端到端的流程。在IPD流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點。

IPD流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對於一些小的項目，也不是非常適合使用該流程。

5. 系統分析與建模學什麼啊，以後就業方向是什麼

應該是屬於信息系統的分析設計和實施，軟體工程里有一個系統分析，就是根據甲方的實際情況，甲方的要求，對系統進行需求分析，並得出需求分析說明書，確定新系統需要的功能性能等情況。建模應該就是軟體工程里的建立物理或者邏輯模型，它是根據前面所說的需求分析說明書，確定構建系統的結構和物理實現方案。以後就業嘛，應該主要面對企事業單位從事信息系統集成與建設，基本上計算機軟體涉及到的領域都可以去試試，這個專業只是在計算機的基礎上增加了管理和會計等知識，更適合與財務系統或者金融系統等信息系統的開發而已。

6. 什麼是UML系統建模

UML
統一建模語言（UML是 Unified Modeling Language的縮寫）是用來對軟體密集系統進行可視化建模的一種語言。UML為面向對象開發系統的產品進行說明、可視化、和編制文檔的一種標准語言。

統一建模語言 (UML)是非專利的第三代建模和規約語言。 UML是在開發階段，說明，可視化，構建和書寫一個面向對象軟體密集系統的製品的開放方法。UML展現了一系列最佳工程實踐，這些最佳實踐在對大規模，復雜系統進行建模方面,特別是在軟體架構層次已經被驗證有效。

UML可以貫穿軟體開發周期中的每一個階段。被OMG採納作為業界的標准。

UML最適於數據建模，業務建模，對象建模，組件建模。

UML作為一種模型語言，它使開發人員專注於建立產品的模型和結構，而不是選用什麼程序語言和演算法實現。當模型建立之後，模型可以被UML工具轉化成指定的程序語言代碼。

IBM的Rational Rose和MS的Visio都是UML工具。
同時還有一些免費的UML工具：
http://java-source.net/open-source/uml-modeling
一. 標准建模語言UML的出現

公認的面向對象建模語言出現於70年代中期。從1989年到1994年，其數量從不到十種增加到了五十多種。在眾多的建模語言中，語言的創造者努力推崇自己的產品，並在實踐中不斷完善。但是，OO方法的用戶並不了解不同建模語言的優缺點及相互之間的差異，因而很難根據應用特點選擇合適的建模語言，於是爆發了一場「方法大戰」。90年代中，一批新方法出現了，其中最引人注目的是Booch 1993、OOSE和OMT-2等。

Booch是面向對象方法最早的倡導者之一，他提出了面向對象軟體工程的概念。1991年，他將以前面向Ada的工作擴展到整個面向對象設計領域。Booch 1993比較適合於系統的設計和構造。

Rumbaugh等人提出了面向對象的建模技術（OMT）方法，採用了面向對象的概念，並引入各種獨立於語言的表示符。這種方法用對象模型、動態模型、功能模型和用例模型，共同完成對整個系統的建模，所定義的概念和符號可用於軟體開發的分析、設計和實現的全過程，軟體開發人員不必在開發過程的不同階段進行概念和符號的轉換。OMT-2特別適用於分析和描述以數據為中心的信息系統。

Jacobson於1994年提出了OOSE方法，其最大特點是面向用例(Use-Case)，並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，但用例貫穿於整個開發過程，包括對系統的測試和驗證。OOSE比較適合支持商業工程和需求分析。

此外，還有Coad/Yourdon方法，即著名的OOA/OOD，它是最早的面向對象的分析和設計方法之一。該方法簡單、易學，適合於面向對象技術的初學者使用，但由於該方法在處理能力方面的局限，目前已很少使用。

概括起來，首先，面對眾多的建模語言，用戶由於沒有能力區別不同語言之間的差別，因此很難找到一種比較適合其應用特點的語言；其次，眾多的建模語言實際上各有千秋；第三，雖然不同的建模語言大多類同，但仍存在某些細微的差別，極大地妨礙了用戶之間的交流。因此在客觀上，極有必要在精心比較不同的建模語言優缺點及總結面向對象技術應用實踐的基礎上，組織聯合設計小組，根據應用需求，取其精華，去其糟粕，求同存異，統一建模語言。

1994年10月，Grady Booch和Jim Rumbaugh開始致力於這一工作。他們首先將Booch 93和OMT-2 統一起來，並於1995年10月發布了第一個公開版本，稱之為統一方法UM 0.8（Unitied Method）。1995年秋，OOSE 的創始人Ivar Jacobson加盟到這一工作。經過Booch、Rumbaugh和Jacobson三人的共同努力，於1996年6月和10月分別發布了兩個新的版本，即UML 0.9和UML 0.91，並將UM重新命名為UML（Unified Modeling Language）。

1996年，一些機構將UML作為其商業策略已日趨明顯。UML的開發者得到了來自公眾的正面反應，並倡議成立了UML成員協會，以完善、加強和促進UML的定義工作。當時的成員有DEC、HP、I－Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。這一機構對UML 1.0（1997年1月）及UML 1.1（1997年11月17日）的定義和發布起了重要的促進作用。

UML是一種定義良好、易於表達、功能強大且普遍適用的建模語言。它溶入了軟體工程領域的新思想、新方法和新技術。它的作用域不限於支持面向對象的分析與設計，還支持從需求分析開始的軟體開發的全過程。

面向對象技術和UML的發展過程可用上圖來表示，標准建模語言的出現是其重要成果。在美國，截止1996年10月，UML獲得了工業界、科技界和應用界的廣泛支持，已有700多個公司表示支持採用UML作為建模語言。1996年底，UML已穩占面向對象技術市場的85％，成為可視化建模語言事實上的工業標准。1997年11月17日，OMG採納UML 1.1作為基於面向對象技術的標准建模語言。UML代表了面向對象方法的軟體開發技術的發展方向，具有巨大的市場前景，也具有重大的經濟價值和國防價值。

7. 數學建模對軟體工程專業學生有用嗎

即使對工作沒有幫助，那也是開發智力、增長知識的好時機啊，何樂而不為呢？

8. 簡述兩種軟體開發建模方法及其顆心思想和相關的建模語言

經典的軟體工程思想將軟體開發分成5個階段:需求分析\系統分析與設計;系統實現\測試及維護五個階段.之所以如此,是因為軟體開發中飠含了物和人的因素,存在著很大的不確定性,這使得軟體工程不可能像理想的,可以其於物理學等的原理來做的物質生產過程.
如想建造一幢高檔的寫字樓,那麼剛開始便將一切材料和工具全准備好顯然是無比愚蠢的行為,因為有可能你正在使用他人的錢,而這些人將是建築大小,開狀和樣式的決定者,通常情況下,投資方會在開工生改變想法,這樣你必須有額外的計劃.而對於整個工程,你也許只是其中的某一個工作組,因此,你需要有各種各樣的圖紙和模型同其他小組溝通,達到聯合工作.很顯然,在客戶的需求與實際的建築技術之間找好一個契合點,是做好工程的關鍵.
許多軟體工開發過程也如同上面例子一樣,軟體問題不僅僅是代碼的問題,而成為了一個怎麼樣將整個過程轉變成一個結構,過程和工具相結合的問題.
建模,即其目的和作用在於提供系統藍圖,包含細節設計,也含有對系統的總體設計,同時模型可以幫助開發小組更好地規劃系統設計,更快的開發.
UML是一種功能強大的,面向對象的可視化系統分析的建模語言,它的各個模型可以幫助開發人員更好地理解業務流程,建立更可靠,更完善的系統模型.從而使用戶和開發人員對問題的描述達到相同的理解,以減少語義差異,保障分析的正確性.

9. 軟體工程三種演化模型的相同點和不同點

瀑布模型，演化模型（如增量模型、原型模型、螺旋模型）、噴泉模型、基於構件的開發模型和形式方法模型等。
瀑布模型（waterfall model）是1970年有W.Royce提出的，它給出了軟體生存周期活動的固定順序，上一階段的活動完成後向下一階段過渡，最終得到所開發的軟體產品。瀑布模型如下圖所示，有時也稱為軟體生存周期模型。

瀑布模型中，上一階段的活動完成並經過評審後才能開始下一階段的活動，其特徵是：
（1）接受上一階段的結果作為本階段活動的輸入。
（2）依據上一階段活動的結果實施本階段應完成的活動。
（3）對本階段的活動進行評審。
（4）將本階段活動的結果作為輸出，傳遞給下一階段。
瀑布模型是最早出現的也是應用最廣泛的過程模型，對確保軟體開發的順利進行、提高軟體項目的質量和開發效率起到重要作用。
在大量的實踐過程中，瀑布模型也逐漸暴露出它的不足。首先，客戶常常難以清楚地描述所有的要求，而且在開發過程中，用戶的需求也常常會有所變化，使得不少軟體的需求存在著不確定性；在某個活動中發現的錯誤常常是由前一階段活動的錯誤引起的，為了改正這一錯誤必須回到前一階段，這就導致了瀑布的倒流，也就是說，實際的軟體開發很少能按瀑布模型的順序沒有迴流地順流而下。其次，瀑布模型使得客戶在測試完成以後才能看到真正可運行的軟體，此時，如果發現不滿足客戶需求的問題（由於需求不確定性），那麼修改軟體的代價是巨大的。
不是任何軟體都可採用瀑布模型的，瀑布模型適合於結構化方法，也就是面向過程的軟體開發方法。軟體項目或產品選擇瀑布模型必須滿足下列條件：在開發時間內需求沒有或很少變化；分析設計人員應對應用領域很熟悉；低風險項目（對目標、環境很熟悉）；用戶使用環境很穩定；用戶除提出需求以外，很少參與開發工作。
演化模型
演化模型主要針對事先不能完整定義需求的軟體開發，其開發過程一般是首先開發核心系統，當核心系統投入運行後，軟體開發人員根據用戶的反饋，實施開發的迭代過程，每一迭代過程均由需求、設計、編碼、測試、集成等階段組成，直到軟體開發結束。演化模型在一定程度上減少了軟體開發活動的盲目性。

螺旋模型：
它是在瀑布模型和演化模型的基礎上，加入兩者所忽略的風險分析所建立的一種軟體開發模型。沿螺旋模型順時針方向，依次表達了四個方面的活動，制定計劃、風險分析、實施工程、客戶評估。

噴泉模型
它體現了軟體創建所固有的迭代和無間隙特徵，噴泉模型主要用於支持面向對象開發過程。
增量模型內容：
在設計了軟體系統整體體系結構之後，首先完整的開發系統的一個初始子集，繼之，根據這一子集，建造一個更加精細的版本，如此不斷的進行系統的增量開發。

瀑布模型、演化模型、螺旋模型之間的聯系：相同點是這三個模型都分為多個階段，而瀑布模型一次完成軟體，演化模型分為多次完成，每次迭代完成軟體的一個部分，螺旋模型也分為多次完成，每次完成軟體的一個新原型，並考慮風險分析。

演化模型和增量模型之間的區別
演化模型首先開發核心系統，每次迭代為系統增加一個子集，整個系統是增量開發和增量提交，增量模型首先完整的開發系統的一個初始子集，然後不斷的建造更精細的版本。