PEI ZHI GUANLI GAISHU 1(liyi)

建立产品
以下情况，我们需要构建软件产品:

(1)集成测试或者系统测试
(2)产品交付
(3)为了故障定位和故障诊断而重新构造产品系统

构建软件产品可以非常频繁

产品系统建立是通过执行特定的目标配置，把组成配置项, 经过编译, 组合成一个完整系统的过程。

为确保每次变更后系统或其一部分能够重建，应考虑以下问题,并作详细记录：
（1）组成系统的所有配置项是否都已齐备,正确及有恰当的版本？
（2）建立结构（从属关系，路径设置等）是否都已齐备,正确及有恰当的版本？
（3）所需的工具（compiler或linker ) 是否齐备，版本是否正确？
软件产品的版本包括:
（1）发布号，指明了实现的功能集
（2）构造号，定义了精确的配置项集合
这不同于工作产品的版本
三、变更处理与它的生命周期
变更是软件开发过程中最基本的特性。开发过程的所有阶段从需求分析到产品再到维护都围绕着变更来进行。

要管理好版本,保护配置库,
变更处理流程是一个重要的部分!

变更处理流程
（1）变更要求
（2）变更评估或变更分析
（3）变更部署
（4）变更实施
（5）变更验证
（6）生成基线实现对变更的控制

变更请求包括以下几种情况:
（1）新增功能
（2）已有功能的改进
（3）错误修正
（4）处理异常状况。
四、SCM与SCCB的角色介绍
    参笔记
高层CCB职责：
（1）批准并发布配置管理计划；
（2）批准/拒绝提交的一级变更；
（3）批准基线产品提交转产。
SCCB 职责：
SCCB的主要任务,是审核和批准以下活动:
（1）配置项的识别
（2）基线的确立
（3）基线的变更

CCB （Configuration Control Board）

SCCB最艰巨的责任是分析大量变更请求的影响，以及把变更请求高效而正确的指派给相应的实施人员。这些可以通过以下方式完成:
（1）SCCB会议的焦点是在管理方面的决议
（2）准备和技术方案不在会上讨论
（3）在各个组在场的情况下,决定指派组别
（4）仅仅决定“做还是不做”

高层CCB成员：
（1）系统部长；
（2）产品总工；
（3）软件专家；
（4）硬件专家；
（5）测试专家；
（6）客户代表，包括：市场人员和用服人员等。
（7）质量保证专家；
（8）配置管理专家；

项目SCCB成员：
（1）系统人员；
（2）软件开发人员；
（3）硬件开发人员；
（4）测试人员；
（5）配置管理经理；
（6）配置管理员。

SCM Group职责
SCM小组的职责：
（1）创建和管理项目的基线库系统
（2）开发，维护和发布项目的SCM计划和SCM程      序
（3）草定纳入SCM的工作产品
（4）管理基线库的使用权限
（5）更新基线
（6）从基线库中创建软件产品
（7）拟制和发布SCM报告
（8）进行SCM审核
（9）支持SCCB活动，执行SCCB的决议

五、配置管理审核

配置管理审核的目的:
（1）确保SCM系统功能的正确性、和所有配置     及更改都已根据规程完成
（2）确保建立系统包括的功能都预备好
（3）确保建立系统的功能和需求文档一致
（4）确保任何时候都可以建立任何版本的系统

系统审核

物理审核是为了确保SCM系统的完好，所有的配置项均存在，并且可获取。
物理审核程序包括以下内容:
（1）检查SCM系统硬件是否工作正常。
（2）检查操作系统是否工作正常。
（3）检查SCM 工具是否工作正常。
（4）检查SCM库是否完整。
（5）检查SCM系统是否有足够的处理能力。
（6）检查SCM库是否做了备份，并且备份可恢复。
（7）检查 SCM的配置项清单，版本清单和系统    版本对应表是否正确。

配置审核

（1）检查是否能够根据基线的配置项清单中的内容，重新构建该基线产品。

（2）重新构建的产品和先前产生的产品的一致性

功能审核

功能审核确保已有的功能特性是根据适当的程序来完成的。
功能审核包括以下内容:

（1）CM库结构和内容是否和配置管理计划相符
（2）编译版本所需要的配置项是否完整地包含在配置管理系统中
（3）编译版本前所有相关变更是否经过正式的流程
（4）纳入基线的工作产品是否经过正式的流程
（5）发布的基线是否完整，包含的配置项之间是否一致，与配置管理计划是否一致
（6）所有的产品功能能否追踪到相应的需求？
（7）是否所有的需求已经正确实现？

软件配置审核总结
软件配置审核:

（1）是用来保证发布产品的质量。
（2）是软件配置组的正常任务和活动。
（3）是协助软件开发人员更好的履行他们的任务。而不是对软件开发人员工作的审核。也不是任何人对软件配置组员工作的审核。

落实软件配置审核

落实软件配置审核的主要方法:
（1）检查变更请求
（2）以变更请求为本的系统建立活动
（3）基线状况

六、配置管理计划

   配置管理计划
   SCM计划是项目进行SCM活动的依据。SCM计划有以下应用:

项目管理人员能够识别配置项，以便控制，跟踪和监督。
项目经理能够监视和跟踪进展情况；系统工程师，软件工程师，测试工程师和其他相关组能够以此为依据，准备和安排各自的工作计划。
项目管理人员能够把SCM活动的费用和时间表包含到项目整体的费用和进度的估算中去。

SCM计划包括以下内容:

（1）建立 SCCB
（2）识别配置项
（3）确定SCM库约定:
（3.1）命名约定
（3.2）控制等级
（3.3）目录结构
（4）变更和构造的程序
（5）备份方案，SCM审核
（6）度量收集和状况报告


七、配置管理报告

SCM –度量和报告

 （1）数据在整个生命周期过程中是持续产生的。
 （2）进行测量并将测量结果用于确定SCM活动的状 态。
 （3）要利用有用的数据来编造对项目有帮助的报告。

SCM –测量和分析

度量包括：
（1）单位时间内处理更改申请的次数；
（2）在SCM计划中，SCM活动重要事件的完成情况；
（3）在SCM活动过程中完成的工作、花费的工作量和资金；
（4）严重程度级的分布；
（5）配置系统的可应用率；
（6）变更请求分配返工率；
（7）产品建立成功率等。

SCM报告
报告要有利于我们的工作。
有效的报告是：
（1）多维的；
（2）包涵了有用的度量；
（3）有利于进度的监控与追踪；
（4）可以指示将来的趋势；
（5）有明确对象的；等。

 

**************************************************************************

2 项目YANFAGUOCHENG ZHUYISHIXIANG

培训内容
(1)第一部分：质量基本概念
(2)第二部分：QA角色职责
(3)第三部分：项目研发过程注意事项
第三部分：项目研发过程注意事项:
(1)项目计划制定
(2)项目计划跟踪和监控
(3)基线
(4)变更
(5)工作产品要求
(6)需求开发和需求管理
(7)风险管理
(8)评审
第一部分：质量基本概念
质量概念的发展
i)符合性质量：
符合标准
ii)适用性质量：
产品在使用时能成功满足顾客需要的程度。
iii)广义质量
质量是一组固有特性满足要求的程度。
质量系统的核心在于预防

质量管理发展的3个阶段
（1）质量检验阶段：由检验人员，按照规定的技术要求和质量标准对产品进行严格的质量检验
（2）统计质量控制阶段：在质量检验的基础上，把数理统计运用到质量管理中，对影响质量的各种因素实施质量控制
（3）全面质量管理阶段：以质量为中心，以全员参与为基础，旨在通过让顾客和所有相关方受益而达到长期成功的一种管理途径。

第二部分：QA角色职责
在 人- 技术-过程 三角中QA关注点在过程

QA存在的必要性
为什么有那么多的过程没有得到落实？
（1）定义的过程不清楚
（2）人们喜欢走捷径
（3）人们的习惯难以改变
（4）人们可能无意识的犯错误
QA与QC的区别：
（1）对象
    过程，工作产品
（2）目的
    预防，检查
（3）时机
   事前，事后
注：QA 是 Quality Assurance ，最重要的职责在于系统层面的完善，侧重于问题的防范及对已发生之问题的探究，从而降低不良的产生。
QC 是 Quality Control ，指检验，在质量管理发展史上先出现了“QC”，产品经过检验后再出货是质量管理最基本的要求。QC的工作主要

是产成品，原辅材料等的检验，QA是对整个公司的一个质量保证，包括成品，原辅料等的放行，质量管理体系正常运行等

有线研究院QA跟踪项目分类：
（1）重点项目
（2）非重点项目

重点项目QA职责：
（1）根据公司或者业务领域质量政策以及产品开发团队制订的产品质量目标和质量策略，组织研发项目组制订项目质量目标和质量策略。
（2）根据项目计划、项目质量目标和质量策略、以及产品质量保证计划，制订项目质量保证计划
（3）监控项目质量目标和计划
（4）指导项目过程活动，实时审核项目过程活动和工作产品
（5）项目决策点，监控项目阶段质量目标达成情况，进行项目阶段审核
（6）跟踪不合格项的处理，直到关闭
（7）参与制订和评审项目计划
（8）向研发项目组宣传质量文化
非重点项目QA职责：
（1）指导研发项目组制订项目质量目标和质量策略
（2）指导项目过程活动
（3）在项目最后一个里程碑点，对项目质量目标达成情况和过程规范性进行QA总结
（4）跟踪不合格项的处理，直到关闭
（5）指导项目过程定义活动，确保项目过程定义裁剪的合理性
（6）向研发项目组宣传质量文化
QA与EPG、项目的关系
  立法  检查  执法

第三部分：项目研发过程注意事项

(1)项目计划制定
(2)项目计划跟踪和监控
(3)基线
(4)变更
(5)工作产品要求
(6)需求开发和需求管理
(7)风险管理
(8)评审
项目计划制定-概念阶段

***************
产品开发任务书
***************
          |
*****************
确定概念阶段
项目活动和工作产品
************* ******
          |
**********************
制定概念阶段研发项目计划
*************************
           |
************************
概念阶段研发活动和输出
**********************

项目定义过程注意事项-质量指标
项目质量指标的确定，不能低于研发中心产品质量策划中对项目质量目标的底线要求，同时结合类似项目的历史数据。裁剪说明中，建议列

出类似项目的历史数据，以供参考。

项目定义过程注意事项-过程裁剪
(1)过程裁剪必须满足模板中的裁剪准则；
(2)所有被裁剪的活动，必须写明裁剪理由；
(3)所有输出的工作产品，必须进行评审裁剪。不评审的文档，要写明不评审的理由。
(4)项目质量策划中的相关活动，必须落实到过程定义活动中。

项目定义过程注意事项-度量计划
度量计划中的度量指标，必须与裁剪后的过程活动一致，项目活动中不包含的度量指标，以及项目明确不跟踪报告的指标，应该不包含在度

量计划中。

计划的一致性
(1)保持开发任务书、业务计划书、估算、WORD计划、PMS计划中相关内容的一致。
(2)项目过程定义中的活动，包含对工作产品的评审，必须在PMS进度计划中全部体现，以保证项目活动与过程定义一致。特别关注质量策划

的活动，要落实到PMS进度计划中。
(3)项目过程定义中输出的工作产品，必须全部包含在配置项齐套清单中，以保证项目实际输出的工作产品不少于过程定义的输出。

计划的一致性--项目范围或进度延误超过10%
项目范围或里程碑变更，应该提交研制任务书变更流程，进行变更影响分析，识别受影响的配置项，调整开发任务书、业务计划书、WORD计

划、PMS计划，保持文档一致。

计划实施过程中常见的不一致问题
(1)质量策划中的部分活动、过程定义中的部分活动项目没有进行；
(2)过程定义中输出的工作产品，与齐套清单不一致；
(3)过程定义中要求输出的工作产品，项目实际进行中没有；
(4)没有按过程定义中要求的同行评审，实施工作产品评审。

项目计划修订
(1)研制任务书调整
(2)每个阶段开始前
(3)其它事件触发

项目计划跟踪和监控:
(1)项目例会
(2)项目周报、月报
(3)阶段或里程碑点的总结报告
(4)项目结束的复盘报告或研制总结报告

项目报告的要求
（1）按度量计划中要求的报告方式，对度量指标进行跟踪分析；
（2）对质量目标数据进行跟踪分析；
（3）周月报中的问题跟踪到关闭。

项目计划跟踪和监控常见问题
（1）项目没有例会，或很长时间没有例会；
（2）项目报告中对度量指标的分析不足，质量目标数据没有跟踪；
（3）周、月报中的问题没有跟踪到关闭。

基线
基本概念
配置项
需要纳入配置管理的工作产品，即配置管理的对象。包含但不限于：齐套清单中的文档、代码、工具。
基线
在配置项的生命周期中，在特定时间经过正式认定的一个或一组配置标识文档。将来的开发将以此为基础，只有通过正规的变更控制程序才

能改变它
基线化
基线的过程就是基线化。
基线库
放配置项的库。

工作产品基线
把配置项放到基线库就是工作产品的基线化过程。
工作产品评审通过后，提交PDM，完成审批流程，就是工作产品基线。后续的文档变更必须走正式的变更流程。
对项目来说，工作产品基线有更大的及时性。

管理基线
每一个技术评审关闭后，项目自己及时在PDM上打基线标签。
管理基线有助于工作产品的分阶段管理

如果同一开发阶段内2个技术评审点的时间间隔比较短，在1个月以内，可以酌情考虑只在后一个技术评审结束后打一个管理基线标签。如概

念阶段和计划阶段。其它开发阶段必须每个技术评审点一个管理基线。

2个管理基线合并为一个的活动，必须在项目过程定义中定义。项目的任何研发活动，都必须保持与过程定义的一致。

变更
变更影响分析
必须按CQ上变更影响分析的内容，进行变更影响分析。
CCB应该识别出所有受影响的配置项，指派责任人完成相关工作产品的变更，提交配置库进行版本升级。必要时，应对变更的工作产品实施

评审。

CQ变更填写要求
（1）字段填写规范；
（2）字段内容准确；
（3）CCB影响分析填写完整；
（4）变更责任人的变更处理结果中应填写实际修改的配置项。如果实际修改的配置项与CCB影响分析中识别的受影响的配置项不一致，需要

进行说明。QA会检查变更文档的一致性。

CQ版本构建
（1）CQ版本构建关联的变更（除中试提交的以外），要求全部完成验证。
（2）版本构建中新发现的故障要求全部提交CQ。

CQ常见问题
（1）缺陷发现阶段填写错误；
（2）变更影响分析不完整；
（3）变更处理结果中，实际修改的配置项与CCB影响分析的不一致，没有原因说明。
（4）变更处理结果填写过于简单。
（5）版本构建中关联的变更没有全部验证；
（6）CQ单长时间处于提交状态，不及时处理；
（7）CQ构建单长时间不验证关闭

工作产品要求

（1）满足模板要求
   常见问题：在前一版本或类似文档的基础上直接修改提交，不满足最新模板要求。
（2）与上游工作产品一致
（3）确保质量，为后续开发提供足够的信息

需求开发和需求管理

需求开发－需求的层次
（1）市场需求说明书
（2）产品包需求
（3）产品规格

需求开发－需求粒度

目标（满足研发中心质量目标要求）
估算工作量/需求数<质量目标中的需求粒度要求,才能保证项目结束时，实际需求粒度满足质量目标要求。
   
QA对需求粒度审核评价的3个点：
（1）产品开发任务书针对产品包需求；
（2）产品业务计划书针对产品包需求；
（3）估算的工作量针对产品规格

需求开发-版本规划
对于每个项目来说，范围应该是明确的，即要实现哪些需求应该是明确的。
产品开发过程中增加、修改、删除的需求，属于项目需求变更。
因此，针对每个产品包需求，应该有确定的版本规划。

如果部分产品包需求或产品规格不是本项目需要实现的，应该在相应层次的需求文档中，对每个需求增加实现版本的属性说明

需求管理－需求追踪

进行需求追踪的3个层次
产品包需求<-->产品规格<-->测试用例

需求追踪覆盖率（对于可测试的需求，要求100%覆盖，以后会加到RP的属性中）
产品开发的设计文档，应该保持与上层需求和设计的一致。

需求管理-需求变更
(1)需求变更必须提交需求变更流程；
(2)需求影响分析要完整。
(3)需求文档变更要同步维护RP需求追踪和TM需求追踪。

风险管理－概念
风险
还没有发生，但必然发生的事件或状况；
还没有发生，但有可能发生的一种不确定事件或状况。
                  0<发生概率<=1
 风险一旦发生，会对至少一个项目目标（如进度、成本、范围、质量）产生积极或消极影响。
问题
风险一旦发生，产生的消极影响就是项目需要跟踪解决的问题。
对“问题”，明确定义为以下要跟踪的内容：CALLOG，现场问题反馈，测试重大缺陷，以及已经发生的对进度、质量、资源有重大影响，需

要跟踪处理的问题

风险和问题的区别
风险：还没有发生，但可能发生  问题：已经发生

为什么要识别风险并跟踪管理？
事先预知风险，可以在风险没有发生时，提前采取有效措施，规避或转移风险。
当风险不可避免时，提前采取措施，尽量减少风险对项目的影响。

风险管理－风险识别和风险计划
项目计划制定时，识别项目风险，制定风险计划。
项目的约束条件和依赖，都是项目的风险，应该作为风险识别出来，进行计划和跟踪管理。
风险识别和跟踪，伴随项目整个生命周期。
对识别出的风险，在项目周月报的风险跟踪表中进行跟踪，注意按模板的内容跟踪。
风险跟踪意味着对风险信息的及时更新和维护。
产品开发过程中，随时识别新的风险，纳入风险跟踪表中进行跟踪管理

风险管理常见问题

（1）风险跟踪表中几个月都没有识别出新风险，但项目进度已有明显延误，且延误原因已知。
原因：风险识别做得不好，没有在事件尚未发生时识别出可能对进度产生影响的风险。
（2）风险跟踪表中的参数没有及时更新。

评审
同行评审－注意事项
（1）评审方式不低于过程裁剪中的评审方式要求；
（2）评委范围满足被评审对象的范围要求（上下游用户）；
（3）使用检查单；
（4）预审报告提交率不得低于80％；
（5）评审记录完整；
(6)所有不采纳的评审意见，都应该写明拒绝的理由；
(7)所有采纳的意见，都应该处理并验证关闭；
(8)评审流程及时处理；
(9)评审缺陷密度不低于组织能力基线。

同行评审－常见问题

(1)系统统计的预审报告提交率达到80％，但大部分评委的预审意见为0，实际预审报告提交率没有达到80％。
可能的原因：
评委责任心不够；
工作产品质量太好，确实提不出意见
(2)实际评审已结束，但评审流程一直不处理；
(3)评审记录不全或没有内容，缺乏对评审意见的跟踪验证。
(4)没有使用检查单

技术评审－注意事项
评审准入
(1)齐套性标准化审核结果；
(2)测试就绪、设计定型准入检查报告；
(3)测试就绪、成果鉴定、设计定型的《遗留故障风险分析和解决计划》；
(4)成果鉴定、设计定型的可靠性检测报告；
(5)技术评审规程中其它准入要求。

评审过程规范要求
(1)技术评审准入条件满足；
(2)评委范围满足要求；
(3)会议评审过程纪律；
(4)预审意见提交率；
(5)所有确认拒绝的评审意见都有原因说明；
(6)所有确认立即修改的问题都应该作为遗留问题跟踪，并正确修改、验证、关闭；
(7)遗留问题全部验证关闭后，才能关闭技术评审单。
(8)不要求立即解决的问题，应通过其他有效手段建立跟踪，确保遗留问题的解决、验证到关闭。

技术评审－常见问题
(1)会议纪律问题，迟到、缺席；
(2)预审意见少；
(3)不采纳的评审意见没有记录拒绝的理由；
(4)遗留问题实际没有验证就关闭评审流程。

 

************************************************************************

333333333333