2008-09-18 14:51
cmm成就了印度軟體業今天的輝煌，但cmm無法適應軟體需求的快速變化，又限制了印度軟體業進一步發展，近年來興起的精益管理模式下的敏捷開發過程為中國軟體業提供了乙個發展思路。
cmm成就了印度軟體業今天的輝煌，但cmm無法適應軟體需求的快速變化，又限制了印度軟體業進一步發展，近年來興起的精益管理模式下的敏捷開發過程為中國軟體業提供了乙個發展思路。
cmm等軟體過程標準最初是由於印度軟體提供商的積極採納而為人們所熟知的，印度軟體廠商也最先達到最高的一致性標準——cmm 5，他們讓市場認為cmm(特別是cmm 5)就意味著能夠可靠、可**地交付高質量的商業軟體。加上印度極具優勢的勞動力**和大量受過訓練的程式設計師，特別是印度的軟體公司還是流程方面的天才，使得軟體開發專案潮水般地湧入印度，讓印度軟體公司很快成為軟體開發、軟體維護、系統整合與運營等與軟體相關的各種專案的主角。然而，最近幾年cmm這一軟體過程遭到了挑戰。
印度軟體模式的困境
cmm由於其提高交付成功率的辦法而大受青睞。cmm注重過程、度量標準以及可重複性，從某種意義上說它確實讓交付變得更可**，並且在某些特定情況下，一些變更造成的影響也變得更可**。但在cmm管理下的「瀑布模型」給軟體開發帶來高度紀律性的同時，使用者對軟體開發的滿意度並未提高。
問題的根源在於: 業務需求的變化促使企業不斷調整它們的軟體功能。在cmm模式下，瀑布式開發過程雖然已經很清楚地定義了需求變更的處理過程，但需求變更的成本非常高，即使很小的變更也需要大量的流程變更和返工。因此企業經常會陷入兩難的境地: 要麼重新制定關鍵專案的計畫並接受延期發布，要麼將新需求推遲到下次軟體發布再完成。而當今的商業環境瞬息萬變，幾個月的拖延往往意味著市場機會的喪失。
在一些專案中，印度的軟體公司引發了客戶事後的強烈不滿，因為交付的軟體並不符合客戶當前的需求。更讓客戶難以接受的是，cmm 5的嚴格讓客戶無話可說，因為交付的軟體已經做到了合同中規定的一切。有些西方買家開始諷刺cmm，他們把cmm叫做「costs more money」(花更多的錢)。
事實上，按階段方式定義流程(瀑布模型)的基礎是乙個假設，即客戶知道他們將來需要什麼，意味著客戶必須在分析階段就決定具體功能的內容。實際情況是，在專案的某些時間點，客戶可能對變更的需求非常強烈，以至於要求專案必須適應這些變更。這時客戶能做的選擇少得可憐: 交付時間延期，付更多的費用，或者開始考慮第二個版本。
現在再看人們常說的「讓開發軟體如同建設橋梁」這句話也值得商榷。建橋所用的過程是為建設乙個堅固耐用的產品而設計的，這種產品一旦建好就能用很多年。而對於重要的軟體而言，在當前版本完成以後，它還有必要隨著需求的變化而改變，正是由於這方面的原因，那些建立在工程學原理之上的軟體過程方法無法很好地適應變化就毫不令人驚訝了。因為適應變化根本就不是其關注的東西。
中國不必模仿印度軟體模式
中國不必模仿印度軟體模式 雖然不是很喜歡ms,但是我覺得這篇文章說的很對,就轉過來了 晨報訊 記者 張旭光 以軟體外包服務為核心的印度軟體業發展模式，長期受到全球尤其是中國很多同行的羨慕與效仿。但反對的聲音已經出現，微軟公司首席技術官克瑞格 蒙迪昨天在華公開唱衰印度模式，並提醒中國不要在軟體外包方面...
工廠模式實現解耦
1.首先建立乙個業務類service，在service中有乙個屬性dao，daoimpl是實現了dao介面的類 public class serviceimpl public inte ce dao 2.在建立乙個測試類 public class testmethod 3.我們發現這樣雖然完成業務但...
UI 解耦 MVC 模式
說起來ui解耦，邏輯盡量不要寫在ui裡邊，這是為什麼？如果是簡單的遊戲可以隨意寫。如果是大型遊戲，建議還是寫在mvc比較好。m 資料層 ui 所操作的資料 v 檢視層ui 的執行邏輯。非ui邏輯建議用註冊的方法 肯定有同學想到要是ui 才有引數呢？這個確實是個問題。因此就需要用到 c 層。c 因為無...