项目配置管理计划改进方法研究与案例分析_项目配置管理案例分析

项目配置管理计划改进方法研究与案例分析由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“项目配置管理案例分析”。

课程名称：《研发过程改进》

论文题目：项目配置管理计划改进方法研究

任课教师评语：

任课教师签字：

考核日期： 年

月

日 项目配置管理计划改进方法研究

配置管理工作是整个软件项目生存周期过程的一项主要而且关键的质量保证活动之一，配置管理也是软件项目开发及项目管理过程中非常重要的一项基础性工作，正确而及时地进行配置管理工作，对于在项目生命周期内建立和维护工作产品的一致性和完整性具有非常重要的意义。

配置管理的目的在于通过有效的管理软件开发过程中的所有的输出，以及对他们的变更，来保证团队的有效协作，配置管理是实施软件工程的基础。

基于以上的目的，配置管理的目标应该明确是：

提供用于识别和控制文档、代码、接口和数据库的结构框架，适用于软件开发生命周期的所有阶段；全面支撑某一特定开发及维护工作方法，能够适应各种类型的需求、标准、政策、组织机构以及相关的管理策略；针对特定的基线状态、变更控制、测试、发布版本或审计活动，生成相对应的管理信息和产品信息。

为了保证项目配置管理计划的顺利实施，立足于软件支持过程复杂性七命题，投资命题，成熟度命题，效果命题，领导命题，过程命题，文档命题，团队命题。分别都设计了对应的方案去保证项目配置管理计划的成功。

 投资命题：需要计划，配备专职人员以及管理时间和资金投入。在投资命题方面，首先需要为项目配备专职人员，即配置人员，根据项目的大小去配置。所有目录只有配置管理员有更改和书写权限；整个项目管理工具由项目负责人指定配置管理员管理；配置管理员要维护所有目录和配置项的权限，保证配置项Reader能够获得到该文档，而其他人员无权获得。

 领导命题：需要高层领导的发起、参与和支持。在领导命题方面，需要领导的自身的足够的重视，了解到配置管理的重要性，在项目启动前，聘请专业的领域专家做咨询，对项目在配置管理方面的常见的难点与一般的解决方案作讲解。

 团队命题：需要全体人员的协作和努力。在团队命题方面，每个人首先明确自己在配置管理过程中的职责与任务。软件配置管理工程师，制定配置计划，负责计划的执行和完善设计软件配置管理库、基线库，控制基线的变更、保存所有变更请求；识别/标识软件配置项，确定哪些内容将纳入基线库；把汇总基线的状态和内容及时通知相关人员；基线化软件工作产品。项目经理，协助软件配置管理工程师制定软件配置管理计划，并支持计划的执行审查软件配置管理计划，确保只选用基线库的基线来构建工作产品或最终产品。项目组成员，了解项目配置管理计划，支持配置管理工程师的工作；按照过程、规定、及工作计划的要求，提交工作产品。高级经理，主持软件配置管理计划的评审，批准产品的发布。

 过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高群体认知活动的效力和效率。在过程命题方面，其基本内容应包括：配置工具、环境；配置更新流程；配置需求变更与会议备忘录；配置备份流程；变更处理流程；工件、产品和报告的发布进程等。

以下我就以现在的项目组中的配置管理以及配置管理工具为例加以说明。

配置工具、环境：VSS（Microsoft SourceSafe User Shell），WINDOWS。说明配置库所在的物理位置。

配置人员的权限：可定义为：只读（R）－只能读取所选择的配置项；修改（C）－可读取、修改所选择的配置项；变更（N）－可读取、修改、增加、删除（可恢复）配置项，此权限通常分配给项目经理和项目骨干；完全控制（Y）－完成控制配置库。此权限通常只分配给配置管理员。

配置更新流程：开发人员要认真填写要更新的补丁清单，只要checkin到v上的JAVA与UI的相关路径下即可。配置人员在版本发布时将java，ui文件全部get，保证开发库的最新。（此操作可使用v的command命令，或者手工进行get）另外配置人员再get下来每个开发小组填写的记录。（此操作可使用v的command的命令，或者手工进行get）

按照记录抽取出相应的文件。（此操作使用excel宏定义文件工具，前提是设置好抽取文件的路径，与需要复制的目的路径，在复制文件过程中宏定义工具如报错，可以考虑复制文件时此文件已存在并且是只读属性这种情况）

将抽取出的补丁包进行备份形成一个按日期排列的补丁基线，然后将补丁包覆盖到本地的源代码上替换旧文件。（此操作可以写一个批处理完成）

用ant工具编译最新的本地源代码环境。（ant工具需要配置环境变量，如在编译环节上有变化如增加了jar包，或者开发人员新加了java包，只需修改ant 的配置文件build.xml即可，build.xml的修改这里不详细说明）

再根据开发人员填写的记录抽取出可执行文件.如cla文件和其他非编译的文件。（此操作过程中需要使用excle宏定义工具抽取已编译好的cla文件）将已形成的补丁包，放入补丁备份库中进行统一管理备份。将以抽取出来的可执行文件覆盖到需要更新的应用程序中覆盖旧文件。（此操作也可写一个批处理完成）发邮件通知开发人员，和测试人员告知此次发布完成。版本的更新执行与操作中使用的工具介绍完成。

请详细参见更新发布流程图（图表 1）

Checkin程序源码和变更登记表配置管理员GET java，ui源代码和登记表开发人员源in程序Check码和变更登记表VSS服务器开发人员以上为开发人员checkin操作和配置人员get操作，以下为配置人员在配置机上的详细操作流程配置工作机配置机操作流程如下汇总所有补丁更新登记文档本次版本发布工作结束版本补丁备份库备份操作从编译环境中抽取新生成的Cla文件编译java源代码更新源代码环境根据登记抽取 java ui源代码发布操作（更新测试环境）以上为配置人员在配置机上的详细操作流程，以下为生成文件后的发布工作发邮件此通知次更新的内容发邮件通开发人员知此次更新的内容对本次更新的进文件行测试测试服务器测试服务器测试人员

图表 1 配置需求变更与会议备忘录：项目的会议备忘录需要被维护（SCCB）。每次SCCB会议的备忘录应该按召开会议的时间来命名。文件名称的格式可以是 “SCCB日期”(日期格式为YYYYMMDD，其中YYYY是年，MM是月，DD是天)。例如在2002年6月25日召开的SCCB会议，次会议备忘录的文件的名称可以是SCCB20020625。注：SCCB会议备忘录的内容记入《变更请求与处理单》

配置备份流程：备份管理分为两部分，一是对程序的定期备份，二是对数据库的定期备份。

对程序的备份分两种：一），动态备份，可采用每天自动运行一个批处理命名对程序（java源码，ui源码）进行增量的备份，注意备份目的存储硬盘要与原代码硬盘在不同机器上进行备份。

二），静态被备份，以周或者几天为单位对项目组内的源代码（java源码，ui源码）进行全部备份，注意目录名字一定要清晰建议使用备份当日日期命名如：20060813。对数据库的备份：

因为数据库的结构变更速度要根据项目的进程情况而决定入。开发初期对数据库的变更较为频繁对数据库对备份频率可以提高。而后期数据库的改动比较缓慢频率可以降低。对数据库的备份也要采取目的硬盘与原硬盘不同的原则进行。（以上方法对生产环境与测试环境都适合）请见图示

应用服务器数据库服务器按时段备份应用程序按时段备份数据库配置管理员配置管理员备份机

图表 2  效果命题：需要明确地努力和定期地强化其效果。在效果命题方面，采用配置审计的方案来加强效果，配置审计的主要目的是通过核配置管理活动和过程，以确保这些活动和过程所产生的基线和文档是正确的，以维护配置基线的完整性。配置审计主要包括基线审计、功能审计和物理审计等。各项配置审计活动在执行时，需要一个非配置管理员小组的成员共同组成一个审计小组，来执行配置审计活动，以确保审计活动的客观性。基线审计，在计划规定的审核日期，或在基线创建或更新后，审计人员根据如下内容进行审计，检查基线及相关配置项：一），组成基线的配置项是否标识正确? 二），组成基线的配置项的标识是否惟一? 三），基线的标识是否正确?基线的标识是否惟一? 四），组成基线的所有配置项是否在库可查? 五），基线及其配置项的访问权限是否正确? 六），配置库的目录是否和计划的一致? 七），基线列表是否完整? 八），检查配置项的最新有效版本是否和开发人员使用的版本一致? 九），检查所有的基线评审是否都有项目经理的签字? 十），基线配置项记录表与库中基线配置项是否一致?

功能和物理审计主要是在变更结束或产品发布的时候进行，也有可能是事件驱动进行。在进行功能审计的时候，审计小组主要应根据如下内容进行审计和检查：一），功能需求对应的所有模块是否已经完成? 二），所有的变更请求是否已经关闭? 三），所有的基线配置项是否经过测试或评审? 四），检查是否所有的模块都有相应的测试报告记录? 在进行物理审计的时候，审计小组主要应根据如下内容和要求进行检查：一），将(合同)需求所要求的发布项(如源代码，安装文档，用户手册，运行代码等)与实际配置项相对照；检查配置项的完整性；检查配置项的一致性；检查配置项的版本的正确性。二），检查发布项产品的介质是否符合要求? 三），检查发布产品是否可以从该介质正常安装? 四），检查发布产品的评审记录是否完整? 五），检查待发布产品的访问权限是否正确?在审计完毕后，审计小组应将审计活动的结果进行记录，并对发现的问题进行处理  文档命题：需要文档（解释和沟通）支持过程活动可视化，使得复杂的智力密集的支持过程活动得到有效地控制。在文档命题方面，文档的完整与及时性决定了开发人员的效率与项目的进度。配置管理计划是项目计划集的重要组成部分，是配置管理活动的基础。其制作以软件开发计划为基础，根据软件开发计划的生命周期和其它计划安排，编写配置管理计划。配置状态报告按时间段提交，项目经理结合其他报告完成项目状态报告。其基本内容应该包括配置项状态（初始/已测试/已发布）、变更统计、基线发布信息、版本发布信息、备份信息等。基线是指正式评审与同意，用作进一步开发的基础，并且只有通过正式的变更控制才能加以更改的工作产品，基线由一个或一组相关性比较强的配置项组成，基线发布表至少应包含如下信息：项目编号、发布人、基线号、发布时间、基线包括的工件以及工件的路径、版本、负责人等。变更申请单的信息一般由整个变更过程的变更信息组成，包括：变更申请人、申请时间、变更涉及工件、变更描述、受影响方（提请人和相关方共同确定）、变更审核结果、变更追踪等。关于文档的命名规则又分为版本号标识规则与命名规则，版本号标识规则由于在项目开发过程中，很多的配置管理工具都提供版本编号规则，而不同工具的规则又不尽相同，因此一般情况对于配置项和基线的版本编号规则不做统一的规定，由项目根据实际情况确定。但是要求同一配置项或基线的不同版本的版本编号不能重复。另外，不管采取哪种标识规则，都要求所有的软件开发文档都必须要有惟一的版本号。可参考的版本号格式例如： Vm.nn，其中 m 为主版本号，由一位或多位数字组成；朋为次版本号，必须是两位数字，不足补零，例如： Vl.00。命名规则在软件项目开发过程中，需命名的主体主要分为配置项和基线两大类。对于配置项的命名又主要包括：文档类基线配置项、源代码类基线配置项、非基线类配置项。文档命名首先要准确清晰，能够很好地体现文档内容；其次要简明扼要，长度不要太长，一般要求不超过20个汉字。具体命名可根据项目的实际情况进行，可参考的命名规则如下：文档编号_文档名称_版本号．文件扩展名。其中文档的编号可按如下规则进行：文档编号长度为8位，格式为A1A2B1B2B3C1C2C3，其中：A1A2：所在的部门编号，两位大写字母，采用部门简称的拼音首字母缩写。B1B2B3：项目编号，三位数字，由组织统一分配。C1C2C3：项目文档编号，三位数字，由项目经理统一分配。源代码类基线配置项命名规则：项目编号_模块名_版本号。对于非基线配置项的命名规则：格式一般不做统一要求，由项目自己进行唯一性标识。对于软件开发产品的命名，没有最优方案，只要适合于项目的实际情况即可。

 成熟度命题：需要不断地组织学习以持续地改进全组织的软件支持过程能力。对于成熟度命题，则需要项目经理定期的组织会议，为确保配置管理工作的准确无误，并保持对配置状态的总体了解和把握，配置管理员应根据配置管理计划的要求定期进行配置状态检查，撰写配置状态报告，并对发现的问题进行处理。配置状态报告主要应包含如下内容：①配置库总体说明：上次报告日期；本次报告日期；项目所处阶段；基线配置项总数；基线总数；变更申请总数；变更总数等。②变更申请状态统计：变更申请总数；待审批的变更申请数；正在实施的变更申请数；已关闭的变更申请数。③变更申请类型统计：功能增强；错误更正；需求变更；计划变更等类型及每种类型的变更总数。④变更统计：变更总数；未关闭变更总数；已关闭变更总数。⑤基线配置项状态统计：配置项总数；稳定状态基线配置项总数；变更状态基线配置项总数。项目开发中的所有成员就上一阶段中的开发工作和配置工作中出现的问题进行讨论，一切以项目的顺利完成为优先原则，去对各自相应的计划进行合理的调整。

总之，配置管理工作是软件项目管理中一项非常重要的基础性工作，在实际项目开发过程中，有很多因配置管理工作没做好而导致重大损失的情况。例如：有的项目因没及时备份而丢失大量宝贵的资料；有的项目因变更控制不严格而导致项目失控；有的项目因标识不清楚而导致产品混乱等。因此对于配置管理的进一步研究和应用具有非常重要的意义。研究的配置管理方法对于软件开发行业具有较大的实用性，且在经过变通的基础上也可以借鉴到其他行业，以最大限度地提高配置管理和其他项目管理工作的协同效率。