1 引子

關(guān)于什么是軟件開(kāi)發(fā)存在很多觀點(diǎn)，有的認(rèn)為軟件開(kāi)發(fā)即服務(wù)，有的認(rèn)為軟件開(kāi)發(fā)即產(chǎn)品，有的認(rèn)為軟件開(kāi)發(fā)即平臺(tái)，這些觀點(diǎn)各有各的側(cè)重點(diǎn)。這篇文章我們來(lái)學(xué)習(xí)和探討一下軟件開(kāi)發(fā)。

2 軟件開(kāi)發(fā)

軟件開(kāi)發(fā)是指在創(chuàng)建和維護(hù)應(yīng)用程序、框架或其他軟件組件的過(guò)程中所涉及的構(gòu)思、設(shè)定、設(shè)計(jì)、編程、記錄、測(cè)試和修正錯(cuò)誤的過(guò)程。

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

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

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

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

2.1 方法論

軟件開(kāi)發(fā)方法是一種用于對(duì)信息系統(tǒng)開(kāi)發(fā)過(guò)程進(jìn)行結(jié)構(gòu)化、計(jì)劃和控制的框架。多年來(lái)，這種框架的種類繁多，每一種框架都有其公認(rèn)的優(yōu)點(diǎn)和缺點(diǎn)。

軟件開(kāi)發(fā)有幾種不同的方法：有些人采取更有結(jié)構(gòu)化的、以工程為基礎(chǔ)的方法來(lái)開(kāi)發(fā)業(yè)務(wù)解決方案，而另一些人則可能采取更多的增量方法，即軟件在逐個(gè)開(kāi)發(fā)的過(guò)程中不斷發(fā)展。一種系統(tǒng)開(kāi)發(fā)方法不一定適合所有項(xiàng)目使用?；诩夹g(shù)、組織、項(xiàng)目和團(tuán)隊(duì)的各種考慮，每一種可用的方法都最適合于特定類型的項(xiàng)目。

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

· 分析問(wèn)題

· 市場(chǎng)調(diào)查

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

· 為基于軟件的解決方案制定計(jì)劃或設(shè)計(jì)

· 軟件的實(shí)施（編碼）

· 測(cè)試軟件

· 部署情況

· 維護(hù)和錯(cuò)誤修復(fù)

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

軟件開(kāi)發(fā)的每個(gè)階段所產(chǎn)生的文檔的詳細(xì)程度也可能不同。這些階段也可以依次進(jìn)行（如"瀑布式"），或者在不同的周期或迭代中重復(fù)進(jìn)行（如"極端編程"）。極端編程的方法通?；ㄔ谟?jì)劃和文檔上的時(shí)間較少，而花在編碼和開(kāi)發(fā)自動(dòng)化測(cè)試上的時(shí)間較多。

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

結(jié)構(gòu)化或 "瀑布式"的方法試圖在編碼開(kāi)始前評(píng)估大部分的風(fēng)險(xiǎn)，并制定詳細(xì)的軟件計(jì)劃，避免在軟件開(kāi)發(fā)生命周期規(guī)劃的后期階段進(jìn)行重大的設(shè)計(jì)變更和重新編碼。

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

2.2 軟件開(kāi)發(fā)活動(dòng)

2.2.1 確定需求

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

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

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

由于軟件開(kāi)發(fā)可能會(huì)涉及到妥協(xié)于或超出客戶的要求，因此軟件開(kāi)發(fā)項(xiàng)目可能會(huì)游離于技術(shù)性較差的領(lǐng)域，如人力資源、風(fēng)險(xiǎn)管理、知識(shí)產(chǎn)權(quán)、預(yù)算編制、危機(jī)管理等。這些過(guò)程也可能導(dǎo)致業(yè)務(wù)開(kāi)發(fā)與軟件開(kāi)發(fā)的作用重疊。

2.2.2 規(guī)劃

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

雖然在需求階段投入了大量的精力來(lái)確保需求的完整和一致性，但現(xiàn)實(shí)中很難做到這一點(diǎn)。需求的波動(dòng)性對(duì)軟件開(kāi)發(fā)很有挑戰(zhàn)性，因?yàn)樗鼈儠?huì)影響到未來(lái)或正在進(jìn)行中的開(kāi)發(fā)工作。

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

2.2.3 設(shè)計(jì)

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

功能實(shí)現(xiàn)、測(cè)試和記錄

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

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

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

2.2.4 部署和維護(hù)

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

軟件的培訓(xùn)和支持很重要，因?yàn)橹挥姓_使用軟件才能達(dá)到預(yù)期的目的。

維護(hù)和改進(jìn)軟件以應(yīng)對(duì)新發(fā)現(xiàn)的故障或需求，可能需要花費(fèi)大量的時(shí)間和精力，因?yàn)殄e(cuò)過(guò)的需求或者新的需求可能會(huì)導(dǎo)致軟件的重新設(shè)計(jì)。

在大多數(shù)情況下，需要定期維護(hù)，并修復(fù)報(bào)告的問(wèn)題來(lái)保持軟件的正常運(yùn)行。

2.3 軟件開(kāi)發(fā)相關(guān)主題

2.3.1 視圖模型

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

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

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

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

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

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

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

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

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

通常情況下，在進(jìn)行后建立一個(gè)模型，稱為業(yè)務(wù)分析。編程范式包括主持人提出一系列問(wèn)題，旨在提取描述一個(gè)過(guò)程所需的信息。訪談?wù)弑环Q為主持人，用以引導(dǎo)參與者提供信息。主持人應(yīng)該對(duì)所關(guān)心的過(guò)程有一定的了解。

因?yàn)橥ǔＪ怯梢粋€(gè)主持人團(tuán)隊(duì)在整個(gè)設(shè)施內(nèi)收集信息，所有訪談?wù)叩男畔⒔Y(jié)果必須在完成后整合在一起，這個(gè)時(shí)候使用合適的方法論很重要。

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

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

2.3.3 計(jì)算機(jī)輔助軟件工程

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

CASE的功能包括分析、設(shè)計(jì)和編程等。CASE工具用所需的編程語(yǔ)言自動(dòng)設(shè)計(jì)、記錄和制作結(jié)構(gòu)化的計(jì)算機(jī)代碼的方法。

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

· 培養(yǎng)軟件開(kāi)發(fā)和軟件維護(hù)過(guò)程中的計(jì)算機(jī)協(xié)助，以及

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

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

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

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

· 源代碼編輯器。

· 編譯器或解釋器。

· 構(gòu)建自動(dòng)化工具，以及

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

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

2.3.5 建模語(yǔ)言

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

軟件工程領(lǐng)域中的圖形建模語(yǔ)言的例子有：

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

· EXPRESS和EXPRESS-G（ISO 10303-11）是一種國(guó)際標(biāo)準(zhǔn)的通用數(shù)據(jù)建模語(yǔ)言。

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

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

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

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

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

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

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

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

2.3.6 編程范式

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

一種編程語(yǔ)言可以支持多種范式。例如，用C++或Object Pascal編寫的程序可以是純程序化的，也可以是純面向?qū)ο蟮?，或者包含兩種范式的元素。軟件設(shè)計(jì)者和程序員決定如何使用這些范式元素。

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

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

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

新的范式往往被習(xí)慣于早期風(fēng)格的人認(rèn)為是教條主義的，或者是過(guò)于僵化。

高級(jí)別的范式的例子包括：

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

· 特定領(lǐng)域的建模

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

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