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