《软件工程导论》（第6版）第2章 可行性研究 复习笔记

第2章　可行性研究

一、可行性研究介绍

1．可行性研究的目的

并非任何问题都有简单明显的解决办法，事实上，许多问题不可能在预定的系统规模或时间期限之内解决。如果问题没有可行的解，那么花费在这项工程上的任何时间、人力、软硬件资源和经费，都是无谓的浪费。可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。

2．可行性研究的任务

（1）对以后的行动方针提出建议。如果问题没有可行的解，分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费；如果问题值得解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。

（2）必须分析几种主要的候选解法的利弊，从而判断原定的系统目标和规模是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。

（3）对每种可能的解决方案都应该仔细研究它的可行性，通常，至少从下述三个方面研究每种解决方案的可行性。

①技术可行性：使用现有的技术能否实现这个系统。

②经济可行性：这个系统的经济效益能否超过它的开发成本。

③操作可行性：这个系统的操作方式在该客户组织内是否行得通。

3．可行性研究过程

可行性研究的一般步骤为：

（1）复查系统规模和目标

分析员访问关键人员，仔细阅读和分析有关的材料，以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。这个步骤的工作，实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。

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

仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。应该注意了解这个系统可以做什么，为什么这样做，还要了解使用这个系统的代价。

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

优秀的设计过程通常是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。

（4）进一步定义问题

新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。用户是否也有同样的看法呢？分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。

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

分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的（较抽象的）物理解法供比较和选择。导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。

（6）推荐行动方针

根据可行性研究结果应该决定的一个关键性问题是：是否继续进行这项开发工程？分析员必须清楚地表明他对这个关键性决定的建议。

（7）草拟开发计划

分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员（例如，系统分析员、程序员）和各种资源（计算机硬件、软件工具等）的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本。最后应该给出下一个阶段（需求分析）的详细进度表和成本估计。

（8）书写文档提交审查。

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

二、系统流程图

1．定义

系统流程图是概括地描绘物理系统的传统工具。

2．基本思想

系统流程图的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件（程序、文档、数据库、人工过程等）。系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流程图。

3．符号

（1）以概括的方式抽象地描绘实际系统时，使用图2-1中列出的基本符号就足够了。

图2-1 基本符号

（2）需要更具体地描绘一个物理系统时，还需要使用图2-2中列出的系统符号。

图2-2 系统符号

4．实例分析

例1：

某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果哪种零件的库存量少于它的库存量临界值，则应该报告给采购部、门以便订货，规定每天向采购部门送一次订货报告。该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。

解答与分析：

图2-3的系统流程图描绘了上述系统的概貌。图中每个符号用黑盒子形式定义了组成系统的一个部件，然而并没有指明每个部件的具体工作过程；图中的箭头确定了信息通过系统的逻辑路径（信息流动路径）。

图2-3 库存清单系统的系统流程图

5．分层

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

（1）用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能；

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

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

三、数据流图

1．概念

（1）定义

数据流图（DFD）是一种图形化技术。它描绘信息流和数据从输入移动到输出的过程中所经受的变换。

（2）特点

①数据流图中没有具体的物理部件，只是描绘数据在软件中流动和被处理的逻辑过程。

②数据流图是系统逻辑功能的图形表示，是分析员与用户之间极好的通信工具。

③设计时只需考虑系统必须完成的基本逻辑功能，不考虑怎样具体地实现这些功能。

2．符号

（1）表示

如图2-4（a）所示，数据流图有4种基本符号，如图2-4（a）所示，它们代表的基本含义如下。

a．正方形（或立方体）：表示数据的源点或终点。

b．圆角矩形（或圆形:代表变换数据的处理。

c．开口矩形（或两条平行横线）：代表数据存储。

d．箭头：表示数据流，即特定数据的流动方向。

注意：数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。

除了4种基本符号之外，有时也使用几种附加符号，图2-4（b）给出了这些附加符号的含义。其中星号（*）表示数据流之间是“与”关系（同时存在）；加号（＋）表示“或”关系；＋号表示只能从中选一个（互斥的关系）。

图2-4 数据流图的符号

（2）注意事项

①在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。

②一个处理框可以代表一系列程序、单个程序或者程序的一个模块。

③一个数据存储可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等。

④数据存储是处于静止状态的数据，数据流是处于运动中的数据。

⑤通常在数据流图中忽略出错处理。

⑥表示数据的源点和终点相同的方法是再重复画一个同样的符号表示数据的终点。

⑦代表同一事物的符号出现在n个地方，在这个符号的角上画（n-1）条短斜线做标记。

3．实例分析

例2：

假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。画出上述订货系统的数据流图。

解答与分析：

（1）第一步可以从问题描述中提取数据流图的4种成分：

①考虑数据的源点和终点

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

②考虑处理

显然他们还没有“采购部需要报表”这种报表，因此必须有一个用于产生报表的处理。事务的后果是改变零件库存量，然而任何改变数据的操作都是处理，因此对事务进行的加工是另一个处理。

③考虑数据流和数据存储

系统把订货报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个处理在时间上明显不匹配，每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。因此，用来产生订货报表的数据必须存放一段时间，也就是应该有一个数据存储。

表2-1总结了上面分析的结果，其中加星号标记的是在问题描述中隐含的成分。

表2-1 组成数据流图的元素可以从描述问题的信息中提取

（2）画数据流图

①画出基本系统模型

任何系统的基本模型都由若干个数据源点／终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。可以画出图2-5这样的基本系统模型。

图2-5 订货系统的基本系统模型

②细化基本系统模型，描绘系统的主要功能

从表2-1可知，“产生报表”和“处理事务”是系统必须完成的两个主要功能，它们将代替图2-5中的“订货系统”（图2-6）。细化后的数据流图中还增加了两个数据存储：处理事务需要“库存清单”数据；产生报表和处理事务需要存储“订货信息”。除了表2-1中列出的两个数据流之外还有另外两个数据流，因为从一个数据存储中取出来的或放进去的数据通常和原来存储的数据相同。在图2-6中给处理和数据存储都加编号，这样做的目的是便于引用和追踪。

图2-6 订货系统的功能级数据流图

③进一步细化功能级数据流图中描绘的系统主要功能

考虑通过系统的逻辑数据流：当发生一个事务时必须首先接收它；随后按照事务的内容修改库存清单；最后如果更新后的库存量少于库存量临界值时，则应该再次订货，也就是需要处理订货信息。因此，把“处理事务”这个功能分解为：“接收事务”、“更新库存清单”和“处理订货”（图2-7）。

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

④考虑是否要继续分解和细化

当进一步分解将涉及如何具体地实现一个功能时就不应该再分解了。订货报表中需要的数据在存储的订货信息中全都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。对“接收事务”或“更新库存清单”等功能也没有必要进一步细化。

⑤检查

a．对数据流图分层细化时必须保持信息连续性；

b．注意对处理进行编号的方法。

4．命名规则 

（1）为数据流（或数据存储）命名

①名字应代表整个数据流（或数据存储）的内容，而不是只反映它的某些成分。

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

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

（2）为处理命名

①通常先为数据流命名，然后再为与之相关联的处理命名。

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

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

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

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

（3）为数据源点／终点命名

数据源点／终点并不需要在开发目标系统的过程中设计和实现，它并不属于数据流图的核心内容，只不过是目标系统的外围环境部分，因此为数据源点／终点命名时通常采用它们在问题域中习惯使用的名字。

5．用途

（1）目的

①作为交流信息的工具（基本目的）

分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来，供有关人员审查确认。

②作为分析和设计的工具

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

（2）自动化边界

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

①考虑图2-7，事务随时可能发生，故处理1.1（“接收事务”）必须是联机的；采购员每天需要一次订货报表，因此处理2（“产生报表”）应该以批量方式进行。可以联机地接收事务并放入队列中，然而更新库存清单、处理订货和产生报表以批量方式进行（图2-8）。

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

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

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

四、数据字典

1．概念

（1）定义

数据字典是关于数据的信息的集合，是对数据流图中包含的所有元素的定义的集合。它的作用是在软件分析和设计的过程中给人提供关于数据的描述信息。

（2）意义

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

2．内容

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

①数据流；

②数据流分量，即数据元素；

③数据存储；

④处理。

（2）数据元素的别名就是该元素的其他等价的名字，出现别名主要是以下3个原因引起的。

①对于同样的数据，不同的用户使用了不同的名字。

②一个分析员在不同时期对同一个数据使用了不同的名字。

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

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

3．定义数据的方法

定义绝大多数复杂事物的方法，都是用被定义的事物的成分的某种组合表示这个事物，这些组成成分又由更低层的成分的组合来定义。

（1）数据元素组成数据的方式

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

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

③重复即把指定的分量重复零次或多次；

④可选即一个分量是可有可无的（重复零次或一次）。

（2）数据元素组成数据的符号表示

①＝意思是等价于（或定义为）；

②＋意思是和（即连接两个分量）；

③[]意思是或（即从方括弧内列出的若干个分量中选择一个）；

④｜意思是隔开供选择的分量；

⑤{}意思是重复（即重复花括弧内的分量）；

⑥（）意思是可选（即圆括弧里的分量可有可无）。

⑦使用上限和下限进一步注释表示重复的花括弧，例如：51{A}和1{A}5含义相同。

4．数据字典的用途

（1）作为分析阶段的工具（最重要）。

在数据字典中建立的一组严密一致的定义很有助于改进分析员和用户之间的通信，可以消除许多可能的误解。对数据的这一系列严密一致的定义有助于改进在不同的开发人员或不同的开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题。

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

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

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

5．数据字典的实现

（1）开发大型软件系统是建议使用数据字典处理程序。

（2）在开发小型软件系统时建议采用卡片形式书写数据字典，如图2-10，给出了几个数据元素的数据字典卡片。

图2-10 数据字典卡片

五、成本／效益分析

1．目的

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

2．成本估计的方法

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

（1）代码行技术

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

（2）任务分解技术

①方法步骤

a．把软件开发工程分解为若干个相对独立的任务；

b．分别估计每个单独的开发任务的成本，先估计完成该项任务需要用的人力（以人月为单位），再乘以每人每月的平均工资而得出每个任务的成本；

c．最后累加起来得出软件开发工程的总成本。

②划分规则

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

③典型环境

典型环境下各个开发阶段需要使用的人力的百分比大致如表2-2所示。

表2-2 典型环境下各个开发阶段需要使用的人力的百分比

（3）自动估计成本技术

采用自动估计成本的软件工具可以减轻人的劳动，并且使得估计的结果更客观。但是，

采用这种技术必须有长期搜集的大量历史数据为基础，并且需要有良好的数据库系统支持。

3．成本／效益分析的方法

（1）方法步骤

①估计开发成本、运行费用和新系统将带来的经济效益。

a．运行费用取决于系统的操作费用和维护费用。

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

c．在进行成本／效益分析时一律假设生命周期为5年。

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

（2）影响经济效益的因素

①货币的时间价值

通常用利率的形式表示货币的时间价值。假设年利率为i，如果现在存入P元，则n年后可以得到的钱数为：

F＝P（1＋i）n

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

P＝F／（1＋i）n

②投资回收期

通常用投资回收期衡量一项开发工程的价值。所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间。投资回收期越短就能越快获得利润，那么这项工程也就越值得投资。投资回收期仅仅是一项经济指标，为了衡量一项开发工程的价值，还应该考虑其他经济指标。

③纯收入

工程的纯收入是在整个生命周期之内系统的累计经济效益（折合成现在值）与投资之差。如果纯收人为零，则工程的预期效益和在银行存款一样，但是开发一个系统要冒风险，因此这项工程可能是不值得投资的。如果纯收入小于零，那么这项工程显然不值得投资。

④投资回收率

计算投资回收率，用它衡量投资效益的大小，并且可以把它和年利率相比较，在衡量工程的经济效益时，它是最重要的参考数据。

其中，P是现在的投资额；Fi是第i年年底的效益（i＝1，2，…，n）；n是系统的使用寿命；j是投资回收率。