第2章  可行性研究

 

• 目的：用最小的代价在尽可能短的时间内确定问题是否能够解决。

• 任务：确定问题是否值得去解决。

• 首先需要进一步分析和澄清问题定义。

      分析问题定义阶段初步确定的规模和目标，正确的加以肯定，有错误及时改正，对目标系统有任何约束和限制，必须把它们清楚地列举出来。   

 

 

问题定义的内容

•问题的背景

•开发系统的现状

•开发的理由和条件

•开发系统的问题要求、总体要求

•问题的性质、类型范围

•要实现的目标

•功能规模

•实现目标的方案

•开发的条件、环境要求

 

 

问题定义举例

      项目：教材销售系统

•                背景：人工销售效率低，容易出错

•                项目目标：建立一个高效率的、无差错的微机教材销售系统

•                项目范围：硬件利用现有微机，软件开发费用不超过5000元

•                初步设想：增加缺书统计与采购功能

•                可行性研究：建议进行一周，费用不超过500元

 

 

学生选课注册系统的《目标和范围说明书》

项目：学生注册选课系统。

•                 问题：在学分制试行过程中，学生选课进行人工注册效率低，容易冲突，任课教师难以获得及时有效的课程选修学生名单。

•                 项目目标：建立一个基于教学管理计算机网络的学生学期选课注册系统。

•                 项目范围：硬件主要利用现有计算机教学管理网络，增配少量专用设备，软件开发费用预期2800元。

•                 初步设想：为学生提供填写选课卡片和计算机网络终端查询对话两种选课方式，教学管理科能够对选课冲突学生进行随即查询，确定调整。系统主要输出课程注册数据库、学生课程表、课程成绩记载单。

•                 可行性研究：由分析员和教学管理科进行，主要对系统实施方案和学校学生选课管理规程进行研究。建议进行大约10天，费用不超过200元。

 

 

2.1  可行性研究的任务

确定问题是否值得去解决的下一步。

 

•导出系统的逻辑模型。

  探索若干种可供选择的主要解法(即系统实现方案)。从下述三方面研究每种解法的可行性：

(1) 技术可行性，使用现有的技术能实现这个系统吗?

(2) 经济可行性，这个系统的经济效益能超过它的开发成本吗?

(3) 操作可行性，系统的操作方式在这个用户组织内行得通吗?

 

    可行性研究最根本的任务是对以后的行动方针提出建议。

    如果问题没有可行的解，分析员应该建议停止这项开发工程。

    如果问题值得解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。

    可行性研究需要的时间长短取决于工程的规模。一般说来，可行性研究的成本只是预期的工程总成本的5%～10%。

 

2.2  可行性研究过程

可行性研究过程有下述一些步骤。

1. 复查系统规模和目标

   确保分析员正在解决的问题确实是要求他解决的问题。

2. 研究目前正在使用的系统

    现有的系统是信息的重要来源。新的目标系统必须也能完成它的基本功能；

    另一方面，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。

3. 导出新系统的高层逻辑模型

（数据流图和数据字典）。

4. 进一步定义问题

    分析员应该和用户一起再次复查问题定义、工程规模和目标，以数据流图和数据字典作为讨论的基础。

    可行性研究的前4个步骤实质上构成一个循环。

    定义问题，分析这个问题，导出一个试探性的解；

    在此基础上再次定义问题，再一次分析这个问题，修改这个解；

    继续这个循环过程，直到提出的逻辑模型完全符合系统目标。

5. 导出和评价供选择的解法

    分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法供比较和选择。

   为每个在技术、操作和经济等方面都可行的系统制定实现进度表。

6. 推荐行动方针

    是否继续进行这项开发工程。

7. 草拟开发计划

    制定工程进度表

    估计对各类开发人员和各种资源的需要情况，指明什么时候使用以及使用多长时间。

    估计系统生命周期每个阶段的成本。

    给出下一个阶段(需求分析)的详细进度表和成本估计。

8. 书写文档提交审查

    把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。

 

2.3  系统流程图

    系统流程图是概括地描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序，文档，数据库，人工过程等)。

    系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流程图。

 

2.3.1  符号

    当以概括的方式抽象地描绘一个实际系统时，仅仅使用图2.1中列出的基本符号就足够了。

    当需要更具体地描绘一个物理系统时还需要使用图2.2（见书29页）中列出的系统符号。

    利用这些符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件（或数据库），把抽象处理具体化为特定的程序或手工操作等。

 

 

图2.1 基本符号

2.3.2  例子

    举例说明系统流程图的用法。

    某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。

    当仓库中零件数量有变化时，应该及时修改库存清单主文件，

    如果哪种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便定货，规定每天向采购部门送一次定货报告。

    该装配厂使用一台小型计算机处理更新库存清单主文件和产生定货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的定货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出定货报告。图2.3的系统流程图描绘了上述系统的概貌。

    图中每个符号用黑盒子形式定义了组成系统的一个部件，然而并没有指明每个部件的具体工作过程；图中的箭头确定了信息通过系统的逻辑路径。

系统流程图的习惯画法是使信息在图中从顶向下或从左向右流动。

 

图2.3 库存清单系统的系统流程图

 

2.3.3  分层

    面对复杂的系统时，一个比较好的方法是分层次地描绘这个系统。

    首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。

    然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。

    这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。

2.4  数据流图

    数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。

    数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具。

     此外，设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，所以它也是今后进行软件设计的很好的出发点。

2.4.1 
符号

    如图2.4(a)（见书31页）所示，数据流图有四种基本符号：正方形(或立方体)表示数据的源点或终点；圆角矩形(或圆形)代表变换数据的处理；开口矩形(或两条平行横线)代表数据存储；箭头表示数据流，即特定数据的流动方向。

    注意，数据流与程序流程图(参看本书第5章)中用箭头表示的控制流有本质不同，千万不要混淆。

    在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件（无法表示分支条件或循环）。

    处理并不一定是一个程序。一个处理框可以代表一系列程序、单个程序或者程序的一个模块；它甚至可以代表用穿孔机穿孔或目视检查数据正确性等人工处理过程。

    一个数据存储也并不等同于一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等；数据可以存储在磁盘、磁带、磁鼓、主存、微缩胶片、穿孔卡片及其他任何介质上(包括人脑)。

    数据存储和数据流都是数据，仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。

    通常在数据流图中忽略出错处理，也不包括诸如打开或关闭文件之类的内务处理。

    数据流图的基本要点是描绘“做什么”而不考虑“怎样做”。

    有时数据的源点和终点相同，如果只用一个符号代表数据的源点和终点，则至少将有两个箭头和这个符号相连(一个进一个出)，可能其中一条箭头线相当长，这将降低数据流图的清晰度。另一种表示方法是再重复画一个同样的符号(正方形或立方体)表示数据的终点。

    有时数据存储也需要重复，以增加数据流图的清晰程度。为了避免可能引起的误解，如果代表同一个事物的同样符号在图中出现在n个地方，则在这个符号的一个角上画（n-1）条短斜线做标记。

    除了上述4种基本符号之外，有时也使用几种附加符号。图2.4(b)给出了这些附加符号的含义。

2.4.2  例子

    假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。

    对于需要再次定货的零件应该列出下述数据：

    零件编号，零件名称，定货数量，目前价格，主要供应者，次要供应者。

    零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。

 

数据流图有4种成分：

    源点或终点，处理，数据存储和数据流。

    因此，第一步可以从问题描述中提取数据流图的4种成分：

• 首先考虑数据的源点和终点

    从上面对系统的描述可以知道“采购部每天需要一张定货报表”，“通过放在仓库中的CRT终端把事务报告给定货系统”，所以采购员是数据终点，而仓库管理员是数据源点。

•处理

    再一次阅读问题描述，“采购部需要报表”，显然他们还没有这种报表，因此必须有一个用于产生报表的处理。

    事务的后果是改变零件库存量，然而任何改变数据的操作都是处理，因此对事务进行的加工是另一个处理。

    注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。

•  数据流：

     系统把定货报表送给采购部，因此定货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。

• 数据存储：

    产生报表和处理事务这两个处理在时间上明显不匹配——

    每当有一个事务发生时立即处理它，

    然而每天只产生一次定货报表。

    因此，用来产生定货报表的数据必须存放一段时间，也就是应该有一个数据存储。

    注意，并不是所有数据存储和数据流都能直接从问题描述中提取出来。

 

    数据流图是系统的逻辑模型，然而任何计算机系统实质上都是信息处理系统，也就是说计算机系统本质上都是把输入数据变换成输出数据。

    因此，任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。

    对于上述的定货系统可以画出图2.5这样的基本系统模型。

 

图2.5 定货系统的基本系统模型

 

    从基本系统模型这样非常高的层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据源点/终点是一目了然的，因此它是很有价值的通信工具。

    然而，图2.5毕竟太抽象了，从这张图上对定货系统所能了解到的信息非常有限。

    下一步应该把基本系统模型细化，描绘系统的主要功能。

    从表2.1可知，“产生报表”和“处理事务”是系统必须完成的两个主要功能，它们将代替图2.5中的“定货系统”(图2.6)。

 

    此外，细化后的数据流图中还增加了两个数据存储：

    处理事务需要“库存清单”数据；

    产生报表和处理事务在不同时间，因此需要存储“定货信息”。

    除了表2.1中列出的两个数据流之外还有另外两个数据流，它们与数据存储相同。

    这是因为从一个数据存储中取出来的或放进去的数据通常和原来存储的数据相同，也就是说，数据存储和数据流只不过是同样数据的两种不同形式。

    在图2.6中给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。

 

图2.6 定货系统的功能级数据流图

 

    接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。

    考虑通过系统的逻辑数据流：当发生一个事务时必须首先接收它；随后按照事务的内容修改库存清单；最后如果更新后的库存量少于库存量临界值时，则应该再次定货，也就是需要处理定货信息。

    因此，把“处理事务”这个功能分解为下述3个步骤，这在逻辑上是合理的：“接收事务”、“更新库存清单”和“处理定货”(图2.7)。

    当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入输出数据流必须相同。

 

图2.7 把处理事务的功能进一步分解后的数据流图

 

 

2.4.3  命名

    数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。因此，给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题：

1. 为数据流(或数据存储)命名

(1) 名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。

(2) 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。

(3) 如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。

2. 为处理命名

(1) 通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。

(2) 名字应该反映整个处理的功能，而不是它的一部分功能。

(3) 名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。

(4) 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。

(5) 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。

数据源点/终点并不需要在开发目标系统的过程中设计和实现，它并不属于数据流图的核心内容，只不过是目标系统的外围环境部分(可能是人员、计算机外部设备或传感器装置)。通常，为数据源点/终点命名时采用它们在问题域中习惯使用的名字(如“采购员”、“仓库管理员”等)。

2.4.4  用途

    画数据流图的基本目的是利用它作为交流信息的工具。分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来，供有关人员审查确认。由于在数据流图中通常仅仅使用4种基本符号，而且不包含任何有关物理实现的细节，因此，绝大多数用户都可以理解和评价它。

    数据流图应该分层，并且在把功能级数据流图细化后得到的处理超过9个时，应该采用画分图的办法，也就是把每个主要功能都细化为一张数据流分图，而原有的功能级数据流图用来描绘系统的整体逻辑概貌。

 

    数据流图的另一个主要用途是作为分析和设计的工具。

    分析员在研究现有的系统时常用系统流程图表达他对这个系统的认识，这种描绘方法形象具体，比较容易验证它的正确性；

    但是，开发工程的目标往往不是完全复制现有的系统，而是创造一个能够完成相同的或类似的功能的新系统。

    用系统流程图描绘一个系统时，系统的功能和实现每个功能的具体方案是混在一起的。

    因此，分析员希望以另一种方式进一步总结现有的系统，这种方式应该着重描绘系统所完成的功能而不是系统的物理实现方案。数据流图是实现这个目标的极好手段。

 

    当用数据流图辅助物理系统的设计时，以图中不同处理的定时要求为指南，能够在数据流图上画出许多组自动化边界，每组自动化边界可能意味着一个不同的物理系统，因此可以根据系统的逻辑模型考虑系统的物理实现。

    例如，考虑图2.7，事务随时可能发生，因此处理1.1(“接收事务”)必须是联机的；采购员每天需要一次定货报表，因此处理2(“产生报表”)应该以批量方式进行。

    问题描述并没有对其他处理施加限制，例如，可以联机地接收事务并放入队列中，然而更新库存清单、处理定货和产生报表以批量方式进行(图2.8)。当然，这种方案需要增加一个数据存储以存放事务数据。

 

图2.8 这种划分自动化边界的方法暗示以批量方式更新库存清单

 

    改变自动化边界，把处理1.1，1.2和1.3放在同一个边界内(图2.9)，这个系统将联机地接收事务、更新库存清单和处理定货及输出定货信息；然而处理2将以批量方式产生定货报表。

    还能设想出建立自动化边界的其他方案吗?

    如果把处理1.1和处理1.2放在一个自动化边界内，把处理1.3和处理2放在另一个边界内，意味着什么样的物理系统呢?

    数据流图对更详细的设计步骤也有帮助，本书第5章将讲述从数据流图出发映射出软件结构的方法——面向数据流的设计方法。

 

 

 

 

图2.9 另一种划分自动化边界的方法建议以联机方式更新库存清单

 

2.5  数据字典

    数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

    任何字典最主要的用途都是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人提供关于数据的描述信息。

    数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，然而没有数据流图数据字典也难于发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。

2.5.1  数据字典的内容

    一般说来，数据字典应该由对下列4类元素的定义组成：

(1) 数据流

(2) 数据流分量(即数据元素)

(3) 数据存储

(4) 处理

    但是，对数据处理的定义用其他工具(如IPO图或PDL)描述更方便，因此本书中数据字典将主要由对数据的定义组成，这样做可以使数据字典的内容更单纯，形式更统一。

    除了数据定义之外，数据字典中还应该包含关于数据的一些其他信息。

    典型的情况是，在数据字典中记录数据元素的下列信息： 一般信息(名字，别名，描述等等)，定义(数据类型，长度，结构等等)，使用特点(值的范围，使用频率，使用方式——输入、输出、本地，条件值等等)，控制信息(来源，用户，使用它的程序，改变权，使用权等等)和分组信息(父结构，从属结构，物理位置——记录、文件和数据库等等)。

    数据元素的别名就是该元素的其他等价的名字，出现别名主要有下述3个原因：

(1) 对于同样的数据，不同的用户使用了不同的名字；

(2) 一个分析员在不同时期对同一个数据使用了不同的名字；

(3) 两个分析员分别分析同一个数据流时，使用了不同的名字。

虽然应该尽量减少出现别名，但是不可能完全消除别名。

2.5.2  定义数据的方法

    定义绝大多数复杂事物的方法，都是用被定义的事物的成分的某种组合表示这个事物，这些组成成分又由更低层的成分的组合来定义。从这个意义上说，定义就是自顶向下的分解，所以数据字典中的定义就是对数据自顶向下的分解。那么，应该把数据分解到什么程度呢?一般说来，当分解到不需要进一步定义，每个和工程有关的人也都清楚其含义的元素时，这种分解过程就完成了。

    由数据元素组成数据的方式只有下述三种基本类型：

(1) 顺序  即以确定次序连接两个或多个分量；

(2) 选择  即从两个或多个可能的元素中选取一个；

(3) 重复  即把指定的分量重复零次或多次。

    因此，可以使用上述3种关系算符定义数据字典中的任何条目。为了说明重复次数，重复算符通常和重复次数的上下限同时使用(当上下限相同时表示重复次数固定)。当重复的上下限分别为1和0时，可以用重复算符表示某个分量是可选的。但是，“可选”是由数据元素组成数据时一种常见的方式，把它单独列为一种算符可以使数据字典更清晰一些。因此，增加了下述的第4种关系算符：

(4) 可选  即一个分量是可有可无的(重复零次或一次)。

    虽然可以使用自然语言描述由数据元素组成数据的关系，但是为了更加清晰简洁，建议采用下列符号：

=意思是等价于(或定义为)；

+意思是和(即，连接两个分量)；

［ ］意思是或(即，从方括弧内列出的若干个分量中选择一个)，通常用“|”号隔开供选择的分量；

{  }意思是重复(即，重复花括弧内的分量)；

(  )意思是可选(即，圆括弧里的分量可有可无)。

 

    常常使用上限和下限进一步注释表示重复的花括弧。一种注释方法是在开括弧的左边用上角标和下角标分别表明重复的上限和下限；另一种注释方法是在开括弧左侧标明重复的下限，在闭括弧的右侧标明重复的上限。

    下面举例说明上述定义数据的符号的使用方法：某程序设计语言规定，用户说明的标识符是长度不超过8个字符的字符串，其中第一个字符必须是字母字符，随后的字符既可以是字母字符也可以是数字字符。使用上面讲过的符号，我们可以像下面那样定义标识符：

标识符=字母字符+字母数字串

字母数字串=0｛字母或数字｝7

字母或数字=［字母字符｜数字字符］

    由于和项目有关的人都知道字母字符和数字字符的含义，因此，关于标识符的定义分解到这种程度就可以结束了。

2.5.3  数据字典的用途

    数据字典最重要的用途是作为分析阶段的工具。 

    在数据字典中建立的一组严密一致的定义很有助于改进分析员和用户之间的通信，因此将消除许多可能的误解。

    对数据的这一系列严密一致的定义也有助于改进在不同的开发人员或不同的开发小组之间的通信。

    如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题。

    数据字典中包含的每个数据元素的控制信息是很有价值的。

    因为列出了使用一个给定的数据元素的所有程序(或模块)，所以很容易估计改变一个数据将产生的影响，并且能对所有受影响的程序或模块作出相应的改变。

    最后，数据字典是开发数据库的第一步，而且是很有价值的一步。

2.5.4  数据字典的实现

    目前，数据字典几乎总是作为CASE“结构化分析与设计工具”的一部分实现的。

    在开发大型软件系统的过程中，数据字典的规模和复杂程度迅速增加，人工维护数据字典几乎是不可能的。

    如果在开发小型软件系统时暂时没有数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据的信息。这样做更新和修改起来比较方便，而且能单独处理描述每个数据的信息。每张卡片上主要应该包含下述这样一些信息：

名字、别名、描述、定义、位置。

2.6  成本/效益分析

    开发一个软件系统是一种投资，期望将来获得更大的经济效益。

    经济效益通常表现为减少运行费用或(和)增加收入。但是，投资开发新系统往往要冒一定风险，系统的开发成本可能比预计的高，效益可能比预期的低。

    效益分析的目的正是要从经济角度分析开发一个特定的新系统是否划算，从而帮助客户组织的负责人正确地作出是否投资于这项开发工程的决定。

    为了对比成本和效益，首先需要估计它们的数量。

2.6.1  成本估计

    软件开发成本主要表现为人力消耗(乘以平均工资则得到开发费用)。成本估计不是精确的科学，因此应该使用几种不同的估计技术以便相互校验。下面简单介绍3种估算技术。

1. 代码行技术

    代码行技术是比较简单的定量估算方法，它把开发每个软件功能的成本和实现这个功能需要用的源代码行数联系起来。通常根据经验和历史数据估计实现一个功能需要的源程序行数。当有以往开发类似工程的历史数据可供参考时，这个方法是非常有效的。

    一旦估计出源代码行数以后，用每行代码的平均成本乘以行数就可以确定软件的成本。每行代码的平均成本主要取决于软件的复杂程度和工资水平。

2. 任务分解技术

    这种方法首先把软件开发工程分解为若干个相对独立的任务。再分别估计每个单独的开发任务的成本，最后累加起来得出软件开发工程的总成本。

    估计每个任务的成本时，通常先估计完成该项任务需要用的人力(以人月为单位)，再乘以每人每月的平均工资而得出每个任务的成本。

    最常用的办法是按开发阶段划分任务。如果软件系统很复杂，由若干个子系统组成，则可以把每个子系统再按开发阶段进一步划分成更小的任务。

    典型环境下各个开发阶段需要使用的人力的百分比大致如表2.2（见书40页）所示。当然，应该针对每个开发工程的具体特点，并且参照以往的经验尽可能准确地估计每个阶段实际需要使用的人力。

3. 自动估计成本技术

    采用自动估计成本的软件工具可以减轻人的劳动，并且使得估计的结果更客观。但是，采用这种技术必须有长期搜集的大量历史数据为基础，并且需要有良好的数据库系统支持。

2.6.2  成本/效益分析的方法

    成本/效益分析的第一步是估计开发成本、运行费用和新系统将带来的经济效益。

• 估计开发成本以介绍。

• 运行费用取决于系统的操作费用(操作员人数，工作时间，消耗的物资等等)和维护费用。

• 系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。

    因为运行费用和经济效益两者在软件的整个生命周期内都存在，总的效益和生命周期的长度有关，所以应该合理地估计软件的寿命。

    虽然许多系统在开发时预期生命周期长达10年以上，但是时间越长系统被废弃的可能性也越大，为了保险起见，以后在进行成本/效益分析时一律假设生命周期为5年。

    应该比较新系统的开发成本和经济效益，以便从经济角度判断这个系统是否值得投资，但是，投资是现在进行的，效益是将来获得的，不能简单地比较成本和效益，应该考虑货币的时间价值。

1. 货币的时间价值

    通常用利率的形式表示货币的时间价值。

    假设年利率为i，如果现在存入P元，则n年后可以得到的钱数为：F=P(1+i)ⁿ

    这也就是P元钱在n年后的价值。

    反之，如果n年后能收入F元钱，那么这些钱的现在价值是

    P=F/(1+i)ⁿ

    例如，修改一个已有的库存清单系统，使它能在每天送给采购员一份定货报表。

    修改已有的库存清单程序并且编写产生报表的程序，估计共需5000元；

    系统修改后能及时定货将消除零件短缺问题，估计因此每年可以节省2500元，5年共可节省12500元。

    但是，不能简单地把5000元和12500元相比较，因为前者是现在投资的钱，后者是若干年以后节省的钱。

    假定年利率为12%，利用上面计算货币现在价值的公式可以算出修改库存清单系统后每年预计节省的钱的现在价值，如表2.3（见书41页）所示。

 

2. 投资回收期

    通常用投资回收期衡量一项开发工程的价值。

    所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间。

    显然，投资回收期越短就能越快获得利润，因此这项工程也就越值得投资。

    举例：参见P42

    投资回收期仅仅是一项经济指标，为了衡量一项开发工程的价值，还应该考虑其他经济指标。

 

3. 纯收入

    衡量工程价值的另一项经济指标是工程的纯收入，也就是在整个生命周期之内系统的累计经济效益(折合成现在值)与投资之差。

    这相当于比较投资开发一个软件系统和把钱存在银行中(或贷给其他企业)这两种方案的优劣。

    如果纯收入为零，则工程的预期效益和在银行存款一样，但是开发一个系统要冒风险，因此从经济观点看这项工程可能是不值得投资的。

    如果纯收入小于零，那么这项工程显然不值得投资。

 

4. 投资回收率

    把资金存入银行或贷给其他企业能够获得利息，通常用年利率衡量利息多少。

    类似地也可以计算投资回收率，用它衡量投资效益的大小，并且可以把它和年利率相比较。

    在衡量工程的经济效益时，它是最重要的参考数据。

    已知现在的投资额，并且已经估计出将来每年可以获得的经济效益，那么，给定软件的使用寿命之后，怎样计算投资回收率呢?

    设想把数量等于投资额的资金存入银行，每年年底从银行取回的钱等于系统每年预期可以获得的效益，在时间等于系统寿命时，正好把在银行中的存款全部取光，那么，年利率等于多少呢?

    这个假想的年利率就等于投资回收率。

   

2.7  小结

    可行性研究进一步探讨问题定义阶段所确定的问题是否有可行的解。

    在对问题正确定义的基础上，通过分析问题，导出试探性的解，然后复查并修正问题定义，再次分析问题，改进提出的解法……。

    经过定义问题、分析问题、提出解法的反复过程，最终提出一个符合系统目标的高层次的逻辑模型。

    然后根据系统的这个逻辑模型设想各种可能的物理系统，并且从技术、经济和操作等各方面分析这些物理系统的可行性。

    最后，系统分析员提出一个推荐的行动方针，提交用户和客户组织负责人审查批准。

 

    在表达分析员对现有系统的认识和描绘他对未来的物理系统的设想时，系统流程图是一个很好的工具。系统流程图实质上是物理数据流图，它描绘组成系统的主要物理元素以及信息在这些元素间流动和处理的情况。

    数据流图的基本符号只有4种，它是描绘系统逻辑模型的极好工具。通常数据字典和数据流图共同构成系统的逻辑模型。没有数据字典精确定义数据流图中每个元素，数据流图就不够严密；然而没有数据流图，数据字典也很难发挥作用。

    成本/效益分析是可行性研究的一项重要内容，是客户组织负责人从经济角度判断是否继续投资于这项工程的主要依据。