配置管理问题单(1)

自我介绍

姓名，在公司负责项目的配置管理和组织级的配置管理。（注：组织级配置管理主要针对EPG、培训、组织级QA的工作产出管理）

Configuration Management

1、 (SP1.1) 请叙述您如何识别项目的配置项? (代码如何划分？)

项目策划阶段，项目经理对项目的过程进行裁剪，制定《项目定义过

程》，根据项目定义过程可以知道项目中有哪些产出物需要被管理，然后

在《项目配置库目录》中识别这些产出物的属性，区分出配置项和数据

项。配置项是指那些会有版本变化的文件或代码，数据项没有版本变化。

配置项的命名规则：公司名—项目名称—过程域—项目文档-版本号。

配置项有：项目计划书、产品源代码、需求规格说明书、项目设计说明

书、用户手册、测试用例等。这些产出物是可能会变更的。

数据项有：项目度量数据表，项目周报、周会议记录，里程碑会议记录、

里程碑状态报告、验收报告、决策分析报告等。这些产出物没有变更的特

性。

代码划分：我管代码，代码划分成多个配置项。一般按照功能模块来划分

管理。代码会变更。都放在SVN上进行管理。

2、 (SP1.2) 请叙述您项目的配置管理系统以及如何建立?如何申请及建置

呢?

配置管理系统有两个目录：组织级和项目级。

组织级有财富库，工作库。财富库只有我是读写权限；工作库，我和EPG

是读写权限。财富库有OSSP（标准过程文件）、经验教训、可复用库、

度量库。

项目级有四个库，开发库，管理库，基线库，产品库。开发库中项目各个

人员都有自己的个人文件夹，个人拥有读写权限，项目组人员的日常工作

都是在开发库完成的。评审通过的文件放在管理库，大家都是只读权限，

我和PM有签入签出权限。基线库放基线文件，只有我能读写，其他人只

读权限。交付的文件放在产品库，只放客户要的版本，只存放1个版本的

产品，产品库只有我有签入签出的权限，其他人员是只读的权限。代码是

在开发阶段开始我会管理，代码会建立一个大的版本，每次变更的时候都

会打新的版本。代码如果修改需要填写申请表，然后我会进行发布，每次

发布都会进行版本的变更，我们在SVN上有不同的目录，没发布之前（开发的时候）会在主干，如果测试需要修改bug或者变更需要修改代

3、(SP1.3) 请叙述您如何及何时将工作产品设立基准?如何公告与发行基

准？目前发行了那些基准？ (编码变更如何处理? 集成测试后如何标识源代码？)

要纳入基线的文件，先要评审通过，基线建立流程：PM提交基线建立申请单，我会去对要纳入基线的文件进行功能审计，通过之后，我把要纳入基线的文件从管理库签出，签入到基线库，然后我会进行物理审计，审计通过，我提交基线发布报告给CCB，CCB审批通过，我会填写《基线发布报告》我发邮件给项目组成员告知他们基线已经创建。我们有四类基线：需求基线主要有需求规格说明书，评审通过可以纳入基线，需求阶段纳入；设计基线包含系统设计，包含接口设计书，数据库设计说明书，评审通过后在设计阶段纳入基线；测试基线包含系统测试用例，集成测试用例，源代码，在开发

阶段末期创建，文档评审，代码评审通过，代码调试通过后可以纳入测试基线；产品基线在测试阶段末期创建，有用户手册，产品源代码，执行文件，bug得到修复，用户手册通过评审可以建立。代码是列入测试基线的，测试人员按照测试基线中的代码版本进行测试，测试过程中的代码开发人员没有修改权限，代码每次有变更要写《代码修改申请表》，通过之后我要有《代码发布的报告》，每次变更之后代码的版本要变化，目前大概都要2个版

4、 (SP2.1) 请叙述您的变更需求追溯流程?

我们变更会有《需求变更申请单》，PM组织大家确认是否做这些变更，项目经理在《需求变更的跟踪表》中会分析出哪个模块下的需求要变更，有哪些配置项受到影响。然后我将相应的文件签到开发库，让相应的人员进行修改，修改完成之后走基线申请流程，重新建立基线。《配置项状态报告》也会把变更情况写上去，写明是因为修改bug的原因还是需求变更的因。然后我会把修改过的情况告知大家。项目变更大约有1次变更，分别在设计阶段，差不多有8-10个左右的变更。

5、 (SP 2.2) 请问您如何管理配置项(不被不当变更)？

我们通过SVN权限管理，在配置管理计划中写明了每个库的权限，发现配置项变更要走变更流程，我会问询问PM大概要多少时间能修改完成，然后跟踪这些配置项。我们开周会议的时候也会报告这些配置项变更的情况。我们每个代码分了多个配置项，每次提变更如果影响代码的话要在《需求变更跟踪表》中写明要修改哪个代码配置项，我就把那个代码配置项签回到开发库，其余的代码配置项是没有修改权限的。配置项要从开发库到管理库的时候会进行评审，PM会组织评审会议，评审通过之后才能签进来。

6、 (SP3.1, GP 2.6) 您会产出那些配置管理纪录?这些记录会被如何使

用？

有配置项状态报告，功能审计报告，物理审计报告，基线发布报告。如配置项状态报告用来跟踪和报告配置项状态。配置项状态有基线、变更、受控、未受控等。

7、 (SP3.2)您的项目中如何确保配置管理程序被有效落实？如何确保配置

管理内容及基准的正确性与整体性？(有没有发现问题？)

功能审计是在建立基线前及变更的时候执行的。功能审计由我执行的。看配置项是否符合设计、开发、测试的需要。物理审计在基线建立后由我执行的。物理审计看配置项存放位置和命名是否正确。审计出来问题会写在《不符合项管理表》中，QA跟踪解决。

Generic Practice

8、 (GP2.1) 就CM过程，请问组织是否订定有过程相关方针? 您如何在项目

中使用这些方针？

CM（配置管理方针）：配置管理人员必须将新版本的基线准时准确地告知项目组。

记录在EPG制定的《组织方针》文档中。

9、请问您如何规划CM工作？包含执行方法与执行规划，如何提供执行过

程所需之权责与资源？

A、 (GP 2.2)项目过程规划?

项目级《配置管理计划》，策划阶段，CM写，包括人员职责，配置管理目的，基线建立计划，基线变更计划，库的结构权限设置，配置项命名规则。组织级《组织级配置管理计划》类似

B、 (GP3.1, IPM SP1.1)项目过程定义？

项目经理执行《项目定义过程》的时候会写明配置管理过程的裁剪情况。项目都是中等规模和小型规模的项目，开发基线被裁剪了。

C、(GP 2.3) 提供资源

SVN管理工具，电脑，办公场地，办公软件，写在《配置管理计划》中。

D、(GP 2.4) 指派权责

职责在《配置管理计划》中写明，CM要通过SVN进行版本控制，备份。QA，CCB，项目经理这些人员的工作也说明在配置管理计划中。

E、(GP 2.7)识别及纳入干系人

《配置管理计划》，EPG，项目经理，设计，开发，QA，测试

10、 (GP 2.5) 请问就CM工作，组织及项目识别及提供了那些培训给您？

我接受过SVN配置管理工具的培训，CMMI的培训，过程文件的培训，新过程文件的培训，配置管理培训。

11、 CM过程如何被监控？(CM, GP 2.8)

项目级：项目经理定期监督我的工作，通过周会议，里程碑来监督我配置管理的工作。

组织级：EPG召开月度会议，监控CM工作。

12、 CM 过程如何被检查其与相关标准及规程的符合性？(GP 2.9 , CM ) QA用《过程检查单》和《产品检查单》2周一次检查我的工作流程和产出物的规范性，将发现的不符合项记录到《不符合项管理表》，跟踪我解决不符合项。

13、 CM的产出与经验如何被收集及反馈，如何运用这些产出及经验？(GP

3.2)

我提交与CM相关的经验教训和改进建议给EPG，EPG评审通过后纳入财富库。

改进建议：配置管理规范里面对配置项的完整性，正确性定义不清楚。配置项状态多了个未变更。

Non-Model issue

14、 Q1:过去一年是否有什么比较明显的改进？

15、 Q2:改进：认为公司可以优先改进的项次是什么？

配置管理工具简介

配置管理工具简介要说配置管理工具，就要说到配置管理，因为配置管理工具是软件配置管理过程中所使用的一些工具，要了解配置管理工具，首先就必须了解配置管理。一、配置管理工具的定义：软件配置管理的定义有很多，现在我只说一个我觉得定义的必要好的定义。它是：“协调软件开发使得混乱减到最小的技术叫做软件配置管理，它是一种标识、组织和控制修改的技术，目的是使错误达到最小并有效地提高生产效率。”它贯穿整个软件生命周期并应用于整个软件工程过程，是软件工程中用来管理软件开发的规范，也是CMM（软件能力成熟度模型）二级中关键过程域。软件配置管理是软件质量改进的核心环节，它贯穿于整个软件生命周期，为软件改进提供了一套解决办法与活动原则。二、软件配置管理的目标：软件配置管理的目标是标识变更、控制变更、确保变更、和报告变更，它主要完成以下几种任务：标识、版本管理、变更控制、配置审计和配置报告。三、配置管理工具的主要功能：配置管理工具作为配置管理过程中使用的工具就理所当然的具有以下功能： 1).并行开发支持：因开发和维护的原因，要求能够实现开发人员同时在同一个软件模块上工作，同时对一个代码部分做不同的修改，即使是跨地域分布的开发团队也能互不干扰，协同工作，而又不失去控制。 2).修订版管理：跟踪一个变更的创造者、时间和原因，从而加快问题和缺陷的确定。 3).版本控制：能够简单、明确地重现软件系统的任何一个历史版本。 4).产品发布管理：管理、计划软件的变更，与软件的发布计划、预先定制好的生命周期或相关的质量过程保持一致；项目经理能够随时清晰地了解项目的状态。 5).建立管理：基于软件存储库的版本控制功能，实现建立过程自动化。 6).过程控制：贯彻实施开发规范，包括访问权限控制、开发规则的实施等。 7).变更请求管理：跟踪、管理开发过程中出现的缺陷、功能增强请求或任务，加强沟通和协作，能够随时了解变更的状态。 8).代码共享：提供良好的存储和访问机制，开发人员可以共享各自的开发资源。四、常见配置管理工具简介：配置管理工具有很多，一下我对一些常见的配置管理工具做一简单的介绍。 1.元老：CCC、SCCS、RCS 上个世纪七十年代初期加利福利亚大学的Leon Presser教授撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为Soft Tool的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。在软件配置管理工具发展史上，继CCC之后，最具有里程碑式的是两个自由软件：Marc Rochkind 的SCCS (Source Code Control System) 和Walter Tichy 的RCS (Revision Control System)，它们对配置管理工具的发展做出了重大的贡献，直到现在绝大多数配置管理工具基本上都源于它们的设计思想和体系架构。 2.中坚：Rational Clear Case

操作系统安全配置管理办法

编号：SM-ZD-96562 操作系统安全配置管理办法 Through the process agreement to achieve a unified action policy for different people, so as to coordinate action, reduce blindness, and make the work orderly. 编制：____________________ 审核：____________________ 批准：____________________ 本文档下载后可任意修改

操作系统安全配置管理办法简介：该制度资料适用于公司或组织通过程序化、标准化的流程约定，达成上下级或不同的人员之间形成统一的行动方针，从而协调行动，增强主动性，减少盲目性，使工作有条不紊地进行。文档可直接下载或修改，使用时请详细阅读内容。 1范围 1.1为了指导、规范海南电网公司信息通信分公司信息系统的操作系统安全配置方法和日常系统操作管理，提高重要信息系统的安全运行维护水平，规范化操作，确保信息系统安全稳定可靠运行，特制定本管理办法。 1.2本办法适用公司信息大区所有信息系统操作系统安全配置管理。主要操作系统包括：AIX系统、Windows系统、Linux系统及HP UNIX系统等。 2规范性引用文件下列文件对于本规范的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本规范。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本规范。 --中华人民共和国计算机信息系统安全保护条例 --中华人民共和国国家安全法

软件开发项目配置管理工具的选择

软件开发项目配置管理工具的选择通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改；但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。常见的配置管理工具正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制

软件配置管理过程指导说明书(超级实用)

软件配置管理过程指导说明书

目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)

1 前言 1.1 目的用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性；验证配置库内容的完备性和正确性等。

35配置管理办法

配置管理办法文件名称：配置管理管理办法文件编号：ZHWH-CM-01-2017 文件类别：技术管理编制部门：北京中航鼎成科技有限公司质量管理部版本号： A 文件密级：秘密受控标识：受控拟制/日期：黄妙然 2017年09月27日审核/日期：刘晔 2017年10月15日会签：批准/日期：杨成 2017年11月1日

修订页

目录第1章目的和范围 (1) 第2章角色和职责 (1) 第3章定义和术语 (2) 第4章配置库管理及规划 (2) 第5章配置管理流程图及活动说明 (2) 5.1 研发配置管理流程图及活动说明 (2) 第6章度量数据收集 (6) 第7章相关文件和记录 (6)

北京中航鼎成科技有限公司配置管理管理办法第1章目的和范围为规范北京中航鼎成科技有限公司在项目生命周期过程中的配置管理活动，确保在项目的整个生命周期中建立和维护项目产品的完整性、正确性、可追溯性和一致性，保证项目过程中配置管理相关工作满足公司质量体系要求，特制定北京中航鼎成科技有限公司配置管理规范。本文档适用于北京中航鼎成科技有限公司所有项目的配置管理活动。第2章角色和职责

注1：“配置变更控制”参见《TDCS/CTC综合维护平台产品变更实施细则》，本文不再说明，配置项拟审批原则参见《北京中航鼎成科技有限公司配置项清单》。第3章定义和术语（1）基线：BaseLine，就是经过正式评审和认可的工作产品，它是以后进一步开发的基础。基线分为过程基线和交付基线。（2）配置项：配置是指在项目生命周期各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合，该集合中的每一个元素称为该配置中的一个配置项。配置项分为基线配置项和非基线配置项。（3）基线配置项：一般组成产品元素的配置项均要定义成基线配置项，如产品需求、设计文件、源代码、测试文件等均要定义成基线配置项，基线发布后所有的变更都要严格按照《北京中航鼎成科技有限公司产品变更实施细则》执行。（4）非基线配置项：一般非产品组成元素的配置项可以定义为非基线配置项，如项目计划、评审类等。非本项目控制的工作产品，但为了共享和最新版本的获取，该类元素作为非基线配置项也纳入配置管理库，如外部文件、标准、参考文件、会议纪要、工作报告、过程记录等。第4章配置库管理及规划配置库管理及规划如下： 1)研发项目（含工程项目的定制开发）：按照产品线进行规划管理； 2)工程项目：按项目管理、工程实施过程两大块进行规划管理；第5章配置管理流程图及活动说明 5.1 研发配置管理流程图及活动说明 5.1.1研发配置管理流程图

16软件配置管理报告

份号：001 密级： XXXXXXXX项目软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日

辑要页

文档修改记录

目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2)

1 范围 1.1 标识本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述本条应概括本文档的用途和内容，并描述与其使用有关的保密性考虑。 2 引用文挡本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述本章应描述软件配置管理活动进展，与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息本章应概述软件配置管理的基本信息，包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配，如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等，权限可分为读出、增加、替换、删除等。 6 配置项记录本章所列出项目的所有配置项，包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。

软件配置管理流程

配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________

目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)

1.配置管理流程 1.1概述规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图

1.3软件需求分析阶段参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护开发人员

海湾配置管理工具的使用

火灾自动报警系统是在保护对象发生火灾的情况下自动探测、显示发出火灾警报的装置。它广泛应用于现代化工厂、物资仓库、高层建筑、计算中心等建筑物内，对保证人民的生命和财产安全起着巨大作用。火灾自动报警要经历安装、接线、调试、验收等诸多环节，其中调试是其中最重要的一个环节之一。说起调试，每个火灾自动报警系统都有其特有的调试软件，而每个厂家的调试软件只有其相关的调试人员才会接触到，相对于普通人来说也是比较神秘的，下面国产火灾报警品牌巨头一海湾的进行揭秘。首先打开海湾调试软件工具，屏幕会出现输入密码界面输入密码后进入GstCfg配置管理工具界面，界面有标题栏、工具栏、状态区域和编辑区域组成。

WRIVJ.A 右击状态区域内“控制器”可以添加控制器操作，GstCfg配置管理工具可添加的控制器有GST20C火灾报警控制器、GST500/5000 火灾报警控制器、GST900C火灾报警控制器、DH9000电气火灾控制器、以及KR9000可燃气体报警控制器。控制器添加界面可以对控制器的名称，是否联网、以及新老国标等基本属性进行选择。

控制器添加完成后进入如下界面，在这了我们添加一个新国标地址号是01的GST500C型火灾报警控制器欝E.H k^ITEHlJ-A A EW4U眠皿活冋1SB 畑：fi ------------------- ■ j ■* 可以在左侧框内的GST5000C控制器右击选择添加回路，选择回路数量进行添加。添加好的界面如下

图中右侧显示的就是设备定义的界面，在这里可以完成对所有设备定义数据的填写。最左边的一列是设备的二次码，选中右击二次码可以对其进行批量修改。 ML 士 HS-ti p -yi | mmv ■■ 離 ?皿心卸 Et? ■F ■?; *g ■ Mimi I q ? mum ? 卜 ii 1 卫 L J Ml?]i | iSH> M G . 口亠■史曲 ■ :石「 '| E P L \ b □ 1 B —帛?P L ?吐皿 Q fl 4 HKOt 阿沁0 □ ■ i 沁〈亍6 * 4 * V M IO? 1 t .：.?■：：:? >Q 4 | 1 i ?l?St 1 I I 0W"*E 0 L j 0 $ 川1 otltlt D L Qb”利1 ? 上理_； M |?|| fn- AhB D u 51- PS.m 1 h 一 ^ b 白會 nsn 0?i-5HE 0 ￡ a>*3 Rfl J ~0 4 "t Al M IMF t 曲祐i b 1 Q V [| (^ICM OCMH 0 k 1 H 「 1 口*飓6 I 口 4 if 1 W 1 wi?ir CW4HL D ._"L g fi 曾 'P ' wwii 1 "T "?■ #￡厂 t 1 6 i i ' il DMAII D C n> A949I □ ；M bMtt i ? i> *!?■? 1 fi ；n t awt-^'S n U S *9 J 口 4 HUtil X 蘇Q k 汁”枕 0 I ；裁?1?2f ' t gMt 0 L as 1 4 i 31 i i g?p-M Q . k "■却捆 n ii ■ i 亦a 沁"厂 k H ■■盟耐 Q 4 |T ?J0? & MHK P 匚岭彗r.g 1 Q I * NIKI ￡M?E 0 =H 联1 I 4 i￡ —慣呻一 MMNE 6 I ? * . 1

公司员工手机配置管理办法

员工统一发卡使用与管理办法一、目的为确保公司信息的及时交换，提高客户服务质量和工作效率，规范公司管理特制定本办法。二、适用范围 1、主管级别（含）以上员工。 2、部分因业务需要的员工（业务员、送票员、地州送票员）。三、流程 1、需要配置手机的员工，统一到行政人事部报名登记，由公司统一发放。 2、行政人事部负责与通讯公司联系办理购卡业务。 3、员工必须报行政人事部备案，由行政人事部统一建档管理。四、具体要求 1、员工在职期间使用公司手机卡必须 24 小时开机，保证通信畅通；如出现关机、停机、无人接听等现象，每次罚款 50 元。 2.若手机出现没电、故障等原因造成暂时无法接通的，应第一时间告知上级主管临时联系方式 3.手机卡丢失或损坏的，应第一时间告知公司， 24 小时内补办手机卡并开通，费用由使用人自行承担。 4.员工不得私变更手机卡。 5.员工使用公司手机卡期间不得利用公司手机卡从事任何违法违纪活动，造成恶劣后果的交与司法机关处理。 6.员工离职应将手机卡交还公司，损坏补卡及所欠话费由使用人承担。 7.主管有监督员工手机卡使用的权利和义务，对员工因联络不上对公司造成的损失，公司将视情况追究其主管的连带责任。员工必须公私分离，不得混淆或有意公私不分，使用公司电话做与工作无关事情，不得再留个人号码给客户或工作关联事宜。五、补贴标准 1、50元/人/ 月？

六、手机卡管理办法 1、每月月底打印上月通话记录微信： 1. 公司配发的手机卡，销售人员必须用公司号码申请一个微信账号，微信号为公司名+手机号码。 2. 所有公司微信账号，昵称必须改为：公司名 +姓名+电话号码。 3.所有公司微信账号，头像必须换成手机持有者的照片（或者公司 LOGO）。 4.公司在微信群发出的通知，所有员工在网咯畅通的情况下必须在两小时之内回复。如收到、执行、马上执行之类的语言，不可见之信息淡漠而视。（特殊情况请做出说明） 5.公司组织的发朋友圈信息活动，所有员工必须无条件的执行。 6.所有销售人员，客户有需求加微信（不主推），必须加到公司微信账号上，不得加到自己私号上。 7．公司不定期抽查销售人员公司微信的对话框中的好友交流时间、人数等等。 8.以上有关微信管理制度的条规，如有违反，每次罚款 50 元，依次叠加。 9.配备手机人员，离职时，不得将工作微信删除，不得将好友删除。如有发现，将扣除最后结算工资。 10、上报用户名及密码监管。

配置管理流程

配置管理流程 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT

简介业务目的：为解决、控制过程及部分服务交付过程提供需要的配置项及其属性信息。 IT 目的： 1)建立一个完整的配置项管理框架，降低了无控制环境变更的危险性； 2)CMDB提高支援及各类服务活动的效率和品质，确保服务交付流程如连续性、容量等良好运作。适用范围此流程适用IT管理手册中定义的服务范围。相关流程 IT服务管理手册 (QM-ITSM-2011) 服务规划及管理流程(OP-ITSM-004) 服务报告管理流程 (OP-ITSM-006) 事件和服务请求管理流程 (OP-ITSM-007) 问题管理流程 (OP-ITSM-008) 变更管理流程 (OP-ITSM-010) 发布管理流程 (OP-ITSM-011) 连续性管理流程 (OP-ITSM-012) 容量与可用性管理流程 (OP-ITSM-014) 信息安全管理流程 (OP-ITSM-015) 供应商管理流程 (OP-ITSM-017) 服务策划管理流程(OP-ITSM-019) 定义术语表：无角色定义表

仪器种类代号

编号格式主要设备按以下方式进行编号登记： XX9999YY XX = 仪器种类代号 9999 = 4至5位数字 YY = 地域代号内的缩写式代号内容流程解释配置管理流程从配置规划、日常运维、配置审计、配置管理检讨的PDCA循环保障CI的完整性和有效性，其中配置规划包括配置管理应用的各类规则。配置规划 (P) 5.2.1配置管理范围工具、用途说明：

ISO软件开发全套文档-配置管理计划编写指南

产品/项目系统名称配置管理计划北京XXXX有限公司 200 年××月 1引言 1.1编写目的

编写的目的主要在于对所开发的软件系统规定各种必要的配置管理条款，以保证所开发出的软件能满足用户需求。 1.2背景 a.开发的软件系统的名称列出本软件系统的中文全称、英文全称及英文表示简称。 b.开发的软件系统的最终用户或适用的领域； c.项目来源、主管部门等 1.3定义列出本文件中涉及的专门术语定义和外文缩写的原词组。 1.4参考资料列出涉及的参考资料。 2 管理描述软件配置管理的机构、任务、职责和有关的接口控制。 2.1 机构描述软件生存周期中各阶段中软件配置管理的功能和负责软件配置管理的机构。说明项目和自项目与其他有关项目之间的关系。指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的关系。 2.2 任务描述在软件生存周期中各阶段的配置管理任务以及要进行的评审和检查工作，并指出各阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控制库或软件产品库）。 2.3 职责指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责；指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系。说明软件生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动。指出与项目开发有关的各机构的代表的软件配置管理职责。指出与其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。 2.4 定义软件配置项（SCI）包括： 1．系统约定 2．软件项目计划 3．软件需求文档 4．用户手册 5．设计文档

软件配置管理计划示例

软件配置管理计划示例作者：赵文锋计划名CADCSC软件配置管理计划项目名中国控制系统CAD工程化软件系统项目委托单位代表签名年月日项目承办单位代表签名年月日 1 引言 1．1 目的本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理

2．1 机构在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

配置管理岗位职责

配置管理员岗位职责摘自：软件配置管理论坛一、配置经理的基本技能与资格资格：能够重视配置管理工作；能够按规范实施配置管理工作；积极支持部门的配置管理方面的工作；能够积极支持与帮助其他人员；为部门的配置管理能力的提高贡献力量；熟悉公司配置流程以及其他相关的流程；为增进项目管理，对于项目内的困难和关键问题，能够及时反映到部门；基本技能：能够独立规划项目的配置管理工作；熟练掌握配置管理的相关概念；能够了解配置的相关工具，熟练使用技术工程部配置所使用的工具；具有基本的与人沟通的技巧；能够了解项目管理过程中的主要环节；初步了解项目管理过程中的质量保证的各个方面；了解部分系统和应用工具，如数据库ORACLE，前台开发工具DEPHI等；二、配置经理的职责作为一名配置人员，配置经理的职责就是能够与质量人员、测试人员等共同保证项目的质量。如：作为质量保证的成员之一，能够为整个技术工程部规范化管理的推进作贡献，如宣传规范化管理的知识，陈述规范化管理的利弊等；能够在项目进行的整个生命过程中，不断的与项目经理、QA、SCCB及项目成员进行配置管理规范化的沟通，为项目配置管理的规范化作出努力. 具体表现为： ?项目进行初期或首次进入项目中时，能够首先与项目经理、QA、SCCB及项目成员就项目的未来配置管理工作进行沟通，取得项目经理、QA、SCCB及项目全体成员对配置工作的认可与支持； ?积极了解项目情况，项目各阶段的进展，为更好的进行配置管理作努力； ?熟练并充分的利用配置管理工具的各方面的功能，提高配置管理的效率； ?为项目控制好版本，保证项目各阶段所使用的版本正确； ?及时发现项目问题，把问题及时反馈给项目经理、QA或SCCB，并积极协助解决； ?与项目内其他组成员，如开发组、测试组等协调工作，并能够很好的沟通； ?能够在项目中不断总结、分析，为项目内配置管理工作的进一步优化作贡献；

配置管理工具SVN

软件配置管理工具SVN配置和使用说明战立章 2008年6月

目录第I 条第一章SVN的安装和使用说明 (1) 1.1SVN（Subversion）简介 (1) 1.2服务器SVN（Subversion）的安装和配置 (2) 1.2.1安装指南 (3) 1.2.2服务器的设置 (3) 1.3客户端TortoiseSVN的安装和配置 (5) 1.3.1安装指南 (5) 1.3.2TortoiseSVN使用说明 (5) 第II 条参考文献 (11)

第I 条第一章SVN的安装和使用说明 1.1SVN（Subversion）简介在开源领域，并行版本控制（CVS）一直是版本控制的选择。CVS（Concurrent Versions System）本身是一个自由的软件，它对用户的非限制性和对网络操作的支持—可以允许大量的分散在不同地域的程序员共享他们的工作（特性）成果，非常符合开源软件领域合作的精神。但是像许多其他工具一样，伴随着软件技术的革新，CVS开始露出了衰老的痕迹。所以，设计者在继承CVS优秀特性的基础上设计了Subversion，并把它作为CVS新的继承者。与CVS类似，程序员依然可以使用Subversion构建一个开源软件系统的版本控制过程，但设计者在设计Subversion过程中，努力弥补了CVS的一些明显的缺陷。下面将通过与CVS对比，简单的介绍Subversion为版本控制领域带来的一些新的特性。 1.版本化的目录 CVS只记录单个文件的历史，但是Subversion实现了一个可以跟踪目录树更改的虚拟版本化文件系统，记录文件和目录的所有版本。 2.真实的版本历史 CVS只记录单个文件的历史，所以CVS对那些可能发生在文件上，但会影响所在目录内容的操作（CVS并不跟踪记录目录的变更，见特性1说明）并不支持。因此，例如，复制和重命名，这些可能改变工作目录内容的操作CVS并不支持。而且在CVS中，如果一个文件搬到另一个地方或者改名，版本号将重新编。同时CVS也不支持在工作目录下用一个内容完全不同的文件来覆盖目录下的同名文件而不继承原来文件的版本历史。而在Subversion中，可以对工作目录下的文件或者目录进行拷贝和改名操作，还可以进行添加和删除操作，而且所有的新加的文件都从一个新的、干净的版本开始。 3.原子提交在Subversion中，一系列的修改要么全部提交到版本库，要么一个也不提交，这样可以帮助用户构建一个提交修改的逻辑块，防止部分修改添加到版本库。 4.版本化的元数据在Subversion版本控制系统中，每一个文件或目录都有自己一套完整的属性键和它们的值，可以建立并存储任何键/值对，并且属性是随着时间流逝逐渐纳入版本控制的。

机构设置及人员配置管理办法

机构设置及人员配置管理办法（试行）第一章总则第一条为了规范公司部门机构的设置，加强人员编制管理，明确部门、岗位职责分工，特制定本管理办法；第二条本管理办法适用于公司总经理部下辖所有部门及岗位；第三条公司机构及人员设置、调整应遵循统一、高效、精简，符合公司事业发展、业务发展、符合公司经营管理需要的原则。第二章职责分工第四条公司总经理部负责根据公司生产经营需要进行部门设置及人员配置、调整的审议、核准工作；第五条综合管理部是公司机构及人员设置的管理部门，负责公司机构设置及人员编制的管理工作及具体操作；第六条公司各部门负责本部门人员编制增减的申请工作。第三章流程第七条部门设置及调整流程: 一、公司总经理部根据公司生产经营需要设立公司部

门，并根据经营方针的变化做出增设、取消、合并、拆分公司部门的决定；二、综合管理部根据总经理部决定进行部门调整及编写部门职责等，并对公司组织架构及工作关系进行调整。第八条人员编制及调整流程：一、公司各部门根据部门工作需要向综合管理部申请本部门人员编制的增减；二、综合管理部对各部门关于人员编制变化的申请进行审核，认为合理者提请总经理部审议；三、公司总经理部针对提案讨论，认为可行者签署通过，交由综合管理部操作执行；四、综合管理部根据总经理部审议结果具体操作，对岗位及人员进行合理安排，并对该部门岗位职责进行调整。第四章监督管理第九条公司各部门应严格遵循配置流程，不得擅自增减本部门编制、调整人员及岗位职责。第十条综合管理部定期对公司部门设置及人员编制的合理性进行实地调查，发现以下情况者，汇报至总经理部，并提出整改方案：一、部门或岗位职能重复、交叉或业务相近者；二、部门或人员为某项工作任务设立，在任务完成或已被停止时，未及时提出予以撤销者;

软件配置管理规范流程模板

软件配置管理规范流程 1 概述 1.1 目的本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

配置管理计划V0.1

XXX项目配置管理计划 xxxxxxxxxxxxxxx公司20xx 年xx月xx 日

文档编号：XXXXXXXX-XXX-XXX 版本号：1.00 项目名称:XXXX项目文档名称: 版本修改内容描述修改人日期备注1.0 第一版xxx 2014.6.3 1.01修正了……xxx 2014.6.3 批准人：日期：审核人：日期：公司名称：xxxxxxxxxxxxxxxxxx有限公司地址：xxxxxxxxxxxxxxxxxxxxxxxxx 电话：010-xxxxxxxx 网址：https://www.360docs.net/doc/2710669477.html, 邮箱：mengsuran@https://www.360docs.net/doc/2710669477.html,

目录 1. 引言 (1) 1.1 目的 (1) 1.2 术语定义 (1) 1.2.1软件配置管理 (1) 1.2.2 配置管理 (1) 1.2.3 配置项 (1) 1.2.4 基线 (1) 1.2.5 变更控制 (2) 1.2.6 配置审计 (2) 1.3 参考资料 (2) 2. 软件配置 (3) 2.1 软件配置环境 (3) 2.1.1服务器软件环境 (3) 2.1.2 硬件环境 (3) 2.1.3 配置管理客户端 (3) 2.2 软件配置项 (3) 2.2.1 受控配置项 (3) 2.2.2 非受控配置项 (4) 2.3 配置管理员 (4) 2.3.1 设立的必要性 (4) 2.3.2 主要职责 (4) 3. 软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (6) 3.2.1文档 (6) 3.2.2 程序 (6) 3.2.3 基线 (6) 3.3 配置库控制 (6) 3.3.1 .权限控制 (6) 3.3.2 配置库控制 (6) 3.3.3 建立软件库 (6) 3.3.4软件配置更改 (7) 3.3.5配置文件清单的维护 (7) 3.4 配置的检查和评审 (7) 3.5 配置库的备份 (8) 3.6 配置管理计划的修订 (9) 3.7 配置管理计划附属文档 (9) 4. 里程碑 (10)

需求管理工具比较

本人从网上收集整理的几个需求管理工具- 项目管理需求是研发团队工作的起点，很多研发团队的开发过程混乱的源头都在于需求管理没有做好。这里是本人收集整理的几个需求管理系统，希望对大家有点帮助。 Rational RequisitePro Rational RequisitePro是一个强大、易用、集成的需求管理产品。而通过与Rational系列软件产品的广泛集成，大大扩展了RequisitePro及其他产品的功能，给软件工程生命周期内的各个阶段都提供了强大、方便的信息查询、跟踪、管理功能。从而能够促进更好的团队沟通、帮助管理变更和评估变更的影响，帮助验证所有的规划需求被交付物所满足、降低项目风险。网址：https://www.360docs.net/doc/2710669477.html,/software/awdtools/reqpro/ IBM Rational DOORS IBM Rational DOORS前身是大名鼎鼎的Telelogic DOORS，被IBM收购后更名为IBM Rational DOORS。DOORS 是最老牌的企业需求管理套件，通过使用DOORS/ERS，可以帮助企业更有效地进行沟通并加强协作与验证，从而降低失败的风险。通过对整个组织实施多种需求管理的方法，可以使项目的管理更加透明。它可以使企业跨越地域与组织的边界来按国际化的方式运行。

网址：https://www.360docs.net/doc/2710669477.html,/software/awdtools/doors/ Borland CaliberRM Borland CaliberRM是一个基于Web 和用于协作的需求定义和管理工具，可以帮助分布式的开发团队平滑协作，从而加速交付应用系统。CaliberRM 辅助团队成员沟通，减少错误和提升项目质量。CaliberRM 有助于更好地理解和控制项目，是Borland 生命周期管理技术暨Borland Suite 中用于定义和设计工作的关键内容，能够帮助团队领先于竞争对手。CaliberRM提供集中的存储库，能够帮助团队在早期及时澄清项目的需求，当全体成员都能够保持同步，工作的内容很容易具有明确的重点。此外，CaliberRM 和领先的对象建模工具、软件配置管理工具、项目规划工具、分析设计工具以及测试管理工具良好地集成。这种有效的集成有助于更好地理解需求变更对项目规模、预算和进度的影响。网址：https://www.360docs.net/doc/2710669477.html,/us/products/caliber/index.html