軟體開發過程為什麼建模
㈠ 為什麼要用UML建模之建模的重要性
從制定一點初步計劃到完成一個滿足適當功能的狗窩，可能不用別人幫助，在幾個小時內就能夠實現。只要狗窩夠大且不太漏水，狗就可以安居。假如未能達到希望的效果，返工總是可以的，無非是讓狗受點委屈。
假如想為家庭建造一所房子，備好木料、釘子和一些基本工具之後，也能開始工作，但這將需要較長的時間，並且家庭對於房子的需求肯定比狗對於狗窩的需求要多。在這種情況下，除非曾經多次建造過房子，否則就需要事先制定出一些具體的計劃，再開始動工，才能夠成功。至少應該繪制一些表明房子是什麼樣子的簡圖。假如想建造一所能滿足家庭的需要並符合當地建築規范的合格房屋，就需要畫一些建築圖，以便能想清楚房間的使用目的以及照明、取暖和水管裝置的實際細節問題。做出這些計劃後，就能對這項工作所需的時間和物料做出合理的估計。盡管自己也可能建造出這樣的房屋，但若有其他人協作，並將工程中的許多要害部分轉包出去或購買預制的材料，效率就會高得多。只要按計劃行事，不超出時間和財務的預算，家庭多半會對這新房感到滿足。假如不制定計劃，新房就不會完全令人滿足。因此，最好在早期就制定計劃，並謹慎地處理好所發生的變化。
假如你要建造一座高層辦公大廈，若還是先備好木料、釘子和一些基本工具就開始工作，那將是非常愚蠢的。因為你所使用的資金可能是別人的，他們會對建築物的規模、外形和風格做出要求。同時，他們經常會改變想法，甚至是在工程已經開工之後。由於失敗的代價太高了，因此必須要做詳盡的計劃。負責建築物設計和施工的是一個龐大的組織機構，你只是其中的一部分。這個組織將需要各種各樣的設計圖和模型，以供各方相互溝通。只要得到了合適的人員和工具，並對把建築概念轉換為實際建築的過程進行積極的治理，將會建成這座滿足使用要求的大廈。假如想繼續從事建築工作，那麼一定要在使用要求和實際的建築技術之間做好平衡，並且處理好建築團隊成員們的休息問題，既不能把他們置於風險之中，也不能驅使他們過分辛勞地工作以至於精疲力盡。
希奇的是，很多軟體開發組織開始想建造一座大廈式的軟體，而在動手處理時卻似乎他們正在倉促地造一個狗窩。
有時你是幸運的。假如在恰當的時間有足夠的合適人員，並且其他一切事情都很如意，你的團隊有可能（僅是可能）推出一個令用戶眼花繚亂的軟體產品。然而，一般的情況下，不可能所有人員都合適（合適的人員經常供不應求），時間並不總是恰當的（昨天總是更好），其他的事情也並不盡如人意（經常由不得自己）。現在對軟體開發的要求正在日益增加，而開發團隊卻還是經常單純地依靠他們唯一真正知道如何做好的一件事——編寫程序代碼。英雄式的編程工作成為這一行業的傳奇，人們似乎經常認為更努力地工作是面對開發中出現的各種危機的正常反應。然而，這未必能產生正確的程序代碼，而且一些項目是非常巨大的，無論怎樣延長工作時間，也不足以完成所需的工作。
假如真正想建造一個相當於房子或大廈類的軟體系統，問題可不是僅僅編寫許多軟體。事實上，要害是要編出正確的軟體，並考慮如何少寫軟體。要生產合格的軟體就要有一套關於體系結構、過程和工具的規范。即使如此，很多項目開始看起來像狗窩，但隨後發展得像大廈，原因很簡單，它們是自己成就的犧牲品。假如對體系結構、過程或工具的規范沒有作任何考慮，總有一天狗窩會膨脹成大廈，並會由於其自身的重量而倒塌。狗窩的倒塌可能使你的狗惱怒；同理，不成功的大廈則將對大廈的租戶造成嚴重的影響。
不成功的軟體項目失敗的原因各不相同，而所有成功的項目在很多方面都是相似的。成功的軟體組織有很多成功的因素，其中共同的一點就是對建模的採用。
建模是一項經過檢驗並被廣為接受的工程技術。建立房屋和大廈的建築模型，能幫助用戶得到實際建築物的印象，甚至可以建立數學模型來分析大風或地震對建築物造成的影響。
建模不只適用於建築業。假如不首先構造模型（從計算機模型到物理風洞模型，再到與實物大小一樣的原型），就裝配新型的飛機或汽車，那簡直是難以想像的。新型的電氣設備（從微處理器到電話交換系統）需要一定程度的建模，以便更好地理解系統並與他人交流思想。在電影業，情節串聯板是產品的核心，這也是建模的一種形式。在社會學、經濟學和商業治理領域也需要建模，以證實人們?的理論或用最小限度的風險和代價試驗新的理論。
模型是對現實的簡化。
模型提供了系統的藍圖。模型既可以包括具體的計劃，也可以包括從很高的層次考慮系統的總體計劃。一個好的模型包括那些有廣泛影響的主要元素，而忽略那些與給定的抽象水平不相關的次要元素。每個系統都可以從不同的方面用不同的模型來描述，因而每個模型都是一個在語義上閉合的系統抽象。模型可以是結構性的，強調系統的組織。它也可以是行為性的，強調系統的動態方面。
建模是為了能夠更好地理解正在開發的系統。
通過建模，要達到4個目的：
（1）模型有助於按照實際情況或按照所需要的樣式對系統進行可視化。
（2）模型能夠規約系統的結構或行為。
（3）模型給出了指導構造系統的模板。
建模並不只是針對大的系統。甚至像狗窩那樣的軟體也能從一些建模中受益。然而，可以明確地講，系統越大、越復雜，建模的重要性就越大，一個很簡單的原因是：
因為不能完整地理解一個復雜的系統，所以要對它建模。
人對復雜問題的理解能力是有限的。通過建模，縮小所研究問題的范圍，一次只著重研究它的一個方面，這就是Edsger Dijkstra幾年前講的「分而治之」的基本方法，即把一個困難問題劃分成一系列能夠解決的小問題；解決了這些小問題也就解決了這個難題。此外，通過建模可以增強人的智力。一個適當選擇的模型可以使建模人員在較高的抽象層次上工作。
任何情況下都應該建模的說法並沒有落到實處。事實上，一些研究指出，大多數軟體組織沒有做正規的建模，即使做了也很少。按項目的復雜性劃分一下建模的使用情況，將會發現：項目越簡單，採用正規建模的就越少。
這里強調的是「正規」這個詞。實際上，開發者甚至對非常簡單的項目也要做一些建模工作，雖然很不正規。開發者可能在一塊黑板上或一小片紙上勾畫出他的想法，以對部分系統進行可視化表示，或者開發組可能使用CRC卡片描述一個場景或某種機制的設計。使用任何一種這樣的模型都沒有什麼錯。假如它能行得通，就可以使用。然而，這些非正規的模型經常是太隨意了，它沒有提供一種輕易讓他人理解的共同語言。建築業、電機工程業和數學建模都有通用的建模語言，在軟體開發中使用一種共同的建模語言進行軟體建模也能使開發組織獲益匪淺。
每個項目都能從一些建模中受益。即使在一次性的軟體開發中——由於可視化編程語言的支持，可以輕而易舉地扔掉不適合的軟體。建模也能幫助開發組更好地對系統計劃進行可視化，並幫助他們正確地進行構造，使開發工作進展得更快。假如根本不建模，項目越復雜，就越有可能失敗或者構造出錯誤的東西。所有實用系統都有一個自然趨勢：隨著時間的推移變得越來越復雜。雖然今天可能認為不需要建模，但隨著系統的演化，終將會對這個決定感到後悔，但那時為時已晚。
㈡ 軟體開發過程中為什麼要建模
UML建模分為需求建模和設計建模，需求建模的目的是確定系統邊界並明確系統需要實現的功能。而設計建模主要目的是用於開發團隊中的設計思想交流；以及後續程序設計的依據；後續測試和驗收程序的依據。
UML的特點是可視化的圖形建模，表達能力強；支持面向對象開發；對各個開發階段統一設計規范和標准；易學易用。
㈢ 軟體開發模型有哪幾種各有什麼特點
軟體開發模型(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流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對於一些小的項目，也不是非常適合使用該流程。
㈣ 軟體開發過程中為什麼需要可視化,多視點的建模語言
UML建模分為需求建模和設計建模，需求建模的目的是確定系統邊界並明確系統需要實現的功能。而設計建模主要目的是用於開發團隊中的設計思想交流；以及後續程序設計的依據；後續測試和驗收程序的依據。
UML的特點是可視化的圖形建模，表達能力強；支持面向對象開發；對各個開發階段統一設計規范和標准；易學易用。
㈤ 軟體開發中有哪幾種過程模型
軟體開發過程
免費下載
鏈接:https://pan..com/s/1rgR0neDfmCzLvLV1mMNwzA
軟體開發過程（英語：software development process），或軟體過程（英語：software process），是軟體開發的開發生命周期（software
development life
cycle），其各個階段實現了軟體的需求定義與分析、設計、實現、測試、交付和維護。軟體過程是在開發與構建系統時應遵循的步驟，是軟體開發的路線圖。
㈥ 為什麼要使用軟體開發模型
軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。對於不同的軟體系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟體工具和不同的軟體工程環境。
(6)軟體開發過程為什麼建模擴展閱讀
軟體開發模型基本目標
1、開發盡可能多的軟體產品，滿足社會對軟體全方位、不同應用領域的應用需求，是軟體工程的首要目標。
2、提高軟體的生產效率。由於軟體產品的特殊性使得如何提高軟體產品的生產效率成了迫切需要解決的難題。為此，人們從各個方面研究、探討軟體產品生產的內在規律，包括生產過程的管理、組織形式、開發工具、程序設計方法等，試圖找出比較滿意的求解方案。
3、滿足應用的功能需要。這里包括幾層意思：產品功能強、性能好、按期交付使用、易於用戶操作和維護。
4、降低軟體開發成本，包括降低軟體設計成本和軟體維護成本，而軟體維護成本比開發成本要大得多。因此，提高軟體可維護性是降低軟體開發成本的有效途徑。
㈦ 在面向對象軟體的開發和設計中,為什麼要使用UML建模
uml是面向對象的分析設計方法，dfd是面向數據流的設計方法。當然uml功能強,表述容易清晰,對將來採用面向對象的實現會省很多力氣。
uml是面向對象分析方法的表達工具,涉及的圖包括用例圖,活動圖,類圖,時序圖,協作圖,狀態圖等等;可以涵蓋從需求分析到設計,編碼整個開發過程用到的模型。
dfd是面向過程分析方法的表達工具,功能大概等價於用例圖,活動圖,加上e-r模型,可以涵蓋面向過程分析(業務建模,概念建模)中所用到的模型。
㈧ 常見的軟體開發模型是什麼
演化模型、螺旋模型、噴泉模型、智能模型等。
軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。
最早出現的軟體開發模型是1970年W·Royce提出的瀑布模型。該模型給出了固定的順序，將生存期活動從上一個階段向下一個階段逐級過渡，如同流水下瀉，最終得到所開發的軟體產品，投入使用。
但計算拓廣到統計分析、商業事務等領域時，大多數程序採用高級語言(如FORTRAN、COBOL等)編寫。瀑布模式模型也存在著缺乏靈活性、無法通過並發活動澄清本來不夠確切的需求等缺點。