导图社区 第15章 信息(文档)和配置管理
软考中项/系统集成项目管理工程师/第15章 信息(文档)和配置管理,介绍详细,描述全面,希望对感兴趣的小伙伴有所帮助!
编辑于2024-02-24 02:23:02系统集成项目管理工程师第3版/第18章 职业道德规范,道德是由一定的社会经济关系所决定的特殊意识形态。社会存在决定社会意识,而社会经济关系是最根本的社会存在。
系统集成项目管理工程师第3版/第17章 法律法规与标准规范,法是由国家制定、认可并保证实施,以权利义务为主要内容,由国家强制力保证实施的社会行为规范及其相应的规范性文件的总称。
系统集成项目管理工程师第3版/第16章 监理基础知识,信息系统监理通常直接面对业主单位和承建单位,在双方之间形成一种系统的工作关系,在保障工程质量、进度、投资控制和合同管理、信息管理,协调双方关系中处于重要的、不可替代的地位。
社区模板帮助中心,点此进入>>
系统集成项目管理工程师第3版/第18章 职业道德规范,道德是由一定的社会经济关系所决定的特殊意识形态。社会存在决定社会意识,而社会经济关系是最根本的社会存在。
系统集成项目管理工程师第3版/第17章 法律法规与标准规范,法是由国家制定、认可并保证实施,以权利义务为主要内容,由国家强制力保证实施的社会行为规范及其相应的规范性文件的总称。
系统集成项目管理工程师第3版/第16章 监理基础知识,信息系统监理通常直接面对业主单位和承建单位,在双方之间形成一种系统的工作关系,在保障工程质量、进度、投资控制和合同管理、信息管理,协调双方关系中处于重要的、不可替代的地位。
信息(文档)和配置管理
信息(文档)
含义
是指某种数据媒体和其中所记录的数据。具有永久性,并可以由人或机器阅读,通常仅用于描述人工可读的东西。
在软件工程中,文档常常用来表示对活动、需求、过程或结果,进行描述、定义、规定、报告或认证的任何书面或图示的信息(包括纸质文档和电子文档)
种类
开发文档
含义
描述开发过程本身
包括
可行性研究报告和项目任务书、需求规格说明书、功能规格说明书、设计规格说明书,包括程序和数据规格说明书、开发计划、软件集成和测试计划、质量保证计划、安全和测试信息
产品文档
含义
描述开发过程的产物
包括
培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告
管理文档
含义
记录项目管理的信息
包括
开发过程的每个阶段的进度和进度变更的记录、软件变更的情况记录、开发团队的责任定义
文档质量分为四级
最低限度文档(1级文档)
适用
适合开发工作量低于一个人月的开发者自用程序
包括
程序清单、开发记录、测试记录和程序简介
内部文档(2级文档)
适用
可用于没有与其他用户共享资源的专用程序
包括
除1级文档提供的信息外还包括程序清单内足够的注释以帮助用户安装和使用程序
工作文档(3级文档)
适用于由同一个单位内若干人联合开发的程序,或可被其他单位使用的程序
正式文档(4级文档)
适合那些要正式发行供普遍使用的软件产品。关键性程序或具用重复管理应用性质的程序,需遵守GB8567的有关规定
规范化管理
文档书写规范
涉及文本、图形和表格等多种类型,无论哪种类型都应该遵循统一的书写规范,包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等
图表编号规则
文档目录编写标准
包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等。
文档管理制度
根据组织实体的具体情况而定,主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则
配置管理
是为了系统的控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性 GB/T11457-2006中正式定义为,应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征,控制这些变更的特征,记录和报告变更处理和实现状态并验证与规定的需求的遵循性
概念
配置项
为配置管理涉及的硬件、软件或二者的集合,在配置管理过程中作为一个单个实体来对待
包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据,经评审和检查通过后进入配置管理
所有的配置项都应该按照相关的规定统一编号,按照相应的模版生成,并在文档中的规定张杰记录对象的标识信息
分类
基线配置项
向开发人员开放读取的权限
包括所有的设计文档和源程序
非基线配置项
向PM、CCB及相关人员开放
包括项目的各类计划和报告
所有的配置操作权限应由CMO配置管理员严格管理
配置项状态
草稿
配置项刚建立时
正式
配置项通过评审后
修改
更改配置项
配置项版本号
草稿
0.YZ,YZ范围01-99
正式
X.Y,X为主版本号,范围1-9、Y为次版本号,范围0-9,第一次正式文件版本号1.0
修改
X.YZ,一般只增大Z值,X Y保持不变
配置项版本管理
目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确的查找到配置项的任何版本
配置基线
由一组配置项组成
基线中的配置项被“冻结”了,不能再被任何人随意修改
基线通常对应于开发过程中的里程碑,一个产品可以有多个基线,也可以只有一个基线
发行基线—交付给外部客户的基线
构造基线—内部开发使用的基线
在项目实施过程中,每个基线都要纳入配置控制,对这些基线的更新只能采用正式的变更控制程序
好处
(1)基线为开发工作提供了一个定点和快照。
(2)新项目可以在基线提供的定点上建立。新项目作为一个单独分支,将与随后对原始项目(在主要分支上) 所进行的变更进行隔离。
(3)当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法
(4)可以利用基线重新建立基于某个特定发布版本的配置,以重现已报告的错误
配置库
概念
存放配置项并记录与配置项相关的所有信息
是配置管理的有力工具,利用库中的信息可以回答许多配置管理的问题
类型
开发库(动态库、程序员库、工作库)
用于保存开发人员当前正在开发的配置实体。动态中的配置项被置于版本管理之下,动态库是开发人员的个人工作区,由开发人员自行控制
受控库(主库)
包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个工作结束时,将当前的工作产品存入受控库
产品库(静态库、发行库、软件仓库)
包含已发布使用的各种基线的存档,被置于完全的配置管理之下。在开发信息系统产品完成系统测试之后,作为最终的产品存入产品库内,等待交付用户或现场安装
建库模式
按配置项的类型分类建库
适用于通用软件的开发组织。产品的继承性往往较强,工具比较统一,对并行开发有一定的需求
按开发任务建立相应的配置库
适用于专业软件的开发组织。开发工具种类繁多,开发模式以线性发展为主
配置库权限设置
配置控制委员会
负责对配置变更做出评估、审批以及监督已批准变更的实施
CCB不必是常设机构
CCB在建立项目时,成员包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员
CCB不只是控制配置变更,而是负有更多的配置管理任务,如配置管理计划审批、基线建立审批、产品发布审批
小的项目CCB可以只有一个人,甚至是兼职人员
配置管理员
负责在项目的整个生命周期中进行配置管理活动
包括编写配置管理计划、建立和维护配置管理系统、建立和维护配置库、配置项识别、建立和管理基线、版本管理和配置控制、配置状态报告、配置审计、发布管理和交付、对项目成员进行配置管理培训。
配置管理系统
用来进行配置管理的软件系统
最根本要求
不允许出现任何混乱现象
6项活动
制定配置管理计划
配置管理计划是对如何开展项目配置管理工作的规划,是配置管理过程的基础,应该形成文件并在整个项目生命周期内处于受控状态。配置控制委员会负责审批该计划。
内容
配置管理活动
覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付
实施这些活动的规范和流程
实施这些活动的进度安排
负责实施这些活动的人员和组织,以及他们和其他组织的关系
配置标识
也称配置识别,包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征
配置标识是配置管理员的职能
步骤
识别需要受控的配置项
为每个配置项指定唯一性的标识号
定义每个配置项的重要特征
确定每个配置项的所有者及其责任
确定配置项进入配置管理的时间和条件
建立和控制基线
维护文档和组件的修订与产品版本之间的关系
配置控制
配置控制即配置项和基线的变更控制,包括下述任务:标识和记录变更申请,分析和评价变更,批准或否决由请,实现、验证和发布已修改的配置项。
步骤
变更申请
变更评估
变更对项目的影响
变更的内容是否必要
变更的范围是否考虑周全
变更的实施方案是否可行
变更的工作量估计是否合理
通告评估结果
变更实施
变更验证与确认
变更的发布
基于配置库的变更控制
流程
(1)将待升级的基线(假设版本号为 V2.1) 从产品库中取出,放入受控库
(2)程序员将欲修改的代码段从受控库中检出(Check out),放入自己的开发库中进行修改。
(3)程序员将开发库中修改好的代码段检入(Check in) 受控库。
(4)软件产品的升级修改工作全部完成后,将受控库中的新基线存入产品库中
配置状态报告
也称配置状态统计,有效的记录和报告配置管理所需的信息,目的是及时、准确的给出配置项的当前状态,供相关人员了解,以加强配置管理工作
内容
每个受控配置项的标识和状态
每个变更申请的状态和已批准的修改的实施状态
每个基线的当前和过去版本的状态以及各版本的比较
其他配置管理过程活动的记录
配置审计
也称配置审核或配置评价
功能配置审计
审计配置项的一致性
包括
(1) 配置项的开发已圆满完成
(2) 配置项已达到配置标识中规定的性质和功能特征
(3) 配置项的操作和支持文档已完成并且是符合要求的
物理配置审计
审计配置项的完整性
包括
(1)要交付的配置项是否存在
(2)配置项中是否包含了所有必须的项目
发布管理和交付
任务是:有效控制软件产品和文档的发行和交付,在软件产品的生产期内妥善保存代码和文档的母拷贝
步骤
存储
复制
打包
交付
重建
项目计划书、需求文档、设计文档、源代码 可执行代码、测试用例、运行软件所需的各种数据