设计模式

创建模式（5种）

单例模型

抽象工厂模型

工厂方法模式

建造者模式

原型模式

结构模式（七种）

组合模式

适配器模式

装饰器模式

代理模式

外观模式

桥接模式

组合模式

享元模式

行为性模式（十一种）

Chain of Responsibility 责任链

Command 命令模式

Interpreter 解释器模式

Iterator 迭代器模式

Mediator 中介者模式

Memento 备忘录

Observer 观察者

State 状态模式

Strategy 策略模式

Template Method 模板方法

Visitor 访问者

软件测试

软件测试方法

测试类型

尽早、不断测试

程序员避免测试自己设计的程序

既要选择有效、合理的设计、也要无效、不合理的数据

修改后应进行回归测试

尚未发现的错误数量与该程序已发现错误数成正比

动态测试（计算机运行）

黑盒测试（功能测试，输入输出）

等价类划分（不同类型选几个，达到全面覆盖）

边界值分析（边界值）

错误推测（经验推测）

因果图

白盒测试（看到内部结构）

基本路径测试

循环覆盖测试

逻辑覆盖测试

灰盒测试

静态测试（纯手工，不依赖计算机）

桌前检查

代码审查

代码走查

测试阶段

单元测试：模块测试，模块功能、性能、接口等。

集成测试：模块间的接口；一次性|增量方式（自顶向下、自低向上、混合 式）

确认测试：验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试，验收测试

系统测试：真实环境下，验证完整的软件配置项能否和系统正确连接

恢复测试

安全性测试

压力测试

性能测试

负载测试

强度测试

容量测试

可靠性测试

可用性测试

可维护性测试

安装测试

回归测试：测试软件变更后，变更部分的正确性对变更需求的符合性。

面向对象测试

算法层（单元测试）：包括等价划分测试、组合功能测（评定表）、递归函数测和多态消息测

类层（模块测试）：包括不变式边界测试、模态类测试和非模态类测试

模板层/类树层（集成测试）：包括多态服务测试和展平测试

系统层（系统测试）

软件调试

调试方法

蛮力法：通过计算机找，低消耗时

回溯法：出错处人工控制流程往回追踪（反向）

原因排除法：主要是演绎和归纳，用二分法实现（正向）

调试和测试的区别

测试目的为找出错误，调试目的是定位错误并修正错误

调试是测试后的活动，目标方法思路不同

测试已知条件开始，预先定义过程，有预知结果；调试从未知条件开始，结束过程不可预计

测试过程可以事先设计，进度可以确定；调试不能描述过程或持续时间

系统转换计划

遗留系统演化策略

淘汰策略：遗留系统的技术含量较低，具有较低业务价值。

继承策略：遗留系统的技术含量低，已经满足企业运作的功能或性能要求，有较高商业价值，目前业务紧密依赖该系统。开发新系统需完全兼容遗留系统功能模型和数据模型，并且为了保证业务连续性，新老系统需要并行运行一段时间，逐渐切换新系统。

改造策略：遗留系统具有较高业务价值，基本能满足企业业务运作和决策支持的需要。建成时间短，演化策略为改造。改造包括 系统功能 和 数据模型；系统功能指在原系统基础上增加新应用要求，对遗留系统本身不改变；数据模型改造指将遗留系统旧的数据模型向新的数据模型的转化。

集成策略：遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自领域工作良好，但对于整个企业，存在多个相似系统，不同系统不同数据不同平台，形成了信息孤岛，策略为集成

新旧系统转换策略

直接转换策略

并行转换策略（蓝绿发布、金丝雀发布）

分段转换策略（按功能|按地市）

数据转换与迁移

ETL: 抽取 -> 转换 -> 装载

旧数据库 -> 切换通过工具/采用手工录入/通过新系统生成 -> 新数据库

系统运行与维护

正确性维护：改正系统开发阶段已发生而系统测试阶段尚未发现错误。

适应性维护：适应信息技术变化和管理需求变化而进行修改。（操作系统、软件运行环境、导致系统不能运行。国产化迁移）

完善性维护：扩充功能和改善性能的修改。

预防性维护：为了改进应用的可靠性和可维护性。

软件架构设计（占20-26分）

软件架构概念

架构就是需求分配，即将满足需求的职责分配到组件上。

软件体系结构 = 架构

需求分析（业务） -> 架构（鸿沟） -> 软件设计（技术）

1.软件架构风格描述某一特定应用领域中系统组织方式惯用模式。

2.为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素相互作用、指导元素集成的模式以及这些模式的约束组成。

3.项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性。

4.推理和控制更改更加简单，有助于循序渐进的原型设计，可以作为培训基础

5.可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

架构发展史

无架构阶段（汇编）

萌芽阶段（程序结构设计）

初级阶段（UML）

高级阶段（4+1视图）

软件架构建模

4+1视图

UML逻辑视图（最终用户：系统功能需求）

UML开发视图（编程人员：软件管理|源代码组件）

UML物理视图（系统工程人员：系统拓扑、安装、通信等|软件到硬件映射关系）

UML进程视图（系统集成人员：性能可扩展性、吞吐量等|并发）

场景（UML: 用例视图）

软件架构风格（https://www.suibibk.com/topic/776202820129914880）

架构设计的一个核心问题是能否达到架构级复用

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整系统。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

5类架构

数据流风格：批处理序列、管道-过滤器

批处理序列（处理完整的一批数据）：数据必须是完整的，以整体的方式传递。

管道-过滤器（数据流、流式处理）：每个构件都有一组输入输出，构件读输入的数据流。

调用/返回风格：主程序/子程序、面向对象、层次结构

主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主/子程序，子程序通常可合成模块。

面向对象：构件是对象，对象是抽象数据类型的实例。

层次结构（3-5层合适）：构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。

独立构件风格：进程通信、事件驱动系统（隐式调用）

虚拟机风格：解释器、基于规则的系统

解释器：工作流引擎，高度定制

基于规则的系统：规则集、规则解析器、规则/数据选择器和工作内存，一般用在人工智能和DSS中。

仓库风格（以数据为中心的风格-数据中心）：数据库系统、超文本系统、黑板系统

数据库系统

超文本系统：构件以网状链接方式相互链接，用户可以在构件之间进行按照人类联想思维方式任意调整到相关构件（现代集成编译环境一般采用这种架构风格）。

黑板系统：大部分以数据库为基础去实现，数据中台-全局数据库，通过黑板来存储、共享、传递、触发，通常用于解决问题没有确定性算法的软件中（信号处理，问题规划和编译器优化等）。

其他架构

闭环控制架构（过程控制）：软件被用来操作一个物理系统时，软件与硬件之间可以粗略表示为一个反馈循环，通过接受一定输入，确定一系列输出，最终使环境达到一个新的状态。适合嵌入式，设计连续动作与状态。（变频空调、定速巡航、PID）

C2风格（并行构件网格）

构件和链接件都有一个顶部和一个底部

构件的顶部要链接件的底部，构件的底部要链接到连接件的顶部，构件不允许直连。

一个连接件可以和任意数目的其他构件和连接件链接

当两个连接件进行直接链接时，必须由其中一个底部到另一个的顶部。

层次架构风格

两层C/S -> 三层C/S -> 三层B/S -> 混合架构

三层B/S

表现层 MVC -> MVP -> MVVM

MVC

Model（模型-Entity Bena）用于处理应用程序数据逻辑部分。

View（视图-JSP）处理数据显示部分。

Controller（控制器-Servlet）处理用户交互部分。

主动 MVC

被动 MVC

MVP（MVC 变种）

实现了 V 与 M 解耦（V不直接使用 M，修改 V 不影响 M）

更好支持单侧（业务逻辑在 P，可以脱离 V 来测试逻辑，一个 P 用于多个 V，不需改变 P 逻辑）

MVP 中 V 要处理界面事件，业务逻辑在 P 中，MVC 中界面事件由 C 处理。

MVVM

中间层

数据访问层 ORM

数据架构层 数据库

富互联网应用（RIA）

RIA 结合了 C/S结构反应快，交互性强，以及BS架构传播范围易

RIA简化并改进了 BS 架构的用户交互

数据能被缓存在客户端，从而实现一个比 HTML 的响应速度更快的数据往返服务器的次数更少的用户界面。

基于服务的架构（SOA）

服务是为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

ESB 总线（中介-简化为星形结构）

1.服务，松散耦合

2.构件，粗粒度

3.对象，标准化接口

实现方式：

Web Service（底层传输层、服务通信协议层、服务描述层、服务层、业务流程层、服务注册层）

服务注册中心

服务请求者

服务提供者

ESB（企业服务总线）

提供位置透明的消息路由和寻址服务

提供服务注册和命名的管理功能

支持多种消息传递泛型

支持多种可以广泛使用的传输协议

支持多种数据格式及其互相转换

提供日志和监控功能

服务注册表

服务注册、服务位置、服务邦定

关键技术

发现服务 UDDI、DISCO

描述服务 ESDL、XML Schema

消息格式层 SOAP、REST

编码格式层 XML(DOM、SAX)

传输协议层 HTTP、TCP/IP、SMTP等

WSDL：是 WebService 接口对应的 WSDL 文件，通过 xml 格式说明如何调用，相当于接口文档（使用说明书）

SOAP（Simple Object Access Protocol）：简单对象访问协议，用于访问网络服务的协议；SOAP协议=HTTP+XML

REST

1.HTTP+XML进行基于 Web 通信的技术

2.简单性，缺少严格配置文件

3.只支持几个操作（POST、GET、PUT、DELETE）

4.强调信息本身，称为资源

1.网络上所有事物抽象为资源

2.资源对应一个唯一标识

3.通过连接器接口对资源标识

4.对资源各种操作不会改变资源标识

5.所有操作无状态

微服务架构

面向服务架构的一种，微小的服务。

特点是：小，专注于一件事情；轻量级通信机制；松耦合、独立部署

微服务的优势：

1.技术异构性

2.弹性

3.扩展

4.简化部署

5.与组织结构相匹配

6.可组合性

7.对可替代性的优化

微服务的挑战

1.分布式系统的复杂度

2.运维成本

3.部署自动化

4.DevOps与组织结构

5.服务间依赖测试

6.服务间依赖管理

区别

MDA 模型驱动架构

Model 客观事物抽象表示

Architecture 构成系统部件、连接件及其约束的规约

Model-Driven 使用模型完成软件分析、设计、构建、部署、维护等各开发活动。 MDA 起源与分离系统规约和平台实现的思想

目标：可移植性(Portability)、互通性(interoperability)、可重用性(Reusability)

3种核心模型

平台独立模型（PIM）：具有高抽象层次，独立于任何实现技术模型。

平台相关模型（PSM）：为某种特定实现技术量身定制，让你用这种技术中可用的实现构造来描述系统的模型。PIM会变换成一个或多个PSM。

代码Code：用源代码对系统的描述（规约）。每个PSM都将变成代码。

架构描述语言ADL

ADL 三个基本元素

构件：计算或数据存储单元；

连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则

架构配置：描述体系结构的构件与连接件的连接图

主要的架构描述语言

Aesop: 支持体系结构风格的应用

MetaH：为设计者提供了关于实时电子控制软件系统的设计指导

C2：支持基于消息传递风格的用户界面系统的描述

Rapide：支持体系结构设计的模拟并提供了分析模拟结构的工具

SADL：提供了关于体系结构加细的形式化基础

Unicon：支持异构的构件和连接类型并提供了关于体系结构的高层编译器

Wright：支持体系结构构件之间交互的说明和分析

特定领域软件架构（DSSA）

基本活动

领域分析(建立领域模型) -> 领域设计(获得DSSA) -> 领域实现(开发和组织可复用信息)

领域分析机制（1是军师，234是干活的）

1.领域专家：有经验的用户、同领域系统需求分析、设计、实现以及项目管理的有经验的软件工程师。

2.领域分析人员：领域设计人员应由有经验的软件设计人员担任。

3.领域实现人员：领域实现应由有经验的程序设计人员担任。

建立过程

定义领域范围 -> 定义领域特定的元素 -> 定义领域的设计和实现需求约束 -> 定于领域模型和架构 -> 产生、搜集可复用的产品单元

基于架构的软件开发

基于架构的软件设计（ABSD）

ABSD 方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。

使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，意味着需求获取和分析没有完成，就开始了软件设计。

ABSD有三个基础。第一个是功能分解，基于模块内聚和耦合技术；第二是通过选择架构风格来实现质量和业务需求；第三个是软件模板的使用。

ABSD是递归的，而且迭代每个步骤都是清晰定义的。因此不管是否完成设计，架构总是清晰的，有助于降低架构设计的随意性。

设计与视图：从不同视角检查，所以会有不同的视图

用例用来捕获功能需求、特定场景来捕获质量需求

软件质量属性（1-4）

1.性能

系统响应能力。

代表参数：响应时间、吞吐量等

设计策略：优先级队列、资源调度

2.可用性

系统能够正常运行的时间比例。

代表参数：故障间隔时间

设计策略：冗余、心跳线

3.安全性

向合法用户提供服务的同时能阻止非授权用户使用的企图或拒绝服务的能力。

设计策略：追踪审计

4.可修改性

较高的性能价格比对系统进行变更的能力。

主要策略：信息隐藏

5.可靠性

意外错误使用或系统错误情况下维持软件功能特性。

代表参数：MTTF、MTBF

设计策略：冗余、心跳线

6.功能性

系统所能完成所期望的工作能力

7.可变性

体系结构经扩充或变更成为新体系结构的能力。

8.互操作性

经常与其他系统或自身环境相互作用。

软件架构评估 （https://www.suibibk.com/topic/771497642910810112）

为什么要进行架构评估？

架构评估到底评什么？

架构评估怎么评？

风险点：系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患

敏感点：指为了实现某种特定的质量属性，一个或多个构件所具有的特性。

权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。

基于调查问卷（检查表）的方式

基于度量的方式

基于场景的方式

ATTM

ATAM的评估目的是依据系统质量属性和商业需求评估设计决策的结果。ATAM希望揭示出架构满足特定质量目标的情况，使我们更清楚地认识到质量目标之间的联系，即如何权衡多个质量目标。

SAAM

SAAM(Scenario-based Architecture Analysis Method)，它也是一种基于场景的评估方法，最早用于分析体系结构的可修改性，后来也用于其他质量属性的评估。相比于SAAM，要简单许多.

评估目的

验证基本的体系结构假设和原则，评估体系结构固有的风险。SAAM指导对体系结构的检查，使其主要关注潜在的问题点，如需求冲突。SAAM不仅能够评估体系结构对于特定系统需求的使用能力，也能被用来比较不同的体系结构。

评估的参与者

风险承担者、记录人员、软件体系结构设计师。

评估活动和过程

1.形成场景

指的是风险承担者们集中在一起，集体讨论，提出一个个系统需求场景。记录人员把这些场景记录在册，形成文档的过程。

2.描述体系结构

指的是体现结构设计师，对待评估的体系结构进行适当的描述，包括静态属性和动态特征，可以用自然语言也可以用形式化手段，以让参加评估的所有人员都能充分理解。

这一步骤和上一个形成场景的步骤可以合并在一起，重复进行多次

3.对场景进行分类和确定优先级

系统可分为直接场景和间接场景，直接场景指的是本体系结构可以直接支持的场景，即不需要对体系结构做任何修改即可直接实现。

另外一种间接场景则是需要对现有体系结构做些更改才能支持的场景。

最后用投票的方法，确定间接场景的重要性优先级，以便大家将有限的时间花在最重要的事情上。

4.对间接场景进行单个评估

就是将选出来的重要场景与体系结构描述对应起来。体系结构设计师具体说明体系结构需要做哪些修改变更才能适用间接场景的要求，并估计这些变更的代价。

最后形成一份全部场景的总结性列表。

列表字段包括：场景编号、场景描述、直接/间接、需要做的更改、更改/新增构建数量、更改工作量估计

5.评估场景的相互作用

当两个或多个间接场景需要修改到同一个构建时，这时场景就在这个构件上出现了相互作用，需要特别评估。

出现这种情况，往往是设计方案中功能分配不合理，或者是设计文档未能充分说明体系结构。

6.形成总体评价

最后，评估人员对场景和场景间的相互作用做一个总体的权衡和评价。通过各个场景权重与分值得出一个总体的评价，从多个体系结构，或者一个体系结构的不同设计方案选择出一个最优的方案。

问题模式 -> 需求说明 -> 架构描述

​

​

软件产品线

构件与中间件技术

Web架构技术

信息安全体系

鉴别服务

用户名+口令

数字证书

生物特征识别

访问控制

自主访问控制（DAC）

访问控制列表（ACL）

强制访问控制（MAC）

基于角色的访问控制（RBAC）

基于任务的访问控制（TBAC）

数据完整性

阻止对媒体访问的机制：隔离，访问控制，路由控制

探测非授权修改的机制：数据签名，数据重复，数字指纹，消息序列号

数据保密性

通过禁止访问提供机密性

通过加密提供机密性

抗抵赖

数据签名

可靠性设计

避错技术

测试、技术设计

容错技术（自动化）

结构冗余（硬件、软件）

信息冗余（校验码）

时间冗余（重复多次进行相同计算）

检错技术（被动人工处理）

出错报警，人工处理，成本较低

降低复杂度设计

N版本程序设计（静态冗余）

支付多渠道集成。恢复实时性好，通过表决检测错误，多机硬件运行环境，向前恢复

恢复块设计（动态冗余）

相当于主备，错误回滚到前一个正确的状态。恢复实时性差，通过验证测试程序检测错误，单机硬件运行环境，向后恢复。

防卫式程序设计

try catch, 处理异常

实现策略：错误检测、破坏估计、错误恢复

双机容错

双机热备（主、备）

双机互备（同时提供不同服务、心不跳则接管）

服务器1

服务A(运行)、服务B（未运行）

服务器2

服务A（未运行）、服务B（运行）

双机双工（同时提供相同服务、集群的一种）

项目管理

范围管理

确定项目边界，哪些工作应该做，哪些不包含在项目中。

步骤：

范围计划编制

范围定义

创建WBS

范围确认

范围控制

时间管理

也叫进度管理，采用科学的方法，确定进度目标，编制进度计划何资源供应计划，进行进度控制，在与质量、成本、目标协调的基础上，实现工期目标。

步骤：

活动定义（WBS工具包）

活动排序

前导图法（单代号网络图，PERT，PDM，有向无环图）

最早开始时间|持续时间|最早完成时间

|活动编号|

最长开始时间|总时差|最迟完成时间

注意：总时差为0 是关键活动

关键路径法（双代号网络图）

甘特图（Gantt）

优点：简单直观、容易制作、便于理解，能清晰标识出每一个的起始与结束时间，适用于小型项目，可用于 WBS 的任何层次、进度控制、资源优化、编制资源和费用计划。

缺点：不能系统表达一个项目所包含的各项工作间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。

活动资源估算

专家判断估算

三点估算

一个功能耗时估算三个时间点：简单实现-3人日+(正常实现-5人日*4)+技术难点实现-8人日

算法：3+(5*4)+8/6

解释：由于正常实现加权4倍，总共6倍所以除6

功能点估算

自上而下的估算

功能拆分，估算

自下而上的估算

功能负责人向上报时，统一收集

活动历时估算

制订进度计划

是否为关键活动

偏差是否大于总时长

偏差是否大于自由时差

进度控制

赶工：增加资源

快速跟进：活动并行执行

成本管理

整个项目实施过程中，为确保项目批准的预算条件下尽可能保质按期完成，而对所需的各个过程进行管理与控制

成本估算

自顶向下估算

自低向上估算

差别估算

成本预算

直接成本与间接成本

管理储备

零基准预算

成本控制

挣值分析（挣值管理）

计划工作量的预算成本(PV)

PV = 计划工作量*预算定额

已完成工作量的实际成本（AC）

已完成工作量的预算成本（EV|挣值）

EV = 已完成工作量*预算定额

完工预算（BAC）

BAC=完工时的PV总和

计算指标

进度偏差：SV=EV-PV

成本偏差：CV=EV-AC

进度绩效指数：SPI=EV/PV

成本绩效指数：CPI=EV/AC

剩余工作的成本（ETC）

ETC=BAC-EV

ETC=(BAC-EV)/CPI

完工估算（EAC）

EAC=AC+ETC

x项目在线测试项目设计对10个函数代码的编写（假设每个函数代码编写工作量相等），项目由2个程序员进行结对编程，计划在10天内完成，总体预算1000元，每个函数的平均成本是100元。项目进行到第五天，实际消耗是400元，完成了3个函数的编写。

PV=500

AC=400

EV=300

进度偏差：-200

成本偏差：-100

软件质量管理-质量保证与质量控制

CMMI、ISO9001

质量保证是每隔一定时间进行的，主要通过系统的质量审计和过程分析保证项目质量。工具包括：质量审计和过程分析。

质量控制是实时监控项目的具体结果，以判断它们是否符合相关质量标准，制订有效方案。

一定时间内质量控制的结果也是质量保证的质量审计对象。

软件评审

不应以测试代替评审

评审人员应关注于实质性问题

评审会议不应变为问题解决方案讨论会

评审应被安排进入项目计划

评审参与者应了解整个评审过程

评审人员事先应对评材料充分了解

应重视评审的组织工作

软件过程改进 CMMI

阶段式（组织能力成熟度）

已管理级：需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证

已定义级：需求开发、计算解决方案、产品集成、验证、确认、组织级过程焦点、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境

定量管理级：组织级过程性能、定量项目管理

优化级：组织级改革与实施、因果分析和解决方案

软件配置管理-配置项与配置库

关于配置项

配置项是构成产品配置的主要元素，分为两大类

1.属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等；

2.属于项目管理和机构支撑过程域产生的文档：工作计划、项目质量报告和项目跟踪报告等。

设备清单、CASE工具操作手册不属于配置项

每个配置项主要属性有：名称、标识符、文件状态、版本、作者和日期等。所有配置项都被保存在配置库里，确保捕获混淆、丢失。配置项及其历史记录反映了软件的演化过程。

关于配置库

开发库（动态库、程序员库、工作库）：可以随意修改

受控库（主库、系统库）：必须先申请，申请通过才有权限修改。

产品库（备份库、静态库）：不能修改。

软件工具

软件开发工具：需求分析工具、设计工具、编码与排错工具。

软件维护工具：版本管理工具（VSS、CVS、SCCS、SVN）、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。

软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具和选择。

变更控制

变更申请

变更评估

变更决策

变更实施

变更验证

沟通存档

草稿 0.x -> 通过评审 -> 正式版 1.0 -> 修改 1.1 -> 通过评审 -> 正式版 1.1

风险管理 - 风险概念

关心未来

关心变化

关心选择

基本属性：随机性和相对性

项目风险

预算、进度、人员和组织、资源、用户和需求问题

项目复杂性、规模和结构的不确定性

技术风险

设计、实现、接口、测试和维护方面的问题

规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）

商业风险

市场风险：系统虽然优秀，但是脱离市场

策略风险：系统不符企业信息系统战略

销售风险：销售部门不清楚如何推销

管理风险：重点转移或人员变动而失去上级支持

预算风险：过程没有得到预算或人员保证

风险曝光度

技术方法是风险出现概率乘以风险可能造成的损失。 风险曝光度=风险影响*概率

假设正在开发的软件项目可能存在一个未被发现的错误，而错误出现概率是0.5%，给公司造成损失将是1000000元，错误风险曝光度为：1000000*0.5%=5000元。

项目管理工具

能做什么（项目管理相关的工作辅助）：任务调度、成本估算、资源分配、预算跟踪、人时统计、配置控制，确定关键路径、松弛时间、超前时间和滞后时间，生成一定报表和报告。

不能做什么（开发技术相关辅助工作）：不能指导软件设计人员按软件生存周期各个阶段使用技术进行设计工作。