软件工程第二章课件.ppt
合集下载
软件工程课本讲解第2章 软件要求定义【ppt】
表2-2
年 1 2 3 4 5 将 来 值 / 千 元 2 .5 2 .5 2 .5 2 .5 2 .5 ( 1 + n · 0 .0 5 ) 1 .0 5 1 .1 1 .1 5 1 .2 1 .2 5 现 在 值 / 千 元 2 .3 8 1 2 .2 7 3 2 .1 7 4 2 .0 8 3 2 .0 累 计 的 现 在 值 / 千 元 2 .3 8 1 4 .6 5 4 6 .8 2 8 8 .9 1 1 1 0 .9 1 1
现有管理制度、人员素质和操作方式是否可行，这些即 为社会可行性研究的内容。
社会可行性所涉及的范围也比较广，它包括合同、
责任、侵权、用户组织的管理模式及规范，其他一些技 术人员常常不了解的陷阱等。
2.1.2
可行性研究的具体步骤
典型的可行性研究有下列步骤： (1) 确定项目规模和目标。分析员对有关人员进行调查 访问，仔细阅读和分析有关的材料，对项目的规模和目标进 行定义和确认，清晰地描述项目的一切限制和约束，确保分 析员正在解决的问题确实是需要解决的问题。 (2) 研究正在运行的系统。正在运行的系统可能是一个 人工操作的系统，也可能是旧的计算机系统，因而需要开发 一个新的计算机系统来代替现有系统。现有的系统是信息的 重要来源。人们需要研究它的基本功能，存在什么问题，运 行现有系统需要多少费用，对新系统有什么新的功能要求， 新系统运行时能否减少使用费用等。
行度量；无形效益主要从性质上、心理上进行衡量，很 难直接进行量的比较。系统的经济效益等于因使用新的
系统而增加的收入加上使用新的系统可以节省的运行费
用。运行费用包括操作人员人数、工作时间和消耗的物 资等。下面主要介绍有形效益的分析。
F = P·(1+n·i) F就是P元在n年后的价值。反之，若n年后能收入F
第二章-软件开发方法概述-PPT课件
把问题／子问题的分解与软件开发 中的系统／子系统或系统／模块对 应起来，就能够把一个大而复杂的 软件系统划分成易于理解的比较单 纯的模块结构。
31
抽象化
软件系统进行模块设计时，可有不 同的抽象层次。 在最高的抽象层次上，可以使用问 题所处环境的语言概括地描述问题 的解法。 在较低的抽象层次上，则采用过程 化的方法。
16
实用性：确认该设计对于需求的解 决方案是否实用 技术清晰度：确认该设计是否以一 种易于翻译成代码的形式表达 可维护性：确认该设计是否考虑了 方便未来的维护 质量：确认该设计是否表现出良好 的质量特征
17
各种选择方案：看是否考虑过其 它方案，比较各种选择方案的标 准是什么 限制：评估对该软件的限制是否 现实，是否与需求一致 其它具体问题：对于文档、可测 试性、设计过程..等进行评估
49
公共耦合的复杂程度随耦合模块的个 数增加而显著增加。若只是两模块间 有公共数据环境，则公共耦合有两种 情况。松散公共耦合和紧密公共耦合。
50
内容耦合 (Content Coupling)
如果发生下列情形，两个模块之间 就发生了内一个模块不通过正常入口转 到另一模块内部;
28
④ 在模块A的箭头尾部标以一个菱 形符号，表示模块A有条件地调用 另一个模块B。当一个在调用箭头 尾部标以一个弧形符号，表示模块 A反复调用模块C和模块D。
29
程序的系统结构图
30
模块化
软件系统的模块化是指整个软件被 划分成若干单独命名和可编址的部 分，称之为模块。这些模块可以被 组装起来以满足整个问题的需求。
外部耦合（External Coupling）
一组模块都访问同一全局简单变量而 不是同一全局数据结构，而且不是通 过参数表传递该全局变量的信息，则 称之为外部耦合。
31
抽象化
软件系统进行模块设计时，可有不 同的抽象层次。 在最高的抽象层次上，可以使用问 题所处环境的语言概括地描述问题 的解法。 在较低的抽象层次上，则采用过程 化的方法。
16
实用性：确认该设计对于需求的解 决方案是否实用 技术清晰度：确认该设计是否以一 种易于翻译成代码的形式表达 可维护性：确认该设计是否考虑了 方便未来的维护 质量：确认该设计是否表现出良好 的质量特征
17
各种选择方案：看是否考虑过其 它方案，比较各种选择方案的标 准是什么 限制：评估对该软件的限制是否 现实，是否与需求一致 其它具体问题：对于文档、可测 试性、设计过程..等进行评估
49
公共耦合的复杂程度随耦合模块的个 数增加而显著增加。若只是两模块间 有公共数据环境，则公共耦合有两种 情况。松散公共耦合和紧密公共耦合。
50
内容耦合 (Content Coupling)
如果发生下列情形，两个模块之间 就发生了内一个模块不通过正常入口转 到另一模块内部;
28
④ 在模块A的箭头尾部标以一个菱 形符号，表示模块A有条件地调用 另一个模块B。当一个在调用箭头 尾部标以一个弧形符号，表示模块 A反复调用模块C和模块D。
29
程序的系统结构图
30
模块化
软件系统的模块化是指整个软件被 划分成若干单独命名和可编址的部 分，称之为模块。这些模块可以被 组装起来以满足整个问题的需求。
外部耦合（External Coupling）
一组模块都访问同一全局简单变量而 不是同一全局数据结构，而且不是通 过参数表传递该全局变量的信息，则 称之为外部耦合。
软件工程(第3版)第2章 人民邮电出版社PPT课件
用于成功开发软件的一组基本观念和原则
6条“最佳实践” 10个“流程要素”
可重用方法内容及流程构建块的框架
可以在定义自己的开发方法和过程
底层方法及流程定义语言
统一方法架构元模型 UML
RUP最佳实践
迭代式开发 需求管理 使用基于组件的架构 可视化建模 验证软件质量 控制软件变更
问题定义 可行性研究 需求分析 概要设计 详细设计 编码和单元测试 集成测试（综合测试） 软件维护
瀑布模型
收集需求 分析 设计 编码 测试 维护
瀑布模型 - 加入迭代过程
收集需求 分析 设计 编码 测试 维护
快速原型法
快速建立一个反映用户 主要需求的原型系统
可视化编程工具的广泛 使用
架构和组件
软件架构（Software Architecture）
构成系统的组件 组件之间的关联和交互
架构刻画了系统的整体设计
去掉了细节部分 突出了系统的重要特征
可视化建模
由于应用领域不同，模型可以有文字、图形或数学 表达式等多种形式，一般说来，使用可视化的图形 更容易令人理解。
验证软件质量
用户故事 需求
测试用例 新用户故事
差错
隐喻 架构试探
制定交付 交付计划 计划
不确定的估计
确定的估计
最新版本
用户认可
迭代开发
验收测试
下一次迭代
小交付
难点试探
XP(极限编程Extreme Programming)的整体开发过程
极限编程
未完成的任务 用户故事 交付计划 项目速率
新用户故事 新项目速率
共享的信息
能力成熟度模型的结构
能力成熟度等级
初始级 可重复级 已定义级 已管理级 优化级
6条“最佳实践” 10个“流程要素”
可重用方法内容及流程构建块的框架
可以在定义自己的开发方法和过程
底层方法及流程定义语言
统一方法架构元模型 UML
RUP最佳实践
迭代式开发 需求管理 使用基于组件的架构 可视化建模 验证软件质量 控制软件变更
问题定义 可行性研究 需求分析 概要设计 详细设计 编码和单元测试 集成测试（综合测试） 软件维护
瀑布模型
收集需求 分析 设计 编码 测试 维护
瀑布模型 - 加入迭代过程
收集需求 分析 设计 编码 测试 维护
快速原型法
快速建立一个反映用户 主要需求的原型系统
可视化编程工具的广泛 使用
架构和组件
软件架构（Software Architecture）
构成系统的组件 组件之间的关联和交互
架构刻画了系统的整体设计
去掉了细节部分 突出了系统的重要特征
可视化建模
由于应用领域不同，模型可以有文字、图形或数学 表达式等多种形式，一般说来，使用可视化的图形 更容易令人理解。
验证软件质量
用户故事 需求
测试用例 新用户故事
差错
隐喻 架构试探
制定交付 交付计划 计划
不确定的估计
确定的估计
最新版本
用户认可
迭代开发
验收测试
下一次迭代
小交付
难点试探
XP(极限编程Extreme Programming)的整体开发过程
极限编程
未完成的任务 用户故事 交付计划 项目速率
新用户故事 新项目速率
共享的信息
能力成熟度模型的结构
能力成熟度等级
初始级 可重复级 已定义级 已管理级 优化级
软件工程第二章(精)
喷泉模型该模型表明软件开发活动之间没 有明显的间隙，用于支持面向对象开发过程。 由于对象概念的引入，使分析、设计、实现之 间的表达没有明显间隙。并且，这一表达自然 地支持复用。
调 试
（4）详细设计
维 护
（5）编码（实现）
（6）软件测试、运行／维护
退 役 图 2.1 软件生命周期
2。2软件开发生命周期过程和活动
软件生命周期过程的 IEEE（美国电气电子工程师学 会 IEEE ）标准描述了一系列活动和过程，对于 [IEEE Std ． 1074-1995] 的软件的开发和和维护来说这些活动 是强制性的。它的目标是为开发生命周期模型建立一 个通用框架。在这一节，我们描述由这一标准引入的 主要过程和活动。 过程是一系列朝着特定目标（例如，需求、管理、 发布）执行的活动。 IEEE 标准一共列出了 17 个过程（ 见表2.1 ）。把过程分组成更高层的抽象称为过程组（ process group）。 过程组的例子是项目管理、前期开发、开发和后期开 发。 表2.1 IEEE 1074的软件过程
第2章 软件生命周期及软件开 发模型
学习要点：
• 软件生命周期表明软件从功能确定、设计， 到开发成功投入使用，并在使用中不断地修改、 增补和完善，直至被新的需要所替代而停止该 软件的使用的全过程。
•软件开发模型是从软件项目需求定义直至软件 经使用后废弃为止，跨越整个生存期的系统开 发、运作和维护所实施的全部过程、活动和任 务的结构框架。
2。2软件开发生命周期过程和活动
• 过程组
生命周期建模 项目管理 项目监控和控制 软件质量管理 前期开发 开发 后期开发
过程
选择生命周期模型 项目启动
整体过程
概念探讨 系统配置 需求设计 实现 安装 操作和支持 维护 报废 验证并确认 软件配置管理 文档开发
调 试
（4）详细设计
维 护
（5）编码（实现）
（6）软件测试、运行／维护
退 役 图 2.1 软件生命周期
2。2软件开发生命周期过程和活动
软件生命周期过程的 IEEE（美国电气电子工程师学 会 IEEE ）标准描述了一系列活动和过程，对于 [IEEE Std ． 1074-1995] 的软件的开发和和维护来说这些活动 是强制性的。它的目标是为开发生命周期模型建立一 个通用框架。在这一节，我们描述由这一标准引入的 主要过程和活动。 过程是一系列朝着特定目标（例如，需求、管理、 发布）执行的活动。 IEEE 标准一共列出了 17 个过程（ 见表2.1 ）。把过程分组成更高层的抽象称为过程组（ process group）。 过程组的例子是项目管理、前期开发、开发和后期开 发。 表2.1 IEEE 1074的软件过程
第2章 软件生命周期及软件开 发模型
学习要点：
• 软件生命周期表明软件从功能确定、设计， 到开发成功投入使用，并在使用中不断地修改、 增补和完善，直至被新的需要所替代而停止该 软件的使用的全过程。
•软件开发模型是从软件项目需求定义直至软件 经使用后废弃为止，跨越整个生存期的系统开 发、运作和维护所实施的全部过程、活动和任 务的结构框架。
2。2软件开发生命周期过程和活动
• 过程组
生命周期建模 项目管理 项目监控和控制 软件质量管理 前期开发 开发 后期开发
过程
选择生命周期模型 项目启动
整体过程
概念探讨 系统配置 需求设计 实现 安装 操作和支持 维护 报废 验证并确认 软件配置管理 文档开发
软件工程课件第二章
GB 8567-88《计算机软件产品开发文件编制指南》
8
§2.3 系统流程图
可行性分析的描述手段： 系统流程图、数据流图 1、什么是系统流程图？ 概括地描绘物理系统的传统工具。
基本思想：用图形符号以黑盒子形式描绘组 成系统的每个部件(程序，文档，数据库，人工 过程等)，表达数据在系统各部件之间流动的情 况。
3、操作可行性：系统的操作方式在用户组织内行得通吗？ 4、其他：法律可行性、社会效应、管理问题等
5
国家标准定义的可行性研究
•
了解客户的要求及现实环境，从技术、经济和社 会因素等三方面研究并论证本软件项目的可行性， 编写可行性研究报告，制定初步项目开发计划。 ----GB 8566-88《计算机软件开发规范》
计算机辅助设计（CAD）的软件项目估算将 CAD项目分为如下7个子项目：
用户界面和控制； 二维几何分析； 三维几何分析； 数据库管理； 计算机图形显示； 外设控制； 设计分析
16
代码行和成本、工作量估算
功能
用户界面 和控制 二维几 何分析 三维几 何分析 数据库 管理
乐观估 计LOC 1790 4080 4600 2900
一般估 计LOC 2400 5200 6900 3400
悲观估 计LOC 2650 7400 8600 3600
加权平 均 2340 5380 6800 3350
美元 /LOC 14 20 20 18
LOC/PM 315 220 220 240
成本(美 工作量 元) (人月) 32760 107600 136000 60300 7.4 24.4 30.9 13.9
第2章 可行性研究
1
本章教学内容
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析 2.7 小结
8
§2.3 系统流程图
可行性分析的描述手段： 系统流程图、数据流图 1、什么是系统流程图？ 概括地描绘物理系统的传统工具。
基本思想：用图形符号以黑盒子形式描绘组 成系统的每个部件(程序，文档，数据库，人工 过程等)，表达数据在系统各部件之间流动的情 况。
3、操作可行性：系统的操作方式在用户组织内行得通吗？ 4、其他：法律可行性、社会效应、管理问题等
5
国家标准定义的可行性研究
•
了解客户的要求及现实环境，从技术、经济和社 会因素等三方面研究并论证本软件项目的可行性， 编写可行性研究报告，制定初步项目开发计划。 ----GB 8566-88《计算机软件开发规范》
计算机辅助设计（CAD）的软件项目估算将 CAD项目分为如下7个子项目：
用户界面和控制； 二维几何分析； 三维几何分析； 数据库管理； 计算机图形显示； 外设控制； 设计分析
16
代码行和成本、工作量估算
功能
用户界面 和控制 二维几 何分析 三维几 何分析 数据库 管理
乐观估 计LOC 1790 4080 4600 2900
一般估 计LOC 2400 5200 6900 3400
悲观估 计LOC 2650 7400 8600 3600
加权平 均 2340 5380 6800 3350
美元 /LOC 14 20 20 18
LOC/PM 315 220 220 240
成本(美 工作量 元) (人月) 32760 107600 136000 60300 7.4 24.4 30.9 13.9
第2章 可行性研究
1
本章教学内容
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析 2.7 小结
第二章_软件工程(可行性分析)
用户单位：xx 校财务处 负 责 人：xxx 分析员单位：xx软件开发公司 分析员：xxx 项目名称：工资管理系统 项目背景：财务处每月工资管理工作太忙，花费精力太大…… 项目目标：开发一个高效的工资管理系统，实现财务支付的 科学管理，工资审核与计算等功能。 项目规模：开发成本约2.4万元
6
2.2 可行性研究
• 课题提出：系统开发人员本身也可以提出系统开发任 务。
• 上级机关布置 • 合作开发
2. 系统任务的提出形式
• 书面形式：系统任务的提出一般以书面形式，如系统 开发任务书或系统开发协议书等形式。
• 口头形式
2
❖ 系统目标的确定
1. 系统目标的含义 系统目标是系统最终要达到的目标，是系统开
发的宗旨，各个阶段的工作都要以这个宗旨为中心。 2. 如何确定系统的目标
23Βιβλιοθήκη 2、成本/收益分析 系统收益分为经济收益和社会收益两方面，社会收
益具有无形性。经济收益主要是新系统将来增加的收 入或可节约的成本。一般说来，投资是现在的支出， 而收益是将来的收入，因此必须考虑货币的时间价值 。
（1）货币的时间价值：货币的时间价值是指同样数 量的货币随时间的不同具有不同的价值。货币的时间 价值一般用利率形式表示，因为一定数量的货币如果 不做其他投资，放在银行里是可以获得利息的。
9
（3）导出新系统的高层逻辑模型，绘制系统流 程图和数据流图，并与现有系统进行比较。
（4）重新定义问题，再次复审工程规模目标和 约束条件，若发现对问题的说明或对用户的 要求有遗漏应及时修改。
（5）导出若干高层次的物理解法，通过对解法 的技术可行性、经济可行性、运行可行性进 行比较分析，推荐行动方案。
假设年利率为 i，现在存入P元钱，n 年后的价值为 F，则F= P(1+i)n ；反之，如果n年后能收入 F元钱， 这些钱现在的价值是P= F/(1+i)n ，称为折现 P36
6
2.2 可行性研究
• 课题提出：系统开发人员本身也可以提出系统开发任 务。
• 上级机关布置 • 合作开发
2. 系统任务的提出形式
• 书面形式：系统任务的提出一般以书面形式，如系统 开发任务书或系统开发协议书等形式。
• 口头形式
2
❖ 系统目标的确定
1. 系统目标的含义 系统目标是系统最终要达到的目标，是系统开
发的宗旨，各个阶段的工作都要以这个宗旨为中心。 2. 如何确定系统的目标
23Βιβλιοθήκη 2、成本/收益分析 系统收益分为经济收益和社会收益两方面，社会收
益具有无形性。经济收益主要是新系统将来增加的收 入或可节约的成本。一般说来，投资是现在的支出， 而收益是将来的收入，因此必须考虑货币的时间价值 。
（1）货币的时间价值：货币的时间价值是指同样数 量的货币随时间的不同具有不同的价值。货币的时间 价值一般用利率形式表示，因为一定数量的货币如果 不做其他投资，放在银行里是可以获得利息的。
9
（3）导出新系统的高层逻辑模型，绘制系统流 程图和数据流图，并与现有系统进行比较。
（4）重新定义问题，再次复审工程规模目标和 约束条件，若发现对问题的说明或对用户的 要求有遗漏应及时修改。
（5）导出若干高层次的物理解法，通过对解法 的技术可行性、经济可行性、运行可行性进 行比较分析，推荐行动方案。
假设年利率为 i，现在存入P元钱，n 年后的价值为 F，则F= P(1+i)n ；反之，如果n年后能收入 F元钱， 这些钱现在的价值是P= F/(1+i)n ，称为折现 P36
软件工程课件第2章
过程，也就是在较高层次上以较抽象的方式进 行的系统分析和设计的过程。
精选ppt
6
可行性研究的内容： 首先进一步分析和澄清问题定义，导出系统的
逻辑模型； 然后从系统逻辑模型出发，探索若干种可供选
择的主要解法(即系统实现方案)； 对每种解法都研究它的可行性，至少应该从三
方面研究每种解法的可行性 。
精选ppt
3
关于系统规模和目标的报告书
1.项目名称：教材销售系统 2.问题：人工发售教材手续繁杂，且易出错。 3.项目目标：建立一个高效率、无差错的微机教材销售
系统。 4.项目规模：利用现有微型计算机，软件开发费用不超
过5000元。 5.初步想法：建议在系统中增加对缺书的统计与采购功
能。 6.可行性研究：建议进行大约10天的可行性研究，研究
该装配厂使用一台小型计算机，处理更新库存清单主文 件和产生定货报告。零件库存量的每一次变化称为一个事务， 由放在仓库中CRT终端输入到计算机中；系统中的库存清单 程序对事务进行处理，更新存储在磁盘上的库存清单主文件， 并且把必要的订货信息写在磁带上。最后，每天由报告生成 程序读一次磁带，并且打印出订货报告。
包括开发和运行该系统所需要的各种资源 如硬件、软件、人员和组织机构等 3. 费用预算：分阶段的人员费用、机时费用及其他费用 4. 进度安排：各阶段起始时间、完成文档及验证方式 5. 要交付的产品清单
精选ppt
16
8. 书写文档提交审查 把可行性研究各个步骤的工作结果写成清晰的
文档，请用户、客户组织的负责人及评审组审 查，以决定是否继续这项工程及是否接受分析 员推荐的方案。
库存清单 主文件
报告生成程序
定货报告
第三层：合成后的系统流程图
精选ppt
6
可行性研究的内容： 首先进一步分析和澄清问题定义，导出系统的
逻辑模型； 然后从系统逻辑模型出发，探索若干种可供选
择的主要解法(即系统实现方案)； 对每种解法都研究它的可行性，至少应该从三
方面研究每种解法的可行性 。
精选ppt
3
关于系统规模和目标的报告书
1.项目名称：教材销售系统 2.问题：人工发售教材手续繁杂，且易出错。 3.项目目标：建立一个高效率、无差错的微机教材销售
系统。 4.项目规模：利用现有微型计算机，软件开发费用不超
过5000元。 5.初步想法：建议在系统中增加对缺书的统计与采购功
能。 6.可行性研究：建议进行大约10天的可行性研究，研究
该装配厂使用一台小型计算机，处理更新库存清单主文 件和产生定货报告。零件库存量的每一次变化称为一个事务， 由放在仓库中CRT终端输入到计算机中；系统中的库存清单 程序对事务进行处理，更新存储在磁盘上的库存清单主文件， 并且把必要的订货信息写在磁带上。最后，每天由报告生成 程序读一次磁带，并且打印出订货报告。
包括开发和运行该系统所需要的各种资源 如硬件、软件、人员和组织机构等 3. 费用预算：分阶段的人员费用、机时费用及其他费用 4. 进度安排：各阶段起始时间、完成文档及验证方式 5. 要交付的产品清单
精选ppt
16
8. 书写文档提交审查 把可行性研究各个步骤的工作结果写成清晰的
文档，请用户、客户组织的负责人及评审组审 查，以决定是否继续这项工程及是否接受分析 员推荐的方案。
库存清单 主文件
报告生成程序
定货报告
第三层：合成后的系统流程图
《软件工程电子教案》课件
《软件工程电子教案》PPT课件第一章：软件工程概述1.1 软件工程的定义解释软件工程的含义和目的强调软件工程的重要性1.2 软件开发生命周期介绍软件开发生命周期的基本阶段讨论每个阶段的关键活动和任务1.3 软件工程原则介绍软件工程的基本原则解释每个原则的重要性和应用第二章：需求分析2.1 需求分析的重要性强调需求分析在软件工程中的作用解释需求分析的目标和结果2.2 需求收集和分析方法介绍需求收集和分析的主要方法讨论每种方法的优缺点和适用场景2.3 需求规格说明书解释需求规格说明书的结构和内容强调需求规格说明书的重要性和维护第三章：软件设计和架构3.1 软件设计的重要性强调软件设计在软件工程中的作用解释设计的目标和结果3.2 软件架构设计介绍软件架构设计的基本概念和方法讨论架构设计的重要性和评估3.3 详细设计解释详细设计的过程和工具强调详细设计的重要性和与实现的关联第四章：软件实现和编码4.1 编码的重要性强调编码在软件工程中的作用解释编码的目标和结果4.2 编程语言和工具介绍常用的编程语言和开发工具讨论每种语言和工具的适用场景和特点4.3 编码规范和最佳实践解释编码规范和最佳实践的作用强调遵循规范和最佳实践的重要性第五章：软件测试和验证5.1 软件测试的重要性强调软件测试在软件工程中的作用解释测试的目标和结果5.2 测试方法和策略介绍常用的软件测试方法和策略讨论每种方法和策略的适用场景和优缺点5.3 测试用例和测试覆盖率解释测试用例的设计和编写强调测试覆盖率的重要性和评估方法第六章：软件维护和演化6.1 软件维护的概念解释软件维护的定义和目的强调软件维护的重要性6.2 维护活动和维护过程介绍软件维护的主要活动和过程讨论每个活动的关键任务和挑战6.3 软件演化模型介绍软件演化的一些常见模型讨论每种模型的适用场景和特点第七章：软件项目管理7.1 软件项目管理的重要性强调软件项目管理在软件工程中的作用解释项目管理的目标和结果7.2 项目管理工具和技术介绍常用的软件项目管理工具和技术讨论每种工具和技术的适用场景和优缺点7.3 项目计划和进度控制解释项目计划的概念和过程强调进度控制的重要性和方法第八章：软件质量保证8.1 软件质量的概念解释软件质量的定义和重要性强调软件质量保证的作用8.2 质量标准和质量模型介绍常用的软件质量标准和模型讨论每种标准和模型的适用场景和特点8.3 质量保证过程和活动解释质量保证的过程和主要活动强调质量保证的重要性和实施方法第九章：软件工程伦理和法律问题9.1 软件工程伦理问题讨论软件工程中的伦理问题，如知识产权、隐私等强调软件工程师的伦理责任和行为准则9.2 软件工程法律问题介绍软件工程中涉及的法律问题，如版权、合同等讨论法律问题对软件工程的影响和应对策略9.3 合规性和标准化解释软件工程的合规性和标准化的概念强调合规性和标准化的作用和实施方法第十章：软件工程前沿技术10.1 软件工程新技术介绍软件工程中的一些前沿技术，如、云计算等讨论每种技术的应用场景和前景10.2 技术趋势和挑战讨论软件工程中的技术趋势和面临的挑战强调应对技术趋势和挑战的方法和策略10.3 未来软件工程的发展展望未来软件工程的发展方向和趋势强调软件工程师在未来的角色和责任重点和难点解析重点环节一：软件工程的定义和目的重点关注软件工程的定义和目的，理解软件工程的核心目标和原则。
软件工程PPT课件
2.1.3 方案的选择
分析员考虑问题解决的方案。一般采用将一 个大而复杂的系统分解为若干个子系统的办 法来降低解的复杂性。如何进行系统分解、 如何定义各子系统的功能、性能和界面，实 现方案不唯一。可以采用折衷的方法，反复 比较各个方案的成本∕效益，选择可行的方 案。
2.2 可行性研究过程
1.复查系统规模和目标 2.研究目前正在使用的系统 3.导出新系统的高层逻辑模型 4.进一步定义问题 5.导出和评价供选择的解法 6.推荐行动方针 7.草拟开发计划 8.书写文档提交审查
▪ 法律可行性 ：确定系统开发可能导致的任何侵 权、妨碍和责任。
2.1.1 经济可行性
分析员需要进行成本∕效益分析。 所谓成本，包括：① 购置并安装软、硬件
及有关设备的费用；② 系统开发费用；③ 系 统安装、运行及维护的费用；④ 人员培训费 用。
效益是指：① 系统为用户增加的收入或为 用户节省的开支，这是有形的效益；② 给潜 在用户心理上造成的影响，这是无形的效益。 它可以转化为有形的效益。
可行性研究是在软件项目计划阶段应该做的 事情，包括四个方面的研究： ▪ 经济可行性 ：进行成本∕效益分析。从经济角 度判断系统开发是否“合算”。
▪ 技术可行性 ：进行技术风险评价。从开发者的 技术实力、以往工作基础、问题的复杂性等出 发，判断系统开发在时间、费用等限制条件下 成功的可能性。
▪ 操作可行性 ：评价系统的操作方式在这个用户 组织内是否可行。
类别 大小 难度 限制 资源
经验
项目要素 项目特性
成本模型
开发机构 特性 开发机构要素
进度安排数据
自动化成本估算系统
2.4.3 成本/效益分析的方法
成本/效益分析应包括估计开发成本、运行费 用和新系统将带来的经济效益。
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2.3.1 符号
2021/2/14
5
库存清单系统的系统流程图
2021/2/14
6
2.4 数据流图
•数据流图(DFD)是是系统逻辑功能的图 形表示，描绘信息流和数据从输入移动 到输出的变换过程。
•不涉及具体的物理部件，只描绘数据在 软件中流动和被处理的逻辑过程。
•不需要考虑怎样具体地实现这些功能
•是分析员与用户之间极好的通信工具
2021/2/14
3
2.3 系统流程图
•概括地描绘物理系统的传统工具。
•用图形符号以黑盒子形式描绘组成系统 的每个部件(程序，文档，数据库，人工 过程等)。
•表达的是数据在系统各部件之间流动的 情况（物理数据流图），而不是对数据 进行加工处理的控制过程(程序流程图) 。
2021/2/14
4
基本符号
2021/2/14
25
自动化边界——批量方式更新库存清单
2021/2/14
26
自动化边界——联机方式更新库存清单
2021/2/14
27
2.5 数据字典
•定义数据流图中包含的所有元素 •与数据流图共同构成系统的逻辑模型 •分别对DFD中元素的定义：
(1) 数据流 (2) 数据流分量(即数据元素)
2021/2/14
10
分层的数据流图
2021/2/14
11
• 在多层数据流图中，顶层流图仅包含一 个加工，它代表被开发系统。它的输入 流是该系统的输入数据，输出流是系统 所输出数据
• 底层流图是指其加工不需再做分解的数 据流图，它处在最底层
• 中间层流图则表示对其上层父图的细化 。它的每一加工可能继续细化，形成子 图。
第2章 可行性研究
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析 2.7 小结
2021/2/14
1
2.1 可行性研究的任务
• 目的:确定问题是否值得去解决。 • 实质:在较高层次上以较抽象的方式进
行的系统分析和设计的过程。
取款 信息
帐户信息
21
DFD案例 定货系统基本系统模型
2021/2/14
22
定货系统的功能级数据流图
2021/2/1423Fra bibliotek进一步分解后的数据流图
2021/2/14
24
2.4.4 用途
•分析员与用户交流信息的工具
– 直观 – 易理解 – 避免自然语言歧义性
•分析和设计的工具
– 根据系统的逻辑模型考虑系统的物理实现
父图
子图 4 客户4.1
4.2 提货 单
4
订货 单
提货 单
帐号
4.3
数量
2021/2/14
18
其它元素
2.4.3 命名
(1) 数据源点/终点是目标系统的外部项（人员 、外设、传感器）。
(2) 局部数据存储只有当它作为某些加工的数 据接口或某个加工特定的输入或输出时， 就把它画出来（信息隐蔽）
局部数据存储：不是父图中相应加工的 外部接口，只是本图中某些加工之间的 数据接口。
名字、别名、描述、数据类型、长度、结构、值的范 围、使用方式、控制信息、分组信息等
(3) 数据存储 (4) 处理（结合IPO图或PDL ）
2021/2/14
28
2.5.2 定义数据的方法
2021/2/14
20
0层DFD
储户
存款/取 款单
储蓄系统
存款/取款 信息
储户
存款/取 款单
1层DFD
存款 p1 信息
接收并分类 取款 信息
p2
存款
p3
取款
存款 信息
取款 信息
p4
打印
存款/取款 信息
取款 信息
2层DFD
2021/2/14
取款
P3.1 信息 P3.2
P3.3
验证身份
验证帐户 取款 更新帐户 信息
2021/2/14
12
数据流命名1
2.4.3 命名
• 为数据流(或数据存储)命名
(1) 是名词或名词短语，画数据流而不是 控制流，一般不画物质流（人民币） 。
(2) 名字应代表整个数据流(或数据存储) 的内容，而不是仅仅反映它的某些成 分。
(3) 不要使用空洞的、缺乏具体含义的名
字(如“数据”、“信息”、“输入
(6) 分层的数据流图
7+/-2个加工 编号要一致
(7) 父图与子图的平衡：保证数据流图的 一致性
2021/2/14
16
数据流命名3 父图与子图的平衡
图 2
b 2.2
图 2.1 e
a1 2.1.2 b
a 2.1
d
a 2.1.1
c 2.3
a2 2.1.3 c
2021/2/14
17
数据流命名3
父图与子图的平衡
2021/2/14
7
2.4.1 DFD符号
2021/2/14
8
2.4.1 符号
2021/2/14
9
2.4.1 符号
•箭头表示数据流的流动方向 •程序流程图箭头表示控制流 •应该描绘所有可能的数据流向 •不能描绘出现某个数据流的条件 •忽略出错处理，打开或关闭文件之类的 内务处理。
•是描绘“做什么”而不考虑“怎样做” 。
(2) 名字应该反映整个处理的功能，而不 是它的一部分功能。
(3) 名字最好是“及物动词+宾语”结构 。应该尽量避免使用“加工”、“处 理”等。
2021/2/14
15
处理的命名2 2.4.3 命名
(4) 如果必须用两个动词才能描述整个处 理的功能，则可能需要再分解。
(5) 如果某个处理不好命名，应考虑重新 分解。
”之类)。
2021/2/14
13
数据流命名2
2.4.3 命名
• 为数据流(或数据存储)命名
(4) 如果命名有困难，则很可能是因为对 数据流图分解不恰当，试试重新分解 。
(5) 每个加工至少有一个输入数据流和一 个输出数据流。
2021/2/14
14
处理的命名1 2.4.3 命名
• 为处理命名
(1) 通常先为数据流命名，然后再为与之 相关联的处理命名。
(3) 提高可理解性：加工功能相对独立，减少 数据流的数目。
2021/2/14
19
DFD案例 储蓄系统数据流图
• 一个储蓄系统，完成以下功能：
– 储户存款
• 根据存款单检查帐户信息，如果是新开户，则添 加此储户信息，并更新帐户；否则更新储户的帐 户信息
– 储户取款
• 检查取款单，如果是合法用户，更新帐户信息。
• 从三方面进行分析:
– 技术可行性 – 经济可行性 – 操作可行性
• 任务:对以后的行动方针提出建议。
2021/2/14
2
2.2 可行性研究过程
•复查系统规模和目标 •研究目前正在使用的系统 •导出新系统的高层逻辑模型 •进一步定义问题 •导出和评价供选择的解法 •推荐行动方针 •草拟开发计划 •书写文档提交审查