發(fā)布時間：2022-08-26 03:43:00
序言：寫作是分享個人見解和探索未知領(lǐng)域的橋梁，我們?yōu)槟x了8篇的測試項(xiàng)目總結(jié)樣本，期待這些樣本能夠?yàn)槟峁┴S富的參考和啟發(fā)，請盡情閱讀。
關(guān)鍵詞 EPC；總承包項(xiàng)目；前期階段；項(xiàng)目策劃；可持續(xù)發(fā)展
中圖分類號F74 文獻(xiàn)標(biāo)識碼A 文章編號 1674-6708（2013）84-0026-02
隨著我國市場經(jīng)濟(jì)體制的不斷發(fā)展與完善，我國的國民經(jīng)濟(jì)逐步進(jìn)入了穩(wěn)定增長的階段，我國的城市化進(jìn)程的步伐越來越大、越來越快，我國的工程承包項(xiàng)目越來越多，EPC作為我國工程總承包項(xiàng)目的重要組成部分，逐漸的被應(yīng)用于我國各個行業(yè)工程的建設(shè)過程當(dāng)中，其中最為明顯的當(dāng)屬我國的石油行業(yè)，隨著EPC總承包模式在我國工程建設(shè)過程中的不斷發(fā)展越完善，我國的EPC總承包模式已經(jīng)越來越成熟，但是不可避免的EPC總承包模式在發(fā)展過程中同樣的產(chǎn)生了一些不利于工程項(xiàng)目正常發(fā)展的不利因素，文章就目前我國EPC總承包模式的前期階段的項(xiàng)目策劃過程中存在的問題進(jìn)行了系統(tǒng)分析和調(diào)查，并針對我國EPC總承包模式的前期階段的項(xiàng)目策劃過程中存在的問題提出了幾點(diǎn)建議，希望能對EPC總承包模式實(shí)現(xiàn)可持續(xù)發(fā)展提供適時的參考。
1 EPC總承包模式的概述
EPC其實(shí)指的就是我們通常所說的工程總承包，EPC（EPC——Engineering Procurement Construction），它的中文漢語意思就是設(shè)計(jì)、采購、施工，是指工程項(xiàng)目的承包部門對工程項(xiàng)目建設(shè)過程中的設(shè)計(jì)、采購和施工的全過程的管理和承包，EPC總承包模式還有另外的一種的名稱，EPC總承包模式又被稱為是交鑰匙工程總承包，EPC工程因本身具有高效率、低成本的優(yōu)勢受到了我國各個行業(yè)的青睞，EPC總承包模式最初在外國得到了廣泛的應(yīng)用，后來逐漸的被應(yīng)用于我國的各個行業(yè)的工程項(xiàng)目承包過程當(dāng)中。
2 EPC總承包模式的前期階段項(xiàng)目策劃的重要性
2.1 前期項(xiàng)目策劃的重要性
EPC總承包模式的實(shí)質(zhì)含義是指對整個工程項(xiàng)目的承包過程的設(shè)計(jì)、采購以及施工進(jìn)行全程、全方位的監(jiān)督和管理，而EPC項(xiàng)目總承包項(xiàng)目的前期階段的項(xiàng)目策劃則是對承包工程的工作內(nèi)容及工作內(nèi)容進(jìn)行策劃的過程，EPC總承包模式的前期階段項(xiàng)目策劃直接影響著整個項(xiàng)目的可行性，直接決定了此工程項(xiàng)目能夠獲得審批，前期階段的項(xiàng)目策劃在整個EPC總承包模式的運(yùn)行過程中發(fā)揮著十分重要的作用，是總承包項(xiàng)目運(yùn)行過程中的關(guān)鍵環(huán)節(jié)，項(xiàng)目前期階段的策劃的科學(xué)性和合理性直接關(guān)注著整個項(xiàng)目運(yùn)行的效果，對項(xiàng)目能夠?qū)崿F(xiàn)高效、有效的運(yùn)行發(fā)揮著十分重要且不可替代的作用。
2.2 前期項(xiàng)目策劃直接關(guān)系著項(xiàng)目的成敗
一般而言，判斷一個項(xiàng)目是否具有可行性，首先要看的就是該項(xiàng)目是否符合我國市場的需要，是否能夠解決或者是緩解市場經(jīng)濟(jì)發(fā)展過程中存在的供求矛盾，由此我們不難看出，前期階段的項(xiàng)目策劃直接關(guān)系著整個項(xiàng)目的成敗，如果前期項(xiàng)目策劃做的好，能為企業(yè)帶來巨大的經(jīng)濟(jì)效益和社會效益，促進(jìn)企業(yè)的經(jīng)濟(jì)發(fā)展，但是，如何前期項(xiàng)目策劃做的不夠合理，則會直接導(dǎo)致項(xiàng)目的流產(chǎn)，可能還會造成巨大的資金浪費(fèi)，不利于企業(yè)經(jīng)濟(jì)的可持續(xù)發(fā)展。
2.3 前期階段策劃具有綜合性
項(xiàng)目的運(yùn)行過程中，所有的環(huán)節(jié)之間都具有十分緊密的聯(lián)系，項(xiàng)目的管理作為一項(xiàng)科學(xué)的、合理的、有效的管理活動，需要在工作過程中通過對專業(yè)知識的合理、靈活運(yùn)用，確保項(xiàng)目施工過程中的科學(xué)性和合理性，實(shí)現(xiàn)項(xiàng)目的高效運(yùn)行，為企業(yè)獲取理想的經(jīng)濟(jì)效益和社會效益，在項(xiàng)目管理工作的開展過程中需要對項(xiàng)目進(jìn)行策劃、設(shè)計(jì)、項(xiàng)目運(yùn)行的進(jìn)度、項(xiàng)目運(yùn)行的質(zhì)量進(jìn)行管理和控制，項(xiàng)目的管理工作是貫穿于整個項(xiàng)目全過程當(dāng)中的，為實(shí)現(xiàn)項(xiàng)目運(yùn)行的最終目標(biāo)，促進(jìn)企業(yè)的經(jīng)濟(jì)發(fā)展提供保障。
3 EPC總承包模式的前期階段項(xiàng)目策劃過程中存在的問題
3.1 相關(guān)的法律法規(guī)存在漏洞
近些年來，隨著我國市場經(jīng)濟(jì)體制的不斷發(fā)展與完善，我國的對各個行業(yè)發(fā)展過程中需要遵守的法律法規(guī)和行為準(zhǔn)則也逐步的建立和完善，但是，根據(jù)對我國目前EPC總承包項(xiàng)目的前期階段項(xiàng)目策劃的相關(guān)情況的調(diào)查分析表明，目前我國對工程項(xiàng)目承包方面的法律法規(guī)的制定還是存在一些細(xì)微的漏洞和缺陷，對工程項(xiàng)目總承包招標(biāo)過程中的管理規(guī)定還不夠健全，導(dǎo)致部分政府和相關(guān)的管理部門在對工程項(xiàng)目總承包招標(biāo)過程中進(jìn)行監(jiān)督和管理時缺乏相應(yīng)的法律依據(jù)；同時，我國的工程總承包合同沒有進(jìn)行統(tǒng)一化、規(guī)范化的制定，在工程項(xiàng)目的總承包過程中，沒有標(biāo)準(zhǔn)的工程總承包合同的示范文本，致使很多的項(xiàng)目工程在施工過程中因?yàn)楫?dāng)初簽訂的EPC總承包合同對權(quán)責(zé)的劃分不明確，內(nèi)容制定的不夠完整、全面，對工程的造價和投資控制無法給予指導(dǎo)性的意見，給EPC總承包項(xiàng)目的前期階段的項(xiàng)目策劃工作的順利展開增添了不小的阻礙。
3.2 缺乏項(xiàng)目管理專業(yè)人才
影響我國EPC總承包模式的前期階段項(xiàng)目策劃不能順利開展的不利因素除了我國對EPC總承包模式相關(guān)方面的法律法規(guī)不健全外，還有一個十分重要的原因就是我國的項(xiàng)目的主辦方的缺乏專業(yè)的項(xiàng)目管理人才，正是由于我國業(yè)主方在工程項(xiàng)目管理過程中專業(yè)人才的缺失，導(dǎo)致項(xiàng)目總承包商之間相互扯皮的現(xiàn)象頻繁的出現(xiàn)，雖然我國已經(jīng)對工程項(xiàng)目實(shí)行項(xiàng)目管理（project management PM）的管理方式，并加大了政府的對工程項(xiàng)目的監(jiān)管力度，但是并沒有從根本上解決這一問題，給項(xiàng)目工程運(yùn)行質(zhì)量埋下了極大的風(fēng)險隱患。
4 提高我國EPC總承包模式的前期階段項(xiàng)目策劃的有效性的措施分析
4.1 建立健全的法律法規(guī)
為了提高我國EPC總承包項(xiàng)目的前期階段項(xiàng)目策劃的有效性，確保EPC總承包模式優(yōu)越性能的能夠得到充分的發(fā)揮，國家首先要做的就是建立健全的項(xiàng)目承包方面的相關(guān)法律法規(guī)，制定科學(xué)的、合理的、嚴(yán)謹(jǐn)?shù)墓こ炭偝邪O(jiān)督管理辦法和準(zhǔn)則，制定統(tǒng)一的、規(guī)范的工程承包合同范本，加大對工程總承包項(xiàng)目的法律監(jiān)管力度，在對承包單位進(jìn)行管理的同時，還需要加大對業(yè)主的監(jiān)督和管理力度，要求業(yè)主和工程項(xiàng)目的承包商對項(xiàng)目所采取的所有活動都必須嚴(yán)格遵守我國頒發(fā)的《工程總承包合同范本》以及《工程總承包招標(biāo)投標(biāo)管理辦法》中的相關(guān)規(guī)章制度的要求采取科學(xué)、合理的措施，確保項(xiàng)目運(yùn)行最終目標(biāo)的實(shí)現(xiàn)。
4.2 加大對EPC總承包模式的宣傳力度
在我國的，工程承包項(xiàng)目的方式有主要有四種，分別是設(shè)計(jì)采購施工（EPC）、設(shè)計(jì)—施工總承包（D-B）、采購總承包（E-P）以及采購—施工總承包（P-C）四種總承包方式，但是，由于我國很多的業(yè)主對EPC總承包模式的重要性和優(yōu)越性認(rèn)識不到位，導(dǎo)致業(yè)主對EPC總承包模式的認(rèn)可性過低，因此，相關(guān)的管理部門一定要加強(qiáng)對EPC總承包模式優(yōu)越性的宣傳力度，提高社會各界對EPC總承包模式的認(rèn)識程度，確保一提到EPC，大家就都知道是一種項(xiàng)目的總承包方式，就會聯(lián)想到EPC總承包方式具有高效率、低成本、性價比高等優(yōu)勢，促進(jìn)我國EPC總承包模式的不斷發(fā)展與完善，同時確保了EPC總承包項(xiàng)目的前期階段項(xiàng)目策劃的科學(xué)性和合理性，確保企業(yè)能夠獲取理性的經(jīng)濟(jì)效益和社會效益，促進(jìn)我國經(jīng)濟(jì)的可持續(xù)發(fā)展。
5 結(jié)論
總之，EPC總承包作為一種工程項(xiàng)目的承包方式，在不斷的發(fā)展過程中取得了一系列可喜的成績，但是，EPC總承包模式還不夠成熟，還需要根據(jù)我國市場經(jīng)濟(jì)的發(fā)展變化進(jìn)行適當(dāng)?shù)难a(bǔ)充和完善，這樣才能為企業(yè)帶來更多的經(jīng)濟(jì)效益和社會效益，促進(jìn)企業(yè)的健康發(fā)展，為實(shí)現(xiàn)我國經(jīng)濟(jì)的可持續(xù)發(fā)展戰(zhàn)略提供保障。
參考文獻(xiàn)
[1]李新華.試談國際EPC總承包模式前期啟動階段的PMC管理[J].石油工業(yè)技術(shù)監(jiān)督，2011（25）.
[2]申月紅.培育發(fā)展工程總承包和工程項(xiàng)目管理企業(yè)——建設(shè)部建筑市場管理司副司長王早生訪談錄[J].建筑經(jīng)濟(jì)，2011（31）.
[3]R.Max Wideman. Project and Program Risk Management： A Guide to Managing Project Risks and Opportunities [J].Project Management Institute，2010（37）.
[4]梁繼承，趙磊.天然氣輸氣工程項(xiàng)目EPC管理與實(shí)踐[J].中國石油和化工標(biāo)準(zhǔn)與質(zhì)量，2011（31）.
【關(guān)鍵詞】手機(jī)軟件設(shè)計(jì) 軟件快速重建模式 軟件項(xiàng)目過程 軟件質(zhì)量
1 軟件需求繼承性的管理
對于目前的手機(jī)設(shè)計(jì)公司來說承接的業(yè)務(wù)大多數(shù)是需求有繼承性的項(xiàng)目，對于需求的差異性很大，開發(fā)需求很復(fù)雜且之前不是很有積累的需求，無論是手機(jī)設(shè)計(jì)方案商還是手機(jī)制造商來說都是很謹(jǐn)慎的。大家對于這里的風(fēng)險意識都是一樣的強(qiáng)烈。所以一般情況下手機(jī)設(shè)計(jì)公司承接的都是有軟件需求可以繼承之前有積累的項(xiàng)目。而對于這些需求的繼承性的管理是快速實(shí)現(xiàn)這些需求的軟件項(xiàng)目的關(guān)鍵。如何實(shí)現(xiàn)這些軟件需求的高效繼承使用呢？
1.1 使用合適的軟件項(xiàng)目版本管理工具
軟件項(xiàng)目的版本管理工具中CVS， Git， Repo等都可以用來管理手機(jī)軟件項(xiàng)目的開發(fā)過程。其中Git和Repo是用于多方合作的分布式版本控制系統(tǒng)，它就適合于類似目前的智能手機(jī)開發(fā)管理的現(xiàn)狀。這里涉及手機(jī)硬件平臺的方案提供商，手機(jī)軟件提供商，還有手機(jī)設(shè)計(jì)公司共同開發(fā)一個項(xiàng)目。關(guān)鍵是Git 和Repo能夠方便的實(shí)現(xiàn)各種需求在軟件版本上的繼承和快速的合入。一般Git和Repo上會建有主線（master）工程，這里主要是平臺的基礎(chǔ)內(nèi)容，各種軟件平臺上開發(fā)出的新內(nèi)容都往上添加，是平臺發(fā)展的基礎(chǔ)。當(dāng)然主線上的內(nèi)容由于來自各種開發(fā)的新內(nèi)容的導(dǎo)入，往往存在有各種問題，而且主線是實(shí)時被更新，也來不及測試它的穩(wěn)定性。鑒于上述的狀況一般真正要實(shí)現(xiàn)的項(xiàng)目都是在一定狀態(tài)的主線上建立起來的分支進(jìn)行單獨(dú)管理的，對于分支（branch）上的管理是需要軟件項(xiàng)目負(fù)責(zé)人（SPL）來管控的。SPL（Software Project Leader）對于開發(fā)（包括MMI和Driver ）的工作成果，根據(jù)各個項(xiàng)目的需求點(diǎn)對點(diǎn)地合入各自項(xiàng)目的分支，如：用Git指令git cherry-pick。每種不同的軟件需求，這里主要是指人機(jī)交互（MMI）上的功能需求，在某個平臺上有了一個完整的需求功能分支，并且這個分支的軟件產(chǎn)品已經(jīng)量產(chǎn)且被市場認(rèn)可驗(yàn)證過，那么后續(xù)相似的項(xiàng)目都可以用來繼承該分支。那么越是后來的項(xiàng)目越是能繼承之前項(xiàng)目的成果，它實(shí)現(xiàn)的過程就能更加的快捷和可靠，實(shí)現(xiàn)軟件的復(fù)用。
1.2 對于需求和共性Bug建立良好的文檔管理機(jī)制
對于需求的繼承光有版本管理工具的分支管理是不夠的，畢竟管理工具上記錄的每條提交記錄（Commit Infomation）都是離散的，同時由于提交時的不謹(jǐn)慎，可能導(dǎo)致相同功能模塊的多次提交，這樣就要求SPL（Software Project Leader）在合入時要清晰了解合入的順序和具體的Commit ID信息。所以有一份詳細(xì)的功能合入文檔信息就很有必要了。文檔里需要記錄的內(nèi)容有：
（1）需求或者Bug的詳細(xì)描述，需求和Bug在他們各自管理系統(tǒng)里的信息記錄。
（2）Bug處理責(zé)任人的信息。
（3）對應(yīng)修改所涉及的makefile里的宏控制信息。
（4）提到到軟件管理工具（Git）的Git log信息，按提交順序記錄。這里的信息要具體到文件和其目錄。
（5）簡單描述修改處理的方法。
這樣的信息要根據(jù)不同的需求分別建立起來，開發(fā)人員要在對應(yīng)的文檔里更新迭代。上面提到的Bug主要是共性Bug。
1.3 需求共性Bug核對自動化點(diǎn)檢機(jī)制
運(yùn)用腳本工具在軟件編譯前對一些關(guān)鍵需求和重要共性Bug的合入情況做自動化的點(diǎn)檢工作，在編譯的初期就對相關(guān)內(nèi)容在整個軟件工程里的配置情況進(jìn)行自動化點(diǎn)檢。如果軟件配置有問題就可以在編譯開始時就被檢查出來，讓SPL盡早發(fā)現(xiàn)和修改。這里就需要前面的文檔管理工作做的好一些，既可以作為記錄讓那個項(xiàng)目參與人員查閱，同時也要適合自動化點(diǎn)檢工具用來查詢比較使用。這里可以被自動化工具用來點(diǎn)檢的項(xiàng)有：
（1）平臺的共性bug；
（2）硬件資源的配置狀態(tài)如：PCM（phase change memory），G-sensor；
（3）平臺共性修改需求，如：YunOS系統(tǒng)驗(yàn)收規(guī)則。
1.4 對于不同項(xiàng)目間進(jìn)行需求分析，準(zhǔn)確判斷之間的繼承性關(guān)系
要讓上面3點(diǎn)發(fā)揮作用，首先要對于需求之間是否有繼承性要有精準(zhǔn)的判斷。對于同一個客戶的需求往往判斷其繼承性很容易，因?yàn)橥粋€客戶他們的某個需求在不同項(xiàng)目間會有繼承。但是對于不同客戶之間的需求往往也存在的很大的相似性，那么如果能準(zhǔn)確找出從一個合適的成熟量產(chǎn)項(xiàng)目的分支上進(jìn)行繼承做，自然也會事半功倍。當(dāng)然并非說成熟量產(chǎn)項(xiàng)目就一定沒有問題，如果主線（master）上確認(rèn)有很重要的內(nèi)容需要合入分支，那也是要在各個項(xiàng)目分支上實(shí)時合入的。比如MTK或者Spreadtrum釋放的重要平臺patch等。這也可以用類似被上面第1.2點(diǎn)提到的文檔進(jìn)行管理的。需求的共性特性需要前方的客戶經(jīng)理來主導(dǎo)判斷，因?yàn)樗麄兏煜た蛻粜枨?，后端的SPL當(dāng)然是這個繼承行為的實(shí)施者。
2 項(xiàng)目系統(tǒng)配置和驅(qū)動配置的敏捷切換
實(shí)踐當(dāng)中項(xiàng)目部門在立項(xiàng)過程中有意識的做一些固定的切換來適應(yīng)市場的需要，比如軟件需求基本不變的情況下引導(dǎo)客戶做手機(jī)頻道的切換，比如從TDD的三模（如表1）切換成五模（如表2）或者6模（全網(wǎng)通）。
對于這樣項(xiàng)目的切換，如果總是從方案商提供的默認(rèn)的頻段配置方式出發(fā)來配置工程，那么對于一個三模切換到五模的項(xiàng)目總是要從五模配置的方案商提供的Release參考makefile和工程目錄配置方式出發(fā)，那么原來三模配置項(xiàng)目中的makefile里的關(guān)于軟件項(xiàng)目的配置選項(xiàng)，比如宏，比如工程目標(biāo)目錄里的配置項(xiàng)涉及到該客戶的軟件需求的都要移植過來，當(dāng)然就還要在重新測試需求。因?yàn)檫@個過程中需求相當(dāng)于重新移植配置。這個過程對于一個項(xiàng)目來說本身無可厚非，但是對于敏捷實(shí)現(xiàn)一個項(xiàng)目來說，它不但當(dāng)SPL重新移植了客戶需求，同時增加了客戶需求測試點(diǎn)檢的需要，從整體上講這種重建工程的方式對于該項(xiàng)目的重建的成本投入就很高了。如果換種思路，如果開發(fā)中的驅(qū)動工程師能從根本上就總結(jié)好從三模的項(xiàng)目配置改成五模的項(xiàng)目配置過程中需要修改的配置項(xiàng)，只要總結(jié)好一次且驗(yàn)證OK的情況下，下一次配置的時候就能輕松重建，這樣的總結(jié)對于不斷有這種項(xiàng)目切換的項(xiàng)目團(tuán)隊(duì)來說是很有益處的。它使得項(xiàng)目重建過程更為簡單且引入的問題控制在一個范圍里。即便真有頻段配置的問題項(xiàng)目團(tuán)隊(duì)也能清晰知道問題所在的范圍。如果過分堅(jiān)持驅(qū)動工作的流程就是要從方案Release狀態(tài)的五模參考配置方式出發(fā)，雖然從驅(qū)動工作的角度出發(fā)，可能提高的配置的正確性，但是對于整體項(xiàng)目的推進(jìn)卻是添加了阻力的。相反針對項(xiàng)目需要敏捷切換的顯示做一些系統(tǒng)配置工作的方式切換卻可以使得原來三模項(xiàng)目的客戶需求修改被更好的被繼承，同時測試的反復(fù)缺失需求也可以不那么必要了，整體上來說就有進(jìn)度推進(jìn)的優(yōu)勢，而對于驅(qū)動本身來說，只要做一次這樣的認(rèn)真切換工作的研究，下一次也是可以很快的重建這個過程，所需要的只是一次認(rèn)真的總結(jié)。這種各種需求的來回切換需要不同的支持不能綜合考慮支持，盡量從整體項(xiàng)目進(jìn)度推進(jìn)的角度出發(fā)來綜合考慮問題，而不是單個從某項(xiàng)工作的角度的出來來判斷這樣做是否合理。即便需要某項(xiàng)工作做一些較難的整理總結(jié)，但是對于后續(xù)項(xiàng)目切換過程中能給更多的項(xiàng)目帶來便利的話，這樣的總結(jié)也是應(yīng)該去做的。
3 對于有需求繼承性的項(xiàng)目快速重建過程中配套的軟件測試策略的改進(jìn)
對于這種繼承性很強(qiáng)的項(xiàng)目來說，如果項(xiàng)目本身確實(shí)是有效繼承于一個成熟的量產(chǎn)項(xiàng)目。針對這樣項(xiàng)目的測試流程也應(yīng)該和普通項(xiàng)目的流程不一樣。首先針對這樣的項(xiàng)目應(yīng)該在前期先要安排這個項(xiàng)目的客戶需求的逐項(xiàng)點(diǎn)檢確認(rèn)，看看需求是不是繼繼承好。一旦項(xiàng)目繼承前面的需求分支后，出的初期軟件就應(yīng)該可以點(diǎn)檢了，測試部門應(yīng)該在之前做項(xiàng)目的時候可以對于項(xiàng)目的需求做好測試文檔記錄規(guī)律工作，對于已經(jīng)做過的共性需求記錄好點(diǎn)檢的測試案例，后面找測試工程師點(diǎn)檢需求的時候可以快速的根據(jù)之前的記錄進(jìn)行點(diǎn)檢，設(shè)置可以開發(fā)自動化測試工具來點(diǎn)檢。同時需求確認(rèn)后就可以判斷驗(yàn)證已知的平臺共性Bug的合入修改情況。如果這兩點(diǎn)能在測試首輪就確認(rèn)好，軟件質(zhì)量的基調(diào)就能定下來了。當(dāng)然如果項(xiàng)目的器件做了切換，也要盡早確認(rèn)器件的功能性測試，也可以適當(dāng)關(guān)注這些的性能表現(xiàn)。如果第一輪的這些測試都做好且效果OK，當(dāng)然即便有一些問題，也能讓軟件團(tuán)隊(duì)盡早先修改繼承需求過程中產(chǎn)生的問題。也可以把器件的問題也在較早的時間段就發(fā)現(xiàn)出來。這樣的軟件基本也可以和客戶一起同步測試了?？蛻裟玫降能浖杏X繼承性較好的話，對于軟件開發(fā)的進(jìn)程也會較有信心。第二輪的時候選著適當(dāng)?shù)臏y試強(qiáng)度的固有測試用例跟進(jìn)這個項(xiàng)目的軟件測試。如果機(jī)器數(shù)量可觀且狀態(tài)良好的情況下可以盡早安排模擬終端用戶使用的alpha測試。這樣的模擬能找到正常測試案例里找不到的問題，同時客戶也是更多的偏向于這種方式發(fā)現(xiàn)問題的。
4 總結(jié)
為了做到手機(jī)軟件項(xiàng)目的有效繼承需求，快速實(shí)現(xiàn)衍生項(xiàng)目的工程重建。要在以下各個方面做了些努力：
（1）做好軟件項(xiàng)目需求繼承性的管理工作，對于有繼承性的項(xiàng)目要做好軟件版本分支管理，Bug管理，共性需求分析工作。開發(fā)使用一下自動化檢查工具來實(shí)現(xiàn)共性需求和Bug的合入情況的檢查。
（2）同時對于重建概率加高的一些開l需求做一些總結(jié)整理，確認(rèn)整理的內(nèi)容有效后可以使得后續(xù)項(xiàng)目對于這些需求在SPL的需求分支上復(fù)現(xiàn)的過程可以快捷高效。
（3）配合這種需求繼承性強(qiáng)的項(xiàng)目以合適的測試流程。從需求繼承和Bug修改繼承出發(fā)，先驗(yàn)證已知的問題和需求的繼承情況，再確認(rèn)系統(tǒng)穩(wěn)定性的測試策略。
通過上述環(huán)節(jié)綜合作用使得項(xiàng)目的進(jìn)度能快速推進(jìn)并且項(xiàng)目質(zhì)量也能得到一定的保證。
參考文獻(xiàn)
[1]薩默維爾著；程成等譯.軟件工程（原書第9版）[M].北京：機(jī)械工業(yè)出版社，2011（04）：144-146.
[2]Leszek A.Maciaszek著；馬素霞，王素琴，謝萍等譯.需求分析與系統(tǒng)設(shè)計(jì)[M].北京：機(jī)械工業(yè)出版社，2009（05）：60-61.
[3]楊芙清，梅宏，李克勤.軟件復(fù)用與軟件構(gòu)件技術(shù)[J].電子學(xué)報，1999，27（02）：68-75.
作者簡介
嚴(yán)王君 （1981）男，大學(xué)本科學(xué)歷。學(xué)士學(xué)位。中級工程師，軟件集成主管。主要研究方向?yàn)榍度胧较到y(tǒng)軟件MMI開發(fā)，軟件系統(tǒng)集成。
一、項(xiàng)目實(shí)施方案概述
軟件產(chǎn)品，特別是行業(yè)解決方案軟件產(chǎn)品不同于一般的商品，用戶購買軟件產(chǎn)品之后，不能立即進(jìn)行使用，需要軟件公司的技術(shù)人員在軟件技術(shù)、軟件功能、軟件操作等方面進(jìn)行系統(tǒng)調(diào)試、軟件功能實(shí)現(xiàn)、人員培訓(xùn)、軟件上線使用、后期維護(hù)等一系列的工作，我們將這一系列的工作稱為軟件項(xiàng)目實(shí)施。大量的軟件公司項(xiàng)目實(shí)施案例證明，軟件項(xiàng)目是否成功、用戶的軟件使用情況是否順利、是否提高了用戶的工作效率和管理水平，不僅取決于軟件產(chǎn)品本身的質(zhì)量，軟件項(xiàng)目實(shí)施的質(zhì)量效果也對后期用戶應(yīng)用的情況起到非常重要的影響。項(xiàng)目實(shí)施規(guī)范主要包括項(xiàng)目啟動階段、需求調(diào)研確認(rèn)階段、軟件功能實(shí)現(xiàn)確認(rèn)階段、數(shù)據(jù)標(biāo)準(zhǔn)化初裝階段、系統(tǒng)培訓(xùn)階段、系統(tǒng)安裝測試及試運(yùn)行階段、總體驗(yàn)收階段、系統(tǒng)交接階段等八個階段工作內(nèi)容，每個階段下面有不同的工作事項(xiàng)，各個階段之間都是承上啟下關(guān)系，上一階段的順利完成是保證下一階段的工作開展的基礎(chǔ)。下面將按照每個項(xiàng)目實(shí)施階段分別介紹。
二、項(xiàng)目實(shí)施方案介紹
（一）項(xiàng)目啟動階段
此階段處于整個項(xiàng)目實(shí)施工作的最前期，由成立項(xiàng)目組、前期調(diào)研、編制總體項(xiàng)目計(jì)劃、啟動會四個階段組成。
此階段主任務(wù)：
公司：在合同簽定后，指定項(xiàng)目經(jīng)理，成立項(xiàng)目組，授權(quán)項(xiàng)目組織完成項(xiàng)目目標(biāo)。
公司項(xiàng)目組：進(jìn)行前期項(xiàng)目調(diào)研，與用戶共同成立項(xiàng)目實(shí)施組織，編制《總體項(xiàng)目計(jì)劃》，召開項(xiàng)目啟動會。
商務(wù)經(jīng)理：配合公司項(xiàng)目組，將積累的項(xiàng)目和用戶信息轉(zhuǎn)交給項(xiàng)目組。將項(xiàng)目組正式介紹給用戶，配合項(xiàng)目組建立與用戶的聯(lián)系。
用戶：成立項(xiàng)目實(shí)施組織，配合前期調(diào)研和召開啟動會，簽署《總體項(xiàng)目計(jì)劃》和《項(xiàng)目實(shí)施協(xié)議》。
1、成立項(xiàng)目組
部門經(jīng)理接到實(shí)施申請后，任命項(xiàng)目經(jīng)理，指定項(xiàng)目目標(biāo)，由部門經(jīng)理及項(xiàng)目經(jīng)理一起指定項(xiàng)目組成員及成員任務(wù)，并報總經(jīng)理簽署《項(xiàng)目任務(wù)書》。
2、前期調(diào)研
項(xiàng)目經(jīng)理及項(xiàng)目組成員，在商務(wù)人員配合下，建立與用戶的聯(lián)系，對合同、用戶進(jìn)行調(diào)研。填寫《用戶及合同信息表》。在項(xiàng)目商務(wù)談判中，商務(wù)經(jīng)理積累了大量的信息，項(xiàng)目組首先應(yīng)收集商務(wù)和合同信息，并與商務(wù)經(jīng)理一起識別那些個體和組織是項(xiàng)目的干系人，確定他們的需求和期望，如何滿足和影響這些需求、期望以確保項(xiàng)目能夠成功。
3、編制《項(xiàng)目總體計(jì)劃》
《項(xiàng)目總體計(jì)劃》是一個文件或文件的集合，隨著項(xiàng)目信息不斷豐富和變化，會被不斷變更，主要介紹項(xiàng)目目標(biāo)、主要項(xiàng)目階段、里程碑、可交付成果。通常包括以下幾方面內(nèi)容：
項(xiàng)目描述，項(xiàng)目目標(biāo)、主要項(xiàng)目階段、里程碑、可交付成果。所計(jì)劃的職責(zé)分配（包括用戶的）；
溝通管理計(jì)劃，確定項(xiàng)目干系人對信息和溝通的需要：即什么人何時需要什么信息以及通過什么方式將信息提供給他們。質(zhì)量管理計(jì)劃，確定適合于項(xiàng)目的質(zhì)量標(biāo)準(zhǔn)和如何滿足其要求。如果有必要，可以包括上述每一個計(jì)劃，詳細(xì)程度根據(jù)每個具體項(xiàng)目的要求而定。未解決事宜和未定的決策。
4、啟動會
項(xiàng)目組與用戶共同召開的宣布項(xiàng)目實(shí)施正式開始的會議。
會程安排如下：
共同組建項(xiàng)目實(shí)施組織，實(shí)施組織的權(quán)利和職責(zé)；雙方簽署《項(xiàng)目實(shí)施協(xié)議》。
項(xiàng)目組介紹《項(xiàng)目總體計(jì)劃》和《項(xiàng)目實(shí)施協(xié)議》，包括以下內(nèi)容：
項(xiàng)目目標(biāo)、主要項(xiàng)目階段、里程碑、可交付成果。所計(jì)劃的職責(zé)分配（包括用戶的）；
項(xiàng)目實(shí)施中項(xiàng)目管理的必要性和如何進(jìn)行項(xiàng)目管理，項(xiàng)目的質(zhì)量如何控制；
項(xiàng)目實(shí)施中用戶的參與和領(lǐng)導(dǎo)的支持的重要作用；
階段驗(yàn)收、技術(shù)交接和項(xiàng)目結(jié)束后如何對用戶提供后續(xù)服務(wù)。
（二）需求調(diào)研確認(rèn)階段
此階段的主要工作是軟件公司的項(xiàng)目實(shí)施人員向用戶調(diào)查用戶對系統(tǒng)的需求，包括管理流程調(diào)研、功能需求調(diào)研、報表要求調(diào)研、查詢需求調(diào)研等，實(shí)施人員調(diào)研完成后，會編寫《需求調(diào)研分析手冊》，并交付用戶進(jìn)行確認(rèn)，待用戶對《需求調(diào)研分析手冊》上所提到的需求確認(rèn)完畢后，項(xiàng)目實(shí)施人員將以此為依據(jù)進(jìn)行軟件功能的實(shí)現(xiàn)。如果用戶又提出新的需求，實(shí)施人員將分析需求的難度及對整個系統(tǒng)的影響程度來確定是否給予實(shí)現(xiàn)。需求調(diào)研階段具體包括如下內(nèi)容：
1、進(jìn)行需求調(diào)研準(zhǔn)備
2、編制《需求調(diào)研計(jì)劃》
3、內(nèi)部評審是否通過《需求調(diào)研計(jì)劃》，項(xiàng)目組、部門經(jīng)理、商務(wù)等人員根據(jù)合同要求和項(xiàng)目實(shí)際情況對《需求調(diào)研計(jì)劃》草稿進(jìn)行評審，如評審?fù)ㄟ^，則在稍后的時間內(nèi)簽署，如評審不通過則重新修改。
4、用戶是否簽署《需求調(diào)研計(jì)劃》，如用戶簽署《需求調(diào)研計(jì)劃》，則作為以后需求調(diào)研工作的指南。否則重新修改。
5、《需求調(diào)研計(jì)劃》是否有變更，如果計(jì)劃存在變更，則執(zhí)行變更控制流程，否則按計(jì)劃進(jìn)行后續(xù)工作。
6、編寫及發(fā)出《需求調(diào)研通知》，項(xiàng)目組編寫《需求調(diào)研通知》，確定進(jìn)行需求調(diào)研的相關(guān)事宜，發(fā)給用戶，為順利完成需求調(diào)研工作做準(zhǔn)備
7、需求調(diào)研，項(xiàng)目組以《需求調(diào)研手冊》為依據(jù)，從業(yè)務(wù)流程、單據(jù)使用、打印格式、報表查詢幾個方面展開深入和全面的調(diào)研，并搜集用戶的個性化需求。
8、需求調(diào)研分析根據(jù)調(diào)研的結(jié)果，項(xiàng)目組和公司其他技術(shù)部門將進(jìn)一步進(jìn)行分析，確定合理、可行的需求，將分析結(jié)果形成《需求分析報告》草稿。
9、內(nèi)部評審是否通過《需求分析報告》。項(xiàng)目組、部門經(jīng)理、公司其他技術(shù)部門的人員對《需求分析報告》草稿進(jìn)行評審，如評審?fù)ㄟ^，則在稍后由用戶簽署，如評審不通過則重新修改，直至內(nèi)部評審?fù)ㄟ^。
10、編寫及發(fā)出《需求分析報告確認(rèn)通知》。項(xiàng)目組編寫《需求分析報告確認(rèn)通知》，發(fā)給用戶，確定進(jìn)行需求確認(rèn)的相關(guān)事宜，告之相關(guān)部門及人員安排好工作，準(zhǔn)時參與需求確認(rèn)工作，為順利完成需求確認(rèn)工作做準(zhǔn)備。
11、用戶是否確認(rèn)《需求分析報告》。如果用戶確認(rèn)，并簽署了《需求分析報告》，則需求調(diào)研階段工作結(jié)束，進(jìn)行后續(xù)的軟件功能實(shí)現(xiàn)的工作；如沒有確認(rèn)，則進(jìn)一步進(jìn)行調(diào)研、分析，直至用戶最終確認(rèn)并簽署《需求分析報告》。雙方簽署了《需求分析報告》，需求調(diào)研工作結(jié)束之后，如果用戶提出新的需求或是變更已有的需求，則執(zhí)行需求新增及變更流程。
（三）軟件功能實(shí)現(xiàn)確認(rèn)階段
此階段的主要工作是項(xiàng)目實(shí)施人員根據(jù)需求調(diào)研階段確認(rèn)的《需求調(diào)研分析手冊》中的用戶需求內(nèi)容進(jìn)行具體軟件功能的實(shí)現(xiàn)工作。在軟件功能實(shí)現(xiàn)的過程中，項(xiàng)目實(shí)施人員將記錄軟件實(shí)現(xiàn)的詳細(xì)過程。便于公司售后服務(wù)之用。每一個實(shí)施技術(shù)人員必須嚴(yán)格按照要求記錄、存檔。按照調(diào)研要求的所有功能實(shí)現(xiàn)完畢后，項(xiàng)目實(shí)施人員將編制《軟件功能確認(rèn)表》，將定制好軟件功能待用戶確認(rèn)，用戶根據(jù)《軟件功能確認(rèn)表》上的功能逐一確定軟件功能是否達(dá)到要求，對不滿足要求的功能，項(xiàng)目實(shí)施人員將會記錄下來并進(jìn)行功能修改，直到滿足用于要求。
（四）數(shù)據(jù)標(biāo)準(zhǔn)化初裝階段
此階段的主要工作是項(xiàng)目實(shí)施人員指導(dǎo)用戶進(jìn)行系統(tǒng)標(biāo)準(zhǔn)化資料的準(zhǔn)備工作，并對用戶進(jìn)行初裝資料的軟件操作培訓(xùn)，以便用戶能夠及時的將標(biāo)準(zhǔn)資料錄入系統(tǒng)，初裝完成后，項(xiàng)目實(shí)施人員會對資料初裝的情況進(jìn)行核查，為以后具體業(yè)務(wù)功能的開展做好基礎(chǔ)。
（五）系統(tǒng)培訓(xùn)階段
系統(tǒng)培訓(xùn)階段工作是整個項(xiàng)目實(shí)施工作中比較重要的工作，用戶對軟件的操作功能是否熟練將直接影響到后面的軟件應(yīng)用效果，所以軟件公司和用戶雙方要對此階段的工作給予足夠的重視。要充分認(rèn)識培訓(xùn)的重要性和艱巨性。在項(xiàng)目實(shí)施之前對用戶的相關(guān)人員進(jìn)行系統(tǒng)和規(guī)范的產(chǎn)品培訓(xùn)是非常必要的，達(dá)到讓用戶了解軟件產(chǎn)品，最終自己能夠解決使用中的具體的問題。
此階段的培訓(xùn)工作中將用戶參加產(chǎn)品培訓(xùn)的人員劃分為三個層次：決策層、技術(shù)層、操作層，對不同層次的用戶參加產(chǎn)品培訓(xùn)人員的培訓(xùn)內(nèi)容分別是：
決策層：領(lǐng)導(dǎo)在實(shí)施中的作用與重要性、決策查詢。
維護(hù)層：系統(tǒng)維護(hù)知識、操作方法。
操作層：操作方法。
具體的培訓(xùn)工作流程為：
1、調(diào)研培訓(xùn)信息：在培訓(xùn)開始前3天由用戶實(shí)施負(fù)責(zé)人，將參加培訓(xùn)的部門和人員情況填入《受訓(xùn)部門匯總表》、《受訓(xùn)人員情況一覽表》。
2、編制培訓(xùn)計(jì)劃：結(jié)合調(diào)研結(jié)果，與用戶實(shí)施負(fù)責(zé)人商議具體培訓(xùn)內(nèi)容、時間，場地，人員等。項(xiàng)目組編制《培訓(xùn)計(jì)劃》。
3、簽署培訓(xùn)計(jì)劃：用戶簽署《培訓(xùn)計(jì)劃》，進(jìn)一步確認(rèn)培訓(xùn)安排。
4、發(fā)培訓(xùn)通知：培訓(xùn)開始前2天，按照簽署的《培訓(xùn)計(jì)劃》，將培訓(xùn)內(nèi)容、時間，場地，人員等信息通知用戶實(shí)施負(fù)責(zé)人。
5、搭建培訓(xùn)環(huán)境：公司項(xiàng)目組在培訓(xùn)開始前，將培訓(xùn)環(huán)境搭建及檢查妥當(dāng)，將培訓(xùn)提綱及培訓(xùn)手冊準(zhǔn)備好。
6、組織培訓(xùn)：公司項(xiàng)目組培訓(xùn)負(fù)責(zé)人與用戶實(shí)施負(fù)責(zé)人組織相關(guān)人員參加培訓(xùn)，按培訓(xùn)制度嚴(yán)格考核。由用戶將考勤情況填入《培訓(xùn)人員簽到表》。
7、培訓(xùn)考核：公司項(xiàng)目組培訓(xùn)負(fù)責(zé)人與用戶實(shí)施負(fù)責(zé)人組織受訓(xùn)人員參加上機(jī)及理論考試。
8、培訓(xùn)總結(jié)：公司項(xiàng)目組培訓(xùn)負(fù)責(zé)人與用戶實(shí)施負(fù)責(zé)人一起將出勤情況及考核情況做出總結(jié)，填入《培訓(xùn)及考核統(tǒng)計(jì)表》，及時向相關(guān)負(fù)責(zé)人
匯報。
（六）系統(tǒng)安裝測試及試運(yùn)行階段
此階段的主要工作是在用戶真實(shí)環(huán)境下，對用戶網(wǎng)絡(luò)及硬件設(shè)備進(jìn)行測試，對軟件系統(tǒng)進(jìn)行容量、性能壓力等測試測試及試運(yùn)行的目的在于確保系統(tǒng)各項(xiàng)功能均能正常使用，并且符合用戶簽署的《需求分析報告》中描述的需求，同時把盡可能多的潛在問題在正式運(yùn)行之前發(fā)現(xiàn)并改正；同時目的還在于在正式運(yùn)行前用戶的有關(guān)人員能進(jìn)一步提高操作水平，掌握操作規(guī)范。此階段的主要工作內(nèi)容為：
1、 編制計(jì)劃：與用戶實(shí)施負(fù)責(zé)人商議具體測試及試運(yùn)行時間，地點(diǎn)，人員等安排，項(xiàng)目組編制《測試及試運(yùn)行計(jì)劃》。
2、簽署計(jì)劃：用戶簽署《測試及試運(yùn)行計(jì)劃》，進(jìn)一步確認(rèn)測試及試運(yùn)行安排。
3、發(fā)測試及試運(yùn)行通知：在測試及試運(yùn)行開始前2天，按照簽署的《測試及試運(yùn)行計(jì)劃》，將時間，地點(diǎn)，人員等信息通知用戶實(shí)施負(fù)責(zé)人。
4、搭建環(huán)境及數(shù)據(jù)準(zhǔn)備：在試運(yùn)行開始前搭建好軟件環(huán)境、硬件環(huán)境、網(wǎng)絡(luò)環(huán)境、調(diào)通線路；檢查軟件、硬件、網(wǎng)絡(luò)、線路等各個環(huán)節(jié)是否有問題；
5、組織測試及試運(yùn)行：用戶相關(guān)各級領(lǐng)導(dǎo)給予全面配合，組織相關(guān)人員進(jìn)行測試及試運(yùn)行。
6、測試及試運(yùn)行總結(jié)：測試及試運(yùn)行完成，總結(jié)試運(yùn)行中設(shè)備、軟件的運(yùn)行情況，總結(jié)試運(yùn)行中業(yè)務(wù)流程和操作環(huán)節(jié)的情況，以書面總結(jié)形式將測試及試運(yùn)行結(jié)果通知相關(guān)負(fù)責(zé)人。
公司項(xiàng)目組負(fù)責(zé)擔(dān)當(dāng)指揮，檢查用戶人員組織情況并給予指導(dǎo)，跟蹤檢查如下情況：
跟蹤單據(jù)流轉(zhuǎn)狀況。
跟蹤新資料登錄環(huán)節(jié)。
觀察業(yè)務(wù)流程執(zhí)行狀況。
觀察操作人員操作表現(xiàn)。
觀察系統(tǒng)運(yùn)行速度及異常表現(xiàn)。
觀察關(guān)鍵數(shù)據(jù)的正確性。
及時糾正錯誤操作、對于新發(fā)生的問題及時與相關(guān)人員溝通，確定解決辦法。
（七）總體驗(yàn)收階段。
此階段是對項(xiàng)目總體的完成情況進(jìn)行驗(yàn)收。驗(yàn)收分階段進(jìn)行，在每一項(xiàng)目階段結(jié)束時，用戶對這一階段的可交付成果進(jìn)行驗(yàn)收，在測試及試運(yùn)行結(jié)束后，對系統(tǒng)進(jìn)行總體驗(yàn)收。
需要驗(yàn)收的可交付成果：
主要項(xiàng)目階段
階段組成
主要里程碑
可交付成果
關(guān)鍵詞：嵌入式軟件；GJB2725A；軟件測試；過程模型
0 引言
隨著信息化軍事技術(shù)的不斷深入，嵌入式軟件已在航空武器裝備軟件中得到了廣泛的應(yīng)用，相應(yīng)的，對其進(jìn)行軟件測試的要求也越來越重要。目前，大部分軟件測試項(xiàng)目主要由事件驅(qū)動完成，存在流程不清晰、被動性高、效率低下等問題，影響了測試質(zhì)量，其嚴(yán)重后果就是沒有及時發(fā)現(xiàn)軟件產(chǎn)品缺陷，導(dǎo)致產(chǎn)品失效。
總裝備部于2001年了GJB2725A《測試實(shí)驗(yàn)室和校準(zhǔn)實(shí)驗(yàn)室通用要求》[1]，其目的就是為了指導(dǎo)軟件測試活動，提高軟件測試過程管控能力。因此提出了一種嵌入式軟件測試過程模型，該模型能夠依據(jù)軍標(biāo)，以流程驅(qū)動的方式對軟件測試進(jìn)行全過程管控，具有很好的工程應(yīng)用價值，提高了研制效率。
1 嵌入式軟件測試過程模型
在型號軟件研制中，測試是一項(xiàng)復(fù)雜而繁瑣的工作，是一門綜合性學(xué)科，涉及技術(shù)、方法、資源以及管理等諸多方面[2]，現(xiàn)有流行軟件測試模型，如V模型、W模型和H模型[3]，并不能完全適用于實(shí)際測試工作，而應(yīng)由研制單位牽頭，建立本地化的軟件測試過程模型。
根據(jù)工程經(jīng)驗(yàn)，將嵌入式軟件測試過程劃分為5個階段，即測試需求分析、測試策劃、測試設(shè)計(jì)與實(shí)現(xiàn)、測試執(zhí)行和測試總結(jié)，每個階段實(shí)現(xiàn)不同的測試活動，前一個階段是后一個階段的輸入，后一個階段是前一個階段的驗(yàn)證，以流程為驅(qū)動力，逐步實(shí)現(xiàn)所有活動，通過不斷地對流程再優(yōu)化，實(shí)現(xiàn)模型的持續(xù)改進(jìn)[4]，逐步趨近實(shí)際工程應(yīng)用。
1.1 測試需求分析
該階段的輸入為軟件測評合同或軟件研制任務(wù)書，以明確被測項(xiàng)目的范圍、目標(biāo)、約束及要求。
同時，確定需要完成的測試類型，如功能測試、性能測試、邊界測試、接口測試、可靠性測試等，并明確每一個測試類型的具體要求，例如：
1）功能測試：每一個軟件測試項(xiàng)輸入的每一個正常等價類和異常等價類都至少被一個用例覆蓋；
2）性能測試：對軟件的精度、時間和適應(yīng)性進(jìn)行測試，以確認(rèn)是否符合規(guī)定的性能要求；
3）接口測試：測試所有外部接口，每一個外部輸入/輸出接口應(yīng)進(jìn)行正常和異常情況測試。
確定測試類型后，可制定測試策略，包括白盒和黑盒測試，并對具有特殊要求的被測項(xiàng)進(jìn)行具體描述。同時，確定測試充分性和終止要求，避免項(xiàng)目無法結(jié)束。
測試需求分析最重要的工作就是依據(jù)軟件設(shè)計(jì)文檔，確定測試的顯性需求和隱形需求，并分解為測試項(xiàng)，為后續(xù)測試用例提供設(shè)計(jì)依據(jù)，本階段的輸出為《軟件測試需求規(guī)格說明》。
1.2 測試策劃
本階段在測試需求分析的基礎(chǔ)上，完成如下工作：
1）確定測試技術(shù)，如等價類劃分法、邊界值分析法和猜錯法等；
2）明確定性評價準(zhǔn)則，包括文檔、設(shè)計(jì)和實(shí)現(xiàn)等方面；
3）數(shù)據(jù)采集要求，主要指被測軟件、用例、缺陷和管理數(shù)據(jù)等；
4）制定軟件測試環(huán)境，包括軟/硬件環(huán)境，確保測試順利開展；
5）明確測試人員的角色與職責(zé)，合理分工，確保進(jìn)度；
6）根據(jù)要求進(jìn)行風(fēng)險分析，如技術(shù)、人員和資源風(fēng)險，并制定措施。
本階段的輸出為《軟件測試計(jì)劃》。
1.3 測試設(shè)計(jì)與實(shí)現(xiàn)
本階段的主要內(nèi)容就是依據(jù)測試需求，設(shè)計(jì)測試用例，單元、部件測試采用“先功能后邏輯”的測試策略，即先滿足基于功能的測試（功能測試覆蓋100%），再滿足基于邏輯的測試（語句、分支、調(diào)用覆蓋率100%），配置項(xiàng)、系統(tǒng)測試采用基于功能的測試策略，測試用例主要包括名稱、標(biāo)識、初始化、前提和約束、輸入、預(yù)期輸出、通過準(zhǔn)則、追蹤關(guān)系、終止條件、用例類型和設(shè)計(jì)人員等信息，本階段的輸出為《軟件測試說明》。
1.4 測試執(zhí)行
本階段的主要內(nèi)容就是在實(shí)際測試環(huán)境下執(zhí)行測試用例，記錄測試結(jié)果，將期望結(jié)果與實(shí)測結(jié)果進(jìn)行比對，如不一致，則進(jìn)行深入分析，確認(rèn)為軟件缺陷，則填寫軟件問題報告單，本階段的輸出為《軟件測試記錄》和《軟件問題報告單》。
1.5 測試總結(jié)
本階段的主要內(nèi)容就是依據(jù)測試結(jié)果，統(tǒng)計(jì)與分析測試數(shù)據(jù)，包括用例執(zhí)行率、用例通過率、代碼缺陷率、功能覆蓋率等指標(biāo)，進(jìn)而對被測軟件產(chǎn)品做出客觀、公正、獨(dú)立的評價，為改進(jìn)軟件產(chǎn)品質(zhì)量提供支撐，本階段的輸出為《軟件測試報告》。
2 模型應(yīng)用
被測軟件為某型嵌入式軟件，要求完成軟件測試，出具測試報告。
2.1 測試需求分析
根據(jù)測試要求，定義被測項(xiàng)目的范圍、目標(biāo)、約束及要求。
范圍：單元、部件和配置項(xiàng)測試。
目標(biāo)：單元測試完成語句、分支100%覆蓋，部件測試完成調(diào)用100%覆蓋，配置測試完成需求100%覆蓋。
策略：單元、部件測試采用白盒測試，配置項(xiàng)測試采用黑盒測試。
測試需求：經(jīng)分析，單元測試共有272個測試需求，部件測試共有36個測試需求，配置項(xiàng)測試共有16個測試需求，27個測試項(xiàng)。
2.2 測試策劃
軟件測試主要采用等價類劃分法和邊界值分析法進(jìn)行測試。
2.3 測試設(shè)計(jì)與實(shí)現(xiàn)
依據(jù)軟件設(shè)計(jì)文件設(shè)計(jì)測試用例，單元測試共設(shè)計(jì)1869個測試用例，部件測試共設(shè)計(jì)266個測試用例，配置項(xiàng)測試共設(shè)計(jì)168個測試用例。
2.4 測試執(zhí)行
經(jīng)測試，并對測試結(jié)果進(jìn)行分析、確認(rèn)，共計(jì)發(fā)現(xiàn)56個軟件問題，提交設(shè)計(jì)進(jìn)行優(yōu)化改進(jìn)。
2.5 測試總結(jié)
測試結(jié)果總結(jié)如表4所示。
測試用例均能100%覆蓋測試需求，配置項(xiàng)測試的用例執(zhí)行率為95%，其原因是有些硬件環(huán)境不能滿足測試要求，如破壞性測試，單元和配置項(xiàng)測試的用例通過率均不到100%，說明這兩種測試是發(fā)現(xiàn)軟件缺陷的重要手段，通過對56個問題的歸零處理，軟件問題得到解決，提高了軟件產(chǎn)品的質(zhì)量。
3 總結(jié)
采用流程驅(qū)動式的嵌入式軟件測試過程模型能夠很好的解決測試工程化問題，通過實(shí)際運(yùn)用，提高了測試管控能力，確保了測試充分性，發(fā)現(xiàn)了軟件問題，提高了軟件的質(zhì)量和可靠性。
參考文獻(xiàn)：
[1] 閆宇華,李誼,黃寧等.GJB 2725A-2001，測試實(shí)驗(yàn)室和校準(zhǔn)實(shí)驗(yàn)室通用要求[S].北京：中國人民總裝備部，2001.
[2] 金先仲,任宏光,李建軍等.空空導(dǎo)彈研制系統(tǒng)工程管理[M].北京：國防工業(yè)出版社，2007.
關(guān)鍵詞：軟件代碼審查；代碼審查過程；代碼審查問題
中圖分類號：TP311.52文獻(xiàn)標(biāo)識碼：A文章編號：1007-9599 (2012) 03-0000-02
Discussion on the Code Review of Software Static Testing
Yuan Zhengjiang
(Jiangnan Institute of Electrical and Mechanical Design,Guiyang550009,China)
Abstract:This paper describes the software code to examine the role,content,code review process,and lists some common problems of code review.
Keywords:Software code review;Code review process;Code review problem
一、引言
軟件測試常用方法可分為動態(tài)測試和靜態(tài)測試，只有動態(tài)測試和靜態(tài)測試有效結(jié)合，才能更好的完成軟件測試工作。代碼審查是軟件靜態(tài)測試中常用的軟件測試方法之一，代碼審查時，只要測試人員方法得當(dāng)、足夠細(xì)心，往往能夠產(chǎn)生意想不到的效果。
二、代碼審查的作用
代碼審查是在不執(zhí)行軟件的條件下有條理的仔細(xì)審查軟件代碼，從而找出軟件缺陷的過程。
代碼審查可以找出動態(tài)測試難以發(fā)現(xiàn)或隔離的軟件缺陷。在開發(fā)過程初期讓測試人員集中精力進(jìn)行軟件代碼審查非常有價值：可以提高代碼質(zhì)量；在項(xiàng)目的早期發(fā)現(xiàn)缺陷，將損失降至最低；促進(jìn)團(tuán)隊(duì)溝通、促進(jìn)知識共享、共同提高。
代碼審查還可以為動態(tài)測試時設(shè)計(jì)和執(zhí)行測試用例提供思路。通過代碼審查，可以確定有問題或者容易產(chǎn)生軟件缺陷的特性范圍。
三、代碼審查的過程
代碼審查過程可分為：代碼審查策劃階段、代碼審查實(shí)施階段以及代碼審查總結(jié)階段。
（一）代碼審查策劃階段
1.項(xiàng)目負(fù)責(zé)人分配代碼審查任務(wù)；
2.確定代碼審查策略：依據(jù)軟件開發(fā)文檔，確定軟件關(guān)鍵模塊，作為代碼審點(diǎn)；將復(fù)雜度高的模塊也作為代碼審查的重點(diǎn)；
3.項(xiàng)目負(fù)責(zé)人確定代碼審查單，審查內(nèi)容一般可包括：
（1）可追溯性：
――代碼是否遵循詳細(xì)設(shè)計(jì)？
――代碼是否與需求一致？
（2）邏輯：
――表示優(yōu)先級的括號用法是否正確？
――代碼是否依賴賦值順序？
――“if…else”和“switch”使用是否正確清晰？
――循環(huán)能否結(jié)束？
――復(fù)合語句是否正確地被花括號括起來？
――case語句是否所有可能出現(xiàn)的情況均已考慮？
――“goto”是否使用？
（3）數(shù)據(jù)：
――變量在使用前是否已初始化？
――變量的聲明是否按組劃分為外部的和內(nèi)部的？
――除最明顯的聲明外，是否所有聲明都有注釋？
――每個命名是否僅用于一個用途？
――常量名是否都大寫？
――常量是否都是通過“#define”定義的？
――用于多個文件中的常量是否在一個頭文件中定義？
――頭文件中是否存在可執(zhí)行的代碼？
――定義為指針的變量是否作為指針使用（而不是作為整數(shù)）？
――指針是否初始化？
――釋放內(nèi)存后是否將指針立即設(shè)置為NULL（或0）？
――傳遞指針到另一個函數(shù)的代碼是否首先檢查了指針的有效性？
――通過指針寫入動態(tài)分配內(nèi)存的代碼是否首先檢查了指針的有效性？
――宏的命名是否都大寫？
――數(shù)組是否越界？
（4）接口：
――在所有的函數(shù)及過程調(diào)用中，參數(shù)的個數(shù)都正確嗎？
――形參與實(shí)參類型匹配嗎？
――參數(shù)順序正確嗎？
――如果訪問共享內(nèi)存，是否具有相同的共享內(nèi)存結(jié)構(gòu)模式？
（5）文檔：
――軟件文檔是否與代碼一致？
（6）注釋：
――注釋與代碼是否一致？
――用于理解代碼的注釋是否提供了必要的信息？
――是否對數(shù)組和變量的作用進(jìn)行了描述？
（7）異常處理：
――是否所有可能的錯誤都已加以考慮？
（8）內(nèi)存：
――在向動態(tài)分配的內(nèi)存寫入之前是否檢查了內(nèi)存申請是否成功？
――若采用動態(tài)分配內(nèi)存，內(nèi)存空間分配是否正確？
――當(dāng)內(nèi)存空間不再需要時，是否被明確的釋放？
（9）其它：
――是否檢查了函數(shù)調(diào)用返回值？
――所有的輸入變量都用到了嗎？
――所有的輸出變量在輸出前都已賦值了嗎？
4.確定代碼審查進(jìn)度安排，項(xiàng)目負(fù)責(zé)人負(fù)責(zé)安排代碼審查的進(jìn)度。
（二）代碼審查實(shí)施階段
1.代碼講解：軟件開發(fā)人員詳細(xì)向測試人員講解如何以及為何這樣實(shí)現(xiàn)，測試人員提出問題和建議。通過代碼講解，測試人員對被審查的軟件有了一個全面的認(rèn)識，為后續(xù)代碼審查打下良好的基礎(chǔ)。
2.靜態(tài)分析：一般采用靜態(tài)分析工具進(jìn)行，主要分析軟件的代碼規(guī)模、模塊數(shù)、模塊調(diào)用關(guān)系、扇入、扇出、圈復(fù)雜度、注釋率等軟件質(zhì)量度量元。靜態(tài)分析在代碼審查時應(yīng)優(yōu)先進(jìn)行，有利于軟件測試人員在后續(xù)代碼審查時對軟件建立宏觀上認(rèn)識，在審查中容易做到有的放矢，更易于發(fā)現(xiàn)軟件代碼中的缺陷。
3.規(guī)則檢查：采用靜態(tài)分析工具對源程序進(jìn)行編碼規(guī)則檢查，對于工具報出的問題再由人工進(jìn)行進(jìn)一步的分析以確認(rèn)軟件問題，是一種比較有效的方法。
4.正式代碼審查：代碼審查可分兩步進(jìn)行：獨(dú)立審查和會議審查。根據(jù)情況，這兩步可以反復(fù)進(jìn)行多次。
（1）獨(dú)立審查：測試人員根據(jù)項(xiàng)目負(fù)責(zé)人的工作分配，獨(dú)自對自己負(fù)責(zé)的軟件模塊進(jìn)行代碼審查。測試人員根據(jù)代碼審查單，對相關(guān)代碼進(jìn)行閱讀、理解和分析后，記錄發(fā)現(xiàn)的錯誤和疑問。
（2）會議審查：項(xiàng)目負(fù)責(zé)人主持召開會議，測試人員和開發(fā)人員參加；測試人員就獨(dú)立審查發(fā)現(xiàn)的問題和疑問與開發(fā)人員溝通，并討論形成一致意見；對發(fā)現(xiàn)的問題匯總，填寫軟件問題報告單，提交開發(fā)人員處理。
5.更改確認(rèn)：開發(fā)人員對問題進(jìn)行處理，代碼審查人員對軟件的處理情況進(jìn)行確認(rèn)，驗(yàn)證更改的正確性，并防止出現(xiàn)新的問題。
（三）代碼審查總結(jié)階段
代碼審查工作結(jié)束后，項(xiàng)目負(fù)責(zé)人總結(jié)代碼審查結(jié)果；編寫測試報告，對軟件代碼質(zhì)量進(jìn)行評估，給出合理建議。
把代碼審查提出的所有問題、亮點(diǎn)及最終結(jié)論詳細(xì)的記錄下來，供其他軟件項(xiàng)目代碼審查借鑒。必要時，可建立常見軟件代碼缺陷數(shù)據(jù)庫，為軟件代碼審查人員培訓(xùn)和執(zhí)行代碼審查提供數(shù)據(jù)支持，也可以為軟件編碼規(guī)則制定規(guī)范提供實(shí)踐依據(jù)。
四、代碼審查中的常見問題
如果軟件測試人員熟悉常見的軟件代碼審查問題，對代碼審查效率是很有幫助的。筆者根據(jù)自己的應(yīng)驗(yàn)，列舉部分常見軟件代碼審查問題如下（僅供參考）：
（1）浮點(diǎn)數(shù)相等比較：可能造成程序未按設(shè)計(jì)的路徑執(zhí)行；
（2）因設(shè)計(jì)原因?qū)е履承┐a不能執(zhí)行：如邏輯表達(dá)式永遠(yuǎn)為真（或假）造成某分支不能執(zhí)行、代碼前面有return語句、某模塊從未被調(diào)用等；
（3）switch語句沒有break語句（有意如此設(shè)計(jì)時除外）；
（4）數(shù)組越界使用：數(shù)組越界容易發(fā)生在數(shù)組下標(biāo)是計(jì)算得到的情況下，而且審查時很難發(fā)現(xiàn)這種代碼缺陷，應(yīng)加以重視；
（5）變量未初始化就使用或者是條件賦值就使用；
（6）程序中存在未使用的多余變量；
（7）復(fù)合邏輯表達(dá)式?jīng)]有使用括號造成運(yùn)算順序錯誤；
（8）有返回值的函數(shù)中return沒有帶返回值；
（9）邏輯判別的表達(dá)式不是邏輯表達(dá)式；
（10）動態(tài)分配的內(nèi)存沒有及時釋放：忘記寫內(nèi)存釋放代碼或由于其它邏輯缺陷導(dǎo)致內(nèi)存釋放代碼未得到執(zhí)行；
（11）沒有對緩沖區(qū)溢出進(jìn)行必要的防護(hù)；
（12）訪問空指針，即指針未初始化就使用；
（13）指針指向的內(nèi)存釋放后，未將指針置為NULL：其它函數(shù)訪問該指針時，判斷指針不為空，當(dāng)作有效指針使用，會造成內(nèi)存訪問錯誤；
（14）注釋說明與程序代碼實(shí)現(xiàn)不一致，甚至相反；
（15）循環(huán)存在不能跳出的可能，程序中沒有相應(yīng)的保護(hù)機(jī)制。
五、結(jié)束語
關(guān)鍵詞：項(xiàng)目實(shí)訓(xùn)課；虛擬公司
中圖分類號：G642文獻(xiàn)標(biāo)識碼：B
文章編號：1672-5913（2007）05-0023-04
對于IT院校常出現(xiàn)的問題是教育與實(shí)踐脫節(jié)，常常是培養(yǎng)出的學(xué)生到IT企業(yè)后不能適應(yīng)公司的工作環(huán)境，所學(xué)的知識與應(yīng)用存在距離，公司還要對他們進(jìn)行特殊培訓(xùn)。在IT院校開設(shè)項(xiàng)目實(shí)訓(xùn)課，模擬公司的工作環(huán)境，把學(xué)生組織成項(xiàng)目小組，按照公司的項(xiàng)目開發(fā)流程指導(dǎo)學(xué)生對真實(shí)項(xiàng)目的開發(fā)，能夠很好地解決這個問題。為此，本文提供了一個項(xiàng)目實(shí)訓(xùn)課的實(shí)現(xiàn)案例。學(xué)生通過項(xiàng)目實(shí)訓(xùn)課的學(xué)習(xí)鍛煉，使其達(dá)到具有一定IT領(lǐng)域項(xiàng)目開發(fā)經(jīng)驗(yàn),體驗(yàn)、了解公司的工作環(huán)境，熟悉公司的項(xiàng)目開發(fā)及項(xiàng)目管理流程，成為上手快、實(shí)戰(zhàn)能力強(qiáng)、技術(shù)過硬、基本功較扎實(shí)、具有較強(qiáng)的團(tuán)隊(duì)精神和創(chuàng)業(yè)能力、用人單位搶手的人才。如果條件允許項(xiàng)目實(shí)訓(xùn)課程可采用雙語教學(xué)，指導(dǎo)教師可盡量用英語指導(dǎo)學(xué)生。
1 項(xiàng)目團(tuán)隊(duì)組成
教師指導(dǎo)學(xué)生以一個虛擬公司為背景，組織成多個項(xiàng)目小組，每個學(xué)生在項(xiàng)目小組中承擔(dān)一個或若干開發(fā)角色。進(jìn)入項(xiàng)目小組后不得無故退出。項(xiàng)目小組有以下角色：
項(xiàng)目經(jīng)理：負(fù)責(zé)本小組的人員協(xié)調(diào)和安排，制定項(xiàng)目開發(fā)計(jì)劃，按照開發(fā)計(jì)劃控制進(jìn)度，在負(fù)責(zé)整體的同時，開發(fā)好屬于自己的模塊。
產(chǎn)品經(jīng)理：主要使命是提高客戶的滿意度，在項(xiàng)目開發(fā)過程中代表為項(xiàng)目付款的系統(tǒng)擁有者的利益。
用戶體驗(yàn)角色：代替實(shí)際用戶使用產(chǎn)品，排除用戶在使用產(chǎn)品過程中遇到的問題和障礙。
文檔人員：協(xié)助項(xiàng)目經(jīng)理、系統(tǒng)分析員完成要提交的文檔，并敦促小組成員提交他們所負(fù)責(zé)的模塊相應(yīng)的文檔，并整理后按照存儲路徑和格式及項(xiàng)目開發(fā)計(jì)劃任務(wù)書中的時間段提交給導(dǎo)師。
系統(tǒng)分析員：負(fù)責(zé)本小組項(xiàng)目開發(fā)技術(shù)支持(軟件配置管理、培訓(xùn)等)，協(xié)助項(xiàng)目經(jīng)理帶領(lǐng)小組成員完成需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測試等一系列工作。
開發(fā)人員：按照項(xiàng)目經(jīng)理和系統(tǒng)分析員以及項(xiàng)目開發(fā)計(jì)劃任務(wù)書的要求，完成相應(yīng)的工作任務(wù)，提交自己所負(fù)責(zé)的模塊或者子系統(tǒng)的文檔給文檔負(fù)責(zé)人。
測試人員：負(fù)責(zé)系統(tǒng)測試。
2 實(shí)施流程
實(shí)施流程如圖1所示。
圖1 實(shí)施流程
3 項(xiàng)目管理
為了使同學(xué)們更好地熟悉掌握軟件項(xiàng)目開發(fā)流程及項(xiàng)目管理規(guī)范，項(xiàng)目管理通過適當(dāng)精簡，主要包括以下活動：
（1）項(xiàng)目進(jìn)度跟蹤與監(jiān)控
①項(xiàng)目周報制度：項(xiàng)目團(tuán)隊(duì)每周總結(jié)項(xiàng)目進(jìn)度情況，撰寫《項(xiàng)目周報》。
②周例會制度：導(dǎo)師每周召開項(xiàng)目例會，探討問題，總結(jié)工作。
③項(xiàng)目計(jì)劃跟蹤:老師指導(dǎo)下各項(xiàng)目小組由項(xiàng)目經(jīng)理根據(jù)項(xiàng)目開發(fā)計(jì)劃對實(shí)際項(xiàng)目進(jìn)展情況進(jìn)行跟蹤，作好項(xiàng)目跟蹤記錄。
④控制偏差：老師指導(dǎo)下項(xiàng)目經(jīng)理根據(jù)項(xiàng)目的需求及設(shè)計(jì)文檔對項(xiàng)目的功能實(shí)現(xiàn)進(jìn)行監(jiān)控，如果出現(xiàn)偏差應(yīng)及時更正。確保項(xiàng)目的各功能與需求文檔所要求的一致。
⑤指導(dǎo)教師應(yīng)該給學(xué)生作適當(dāng)?shù)捻?xiàng)目管理方面的培訓(xùn)，讓學(xué)生了解軟件工程及項(xiàng)目管理方面的知識。
（2）項(xiàng)目各階段評審
①項(xiàng)目開發(fā)計(jì)劃評審：由指導(dǎo)教師主持，由該虛擬公司的所有項(xiàng)目小組參加，對各項(xiàng)目小組制定的開發(fā)計(jì)劃進(jìn)行評審，學(xué)生可以提出自己的觀點(diǎn)，進(jìn)行辯論。老師進(jìn)行講評總結(jié)，然后各小組對項(xiàng)目開發(fā)計(jì)劃進(jìn)行修改、提交，作為考核項(xiàng)目小組工作的文檔。
②項(xiàng)目需求分析報告評審：由指導(dǎo)教師主持，由該虛擬公司的所有項(xiàng)目小組參加，對各項(xiàng)目小組作的需求分析報告進(jìn)行評審，學(xué)生可以提出自己的觀點(diǎn)，進(jìn)行辯論。老師進(jìn)行講評總結(jié)，各小組對需求分析報告進(jìn)行修改、提交，作為考核項(xiàng)目小組工作的文檔。
③項(xiàng)目設(shè)計(jì)報告評審：由指導(dǎo)教師主持，由該虛擬公司的所有項(xiàng)目小組參加，對各項(xiàng)目小組作的設(shè)計(jì)報告進(jìn)行評審，學(xué)生可以提出自己的觀點(diǎn)，進(jìn)行辯論。老師進(jìn)行講評總結(jié)，各小組設(shè)計(jì)報告進(jìn)行修改、提交，作為考核項(xiàng)目小組工作的文檔。
④項(xiàng)目實(shí)施與測試指導(dǎo)評審：由指導(dǎo)教師主持，由該虛擬公司的所有項(xiàng)目小組參加，對各項(xiàng)目小組演示所做項(xiàng)目的功能，講解項(xiàng)目實(shí)現(xiàn)原理，對認(rèn)為好的算法或使用先進(jìn)技術(shù)解決問題，應(yīng)進(jìn)行說明。其他學(xué)生對系統(tǒng)進(jìn)行評審，學(xué)生可以提出自己的觀點(diǎn)，進(jìn)行辯論。老師進(jìn)行講評總結(jié)，各小組對項(xiàng)目系統(tǒng)作進(jìn)一步進(jìn)行修改，然后提交，作為考核項(xiàng)目小組工作的文檔。
⑤項(xiàng)目總結(jié)與評審：由指導(dǎo)教師主持，由該虛擬公司的所有項(xiàng)目小組參加，以項(xiàng)目小組為單位對項(xiàng)目進(jìn)行總結(jié)，指導(dǎo)學(xué)生寫出項(xiàng)目總結(jié)報告。
（3）里程碑成果提交
①評審確認(rèn)的各階段文檔。包括：項(xiàng)目開發(fā)計(jì)劃、需求分析報告、設(shè)計(jì)報告等文檔。
②項(xiàng)目總結(jié)報告。
③程序代碼。
④最終成果物。
可以按照需求達(dá)到設(shè)計(jì)標(biāo)準(zhǔn)的可運(yùn)行系統(tǒng)。
（4）管理文件及表格
項(xiàng)目開發(fā)進(jìn)度表等。
4 項(xiàng)目質(zhì)量保證
（1）執(zhí)行研發(fā)中心質(zhì)量管理體系
①依據(jù)ISO9001：2000質(zhì)量保證體系要素
②適當(dāng)加入特定文件及質(zhì)量表格
③嚴(yán)格風(fēng)險控制
④嚴(yán)格設(shè)計(jì)及測試環(huán)節(jié)
（2）加強(qiáng)預(yù)防和糾正措施
（3）加強(qiáng)管理評審
（4）加強(qiáng)問題跟蹤
5 配置管理
軟件配置管理分為版本管理和配置庫管理，配置管理軟件SourceSafe。
版本管理包括以下主要任務(wù)：
* 建立項(xiàng)目；
* 重構(gòu)任何修訂版的某一項(xiàng)或某一文件；
* 利用加鎖技術(shù)防止覆蓋；
* 當(dāng)增加一個修訂版時要求輸入變更描述；
* 提供比較任意兩個修訂版的使用工具；
* 采用增量存儲方式；
* 提供對修訂版歷史和鎖定狀態(tài)的報告功能；
* 提供歸并功能；
* 允許在任何時候重構(gòu)任何版本；
* 權(quán)限的設(shè)置；
* 晉升模型的建立；
* 提供各種報告。
6 項(xiàng)目考核
平時成績與項(xiàng)目結(jié)項(xiàng)答辯成績的比例為1∶1。
平時成績考核：由考勤、程序代碼及整個項(xiàng)目實(shí)施過程中所產(chǎn)生的所有文檔的評審結(jié)果的綜合。
項(xiàng)目結(jié)項(xiàng)答辯成績考核：
（1）檢查項(xiàng)目的系統(tǒng)運(yùn)行是否正常，各項(xiàng)功能是否按照需求要求實(shí)現(xiàn)。
（2）項(xiàng)目結(jié)項(xiàng)后組織對項(xiàng)目的答辯會。
7 項(xiàng)目培訓(xùn)
指定項(xiàng)目實(shí)訓(xùn)課指導(dǎo)計(jì)劃，設(shè)計(jì)流程，按計(jì)劃對學(xué)生進(jìn)行培訓(xùn)。
（1）指導(dǎo)教師在指導(dǎo)學(xué)生從事項(xiàng)目實(shí)施過程中，將“軟件工程與項(xiàng)目管理”課程融入到項(xiàng)目的立項(xiàng)管理、需求開發(fā)與需求管理、系統(tǒng)概要設(shè)計(jì)等各個過程當(dāng)中。同時將進(jìn)行二次集中的知識講授，講授內(nèi)容包含：項(xiàng)目場景的描述、分析項(xiàng)目；項(xiàng)目實(shí)施與測試指導(dǎo)、評價。
（2）指導(dǎo)教師根據(jù)學(xué)生的特點(diǎn)及項(xiàng)目的特點(diǎn)對項(xiàng)目實(shí)現(xiàn)過程中所要使用的一些關(guān)鍵技術(shù)進(jìn)行培訓(xùn)。
（3）在項(xiàng)目的實(shí)現(xiàn)階段，對學(xué)生項(xiàng)目開發(fā)工具的使用、項(xiàng)目開發(fā)環(huán)境的設(shè)置等方面進(jìn)行指導(dǎo)?？蓪ο到y(tǒng)的整體框架，根據(jù)每個學(xué)生的具體情況，對一兩個比較典型的模塊進(jìn)行剖析，讓學(xué)生有一個開發(fā)參照模式，可以避免學(xué)生開發(fā)時無從下手的問題。
8 項(xiàng)目研討
實(shí)訓(xùn)課的項(xiàng)目研討分為三部分內(nèi)容：
答疑解問：導(dǎo)師集中對同學(xué)在項(xiàng)目開發(fā)過程中出現(xiàn)的各種問題進(jìn)行解答。
技術(shù)預(yù)研：是指在項(xiàng)目立項(xiàng)之后到項(xiàng)目開發(fā)工作完成之前的這段時間內(nèi)，對項(xiàng)目所采用的關(guān)鍵技術(shù)提前學(xué)習(xí)和研究 ，以便盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將遇到的技術(shù)障礙。
項(xiàng)目階段性研討會議：實(shí)訓(xùn)課分為項(xiàng)目說明會、項(xiàng)目小組確定；項(xiàng)目需求分析研討；項(xiàng)目設(shè)計(jì)研討。其中項(xiàng)目小組成員對評審中的問題可以發(fā)表自己的意見，可以進(jìn)行相互辯論，最后指導(dǎo)教師進(jìn)行點(diǎn)評。
9 項(xiàng)目評審
由指導(dǎo)老師組成項(xiàng)目評審小組，聽取項(xiàng)目團(tuán)隊(duì)的匯報并進(jìn)行評審。包括項(xiàng)目開發(fā)計(jì)劃評審、項(xiàng)目需求分析報告評審、項(xiàng)目設(shè)計(jì)報告評審、項(xiàng)目實(shí)施與測試指導(dǎo)評審、項(xiàng)目總結(jié)與評審。
評審目標(biāo)如下：
* 發(fā)現(xiàn)任何形式表現(xiàn)的軟件功能、邏輯或?qū)崿F(xiàn)方面的錯誤；
* 通過評審驗(yàn)證軟件的需求；
* 保證軟件按預(yù)先定義的標(biāo)準(zhǔn)表示；
* 使項(xiàng)目更容易管理。
通過評審使項(xiàng)目小組成員真正掌握項(xiàng)目開發(fā)流程、了解軟件工程及項(xiàng)目管理在項(xiàng)目開發(fā)過程中的作用。同時解決項(xiàng)目開發(fā)中一些問題，也起到對項(xiàng)目小組成員工作考核作用。
（1）評審過程
召開評審會議：一般應(yīng)有3-5人參加。會議結(jié)束導(dǎo)師給予評審分?jǐn)?shù)。
評審報告與記錄：所提出的問題都要進(jìn)行記錄，在評審會結(jié)束前產(chǎn)生一個評審問題表，另外必須完成評審簡要報告。
（2）評審準(zhǔn)則
對每個正式技術(shù)評審分配資源和時間進(jìn)度表；
對全部評審人員進(jìn)行必要的培訓(xùn)。
10 結(jié)束語
本文中所論述的實(shí)訓(xùn)課的設(shè)計(jì)及實(shí)施方法已在我院的大學(xué)生創(chuàng)業(yè)中心實(shí)施，并收到了明顯的效果，經(jīng)過實(shí)訓(xùn)課培訓(xùn)后學(xué)生的項(xiàng)目能力有了明顯的增強(qiáng)，完全可以在我們的創(chuàng)業(yè)中心參與各虛擬公司的項(xiàng)目開發(fā)工作并從中得到更多的工作經(jīng)驗(yàn)。
參考文獻(xiàn)：
[1] 林銳，唐勇，黃曙江，石志強(qiáng)． IT企業(yè)項(xiàng)目管理：問題、方法和工具[M]．北京：電子工業(yè)出版社.2005．
[2] 陳宏剛，熊明華，林斌，等．軟件開發(fā)過程與案例[M]．北京：清華大學(xué)出版社．2003．
關(guān)鍵詞:海外工程弱電項(xiàng)目項(xiàng)目管理。
中圖分類號:F270 文獻(xiàn)標(biāo)識碼:A 文章編號:1007-3973(2010)08-150-02
經(jīng)濟(jì)全球化浪潮與國家“走出去”戰(zhàn)略的實(shí)施,讓越來越多的企業(yè)逐漸把自己的視野投向國際市場。筆者所在的中國電子進(jìn)出口總公司(以下簡稱CEIEC),是一家成立于1980年的國有外貿(mào)企業(yè),從1999年開始,公司開進(jìn)入海外工程業(yè)務(wù)市場,現(xiàn)已成為ENR評選的全球225家最大的國際工程承包商之一。
筆者作為項(xiàng)目經(jīng)理,參與了非洲安哥拉國家電視臺綜合布線項(xiàng)目建設(shè)和柬埔寨國家警察局大樓視頻監(jiān)控項(xiàng)目建設(shè)。對于如何在海外實(shí)施弱電工程積累了一些經(jīng)驗(yàn),希望通過本文,與大家共享項(xiàng)目實(shí)施過程中的艱辛和海外弱電項(xiàng)目的一些特點(diǎn)。
1項(xiàng)目概況
1.1安哥拉國家電視臺綜合布線項(xiàng)目
本項(xiàng)目是安哥拉電視臺項(xiàng)目的配套工程,主要工作任務(wù)是完成電視臺制作中心和發(fā)射中心內(nèi)部的電話網(wǎng)、數(shù)據(jù)網(wǎng)的綜合布線,并提供必要的機(jī)房設(shè)備和辦公自動化設(shè)備。以下簡稱TPA-ZHBX。
1.2柬埔寨國家警察局大樓視頻監(jiān)控項(xiàng)目
本項(xiàng)目是為柬埔寨內(nèi)政部國家警察總局建立覆蓋總局樓群的視頻監(jiān)控系統(tǒng)。包括分布于大樓內(nèi)外的各類攝像頭和分布于監(jiān)控室、警察總監(jiān)房間、秘書房間的不同類型的控制和監(jiān)控設(shè)備。以下簡稱CAM-JCJK。
2項(xiàng)目計(jì)劃
通常,海外工程的項(xiàng)目計(jì)劃的時間估算比較困難,因?yàn)槲锪鞯牟淮_定性,項(xiàng)目執(zhí)行的時間跨度可能比較大。項(xiàng)目計(jì)劃的內(nèi)容主要包括:項(xiàng)目范圍、項(xiàng)目組織、培訓(xùn)計(jì)劃、工作任務(wù)分解(WBS)、風(fēng)險識別和應(yīng)對、項(xiàng)目里程碑及工作日程安排。
2.1項(xiàng)目范圍
海外工程通常采用EPC方式,即工程總承包,這種模式在項(xiàng)目的招標(biāo)階段,業(yè)主往往只能給出項(xiàng)目的預(yù)期目標(biāo)、功能要求及設(shè)計(jì)標(biāo)準(zhǔn),因此,當(dāng)合同簽訂后,需盡快與業(yè)主確定設(shè)計(jì)圖紙與材料設(shè)備清單,這樣才能最終確定項(xiàng)目范圍。
2.2項(xiàng)目組織
項(xiàng)目組織中除了通常國內(nèi)項(xiàng)目中都會有的項(xiàng)目經(jīng)理、施工人員之外,還應(yīng)充分考慮與業(yè)主、監(jiān)理的溝通需要,有時會配備專職翻譯。
通常項(xiàng)目的設(shè)計(jì)、采購、發(fā)貨在國內(nèi)進(jìn)行,施工在國外進(jìn)行,因此,項(xiàng)目經(jīng)理要克服時差等困難對國內(nèi)外兩個團(tuán)隊(duì)進(jìn)行協(xié)調(diào)和溝通,推進(jìn)項(xiàng)目的順利進(jìn)展。
2.3工作任務(wù)分解
工作任務(wù)分解是項(xiàng)目計(jì)劃中最重要的一部分。通常,項(xiàng)目的開始階段會有各種不可預(yù)期的問題需要磨合解決,因此,我們會在項(xiàng)目開始階段為各項(xiàng)任務(wù)留出較大的余量,而在項(xiàng)目中后期,一切走入正軌后,可以將各項(xiàng)任務(wù)的時間安排得緊張一些。例如,通常情況下,預(yù)計(jì)完成一層樓電纜的鋪設(shè)需要2天時間,那么,如果這項(xiàng)任務(wù)位于項(xiàng)目的前期,則不妨將工作時間估算為3天,而如果這項(xiàng)任務(wù)位于項(xiàng)目的后期,則2天就可以保證完成任務(wù)。
3項(xiàng)目實(shí)施
3.1溝通管理
在海外做工程項(xiàng)目,溝通是最重要的,而溝通又是最有障礙和最有挑戰(zhàn)性的。主要的問題在于:語言問題、文化問題、標(biāo)準(zhǔn)問題。
安哥拉的官方語言是葡萄牙語,因此,與當(dāng)?shù)厝说臏贤ê芾щy,在一些重要的會議上,都需要依靠翻譯。柬埔寨情況稍好,很多人都會英語,溝通起來相對容易。
文化上的沖突也不少,當(dāng)?shù)厝斯ぷ髯黠L(fēng)渙散,時間觀念差,給我們的工作造成了很大的麻煩。
在TPA-ZHBX項(xiàng)目中,最初我們是按中國標(biāo)準(zhǔn)來設(shè)計(jì)的,業(yè)主也表示認(rèn)可,但當(dāng)西方的監(jiān)理公司介入后,要求按照西方標(biāo)準(zhǔn)進(jìn)行修改,這就涉及到大量的溝通和協(xié)調(diào)問題。
3.2現(xiàn)場記錄
做好現(xiàn)場的記錄是海外工程中非常重要的一環(huán),主要有:
項(xiàng)目周報:海外工程的項(xiàng)目經(jīng)理每周會以書面形式,向公司報告項(xiàng)目的進(jìn)展情況。
會議記錄:我們與客戶、監(jiān)理定期召開會議,與分包商、設(shè)計(jì)單位也定期召開會議,這些會議的議題和決議都要形成會議紀(jì)要并存檔。
變更記錄:所有與原設(shè)計(jì)不同的變更都必須有記錄,并且需要相關(guān)人員簽字確認(rèn),以便于最終的工程結(jié)算和決算。
聲像記錄:項(xiàng)目經(jīng)理應(yīng)盡可能的用照相機(jī)、攝像機(jī)拍攝下施工過程中的進(jìn)展情況,為項(xiàng)目的總結(jié)和回顧留下珍貴的聲像資料。有些資料甚至?xí)蔀楸ｋU索賠的重要證據(jù)。例如在安哥拉工地曾發(fā)生一次火災(zāi),當(dāng)?shù)厝朔呕馃?將我們的一臺挖土機(jī)引燃,最終通過我們拍攝的照片找保險公司索賠成功。
3.3風(fēng)險應(yīng)對
項(xiàng)目計(jì)劃中應(yīng)該進(jìn)行風(fēng)險的識別和制定應(yīng)對預(yù)案,在項(xiàng)目實(shí)施過程中,應(yīng)該對這些風(fēng)險進(jìn)行實(shí)時的追蹤檢查。當(dāng)然,有些難以預(yù)料的風(fēng)險發(fā)生后,也要能夠及時的加以處理,以免造成更嚴(yán)重的后果。下表是CAM-JCJK項(xiàng)目的實(shí)際風(fēng)險情況:
從項(xiàng)目計(jì)劃中的風(fēng)險預(yù)測與實(shí)際發(fā)生風(fēng)險表的對比來看,我們根據(jù)以往經(jīng)驗(yàn)制定的風(fēng)險識別和應(yīng)對方案基本涵蓋了實(shí)際發(fā)生的風(fēng)險類型,并對進(jìn)度風(fēng)險、當(dāng)?shù)毓九浜巷L(fēng)險、系統(tǒng)實(shí)施風(fēng)險進(jìn)行了較好的識別和預(yù)測。
3.4變更控制
項(xiàng)目執(zhí)行中,通常都會出現(xiàn)變更,有時候一些變更會對項(xiàng)目的工期和預(yù)算造成很大的影響,因此需要充分的溝通,有理有據(jù)有節(jié)的為公司贏得最大利益,并對變更進(jìn)行控制和管理。
例如在CAM-JCJK項(xiàng)目中,業(yè)主在工程即將完工的時候,要求將一臺原設(shè)計(jì)在監(jiān)控室中的控制臺移至應(yīng)急指揮中心。在與業(yè)主進(jìn)行溝通后,我們發(fā)現(xiàn)在應(yīng)急指揮中心安裝控制臺有著房間面積大,視覺效果好的優(yōu)點(diǎn),有利于項(xiàng)目產(chǎn)品的推廣。因此,我們很快制定出一套最經(jīng)濟(jì)的安裝方案,向公司做了匯報,公司同意后,雙方簽字確認(rèn)。最后我們成功的實(shí)施了此次變更,取得了很好的效果。
5項(xiàng)目完工
5.1項(xiàng)目交付
項(xiàng)目交付工作涉及到培訓(xùn)和驗(yàn)收測試。
通常,培訓(xùn)都采用業(yè)主的母語或者英語進(jìn)行,相關(guān)的資料也必須翻譯成這兩種語言。
在TPA-ZHBX項(xiàng)目的培訓(xùn)中,涉及到程控交換機(jī)的手冊多達(dá)十幾本,非常復(fù)雜。最后,我們自行縮寫、編撰了簡單易行的Q&A手冊,取得了很好的效果。
驗(yàn)收測試工作需要與業(yè)主和監(jiān)理進(jìn)行很好的溝通,由于標(biāo)準(zhǔn)的不同,監(jiān)理往往對測試的設(shè)備、方法都要求按照他們的標(biāo)準(zhǔn)進(jìn)行,這就需要我們提前準(zhǔn)備好各種設(shè)備的性能測試報告,有些測試報告還需要國內(nèi)的設(shè)備供應(yīng)商提供英文版本。
5.2項(xiàng)目總結(jié)
及時的總結(jié)非常重要,通過總結(jié),項(xiàng)目團(tuán)隊(duì)能更上一層樓,公司能積累更多的經(jīng)驗(yàn),為公司在未來的項(xiàng)目中取得成功提供保障。
項(xiàng)目總結(jié)主要包括項(xiàng)目實(shí)際工期、風(fēng)險跟蹤、實(shí)際工作量與計(jì)劃的對比、項(xiàng)目成本核算、遺留問題匯總、經(jīng)驗(yàn)總結(jié)與建議等等。這是公司的一份寶貴財(cái)富。
關(guān)鍵詞：軟件項(xiàng)目管理；軟件配置管理；軟件項(xiàng)目計(jì)劃書
1軟件項(xiàng)目管理的組織模式
1．1項(xiàng)目管理委員會。項(xiàng)目管理委員會是公司項(xiàng)目管理的最高決策機(jī)構(gòu)，—般由公司總經(jīng)理、副總經(jīng)理組成。主要職責(zé)如下：(1)照項(xiàng)目管理相關(guān)制度管理項(xiàng)目；(2)監(jiān)督項(xiàng)目管理相關(guān)制度的執(zhí)行；(3)對項(xiàng)目立項(xiàng)、項(xiàng)目撤消進(jìn)行決策；(4)任命項(xiàng)目管理小組組長、項(xiàng)目評審蠶員會主任、項(xiàng)目組組長。
1.2項(xiàng)目管理小組。項(xiàng)目管理小組對項(xiàng)目管理委員會負(fù)責(zé)，—般由公司管理人員組成。主要職責(zé)如下：(1)草擬項(xiàng)目管理的各項(xiàng)制度；(2)組織項(xiàng)目階段評審；(3)保存項(xiàng)目過程中的相關(guān)文件和數(shù)據(jù)：(4)為優(yōu)化項(xiàng)目管理提出建議。
1.3項(xiàng)目評審小組。項(xiàng)目評審小組對項(xiàng)目管理委員會負(fù)責(zé)，可下設(shè)開發(fā)評審小組和產(chǎn)品評審小組，—般由公司技術(shù)專家和市場專家組成。主要職責(zé)如下：(1)對項(xiàng)目可行性報告進(jìn)行評審；(2)對市場計(jì)劃和階段報告進(jìn)行評審；(3)對開發(fā)計(jì)劃和階段報告進(jìn)行評審；(4)項(xiàng)目結(jié)束時，對項(xiàng)目總結(jié)報告進(jìn)行評審。
1．4軟件產(chǎn)品項(xiàng)目組。主要職責(zé)是：根據(jù)項(xiàng)目管理委員會的安排具體負(fù)責(zé)項(xiàng)目的軟件開發(fā)和市場調(diào)研及銷售工作。
2軟件項(xiàng)目管理的內(nèi)容
在二十世紀(jì)八十年代初，著名軟件工程專家B．W．Boehm總結(jié)出了軟件開發(fā)時需遵循的七條基本原則，同洋，我們盔件項(xiàng)目管理時，也應(yīng)該遵循這七條原則。它們是：(1)用分階段的生命周期計(jì)劃嚴(yán)格管理；(2)堅(jiān)持進(jìn)行階段評審；(3)實(shí)行嚴(yán)格的產(chǎn)品控制；(4)采用現(xiàn)代程序設(shè)計(jì)技術(shù)；(5)結(jié)果應(yīng)能夠清楚地審查；(6)開發(fā)小組的人員應(yīng)該少而精；(7)承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性。
3編寫《軟件項(xiàng)目計(jì)劃書》
《軟件項(xiàng)目計(jì)劃書》一般應(yīng)該包括下述內(nèi)容
(1)引言。A計(jì)劃的目的；頁目的范圍和目標(biāo)：范圍描述；主要功能；性能；管理和技術(shù)約束。(2)項(xiàng)目估算。使用的歷史數(shù)據(jù)；b使用的評估技術(shù)；c工作量、成本、時間估算。(3)風(fēng)險管理戰(zhàn)略。風(fēng)險識別；d風(fēng)險的時論；e岡險管理計(jì)劃：風(fēng)險計(jì)劃風(fēng)險監(jiān)視；風(fēng)險管理。(4)日程。a項(xiàng)目工作分解結(jié)構(gòu)；b時限圖(甘特圖)；c琶源表。(5)項(xiàng)目資源。a人員；b硬件和軟件；c特別資源。(6)人員組織。a組織結(jié)構(gòu)；b管理報告。(7)跟蹤和控制機(jī)制。a質(zhì)量保證和控制；b變化管理和控制。(8)附錄。
4軟件配置管理
軟件配置管理應(yīng)提供的功能：在IS090003中了如下描述：
唯一地標(biāo)識每個軟件項(xiàng)的版本；標(biāo)識共同構(gòu)成一完整產(chǎn)品的特定版本的每一軟件項(xiàng)的版本；控制由兩個或多個獨(dú)立工作的人員同時對一給定軟件項(xiàng)的更新；控制由兩個或多個獨(dú)立工作的人員同時對一給定軟件項(xiàng)的更新：按要求在—個或多個位置對復(fù)雜產(chǎn)品的更新進(jìn)行協(xié)調(diào)；標(biāo)識并跟蹤所有的措施和更改；這些措施和更改是在從開始直到放行期問，由于更改請求或問題引起的。
5軟件質(zhì)量管理
5．1軟件質(zhì)量保涇計(jì)劃。在進(jìn)行軟件開發(fā)前。需要有—個《軟件質(zhì)量保證計(jì)劃》。一般包括以內(nèi)容：(1)計(jì)劃目的；(2)參考文獻(xiàn)；(3)管理。a組織任務(wù)；b責(zé)任。(4)文檔。a目的；b要求的軟件工文檔；d也文檔；(5)標(biāo)準(zhǔn)和約定。a目的；b約定(6)評審和審計(jì)。a目的；b評審要求。軟件需求自噼審；設(shè)計(jì)評審；軟件驗(yàn)證和確認(rèn)評審；功能評審；理評審；內(nèi)部過程評審；管理評審。(7)測試。(8)題報告和改正活動。(9)工具、技術(shù)和方法。(10)媒體控制。(11)供應(yīng)者控制。(12)記錄、收集、維護(hù)和保密。(13)培訓(xùn)。(14)風(fēng)險管理。
5.2質(zhì)量管理的基本原則?？刂扑羞^程的質(zhì)量；過程控制的出發(fā)點(diǎn)是預(yù)防不合格；質(zhì)量管理中心任務(wù)是建立并實(shí)施文件化的質(zhì)量體系；持續(xù)的質(zhì)量改進(jìn)；有效的質(zhì)量體系應(yīng)滿足顧客和組織內(nèi)部雙方的需要和利益；定期評價質(zhì)量體系；搞好質(zhì)量管理關(guān)鍵在于領(lǐng)導(dǎo)。
5.3軟件評審。軟件評審并不是在軟件開發(fā)畢后進(jìn)行評審，而是在軟件開發(fā)的各個階段都進(jìn)行評審。因?yàn)樵谲浖_發(fā)的各個階段都可能生錯誤，如果這些錯誤不及時發(fā)現(xiàn)并糾正，會不地?cái)U(kuò)大。最后可能導(dǎo)致開發(fā)的失敗。軟件評審是相當(dāng)重要的工作，也是目前國開發(fā)最不重視的工作。
5．4測試。測試—般包括單元測試省測試集成系統(tǒng)測試。如果測試結(jié)果與預(yù)期結(jié)果不—致，則很可能是發(fā)現(xiàn)了系統(tǒng)中的錯誤，測試過程中將產(chǎn)生下述基本文檔：(1)測試計(jì)劃：確定測試范圍、方法和需要的資源等。(2)測試過程：詳細(xì)描述和每個測試方案有關(guān)的測試步驟和數(shù)據(jù)(包括測試數(shù)據(jù)及預(yù)期的結(jié)果)。(3)測試結(jié)果：把每次測試行的結(jié)果歸人文檔，如果運(yùn)行出錯，則應(yīng)產(chǎn)生問題報告，并且必須經(jīng)過調(diào)試解決所發(fā)現(xiàn)的問題。
6軟件風(fēng)險管理
6．1風(fēng)險的分類。根據(jù)風(fēng)險內(nèi)容，我們可以將風(fēng)臉分為項(xiàng)目風(fēng)險(成本提高，時間延長等)、技術(shù)風(fēng)險(技術(shù)不成熟等)、商業(yè)風(fēng)險(銷售問題等)、戰(zhàn)略風(fēng)險(公司的經(jīng)營戰(zhàn)略發(fā)生了變化)、管理風(fēng)險(公司管理人員是否成熟等)、預(yù)算風(fēng)險(預(yù)算是否準(zhǔn)確等)等。另外，我們還可以將風(fēng)險分為已知風(fēng)險(如員工離職等)、可預(yù)報風(fēng)險(從以往經(jīng)驗(yàn)得出可能有風(fēng)險的)和不可預(yù)知風(fēng)險。
6.2風(fēng)臉的識別。風(fēng)險項(xiàng)目檢查表。主要涉及以下幾方面檢查：(1)產(chǎn)品規(guī)模風(fēng)臉檢查；(2)業(yè)務(wù)影響風(fēng)險檢查；(3)與客戶相關(guān)的風(fēng)險檢查；(4)過程風(fēng)險檢查；(5)技術(shù)風(fēng)險檢查；(6)開發(fā)環(huán)境風(fēng)險檢查；(7)與人員的模式和經(jīng)驗(yàn)有關(guān)的風(fēng)險檢查?！?nbsp;
6．3風(fēng)險評估。風(fēng)險評估主要從下面七個方面進(jìn)行：(1)發(fā)生的可能性；(2)發(fā)生的結(jié)果(影響) (3)建立—個尺度表示風(fēng)險可能性(如，極罕見、罕見、普通、可能、極可能)；(4)描述風(fēng)險帶來的后果；(5)產(chǎn)品和項(xiàng)目的影響；(6)確定風(fēng)險評估的正確性；(7)根據(jù)影響排定有限隊(duì)列。另外，要對每個風(fēng)險的表現(xiàn)、范圍、時間做出盡量準(zhǔn)確的判斷。
