软件开发过程规范20160804.doc

北京伊瑞德森科技有限公司软件开发规范 发布日期: 2013年12月1日 实施日期: 2013年12月1日第一部分 软件需求分析规范1、引言本规范规定了软件需求分析阶段的任务、过程和相关要求，以及需求分析阶段的完成标志。它是软件开发规范的组成部分。本规范适用于软件需求分析阶段的所有任务和相关人员，包括项目管理人员、软件需求分析人员、文档编制人员和质量审核人员。2、引用标准2.1 GB/T 8566-2007 信息技术 软件生存周期过程2.2 GB8567-2006计算机软件文档编制规范2.3 GB/T 9385-2008计算机软件需求说明规范2.4 GB/T 9386-2008 计算机软件测试文档编制规范2.5 GB/T11457-2006 信息技术 软件工程术语2.6 GB/T 14394-2008 计算机软件可靠性和可维护性管理3、术语本规范的术语和定义与GXB 01-001软件工程术语中的定义相一致。4、需求分析的任务和过程4.1需求分析任务确定被开发软件的运行环境、功能、性能和数据需求，建立确认测试准则，编写用户手册，为概要设计提供需求说明书。4.2需求分析过程需求分析过程由下列步骤组成：1）确定需求分析方法和工具；2）人员培训；3）确定需求分析输入；4）需求分析；5）制定确定测试计划；6）修改开发计划；7）编制文档；8）需求分析审查；9）需求分析文档存档。5、总体要求5.1用户参与软件需求分析应该有客户指定的人员参加。5.2用户确认需求说明必须明确，经过客户同意，并用合同的方式予以确认。5.3面向用户描述需求应以用户能够理解的形式和术语描述需求，以利于与用户沟通。6、需求分析流程6.1确定需求分析方法和工具选定合适的需求分析方法，在一个软件项目内所用的分析方法应该保持一致性。候选分析方法：1）结构分析方法，包括面向数据流的分析方法和面向数据结构的分析方法。2）面向对象的分析方法。在需求分析方法选定后，应确定支持该方法的工具。在一个软件项目内，需求建模语言和工具应该保持一致性和规范化。 6.2人员培训针对所选定的设计方法和工具，以及相关的标准对需求人员进行相应的培训。这是一个可选项，但对于新的方法和工具，或新的分析人员，培训是必需的。6.3确定需求分析输入需求分析的输入一般包括下列类型的资料：1）可行性研究报告；2）项目开发计划；3）相关的用户资料，例如，用户工作手册、相关行业的技术规范、相关的法律文件等；4）现有同类系统的资料；5）软件需求分析相关的标准化文件，如：软件需求分析规范；软件需求说明书规范；测试规范等。6.4需求分析需求分析包括下列类型的活动：1）初步需求获取初步需求获取可采用以下方式：访谈和会议。分析人员以个别访谈或小组会议的形式开始与用户进行初步沟通。精心准备一系列问题，通过用户对问题的回答获取问题及环境的知识，逐步理解用户对目标软件的要求。. 观察用户工作流程。实际观察用户现存的操作过程，从中发现用户需求，并经过分析，剔除不合格的需求，提出新的潜在需求。考察现有的同类软件的运行。如果存在同类的软件系统，对其运行进行考查，描述其逻辑模型，作为目标系统的参考。用户和开发人员共同组成软件研发小组。用户作为分析人员参加软件研发小组。软件研发小组应制定自己的工作制度和计划，确定专门的记录员，另设专人负责资料的综合和整理。 2）需求建模分析活动的焦点是建立目标软件系统的模型。分析过程实质上是软件模型的建造和不断完善的过程。软件模型用来刻画系统涉及的信息、处理功能和实际运行时的外部行为。应该用图形记号分别表示信息流、处理功能和系统行为，并利用受限的自然语言给出用户需求的描述。模型的表示机制应具备良好的结构化能力。3）需求评审 应对需求说明书对进行严格、仔细的评审，对评审过程中发现的错误或缺陷，及时进行修正和补充。重新进行相应部分的初步需求分析，需求建模，修改需求说明书，并重新进行评审。 需求评审应以用户、分析人员和系统设计人员共同参与的会议形式进行，对需求说明书的下列特性进行评价：正确性、无歧义性、完全性、可验证性、一致性、可理解性，可修改性和可追踪性。6.5制定确认测度计划需求分析完成后，应制定相应的确认测度计划。关于确认测试的规定参见相关测试规范。6.6修改开发计划需求分析完成后，将对系统目标和规模有了更全面和详细的了解。因此，应对开发计划进行修改，以使开发计划切实可行。6.7编制文档按标准的文档格式编制下列文档：1）软件需求说明书；2）数据需求说明书（可包含在软件需求说明书中）；3）确认测试计划：4）修改的开发计划；5）用户手册概要。6.8需求评审需求评审包括两个方面：1）文档审查，对6.7节列出的各类文档进行审查，以保证文档的正确性，并且文档格式标准。2） 需求分析过程审查，以检查需求分析过程是否符合开发规范。6.9需求分析文档存档需求分析文档审查通过后，文档编制人、质量审核员、审查组负责人签名。然后由项目负责人或公司相关负责人复审，复审通过后签名。最后将文档交管理部存档，进入配置管理程序。 软件需求说明书通过审查和复审后，应与用户就相关内容签订合同。合同与软件需求说明书一起存档。7、需求分析完成标志所有指定的文档齐全，通过复审，并提交软件开发部。提交的文档包括：1）软件需求说明书；2）数据需求说明书（可包含在软件需求说明书中）；3）确认测试计划；4）修改的开发计划；5）用户手册概要。 第二部分 软件概要设计规范1、引言本规范规定了软件概要设计阶段的任务、过程和相关要求及该阶段的完成标志。它是软件概要设计阶段所有任务和所有相关人员，包括项目管理人员、软件设计人员、软件测试人员、文档编制人员和质量审核人员。 2、引用标准2.1GB8566-88 计算机软件开发规范2.2ISO/IEC 12207:1995 信息技术软件生存周期过程2.3GXB 02-001 软件开发规范： 第一部分 软件生存周期2.4GXB 01-001 软件工程术语2.5GXB 02-007 软件测试规范3、术语本规范的术语的定义与GXB 01-001软件工程术语中的定义相一致。4、概要设计任力和过程4.1概要设计任务依据软件需求说明，建立目标系统的总体结构和模块间的关系；定义模块的接口；设计数据库数据结构；设计目标系统的外部接口，包括用户界面；设计系统的安全机制，出错处理机制；定义目标系统的动行；制定组装测试计划；编写文档；概要设计审查和复审。4.2概要设计过程概要设计过程由下列步骤组成：1）确定概要设计方法和工具；2）人员培训；3）确定设计输入；4）概要设计；5）制定组装测试计划；6）修改开发计划；7）编制文档；8）概要设计审查；9）概要设计文档存档。5、总体要求5.1一致性概要设计必须满足软件需求说明书的所有要求，包括所有功能要求、性能要求和其它要求。软件需求说明的变化与软件概要设计的变化必须保持一致。变化不能随意进行，应置于严格的配置管理之下。5.2抽象鉴别系统元素的不同抽象级别，并根据抽象级别建立系统的层次结构。采用自顶向下，逐步求精的方法进行系统的总体结构设计。5.3独立性依据高内聚、低耦合的原则，确定功能模块功能独立且简单。5.4信息隐藏尽可能使操作和数据局部化，严格限制模块外对其内的操作和数据的访问。5.5模块大小适中 保持模块的大小适中。体积太大的模块，往往功能复杂，对于这样的模块，要进行功能分解，划分为多个模块。6、 概要设计流程6.1确定概要设计方法和工具所选定的设计方法与需求分析方法保持一致。这种一致性不仅表现在形式上，而且表现在逻辑联系上。在一个软件项目内所用设计方法应该保持唯一性。候选设计方法：1）结构设计方法，包括面向数据流的设计方法和面向数据结构的设计方法。2）面向对象设计方法。确定支持所选定的方法的工具。工具中的设计描述语言不论是图形的，还是文字的，在一个软件项目中要保持唯一性和规范化。 6.3确定概要设计输入概要设计输入必须是形成文件的，并经过确认。一般有下列资料：1）软件需求说明书，指明软件需求说明书的相关部分。2）相关系统的资料，这是指与目标系统有接口关系的软硬件系统。可能的类型有：硬件运行平台；软件动行环境；数据库管理系统；第三方提供的API；驱动器；软构件库，包括控件、标准类库、标准函数。3）相关的用户资料。4）其它子系统的资料。一个系统可能划分为多个子系统。在该系统中，与目标子系统有接口关系的其它子系统的资料，也应确定为设计输入。 5）软件概要设计相关的标准化文件，例如：软件概要设计规范；软件概要设计说明书规范；测试规范等。6.4概要设计概要设计包括下列活动：1）设计和确定目标系统的总体结构和模块间关系。模块间的关系主要是调用关系和组成关系。对于大型系统，可按软件需求说明将系统分为多子系统，然后为每个子系统定义总体结构，并描述各子系统的接品关系。对于一般系统，可按软件需求定义目标系统的总体结构。2）定义模块的接口 模块的接口包手输入/输出参数，和参数的传递方式。这义模块的接口应标识错误的参数。3）设计数据库/数据结构这里的数据结构指全局数据结构，特别是需要存储在外存储介质的数据结构。4）设计外部接口外部接口机制包括启动或调用方式，参数或信息传递方式，信息格式等方面。用户界面的设计，外部输入/输出信息格式的规定都属于该任务范畴。5）设计安全机制安全机制包括下列方面：a）系统和数据的访问权限和权限鉴别机制；b）数据备份方法；c）系统和数据恢复方法；d）出错处理方法和出错信息包括错误的编号，错误类型，解释性信息，可能的纠错方法； e）预防计算机病毒的方法。6）设计系统的运行系统的运行设计有下列任务：a）确定系统的动行类型：b）规定每类运行的控制和操作；c）指明每类运行覆盖的功能模块。7）确定设计限制明确描述设计的限制。6.5制定组装测试计划目标软件系统的概要设计完成后，应制定相应的组装测试计划。关于组装测试参见相关测试规范。6.6修改开发计划概要设计完成后，将对系统目标和规模有更全面、准确和详细的了解。因此，需要对开发计划进行必要的修改、补充和细化。 6.7编制文档按标准的文档格式编制下列文档：1）概要设计与明书；2）数据库/数据结构设计说明书（可包含在概要设计说明书内）；3）组装测试计划；4）修改的开发计划；5）用户手册；6）操作手册；6.8概要设计审查概要设计审查包括两个方面；1）文档审查，对6.7列出的各类文档进行审查，以确保存概要设计满足所有需求、文档格式符合标准。有关文档审查的详细规定见文档审查规范。2）概要设计过程审查，以栓查概要设计过程是否符合开发规范。 6.9概要设计文档存档概要设计文档审查通过后，文档编制人、质量审核员、审查组负责人签名。然后由项目负责人或公司相关负责人复审，复审通过后签名。最后将文档提交软件开发部存档，进入配置管理程序。7、概要设计完成标志所有指定的文档齐全，通过复审，并提交软件开发部。提交的文档包括：1） 概要设计与明书；2） 数据库/数据结构设计说明书（可包含在概要设计说明书内）；3） 组装测试计划；4） 修改的开发计划；5） 用户手册6） 操作手册。第三部分 软件项目详细设计文档规范 1.0概述 这部分提供对整个设计文档的概述。描述了所有数据，结构，接口和软件构件级别的设计。 1.1 目标和对象 描述软件对象的所有目标。 1.2 陈述范围 软件描述。主要输入，过程功能，输出的描述，不考虑详细细节。 1.3软件内容 软件被置于商业或者产品线中，讨论相关的战略问题。目的是让读者能够对“宏图”有所了解。 1.4主要系统参数 任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范。 2.0数据设计 描述所有数据结构包括内部变量，全局变量和临时数据结构。 2.1内部软件数据结构 描述软件内部的构件之间的数据传输的结构。 2.2全局数据结构 描述主要部分的数据结构。 2.3临时数据结构 为临时应用而生成的文件的描述。 2.4数据库描述 作为应用程序的一部分，描述数据库结构。 3.0结构化和构件级别设计 描述程序结构。 3.1程序结构 详细描述应用程序所选定的程序结构。 3.1.1结构图 图形化描述结构。 3.1.2选择性 讨论其它可供考虑的结构。选定3.1.1中结构类型的原因。 3.2构件描述 详细描述结构中的每个软件构件。 3.2.1构件过程叙述(PSPEC) 描述构件的过程。 3.2.2构件接口描述 详细描述构件的输入和输出。 3.2.3构件执行细节 每个构件的详细演算描述。 3.2.3.1接口描述 3.2.3.2演算模型(e.g., PDL) 3.2.3.3规范/限制 3.2.3.4本地数据结构 3.2.3.5在3.2.3.6设计中包含的执行结果 3.3软件接口描述 软件对外界的接口描述 3.3.1机器对外接口 与其他机器或者设备的接口描述。 3.3.2系统对外接口 对其它系统、产品和网络的接口描述。 3.3.3与人的接口 概述软件与任何人的界面。 4.0用户界面设计 描述软件的用户界面设计。 4.1描述用户界面 详细描述用户界面，包括屏幕显示图标、图片或者类型。 4.1.1屏幕图片 从用户角度描述界面。 4.1.2对象和操作 所有屏幕对象和操作的定义。 4.2界面设计规范 用户界面的设计和实现的规范和标准。 4.3可见构件 实现的GUI可见构件说明。 4.4UIDS描述 用户界面开发系统描述。 5.0约束、限制和系统参数 会影响软件的规格说明、设计和实现的特殊事件。 6.0测试标准 测试策略和预备测试用例描述。 6.1测试的类别 规定实施测试的类别，包括尽量详细的描述。这里是针对黑盒测试现象的描述。 6.2期待软件反馈 测试期待的结果描述。 6.3执行界线 特殊执行需要的说明。 6.4重要构件确认 决定性构件或者需要特殊注意的构件的测试确认。 7.0附录 设计说明的补充信息。 7.1系统可跟踪矩阵 一个定期回归系统规格跟踪软件需求的矩阵。 7.2产品战略 如果规格说明书是为一个产品设计的，描述相关的产品战略。 7.3使用分析算法 描述所有分析活动所使用到的分析算法。 7.4补充信息 (如果有需要特别说明的)。