軟件開發是什么,?該怎么做？

1??引子

關于什么是軟件開發存在很多觀點，有的認為軟件開發即服務，有的認為軟件開發即產品，有的認為軟件開發即平臺，這些觀點各有各的側重點。這篇文章我們來學習和探討一下軟件開發。

2??軟件開發

軟件開發是指在創建和維護應用程序、框架或其他軟件組件的過程中所涉及的構思、設定、設計、編程、記錄、測試和修正錯誤的過程。

軟件開發是一個編寫和維護源代碼的過程，但從廣義上講，它包括了從構思所需的軟件到軟件的最終表現形式之間的所有活動，一般來說是一個有計劃、有組織的過程。因此，軟件開發可以包括研究、新開發、原型設計、修改、再利用、再設計、維護或其他任何關聯軟件產品生產的活動。

??? 軟件可以為各種目的而開發，最常見的三種情況是滿足特定客戶和企業的特定需求(定制軟件的情況)、滿足某些潛在用戶的某種需求(商業和開放源碼軟件的情況)或個人使用(例如，科學家可以編寫軟件來自動完成一項常規的任務)。比如，嵌入式軟件開發，可用于控制消費類產品的嵌入式軟件的開發，它要求開發過程與被控物理產品的開發相結合。系統軟件是應用軟件和編程過程本身的基礎，往往是單獨開發的。

??? 為了更好地對軟件開發過程進行質量控制的需要，軟件工程學科應運而生，它的目的是將工程范式中的系統化方法應用到軟件開發過程中。

??? 軟件項目管理的方法有很多，可以被稱為軟件開發生命周期模型、方法論、過程或模型。瀑布模型是傳統的軟件開發模式，與近來創新的敏捷軟件開發模式形成鮮明對比。

2.1??方法論

軟件開發方法是一種用于對信息系統開發過程進行結構化、計劃和控制的框架。多年來，這種框架的種類繁多，每一種框架都有其公認的優點和缺點。

軟件開發有幾種不同的方法：有些人采取更有結構化的、以工程為基礎的方法來開發業務解決方案，而另一些人則可能采取更多的增量方法，即軟件在逐個開發的過程中不斷發展。一種系統開發方法不一定適合所有項目使用。基于技術、組織、項目和團隊的各種考慮，每一種可用的方法都最適合于特定類型的項目。

大多數方法論在軟件開發的以下幾個階段中都有一定的組合:

·????????分析問題

·????????市場調查

·????????收集擬議的業務解決方案的需求

·????????為基于軟件的解決方案制定計劃或設計

·????????軟件的實施(編碼)

·????????測試軟件

·????????部署情況

·????????維護和錯誤修復

這些階段通常被統稱為軟件開發生命周期，即SDLC。不同的軟件開發方法可能以不同的順序進行這些階段，或將更多或更少的時間用于不同的階段。

軟件開發的每個階段所產生的文檔的詳細程度也可能不同。這些階段也可以依次進行(如"瀑布式")，或者在不同的周期或迭代中重復進行(如"極端編程")。極端編程的方法通常花在計劃和文檔上的時間較少，而花在編碼和開發自動化測試上的時間較多。

極端編程方法也促進了在整個開發生命周期內的持續測試，以及確保在任何時候都有一個可工作(或無BUG)的產品。

結構化或?"瀑布式"的方法試圖在編碼開始前評估大部分的風險，并制定詳細的軟件計劃，避免在軟件開發生命周期規劃的后期階段進行重大的設計變更和重新編碼。

各種方法都有明顯的優點和缺點，用軟件解決問題的最佳方法往往取決于問題的類型。如果對問題有很好的理解，并且可以提前有效地規劃出解決方案，那么基于?"瀑布式 "的方法可能效果最好。另一方面，如果問題是獨一無二的(至少對開發團隊來說是獨一無二的)，而且軟件解決方案的結構不容易設想，那么"極端編程"的增量方法可能是最好的。

2.2??軟件開發活動

2.2.1??確定需求

軟件產品的創意來源是非常豐富的。這些創意可以來自市場調查，包括潛在新客戶的人口統計、現有客戶、拒絕產品的人群的分析、其他內部軟件開發人員或有創意的第三方。軟件產品的創意通常首先由營銷人員評估經濟可行性、與現有渠道分銷的契合度、對現有產品線可能產生的影響、所需的功能、與公司的營銷目標的契合度。在營銷評估階段，成本和時間假設成為評估的內容。在第一階段的早期，根據營銷和開發人員所得到的更詳細的信息，決定是否要進一步推進該項目。

在《偉大的軟件辯論》一書中，AlanM. Davis在 "需求 "一章的"需求"小節"的軟件開發中缺失的部分"中指出:

學工科的學生學的是工科，很少接觸到金融或者是市場營銷。市場營銷專業的學生學的是市場營銷，很少接觸到金融或工程。我們中的大多數人只成為了一個領域的專家。更為復雜的是，我們很少有人在職場上遇到跨學科的人，我們沒有更多的資源可以借鑒。然而，軟件產品策劃是開發成功的關鍵，這絕對需要多個學科的知識。

由于軟件開發可能會涉及到妥協于或超出客戶的要求，因此軟件開發項目可能會游離于技術性較差的領域，如人力資源、風險管理、知識產權、預算編制、危機管理等。這些過程也可能導致業務開發與軟件開發的作用重疊。

2.2.2??規劃

創建軟件程序的一個重要任務是提取需求或需求分析，客戶通常對他們想要的最終結果有一個抽象的想法，但不知道軟件應該做什么。熟練而有經驗的軟件工程師會在這一點上認識到不完整的、模糊的、甚至是相互矛盾的需求。

雖然在需求階段投入了大量的精力來確保需求的完整和一致性，但現實中很難做到這一點。需求的波動性對軟件開發很有挑戰性，因為它們會影響到未來或正在進行中的開發工作。

一旦從客戶那里收集到一般需求，就應該確定并明確說明開發的范圍分析。這通常被稱為范圍文件。

2.2.3??設計

需求確定后，可以在軟件設計文檔中確定軟件的設計。這涉及到主要模塊的初步設計或高級設計，并對各部分如何組合在一起進行總體規劃。語言、操作系統和硬件組件在這時都應該是已知的。接下來就是創建一個詳細的或低級的設計，可能是作為概念驗證或確定需求的原型設計。

功能實現、測試和記錄

功能實現是軟件工程師實際為項目編寫代碼的過程中的一個部分。

軟件測試是軟件開發過程中不可或缺的重要階段。這一部分的過程確保了缺陷盡快被識別出來。在某些過程中，通常被稱為測試驅動開發，測試可能就在功能實現之前就已經制定好了，并作為驗證功能實現的方法。

在整個開發過程中，對軟件的內部設計進行文檔化，以便于將來的維護和改進。這包括編寫外部的和內部的API文檔。開發團隊所選擇的軟件工程過程將決定有多少內部文檔是必要的。計劃驅動的模式(例如，瀑布模式)通常比敏捷模式產生的文檔多。

2.2.4??部署和維護

在代碼經過適當的測試、批準發布、銷售或以其他方式分發到生產環境后，部署工作就直接開始了。這可能涉及到安裝、定制(如將參數設置為客戶所需要的值)、測試，以及可能的評估期延長。

軟件的培訓和支持很重要，因為只有正確使用軟件才能達到預期的目的。

維護和改進軟件以應對新發現的故障或需求，可能需要花費大量的時間和精力，因為錯過的需求或者新的需求可能會導致軟件的重新設計。

在大多數情況下，需要定期維護，并修復報告的問題來保持軟件的正常運行。

2.3??軟件開發相關主題

2.3.1??視圖模型

??? 視圖模型是一個框架，它提供了關于系統及其環境的相互關系。

??? 觀察點和視圖的目的是為了使人類工程師能夠理解非常復雜的系統，并圍繞專業領域組織問題的要素和解決方案。在物理密集型系統的工程中，觀點往往與工程組織中的能力和責任相對應。

大多數復雜的系統規范非常的廣泛，沒有一個人能夠完全理解規范的所有方面。

此外，我們都對某一系統有不同的側重點，也有不同的原因來研究系統的規范。一個業務主管會和一個系統的功能實現者會對系統的構成提出不同的問題。因此，觀察點框架的概念是將不同的觀察點提供給定復雜系統的規范。

這些觀察點分別滿足了對系統的某些方面感興趣的受眾。與每個觀察點相關聯的是一種觀察點共識語言，它為該觀察點的受眾提供了交流方式。

2.3.2??業務流程和數據建模

??? 使用圖形化的方式來表示信息的現狀為用戶和系統開發人員提供了一種非常有效的信息呈現方式。

·????????業務模型說明了與被建模的業務流程相關的功能和執行這些功能的組織。通過描述活動和信息流，為可視化、定義、理解以及驗證流程奠定了基礎。

·????????數據模型提供了要存儲的信息的細節，這些模型可以為自己編寫還是購買軟件產品提供依據。

通常情況下，在進行后建立一個模型，稱為業務分析。編程范式包括主持人提出一系列問題，旨在提取描述一個過程所需的信息。訪談者被稱為主持人，用以引導參與者提供信息。主持人應該對所關心的過程有一定的了解。

因為通常是由一個主持人團隊在整個設施內收集信息，所有訪談者的信息結果必須在完成后整合在一起，這個時候使用合適的方法論很重要。

這些模型的建立，要么定義了流程的當前狀態，最終產品被稱為"現況"快照模型，要么是流程應包含哪些內容的想法的集合，從而形成了"可能的"模型。

流程和數據模型的生成可以用來判斷現有的流程和信息系統是否健全，只需要稍作修改或增強，或者作為糾正措施，是否需要重新設計。業務模型的建立不僅僅是查看或自動化信息流程的一種方法。分析可以用來從根本上重塑你的企業或組織的運營方式。

2.3.3??計算機輔助軟件工程

計算機輔助軟件工程(Computer-aidedsoftware engineering，簡稱CASE)，在軟件工程領域，是指將一套軟件工具和方法科學地應用到軟件開發中，從而獲得高質量、無缺陷、可維護的軟件產品，也是指在軟件開發過程中，與自動化工具一起用于信息系統開發的方法。

CASE的功能包括分析、設計和編程等。CASE工具用所需的編程語言自動設計、記錄和制作結構化的計算機代碼的方法。

??? 計算機輔助軟件系統工程(CASE)的兩個重要思想是：

·????????培養軟件開發和軟件維護過程中的計算機協助，以及

·????????培養軟件開發和維護的一種工程化方法。

典型的CASE工具有配置管理、數據建模、模型轉換、重構、源碼生成等。

2.3.4??集成開發環境

??? 集成開發環境(IDE)又稱為集成設計環境或集成調試環境，是指為計算機程序員提供軟件開發的綜合設施的軟件應用。一個集成開發環境通常由以下幾個部分組成:

·??????????源代碼編輯器。

·??????????編譯器或解釋器。

·??????????構建自動化工具，以及

·??????????調試器(通常)。

??? IDE的設計目的是通過提供具有類似用戶界面的緊密組件來最大限度地提高程序員的工作效率。通常情況下，IDE是專門針對特定的編程語言而設計的，以便提供最符合該語言編程范式的功能集。

2.3.5??建模語言

??? 建模語言是指任何可以用來表達信息、知識或系統的人工語言，它是由一組一致的規則定義的結構。這些規則用于解釋結構中各組成部分的意義。建模語言可以是圖形化的，也可以是文本化的，圖形化的建模語言使用圖式技術，用命名的符號表示概念，用線來表示關系，用各種其他圖形注釋來表示約束。文本建模語言通常使用標準化的關鍵字跟參數來構建計算機可理解的表達。

??? 軟件工程領域中的圖形建模語言的例子有：

·??????????業務流程建模語言(BPMN，和XML形式的BPML)是流程建模語言的一個例子。

·??????????EXPRESS和EXPRESS-G(ISO 10303-11)是一種國際標準的通用數據建模語言。

·??????????擴展企業建模語言(Extended Enterprise Modeling Language，EEML)常用于跨層業務流程建模。

·??????????流程圖是一種算法或分步流程的示意圖。

·??????????基本建模概念(FMC)建模語言，用于軟件密集型系統的建模語言。

·??????????IDEF是一個建模語言家族，其中最著名的有IDEF0用于功能建模，IDEF1X用于信息建模，IDEF5用于本體建模。

·??????????LePUS3是一種面向對象的可視化設計描述語言，也是一種正式的規范語言，主要適用于大型面向對象(Java、C++、C#)程序和設計模式的建模。

·??????????規范和描述語言(SDL)旨在對反應式和分布式系統的行為進行明確的規范和描述。

·??????????統一建模語言(Unified Modeling Language，UML)是一種通用的建模語言，是指定軟件密集型系統的行業標準。當前版本的UML 2.0支持13種不同的圖示技術，并有廣泛的工具支持。

??? 并非所有的建模語言都是可執行的，對于那些可執行的建模語言，使用它們并不一定意味著不再需要程序員。恰恰相反，可執行的建模語言旨在提高程序員的工作效率，使他們能夠解決更多的難題，如并行計算和分布式系統等。

2.3.6??編程范式

??? 編程范式是計算機程序設計的一種基本風格，它一般不受項目管理方法(如瀑布式或敏捷)的支配。范式在用于表示程序元素(如對象、函數、變量、約束)和構成計算的步驟(如分配、評估、延續、數據流)的概念和抽象上有所不同。有時，范式所斷言的概念在高級系統架構設計中被協同使用；在其他情況下，編程范式的范圍僅限于特定程序或模塊的內部結構。

一種編程語言可以支持多種范式。例如，用C++或Object Pascal編寫的程序可以是純程序化的，也可以是純面向對象的，或者包含兩種范式的元素。軟件設計者和程序員決定如何使用這些范式元素。

在面向對象編程中，程序員可以把程序看成是一個交互對象的集合，而在功能編程中，程序可以看成是一個無狀態的函數評價序列。當計算機或具有許多處理器的系統編程時，面向過程的程序設計允許程序員將程序看作是一組并發的進程，并在邏輯上共享的數據結構上起作用。

??? 正如軟件工程中不同的群體主張不同的方法論一樣，不同的編程語言也主張不同的編程范式。有些語言的設計是為了支持一種范式(Smalltalk支持面向對象編程，Haskell支持功能編程)，而其他編程語言則支持多種范式(如ObjectPascal、C++、C#、VisualBasic、Common Lisp、Scheme、Python、Ruby和Oz)。

許多編程范式都是以其禁止什么方法而聞名，或者是以其啟用什么方法而聞名。例如，純函數式編程禁止使用跨范圍修改；結構化編程禁止使用?goto 語句。

新的范式往往被習慣于早期風格的人認為是教條主義的，或者是過于僵化。

高級別的范式的例子包括：

·??????????面向方面的軟件開發

·??????????特定領域的建模

·??????????模型驅動的工程

·??????????面向對象的編程方法

GradyBooch的面向對象設計(OOD)，又稱面向對象分析與設計(OOAD)。Booch模型包括類、對象、狀態過渡、交互、模塊、過程六張圖。

·??????????基于搜索的軟件工程

·??????????面向服務的建模

·??????????結構化的程序設計

·??????????自上而下和自下而上的設計