軟件工程學習筆記（全）

文章目錄

1.軟件的概念

軟件的特點：

軟件是抽象的，是一種邏輯實體而不是一種物理實體。
軟件是不會因爲使用而損壞的。
軟件是可以被拷貝的。（portable）
軟件是複雜的。
軟件是昂貴的。

請用你所見、所聞、所經歷的事例來描述軟件危機的現象或表現。

對軟件開發成本和進度的估計常常很不準確。
用戶對已完成的軟件不滿意的現象時有發生。
軟件產品的質量往往是靠不住的。
軟件常常是不可維護的。
軟件通常沒有適當的文檔資料。
軟件成本在計算機系統總成本中所佔比例逐年上升。
軟件開發生產率提高的速度遠跟不上日益增長的軟件需求

軟件工程定義

軟件工程是指導計算機軟件開發和維護的工程學科。採用工程的概念、原理、技術和方法來開發和維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件並有效地維護它，這就是軟件工程。
軟件工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。

軟件工程與計算機科學有什麼不同？

1、計算機科學與技術：涉及大數據技術導論、數據採集與處理實踐（Python）、Web前/後端開發、統計與數據分析、機器學習、高級數據庫系統、數據可視化、雲計算技術、人工智能、自然語言處理、媒體大數據案例分析、網絡空間安全、計算機網絡、數據結構、軟件工程、操作系統等方面

2、軟件工程：涉及程序設計語言、數據庫、軟件開發工具、系統平臺、標準、設計模式等方面。

二、軟硬件不同

1、計算機科學與技術：既有軟件技術，也包括硬件技術。

2、軟件工程：偏向軟件技術。

三、就業領域不同

1、計算機科學與技術：主要就業領域是從事網絡工程領域的設計、維護等工作和軟件信息技術領域的技術開發、教學、科研及管理等工作。

2、軟件工程：主要就業領域是軟件信息技術領域的技術開發工作和金融領域的經濟管理工作。

軟件的生命週期

一個軟件從定義，使用，開發，維護，直到最終被廢棄爲止的整個過程。

軟件生命週期方法學

基本思想：從時間角度對軟件開發和維護的複雜問題進行分解，把軟件生命的漫長週期依次分爲若干個階段，每個階段有相對獨立的任務，然後逐步完成每個階段的任務。
前階段任務的完成是後階段工作開始的前提與基礎，後階段任務是前階段的具體與細化。
優點：各階段任務相對獨立，便於分工協作，降低開發工作的難度，便於科學組織與管理；保證了產品的質量，提高了可維護性。

軟件工程的基本原理

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

這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由於計劃不周而造成的。在軟件開發與維護的漫長生命週期中，需要完成許多性質各異的工作。這條原理意味着，應該把軟件生命週期分成若干階段，並相應制定出切實可行的計劃，然後嚴格按照計劃對軟件的開發和維護進行管理。 Boehm 認爲，在整個軟件生命週期中應指定並嚴格執行6類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產品控制計劃、驗證計劃、運行維護計劃。

堅持進行階段評審

統計結果顯示：大部分錯誤是在編碼之前造成的，大約佔63%; <2> 錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。因此，軟件的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便儘早發現錯誤。

實行嚴格的產品控制

開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要採用科學的產品控制技術來順應這種要求。也就是要採用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼隨之相應變動，以保證軟件的一致性。

採納現代程序設計技術

從六、七時年代的結構化軟件開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大似氣力。採用先進的技術即可以提高軟件開發的效率，又可以減少軟件維護的成本。

結果應能清楚地審查

軟件是一種看不見、摸不着的邏輯產品。軟件開發小組的工作進展情況可見性差，難於評價和管理。爲更好地進行管理，應根據軟件開發的總目標及完成期限，儘量明確地規定開發小組的責任和產品標準，從而使所得到的標準能清楚地審查。

開發小組的人員應少而精

開發人員的素質和數量是影響軟件質量和開發效率的重要因素，應該少而精。這一條基於兩點原因：高素質開發人員的效率比低素質開發人員的效率要高几倍到幾十倍，開發工作中犯的錯誤也要少的多；當開發小組爲N人時，可能的通訊信道爲N(N-1)/2, 可見隨着人數N的增大，通訊開銷將急劇增大。

承認不斷改進軟件工程實踐的必要性

遵從上述六條基本原理，就能夠較好地實現軟件的工程化生產。但是，它們只是對現有的經驗的總結和歸納，並不能保證趕上技術不斷前進發展的步伐。因此，Boehm提出應把承認不斷改進軟件工程實踐的必要性作爲軟件工程的第七條原理。根據這條原理，不僅要積極採納新的軟件開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的軟件技術的效果，也可以用來指明必須着重注意的問題和應該優先進行研究的工具和技術。

軟件的倫理道德

公衆感：軟件工程師要始終與公衆利益一致。
客戶&僱主：軟件工程師要在與公衆利益一致的情況下保證僱主和公衆的最大利益。
產品：軟件工程師要保證其產品即相關組件達到儘可能高的行爲標準。
判斷力：軟件工程師要具備公正獨立的職業判斷力。
管理：軟件工程管理者和領導者應當維護並提倡合乎道德的軟件的管理方法。
職業感：軟件工程師要弘揚正義感和榮譽感，維護公衆利益。
同事：軟件工程師要公平的對待和協助每一位同事。
個人：軟件工程師應當畢生學習專業知識，倡導合乎職業道德的職業方式。

2. 軟件的過程

軟件過程活動

軟件過程模型的概念

軟件過程模型（software process model）是軟件開發全部過程，活動和任務的結構框架，它能直觀表達軟件開發全過程，明確規定要完成的主要活動，任務和開發策略。

瀑布模型（waterful model）

優點：

爲項目提供了按階段劃分的檢查點。
當前一階段完成後，您只需要去關注後續階段。
可在迭代模型中應用瀑布模型。

缺點：

不適應需求變化，只能用於需求不改變或很少改變的場合。
最終纔可以見到可執行系統，風險較大。
“瀑布模型是由文檔驅動的“這個事實也是它的一個主要缺點。在可運行的軟件產品交付給用戶之前，用戶只能通過文檔來了解產品是什麼樣的。要求用戶不經過實踐就提出完整準確的需求，在許多情況下都是不切實際的。總之，由於瀑布模型幾乎完全依賴於書面的規格說明，很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。

增量模型（Increment Model）

在大型軟件開發中存在着很多的不確定因素，需求的變更不可避免，所以積極應對變更對於一個軟件過程模型來說尤爲重要。

先完成一個系統子集的開發，再按同樣的開發步驟增加功能（系統子集），如此遞增下去直至滿足全部的系統需求。

優點：

軟件逐次交付，每次增量交付過程中獲取的經驗，有利於後面的改進，客戶也有機會對建立好的模型作出反應。
用戶可以更好的獲得收益。
核心功能先被開發，降低了項目失敗的可能性。
風險分佈到幾個更小的增量中，而不是集中於一個大型開發中。

缺點：

系統體系結構非常重要，需要良好的可擴展性架構設計，這是增量開發成功的基礎。

原型模型（Prototype Model）

原型模型是一個軟件系統的初期版本，用於展示概念，驗證設計方案，發現存在的問題和尋找可能的解決方法。

克服了瀑布模型的缺點，使它更好的滿足用戶並減少由於需求不明確帶來的項目風險；
適合預先不能確切定義需求的軟件系統的開發。
不適合開發大型的軟件系統，只適合開發小型的
前提是要有一個展示性的原型，因此在一定程度上限制了開發人員的創新。

螺旋模型（spiral model）

優點
對可選方案和約束條件的強調有利於已有軟件的重用，也有助於把軟件質量作爲軟件開發的一個重要目標。
減少了過多測試（浪費資金）或測試不足（產品故障多）所帶來的風險。
在螺旋模型中維護只是模型的另一個週期，在維護和開發之間並沒有本質區別。

缺點

採用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失。
過多的迭代次數會增加開發成本，延遲提交時間。

RUP的基本策略與特點

RUP（Rational Unified Process，統一軟件開發過程）

敏捷開發

傳統的開發方法有詳細的項目規劃，受控的過程管理和嚴格的質量保證，在規劃，設計及文檔編寫方面投入句法，適合大型，長壽命週期的軟件開發，無法滿足中小型軟件的開發需要。

敏捷開發適合系統需求在開發過程中快速變化的應用類型。

敏捷開發基本原則：

我們的最高目標是通過儘早和持續第交付有價值的軟件來滿足客戶。
歡迎對需求提出變更 - 即使在項目開發後期，要善於利用需求變更，幫助客戶獲得競爭優勢。
要不斷交付可用的軟件，週期從幾周到幾個月不等，越短越好。
項目過程中，業務人員與開發人員必須在一起。
要善於激勵項目人員，給他們以所需要的環境和支持，並相信他們能夠完成任務。
無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
可用的軟件是衡量進度的主要指標。
敏捷過程提倡可持續的開發，項目方，開發人員和用戶應該能夠保持恆久穩定的進展速度。
對技術的精益求精以及對設計的不斷完善將提升敏捷性。
要做到簡潔，儘可能減少不必要的工作，這是一門藝術。
最佳的架構，需求和設計出自於自組織的團隊。
團隊要定期反省如何能夠做到更有效，並相應調整團隊的行爲。

極限編程（XP Extreme Programming， Kent Beck 2000）

極限編程是目前最爲流行的敏捷開發方法。該方法推行最佳工程實踐，如迭代式開發，結對編程，測試驅動開發等，致力於積極響應用戶需求變化，並能高效率的開發出高質量軟件。XP適合於小團隊開發。

XP是一個輕量級的、靈巧的軟件開發方法；同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解爲一個個相對比較簡單的小週期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。

具體可以點擊這裏–>極限編程

結對編程

兩個程序員在一個計算機上共同工作。一個人輸入代碼，而另一個人審查他輸入的每一行代碼。且角色一直互換。
項目開發中會不斷的更換合作伙伴。

優點：

編碼，設計和測試至少被另外一個人檢查過，代碼，設計和測試的質量提高。
增強了彼此之間的溝通。

測試團隊和開發團隊是否應該處在一個團隊中，應該是怎樣一種管理結構？

不應該，軟件的成功不僅需要開發人員的設計和實現。而且還需要測試人員去做測試找出bug，避免在用戶使用時出現較多錯誤，影響用戶體驗度。在一個團隊中，大家均是爲了完成這個軟件，難免會有漏洞，只有獨立開，專以找出軟件的漏洞爲職責，才能更好地修復軟件。

3. 軟件需求

軟件需求是待開發系統特徵的描述，即提供的服務及運行時滿足的約束條件。

可行性研究

可行性研究的主要任務是”瞭解客戶的要求及現實環境，從技術，經濟和社會因素等三方面研究並論證本軟件項目的可行性，編寫可行性研究報告，制定初步項目的開發計劃。“

技術可行性：對待開發的項目的功能，性能和限制條件進行分析，確認現有的資源（硬件，軟件，技術人員水平，已有的工作基礎）條件下，項目能否實現。
經濟可行性：對待開發的項目的開發成本與預期收益進行評估，確定該項目是否值得去投資開發。考慮的問題主要是成本和效益的估算。
社會可行性：待開發項目是否存在着違反法律的（合同，責任，侵權）的潛在因素以及待開發的項目在用戶組織內是否行的通，現有的管理體制，人員素質和操作方式是否可行。

需求工程概述

清楚的理解用戶要解決的問題，完整準確的獲取用戶的需求，並用《軟件需求規格說明書》規範的形式準確的表達用戶的想法。

所面臨的挑戰是：

問題空間理解。
人與人之間的通信。
需求的不斷變化。

需求工程對人員的要求：

概括能力，分析能力和社交能力。
一定的軟，硬件系統開發經驗。
能理解用戶提出的要求。
善於在用戶和軟件開發機構之間進行良好的通訊。

在這個階段，重要的是什麼，而不是怎麼做。

需求工程有三個層次：

業務需求 Business Requirements：描述了企業對項目的高層次目標，從宏觀上描述開發系統的必要性，意義和目標。
用戶需求 User Requirements：描述了用戶對於系統的期望和目標，即用戶要讓系統做什麼，產生什麼樣的業務價值，這是需求獲取階段的產物。具有離散型（用戶從不同角度，不同層面，不同粒度提出需求）和矛盾性（用戶處於不同的工作崗位，難免有侷限性和矛盾性）的特點。
系統需求：描述軟件產品要實現的軟件服務以及需要滿足的約束條件。用戶利用這些服務來完成工作任務，滿足業務需求。這是需求分析和建模的產物，對UR進行分析得到。

需求規約與建模（Requirements specification）

在需求文檔中撰寫用戶需求與系統需求的過程，需求要求具有清晰性，明確性，易讀性，完整性和一致性的特點。

用戶需求：從用戶角度描述體統功能及非需求功能，只涉及外部功能，不涉及內部設計，用自然語言及圖形描述。
系統需求：如何讓系統滿足用戶的需求，是系統的一個完備，詳盡的描述，也是系統設計的起點。

基本步驟如下：

需求的獲取

目標：完整的獲取系統必須提供的服務，以及需要滿足的約束條件。

主要方法：

用戶訪談。
用戶調查（針對於無法訪談的涉衆，發放調查問卷進行需求獲取）。
參與，觀察業務流程。
情景串聯（結合原型/ppt等方法展示業務處理場景和流程）。
現有的產品和競爭對手文檔（取長補短）。

需求分析

對需求獲取得到的用戶第一手需求資料進行綜合整理分析，從而得到系統需求的過程。

主要任務：

建立系統用例模型。
業務流程分析。
編制用例說明。
查詢報表分析。
非功能需求分析。

需求驗證與確認

需求驗證：檢測需求是否正確，完備和一致，且爲後續設計開發和測試提供了足夠的基礎。
需求確認：確認建立的需求正確的反映了用戶對軟件的要求，通常由軟件公司和客戶共同完成。

主要方法：

快速原型。
需求評審。

討論快速原型與需求評審

快速原型是建造一個模型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼。快速原型模型需要迅速建造一個可以運行的軟件原型，以便理解和澄清問題，使開發人員與用戶達成共識，最終在確定的客戶需求基礎上開發客戶滿意的軟件產品。快速原型模型允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型，該原型向用戶展示待開發軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發人員據此對軟件進行修改完善，直至用戶滿意認可之後，進行軟件的完整實現及測試、維護。

需求管理

組織記錄軟件需求，控制變更，並確保軟件開發與軟件需求一致的一系列方法與活動。

需求標識
建立基線
變更控制
需求追蹤

4. 面向對象範型

耦合是影響軟件複雜程度和設計質量的一個重要因素，爲提高模塊的獨立性，應建立模塊間儘可能鬆散的系統，在設計上我們應採用以下原則：若模塊間必須存在耦合，應儘量使用數據耦合，少用控制耦合，慎用或有控制地使用公共耦合，並限制公共耦合的範圍，儘量避免內容耦合。

內聚有如下的種類，它們之間的內聚度由弱到強排列如下：
（1） 偶然內聚：一個模塊內的各處理元素之間沒有任何聯繫，只是偶然地被湊到一起。這種模塊也稱爲巧合內聚，內聚程度最低。
（2） 邏輯內聚：這種模塊把幾種相關的功能組合在一起，每次被調用時，由傳送給模塊參數來確定該模塊應完成哪一種功能。
（3） 時間內聚：把需要同時執行的動作組合在一起形成的模塊稱爲時間內聚模塊。
（4） 過程內聚：構件或者操作的組合方式是，允許在調用前面的構件或操作之後，馬上調用後面的構件或操作，即使兩者之間沒有數據進行傳遞。簡單的說就是如果一個模塊內的處理元素是相關的，而且必須以特定次序執行則稱爲過程內聚。
（5） 通信內聚：指模塊內所有處理元素都在同一個數據結構上操作或所有處理功能都通過公用數據而發生關聯（有時稱之爲信息內聚）。即指模塊內各個組成部分都使用相同的數據數據或產生相同的數據結構。
（6） 順序內聚：一個模塊中各個處理元素和同一個功能密切相關，而且這些處理必須順序執行，通常前一個處理元素的輸出時後一個處理元素的輸入。
（7） 功能內聚：模塊內所有元素的各個組成部分全部都爲完成同一個功能而存在，共同完成一個單一的功能，模塊已不可再分。即模塊僅包括爲完成某個功能所必須的所有成分，這些成分緊密聯繫、缺一不可。

對於低耦合，粗淺的理解是:一個完整的系統，模塊與模塊之間，儘可能的使其獨立存在。也就是說，讓每個模塊，儘可能的獨立完成某個特定的子功能。模塊與模塊之間的接口，儘量的少而簡單。如果某兩個模塊間的關係比較複雜的話，最好首先考慮進一步的模塊劃分。這樣有利於修改和組合。

軟件架構設計的目的簡單說就是在保持軟件內在聯繫的前提下，分解軟件系統，降低軟件系統開發的複雜性，而分解軟件系統的基本方法無外乎分層和分割。但是在保持軟件內在聯繫的前提下，如何分層分割系統，分層分割到什麼樣的程度，並不是一件容易的事，這方面有各種各樣的分解方法，比如:關注點分離，面向方面，面向對象，面向接口，面向服務，依賴注入，以及各種各樣的設計原則等。

耦合可以分爲以下幾種，它們之間的耦合度由高到低排列如下:

(1) 內容耦合:一個模塊直接訪問另一模塊的內容，則稱這兩個模塊爲內容耦合。

若在程序中出現下列情況之一，則說明兩個模塊之間發生了內容耦合:

一個模塊直接訪問另一個模塊的內部數據。
一個模塊不通過正常入口而直接轉入到另一個模塊的內部。
兩個模塊有一部分代碼重疊(該部分代碼具有一定的獨立功能)。
一個模塊有多個入口。

內容耦合可能在彙編語言中出現。大多數高級語言都已設計成不允許出現內容耦合。這種耦合的耦合性最強，模塊獨立性最弱。

(2) 公共耦合:一組模塊都訪問同一個全局數據結構，則稱之爲公共耦合。公共數據環境可以是全局數據結構、共享的通信區、內存的公共覆蓋區等。如果模塊只是向公共數據環境輸入數據，或是隻從公共數據環境取出數據，這屬於比較鬆散的公共耦合;如果模塊既向公共數據環境輸入數據又從公共數據環境取出數據，這屬於較緊密的公共耦合。

公共耦合會引起以下問題:

無法控制各個模塊對公共數據的存取，嚴重影響了軟件模塊的可靠性和適應性。
使軟件的可維護性變差。若一個模塊修改了公共數據，則會影響相關模塊。
降低了軟件的可理解性。不容易清楚知道哪些數據被哪些模塊所共享，排錯困難。

一般地，僅當模塊間共享的數據很多且通過參數傳遞很不方便時，才使用公共耦合。

(3) 外部耦合:一組模塊都訪問同一全局簡單變量，而且不通過參數表傳遞該全局變量的信息，則稱之爲外部耦合。

(4) 控制耦合:模塊之間傳遞的不是數據信息，而是控制信息例如標誌、開關量等，一個模塊控制了另一個模塊的功能。

(5) 標記耦合:調用模塊和被調用模塊之間傳遞數據結構而不是簡單數據，同時也稱作特徵耦合。標記耦合的模塊間傳遞的不是簡單變量，而是像高級語言中的數據名、記錄名和文件名等數據結果，這些名字即爲標記，其實傳遞的是地址。

(6) 數據耦合:調用模塊和被調用模塊之間只傳遞簡單的數據項參數。相當於高級語言中的值傳遞。

討論面向對象範型

面向對象範型主要是基於將數據和操作綁定到一起;，或者說形成對象, 利用對象來綁定操作。要點如下：面向對

（1）面向對象的軟件系統是由對象組成的，軟件中的任何元素都是對象，複雜的軟件對象由簡單的軟件對象組合而成。

（2）所有對象劃分成各種對象類，每個對象都定義了一組數據和一組方法。

（3）按照子類（派生類）和父類（基類）的關係，把若干個對象類組成一個層次結構的系統（類等級）。在派生類中對某些特性又做了重新描述，則在派生類中的這些特性將以新描述爲準，也就是說，低層的特性將屏蔽高層的同名特性。

（4）對象彼此之間僅能通過傳遞消息互相聯繫。

面向對象的特點：對象對自己負責；找到變化並封裝之；優先使用對象聚集，而不是類繼承：相比這下，繼承類需要深入瞭解父類，有可能帶來冗餘和職責不清的問題。針對接口編程，而不是實現；相同功能下，減少了代碼的數量，也減少了出錯的機率。代碼越少，問題越少。約定優於配置。

UML（Unified Modeling Language 統一建模語言）

討論用例圖（case diagram）

用例圖是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關係構成的用於描述系統功能的視圖。用例圖（User Case）是外部用戶（被稱爲參與者）所能觀察到的系統功能的模型圖。用例圖是系統的藍圖。用例圖呈現了一些參與者，一些用例，以及它們之間的關係，主要用於對系統、子系統或類的功能行爲進行建模。

一個類可能有多於一個狀態圖？

狀態圖用來描述一個特定的對象所有可能的狀態,以及由於各種事件的發生而引起的狀態之間的轉移和變化。

並不是所有的類都需要畫狀態圖，有明確意義的狀態，在不同狀態下行爲有所不同的類才需要畫狀態圖。

5. 軟件生命週期

你認爲哪種軟件生命週期模型最好？爲什麼？

要根據情況而決定，不同情況使用不同的模型。目前有瀑布模型、快速原型模型、增量模型、螺旋模型

瀑布模型，也稱軟件生存週期模型。
優點：（1）在軟件工程中佔有重要地位，它提供了軟件開發的基本框架，這比依靠“個人技藝”開發軟件好得多。（2）有利於大型軟件開發過程中人員的組織、管理，有利於軟件開發方法和工具的研究與使用，從而提高了大型軟件項目開發的質量和效率。
缺點：（1）階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量；（2）由於開發模型是線性的用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；（3）早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重後果。適用：（1）在開發時間內需求沒有或很少變化；（2）分析設計人員應對應用領域很熟悉；（3）低風險項目（對目標、環境很熟悉）；（4）用戶使用環境很穩定；用戶除提出需求以外，很少參與開發工作。
快速原型模型
優點：（1）可以得到比較良好的需求定義，容易適應需求的變化；（2）有利於開發與培訓的同步；（3）開發費用低、開發週期短且對用戶更友好。
缺點：（1）客戶與開發者對原型理解不同；（2）準確的原型設計比較困難；（3）不利於開發人員的創新。適用：（1）對所開發的領域比較熟悉而且有快速的原型開發工具；（2）項目招投標時，可以以原型模型作爲軟件的開發模型；（3）進行產品移植或升級時，或對已有產品原型進行客戶化工作時，原型模型是非常適合的。
增量模型
優點：（1）採用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源；（2）如果核心產品很受歡迎，則可增加人力實現下一個增量；（3）可先發布部分功能給客戶，對客戶起到鎮靜劑的作用。
缺點：（1）並行開發構件有可能遇到不能集成的風險，軟件必須具備開放式的體系結構；（2）增量模型的靈活性可以使其適應這種變化的能力大大優於瀑布模型和快速原型模型，但也很容易退化爲邊做邊改模型，從而是軟件過程的控制失去整體性。適用：（1）進行已有產品升級或新版本開發，增量模型是非常適合的；（2）對完成期限嚴格要求的產品，可以使用增量模型；（3）對所開發的領域比較熟悉而且已有原型系統，增量模型也是非常適合的。
螺旋模型
優點：（1）設計上的靈活性,可以在項目的各個階段進行變更；（2）以小的分段來構建大型系統,使成本計算變得簡單容易；（3）客戶始終參與每個階段的開發,保證了項目不偏離正確方向以及項目的可控性；（4）隨着項目推進,客戶始終掌握項目的最新信息 , 從而他或她能夠和管理層有效地交互。
缺點：（1）採用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失；（2）過多的迭代次數會增加開發成本，延遲提交時間。適用：只適合於大規模的軟件項目

6. 軟件測試

軟件測試是保證軟件質量，提高軟件可靠性的關鍵。

狹義的軟件測試定義：爲發現軟件缺陷而執行程序或系統的過程

廣義的軟件測試定義：人工或自動地運行或測定某系統的過程，目的在於檢驗它是否滿足規定的需求或弄清預期結果和實際結果間的差別

爲什麼要做軟件測試？

發現軟件缺陷
- 功能錯
- 功能遺漏
- 超出需求部分（畫蛇添足）
- 性能不符合要求
軟件質量高低：是否符合用戶習慣、符合用戶需求

測試的任務

找出
定位
修改
修改後要做迴歸測試，對已修改的部分進行再次的測試，避免引入新的錯誤

軟件測試原則

軟件測試的原則

所有的測試都應追溯到用戶的需求
儘早地和不斷地進行軟件測試（缺陷具有放大的特點，測試成本隨階段深入而上升）
8-2原則
- 測試中發現的錯誤80%很可能起源於程序中的20%
- 提前測試可發現80%，系統測試找出剩餘bug的80%（總體的16%），最後的4%可能只有用戶大範圍長時間使用後才暴露出來
- 80%的工程用在20%的需求上（即關鍵需求）
軟件缺陷的寄生蟲性：找到的缺陷越多說明軟件遺留的缺陷越多
避免自己測試自己的程序
迴歸測試：避免引入新的錯誤