02章 可行性研究讲义.ppt

* * * 可行性研究报告的编写GB 8567-88《 计算机软件产品开发文件编制指南 》 * * * 如图2.4(a)所示，数据流图有4种基本符号：正方形(或立方体)表示数据的源点或终点；圆角矩形(或圆形)代表变换数据的处理；开口矩形(或两条平行横线)代表数据存储；箭头表示数据流，即特定数据的流动方向。注意，数据流与程序流程图(参看本书第5章)中用箭头表示的控制流有本质不同，千万不要混淆。熟悉程序流程图的初学者在画数据流图时，往往试图在数据流图中表现分支条件或循环，殊不知这样做将造成混乱，画不出正确的数据流图。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。 * * 首先以大家熟悉的事务处理--------“我们去银行取款为例”来说明数据流图描述数据处理的过程。 下图表示储户到银行用存折取款的手续。储户把存折和取款单一并交给银行出纳员检验。出纳员核对帐目，一旦发现 存折有效性问题、取款单填写问题或是存折、帐卡与取款但不符等问题时均应报告储户。在检验通过后，出纳员将取款 信息登记在存折和帐卡上，并通知付款。根据付款通知给储户，从而完成这一简单的数据处理活动。 * * * * * * * 考虑通过系统的逻辑数据流：当发生一个事务时必须首先接收它；随后按照事务的内容修改库存清单；最后如果更新后的库存量少于库存量临界值时，则应该再次订货，也就是需要处理订货信息。因此，把“处理事务”这个功能分解为下述3个步骤，这在逻辑上是合理的：“接收事务”、“更新库存清单”和“处理订货”(图2.7)。 图2.6订货系统的功能级数据流图图2.7把处理事务的功能进一步分解后的数据流图为什么不进一步分解“产生报表”这个功能呢?订货报表中需要的数据在存储的订货信息中全都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。同样道理，对“接收事务”或“更新库存清单”等功能也没有必要进一步细化。总之，当进一步分解将涉及如何具体地实现一个功能时就不应该再分解了。 当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入输出数据流必须相同。例如，图2.5和图2.6的输入输出数据流都是“事务”和“订货报表”；图2.6中“处理事务”这个处理框的输入输出数据流是“事务”、“库存清单”和“订货信息”，分解成“接收事务”、“更新库存清单”和“处理订货”3个处理之后(图2.7)，它们的输入输出数据流仍然是“事务”、“库存清单”和“订货信息”。 此外还应该注意在图2.7中对处理进行编号的方法。处理1.1，1.2和1.3是更高层次的数据流图中处理1的组成元素。如果处理2被进一步分解，它的组成元素的编号将是2.1，2.2，…；如果把处理1.1进一步分解，则将得到编号为1.1.1，1.1.2，…的处理。 * * * * * * * * * 数据字典最重要的用途是作为分析阶段的工具。在数据字典中建立的一组严密一致的定义很有助于改进分析员和用户之间的通信，因此将消除许多可能的误解。对数据的这一系列严密一致的定义也有助于改进在不同的开发人员或不同的开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题。 数据字典中包含的每个数据元素的控制信息是很有价值的。因为列出了使用一个给定的数据元素的所有程序(或模块)，所以很容易估计改变一个数据将产生的影响，并且能对所有受影响的程序或模块作出相应的改变。 最后，数据字典是开发数据库的第一步，而且是很有价值的一步。 * 除了数据定义之外，数据字典中还应该包含关于数据的一些其他信息。典型的情况是，在数据字典中记录数据元素的下列信息： 一般信息(名字，别名，描述等)，定义(数据类型，长度，结构等)，使用特点(值的范围，使用频率，使用方式——输入、输出、本地，条件值等)，控制信息(来源，用户，使用它的程序，改变权，使用权等)和分组信息(父结构，从属结构，物理位置——记录、文件和数据库等)。 * * * * * * * * * 成本估算不是精确的科学，因此应该使用几种不同的估计技术以便相互校验 * 代码行技术是比较简单的定量估算方法。具体计算方法见13.1.1 章节 * 具体计算方法见软件项目管理时13.2章节 * 软件的可行性研究中不包括（ ） ?Ａ、法律可行性?Ｂ、技术可行性?Ｃ、经济可行性?Ｄ、政治可行性? 本章小结 第2章可行性研究 * * 我们还记得在瀑布模型中软件生存周期的第一个时期是计划时期，它包括问题的定义和可性行研究两个阶段。 问题定义是计划时期的第一个阶段，其目的是要弄清楚用户需要计算机解决什么样的问题