�。牐�需求變化的影響是多方面的，客戶可能不了解需求變化帶來的影響，也可能知道但又不得不那么做。需求變化的后果可能是造成系統的重新設計，設計人員的日程的重新安排，已經完成的工作可能要重做或者完全拋棄，對其他項目產生影響，硬件需求可能要因此改變，等等。如果有許多小的改變或者一次大的變化，項目各部分之間已知或未知的依賴性可能會相互影響而導致更多問題的出現，需求改變帶來的復雜性可能導致錯誤，還可能影響工程參與者的積極性。
�。牐牏�、時間壓力
�。牐犥浖椖康娜粘瘫砗茈y做到準確，很多時候需要預計和猜測。當最終期限迫近和關鍵時刻到來之際，錯誤也就跟著來了。
�。牐牏�、自負人更喜歡說:'沒問題','這事情很容易','幾個小時我就能拿出來'
�。牐犔嗖磺袑嶋H的‘沒問題’，結果只能是引入錯誤。
�。牐牏�、代碼文檔貧乏
�。牐犡毞蛘卟顒诺奈臋n使得代碼維護和修改變的異常艱辛，其結果是帶來許多錯誤。事實上，在許多機構并不鼓勵其程序員為代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和容易理解，相反他們認為少寫文檔可以更快的進行編碼，無法理解的代碼更易于工作的保密(“寫得艱難必定讀的痛苦”)。
�。牐牏�、軟件開發工具
�。牐牽梢暬ぞ�，類庫，編譯器，腳本工具，等等，它們常常會將自身的錯誤帶到應用軟件中。就象我們所知道的，沒有良好的工程化作為基礎，使用面向對象的技術只會使項目變得更復雜。
�。牐牉榱烁玫亟鉀Q這些問題，軟件界做出了各種各樣的努力。
�。牎∪藗冊浾J為更好的程序語言可以使我們擺脫這些困擾，這推動了程序設計語言的發展，更多的語言開始流行，為了使程序更易于理解開發了結構化程序設計語言，如pl/1,pascal等;為了解決實時多任務需求開發了結構化多任務程序設計語言，如modula，ada等;為了提高重用性開發了面向對象的程序設計語言，如simlasa等;為了避免產生不正確的需求理解，開發形式化描述語言，如hal/s等，這使得建立基于自然語言的描述成為可能，人們以形式化語言來描述需求;為了支持大型數據庫應用，開發了可視化工具，如visual studio、power builder等。程序語言對提高軟件生產效率起到了一定的積極作用，但它對整個軟件質量尤其是可靠性的影響，與其他因素相比作用較小。
�。牐牽赡苁且驗槌绦蛘Z言基于嚴格的語法和語義規則，人們企圖用形式化證明方法來證明程序的正確性。將程序當作數學對象來看待，從數學意義上證明程序是正確的是可能的。數學家對形式化證明方法最有興趣，在論文上談起來非常吸引人，但實際價值卻非常有限，因為形式化證明方法只有在代碼寫出來之后才能使用，這顯然太遲了，而且對于大的程序證明起來非常困難。
�。牐犑艿狡渌袠I項目工程化的啟發，軟件工程學出現了，軟件開發被視為一項工程，以工程化的方法來進行規劃和管理軟件的開發。
�。牐犪槍π枨蟛淮_定的應用，可以使用漸進和迭代類的開發模型。還可以采用快速應用程序開發(rad)和協同應用程序開發(jad)技術，由軟件開發者和用戶代表共同參與開發軟件規范。rad和jad的基本思路是開發者和用戶共同設計系統中的屏幕，開發者迅速地把實現這些屏幕的最基本功能編寫好，然后把它們交給用戶看，然后用戶和開發者回顧這些屏幕以確認它們達到了用戶的要求，這個周期一直持續到系統的基本部分定義完畢。一旦設計被用戶接受，開發者將完成完全實現屏幕需要的代碼。rad和傳統軟件開發項目之間的一個基本區別是：應用程序rad系統是按階段發布的。傳統項目一般一次發布，也叫“big bang”。rad方法使用高效開發工具，開發者能夠非常迅速地設計出系統的基本屏幕，允許用戶在開發周期中很早就能見識到系統將來看起來怎么樣，避免了在傳統開發項目中長篇大論并且枯燥難懂的說明。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
