軟件驗收報告（通用5篇）

軟件驗收報告 篇1

　　用戶名稱： huaxia

　　密級：huaxia123

　　文檔編號：

　　編 寫：

　　審 核：

　　批 準

　　項目名稱：

　　編寫日期：

　　審核日期：

　　批準日期：

　　項目名稱

　　【驗收報告應由客戶方起草，雙方有關人員簽字，此時驗收報告的格式主要由客戶方選定;當然，也可接受用戶方委托，由項目經理起草驗收報告，經用戶方簽字蓋章認可。】

　　第一章 項目概述

　　1.1 項目背景

　　目前，電視臺除了自制節目以外，外購節目制度存在非常明顯的潛規則、暗箱操作、圈子交易等現象，一個公平、公正、公開、透明的節目采購方式呼之欲出。

　　各省級衛視也有自己的采購方式。如江蘇廣播電視總臺電視節目采購工作按照民主集中制的原則開展，實行四級審片制，即采購人員初審、審片組審片、分管主任復審、主任審看。另外還有送頻道或者召開觀眾審片會議復審。對審片評價較好的劇目進行外地播出效果評估，最后形成劇目的總體評價，對有爭議的劇目報總臺分管領導仲裁。所有外購節目采購在部門民主集中形成意見后報總臺領導批準購買。廣州電視臺除新聞節目外，所有頻道、節目將全面實行制播分離，所屬九個頻道向臺內外制作機構開放，建立起多主體、多渠道采購節目，擇優播出機制。

　　面對激烈的市場競爭和不規范的市場原則，省級衛視為了搶占市場先機，降低采購成本，采取聯合采購的模式。如2+4模式：東方衛視和北京衛視購買了《馬文的戰爭》的首輪播出權后，二輪播權由山東、天津、吉林和深圳4家衛視采購。還有《我的團長我的團》、《潛伏》、《婚變》等電視劇被適用于4+4模式。另外，目前的電視劇爭奪戰中還出現了“劇本期貨”交易現象——在劇本出來之后，只要有足夠的賣點和看點，電視臺就會采取前期介入，迅速獲得優勢資源。

　　另一方面，由于電視劇買賣的圈子很小，電視臺和制作機構之間的買賣屬于圈子交易。每年60億元的購片經費中，大部分都集中在幾十個電視臺采購負責人手中。很多情況下，電視臺的節目采購很大程度上受到采購者的個人因素影響，如與節目制作機構的人際關系，個人的喜好或者審美習慣等等。這樣就無法保證把經費用在刀刃上，既浪費了資源，又沒有買到好的節目。

　　各家電視臺都出臺了各種采購形式，但電視臺的節目采購形式都沒有在業界形成

　　項目名稱

　　公信度和絕對優勢，因為沒有一個切實有效的部門(崗位)來統籌規范電視節目的引進工作，這就非常有必要增設采購編輯來改變這一現狀。

　　1.2 參考資料

　　編寫本驗收報告時主要參考了如下的資料和文獻：

　　1.

　　2.

　　3.

　　4.

　　5.

　　6. 《華夏影視交易平臺系統合同書(主合同)》 《華夏影視交易平臺系統軟件開發合同書》 《華夏影視交易平臺系統需求分析說明書》 《華夏影視交易平臺系統總體設計說明書》 《華夏影視交易平臺系統詳細設計說明書》 《應達到的技術指標和參數(驗收標準)》

　　第二章 驗收定義

　　2.1 驗收方式

　　組織匯報、功能代碼審查

　　2.2 驗收依據

　　《華夏影視交易平臺系統合同書(主合同)》

　　《華夏影視交易平臺系統軟件開發合同書》

　　《附件五 華夏影視交易平臺系統工作說明書》

　　2.3 驗收環境

　　華夏影視交易平臺X綜合業務系統實際運行的生產環境為驗收環境。

　　 硬件平臺

　　服務器：AS/400-840系列;RS/6000-H85

　　客戶機：IBM_PC、實達、國光、長城系列終端及終端外圍設備。

　　 軟件平臺

　　項目名稱

　　服務器：OS/400 Ver5.1 AIX 4.3.3操作系統，DB2 數據庫 Ver 7.2.0;

　　客戶機：SCO UNIX操作系統3.24及5.01, INFORMIX ONLINE 數據庫 Ver 7.3

　　2.4 驗收標準

　　2.4.1 系統功能標準

　　如果各模塊驗收測試結果如下表所述則視為驗收合格，否則將進行修改，以進行再次驗收評審。

　　2.4.2 性能標準

　　1.優秀

　　1)材料完整

　　2)軟件可正常運行

　　3)實現項目軟件需求說明書要求的各項功能需求

　　4)軟件界面友好，易于交互

　　5)軟件功能新穎，有較強創新

　　2.合格

　　1)本標準第3條要求的材料完整

　　2)可正常運行實現功能達到軟件需求說明書要求的三分之二以上 3.不合格

　　1)標準第3條要求的材料不完整 2)軟件不能運行

　　3) 軟件需求說明書要求的主要功能 。

　　2.5 驗收規則

　　驗收規則一：【避免在法度中應用魔鬼數字，必須用有意義的常量來標識。】

　　驗收規則二：【明白辦法的功能，一個辦法僅完成一個功能。】

　　驗收規則三：【辦法參數不克不及跨越5個】

　　驗收規則四：【辦法調用盡量不要返回null，取而代之以拋出異常，或是返回特例對象(SPECIAL CASE object，SPECIAL CASE PATTERN);對于以湊集或數組類型作為返回值的辦法，取而代之以空湊集或0長度數組。】

　　驗收規則五：【在進行數據庫操縱或IO操縱時，必須確保資料在應用完畢后獲得開釋，并且必須確保開釋操縱在finally中進行。】

　　驗收規則六：【異常捕獲不要直接catch (Exception ex) ，應當把異常細分處理懲罰。】

　　驗收規則七：【對于if „ else if „(后續可能有多個else if …)這種類型的前提斷定，最后必須包含一個else分支，避免呈現分支漏掉造成錯誤;每個switch-case語句都必須包管有default，避免呈現分支漏掉，造成錯誤。】

　　驗收規則八：【覆寫對象的equals辦法時必須同時覆寫hashCode辦法。】

　　驗收規則九：【禁止輪回中創建新線程，盡量應用線程池。】

　　驗收規則十：【在進行正確策畫時(例如:貨幣策畫)避免應用float和double，浮點數策畫都是不正確的，必須應用BigDecimal或將浮點數運算轉換為整型運算。】

　　2.6 驗收人員

　　2.7 驗收時間

　　第三章 遺留問題

　　暫無。

　　第四章 交付物清單

　　4.1 文檔提交清單

　　4.2 源碼提交清單

　　第五章 驗收結論

　　第一版驗收通過

　　第六章 雙方簽字

　　客戶方(蓋章)： 代表：

　　公司(蓋章) 代表： 日期：

　　日期：

　　第三方((蓋章)[如果有]： 代表： 日期：

　　附件:

　　驗收測試記錄、測試報告等記錄。

軟件驗收報告 篇2

　　甲方： 有限公司

　　乙方： 有限公司

　　甲方收到乙方開發的)，下文簡稱“軟件”。截止于 年 月 日初步測試已經通過，暫時無發現重大軟件漏洞問題，軟件細節后期有待驗證。

　　乙方應在甲方實際使用軟件過程中，對軟件已有功能做售后服務。如后期有軟件漏洞問題，乙方應積極配合甲方做免費修復。

　　甲方驗收人員： 日期：

　　甲方驗收人員： 日期：

軟件驗收報告 篇3

　　甲方：

　　乙方：

　　就“ ，經過甲乙雙方的通力配合和共同努力，完成了合同中約定的全部任務，現在整個系統運行正常，按照合同約定，進行項目驗收工作。

　　驗收工作分為設備清點、安裝調試、初驗、上線試運行和終驗幾個階段，驗收方式主要以清單、測試和實地操作為主。具體內容如下： 第一部分：設備清點

　　主要檢查運到甲方的設備是否與合同相符

　　甲乙雙方按照合同要求對運抵現場的設備進行了清點，此項工作已于 年 月 日完成，結論如下：

　　1.1 核對到貨清單，實物與運送單據是否一致。

　　□通過 □未通過 備注：

　　1.2 檢查和清點運抵現場的各種設備是否與合同相符。

　　□通過 □未通過 備注：

　　1.3 檢查運抵現場的文檔是否齊全

　　□通過 □未通過 備注：

　　第二部分：安裝調試

　　通過系統硬件測試證明各部分硬件物理破壞且已正確安裝。

　　按照合同要求，乙方對已經到貨的設備進行了安裝，甲乙雙方進行了加電測試，主要觀察設備加電后的表現和運行自檢程序的結果，此項工作已于 年 月 日完成，結論如下：

　　2.1 加電是否成功

　　□通過 □未通過 備注：

　　2.2 設備狀態是否正常

　　□通過 □未通過 備注：

　　2.3 系統顯示的版本和序列號等信息是否符合合同要求

　　□通過 □未通過 備注：

　　2.4 自檢有無報警

　　□通過 □未通過 備注：

　　第三部分：初驗、上線試運行

　　通過系統運行，證明系統可以正常工作

　　乙方進行設備安裝調試后，甲乙雙方在操作系統、數據庫等運行環境下進行系統測試，此項工作已于 年 月 日完成，結論如下：

　　3.1 系統啟動是否正常

　　□通過 □未通過 □未涉及 備注：

　　3.2 系統管理功能是否正常

　　□通過 □未通過 □未涉及 備注：

　　3.3 相關軟件License是否已經生效使用

　　□通過 □未通過 □未涉及 備注：

　　3.4系統運行是否正常

　　□通過 □未通過 □未涉及 備注：

　　第四部分 終驗

　　系統和設備在質保期內能正常運轉，出現故障，能及時解決。

　　乙方在質保期內對系統和設備進行了終驗驗收，此項工作已于 年 月 日完成，結論如下：

　　□通過 □未通過 □未涉及 備注：

　　完成上述工作以后，甲乙雙方認為整個項目驗收正式通過，整個系統交付完畢，設備運行正常，可以投入使用。

　　甲方： 乙方：

　　代表 代表

　　日期 日期

軟件驗收報告 篇4

　　課程名稱：

　　實驗項目：

　　實驗地點：

　　專業班級：

　　學生姓名：

　　指導教師：

　　本科實驗報告 軟件工程 學校內部工資管理系統 綜合樓506室 計Z1102 學號： 寧高琴 崔冬華 20xx年 9 月23 日

　　學校內部工資管理系統設計說明書

　　1.引言

　　1.1系統簡介

　　假設學校共有教職工約1000人，10個行政部門和8個系部。每個月20日前各部門(包括系、部)要將出勤情況上報人事處，23日前人事處將出勤工資、獎金及扣款清單送財務處。財務處于每月月底將教職工的工資表做好并將數據送銀行。每月初(3日前)將工資條發給各單位。若有員工調入、調出、校內調動、離退休等數據變化，則由人事處通知相關部門和財務處。

　　一.系統可行性研究

　　主要功能：月工資發放和處理、標準工資庫維護、臨時工資發放、查詢與系統維護和系統幫助。用戶可以查詢每月工資獎金發放扣除等詳細細節變化狀況。性能要求：方便、快捷、有效地完成工資發放的各項任務,在工資數據統計和報表打印等方面,具有準確率高、速度快等特點。系統的輸入 輸入所有職工的標識,如職工的姓名、工號、所在部門、各項應發的金額和各項應扣的金額。

　　系統的輸出 輸出各種報表、上報的文件和上報的磁盤。

　　安全與保密要求：本系統在使用前必須正確輸入密碼,否則系統將不能運行。進入系統后,要想修改密碼或對系統的一些信息進行修改,也必須輸入高級用戶密碼,對數據庫中的關鍵數據應該要求保密。服務器的管理員享有對工資數據信息庫的管理與修改。用戶只享有對信息的查詢和部分信息修改(如個人信息)。

　　完成期限：預計六個月。

　　開發目標:本系統開發目標應該考慮到以下幾個方面的因素:人力與設備費用的相對減少;數 據處理速度的提高;數據統計精度的和準確率的提高。管理信息服務的改進;自動決策系統的改進;人員利用率的改進。

　　2.3可行性研究的方法

　　(1)客戶調查：通過對客戶調查,了解和認知客戶對軟件產品的需求,按照客戶的要求不僅要實現月工資發放,而且要實現臨時的工資發放,同時還要有數據庫備份。GZGL系統的主要功能為:月工資發放和處理、標準工資庫維護、臨時工資發放、查詢與系統維護和系統幫助。

　　(2)同類產品調查：通過對市場中相關或同類產品的調查,筆者了解到,工資管理系統大體上都應該實現工資的統計、匯總、報表打印等功能。

　　三 技術可行性

　　1.簡要描述

　　工資管理系統采用常規的數據庫處理方法,根據工資信息管理的特點對數據庫進行操作,如對工資發放項目的修改、人員的增刪、工資數據的添加和修改、工資的統計、工資的匯總、臨時發放工資的管理、上報文件和磁盤、打印等給予了優化。

　　2.與現有系統的優越性比較

　　工資管理系統有利于工資發放的統一、有效管理。與傳統的手工記賬方式相比,占據空間小、易于統計工資總額、易于更新、易于數據備份;與其它工資系統相比,該系統實現了對不同類型職工的工資發放,系統功能比較全面,而且價格也比較合理。

　　工資管理系統具有高效率的系統靈活性。當修改工資庫中某個職工的工資情況或者修改某個工資發放項目時,只需在工資數據編輯狀態下對該職工的工號進行鎖定,或者對某個工資項目進行鎖定,即可對鎖定的項目進行修改,而對其它的人員或項目無權修改,這樣可以提高系統的準確性。

　　工資管理系統能夠較好保證數據庫的安全。用戶可以對后臺數據庫進行加密,同時還可以給系統設定密碼。

　　四 經濟可行性

　　1.支出

　　(1)基本投資。硬件設備:PC機;軟件:Windows98/Windows20xx/xp/7,Delphi 7,sql 20xx/20xx;

　　(2)其他一次性支出,主要是軟件設計和開發費用。軟件設計開發過程當中,投入設計和開發費用包括:購買書籍的資金500元;正版dephi7安裝盤50元;需求分析的費用為3300元(其中包含技術開發上的花銷、生活花銷等)。以上的費用共計4000元。

　　(3)經常性支出,主要是軟件后期維護費用。軟件開發完畢后投入使用時,對軟件產品進行的后期軟件維護所需要支出的費用。

　　2.效益

　　本系統的應用進一步實現辦公自動化,減少了人力投資和辦公費用的開銷,極大地提高辦公效率。投入使用將獲得的經濟效益分為直接效益和間接效益兩方面。直接效益主要體現在:原來4人/周工作量將只須1人/周完成;間接效益體現在:減少支付3人工資(1200元/人月),共計3600元/月。

　　3.投資回收周期

　　根據經驗的算法,當收益的累計數開始超出支出的累計數的時候,就是投資 的回收期。

　　投資回收期:4000元/(3600元/月)=1.11月(因軟件未交付使用,故未將軟件的

　　后期維護費用計入)。

　　五 法律方面的可行性

　　系統的研制和開發,將不會侵犯他人、集體和國家的利益,不會違反國家政策和法律。

　　法律因素

　　所有軟件都選用正版.

　　所有技術資料都由提出方保管。

　　合同制定確定違約責任.

　　六 使用方面的可行性

　　系統的研制和開發充分考慮到用戶的工資發放策略、管理流程和操作人員的素質等因素,可以滿足用戶的使用要求。

　　用戶使用可行性

　　使用本軟件人員要求有一定計算機基礎的人員,系統管理員要求由計算機的專業知識,所有人員都要經過本公司培訓.

　　管理人員也需經一般培訓.

　　經過培訓人員將會熟練使用本軟件.

　　兩名系統管理員,一名審計員將進行專業培訓,他們將熟練管理本系統.

　　本系統定位于各高校，也可以適用于各中小型企業。運用此系統進行工資管理，給各院校教職工帶來極大的方便。

　　作為本產品的使用者要求有一定的計算機基礎，可以熟練得使用window操作系統所提的各種功能。

　　數據庫管理要求具有專業水平的數據庫管理員，而且要經過我們的專門培訓。

　　我們會在售出后長期提供軟件維護免費服務，以便用戶在軟件使用中出現的問題

　　新系統的研制和開發是充分得考慮工作人員對工資的易于管理，管理者方便查詢職工的個人基本信息效率。從而能完全滿足使用者的要求。如今的互聯網已經走進千家萬戶，連小學生都會上網了，我的系統是利用微軟自帶的IE瀏覽器作為客戶端平臺，只要上過網的朋友就很方便操作，而且本系統有友好的用戶界面、有良好的安全性設置、有詳細的操作說明書，這樣更使各類用戶很快地掌握系統的使用方法。

　　1.2 定義

　　專門術語：職工基本信息表(Basic)

　　職工出缺勤信息表(Attendance )

　　職工工資信息表(Salaries)

　　2.總體設計

　　3.2.1需求概述

　　本軟件的主要服務對象是太原理工大學的財務處和人事處，各系部。

　　各系部的主要任務是在每個月20日前各部門(包括系、部)要將出勤情況上報人事處(各系部在這里的主要任務是提供數據的輸入);

　　而人事處將出勤工資、獎金及扣款清單送財務處(人事處在這里對各系部送來的數據進行分析處理，對應得出數據的處理結果;

　　財務處于每月月底將教職工的工資表做好并將數據送銀行，每月初(3日前)將工資條發給各單位，(財務處在這里對數據起一個網關過濾的作用，主要起一個審批作用，負責接受成型的工資數據和審批然后向銀行提交成型數據，最后打到發放工資的目的。

　　另外，人事變動的數據是由人事處接受并修改，最后同意傳達給財務處和相關部門。

　　2.2軟件結構

　　則根據需求分析和概要設計得出軟件的功能結構模塊圖

　　2.3數據庫設計

　　數據庫表設計

　　職工基本信息表

　　職工出缺勤信息表

　　職工工資信息表

　　2.4 對應的數據字典與E-R圖：

　　1靜態數據：職工基本信息，職工出缺勤信息

　　.2動態數據

　　輸入數據：職工基本信息，職工工資信息，出勤工資，獎金，扣款清單，職工出缺勤信息;輸出數據：職工基本信息，職工工資信息，職工標準工資信息，職工工資條，職工出缺勤報表

　　.3數據庫介紹

　　職工基本信息數據庫：包括職工的工號，姓名，所屬系別，職位職工出缺勤信息數據庫：包括職工的工號，姓名，應出勤次數/月，實際出勤次數/月，缺勤次數，缺勤原因;職工工資信息數據庫：包括職工的工號，姓名，基本工資，原始獎金，缺勤金，實際工資;

　　則得DFD如下：

　　4數據詞典：

　　數據項：

　　數據項名:工號

　　別名:TNo,

　　簡述:所有職工的編號

　　類型:CHAR

　　長度：10

　　取值范圍及含義:

　　第1位：3 (代表安工科) 第2∼3位：0X (入學校年份) 第4-5位： ( 所屬系部) 第5-10位:( 所在系部內的編號)

　　數據項名:姓名

　　別名:NAME

　　簡述:所有職工的姓名

　　類型:CHAR

　　長度：8

　　取值范圍及含義:

　　第1-8位：(姓名,2~4字)

　　數據項名:所屬系別

　　別名:DEPARTMENTS

　　簡述:職工所屬的部門

　　類型:CHAR

　　長度：20

　　取值范圍及含義: 具體的部門名稱

　　數據項名:職位

　　別名:JOBS

　　簡述:職工所在該部門的具體職位 類型:CHAR

　　長度：20

　　取值范圍及含義: 具體的職位名稱

　　數據項名: 應出勤次數/月

　　別名:SHOULD

　　簡述:按工作表每個月應出勤的次數 類型:INT

　　長度：2

　　取值范圍及含義:次數

　　數據項名: 實際出勤次數/月

　　別名:ACTUAL

　　簡述:實際每個月應出勤的次數

　　類型:INT

　　長度：2

　　取值范圍及含義:次數

　　數據項名: 缺勤次數

　　別名:MISSNUM

　　簡述:每個月應缺勤的次數

　　類型:INT

　　長度：2

　　取值范圍及含義:次數

　　數據項名: 缺勤原因

　　別名:REASON

　　簡述:缺勤的具體原因

　　類型:CHAR

　　長度：50

　　取值范圍及含義:缺勤的大致原因

　　數據項名: 基本工資

　　別名:JIBENGONGZI

　　簡述:由工齡和職位規定的基本工資 類型:INT

　　數據存儲:

　　缺勤原因

　　長度：5 取值范圍及含義:金額數目 數據項名: 原始獎金 別名:YUANSHIJIANGJIN 簡述：由工齡和職位規定的原始獎金 類型:INT 長度：5 取值范圍及含義: :金額數目 數據項名:缺勤金 別名：QUEQINJIN 簡述:由缺勤次數所得的應扣金額數目 類型:INT 長度：5 取值范圍及含義:金額數目 數據項名:實際工資 別名：SHIJIGONGZI 簡述：每月實際得到的工資數金額數目 類型:INT 長度：5 取值范圍及含義:金額數目 文件名: 職工基本信息數據庫 別名: 基本信息表 簡述: 存放職工基本信息 組成：包括職工的工號+姓名+所屬系別+職位 組織方式：索引文件，以工號為關鍵字 查詢要求: 要求能夠立即查詢 文件名: 職工出缺勤信息數據庫 別名: 出缺勤信息表 簡述: 存放職工基本信息 組成：工號+姓名+應出勤次數/月+實際出勤次數/月+缺勤次數+組織方式：索引文件，以工號為關鍵字 查詢要求: 要求能夠立即查詢 文件名: 職工工資信息數據庫 別名: 工資信息表 簡述: 存放職工工資信息 組成：工號+姓名+基本工資+原始獎金+缺勤金+實際工資

　　組織方式：索引文件，以工號為關鍵字

　　查詢要求: 要求能夠立即查詢

　　數據流:

　　數據流名:職工基本信息

　　別名: 無

　　簡述: 職工的各項屬性信息

　　來源: 各系部

　　去向: 加工1.1“職工信息的輸入并整理存儲”

　　組成: 工號+姓名+性別+所屬系部+職位

　　數據流量:一般:1次/學期

　　高峰值：職工出現異動1000次/天

　　數據流名:出勤工資,獎金,扣款清單

　　別名: 無

　　簡述: 人事處的對職工出勤信息的整理結果

　　來源: 人事處

　　去向: 加工2.1“職工工資信息生成”

　　組成: 出勤工資+獎金+扣款清單

　　數據流量:一般:1次/月

　　高峰值：1次/月

　　數據流名:職工工資信息

　　別名: 無

　　簡述: 生成的職工工資信息

　　來源: 加工2.1

　　去向: 加工2.2“財務處職工工資信息整理發送”

　　組成: 工號+姓名+基本工資+原始獎金+缺勤金+實際工資

　　數據流量:一般:1次/月

　　高峰值：1次/月

　　數據流名:職工標準工資信息

　　別名: 無

　　簡述: 生成的標準工資信息

　　來源: 加工2.2

　　去向: 銀行

　　組成: 工號+姓名+基本工資+原始獎金+缺勤金+實際工資

　　數據流量:一般:1次/月

　　高峰值：1次/月

　　數據流名:職工工資條

　　別名: 無

　　簡述: 針對系部的工資條

　　來源: 加工2.2

　　去向: 各系部

　　組成: 工號+姓名+基本工資+原始獎金+缺勤金+實際工資

　　數據流量:一般:1次/月

　　高峰值：1次/月

　　E-R圖如下：

　　3.程序描述

　　3.1功能

　　職工基本信息管理子系統：

　　1)職工基本信息輸入：用于采集職工的職工的工號，姓名，所屬系別，職位

　　2)建立職工基本信息表：為三個子系統提供數據源

　　3)職工基本信息查詢：實現查詢功能

　　4)職工基本信息修改：

　　a.寫修改職工基本信息：對職工信息異動進行修改

　　b.發送提示信息至其他部門：將異動報告提交給使用該表的其他部門

　　職工出勤信息管理子系統：

　　數/月，缺勤次數，缺勤原因

　　2)職工出缺勤信息查詢：實現查詢功能

　　3)職工出缺勤信息表的建立：為職工工資管理子系統提供數據源

　　職工工資管理子系統：

　　1)職工基本工資信息讀取：為實際工資獎金計算提供數據源

　　2)職工實際工資獎金計算：得出實際工資

　　3)標準工資信息與銀行之間的雙向傳輸：向銀行提供標準工資信息，銀行提供資金異動信息

　　4)工資條對各部門的發放：向各個部門傳輸標準工資信息

　　3.2性能

　　職工基本信息管理子系統：

　　1)職工基本信息輸入：數據輸入，存儲

　　2)建立職工基本信息表：數據集中

　　3)職工基本信息查詢：數據查詢

　　4)職工基本信息修改：

　　a.寫修改職工基本信息：數據修改

　　b.發送提示信息至其他部門：數據讀出

　　職工出勤信息管理子系統：

　　1)職工出缺勤信息輸入：數據輸入，存儲

　　2)職工出缺勤信息查詢：數據查詢

　　3)職工出缺勤信息表的建立：數據集中

　　職工工資管理子系統：

　　1)職工基本工資信息讀取：數據讀出

　　2)職工實際工資獎金計算：數據加工

　　3)標準工資信息與銀行之間的雙向傳輸：數據讀出，輸入

　　4)工資條對各部門的發放：數據讀出

　　3.3輸入項目

　　職工基本信息管理子系統：

　　1)職工基本信息輸入：職工的工號，姓名，所屬系別，職位

　　2)建立職工基本信息表：無

　　3)職工基本信息查詢：存儲在表中的任一數據

　　4)職工基本信息修改：

　　a.寫修改職工基本信息：新數據(職工基本信息)

　　b.發送提示信息至其他部門：異動提示報告職工出勤信息管理子系統：/月，缺勤次數，缺勤原因

　　2)職工出缺勤信息查詢：存儲在表中的任一數據

　　3)職工出缺勤信息表的建立：

　　無職工工資管理子系統：

　　1)職工基本工資信息讀取：職工的工號，姓名，基本工資，原始獎金，缺勤金，實際工資

　　2)職工實際工資獎金計算：職工出缺勤信息，職工基本工資信息

　　3)標準工資信息與銀行之間的雙向傳輸：標準工資信息

　　4)工資條對各部門的發放：標準工資信息

　　3.4輸出項目

　　職工基本信息管理子系統：

　　1)職工基本信息輸入：職工基本信息表

　　2)建立職工基本信息表：職工基本信息表

　　3)職工基本信息查詢：查詢目標

　　4)職工基本信息修改：

　　a.寫修改職工基本信息：新數據(職工基本信息)

　　b.發送提示信息至其他部門：異動提示報告

　　職工出勤信息管理子系統：

　　1)職工出缺勤信息輸入：職工出缺勤信息表

　　2)職工出缺勤信息查詢：查詢目標

　　3)職工出缺勤信息表的建立：職工出缺勤信息表

　　職工工資管理子系統：

　　1)職工基本工資信息讀取：職工基本工資信息表

　　2)職工實際工資獎金計算：標準工資信息

　　3)標準工資信息與銀行之間的雙向傳輸：標準工資信息

　　4)工資條對各部門的發放：標準工資信息

　　3.6詳細設計

　　則根據需求分析，功能模塊分析可得程序的流程圖為

　　3.7測試要點

　　對于職工基本信息模塊：測試的要點是針對職工基本信息屬性的添加，查詢，修改，刪除，以及對數據庫的同步更新

　　對于職工出缺勤模塊：測試的要點是針對職工出缺勤信息的添加，查詢，修改，刪除，對數據庫的同步更新，以及對缺勤次數的觸發器的運算職工工資信息表：測試的要點是針對職工工資信息的添加，查詢，修改，刪除，對數據庫的同步更新，以及對缺勤金和實際工資的運算

　　5.功能模塊的測試

　　選取職工出缺勤信息管理進行操作。

　　1.首先，添加職工的基本信息：

　　工號：3040766666

　　姓名：張三

　　應出勤：30

　　實出勤：25

　　在相應的EDIT框中添加進入此類信息，點擊保存。

　　在職工出缺勤管理界面進行瀏覽操作，發現信息已經成功保存，并可以瀏覽到。

　　2.錯誤測試：同樣輸入一組值。其值完全同上，唯一區別的是不對工號的內容不輸入，其他都輸入。然后點擊保存。發現系統提示出錯信息，無法成功保存信息。原因分析：對于設為主鍵的屬性值，在數據庫表中是不可以為空的。在添加信息中，注意不能缺少對主鍵的設置。

　　3.對于數據庫的檢查：對于數據庫中的表的一些屬性值，比如缺勤次數，是采取觸發器進行輸入的。在每輸入一組應“出勤次數/月“和 “實出勤次數/月”，對應的屬性缺勤次數將得到更新。在數據庫表中檢查并得到驗證。

軟件驗收報告 篇5

　　一、項目基本信息

　　二、驗收目的

　　目的在于對項目進行全方位的檢驗與測評，檢驗乙方提供的軟件系統是否遵循軟件開發標準的要求，檢驗各項指標與功能是否與合同要求相吻合。

　　三、驗收范圍

　　驗收范圍以雙方簽訂的技術開發合同所描述的內容為準。具體如下：

　　1、項目技術目標________系統可支持4個人工座席客戶端，實現_____功能。 2、項目技術內容

　　(1)、研究設計_______系統，系統可支持4個人工座席客戶端;實現。。。。;

　　(2)、硬件平臺建設:包括研華工控機 1套;客戶端主機DELL臺式機10套，DELL筆記本3套;三匯語音卡1套;SONY DSLR-A230L數碼相機1套;D-Link 24口 網絡交換機1套。

　　項目于20__年11月開始組織建設，在甲乙雙方密切配合下，項目進展順利，乙方按合同完成了___硬件平臺建設、軟件系統平臺開發、數據庫建設、系統培訓、技術支持等工作，系統于20__年12月正式投入使用，系統正常運行。

　　四、項目驗收表