㈠ java軟體開發項目驗收有什麼需要注意的
依據我們開發java軟體項目的經驗，下面為大家介紹下驗收時的注意事項，當系統經過一段試運行，具備驗收的各項條件之後，我們就需要著手驗收階段的准備工作了。
我們需要把到目前為止完成的工作進行一個總結，列出我們已經完成
的各項目工作成果、各類文檔，對合同以及各類約定的技術文檔中的相關內容進行自查，要徹底了解系統目前完成的情況如何，是否已經完成了與客戶方達成的各項書面約定以及口頭約定。
在項目實施過程中注重里程碑的確定，制定階段性目標如果要做好一個項目，完成項目的驗收條件，主要還是以業務是否可用作為衡量的。
寫好備忘錄和問題跟蹤記錄
㈡ 常見軟體故障的判斷與解決方法。
§1.1 進行電腦維修應遵循的基本原則：
一、 進行維修判斷須從最簡單的事情做起
簡單的事情，一方面指觀察，另一方面是指簡捷的環境。
簡單的事情就是觀察，它包括：
1、 電腦周圍的環境情況——位置、電源、連接、其它設備、溫度與濕度等；
2、 電腦所表現的現象、顯示的內容，及它們與正常情況下的異同；
3、 電腦內部的環境情況——灰塵、連接、器件的顏色、部件的形狀、指示燈的狀態等；
4、 電腦的軟硬體配置——安裝了何種硬體，資源的使用情況；使用的是使種操作系統，其上又安裝了何種應用軟體；硬體的設置驅動程序版本等。
簡捷的環境包括：
1、 後續將提到的最小系統；
2、 在判斷的環境中，僅包括基本的運行部件/軟體，和被懷疑有故障的部件/軟體；
3、 在一個干凈的系統中，添加用戶的應用（硬體、軟體）來進行分析判斷
從簡單的事情做起，有利於精力的集中，有利於進行故障的判斷與定位。一定要注意，必須通過認真的觀察後，才可進行判斷與維修。
二、 根據觀察到的現象，要「先想後做」
先想後做，包括以下幾個方面：
首先是，先想好怎樣做、從何處入手，再實際動手。也可以說是先分析判斷，再進行維修。
其次是，對於所觀察到的現象，盡可能地先查閱相關的資料，看有無相應的技術要求、使用特點等，然後根據查閱到的資料，結合下面要談到的內容，再著手維修。
最後是，在分析判斷的過程中，要根據自身已有的知識、經驗來進行判斷，對於自己不太了解或根本不了解的，一定要先向有經驗的同事或你的技術支持工程師咨詢，尋求幫助。
三、 在大多數的電腦維修判斷中，必須「先軟後硬：
即從整個維修判斷的過程看，總是先判斷是否為軟體故障，先檢查軟體問題，當可判軟體環境是正常時，如果故障不能消失，再從硬體方面著手檢查。
四、 在維修過程中要分清主次，即「抓主要矛盾「
在復現故障現象時，有時可能會看到一台故障機不止有一個故障現象，而是有兩個或兩個以上的故障現象（如：啟動過程中無顯，但機器也在啟動，同時啟動完後，有死機的現象等），為時，應該先判斷、維修主要的故障現象，當修復後，再維修次要故障現象，有時可能次要故障現象已不需要維修了。
§1.2 電腦維修的基本方法
一、觀察法
觀察，是維修判斷過程中第一要法，它貫穿於整個維修過程中。觀察不僅要認真，而且要全面。要觀察的內容包括：
1、 周圍的環境；
2、 硬體環境。包括接插頭、座和槽等；
3、 軟體環境；
4、 用戶操作的習慣、過程
二、最小系統法
最小系統是指，從維修判斷的角度能使電腦開機或運行的最基本的硬體和軟體環境。最小系統有兩種形式：
硬體最小系統：由電源、主板和CPU組成。在這個系統中，沒有任何信號線的連接，只有電源到主板的電源連接。在判斷過程中是通過聲音來判斷這一核心組成部分是否可正常工作；
軟體最小系統：由電源、主板、CPU、內存、顯示卡/顯示器、鍵盤和硬碟組成。這個最小系統主要用來判斷系統是否可完成正常的啟動與運行。
對於軟體最小環境，就「軟體」有以下幾點要說明：
1、 硬碟中的軟體環境，保留著原先的軟體環境，只是在分析判斷時，根據需要進行隔離如卸載、屏蔽等）。保留原有的軟體環境，主要是用來分析判斷應用軟體方面的問題
2、 硬碟中的軟體環境，只有一個基本的操作系統環境（可能是卸載掉所有應用，或是重新安裝一個干凈的操作系統），然後根據分析判斷的需要，載入需要的應用。需要使用一個干凈的操作系統環境，是要判斷系統問題、軟體沖突或軟、硬體間的沖突問題。
3、 在軟體最小系統下，可根據需要添加或更改適當的硬體。如：在判斷啟動故障時，由於硬碟不能啟動，想檢查一下能否從其它驅動器啟動。這時，可在軟體最小系統下加入一個軟碟機或乾脆用軟碟機替換硬碟，來檢查。又如：在判斷音視頻方面的故障時，應需要在軟體最小系統中加入音效卡；在判斷網路問題時，就應在軟體最小系統中加入網卡等。
最小系統法，主要是要先判斷在最基本的軟、硬體環境中，系統是否可正常工作。如果不能正常工作，即可判定最基本的軟、硬體部件有故障，從而起到故障隔離的作用。
最小系統法與逐步添加法結合，能較快速地定位發生在其它板軟體的故障，提高維修效率。
三、逐步添加/去除法
逐步添加法，以最小系統為基礎，每次只向系統添加一個部件/設備或軟體，來檢查故障現象是否消失或發生變化，以此來判斷並定位故障部位。
逐步去除法，正好與逐步添加法的操作相反。
逐步添加/去除法一般要與替換法配合，才能較為准確地定位故障部位。
四、隔離法
是將可能防礙故障判斷的硬體或軟體屏蔽起來的一種判斷方法。它也可用來將懷疑相互沖突的硬體、軟體隔離開以判斷故障是否發生變化的一種方法。
上提到的軟硬體屏蔽，對於軟體來說，即是停止其運行，或者是卸載；對於硬體來說，是在設備管理器中，禁用、卸載其驅動，或乾脆將硬體從系統中去除。
五、替換法
替換法是用好的部件去代替可能有故障的部件，以判斷故障現象是否消失的一種維修方法。好的部件可以是同型號的，也可能是不同型號的。替換的順序一般為：
1、 根據故障的現象或第二部分中的故障類別，來考慮需要進行替換的部件或設備；
2、 按先簡單後復雜的順序進行替換。如：先內存、CPU，後主板，又如要判斷列印故障時，可先考慮列印驅動是否有問題，再考慮列印電纜是否有故障，最後考慮列印機或並口是否有故障等；
3、 最先考查與懷疑有故障的部件相連接的連接線、信號線等，之後是替換懷疑有故障的部件，再後是替換供電部件，最後是與之相關的其它部件。
4、 從部件的故障率高低來考慮最先替換的部件。故障率高的部件先進行替換。
六、比較法
比較法與替換法類似，即用好的部件與懷疑有故障的部件進行外觀、配置、運行現象等方面的比較，也可在兩台電腦間進行比較，以判斷故障電腦在環境設置，硬體配置方面的不同，從而找出故障部位。
七、升降溫法
在上門服務過程中，升降溫法由於工具的限制，其使用與維修間是不同的。在上門服務中的升溫法，可在用戶同意的情況下，設法降低電腦的通風能力，靠電腦自身的發熱來升溫；降溫的方法有：1）一般選擇環境溫度較低的時段，如一清早或較晚的時間；2）使電腦停機12~24小時以上等方法實現；3）用電風扇對著故障機吹，以加快降溫速度。
八、敲打法
敲打法一般用在懷疑電腦中的某部件有接觸不良的故障時，通過振動、適當的扭曲，甚或用橡膠錘敲打部件或設備的特定部件來使故障復現，從而判斷故障部件的一種維修方法。
九、對電腦產品進行清潔的建議
有些電腦故障，往往是由於機器內灰塵較多引起的，這就要求我們在維修過程中，注意觀察故障機內、外部是否有較多的灰塵，如果是，應該先進行除塵，再進行後續的判斷維修。在進行除塵操作中，以下幾個方面要特別注意：
1、 注意風道的清潔
2、 注意風扇的清潔
風扇的清潔過程中，最好在清除其灰塵後，能在風扇軸處，點一點兒鍾表油，加強潤滑。
3、 注意接插頭、座、槽、板卡金手指部分的清潔
金手指的清潔，可以用橡皮擦拭金手指部分，或用酒精棉擦拭也可以。
插頭、座、槽的金屬引腳上的氧化現象的去除： 一是用酒精擦拭，一是用金屬片（如小一字改錐）在金屬引腳上輕輕刮擦。
4、 注意大規模集成電路、元器件等引腳處的清潔
清潔時，應用小毛刷或吸塵器等除掉灰塵，同時要觀察引腳有無虛焊和潮濕的現象，元器件是否有變形、變色或漏液現象。
5、 注意使用的清潔工具
清潔用的工具，首先是防靜電的。如清潔用的小毛刷，應使用天然材料製成的毛刷，禁用塑料毛刷。其次是如使用金屬工具進行清潔時，必須切斷電源，且對金屬工具進行泄放靜電的處理。
用於清潔的工具包括：小毛刷、皮老虎、吸塵器、抹布、酒精（不可用來擦拭機箱、顯示器等的塑料外殼）。
6、 對於比較潮濕的情況，應想辦法使其乾燥後再使用。可用的工具如電風扇、電吹風等，也可讓其自然風干。
十、軟體調試的幾個方法和建議
1、 操作系統方面。
主要的調整內容是操作系統的啟動文件、系統配置參數、組件文件、病毒等。
修復操作系統啟動文件。
1) 對於Windows 9x系統，可用SYS命令來修復（要保證MSDOS.SYS的大小在1KB以上），但要求，在修復之前應保證分區參數是正確的。這可使用諸如DiskMap之類的軟體實現；
2) 對於Windows 2000/XP系統，有兩種方法——修復啟動文件，使用fixboot命令；修復主引導記錄，使用fixmbr命令。
調整操作系統配置文件。
A. 對於Windows 9x系統，可用的工具很多，如：Msconfig命令、系統文件檢查器、注冊表備份和恢復命令（scanreg.exe，它要求在DOS環境下運行。另外如果要用scanreg.exe恢復注冊表，最好使用所列出的恢復菜單中的第二個備份文件）等；
B. 對於Windows 2000系統，可用的工具與Windows 9x相比比較少，但某些調試命令可用Win98中的一些命令（如win98下的Msconfig命令，就可用在windows 2000下）；
C. 對於Windows XP系統，可用的工具主要是Msconfig命令；
D. 調整電源管理和有關的服務，可以使用的命令是，要「運行」文本框中輸入gpedit.msc來進行；
E. 所有操作系統的調試，都可通過控制面板、設備管理器、計算機管理器（Windows 9x系統無）來進行系統的調試。
組件文件（包括.DLL、.VXD等）的修復
A. 通過添加刪除程序來重新安裝；
B. 通過從.CAB文件中提取安裝；
C. 可用系統文件檢查器（sfc.exe命令）來修復有錯誤的文件；
D. 從好的機器上拷貝覆蓋。
檢查系統中的病毒。
建議使用命令行方式下的病毒查殺軟體，並能直接訪問諸如NTFS分區。
2、 設備驅動安裝與配置方面。
主要調整設備驅動程序是否與設備匹配、版本是否合適、相應的設備在驅動程序的作用下能否正常響應。
A. 最好先由操作系統自動識別（特別要求的除外，如一些有特別要求的顯示卡驅動、音效卡驅動、非即插即用設備的驅動等），而後考慮強行安裝。這樣有利於判斷設備的好壞；
B. 如果有操作系統自帶的驅動，則先使用，仍不能正常或不能滿足應用需要，則使用設備自帶的驅動；
C. 更換設備，應先卸載驅動再更換。卸載驅動，可從設備管理器中卸載；再從安全模式下卸載；進而在INF目錄中刪除；最後通過注冊表卸載；
D. 更新驅動時，如直接升級有問題，須先卸載再更新。
3、 磁碟狀況方面。
檢查磁碟上的分區是否能訪問、介質是否有損壞、保存在其上的文件是否完整等。
可用的調整工具：
A. DiskMap，方便地找回正確的分區；
B. Fdisk及Fdisk /MDR，檢查分區是否正確及使主引導記錄恢復到原始狀態；
C. 當硬碟容量大於64GB時，如果要重新分區或查看分區，要求使用隨機附帶的磁碟分區軟盤中的Fdisk命令。這個命令可用windows Me下的Fdisk命令來代替；
D. Format、Scandisk、廠商提供的磁碟檢測程序，檢查磁碟介質是否有壞道；
E. 文件不完整時，要求對不完整的文件先進行改名，再用在「操作系統方面」中所述的方法重建。
4、 應用軟體方面。
如應用軟體是否與操作系統或其它應用有兼容性的問題、使用與配置是否與說明手冊中所述的相符、應用軟體的相關程序、數據等是否完整等；
5、 BIOS設置方面。
1) 在必要時應先恢復到最優狀態。建議：在維修時先把BIOS恢復到最優狀態（一般是出廠時的狀態），然後根據應用的需要，逐步設置到合適值。
2) BIOS刷新不一定要刷新到最新版，有時應考慮降低版本。
6、 重建系統。
在硬體配置正確，並得到用戶許可時，可通過重建系統的方法來判斷操作系統之類軟體故障，在用戶不同意的情況下，建議使用自帶的硬碟，來進行重建系統的操作。在這種情況下，最好重建系統後，逐步復原到用戶原硬碟的狀態，以便判斷故障點。
1 本站域名：http://www.cn12.com
本站論壇：http://www.jxlb.com/cgi-bin/leoboard.cgi
㈢ 如何做好軟體項目的驗收
項目驗收是公司乃至每個項目成員都想要的結果，一旦驗收對公司來說就是，可以收驗收階段的款了，不需要再投入那麼多人力到項目當中，項目終於可以告 一段落，大家都可以輕松一下了。項目驗收是一系列細致工作完成到位的結果，而不是某一點的成功或某個人能力就可以促成的事情。一個項目的驗收，一般是由一 系列驗收准備工作組成的。如果我們在最終驗收前，已經將很多階段的工作細化並得到認可執行，那麼項目驗收也就是水到渠成的事情了。首先我們要明確進入驗收的前提。很多人都認為只要我們完成了合同中規定的內容，完成了需求規格說明中規定的工作，並且按合同試運行了幾個月，應該就可以驗收了。就可以拿著合同或技術協議與客戶談論驗收的相關事宜了。但 實際上客戶往往不同意在此時驗收。他們的判斷往往不是招標書、合同、技術協議、需求規格說明書等文檔。其實這些文檔無論做得如何細致，對用戶而言並沒太大 的參考價值。客戶關心的是他們的業務是否真地在系統中運作，並且運行良好，並以此作為檢驗項目驗收的標准。當然有的項目也可以通過商務運作，在業務實現不 太好的情況下驗收。1、在項目實施過程中注重里程碑的確定，制定階段性目標如果要做好一個項目，完成項目的驗收條件，主要還是以業務是否可用作為衡量的。不是一定得實現所有用戶的需求（這里指的是口頭上的需求，如果落實到文字上的還是要實現的），也不是只有將一些所謂的技術難點解決用戶就會同意驗收，而是我們可以完成一定的階段應用業務目標。我們從進行需求調研的時候就要主動控制項目的邊界，將一個一個業務流根據客戶方的實際情況合理組織實施順序，形成我們項目實施計劃中的里程碑點，明確達到里程碑點的條件，並得到雙方一致正式認可。沒有雙方高度達成一致的里程碑認可，也就是沒有項目目標約定，沒有目標約定的項目實施計劃一定會經常變更內容、變更初始設定目標，導致計劃不可控制，更談不上驗收。很多人希望通過詳細的系統需求規格說明書來定義項目要實現的內容和業務目標，這是很有必要的，但需求規格說明書得到認可並非是通過用戶審核就可以的結果，應該想辦法讓用戶一起參與到需求規格說明書的制定過程中來，變成用戶自己推導出來的業務實施目標，未來才不容易變形。2、積極主動地與客戶進行溝通 項目中一定要有溝通策略，和高管如何匯報工作進展，取得支持？和中層如何就業務目標不斷確認，逐步清晰？和基層如何就項目應用操作模式達成一致，持續改進？都需要通過溝通反饋完成。溝 通的作用對於高管是讓他們清楚我們一直按照項目目標前進，每個階段工作進展是否順利，影響項目正常運做原因是什麼，需要哪些資源幫助。和高管溝通比較多的 話，第一個好處是高管經常聽匯報就知道項目進展程度，可以安排反饋檢查，看是否具備我們所說的進展，這樣一旦認可了各個階段目標後，最終要求高管簽字確認 也就順理成章了。給高管匯報技巧就是簡潔明了，真實客觀，有理有據分析問題，提出對策建議請其決策即可。中層往往是項目主要的推動力量和實際執行者，也往往是對具體業務需求最主要的要求者，他們對企業實際運做過程最清楚，提出要求最具體，而且項目驗收與否沒有中層的同意往往也是不太容易做到的。往往通過前期業務調研只能對企業項目目標有一個大的，宏觀的認識，但如何細化並最終落實並非是一步到位的過程。因此在整個項目過程中，雙方項目組要不斷溝通，特別是企業中層溝通，才能逐步認識越來越深刻，最終達成一致。和基層的溝通主要體現對最終用戶的關懷，定期主動和最終用戶溝通，消除一些怨氣，讓用戶能堅持用下去，這個時候我們往往發現很多用戶真的是非常好相處，盡管軟體還有很多值得改進的地方，但他們一旦認可我們團隊，反而會盡心盡力幫助我們推動項目的進行。目前我們公司一般要求每個項目經理在項目進行中都要填寫詳盡的項目月報，反映項目的進度，與計劃的偏差，完成的項目內容，投入人力，目前項目存在的問題，以及預計項目下月的進度等等。將進度月報交部門負責人、項目管理中心、總經辦審閱。類似地也要制定針對客戶的月報甚至是周報，將相關的信息反應到客戶方的負責人，及相關高層。可以先發郵件，然後還要電話落實收到並口頭簡要匯報，特別是高管層，千萬不要以為發了就等於別人會去看，一定要口頭跟進匯報一次，保證客戶各方面負責人對項目進展做到心中有數。在 項目的過程中，我們也需要注意平時做人的積累，比如要做到講誠信，講原則。主要是三條：1）做不到的事情千萬別隨意承諾；2）承諾的事情一定要努力做 到；3）每次做到的事情都進步一點點。按這三條做事，即使在系統的使用過程中總會有這樣或那樣的一些不方便，用戶也會慢慢接受稍微長一點的響應周期，也會 用更多積極性眼光看現在的問題，也相信問題一定有人響應，也一定可以得到解決。進而使我們和客戶之間形成一種較為和諧的關系。3、寫好備忘錄和問題跟蹤記錄 在一個漫長項目周期中，很多工作做了也就做了，認可了也就認可了，時間一長也就忘記了很多承諾和約定，到了驗收的時候就可能重新翻出來，這種事情很多人可能都經歷過，明明說可以先不做的內容最終驗收的時候又成了必要條件。每次備忘錄要口頭交流認可後才列印簽字確定階段性工作成果。下次工作則根據前次備忘錄的雙方約定繼續進行，保障項目在每次工作基礎上不斷前進，並用備忘錄約束雙方的行為。同 時我們建議在收集項目出現的各種問題時，採用問題跟蹤記錄表的形式，這樣可以一目瞭然地顯示出我們曾經收集到的各種問題，目前的解決情況，以及還有什麼問 題沒有解決，准備什麼時候解決。這樣客戶和我們都會對目前的情況非常了解，通過不斷地解決出現的問題，來收斂可能出現的問題，當存在的問題越來越少時，也 就表示我們的系統已經在接近驗收的標准了。4、驗收階段的准備工作及注意事項 當 系統經過一段試運行，具備驗收的各項條件之後，我們就需要著手驗收階段的准備工作了。首先我們需要把到目前為止完成的工作進行一個總結，列出我們已經完成 的各項目工作成果、各類文檔，對合同以及各類約定的技術文檔中的相關內容進行自查，要徹底了解系統目前完成的情況如何，是否已經完成了與客戶方達成的各項 書面約定以及口頭約定，沒有完成的，如果是書面約定，准備採取什麼策略去進一步完成或者採取一定的迴避措施，使客戶在驗收的時候不再提出這些未實現的需 求。做一個詳細的驗收計劃是非常必 要的，可以用來作為驗收階段的工作指導。這就需要與客戶進行詳細的溝通，再次明確驗收前需要完成的工作，盡量避免客戶方在此階段提出過多的更改需求，這是 極為重要的。驗收計劃中不光要有需要繼續完成的工作，還需要有一個相對固定的工期，使雙方都繼續朝著這個方向去努力，防止無限制的拖延。我們很多的項目碰到的一些常見 問題就是軟體開發完之後，很多客戶也不使用，如果我們去催促他們的時候，就經常推脫工作太忙，還有其它的事要做等等，或者也就是應付一下隨便提一兩個小問 題。而等我們提出要驗收的時候，他們又總是覺得這也不滿意那也不滿意，總之是怕承擔相應的責任，不願意驗收。針對這種情況我想主要還是想辦 法讓客戶盡量把系統使用起來，只有在使用中才能發現問題，我們也才能解決問題，使系統能更好地運行。如果是基層的人員不願意使用，我們可以走上層路線，使 客戶的高層了解項目正常運行的重要性，也使他們意識到項目驗收的重要性，意識到無限制地拖延下去會對政府機會的權威、形象和公司的收益造成不好的影響，利 用他們的主觀積極性克制拖沓的工作作風。如果項目經理在這方面沒有太多的辦法的時候，可以讓市場人員動用一些商業運作的手段，或者提請公司高層出面與客戶 方的高層盡早溝通，明確系統運行的各項工作。還有一種情況就是客戶無窮盡地提出一些需求，一些主要領導對系統指指點點，隨便一句話，就要進行需求變更，項目的范圍不斷擴大，導致項目試運行一直無法結束。甚至一些客戶追求系統的完美，提出了很多高難度的需求，導致我們需要投入較多的精力去解決。這 種情況，我覺得是一些政府主管領導對電子政務認識上存在一定的誤區，認為這么一個系統就應該能夠解決所有的問題。其實信息系統只是政府管理工作的一種輔助 性手段，信息化不是一步到位工程，而是一種長期的、不斷改善的系統工程。我們應該想法讓他們結合實際情況，提出他們真正需要解決的問題，而不是依靠他們的 長官意志，提出一些不切合實際的、易變的需求。要實現這一點，就需要項目經理安排人員定期到政府機關進行信息化普及培訓以及項目管理知識培訓。同時在合適 的情況下，建議在該項目驗收後啟動新的項目來完成一些新的需求。項目驗收對任何一個項目管理者 都是一個極大的挑戰，即使已經採取本文提到的幾種手段，也不能保證我們的項目能夠順利驗收，但作為項目的承建方，我們所能做到的就是盡量做好我們所能控制 的事情，另外一些很難由我們控制的事情則需要借用一些其它的力量去完成，比如請市場部運用一些商業手段來促成項目的驗收等等。本文中提出的這些建議，是希 望能夠起到拋磚引玉的效果，希望各位同仁可以提出更多更好的方法來促進我們的項目如期驗收。
㈣ 軟體項目客戶遲遲不肯驗收怎麼辦
在項目驗收的時候，對於項目中可能存在的一些問題，不要讓客戶想等系統沒有一點問題或保證以後沒有問題的情況下才驗收。如果客戶這樣想開發團隊就麻煩了，微軟那麼牛，做的操作系統還天天打補丁。開發團隊要讓客戶明白，所謂驗收，就是依照合同需求和能夠滿足企業的需求，結果和預期結果一致就應該算通過了，而且還容許有一些小錯誤留在驗收後改正。 一般來說，現場長時間驗收檢查不太可行。因此，在驗收前准備階段，項目負責人應主動、積極的與客戶密切溝通，及時、准確地收集和理解驗收條件。特別是客戶對即將驗收項目的真實、初步意見和評價，最好是在驗收前就溝通好和形成書面正式的《項目評價報告》。如還留有一些可能影響或暫時不影響項目整體驗收通過的細節、小問題、變更或異議、分歧等，應與客戶協商解決處理好，做到事先溝通、達成共識。強調已經基本上完成項目內容，滿足合同要求。 如何順利地讓客戶進入驗收狀態？ 如何才能順利地讓客戶進行驗收是一直困撓開發團隊的一個難題，為了避免項目驗收遙遙無期的局面，建議加強以下幾方面工作。 （1）及時解決問題，端正處理BUG的態度 既然發現軟體存在問題，就應該盡力去解決，這是開發團隊的責任。客戶不肯驗收，主要是害怕承擔責任，畢竟還有問題沒有解決嘛。如果換做我，我也不會給你驗收的。因此，要想讓客戶方驗收，首先要做好合同的明確規定和服務承諾。並以此為依據，讓客戶放心，讓客戶方驗收。在開發過程中給客戶感覺是不是用心的做事是很重要的，否則的話後期驗收就會有點困難了。 在項目過程中，需要注意平時承諾的積累，比如要做到講誠信、講原則。主要是三條：做不到的事情千萬別隨意承諾、承諾的事情一定要努力做到、每次做到的事情都要進步一點點。按這三條做事，即使在與與客戶溝通中有這樣或那樣的不愉快和矛盾，客戶也會慢慢接受，也會用更多積極性眼光看存在的BUG問題。當然，項目中如果有關鍵瑕疵，也是客戶忌諱的，開發團隊一定要理解這些瑕疵並解決好。 （2）平衡和識別項目干係人需求 在項目驗收階段前，要盡量識別和關注所有項目干係人的需求和態度，並時刻給客戶灌輸只要完成那幾項工作就代表項目可以驗收了。當客戶不肯驗收時，要與客戶展開深入的交流，明確客戶為什麼不願意驗收。有時客戶的問題只是借口，所以要根據客戶的表現判斷出這個背後的問題所在。當找到問題後，協調相關的資源來解決。有時和客戶直接把問題攤開溝通，或許是比較好的解決方法。 總之，開發團隊應要對項目利害關系者進行關注，和關注他們關注的內容，或者他們擔憂的內容。作為開發團隊要做到盡量做好所能控制的事情，另外一些很難由開發團隊控制的事情則需要借用一些其它的力量去完成。比如關注項目利害關系者的一些秘密需求是否得到了滿足，或請高層領導運用一些商業手段來促成項目的驗收等。 （3）重視階段性成果驗收，提高客戶感知度 其實，軟體開發項目驗收遠非是僅僅對系統的測試和檢驗這樣簡單，它是開發團隊和客戶在開發過程中雙方合作博弈的結果。因此，在項目開發過程之中，與客戶的溝通和績效匯報是非常重要的。客戶之所以遲遲不驗收項目，簡單的說是因為客戶對開發團隊做的項目不滿意。 一般來說，滿意=感知-期望。因此，客戶不滿意是因為客戶的感知度非常低，而期望很高。換句話說，是由於開發團隊對項目需求沒有定義好，或者沒有分析好，或在定義需求的時候沒有考慮到客戶的感知和期望，導致現在的項目驗收困難。所以，一方面量化和降低客戶的期望值，另一方面盡量提高客戶的感知度是非常重要的。方法可以是對於每一個階段性的成果，盡量讓客戶可以參與並且驗收，目的是為了盡可能來提高客戶的感知度。 （4）清晰處理好客戶反饋問題的跟蹤狀態 在一個項目開發周期中，每次客戶的反饋問題都需要認真做好跟蹤記錄。下次工作要根據前次備忘錄的雙方約定或客戶的反饋問題繼續進行，保障項目在雙溝通的基礎上不斷前進，並用備忘錄約束雙方的行為。 建議在收集項目出現的各種問題時，採用問題跟蹤記錄表的形式，這樣可以一目瞭然地顯示出曾經收集到的各種問題、目前的解決情況、以及還有什麼問題沒有解決，或准備什麼時候解決。這樣客戶和開發團隊就都會對目前的情況非常了解，通過不斷地解決出現的問題，來收斂可能出現的問題。當存在的問題越來越少時，也就表示項目開發已經在接近驗收的標准了，也可使客戶在需要驗收的時候不能再找各種各樣的借口來拖延驗收。
㈤ 軟體開發客戶驗收，如果出現出現客戶惡意不驗收，如何解決
一般來說，當軟體開發項目到了具備驗收的各項條件之後，開發團隊就會著手准備驗收階段的工作。但如果這時發生客戶不願意驗收的話，這是一個讓開發團隊很頭痛和很普遍的問題。原因是多方面的，如果出現出現客戶惡意不驗收，沒有特別辦法的時候，也只能傷感情了。
其實，疫情期間，客戶因資金原因會找各種借口推遲驗收，這也是很常見的。有時，客戶遲遲不肯驗收或故意推遲驗收，有可能客戶是以推遲驗收而推遲結算和要支付的款項。對於有這種想法的客戶是最讓開發團隊為難的了。動用法律吧，擔心破壞了長久建立的關系；不動用法律吧，還真有這么不客氣的客戶。
㈥ 怎樣做好軟體項目驗收工作
項目驗收是公司乃至每個項目成員都想要的結果，一旦驗收對公司來說就是，可以收驗收階段的款了，不需要再投入那麼多人力到項目當中，項目終於可以告一段落，大家都可以輕松一下了。項目驗收是一系列細致工作完成到位的結果，而不是某一點的成功或某個人能力就可以促成的事情。一個項目的驗收，一般是由一系列驗收准備工作組成的。如果我們在最終驗收前，已經將很多階段的工作細化並得到認可執行，那麼項目驗收也就是水到渠成的事情了。 首先我們要明確進入驗收的前提。很多人都認為只要我們完成了合同中規定的內容，完成了需求規格說明中規定的工作，並且按合同試運行了幾個月，應該就可以驗收了。就可以拿著合同或技術協議與客戶談論驗收的相關事宜了。 但實際上客戶往往不同意在此時驗收。他們的判斷往往不是招標書、合同、技術協議、需求規格說明書等文檔。其實這些文檔無論做得如何細致，對用戶而言並沒太大的參考價值。客戶關心的是他們的業務是否真地在系統中運作，並且運行良好，並以此作為檢驗項目驗收的標准。當然有的項目也可以通過商務運作，在業務實現不太好的情況下驗收。 1、在項目實施過程中注重里程碑的確定，制定階段性目標 如果要做好一個項目，完成項目的驗收條件，主要還是以業務是否可用作為衡量的。不是一定得實現所有用戶的需求(這里指的是口頭上的需求，如果落實到文字上的還是要實現的)，也不是只有將一些所謂的技術難點解決用戶就會同意驗收，而是我們可以完成一定的階段應用業務目標。 我們從進行需求調研的時候就要主動控制項目的邊界，將一個一個業務流根據客戶方的實際情況合理組織實施順序，形成我們項目實施計劃中的里程碑點，明確達到里程碑點的條件，並得到雙方一致正式認可。 沒有雙方高度達成一致的里程碑認可，也就是沒有項目目標約定，沒有目標約定的項目實施計劃一定會經常變更內容、變更初始設定目標，導致計劃不可控制，更談不上驗收。 很多人希望通過詳細的系統需求規格說明書來定義項目要實現的內容和業務目標，這是很有必要的，但需求規格說明書得到認可並非是通過用戶審核就可以的結果，應該想辦法讓用戶一起參與到需求規格說明書的制定過程中來，變成用戶自己推導出來的業務實施目標，未來才不容易變形。項目經理博客 2、積極主動地與客戶進行溝通 項目中一定要有溝通策略，和高管如何匯報工作進展，取得支持?和中層如何就業務目標不斷確認，逐步清晰?和基層如何就項目應用操作模式達成一致，持續改進?都需要通過溝通反饋完成。溝通的作用對於高管是讓他們清楚我們一直按照項目目標前進，每個階段工作進展是否順利，影響項目正常運做原因是什麼，需要哪些資源幫助。和高管溝通比較多的話，第一個好處是高管經常聽匯報就知道項目進展程度，可以安排反饋檢查，看是否具備我們所說的進展，這樣一旦認可了各個階段目標後，最終要求高管簽字確認也就順理成章了。 給高管匯報技巧就是簡潔明了，真實客觀，有理有據分析問題，提出對策建議請其決策即可。 中層往往是項目主要的推動力量和實際執行者，也往往是對具體業務需求最主要的要求者，他們對企業實際運做過程最清楚，提出要求最具體，而且項目驗收與否沒有中層的同意往往也是不太容易做到的。項目管理培訓 往往通過前期業務調研只能對企業項目目標有一個大的，宏觀的認識，但如何細化並最終落實並非是一步到位的過程。因此在整個項目過程中，雙方項目組要不斷溝通，特別是企業中層溝通，才能逐步認識越來越深刻，最終達成一致。 和基層的溝通主要體現對最終用戶的關懷，定期主動和最終用戶溝通，消除一些怨氣，讓用戶能堅持用下去，這個時候我們往往發現很多用戶真的是非常好相處，盡管軟體還有很多值得改進的地方，但他們一旦認可我們團隊，反而會盡心盡力幫助我們推動項目的進行。目前我們公司一般要求每個項目經理在項目進行中都要填寫詳盡的項目月報，反映項目的進度，與計劃的偏差，完成的項目內容，投入人力，目前項目存在的問題，以及預計項目下月的進度等等。將進度月報交部門負責人、項目管理中心、總經辦審閱。項目經理圈子 類似地也要制定針對客戶的月報甚至是周報，將相關的信息反應到客戶方的負責人，及相關高層。
㈦ 軟體項目驗收的具體流程
1、流程內容 本流程描述項目驗收的全過程。即招投標管理 、軟體 采購 和簽訂信息系統合同的過程。
2、流程的起止點 項目驗收流程自開發商申請驗收，計算機信息中心主任決定驗收方案始，至財務資產處支付結算止。
3、術語解釋：二、流程涉及部門及職責 業務主管部門及職責：計算機信息中心：決定驗收方案、提供專家組名單、編寫科技項目（課題、專題）驗收申請表，進行系統測試、匯總驗收資料 提交驗收報告，申請項目付款2、業務參與部門及職責：系統驗收評審組：編寫驗收報告 技術中心：組成項目驗收組，審批驗收報告 財務資產處：支付結算