信息系统开发项目管理指导书Word下载.docx
- 文档编号:8692001
- 上传时间:2023-05-12
- 格式:DOCX
- 页数:34
- 大小:33.08KB
信息系统开发项目管理指导书Word下载.docx
《信息系统开发项目管理指导书Word下载.docx》由会员分享,可在线阅读,更多相关《信息系统开发项目管理指导书Word下载.docx(34页珍藏版)》请在冰点文库上搜索。
系统转换时必须详细记录原系统中的重要参数、设置等系统信息,并填写试运行报告相关容。
4、系统转换和数据迁移完成后,正式启动试运行。
在试运行过程中,项目组应把系统运行情况(系统资源使用,反应速度等)记录到试运行报告中。
必要时,项目组应根据系统运行情况对应用系统进行优化。
5、试运行达到试运行计划规定的终止条件时,开发商编写《试运行报告》(式样见附件10)。
此报告应由开发商和甲方单位签字确认,试运行结束。
2.6系统验收与正式上线
1、系统验收主要用户单位及开发商联合组成独立系统验收小组,由验收小组共同商定验收的标准和方法。
验收小组从功能需求及技术需求层面对系统进行综合评估,系统验收容包括但不限于移交给甲方的系统测试报告、系统安装文档、配置文档、源代码、操作手册、维护手册、系统应急预案、系统“回退”计划等。
2、验收小组应根据验收情况整理形成《系统验收报告》(式样见附件11),验收报告必须甲乙双方签字,并提交甲方作为付款依据。
3、系统验收合格且问题整改完成并经甲乙双方主要领导同意后系统转入正式上线运行。
3售后服务及保密要求
开发商应该保证系统技术支持人员队伍的稳定,明确售后服务容与责任,按照合同要求安排维护人员对系统进行技术支持。
系统需求变更或调整,记录变更原因和软件及源代码的版本控制,按照软件变更要求对系统进行维护。
为了保护甲乙双方的商业、技术秘密等权益,开发商与甲方、开发商与其相关员工必须签订保密协议。
附件1:
项目执行计划
文件状态:
[√]草稿
[]正式发布
[]正在修改
文件标识:
当前版本:
作者:
完成日期:
版本历史
版本/状态
作者
参与者
起止日期
备注
1文档介绍
1.1文档目的
1.2文档围
1.3参考文献
提示:
列出本文档的所有参考文献(可以是非正式出版物),格式如下:
[标识符]作者,文献名称,出版单位(或归属单位),日期
例如:
[AAA]作者,《立项建议书》,机构名称,日期
1.5术语与缩写解释
缩写、术语
解释
2项目介绍
2.1项目围
(1)用简练的语言说明本项目“是什么”,“说明用途”。
(2)说明本项目“应当包含的容”和“不包含的容”。
2.2项目目标
给出“清晰的”、“可实现”、“可验证”的目标。
2.3客户与最终用户介绍
请说明本项目的客户、用户及其相关责任人是谁,描述最终用户的特征。
2.4约束
(1)请说明在项目开发过程中应当遵循的标准或规
(2)请说明相关项目可能对本项目造成的影响。
(3)说明一些假设和依赖。
3项目过程定义
3.1软件生命周期模型
简要描述、绘制本项目的软件生命周期模型。
3.2项目规
描述项目需遵循的规,例如:
编码规。
此处可以表现为编码规的。
3.3方法与工具
说明在过程中将采用的方法与工具。
例如采用RationalRose进行面向对象分析与设计,采用VisualSourceSafe进行配置管理,采用MicrosoftOffice制作文档。
方法与工具
用途
VisualSourceSafe
配置管理
…
4里程碑计划
序号
里程碑名称
开始日期
结束日期
工作成果
5资源计划
5.1人力资源计划
制定本项目的角色职责表,并为已知的项目成员分配角色(一个人可以兼多个角色)。
角色
职责
人员姓名
工作说明
高层领导
项目经理
需求分析员
系统设计员
程序员
测试员
5.2软硬件资源计划
分析项目开发、测试、运行所需的软硬件资源和关键计算机资源(会影响软件产品的性能的CPU、存、带宽等容),主要容包括:
●资源级别(分为“关键”、“普通”两种)
●详细配置
●获取方式(如“已经存在”、“可以借用”或“需要购买”等)与获取时间
●使用说明(如“谁”在“什么”时候使用)
软硬件资源名称
级别
详细配置
获取方式与时间
使用说明
关键
普通
6文档交付列表
交付文档名称
交付日期
7风险管理计划
以下是各个列标题的解释。
约定在项目中的风险管理方案,例如:
风险识别频度、风险跟踪频度等。
风险级别:
确定风险的严重性、可能性、风险系数
风险描述:
缓解方案或者应急计划。
风险编号
风险级别
风险描述
缓解方案
应急计划
严重性
(1-5)
可能性
(%)
风险系数
(严重性*可能性)
8沟通计划
甲方代表
乙方代表
沟通方式
沟通频率/时间
期望结果
9附件
●项目进度计划
⏹进度表
制定项目开发的进度表(建议给出项目里程碑计划)。
编号
预计结束时间
需求调研完成
项目计划完成
需求分析完成
系统设计完成
.....
开发完成
集成测试完成
系统测试完成
用户验收测试完成
试运行结束
项目验收
附件2:
业务需求说明书
1概述
1.1业务调研人员
【可选】
职能部门
姓名
主管
联系
1.2业务围
此处描写总体业务的概要分类。
1.3业务目标
从甲方高层或商务利益的角度提出本业务系统的期望目标,以及评价标准。
1.4相关文档
说明:
列出本文档的所有参考文献(可以是非正式出版物),包括现有规、标准、批文、引用到的文件、资料等。
1.5业务词汇表
列出本文档的所引用的专属领域词汇、术语等,以便于业务需求的提供者和接收者是建立在一致的业务理解基础之上的。
2组织结构及业务
2.1业务相关组织结构、人员组织结构
如果用户岗位设置复杂可分别设置,业务组织结构和人员组织结构
2.2组织机构描述
2.3角色职责
将业务涉及的具体人员进行一定程度的分类和抽象,描述该抽象角色的操作职责。
2.4管理综述
主要描述该业务的管理特点和管理模式。
2.5现有业务流程清单
现有业务流程需要考虑,很多新的业务是在已有业务流程基础上进行重组的。
流程编号
流程名称
责任部门
辅助部门
3业务流程及业务处理描述
针对每一项具体的目标业务,描述具体的业务流程,以及相关业务的具体描述。
3.1具体业务流程(系统名称+编号)
对于具体业务流程的命名有规,对具体流程进行编号,便于形成需求矩阵,同时形成需求的管理和跟踪。
3.1.1业务流程
3.1.2业务描述
描述具体的业务流程。
3.1.3相关业务对象
业务对象:
业务流程中涉及的单据、报表等。
业务对象
使用部门
对应电子档案编号
3.1.4业务规则及关键算法
描述业务环节关键算法体系。
4假定和约束
列出进行本软件开发工作的假定和约束,例如开发期限等。
4.1运行环境约束
4.2设计约束
开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等。
4.3产品应当遵循的标准或规
阐述本产品应当遵循什么标准、规或业务规则,违反标准、规或业务规则的产品通常不太可能被接受。
5其他
5.1目前核心问题和困难
5.2业务对项目实施的需求和期望
5.3其他未尽事宜
附件3:
系统需求规格说明书
1引言
1.1目的
规定系统的边界和目标,描述系统的功能性需求和非功能性需求。
1.2读者对象及阅读建议
指明本文档面向的读者群,及相应的阅读意见。
1.3文档围
对本文的围做阐述,本文档改动时,受到影响的围,例如,本文引用到的用例模型,系统原型,系统测试用例等文档。
1.4参考文档
列出本文档的所有参考文献(可以是非正式出版物),包括计划任务书、合同、批文、引用到的文件、资料及软件开发标准等。
列出本文件中用到的专门术语的定义和缩写词的原词组,并给予解释,以便于所有读者达成共识。
2综合描述
2.1系统背景
介绍系统的预期效果、历史原因。
2.2问题说明
提供一段说明,总结此项目需要解决的问题。
可以采用以下格式:
问题是
[对问题进行说明]
影响
[问题影响的干系人]
问题的后果
[该问题会导致什么后果]
成功的解决方案
[应列出成功解决方案的一些主要优点]
2.3系统围
阐述本项目“适用的业务领域”和“不适用的业务领域”,本产品“应当包含的容”和“不包含的容”。
说清楚系统围的好处是:
(1)有助于判断什么是需求,什么不是需求;
(2)可以将开发精力集中在产品围之;
(3)有助于控制需求的变更。
●完整而准确的定义本产品的干系人;
●明确本产品所影响到的部门和业务;
●用图表或者文字描述产品的围,概要的定义产品的功能。
2.4干系人与用户说明
2.4.1用户环境
详细说明目标用户的工作环境。
以下是几项建议:
该任务由多少人来完成?
是否总在变化?
一个任务周期需要多长时间?
执行每项活动要用多长时间?
是否有特殊的环境约束:
移动、户外、乘机旅行等?
目前使用的是哪些系统平台?
以后会使用哪些平台?
还在使用哪些应用程序?
您的应用程序是否需要和这些应用程序集成?
在此处可以从业务模型中摘录一些容来概述所涉及的任务和角色等等。
2.4.2干系人简档
通过在下表中填写各干系人的相关信息来说明系统中的各个干系人,详尽的简档应包括各种干系人在以下方面的信息:
代表
[谁是此产品的干系人代表?
(如在他处已作记录,则此处为可选。
)此处只需填写姓名。
]
说明
[对干系人类型的简要说明。
类型
[介绍干系人的技能特长、技术背景和熟练程度(即权威用户、业务用户、专家用户、初级用户等)]
[列出干系人对所开发的系统负有的关键职责,即他们作为干系人的利益。
使用频率
[该干系人使用系统的频率]
意见/问题
[在此处列出会阻碍成功的问题以及任何其他相关信息。
2.4.3关键的干系人/用户需要
列出干系人认为现有解决方案存在的关键问题。
对于列出的每个问题,需澄清以下要点:
•为什么会出现这一问题?
•目前如何解决该问题?
•干系人需要什么样的解决方案?
务必要了解干系人或用户对解决各个问题的相对重视程度。
分级和累积投票方法表明,必须解决的问题与干系人或用户希望解决的问题大有不同。
2.5目标业务模型
新系统业务模型描述,如有相应业务模型材料了,可作为需求规格说明书的输入参考资料。
2.6功能摘要
总结该产品将提供的主要优点和特性,而不必涉及每个功能的细节。
对功能加以组织,使客户或初次阅读该文档的其他人能够理解此功能列表。
2.7功能清单及重要程度说明
功能名称、功能描述、重要程度。
重要程度,以ABC三类来表示:
A:
核心功能;
B:
辅助功能;
C:
外围功能;
级别,按照继承关系分为:
一级,二级,三级;
重要程度
功能名称
功能描述
2.8功能与业务对照关系表
业务组为主编写业务需求,业务需求提交至信息技术组后,由信息技术组建立目标系统业务模型并与业务组进行确认(本操作可选,也可由信息技术组与开发商合作建立),目标业务模型作为系统需求的输入,由信息技术组与开发商合作撰写和评审《系统需求规格书明书》。
业务需求
目标系统业务活动(可选)
2.9假定和约束
列出进行本软件开发工作的假定和约束,例如:
开发语言、开发期限等。
格式限制说明:
本项将指定由现有的标准或规则派生的要求。
报表格式;
数据命名;
财务处理;
审计追踪,等等。
硬件限制说明:
本项包括在各种硬件约束下运行的软件要求,例如,应该包括:
硬件配置的特点(接口数,指令系统等);
存储器和辅助存储器的容量。
2.9.1运行环境约束
硬件设备、支持软件、接口、控制等方面的约束
名称
详细要求
2.9.2设计约束
2.9.3产品应当遵循的标准或规
3具体需求
3.1功能需求
3.1.1具体功能
3.1.1.1容
对于每一类功能或者有时对于每一个功能,需要具体描述其输入、加工和输出的需求。
3.2非功能需求
3.2.1外部接口
3.2.1.1用户接口
提供用户使用软件产品时的接口需求。
例如,如果系统的用户通过显示终端进行操作,就必须指定如下要求:
a对屏幕格式的要求
对界面上的各对象、类型、宽度、取值围、数据来源、能否为空等属性进行描述。
b报表或菜单的页面打印格式和容
c输入输出的需求
解释各输入输出数据类型,并逐项说明其媒体、格式、数值围、精度等。
对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
d程序功能键的可用性
快捷键定义等。
3.2.1.2硬件接口
要指出软件产品和系统硬部件之间每一个接口的逻辑特点。
还可能包括如下事宜:
支撑什么样的设备,如何支撑这些设备,有何约定。
3.2.1.3软件接口
在此要指定需使用的其他软件产品(例如,数据管理系统、操作系统或数学软件包),以及同其他应用系统之间的接口。
对每一个所需的软件产品,要提供如下容:
名字、助记符、规格说明号、版本号、来源。
对于每一个接口,这部分应说明与软件产品相关的接口软件的目的,并根据信息的容和格式定义接口,但不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件即可。
【接口定义】
下表是对一些接口的具体描述:
接口名称
接口描述
填写接口完成的任务
接口类型
填写是输入接口(inbound)还是输出接口(outbound)
源系统
填写接口输入方系统或部件
目标系统
填写接口输出方系统或部件
厂商提供/客户化开发
文件类型
填写文件类型;
若通过数据库表来交互,请指明数据库及表名
文件数量
峰值数据量
频度
填写数据处理的频度
复杂度
批处理/人工
填写接口数据的驱动模式是人工(manual)还是自动(automatic),还是都支持
填写是实时接口还是批量接口等
【其他系统详细信息】
列出所有与接口交互的外围系统的详细信息。
包括输入、输出系统等
系统
填写与接口交互的系统名称
系统类型
填写是接口的数据源系统(source)还是目标系统(object)
数据库
填写交互系统使用的数据库及版本
软件
填写交互系统的软件名称
架构类型
交互系统的架构类型是B/S还是C/S。
位置
填写该软件在交互软件体系中所出的位置
技术支持
填写交互系统的开发商和支持商
功能支持
填写具体的支持商或技术团队
数据归属
【接口隶属系统的详细信息[可选]】
填写接口隶属系统的名称
模块
隶属于具体的模块名称
隶属系统的数据库及版本
负责人
控制报告
【接口配置】
(1)接口基础信息配置
接口基础信息的配置项目,描述配置的方式。
(2)接口运行参数配置
接口运行参数的配置方式和步骤。
【其他配置[可选]】
外围系统或相关模块的配置。
3.2.1.4通信接口
指定各种通信接口。
例如,局部网络的协议等等。
3.2.2其他非功能性需求
下表中的各种需求,可根据实际情况进行选择其中的一种或者几种进行描述,在表的后面是各种需求的详细解释。
静态数值需求
动态数值需求
精度
时间特性要求
可用性
可靠性
可维护性
安全性
可移植性
可扩展性
兼容性
3.2.2.1静态数值需求
支持的终端数;
支持并行操作的用户数。
3.2.2.2动态数值需求
欲处理的事务和任务的数量,以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。
3.2.2.3精度
说明:
对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
3.2.2.4时间特性要求
对于该软件的时间特性要求,如对:
a.响应时间;
b.更新处理时间;
c.数据的转换和传送时间;
d.解题时间等要求。
3.2.2.5数据管理要求
需
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息系统 开发 项目 管理 指导书