第二章：可行性研究

第二章：可行性研究

前言

链接地址百度网盘地址

一、可行性研究介绍

1.可行性研究的目的

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

2.可行性研究的任务

• (1)对以后的行动方针提出建议。如果问题没有可行的解，分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费；如果问题值得解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。
  (2)必须分析几种主要的候选解法的利弊，从而判断原定的系统目标和规模是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。
  (3)对每种可能的解决方案都应该仔细研究它的可行性，通常，至少从下述三个方面研究每种解决方案的可行性。
  ①技术可行性：使用现有的技术能否实现这个系统。
  ②经济可行性：这个系统的经济效益能否超过它的开发成本。
  ③操作可行性：这个系统的操作方式在该客户组织内是否行得通。

3.可行性研究过程

• 可行性研究的一般步骤为：
  (1)复查系统规模和目标
  分析员访问关键人员，仔细阅读和分析有关的材料，以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。这个步骤的工作，实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。
  (2)研究目前正在使用的系统
  仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。应该注意了解这个系统可以做什么，为什么这样做，还要了解使用这个系统的代价。
  (3)导出新系统的高层逻辑模型
  优秀的设计过程通常是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。
  (4)进一步定义问题
  新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。用户是否也有同样的看法呢?分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。
  (5)导出和评价供选择的解法
  分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法供比较和选择。导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。
  (6)推荐行动方针
  根据可行性研究结果应该决定的一个关键性问题是：是否继续进行这项开发工程?分析员必须清楚地表明他对这个关键性决定的建议。
  (7)草拟开发计划
  分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员(例如，系统分析员、程序员)和各种资源(计算机硬件、软件工具等)的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本。最后应该给出下一个阶段(需求分析)的详细进度表和成本估计。
  (8)书写文档提交审查。
  分析员应该把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。

二、系统流程图

1.定义

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

2.基本思想

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

3.符号

• 图2.1基本符号
  

• 图2.2系统符号
  

4.实例分析

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

  • 图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.实例分析

• 详见P42

4.命名规则

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

5.用途

• (1)目的
  ①作为交流信息的工具(基本目的)
  分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来，供有关人员审查确认。
  ②作为分析和设计的工具
  分析员在研究现有的系统时常用系统流程图表达他对这个系统的认识，这种描绘方法形象具体，比较容易验证它的正确性。
• (2)自动化边界
  以图中不同处理的定时要求为指南，能够在数据流图上画出许多组自动化边界，每组自动化边界可能意味着一个不同的物理系统，因此可以根据系统的逻辑模型考虑系统的物理实现。

四、数据字典

1.概念

• (1)定义
  数据字典是关于数据的信息的集合，是对数据流图中包含的所有元素的定义的集合。它的作用是在软件分析和设计的过程中给人提供关于数据的描述信息。
• (2)意义
  数据流图和数据字典共同构成系统的逻辑模型，没有数据字典，数据流图就不严格，然而没有数据流图，数据字典也难于发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。

2.内容

• (1)一般来说，数据字典应该由对下列4类元素的定义组成。
  ①数据流；
  ②数据元素；
  ③数据存储；
  ④处理。
• (2)数据元素的别名就是该元素的其他等价的名字，出现别名主要是以下3个原因引起的。
  ①对于同样的数据，不同的用户使用了不同的名字。
  ②一个分析员在不同时期对同一个数据使用了不同的名字。
  ③两个分析员分别分析同一个数据流时，使用了不同的名字。
  注意：虽然应该尽量减少出现别名，但是不可能完全消除别名。

3.定义数据的方法

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

• (1)数据元素组成数据的方式
  ①顺序即以确定次序连接两个或多个分量；
  ②选择即从两个或多个可能的元素中选取一个；
  ③重复即把指定的分量重复零次或多次；
  ④可选即一个分量是可有可无的(重复零次或一次)。
• (2)数据元素组成数据的符号表示
  ①=意思是等价于(或定义为);
  ②+意思是和(即连接两个分量);
  ③[]意思是或(即从方括弧内列出的若干个分量中选择一个);
  ④|意思是隔开供选择的分量；
  ⑤{}意思是重复(即重复花括弧内的分量);
  ⑥()意思是可选(即圆括弧里的分量可有可无)。
  ⑦使用上限和下限进一步注释表示重复的花括弧。

4.数据字典的用途

• (1)作为分析阶段的工具(最重要)。
  在数据字典中建立的一组严密一致的定义很有助于改进分析员和用户之间的通信，可以消除许多可能的误解。对数据的这一系列严密一致的定义有助于改进在不同的开发人员或不同的开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题。
• (2)数据字典中包含的每个数据元素的控制信息是很有价值的。数据字典列出了使用一个给定的数据元素的所有程序(或模块),所以很容易估计改变一个数据将产生的影响，并且能对所有受影响的程序或模块做出相应的改变。
• (3)数据字典是开发数据库的第一步，而且是很有价值的一步。

5.数据字典的实现

• (1)开发大型软件系统是建议使用数据字典处理程序。
  (2)在开发小型软件系统时建议采用卡片形式书写数据字典，给出了几个数据元素的数据字典卡片。

  • 数据字典卡片
    

五、成本/效益分析

1.目的

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

2.成本估计的方法

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

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

• (2)任务分解技术
  ①方法步骤
  a.把软件开发工程分解为若干个相对独立的任务；
  b.分别估计每个单独的开发任务的成本，先估计完成该项任务需要用的人力(以人月为单位),再乘以每人每月的平均工资而得出每个任务的成本；
  c.最后累加起来得出软件开发工程的总成本。
  ②划分规则
  最常用的办法是按开发阶段划分任务。如果软件系统很复杂，由若干个子系统组成，则可以把每个子系统再按开发阶段进一步划分成更小的任务。
  ③典型环境
  典型环境下各个开发阶段需要使用的人力的百分比大致如表2-2所示。

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

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

3.成本/效益分析的方法

• (1)方法步骤
  ①估计开发成本、运行费用和新系统将带来的经济效益。
  a.运行费用取决于系统的操作费用和维护费用。
  b.系统的经济效益等于因使用新系统而增加的收入加上新系统可以节省的运行费用。
  c.在进行成本/效益分析时一律假设生命周期为5年。
  ②比较新系统的开发成本和经济效益，以便从经济角度判断这个系统是否值得投资。但是，投资是现在进行的，效益是将来获得的，不能简单地比较成本和效益，应该考虑货币的时间价值。
• (2)影响经济效益的因素
  ①货币的时间价值
  ②投资回收期
  ③纯收入
  ④投资回收率