华为开发文档docx.docx
《华为开发文档docx.docx》由会员分享，可在线阅读，更多相关《华为开发文档docx.docx（29页珍藏版）》请在冰点文库上搜索。
华为开发文档docx
软件开发及文档培训
（仅供内部使用）
深圳市华为技术有限公司
版权所有XX
1软件开发过程介绍
华为公司的软件开发过程基本上由以下几个开发过程组成
•系统需求分析过程
•系统设计过程
•软件需求分析过程
*软件概要设计过程
*软件详细设计过程
*软件编码和单兀测试过程
*软件集成与集成测试过程
*系统集成和系统集成测试过程
•系统验收测试过程
•软件维护过程
口P-O*g
口匚十B卫話fl1±^
申琏明暉EOltS
月n什4,
:
Sg
*F1|0
MW-tt
j•岸
•雨列%收伸
■HU
S&ff*
迓卫希呵
恒鑑詣暉用稱■
g.
24
卅虬
fti=38*怙各！
t丈年铮即曲财1|巧乱
图一.软件开发相关的过程示意图：
各软件开发过程中应该输出的文档如下
软件开发过程
输出文档名称
文档模板
系统需求分析
操作概念文档
OCD
系统/了系统需求规格书
SSS
系统/了系统接口需求规格书
IRS
系统结构设计
系统/子系统设计描述
SSDD
系统/子系统接口设计描述
IDD
软件需求分析
软件需求规格书
SRS
接口需求规格书
IRS
软件概要设计
软件设计描述
SDD
接口设计描述
IDD
软件详细设计
数据库设计描述
DBDD
L
cscigt_
"7丽i丽ill丽?
蘇耳蔽?
融丽TI需IH爵"环藪嬴■田旳wmw口跟朕瑕履的合也珈mas
2.软件开发过程详细要求
2.1系统需求分析
开发者应该根据以下要求参与系统需求分析。
注：
如果一个系统分成多个版本开发，可能直到最后一个版本需求才能完全定义。
开发者的计划中应该定义在每个版本中确定的需求子集，每个版本中实现的需求子集。
某个版本的需求分析应该理解为定义那个版本的系统需求。
2.1.1分析用户的输入
开发者应该通过分析用户的输入来理解用户的需求。
这个输入的形式可能是需求报告单、调查、问题/修改报告，原型的反馈，访谈或其他用户或反馈。
2.1.2操作概念
开发者应该参与定义和记录系统的操作概念。
结果应该包括在《操作概念描述
（OCD》文档模板中的所有条目。
2.1.3系统需求
开发者应该参与定义和记录系统应该满足的需求以及验证每个需求已经被满足
的方法。
结果应在包括《系统/子系统规格说明书（SSS》中的所有可能的条目。
根据实际情况，有关系统接口的需求可以在SSS中规定或者在《接口需求规格说明书（IRSs）》中规定。
注：
如果一个系统由子系统组成，系统需求分析）中的活动应该同系统设计中的活动叠代进行。
定义系统的需求，设计系统并定义它的子系统，定义这些子系统的需求，设计子系统并定义他们的部件，如此下去。
2.2系统的设计
开发者应该按照下列要求参与系统的设计。
注：
如果系统分成多个版本开发，系统的设计可能要等到最后一个版本才完成。
开发者的计划中应该定义每个版本中所要完成的设计。
一个特定版本的设计应理解为那个版本中应完成的设计内容。
2.2.1系统范围的设计决定（System-widedesigndecisions）
开发者应该参与定义和记录系统范围的设计决定（这就是，有关系统运行设计和其它影响到系统部件选择、设计的决定）。
结果应该包括《系统/子系统设计说明书（SSDD》模板中有关系统范围设计决定的所有内容。
根据实际情况，有关接口的设计可以包括在SSDD中或者《接口设计说明书》中，有关数据库的设计可以包括在SSDD或者《数据库设计说明书（DBDDS》中。
注：
除非在需求中有明确的规定，设计一般由开发者负责。
开发要满足所有的需求并通过系统集成测试来证明需求得到了满足。
2.1.2系统结构设计（Systemarchitecturaldesign）开发者应该参与定义和记录系统的结构设计（定义系统的部件，它们的接口，以及它们之间的运行概念）以及系统部件同系统需求之间的跟踪关系。
结果应该包括《系统/子系统设计说明书（SSDD》中有关结构设计及跟踪性的部分的所有条目。
根据需要，有关接口的设计可以包括在SSDDs或《接口设计说明书》中。
2.3软件需求分析（Softwarerequirementsanalysis）
开发者应该定义和记录每个CSCI应该满足的软件需求，验证每个需求是否完成的方法，以及CSCI需求同系统需求之间的跟踪关系。
结果应该包括《软件需求规格说明书（SRS》中所有的条目。
根据需要，CSCIs接口的需求可以包括在SRS中或《接口需求规格说明书（IRSs）》中。
注：
如果一个CSCI分成多个版本开发，需求可能要到最后一个版本才能完全定义。
开发者的计划中应该说明每个版本中每个CSCI需求的子集。
2.4软件设计
开发者应该根据以下要求进行软件的设计。
注意：
如果一个CSCI分成多个版本开发，可能需要等到最后一个版本才能完全设计完毕。
每个版本的软件设计应该理解为为了实现这个版本的需求而进行的设计。
2.4.1CSCI范围的设计决定（CSCI-widedesigndecision）.
开发者应该定义和记录CSCI范围的设计决定（这就是，有关CSCI的运行设计和其它影响到构成CSCI的软件单元选择和设计的设计决定）。
结果应该包括《软件设计说明书（SDD》中有关CSCI范围设计决定的所有项目。
根据需要，有关接口的设计内容可以包括在SDD中，也可以安排在《接口设计说明书》中。
有关数据库的设计可以安排在《数据库设计说明书》中。
2.4.2CSCI结构设计（CSCIarchitecturaldesign）。
开发者应该定义和记录每个CSCI的结构设计（定义构成CSCI的软件单元，它们的接口，它们之间的运行概念）以及软件单元CSCI需求的跟踪关系。
结果应该包括《软件设计说明书》中有关结构设计及跟踪性的所有项目.根据实际需要，
有关接口的设计内容可以包括在《接口设计说明书》中。
注意：
如果软件单元又有其它软件单元组成，则CSCI的结构可以根据需要组成多个层次。
例如。
一个CSCI可以被分成三个软件单元，上述每个软件单元又可以分成其他的软件单元，如此下去。
2.4.2CSCI的详细设计（CSCIdetaileddesign）
开发者应该开发和记录每个软件单元的设计描述。
结果应该包括《软件设计说明书》模板的所有项目。
根据需要，接口的内容可以在《接口设计说明书》中，有关数据库访问和操作的软件单元可以安排在《数据库设计说明书》中。
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.7CSCI/HWCI的集成和测试
开发者应该根据以下要求参加CSCI/HWC（I软件配置项/硬件配置项）的集成和测试活动。
注意1：
CSCI/HWC集成和测试的含义是将CSCI和与之有接口的HWC、CSCI结合，通过测试来验证它们在一起工作是否正常。
连续进行这个过程，直到系统中所有CSCI和HWC都已经集成并进行测试过。
这个集成测试的最后阶段是开发者内部的系统测试。
注意2:
如果一个系统CSCI分成多个版本开发，CSCI/HWC集成和测试可能要到最后一个版本才完成。
某个版本的CSCI/HWC的含义为此版本中的CSCI和此版本中HWC进行测试以保证这个版本的系统需求得到了实现。
2.7.1准备CSCI/HWC的集成和测试
开发者应该参与开发和记录CSCI/HWC集成和测试的测试用例（根据输入、预期输出和评价标准）、测试过程。
测试用例应该覆盖系统范围设计和系统结构设计的所有方面。
开发者应该将软件相关信息记录在软件开发文件中。
2.7.2进行CSCI/HWC集成和测试
开发者应该参加CSCI/HWC的集成和测试。
测试应该按照CSCI/HWC集成测试用例和测试过程进行。
2.7.3修正和重新测试
根据CSCI/HWC集成和测试的结果，开发者应该做所需要的修正，参加所有需要的重新测试，更新相应的软件开发文件和其他软件产品。
2.7.4分析和记录CSCI/HWC集成和测试的结果
开发者应该参加分析CSCI/HWC集成测试的结果。
软件相关的分析和测试结果应该记录在相应的软件开发文件中。
2.8系统测试
开发者应该根据以下要求参加系统测试。
注意1:
系统测试用来给用户演示系统需求已经得到满足。
它覆盖《系统/子系统规格说明书（SSS》中的系统需求和相关的接口需求。
这个测试和集成测试的最后阶段在开发者内部进行的系统测试不同。
注意2:
如果系统分成多个版本开发，完整的系统测试可能在最后一个版本才遇到。
每个版本的质量测试应该理解为为了验证此版本的需求已经得到满足而进行的测试。
2.8.1系统测试中的独立性
负责系统测试的人不应该是进行详细设计或软件实现的人。
这并不排除负责详细设计或实现的人对这个过程作出贡献，例如:
提供需要了解系统内部实现的测试用例。
2.8.2在目标计算机上的测试
开发者的系统测试应该包括在目标计算机（或其它用户同意的系统）上的测试
2.8.3系统测试的准备
开发者应该参加参加开发和记录测试的准备、测试用例、测试过程以及测试用例
和系统需求之间的跟踪性。
对于软件系统，结果应该包括《软件测试说明书（STD》中的所有项目。
开发者应该参加准备系统测试需要的测试数据以及通知用户测试的时间和地点。
2.8.4运行（自己动手）系统测试
如果系统测试需要用户见证，开发者应该参加（自己动手）运行系统测试用例和过程以保证其完整性和正确性。
开发者应该将这些测试活动的结果记录在相应的软件开发文件中并根据需要对测试用例和过程进行更新。
2.8.5进行系统测试
开发者应该参加系统测试。
测试应该根据测试用例和过程进行。
2.8.6修正和重新测试
根据系统测试的结果，开发者应该对软件做必要的修正，给用户提供重新测试的建议，参加所有需要的重新测试并更新软件开发文件和其他软件产品。
2.8.7分析和记录系统测试结果
开发者应该参加分析和记录系统测试结果。
对于软件小，这些结果应该包括《软件测试报告（STR》中的所有项目。
深圳市华为技术有限公司
文档编号
产品版本
密级
研究管理部文档中心
产品名称：
共10页
软件需求规格说明书
（SRS
（仅供内部使用）
拟制：
日期：
yyyy/mm/dd
审核：
日期：
yyyy/mm/dd
审核：
日期：
yyyy/mm/dd
批准：
日期：
yyyy/mm/dd
深圳市华为技术有限公司
版权所有XX
修订记录
日期
修订版
本
描述
作者
1999/01/30
1.00
初稿完成
作者名
r
—
—
L
—
L
L
1
1范围4
1.1标记4
1.2系统概论4
1.3文档概述4
2参考文献4
3需求4
3.1所需的状态和模式5
3.2CSCI能力需求5
3.2.1（CSCI能力）5
3.3CSCI外部接口需求5
3.3.1接口标识符和示意图5
3.3.2（项目内部接口唯一的标识符）6
3.4CSCI内部接口需求7
3.5CSCI内部数据需求7
3.6适应性需求7
3.7安全性需求8
3.8安全和隐蔽性需求8
3.9CSCI的环境需求8
3.10计算机资源需求8
3.10.1计算机硬件需求8
3.10.2计算机硬件资源利用程度需求8
3.10.3计算机软件需求8
3.10.4计算机通讯需求8
3.11软件质量因素9
3.12设计和实现约束9
3.13人员相关的需求9
3.14培训有关的需求9
3.15后勤相关的需求9
3.16其它需求9
3.17包装的需求9
3.18需求的优先和关键顺序9
4质量保证措施10
5需求跟踪10
6注释10
7附录10
软件需求规格说明书
软件需求规格说明书（SRS规定一个计算机软件配置项（CSC）的需求，以及验证每个需求是否得到满足的方法。
CSCI的外部接口需求可以在SRS中进行规定，也可以在一个或多个接口需求规格说明书（IRS）中进行规定，在软件需求规格说明书（SRS对这些文档进行引用。
软件需求规格说明书（SRS（可能需要IRS的补充）是CSCI设计和测试的基础。
1.范围
这部分将被分为以下几段。
1.标识
这一部分应包含系统、接口实体、被说明接口的完整标识，尽可能包括：
标识号码、标题、缩写、版本号、发布号。
1.系统概论
这一部分将简要的阐述文档所说明的系统和软件的目的。
它将大概描述系统、软件的本质；总结系统的发展、操作和维护的历史；确定这个方案的发起人、受益人、使用人、开发者和维护机构；确定当前的状况并计划操作地点；最后列出其它相关联的文档。
1.文档概述
这一部分总结了这个文档的目的和内容，并且描述了与文档用处有关的任何安全性及保密性的事项。
1.参考文献
这一部分列出了一些文档中引用的所有文档的号码、名称、修订本和数据。
1.需求
本部分应该分成以下段落来描述CSCI的需求，它们是CSCI为了被接受而必须具有的特性。
CSCI的需求是为了满足分配到本CSCI的系统需求而产生的软件需求。
需要给每个需求分配一个项目唯一的标识符以支持需求的测试和跟踪，对需求的描述必须能够达到可以设计针对性测试的程度。
如果在以后的4、5节没有说明，在这里每个需求都要注明相应的测试方法（见4节）及与系统需求间的追溯关系（见5节）。
需求描述的详细程度应该依照以下原则：
包括CSCI达到可接受的标准所必须具有的特征，避免进行设计描述，这些是开发者的工作。
如果在某一段中没有需求，只需要写“无”即可。
如果一个需求在多个段落中出现，它只需描述一次即可，在其它地方进行引用。
1.所需的状态和模式
如果CSCI工作在不同的状态和模式中，并且在不同的工作状态和模式有不同的需求，本段应定义每一个状态和模式。
状态和模式的例子如下：
等待、待命、行动、事后分析、训练、降级、紧急、备份、战时、和平时期。
状态和模式间的区别时灵活的。
一个CSCI可以只按照状态描述，只按照模式描述，按照模式中的状态描述，按照状态中的模式描述或按照任何其他有用的顺序描述。
如果系统没有任何状态和模式的特别要求，按照实际情况描述即可，没有必要“人工创造”不同。
如果需要按照模式或状态描述，那么每个需求或者需求集合都要和状态或模式相关。
这些相关性可以通过段落或附录中的一个表格进行说明，也可以对需求进行注释。
1.CSCI能力需求
本段应该分成以下子段落以逐条说明CSCI的每个能力需求。
一个“能力”定义成一组相关的需求。
名词“能力”可以用“功能”、“题目”、“目标”等有助于表达需求的名词替代。
1.（CSCI能力）
本段定义CSCI的一个能力并罗列有关此能力的需求。
如果此能力分成几个组成部分描述更清楚些，这些子能力应在各子段落中描述。
需求规定CSCI的动态行
为并包括可能的参数，例如：
反映时间、吞吐时间、其他时间约束、顺序、准确度，能力（多少）、优先级、连续操作的需求，不同操作条件下允许的偏差。
需求应尽可能包括：
在异常情况下、越界情况下所需的动态行为，错误处理的需求，紧急情况下提供连续操作能力的需求。
3.3段规定了描述CSCI有关输入输出需求时需要考虑的一系列题目。
1.CSCI外部接口需求
本段应该分成以下几个子段落来规定CSCI的外部接口需求，本段可能引用一个或多个接口需求规格说明书或其它相关文档。
1.接口标识符和示意图本段应该定义CSCI所需的外部接口（它们是和其他外部实体之间涉及共享、提供或交换数据的关系）。
每个接口的标识包括一个项目内部唯一的标识符以及接口实体（系统、配置项、用户、等），对接口实体的说明尽量包括以下内容：
名称、编号、版本、参考文档。
定义应该说明那个接口实体具有固定的接口特性（因
此对相应的接口实体提出接口要求），那些正在被开发或修改（因此被赋予接口需求）。
应该提供一个或多个示意图以对接口进行说明。
1.（接口的标识符）
本段（从332开始〕应该给CSCI的一个外部接口定义一个项目唯一的标识符，简要描述接口实体。
为了描述一个或者多个接口实体的需求，可以划分为子段落。
如果一个接口实体未被本文档覆盖（例如一个外部系统），但是描述接口需要提到它时，应该以假定的方式说明，或者以“当［未被覆盖的实体］这样作，［系统中说明的实体］将…••…"样的方式说明。
本段可能会引用其他文档（例如：
数据字典、标准协议、用户接口标准）。
设计描述应该尽可能包括以下信息，可以用任何适合需求的顺序提供，应该注明这些特征从接口实体角度看的任何区别（例如：
对数据元素的大小、频率或其他特征的不同理解）：
*接口实体必须赋予接口的优先级。
•接口类型的需求（例如：
实时数据传送，存储—检索，等等）。
•接口实体提供、存储、发送、访问、接收的每个数据元素的特征。
例如：
1.名称/标记
1.项目唯一的标记
2.自然语言的名称
3.国防部标准数据元素名称
4.技术名称（例如，代码或数据库中的变量名和域名）
5.缩写词或同义词
2.数据类型（字符型、整型等）
3.大小和格式（例如字符串的长度和分隔符号〕
4.测量单位（例如米、美元、微秒）
5.可能的数值范围（例如：
0—99）
6.准确度（正确的程度）和精确度（有效数字的位数）
7.优先级、时序、频率、数量、顺序和其他约束，例如：
是否更新数据成员，是否应用行业标准。
8.安全和隐蔽性的约束
9.源头（设置/发送实体）和接受（使用/接收实体）
*数据元素集（纪录，消息，文件，数组，显示，报告）的特性。
11.名称/标记
1.项目唯一的标记
2.自然语言的名称
3.技术名称（例如，代码或数据库中的变量名和域名）
4.缩写词或同义词
12.装配中的数据元素及其类型（编号，顺序，分组）
13.媒介（如磁盘）和在媒介上的元素/装配的结构
14.输出的视觉和听觉特性，其他输出（颜色，字体，布局，图标，亮度，蜂鸣等）
15.数据集合之间的关系，如排序/存取特性
16.优先级、时序、频率、数量、顺序和其他约束，例如：
是否更新数据成员，是否应用行业标准。
17.安全和隐蔽性的约束
18.源头（设置/发送实体）和接受（使用/接收实体）
•接口使用的通讯方法
•项目唯一的标识符
•通讯链接、波段、频率、媒质和特性。
*消息格式
•流控（例如：
顺序号和分配缓冲）。
•数据传输数率，是周期性还是突发性，传送的间隔。
•路由、地址、和命名约定。
•传送服务，包括：
优先和分级
•安全和隐蔽性的考虑，例如：
加密、用户验证、隔离和审计。
*接口中使用的协议特性需求
*项目唯一的标志符
+协议的优先级和层次
•包操作，包括拆分、组装、路由和寻址
•合法性检查，出错控制，恢复过程。
•同步过程，包括：
建立连接，保持，结束。
*状态、标志、任何其他的报告特性。
•其他特性，例如：
接口实体的物理兼容性（体积、公差、负荷、电压、插头兼容性等）
36.CSCI内部接口需求
本段定义CSCI内部接口需求。
如果内部接口情况由开发者决定，这里说明即可如果需要定义内部接口需求，请参照3.3的题目进行说明。
1.CSCI内部数据需求
本段定义CSCI内部数据的需求，内部数据库和数据文件的需求。
如果所有的设
计由开发者决定，这里只要说明即可。
如果具有这方面的需求，本段的3.3.X.C和3.3.x.d提供了需要考虑的条目。
1.适应性需求
本段规定CSCI和安装数据有关的需求（例如：
和安装地点有关的经纬度，或和安装有关的州税务码）以及不同操作下可能不同的操作参数需求（例如：
指示和操作有关的目标变量或数据记录的参数）。
1.安全性需求
本段应该描述CSCI有关避免或减少对人员、财产、环境的意外伤害的需求。
例如：
必须提供一些保证措施来避免一些无意中的行为（例如：
无意中发出一个关闭自动驾驶仪的命令）和“不行为”（例如：
没有按要求发出“关掉自动驾驶”命令）。
1.安全和隐蔽性需求
本段规定有关保持系统安全和隐蔽性的需求。
这些需求包括，CSCI操作必须的
升级会员 