- 项目估算的能力
- 有较强的沟通协调能力
- 风险识别、分析、管理的能力
- 项目策划的能力
- 进度及预算编制的能力
- 项目监控与管理的能力
- 具体需求管理的能力
9、基线、版本、存储的定义
- 基线：是由一个或多个配置项组成的逻辑实体，并可以作为进一步开发的基础。组成基线的配置项需要经过正式的评审和批准、正式的变更控制规程。通过评审的文档、开发文档，以及通过测试的，例如：代码、计划（策划阶段）
- 版本：
- 存储：工作记录，例如：会议纪要、报告
11、项目级Car基本改进原则：
- 项目执行中，当前性能目标无法达到现有组织过程性能。
- 项目执行中，出现的缺陷或问题等导致与当前组织过程绩效出现严重偏差，明显影响项目绩效。
- 工作产品与需求出现明显的偏离。
12、确定软件开发生命周期模型的参考规则
- 偏差不大于20%（项目可控）
- 交付产品通过审批或验证
- 里程碑内主要工作完成。
14、 软件项目风险管理规则
- 风险类别有：人员、客户、管理、质量、测试、环境等；
- 风险系数有：高、中、低；
- 风险发生概率和风险影响范围分别1～5分。
三、项目策划实践
1、项目策划实践过程简述
我在试点项目中的，策划过程如下图所示，其中包含过程中的输入、输出，以及参与的角色。
2、流程中关键点说明：
⑴、项目实施计划内容：
项目的章程、项目概况、项目组构成及人力资源计划、项目预算及进度计划、干系人参与计划、其他下属计划（度量分析计划以及数据管理计划、项目监控计划、需求管理计划、决策分析计划、项目评审计划、承诺管理等子计划）。
a.如何使用资产库和历史数据？做估算、计划。
- 过程裁剪指南、软件生命周期指南、标准工作环境指南、团队指南等、风险库；
- 开发过程定义（PDP）
- 生产率、估算模型、工作分配比例、人员技能水平。
b.估算参数：代码行、页码、缺陷密度；质量参数：缺陷清除率、缺陷数；
c.文档（需求、设计等技术文档）是按类比法进行估算（页码），参考规定相当的度量库，再通过页数转换为工作量（转换模型）；
d.采用Delphi（专家法）估算代码行数，额定偏差为20%；
e.项目管理占比为10～15%，预留5%，QA%5～6、CM3～4%。
本项目采用瀑布模型，在需求比较明确、文档，复杂度较低情况下采用，思路、路径清晰，但是前期出现的问题，在后期会方法；
需求阶段、设计阶段、编码及单元测试阶段、集成测试阶段、系统测试阶段、验收测试阶段，其中，需求、编码及单元测试、系统测试、验收测试为里程碑。
⑷、估算成本、估算假设
估算成本由工作量（人工成本）、差旅、采购等成本构成。
- 团队水平高于平均水平，包括环境、士气；
- 需求变更范围很小；
- 技术复杂度低。
Budget——指标/人天（成本）
任务分解（WBS）->网络图（前置、后期任务）->分配资源->估算任务（征询当事人的意见）->资源平衡 ->设定里程碑。
⑹、人力资源计划
根据项目工期、工作量、沟通工作，按项目时间进度来安排项目人员进出。
- 识别项目需要技能、业务知识，例如此项目需要Cordys平台开发技术；
- 根据人员技术，进行差距分析，例如有部分人员缺乏Cordys平台开发技术；
- 根据差异制定培训计划。
⑺、软、硬件资源及其环境
- 组织级工作环境提供了标准办公环境，例如工作终端、配置库等；
- 项目特有环境，例如：开发服务器。
3、关键过程举例说明
⑴、项目过程定义（过程剪裁）
在项目过程定义中，在项目级QA的协助下，参考《组织过程裁剪指南》和《软件生命周期》裁剪定制适合于项目的生命周期模型，制定《项目定义过程》。例如：接口设计过程，在项目定义中剪裁到详细设计文档中体现。
⑵、如何管理项目计划？
- 管理项目计划包括渐进明细维护项目计划，与组员及时沟通计划完成情况，以及通过周例会、周报、报工系统收集计划完成情况和进度，并通过挣值分析分析项目的偏差，也通过周例会收集风险、问题，及时跟踪；
- 通过挣值分析管理项目进度、成本偏差；
- 问题管理，识别问题、跟踪问题、关闭问题。
⑶、如何评价团队的有效性，如何构建项目团队的？
- 组织团队指南；
- 在项目启动时，项目通知中初步提供人员；
- 按项目实施计划模版，制定人力资源计划，对人员进行分工（项目经理、开发人员、QA、CM）。
⑷、什么地方记录了项目干系人，如何确保干系人参与有效？
- 在项目实施计划中干系人管理计划中，干系人沟通记录；
- 在与干系人沟通时，事前通知，事中控制、确认，事后分析。
⑸、项目关键依赖
依赖客户，需要客户提供需求和需求确认，以及系统部署、验收测试。
四、量化管理及监控（QPM）实践
1、度量点、统计技术的选择准则：
度量点选择准则：
（1） 与商业目标有关的度量点；
（2） 度量点能覆盖项目生命周期；
（3） 度量是能够被有效地正确地收集；
（4） 度量点是客观的；
（5） 度量点有足够的历史数据;
（6）通过改变过程或子过程，度量点是可控制的；
统计技术的选择准则：
（1）根据度量点的数据类型选择统计技术，X/Y都是连续型变量，则选择相关性分析和回归分析；
（2）根据度量点的单值性，选择单值-移动极差I-MR控制图.
⑴、量化执行过程图
⑵、MiniTab回归预测
在每个子过程的前后，都需要进行回归预测，例如需求评审前，预测需求评审缺陷移除率（RR_Defect）是否在基线范围内（PPB-PPM），预测输入是：
- （RR_Size ）需求评审文档正文页数（单位：页）；
- （RR_Workload） 需求评审投入工作量（单位：人天）；
- （RR_TL） 需求评审高级人员比例
在需求启动和各个子过程阶段后，使用CB:OptQuest，根据项目过程性能目标选择最佳的过程或子过程的组合。选择完之后将最佳方案的实现概率填写到QPMPlan中。
3、量化管理结果达成规则（QPPO冲突）
- 达成概率>95%，接受
- 90—95%，关注风险，有10%-5%的概率达不到
- <90%，协商（降低目标，不降低也只能接受，当风险管理）谈判
补充：工作量（成本）是限定条件，量化管理就是达成成本与质量的平衡，综合考虑，达到较好的性价比。如果，不满足综合性价比，则可以进行决策分析。
4、度量点在什么时候发生变化：
QPPO发生变化，过程发生变化，公司要求度量额外信息，导致度量点的变化，客户提出的要求（个性化的要求，例如非标准度量要求）。
使用统计过程控制技术，对每一次评审的性能进行监控。如果在子过程性能监控中发现过程不稳定时，需要分析异常原因，并且采取纠正措施。
- 不能超过上下限；
- 不能出现连续7个上升；
- 在规格线之间表示有能力。
6、量化项目管理问题记录
需要仔细分析量化项目管理问题记录，包括原因及异常说明、应对措施、实施效果、图表说明、固化措施（提交到EPG），详细内容略。
7、开发过程量化分析与评审过程量化分析差异
⑴、 预测缺陷注入率(RD_DIRSD_DIRCD_DIR)
在项目需求开发前获取RD_Effort和RD_DE，使用Minitab中RD_DIR回归公式预测RD_DIR的预测值、上限值和下限值，如果预测值不在基线范围内，则需要调整RD_Effort和RD_DE，并重新预测。将调整后的因子和预测值填入需求开发前调整列。把RD_DIR的最新预测值定义成三角分布。
⑵、评审过程使用Minitab线性回归预测缺陷移除率（DRR）在PPB-PPM范围内
五、原因分析与解决过程实践
1、触发条件（入口准则）
在量化分析子过程过程中，发生未达能力问题时，在调整因子或优化路径情况下，无法达成QPPO，则根据体系文件《原因分析与解决过程》所规定的入口准则，启动根因分析，由项目经理编制根因分析实施计划。
工作中，发生计划等活动中未预测到的事件（问题或好的方法），触发根因分析，根因分析要使用预测模型。
⑴、确定原因分析的范围
⑵、分析原因，确定建议的改进措施
项目组（经理）组织项目相关人员，同样采用鱼骨图（鱼骨图至少应分解到第三层）和Pareto图等技术，分析问题和缺陷的根本原因，并制定改进措施。
⑶、制定行动计划
项目经理制定计划，经EPG批准后执行。
⑷、实施改进建议
项目组（经理）组织项目相关人员，在项目级QA的指导下，执行项目改进措施及建议。
⑸、评价实施效果
对项目单元测试过程进行分析，分析单元测试缺陷移除率低的原因，并制定改进实施方案。
H－高，M－中，L－低；
●－实施，○－暂缓实施，△－不实施
通过改进方案的实施：
- 经过单元测试用例的重新梳理及测试用例评审提高单元测试用例的质量；
- 通过重新测试保证测试的充分性，提高代码质量。
- 重新整理单元测试用例
- 单元测试用例评审
- 对单元测试缺陷移除率低的模块进行重新测试，并对后续模块进行测试
- 跟踪执行效果
- 进行效果评价
5、CAR实施效果评价报告
⑴、效果分析说明：
●统计分析结果说明：通过本次原因分析与解决工作的实施，改进前与改进后的RR_DRR改进效果说明如下：
- 如上图所示：CAR方案实施后，后续的单元测试模块过程过程能力也得控制，稳定性也得到显著提高。
- 因此判定本次CAR的执行有效。
⑵、固化改进成果
- 单元测试用例的质量对于单元测试过程至关重要，因此要加强单元测试用例的评审；
- 修改编码与测试过程，删除编码与测试过程中单元测试用例可不进行评审的描述。
六、决策分析过程实践
1、输入：组织级过程体系文件《决策分析过程》、《决策分析指南》
此次（项目仅有一次）评估方法为专家打分法（Delphi）。
评估常用方法有：SWOT分析、头脑风暴法、决策树分析法。
- 方案一：自主开发消息管理
- 方案二：采用第三方消息中间件（IBM MQ）
5 、实施过程与计划
项目经理根据项目前期的需求和方案，识别出两套技术解决方案，根据组织级过程体系文件《决策分析过程》、《决策分析指南》和入口准则，编制“决策分析计划”，计划内容包括（开始时间为3月28日）：
- 决策问题描述：
- 制定决策分析计划：
- 成立决策小组：小组由项目组成员、项目QA、项目经理构成；
- 建立评估准则：根据待决策问题的特征，确定明确的评估准则和评分标准，填写评估准则列表；
- 识别候选方案：寻找潜在的候选解决方案，填写候选方案列表
- 确定评估方法：
- 评选候选方案：
- 完成决策分析：根据评估结果确定最终方案，填写决策分析报告。
根据两种方案评估结果和可接受准则：方案一得分最高，并且评估项1达到60分，所以选择方案一。
风险：对现有系统改造，改造质量影响系统稳定运行；应对措施：引入了代码自动化检查工具及测试工具，提升代码质量
七、项目监控实践
项目监控(Project Monitoringand ControlPMC)的目的是通过周期性地跟踪项目计划的各种参数，如进度、工作量、资源、工作成果等，并不断的了解项目进展情况，以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施。
- 过程体系文件《项目监控过程》
- 模版：个人工作周报、项目工作周报、里程碑报告、例会会议纪要、外部干系人管理记录
- 项目计划已发布。
- 项目组人员已到位，并得到相关培训。
- 项目实施计划
- 项目进度计划
- 质量保证计划与跟踪表
- 配置管理计划与跟踪表
- 风险管理跟踪表
- 项目进度计划（已更新）
- 个人工作周报
- 项目工作周报
- 项目度量数据库
- 里程碑报告
- 例会会议纪要
- 里程碑评审会议纪要
- 风险管理跟踪表（已更新）
- 外部干系人管理记录
以项目例会为例，在例会上监控内容和点如下：
- 工作进度及完成工作量，识别项目偏差并分析；
- 识别问题并分析问题；
- 识别风险并跟踪风险，对项目风险进行规避，直至关闭；
- 按进度计划，安排组员的具体任务（TFS），并协调相关任务；
- QA监控过程符合状况；
- 进行干系人计划跟踪，组织干系人参与里程碑会议和其他讨论会。
- 项目性能度量:监控项目性能，保证项目能够按计划要求完成项目任务
- 产品质量度量:监控项目产品工作质量，保证项目能够高质量地完成
- 需求变更度量:监控项目需求稳定性，保证通过需求管理及需求开发活动，减少需求变更
- 过程质量度量:监控项目过程质量，保证QA人员能够了解项目成员对过程的遵守程度，识别不符合项高的过程加以指导和审计
- 项目规模度量:监控项目的规模，识别估计规模和实际规模的偏差
- 其它度量数据:监控各阶段的评审和测试方式、资源投入、人员水平、各过程的复用率、覆盖率、按期交付率
- PV：计划工作量的预算成本
- EV：已经完成工作量的预算成本
- AC：已经完成工作量的实际成本。
- 进度偏差率(SV%)：进度偏差SV（SV=EV-PV）与计划工时的预算成本BCWS（PV）之间的比值
- 成本偏差率(CV%)：成本差异CV（CV=EV-AC）与已完成工时的预算成本BCWP（EV）的比值
- 进度性能指标(SPI)
- 成本性能指标(CPI)
2、度量数据收集来源
- 报工系统
- 技术评审报告
- 各类测试报告
- 周例会
3、度量数据记录在度量数据库里
度量分析主要是在度量数据库和里程碑报告中，结项报告是引用度量报告。
九、项目风险管理实践
1、概述（基本概念补充）
⑴、风险应对策略
风险应对策略就是对已经识别的风险进行定性分析、定量分析和进行风险排序，制订相应的应对措施和整体策略。
- 风险规避：是改变项目计划来消除特定风险事件的威胁。例如，对于开发过程中存在的技术风险，我们可以采用成熟的技术，团队成员熟悉的技术或迭代式的开发过程等方法来规避风险。
- 风险转移：是转移风险的后果给第三方，通过合同的约定，由保证策略或者供应商担保。
- 风险减轻：是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在项目的早期采取风险减轻策略可以收到更好的效果。
- 风险接受：准备应对风险事件，包括积极的开发应急计划，或者消极的接受风险的后果。对于不可预见的风险，例如不可抗力；或者在风险规避，风险转移或者风险减轻不可行，或者上述活动执行成本超过接受风险的情况下采用。
来自那些不好的事情，或者是造成潜在问题的源头：
- 不稳定的需求
- 复杂、不成熟的技术
- 过多的接口
- 客户的配合情况
- 团队技术水平低
（ 来源于公司资产库——风险库，项目个性化情况。 ）
在风险管理指南中，风险分类定义有：需求、设计、编码、测试、开发环境、人员、客户、管理、质量、商业（市场）、其他。
2、识别风险与风险分析
项目经理针对项目情况，综合考虑项目成本、进度、质量、范围等因素，项目经理组织风险分析小组进行识别风险活动，并将识别结果及时更新到《风险管理跟踪表》中。
在识别风险过程中，需要明确风险项、风险来源、风险类别等要素，并参考《风险数据库》。
风险识别方式：头脑风暴法、假设法、访谈法、文档审查法等。
项目经理根据项目情况，组织风险分析小组对风险进行定性分析，确定每个风险项的“风险发生概率”、“风险影响范围”，计算出风险系数，并及时更新到《风险管理跟踪表》。
（风险系数=风险发生概率×风险影响范围。）
- 风险影响范围包括：范围、成本、进度、质量等项，每项分为1～5级（例如成本5级划分如下：小于5%的成本增加、5%～10%的成本增加、11%～20%的成本增加、21%～30%的成本增加、大于30%的成本增加）。
- 风险发生概率也分成5级
3、风险应对措施/计划
- 首先，参考公司资产库中的风险库（风险列表），公司以往最佳实践所提供的应对措施，业界常用的应对措施；
- 接着，是团队的智慧，大家讨论。
例如：在实施计划中安排培训计划，减轻人力资源不足、不稳定的风险。
4、如何跟踪风险，跟踪哪些？
按项目实施计划，通过项目周例会，在风险跟踪管理表上进行跟踪风险。
- 跟踪开放状态风险及其应对措施
- 跟踪重新分析
- 不断识别新风险
风险跟踪记录在风险跟踪管理表中。
5、举例说明本项目风险跟踪情况
本项目识别出8个风险项，主要风险是：
- 人力资源不足,资源负载严重，可能影响项目进度、质量，来源是不稳定的团队；
- 不能按进度计划要求完成项目开发各阶段任务，来源是技术不成熟。
十、技术评审与测试
- 评审规模、规模单位（例如页数）
- 预评审工作量（人时）
- 评审人数
- 评审总工作量
- 缺陷数量
3、评审缺陷分类、等级
- 遗漏（M）：Missing，工作产品遗漏了必要的内容。
- 错误（W）：Wrong，工作产品存在错误。
- 其它（E）：Extra，其它不属于以上两类的缺陷。
⑵、缺陷等级（DefectSeverity）:
- 致命缺陷（A）：指被评审的工作产品存在结构上或内容上的缺陷，如果不进行修正后续的工作无法开展或造成软件存在功能上的缺陷。
- 严重缺陷（B）：指被评审的工作产品存在内容上的缺陷，如果不进行修正后续的工作可能产生更为严重的缺陷。
- 一般缺陷（C）：指被评审的工作产品存在内容上的缺陷，如果不进行修正后续的工作基本不受影响，但可能对最终的软件产品质量造成一定影响。
- 轻微缺陷（D）：指被评审的工作产品存在文字、规范等方面的缺陷，不会对最终的软件产品质量造成影响。
十一、软件开发过程中的知识点
1、需求跟踪矩阵的两个作用
跟踪管理需求变更；
跟踪需求实现完全覆盖，保证需求与输出产品完整一致。
2、需求变更评价及其影响分析
需求变更接受后，将涉及到计划调整，一般工期影响不大，主要是成本。
⑴、 变更影响分析报告
- 变更申请->变更分析->变更审批->变更执行->变更验证-> 重新入库与发布
- 变更起止时间、状态（开放、关闭）
3、变更影响值分析规则
- 如果级别为1，需要由CCB审批后才可执行；
- 如果级别为2，需要CCB组长审批后即可执行；
- 如果级别为3，只要项目经理审批就可执行。
十二、过程建议及贡献
1、建议采用商用级代码检查和自动化测试工具
例如：业界发明了程序静态分析（Program StaticAnalysis）技术，静态分析是指在不运行代码的方式下，通过词法分析、语法分析、控制流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析技术。它可以帮助软件开发人员、质量保证人员查找代码中存在的结构性错误、安全漏洞和代码缺陷等问题，从而保证软件的整体质量。静态分析的特点是能够在代码研发的全周期协助开发人员优化代码，缩短项目周期，降低研发成本，提高代码质量。
建议采用商用软件Klocwork Insight。
2、项目贡献（对EPG贡献）
- 项目度量数据
- 项目经验教训（包括好的经验、不好的教训）
- 复用代码
- 好的工作产品，例如设计、架构
- CAR的输出
⑵、经验教训举例