|
|
知识路径： > 电子商务系统程序设计基础 > 电子商务系统规划 >
|
被考次数：7次
被考频率：中频率
总体答错率：49%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：80个
|
|
|
|
|
|
|
|
|
需求分析的任务是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰而且具体的需求。
|
|
|
|
需求分析实际上是调查、评价以至肯定用户对软件需求的过程，其目的在于精化软件的作用范围，也是分析和确认软件系统构成的过程，以确定未来系统的主要成分以及它们之间的接口细节。所以，需求分析实际上是一个对用户意图不断进行揭示和判断的过程，它并不考虑系统的具体实现，而是完整地、严密地描述应当“做什么”的一种过程。
|
|
|
|
首先，把用户提出来的各种问题和要求（这些问题和要求往往是十分模糊的）归纳整理、分析和综合，弄清楚用户想要做什么，应当做什么。把这些作为要求和条件予以明确，这一步称为“用户意图分析”。其次，是在完全弄清用户对软件系统的确切需求的基础上，建立分析模型，从逻辑上完整、严密地描述所要开发的系统，并保证它能满足上述要求和条件。这一步称为“规范化”。
|
|
|
|
|
|
|
|
①系统界面要求。描述软件系统的外部特性，即系统从外部输入哪些数据，系统向外部输出哪些数据。
|
|
|
|
②系统的功能要求。列出软件系统必须完成的所有功能。
|
|
|
|
③系统的性能要求。如响应时间、吞吐量、处理时间等。
|
|
|
|
|
|
⑤系统的运行要求。如对硬件、支撑软件和数据通信接口等的要求。
|
|
|
|
⑥异常处理要求。在运行过程中出现异常情况（如临时性或永久性的资源故障，不合法或超出范围的输入数据、非法操作和数组越界等）时应采取的行动以及希望显示的信息。
|
|
|
|
⑦将来可能提出的要求。主要是为将来可能的扩充和修改做准备。
|
|
|
|
（2）分析软件系统的数据要求。包括基本数据元素、数据元素之间的逻辑关系、数据量和峰值等。常用的数据描述手段是实体-关系模型。
|
|
|
|
（3）导出系统的逻辑模型。在结构化分析方法中可用数据流图来描述；在面向对象分析方法中可用类模型来描述。
|
|
|
|
（4）修正项目开发计划。在明确了用户的真正需求后，可以更准确地估算软件的成本和进度，从而修正项目开发计划。
|
|
|
|
（5）如有必要，可开发一个原型系统。对一些需求不够明确的软件，可以先开发一个原型系统，以验证用户的需求。
|
|
|
|
需要再次强调的是，需求分析阶段主要解决“做什么”的问题，而“怎么做”则由设计阶段来完成。
|
|
|
|
|
|
（1）必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构三个方面，而功能域则反映数据域三个方面的控制信息。
|
|
|
|
（2）可以把一个复杂问题按功能进行分解并可逐层细化。
|
|
|
|
（3）建立模型可以帮助分析人员更好地理解软件系统的信息、功能、行为，这些模型也是软件设计的基础。
|
|
|
|
|
|
|
|
客户访谈是最早开始使用的获取用户需求的方法，也是至今仍然广泛使用的一种需求分析方法。客户访谈是一个直接与客户交流的过程，既可了解高层用户对软件的要求，也可以听取直接用户的呼声。访谈可分为正式的和非正式的两种基本形式。正式访谈时，系统分析员将提出一些用户可以自由回答的开发性问题，以鼓励被访问的人能说出自己的想法，例如，可以询问用户对目前正在使用的系统有哪些不满意的地方、为什么等问题。另外，对一些需要调查大量人员的意见的时候，可以采用向被调查人发调查表的方法进行。然后对收回的调查表仔细阅读，之后系统分析员可以有针对性地访问一些用户，以便向他们了解在分析调查表中所发现的问题。
|
|
|
|
|
|
系统在开始的时候，往往是系统分析员用户领域内的专业知识，而用户也不熟悉计算机知识，这样就造成他们之间的交流存在着巨大的文化差异。因而，需要建立一个由用户、系统分析员和领域专家参加的联合分析小组，由领域专家来沟通。这对系统分析员与用户逐渐的交流和需求的获取将非常有用。另外，特别要重视用户业务人员的作用。
|
|
|
|
|
|
不要期望用户在一两次交谈中，就会对目标系统的需求阐述清楚，也不能限制用户在回答问题的过程中自由发挥。在每次访问之后，要及时进行整理、分析用户提供的信息，去掉错误的、无关的部分，整理有用的内容，以便在下一次与用户见面时由用户确认；同时准备下一次访问用户时更进一步的细节问题。如此循环，大概需要3～5个来回。
|
|
|
|
用传统的常规的需求获取方法定义需求时，用户过于被动，而且往往与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，所以这种方法效果有时不太理想。为了解决这个问题，人们研究出一种面向团队的需求获得方法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。这种方法有许多优点：开发者与用户不分彼此，齐心协力，密切配合，共同完成需求获取工作。感兴趣的读者可以查阅相关资料。
|
|
|
|
|
|
系统分析是研制开发一个电子商务系统最重要的阶段，也是最困难的阶段。系统分析的好坏，直接影响到完成系统的质量、用户的满意度等，甚至直接影响项目的成功与否。
|
|
|
|
系统分析阶段要回答的中心问题是系统要“做什么”，即明确系统功能。这个阶段的成果是逻辑模型。而系统设计阶段要回答的中心问题是系统要“怎么做”，即如何实现系统分析说明书中规定的系统功能。要根据实际技术条件、经济条件和社会环境条件等，确立系统实施方案，建立系统物理模型，具体包括界定系统的外部边界，说明系统的组成及其功能和相互关系，描述系统的处理流程，给出未来系统的结构等。
|
|
|
|
模型是现实的一种抽象表示。一个电子商务系统的模型包括逻辑模型和物理模型两种。
|
|
|
|
逻辑模型也称概念模型，它展示了系统是什么，能够做什么事情。逻辑模型与实现无关，它们独立于任何的技术实现来描述系统。逻辑模型说明了系统的本质。逻辑模型降低了由于过分关注技术细节而丢失业务需求所带来的风险，使我们可以少用技术性的语言与最终用户进行沟通。
|
|
|
|
物理模型有时也称为技术模型，它展示了系统如何去做事情，即系统在实际上以及技术上是如何实现。它们是与实现相关的，反映了技术选择和所选技术的限制等。
|
|
|
|
电子商务系统分析的主要任务就是在系统规划的指导下，通过对企业各部门，各业务的详细调查研究，深入研究现有系统的工作流程，分析用户的需求，得到新系统的逻辑设计方案，以解决系统“能做什么”的问题。需要注意的是：现有系统不只包括企业现有的可在计算机运行的信息系统，也包括企业现有的手工作业条件下的业务流程。
|
|
|
|
系统分析阶段需要系统分析员和用户一起充分理解用户的需求，并把双方都认同的理解用书面文档（系统分析说明书）表达出来。而此系统分析说明书通过审核之后，将作为系统设计的依据和将来验收系统的依据。
|
|
|
|
系统分析阶段的工作必须深入详细，充分调动用户的积极性，系统分析员要与用户精诚合作。除此之外，也需要使用一定的技术与工具。例如图表等，直观的图表既可以帮助系统分析员理清思路，也便于与用户交流。
|
|
|
|
|
|
（1）现行系统详细调查。详尽的调查是系统分析与设计的基础。详细调查现行系统的基本情况和具体结构，并用一定的工具对现行系统进行形象的描述，这是系统分析最基本的任务。详细调查需要组织相关部门的业务人员、主管、系统分析员、系统设计人员的共同参与。系统分析人员要事先制订好调查计划，设计好调查问卷等。调查的具体方法包括阅读书面资料，实地考察，与业务人员进行面谈，发放调查表，请业务专家为系统分析员做专题报告等。
|
|
|
|
（2）需求分析。需求分析在详尽调查的基础上进行分析和综合，并进行评价和检查，进而提出对目标系统的综合要求。主要包括功能需求、性能需求、资源和环境需求、可靠性需求、安全保密需求、用户界面需求、成本消耗与开发进度需求、预先估计的可扩展性需求等。
|
|
|
|
（3）提出新系统逻辑模型。对新系统进行适当的文字说明，将已经得到的确切需求清晰准确地描述，并整理出系统分析报告。
|
|
|
|
逻辑建模过程包括过程建模和数据建模。使用的工具分别为数据流图和数据字典。
|
|
|
|
系统的设计就是在反映用户需求的逻辑方案的基础上，专注于系统的技术性和实现方面，科学合理地使用各种系统设计方法，得到一个详细的计算机系统方案。系统设计也被称为物理设计。
|
|
|
|
系统设计的目标是在保证逻辑模型的实现的基础上，设计出一个易于理解，容易维护的系统，尽可能提高系统的各项指标，即系统的效率、质量、可靠性、可变性和经济性等。系统设计根据系统分析的结果，对新信息系统进行深入设计，设计出一套与改进后的管理体制及管理手段相适应的新的信息系统，并为系统实施阶段的程序设计、调试提供依据。
|
|
|
|
|
|
|
|
模型就是对现实世界特征的模拟和抽象，数据模型是对现实世界数据特征的抽象。对于具体的模型人们并不陌生，如航模飞机、地图和建筑设计沙盘等都是具体的模型。最常用的数据模型分为概念数据模型和基本数据模型。
|
|
|
|
（1）概念数据模型，也称信息模型，是按用户的观点对数据和信息建模，是现实世界到信息世界的第一层抽象，强调其语义表达功能，易于用户理解，是用户和数据库设计人员交流的语言，主要用于数据库设计。这类模型中最著名的是实体联系模型，简称E-R模型。
|
|
|
|
（2）基本数据模型。它是按计算机系统的观点对数据建模，是现实世界数据特征的抽象，用于DBMS的实现。基本的数据模型有层次模型、网状模型、关系模型和面向对象模型（Object Oriented Model）。
|
|
|
|
|
|
数据库结构的基础是数据模型，是用来描述数据的一组概念和定义。数据模型的三要素是数据结构、数据操作和数据的约束条件。
|
|
|
|
（1）数据结构。它是所研究的对象类型的集合，是对系统静态特性的描述。
|
|
|
|
（2）数据操作。对数据库中各种对象（型）的实例（值）允许执行的操作的集合，包括操作及操作规则。如操作有检索、插入、删除和修改，操作规则有优先级别等。数据操作是对系统动态特性的描述。
|
|
|
|
（3）数据的约束条件。它是一组完整性规则的集合。也就是说，对于具体的应用数据必须遵循特定的语义约束条件，以保证数据的正确、有效和相容。例如，某单位人事管理中，要求在职的“男”职工的年龄必须大于18岁小于60，工程师的基本工资不能低于1500元，每个职工可担任一个工种，这些要求可以通过建立数据的约束条件来实现。
|
|
|
|
|
|
概念模型是对信息世界建模，所以概念模型能够方便、准确地表示信息世界中的常用概念。概念模型有很多种表示方法，其中最为常用的是P.P.S.Chen于1976年提出的实体-联系方法（Entity Relationship Approach）。该方法用E-R图来描述现实世界的概念模型，称为实体-联系模型（Entity-Relationship Model，E-R模型）。
|
|
|
|
E-R模型是软件工程设计中的一个重要方法，因为它接近于人的思维方式，容易理解并且与计算机无关，所以用户容易接受，是用户和数据库设计人员交流的语言。但是，E-R模型只能说明实体间的语义联系，还不能进一步地详细说明数据结构。在解决实际应用问题时，通常应该先设计一个E-R模型，然后再把其转换成计算机能接受的数据模型。
|
|
|
|
|
|
在E-R模型中，实体用矩形表示，通常矩形框内写明实体名。实体是现实世界中可以区别于其他对象的“事件”或“物体”。例如，企业中的每个人都是一个实体。每个实体由一组特性（属性）来表示，其中的某一部分属性可以唯一标识实体，如职工号。实体集是具有相同属性的实体集合，例如，学校所有教师具有相同的属性，因此教师的集合可以定义为一个实体集；学生具有相同的属性，因此学生的集合可以定义为另一个实体集。
|
|
|
|
|
|
在E-R模型中，联系用菱形表示，通常菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标注上联系的类型（1:1、1:n或m:n）。实体的联系分为实体内部的联系和实体与实体之间的联系。实体内部的联系反映数据在同一记录内部各字段间的联系。
|
|
|
|
（1）两个不同实体之间的联系。两个不同实体集之间存在如下三种联系类型。一对一（1:1）联系，指实体集E1中的一个实体最多只与实体集E2中的一个实体相联系。一对多（1:n）联系，表示实体集E1中的一个实体可与实体集E2中的多个实体相联系。多对多（m:n）联系，表示实体集E1中的多个实体可与实体集E2中的多个实体相联系。
|
|
|
|
|
|
电影院里一个座位只能坐一个观众，因此观众与座位之间是一个1:1的联系，联系名为V_S，用E-R图表示如下图（a）所示。
|
|
|
|
部门DEPT和职工EMP实体集，若一个职工只能属于一个部门，那么这两个实体集之间应是一个1:n的联系，联系名为D_E，用E-R图表示如下图（b）所示。
|
|
|
|
工程项目PROJ和职工EMP实体集，若一个职工可以参加多个项目，一个项目可以有多个职工参加，那么这两个实体集之间应是一个m:n的联系，联系名为PR_E，用E-R图表示如下图（c）所示。
|
|
|
|
|
|
|
|
（2）两个以上不同实体集之间的联系。两个以上不同实体集之间存在1:1:1、1:1:n、1:m:n和r:m:n的联系。例如，下图表示了三个不同实体集之间的联系。其中：
|
|
|
|
下图（a）表示供应商Supp、项目Proj和零件Part之间多对多对多（r:n:m）的联系，联系名为SP_P。表示供应商为多个项目供应多种零件，每个项目可用多个供应商供应的零件，每种零件可由不同的供应商供应的语义。
|
|
|
|
下图（b）表示病房、病人和医生之间一对多对多（1:n:m）的联系，联系名为P_D。表示一个特护病房有多个病人和多个医生，一个医生只负责一个病房，一个病人只属于一个病房的语义。
|
|
|
|
|
|
|
|
注意，三个实体集之间的多对多联系和三个实体集两两之间的多对多联系的语义是不同的。例如，供应商和项目实体集之间的“合同”联系，表示供应商为哪几个工程签了合同。供应商与零件两个实体集之间的“库存”联系，表示供应商库存零件的数量。项目与零件两个实体集之间的“组成”联系，表示一个项目由哪几种零件组成。
|
|
|
|
（3）同一实体集内的二元联系。同一实体集内的各实体之间也存在1:1、1:n和m:n的联系，如下图所示。
|
|
|
|
|
|
|
|
从图中可见，职工实体集中的领导与被领导联系是1:n的。但是，职工实体集中的婚姻联系是1:1的。
|
|
|
|
|
|
|
|
|
|
说明1：在E-R图中，实体集中作为主码的一部分属性以下划线标明。另外，在实体集与联系的线段上标上联系的类型。
|
|
|
|
说明2：在本书中，若不引起误解，实体集有时简称实体，联系集有时简称联系。
|
|
|
|
|
|
层次模型（Hierarchical Model）采用树型结构表示数据与数据间的联系。在层次模型中，每一个节点表示一个记录类型（实体），记录之间的联系用节点之间的连线表示，并且根节点以外的其他节点有且仅有一个双亲节点。
|
|
|
|
层次模型不能直接表示多对多的联系。若要表示多对多的联系，可采用如下两种方法。
|
|
|
|
（1）冗余节点法。两个实体的多对多联系转换为两个一对多联系。该方法的优点是节点清晰，允许节点改变存储位置。缺点是需要额外的存储空间，有潜在的数据不一致性。
|
|
|
|
（2）虚拟节点分解法。将冗余节点转换为虚拟节点。虚拟节点是一个指引元，指向所代替的节点。该方法的优点是减少对存储空间的浪费，避免数据不一致性。缺点是改变存储位置可能引起虚拟节点中指针的修改。
|
|
|
|
层次模型的特点是记录之间的联系通过指针实现，比较简单，查询效率高。
|
|
|
|
层次模型的缺点是只能表示1:n的联系，尽管有许多辅助手段实现m:n的联系，但较复杂不易掌握；由于层次顺序严格和复杂，插入删除操作是限制比较多，导致应用程序编制比较复杂。1968年，美国IBM公司推出的IMS系统（信息管理系统）是典型的层次模型系统，20世纪70年代在商业上得到了广泛的应用。
|
|
|
|
|
|
需求分析阶段除了使用以上介绍的数据流图和数据字典外，还经常利用一些图形工具来描述复杂的数据关系和逻辑处理功能，图形比文字叙述更形象直观，且更容易理解。在需求分析阶段还可能用到另外三种图形工具：层次方框图、Warnier图和IPO图。
|
|
|
|
|
|
层次方框图是由一系列多层次的树形结构的矩形框组成，用来描述数据的层次结构。层次方框图的顶层是一个单独的矩形框，它代表数据结构的整体，下面各层的矩形框代表这个数据结构的子集，最底层的各个框代表组成这个数据是不能再分割的基本元素。随着结构描述的向下层的细化，层次方框图对数据结构的描述也越来越详细，系统分析员从顶层数据开始分类，沿着图中每条路径不断细化，直到确定了数据结构的全部细节时为止，这种处理模式很适合需求分析阶段的需要。但在使用中需要注意，方框之间的联系表示组成关系，不是调用关系，因为每个方框不是模块。
|
|
|
|
|
|
Warnier图是表示信息层次体系的一种图形工具，是法国计算机科学家J.D.Warnier提出来的。Warnier图又称Warnier—Orr图，同层次方框图类似，也可以用来描述树形结构的信息，可以指出一类信息或一个信息是重复出现的，也可指明信息是有条件出现的。在Warnier图中使用以下几种符号。
|
|
|
|
|
|
②异或符号“++”指出一个信息类或一个数据元素在一定条件下出现，符号上、下方的名字代表的数据只能出现一个。
|
|
|
|
|
|
|
|
IPO（Input—Process—Output）图即为输入一处理一输出图，是美国IBM公司发展完善起来的一种图形工具，它使用的基本符号少而简单，因此易学易懂。它的基本形式是画三个方框，在左边的框中列出有关输入数据，在中间框内列出主要处理，在右边的框内列出产生的输出数据。处理框中列出的处理次序是按执行顺序书写的。但是这些符号还不能精确地描述执行处理的详细情况，在IPO图中，还用类似向量符号的空心箭头清楚地指出数据流向的情况。
|
|
|
|
|
|
通过可行性分析、需求分析阶段的工作，我们已经分析并定义了与软件开发目标相关的各种模型、分析出了软件的功能、性能要求等，解释了“软件目标是什么”的问题。在系统方案阶段，主要完成的工作则是解释“软件如何实现”的问题。
|
|
|
|
|
|
在问题定义阶段得到的软件概念模型使用各种工具定义了软件项目的开发目标。在系统方案制定阶段才开始真正考虑如何去实现软件。其中最重要的工作，就是制定软件的实现架构。
|
|
|
|
通过使用软件架构技术的各种逻辑视图、进程视图、物理视图、开发视图、场景视图，具体描述软件系统的高阶抽象模型，揭示了系统需求和构成系统的元素之间的对应关系，指导后续软件的分析。
|
|
|
|
|
|
实现要素对应于软件目标实现最重要的场景，表示了整个系统最主要的控制流程和实现机制。其中分析模型的结果，可能是采用结构化分析方法得到的功能分解体系，或面向对象的类和对象—关系图、对象—行为图。取决于具体选择的设计分析方法。
|
|
|
|
|
|
.关键的用例、最主要的控制类、功能的组织和调度方式。
|
|
|
|
|
|
.对象（OOAD）或程序模块（结构化方法）的组织模式。
|
|
|
|
|
|
|
|
|
|
.选定基础计算平台，如操作系统、数据库、Web服务器、中间件平台等。
|
|
|
|
.选定开发工具和开发环境，如计算机语言、构件库、工具软件等。
|
|
|
|
.确定项目的组织方法、管理要件（如配置管理、需求管理、知识管理）方案。
|
|
|
|
|
|
|
|
通常，总是有一些标准的计算体系可供选择（如Windows DNA、J2EE），对于大多数软件开发项目来说，可通过比较各种标准计算体系与预期目标之间的匹配程度选定计算体系。选择标准的计算体系去实现软件可忽略大多数基础平台和底层支撑技术的实现问题，从而大大提高软件质量、降低开发风险和成本。通常，可以根据基础平台的功能和性能指标、公司或项目组的技术积累、要开发软件系统的特点和分层方式等选定标准的计算平台。典型的系统分层方式包括如下几种：
|
|
|
|
|
|
.多层结构的技术组成模型：表现层、中间层、数据层。
|
|
|
|
.网络系统的常用三层结构：核心层、汇聚层、接入层。
|
|
|
|
.RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层。
|
|
|
|
.B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理层。
|
|
|
|
.六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层。
|
|
|
|
在其他一些情况下，出于各种诸如用户指定，与用户现有的IT设施保持一致性、兼容性、扩展性、未来的维护能力等因素，软件的基础平台很可能在项目的论证阶段就已经被确定下来，如操作系统、数据库系统、Web服务器、开发工具或开发环境等。在这种情况下，软件的计算体系实际上已经确定。
|
|
|
|
|
|
通过将前面得到的软件功能清单和软件实现的各种关键要素整理并分类，然后与现有的软件技术、标准的软件实现体系进行比较和匹配，就可以将软件概念模型定义的开发目标，进一步映射到真正可计算、可实现的软件架构上。
|
|
|
|
这个过程可以理解为一种不断归结、比较并匹配、设计以及分配的过程。进行匹配的过程常常是一种双向的选择和探究过程，一方面我们拿出一个软件目标中的功能或实现要素，询问：这部分功能属于表示层、业务逻辑，还是数据服务？另一方面，我们也研究标准计算体系提供的功能以及现有开发团队的技术能力和积累，例如：放在业务逻辑层合适吗？该体系的实现技术是什么？存在可复用的标准构件吗？如果开发则具体内容是什么？一旦完成了比较、匹配、分配、确认的过程，也就确认了从总体设计到具体模块开发的各层次上需要完成的工作内容。
|
|
|
|
归结设计要素的过程，可以看作是一个全面设计在头脑中不断演算、细化、规划评估、分配的快速过程，也是高度技术导向的。为了完成这一过程，系统分析员必须对流行的计算体系、实现技术、软件工具和方法以及模式、实现难度和代价等了如指掌，还必须具有一种兼顾总体把握和细微探究的能力，才能完成系统方案的制定、评价和改进。
|
|
|
