软件项目的配置管理（精选8篇）
软件项目的配置管理 篇1
[摘要]：
2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，该系统具有严格的安全，稳定，时实高效和可靠性能要求，该系统由票务管理系统和呼叫中心系统两部分组成，呼叫中心系统主要实现电话，传真和短信业务，票务管理系统是整个系统的核心，采用了struts+hibernate+spring主流WEB应用框架，实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成.随着软件系统的日益复杂化和用户需求，软件更新的频繁化，配置管理在软件项目中显得越来越重要了。本文以该项目为例，结合作者时间，主要通过在项目前期，做好需求调研，总体设计和详细设计并制定完整的配置管理计划。在该项目全过程中规范化配置管理，注意员工培训并加强沟通与协调，来实施项目的配置管理。目前，该系统已开发完毕，正式投入运行，状况良好，受到客户一致好评。
[正文]：
2004年6月，2004年6月，我作为项目经理开始参与某航空公司航空票务系统项目的开发，主要负责系统的组织规划实施开发与项目管理，当然还做一些编码工作，主要是公用基础代码和核心代码的编写与维护。航空票务系统是将呼叫中心系统和票务管理系统有效的结合起来，采用先进的ＣＴＩ技术和语音板卡技术，充分利用电话，短信，传真，因特网等信息化手段，解决航空公司的机票销售问题，规范了业务流程，强化了内部管理，与电子商务的完美结合，使应用系统功能更加完善，提高了整个航空业务的工作效率。其中，票务管理系统包括：客户管理，机票管理，票证管理，销售管理，财务结算，调度管理，远程营业部（代理商／分销商）管理，系统管理八大功能模块，并统一于服务器端软件模块。呼叫中心系统由电话呼叫系统，短信分发系统，传真呼叫系统三部分组成。票务管理系统是整个系统的核心，采用了struts+hibernate+spring主流WEB应用框架，实现了WEB应用服务器websphere与协作应用服务器lotus domino 的高度集成,在本次开发中，我把它视为整个项目的重点
由于考虑到寒假和春运期间将会是旅客的高峰期，客户要求系统必须在12月底前交付，项目开发周期为6个月，为此我做了如下安排：前4个月主要集中精力用于开发票务管理系统，后两个月主要完成票务管理系统和呼叫中心系统的集成以及项目收尾工作
随着软件系统的日益复杂化和用户要求，软件更新的频繁化，配置管理逐渐成为软件生命周期中的主要控制过程。在软件开发过程中，扮演越来越重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开发过程的客观管理，即项目管理也有重要的支持作用。在该系统项目中，我主要使用intersolv公司的pvcs配置管理工具，并通过在项目前期作好需求调研，总体设计和详细设计并制定完整的配置管理计划。在项目全过程规范化配置管理，注意员工培训并加强沟通与协调等方法和策略来实施配置管理。项目前期做好要求调研，总体设计和详细设计，并制定完整的配置管理计划。
项目计划阶段，我对需求分析，总体设计和详细设计这三项活动工期安排如下：需求分析12天，总体设计和详细设计总共20天，时间尽量充足。在做需求调研的时候，我要求一定要和客户充分沟通，深入挖掘客户的隐性需求。不仅要实现客户需求的功能，在界面上也要让客户满意，为此我们作出了航空系统的虚拟界面，让客户对系统 有一个感官上的整体了解，在需求分析完成工作之后，我们还通过小组会议的形式进行了确认和评审。并邀请客户方代表参与。最终的《需求规格说明》我们也要求客户方代表一定要签字确认。在总体设计和详细设计过程中，我们尽量使用适合本项目团队特点的工具和技术，并充分考虑其先进性和成熟性。在设计完成之后，我们仍旧对其进行了评审，总结和讨论，对争议比较大的地
方交公司资深专家审核评定。
配置管理计划的制定也使配置管理中不可少的一步，它能有效的指导后期配置管理工作。在本项目中，配置管理计划由配置管理员完成，我只做一些审核工作，软件资源配置管理计划，配置项目计划，交付计划，备份计划，CCB审批计划等．．．．总之，我认为项目前期做好以上铺垫工作可以减少变更，对后面一些工作可以说是水到渠成。同时，一个比较完整的计划，也可以避免不必要的项目反工，而且项目管理员的工作也会比较好做一些。项目全过程规范化配置管理。
开发过程中，对文档修改非常麻烦，在配置管理中，对任何一配置项的修改都可能导致版本的变化。因此，对配置管理规范化势在必行，在本项目中，我要求配置标识一定要规范，必须独立命名配置项，配置对象的标识要充分考虑命名对象间存才联系。在配置管理中，项目组成员要各司其职，不得越权操作，同时还要根据自己的权限操作配置项。我的工作在配置管理中主要是：定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，进行系统集成．．．．．而配置管理员的职责主要是：创建配置序，为项目成员分配权限，对存储库进行日常备份恢复等．．．软件开发人员主要根据项目的开发配管理策略，创建，修改和测试工件等。软件生存期内全部软件配置是软件产品的真正代表，必须保持精确，软件工程中某一阶段的变更都会引起软件配置的变更，对这种变更也必须做到严格规范的控制和管理。为此，我做了如下规定：处于工作状态的产品开发人员可对其修改，而作为基线进入配置库的产品，则不允许开发人员对其进行修改。在本项目中，我们还成立了临时CCB,由项目经理，用户代表，软件质量控制人员，配置管理员5人组成。我们要求对于用户提出的变更请求要严格按照变更控制流程处理。在用户提交更多请求后，开发人员对其进行评价，并产生变更报告。在由变更控制委员会〈CCB〉作出决定是否进行变更。通过批准，就重新检出变更的配置项，建立测试基准程序，并执行质量保证和测试活动，必须通过CCB的鉴定审批后，方可实施变更。
注意员工培训并加强协调与沟通。
项目组成员大多来自不同部门，对项目环境还不熟悉，为了能实施配置管理系统，我建议公司对项目组成员进行相关培训。针对配置管理员，我们要求他学习配置管理工具管理相关的内容。针对开发人员，主要学习配置管理工具与开发相关的常用操作。针对全体人员，要让他们了解配置管理策略和流程，以及如何与开发管理，项目管理相结合。同时，我要求项目组成员要加强协调和沟通。可以使用PVCS，通过ressionmanger文档共享和连锁机制。Tracker与电子邮件的集成，加强项目成员之间的沟通，做到有问题及时发现，及时修改，及时通知，但又不额外增加很多的工作量，这样有助于营造一个和谐，公平，竞争的气氛和环境。
软件项目的配置管理 篇2
IT企业在应对单个客户需求时, 可能具有较好的弹性及其应变优势, 企业领导者也可以对资源进行有效协调指挥, 但当项目增加到一定程度时, 由于受到技术更新程度、IT项目特殊化和其资源的限制, 多项目实施的管理面临严峻的考验。其中资源能否实现合理配置显得尤为重要。
资源合理配置的难点主要体现在以下几个方面。
人力资源配置不均衡。项目较少的时候, 人力资源处于闲置状态, 而对于突然到来的一个重大项目, 企业采用加班加点的措施应对, 造成人力资源疲劳, 开发效率低下, 甚至出现在项目任务较重的情况下, 项目团队的成员身兼几个开发任务, 也就是说, 企业在人力资源配置的时间维度上存在极大的不均衡性。
人才结构不合理。软件开发项目具有技术含量高和创新性要求高的特点。高级设计和开发人员稀缺, 造成多个项目经理对该类资源的争夺, 很多时候项目经理在未结项前不会将这些资源有效释放, 导致关键资源利用率低, 出现不和谐的波峰和波谷。
沟通成本过大。软件企业的人员流动速率和频率都很高, 关键资源在项目进程中的流失导致项目进度的推迟和成本的增加, 新投入到项目的资源往往无法马上接手其他项目成员的工作, 需要项目经理或其他项目成员的指导和支持, 在沟通中产生的时间成本和人力成本过大。
2 实现资源合理配置的方法
项目质量和最终成功一般认为是在项目时间、成本和绩效方面满足或超过客户和高层管理人员的期望。在实际的多项目管理活动中, 更多的情况是项目经理根据项目的实际情况进行相应的项目资源占用取舍, 这往往需要项目经理综合各种因素, 确定这些因素的重要性做出相应的决断。但是需要指出的是, 解决资源问题才是解决多项目管理问题的关键。
建议采取以下办法加强资源的平衡和合理配置。
建立共享资源池。所有资源全部进入资源池, 由项目管理委员会统一管理。项目立项后需要资源向资源池提出申请, 项目必须有明确的收尾和团队解散时间, 项目解散后资源重新回到资源池等待分配。项目团队组建的时候向资源池里面要人需要计入项目的人力资源成本, 项目如果按预算或者少于预算成功完成后还有一定的返现奖励, 这样项目就不会一直去占用某一个资源, 同时资源在一定的时间段里面工作量情况, 整体的对项目的贡献率也一清二楚, 长期在资源池里面没人预定的资源由于无法挣够足够的积分被自然淘汰掉。
排定关键资源工作计划。由于关键资源在企业中属于稀缺资源, 对关键资源的合理有效使用是保证多项目进度的重中之重。首先收集各项目使用关键资源的时间和周期, 并以此为依据排定关键资源工作计划, 如果发生冲突, 应考虑排定项目的优先级, 保证重点项目优先使用关键资源。同时设置资源缓冲, 对所有项目资源使用情况进行监控, 并根据任务完工程度与缓冲消耗程度的比值对资源的使用权进行合理分配。尽量错开项目间在同一时间对同类资源的争夺。从而让关键资源尽量保持处于非过载状态。
构建具有有知识积累和创造力的项目团队。在进行人力资源配置的过程中, 应该从知识共享的角度出发, 将知识互补程度较高的人力资源组建在同一个项目团队中, 激励团队成员以及和其他团队成员间的沟通和交流。同时建立信息共享机制, 所有团队成员所做工作的成果在企业内部以知识库的方式进行积累, 从而保证任务和工作成果的透明度, 减少其他成员的理解时间, 有效提高工作效率。
实现业务流程重组, 扩大资源利用效率。项目管理中心根据每个业务流程的重要性和优先级对资源进行分配, 实现整个企业资源的最优投入产出率。具体实施过程中还要遵循“相似性”原则:将技术相似、项目业务领域相似、优先级相同的项目适当归类, 以减少和优化资源配置。
3 结语
软件开发企业是典型的知识型企业, 人力资源是其最重要的资源, 将合适的人力资源分配到项目中是软件开发企业实施多项目管理的关键任务。人力资源的合理配置不仅有利于项目进度、成本和质量目标的实现, 更是企业战略目标顺利实现的重要一环, 它将有助于企业知识的积累和创新, 极大地提高软件开发企业的核心竞争能力。
参考文献
[1]彭忠华.企业多项目管理的资源优化方法研究[D].国防科学技术大学, 2007 (5) .
[2]任劲松.企业进行多项目管理的研究[D].西南交通大学, 2004.
[3]杜维.人力资源、IT能力与组织绩效——知识管理战略的影响因素及实施后果研究[D].重庆大学, 2009 (12) .
[4]彭先晚.多项目管理中的冲突问题研究[D].天津大学, 2009 (4) .
[5]郭研.软件行业中的多项目管理[D].南京航空航天大学, 2005.
[6]褚宏涛.XX公司多项目管理组织机构设置的应用研究[D].昆明理工大学, 2008 (9) .
[7]丁荣贵.项目组织与人力资源管理[M].电子工业出版社, 2009.
软件项目的配置管理 篇3
【关键词】软件配置 软件开发 软件工程
1 软件配置管理概述
软件配置管理是指在软件开发过程中管理软件的配置，包括源程序、数据文件、设计文档、用户文档，及其组织关系。相应的管理包括管理这些部件的产生、修改、提取与发布，以保证整个产品的正确性、完整性，产品部件的一致性。
软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动态的、成长的产品进行管理。没有采用配置管理的“作坊”式的软件开发项目经常会遇到许多问题。例如，一个严重的错误被修正了，却在一段时间后又重现了；一个已经开发并经过测试的功能在手工集成后完全消失了；系统崩溃了，却很难查出是什么修改造成的；用于测试的执行程序与源程序严重不一致；新的开发人员对现有代码难以理解，不知其前因后果；无法判断单个功能的实现进度和整个项目的完成程度；无法确知整个产品的代码修改频度和每个版本的代码修改量。种种这些问题，在没有配置管理或配置管理系统不完善的项目中必然会出现，并让项目所有相关人员感到困惑，甚至十分恼火。
2 软件配置管理的主要过程
2.1配置标识与存储过程
配置标识是定义各类配置项、建立各种基线、描述相关软件配置及其文档的过程。标识过程的关键是如何给每个配置项赋予一个唯一而又有意义的标识符。在配置管理系统中同一个文件的配置项有许多版本，因此，必须把每个版本也标识出来。配置项存储过程指如何把普通文件系统中的文件转化为受配置管理系统控制的配置项的过程，此过程与生成配置项初始标识的过程几乎是同时发生的。经过一定选取标准选定的作为配置项的文件先被存放在工作空间，然后由工作空间的拥有者把该文件由工作空间添加到配置库。
2.2版本管理过程
在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。版本管理过程是实现完整的配置管理功能的基础。版本管理的主要内容是管理产品配置项的每一个版本的生成和使用，主要方法包括版本访问和修改控制、版本分支和合并、版本历史记录，以及历史版本检取。检出和检入机制是版本管理中实现修改控制的主要方法。检出就是将软件配置项的某一版本从配置库中提取出来，以供开发人员在工作空间内修改的操作；检入就是将修改过的软件配置项从工作空间中上传到配置库中从而生成新的版本的操作。
2.3 变更控制过程
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。软件产品在开发过程中进行变更时不可避免的，变更和变更控制是矛盾的统一体。变更控制过程就是通过一系列方法、手段对变更进行约束，使变更的结果有利于改进产品、满足客户需要，同时使变更的实施对项目影响较小。项目中引起变更的因素有两个：一是来自外部的变更要求，如客户要求修改工作范围和需求等；二是开发过程内部的变更要求，如为解决测试中发现的一些错误而修改源码甚至设计。变更控制不能仅在过程中靠流程控制，有效的方法是在事前明确定义。事前控制的一种方法是在项目开始前明确定义，否则“变化”也无从谈起。另一种方法是评审，特别是对需求进行评审，这往往是项目成败的关键。需求评审的目的不仅是“确认”，更重要的是找出不正确的地方并进行修改，使其尽量接近“真实”需求。
2.4 基线管理过程
基线是指项目开发中的业务主线，对其管理是为保证基线的正确更新，它是一定阶段变更请求实施后的累加效果。通过基线管理可以使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统可使用已有的版本组装成各种各样、不同功能的模型。基线的变更需要一个严格的流程，需要提出申请，经过审批，然后才能进行。基线管理和产品开发模式、开发阶段划分，以及产品发布过程紧密相关。基线管理过程主要解决基线的创建、发布、使用和维护等方面的问题。基线一旦创建就成为整个产品的一个正式标准，随后的开发都基于此标准进行，直到下一个基线被创建。
3 结语
配置管理本身无论从理论和实践都在不断丰富和发展。配置管理提供的状态报告和数据统计也为软件度量提供了决策依据。同时为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。此外配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动带来的困境，使新的成员可以快速实现任务交接，减少了因人员流动而造成的损失。
【参考文献】
[1]刘江华，王立，马玲等，著.软件开发过程与配置管理——基于Rational的敏捷方案设计与应用.电子工业出版社，2011，2.
[2]勃克扎（美国）等，著. 软件配置管理模式 .中國电力出版社，2004，6.
软件项目的配置管理 篇4
实 验 报 告
实验名称基于SNMP的网络管理软件的配置与使用
课程名称网络管理
专业班级：学生姓名： 学 号： 成 绩：
指导教师：实验日期：
（一）基于SNMP的网络管理软件的配置与使用
一、实验目的
1.熟悉路由器和交换机并掌握路由器和交换机的基本配置方法和配置命令。2.练习构建一个由四个路由器和四台主机构成的网络。
3.操作SiteView NNM管理系统，掌握如何添加网元，构建管理系统，并每一个可被管理的设备进行操作。
4.掌握网络管理软件的使用方法，实现对网络的拓扑发现实时监控，告警设置： 1).应用Siteview软件进行拓扑发现。通过自动和手动两种方式实现。2).基于SNMP的实时监控。对设备，链路，端口等进行相应的监控。3).进行告警设置（告警方式）。通过对不同设备，条件等进行告警设置。
二、实验环境
计算机4台、路由器4台、交换机4台、SiteView NNM网络管理软件系统。
三、实验原理
网络设备只有配置了SNMP协议以后，才能够通过SNMP进行监控和管理，因此，使用网络管理软件之前，需要对所有设备进行配置。主要包括： 1）主机SNMP配置； 2）路由器SNMP配置； 3）交换机SNMP配置。
四、实验步骤：
1、局域网的实现与配置：
网络拓扑图：
路由配置： 1）IP分配：
四台PC的本地连接2的IP分别为：
PC1：222.1.3.5 PC2：222.1.2.5 PC3：222.1.1.5 PC4：222.1.4.5 本地连接1 IP: PC51：192.168.1.21 PC52：192.168.1.22 PC53：192.168.1.23 PC54：192.168.1.24
2)地址分配：
路由器R1 S2端地址：222.1.6.1 路由器R1 S3端地址：222.1.7.1 路由器R1与路由器R2间的地址：222.1.6.0 路由器R1与两层交换机1间接口G1 地址：222.1.3.1 路由器R2 S2端地址：222.1.6.2 路由器R2 S3端地址：222.1.5.1 路由器R2与路由器R3间的地址：222.1.5.0 路由器R2与两层交换机2间的地址:222.1.2.1 路由器R3 S2端地址：222.1.5.2 路由器R3 S3端地址：222.1.8.1 路由器R3与路由器R4间的地址：222.1.8.0 路由器R3与两层交换机2间的地址：222.1.1.1 路由器R4 S2端地址：222.1.8.2 路由器R4 S3端地址：222.1.7.2 路由器R4与路由器R1间的地址：222.1.7.0 路由器R4与交换机间的地址：222.1.4.1
PC1地址：222.1.3.5 网关：222.1.3.2 PC2地址：222.1.2.5 网关：222.1.2.2 PC3地址：222.1.1.5 网关：222.1.1.2 PC4地址：222.1.4.5 网关：222.1.4.2
3)路由器的配置
路由器R1的配置（代码）： R1(config)# interface S 2/0 R1(config-if)# ip address 222.1.6.1 255.255.255.0 R1(config-if)#exit R1(config)# interface S 3/0 R1(config-if)# ip address 222.1.7.1 255.255.255.0 R1(config-if)#exit R1(config)# interface gi 0/1 R1(config-if)# ip address 222.1.3.1 255.255.255.0 R1(config-if)#exit R1(config)# router rip R1(config-router)#network 222.1.6.0 R1(config-router)#network 222.1.7.0 R1(config-router)#network 222.1.3.0 R1(config-router)#end
路由器R2的配置（代码）： R2(config)# interface S 2/0 R2(config-if)# ip address 222.1.6.2 255.255.255.0 R2(config-if)#exit R2(config)# interface S 3/0 R2(config-if)# ip address 222.1.5.1 255.255.255.0 R2(config-if)#exit R2(config)# interface gi 0/1 R2(config-if)# ip address 222.1.2.1 255.255.255.0 R2(config-if)#exit R2(config)# router rip R2(config-router)#network 222.1.6.0 R2(config-router)#network 222.1.5.0 R2(config-router)#network 222.1.2.0 R2(config-router)#end 路由器R3的配置（代码）： R3(config)# interface S 2/0 R3(config-if)# ip address 222.1.5.2 255.255.255.0 R3(config-if)#exit R3(config)# interface S 3/0 R3(config-if)# ip address 222.1.8.1 255.255.255.0 R3(config-if)#exit R3(config)# interface gi 0/1 R3(config-if)# ip address 222.1.1.1 255.255.255.0 R3(config-if)#exit R3(config)# router rip R3(config-router)#network 222.1.5.0 R3(config-router)#network 222.1.8.0 R3(config-router)#network 222.1.1.0 R3(config-router)#end
路由器R4的配置（代码）： R4(config)# interface S 2/0 R4(config-if)# ip address 222.1.8.2 255.255.255.0 R4(config-if)#exit R4(config)# interface S 3/0 R4(config-if)# ip address 222.1.7.2 255.255.255.0 R4(config-if)#exit R4(config)# interface gi 0/1 R4(config-if)# ip address 222.1.4.1 255.255.255.0 R4(config-if)#exit R4(config)# router rip R4(config-router)#network 222.1.8.0 R4(config-router)#network 222.1.7.0 R4(config-router)#network 222.1.4.0 R4(config-router)#end
交换机配置：
R1交换机的配置（代码）：
Ruijie
R2交换机的配置（代码）：
Ruijie
R3交换机的配置（代码）：
Ruijie
R4交换机的配置（代码）：
Ruijie
在网络配置好之后，通过ping命令来查看网络是否连通，测试网络的连通性。测试结果：
由图可知：本机到其他机子的网络已全部连通，局域网构建完成。
2、主机SNMP配置
设置管理者（Manager）和代理者（Agent）的动态分布式处SNMP服务控制面板－管理工具－服务，实时性好。它所具有的图形化界面，各种生动形象而又简单的图形操作。(如图所示)
控制面板－管理工具
3、路由器交换机SNMP配置
Router>enable Router# configure terminal Router(config)# snmp-server community public ro Router(config)# snmp-server community private rw Router(config)# snmp-server enable trap Router(config)# snmp-server host 222.1.3.5 rw
4、SiteView NNM的安装与使用：（1）拓扑图管理，扫描网络。
（2）IP资源管理，端口连接设备，IP网段分配统计。
（3）设备管理，添加连线，全网设备统计。（4）监测报表，端口分析，多端口对比分析，（5）告警设置。扫描网络：
设置扫描参数，搜索深度为2，并行线程数为100，重试次数为1，超时时间为200毫秒。
设置扫描范围，添加允许的地址范围为222.1.0.0~222.1.9.0。
结果如下图所示：
设备端口状态实时分析：
端口分析：
多端口对比分析：
端口月报表：
告警设置：
五、实验总结：
本次实验比较复杂，先要设计好网络拓扑图，配置好路由交换机器，然后编写代码分配地址，构成局域网，在网络连通的情况下配置SNMP。整个过程耗时较长，在实验过程中也遇到了一些困难，但在同学与老师的帮助下，最终实现了网络的合理分配。
论软件项目的进度管理 篇5
摘要
本文讨论了《电力行业工作票、操作票系统》的项目管理，在本项目中我作为项目负责人，承担了项目管理工作．
在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的工作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不足。
本文从合理的估算项目的工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面讨论了《电力行业工作票、操作票系统》项目管理的基本活动与方法，有效地控制开发进度，确保项目如期按质量完成．本系统在电力系统已经运行，状况良好，受到一致好评．
正文
2003年2月，我参加了《电力行业工作票、操作票系统》的开发，担任项目管理工作．电力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业相关标准进行工作，《电力行业工作票、操作票系统》就是按照国家有关标准及电力行业操作规程设计的仿真系统。工作人员在施工前按照工作流 程在此仿真系统上进行操作，严格遵守电力设施的逻辑闭锁关系，顺序执行．有效地防止不规范操作，确保电力设施及现场工作人员的安全，提高安全意识．
本系统由系统图编辑平台和工作票、操作票签发系统两大部分组成，其中系统图编辑平台主要是编辑变电站、用电系统及变电站控制系统图，每一个电力设施对应一个对象，在系统图上都有相对应的部分，系统图真实地反映电力设施的布局及相互关系，生动形象又合乎技术标准，同时为第二部分提供操作对象．工作票、操作票 签发系统主要是在系统图的基础上进行点击操作，每饮点击对应一个对象即一个电力设施，根据电力设施的逻辑闭锁关系自动生成相应的工作票或操作票或提示操作不规范．
在本系统的开发过程中，我通过合理的估算项目工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面对项目进行管理，确保本系统如期按质量完成。
1、合理的估算项目工作量及技术难度
我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则．
本系统采用了面向对象的分析、设计等一系列面向对象技术，在本系统工作量的估算上根据功能点进行估算．将每个功能模块逐步分解，直至基本模块为止．我们将系统分为系统图编辑与工作票、操作票签发两个大的功能分别进行估算。系统图编辑部分主要是一个图形编辑系统．一种电力设施对应一个类，电力设施的技术参数 及其操作对应相应类的属性和方法，电力设施图是由线段、圆、曲线、折线、多边形等基本图形组成，这些基本图形分别对应一个类，这些类又继承一个最基本的类．系统图编辑部分的工作量也就是这些类的实现，工作票、操作票签发部分用到了编辑平台的系统图，因此由大量的功能可以复用，这部分的功能划分同系统图编 辑部分一样也是采用类作为基本结构，这样就比较准确的进行工作量的估算．
同时我们开发的这个系统是基于C/S结构的，由于C/S结构的系统我们公司有不少成功的案例，因此有不少的案例供我们参考．对于本系统的第二部分我们就是借鉴以前我们做过的基于C/S结构的系统，基于C/S结构的系统的框架基本上是一致的，数据库的设计、前台操作如对数据库进行添加、删除、修改、查询等一系列活动大体相同．正是如此，有大量的东西可供我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改．在工作量的估算上也有很好的借鉴作用．这 对工作量的估算也是一个重要的参考，为工作进度安排提供了依据．
在技术上，我们重点考虑本系统与其他C/S 结构的系统的不同之处，相同或相似之处我们认为没有技术难点．系统编辑平台主要是绘图，我们知道MFC的绘图功能确实强大，但是过于繁琐，功能封装不是十 分完美，我们采用了Form++这个MFC 扩展类库，这个扩展类库对图形操作封装得很好，大大降低了系统图编辑部分的难度，在界面设计上我们采用了BCG 这个扩展类库，使得VC应用程序界面设计得如同Delphi等工具一样完美．同时减少了工作量，在工作安排上，技术难度相对大一点的部分我们安排经验丰富 的程序员，同时也同其他工作组的成员商讨技术细节间题，同他们进行技术探讨．这样不至于因为某一技术细节而影响整个工程进度．根据上述分析我们制定一个详细的进度表并定义相应的里程碑．
2、识别关键任务
系统图编辑部分是整个系统的基础，因为工作票、操作票签发部分是建立在该部分的基础之上，系统图编辑部分直接影响到整个项目．因此该部分是整个系统的关键部分，在这部分中每种电力设施所对应的类及其父类的定义是关键，因为所定义的类必须完整、准确地反映该电力设施的技术参数和操作．
工作票、操作票签发部分，是用户明确提出的要求实现的功能，直接面对用户，这部分的成功与否直接影响到该系统的质量，因此也是不容忽视的．
如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁．因此是本项目的关键任务．在进度控制时我们将其作为重点对象进行控制．
3、随时了解项目进度，必要时调整进度表
在确定项目开发计划时，我们制定了详细的进度表．我们在确定每一项任务时都确定该任务的工作量、开始时间、持续时间、结束时间．同时让每个小组成员知道自己所承担任务的时间表，小组成员根据自己的任务制定自己的详细工作计划．
工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成品对自己的工作都要做工作日志，对自己每天的工作做详细记录．每周对自己的工作进展做出结论，向项目组汇报．在做结论时，不得使用“差不多”、“大概”、“完成了90%”„ 等模糊字眼．而是采用某任务“已经全部完成”、或者“90%的工作全部完成”或者“再过1 天全部完成”„等方式．每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目计划提供客观基础．
同时我们在项目进度计划中根据项目设计定义了相关的里程碑，在每个里程碑我们都采取小组会议形式对本阶段的工作进行确认、总结，对本阶段的进展情况做出结论，并决定是否调整下一阶段的进度计划．
在系统图编辑部分我们认为各电力设施所对应的类（包括其父类）定义完成为一个里程碑，每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的标 准，这些类（包括其父类）的实现完成又为一个里程碑，„ „ 整个系统图编辑部分完成也是一个里程碑．每个里程碑的标准在系统设计时已经定义好．
结束语
软件项目的配置管理 篇6
论文题目：项目配置管理计划改进方法研究
任课教师评语：
任课教师签字：
考核日期： 年
月
日 项目配置管理计划改进方法研究
配置管理工作是整个软件项目生存周期过程的一项主要而且关键的质量保证活动之一，配置管理也是软件项目开发及项目管理过程中非常重要的一项基础性工作，正确而及时地进行配置管理工作，对于在项目生命周期内建立和维护工作产品的一致性和完整性具有非常重要的意义。
配置管理的目的在于通过有效的管理软件开发过程中的所有的输出，以及对他们的变更，来保证团队的有效协作，配置管理是实施软件工程的基础。
基于以上的目的，配置管理的目标应该明确是：
提供用于识别和控制文档、代码、接口和数据库的结构框架，适用于软件开发生命周期的所有阶段；全面支撑某一特定开发及维护工作方法，能够适应各种类型的需求、标准、政策、组织机构以及相关的管理策略；针对特定的基线状态、变更控制、测试、发布版本或审计活动，生成相对应的管理信息和产品信息。
为了保证项目配置管理计划的顺利实施，立足于软件支持过程复杂性七命题，投资命题，成熟度命题，效果命题，领导命题，过程命题，文档命题，团队命题。分别都设计了对应的方案去保证项目配置管理计划的成功。
投资命题：需要计划，配备专职人员以及管理时间和资金投入。在投资命题方面，首先需要为项目配备专职人员，即配置人员，根据项目的大小去配置。所有目录只有配置管理员有更改和书写权限；整个项目管理工具由项目负责人指定配置管理员管理；配置管理员要维护所有目录和配置项的权限，保证配置项Reader能够获得到该文档，而其他人员无权获得。
领导命题：需要高层领导的发起、参与和支持。在领导命题方面，需要领导的自身的足够的重视，了解到配置管理的重要性，在项目启动前，聘请专业的领域专家做咨询，对项目在配置管理方面的常见的难点与一般的解决方案作讲解。
团队命题：需要全体人员的协作和努力。在团队命题方面，每个人首先明确自己在配置管理过程中的职责与任务。软件配置管理工程师，制定配置计划，负责计划的执行和完善设计软件配置管理库、基线库，控制基线的变更、保存所有变更请求；识别/标识软件配置项，确定哪些内容将纳入基线库；把汇总基线的状态和内容及时通知相关人员；基线化软件工作产品。项目经理，协助软件配置管理工程师制定软件配置管理计划，并支持计划的执行审查软件配置管理计划，确保只选用基线库的基线来构建工作产品或最终产品。项目组成员，了解项目配置管理计划，支持配置管理工程师的工作；按照过程、规定、及工作计划的要求，提交工作产品。高级经理，主持软件配置管理计划的评审，批准产品的发布。
过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高群体认知活动的效力和效率。在过程命题方面，其基本内容应包括：配置工具、环境；配置更新流程；配置需求变更与会议备忘录；配置备份流程；变更处理流程；工件、产品和报告的发布进程等。
以下我就以现在的项目组中的配置管理以及配置管理工具为例加以说明。
配置工具、环境：VSS（Microsoft SourceSafe User Shell），WINDOWS。说明配置库所在的物理位置。
配置人员的权限：可定义为：只读（R）－只能读取所选择的配置项；修改（C）－可读取、修改所选择的配置项；变更（N）－可读取、修改、增加、删除（可恢复）配置项，此权限通常分配给项目经理和项目骨干；完全控制（Y）－完成控制配置库。此权限通常只分配给配置管理员。
配置更新流程：开发人员要认真填写要更新的补丁清单，只要checkin到vss上的JAVA与UI的相关路径下即可。配置人员在版本发布时将java，ui文件全部get，保证开发库的最新。（此操作可使用vss的command命令，或者手工进行get）另外配置人员再get下来每个开发小组填写的记录。（此操作可使用vss的command的命令，或者手工进行get）
按照记录抽取出相应的文件。（此操作使用excel宏定义文件工具，前提是设置好抽取文件的路径，与需要复制的目的路径，在复制文件过程中宏定义工具如报错，可以考虑复制文件时此文件已存在并且是只读属性这种情况）
将抽取出的补丁包进行备份形成一个按日期排列的补丁基线，然后将补丁包覆盖到本地的源代码上替换旧文件。（此操作可以写一个批处理完成）
用ant工具编译最新的本地源代码环境。（ant工具需要配置环境变量，如在编译环节上有变化如增加了jar包，或者开发人员新加了java包，只需修改ant 的配置文件build.xml即可，build.xml的修改这里不详细说明）
再根据开发人员填写的记录抽取出可执行文件.如class文件和其他非编译的文件。（此操作过程中需要使用excle宏定义工具抽取已编译好的class文件）将已形成的补丁包，放入补丁备份库中进行统一管理备份。将以抽取出来的可执行文件覆盖到需要更新的应用程序中覆盖旧文件。（此操作也可写一个批处理完成）发邮件通知开发人员，和测试人员告知此次发布完成。版本的更新执行与操作中使用的工具介绍完成。
请详细参见更新发布流程图（图表 1）
Checkin程序源码和变更登记表配置管理员GET java，ui源代码和登记表开发人员源in程序Check码和变更登记表VSS服务器开发人员以上为开发人员checkin操作和配置人员get操作，以下为配置人员在配置机上的详细操作流程配置工作机配置机操作流程如下汇总所有补丁更新登记文档本次版本发布工作结束版本补丁备份库备份操作从编译环境中抽取新生成的Class文件编译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：项目文档编号，三位数字，由项目经理统一分配。源代码类基线配置项命名规则：项目编号_模块名_版本号。对于非基线配置项的命名规则：格式一般不做统一要求，由项目自己进行唯一性标识。对于软件开发产品的命名，没有最优方案，只要适合于项目的实际情况即可。
成熟度命题：需要不断地组织学习以持续地改进全组织的软件支持过程能力。对于成熟度命题，则需要项目经理定期的组织会议，为确保配置管理工作的准确无误，并保持对配置状态的总体了解和把握，配置管理员应根据配置管理计划的要求定期进行配置状态检查，撰写配置状态报告，并对发现的问题进行处理。配置状态报告主要应包含如下内容：①配置库总体说明：上次报告日期；本次报告日期；项目所处阶段；基线配置项总数；基线总数；变更申请总数；变更总数等。②变更申请状态统计：变更申请总数；待审批的变更申请数；正在实施的变更申请数；已关闭的变更申请数。③变更申请类型统计：功能增强；错误更正；需求变更；计划变更等类型及每种类型的变更总数。④变更统计：变更总数；未关闭变更总数；已关闭变更总数。⑤基线配置项状态统计：配置项总数；稳定状态基线配置项总数；变更状态基线配置项总数。项目开发中的所有成员就上一阶段中的开发工作和配置工作中出现的问题进行讨论，一切以项目的顺利完成为优先原则，去对各自相应的计划进行合理的调整。
软件配置管理简化实施方法 篇7
随着科技的不断发展, 软件项目的复杂性与集成度越来越高, 项目的成败在很大程度上取决于对其开发过程的控制, 包括对质量、源代码、进度、资金、人员等的控制, 有效的过程必须有科学的管理方法, “软件配置管理”是通过技术或行政手段, 对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。实践证明, 软件配置管理是一套规范、高效的软件开发管理方法, 同时也是提高软件质量的重要手段。
1.1 实施软件配置管理, 是提高效率和质量的必要手段
软件研发中出现的每一个问题, 必须及时定位、修改、更新和记录, 配置管理过程中的记录、报告和版本控制, 通过问题跟踪和追溯, 能加快问题的定位和修复, 并最大限度减少缺陷和错误的发生以及再次发生;同时, 在软件编码过程中, 使用配置管理工具, 能够较好的避免因并行开发、多重维护带来的版本混乱、重复编码等问题, 清晰的配置管理过程, 在节约人力的同时, 提高了产品质量。
1.2 实施软件配置管理, 有利于单位建立知识库
软件代码是软件开发人员脑力劳动的结晶, 也是软件开发单位的宝贵财富, 长期开发过程中形成的各种代码对象就像一个个零件坯一样, 是快速生成系统的组成部分。实施配置管理, 能够对各人的有用对象进行管理, 把其使用范围扩大到单位级, 进行规范化并加以说明和普及, 建立单位级的代码对象库;在配置管理中, 形成完整的开发日志及问题集合, 以文字方式伴随开发的整个过程, 不依某个人的转移而消失, 有利于单位积累业务经验, 无论对版本整改或版本升级, 都具有重要的指导作用。
1.3 实施软件配置管理, 能够降低成本, 节约费用
通过软件配置管理, 可以对不同阶段软件代码版本进行管理和跟踪, 建立代码知识库, 提高代码的重用率, 同时最大限度地共享代码, 便于进行新版本或类似功能的开发, 减少再开发的成本, 提高开发效率, 缩短开发周期;通过配置管理, 建立开发管理计划和规范, 共享最新文件和代码, 当项目成员跨地域分布时, 能够实现协同有序, 互不干扰而又不失去控的异地工作, 从而节约大量的旅差费用。
1.4 实施软件配置管理, 是规范管理的要求
通过建立科学的配置管理流程, 将大量的文档和代码等知识财富统一标识, 按阶段进行规范化管理, 避免随意保存在项目经理和软件工程师各自的机器里, 因硬盘故障或人员离职造成数字财富因缺乏必要的配置管理而白白流失。能够应对人员离职、版本混乱、加快问题的定位和修复;通过配置管理规范软件研发各阶段的文档, 进行有效的质量记录和文档管理, 保证每个使用者都能得到正确的版本, 在提高项目研发效率的同时, 也为企业积累了组织级财富, 便于今后的项目共享;软件项目的研制过程是随项目的规模以指数上升, 只有在项目研制之初, 制定项目开发和管理计划, 并在研制过程中, 依照计划实施, 才能避免项目研制过程中的盲目性;代码回溯是软件编制过程中经常发生的, 使用工具进行规范化的配置管理, 每天记录当天代码修改情况, 规范文档和代码每天的版本, 使工作或代码回溯成为轻松便捷的事。
2 简化实施软件配置管理的策略
软件配置的主要工作包括:建立配置管理机构和配置库 (即软件开发库、受控库、产品库, 又称软件三库) 、制定配置管理计划、基线控制、出入库控制、更改控制、配置状态记实、配置审核。本文重点介绍综合性科研单位的软件配置管理工作的简化实施。
2.1 建立配置管理机构和配置库
在项目设计开发期间, 应建立相应的配置管理组织 ( 配置管理委员会或配置管理小组) , 专门负责配置管理工作。项目组应指定专人 (配置管理员) 处理配置管理事务。
配置库也称为软件“三库”, 是软件配置管理机构的组成部分, 包括:开发库、受控库、产品库。开发库存放各开发阶段产生的尚未通过评审的程序、文档等电子版本或纸制资料, 一般由项目组建立并维护;受控库存放已通过测试或评审且作为阶段性产品的软件配置项集合, 包括程序和文档, 一般由研制管理部门 (或质量管理部门) 建立和维护, 受控使用;产品库存放已定型 (鉴定) 且供交付、生产、检验验收的软件配置项集合, 包括源代码、可执行程序、数据和文档的电子版或纸制资料, 一般由组织的技术档案管理部门建立和管理。
三库可以借助专门的配置管理软件建立, 也可以以电子或物理形式建立。例如:受控库可以是一系列电子文件夹, 产品库可以是一组文件柜。如表1 所示。
2.2 制定配置管理计划
配置管理计划的目的在于对所开发的软件规定各种必要的配置管理条款, 从而保障产品质量。内容包括:说明配置管理角色和职责、计划纳入配置管理的配置项、计划的基线时间和内容、配置库的建立方式和授权、配置状态记录和统计计划、更改和版本控制, 并确定项目标识、文档标识、程序和产品标识、版本标识等。
对基线的管理是配置管理的重点内容。基线是软件文档或软件代码的一个稳定版本。是被正式确认并作为今后研制生产、使用保障活动的基准。已形成基线的关键文档, 虽然可以修改, 但必须以一个特殊的、正式的过程进行评估, 确认每一处修改。软件开发项目的配置管理基线包括:功能基线、分配基线、设计基线、开发基线和产品基线。在实际应用中, 根据项目的规模和实际研发情况, 可以只划分功能基线、分配基线和产品基线。基线对应的标志性文档如表2, 每一种基线以通过一定级别的评审后建立。
2.3 配置控制
开发库出入库较频繁, 主要由项目组控制。通常配置控制主要是对受控库和产品库的控制。为了简化实施, 只能涉及基线的配置项目进行控制。
2.3.1 基线控制
在确立基线的标志性评审通过后, 及时将基线文件入库, 此后, 若有对基线文件的使用和修改, 应及时记录并向有关人员发布最新版本。
2.3.2 出入库控制
一般在基线建立后、变更前后和重要事件前后, 要记录配置项出入库。配置项出入受控库或产品库应当填写《出库单》和《入库单》。
2.3.3 更改控制
被更改的源代码和相关文档必须正式取自配置管理的受控库或产品库, 更改后重新入库并填写《配置变更报告单》, 版本的变更, 也应进行记录。
2.3.4 配置状态记实
记录并报告受控软件配置管理项的现行状态和历史。在实施配置变更处理的过程中, 配置项的状态分为:变更中、有效、无效。配置管理者应在一个重要阶段结束时, 及时汇总《配置状态记录单》。
2.3.5 配置审核
在项目研发完成一个阶段或在产品交付前, 应进行功能配置审核和物理配置审核, 功能配置审核以确定和保证配置项的完整性;物理配置审计以检查程序与文档的—致性、文档与文档的—致性、交付的产品与任务书要求的—致性以及与标准规范的—致性。完成审核后, 应填写《配置审核单》。
2.3.6 配置总结
根据配置管理情况, 一般在项目完成时, 编写配置管理报告, 也可以在研制总结中进行配置管理总结, 内容包括:配置管理情况综述、用户组划分及权限分配、配置项记录、基线记录、入库记录、出库记录、变更记录、审核记录、备份记录等。
3 结束语
专业软件开发单位的软件配置管理工作, 一般应达到软件研制能力成熟度模型 (CMM) 3 级或以上标准, 故一般采用专业的配置管理软件实现;对于实施质量管理体系的综合性科研单位的配置管理, 一般达到软件研制能力成熟度模型二级标准即可, 重点记录基线形成和变更、大阶段的配置管理状态和审核, 以及相应的出入库, 可以采用一些版本管理软件辅助实施, 同时制定一系列规则, 以人工辅助部门级配置管理工作。
注:文中提到的配置表单和文档表单, 可参考相关标准中的格式。
摘要：软件配置管理是通过技术或行政手段, 对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。配置管理的主要工作一般包括:建立配置管理机构和软件三库、制定配置管理计划、基线控制、出入库控制、更改控制、配置状态记实、配置审核。根据项目的具体情况, 配置管理的实际工作内容不同。
关键词：软件配置管理,配置管理,软件三库,配置管理简化实施
参考文献
[1]陈焱, 李勇, 韩铁军.配置管理在软件系统开发中的作用[J].自动化指挥与计算机, 2012 (04) .
[2]冯济舟.软件配置管理典型问题的研究与思考[J].航天标准化, 2013 (03) .
[3]刘旭奕.基于GJB5235的软件配置管理方法初探[J].标准介绍, 2011 (02) .
[4]高贤志, 戴恒毅.导航装备软件配置管理方法研究与实践[J].装备质量管理, 2012 (08) .
浅析软件项目中的质量管理 篇8
[关键词] 软件项目 软件质量 软件质量管理 软件项目管理
一、引言
软件产品是软件项目的最终结果，与其相关的质量问题主要来自项目开发过程。但软件是一个纯智力的特殊产品，描述软件质量的定义则比描述实际物品质量定义面临着更多的潜在因素。所以，保证软件质量比保证设备质量更具挑战性和不确定性。
国际化标准组织ISO在ISOPIEC9126中将软件质量定义为：“反映软件产品满足规定需求和潜在需求能力的特征和特征的总和”。而M. J . Fisher 将软件质量定义为：“所有描述计算机软件优秀程度的特性的组合”。目前，对软件质量的研究主要从两方面展开：一是软件开发过程的质量保证，以过程文档化和管理科学化为内容；二是软件过程和产品的质量评估，包括中间产品和最终产品，采用软件度量技术作为软件质量特性量化的主要技术。本文将就第一个方面展开讨论，通过给出或设计一些符合文档化开发标准的管理规范和文档模板，以达到使软件质量满足之前用户对各项功能或性能的精确定义的目的。
二、项目概况及背景
某船厂在信息集成系统CIMS第一期结束后，初步建立起企业的基础信息资源的共享平台，并将物资管理与财务管理进行了整合。但在第一期CIMS平台中没有对其涂装生产管理建立相应的系统。为尽快解决涂装生产管理的问题，项目组在进行一个月的需求调研后就进入了开发。但是由于前期需求阶段没有细化需求，涉众范围太小，在开发阶段代码管理松散，导致项目在开始不久后，就处于一边开发一边继续需求分析细化的状态，并伴随不断的需求变更，最后在拖期半年后才交付了一个带有隐患的产品，而且原定两周的试运行期因为修改不断发现的缺陷也延长为两个月。
在完成涂装项目后，项目组又接到船厂关于开发生产安全监管系统的任务，为了避免同样的问题发生和提高软件质量，项目组认为要在软件开发项目过程中引入完善的质量管理，并针对船厂项目特点，结合实际情况重点覆盖需求、编码、测试三个阶段。
三、分析及应对措施
1.定义合适的项目过程
软件过程是指开发和维护软件产品的活动、技术和实践的集合。在以计算机网络为基础的现代社会信息化背景下，过程管理作为现代企业管理的先进思想和有效工具，随着外部环境与组织模式的变化而变化。因此，作为一个好的软件项目过程，必须针对企业和项目的实际情况，确定软件项目运作流程，定义软件功能及相关性能，明确各阶段的进入条件和退出条件，进行有效的过程控制与管理，在提高软件开发的效率和项目的成功率的基础上进一步保证所开发软件的质量。
在现阶段主流的软件工程过程主要是RUP（Rational Unified Process）和XP（Extreme Programming）。由于新项目的需求明确，并且项目组成员的构成方式是新老搭配，在经过综合考虑后，我们决定采用RUP方法。最后，项目组根据项目实际情况对传统的RUP模式进行按需裁剪，具体方案是将“需求与分析”和“设计”两个活动合并为“需求分析”，将“配置”和“变更管理”统一纳入“项目管理”，移除“环境活动”环节。
2.明确项目需求
对于任何软件项目过程而言，需求不仅是一个不可避免的环节，也是软件开发的基础。往往用户需求明确、变更少的项目的成功率就高，而那些用户需求混乱、变更频繁的项目几乎从一开始就注定了失败的命运。但是，在现实生活中，用户需求总是在开发进入中后期时，因为各种不同的原因而发生变化。这就给软件项目过程实施带来不确定因素。在涂装项目中，由于前期需求不明确以及随意变更需求，导致项目组在开发阶段不停的返工，进而造成代码质量低下，测试拖期等一系列问题。因此，在项目实施过程中，为了保证软件开发的顺利进行和最后交付的产品质量，应该对项目需求变更进行管理。
(1)需求说明书要描述明确、详尽。由于与用户沟通的需求人员并不是最后的开发人员，所以有可能导致开发人员对需求说明书的理解与用户真正的意图会产生一定的偏差。另外，当项目在进行到开发（编码）阶段时，由于记忆的缺失，对当初所作的需求说明书的理解也会产生偏差。
(2)要对需求变更进行管理。通常需求分析完成后项目就进入开发阶段，用户可能会因为市场或策略的变化而提出需求变更的要求。此时，若是合理变更则有利于项目实施，但有时所作的变更可能会影响项目整体的设计和开发，造成项目进度的延期。对于这一情况，项目组应该积极与用户沟通，制订需求变更说明书，在双方都认可的情况下方可实施。
(3)在项目开发过程中要尽早明确用户需求，有些内容一时无法确定则应该暂缓该部分的开发，尽量降低因需求变更而带来的风险。
3.代码走查
软件质量在很大程度上依赖于代码质量。在实际环境中对于同一项目而言，由于项目组成员的编程能力、习惯、风格、对需求的理解和个性的不同，所开发的代码质量也不尽相同。再加上一些难以预测的人为因素，由此带来的隐患将严重影响代码质量，最终造成软件质量低下，使得用户无法正常使用并为以后的维护带来更大的工作量和难度。
考虑到项目进度以及实际情况，要进行完整的代码评审不太现实，因此，在软件开发过程中可以根据需要引进代码走查。每周在规定的时间内，轮流让程序员讲解其所开发代码的主要部分。这项措施一方面可以从侧面促使程序员本人注意所开发代码的质量，另一方面在走查过程中可以获得他人的意見进一步改善代码效率，使开发成员共享项目实施过程中问题解决的思路和方法，同时还可以促进项目组成员之间的交流并加深对需求的理解，关注软件开发过程中的各个环节，并进行过程改善的讨论，使得软件质量更有保障。
4.进行正式的测试，并形成制度
测试就是对软件产品的检验。软件测试的目的是根据用户需求检查系统是否符合项目合同与任务书规定的要求。项目测试分集成测试和系统测试，主要进行功能测试、健壮性测试、性能－效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等活动。测试过程通常在模拟环境中进行。只有通过了上述全部测试的软件，才可以称之为符合用户质量要求的合格的软件。
测试活动要尽可能覆盖整改项目过程，从最初的需求到部署阶段，都应该制订详细的计划并编制相应的文档，如测试计划、测试用例文档、测试报告等。通过测试活动，尽可能早得发现每个阶段中软件存在的缺陷，以方便后续阶段的实施。在这测试活动过程中，我们应该遵守一条基本原则——按照用户需求进行测试。我们即不能为求速度而缩短测试规模，也不能忽视用户需求而提高测试要求。总之，一切测试应该符合用户需求。
四、结论
除了上述几个方面外，对于软件产品的质量管理还有其他要考虑的因素，如风险控制、变更管理和配置管理等等。其实，美国软件工程研究所（SEI）开发的软件过程能力成熟度模型（CMMI）和ISO9001标准，都着眼与质量和过程管理。而且在组织结构方面，国外成熟的软件企业一般都设有单独的QA（Quality Assure）部门，它与开发部门独立，负责监督流程的执行。但是，对于任何一个具体项目的实施都应制订合适的质量管理方案，不能生搬硬套，而这些需要项目经验的积累以及不断的学习新知识。
参考文献
[1]殷立欣:软件开发中的质量管理，软件质量管理，200～3
[2]赵京胜:软件企业实施CMM改进软件过程的研究，计算机工程与设计，2006～3
[3]李健:软件过程质量度量与控制，清华大学出版社，2006～1
[4]罗铁清:软件项目管理流程分析与设计，计算技术与自动化，2005～9