华为软件开发行为规范.docx
《华为软件开发行为规范.docx》由会员分享，可在线阅读，更多相关《华为软件开发行为规范.docx（35页珍藏版）》请在冰豆网上搜索。
华为软件开发行为规范
软件开发行为标准
第一版
深圳市华为技术
版权所有不得复制
软件开发行为标准
（第一版〕
为了把公司已经发布的软件开发过程标准有效地运作于产品开发活动中，把各种标准“逐步形成工程师的作业标准〞，特制定本软件开发行为标准，以到达过程控制的目的。
与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为标准。
对违背标准的开发行为，必须按照有关管理规定进展处分。
本软件开发行为标准的内容包括：
软件需求分析、软件工程方案、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。
本软件开发行为标准，采用以下的术语描绘：
★规那么：
在软件开发过程中强迫必须遵守的行为标准。
★建议：
软件开发过程中必须加以考虑的行为标准。
★说明：
对此规那么或建议进展必要的解释。
★例如：
对此规那么或建议从正或反两个方面给出例子。
本软件开发过程行为标准由研究技术管理处负责解释和维护。
研究技术管理处
1软件需求分析
5
2软件工程方案
9
3概要设计
11
4详细设计
14
5编码
18
6需求管理
19
7软件配置管理
21
8软件质量保证
23
9数据度量和分析
25
1软件需求分析
1-1：
软件需求分析必须在产品需求规格的根底上进展，并保证完全实现产品需求规格的定义。
1-2：
当产品的需求规格发生变更时，必须修订软件需求规格文档。
软件需求规格的变更必须经过评审，并保存评审记录。
1-3：
必须对软件需求规格文档进展正规检视。
1-4：
软件需求分析过程活动完毕前，必须经过评审，并保存评审记录。
1-5：
在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的明晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、强健性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。
说明：
参考建议1-1到1-16。
1-1：
采用以下检查表检查软件需求规格文档中需求的明晰性。
序号
问题
1
所有定义、实现方法是否清楚地表达了用户的原始要求？
2
在功能实现过程、方法和技术要求的描绘上，是否没有背离了功能的实际要求？
3
是否没有不能理解或造成误解的描绘？
1-2：
采用以下检查表检查软件需求规格文档中需求的完备性。
序号
问题
1
需求定义中是否包含了有关文件〔指质量手册、质量方案以及其它有关文件〕种所规定的需求定义所应该包含的所有内容？
2
需求定义是否包含了有关功能、性能、限制、目的、质量等方面的所有需求？
3
功能性需求是否覆盖了所有非正常情况的处理？
4
是否对各种操作形式〔如正常、非正常、有干扰等〕下的环境条件都作了规定？
5
是否对所有功能与时间因素有关的方面都作了考虑？
6
是否标识出了所有与时间因素有关的功能？
它们的时间准那么是否都说明了？
时间准那么的最大、最小执行时间是否都定义了？
7
是否标识并定义了在将来可能会变化的需求？
8
是否认义了系统所有的输入？
9
是否标识清楚了系统输入的来源？
10
是否标识出了系统的输出？
11
是否说明了系统输入、输出的类型？
12
是否说明了系统输入、输出的值域、单位、格式等？
13
是否说明了如何进展系统输入的合法性检查？
14
是否认义了系统输入、输出的精度？
15
是否认义了系统性能的各个方面？
16
在不同负载情况下，是否规定了系统的处理才能？
17
在不同情况下，是否规定了系统的响应时间？
18
是否充分定义了关于人机界面的需求？
19
是否对需求定义进展了可行性分析和相关文件〔资料〕是否已归档？
20
是否对影响需务实现的因素进展了调查，调查结果是否已归档？
21
是否有经济效益分析，分析结果是否已归档？
22
是否详细描绘了有关硬件、软件、操作人员、操作过程等方面的平安性？
23
是否评估了本工程对用户、其它系统、环境的影响特性？
24
是否按完成时间、重要性对系统功能、外部接口、性能进展了优先排序？
1-3：
采用以下检查表检查软件需求规格文档中需求的兼容性。
序号
问题
1
界面需求是否使软硬件系统具有兼容性？
2
需求定义的文档是否满足工程文档编写标准？
在矛盾时，是否有适当的标准可供选择？
1-4：
采用以下检查表检查软件需求规格文档中需求的一致性。
序号
问题
1
各个需求之间是否一致？
是否有冲突和矛盾？
2
所规定的模型、算法和数值方法是否相容？
3
是否使用了标准的术语和定义形式？
4
需求是否与其软硬件操作环境相容？
5
是否说明了软件对其系统和环境的影响？
6
是否说明了环境对软件的影响？
7
所采用的技术是否与用户要求的技术一致？
1-5：
采用以下检查表检查软件需求规格文档中需求的正确性。
序号
问题
1
需求定义是否满足标准的要求？
2
算法和规那么是否有科技文献或其它文献作为根底？
3
是否认义了对在错误、风险分析中所标识出的各种故障形式和错误类型所需的反响？
4
是否参照了有关的标准？
5
是否对每一个需求都给出了理由？
理由是否充分？
6
对设计和实现的限制是否都有论证？
1-6：
采用以下检查表检查软件需求规格文档中需求的可行性。
序号
问题
1
需求定义是否使软件的设计、实现、操作和维护都可行？
2
所规定的模型、数值方法和算法是否对待解决问题适宜？
是否可以在相应的限制条件下实现？
3
是否可以到达关于质量的要求？
1-7：
采用以下检查表检查软件需求规格文档中需求的易修改性。
序号
问题
1
对需求定义的描绘是否易于修改〔如是否采用良好的构造和穿插引用表等〕？
2
是否有冗余的信息？
是否一个需求被定义了屡次？
1-8：
采用以下检查表检查软件需求规格文档中需求的强健性。
序号
问题
1
是否有容错的需求？
1-9：
采用以下检查表检查软件需求规格文档中需求的易追溯性。
序号
问题
1
是否可从上一阶段的文档中找到需求定义中的相应内容？
2
需求定义是否明确地说明前阶段中提出的有关需求和设计限制都已被覆盖了？
3
需求定义是否便于向后继开发阶段查找信息
1-10：
采用以下检查表检查软件需求规格文档中需求的易理解性。
序号
问题
1
是否每一个需求都只有一种解释？
2
功能性需求是否以模块方式描绘的？
是否明确地标识出了其功能？
3
是否有术语定义一览表？
4
是否使用了形式化或半形式化的语言？
5
语言是否有歧义性？
6
需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节？
是否过分细致了？
7
需求定义是否足够清楚和明确使其可以作为开发设计规约和功能性测试数据的根底？
8
需求定义的描绘是否将对程序的需求和所提供的其它信息别分开来了？
1-11：
采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。
序号
问题
1
需求是否可以验证〔即是否可以检验软件是否满足了需求〕？
2
是否对每一个需求都指定了验证过程？
3
数学函数的定义是否使用了准确定义的语法和语义符号？
1-12：
采用以下检查表检查软件需求规格文档中的性能需求描绘。
序号
问题
是否准确的描绘了所有的性能需求和可容忍的性能降低程度？
对每一个性能应包含两方面的内容：
1
a.在最坏情况的执行结果
2
b.本性能失效后，对系统产生的影响
1-13：
采用以下检查表检查软件需求规格文档中功能需求描绘。
序号
问题
1
是否清楚、明确地描绘了所有的功能？
2
所有已描绘的功能是否是必须的？
是否能满足任务书或系统目的的要求？
1-14：
采用以下检查表检查软件需求规格文档中的接口需求描绘。
序号
问题
1
是否清楚地定义了所有的接口？
3
所有接口是否必须？
各接口间的关系是否一致、正确？
1-15：
采用以下检查表检查软件需求规格文档中的数据需求描绘。
序号
问题
1
在某异常数据〔如条件、标志等〕下，是否有真正没有考虑到的结果？
2
对异常数据产生的结果是否作了准确的描绘？
1-16：
采用以下检查表检查软件需求规格文档中的可维护性需求描绘。
序号
问题
1
需求定义中是否包括了可行的系统维护方法？
2
软件系统间的关系是否是松耦合的〔即能否保证在对某局部修改后，产生最小的连锁效应〕？
2软件工程方案
2-1：
软件工程方案必须以产品/软件的需求规格为根底。
当发生需求更改时，必须修订软件开发方案。
说明：
软件工程方案必须根据需求规格进展制定。
工程方案中的工作产品和工作任务应保证能完全实现需求规格的定义。
当需求更改时，必须考虑需求更改的相关性，修订相应软件开发方案。
2-1：
制定软件工程方案的活动制定，必须遵守“软件工程方案标准〞。
2-2：
软件经理对软件工程方案的制定和结果负责。
2-3：
软件经理和相关参与软件工程方案的制定和评审的人员，在参与方案制定之前必须经过软件工程和软件工程方案制定流程的培训。
2-2：
对于软件工程方案中各项工作产品和工作任务，必须进展规模和工作量的软件估计，并在软件工程方案文档中记录估计的方法和估计数据。
说明：
参考建议2-4到2-8。
2-4：
可以使用PERT统计估计、专家断定平均法、经历类比估计、公式计算等方法，或以上方法的组合，进展软件估计。
例如：
PERT统计估计和经历类比估计的结合
PERT统计估计值＝（最大估计＋4×期望估计＋最小估计〕/6
估计记录如下：
工作产品任务
最大估计
期望估计（根据经历类比获得）
最小估计
PERT估计
规模
工作量
规模
工作量
规模
工作量
规模
工作量
XX版本〔增加XX特性〕话统模块概要设计
文档页数:
45;增加、修改模块设计数目:
12
12天
文档页数:
42;增加、修改模块设计数目:
10
10天
文档页数:
30;增加、修改模块设计数目:
5
5天
文档页数:
41;增加、修改模块设计数目:
10
天
期望估计值是根据XX版本的话统模块设计的数据获得。
2-5：
对某项工作产品和任务的软件，同时采用两种或以上的方法进展估计，以防止一种方法的偏向。
2-6：
尽量采用历史经历数据进展软件估计。
2-7：
参照“软件估计指导书〞进展软件估计。
2-8：
软件估计对应工程的任务分解构造进展。
说明：
软件估计对于工程的任务分解构造对应得越明晰、越细致，相应的估计越准确。
2-9：
在“软件工程方案〞中必须包括工程管理活动的方案。
2-10：
在“软件工程方案〞中包括软件重用方案。
包括重用软件部件的方案和开发可重用软件部件的方案。
2-11：
在“软件工程方案〞包括人员的培训方案。
说明：
工程人员方案包括需要的人员类型、数量和技术等级的要求，相关人员的开场工作时间、工作周期、承受培训的方案等。
2-12：
对软件工程进展风险分析与评估。
说明：
可能存在的风险领域含：
需求的不明确和变更、外部的限制与对外的依赖、人力资源的到位情况、人力资源的技术等级满足要求状况、技术问题等。
对风险的分析与评估理论包括：
从的情况推导出潜在风险；
对风险进展分析，得出：
潜在风险可能引发的问题的影响、潜在风险发生的可能性大小、风险发生的时间段等；
排列风险的重点次序；
对风险记录成文件〔属于软件工程方案中的一局部〕；
风险经受风险影响人审核，并获得他的同意；
根据需要，在开发过程中对风险文档进展维护和修订。
2-3：
对应工作任务，制定工程的文档方案。
2-4：
软件工程方案中应该包括正规检视活动方案、软件质量保证方案、软件配置管理方案。
软件质量保证方案和软件配置管理方案可以和软件工程方案在同一份文档中，也可以分开为三份文档。
说明：
参考建议2-13。
2-13:
软件质量保证方案和软件配置管理方案作为独立的方案文档。
2-14：
软件工程方案必须是整个工程开发过程的方案，包括测试。
2-15：
测试经理对照整个开发方案建立软件验证与确认方案。
软件验证与确认方案可作为独立的方案文档。
2-5：
必须对工程工作进展分解，确定工程的工作任务，任务的责任人、资源要求、时间要求、工程的进度。
2-6：
必须分析任务之间的依赖性，确定并明确标识工程的关键途径。
2-7：
“软件工程方案〞必须按照文档模板的要求编写。
工程组可根据工程的实际情况，对文档模板中的内容进展裁减。
工程组对文档模板内容的裁减必须得到上级管理部门〔包括产品方案处、软件工程组SEPG〕的审核批准。
2-8：
软件工程方案必须经过评审。
说明：
参考建议2-16。
2-16：
软件工程方案的评审采用以下检查表。
序号
问题
1
软件工程方案是否完全反映〔对应〕“软件需求说明书〞里的需求？
2
软件工程方案是否有开发方法的说明？
3
软件工程方案是否有资源需求的说明？
4
软件工程方案是否包含风险管理方案？
5
软件工程方案是否包含了版本发布的机制？
6
软件工程方案是否标识了所有必须的培训方案？
7
软件工程方案是否标识了所有内部和外部的传递关系？
8
软件工程方案是否标明了工程的依赖关系？
9
软件工程方案是否标明了角色和职责？
10
软件工程方案是否标明了汇报的机制？
11
软件工程方案是否说明了跟踪和监控机制？
12
软件工程方案是否包含“软件质量保证方案〞和“软件配置管理方案〞？
13
软件工程方案是否包含工程开发使用的工具？
14
软件工程方案是否包含工程的各里程碑的说明？
15
进度中是否标明了软件工程方案的关键途径？
2-17：
参加“软件工程方案〞评审的人员，除软件经理和工程组人员外，必须有产品经理、上级管理部门〔包括软件工程组SEPG〕、SQA人员。
2-18：
“软件工程方案〞通过评审后，软件经理组织相关人员对任务进展承诺，签定工作任务书。
2-9：
必须对“软件工程方案〞进展配置管理，“软件工程方案〞的更改必须经过评审。
2-10：
在开发活动中，必须按照工程跟踪与监控方案和体制，对照“软件工程方案〞，跟踪工程开发的实际结果和性能。
2-11：
当实际结果和“软件工程方案〞发生偏离时，必须进展分析，根据分析结果标明纠正措施。
必要的情况下，要及时修订“软件工程方案〞。
2-12：
在软件工程跟踪监控活动中，必须定期进展总结和评审，撰写开发状态报告。
2-19：
根据工程的特点，报告的周期可以为周、双周、月。
2-13：
在软件开发各里程碑阶段完毕前，必须进展阶段评审，对软件工程进展重估计，必要的情况下修订“软件工程方案〞。
2-20：
必须提供相应资源，包括工具和人员等，进展软件工程方案和工程跟踪监控活动。
2-14：
在软件工程方案和工程跟踪监控过程活动中，必须进展数据度量和分析。
说明：
参见“9.数据度量和分析〞。
3概要设计
3-1：
概要设计要以软件需求规格为根底，必须保证需要实现的需求规格已经被设计。
3-2：
当需求规格发生变更时，必须修订相关概要设计文档。
3-3：
在概要设计文档或需求管理文档中，必须记录、验证需求和概要设计的跟踪关系。
说明：
需求和概要设计的跟踪关系可参考建议3-1。
3-1：
采用需求、子系统、模块的跟踪矩阵表记录需求和概要设计的跟踪关系。
3-4：
必须保证概要设计文档和代码的一致性。
当发生设计更改时，必须修订相应设计文档。
3-5：
必须对概要设计文档进展正规检视。
3-6：
概要设计过程完毕前，必须通过评审，并保存评审记录。
3-7：
设计更改必须经过相关评审，并保存评审记录。
3-8：
对概要设计文档的正规检视或评审，必须检查概要设计文档的明晰性、完备性、标准性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。
说明：
参考建议3-2。
3-2：
采用以下检查表检查概要设计文档的明晰性。
序号
问题
1
程序构造，包括数据流、控制流和接口的描绘是否清楚？
3-3：
采用以下检查表检查概要设计文档的完备性。
序号
问题
1
设计目的是否认义？
2
需求规格评审中不完好的需求（TBD）是否都已经解决?
3
假如以前定义的不完好的需求（TBD）发生了改变,本设计是否可以支持?
4
是否对不完好需求（TBD）的影响进展了评估?
5
对有可能不能实现的设计是否有风险管理方案?
6
是否对设计形式进展了描绘?
3-4：
采用以下检查表检查概要设计文档的标准性。
序号
问题
1
文档是否符合公司模板和写作要求?
3-5：
采用以下检查表检查概要设计文档的一致性。
序号
问题
2
程序、模块、函数、数据成员的名称是否保持一致？
3
设计是否反映了真正的操作环境?
硬件环境?
软件环境?
4
对系统设计的多种可能的描绘之间是否保持一致?
（例如:
静态构造的描绘和动态描绘）
3-6：
采用以下检查表检查概要设计文档的正确性。
序号
问题
1
设计在方案、预算、技术上是否可行？
2
逻辑是否正确和完备？
3-7：
采用以下检查表检查概要设计文档的数据描绘。
序号
问题
1
是否对所有的数据成员,参数,对象进展了描绘?
2
是否所有需要的数据构造都进展了定义,或者定义了不需要的数据构造?
3
是否所有的数据成员都进展了足够详细的描绘?
数据成员的有效值区间是否认义?
4
共享和存储数据的使用是否描绘清楚?
3-8：
采用以下检查表检查概要设计文档的功能性要求。
序号
问题
1
模块的规格是否和软件需求文档中的功能需求和软件接口规格要求保持一致.
2
是否给每个子模块确定了抽象算法?
3
设计和算法是否能满足模块的所有需求?
3-9：
采用以下检查表检查设计的接口描绘。
序号
问题
1
是否描绘了接口的功能特征?
2
接口是否便于查错?
3
接口互相之间、和其他模块、和需求说明书及接口规格书保持一致？
4
对接口的数量和复杂度进展了有效的平衡，使接口数量控制在一个较小数量，每个接口具有可承受的复杂度？
5
是否所有的接口都能描绘了必要的类型、数量、质量等信息？
6
操作界面是否考虑了用户〔例如：
提供准确、明晰、有用的提示信息〕？
3-10：
采用以下检查表检查设计的详细程度。
序号
问题
1
是否估计了每个子模块的规模〔代码的行数〕？
是否可信？
2
是否考虑了足够数量及代表性的系统状态？
3
详细程度是否足够进展下一步的详细设计？
3-11：
采用以下检查表检查设计的可维护性。
序号
问题
1
是否模块化设计？
2
模块是否为高内聚、低耦合？
3-12：
采用以下检查表检查设计的性能。
序号
问题
1
是否进展了性能模型分析？
2
是否描绘了所有的性能参数？
〔例如：
实时性能约束，存储空间，速度要求，磁盘I/O空间〕
3
进程是否有时间窗？
〔例如：
需要“加锁〞的标记，信号灯，某些代码执行时需要屏蔽中断〕？
4
程序执行过程中的关键途径是否都被标识和经过分析？
3-13：
采用以下检查表检查设计的可靠性。
序号
问题
1
设计是否考虑了检错和恢复措施？
〔例如：
输入检查〕
2
是否考虑了异常情况？
3
是否完全准确描绘了所有的出错情况？
4
设计是否可以满足所有系统集成方面的要求？
3-14：
采用以下检查表检查设计的可测试性。
序号
问题
1
设计是否可以被实验、演示或检视以显示它满足了需求？
2
设计是否可以使用以前的测试代码，是否可以进展增量式的测试？
3-15：
采用以下检查表检查设计的可追溯性。
序号
问题
1
是否每一局部的设计都可以追溯到需求说明书，接口规格说明书、或其他产品文档？
2
是否所有的设计决策都可以追溯到财务分析？
3
对所继承下来的那些特别和不常用的特性对目前设计的影响是否进展了分析？
4
对所继承设计中的风险是否进展了定位和分析？
4详细设计
4-1：
详细设计要以软件需求规格和概要设计为根底，必须保证需要实现的需求规格已经被设计，必须保证概要设计定义的所有模块已经被详细设计。
4-2：
当需求规格或概要设计发生变更时，必须修订相关详细设计文档。
4-3：
在详细设计文档或需求管理文档中，必须记录、验证需求、概要设计、详细设计的跟踪关系。
说明：
需求、概要设计、详细设计的跟踪关系可参考建议4-1。
4-1：
采用需求、子系统、模块、函数的跟踪矩阵表记录需求、概要设计、详细设计的跟踪关系。
4-4：
必须保证详细设计文档和代码的一致性。
当发生设计更改时，必须修订相应设计文档。
4-5：
必须对重要的详细设计文档进展正规检视。
说明：
参考建议4-2。
4-2：
根据模块的复杂度、规模和在软件系统中的重要程度，选择重要的详细设计文档进展正规检视。
在产品中，进展正规检视的详细设计文档比例要到达60%。
4-6：
详细设计过程完毕前，必须通过评审，并保存评审记录。
4-7：
设计更改必须经过相关评审，并保存评审记录。
4-8：
对详细设计文档的正规检视或评审，必须检查详细设计文档的明晰性、完备性、标准性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。
说明：
参考建议4-3。
4-3：
采用以下检查表检查详细设计文档的明晰性。
序号
问题
1
是否所有的单元和进程的设计目的都已文档化？
2
单元设计，包括数据流、控制流、接口描绘是否清楚？
3
单元的整体功能是否描绘清楚？
4-4：
采用以下检查表检查详细设计文档的完备性。
序号
问题
1
是否提供了所有程序单元的规格？
2
是否描绘了所采用的设计标准？
3
是否确定了单元应用的算法？
〔例如：
PDL〕
4
是否列出了单元的所有调用？
5
是否记录了设计继承的历史和的风险？
4-5：
采用以下检查表检查详细设计文档的标准性。
序号
问题
1
文档是否遵从了公司的标准？
2
单元设计是否使用了要求的方法和工具？
4-6：
采用以下检查表检查详细设计的一致性。
序号
问题
1
在单元和单元的接口中数据成员的名称是否保持一致？
2
所有接口之间，接口和接口规格书之间是否保持一致？
3
详细设计和概要设计文档是否可以完全描绘“正在构建〞的系统
4-7：
采用以下检查表检查详细设计的正确性。
序号
问题
1
是否有逻辑错误？
2
需要使用常量名称的地方是否有错误？
3
是否所有的条件都被处理？
〔>,=,<,switchcase）?
4
分支所处的状态是否正确？
〔逻辑没有搞反〕
4-8：
采用以下检查表检查详细设计的数据描绘。
序号
问题
1
是否所有声明的数据块都已经使用？
2
定位于单元的数据构造是否已经描绘？
3
假如有对共享数据、文件的修改，对数据的访问是否按照正确的共享协议进展？
〔例如：
通过信号灯同步进程〕
4
是否所有的逻辑单元、事件标记、同步标记都已经定义和初始化？
5
是否所有的变量、指针、常量
升级会员 