软件工程复习笔记

这是软件工程的复习笔记。

Chapter 1 软件工程概述

 

【软件工程】

定义： 系统工程；技术问题 开发过程 给参与者分配角色

目的： 高质量软件 解决方案 考虑特性 质量影响

方法及作用（5部分）： 分析（正反）、设计（解决方案）、开发团队（角色和职责）、开发（实现）、项目管理（小部分，进度）

 

【错误、故障、失效】

错误：人为出错（误解需求，错误代码）

故障：错误导致的缺陷，静态存在，内部视图

失效：故障导致，指系统违背了它应有的行为。动态存在，外部视图

一个错误对应多个故障，一个故障并不一定对应一个失效

 

【软件质量衡量】

产品质量 A.用户（足够功能，易学易用） B.开发者（内部特性）

过程质量（开发和维护过程的质量）

商业价值 商业环境提供的产品和服务，将技术价值与商业价值统一起来

 

【软件工程的阶段及对应文档】

共有9步！

需求分析和定义（SRS，软件需求规格说明书）

系统设计（SAD，系统结构图）

程序设计（模块功能算法与数据描述）

程序实现（程序文档）

单元测试

集成测试（结构图）

系统测试

系统交付（培训手册）

维护

 

【软件过程】

定义 组织和规范 有序任务

重要性（英文课本45页）它强制活动具有一致性和结构性，以及指导性。

阶段 同软件工程阶段

 

名词解释：抽象、复用

 

Chapter 2 过程和生命周期的建模

 

【瀑布模型】

定义： 阶段 瀑布般

各阶段以及文档： 共有8步！和软件工程的阶段几乎一样。将单元测试和系统测试合一了。系统交付改成了验收测试。

优缺点：优点是方便布置工作；简单易于解释；是其他模型的基础。缺点是：不实际；软件变动无法处理重复开发；文档转换有问题。

 

【分阶段开发模型】

定义： 部分提交

增量式开发：添加子系统

迭代式开发：增强子系统

 

【螺旋模型】

四个象限 确定 评估 计划 开发

四重循环的结果 操作概念 需求 产生设计 进行测试

画图

 

名词解释：原型、UP(RUP)

 

习题2

本章中各种过程模型的优点和缺点

瀑布模型：略

V模型：优点：更好的说明了各类测试活动所扮演的角色，将用户考虑进了测试中。缺点：增加的测试可能消耗过大，还有一些类似与瀑布模型的缺点

原型模型：优点：在制定解决方案之前促进开发者对问题的理解；减少了风险和不确定性。缺点：在那些容易理解或者比较简单的地方，花费在构造原型上的时间就浪费了。原型的构造资源消耗量较大。

分阶段开发模型：优点：减少了用户得到产品需要等待的时间；用户培训可以很早开始；可以顺应市场开发新功能；多次发布允许问题快速修正；缺点：用户可能因为不完全的系统或者频繁修改而不满；产品可能永远无法“完成”；问题分解困难。

螺旋模型：优点：在开发过程中控制风险；容易与原型结合。缺点：间接开销大。

 


 

Chapter 3 计划和管理项目

【项目进度】

项目进度： 软件开发周期 项目阶段、步骤、活动 离散活动交互 完成时间 估算

活动： 项目的一部分

里程碑： 活动的完成

关键路径： 节点时差为0

 

【软件人员的能力】

完成工作

兴趣 经验 培训

交流 责任

管理技能

 

【软件项目组织结构】

7个部分

主副程序员，高级低级程序员，资料员，管理，测试

 

【COCOMO模型】

构造成本模型 Constructive Cost Model

阶段1 应用组装 高层 工作量生成器 规模

阶段2 早期设计 功能点 规模 测量

阶段3 后体系结构 功能点 代码行 规模预算

 

【软件风险】

定义 负面结果 不希望看到

降低策略： 改变性能或功能；分配到其他系统，或购买保险；接受并控制

 

名词解释：软件风险

 

Chapter 4 获取需求

【需求过程】

四步一结果

引发（收集），分析（理解和建模），规格说明（文档化），确认（检查是否匹配）=》SRS（软件需求规格说明）

 

【发生冲突时的优先级】

必须，值得要，可选

 

【需求文档】

需求定义：面向用户 完整罗列期望

需求规格说明（SRS）：面向开发者 专业词汇

 

【功能性需求和非功能性需求】

功能性需求： 内部功能 外部交互 输入应对 实体状态变化 输出结果 设计约束与过程约束

非功能性需求/质量需求： 质量特性 响应时间 可靠性 低维护代价

设计约束： 设计决策 如：平台或者接口的选择，用户的类型限定

过程约束： 技术和资源限制 如：材料、人员、文档的数量或者类型

 

【数据流图 DFD】

Data Flow Diagrams

构成和画法： 加工 数据流向 数据集合 外部项

 

【需求原型化】

抛弃型原型 仅用于了解问题 不提交 Throw-away

演化型原型 最终会变为产品 Evolutionary

 

名词解释：需求（来自用户的 期望行为 综合描述 对象、状态、约束、功能）

 

Chapter 5 设计体系结构

【三种设计层次】

体系结构设计： 软件需求 系统能力与系统部件 软件整体结构

代码设计： 模块算法 数据结构设计

运行设计： 最底层：内存分配、数据格式、位模式

关系： 顺序。开发人员会往返于各个层次之间。

 

什么是设计？

设计是将问题转换为解决方案的创造性过程。

 

【设计用户界面】

5个要注意的要素： 比喻/寓意思维模型 模型的导航 规则 外观 感觉

文化差异

用户爱好

 

Chapter 6 设计模块

【模块概念】

模块化： 关注点分离 不相关的部分 独立研究

耦合： 互相关联程度 coupling

内聚： 内部关联程度 cohesion

 

【耦合和内聚的基本分类】

耦合有6个层次：非直接（无信息传递），数据，特征（数据结构），控制（控制量），公共（公共数据），内容（直接修改另一个）。

内聚有7个层次：偶然性（不相关的功能），逻辑性（逻辑上相关），时间性（同一时间完成），通讯性（访问共享数据）、过程性（特定次序）、顺序性（有输入输出关系）、功能性（组成单一功能）

 

【OO设计的基本原则】

单一职责原则（SRP） SingleResponsibility Principle 一个类只负责一个功能领域

重用原则（DRY） Don’trepeat yourself Principle

开闭原则（OCP）Open-Close Principle

替换原则（LSP）The LiskovSubstitution Principle

依赖倒置原则

接口隔离原则

迪米特原则（LOD） Law ofDemeter 一个软件实体尽可能少与其他实体发生相互作用 中介者模式

 

【OO开发优势】

语言一致性（用同一种语义构造来描述问题和解决方案）

过程一致性（需求、高级设计、低级设计、代码、测试...相同语义构造）

 

【OO开发步骤】

需求、高级设计、低级设计、OOP、测试

 

【UML图对OO开发的意义】

都显示了系统某个方面，提供了对问题或解决方案的详细描述

 

名词解释：模块化、抽象、设计模式

 

Chapter 7 编写程序

 

【程序内部文档需要的注释信息】

共5项

头部注释板块（HCB） header commentblock

其他程序注释

有意义的变量名和语句标记

安排格式以增强理解

文档化数据

 

名词解释：极限编程（XP, Extreme Programming）、派对编程（Pair Programming）

 

Chapter 8 测试程序

 

【故障类型】

共有10种

算法、计算和精度（如浮点数）、文档（文档与程序不匹配）、压力或过载（数据结构承载不了）、能力或边界、计时、性能（反应时间）、恢复（不能从运行时失效恢复）、硬盘和系统软件、标准和过程

 

【测试阶段及其任务】

单元测试（隔离每个部件，对构件本身单独测试），集成测试（验证构件是否能共同工作），功能测试（是否满足功能需求），性能测试（将系统与软硬件需求剩余部分比较），验收测试（按客户预期），安装测试（在用户环境下正确运行）。

 

【测试方法】

黑盒：只测试功能，输入数据，记录输出

白盒：根据测试对象的结构来测试

 

【集成测试】

自底向上集成（驱动） 易生成测试用例，适合OO；底层为通用模块较好；顶层设计缺陷不能及时纠正

自顶向下集成（桩，stubs） 顶层模块缺陷尽早发现；测试用例难生成，需要大量桩

 

名词解释：正交故障分类（Orthogonal Defect Classification，一个故障属于一个类别）、单元测试（集成的系统）、走查（评审小组，代码和文档，正确性）、审查（更正式=》评审小组，关注问题清单，代码和文档）

 

Chapter 9 测试系统

【系统测试】

主要步骤：

功能测试 性能测试（与非功能系统需求比较） 验收测试（根据用户需求描述） 安装测试（保证能正确运行）

 

【功能测试】

含义：基于SRS，闭盒

作用：比较系统实际表现与需求

基本指导原则：1. 故障检测概率 2.独立的测试小组 3. 了解期望动作和输出 4. 测试合法输入和不合法输入 5. 不能为了测试去改系统 6. 停止测试的标准

 

【性能测试】

含义：针对非功能要求，考虑这些功能执行的方式

分类： 压力、容量、配置、兼容性、安全性、计时、环境、质量、恢复、维护、文档、人为因素

 

【确认测试（验收测试）】

含义：询问用户是否也认为系统满足需求

分类：

1.基准测试（benchmark test）用户准备测试用例 用户来评估

2.引导测试（pilot test）非正式日常工作中进行 没有正式的测试用例 分为alpha test和beta test

Alpha test：公司或组织内部先来测试一下（by developer）

Beta test：客户测试，试用性质非正式

3.平行测试（parallel test）用于分阶段开发模型，新旧版本的系统并行运转

 

名词解释：系统配置（客户 系统组件）、软件配置管理（管理和控制方法 控制差别 降低风险和错误 版本）