软件工程课件11
合集下载
第11章软件工程管理.pptx

数据库规模
0.94 - 1.16
0.94
产品复杂度
0.70 - 1.65
1.30
对程序执行时间的约束
1.00 - 1.66
1.11
对程序占用存储容量的约束
1.00 - 1.56
1.06
开发环境的变动
0.87 - 1.30
1.00
开发环境的响应时间
0.87 - 1.15
1.00
分析员水平 程序员水平 对应用领域的熟悉程度 对开发环境的熟悉程度 对所用语言的熟悉程度
SYSTEM DESIGN
PROGRAM DESIGN
PROGRAM IMPLEMENTATION
UNIT TESTING
(3)估计各个任务单元的成本;
(4)汇合成项目总成本。
●由底向上成本估计的缺点是:具体工作人员往往只
注意到自己范围内的工作,对涉及全局的花费可能估
计不足,可能使成本估计偏低。
3. 算法模型估计
●算法模型就是资源模型,要选择适用的模型。
●算法模型估计法常与自顶向下估计或由底向上估计
结合使用。
软件工程
12
11.4 人员的分配与组织
●各个开发阶段需要的人力并不相同。一
般地说, 计划与分析阶段只需要很少的人;
概要设计的人多一些; 详细设计的人又多
一些; 编码和测试阶段的人数最多; 在运
行初期, 需要较多的人参加维护, 但很快
就可以减少下来, 只需保留很少的维护人
员就可以满足需要。
软件工程
13
1. Rayleigh-Norden 曲线
第十一章 软件工程管理 Chapter 11 Software Engineering Management
《软件工程》教学课件 第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) 代码重用 源代码剪贴:最原始的重用形式。 复制或修改原有代码时可能出错,存在严重的配臵 管理问题,人们几乎无法跟踪原始代码块多次修改 重用的过程。 源代码包含:许多程序设计语言都提供包含库中 源代码的机制。配臵管理问题有所缓解,修改了库 中源代码之后,所有包含它的程序自然都必须重新 编译。 继承:利用继承机制重用类库中的类时,无须修 改已有的代码,就可以扩充或具体化在库中找出的 类,基本上不存在配臵管理问题。
软件工程课件(全)

03
识别项目中的关键路径,确保项目按计划进 行
04
及时调整项目计划,应对项目变更和不确定 性
风险管理策略制定
识别项目中的潜在风险, 包括技术风险、市场风险、 资源风险等
制定相应的风险应对策略 和措施,如风险规避、减 轻、转移和接受等
评估风险的概率和影响程 度,制定风险优先级列表
监控风险状态,及时调整 风险管理计划
质量改进
根据质量评估结果,制定相应的改进措施, 如优化性能、增强安全性等。
经验教训总结
对测试过程中遇到的问题进行总结,形成经 验教训,为后续项目提供参考。
06
项目管理与团队协作
项目计划制定与监控
01 制定详细的项目计划,包括项目目标、范围 、时间表、资源需求、成本估算等
02 设立项目里程碑,对项目进度进行阶段性监 控
开发方向。
持续集成和测试
03
迭代增量模型强调持续集成和测试的重要性,以确保每个迭代
周期都能交付高质量的软件产品。
03
需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领 域专家等进行沟通,收集原始
需求。
需求分类
将收集到的需求按照功能、性 能、安全、易用性等方面进行 分类。
需求筛选
去除重复、模糊、不切实际的 需求,确保需求的准确性和可 行性。
处理变更请求
根据实际情况,决定是否接受变更请求,并 制定相应的实施计划。
跟踪和验证变更
对实施的变更进行跟踪和验证,确保变更的 正确性和完整性。
04
系统设计与实现
系统架构设计
分层架构
将系统划分为表示层、业务逻辑层和数据访问层,实现高内聚、 低耦合的设计。
软件工程_课件

需求分析是一项重要的工作,也是困难的工作。该阶 段是用户与软件人员双方讨论协商的阶段,由用户提出问 题,软件开发人员给出问题的解答。用户的业务活动和业 务环境对软件开发人员来说是不熟悉的,要想在短期内搞 清楚是不太可能的;用户只熟悉本身的业务活动和业务环 境,不熟悉计算机技术。由于这两方面人员缺乏共同的语 言,开发人员往往急于求成,于是在未明确软件系统应该 “做什么”的情况下,就开始进行设计、编程,而用户则 不清楚软件人员在设计怎样的一个系统,直至系统完成交 付用户之后,才发现它不符合要求,但这为时已晚,这类 教训国内外都不少见。用户与开发人员无共同语言,很难 进行交流,这是需求分析阶段的特点之一。
在性能描述中说明系统应达到的性能和应该满足 的条件,以及测试的方法和标准,预期的软件响应和 可能需要考虑的特殊问题。
参考文献目录中应包括与该软件有关的全部参考 文献,其中包括前期的其它文档、技术参考资料、产 品目录手册以及标准等。
附录部分包括一些补充资料,如列表数据、算法 的详细说明、框图、图表和其它材料。
2) 推荐方案 根据可行性研究结果要做出的决定是:是否继续
按预定目标进行开发。可行性分析人员必须清楚地表 明他对这个关键性决定的建议。如果认为值得继续进 行这项开发工程,则应提供一种最好的解决方案,并 说明理由。
3) 软件开发计划 分析人员应该为推荐的系统草拟一份软件开发计
划。软件开发计划是根据用户提出的功能性要求,开 发时间和费用的限制而制定的,它要说明该项目需要 的硬件资源和软件资源,需要的开发人员的层次和数 量,项目开发费用的估算,开发进度的安排等。
计划期 开发期 运行期
问题定义 项目说明
可行性研究 可行性分析报告
需求分析 需求说明书
设计 设计说明书
《软件工程全》课件

软件质量的标准
软件质量的标准包括ISO 9126、 McCall等,它们从不同角度对软 件质量进行了描述和评价。
单元测试
单元测试的概念
单元测试是对软件中的最小可测试单 元进行检查和验证。在面向对象编程 中,单元测试通常是对类的方法进行 测试。
单元测试的方法
单元测试的方法包括白盒测试和黑盒 测试。白盒测试需要了解内部实现细 节,而黑盒测试只需要关注输入和输 出结果。
软件工程的定义
详细描述
软件工程是一门研究软件开发和维护的学科,它采用工程化的方法和技术,将 系统化的开发过程、先进的开发技术和高效的开发管理结合起来,以高效地开 发高质量的软件产品。
软件工程的历史与发展
总结词:软件工程的历史与发展
详细描述:软件工程的历史可以追溯到20世纪60年代 。最初,软件开发主要依靠程序员的手动编程,随着软 件规模的扩大和复杂性的增加,软件开发过程中的问题 逐渐显现。为了解决这些问题,软件工程的概念和方法 逐渐形成和发展。随着时间的推移,软件工程不断演进 和完善,形成了许多经典的软件开发模型和方法论,如 瀑布模型、螺旋模型、迭代模型等。同时,随着技术的 不断发展,软件工程也在不断引入新的技术和方法,如 敏捷开发、持续集成和持续交付等。
系统测试与验收测试
系统测试的概念
系统测试是对整个系统的功能、性能 和其他方面进行全面的测试,以确保 系统能够满足用户需求。
验收测试的概念
验收测试是用户对系统的最终验收过 程,其目的是确认系统是否符合合同 或需求规格说明中的要求。
PART 06
软件维护与演化
软件维护的定义与分类
定义
软件维护是在软件运行过程中,为了改正错误、满足新的需求、改进性能等目的,对软件进行的修改和调整。
软件质量的标准包括ISO 9126、 McCall等,它们从不同角度对软 件质量进行了描述和评价。
单元测试
单元测试的概念
单元测试是对软件中的最小可测试单 元进行检查和验证。在面向对象编程 中,单元测试通常是对类的方法进行 测试。
单元测试的方法
单元测试的方法包括白盒测试和黑盒 测试。白盒测试需要了解内部实现细 节,而黑盒测试只需要关注输入和输 出结果。
软件工程的定义
详细描述
软件工程是一门研究软件开发和维护的学科,它采用工程化的方法和技术,将 系统化的开发过程、先进的开发技术和高效的开发管理结合起来,以高效地开 发高质量的软件产品。
软件工程的历史与发展
总结词:软件工程的历史与发展
详细描述:软件工程的历史可以追溯到20世纪60年代 。最初,软件开发主要依靠程序员的手动编程,随着软 件规模的扩大和复杂性的增加,软件开发过程中的问题 逐渐显现。为了解决这些问题,软件工程的概念和方法 逐渐形成和发展。随着时间的推移,软件工程不断演进 和完善,形成了许多经典的软件开发模型和方法论,如 瀑布模型、螺旋模型、迭代模型等。同时,随着技术的 不断发展,软件工程也在不断引入新的技术和方法,如 敏捷开发、持续集成和持续交付等。
系统测试与验收测试
系统测试的概念
系统测试是对整个系统的功能、性能 和其他方面进行全面的测试,以确保 系统能够满足用户需求。
验收测试的概念
验收测试是用户对系统的最终验收过 程,其目的是确认系统是否符合合同 或需求规格说明中的要求。
PART 06
软件维护与演化
软件维护的定义与分类
定义
软件维护是在软件运行过程中,为了改正错误、满足新的需求、改进性能等目的,对软件进行的修改和调整。
太原理工大学软件工程第十一章PPT课件
2020/7/19
第11面向对象的设计与实现
第18页
11.2.1 问题域子系统设计
(1)为复用设计与编程的类而增加结构
如果OOA识别和定义的类是本次开发中新定义的,那就需要 进行从头开始设计。如果已存在一些可复用的类,而且这 些类既有分析、设计时的定义,又有源程序,那么复用这 些类即可提高开发效率与质量。注意可复用的类可能只是 与OOA模型中的类相似,而不是完全相同,因此需对其进 行修改。设计目标是尽可能使复用成分增多,新开发的成 分减少。
2020/7/19
第11面向对象的设计与实现
第12页
11.1.2 启发式规则
(3)减少消息模式的数目:如果已有标准的消息协议,涉 及人员应该遵守这些协议。如果确需自己建立消息协议,则 应该尽量减少消息模式的数目,只要可能,就使消息具有一 致的模式,以利于读者理解。 (4)避免模糊的定义:一个类的用途应该是有限的,而且 应该从类名可以较容易地推导出它的用途。
重要措施。保障设计结果清晰易懂的主要因素如下。 (1)用词一致:设计中应该使名字与它所代表的事物一致,而且
应该尽量使用人们习惯的名字。不同类中相似服务的名字应该 相同。 (2)使用已有的协议:如果开发同一软件的其他设计人员已经建 立了类的协议,或者在所使用的类库中已有相应的协议,则应 该使用这些已有的协议。
2020/7/19
第11面向对象的设计与实现
第22页
11.2.1 问题域子系统设计
(5)对复杂关联的转化并决定关联的实现方式。 【例11.3】 把多对多关联转化为一对多关联,参见图11.4。
2020/7/19
第11面向对象的设计与实现
第23页
11.2.1 问题域子系统设计
【例11.4】 把多元关联转化为二元关联,参见图11.5。
软件工程 第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 软件工程人员组织
2024年度软件工程ppt课件完整版
2024/3/24
40
遗留系统现代化改造
遗留系统分析
分析遗留系统的结构、功能和性能等问题。
现代化改造策略
制定针对遗留系统的现代化改造策略,如重 构、替换或集成等。
改造实施与测试
实施改造策略,并对改造后的系统进行测试 以确保其正确性。
2024/3/24
版本迁移与数据迁移
将旧版本的数据迁移到新版本,确保数据的 完整性和一致性。
。
评审测试用例
组织相关人员对测试用例进行 评审,确保测试用例的准确性
和完整性。
执行测试用例
按照测试用例的步骤和预期结 果,执行测试用例并记录测试
结果。
缺陷管理
对发现的缺陷进行记录、跟踪 和修复,确保软件质量。
2024/3/24
25
缺陷跟踪与修复
缺陷记录
详细记录缺陷的描述、重现步 骤、严重程度等信息。
同时引入了风险管理机制。
螺旋模型的主要阶段包括:制 定计划、风险分析、工程实施
和客户评估。
2024/3/24
螺旋模型的优点在于其强调风 险分析和迭代开发,能够及时 发现并解决问题,降低项目风 险。
螺旋模型的缺点在于其需要较 高的项目管理能力和技术水平 ,且可能因为过度关注风险而 忽略其他重要因素。
11
控。
2024/3/24
评估变更影响
对变更请求进行评估, 分析变更对系统范围、 进度和成本等方面的影
响。
处理变更请求
根据评估结果决定是否 接受变更请求,并与相
关干系人进行沟通。
17
更新文档和计划
将批准的变更请求更新 到需求规格说明书中, 并调整项目计划和资源
安排。
04 系统设计与实现
《软件工程》课件第11章 面向对象的OMT方法
分析的目的是确定一个系统“干什么”的模型,该模 型通过使用对象、关联、动态控制流和功能变换等来描述。 分析过程是一个不断获取需求及不断与用户磋商的过程。
1. 问题陈述 问题陈述为记下或获取对问题的初步描述。
第11章 面向对象的OMT方法
2. 构造对象模型 构造对象模型的步骤如下: (1) 确定对象类。 (2) 编制类、属性及关联描述的数据词典。 (3) 在类之间加入关联。 (4) 给对象和链加属性。 (5) 使用继承构造和简化对象类。 (6) 将类组合成模块,这种组合在紧耦合和相关 功能上进行。 最后得到:对象模型=对象模型图+数据词典。
第11章 面向对象的OMT方法
两个类之间的关联称为二元关联,三个类之间的 关联称为三元关联。关联的表示是在类之间画一连线。 图11.3表示了二元关联,图11.4表示一种三元关联, 说明程序员使用计算机语言来开发项目。
第11章 面向对象的OMT方法 图11.3 二元关联
第11章 面向对象的OMT方法 图11.4 三元关联
第11章 面向对象的OMT方法
操作的表示如图11.2底部区域所示,操作名后可跟 参数表,用括号括起来,每个参数之间用逗号分开,参 数名后可跟类型,用冒号与参数名分开,参数表后面用 冒号来分隔结果类型,结果类型不能省略。
2. 关联和链 关联和链是建立对象及类之间关系的一种手段。 1) 关联和链的含义 链表示对象间的物理与概念的联结,如张三为通 达公司工作。关联表示类之间的一种关系,就是一些可 能的链的集合。 正如对象与类的关系一样,对象是类的实例,类是 对象的抽象。而链是关联的实例,关联是链的抽象。
第11章 面向对象的OMT方法
3. 构造动态模型 构造动态模型的步骤如下: (1) 准备典型交互序列的脚本。 (2) 确定对象间的事件并为各脚本安排事件跟踪。 (3) 准备系统的事件流图。 (4) 开发具有重要动态行为的各个类的状态图。 (5) 检查状态图中共享事件的一致性和完整性。 最后得到:动态模型 = 状态图 + 全局事件流图。
1. 问题陈述 问题陈述为记下或获取对问题的初步描述。
第11章 面向对象的OMT方法
2. 构造对象模型 构造对象模型的步骤如下: (1) 确定对象类。 (2) 编制类、属性及关联描述的数据词典。 (3) 在类之间加入关联。 (4) 给对象和链加属性。 (5) 使用继承构造和简化对象类。 (6) 将类组合成模块,这种组合在紧耦合和相关 功能上进行。 最后得到:对象模型=对象模型图+数据词典。
第11章 面向对象的OMT方法
两个类之间的关联称为二元关联,三个类之间的 关联称为三元关联。关联的表示是在类之间画一连线。 图11.3表示了二元关联,图11.4表示一种三元关联, 说明程序员使用计算机语言来开发项目。
第11章 面向对象的OMT方法 图11.3 二元关联
第11章 面向对象的OMT方法 图11.4 三元关联
第11章 面向对象的OMT方法
操作的表示如图11.2底部区域所示,操作名后可跟 参数表,用括号括起来,每个参数之间用逗号分开,参 数名后可跟类型,用冒号与参数名分开,参数表后面用 冒号来分隔结果类型,结果类型不能省略。
2. 关联和链 关联和链是建立对象及类之间关系的一种手段。 1) 关联和链的含义 链表示对象间的物理与概念的联结,如张三为通 达公司工作。关联表示类之间的一种关系,就是一些可 能的链的集合。 正如对象与类的关系一样,对象是类的实例,类是 对象的抽象。而链是关联的实例,关联是链的抽象。
第11章 面向对象的OMT方法
3. 构造动态模型 构造动态模型的步骤如下: (1) 准备典型交互序列的脚本。 (2) 确定对象间的事件并为各脚本安排事件跟踪。 (3) 准备系统的事件流图。 (4) 开发具有重要动态行为的各个类的状态图。 (5) 检查状态图中共享事件的一致性和完整性。 最后得到:动态模型 = 状态图 + 全局事件流图。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件工程
23
Fig u re 1 2 .2 Sw imlan e d iag ram fo r p rescrip t io n refill fu n ct io n
Байду номын сангаас
软件工程
10
工作环境分析
软件系统(用户界面)的使用环境直接影响界面 的设计。 光线强度(界面亮度亮些) 噪音(不考虑在界面操作中使用声音提示) 键盘、鼠标等使用限制(全力支持可行的设备操 作,忽略受限制设备操作) ……
2
置用户于控制之下
以不强迫用户进入不必要的或不希望的动作的方式来定义 交互模式; 提供灵活的交互; 允许用户交互被中断和撤销; 当技能级别增长时可以使交互流线化并允许定制交互; 使用户与内部技术细节隔离开来; 设计应允许用户与出现在屏幕上的对象直接交互。
软件工程
3
减少用户的记忆负担
减少对短期记忆的要求; 建立有意义的缺省; 定义直观的快捷方式; 界面的视觉布局应该基于真实世界的象征; 以不断进展的方式揭示信息
软件工程
4
保持界面一致
允许用户将当前任务放入有意义的环境中; 在应用系统家族内保持一致性; 如果过去的交互模型已经建立起了用户期望,除 非有不得已的理由,否则不要改变它。
r e ce iv e s t im e / d at e t o p ick u p
none
p icks u p p r e scr ip t io n
f ills p r e scr ip t io n
r e ce iv e s r e q u e st t o co n t act p h y sician
软件工程
11
界面设计步骤
使用界面分析中获得的信息,定义界面对象和行 为; 定义那些导致用户界面状态发生变化的事件; 描述每一个界面状态,就像最终用户实际看到的 那样; 简要说明用户如何从界面提供的界面信息来解释 系统状态。
软件工程
12
界面设计模式
界面设计模式可用于: 完整用户界面 页面布局 表格和输入 表 直接数据操作 导航 搜索 页面元素 电子商务
软件工程
5
用户界面的分析与设计
1. 2. 3. 4.
用户界面分析和设计需要建立4种模型: 用户模型 设计模型 心理模型 实现模型
软件工程
6
用户界面分析和设计过程
1. 2.
3.
4.
用户界面分析和设计的过程包括4个活动: 用户、任务和环境分析 界面设计 界面构造 界面确认
软件工程
7
界面分析
其他用户界面的设计原则
• 界面美观性
– 界面美观性是视觉上的吸引力,主要体现在具有 平衡和对称性、合适的色彩、各元素具有合理的 对齐方式和间隔、相关元素适当分组、使用户可 以方便地找到要操作的元素等。
软件工程
16
界面中的颜色
• 颜色能够改善用户界面,帮助用户理解系统的复杂信息结 构,有时颜色可以用于突出显示例外事件。
界面分析包括用户分析、任务分析、工作环境分 析。 用户分析目标:使得用户想象和设计模型尽可能 接近。 手段:努力了解用户。 途径:用户访谈、零售输入、市场输入、支持输 入。
软件工程
8
任务分析和建模
用户目的是通过界面来完成一个或多个任务。 回答如下问题 … 在指定环境下用户将完成什么工作? 当用户工作时将完成什么任务和子任务? 在工作中用户将处理什么特殊的问题域对象? 工作任务的顺序(工作流程)如何? 任务的层次关系如何?
no ref ills remaining ref ills remaining
ch e cks p at ie n t r e co r d s
approv es ref ill
ch e cks in v e n t o r y f o r r e f ill o r alt e r n at iv e
ref ill not allowed
e v alu at e s alt e r n at iv e m e d icat io n r e ce iv e s o u t o f st o ck n o t if icat io n
out of st ock alt ernat iv e av ailable in st ock
用例 定义基本任务、对象、工作流 任务细化 精化这些任务 对象细化 明确接口对象 (类) 工作流分析 定义当有大量角色使用界面时,一个工作过程如何完成
软件工程
9
泳道图例子
p at ien t p h armacist p h ysician
r e q u e st s t h at a p r e scr ip t io n b e r e f ille d d e t e r m in e s st at u s o f p r e scr ip t io n
• 使用颜色的指导原则 – 避免使用太多的颜色(通常一个窗口内不要多于三种颜色) – 使用颜色编码支持用户的任务 – 允许用户控制颜色编码 – 使用颜色编码时需要前后一致 – 使用颜色的变化显示系统状态的变化 – 注意在低分辨率情况下的颜色显示 – 注意颜色的搭配 软件工程 17
界面中的颜色
软件工程
软件工程
13
设计问题
主要: 系统响应时间 帮助设施 错误处理 菜单和命令标记 次要: 应用的可访问性 国际化
软件工程
14
其他用户界面的设计原则
• 界面容错性 – 一个好的界面应该以一种宽容的态度允许用户进行实验和 出错,用户在出现错误时能够方便地从错误中恢复。 • 界面可适应性 – 界面可适应性是指用户界面应该根据用户的个性要求及其 对界面的熟知程度而改变,即满足定制化和个性化的要求。 – 所谓定制化是在程序中声明用户的熟知程度,用户界面可 以根据熟知程度改变外观和行为; – 所谓个性化是使用户按照自己的习惯和爱好来设置用户界 面元素。 软件工程 15
软件工程
第十一章 完成用户界面设计
11.1 黄金规则 11.2 用户界面的分析与设计 11.3 界面分析 11.4 界面设计步骤 11.5 设计评估
软件工程
1
黄金规则
Theo Mandel在其关于界面设计的著作中提出三条 黄金规则: 置用户于控制之下 减少用户的记忆负担 保持界面一致
软件工程
软件工程
21
课堂讨论问题
设计一个mini-library系统的泳道图,里面包括读 者、管理员两种角色,该图应能表现出读者注册、 管理员认证、读者借阅,如果读者想借阅的图书 没有,还可以向管理员发起购置请求等流程。
软件工程
22
课后作业
进行用户界面设计时需要了解哪些环境?P227 怎样知道用户希望从用户界面上得到什么?P228
18
信息表示
• 信息的表示方式主要包括文本方式和图形方式 – 文本方式占据较少的屏幕空间 – 图形方式所显示的内容比较直观 • 举例 – 某系统需要显示库存商品的名称、规格、单价、数量等信 息,应该选择哪一种方式表示信息? – 某系统需要按月汇总某个商品的销售情况,应该选择哪一 种方式表示信息? – 某系统需要监控一个设备的压力和温度,应该选择哪一种 方式表示信息?
软件工程
19
用户界面评价
软件工程
20
用户界面评价
一般情况下,应该基于可用性属性进行界面的评价。
属性 可学习性 操作速度 鲁棒性 可恢复性 适应性 说明 一个新用户需要多长时间才能成为熟练用户? 系统响应用户工作情况的匹配速度如何? 系统对用户错误的容忍程度如何? 系统从用户错误中的恢复能力如何? 系统与单一工作模式的紧密程度如何?