解讀軟體工程—（1）開端

真的很慚愧，大學學的專業是軟體工程，但是畢業後，除了敲程式碼，其他啥都不懂，只能淪為三流小碼農，當初總覺得搞這些分析畫圖之類的工作是枯燥乏味的，後來才發現而且從事這一項枯燥乏味工作的人工資竟然如此之高，引得無數程式猿擠破頭都想跳進去。

但是現在連連“什麼是軟體？”這個問題都回答不下來，那該怎麼辦？

還好年輕就是本錢，趁著現在有點時間，接下來就用幾天時間開始重新學習下軟體工程基本思想理論（當然更多還是靠實踐），擴充套件知識的同時，也為自己未來的職業發展開闢道路。

本篇先講解幾個基本概念。

1、千萬程式猿心中的疑問——什麼是軟體？

簡單的回答是：軟體 = 程式 + 資料 + 文件

2、軟體危機與軟體工程

軟體危機通俗來講就是投入了大量資金，人力，結果做出的軟體卻達不到預期的效果，或者根本無法使用，這帶來的後果是十分可怕的，所以為了解決這個問題，前人總結出了一堆的經驗，然後漸漸就發展成了一門新的工程類概念，這就是我們文章的主體——軟體工程
PS：軟體危機在現實工作中十分常見。因為之前待過的幾個創業公司，所以深有體會，在創業公司中基本上只有一條定理——敏捷開發。需求過來，依照需求大概設計下資料庫，產品設計好原型，然後照著開做。然而需求往往並不會如此穩定，然後就進入了一邊做新功能，一般改舊功能的迴圈。接著到了後期，測試加入，巨量BUG隨之而來，這種感覺對一個單純的程式猿無疑是痛苦的。我曾經待過的一個創業公司做了大半年，結果卻還沒有一個完整產品出爐，也差不多這個原因。

3、什麼是軟體工程？

應用系統化的、學科化的、定量的方法，來開發、執行、和維護軟體。即將工程化那套概念運用於軟體。

4、軟體工程的意義

引用別人的一句話“一種是遵守軟體工程開發規則的，我們稱之為工程師；一種是不遵守軟體工程開發規則的，我們稱之為碼農。”
先不管這句話的對與錯，我們已經知道軟體不是隻由程式碼組成的，而軟體的生命週期是很長的，而為了保證軟體在這個長期的、不斷變化的迭代過程中能繼續保持著青春活力，那麼採用工程性的思維來開發管理軟體就顯得至關重要，這也是我認為的軟體工程的意義。

5、軟體工程的三要素

• 方法：技術手段，即如何去做？
• 過程：基礎、框架，即做什麼？
• 工具：為方法和過程提供支援，即方法使用工具完成過程。

6、軟體工程七大原則

1）按軟體生存週期分階段制定計劃並認真實施；

在軟體開發與維護的漫長的生命週期中，需要完成許多性質各異的工作。這條基本原理意味著，應該把軟體生命週期劃分成若干個階段，並相應地制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發與維護工作進行管理。在軟體的整個生命週期中應該制定並嚴格執行六類計劃，它們是專案概要計劃，里程碑計劃，專案控制計劃，產品控制計劃，驗證計劃，執行維護計劃。不同層次的管理人員都必須嚴格按照計劃各盡其職地管理軟體開發與維護工作，絕不能受客戶或上級人員的影響而擅自背離預定計劃。

2）堅持進行階段評審

軟體的質量保證工作不能等到編碼階段結束之後再進行。這樣說至少有兩個理由：第一，大部分錯誤是在編碼之前造成的，例如，根據統計，設計錯誤佔軟體錯誤的63%，編碼僅佔37%；第二，錯誤發現與改正得越晚，所需付出的代價也越高。因此，在每個階段都進行嚴格的評審，以便儘早發現在軟體開發過程中所犯的錯誤，是一條必須遵循的重要原則。

3）實行嚴格的產品控制

在軟體開發過程中不應隨意改變需求，因為改變一項需求往往需要付出較高的代價，但是，在軟體開發過程中改變需求又是難免的，由於外部環境的變化，相應地改變使用者需求是一種客觀需要，顯然不能硬性禁止客戶提出改變需求的要求，而只能依靠科學的產品控制技術來順應這種要求。也就是說，當改變需求時，為了保持軟體各個配置成分的一致性，必須實行嚴格的產品控制，其中主要是實行基線配置，它們是經過階段評審後的軟體配置成分（各個階段產生的文件或程式程式碼）。基線配置管理也稱為變動控制：一切有關修改軟體的建議，特別是涉及到對基準配置的修改建議，都必須按照嚴格的規程進行評審，獲得批准以後才能實施修改。絕對不能誰想修改軟體（包括尚在開發過程中的軟體），就隨意進行修改。

4）用現代程式設計技術

從提出軟體工程的概念開始，人們一直把主要精力用於研究各種新的程式設計技術。60年代末提出的結構程式設計技術，已經成為絕大多數人公認的先進的程式設計技術。以後又進一步發展出各種結構分析（SA）與結構設計（SD）技術。實踐表明，採用先進的技術既可提高軟體開發的效率，又可提高軟體維護的效率。

5）結果應能清楚地審查

軟體產品不同於一般的物理產品，它是看不崢摸不著的邏輯產品。軟體開發人員（或開發小組）的工作進展情況可見性差，難以準確度量，從而使得軟體產品的開發過程比一般產品的開發過程更難於評價和管理。為了提高軟體開發過程的可見性，更好地進行管理，應該根據軟體開發專案的總目標及完成期限，規定開發組織的責任和產品標準，從而使得所得到的結果能夠清楚地審查。

6）開發小組的人員應該少而精。

軟體開發小組的組成人員的素質應該好，而人數則不宜過多。開發小組人員的素質和數量是影響軟體產品質量和開發效率的重要因素。素質高的人員的開發效率比素質低的人員的開發效率可能高几倍至幾十倍，而且素質高的人員所開發的軟體中的錯誤明顯少於素質低的人員所開發的軟體中的錯誤。此外，隨著開發小組人員數目的增加，因為交流情況討論問題而造成的通訊開銷也急劇增加。當開發小組人員數為N時，可能的通訊路徑有N（N?/FONT>1）/2條，可見隨著人數N的增大，通訊開銷將急劇增加。因此，組成少而精的開發小組是軟體工程的一條基本原理。

7）承認不斷改進軟體工程實踐的必要性

遵循上述六條基本原理，就能夠按照當代軟體工程基本原理實現軟體的工程化生產，但是，僅有上述六條原理並不能保證軟體開發與維護的過程能趕上時代前進的步伐，能跟上技術的不斷進步。因此，承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條基本原理。按照這條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗。