然后我们来看，信息文档管理与配置管理，这个可以保证我们工作有序稳定的推进。
可以看到分为3个部分
然后我们看第一部分:信息系统项目相关信息(文档)
1.软件文档分类 开发文档 产品文档 管理文档
然后我们再来看 开发文档
,基本的开发文档包括: 1. 可行性研究报告 和项目任务书….
开发的3类文档要知道,开发文档,管理文档,产品文档
然后再来看,文档的质量,可以分为4个等级,这个也需要知道
凡是跟工资计算相关的,可以认为是4级文档
群
然后我们看完,项目的文档管理,然后再去看配置管理,
先看定义,以及 配置管理包含的6个主要活动,然后
我们再来看配置管理的概念:
配置管理的概念,我们可以看到有很多,先看
1.典型配置项
2.配置项的分类,这个要记住 要知道计划和报告属于非基线配置项 比如v1.0 v1.1 …等,代码,文档等跟着基线走的,这些属于
基线配置项
配置项的状态这个也需要掌握
有考过..草稿经过评审,变成正式, 正式文档修改了,再次经过评审 也会变成正式的.
然后我们再来看配置版本号,可以看到
草稿的版本是 0.XY 然后正式的版本是 1.1 之类的
然后修改版本是 1.01 类似这样的 3位的
然后在看6，配置项版本管理 7 配置基线
然后我们再来看一下,配置库,可以看到
分类有:开发库 受控库 产品库
配置库,有1.定义 2.分类
3.配置库的建库模式有两种:
按任务建库: 这个适用于专业软件的开发组织..有自己的一套
按配置项类型建库 这个适用于通用软件开发组织,比如可以有 设计库 需求库 开发库 测试库 产品库 验收库等是通用的
4.然后再看配置库的权限设置:
可以看到不同角色,对文档和代码的权限,都没有删除权限对吧. 对文档,项目经理 开发人员 QA 测试人员 都有
read check add 但是只有配置管理员有destroy的权限.
对于代码来说,只有项目经理 和 开发人员 有 read check add 权限
QA 测试人员 只有读的权限
可以看到关于产品库的权限配置, 这里书上可能不对,
项目经理 项目成员 QA 测试人员 都应该只有read的权限,而这里即使是标注了
Check的权限,实际上也只是check out的权限.没有check in的权限.
然后再来看配置控制委员会,这个是CCB 和 变更控制委员会CCB 不是一个意思,虽然都叫CCB
然后再看配置管理员的具体工作
然后再看 配置管理的目标和方针
然后配置管理 1.配置管理的概念 2.配置管理的目标和方针
3.日常配置管理活动
1.配置管理计划
2.配置标识
3.配置控制
4.配置状态报告
5.配置审计
6.发布管理和交付
先看配置管理工作中的，配置管理计划
然后在看配置标识，这里，配置标识的7个步骤
然后是配置控制,配置控制活动 1.变更评估 2.基于配置库的变更控制.
然后我们再来看一下,基于配置库的变更控制过程
然后再来看配置状态报告,配置报告的内容.
配置状态报告以后,然后看配置审计
配置审计的作用 2.配置审计目的 配置审计分类
然后配置审计,配置审计作用 配置审计的目的
按行再来看配置审计分类,
1.功能配置审计
2.物理配置审计
发布管理和交付
涉及活动 : 存储 复制 打包 交付 重建
然后我们再来看,文档管理 配置管理的工具
14.3.1 工具综述
14.3.2 这里的工具有 SVN CC GIT 还有VSS CVS
还有纯手工配置管理,这个也是可以的
然后再看一下,补充考点
CCB 负责审核变更计划
CMO 项目经理 开发人员
每个人的负责的内容
然后去看一下题目
工作性能是功能配置审计
2.配置标识.
CCB可以是兼职人员
4.配置控制委员会成员,不用必须是专职人员
配置管理员的主要工作,将变更后的配置项纳入基线,并将变更内容和结果通知相关人
6.测试完了以后将 全部测试工具 被测试软件 测试支持软件 纳入配置管理
然后 设备故障信息 不是配置状态报告的内容
备份信息也不是.
然后,软件开发人员对文件应该在开发库修改
CCB是审核不是执行
新基线存入产品库以后,旧版本不能删除
9.D 审核要是变更控制委员会
10,该配置项的状态应该从 对需求规格说明书进行变更,应该是 把文件从正式版 变成修改版
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。