@illuz
2014-06-26T07:09:17.000000Z
字数 3640
阅读 4359
软件工程个人复习用笔记
复习
个人复习用，范围确定型复习笔记，配套软件工程:实践者的研究方法
Almost complete. 补充B卷内容，补充部分标题有（补充）
1. 2.3.3 演化过程模型（螺旋模型）
风险驱动型
螺旋模型结合了原型的迭代性质和瀑布模型的系统性和可控性特点。随着演进过程的开始，从圆心开始顺势针方向，执行螺旋上的一圈表示的活动。每次演进都要考虑风险，每个演进过程都要标记里程碑。螺旋模型应用在计算机软件的整个生命周期。是开发大型系统的理想方法，可以有效的应对风险。
螺旋模型的特点：
- 可应用在计算机软件的整个生命周期
- 是开发大型系统和软件的理想方法
- 把原型开发作为降低风险的机制
优缺点：
- 优点（From 百科）
- 设计上的灵活性,可以在项目的各个阶段进行变更。
- 以小的分段来构建大型系统,使成本计算变得简单容易。
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
- 随着项目推进,客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。
- 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
- 缺点
很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
2. 2.3.3 演化过程模型（原型开发模型）
过程：
沟通 → 快速策划 → 建模快速设计 → 构建原型 → 部署交付及反馈 → 沟通...
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。
优缺点：
- 优点：
- 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
- 这种模型适合预先不能确切定义需求的软件系统的开发。
- 缺点：
- 开发者可能没有考虑整体软件质量和长期的可维护性。
- 开发者在实现过程中往往采用折中的手段。
3. 6.1.1 总体目标和原理（需求模型的主要目标）
三个主要目标：
- 描述客户需要什么
- 为软件设计奠定基础
- 定义在软件完成后可以被确认的一组需求
4. 6.3 补充用例的UML模型
开发活动图
- UML活动图在特定场景内通过提供迭代流的图形化表示来补充用例。
- 使用两端半圆的矩形、箭头、菱形表示。
泳道图
- 可以使用垂直实线将活动图划分为泳道。每条泳道代表整个工作流程的某个部分的职责，该职责由组织的某个部门来执行。
5. 8.3.7 功能独立性
- 通过开发具有“专一”功能和“避免” 与其他模块过多交互的模块，可以实现功能独立。
- 独立性定性标准评估：
- 内聚性：显示模块相关功能的强度（与其他构件的交互）
- 耦合性：显示模块间的相互依赖性（多个模块间的连接）
6. 11.2.1 用户界面分析和设计模型
要考虑四种模型：
- 工程师创建的用户模型
- 软件工程师创建的设计模型
- 最终用户对界面产生的映像，心理模型
- 系统实现后得到的实现模型
用户分类：
- 新手
- 对系统有了解的间歇性用户
- 对系统有了解的经常用户
四种模型可能相差甚远，界面设计人员的任务就是消除这些差距，导出一致的界面表示。
7. 17.1.2 软件测试的组织
- 独立测试组的作用是避免开发人员进行测试所引发的固有问题。
- 有一定程度的独立性。
8. 17.3.2 集成测试（回归测试）
- 集成测试通常采用增量方式。
- 回归测试是对已测试过的子集的重新执行，以确保对程序的改变和修改，没有传播不期望的副作用。
回归测试集（已经过测试的子集）包括三种不同类型的测试用例：
- 能测试软件所有功能的代表性测试用例
- 专门针对可能会被修改影响的软件功能的额外测试
- 注重于修改过的软件模块的测试
9. 17.7 系统测试（系统测试概念）
- 系统测试是对整个基于计算机的系统进行的一系列不同考验的测试。
- 常用的系统测试主要包括：恢复测试、安全测试、压力测试和性能测试。
10. 5.1 需求工程（需求工程的7个活动）
需求工程过程通过执行起始、导出、精化、协商、规格说明、确认和管理七个不同的活动来完成。
- 在起始阶段，建立基本理解。
- 导出需求，面临范围问题、理解问题和易变问题。
- 精化阶段开发精确的技术模型用以说明软件的功能、特征和约束。
- 通过协商过程来调解客户/最终用户提出的过高要求和需求冲突。
- 规格说明是需求工程师完成的最终工作产品。
- 在确认阶段将对需求工程的工作产品进行质量评估。正式技术评审是最主要的需求确认机制。
- 需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。
11. 11.1 黄金规则
- 用户操纵控制
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
- 允许用户交互可以被中断和撤消
- 技能级别增加时可以使交互流水化并允许定制交互使用户隔离内部技术细节
- 设计应允许用户和出现在屏幕上的对象直接交互
- 使用户与内部技术细节隔离开来
- 减少用户记忆负担
- 减少用户对短期记忆的要求
- 建立有意义的缺省
- 定义直观的快捷方式
- 界面的视觉布局应该基于真实世界的象征
- 以不断的方式揭示信息
- 保持界面一致
- 允许用户将当前任务放入有意义的语境
- 在应用系列内保持一致性
- 如过去的交互模型已建立起了用户期望,除非有不得已的理由,不要改变它
12. 1.4 软件过程（软件工程过程框架）
- 软件过程是为工作产品构建时所执行的一系列活动、动作和任务的集合。
- 过程框架定义了若干个框架活动，为实现完整的软件工程过程建立了基础。
一个通用的软件工程过程框架通常包含以下5个活动：*（重点）*
- 沟通：和客户及其他利益相关者沟通，理解目标、收集需求
- 策划：定义与描述软件工程工作
- 建模：利用模型理解软件需求，完成设计
- 构建：编码和测试
- 部署：交付用户，用户评测与反馈
典型的普适性活动：
- 软件项目跟踪和控制
- 风险管理
- 软件质量保证
- 技术评审
- 测量
- 软件配置管理
- 可复用管理
- 工作产品的准备和生产
13. 15.6 正式技术评审（目标. 评审会议. 评审指导原则）
目标：
- 发现任何形式表现的软件功能、逻辑或实现方面的错误；
- 验证软件的需求；
- 保证软件符合预先定义的标准；
- 获得以统一的方式开发的软件；
- 使项目更容易管理。
评审会议
- 召开评审会议：公司评审委员组织，会前每个参加者做好准备。
- 会议结束后必需有结果：接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品。
- 评审报告与记录：所提出的问题都要进行记录，在评审会结束前产生一个评审问题清单，另外必须完成评审总结报告。
评审指导原则
- 评审产品，而不是评审设计者
- 指定并遵守日程表
- 限制争论与反驳
- 阐明问题，而不是试图解决所有问题
- 做笔记
- 限制会议人数,坚持事先准备
- 为每个被评审的产品要建立评审清单
- 为FTR分配资源和时间
- 对所有评审员进行有意义的培训
- 评审以前做的评审
14. 11.1.2 减轻用户记忆负担（重点）
- 减少用户对短期记忆的要求
- 建立有意义的缺省
- 定义直观的快捷方式
- 界面的视觉布局应该基于真实世界的象征
- 以不断的方式揭示信息
15. 11.3.1 用户分析（重点）
途径：
- 用户访谈
- 销售输入
- 市场输入
- 支持输入
16. 17.6.3 α测试与β测试（重点）
α测试和β测试是确认测试的两种常用方法
- α测试是由用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经α测试后的软件称为β版软件。
- β测试是由软件的最终用户在一个或多个用户场所进行的，与α测试不同，开发者通常不在测试现场。
（补充）
(补充) 1.3 软件工程
软件的定义
- 指令的集合
- 数据结构
- 可用的文档
软件和硬件不同的特性
- 软件是设计开发的，而不是传统意义上生产制造的
- 软件不会“磨损”
- 虽然整个工业向着基于构件的构造模式发展，然而大多数软件仍是根据实际的顾客需求定制
软件工程的定义
- 将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
- 上面所述方法的研究。
软件与硬件
（补充） 5.2.1 利益相关者
直接或间接地从正在开发的系统中获益的人。
（补充） 5.3.2 质量功能部署中的三类需求
- 质量功能部署（QFD）是一种将客户要求转化为软件技术的技术。
- QFD目的是最大限度的让客户从软件工程中感到满意。
- 它确认三类需求：正常需求、期望需求、令人兴奋的需求。
（补充） 9.3.1 体系结构风格的简单分类
- 体系结构风格是一种加在整个系统设计上的变换，其目的在于为系统的所有的构件建立一个结构。
- 通常分为：
- 以数据为中心的体系结构
- 数据流体系结构
- 调用和返回体系结构
- 面向对象体系结构
- 层次体系结构。
（补充） 11.4.1 应用界面设计步骤
- 定义界面对象和作用于对象上的动作
- 按类型分类
- 屏幕布局
（补充） 11.4.3 设计问题
- 系统响应时间：时间长度和可变性
- 用户帮助设施：用户手册
- 错误信息处理
- 菜单和命令标记：快捷键
- 应用系统的可访问性：照顾残疾人
- 国际化
（补充） 17.1.1 验证与确认
- 软件测试是验证与确认的一部分。
- 验证指确保软件正确地实现某一特定功能的一系列活动
- 确认指确保开发的软件可追溯到客户需求的另外一系列活动
（补充） 17.3.1 单元测试
- 软件设计的最小单元，即软件构件或模块的验证工作。
- 单元测试的主要内容包括：模块接口、局部数据结构、边界条件、所有独立路径和所有错误处理路径。
- 在单元测试中，每个被测模块开发一个驱动(driver)程序和若干个桩(stub)模块。
（补充） 17.7.3 压力测试
- 一种要求以非常量的数量、频率或容量的方式执行系统。
