全部科目 > 系统架构设计师 >
2024年上半年 上午试卷 综合知识
第 15 题
知识点 可靠性指标与评估   需求分析   可靠性   软件可靠性管理   需求分析阶段  
关键词 分析阶段   软件可靠性   需求分析   可靠性   需求  
章/节 系统可靠性  
 
 
在软件可靠性管理过程中,以下工作不属于需求分析阶段应完成的是()。
 
  A.  分析可能影响可靠性的因素
 
  B.  确定软件的可靠性目标
 
  C.  可靠性建模
 
  D.  确定可靠性的验收标准




 
 
相关试题     系统可靠性 

  第8题    2025年下半年  
多道程序设计技术不仅使CPU得到充分利用,同时改善0设备和内存的( ),从而提高了整个系统的资源利用率和系统吞叶量(单时间内处理作业(程序)的个数),最终提高了整..

  第17题    2022年下半年  
系统(16)是指在规定的时间内和规定条件下能有效地实现规定功能的能力。它不仅取决于规定的使用条件等因素,还与设计技术有关。常用的度量指标主要有故障率(或失效..

  第40题    2024年下半年  
N版本设计较传统多了哪三个步骤。

 
知识点讲解
· 可靠性指标与评估
· 需求分析
· 可靠性
· 软件可靠性管理
· 需求分析阶段
 
        可靠性指标与评估
        14.2节讨论了系统可靠性的模型,那么,究竟如何来评估一个系统的可靠性呢?这就是本节要介绍的内容。
                      可靠性指标
                      与可靠性相关的概念主要有平均无故障时间、平均故障修复时间以及平均故障间隔时间等。
                             平均无故障时间
                             可靠度为Rt)的系统的平均无故障时间(Mean Time To Failure,MTTF)定义为从t=0时到故障发生时系统的持续运行时间的期望值,计算公式如下:
                             
                             如果,则MTTF=1/λλ为失效率,是指器件或系统在单位时间内发生失效的预期次数,在此处假设为常数。
                             例如,假设同一型号的1000台计算机,在规定的条件下工作1000小时,其中有10台出现故障。这种计算机千小时的可靠度R为(1000-10)/1000=0.99。失效率为10/(1000×1000=1×10-5)。因为平均无故障时间与失效率的关系为MTTF=1/λ,因此,MTTF=105小时。
                             平均故障修复时间
                             可用度为At)的系统的平均故障修复时间(Mean Time To Fix,MTTR)可以用类似于求MTTF的方法求得。设A1t)是在风险函数Zt)=0且系统的初始状态为1状态的条件下At)的特殊情况,则:
                             
                             此处假设修复率μt)=μ(常数),修复率是指单位时间内可修复系统的平均次数,则:
                             MTTR=1/μ
                             平均故障间隔时间
                             平均故障间隔时间(Mean Time Between Failure,MTBF)常常与MTTF发生混淆。因为两次故障(失败)之间必然有修复行为,因此,MTBF中应包含MTTR。对于可靠度服从指数分布的系统,从任一时刻t0到达故障的期望时间都是相等的,因此有:
                             MTBF=MTTR+MTTF
                             在实际应用中,一般MTTR很小,所以通常认为MTBF≈MTTF。
                      可靠性计算
                      计算机系统是一个复杂的系统,而且影响其可靠性的因素也非常繁复,很难直接对其进行可靠性分析。但通过建立适当的数学模型,把大系统分割成若干子系统,可以简化其分析过程。
                             串联系统
                             假设一个系统由n个子系统组成,当且仅当所有的子系统都有能正常工作时,系统才能正常工作,这种系统称为串联系统,如下图所示。
                             
                             串联系统
                             设系统各个子系统的可靠性分别用R1R2,…Rn表示,则系统的可靠性R=R1×R2×…×Rn
                             如果系统的各个子系统的失效率分别用λ1λ2,…,λn来表示,则系统的失效率λ=λ1+λ2+…+λn
                             并联系统
                             假如一个系统由n个子系统组成,只要有一个子系统能够正常工作,系统就能正常工作,如下图所示。
                             
                             并联系统
                             设系统各个子系统的可靠性分别用R1,…R2Rn表示,则系统的可靠性R=1-(1-R1)×(1-R2)×…×(1-Rn)。
                             假如所有的子系统的失效率均为λ,则系统的失效率为μ
                             
                             在并联系统中只有一个子系统是真正需要的,其余n-1个子系统称为冗余子系统,随着冗余子系统数量的增加,系统的平均无故障时间也增加了。
                             模冗余系统
                             m模冗余系统由m个(m=2n+1为奇数)相同的子系统和一个表决器组成,经过表决器表决后,m个子系统中占多数相同结果的输出作为系统的输出,如下图所示。
                             
                             模冗余系统
                             在m个子系统中,只有n+1个或n+1个以上子系统能正常工作,系统就能正常工作,输出正确结果。假设表决器是完全可靠的,每个子系统的可靠性为R0,则m模冗余系统的可靠性为:
                             
                             其中为从m个元素中取j个元素的组合数。
                             在实际应用系统中,往往是多种结构的混联系统。例如,某高可靠性计算机系统由下图所示的冗余部件构成。
                             
                             某计算机系统
                             显然,该系统为一个串并联综合系统,我们可以先计算出中间2个并联系统的可靠度,根据并联公式R=(1-(1-R1)×(1-R2)×…×(1-Rn),可得到3个部件并联的可靠度为1-(1-R3,2个部件并联的可靠度为1-(1-R2
                             然后,再根据串联公式R=R1×R2×…×Rn,可得到整个系统的可靠度:R×(1-(1-R3)×(1-(1-R2)×R
 
        需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在9.4节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis,PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               
               业务流程图符号
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括三个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,我们称它的上层图为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用三类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
        可靠性
        (1)完备性。完备性评价指标及测量,如下表所示。
        
        完备性评价指标及测量
        (2)连续性。连续性评价指标及测量,如下表所示。
        
        连续性评价指标及测量
        
        (3)稳定性。稳定性评价指标及测量,如下表所示。
        
        稳定性评价指标及测量
        (4)有效性。有效性评价指标及测量,如下表所示。
        
        有效性评价指标及测量
        (5)可追溯性。可追溯性评价指标及测量,如下表所示。
        
        可追溯性评价指标及测量
        
 
        软件可靠性管理
        为了进一步提高软件可靠性,人们又提出了软件可靠性管理的概念,把软件可靠性活动贯穿于软件开发的全过程。
        软件可靠性管理是软件工程管理的一部分,它以全面提高和保证软件可靠性为目标,以软件可靠性活动为主要对象,是把现代管理理论用于软件生命周期中的可靠性保障活动的一种管理形式。
        软件可靠性管理的内容包括软件工程各个阶段的可靠性活动的目标、计划、进度、任务、修正措施等。
        软件工程各个阶段可能进行的主要的软件可靠性活动如下所述。由于软件之间的差异较大,并且人们对可靠性的期望不同,对可靠性的投入不同,所以下面的每项活动并不是每一个软件系统的可靠性管理的必须内容,也不是软件可靠性管理的全部内容。
               需求分析阶段
               . 确定软件的可靠性目标;
               . 分析可能影响可靠性的因素;
               . 确定可靠性的验收标准;
               . 制定可靠性管理框架;
               . 制定可靠性文档编写规范;
               . 制定可靠性活动初步计划;
               . 确定可靠性数据收集规范。
               概要设计阶段
               . 确定可靠性度量;
               . 制定详细的可靠性验收方案;
               . 可靠性设计;
               . 收集可靠性数据;
               . 调整可靠性活动计划;
               . 明确后续阶段的可靠性活动的详细计划;
               . 编制可靠性文档。
               详细设计阶段
               . 可靠性设计;
               . 可靠性预测(确定可靠性度量估计值);
               . 调整可靠性活动计划;
               . 收集可靠性数据;
               . 明确后续阶段的可靠性活动的详细计划;
               . 编制可靠性文档。
               编码阶段
               . 可靠性测试(含于单元测试);
               . 排错;
               . 调整可靠性活动计划;
               . 收集可靠性数据;
               . 明确后续阶段的可靠性活动的详细计划;
               . 编制可靠性文档。
               测试阶段
               . 可靠性测试(含于集成测试、系统测试);
               . 排错;
               . 可靠性建模;
               . 可靠性评价;
               . 调整可靠性活动计划;
               . 收集可靠性数据;
               . 明确后续阶段的可靠性活动的详细计划;
               . 编制可靠性文档。
               实施阶段
               . 可靠性测试(含于验收测试);
               . 排错;
               . 收集可靠性数据;
               . 调整可靠性模型;
               . 可靠性评价;
               . 编制可靠性文档。
               可靠性管理目前还停留在定性描述的水平上,很难用量化的指标来进行可靠性管理。可靠性管理规范的制定水平和实施效果也有待提高。怎样利用有限的可靠性投入,达到预期的可靠性目标是软件项目管理者常常要面对的难题。因此,可靠性管理研究是一个长期的课题。
 
        需求分析阶段
        . 确定软件的可靠性目标;
        . 分析可能影响可靠性的因素;
        . 确定可靠性的验收标准;
        . 制定可靠性管理框架;
        . 制定可靠性文档编写规范;
        . 制定可靠性活动初步计划;
        . 确定可靠性数据收集规范。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2026 All Rights Reserved
软考在线版权所有