软件体系结构的质量特性
- 格式:doc
- 大小:280.00 KB
- 文档页数:18
软件体系结构5_软件体系结构的质量属性
1. 性能(Performance):性能是衡量软件体系结构完成特定任务所需的时间和资源的能力。
在性能方面,主要关注的指标包括响应时间、吞吐量和资源利用率。
一个好的体系结构应能够支持大规模并发用户使用,而不会因为系统负载增加而导致性能下降。
2. 可用性(Availability):可用性是指软件体系结构在特定时间内处于可操作状态的能力。
可用性主要与系统的可靠性、容错性和可恢复性相关。
一个可靠的软件体系结构应能够及时响应用户需求,并尽量减少停机时间和故障恢复时间,提供稳定、可靠的服务。
3. 可靠性(Reliability):可靠性是指软件体系结构在给定的时间内正确执行其功能的能力。
可靠性与系统的错误率和故障率相关。
一个可靠的软件体系结构应能够预防和容忍异常情况,以确保正确的运行,保证数据的完整性和准确性。
4. 安全性(Security):安全性是指软件体系结构在防止未经授权的访问和保护用户数据等方面的能力。
软件体系结构应能够识别和阻止潜在的安全威胁,如恶意攻击、非法访问和数据泄露等。
安全性要求通常包括认证、授权、加密和审计等功能。
5. 可扩展性(Scalability):可扩展性是指软件体系结构能够在不同规模和负载下进行水平或垂直扩展的能力。
一个可扩展的软件体系结构应能够动态调整资源,并能够在需要时自动增加或减少处理能力,以适应不断变化的用户需求。
总之,软件体系结构的质量属性是衡量软件体系结构能力和性能的关键指标。
在设计软件体系结构时,需要充分考虑这些质量属性,以确保软件能够满足用户的需求,并具有高性能、可靠性、安全性和可扩展性。
一、什么是软件系统结构软件体系结构也称为软件构架(有时简称构架),是系统的一个或多个结构,它包括:软件的组成元素(组件),这些元素(组件)的外部可见特性,以及这些元素(组件)之间的相互关系。
含义:(1)系统由一个或多个结构组成,其中任何一个结构并不能与构架等同。
(2)每个系统都有一个体系结构。
(3)软件体系结构是系统的抽象。
(4) 构架定义了软件元素以及各元素间的交互关系。
(5) 以往作为体系结构传递的线框图,事实上并等同于体系结构。
二、构架商业周期(ABC)1.构架由什么决定?构架是否由系统需求决定?×软件构架是技术、商业和社会因素共同作用的结果。
2. 构架从哪里来?(影响构架的因素)影响构架的因素主要包括:❑系统涉众(stakeholder)、主要有:管理者:成本要低,人人都得干活营销人员:特性突出、投放市场快、成本低、可与同类产品相匹敌。终端用户:行为、性能、安全性、可靠性、易用性。维护人员:可修改性强。客户:成本低、及时交付、不要频繁修改。❑开发组织・组织内对现存构架的重用・对某个基础设施进行长期的商业投资以实现某些战略目标・开发组织本身的机构也会影响构架的形成❑构架师的素质和经验构架师先前的一些经验、教育、培训以及所接触到过的成功构架模式都会影响到他们对某种构架的选择。
❑技术环境当前技术发展水平代表了某个时代的构架师的普遍素质和经验,对架构有很大的影响力。
❑其它因素其它如社会、法律、人文环境等都会对构架产生影响。
3.构架的反影响力・构架会影响开发组织的结构・构架会影响开发组织的目标・构架会影响客户对下一个系统的要求・构建系统的过程丰富了整个开发团队的经验,从而将影响设计师对后继系统的设计・一些系统会影响并实际改变软件工程的环境,也就是系统开发人员学习或实践的技术环境。
4.构架的商业周期软件构架是技术、商业和社会等诸多因素作用的结果,而软件构架的存在反过来又会影响技术、商业和社会环境,从而影响未来的软件构架。
摘要在软件开发过程中,软件的质量是一个重要的因素,而软件体系结构在整个过程中显得尤为重要。
软件的质量需求是在开发初期的非功能性需求,对软件的体系结构影响很大。
但是并不意味着一味的追求质量,必须在效率和质量之间寻求一个平衡点。
为了实现高的软件质量,软件体系结构必须具有良好地可移植性,可靠性,可维护性,适应性,互用性,组件复用和实时性等方面的要求。
ISO/IEC 9126-1 :软件产品评估—质量特性及其使用指南纲要。
在此标准中,定义了六种质量特性,并且描述了软件产品评估过程的模型。
该技术将质量这一大的特性细化到属性级别或可测项。
这样,就可以通过比较这些属性、可测项从一系列候选体系结构中选择出一个合适的来开发软件。
在此标准中,定义了六种质量特性,27个子特性,并且描述了软件产品评估过程的模型。
1.功能性:是指当软件在指定条件下使用,软件产品满足明确和隐含要求功能的能力,即适合性;并且能够得到正确或相符的结果或效果,即准确性;拥有能够和其他指定系统进行交互的能力,即互用性;防止对程序或数据的未经授权访问的能力,即安全性。
2.可靠性:在指定条件下使用时,软件产品维持规定的性能水平的能力。
其中包括成熟性,指软件产品避免因软件中错误发生而导致失效的能力;容错性:是指在软件发生故障或违反指定接口的情况下,软件产品维持规定的性能水平的能力;易恢复性:是指在失效发生的情况下,软件产品重建规定的性能水平并恢复受直接影响的数据的能力。
3.易用性:是指在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力。
4.效率:是指在规定条件下,相对于所用资源的数量,软件产品可提供适当的性能的能力。
其中,时间特性:是指在规定条件下,软件产品执行其功能时,提供适当的响应时间和处理时间以及吞吐率的能力;除此之外,资源利用性:是指在规定条件下,软件产品执行其功能时,所使用的资源数量及其使用时间。
5.可维护性:是指软件产品可被修改的能力,修改可能包括修正,改进或软件适应环境、需求和功能规格说明中的变化。
ISO/IEC9126的软件质量模型包括6个质量特性和21个质量子特性。
(1)功能性(Functionality)功能性是指与软件所具有的各项功能及其规定性质有关的一组属性,包括:■适合性(Suitability):与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性。
适合程度的例子是面向任务系统中由子功能构成功能是否合适、表容量是否合适等。
■准确性(Accuracy):与能否得到正确或相符的结果或效果有关的软件属性。
此属性包括计算值所需的准确程度。
■互操作性(互用性,Interoperability):与同其他指定系统进行交互的能力有关的软件属性。
为避免可能与易替换性的含义相混淆,此处用互操作性(互用性)而不用兼容性。
■依从性(Compliance):使软件遵循有关的标准、约定、法规及类似规定的软件属性。
■安全性(Security):与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性。
(2)可靠性(Reliability)可靠性是指在规定运行条件下和规定时间周期内,与软件维护其性能级别的能力有关的一组属性。
可靠性反映的是软件中存在的需求错误、设计错误和实现错误,而造成的失效情况。
包括:■成熟性(Maturity):与由软件故障引起失效的频度有关的软件属性。
■容错性(Fault tolerance):与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性。
指定的性能水平包括失效防护能力。
■可恢复性(Recoverability):与在失效发生后,重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和努力有关的软件属性。
(3)可用性(Usability)可用性是指根据规定用户或隐含用户的评估所作出的关于与使用软件所需要的努力程度有关的一组属性。
包括:■可理解性(Understandability):与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性。
盛年不重来,一日难再晨。
及时宜自勉,岁月不待人。
软件体系结构的质量特性摘要:众所周知的是,为了降低风险和减少构建软件系统的困难,人们在软件开发过程的早期应该首先考虑质量问题。
此外,系统的结构驱动着整个开发过程。
备用的结构中非功能性质量需求的实现决定了选择衔接整个系统的便利结构。
这一议题在可靠的变革的应用程序构建中非常重要。
软件开发的思想并没有在这一重要阶段给与很多细节关注。
这篇文章详述了软件体系结构的质量特性,并且介绍了一种基于ISO 9126-1标准的技术。
ISO模型的质量特性被精炼成为一种属性。
而这种属性可被度量以增加体系结构的信息。
我们的技术通过比较各自的质量属性的值从一组候选中挑选出适当的体系结构。
并以一个关于监制系统技术应用程序为例说明。
我们的方法有助于在体系结构分析过程中正确选择的决定。
它可以很容易的被并入一般软件开发的过程或者一种特别的体系结构设计思想。
简介:在软件开发早期阶段以非功能需求为目标的质量需求极大的影响了软件系统的体系结构。
但是,系统核心功能需求的提取在初始的系统结构的确定上扮演着重要的角色。
另一方面,质量需求在软件设计阶段需要平衡[Kazman et al. 2000]。
仅仅在最近,精确的软件体系结构设计的重要性(并不是局限于笔纸图画符号的设计方式)为了可靠的系统结构而蓬勃的发展起来[Bachmann et al.1996], [Bosch 2000], [Krutchen 2000].。
那些包括istribution, adaptability, interoperability, component reusability and real-time issues 现代的应用软件需要一个早期的体系结构的定义来满足可维护行和可靠性之类的质量需求。
这些对于在架构之下的软件系统全部功能性需求目标的完成是至关重要的。
特殊的,使用网络服务的新的信息系统,比如基于网络的电子商务应用程序,没有过多关心软件工程的时间而是因市场需求而发展的及其迅速。
中华人民共和国国家标准GB/T16260—1996idt ISO/IEC9126:1991信息技术软件产品评价质量特性及其使用指南Information technology-software product evaluation-Quality characteristics and guidelines for their use----------------------------------------------------------- 1.范围本标准定义了六个特性,它们以最小的重迭描述了软件质量。
这些特性可以作为进一步细化和描述软件质性的基线。
本际准描述了如何使用质量特性来评价软件质量。
本标准正文不规定子特性和度量以及有关测量(masurement)、评级(rating)和评估(asscssment)的方法。
本际准符合GB/T 6583-92的质量定义。
注:在附录A中提供了子特性定义的建议,供参考。
本标准的特性定义和相关的质量评价过程模型适用于对软件产品质量需求的确定以及在软件生存期中对软件产品质量的评价。
这些特性运用于各种软件,包括固件中的计算机程序和数据。
本标准供获取(acquisition)、开发(development)、使用(use)、支持(support)、维护(maintenancen)或评审(audit)软件的那些人所使用。
2.引用标准下列标准包含的条文,通过在本标准中引用而构成为本标准的条文。
本标准出版时,所示版本均为有效。
所有标准都会被修订.使用本标准的各方应探讨使用下列标准最新版本的可能性。
.GB/T 6583-92质量术语(idt ISO 84O2:1986)部分:系统开发2O第词汇信息技术1990 :2O-ISO/IEC 2382.3.定义下列定义适用于本标准3.1发评估assessment为了确定一特定的软件模块、软件包或软件产品是验收合格还是发布,把特定的已成文的评估准则应用到该软件模块、软件包或软件产品上去的活动。
软件体系架构的质量属性摘要:软件架构(及软件架构设计师)重点关注的是质量属性。
本⽂从常见的六个质量属性,即可⽤性、可修改性、性能、安全性、可测试性、易⽤性写起,使读者对其有初步的认识和了解。
解决了在具体的软件开发环境中的质量属性是什么,怎么⽤,如何⽤好的问题。
只⽤遵循质量属性的原则,才能有好的设计思想,才能开发出好的软件产品。
关键字:质量属性、软件体系架构、架构设计软件属性包括功能属性和质量属性,但是软件架构重点关注的是质量属性。
架构的基本需求主要是在满⾜功能属性的前提下,关注软件质量属性。
软件的质量属性可列举很多,也有各种不同的分类法和不同的表述。
⼀般将质量属性分为3类:系统的质量属性。
可⽤性,可修改性,性能,安全性,可测试性和易⽤性。
受架构影响的商业属性(上市时间)。
与架构本⾝相关的⼀些质量属性(如概念完整性),它们会间接影响其他质量属性,如可修改性。
1. 可⽤性(Availability)可⽤性与系统故障及其相关后果有关。
当系统不再提供其规范中所说明的服务时,就出现了系统故障。
所关注的⽅⾯有:(1)如何检测系统故障(2)系统故障发⽣的频度(3)出现故障时会发⽣什么情况(4)允许系统有多长时间⾮正常运⾏(5)什么时候可以安全地出现故障(6)如何防⽌故障的发⽣以及故障时要求进⾏哪种通知在计算可⽤性时,通常不考虑预定的停机时间(即停⽌服务),因为根据定义是”不需要“系统的。
这就导致会出现这种情况:系统停⽌运⾏,⽤户等待系统提供服务,但因为停机时间是预定的,因此不计⼊故障时间,也就不会影响可⽤性的数值。
可⽤性定义:可⽤性是指系统正常运⾏时间的⽐例,是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运⾏的速度来衡量的。
可⽤性⼀般场景:所关注的⽅⾯包括系统故障发⽣的频率、出现故障时会发⽣什么情况、允许系统有多长是将⾮正常运⾏、什么时候可以安全地出现故障、如何防⽌故障的发⽣以及发⽣故障时要求进⾏哪种通知。
软件产品质量特性之全面解读:功能、可靠性、安全性等的重要性软件产品质量特性是软件开发过程中需要关注的重要方面,它直接关系到软件产品的可用性、可靠性、安全性、可维护性、可扩展性等方面。
以下是软件产品质量特性的详细内容:一、功能性功能性是指软件产品能够满足用户需求的能力。
在软件开发过程中,需要根据用户需求进行功能设计、功能实现和功能测试,以确保软件产品能够实现用户所需的功能,满足用户的需求。
二、可靠性可靠性是指软件产品在规定条件下,在规定时间内完成规定功能的能力。
可靠性包括稳定性、健壮性和可用性等方面。
在软件开发过程中,需要采用可靠性设计、测试和维护等措施,以确保软件产品的可靠性。
三、安全性安全性是指软件产品保护用户数据和信息安全的能力。
在软件开发过程中,需要采取安全措施,如数据加密、访问控制、漏洞修复等,以确保软件产品的安全性。
四、可维护性可维护性是指软件产品能够被维护和修改的能力。
在软件开发过程中,需要采用可维护性设计、编码规范、测试等措施,以提高软件产品的可维护性。
五、可扩展性可扩展性是指软件产品能够适应未来变化和发展的能力。
在软件开发过程中,需要考虑软件产品的可扩展性,以便在未来能够适应新的需求和技术变化。
六、易用性易用性是指软件产品能够被用户方便地使用的能力。
在软件开发过程中,需要关注用户体验和易用性设计,以提高软件产品的易用性。
七、可测试性可测试性是指软件产品能够被有效测试的能力。
在软件开发过程中,需要采用可测试性设计、测试策略和测试工具等措施,以提高软件产品的可测试性。
八、可重用性可重用性是指软件产品能够在其他应用场景中被重复使用的能力。
在软件开发过程中,需要考虑软件产品的可重用性,以便在其他应用场景中重复使用。
九、可移植性可移植性是指软件产品能够在不同平台和环境下运行的能力。
在软件开发过程中,需要考虑软件产品的可移植性,以便在不同平台和环境下运行。
十、兼容性兼容性是指软件产品能够与其他产品或系统协同工作的能力。
软件工程6 软件体系结构在当今数字化的时代,软件已经成为我们生活和工作中不可或缺的一部分。
从智能手机上的各种应用程序,到企业内部复杂的业务系统,软件的质量和性能直接影响着用户的体验和业务的效率。
而软件体系结构作为软件工程中的一个重要领域,对于软件的成功开发和维护起着至关重要的作用。
那么,什么是软件体系结构呢?简单来说,软件体系结构就是软件系统的高层结构和组织方式。
它描述了软件系统中的组件、组件之间的关系以及它们如何协同工作来实现系统的功能。
就好比盖房子,软件体系结构就是房子的设计蓝图,决定了房子的布局、结构和各个部分的连接方式。
一个好的软件体系结构具有许多重要的特性。
首先,它应该具有可扩展性。
随着业务的发展和用户需求的变化,软件系统需要能够方便地进行功能的增加和修改。
如果体系结构设计得不合理,可能会导致在添加新功能时牵一发而动全身,需要对整个系统进行大规模的重构,这不仅费时费力,还可能引入新的错误。
其次,软件体系结构应该具有高可靠性和容错性。
软件系统在运行过程中难免会遇到各种故障和错误,一个良好的体系结构能够确保系统在出现部分故障时仍能继续运行,或者能够快速地从错误中恢复,从而保证系统的稳定性和可用性。
再者,性能也是软件体系结构需要考虑的重要因素。
这包括系统的响应时间、吞吐量、资源利用率等方面。
通过合理的体系结构设计,可以优化系统的性能,提高系统的运行效率,满足用户对于系统速度和效率的要求。
软件体系结构的设计过程并不是一蹴而就的,它需要综合考虑多种因素。
首先,要对系统的需求进行深入的分析和理解。
这包括了解系统的功能需求、性能需求、安全需求等。
只有清楚地知道系统需要做什么,才能设计出合适的体系结构。
在需求分析的基础上,选择合适的体系结构风格也是非常关键的一步。
常见的体系结构风格有分层架构、客户端服务器架构、微服务架构等。
每种风格都有其特点和适用场景,例如分层架构将系统分为不同的层次,每层完成特定的功能,具有结构清晰、易于维护的优点;客户端服务器架构则适用于分布式环境下的系统,能够有效地实现资源共享和负载均衡;微服务架构则将系统拆分成多个独立的服务,每个服务可以独立开发、部署和扩展,提高了系统的灵活性和可扩展性。
软件质量体系标准
软件质量体系标准主要包括以下几个方面:
1. 功能性:软件应该提供满足用户需求的功能,并且正确、准确地完成各项任务。
2. 可靠性:软件在各种情况下都能稳定运行,不会出现突然崩溃或数据丢失等问题。
3. 易用性:软件的用户界面友好,操作简单易懂,符合用户习惯。
4. 效率性:软件能够快速响应用户操作,处理速度满足用户需求。
5. 维护性:软件的代码结构清晰,易于修改和维护。
6. 兼容性:软件可以与各种不同型号、不同配置的硬件和软件进行兼容。
7. 可扩展性:软件可以适应业务发展和用户需求的变化,方便地进行升级和扩展。
8. 安全性:软件采取必要的安全措施,保护用户数据和隐私。
以上标准可以通过制定相应的质量保证计划、进行代码审查、测试验收、上线部署等环节来保证实现。
同时,持续改进也是软件质量体系标准的重要一环,通过不断优化和改进,可以提高软件的质量水平,提升用户体验。
软件体系结构的质量特性摘要:众所周知的是,为了降低风险和减少构建软件系统的困难,人们在软件开发过程的早期应该首先考虑质量问题。
此外,系统的结构驱动着整个开发过程。
备用的结构中非功能性质量需求的实现决定了选择衔接整个系统的便利结构。
这一议题在可靠的变革的应用程序构建中非常重要。
软件开发的思想并没有在这一重要阶段给与很多细节关注。
这篇文章详述了软件体系结构的质量特性,并且介绍了一种基于ISO 9126-1标准的技术。
ISO模型的质量特性被精炼成为一种属性。
而这种属性可被度量以增加体系结构的信息。
我们的技术通过比较各自的质量属性的值从一组候选中挑选出适当的体系结构。
并以一个关于监制系统技术应用程序为例说明。
我们的方法有助于在体系结构分析过程中正确选择的决定。
它可以很容易的被并入一般软件开发的过程或者一种特别的体系结构设计思想。
简介:在软件开发早期阶段以非功能需求为目标的质量需求极大的影响了软件系统的体系结构。
但是,系统核心功能需求的提取在初始的系统结构的确定上扮演着重要的角色。
另一方面,质量需求在软件设计阶段需要平衡[Kazman et al. 2000]。
仅仅在最近,精确的软件体系结构设计的重要性(并不是局限于笔纸图画符号的设计方式)为了可靠的系统结构而蓬勃的发展起来[Bachmann et al.1996], [Bosch 2000], [Krutchen 2000].。
那些包括istribution, adaptability, interoperability, component reusability and real-time issues 现代的应用软件需要一个早期的体系结构的定义来满足可维护行和可靠性之类的质量需求。
这些对于在架构之下的软件系统全部功能性需求目标的完成是至关重要的。
特殊的,使用网络服务的新的信息系统,比如基于网络的电子商务应用程序,没有过多关心软件工程的时间而是因市场需求而发展的及其迅速。
此外,此种产品的质量不在讨论范围之内。
然而,当一个HTML页面在浏览器端显示出来的时候,我们马上就能意识到我们是否使用了一个好的或者坏的网络应用程序。
像可用性,可靠性或有效性等的因素涉及到这个快速的评估。
事实上,自从系统开发之初,软件开发者们对网络应用程序的质量特性就没有一个清晰的描述,正如我们所指出的,软件工程的范例通常被忽略。
比如,即使当应用程序数据的语义与描述分离是一个可接受的范例,H TML i s n o r m a ll y u se dr e g a r d l e ss o f t h i s i ssue,直到最近,XML才被接受。
于是,质量需求的详述就成为了一个有趣的问题。
在功能需求的详述过程中,质量需求可能会隐藏的出现,比如在一个纯文本用例或一个方案中。
但是在标准的面向对象思想中没有直接的指导方法和清晰的建模原理来捕获或详细描述质量需求。
并且我们直到软件体系结构的设计不是一个独立的行为,而是软件产品开发和改良过程中的更进一步的阶段。
软件体系结构应该作为一个主要的侧重点以建立更清晰可重用的软件框架f o r gu a r a n t ee i ng t o a c e r t a i n e x t e n t,t h eo v e r a ll qu a li t y o f t h e r esu l t i ng so f t w a r e p r o du ct s.本篇文章的主要目的是介绍(建议)一种基于ISO 9126-1 [ISO/IEC 1998]标准的技术来描述相应的软件质量特性,而这种技术为品质等级或其他可测量的要素所精确描述,并参与软件体系结构的设计过程之中。
作为体系结构设计阶段中,质量特性的详细说明和规范度量是软件体系结构改进过程的基础,而这些改进过程允许对最初设计进行改进和增加。
这种基于系统的某些关键功能需求而选择的备案在设计过程中不断被转变和改进以达到预期的质量目标,而这些质量目标正是系统应当达到的质量需求的价值所在。
在这一过程中为了最终的系统,质量需求经常被转化为隐性的功能需求[B osch2000],比如最终的系统把这些需求表达为附加的机制。
但是,在一般习惯性的软件分析和设计思想中,这些质量特性的详述和评估的表述仅仅基于设计者的经验。
ATMT(基于构架的权衡分析方法)[K a z m a n e t a l.2000]与我们的方法有一些共同之处。
它使用了一种称之为u t ili t y(sy s t e m g oo dn e ss)t r ee的质量特性详述标准来将基于精确质量特性的方案分清主次。
体系结构和属性的信息被收集到ABAS(A tt r i bu t e-B a se d A r ch i t e ct u r a l S t y l e)框架中[K l e i n a nd K a z m a n1999].。
但是如何获得质量视图是如此描述和为何仅有一个描述等级的utility tree并不清楚,并且质量特性的解释并不标准。
utility tree通过一组可被驱动的体系结构测试方案来给与方案优先权来确定关键之处。
特性的测量通过stimuli,参数和响应来显示。
我们的方法使用根据ISO 9126-1标准的质量模型来考虑质量需求的详述。
这个在结构上接近ATAM质量树的等级模型对于软件体系结构很合适。
ISO质量模型现在是软件工业的标准并且它通过高度抽象的层次来解释。
它由内部和外部因素和使用品质特性视图的质量决定的。
这种质量特性(ATAM的特性)恰好被很标准的解释,并且特性的度量通常很普遍,它可以为详细的应用做更进一步的解释。
软件运行环境的质量是由用例模型的质量决定的,也就是在上下文的使用中,用户对于质量的观点。
此篇文章中我们只关心有关内外因素质量模型,而这个质量模型分别描述了用户和开发者的观点。
为了完备使用的质量,这个系统必须达到内部和外部的目标。
在软件开发过程中出现如下情况:当软件作为电脑系统中的一部分和内部软件评估或是实体属性测量的结果时,质量特性常常被详细描述为显现的外在子特性。
在我们的例子中,不得不把这些属性转化或翻译成称之为媒介软件产品的软件体系结构。
在软件开发过程中获得的特性的值可被用来校验内部的质量目标,而这些内部的质量目标有助于确认最终软件系统要求的外部目标[SO/I E C1998].。
拥有质量特性详细描述这样的事实为体系结构详细说明增加了更多的信息,这样有助于为解决特定设计问题而挑选体系结构的设计过程。
除了介绍和结论,;论文的主要部分如下:——为详述软件体系结构的质量特性,给出了一个基于ISO 9126-1标准的通用质量模型的描述。
——一个实例的研究,在这个实例中,我们将获得的通用质量模型来进行使用网络设备的实时监视系统软件体系结构的选择。
2、为软件体系结构而修改的ISO 9126-1质量模型。
ISO 9126-1质量模型:根据ISO 9126-1标准[ISO/IEC, 1998],质量被描述为一组产品或服务的特色或特性,而这些特色和特性是基于自己的能力来满足显性或隐性的需求。
同时,对于质量定义的不同看法也应被尊重:从用户角度来看,它是最终产品的质量;从开发者的角度来看,它是在开发过程中由不同的项目相关人员生产的中间产品的质量。
从终端管理者角度来看,它是营销的需求。
所有产品的质量都可以被不同观点的集合所表达。
在我们的文章中,用户和开发者(架构师)的观点角度将会被采纳。
MCCALL的工作区分了两类质量特性:因素和标准。
前者不能直接被测量而后者可以被主观的测量。
这启发了I SO 9126-1模型。
基于这个标准,ISO 9126-1更进一步的将McCall的模型化简为ISO 9126-1质量模型,现在它在广泛的艺术级的产品质量说明书中被接受。
它提议了一组六个相互独立的高阶的质量特性。
而这些质量特性被定义为其质量已被描述和评估的软件产品的质量特性。
在开发的各种阶段,质量特性被作为外部质量确认和内部质量审查的目标。
当获得特性和可测量的实体时,他们被描述成子特性。
在文中度量和测量标准被定义为一个测量方法或测量手段来获取一个值。
这种关系如图1所示:在开发过程中,为了监视和控制软件质量外部的质量需求会转变或转化成在开发活动中获得的中间产品的质量需求。
表1:ISO9126质量模型的特性。
子特性如图2所示:注意:符合性意味着与标准,协议或者规则的联系。
它被解释为所有特性的子特性之一[I SO/I E C1998]。
这里我们仅把它认为是功能性来精简它的描述。
注意:符合性子特性的出现意味着特性中其余的部分已经被偶些选定的标准完全测量了。
软件体系结构标准质量模型的制定:为了定制ISO质量模型,我们必须了解这些成分。
他们是体系结构或者软件系统所基于的一般框架所期盼的成分。
我们把它当作是软件开发过程的中间产品。
因此,一个特别的在深层次上被构建所解释的体系结构,必须满足ISO9126的全部或部分特性,而连接器连接着这些构件,结构和拓扑。
每个与属性相关联的特性都应被测量。
这些属性应当完全与体系结构或者构件和连接器有关。
质量特性的测量应被量化。
起先,它们被定义为特定符号的公式,接下来就使用标准的语言来定义[M a r c a n o e t a l.2000]。
在这个逐步的体系结构定义过程中,我们也许能够估计体系结构的精华是否提高了质量特性,但此问题在本文中不予讨论。
对于最终产品的每项属性来说,都有需要达到或是超越的质量目标值。
当这些质量目标值被达到或是超越后,我们便说这个体系结构符合质量特性的需求。
这些目标值是在质量需求中所确定的。
接下来我们通过对每个属性给与相应的标准来解释质量需求如何被精确到相应的子特性及属性上,以及它们如何与体系结构相适应。
注意,这里的特性及子特性被认为是相互独立的。
1、功能性特性:(1)、子特性——适应性:拥有符合特定任务需求的足够的功能。
它包括两个方面:存在:任务已被详细说明,比如以用例的方式。
每一个任务必须存在一个特定的功能去完成它。
正确:正确的解释任务的详细说明。
比如必须满足图3 的次序图。
从软件体系结构的层次上说明:a.系统的功能性必须被确定。
在此种情况下,子特性被解释成拥有是【1】或者否【0】这样值的属性。
注意,存在着值介于离散数字【n…m】之间的属性,比如【0….1】代表着不存在或存在。
这种标准是一种获取级别水平的度量。
b.由功能需求所获得的次序图必须被详细精化。
在拥有一个体系结构说明书的情况下,特定的功能被分解成与构件有关的子功能,并且这些子功能都应符合系统的功能性需求。
图3:系统需求向软件体系结构的转化(2)、子特性——正确性:以需要的精确程度来制定正确或一致的结果。