課程名稱：
實驗專案：
實驗地點：
專業班級：
學生姓名：
指導教師：
本科實驗報告 軟體工程 學校內部工資管理系統 綜合樓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.對於資料庫的檢查：對於資料庫中的表的一些屬性值，比如缺勤次數，是採取觸發器進行輸入的。在每輸入一組應“出勤次數/月“和 “實出勤次數/月”，對應的屬性缺勤次數將得到更新。在資料庫表中檢查並得到驗證。
一、專案基本資訊
二、驗收目的
目的在於對專案進行全方位的檢驗與測評，檢驗乙方提供的軟體系統是否遵循軟體開發標準的要求，檢驗各項指標與功能是否與合同要求相吻合。
三、驗收範圍
驗收範圍以雙方簽訂的技術開發合同所描述的內容為準。具體如下：
1、專案技術目標系統可支援4個人工座席客戶端，實現功能。 2、專案技術內容
(1)、研究設計系統，系統可支援4個人工座席客戶端;實現。。。。;
(2)、硬體平臺建設:包括研華工控機 1套;客戶端主機DELL桌上型電腦10套，DELL筆記本3套;三匯語音卡1套;SONY DSLR-A230L數碼相機1套;D-Link 24口 網路交換機1套。
專案於20xx年11月開始組織建設，在甲乙雙方密切配合下，專案進展順利，乙方按合同完成了硬體平臺建設、軟體系統平臺開發、資料庫建設、系統培訓、技術支援等工作，系統於20xx年12月正式投入使用，系統正常執行。
四、專案驗收表
驗收單位(簽章)：
一、專案基本資訊
二、驗收目的
目的在於對專案進行全方位的檢驗與測評，檢驗乙方提供的軟體系統是否遵循軟體開發標準的要求，檢驗各項指標與功能是否與合同要求相吻合。
三、驗收範圍
驗收範圍以雙方簽訂的技術開發合同所描述的內容為準。具體如下：
1、專案技術目標________系統可支援4個人工座席客戶端，實現_____功能。 2、專案技術內容
(1)、研究設計_______系統，系統可支援4個人工座席客戶端;實現。。。。;
(2)、硬體平臺建設:包括研華工控機 1套;客戶端主機DELL桌上型電腦10套，DELL筆記本3套;三匯語音卡1套;SONY DSLR-A230L數碼相機1套;D-Link 24口 網路交換機1套。
專案於20__年11月開始組織建設，在甲乙雙方密切配合下，專案進展順利，乙方按合同完成了___硬體平臺建設、軟體系統平臺開發、資料庫建設、系統培訓、技術支援等工作，系統於20__年12月正式投入使用，系統正常執行。
四、專案驗收表
目前，國內軟體的驗收沒有可參照的強制性標準，就軟體測試和評價來說，參照的標準是GB/T 17544 和GB/T 16260，它們都是推薦性標準，且都是定性而非定量的標準，這樣，對於軟體的驗收來說，存在很大的分歧和不確定性。為此，我們在參考了大量的實踐案例和文獻的基礎上，結合本校實際制定本驗收辦法，用於規範本校軟體系統驗收。
軟體系統的驗收可通過本校組織驗收或通過第三方驗收兩種辦法。 1、驗收原則
驗收參與部門：資產管理處、紀檢監察、使用者使用單位、專家小組或第三方驗收人員;開發單位。
在軟體開發合同的簽訂階段就提出軟體驗收專案和驗收通過標準的意見;在軟體的需求評審階段，仔細審閱軟體的需求規格說明書，指出不利於測試和可能存在歧義的描述;在開發方開發完軟體並經過開發方內部仔細的測試後，對完成的軟體進行評審或第三方的驗收測試，提供完整的錯誤報告提交給使用者方，由使用者方根據之前簽訂的開發合同中相應的驗收標準判斷是否進行驗收。
2、驗收專案和驗收標準 2.1 驗收專案 a) 功能項測試
對軟體需求規格說明書中的所有功能項進行測試; b) 業務流程測試
對軟體專案的典型業務流程進行測試; c) 容錯測試
容錯測試的檢查內容包括:
1) 軟體對使用者常見的誤操作是否能進行提示;
2) 軟體對使用者的的操作錯誤和軟體錯誤，是否有準確、清晰的提示; 3) 軟體對重要資料的刪除是否有警告和確認提示;
4) 軟體是否能判斷資料的有效性，遮蔽使用者的錯誤輸入，識別非法值，並有相應的錯誤提示。
d) 安全性測試安全性測試的檢查內容包括:
1) 軟體中的金鑰是否以密文方式儲存;
2) 軟體是否有留痕功能, 即是否儲存有使用者的操作日誌; 3) 軟體中各種使用者的許可權分配是否合理; e) 效能測試
對軟體需求規格說明書中明確的軟體效能進行測試。測試的準則是要滿足規格說明書中的各項效能指標。
f ) 易用性測試 易用性測試的內容包括:
1) 軟體的使用者介面是否友好，是否出現中英文混雜的介面; 2) 軟體中的提示資訊是否清楚、易理解，是否存在原始的英文提示; 3) 軟體中各個模組的介面風格是否一致;
4) 軟體中的查詢結果的輸出方式是否比較直觀、合理。 g) 適應性測試
參照使用者的軟、硬體使用環境和需求規格說明書中的規定，列出開發的軟體需要滿足的軟、硬體環境。對每個環境進行測試。
h) 文件測試
使用者文件包括: 安裝手冊、操作手冊和維護手冊。對使用者文件測試的內容包括: 1) 操作、維護文件是否齊全、是否包含產品使用所需的資訊和所有的功能模組; 2) 使用者文件描述的資訊是否正確, 是否沒有歧義和錯誤的表達;
3) 戶文件是否容易理解, 是否通過使用適當的術語、圖形表示、詳細的解釋來表達;
4) 使用者文件對主要功能和關鍵操作是否提供應用例項; 5) 使用者文件是否有詳細的目錄表和索引表; i)
使用者有特別要求的測試
2.2 驗收標準
2.2.1 軟體錯誤的嚴重性等級
1：不能執行正常功能或重要功能, 或者危及人身安全; 2：嚴重地影響系統要求或基本功能的實現, 且沒有辦法解決; 3：嚴重地影響系統要求或基本功能的實現, 但存在合理的解決辦法; 4：使操作者不方便或遇到麻煩, 但不影響執行正常功能或重要功能; 5 ：其它錯誤;
2.2.2錯誤與嚴重性等級對應表 a) 1 級錯誤的描述
這一級別的錯誤一般包括以下內容: 沒有實現或錯誤地實現重要的功能;業務流程存在重大隱患;軟體在操作過程中由於軟體自身的原因自動退出系統或出現宕機的情況;軟體在操作過程中由於軟體自身的原因對系統或資料造成破壞;在現有的軟、硬建設環境下不能實現應有的功能;特殊軟體在操作過程中可能危及系統和人身安全等。
b) 2 級錯誤的描述
這一級別的錯誤一般包括: 沒有實現基本功能，並且不存在替代辦法;沒有實現重要功能中的部分功能，並且不存在替代辦法;業務流程銜接錯誤;金鑰以明文方式儲存;沒有留痕功能;使用者的許可權分配不合理;在現有的環境下，不能實現部分功能且沒有替代方案;沒有滿足系統的效能要求。
c) 3 級錯誤的描述
這一級的錯誤是與第2 級別的錯誤相對應的，而第3 級錯誤則存在替代方法;對誤操作或錯誤操作沒有提示，導致非法資料進入資料庫。
d) 4 級錯誤的描述
這一級別的錯誤通常為易用性方面的錯誤。比如介面不友好、前後風格不一;中英文混雜;查詢結果輸出不直觀等。
e) 5 級錯誤的描述
通常為文件方面的錯誤，如安裝手冊、操作手冊、維護手冊中的描述錯誤。 其次，對發現的每一個錯誤都要確定相應的嚴重性等級，如表2 中的說明。
全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，使用者方認為軟體不可驗收，要求開發方在規定的時間內全面整改軟體, 提交給軟體評測中心再次進行完整的驗收測試。
2.2.2 驗收標準
1) 測試用例不通過數的比例< 1.5 %; 2) 不存在錯誤等級為1 的錯誤; 3) 不存在錯誤等級為2 的錯誤; 4) 錯誤等級為3 的錯誤數量≤ 5; 5) 所有提交的錯誤都已得到更正; 2.3 驗收標準的詳細說明
驗收專案的劃分參照GB/T 16260 標準。在該標準中，將軟體的質量特性分為6 大特性、21 個子特性，而對於具體的軟體，並非都要進行這21 個特性的測試和評價。本文選取的是最通用的子特性部分，針對各種不同的軟體，可以對驗收專案進行剪裁或擴充。
需要制定的驗收標準，即每一級別的錯誤量的可接受範圍。一般來說，不允許存在1 級和2級錯誤，而3 級錯誤的數量則可按本標準確定或由使用者方和開發方根據軟體的規模和複雜程度進行商定，並在軟體開發合同中明確地列出。
在軟體驗收測試中， 測試的依據包括軟體的投標檔案、開發合同、需求規格說明書, 同時還包括特定軟體的相關行業標準(這些行業標準應在開發合同中明示出來)。
在進行第三方的驗收測試後，軟體評測中心將發現的所有錯誤進行總結和歸納， 並提交完整的錯誤報告，在錯誤報告中包括每一級別的錯誤數量和錯誤清單(所有的錯誤都需經過使用者方和開發方的確認)。
使用者方根據錯誤報告中每一級別的錯誤數量和錯誤清單與軟體開發合同中的驗收標準進行對照，如錯誤的級別和數量在合同中沒有約定，可按本辦法的規定進行。使用者方認為軟體可以驗收，但要求開發方對錯誤報告中的所有錯誤進行整改，並提交給軟體評測中心進行迴歸測試，確認錯誤報告中的所有錯誤全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，使用者方認為軟體不可驗收，要求開發方在
規定的時間內全面整改軟體，提交給軟體評測中心再次進行完整的驗收測試。
3、驗收資料
(1)工程立項批准檔案 (2)專案驗收申請報告; (3)工程招標書 (4)工程投標書 (5)工程施工中標通知書 (6)工程施工合同(含預算表) (7)軟體需求說明書; (8)概要設計說明書;
(9)資料及資料庫設計要求說明書; (10)詳細設計說明書; (11)操作手冊; (12)使用者手冊
(13)專案使用者評價過程意見; (14)軟體介面規範; (15)原始碼或安裝盤; (16)專家組要求的其他材料 4、其他
在有條件的情況下，還應該進行安裝測試、壓力測試和資料恢復測試。若進行子系統驗收或部分驗收，可參照以上方法和資料，雙方共同協商確定。
參考文獻：
GB/T 17544 ;GB/T 16260;《軟體驗收標準探討》
{專案名稱}
驗收報告
{日期}
目 錄
§1 專案基本情況.................................................... §2 專案進度稽核.................................................... 2.1 專案實施進度情況 2.2 專案變更情況 2.3 專案投資結算情況
§3 專案驗收計劃.................................................... 3.1 專案驗收原則 3.2 專案驗收方式 3.3 專案驗收內容
§4 專案驗收情況彙總................................................ 4.1 專案驗收情況彙總表 4.2 專案驗收附件明細 4.3 專家組驗收意見
§5 專案驗收結論.................................................... 5.1 開發單位結論 5.2 建設單位結論
§6 附件............................................................ 6.1 附件一：軟體平臺驗收單 6.2 附件二：功能模組驗收單 6.3 附件三：專案文件驗收單 6.4 附件四：硬體裝置驗收單
§1 專案基本情況
§2 專案進度稽核2.1 專案實施進度情況
2.2 專案變更情況2.2.1 專案合同變更情況
{記錄合同變更情況}
2.2.2 專案需求變更情況
{記錄需求變更情況}
2.3 專案投資結算情況
§3 專案驗收計劃3.1 專案驗收原則
1、審查提供驗收的各類文件的正確性、完整性和統一性，審查文件是否齊全、合理; 2、審查專案功能是否達到了合同規定的要求; 3、審查專案有關服務指標是否達到了合同的要求; 4、審查專案投資以及實施進度的情況;
5、對專案的技術水平做出評價，並得出項目的驗收結論。
3.2 專案驗收方式
{記錄專案驗收的組織方式和參與驗收工作的人員情況}
3.3 專案驗收內容
1、硬體裝置驗收; 2、軟體平臺驗收; 3、應用系統驗收; 4、專案文件驗收;
5、專案服務響應(如售後服務、問題相應等方面)驗收。
§4 專案驗收情況彙總
4.1 專案驗收情況彙總表
4.2 專案驗收附件明細
1、軟體平臺驗收單(見附件一)。 2、功能模組驗收單(見附件二)。
3、專案文件驗收單(見附件三)。 4、硬體裝置驗收單(見附件四)。
4.3 專家組驗收意見
§5 專案驗收結論5.1 開發單位結論
5.2 建設單位結論
§6 附件6.1 附件一：軟體平臺驗收單
驗收人： 驗收時間：
6.2 附件二：功能模組驗收單
驗收人： 驗收時間：
6.3 附件三：專案文件驗收單
驗收人： 驗收時間：
6.4
附件四：硬體裝置驗收單
驗收人： 驗收時間：
目前，國內軟體的驗收沒有可參照的強制性標準，就軟體測試和評價來說，參照的標準是GB/T 17544 和GB/T 16260，它們都是推薦性標準，且都是定性而非定量的標準，這樣，對於軟體的驗收來說，存在很大的分歧和不確定性。為此，我們在參考了大量的實踐案例和文獻的基礎上，結合本校實際制定本驗收辦法，用於規範本校軟體系統驗收。
軟體系統的驗收可通過本校組織驗收或通過第三方驗收兩種辦法。 1、驗收原則
驗收參與部門：資產管理處、紀檢監察、使用者使用單位、專家小組或第三方驗收人員;開發單位。
在軟體開發合同的簽訂階段就提出軟體驗收專案和驗收通過標準的意見;在軟體的需求評審階段，仔細審閱軟體的需求規格說明書，指出不利於測試和可能存在歧義的描述;在開發方開發完軟體並經過開發方內部仔細的測試後，對完成的軟體進行評審或第三方的驗收測試，提供完整的錯誤報告提交給使用者方，由使用者方根據之前簽訂的開發合同中相應的驗收標準判斷是否進行驗收。
2、驗收專案和驗收標準 2.1 驗收專案 a) 功能項測試
對軟體需求規格說明書中的所有功能項進行測試; b) 業務流程測試
對軟體專案的典型業務流程進行測試; c) 容錯測試
容錯測試的檢查內容包括:
1) 軟體對使用者常見的誤操作是否能進行提示;
2) 軟體對使用者的的操作錯誤和軟體錯誤，是否有準確、清晰的提示; 3) 軟體對重要資料的刪除是否有警告和確認提示;
4) 軟體是否能判斷資料的有效性，遮蔽使用者的錯誤輸入，識別非法值，並有相應的錯誤提示。
d) 安全性測試安全性測試的檢查內容包括:
1) 軟體中的金鑰是否以密文方式儲存;
2) 軟體是否有留痕功能, 即是否儲存有使用者的操作日誌; 3) 軟體中各種使用者的許可權分配是否合理; e) 效能測試
對軟體需求規格說明書中明確的軟體效能進行測試。測試的準則是要滿足規格說明書中的各項效能指標。
f ) 易用性測試 易用性測試的內容包括:
1) 軟體的使用者介面是否友好，是否出現中英文混雜的介面; 2) 軟體中的提示資訊是否清楚、易理解，是否存在原始的英文提示; 3) 軟體中各個模組的介面風格是否一致;
4) 軟體中的查詢結果的輸出方式是否比較直觀、合理。 g) 適應性測試
參照使用者的軟、硬體使用環境和需求規格說明書中的規定，列出開發的軟體需要滿足的軟、硬體環境。對每個環境進行測試。
h) 文件測試
使用者文件包括: 安裝手冊、操作手冊和維護手冊。對使用者文件測試的內容包括: 1) 操作、維護文件是否齊全、是否包含產品使用所需的資訊和所有的功能模組; 2) 使用者文件描述的資訊是否正確, 是否沒有歧義和錯誤的表達;
3) 戶文件是否容易理解, 是否通過使用適當的術語、圖形表示、詳細的解釋來表達;
4) 使用者文件對主要功能和關鍵操作是否提供應用例項; 5) 使用者文件是否有詳細的目錄表和索引表; i)
使用者有特別要求的測試
2.2 驗收標準
2.2.1 軟體錯誤的嚴重性等級
1：不能執行正常功能或重要功能, 或者危及人身安全; 2：嚴重地影響系統要求或基本功能的實現, 且沒有辦法解決; 3：嚴重地影響系統要求或基本功能的實現, 但存在合理的解決辦法; 4：使操作者不方便或遇到麻煩, 但不影響執行正常功能或重要功能; 5 ：其它錯誤;
2.2.2錯誤與嚴重性等級對應表 a) 1 級錯誤的描述
這一級別的錯誤一般包括以下內容: 沒有實現或錯誤地實現重要的功能;業務流程存在重大隱患;軟體在操作過程中由於軟體自身的原因自動退出系統或出現宕機的情況;軟體在操作過程中由於軟體自身的原因對系統或資料造成破壞;在現有的軟、硬建設環境下不能實現應有的功能;特殊軟體在操作過程中可能危及系統和人身安全等。
b) 2 級錯誤的描述
這一級別的錯誤一般包括: 沒有實現基本功能，並且不存在替代辦法;沒有實現重要功能中的部分功能，並且不存在替代辦法;業務流程銜接錯誤;金鑰以明文方式儲存;沒有留痕功能;使用者的許可權分配不合理;在現有的環境下，不能實現部分功能且沒有替代方案;沒有滿足系統的效能要求。
c) 3 級錯誤的描述
這一級的錯誤是與第2 級別的錯誤相對應的，而第3 級錯誤則存在替代方法;對誤操作或錯誤操作沒有提示，導致非法資料進入資料庫。
d) 4 級錯誤的描述
這一級別的錯誤通常為易用性方面的錯誤。比如介面不友好、前後風格不一;中英文混雜;查詢結果輸出不直觀等。
e) 5 級錯誤的描述
通常為文件方面的錯誤，如安裝手冊、操作手冊、維護手冊中的描述錯誤。 其次，對發現的每一個錯誤都要確定相應的嚴重性等級，如表2 中的說明。
全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，使用者方認為軟體不可驗收，要求開發方在規定的時間內全面整改軟體, 提交給軟體評測中心再次進行完整的驗收測試。
2.2.2 驗收標準
1) 測試用例不通過數的比例< 1.5 %; 2) 不存在錯誤等級為1 的錯誤; 3) 不存在錯誤等級為2 的錯誤; 4) 錯誤等級為3 的錯誤數量≤ 5; 5) 所有提交的錯誤都已得到更正; 2.3 驗收標準的詳細說明
驗收專案的劃分參照GB/T 16260 標準。在該標準中，將軟體的質量特性分為6 大特性、21 個子特性，而對於具體的軟體，並非都要進行這21 個特性的測試和評價。本文選取的是最通用的子特性部分，針對各種不同的軟體，可以對驗收專案進行剪裁或擴充。
需要制定的驗收標準，即每一級別的錯誤量的可接受範圍。一般來說，不允許存在1 級和2級錯誤，而3 級錯誤的數量則可按本標準確定或由使用者方和開發方根據軟體的規模和複雜程度進行商定，並在軟體開發合同中明確地列出。
在軟體驗收測試中， 測試的依據包括軟體的投標檔案、開發合同、需求規格說明書, 同時還包括特定軟體的相關行業標準(這些行業標準應在開發合同中明示出來)。
在進行第三方的驗收測試後，軟體評測中心將發現的所有錯誤進行總結和歸納， 並提交完整的錯誤報告，在錯誤報告中包括每一級別的錯誤數量和錯誤清單(所有的錯誤都需經過使用者方和開發方的確認)。
使用者方根據錯誤報告中每一級別的錯誤數量和錯誤清單與軟體開發合同中的驗收標準進行對照，如錯誤的級別和數量在合同中沒有約定，可按本辦法的規定進行。使用者方認為軟體可以驗收，但要求開發方對錯誤報告中的所有錯誤進行整改，並提交給軟體評測中心進行迴歸測試，確認錯誤報告中的所有錯誤全部改正方可;如錯誤的級別和數量在合同可接受的範圍外，使用者方認為軟體不可驗收，要求開發方在
規定的時間內全面整改軟體，提交給軟體評測中心再次進行完整的驗收測試。
3、驗收資料
(1)工程立項批准檔案 (2)專案驗收申請報告; (3)工程招標書 (4)工程投標書 (5)工程施工中標通知書 (6)工程施工合同(含預算表) (7)軟體需求說明書; (8)概要設計說明書;
(9)資料及資料庫設計要求說明書; (10)詳細設計說明書; (11)操作手冊; (12)使用者手冊
(13)專案使用者評價過程意見; (14)軟體介面規範; (15)原始碼或安裝盤; (16)專家組要求的其他材料 4、其他
在有條件的情況下，還應該進行安裝測試、壓力測試和資料恢復測試。若進行子系統驗收或部分驗收，可參照以上方法和資料，雙方共同協商確定。
參考文獻：
GB/T 17544 ;GB/T 16260;《軟體驗收標準探討》
{專案名稱}
驗收報告
{日期}
目 錄
§1 專案基本情況.................................................... §2 專案進度稽核.................................................... 2.1 專案實施進度情況 2.2 專案變更情況 2.3 專案投資結算情況
§3 專案驗收計劃.................................................... 3.1 專案驗收原則 3.2 專案驗收方式 3.3 專案驗收內容
§4 專案驗收情況彙總................................................ 4.1 專案驗收情況彙總表 4.2 專案驗收附件明細 4.3 專家組驗收意見
§5 專案驗收結論.................................................... 5.1 開發單位結論 5.2 建設單位結論
§6 附件............................................................ 6.1 附件一：軟體平臺驗收單 6.2 附件二：功能模組驗收單 6.3 附件三：專案文件驗收單 6.4 附件四：硬體裝置驗收單
§1 專案基本情況
§2 專案進度稽核2.1 專案實施進度情況
2.2 專案變更情況2.2.1 專案合同變更情況
{記錄合同變更情況}
2.2.2 專案需求變更情況
{記錄需求變更情況}
2.3 專案投資結算情況
§3 專案驗收計劃3.1 專案驗收原則
1、審查提供驗收的各類文件的正確性、完整性和統一性，審查文件是否齊全、合理; 2、審查專案功能是否達到了合同規定的要求; 3、審查專案有關服務指標是否達到了合同的要求; 4、審查專案投資以及實施進度的情況;
5、對專案的技術水平做出評價，並得出項目的驗收結論。
3.2 專案驗收方式
{記錄專案驗收的組織方式和參與驗收工作的人員情況}
3.3 專案驗收內容
1、硬體裝置驗收; 2、軟體平臺驗收; 3、應用系統驗收; 4、專案文件驗收;
5、專案服務響應(如售後服務、問題相應等方面)驗收。
§4 專案驗收情況彙總
4.1 專案驗收情況彙總表
4.2 專案驗收附件明細
1、軟體平臺驗收單(見附件一)。 2、功能模組驗收單(見附件二)。
3、專案文件驗收單(見附件三)。 4、硬體裝置驗收單(見附件四)。
4.3 專家組驗收意見
§5 專案驗收結論5.1 開發單位結論
5.2 建設單位結論
§6 附件6.1 附件一：軟體平臺驗收單
驗收人： 驗收時間：
6.2 附件二：功能模組驗收單
驗收人： 驗收時間：
6.3 附件三：專案文件驗收單
驗收人： 驗收時間：
6.4
附件四：硬體裝置驗收單
三優範文網