軟體工程建模的步驟

① 軟體過程模型的過程模型

它有時也稱為傳統生存周期模型或瀑布模型。它提出了軟體開發的系統化的、順序的方法。其流程從系統開始，隨後是需求分析、設計、編碼、測試、支持。這種模型是最早也是應用最廣泛的軟體過程模型(雖然這種模型會引起「堵賽狀態」)。
缺點：
1、實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。
2、 經常情況下客戶難以表達真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。
3、 客戶要等到開發周期的晚期才能看到程序運行的測試版本，而在這時發現大的錯誤時，可能引起客戶的驚慌，而後果也可能是災難性的。
4、採用這種線性模型，會經常在過程的開始和結束時碰到等待其他成員完成其所依賴的任務才能進行下去，有可能花在等待的時間比開發的時間要長。我們稱之為「堵賽狀態」。
優點：
1、它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該摸板下有一個共同的指導。
2、雖然有不少缺陷但比在軟體開發中隨意的狀態要好得多。 從需求收集開始，開發者和客戶在一起定義軟體的總體目標，標識已知的需求並且規劃出需要進一步定義的區域。然後是「快速設計」，它集中於軟體中那些對客戶可見的部分的表示，這將導致原型的創建，並由客戶評估並進一步精化待開發軟體的需求。逐步調整原型使其滿足客戶的需求，這個過程是迭代的。其流程從聽取客戶意見開始、隨後是建造/修改原型、客戶測試運行原型、然後回頭往復循環直到客戶對原型滿意為止。由於這種模型可以讓客戶快速的感受到實際的系統（雖然這個系統不帶有任何質量的保證），所以客戶和開發者都比較喜歡這種過程模型（對於那些僅僅用來演示軟體功能的公司而言或從來不考慮軟體質量和不害怕長期維護的公司而言）。
缺點：
1、沒有考慮軟體的整體質量和長期的可維護性。
2、大部分情況是不合適的操作演算法被採用目的為了演示功能，不合適的開發工具被採用僅僅為了它的方便，還有不合適的操作系統被選擇等等。
3、由於達不到質量要求產品可能被拋棄，而採用新的模型重新設計。
優點：
1、如果客戶和開發者達成一致協議：原型被建造僅為了定義需求，之後就被拋棄或者部分拋棄， 那麼這種模型很合適了。
2、迷惑客戶搶占市場，這是一個首選的模型。 這是一個增量型的軟體開發過程模型，強調極短的開發周期，它是線性模型的一個「高速」變種，通過使用構件的建造方法贏得了快速開發。如果需求理解的好而且約束了項目的范圍，利用這種模型可以很快的創建出功能完善的「信息系統」。其流程從業務建模開始，隨後是數據建模、過程建模、應用生成、測試及反復。RAD過程強調的是復用，復用已有的或開發可復用的構件。實際上RAD採用第四代技術。
缺點：
1、只能用於信息系統。
2、對於較大的項目需要足夠的人力資源去建造足夠的RAD組。
3、開發者和客戶必須在很短的時間完成一系列的需求分析， 任何一方配合不當都會導致RAD項目失敗。
4、這種模型對模塊化要求比較高，如果有哪一功能不能被模塊化，那麼建造RAD所需要的構件就會有問題。
5、技術風險很高的情況下不適合這種模型。
優點：
1、開發速度快，質量有保證。
2、對信息系統特別有效。 這種模型融合了線性順序模型的基本成份和原型實現模型的迭代特徵。增量模型採用隨著日程時間的進展而交錯的線性序列。每一個線性序列產生軟體的一個可發布的「增量」。當使用增量模型時，第一個增量往往是核心的產品，也就是說第一個增量實現了基本的需求，但很多補充的特徵還沒有發布。客戶對每一個增量的使用和評估，都做為下一個增量發布的新特徵和功能。這個過程在每一個增量發布後不斷從復，直到產生了最終的完善產品。增量模型強調每一個增量均發布一個可操作的產品。
缺點：
1、至始至終開發者和客戶糾纏在一起，直到完全版本出來。
優點：
1、人員分配靈活，剛開始不用投入大量人力資源，當核心產品很受歡迎時，可增加人力實現下一個增量。
2、當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑，這樣就可以先發布部分功能給客戶，對客戶起到鎮靜劑的作用。
3、具有一定的市場。 這是一個演化軟體過程模型，它將原型實現的迭代特徵和線性順序模型中控制的和系統化的方面結合起來。使得軟體的增量版本的快速開發成為可能。在螺旋模型中，軟體開發是一系列的增量發布。在每一個迭代中，被開發系統的更加完善的版本逐步產生。螺旋模型被劃分為若干框架活動，也稱為任務區域。典型地，有3到6個任務區域：
1、客戶交流：建立開發者和客戶之間有效通信所需要的任務。
2、計劃：定義資源、進度、及其它相關項目信息所需要的任務。
3、風險分析：評估技術的及管理的風險所需要的任務。
4、工程：建立應用的一個或多個表示說需要的任務。
5、構造及發布：構造、測試、安裝和提供用戶支持所需要的任務。
6、客戶評估：基於對在工程階段產生的或在安裝階段實現的軟體表示的評估，獲得客戶反饋所需要的任務。
這是一個相對較新的模型，它的功效還需要經歷若干年的使用方能確定下來。
缺點：
1、需要相當的風險分析評估的專門技術，且成功依賴於這種技術。
2、很明顯一個大的沒有被發現的風險問題，將會導致問題的發生，可能導致演化的方法失去控制。
3、這種模型相對比較新，應用不廣泛，其功效需要進一步的驗證。
優點：
1、對於大型系統及軟體的開發，這種模型是一個很好的方法。開發者和客戶能夠較好地對待和理解每一個演化級別上的風險。 螺旋模型提出了強調客戶交流的一個框架活動。該活動的目標是從客戶處誘導項目需求。在理想情況下，開發者簡單地詢問客戶需要什麼,而客戶提供足夠的細節進行下去。不幸的是這種情形很少發生。在現實中，客戶和開發者進入一個談判過程，客戶被要求在成本和應市之間的約束下平衡功能、性能、和其它產品或系統特徵。最好的談判追求「雙贏」結果，也就是說通過談判客戶獲得大部份系統的功能，而開發者則獲得現實的和可達到的預算和時限。對客戶的交流定義了下面的活動：
1、系統或子系統的關鍵「風險承擔者」的標識。
2、風險承擔者的「贏條件」的確定。
3、風險承擔者的贏條件談判，以將它們協調為一組滿足各方考慮的雙贏條件。
缺點：
1、需要額外的談判技巧。
優點：
1、客戶和開發者達到一種平衡。 這種模型關注於多個任務的並發執行，表示為一系列的主要技術活動、任務及它們的相關狀態。並發過程模型是由客戶要求、管理決策、評審結果驅動的。該模型不是將軟體工程活動限定為一個順序的事件序列，而是定義了一個活動網路。網路上的每一個活動均可於其它活動同時發生。這種模型可以提供一個項目的當前狀態的准確視圖。
缺點：暫時無
優點：
1、可用於所有類型的軟體開發，而對於客戶/伺服器結構更加有效。
2、可以隨時查閱到開發的狀態。 面向對象的技術為軟體工程的基於構件的過程模型提供了技術框架。面向對象模型強調了類的創建、類的封裝了的數據、操縱該數據的演算法。一般來講經過合適的設計和實現，面向對象的類可以在不同的應用及基於計算機的系統的體系結構中復用。基於構件的開發模型融合了螺旋模型的許多特徵，它本質上是演化形的，要求軟體創建的迭代方法。然而基於構件的開發模型是利用預先包裝好的軟體構件（有時成為類）來構造應用。
開發活動從候選類的標識開始，這一步是通過檢查將被應用系統操縱的數據及用於實現該操縱的演算法來完成的。相關的數據和演算法被封裝成一個類。
缺點：
1、過分依賴於構件，構件庫的質量影響著產品質量。
優點：
1、構件可復用。提高了開發效率。
2、採用了面向對象的技術。 形式化方法模型包含了一組活動，他們導致了計算機軟體的數學規約。形式化方法使得軟體工程師們能夠通過應用一個嚴格的數學符號體系來規約、開發、和驗證基於計算機的系統。 這種方法的一個變種，稱為凈室軟體工程，已經被一些組織所採用。在開發中使用形式化方法時，它們提供了一種機制，能夠消除使用其它軟體過程模型難以克服的很多問題。二義性、不完整性、不一致性能被更容易地發現和糾正，而不是通過專門的評審，是通過對應用的數學分析。 形式化方法提供了可以產生無缺陷軟體的承諾。
缺點：
1、開發費用昂貴（對開發人員需要多方面的培訓），而且需要的時間較長。
2、不能將這種模型作為對客戶通信的機制，因為客戶對這些數學語言一無所知。
3、還不流行。
優點：
1、形式化規約可直接作為程序驗證的基礎，可以盡早的發現和糾正錯誤（包括那些其它情況下不能發現的錯誤）。
2、開發出來的軟體具有很高的安全性和健壯性，特別適合安全部門或者軟體錯誤會造成經濟損失的開發者。
3、具有開發無缺陷軟體的承諾。 一系列的軟體工具的使用，是第四代技術的特點。這些工具有一個共同的特點：能夠使軟體工程師們在較高級別上規約軟體的某些特徵，然後根據開發者的規約自動生成源代碼。我們知道，軟體在越高的級別上被規約，就越能被快速的建造出程序。軟體工程的
4GT模型集中於規約軟體的能力：使用特殊的語言形式或一種採用客戶可以理解的術語描述待解決問題的圖形符號體系。和其它模型一樣，4GT也是從需求收集這一步開始的，要將一個4GT實現變成最終產品，開發者還必須進行徹底的測試、開發有意義的文檔，並且同樣要完成其它模型中同樣要求的所有集成活動。總而言之，4GT已經成為軟體工程的一個重要方法。特別是和基於構件的開發模型結合起來時，4GT模型可能成為當前軟體開發的主流模型！
缺點：
1、用工具生成的源代碼可能是「低效」的。
2、生成的大型軟體的可維護性還令人懷疑。
3、在某些情況下可能需要更多的時間。
優點：
1、縮短了軟體開發時間，提高了建造軟體的效率。
2、對很多不同的應用領域提供了一種可行性途徑和解決方案

② 什麼是軟體過程建模

這個問題好像是軟體工程里的

③ 軟體工程順序圖怎麼畫

1. 在VP官網下載 Simple-Registration.vpp 。
2. 在Visual Paradigm中打開已下載的vpp文件。通過工具欄中的 Project > Open 可打開這個項目。
3. 打開類圖 Registration ，通過對圖表內容的查看，我們了解到這里有三個類——RegistrationUI 、 RegistrationController 和 User 。

4. 現在我們想要對在運行時這些類的對象實例間的交互進行建模。由於控制器類負責控制登記流程，因此添加一個它的子順序圖。將滑鼠指針移動到 RegistrationController ，點擊底部右下角的資源圖標然後從彈出菜單中選擇 New Diagram... 。

5. 在 New Diagram 窗口，選擇 Sequence Diagram ，然後點擊 Next 。保持默認圖標名稱不變，然後點擊 OK 進行確認。

6. 一個空的UML順序圖創建以後，從圖表工具欄中選擇 Boundary LifeLine (B) 。

7. 點擊圖表創建生命線的分界線。

8. 輸入 registrationUI 作為生命線名稱，然後敲擊回車鍵進行確認。

9. 右鍵點擊生命線，然後從彈出菜單中選擇 elect Class > Select Class... 。

10. 在 Select Class 窗口，選擇 RegistrationUI 類，然後點擊 OK 進行確認。

然後所繪制的生命線就：

11. 創建一個控制生命線（ Control LifeLine ）： registrationController : RegistrationController 和一個實體生命線（Entity LifeLine）： user : User 。不要忘了為它們選擇合適的類。所繪制的圖表如下圖所示：

12. 讓我們為生命線之間所調用的方法進行建模，將滑鼠指針移動到生命線 registrationUI 。

13. 按住資源 Resource Catalog ，然後進行拖動。

14. 移動到生命線 registrationController ，然後釋放滑鼠按鈕。

15. 從Resource Catalog中選擇 Message 。

16. 這會彈出一個可供你選擇的新的序列信息的列表名稱。你可以看到這些選項都是classRegistrationController的操作，在其中選擇 createUser(name, password) 。

17. 關聯生命線 registrationController 和 user ，我們可以看到是 registrationController 創建了user生命線。因此，我們需要創建一條信息來關聯這兩者。將滑鼠指針移動激活生命線 registrationController 。

18. 按住資源 Resource Catalog 進行拖動。
19. 在生命線 user 處放開滑鼠指針。
20. 從Resource Catalog中選擇 Create Message 。

於是信息就被創建好了，所得的圖像如下圖所示：

21. 創建從生命線 registrationController 到user的信息 setName 和 setPassword ，到目前為止，圖表如下圖所示：

22. 您還可以指定操作的參數，以信息 createUser(name, password) 為例。右鍵點擊它，然後從下拉菜單中選擇 Open Specification... 。

23. 通過點擊按鈕上的省略號對行為屬性進行編輯，跳轉到 Action type 。

24. 在 Call Action Specification 窗口，點擊 Add > Text... 添加參數。在本例中，點擊 Add > Text... 添加參數 peter 。再次點擊 Add > Text... 添加參數 mypwd 。注意，這里的兩個參數指的是兩個通過操作賦予的參數，如果你再添加第三個參數，它將被自動忽略（因為只定義了兩個操作）。

25. 點擊 OK 關閉窗口，然後返回圖表。添加的參數被呈現在了圖表上

④ 軟體過程模型的總結

過程模型總分為五大類：
1.慣例過程模型。
2.瀑布模型(又叫作生命周期模型)。
3.增量過程模型: 包括增量模型、RAD模型。
4.演化過程模型: 包括 原型開發模型、螺旋模型、協同開發模型。
5.專用過程模型: 包括 基於構件的開發模型、形式化方法模型、面向方面的軟體開發模型。
(參考文獻:軟體工程-實踐者的研究方法 (美)Poger S.Pressman )

⑤ 軟體工程過程的介紹

本書以UPEDU軟體工程過程作為具體的過程實例，全面介紹軟體工程過程的基本知識，闡述了一系列助於在更短的時間內開發出更好的軟體的活動。全書分4個部分：第I部分介紹了軟體過程的基本問題，即軟體生命周期的方法、工具和概念；第II部分和第III部分主要介紹軟體工程規范和管理規范；第IV部分介紹軟體工程過程的質量和建模問題，最後一章介紹了軟體工程元模型，它是所有軟體過程的理論基礎。

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

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

⑦ 軟體設計的基本步驟是什麼

軟體開發是指一個軟體項目的開發，如市場調查，需求分析，可行性分析，初步設計，詳細設計，形成文檔，建立初步模型，編寫詳細代碼，測試修改，發布等。

軟體是怎麼樣開發出來的

第一個步驟是市場調研，技術和市場要結合才能體現最大價值。

第二個步驟是需求分析，這個階段需要出三樣東西，用戶視圖，數據詞典和用戶操作手 冊。

用戶視圖 是該軟體用戶（包括終端用戶和管理用戶）所能看到的頁面樣式，這裡麵包含了 很多操作方面的流程和條件。

數據詞典 是指明數據邏輯關系並加以整理的東東，完成了數據詞典，資料庫的設計就完成了一半多。

用戶操作手冊是指明了操作流程的說明書。

請注意，用戶操作流程和用戶視圖是由需求決定的，因此應該在軟體設計之前完成，完成這些，就為程序研發提供了約束和准繩，很遺憾太多公司都不是這樣做的，因果顛倒，順序不分，開發工作和實際需求往往因此產生隔閡脫節的現象。

需求分析，除了以上工作，筆者以為作為項目設計者應當完整的做出項目的性能需求說明 書，因為往往性能需求只有懂技術的人才可能理解，這就需要技術專家和需求方（客戶或公司市場部門）能夠有真正的溝通和了解。

第三個步驟是概要設計，將系統功能模塊初步劃分，並給出合理的研發流程和資源要求。
作為快速原型設計方法，完成概要設計就可以進入編碼階段了，通常採用這種方法是因為涉及的研發任務屬於新領域，技術主管人員一上來無法給出明確的詳細設計說明書，但是 並不是說詳細設計說明書不重要，事實上快速原型法在完成原型代碼後，根據評測結果和 經驗教訓的總結，還要重新進行詳細設計的步驟。

第四個步驟是詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把 具體的模塊以最』干凈』的方式(黑箱結構）提供給編碼者，使得系統整體模塊化達到最 大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低，實際上，嚴格的講詳細 設計說明書應當把每個函數的每個參數的定義都精精細細的提供出來，從需求分析到概要 設計到完成詳細設計說明書，一個軟體項目就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行代碼工作。

那些把作軟體的程序員簡單理解為寫代碼的，就從根子上犯了錯誤了。

第五個步驟是編碼，在規范化的研發流程中，編碼工作在整個項目流程里最多不會超過1/ 2，通常在1/3的時間，所謂磨刀不誤砍柴功，設計過程完成的好，編碼效率就會極大提 高，編碼時不同模塊之間的進度協調和協作是最需要小心的，也許一個小模塊的問題就可能影響了整體進度，讓很多程序員因此被迫停下工作等待，這種問題在很多研發過程中都 出現過。
編碼時的相互溝通和應急的解決手段都是相當重要的，對於程序員而言，bug永 遠存在，你必須永遠面對這個問題，大名鼎鼎的微軟，可曾有連續三個月不發補丁的時候 嗎？從來沒有！

第六個步驟是測試

測試有很多種：

按照測試執行方，可以分為內部測試和外部測試

按照測試范圍，可以分為模塊測試和整體聯調

按照測試條件，可以分為正常操作情況測試和異常情況測試

按照測試的輸入范圍，可以分為全覆蓋測試和抽樣測試

以上都很好理解，不再解釋。

總之，測試同樣是項目研發中一個相當重要的步驟，對於一個大型軟體，3個月到1年的外部測試都是正常的，因為永遠都會又不可預料的問題存在。

完成測試後，完成驗收並完成最後的一些幫助文檔，整體項目才算告一段落，當然日後少不了升級，修補等等工作，只要不是想通過一錘子買賣騙錢，就要不停的跟蹤軟體的運營 狀況並持續修補升級，直到這個軟體被徹底淘汰為止。

什麼是軟體開發的核心問題

按照軟體工程鼻祖，《人月神話》作者 Brooks 在「沒有銀彈——軟體工程中的根本和次要問題」一章中闡述的思想，軟體開發的核心問題就是如何從概念上對一個復雜的業務系統進行建模。這個建模是含義廣泛的，不僅僅包括對象建模，還包括數據建模、演算法建模等等一系列的內容。總而言之是要先找到解決復雜問題的突破口（先要搞明白需要做什麼，然後再考慮如何做）。至於採用什麼表示方法（簡單文本、UML 圖、E-R 圖）、採用什麼高級語言、是否一定要用面向對象、使用什麼開發工具都是次要的問題。

軟體開發方法

軟體開發方法(Software Development Method)是指軟體開發過程所遵循的辦法和步驟。
軟體開發活動的目的是有效地得到一些工作產物，也就是一個運行的系統及其支持文檔，並且滿足有關的質量要求。軟體開發是一種非常復雜的腦力勞動，所以經常更多討論的是軟體開發方法學，指的是規則、方法和工具的集成，既支持開發，也支持以後的演變過程(交付運行後，系統還會變化，或是為了改錯，或是為了功能的增減)。

關於組成軟體開發和系統演化的活動有著各種模型(參見軟體生存周期，軟體開發模型，軟體過程)，但是典型地都包含了以下的過程或活動：分析、設計、實現、確認(測試驗收)、演化(維護)。

有些軟體開發方法是專門針對某一開發階段的，屬於局部性的軟體開發方法。
特別是軟體開發的實踐表明，在開發的早期階段多做努力，在後來的測試和維護階段就會使費用較大地得以縮減。因此，針對分析和設計階段的軟體開發方法特別受到重視。其它階段的方法，從程序設計發展的初期起就是研究的重點，
已經發展得比較成熟(參見程序設計，維護過程)。除了分階段的局部性軟體開發方法之外，還有覆蓋開發全過程的全局性方法，尤為軟體開發方法學注意的重點。

對軟體開發方法的一般要求：當提出一種軟體開發方法時，應該考慮許多因素，包括：

①覆蓋開發全過程，並且便於在各階段間的過渡；

②便於在開發各階段中有關人員之間的通信；

③支持有效的解決問題的

④支持系統設計和開發的各種不同途徑；

⑤在開發過程中支持軟體正確性的校驗和驗證；

⑥便於在系統需求中列入設計、實際和性能的約束；

⑦支持設計師和其他技術人員的智力勞動；

⑧在系統的整個生存周期都支持它的演化；

⑨受自動化工具的支持。此外，在開發的所有階段，有關的軟體產物都應該是可見和可控的；軟體開發方法應該可教學、可轉移，還應該是開放的，即可以容納新的技術、管理方法和新工具，並且與已有的標准相適應。