当前位置：首页 > news >正文

工厂网站建设公司有什么有用的网站

news 2025/11/5 15:05:58

工厂网站建设公司,有什么有用的网站,php网站开发工程师招聘会,企业年金个人查询系统质量属性根据GB/T 16260.1 定义#xff0c;从管理角度对软件系统质量进行度量#xff0c;可将影响软件质量的主要因素划分为6种维度特性包括#xff1a;功能性、可靠性、易用性、效率、维护性、可移植性功能性适合性、准确性、互操作性、依从性、安全性可靠性容错…系统质量属性根据GB/T 16260.1 定义从管理角度对软件系统质量进行度量可将影响软件质量的主要因素划分为6种维度特性包括功能性、可靠性、易用性、效率、维护性、可移植性功能性适合性、准确性、互操作性、依从性、安全性可靠性容错性、易恢复性、成熟性易用性易学性、易理解性、易操作性效率资源特性、时间特性维护性可测试性、可修改性、稳定性、易分析性可移植性适应性、易安装性、一致性和可替换性开发期质量属性开发期质量属性包括易理解性、可拓展性、可重用性、可测试性、可移植性运行期质量属性运行期质量属性包括性能、安全性、可伸缩性、互操作性、可靠性、鲁棒性质量属性场景描述质量属性场景是一种面向特定质量属性的需求由6部分组成刺激源、刺激、环境、制品、响应、响应度量刺激源这是某个个生成刺激的实体。刺激该刺激是当刺激到达系统时需要考虑的条件环境该刺激在某些条件内发生。当激励发生时系统可能处于过载、运行或者其他情况。制品某个制品被激励。这可能是整个系统也可能是系统的一部分。响应该响应是在激励到达后所采取的行动。响应度量当响应发生时应当能够以某种方式对其进行度量以对需求进行测试。面向架构评估的质量属性性能是指系统的响应能力及要经过多长时间才能对某个事件做出响应或者在某段事件内系统所能处理的事件的个数。经常用单位时间内处理事务的数量或系统完成某个事物处理所需的时间来对性能进行定量标识。性能测试经常要使用基准测试程序。性能质量属性场景刺激源用户请求、其他系统触发等刺激事件定期、随机、偶然事件制品系统环境正常模式、超载模式响应处理刺激、改变系统状态响应度量指标处理时间所花时间、单位时间内处理事件的数目、处理的错误率/丢失率提升性能的策略提升性能的策略包含以下方式资源需求、资源管理、资源仲裁资源的需求减少处理事件时对资源的占用、减少处理事件的数量、控制资源的使用减少处理事件时对资源的占用改进算法、减少计算开销减少处理事件的数量控制事件到来的速率、控制采样频率控制资源的使用限制执行时间、限制队列大小资源管理并发机制、增加资源并发机制多核、多线程增加资源计算资源、存储资源、带宽资源资源仲裁先来先服务、固定优先级、动态优先级、静态调度动态优先级时限时间最早优先、轮转调度可靠性可靠性是软件系统在应用或系统错误面前在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特征通常用来衡量在规定的条件和时间内软件完成规定功能的能力。通常用平均失效等待时间MTTF 和平均失效间隔时间 MTBF 来衡量。在失效率为常数和修复时间很短的情况下MTTF 和 MTBF 几乎相等。可靠性分为两个方面容错容错的目的是错误发生时确保系统正确的行为并进行内部“修复”。例如在一个分布式软件系统中失去了一个与远程构件的连接接下来恢复了连接。在修复这样的错误之后软件系统可以重新或重复执行进程间的操作直到错误再次发生。健壮性这里说的是保护应用程序不受错误使用和错误输入的影响在发生意外错误事件时确保应用系统处于预先定义好的状态。值得注意的是和容错相比健壮性并不是说在错误发生时软件可以继续运行它只能保证软件按照某种已经定义好的方式终止执行。软件架构对软件系统的可靠性有巨大的影响。例如软件架构设计上通过在应用程序内部采用冗余机制或集成监控构件和异常处理以提升系统可靠性。软件/硬件可靠性对比复杂性软件失效可能性大于硬件物理退化硬件有物理退化软件没有唯一性软件唯一,硬件不可能相同版本更新快软件更新比硬件快软件可靠性定量描述规定时间人们使用执行时间来度量软件的可靠性最为准确效果也最好失效概率可靠度软件规定的条件下、规定的时间内不发生失效的概率失效强度单位时间软件系统出现失效的概率使用失效强度来表示软件缺陷对软件运行的影响程度失效严重程度类就是对用户具有相同程度影响的失效集合平均失效前时间MTTFMean Time To Faliure从t0 时到故障发生时系统的持续运行时间的期望值不包括老化失效。平均恢复前时间 MTTRMean Time To Restoration从出现故障到修复成功的一段时间平均故障间隔时间MTBFMean Time Between Failures失效或维护中所需的平均时间包括故障时间以及检测和维护设备的时间MTBF MTTF MTTR 影响软件可靠性的因素运行环境软件规模软件的内部结构软件的开发方法和开发环境软件的可靠性投入软件可靠性建模可靠性建模的步骤包括模型假设、性能度量、参数估计方法、数据要求模型假设。模型是实际情况的简化或规范化总要包含若干假设例如测试的选取代表实际运行剖面不同软件失效独立发生等。性能度量。软件可靠性模型的输出量就是性能度量如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。参数估计方法。某些可靠性度量的实际值无法直接获得例如残留缺陷数这时需要通过一定的方法估计参数的值从而间接确定可靠性度量的值。估计是通过收集到的失效数据进行统计分析利用一定的推导过程归纳出模型的参数预测则是使用软件产品自身的属性和开发过程来确定模型的参数这种方法可以在开始执行程序前完成。数据要求一个软件可靠性模型要求一定的输入数据即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。模型的3个共同假设包括代表性假设、独立性假设、相同性假设代表性假设。此假设认为软件测试用例的选取代表软件实际的运行剖面甚至认为测试用例是独立随机地选取。此假设实际上是指可以用测试产生的软件可靠性数据预测运行阶段的软件可靠性行为。独立性假设。此假设认为软件失效是独立发生于不同时刻一个软件失效的发生不影响另一个软件失效的发生。相同性假设。此假设认为所有软件失效的后果相同即建模过程只考虑软件失效的具体发生时刻不区分软件的失效严重等级好的可靠性建模满足基于可靠的假设简单计算一些有用的量给出未来失效行为的好的映射可广泛应用软件的可靠性模型分类类型描述种子法模型预先在程序中播种错误“种子”根据测试找出错误以及估计残留错误数量。失效率类模型用来研究程序的失效率曲线拟合类模型用回归分析的方法研究软件复杂性、程序中的缺陷数、失效率、失效间隔时间包括参数方法和非参数方法两种。可靠性增长模型预测软件在检测过程中的可靠性改进用增长函数来描述软件的改进过程程序结构分析模型根据程序、子程序及其相互间的调用关系形成一个可靠性分析网络输入域分类模型选取软件输入域中的某些样本“点”运行程序根据这些样本点在“实际”使用环境的使用概率的测试运行时的成功/失效率推断软件的使用可靠性。执行路径分析方法模型先计算程序各逻辑路径的执行概率和程序中错误路径的执行概率再综合出该软件的使用可靠性非齐次泊松过程模型以软件测试过程中单位时间的失效次数为独立泊松随机变量来预测在今后软件的某使用时间点的累计失效数马尔可夫过程模型用于预测未来的数学模型贝叶斯模型利用失效率的试验前分布和当前的测试失效信息来评估软件的可靠性软件可靠性管理软件可靠性管理分为六个阶段需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、实施阶段需求分析阶段确定软件的可靠性目标分析可能影响可靠性的因素确定可靠性的验收标准制订可靠性管理框架制定可靠性文档编写规范制订可靠性活动初步计划确定可靠性数据收集规范概要设计阶段确定可靠性度量制定详细的可靠性验收方案可靠性设计收集可靠性数据调整可靠性活动计划明确后续阶段的可靠性活动的详细计划。编制可靠性文档详细设计阶段可靠性设计可靠性预测调整可靠性活动计划收集可靠性数据明确后续阶段的可靠性活动的详细计划编写可靠性文档编码阶段可靠性测试排错调整可靠性活动计划收集可靠性数据明确后续阶段的可靠性活动的详细计划编制可靠性文档测试阶段可靠性测试排错可靠性建模可靠性评价调整可靠性活动计划收集可靠性数据明确后续阶段的可靠性活动的详细计划编制可靠性文档实施阶段可靠性测试排错收集可靠性数据调整可靠性模型可靠性评价编制可靠性文档软件可靠性设计容错设计恢复快设计恢复快方法是一种动态的故障屏蔽技术采用向后恢复策略。N版本程序设计:N版本程序设计是一种静态的故障屏蔽技术采用向前恢复的策略。订单、对账、清算工作防卫式程序设计通过在程序中包含错误检查代码和错误恢复代码使得一旦发生错误程序就能撤销错误状态恢复到一个已知的正确状态中去冗余设计改善软件可靠性的一个重要技术是冗余设计。在硬件系统中在主程序运行的系统之外备用额外的元件或系统如果出现一个元件故障或系统故障则立即更换冗余的元件或切换到冗余的系统则该硬件仍可以继续维持运行。在软件系统中冗余技术的运用有所区别。如果采用相同两套软件系统互为备份其意义不大因为在相同的环境中一套软件出现故障的地方另外一套也一定会出现故障。软件冗余设计技术实现的原理是在一套完整的软件系统之外设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份在出现故障时可以使用冗余的部分进行替换从而维持软件系统的正常运行。检错技术采用检错技术要着重考虑几个要素检测对象、检测延迟、实现方式和处理方式检测对象包含两个层次的含义即检测点和检测内容。在设计时应考虑把检测点放在容易出错的地方和出错对软件系统影响较大的地方检测内容选取那些有代表性的、易于判断的指标。检测延时从软件发生故障到被自检出来是有一定延时的这段延时的长短对故障的处理是非常重要的。因此在软件检错设计时要充分考虑到检测延时。如果延时长到影响故障的及时报警则需要更换检测对象或检测方式实现方式最直接的一种实现方式是判断返回结果如果返回结果超出正常范围则进行异常处理。计算运行时间也是一种常用的技术如果某个模块或函数运行超过预期的时间可以判断出现故障。另外还有置状态标志位等多种方法自检的实现方式要根据实际情况来选用。处理方式大多数检错采用查出故障-停止软件系统运行-报警的处理方式但也有采用不停止或部分停止软件系统运行的情况这一般由故障是否需要实时处理来决定。降低复杂度设计软件复杂性常分为模块复杂性和结构复杂性模块复杂性主要包含模块内部数据流向和程序长度两个方面结构复杂性用不同模块之间的关联程度来表示降低复杂度的思想就是在保证实现软件功能的基础上简化软件结构、缩短程序代码长度优化软件数据流向降低软件复杂度从而提高软件可靠性。系统配置技术系统配置技术主要包括双机热备、双机互备、双机双工、服务集群技术双机热备双机热备即是目前通常所说的active/standby方式服务器数据包括数据库数据同时往两台或多台服务器写或者使用一个共享的存储设备。当 active服务器出现故障的时候通过软件诊测(一般是通过心跳诊断)将standby机器激活保证应用在短时间内完全恢复正常使用。双机互备在双机热备的基础上两个相对独立的应用在两台机器同时运行但彼此均设为备机当某一台服务器出现故障时另一台服务器可以在短时间内将故障服务器的应用接管过来从而保证了应用的持续性。这种方式实际上是双机热备的一种应用。它避免了两个应用使用四台服务器分别实现双机热备。双机双工两台或多台服务器均为活动同时运行相同的应用保证整体的性能也实现了负载均衡和互为备份。需要利用磁盘柜存储技术(最好采用san)。对于数据库服务而言它同时需要数据库软件的支持是比较复杂的。而WEB服务器或应用服务器就比较简单了。服务器集群技术集群技术是指一组相互独立的服务器在网络中组合成为单一的系统工作并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。大多数情况下集群中所有的计算机拥有一个共同的名称集群内任一系统上运行的服务可被所有的网络客户所使用。可靠性测试分为广义的可靠性测试与狭义的可靠性测试广义的软件可靠性测试是指为了最终评价软件系统的可靠性而运用建模、统计、试验、分析和评价等一系列手段对软件系统实施的一种测试。狭义的软件可靠性测试是指为了获取可靠性数据按预先确定的测试用例在软件的预期使用环境中对软件实施的一种测试目的发现软件系统在需求、设计、编码、测试和实施等方面的各种缺陷为软件的使用和维护提供可靠性数据确认软件是否达到可靠性的定量要求步骤可靠性目标的确定定义软件运行剖面测试用例的设计测试实施测试结果分析内容软件产品标识测试环境配置软件和硬件测试依据测试结果测试问题测试时间可靠性评价过程可靠性的评价过程包括选择可靠性模型、收集可靠性数据、可靠性评估和预测选择可靠性模型模型假设的适用性预测的能力与质量模型输出值是否满足可靠性评价需求模型使用的简便性收集可靠性数据尽早确定可靠性模型并确定需要收集的可靠性数据制定数据收集计划重视测试产生的数据利用数据库分析可靠性评估和预测评估和预测依赖于可靠性模型使用支持软件可靠性估计的软件工具失效数据的图形分析法、试探性数据分析技术可用性可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。可用性质量属性刺激源故障来自系统内部或外部刺激系统出错系统崩溃反复出错给出结果不及时给出错误结果制品计算或存储或网络环境正常状态降级模式响应错误报告回传厂家通知管理员或其它系统关闭系统系统在维修期间不可用响应度量指标故障时间百分比平均故障修复时间平均无故障时间提升可用性的策略提升可用性的策略包括错误检测、错误恢复、错误避免错误检测心跳ping/Echo异常心跳被监控组件定期向监控的组件发出心跳消息。若连续未收到的心跳信号到了一定的数目则认为相应的系统已经出现故障。ping/Echo: 监控组件不定期向被监控的组件发出ping 消息并根据收到的echo 消息做出响应异常需要编程语言的支持。如抛出捕获处理错误恢复表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚表决多个冗余的组件用同一或不同的算法来完成一个任务如果计算结果不同则由表决器按照算法少数服从多数的原则确定主动冗余服务器A 和B并行完成同样的运算它们的状态时刻保持一致平时只取A算出的结果。当A 出现故障时系统可以迅速切换到B被动冗余服务器A完成运算后在一定时间内通知服务器B 进行更新重新同步主动冗余和被动冗余都需要在重新上线前做状态的重新同步检查点/回滚定期保存便于恢复错误避免服务下线、事务、进程监控器安全性是指系统在合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可分为机密性、完整性、不可否认性及可控性等特性。其中机密性保证信息不泄露给未授权的用户、实体或过程。完整性保证信息的完整和准确防止信息被非法修改不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为可控性保证对信息的传播及内容具有控制的能力防止为非法者所用。安全性质量属性场景刺激源正确识别、非正确识别授权、未授权刺激试图显示数据改变/删除数据访问系统服务环境在线或离线、联网或断网制品系统服务、系统中的数据响应对用户身份进行认证隐藏用户的身份阻止或允许访问数据或服务响应度量用成功的概率表示检测到攻击的可能性确定攻击或访问、修改数据或服务的个人的可能性提升安全性的策略提升安全性的策略包括抵抗攻击、检测攻击、从攻击中恢复抵抗攻击用户身份验证动态密码、一次性密码、生物识别用户授权对用户访问进行控制管理维护数据机密性与完整性给数据和传输过程加密维护数据完整性、MD5码校验限制暴露关闭无用端口、自启动的服务、无线路由SSID 等限制访问设置黑名单、白名单检测攻击入侵检测系统从攻击中恢复恢复状态恢复检查点识别攻击者用于预防或惩罚性目的可修改性可修改性是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准通过考察这些变更的代价来衡量可修改性。可修改性分为4个方面可维护性这主要体现在问题的修复上在错误发生后“修复”软件系统。可维护性好的软件架构往往能做局部性的修改并能使对其他构件的负面影响最小化。可拓展性这一点关注的是使用新特性来拓展软件系统以及使用改进版本方式替换构件并删除不需要或不必要的特性和构件。为了实现可拓展性软件系统需要松散耦合的构件。其目标是实现一种架构能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的架构中也是必要的。结构重组这一点处理的是重新组织软件系统的构件及构件间的关系例如通过将构建移动到一个不同的子系统而改变它的位置。为了支持结构重组软件系统需要精心设计构件间的关系。理想情况下它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。可移植性可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植性需要按照硬件、软件无关的方式组织软件系统。可移植性是系统能够在不同计算环境下运行的能力这些环境可能是硬件、软件也可能是两者的结合。如果移植到新的系统需要做适当更改则该可移植性就是一种特殊的可修改性。可修改性质量属性场景刺激源最终用户、开发人员、系统管理员刺激希望增加、删除、修改、改变功能、质量属性、容量等环境系统设计时、编译时、构建时、运行时制品系统用户界面、平台、环境或与目标系统交互的系统响应查找架构中需要修改的位置进行修改且不会影响其他功能对所做的修改进行测试部署所做的修改响应度量根据所影响元素的数量度量的成本、努力、资金该修改对其他功能或质量属性所造成影响的程度提升可修改性的策略提升可修改性的策略有局部化修改、防止连锁反应、延迟绑定时间局部化修改高内聚、低耦合对程序的修改控制在一个模块内预测变更使模块通用防止连锁反应信息隐藏利用面向对象中的可访问性Public、Protected、Private维持现有接口接口不变的情况下双方都能独立地变化定义一个稳定的接口使得接口的实现方和依赖方能够解耦双方能够独立变化的分别适应各自的需求变化不会在一方维护时牵连另一方的情况限制通信路径使用中介数据中介仓库数据共享风格服务中介桥接模式、工厂方法模式、代理模式延迟绑定时间运行时注册即插即用多态动态绑定配置文件配置文件来避免修改代码功能性是系统完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。可变性是指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则在某些方面不同于原有的架构。当要将某个架构作为一系列相关产品的基础时可变性是很重要的。互操作性作为系统组成部分的软件不是独立存在的通常与其他系统或自身环境相互作用。为了支持互操作性软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和其他编程语言编写的软件系统的交互作用就是互操作性的问题这种互操作性也影响应用的软件架构。

查看全文

http://www.ho-use.cn/article/10817319.html