可靠性与系统工程学院课件20151023软件质量no3-避错上-new

1、软件避错设计北京航空航天大学可靠性与系统工程学院 2012.31 缺陷预防缺陷预防活动可以减少缺陷注入的机会，从而减少检测和排除注入的缺陷的费用23 Review：缺陷预防技术概述 软件开发方法：软件开发方法对软件的质量有着直接的影响。合适和合理的开发方法可以有效的预防软件缺陷，提高开发效率，增进软件的可靠性、安全性、易测试性和易维护性等质量指标。 软件配置管理：软件配置管理在软件质量管理和质量保证中起着重要作用，是CMM（软件能力成熟度模型）和ISO9000质量管理体系的核心内容之一，贯穿于整个软件生命周期。是一种非常有效的缺陷预防技术。 软件可靠性安全性设计：软件可靠性安全性设计准则是长期

2、以来人们对如何开发高质量、高可靠软件经验的总结， 遵循这些设计准则就可以有效地预防缺陷的发生。 自动化缺陷预防 软件避错设计从一开始就避免故障的引入， 是软件可靠性设计的首要方法。 目标 为什么要进行避错设计？ 什么是软件避错设计原理？ 软件需求阶段如何避错？ 软件需求文档有何要求？ 内容1 软件避错设计原理2 软件需求分析阶段的主要避错分析准则 避错是软件可靠性设计的首要方法 错误、故障是导致软件失效、不可靠、不正确的 根本 原因 应从一开始就避免错误的引入，尽可能减少故障体现 预防为主! 错误引入的越少，故障检测和改正的成本越低，失效 遏制的必要性和 成本也相应降低！ 软件避错设计首先要贯

3、彻软件工程化，软件开发遵循 软件工程化是软件避错设计的前提 需求和设计阶段的故障居多！软件开发周期各阶段需求分析设计编码与单元测试综合与测试运行与维护故障百分数%551713105 故障改正费用越晚越高！故障发生阶段需求分析设计编码与单元测试综合与测试运行与维护修正故障所需费 用百分数(%)57820601什么是软件避错设计原理？ 软件避错设计原理1. 简单原理2. 同型原理3. 对称原理4. 层次原理5. 线型原理6. 易证原理7. 安全原理 简单原理 简单原理是一种越简单越好的原理1. 需求分析时应贯彻自顶向下、逐层分解的方式对问题 进行分解和不断细化等2. 设计阶段时模块规模应该适中、

4、力争降低模块接口的复杂度、须对程序的圈复杂度进行限制等3. 编码阶段时在程序设计风格中要求数据说明应便于查 阅易于理解、语句应该尽量简单清晰等 同型原理 同型原理是保持形式一样的原理1. 需求分析组人员间应统一采用的需求建模方法、用统 一的文字、图形或数学方法描述每一项功能特性、遵 守统一的需求变更规范等2. 设计人员间采用统一的设计描述方法、遵守统一的设 计文档模板等3. 编码人员间采用统一的编程风格，如源程序的标识符 应该按其意思取名、如果标识符使用缩写，那么缩写 规则应该一致，并且应该为每个名字加注释等 对称原理 对称原理是保持形式对称的原理1. 功能需求分析时要求当输入有范围要求时，不

5、仅需要 列出输入在范围内的处理流程，而且需要列出输入在 范围之外的处理流程。2. 设计阶段特别强调需要进行异常情况设计。3. C语言编程时条件语句if与else一般是成对出现，对于只有if分支没有else分支的代码，应检查是否真的不需要else分支；还有switch语句每个case语句的结尾不要忘了加break，并且不要忘记最后那个default分支。 层次原理 层次原理是形式上和结构上保持层次分明的原理从软件的角度看，软件的层次化和模块化设计方法，其本质是将系统实施 简化的一种手段。 线型原理 线型原理是形式上最好能用直线描述、最多也只用矩形 描述的原理1. 函数树中发生逆向调用是不允许的，

6、因为它严重违反 了线型原理。GOTO语句要少用。2. 根据线型原理，IF、WHILE、FOR和SWITCH等语句的 使用要慎重。主要是这些语句的嵌套层次要控制，必 须限制圈复杂度的大小。 易证原理 易证原理是保持程序在逻辑上容易证明的原理1. 利用形式化方法应用于程序验证需要正确的严密定义，这些定义由形式规范给出需要专用工具的支持对复杂的软件系统，应用该技术仍有困难2. 根据易证原理，当采用定量的数值说明非功能需求时 应考虑系统的定量要求是否合理以及是否能够验证。 安全原理 安全原理是意识其必然稳妥的原理在软件设计和编码时，重点考虑以下注意事项和策略：1. 使用操作系统提供的 系统调用和函数调

7、用时，这些系统功能模块一般都提供该模块返回时的例外信息。这些信息反映了模块执行时可能出现的异常情况， 对这些情况均 要分别作妥当的处理，不能怕麻烦，不能有任何疏忽。2. 全面分析临界区，防止发生冲突动态。3. 动态资源有申请，就要有释放。采用有借有还策略，以免只借不还，将资源 消耗尽后造成系统故障。4. 对关键信息资源的使用，按照“权能”法，采用最小策略，多余的权力一律不给。5. 对于安全关键功能必须具有强数据类型；不得使用一位的逻辑“0”或“1”来表 示“安全”或“危险”状态；其判定条件不得依赖于全“0”或全“1”的输入2 需求阶段如何进行避错分析？2.1 软件需求分析阶段基本避错准则2.2

8、 功能需求分析准则2.3 非功能需求分析准则 软件需求分析阶段的工作 主要解决软件产品 应该“做什么”的问题 定义软件的范围及必须满足的约束 确定软件的功能和性能及与其他系统成分的接口，建立数据模型、功能模型和行为模型 提供需求规格说明，作为指导设计和评估软件质量的依据 需求定义了软件的输入、输出以及它们之间的关系 需求包括：功能需求+非功能需求2.1 软件需求分析阶段基本避错准则 准则A：软件需求分析人员必须和用户密切合作无论是软件需求分析人员还是用户都不可能单独 写出满意的软件需求规格说明书，而应由双方密 切合作，以需求分析人员为主并执笔，与用户联合编 制。各方人员在需求分析的时间投入时很

9、有必要的。 准则B：应采用统一的需求建模方法 同型原理要求 应根据软件的特点采用相应的建模方法和工具 主要方法： 数据模型 功能模型 行为模型 面向对象建模 ? (DFD,ERD,DD,用例图）1 数据咐加 I无效B单f数据谎名： 发票说用： 月作学生已付书款的依据数据流来源： 来自加1”审查并开发票” 数据流去向： 流向加1“开领书单”。/ /萃统维护者。1定义会议。2更改会议。心。3肘徐会议9会议室维护。义参加人贝会议人员管理数据流组成： 学号姓名书号单价总价书费合计10预定会议阮间8归还会议室软件质量和可靠性保证技术：软件避错设计20垃 讲义员第3章24 准则C：自顶向下、逐层分解的方式

10、进行分解和细化 是简单原理和层次原理的体现 对问题的分解分为横向和纵向 横向分解：如把一个功能分解成几个子功能，并确定这些子功能与父功能的接口 纵向分解：继续分解，把某些子功能又分解为小的子功能， 某个小的子功能又分解为更小的子功能53 准则D：需求文档要求软件需求分析阶段必须编制软件需求规格说 明文档，软件需求规格说明应遵守相应的格式和 内容要求，必须确保软件需求规格说明的 正确性、 无歧义性、完整性、一致性、可验证性、可修改 性和可追踪性。必要性优先级More? 正确性 正确性：一个软件产品的软件需求规格说明是 正确的， 当且仅当其中的每一条需求体现了该软件产品应该具备的特性。 Each

11、requirement must accurately describe the functionality to be delivered. The reference for correctness is the source of the requirement, such as a customer, regulatory or a higher-level system requirements specification. 无歧异性 无歧异性：一个软件产品的软件需求规格说明是 无歧 义的，当且仅当其中的每一条需求只有唯一的解释。 无歧义性就是要用唯一定义的术语来描述软件产品的各个特

12、性。如果一个术语在特定的上下文中可能有多种含义，那么要在术语表中规定其特定的含义。 Unambiguous Thereaderofa requirement statement shouldbeable todrawonlyone interpretation. Multiple readers ofa requirement should arrive at the same interpretation. Natural language is highly prone to ambiguity. Avoid subjective words like user-friendly, eas

13、y, simple, rapid, efficient, several, state-of-the-art, improved, maximize, andminimize.WordsthatarecleartotheSRauthor may not be clear to readers. Write each requirement in simple, straightforward language avoiding Acronyms and excessive technical or business jargon. 自然语言易产生歧义 Shoes must beworn. Do

14、gs must becarried 完整性 完整性：一个软件产品的软件需求规格说明是 完整的， 当且仅当它包含了以下成分： 所有与功能、性能、设计约束、属性、外部接口有关的重要需求，特别是系统规范中提出的外部需求。 软件对所有环境中的所有合法和非法输入数据的响应。 所有图、表的标识和索引，所有术语和量纲的定义。一般来说，含有“待定（TBD）”的软件需求规格 说明是不完整的。 Complete Focus on user tasks rather than on system functions during requirements elicitation is given, requirem

15、ents are neither less likely to be overlooked and unnecessary requirements are likely to excluded. 一致性 一致性：一个软件产品的软件需求规格说明是 一致的， 当且仅当独立的需求子集中没有矛盾： 对实际对象规定了相互矛盾的特性 两个规定的动作之间有逻辑或时序的矛盾 用不同的术语描写同一个对象 Consistent Consistent requirements donot conflictwithother software requirements or with higher level (s

16、ystem or business) requirements. Disagreements among requirements must be resolved before development can proceed. Be careful when modifying the requirements, as inconsistencies can slip in undetected if a review of the specific change only is carried out andnot any related requirements. 可验证性 可验证性：一

17、个软件产品的软件需求规格说明是 可验 证的，当且仅当每一条需求都可用某种成本有限的过 程来检测其是否被软件产品满足。如果对一条需求找 不到验证的方法，应改写或删除它。 Verifiable Cantestsorotherverificationapproaches,suchas inspection or demonstration, determine whether each requirement is properly implemented in the product. If a requirement is not verifiable, determining whether

18、it wascorrectlyimplementedisa matterofopinion.Requirements that are not consistent, feasible, or unambiguous also are not verifiable. Any requirement that says the product shall support something is not verifiable. 可修改性 可修改性：一个软件产品的软件需求规格说明是 可修 改的，当且仅当可以容易地、完整地和一致地更改某 些需求并保持整个文档的结构和风格。 Modifiable Re

19、visionof the requirements document must be possible. When necessary maintain a history of changes made to each requirement. This ability is inherent within a properly set up DOORS environment. 可追踪性 可追踪性：一个软件产品的软件需求规格说明是 可追 踪的，当且仅当每一条需求有明确的出处并且便于被 其它文档引用。 建议采用以下两种可追踪性： 向上可追踪性，即标明每一条需求的来源。 向下可追踪性，即每一条

20、需求有唯一的标识供其它文档引用。 实现可追踪性的必要条件是每一条需求要有唯一的标识号。 Traceable Each requirement must be traceable toitssource. Also link each requirement to the design elements, or analysesthatare constructed to implement and verify the requirement. Traceable requirements are uniquely labelledand are written in a structured

21、, fine-grained way, as opposed to large, narrative paragraphs or bullet lists Necessary A requirement should document something the customers need or something that is required for conformance to an external requirement, interface, or design/regulatory standard. A way to understand necessary is that

22、 a requirement originates from a source recognized as having the authority to specify requirements. Trace each requirement back to its origin, such as a use case, system requirement, regulation, or some other voice-of-the-customer input. If the origin cannot be identified, the requirement may be an

23、example of gold plating and not really necessary. Feasible It must be possible to implement each requirement within the capabilities and limitations of the system andenvironment. Toavoid infeasible requirements, a system specialist should be encouraged to work with the requirements analysts througho

24、ut the elicitation process. The system specialist can provide a reality checkon whatcanandcannotbe done technically, and what can be done only at excessive cost or with other tradeoffs. Prioritized Indicate how essential it is to include it in a particular product release. Customers or their surroga

25、tes have the responsibility forestablishing priorities. Ifall the requirements are regarded asequally important, the project manager is less able to react to new requirements added during development, budget cuts, scheduleoverruns, or the departureof astakeholder. 准则E：需求外部评审软件需求分析完成后必须进行软件需求外部评审， 以确

26、保对软件需求理解的一致性和准确性。 准则F：需求变更要求 需求变更要立即联系，并遵照制定的软件需求变更 规范。发生需求变更，必须经过变更申请、变更评估、决 策、验证这4个步骤，一般需遵循以下要求：1. 必须完整、准确地说明修改内容和原因。2. 提供准确和完整的审查记录，并同时保存修改前和修改后的条款。3. 对软件需求的更改必须执行配置管理规范，严格实施更改管理。4. 对更改过的软件需求在软件需求规格说明中必须有更改记录；确保对有关文档进行。2.2 功能需求分析准则 准则A：必须全面了解软件的每一项功能， 应明确每个功能的输入、输出及之间关系 必须确保与功能有关的所有输入信息： 包括其来源、意义

27、、格式、接收方法、数量、输入范围及换算方法，必须说明时间要求、优先顺序（常规作业、紧急情况），操作控制要求和所用的输入媒体 必须描述与功能有关的所有输出信息 包括信息的传送方法、意义、格式、数量、输出范围及换算方法，必须说明时间要求、优先顺序和输出形式（显示、打印等） 可通过流程表明输入输出关系 准则A：必须全面了解软件的每一项功能，需求 R1R2R3R4R1 冲突 R2冲突 重叠 R3 重叠 R4 重叠 重叠 所有的软件功能都应该被清楚地标识和编号，保证所有的需求不会重叠或冲突，可使用如下需求依赖矩阵 需求分析时如果有上一级文件作为依据，则应明确需求与上一级文件中对该需求的映射关系，可以使用

28、如下追踪表 准则B：要列出输入在范围之外的处理流程例：某模块DTPP根据输入“操作控制字”不同时执 行不同的任务，“操作控制字”为二位BIT，取值为0、 1、2、3，取值1、2为合理范围，其他为无效范围， 其处理流程应写成：1. 当操作控制字为1时，DTPP执行上电BIT任务，上电BIT 任务完成RAM BIT；2. 当操作控制字为2时，DTPP执行启动BIT任务，启动BIT 任务完成RAM BIT、ROM BIT；3. 当操作控制字为其它时，DTPP不响应（输入在范围之外的处理流程）。 准则C：对可能的异常情况，考虑相应的保护措施必须仔细分析软件运行过程中各种可能的异常情况，处理过程应考虑相

29、应的保护措施。特别当采用现成软件时，必须仔细分析原有的异常保护措施对于现有的软件需求是否足够且完全使用。异常处理措施必须使系统转入安全状态，并保持计算机处于运行状态。 准则D：定义软件功能所涉及的各种数据所有软件定义与开发工作最终是为了解决数据处 理问题，就是将一种形式的数据转换成另一种形式的 数据。其转换过程必定经历输入、加工数据和产生结 果数据等步骤，所以定义软件功能时一定会涉及到相 关的数据，必须规定 静态数据、 动态输入输出数据及 内部生成数据的逻辑结构，列出这些数据的 ，说 明对数据的约束。同时，必须规定 数据采集的要求， 说明被采集数据的特性、要求和范围。对重要的数据 使用前后都要

30、进行检验。 推荐建立数据字典，并阐明 数据的来源、处理及目的地。 准则D：定义软件功能所涉及的各种数据定义软件功能所涉及的各种数据， 明确数据的度 量单位、精度、分辨率等信息例：输出量故障码字节编码说明数据位（8bit）内容 说明 D7RAM故障 1=故障 D6ROM故障 1=故障 D5WDT故障 1=故障 D4键盘卡死故障 1=故障 D3D0备用 02.3 非功能需求分析准则 非功能性要求有哪些？外部质量 功能性 可靠性 易用性 效率 维护性 可移植性 适合性 准确性互操作性安全保密性 成熟性容错性易恢复性 易理解性易学性易操作性吸引性 时间特性 资源利用性 易分析性易改变性稳定性易测试性

31、适应性易安装性共存性 易替换性 54功能性的依从性 可靠性的依从性 易用性的依从性 效率的依从性 维护性的依从性 可移植性的依从性 准则A：须全面分析软件有哪些非功能需求 非功能需求能使软件更准确、高效、可靠地完成任务。 例：用户要求产品要“界面友好”或“健壮”或“高效率” 对于分析人员来讲，太主观了并无实用价值 分析人员通过询问和调查了解客户所要的“友好、健壮、高权衡，以确保做出合理的取舍63 准则B：定量要求应合理、可达且可验证 定量的度量： 性能： 存储器的容量： 一般包括处理的记录数和处理数据的最大容量等 精度要求：一般包括数据或数值计算的精度要求、数据传输的精度要求等。 时间特性要求

32、：一般包括处理时间、响应时间等。 对实时嵌入式软件，实时性要求：一般包括周期任务处理时间、中断响应时间、采集数据时间、两次输出间隔时间等。 可靠性： 可靠度，失效率，MTTF等 准则B：定量要求应合理、可达且可验证例：以下是一些软件的给定的定量要求 存储容量：ROM 256K，RAM 256K 处理时间：每5毫秒处理MBI数据，每50毫秒处理IOP接口数据。 5ms内导入的数据大小1M 1ms内处理的记录数为10000条 准则C：对于需要处理避免敏感数据的软件保密性要求可以采用加密算法、保存数据历史 、把功能分配到不同模块；限制某些软件内部通信；检查关键数据的完整性。例：为保证子系统所处理的各

33、类数据的保密性，子系统基于Oracle数据库提供C3级数据安全 保密等级，并提供用户管理、角色管理、权限管理、用户审计等安全管控手段，保障各类数据的使用安全。 软件需求问题实例 一架飞机原用硬件控制 发射器，后改为用软件控制发 射器。该飞机按照标准正确地进行了修改，软件在交付运行测试前进行了所有级别的测试。充分测试了标准 挂架接口和安全性补偿。该飞机装载了一枚实际 （带有一个无效的弹头），并被送到测试点火的空间。 飞机得到命令点燃该，它按照设计进行了点火。不幸， 设计并未详细说明解锁暂停装置的时间量，而由编程人员 按自己的假设编码。在这种情况下，假设的解锁时间不足，致使在离开挂架之前暂停装置被锁着。随着被加电，在 与飞机连接状态下发动机驱动了 。这导致丧失高度和野蛮航行，但