软件工程导论—可行性研究

1. 可行性研究

1.1. 可行性研究的目的

可行性研究实质上是要进行一次简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。这个过程通常结合了初步的需求分析，不做需求分析，就无法对需求进行可行性分析。它所需要的时间长短取决于工程的规模。一般说来，可行性研究的成本只是预期的工程总成本的5%到10%。

因此，可行性研究的目的不是解决问题，而是确定问题是否能够并且值得去解决。

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

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

1.2. 可行性研究过程

1. 首先需要进一步分析和澄清问题定义。
2. 在澄清了问题定义之后，分析员应该导出系统的逻辑模型。
3. 然后从系统逻辑模型出发，探索若干种可供选择的主要解法(即系统实现方案)。对每种解法都应该仔细研究它的可行性，一般说来，至少应该从下述三方面研究每种解法的可行性：
   (1)技术可行性：工使用现有的技术能实现这个系统吗?
   (2)经济可行性：这个系统的经济效益能超过它的开发成本吗?
   (3)操作可行性：系统的操作方式在这个用户组织内行得通吗?
   必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。

展开来说，典型的可行性研究过程有下述一些步骤

1. 复查系统规模和目标
   分析员对问题定义阶段书写的关于规模种目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束
2. 研究目前正在使用的系统
   现有的系统是信息的重要来源，新的目标系统必须也能完成它的基本功能；另一方面，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。此外，运行使用旧系统所需要的费用是一个重要的经济指标，如果新系统不能增加收入或减少使用费用，那么从经济角度看新系统就不如旧系统
3. 导出新系统的高层逻辑模型
   优秀的设计过程通常总是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统；
   通过上一步的工作，分析员能够使用数据流图，描绘数据在系统中流动和处理的情况，从而概括地表达出他对新系统的设想。为了把新系统描绘得更清晰准确，还应该有一个初步的数据字典，定义系统中使用的数据中。
4. 进一步定义问题
   新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。可行性研究的前4个步骤实质上构成一 个循环。
   分析员定义问题，分析这个问题，导出一个试探性的解。在此基础上再次定义问题，再一次分析这个问题，修改这个解。继续这个循环过程中直到提出的逻辑模型完全符合系统目标。
5. 导出和评价供选择的解法
   分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法，供比较和选择。导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。
   首先，根据技术可行性的考虑初步排除一些不现实的系统方案。
   其次，考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案。
   最后考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。
6. 推荐行动方针
   根据可行性研究结果应该做出的一个关键性决定是，是否继续进行这项开发工程。如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。
   通常使用部门的负责人主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。
7. 草拟开发计划
   分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员和各种资源的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本，最后应给出下一个阶段(需求分析)的详细进度表和成本估计。
8. 书写文档提交审查
   应该把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案

2. 系统流程图

2.1. 系统流程图概述

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

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

2.2. 系统流程图的图符

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

图符	名称	说明
	处理	能改变数据值或数据位置的加工或部件，例如，程序、处理机、人工加工等都是处理
	输入输出	表示输入或输出(或既输入又输出)，是一个广义的不指明具体设备的符号
	连接	指出转到图的另一部分或从图的另一部分转来，通常在同一页上
	换页连接	指出转到另一页图上或由另一页图转来
	数据流	用来连接其他符号，指明数据流动方向
	穿孔卡片	表示用穿孔卡片输入或输出，也可表示一个穿孔卡片文件
	文档	通常表示打印输出，也可表示用打印终端输入数据
	磁带	磁带输入输出，或表示一个磁带文件
	联机存储	表示任何种类的联机存储，包括磁盘、磁鼓、软盘和海量存储器件等
	磁盘	磁盘输入输出，也可表示存储在磁盘上的文件或数据库
	磁鼓	磁鼓输入输出，也可表示存储在磁鼓上的文件或数据库
	显示	CRT终端或类似的显示部件，可用于输入或输出，也可既输入又输出
	人工输入	人工输入数据的脱机处理，例如填写表格
	人工操作	人工完成的处理，例如会计在工资支票上签名
	辅助操作	使用设备进行的脱机操作
	通信链路	通过远程通信线路或链路传送数据

2.3. 系统流程图的例子

以一个简单的例子进行讲解

某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的存量临界值等数据，记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。

该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务，流程如下：

1. 零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；
2. 系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上；
3. 最后，每天由报告生成程序读一次磁带，并且打印出订货报告。如下图所示。

2.4. 系统流程图的分层

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

首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。

3. 数据流图 Data Flow Diagram,DFD

3.1. 数据流图的概念

数据流图(DFD)是一种图形化的交流工具和分析设计工具，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。

在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具。

此外，设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能。

下面的顶级DFD高度概括了数据流图的处理过程，数据从外部实体流入目标系统进行加工，然后又流出到外部实体。

3.2. 数据流图的基本图符

数据流图有四种基本符号:

1. 正方形(或立方体)，表示数据的源点或终点；
2. 圆角矩形(或圆形)，代表数据的加工处理；
3. 开口矩形(或两条平行横线)，代表数据存储；
4. 箭头表示数据流，即特定数据的流动方向。

如下图所示：

图符	含义
	数据的源点或终点
	数据的加工处理
	数据存储
	数据流

除了4个基本符号以外，数据流图还有一个附加符号，如下图所示：

图符	含义
	数据A和B同时输入才能变换成数据C
	数据A变换成B和C
	数据A或B，或A和B同时输入变换成C
	数据A变换成B或C，或B和C
	只有数据A或只有数据B(但不能A、B同时)输入时变换成C
	数据A变换成B或C，但不能变换成B和C

3.3. 绘制数据流图

3.3.1. 绘制数据流图的步骤

概括地说：自外向内，自顶向下，逐层细化，完善求精。

1. 首先确定系统的输入和输出，以反映系统与外界环境的接口；
2. 顶层数据流图将软件系统描述为一个加工，以反映最主要业务处理流程，它代表系统本身。但它并未明确表达数据加工的要求；
3. 从输入端开始，根据系统业务工作流程，画出数据流流经的各加工框，以反映数据的实际处理过程，逐步画到输出端，得到第一层数据流图。对图中的加工分别加以编号；
4. 细化每一个加工框。如果加工框内还有数据流，可将这个加工框再细分成几个“子加工框”，并在各子加工框之间画出数据流；
5. 一次细化一个加工。

数据流图的细化可以连续进行，直到每一个加工只执行一个简单操作为止。就是说，直到每一个加工执行一个可以用程序实现的功能为止。

3.3.2. 成分的命名

数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。在命名时应注意的问题：

1. 为数据流(或数据存储)命名
   （1）名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分；
   （2）不要使用空洞的、缺乏具体含义的名字(如"数据"、“信息”、"输入"之类);
   （3）如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。
2. 为处理命名
   （1）通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的"由表及里"的思考过程。
   （2）名字应该反映整个处理的功能，而不是它的一部分功能；
   （3）名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用"加工"、"处理"等空洞笼统的动词作名字；
   （4）通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。
   （5）如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。
3. 为数据源点/终点命名
   数据源点/终点并不需要在开发目标系统的过程中设计和实现，它并不属于数据流图的核心内容，只不过是目标系统的外围环境部分(可能是人员、计算机外部设备或传感器装置)。通常，为数据源点/终点命名时采用它们在问题域中习惯使用的名字(如"采购员"、"仓库管理员"等)。

3.4. 数据流图的例子

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

对于每个需要再次订货的零件应该列出下述数据：零件编号、零件名称、订货数量、目前价格、主要供应者、次要供应者。

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

按步骤对题干进行分析，提取数据流图的四种成分：

1. 首先考虑数据的源点和终点，从上面对系统的描述可以知道"采购部每天需要一张订货报表"，“通过放在仓库中的CRT终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。
2. 这其中必须有一个用于产生报表的处理。事务的后果是改变零件库存量，然而任何改变数据的操作都是处理，因此对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。
3. 系统把订货报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个处理在时间上明显不匹配一每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。因此，用来产生订货报表的数据必须存放一段时间，也就是应该有一个数据存储。

在弄清楚数据流图的成分之后，就开始画数据流图了，首先画出一个顶级数据流图：

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

下一步应该把基本系统模型细化，描绘系统的主要功能。“产生报表"和"处理事务"是系统必须完成的两个主要功能，它们将代替图的"定货系统”，如下面的一级数据流图：

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

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

因此，把"处理事务"这个功能分解为"接收事务"、"更新库存清单"和"处理定货"三个步骤，这在逻辑上是合理的，如下面的二级数据流图所示。

至此，一个详细的数据流图才算画完了。

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

例如，事务随时可能发生，因此处理1.1(“接收事务”)必须是联机的；采购员每天需要一次定货报表，因此处理2(“产生报表”)应该以批量方式进行。问题描述并没有对其他处理施加限制。对$L2$划分自动化边界的结果如下图所示：

3.4. 数据流图的分层

以上绘制数据流图的步骤可以用下面这张分层数据流图来表示，首先绘制最上面一层的顶级数据流图$L0$，然后是第二层的一级数据流图$L1$，再是最下面的二级数据流图$L2$，理论上还可以画出$L3$、$L4$等等。

如果要产生详细的数据流图就要把所有加工处理都分解成基本加工，所谓基本加工，就是数据流图中所有不能进一步分解的加工，一般有父项、无子项的加工就是基本加工。

3.5. 基本加工说明 PSPEC

PSPEC用来说明DFD中的每个基本加工

可以用的描述工具有：结构化语言、决策树、决策表、盒图、数学公式等等

其中结构化语言也叫作伪代码或者过程设计语言，其介于自然语言和计算机语言之间，通过顺序语句、条件语句和循环语句对基本加工进行描述，例如：

IF 发货单金额超过$500 THEN
	IF 欠款超过60天 THEN
		在偿还欠款前不予批准
	ELSE 欠款未超期
		发批准书及发货单
	ENDIF
ELSE 发货单金额未超过$500
	IF 欠款超过60天 THEN
		发批准书、发货单及催款通知
	ELSE 欠款未超期
		发批准书及发货单
	ENDIF
ENDIF

决策树是一种图形工具，适合于描述加工中具有多个策略，而且每个策略和若干条件有关的逻辑功能，例如：

决策表的内涵与决策树一致，但是适用于如果判断的条件较多，各条件又相互组合的情况，如下表所示：

		1	2	3	4
条件	发货单金额	>$500	>$500	<=$500	<=$500
	赊欠情况	>60天	<=60天	>60天	<=60天
操作	不发出批准书	√
	发出批准书		√	√	√
	发出发货单		√	√	√
	发出赊欠报告			√

4. 数据字典 Data Dictionary,DD

4.1. 数据字典的概念

数据字典是对数据流图中包含的所有元素的定义的集合。它是分析阶段的交流工具，也是数据库设计的基础。在结构化系统分析中，数据字典是分析的核心。

任何字典最主要的用途都是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人提供关于数据的描述信息。数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，然而没有数据流图数据字典也难于发挥作用，它们两个要放在一起才能发挥作用。

4.2. 数据字典的内容

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

1. 数据流
2. 数据元素（字段）
3. 数据存储（表）
4. 加工处理
5. 外部项

但是，对于数据处理，用其他工具描述更方便，通常是使用IPO图或PDL。

典型的情况是，在数据字典中记录数据元素的下列信息：

1. 一般信息，名字、别名、描述等等；
2. 定义，数据类型、长度、结构等等；
3. 使用特点，值的范围、使用频率、使用方式(输入、输出、本地)、条件值等等；
4. 控制信息，来源、用户、使用它的程序、改变权、使用权等等
5. 分组信息，父结构、从属结构、物理位置记录、文件和数据库等等。

4.3. 定义数据的方法

数据是通过下面五种运算符由数据元素：

1. 顺序连接$+$，即以确定次序连接两个或多个分量；
2. 选择$[|]$，用于从两个或多个可能的元素中选取一个；
3. 重复$\{\}n$，用于把指定的分量重复$n$次；
4. 可选$()$，即一个分量是可有可无的(重复零次或一次)；
5. 定义为$=$，用于最终确定一个数据；

例如：
学生成绩通知=$\{$学号+姓名+$\{$课程名称+成绩$\}$+(补考课程名称+补考时间+补考地点)$\}$所有注册学生
学生奖励通知=$\{$学号+姓名+[一等奖 | 二等奖 | 三等奖]$\}$所有获奖学生

4.4. 数据字典的实现

目前，数据字典几乎总是作为CASE"结构化分析与设计工具"的一部分实现的。在开发大型软件系统的过程中，人工维护数据字典几乎是不可能的。

如果在开发小型软件系统时暂时没有数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上主要应该包含下述这样一些信息：名字、别名、描述、定义、位置。

例如下面就是一张描绘数据流的数据字典卡片：

数据流
系统名				编号
条目名				别名
来源				去处
数据流结构
简要说明
修改记录		编写		日期
		审核		日期

5. 成本/效益分析

5.1. 成本估算

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

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

1. 代码行技术
   代码行技术是比较简单的定量估算方法，它把开发每个软件功能的成本和实现这个功能需要用的源代码行数联系起来。估计出源代码行数以后，用每行代码的平均成本乘以行数就可以确定软件的成本每行代码的平均成本主要取决于软件的复杂程度和工资水平。
2. 任务分解技术
   这种方法首先把软件开发工程分解为若干个相对独立的任务，再分别估计每个单独的开发任务的成本，最后累加起来得出软件开发工程的总成本估计每个任务的成本时。通常先估计完成该项任务需要用的人力(以人月为单位)，再乘以每人每月的平均工资而得出每个任务的成本。
3. 自动估计成本技术
   采用自动估计成本的软件工具可以减轻人的劳动，并且使得估计的结果更客观。但是，采用这种技术必须有长期搜集的大量历史数据为基础，并且需要有良好的数据库系统支持。

5.2. 成本/效益分析方法

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

其中，运行费用取决于系统的操作费用(操作员人数，工作时间，消耗的物资等等)和维护费用；系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。

因为运行费用和经济效益两者在软件的整个生命周期内都存在，总的效益和生命周期的长度有关，I 所以应该合理地估计软件的寿命。为了保险起见，在进行成本/效益分析时一律假设生命周期为5年。

在以上条件的基础上，可以从四个方面来考虑对成本/效益进行分析：

1. 货币的时间价值
2. 投资回收期
   所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间。
3. 纯收入
   纯收入就是在整个生命周期之内系统的累计经济效益(折合成现在值)与投资之差。这相当于比较投资开发一个软件系统和把钱存在银行中这两种方案的优劣。
4. 投资回收率
   把资金存入银行或贷给其他企业能够获得利息，通常用年利率衡量利息多少。类似地也可以计算投资回收率，用它衡量投资效益的大小，并且可以把它和年利率相比较，在衡量工程的经济效益时，它是最重要的参考数据。

5.2.1. 货币的时间价值

通常用利率的形式表示货币的时间价值。假设年利率为$i$，如果现在存入$p$元，则$n$年后可以得到的钱数为:$$F=p(1+i{)}^n$$ 这也就是$p$元钱在$n$年后的价值。反之，如果$n$年后能收入$F$元钱，那么这些钱的现在价值是$$p=\frac{F}{(1+i{)}^n}$$

例如，修改一个已有的库存清单系统，使它能在每天送给采购员一份订货报表。修改已有的库存清单程序并且编写产生报表的程序，估计共需5000元; 系统修改后能及时订货，这将消除零件短缺问题，估计因此每年可以节省2500元，5年共可节省12500元。

但是，不能简单地把5000元和12500元相比较，因为前者是现在投资的钱，后者是若干年以后节省的钱。假定年利率为12%，利用上面计算货币现在价值的公式可以算出修改库存清单系统后每年预计节省的钱的现在价值，如下表所示。

年	将来值(元)	$(1+i{)}^n$	现在值(元)	累计的现在值((元)
1	2500	1.12	2232.14	2232.14
2	2500	1.25	1992.98	4225.12
3	2500	1.40	1779.45	6004.57
4	2500	1.57	1588.80	7593.37
5	2500	1.76	1418.57	9011.94