軟體工程原理方法分析整理

1. 軟體工程的基本原理有哪些

軟體工程的七條基本原理
1、用分階段的生命周期計劃嚴格管理有人經統計發現，在不成功的軟體項目中有一半左右是由於計劃不周造成的，可見把建立完善的計劃作為第一條基本原理是吸取了前人的教訓而提出來的。
在軟體開發與維護的漫長的生命周期中，需要完成許多性質各異的工作。這條基本原理意味著，應該把軟體生命周期劃分成若干個階段，並相應地制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發與維護工作進行管理。Boehm 認為，在軟體的整個生命周期中應該制定並嚴格執行六類計劃，它們是項目概要計劃，里程碑計劃，項目控制計劃，產品控制計劃，驗證計劃，運行維護計劃。

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

2、堅持進行階段評審

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

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

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

5、結果應能清楚地審查

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

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

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

2. 軟體工程學科涉及哪些理論和方法

(一軟體工程學科已發展為計算機科學與技術、數學、工程學、管理學等相關學科的交 叉性學科。傳統的計算機科學與技術學科已經涵蓋不了軟體工程可歸屬的二級學科問題, 不適應軟體產業對軟體工程人才培養的需要。

(二軟體工程學科已形成較完整的理論與工程技術體系,課程體系基本明確,高端人才 培養能力基本形成,創新型復合型人才的社會需求不斷提高。

(三軟體工程涉及軟體產業、信息產業和現代服務業,代表未來社會產業發展方向。

(四現有軟體工程人才培養體系不完整,需要通過進一步學科建設方能適應產業發展對 高端人才的需求。

3. 傳統的軟體工程方法存在的主要問題有哪些

運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

IEEE在軟體工程術語匯編中的定義：軟體工程是：1.將系統化的、嚴格約束的、可量化的方法應用於軟體的開發、運行和維護，即將工程化應用於軟體；2.在1中所述方法的研究

Fritz Bauer在NATO會議上給出的定義：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。
目前比較認可的一種定義認為：軟體工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。

《計算機科學技術網路全書》中的定義：軟體工程是應用計算機科學、數學及管理科學等原理，開發軟體的工程。軟體工程借鑒傳統工程的原則、方法，以提高質量、降低成本。其中，計算機科學、數學用於構建模型與演算法，工程科學用於制定規范、設計范型(paradigm)、評估成本及確定權衡，管理科學用於計劃、資源、質量、成本等管理。

4. 淺談對軟體工程的基本概念,方法與過程的理解及如何運用1500字左右

件工程(SoftWare Engineering)的框架可概括為：目標、過程和原則.
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品.正確性指軟體產品達到預期功能的程度.可用性指軟體基本結構、實現及文檔為用戶可用的程度.開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度.這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題,它們形成了對過程、過程模型及工程方法選取的約束.
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟.軟體工程過程主要包括開發過程、運作過程、維護過程.它們覆蓋了需求、設計、實現、確認以及維護等活動.需求活動包括問題分析和需求分析.問題分析獲取需求定義,又稱軟體需求規約.需求分析生成功能規約.設計活動一般包括概要設計和詳細設計.概要設計建立整個軟體系統結構,包括子系統、模塊以及相關層次的說明、每一模塊的介面定義.詳細設計產生程序員可用的模塊說明,包括每一模塊中數據結構說明及加工描述.實現活動把設計結果轉換為可執行的程序代碼.確認活動貫穿於整個開發過程,實現完成後的確認,保證最終產品滿足用戶的要求.維護活動包括使用過程中的擴充、修改與完善.伴隨以上過程,還有管理過程、支持過程、培訓過程等.
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則.

5. 軟體工程的基本原理

自從1968年提出「軟體工程」這一術語以來，研究軟體工程的專家學者們陸續提出了100多條關於軟體工程的准則或信條。美國著名的軟體工程專家巴利·玻姆（Barry Boehm）綜合這些專家的意見，並總結了美國天合公司（TRW）多年的開發軟體的經驗，於1983年提出了軟體工程的七條基本原理。
玻姆認為，這七條原理是確保軟體產品質量和開發效率的原理的最小集合。它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟體工程准則都可以有這七條原理的任意組合蘊含或派生。
下面簡要介紹軟體工程的七條原理：
用分階段的生命周期計劃嚴格管理
這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由於計劃不周而造成的。在軟體開發與維護的漫長生命周期中，需要完成許多性質各異的工作。這條原理意味著，應該把軟體生命周期分成若干階段，並相應制定出切實可行的計劃，然後嚴格按照計劃對軟體的開發和維護進行管理。玻姆認為，在整個軟體生命周期中應指定並嚴格執行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產品控制計劃、驗證計劃、運行維護計劃。
堅持進行階段評審
統計結果顯示：大部分錯誤是在編碼之前造成的，大約佔63%錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。 因此，軟體的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便盡早發現錯誤。
實行嚴格的產品控制
開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟體的一致性。
採納現代程序設計技術
從六、七十年代的結構化軟體開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大似氣力。採用先進的技術即可以提高軟體開發的效率，又可以減少軟體維護的成本。
結果應能清楚地審查
軟體是一種看不見、摸不著的邏輯產品。軟體開發小組的工作進展情況可見性差，難於評價和管理。為更好地進行管理，應根據軟體開發的總目標及完成期限，盡量明確地規定開發小組的責任和產品標准，從而使所得到的標准能清楚地審查。
開發小組的人員應少而精
開發人員的素質和數量是影響軟體質量和開發效率的重要因素，應該少而精。這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高幾倍到幾十倍，開發工作中犯的錯誤也要少的多；當開發小組為N人時，可能的通訊信道為N(N-1)/2, 可見隨著人數N的增大，通訊開銷將急劇增大。
承認不斷改進軟體工程實踐的必要性
遵從上述六條基本原理，就能夠較好地實現軟體的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，玻姆提出應把承認不斷改進軟體工程實踐的必要性作為軟體工程的第七條原理。根據這條原理，不僅要積極採納新的軟體開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的軟體技術的效果，也可以用來指明必須著重注意的問題和應該優先進行研究的工具和技術。

6. 軟體工程中常用的需求分析的方法有哪些

一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。

這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。

1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那麼這個需求就可能是偽需求。

以下面的案例說明：

背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。

需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。

分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。

因此，該需求是個偽需求，應該被過濾掉。

2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。

因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。

如果不屬於該系統范疇，那麼直接說服需求方更換方案。以

下面的案例說明：

背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。

需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。

分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。

所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；

其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。

結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。

否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。

二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：

先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。

每個需求點再當做一個子需求進行調研，最後再聚合在一起。

以下面的案例說明：

背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。

需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。

該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：

自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。

這里不一一展開。

2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：

由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。

然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。

三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。

比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。

最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：

背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。

分析：需求是很明白的，也有它的意義，但有風險。

因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。

因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。

於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。

測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。

四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。

舉例說明：

背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。

需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。

分析：

第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……

第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……

通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。

羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。