软件工程课件第十一章
合集下载
软件工程第十一章面向对象设计
THANKS
感谢观看
01
抽象类是一种不能被实例化的 类,它只能被其他类继承。
02
抽象类可以包含抽象方法和具 体方法。抽象方法是没有具体 实现的方法,需要在继承抽象 类的子类中实现。
03
通过继承抽象类,子类可以继 承抽象类的属性和方法,并且 可以重写或实现抽象类中的方 法。
接口与抽象类的选择
在设计软件时,选择使用接口还是抽象类取决于具体需求和设计目标。
关系
关系描述了对象之间的交互和联系。 常见的关系包括关联、聚合和继承。
继承与多态的设计
继承
继承是一种实现代码重用的方式,子类可以继承父类的属性和方法,并可以扩展或覆盖它们。通过继承,可以建 立类之间的层次结构,使得代码更加清晰和易于维护。
多态
多态是指一个接口可以有多种实现方式,或者一个对象可以有多种形态。多态可以提高代码的灵活性和可扩展性, 使得程序更加易于维护和修改。
02
类与对象的设计
类的定义与属性
类的定义
类是对象的抽象,它描述了一组具有相同属性和行为的对象。类定义了对象的结构、行为和关系。
属性
属性是类中用于描述对象状态的变量。每个对象都有其自己的属性值,这些属性值决定了对象的状态 。
对象的行为与关系
行为
行为是类中定义的方法,用于描述对 象可以执行的操作。方法定义了对象 的行为和功能。
高层模块不应该依赖于低层模块,它们都应 该依赖于抽象。
面向对象设计的优势
提高代码可重用性
通过类和继承实现代码重用,减少重 复代码。
提高代码可维护性
面向对象设计使得代码结构更加清晰, 易于理解和维护。
提高开发效率
通过快速原型开发,快速构建软件系 统。
《软件工程》教学课件 第11章 软件项目管理
式为组织型、半独立型或嵌入型。
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 , 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4(KLOG)1.05 MM=3.0(KLOG)1.12 MM=3.6(KLOG)1.20
进度 TDEV=10.5(MM)0.38 TDEV=10.5(MM)0.35 TDEV=10.5(MM)0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数,乘以根据经验推算的每行源代 码所需成本,即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部(FSD)负责的60个项目的数据,利用最小二 乘法拟合,得到如下估算公式:
PERT(Program evaluation & review technique)计 划评审技术或CPM(Critical path method)关键路径法, 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间,数字结点为任务的起点和终点。
70
任务
月份 1 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图(Gantt Chart)
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 , 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4(KLOG)1.05 MM=3.0(KLOG)1.12 MM=3.6(KLOG)1.20
进度 TDEV=10.5(MM)0.38 TDEV=10.5(MM)0.35 TDEV=10.5(MM)0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数,乘以根据经验推算的每行源代 码所需成本,即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部(FSD)负责的60个项目的数据,利用最小二 乘法拟合,得到如下估算公式:
PERT(Program evaluation & review technique)计 划评审技术或CPM(Critical path method)关键路径法, 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间,数字结点为任务的起点和终点。
70
任务
月份 1 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图(Gantt Chart)
软件工程导论第11章
22
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口, 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的,这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时,应该在根类(或适当的基类)中, 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法,则应该把它当作扩充接口。扩充接口与转换接口不同,并 不需要强迫用户在派生类中重新定义它们,相反,如果在派生类中没 有给出扩充接口的新算法,则将继承父类中的算法。当用C++语言实现 时,在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合:指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中,对象是最基本的模块,因此, 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类: (1) 交互耦合: 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散,应遵守下述准则: 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数,降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反,应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类,构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务,从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴:最原始的重用形式。 复制或修改原有代码时可能出错,存在严重的配臵 管理问题,人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含:许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解,修改了库 中源代码之后,所有包含它的程序自然都必须重新 编译。 继承:利用继承机制重用类库中的类时,无须修 改已有的代码,就可以扩充或具体化在库中找出的 类,基本上不存在配臵管理问题。
【还可以把适配接口再进一步细分为转换接口和扩充接口。转换接口, 是为了克服与表示方法、数据结构或硬件特点相关的操作给重用带来 的困难而设计的,这类接口是每个类构件在重用时都必须重新定义的 服务的集合。当使用C++语言编程时,应该在根类(或适当的基类)中, 把属于转换接口的服务定义为纯虚函数。如果某个服务有多种可能的 实现算法,则应该把它当作扩充接口。扩充接口与转换接口不同,并 不需要强迫用户在派生类中重新定义它们,相反,如果在派生类中没 有给出扩充接口的新算法,则将继承父类中的算法。当用C++语言实现 时,在基类中把这类服务定义为普通的虚函数。】
4. 弱耦合 耦合:指一个软件结构内不同模块之间互连的紧 密程度。 在面向对象方法中,对象是最基本的模块,因此, 耦合主要指不同对象之间相互关联的紧密程度。 弱耦合是优秀设计的一个重要标准。
5
对象之间的耦合分为两大类: (1) 交互耦合: 对象之间的耦合通过消息连接来实现。 使交互耦合尽可能松散,应遵守下述准则: 尽量降低消息连接的复杂程度。 应该尽量减少消息中包含的参数个数,降低参数的复 杂程度。 减少对象发送(或接收)的消息数。 (2) 继承耦合 与交互耦合相反,应该提高继承耦合程度。 通过继承关系结合起来的基类和派生类,构成系统中 粒度更大的模块。设计时应该使特殊类尽量多继承并 使用其一般化类的属性和服务,从而更紧密地耦合到 其一般化类。
13
2. 软件成分的重用级别 (1) 代码重用 源代码剪贴:最原始的重用形式。 复制或修改原有代码时可能出错,存在严重的配臵 管理问题,人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含:许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解,修改了库 中源代码之后,所有包含它的程序自然都必须重新 编译。 继承:利用继承机制重用类库中的类时,无须修 改已有的代码,就可以扩充或具体化在库中找出的 类,基本上不存在配臵管理问题。
第11章软件工程课件
第11章软件工程课件
• 选择程序设计语言的关键因素,是语言的一致的表达能力、 可重用性及可维护性。面向对象语言刻画客观系统较为自然,它 具有:
• ① 识认性,系统中的基本构件可识认为一组可识别的离散 对象;
• ② 类别性,系统具有相同数据结构与行为的所有对象可组 成一类;
• ③ 多态性,对象具有惟一的静态类型和多个可能的动态类 型;
第11章软件工程课件
• 我们仍以“自动饮料售货机”为例,说明可重用性对于提 高软件产品的质量和软件开发效率意义重大。假设该“自动饮 料售货机”可提供汽水、洛神、红茶、可乐、奶昔等五种饮料, 有关这五种饮料所实施的操作是相同的,因此,可以构造一个 饮料类,然后由该类构造汽水、洛神、红茶、可乐、奶昔等五 种不同的对象。这对于提高软件开发质量和软件开发效率具有 重要的意义。
第11章软件工程课件
•11.1.2 面向对象语言的技术特点
• 面向对象语言借鉴了20世纪50年代诞生的人工智能语言LISP, 引入了动态绑定的概念和交互式开发环境的思想;始于20世纪60 年代的离散事件模拟语言SIMULA 67,引入了类的概念和继承机 制;形成于20世纪70年代的Smalltalk语言。面向对象语言发展有 两大方向,一是纯面向对象的语言,如 Smalltalk、EIFFEL、Java 等语言;另一类是混合型面向对象语言,也就是在过程语言或其 他语言中增加了类、继承等面向对象机制,如C++、Objective_C 等语言。就两种形式的面向对象语言比较而言,纯面向对象语言 更加适合面向对象方法研究和快速原型的实现;而混合型面向对 象语言则更加注重于提高系统的运行速度,使传统使用结构化编 程方式的程序员容易接受面向对象思想。
第11章软件工程课件
• 选择程序设计语言的关键因素,是语言的一致的表达能力、 可重用性及可维护性。面向对象语言刻画客观系统较为自然,它 具有:
• ① 识认性,系统中的基本构件可识认为一组可识别的离散 对象;
• ② 类别性,系统具有相同数据结构与行为的所有对象可组 成一类;
• ③ 多态性,对象具有惟一的静态类型和多个可能的动态类 型;
第11章软件工程课件
• 我们仍以“自动饮料售货机”为例,说明可重用性对于提 高软件产品的质量和软件开发效率意义重大。假设该“自动饮 料售货机”可提供汽水、洛神、红茶、可乐、奶昔等五种饮料, 有关这五种饮料所实施的操作是相同的,因此,可以构造一个 饮料类,然后由该类构造汽水、洛神、红茶、可乐、奶昔等五 种不同的对象。这对于提高软件开发质量和软件开发效率具有 重要的意义。
第11章软件工程课件
•11.1.2 面向对象语言的技术特点
• 面向对象语言借鉴了20世纪50年代诞生的人工智能语言LISP, 引入了动态绑定的概念和交互式开发环境的思想;始于20世纪60 年代的离散事件模拟语言SIMULA 67,引入了类的概念和继承机 制;形成于20世纪70年代的Smalltalk语言。面向对象语言发展有 两大方向,一是纯面向对象的语言,如 Smalltalk、EIFFEL、Java 等语言;另一类是混合型面向对象语言,也就是在过程语言或其 他语言中增加了类、继承等面向对象机制,如C++、Objective_C 等语言。就两种形式的面向对象语言比较而言,纯面向对象语言 更加适合面向对象方法研究和快速原型的实现;而混合型面向对 象语言则更加注重于提高系统的运行速度,使传统使用结构化编 程方式的程序员容易接受面向对象思想。
第11章软件工程课件
软件工程(第二版)第十一章new
类名
属性 服务
类名 属性 服务
11.1 表示符号
11.2 面向对象建模——三模 型法求分析(对象模型)
11.2.2 表示结构的图形符号
1.归纳关系 一般化关系的形成,可以通过检查一组 概念和识别这组概念中的共同元素来实现。 小汽车、卡车和公共汽车可以蕴含在更一般 的汽车概念中。这个较一般化的抽象还可以 帮助定义其他比较特殊的抽象,如赛车、面 包车和牵引车。
11.3 面向对象建模——三模 2、标识消息传递 型需求分析(动态模型)
11.4 面向对象建模——三模 型需求分析(功能模型)
功能模型着重于系统内部数据的传送和处理。功能模 型定义“做什么”,通常,功能模型由一组数据流图 组成。功能模型表明整个的数据流动情况,从外部输 入,通过操作和内部存储,直到外部输出。功能模型 还包括了对象模型内部数据间的限制。
项目
活动
﹡
工作成果
﹡由„产生 “) 《
任务
﹡
消耗﹡
资源
系统
参与者
模型 文档
时间 设备
(2)对象之间的消息传递构成静态结构视点。
11.5 UML概述
在 UML 中可以将建模语言划分为三种构 造块,即三类词汇或基本元素:事物、关 系和图。其中事物是对模型中最具有代表 性的成分的抽象,可分为结构事物、行为 事物、分组事物和注释事物;关系能把事 物联系在一起,可分为依赖、关联、泛化 (归纳)、实现。
功能模型中所有的数据流图往往形成一个层次 结构。在这个层次结构中,一个数据流图中的过 程可以由下一层的数据流图做进一步的说明。— 般来讲,高层的过程相应于作用在组合对象上的 操作,而低层的过程则代表作用于一个简单对象 上的操作。
11.5 UML概述
软件工程讲义_第十一章 质量概念
第十一章 质量概念
质量概念
如果软件团队在所有软件工程活动中强调 质量,就可以减少很多必需的返工,结果 是降低了成本,更为重要的是缩短了上市 时间。 为实现高质量软件,必须做4项活动:已 验证的软件过程和实践、扎实的项目管理、 全面的质量控制和具有质量保证基础设施。
质量概念
[Ric01]提到:尽管意愿良好,有缺陷的 代码仍然是软件工业的幽灵,计算机系统 的故障时间高达45%,美国公司去年花 费了大约一千亿美元,用在了丧失的生产 率和修补上,这还不包括使客户生气而失 去了这些客户的代价。
什么是质量
质量是一个复杂多面的概念。可以从5个 不同的观点来描述。玄妙观点认为质量是 马上就能识别的东西,却不能清楚地定义。 用户观点是从最终用户的具体目标来说的。 如果产品达到这些目标,就显示出质量。 制造商观点是从产品的原始规格说明的角 度来定义质量,如果产品符合规格说明, 就显示出质量。产品观点认为质量是产品 的固有属性。最后,基于价值的观点根据 客户愿意为产品支付多少钱来评测质量。
质量成本
质量成本包括追求质量过程中或在履行质 量有关的活动中引起的费用以及质量不佳 引起的下游费用等所有费用。为了解这些 费用,一个组织必须收集度量数据,为目 前的质量成本提供一个基准,找到降低这 些成本的机会,并提供一个规范化的比对 依据。质量成本可分为预防成本、评估成 本和失效成本。
质量成本
ISO 9126质量因素
功能性:软件满足已确定要求的程度,由以下子属性表 征:适合性、准确性、互操作性、依从性和安全保密性。 可靠性:软件可用的时间长度,由以下子属性表征:成 熟性、容错性和易恢复性。 易用性:软件容易使用的程度,由以下子属性表征:易 理解性、易学习性和易操作性。 效率:软件优化使用系统资源的程度,由以下子属性表 征:时间特性和资源利用特性。 维护性:软件易于修复的程度,由以下子属性表征:易 分析性、易改变性、稳定性和易测试性。 可移植性:软件可以从一个环境移植到另一个环境的容 易程度,由以下子属性表征:适应性、易安装性、符合 性和易替换性。
软件工程教学课件chapter11
处方重填功能的泳道图
13
显示内容分析
不同类型的数据是否要放置到屏幕上固定的位置(例如, 照片一般显示在右上角)? 用户能否定制内容的屏幕位置? 是否对所有的内容赋予适当的屏幕标识? 为了便于理解,应如何划分长篇报告? 对于大集合的数据,是否存在直接移动到摘要信息的机制? 输出图形的大小是否需要适合所使用显示设备的限制? 如何使用颜色来曾强理解? 出错信担
减少对短期记忆的要求。 建立有意义的缺省。 定义直观的快捷方式。 界面的视觉布局应该基于真实世界的象征。 以不断进展的方式揭示信息。 牛牛文档分享5保持界面一致
在应用系统家族内保持一致性。 如果过去的交互模型已经建立起了用户期望,除非 有不得
使用界面分析中获得的信息,定义界面对象和动 作(操作)。 定义那些导致用户界面状态发生变化的事件(用 户动作),并对行为建模。 描述每个界面状态,就像最终用户实际看到的那 样。 简要说明用户如何从界面提供的界面信息来解释 系统状态。
界面设计
Easy to learn? 易学? Easy to use? 易用?
Easy to understand? 易理解? 牛牛文档分享1界面设计
典型设计错误 缺乏一致性 太多的记忆 没有指导/帮助
新手 对系统有了解的间歇用程
界面确认 界面分析和建模
界面构造界面设计 牛牛文档分享9界面分析
界面分析意味着了解
(1) 通过界面和系统交互的人(最终用户) (2) 最终用户为完成工作要执行的任务 (3) 作为界面的一部分而显示的内容 (4) 任务处理的环境
检查库存查找新补 充的药或替换药 接到缺货通知单 接收供选择的时间/日期
软件工程 第4版 第11章 软件工程管理
本章内容
11.1 软件工程管理概述 11.2 软件开发成本估算 11.3 软件工程人员组织 11.4 软件配置管理 11.5 软件质量保证 11.6 软件开发风险管理 11.7 软件工程标准与软件工程文档
这种估算方法的优点是,由于各个任务单元的成本 可交给该任务的开发人员去估计,因此估计结果比较准 确。缺点在于,由于具体工作人员往往只注意到自己职 责范围内的工作,而对涉及全局的成本。
11.2.3 COCOMO2 模型
COCOMO2 模型分为如下3 个模型,在估算软件开发工作量时,对软件细节问题考虑的详 尽程度逐渐增加。
OPTION
软件开发人员一般分为项目负责人、系统分析员、高级程序员、程序员、初级程序员、资 料员和其他辅助人员。
项目负责人需要对项目的需求和团队人员有全面的了解
系统分析员需要有概括能力、分析能力和社交活动能力
程序员需要有熟练的编程能力等 资料员和其他辅助人员负责及时登记软件工程每个阶段的文档等资料
11.3 软件工程人员组织
11.1 软件工程管理概述
02 软件工程管理的重要性
OPTION
基于软件本身的复杂性,软件工 程将软件开发划分为若干个阶段,每 个阶段完成不同的任务、采取不同的 方法。
如果软件开发管理不善,造成的 后果会很严重。因此软件工程管理非 常重要。
11.1 软件工程管理概述
03 软件工程管理的内容
OPTION
02 组织机构
OPTION
软件开发团队不能只是一个简单的集合,要求具有良好的组织机构,要具有合理的人员分 工和有效的通信,共同高效率地完成任务。
按项目划分的模式
按职能划分的模式
矩阵型模式
11.3 软件工程人员组织
软件工程导论(第11章)
3. 信息隐蔽
在面向对象方法中,信息隐蔽通过对象的封
装性实现:类结构分离了类的接口与类的实
现,从而支持了信息隐蔽。
4. 弱耦合
弱的耦合可以提高软件模块的独立性,避免 某一部分模块发生变化对其它模块有较大的影 响。
一般来说,对象间的耦合有两大类:
A.交互耦合:对象间的耦合通过信息连接来
实现。应使交互耦合尽量松散。
2. 一般—特殊结构的深度应适当
中等规模的系统中,类等级层次数应保持 为7±2。不是必要情况,不应该随意创建派生类;
3. 设计简单的类:设计小而简单的类,便于
开发和管理;
1)避免包含过多的属性; 2)有明确的定义; 3)尽量简化对象之间的合作关系; 4)不要提供太多服务。
4. 使用简单的协议:设计简单的类接口,发送 的消息中参数要少。 5. 使用简单的服务:编写实现每一个服务时, 避免复杂的语句和结构; 6. 把设计变动减至最小。
2.
两个方向的关联都用属性实现,这种方法能 实现快速访问。
3.
用独立的关联对象实现双向关联。关联对象 不属于相互关联的任何一个类,它是独立的 关联类的实例 。
40
41
4、关联对象的实现
关联对象的实现方法取决于关联的阶数:
一对一关联:
• 关联对象可以与参与关联的任一个对象合并。
一对多关联:
• 关联对象可以与“多”端对象合并。
11.9 设计类中的服务 11.9.1 确定类中应有的服务 11.9.2 设计实现服务的方法
1. 设计实现服务的算法
1)算法复杂度;
2)容易理解、容易实现;
3)容易修改;
2. 选择数据结构 3. 定义内部类和内部操作
98489-软件工程-chapter 11
第十一章 软件的标准与软件文档
❖11.1 软件工程标准化 ❖11.2 软件文档 ❖11.3软件质量认证 ❖11.4 注释文档工具JAVADOC ❖11.5 本章小结
11.1.1 什么是软件工程标准化
❖ 为在一定的范围内获得最佳秩序,对活动或其 结果规定共同的和重复使用的规则、导则或特 性文件。该文件经协商一致制定,并经一个公 认机构的批准。标准应以科学、技术和经验的 综合成果为基础,以促进最佳社会效益为目的。
6
3级
项目开发计划 需求规格说明 概要设计说明 详细设计说明 测试计划 测试报告 项目开发总结 用户手册
8
11.2.8 几种常用标准中文档的名称 各阶段形成或使用的文档
GJB 438A-97文档名称 GJB 2115-94文档名称 HB 6465-90文档名称 HB 6466-90、HB 6467-90、 HB/Z 178-90、HB/Z179 -90文档名称 GJB 438A-97文档名称
❖ 认证之前必须做好的3件事情 ❖ 认证程序 ❖ 实施步骤
11.3.4 ISO 9000标准的构成
❖ 第一部分 核心标准 ❖1) ISO9000 ❖2) ISO9001 ❖3) ISO9004
11.3.4 ISO 9000标准的构成
❖第二部分 其它标准 ❖ISO10012 测量管理体系 ❖ISO10019 质量管理体系咨询师选择和使用指
11.2.5 软件文档的编写—软件文档的主要内容及写作指南
❖详细设计说明书 : ① 引言 ② 总体设计 ③ 程序描述 ④ 接口
11.2.5 软件文档的编写—软件文档的主要内容及写作指南
❖程序维护手册 : ① 引言 ② 系统说明 ③ 操作环境 ④ 维护过程
11.2.5 软件文档的编写—软件文档的主要内容及写作指南
❖11.1 软件工程标准化 ❖11.2 软件文档 ❖11.3软件质量认证 ❖11.4 注释文档工具JAVADOC ❖11.5 本章小结
11.1.1 什么是软件工程标准化
❖ 为在一定的范围内获得最佳秩序,对活动或其 结果规定共同的和重复使用的规则、导则或特 性文件。该文件经协商一致制定,并经一个公 认机构的批准。标准应以科学、技术和经验的 综合成果为基础,以促进最佳社会效益为目的。
6
3级
项目开发计划 需求规格说明 概要设计说明 详细设计说明 测试计划 测试报告 项目开发总结 用户手册
8
11.2.8 几种常用标准中文档的名称 各阶段形成或使用的文档
GJB 438A-97文档名称 GJB 2115-94文档名称 HB 6465-90文档名称 HB 6466-90、HB 6467-90、 HB/Z 178-90、HB/Z179 -90文档名称 GJB 438A-97文档名称
❖ 认证之前必须做好的3件事情 ❖ 认证程序 ❖ 实施步骤
11.3.4 ISO 9000标准的构成
❖ 第一部分 核心标准 ❖1) ISO9000 ❖2) ISO9001 ❖3) ISO9004
11.3.4 ISO 9000标准的构成
❖第二部分 其它标准 ❖ISO10012 测量管理体系 ❖ISO10019 质量管理体系咨询师选择和使用指
11.2.5 软件文档的编写—软件文档的主要内容及写作指南
❖详细设计说明书 : ① 引言 ② 总体设计 ③ 程序描述 ④ 接口
11.2.5 软件文档的编写—软件文档的主要内容及写作指南
❖程序维护手册 : ① 引言 ② 系统说明 ③ 操作环境 ④ 维护过程
11.2.5 软件文档的编写—软件文档的主要内容及写作指南
精品课件-软件工程与开发技术(第二版)-第11章
第11章 系统结构与包模型
元素和包之间也可以有依赖关系,如果某个元素(用例、 类、组件等)和某个包内的元素存在着关系(泛化、关联、依赖 等),则该元素和该包存在着依赖关系。如图11.3所示,业务 服务包中的类使用到了数据库访问对象DAO,DAO的实现又使 用到了Business Object。
第11章 系统结构与包模型 图11.2 包依赖关系举例
第11章 系统结构与包模型 图11.3 包依赖性举例
第11章 系统结构与包模型
在包和接口之间也可以存在实现关系,如图11.4所示。 如果包中的类实现了该接口,在这种情况下也可以画依赖关系, 但语义更弱,实现关系则特指类实现接口。
包机制也是一种封装或者隐藏机制,使用包名字来描述其 中包含的所有元素的特性,这可以起到信息隐藏的作用,但也 可以选择包内的元素(非子包元素),使其暴露出来,如图 11.5所示。
第11章 系统结构与包模型 图11.1 包的UML表示
第11章 系统结构与包模型 11.2 包之间的依赖关系
包与包之间可以存在依赖关系。如果某个包中的元素和另 外一个包中的元素存在着依赖关系,则这两个包之间存在着依 赖关系。图11.2所示是一个系统的三层结构,GUI包中包含了 所有的界面元素,使用到Business Service包中提供的业务 服务类,如订单管理类;同时也使用了Business Object包中 的业务对象,如订单;业务服务类中,订单管理类也使用到业 务对象订单类,此时这三个包就存在着依赖关系。
包中的所有类对于同一类性质的变化应该是共同封闭的。 即系统的某些变化若对一个包有影响,则将对包中的所有类产
第11章 系统结构与包模型
11.5.3 共同重用原则(CRP) 共同重用原则指的是不要把不会一起使用的类放在同一个
软件工程课件第十一章
对于一个大型的软件项目,由于项目 的复杂性,开发成本的估算不是一件 简单的事,要进行一系列的估算处理。 主要靠分解和类推。 基本估算方法分为三类。
– 自顶向下的估算方法 – 自底向上的估计法 – 差别估计法
自顶向下的估算方法
这种方法的主要思想是从项目的 整体出发,进行类推。 估算人员根据以前已完成项目所 消耗的总成本(或总工作量), 推算将要开发的软件的总成本 (或总工作量),然后按比例将 它分配到各开发任务单元中去, 再来检验它是否能满足要求。
管理的目的与内容 软件估算模型 软件成本估计 人员的分配与组织 项目进度安排
11.1 管理的目的与内容
管理的目的是为了按照预定的时间和费 用,成功地完成软件的计划、开发和 维护任务。
1、费用管理 对软件开发进行成本核算 2、质量管理 保证软件产品质量 3、进度管理 保证项目的按时完成 4、人员的组织与管理
此时,工作量计算公式改成
MM r (KDEV) fi
c i 1 15
例1. 一个 32KDSI 的声音输入系统是 一个输入原型,或是一个可行性表演 模型。所需可靠性非常低。把此模型 看做半独立型软件。则有 MM = 3.0(32)1.12 = 146 又查表知 f1=0.75,其它 fi=1.00, 则最终有MM = 146×0.75 = 110.
基本COCOMO模型
基本COCOMO模型的工作量和 进度公式
总体类型 工 作 量 组织型 MM= = 2.4(KDSI)1.05 半独立 MM= 型 = 3.0(KDSI)1.12 嵌入型 MM= = 3.6(KDSI)1.20 进 度 TDEV= = 2.5(MM)0.38 TDEV= = 2.5(MM)0.35 TDEV= = 2.5(MM)0.32
清华软件工程ppt课件第11章软件测试_1
有关软件测试的错误观点
“软件测试是为了证明程序是正确的,即测 试能发现程序中所有的错误”。事实上这 是不可能的。要通过测试发现程序中的所 有错误,就要穷举所有可能的输入数据。
对于一个输入三个16位字长的整型数据的程序, 输入数据的所有组合情况有248 3*1014,如果测试 一个数据需1ms,则即使一年365天一天24小时不停 地测试,也需要约1万年。
例:对下列子程序进行测试
procedure example(y,z:real;var x:real); begin
if (y>1) and (z=0) then x:=x/y; if (y=2) or (x>1) then x:=x+1; end; 该子程序接受x、y、z的值,并将计算 结果x的值返回给调用程序。 与该子程序对应的流程图如下:
软件测试的原则
Davis提出了一组指导软件测试的基本原则:
1.所有的测试都应可追溯到客户需求
2.应该在测试工作真正开始前的较长时间就进 行测试计划
3. Pareto原则:测试中发现的80%的错误可能 来自于20%的程序代码
4.测试应从“小规模”开始,逐步转向“大规
模”
5.穷举测试是不可能的
6.为了达到最有效的测试,应由独立的第三方
白盒测试
常用的白盒测试方法有:
• 逻辑覆盖测试 • 基本路径覆盖测试 • 数据流测试 • 循环测试
2020/11/4
软件工程
16
生活家饮食保健孕期选择食用油的学 问邢台 市第四 病院罕 见护理 应急预 案猪气 喘病综 合防制 技术动 物营养 系列理 想蛋白 与氨基 酸模式 的研究 进展皮 肤病的 诊断包 括病史 体格检 查和必 要的实 验室检 查我国 有关食 物添加 剂营养 强化剂 食物新 资本的 治理律 例与标 准
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
基本COCOMO模型
基本COCOMO模型的工作量和 进度公式
总体类型 工 作 量 组织型 MM= = 2.4(KDSI)1.05 半独立 MM= 型 = 3.0(KDSI)1.12 嵌入型 MM= = 3.6(KDSI)1.20 进 度 TDEV= = 2.5(MM)0.38 TDEV= = 2.5(MM)0.35 TDEV= = 2.5(MM)0.32
– 现成的用以支持软件开发的工具
──硬件工具及软件工具
– 最基本的资源
──人
软件开发中的资源
人 需要的技能, 有效性 开始时间, 工作期限
人 工具
硬件 开发系统, 目标机器, 新系统其他硬件部分 软件 支持软件, 实用软件
有效性,投入时间, 持续时间
通常,对每一种资源,应说明以 下四个特性: (1)资源的描述; (2)资源的有效性说明; (3)资源在何时开始需要; (4)使用资源的持续时间。 最后两个特性统称为时间窗口。
15种影响软件工作量的因素 fi
产品因素:软件可靠性、数据库规模、 产品复杂性 硬件因素:执行时间限制、存储限制、 虚拟机易变性、环境周转时间 人的因素:分析员能力、应用领域实 际经验、程序员能力、虚拟机使用经 验、程序语言使用经验 项目因素:现代程序设计技术、软件 工具的使用、开发进度限制
此时,工作量计算公式改成
MM r (KDEV) fi
c i 1 15
例1. 一个 32KDSI 的声音输入系统是 一个输入原型,或是一个可行性表演 模型。所需可靠性非常低。把此模型 看做半独立型软件。则有 MM = 3.0(32)1.12 = 146 又查表知 f1=0.75,其它 fi=1.00, 则最终有MM = 146×0.75 = 110.
基本COCOMO模型是静态单变 量模型,用源代码行数(LOC) 为 自变量的经验函数计算软件开发 工作量。
中间COCOMO模型在用LOC为自变 量的函数计算软件开发工作量(称为 名义工作量)的基础上,用涉及产品、 硬件、人员、项目等方面的影响因素 调整工作量估算。 详细COCOMO模型包括中间COCO MO模型的所有特性,但用上述各种 影响因素调整工作量估算时,还要考 虑对软件工程过程中每一步骤(分析、 设计等)的影响。
1. 人力资源
在考虑各种软件开发资源时,人 是最重要的资源。在安排开发活 动时必须考虑人员的技术水平、 专业、人数、以及在开发过程各 阶段中对各种人员的需要。 计划人员首先估算范围并选择为 完成开发工作所需要的技能。还 要在组织和专业两方面做出安排。
对于一些规模较小的项目(1个人年 或者更少),只要向专家做些咨询, 也许一个人就可以完成所有的软件 工程步骤。 对一些规模较大的项目,在整个软 件生存期中,各种人员的参与情况 是不一样的。下面是各类不同的人 员随开发工作的进展在软件工程各 个阶段的参与情况的典型曲线。
管理的目的与内容 软件估算模型 软件成本估计 人员的分配与组织 项目进度安排
11.1 管理的目的与内容
管理的目的是为了按照预定的时间和费 用,成功地完成软件的计划、开发和 维护任务。
1、费用管理 对软件开发进行成本核算 2、质量管理 保证软件产品质量 3、进度管理 保证项目的按时完成 4、人员的组织与管理
IBM模型是静态单变量模型。 在此模型中,一般指一条机器指 令为 一行源代码。 一个软件的源代码行数不包括程 序注释、作业命令、调试程序在 内。 对于非机器指令编写的源程序, 例如汇编语言或高级语言程序, 应转换成机器指令源代码行数来 考虑。
Putnam模型
Putnam模型是一种动态多变量模 型。适用于大型项目,但也可以 应用在一些较小的软件项目中。 它是假定在软件开发的整个生存 期中工作量有特定的分布。 大型软件项目的开发工作量分布 可以用Rayleigh-Norden曲线表示。
软件项目的估算
软件项目管理过程开始于项目计划。 在做项目计划时,第一项活动就是估算。 在做估算时往往存在某些不确定性,使得 软件项目管理人员无法正常进行管理而导 致产品迟迟不能完成。 现在已使用的实用技术是时间和工作量估 算。
软件开发中的资源
软件项目计划的第二个任务是对 完成该软件项目所需的资源进行 估算。 软件开发所需的资源有
中间COCOMO模型
进一步考虑15种影响软件工作量 的因素,通过定下乘法因子,修 正COCO MO工作量公式和进度 公式,可以更合理地估算软件 (各阶段)的工作量和进度。 中间COCOMO模型的名义工作量 与进度公式如下所示。
中间COCOMO模型的名义工作量 与进度公式
总体类型 工 作 量 进 度 组织型 MM= TDEV= = 3.2(KDSI)1.05 = 2.5(MM)0.38 半独立 MM= TDEV= 型 = 3.0(KDSI)1.12 = 2.5(MM)0.35 嵌入型 MM= TDEV= = 2.8(KDSI)1.20 = 2.5(MM)0.32
详细COCOMO模型
详细COCOMO模型的名义工作量公 式和进度公式与中间COCOMO模型 相同。 工作量因素分级表分层、分阶段给出。 针对每一个影响因素,按模块层、子 系统层、系统层,有三张工作量因素 分级表,供不同层次的估算使用。每 一张表中工作量因素又按开发各个不 同阶段给出。
软件开发成本估算方法
11.2 软件估算模型
数据是一切管理工作的基础。
Yourdon:“对于一个软件开发项目进 行管理的唯一有效方法,就是对开发 过程中发生的一切进行监控与度量。” T. DeMarco:“你不能管理你无法度量 的事物。不进行度量的事物是控制不 住的。” 在软件开发前只能进行估算。估算既是 科学,又是艺术。
2. 硬件资源
硬件是作为软件开发项目的一种 工具而投入的。 (1)宿主机(Host)─ 软件开发 时使用的计算机及外围设备; (2)目标机(Target)─ 运行已 开发成功软件的计算机及外围设 备; (3)其它硬件设备 ─ 专用软件 开发时需要的特殊硬件资源;
3. 软件资源 软件人员在软件开发期间使用了许 多软件工具来帮助开发。这种软件 工具集叫做计算机辅助软件工程 (CASE)。 (1)业务系统计划工具集 (2)项目管理工具集 (3)支援工具──文档生成工具、 网络系统软件、数据库、电子邮件、 通报板,以及配臵管理工具。
情 况 只用于局部地区,恢 复问题不严重 5K 使用商用微处理机 平均2小时 优秀人才 远程通信工作3年 优秀人才 微型机工作 6个月 12个月 1年以上 基本的微型机软件 9个月
取 值 1.00(正常) 0.94(低) 1.30(很高) 1.10(高) 1.06(高) 1.00(额定值) 1.00(额定值) 0.86(高) 1.10(低) 0.86(高) 1.00(正常) 1.00(正常) 0.91(高) 1.10(低) 1.00(正常)
软件 库存情况更新 开发者 W.Ward 日期 2 / 8 / 82 阶 段 项目任务 工作量分布(1/53) 小计(1/53) 5 计划和需求 软件需求定义 1 6 开发计划 6 产品设计 3 产品设计 初步的用户手册 1 10 测试计划 4 详细PDL描述 4 详细设计 数据定义 2 过程设计 2 12 正式的用户手册 6 编码与 程序编码 10 16 单元测试 单元测试结果 4 组装与 编写文档 5 9 联合测试 组装与测试 53 总 计
开发所用时间 TDEV = 2.5 (51.5)0.32 = 8.9 (月) 如果分析员与程序员的工资都按每月 6,000美元计算,则该项目的开发人 员的工资总额为 51.5×6,000 = 309,000 (美元) 做为对比,现在用IBM模型计算: PM = 5.2 (10)0.91 = 42.27 (人月) D = 4.1 (10)0.38 =9.84 (月) S = 0.54 (42.27)0.60 = 5.1 (人)
MM(度量单位为人月)表示开 发工作量。 TDEV(度量单位为月)表示开 发进度。它由工作量决定。 软件开发项目的分类 软件开发项目的总体类型:
– 组织型
– 嵌入型
– 半独立型
COCOMO模型的分类 COCOMO模型按其详细程度分 成三级:
– 基本COCOMO模型 – 中间COCOMO模型 – 详细COCOMO模型
例14. 一个规模为10KDSI的商用微机 远程通信的嵌入型软件,使用中间 COCOMO模型进行成本估算。
程序名义工作量
MM = 2.8 (10)1.20 = 44.38(MM)
程序实际工作量 MM = 44.38×
i 1 15
fi
= 44.38×1.17 = 51.5(MM)
影响工作量因素 fi 1 软件可靠性 2 3 4 5 6 7 8 9 10 11 12 13 14 15 数据库规模 产品复杂性 时间限制 存储限制 机器 周转时间 分析员能力 工作经验 程序员能力 工作经验 语言使用经验 使用现代程序设计技术 使用软件工具 工期
软件成本和工作量的估算
软件成本和工作量的估算中变化的 东西太多,人、技术、环境、政治, 都会影响软件最终成本和工作量。 软件项目的估算能够通过一系列系 统化的步骤,在可接受的风险范围 内提供估算结果。 成本估算必须“事前”给出。时间 越久,了解得越多,估算中出现的 严重误差就越少。
软件开发成本估算的经验模型
软件开发成本估算是依据开发成本 估算模型进行估算的。 开发成本估算模型通常采用经验公 式来预测软件项目计划所需要的成 本、工作量和进度数据。 用以支持大多数模型的经验数据都 是从有限的一些项目样本中得到的。
IBM模型
E = 5.2×L0.91 D = 4.1×L0.36 = 14.47×E0.35 S = 0.54×E0.6 DOC = 49×L1.01 L 是源代码行数 (KLOC),E 是 工作量 (PM),D 是项目持续时间 (月),S 是人员需要量 (人), DOC是文档数量 (页)。