rel="file-list" href="file:///c:%5cdocume%7e1%5ccn1ww2g0%5clocals%7e1%5ctemp%5cmsohtml1%5c01%5cclip_filelist.xml">比爾蓋茨在
70年代就意識到了軟體的重要性。相比硬體，軟體是無限制的，軟體提供的服務也是無限制的，軟體可以創造任何東西，所以軟體將主宰未來的應用。事實也證明了這一點，軟體在生活中佔據了越來越重要的地位，軟體的應用範圍也在不斷擴大，軟體不再是可有可無的點綴，軟體的質量也開始受到人們前所未有的重視，因為我們已經離不開軟體了。軟體組織開始感受到來自客戶對軟體功能的要求和對質量的壓力。因此改進軟體生產過程，提高軟體生產率和軟體質量變得比以前任何時候都重要。
目前在軟體過程領域也存在不同的流派和方法，傳統的計畫驅動方法仍然是佔據主流的開發方法，瀑布模型，迭代模型，
iso9000
，rup
，cmm
層出不窮，你方唱罷我登場，乙個個好不熱鬧；最近幾年興起的敏捷方法也逐步引起大家的重視和研究。輪番出場的各種方法讓人感覺象霧裡看花。到底應該選擇哪種軟體過程好呢？怎樣才能建立適合自己的軟體過程呢？
rel="file-list" href="file:///c:%5cdocume%7e1%5ccn1ww2g0%5clocals%7e1%5ctemp%5cmsohtml1%5c01%5cclip_filelist.xml">
無論那種方法，我認為都要堅持如下的一些基本原則：只有這樣才能找到適合自己的方法。
以人為本
程式設計師在軟體生產中是第一位的。這是敏捷方法帶給我們的最重要的思想。程式設計師是軟體過程參與的主體，他們對於如何實施軟體過程最有發言權，因此無論任何軟體開發過程改進都應該以程式設計師為本。軟體開發過程改進的成敗也在於是否堅持以程式設計師為本。
軟體過程改進的根本目的是為了提高軟體生產的效率，提高軟體的質量。因此實施軟體過程改善不僅僅是管理者單方面的需要，更是程式設計師自身的需要。管理者不應該獨自決定如何進行軟體過程改進，然後強行把它推給程式設計師執行。
軟體過程改進必須要全員參與，首先讓大家明白過程改進是為了提高自己的工作效率，提高軟體質量。另外要讓程式設計師參與到過程改進的規範制定中去，讓管理者和程式設計師能夠達成一致的思想和行動。在規範制定過程中，要始終堅持一種思想：軟體過程改進是為程式設計師服務的，不是單純為了管理者服務的；因此在制定過程的時候，要盡量考慮程式設計師的需求，要盡可能減輕程式設計師的額外負擔，而不是簡單為了管理者方便檢查，監督而制定很多繁文冗節的規定，程式設計師不勝其煩，自然想方設法蒙混過關，或者百般推託，達不到改進的目的；讓程式設計師參與其中並虛心聽取他們的意見，這樣制定出來的改進措施一定是敏捷的，既能真正提高工作效率，又不會帶來過多的工作量，程式設計師何樂而不為呢？
以人為本的另乙個體現是注重員工培訓。國內很多軟體組織的通病之一就是不重視員工培訓，他們天然認為程式設計師都是天才，不學就會，能夠無師自通，從戰爭中學習戰爭，所以他們從來不考慮培訓。但是所有的開發流程，制度，無論多麼完美，最終都是要人去實施的，因此員工的素質是一切軟體過程，軟體開發成敗的關鍵，如果員工不能得到很好的培訓，他們就不能很好的理解這些軟體過程，制度在軟體質量和工作效率提高方面的作用，從而不能很好地發揮軟體過程的效果。即使有了完美的軟體過程，軟體的設計和開發依然不是隨便什麼人就可以設計出來的，具有有高超軟體設計能力的程式設計師是生產高質量軟體的根本條件，而培訓是提高程式設計師設計能力的乙個快捷途徑。
培訓的重要性對於敏捷方法尤其重要，敏捷方法號稱敏捷，但是它對於程式設計師，組織的能力和組織文化的要求都很高，從國內的大多數組織來說，他們根本不具備實施敏捷方法的條件，因為他們既沒有訓練有素的程式設計師，也沒有成熟，開發的團隊開發文化。如果不能通過培訓提高程式設計師的能力，建立適合敏捷方法的組織文化，即使實施敏捷方法也不可能得到良好的效果，這就是眾多組織實施敏捷方法失敗的原因。駕馭敏捷方法的關鍵就在於高素質的程式設計師。
沒有銀彈
不要期望存在完美的軟體過程模型可以解決所有問題，軟體質量就可以大幅度提高。軟體開發從來不存在銀彈。明白了這一點，要堅持活學活用，。
有一句非常有名的話：所有的模型都是不正確的，只有部分模型是正確的
(all models are wrong, some models are right)
。再完美的理論不可能完全符合實際，實踐也不能完全照搬，套用理論，要堅持走中國特色的社會主義道路，全盤西化要不得。因此必須結合本組織，團隊的實際開發狀況，選擇符合實際的改進方法和措施，不必一定拘泥於某種方法，不必一定完全照搬某種方法，
iso9000
，cmm，xp
等等都有很多優秀的，比如
iso9000
的階段評審，
cmm的
kpa實踐，
xp的小型發布，簡單設計等等都是可以借鑑的方法和最佳實踐。要堅持一切從實際出發，拿來主義，以我為主，唯我所用，不能唯方法而方法，作方法的奴隸。不管黑貓白貓，能抓到耗子就是好貓。只有堅持以我為主的思想，才能逐步改進現有的軟體過程，最終找到真正建立適合自己的軟體過程。
要改革不要革命
暴風驟雨的革命可能顯得氣勢恢巨集，顛覆性的方法更多是廣告式的宣傳。革命性的改變對於組織的影響是巨大的，是破壞性的，在某種情況下可能是致命的，如果不能取得好的效果，原有的過程勢必也被破壞殆盡。因此，不是萬不得已，不要輕易採用什麼激進的，革命性的休克**，俄羅斯就是休克**的乙個例子，效果大家想必都看得到。我們做軟體的就不要重蹈覆轍了。
如果乙個軟體組織沒有任何軟體過程，它完全可以照搬任意一種它認為完美的軟體過程方法，有總比沒有好；但是，大多數軟體組織已經形成了自己的軟體開發過程，具有自己的特點和開發文化，其中有合理有效的部分，也有需要改進的部分。這時候如果全盤否定過去，強行推行一種新的軟體過程，可能會導致大多數組織成員的不適應和反抗，還可能拋棄了自己原有的好的傳統，效果可能適得其反。比較有效的策略是「和風細雨，潤物無聲，積小成多」的改革，改革對現有組織的影響小，在保持原有機制基本穩定並且繼續發揮作用的基礎上，根據自己的實際情況，分析自己存在的主要問題，確定自己的目標和改進方向，在此基礎上進行軟體過程的改進。這樣不斷的通過小步的改進，逐步積累成大改進，最後讓軟體組織達到乙個質的提公升，產品質量也會隨之逐步提高。這個過程雖然可能漫長一點，但是比較穩妥，也比較有效。只有致持之以恆，持續不斷的改進，軟體過程改進才能真正見到實效。有的軟體組織今天採用
cmm，明天
rup，後天又是
xp，就像是學習外語，今天是跟我學，明天是許國璋，後天是新概念，英語水平永遠提不高。
管理層支援
建立成熟的軟體過程是乙個漫長的過程，不可能一蹴而就，有時候可能還需要組織結構的改變，因此需要方方面面的參與和支援。在軟體過程的建立，改進初期，由於採取了新的措施，方法，大家可能會有一些不適應，在實際執行中還可能出現一些問題，此時的軟體生產率其實是比較低的，比採用新方法之前還要低，這時候最需要組織各方面特別是管理層的理解和寬容，管理層應該鼓勵創新的精神，容許改進過程中的失誤，給予足夠的時間去試驗，而不是一如既往的壓任務，趕進度；在任務和進度的壓力下，大家只能勉力應付現有工作，根本無心也無力改進，最後只能導致改進失敗，再次回到起點。
持續改進
軟體過程是乙個持續改進的過程，軟體過程的改進不是孤立的實踐，有時組織架構也要根據軟體過程而作改變，因此軟體過程的改進不是一朝一夕的工作，也不是乙個人或者幾個人的事情，它需要整個組織的支援，特別是高層管理者的支援和相關部門的配合，軟體過程的改變還影響組織文化的建立和改變，它影響組織中的每乙個人，它改變了組織的工作模式和流程。軟體過程改進
(spi)
的乙個核心思想就是：不斷改進，永不停止。軟體工程的著名學者
barry boehm
曾經總結了軟體開發的七個基本原則。其中最後一條，也是最重要的一條就是承認不斷改進軟體工程實踐的必要性。
cmm的最高端第五級被稱為優化級。這些思想都強調了持續改進的重要性，只有不斷改進，才能臻於完美。
沒有最好的軟體過程，只有更好的軟體過程，只有適合自己的軟體過程。軟體過程改進沒有終點。
怎樣進行軟體過程改進
原帖裡面其他的文章也非常好 有人認為，如果乙個軟體機構在五個開發人員以下，以及開發周期短於六個月，進行基於sw cmm的軟體過程改進是不划算的。寫這篇文章的乙個目的，就是幫助人力財力不那麼雄厚的中小型企業進行軟體過程改進，讓他們能少花錢，少花時間，並且顯著得益。無論人數多少，開發周期多短，改進必得益...
如何進行軟體驗收
軟體專案驗收是對軟體專案成果的檢驗和確認，也是對軟體專案範圍的再確認。軟體驗收應是乙個過程的概念，包括驗收前的系統測試 資料移植 系統上線和正式驗收四個階段。1.系統測試 專案管理者聯盟文章，深入 系統測試是對系統進行全面的測試，應在測試環境中進行，以確保系統的功能和技術設計滿足企業的業務需求，並能...
如何進行軟體需求分析
概念 需求的定義包括從使用者角度 系統的外部行為 以及從 開發者角度 一些內部特性 來闡述需求。關鍵的問題是一定要編寫需求文件。我曾經目睹過乙個專案中途更換了所有的 開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說 我們想與你談談你的需求。客戶的第一反應便是 我已經將我的要求都告訴你們前任...