0. 軟件開發(fā)需要過程么？

寫了再改，不挺好么？不需要太多其他準備或相關知識，無需文檔，無需規(guī)劃，無需質(zhì)量保障，上來就寫代碼；也許就能寫出來，寫不出來就改，也許能改好。但是這種寫法適用的場合有限:

• “只用一次”的程序
• “看過了就扔” 的原型
• 一些不實用的演示程序

但是要開發(fā)一個復雜的軟件，這個方法的缺點就太大了，現(xiàn)實中基本毫無用處。

1. 黑盒與白盒過程

• 黑盒測試
  • 概念：測試者不了解程序的內(nèi)部情況，不需具備應用程序的代碼、內(nèi)部結(jié)構和編程語言的專門知識。只知道程序的輸入、輸出和系統(tǒng)的功能，這是從用戶的角度針對軟件界面、功能及外部結(jié)構進行測試，而不考慮程序內(nèi)部邏輯結(jié)構。測試案例是依應用系統(tǒng)應該做的功能，照規(guī)范、規(guī)格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出；
  • 適用場合：大部分測試，如整合測試和系統(tǒng)測試。

  • 存在的問題：要求開發(fā)之前需求被充分理解；與客戶的交互只在開始(需求)和最后(發(fā)布)——類似于產(chǎn)品制造過程；而實際情況往往不是如此。

    
    
    

    black box
• 白盒測試
  • 概念：在白盒測試時，以編程語言的角度來設計測試案例。測試者輸入數(shù)據(jù)驗證數(shù)據(jù)流在程序中的流動路徑，并確定適當?shù)妮敵?，類似測試電路中的節(jié)點。測試者了解待測試程序的內(nèi)部結(jié)構、算法等信息，這是從程序設計者的角度對程序進行的測試。
  • 適用場合：白盒測試可以應用于單元測試、集成測試和系統(tǒng)的軟件測試流程，可測試在集成過程中每一單元之間的路徑，或者主系統(tǒng)跟子系統(tǒng)中的測試。盡管這種測試的方法可以發(fā)現(xiàn)許多的錯誤或問題，它可能無法檢測未使用部分的規(guī)范。
  • 優(yōu)點：通過改進可見性來減少風險；在開發(fā)過程中，通過不斷地獲得顧客的回饋允許變更——類似于服務過程。
    
    

    white box

2. 典型的軟件過程模型

• 瀑布模型
  也叫做鮭魚模型，向前一階段回溯，很難，特點：
  • 上一個階段結(jié)束，下一個階段才能開始；
  • 每個階段均有里程碑和提交物；
  • 上一階段的輸出是下一階段的輸入；
  • 每個階段均需要進行V&V；
  • 側(cè)重于文檔與產(chǎn)出物。

優(yōu)點：簡單、易懂、易用、快速；為項目提供了按階段劃分的檢查點，項目管理比較容易?？傊?code>追求效率。
??缺點：用戶難以清楚地確定所有需求，需求的錯誤很難在開發(fā)后期糾正，因此難以快速響應用戶需求變更；開發(fā)人員與用戶之間缺乏有效的溝通，開發(fā)人員的工作幾乎完全依賴規(guī)格說明文檔，容易導致不能滿足客戶需求?？傊?，過于理想化。

• 增量過程模型

在很多情況下，由于初始需求的不明確，開發(fā)過程不宜采用瀑布模型。這時增量過程模型應運而生。其分為兩種：增量模型和RAD。
??增量模型：軟件被作為一系列的增量來設計、實現(xiàn)、集成和測試，每一個增量是由多種相互作用的模塊所形成的提供功能的代碼片段構成。本質(zhì)：以迭代的方式運用瀑布模型。
??RAD：側(cè)重于短開發(fā)周期(一般為60~90天)的增量過程模型，是瀑布模型的高速變體，通過基于構件的構建方法實現(xiàn)快速開發(fā)。

增量模型是串行的瀑布模型，RAD是并行的瀑布模型。

• 演化過程模型

軟件系統(tǒng)會隨著時間的推移而發(fā)生變化，在開發(fā)過程中，需求經(jīng)常發(fā)生變化生變化，直接導致產(chǎn)品難以實現(xiàn)；本質(zhì)：循環(huán)、反復、不斷調(diào)整當前系統(tǒng)以適應需求變化。其分成兩種：快速原型法和螺旋模型。

process

• 敏捷過程模型
  詳情參考：淺談「敏捷」開發(fā)

3. 對比總結(jié)

我個人認為這些方法都有各自適應的情況，瀑布模型追求效率，增量過程模型適用用戶需求不斷增加，但是核心計劃不變，而演化過程模型較為復雜，是在不斷迭代，重新策劃中進行。
??在短期、項目小、人員有限的情況下，敏捷過程模型是最恰當不過了。