正文
  

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