|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。由配置控制委员会审批该计划。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（5）确定和配置管理有关的项目干系人并确定其介入时机。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
变更请求是关于修改任何文档、可交付成果或基准的正式提议。变更请求被批准之后将会引起对相关文档、可交付成果或基准的修改，也可能导致对项目管理计划其他相关部分的更新。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。变更请求可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的。
|
|
|
|
|
|
.纠正措施：为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。
|
|
|
|
.预防措施：为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。
|
|
|
|
.缺陷补救：为了修正不一致的产品或产品组件而进行的有目的的活动。
|
|
|
|
.更新：对正式受控的项目文件或计划等进行的变更，以反映出修改或增加的意见或内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。
|
|
|
|
建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
|
|
|
|
作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
|
|
|
|
如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。
|
|
|
|
（1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
|
|
|
|
（2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
|
|
|
|
（3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
|
|
|
|
另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
|
|
|
|
：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
|
|
|
|
信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
|
|
|
|
|
|
根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。
|
|
|
|
为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。
|
|
|
|
|
|
版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
|
|
|
|
|
|
变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。
|
|
|
|
|
|
配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。
|
|
|
|
（1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。
|
|
|
|
（2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。
|
|
|
|
|
|
状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置控制即配置项和基线的变更控制，配置控制包括如下活动：
|
|
|
|
.变更申请：相关人员如项目经理填写变更申请表，说明要变更的内容、变更的原因、受变更影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人等，并提交给CCB。
|
|
|
|
.变更评估：CCB对变更申请进行评估并确定变更对项目的影响、变更的内容是否必要、变更的范围是否考虑周全、变更的实施方案是否可行、变更工作量估计是否合理。CCB对变更申请作出决定。
|
|
|
|
.通告评估结果：CCB把关于变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人。
|
|
|
|
.变更实施：项目经理组织修改相关的配置项，并在相应的文档或程序代码中记录变更信息。
|
|
|
|
.变更验证与确认：项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交CCB，由其确认变更是否已经按要求完成。
|
|
|
|
.变更的发布：配置管理员将变更后的配置项纳入基线并将变更内容和结果通知相关人员，并做好记录。
|
|
|
|
为了解决一个文档的变更引起多个相关文档的变更时文档修改不全面，以及多个开发人员对同一部件进行修改引起版本混乱等问题，可以基于配置库进行变更控制。
|
|
|
|
|
|
|
|
|
|
下面以某软件产品的升级为例，说明基于配置库变更的流程：
|
|
|
|
（1）将待升级的基线（假设版本号为V1.0）从产品库中复制到受控库。
|
|
|
|
（2）程序员甲将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。代码被检出后即被“锁定”，其他程序员无法检出，以保证同一段代码只能同时被一个程序员修改。
|
|
|
|
（3）程序员甲将开发库中修改好的代码段检入（Check in）受控库。检入后，代码的“锁定”被解除，其他程序员可以检出该段代码了。
|
|
|
|
（4）软件产品的升级修改工作全部完成后，将受控库中的新基线更新到产品库中（软件产品的版本号更新为V1.1，旧的V1.0版并不删除，继续在产品库中保存）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
|
|
|
|
很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。
|
|
|
|
在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。
|
|
|
|
评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
|
|
|
|
评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
|
|
|
|
评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。
|
|
|
|
用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。
|
|
|
|
工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。
|
|
|
|
所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。
|
|
|
|
在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。
|
|
|
|
进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。
|
|
|
|
网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。
|
|
|
|
需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。
|
|
|
|
制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。
|
|
|
|
最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
变更的评估中要充分考虑失败的变更对服务、服务资产和配置的影响，所有变更都需考虑如下因素。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
评估者应基于变更的影响度、紧急度（优先级）、风险、收益和成本来综合评估变更，并要就是否支持该变更做出评估意见。同时，还应该制定详细的变更计划、时间安排以及补救方案。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡的许多阶段，一般称为软件生存周期。把整个软件生存周期划分为若干阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。通常，软件生存周期包括可行性分析与项目开发计划、需求分析、概要设计、详细设计、编码和单元测试、综合测试及维护阶段。
|
|
|
|
|
|
可行性分析与项目开发计划阶段的主要任务是确定软件的开发目标及可行性。必须考虑的关键问题是：“要解决的问题是什么？”“对这些问题有可行的解决办法吗？”等。可行性分析的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。该阶段应该给出关于问题定义、可行性分析和项目开发计划。
|
|
|
|
|
|
需求分析阶段的任务不是具体地解决问题，而是准确地确定软件系统必须做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。
|
|
|
|
|
|
在概要设计阶段，开发人员需要将确定的功能需求转换成相应的体系结构。在该体系结构中，每个成分都是意义明确的模块，即每个模块都和某些功能需求相对应。可见，概要设计就是设计软件的结构，明确软件有哪些模块组成，模块的层次以及功能。与此同时，还要应用系统的总体数据结构和数据库结构。
|
|
|
|
|
|
详细设计阶段的主要任务就是对每个模块完成的功能进行具体描述，不是编写程序，而是设计出程序的详细规格说明，该说明应该包含必要的细节，使程序员可以根据它们写出实际的程序代码。通常采用HIPO（层次加输入／处理／输出图）或PDL语言（过程设计语言）描述详细设计的结果。
|
|
|
|
|
|
编码和单元测试阶段就是把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单，并仔细测试编写出的每一个模块。
|
|
|
|
|
|
综合测试阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参与下）对目标系统进行验收。通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。
|
|
|
|
|
|
维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
依据知识库内容加入的审核标准，由资深技术人员审核内容的正确性和完整性，避免与原有的知识库内容重复或冲突，给出审核意见后提交批准加入知识库中。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
完整性（Integrity）是指网络信息或系统未经授权不能进行更改的特性。例如，电子邮件在存储或传输过程中保持不被删除、修改、伪造、插入等。完整性也被称为网络信息系统CIA三性之一，其中I代表Integrity。完整性对于金融信息系统、工业控制系统非常重要，可谓“失之毫厘，差之千里”。
|
|
|
|
|
|
|
|
|
|
|
|
|
