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