复习的时候手打了一遍，为了不浪费正好发出来。
学弟学妹们...可以参考一下了
懂的都懂。。
第一章 软件过程基础（10分）
几位质量管理大师的主要贡献
经典软件过程及其特点
（看ppt吧）
第二章 PSP（25分）
PSP中的基本度量项
时间、缺陷、规模
PROBE估算的流程
概要设计、代理识别、估算并调整程序规模（时间）、计算预测区间
使用线性回归方法估算程序规模和资源
看ppt吧，有公式
相对大小矩阵
一般：最小值最为作为VS、最大值作为VL、中值作为M、VS与M的均值作为S、VL与M的均值作为L
正态：均值作为M、M - 标准差= S、M - 2 * 标准差= VS，M + 标准差 = L、M + 2 * 标准差 = VL
对数正态分布：取e为底的对数以后再求类比正态。
常用的PSP过程质量的度量指标
Yield：
Phase Yield = 100 * （某阶段发现缺陷数）/ （某阶段注入的缺陷数） + （进入前遗留缺陷数）
Process Yield = 100 * (第一次编译前发现的缺陷个数) / （第一次编译前注入的缺陷个数）
A/FR： = psp质检成本 / psp失效成本
失效成本：编译时间和单元测试时间之和
质检成本：设计评审时间与代码评审时间之和
值越大，质量越高
过高则影响效率，最佳为2.0
俩倍于编译+测试的时间进行评审
PQI（Process Quality Index）：过程质量指标
用来度量PSP过程的整体质量
用来全面刻画软件过程质量
五个过程质量指标的乘积：（0 到1 的值）
超过0.4，通常组件质量往往比较高
- 设计质量：设计时间大于编码时间
- 设计评审质量：设计评审时间大于设计50%
- 代码质量：代码编译缺陷密度小于10个/千行
- 代码评审质量：代码评审时间大于编码时间的50%
- 程序质量：代码的单元测试缺陷密度小于5个/千行
评审速度（Review Rate）：
代码评审速度小于200行/小时
文档评审速度小于4Page/小时
缺陷消除效率比：DRL(Defect-Removal Leverage)
其他阶段每小时发现缺陷数与该测试阶段（单元测试）每小时发现缺陷数的比值
代码评审往往高于单元测试
PSP四大设计模板以及与UML的对应关系
操作规格模板（OST Operational Specification Template）：
描述系统与外界的交互情形
功能规格模板（FST Functional Specification Template）：
描述系统对外的静态接口
状态规格模板（SST State Specification Template）：
描述系统的状态信息
逻辑规格模板（LST Logical Specification Template）
描述系统的静态逻辑
用例图、顺序图提供与OST同样的信息
类图只有方法构型，但无行为描述。PST有
LST描述程序的静态逻辑，UML中无
状态机图与SST类似，但是SST中描述关于状态、状态转换条件、以及状态转换中的动作没有对应的UML图示方法。
第三章 TSP（15分）
WBS工作分解结构
项目管理、项目需求、详细设计、构建、整合与测试
风险识别及风险应对
风险识别：
识别可能会给项目目标的实现带来负面影响的潜在问题，进行风险管理的基础
识别方法：
检查wbs组件
使用风险分类表来评估
访谈专家
风险应对：
识别风险后，应该指制定相应的风险管理策略
策略：
风险转嫁
风险解决
风险缓解
TSP团队项目规划流程
俩个过程：团队组建过程、团队工作过程（9个会议）
- 建立产品目标和业务目标
- 角色分配和小组目标定义
- 开发流程定义与策略选择
- 整体计划
- 质量计划
- 个人计划及计划分配
- 风险评估
- 准备向管理层汇报计划
- 向管理层汇报计划内容
纠偏活动
偏差原因分析
纠偏措施定义
纠偏措施管理
TSP总结过程
准备阶段、过程数据评价阶段、人员角色评价阶段、总结报告撰写阶段
典型的TSP角色及其主要工作内容
项目组长：
激励团队成员努力工作
主持项目周例会
每周汇报项目状态
分配工作任务
维护项目资料
组织项目总结
计划经理：
带领项目小组开发项目计划
带领项目小组平衡计划
跟踪项目进度
参与项目总结
开发经理：
带领团队指定开发策略
带领团队开展产品规模估算和所需时间资源的估算
带领团队开发需求规格说明
带领团队开发高层设计
带领团队开发设计规格说明
带领团队实现软件产品
带领团队开展集成测试和系统测试
带领团队开发用户支持文档
参与项目总结
质量经理：
带领团队开发和跟踪质量计划
向项目组长警示质量问题
软件产品提交配置管理前，对其评审，消除质量问题
充当项目小组评审的组织者和协调者
参与项目总结
过程经理：
带领团队定义和记录开发过程并且支持过程改进
建立和维护团队的开发标准
记录和维护团队的会议记录
参与项目总结
支持经理：
带领团队识别开发过程中所需要的各类工具和设施
支持配置管理委员会，管理配置管理系统
维护软件项目的词汇表
维护项目风险和问题跟踪系统
支持软件开发过程中复用策略的应用
参与项目总结
第四章-第六章 CMM和CMMI（25-30分）
CMM的基本概念和用途
对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述
能力成熟度模型，Capability Maturity Model for Software. SW-CMM
概念：
1、软件过程（Software Process）：人们在开发和维护软件及其相关产品时所涉及到的各种活动方法、实践和改革等。
2、软件过程能力（Software Process Capability）：当遵循某个软件过程时所能达到的期望效果，有效预测企业接受新项目时可能得到的结果
3、软件过程效能（Software Process Performance）：当遵循某个软件过程时所达到的实际效果，用于验证软件过程能力。
4、软件过程成熟度（software process maturity）：指一个特定的软件过程被明确定义、管理、度量、控制以及有效的程度。
5、软件工程过程组（software engineering process group）负责组织的软件过程活动的小组
用途：
- 用于软件过程评估（SPA， Software Process Assessment）
- 用于软件过程改进（SPI， Software Process Improvement）
- 用于软件能力评价（SCE， Software Capability Evaluation）
CMM五个级别的名称、特点和成熟度的行为刻画
- 初始级
- 主要特征
- 无秩序的，甚至有时混乱。软件过程定义几乎处于无章法和步骤可循的状态
- 成功往往取决于极个别人的努力和机遇。
- 行为刻画：
- 成功来源于个人英雄主义而非机构行为，因为它不可重复
- 跟换人员后成功便难以维持
- 初始级组织一般不提供开发和维护软件的稳定环境
- 特点
- 主要特征
- 可重复级
- 主要特征
- 已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的项目有章可循并能重复以往所取得的成功。
- 行为刻画：
- 过程已经建立，项目计划和跟踪是确定且有效的，项目的软件过程是可控的，以及已有的成功经验是可重复的。
- 建立过程
- 经验利用
- 具体项目
- 项目执行
- 项目跟踪
- 问题确定
- 基线完整
- 遵循标准
- 分承制方
- 在可重复级上，已建立管理软件项目的方针和实施这些方针的规程。基于类似项目上的经验，对新项目进行规划和管理
- 让软件项目的有效管理过程制度化
- 过程已经建立，项目计划和跟踪是确定且有效的，项目的软件过程是可控的，以及已有的成功经验是可重复的。
- 特点
- 主要特征
- 已定义级
- 主要特征
- 用于管理和工程的软件过程均已文档化、标准化。并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合、适当修改后的标准软件过程来进行操作
- 行为刻画
- 机构标准软件过程
- 软件过程组（SEPG组）
- 项目标准软件过程
- 过程内容
- 跟踪和控制
- 共同理解
- 主要特征
- 特点
- 主要特征
- 已管理级
- 主要特征：
- 定量化
- 可预测
- 异常控制
- 高质量
- 软件过程和产品质量均有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
- 行为刻画
- 软件的过程和产品有定量的质量指标
- 软件项目的产品生产过程的控制具有可预测性
- 主要特征：
- 优化级
- 主要特征：
- 新技术的采用
- 软件过程的改进
- 通过对来自过程、新概念和新技术等方面各种有用信息的定量分析，能够不断地、持续地对过程进行改进。
- 行为刻画
- 机构集中与持续的过程改进
- 改进的途径
- 对已有的渐进
- 有选择的使用新技术
- 主要特征：
18个KPA与5个级别的对应关系
KPA：Key Process Areas（关键过程域）
为了改进其软件过程组织应关注的区域
可重复级：
需求管理（requirement management）
目的：在客户和遵循客户需求的软件项目之间建立一种共同的理解。
目标：1控制指定给软件的系统需求，为软件工程和管理运用建立基线2保持系统需求在软件计划、产品和活动与指定的一致。
软件项目计划（software project planning）
目的：为实施软件工程和管理软件项目指定合理的计划，包括对要完成的工作进行评估、确定必要和制定工作计划。
目标：1形成软件估计文档2制定软件的活动和约定计划，并形成文档3相关小组和个人认同与项目相关的约定。
软件项目跟踪和监控（software project tracking oversight）
目的：能够随时掌握软件项目的实际开发过程，使得当软件项目的执行与软件计划相背离时，管理部门能够采取有效的措施。
目标：1依据软件计划对实际结果和过程运行效能进行跟踪。2当结果与过程差别大时，采取措施设法关闭3软件约定的更改经小组和个人的同意认可
软件子合同管理（software subcontract management）
目的：为了选择软件开发的合格的分承制方，并进行有效的管理
目标：1、主承制方选择合格的分承制方2俩方就彼此约定达成一致3俩方保持工作联系4主方根据约定跟踪分方的实际执行情况及其结果
软件质量保证（software quality assurance）
目的：为管理者提供有关项目过程和产品的适当的可见性
目标：1对软件质量保证活动做到有计划2客观的验证软件产品及其活动是否遵守应用的标准、规程和要求3将软件质量保证活动及其结果及时通知相关小组和个人4上级管理部门及时处理软件项目内部解决不了的不一致性问题
软件配置管理（software configuration management）
目的：保证软件项目生成的产品在软件生命周期中的完整性
目标:1软件配置管理活动是有计划的2所选择的软件工作产品是经过标识、收到控制并具有可用性3更改是可控的4让相关小组和个人及时了解软件基线的状态内容
已定义级：
组织过程焦点（organization process focus）
目的：为以能改进组织整体软件过程能力的软件过程活动建立组织的职责
目标：1组织内部软件过程的制定和改进活动协调一致2相对于过程标准，所使用的软件过程的优势和薄弱环节标识清楚3组织的过程开发和改进活动有计划
组织过程定义（organization process definition）
目的：开发和维护一个可用的软件过程资源集，以提高各项目的软件过程效能，以积累的方式使项目长期收益
目标：1开发和维护一个组织标准软件过程2收集、评审供软件项目使用的组织标准过程的相关信息，使之可用。
培训大纲（training program）
目的：提高个人的知识和技能，使其有效地履行职责
目标：1培训活动是有计划的2提供完成软件管理的记述人物所需的知识与技能培训3软件工程组和软件相关小组中的成员收到所需的培训
集成软件管理（integrated software management）
目的：将软件工程和管理活动结合成为密切相关的、定义完整的软件过程。该软件过程从机构标准软件过程和相关过程资源中剪裁而来。
目标：1项目定义的软件过程是机构标准软件过程的剪裁版2依据项目定义的软件过程对项目进行计划和管理
软件产品工程（software product engineering）
目的：是为了一致地执行一个经过完整定义的工程过程，该过程综合了所有软件工程活动，以便高效生产出正确而一致的软件产品。
目标：1定义和综合各软件工程任务，并在生产软件的过程中始终如一地执行这些任务2软件工作产品彼此间保持一致性
组间协调（intergroup coordination）
目的：为建立一种工作方式，使软件工程组与其他小组能积极协作，从而使项目能更好、更有效地满足客户需求。
目标：1客户需求经所有相关小组通过2各工程组之间的约定经相关小组同意3各工程组识别、跟踪和解决组间问题。
同行评审（peer review）
目的：是为了尽早而有效地排除软件工作产品中的缺陷，一个重要的必然结果是对软件工作产品和可预防的缺陷有更好的理解。
目标：1计划同行平生活动2识别和排除软件产品中的缺陷
已管理级：
定量质量管理（quantitative process management）
目的：为了定量的控制软件项目的过程运行效能，软件过程运行效能用来标识遵循软件过程所达到的实际效果。
目标：1定量过程管理活动是有计划的2定量地控制项目定义软件过程的过程运行效能3机构标准过程的过程能力能定量地区分
软件质量管理（software quantity management）
目的：为了定量了解项目的软件产品的质量，并实现具体的质量目标。
目标：1项目的软件质量管理活动是有计划的2软件产品质量的可测目标和目标的优先级被定义3实现软件产品质量目标的实际进展过程被量化管理
优化级：
缺陷预防（defect prevetion）
目的：分析项目开发中遇到的缺陷的来源并设法防止其发生。这些缺陷包括当前项目中被发现的缺陷和其他项目中的缺陷。
目标：1对缺陷预防活动做出的计划2找出和标识缺陷的原因3将缺陷的原因按照优先级排序，并系统地消除
技术改革管理（technology change management）
目的：识别新技术（如工具、方法和过程），并有序地将这些技术引入到机构内
目标：1有计划的地进行技术更新2评价新技术，确定他们对质量和生产率的影响3将适用的新技术转到机构的正常实践中
过程更改管理（process change management）
目的：不断改进机构中所使用的软件过程，从而提高软件质量和生产率，缩短产品开发周期。
目标：1有实施持续的过程改进的计划2机构范围内的人员都参与机构的软件过程改进活动3持续地改进机构标注软件过程和项目定义的软件过程。
CMMI的五个级别以及CMM的区别
主要区别是覆盖了更多领域：1软件工程（SW-CMM）2系统过程（SE-CMM）3集成的产品和过程开发（IPPD-CMM）4采购（SS-CMM）
CMMI：capability maturity model – integration
软件能力成熟度集成模型
将系统工程和软件工程集成在一起
将系统学科和软件学科集成为一个过程改进框架
1、初始级（Initial）
2、已管理级（Managed）
CMMI多一个度量与分析
3、已定义级（Defined）
CMMI多一个风险管理
CMM集成软件管理 、组间协调 = 集成化项目管理
CMM软件产品工程 = 需求开发、技术解决方案、产品集成
CMM同行评审 = 验证 、确认
4、量化管理级（Quantitatively Managed）
5、持续优化级（Optimizing）
缺陷预防 = 因果分析和解决方案
技术变更管理 = 组织改革和部署
CMM多一个过程变更管理
软件估算（10-15分）
- 如果项目是全新的或者没有历史数据，建议使用自底向上方法
- 设计软件、编写软件代码、测试软件将最难估算工作量
- 自顶向下: effort = 系统规模 * 生产率
- 专家判断：对原有系统进行替换的时候有用
- 类比估计（基于案例的推理），利用欧几里得公式，找到与待测项目最相近的项目。
- COCOMO：Constructive Cost Model构造性成本模型
计算规模因素的质量：
1、先前经验
2、开发的灵活性
3、体系结构/风险解决
4、团队的凝聚性
5、过程的成熟型
规模因素sf = 1.01 + 0.01 * (a + b + c + d + e)
Scrum敏捷开发过程（10分）
Scrum:一个轻量级的敏捷软件开发方法。
依赖迭代和增量的敏捷方法
是一种工作管理方法，不包含技术方法或实践
基本过程：
划分为多个迭代过程，称为冲刺（sprint）2-4周
每一个sprint的时间是固定的
每一个sprint都可以产生可交付的迭代产品
Scrum项目阶段划分：
规划（产品定义）
运行sprint 所需要的准备、规划和技术分析
执行（执行sprint）
在增量时间段内实现需求
结束
准备最终发布，结束项目
角色分为猪角色和鸡角色
猪角色：全身投入项目和scrum过程的人
产品负责人（Product Owner）：多为产品经理担任，某些情况下是客户本人
Scrum Master：整个团队的导师和组织者，负责提高团队的开发效率
开发团队（Scrum Team）：中心角色，负责交付产品的团队，5-9名具有跨技能的人组成。角色不分等级，职能交叉，按照最有利于项目原则分担责任
鸡角色：只参与
客户：产品的最终用户
管理层：公司高级管理层
Scrum文档
产品订单（Product Backlog） / 用户故事（User Stories）
整个项目的概要文档，天为单位
冲刺订单（Sprint Backlog） / 迭代任务清单
产品订单的细化子集，小时为单位
每一个任务不超过16小时，如果大，则进一步分解
团队成员签名认领
燃尽图（Burndown Chart）
显示当前冲刺中未完成的任务数目，或者在冲刺订单上未完成的订单项的数目
Sprint常见活动
冲刺计划会议（Sprint Planning Meeting）：
每个冲刺之初，产品负责人讲解需求，开发团队进行估算的计划会议
参加人员：产品负责人、Scrum Master、Scrum开发团队和其他感兴趣的人
目的：知道工作
每日站立会议（Daily Standup Meeting）：
团队每天进行沟通的内部短会，15分钟站立
每天早上开，时间控制到15分钟之内
Scrum Master主持，只有团队成员发言，回答昨天完成了啥，今天要做啥，遇到啥障碍。
更新燃尽图
评审会议（Review Meeting）：
冲刺结束前给产品负责人演示并接受评价的会议
使用演示形式展示新功能或者底层架构的实现
回顾会议（Retrospective Meeting）：
在冲刺结束后召开的关于自我持续改进的会议
周期性的回顾
整个团队都需要参加
总结会议
目的：团队工作方式检查和自适应
每次迭代回顾后召开，1-2小时
整个团队参加
任务看板：
一种使用可视化管理的方式，跟踪任务在整个价值流中流经的不同阶段
每人使用一种专用颜色标签纸
计划纸牌：
防止项目在开发过程中被某些人左右
用来估算规模