學了這麽長時(shí)間(jiān)的軟件工程，相信有(yǒu)很(hěn)多(duō)人(rén)對這門(mén)學科會(huì)産生(shēng)很(hěn)多(duō)的疑問，我在這裏談談我個(gè)人(rén)對軟件工程的理(lǐ)解和(hé)感受，希望對各位有(yǒu)所幫助和(hé)借鑒。如果大(dà)家(jiā)有(yǒu)更好的想法也希望能夠提出來(lái)一起交流。
首先談談什麽是軟件工程。相信大(dà)家(jiā)肯定都聽(tīng)說過橋梁工程、道(dào)路工程等等這些(xiē)名詞，我們得(de)理(lǐ)解工程這個(gè)詞的定義，工程說簡單點就是各個(gè)行(xíng)業的工程師(shī)或者應用人(rén)員通(tōng)過總結規律或者方法，以最短(duǎn)的時(shí)間(jiān)和(hé)人(rén)力、物力來(lái)做(zuò)出高(gāo)效可(kě)靠的東西。因此，我們也就能理(lǐ)解橋梁工程，其實就是人(rén)們通(tōng)過經驗的總結和(hé)各種研究得(de)出來(lái)的、用來(lái)修建橋梁時(shí)所采用的高(gāo)效的方法，當然這種方法是可(kě)套用的。那(nà)麽我們将這個(gè)思想應用到軟件上(shàng)，于是就産生(shēng)了一門(mén)新的學科—軟件工程。
以往，人(rén)們做(zuò)軟件基本上(shàng)是沒有(yǒu)章法可(kě)循，不知道(dào)該怎麽去設計(jì)一個(gè)軟件，很(hěn)多(duō)時(shí)候隻能憑一些(xiē)在軟件行(xíng)業摸爬滾打了很(hěn)多(duō)年的資深人(rén)士做(zuò)出經驗上(shàng)的判斷，這樣得(de)出來(lái)的軟件不僅耗費人(rén)力物力，而且質量還(hái)得(de)不到保證，同時(shí)維護起來(lái)也是困難重重。于是為(wèi)了能夠實現軟件的流水(shuǐ)線式生(shēng)産，在設計(jì)和(hé)構建軟件時(shí)能夠有(yǒu)一種規範和(hé)工程化的方法，人(rén)們便提出了軟件工程這個(gè)概念。需要強調的是，目前有(yǒu)關軟件工程方法真實本質的争論一直都在持續進行(xíng)着，要真正将軟件工程變成一個(gè)全成熟的學科，還(hái)有(yǒu)大(dà)量的工作(zuò)要做(zuò)。
軟件工程的內(nèi)容
目前，一個(gè)通(tōng)用的軟件工程過程框架通(tōng)常包括5個(gè)活動：溝通(tōng)-策劃-建模-構建-部署。根據不同的過程模型(後文再介紹)這5個(gè)框架活動的順序是不一定的。下面我們來(lái)一一介紹這5個(gè)框架活動的內(nèi)容。
溝通(tōng)：一個(gè)軟件在設計(jì)之前一定要充分了解客戶的需求，不然得(de)到的結果很(hěn)有(yǒu)可(kě)能會(huì)南轅北轍，有(yǒu)很(hěn)多(duō)軟件系統都是在已經實現之後卻發現跟客戶的需求有(yǒu)很(hěn)大(dà)差異，或者沒有(yǒu)達到客戶的期望，最後弄得(de)雙方都十分尴尬。這種案例就是前期的溝通(tōng)沒有(yǒu)做(zuò)好，一方面客戶的需求可(kě)能非常理(lǐ)想化，他們對軟件的實現完全不了解，他們想達到的功能很(hěn)有(yǒu)可(kě)能是目前技(jì)術(shù)還(hái)無法實現的，我們在溝通(tōng)時(shí)一定要在他心中建立一個(gè)正确的觀念。另一方面，客戶可(kě)能自己都不知道(dào)要做(zuò)一個(gè)具有(yǒu)哪些(xiē)功能的軟件，他們隻是有(yǒu)一個(gè)初步的想法，這個(gè)時(shí)候就需要開(kāi)發人(rén)員去引導，最好的方式就是提出各種版本方案讓客戶選擇，最後再擇優處理(lǐ)。很(hěn)多(duō)人(rén)肯定都覺得(de)軟件開(kāi)發大(dà)部分時(shí)間(jiān)都花(huā)在編碼，其實恰恰相反，一個(gè)軟件的開(kāi)發周期，其中一大(dà)半都是花(huā)在需求分析，也就是我們的溝通(tōng)階段。有(yǒu)一個(gè)例子就使我印象特别深刻。
我的大(dà)學數(shù)據庫老師(shī)曾經接了一個(gè)醫(yī)院數(shù)據庫開(kāi)發項目，然後他們團隊負責需求分析的幾個(gè)人(rén)就集體(tǐ)搬到了醫(yī)院一個(gè)小(xiǎo)房(fáng)間(jiān)住下來(lái)，然後天天"纏在"各個(gè)部門(mén)的負責人(rén)身邊，問東問西，做(zuò)各種數(shù)據的分析，例如醫(yī)院的職位分配是怎麽樣的制(zhì)度，每個(gè)部門(mén)有(yǒu)多(duō)少(shǎo)分職，藥庫是怎樣管理(lǐ)的…等等等等。然而，就算(suàn)是天天住在那(nà)裏，都面臨着各種阻礙。首先是對方不願意也沒有(yǒu)時(shí)間(jiān)來(lái)做(zuò)各種需求的統計(jì)(像醫(yī)院這種地方，每個(gè)人(rén)都很(hěn)忙)，其次他們自己也不太清楚自己的需求。甚至到了最後居然出現了某個(gè)部門(mén)的負責人(rén)常常不來(lái)辦公室(躲着他們)的情況。可(kě)想而知，項目最後的結果也不太理(lǐ)想。所以，很(hěn)多(duō)時(shí)候我們做(zuò)軟件開(kāi)發的應該多(duō)多(duō)學習怎麽樣跟利益相關者打交道(dào)，引導他們做(zuò)出準确的需求分析。說了這麽多(duō)，足以見得(de)前期的溝通(tōng)有(yǒu)多(duō)麽重要。
策劃：策劃階段就是要做(zuò)出我們整個(gè)軟件系統的“設計(jì)地圖”，有(yǒu)了地圖我們才能将旅程變得(de)簡單而且易于掌握。這個(gè)地圖就是我們的軟件項目計(jì)劃，它包括需要執行(xíng)的技(jì)術(shù)任務、可(kě)能存在的風險、需要用到的資源、整個(gè)項目的工作(zuò)進度等等。
建模：顧名思義，建模就是建立我們軟件設計(jì)的模型，最初的草圖包括整個(gè)項目的體(tǐ)系結構、不同的組件模塊之間(jiān)怎麽連接，以及其他的一些(xiē)特性。最後經過不斷的討(tǎo)論與設計(jì)，對草圖進行(xíng)精化，得(de)到每一個(gè)功能模塊的具體(tǐ)類與接口，這樣即使團隊中有(yǒu)人(rén)離職，不得(de)已讓新人(rén)進來(lái)取代的時(shí)候，也能根據設計(jì)模型以及各種UML圖遊刃有(yǒu)餘的進行(xíng)編碼，這也就是為(wèi)什麽要有(yǒu)一個(gè)圖紙的原因之一。
到此為(wèi)止，我們軟件工程的五大(dà)過程框架就簡單的給大(dà)家(jiā)介紹了一遍，其實研究的最多(duō)的也就是這幾大(dà)活動，但(dàn)是這幾個(gè)過程的執行(xíng)順序在現實應用中都不會(huì)是線性的一步接一步，往往在編碼的時(shí)候還(hái)有(yǒu)可(kě)能在做(zuò)需求分析，也有(yǒu)可(kě)能會(huì)先開(kāi)發出系統的主要功能，然後再慢慢往上(shàng)加其他的拓展功能。這就不得(de)不提軟件工程的過程模型。
瀑布模型：這是一種經典的模型，顧名思義，瀑布就是順流而下的，瀑布模型也是一種線性的、順序的軟件開(kāi)發方法，從最開(kāi)始的溝通(tōng)，到最後的部署，一步緊接一步線性執行(xíng)到最後。因此我們也能想象，實際的項目是很(hěn)少(shǎo)遵守瀑布模型提出的順序的。因為(wèi)瀑布模型要求客戶具有(yǒu)十分明(míng)确的需求，這在現實中是基本不存在的。
增量過程模型:即前面所提到的先開(kāi)發出系統的核心功能,然後再依據重要性評估交付新添的增量,直到最終産品的産生(shēng)。
螺旋模型:螺旋模型在瀑布模型的基礎上(shàng)加了風險分析,同時(shí)叠代式的開(kāi)發一系列的演進版本。螺旋最中間(jiān)的就是項目的起點,螺旋式的進行(xíng)着五個(gè)框架活動,一直進行(xíng)到螺旋最外圈。螺旋模型是開(kāi)發大(dà)型系統和(hé)軟件的很(hěn)實際的方法,像大(dà)型的軍工軟件系統都是使用的螺旋模型進行(xíng)開(kāi)發的,而且像這種系統的螺旋終點是沒有(yǒu)的,因為(wèi)軍工産品需要不停地進行(xíng)更新叠代,不然很(hěn)快就會(huì)被時(shí)代淘汰。
螺旋模型
相信大(dà)家(jiā)看到現在應該對軟件工程已經有(yǒu)了一個(gè)大(dà)體(tǐ)的了解。
