使用者名稱稱: 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 原始碼提交清單
第五章 驗收結論
第一版驗收通過
第六章 雙方簽字
客戶方(蓋章): 代表:
公司(蓋章) 代表: 日期:
日期:
第三方((蓋章)[如果有]: 代表: 日期:
附件:
驗收測試記錄、測試報告等記錄。
甲方: 有限公司
乙方: 有限公司
甲方收到乙方開發的),下文簡稱“軟體”。截止於 年 月 日初步測試已經通過,暫時無發現重大軟體漏洞問題,軟體細節後期有待驗證。
乙方應在甲方實際使用軟體過程中,對軟體已有功能做售後服務。如後期有軟體漏洞問題,乙方應積極配合甲方做免費修復。
甲方驗收人員: 日期:
甲方驗收人員: 日期:
甲方:
乙方:
就“ ,經過甲乙雙方的通力配合和共同努力,完成了合同中約定的全部任務,現在整個系統執行正常,按照合同約定,進行專案驗收工作。
驗收工作分為裝置清點、安裝除錯、初驗、上線試執行和終驗幾個階段,驗收方式主要以清單、測試和實地操作為主。具體內容如下: 第一部分:裝置清點
主要檢查運到甲方的裝置是否與合同相符
甲乙雙方按照合同要求對運抵現場的裝置進行了清點,此項工作已於 年 月 日完成,結論如下:
1.1 核對到貨清單,實物與運送單據是否一致。
□通過 □未通過 備註:
1.2 檢查和清點運抵現場的各種裝置是否與合同相符。
□通過 □未通過 備註:
1.3 檢查運抵現場的文件是否齊全
□通過 □未通過 備註:
第二部分:安裝除錯
通過系統硬體測試證明各部分硬體物理破壞且已正確安裝。
按照合同要求,乙方對已經到貨的裝置進行了安裝,甲乙雙方進行了加電測試,主要觀察裝置加電後的表現和執行自檢程式的結果,此項工作已於 年 月 日完成,結論如下:
2.1 加電是否成功
□通過 □未通過 備註:
2.2 裝置狀態是否正常
□通過 □未通過 備註:
2.3 系統顯示的版本和序列號等資訊是否符合合同要求
□通過 □未通過 備註:
2.4 自檢有無報警
□通過 □未通過 備註:
第三部分:初驗、上線試執行
通過系統執行,證明系統可以正常工作
乙方進行裝置安裝除錯後,甲乙雙方在作業系統、資料庫等執行環境下進行系統測試,此項工作已於 年 月 日完成,結論如下:
3.1 系統啟動是否正常
□通過 □未通過 □未涉及 備註:
3.2 系統管理功能是否正常
□通過 □未通過 □未涉及 備註:
3.3 相關軟體License是否已經生效使用
□通過 □未通過 □未涉及 備註:
3.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.對於資料庫的檢查:對於資料庫中的表的一些屬性值,比如缺勤次數,是採取觸發器進行輸入的。在每輸入一組應“出勤次數/月“和 “實出勤次數/月”,對應的屬性缺勤次數將得到更新。在資料庫表中檢查並得到驗證。
一、專案基本資訊
二、驗收目的
目的在於對專案進行全方位的檢驗與測評,檢驗乙方提供的軟體系統是否遵循軟體開發標準的要求,檢驗各項指標與功能是否與合同要求相吻合。
三、驗收範圍
驗收範圍以雙方簽訂的技術開發合同所描述的內容為準。具體如下:
1、專案技術目標________系統可支援4個人工座席客戶端,實現_____功能。 2、專案技術內容
(1)、研究設計_______系統,系統可支援4個人工座席客戶端;實現。。。。;
(2)、硬體平臺建設:包括研華工控機 1套;客戶端主機DELL桌上型電腦10套,DELL筆記本3套;三匯語音卡1套;SONY DSLR-A230L數碼相機1套;D-Link 24口 網路交換機1套。
專案於20__年11月開始組織建設,在甲乙雙方密切配合下,專案進展順利,乙方按合同完成了___硬體平臺建設、軟體系統平臺開發、資料庫建設、系統培訓、技術支援等工作,系統於20__年12月正式投入使用,系統正常執行。
四、專案驗收表