logo资料库

华为 软件开发行为规范.doc

第1页 / 共30页
第2页 / 共30页
第3页 / 共30页
第4页 / 共30页
第5页 / 共30页
第6页 / 共30页
第7页 / 共30页
第8页 / 共30页
资料共30页,剩余部分请下载后查看
1 软件需求分析
2 软件项目计划
3 概要设计
4 详细设计
5 编码
6 需求管理
7 软件配置管理
8 软件质量保证
9 数据度量和分析
软件开发行为规范 第一版 深圳市华为技术有限公司 版权所有 不得复制
软件开发行为规范 (第一版) 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中,把各种规范“逐 步形成工程师的作业规范”,特制定本软件开发行为规范,以达到过程控制的目的。 与软件开发相关的所有人员,包括各级经理和工程师都必须遵守本软件开发行为规范。对 违反规范的开发行为,必须按照有关管理规定进行处罚。 本软件开发行为规范的内容包括:软件需求分析、软件项目计划、概要设计、详细设计、 编码、需求管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范,采用以下的术语描述: ★ 规则:在软件开发过程中强制必须遵守的行为规范。 ★ 建议:软件开发过程中必须加以考虑的行为规范。 ★ 说明:对此规则或建议进行必要的解释。 ★ 示例:对此规则或建议从正或反两个方面给出例子。 本软件开发过程行为规范由研究技术管理处负责解释和维护。 研究技术管理处
目 录 1 软件需求分析 2 软件项目计划 3 概要设计 4 详细设计 5 编码 6 需求管理 7 软件配置管理 8 软件质量保证 9 数据度量和分析 5 9 11 14 18 19 21 23 25 仅供内部使用 3
软件开发行为规范 1 软件需求分析 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 是否说明了系统输入、输出的类型? 仅供内部使用 4
软件开发行为规范 1 软件需求分析 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 所规定的模型、数值方法和算法是否对待解决问题合适?是否能够在相 仅供内部使用 5
软件开发行为规范 1 软件需求分析 应的限制条件下实现? 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:采用以下检查表检查软件需求规格文档中的性能需求描述。 序号 问题 是否精确的描述了所有的性能需求和可容忍的性能降低程度?对每一个 性能应包含两方面的内容: 仅供内部使用 6
软件开发行为规范 1 软件需求分析 1 2 a. 在最坏情况的执行结果 b. 本性能失效后,对系统产生的影响 1-13:采用以下检查表检查软件需求规格文档中功能需求描述。 序号 问题 1 是否清楚、明确地描述了所有的功能? 2 所有已描述的功能是否是必须的?是否能满足任务书或系统目标的要 求? 1-14:采用以下检查表检查软件需求规格文档中的接口需求描述。 序号 问题 1 是否清楚地定义了所有的接口? 3 所有接口是否必须?各接口间的关系是否一致、正确? 1-15:采用以下检查表检查软件需求规格文档中的数据需求描述。 序号 问题 1 在某异常数据(如条件、标志等)下,是否有真正没有考虑到的结果? 2 对异常数据产生的结果是否作了精确的描述? 1-16:采用以下检查表检查软件需求规格文档中的可维护性需求描述。 序号 问题 1 需求定义中是否包括了可行的系统维护方法? 2 软件系统间的关系是否是松耦合的(即能否保证在对某部分修改后,产生 最小的连锁效应)? 仅供内部使用 7
软件开发行为规范 2 软件项目计划 2 软件项目计划 2-1:软件项目计划必须以产品/软件的需求规格为基础。当发生需求更改时,必须修订软件开 发计划。 说明:软件项目计划必须依据需求规格进行制定。项目计划中的工作产品和工作任务应保 证能完全实现需求规格的定义。当需求更改时,必须考虑需求更改的相关性,修订相应软 件开发计划。 2-1:制定软件项目计划的活动制定,必须遵守“软件项目计划规范”。 2-2:软件经理对软件项目计划的制定和结果负责。 2-3:软件经理和相关参与软件项目计划的制定和评审的人员,在参与计划制定之前必须经过软 件工程和软件项目计划制定流程的培训。 2-2:对于软件项目计划中各项工作产品和工作任务,必须进行规模和工作量的软件估计,并 在软件项目计划文档中记录估计的方法和估计数据。 说明:参考建议2-4到2-8。 2-4:可以使用PERT统计估计、专家判定平均法、经验类比估计、公式计算等方法,或以上方 法的组合,进行软件估计。 示例:PERT统计估计和经验类比估计的结合 PERT统计估计值 = (最大估计+4×期望估计+最小估计〕/ 6 估计记录如下: 工作产 品任务 XX版本 (增加 XX特 性〕话统 模块概 要设计 最大估计 规模 文档页 数:45;增 加、修改 模块设 计数 目:12 期望估计(根据经验 类比获得) 最小估计 PERT估计 工作量 规模 12天 文档页 数:42;增 加、修改 模块设 计数 目:10 工作量 规模 10天 文档页 数:30;增 加、修改 模块设 计数目:5 工作量 规模 5天 文档页 数:41;增 加、修改 模块设 计数 目:10 工作量 9.5天 期望估计值是根据XX版本的话统模块设计的数据获得。 仅供内部使用 8
分享到:
收藏