【期末复习】软件工程知识总结（四川大学）

第一章 介绍

1.1 软件的定义

答：

1.指令的集合（程序）通过这些指令来满足预期的特性、功能、需求

2.数据结构。使程序可以良好的使用信息

3.软件描述信息。以硬拷贝和虚拟形式存在，用来描述程序的操作和使用

1.2 软件与硬件的区别（软件特征）

属性	软件	硬件
开发方式	开发或者工程获得	以传统方式制造
使用时间	不会磨损(wear out)(最本质区别),而是退化(deterioriting)	会磨损
复用性	客户定制,可复用程度低(尽管模块化)	可复用程度高
替换	不存在备用部件	存在备用部件

双重角色 既是产品也是产品交付的载体

Q:为什么软件要更新?

A:新的商业需求，新的环境和技术，与其他软件的兼容和交互，新的计算环境

1.3 软件过程是什么？

软件过程是工作产品构建时所执行的一系列活动,动作和任务的集合.

• 活动 实现宽泛目标(如与利益相关者沟通)
• 动作 如体系结构设计,包含很多任务
• 任务 小而具体,如一个单元测试

软件过程定义了软件工程化中采用的方法（框架活动），但软件工程还包括该过程中的应用技术（技术方法和自动化工具），软件过程包含在软件工程中。

1.4 软件工程是什么？

软件工程是建立和使用一套合理的工程原则,以便经济的获得可靠的,可以在实际机器上高效运行的软件.

定义

1. 将系统化、规范化、可量化的方法应用于软件的开发、运行和维护），即：将工程化的方法应用于软件开发
2. 以及对上述方法的研究

第二章 软件过程

2.1 软件工程的层次

软件工程是层次化的结构

• 工具 为Process过程和Method方法提供支持
• 方法 提供技术上的解决方法，指出如何构建
• 过程 基础，及时、合理地把技术结合在一起
• 质量关注点 根基，质量承诺

2.2 普适性活动

• 软件项目跟踪和控制Software project management
• 技术评审Formal technical reviews
• 软件质量保障Software quality assurance
• 软件配置管理Software configuration management
• 工作产品的准备和生产Work product preparation and production
• 可复用管理Reusability management
• 测量Measurement
• 风险管理Risk management

2.3 过程评估和改进（Capability maturity Model，CMM等）

• Standard CMMI Assessment Method for Process Improvement (SCAMPI)： 用于过程改进的CMMI标准评估方法.

  分五个评估阶段：起始、诊断、建立、行动和学习

• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)：用于组织内部过程改进的CMM评估

  为评估软件组织的相对成熟度提供诊断技术；使用SEI-CMM作为评估的基础

• SPICE—The SPICE (ISO/IEC15504) ：软件过程改进和能力测定（software process improvement and capability determination）

  标准定义了软件过程评估的一组需求。本标准的目的是帮助组织对任何定义的软件过程的有效性进行客观的评估。

• ISO 9001:2000 for Software：国际标准化组织的软件开发标准

  一种通用标准，适用于任何希望提高其提供的产品、系统或服务的总体质量的组织。因此，本标准直接适用于软件组织和公司。

• GB 国标

CMM最先出现，但后来得到了改进，并被CMMI所取代。

不同的三坐标测量机存在重叠、矛盾、缺乏标准化等问题。CMMI后来解决了这些问题。

最初，CMM专门描述软件工程，而CMMI描述集成过程和规程，因为它同时适用于软件和系统工程。

CMM/CMMI适用于大型项目。关注过程，而不是软件开发的人员和技术方面，这意味着实现它们并不能保证项目成功。

CMM/CMMI是一个综合的过程元模型，它描述了成熟软件过程中应该出现的特定目标、实践和能力

2.4 过程流（线性、迭代、演化、并行）

1. 线性过程流：从沟通到部署顺序执行五个框架活动
2. 迭代过程流：在执行下一个活动前，重复执行之前的一个或多个活动
3. 演化过程流：采用循环的方式执行各个活动
4. 并行过程流：将一个或多个活动与其他活动并行执行
   

2.5 过程模型

2.5.1 瀑布模型

典型生命周期模型 沟通、策划、建模、构建、部署

好处	坏处
适用于：需求固定，工作将以线性方式进行到完成	真正的项目很少遵循顺序流程。随着项目团队的进行，更改可能会导致混乱
	要求客户明确地陈述所有需求，并且难以适应许多项目开始时所存在的自然不确定性
	最后才能看到可执行程序，如果系统存在重大缺陷，会导致灾难后果

V-模型 与之相似 提供了将验证确认动作应用于早期软件工程中的方法

2.5.2 增量模型

优点	缺点
克服人手不足	关注每一个增量的操作产品的交付。早期的增量很容易被“忽略”。
技术风险控制
线性（每个增量按照瀑布模型进行管理）+并行
每个增量都是可提交运行的版本，（第一个增量往往是核心产品core product

2.5.3 原型模型

优点	缺点
当需求很模糊时适用	原型常常会被抛弃，而不是在其上继续开发（增加成本）
适用高风险	一些凑合的技术和算法可能会遗留在最终系统中

2.5.4 螺旋模型（风险驱动的过程模型）

螺旋模型是一种演化过程模型，它结合了原型的迭代性质和瀑布模型的系统性和可控性，注重风险控制（里程碑），适合大型项目开发

螺旋模型两个显著特点：

• 采用循环的方式逐步加深系统定义和实现的深度
• 确定一系列里程碑，确保利益相关者都支持可行的和令人满意的系统解决方案

在每一次迭代的过程中，都要考虑风险、标记里程碑

优点	缺点
使用原型作为风险降低机制，任何时候都可以应用原型模型方法	很难说服客户项目演进的方法是可控的
开发大型系统和软件的现实方法。（开发人员和客户更好地理解和应对每一个过程中的风险）	依赖风险专家来保证项目成功，同样有风险

2.5.5 并行开发模型（concurrent development model）

协同开发模型，又叫做协同工程。可以表示一系列框架活动，软件工程动作和任务以及相应的状态。协同模型更适合于不同的工程团队共同开发的系统工程项目。尤其是大型的软件公司或者是跨国公司往往要用到这种模型来开发项目。

其它活动（比如沟通或编码等）、动作、任务都可以如右图方式表示，它们同时存在并处于不同的状态

2.5.6 演化模型

软件总是在持续改变，这些改变通常要求在非常短的期限内完成，在许多情况下，及时投入市场是最重要的要求（如果错过了，软件本身可能会变得毫无意义）。

软件团队面临的挑战是在这些关键项目、产品参数和客户满意度之间建立适当的平衡

在许多情况下，上市时间是最重要的管理要求。

如果错过了一个市场窗口，软件项目本身可能毫无意义。

缺陷

• 不确定性
• 演化速度的控制
• 应侧重灵活性与扩展性

演化模型是迭代的过程模型

• 原型模型
• 螺旋模型
• 协同模型

2.5.7 其他模型

• ​ 基于构建的开发
• ​ 形式化方法模型
• ​ AOSD（Aspect-Oriented Software Development）

2.6 统一过程模型（迭代增量过程，用UML进行面向对象软件工程的框架和过程）

“用例驱动、以架构为核心、迭代和增量”的软件开发过程，关注风险

统一过程模型尝试从传统的软件过程模型中挖掘最好的特征和性质，但是以敏捷软件开发中最好的原则来实现

统一过程模型是使用UML进行面向对象软件软件开发的理想的过程模型

第三章 敏捷开发

3.1 敏捷是什么？

最简而言之：快速、增量（迭代）

• 快速交付产品
• 对变化的有效响应
• 客户加入团队，所有利益相关者之间的有效沟通
• 项目计划必须灵活
• 一个自组织团队，便于沟通

3.2 敏捷宣言（Manifesto for Agile）

敏捷	传统
个人与交互	过程和工具
可运行软件	繁复文档
客户合作	合同谈判
响应变更	遵循计划

3.3 极限编程（XP）

3.3.1 极限编程框架活动

策划

设计 KIS, CRC

编码 结对编码

测试 关注重要的、易出错的地方，进行回归测试，80%错误发生在20%代码中

3.3.2 极限编程的关键

五个要素

沟通（紧密的非正式口头协作，避免大量文档）

简单（只为眼前的需要而设计，不考虑未来的需要）

反馈（来自实施的软件本身、客户、其他软件团队成员）

勇气（今天的设计意味着未来的需求可能会发生巨大的变化，因此需要大量的返工）

尊重（IT成员之间、利益相关者之间）

3.4 其他敏捷过程

Scrum

DSDM-Dynamic Systems Development Method

AM

AUP

第四章 需求工程

4.1 需求工程的定义

• 需求工程是指致力于不断理解需求的大量任务和技术。
• 建立了从设计到构建的桥梁
• 从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通活动并持续到建模活动

4.2 质量功能部署（quality funtion development，QFD）

将用户要求转换成软件技术需求。

QFD概念可应用于整个软件过程（不仅仅在需求收集中）

三种需求

• 常规需求
• 预期需求
• 兴奋需求

四种展开

1. 功能展开
2. 信息展开
3. 任务展开
4. 价值评估

4.3 ERD图

椭圆表示属性，加在长方形上

4.4 用例图

4.5 需求工程的目标

起始、获取、细化、协商、规格说明、验证、需求管理

4.6 需求分析建模原则（rule of thumb）

1. 关注可见需求，不要陷入细节
2. 增加对软件需求主体的理解
3. 有些非功能的模型可以延后到设计阶段完成
4. 低耦合
5. 确认需求模型对所有利益相关者带来价值
6. 简洁

4.7 需求建模模型

4.7.1 基于场景的建模

用例：

用户故事： 描述对用户有价值的功能,好的用户故事应该包括角色、功能和商业价值三个要素

1.角色：谁要使用这个功能。

2.功能：需要完成什么样的功能。

3.价值：为什么需要这个功能，这个功能带来什么样的价值。

4.7.2 基于类的建模（class-modeling， CRC）

类图、协作图

类-职责-协作者

CRC建模提供了一个简单方法，可以识别和组织与系统或产品需求相关的类

职责 封装在类中的属性和操作

协作者 完成某个职责的其它协作的类

类之间关系

• Aggregate聚合**(is-part-of)**

（强关联）

• Associate关联**(has-knowledge-of)**

（只有控制面板和传感器协作，才能确定传感器状态）

（双向）

• Dependency依赖**(depends-upon)**

（单向）

4.7.3 面向流的建模

DFD，数据模型，数据流图

4.7.4 行为模型

状态图、序列图

• 状态图描述系统的状态，并显示事件如何影响系统状态。
• 序列图指示事件如何导致从对象到对象的转换。

4.8 UML是什么

4.9 分析建模所使用的图

• 用例图

• 活动图

• 类图

• 状态图

• 部署图

• 序列图

• 协作图

第五章 设计概念

5.1 设计概念

模块化

信息隐藏

关注点分离

重构

内聚（cohesion）

耦合（coupling）

5.2 面向对象概念

类、属性、行为

多态性

封装

继承

5.3 质量属性（FURPS）

功能性Functional

易用性Usability

可靠性Reliability

性能Performance

可支持性Supportability

5.4 DFD

变换流/事务流

使用数据流映射

举例

5.5 四个设计模块

包括数据设计、架构设计、界面设计、部件设计、（部署设计）

5.5.1 数据设计

5.5.2 架构设计

架构设计包括软件构件，构件的属性和构件之间的相互关系

架构设计的重要性

1. 有助于各方的交流
2. 突出早期的设计，对其后工作很重要（打好设计的根基）
3. 建立一个相对小的、易于理解的模型，其描述了系统如何构成及构件如何一起工作

架构的风格流派

• 以数据为中心架构
• 数据流架构
• 调用和返回架构
• 面向对象架构
• 层次化架构

5.5.3 界面设计

黄金原则

1. 用户操作控制
2. 减少用户的记忆和负担
3. 保持界面的一致性

用户界面设计模型

• 用户模型 所有终端用户的画像
• 设计模型 用户模型的设计实现
• 感知模型 界面给用户的印象
• 实施模型 界面的外观和给用户的感觉与描述的支持文档相符合

用户界面设计过程

• 界面分析和建模
• 界面设计
• 界面构建
• 界面确认

界面分析和建模

• 用户分析
• 任务分析
• 展出内容分析
• 工作环境分析

界面设计

1. 使用接口分析期间获得的信息定义接口对象和操作
2. 定义将导致用户界面改变的事件,对这种行为进行建模
3. 将每个接口状态描述为它将实际呈现给终端用户的样子
4. 指示用户通过界面提供的信息理解系统的状态

5.5.4 部件设计

构件是模块化的、可部署的和可替换的部件，该部件封装了操作实现和接口

从面向对象角度看部件是

从方便角度看部件是

决策表Decision Table

部件设计原则

• 开闭原则 （open-close principle, OCP）
• 替换原则 (the liskov substitution, LSP)
• 依赖倒置原则(dependency inversion principle, DIP)
• 接口分离原则(the interface segregation principle, ISP)

5.5.5（部署设计）

第六章 测试

6.1 测试是什么

测试是为了在将软件交付给用户之前发现软件设计和实现过程中因疏忽所造成的错误

6.2 测试策略

• 为了执行有效的测试,应该进行有效的技术审查.这样可以在测试开始之前消除许多错误
• 测试是从部件级开始并且向外朝着整个基于计算机的系统的集成测试
• 不同的测试方法适用于不同时间点的不同软件工程方法
• 测试是由软件开发者和一个独立的测试组执行的
• 测试和调试是不同的活动,但任何测试策略都应该适应调试

6.3 测试方法

1. 单元测试

2. 集成测试

   • 自顶向下
   • 自底向上
   • 三明治测试

3. 验证测试

   • 软件的验证是通过一系列证明符合要求的测试来实现的.设计测试计划和测试用例都是为了确保所有的功能需求得到满足,所有的行为体征和属性得到实现,所有的内容都是准确的,并且正确的呈现,所有的性能需求都得到了满足,文档是正确的,并且可用性和其他需求都得到了满足
   • 配置检查
   • 验收测试(alpha/beta testinng)

4. 系统测试

   • 恢复测试
   • 安全性测试
   • 压力测试
   • 性能测试
   • 部署测试
   • 配置测试

5. 黑盒测试与白盒测试

   • 黑盒测试

     就是功能测试,从外部执行测试用例,用以验证待测功能的正确性,而不考虑软件内部处理逻辑,外部测试

   • 白盒测试

     也叫玻璃盒测试,是一种测试用例设计方法.它利用作为构件层设计的一部分所描述的控制结构来生成测试用例.白盒测试是基于过程细节的封闭测试.测试构建内部的数据结构,算法流程与接口,内部测试.

6. 其他测试

   回归测试\冒烟测试\调试|调试方法

6.4 面向对象的测试

• 面向对象的单元测试

  单元的概念改变,最小的可测试单元是封装的类,单个操作不能再单独测试,而是作为类的一部分

• 面向对象的集成测试

  集群测试是OO软件集成测试的一个步骤,定义一个协作类集群(通过检查CRC和对象关系模型确定),是通过测试用例来实现的,这些测试用例试图发现协作中的错误.

  两种集成方法

  • 基于线程的测试集成了响应系统使用的一个输入或事件所需的一组类.
  • 基于使用的测试通过测试那些很少使用服务类在独立的类测试后,下一层的类称为从属类

6.5 环复杂度(cyclomatic complexity)

V(G) = E(edge) - N(Node) + 2

V(G) = P(选择节点数) + 1