JB/T 6987-1993 制造资源计划MRPⅡ系统原型法软件开发规范 JB/T 6987-1993 制造资源计划MRPⅡ系统原型法软件开发规范

JB/T 6987-1993 制造资源计划MRPⅡ系统原型法软件开发规范

  • 期刊名字:
  • 文件大小:72.00KB
  • 论文作者:网友
  • 作者单位:
  • 更新时间:2020-04-24
  • 下载次数:
论文简介

L07中华人民共和圜机械行业标准JBT6987-1993制造资源计划MRPⅡ系统原型法软件开发规范1993-0727发布199407-01实施中华人民共和国机械工业部发布目次1主题内容与适用范围…(1)2引用标准(1)3术语(2)4项目管理…5软件开发流程(2)6文档编制说明(10)附录A可行性研究与规划报告内容提要(参考件)(12)附录B软件基本需求说明书内容提要(参考件)(13)附录C系统需求分析有关参考表格(参考件)…(15)附录D系统设计有关参考表格(参考件)…(28)附录E软件问题报告(参考件)…………(45附录F软件修改报告(参考件)(47)中华人民共和国机械行业标准制造资源计划MRPⅡ系统JBT6987-1993原型法软件开发规范信息系统传统的软件开发方法是生命周期法。在开发过程中,系统需求分析阶段是关键的一步,特别是在软件开发的早期阶段岀现的错误定义,只有在完成初步设计、详细设计和测试后才能暴露出来。而修正这些错误要花费很高的费用,而且难以修复。有些错误甚至可能导致重新考虑软件系统全部设计,以至于造成整个系统全部失败为了克服生命周期法的这些弱点,产生了软件开发的原型法。这些开发方法是用户驱动和参与的方法,它把重点放在对问题的描述和尽快提供给用户一个可操作的系统原型上,这样就使得用户和设计者能够反复的运行、测试、评价和修改系统原型。用这种方法使开发的软件系统的需求和系统原型密切结合起来,通过系统原型的修改、完善,开发岀一个结构合理的、可执行的、明确的、能逐步满足用户需要的系统。目前,在计算机和信息系统产业,传统的系统开发方法正逐步与动态的原型开发方法相结合。根据原型法的应用目的及场合,可以分为三种类型:丟弃式、演化式和递增式,其中递增式比较适合企业管理信息系统的开发。原型法是传统生命周期法的补充,因此可以把原型法和生命周期法结合起来,丢弃式和递增式的原型法,甚至于可以认为被包含在传统的生命周期法中。1主题内容与适用范围1.1目的与作用本标准是把递增式原型法和传统的生命周期法结合起来,制订企业管理信息系统MRPⅡ的开发过程的各个阶段及每个阶段的任务、主要工作内容、工作要求及交付文档。本标准的目的是使整个MRPⅡ软件开发过程阶段清晰、要求明确、任务具体,使之软件系统开发快速、高效、实用。向广大企业用户和开发人员提供行之有效的方法、准则和规程。使用本标准能提高软件系统质量、缩短开发时间、减少开发费用,使软件开发人员和用户密切配合,共同协作,在早期的开发阶段,就可以对一个实际的原型,提出使用性意见和评价,可以早期发现和解决问题,同时培养了用户,使软件开发更加科学、更加有成效。1.2适用范围本标准主要是我国制造业企业建立管理信息系统MRPⅡ的指导性文件。旨在适用于尽可能广泛的软件系统的开发工作,包括不同类型的系统。本标准给岀的开发过程及推荐文件,在使用过程中可以根据开发的系统特点和规模进行选择。2引用标准GB8566计算机软件开发规范GB8567计算机软件产品开发文件编制指南机械工业部1993-07-27批准1994-07-01实施JBr6987-19933术语3.1生命周期法(SDLC)生命周期法是软件系统的传统开发方法。它是将软件系统的生命周期分为若干个互相区别又有联系的阶段,每个阶段的工作均以前一阶段工作的结果为依据,并作为下一阶段工作的前提。通常,软件信息系统的生命周期可以分为五个阶段∶可行性研究与规划、系统需求分析、系统设计、系统实施及测试、系统运行与维护开发单位可根据所开发系统的性质、用途和规模等因素决定在软件生命周期中增加或减少相应的阶段。3.2原型法原型法是动态的软件系统开发方法。它是将系统仿真技术引入软件系统的开发过程中。原型法是根据用户的基本需求,快速建造或者选用已存在的软件系统或商品软件作为系统原型,经过反复分析、评价、修改和重新定义,提高原型。最终建立满足用户需求的目标系统的一种开发方法。与经典的原型法有区别的改进的原型法的开发过程概括为四个阶段:可行性研究与规划、基本需求分析和系统设计、建造和运行系统原型、完善原型(包括评审、修改、使用和维护)3.3现行系统现行系统是指正在运行的企业管理系统,其职能部门可能是手工操作,也可能实现了部分计算机管理3.4目标系统目标系统是指将要建立的计算机管理信息系统。3.5系统原型原型就是模型,而系统原型就是一个计算机管理信息系统的模型。这个模型可以在运行中进行检查、测试、修改、再测试,直到它的性能达到用户需求为止项目管理企业建立MRPⅡ系统是一项复杂的系统工程,为了保证系统开发成功,必须进行全面、全员、全过程的管理。4.Ⅰ设置项目管理组织。实施对软件开发的计划、进度、人员组织及软件开发过程与资源的管理,并要制订执行规程,用来控制软件开发全过程。4.2建立项目课题组,由用户和开发单位共同组成。原形法开发方法强调用户的直接参与,以及与开发单位的紧密联系和密切配合,共同有效地反复进行系统设计、测试、定义和实施,这样才能开发出高质量的软件系统。5软件开发流程5.1可行性研究与规划5.1.1任务通过详细调査和综合分析,了解用户的要求、现实环境及现行系统。提出新系统初步建议方案。从技术上、经济上和社会等因素研究并论证软件项目的可行性,编写可行性研究报告,制订初步项目开发和实施规划。JBr6987-19935.1.2主要工作内容5.1.2.1用户需求调查:a.系统目标需求调查;b.系统规划发展要求调查。5.1.2.2企业环境初步调查a.企业概况企业自然情况产品开发及市场情况;经济效益生产与生产管理情况;资源情况;企业发展规划影响企业发展的”企业瓶颈b.组织机构与外部联系描述企业组织机构及业务范围企业与外部联系主要业务流程描述主要物质流程主要数据流程。d.现行计算机信息系统的现状企业计算机信息系统的地位、状况和应用水平应用效益企业中计算机应用人员素质情况和要求有关项目经费支持情况。e.现行系统(包括人工、计算机系统)的分析现行人工系统的主要问题现行计算机系统的主要问题;对目标系统要解决或改进的主要问题现行系统改进的主要途径。5.1.3提出目标系统初步建议方案5.1.3.1分析用户需求,确定系统目标。5.1.3.2确定目标系统的子系统划分原则及其划分。5.1.3.3确定目标系统的逻辑结构和功能。5.1.3.4确定目标系统的物理结构a.基本系统物理结构及网络通讯环境的确定。b.计算机硬件配置。JBr6987-1993c.计算机软件配置d.分析基本物理结构及计算机选型、硬软件配置的优缺点。e.确定目标系统的开发进度计划。f.经费预算和投资方案。g.人员需求与培训计划管理人员的培训计划;计算机管理机构及专业人员培训计划。h.提出可供选择的原型及软件产品进行可用性评价功能的比较评价实现功能的方法评价;系统的易操作、易使用评价二次开发投入评价。系统原型选择基本原则:运行环境应是开放系统环境选用较成熟的软件包并在本行业运行且取得较好效果;能利用开发工具快速修改、扩充的软件应用软件有关资料完整(包括源程序、程序设计说明、使用说明等);软件功能基本满足用户需求。j.多种方案可行性比较分析技术可行性;经济可行性;性能价格比;效益和效果5.1.4工作要求5.1.4.1可行性分析中优先考虑经济可行性,它包括成本/效益分析、市场经营的长短期策略。5.1.4.2成本效益分析应有确切的数据和估算方法。5.1.4.3系统目标的确定是用户和开发者不断交互、逐步明确和深化的过程,因此双方要共同工作,共同协商,根据企业情况制定可分步实现的系统目标。5.1.5交付文档5.1.5.1可行性研究报告。5.1.5.2初步的项目开发进度计划。5.2系统基本需求分析5.2.1任务根据现行系统的需求分析确定管理信息系统的软件的运行环境、基本功能和性能要求,人机界面基本形式,编写软件设计说明和确认测试计划。JBr6987-19935.2.2主要工作内容5.2.2.1现行系统的详细调查与分析现行系统的数据流程b.有关数据流程的信息要求,包括输λ信息、处理过程和算法、输岀信息及信息编码等c.信息处理的处理量及处理响应时间要求d.性能控制方法,包括适用性、可靠性、安全性、可维护性;e.现有计算机信息系统的主要功能,应用范围、结构及与目标系统的关系f.现行编码体系。5.2.2.2确定目标系统的基本需求a.目标系统的基本功能需求确定子系统的划分确定各子系统的功能需求定义。b.接口需求定义人机界面的基本形式(屏幕、报表、声音、图形等多媒体);与其他系统之间的接口子系统之间的接口。c.目标系统的数据需求外部数据及全局数据定义数据库或数据结构定义。d.确定开发软件运行环境。5.2.2.3目标系统的逻辑模型设计(初步设计)总体结构目标系统的系统逻辑结构子系统的划分与功能定义;子系统之间关联及接口定义;数据的总体结构系统与外部环境接口定义。b.子系统描述子系统功能模块的划分及其定义;代码设计输岀设计(屏幕显示、打印输出、文件输出、图形等多媒体形式);输入设计(数据采集、数据登录和数据录入的多媒体形式);文件和数据库结构和定义设计。5.2.2.4系统可靠性设计5.2.2.5目标系统的物理结构设计a.物理结构;b.计算系统硬件配制。JBr6987-19935.2.2.6实施计划调整a.实施方案调整;b.实施计划调整。5.2.2.7制订确认测试计划。5.2.3工作要求5.2.3.1软件开发单位与用户要密切配合,做好软件需求分析工作和对现场改造工作。5.2.3.2采用面向数据流的结构化分析方法(SA)进行软件需求分析。5.2.3.3建议采用结构化分析和设计方法使用如下工具a.数据流图b.数据字典。5.2.4交付文档5.2.4.1软件需求说明书5.2.4.2修改后的项目开发计划5.2.4.3确认的测试计划。5.3快速建造和运行系统原型5.3.1任务利用软件开发工具,根据需求分析和系统初步设计,快速建造系统原型,也可以根据基本需求选择现成软件包或商品软件产品作为系统原型,然后输λ使用数据,运行系统原型。5.3.2主要工作内容其工作內容要根据建造或者选择原型,而有不同的选择项。5.3.2.1详细设计a.软件系统结构用图表示本系统的系统元素(各子系统的各层模块、子程序公用程序等)的划分、标识、功能及它们之间的控制关系。b.程序系统结构用图表示本程序系统內的毎个程序(包括模块和子程序)的名称、标识符和它们之间的层次关系。c.程序设计约定功能性能输入输出;算法及处理逻辑流程;接口;测试计划(〔模块测试和组装测试——测试技术要求、测试数据输入、预测结果、人员安排、进度d.数据库结构设计:确定数据结构模型(层次、网络、关系);JBr6987-1993逻辑结构设计物理结构设计建立系统程序员视图,包括数据在內存中的安排、索引区、缓冲区的设计、所使用的外存设备及外存空间的组织包括索引区、数据块组织与划分、访问数据的方式方法等。e.数据字典设计对数据库设计中涉及到的各项目,要建立起数据字典,以说明它们的标识符、定义及有关信息。f.数据安全保密设计。5.3.2.2明确软件开发工具及支持软件a.数据库管理系统;b.屏幕生成系统程序c.报表生成系统程序d.连接装配程序e.编译程序f.编辑程序;其他5.3.2.3快速建造原型a.编程规约;b.建立数据库和数据文件c.建立屏幕及总控程序d.编制程序。5.3.2.4模块测试检査软件设计的最小单位模块。测试的主要特性a.模块接口b.局部数据结构c.全局数据对模块的作用和影响d.功能的完整性、有效性e.错误处理能力5.3.2.5组装测试检査模块组裝在一起之间的接口和互相调用问题。其目标是将经过模块测试的模块构成一个设计所要求的软件结构。测试的主要特性a.模块之间的连接b.软件系统及子系统的输入输出处理能力是否达到设计要求;c.容错能力。5.3.2.6编写操作手册和用户手册。5.3.3工作要求5.3.3.1利用开发工具快速建造原型5.3.3.2利用基本满足系统需求的国内开发的软件包作为原型,可提高效率和软件质量。JBr6987-19935.3.3.3用户一定要直接和开发人员一起进行工作,包括系统原型的建造、运行和测试工作。5.3.4交付文档5.3.4.1软件设计说明书。5.3.4.2软件系统源程序清单。5.3.4.3操作手册。5.3.4.4用户手册5.3.5推荐使用的测试方法与措施a.黑箱、白箱测试法,以及基于两者间的灰盒测试法等b.可进行动态和静态测试;c.组织测试小组,负责测试、记录和分析工作。5.4评审系统原型5.4.1任务这一阶段是整个开发过程的关键。用户和开发人员一起对刚完成的或经过若干次修改后的原型系统进行评审,提岀完善意见。在这个阶段用户是主角。用户通过亲自使用这个系统,了解自己对系统的需求到底是什么,更能发现系统存在的问题,开发者也能更清楚地了解用户的意图,从而开发的最终系统符合用户需求。5.4.2主要工作内容5.4.2.1演示原型系统a.制订演示原型系统计划b.准备演示操作数据;c.按计划进行演示d.评价和收集评价意见5.4.2.2确认测试与评价测试的主要内容系统的功能确认测试测试和评价软件满足系统需求说明书要求程度系统的验收测试验证在实际运行环境的条件下,软件是否满足系统需求说明书的要求负荷能力测试证明程序是否在短时间内处理大量数据性能测试检查系统是否满足指定性的性能指标配置证明程序所需配置的各种情况的可达到性;恢复证明岀现程序错误、硬件失效及数据输入错误后,系统恢复工作的功能是否正常;安全性。5.4.2.3测试基本步骤a.制订详细的测试计划及测试规程说明书b.执行测试(包括修改及测试);c.记录并分析测试结果;d.分析确定系统测试与用户需求差异,提岀修改/补充意见;e.补充制订修改/增补需求说明书。JBr6987-19935.4.2.4结论a.提出测试结果和评审意见b.如果经过评审后,系统为用户所接受,系统原型就作为目标系统,系统开发结束,转到开发结束阶段c.如果系统原型不被用户接受,就要按开发顺序往下一阶段进行。5.4.3工作要求5.4.3.1在原型系统的测试和评审期间,以用户为主,由用户操作系统。5.4.3.2开发人员要详细记录评审意见。5.4.3.3对原型系统的评审,要以用户软件需求说明书为主,防止无休止的争论。5.4.4交付文档5.4.4.1软件需求说明修改意见。5.4.4.2项目计划修改意见5.5系统原型完善化5.5.1任务根据在评审阶段,用户对实际的原型系统提供新的要求,或者提出了原型系统中存在的问题,开发人员就要根据用户的意见对原型系统进行修改、扩充和完善,最终达到满足用户需求。5.5.2主要工作内容5.5.2.1重新设计或补充设计a.确定新的用户软件需求b.确定修改/完善功能模块;c.制订实施计划;d.制订测试计划。5.5.2.2修改完善原型a.修改补充编程规约b.修改/完善数据库和数据文件;c.修改/完善屏幕;d.修改完善控制程序;e.修改/完善程序。5.5.2.3测试主要进行模块测试和组装测试,主要内容:a.重点测试、修改和补充部分;b.模块测试同第5.3.2.4条c.组装测试同第5.32.5条5.5.2.4评审原型系统a.重点评审新的需求及修改完善部分b.转到第54条(用户和开发人员评审原型系统5.5.2.5修改操作手册和用户手册。JBr6987-19935.5.3工作要求5.5.3.1开发人员在对原型系统进行修改完善后,要转到前面第四个阶段,即和用户一起完成系统评审。5.5.3.2评审结果不满足用户需求,则回到第五阶段,对原型系统完善化。5.5.3.3对原型系统要多次反复进行修改完善、评审。5.6结束5.6.1任务经过用户评审,该系统符合需求,则可以使开发的软件系统投入运行,并进行维护。要保证系统尽快地安全、可靠的运行,随时发现问题要及时修正、完善目标系统。5.6.2主要工作内容5.6.2.1系统投入运行a.制订操作规程填写运行记录;c.提交软件问题报告。5.6.2.2系统维护a.根据软件问题报告,软件维护人员向管理人员提交”软件修改报告b.制订修改计划c.维护成本估计d.修改∫充实施e.测试f.修改所有有关文件及资料原型与修改完善后的软件资料归档5.6.2.3系统鉴定与验收5.6.3工作要求5.6.3.1数据整理和录入工作要提前进行。5.6.3.2现行系统要分期尽快转换为目标系统。发现问题及时解决。5.6.4交付文档5.6.4.1软件问题修改报告及软件修改报告。5.6.4.2最终的用户手册、操作手册和软件设计说明书。5.6.4.3项目开发总结报告6文档编制说明文档是MIS系统的重要组成部分,也是系统开发和维护的重要保证,因此需严格管理。原型法开发系统对文档要求不象生命周期法那样严格,但几个主要文档需要编制,其中有的文档要随时修改,以便与开发的系统原型相一致。JBr6987-1993本标准共列出十种文档,下面列表说明开发阶段及交付文档之间的对应关系。开发阶段交付文档可行性研究与规划可行性研究与规划报告[见附录A(参考件)初步的项目开发进度计划软件基本需求说明书[见附录B(参考件)、附录C(参考件)]系统基本需求分析修改项目开发计划确认的测试计划软件设计说明书[见附录D(参考件)]快速建造和运行系统原型软件系统源程序清单操作手册用户手册软件需求说明修改意见项目计划修改意见评审系统原型软件问题修改报告及软件修改报告[见附录E(参考件)、附录F(参考件)]最终的用户手册、操作手册和软件设计说明书项目开发总结报告注:由于本标准是生命周期法的补充与完善,很多文档可参阅已公布的有关标准文档格式。表中没有列岀附录说明的文档,可参阅《企业管理信息系统开发规范》(试行)中有关文档编制说明一节11JBr6987-1993附录可行性研究与规划报告内容提要(参考件)A1引言A2系统建设的背景、必要性和意义A2.1现行系统分析摘要。A2.2需求调查和分析A2.3需求预测A3拟建系统的候选规模及方案A3.1拟建系统的目标A3.2系统的建设规模和初步设计方案。A3.3系统实施计划A3.4投资方案A3.5人员培训及补充方案。A3.6其他A4选择系统原型及其评价如果有类似系统需求的原型系统,用户可以对其进行可用性评价,主要评价内容A4.1功能比较评价。A4.2实现功能的方法评价。A4.3系统的易操作、易使用性评价。A5可行性研究对候选方案进行可行性分析及比较研究。A5.1技术可行性。A5.2经济可行性A5.3运行可行性A5.4几种方案的比较研究A6建设性结论JBr6987-1993附录软件基本需求说明书内容提要(参考件)B1引言B1.1摘要B1.1.1系统的名称、目标和主要功能B1.1.2软件需求分析的目的和主要任务B1.1.3软件需求分析的组织方式和承担者。B1.2背景B1.2.1软件需求分析的依据B1.2.2软件需求分析的条件和限制B1.2.3项目计划的主要变动事项B1.3参考与引用资料。B1.4专门术语的定义B2软件需求规定B2.1基本功能规定B2.2基本性能规定。B2.3输入输出要求B2.4数据管理能力要求。B2.5处理故障要求B2.6其他B3运行环境规定B3.1设备。B3.2支持软件。B3.3接口B3.4控制。B4数据要求说明B4.1数据的逻辑描述。B4.2数据约定B4.3数据的采集。B5目标系统的逻辑模型B5.1总体结构B5.1.1目标系统的总体逻辑结构JBr6987-1993B5.1.2子系统划分与功能定义;B5.1.3子系统之间的关联与定义B5.1.4数据组织与分类B5.1.5目标系统与外部环境接口定义。B5.2子系统描述B5.2.1功能模块的划分与定丶B5.2.2代码设计B5.2.3输出设计B5.2.4输入设计;B5.2.5文件和数据库设计。B6系统可靠性设计B7目标系统运行环境B7.1硬件系统结构。B7.2硬设备。B7.3通讯和网络软硬件。B7.4系统软件和应用软件。JBr6987-1993附录系统需求分析有关参考表格(参考件)C1系统分析报告表格式系统分析报告表SAOI系统名称部门名称设计审核日期JBr6987-1993C2职能部门组织机构调查表格式职能部门组织机构调查表SA02系统名称部门设计:审核日期下设机构责人职能简述JBr6987-1993C3部门相关图表格式部门相关图表SAO系统名称部门设计:审核日期JBr6987-1993C4业务调查表格式业务调查表SAO4系统名称部门设计:审核日期编号业务名称负责人业务内容JBr6987-1993C5业务数据流程图表格式业务数据流程图表SAOS系统名称部门设计:审核日期业务名称JBr6987-1993C6业务处理活动描述表格式业务处理活动描述表SA06系统名称部门设计:日期业务名称输入数据流输出数据流业务处理活动描述JBr6987-1993C7数据流描述表格式数据流描述表SA07系统名称部门设计:审核日期编号名称数据项编号JBr6987-1993C8物流图表格式物流图表SAOS系统名称子系统名称:设计:审核日期JBr6987-1993C9原始单据/凭证/帐册/报告一览表格式原始单据/凭证/帐册/报告一览表SA09系统名称部门设计:审核日期序号名称发生频度保存时间来源部门门JBr6987-1993C10系统结构图表格式系统结构图表(建议)SA1O系统名称部门设计:审核日期JBr6987-1993CI1系统信息相关图表格式系统信息相关图表SAl系统名称部门设计:审核日期JBr6987-1993C12系统分析报表中各表用途说明C12.1SA01的用途简单概括地描述一下相应部门的业务情况、现行系统存在的问题以及用户迫切希望计算机做些什么工作。SAO1的填写在系统名称后,填写所要开发的软件系统的名称。在SA01处填写内容如下SAOI填写SA01本张表的顺序号填写表格SAOI的总张数在部门名称后,填写所描述的部门名称在设计后,填写设计人姓名;在审核后,填写审核人姓名在日期后,填写编表日期;表末一行为开发单位名称和全部表格资料的汇总编号;中间空白区域用来填写正文C12.2SA02的用途描述各职能部门的內部机构设置,并对各专业机构的职能给予简要概括的描述。SA02的填写在描述职能部门的内部机构设置时,建议用图来表示。例如:企管办C12.3SA03的用途用图形的方式来描述某职能部门与其他部门的业务联系和信息传递关系。SA03的填写在填写时,建议用表示职能部门表示两个部门的关系两个部门间的传递信息可以顺箭头方向来表明。例如企管办设备科设备能力年季计划生产科生产作业计划库存情况JBr6987-1993C12.4SA04的用途概述一个职能部门的业务情况C12.5SA05的用途用DFD( Data Flow Diagram)来描述某部门的业务流程SA05的填写DFD的主要符号外部实体指系统外部的人及组织,是系统数据和信息的基本供应者或者最后接收者数据流传送数据元素或者数据结构的通道;处理过程输入数据流变成输岀数据流的转换;□数据存贮系统中的临时存贮,处理过程可以向这些存贮中加入数据,亦可以从这些存贮中得到数据数据收集( Collectors)将分开的比较详细的数据流合到一起,形成一个单个的、更加综合的或者更高一级的数据流继续传送,无处理和转换;>>数据分解( router)与数据收集功能相反C126SA06的用途对SA04中描述的某部门的所有业务分别进行比较详细的文字描述。SA06的填写输入数据流为该业务处理活动的输入数据存贮;输岀数据流为该业务处理活动的输岀数据存贮。C12.7SA07的用途描述业务流程图中的输入数据项、输岀数据项C12.8SA08的用途描述某部门物流的过程(亦即工艺过程)。SA08的填写用图示的方法表示C12.9SA09的用途对在某部门发生的原始单据、凭证、帐册、报告的一些基本特性逐一进行登记描述,为进行系统设计时便于査阅,提供可靠的依据。C12.10SA10的用途向用户提供一新系统的建议结构图。SA10的填写用框图采取树形结构来填写。C12.11SA11的用途描述建议的新系统的信息关联图。SAl1的填写用通用的模板符号来填写。JBr6987-1993附录D系统设计有关参考表格(参考件)D1系统设计报告表格式系统设计报告表SDOl系统名称子系统名称设计审核日期JBr6987-1993D2系统结构图表格式系统结构图表SDO2系统名称子系统名称:设计:审核日期JBr6987-1993D3系统信息相关图表格式系统信息相关图表SDO3系统名称子系统名称:设计:审核日期JBr6987-1993D4处理流程图表格式处理流程图表SDO4系统名称子系统名称:设计:审核日期处理名称JBr6987-1993D5处理描述表格式处理描述表SDOS系统名称子系统名称:设计:审核日期处理名称输入描述处理描述输出描述JBr6987-1993D6数据集合描述表格式数据集合描述表SDO6系统名称子系统名称设计:审核日期编号名称数据项JBr6987-1993D7输入描述表格式输入描述表SDO系统名称子系统名称:设计:审核日期输入凭证名称数据名称解释JBr6987-1993D8输入原始凭证一览表格式输入原始凭证一览表SDOS系统名称子系统名称:设计:审核日期序号名称发生频度保存时间来源部门去向部门JBr6987-1993D9输出报告描述表格式输出报告描述表SDo9系统名称子系统名称:设计:审核日期报告名称报告编号JBr6987-1993D10光屏描述表格式光屏描述表SDIO系统名称子系统名称:设计:审核日期光屏名称光屏编号JBr6987-1993D11输出报告/光屏一览表格式输出报告/光屏一览表SDI系统名称子系统名称:设计:审核日期报告总数报告/光屏名称格式编号份数|输出方式制表周期送交部门JBr6987-1993D12代码设计表格式代码设计表SD12系统名称子系统名称:设计:审核日期名称格式意义JBr6987-1993D13文件描述表格式文件描述表SDI3系统名称子系统名称:设计:审核日期文件英文名文件中文名记录期望数存储方式文件容量:层号数据场英文名键值关连键类型长度数据场中文名说明JBr6987-199314文件一览表格式文件一览表SD14系统名称子系统名称设计:审核日期序号文件中文名称文件英文名称存储方式记录长度期望记录数JBr6987-1993D15程序描述表格式程序描述表SDI5系统名称子系统名称:设计:审核日期程序名称程序编号功能模块编号输入文件输出文件调用程序程序处理描述JBr6987-199316系统屏幕逻辑图表格式系统屏幕逻辑图表SD16系统名称子系统名称:设计:审核日期JBr6987-1993D17系统设计报表用途说明D17.1SD01的用途描述系统的目标、功能及采用旳主要模型和算法及其他存在系统的接口等。D17.2SD02的用途用图的方式、以树形结构描述系统的子系统划分和各子系统的模块构成及其关系。D17.3SD03的用途用图表示系统与其他系统之间的信息关系及子系统之间的信息关系。D17.4SD04的用途描述各功能模块(程序)的处理流程。D17.5SD05的用途用于描述一个处理活动的输入数据流、输岀数据流和处理活动旳算法、公式等。D17.6SD06的用途登记描述每一数据流中所含的所有数据项名称,为详细设计文件提供依据。17.7SDO7的用途描述原始单据的数据项定义及用途D17.8SD08的用途子系统输入原始数据清单。D17.9SD09的用途描述输出报告的要求、格式D17.10SD10的用途用于描述屏幕显示信息。D17.1SD1l的用途用于描述输出报告/光屏显示信息。D17.12SD12的用途描述系统的统一代码设计及子系统的专用代码设计,便于系统规范化、一致化。D17.13SD13的用途描述子系统中各文件的属性。D17.14SD14的用途文件一览表便于查阅。D17.15SD15的用途功能模块或程序的详细设计D17.16SD16的用途描述系统屏幕的逻辑关系,反映子系统及其之间的调用关系。JBr6987-1993附录E软件问题报告(参考件)E1软件问题报告表格式软件问题报告表登记号:a软件问题报告登记日期:b时间:cd单元测试口组装测试口状态e16确认测试口运行维护口姓名报告人地址电g问题程序口数据库口文件子程序/子系统h修订版本号:i磁带数据库文件测试用例m硬件问题描述/影响附注JBr6987-1993软件问题报告表”中各项含义解释登记号由软件配置控制部门为该报告规定一个唯一的、顺序的编号。b登记日期软件配置控制部门登记该报告的日期。问题发现日期发现该问题的日期和时间。d活动在哪个阶段发现的问题,分为单元测试、组装测试、确认测试和运行维护四个阶段。e状态这是在软件配置记录中维护的动态指示。它在”软件问题报告”中的作用是为了让开发者和测试者追溯和向软件配置控制部门报告最新的状态。状态表示如下1—“软件问题报告”正被复查,以确定采用什么行动;软件问题报告”已由指定的开发人员去进行处理3-——修改已做完,测试好,正准备交给主程序库4—主程序库已经更新,主程序库修改的重新测试尚未完成5—测试重做,问题仍存在;6测试重做,所做的修改无故障〃软件问题报告”被关闭7—留待以后关闭,因问题不是可重产生的,或者是属于产品改善方面的,或者只具有很低的优先级等f报告人〃软件问题报告”填写者的姓名、地址、电话。问题属于哪一方面区分是程序的问题还是子程序的问题,或是数据库的问题、文件的问题,也可能是它们的某种组合。h子程序/子系统出现问题的子程序的名字。如果不知是哪个子程序,可标岀子系统名。总之,尽可能给出细节。修订版本号出现问题的子程序版本。j磁带包含有问题的子程序的主程序库磁带的标识符。k数据库当发现问题时所使用的数据库标识符。1文件号有错误的文件编号。测试用例出现错误的主要测试用例的标识符硬件发现问题时所使用的计算机系统的标识。o问题描述影响问题征兆的详细描述,如果可能则写眀实际问题所在。也要给岀该问题对将来测试、接口软件和文件等的影响p附注记载补充信息。JBr6987-1993附录F软件修改报告(参考件)FI软件修改报告表格式软件修改报告表登记号:a软件修改报告登记日期:b时间报告人:d子系统名:e子程序名:f响应哪些“软件问题报告”gh修改程序口文件口数据库口解释口修改描述:i批准人j修改语句类型:kO口计算口逻辑口数据处理口程序名:1老版本号:m新版本号:n数据库:o数据库修改报告:p文件:q文件更新:r修改已测试否?成功否:s单元子系统组裝认运软件问题报告″的问题叙述准确否:t是口否附注:u问题来自:v软件需求说明书口设计说明书口数据库口程序口资源估计:w人时数计算机时间JBr6987-1993〃软件修改报告”中各项含义解释登记号它是软件配置控制部门在收到”软件修改报告”时指定的”软件修改报告″的编号。b登记日期软件配置控制部门登记”软件修改报告”的日期。c时间准备好”软件修改报告”的时间。d报告人填写该报告的作者子系统名受修改影响的子系统。f子程序名被修改的子程序名字。g“软件问题报告”的编号被”软件修改报告”处理或部分处理的″软件问题报告″的编号。如果某“软件问题报告”的问题只是部分解决,则在编号后附以字母P,如1234(Ph修改包括程序修改、文件更新、数据库修改或它们的组合。如果该″软件修改报告”对″软件问题报告”的处理只需做解释性工作,这里将指出。解释多半是针对用户文件的缺陷,但这也将导致用户文件更新。修改描述修改的详细描述。如果是文件更新或数据库修改,还要列岀文件更新通知或数据库修改申请的标识号批准人批准人签字,正式批准进行修改。k语句类型程序修改中涉及到的语句类型,包括:输入输岀语句类、计算语句类、逻辑控制语句类、数据处理语句类(如数据传送、存放语句)程序名被修改的程序、文件或数据库旳名字。如果只要求″软件修改报告″做解释性工作,则是重复”软件问题报告”中给出的名字。老版本号当前的版本修订本标识。n新版本号修改后的新版本/修订本标识。o数据库如果申请数据库修改,这里给出数据库的标识符。JBr6987-1993数据库修改报告数据库修改申请号q文件如果也要求文件修改,这里给出它的名字文件更新文件更新通知单编号。修改是否已测试指出已对修改做了哪些测试,如单元、子系统、组装、确认和运行测试等,并注明测试成功与否。t“软件问题报告”的问题是否叙述准确软件问题报告”给出问题的准确叙述与否,回答是或否。问题注释准确地重新叙述要维护的问题。附加说明本标准由全国工业自动化系统标准化技术委员会提出并归口。本标准由北京机械工业自动化研究所负责起草本标准主要起草人马秀彬、胡自新。閂中华人民共和国机械行业标准制造资源计划MRPⅡ系统原型法软件开发规范机械科学研究院出版发行机械科学研究院印刷北京首体南路2号邮编100044)开本880×12301/16印张3字数98.0001994年4月第一版1994年4月第一次印刷印数价21.00元编号1428机械工业标准服务网:htp:/www.JB,accn

论文截图
版权:如无特殊注明,文章转载自网络,侵权请联系cnmhg168#163.com删除!文件均为网友上传,仅供研究和学习使用,务必24小时内删除。