什麽是軟件工程

        學了這麽長時間的軟件工程，相信有很多人對這門學科會産生很多的疑問，我在這裏談談我個人對軟件工程的理解和感受，希望對各位有所幫助和借鑒。如果大家有更好的想法也希望能夠提出來一起交流。

首先談談什麽是軟件工程。相信大家肯定都聽說過橋梁工程、道路工程等等這些名詞，我們得理解工程這個詞的定義，工程說簡單點就是各個行業的工程師或者應用人員通過總結規律或者方法，以最短的時間和人力、物力來做出高效可靠的東西。因此，我們也就能理解橋梁工程，其實就是人們通過經驗的總結和各種研究得出來的、用來修建橋梁時所采用的高效的方法，當然這種方法是可套用的。那麽我們将這個思想應用到軟件上，于是就産生了一門新的學科—軟件工程。

    需要強調的是，目前有關軟件工程方法真實本質的争論一直都在持續進行着，要真正将軟件工程變成一個全成熟的學科，還有大量的工作要做。

                                                      軟件工程的内容

溝通：一個軟件在設計之前一定要充分了解客戶的需求，不然得到的結果很有可能會南轅北轍，有很多軟件系統都是在已經實現之後卻發現跟客戶的需求有很大差異，或者沒有達到客戶的期望，最後弄得雙方都十分尴尬。這種案例就是前期的溝通沒有做好，一方面客戶的需求可能非常理想化，他們對軟件的實現完全不了解，他們想達到的功能很有可能是目前技術還無法實現的，我們在溝通時一定要在他心中建立一個正确的觀念。另一方面，客戶可能自己都不知道要做一個具有哪些功能的軟件，他們隻是有一個初步的想法，這個時候就需要開發人員去引導，最好的方式就是提出各種版本方案讓客戶選擇，最後再擇優處理。很多人肯定都覺得軟件開發大部分時間都花在編碼，其實恰恰相反，一個軟件的開發周期，其中一大半都是花在需求分析，也就是我們的溝通階段。有一個例子就使我印象特别深刻。

        我的大學數據庫老師曾經接了一個醫院數據庫開發項目，然後他們團隊負責需求分析的幾個人就集體搬到了醫院一個小房間住下來，然後天天"纏在"各個部門的負責人身邊，問東問西，做各種數據的分析，例如醫院的職位分配是怎麽樣的制度，每個部門有多少分職，藥庫是怎樣管理的…等等等等。然而，就算是天天住在那裏，都面臨着各種阻礙。首先是對方不願意也沒有時間來做各種需求的統計(像醫院這種地方，每個人都很忙)，其次他們自己也不太清楚自己的需求。甚至到了最後居然出現了某個部門的負責人常常不來辦公室(躲着他們)的情況。可想而知，項目最後的結果也不太理想。所以，很多時候我們做軟件開發的應該多多學習怎麽樣跟利益相關者打交道，引導他們做出準确的需求分析。說了這麽多，足以見得前期的溝通有多麽重要。

        策劃：策劃階段就是要做出我們整個軟件系統的“設計地圖”，有了地圖我們才能将旅程變得簡單而且易于掌握。這個地圖就是我們的軟件項目計劃，它包括需要執行的技術任務、可能存在的風險、需要用到的資源、整個項目的工作進度等等。

        到此爲止，我們軟件工程的五大過程框架就簡單的給大家介紹了一遍，其實研究的最多的也就是這幾大活動，但是這幾個過程的執行順序在現實應用中都不會是線性的一步接一步，往往在編碼的時候還有可能在做需求分析，也有可能會先開發出系統的主要功能，然後再慢慢往上加其他的拓展功能。這就不得不提軟件工程的過程模型。

過程模型

    瀑布模型：這是一種經典的模型，顧名思義，瀑布就是順流而下的，瀑布模型也是一種線性的、順序的軟件開發方法，從最開始的溝通，到最後的部署，一步緊接一步線性執行到最後。因此我們也能想象，實際的項目是很少遵守瀑布模型提出的順序的。因爲瀑布模型要求客戶具有十分明确的需求，這在現實中是基本不存在的。

增量過程模型:即前面所提到的先開發出系統的核心功能,然後再依據重要性評估交付新添的增量,直到最終産品的産生。

螺旋模型:螺旋模型在瀑布模型的基礎上加了風險分析,同時叠代式的開發一系列的演進版本。螺旋最中間的就是項目的起點,螺旋式的進行着五個框架活動,一直進行到螺旋最外圈。螺旋模型是開發大型系統和軟件的很實際的方法,像大型的軍工軟件系統都是使用的螺旋模型進行開發的,而且像這種系統的螺旋終點是沒有的,因爲軍工産品需要不停地進行更新叠代,不然很快就會被時代淘汰。

                                                                    螺旋模型

相信大家看到現在應該對軟件工程已經有了一個大體的了解。