GB 8566-2007 信息技术软件生存周期过程

GB 8566-2007 信息技术软件生存周期过程
仅供个人学习
反馈
标准编号:
文件类型:.pdf
资源大小:2.9M
标准类别:电力标准
资源ID:40075
免费资源

标准规范下载简介

GB 8566-2007 信息技术软件生存周期过程简介:

GB 8566-2007是中国的国家标准,全称为《信息技术软件生存周期过程规范》,该标准主要规定了软件开发和维护的全过程,包括软件生存周期的各个阶段和相应的管理要求。以下是该标准中主要过程的简介:

1. 需求分析:这是软件开发的第一阶段,主要是明确和理解用户的需求,包括功能需求、性能需求、用户界面需求等。

2. 软件设计:在需求分析的基础上,进行系统架构设计、模块设计和数据设计等,形成详细的软件设计方案。

3. 编码实现:根据设计文档,程序员进行代码编写,将软件从概念转化为实际的可运行程序。

4. 测试:包括单元测试、集成测试、系统测试和验收测试,以确保软件的质量和功能的正确性。

5. 部署与维护:软件部署到实际运行环境后,需要进行运行监控、问题修复和功能升级等工作,保证软件的稳定运行。

6. 维护管理:包括软件的版本控制、文档管理、变更管理、风险管理等,以支持软件的持续改进和优化。

7. 合同管理:涉及与用户、供应商等的合同签订、执行和变更管理。

8. 项目管理:包括项目计划、进度控制、成本控制、质量保证和风险管理等,以确保整个软件开发过程的顺利进行。

GB 8566-2007为软件开发提供了标准化的流程和管理方法,对于提高软件开发的质量和效率,保障软件的稳定运行具有重要意义。

GB 8566-2007 信息技术软件生存周期过程部分内容预览:

。应选择本标准的开发过程的活动和任务,并将其映射到生存周期。 注:这些活动和任务可以重叠或相互作用,并且可以重复或循环地进行。 5.3.1.2开发方应: & 按照文档编制过程(6.1)将输出形成文档: b 将输出置于配暨管理过程(6.2)之下,并按照配置管理的要求进行变更控制; C) 按照问题解决过程(6.8),文档化并解决在软件产品和任务中发现的问题和不符合项; d) 按合同规定实施支持过程(第6章); e) 适当时按需方和供方确定的要求为每个配置项建立基线。 5.3.1.3开发方应选择、剪裁和使用那些已形成文档的、恰当的、并由执行开发过程和支持过程(第6章) 的活动的组织建立的标准、方法、工具和计算机编程语言(如果合同没有限定)。 5.3.1.4开发方应为实施开发过程的活动制定开发计划。该计划应包括与包括安全、安全保密性在内 的所有需求的开发、合格性认定相关的特定标准、方法、工具、措施和职责。如果必要,可以制订一些独 立的计划,这些计划应形成文档并得到执行。 5.3.1.5非交付项可用于软件产品的开发或维护。但应确保可交付软件产品在交付给需方后,它的运 行和维护独立于非交付项。否则,这些非交付项应被考虑为可交付的。

5.3.1.2开发方应

5.3.2系统需求分析

下列任务组成Q/GDW 11398-2015标准下载,开发方应按照合同要求执行

5.3.2.1应分析待开发系统的特定的预期使用要求,以规定系统需求。系统需求规格说明应描述:系 统的功能与能力;业务、组织和用户的需求;安全、安全保密性、人因工程(人机工程学)、接口、运行和维 护需求;设计约束和合格性带求。系统需求规格说明应形成文档

a)获取需要的可追踪性: b) 获取需要的一致性; c) 可测试性: d) 系统体系结构设计的可行性; e)运行和维护的可行性。

a)获取需要的可追踪性 b) 获取需要的一致性; 可测试性: d) 系统体系结构设计的可行性: e)运行和维护的可行性。

5.3.3系统体系结构设讯

此项活动由下列任务组成,开发方应按合同要求执行或支持这些任务。 5.3.3.1应建立系统的顶层体系结构。该体系结构应标识硬件、软件和人工操作项。应确保所有系统 需求都被分配到各项中。然后应从这些项中标识出硬件配置项、软件配置项和手工操作项。分配到各 项中的系统体系结构和系统需求应形成文档。

a) 系统需求的可追踪性: b) 与系统需求的一致性; c) 所使用的设计标准和方法的适宜性: d) 软件项满足其分配需求的可行性; 运行与维护的可行性,

5.3.4软件盘求分析

对于每一个软件项(或软件配置项,如巢已标识),此项活动由下述任务组成: 3.4.1开发方应建立软件需求(包括质量特性规格说明)并形成文档。软件质量特性规定见 /T16260.1。软件需求包括: a)功能与能力规格说明,包括性能、物理特性和软件项执行的环境条件; b) 软件项的外部接口, 合格性需求; d) 安全规格说明,包括那些与运行、维护相关的方法、环境影响和人为损坏; 安全保密性规格说明,包括那些与敏感信息泄露相关的要求; 人因工程(人机工程学)规格说明,包括与人工操作、人机界面、对人员的约束、需要人员集中注 意力的区域(这些区域对人为差错和培训是敏感的)等有关的要求; 数据定义和数据库需求; h) 在运行和维护场所安装与验收已交付的软件产品的需求; i) 用户文档; j) 用户操作与执行需求: k 用户维护需求。 .4.2开发方应根据下列评价准则评价软件需求。评价结果应形成文档: 系统需求和系统设计的可追踪性; b) 与系统需求的外部一致性: c) 内部一致性: 可测试性: e) 软件设计的可行性 f) 运行和维护的可行性

GB/T8566—2007

5.3.4.3开发方应按照6.6实施联合证

3开发方应按照6.6实施联合评审

5.3.5软件体系结构设讯

对于每一个软件项(或软件配置项,如果已标识),此项活动由下列任务组成: 5.3.5.1开发方应把软件项的需求转变为一种体系结构,该体系结构描述其顶层结构并标识各个软件 部件。应确保软件项的所有需求都被分配给了其软件部件,并得到进一步的细化以便于进行详细设计。 软件项的体系结构应形成文档。

对于每一个软件项(或软件配暨项,如果已标识),此项活动由下列任务组成: 5.3.5.1开发方应把软件项的需求转变为一种体系结构,该体系结构描述其顶层结构并标识各个软件 部件。应确保软件项的所有需求都被分配给了其软件部件,并得到进一步的细化以便于进行详细设计。 软件项的体系结构应形成文档。 5.3.5.2开发方应开发关于软件项的外部接口以及软件项的各个软件部件间的接口的顶层设计,并形 成文档。 5.3.5.3开发方应编制数据库的项层设计,并形成文档。 5.3.5.4开发方宜编制用户文档的最初版本,并形成文档。 5.3.5.5开发方应确定软件集成的初步测试需求和进度安排,并形成文档。 5.3.5.6开发方应根据下列评价准则评价软件项的体系结构、接口和数据库设计,评价结果应形成 文档: a) 软件项需求的可追踪性; b) 与软件项需求的外部一致性; 软件部件之间的内部一致性; 所应用的设计方法和标准的适宜性; 详细设计的可行性; 运行与维护的可行性

5.3.5.7开发方应按照6.6实施联合评

7开发方应按照6.6实施联合评审。

5.3.6软件详细设计

对于每一个软件项(或软件配置项,如果已标识),此项活动由下述任务组成: .3.6.1开发方应对软件项的每一软件部件进行详细设计。软件部件应细化到更低级别,这些级别 含能被编码、编译、测试的软件单元。应确保来自这些软件部件的所有软件项需求都被分配到软件 元。详细设计应形成文档。 5.3.6.2开发方应开发关于软件项外部接口,软件部件之间以及软件单元之间的接口的详细设计, 等其形成文档。接口的详细设计应允许在不需要更多信息的情况下进行编码。 5.3.6.3开发方应编制数据库的详细设计并形成文档。 5.3.6.4必要时,开发方应更新用户文档。 5.3.6.5开发方应规定要测试的软件单元的测试需求和进度安排,并将其形成文档。测试需求宜包 对软件单元在需求边界的强化要求。 5.3.6.6开发方应更新软件集成的测试需求和进度安排。 5.3.6.7开发方应根据下列评价准则评价软件详细设计和测试需求,评价结果应形成文档: a) 软件项带求的可追踪性; 与结构设计的外部一致性: 软件部件和软件单元之间的内部一致性; 所应用的设计方法和标准的适宜性 e) 测试的可行性; f 运行与维护的可行性。 3.6.8开发方应按照66实施联合评审

对于每一个软件项(或软件配置项,如果已标识),此项活动由下述任务组成: 5.3.6.1开发方应对软件项的每一软件部件进行详细设计。软件部件应细化到更低级别,这些级别包 含能被编码、编译、测试的软件单元。应确保来自这些软件部件的所有软件项需求都被分配到软件单 元。详细设计应形成文档。

5.3.7软件继码和测试

对于每一个软件项(或软件配置项,如果已标识),此项活动由下述任务组成: 7.1开发方应开发下列各项并形成文档:

a) 每一个软件单元和数据库; b) 用于测试每一个软件单元和数据库的测试规程和数据。 3.7.2开发方应测试每个软件单元和数据库,以确保满足需求。测试结果应形成文档。 3.7.3 必要时,开发方应及时更新用户文档。 3.7.4 开发方应及时更新测试需求和软件集成进度安排。 B.7.5 开发方应根据下列准则评价软件编码和测试结果,评价结果应形成文档: 软件项需求和设计的可追踪性; b) 与软件项的需求及设计的外部一致性; c) 单元需求之间的内部一致性: 单元的测试覆盖率; e) 所应用的编码方法和标准的适宜性, f) 软件集成与测试的可行性; 运行与维护的可行性。

CJJ∕T 233-2015 城市桥梁检测与评定技术规范a)每一个软件单元和数据库;

软件项需求和设计的可追踪性; b) 与软件项的需求及设计的外部一致性 c) 单元需求之间的内部一致性. d) 单元的测试覆盖率; 所应用的编码方法和标准的适宜性! f) 软件集成与测试的可行性: 运行与维护的可行性。

对于每一个软件项(或软件配置项,如果已标识),此项活动由下述任务组成: 5.3.8.1开发方应制订一个集成计划,以便将软件单元和软件部件集成到软件项。该计划应包括测试 需求、规程、数据、职责和进度安排。该计划应形成文档。 5.3.8.2开发方应按照集成计划将软件单元和软件部件作为开发的集合体进行集成和测试。应确保 每一集合体满足软件项的需求并且在集成活动终了时软件项已经集成。集成和测试结果应形成文档。 5.3.8.3必要时,开发方应更新用户文档。 5.3.8.4对软件项的每一合格性需求,开发方应开发用于实施软件合格性测试的测试集、测试用例(输 入、输出、测试准则)和测试规程,并将其形成文档。开发方应确保已集成的软件项可用于软件合格性 测试。 5.3.8.5 开发方应根据下列准则评价集成计划、设计、编码、测试、测试结果和用户文档,评价结果应形 成文档

入、输出、测试准则)和测试规程,并将其形成文档。开发方应确保已集成的软件项可用于软件合格性 测试。 5.3.8.5 开发方应根据下列准则评价集成计划、设计、编码、测试、测试结果和用户文档,评价结果应形 成文档: a 系统需求的可追踪性; 与系统需求的外部一致性; c) 内部一致性; 软件项需求的测试覆盖率; e) 所应用的测试标准和方法的适宜性; f) 与预期结果的符合程度; &) 软件合格性测试的可行性; h) 运行与维护的可行性。 5.3.8.6开发方应按6.6实施联合评审。

系统需求的可追踪性; 与系统需求的外部一致性; c) 内部一致性; 软件项需求的测试覆盖率; e) 所应用的测试标准和方法的适宜性: f) 与预期结果的符合程度; g) 软件合格性测试的可行性; h) 运行与维护的可行性。 3.8. 6 开发方应按6.6实施联合评审

5.3.9软件合格性测试

对于每一个软件项(或软件配置项,如果已标识)CJJ 11-2011 城市桥梁设计规范,此项活动由下述任务组成: 5.3.9.1开发方应按照软件项合格性需求实施合格性测试。应确保针对依从性对每一软件需求的实 现进行测试,合格性测试结果应形成文档。 5.3.9.2必要时,开发方应更新用户文档,

©版权声明
相关文章