软件工程

软件工程

软件工程

1.软件的概念

软件＝程序＋数据＋文档

程序是按事先设计的功能和性能要求执行的指令序列。
数据是使程序能正常操纵信息的数据结构。
文档是与程序开发，维护和使用有关的图文材料。

软件产品是一种逻辑产品

软件的分类：

系统软件
- 操作系统
- 编译程序
- 设备驱动程序
- 通信和网络处理程序等
应用软件
- 工程与科学计算软件
- 商业数据处理软件
- ERP软件/MIS系统
- 计算机辅助设计／制造软件
- 系统仿真软件
- 办公自动化软件/游戏娱乐
- 智能产品嵌入软件（GPS/汽车ECU/数码相机）
  - 驻留在智能产品内存，控制产品工作的
- 人工智能软件（深蓝/AlphaGo）
  - 利用非数值算法去解决复杂问题的软件。
- 专家系统、模式识别软件、人工神经网络软件
支撑软件（工具软件）
- 纵向支撑软件：分析、设计、编码、测试工具等
- 横向支撑软件：项目管理工具，配置管理工具等
可复用软件
- 标准函数库、类库、构件库等

基于规模的分类：

微型软件
- 500行代码以下
- 1人
- 1-4周
小型软件
- 1k-2k行代码
- 1人
- 1-6月
中型软件
- 5k-50k行代码
- 2-5人
- 1-2年
大型软件
- 50k-100k行代码
- 5-20人
- 2-3年
甚大型软件
- 1M（1000k ）行代码
- 100-1000人
- 4-5年
极大型软件
- 1M-10M行代码
- 2000-5000人
- 5-10年

软件危机：

软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。
软件开发周期长、成本高、质量差、维护困难。

基本目标：

付出较低的开发成本
达到要求的软件功能
取得较好的软件性能
开发的软件易于移植
需要较低的维护费用
能按时完成开发工作，及时交付使用

软件的生存期：

2.软件工程

2.1 软件工程的定义

软件工程是一门交叉性学科，涉及数学、计算机科学、管理和工程学科。

软件工程是：

将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将软件工程方法应用于软件
对1中所述方法的研究

2.2 定义软件工程学科

质量：支持软件工程的根基
软件工程的三要素：方法、过程和工具
- 过程：软件工程的基础，建立了工作环境
- 方法：为构建软件提供技术上的解决方法
- 工具：为过程或方法提供自动化或半自动化的支持

2.2.1软件过程

2.2.1.1软件过程的涵义

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

活动：主要实现宽泛的目标（如：与利益相关者进行沟通）
动作：（如体系结构设计）包含了主要工作产品生产过程中的一系列任务
任务：关注小而明确的目标，能够生产实际产品（如构建一个但软测试）

2.2.1.2过程框架

定义了若干个框架活动，还包含适用于整个软件过程的普适性活动。为实现完成的软件过程建立了基础。

通常包含以下五个活动：

沟通：技术工作开始前，与利益相关者沟通，了解项目目标、收集需求以定义软件功能和特性
策划：定义和描述软件工程工作，包括要需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划
建模：通过建模更好的理解软件需求（细化的），并完成这些需求的软件设计
- 需求分析
- 设计
构建：对所做的设计进行构建，包括编码和测试，后者用于发现编码中的错误
- 编码
- 测试
部署：软件全部或者部分交给用户，用户评测并给出反馈意见

2.2.1.3 框架活动

普适性活动：

软件项目跟踪和控制
风险管理
软件质量保证
技术评审
测量
软件配置管理
可复用管理
工作产品的准备和生产

2.3软件工程实践的精髓及通用性原则

2.3.1精髓

理解问题（沟通和分析）
- 谁是利益相关者
- 需要哪些数据、功能和特性
- 问题是否可划分、是否可建模
策划解决方案（建模和软件设计）
- 解决问题
- 找到最优方法
实施计划（代码生成）
- 评审是否最优
检查结果（测试和质量保证）
- 是否还存在问题
- 是否最优

2.3.2通用原则

David Hooker提出的7个关注软件工程整体实践的原则

存在价值

是否能为系统增加价值
保持简洁（KIS）

利于维护，错误少
保持愿景

开发出来要和希望的一样
关注使用者

要让使用者理解并方便使用
面向未来

软件要持久耐用并且可拓展，提高系统可复用性
提前计划复用

复用省时省力，要提前计划好代码的复用
认真思考

把前六条思考好了再做

2.4软件开发神话

2.4.1管理神话

管理松懈，觉得管理很容易

2.4.2客户神话

客户觉得软件开发知道需求就可以很容易开发，但是都很多不稳定因素，有些东西开发不出来或者很久才能开发出来，而且开发出来不一定是个客户自己满意的

2.4.3从业神话

觉得交了工作就可以

3.过程模型

3.1过程模型的作用

过程模型为软件工程工作提供了特定的路线图，该路线图规定了所有活动的流程、动作、任务、迭代的速度、工作产品及要完成的工作应如何组织。

3.2常用的过程模型

1瀑布模型

系统的、顺序的软件开发方法。适用于需求已确定

难以响应需求的变更，当需求发生改变时,越到后期代价越大
工作量分布不均衡。（例如前期开发、测试人员无法参与，而后期开发、测试人员又特别忙碌。）
客户要有耐心，因为只有在项目结尾的时候才可以收到可执行的程序
线性的开发很容易造成堵塞

2增量过程模型

适用于需求经常改变的软件开发过程。

3演化过程模型

对应开发过程中商业和产品需求变化

1原型开发（快速原型模型）

快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。目的是尽快获知用户的真正需求。

开发人员可以利用已有代码片段或应用工具快速产生可执行的程序

采用迭代技术，不断调整以逐步满足用户需求

当需求很模糊的时候，原型开发模型能帮助相关人员更好的理解需求。

客户的需求可能导致质量和长期维护性不能得到保证
开发人员可能为了完成任务而忘了优化性能

2螺旋模型

特别适用于庞大、复杂并具有高风险的系统；
适用于内部开发的大规模软件项目。

快速开发，越来越完善

采用循环方式逐步加深系统定义和实现的深度，同时降低风险。
确定一系列里程碑作为支撑点，确保利益相关者认可是可行且满意的系统解决方案

4 统一过程

迭代式开发：允许在每次迭代过程中需求都可以有变化
管理需求：RUP描述了如何提取、组织系统的功能性需求和约束条件并把它们文档化。
使用基于构件的体系结构：UP提供了使用现有的或新开发的构件定义体系结构的系统化方法，降低软件开发的复杂性，提高软件重用率。
可视化建模：可视化建模语言UML，提高管理软件复杂性的能力。
验证软件质量：软件质量评估贯穿于整个开发过程,由全体成员参与的所有活动中
控制软件变更:RUP描述了如何控制、跟踪和监控修改，以确保迭代开发的成功。

RUP的四个阶段

初始阶段：建立业务模型，定义最终产品视图，并且确定项目的范围，主要关注项目计划和风险评估；
细化阶段：设计并确定系统的体系结构，制定项目计划，确定资源需求。目标是细化初始需求、细化体系结构、监控风险并细化它们的优先级、细化业务用例以及制订项目管理计划。
构造阶段：开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能。
移交阶段：把开发出的产品提交给用户使用。移交阶段包含β测试时期，以发布完整的系统而终止，其目标是确保信息系统真正满足客户的需求。

5 专用过程模型

1.基于构建开发

强调使用可复用软件，重点在集成

适用于大型软件中存在足够多的共性时

2 形式化方法模型

形式化数学变换，将系统的规格说明书转换为可执行的程序，能提供无缺陷的软件

可用严格的数学符号来说明、开发、验证系统

在商业环境中应用受限制

非常耗时、成本高；
对程序员要求高、需大量培训
很难与客户进行沟通

主要应用于：

高度关注安全的软件
一旦出错将导致重大经济损失的软件

4.敏捷开发

敏捷开发的步骤是“软件工程精简版”，轻量级开发方法

让客户满意且尽早的增量发布；
小而高度自主的项目团队；
非正式的方法；最小化软件工程工作产品以及整体精简开发。

开发的指导方针强调超越分析和设计（尽管并不排斥这类活动）的发布，以及开发人员和客户之间主动和持续的沟通。

4.1 宣言

个体和互动>开发工具和过程
可运行的软件>文档
客户合作>合同谈判
对变更的良好响应>按部就班的遵循计划

4.2 什么是敏捷

瀑布开发模型是以文档为驱动的

敏捷开发只写有必要的文档，或尽量少写文档

利益相关者（经理、客户、最终用户）间

的有效沟通
将客户作为开发团队的一部分
组建高度自主的项目团队
敏捷开发相对于传统的开发变更成本低
具有可适应性，适应快速变更
迭代的方式周期的拿到客户的反馈，增量式的开发策略，增量式的适应

4.3 极限编程

适用于需求模糊且经常改变的场合

eXtreme Programming ，XP

使用面向对象的方法

4.3.1 XP 策划

倾听产生一系列“用户故事”。
评估故事，并给出以开发周数为度量单位的成本。
故事分组，并置于将要开发的下一个软件增量中。
给出对下一个发布版本的基本承诺（就包括的故事、交付日期和其他项目事项）
项目的第一个发行版本（也称为一个软件增量）交付之后，XP团队计算项目的速度估计后续发行版本的发布日期和进度安排。

User Story：是对用户的一个需求的一段简洁清晰的描述，该段描述有三个属性，即商业优先级、开发时间和风险。从某个角度看，XP过程是面向User Story的。

故事卡：用户把User Story的内容和属性写在一张卡片上，该卡片即故事卡

4.3.2 XP设计

严格遵循KIS（Keep It Simple，保持简洁）原则。
鼓励使用CRC卡（类-责任-协作者）。
如果在设计中碰到困难，推荐使用“Spike解决方案”-->一种设计原型。
鼓励“重构”

SPIKE：对不确定的需求和设计等，通过写一些程序、进行详细设计或者演算等等方式做探测和尝试，以确定可行性。这些探测过程称为SPIKE。（一次性原型）

CRC：Class –Responsibility –Collaboration。

Responsibility：Class的行为。
Collaboration：Class之间的相互联系和作用；

重构：在不改变系统行为的前提下，重新调整和优化系统的内部结构，以降低复杂性、消除冗余、增加灵活性和提高性能。

4.3.3 XP编程

推荐在编码开始之前建立单元测试。
鼓励“结对编程”。

结对编程：一种编程模式，两个程序员一起用一台电脑，一起做事。

4.3.4 XP测试

所有单元测试应当使用一个可以自动实施的框架。
“验收测试”由客户规定技术条件，并且着眼于客户可见的系统级特征和功能。

持续集成：不断地把完成的功能模块整合在一起。目的在于不断获得客户反馈以及尽早发现BUG。

4.3.5 XP不适用的领域：

项目团队超过10人；
重构导致大量开销；
很长的编译或者测试周期；
不易进行测试；
团人员异地分布；
不能接收XP文化；

4.4 SCRUM方法

一个增量的、迭代的开发过程。

在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。

4.4.1 基本特征

开发活动由工作单元(packets)组成
测试和文档编制工作贯穿始终
发生于一个过程模式中的工作任务称为一个冲刺(sprint)，其来源于待定项(backlog)中定义的需求
例会时间很短，有时甚至站立开会
在规定时间段内将演示软件交付给用户

4.4.2 过程

5.可行性分析

5.1 可行性研究的位置

5.2 重要性和目的

重要性：

许多问题不可能在预定的系统规模或时间期限之内解决。
如果问题没有可行的解，那么花费在这项工程上的任何时间、人力、软硬件资源和经费，都是无谓的浪费

目的：就是用最小的代价在尽可能短的时间内确定问题是否能够解决

5.3 可行新研究的任务

过程：

确定系统规模和目标
研究目前正在使用的系统
- 新的目标系统必须也能完成它的基本功能；
- 新系统必须要解决旧系统中存在的问题。
- 仔细阅读分析现有系统的文档资料和使用手册，实地考察现有的系统。
导出新系统的高层逻辑模型
- 从现有的物理系统出发
  - 导出现有系统的逻辑模型
    - 再参考现有系统的逻辑模型，设想目标系统的逻辑模型
      - 最后根据目标系统的逻辑模型，建造新的物理系统
进一步定义问题
- 前4个步骤实质上构成一个循环：继续循环过程直到提出的逻辑模型完全符合系统目标
导出和评价供选择的解法
- 技术可行性
  - 使用现有的技术能实现这个系统吗?
  - 软件的质量如何？
  - 软件的生产效率如何？
- 经济可行性
  - 这个系统的经济效益能超过它的开发成本吗?
  - “成本/收益”分析
  - “短期/长期利益”分析
- 社会可行性
  - 系统的操作方式在这个用户组织内行得通吗?
  - 新系统的研制和开发会侵犯他人、集体和国家的利益吗？
  - 会违反国家政策和法律吗？
推荐行动方针
草拟开发计划书
写文档提交审查
- 决定是否继续这项工程以及是否接受分析员推荐的方案

系统的描述：

描述常用的方法
- 系统流程图
  - 数据在系统各部件之间流动情况，它是物理数据流图
- 数据流图DFD
  - 图形化技术，描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能，用于功能建模
  - 用途
    - 环境图（context diagram）也称为顶层数据流图（或0层数据流图），它仅目标系统包括一个数据处理过程。
    - 通过确定系统的输入和输出与外部实体的关系确定系统的边界
- 数据字典
  - 是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明。
  - 数据字典和数据流图共同构成系统的逻辑模型。没有流图数据字典难以发挥作用。没有数据字典，数据流图就不严格。

6.理解需求

需求是成功的软件开发的前提
用户的需求需要通过分析才能得到
客户是逐步发现真正需求的。

需求分析的任务：

获取需求
分析需求（建模）
定义需求（文档）
验证需求

什么样的陈述可作为需求：

必要的(Necessary)。是要求的吗?
无歧义的(Unambiguous)。只能用一种方式解释吗?
可测的(Testable)。可以对它进行测试吗?
可跟踪的(Traceable)。可以从一个开发阶段到另一个阶段对它进行跟踪吗?
可测量的(Measurable)。可以对它进行测量吗?

需求的分类：

功能需求
性能需求
外部接口
- 规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。它也可能规约其格式、时间或其他因素。
- 分类：
  - 系统接口(System interfaces):描述一个应用如何与系统的其他应用进行交互。
  - 用户接口(User interfaces):规约了软件产品和用户之间接口的逻辑特性。即规约对给用户所显示的数据，对用户所要求的数据以及用户如何控制该用户接口。
  - 硬件接口(Hardware interfaces):如果软件系统必须与硬件设备进行交互，那么就应说明所要求的支持和协议类型。
  - 软件接口(Software interfaces):允许与其它软件产品进行交互，如，数据管理系统、操作系统或数学软件包。
  - 通讯接口(Communications interfaces):规约待开发系统与通讯设施（如局域网）之间的交互。如果通讯需求包含了系统必须使用的网络类型(TCP/IP，Novell)，那么有关类型的信息就应包含在SRS中。
  - 内存约束(Memory constraints):描述易失性存储和永久性存储的特性和限制，特别应描述它们是否被用于与一个系统中其它处理的通讯。
  - 操作(Operation):规约用户如何使系统进入正常和异常的运行以及在系统正常和异常运行下如何与系统进行交互。应该描述在用户组织中的操作模式，包括交互模式和非交互模式;描述每一模式的数据处理支持功能;描述有关系统备份、恢复和升级功能方面的需求。
  - 地点需求(Site adaptation requirements):描述系统安装以及如何调整一个地点，以适应新的系统。
设计约束
- 例如：
  - 系统必须用C++或其他面向对象语言编写。
  - 系统用户接口需要菜单。
  - 任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%。
  - 必须在对话窗口的中间显示错误警告，其中使用红色的、14点加粗Arial字体。
质量属性
- 可靠性、可维护性、用户友好性、安全性、可移植性

需求发现

自悟
交谈
观察
客户可能抵触这一观察。其原因是他们认为开发者打扰了他们的正常业务。
小组会
针对已有部分需求文档进行提炼
综合运用以上几点

需求规约SRS

一般来说，SRS应必须具有以下4个性质：

重要性和稳定性程度(Ranked for importance and stability)。例如：基本需求、可选的需求和期望的需求。
可修改的(Modifiable)：在不过多地影响其它需求的前提下，可以容易地修改一个单一需求。
完整的(Complete)：没有被遗漏的需求。
一致的(Consistent)：不存在互斥的需求

需求工程的7项任务

获取需求

质量功能部署（QFD）

是一种将客户要求转化成软件技术需求的技术
QFD的目的：最大限度地让客户从软件工程活动中感到满意
QFD强调：要理解“什么是对客户有价值的”，并去部署这些价值；

使用场景

场景通常称为用例，它描述了人们如何使用系统

构建分析模型

分析模型元素

基于场景的元素
- 功能—从用户的角度描述软件功能
- 用例—描述用户和系统之间的相互关系
基于类的元素
- 在场景中去查找（名词提取法）
行为元素
- 状态图
流化元素
- 数据流图

分析模式

是在特定应用领域内提供的一些解决方案（类、功能、行为），为许多其它应用项目建模时都可以重复使用。
能提高需求抽象分析模型的开发速度。
分析模式存储在一个仓库中，可以被搜索和复用。

7.需求建模

需求建模的方法

7.1基于场景方法

创建初始用例
1. 编写什么？
  - 开始开发用例时，应列出特定参与者执行的功能或活动。
2. 写多少？
3. 编写说明应该多详细？
4. 如何组织说明？
细化初始用例
- 主场景中的每个步骤将通过提问得到评估，并得到更多的其它可能场景
编写正式用例

绘制用例图
- 确定参与者
- 确定用例
- 绘制用例图

7.2 UML模型

UML模型由事物、关系和图组成

事物是对模型中最具代表性成分的抽象，在UML中，可以分为结构事物、行为事物、分组事物和注释事物4类

结构事物是UML模型的静态部分，主要用来描述概念的或物理的元素，包括类、主动类、接口、对象、用例、参与者、协作、构件和节点等。

类（class）── 类用带有类名、属性和操作的矩形框来表示。
主动类（active class）── 主动类的实例应具有一个或多个进程或线程，能够启动控制活动。
接口（interface）── 描述了一个类或构件的一组外部可用的服务（操作）集。接口定义的是一组操作的描述，而不是操作的实现。一般将接口画成从实现它的类或构件引出的圆圈，接口体现了使用与实现分离的原则。
对象（object）── 对象是类的实例，其名字下边加下划线，对象的属性值需明确给出。
用例（use case）── 也称用况，用于表示系统想要实现的行为，即描述一组动作序列（即场景）。而系统执行这组动作后将产生一个对特定参与者有价值的结果。
参与者（actor）── 也称角色，是指与系统有信息交互关系的人、软件系统或硬件设备，在图形上用简化的小木头人表示。
协作（collaboration）── 用例仅描述要实现的行为，不描述这些行为的实现。这种实现用协作描述。协作定义交互，描述一组角色实体和其他实体如何通过协同工作来完成一个功能或行为。类可以参与几个协作。
构件（component）── 也称组件，是系统中物理的、可替代的部件。它通常是描述一些逻辑元素的物理包
节点（node）── 是在运行时存在的物理元素。它代表一种可计算的资源，通常具有一定的记忆能力和处理能力

行为事物是UML模型的动态部分，包括两类：

交互（interaction）── 交互由在特定的上下文环境中共同完成一定任务的一组对象之间传递的消息组成。如图所示。交互涉及的元素包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）
状态机（state machine）── 描述了一个对象或一个交互在生存周期内响应事件所经历的状态序列，单个类或者一组类之间协作的行为都可以用状态机来描述。状态机涉及到状态、变迁和活动，其中状态用圆角矩形来表示。

分组事物

是UML模型的组织部分。
它的作用是为了降低模型复杂性。
UML中的分组事物是包（package）。
包是把模型元素组织成组的机制，结构事物、行为事物甚至其他分组事物都可以放进包内。

注释事物

是UML模型的解释部分
它们用来描述和标注模型的任何元素
通常可以用注释修饰带有约束或者解释的图

UML的图

第1类：用例图
第2类：静态图（包括类图/对象图和包图）
第3类：行为图（包括状态图和活动图）
第4类：交互图（包括顺序图和协作图）
第5类：实现图（包括组件图和配置图）

1 用例图

用例之间可以有泛化(generalization)、扩展(extend)、使用（包含,include）三种关系。

泛化关系：用例泛化是指一个用例可以被特别列举为一个或多个子用例。
扩展关系：基础用例中一段相对独立并且可选的动作，在一定条件下才会执行
使用（包含）关系：一个用例使用另一个用例。当有一大块相似的动作存在于几个用例，又不想重复描述该动作，将重复的部分分离为一个用例，两用例间关系称为使用关系。

2 活动图

UML活动图在特定场景内通过提供迭代流的图形化表示来补充用例。

3 泳道图

活动图的一种变形
UML泳道图表现了活动流和一些判定；
并指明哪个参与者或分析类来实施由活动矩形所描述的活动。

4 类图

5 顺序图

顺序图与用例图和类图的关系顺序图用来表示用例中的行为顺序；展示对象之间的交互，描述类的职责。

6 状态图

7.3 UML和面向对象

1.概念

类可以看成是对象的抽象，代表了此类对象所具有的共有属性和行为。

面向对象＝对象＋类＋继承＋消息通信

面向过程的程序设计：

结构化程序设计，以函数为中心，以功能为中心
以对象为基础，以事件或消息来驱动对象执行处理

面向对象与面向过程的区别：

面向过程：模块化方法，不强调数据与过程的完整结合
面向对象：强调信息隐蔽，更强调数据与处理的完整性。

面对对象的基本特征：

抽象
- 从许多事物中舍弃个别的、非本质的特征，抽取共同及本质的特征
封装
- 把对象的属性和方法结合成一个独立的系统单位，并尽可能地隐藏对象的内部细节。也称“信息隐藏”
继承
- 特殊类的对象拥有一般类的属性和行为
多态
- 两个或多个属于不同类的对象，对于同一个消息或方法所做出不同响应的能力

面对对象方法论：

面向对象分析—OOA( Object-Oriented Analysis )
- 就是运用面向对象的方法进行需求分析。侧重点是业务领域分析，与软件所要应用的行业领域相关，需要由领域专家进行。
- 过程：
  - 获取问题域陈述
  - 建立系统的对象模型
    - 标识和确定类
    - 确定关联
    - 确定属性
  - 建立对象的动态模型
    - 确定事件
    - 顺序图
    - 状态图
  - 建立系统的功能模型
    - 从用户角度展示系统的功能用例图
- OOA的成果：
  - 业务领域用例图
  - 活动图
  - 协作图
  - 大量的业务文档资料
面向对象设计—OOD( Object-Oriented Design )
- 把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。
- 面向对象设计的准则
  - 模块化
  - 抽象
  - 信息隐藏
  - 低耦合
  - 高内聚

7.4基于类的方法

基于类的分析模型的元素包括

类
对象
属性
操作
类的职责协作者(CRC)模型
协作图
包

1.分析类

带有下划线的每个名词或名词词组可以确定为类，并将这些名词输入到一个简单的表中。

类的分析：

外部实体（例如，其他系统、设备、人员）
事物（例如，报告、显示、字母、信号）
偶发事件或事件（例如，所有权转移或完成机器人的一组移动动作）
角色（例如：经理、工程师、销售人员）
组织单元（例如，部门、组、团队）
场地（例如：制造车间或码头）
结构（例如：传感器、四轮交通工具、计算机）

属性描述

定义操作

2.定义类

3.类-职责-协作者建模（CRC）

Class-Responsibility-Collaborator

CRC模型实际上是表示类的标准索引卡片的集合。

这些卡片分三部分

顶部写类名
卡片主体左侧部分列出类的职责
右侧部分列出类的协作者。

评审CRC模型：

所有参加（CRC模型）评审的人员拿到一部分CRC模型索引卡。
拆分协作卡片（也就是说每个评审员不得有两张存在协作关系的卡片）。
- 分类管理所有的用例场景（以及相关的用例图）。评审组长细致地阅读用例。
当评审组长看到一个已命名的对象时，给拥有相应类索引卡的人员一个令牌。
- 当令牌传递时，该类卡的拥有者需要描述卡上记录的职责。
评审组确定（一个或多个）职责是否满足用例需求。
- 如果记录在索引卡上的职责和协作不能满足用例，就需要修改卡片。
修改可能包括定义新类（和相关的CRC索引卡），或者在已有的卡上说明新的或修改的职责、协作。

4.类的分类

实体类
- 也称作模型或业务类，是从问题说明中直接提取出来的（例如FloorPlan和Sensor）
边界类
- 用于创建用户可见的和在使用软件时交互的接口（如交互屏幕或打印的报表）。
控制类
- 自始至终管理“工作单元”[UML03]。
- 设计控制类可以管理：
  - 实体类的创建或更新
  - 当边界类从实体对象获取信息后的实例化
  - 对象集合间的复杂通信
  - 对象间或用户和应用系统间交换数据的确认。

5.UML类图关系

依赖(Dependency)

是两个事物之间的语义关系，其中一个事物发生变化会影响到另一个事物的语义
关联(association)

一种结构关系，它描述了两个或多个类的实例之间的连接关系，是一种特殊的依赖。

分类：
- 普通关联
  
  只要类与类之间存在连接关系就可以用普通关联表示。
  
  普通关联又分为二元关联和多元关联
  
  多重性（multiplicity）：多重性表明在一个关联的两端连接的类实例个数的对应关系，即一端的类的多少个实例对象可以与另一端的类的一个实例相关。
  
  如果图中没有明确标出关联的多重性，则默认的多重性为1。
- 限定关联
  
  通常用在一对多或多对多的关联关系中，可以把模型中的多重性从一对多变成一对一，或将多对多简化成多对一。
- 关联类
  
  用来描述关联的属性
- 聚合与复合
  
  描述了整体和部分之间的结构关系
  - 共享聚合（聚合）：在聚合关系中处于部分方的实例可同时参与多个处于整体方实例的构成
  - 复合聚合（组合）：部分类完全隶属于整体类，部分类需要与整体类共存，一旦整体类不存在了，则部分类也会随之消失，或失去存在价值
泛化(generalization)

就是一般类和特殊类之间的继承关系。
- 普通泛化
  
  在泛化关系中常遇到抽象类
  
  可以分为多重继承和单继承。多重继承是指一个子类可同时继承多个上层父类
- 受限泛化
  
  泛化具有约束条件
  
  一般有4种约束：交叠（overlapping）、不相交（disjoint）、完全（complete）和不完全
- 实现(implement)
  
  是泛化关系和依赖关系的结合，也是类之间的语义关系，通常在以下两种情况出现实现关系：
  - 接口和实现它们的类或构件之间；
  - 用例和实现它们的协作之间。

6 建立对象模型

对象模型的5个层次：

主题层(也称为范畴层)
类-对象层
- 确定类与对象：
  - 找出候选的类与对象
  - 区分实体类、边界类和控制类
结构层
- 确定结构：
  - 确定泛化（继承）关系
  - 确定关联
属性层
- 找出属性
服务层
- 找出服务，如增删查改、统计、排序

7.4行为和模式

1.生成行为模式

行为模型显示了软件如何对外部事件或激励作出响应。

2.识别用例事件

确定事件
- 事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等
画出事件跟踪图
- 事件跟踪图是一种简化的顺序图

3.状态表达

行为建模的场合下，要考虑到：

系统执行其功能时每个类的状态
- 被动状态只是某个对象所有属性的当前状态
- 主动状态指的是对象进行持续变换或处理时的当前状态。
  - 例如，player对象的主动状态：移动、休息、受伤、被捕、失踪
- 事件：是触发器，使对象从一个主动状态到另一个主动状态的转移
系统执行其功能时从外部观察到的系统状态
- 状态———一组在可观察到的情况下,在给定的时间描述系统的行为
- 状态转移———从一个状态转移到另一个状态
- 事件———发生时系统将表现出某种可以测的行为
- 动作———与状态转移同时发生的或者它作为状态转移的结果，通常包含对象的一个或多个操作（职责）

两种不同的行为表现形式：

第一种：显示一个类如何改变基于外部事件的状态。用状态图表示。
第二种：以时间函数的形式显示软件的行为。用顺序图表示。

4 行为建模

列出系统的不同状态（系统如何表现？）
指出系统如何从一种状态转移到另一种状态（系统如何改变状态？）
- 指出事件
- 指出动作
绘制状态图或顺序图

7.5 面向对象软件工程(OOSE)开发的活动及产物

7.6 对象模型技术(Object Model Technology，OMT )系统分析和设计过程概观图

8.设计概念

包括一系列原理、概念和实践，可以指导高质量的系统或产品开发

设计良好的软件应该展示出：

坚固性：程序应该不含任何妨碍其功能的缺陷
适用性：程序应该符合开发的目标
愉悦性：使用程序的体验应是愉快的

1 软件工程中的设计

数据/类设计——将分析类模型变换为软件实现类模型及数据结构
体系结构设计——描述软件主要构造元素之间的关系
接口设计——描述软件元素、硬件元素和终端用户间如何通信
构件级设计——将软件体系结构的构造元素变换为对软件构件的过程性描述

2 设计过程

1.软件的质量：

指导良好设计演化的三个特征：

设计必须实现所有包含在需求模型中的明确需求，而且必须满足利益相关者期望的所有隐含需求。
对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可理解
的指南。
设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域

质量指导原则：

设计应展示出这样一种结构：
- 已经使用可识别的体系结构风格或模式创建；
- 由展示出良好设计特征的构件构成
- 能够以演化的方式实现，从而便于实现和测试。
设计应该模块化；也就是说，应将软件逻辑地划分为元素或子系统。
设计应该包含数据、体系结构、接口和构件的清晰表示。
设计应导出数据结构，这些数据结构适用于要实现的类，并从可识别的数据模式提取。
设计应导出显示独立功能特征的构件。
设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性。
设计的导出应根据软件需求分析过程中获取的信息采用可重复的方法进行。
设计应使用能够有效的表示法来传达其意义。

质量属性：

功能性（functionality)
易用性（usability)
可靠性（reliability）
- 平均故障时间、故障恢复能力等
性能（performance)
- 处理速度、响应事件、资源消耗
- 吞吐量和效率
可支持性（supportability)/可维护性
- 可扩展性
- 可适应性
- 可用性

3 设计基本概念

两种思维

抽象——数据，过程，控制
- 过程抽象：对软件要执行的动作进行抽象。命名暗示了功能，但隐藏了具体细节。如进门
- 数据抽象是描述数据对象的具名数据集合。如门，不显示门的具体属性
- 以降低复杂性，增强扩展能力
求精——细化所有抽象的细节

六种内容

体系结构——软件的整体结构
结构特性: 定义了系统的构件（如模块、对象、过滤器）、构件被封装的方式以及构件之间相互作用的方式。例如，对象封装了数据和过程，过程操纵数据并通过方法调用进行交互。
外部功能特性: 设计体系结构如何满足需求，这些需求包括性能需求、能力需求、可靠性需求、安全性需求、可适应性需求以及
其他系统特征需求。相关系统族: 体系结构应当能抽取出在一类相似系统开发中经常遇到的重复性模式。本质上，设计应当能够重用体系结构构件。
体系结构建模
- 结构模型 – 程序构件的有组织集合
- 框架模型 – 可复用体系结构设计模式
- 动态模型 – 程序体系结构的行为方面
- 过程模型 – 业务或技术流程的设计
- 功能模型 – 用于表示系统的功能层次模型
抽象工厂模式
- 提供一个接口,用以创建一个相联系或相依赖的对象族，而无须指定它们的具体类。
关注点分离——任何复杂问题在被分解为若干块后将更易处理
模块化——数据和功能的分割
（信息）隐蔽——控制接口
- 将细节信息隐藏在接口之后
- 为什么隐蔽信息
  - 减少局部设计决策对全局的影响；
  - 阻止全局数据使用；
  - 促进封装——高质量设计的属性之一；
  - 形成高质量软件。
功能独立——单一功能和低耦合
- 开发具有“专一”功能的模块；
- “避免”与其他模块过多交互的模块
- 内聚性显示了某个模块相关功能的强度；
  - 偶然内聚（Coincidental Cohesion）
    - 当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散
    - 内聚程度最低
    - 缺点：
      - 内容不易理解，很难描述其功能。
      - 把完整的程序分割到多个模块中，在程序运行时会频繁地互相调用
  - 逻辑内聚（Logical Cohesion）
    - 把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪个功能
    - 缺点
      - 不易修改，因包含多个功能
      - 需传递控制参数——控制耦合
      - 未用部分调入内存，影响效率
  - 时间内聚（Classical Cohesion）
    - 大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。例如：初始化模块和终止模块。
  - 过程内聚（Procedural Cohesion）
    - 模块内的处理是相关的，而且必须以特定次序执行
  - 通信内聚 (Communication Cohesion）
    - 模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据
  - 顺序内聚
    - 模块中的处理元素和同一功能密切相关，而且这些处理必须顺序执行
  - 功能内聚 (Functional Cohesion)
    - 模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。
    - 容易修改和维护
- 耦合性显示了模块间的相互依赖性；
  - 非直接耦合(Nondirect Coupling)
    - 两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。
    - 模块独立性最强。
  - 数据耦合 (Data Coupling)
    - 一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。也是较理想的耦合。
  - 特征耦合 (Stamp Coupling)
    - 一组模块通过参数表传递记录信息，就是特征耦合。这个记录是某一数据结构的子结构，而不是简单变量。
  - 控制耦合 (Control Coupling)
    - 如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
  - 公共耦合（Common Coupling）
    - 若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
  - 内容耦合 (Content Coupling)
    - 一个模块直接访问另一个模块的内部数据。
    - 一个模块不通过正常入口转到另一模块内部。
    - 两个模块有一部分程序代码重迭。
    - 一个模块有多个入口。
  - 选择耦合的设计原则
    - 尽量使用数据耦合
    - 少用控制耦合
    - 限制使用公共耦合（除非传递大量数据）
    - 完全不用内容耦合
设计类——提供设计细节以实现分析类

两种经验

模式——传递已验证设计方案的精髓
面向对象设计原则----依赖倒置…

四种机制

方面——理解全局需求如何影响设计的机制
重构——简化设计的重组技术
- 重构软件时，检查现有设计的：
  - 冗余性
  - 没有使用的设计元素
  - 低效的或不必要的算法
  - 拙劣的或不恰当的数据结构
  - 以及其他不足，并通过修改获得更好的设计
面向对象的设计概念
设计类
- 实体类
- 边界类
- 控制类
- 良好设计类的四个特征
  - 完整性 — 封装所有必要的属性和方法
  - 充分性 — 只包含那些“对实现这个类的目的足够”的方法
  - 原始性 — 和一个设计类相关的方法应该关注于实现类的某一个服务，唯一性
  - 高内聚性 — 小的、集中的职责集合
  - 低耦合性 — 类之间的相互协作保持在最小范围内
继承——超类的属性的任何改变都可以立即被所有子类继承
消息——刺激接收对象产生某种行为
多态——这种特性可显著减少扩展已存在的设计所需工作量
测试设计—测试驱动开发

4 面向对象的七个原则

单一职责原则(Single Responsibility Principle)
- 一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中
开闭原则(Open Closed Principle)
- 一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。
里氏代换原则( Liskov Subsitution Principle)
- 所有引用基类（父类）的地方必须能透明地使用其子类的对象。
依赖倒置原则(Dependency Inversion Principle)
- 高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。也就是要针对接口编程，不要针对实现编程。
接口隔离原则(InterFace Segregation Principle)
- 一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。
合成复用原则(Composite/Aggregate Reuse Principle)
- 尽量使用对象组合，而不是继承来达到复用的目的。
迪米特法则（Demeter）
- 一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。

9.体系结构设计

软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件

处理构件负责对数据进行加工，
数据构件是被加工的信息，
连接构件把体系结构的不同部分组合连接起来

1.以数据为中心的体系结构

剪贴板

黑板

2 数据流体系结构

3 调用和返回体系结构

4. 面向对象体系结构

5. 层次体系结构

6 客户机/服务器体系结构

三层C/S结构

![image-20210620231345168](C:\Users\YYX LX\AppData\Roaming\Typora\typora-user-images\image-20210620231345168.png)

B/S结构

MVC结构

5.模式的种类

创建型模式：着眼于对象的“创建、组合及表示”，
例如
- 抽象工厂模式：集中决定实例化什么工厂。
- 工厂方法模式：集中创建某一特定类型的对象，并从几种实现中选择其中的一种。
结构型模式：着眼于有关如何将类和对象组织和集成起来，以创建更大结构的问题和解决方案，例如
- 适配器模式：将一个类的接口转换成客户希望的另外一个接口。
- 聚集模式：是组合模式的一个版本，采用将产物聚集在一起的方法。
行为型模式：解决与对象间任务分配以及影响对象间通信方式的有关问题，

例如
- 责任链模式：对命令对象进行处理，或者通过逻辑包含的处理对象传递给其他对象进行处理。
- 命令模式：命令对象把行动和参数封装起来

6

对体系结构的建模一般会通过体系结构环境图来建模

模块的依赖性在设计中非常重要，体系结构设计是一种能主动管理软件模块依赖性的实践

10.用户界面设计

1.黄金规则q

把控制权交给用户
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式（界面的当前状态）。
- 提供灵活的交互。（不同用户偏好，提供选择机会）
- 允许用户交互被中断和撤销。
- 当技能级别增长时可以使交互流线化并允许定制交互。（宏机制）
- 使用户与内部技术细节隔离开来。
- 设计应允许用户与出现在屏幕上的对象直接交互。（自然的方式，比如拖拽）
减少用户的记忆负担
减少对短期记忆的要求。
建立有意义的默认设置。
定义直观的快捷方式。（助记符，快捷键要有意义）
界面的视觉布局应该基于真实世界的象征。（账单支付系统的例子）
以一种渐进的方式揭示信息。（层次化方式组织）
保持界面一致
- 允许用户将当前任务放入有意义的环境中。（界面太多时知晓当前位置和导航）
- 在完整的产品线内保持一致性。
- 如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它。

2.用户界面的分析

用户分析：通过界面和系统交互的人（最终用户）;
- 用户是经过训练的专业人员、技术员，还是制造业工人？
- 用户平均正规教育水平如何？
- 用户是否具有学习书面资料的能力或者渴望接受集中培训？
- 用户是否是专业录入人员还是键盘恐惧者？
- 用户群体的年龄范围如何？
- 是否需要考虑用户的性别差异？  如何为用户完成的工作提供报酬？
- 用户是否在正常的办公时间内工作或者一直干到工作完成？
- 软件是用户所完成工作中的一个集成部分还是偶尔用一次？
- 用户群中使用的主要交流语言是什么？
- 如果用户在使用软件的过程中出错，结果会怎么样？
- 用户是否是系统所解决问题领域的专家？
- 用户是否想了解界面背后的技术
任务分析建模：最终用户为完成工作要执行的任务;
- 在指定环境下用户将完成什么工作？
- 当用户工作时将完成什么任务和子任务？
- 在工作中用户将处理什么特殊的问题域对象？
- 工作任务的顺序（工作流）如何？
- 任务的层次关系如何？
显示内容分析：作为界面的一部分而显示的内容;
- 不同类型的数据是否要放置到屏幕上固定的位置（例如，照片一般显示在右上角）？
- 用户能否定制内容的屏幕位置？
- 是否对所有内容赋予适当的屏幕标识？
- 为了便于理解，应如何划分长篇报告？
- 对于大集合的数据，是否存在直接移动到摘要信息的机制？
- 输出图形的大小是否需要适合所使用显示设备的限制？
- 如何使用颜色来增强理解？
- 出错信息和警告应如何呈现给用户？
工作环境分析：任务处理的环境。
- 工作环境分析确定了用户接口操作的物理结构和社会结构

11.质量概念

1.什么是质量

对于软件，可能有两种质量：

设计质量：包括需求、规格和系统的设计。
符合性质量：重在实施（遵从设计的程度、满足需求和性能目标的程度）

用户满意度＝合格的产品＋好的质量＋按预算和进度安排交付

质量的实用观点

先验观（transcendental view）：（如Persig）认为质量是马上就能识别的东西，却不能清楚地定义。
用户观点：是从最终用户的具体目标来说的。如果产品达到这些目标，就显示出质量。
制造商观点：是从产品原始规格说明的角度来定义质量，如果产品符合规格说明，就显示出质量。
产品观点：认为质量是产品的固有属性（比如，功能和特性）
基于价值的观点：根据客户愿意为产品支付多少钱来评测质量。

实际上，质量涵盖所有这些观点，或者更多。

2.质量的成本

预防成本
- 质量计划、质量控制和质量保证的管理活动成本
- 为开发模型所怎加的技术活动成本
- 测试计划的成本
- 与上述活动相关的所有培训成本
评估成本
- 工作产品的技术评审成本
- 数据收集和度量数据的成本
- 测试和调试成本
失效成本
- 内部失效成本
  - 返工
  - 补救
  - 失效模型分析
- 外部失效成本
  - 解决投诉
  - 产品退货和更换
  - 热线支持
  - 保修工作

12.项目管理

达到项目预期的软件产品功能和性能要求
时限要求。
项目开销限制在预算之内

1.项目管理涉及的范围

4P：

人员（People） — 成功的项目中最重要的因素
- 利益相关者
  - 高级管理者
  - 项目（技术）管理者
  - 开发人员
  - 客户
  - 最终用户
- 团队负责人
- 软件团队
- 敏捷团队
- 团队的协作交流与沟通
产品（Product）— 要构建的软件
- 产品范围
  - 软件项目范围在管理层和技术层都必须是无歧义的和可理解的
- 问题分解
  - 一旦定义了范围...
    - 它被分解为所包含的功能
    - 它被分解为用户可见的数据对象
    - 它被分解为一组问题类
  - 分解过程一直持续到所有的功能或问题类已经定义出来
过程（Process）— 完成一项工作所要做的框架活动和软件工程任务的集合
- 合并产品和过程
  - 过程框架一旦建立
    - 考虑项目特性
    - 确定所需的严格程度
    - 为每个软件工程活动定义任务集
    - 任务集=
      - 软件工程任务
      - 工作产品
      - 质量保证点
      - 里程碑
- 过程分解
  - 根据实际项目任务开始过程框架活动的分解，如回答一系列问题
项目（Project） — 实现一个产品所需要完成的所有工作
- 易于理解的项目方法

2.五why原则

为什么（Why）要开发这个系统？
将要做什么（What）？
什么时候（When）完成？
由谁（Who）负责？
他们的机构组织位于何处（Where）？
如何（How）完成技术工作和管理工作？
每种资源（例如，人员、软件、工具、数据库）需要多少（How much）？

13.软件项目估算

1 项目估算：

要解决的问题是项目实施的几个主要属性，即：

将要开发产品的规模（size）
- 规模的两种表示方法
  - 代码行：以编程阶段完成以后得到程序的代码行表
    示，如以1千行代码为单位，记为KLOC（Lines Of
    Code）。在项目的开始只是对代码行的估计值。
  - 功能点：它是根据软件需求中的功能估算的。记为
    FP(Function Point)。功能点的估算方法与开发的语言无关。
项目所需的工作量（effort）
- 项目的工作量按项目将要投入的人工来考虑，以一个人工作一个月为单位，记为“人月”。
项目的成本（cost）
- 软件项目的成本通常只考虑投入的人工成本，如某项目投入的总人工费用为12万元。

2 基于问题的估算

首先为每个功能或信息域值确定一个估算值的范围。利用历史数据或凭直觉分别估算各种情况下的规模值。可采用三点（估算值）期望值法：

乐观值
可能值
悲观值

则：规模的期望值S=（乐观值+4*可能值+悲观值）/6

3 基于FP估算的实例

4 五种类型的功能

外部输入
外部输出
内部逻辑文件
外部接口文件
外部查询

5 功能复杂度

软件项目每类功能的复杂程度可能各不相同，将其分为简单的、中等的和复杂的3个等级，分别给予不同的影响参数。

6 调节因子

影响因子
影响级
- 14种类型对软件功能度的影响必须加以区分，将影响因子的影响程度分为6级
- CAF = 0.65 + 0.01N

14.项目进度安排

1.进度安排

熟悉几个图或技术

甘特图(Gantt chart) = 时序图(timeline chart)
- 表示工作进度计划与实际进度情况最为简明的图示方法
WBS(Work Breakdown Structure)
- 项目的工作分解结构 (与任务网络有关)
- 任务的另一种叫法
- 是进度安排的基础，能够建立任务网络和工作分解结构，并利用工具进行项目的进度管理
PERT(Program Evaluation and Review Technique)
- 进度计划评估及评审技术
- 画出PERT图后，系统分析员就可以估算工程进度了，为此需要在PERT上增加一些必要的信息：
  - 把每个作业估计需要时间写在表示该项作业的箭头上方。
  - 为每个事件计算两个统计数字：最早时刻(EET)和最迟时刻(LET)。这两个数字分别写在表示事件的圆圈的左上角和右下角。
- 事件的最早时刻是该事件可以发生的最早时间。通常PERT中第一个事件的EET定义为0，其他事件的EET从左到右按事件发生顺序计算。简单原则：
  - 考虑进入该事件的所有作业；
  - 对每个作业都计算它的持续时间与开始事件EET之和；
  - 选取上述和数中最大值作为该事件的EET。
CPM(Critical Path Method)
- 关键路经法（PERT图的另一种表示法）

2.人员与工作量的关系

3.挣值分析

挣值分析EVA (Earned Value Analysis)

挣值：

是对项目进展的测量。
能够让我们采用定量分析的方法，而不是依赖感觉，来评估一个项目的“完成百分比”。
“早在项目进展的前15%就提供了精确而可靠的性能数据.” [Fle98]

计算挣值的步骤：

BCWS(budgeted cost of work scheduled)：预计工作的预算成本，
- 为进度表中的每个工作任务确定其预计工作的预算成本；
- BCWSi是指工作任务i的计划工作量；
- 在项目进度表中某特定时间点的项目进展状况，BCWS的值是在项目进度表中该时间点应该完成的所有工作任务的BCWSi值之和。
BAC(budget at completion)：完成工作的预算成本，是所有工作任务的BCWS值之和。

对所有任务k BAC = ∑ (BCWSk)

BCWP(budgeted cost of work performed)。已完成工作的预算成本
- BCWP的值是在项目进度表中该时间点已经实际完成的所有工作任务的BCWS值之和。
给定BCWS、BAC和BCWP的值，就可以计算出重要的项目进展指标：
- 进度表执行指标 SPI = BCWP/BCWS
- SPI是效率指标，表示项目使用预定资源的效率。
- 进度表偏差 SV = BCWP–BCWS
  
  SV表示与计划进度的偏差。
- 预定完成百分比= BCWS/BAC ，表示在时间点t应该完成工作的百分比值。
- 完成百分比= BCWP/BAC ，
- 表示在特定时间点 t 实际完成工作的百分比值。
ACWP(actual cost of work performed)---已完成工作的实际成本，是在项目进度表中某时间点已经完成的工作任务所用的工作量之和。然后，可以再计算
- 成本执行指标，CPI = BCWP/ACWP
- 成本偏差，CV = BCWP – ACWP

15.风险管理

1.项目风险

哪些方面会发生错误？
潜在问题是什么？
可能的损害是什么？
我们能做些什么？

风险涉及的是未来将会发生的事情，涉及改变，涉及选择

2.风险策略

被动风险策略：救火模式

被动风险发生时项目团队的处理方法：

缓解—为预期的救火所需要的额外资源做的计划；
失效修复—当风险发生时，找到并使用资源；
危机管理—当缓解和失效修复都失败后，项目处于危机中；

主动风险策略：防火模式

执行正式的风险分析
- 在技术工作开始前启动；
- 识别出潜在的风险，评估其发生的概率及产生的影响，并按重要性排序；
项目团队制定计划管理风险
目的是回避风险；
应急计划在必要时能以可控和有效的方式做出反应；

3.软件风险

软件风险包含两个特性：

不确定性：可能发生也可能不发生
损失：风险发生就会产生恶性后果或损失

风险的类型：

项目风险
技术风险
商业风险

其它分类方式：

已知风险
可预测风险
不可预测风险

4.风险管理的七个原则

保持全面观点
- 全面考虑风险
采用长远观点
- 考虑将来（如软件的变更），做好计划
鼓励广泛交流
- 要重视别人提出的潜在风险，鼓励利益相关者和用户提出风险
强调持续过程
- 持续保持警惕
开发共享产品
- 更容易进行风险识别和评估
鼓励协同工作

5.风险管理范型

MSF风险管理范型

6.风险识别

识别风险的一种方法是建立风险条目检查表。

6.1评估项目风险

风险评估是需要根据项目进度不断更新

与利益相关者的共识有关：

高层的软件管理者和客户管理者已经正式承诺支持该项目了吗？
最终用户对项目和待开发的系统或产品热心支持吗？
所有的客户或用户对项目的重要性和待开发的系统或产品的需
求有共识吗？

与需求相关：

软件工程团队及其客户充分理解需求了吗？
客户已经完全地参与到需求定义中了吗？
最终用户的期望现实吗？
项目范围稳定吗？
项目需求稳定吗？

与项目团队相关：

软件工程团队的技能搭配合理吗？
项目团队对将实现的技术有经验吗？
项目团队的人员数量满足项目需要吗？

6.2 风险因素和驱动因子

4类风险因素：

性能风险（performance risks）— 产品能够满足需求且符合其使用目的的不确定程度。
成本风险（cost risks）— 能够维持项目预算的不确定程度。
支持风险（support risks）— 开发出的软件易于纠错、修改及升级的不确定程度。
进度风险（schedule risks）— 能够维持项目进度且按时交付产品的不确定程度

风险驱动因子对风险因素的影响有四个类别：

7 风险预测

建立风险表：

风险显露度（影响）：risk exposure，RE

RE = P x C
P 是风险发生的概率
C 是风险发生时带来的项目成本

8 风险缓解、检测和管理（RMMM）

风险缓解—我们如何能避免风险？
风险监测—监测那些能使我们确定风险在变高或变低的因素？
风险管理及应急计划—风险发生时我们采取什么应急计划？（风险缓解已经失败，风险已经发生）

要考虑成本问题：评估RMMM步骤带来的效益>实施RMMM步骤所需的成本吗？

风险管理的80-20经验法则：

整个项目的80%的风险可能是由只占20%的已经识别的风险所引发；
早期风险分析的工作可帮组项目管理者确定哪些风险在这20%中（如高风险显露度的风险）

9 RMMM计划

风险缓解是一种问题规避活动
风险监测是一种项目跟踪活动

posted @ 2021-06-24 00:30 doms-xiang 阅读(1973) 评论(0) 收藏举报

刷新页面返回顶部