人才管理信息系统

1课 程 设 计 报 告学生姓名:学 号：学 院:班 级:题 目:人才管理信息系统员工招聘子系统分析与设计教授王欣指导教师： 职称: 2011年 7 月 13 日21目 录1. 选题背景12 人才管理系统需求分析22.1 人才管理系统的需求陈述22.2需求分析22.2.1 功能需求22.2.2 性能需求32.3系统需求建模4确定参与者42.3.2 确定用例42.3.3 系统用例建模42.3.4 用例描述63. 人才管理系统系统分析83.1 系统用例建模83.2 静态结构模型103.2.1 类的识别103.2.2 类的关联分析113.2.3 类的属性描述113.2.4 类图的构建113.3 系统动态模型123.3.1 系统执行顺序分析123.3.2 系统的协作分析133.3.3 系统状态分析143.3.4 系统活动分析154. 人才管理系统系统设计与实现174.1 UML体系结构设计174.1.1 硬件体系结构设计174.1.2 软件体系结构设计174.2 对象模型设计184.3 系统实现194.3.1 组件分析194.3.2 配置分析205. 课程设计心得体会21参考文献221. 选题背景1. 选题背景人才管理是每个企业必不可少的。科学的管理和利用专门人才将对企业产生不可估量的效益。如果人工直接统计的话，工作量将十分庞大，特别是，如果企业员工有几万或几十万人时，人工统计将变得不可能想象。用计算机可使人们从繁重而又单调的统计运算中解脱出来，仅用一些简单的操作便可及时准确地获得需要的信息。人才管理系统的主要任务是对人才信息进行整理，使得能方便快捷地对人才信息进行查询、统计、更新，并且能按一定要求输出报表。通过该系统，使企业的人事管理工作系统化、规范化、自动化，从而提高企业人事管理的效率。对现行人才管理信息系统进行调查之后人才管理信息系统主要由人才培养资助管理子系统；人才选拔管理子系统；人力资源库建立管理子系统；人才专项业务管理子系统；社会化服务管理子系统及其他管理子系统组成，其组织机构图如图1.1所示。人才培养资助其他业务人才管理信息系统人才选拔人力资源管理人才专项业务管理社会化服务招聘管理职位管理人事管理图1.1 人才管理信息系统组织机构图2. 人才管理系统需求分析2 人才管理系统需求分析2.1 人才管理系统的需求陈述人力资源管理子系统主要负责完成对在职员工、解聘员工、离退员工的基本信息、任职情况、组织变动、奖惩情况等档案数据的维护、统计分析，晋升、降职、辞职、辞退、退休等人事变动业务的处理，并提供各类员工信息卡片、信息报表。发展规划人 员组织机构 管理模式基础条件人才管理系统应用系统计算机硬件系统软件网络数据库总体数据模型外部环境图2.1 人力资源管理子系统对人才管理子系统的需求为：（1） 企业招聘人员将员工登记表给企业管理员进行录入；（2） 企业管理人员将员工基本信息提交报表管理；（3） 企业管理人员记录员工出勤信息并将员工数据提交报表管理；（4） 企业管理人员记录员工工资信息并将员工数据提交报表管理；（5） 管理人员通过对各类报表的分析，向财务部提交工资下发报表；2.2 需求分析2.2.1 功能需求面对大量繁杂的人才管理，人员的招聘、绩效考评与工资发放工作，迫切的需要通过计算机来帮助解决，减少人力管理人员的工作量。人才管理信息系统采用符合有关国际标准，具有良好的开放性和兼容性的计算机，外部设备，操作系统及应用软件，达到和办公自动化网络的连接，实现人才管理的自动化。“人才管理系统”需要具有界面友好，功能强大， 使用方便，安全可靠等优点。通过人才管理工作人员对人才管理系统的理解：1、人才管理系统需要有能够及时地查询员工的信息，以便及时准确地为员工提供个人信息，但是不能更改数据，无信息处理权，即可以打印清单，浏览数据等，管理权限由系统管理员掌握分配。2、能够提供外界进行查询，无特殊权限限制，面向所有员工。3、企业人才各项数据信息必须保证安全性和完整性，网络系统设有通信，程序，网络三级权限和口令管理，确保系统的安全。这个是对数据的安全考虑的。2.2.2 性能需求根据调研，总结其它企业开发实施人才管理系统的经验和教训，我们认为，由于目前还没有一个人才管理系统的行业标准，而实施人才管理系统，又是发展趋势，因此，各企业只能根据自己的情况选择适合自己的人才管理模式，就目前来说没有哪一家企业的人才管理系统是适合其它所有企业的，也就是说我们必须结合本单位的情况设计适合自己的人才管理系统。在系统的设计和开发中，以下问题是应该注意的：新系统应该尽可能地解决现有系统存在的问题。例如：减少手工操作和重复劳动，提高计算机管理程度，尽可能的杜绝漏费现象，方便查询、统计，方便数据的管理和备份等等。由于医院工作的特殊要求，从硬件及软件上都要考虑到有良好的数据量处理能力。系统应具备较好的可维护性，较长的生存期，避免较短的时间内被推倒重来的情况发生。针对现行人才资源管理系统运行状况的调查分析结果，建设本人才资源管理系统的性能需求主要有如下几个方面：(l)连续不间断为了能随时随地为员工提供查询服务，能够不断更新员工信息，以及删改、变动。(2)时间响应要求响应时间短，更新时间短，数据转换和传送时间段。(3)数据量大要能适应大的数据存储量，要求具有强大的存储空间。(4)信息类型多样支持多种信息类型，比如说表格、图形等信息类型。(5)标准规范的符号语言根据实际情况，要选择合适的符号语言，能够清晰的描述系统的要求。(6)高质量的信息保密和安全人才管理系统对员工的基本信息进行保密，不能随意透露员工的基本信息，有一定的可靠性。(7)良好的人机交互在开发中应重视良好人机交互性能的设计，包括更好的引导性界面，更方便的在线帮助提示，更简单的操作方法，更易学、快捷的汉字信息录入等，尽力减少用户文字信息的键盘输入。2.3 系统需求建模确定参与者在分析过程开始的时候，我们考虑到获取用例首先要找出系统的执行者。有鉴于此，我们通过用户回答一些问题的答案来识别执行者。1.谁使用系统的主要功能(主要使用者)。2.谁需要系统支持他们的日常工作。3.谁来维护、管理使系统正常工作(辅助使用者)。4.系统需要操纵哪些硬件。5.系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。6.对系统产生的结果感兴趣的人或事物。通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：总经理，财务部，人事部，相关部门。2.3.2 确定用例能否成功地开发一个项目，在很大程度上取决于能否采用一种对于项目组人员和用户来说都非常直观的方式定义系统的需求。用例就是目前定义系统需求的最佳方式用例识别是应用UML进行面向对象分析的关键的一步，是后续工作的前提。用例是面向目标的，它代表的是系统将做什么，而不是系统将怎么做。它相当于一个容器，一个满足系统各种交互的容器。识别出用例并不总是很直观的。可以从事件表中来识别用例，一旦事件被定义，用例的定义就变得简单了。活动者是事件的主体，事件从系统活动者中寻找。事件可以按照下面的格式来定义：主语+动词+宾语其中：主语一表示已被识别出来的活动者，例如人力资源部；动词表示动作，例如规划、管理、考评；宾语一表示动词涉及的目标，例如劳动合同或人事档案。2.3.3 系统用例建模事件表中的每个事件并不总是对应一个用例。可能有些事件是相近或相同的，如果多个事件有共同点或者多个事件的最终目标相同，那么就可以将这些事件合并为一个事件。系统层的用例识别过程如下：通过前面对人才资源管理的系统描述，按照上面介绍的用力识别方法，可以从系统顶层得到系统层事件。从系统层识别出的用例，它们是：(1)管理组织机构(2)管理招聘(3)管理职位(4)规划人力资源(5)考评员工绩效(6)管理人事档案(7)管理劳动合同(8)管理培训(9)管理员工薪资(10)管理员工福利(11)管理系统权限(12)登录系统(13)修改个人资料人才资源管理系统的用例图如图2.2所示。图2.2 人力资源管理用例图2.3.4 用例描述一个用例对应并描述一个完整的功能。路径是用例中事件的步骤。一个路径也称为一个场景。每一个用例包含多种路径，每一个路径由一系列业务步骤组成。如果用例的粒度太粗，一个路径甚至一个业务步骤也可以定义为一个用例；如果用例的粒度太细，则一个用例只有一条路径，这会导致某一功能支离破碎。因此要合理掌握用例的粒度。路径有3个层次：主要的、可选的和例外的。主路径是用例中最通常情况下发生的路径；可选路径是合法的但不是经常发生的路径；例外路径是不按设想顺序进行的路径，是应用程序中必须要捕获的错误情况。用例描述了系统做什么，但没有规定怎么做，即用例图没有显示不同的路径，只显示了活动者与用例之间的关系。因此，需要为用例配上结构化叙述的文体。为了统一格式，每个项目应该使用一个用例模板。在论文中，系统实例使用如下所示的用例模板来描述用例。用例模板用例名称 (用例名)用例目标 (用例在系统中的目标)级别 (概要任务首要任务子功能)活动者 (此用例的活动者)状态 (未定义路径只定义了初始路径路径定义完成)前件条件 (用例执行前系统应具有的状态)主路径 (用例主路径的名称)可选路径 (用例的可选路径)例外路径 (用例的例外路径)这个模板描述了一个用例的主要方面。下面以管理招聘用例为例说明用例模板的用法。用例名称 管理招聘；用例目标 制定年度人力资源计划及招聘计划，发布招聘公告，管理员工筛选过程及评估工作；级别 子功能；活动者 人力资源部，公司主管，用人部门；状态 只定义了初始路径；前件条件 人力资源部登录系统；主路径 用人部门提出人员需求，人力资源部拟定招聘计划，公司主管审批招聘计划，人力资源部发布招聘公告，人力资源部筛选录用应聘者，人力资源部评估招聘工作；可选路径 特殊人员员招聘；例外路径 无。其它用例描述从略。3. 人才管理系统系统分析3. 人才管理系统系统分析3.1 系统用例建模对系统顶层识别出的员工招聘管理用例进一步细化，从而建立比较详细的员工招聘管理用例模型。1、活动者识别通过对员工招聘管理功能模块的文字描述，与系统发生交互的实体有总经理、人力资源部、人力资源部部长、用人部门、用人部门主管领导、应聘人员、复试小组、用人部门代表、资深专业人士和劳动部门。总经理直接与系统交互参与招聘管理，可以识别为活动者：总经理：人力资源部和人力资源部部长与系统直接进行交互，二者的目标相同，可识别为一个活动者：人力资源部；用人部门、用人部门代表和用人部门主管领导与系统直接进行交互，三者的目标相同，可识别为一个活动者：用人部门；应聘人员参与系统交互，可以识别为一个活动者：应聘人员；劳动部门参与系统交互，可以识别为一个活动者：劳动部门；资深专业人士不参与系统交互，不能识别为活动者，复试小组虽然与系统直接交互，但它由用人部门代表、人力资源部部长、资深专业人士组成，不能识别为活动者。综上所述，员工招聘管理功能模块共识别出5类活动者。(1)总经理 (2)人力资源部 (3)用人部门(4)应聘人员(5)劳动部门2、用例识别根据前面介绍的用例识别方法，下面来定义事件。通过已识别的活动者并结合对员工招聘管理功能模块的文字描述，将系统层事件中的管理招聘事件细化，可以得到管理招聘事件表。描述短语是从系统层的员工招聘管理用例中识别出的子用例。他们是：(1)提出人员需求 (2)制定人力资源需求计划 (3)审批人力资源需求计划 (4)拟定招聘计划 (5)审批招聘计划(6)发布招聘公告(7)登记个人简历和求职表(8)参与员工筛选录用(9)评估招聘工作3、员工招聘管理用例模型用例识别出来以后，就可以画出员工招聘管理用例模型，如图3-3所示。4、用例描述用例名称 提出人员需求；用例目标 根据本部门的具体情况，制定本部门的年度人员需求计划并提交到数据库：级别 子功能；活动者 用人部门；状态 只定义初始路径；前件条件 用人部门登录系统；成功后件 用人部门登录系统后可以编辑、修改、查看、删除本部门的人员需求计划；主路径 用人部门登录系统后编辑、修改、查看、删除本部门的人员需求计划并提交到数据库中；可选路径 1、修改并提交；2、查看：3、删除；例外路径 无。其它用例这里不再描述。图3.1 员工招聘管理用例图3.2 静态结构模型3.2.1 类的识别首先从系统文字描述中找出用来描述问题域实体的名词。根据招聘管理事务描述可以得到以下名词：总经理，人力资源部，用人部门，劳动部门，求职者，“拟予聘任”的人员，“拟予复试”的人员，通过复试的应聘人员，应聘人员，拟录用的人员，体检合格者，社会应聘人员，被录用的应届毕业生，被录用员工，员工，落选的应聘者，试用期的人员，部门，部门人员需求，年度人力资源需求计划，招聘计划，招聘公告，个人简历，求职表，面试通知，初试测评表，复试记录表，复试结果推荐书，复审意见，拟录用人员，体检结果，劳动手续，试用通知，员工登记表，试用劳动合同，试用意见，转正定级审批表，试用期工作小结，考核意见，正式劳动合同下面对上述名词进行分析，从而得到实体类。总经理，人力资源部，用人部门，劳动部门属于系统的用户，可以识别为一个类：用户；求职者，“拟予聘任”的人员，“拟予复试”的人员，通过复试的应聘人员，应聘人员，拟录用的人员，体检合格者，社会应聘人员，被录用的应届毕业生，被录用员工，员工，落选的应聘者，试用期的人员，拟录用人员，个人简历可以识别为一个类：应聘者；部门可以识别为一个类：部门；部门人员需求可以识别为一个类：部门人员需求；年度人力资源需求计划可以识别为一个类年度人力资源需求计划；招聘计划可以识别为一个类：招聘计划：招聘公告可以识别为一个类：招聘公告；求职表可以识别为一个类：求职表；面试通知可以识别为一个类：面试通知；初试测评表可以识别为一个类：初试测评表；复试记录表可以识别为一个类：复试记录表；复试结果推荐书可以识别为一个类：复试结果推荐书；复审意见可以识别为一个类：复审意见：体检结果可以识别为一个类：体检结果：试用通知可以识别为一个类：试用通知；员工登记表可以识别为一个类：员工登记表：试用劳动合同可以识别为一个类：试用劳动合同；试用意见可以识别为一个类：试用意见；转正定级审批表可以识别为一个类：转正定级审批表；试用期工作小结可以识别为一个类：试用期工作小结；考核意见可以识别为一个类：考核意见：正式劳动合同可以识别为一个类：正式劳动合同。3.2.2 类的关联分析要建立类模型，不仅要识别出类，还要识别出类与类之间的关系。通常显式的关系可以从用例中找到，而隐式的关系在用例中没有明确的说明，这需要认真的分析。招聘管理菜单和制定需求计划、主菜单有关联；员工筛选录用和主菜单、登记个人简历有关联；制定需求计划和招聘管理菜单和审批招聘计划有关联；审批招聘计划和制定需求计划和拟定招聘计划有关联；需求计划和拟定招聘计划、发布招聘广告有关联；发布招聘广告和需求计划、主菜单、登记个人简历有关联；登记个人简历和发布招聘广告、主菜单、员工筛选录用有关联。3.2.3 类的属性描述窗口结构是窗口之问的切换流程，通过窗口结构可以直观地看到通过用例的路径流程。一个软件在实用性上满足用户的需求是不够的，因为如果窗口结构不合理，也不会受到用户的欢迎。这里只介绍总体窗口结构。在进入系统窗口之前，首先要经过用户权限验证窗口，通过验证后弹出系统主窗口，在系统主窗口中共包含9个菜单项，根据用户权限的不同，使主菜单显示不同的菜单项。3.2.4 类图的构建经上述分析过程之后得出的员工招聘管理子系统的类图如图3.2所示。图3.2 员工招聘管理系统类图属性描述：员工招聘管理的属性： 招聘管理菜单、员工筛选录用、制定需求计划、审批招聘计划、拟定招聘计划、需求计划、登记个人简历、发布招聘广告。3.3 系统动态模型3.3.1 系统执行顺序分析为了实现一个合适的系统，第一步应对企业目前情况进行调研分析，掌握现有的工作模式和工作流程。在顺序图中，一条竖线代表一个对象，每个时间用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象，时间从上向下递增，箭头线在垂直方向上的相对位置表示事件发生的先后。根据对员工招聘管理系统的评估招聘工作业务流程分析，可以得到顺序图，如图3.3所示。图3.3 评估招聘工作序列图3.3.2 系统的协作分析合作图也称为协作图，用于描述相互合作的对象间的交互关系和链接关系。与顺序图一样，合作图也展示了对象间的动态协作关系。它除了说明信息的交换外，还显示对象间的连接关系，描述信息在连接的对象之间的传递。根据对员工招聘管理系统的业务流程进行分析得出的顺序图，可以得出该系统的协作图如图3.4所示。图3.4 员工招聘管理合作图3.3.3 系统状态分析状态图描述了事件和对象状态的关系。员工首先输入自己的基本信息，上交基本信息，然后由经理审批或是用人单位审批，用人单位把员工信息存档；用人单位再上交人事部审批，最终送到劳动部门。根据以上流程，用UML的动态建模机制定义并描述系统结构元素的动态特性及行为，可以定义出人才管理系统人员招聘子模块的状态图如图3.5所示。图3.5 员工招聘管理状态图3.3.4 系统活动分析活动图是由状态图转化而来的，它描述了系统中各种活动执行的顺序，刻画了一个系统中所要进行的各项活动的执行流程。根据上文中绘制得出的顺序图以及合作图，对两图中相互交互的对象进行分析可以得出系统主要的活动如下： 有关用人单位填写需求表格，然后根据需求表格制定相应的招聘计划，最终将招聘计划上交领导审批。根据领导审批的结果，开始进行人员招聘，人员招聘可以分为内部招聘和外部招聘，其中内部招聘包括部门测试内容，外部招聘包括相应的招聘测试，吧招聘的结果交给领导审批，最终将审批完的员工信息归档。通过分析，可以得到员工招聘管理系统的活动图如图3.6所示。图3.6 员工招聘管理的活动图4. 人才管理系统系统设计与实现4. 人才管理系统系统设计与实现4.1 UML体系结构设计4.1.1 硬件体系结构设计本系统采用C/S结构开发，三层C/S结构是在客户和服务器之间引入应用层的概念，即在客户端与数据库之间加入了一个“中间层”。它将应用逻辑移到应用层完成，而客户端弱化为一个图形用户接口，成为一个瘦客户机。其解决方案是:对这三层进行明确分割，并在逻辑上使其独立形成三层软件结构。在这种结构中，表示层、业务逻辑层和数据访问层在逻辑上是彼此分离的，表示层向用户提供数据，并有选择地允许用户使用逻辑数据。对于基于PC的应用程序来说，本机用户和基于Web的用户接口是其两个主要的用户接口。本机用户接口使用底层操作系统服务，基于Web的用户以HTML为基础，可通过任何平台的浏览器来阅读。本系统的硬件体系结构如图4.1所示。图4.1硬件体系结构图4.1.2 软件体系结构设计信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架，一般呈现多层次结构模式。子系统是对软件进行分解的一种中间形式，也是组织和描述软件的一种方法。软件结构设计就是把软件分解成多个子系统，并确定各子系统及其接口之间的相互关系。员工招聘管理子系统的软件结构如图4.2所示。用户单位员工操作员用户界面员工信息用人单位数据库信息库员工信息存档审查信息人事部门管理审核存档领导批准审核批准用人部门合理分配用户层用户界面层应用层数据库层图4.2 软件体系结构图4.2 对象模型设计经过筛选，得到类与对象：招聘管理菜单，主窗口，主菜单，员工筛选录用，制定需求计划，登记个人简历，审批招聘计划，拟定招聘计划，需求计划，发布招聘公告，由以上的分析过程，建立的对象模型如图4.3所示。图4.3 对象模型图4.3 系统实现4.3.1 组件分析组件可以看作包与类对应的物理代码模块，逻辑上与包、类对应，它实际上是一个文件，可以有源代码构件、二进制构件、可执行构件。构件对外提供的可见操作和属性称为构件的界面。在UML中，组件图描述了组件及组件之间的关系，表示了组件之间的组织