项目工作说明书.docx
- 文档编号:14455634
- 上传时间:2023-06-23
- 格式:DOCX
- 页数:20
- 大小:85.98KB
项目工作说明书.docx
《项目工作说明书.docx》由会员分享,可在线阅读,更多相关《项目工作说明书.docx(20页珍藏版)》请在冰点文库上搜索。
项目工作说明书
密级:
★高★
工程工作说明书
XXXXXX
XXXXX
2021年8月11日
文档控制
更改记录
日期
作者
版本
更改参考
2015-7-30
XXX
创立
审核
姓名
职位
签字
分发
拷贝号
姓名
区域
文档目的
本文档资料的目的是用来确定适合本工程的政策,标准及程序。
文档资料也说明了何时,何人如何使用这些政策,标准及程序。
如未有特殊申明,本文档资料的内容适合于工程组中的所有人。
关键联系信息
姓名
职务/职位
工程角色
邮箱
1工程工作说明书介绍
XX信息化是促进XX改革和开展、缩小城乡XX差距、实现XX公平和XX现代化的重要途径,是办好让人民满意的XX,构建社会主义和谐社会的必然选择。
为了推动我国XX开展,中央制定了?
国家中长期XX改革和开展规划纲要?
,明确提出要强化信息技术应用,提高信息技术水平,构建国家XX管理信息系统,加快学校管理信息化进程,促进学校管理标准化、标准化。
在规划纲要的根底上,XX部针对XX信息化,进一步制订了?
XX信息化十年开展规划?
,明确提出要运用云计算、顶层设计等先进技术和理念进行区域XX公共效劳平台的建设,指出XX公共效劳平台的核心目标和核心工程是大力推进“三通两平台〞建设,即宽带网络校校通、优质资源班班通、网络学习空间人人通,建设XX资源公共效劳平台、XX管理公共效劳平台。
通过信息技术与XX全面深度融合、优质数字XX资源共建共享促进XX教学和管理创新,助力破解XX改革和开展的难点问题,促进XX公平、提高XX质量、建设学习型社会;通过建设信息化公共支撑环境、增强队伍能力、创新体制机制,解决XX信息化开展的重点问题,实现XX信息化可持续开展。
随着我国XX信息化的快速开展,分散独立的建设模式已经不能解决和满足XX信息化开展的需求,为改变传统的XX信息化建设模式,形成统一完善的XX管理体制,XX部提出两级建设五级应用的建设思想,两级建设是指XX部和各省XX厅建设网络中心,对全省乃至全国的XX信息进行保存,五级应用是指由XX部统一建设全国的信息化管理系统,形成从学校到区XX局到市XX局到省XX厅到XX部的基于业务单线条数据采集,到达一数一源。
从XX部开始形成一个大的顶层云平台对全国32个省级数据进行统一管理,各省又建设自己的省级云平台对各地市州进行统一管理,但是目前国家的云平台规划只到了部、省级,而区县级同样需要这样一个云平台对自己区域内的学校进行全方位的精细化管理,即使有了国家的管理系统从学校直接采集数据,但也只能是为了采集数据,对学校内部的精细化管理及区域内部的全面管理起不到太大作用,且无法实现区域内的横向的贯穿。
所以作为区域XX局非常有必要建立一个属于自己区域内的云平台,形成一个集管理精细化与资源整合化的个性化私有云平台。
“XXXXX信息化平台建设工程〞是XX市XXX落实XX规划纲要精神,响应XXXXX信息化高速开展战略规划,结合XXX信息化建设的实际需求和特点,建设具有XXX特点的XX信息化云平台。
1.2工程目标
1.总体应用目标
XXXXX局内部信息化建设目标:
Ø建立统一、交互的XXXXX共享中心数据库;
Ø整合根底数据,消除信息孤岛;
Ø建立数据分析和领导综合数据查询系统,为决策提供依据。
Ø建立完善的XXXXX云公共效劳门户平台,实现所有应用系统统一访问和单点登录,实现应用系统间的协同工作
Ø建立全方位顶层监控与管理云效劳,建立有效管理机制和鼓励机制,促进学校管理水平,提升教师专业开展,实现XX水平质的飞跃。
Ø统一全区教学资源,实现优质教学资源共建共享;
Ø利用移动智能技术,为XX局领导和工作人员提供方便的全局监控和移动办公效劳。
中小学校信息化建设的目标:
Ø为各学校提供网络化、智能化、精细化的管理平台,集合优秀学校的管理机制和方法,促进学校管理水平均衡开展;
Ø为教师提供高效便捷的教学环境,相互观摩、借鉴、交流学习的网络平台,促进教师信息化素养、教研能力、教学专业水平得到全方位的促进和提升。
Ø建立面向学校、老师、家长、学生的XX效劳体系,通过基于角色的自助效劳,加强学生学习交流、师生互动、家校互动,提高学生自主学习和家校协同XX。
Ø加大信息技术与终端根底设施的深度融合,切实有效的利用根底设施进行教学效劳工作。
Ø利用移动智能技术,提供随时随地的移动办公和教学效劳。
Ø实现优质教学资源共建共享,包含微课、名师资源,提高学校网上自主学习能力,提高学习效率。
建设清单:
序号
工程名称
数量
单位
招标范围
1
2
3
4
5
1.3工程启动时间
经双方共同协商确认工程正式启动时间为:
2015年xx月xx日
2实施策略
实施策略
∙整体规划,分步实施;
∙注重数据准备和测试贯穿于工程每个阶段;
实施策略的考虑
为实现上述总体目标,引进先进的系统只是成功迈出的第一步,我们还必须结合企业目前信息管理现状和现实需求,通过成功的实施才能充分发挥系统功能,提升企业价值。
针对目前企业内部信息系统繁杂且不统一的特点,我们建议通过以下几个方面来高效率、高质量、低风险地实现总体目标。
∙切实可行的实施对策:
Ø目标明确,分步实施:
先试点,后推广,先实现根本需求,将来再实现扩展需求;
Ø试点阶段重投入,积累经验并确保效益;
Ø通过知识转移,合作推广;
Ø采用成熟标准的实施方法和工具;
∙从业务的角度考虑,尽早解决核心业务功能实现,确保整个业务流程的畅通。
∙确保所有可能导致时间延长或本钱上升的有关工程范围的问题由工程领导会议解决,以此来对建议的改变保持强有力的控制。
∙建立将知识转移给最终用户的正式渠道,即重点非只是安装一个软件,而是实施解决客户的实际业务需求。
∙在工程上线之前,依靠系统的结果来获得最终用户对系统的接受。
3工程范围
3.1范围
整体而言,本工程的功能工作范围包括四个方面:
数据管理、查询管理、权限管理、数据采集管理;
功能范围
功能模块
∙硬件
∙网络
∙根底平台
∙电子政务
∙管理云平台
3.2实体范围
XX市XXXXX局
XX市XXX所管辖的74所学校
4工程组织结构
4.1工程组织结构图
系统工程组由工程领导小组、工程经理、实施组构成。
该工程是由工程领导小组发起的,同时还是该工程的主要决策和策略的制订者。
而工程的所有事务都要由工程组进行协调和管理,工程组将由康赛专职工程管理人员、技术人员和系统设计专家等组成;此外,工程组还将包括来自康赛的需求参谋和测试工程师。
领导小组
领导小组
工程经理
工程经理
工程实施核心小组
实施组
核心业务组。
数据管理组。
系统管理组
需求参谋组
设计参谋组
XXXXXXXXX
XXXX
开发技术组
测试组
现场实施组
商务工程经理
[图:
工程组织机构图]
工程领导小组:
工程核心小组:
三、成员职责
工程领导:
定期对工程的工作质量进行监督,随时检查工程的相关文档,对提交的所有文档进行质量监督。
与客户工程经理及企业高层的阶段性沟通与协调。
对工程实施总体方案提出建议,并定期接受工程经理对于工程进程汇报。
工程经理:
作为工程的总负责人,负责工程的全面实施督导和工程进度过程控制。
主要包括:
整个工程实施方案制定、工程进度的控制、客户沟通、工程验收重点是文档收集和整理,其中包括:
业务流程文档的整理,实施各阶段的文档等。
商务工程经理:
作为康赛方的商务负责人,负责整个工程的商务谈判、商务进程等工作,向工程领导汇报工作。
实施参谋:
协助工程经理共同制定需求调研方案,负责客户需求调研和系统功能设计方案,并负责产品在客户现场环境中的实现,直接向工程经理汇报工作。
开发工程师:
协助工程经理共同制定工程开发方案,负责按照开发方案进行工程的开发工作,服从工程经理的安排。
〔注:
美工归类到开发工程师。
〕
测试工程师:
对研发出的产品质量负责,向工程经理汇报工作,主要职责包含:
1.制作测试用例
2.初始化数据
3.功能测试
4.系统测试
5.性能测试
5工程方案
本工程将遵循康赛在软件系统实施领域所总结出的系统实施方法论。
本工程将按照这一实施方法论来进行,将完成系统功能的全部设计工作。
5.2时间表
根据上述实施方法论,本工程的具体实施方案如下,工程工作的开展将按照此方案执行。
任务名称
工期
开始时间
完成时间
XX市XXXXX工程(一期〕
51个工作日
2015年7月30日
2015年10月19日
工程启动
4个工作日
2015年7月30日
2015年8月4日
成立工程组
1个工作日
2015年7月30日
2015年7月30日
工程综合管理
2个工作日
2015年7月31日
2015年8月3日
工程启动会
1个工作日
2015年8月4日
2015年8月4日
工程实施
37个工作日
2015年7月30日
2015年9月22日
硬件局部
13个工作日
2015年7月30日
2015年8月17日
网络局部
24个工作日
2015年8月18日
2015年9月22日
软件局部
33个工作日
2015年8月5日
2015年9月22日
需求调研
6个工作日
2015年8月5日
2015年8月12日
电子政务
1个工作日
2015年8月5日
2015年8月5日
XX管理根底平台
1个工作日
2015年8月6日
2015年8月6日
系统整合
4个工作日
2015年8月7日
2015年8月12日
调研报告
2个工作日
2015年8月13日
2015年8月14日
实施方案设计
7个工作日
2015年8月17日
2015年8月25日
系统实现
18个工作日
2015年8月26日
2015年9月22日
工程收尾
14个工作日
2015年9月23日
2015年10月19日
初步验收
3个工作日
2015年9月23日
2015年9月25日
试运行
10个工作日
2015年9月28日
2015年10月16日
最终验收
1个工作日
2015年10月19日
2015年10月19日
具体的工程方案内容,包括工程阶段划分、工程任务清单、每项任务起始截止日期、责任人、以及各项任务所需要完成的文档,请参见:
?
工程总体方案?
。
5.3里程碑
里程碑是用于标志工程组完成的事件或主要成就的时间点,同时还是可以标记工程进展的时间点。
工程主要里程碑和相关时间表如下所示:
工程阶段
里程碑
方案日期
硬件局部
开箱验收
2015-08-17
系统设计
设计报告
2015-08-25
系统实现
初验报告
2015-09-22
最终验收
验收报告
2015-10-19
这些里程碑出现于工程方案中,里程碑插入在作为工程方案中重要事件的工作、步骤和任务完成的时间点上,有助于对工程进展进行监控。
里程碑的状态在每周的工程管理报告中加以监控,该报告要提交给工程领导。
5.4工程方案执行和报告
工程经理对监控工程进展负主要责任。
工程方案是用于通报工程进展和当前状态的关键性文件。
工程方案包括工程阶段、任务、任务期限、资源、任务的方案开始和结束日期、里程碑、责任人、和可交付成果等。
工程方案将由MSProject进行维护并且要反响出工程方法论方案阶段。
只有在两种情况下,才能对整个基准方案进行重新设计。
一是只要出现任何会从根本上影响工程进度的范围变化,就应该更新整个基准方案。
同样,当进度或预算偏差非常严重的时候,就需要重新制定基准方案以使业绩报告重新变得有意义。
工程方案执行和报告应按照流程进行,具体来说如下:
每个工程组成员将负责按照工程方案更新实际进展情况并估算自己分配到的任务离完成还需多少时间,这些工作是每周工程报告例会的一局部。
工程管理组每个星期五会晤一次,参照工程方案审查工程进展情况。
审查工作以考察拖延情况为根底,集中精力查找现存的或潜在的任务拖延,评估对工程造成的影响,并对要采取的用于减轻影响的行动方案达成一致意见。
对于那些存在拖延可能的任务〔例如:
预计完成时间晚于方案时间〕工程经理加以突出表示。
该任务的负责人应制定出一个应对潜在拖延的行动方案以减小对其他工程工作造成的影响。
工程组组长要在每周的状态报告问题局部中注明可能发生的任务拖延,其内容包括问题的简短说明、防止拖延的行动方案简短说明或者是新任务日期,日期上应注明对其他任务造成的影响。
6工程文档管理
6.1工程文档管理的重要性
实施系统是一项复杂系统的工作,为了保证工程的最终成功,必须在工程的每一个阶段都进行严格的控制。
而工程的文档是工程工作过程及结果的反映,是工程控制的依据,同时也是“知识转移〞的关键载体,因此必须对工程整个过程都要充分文档资料化。
本文件规定了工程过程中的所需要编写的文档,主要包括工程管理文档、工程技术文档及工程功能文档等。
此外,本文件还对文档编制的具体要求进行了说明,工程组成员在制作这些文档时都要按照这些要求进行,而且都必须经过相应负责人确实认签字。
6.2工程文档体系
在工程实施的不同阶段都需要编写相应文件,下表说明了在工程哪些阶段需要哪些文档,以及相应的文件格式、编码规那么及需要完成日期要求等。
文档名称
工程阶段
文件格式
签字人
工程实施及工作方案
整个阶段
doc
双方工程经理
调研报告
需求阶段
doc
双方工程经理
数据准备表
需求阶段
doc
双方工程经理
实施方案
实现阶段
doc
双方工程经理
用户培训方案
上线阶段
doc
双方工程经理
用户使用手册
上线阶段
doc
双方工程经理
用户培训教材
上线阶段
doc
双方工程经理
初验报告
交付阶段
doc
双方工程经理
试运行报告
交付阶段
doc
双方工程经理
验收报告
交付阶段
doc
双方工程经理
下面对上表列出报告的主要内容和编写目的进行说明:
▪工程实施及工作方案:
在工程开始时需对整体的时间方案、关键检查点、职责分工等进行明确。
此外,在具体实施过程中,还要有具体的工作方案,一般是按周制订并且检查。
▪调研报告:
是系统调研阶段的主要工作成果。
它总结所有当前的业务流程,以及所有当前业务流程和当前系统的输入〔表单等〕和输出〔报告等〕。
它还应包括,系统功能检查表,将系统功能在高层次上与当前业务流程进行对应,并找出和当前流程/系统的差异。
同时该报告还应包括主要的系统接口需求和数据迁移的战略。
▪数据准备表:
根据数据清洗的策略进行制定,包括所需要清洗数据的每一数据项,以及对其的格式要求。
应根据该准备表进行原始数据的清理和准备。
▪实施报告:
在对系统进行设计的根底上,总结需要对当前业务流程进行哪些修改。
在确定的流程的根底上应当总结对系统进行何种配置来满足流程的要求。
对于要进行的系统的客户化开发包括报告,需要由功能人员制定从功能的角度对开发应到达的效果提出的要求。
▪用户培训方案:
培训开始前制订培训方案,对培训的过程、课程和参加人员进行安排。
▪用户使用手册:
用户对系统进行操作的指导和备查手册。
它应包括确定的天狮的所有业务流程,并按照业务流程的方式来组织系统的功能。
新用户在接受过系统使用培训后,参照该手册和业务流程的政策规定应该即可以根本完成系统的操作。
该手册也将作为最终用户系统培训所使用的教材的一局部。
▪用户培训教材:
对最终用户培训所使用的教材,与用户手册结合对最终用户进行培训。
▪初验报告:
对系统上线进行初步验收的报告,核对系统所提供的产品和目标的完整性和质量进行验收。
。
▪试运行报告:
总结系统上线至今的状况,分析过去发生的主要问题和解决方案。
对系统使用的进一步提高和改良提出相应的意见。
全部工程文档都只使用中文编写。
对于文档的签字,原那么上由工程经理完成,对于设计报告等这些关键的工程阶段总结报告,需要在工程会议上进行汇报讨论,并最终由相关领导签字确认。
同时,由于本工程的日程安排紧密,为了保证工程能够按照方案进行并最终能够在方案日期上线,因此工程文件的签字工作应该在文件递交3个工作日内完成。
如果超过3个工作日仍然没有签字,那么视同已经签字确认,并且工程组的工作将按照这些文件进行。
7工程沟通管理
7.1工程决策流程
下面介绍的决策和上报流程与日常挑战和决策有关。
某些挑战可能会造成工程范围、资源或时间表的变更并需要利用变更管理中描述的变更控制流程进行处理。
对于那些不会对工程范围、资源或时间表造成明显影响的决策,工程组有权自行决定。
决策的第一级上报领导为工程经理。
第二级上报领导是工程领导。
在向更上一级报告之前,在某一级领导处不得上报两次以上。
7.2工程例会
工程沟通方案用于为工程实施和培训说明沟通的目标、范围、流程和方案,确保工程领导、参谋和工作组能接收到及时准确的信息。
工程沟通的目标受众是:
▪工程领导
▪工程经理
▪核心工程组
▪最终用户
周例会:
每周一14:
00-15:
00工程组全部成员都要会晤一次。
会议由工程经理主持,对过去一周的工作进行总结,讨论工程工作中存在的问题和解决方案,并且对下周的工作进行安排。
工程组的特别会议将根据情况安排日期。
月例会:
每月最后一个工作日14:
00-15:
00工程召开一次月度会议,参加者包括工程领导,工程经理,以及小组负责人。
会上以每周提交一次的工程周报为主要数据根底,工程经理对当月工程进度及完成情况进行汇报总结,同时宣布下个月的工作目标。
8工程风险管理
在实施应用过程中,不可防止的会存在一些问题和风险,这就需要我们双方本着务实的原那么,及时总结和认真看待,正确协调和解决。
本次工程实施可能面对风险及建议的应对策略。
8.1实施周期延期的风险
1、统初始化过程中新老数据整理可能耗时较长;
应对方法:
企业在准备初试化数据之前就建立针对该问题的明确的解决方案。
2、需求变动频繁
应对方法:
对需求变更严格按需求变更流程处理。
8.2实施范围风险
1、在某一实施分步内的实施主体范围过多,可能会导致工程延期;
应对方法:
按照实施方案分步实施。
2、过分关注细节,导致工程消耗在无尽的讨论开会
应对方法:
工程高层应正确引导,以核心需求实施目标为重点,先上线,后改良
8.3人员的风险
1、中高层领导安排其他事务给实施人员,导致实施进度无法按期完成;
应对方法:
专人专用,如需处理其他事务,必须经工程实施领导小组成员批准。
9工程变更管理
变更控制是通过有序地管理变更来稳定开发过程、减少工程风险。
本程序的制定是为了检查所有的变更请求,决定哪些需要实施、哪些需要推延、哪些需要否决。
在得到对方的认可后,进度和本钱将相应地做出调整。
一个有效的变更控制程序对于防止工程延期和超支是必要的。
9.1提出变更
提出变更需首先填写“变更申请表〞〔REQUESTFORCHANGE,以下简称RFC〕。
RFC需由申请方工程经理交给对方工程经理。
接收方工程经理将就RFC的技术可靠性以及对整个工程的影响做出评估。
经接收方工程经理同意的RFC将提交工程领导小组批准备案,未被批准的RFC将退还给申请方工程经理。
任何双方工程经理不能解决的争议将提交工程领导小组审议。
变更申请表
变更申请
(系统名称)变更申请序号#:
申请人:
日期:
申请变更内容:
申请变更原因:
变更类别(标明一个)
授权人签字:
_______________________日期:
______________
9.2接收方的响应
Ø接收方工程经理将在接到RFC的三个工作日内确认收讫,并说明分析RFC,做出相应的工程变更建议书〔ENGINEERINGCHANGEPROPOSAL,以下简称ECP〕所需的时间。
如果康赛是接收方,康赛可对RFC分析报告以及ECP进行收费并以书面形式告知客户收费标准,康赛将于客户同意收费标准后三十天或双方协定的时间内,对RFC进行分析研究并做相应的ECP。
ØECP将就RFC中所提出的变更对整个工程的影响做出以下几方面的说明
Ø根本变更-文件的增改和删除
Ø软件设计-程序编码的增加、修改和删除
Ø测试工程-测试方案、测试和重新测试的修改
Ø系统性能-确认修改工程对系统性能的影响以及增加或改装其它机器是否必要
Ø培训-培训方案、课程准备及教材
Ø其他材料-列出所有其它材料
Ø人员需求-确认增加其他人员的必要性
Ø进度-工程进展情况、交付件的进展速度和协议的终止日期
Ø可能的费用
9.3申请方的认可
Ø申请方工程经理需对ECP进行书面确认。
任何双方工程经理不能解决的争议将提交工程领导小组审议。
Ø在申请方工程经理确认后,如果修改涉及工程合同或费用,还需由工程领导小组批准。
Ø批准后的ECP将以“工程变更建议书〞的形式列为本工作说明书的协议,同时取代前期的任何相冲突的协议。
9.4变更实施
Ø双方将根据经确认批准的ECP重新调整工程方案,并进行任务分配。
Ø双方将根据新的工程方案履行各自的责任。
9.5变更程序流程
Ø客户或康赛一方以书面形式提出RFC;
Ø将RFC提交对方(或工程领导小组)作技术可行性评定;
Ø康赛以书面形式给出ECP的准备时间和所需费用;
Ø工程经理委派评审小组讨论康赛提出要求是否批准RFC;
Ø康赛做出ECP并确认所需费用和进度;
Ø双方(或工程领导小组)讨论ECP并提出实施建议;
Ø申请方对ECP提出认可;
Ø工程领导小组批准对合同进行修改(如果需要的话);
Ø实施ECP。
10知识转移
在工程进行中,知识的转移给贵公司用户是每个参谋的目标。
知识转移主要分为以下几个层次:
∙从工程经理至贵公司工程管理层
∙从实施参谋至贵公司关键用户、IT部门人员和内部参谋
∙贵公司关键用户和内部参谋至其它贵公司员工
在工程实施过程中,将主要通过以下方式进行知识转移:
•工程小组培训
通过该培训,贵公司工程小组成员及来自业务部门的关键用户将对系统相关模块的概念和流程有初步的认识,从而为后续的业务流程设计打下根底。
12验收标准
验收方式
本工程采用分阶段提交成果和验收的方法。
在得到本阶段成果确实认以后,再开始下一阶段的实施工作。
以保证工程始终在实施双方意见一致的前提下进行。
工程阶段验收将根据双方确认的本阶段实施目标,工作方案和提交的阶段工作完成报告作出结论。
在康赛方书面提出验收申请之日起,甲方工程经理〔或其授权人〕应在3个工作日内,书面签署确认报告或向康赛工程组提出优化的建议。
验收标准
第一期:
验收工程
是否合格
备注
13文件签署
该章程已经贵公司和公司审阅并予以批准。
签字确认
-----------------------------
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 工作 说明书