考勤系统(计算机毕业论文).doc

辽宁工程技术大学毕业设计（论文）0. 前言21. 系统调查31.1 阜新盛明热电有限责任公司简介31.2企业组织结构41.3 现行考勤业务分析61.3.1现行系统业务流程图61.3.2 现行系统业务说明71.3.3 现行系统现状分析81.4 需求分析81.4.1 系统功能目标81.4.3 系统需求81.5 新系统初步方案91.6 可行性分析91.6.1 技术可行性102.3.5选定分析局部332.4 局部分析342.4.1 “请假考核”分析352.4.2 “作业考核”分析362.4.3 “生成考勤报表”分析382.4.4 “数据维护”分析392.4.5 分析类属性413. 系统设计423.1 全局设计423.1.1 确定核心元素423.1.2引入外围元素433.1.3 外围设计元素433.1.4 “分析机制”向“设计机制”映射433.1.5 落实“设计机制”的具体内容433.1.6模型组织结构465.2 系统评价715.2.1 经济效益评价715.2.2 系统性能评价715.2.3 管理性能评价71结论73致谢75参考文献760. 前言在电脑考勤系统自90年代从中国台湾引进大陆之前，国内的考勤管理先后经过人工考勤和机械打卡钟阶段，但是考勤数据采集不精确，请假等数据录入采集不方便，考勤统计报表错误多需要大量的人工修正，大量考勤工作集中在HR（人力资源部）一个部门处理，不论是基层员工还是HR部门和企业的各级主管对考勤系统都有怨言。引进以后就从条码卡发展到磁卡IC卡感应卡以至指纹考勤。新的考勤管理系统的特征：报表准确，报表没有过多的异常数据需要HR部门二次干预；系统可以查询实时员工在岗情况，并可以提供集成请假记录；全员式参与考勤管理；员工考勤自助；考勤数据全员共享；具体日常考勤管理工作权限可以从HR部门下放到具体的各考勤群组。新的考勤系统有两个重要意义： 其一，可以将考勤事务交给基本部门处理，交个每个员工自己处理，交给系统自动处理，用IT技术推动人事考勤管理的变革；其二，新的考勤系统的实施，不仅把HR人员从考勤的具体事务中解放出来，而且也推动了全员对人事管理的参与和互动。HR人员的可以把工作重心可以放在服务员工、支持公司管理层的战略决策上，放在公司最重要的资产员工和员工的集体智慧的管理上等核心业务上来。在此讨论的考勤管理系统的开发，旨在探索一种新的考勤模式。通过这种新的模式，为企业的传统考勤模式创造一种新的概念，提高考勤工作效率和标准化水平。由于本人能力有限，加之经验不足，时间仓促，设计中还有很多不足，还请各位老师提出宝贵意见和建议。1. 系统调查1.1 阜新盛明热电有限责任公司简介阜新盛明热电有限责任公司现装机容量2.4万千瓦，于2003年投产，该项目是阜新市经济转型重点项目之一，是由辽宁电力开发公司、阜新太平电厂等九家单位投资兴建。该厂以热定电，实行热电联产，电力送入辽宁电网，年设计上网电量1.32亿千瓦时。该项目的建设对就地消化阜新低质煤炭，改善阜蒙县城区居民生活水平，减少城市环境污染，加快城镇建设，改善投资环境，节约能源，实行资源优化配置，增加工业产值和税收，拉动地方经济增长具有重要意义。阜新盛明热电有限责任公司一期2台机组分别于2003年1月和9月发电并网，投产当年完成上网电量7978万千瓦时，接待县城区供热面积75万平方米。到20042005年采暖期供热面积达到90万平方米，上网电量达1.4亿千瓦时以上。阜新盛明热电有限责任公司年工业产值超过5000万元，创利税700多万元，列阜蒙县前10位，有效拉动了阜蒙县地区经济；公司安排就业人员300多人，保证了地区的稳定和发展，经济效益和社会效益明显。目前，阜新盛明热电有限责任公司正在筹建二期二炉一机工程，届时该公司装机容量将达到3.6千瓦，年上网电量2亿千瓦时以上，供热面积达到130万平方米以上。该公司二期工程建设完成后，将进一步提高公司产值和税收，造福阜蒙县人民。1.2企业组织结构企业设有经理工作部、发电部、生技部、物资部、财务部、安监部、经营部、维护部和供热公司共9个职能部门。经理工作部：在接收各部门的工作汇报的同时，也审核各部门的业务情况。财务部：该企业的财务部除了要处理日常的财务信息外，还负责对考勤信息进行汇总、统计，并依此为员工发放工资。经营部：接收电业局的需求信息，并把需求信息传达给生技部；这里需要说明的是，电业局是需求的主体，企业全年的生产计划是根据电业局的需求制定的，而对供暖用户的需求是不做处理的；因为该电厂是正常发电的电厂，而非调峰电厂（阜新热电厂就是调峰电厂）在发电的同时产生的余热是副产品，夏天的时候从水塔蒸发掉，冬天的时候才对用户供暖，全年发电所产生的余热是远远超过阜新县城的供暖需求的。生技部：根据经营部的需求信息制定生产计划并传达给发电部，且对发电部给予技术支持；编制生产计划并制定维修、维护方案，然后整理成物料需求信息交给物资部。发电部：按照生产计划进行发电；向生技部反映生产方面的问题。物资部：各部门的生产、日用物资需求信息传达给财务部，并领取采购金，在采购后发放下去。安监部：负责发电部的生产、安全的监察工作；负责审核物料需求计划。维护部：负责对发电部的维护和维修。供热公司：是企业内部相对独立的一个子公司，有自己的营业部、工程管理部、调度运行部；主要职能是对阜新县城区进行供热。该考勤管理系统预期解决原考勤业务中的问题，通过减少HR部门的工作量从而提高工作质量，提高工作效率，减少不必要的人力劳动。以刷卡考勤取代手工考勤，从而确保考勤数据的准确性，共享性，透明性进而是整个改进后的系统实现高效、快捷、准确的管理目标。1.5 新系统初步方案以原有系统业务为依托，以适应考勤管理的发展为需要，整理新系统初步解决方案如下。新的考勤管理系统提供以下7个方面的服务功能。1. 签到刷卡。普通员工（包括基层主管和DBA）和经理层在签到的时候使用IC卡刷卡，考勤机记录了员工上班时刷卡的日期、时间，为了防止有人代刷，考勤机还要配合监视器一起使用。2. 签出刷卡。普通员工（包括基层主管和DBA）在签出的时候使用IC卡刷卡，考勤机记录了员工下班时刷卡的日期、时间；但是经理级角色对签出刷卡用例则不同，他们是管理者，拥有是否要求该员工出勤的权限，所以不必在签出是刷卡。3. 请假考核。基层主管对普通员工的请假情况进行审批和记录，然后录入记录的请假信息。4. 作业考核。基层主管对普通员工工作操作、行为规范等情况进行考核，然后录入作业考核信息。5. 生成考勤报表。系统对考勤数据做最终统计，以便领导查询。6. 考勤查询。所有员工都具有对统计后的考勤数据进行查询的权限。7. 数据维护。管理员对数据库进行维护，包括数据修改、数据备份、数据还原等工作。1.6 可行性分析可行性分析是从技术可行性，经济可行性和运行可行性三方面，论证系统开发的可行性。以下是对本系统的可行性分析。1.6.1 技术可行性考勤管理系统采用C/S结构，该结构具有开发灵活，运行效率高，技术成熟等特点。开发语言选择C+，C+一种设计非常优秀的语言，继承了C的基本功能，但比C复杂的多。C+还深受其他语言的影响，包括Java和Delphi，C+博采众家之长，同时克服了其各自的缺点。开发工具选择Miscrosoft Vsiual C+ 6.0。该开发工具对C+具有良好的支持，提供可视化开发环境及丰富的窗体控件。后台数据库采用Microsoft公司的SQL Server2000，它能够胜任目标系统数据处理的需求，并与Windows操作系统紧密完美的结合。实施人员掌握SQL Server2000，网络技术，虽然新接触C+，但曾开发过C/S结构信息管理系统，有PB，C的编程经验。因此，考勤管理系统的开发在技术上是可行的。1.6.2 经济可行性该公司共有机房2个，以公司目前员工的数量，可满足考勤管理的需要。因此，不需要增加计算机，只需要购买刷卡用的考勤机和IC卡即可。考勤管理系统运行环境采用现有的操作系统Windows系列。系统开发工具，以及后台数据库，均无须购买。因此实施考勤管理系统，所需费用为0。若想将考勤管理系统全面投入运行，所需资金投入也不过千元而已。因此，实施考勤管理系统，在经济上是可行的；将考勤管理系统全面投入运行，在经济上也是可行的。1.6.3 运行可行性自动化考勤管理系统，是考勤模式模式的发展方向，以现代信息技术完成考勤业务，可以提高工作效率和工作质量，这与企业的要求是相吻合的。企业管理制度齐全，领导支持创新。企业计算机设备齐全，网络完善，有良好的机房管理制度。企业的DBA对微机操作熟练，完全可以掌握系统的使用。因此，考勤管理系统的运行可行性是可行的。1.6.4 总体可行性综上3个因素，实施考勤管理系统是完全可行的；全面投入使用，也是完全可行的。2. 系统分析2.1 分析问题领域2.1.1 系统边界考勤管理系统与工资管系统有着紧密联系。员工考勤信息存入考勤管理数据库，再经过统计传递给工资管理数据库，最后计算出员工工资，从而实现数据的充分共享。该系统为C/S结构，因此具有可扩展性好，易维护、易升级，易管理，硬件投资小，安全性好的特点。2.1.2 定义活动者活动者（Actor）是用户作用于系统的一个角色。活动者有自己的目标，通过与系统的交互达到目标。根据考勤管理系统的职责和需求可以确定6个活动者：普通员工、基层主管、DBA、经理级、人事考勤管理数据库和财务系统。对于每一个活动者，应当明确其业务活动的内容，对系统的服务要求。“普通员工”活动者是考勤管理的主体对象，需要进行签到和签出刷卡，可以对自己的考勤情况进行查询（不可以对其他员工的考勤情况进行查询，其一是普通员工不具备该权限，其二是这样做不利于集体的团结）。“基层主管”活动者是考核管理的负责人，其工作包括：请假考核和作业考核。其中请假考核在信息技术的支持下可以实现客观化管理，但作业考核虽然需要评价，可还是不能避免主观因素的存在，因此作业考核的准确性存在偏差。“DBA”活动者负责对“人事考勤管理数据库”和“工资管理数据库”进行维护，主要工作是数据修改、数据备份、数据还原。“经理级”活动者通过考勤管理系统对员工的考勤进行监管。“人事考勤管理数据库”活动者收集、存储原始考勤数据，并对其进行统计，进而生成考勤报表，以便普通员工查询和“经理级”审阅。2.1.3 定义Use CaseUse Case是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述序列1。在该Use Case图中只有顶层图，主要是考虑到考勤管理系统体积不大，做成一个顶层图会使得各用例间的关系更清晰。具体关系如图3-1所示。图2-1 考勤管理系统顶层Use Case图2.2 Use Case报告2.2.1 “签到刷卡”的Use Case报告简介普通员工（包括基层主管和DBA）和经理层在签到的时候使用IC卡刷卡，考勤机记录了员工上班时刷卡的日期、时间。事件流基本事件序列1. 接收签到刷卡信息员工：员工进行签到刷卡。系统：接收员工签到刷卡的信息。2. 身份确认系统：系统对IC卡上的员工的个人信息进行确认，如果确认为“无效”，转至A1备选事件序列。 员工：员工进行签出刷卡。系统：接收员工签出刷卡的信息。1. 身份确认系统：系统对IC卡上的员工的个人信息进行确认，如果确认为“无效”，转至A2备选事件序列。2. 记录签出刷卡即时信息系统：系统记录员工刷卡的时间、日期、职员编号。3. 整理签出刷卡信息系统：系统整理记录的签出刷卡的即时信息，生成出勤信息，内容包括：日期、职员编号、下班刷卡时间、是否早退、早退时间。4. 上传签出刷卡信息系统：系统将整理后的签出信息上传到数据库 备选事件序列结束状态如果该Use Case顺利执行，系统将成功记录员工的请假考核信息；否则，系统状态应该保持和该Use Case执行之前相同。Use Case图图2-6 “请假考核”Use Case图事件流图图2-7“请假考核”Use Case的事件流图2.2.4 “作业考核”的Use Case报告简介基层主管对普通员工的作业情况进行记录，并录入系统。事件流基本事件序列1. 考核作业情况基层主管：基层主管对普通员工的作业进行考核。2. 记录作业考核信息基层主管：基层主管对普通员工作业考核的情况进行记录，主要内容为是否有违规操作。1. 上传作业考核信息系统：系统将记录的请假信息上传到数据库 。启动条件基层主管对普通员工的作业进行考核。结束状态如果该Use Case顺利执行，系统将成功记录员工的作业考核信息；否则，系统状态应该保持和该Use Case执行之前相同。图2-9“作业考核”Use Case的事件流图2.2.5 “生成考勤报表”的Use Case报告简介系统对考勤数据进行统计，进而生成考勤报表。事件流基本事件序列1. 提取考勤数据财务系统：财务系统从人事考勤管理数据库中提取考勤数据。2. 统计考勤数据财务系统：财务系统对提取的考勤数据进行统计。3. 编制考勤报表财务系统：财务系统将统计后的考勤数据编制成报表。4. 打印报表财务系统：财务系统打印考勤报表。经理级：审阅考勤报表5. 考勤查询系统：将考勤报表的内容提供给查询者。（由于考勤查询是另一用例，故在事件流图中未继续画出，而在下一Use Case报告中具体阐述）启动条件财务系统有统计行为。结束状态如果该Use Case顺利执行，系统将成功生成考勤报表；否则，系统状态应该保持和该Use Case执行之前相同。备选事件序列A4提示重新登陆起始位置：基本事件序列中，身份验证。触发条件：员工身份验证失败。具体内容：系统做出提示，提供2种选择：1. 重新登陆；2. 登陆成功。返回位置：1. 返回起始位置。2. 进入考勤查询界面。A5继续查询起始位置：基本事件序列中，显示查询结果。触发条件：上次查询结束。具体内容：系统做出提示，提供2种选择：1. 继续查询；2. 退出系统。返回位置：1. 返回查询界面。2. 退出系统。启动条件查询者有查询行为。结束状态如果该Use Case顺利执行，系统将成功显示查询结果；否则，系统状态应该保持和该Use Case执行之前相同。Use Case图图2-12 “考勤查询”Use Case图事件流图图2-13“考勤查询”Use Case的事件流图2.2.7 “数据维护”的Use Case报告简介查询者（包括普通员工和经理层）根据自身权限的不同，对考勤查询的内容也不同：普通员工只能对自己的考勤信息进行查询，经理层可以对所有的员工的考勤信息进行查询。事件流基本事件序列1. 登陆数据维护界面DBA：登陆数据维护界面。2. 身份验证系统：系统对查询者的个人信息进行验证，如果验证失败，转至A6备选事件列。3. 进入数据维护界面系统：通过身份验证后，系统将自动跳转到数据维护界面。4. 选择操作内容DBA：选择所要进行的操作，包括：数据修改、数据备份和数据还原。其中数据修改又分为员工变动数据修改和考勤数据修改，修改后的数据存入数据库；在完成数据上次维护操作后，如果要继续操作，则转至A7 备选事件序列。5. 退出登陆查询者：注销登陆身份。系统：退出查询系统。备选事件序列A6提示重新登陆起始位置：基本事件序列中，身份验证。触发条件：员工身份验证失败。图2-19 “请假考核”序列图协作图图2-20 “请假考核”协作图2.4.2 “作业考核”分析提取分析类根据“作业考核”Use Case报告，提取如下分析类。1. 边界类：作业考核界面。2. 控制类：考核类。3. 实体类：作业信息类。转述需求场景将“作业考核”Use Case报告中用文字描述的需求场景转述成基于面向对象概念的UML交互图。如下面2图所示：序列图图2-21 “作业考核”序列图协作图图2-22 “作业考核”协作图2.4.3 “生成考勤报表”分析提取分析类根据“发送试卷”Use Case报告，提取如下分析类。1. 边界类：生成考勤报表界面。2. 控制类：统计考勤数据类。3. 实体类：考勤数据类。转述需求场景将“生成考勤报表”Use Case报告中用文字描述的需求场景转述成基于面向对象概念的UML交互图。如下面2图所示：序列图图2-23 “生成考勤报表”序列图协同图图2-24 “生成考勤报表”协作图2.4.4 “数据维护”分析提取分析类根据“数据维护”Use Case报告，提取如下分析类。1. 边界类：数据维护界面类。2. 控制类：维护操作类。3. 实体类：考勤数据类。转述需求场景将“数据维护”Use Case报告中用文字描述的需求场景转述成基于面向对象概念的UML交互图。如下面2图所示：序列图图2-25 “数据维护”序列图协同图图2-26 “数据维护”协作图2.4.5 分析类属性各类属性如下图所示：图2-27 各分析类属性3. 系统设计3.1 全局设计“全局设计”任务将在拟建系统的选举范围内，以分析活动的结果为出发点，将现有的“分析类”映射成模型中的“设计元素”。“全局设计”任务的总体思路是从上向下充实层次构架中的内容，然后做贯穿层次的调整。3.1.1 确定核心元素“确定核心元素”活动的主要依据是多个“局部分析”活动中得到的“分析类”的集合。概念上，“设计元素”是能够直接用于指导实施（编码）的模型要素。在本文范围内，“核心设计元素”指由“分析类”映射而来的“设计类”。“分析类”到“设计元素”的映射如下表所示：表3-1 “分析类”与“设计元素”映射表3.1.2引入外围元素“引入外围元素”活动的主要依据包括位于中高层次中的“核心设计元素”以及分析活动中得到的“分析机制”；该活动的结果是包含具体内容的“设计机制”和被充实的层次构架中低层次。3.1.3 外围设计元素“外围设计元素”与拟建系统的应用逻辑不直接相关，它们辅助“核心设计元素”具体的利用“分析机制”所概括的基本服务。“外围设计元素”通常伴随“设计机制”及“实施机制”的逐步“落实”而被引入拟建系统构架中的中低层次。换而言之，明确“设计机制”及“实施机制”的过程将“带动”向设计模型中引入“外围设计元素”。1图3-9 “设计元素”数据控制类使用DBMS-SQL的读取的静态结构下图为“设计元素”数据控制类使用DBMS-SQL的读取场景2. “设计类”考勤数据类“设计类”考勤数据类应用“留存”机制时，构造型role所对应的具体“核心设计元素”与“衔接设计元素”如下表所示：DBMS-SQL中的role核心设计元素与衔接设计元素rolePersistentClass考勤数据类rolePersistentClient数据控制类rolePersistentClassList考勤数据ListroleDBClassDB数据控制类表3-7 “设计类”考勤数据应用“留存”机制的role