查看完整版本: 一个项目的所有配置项都需要放到版本库中进行管理吗?

一个项目的所有配置项都需要放到版本库中进行管理吗?

您好,我有一个问题需要您的帮助...

我所在的公司最近推行使用SVN做为公司的配置管理版本控制工具,
在网络上搜索到的大致应该做为配置项的有以下一些,
1、项目计划；
2、SCM计划；
3、需求定义文档（RDD）；
4、分析、设计、代码、测试和审核标准；
5、系统分析文档（SAD）；
6、系统设计文档（SDD）；
7、系统原型；
8、系统测试说明；
9、系统测试计划；
10、程序源代码；
11、对象代码和执行文件；
12、单元测试说明；
13、数据库设计文档；
14、测试数据；
15、项目数据；
16、用户手册
将它们总结出来可以分为三个主要类别：
（1）计算机程序（源代码和可执行程序），
（2）描述计算机程序的文档（针对技术开发者和用户），
（3）数据（包含在程序内部或外部）

在一个项目下产生的所有配置项, 这些配置项是否都要放到同一个SVN版本库中进行管理呢?

如果是将除源代码之外的文档全都放到版本库中进行管理,那每修改一次,就会增加整个库的版本号(包括代码的版本号),

是这样的吗?这需要如何才能解决啊?

Re：一个项目的所有配置项都需要放到版本库中进行管理吗？

其实楼主的问题就是配置项识别的问题；
配置项识别和标识是配置管理的一个大头戏；
每个公司都有自己的定义标准；
网上也有很多这方面的介绍；

这里有一个“配置项控制等级分类”不错：

Control Level
There are some situations leading to multiple levels of control include the following:
        Differences in the levels of control needed at different times in the project life cycle
        Differences in the levels of control needed for different types of systems
        Differences in the levels of control needed to satisfy privacy and security requirement for the configuration items
CM should design a suitable control system according to the characteristics of projects. Generally, there are three levels of CM defined as follows:
Level 1: The CIs need not undergo a rigorous version control and change control.
Level 2: The CIs need to be under manage and control
Level 3: The CIs need to be under Configuration Management Control
The examples stated under each control level are a suggest list and may be modified as per the specific needs.
The level of configuration management to be followed by a project or P&Q or training group would be identified and documented in the respective document.

1        CIs under Level 1 CM
CIs which need to be defined and maintained in a project are identified under Level 1 CM. These CIs need not undergo a rigorous version control and change control. The definition will include the location and access control mechanism for these CIs so as to allow them to be stored and accessed appropriately.  
Typical configuration items for Level 1 CM are:
        Minutes of Meeting
        PMC/Issue/Risk Log
        QA audit reports
        CM Log and Reports
        Peer Review Reports
        Quality Records
        Status Reports
        Status Review Presentation
        Initial Estimation papers
        Correspondence having contractual implications
        P&Q Records
        Training Records
        Risk Repository
        SPI/Training/Skills Database
        Pilot documentation for organizational innovations, records created for DAR, etc.

2         CIs under Level 2 CM (Manage and Control)
CIs for which baseline needs to be established and maintained is identified at manage and control level. The project/group would need to maintain and track different versions of the CIs. Management documents such as plans and metrics can be put under mange and control.
Typical configuration items for Level 2 CM (Manage and Control) are:
        Technical Proposal
        Project Management Plan, Schedule, CM Plan, QA Plan, QPM Plan
        Size Calculation document
        Estimation document
        Requirement Traceability Matrix and Most of the metrics
        Work breakdown Structure
        P&Q Plan, Process Improvement Plan, MA plan and Organizational Training Plan etc.

3        CIs under Level 3 CM (CM Control)
CIs for which baseline needs to be established and maintained are identified under CM Control. The change to these CIs shall follow formal change procedure. Engineering documents and other important documents shall be put under CM control.
Typical configuration items for Level 3 CM (CM Control) are:
        Project Initiation Document
        Requirement Definition Document
        Requirement Analysis Document
        Design Document
        Software Codes
        Test Case
        Test Data
        Test Report
        User Manual
        Postmortem

关于此部分内容的原帖也在本论坛上；
联接是： [url]http://www.scmlife.com/bbs/thread-1886-1-1.html[/url]
楼主可以去看看！

楼主也可以去这个帖子： [url]http://bbs.scmlife.com/thread-12971-1-1.html[/url]
里面是关于软件配置管理的相关资料；
内容还是相当丰富的；
关于配置项的识别也做了相关的介绍。

我摘抄一部分相关知识与你共享：

三．关键活动
1 配置项（Software Configuration Item，SCI）识别
    Pressman对于SCI 给出了一个比较简单的定义：“软件过程的输出信息可以分为三个主要类别：（1）计算机程序（源代码和可执行程序），（2）描述计算机程序的文档（针对技术开发者和用户），以及（3）数据（包含在程序内部或外部）。这些项包含了所有在软件过程中产生的信息，总称为软件配置项。”由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。
    软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线（Base Line）”这一概念。IEEE 对基线的定义是这样的：“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
......................

引用楼主的话:
如果是将除源代码之外的文档全都放到版本库中进行管理,


楼主怎么可把源代码排除在外呢,我理解的配置项中源代码才是最重要的啊....