PERT的步骤：
1.估计每个活动的最有可能时间，乐观时间，悲观时间，计算活动的期望周期与标准偏差。
2.正向遍历得到期望达到事件的日期
3满足目标的可能性
6.软件项目的资源管理：资源定义，资源分配直方图。
资源定义----资源是执行项目所需要的任何项和人。
资源分配直方图通过延迟某些活动的开始日期，来平衡化资源直方图。
软件项目的风险管理：风险的定义，风险管理的框架，风险处理的方法。
风险的定义---一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。
风险管理的框架---风险识别，风险分析与优先级排序，风险策划，风险监督
风险优先级，风险影响 = (可能的危害)×(发生概率)
风险处理的方法---接受风险，规避风险，降低风险，转移风险
风险的分类--4大类：参与者，技术，结构，任务
7. 软件项目的监督和控制：挣值分析。
(1) https://wenku.baidu.com/view/7bcf90280066f5335a81211b.html
(2) https://blog.csdn.net/pmpljp/article/details/19299077
挣值分析---0/100 OR 百分比
计划价值(已计划工作的预测成本)---Planned value --- PV-----200*5
挣值(已执行工作的预测成本)---Earned value ---EV-----200*3.5
实际成本(已执行工作的实际成本)--- Actual Cost ---AC----1000
进度偏差(已完成的工作值与计划的工作值的差)---Schedule Variance-- SV ---EV-PV---700-1000
成本偏差(已完成工作的预算成本和实际成本的偏差)---Cost Variance --CV --EV-AC---700-1000
进度性能指标(Schedule Performance Index, SPI): SPI = EV / PV---大于1及比预期好
成本性能指标(Cost Performance Index, CPI): CPI = EV / AC----大于1及比预期好
完成时间的估计值(按照当前进度项目的完成时间估计)---TEAC = SAC / SPI (Schedule At Completion, SAC, 项目的计划周期)--------10/0.7
项目的成本预算(按照当前的进度，项目的总支出的估计)--- EAC = BAC / CPI (Budget At Completion, BAC, 计划的项目预算)-----2000/0.7
出题另有：试画出项目的PV、AC、EV曲线，并分析项目的状态。各项任务完成的比例见表3。(完成百分比法分配挣值)
8. 软件项目的配置管理：配置管理的任务，配置项。
配置管理的任务---标志变更,控制变更,确保变更正确实现,向受变更影响的组织和个人报告变更
配置项---软件配置管理的对象，一个软件配置项是项目中一个特定的、可文档化的工作产品集。例如，程序，文档等
常见的软件配置管理软件---GitHub,Bitbucket,CVS,Subversion（SVN）,Google code
四、经典的软件过程管理
1. CMM/CMMI
CMM是一种理念，是指导思想，不是过程不是技术不是方法。
(1) CMM：出发点，体系结构，关键过程域，关键实践活动。
CMM---能力成熟度模型
CMM出发点---改善现有软件开发过程，也可用于其他过程。
CMM体系结构
CMM由5个成熟度级别组成：
每个成熟度级别（除级别1）包含了实现该级别的若干个关键过程域（KPA）
关键过程域(Key Process Area)：一系列相互关联的操作活动，标识了达到某个成熟度级别时所必须满足的条件。
CMM共有18个KPA，每一级都有自己的KPA。KPA分为三大类：管理过程、组织过程和工程过程。
每一个KPA进一步被分为称为公共特征的5个部分：执行约定、执行能力、执行活动、测量和分析、验证实施
这些公共特征包括了关键实践（KP），即每一个KPA包括5类KP
实现了这些KP后，就实现了关键过程域的目标
(2) CMMI与CMM的区别和联系，CMMI的两种表示方法。
---CMMI的两种表示方法：连续式，阶段式。
区别：连续式作为单一过程域或者过程域集合，阶段式作为整个组织已建立的一个过程域集合。CMMI和CMM区别在于：
I是intergration，集成的意思。CMM适用于软件的组织成熟度测评。CMMI适用于多种组织成熟度测评。CMMI相对CMM更完整，更适用于大环境。
2. PSP：结构，两种日志，评审比测试有效的原因，四个设计模板(要知道4个设计模板是什么，做什么，对应哪一个UML图哪一个)。
结构
日志---时间日志和缺陷日志
评审比测试有效的原因--在评审时发现的错误比测试是发现的多；成本低。缺陷发现的越早，修复的花费越低；且避免缺陷比发现和修复缺陷更有效。------------------------------------
四个设计模板---a操作规格模板，b功能规格模板,c状态规格模板,d逻辑规格模板
LST逻辑规格模板（无）：用于描述系统中各有机组分（方法，项，算法等）的逻辑实现。
SST状态规格模板（UML:时序图）：用于描述系统中所有可能发生的状态的集合，以及状态之间转换的条件，伴随的动作。。
FST功能规格模板（UML:类图）：描述了系统可以向用户提供对外部可见的行为说明书，以及与这些功能相关的系统行为，变量和内部关系（继承关系）。OST操作场景模板（UML:用例图）。描述了系统与外界的交互。描述了用户与待设计系统的正常情况下和异常情况下的交互。
3.MSF：六个角色；过程模型中的五个阶段。
MSF即微软的解决方案。团队是微软作战最小的基本单元。
项目场景中的6个角色：产品管理，程序管理，开发，测试，发布管理，用户体验。-------产程开测发用
5个阶段：构思阶段，计划阶段，开发阶段，稳定阶段，部署阶段。
------购计开稳部
4.RUP：九个软件过程(6+3)，四个阶段，六大经验。
（Rational Unified Process），统一软件开发过程,面对对象的软件工程的过程框架。
- 9个过程域：6个是核心3个是辅助：
6个核心过程流：商业建模，需求，分析和设计，实现，测试，部署。
3个辅助过程流：配置和变更管理，项目管理，环境。
(商分需设，实测部)----（培根项环）
- 4个阶段：初始，细化，构造，交付。(每个阶段做什么，做完的里程碑，中间产品是什么？)
|
|
主要活动 |
里程碑 |
中间产品 |
|
起始（先启/初始）阶段 |
² 建立系统的业务模型 ² 捕获系统的基本需求 ² 确定系统的边界 ² 识别关键任务 ² 确定系统验收标准 ² 进行项目风险评估 ² 进行项目资源的估计与效益分析 ² 制定项目开发计划于重要里程碑 |
生命期目标 |
² 项目蓝图文档：系统的核心需求、关键特性与主要约束 ² 初始的用例模型（完成10%~20%） ² 初始的项目术语表 ² 业务用例模型，包括商业环境、验收标准和财政预测 ² 初始的风险评估 ² 一个可以显示阶段和迭代的项目计划 ² 一个或多个原型 ² 初始的架构文档 |
|
细化阶段（最关键的阶段） |
² 细化构想，建立对大多数关键用例的确定理解 ² 分析问题域，建立坚实的架构 ² 细化机构并选择组件 ² 捕获80%的功能需求用例 ² 精化风险评估 ² 建立可执行的软件原型 ² 定义非功能需求 ² 制定过程迭代计划和迭代的评价标准 |
生命期构架 |
² 系统架构基线 ² UML静态模型、UML动态模型、UML用例模型 ² 修订的风险评估 ² 修订的用例 ² 修订的项目计划 ² 可执行的原型 |
|
构造阶段 |
² 资源管理、资源控制和过程优化 ² 完成组件开发并根据已定义的评价准则进行测试 ² 利用构想指定的准则对发布的产品进行评估 |
初始运作功能。 构造阶段的结束时项目开发的第三个重要的里程碑。这个阶段产生的版本通常被称为β版。 |
² 可运行的软件系统 ² UML模型 ² 测试用例 ² 用户手册 ² 发布描述 |
|
交付（转化、产品化）阶段 |
² 将软件系统部署到用户环境 ² 修复软件的缺陷 ² 编制用户手册和其他文档 ² 培训用户和维护人员 ² 提供用户咨询 |
产品发布 |
² 可运行的软件产品 ² 用户手册 ² 用户支持计划 |
六大经验---迭代式开发，管理需求，基于组件的体系结构，可视化建模，验证软件质量，控制软件变更------------------------------------------------------------------------
五、敏捷软件开发
1. 敏捷宣言--一字不差背住
敏捷宣言-----四个核心价值十二个原则：
“注重个人及互动胜于过程和工具”
“注重可用的软件胜于详尽的文档”
“注重客户协作胜于合同谈判”
“注重响应变化胜于恪守计划”
