第二章 可行性研究

问题的定义与可性行研究 开始 问题定义 可性行研究 可行否？ 结束 有用的软件 为谁设计，用户是谁？ Who 要解决哪些问题？ What 为什么要解决这些问题 Why 可行否？ N Y 项目实施计划 终止项目的建议 结束

可行性研究 目的： 用最小的代价在尽可能短的时间内确定问题是否能够解决。 不是解决问题，而是确定问题是否值得去解决。

可行性研究的目的 说明该软件开发项目的实现在技术上、 经济上和社会条件上的可行性；评述为 合理地达到开发目标可能选择的各种方 案。 (GB 8567-88《 计算机软件产品开发文件编制指南 》)

2.1 可行性研究的任务 可行性研究的最根本任务是： 对以后的行动方针提出建议。 2.1 可行性研究的任务 GB 8566-88 《计算机软件开发规范》中指出： 可行性研究的主要任务是“了解客户的要 求及现实环境，从技术、经济和社会因素等三 方面研究并论证本软件项目的可行性，编写可 行性研究报告，制定初步项目开发计划。” 可行性研究的最根本任务是： 对以后的行动方针提出建议。

可行性研究的内容 (1) 技术可行性 (2) 经济可行性 (3) 操作可行性 (4) 社会可行性(法律可行性) (5) 抉择

技术可行性 度量一个特定技术信息系统解决方案的实用性及技术资源的可用性 考虑的问题 (1)开发风险分析 (2)资源分析 (3)相关技术的发展（现有技术能 否实现新系统，技术难点、建议 采用技术的先进性）

经济可行性 度量系统解决方案的性能价格比。 考虑的问题： 成本/效益分析（开发、运行的成本/效益） 有形成本、效益 无形成本、效益 价值和成本的关系 质量与价值、成本的关系 价值/成本的均衡

举例 1 2 3 4 5 年 60 40 20 成本-效益(万元) 该系统节省经费 盈亏平衡点 该系统成本 投资回收期 1 2 3 4 5 年 60 40 20 成本-效益(万元) 该系统节省经费 盈亏平衡点 该系统成本 投资回收期 ---------成本及效益分析图

操作可行性 用户使用可能性 时间进度可行性 组织和文化上的可行性

社会可行性(法律可行性) 开发项目是否会在社会上或政治上引起侵权、破坏或其它责任问题。

2.2 可行性研究过程 1. 复查系统规模和目标 2. 研究目前正在使用的系统 3. 导出新系统的高层逻辑模型 4. 进一步定义问题 2.2 可行性研究过程 1. 复查系统规模和目标 2. 研究目前正在使用的系统 3. 导出新系统的高层逻辑模型 4. 进一步定义问题 5. 导出和评价供选择的解法 6. 推荐行动方针 7. 草拟开发计划 8. 书写文档提交审查

可行性研究报告的编写 GB 8567-88《 计算机软件产品开发文件编制指南 》

可行性研究报告的编写 1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料 2 可行性研究的前提 2.1 要求 2.2 目标 2.3 条件、假定和限制 2.4 进行可行性研究的方法 2.5 评价尺度

可行性研究报告的编写 4 所建议的系统 3 对现有系统的分析 3.1 数据流程和处理流程 4.1 对所建议系统的说明 3.2 工作负荷 3.3 费用开支 3.4 人员 3.5 设备 3.6 局限性 4 所建议的系统 4.1 对所建议系统的说明 4.2 数据流程和处理流程 4.3 改进之处 4.4 影响 4.5 局限性 4.6 技术条件方面的可行性

可行性研究报告的编写 6 投资及收益分析 6.1 支出 6.2 收益 6.3 收益/投资比 6.4 投资回收周期 6.5 敏感性分析 5 可选择的其它系统方案 5.1 可选择的其它系统1 5.2 可选择的其它系统2 ...... 6 投资及收益分析 6.1 支出 6.2 收益 6.3 收益/投资比 6.4 投资回收周期 6.5 敏感性分析 7 社会条件方面的可行性 7.1 法律方面的可行性 7.2 使用方面的可行性

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

基本符号 ----以概括的方式抽象地描绘一个实际系统所用符号 基本符号 ----以概括的方式抽象地描绘一个实际系统所用符号

--- 具体地描绘一个物理系统所用符号 系统符号

举例 ----库存清单系统的系统流程图

举例 ---- 计算机售书系统流程图 1 2 学生 1---学生各学期用书数据库 2---教材存量数据库 购书单 终端 结束 购书发票 举例 ---- 计算机售书系统流程图 学生 1---学生各学期用书数据库 2---教材存量数据库 购书单 终端 结束 购书发票 审查并 开发票 到书库 领书 购书单 1 2

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

2.4 数据流图 DFD ---- Data Flow Diagram 1.一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。 2.在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。

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

数据流图四种基本符号 或 数据加工 (数据变换) 或 数据源点或终点 (外部实体) 或 数据存储文件 数据流

数据流图几种附加符号

数据流图的层次结构 为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。

在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。 底层流图是指其加工不需再做分解的数据流图，它处在最底层。 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。

分层的数据流图

---- 系统逻辑模型 数据的 加工或 变换 输入 输出 软件 系统 外部实体 … … 输入 数据流 输出

分层的数据流图 第 n 层 第 n+2 层 F0 A0 B0 F11 A0 B0 F12 F13 F14 F15 p1 C1 D1 M1 K2 F24 W2 F25 p1 Y2 X2 第 n+2 层

举 例 1、定货系统 （见书P33—P34） 2、学生购买教材系统

外部实体 外部实体 学 生 保 管员 第 1 层 1 销售 学 生 2 采购 保 管员 第 2 层 教材 购销 系统 购书单 缺书单 领书单 进书通知 第 1 层 教材存量表 F1 1 销售 购书单 领书单 学 生 缺书单 进书通知 2 采购 保 管员 进书通知 画数据流图的基本步骤概括地说，就是。。。 。。。。 具体步骤可按如下来做。。。 。。。 1、先找出系统的数据源点与汇点。（它们是外部实体，由它们来确定系统与外界的接口） 第一步是画顶层图。通常把整个系统当作一个大的加工，并标明系统的输入与输出，以及数据的源点与终点图中表明，系统从学生接受购书单，经处理后把领书单返回给学生，使学生可凭领书单到书库领书。对脱销的教材，系统则用缺书单的形式通知给书库；新书进库后也由书库将进书通知返回给系统。 第二步画分层DFD图：把系统分解为销售和采购两大加工。如图所示，显然，外部项学生应与 销售子系统联系，保管员应与采购子系统联系。 且两个子系统之间也存在两项数据联系：其一是缺书登记表，由销售子系统把脱销的教材传给采购子系统； 其二是进书通知，直接由采购子系统将教材入库信息通知销售子系统。 同时，对于销售子系统来说，它还需要对教材存量表进行操作，即对售出的教材要在原存量中减去售出的数量，而对于新购的教材还要写到教材存量表中，所以该文件执行的读写操作，应用双箭头表示。 缺书登记表 F2 第 2 层

1 销售 2 采购 学 生 保 管员 第 2 层 学 生 学 生 第 3 层 外部 项 教材销售子系统 1.5 采 购 F1 书号 单价 购书单 领书单 缺书单 进书通知 2 采购 缺书登记表 教材存量表 学 生 保 管员 第 2 层 外部 项 教材销售子系统 缺书登记表 F2 1.5 补售 教材 采 购 进书通知 F1 书号 单价 数量 1.4 登记 缺书 补售 书单 教材存量表 F1 暂缺书单 继续分解，就可以获得第三层的数据流图。我们可以从第1层的销售子系统扩展而成： 审查有效性时，首先要核对购书单上的内容是否与学生用书表F3相符，还要通过售书登记F4检查学生已否购买过这些教材。若发现购书单中有学生不用或买重了的教材，便发出无效书单。只有将通过了审查的教材保留在有效构书单中。 开发票加工符号，按购书单的内容查对教材存量表(F1)，把可供应的教材写入发票，在F4中登记后开领书单并发给学生。对数量不足或全缺的教材写入暂缺书单并登记到缺书登记表(F2)中，等待接到进书通知后再补售给学生。补售的手续及数据流图和第一次购书相同。 请大家注意，在上一层DFD中，采购是系统内部的一个加工符号，但本图却是处于销售子系统之外的一个外部实体。 从图中可以看出，该销售子系统将被分解为5个子加工，编号从1.1----1.5，涉及到4个数据文件，分别用 F1—F4来表示。 学 生 无效书单 1.1 审查 有效性 1.2 开发票 1.3 登记并开 领书单 学 生 有效书单 发票 领书单 购书单 各班用书表 F3 售书登记表 F4 第 3 层

从图中可以看出，该采购子系统将被分解为3个子加工，编号从2.1----2.3，涉及到4个数据文件，分别用 F1,F2 和 F5,F6。 销售 购书单 领书单 缺书单 进书通知 2 采购 缺书登记表 教材存量表 学 生 保 管员 第 2 层 缺书登记表 F2 采购 子系统 2.1 按书号汇 总缺书 2.2 按出版社统 计缺书 教材存量表 F1 待购教材表 F5 教材一览表 F6 采购子系统在图中被分解为3个子加工。由销售子系统建立起来的缺书登记表，首先按书号汇总后登入待购教材表，然后再按出版社分别统计制成缺书单并送给书库保管员作为采购教材的依据。另外，在汇总缺书要再次核查教材存量表，而且，分出版社统计时还要参阅教材一览表，从该文件中可以知道这些缺书是何处出版的。新书入库后，要及时修改教材存量表和待购教材表中的有关教材数量，同时把进书信息通知销售子系统，使销售人员能通知缺书的学生补售教材。 从图中可以看出，该采购子系统将被分解为3个子加工，编号从2.1----2.3，涉及到4个数据文件，分别用 F1,F2 和 F5,F6。 以上三层、4张的DFD图，一起组成了教材购销系统的分层DFD图。从分析中大家可以得知，愈到下层，加工愈细。第三层就有8个加工。大都是足够简单的---基本加工，可以不用再进行分解了。 缺书单 2.3 修改教材库 存和待 购量 销 售 保 管员 进书通知 进书通知 第 3 层

分层 DFD 图的优点 . 便于实现 --- 采用逐步细化的扩展方法，可避免一 次引入过多的细节，有利于控制问题 的复杂度； . 便于使用 --- 用一组图代替一张总图，方便用户及 软件开发人员阅读。

画分层 DFD 的指导原则 1） 为数据流(或数据存储)命名 1. 注意数据流图中成分的命名 (1) 名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。 (2) 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。 (3) 如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。

画分层 DFD 的指导原则 1. 注意数据流图中成分的命名 2） 为处理命名 (1) 通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。 (2) 名字应该反映整个处理的功能，而不是它的一部分功能。 (3) 名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。

(4) 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 (5) 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。

画分层 DFD 的指导原则 2. 注意父图和子图的平衡 1.3 (a) 父图 (a)子图 1.3.1 学生 领书单 1.3.2 1.3.3 教材 (a)子图 发票 1.3 开领书单 领书单 (a) 父图 1、注意父图和子图的平衡 在分层图中，每一层都是它上层的子图，同时又是它下层的父图。如前面例子中的第二层就是。所谓的平衡，就是指父图和子图的输入和输出数据应分别保持一致。 以采购子系统的DFD图为例，图中所联系的外部项的数据共有3个，即一个输入数据流-------进书通知， 两个输出数据流-------进书通知和缺书通知 这和第二层的教材购销系统中的“采购”加工的输入和输出是一致的，即满足了父、子图间数据平衡的要求。 再比如，从上图中可能发现，父图和子图的输入数据流从名称到数量均不相同，但如果，我们把 “发票=学生+教材” 的关系能够满足，那么，这一对父子图仍可算是平衡的。

画分层 DFD 的指导原则 3. 区分局部文件和局部外部项 1 销售 2 采购 学 生 保 管员 第 2 层 第 3 层 销 售 购书单 领书单 缺书单 进书通知 2 采购 缺书登记表 教材存量表 学 生 保 管员 采购 子系统 第 2 层 第 3 层 2.3 修改教材库 存和待 购量 销 售 2.1 按书号汇 总缺书 2.2 按出版社统 计缺书 教材存量表 F1 待购教材表 F5 教材一览表 F6 缺书登记表 F2 2、区分局部文件和局部外部项 随着DFD图的分解，在下层DFD中可能出现父图中没有的文件和外部项。例如在前面的举例中的第三层(采购子系统)与它的父图(即第二层)采购加工符号相比较，就多了两个文件，即F5、F6和一个外部项（销售），则它们是图（采购子系统）的局部文件和外部项。 对初次画DFD图 的人来说，在这一点上比较容易出错，如在父图中多画了子图的局部文件，或者在子图中有漏画了应该添入的外部项。一般来说，除底层DFD需画出全部的外部文件外，各中间层的DFD仅显示处于加工之间的接口文件，而其余的文件均不必画出，以保持图面的简洁。 如上述的F5,F6都是局部于采购子系统内部的文件，与父图（第二层）其余加工无关（如销售），在父图中画出反显得累赘。 此外，在第二层中的----进书通知 是指向 销售框的。所以在采购子系统中，销售就成了采购子系统的外部项。那么如果漏画了这个外部项，进书通知便将成为无“的”之“矢”了。 3、掌握分解的速度：分解是一个个逐步细化的过程，通常在上层可分解快一些，下层应慢一些，因为越接近下层功能愈强，如果分解太快，将会增加用户理解的困难，同一图中的各个加工，分解的步骤应大致均匀，保持同步扩展。 局部 文件 局部 外部项

画分层 DFD 的指导原则 4. 掌握分解的速度 一般来说，每一个加工每次可分为 2-4个子加工，最 多不得超过 7 个。 5. 遵守加工编号规则 顶层加工不编号。第二层的加工编号为1,2,3,…,n号。 第三层编号为1.1,1.2,1.3…n.1,n.2…等号，依此类推。

课堂练习：画出系统的数据流图 一个简单的考务处理系统功能描述： (1)对考生送来的报名单进行检查; (2)对合格的报名单编好准考证号后将准考证送给 考生，并将汇总后的考生名单送给阅卷站; (3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者; (4)制作考生通知单(含成绩及合格/不合格标志)送给考生; (5)按地区进行成绩分类统计和试题难度分析，产生统计分析表。

2.5 数据字典 ---- DD（Data Dictionary） 数据字典的任务是: 对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。 数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，然而没有数据流图数据字典也难于发挥作用。

数据字典的内容 一般说来，数据字典应该由对 下列4类元素的定义组成： (1) 数据流 (2) 数据流分量(即数据元素) (3) 数据存储 (4) 处理

(1) 数据流词条的描述 数据流名： 说明：简要介绍作用，即它产生的原因和结果。 数据流来源：即该数据流来自何方。 数据流去向：去向何处。 数据流组成：数据结构。 每个数据量流通量：数据量、流通量。 数据流名：发票 说明：用作学生已付书款的依据 数据流来源：来自加工“审查并开发票” 数据流去向：流向加工“开领书单”。 数据流组成：学号+姓名+书号+单价总价+书费合计 审查并 开发票 发票 购书单

类型:数字（离散值、连续值），文字（编码类型） 长度: 取值范围: 相关的数据元素及数据结构 (2) 数据元素词条的描述 数据元素名: 类型:数字（离散值、连续值），文字（编码类型） 长度: 取值范围: 相关的数据元素及数据结构 (2) 数据元素词条的描述 年 = “1900”..“3000” 月 = “01”..“12” 日 = “01”..“31” 摘要 = 1{字母}4 金额 = “00000000.01”..“999999999.99” … …

(3) 数据文件词条的描述 数据文件名： 简述：存放的是什么数据。 输入数据: 输出数据: 数据文件组成:数据结构。 存储方式:顺序，直接，关键码。 存取频率: … … 审查并 开发票 学 生 发票 购书单 各班学生用书表 教材存量表

(4) 加工逻辑词条的描述 加工编号:反映该加工的层次 简要描述:加工逻辑及功能简述 输入数据流: 取值范围: 相关的数据元素及数据结构 加工名: 加工编号:反映该加工的层次 简要描述:加工逻辑及功能简述 输入数据流: 取值范围: 相关的数据元素及数据结构 … … 1.3 审查并 开发票 学 生 发票 购书单 各班学生用书表 教材存量表

(5) 外部实体词条描述 简要描述:什么外部实体 有关数据流: 数目: 名称：外部实体名 1 销售 2 采购 学 生 保 管员 教材存量表 购书单 领书单 缺书单 进书通知 2 采购 缺书登记表 教材存量表 学 生 保 管员

数据字典定义符号 = + [ ] { } m{ }n ( ) *…* 符号 含 义 例 子 x=a+b，则表示 x 由 a 和 b 组成 含 义 例 子 = 被定义为 + 与 x=a+b，则表示 x 由 a 和 b 组成 [ ] 或 x=[a,b]，则表示 x 由 a 或由 b 组成 x={a}，则表示 x 由 0个或多个 a 组成 { } 重复 m{ }n 重复 x=3{a}8，则表示x中至少出现3次a ,最多出现8次 ( ) 可选 x=(a)，则表示 a 在 x 中出现, 也可不出现 *…* 注释符 表示在两个 * 之间的内容为词条的注释

例：存折格式

存折 = 户名+所号+帐号+开户日+性质+(印密)+1{存取行}20 户名 = 2{字母}24 所号 = “001”..“999” 户名: 所号: 帐号: 开户日: 性质: 印密: 日期 (年月日) 摘要 支出 存入 余额 操作 复核 存折 = 户名+所号+帐号+开户日+性质+(印密)+1{存取行}20 户名 = 2{字母}24 所号 = “001”..“999” 帐号 = “00000001”..“99999999” 开户日 = 年+月+日 性质 = “1”..“6” 注：“1”表示普通户，…“6”表示工资户等 印密 = “0” 注：印密在存折上不显示 存取行 = 日期+（摘要）+支出+存入+余额+操作+复核 日期 =年+月+日 年 = “1900”..“3000” 月 = “01”..“12” 日 = “01”..“31” 摘要 = 1{字母}4 支出 = 金额 金额 = “00000000.01”..“999999999.99” … …

注：加工说明 ----（Process Specification） PS 加工说明是:对 DFD 中每个加工给予说明。它是从系统功能的角度对 DFD 作出了注解，与 DD 一样是DFD 必不可缺少的辅助资料。 PS

加工逻辑说明 对数据流图的每一个基本加工，必须有一个基本加工逻辑说明。 基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。 加工逻辑说明中包含的信息应是充足的，完备的，有用的，无冗余的。

加工说明描述工具 换为输出数据流的加工过 程，是加工说明的主体。 加工说明组成 输入 数据 加工 逻辑 输出 数据 结构化 语言 判定 表 描述把输入数据流变 换为输出数据流的加工过 程，是加工说明的主体。 加工说明组成 输入 数据 加工 逻辑 输出 数据 加工说明描述工具 结构化 语言 判定 表 判定 树

自然语言+结构化形式 … … 选 择 （1）结构化语言 结 If <condition> 构 如果<条件> <策略> If <condition> <policy> 则 <策略1> 否则 <策略2> 情况1 <条件> … … 情况n <条件> <策略n> then <policy1> Otherwise <policy2> case 1 <condition> <policy1> case n <condition> <policyn> 循 环 对 … , 重复以下 直至 <条件> For each … , Repeat the following: Until <condition>

商店业务处理系统中“检查发货单” if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else （欠款未超期） 发批准书，发货单 else （发货单金额未超过$500） if 欠款超过60天 then 发批准书，发货单及赊欠报告

（2）判定表 如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适

以“检查发货单”为例

（3）判定树 判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。 欠款>60天 检 查 发 货 单 金额>$500 不发出批准书 检 查 发 货 单 金额>$500 欠款60天 发出批准书、发货单 欠款>60天 发出批准书、发货单及赊欠报告 金额$500 欠款60天 发出批准书、发货单

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

2.6.1 成本估计 ---- 人力成本估计 软件开发成本主要表现为人力消耗 (乘以平均工资则得到开发费用)。 估算技术： 1. 代码行技术 2.6.1 成本估计 ---- 人力成本估计 软件开发成本主要表现为人力消耗 (乘以平均工资则得到开发费用)。 估算技术： 1. 代码行技术 2. 任务分解技术 3. 自动估计成本技术

代码行技术 根据源程序行数，用每行代码的平均成本乘以行数。 每行代码的平均成本主要取决于软件的复杂程度和工资水平。 代码行技术是比较简单的定量估算方法。 具体计算方法见13.1.1 章节

任务分解技术 把软件开发工程分解为若干个相对独立的任务。 分别估计每个单独的开发任务的成本，最后累加起来得出软件开发工程的总成本。 通常先估计完成该项任务需要用的人力(以人月为单位)，再乘以每人每月的平均工资而得出每个任务的成本。 具体计算方法见13.2章节

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

2.6.2 成本/效益分析的方法 成本/效益分析的第一步是估计开发成本、运行费用和新系统将带来的经济效益，然后从经济角度判断这个系统是否值得投资。 运行费用取决于系统的操作费用(操作员人数，工作时间，消耗的物资等)和维护费用。 系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。

注意： 总的效益和生命周期的长度有关，所以应该合理地估计软件的寿命。 2.6.2 成本/效益分析的方法 注意： 总的效益和生命周期的长度有关，所以应该合理地估计软件的寿命。 投资是现在进行的，效益是将来获得的，不能简单地比较成本和效益，应该考虑货币的时间价值。

成本/效益分析使用的几个概念 货币的时间价值 投资回收期 纯收入 投资回收率

系统开发和每年运行费用举例 1.系统开发费用（一次） 2名系统分析员(450小时/名,45美元/小时) $40,500 5名系统开发人员(275小时/名,36美元/小时)$49,500 1名数据库管理员(30小时/名,42美元/小时) $1,260 2名技术写作者(120小时/名,25美元/小时) $6,000 1名秘书(160小时/名,15美元/小时) $2,400 1名数据通讯专家(60小时/名,42美元/小时) $2,400 2名在转换期间数据输入人员(40小时/名,12美元/小时) $49,500 培训： 三天的开发人员内部培训课程 $7,000 30个用户，三天的内部培训课程 $10,000 物资： 复印 $500 磁盘、纸张等消耗品 $650

购买硬件、软件： 20台工作站Windows软件 $1,000 20台工作站内存升级 $8,000 网络软件 $17,500 20台工作站办公软件产品 $20,000 系统开发总费用 $161,670 2.年运行费用（每年） 人员： l维护程序员/分析员(250小时/年,42美元/小时) $10,500 网络管理员(300小时/年,50美元/小时) $15,000 购买硬件、软件升级： 硬件 $5,000 软件 $6,000 物资和杂项 $3,500 每年总运行费用 $40,000

可行性分析案例 -高职学院管理信息系统

(1)基本情况

作业： 1、习题 2-1，2-5每人必做。 2、以团队为单位在习题 2-2，2-3， 2-4中人选一个，或自选一个题目 完成可行性分析报告。