|
|
|
|
|
|
|
|
|
|
|
配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。
|
|
|
|
GB/T 11457—2006中，对“配置管理”的正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具，利用库中的信息可回答许多有关配置管理的问题，例如：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。
|
|
|
|
|
|
.开发库：也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
|
|
|
|
.受控库：也称为主库，包含当前的基线以及对基线的变更。受控库中的配置项被置于完全的配置管理之下。可在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
|
|
|
|
.产品库：也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。
|
|
|
|
配置库的建库模式有两种，即按配置项类型建库和按开发任务建库，如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 11457—2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。
|
|
|
|
在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
考虑一个有很多出纳的银行。每一个出纳必须对同一组关系具有同种类型的权限。无论何时指定一个新的出纳，他都必须被单独授予所有这些授权。
|
|
|
|
一个更好的机制是指明所有出纳应该有的授权，并单独标示出哪些数据库用户是出纳。系统可以用这两条信息来确定每一个有出纳身份的人的权限。当一个人被新雇佣为出纳时，必须给他分配一个用户标识符，并且必须将他标示为一个出纳，而不需要重新单独给予出纳权限。
|
|
|
|
角色（role）的概念可用于该机制。在数据库中建立一个角色集，和授予每一个单个用户一样，可将权限授予角色。分配给每个数据库用户一些他（或她）有权扮演的角色（也可能是空的）。
|
|
|
|
事实上，在银行的数据库里，角色的例子可以包括system-administrator、branch-manager、teller和auditor。一个不是很合适的方法是建立一个teller用户号，允许每一个出纳用这个出纳用户号来连接数据库。该机制的问题是它无法鉴别出到底哪个出纳执行了事务，从而导致安全隐患。应用角色的好处是需要每个用户用自己的用户号连接数据库。
|
|
|
|
任何可以授予一个用户的权限都可以授予一个角色。给用户分配角色就跟给用户授权一样。与其他授权一样，一个用户也可以被授予给他人分配角色的权限。这样，可以授予支行经理（branch-manager）分配出纳角色的权限。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
①多媒体软件：项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
|
|
|
|
②多媒体电子出版物：策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cadence公司的PCB系统设计的库管理提供3个工具，分别是PCB库专家、PCB库、库浏览。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
运维是运行维护的简称，是一种IT服务形态。在《信息技术服务分类与代码》（GB/T 29264-2012）中，对运行维护服务（operation maintenance service）给出的定义是“采用信息技术手段及方法，依据需方提出的服务级别要求，对其信息系统的基础环境、硬件、软件及安全等提供的各种技术支持和管理服务”。
|
|
|
|
运维是信息系统全生命周期中的重要阶段，也是内容最多、最繁杂的部分，是对信息系统提供维护和技术支持以及其他相关的支持和服务。运维服务的主要对象包括基础设施、硬件平台、基础软件、应用软件以及依赖于IT基础设施的数据中心、业务应用等信息系统，其范围可以是单个IT基础设施的运维，也可以是整体IT基础设施和业务应用的总体运维。运维服务交付内容主要包括咨询评估、例行操作、响应支持和优化改善。
|
|
|
|
在《信息技术服务分类与代码》（GB/T 29264-2012）中，将运行维护服务分成基础环境运维、硬件运维服务、软件运维服务、安全运维服务、运维管理服务和其他运行维护服务六类，每类运维服务及其说明见下表。
|
|
|
|
|
|
|
|
|
|
任何组织和个人提供运维服务需要依据需方提出的服务级别要求，并确保提供的运行维护服务符合与需方约定的质量要求。因此，具备相应运维服务能力是服务组织提供服务的必要条件，比如规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决事故和问题经验、提供知识的积累和共享手段、实现完善的IT运维管理、提高组织经营水平和服务水平等等。在《信息技术服务运行维护第1部分：通用要求》（GB/T 28827.1-2012）中给出了供方运维服务的能力模型，该模型定义了运行维护服务能力的四个关键要素：人员、资源、技术和过程，每个要素通过关键指标反映应具备的条件和能力。模型也给出了供方为持续提升运维能力的管理方法。
|
|
|
|
|
|
|
|
|
|
|
|
|
