第5章 软件系统分析 总体规划阶段提出了新系统的初步规划,软件系统分析则是根据总体规划所确定的范围,对现行系统进行调查,刻画现行系统的业务流程,确定新系统的基本目标和逻辑功能模型。逻辑功能模型规定了系统应该做什么,与具体的实现技术无关,它根据业务流程分析将业务需求转化为数据流程图。 5.1软件系统分析任务 软件系统分析的目的是研究各个部分如何交互工作以实现系统的最终目标,系统分析阶段重点强调业务问题流程,而非技术实现的层面。系统分析阶段的任务是从现行系统出发,对现行系统进行调查,详细了解每一个业务过程、业务活动以及用户对信息系统的需求。系统分析员首先根据现行系统的功能及存在的问题,运行计算机、管理学等相关知识进行分析,然后对现行系统进行数据流程提取,并用数据流程图进行表示,最后确定出新系统应该具有的逻辑功能模型。 5.1.1软件系统分析的原则 系统分析应遵循3方面原则,即逻辑设计与物理设计分开的原则、面向用户的原则和结构化分析的原则。 1. 逻辑设计与物理设计分开 在传统的系统开发过程中,系统开发人员过早地花费时间和精力选择软硬件配置和处理方法等物理细节,往往到开发后期发现某些不合适甚至没有必要的部分,这不仅容易造成人力、物力和财力等方面的浪费,还会对系统开发造成严重的不良后果。 系统的逻辑设计主要处理独立于任何技术方案的业务需求,是总体设计; 物理设计侧重于描述用户业务需求的技术实现,是在总体设计下的各个局部细节的安排。逻辑设计与物理设计分开是结构化方法的特点之一,在系统分析阶段专注于逻辑设计,有利于保证系统整体的合理性,而系统设计阶段才应该以逻辑设计的结果为依据规划物理设计方案,如图51所示。 图51逻辑设计与物理设计关系图 2. 面向用户 用户是系统开发的源点,用户的参与程度和满意度是关系系统开发成功的关键,新系统的逻辑模型能否满足用户的需求是系统开发工作围绕的核心。在系统分析阶段,只有把用户的需求放在第一位,才能提出合理正确的新系统逻辑模型。尽可能消除交流障碍和误解是系统分析中应该解决的重要问题。 3. 结构化分析 按照系统的观点,客观世界的任何事物都是相互联系的整体。结构化分析的基本思想是用系统的思想、系统工程的方法,按用户至上的原则,自顶向下、逐层分解地分析和设计系统。通过结构化的方法,将系统分析中复杂的大问题分解为若干简单的小问题。 5.1.2软件系统分析的步骤 软件系统分析包括7个执行步骤: (1) 调查现行系统。 对现行系统进行详细的调研,包括系统的功能要求、性能要求、联机系统响应时间、存储容量、安全性要求等,同时调查清楚现行系统的具体业务环节的执行人、执行时间、执行地点、执行目的以及执行方法等。 (2) 分析业务流程。 在详细调查的基础上,用业务流程图(Business Flow Diagram, BFD)刻画和分析具体的业务流程。 (3) 分析数据流程。 在业务流程分析的基础上,抽象和提取流程中的数据传递和依赖关系,并用数据流程图(Data Flow Diagram, DFD)刻画分析的结果。 (4) 确定新系统的逻辑结构。 针对现行系统存在的问题,在业务和数据流程分析的基础上,确定新系统的开发目标和逻辑功能结构,用数据流程图或IPO(Input Process Output)图进行表示。 (5) 分析数据。 对数据进行分析,并设计系统的概念数据模型,同时对实体运用数据存储规划技术进行规范化处理。 (6) 建立数据字典。 建立数据字典(Data Dictionary, DD),对系统中的功能描述运用结构式语言、判断树、判断表等系统分析工具进行定义。 (7) 撰写系统分析报告。 根据上述详细分析的结果,撰写完成系统分析报告。 图52系统分析的步骤 在系统分析过程中涉及不同种类的工具: 在系统概要描述阶段使用业务流程图和数据流程图; 在数据描述阶段使用数据字典; 在数据库逻辑设计阶段使用数据存储结构规范化方法; 在功能详细描述阶段使用结构式语言、判断树和判断表等工具。 5.2软件系统业务流程分析 图53业务流程层次图 业务流程分析是对现行系统详细调查结果进行整理和分析后,用简单方便的、用户能够理解的方法和工具来进行描述和表达,使其成为系统分析人员和用户之间进行交流的媒介和工具。业务流程分析采用自顶向下的方法,即先对高层管理业务进行分析,刻画高程管理业务流程图,再对每一个功能描述部分进行分解,刻画详细的业务流程图,如图53所示。 5.2.1业务流程图的符号 业务流程图包括5种不同含义的符号,具体描述如下: (1) 外部实体,表示业务处理的单位或部门,表达了某项业务参与的人或物。 (2) 数据存储,表示数据存储或存档,是作为档案来进行保存的数据的载体。 (3) 业务处理,表示业务功能描述,一般用简单的祈使句表明业务处理功能,如打印单证、统计数据。 (4) 单证,表示各类单证、报表,是一种数据的载体。 (5) 数据流,表示业务数据的流动和方向,用单箭头表示。 5.2.2业务流程分析方法 以医院管理信息系统的部分业务描述为例介绍业务流程分析方法的步骤和表达。该医院管理信息系统将分为门诊管理子系统、物资管理子系统、住院管理子系统、人事管理子系统、财务管理子系统、数据分析子系统以及开放给患者和社会的患者服务系统。各个子系统之间进行相关数据的共享,可以更加高效地服务患者。 5.2.2.1门诊管理系统业务描述 门诊部是医院对外提供医疗服务的主要窗口,医院门诊部的服务质量和效率很大程度上决定了医院的服务水平和效率,门诊管理系统将以患者信息为核心、诊疗流程为主线,以经济核算为基础,对患者信息(包括挂号信息与诊断信息)、缴费、药品信息进行规范化管理。门诊业务流程分为普通门诊与急诊,对于普通门诊病人,处理过程如下: 首先,病人需要挂号,挂号系统分为线上挂号和线下挂号。线上挂号流程为: 病人网上预约挂号,预约成功后网上预约系统向患者手机上发送预约成功短信,病人利用第三方支付平台进行网上缴费,病人就诊时到挂号处领取病历本和医疗卡。线下挂号流程为: 病人来到医院挂号处排队等待挂号,挂号处工作人员根据病人的病情描述为他们选择相应的诊疗科室和门诊医生,并填写好病历本基本信息,发放医院医疗卡。病人缴纳挂号费后,排队等待叫号就诊。医生根据病人的病症做出基本判断,为病人开具药方或要求病人去各检查科室进行检查。病人做完检查后,将检查结果反馈给主治医生,医生再次诊断后出具诊断结果,填写病历本,储存病历电子档。为了方便管理,病人需要将现金储存在医疗卡中,先到收费处划卡缴费,然后携带收据去药房开药或去各检查科室做检查。 对于急诊病人,先对急诊病人进行基本检查,根据检查结果进行急诊处理,病人缴纳费用,最后由医生补写病历。 1. 急诊业务流程图 对急诊病人进行急诊检查与处理,并对病历进行存档,如图54所示。 图54急诊业务流程图 2. 门诊业务流程图 门诊业务实现病人挂号、就诊、检查、缴费管理,对病人病历进行存档,如图55所示。 图55门诊业务流程图 3. 挂号业务流程图 挂号业务分为线上挂号与线下挂号,实现病人挂号管理和挂号费缴纳,如图56所示。 图56挂号业务流程图 4. 缴费业务流程图 缴费业务实现病人医疗卡充值,划卡消费管理,对缴费收据进行存档,如图57所示。 图57缴费业务流程图 5.2.2.2住院管理系统业务描述 医院住院管理系统包含三个子管理系统,分别是出入院管理子系统、诊治管理子系统、医疗资源调用管理子系统。出入院管理子系统: 患者需要住院治疗时,必须由门诊医生签发入院通知卡(含患者姓名性别年龄职业工作单位及家庭详细地址和诊断),住院部收到入院通知卡后,结合床位等医疗资源信息办理入院手续并对患者信息和医疗资源信息进行更新存档(含床位、医保等住院信息),住院部通知临床科室接受患者,患者入院。对于危重患者经医师许可,须立即入院抢救的,可送入病房后办理入院手续。患者出院由主治医生提出,上级医师或科主任同意后,于出院前一日下医嘱,完成出院手续。对于转院,应逐级办理审批手续,写病情报告。或由患者或者家属提出申请书,经医务科同意后转院。诊治管理子系统: 主管医生接到住院部通知后,对患者进行检查,做病程记录,下医嘱,开处方。对于夜间入院患者,值班医生接诊,在当班内完成病程记录,次日向主管医生交班。对于其他科患者误收本科,由接诊医生完成入院记录、病程记录、转科记录。住院医师查房,并核对查房记录、提出查房建议、检查医嘱完成情况并对信息进行存档。主管医生提出会诊要求,填写病程记录,经上级医师同意后送出。对会诊人员,结果进行存档。主治医生制定治疗方案,开医嘱。医疗资源调用管理子系统: 根据患者的病情和医技科室提供的资源清单,主管医生制定治疗方案,相关科室和相关医生协同治疗,主管医生完成治疗记录,将记录保存到患者的病程记录中。 1. 资源调用管理业务流程图 患者提交基本信息表,经过出入院管理、诊治管理和医疗资源管理等业务流程直至退出住院管理系统业务,如图58所示。 图58资源调用管理业务流程图 2. 出入院管理业务流程图 主管医生、值班医生和查房医生共同完成病程记录,此外主管医生根据患者病情发起会诊,整理会诊记录并存档,如图59所示。 图59出入院管理业务流程图 3. 诊疗记录管理子系统 主管医生结合病程记录和医疗资源信息制定诊治方案,治疗后对病程记录和医疗资源信息存档更新,如图510所示。 图510诊疗记录管理业务流程图 5.2.2.3人事管理系统业务描述 医院人事管理系统是医院合理用人、配置人力资源的重要系统。在系统开发中就要求系统能够合理并最大限度地实现人力资源的价值、提高员工工作效率和医院经济效益、降低人力资源成本。医院应以此系统为中心实现全员各部门计算机网络的信息共享,为医院领导的决策提供翔实的依据。 人事管理信息系统实际上是医院各项管理系统中的一个职能域,是医院信息系统的一个子系统。人事管理的业务流程(见图511)是: 人员招聘前,各科室将需要人才数量上报管理层,管理层审批后由人事部进行招聘和审核。新任命的员工填写员工登记表,审核后由人事部门录入信息,检查准确无误后存档。实习人员填写实习登记表,审核后由人事部门录入信息,检查准确无误后存档。每年各科室要进行人事考核,人事考核信息要进行存档,并将统计报表上交管理层。各科室每月要将月计划表上交人事部,业务执行计划准确无误后进行存档。每月的业务信息要进行管理,各科室将每月业务汇总后上报人事部,人事部进行统计并存档,后期用于人员考核。考核后结算的工资要进行统计并存档,后期交给财务部门。所有员工都要进行考勤登记,各科室将考勤记录表上报人事部门,统计后存档后期用于人员考核。对于合同到期和退休人员需要填写登记表,审核后交给相关人员。 图511人事管理业务流程图 5.3软件系统数据流程分析 对软件系统进行业务流程分析后会发现,并非所有的业务处理都会产生数据,并非全部的业务环节都需要由计算机来完成。在业务流程分析的基础上,需要提取可由计算机完成的业务活动,通过数据流程图来表示各环节产生的数据的存储、处理及其流向。 5.3.1数据流程图的符号 数据流程图包括4种不同含义的符号,具体描述如下: (1) 外部项(外部实体),是数据的来源和流向目的地。 (2) 静态的数据存储,是数据库的逻辑描述。 (3) 数据流,表示数据的输入或输出,表明了数据的动态流向,数据流的上方需要标注数据流的名称。 (4) 处理功能,表示对数据进行加工处理的逻辑功能。 1. 外部项 外部项(又称为外部实体)表示不受系统控制的、系统以外的人或部门,它表达了该系统数据处理的外部来源和流向的目的地。某些情况下,为了避免在同一张数据流程图中出现线条交叉的现象,同一个外部项可以在一张数据流程图中的不同位置出现多次。 如图512所示,医院管理系统中的门诊业务数据流程图中两次出现了“患者”这一相同的外部项。 图512外部项描述示例 管理信息系统涉及的外部项应该较少,如果外部项过多,则说明系统缺少独立性。 2. 数据存储 数据存储是用来保存数据的地方,它既不是指数据保存的物理地点或物理存储介质,也不是指文件箱、磁盘或磁带,而是指数据存储的逻辑描述,即数据库的逻辑描述。为避免数据流程图中线条的交叉,同一个数据存储可以在一张数据流程图中的不同位置出现多次。在数据流程图中,处理逻辑和处理逻辑之间尽量避免有直接的箭头联系,这时可通过数据存储进行衔接,既可以提高每个处理逻辑的独立性,又减少了系统的重复性。例如,图513中的“记录考勤”和“计算工资”两个处理逻辑通过“职工考勤”数据存储来衔接。 图513数据存储示例 数据流程图中常见的数据存储分三种类型: 数据流入型、数据流出型、数据更新型。 (1) 数据流入型表示向数据存储存入数据,即向数据存储写入数据。 (2) 数据流出型表示从数据存储读取数据。 (3) 数据更新型表示从数据存储读取数据,经系统修改后又重新存入数据存储中,即更改数据存储中的数据。 3. 数据流 数据流图中的数据流应该在其上方标明数据流的名称,如图514所示。 可能的数据流向有下列4种形式: (1) 外部项向系统流入数据,如图515所示 。 (2) 系统向外部项输出数据,如图516所示。 (3) 数据存储可采用双箭头,如图517所示。 (4) 向处理传送数据,经处理后生成新的数据,如图518所示。 图514数据流示例 图515输入数据 图516输出数据 图517数据存储 图518传送数据 当数据流表示的含义很明显时,其上的名称可以省略。 绘制数据流时应该注意: 数据流必须有一端与处理功能连接; 不能从外部实体直接到外部实体; 不能从数据存储直接到外部实体或从外部实体直接到数据存储; 不能从数据存储直接到数据存储。 4. 数据处理功能 图519数据处理功能 处理功能,表示对数据处理的逻辑功能,即把流向它的数据进行一定的变换处理,生成新的数据,如图519所示。 其中的“标识”用来标明处理功能,以区别于其他处理; 既可用单纯的数字 表示,也可用字母P加数字表示,标明它的层数,如图520中的P1、P1.1、P1.1.1、P1.1.2分别表示位于第1层、第2层和第3层的处理功能。 图520数据处理分层 其中的“功能描述”应有唯一的名称,是处理功能中必不可少的组成部分,要用简单的祈使句来表示这个处理所要完成的事情。祈使句应是“动词+名词”的形式,如图521中前3个是正确的处理功能描述,后2个功能描述是不标准的。 图521处理功能描述 “功能执行者”表示完成功能的角色,可以是人、部门或计算机程序。 在数据流程图中,处理逻辑必须要有输入/输出的数据流,可有若干个输入/输出的数据流,但不能只有输入或只有输出的数据流,例如图522中前2个是正确的处理功能,而第3个处理功能只有输入数据流,第4个处理功能只有输出的数据流,因此都是不正确的表示方法。 图522数据流 5.3.2数据流程分析方法 数据流程图是用来反映系统中各项业务过程或业务活动之间的错综复杂的数据流通、加工、交换关系,以及数据处理之间的相互制约关系。数据流程图中不考虑具体的组织机构、工作场所、物流、资金流等,只考虑数据的加工、存储、流动或使用情况,它可以使系统分析员抽象地总结出新的信息系统的任务以及各项任务之间的关系。 5.3.2.1数据流程图绘制步骤 进行数据流程分析的第一步是确定外部项,然后画出顶层数据流图(即TOP图),最后细化分支数据流图。TOP图应该概括地反映出信息系统最主要的逻辑功能、最主要的外部项、输入和输出数据流、数据存储内容应尽可能少。如图523是TOP图示例。 图523TOP图示例 细化数据流程图是逐层扩展的数据流程图,是指对上一层中的每个处理逻辑分别加以扩展。需要注意的是,下一层的输入和输出数据流至少要和上一层的输入和输出数据流相对应,下一层的外部项至少要和上一层的外部项相对应。输入/输出数据流、外部项只能增加,不能减少,并且每一层的数据流程图中的处理逻辑不宜过多,如图524~图526所示。 图524一级细化数据流程图 图525二级细化数据流程图 图526三级细化数据流程图 5.3.2.2医院管理信息系统TOP图 以医院管理信息系统业务中的数据流向、存储和处理为例介绍数据流程分析方法的步骤和表达。医院与处理,对检查结果、病历和缴费收据进行存档。检查结果反馈给医生,医生根据结果进行处理。系统顶层数据流程图将具体展现患者、医生以及各个医院部门等外部实体与该医院管理信息系统之间的数据交换,同时说明各个子系统之间是如何进行数据传输、共享以及它们之间是如何相互协调,分工合作。图527描述了医院管理信息系统的高层数据流程图。 图527医院管理信息系统TOP图 5.3.2.3资源调用管理数据流程图 总的数据流程图包含P1(出/入院管理)、P2(诊治管理)和P3(医疗资源调用管理)3个层次的数据流程图,如图528所示。 图528资源调用管理数据流程图 5.3.2.4医保患者就医数据流程图 具有医保卡的患者在就医时,其信息与医保政策实时更新发给各部门以便记录与查询,如图529所示。 图529医保患者就医数据流程图 5.3.2.5医保项目报销数据流程图 普通医保业务与特殊医保业务报销时相关信息在系统中的流动、存储、加工和流出的具体情况,如图530所示。 图530医保项目报销数据流程图 5.3.2.6人事管理系统数据流程图 人事管理系统数据流图流程为: 人员招聘前,各科室将需要人才数量上报管理层,管理层审批后由人事部进行招聘和审核。新任命的员工填写员工登记表,审核后由人事部门录入信息,检查准确无误后存档。实习人员填写实习登记表,审核后由人事部门录入信息,检查准确无误后存档。每年各科室要进行人事考核,人事考核信息要进行存档,并将统计报表上交管理层。各科室每月要将月计划表上交人事部,业务执行计划准确无误后进行存档。每月的业务信息要进行管理,各科室将每月业务汇总后上报人事部,人事部进行统计并存档,后期用于人员考核。考核后结算的工资要进行统计并存档,后期交给财务部门。所有员工都要进行考勤登记,各科室将考勤记录表上报人事部门,统计后存档后期用于人员考核。对于合同到期和退休人员需要填写登记表,审核后交给相关人员,如图531所示。 图531人事管理系统数据流程图 5.3.2.7患者服务系统数据流程图 该数据流程图将展示患者服务系统在实现充值、查询、在线购药等功能时,系统内部是如何进行数据交换的,如图532所示。 图532患者服务系统数据流程图 在绘制数据流程图时,应注意检验其与对应的业务流程图以及检验数据流图之间的一致性,注意画图时的细节问题。 检验数据流程图与业务流程的一致性。 按照“自顶向下”的原则进行检验; 将数据流程图与相应的业务流程图进行对比检查,看是否有遗漏的数据处理功能; 有关数据载体部分要与业务流程图一致。 检验数据流程图的一致性和完整性。 检查外部实体、数据流、数据存储、处理逻辑以及数据流程图之间的一致性; 在高层数据流程图中出现的外部项、数据流和数据存储一定要在低层的数据流程图中出现。 画图时的注意事项。 画图的时候,先从左侧开始标出外部项,左侧的外部项通常是系统主要的数据输入来源。画出由该外部项产生的数据流和相应的处理逻辑,如果需要将数据保存,则标出其数据存储。接收系统数据的外部项一般画在数据流的右侧。 数据流程图与程序框图的区别。 数据流程图完全不反映时间的顺序,只反映数据的流向、自然的逻辑过程和 必要的逻辑数据存储,不反映起始点也不反映终止点; 不反映任何与计算机有关的专业技术; 程序框图有严格时间顺序,有起始点和终止点,可以反映循环过程和条件判断。 5.4软件系统处理功能的表达 处理过程对数据的加工和处理包括数学运算、数据交换以及逻辑判断。其中的数学运算和数据交换可以使用精确的语言进行表达,而逻辑判断可能涉及部分非精确、意义模糊的描述,这可能会导致处理过程描述时出现界限不明确、逻辑条件次序不清晰和意义模糊词语的出现等现象。这不利于系统逻辑模型的构造和与用户进行有效的交流。因此,结构化分析中采用了一些有利于系统分析人员与用户的表达和理解的工具,比较典型的包括结构式语言、判断树和判断表。 5.4.1结构式语言 结构式语言是介于自然语言和程序设计语言之间的语言。程序设计语言的优点是严格精确,但专业性太强不易被用户接受; 自然语言的优点是容易理解,但不够精确,易于产生二义性。结构式语言是由程序设计语言的框架(顺序结构、分支结构和循环结构)和自然语言的词汇(如动词和名词等)组成。 结构式语言具有易于编写,并且可以简明地描述较复杂的处理逻辑功能的特点。结构式语言可以使用的词汇包括3类: 祈使句中的动词。 数据字典中已定义的名词。 常用的运算符、关系符等保留字。 结构式语言使用4类语句,即简单祈使句、判断语句、循环语句和复合语句。 1. 祈使句 祈使句是指要做什么事情,它至少包括一个动词,明确地指出要执行的功能,至少包括一个名词作为宾语,表示动作的对象,例如: 统计评价信息、审批购药申请、处理预约。祈使句中尽量简短,不要使用形容词和副词。 例51假设有如下自然语言描述的场景。 某患者到医院首先选择一个自己对症的科室,然后携带诊断书到药房,请药剂师开票,到收银台交款,再回到药房,盖付款标记,然后取药离开医院。 用结构式语言描述如下: (1) 选择科室。 (2) 携诊断书到药房。 (3) 开票。 (4) 交款。 (5) 盖付款标记。 (6) 取药。 (7) 离开医院。 每一条都是祈使句,并按顺序显示出7个步骤,步骤中没有包括任何主 观的决策或条件,仅按次序列出; 每一步骤都有特定的次序,如果打乱了顺序,则看病买药过程就不成立; 对处理过程的描述必须指出行动的正确次序。 2. 判断语句 判断语句类似于结构化程序设计中的判断结构,它的一般形式如下: 如果条件1(成立) 则 动作A 否则(条件1不成立) 就 动作B 例如,对学生成绩等级评定使用上述结构表示如下: 如果 100>=成绩>=90则 等级定为“优” 如果 成绩>=80则 等级定为“良” 如果 成绩>=70则 等级定为“中” 如果 成绩>=60则 等级定为“及格” 如果 成绩<60则 等级定为“不及格” 3. 循环语句 循环语句指在某种条件下,连续执行相同的动作,直到这个动作不成立为止; 它还可以明确地指出对每一种相同的事务,都执行相同的动作,其一般形式为: 如果条件满足则循环执行 例52医生给患者挂号时,通常连续、重复地对每个患者病历手册做登记、分配科室,其结构式语言描述如下: 如果存在待挂号的患者则执行 登记病历手册 分配科室 4. 结构式语言注意的问题 (1) 所有的语句必须力求精练,具有较高的可读性,做到言简意赅,清晰准确,不要使用修饰或漫谈的形式。 (2) 祈使句中必须有一个动词,明确地表达执行的动作,但不要使用“做”“处理”“控制”之类的动词。描述功能中避免使用界限不明确的、含义模糊的或逻辑次序不清晰的词语。 (3) 祈使句中必须包括至少一个宾语,以明确地指出要做的事情,所有的名词必须在数据字典中已经定义。 (4) 不要使用形容词和副词。 (5) 在同一个系统中不要使用各种意义相似的动词,即只确定其中一个动词表达同一个意思。如: “修正”“修改”和“改变”意义相似,在确定使用“修改”这个动词后,就不要再使用其他意义相似的动词。 (6) 判断句中的“如果”和“否则”要成对出现,每一层次要对齐。 5.4.2判断树 如果某个动作的执行依赖于多个条件的话,则用结构式语言表示动作就需要多层的判断嵌套结构,而使逻辑表示不够清晰。因此,需要使用新的功能处理表达工具——判断树。 判断树是用树型图形来表示多个条件、多个取值所应采取动作的方式。判断树自左向右画,判断树的最左端是树根,它是决策序列的起点(决策名称); 右边是各个判断分支,即每一个条件的取值状态; 最右端(树叶)为应该采取的策略(即执行动作)。树中的非叶结点代表条件,它指出必须在能够选择下一条路线之前作出决定,查看条件是否满足,并依据条件作出决策。树的叶结点表明要采取的行动,这种行动依赖于它左边的条件序列。从树根开始,自左至右沿着某一个分支,能够做出一系列的决策。 例53假设某企业年终奖类别及具体评选条件如下: 优秀员工奖金 优秀员工一等奖金比例为4%,奖金金额为15000元; 优秀员工二等奖金比例为7%,奖金金额为10000元; 优秀员工三等奖金比例为18%,奖金金额为6000元。 获奖条件如下: 优秀员工一等奖金,绩效评分在85分以上; 优秀员工二等奖金,绩效评分在78分以上; 优秀员工三等奖金,绩效评分在68分以上。 有3个处理动作,即最后发放的奖金金额。 在如图533所示绘制的判断树中,G代表绩效评分,PX代表综合考评排序号。Di代表第i等奖金名额,Di=int(奖金等级比例×员工人数)。 图533奖金政策的判断树表示图 根据示例,思考如下物流公司收费政策判断树。 例54某物流公司的收费标准如下: 收费地点在本省,则快件每千克8元,慢件每千克6元。 收费地点在外省,则在30千克以内(含30千克)快件每千克12元,慢件每千克10元; 如果超过30千克时,则快件每千克14元,慢件每千克12元。 请根据上述要求,绘制确定收费标准的判断树。 当系统本身太复杂时,会存在许多步骤和组合条件的序列,结果系统的规模可能因为分支的数目和路径太多而难以控制,以致出现条件遗漏的情况。如例55中的情况。 例55某工厂人事部门对职工分配工作原则: 如果年龄不满20岁: 文化程度是小学,则脱产学习。 文化程度是中学,则当电工。 如果年龄满20岁但不满40岁: 如果文化程度是小学或中学,若是男性,则当钳工; 若是女性,则当车工。 文化程度是大学,则当技术员。 如果年龄满40岁及以上者: 文化程度是小学或中学,则当材料员。 文化程度是大学,则当技术员。 该例可以用判断树表示。如图534所示,由于本例中的条件 复杂,致使判断树表示的逻辑性不强,可读性也不够理想。 图534分配政策的判断树表示图 5.4.3判断表 鉴于结构式语言和判断树各自应用范围和表现形式的局限性,系统分析功能处理还可采用另外一种工具,即判断表。 将例55的用工政策进行分析,该政策涉及3类判断条件,即年龄、性别和文化程度; 其中年龄有3个可能取值区间,性别有2个可能取值,文化程度有3个可能取值,不同条件下的取值如表51所示。 表51用工政策条件/取值表 条 件 名 称取值含义 性别0 1男性 女性 年龄0 1 2未满18岁 满18岁但不满40岁 满40岁以上 文化程度0 1 2小学毕业 中学毕业 大学毕业 通过概率统计知识可以知道,表51中有18种条件组合,即2×3×3=18。该用工政策可能的用工结果包括“脱产学习”“当钳工”“当电工”“当车工”“当材料员”和“当技术员”。将18种条件组合通过判断表的形式进行表示,如表52所示,表中Ci(i=1,2,3)表示不同条件、Ai表示用工结果(i=1,2,…,6)。 表52用工政策条件表 123456789101112131415161718 C1: 性别 C2: 年龄 C3: 文化程度 A1: 脱产学习 续表 123456789101112131415161718 A2: 当电工 A3: 当钳工 A4: 当车工 A5: 当技术员 A6: 当材料员 根据表51中的值对表52中的条件进行组合标注,如表53所示。 表53用工政策条件组合表 123456789101112131415161718 C1: 性别000000000111111111 C2: 年龄000111222000111222 C3: 文化程度012012012012012012 A1: 脱产学习 A2: 当电工 A3: 当钳工 A4: 当车工 A5: 当技术员 A6: 当材料员 对每一种条件组合应执行的用工结果在对应位置标注符号“×”,如表54所示。 表54用工政策初始表 123456789101112131415161718 C1: 性别000000000111111111 C2: 年龄000111222000111222 C3: 文化程度012012012012012012 A1: 脱产学习× × A2: 当电工 × × A3: 当钳工 ×× A4: 当车工 ×× A5: 当技术员 × × × × A6: 当材料员 ×× ×× 从表54中可以看出,表中第3列和第12列的条件组合没有相应的用工结果,说明该政策遗漏了年龄未满20岁,但文化程度是大学的男性或女性职工这种情况的分配。根据分析结果,应通知用户对这种遗漏进行弥补,重新修改用工政策。 本例中修改后的政策为: 如果出现这种情况,则不论男性或女性,都分配当技术员,修改后的结果如表55所示。 表55用工政策修改表 123456789101112131415161718 C1: 性别000000000111111111 C2: 年龄000111222000111222 C3: 文化程度012012012012012012 续表 123456789101112131415161718 A1: 脱产学习× × A2: 当电工 × × A3: 当钳工 ×× A4: 当车工 ×× A5: 当技术员 × × × × × × A6: 当材料员 ×× ×× 列出包括全部条件组合的修改表以后,还需要采取适当的办法对判断表进一步进行化简。化简的方法按条件进行合并,例如表55中第1列和第10列年龄和文化程度两个条件取值相同的情况下,性别的全部取值对应的结果都是A1(脱产学习),则可以将第1列和第10列进行合并,同理,可将第2列和第11列,第3列和第12列,第6列和第15列,第7列和第16列,第8列和第17列,第9列和第18列进行上述合并。简化合并后的结果如表56所示。 表56用工政策简化表 1/102/113/12456/157/168/179/181314 C1: 性别///00////11 C2: 年龄00011122211 C3: 文化程度01201201201 A1: 脱产学习× A2: 当电工 × A3: 当钳工 ×× A4: 当车工 ×× A5: 当技术员 × × × A6: 当材料员 ×× 例55用工政策判读表表示的最终简化结果如表57所示。 表57用工政策判断表结果 123456789 C1: 性别///00//11 C2: 年龄000112211 C3: 文化程度012010101 A1: 脱产学习× A2: 当电工 × A3: 当钳工 ×× A4: 当车工 ×× A5: 当技术员 × A6: 当材料员 ×× 5.4.4三种表达工具的比较分析 在对系统分析处理功能进行描述时,可以选择结构式语言、判断树和判断表中的任意一种工具,而这三种工具适合不同的场景,在很多情况下也会被交替结合使用。从不同角度对三种工具的特点总结如下: 从作为程序设计资料的角度看,结构式语言和判断表最好,而判断树最弱。 从逻辑验证的角度看,判断表最好,因为它可以通过条件组合考虑到所有可能的情况; 结构式语言次之; 判断树不如前两项工具。 从直观表达判断逻辑结构的角度看,判断树最好,因为它能够借助图形表示,便于用户理解,直观性强; 结构式语言次之; 判断表的直观表达能力最弱。 从可修改性的角度看,结构式语言的可修改性最高; 判断树次之; 判断表的可修改性最弱。 从工具掌握难易的角度看,判断树最易于被掌握; 结构式语言次之; 而判断表的难度最高。 5.5软件系统分析实践案例 5.5.1软件系统功能结构图 在第三方物流管理信息系统中,有如下功能: 在入库管理子系统中,能查询剩余库存,安排存放,以及符合更新货物信息; 在出库管理子系统中,能查询货物仓位,装货打包,以及复合更新货物信息; 在配送管理子系统中,能进行车队信息管理与考核,订单分配与车辆分配,以及货物跟踪; 在结算管理子系统中,能进行上下游客户财务结算,查询业务收支,以及查询审计业务账单; 在客户管理子系统中,能对客户的基本信息进行管理,客户的信用等级进行评定,以及查询销售业绩; 在订单管理子系统中,能对订单信息进行管理、查询和修改,订单信息转换、确认和打印,以及交接单信息管理; 在人力资源管理子系统中,能对人力资源进行规划,人员分配、培训和考核,以及薪酬福利管理; 在系统管理子系统中,能对系统进行维护和运行管理,如图535所示。 图535软件系统功能结构图 5.5.2业务流程图 5.5.2.1结算管理子系统业务流程图 工作人员通过结算功能得到承运人结算单,交由审计人员进行审核,确认无误后打印承运人业务账单,交由财务处向承运人付款; 工作人员通过结算功能得到需缴费的客户订单列表,通知客户缴费,待客户交费成功后更新订单信息库; 财务人员通过业务查询功能实时查询订单信息; 审计人员实时审核订单信息,对问题订单筛选处理并及时更新订单信息库; 客户通过查询功能查询该公司的相关业务种类和收费标准,如图536所示。 5.5.2.2客户管理子系统业务流程介绍 客户填写基本信息登记表并成功提交后,通过信息管理功能录入客户信息库,当需要更改个人及组织信息时,提交变动申请,通过信息变动管理功能及时更新客户信息库; 运营部提交客户合同明细录入客户信息库,财务部提交客户缴费情况,通过信用评定功能对客户的信誉进行评定并录入客户信息库; 相关部门通过信用等级查询功能获得客户的信誉等级; 运营部及时将客户信息分类归档,按工作性质和工作需求分别提交至各个部门; 客户提交查询要求申请,通过查询功能获得本人或本组织的业绩统计报表,了解自身产品的销售情况,如图537所示。 5.5.2.3出库管理子系统业务流程图 货物出库从仓库主管接收提货单,根据系统的库存信息,查询出对应的货物仓位信息,将货物仓位信息传输给仓管员,仓管员下发任务到运输员和卸装工,进行拣货打包和车辆安排,在货物完成出库之后,仓管员对仓库货物进行检查,复核商品信息,并进行存储,便于结算此次出货账单和下次的货物信息查询,如图538所示。 5.5.2.4订单管理子系统业务流程图 运营部把收到的全部订单进行分类规整,然后把订单的信息录入到公司的信息管理系统并进行存档。如若遇到订单信息变更,运营部会及时把订单信息进行更新并重新存档,并在对订单信息进行确认无误后把新的订单信息按照顾客的需求按照一定的形式打印出来。当然,运营部还可以随时对公司的订单按照日期、客户等进行查询来获取所需信息。除此之外,运营部还负责订单向运单核交接单的转化以及对应信息的管理,把订单上的信息转换为运营部等对应交接部门需要进一步执行的计划,如图539所示。 5.5.2.5人力资源管理子系统业务流程图 人事处通过招聘需求分析制定公司的招聘计划并严格执行,然后对录取人员的信息进行汇总分析以及对人员定岗定编确定录取人员的劳工合同书的具体内容。劳工合同书里应包括公司人员的薪酬管理制度和人员培训制度以及二者的详细执行情况。除此之外,人事处还负责公司人员的绩效考核以及其他人力资源规划,二者的具体流程为先制定计划书、然后实施计划、最后对计划的反馈信息进行整理和分析,如图540所示。 图536结算管理子系统业务流程图 图537客户管理子系统业务流程图 图538出库管理子系统业务流程图 图539订单管理子系统业务流程图 图540人力资源管理子系统业务流程图 5.5.2.6配送管理子系统业务流程图 配送中心对旗下车辆有实时的信息统计并储存车辆信息(一般情况驾驶员和车辆是二对一配对的),顾客通过各类平台下单之后汇总给配送中心,配送中心开始受理业务,配送中心对订单进行始发地、目的地、重量、体积等进行统计,产生每一个订单的配送计划,由系统自动地进行车辆和线路和装车的安排; 装车完毕后,进行送货单打印,同时对货物进行实时的跟踪; 在货物到达目的地后,经收货方确认,凭回单向物流配送中心确认; 车辆每完成一次配送就要对车辆进行一次考核,如图541所示。 图541配送管理子系统业务流程图 5.5.2.7信息维护子系统业务流程图 管理员填写基本信息表并且提交成功以后,系统通过识别管理员信息自动对管理员进行分类; 当需要变动个人信息时,需要提交修改信息申请,通过管理员信息变动管理及时更新完善管理员信息库。管理员可以通过这样的方式改密码。管理员收集各部门提交的数据报表,提交给系统自动处理,构成系统数据库。管理员每天都要对今日数据进行筛选备份,提交筛选要求以后,系统进行数据筛选,生成备份数据库。也可以将客户需求提交,经过需求分析处理,对系统数据库进行数据挖掘得出有用的信息报表反馈给客户,如图542所示。 图542信息维护子系统业务流程图 5.5.3数据流程图 5.5.3.1高层数据流程图 在图543中仅存在8个外部实体,分别是工作人员、承运人、客户、财务部、运营部、市场部、运输部和信息处。其中,工作人员通过信息维护子系统和配送管理子系统与客户构成联系; 工作人员通过结算管理子系统与承运人相联系; 工作人员通过客户管理子系统分别与财务部和市场部构成联系; 工作人员通过入库管理子系统和客户管理子系统与运营部构成联系; 工作人员通过订单管理子系统和出库管理子系统与运输部构成联系; 工作人员通过人力资源管理子系统与信息处相联系。 5.5.3.2结算管理子系统数据流图 工作人员输入查询要求,通过订单结算处理得到承运人账单和客户收款信息,承运人账单经审核无误后,向承运人支付尾款; 将客户收款信息传给需交费的客户,交费成功后更新订单信息库内容; 财务人员输入查询要求,可以从订单信息库中调取需要查询的业务; 客户输入查询要求,可以从订单信息库中查询属于自己公司产品的销售情况,如图544所示。 5.5.3.3客户管理子系统数据流图 运营部将客户合同中有关客户信息整理并上传至客户合同管理系统,经过进一步处理后储存并更新客户信息库。财务部将客户缴费情况整理并上传,经由信用分析及信誉评定功能,将客户信誉信息上传至客户信息库。客户填写个人基本信息,并储存在客户信息库,如需修改个人信息,提交修改申请,审核通过后更新信息库。相关部门可以通过查询客户信息数据库获得客户的信用等级信息,经分类归档管理功能,财务部得到客户收支信息流,运营部得到客户订单信息流,市场部得到客户业务信息流。客户通过递交查询申请,可以获得本公司产品销售详情数据,如图545所示。 5.5.3.4入库管理子系统数据流程图 在入库过程中,仓库主管收到客户订单后,在产品记录里查找产品,然后在客户记录里,对客户进行信贷检查,合格,则接单入库,否则拒绝并通知客户。接单入库后,生成入库单交给仓管员进行仓位处理,再生成仓位单,交给装卸工进行卸货存放。之后仓管员复合货物信息,接着进行货物的残损处理。最后进行库存处理,并同时在库存记录中更新货物信息,如图546所示。 5.5.3.5出库管理子系统数据流图 在出库过程中,仓库主管首先接收到提货单,进行仓位查询,并将提货单传送给仓管员,仓管员进行复核查询处理得出实际货物仓位单,装卸完成之后,仓管员进行仓库货物检查,整理出发货单、损坏过期单和仓库余货单、顾客余货单,并进行数据存储,便于仓库主管的下次查询根据以上功能流程做出数据流程图(图547)。 5.5.3.6订单管理子系统数据流程图 在图548中存在4个外部实体,分别为运营部、信息部、运输部和客户。操作共有五项: P1: 订单信息统计录入,产生原始订单信息; P2: 信息修改,产生更新订单信息; P3: 订单转换管理,产生交接单信息; P4: 信息查询,产生目标订单信息; P5: 打印订单,产生订单。其中,运营部通过P1、P2、P3和P4四项操作与信息部和运输部构成联系,运输部通过操作P5与客户相联系。 图543高层数据流程图 图544结算管理子系统数据流程图 图545客户管理子系统数据流程图 图546入库管理子系统数据流程图 图547出库管理子系统数据流程图 图548订单管理子系统数据流程图 5.5.3.7人力资源管理子系统数据流程图 在图549中仅存在两个外部实体,即人事处和信息处。在这两个实体间存在9项操作。P1: 招聘需求分析,产生招聘执行计划; P2: 招聘实施,产生录取信息; P3: 定岗定位,产生劳工合同; P4: 绩效考核,产生考核计划; P5: 人力资源规划,产生人力资源规划书; P6: 薪酬管理,产生薪酬福利信息; P6: 薪酬管理,P7: 绩效考核实施,P8: 人员培训,P9: 规划书实施,这4项共同生成反馈信息。 5.5.3.8配送管理子系统数据流程图 在配送过程中,在顾客下单和供应商接单之后提交到配送中心,配送中心进行业务受理,开始订单汇总和订单分配,并将订单信息和配送方案存储,同时进行货物跟踪并实时提交给信息部,信息部将物流信息反馈给顾客和供应商,如图550所示。 5.5.3.9系统维护子系统数据流程图 管理员提交数据报表给系统,系统处理分类后对数据进行存储,数据流向系统数据库; 提交筛选要求,系统对数据进行筛选,生成备份数据报表,同样进行分类归档处理,最后数据备份流向备份数据库; 当系统出现故障需要数据恢复时,备份数据库的数据通过数据恢复功能流向系统数据库; 管理员还可以提交用户需求,进过系统评定的需求流向数据挖据功能,最后得出数据反馈表反馈给客户,如图551所示。 5.5.4软件系统操作流程图 5.5.4.1总系统操作流程图(用户视角) 用户在登录系统后,可以实现如下操作: 在结算操作流程下,用户可以查询承运人和客户的已结算的明细表; 在客户操作流程下,用户可以查询客户的信贷情况; 在出入库操作流程下,用户可以查询货物订单、仓库库位、货物残损以及库存信息; 在订单操作流程下,用户可以更新和查询订单信息,也可进行订单转换; 在人资操作流程下,用户可以查询招聘信息,人员岗位信息,绩效考核信息,薪酬福利信息,以及人力资源规划信息; 在维护操作流程下,用户可以修改密码,提交、备份数据,以及查询数据; 在配送操作流程下,用户可以统计订单和车辆的信息,如图552所示。 图549人力资源管理子系统数据流程图 图550配送管理子系统数据流程图 图 551系统维护子系统数据流程图 图552总系统操作流程图(用户视角) 5.5.4.2结算管理子系统操作流程图(用户视角) 工作人员注册账号并通过身份认证获得权限,登录成功后,可以查询已结算承运人明细表,如果存在未支付的合同,交由审计人员进行审核,确认无误后打印承运人业务账单,交由财务处向承运人付款; 也可以查询已结算客户订单列表,如果存在未交费的客户,联系客户缴费,待客户交费成功后更新订单信息库,如图553所示。 图553结算管理子系统操作流程图(用户视角) 5.5.4.3客户管理子系统操作流程图(用户视角) 客户可以填写个人信息并注册,成功登录后,可以查询本公司商品的销售和物流情况,得到业绩报表,当需要更改个人或组织信息时,提交变动申请,成功后修改更新个人信息; 工作人员可以进行注册并验证身份,获得相应权限,登录成功后,可以查询客户信用等级、收支情况、订单详情、业务详情等信息,并得到相关明细表,如图554所示。 图554客户管理子系统操作流程图(用户视角) 5.5.4.4入库管理子系统操作流程图(仓库主管视角) 仓库主管登录仓储系统,对客户的信贷进行查询,系统生成客户信贷表,若不合格,则拒绝接受订单,并同时告知客户; 若合格,则接单入库。仓库主管对入库货物订单的详细信息、仓库库位剩余情况、入库过程中的货物残损情况,以及哪位员工在搬运货物的过程中对货物有残损的情况都可以进行查询,系统会生成货物订单表、库位图、残损货物信息表以及员工损坏货物信息表。仓库主管会根据员工运货的表现对员工进行相应的奖惩措施。仓库主管还可以进行所有库存信息查询,系统会生成所有订单的实际入库信息表,如图555所示。 5.5.4.5订单管理子系统操作流程图(工作人员视角) 运营部首先登录系统,成功可进入下一步操作,不成功将返回重新登录。运营部登录成功后可进行五个子操作。一是录入信息订单,操作成功即立即生成原始订单信息库,不成功将返回重复上一步; 二是修改订单信息,操作成功即生成更新后的订单信息库,不成功则返回上一步; 三是查询订单信息,操作成功即生成目标订单信息,不成功则返回上一步; 四是进行订单转换,成功则订单立刻转变生成运单和交接单,不成功返回上一步重新开始; 五是打印订单,成功则会按照顾客要求生成订单,不成功返回上一步,如图556所示。 图555入库管理子系统操作流程图(仓库主管视角) 图556订单管理子系统操作流程图(工作人员视角) 5.5.4.6人力资源管理子系统操作流程图(工作人员视角) 人事处首先登录系统,成功可进入下一步操作,不成功将返回重新登录。人事处登录成功后可进行五个子操作。一是招聘新职员,操作成功即立即生成录取信息,不成功将返回重复上一步; 二是人员定岗定位,操作成功即生成劳工合同,不成功则返回上一步; 三是进行工作人员的绩效考核,操作成功即生成绩效考核等级评定表,不成功则返回上一步; 四是进行薪酬福利管理,成功则生成人员工资福利表,不成功返回上一步重新开始; 五是进行公司的人力资源规划,成功则会生成人力资源规划书,不成功返回上一步,如图557所示。 图557人力资源管理子系统操作流程图(工作人员视角) 5.5.4.7出库管理子系统操作流程图(仓库主管视角) 出库子系统在操作方面,实现的是仓库主管在登录进入仓储系统之后,可以对来自顾客的提货单进行仓库库位查询,当仓库存货与提货单相匹配时,可以打印货物仓位单,当不匹配时,可以与顾客联系进行提货调整。同时,登录该系统后能进行货物的过期、损坏、失效等查询,进而生成货物损坏单; 在进行仓库余货查询后可以得到仓库库存单; 同时,可以对顾客存储在仓库中的货物继续余货查询,生成顾客余货单,便于为顾客提供下一次的提货查询,如图558所示。 5.5.4.8配送管理子系统操作流程图(配送中心管理人员视角) 配送中心工作人员注册账号并通过身份认证获得权限,登录成功后,可以查询订单情况和车辆位置信息,订单情况包括订单的始发地、目的地、重量、承运方式等明细情况,车辆信息包括车辆的位置,是否承运,以及承运明细情况等,生成订单明细表和车辆信息明细表,然后配送中心首先根据系统自动进行订单分配,生成货物配送单,同时再由人工进行微调,如图559所示。 图558出库管理子系统操作流程图(仓库主管视角) 图559配送管理子系统操作流程图(配送中心管理人员视角) 5.5.4.9系统维护子系统操作流程图(系统管理员视角) 系统管理员提交个人信息注册,全面管理员可以操作所有模块,部分管理员只能操作部分模块。成功登录系统后,每个管理员都可以进行修改密码操作,修改密码成功后系统会对新密码修改存档; 管理员要对各部门提交的数据报表进行整理提交存档操作; 管理员每天都要对数据进行筛选并进行备份数据存档操作,以防系统出故障数据丢失。每年还要进行数据年备份; 管理员根据用户提交的需求进行数据查询,得出反馈信息可以反馈给客户,如图560所示。 图560系统维护子系统操作流程图(系统管理员视角) 5.6本 章 小 结 结构化系统分析采用了业务流程图、数据流程图、数据字典、处理逻辑表达等工具,通过系统分析可以获取系统抽象的逻辑模型。软件系统分析强调业务问题方面,因而常采用业务流程图进行分析,然后采用数据流程图进行数据流程的抽取,再辅以判断树、判断表和结构式语言等进行补充分析和说明。系统分析强调系统的逻辑功能,而不是它的物理实现方法。