在學習《軟體工程》前，我個人倒是著實作了點專案，個人做的和團隊合作的都有。但無論是個人做或是團隊合作，給我印象最深的就是分工不明，雖然這種組織專案開發的方式快速，但與此對應所帶來的惡果常常是混亂和持續不斷的錯誤，並使得開發熱情迅速消耗殆盡，最後變成了磨洋工。學了《軟體工程》之後，覺得自己的思路開闊了不少。不過對於《軟體工程》中所說的知易行難，所以結合自己的經驗和當前的主流思想，總結了一些自己在做軟體專案中所遇到的問題。
在軟體專案中經常會遇到以下幾個方面的問題：
需求不充分同時經常變更；缺乏與客戶的溝通；
團隊內部溝通不暢；
不必要的複雜度；
團隊工作缺乏效率；
上面的第1條好理解，因為這是軟體專案成敗的基礎，還軟體是用來幹什麼的都沒搞清楚，那麼怎麼可能指望它能得到客戶的滿意呢？為什麼會出現需求不充分這種情況呢？主要有兩點原因：其一是客戶常常自己不能明確地了解自已的需求；其二是就算客戶有能力了解乙個複雜系統需求的所有細節，他也可能不知道如何有效地組織需求文件。同時就算是在專案開發將近結束的時候，仍會發現新的需求或是要進行需求更改。比如隨著程式開發過程的深入，客戶對億們需要什麼有了更清楚的了解；客戶認識到最初的需求無法滿足他們的需要；客戶在需求階段可能提出了一些他們並不真正需要的需求，然後在開發過程中又不想要了；客戶需求的改變；客戶方的職員或經理發生變更，由於想法不一致，導致需求的改變等等。
第2條也比較容易理解，因為要準確定義需求是一項困難的工作，因此，與客戶保持開放和有建設性的交流是很重要的，那樣做可以確保你所做的工作正是客戶想得到的。一定要通過與客戶的互動來完成需求分析。另外，每個專案都是從一些不完善的資訊開始的，對於專案將如何進展也是處於一系列設想之中的。通常在隨著專案進度的展開，這些設想將不得不進行調整，你和客戶將分擔這些調整所帶來的影響，因此交流的結果最終必須達成協議。
第3條主要是當開發人員增多時，每個開發人員也相應地要與更多的人進行同步，根據《人月神話》這本書上所指到的那樣，開發人員的增長，會導致團隊裡用於溝通的資訊量呈二次級數增長。不暢的溝通有兩種：太少或太多，太少會導致不能消除系統分歧，太多則浪費太多時間在協調而非**開發上。
第4條的複雜度增加會占用大量資源和時間進行開發、維護和擴充套件，從而導致團隊工作越來越繁雜且收效甚微。當乙個程式規模擴大，內部互動增多時，就會使出錯的機會增大，且這些漏洞在開發過程中難以發現。同時複雜性還會導致**的難以理解。乙個專案一般包含很多元件，當構件數目增加時，就會增加每個元件與更多元件互動的機會。當互動數量大大增加時，就不太容易理解程式正在做什麼，也使得沒有人能夠修改或擴充套件這個程式了。
第5條是在開發中很常見的，因為沒有哪個程式設計師是通過培訓成為團隊成員的，學校裡也不會教學生如何參與團隊系統的開發。作為團隊成員，溝通、協作和建立共識的技能比個人的程式設計技能要重要得多，這對於學校出來的程式設計師來說是認識不到的，他們通常認為自己能寫出沒有毛病的**，同時覺得別人的**都不夠完美或嚴謹。溝通、協作和建立共識是花時間且沒必要的，他們崇敬的不是傑出的團隊成員，也不是什麼團隊領導，而是個別有創造力的程式設計師。而結果是他們的**難以理解並潛伏著錯誤，同時帶來的問題就是開發時間的延長。
軟體專案中存在的問題
在學習 軟體工程 前，我個人倒是著實作了點專案，個人做的和團隊合作的都有。但無論是個人做或是團隊合作，給我印象最深的就是分工不明，雖然這種組織專案開發的方式快速，但與此對應所帶來的惡果常常是混亂和持續不斷的錯誤，並使得開發熱情迅速消耗殆盡，最後變成了磨洋工。學了 軟體工程 之後，覺得自己的思路開闊了...
軟體專案中的風險管理
http www.csai.cn 2005年07月27日 1.引言 軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理...
軟體專案中的基礎測試
軟體專案中的基礎測試 單元測試 ut 什麼是單元測試 單元測試 又稱為模組測試 是針對程式模組 軟體設計的最小單位 來進行正確性檢驗的測試工作。序單元是應用的最小可測試部件。在過程化程式設計中，乙個單元就是單個程式 函式 過程等。單元測試流程 在傳統軟體開發過程中，單元測試是在編寫完模組 後開始進行...