北京可以治疗白癜风的医院 https://wapjbk.39.net/yiyuanfengcai/video_bjzkbdfyy/在《信息系统项目管理师第3版》中有一单独章节来对信息文档管理与配置管理进行介绍，也确实符合中国的实际国情，将引入的项目管理知识与之相结合形成符合我们需要的知识。现将自己对这块内容的理解和认识整理整理，希望能对大家有所帮助。知识小结1、软件配置管理涵盖了项目的整个生命周期。2、配置管理包括6个主要活动：制定配置管计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。3、典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理；注意：测试报告、会议纪要、工作记录不计入配置项的内容；因为一经形成就不好修改了！4、所有配置项的操作权限由配置管理人员（CMO)严格管理，基本原则是：基线配置项向软件开发人员开放读权限：非基线配置项向PM,变更控制委员会（CCB)及相关人员开放。5、基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等；6、配置项的状态可分为“草稿”、“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。（1）、处于“草稿”状态的配詈项的版本号格式为0.YZ，YZ的数字范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。（2）、处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9。配置项第一次成为“正式”文件时，版本号为1.0。（3）、处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕,状态成为“正式”时，将Z值设置为0，增加X.Y值。7、配置项的版本控制作用于多个配置管理活动之中，如创建配置项、配置项的变更和配置项的评审等。在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。8、基线：由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随竟修改。对基线的变更必须遵循正式的变更控制程序。在建立基线以前，工作产品所有者能快速、非正式的对产品做出变更。在基线建立后，变更要通过评价证变更的正式程序来控制。9、基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被冻结了，不能再被任何人随意修改。基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。通常将总价值给客户的基线称为一个发行基线“Release,为内部开发用的基线则称为一个构造基线“Build”。配置项是可以要改的，在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来，只是需要做好版本控制管理。10、一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。产品的一个测试版本(可能包括需求分析说明书、.概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。11、对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。12、建立基线还可以有如下好处：(1) 基线为开发工作提供了一个定点和快照。(2) 新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目(在主要分支上）所进行的变更进行隔离。(3) 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。(4) 可以利用基线重新建立基于某个特定发布版本的配置，以重现己报告的错误。13、配置库可以分为开发库、受控库、产品库3种类型。（1）、开发库(DevelopmentLibrary).也称为动态库、程序员库或工作库,用于保存开发人员当前的配置实体，动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改。（2）、受控库(ControlledLibrary),也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结柬时，将当前的工作产品存入受控库。（3）、产品库(ProductLibrary),也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。14、配置库的建库模式有两种：按配置项类型建库和按任务建库。（1）、按配置项的类型分类建库，适用于通用软件的开发组织。在这样的组织内，产品的继承性往往较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。（2）、按开发任务建立相应的配置库，适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活。15、用于建立配置库的工具：VSS、CVS；也可以通过手工方式进行建库;16、配置库的操作权限17、受控库的权限设置18、产品库的权限设置19、配置（标识）识别是配置管理员的职能，包括内容：(1) 识别需要受控的配置项;(2) 为每个配置项指定唯一性的标识号;(3) 定义每个配置项的重要特征；(4) 确定每个配置项的所有者及其责任；(5) 确定配置项进入配置管理的时间和条件；(6) 建立和控制基线；(7) 维护文档和组件的修订与产品版本之间的关系。20、配置管理计划的主要内容为：(1) 配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付；(2) 实施这些活动的规范和流程；(3) 实施这些活动的进度安排；(4) 负责实施这些活动的人员或组织，以及他们和其他组织的关系。21、配置状态报告也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作。配置状态报告应着重反映当前基线配置项的状态，以向管理者报告系统开发活动的进展情况。22、配置状态报告应该包含以下内容：(1)每个受控配置项的标识和状态。一旦配置项被置于配置控制下，就应该记录和保存它的每个后继进展的版本和状态。(2)每个变更申请的状态和己批准的修改的实施状态。(3) 每个基线的当前和过去版本的状态以及各版本的比较。(4) 其他配置管理过程活动的记录。23、配置审计的实施是为了确保项目配置管理的有效性，不允许出现任何混乱现象，例如：(1) 防止向用户提交不适合的产品，如交付了用户手册的不正确版本；(2) 发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更；(3) 找出各配置项间不匹配或不相容的现象；(4) 确认配置项己在所要求的质量控制审核之后纳入基线并入库保存；(5) 确认记录和文档保持着可追溯性。24、配置审计可分为功能性配置审计和物理配置审计；25、功能配置审计是进行审计以验证以下几个方面：(1) 配置项的开发己圆满完成(2) 配置项己达到规定的性能和功能特定特性(3) 配置项的运行和支持文档己完成并且是符合要求的26、物理配置审计是进行审计以验证如下方面：(1) 每个构建的配置项符合相应的技术文档(2) 配置项与配置状态报告中的信息相对应27、项目经理组织修改相关的配置项，并在相应的文挡或程序代码中记录变更信息。软考真题这部分知识相关的考题不难，对书本上的知识有个印象考试的时候基本就都能答对了。1、配置审核的实施可以（）。A.防止向用户交付用户手册的不正确版本B.确保项目进度的合理性C.确认项目分解结构的合理性D.确保活动资源的可用性2、软件配置管理受控制的对象应是（64），实施软件配置管理包括4个最基本活动，其中不包括（65）。（64）A.软件元素B.软件项目C.软件配置项D.软件过程（65）A.配置项标识B.配置项优化C.配置状态报告D.配置审计3、某软件开发项目的需求规格说明书第一次正式发布，命名为《需求规格说明书V1.0》，此后经过两次较小的升级，版本号升至V1.2，此时客户提出一次需求变更，项目组接受了变更，按客户的要求对需求规格说明书进行了较大的改动并通过评审，此时版本号应升级为（66）A.V1.3B.V1.5C.V2.0D.V3.04、基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体，是一组经过（62）正式审查、批准、达成一致的范围或工作产品，其主要属性一般主要包括（63）。（62）A、用户B、配置管理员C、配置控制委员会D、专家组（63）A、配置项、标识符、版本、流程B、配置项、名称、流程、日期C、名称、标识符、版本、日期D、配置计划、版本、状态、流程5、配置管理是软件生命周期中的重要控制过程，在软件开发过程中扮演着重要的角色，根据GB/T-《软件工程术语》的描述，以下关于配置管理基线的叙述中，（）是不正确的。A、配置管理基线包括功能基线，即最初通过的功能的配置B、配置管理基线包括分配基线，即最初通过的分配的配置C、配置管理基线包括产品基线，即最初通过的或有条件通过的产品的配置D、配置管理基线包括时间基线，即最初通过的时间安排真题参考答案1、分析：配置审核的实施是为了确保项目配置管理的有效性，体现配置管理的最根本要求，不允许出现任何混乱现象，如：l防止出现向用户提交不适合的产品，如交付了用户手册的不正确版本。l发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。l找出各配置项间不匹配或不相容的现象。l确认配置项已在所要求的质量控制审查之后作为基线入库保存。l确认记录和文档保持着可追溯性。参考答案：A2、参考答案：（64）C、（65）B3、分析：1)处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01～99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。2)处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1～9。Y为次版本号，取值范围为0～9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1，……。当附件的变动积累到一定程度时，配置项豹Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值。3)处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。参见上述规则（2）。参考答案：C4、分析：基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（如：跟踪和控制变更）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。参考答案：（62）C、（63）C5、分析：2.基线baselinea）业已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理过程方能加以修改的规格说明或产品；b）在配置项目生存周期的某一特定时间内，正式指定或固定下来的配置标识文件和一组这样的文件。基线加上根据这些基线批准同意的改动构成了当前配置标识；参见：分配的基线allocatedbaseline（2.57）、开发配置developmentalconfiguration（2.）、功能基线functionalbaseline（2.）和产品基线productbaseline（2.）。c）任何协议或在一给定时间赋予或固定的结果，如要变更，要求证明和批准。对于配置管理，有以下三种基线：功能基线——最初通过的功能配置；分配基线——最初通过的分配的配置；产品基线——最初通过的或有条件地通过的产品配置。参考答案：D
转载请注明：http://www.0431gb208.com/sjslczl/9038.html
