如何更好的控制基线后的配置项

xixiaojing666

下面说说建立基线后的代码和文档的控制：
我们代码和软件工程的文档在建立基线后，控制手段不太一样。文档的控制是严格的按照变更流程进行执行的。配置项进入基线后，写权限就关闭了，只有读的权限。
流程如下：
变更申请->评估变更大小->审批变更申请->安排变更任务->执行变更任务->对更改后的配置项重新进行SCCB评审->结束变更
其中评估变更大小是由项目经理来进行评估；如果是大变更，项目经理交给SCCB来审批；如果是小变更，由项目经理进行审批。
但是单元测试完成后的代码基线，我们不般不把写权限进行关闭，因为在以后的测试过程中，变更的次数很多，所以只要开发人员在变更时通知PM、CM和相关人员，就可以了。

不知道各位是如何控制代码基线的，欢迎大家来讨论！


上一篇：关于产品分支管理的讨论
下一篇：Subversion培训教程

xixiaojing666

原帖由 iamredeye 于 2008-5-8 20:23 发表
楼上的只baseline代码?

这样的话在project level实际上基本上就没有change control了。在release level（如果存在的话）有change control，但只关注代码。

不知道我理解的对不对。

代码基线也有变更控制,但是由于变更比较频繁,所以我们控制比较松.但是每个变更还是都记录的,一般用打标签的方法,便于追溯.

不是很理解你后一句话是什么意思:)
是说产品基线的变更只关注代码这个配置项吗?

xixiaojing666

原帖由 fishred 于 2008-5-8 15:48 发表
我们一般按照系统上线来分，至于具体代码的变更，通过打标签来控制，至于流程上面大致时这样的：
需求变更－分析设计－评审－编码－发布，建立代码基线，代码基线是批量化的

代码基线是批量化的是什么意思?:)

xixiaojing666

能不能请教一下你们的lifecycle model是什么？waterfall，rup,agile，或近似?

我们生命周期一般都是瀑布的,迭代的还没有用过,说实话对迭代模型还不是很了解.:loveliness:

要向我们论坛里的高手多多请教了:lol

[ 本帖最后由 xixiaojing666 于 2008-5-8 21:14 编辑 ]

xixiaojing666

这个比喻很好，但是我觉得，真正能实现这个比喻的，恐怕没有。

细想想，计划都在头脑里，一周的事情恐怕能记清楚，但是一周以上的事情呢？
还有就是除非你自己一个人做项目，否则计划怎么沟通呢？别人怎么能知道你脑子里的计划？

xixiaojing666

原帖由 iamredeye 于 2008-5-22 17:44 发表
关键是，迭代的phase和瀑布的phase关注点是不一样的，没弄清楚这一点就比较麻烦了。迭代关注的是risk，瀑布关注的是deliverable。

有时间给我们详细讲讲他们关注点的区别！:lol

xixiaojing666

原帖由 iamredeye 于 2008-5-27 10:49 发表
这个有点难度啊:Q ，人家可是用一本书的篇幅在讲

你可以挑一两个关注点给我们讲讲呀!:lol

xixiaojing666

感谢一下!
继续支持:victory:

xixiaojing666

原帖由 jiayan2000cn 于 2008-6-13 17:06 发表
这些内容我现在比较关注!

你可以在这里提出你的关注问题，或经验分享呀！:)