可行性分析與需求分析立項報告書_第1頁
可行性分析與需求分析立項報告書_第2頁
可行性分析與需求分析立項報告書_第3頁
可行性分析與需求分析立項報告書_第4頁
可行性分析與需求分析立項報告書_第5頁
免費預覽已結束,剩余10頁可下載查看

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、編寫員:信息管理與信息系統專業99094343 蔡藝孟審核員:電子系 劉繼聰可行性分析與需求分析立項報告書第一章 引言在今天計算機技術日益提高及企業管理功能等多項職能觀念相結合的情況下,絕大多數的企業內外部職能都可以利用計算機建模立系統來實現。辦公室電腦化、企業內部網的設立及完善、個人微機的普及以及電子商務的日漸推廣,似的企事業單位對內部和職工的工資管理這一環節大可以通過電子計算機及Internet 技術完成。數據庫技術的穩固更是對此工資管理系統的建立及運行、維護的一大支持。以當前數據庫建模, Client/Server 模式的分布式數據庫服務器硬件基礎,各計算機專業人員素質的提高,該系統的數

2、據歸檔及數字化管理無疑是可以成功的。第二章可行性考究第一節規模及目標工資管理系統(Salary Management System)所涉及的企事業單位或部門主要是該單位內部各職工 (普通用戶) 、 該單位財政部門、 人事部門以及作為代理人角色的銀行部門,從安全性和便利性考慮,則該系統的各級別用戶應該處于一個較集中的地域內,其最高層管理部門可以在域范圍外。該系統規模的完整性應該是建立在具 有專業技術的計算機管理人員若干及在該代理銀行具有戶頭、并最好擁有可以上網 的個人電腦的用戶,在這種情況下,規模是統一的。建立該工資管理系統,目標是為了在最為經濟的開銷下,準確無誤,及時地處理職工的工資發放及其相

3、關數據的立檔收留。第二節工資管理系統的高層邏輯模型通過對舊系統的經濟開銷、管理鄙陋、實現功能不完全的得知和分析(因無舊 系統,故簡而概之),對新系統的規模和目標的假想,我們以導出新系統的邏輯模型, 并建造新的物理系統。首先,我們建立該系統的數據流圖。1 .功能級數據流圖2 .進一步細分的數據流圖工資事務資事務更新信息個人工資,工資事務工資清單文工資信息D2稅收規范表1.1接受事務3.我們可以建立系統流程圖(物理系統)匯總表或工資條代理銀行工作人員單位內部工資管理人員D1 1職工工資清單稅收規范表職檔案1 .2更新工資清單21 3 I處理工資產生工資匯變動及發工資匯總表或工資條生成程序處理工資程

4、序3產生工資條印單位4部工 資管理人員銀彳亍工資底質打印那么我們現在就可以定義該新系統的數據字典了。首先,我們可以用數據字典卡片形式描述這些信息。名字:代理銀行工作人員別名:工資發放驗收員描述:定期將職工工資轉入職工帳戶的銀行員工定義:代理銀行工作人員=銀行地 址+銀行名稱+部門號+工作人 員名字+年齡+職稱位置:代理銀行工作人員表、銀行 地址信息表,以索引技術將二者綜合名字:單位內部工資管理人員別名:工資管理人描述:處理單個職工工資事務、匯 總所有職工工資審查,并及時更新 變動信息,立檔保存的工作人員。 定義:單位內部工資管理人員=單 位名稱+部門號+職工號+職工 姓名+年齡+職稱位置:職工

5、在職檔案表名字職工別名描述定期檢查或領取工資及工資條,及時告知工作變動信息的工作人員定義職工=單位名稱+部門號+職工號+職工姓名+年齡+職稱 +職,調動代碼+調動日期:職工在職檔案名字:工資事務別名:描述:類似于工資驗收、發放、修 改等操作和工資匯總表、工資條的 打印等活動。定義:工資事務=事務代碼+事務 處理日期+檢驗號位置:工資事務表名字:工資清單別名:工資文件描述:記錄職工定期工資信息、最 近變動信息的文件。定義:工資清單=職工號+職工姓 名+職稱+工資數量+稅收號+ 實發工資數+上次發放日期+備 注位置:職工工資清單表 名字:工資匯總表別名:描述:記錄所有職工在一定時期內 工資信息。定

6、義:工資匯總表=職工號+職工 姓名+職稱+職工調動代碼+調 動日期+工資數量+稅收號+實 發工資數+上次發放日期位置:工資清單表、稅收規范表、 職工在職檔案表,三者結合。名字:稅收規范表別名:描述:法定記錄在一定額收入范圍 內的納稅比例信息。定義:稅收規范表=稅收號+收入 范圍+備注位置:稅收規范表名字:工資條別名:個人工資表描述:對單個職工最近接收工資的 相關信息記錄。定義:工資條=工資卡號+身份證 號碼+職工號+職工姓名+職稱 +稅前工資數量+實發工資數量 +發放日期+銀行工作人員編號 位置:工資清單、稅收規范表、職 工在職檔案表、銀行工作人員表合在定義了較大的數據流節點后,我們就開始為各

7、個數據作出結構化描述了。1.基礎數據表2、21代理銀行工作人員表序號數據名含義數據類型是否允許為空1DepartmentNo.部門號Char(4)否2EmployeeNo.工作人員編號Char(4)否3EmployeeName工作人員姓名Char(12)否4Age年齡Char(2)是5Position職稱Char(16)否表2、2 2銀行地址信息表序號數據名含義數據類型是否允許為空1BankCode銀行代碼Char(4)否2BankName銀行名稱Char(20)否3BankAddress銀行地址Char(36)否表2、2- 3職工在職檔案表序號數據名含義數據類型是否允許為空11Departm

8、entNumber部門號Char(4)否2EmployeeNumber職工號Char(6)否3EmployeeName職工姓名Char(12)否4Age職工年齡Char(2)是5Position職稱Char(16)否6ChangeCode職工調動代號Char(4)是7ChangeDate調動日期Char(8)是8IDNumber身份證號碼Char(18)否表2、2 4單位信息表序號數據名含義數據類型是否允許為空1CompanyName單位名稱Char(32)否2CompanyAdr單位地址Char(30)否3ChiefMan法人代表Char(12)否表2、2 5工資事務表(一)序號數據名含義數

9、據類型是否允許為空1BusinessCode事務代碼Char(4)否2BusinessDate事務處理日期Char(8)否3CheckCode檢驗號Char(6)否表2、26工資事務表(二)序號數據名含義數據類型是否允許為空1BusinessCode事務代碼Char(4)否2Business事務具體描述Char(40)否注:工資事務表(二)是對工資事務表(一)中事務代碼對應的具體事項,其具體項是對職工工作的調入、調出及稅收等情況所作的工資處理。表2、27職工工資清單表序號數據名含義數據類型是否允許為空1SalaryNumber工資卡號Char(6)否2EmployeeNumber職工號Char

10、(6)否3EmployeeName職工姓名Char(12)否4Position職稱Char(16)否5SalaryQuantity工資數量Char(6)否6DiscountCode稅收號Char(4)否7SalaryReal實發工資Char(6)否8PaymentDay上次發放日期Char(8)否9Record備注Char(20)是表2、28稅收規范表序號數據名含義數據類型是否允許為空1DiscountCode稅收號Char(4)否2DiscountArrange稅收范圍Char(30)否3DiscountRate稅收率Double(8)否關于這些數據的采集,主要由單位人事部門,財政部門提供:

11、認識部門提供職工職工工作信息;財政部門提供職工工資信息。第三節 可以考慮的物理方案1 .建立一個企業內部網,人事部門對單位內部所有人員的信息記錄管理保存在一個人事信息服務器內;財政部門對于工資調動、發放等管理的信息保存在另一個財政信息服務器內;而工資管理部由若干人構成,并在一定權限下可訪問人事、財政信息服務器,也可另外建立容稅收規范表、職工工資清單表、在職檔案表等一起的工資管理服務器。2 .代理銀行也可以建立一個內部網,設立一個工資發放代理信息服務器;其工作人員在一定的權限下可以訪問企業內部網,但必須遵守法律規范。3 .職工人員有條件的亦可以通過局域網或互聯網作為在最低權限下訪問個人工資信息和

12、稅收規范信息等項。以上所說的三個方面可以通過現在的內部網、局域網、互聯網技術,數據加密技術等實現,其中大部分操作可以通過計算機,實時操作系統的方式進行。另外,若是企業分布區域跨度大,也可以利用分布式數據庫模式設立各種服務器及響應各種服務,遠程登錄等各項具體的網絡功能也是一個有力的軟件、協議技術支持。由此可以得到各種數據流向: 1 .職工領取工資銀行工作人員 工資代理服務器工資條.A2 .職工審查工資信息工資服務器個人公子信息或稅收信息AA3 .工資管理人員審查工資信息工資服務器匯總表*-4 .代理銀行工作人員杳詢信息代理服務器 工資服務器代理服務器核對 發放、轉帳操作 5 .職工調動信息人事服

13、務器工資服務器 6 .財政工資變動信息財政服務器工資服務器第四節成本/效益分析1 .時間價值估計 對于一個中小型企業來說,建立此項工資管理系統至少約需一年時間,而大規模企業,則至少需要2年時間。在這一段新舊系統的交換期間,由于新系統的完全投入,可根據實有貨幣在時間比銀行利率得知應收益或費的貨幣數量為多少。2. 人力物質價值估計 由于更新系統,故企事業單位必須有若干人一組的人力資源供建立內部數據庫使用。代理銀行部門和軟件開發商提供的人力作為貨幣投資方式計算。需要若干中型(大小)服務器若干,網絡布線若干,集線器、交換機等若干,打印機、微機平臺等亦可以一一計算。3. 粗略評估收益在沒有具體數據情況下

14、,我們也可以宏觀地展望該系統投入后所能獲得的各項收益。首先,企事業單位可以節省大批人力及時間去進行人對人的工資交互操作。高效率是該系統的追求目標之一。其次,可實現低錯誤率的處理。再者,職工取款等直接與銀行掛鉤,也大大方便了銀行與職工雙方對存取款關系的處理。第四,可通過分布式數據庫處理實現高層次的工作監督。第三章 需求分析第一節 系統功能要求及描述工資管理系統分為三大部分。新系統開發完成之后必須滿足用戶需求的最低要求,并且有可擴展性能。第一部分是職工查詢事務管理,該部分主要有普通職工以只讀權限展開,由職工通過網絡平臺往終端輸入個人查詢信息,再通過身份及權限驗證,向服務器提出請求,然后有服務器作出

15、物理操作將所需信息經過過濾器,網絡線路,才最終返回到職工的終端顯示。第二部分是工資實時管理。工資實時管理運用實時操作系統的運行觀念,通過工資管理人員往終端輸入身份密碼信息,經驗證后再輸入工資(或做變動)事務,通過服務器作基礎的物理數據變動、修改并保存,備份;最后核對,將核對信息送返工資管理人員,有必要時,打印所生成的工資匯總表。第三部分是代理銀行工資事務管理。該項管理功能也是首先由代理銀行工作人員往終端輸入身份、密碼,經過驗證后,申請代發工資處理事項,期間或完成工資轉入帳戶操作,或完成工資提款操作,最后由終端輸出職工的個人工資條。第二節 用戶需求與運行要求、效果評估該系統開發的用戶要求系統可以

16、綜合考慮職工調進、調出、內部調動的操作以及由此帶來的工資項目(數量)的變化,并加以考慮個人所得稅,來計算職工的實發工資數量。除此之外,工資的發放、轉入均有代理銀行實現,代理銀行以輸出含職工工資卡號、身份證號碼(安全性考慮)作為憑據;而內部管理人員也可以幾時地完成職工工資地匯總審查。現在提出值得考慮地性能支持:1. 聯機系統響應時間不超過半分鐘。系統周轉時間不超過三分鐘。2. 數 據 庫 建 立 所 需 地 存 儲 容 量 在 40G60G 之 間 ( 視 情 況 而 定 , 可 為15G20G,20G30G ) , 備份存儲容量在 20G 左右, 采用分布式數據庫模式雙服務器冗余備份以保障數據

17、安全。3. 外存儲器使用多個硬盤,7200 轉 /分,單碟式; 處理器使用 1.5G 以上頻率地Pentium 4 ,并且是多個,以保證運行速度。4. 數據通信接口主要由一些輔助軟件或是操作系統實現。5. 采用 ADSL 網絡模式,提供基于100BASE-T 技術的網絡傳輸速度(也可使用 ATM 的數據傳輸模式)6. 顯示終端使用17寸純平顯示器。另外配鼠標、鍵盤,有必要的配置刻錄機,掃描儀,打印機,傳真機。以目前可以供應的人力、財力及硬軟件技術,該系統將實現較完善的辦公自動 化和辦公遠程化。雖然前期投入大,但收效可觀。另外一些即時發現的問題可由用 戶和開發人員提出并修正。第三節建立系統的概念

18、模型在可行性分析環節中,我們已經建立了比較細的數據流程圖和數據字典,那么現在可以建立該系統的概念模型。用實體-聯系方法分析得出概念性的數據模型,附注:ER圖所示的中心是內部網、數據庫服務器,絕大部分事務必須通過該中心,其間所保留的E-A和E-M關系是因為可能有現實世界中電腦不可實現而只能人工操作的事件發生。人事管理人員、財政管理人員的屬性不再細分,他們提供原始 數據。第四節工資管理系統的功能模塊通過上述的功能要求及描述,和ER圖揭示對象實體之間的關系,綜合之,就可以得到該系統的功能模塊層次方框圖了。第五節將來可能提出要求1. 基于安全性考慮由防火墻的升級或匹配問題引起的工資管理系統權限驗證功能的進一步加密。2. 若企事業單位實行由工資提供內部保險金所引起的工

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論