G003-185-16

期末报告

李子泓 1814080902521
吴伟滨 1814080902530


摘要:本文档为软件需求分析与建模课程,16小组的期末报告文档,我们小组的项目是实验室设备管理系统,文档包含四大部分,第一部分为EA图档,第二部分为项目需求提案计划书,第三部分为项目需求萃取分析书,第四部分为实验室设备管理系统需求获取与分析说明书,我们的分工比例为每人各50%

关键词:实验室设备管理系统 需求分析 EA图 项目计划

  1. 实验室设备管理系统EA图档

    1. Capability Roadmap(能力路线图)

在这里插入图片描述
在这里插入图片描述

1.1.1适用环境

能力路线图概述了组织在未来几个季度和几年中计划拥有的大规模能力。能力路线图不是跟踪特定的项目或计划,而是阐明组织计划在给定时间内能够完成的计划或计划。能力路线图是制定长期战略的一种目标导向的方式,关注组织超越任何特定计划限制的潜力。

1.1.2图档使用目的

能力路线图可以用于内部服务组织,如制造或信息技术集团;或者,它也可能被作为业务提供服务的组织使用,例如咨询公司或维护或维修提供商。路线图绘制过程确定了关键的客户需求,以及将满足这些需求的能力、技术和技能。路线图绘制过程也有助于规划团队在面向未来的竞争环境中制定战略方法。道路映射过程识别出满足客户需求方面的差距,并帮助定义填补差距的计划。路线图连接并平衡了客户需求和技术创新的驱动因素。

1.1.3绘制步骤与图例说明

能力路线图,使用EA,结合分析我们小组的实验室设备管理系统绘制而成,图中确定了我们项目的能力,技术,技能以及项目计划等内容

1.2 Project Roadmap

在这里插入图片描述

1.2.1适用环境

项目路线图只提供高层次的、战略性的视图,而不会深入到日常任务中,也不会提供每个人都在做什么的详细视图。路线图的设计是为了帮助团队向其他团队(如管理人员、投资者、市场营销和销售部门等)提供项目状态的一览表。

1.2.2图档使用目的

项目路线图是项目战略目标的持续提醒,当团队在任何复杂的项目上取得进展时,他们工作的日常现实往往会发生变化。人们需要被转移到其他更高优先级的任务上。预算需要调整。基于市场的变化,一个曾被视为低优先级的计划突然变得紧迫起来。当这些变更需要项目团队重新安排项目计划的任务级别细节时,一目了然地提醒他们要达到的高级目标可以帮助团队做出更明智的决策。

项目路线图在设定预期、赢得认可、以及迅速更新其他利益相关者(如高管和投资者)方面的价值。

1.2.3绘制步骤与图例说明

1.3 Organization Chart

在这里插入图片描述

1.3.1适用环境

组织结构图或"组织结构图"的定义是显示报告或关系层次结构的图表。组织结构图最常见的应用是显示企业、政府或其他组织的结构。

组织结构图有各种各样的用途,可以用许多不同的方式组织。它们可以用作管理工具,用于计划目的,或者用作人员目录等。也许你的组织不是以"命令和控制"的方式运作,而是依赖于团队。

1.3.2图档使用目的

通过组织结构图

1. 可以显示其职能的划分.

2. 可以知道其权责是否适当.

3. 可以看出该人员的工作负荷是否过重.

4. 可以看出是否有无关人员承担几种较松散,无关系的工作.

5. 可以看出是否有让有才干的人没有发挥出来的情形.

6. 可以看出有没有让不胜任此项工作的人担任的重要职位.

7. 可以看出晋升的渠道是否畅通.

8. 可以显示出下次升级时谁是最合适的人选.

1.3.3绘制步骤与图例说明

我们项目的组织架构图,使用EA,结合分析项目的组织架构绘制而成,项目中由项目经理总负责项目的的开发测试与运维,并和客户的项目负责人沟通对接,各个部门各司其职,共同推进项目实现,本项目的用户人群有实验室管理员,教师与学生

1.4 Organization Viewpoint

在这里插入图片描述

1.4.1适用环境

组织视角集中于一个公司、部门、公司网络或另一个组织实体的(内部)组织。在这个观点中,可以将模型表示为嵌套的框图,但也可以采用更传统的方式,如组织结构图。组织观点在识别组织中的能力、权威和责任方面非常有用。

1.4.2图档使用目的

组织观点图用于描述组织或实体或组织(如部门或部门)的一部分的角色和参与者

1.4.3绘制步骤与图例说明

我们项目的组织视角图,使用EA,结合分析实验室设备管理系统项目的组织结构以及各个部门的角色绘制而成,实验室设备管理系统管理部部长管理下属的开发部,运维部,测试部,各个部门的成员各有自己的分工角色

1.5 Business Motivation Model

在这里插入图片描述

1.5.1适用环境

如果一个企业为其业务活动规定了某种方法,它应该能够说明这种方法的目的是什么以及要达到什么样的结果。业务动机模型(Business Motivation Model,BMM)是一个 OMG 建模符号,用于支持关于如何应对不断变化的世界的业务决策。企业将通过获取 BMM 建模工具,然后创建自己的 BMM 来使用它------用企业特有的业务信息填充模型。

1.5.2图档使用目的

  • 捕捉有关对变化的反应的决定和做出这些决定的理由,目的是使这些决定可以分享,提高清晰度,并通过学习经验来改进决策

  • 参考决策的结果对运营业务的影响(例如业务流程和组织职责的变更) ,提供从影响者到运营变更的可追溯性

1.5.3绘制步骤与图例说明

1.6 Motivation Viewpoint

在这里插入图片描述

1.6.1适用环境

动机视角涵盖了从给定利益相关者的角度定义驾驶员,评估,若干目标和所应用的原则以及限定原则所需的要求和约束的动机方面。

1.6.2图档使用目的

动机视角允许设计师或分析师对动机方面进行建模,而不关注该方面的某些元素。例如,此观点可用于呈现利益相关者动机方面的完整或部分概述、他们的主要目标、应用的原则以及服务、流程、应用程序和对象的主要需求。

1.6.3绘制步骤与图例说明

动机视角图,使用EA,结合实验室设备管理系统进行分析绘制,项目经理作为利益相关者,为了更好的推广系统,需要系统尽量减少手动操作,提高用户的体验,从需求上来看,设备报修功能以及实验室设备的增删改查功能在数据完整性的原则下,可以实现系统对设备的自动排序分类以及打印所需的报表。

1.7Service Realization Viewpoint

在这里插入图片描述

1.7.1适用环境

服务实现视角对一个或多个业务服务如何由底层流程(有时由应用程序组件)实现进行建模。因此,它形成了业务产品视图和业务流程视图之间的桥梁。它从外部提供了一个或多个业务流程的视图。

1.7.2图档使用目的

服务实现视角用于显示一个或多个业务服务是如何由底层流程(有时是由应用程序组件)实现的。因此,它形成了业务产品视图和业务流程视图之间的桥梁。它从外部提供了一个或多个业务流程的视图。

1.7.3绘制步骤与图例说明

服务实现视角使用EA,结合实验室设备管理系统的设备报修功能分析绘制而成,在设备报修流程过程中,教师或学生,实验室管理员作为业务的参与者,由教师或学生在教师或学生系统端报修设备,由实验室管理员在实验室管理员系统端对报修信息进行处理

1.8 Requirements Realization Viewpoint

在这里插入图片描述

1.8.1适用环境

需求实现视角使设计师可以对需求是如何被各种核心元素(如业务参与者、业务流程、业务服务以及应用组件等)所实现的这一情形进行建模。除此之外,此视角还可以被用来对各概括程度较高的需求进行更加深入的细分,从而形成更加详细的需求。

1.8.2图档使用目的

需求实现视角允许设计人员根据核心元素(如业务角色、业务服务、业务流程、应用服务、应用组件等)对需求的实现建模。通常,需求源于目标细化观点。此外,这个观点可以用来将需求细化为更详细的需求。聚合关系用于此目的。

1.8.3绘制步骤与图例说明

需求实现视角,使用EA,结合实验室设备管理系统,从需求的角度绘制而成,从设备报修和设备申购两个需求进行目标细化,确保报修信息和申购信息填写完整规范且正确。

1.9 Principles Viewpoint models

在这里插入图片描述

1.9.1适用环境

原则视角为目标和原则之间的关系建模。聚合关系模型目标的分解和实现关系模型原则如何与一个或多个目标相关联。

1.9.2图档使用目的

原则视角可以使设计师或分析师对与当前设计问题相关的各种原则、驱使这些原则落实的相关目标,以及他们之间的关系进行描述。

1.9.3绘制步骤与图例说明

原则视角图,使用EA,结合实验室设备管理系统,从原则的视角进行绘制,图中所示数据只存储一次的原则,目标时为了保持数据的一致性,而系统应面向可以原则,为了使客户有更好的使用体验,满足客户的需求,以减少人工工作和减少与客户的交互为目标,分析出在线服务的需求

1.10 Specification Manager

在这里插入图片描述
在这里插入图片描述

1.10.1适用环境

规范管理器是模型中选定包的基于文档的界面,提供了创建和查看元素(作为该包中模型对象的文本表示形式)的方法。您可以在"规范管理器"窗口本身中快速定义或编辑元素的属性,还可以立即打开一系列窗口和对话框以添加或查看特定于每个元素的其他属性和特征。

1.10.2图档使用目的

规范管理器的一个重要特点是速度和容易程度可以创建,过滤器和从一个点审查大量元件,并且开发或每个元件上检查复杂的细节或没有

1.10.3绘制步骤与图例说明

规范管理器是EA自带的一个组件,通过它可以快速且简单得创建元件,上图举例了我们小组绘制的Business Motivation Model和Organization Chart通过使用规范管理器绘制的样例。

1.11 Requirement Specification View

在这里插入图片描述

1.11.1适用环境

需求规范视图模式创建元素和规范视图,允许在文档或类似电子表格的视图中可视化需求,从而允许将复杂的需求分解为更细粒度的需求(下至两个级别)。这种模式可以向下扩展到任意数量的级别。

1.11.2图档使用目的

需求规范视图模式提供一种将一组需求的结构可视化到两个层次的方法,允许在适合非技术受众的熟悉界面中创建和管理需求。对该视图中需求的更改将导致所有其他视图(如图表)自动更新。需求或业务分析师希望在文档或类似电子表格的视图中工作时,通常会使用它,因为这样可以提高工作效率,

1.11.3绘制步骤与图例说明

步骤:

定义跟踪关系,显示需求如何与向上流程元素(如策略、业务规则和其他需求)以及向下流程元素(如用户情景、用例、组件、工件和数据库表)相关。创建从模型自动生成的高质量文档。

说明:

通过ea建模,将项目的各模块需求列出,对每个子模块下的功能再合并列出,方便开发人员了解系统功能。

1.12 Composite Requirement Hierarchy

在这里插入图片描述
在这里插入图片描述

  1. 适用环境

    复合需求层次结构模式创建元素和图表,这些元素和图表允许将需求层次结构定义到任何级别,从而允许从一个级别的需求向下钻取(单击)到另一个图表,在层次结构的下一个级别显示其子需求。当需求或业务分析员需要显示需求层次结构的单一级别,但希望指出需求由其他需求组成,从而允许深入到图中的其他级别。

  2. 图档使用目的

    显示子需求的需求图提供一种可视化一组需求的结构的方法,一次一个级别地显示一个或多个需求具有元素右下角的标记所指示的子级。复合模式可以应用到任何级别。

1.12.3绘制步骤与图例说明

步骤:

重命名关系图、重新命名需求以适应计划、添加描述需求的业务或系统重要性的详细注释、更新需求的属性以适应计划。

说明:

通过创建类似图表,对系统各模块层次模块进行定义,使得业务分析员可以深入了解程序。

  1. 1.13 Requirements traceability Diagram

在这里插入图片描述

1.13.1适用环境

需求跟踪模式创建元素和一个跟踪图,显示需求和模型中其他元素之间的关系,包括拥有需求块、用例和测试用例的涉众。它通常用于开发模型和定义模块、用例和测试用例等元素,并与它们满足的需求相关。

1.13.2 图档使用目的

显示了一个需求关系图,允许系统工程师创建一个图表,其中模型元素和它们相关的需求之间的关系可以可视化,包括其他需求

1.13.3 绘制步骤与图例说明

步骤:

从用户需求出发,确认要开发的产品特性。将用户需求与相关的产品特性连接起来,建立这两个元素之间的可追溯性。分析员可以从产品特性中开发用例,作为需求分析的一部分。

说明:

使用EA,结合实验室设备管理系统,从需求的角度绘制而成,从系统功能进行目标细化,从系统的实际用例出发,对本系统进行测试。

1.14 Non Functional Requirements Diagram

在这里插入图片描述
在这里插入图片描述

  1. 适用环境

    非功能性需求分析模式创建了一系列包、元素和一个对非功能性需求建模的图。需求根据需求的类型进行分组,包括可用性、可比性、可扩展性和可伸缩性等组。

  2. 图档使用目的

提供在单个图表或项目浏览器中可视化非功能性需求组的方法。预定义的包集有助于通过允许识别缺失的需求来帮助识别需求规范中的差距。

绘制步骤与图例说明

步骤:

明确哪些业务对象会有大数据量要求,考虑功能对于并发用户数的要求明确了数量要求后,在分析时就需要结合业务对象、场景等进行设计。

说明:

根据自己的实验室设备管理系统,描述整个系统的非功能需求,可以使得系统完成时可以按照预期的情况运行。

  1. 1.15 Domain Model Diagram

在这里插入图片描述

1.15.1 适用环境

域模型模式在类图上创建类,这些类描述讨论中的域中的重要概念或"事物"。类可以命名,也可以有详细的注释。域模型通常是在一个计划中创建的第一个模型之一,它构成了开发存储库其他部分的基础。它可以像使用词典一样作为一种交流工具。它还可以用作其他模型的参考,如流程图或组件图,指示输入或输出的信息。

1.15.2 图档使用说明

显示一个类图,其中包含表示域中概念的多个类。类被连接以显示它们的关系,而多重性用于描述关系的基数。创建一个领域中重要概念的模型,该模型可用作通信设备,以确保所有利益相关者对概念有一个共同和一致的理解。

1.15.3 绘制步骤与图例说明

步骤:

更改类和关系的名称以适应您的计划。

向类添加属性以描述概念的属性。

随着域分析的继续,细化模型。

为元素和关系添加颜色以传达意义。

说明:

系统主要设计用户、实验室、实验设备三个实体,通过这个模型将三者的关系进行描述。

1.16 Use Case Model

在这里插入图片描述

1.16.1适用环境

用例模型模式创建元素和用例图,描述用户角色希望从系统中实现的目标。用例都包含在系统边界内,参与者都在边界之外。该模式通常用于计划的分析阶段,可用于实现任意数量的需求,并作为为实现团队提供规范的一种方式。

1.16.2 图档使用目的

以人机交互和用户为中心的方式通过分析业务过程中的这些业务活动实体场景。显示了一个用例图,其中包含参与者和系统边界中包含的多个用例。允许业务分析师和其他涉众描述参与者(用户扮演的角色)在与系统交互时想要实现的价值。

1.16.3 绘制步骤与图例说明

步骤:

a,为每个Use case提供一个脚本描述,描述要简洁意骇,而且基本语句结构要符合语句为:时间,地点,谁,做了什么,怎么做,为什么做。

b,更改系统边界的名称以适应该计划。

更改参与者和用例的名称以适合该方案。

添加描述来描述用例提供的价值。

说明:

在这个例图中,对系统中的每个角色进行了描述,以人机交互的方式为中心,对系统涉及的业务以及场景进行分析。

1.17 Sequence Diagram

在这里插入图片描述

  1. 适用环境

    序列图模式创建元素和一个序列图,它描述了三个组件之间的时间顺序交互以及在它们的交互过程中被调用的消息。循环交互运算符用于指示一组消息被迭代多次。该模式通常在设计或实现阶段使用,但也可以在计划完成并需要文档记录时使用。它们可以用于可视化两个或多个组件之间的复杂交互以及它们交换的消息。序列图也可以方便地从调用堆栈自动创建。

  2. 图档使用目的

    目的是使元素之间的交互可视化。设计人员和实现团队通常创建序列图,作为设计工具或用于文档目的。消息序列通常可以通知设计决策或使在操作系统中发现的问题变得清晰。

  3. 绘制步骤与图例说明

步骤:

更改图表的名称以适应计划。

更改组件的名称以适应方案。

更改组件操作的名称,这些操作在图中作为消息可见。

创建附加的组件和消息,这些组件和消息对应用于该计划的交互进行建模。

更改Note元素上的文本,使其适用于消息,以适应计划。

说明:

对系统组件之间的时间顺序进行设置,以及模式中循环交互的事务进行迭代并记录。

1.18 Activity Diagram

在这里插入图片描述

适用环境

带有中断区域模式的基本活动图创建元素和活动图,其中包含一系列操作和控制节点(初始、最终、决策等),这些节点由控制流连接,这些控制流指示操作的启动顺序。它通常在计划的分析阶段使用,以显示活动所描述的工作是如何由一系列动作执行的。图表通常不会为每一项活动而创建,而是为一小部分活动而创建,在这些活动中,明确说明工作是如何进行的很重要。其用途包括:指定事件发生时的备用操作。

图档使用目的

目的是允许业务分析师和其他利益相关者通过定义一系列动作来创建活动如何执行其工作的可视化表示。顺序由控制流关系表示。允许modeler指定当事件发生时允许modeler接收一个事件。

绘制步骤与图例说明

步骤:

重新命名元素和图表以适合该计划。

重命名操作和伪节点(初始、最终、决策等)以适应主动性。

在需要的地方添加更多元素来扩展图的语义。

说明:

对系统的初始点、最终点进行部署,绘制出系统中的各个活动,已经活动进行的顺序。

  1. 1.19 Deploy diagram

在这里插入图片描述

1.19.1 适用环境

具有Deploy Dependency模式的节点实例创建元素和一个部署关系图,该图描述具有单个节点(服务器)和执行环境(容器)的部署环境以及部署到这些节点上的构件。该模式通常用于在企业级或计划级定义技术体系结构时。它可用于:

为工件(软件)实例到部署目标实例的部署建模。

当需要显示节点的隔间时进行模型部署。

使用部署规范指定部署的属性。

1.19.2 图档使用目的

该模式的目的是允许设计师或技术架构师创建或查看虚拟或物理部署环境的模型,包括节点(如机器服务器)、执行环境(如操作系统、容器、基于软件的服务器)。构件和部署规范为软件如何部署到节点或执行环境建模。工件实例提供了设计和实现模型与部署环境模型之间的链接。

1.19.3 绘制步骤与图例说明

步骤:

更改包和图的名称以适应该计划。

更改节点、工件和部署描述符的名称,以适应该计划。

为元素添加注释,以描述它们的用途和功能。

在包或关系图中添加或删除元素以适应计划。

向通信路径末端添加多重性以反映基数。

说明:

对系统中需要确定的基本规范进行指定。

  1. 1.20 MySQL Install OR Simple Cloud install

在这里插入图片描述

1.  ### 适用环境

    MySQL关是一种关系数据库管理系统,所使用的 SQL 语言是用于访问数据库的最常用的标准化语言,其特点为体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,在 Web应用方面 MySQL 是最好的 RDBMS(Relational Database Management System:关系数据库管理系统)应用软件之一。

2.  ### 图档使用目的

    帮助用户开始上手项目,节省时间。

3.  ### 绘制步骤与图例说明

    以管理员身份打开命令行,安装mysql的服务:mysqld \--install,并初始化mysql,设置系统的全局变量。

1.21 Create a new Database

在这里插入图片描述

1.21.1 适用环境

简单实体关系模型模式创建元素和一个图表,描述域中感兴趣的事物以及它们之间的关联方式。实体被建模为矩形,它们的属性(属性)使用椭圆建模为单独的元素。使用实线的菱形标记在实体之间创建关系。它们通常被用作更正式和更严格的数据库建模的前身。

1.21.2 图档使用目的

该模式的目的是允许信息架构师、业务和信息分析师在研究或讨论领域中创建重要"事物"(实体)的可视化表示。它们通常被用作概念数据模型或用于描述关系数据库管理系统的更正式的数据模型的前身。

1.21.3 绘制步骤与图例说明

步骤:

更改实体的名称、属性和其他属性(如标记值)。

创建其他实体(包括属性)并添加关系。

说明:对数据库中的数据表进行描述,数据表都有相对应的实体类。

1.22 Data Flow Model pattern

在这里插入图片描述
在这里插入图片描述

1.22.1 适用环境

数据流图模式创建元素和大量的图,这些图显示了一个系统以及与外部实体之间的数据流,允许向下钻取(单击)到两个较低级别的图。模式通常在信息分析期间使用。上下文(0级)图通常在早期创建,以了解系统和外部实体之间交换的信息(数据),包括行程方向和其他对分析非常重要的细节,如传输的类型、格式、大小和频率。

1.22.2 图档适用目的

该模式的目的是允许业务分析员、数据分析员、信息架构师或其他涉众创建数据在被观察系统和外部实体之间流动的方式的表示(上下文或0级图)。

1.22.3 绘制步骤与图例说明

步骤:

重命名关系图。

重命名系统和外部实体以适合该方案。

重命名并创建显示数据流的其他关系。

添加描述系统、实体和信息的详细注释。

更改活动和数据存储的名称以适应该计划。

更新元素的属性以适应计划。

说明:系统的外部实体主要采购设备时的设备供应商,以及设备损坏时的设备维修商,外部数据来源来自采购以及维修设备等事务产生的。

1.23项目Glossary

  1. Viewpoint 视角

  2. Motivation 动机因素

  3. Business 业务

  4. Service 服务

  5. Realization 认识,认知

  6. Principles 原则

  7. Specification 规范

  8. Manager 管理者

  9. Composite 组合

  10. Hierarchy 层次体系

  11. Domain 领域

实验室设备管理系统项目需求提案计划书

2.1 项目背景

2.1.1 项目需求发起人:;李子泓,吴伟滨

2.1.2 项目背景:

实验室作为实践教学中的重要手段,在学习的教学中扮演了重要的角色。正式认识到了实验室教学的重要性,各个学校的实验室也是鳞次栉比的落成。实验室的仪器、耗材、低值品等的需求也越来越大,旧式的登记管理方式已经渐渐显得力不从心。

实验室资源是衡量一所学校的硬件和科研水平的一 个重要标准,所以各个学校都会投入大量的人力,物力,财力来更新,优化实验室的教学和设备等,虽然对实验室的硬件设施比较重视,花费也比较多,但实验室的软件却没有跟上。实验室的软件,包括对实验室器材,教学仪器,辅助设备,实验教学等的统筹管理,使之达到对仪器设备的充分利用和保养维护,对实验课堂效率的提高。

2.1.3项目发起原因

为使实验室设备管理结构化、系统化、简单化,使采购业务流程顺畅,减少管理人员的工作量,提高工作效率,减少维修设备过程中程序的繁杂,便于今后对设备数据的查阅和分析,充分地利用信息资源,避免认为操作错误,节省大量的人力、物力及时间,为管理者提供及时、准确的信息。

2.1.4 项目实施的影响

本项目实施完成后,可用于各大高校的实验室,对其实验室的设备进行高效便捷的管理

2.1.5项目完成指标

实验室设备管理系统开发完成,并投放使用

需求的功能基本实现

2.1.6项目交付的最终日期

项目交付的最终日期初步定为2021年4月1号,出现特殊情况可延迟

2.2 主要任务

2.2.1 本次项目从可行性研究开始,包括以下主要任务

1.项目可行性研究

2.项目需求调查与获取

3.项目需求分析说明书编写

4.项目概要设计编写

5.项目详细设计编写

6.项目数据库设计

7.项目前端页面编码实现

8.项目后端编码实现

9.编码测试

10.项目公测

11.项目投放使用

2.3 工作量评估

2.3.1总工作量

±-------------------±-------------------+
| ### 任务 | ### 工作量(人天) |
±-------------------±-------------------+
| ### 项目可行性研究 | ### 5 |
±-------------------±-------------------+
| ### 需求调查与获取 | ### 20 |
±-------------------±-------------------+
| ### 编写需求分析书 | ### 30 |
±-------------------±-------------------+
| ### 编写概要设计书 | ### 20 |
±-------------------±-------------------+
| ### 编写详细设计书 | ### 20 |
±-------------------±-------------------+
| ### 数据库设计 | ### 20 |
±-------------------±-------------------+
| ### 前端页面设计 | ### 25 |
±-------------------±-------------------+
| ### 后端编码实现 | ### 40 |
±-------------------±-------------------+
| ### 编码测试 | ### 30 |
±-------------------±-------------------+
| ### 公测 | ### 20 |
±-------------------±-------------------+
| ### 总计:220 | |
±-------------------±-------------------+

2.4项目进度计划


任务名称 耗时(天) 开始 结束
实验室设备管理系统 138 2021.01.01 2021.05.08
可行性研究 10 2021.01.01 2021.01.10
需求分析 25 2021.01.11 2021.01.25
概要设计 10 2021.01.26 2021.02.05
详细设计 10 2021.02.06 2021.02.15
编码 70 2021.02.16 2021.04.25
测试 10 2021.04.26 2021.05.05
交付 3 2021.05.06 2021.05.08


2.5风险与规避

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UbZPcjx5-1609752224913)(media/image28.png)]{width=“5.7652777777777775in” height=“1.8284722222222223in”}

2.6项目交付件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UJD03jZi-1609752224914)(media/image29.png)]{width=“5.761805555555555in” height=“4.915972222222222in”}

2.7项目需求变更管理

开发过程中,对于新的需求,双方需参照《软件设计说明书》来判定,如果属于说明书里面没有的新出现的功能要求,则属于需求变更。

系统交付后,对于新出现的功能或已有功能的改变,也属于需求变更的范畴。

双方共同评估其对项目范围、设计、交付时间、质量和成本等方面的影响,并根据影响的大小来确定是否实施。

3 项目需求萃取分析书

3.1实验室设备管理系统用例图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Oswwbomd-1609752224915)(media/image30.png)]{width=“5.758333333333334in” height=“4.195833333333334in”}

3.2数据库管理用例图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bo3alFQo-1609752224916)(media/image31.png)]{width=“5.7625in” height=“3.9694444444444446in”}

3.3需求描述

±-------------------------------------------------------+
| 简单描述 |
| |
| 用户登录 |
±-------------------------------------------------------+
| 按步骤描述 |
| |
| 1. 用户选择用户登录 |
| |
| 2. 打开用户登录窗口 |
| |
| 3. 用户输入用户名、密码,然后提交 |
| |
| 4. 成功时提示"登录成功",失败则提示"用户名或密码错误" |
±-------------------------------------------------------+

±---------------------------------------------+
| 简单描述 |
| |
| 用户注册 |
±---------------------------------------------+
| 按步骤描述 |
| |
| 1. 用户选择用户注册 |
| |
| 2. 打开用户注册窗口 |
| |
| 3. 用户输入用户名、密码、确认密码,然后提交 |
| |
| 4. 成功时提示"注册成功" |
±---------------------------------------------+

±-------------------------------+
| 简单描述 |
| |
| 设备报废 |
±-------------------------------+
| 按步骤描述 |
| |
| 1. 用户选择报废设备 |
| |
| 2. 用户输入查询设备编号 |
| |
| 3. 将设备在数据库中的信息删除 |
±-------------------------------+

±-----------------------------------------+
| 简单描述 |
| |
| 登记使用 |
±-----------------------------------------+
| 按步骤描述 |
| |
| 1. 用户选择登记使用 |
| |
| 2. 用户在将个人信息以及所用设备编号填入 |
| |
| 3. 将信息存入数据库 |
±-----------------------------------------+

±-----------------------------------------+
| 简单描述 |
| |
| 设备报修 |
±-----------------------------------------+
| 按步骤描述 |
| |
| 1. 用户发现损坏设备 |
| |
| 2. 用户输入设备编号,描述损坏状态 |
| |
| 3. 将信息提交到数据库供实验室管理员查看 |
±-----------------------------------------+

±---------------------------+
| 简单描述 |
| |
| 添加设备 |
±---------------------------+
| 按步骤描述 |
| |
| 1. 实验室购入设备 |
| |
| 2. 将新设备的各项信息填入 |
±---------------------------+

±---------------------------------------------------------+
| 简单描述 |
| |
| 申请借出设备 |
±---------------------------------------------------------+
| 按步骤描述 |
| |
| 1. 用户选择需借设备 |
| |
| 2. 填入设备信息,以及个人信息,何时借出,何时归还等信息 |
| |
| 3. 存入数据库 |
±---------------------------------------------------------+

4实验室设备管理系统需求获取与分析

4.1.文档介绍

4.1.1 简介

本文档作为实验室设备管理系统需求获取与分析文档,其主要目的是提供一个明确的"用户要求声明",可作为实验室设备管理系统进一步开发的参考。本文档分为多个部分,从逻辑上将软件要求分成易于引用的部分

4.1.2目的

定义和描述实验室设备管理系统的功能和规格是本需求获取与分析文档的主要目标。本文档说明了实验室设备管理系统的主要用途和所需功能

本文档的目标受众是实验室设备管理系统的客户,董瑞生老师,以及其他需要访问此文档的同学

4.2.问题域

4.2.1前景

实验室作为实践教学中的重要手段,在学习的教学中扮演了重要的角色。正式认识到了实验室教学的重要性,各个学校的实验室也是鳞次栉比的落成。实验室的仪器、耗材、低值品等的需求也越来越大,旧式的登记管理方式已经渐渐显得力不从心。

实验室资源是衡量一所学校的硬件和科研水平的一 个重要标准,所以各个学校都会投入大量的人力,物力,财力来更新,优化实验室的教学和设备等,虽然对实验室的硬件设施比较重视,花费也比较多,但实验室的软件却没有跟上。实验室的软件,包括对实验室器材,教学仪器,辅助设备,实验教学等的统筹管理,使之达到对仪器设备的充分利用和保养维护,对实验课堂效率的提高。

4.2.2什么是实验室设备管理系统

面对日益增多的实验教学任务和老师学生使用实验室的需要,实验室设备的损耗问题也随之增多,以往人工管理方式和人工报修方式已经不符合需求,简便和规范化的管理需要一套与之对应的实验室设备管理系统

通过使用实验室管理系统实现实验仪器与实验耗材管理的规范化,信息化;提高实验教学特别是开放实验教学的服务水平;为实验室评估、实验室维护及实验教学质量等决策提供数据支持。运用计算机技术,为实验室设备管理维护进行规范化。

4.2.3项目范围

正在开发的软件系统称为实验室设备管理系统或LEAS。它为高校实验室管理人员所开发,该系统旨在提供自动化支持,用于实验室设备的更新与维护记录。该系统适用于高校各个中小型实验室,是比较完善的设备管理软件。该系统的适用对象是高校实验室的老师与管理员,操作人员必须掌握计算机的基本操作与终端的登入方法。该系统的预期使用频度是每天都使用。系统将在中央服务器上运行,每个用户通过Web浏览器具有的远程用户界面来与其交互。

实验室设备管理系统只允许系统管理员或实验室设备管理员创建账户成为该系统的使用者,该系统将允许使用者对实验室的设备进行查询,添加或删除设备,以及修改设备的信息,对于需要维修的设备,进行记录并提供维修人员的联系方式。

LEAS将有许多限制,它不允许除了系统管理员和实验室设备管理员之外的人员进行操作,系统不会允许使用者检索密码或编辑其他用户的信息

4.2.5硬数据采样

4.3 涉众

LEAS的涉众有:学校管理层,系统管理员,实验室管理员,教师,学生

4.3.1涉众分析

4.4 用户需求

4.4.1用户需求获取

用户访谈是最基本的一种需求获取手段。

  1. 通过访问学校的实验室管理人员,了解目前设备管理的现状和存在的问题,随着我校教学规模和教学内容的扩大与深入,实验室设备的数量和种类越来越多,通过单纯的纸质对设备的信息进行记录效率极低,针对目前现状,开发实验室设备管理系统势在必行。

  2. 访问学校的教师也希望能够查询到一些所使用设备的信息,提高实验教师环节的质量,以帮助更好地工作、学习。

4.4.2项目目标

本系统的目标旨在将设备管理和维修过程结构化、系统化、简单化,使采购业务流程顺畅,减少管理人员的工作量,提高工作效率,减少维修设备过程中程序的繁杂,便于今后对设备数据的查阅和分析,充分地利用信息资源,避免认为操作错误,节省大量的人力、物力及时间,为管理者提供及时、准确的信息。本系统针对高校实验室设备进行管理,目的是使设备日常的管理更加方便以及统计设备使用,维修和报废的各种情况。以及查询和生成报表的功能。

4.4.3获取方法的使用

  1. 查阅相关资料,了解本系统的研究意义。

  2. 通过查询资料了解该系统要如何做,及要做哪些东西;

  3. 设计出大体上的功能模块,画出模块图;

  4. 通过进一步了解,对需求进行细化,将每一步想清楚,制定出每 一步的做法和注意的地方;

  5. 通过小组内讨论,对系统要求进一步分析确定,建立具体的规格说明;

4.4.5功能需求

  1. 使用者可以查询设备的使用情况如:设备维修记录、设备使用时间、设备购进时间,当前状态等;

  2. 实验室淘汰旧设备时删除该设备的信息:

3)实验室损坏设备记录

4)实验室设备维修记录

5)实验室设备申购与申购记录功能

4.5系统环境

系统输入用户名和密码登陆这套设备管理系统后,应该可以查看本实验室所有登记的设备,还可以进一步查看此设备的相关详细信息,例如设备进入实验室的时间、管理该设备的人员的信息等。

4.5.1外部接口需求

用户接口:本产品的用户需要通过终端进行操作,进入主界面后点击相应的窗口,分别进入相应的界面。用户对程序的维护,最好要有备份;

软硬件接口:使用本产品的软硬件需求如下:

- 采用windows的通用图形届,对用户友好,且必须对鼠标和键盘提供支持

- 支持一般x86,x64系列微机和windows ce,即一般的PC机

- 运行于windowsxp及更高版本具有win32API的操作系统之上

4.5.2性能需求

为了保证系统能够长期、安全、稳定、可靠、高效的运行,实验室设备管理系统应该满足以下的性能需求:

- 系统处理的准确性和及时性

系统处理的准确性和及时性是系统的必要性能。在系统设计和开发过程中,要充分考虑系统当前和将来可能承受的工作量,使系统的处理能力和响应时间能够满足实验室对信息处理的需求

- 系统的易用性和易维护性

系统能够提供良好的用户接口,易用的人机交互界面

- 系统的标准性

系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。所有这些都要符合主流国际、国家和行业标准,保证代码的易读性、可操作性和可移植性。

4.5.3故障处理

程序在运行时主要会出现两种错误,由于输入信息,或无法满足要求时产生的错误,称为软错误;由于其他问题,如数据库连接超时等,产生的问题,称为硬错误;对于软错误,在系统操作过程中,用窗体或者用标签提示出错的信息。对于硬错误,可在出错的相应模块中弹出的出错语句,并将程序重置。

参考文献:

  1. 姜丽,宋建华.高校实验室信息化体系的建设研究[J].实验技术与管理,2018, 35(1):25–36.

  2. 孟令军,刘艳,李臣亮,等.高校实验室信息化综合管理平台的建设[J].中国医学装备,2019(2):117–120.

  3. 廖军,张毅,王成良,等.基于数据智能一体化的实验室云平台的建设与研究[J].实验技术与管理,2020(4):249-252.

  4. 骆斌.丁二玉.需求工程------软件建模与分析(第二版).高等教育出版社

  5. [ Ahmed 2013] AHMED F, CAPRETZ L F, BOUKTIF Set. Soft skills and software development: a reflection from soft-ware industry. International Jourmal of Information Processing and Management(JIPM), 2013, 4:3.

  6. Crone S F, Lessmann S, Stahlbock R. Empirical comparison and evaluation of classifier performance for data mining in customer relationship management neural networks[ C] / /Proceedings of 2004 IEEE International Joint Conference.[ s.l.]: [ s.n.],2004.
    实验室设备管理系统应该满足以下的性能需求:

- 系统处理的准确性和及时性

系统处理的准确性和及时性是系统的必要性能。在系统设计和开发过程中,要充分考虑系统当前和将来可能承受的工作量,使系统的处理能力和响应时间能够满足实验室对信息处理的需求

- 系统的易用性和易维护性

系统能够提供良好的用户接口,易用的人机交互界面

- 系统的标准性

系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。所有这些都要符合主流国际、国家和行业标准,保证代码的易读性、可操作性和可移植性。

4.5.3故障处理

程序在运行时主要会出现两种错误,由于输入信息,或无法满足要求时产生的错误,称为软错误;由于其他问题,如数据库连接超时等,产生的问题,称为硬错误;对于软错误,在系统操作过程中,用窗体或者用标签提示出错的信息。对于硬错误,可在出错的相应模块中弹出的出错语句,并将程序重置。

参考文献:

  1. 姜丽,宋建华.高校实验室信息化体系的建设研究[J].实验技术与管理,2018, 35(1):25–36.

  2. 孟令军,刘艳,李臣亮,等.高校实验室信息化综合管理平台的建设[J].中国医学装备,2019(2):117–120.

  3. 廖军,张毅,王成良,等.基于数据智能一体化的实验室云平台的建设与研究[J].实验技术与管理,2020(4):249-252.

  4. 骆斌.丁二玉.需求工程------软件建模与分析(第二版).高等教育出版社

  5. [ Ahmed 2013] AHMED F, CAPRETZ L F, BOUKTIF Set. Soft skills and software development: a reflection from soft-ware industry. International Jourmal of Information Processing and Management(JIPM), 2013, 4:3.

  6. Crone S F, Lessmann S, Stahlbock R. Empirical comparison and evaluation of classifier performance for data mining in customer relationship management neural networks[ C] / /Proceedings of 2004 IEEE International Joint Conference.[ s.l.]: [ s.n.],2004.

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值