軟體工程實踐思想

1、用分階段的生命週期計劃嚴格管理

有人經統計發現，在不成功的軟體項目中有一半左右是由於計劃不周造成的，可見把建立完善的計劃作為第一條基本原理是吸取了前人的教訓而提出來的。

在軟體開發與維護的漫長的生命週期中，需要完成許多性質各異的工作。這條基本原理意味著，應該把軟體生命週期劃分成若干個階段，並相應地制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發與維護工作進行管理。Boehm 認為，在軟體的整個生命週期中應該制定並嚴格執行六類計劃，它們是項目概要計劃，裡程碑計劃，項目控制計劃，產品控制計劃，驗證計劃，運行維護計劃。

不同層次的管理員都必須嚴格按照計劃各盡其職地管理軟體開發與維護工作，絕不能受客戶或上級人員的影響而擅自背離預定計劃。

2、堅持進行階段評審

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

3、實行嚴格的產品控制

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

4、採用現代程式設計技術

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

5、結果應能清楚地審查

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

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

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

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

遵循上述六條基本原則，就能夠按照當代軟體工程基本原理實現軟體的工程化生產，但是，僅有上述六條原則並不能保證軟體開發與維護的過程能趕上時代前進的步伐，能跟上技術的不斷進步。因此，Boehm提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條基本原則。按照這條原則，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗，例如，收集進度和資源耗費資料，收集出錯類型和問題報告資料等等。這些資料不僅可以用來評價新的軟體技術的效果，而且可以用來指明必須著重開發的軟體工具和應該優先研究的技術