1、 現在的應用和以前大不一樣�，F在的應用是一種龐大的集成，包括跨平臺，網絡，數據庫等等，而且新技術的出現越來越快，任何人都無法精通甚至是掌握全部技術。簡單例子：現在有Windows,Unix,Linux等平臺，有SQL Server,Oracle,Sybase等數據庫，有C++,VB,Delphi等工具，誰能全部精通呢？如果不能，那么如何確定是Windows+SQL Server+Delphi好還是Unix+Oracle+C++合適？
2、 客戶沒有需求。我做過銀行、電信等大客戶及各種小客戶，他們無一另外的說"我要做一個OA系統"，"我要做一個企業網"，"我要做一個……"�？伤麄儫o法確定要實現什么，因為很少有用戶是真正由于業務的需求而做項目的；而且他們也不清楚能夠實現什么(因為他們不懂notes,不懂企業網)。
3、 需求與環境的變化。由于在項目開發前客戶沒有實質性的需求，加上軟件開發人員不熟悉客戶的業務，就導致在開發過程中需求的不斷變化，嚴重時將導致分析與設計作廢。
4、 對象化的工具和過程化的程序現在的開發工具已經很對象化了，而我們開發的程序卻很過程化。也就是說你雖然努力的模塊化，層次化，可只要運行環境有所變化，你還要不斷地修改再修改。
上述的實際情況說明我們確實需要把實際中的做法修改一下。一個項目如果做到了80%的時候才真正明確這個系統是什么樣子的話，我認為是設計者的失敗。所以在設計階段不但應該做好傳統做法的各種文檔和論證，而且，應該做一些具體的設計工作。比如，系統的整體運行設計及系統各功能模塊的具體設計。而且這些設計應當都有詳細的設計說明書。當這些說明書完成后，應當能做到：隨便找個程序員他都能只通過看某功能模塊的設計說明書就能夠開始代碼的開發而不用再重新思考該怎樣去做了，程序員在這里就真的只是一個設計者的實現工具。當然，也象某些兄弟說的那樣，現在的系統都越來越繁雜、越來越龐大、越來越向集成性質靠攏，似乎是沒有多少人能掌握具體用什么做效果如何，但關鍵就在這里。莫非真的沒有人能做到這點嗎？非也！只不過是目前的顯示情況是，設計人員的水平偏低，有些公司的設計人員根本就沒有多少的開發經驗，他又怎能了解太多的系統呢。
系統設計在目前看來似乎是個拿錢多干活少的工作，這是不正常的現象。培養一個程序員根本不用花多大的力氣，一個人只要不太笨不太蠢，給他一個機會，相信就能掌握某門技術或方法。但要掌握若干種方法，就不是能夠通過速成解決的了。問題也在于此。目前似乎所有的系統設計人員都能夠設計所有的東西。其實不然。很多人都有知識的局限性，這就決定他只能對某些方向的東西做出決策和設計�？蛻艄倘徊恢浪鍪裁�，但我們應該知道。如果在前期能夠多接觸用戶、多深入實際，把設計人員當成客戶工作中的一員，他就能夠真正了解到客戶的需求，當然也就能夠為他做出合適的設計。
至于說到各種系統之間的好壞對比，我想，任何東西都沒有絕對，有的只是某些方面的權衡。比如性能或空間的權衡、價格和性能的權衡和功能側重上的權衡等等如此而已。計算機里的東西沒有哪一樣的存在不是包含了這種權衡在內的。雖然從商務上似乎總想說服用戶什么東西好什么東西不好，其實從技術上講無所謂好和不好，有的只是區別及該區別所針對的問題而已。這就象有人總在爭論Linux和Window到底誰好一樣�；蛟S從"技術"上講，Linux比Window好，但這其實并不公正，因為漂亮的GUI界面和友好的人際交互同樣應該是"技術"中應該考慮到的一部分。把所有的東西結合起來一看就知道沒有絕對的好。所以，不見得非要在用戶決定之前由系統設計的人員事先來為各種方案做個排隊，只需要了解用戶的需求，然后從大方向上決定一個方向再做具體設計就可以了。
在這里我只從過去的實踐角度舉例來說，至于理論方面實在沒時間深入。首先，認同兩個說法：
1. 項目(或說工程)有三個主要方面：功能，時間，成本。
2. 系統分析的任務：將用戶的業務邏輯轉化為程序邏輯，計算時間和成本。
讓我們來做一個概要設計：
1) 功能：簡單的信息發布系統。
2) 系統分析員根據項目的時間和成本，在充分權衡各種方案的利弊的基礎上提出SQLSERVER+CORBA+DELPHI的方案……用戶很滿意，OK，開始詳細設計：
1) 為方便用戶的安裝使用三層結構。
2) 客戶端包含信息分布和查詢兩個模塊。
3) 使用各種圖或語言描述各種函數，過程，模塊，層次……一切順利，開始編碼……編碼完成，用戶試用，這時用戶提出：在客戶端要能實時跟蹤信息的變化，而你卻發現DELPHI的CORBA不支持回調！轉用其它方按時間上不可能，補救措施也不靈(比如使用timer，但客戶的網絡環境不允許多個用戶的頻繁刷新)，怎么辦？
分析一下問題出在哪里：
1) 有人會說系統分析員不真正了解客戶的需求，可這不可能(項目時間的限制)也不現實(不可能讓分析員到每個崗位都去操作一下)。
2) 有人會說系統分析員的知識和經驗不足，可現實卻是分析員認為應該的客戶覺得沒必要，而客戶覺得必須的分析員又不可理解。這是不同的工作造成的，俗話說隔行如隔山。
3) 有人會說系統分析員的水平不夠，可問題絕大部分是出在細節而不是大方向上，掌握全部細節可能嗎？這就是一個長期困擾我的問題：細節(而不是方向)往往成為成功與失敗的關鍵(注意，這里的成功是包含了時間和成本的)，而細節是不可能全部發現與分析清楚的。
如何在這種不完整的需求上構造完整的系統呢？或是根本不可能呢？這種問題我遇到過多次──當然都是別人做的設計。但我認為這個過程中不足的地方就是：把東西做死了，沒有切實地為用戶著想。很多人在做設計時，可能考慮的最多的是實現上的方便，而不是系統的擴展及更新。需知道，用戶的需求是在不斷變化的，如果總是在設計前就"善意"地替用戶假設，是難以預料后事的結局的。所以我想，在設計階段就因該把可能出現的問題都擺到桌面上討論，包括其特點、效果和后果，而不是自以為是地、好心地替用戶"假設"。其實一個系統設計的優劣，其系統的擴展性能是一個很重要的指標，一個單純就事論事地針對某件事情而做出的"專用"系統是沒有任何遠見的
文章來源于領測軟件測試網 http://www.kjueaiud.com/
