殷人昆《实用软件工程》复习资料

1.软件工程

目标：正确性、可用性、适合销售

活动：需求、设计、实现、V&V(验证与确认)、支持

原则：开发泛型、设计方法、支持工具、工程管理WW

软件工程是开发，运行，维护和修复软件的系统方法，将系统化的，规范的，可度量的方法应用与软件的开发，运行维护的过程。即将工程化应用于软件中。

2.软件过程中的基本活动（pdca）

1.软件规格说明plan

2.软件开发do

3.软件确认check

4.软件演进action

3.瀑布模型：需求-》系统设计-》实现单元测试-》集成与系统测试-》运营维护。他的显著特点是顺序性

和依赖性。

4.演化模型：软件通过不断的演化才能完成和完善，其显著特点是迭代。适合于业务和需求不断变更的

开发过程，交付部分功能给客户，确认需求，逐步完善。

5.螺旋模型：将瀑布模型和演化模型结合起来，加入了风险分析。

6.增量模型：是将软件分解成一系列的增量的构件，在增量开发迭代中逐步加入，也叫极限程序设计。

7.软件工程原则：

a)抽象自顶向下，逐层细化

b)模块化的开发方法

c)信息隐蔽和数据封装。

d)局部化

e)一致性

f)完备性

g)可验证性

8.软件工程基本原理：

a)按软件生存期分阶段制定计划并认真实施

b)坚持进行阶段评审

c)坚持严格的产品控制

d)使用现代程序设计技术

e)明确责任

f)用人少而精

g)不断改进开发的过程

9.识别用户要求，必须考虑的问题：

a)功能和性能

b)可靠性和质量

c)总的系统目标

d)成本与进度的把控

e)制造需求

f)市场竞争情况

g)有效的技术

h)将来可能的扩展

10.可行性研究

a)问题识别

b)市场调查

c)分析准备

d)环境分析

e)物理分析

f)功能分析

g)信息分析

h)动态分析

i)确立系统方案和成本估算

j)模型评审

k)成本可行性

l)法律可行性

11.面向对象设计

面向对象=对象+分类+继承+消息通信，基本组成部分叫对象，计算是通过新对象的确立和对象之间的通信来执行。相对于面向过程开发，核心：数据被封装在对象中，而不是全局变量中，数据流是通过消息传递，而不是面向过程解决办法。算法被包裹在对象中，实现功能。

12.统一建模语言：UML概述

Unified Modeling Language的缩写，他聚集了建模的精髓。

数据建模（实体关系图ERD）

业务建模（工作流）

对象建模

构件建模

13.UML图

用例图：描述系统边界和主要功能；主要该系统在它的上下文环境所提供的服务。

1）上下文环境建模：主要指在位于系统之外并与系统进行交互的参与者以及他们扮演的角色的含义。

2）功能需求建模：说明系统想要的行为。

交互图（时序图，协作图）：描述用例的实现，其主要描述了系统的外部视图，如何通过对象之间的交互实现用例。包括顺序图和协作图，顺序图也叫时序图或序列图，他是按照时间顺序来的。

类图：标示系统的静态机构

类图从系统的逻辑视图展现了一组类、接口、协作和它们之间的关系，类图给出系统的静态设计视图，主动类的类图给出了系统的静态进程视图。其主要包括

1）类及其结构和行为

2）接口

3）协作

4）关联、依赖、泛化关系

5）多重性和导航指示符

6）角色名字

类图的关系：

父子关系实现关系

关联关系（单向关联有箭头，多项无箭头）

聚合：整体和部分关系

组合关系（也是整体与部分，但是部分离开整体无法存活）依赖关系（动物无法离开氧气，为依赖关系）

整体类图状态图：模型化对象的行为

泳道图

泳道图

构件图和部署图：展现物理实现的体系结构

衍型：扩展建模能力

14.软件需求：

a)为满足用户解决某一问题而达到某个目标所需要的条件或者能力，系统或系统部件为满足合同、

规格、标准说明或其他正式的强制性文档所必须具有的条件和能力。为满足以上条件和能力的文档化说明

b)软件需求包括：业务需求、用户需求、功能需求、非功能性需求。

c)业务需求：描述了组织愿景，即为什么要开发一个系统；系统的业务范围、业务对象、客户特性、

价值和各种特性的优先级别。

d)用户需求：描述了系统必须完成任务，即用户对系统的目标要求。它只涉及到外部可见行为，不

涉及内部特性。是用户对自身需求的一种陈述。这种陈述可能与实际需求不一致。

e)功能需求：定义了开发者应该提供的软件功能或服务，但不涉及这些功能和服务的实现。

f)非功能需求：对功能需求的补充，包括了对系统的各种限制和用户对系统的质量的要求。如系统

响应时间或截面。

i.包括产品必须遵从的标准、规范和合约

ii.外部接口的具体细节

iii.性能要求

iv.设计实现的约束条件

15.需求获取的过程

需求获取包括以下活动：

（a）发现和分析问题

（b）获取需求

（c）需求归档

需求获取的主要步骤

（a）理解业务领域，即目标软件的业务环境，如银行、电信，了解后可以建立自对业务理解后的数据模型。通过结合实际业务，迭代完善业务模型

（b）定义项目的视图和范围，定义项目范围是描述项目该做什么，不该做什么一般使用用例图。

（c）寻找软件的需求来源，客户、竞品、系统需求规格说明书、当前系统的问题报告和改进要求、市场调研报告、观察用户如何工作、用户工作场景分析、事件和响应。

（d）识别用户类和用户代表，确定系统的用户及其分类，与用户一块工作，确定系统的决策者。

（e）确定系统的业务流程和业务规则

（f）访谈和记录

（g）需求整理和描述

16.面向对象的UML需求获取方法：

a)用户模型视图：从用户角度来标示系统，通过用例图来标示

b)结构模型视图：通过静态的数据模型图，类图、对象图来建模

c)行为模型视图：描述系统的动态和行为，以及在上述两种视图中的各元素如何交互。

d)实现模型视图

e)环境模型视图

面向对象模型，分为三个独立模型

a)有用例和场景组成功能视图

b)用类和对象标示的分析对象模型

c)用状态图和顺序图标示的动态模型

17.对需求文档的要求：

1）完整：要求必要的需求信息，必须进行完整的描述

2）无歧义：每种需求只有一种解释。

3）一致性：对需求规格说明，必须保持一致。

4）可验证：可演示、测试、分析、审查、特殊的检查

5）可修改

6）可追踪：向前和向后的追踪性。

18.软件需求评审的主要内容：

a)用例：是否清晰，用例规格。

b)功能：是否清楚，是否必须，是否满足，是否覆盖异常

c)性能：是否精确描述，是否制定指标，是否制定使用环境

d)接口：外部、内部描述是否清晰。调用关系。

e)数据：是否确定系统的输入、输出

f)硬件

g)软件

h)通信

i)正确性完整性一致性，兼容性，安全性清晰性，健壮性，可扩展性。

19.需求管理：

a)需求变更：建议变更---分析影响---作出决策---交流---合并

b)版本控制：确定需求文档版本

c)需求跟踪：

d)需求状态跟踪

20.需求变更的控制策略：

a)需求变更原因：内部原因，外部原因

i.内部原因：需求获取的不确切，需要发生变更，以适应真正的客户需求