Ⅰ 如何做好軟體項目的驗收
項目驗收是公司乃至每個項目成員都想要的結果，一旦驗收對公司來說就是，可以收驗收階段的款了，不需要再投入那麼多人力到項目當中，項目終於可以告 一段落，大家都可以輕松一下了。項目驗收是一系列細致工作完成到位的結果，而不是某一點的成功或某個人能力就可以促成的事情。一個項目的驗收，一般是由一 系列驗收准備工作組成的。如果我們在最終驗收前，已經將很多階段的工作細化並得到認可執行，那麼項目驗收也就是水到渠成的事情了。首先我們要明確進入驗收的前提。很多人都認為只要我們完成了合同中規定的內容，完成了需求規格說明中規定的工作，並且按合同試運行了幾個月，應該就可以驗收了。就可以拿著合同或技術協議與客戶談論驗收的相關事宜了。但 實際上客戶往往不同意在此時驗收。他們的判斷往往不是招標書、合同、技術協議、需求規格說明書等文檔。其實這些文檔無論做得如何細致，對用戶而言並沒太大 的參考價值。客戶關心的是他們的業務是否真地在系統中運作，並且運行良好，並以此作為檢驗項目驗收的標准。當然有的項目也可以通過商務運作，在業務實現不 太好的情況下驗收。1、在項目實施過程中注重里程碑的確定，制定階段性目標如果要做好一個項目，完成項目的驗收條件，主要還是以業務是否可用作為衡量的。不是一定得實現所有用戶的需求（這里指的是口頭上的需求，如果落實到文字上的還是要實現的），也不是只有將一些所謂的技術難點解決用戶就會同意驗收，而是我們可以完成一定的階段應用業務目標。我們從進行需求調研的時候就要主動控制項目的邊界，將一個一個業務流根據客戶方的實際情況合理組織實施順序，形成我們項目實施計劃中的里程碑點，明確達到里程碑點的條件，並得到雙方一致正式認可。沒有雙方高度達成一致的里程碑認可，也就是沒有項目目標約定，沒有目標約定的項目實施計劃一定會經常變更內容、變更初始設定目標，導致計劃不可控制，更談不上驗收。很多人希望通過詳細的系統需求規格說明書來定義項目要實現的內容和業務目標，這是很有必要的，但需求規格說明書得到認可並非是通過用戶審核就可以的結果，應該想辦法讓用戶一起參與到需求規格說明書的制定過程中來，變成用戶自己推導出來的業務實施目標，未來才不容易變形。2、積極主動地與客戶進行溝通 項目中一定要有溝通策略，和高管如何匯報工作進展，取得支持？和中層如何就業務目標不斷確認，逐步清晰？和基層如何就項目應用操作模式達成一致，持續改進？都需要通過溝通反饋完成。溝 通的作用對於高管是讓他們清楚我們一直按照項目目標前進，每個階段工作進展是否順利，影響項目正常運做原因是什麼，需要哪些資源幫助。和高管溝通比較多的 話，第一個好處是高管經常聽匯報就知道項目進展程度，可以安排反饋檢查，看是否具備我們所說的進展，這樣一旦認可了各個階段目標後，最終要求高管簽字確認 也就順理成章了。給高管匯報技巧就是簡潔明了，真實客觀，有理有據分析問題，提出對策建議請其決策即可。中層往往是項目主要的推動力量和實際執行者，也往往是對具體業務需求最主要的要求者，他們對企業實際運做過程最清楚，提出要求最具體，而且項目驗收與否沒有中層的同意往往也是不太容易做到的。往往通過前期業務調研只能對企業項目目標有一個大的，宏觀的認識，但如何細化並最終落實並非是一步到位的過程。因此在整個項目過程中，雙方項目組要不斷溝通，特別是企業中層溝通，才能逐步認識越來越深刻，最終達成一致。和基層的溝通主要體現對最終用戶的關懷，定期主動和最終用戶溝通，消除一些怨氣，讓用戶能堅持用下去，這個時候我們往往發現很多用戶真的是非常好相處，盡管軟體還有很多值得改進的地方，但他們一旦認可我們團隊，反而會盡心盡力幫助我們推動項目的進行。目前我們公司一般要求每個項目經理在項目進行中都要填寫詳盡的項目月報，反映項目的進度，與計劃的偏差，完成的項目內容，投入人力，目前項目存在的問題，以及預計項目下月的進度等等。將進度月報交部門負責人、項目管理中心、總經辦審閱。類似地也要制定針對客戶的月報甚至是周報，將相關的信息反應到客戶方的負責人，及相關高層。可以先發郵件，然後還要電話落實收到並口頭簡要匯報，特別是高管層，千萬不要以為發了就等於別人會去看，一定要口頭跟進匯報一次，保證客戶各方面負責人對項目進展做到心中有數。在 項目的過程中，我們也需要注意平時做人的積累，比如要做到講誠信，講原則。主要是三條：1）做不到的事情千萬別隨意承諾；2）承諾的事情一定要努力做 到；3）每次做到的事情都進步一點點。按這三條做事，即使在系統的使用過程中總會有這樣或那樣的一些不方便，用戶也會慢慢接受稍微長一點的響應周期，也會 用更多積極性眼光看現在的問題，也相信問題一定有人響應，也一定可以得到解決。進而使我們和客戶之間形成一種較為和諧的關系。3、寫好備忘錄和問題跟蹤記錄 在一個漫長項目周期中，很多工作做了也就做了，認可了也就認可了，時間一長也就忘記了很多承諾和約定，到了驗收的時候就可能重新翻出來，這種事情很多人可能都經歷過，明明說可以先不做的內容最終驗收的時候又成了必要條件。每次備忘錄要口頭交流認可後才列印簽字確定階段性工作成果。下次工作則根據前次備忘錄的雙方約定繼續進行，保障項目在每次工作基礎上不斷前進，並用備忘錄約束雙方的行為。同 時我們建議在收集項目出現的各種問題時，採用問題跟蹤記錄表的形式，這樣可以一目瞭然地顯示出我們曾經收集到的各種問題，目前的解決情況，以及還有什麼問 題沒有解決，准備什麼時候解決。這樣客戶和我們都會對目前的情況非常了解，通過不斷地解決出現的問題，來收斂可能出現的問題，當存在的問題越來越少時，也 就表示我們的系統已經在接近驗收的標准了。4、驗收階段的准備工作及注意事項 當 系統經過一段試運行，具備驗收的各項條件之後，我們就需要著手驗收階段的准備工作了。首先我們需要把到目前為止完成的工作進行一個總結，列出我們已經完成 的各項目工作成果、各類文檔，對合同以及各類約定的技術文檔中的相關內容進行自查，要徹底了解系統目前完成的情況如何，是否已經完成了與客戶方達成的各項 書面約定以及口頭約定，沒有完成的，如果是書面約定，准備採取什麼策略去進一步完成或者採取一定的迴避措施，使客戶在驗收的時候不再提出這些未實現的需 求。做一個詳細的驗收計劃是非常必 要的，可以用來作為驗收階段的工作指導。這就需要與客戶進行詳細的溝通，再次明確驗收前需要完成的工作，盡量避免客戶方在此階段提出過多的更改需求，這是 極為重要的。驗收計劃中不光要有需要繼續完成的工作，還需要有一個相對固定的工期，使雙方都繼續朝著這個方向去努力，防止無限制的拖延。我們很多的項目碰到的一些常見 問題就是軟體開發完之後，很多客戶也不使用，如果我們去催促他們的時候，就經常推脫工作太忙，還有其它的事要做等等，或者也就是應付一下隨便提一兩個小問 題。而等我們提出要驗收的時候，他們又總是覺得這也不滿意那也不滿意，總之是怕承擔相應的責任，不願意驗收。針對這種情況我想主要還是想辦 法讓客戶盡量把系統使用起來，只有在使用中才能發現問題，我們也才能解決問題，使系統能更好地運行。如果是基層的人員不願意使用，我們可以走上層路線，使 客戶的高層了解項目正常運行的重要性，也使他們意識到項目驗收的重要性，意識到無限制地拖延下去會對政府機會的權威、形象和公司的收益造成不好的影響，利 用他們的主觀積極性克制拖沓的工作作風。如果項目經理在這方面沒有太多的辦法的時候，可以讓市場人員動用一些商業運作的手段，或者提請公司高層出面與客戶 方的高層盡早溝通，明確系統運行的各項工作。還有一種情況就是客戶無窮盡地提出一些需求，一些主要領導對系統指指點點，隨便一句話，就要進行需求變更，項目的范圍不斷擴大，導致項目試運行一直無法結束。甚至一些客戶追求系統的完美，提出了很多高難度的需求，導致我們需要投入較多的精力去解決。這 種情況，我覺得是一些政府主管領導對電子政務認識上存在一定的誤區，認為這么一個系統就應該能夠解決所有的問題。其實信息系統只是政府管理工作的一種輔助 性手段，信息化不是一步到位工程，而是一種長期的、不斷改善的系統工程。我們應該想法讓他們結合實際情況，提出他們真正需要解決的問題，而不是依靠他們的 長官意志，提出一些不切合實際的、易變的需求。要實現這一點，就需要項目經理安排人員定期到政府機關進行信息化普及培訓以及項目管理知識培訓。同時在合適 的情況下，建議在該項目驗收後啟動新的項目來完成一些新的需求。項目驗收對任何一個項目管理者 都是一個極大的挑戰，即使已經採取本文提到的幾種手段，也不能保證我們的項目能夠順利驗收，但作為項目的承建方，我們所能做到的就是盡量做好我們所能控制 的事情，另外一些很難由我們控制的事情則需要借用一些其它的力量去完成，比如請市場部運用一些商業手段來促成項目的驗收等等。本文中提出的這些建議，是希 望能夠起到拋磚引玉的效果，希望各位同仁可以提出更多更好的方法來促進我們的項目如期驗收。
Ⅱ 軟體項目驗收的具體流程
1、流程內容 本流程描述項目驗收的全過程。即招投標管理 、軟體 采購 和簽訂信息系統合同的過程。
2、流程的起止點 項目驗收流程自開發商申請驗收，計算機信息中心主任決定驗收方案始，至財務資產處支付結算止。
3、術語解釋：二、流程涉及部門及職責 業務主管部門及職責：計算機信息中心：決定驗收方案、提供專家組名單、編寫科技項目（課題、專題）驗收申請表，進行系統測試、匯總驗收資料 提交驗收報告，申請項目付款2、業務參與部門及職責：系統驗收評審組：編寫驗收報告 技術中心：組成項目驗收組，審批驗收報告 財務資產處：支付結算
Ⅲ 軟體項目驗收怎麼做需要提交書面資料
政府項目驗收一般是根據咱們立項書上提的技術指標進行驗收測試，需要提供的資料報告開發需求文檔，操作手冊和委託測試申請表。價格的話一般是根據咱們項目金額的3%到8%進行收取，完成周期一般控制在7-15個工作日，不過驗收測試很有可能會涉及到有不通過項，遇到有整改時間的另算。詳情頁可以咨詢到我，因為政府項目驗收現在都是要求走CMA的質量體系。
Ⅳ 軟體開發項目驗收要做哪些測試
1、業務流程測試
對軟體項目的典型業務流程進行測試。
2、容錯測試
容錯測試的檢查內容包括:
2.1軟體對用戶常見的誤操作是否能進行提示;
2.2軟體對用戶的的操作錯誤和軟體錯誤,是否有準確、清晰的提示;
2.3軟體對重要數據的刪除是否有警告和確認;
2.4軟體是否能判斷數據的有效性,屏蔽用戶的錯誤輸入,識別非法值,並有相應的錯誤提示。
3、安全性測試
安全性測試的檢查內容包括:
3.1軟體中的密鑰是否以密文方式存儲;
3.2軟體是否有留痕功能,即是否保存有用戶的操作日誌; 3)軟體中各種用戶的許可權分配是否合理。
4、易用性測試
易用性測試的內容包括:
4.1軟體的用戶界面是否友好,是否出現中英文混雜的界面;
4.2軟體中的提示信息是否清楚、易理解,是否存在原始的英文提示; 3)軟體中各個模塊的界面風格是否一致;
4.3軟體中的查詢結果的輸出方式是否比較直觀、合理。
4.4適應性測試參照用戶的軟、硬體使用環境和需求規格說明書中的規定,列出開發的軟體需要滿足的軟、硬體環境。對每個環境進行測試。
5、文檔測試
用戶文檔包括:安裝手冊、操作手冊和維護手冊。
對用戶文檔測試的內容包括:
5.1操作、維護文檔是否齊全、是否包含產品使用所需的信息和所有的功能模塊;
5.2用戶文檔描述的信息是否正確,是否沒有歧義和錯誤的表達;
5.3戶文檔是否容易理解,是否通過使用適當的術語、圖形表示、詳細的解釋來表達;
5.5用戶文檔對主要功能和關鍵操作是否提供應用實例;
5.6用戶文檔是否有詳細的目錄表和索引表。
6、性能測試
對軟體需求規格說明書中明確的軟體性能進行測試。測試的准則是要滿足規格明書中的各項性能指標。
7、用戶有特別要求的測試。