信息系统开发项目管理系统指导书

1、标准文档信息系统开发项目管理指导书1、项目建设总体目标系统应该根据甲方用户的现有业务需求及发展规划的扩延要求，提供功能完善、界面友好、流程清晰、智能高效，配置维护方便的系统功能，满足系统运行稳定、安全、可靠、高效等技术要求。提供电脑版和手机版2个版本。2、项目开发建设过程及要求为了确保项目能按照甲乙双方达成的目标要求顺利开展，甲乙双方应该联合成立项目组，由乙方编制项目执行计划（式样见附件1）并有甲方确认同意。2.1系统需求分析1 、开发商必须对甲方公司的业务需求进行深入调研，收集汇总客户的具体需求，出具业务需求说明书（式样见附件2）,并确保业务需求说明书中包含了所有的业务需求。业务需求说明书经

2、甲方公司（用户）负责人签字确认，作为业务需求基线。2 、开发商在获得甲方签字确认的业务需求说明书后，提出技术需求和解决方案，并对系统进行定义，出具系统需求规格说明书（式样见附件3）。系统需求规格说明书需详细列出业务对系统的要求（界面、输入、输出、管理功能、安全需求、运作模式、关键指标等）。系统需求规格说明书需经甲方公司（用户）负责人签字确认。3 、当业务需求发生变更时，应由甲方公司提交需求变更申请标准文档（式样见附件4）给乙方开发商实施。2.2系统设计为简化流程，本项目建议将概要设计和详细设计合二为一，统一遵循完备性、一致性、扩展性、可靠性、安全性、可维护性等原则。1、在该阶段确定总体结构和软

3、件开发架构，文件命名规范，编码规范。按软件需求划分成子系统，定义目标系统的功能模块及各个功能模块的关系。2、确定软件模块结构，给出每个功能模块的功能描述、数据接口描述，各模块之间的详细接口信息，并完成系统设计说明书（式样见附件5）。3、系统设计说明书应该包括所有用户界面的原型图。4、完成数据库的设计，并编写数据库设计说明书。5、在设计阶段，用户应充分参与，确保设计能满足系统需求。6、甲方应对组织对开发商提交的系统设计说明书进行评审，设计评审均以业务需求说明书和系统需求规格说明书为依据，确保系统设计满足全部需求，并出具系统设计评审报告（式样见附件6）。2.3系统开发1 、系统开发包括程序编码、单

4、元测试和集成测试。开发商根据系统设计说明书制定系统开发计划，并提交给甲方对计划进行监督。2 、开发商有条件的情况下尽可能开发、测试和生产环境独立标准文档选择软件工具，明确项目成员的职责分工，按照编码规范和详细设计实现软件功能。3、代码应满足结构良好，清晰易读，且与设计一致，符合编码规范。4、开发人员需要软件实现过程中编写软件功能说明，源代码说明。软件功能说明文档应说明项目名称、编号、软件名称和版本号，软件功能、主要功能实现过程。源代码说明应说明项目编号、软件名称、功能，全局变量、数据库字典、函数功能、接口。该文档包含在源代码文件中，以注释形式存在。5、开发商进行单元测试和集成测试。开发人员处理

5、测试人员反馈的测试问题，并以书面形式反馈主要问题及解决办法，直至系统运行稳定。测试组出具系统测试报告，测试人员签字确认测试结果。2.4用户测试1 、开发商编制用户测试计划（式样见附件7）,测试计划必须定义测试标准，并明确各种测试的测试步骤和需要的系统设置要求，并提交甲方准备。2 、甲方应该按照开发商测试组要求配合标准测试数据，测试用数据要足够模拟使用环境中的实际数据。对已评定为敏感信息的数据进行敏感性处理和保护。3 、按照测试计划完成用户测试后，测试组应该出具用户测试报告（式样见附件8）,甲乙双方必须在用户测试报告中签字确认。4、完成测试后，开发商完成系统帮助文档（其中包括用户操标准文档作手册

6、和安装维护手册）的编写。凡涉及应用系统的变更，应对系统帮助文档及时更新。2.5 系统试运行1 、项目组必须制定试运行计划（式样见附件9）,并制定试运行验收指标。试运行计划中应包含问题应对机制，明确问题沟通渠道和职责分工。2 、项目组联合甲方公司进行相关系统部署工作，准备培训资料,对相关用户和信息技术人员进行培训。3 、项目组根据试运行计划负责对用户的老旧系统进行系统转换和数据迁移。系统转换前，检查系统环境，确保运行环境能满足新应用系统的需要。系统转换时必须详细记录原系统中的重要参数、设置等系统信息，并填写试运行报告相关内容。4、系统转换和数据迁移完成后，正式启动试运行。在试运行过程中，项目组应

7、把系统运行情况（系统资源使用，反应速度等）记录到试运行报告中。必要时，项目组应根据系统运行情况对应用系统进行优化。5、试运行达到试运行计划规定的终止条件时，开发商编写试运行报告（式样见附件10）。此报告应由开发商和甲方单位签字确认，试运行结束。2.6 系统验收与正式上线1 、系统验收主要用户单位及开发商联合组成独立系统验收小组，由验收小组共同商定验收的标准和方法。验收小组从功能需求及技术标准文档需求层面对系统进行综合评估，系统验收内容包括但不限于移交给甲方的系统测试报告、系统安装文档、配置文档、源代码、操作手册、维护手册、系统应急预案、系统“回退”计划等。2 、验收小组应根据验收情况整理形成系

8、统验收报告（式样见附件11）,验收报告必须甲乙双方签字，并提交甲方作为付款依据。3 、系统验收合格且问题整改完成并经甲乙双方主要领导同意后系统转入正式上线运行。3售后服务及保密要求开发商应该保证系统技术支持人员队伍的稳定，明确售后服务内容与责任，按照合同要求安排维护人员对系统进行技术支持。系统需求变更或调整，记录变更原因和软件及源代码的版本控制，按照软件变更要求对系统进行维护。为了保护甲乙双方的商业、技术秘密等权益，开发商与甲方、开发商与其相关员工必须签订保密协议。标准文档附件1:项目执行计划文件状态：，草稿正式发布正在修改文件标识：当前版本：作者：完成日期：版本历史版本/状态作者参与后起止日

9、期备注1文档介绍1.1 文档目的1.2 文档范围1.3 参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下:标识符作者，文献名称，出版单位（或归属单位），日期例如：AAA作者，立项建议书，机构名称，日期1.5 术语与缩写解释缩写、术语解释2项目介绍2.1 项目范围提示：标准文档(1)用简练的语言说明本项目“是什么”，“说明用途”。(2)说明本项目“应当包含的内容”和“不包含的内容”。2.2 项目目标提示：给出“清晰的”、“可实现”、“可验证”的目标。2.3 客户与最终用户介绍提示：请说明本项目的客户、用户及其相关责任人是谁，描述最终用户的特征。2.4 约束提示：(1)请说明

10、在项目开发过程中应当遵循的标准或规范(2)请说明相关项目可能对本项目造成的影响。(3)说明一些假设和依赖。3项目过程定义3.1 软件生命周期模型提示：简要描述、绘制本项目的软件生命周期模型。3.2 项目规范提示：描述项目需遵循的规范，例如：编码规范。此处可以表现为编码规范的链接。3.3 方法与工具提示：说明在过程中将采用的方法与工具。例如采用RationalRose进行面向对象分析与设计，采用VisualSourceSafe进行配置管理，采用MicrosoftOffice制作文档。方法与工具用途VisualSourceSafe配置管理4里程碑计划1丁P里程碑名称开始日期结束日期工作成果备注标准

11、文档5资源计划5.1人力资源计划提示：制定本项目的角色职责表，并为已知的项目成员分配角色（一个人可以兼多个角色）。角色职责人员姓名工作说明高层领导项目经理需求分析员系统设计员程序员测试员5.2软硬件资源计划提示：分析项目开发、测试、运行所需的软硬件资源和关键计算机资源（会影响软件产品的性能的CPU内存、带宽等内容），主要内容包括：资源级别（分为“关键”、“普通”两种）详细配置获取方式（如“已经存在”、“可以借用”或“需要购买”等）与获取时间使用说明（如“谁”在“什么”时候使用）软硬件资源名称级别详细配置放取方式与时间使用说明关键关键普通6文档交付列表1丁P交付文档名称交付日期备注标准文档7风险

12、管理计划提示：以下是各个列标题的解释。约定在项目中的风险管理方案，例如：风险识别频度、风险跟踪频度等。风险级别：确定风险的严重性、可能性、风险系数风险描述：缓解方案或者应急计划。风险编号风险级别风险描述缓解方案应急计划严重性(1-5)可能性(%)风险系数(严重性*可能性)8沟通计划甲方代表乙方代表沟通方式沟通频率/时间期望结果9附件项目进度计划进度表提示：制定项目开发的进度表(建议给出项目里程碑计划)。例如:编号里程碑名称预计结束时间备注需求调研完成项目计划完成需求分析完成系统设计完成开发完成标准文档集成测试完成系统测试完成用户验收测试完成试运行结束项目验收附件2:业务需求说明书文件状态：V草

13、稿正式发布正在修改文件标识：当前版本：作者：完成日期：版本历史版本/状态作者参与后起止日期备注1概述1.1 业务调研人员名单【可选】标准文档1丁P职能部门姓名主管联系电话备注1.2 业务范围此处描写总体业务的概要分类。1.3 业务目标从甲方高层或商务利益的角度提出本业务系统的期望目标，以及评价标准。1.4 相关文档说明：列出本文档的所有参考文献（可以是非正式出版物），包括现有规范、标准、批文、引用到的文件、资料等。1.5 业务词汇表说明：列出本文档的所引用的专属领域词汇、术语等，以便于业务需求的提供者和接收者是建立在一致的业务理解基础之上的。2组织结构及业务2.1 业务相关组织结构、人员组织结

14、构说明：如果用户岗位设置复杂可分别设置，业务组织结构和人员组织结构2.2 组织机构描述2.3 角色职责说明：将业务涉及的具体人员进行一定程度的分类和抽象，描述该抽象角色的操作职责。2.4 管理综述【可选】说明：主要描述该业务的管理特点和管理模式。例如：2.5 现有业务流程清单【可选】说明：现有业务流程需要考虑，很多新的业务是在已有业务流程基础上进行重组的。流程编号流程名称责任部门辅助部门3业务流程及业务处理描述标准文档说明：针对每一项具体的目标业务，描述具体的业务流程，以及相关业务的具体描述。3.1 具体业务流程（系统名称+编号）对于具体业务流程的命名有规范，对具体流程进行编号，便于形成需求矩

15、阵，同时形成需求的管理和跟踪。3.1.1 业务流程3.1.2 业务描述说明：描述具体的业务流程。3.1.3 相关业务对象说明：业务对象：业务流程中涉及的单据、报表等。业务对象使用部门对应电子档案编号3.1.4 业务规则及关键算法说明：描述业务环节关键算法体系。4假定和约束说明：列出进行本软件开发工作的假定和约束，例如开发期限等。4.1 运行环境约束4.2 设计约束【可选】说明：开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等。4.3 产品应当遵循的标准或规范【可选】说明：阐述本产品应当遵循什么标准、规范或业务规则，违反标准、规范或业务规则的产品通常不太可能被接受

16、。5其他5.1 目前核心问题和困难5.2 业务对项目实施的需求和期望【可选】标准文档5.3 其他未尽事宜附件3:系统需求规格说明书文件状态：V草稿正式发布正在修改文件标识：当前版本：作者：完成日期：版本历史版本/状态作者参与后起止日期备注1引言1.1 目的标准文档例如：规定系统的边界和目标，描述系统的功能性需求和非功能性需求。1.2 读者对象及阅读建议说明：指明本文档面向的读者群，及相应的阅读意见。1.3 文档范围【可选】说明：对本文的范围做阐述，本文档改动时，受到影响的范围，例如，本文引用到的用例模型，系统原型，系统测试用例等文档。1.4 参考文档说明：列出本文档的所有参考文献（可以是非正式

17、出版物），包括计划任务书、合同、批文、引用到的文件、资料及软件开发标准等。1.5 术语与缩写解释说明：列出本文件中用到的专门术语的定义和缩写词的原词组，并给予解释，以便于所有读者达成共识。2综合描述2.1 系统背景【可选】说明：介绍系统的预期效果、历史原因。2.2 问题说明【可选】提供一段说明，总结此项目需要解决的问题。可以采用以下格式：问题是对问题进行说明影响问题影响的干系人问题的后果该问题会导致什么后果成功的解决方案应列出成功解决方案的一些主要优点2.3 系统范围说明：阐述本项目“适用的业务领域”和“不适用的业务领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚系统范围的好处是：（

18、1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内；（3）有助于控制需求的变更。完整而准确的定义本产品的干系人;标准文档明确本产品所影响到的部门和业务；用图表或者文字描述产品的范围，概要的定义产品的功能。2.4 干系人与用户说明【可选】2.4.1 用户环境【可选】详细说明目标用户的工作环境。以下是几项建议：该任务由多少人来完成？是否总在变化？一个任务周期需要多长时间？执行每项活动要用多长时间？是否总在变化？是否有特殊的环境约束：移动、户外、乘机旅行等？目前使用的是哪些系统平台？以后会使用哪些平台？还在使用哪些应用程序？您的应用程序是否需要和这些应用程序集成？在此处可

19、以从业务模型中摘录一些内容来概述所涉及的任务和角色等等。2.4.2 干系人简档【可选】通过在下表中填写各干系人的相关信息来说明系统中的各个干系人，详尽的简档应包括各种干系人在以下方面的信息：代表谁是此产品的干系人代表？（如在他处已作记录，则此处为可选。）此处只需填写姓名。说明对干系人类型的简要说明。口介绍干系人的技能特长、技术背景和熟练程度（即权威用户、业务用户、专家用户、初级用户等）职责列出干系人对所开发的系统负有的关键职责，即他们作为干系人的利益。使用频率该干系人使用系统的频率意见/问题在此处列出会阻碍成功的问题以及任何具他相关信息。2.4.3 关键的干系人/用户需要列出干系人认为现有解决

20、方案存在的关键问题。对于列出的每个问题，需澄清以下要点:标准文档?为什么会出现这一问题？?目前如何解决该问题？?干系人需要什么样的解决方案？务必要了解干系人或用户对解决各个问题的相对重视程度。分级和累积投票方法表明,必须解决的问题与干系人或用户希望解决的问题大有不同。2.5 目标业务模型【可选】说明：新系统业务模型描述，如有相应业务模型材料了，可作为需求规格说明书的输入参考资料。2.6 功能摘要总结该产品将提供的主要优点和特性，而不必涉及每个功能的细节。对功能加以组织，使客户或初次阅读该文档的其他人能够理解此功能列表。2.7 功能清单及重要程度说明说明：功能名称、功能描述、重要程度。重要程度，

21、以ABC三类来表示：A:核心功能；B:辅助功能；C:外围功能；级别，按照继承关系分为：一级，二级，三级；编号级别重要程度功能名称功能描述备注2.8功能与业务对照关系表说明：业务组为主编写业务需求，业务需求提交至信息技术组后，由信息技术组建立目标系统业务模型并与业务组进行确认（本操作可选，也可由信息技术组与开发商合作建立），目标业务模型作为系统需求的输入，由信息技术组与开发商合作撰写和评审系统需求规格书明书。业务需求目标系统业务活动（可选）功能名称标准文档2.9假定和约束说明：列出进行本软件开发工作的假定和约束，例如：开发语言、开发期限等。格式限制说明：本项将指定由现有的标准或规则派生的要求。例如：报表格式；数据命名；财务处理；审计追踪，等等。硬件限制说明：本项包括在各种硬件约束下运行的软件要求，例如，应该包括:硬件配置的特点（接口数，指令系统等）；内存储器和辅助存储器的容量。2.9.1 运行环境约束说明：硬件设备、支持软件、接口、控制等方面的约束名称详细要求2.9.2 设计约束【可选】说明：开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等。2.9.3 产品应当遵循的标准或规范说明：阐述本产品应当遵循什么标准、规范或业务规则，违反标准、规范或业务规则的产品