《软件工程导论（第六版）》第二章可行性分析与研究

2.1可行性研究相关概念

2.1.1可行性研究的目的

2.1.2可行性研究的内容

2.1.3可行性研究的过程

2.2软件风险分析

软件风险分析一般过程:

2.2.1风险识别

2.2.2风险预测（风险估计）

2.2.3风险的驾驭和监控

2.3系统流程图

2.4数据流图（结构化分析方法）

2.1可行性研究相关概念

2.1.1可行性研究的目的

花最小的代价在尽可能短的时间内确定问题是否能够解决。（参考算法设计）

弄清待开发的项目是不是可能实现和值得进行，通常由系统分析员完成。如果可行，即可制定项目实施计划，同时开始软件开发；如果不太可行，则应当提出终止该项目的建议。

总之，可行性研究的目的不是解决问题，而是确定问题是否值得去解决。

2.1.2可行性研究的内容

可行性研究分析的大概过程：

首先，进一步分析和澄清问题定义，初步确定问题规模和目标

然后，分析员应该导出系统的逻辑模型

再，探索若干种可供选择的主要解法

最后，对每种解法研究其可行性

建议：

1.经济可行性---实现这个系统有没有经济效益？多长时间能收回成本？

2.技术可行性----现有的技术能否实这一新系统？有什么技术难点？建议采用技术的先进程度怎么样？

3.运行可行性（操作可行性）-----为新系统规定的运行方式是否可行？

4.法律可行性----新系统的开发会不会在社会上或政治上引起侵权、破坏或其它责任问题？

其它，社会效益可行性等等。

2.1.3可行性研究的过程

典型的可行性研究的过程：

1.理清问题定义。

1.对当前系统进行调查和研究。（不是抄）

2.导出新系统的解决方案。（一般多种）

3.提出推荐方案。

4.编写可行性论证报告。（系统概述+可行性分析+结论意见）

张海藩教材上的过程：

1.复查系统规模和目标

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

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

现有的系统是信息的重要来源。显然，如果目前有一个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功能；另一方面，如果现有的系统是完美无缺的，用户自然不会提出开发新系统的要求，因此，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。应该仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。常见的错误做法是花费过多时间去分析现有的系统。没有一个系统是在“真空”中运行的，绝大多数系统都和其他系统有联系。

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

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

4.进一步定义问题

可行性研究的前4个步骤实质上构成一个循环。分析员定义问题，分析这个问题，导出一个试探性的解；在此基础上再次定义问题，再一次分析这个问题，修改这个解；继续这个循环过程，直到提出的逻辑模型完全符合系统目标。

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

分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的物理解法供比较和选择。其次可以考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。接下来应该考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，这个进度表不需要制定得很详细，通常只需要估计生命周期每个阶段的工作量。

根据可行性研究结果应该决定的一个关键性问题是：是否继续进行这项开发工程？分析员必须清楚地表明他对这个关键性决定的建议。如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。通常客户主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。

6.草拟开发计划

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

7.书写文档提交审查

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

2.2软件风险分析

软件风险分析一般过程:

风险识别+风险预测+风险的驾驭与操控

2.2.1风险识别

下表展示了一些常见的风险：

常见风险	内容
产品规模风险	与软件总体规模相关
商业影响风险	与管理与市场约束相关
与客户相关风险	与客户素质及通信能力相关
过程风险	与软件定义和开发相关
技术风险	与软件复杂性及系统所包含的技术成熟度相关，一般设计、实现、接口和维护等方面的问题。后果：例如：降低软件开发质量，延长交付时间等
开发环境风险	开发工具的可用性与质量
人员结构和经验风险	参与开发人员总体技术水平及项目经验
项目风险	在预算、进度、人力、资源、客户及需求等方面潜在的问题。后果：例如：项目成本提高，时间延长等
商业风险	包括市场、商业策略、推销策略等方面的风险，直接影响软件的生存能力。
销售风险	销售部门是否知道如何推销这种软件？
预算风险	项目预算或参加人员有无保证？
管理风险	有没有因为课题内容或人员的变动，是该项目失去管理层的支持？
策略风险	建立的软件是否符合公司的整体商业策略？
市场风险	建立的软件是否符合市场需求？

2.2.2风险预测（风险估计）

风险发生的可能性+风险可能产生的后果

该做什么?

1.建立风险可能性尺度

2.估计对产品和项目的影响

2.2.3风险的驾驭和监控

2.3系统流程图

定义：

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

基本思想：

用图形符号以黑盒子形式描绘组成系统的每个部件(程序、文档、数据库、人工过程等)。

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

符号：

1.基本符号

以概括的方式抽象地描绘一个实际系统时，仅仅使用下图中列出的基本符号就足够了：

2.系统符号

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

复杂系统，可分层描述。分层步骤如下：

1.首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。

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

一道例题：

该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。

解：

2.4数据流图（结构化分析方法）

概念：

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

数据流四中基本符号：

数据流图中的附加符号：

数据流图中的注意事项：

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