194.可行性研究
第2章 可行性研究数据库
• 目的：用最小的代价在尽量短的时间内肯定问题是否可以解决。网络
• 任务：肯定问题是否值得去解决。工具
• 首先须要进一步分析和澄清问题定义。post
分析问题定义阶段初步肯定的规模和目标，正确的加以确定，有错误及时改正，对目标系统有任何约束和限制，必须把它们清楚地列举出来。 spa
问题定义的内容计算机网络
•问题的背景设计
•开发系统的现状3d
•开发的理由和条件blog
•开发系统的问题要求、整体要求排序
•问题的性质、类型范围
•要实现的目标
•功能规模
•实现目标的方案
•开发的条件、环境要求
问题定义举例
项目：教材销售系统
• 背景：人工销售效率低，容易出错
• 项目目标：创建一个高效率的、无差错的微机教材销售系统
• 项目范围：硬件利用现有微机，软件开发费用不超过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)n
这也就是P元钱在n年后的价值。
反之，若是n年后能收入F元钱，那么这些钱的如今价值是
P=F/(1+i)n
例如，修改一个已有的库存清单系统，使它能在天天送给采购员一份订货报表。
修改已有的库存清单程序而且编写产生报表的程序，估计共需5000元；
系统修改后能及时订货将消除零件短缺问题，估计所以每一年能够节省2500元，5年共可节省12500元。
可是，不能简单地把5000元和12500元相比较，由于前者是如今投资的钱，后者是若干年之后节省的钱。
假定年利率为12%，利用上面计算货币如今价值的公式能够算出修改库存清单系统后每一年预计节省的钱的如今价值，如表2.3（见书41页）所示。
2. 投资回收期
一般用投资回收期衡量一项开发工程的价值。
所谓投资回收期就是使累计的经济效益等于最初投资所须要的时间。
显然，投资回收期越短就能越快得到利润，所以这项工程也就越值得投资。
举例：参见P42
投资回收期仅仅是一项经济指标，为了衡量一项开发工程的价值，还应该考虑其余经济指标。
3. 纯收入
衡量工程价值的另外一项经济指标是工程的纯收入，也就是在整个生命周期以内系统的累计经济效益(折合成如今值)与投资之差。
这至关于比较投资开发一个软件系统和把钱存在银行中(或贷给其余企业)这两种方案的优劣。
若是纯收入为零，则工程的预期效益和在银行存款同样，可是开发一个系统要冒风险，所以从经济观点看这项工程多是不值得投资的。
若是纯收入小于零，那么这项工程显然不值得投资。
4. 投资回收率
把资金存入银行或贷给其余企业可以得到利息，一般用年利率衡量利息多少。
相似地也能够计算投资回收率，用它衡量投资效益的大小，而且能够把它和年利率相比较。
在衡量工程的经济效益时，它是最重要的参考数据。
已知如今的投资额，而且已经估计出未来每一年能够得到的经济效益，那么，给定软件的使用寿命以后，怎样计算投资回收率呢?
设想把数量等于投资额的资金存入银行，每一年年末从银行取回的钱等于系统每一年预期能够得到的效益，在时间等于系统寿命时，正好把在银行中的存款所有取光，那么，年利率等于多少呢?
这个假想的年利率就等于投资回收率。
2.7 小结
可行性研究进一步探讨问题定义阶段所肯定的问题是否有可行的解。
在对问题正肯定义的基础上，经过分析问题，导出试探性的解，而后复查并修正问题定义，再次分析问题，改进提出的解法……。
通过定义问题、分析问题、提出解法的反复过程，最终提出一个符合系统目标的高层次的逻辑模型。
而后根据系统的这个逻辑模型设想各类可能的物理系统，而且从技术、经济和操做等各方面分析这些物理系统的可行性。
最后，系统分析员提出一个推荐的行动方针，提交用户和客户组织负责人审查批准。
在表达分析员对现有系统的认识和描绘他对将来的物理系统的设想时，系统流程图是一个很好的工具。系统流程图实质上是物理数据流图，它描绘组成系统的主要物理元素以及信息在这些元素间流动和处理的状况。
数据流图的基本符号只有4种，它是描绘系统逻辑模型的极好工具。一般数据字典和数据流图共同构成系统的逻辑模型。没有数据字典精肯定义数据流图中每一个元素，数据流图就不够严密；然而没有数据流图，数据字典也很难发挥做用。
成本/效益分析是可行性研究的一项重要内容，是客户组织负责人从经济角度判断是否继续投资于这项工程的主要依据。