查看完整版本: 基线的定义

基线的定义

当一个配置项被完成的时候，将被交到配置管理组，配置管理组将检查交来的配置管理项是否完整，并为它建立基线。基线是通过正是评审并通过的文档说明和产品，是下一步开发的基准。所有对它的变更，必须经过正式的变更控制过程。
有功能基线，分配基线，产品基线，测试基线等。

::em71::

要是加上几个图示就更清晰了。

请问这里的基线是否就是那个mainline呢？它和element的“糖葫芦”是什么关系呢？

不知道各位打基线是在什么时候？例如，是一个需求文档经过评审后就打，还是说系统设计方案结束啊，连同一起打上基线呢？我们现在用BaseCC,真的没有明显感到基线的好处，只是评审通过一个文档就控制起来不让修改等等。基线体会并不深，希望听听大家的实践

不是所有的工作产品都需要打基线，有选择的的做基线就行

本人认为。基线是一个比较模糊的概念。基线是一个阶段的产品，又作为下一个阶段的开始，可以算是一个里程碑。但基线注重的是产品和成果的内容。
但在现实的工作中，基线应扩展开，作为一个稳定的阶段，都可以看成是一个基线，用来进行下一步的开发。

参考[url]http://bbs.scmlife.com/thread-2022-1-1.html[/url]里面的图片，如果工作产品满足图片里面说的作用，就做基线，要不就不用。
功能基线，分配基线，产品基线，测试基线不太好理解，容易让人混淆，CMM/CMMi里面也没有要求要分这样的基线，不用这么麻烦吧。

每一个基线的确认是否都需要经过评审？

打基线可以按照项目计划的里程碑去打，有变更之前是必须打的。

我认为基线其实就是一个基础，下一阶段工作的基础～～

并不是一定非要有什么需求基线、设计基线、测试基线，应该看项目本身的情况，以及采用的策略。

我们公司关于基线的定义:
Project baselines are created when a significant milestone is completed, or it is critical to capture significant work. All CIs placed into a baseline require adherence to established change control rules. CIs are approved for placement into a specific baseline on the authority of the responsible TDM after sign-off by the inspection/review team. The development team member chosen as the moderator for the inspection/review of the CI has sign-off authority.  Baselines build upon previous baselines.

不是很明晰,也没有明确的说明,我想应当是在每个SCMP里面详细规定何时生成基线,并且那些配置项会放入基线里的吧

反正至少每个release就是一个baseline了,我想,其他的何时还要打呢?

基线的建立以打lable是否可以？

在你做配置管理计划里就要做出基线计划，包括基线类别（有哪些基线），基线的内容（需求、设计……），基线的建立时机（比如需求结束），基线的变更策略（变更授权或者变更流程），基线的命名标识。
        要做出这些计划，首先要搞清楚你的高层以及项目经理愿意花多少因为基线从计划、审批、发布、以及变更维护等引起的工作量来平衡因为不设置基线策略或者基线没有控制好而导致的项目开发的工作量。这样，你才能划分你的基线，否则基线划得太多，由基线变更引起管理工作量过大，基线太少，没有达到控制的效果。
        基线的内容，我认为一般至少要有两个基线，即需求基线和产品发布基线。需求变更是引起项目变更的最大来源，所以在需求阶段结束，产品需求说明书被评审后，即可建立需求基线。在产品正式发布给客户前，要建立发布基线。
        关于基线类型和基线内容，我打算以后重新开贴和大家讨论，因为在实际的工作中，我们公司的配置管理员总是把基线设置为以下基线中的某几种，需求、设计、编码、集成、测试、发布。但是在我看来根据项目生命周期模型的不同，这种定基线的方法不适合所有的项目。比如，对于一些增量开发的项目，完全可以设为第一次增量、第二次增量……。因为有些采用迭代和增量的项目，很可能就是连需求也一起迭代或者增量了，即需求并不时一开始就能很清晰地定义下来，那么要等到所有需求都出来再建立需求基线的话，恐怕项目也快结束了。
       关于基线的建立时机一般按照项目计划里的进度建立就可以了。
      基线的变更策略，大家都知道一旦纳入基线的内容是不允许随便更改的。那么如果一个项目中就界面出现了一个错别字，需要走那么繁琐的流程吗？这种情况下，就推荐对于引起不同工作量大小的变更有不同的策略，比如工作量小于5人日，项目经理可以直接授权，大于5人日必须经过ccb的审批，也可以采用对不同的基线设置分类，比如将基线分为正式基线和非正式基线，正式的基线必须通过ccb批准，非正式的基线由项目经理和负责变更的开发人员共同决定是否要变更。
        基线的命名规范在这里不多说了。
        在配置状态包括理，一般会有基线与配置项的对应关系。对于做产品的公司，这个关系维护起来会比较费事，但是也相当重要，对于做项目的公司，个人觉得有些形势，基本上不会有太多人在意，当然如果纯粹为过cmmi的话，那是另外一回事了。

[quote]原帖由 [i]maqlpony[/i] 于 2007-2-6 11:55 发表
基线的建立以打lable是否可以？ [/quote]

我觉得可以～～

基线已何种方式建立本来就是形式的东西，关键是能随时取出该条基线

发表点点想法

基线是特殊的里程碑，里程碑不需要每个都评审，基线是必须经过评审（当然每个公司的情况不尽相同啦）。经过评审的基线是必须有变更申请才能修改的。

写的很清楚~~~~~~~~~~~~~~~~~~~~`

我们公司是用CC的，感觉在UCM中基线的概念很明确
而在BASB下基线的概念就很模糊，通常就被label所代替了label即基线，基线即label

CMMI中基线的定义是指关键阶段末形成的工作产品的快照，是前一阶段的工作成果的总结，下一阶段工作的基础。

[size=5][size=6][size=5]我们公司对基线创建和变更的定义，仅供参考[/size]

[/size][/size][size=4]基线创建和变更
a)        由项目经理或者项目经理授权SCM人员发送邮件给SCCB成员，提出建立或者更改基线
i.        邮件的内容必须包括建立基线的名称以及SCCB以什么方式（邮件，会议）确定基线
b)        SCM人员按照SCM规程定义中基线审核方法审核基线，填写《配置项记录表》中的基线库审核问题报告sheet，并且把问题报告发送给SCCB成员
c)        SCCB负责人组织SCCB成员用邮件或者会议的形式确定以下内容
i.        SCCB确认基线库中的配置项符合软件基线
ii.        SCM报告的问题得到解决
iii.        SCCB同意建立新的基线
d)        如果SCCB没有通过新的软件基线
i.        SCCB负责人确定人员跟踪解决SCCB发现的问题
ii.        SCCB负责人确定何时由什么方式（会议还是邮件）再次确认建立新的基线或者更改基线
e)        如果SCCB会议同意建立基线，SCM人员在开发库上用《配置项记录表》中的软件基线页定义的基线名称打上Label，填上备注，说明这个基线的配置项
f)        把这个基线中的配置项文件Add到受控库的相应目录，在受控库以相同的基线名称打上Label，填上备注，说明这个基线的配置项
g)        SCM人员发送邮件给项目组，声明建立新的基线
i.        邮件的内容包括建立基线的名称，建立基线的时间，以及基线包括那些配置项[/size]