這篇文字是應目前在it168工作的原CSDN老哥熊建國之約，基于他們的統計數據作出的調研，因為一些原因，其中修改并了少量文字，這里我把我的全文貼在這里。
目前的已發布文檔連接如下：
http://tech.it168.com/m/p/2007-01-29/200701290911953.shtml 中國軟件開發工具應用狀況分析
http://tech.it168.com/m/p/2007-01-30/200701300922046.shtml 中國軟件質量管理和測試工具的應用狀況分析
http://tech.it168.com/m/a/2007-01-23/200701230933790.shtml 中國軟件項目開發管理體系建立狀況分析
這篇文章被分成了三個部分在it168上作了發布，現在時間已經過了兩個月，我可以將我的文章發表在我的blog上了。
注：因為本文較長，所以文中圖片沒有進行上傳，文中的相關圖片可以在上面三個連接中看到，給大家帶來的麻煩，請多多見諒。
正文
第四章 軟件開發過程技術應用研究
n 軟件開發過程技術應用研究的主要結論：
1.國內軟件企業的規范化程度在不斷提升
2.軟件開發輔助工具的使用日益普及
3.中國軟件企業仍然有絕大部分處于原始開發狀態，需要真正懂得軟件工程技術和管理的技術人員或者國內軟件咨詢技術企業的成長。
n 軟件開發過程技術應用的概況：
中國的軟件行業從上世紀八十年代末開始形成，到現在已經經歷了將近二十年的時間，這二十年時間里，國際軟件行業和技術的革新變化非常之大，我們不得不面對國際軟件行業企業已經走過了幾十年的歷程和經驗積累對我們產生的壓力。
從下面的調查數據上我們可以看到中國軟件行業的從業人員的努力與拼搏，但是，仍然有太多的地方是不如意的，也使得我們中國軟件行業的從業人員不得不再次的深入思考，反省我們曾經的做法，規劃我們將來的道路。
一組組的數據上到底說明了些什么問題，下面我們會在文中進行詳細的分析和講述。
第1節 軟件項目開發管理體系的建立狀況
參考問卷
1． 您所在的公司或項目組通過什么樣的評估體系認證？
都沒有 ISO-9000系列 CMM/CMMI系列 其它
現階段國內的企業感覺到規范化研發過程的對企業的重要性，目前絕大多數企業都通過了相關的認證評估，其中38%的企業通過了ISO-9000系列的認證，28.2%的企業通過了CMM/CMMI方面的評估，只有32%的企業還沒有進行相關的認證評估工作。
圖表 1 開發者公司或項目獲得軟件評估認證體系的分布狀況
ISO9000被認為是國內各種類型的企業在規范化進行中必須經過的一種認證，CMM/CMMI評估是2000年開始進入中國大陸并迅速得到各類軟件企業認同的一種評估手段。
可以這樣說，基本上通過CMM/CMMI評估的軟件企業都會先考慮通過ISO9000系列的認證，因為CMM/CMMI評估的費用較大，周期也相應較長。
2000年的時候珠海市宣布對通過CMM評估的軟件企業給與一次性50萬人民幣的獎勵，同時國內多個城市都出臺了類似的獎勵措施。但是，直到2001年底國內也只有幾家企業通過了CMM2級的評估，CMM3級的評估只有2家。企業在通過CMM/CMMI評估的過程中，CMM/CMMI2級大約需要100萬人民幣，而3級的評估則需要150萬到200萬人民幣的投入。現在居然能占到了28.2%的企業中的部門通過了CMM/CMMI的評估，可見國內企業進行這方面認證的投入是相當積極的。
這里有一個需要澄清的觀點，那就是：CMM/CMMI只有評估，沒有認證！
關于CMM/CMMI有下面兩個特點是與ISO9000不同的：
第一、CMM/CMMI的評估是一個持續不斷的過程，CMM/CMMI的目的是為了幫助目標企業改進其軟件開發過程，而不是簡單的認證，因此，每過一段時間就需要進行重新的評估，如果再次評估的時候沒有達到上次評估的要求，則在CMM/CMMI的級別發布中會修改其級別。
第二、CMM/CMMI只是對組織中的某一個部門的評估，不會對整個組織/企業進行評估！CMM/CMMI的評估只是針對部門，同時在3級以上才需要組織/企業提供一些環境和配套措施，但它始終都不是對整個組織/企業的評估。
第三、按照規定大概每過半年，該部門的狀態就需要進行一次重新的評估，以確保他們在此期間的項目仍然能夠達到此前評估中認定的級別。檢查該部門是否出現新的問題或者其級別是否已經有所提高！如果過了期限而沒有參加評估，則不會被認定仍然具有該資格。在SEI那里記錄的也只是曾經通過評估的有哪些，并不是說明現在還擁有資格的有哪些，所以，在看CMM證書的時候一定要注意一下！
因為每次評估，CMM的主任評估師都只會說：
“我是來幫助你們改進過程的。每過一段時間，我們都需要過來評估一下你們目前的開發過程所處的狀態，并針對你們的缺陷提出我們的意見和建議，供你們參考來改進你們部門的過程，提高你們的軟件開發管理水平……”
另外，CMM/CMMI的評估沒有其所要求的固定的軟件開發與管理要求，它就像一個抽象的理論框架，企業采用哪種具體的實現方法是沒有關系的，因此，企業可以選擇XP或者選擇RUP或者選擇其他開發過程來進行這個評估。
參考問卷
2． 您所在的公司或項目組采用什么項目過程管理框架？
RUP XP MSF 自定義的過程管理框架 順其自然，沒有采用什么特別的過程管理框架
項目過程管理框架的使用情況與程度表現了一個企業軟件開發團隊成熟度的最關鍵的標志之一。從完全混亂的開發狀態到現在，中國軟件業不到20年的過程中，走過了國外四五十年的經歷，調查顯示，目前企業中采用輕量級過程XP框架的戰友42.5%，重量級軟件過程RUP框架的戰友17.7%，采用微軟MSF框架的有14.6%，而采用自定義過程管理框架的戰友20.3%，目前仍然沒有采用任何過程管理框架的只有微小的4.9%的比例。
圖表 2 開發者公司或項目組對項目過程管理框架的應用狀況
從這些比例數據的對比中可以看出，國內軟件企業的規范化程度有了顯著的提高，因為軟件開發的過程管理框架可以顯示出一個企業在軟件開發上的規范程度，這是一個企業從混沌狀態到規范化狀態必須跨越的一個門檻，而有了自己的過程管理框架也說明這個企業有了自己的核心技術人員和專家團隊。
關于RUP相關數據的評論：
從軟件企業的開發過程和實踐來看，完全采用RUP的過程框架進行開發在中國國內是不太現實的，因為RUP過程本身的復雜度和管理上的重量是國內從大型企業到小型企業都無法承受的。這一點也可以從下面使用軟件開發輔助工具的情況上看出來。
關于XP相關數據的評論：
而XP的過程由于其先天的特征，要求企業內必須有技術水平絕對高的架構師的存在，而從中國的軟件開發歷程來看，中國國內目前還沒有開發經驗20年以上的軟件技術人員存在，加上軟件技術本身的變革和飛躍，基本上可以認為國內目前還沒有真正培養出自己的軟件架構師的時間，所以，從這一點來看，完全的XP實施就是不現實的事情，但是部分的采用XP框架進行實施是有其應用環境的。這一點同樣可以從后面的第四個問題“您所在的公司或項目組是否選用了迭代的開發方式”中看出來。
參考問卷
3． 您怎樣獲得需求？（可多選）
一開始獲得所有需求 迭代開發獲取需求 現場客戶獲取需求 其它
需求獲取地點上仍然是以客戶現場獲取需求為主，它占有了48.5%的比例，需求獲取的方式上是迭代開發獲取為主，它占有超過半數的54.7%的比例，而只有27.1%的開發人員是在項目已開始就獲得所有需求的。
圖表 3 開發者獲取用戶需求的方式分布狀況
需求的獲取方式是與當前國內項目和客戶的實際狀況有著密切關系的，這一點在上圖中表現得十分明顯。下面我們分為這幾個情況進行一下分析：
1、 一開始獲得所有需求：
這是瀑布式開發過程所提出的需求獲取模式，實際上這對于一般的項目是十分不實用也不太現實的，但是，如果能以這種方式達成需求獲取目的，那就是最佳的需求獲取時間了。
在目前國內的項目狀況上，基本上只有單純的外包項目才能做到這一點，這個27.1%的數值也可以看出國內外包項目所占的市場分額。比如，東軟就從原來最大的國內軟件承包商變成了國內相對較大（是不是最大的，還沒有看到明確的數據）的外包軟件承包商。
2、 現場客戶獲取需求
現場客戶獲取需求這不僅僅是國內最常見的需求獲取方式，也是國際上幾乎所有的軟件項目的最初需求獲取方式。例外的也只有產品開發類別的項目會不一定需要到用戶現場進行需求獲取，但是，從一個公司做項目積累到做產品，其實，這個產品型項目的原始需求還是從用戶現場獲取到的。
至于這個比例只有48.5%的原因，我們認為這應該是由于并不是所有的開發人員都會去做或者去了解需求獲取的手段和方式，因此大部分開發人員其實是不需要到用戶現場的，尤其是由于人員變動后來進入到項目組中的開發人員是不了解需求獲取的最初狀態的。
3、 迭代開發獲取需求
首先應該認同一點：迭代開發獲取需求與現場客戶獲取需求兩者之間是不矛盾的，而且正常來說后者應該與前者的比例是相近的。
迭代開發獲取需求一方面是因為國內用戶對想要開發的項目的不確定性，這不僅在國內，在國際上也是同樣存在的，否則，迭代化開發不會成為目前最流行也最強力的過程論之一。甚至RUP與XP等國際上最著名的開發過程都是以迭代化思想為基礎搭建起來的。
迭代開發獲取需求并不復雜，其實這也可以看作是原型法的一個展現形式，不斷地將已獲取的用戶需求進行實現，用戶在看到已實現的功能的基礎上進一步提出自己更深一層的理解和要求。這樣不斷輪回提升的方式，就是迭代過程的體現。這也符合人類對事物的認識過程，從表象到本質的理解過程，從剛開始的表層理解逐漸過渡到深層次的用戶意識目的的理解，從簡單的操作電子化到深層次的業務過程重組和整合，然后經過幾年的數據積累后再逐漸到專家系統和輔助決策支持系統。
參考問卷
4． 您所在的公司或項目組是否選用了迭代的開發方式？
沒有采用 沒有采用但很想采用 已經采用但不徹底 已經采用并比較徹底
迭代化的思想已經在中國的開發人員中有了很深入的影響，但是，真正懂得如何應用的卻并不多。從下表中可以看到，其中46.1%的人士沒有采用的，47.5%的人使用的不徹底，采用并且比較徹底的只有6.4%，而部分采用的占有最大的份額47.5%。
圖表 4 開發者公司或項目組對迭代開發方式的應用狀況
這里可以看到一個中國軟件業十分嚴峻的問題，那就是開發過程中的迭代方法到底是什么，到底如何使用，到底如何應用迭代思想才能幫助我們更好的處理軟件開發中遇到的問題。
6.4%的人認為公司使用得很徹底，這一點從一個側面表現出問題2中的使用RUP和XP的60.3%的人也并不是徹底采用RUP和XP來進行開發的，因為RUP與XP的基礎都是迭代化思想，而這里看到的最多只有52.5%的人認為他們公司在使用迭代化思想進行軟件開發，這中間差異的7.8%說明了什么？
這兩組數據的對比說明國內技術人員對于什么是RUP什么是XP以及什么是迭代還并不能很正確的理解，更不用說，真正的將這些概念能夠投入到真實的軟件開發過程中來進行應用了。
第2節 軟件開發工具的應用狀況
n 項目管理工具應用狀況
參考問卷
5． 您所在的公司或項目組經常采用下列哪種工具進行項目管理？
Microsoft Project IBM Rational SUMMIT PMOffice primavera Project Planner Artemis Views Microsoft Team Foundation System 其它
調查顯示，現階段國內在項目管理方面所使用的工具主要是微軟的Project，它占有64.7%的比例，雖然Project一直到2002年推出真正實用的企業級項目管理版本，但是由于微軟工具使用得便利性上是深得人心的，所以，即使在功能相對較弱的情況下也能夠在國內占有較多的用戶數量。另外，IBM Rational的Summit占有201%的比例位列第二，其它工具都只占有較少的分額，比如：PMOffice的2.8%，微軟的Team Foundation System占有2.4%等等。
圖表 5 開發者的公司或項目組采用的項目管理工具分布狀況
國內使用項目管理工具除了用它來制定甘特圖的計劃表之外，還很少有企業用到Project的資源分配，日程管理，進度控制，任務分發等更復雜更高級的功能。
國內企業在項目管理上限于用戶需求頻繁變更的困境和管理人員的技能水平問題使得他們無法在項目管理上采用有效的計劃手段，可以說絕大多數公司仍然處于計劃與實際執行的部分脫節甚至完全脫節而無關的狀態下。
另外，項目管理的工具有很多種，項目管理較為成熟的企業一般都會考慮根據自己的特點開發一些相關的輔助工具，另外，除了Project等計劃管理工具外，常用的工具還有Excel等，很多管理規范的公司都是采用諸如Excel這類的表格工具進行周計劃和細節實施計劃制定和檢查的，而對于Project等工具則是用來指定宏觀計劃，或者說給領導和客戶看的理論執行計劃，而這才是計劃執行的實質。
參考問卷
6． 在您的工作中，是否會涉及項目管理的工作？
是 否
調查顯示，國內的開發者有76.8%的人的工作內容中涉及到項目管理工作，而只有23.2%的人不涉及到項目管理工作。
圖表 6 開發者在工作涉及項目管理工作的狀況
從這里我們可以看出國內軟件企業的項目管理工作是相當混亂的，單純從企業項目管理團隊的人數比例來看，這個涉及到項目管理工作的比例是何其得高。而由于我們這個行業和網絡與計算機的關系，使得我們這個行業的從業人員應該是全員上網，而不是只有管理層才可以方便行使的權力。所以，上面我們看到的數據應該可以認為是全部項目組成員中涉及到項目管理工作的人數居然達到了76.8%，這個數據可以告訴我們，國內的項目管理是何等的混亂，團隊的穩定性是何等得差。因為，只有當團隊不穩定的時候，才會出現較多的人的工作內容會涉及到項目管理工作，很多軟件開發者都經歷過剛開始只是一個最初級的編碼人員，由于其它人員的離職，他從初級程序員變成高級程序員到整個項目的主程序員，而到了項目結束的時候，已經不得不承擔項目經理的角色的實際情況。
而正因為國內企業對員工利益的漠視，這使得軟件開發者一年跳槽十多次都成為一種可能。而在一個相對穩定的開發團隊中涉及到項目管理的人應該不超過30%，而這樣，這個團隊才會有足夠的技術積累，才能不斷地提升團隊的整體技術水平，并保證團隊的穩定性。而從上面這幅圖中，我們不得不為此擔心，而這個擔心，也是我們對整個中國軟件業和軟件從業人員的擔心。
參考問卷
7． 以下哪些因素是您覺得在選擇項目管理工具是最重要的？
品牌形象 簡單易用 靈活 功能強大 有良好的技術支持及資源 能提供強大的項目管理咨詢服務 其它
開發者再項目管理工具選擇上的考慮首先是簡單易用性，它占有了最大的35.0%的比例，其后依次為良好的技術支持及資源17.2%，功能強大14.8%，靈活性12.0%，能提供強大的項目管理咨詢服務10.7%和品牌形象9.3%，后面這五個部分基本上沒有較大的比例差異。
圖表 7 開發者選擇項目管理工具所關注的因素
從這這個比例差異上我們可以看到，國內開發人員在選擇工具的時候主要是考慮簡單易用性，其他的因素都是排列其后的，這也是Project占有較大用戶數的一個根本原因，而微軟產品的簡單易用性是他的傳統，也是全世界用戶對它的最大認可度。
在這里可以看到靈活性其實和簡單易用是具有一致性的，，而剩下的除了有良好的技術支持及資源與功能強大這兩項要求外，其他的都是比例較小的，微軟的Project工具在功能上自2002版發布后，才可以稱得上是強大，而微軟可以提供良好的技術支持及資源，所以，這也是微軟的Project能夠占有較大用戶數的原因之一。
從只占有10.7%的能提供強大的項目管理咨詢服務來看，國內對軟件咨詢業和從業人員的認同程度也在逐漸的提升，這也許是一些已經對國內老板失望的經驗相對較為豐富的技術人員可以考慮的一項未來的職業發展方向。
n 項目需求管理工具應用狀況
參考問卷
8． 您是否親自做需求管理的工作？
是 否
需求管理是一個項目過程中必須要做的事情，只有做了需求管理，其管理過程才是真正具有了一定的規范性，因此在CMM2評估中的第一項要求就是需求管理。調研數據表明，國內有59.8%的技術人員親自參與到需求管理工作中，而不作需求管理的只有40.2%。
圖表 8 開發者在工作涉及需求管理工作的狀況
這張圖表一方面說明了中國企業開始認同并逐漸將需求管理投入到開發實踐過程中，但同時需求管理做的也較為混亂，另一方面說明中國軟件開發者面對的用戶業務需求的變化實在是很頻繁。
需求管理真正在中國大陸推行起來的時間應該是2001到2002年間，到現在月來越多的企業開始重視需求管理，并開始將之投入到開發管理實踐過程中。但是，在正常的軟件開發過程中，需求管理在一個人數為三十人以內的項目組中只需要一個人就可以負責來完成，在一百人以內的項目組中根據不同的項目情況也不需要超過五個需求管理人員，而這里卻達到了超過半數的59.8%的比例，這一方面說明中國的軟件開發者不得不在各個階段來面對需求變更的問題，另一方面說明軟件開發過程中的需求管理工作仍然相對處于混亂狀態，并不是專人負責，職責明確的分工合作，中國軟件業的規范化還有相當長的道路需要走。
用戶業務需求變化的頻繁程度可以從這里也可以看到，只有當用戶需求頻繁變化的時候，軟件開發者才會因為需要應對需求的變化而不得不與需求管理工作打交道，這也使得軟件開發者認為自己都在親自做需求管理。而當需求相對較為穩定的情況下，軟件開發者所面對的需求變更次數不是頻繁到必須每一個業務模塊的開發者都必須進行多次的需求變更工作，那么軟件開發者就不會都認為自己是親自在做需求管理工作，因為將這項工作轉交給指定的需求管理員也是一種更高效更規范化的操作方式，同時也會減輕自己在開發過程中受到外在影響而不得不改變工作頻率導致工作效率降低的一種有效措施。