| CMMI知识竞赛参考资料 CMMI：软件能力成熟度模型集成(Capability Maturity Model Integration) 也叫：软件能力成熟度集成模型 | ||
| 分类 | 内容 | 备注 |
| 专业术语 | REQM 需求管理 (Requirements Management) | CMMI2-可重复级（基本的项目管理） |
| MA 度量分析 (Measurement and Analysis) | ||
| CM 配置管理 (Configuration Management) | ||
| SAM 供应商协议管理 (Supplier Agreement Management) | ||
| PP 项目计划 (Project Planning) | ||
| PMC 监督与控制 (Project Monitoring and Control) | ||
| PPQA 品质保证 (Process and Product Quality Assurance) | ||
| VER&VAL 验证与确认 (VER:Verification)(VAL:Validation) | CMMI3-已定义级（过程标准化） | |
| IPM 集成项目管理 (Integrated Project Management) | ||
| RSKM 风险管理 (Risk Management) | ||
| RD 需求开发 (Requirements Development ) | ||
| OT 组织培训 (Organizational Training) | ||
| OPF 组织过程焦点 (Organizational Process Focus) | ||
| DAR 决策分析 (Decision Analysis & Resolution) | ||
| PI 产品集成 (Product Integration) | ||
| TS 技术解决 (Technical Solution ) | ||
| OPD 组织过程定义 (Organizational Process Definition) | ||
| QPM 定量项目管理 (Quantitative Project Management) | CMMI4-已管理级（定量化管理） | |
| OPP 组织过程性能 (Organizational Process Performance) | ||
| OID 组织革新与推广 (Organizational Innovation and Deployment) | CMMI5-优化级（持续过程改进） | |
| CAR 因果分析与决策 (Causal Analysis and Resolution) | ||
| SOW 项目工作范围/工作陈述 (Statement Of Work) | ||
| CCB 配置控制委员会(Configuration Control Board) | ||
| 过程域划分 | CMMI2过程域包括：REQM、MA、CM、SAM、PP、PMC、PPQA | |
| CMMI3过程域包括：VER&VAL、IPM、RSKM、RD、OT、OPF、DAR、PI、TS、OPD | ||
| CMMI4过程域包括：QPM、OPP | ||
| CMMI5过程域包括：OID、CAR | ||
| 过程管理包括：OPD、OPF、OT | ||
| 项目管理包括：PP、PMC、SAM、IPM、RSKM | ||
| 工程管理包括：RD、REQM、TS、PI、VER&VAL | ||
| 支持管理包括：CM、PPQA、MA、DAR、OPP、QPM、OID、CAR | ||
| 项目过程定义 | 项目过程定义是根据《组织过程裁剪指南》进行裁剪的 | |
| 根据客户提供的资料，确定项目工作范围，即项目工作陈述，并获得评审。 | ||
| 进行项目过程定义裁剪前，需先明确项目工作范围，确定开发阶段，选择相应的模板 | ||
| SOW包括客户基本信息、项目目标/内容/范围/周期、交付产品、验收标准、约束事项 | ||
| 对工作陈述进行评审时，确保工作陈述与合同要求、与客户达成一致意见的约束事项保持一致，并且不违背公司的经营目标、基本战略等 | ||
| 确定项目开发方针时，要明确质量、进度、成本三者之间的优先级，以及相应的理由,并将此作为该项目开发的基础。 | ||
| 确定开发方法和开发工程时包含： 确定开发模型、明确各工程输入/输出准则以及实施内容、确定定量项目管理的设定 | ||
| 各阶段输出准则应包括： 各工作产品的验证/确认方法、各阶段结束的判定标准 | ||
| 项目过程定义的目的：根据项目合同以及与客户达成一致意见的事项，制定项目开发标准。 | ||
| Review和测试结束后，针对纳品物，确认是否与客户原先的要求事项、使用者的需要确实一致，这个称为妥当性确认。 | ||
| 项目计划 | 制定项目计划的开始条件：项目工作陈述和过程定义已经制定并通过评审 | |
| 制定项目计划的终了：项目计划通过评审并获得承认 | ||
| 从体制、人员计划、教育・培训计划这几个方面来制定人员体制计划 | ||
| 参照类似项目的总结报告中的生产性实际值・分析后的推荐值算出生产性目标值 | ||
| 制定品质管理相关计划时，须设定各阶段的品质管理单位、品质要素以及品质目标（目标标准、容许范围） | ||
| 品质管理要素包括Review速度,Review指摘率 | ||
| 针对系统相关设备（硬件、软件）要求，制定环境准备计划（包含为了确认可行性的计划、决定时期、导入时期、台数等） | ||
| 配置管理的必要活动 Ø 事前准备配置管理的工具 Ø 在特定的时间点时，将选择的工作产品作为基线进行管理 Ø 控制已管理的工作产品的变更，追踪变更实施状态 Ø 维持基线的一致性 | ||
| 对于系统以及系统开发工作，要根据顾客要求的信息安全等级、在项目中制定信息安全管理规则 | ||
| 项目计划评审涉及人员：项目经理/组长、开发人员、高层经理 | ||
| 规模和工数的估算 | 估算方法：逐步逼近法、一周原则 | |
| 在制定估算策略时，着重从项目的基本特征、度量数据库中可利用的数据两个方面进行考虑 | ||
| 客户的需求已经很好的定义了，预计不会有很多变化；而且，开发小组对项目的应用领域有丰富的经验；开发过程和在以前的项目中使用的类似，组织有可靠的历史数据。在这种情况下，可行的策略应包括： 1.在项目定义之初，做出整个项目的总体估算 2.在每个阶段开始之前就对其进行详细的估算 3.做完详细的阶段估算，在每个阶段结束时，更新总体估算 | ||
| 客户的需求定义不清楚；组织几乎没有项目应用领域和使用技术的经验。由于在项目开始时所知很少，所以合理的估算策略应该包括： 1.仅仅初步地估算需求阶段 2.需求阶段完成时，对设计阶段进行详细的估算，并为剩余的工作做出粗略的数量级估算（rough-order-of-magnitude） 3.在每个后续的阶段开始之前对其进行详细的估算，如有必要，更新对剩余阶段的总体估算 | ||
| 规模和工数的估算管理过程顺序： ①确定估算方法 ②设定估算属性 ③设定生产性目标值 ④工作量的估算 ⑤估算跟踪 | ||
| 对工作量进行估算的三个度量单位分别是：“人时”、“人日”、“人月” | ||
| 1人月=20人日，1人日=7人时 | ||
| 进行估算跟踪时，规模估算偏差率 =（项目实际规模—估算规模）／项目实际规模 | ||
| 进行估算跟踪时，工作量估算偏差率 =（项目实际工作量—估算工作量）／实际项目工作量 | ||
| 进行项目估算是除了开发的工作量，还需估算项目支持工作量以及项目管理工作量 | ||
| 进度管理 | 进度管理的开始条件： n 明确工作任务、相应的工作产物以及具体的担当者 n 明确进度，设定里程碑 n 明确成果物的完成标准 n 明确进度报告的方法（周期、会议体制、报告内容、模板等） | |
| 进度管理的输入：作业进度表、体制、问题管理表 | ||
| 进度管理过程中需对本阶段的任务进行细化，明确成果物、期限、担当者 | ||
| 在进度表上，要明确以下几项内容 Ø 任务描述(明确任务内容) Ø 成果物 Ø 期限 Ø 任务担当者 | ||
| 工作任务分解的两个要素 Ø 分解观点 Ø 任务工期 | ||
| 任务工期的设定要以估算为基础，按照实际担当者的能力，进行实际的工期安排 | ||
| 进度表中的工期是项目管理者，根据每个任务的实际担当者，进行确认的工期 | ||
| 根据分解的任务需设定进度管理指标，尽可能做到定量化管理 | ||
| 在难以通过管理指标来定量的把握进度时，通过状态进行管理（如：未着手→着手→半成品→终了） | ||
| 对作业效率和日常作业质量的确认包括几方面 Ø 管理者每天口头上对实际生产物进行确认 Ø 进度率的定量化 Ø 延迟的确认、处理 Ø 对遗留任务的确认 | ||
| 在任务发生延迟的场合，要迅速地调查延迟的原因，找出对策，及时反映到问题管理表中 | ||
| 在进度管理过程中需进行定期的进度报告，包含进度和问题点的报告 | ||
| 品质管理（设计/编码） | 品质管理的开始条件：明确项目的验证活动的计划，品质要素以及品质指标值 | |
| 品质管理的终了条件： ①设计或者制造成果物获得客户承认。 ②品质状况获得高层的承认。 | ||
| 针对品质管理部分，项目经理在制定项目计划时应设定品质管理单位 | ||
| 品质管理单位是把成果物分割成大小适中，便于品质分析与评价，易于对于品质差的部分采取措施的管理单位 | ||
| 要件定义的管理单位为业务、功能等，也是设计书的目录结构的Review实施/品质评价的单位 | ||
| 设计工程的管理单位为功能、模块等，也是设计书的目录结构的Review实施/品质评价单位 | ||
| 品质要素是为了衡量品质的一组度量元 | ||
| 品质指标值是为了对品质要素进行定量的分析和评价的水准，它包括上限、目标值、下限 | ||
| Review计划包括以下内容 Ø Review种类（组内Review，客户Review等） Ø Review实施的日期 Ø Review的对象 Ø Review种类不同选择不同的Review观点 Ø Review时的角色分担 Ø Review的参加者 Ø 明确必须参加的Review担当者 Ø Review结果的记录方法 Ø Review实施的日程表等 | ||
| 所有的工作产品（设计书、代码）都必须100%进行Review，以确保Review覆盖率为100%。若有特殊情况无法达到100%的覆盖率，必须提前获得EPG的同意 | ||
| 项目经理在工程开始前，对制定的Review计划进行确认，并予以承认 | ||
| Review分两大类：非正式Review、正式Review且作为品质评价的对象 | ||
| 非正式Review指自我检查（设计人员自己检查） | ||
| 非正式的Review，检出的缺陷是不进行统计的 | ||
| 正式Review分为：中间Review、综合Review（组内Review、设计Review、客户Review） | ||
| 正式Review的时候，需要统计缺陷的件数。但是中间Review可以不统计。 | ||
| 关于式样书中的错字或者漏字等不作为缺陷，不进行统计。 | ||
| 项目经理制定品质管理实施要领，包括以下要点: n 工程定义 n 品质管理体制 n 角色/权限 n 品质管理的会议体 n 品质管理单位 n 品质要素以及品质指标值 n Review计划 n 品质分析以及评价 n 品质管理工具 n 使用模板 | ||
| 项目经理和开发组PL对制定的作业要领进行确认，并予以承认 | ||
| 品质管理实施要领需在本工程开始前，周知项目组成员，对于中途参加的人员也要进行周知 | ||
| 项目经理需从以下几个方面对品质管理的实施状况进行确认： n 是否把握了品质管理单位的设计/编码的进度状况 n 是否把握了设计/编码规约的遵守状况 n 是否把握了超过最大规模的模块 | ||
| 开发小组的成员每次执行完Review后，把Review担当者指出的问题点以及实施的结果记录到问题记述票中 | ||
| 问题记述票应包含以下内容： Ø 问题出处 Ø 问题点的内容 Ø Review的种类 Ø Review参加者 Ø Review对象 Ø Review对象规模 Ø Review次数 Ø Review时间 | ||
| 开发组PL对指摘出的缺陷按以下几项进行分类： 发生种别、缺陷现象、重要度、缺陷原因以及混入工程 | ||
| Review实施过程中需进行以下管理： 进度管理、Review的记录确认、Review有效性的确认、Review结果的定量分析、Review结果的定性分析 | ||
| 项目经理需从以下几个方面对Review实施情况进行确认： Ø 有否对Review的进度状况进行管理 Ø Review的记录内容是否妥当 Ø 每次Review的有效性有否确认 Ø 每次Review的结果有否进行定量分析 Ø 每次的修正状况有否进行确认 | ||
| 利用Review的速度和检出密度控制目标对该次Review效果进行定量分析 | ||
| Review结果的定量分析从以下几个方面进行： Ø 利用Review的速度和检出密度控制目标对该次Review效果进行定量分析 Ø 每次Review的缺陷收缩状态 Ø 修正完成件数以及未修正件数 Ø 缺陷内容 Ø Review时间 Ø 每次Review文档修改后的页数的变更 | ||
| 品质判定基准根据下面几项进行判断： Ø 对于全部的文档是否按照计划实施了Review Ø 对于每个品质管理单位是否实施了品质分析、实施了品质改善的措施 Ø Review中指摘的事项是否全部在对应的文档中进行了修正 Ø 对于残留的检讨事项，对应的期限、实施的担当者、客户方的责任者是否明确 Ø Review所花的时间是否合适 Ø Review计划中必须参加的人员是否全部参加了 | ||
| 项目经理须召开品质评价会议，获得高层对本阶段品质状况的承认。 | ||
| 对于Review后的设计/制造成果物须获得客户方责任者的承认 | ||
| 品质管理（单体测试/结合测试） | 测试工程品质管理的开始条件：明确了项目的试验计划，品质要素以及品质指标值 | |
| 测试工程品质管理的终了条件：项目经理对能够进入下一个工程的品质水准作出了判断（里程碑评审通过） | ||
| 项目经理在制定计划的时候，定义试验工程的活动（包括单体试验和结合测试），明确成果物 | ||
| 试验工程包含以下几个品质要素： n 试验密度 n Bug检出密度 n 模块最大规模 | ||
| 单体和结合测试的作业要领，包括以下几方面： n 试验内容（试验范围、试验方法） n 实施的计划 n 试验的体制 n 试验的工具 n 管理的体制和规则 n 试验项目抽出的手顺 n 试验项目抽出的基准 n 文档的样式等 | ||
| 单体和结合试验的品质管理作业要领，包括以下几方面 n 工程的定义 n 品质管理的体制 n 职务/权限 n 品质管理的会议体 n 品质管理单位 n 品质要素以及品质指标值 n 品质分析以及评价 n 统计规模的方法（包括统计代码的工具名称和版本） n 故障处理的手顺 n 品质管理工具 n 文档的式样等 | ||
| 试验项目作成时，项目经理需要确认以下几项管理作业： n 是否对试验项目进行了Review。 n 是否对Review完了的每个品质管理单位的试验项目抽出件数进行了确认。 n 是否根据每个品质管理单位的品质指标值，对试验密度进行了评价等 | ||
| 开发组的组员根据试验项目作成试验数据、试验手顺书。开发组PL对其进行Review。 | ||
| 试验过程包括以下几点： 试验的实施、试验结果的记录、故障状况的记录、故障解析、故障修正、再试验 | ||
| 作为故障解析的结果，在故障处理票中需记录以下几项： n 故障模块ID n 故障原因 n 混入故障的工程 n 在设计工程中没有摘出的原因 n 故障应该指摘出来的工程 n 在试验工程中没有指摘出来的原因 | ||
| 项目经理和开发组PL根据试验消化计划，在设定的时间段中对每个品质管理单位的试验消化状况以及故障的解决状况进行管理 | ||
| 项目经理和开发组PL在试验实施中，在设定的时间段中对于故障从以下几方面进行管理： n 是否按照既定的故障处理手顺进行。 n 故障处理票项目的填写是否有遗漏。 n 故障处理票的记述内容是否恰当。 n 是否对故障的回答、故障的修改、再次试验状况等的期限进行管理。 n 是否对未回答/未修改/需要巡回的故障进行管理等。 | ||
| 开发组PL在试验实施中，在设定的时间段中对于Bug发生的状况从以下几方面进行确认： n 试验项目消化件数对应的Bug检出状况是否合适。 n 是否在发生类型、故障模块、Bug原因、缺陷混入工程的项目上有偏重。 n 是否有对试验进度有影响的重大Bug。 n 在结合试验中是否有应该在单体试验中发现的Bug等。 | ||
| 项目经理需从以下几方面对试验实施状况进行确认： n 是否把握了每个品质管理单位的试验消化状况以及故障的解决状况。 n 在试验实施中，在设定的时间段中对故障的管理是否恰当。 n 在试验实施中，在设定的时间段中是否对模块单位的Bug检出密度实施了评价等。 | ||
| 品质报告书 | 品质报告书构成要素： 案件基本情报 品质评价 品质强化对策 与下一阶段的交接事项 结论 | |
| 案件基本情报： 工程定义 Review计划和实际（包括Review担当者及Review时间） Review实施的法 | ||
| 品质分析包括定性、定量 | ||
| 定量分析：对低于下限或高于上限的业务/机能的品质进行分析（为判断Review的妥当性，需记录Review担当者、Review次数等） | ||
| 定性分析：根据问题记述票，详细分析Error现象及原因（以业务或机能为单位） | ||
| 根据品质分析的结果，针对容许范围外的品质管理对象及具有明显倾向的问题点，采取相应的对策 | ||
| 设计/制造过程中与下一阶段的交接事项通常为需求变更的对应 | ||
| 单体/结合过程中与下一阶段的交接事项通常为式样变更的对应和追加测试 | ||
| 沟通管理 | 沟通管理的输出为：沟通管理实施要领、会议记录、QA票、沟通邮件、项目状态报告 | |
| 沟通管理包含明确沟通需求、确定沟通工具、确定沟通方法、执行沟通、确认并管理沟通 | ||
| 沟通工具有会议、QA、电子邮件、电话 | ||
| 开会内容需形成会议记录/议事录，会后整理并由参加人员进行内容确认 | ||
| 会议记录的主要内容应该包括： Ø 会议基本信息（名称、目的、参加者、主持者、开始时间、结束时间） Ø 决定的内容 Ø 待解决的内容（要明确担当者，预定完成期限） Ø 下次会议要做的内容以及时间 | ||
| 确认QA票时需注意以下问题点： n 是否已经超过回答期限而没有回答的内容 n 客户暂时性回答，问题状态不能为关闭状态 n 通过电话等沟通的问题，是否及时填入概要信息（沟通双方确认，同时其他信息共享） | ||
| 需求管理 | 简述需求管理的目的：维护需求并且确保能把对需求的更改反映到项目计划、活动和工作产品中 | |
| CCB的职责：分析需求变更产生的影响，评审和审批需求及需求变更请求 | ||
| 需求管理过程中可根据需求的性质和功能两种方法来对需求进行分类 | ||
| 按照需求性质划分，将需求分为：原始需求、项目需求、新需求 | ||
| 按照需求功能划分，将需求分为：功能需求、性能需求、环境需求、UI需求、业务流程需求、接口需求、其它需求 | ||
| 原始需求和项目需求是项目成本预算的依据 | ||
| “新需求”是指在确认需求基准后提出，经项目经理和客户沟通后，双方共同认可不属于项目范围内的需求 | ||
| 进行需求评审时需注意以下几点： n 相关利益者的代表必须参加。 n 对于需求参加评审的相关利益者必须达成一致。 n 参加评审的相关利益者要对实现这些需求所要进行的活动作出承诺。 n 评审要有记录，并且要得到参加人员的确认。 | ||
| 完整记录需求，并列出其中间产物以及标识需求和需求、需求和产物、产物和产物间的网状关系，以便在需求发生变更时能清楚了解相关影响范围 | ||
| 按照配置管理的基线变更控制规程对需求的变更进行管理 | ||
| 获取需求的变更申请后，CCB组需结合需求跟踪矩阵分析该变更的影响范围 | ||
| 确定变更的影响范围后，需要确定该变更的对应方法和修改成本，如果变更复杂、影响较大，可能需要技术解决方案和决策分析来最终确定 | ||
| 问题管理 | 问题管理是从项目组成立开始进行的 | |
| 项目结束，体制解散起可以不用进行问题管理 | ||
| 问题管理表中应包含以下内容： n 问题内容（问题发生的环境，上下文等） n 优先级 n 对应期限 n 对应内容 n 担当者 n 问题提出者（发现者） | ||
| 为了避免某些共通问题再次发生，需针对该问题制定措施，并在在项目组或公司范围内进行横展开 | ||
| 把实施处理方案后的处理结果报告给组长、项目经理，通知全项目组成员 | ||
| 开发过程中发现问题时,需及时把问题登记到问题管理表中 | ||
| 小组或项目组内不能解决的问题要上报上层管理者或客户 | ||
| 问题解决担当者需调查问题的根本原因,讨论处理方案 | ||
| 实施解决方案前需上报上层管理者或客户 | ||
| 项目经理需确认处理结果和效果 | ||
| 风险管理 | 风险管理的目的：识别潜在的风险，并对已识别的风险进行管理，使风险发生时造成损失降到最低 | |
| 以下几个时机是必须要进行风险分析的 提案书制作前 需求设计阶段开始前 详细设计阶段开始前 编码阶段开始前 | ||
| 项目中的风险是指： 所有有可能阻碍项目成功（包括品质、成本、纳期）的因素 | ||
| 风险管理的操作手顺： 制定风险管理计划 识别风险 分析风险 确定风险优先级 制定风险对应计划 实施风险对应计划 报告、周知实施结果 确认实施效果 | ||
| 应急计划指：预先制定风险发生时的对应措施、人员等 | ||
| 项目经理针对以下几点制定风险管理计划 n 风险管理的职责和责任分担 n 项目风险大小确定风险优先级 n 风险分析和监控的任务计划 | ||
| 对于项目开发周期短的项目，在项目开始前可针对以下观点进行分析，制定对应计划并实施 n 品质、成本、纳期（QCD） n 项目开发体制/人员（包括人员能力） n 项目开发环境（包括硬件、软件、开发工具） n 新的技术 | ||
| 对已识别的风险，分析每个风险产生的影响、发生概率以及发生时间 | ||
| 风险分析小组要分析已标识的风险对成本、进度以及产品质量的影响 | ||
| 风险严重程度参数： 危险 进度延误＞30% 或 费用超支＞40% 严重 15%<进度延误≦30% 或 20% < 者费用超支≦40% 一般 5%<进度延误≦15% 或 5%<费用超支≦20% 不严重 进度延误≦5% 或 费用超支≦5% | 量化值： 4 3 2 1 | |
| 风险时间框架参数： 近 风险预计发生的时间≦工程总工期的15% 中 风险预计发生的时间∶工程总工期的15% ～ 25% 远 风险预计发生的时间≧工程总工期的25% | 量化值： 3 2 1 | |
| 风险大小（RM）= 风险影响大小 × 风险发生概率 × 风险发生远近度 | ||
| 风险发生概率参数的范围是： 0%≦发生概率<100% | ||
| 风险等级定义（五种） Ø 非常低的风险（风险大小（RM）≦2.4） Ø 低的风险（2.4<风险大小（RM）≦4.8） Ø 中等的风险（4.8<风险大小（RM）≦7.2） Ø 高的风险（7.2<风险大小（RM）≦9.6） Ø 很高的风险（风险大小（RM）>9.6） | ||
| 风险处理方法有： 回避 减轻 监控 转移 接受 | ||
| 实施责任者根据风险对应计划，实施相应的对策，并将实施结果反映到风险报告中 | ||
| 实施责任者需将实施结果在项目组内进行周知，并汇报给项目经理 | ||
| 项目经理必须对实施的效果进行确认，若实施效果未达到预期目标，转为问题管理 | ||
| 项目经理从以下几方面进行实施效果确认 Ø 对策是否全部实施 Ø 预防措施是否降低了发生的影响度或者概率 Ø 是否降低了影响 | ||
| 生产性管理 | 生产性管理的开始条件 系统开发的规模已被计算出来（估算/实际） | |
| 针对生产性预计与实际偏离、进行原因的分析、并实施解决方案后可以结束生产性的相关管理 | ||
| 生产性管理：设定生产性目标值的设定，把握各工程的工数，计算生产性的实际值，分析和比较生产性数据，处理生产性数据的比较和分析和处理预定和实际的偏离的偏离 | ||
| 各工程结束时，合计各工程的业务工数、管理工数 | ||
| 生产性计算公式 生产性＝代码开发规模（估计或者实际）（Step）／实际工数（人月） | ||
| 配置管理 | 配置管理的终了条件 该项目结束，项目的资料（代码、文档、数据等）进入公司资产库 | |
| 配置控制委员会（CCB）的职责有： Ø 评审/批准配置管理计划 Ø 评审分析变更请求 Ø 做出对变更请求的决定（接受/拒绝），授权变更 Ø 对变更结果进行审查 Ø 进行基线审计，提交基线审计报告 | ||
| 制定配置管理计划时需明确： 1. 确定配置管理策略 2. 确定配置管理对象 3. 定义变更管理过程 | ||
| 建立配置管理环境考虑要点： 1. 根据公司的标准开发环境或客户要求，确定配置管理工具。 2. 确定共利益者对配置管理库的控制权限。 3. 由项目组建立开发库、由配置管理工程师建立受控库、产品库，并按照访问权限建立各种用户进行管理，开发库建立完成后项目经理需要把Admin密码发送给中高层经理。 4. 映射项目目录结构到配置管理库（机器名、库名、内部层次关系等）。 5. 创建项目初始基线，将项目已存在的配置项导入到配置管理库中。 6. 建立备份、恢复机制和策略，确保数据安全。 | ||
| 配置管理环境建立后，建立基线、配置项入库 | ||
| 配置项通过评审后方能检入，状态修改由配置管理工程师执行。设定每一成员对基线进行访问阅读的权限 | ||
| 设计书review前打标签 | （不管是简单检查还是业务逻辑review，每次都需要打标签。目的是为了明确表明每次检查或review的对象） | |
| 设计书FIX后（或通过客户Review后），checkout。入库管理 | ||
| 对受控非基线的变更，必须提交变更请求，由项目经理进行评审决定是否进行变更 | ||
| 如果需要对已经基线化的工作产品进行修改，必须提交变更请求，并通过评审决定是否进行变更 | ||
| 对是否进行变更的评审，由CCB负责进行 | ||
| CM工程师定期报告配置管理状态 | ||
| 配置管理报告主要包括以下内容： Ø 变更请求的状态和变更活动 Ø 在配置管理库中产品的规模/容量 | ||
| 各阶段终了判定 | 项目经理通过对该开发阶段的任务的完成状况，以及工作产品的质量进行的评价，来判断已完成的工作产品是否已达到能够进入下一个开发阶段的质量要求 | |
| 该阶段的质量实际数据已统计完毕可以进行该工程终了判定 | ||
| 终了判定的子活动有： 收集项目实施数据 判定品质状况 判定项目状况 确认与下一阶段的交接事项 判断阶段是否结束 获得高层的承认 | ||
| 判定该工程项目状况时，需从以下几个方面进行确认： n 是否已满足阶段结束条件？ n 存在的问题点、风险等，是否已有解决对策？ n 是否存在仍未解决的客户提出的重大的问题？ n 与客户签订的合同/作业依赖数内容是否反映到开发中？ | ||
| 里程碑点时，召开项目品质评价会议，以获得高层对项目状况、品质状况的承认，确定进入下一阶段的实施 | ||
| 项目总结 | 项目总结的开始条件是： ① 系统开发完成，客户已经投入使用。 ② 系统代码已经全部入库。 ③ 客户投入使用一个月以后为标准。 | |
| 项目总结的终了条件是： 在项目反省会上得到项目开发结束的承认 | ||
| 项目总结的子活动有： 计划与实际的偏离分析 设定分析后的推荐值 完成项目总结报告 承认项目总结报告 | ||
| 偏离分析的主要对象有： n 项目的每个品质要素 n 项目的每个生产性数据 n 規模 n PM补充策略 n 改善目标 n 客户的评价 n 开发进度 n 人员计划 n 风险的确认 | ||
| 项目经理要参考计划与实际的偏离分析的结果，分析应该改善的点，设定以后项目的参考值（分析后的推荐值） | ||
| 偏离分析后，以下几项可以做为以后项目的推荐值： n 项目的每个品质要素 n 项目各阶段的生产性数据（生产率） n 规模 n 开发进度 n 人员计划 n 改善目标 | ||
| 项目结束报告书包含以下内容 n 项目各阶段的品质要素必须 n 项目各阶段的生产性数据必须 n 规模必须 n PM补充策略必须 n 改善目标必须 n 开发进度的计划和实际结果 n 风险的确认（工程完了时的确认） n 改善目标 n 横展开事项 n 各担当者的自我评价报告 n 管理者的项目评价报告 n 其他 | ||
| 项目管理者要将[项目总结报告]提交[项目反省会]讨论，在报告的同时，要得到PMO开发管理的决定权人员的批准 | ||
| 项目责任者需向公司提交项目资产 | ||
请您注意
·自觉遵守：爱国、守法、自律、真实、文明的原则
·尊重网上道德，遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规
·严禁发表危害国家安全，破坏民族团结、国家宗教政策和社会稳定，含侮辱、诽谤、教唆、淫秽等内容的作品
·承担一切因您的行为而直接或间接导致的民事或刑事法律责任
·您在NoteShare上发表的作品，NoteShare有权在网站内保留、转载、引用或者删除
·参与本评论即表明您已经阅读并接受上述条款
