项目数字化管理解决方案.docx
《项目数字化管理解决方案.docx》由会员分享，可在线阅读，更多相关《项目数字化管理解决方案.docx（19页珍藏版）》请在冰豆网上搜索。
项目数字化管理解决方案
项目数字化管理解决方案
1项目配置管理
1.1配置管理的意义
很多项目实施过程中遇到的问题大都是因配置管理不善而造成的，而发生这些问题需要时间去确定，而且有可能很多是重复的问题。
通过常年对基础教育领域信息化建设的关注与理解，以及在教育行业信息化建设领域取得的成功经验，认为精准教育大数据平台项目在建设过程中，要采用精英管理团队，利用成熟的项目配置管理理念对本项目建设过程进行综合管理，跟踪管理项目建设过程提供支持与帮助，保障项目的成功实施。
⏹不做配置管理可能引起的混乱
Ø发给用户的软件产品的用户手册是老版本，没有及时更新；
Ø系统内某个模块已开发完成，可是安装后就是不工作；
Ø在某个学校能正常使用的云平台系统，到另外的学校就出问题；
Ø上个月已解决的缺陷，现在又出现；
Ø最新修改的源程序找不到；
Ø上个月用户让做某个变更，这个月又不要了……
Ø接收别人的工作很困难！
Ø……
⏹配置管理带来的好处
Ø项目参与各方对本项目有哪些财富都很清楚：
统一的库结构和库的演化过程；
Ø开发过程中不会产生版本混乱的现象：
统一的版本控制规则；
Ø项目的劳动成果得到保障：
统一标识工作产品并定期备份；
Ø项目组在每一阶段的工作都是始于相同的起跑线：
建立相对稳定的基线；
Ø不因为个人意愿使本项目的劳动成果被修改：
基线的修改会得到审计和跟踪；
Ø各个角色都很清楚工作产品的变化：
状态报告和变更通知；
Ø项目财富会越积累越多：
文档库的积累，最佳实践的提取；
Ø有人专注于项目工作产品的存放和一致性：
QA对配置管理的审计；
1.2配置管理的基本概念
第1章
1.1
1.2
1.2.1软件配置管理
软件配置管理（SoftwareConfigurationManagement）是指标识、定义系统中软件项并制定基线；控制软件项的修改和发行；记录和报告软件项的状态和修改申请；保证软件项的完整性、协调性和正确性；以及控制软件项的储存、装载和交付。
主要是对软件生存期过程中的各种阶段产品和最终产品演化和变更的管理，是软件质量管理的重要组成部分。
目的是在整个软件生命周期中建立和维护软件项目中的产品的完整性。
它包括标识在给定时间点上软件的配置，系统地控制对配置的更改，并维护在整个软件生命周期内配置的完整性和可跟踪性。
IEEE对软件配置管理的定义：
是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性、控制这些特性的变更、记录和报告变更的过程和状态，并验证它们与需求是否一致。
”
1.2.2软件配置项
软件开发的过程中，会得到许多工作产品、阶段产品或者工具软件。
所有这些独立的信息项都要得到妥善的管理，不能出现混乱，在提出某些特定的要求时，能将其进行约定的组合来使用。
这些信息项是配置管理的对象，称为软件配置项（SoftwareConfigurationItem）。
例如，需求规格说明、设计规格说明、用户手册、维护使用手册都属于此。
1.2.3基线
基线（Baseline）是一个或者一组配置项的组合。
它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。
IEEE对于基线的定义是：
已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。
1.2.4配置项标识
软件配置标识是软件配置管理的基础性工作，是管理配置的前提。
Ø确定配置项；
Ø配置项命名（唯一性、可追溯性）；
1.2.5配置管理委员会
Ø软件配置管理控制委员会，负责评价、认可或否定有关配置项更改建议并确保确认的更改得以执行的一个小组，负责管理项目软件基线和最终产品发布；
Ø主要成员，一般是部门经理、PM、SQA、SCM、分析设计员等人员组成。
1.2.6配置库
Ø管理各基线和配置项的一个工具；
Ø分为开发库和配置库，配置库又分为基线库和非基线库。
1.2.7标签
Ø软件配置实际上是一个动态的概念。
一方面随软件生命周期向前推进，配置项的数量在不断增多，另一方面又会随时有新的变更出现，形成新的版本。
Ø为了方便对配置项在各阶段进行控制和管理，不致造成混乱，应在配置项入库时，将其相关信息记录在Label中。
ØLabel是配置项入库时的标签记录。
配置项纳入配置库中时，应该及时的打标签，记录配置项的相关信息。
Ø例如：
配置项纳入时间、配置项提交人、配置项的版本号、此版本的配置项与上版本相比，有何改动、等等，特别是修改后的源程序，要在标签中记录清楚基于上次版本修改了哪些内容。
Ø配置项打上标签后，表明该配置项已经受控，不能随意改动，如有修改，必须走变更申请的流程。
1.3配置管理活动
1.3
1.3.1配置项和基线
项目开始阶段就要确定本项目的配置项CSCIs（ComputerSoftwareConfigurationItem），根据其在项目中的作用为每个基线和配置项CSCI分配唯一的标识并形成一系列的基线，策划每个CSCI在项目不同时期的版本状态。
1.基线
根据项目裁剪过程，确定项目的正式基线如下
编号
基线名称
基线建立时机
计划建立时间
基线变更权威
1
项目启动基线
1.项目启动，配置资料库创建，项目任务书已下达
2.召开项目启动会后。
参照项目计划
CCB
2
项目计划基线
1.已经完成项目总体进度计划计划的制定
2.已经完成项目部署实施方案的制定。
3.已经完成配置管理计划和质量管理计划
4.所有计划均已通过评审后
参照项目计划
CCB
3
项目调研&需求基线
1.完成需求调研；
2.完成部署实施环境调研
3.完成需求规格文档编写
4.完成部署实施方案文档编写；
5.所有文档已经通过评审
参照项目计划
CCB
4
软件开发基线
1.云平台已经完成数据库设计、概要设计和详细设计
2.云平台的设计文档已经通过评审。
3.云平台系统编码工作已经完成，并已通过单元测试。
参照项目计划
CCB
5
软件发布基线
1.系统测试完成，所发现的所有缺陷已得到妥善处理
2.符合系统测试退出条件
3.已完成测试分析报告
4.生成可执行安装包
5.用户要求提交的文档及发行相关文档准备完毕。
6.发行/产品基线建立
参照项目计划
CCB
6
硬件实施完成
1.项目计划规定的所有硬件与成熟软件部署完成
2.已经形成计划、部署、测试和培训文档
3.方案、计划、实施和培训文档已经经过外部评审
4.系统集成工作已经经过用户验收，进入试运行阶段
参照项目计划
CCB
7
项目结束
1.已经完成对用户的培训
2.已经完成项目的试运行
3.所有试运行期间工作已经形成文档产物
4.项目结项工作结束
5.开发活动停止
参照项目计划
CCB
2.配置项
项目开始时，配置人员和项目经理共同选择并确定适用于本项目的配置项，并为配置项分配标识。
在VSS中，通过基线来标识这些配置项及其版本信息，通过配置项状态报告报出。
本项目关注的重要配置项如下表：
分类
元素列表
作者
立项管理
项目任务书.doc
PMO
项目合同书
（业主）
项目计划
项目实施计划.mpp
项目经理
项目监控
项目周报
项目经理
QA周报
QA
项目状态报告（里程碑评审报告）
项目经理、QA
项目会议记录
QA
风险管理
项目风险管理方案
项目经理
TOP10风险清单
项目经理
度量与分析
项目度量计划（项目状态报告）
QA
项目度量数据表
QA
技术评审
技术评审计划
QA
技术评审报告
QA
评审检查表
QA
需求管理
需求跟踪矩阵
项目经理
变更控制
变更提案
项目经理
质量保证
质量保证计划
QA
工作成果审计报告
QAQC
过程审计报告
QAQC
产品质量分析报告（项目状态报告）
QAQC
不符合问题报告
QAQC
配置管理
配置管理计划
QAQC
配置项状态报告
QAQC
基线发布报告
QA、项目经理
结项管理
项目总结报告：
项目经理
客户满意度调查报告
项目经理
结项评审报告
项目经理、QA
培训管理
培训计划
培训经理
培训记录单
培训经理
培训总结报告
培训经理
外包与采购管理
采购清单
采购经理
采购合同
采购经理
验收报告
采购经理、QA
服务与维护
服务维护计划（推进计划）
分项项目经理、客户接口人
服务维护记录（试运行期间的调研记录、培训记录、服务支持记录、问题跟踪记录单）
分项项目经理、客户接口人
需求
需求调研记录
产品经理
需求规格说明：
产品经理
专业术语表
技术经理
原型
设计经理
用户需求调查材料
项目经理保管
设计
概要设计
概要设计规格说明
技术经理
数据库设计（PDM）
技术经理
用户界面设计规格说明：
UI、技术经理
项目编码规范：
技术经理
详细设计
内部设计：
不限形式
技术经理
详细设计规格说明
技术经理
软件建造命令：
技术经理
UI详细设计：
技术经理
代码
项目源代码工程文件：
各模块负责人
系统测试
系统测试计划
测试经理
系统测试用例
测试经理
系统测试记录
测试经理
系统测试总结报告：
测试经理
验收测试
验收测试报告：
第三方测试机构
试运行测试
测试资料包：
{BETA软件、测试指导手册（测试说明）测试意见反馈表}
项目组
系统部署记录
分项项目经理、测试经理
测试总结报告
测试经理
用户文档
用户操作指南or用户使用说明书
分项项目经理、客户接口人、实施负责人
安装使用手册
分项项目经理、客户接口人、实施经理
在线帮助文档（分模块）
实施经理
培训资料包：
分项项目经理、客户接口人、实施经理
1.3.2控制基线变更
3.变更控制
正式变更：
1）项目组填写并提交《变更提案》；
2）并按照《配置管理过程》中的变更控制来处理；
3）配置人员应填写《变更与问题日志》；
4）给定《变更状态报告》发布频度；
非正式变更：
1）项目组借助配置管理工具提出变更请求；
2）并按照《软件配置管理过程》中的变更控制来处理；
3）配置人员应填写《产品发布报告》给定《产品发布报告》发布频度；
4.变更控制人员责任
角色
在配置变更过程中的职责
变更请求者
描述变更、阐明变更理由、描述变更带来的影响、把变更提案CCR提交给变更管理员（SCML）
变更评价者
评估变更带来的影响、验证变更原因、将评价结果在CCR中做出记录并提交给SCML。
变更管理员（SCML）
负责保存从变更被提交时刻起的CCR、监控变更进展情况并形成《变更状态报告》。
变更授权机构（CCB）
负责批准所控制配置项的变更。
5.非正式变更的控制
软件问题或者是错误（即产品功能与设计、需求不一致），或者是对配置控制下的元素的异常发现（即产品功能与预想的不符），需要更改基线库时，必须填写CCR表，按基线变更流程解决此类问题。
对于在开发过程中发生的变更，要及时通知相关功能的需求、设计文档编写人员，代码编制人员以及测试人员。
1.3.3配置状态信息
确定项目中配置状态记录的信息、报告和发布频度。
在项目的SCM过程中，需要记录配置管理行动，使得每个配置项的内容和状态都清晰明确，并可恢复配置项以前的版本。
可按照下表要求记录和发布配置状态信息：
文档
记录方法
发布频度
发布形式及对象
配置项状态报告
手工维护
配置项发生变化时（即变更后的配置项已做基线后）
发布书面的《配置项状态报告》，邮件通知干系人
基线发布报告
手工维护
基线发布后进行检查
发布书面的《基线发布报告》，邮件通知干系人
1.3.4基线审计计划
在每次主要的应用系统发布之前，必须进行基线审计，验证其完整性。
基线审计计划表：
序号
审计基线类别
审计人员
1
项目启动基线
SCM及相关组人员
2
项目计划基线
SCM及相关组人员
3
软件发布基线
SCM及相关组人员
4
项目实施基线
SCM及相关组人员
5
结项基线
SCM及相关组人员
1.3.5构造产品
应用系统的构造指将源代码进行编译，形成可执行文件，发布给客户的过程。
开发经理构建开发基线、发行人员构建发布基线。
此处需要项目经理安排技术经理和测试经理共同制定产品构建和发布指令。
1.3.6软件配置库的管理
规定项目人员对该配置库的访问权限。
具体用户组和可以执行的处理过程的对应关系。
1.3.7配置检查和审核
配置管理员按照以下软件配置审核列表对配置管理进行检查，审核完毕填写《配置审核管理报告》。
配置审核在每次基线评审提供，此外每次软件版本发布时也要进行配置审核。
配置审核列表
审计编号
审计日期或事件（视时间或事件驱动而定）
审计重点
1．物理审计（每周一次）
A01
SCM硬件环境（机器性能及网络环境）
SCM运行库安装的机器是否能正常运行，网络是否能保持通讯。
A02
SCM系统运行环境
安装SCM工具的操作系统能否保持正常的运行。
A03
SCM工具运行状态
SCM工具是否运行良好。
A04
SCM库的完整性
SCM库中的配置管理项是否是完备的。
A05
SCM库的有备份及可恢复性
SCM库是否定期的备份，备份的数据是否有效，能否在意外的情况下恢复到正常的运行环境中，保证有效。
A06
配置项清单、版本清单、系统版本引用正确性
配置项清单、版本清单、系统版本是否是一致的。
2．功能审计（每周一次）
B01
编译版本前所有相关变更是否完全处理
在编译某个版本时，此版本的相应的变更单所列的变更是否都得到完全的处理，并且是有效的。
B02
版本的修改是否经过正式的流程
所有修改的版本是否具有符合规定的变更处理。
B03
变更是否有影响范围分析
变更责任人是否对有影响的范围进行分析,并填写结果。
B04
版本的修改是否向受影响的组发出通知
如果修改影响到了其他的小组，被影响的小组是否得到相应的版本修改通知。
B05
检查变更是否影响需求基线，如果是，则需求变更的处理是否进入正式的需求变更流程
如果变更影响到了需求，那么需求变更是否得到了相应的处理。
B06
涉及的小组是否有统一讨论的记录
变更有关联的各个小组是否具有统一的讨论。
B07
检查变更是否涉及别的开发组，如果是，相应的变更是否完成
如果变更涉及其他开发组，则需要其他组的变更是否处理。
B08
根据流程的变更强制项是否填写完全
在变更流程中强制的选项是否都已经填写。
3．跟踪审计（每周一次）
C01
所有的产品功能能否追踪到相应的需求
某版本中的所有的功能能否追踪到相应的需求。
C02
是否所有的需求已经完成
某版本要求的需求是否已经全部完成。
4．集成审计（版本发布时）
D01
是否可根据版本配置单编译出对应的版本
使用某版本的版本配置单能否编译出相应的版本。
D02
编译出的版本与先前版本大小版本生成说明书是否一致
此恢复编译的版本与历史版本是否有一致性的。
1.3.8配置管理计划的修订
初始的配置管理计划在项目开始的初期进行制定，由于此时只能大致确定整个开发过程中的一些活动及其会产生的文档，在实际开发过程中，可能会与此有些差异，因此，配置管理计划也需要根据开发过程的实际情况，及时进行修订，使之能够有效地对本项目的配置管理活动进行指导。
在一般情况下，进行配置管理计划修订的时机选在到达各个阶段的里程碑时。
如果在一个阶段的实施过程中，配置管理计划不能适应实际过程的变更，则由配置管理员与项目管理人员一起根据实际情况修订配置管理计划。
配置管理计划的修订，需要通过项目的项目负责人、软件质量控制专员、配置管理员的共同审核，一致签字同意后方能作为此后阶段的配置管理计划。
2项目风险分析及对策
2.1风险分析
第2章
2.1
2.1.1用户与建设方关系
1、用户是主导
精准教育大数据平台是采用现代化信息手段所构建的云平台系统，为教学核心业务提供服务，这就决定了用户在信息化建设中的主导地位。
只有建设与开发完成是远远不够的，系统必须能在实际教学工作中发挥作用，才是真正的成功。
在这个过程中，用户方的各级领导、一线任课老师、电教或网管教师，都要积极参与云平台的前期建设与后期的培训工作，与建设方相互密切配合，并发挥主导作用。
同时要求建设方不仅具有先进的技术研发能力，还要有丰富的实践经验、对用户业务的透彻理解和全身心的投入。
2、用户方与建设方是互动关系
用户方领导、教师以及电教、网管教师是精准教育大数据平台系统的管理者和实际使用者。
是否能够在日常教育、教学工作中充分利用精准教育大数据平台系统，真正做到高效应用，是项目成败的关键。
各学校各级领导、一线任课老师应该根据教育教学的业务特点，提出业务需求，与建设方共同设计新型业务应用场景。
用户方与建设方是互相学习、互动前进的，建设方更要学习用户的实际教育业务，根据用户提出的实际教育、教学需求，实现云平台系统的不断优化。
2.1.2主要风险因素
成功的精准教育大数据平台项目建设需要全体项目人员和相关部门与人员的全力合作，而一个小的错误，就很可能会导致精准教育大数据平台系统的全面失败。
系统的开发、运行是有一定风险的。
6.影响项目实施进度和质量的风险
Ø设备到货的及时性；
Ø设备供货的数量、质量等；
Ø实施范围的不确定性、变化引起的实施进度控制；
Ø项目实施人员的技能程度和项目管理能力；
Ø用户方各部门及相关学校的支持和重视；
若以上风险不能有效避免，则本项目的实施可能会受到严重影响。
7.项目建设过程中的风险因素主要有
Ø用户方与建设方对精准教育大数据平台系统的应用的认识差异。
用户方与建设方之间的任务不同，因而在对教育公共云服务平台的认识和观念上可能会存在差距，这种差距有可能会对云平台系统的功能、实施方式、资源投入等方面产生不同的看法，进而影响项目的开展；
Ø由于国家政策、用户方学校体制改革等因素引起的业务工作环境变化，导致精准教育大数据平台系统整体或部分应用系统无法正常使用；
Ø用户方与建设方之间缺乏配合，没有周密的工作计划，开发工作随着进展的深入，举步维艰，导致工程不能按期结束；
Ø建设方能力不足，投入力量不够，项目方案缺乏可行性，项目人员变动频繁；
Øxxx市教育局精准教育大数据平台基于xxx市及各区县现有信息化基础进行，云平台系统如何与原有系统进行完美对接，相互整合的涉及的因素多，有较大的不确定性，将是工程建设中的重要隐患；
Øxxx市教育局精准教育大数据平台缺乏有效的应用推进措施，导致云平台系统无法被广泛接受。
8.资产管理风险
Ø精准教育大数据平台项目涉及xxx市及下辖多个区县，覆盖小学、初中、高中全学段，各校情况各异，网络及终端等信息化设备到校后交接程序及交接人员不确定；
Ø信息化设备到指定地点的存放和管理；
Ø资产管理数据的管理和备份；
Ø对于信息化设备在使用过程中发生丢失、损毁或损坏的情况能否及时进行记录，设备返修过程中的状态能否及时跟踪；
Ø发生设备临时更换的情况，能否有充足的备品备件支持，并做好及时登记和管理。
9.后期运行维护过程中的风险
Ø网络问题导致精准教育大数据平台系统不可用；
Ø各层级服务器宕机导致云平台系统不可用；
Øxxx市地域广阔，由于技术支持人员不能及时到达故障发生学校现场，导致云平台系统不可用或造成教学事故；
Ø遇有重大事件或突发性事件时，由于考虑不周，致使云平台系统不可用；
2.2风险预案
2.2
2.3
2.3.1项目实施方案切实可行
xxx市教育局精准教育大数据平台建设要想取得成功，不仅依赖于先进的设计方案，适当的技术路线，更要有周密的建设计划。
以下是项目建设成功的基本条件
Ø选择实力雄厚，信誉卓著的建设供应商和设备供应商，确保云平台网络设施、基础环境和各级应用系统稳定高效，确保所供应的设备数量、质量供货周期等符合设计要求；
Ø用户方高层领导对项目的高度重视和支持；
Ø提供合适的人员加入到项目建设中，并按时按质完成分派的任务；
Ø明确的实施范围、项目成员角色和职责的界定；
Ø合理的项目建设和管理计划；
Ø合理的运作模式。
2.3.2系统建设方案成熟可靠
系统建设阶段的主要任务是要在规定的时间内，完成满足用户方需求、达到设计目标的开发工作。
为了保证这一阶段的工作的成功，用户方与建设方的配合最为关键。
10.建立完善的系统建设组织机构
建设方应建立完善的项目组织结构，涉及云平台系统设计、开发、测试、集成、实施、培训、技术服务等各个环节，人员包括项目负责人、系统设计工程师、系统开发工程师、系统测试工程师、系统集成工程师、项目实施工程师、系统网络工程师、质量保证工程师、美工设计师、培训教师和客户服务人员等。
11.建立畅通的沟通机制
用户方和建设方之间要建立畅通的沟通机制，包括上层沟通，用户方主管领导与建设方领导的联络，对一些重大事情进行决策；中层沟通，用户方工作小组与建设方项目负责人的沟通；基层沟通，用户方业务人员与建设方项目组人员的沟通。
保证各种信息能够快速有效的传递到相关人员，以便及时采取措施。
沟通方式如：
周汇报、例会，阶段报告，座谈，介绍会等，以及确定的与关键人员的直接联系。
阶段审核。
在项目建设过程中设立若干控制点，由项目组、工作小组、相关部门人员集体对项目进展情况进行检查，发现问题，及早处理。
项目建设过程严格按照ISO9000质量体系、CMMI体系要求执行。
12.系统建设注重技术先进性与成熟性的结合
在系统建设过程中，在追求先进技术的同时，首先要考虑的应该是成熟的、稳定的、可掌握的技术，否则将会加大云平台项目建设的不确定性；
要保证xxx市教育局精准教育大数据平台要比现有系统更加具有易用性和实用性，能够真正解决实际问题，这样才能调动使用者的积极性和主动性；
2.3.3资产管理方案合理细致
Ø优化信息化设备的交接程序，指定专人负责资产移交、登记等事宜；
Ø做好与用户方的提前沟通，选定信息设备存放、安装地点和存放、安装的方式；
Ø运用资产管理应用系统等信息化工具，定期更新、备份基础的资产管理数据；
Ø对于信息化设备在使用过程中发生损毁或损坏的情况及时进行记录，信息化设备返修过程中的状态及时跟踪；有详细、完备的信息化设备返修流程控制；
Ø发生信息化设备临时更换的情况，做到充足的备品备件支持，并做好及时登记和管理。
2.3.4技术支持方案全面到位
Ø建立项目快速响应中心，与用户方运维服务热线实现对接，如果遇到网络中断导致云平台系统不可用事宜，实时与用户方网络运维沟通，及时修复故障，保障系统迅速恢复正常使用；
Ø建立自动化运维体系，实时监控各层级信息化设备运行状态，做到提前预警，防止设备故障导致云平台系统整体或部分不可用；
Ø合理地按地域范围划分运维分区，各运维分区有独立的项目运维团队进行技术支持保障，使运维人员能够最快速到达故障发生现场；
Ø按照运维分区建立完备的备件库，保障云平台对常态化教学的使用要求；
升级会员 