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

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:工程执行方案文件状态：文件标识：M草稿当前版本：正式发布作 者：正在修改完成日期：版本历史版本/

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方法与工具提示：说明在过程中将采用的方法与工具.例如采用Rational Rose 进行面向对象分析与设计,采用Visual SourceSafe 进行配置治理,采用Microsoft Office制作文档.方法与工具用途Visual SourceSafe配置治理4里程碑方案里程碑名称开始日期结束日期工作成果备注5资源方案5.1人力资源方案提示：制定本

11、工程的角色责任表,并为的工程成员分配角色一个人可以兼多个角色.角色责任人员姓名工作说明高层领导工程经理需求分析员系统设计员程序员测试员5.2软硬件资源方案提示：分析工程开发、测试、运行所需的软硬件资源和关键计算机资源会影响软件产品的性能的CPU、存、带宽等容,主要容包括：资源级别分为“关键、“普通两种详细配置获取方式如“已经存在、“可以借用或“需要购置等与获取时间使用说明如“谁在“什么时候使用软硬件资源名称级别详细配置狄取方式与时间使用说明关键关键普通6文档交付列表交付文档名称交付日期备注7风险治理方案提示：以下是各个列标题的解释.约定在工程中的风险治理方案,例如：风险识别频度、风险跟踪频度等

12、.风险级别：确定风险的严重性、可能性、风险系数风险描述：缓解方案或者应急方案.风险编号风险级别风险描述缓解方案应急方案严重性(1-5)可能性(%)风险系数(严重性*可能性)8沟通方案甲方代表乙方代表沟通方式沟通频率/时间期望结果9附件工程进度方案进度表提示：制定工程开发的进度表(建议给出工程里程碑方案).例如:编号里程碑名称预计结束时间备注需求调研完成工程方案完成需求分析完成系统设计完成开发完成集成测试完成系统测试完成用户验收测试完成试运行结束工程验收附件2 :业务需求说明书文件状态：M草稿正式发布正在修改文件标识：当前版本：作 者：完成日期：版本历史版本/状态作者参与者起止日期备注1概述1.

13、1业务调研人员【可选】职能部门姓名主管联系备注1.2业务围此处描写总体业务的概要分类.1.3业务目标从甲方高层或商务利益的角度提出本业务系统的期望目标,以及评价标准.1.4相关文档说明：列出本文档的所有参考文献可以是非正式出版物 ,包括现有规、标准、批文、引用到的文件、资料等.1.5业务词汇表说明：列出本文档的所引用的专属领域词汇、术语等,以便于业务需求的提供者和接收者是建立在一致的业务理解根底之上的.2组织结构及业务2.1业务相关组织结构、人员组织结构说明：如果用户岗位设置复杂可分别设置,业务组织结构和人员组织结构2.2组织机构描述2.3角色责任说明：将业务涉及的具体人员进行一定程度的分类和

14、抽象,描述该抽象角色的操作责任2.4治理综述【可选】说明：主要描述该业务的治理特点和治理模式.例如：2.5现有业务流程清单【可选】说明：现有业务流程需要考虑,很多新的业务是在已有业务流程根底上进行重组的.流程编号流程名称责任部门辅助部门3业务流程及业务处理描述说明：针对每一项具体的目标业务,描述具体的业务流程,以及相关业务的具体描述.3.1具体业务流程系统名称+编号对于具体业务流程的命名有规,对具体流程进行编号,便于形成需求矩阵,同时形成需求的治理和跟踪.3.1.1业务流程3.1.2业务描述说明：描述具体的业务流程.3.1.3相关业务对象说明：业务对象：业务流程中涉及的单据、报表等.业务对象使

15、用部门对应电子档案编号3.1.4业务规那么及关键算法说明：描述业务环节关键算法体系.4假定和约束说明：列出进行本软件开发工作的假定和约束,例如开发期限等.4.1运行环境约束4.2设计约束【可选】说明：开发过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第三方产品等.4.3产品应当遵循的标准或规【可选】说明：阐述本产品应当遵循什么标准、规或业务规那么,违反标准、规或业务规那么的产品通常不太可能被接受.5其他5.1目前核心问题和困难5.2业务对工程实施的需求和期望【可选】5.3其他未尽事宜附件3:系统需求规格说明书文件状态：文件标识：M草稿当前版本：正式发布作 者：正在修改完成日期

16、：版本历史版本/状态作者参与者起止日期备注1引言1.1目的例如：规定系统的边界和目标,描述系统的功能性需求和非功能性需求.1.2读者对象及阅读建议说明：指明本文档面向的读者群,及相应的阅读意见.1.3文档围【可选】说明：对本文的围做阐述,本文档改动时,受到影响的围,例如,本文引用到的用例模型,系统原型,系统测试用例等文档.1.4参考文档说明：列出本文档的所有参考文献可以是非正式出版物,包括方案任务书、合同、批文、引用到的文件、资料及软件开发标准等.1.5术语与缩写解释说明：列出本文件中用到的专门术语的定义和缩写词的原词组,并给予解释,以便于所 有读者达成共识.2综合描述2.1系统背景【可选】说

17、明：介绍系统的预期效果、历史原因.2.2问题说明【可选】提供一段说明,总结此工程需要解决的问题.可以采用以下格式:问题是对问题进行说明影响问题影响的干系人问题的后果该问题会导致什么后果成功的解决方案应列出成功解决方案的一些主要优点2.3系统围说明：阐述本工程“适用的业务领域和“不适用的业务领域,本产品“应当包含的容和“不包含的容.说清楚系统围的好处是：1有助于判断什么是需求,什么不是需求；2可以将开发精力集中在产品围之；3有助于限制需求的变更.完整而准确的定义本产品的干系人；明确本产品所影响到的部门和业务；用图表或者文字描述产品的围,概要的定义产品的功能.2.4干系人与用户说明【可选】2.4.

18、1用户环境【可选】详细说明目标用户的工作环境.以下是几项建议：该任务由多少人来完成？是否总在变化？一个任务周期需要多长时间？执行每项活动要用多长时间？是否总在变化？是否有特殊的环境约束：移动、户外、乘机旅行等？目前使用的是哪些系统平台？以后会使用哪些平台？还在使用哪些应用程序？您的应用程序是否需要和这些应用程序集成？在此处可以从业务模型中摘录一些容来概述所涉及的任务和角色等等.2.4.2干系人简档【可选】通过在下表中填写各干系人的相关信息来说明系统中的各个干系人,详尽的简档应包括各种干系人在以下方面的信息：代表谁是此产品的干系人代表？如在他处已作记录,那么此处为可选.此处只需填写姓名.说明对干

19、系人类型的简要说明.类型介绍干系人的技能特长、技术背景和熟练程度即权威用户、业务用户、专家用户、初级用户等责任列出干系人对所开发的系统负有的关键责任,即他们作为干系人的利益.使用频率该干系人使用系统的频率意见/问题在此处列出会阻碍成功的问题以及任何具他相关信息.2.4.3关键的干系人/用户需要列出干系人认为现有解决方案存在的关键问题.对于列出的每个问题,需澄清以下要点:?为什么会出现这一问题？?目前如何解决该问题？?干系人需要什么样的解决方案？务必要了解干系人或用户对解决各个问题的相对重视程度.分级和累积投票方法说明,必须解决的问题与干系人或用户希望解决的问题大有不同.2.5目标业务模型【可选

20、】说明：新系统业务模型描述,如有相应业务模型材料了,可作为需求规格说明书的输入参考资料.2.6功能摘要总结该产品将提供的主要优点和特性,而不必涉及每个功能的细节.对功能加以组织,使客户或初次阅读该文档的其他人能够理解此功能列表.2.7功能清单及重要程度说明说明：功能名称、功能描述、重要程度.重要程度,以ABC三类来表示：A :核心功能；B:辅助功能；C:外围功能；级别,根据继承关系分为：一级,二级,三级；编号级别重要程度功能名称功能描述备注2.8功能与业务对照关系表说明：业务组为主编写业务需求,业务需求提交至信息技术组后,由信息技术组建立目 标系统业务模型并与业务组进行确认本操作可选,也可由信

21、息技术组与开发商合作建 立,目标业务模型作为系统需求的输入,由信息技术组与开发商合作撰写和评审?系 统需求规格书明书?.业务需求目标系统业务活动可选功能名称2.9假定和约束说明：列出进行本软件开发工作的假定和约束,例如：开发语言、开发期限等.格式限制说明：本项将指定由现有的标准或规那么派生的要求.例如：报表格式；数据命名；财务处理；审计追踪,等等.硬件限制说明：本项包括在各种硬件约束下运行的软件要求,例如,应该包括:硬件配置的特点接口数,指令系统等；存储器和辅助存储器的容量.2.9.1运行环境约束说明：硬件设备、支持软件、接口、限制等方面的约束名称详细要求2.9.2设计约束【可选】 说明：开发

22、过程中必须使用的软件语言、软件进程需求、主要开发工具、核心技术、第 三方产品等.2.9.3产品应当遵循的标准或规说明：阐述本产品应当遵循什么标准、规或业务规那么,违反标准、规或业务规那么的产品 通常不太可能被接受.3具体需求3.1功能需求3.1.1具体功能3.1.1.1 容说明：对于每一类功能或者有时对于每一个功能,需要具体描述其输入、加工和输出的 需求.3.2非功能需求3.2.1外部接口3.2.1.1用户接口说明：提供用户使用软件产品时的接口需求.例如,如果系统的用户通过显示终端进行操作,就必须指定如下要求：a对屏幕格式的要求说明：对界面上的各对象、类型、宽度、取值围、数据来源、能否为空等属

23、性进行 描述.b报表或菜单的页面打印格式和容c输入输出的需求说明：解释各输入输出数据类型,并逐项说明其媒体、格式、数值围、精度等.对 软件的数据输出及必须标明的限制输出量进行解释并举例,包括对硬拷贝报告(正 常结果输出、状态输出及异常输出)以及图形或显示报告的描述.d 程序功能键的可用性说明：快捷键定义等.3.2.1.2硬件接口【可选】说明：要指出软件产品和系统硬部件之间每一个接口的逻辑特点.还可能包括如下事宜:支撑什么样的设备,如何支撑这些设备,有何约定.3.2.1.3软件接口【可选】说明：在此要指定需使用的其他软件产品(例如,数据治理系统、操作系统或数学软件包),以及同其他应用系统之间的接

24、口.对每一个所需的软件产品,要提供如下容：名 字、助记符、规格说明号、版本号、来源.对于每一个接口,这局部应说明与软件产品相关的接口软件的目的,并根据信息的容和 格式定义接口,但不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件 即可.【接口定义】下表是对一些接口的具体描述：接口名称接口描述填写接口完成的任务接口类型填与是输入接口( inbound )还是输出接口( outbound )源系统填写接口输入方系统或部件目标系统填写接口输出方系统或部件厂商提供/客户化开发文件类型填写文件类型；假设通过数据库表来交互,请指明数据库及表名文件数重峰值数据量频度填写数据处理的频度复杂度批处理/

25、人工填写接口数据的驱动模式是人工(manual )还是自动(automatic),还是都支持接口类型填写是实时接口还是批量接口等【其他系统详细信息】说明：列出所有与接口交互的外围系统的详细信息.包括输入、输出系统等系统填写与接口交互的系统名称系统类型填写是接口的数据源系统(source)还是目标系统(object)数据库填与交互系统使用的数据库及版本软件填与交互系统的软件名称架构类型交互系统的架构类型是B/S还是C/S.位置填写该软件在交互软件体系中所出的位置技术支持填与'交&系统的开发商和支持商功能支持填与具体的支持冏或技术团队数据归属【接口隶属系统的详细信息可选】系统填写接

26、口隶属系统的名称模块隶属于具体的模块名称数据库隶属系统的数据库及版本负责人限制报告【接口配置】(1) 接口根底信息配置说明：接口根底信息的配置工程,描述配置的方式.(2) 接口运行参数配置说明：接口运行参数的配置方式和步骤.【其他配置可选】说明：外围系统或相关模块的配置.3.2.1.4通信接口【可选】说明：指定各种通信接口.例如,局部网络的协议等等.3.2.2其他非功能性需求说明：下表中的各种需求,可根据实际情况进行选择其中的一种或者几种进行描述,在 表的后面是各种需求的详细解释.名称详细要求静态数值需求动态数值需求精度时间特性要求可用性可靠性可维护性平安性可移植性可扩展性兼容性.3.2.2.

27、1静态数值需求说明：支持的终端数；支持并行操作的用户数.3.2.2.2动态数值需求说明：欲处理的事务和任务的数量,以及在正常情况下和峰值工作条件下一定时间周期 中处理的数据总量.3.2.2.3 精度说明:对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度.3.2.2.4时间特性要求说明：对于该软件的时间特性要求,如对：a.响应时间；b .更新处理时间；c.数据的转换和传送时间；d .解题时间等要求.3.2.2.5数据治理要求【可选】说明：需要治理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求做出估算.3.2.2.6可用性指出普通用户和高级用户要高效地

28、执行特定操作所需的培训时间,指出典型任务的可评测任务次数或根据用户或喜欢的其他系统确定新系统的可用性需求性能3.2.2.7可靠性指出可用时间百分比 xx.xx%、使用小时数、维护访问权、降级模式操作等.平均故 障间隔时间MTBF.平均修复时间 MTTR一系统在发生故障后可以暂停运行的时 间.指出系统输出要求具备的精密度分辨率和精确度根据某一的标准.3.2.3文档需求说明：主要是在线用户手册与帮助系统,也包括其他的文档3.2.4第三方产品【可选】说明：使用到的第三方产品相关的使用许可、使用限制、接口标准.3.3数据字典说明：把相关的数据抽取出来统一维护,在其他章节如有类似信息描述,那么关联到数据

29、 字典的相关局部并加辅助说明,如：引用到的字段等.4补充资料【可选】4.1待确定的问题列表【可选】需求标题1调查方式调查人调查对象时间、地点需求信息记录附件4:需求变更申请记录号:项目：类 型：开发工程工程负责人：变更申请人：申请部门：申请日期：变更容变更的容及其理由说明变更的容及变更的理由,如果变更为业务组提出,那么业务组填写；如果变更为为信息技术组提出,那么信息技术组填写；变更的系统及版本说明变更所涉及的工作产品及其当前版本,如果变更为业务组提出,那么业务组填写；如果变更为为信息技术组提出,那么信息技术组填写；对业务及其接分析需求变更引起的业务变更、业务接口的变更,口的影响业务组填写甲方业

30、务负责同意不同意人意见：签字：日期：变更结果变更分析对相关的资源影响分析需求变更对人员、开发设备和目标设备的影响,仅信息技术组填写风险分析分析需求变更的风险,仅信息技术组填写对其他系统或接口的影响分析需求变更引起的系统变更、其他系统或接口的变更,仅信息技术组填写对开发工作量、进度和本钱影响估计需求变更对开发工作顽日进度的影响,需说明本次变更工作重/本钱是否超过本工程总开发工作量/总本钱的1%?仅信息技术组填写开发商意见开发商负责人意见：同意不同意指定验证人员：签字：日期：变更结果变更的系统及版本说明变更后的工作产品签字：日期：变更验证验证变更结果完整性是否正确性是否附加变更是否版本和名称是否甲

31、方验证人意见：符合要求不符合要求签字：日期：附件5:系统设计说明书文件状态：V草稿正式发布正在修改文件标识：当前版本：作 者：完成日期：版本历史版本/状态作者参与者起止日期备注1引言1.1编写目的说明编写这份详细设计说明书的目的,指出预期的读者1.2背景说明：待开发软件系统的名称；本工程的任务提出者、开发者、用户和运行该程序系统的计算中央.1.3定义列出本文件中用到专门术语的定义和外文首字母组词的原词组.1.4参考资料列出有关的参考资料,如：本工程的经核准的计戈M壬务书或合同、上级机关的批文；属于本工程的其他已发表的文件；本文件中各处引用到的文件资料, 包括所要用到的软件开发标准. 列出这些文

32、件的 标题、文件编号、发表日期和出版单位,说明能够取得这些文件的来源.2程序系统的结构用一系列图表列出本程序系统的每个程序包括每个模块和子程序的名称、标识符和它们之间的层次结构关系.3程序1 标识符设计说明从本章开始,逐个地给出各个层次中的每个程序的设计考虑.以下给出的提纲是针对一般情况的.对于一个具体的模块,尤其是层次比拟低的模块或子程序,其很多条目 的容往往与它所隶属的上一层模块的对应条目的容相同,在这种情况下,只要简单地说明这一点即可.3.1程序描述给出对该程序的简要描述, 主要说明安排设计本程序的目的意义,并且,还要说明本程序的特点如 是常驻存还是非常驻？是否子程序？是可重人的还是不可

33、重人的？ 有无覆盖要求？是顺序处理还是并发处理等.3.2功能说明该程序应具有的功能,可采用IPO图即输入一处理一输出图的形式.3.3性能说明对该程序的全部性能要求,包括对精度、灵活性和时间特性的要求.3.4输人项给出对每一个输入项的特性,包括名称、标识、数据的类型和格式、数据值的有效围、输入的方式.数量和频度、输入媒体、输入数据的来源和平安保密条件等等.3.5输出项给出对每一个输出项的特性,包括名称、标识、数据的类型和格式,数据值的有效围,输出的形式、数量和频度,输出媒体、对输出图形及符号的说明、平安保密条件等 等.3.6算法详细说明本程序所选用的算法,具体的计算公式和计算步骤.3.7流程逻辑

34、用图表例如流程图、判定表等辅以必要的说明来表示本程序的逻辑流程.3.8 接口用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序,说明参数赋值和调用方式,说明与本程序相直接关联的数据结构数据库、数据文 卷.3.9界面原型图根据系统各功能模块的逻辑顺序,提供界面原型图的跳转展示,各项人机互动组件及数据显示必须根本完善,界面直观友好.3.10存储分配根据需要,说明本程序的存储分配.3.11注释设计说明准备在本程序中安排的注释,如：加在模块首部的注释；加在各分枝点处的注释；对各变量的功能、围、缺省条件等所加的注释；对使用的逻辑所加的注释等等.3.12限制条件说明本程序运行中所受到

35、的限制条件.3.13尚未解决的问题说明在本程序的设计未解决而设计者认为在软件完成之前应解决的问题.4程序2 标识符设计说明用类似F. 3的方式,说明第2个程序乃至第N个程序的设计考虑.附件6 :系统设计评审报告文件状态：M草稿正式发布正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.根本信息提7K ：由评审主持人或评审员填写此表格.待评审的工作成果工作成果名称,标识符,版本,作者,时间技术评审方式正式评审或者走查评审时间评审地点参加技术评审的人员类别名字工作单位职称、职务：主持人评审小组成员记录员

36、2.缺陷识别和跟踪评审1可题跟踪表编问题问题严重提交提交问题解决举措/问实问备号描述类型性者日期处理原因说明题际题注负责解关关人决闭闭状日验态期证人1233. 评审结论与意见提示：由主持人或评审员填写此表格.评审结论工作成果合格,“无需修改或者“需要稍微修改但不必再审核V工作成果根本合格,需要作少量的修改,之后通过审核即可.工作成果不合格,需要作比拟大的修改,之后必须重新对其评审.0意见负责人签字签字：日期：附件7:用户测试方案文件状态：文件标识：M草稿当前版本：正式发布作 者：正在修改完成日期：版本历史版本/状态作者参与者起止日期备注1.测试围与主要容般地,系统测试的主提示：系统测试小组应当

37、根据工程的特征确定测试围与容.要容包括功能测试、健壮性测试、性能测试、用户界面测试、平安性( security )测试、 安装与反安装测试等.2. 测试方法提示：例如黑盒测试和白盒测试.3. 测试环境与测试辅助工具环境设备配置名称/类型备注效劳器软件硬件客户端软件硬件网络工具类型工具开发商版本测试治理缺陷跟踪用于功能性测试的工具用于性能测试的工具测试覆盖监测器或评测器4. 测试进度方案任务人员任务开始日期结束日期制测试方案设计测试实施测试执行测试对测试进行评估5. 测试完成准那么提示：对于非严格系统可以采用“基于测试用例的准那么：(1 )功能性测试用例通过率到达 100 %;(2)非功能性测试用例通过率到达95%时.对于严格系统,应当补充“基于 BUG密度的规那么：相邻n个CPU小时“测试期BUG密度全部低于某个值 m.例如n大于10 , m 小于等于1.最后一次回归测试二类缺陷数量为零,用例外非常规缺陷数量小于等于 2个/万行 程序；测试用例功能点覆盖率100% ;6. BUG治理与改错方案提示：根据所采用的 BUG治理工具确定：(1 ) BUG治理流程,(2) BUG修改流 程.定义BUG修改约定,例如：不同级别的 BUG必须在几日处理完成.7. 附录.本方案审批意见测试组审批意见:日期附件8:用户测试报告1.根本信息测试依据例如：参照标准、客户