第2章可行性研究47176229.pptx
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
（1）技术可行性：指使用现有的技术能否完成这个 项目。 （2）经济可行性：指通过对软件开发项目进行成本 /效益估计，以确定软件系统可能带来的经济效益能 否超过研制和维护此系统所需的费用。 （3）操作可行性：系统的操作方式在这个用户组织 内行得通吗? （4）社会因素的考虑：软件开发是否会侵犯他人、 集体或国家的利益，是否违反国家的法律并可能由 此而承担法律责任。
4
三、可行性研究的任务
可行性研究的任务是用最小的代价、在尽 可能短的时间内确定问题是否能够解决。在澄 清了问题定义之后，分析员首先应该导出系统 的逻辑模型，然后从系统逻辑模型出发，探索 出若干种可供选择的主要解法（即系统实现方 案）。最后仔细研究每种解法的可行性。
5•
研究可行性应该从下述几方面进行：
6
四、可行性研究的期限与成本
期限：可行性研究需要的时间长短取 决于工程的规模。 成本：一般说来，可行性研究的成本 只是预期的工程总成本的5%～10%。
7
§2.2 可行性研究过程
（1）复查系统规模和目标
（2）研究目前正在使用的系统
（3）导出新系统的高层逻人辑人模型痛恨不写
（4）重新定义问题
文档的人，但
（5）导出和评价供选择的是写方人 文案 人档都不爱
（6）推荐方案和行动方针
（7）草拟开发计划
（8）书写文档、提交审查
8
§2.3 系统流程图
【用 Hale Waihona Puke Baidu】：描绘物理系统的传统工具；
【基本思想】：用图形符号以黑盒子形式描绘系 统里面的每一个部件（程序、文件、数据库、表 格、人工过程等）。
注：尽管系统流程图使用的某些符号和程序流程 图所用的符号相同，但：系统流程图表达的是信 息在系统中各个部件之间流动的情况；程序流程 图表达的是对信息进行加工处理的控制过程。
• 20
输入
处理
输出
图2.5 定货系统的基本系统模型（抽象描述）
• 21
编号规则：如1、2 或P1,P2 或1.1、1.2 或P1.1、P2.1等等
图2.6 定货系统的功能级数据流图（细化） • 22
图2.7 把处理事务的功能进一步分解后的数据流图
23
§2.4.3 命名的可理解性
数据流图中每个成分的命名是否恰当，直接 影响数据流图的可理解性。
软件工程
张聚礼 zhjl@lut.cn
兰州理工大学计算机与通信学院
1
第2章 可行性研究
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析 2.7 小结 习题
2
§2.1 可行性研究的任务
一、 问题定义的内容
首先明确：问题的背景、开发系统的现状； 开发的理由和条件、开发系统的问题要求； 总体要求、问题的性质、类型范围； 要实现的目标、功能规模、实现目标的方案 开发的条件、环境要求等等。
12
§2.3.2 例子
说明： 图中每个符号用黑盒子形
式定义了组成系统的一个部 件，然而并没有指明每个部 件的具体工作过程；图中的 箭头确定了信息通过系统的 逻辑路径。
系统流程图的习惯画法是 使信息在图中从顶向下或从 左向右流动。
图2.3 库存清单系统的系统流程图13
§2.4 数据流图
数据流图(DFD)是一种图形化技术，它描绘 信息流和数据从输入移动到输出的过程中所 经受的变换。 注意：设计数据流图时只需考虑系统必须完 成的基本逻辑功能，即数据流图的基本要点 是描绘“做什么”，而不考虑“怎样做” 。
【可理解性分析】与实际业务结合分别对数 据流(数据存储) 、处理过程、数据流的源点 与终点进行命名。
例如：暂存订单、库存清单、订货信息、 采购员、库存管理员、供应商、产生到货通 知单、产生报表 等等。
24
§2.4.4 用途 数据加工 (数据变换)
数据源点或终点 (外部实体)
【用途】：信息交流的数工据流具，作为分析和设
数据流图中的四种主要图形元素
或
数据加工 (数据变换)
或
数据源点或终点 (外部实体)
数据流
或
数据存储文件
• 18
内容提示：
数据存储和数据流都是数据，仅仅所处的状 态不同。 数据存储是处于静止状态的数据，数据流是 处于运动中的数据。
19
§2.4.2 例子
【业务分析举例】假设一家工厂的采购部每天需要一
计的工具。
数据存储文件
【主要体现】：分析员把他对现有系统的认 识或对目标系统的设想用数据流图描绘出来， 供有关人员审查确认。
【易理解性】：仅使用4种基本符号，不包含 任何有关物理实现的细节，使用户都可以理 解和评价它。
• 25
数据流图应该分层，分层越细、功能越 详细。 (见后案例介绍)
数据流图对更详细的设计步骤也有帮助， 本书第5章将讲述从数据流图出发映射 出软件结构的方法——面向数据流的设 计方法。
然后写出：问题定义报告（或称系统定义报告），以供 可行性分析阶段使用。
3
二、 问题定义的步骤
在问题定义阶段，系统分析员要深入现场，阅读 用户写的书面报告、听取用户对开发系统的要求、 调查开发系统的背景理由。还要与用户负责人反 复讨论，以澄清模糊的地方、改正不正确的地方。 最后写出双方都满意的问题定义报告，并确定双 方是否可继续合作的意向。
9
§2.3.1 符号
当以概括的方式抽象地描绘一个实际系统 时，使用图2.1中列出的基本符号。
当需要更具体地描绘一个物理系统时还需 要使用图2.2（见书29页）中列出的系统符 号（经常使用）。
利用这些符号可以把抽象处理具体化为特 定的程序或手工操作等。
• 10
图2.1 基本符号
• 11
图 2.2 系 统 符 号
张定货报表，报表按零件编号排序，表中列出所有需要 再次定货的零件。
【提取数据举例】对于每个需要再次定货的零件应该
列出下述数据：零件编号，零件名称，定货数量，目前 价格，主要供应者，次要供应者。
【分析事务举例】零件入库或出库称为事务，通过放
在仓库中的CRT终端把事务报告给定货系统。当某种零 件的库存数量少于库存量临界值时就应该再次定货。
• 14
数据流图
数据存储
信息需求
数据流
数据来源
处
理
数据流 数据输出
处理需求
• 15
数据流图示例
报销登记
报销人 报销单
付款凭证 审查 分录
数据流图是系统逻辑功能的图形表示，即使不 是专业的计算机技术人员也容易理解它，因此 是分析员与用户之间极好的通信工具。
• 16
描述银行取款过程的数据流图
17
§2.4.1 符号
4
三、可行性研究的任务
可行性研究的任务是用最小的代价、在尽 可能短的时间内确定问题是否能够解决。在澄 清了问题定义之后，分析员首先应该导出系统 的逻辑模型，然后从系统逻辑模型出发，探索 出若干种可供选择的主要解法（即系统实现方 案）。最后仔细研究每种解法的可行性。
5•
研究可行性应该从下述几方面进行：
6
四、可行性研究的期限与成本
期限：可行性研究需要的时间长短取 决于工程的规模。 成本：一般说来，可行性研究的成本 只是预期的工程总成本的5%～10%。
7
§2.2 可行性研究过程
（1）复查系统规模和目标
（2）研究目前正在使用的系统
（3）导出新系统的高层逻人辑人模型痛恨不写
（4）重新定义问题
文档的人，但
（5）导出和评价供选择的是写方人 文案 人档都不爱
（6）推荐方案和行动方针
（7）草拟开发计划
（8）书写文档、提交审查
8
§2.3 系统流程图
【用 Hale Waihona Puke Baidu】：描绘物理系统的传统工具；
【基本思想】：用图形符号以黑盒子形式描绘系 统里面的每一个部件（程序、文件、数据库、表 格、人工过程等）。
注：尽管系统流程图使用的某些符号和程序流程 图所用的符号相同，但：系统流程图表达的是信 息在系统中各个部件之间流动的情况；程序流程 图表达的是对信息进行加工处理的控制过程。
• 20
输入
处理
输出
图2.5 定货系统的基本系统模型（抽象描述）
• 21
编号规则：如1、2 或P1,P2 或1.1、1.2 或P1.1、P2.1等等
图2.6 定货系统的功能级数据流图（细化） • 22
图2.7 把处理事务的功能进一步分解后的数据流图
23
§2.4.3 命名的可理解性
数据流图中每个成分的命名是否恰当，直接 影响数据流图的可理解性。
软件工程
张聚礼 zhjl@lut.cn
兰州理工大学计算机与通信学院
1
第2章 可行性研究
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析 2.7 小结 习题
2
§2.1 可行性研究的任务
一、 问题定义的内容
首先明确：问题的背景、开发系统的现状； 开发的理由和条件、开发系统的问题要求； 总体要求、问题的性质、类型范围； 要实现的目标、功能规模、实现目标的方案 开发的条件、环境要求等等。
12
§2.3.2 例子
说明： 图中每个符号用黑盒子形
式定义了组成系统的一个部 件，然而并没有指明每个部 件的具体工作过程；图中的 箭头确定了信息通过系统的 逻辑路径。
系统流程图的习惯画法是 使信息在图中从顶向下或从 左向右流动。
图2.3 库存清单系统的系统流程图13
§2.4 数据流图
数据流图(DFD)是一种图形化技术，它描绘 信息流和数据从输入移动到输出的过程中所 经受的变换。 注意：设计数据流图时只需考虑系统必须完 成的基本逻辑功能，即数据流图的基本要点 是描绘“做什么”，而不考虑“怎样做” 。
【可理解性分析】与实际业务结合分别对数 据流(数据存储) 、处理过程、数据流的源点 与终点进行命名。
例如：暂存订单、库存清单、订货信息、 采购员、库存管理员、供应商、产生到货通 知单、产生报表 等等。
24
§2.4.4 用途 数据加工 (数据变换)
数据源点或终点 (外部实体)
【用途】：信息交流的数工据流具，作为分析和设
数据流图中的四种主要图形元素
或
数据加工 (数据变换)
或
数据源点或终点 (外部实体)
数据流
或
数据存储文件
• 18
内容提示：
数据存储和数据流都是数据，仅仅所处的状 态不同。 数据存储是处于静止状态的数据，数据流是 处于运动中的数据。
19
§2.4.2 例子
【业务分析举例】假设一家工厂的采购部每天需要一
计的工具。
数据存储文件
【主要体现】：分析员把他对现有系统的认 识或对目标系统的设想用数据流图描绘出来， 供有关人员审查确认。
【易理解性】：仅使用4种基本符号，不包含 任何有关物理实现的细节，使用户都可以理 解和评价它。
• 25
数据流图应该分层，分层越细、功能越 详细。 (见后案例介绍)
数据流图对更详细的设计步骤也有帮助， 本书第5章将讲述从数据流图出发映射 出软件结构的方法——面向数据流的设 计方法。
然后写出：问题定义报告（或称系统定义报告），以供 可行性分析阶段使用。
3
二、 问题定义的步骤
在问题定义阶段，系统分析员要深入现场，阅读 用户写的书面报告、听取用户对开发系统的要求、 调查开发系统的背景理由。还要与用户负责人反 复讨论，以澄清模糊的地方、改正不正确的地方。 最后写出双方都满意的问题定义报告，并确定双 方是否可继续合作的意向。
9
§2.3.1 符号
当以概括的方式抽象地描绘一个实际系统 时，使用图2.1中列出的基本符号。
当需要更具体地描绘一个物理系统时还需 要使用图2.2（见书29页）中列出的系统符 号（经常使用）。
利用这些符号可以把抽象处理具体化为特 定的程序或手工操作等。
• 10
图2.1 基本符号
• 11
图 2.2 系 统 符 号
张定货报表，报表按零件编号排序，表中列出所有需要 再次定货的零件。
【提取数据举例】对于每个需要再次定货的零件应该
列出下述数据：零件编号，零件名称，定货数量，目前 价格，主要供应者，次要供应者。
【分析事务举例】零件入库或出库称为事务，通过放
在仓库中的CRT终端把事务报告给定货系统。当某种零 件的库存数量少于库存量临界值时就应该再次定货。
• 14
数据流图
数据存储
信息需求
数据流
数据来源
处
理
数据流 数据输出
处理需求
• 15
数据流图示例
报销登记
报销人 报销单
付款凭证 审查 分录
数据流图是系统逻辑功能的图形表示，即使不 是专业的计算机技术人员也容易理解它，因此 是分析员与用户之间极好的通信工具。
• 16
描述银行取款过程的数据流图
17
§2.4.1 符号