機房收費系統收費報告
1、專案資訊
專案名稱： 機房收費系統
2、專案概述
該專案，主要用於做學校機房中，學生上下機管理系統。該專案中，限定了使用者的許可權，做到更好的管理學生的上下機過程及相關事項。
3、驗收測試環境
遠端到五樓機房電腦，將安裝包安裝到機器上，進行測試。
開發人員：
測試人員：
4、驗收及測試結果
5、驗收總結
系統驗收結果有以下問題：
a）、對於一些用於查詢的文字框，用於顯示的組合框，只能起到顯示作用，而不能人為進行輸入。為了減少使用者使用過程中錯誤的發生，這點兒必須嚴格把關。
b）、可輸入文字框資料的驗校。哪些不能為空，哪些必須輸入數值型資料……這些都可以通過msgbox函式進行提醒，並用eixt sub退出該過程，防止錯誤的發生。
c）、資料有效性的驗校。比如卡號、學號的輸入必須限定輸入的位數。一般卡號限定十位，學號限定十 一位。防止使用者過長輸入。如果使用者輸入的資料過長，長到超過你限定的上限值，系統在執行時就會出錯。
d）、注意正在上機的卡不能退卡
e）、注意正在登入的使用者不能刪除，比如管理員使用者正在登入，假如能過刪除他，那麼再結賬時就會出錯。
f）、esc和回車鍵的相應。感覺每乙個窗體都應該設定，增加軟體的人性化特點。
g）、再次輸入卡號或者卡號有錯誤時，卡號應該是被選中狀態。假如有一群人要上機，通過設定卡號被選中，你就可以實現連續刷卡功能。
h）、下拉框的問題。我的系統，許多問題都是起自下拉框。應該根據實際情況，設定style為不同的值，盡最大可能減少錯誤的發生。
i）、command按鈕的問題。已經下過機或者已經結過帳的按鈕，enabled屬性應該設為false，或者通過清空相應文字框，並使用一些提醒框的方法，防止其多次操作。
j）、退卡後，是否能夠再次註冊，我原先非常肯定的認為：不能再次註冊是最好的，退卡就等同於該卡廢掉了。後來仔細想了想，感覺還是能夠註冊比較好。因為學生退卡後，卡應該是由工作人員收回來的，這樣就能夠實現卡的再次利用。
k）、充值框的限定。對於一些經常要認為輸入的文字框，我們要對它多做限定。比如充值框，充值時，必須只填寫數字，如果使用者在前面輸入很多零的處理，充值金額最大最少的限定。
l）、myflexgrid控制項的現實問題。該控制項顯示的時候，總是不能夠顯示完全所有資料，這是可以通過找 到乙個函式，自動調節該控制項的列寬，達到清晰顯示資料的目的。
m）、在查詢等操作時，原始碼是這樣寫的：
strsql="select * from student_info where cardno=' " & txtcardno.text & " ' "
那麼當我在txtcardno中輸入 ' or " =' 時，在執行這條sql命令時就會出錯。
n）、打包問題。我的系統打包的時候，出現很多問題。首先我的win7系統打包時，報表的dll檔案總是打包不進來，沒辦法，打包我是在xp下完成的。
對於以上問題，我都歸結他們是系統的健壯性的問題。乙個成功的軟體的成功研發，實現使用者所需要的功能是一方面，更重要的是，不要出現系統崩潰的現象。
6、建議：
o）、在卡法系統之前，先對軟體的整體做乙個把握，先把軟體的整體構架構建出來，然後在想裡面添血添肉；
p）、制定軟體開發計畫。
q）、合理測試。
機房收費系統驗收報告
首先感謝小崔，小崔不厭其煩的給我進行了兩次驗收。在這兩次的驗收過程中幫我找出了很多的問題，經過改正，系統明顯比之前要健壯的多。一 專案資訊 專案名稱 機房收費系統 二 專案概述 該專案，主要用於做學校機房中，學生上下機管理系統。該專案中，限定了使用者的許可權，做到更好的管理學生的上下機過程及相關事項...
專案驗收報告模板
專案名稱 專案合同甲方 專案合同乙方 合同型別 技術開發合同 合同簽訂時間 目的在於對專案進行全方位的檢驗和測評，檢驗乙方提供的軟體系統是否遵循軟體開發標準的要求，檢驗各項指標與功能是否與合同要求吻合。驗收範圍已雙方簽訂的技術開發合同所描述的內容為準。專案名稱 驗收單位 開發單位 驗收時間 專案負責...
機房收費系統 驗收
自己的機房收費系統開始的算是非常晚的，由於開始的晚。就導致了一件事情。拖。由於開始的時候，搬家。搬學習的地方，然後itoo的專案也開始，事情都堆在一塊兒，然後就做不動了。自己身為組長，突然就感覺到了壓力。以下總結一下自己通過這次機房合作的不足。由於是三個人一起合作。所以就非常自然地每人負責一到兩層。...