下载文档原格式
华为的项目策划书华为的项目策划书华为技术有限公司是一家生产销售通信设备的民营通信科技公司，总部位于中国广东省深圳市龙岗区坂田华为基地。
华为的产品主要涉及通信网络中的交换网络、传输网络、无线及有线固定接入网络和数据通信网络及无线终端产品，为世界各地通信运营商及专业网络拥有者提供硬件设备、软件、服务和解决方案。
华为于1987年在中国深圳正式注册成立。
一、产品品牌1、华为品牌：全球领先的电信解决方案供应商，专注于与电信运营商建立长期的合作伙伴的关系。
拥有热诚的员工和强大的研发能力，快速响应客户需求，提供客户化的产品和端到端的服务。
2、华为品牌的命名：华为手机目前的子品牌有三类，致力于低端市场的华为品牌，着眼中低端市场的荣耀以及放眼中高端市场的Ascend。
产品市场定位明确。
二、产品的定位1、商务型消费者的市场定位：商务型消费者需要处理的信息相对较多，而且手机的外显性比较强，所以既注重产品的功能，也注重产品的造型、外观。
还有商务人员出差的时间比较多，所以对电池的续航时间也要求比较高。
因此，华为手机在商务型消费者的市场定位要主要考虑功能、外观、续航三个方面。
2、大学生消费者的市场定位：大学生具有年轻人喜欢娱乐、交流、追求时尚的个性，在娱乐功能上比较注重一些技术含量高的功能，比如说个性化的铃声、图片处理、游戏、音乐等;大学生喜欢交流，所以需要超强的信息功能;大学生的主要任务还是学习，他们对一些学习方面的功能还是有所需求的，例如金山词霸、英汉互译词典、计算器、文档、公示等等;还有大学生喜欢运动、外出游玩，所以他们对手机防尘、防水、防摔有一定的要求。
因此，华为手机在大学生消费者的市场定位主要是根据大学生的需求，定制专业性的手机。
二、产品的包装1、承重抗摔、防水、防尘2、个性、时尚三、产品的售后服务1、提供保修：①售后网点维修②快递返厂维修③上门现场维修(维修人员上门维修时，携带一部备用机，如果无法现场修复手机而需要带回售后代理维修时，这部备用机可以暂时提供给用户作为临时手机使用，以免耽误用户用机)④提供包换(十五天包换)⑤提供包退(七天包退)⑥手机在售后服务中的期间费用有华为公司承担.(二)价格即根据不同的市场定位，制定不同的价格策略，产品的定价依据是企业的品牌战略，注重品牌的含金量。
华为Eudemon配置文档Eudemon防火墙的双机热备份需要三个协议的支持：VRRP（Virtual Router Redundancy Protocol）是由RFC2338定义的一种容错协议，通过实现物理设备和逻辑设备的分离，实现在多个出口网关之间进行选路。
VGMP（VRRP Group Management Protocol）是华为公司为防止VRRP状态不一致现象的发生，在VRRP的基础上自主开发出的扩展协议。
该协议负责统一管理加入其中的各备份组VRRP的状态。
HRP（Huawei Redundancy Protocol）协议用来进行防火墙的动态状态数据的实时备份。
此配置文档适用于不支持VGMP的Eudemon系统版本，该系统默认有master 和slave两个管理组，master用于管理主防火墙VRRP备份组，slave用于管理备防火墙VRRP备份组，主要区别体现在它们的优先级上。
一、Eudemon双机配置的二个步骤如下：1、接口划分和VRRP备份组配置[Eudemon]firewall zone trust[Eudemon-zone-untrust] add interface GigabitEthernet0/0/0[Eudemon]firewall zone untrust[Eudemon-zone-untrust] add interface GigabitEthernet5/0/0[Eudemon]firewall zone dmz[Eudemon-zone-dmz] add interface GigabitEthernet0/0/1[Eudemon-zone-dmz] add interface GigabitEthernet6/0/0注：Eudemon防火墙默认有四个区域，local（本机）、untrust（连接外网）、trust （连接内网）、dmz（中立区），安全级别系数分别是100、5、85、50，这四个默认区域不能删除，也不能修改安全级别系数；并且四个区域默认是不允许所有IP 进行互访的。
数据仓库服务(DWS) 8.1.3.310API参考文档版本01发布日期2023-03-30版权所有 © 华为云计算技术有限公司 2023。
保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
商标声明和其他华为商标均为华为技术有限公司的商标。
本文档提及的其他所有商标或注册商标，由各自的所有人拥有。
注意您购买的产品、服务或特性等应受华为云计算技术有限公司商业合同和条款的约束，本文档中描述的全部或部分产品、服务或特性可能不在您的购买或使用范围之内。
除非合同另有约定，华为云计算技术有限公司对本文档内容不做任何明示或暗示的声明或保证。
由于产品版本升级或其他原因，本文档内容会不定期进行更新。
除非另有约定，本文档仅作为使用指导，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。
目录1 使用前必读 (1)1.1 概述 (1)1.2 调用说明 (1)1.3 终端节点 (1)1.4 基本概念 (1)2 API概述 (3)3 如何调用API (5)3.1 构造请求 (5)3.2 认证鉴权 (8)3.3 返回结果 (9)4 快速入门 (11)5 API说明 (17)5.1 集群管理接口 (17)5.1.1 创建集群 (17)5.1.2 查询集群列表 (22)5.1.3 查询集群详情 (29)5.1.4 查询节点类型 (37)5.1.5 删除集群 (39)5.1.6 重启集群 (41)5.1.7 扩容集群 (42)5.1.8 重置密码 (44)5.1.9 集群工作负载管理 (46)5.1.9.1 查询工作负载管理计划列表 (46)5.1.9.2 查询工作负载管理计划 (49)5.1.9.3 切换工作负载计划阶段 (52)5.1.9.4 启动工作负载计划 (53)5.1.9.5 停止工作负载计划 (55)5.2 快照管理接口 (56)5.2.1 创建快照 (56)5.2.2 查询快照列表 (58)5.2.3 查询快照详情 (60)5.2.4 删除手动快照 (63)5.2.5 恢复集群 (64)5.3 数据库监控管理接口 (67)5.3.1 查询DWS集群状态 (67)5.3.2 查询DWS集群中数据库使用情况 (72)5.3.3 查询DWS集群各节点磁盘IO使用情况 (74)5.3.4 查询DWS集群各节点磁盘IO使用情况（聚合类型） (77)5.3.5 查询DWS集群各节点文件系统使用情况 (81)5.3.6 查询DWS集群各节点文件系统使用情况（聚合类型） (83)5.3.7 查询DWS集群节点各网卡流量 (87)5.3.8 查询DWS集群查询执行情况 (90)5.3.9 查询DWS集群会话执行情况 (94)5.3.10 查询DWS硬件资源使用情况 (96)5.3.11 查询DWS集群硬件资源使用情况（聚合类型） (99)6 附录 (103)6.1 状态码 (103)6.2 错误码 (105)6.3 创建VPC (113)6.4 获取资源集ID (113)6.5 获取租户ID (114)6.6 获取集群ID (114)6.7 获取Endpoint (115)1使用前必读1.1 概述欢迎使用数据仓库服务GaussDB(DWS)。
软件开发行为规范第一版深圳市华为技术有限公司版权所有不得复制软件开发行为规范(第一版）为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。
与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。
对违反规范的开发行为，必须按照有关管理规定进行处罚。
本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。
本软件开发行为规范，采用以下的术语描述：★规则：在软件开发过程中强制必须遵守的行为规范。
★建议：软件开发过程中必须加以考虑的行为规范。
★说明：对此规则或建议进行必要的解释。
★示例：对此规则或建议从正或反两个方面给出例子。
本软件开发过程行为规范由研究技术管理处负责解释和维护。
研究技术管理处目录1 软件需求分析 52 软件项目计划93 概要设计114 详细设计145 编码186 需求管理197 软件配置管理218 软件质量保证239 数据度量和分析251 软件需求分析1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。
1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。
软件需求规格的变更必须经过评审，并保存评审记录。
1-3：必须对软件需求规格文档进行正规检视。
1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。
1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。
说明：参考建议1-1到1-16。
1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。
1-2：采用以下检查表检查软件需求规格文档中需求的完备性。
华为TD模块Linux第三方集成指导文档Catalog 目录1 目的 (2)2 范围 (2)3 简介 (2)4 Linux系统支持华为TD模块设备的集成步骤 (2)4.1 USB cdc-acm内核驱动模块集成步骤 (2)4.2 Linux PPP拨号工具集成步骤 (3)5 在Linux系统上的modem拨号 (4)6 附录 (4)6.1 获取单板当前的端口映射情况信息 (4)1 目的本文档主要针对华为TD模块设备基于Linux系统的集成开发活动进行相关的指导说明。
主要面向第三方软件开发商的集成开发人员。
2 范围本文档主要说明了在Linux系统上支持华为TD模块设备的相关开发工作，及其注意事项。
3 简介要在Linux系统中支持华为TD模块设备，则要求Linux系统必须存在内核驱动模块cdc-acm.ko，PPP协议模块和PPP拨号相关的工具程序。
对于通用的PC Linux系统，如果Ubuntu、RedHat、Fedora、OpenSUSE等系统，其内核系统中默认已经内置有对应的cdc-acm.ko驱动模块和相关的PPP模块文件了，至于拨号管理的功能，建议直接集成华为提供的Linux后台软件来支持。
本文不再作详细说明。
本文将主要说明定制的Linux系统或嵌入式的Linux系统支持华为TD模块设备的集成操作。
4 Linux系统支持华为TD模块设备的集成步骤4.1 USB cdc-acm内核驱动模块集成步骤USB cdc-acm驱动模块，是Linux内核内置的标准的驱动模块。
其源文件在Linux内核代码中的位置为drivers/usb/class/cdc-acm.c，编译后，生成名称为cdc-acm.ko的模块文件，该文件存放于Linux系统/lib/modules/$(uname -r)/kernel/drivers/usb/class目录下。
其具体的集成步骤如下：1、Linux内核编译配置时，需要选中下面蓝色的配置项。
华为代码规范目录1 概述 (5)1.1 编写目的 (5)1.2 文档约定 (5)1.3 预期的读者和阅读建议 (5)1.4 参考文献 (5)2 排版要求 (5)2.1 程序块缩进 (5)2.2 程序块之间空行 (5)2.3 长语句和长表达式 (6)2.4 循环、判断等长表达式或语句 (7)2.5 长参数 (7)2.6 短语句 (8)2.7 条件、循环语句 (8)2.8 语句对齐 (8)2.9 函数、过程和结构等语句块 (9)2.10 程序块分界符 (9)2.11 操作符前后空格 (10)2.12 其他 (11)3 注释 (11)3.1 有效注释量 (11)3.2 公司标识 (11)3.3 说明性文件 (12)3.4 源文件头 (13)3.5 函数头部说明 (13)3.6 注释与代码一致 (14)3.7 注释内容 (14)3.8 注释缩写 (14)3.9 注释位置 (14)3.10 变量、常量注释 (15)3.11 数据结构的注释 (15)3.12 全局变量 (16)3.13 注释缩排 (16)3.14 注释与代码之间空行 (17)3.15 变量定义、分支语句 (17)3.16 其他 (19)4 标识符命名 (20)4.1 命名清晰 (20)4.2 特殊命名需注释 (21)4.3 命名风格保持一致 (21)4.4 变量命名 (21)4.5 命名规范与系统风格一致 (21)4.6 其他 (22)5 可读性 (23)5.1 运算符优先级 (23)5.2 避免直接使用数字作为标识符 (23)5.3 其他 (24)6 变量、结构 (25)6.1 公共变量 (25)6.2 公共变量说明 (25)6.3 公共变量访问说明 (25)6.4 公共变量赋值 (26)6.5 防止局部变量与公共变量同名。
(26)6.6 严禁使用未经初始化的变量作为右值。
(26)6.7 其他 (26)7 函数、过程 (34)7.1 对所调用函数的错误返回码要仔细、全面地处理。
软件开发及文档培训(仅供内部使用)深圳市华为技术有限公司版权所有侵权必究1 软件开发过程介绍华为公司的软件开发过程基本上由以下几个开发过程组成: •系统需求分析过程•系统设计过程•软件需求分析过程•软件概要设计过程•软件详细设计过程•软件编码和单元测试过程•软件集成与集成测试过程•系统集成和系统集成测试过程•系统验收测试过程•软件维护过程图一. 软件开发相关的过程示意图：各软件开发过程中应该输出的文档如下软件开发过程输出文档名称文档模板系统需求分析操作概念文档OCD系统/子系统需求规格书SSSIRS系统/子系统接口需求规格书系统结构设计系统/子系统设计描述SSDDIDD系统/子系统接口设计描述软件需求分析软件需求规格书SRS接口需求规格书IRS软件概要设计软件设计描述SDD接口设计描述IDD数据库设计描述DBDD 软件详细设计2. 软件开发过程详细要求2.1系统需求分析开发者应该根据以下要求参与系统需求分析。
注：如果一个系统分成多个版本开发，可能直到最后一个版本需求才能完全定义。
开发者的计划中应该定义在每个版本中确定的需求子集，每个版本中实现的需求子集。
某个版本的需求分析应该理解为定义那个版本的系统需求。
2.1.1 分析用户的输入开发者应该通过分析用户的输入来理解用户的需求。
这个输入的形式可能是需求报告单、调查、问题/修改报告，原型的反馈，访谈或其他用户或反馈。
2.1.2 操作概念开发者应该参与定义和记录系统的操作概念。
结果应该包括在《操作概念描述（OCD）》文档模板中的所有条目。
2.1.3 系统需求开发者应该参与定义和记录系统应该满足的需求以及验证每个需求已经被满足的方法。
结果应在包括《系统/子系统规格说明书（SSS）》中的所有可能的条目。
根据实际情况，有关系统接口的需求可以在SSS中规定或者在《接口需求规格说明书（IRSs）》中规定。
注：如果一个系统由子系统组成，系统需求分析）中的活动应该同系统设计中的活动叠代进行。
定义系统的需求，设计系统并定义它的子系统，定义这些子系统的需求，设计子系统并定义他们的部件，如此下去。
2.2系统的设计开发者应该按照下列要求参与系统的设计。
注：如果系统分成多个版本开发，系统的设计可能要等到最后一个版本才完成。
开发者的计划中应该定义每个版本中所要完成的设计。
一个特定版本的设计应理解为那个版本中应完成的设计内容。
2.2.1 系统范围的设计决定（System-wide design decisions)开发者应该参与定义和记录系统范围的设计决定（这就是，有关系统运行设计和其它影响到系统部件选择、设计的决定）。
结果应该包括《系统/子系统设计说明书（SSDD）》模板中有关系统范围设计决定的所有内容。
根据实际情况，有关接口的设计可以包括在SSDD中或者《接口设计说明书》中，有关数据库的设计可以包括在SSDD或者《数据库设计说明书（DBDDs）》中。
注：除非在需求中有明确的规定，设计一般由开发者负责。
开发要满足所有的需求并通过系统集成测试来证明需求得到了满足。
2.1.2系统结构设计(System architectural design)开发者应该参与定义和记录系统的结构设计（定义系统的部件，它们的接口，以及它们之间的运行概念）以及系统部件同系统需求之间的跟踪关系。
结果应该包括《系统/子系统设计说明书（SSDD）》中有关结构设计及跟踪性的部分的所有条目。
根据需要，有关接口的设计可以包括在SSDDs或《接口设计说明书》中。
2.3 软件需求分析（Software requirements analysis)开发者应该定义和记录每个CSCI应该满足的软件需求，验证每个需求是否完成的方法，以及CSCI需求同系统需求之间的跟踪关系。
结果应该包括《软件需求规格说明书（SRS）》中所有的条目。
根据需要，CSCIs接口的需求可以包括在SRS中或《接口需求规格说明书（IRSs）》中。
注：如果一个CSCI分成多个版本开发，需求可能要到最后一个版本才能完全定义。
开发者的计划中应该说明每个版本中每个CSCI需求的子集。
2.4 软件设计开发者应该根据以下要求进行软件的设计。
注意：如果一个CSCI分成多个版本开发，可能需要等到最后一个版本才能完全设计完毕。
每个版本的软件设计应该理解为为了实现这个版本的需求而进行的设计。
2.4.1 CSCI范围的设计决定（CSCI-wide design decision).开发者应该定义和记录CSCI范围的设计决定（这就是，有关CSCI的运行设计和其它影响到构成CSCI的软件单元选择和设计的设计决定）。
结果应该包括《软件设计说明书（SDD）》中有关CSCI范围设计决定的所有项目。
根据需要，有关接口的设计内容可以包括在SDD中，也可以安排在《接口设计说明书》中。
有关数据库的设计可以安排在《数据库设计说明书》中。
2.4.2 CSCI结构设计（CSCI architectural design)。
开发者应该定义和记录每个CSCI的结构设计（定义构成CSCI的软件单元，它们的接口，它们之间的运行概念）以及软件单元CSCI需求的跟踪关系。
结果应该包括《软件设计说明书》中有关结构设计及跟踪性的所有项目.根据实际需要，有关接口的设计内容可以包括在《接口设计说明书》中。
注意：如果软件单元又有其它软件单元组成，则CSCI的结构可以根据需要组成多个层次。
例如。
一个CSCI可以被分成三个软件单元，上述每个软件单元又可以分成其他的软件单元，如此下去。
2.4.2 CSCI的详细设计（CSCI detailed design)开发者应该开发和记录每个软件单元的设计描述。
结果应该包括《软件设计说明书》模板的所有项目。
根据需要，接口的内容可以在《接口设计说明书》中，有关数据库访问和操作的软件单元可以安排在《数据库设计说明书》中。
2.5 软件编码与单元测试开发者应根据以下要求进行软件单元实现和测试。
注意：“软件”的含义即包括计算机程序也包括计算机数据库。
“实现"的含义为将软件实现转换为计算机程序和计算机数据库。
如果一个CSCI的开发分成多个版本，软件实现、和单元测试可能要到最后一个版本才能完成。
每个版本的软件实现和单元测试指在那个版本中需要实现的软件单元或部分软件单元。
2.5.1 软件实现开发者应该开发和记录CSCI设计中的每个软件单元。
这些活动应该包括，编码、数据定义、构造数据库，给数据库或其他数据文件赋值以及其他实现设计所需要的活动。
注意：设计中的软件单元不一定与实现它们的代码和数据实体有一一对应的关系。
2.5.2 单元测试准备开发者应该建立测试用例（按照输入、预期输出和评价标准）、测试过程和测试数据来测试每个软件单元。
测试用例应该覆盖单元详细设计的所有方面。
开发者应该将这些信息记录在相应的软件开发文件中。
2.5.3 进行单元测试开发者应该测试每个软件单元对应的软件。
这些测试应该按照单元测试用例和测试过程进行。
2.5.4 修正和回归测试开发者应该根据单元测试的结果进行所需的修正并进行回归测试，更新相关的软件开发文件。
2.5.5 分析和记录单元测试的结果开发者应该分析单元测试的结果并将测试和分析结果记录在相应的软件开发文件中。
2.6 单元集成和测试开发者应该根据以下要求进行单元集成和测试。
注意1：单元集成和测试指将两个或多个软件单元集成起来，通过测试保证它们在一起工作正常，继续这个过程直到每个CSCI中的软件单元都集成和测试过。
因为一个软件单元可能由其它单元组成，一些集成测试在单元测试过程中就可以完成，这里不要求重复这些测试活动。
如果一个CSCI分成多个版本开发，CSCI的单元集成和测试可能要等到最后一个版本才能完成。
2.6.1 单元集成和测试的准备开发者应该建立单元集成和测试的测试用例、测试过程和测试数据（按照输入、预期结果和评价标准）。
测试用例应该覆盖CSCI范围和CSCI结构设计的所有方面。
开发者应该将这些信息记录在相应的软件开发文件中。
2.6.2 进行单元集成和测试开发者应该进行单元集成和测试，测试应该按照单元集成测试用例和过程进行。
2.6.3 修正和回归测试开发者应该根据单元集成和测试的结果修正软件并进行回归测试，更新软件开发文件及其他所需的软件产品。
2.6.4 分析、记录单元集成和测试的结果开发者应该分析单元集成和测试的结果并记录在相应的软件开发文件中。
2.7 CSCI/HWCI的集成和测试开发者应该根据以下要求参加CSCI/HWCI（软件配置项/硬件配置项）的集成和测试活动。
注意1：CSCI/HWCI集成和测试的含义是将CSCI和与之有接口的HWCI、CSCI结合，通过测试来验证它们在一起工作是否正常。
连续进行这个过程，直到系统中所有CSCI和HWCI都已经集成并进行测试过。
这个集成测试的最后阶段是开发者内部的系统测试。
注意2：如果一个系统CSCI分成多个版本开发，CSCI/HWCI集成和测试可能要到最后一个版本才完成。
某个版本的CSCI/HWCI的含义为此版本中的CSCI和此版本中HWCI进行测试以保证这个版本的系统需求得到了实现。
2.7.1 准备CSCI/HWCI的集成和测试开发者应该参与开发和记录CSCI/HWCI集成和测试的测试用例（根据输入、预期输出和评价标准）、测试过程。
测试用例应该覆盖系统范围设计和系统结构设计的所有方面。
开发者应该将软件相关信息记录在软件开发文件中。
2.7.2 进行CSCI/HWCI集成和测试开发者应该参加CSCI/HWCI的集成和测试。
测试应该按照CSCI/HWCI集成测试用例和测试过程进行。
2.7.3 修正和重新测试根据CSCI/HWCI集成和测试的结果，开发者应该做所需要的修正，参加所有需要的重新测试，更新相应的软件开发文件和其他软件产品。
2.7.4 分析和记录CSCI/HWCI集成和测试的结果开发者应该参加分析CSCI/HWCI集成测试的结果。
软件相关的分析和测试结果应该记录在相应的软件开发文件中。
2.8 系统测试开发者应该根据以下要求参加系统测试。
注意1：系统测试用来给用户演示系统需求已经得到满足。
它覆盖《系统/子系统规格说明书（SSS）》中的系统需求和相关的接口需求。
这个测试和集成测试的最后阶段在开发者内部进行的系统测试不同。
注意2：如果系统分成多个版本开发，完整的系统测试可能在最后一个版本才遇到。
每个版本的质量测试应该理解为为了验证此版本的需求已经得到满足而进行的测试。
2.8.1 系统测试中的独立性负责系统测试的人不应该是进行详细设计或软件实现的人。
这并不排除负责详细设计或实现的人对这个过程作出贡献，例如：提供需要了解系统内部实现的测试用例。
2.8.2 在目标计算机上的测试开发者的系统测试应该包括在目标计算机（或其它用户同意的系统）上的测试。
