一、结构化分析方法

1.1需求描述

教务管理子系统的需求描述：

教务管理是一项需求周密计划、严谨安排的工作，要依据教师、学生信息进行合理安排。

开学阶段，需要教师提交开课申请进行开课，学生根据老师的开课信息，选择课程，教务处生成学生课表、教师课表。

期末阶段，需要根据开课情况对学生进行考试安排，对教师进行监考安排，以及学生考试成绩管理。

学期结束，需要对学生成绩进行统计，计算绩点，排名，评定奖学金。

图书馆管理子系统的需求描述：

借书过程，学生到图书馆查询图书信息，出示借书证，办理借书。

还书过程，判断是否超期、图书是否破损，办理还书。

1.2可行性分析

1.2.1技术可行性

开发教务管理系统和图书管理系统，市场上已经有了众多先例，所以我们可以得知技术的成熟度和现实性能够得到很好的保障，我们实现软件开发所需要的技术应当与时俱进，应当属于当下技术行业的流行水平。尽可能采用成熟技术，满足系统开发需要、能够适应系统发展、保证开发成本。

该系统可采用Windows10作为操作平台，数据库采用MySQL server 8.0。该系统在Windows8上也可运行，同时提供数据库之间的数据复制功能，可替代现有的人工传递工作，降低了出错率。

1.2.2经济可行性

研发管理系统的平台可以使多种多样：我们可以将系统安装到学校自身的软件当中，或者使用微信公众号或者其他第三方平台的帮助来降低开发成本。硬件维护和软件支持可以由学校负责提供。因为此次软件开发追求实用性，因此可以直接由校内教师或者学生团队负责开发或者辅助发开。工作量无需过于繁重，可以作为实验室项目安培进来，利用学生的课余时间自行完成即可。

教务管理系统总体流程清晰，完成难度小，所需要的成本较少。采用教务管理子系统可取代传统的手工传递工作，有效的减少人工开支，节省资金，并且可以大大提高信息量的提取，缩短信息处理周期，规划教学资源，提高学生信息，及时反馈教学信息的利用率。总体来看其效益巨大，成本较小，有经济可行性。项目早期阶段对系统开发成本进行精确估算是相当困难的，所以我们也可以组织老师和学生参观国内一些知名大厂，学习算法成本，计算项目工作量。

1.2.3社会效益可行性

此系统开发主要目的就是服务于学生、服务于学校。能够方便学生平时对学习有更深层次规划，具有长远的效益。另外此系统开发更新性强，因此无需担心存在落后淘汰的情况，开发人员可以与时俱进地去更新他们的系统。

1.2.4管理可行性可行性

本系统只需简单的数据采集，人员在经过培训后即可上手，操作简便，具有良好的管理可行性。

1.3需求分析

1.3.1数据流图创建

通过寻找两个子系统中的实体类构建教务管理系统数据流图，考虑数据的源点和终点，从上面对系统的描述可以知道教务管理系统中课程是数据终点，而教师、学生、教务管理系统是数据源点。而图书管理系统中学生既是数据起点；也是数据终点。

接下来考虑处理。再一次阅读问题描述必须有一个用于对结果的处理。对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。

最后考虑数据流和数据存储。本题中需要储存的有开课信息、选课内容、成绩、书籍信息等内容。完整的构建出数据流图。

教务管理子系统

第一层：

第二层：

第三层：

图书馆管理子系统

第一层：

第二层：

第三层：

1.3.2数据字典分析

通过上述数据流图中的数据流、数据存储、处理逻辑、数据项、数据结构、外部实体来编制数据字典。找出文中的实体类，描述主要名称、数据流的去向、组成等。

数据项

一、教务管理

数据项编号：I1

数据项名称：课程信息编号

别名：课程信息编号

简述：教师创立的课程的信息

类型及宽度：字符型，6位

取值范围“000001”~”999999”

数据项编号：I2

数据项名称：课程日期

别名：课程时间

简述：课程的起止日期

类型及宽度：Date，8位

取值范围2022-9-1~2023-01-19

二、图书管理

数据项编号：I1

数据项名称：书籍编号

别名：书籍编码

简述：标识哪本书的代码

类型及宽度：字符型，6位

取值范围“000001”~”999999”

数据项编号：I2

数据项名称：书籍名

别名：书籍名

简述：书籍的名字

类型及宽度：字符型

取值范围“u4e00~u9fa5 (中文)

数据结构

一、教务管理

数据结构编号：KC-001

数据结构名称：课程学生名单

简述：某一门课选课的学生信息

数据结构组成：I1+I2（学生选课数据项）

二、图书管理

数据结构编号：DS01-01

数据结构名称：书籍信息

简述：某一本书籍的信息

数据结构组成：I1+I2

数据流

一、教务管理

数据流编号：CJ-001

数据流名称：成绩单

简述：某一课学生的成绩单

数据流来源：教务处

数据流去向：学生、教师

数据流组成：课程信息+学生成绩

数据流量：

高峰流量：

数据流编号：XK-001

数据流名称：选课信息表

简述：学生选课信息

数据流来源：学生

数据流去向：教务处

数据流组成：课程信息+学生信息+选课信息

数据流量：

高峰流量：

二、图书管理

数据流编号：F01-01

数据流名称：书籍信息表

简述：书籍信息

数据流来源：图书馆

数据流去向：管理员

数据流组成：书籍编号+书籍名

数据流量：4本/分

高峰流量：5本/分

数据流编号：F02-01

数据流名称：借阅信息表

简述：书籍借阅信息

数据流来源：管理员

数据流去向：学生

数据流组成：学号+学生姓名+书籍编号+书籍名

数据流量：4本/分

高峰流量：5本/分

处理逻辑

一、教务管理

处理逻辑编号：P2.2

处理逻辑名称：学生期末考试成绩排序

简述：学生期末考试成绩排序

输入的数据流：学生考试信息

处理：根据分数、学号数排序

输出的数据流：学生成绩S1、班级排名S2

处理频率：一学期一次

处理逻辑编号：P1.2

处理逻辑名称：生成学生课表

简述：生成学生课表

输入的数据流：学生选课信息

处理：根据学生的选课信息，产生一个完整的课表

输出的数据流：课表K1，课程信息K2

处理频率：

二、图书管理

处理逻辑编号：P1.1

处理逻辑名称：查询图书信息

简述：查询图书的信息

输入的数据流：借书的申请

处理：根据学生借书申请来查询相关图书信息

输出的数据流：书籍的信息

处理频率：一分钟一次

处理逻辑编号：P1.2

处理逻辑名称：借书办理

简述：借书办理

输入的数据流：书籍信息

处理：根据书籍信息找到相应的书籍给学生

输出的数据流：借阅信息

处理频率：一分钟一次

数据存储

一、教务管理

数据存储编号：C1

数据存储名称：成绩存档

简述：某一课程期末考试学生的成绩以及排名

数据存储组成：考试时间+学生姓名+学生成绩

关键字：学号

1.4总体设计

1.4.1软件结构分析

教务管理系统主要物理输出层为学生、教师和教务处，教师查询开课信息；学生查询选课信息；教务处接受教师和学生的事务，并反馈给教师和学生答案。

图书管理系统主要物理输出层也为学生，通过学生与系统的互动，并借助借书证、书本等实体类办理借书流程。

1.4.2软件结构图

教务流程软件结构图

图书馆流程软件结构图。

1.5.详细设计

期末考试安排程序环形复杂度：

1.进行考试编制

2.生成考试人数

3.教室排课信息

4.生成考试编号

5.生成考试科目

6.教师排课信息

7.筛选考试时间

8.考试时间是否匹配

9. 安排考试教室

10.考试教室是否匹配

11.安排考试教师

12.考试教师是否匹配

13.生产考试编制信息

根据图可以得出复杂度为：V(G)=E-N+2 ，其中E是流图中边的条数，N是节点数。所以可以得出V(G)=9-7+2=4。

二、面向对象分析方法

2.1需求描述

医院预约挂号系统是医院利用网络平台方便患者预约挂号看病的系统。

患者通过平台实名填写患者信息、身份证号码、联系方式等信息进行用户注册。注册完成后可以选择医生、看病日期，实现网上预约挂号，并可通过社保卡、医院门诊卡、银行卡、微信、支付宝等多种方式预约支付门诊挂号费。支付完成后，患者获得挂号信息，预约挂号成功。

患者凭挂号信息的预约码和身份证可在预约日期前往医院挂号处换取号牌。如果在预约日期前有其他特殊情况不能按时去医院就诊，可以登录系统提前取消。取消预约只能在预约日期之前进行。

当号牌顺序号到时，护士叫号并带领患者进入诊室就诊。医生登记患者的挂号信息，询问病情，根据患者病情开出医嘱、药品，就诊结束。

2.2可行性分析

2.2.1技术可行性

医院预约挂号系统是基于一种普通的取号功能系统提升而来的系统，需要优秀的技术成熟度和现实性能，保证系统零失误，要使用国内最先进技术，满足系统开发需要、能够适应系统使用和发展。

2.2.2经济可行性

在可行性分析阶段，因为开发的是隶属于医院的挂号管理系统，因此可以通过向国家申请开发请求，提供研发必要的启动资金和维护资金，以及支付给软件工程师和管理人员的费用。人才可以从广大市场寻找。

对于绝大多数部分，主要的成本是工作量成本，系统管理员工可以由医院负责从医院内部调用计算机人才或者在市场招聘其他人才来管理。

2.3用对象模型辅助分析

2.3.1罗列类与对象

罗列上述需求陈述中的名词作为类与对象的候选者：医生、患者、护士、系统平台、用户注册、患者信息、身份证号码、联系方式、选择医生、看病日期、医院挂号处、挂号、社保卡、医院门诊卡、银行卡、微信、支付宝、门诊挂号费、号牌、特殊情况、取消预约、挂号信息、叫号、就诊、病情、医嘱药品。

罗列出删除的不正确或不必要的类与对象：挂号、社保卡、医院门诊卡、银行卡、微信、支付宝、患者信息、身份证号码、联系方式、病情、用户注册、特殊情况、叫号、就诊、病情。

2.3.2罗列关联关系

罗列出需求陈述中使用的描述性动词或动词词组，这些通常表示关联关系。

·医生、护士、患者、系统平台组成网络

·患者通过平台填写信息

·系统平台提供患者信息

·系统平台有选择医生功能

·系统平台有看病日期功能

·系统平台有提供挂号信息功能

·患者通过社保卡支付门诊挂号费

·患者通过医院门诊卡支付门诊挂号费

·患者通过银行卡支付门诊挂号费

·患者通过微信支付门诊挂号费

·患者通过支付宝支付门诊挂号费

·系统平台为患者提供挂号信息

·医院挂号处为患者挂号

·医院挂号处提供患者的挂号信息

·患者可以在系统平台取消预约

·护士通过挂号顺序叫号

·医生询问患者病情

·医生开出医嘱

·医生开出药品

罗列出删除的不正确的或不必要的关联：

·系统平台有提供挂号信息功能

·患者通过社保卡支付门诊挂号费

·患者通过医院门诊卡支付门诊挂号费

·患者通过银行卡支付门诊挂号费

·患者通过微信支付门诊挂号费

·患者通过支付宝支付门诊挂号费

·医院挂号处提供患者的挂号信息

2.3.3绘制初始类图

2.3.4完善类图

1、罗列在需求陈述中用名词词组，用于表示属性

患者信息、身份证号码、联系方式、病情、用户注册、用户信息、取消预约、叫号、就诊、病情、特殊情况、登记患者、询问病情、叫号、带领患者、号牌顺序。

2、罗列出删除的不正确或不必要的属性

病情、用户注册、叫号、就诊、特殊情况

3、罗列出继承关系

·医生和护士泛华出父类“诊室”

·号牌、号牌顺序、预约取消是医院挂号处上的限定词

·用户信息是系统平台上的限定词

·门诊挂号费和选择医生是网上预约上的限定词

·挂号信息是患者上的限定词

·医嘱药品是诊室上的限定词

4、绘制如下的完善后的类图

2.4、估算项目的规模

软件的规模和其外延成正比

外延包括: 挂号功能, 患者数据, 患者、公厝恩怨操作界面数, 显示界面数等等。

不同的功能点实现的困难度不同, 但从整个项目来说, 平均的困难度差不多。规模估算的目标决定工作量的大小在半年左右。

对于成本模型，规模是计算软件项目的工作量、成本和进度的主要输入。在规模估算之前，软件功能需求必须被定义。在项目早期定义需求可能是非常困难任务。如果知道部分需求，那么估算基于已知的需求并且相信每一个人都相信估算仅仅是基于那些已知的需求，如果使用了增量或演进的开发策略，那么估算基于增加的已定义需求。

2.5、项目进度计划、成本估算

2.5.1进度计划

软件体系结构决定进度计划。

• 子系统如用户注册、挂号、排序等分解应该是高层的，专注于功能，并且要保持稳定。

• 每一个子系统可以被分配给一个团队或一个人，由他负责其定义和实现。

项目工作可以将项目整体分解成较小的、易于管理和控制的若干子项目或工作单元，直到可交付成果定义的足够详细，足以支持项目将来的活动。

在项目工作分解的基础上，进一步估算活动所需的时间和资源，并按照一定的顺序将这些活动进行组织和调度，从而创建项目的进度计划表。

2.5.2成本估算

项目估算是对完成项目交付物的时间和成本进行预算和估计的过程。

• 该系统软件规模较大，复杂性较高，不确定性成本就越多，

• 需求的不确定性会对项目估算产生很大影响，因此开发前期要优先将主要功能模块的成本预估算出来。

• 通过以往可靠历史数据使项目估算来参考成本中缺少的部分。

三、课程总结

一个学期对于软件工程的学习，主要就需求分析进行总结。软件的生存周期可分为八个阶段:①问题定义;②可行性研究;③需求分析;④总体(概要)设计;⑤详细设计;⑥编码与单元测试;⑦综合测试;⑧软件维护;

需求分析:系统开发前期需求分析很重要，它是为了有效解决用户问题的需要进行的一项工程活动，所需要考虑的需求问题是功能需求、数据需求、性能需求和接口需求，开发者承担分析任务，核心是用户。其步骤有三个：1、获取客户需求2、建立需求模型，常用的模型有:业务树图、用例图、活动图。3、需求建模。结构化分析建模:它是建立在需求规约基础上的；功能建模，是对系统数据加工的图解，数据流程图是常用的建模工具，涉及数据接口、数据处理、数据流、数据存储等图形元素，用于描述系统数据加工细节；数据字典，是用于定义软件的元素，使软件元素获得严肃的、详密的、精确的规格说明。

软件工程，给我提供一个系统化的软件设计流程思路，对今后专业发展能起到很大的帮助。