1 引子

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

2 軟件開發(fā)

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

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

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

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

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

2.1 方法論

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

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

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

· 分析問題

· 市場調(diào)查

· 收集擬議的業(yè)務解決方案的需求

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

· 軟件的實施（編碼）

· 測試軟件

· 部署情況

· 維護和錯誤修復

這些階段通常被統(tǒng)稱為軟件開發(fā)生命周期，即SDLC。不同的軟件開發(fā)方法可能以不同的順序進行這些階段，或?qū)⒏嗷蚋俚臅r間用于不同的階段。

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

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

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

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

2.2 軟件開發(fā)活動

2.2.1 確定需求

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

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

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

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

2.2.2 規(guī)劃

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

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

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

2.2.3 設計

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

功能實現(xiàn)、測試和記錄

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

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

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

2.2.4 部署和維護

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

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

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

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

2.3 軟件開發(fā)相關主題

2.3.1 視圖模型

視圖模型是一個框架，它提供了關于系統(tǒng)及其環(huán)境的相互關系。

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

大多數(shù)復雜的系統(tǒng)規(guī)范非常的廣泛，沒有一個人能夠完全理解規(guī)范的所有方面。

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

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

2.3.2 業(yè)務流程和數(shù)據(jù)建模

使用圖形化的方式來表示信息的現(xiàn)狀為用戶和系統(tǒng)開發(fā)人員提供了一種非常有效的信息呈現(xiàn)方式。

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

· 數(shù)據(jù)模型提供了要存儲的信息的細節(jié)，這些模型可以為自己編寫還是購買軟件產(chǎn)品提供依據(jù)。

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

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

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

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

2.3.3 計算機輔助軟件工程

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

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

計算機輔助軟件系統(tǒng)工程（CASE）的兩個重要思想是：

· 培養(yǎng)軟件開發(fā)和軟件維護過程中的計算機協(xié)助，以及

· 培養(yǎng)軟件開發(fā)和維護的一種工程化方法。

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

2.3.4 集成開發(fā)環(huán)境

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

· 源代碼編輯器。

· 編譯器或解釋器。

· 構建自動化工具，以及

· 調(diào)試器（通常）。

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

2.3.5 建模語言

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

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

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

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

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

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

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

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

· LePUS3是一種面向?qū)ο蟮目梢暬O計描述語言，也是一種正式的規(guī)范語言，主要適用于大型面向?qū)ο螅↗ava、C++、C#）程序和設計模式的建模。

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

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

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

2.3.6 編程范式

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

一種編程語言可以支持多種范式。例如，用C++或Object Pascal編寫的程序可以是純程序化的，也可以是純面向?qū)ο蟮模蛘甙瑑煞N范式的元素。軟件設計者和程序員決定如何使用這些范式元素。

在面向?qū)ο缶幊讨?，程序員可以把程序看成是一個交互對象的集合，而在功能編程中，程序可以看成是一個無狀態(tài)的函數(shù)評價序列。當計算機或具有許多處理器的系統(tǒng)編程時，面向過程的程序設計允許程序員將程序看作是一組并發(fā)的進程，并在邏輯上共享的數(shù)據(jù)結構上起作用。

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

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

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

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

· 面向方面的軟件開發(fā)

· 特定領域的建模

· 模型驅(qū)動的工程

· 面向?qū)ο蟮木幊谭椒?/FONT>