龙潭古镇网站建设,企业主页是什么意思,智能魔方网站,移动网站 pc网站的区别吗信息文档管理与配置管理对于项目管理来说#xff0c;文档非常重要#xff0c;如果是传统的工程行业项目的话#xff0c;仅仅标书就是几百上千页的。相对来说#xff0c;其实信息系统开发项目已经好很多了。另外就是配置项#xff0c;它是比文档更大的一个概念#xff0c;…信息文档管理与配置管理对于项目管理来说文档非常重要如果是传统的工程行业项目的话仅仅标书就是几百上千页的。相对来说其实信息系统开发项目已经好很多了。另外就是配置项它是比文档更大的一个概念项目文档是包含在配置项中的除了文档之外它还包括源程序、计划、报告等。今天我们就主要来看一看在信息系统项目中的这些文档和配置项相关的内容。今天的内容比较长但是只是说明项比较多重点内容其实还好。其它的相关了解知识也都是非常有用的内容大家可以好好看看哦。信息系统项目相关文档软件系统相关的文档一般分为三类包括 开发文档、产品文档、管理文档 。开发文档开发文档用于描述 开发过程本身 基本的开发文档包括可行性研究报告和项目任务书需求规格说明功能规格说明设计规格说明包括程序和数据规格说明开发计划软件集成和测试计划质量保证计划安全和测试信息产品文档产品文档主要是描述 开发过程的产物 包括产品使用、维护、增强、转换、传输方面的内容这些文档包括培训手册参考手册和用户指南软件支持手册产品手册和信息广告管理文档管理文档记录项目管理的信息例如开发过程的每个阶段的进度和进度变更的记录软件变更情况的记录开发团队的职责定义项目计划、项目阶段报告配置管理计划文档的质量文档的质量可以分为四级1最低限度文档1级文档适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。2内部文档2级文档可用于没有与其他用户共享资源的专用程序。除1级文档提供的信息外2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。3工作文档3级文档适合于同一单位内若干人联合开发的程序或可被其他单位使用的程序。4正式文档4级文档适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质如工资计算的程序需要4级文档。4级文档遵守 GB/T8567-2006 的有关规定。配置管理配置管理是为了系统地控制配置变更在系统的整个生命周期中维持配置的完整性和可跟踪性而标识系统在不同时间点上配置的学科。在 GB/T 11457-2006 中将配置管理定义为“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特性控制这些特征的变更记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”其实从上面的定义中我们就可以看出配置管理实际是为了解决多重维护、同时修改以及丢失版本或不知版本的问题。它包括 6 个主要的活动制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。而 CMMI 定义的配置管理主要包含制定配置管理计划、识别配置项、建立配置管理系统、创建或发行基线、跟踪变更、控制变更、建立配置管理记录、执行配置审核、版本控制这些步骤。配置管理计划配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划、配置审核和评审、变更管理等由 CCB变更控制委员会审批该计划。制定配置管理计划便于配置管理员按计划开展配置管理工作并保持配置管理工作的一致性。制定配置管理计划的步骤包括建立并维护配置管理的组织方针确定配置管理需使用的资源分配责任培训计划确定配置管理的项目干系人并确定其介入时机制定识别配置项的准则制定配置管理软件资源制定基线计划制定配置库备份计划制定变更控制流程制定审批计划配置项GB/T 11457-2006 中对配置项的定义为“为配置管理设计的硬件、软件或二者的集合在配置管理过程中作为一个单个实体来对待。”可以作为配置项的有外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据它们经评审和检查通过后进入配置管理。在识别配置项的过程中要遵循下列步骤识别配置项为每个配置项指定唯一的标识号确定每个配置项的重要特征确定配置项进入配置管理的时间确定每个配置项拥有者的责任填写《配置项管理表》审批《配置项管理表》需要加以控制的配置项可以分为基线配置和非基线配置项两类基线配置可能包括所有的设计文档和源程序等非基线配置可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO配置管理员严格管理基本原则是基线配置项向开发人员开放读取权限非基线配置项向 PM、CCB 及相关人员开放。这个我们后面还会说。建立配置管理系统配置管理系统用于控制工作产品的配置管理和变更管理。该系统包括存储媒体、规程和访问配置系统的工具用于记录和访问变更请求的工具。CMO配置管理员建立并维护用于控制工作产品的配置管理系统和变更管理系统。建立配置管理系统的步骤包括建立使用于多控制等级配置管理的管理机制存储和检索配置项共享和转换配置项存储和复原配置项的归档版本存储、更新和检索配置管理记录创建配置管理报告保护配置管理系统的内容权限分配配置库配置库是用于记录与配置的所有信息是配置管理的有力工具利用库中的工具可评价变更的后果这对变更控制有重要意义。从库中还可以提取各种配置管理过程的管理信息可利用库中的信息查询回答许多配置管理的问题。配置库可以分为三种类型开发库Development Library也称为动态库、程序员库、动态系统、开发系统、工作空间或工作库用于保存开发人员当前正在开发的配置实体。无需对其进行配置控制。主要供开发人员使用修改频繁控制宽松。受控库Controlled Library也称为主库、系统库、主系统、受控系统包含当前基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下保存生存期内某一阶段结束时发布的阶段性产品。产品库Product Library也称为静态库、发行库、软件仓库、备份库、静态系统等。包含已发布使用的各种基线的存档被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后作为最终产品存入产品库内等待交付用户或现场安装。配置库的建库模式有两种按配置项的类型分类建库。这种形式适用于产品的继承性较强工作比较统一对并行开发有一定的需求。优点是有利于对配置项的统一管理和控制同时也能提高编译和发布的效率。缺点是由于这样的库结构并不是面向各个开发团队的开发任务所以可能会造成开发人员的工作目录结构过于复杂带来一些不必要的麻烦。按开发任务建库。也可以说是按项目建立相应的配置库。适用于专业软件相关的研发组织优点在于设置策略灵活缺点则是不利于对配置项的统一管理和控制。配置库的权限管理非常重要我们主要通过三个表格来看一下这三个表格其实很清楚了第一个表格说明的是四种操作权限所代表的含义。后两个表格说明的则是不同的角色在不同的库中所拥有的权限。这两个表格大家可以用心多看几遍选择题有可能就冷不丁的来一个项目经理在产品库有没有追加权限之类的问题。版本控制配置项的状态可以分为“草稿Draft”、“正式发布Released”和“正在修改Changing”三种。配置项刚建立时其状态为“草稿”。配置项通过评审后其状态变为“正式”。此后若更改配置项则其状态变为“修改”。当配置项修改完毕并重新通过评审时其状态又变为“正式”。这三种状态变化的过程可以参考下图加深理解。配置项的版本号规则与配置项的状态相关处于“草稿”状态的配置项的版本号格式为 0.YZ YZ的数字范围为01-99。随着草稿的修正YZ的取值应递增。YZ的初值和增幅由用户自己把握。处于“正式”状态的配置项的版本号格式为X.YX为主版本号取值范围为1-9Y为次版本号取值范围为0-9.处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时一般只增大Z值X.Y值保持不变。当配置项修改完毕状态成为“正式”时将Z值设置为0增加X.Y值。一般来说配置项的版本控制流程是先创建配置项然后修改处于“草稿”状态的配置项 0.YZ 的或者“发布”状态的 X.YZ 变成“修改”状态版本号变成 X.Y 。然后通过技术评审或领导审批成为正式“发布”版本版本号也转为 X.Y 。之后进行的变更就继续重复上述的流程即可。配置基线之前我们一直提到了一个名词基线。不知道大家有没有印象其实基线配置基线就是一组经过正式审查并且达成一致的规范或工作产品是开发工作的基础。基线由一组配置项组成这些配置项构成了一个相对稳定的逻辑实体。基线通常对应于开发过程中的里程碑一个产品可以有多个基线也可以只有一个基线。基线的主要属性有名称、标示符、版本、日期等。对于基线来说有几种不同的角度可以划分出许多不同的基线。国家标准功能基线系统规格说明、分配基线需求规格说明书、产品基线软件产品所有配置项规格说明实际工作需求基线、设计基线、测试基线、产品基线对内对外发行基线交付给外部客户、构造基线企业内部使用上面的这几种基线类型的划分也是很容易出选择题的内容哦。建立配置基线的步骤可以概括为以下几步获得CCB授权、创建构造基线或发行基线、形成文件、使基线可用。配置审核配置审核主要是对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象。配置审核的目的就是为了确保项目配置管理的有效性。具体来说包括防止不适用的产品发现不完善的地方找出各配置项之间不匹配的地方确认配置项已在所要求的质量控制审查之后作为基线入库保存确认记录和文档保持着可追溯性。对于配置审核也有两个分类功能配置审核功能配置审核主要是针对验收的着重与功能和文档性的完备。包括检查配置项的 开发 是否已圆满 完成 配置项是否 已达 到规定的 性能 和 功能 特定特性配置项的运行和支持 文档 是否完成是否符合要求。物理配置审核物理配置审核其实主要就是针对开发过程是否正确的审核。包括每个构建的配置项是否符合相应的技术文档系统规格说明书、需求文档、编码标准等配置项与配置状态报告中的信息是否相对应。配置状态报告配置状态报告详细记录了开发过程中的每一项变更反映了开发活动的历史情况从而达到提高所有开发人员之间的通信能力避免出现不一致和冲突的目的。它的内容包括变更内容、变更原因、变更请求人和实施人、变更发生时间、变更影响分析。其实配置状态报告记录的都是变更相关的内容毕竟没有变更状态也就不会发生变化也就没有报告记录的必要后面我们还有一课是专门讲项目变更的。配置状态报告的任务是有效记录和报告管理配置所需要的信息。它的目的是及时、准确地将软件配置项的当前状况供相关人员了解以加强配置管理工作。配置管理中的角色分工最后我们再简单地了解一下配置管理中的角色和分工情况。配置管理过程中有几个重要的角色分别是项目经理、配置控制委员会、配置管理员、开发人员。项目经理PM是整个信息系统开发和维护活动的负责人他根据配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。其具体工作职责如下制定项目的组织结构和配置管理策略批准、发布配置管理计划决定项目起始基线和软件开发工作里程碑接受并审阅配置控制委员会的报告配置控制委员会CCB负责指导和控制配置管理的各项具体活动的进行为项目经理的决策提供建议。其具体工作职责包括批准配置项的标志以及软件基线的建立制定访问控制策略建立、更改基线的设置、审核变更申请根据配置管理员的报告决定相应的对策配置管理员CMO根据配置管理计划执行各项管理任务定期向 CCB 提交报告并列席 CCB 的例会。他们的具体工作职责包括软件配置管理工具的日常管理与维护提交配置管理计划各配置项的管理与维护执行版本控制和变更控制方案完成配置审计并提交报告对开发人员进行相关的培训识别开发过程中存在的问题并制定解决方案开发人员Dev他们的职责就是根据项目组织确定的配置管理计划和相关规定按照配置管理工具的使用模型来完成开发任务。总结看着感觉非常多吧其实重点需要我们关注的内容并不是特别多包括文档分类、文档等级、配置库、版本号、配置审核分类这几块在上面也都加粗或者标红了。其它的内容其实就像开头说过的一样也都是非常有意思的内容有兴趣的同学可以查阅相关的资料继续深入学习哦。参考资料《信息系统项目管理师教程》《某机构培训资料》《项目管理知识体系指南 PMBOK》第六版
