|
|
知识路径： > 电子商务系统程序设计基础 > 电子商务系统规划 >
|
被考次数：7次
被考频率：中频率
总体答错率：44%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
相关知识点：78个
|
|
|
|
|
|
|
电子商务应用系统的需求调查过程是各类原始素材的收集过程，相应的信息收集方法大致有以下几种：
|
|
|
|
|
|
尽可能地对所有数据载体（各类表格、记录、报告、手册等）以及岗位责任制、职责范围、规程手册、业务书籍等进行收集，掌握它们的来龙去脉、涉及范围。特别值得注意的是规程手册和与该企业有关的相关业务书籍。通过仔细阅读，掌握该企业的基本业务术语和主要业务流程，以减少有关术语的歧义性，增加需求分析的准确度。
|
|
|
|
|
|
它又叫做直接观察法。实地观察的一个目的就是尽可能接近事件发生地，去研究真实系统。作为观察者要遵循一定的规则，在观察时尽可能多听、少说或不说；特别要注意那些一闪即逝的有用的信息。观察内容包括现有系统的实际布局、人员的安排、各项活动及工作情况。通过实地观察，可以增加系统开发人员的感性认识，有助于加快对业务流程与活动的理解。
|
|
|
|
|
|
调查表是一种具有特殊目的的文档，调研人员可以从它那里收集信息和观点。调查表方式的优点在于比较省时间，执行起来需要较少的技巧，问卷者有时间思考、计算、查阅资料，提供的信息更准确，能够相对廉价的从大量的人中收集数据，允许匿名填写，答案可以快速地表格化和分析等。缺点是回收率可能比较低，很多人难于清楚地表达自己的观点，尤其是回答发挥式问题时，许多人不愿动笔。此外，设计一个好的调查表往往不容易。
|
|
|
|
|
|
面谈是一种调查研究技术，调研人员借此从个人那里通过面对面的交流收集信息。一般认为个人面谈是最重要和最常用的调查研究技术。面谈可以用来实现如下目标：发现事实、验证事实、澄清事实、激发热情、让最终用户参与、确定需求以及征求想法和观点。这种方法的成功与否主要依赖于调研人员的提问水平。
|
|
|
|
|
|
（1）事先安排好时间、地点、面谈人员、顺序，保证清静的环境，使面谈不易被打断。
|
|
|
|
（2）最好准备一个面谈提纲或问卷。从系统目标出发，加上主观判断，规定调查的思路。不应该带着主观偏见去收集信息，但如果没有主观上规定数据的范围，而是以相同的权重看待所有信息，则只可能眉毛胡子一把抓，丢失重点。在面谈开始时应该首先交待清楚面谈的目的和内容，然后作为聆听者而非答辩者来展开具体的谈话，面谈时既要把握重点，又要注意提纲尚未出现但很可能很重要的信息。
|
|
|
|
（3）提的问题应该明确简洁，尽量使用清楚精确的语言。注意提问的方式与问题的提出顺序。
|
|
|
|
|
|
|
|
|
|
|
|
对于某些需要电子商务应用系统特别支持的业务需求或比较复杂的业务需求，最好能请有关人员为应用系统调研人员作专题报告。专题报告由报告人认真准备，故系统性、逻辑性、完整性、准确性都较强，极好地提高了调研效率。
|
|
|
|
采用上述五种主要的方法收集了信息后，应当将其记录下来，作为可行性分析报告的一部分，并且记录应当尽量完整、明确、可验证等。对企业信息的收集是新应用系统可行性研究阶段和系统分析阶段所必须进行的工作内容，无论是可行性研究阶段还是系统分析阶段均可采用上述方法，但是调查的程度有所不同：可行性研究阶段的调查不必非常详细，而系统分析阶段的调查则越详细越好。
|
|
|
|
|
|
在应用系统的目标需求已经确定，对系统的基本又有所了解的情况下，系统分析人员就可以进行可行性分析。
|
|
|
|
可行性分析就是根据系统的环境、资源等条件，判断新系统的建设项目是否有必要、有可能开始进行。做出这个决定的前提是明确和量化了目标，没有明确的定量检查目标，便无法进行可行性分析。
|
|
|
|
|
|
|
|
运行可行性是对方案在组织中的合适程度的度量，也是人们对该系统的感觉的度量。运行可行性的以下两个方面需要考虑：
|
|
|
|
（1）问题是否值得解决，或者问题的解决方案能工作吗？
|
|
|
|
（2）用户和管理人员对问题或问题的解决方案感觉如何？
|
|
|
|
我们不仅要评价一个系统是否能够满足功能性和非功能性需求，而且还要评价它是否受到管理层、最终用户等的支持，因为一个可以工作的方案仍可能由于最终用户和管理层的抵制而落选。
|
|
|
|
|
|
分析所提出的要求在现有技术水平下是否有可能实现。这里所说的现有水平，是指社会上已经比较普遍地使用了的技术，不应该把尚在实验室里的新技术作为讨论的依据。
|
|
|
|
技术可行性主要涉及三个问题：建议的技术或方案在现有技术水平下是否可以实现？企业目前拥有所需的技术吗？企业拥有所需的技术专家吗？
|
|
|
|
|
|
从经济上考虑，包括对项目所需费用的预算和对项目效益的估算。这是非常重要的，如果忽略了，就会造成巨大的损失。在估算的过程中常常把费用估计低了而把收益估计高了，这是因为人们在考虑问题的时经常忽略一些重要的因素。例如人们在考虑费用的时候，常常是：
|
|
|
|
（1）只考虑了计算机的费用，而低估了外围设备的费用；
|
|
|
|
|
|
（3）只考虑了研制系统时所需要的一次性投资，而忘记或低估了日常运行的维持性费用（如备件、打印纸等各种耗材）；
|
|
|
|
（4）只考虑了设备材料等物资的费用，而忘记或低估了人员技术培训的费用。
|
|
|
|
所有这些都使人们低估了改善应用系统的费用。另一方面，对于项目的收益，人们往往把引入应用系统后所增加的信息处理能力，与实际发展出来的效益混为一谈。必须明确，当我们引进计算机或其他新技术的时候，只是使应用系统在某一环节增加了处理能力。
|
|
|
|
|
|
要考虑各种社会因素，才能确定项目是否可行。由于电子商务应用系统是在社会环境中工作的，除了技术和经济等因素之外，还有许多社会因素对于项目的开展起着制约的作用。与项目有直接关系的人、处于变动中的企业的管理制度、工作人员的文化水平等等都必须作为社会和人的因素考虑在内。
|
|
|
|
总之我们需要从上述四个方面来判断项目是否具备开始进行的各种必要条件，这就是可行性分析。在可行性分析之后，应该把分析结果用可行性报告的形式编写出来，形成正式的工作文件。这个报告非常必要，因为我们把项目的目标用我们的语言表达出来，并按照我们的理解把它明确化、定量化，列出优选顺序并进行权衡考虑，这些是否符合使用者的原意，有没有偏离使用者的目标，都还没有得到验证。虽然我们尽力去体会使用者的意图，但是，由于工作背景和职业的差别，仍然难免发生一些误解和疏漏。因此，与使用者交流，请他们审核可行性分析报告也是非常必要的。
|
|
|
|
可行性报告的结果不一定可行，也有可能是得出在目前条件下不可行的结论，这是完全正常的。如果限定必须证明可行，那么可行性分析就没有意义了。判断不可行性比判断可行性的收获还大，因为这就避免了巨大的浪费。另外，可行性分析的结果也有可能是要求做一些局部的修改。
|
|
|
|
对可行性报告的讨论是研制过程中的关键步骤，必须在项目的目标及可行性问题上和领导及管理人员取得一致的认识，才能正式开始项目的详细调查研究。为了做好这一次讨论，在条件许可的情况下，可以请一些外单位的参加过类似系统研制的专家来讨论。他们的经验以及他们局外人的立场都有利于对于项目目标和可行性做出更准确的表达、判断与论证。可行性报告通过之后，项目就进入了实质性的阶段。
|
|
|
|
|
|
|
|
分析员对关键人员进行调查访问，仔细阅读和分析有关材料，以便对问题定义阶段书写的关于系统的规模和目标的报告书进行进一步的复查和确认，清晰地描述对目标系统的一切限制和约束，改正规模或不确切的叙述，确保分析员正在解决的问题确实是用户要求他解决的问题，这是这一步的关键。
|
|
|
|
|
|
目前正在使用的系统可能是一个人工操作系统，也可能是旧的计算机系统，旧的系统必然有某些缺陷，因而需要开发一个新的系统且必须能解决旧系统中存在的问题。那么现有的系统就是信息的重要来源。人们需要研究现有系统的基本功能，存在哪些问题，运行现有系统需要多少费用，对新系统有什么新要求，新系统运行时能否减少使用费用等。
|
|
|
|
应该仔细收集、阅读、研究和分析先有系统的文档资料和使用手册，实地考察现有系统。观察现有系统可以做什么，为什么这样做，有何缺点，使用代价以及其他系统的联系等，但并不了解它怎样做这些工作。分析人员在考察的基础上，访问有关人员，画出描绘现有系统的高层系统流程图，有关人员一切审查该系统流程图是否正确，为目标系统的实现提供参考。
|
|
|
|
|
|
比较理想的设计通常总是从现有的物理系统出发，推导出现有系统的逻辑模型，由此再设想目标系统的逻辑模型，从而构造新的物理系统，然后使用建立逻辑模型的工具—数据流图和数据字典，来描绘数据在系统中流动和处理情况。数据流图和数据字典共同定义了新系统的逻辑模型，为目标系统的设计打下了基础。但要注意，现在还不是软件需要分析阶段，只是概括地描绘高层的数据处理和流动。
|
|
|
|
|
|
分析人员建立了系统的高层逻辑模型之后，分析人员和用户有必要一起再复查问题的定义、工程模型和目标。如有疑义，应予以修改，直到提出的逻辑模型完全符合系统目标为止。在此基础上，分析员从他建立的系统逻辑模型出发，进一步导出若干个较高层次的（较抽象的）物理解法，根据经济可行性、技术可行性、操作可行性、法律可行性对各种方案进行评估，去掉行不通的解，就得到了可行的解法。
|
|
|
|
|
|
根据可行性研究结果，分析人员应做出关键性的决定，即这项工程是否值得去开发。如果值得去开发，应该选择一种最好的解法，并说明该方案是可行的原因和理由。特别是对所推荐的可行方案要进行比较详细的成本／效益分析，供使用部门决策。
|
|
|
|
|
|
计划中除工程进度表之外，还应估计对各种开发人员和各种软、硬件资源的需要情况，初步估计系统生存周期每个阶段的成本，给出需求分析阶段的详细进度表和成本估计。
|
|
|
|
|
|
应该把上述可行性研究各个步骤的结果写成可行性研究报告，提请用户和使用部门仔细审查，从而决定该项目是否进行开发，是否接受分析员推荐的方案。
|
|
|
|
|
|
结构化分析（Structured Analysis，SA）方法是一种面向数据流的需求分析方法，也是一种建模活动。适用于分析大型数据处理系统，是一种简单、实用的方法，现在已经得到广泛的使用。
|
|
|
|
结构化分析方法的基本思想是自顶向下逐层分解。分解和抽象是人们控制问题复杂性的两种基本手段。对于一个复杂的问题，人们很难一下子考虑问题的所有方面和全部细节，通常可以把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题，经过多次逐层分解，每个最底层的问题都是足够简单，容易解决的，于是复杂的问题也就迎刃而解了。这个过程就是分解的过程。
|
|
|
|
SA方法的分析结果由以下几部分组成：一套分层的数据流图、一本数据词典、一组小说明（也称加工逻辑说明）、补充材料。
|
|
|
|
数据流图或称数据流程图（Data Flow Diagram，DFD），是一种便于用户理解、分析系统数据流程的图形工具。它摆脱了系统的物理内容，精确地在逻辑上描述系统的功能、输入、输出和数据存储等，是系统逻辑模型的重要组成部分。
|
|
|
|
|
|
|
|
|
|
|
|
（1）外部实体（外部主体）。外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地和系统所产生的数据的归宿地。
|
|
|
|
（2）加工。加工描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流。每个加工有一个名字和编号。编号能反映出该加工位于分层DFD中的哪个层次和哪张图中，也能够看出它是哪个加工分解出来的子加工。
|
|
|
|
（3）数据存储。数据存储用来表示存储的数据，每个数据存储都有一个名字。
|
|
|
|
（4）数据流。数据流由一组固定成分的数据组成，表示数据的流向。值得注意的是，DFD中描述的是数据流，而不是控制流。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个合适的名字，以反映该数据流的含义。
|
|
|
|
|
|
（1）画系统的输入和输出。把整个软件系统看作一个大的加工，然后根据系统从哪些外部实体接收数据流，以及系统发送数据流到哪些外部实体，就可以画出系统的输入和输出图，这张图称为顶层图。
|
|
|
|
（2）画系统的内部。将顶层图的加工分解成若干个加工，并用数据流将这些加工连接起来，使得顶层图中的输入数据经过若干个加工处理后变换成顶层图的输出数据流。这张图称为0层图。从一个加工画出一张数据流图的过程实际上就是对这个加工的分解。
|
|
|
|
可以用下述的方法来确定加工：在数据流的组成或值发生变化的地方应画一个加工，这个加工的功能就是实现这一变化；也可根据系统的功能确定加工。
|
|
|
|
确定数据流的方法：当用户把若干个数据看作一个整体来处理（这些数据一起到达，一起加工）时，可把这些数据看成一个数据流。
|
|
|
|
对于一些以后某个时间要使用的数据可以组织成一个数据存储来表示。
|
|
|
|
（3）画加工的内部。把每个加工看作一个小系统，该加工的输入输出数据流看成小系统的输入输出数据流。于是可以用与画0层图同样的方法画出每个加工的DFD子图。
|
|
|
|
（4）对第（3）步分解出来的DFD子图中的每个加工，重复第（3）步的分解，直至图中尚未分解的加工都足够简单（也就是说这种加工不必再分解）为止。至此，得到了一套分层数据流图。
|
|
|
|
|
|
对于一个软件系统，其数据流图可能有许多层，每一层又有许多张图。为了区分不同的加工和不同的DFD子图，应该对每张图和每个加工进行编号，以利于管理。
|
|
|
|
（1）父图与子图。假设分层数据流图里的某张图（记为图A）中的某个加工可用另一张图（记为图B）来分解，称图A是图B的父图，图B是图A的子图。在一张图中，有些加工需要进一步分解，有些加工则不必分解。因此，如果父图中有n个加工，那么它可以有0～n张子图（这些子图位于同一层），但每张子图都只对应于一张父图。
|
|
|
|
（2）编号。顶层图只有一张，图中的加工也只有一个，所以不必编号。0层图只有一张，图中的加工号可以分别是0.1，0.2，…或者是1，2，…。子图号就是父图中被分解的加工号。图的加工号由图号、圆点和序号组成。例如，某图中的某加工号为2.4，这个加工分解出来的子图号就是2.4，子图中的加工号分别为2.4.1，2.4.2，…。
|
|
|
|
|
|
①适当地为数据流、加工、数据存储、外部实体命名，名字应反映该成分的实际含义，避免空洞的名字。
|
|
|
|
|
|
|
|
④一个加工的输出数据流不应与输入数据流同名，即使它们的组成成分相同。
|
|
|
|
⑤允许一个加工有多条数据流流向另一个加工，也允许一个加工有两个相同的输出数据流流向两个不同的加工。
|
|
|
|
⑥保持父图与子图平衡。也就是说，父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量和名字上相同。值得注意的是，如果父图的一个输入（或输出）数据流对应于子图中几个输入（或输出）数据流，而子图中组成这些数据流的数据项全体正好是父图中的这一个数据流，那么它们仍然算是平衡的。
|
|
|
|
⑦在自顶向下的分解过程中，若一个数据存储首次出现时只与一个加工有关，那么这个数据存储应作为这个加工的内部文件而不必画出。
|
|
|
|
⑧保持数据守恒。也就是说，一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据。
|
|
|
|
|
|
⑩在整套数据流图中，每个数据存储必须既有读的数据流，又有写的数据流。但在某一张子图中可能只有读没有写，或者只有写没有读。
|
|
|
|
|
|
数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项作出说明。其中对加工的描述称为“小说明”，也可以称为“加工逻辑说明”。
|
|
|
|
|
|
数据字典有以下四类条目：数据流、数据项、数据存储和基本加工。数据项是组成数据流和数据存储的最小元素。源点、终点不在系统之内，故一般不在字典中说明。
|
|
|
|
（1）数据流条目。数据流条目给出了DFD中数据流的定义，通常列出该数据流的各组成数据项。在定义数据流或数据存储组成时，使用下表给出的符号。
|
|
|
|
|
|
|
|
|
|
（2）数据存储条目。数据存储条目是对数据存储的定义。
|
|
|
|
（3）数据项条目。数据项条目是不可再分解的数据单位。
|
|
|
|
（4）加工条目。加工条目是用来说明DFD中基本加工的处理逻辑的，由于下层的基本加工是由上层的加工分解而来，只要有了基本加工的说明，就可理解其他加工。
|
|
|
|
|
|
字典管理主要是把词典条目按照某种格式组织后存储在字典中，并提供排序、查找和统计等功能。如果数据流条目包含了来源和去向，文件条目包含了读文件和写文件，还可以检查数据字典与数据流图的一致性。
|
|
|
