第3讲 可行性研究1.ppt

2 数据流图的层次结构 为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解（处理），并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统 * * 图2-4分层数据流图 在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据 底层流图是指其加工不需再做分解的数据流图，它处在最底层只要是模块的最底层就是底层流图，不管是第二层还是第三层的底层 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。 * 2.4.2数据流图—例子 工厂的采购部每天需要一张订货报表，报表按零件排序，对每个需要订货的零件列出下述数据：零件编号，零件名称，定货数量，目前价格，主要供应者，次要供应者。 当零件的库存数量少于临界值就再次定货 * 采购员 采购员 仓库 管理员 定货系统 定货 报表 事务 图2-5定货系统的顶层数据流图 * 采购员 仓库 管理员 1 事务处理 2 产生报表 库存清单 D1 定货信息 D2 定货 信息 库存 清单 定货 信息 定货 报表 事务 图2-6定货系统的第一层数据流图 一级数据流图或功能级数据流图，可看到事务大概走向 思考：事务处理可否进一步分解？ 仓库管理员是一个输入，输入一个事务 1表示第1个处理模块，名叫处理事务或事务处理单元或事务处理程序 D1为编号，数据D1叫库存清单 交换数据也叫库存清单 * 图2-7定货系统的第二层数据流图 仓库 管理员 库存清单 D1 库存 清单 采购员 1.3 处理定货 2 产生报表 定货信息 D2 定货 信息 定货 信息 定货 报表 事务 1.1 接收事务 1.2 更新库存 库存 信息 事务 数据流图分层细化时必须保持信息连续性，跟前一层的信息完全一样。3 命名 为数据流图(或数据存储)命名跟数据本身相关联 （1）名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。 （2）不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。 （3）如果在为某个数据流（或数据存储）起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该尝试进行重新分解。* 为处理命名。表征数据是怎样处理的。 （1）通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。 （2）名字应该反映整个处理的功能，而不是它的一部分功能。 （3）名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。 （4）通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 （5）如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的情况，应考虑重新分解。 * 5）检查和修改数据流图的原则 数据流图上所有图形符号只限于前述四种基本图形元素，并且必须包括前述四种基本元素，缺一不可。 数据流图的主图上的数据流必须封闭在外部实体之间。 每个加工至少有一个输入数据流和一个输出数据流。 在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系。 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。 可以在数据流图中加入物质流，帮助用户理解数据流图。 图上每个元素都必须有名字。 数据流图中不可夹带控制流。 初画时可以忽略琐碎的细节 * 2.5 成本／效益分析 1、成本估计 代码行技术 ，根据经验和历史数据估计实现一个功能需要的源程序行数。每行代码的平均成本 ? 源代码行数 （ 每行平均 成本取决于工资水平和复杂程度） 任务分解技术，最常用按开发阶段划分任务，估计每个任务的成本，最后累加得出软件开发工程总成本，通常先估计完成该项任务需要的人力（人/月），再乘以每人每月平均工资得出每个任务成本。典型环境下各个开发阶段需要使用的人力的百分比如表 * 2.6 开发人员组成和进度安排 * 任务 人力（%）可行性研究 5需求分析 15设计 25编码和单元测试 20* 综合测试 35 产品开发团队 1个产品/项目总监 架构师1，公共代码开发2 业务组长1，主要代码开发1，辅助代码开发1 每个子系统3人，假设4个子系统，12人 每个子系统测试1人，4+1（公共代码） 每个子系统一个文档编写，1个培训 共27人 * 开发周期-开发费用 调研14天，开发60天 测试10天，文档10天，内部培训10天 共94天 每个人平均6000元 成本=6000*27*3=486000元 加上30%或者更多利润 *成本效益分析的方法 投资回收期