导图社区 信息系统文档和配置管理
简单列出了软件项目管理过程中产生的文档是如何分类管理，如何做好配置管理的，以及配置管理要做的步骤，需要可收藏。
总结了向上管理的8个关键：明确需求、站对立场、分清矛盾、适当示弱、解决问题、提供信息、执行命令、理解与支持以及每个关键的注意点
总结了私域运营引流入口最强攻略的8个方面：微信、抖音、小红书、微博、知乎、B站、今日头条、快手，列出了每个方面的引流入口
总结了裂变增长的底层逻辑，主要从社交驱动、效率驱动、信任驱动、资源驱动 四个方面以及每个方面的实现，简单的讲述
社区模板帮助中心，点此进入>>
互联网9大思维
组织架构-单商户商城webAPP 思维导图。
域控上线
python思维导图
css
CSS
计算机操作系统思维导图
计算机组成原理
小学教育知识与能力
IMX6UL(A7)
信息系统相关文档
文档的种类
开发文档
开发文档描述开发过程本身，基本的开发文档包括以下八个方面：
可行性研究报告和项目任务书
需求规格说明
功能规格说明
设计规格说明，包括程序和数据规格说明
开发计划
软件集成和测试计划
质量保证计划
安全和测试信息
产品文档
产品文档描述开发过程的产物，基本包括以下四个方面：
培训手册
参考手册和用户指南
软件支持手册
产品手册和信息广告
管理文档
管理文档记录项目管理的信息
开发过程的每个阶段的进度和进度变更的记录
软件变更情况的记录
开发团队的职责定义
项目计划、项目阶段报告
配置管理计划
文档质量分级
最低限度文档（1级文档），适合开发工作量低于一个人月的开发者自用程序。包括程序清单、开发记录、测试数据和程序简介
内部文档（2级文档），可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
工作文档（3级文档），适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序
正式文档（4级文档），适合那些要正式发行供普遍使用的软件产品
文档管理的规则和方法
文档编写规范
图标编号规则
文档目录编写标准
文档管理制度
配置管理
定义
配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科
配置管理活动
配置管理包括6个活动
制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付
配置项
外部交付的软件产品和数据
指定的内部软件工作产品和数据
指定的用于创建或支持软件产品的支持工具
供方/供应商提供的软件和客户提供的设备/软件
项目计划书
需求文档
设计文档
源代码
可执行代码
测试用例
运行软件所需的各种数据
所有配置项的操作权限有配置管理员管理，基线配置项向开发人员开发只读权限；非基线配置项向PM、CCB及相关人员开发
配置项状态
配置项状态可分为“草稿”、“正式”、“修改”三种
配置项版本号
处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01~99
处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9
配置项第一次成为“正式”文件时，版本号为1.0
处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。
配置项版本管理
配置基线
基线通常对应于开发过程中的里程碑
交付给外部顾客的基线一般称为发行基线，内部开发使用的基线一般称为构造基线
建立基线的事件
受控的配置项
建立和变更基线的程序
批准变更基线所需的权限
每个基线定义的内容
基线为开发工作提供了一个定点和快照
新项目可以再基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离
当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法
可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误
建立基线的好处
配置库
开发库
动态库或工作库，用于保存开发人员当前在开发的配置实体
动态库是开发人员的个人工作区，由开发人员自行控制，无需对其进行配置控制
受控库
成为主库，包含当前的基线加上对基线的变更
受控库中的配置项被置于完全的配置管理之下
在开发的某个阶段工作结束时，将当前的工作产品存入受控库
产品库
也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下
在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装
建库
有两种建库模式：按配置项类型建库和按任务建库
按配置项的类型分类建库：适用于通用软件的开发组织，产品的继承性较强
按开发任务建立相应的配置库，适用于专业软件的开发组织，采用这种设置策略比较灵活
配置库权限设置
配置控制委员会CCB
负责对配置变更做出评估、审批以及监督已批准变更的实施
CCB建立在项目级，其成员可以包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等
CCB不是控制配置变更，而是负有更多的配置管理任务，例如基线审批，配置管理计划审批
配置管理员CMO
编写配置管理计划
建立和维护配置管理系统
建立和维护配置库
配置项识别
建立和管理基线
版本管理和配置控制
配置状态报告
配置审计
发布管理和交付
对项目成员进行配置管理培训
配置管理系统
是用来进行配置管理的软件系统
配置管理方针
确定配置管理目标
确保软件配置管理计划得以制订，并经过相关人员的评审和确认
应该识别出要控制的项目产品有哪些，并且制订相关控制策略，以确保这些项目产品被适合的人员获取
应制订控制策略，以确保项目产品在受控制范围内更改
应该采取适当的工具和方法，确保相关组别和个人能够及时了解到软件基线的状态和内容
确定配置管理的方针
日常配置管理活动
制订配置管理计划
配置管理活动，覆盖的主要活动包括配置标识、配置控制、配置状态报告、配置审计、发布管理与交付
实施这些活动的规范和流程
实施这些活动的进度安排
负责实施这些活动的人员或组织，以及他们和其他组织的关系
配置管理计划包括的内容
配置项标识
识别需要受控的配置项
为每个配置项指定唯一性的标识号
定义每个配置项的重要特征
确定每个配置项的所有者及其责任
确定配置项进入配置管理的时间和条件
建立和控制基线
维护文档和组件的修订与产品版本之间的关系
配置项标识是配置管理员的职能，需要包括这些步骤
配置控制
变更申请
变更评估
变更对项目的影响
变更的内容是否必要
变更的范围是否考虑周全
变更的实施方案是否可行
变更工作量估计是否合理
CCB组织对变更申请评估需确定的内容
CCB决定是否接受变更，并将决定通知相关人员
通告评估结果
变更实施
变更验证与确认
变更发布
基于配置库的变更控制
将待升级的基线（假设版本号为V2.1）从产品库中取出，放入受控库
程序员将欲修改的代码段从受控库中检出（Check out），放入自己的开发库中进行修改。
代码被Check out后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对其修改，乙就无法Check out
程序员将开发库中修改好的代码段检入（Check in）受控库。Check in后，代码的“锁定”被解除，其他程序员可以Check out该段代码了
软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的版本号更新为V2.2，旧的V2.1版并去删除，继续在产品库中保存）
以某个软件产品升级为例讲述配置库变更控制
每个受控配置项的标识和状态
每个变更申请的状态和已批准的修改的实施状态
每个基线的当前和过去版本的状态以及各版本的比较
其他配置管理过程活动的记录
配置状态报告包括的内容
作用
防止向用户提交不适合的产品
发现不完善的实现
找出各配置项已在所要求的质量控制审核之后纳入基线并入库保存
确认记录和文档保持着可追溯性
功能配置审计
配置项的开发已圆满完成
配置项已达到配置标识中规定的性能和功能特征
配置项的操作和支持文档已完成并且是符合要求的
是审计配置项的一致性（配置项的实际功效是否与其需求一直）
物理配置审计
要交付的配置项是否存在
配置项中是否包含了所有必需的项目
是审计配置项的完整性（配置项的物理存在是否与预期一致）
存储
将副本存储在不同的受控场所，以减少丢失的风险
复制
建立规程以确保复制的一致性和完整性
确保发布用的介质不含无关项
使用适合的介质以确保软件产品符合复制要求，确保其在整个交付期中内容的完整性
打包
交付
重建
配置管理工具
开源的工具：SVN、GIT、CVS
信息文档管理与配置管理
