在软件项目管理中，总是把估计值当作承诺，无论是对自已或对同事，都会造成不必要的焦虑。为避免此类困境，就算最后期限迫在眉睫，你也能专注于该做的事。然而也应该做到随时沟通，让相关人员看到事情进展。
项目管理过程方针：规范产品/项目立项和结项过程，制定合理的项目计划，并据此对项目进行跟踪，建立对项目监控的可视性，使项目管理者能在项目执行明显偏离项目计划时及时采取有效的纠正措施。
CMMI由如下内容构成，组织级体系文件、工作指南、证据；在工作中处理问题原则，识别问题、跟踪问题、解决问题、关闭问题。
一、关于访谈
1、访谈问题类型及回答方法
提问类型有：如何（How）、什么（What）、分析、有没有、是否等类型。
回答方法有：
⑴、输入条件、前提=>过程描述=>输出产品
⑵、事前预测=>事中控制=>事后分析
⑶、制度（或体系）已经存在=>被使用=>被一致执行=>改进，形成闭环
⑷、回答问题关键词：依据软件开发过程体系文件（或指南）、受过培训、经过评审、发布通知（例会、报给项目经理）
⑸、结合实际项目回答。
2、访谈内容关键点
计划、评审、度量、量化管理、风险、决策分析。
⑴、量化分析技术
量化管理技术：统计过程控制技术、蒙特卡洛分析技术、多目标决策分析技术
⑵、量化分析工具
MiniTab、CrystarBall
3、什么是过程？
过程是为了达到特定目标所实施的一系统活动或步骤。一个标准的过程应该包括：
目标/目的（Purpose）
角色与职责（Role and Responsibility）
入口准则（Entry Criteria）
出口准则（Exit Criteria）
输入（Inputs）
输出（Outputs）
流程图及活动说明（Activities）
度量（Measures）
验证（Verification）
4、过程域
⑴、项目管理主要7个过程域
⑵、基本项目管理过程域模型
⑶、高级项目管理过程域模型
5、评审方法
在体系文件《技术评审过程》中定义了评审方法。
审查（Inspection），通常是由经过技术评审培训的项目经理或PPQA主持，规模在3～7人之间为宜，一般在完成了一个工作产品后对其进行的评审
轮查（EmailRouting），通常由技术负责人或项目经理召集，一般三人以上参加。目的在于通过对开发人员的工作产品的技术审查，提出改进意见
走查（Walkthrough），审查的范围根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。通常是小型讨论会，一般是在工作产品形成的早期进行，作者有一定的想法时，希望从中获得一些帮助或补充一些想法。当然也可以在编制工作产品的任何阶段进行，两三个人参加，由作者主持，主要是评估和提高工作产品的质量
二、准则、依据
1、风险的管理策略：
a. 当风险系数(高)在16~25之间，必须制定应急计划，并且随时监控风险变化情况，一旦风险发生，则立刻启动应急计划。
b. 当风险系数(中)在 9~15之间，可不制定应急计划，定期监控风险变更情况，随时准备启动缓解措施。
c. 当风险系数(低)在 1~8之间，可不制定应急计划，定期监控风险变更情况，必要时启动缓解措施。
注：对于部分低风险，可选择接受。
2、项目QPPO下达：
经营管理部立项审批时下达，基于内部环境(例如：基线)与外部环境(例如：客户要求)的考虑，项目经理在QA的协助下，预测项目QPPO达成率：
若QPPO达成率 〉95 ，则接受
若QPPO达成率在 90-95之间， 则将其纳入风险进行监控与管理
若QPPO达成率 < 90 ,则与管理层进行谈判、沟通，是否可以降低目标，如果降低，则重新进行QPPO达成率预测；否则则接受，并纳入风险进行监控
3、评审通过准则：
评审出缺陷数满足要求。
4、评审准则（以需求为例）：
依据《技术评审检查列表》中“用户需求说明书检查单”，主要有：完整性、一致性、描述清晰性等9项检查点。
5、任务分解准则（WBS）：
依据《项目定义过程》、《项目估算报告》、《项目实施计划》、《项目进度计划模版》等过程体系文件和指南，任务分解准则如下：
⑴、WBS分解分类：项目分解WBS（项目管理类型任务分解）、技术分解WBS（项目工程任务及特有技术工作内容分解）。
⑵、WBS分解原则：
项目要求；
定义逐步求精；
人时（工作量）：一般的任务不超过2周，也就是80人时；
任务责任到人；
团队工作原则：项目经理在制定项目计划过程中，尤其是在任务分解，工期估计对关键过程中一定要与项目成员一起进行。
6、评审员的选择准则：
在要评审的领域拥有丰富经验。
具备专业技术知识。
能够有效识别待评审工作产品中存在的缺陷。
7、评审度量指标
评审活动的工时及工作量
评审发现的缺陷数（按严重程度及类型）
评审产品的规模
8、项目经理技能
项目估算的能力
有较强的沟通协调能力
风险识别、分析、管理的能力
项目策划的能力
进度及预算编制的能力
项目监控与管理的能力
具体需求管理的能力
9、基线、版本、存储的定义
基线：是由一个或多个配置项组成的逻辑实体，并可以作为进一步开发的基础。组成基线的配置项需要经过正式的评审和批准、正式的变更控制规程。通过评审的文档、开发文档，以及通过测试的，例如：代码、计划（策划阶段）
版本：
存储：工作记录，例如：会议纪要、报告
11、项目级Car基本改进原则：
项目执行中，当前性能目标无法达到现有组织过程性能。
项目执行中，出现的缺陷或问题等导致与当前组织过程绩效出现严重偏差，明显影响项目绩效。
工作产品与需求出现明显的偏离。
12、确定软件开发生命周期模型的参考规则
13、完成里程碑成果的准则：
偏差不大于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控制图.
2、量化过程
⑴、量化执行过程图
量化优化路径说明：
⑵、MiniTab回归预测
在每个子过程的前后，都需要进行回归预测，例如需求评审前，预测需求评审缺陷移除率（RR_Defect）是否在基线范围内（PPB-PPM），预测输入是：
（RR_Size ）需求评审文档正文页数（单位：页）；
（RR_Workload） 需求评审投入工作量（单位：人天）；
（RR_TL） 需求评审高级人员比例
⑶、蒙特卡洛模拟分析（水晶球）
在需求启动和各个子过程阶段后，使用CB:OptQuest，根据项目过程性能目标选择最佳的过程或子过程的组合。选择完之后将最佳方案的实现概率填写到QPMPlan中。
3、量化管理结果达成规则（QPPO冲突）
达成概率>95%，接受
90—95%，关注风险，有10%-5%的概率达不到
<90%，协商（降低目标，不降低也只能接受，当风险管理）谈判
补充：工作量（成本）是限定条件，量化管理就是达成成本与质量的平衡，综合考虑，达到较好的性价比。如果，不满足综合性价比，则可以进行决策分析。
4、度量点在什么时候发生变化：
QPPO发生变化，过程发生变化，公司要求度量额外信息，导致度量点的变化，客户提出的要求（个性化的要求，例如非标准度量要求）。
5、过程性能监控
使用统计过程控制技术，对每一次评审的性能进行监控。如果在子过程性能监控中发现过程不稳定时，需要分析异常原因，并且采取纠正措施。
过程性能监控说明子过程稳定性和有能力规则如下：
不能超过上下限；
不能出现连续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，则根据体系文件《原因分析与解决过程》所规定的入口准则，启动根因分析，由项目经理编制根因分析实施计划。
工作中，发生计划等活动中未预测到的事件（问题或好的方法），触发根因分析，根因分析要使用预测模型。
2、过程
⑴、确定原因分析的范围
⑵、分析原因，确定建议的改进措施
项目组（经理）组织项目相关人员，同样采用鱼骨图（鱼骨图至少应分解到第三层）和Pareto图等技术，分析问题和缺陷的根本原因，并制定改进措施。
⑶、制定行动计划
项目经理制定计划，经EPG批准后执行。
⑷、实施改进建议
项目组（经理）组织项目相关人员，在项目级QA的指导下，执行项目改进措施及建议。
⑸、评价实施效果
3、根因分析实践
对项目单元测试过程进行分析，分析单元测试缺陷移除率低的原因，并制定改进实施方案。
⑴、要因分析：
对输入、工具、人员、管理、过程、环境等原因，逐级深化分析，根因分析目标就是鱼头（UT_DRR低，单元测试缺陷移除率低的问题）。
⑵、做Pareto分析图表
按二八原则，80%的问题是由于20%原因造成的，选出20%的问题进行改进方案。
⑶、应对方案
说明：AP－Action Proposal，行动方案；
H－高，M－中，L－低；
●－实施，○－暂缓实施，△－不实施
4、改进实施方案
●方案目标
通过改进方案的实施：
经过单元测试用例的重新梳理及测试用例评审提高单元测试用例的质量；
通过重新测试保证测试的充分性，提高代码质量。
●活动名称
重新整理单元测试用例
单元测试用例评审
对单元测试缺陷移除率低的模块进行重新测试，并对后续模块进行测试
跟踪执行效果
进行效果评价
5、CAR实施效果评价报告
⑴、效果分析说明：
●统计分析结果说明：通过本次原因分析与解决工作的实施，改进前与改进后的RR_DRR改进效果说明如下：
●分析结论：
如上图所示：CAR方案实施后，后续的单元测试模块过程过程能力也得控制，稳定性也得到显著提高。
因此判定本次CAR的执行有效。
⑵、固化改进成果
单元测试用例的质量对于单元测试过程至关重要，因此要加强单元测试用例的评审；
修改编码与测试过程，删除编码与测试过程中单元测试用例可不进行评审的描述。
六、决策分析过程实践
1、输入：组织级过程体系文件《决策分析过程》、《决策分析指南》
入口准则：存在多个技术方案选择时
2、决策准则
⑴、入口准则
全新标准产品立项时。
定制产品立项时。
存在多个技术方案选择时。
决定全新开发、复用还是采购商用组件时，同时所做出的决定对项目的成败或进度、成本影响大于50%时。
⑵、评估准则
评估准则选择，依据体系文件中决策分析报告模版的“建议评估准则”。
3、评估方法
此次（项目仅有一次）评估方法为专家打分法（Delphi）。
评估常用方法有：SWOT分析、头脑风暴法、决策树分析法。
4、候选方案列表
方案一：自主开发消息管理
方案二：采用第三方消息中间件（IBM MQ）
5、实施过程与计划
项目经理根据项目前期的需求和方案，识别出两套技术解决方案，根据组织级过程体系文件《决策分析过程》、《决策分析指南》和入口准则，编制“决策分析计划”，计划内容包括（开始时间为3月28日）：
决策问题描述：
制定决策分析计划：
成立决策小组：小组由项目组成员、项目QA、项目经理构成；
建立评估准则：根据待决策问题的特征，确定明确的评估准则和评分标准，填写评估准则列表；
识别候选方案：寻找潜在的候选解决方案，填写候选方案列表
确定评估方法：
评选候选方案：
完成决策分析：根据评估结果确定最终方案，填写决策分析报告。
6、决策分析结果
根据两种方案评估结果和可接受准则：方案一得分最高，并且评估项1达到60分，所以选择方案一。
风险：对现有系统改造，改造质量影响系统稳定运行；应对措施：引入了代码自动化检查工具及测试工具，提升代码质量
七、项目监控实践
项目监控(Project Monitoringand ControlPMC)的目的是通过周期性地跟踪项目计划的各种参数，如进度、工作量、资源、工作成果等，并不断的了解项目进展情况，以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施。
1、监控依据
过程体系文件《项目监控过程》
模版：个人工作周报、项目工作周报、里程碑报告、例会会议纪要、外部干系人管理记录
2、入口准则
项目计划已发布。
项目组人员已到位，并得到相关培训。
3、监控输入
项目实施计划
项目进度计划
质量保证计划与跟踪表
配置管理计划与跟踪表
风险管理跟踪表
4、监控输出
项目进度计划（已更新）
个人工作周报
项目工作周报
项目度量数据库
里程碑报告
例会会议纪要
里程碑评审会议纪要
风险管理跟踪表（已更新）
外部干系人管理记录
5、证据举例
以项目例会为例，在例会上监控内容和点如下：
工作进度及完成工作量，识别项目偏差并分析；
识别问题并分析问题；
识别风险并跟踪风险，对项目风险进行规避，直至关闭；
按进度计划，安排组员的具体任务（TFS），并协调相关任务；
QA监控过程符合状况；
进行干系人计划跟踪，组织干系人参与里程碑会议和其他讨论会。
八、度量实践
1、度量体系简介
⑴、度量目标
项目性能度量:监控项目性能，保证项目能够按计划要求完成项目任务
产品质量度量:监控项目产品工作质量，保证项目能够高质量地完成
需求变更度量:监控项目需求稳定性，保证通过需求管理及需求开发活动，减少需求变更
过程质量度量:监控项目过程质量，保证QA人员能够了解项目成员对过程的遵守程度，识别不符合项高的过程加以指导和审计
项目规模度量:监控项目的规模，识别估计规模和实际规模的偏差
其它度量数据:监控各阶段的评审和测试方式、资源投入、人员水平、各过程的复用率、覆盖率、按期交付率
⑵、挣值分析
PV：计划工作量的预算成本
EV：已经完成工作量的预算成本
AC：已经完成工作量的实际成本。
进度偏差率(SV%)：进度偏差SV（SV=EV-PV）与计划工时的预算成本BCWS（PV）之间的比值
成本偏差率(CV%)：成本差异CV（CV=EV-AC）与已完成工时的预算成本BCWP（EV）的比值
进度性能指标(SPI)
成本性能指标(CPI)
2、度量数据收集来源
报工系统
技术评审报告
各类测试报告
周例会
3、度量数据记录在度量数据库里
4、度量过程
如上图所示，度量是周期性的工作，发生在各个阶段和里程碑点之后，数据来源于工作周报（报工系统）、技术评审报告、估算报告、测试计划和报告等，度量数据记录在度量数据库里。
5、度量分析
度量分析主要是在度量数据库和里程碑报告中，结项报告是引用度量报告。
九、项目风险管理实践
1、概述（基本概念补充）
⑴、风险应对策略
风险应对策略就是对已经识别的风险进行定性分析、定量分析和进行风险排序，制订相应的应对措施和整体策略。
风险规避：是改变项目计划来消除特定风险事件的威胁。例如，对于开发过程中存在的技术风险，我们可以采用成熟的技术，团队成员熟悉的技术或迭代式的开发过程等方法来规避风险。
风险转移：是转移风险的后果给第三方，通过合同的约定，由保证策略或者供应商担保。
风险减轻：是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在项目的早期采取风险减轻策略可以收到更好的效果。
风险接受：准备应对风险事件，包括积极的开发应急计划，或者消极的接受风险的后果。对于不可预见的风险，例如不可抗力；或者在风险规避，风险转移或者风险减轻不可行，或者上述活动执行成本超过接受风险的情况下采用。
⑵、风险来源
来自那些不好的事情，或者是造成潜在问题的源头：
不稳定的需求
复杂、不成熟的技术
过多的接口
客户的配合情况
团队技术水平低
（来源于公司资产库——风险库，项目个性化情况。）
⑶、风险分类
在风险管理指南中，风险分类定义有：需求、设计、编码、测试、开发环境、人员、客户、管理、质量、商业（市场）、其他。
2、识别风险与风险分析
⑴、识别风险
项目经理针对项目情况，综合考虑项目成本、进度、质量、范围等因素，项目经理组织风险分析小组进行识别风险活动，并将识别结果及时更新到《风险管理跟踪表》中。
在识别风险过程中，需要明确风险项、风险来源、风险类别等要素，并参考《风险数据库》。
风险识别方式：头脑风暴法、假设法、访谈法、文档审查法等。
⑵、风险分析
项目经理根据项目情况，组织风险分析小组对风险进行定性分析，确定每个风险项的“风险发生概率”、“风险影响范围”，计算出风险系数，并及时更新到《风险管理跟踪表》。
（风险系数=风险发生概率×风险影响范围。）
风险影响范围包括：范围、成本、进度、质量等项，每项分为1～5级（例如成本5级划分如下：小于5%的成本增加、5%～10%的成本增加、11%～20%的成本增加、21%～30%的成本增加、大于30%的成本增加）。
风险发生概率也分成5级
3、风险应对措施/计划
首先，参考公司资产库中的风险库（风险列表），公司以往最佳实践所提供的应对措施，业界常用的应对措施；
接着，是团队的智慧，大家讨论。
例如：在实施计划中安排培训计划，减轻人力资源不足、不稳定的风险。
4、如何跟踪风险，跟踪哪些？
按项目实施计划，通过项目周例会，在风险跟踪管理表上进行跟踪风险。
跟踪开放状态风险及其应对措施
跟踪重新分析
不断识别新风险
风险跟踪记录在风险跟踪管理表中。
5、举例说明本项目风险跟踪情况
本项目识别出8个风险项，主要风险是：
人力资源不足,资源负载严重，可能影响项目进度、质量，来源是不稳定的团队；
不能按进度计划要求完成项目开发各阶段任务，来源是技术不成熟。
十、技术评审与测试
1、技术评审概况
2、评审收集数据
评审规模、规模单位（例如页数）
预评审工作量（人时）
评审人数
评审总工作量
缺陷数量
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的输出
⑵、经验教训举例
在单元测试中，采用交叉测试，并提高测试用例的质量，对发现更多的缺陷有很大的帮助；
在设计阶段同行评审中，由于组员临时出差，找其他项目人员替代参与评审，评审时识别缺陷偏少，原因是替代人员对业务、技术架构不熟悉，很难识别问题，因此，在以后评审时，尽量安排项目组成员或对业务、技术较熟悉人员参与，例如，在后续评审时，通过经理协商，把出差人员抽调回来。
2013年11月1日补充。
---------------------
作者：肖永威
来源：CSDN
原文：https://blog.csdn.net/xiaoyw71/article/details/15338443
版权声明：本文为博主原创文章，转载请附上博文链接！