精华内容
下载资源
问答
  • 软件系统的可维护性评价指标不包括
    2021-07-07 21:13:37

    5.1 Metrics and Construction Principles for Maintainability

        可维护性的度量与构造原则

    1. 可维护性的指标

    软件维护的类型:纠错性维护(25%)、适应性维护(21%)、完善性维护(50%)、预防性维护(4%)

    可维护性(Maintainability)、可扩展性(Extensibility)、灵活性(Flexibility)、可适应性(Adaptability)、可管理性(Manageability)、支持性(Supportability)这些指的都是可维护性。

    评判可维护性的一些方面:

        设计结构足够简单;
        模块之间松散耦合;
        模块内部高度聚合;
        不要使用了非常深的继承树,尽量使用delegation替代继承;
        代码的圈复杂度不能太高;
        不存在重复代码

    2. 模块化设计原则

    目的:高内聚低耦合;分离关注点 (通过delegation等机制分离功能);信息隐藏 (避免表示泄露、静态工厂方法等等)

    评估模块化的五个标准:

        可分解性 (Decomposability):让复杂的功能分解成一个个ADT完成
        可组合性 (Composability):让一个个ADT组合完成复杂的功能
        可理解性 (Understandability):OOP是面向世界上存在的事物编程,所以容易被理解
        可持续性 (Continuity):发生变化时使得受影响范围最小
        出现异常之后的保护 (Protection):出现异常后使得受影响范围最小

    模块化设计的五个原则:

        Direct Mapping (直接映射)
        Few Interfaces (尽可能少的接口)
        Small Interfaces (尽可能小的接口)
        Explicit Interfaces (显式接口)
        Information Hiding (信息隐藏)

    高内聚低耦合

        高内聚:模块内部的功能之间的联系要紧密,无关的功能之间要分离成不同的模块

        低耦合:模块之间的关系要越松散越好

    3. SOLID设计原则

    SOLID原则:

        (SRP) The Single Responsibility Principle --------- 单一责任原则
        (OCP) The Open-Closed Principle ------------------- 开放-封闭原则
        (LSP) The Liskov Substitution PrincipleLiskov ---- 替换原则
        (DIP) The Dependency Inversion Principle -------- 依赖转置原则
        (ISP) The Interface Segregation Principle ---------- 接口隔离原则

    更多相关内容
  • 可能是产生了巨大的商业价值,也可能是解决了某个领域的难题,就我个人而言,如果这个项目可维护、可运营,就可以称之为健康的项目。那么关于可维护、可运营的项目有什么特点呢?下面我列举一些更具体的方面。可估量...

    每个软件开发人员可能对什么是健康的软件项目都有自己的想法。可能是产生了巨大的商业价值,也可能是解决了某个领域的难题,就我个人而言,如果这个项目可维护、可运营,就可以称之为健康的项目。那么关于可维护、可运营的项目有什么特点呢?下面我列举一些更具体的方面。

    可估量

    估量主要指两个方面,一是开发工作量,二是容量明确。

    开发工作量

    软件项目不同于硬件,唯一不变的就是变化。只要持续运行就会持续变化。变化需要对功能进行扩展,扩展就要开发,开发就有工作量。有工作量就需要预估工作量,软件开发中的工作量很难估算准确(棋牌法、多人估算)。如果实际工作量与估计工作量相比的差异小于 15%,则您的估计值非常好。然而,一些软件项目允许令人惊讶的准确估计,而其他软件项目往往会产生令人难以置信的异常值。我不止一次遇到过这样的异常值,偏差高达 700%,就好比一个功能看似一天完成,结果做了七天。5063f41401225164036baf1f613ec802.png出现预估不准确基本都是架构设计存在扩展性问题,当然也不排除不了解项目内部运行机制而导致的盲目评估。

    容量明确

    日常生活中的各种工业化产品都会有一个说明书或者仪表盘,明确告诉你该产品的能力。比如汽车,承载量2t,时速 140km/h。软件项目也一样,应该明确说明该项目 core 数 对应的 qps,当出现性能问题可以进行准确的容量和资源评估。

    可观测

    监控其本质就是软件系统运行情况的可视化,具体参考:Prometheus+Grafana的思考和实践,打个形象的比方,你在开车的时候,你不知道你的时速是多少?那么如何决定什么时候加速?什么时候刹车?什么时候加油?即便如此重要,很多公司,特别是中小企业基本不会重视监控指标的建设,究其原因成本高,短期收益相对较低,所以只能头疼医头脚痛医脚。

    在缺少告警机制的情况下,无法第一时间洞悉到系统发生故障,只能通过用户的反馈来获取,系统运维人员往往也只是充当了一个“救火” 队员,大面积的系统瘫痪往往也会给企业和用户带来极大的损失。通过监控,服务可以在系统受损的第一时间得到反馈,并通过电话/短信进行告警,oncall 人员及时处理问题,大大减小了系统故障对企业和用户造成的影响,更有可以做到无感知的修复。

    可部署

    软件部署及其自动化程度是另一个关键方面。这与可重复性密切相关,但自信的布署也是一个文化问题。如果部署仍然是一件特殊且危险的事情,没有人愿意负责,那么部署问题会成为一个复杂问题。我了解到很多公司和团队也很重视 CI/CD、DevOps 等文化,但是多数停留于概念表面,比如通过文档驱动部署、千遍一律的人工配置发布,这种方式看似稳妥,其实一种偷懒的表现。因为文档和人都会犯错,它不能帮助我们解决软件部署的根本问题。当然持续部署模型并不适合每个团队或产品,但部署至少必须尽可能自动化、尽可能可重复且尽可能简化。

    总结

    业界的发展历程来看,技术的代码化、标准化、自动化是一个必然的演进过程。对于有能力和前景的企业,在发展过程中会把技术栈统一、资源接口统一、底层基础设施统一,这个历程会非常长,从笔者的经验来看,应该小步迭代,按照实际效果谨慎执行。软件项目虽然说技术很重要,但是人、成本、落地场景同样重要。所以不能只是考虑光鲜的政绩,并没有有效地解决实际问题。就像最近一段时间提出的 AIOps,这种高度自愈的系统一定是软件运行的终极目标。但这跟软件工程并不冲突,学会用科学的方法实现最大化软件收益仍然是最重要的。

    ab408707083d9456bfcd68cb08e10ba7.png

    推荐

    为什么HTTP REST比RPC更受欢迎|微服务

    如何检测分布式系统中的故障节点


    原创不易,随手关注或者”在看“,诚挚感谢!

    展开全文
  • 系统运行与维护

    2022-04-28 21:24:36
    信息系统交付用户,运行过程中,仍会出现在系统调试与测试阶段没有发现的隐藏错误,还可能为系统功能的扩展与集成进行系统的改动,为此要对系统进行科学的维护与管理,记录系统运行的情况,评价系统的工作质量与经济...

    系统运行与维护阶段在整个系统生命周期所占比重在60%~80%之间。

    信息系统交付用户,运行过程中,仍会出现在系统调试与测试阶段没有发现的隐藏错误,还可能为系统功能的扩展与集成进行系统的改动,为此要对系统进行科学的维护与管理,记录系统运行的情况,评价系统的工作质量与经济效益。这是一项长期的工作。

    一、遗留系统的处理策略

    遗留系统(Legacy System)是指任何基本上不能进行修改和演化,以满足新的或变化的业务需求的信息系统。

    在信息系统升级改造过程中,如何处理和利用遗留系统,称为新系统建设的重要组成部分。处理是否恰当,直接关系到新系统的成败和开发效率。

    1、评价方法
    对遗留系统评价的目的是为了获得对遗留系统的更好理解,这是遗留系统演化的基础,是所有遗留系统演化项目的起点。主要评价方法包括度量系统技术水准、商业价值和与之关联的企业特征,评价结果作为选择对遗留系统的处理策略的基础。

    评价方法由一系列活动组成
    在这里插入图片描述
    在这里插入图片描述
    2、演化策略
    1)淘汰策略
    低水平、低价值。直接转换。

    2)集成策略
    高水平,低价值。信息孤岛。

    3)继承策略
    低水平,高价值。并行更新。

    4)改造策略
    高水平,高价值。增强功能,改造数据模型。

    二、系统转换与交接

    系统转换,新系统取代旧系统。系统转换与交接之前,需要做一些准备工作,包括:

    数据准备
    系统文档准备
    人员培训
    设备安装
    系统试运行

    1、新旧系统的转换策略
    在这里插入图片描述
    1)直接转换
    原系统停止运行的某一时刻,新系统立即投入运行,中间没有过渡阶段。这种方式,最节省资源,但在转换之前必须经过详细而严格的测试,且转换时做好准备,万一新系统不达预期,必须有相应预案。适合于新系统不太复杂,或现有系统已经完全不能使用的情况。

    2)并行转换
    并行转换就是新系统和现有系统并行工作一段时间,经过这段时间的试运行后,再用新系统正式替换现有系统。并行工作期间,现有系统的作业为正式,新系统的处理结果作为校核。并行运行时间一般可在2、3个月到1年不等。

    并行转换风险小,还可以同时比较2个系统,并让系统操作员和其他有关人员得到培训。因此,对于一些较大的信息系统,或处理过程复杂、数据重要的系统,并行转换是一种最常用的转换方式。但是,需要两套系统并存,资源消耗较大,转换周期长,难以控制新旧系统中的数据变化,需要做好转换计划并加强管理,验证后及时停止旧系统。

    3)分段转换
    分段转换也称为逐步转换,是直接转换和并行转换的结合,采取分期分批方式逐步转换。

    一般比较大的系统适宜采用分段转换方式。能保证平稳运行,费用也不太高。也适合这样的情况:现有系统比较稳定,能够适应自身业务发展需要,或新旧系统转换风险很大(如在线订票系统、银行的中间业务系统等)。

    优点是新旧系统的转换震动比较小,用户容易接受。但转换周期长,同时可能需求出现变化,给新系统的稳定造成比较大的影响。另外对设计和实现有一定的要求,需要开发新旧系统之间的接口,还需要制订阶段性的转换目标和计划。一句话,比较复杂。

    分段策略可以
    (1)按功能分阶段逐步转换
    (2)按部门分阶段
    (3)按机器设备分阶段

    2、数据转换和迁移
    数据转换和迁移是新旧系统转换交接的主要工作之一。原则是数据不丢失。

    1)数据迁移的方法
    系统切换前通过工具迁移、手工录入和系统切换后新系统生成。

    2)数据迁移前的准备工作
    数据迁移的实施可以分为三个阶段:数据迁移前的准备、数据转换与迁移和数据迁移后的校验。充分周到的准备工作室数据迁移的主要基础,包括:

    (1)待迁移数据源的详细说明,包括数据的存放方式、数据量和数据的时间跨度。
    (2)建立新旧系统数据库的数据字典,对现有系统的历史数据进行质量分析,以及新旧系统数据结构的差异分析。
    (3)新旧系统代码数据的差异分析。
    (4)建立新旧系统数据库表的映射关系,对无法映射字段的处理方法。
    (5)开发或购买、部署ETL工具
    (6)编写数据转换的测试计划和校验程序。
    (7)制定数据转换的应急措施。

    3)数据转换与迁移
    首先制定详细实施步骤和流程,准备数据迁移环境,做好业务上的准备,充分测试数据迁移技术,然后再实施。

    实施过程有抽取、转换、装载。

    4)数据迁移后的校验
    质量分析、数据对比检查。

    三、系统的扩展与集成

    随着信息系统的运行和业务的发展,对现有系统进行有效的扩展升级,适应当前的应用,是很自然的事情;而如果企业有多个应用系统,就需要对这些系统进行集成,是数据能在多个系统中共享。

    1、系统扩展
    系统的可扩展性是指将新的功能添加到系统中的能力。可扩展性分为动态可扩展性和静态可扩展性。

    【动态可扩展性】
    在系统运行的过程中能够添加新的功能,而不会影响系统的其他部分。

    【静态可扩展性】
    在添加新的功能时,系统必须停止运行,添加完成后重启系统。

    提高系统可扩展性的方法是在系统架构中减少构件之间的耦合。

    扩展一般包括延伸型扩展和新建型扩展。前者在原有基础上扩充,后者可能需要另起炉灶。引入第三方软件包并进行二次开发可以迅速对现有系统进行功能扩充。不过引入前需要充分研究和分析,确保能满足扩展需求,最好还要有适度的前瞻性。同时要求包含详细的设计文档甚至是源码,以保证可控性。

    2、扩展与集成的比较
    系统扩展和集成分别属于深度维护和广度维护活动,和开发类似,需要分析、设计、编码、测试等多角色、多工种参与,系统集成还特别需要高层人员协调和沟通。系统扩展的重点在设计,力求平滑扩展;系统集成重点在分析,争取无缝集成。系统扩展和系统集成都需要进行全面的回归测试,系统集成尤其要重视接口的测试和流程流畅性的测试。

    四、系统运行管理

    系统运行管理的目的是对信息系统的运行进行控制,记录其运行状态,进行必要的修改与扩充,以便使信息系统真正符合管理和决策的需要。系统运行管理的主要内容包括日常运行管理、系统运行情况的记录、对系统运行情况的检查与评价等,这些工作室原始资料的积累过程,不能忽视。

    1、系统成本管理
    系统运行与管理需要硬件、网络、场地、人员等资源支撑,都是成本。需要做预算、分析等各种功课。

    2、系统用户管理
    管理系统用户的身份和权限。

    3、网络资源管理

    4、软件资源管理
    软件资源指软件和文档。
    1)软件构件管理
    2)软件分发管理
    软件部署、安全补丁分布、远程管理和控制
    3)文档管理

    五、系统故障管理

    故障无可避免,如何进行有效的故障管理好似系统运行与维护过程中一项非常重要的工作。故障管理主要目标是尽快恢复系统运行。影响度、紧迫性和优先级是描述故障的3个特征。

    故障管理包括故障监视、故障调查、故障支持、恢复处理和故障终止5项基本活动。

    【故障监视】
    人员、规范操作的执行、系统硬件和软件是监视重点内容。

    六、软件维护

    系统维护包括软件维护(程序维护)、数据维护、代码维护(这里说的代码是指编号之类)、设备维护,以及机构和人员的变动等。其中软件维护最重要,也最难。

    1、软件维护概述
    软件维护是指在软件交付使用之后,直至软件被淘汰的整个时期内,为了改正错误或满足新的需求而修改软件的活动。软件的维护活动基于“软件是可维护的”这一基本前提。

    1)软件可维护性
    【易分析性】
    【易改变性】
    【稳定性】
    【易测试性】
    【维护性的依从性】
    软件产品遵循与维护性相关的标准或约定的能力。

    2)可维护性度量
    在软件外部,用MTTR(平均故障修复时间)来度量软件的可维护性,

    M = 1 / (1 + MTTR)
    

    M为可维护性指标。

    在软件内部,可以通过度量软件的复杂性来间接度量可维护性。

    3)软件维护的分类
    【改正性维护】
    改正错误和缺陷

    【完善性维护】
    用户提出新要求,为了满足这些要求,需要修改或再开发软件,改善和增强软件。

    【适应性维护】
    软件使用过程中,外部环境、数据环境可能发生变化,为使软件适应这种变化,而去修改软件的过程称为适应性维护。

    【预防性维护】
    预先提高软件的可维护性、可靠性等,为以后进一步改进软件打下良好的基础。
    在这里插入图片描述

    2、软件维护的影响因素

    软件维护的影响因素很多,业务因素,理解局限性,维护优先级,维护人员积极性,测试困难等。为尽可能减弱这些因素的影响,需要在长期与短期目标、质量与速度之间做出权衡,除此之外,还可以从以下方面提高软件的可维护性:

    1)采用软件工程方法

    2)注重可维护性的开发过程,
    开发阶段,就要重视如何使软件易于分析、易于测试、易于修改:

    需求分析阶段,对讲来要改进的和可能会修改的部分加以明确,对软件的跨平台可移植性进行讨论,形成解决方案;

    设计阶段,尽量遵循高内聚、低耦合的设计原则,对将来可能要修改的地方,采用灵活的、易于扩充的设计方案;考虑跨平台的可移植性设计,加大可复用构件的设计力度。

    编码阶段,规范代码,强化注释,保证注释质量,加大可复用构件的使用力度

    测试阶段,扎实做好测试工作,编写好相关测试文档

    维护阶段,要有严格的配置管理,同步更新文档,保证系统与文档的一致性

    3、软件维护成本
    软件维护成本与软件本身质量有关,质量高,编码规范,注释清晰,文档完备,维护工作就相对轻松。同时也跟系统类型、架构,硬件因素有关。也受到维护工作本身是否规范,维护人员素质的影响。

    4、软件维护管理
    维护过程是修改和压缩了的开发过程,而且维护的范围更广,需要控制和跟踪的东西更多。维护的重点是控制系统更改,完善系统功能,防止系统掉链子。
    在这里插入图片描述
    在这里插入图片描述

    七、系统监理与评价

    企业信息化有风险,而信息系统项目建设过程中,绝大多数信息系统业主无法进行缺乏专业管理,建设方与承建方存在严重的信息不对称问题,所以需要借助第三方力量对信息系统工程项目进行监控和管理,并对信息系统进行审计和评价。

    1、工程监理
    1)监理内容
    四控三管一协调:
    投资控制、进度控制、质量控制、变更控制
    安全管理、信息管理、合同管理
    沟通协调

    2)监理分类
    【咨询式监理】
    最简单,费用最少,监理方责任最轻,适合于对信息化把握比较好,技术力量比较强的用户。

    【里程碑式监理】
    把信息系统的建设分为若干个阶段,每个阶段结束都设置一个里程碑,在里程碑到来时通知监理方进行审查或测试。监理方需要承担一定的责任,并且里程碑的确定或监理合同需要承建方参与。

    【全程式监理】
    费用最高,监理方的责任也最大。适合对信息系统不太了解,技术力量弱的用户方。

    2、系统评价
    系统评价是对系统运行一段时间护的技术性能和经济效益等方面的评价,是对信息系统审计工作的延伸。评价的目的是检查系统是否达到了预期的目标,技术性能是否达到了设计的要求,系统的各种资源是否得到充分利用,经济效益是否理想,并指出系统的长处与不足,为以后系统的改进和扩展提出依据。

    1)评价的步骤
    确定评价对象,拟订评价工作方案,实施评价,专家咨询组审核。

    2)评价指标

    (1)系统性能评价
    可靠性,系统效率,可维护性,可扩充性,可移植性,实用性,适应性,安全保密性

    (2)系统效益评价
    经济效益和社会效益

    (3)系统建设评价

    3)系统改进建议
    系统改进建议是系统评价的最后一个环节。

    4)评价报告
    由正文和附录两部分组成。

    【正文】
    基本情况描述,主要各项指标对比分析,评价结论,评价依据,评价方法等。

    【附录】
    评价工作的基础文件和数据资料。

    评价报告要维护被评价企业的正当商业秘密,必须客观、公正、准确地描述信息系统的实际状况和后续发展能力,并提出改进建议。

    展开全文
  • 文章目录1.软件质量属性1.1运行期质量属性1.2开发期质量属性1.3提高质量属性架构策略2.架构权衡分析方法3.质量属性效用树4....  《GB/T16260-1996(idt ISO/IEC9126:1991)信息技术软件产品评价质量


      在软件考试中,可用性,稳定性,可靠性和连续性的概念难以分清,本概念来自互联网,供读者参考:

    • 可用性:保持稳定态的时长。
    • 稳定性:抵御故障的能力。
    • 可靠性:故障的频率。
    • 连续性:恢复能力。

    质量属性效用树主要关注性能、可用性、安全性和可修改性。

    1.软件质量属性

      《GB/T16260-1996(idt ISO/IEC9126:1991)信息技术软件产品评价质量特性及其使用指南》中描述的软件质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等 6 个方面,每个方面都包含若干个子特性。

    功能性:适合性、准确性、互操作性、安全性;
    可靠性:成熟性、容错性、依从性、易恢复性;
    易用性:易理解性、易学性、易操作性;
    效率:时间特性、资源特性;
    可维护性:易分析性、易改变性、稳定性、易测试性;
    可移植性:适应性、易安装性、遵循性、易替换性;

    1.1运行期质量属性

    性能:性能是指软件系统及时提供相应服务的能力。包括速度、吞吐量和持续高速性三方面的要求。
    安全性:指软件系统同时兼顾向合法用户提供服务,以及阻止非授权使用的能力。
    易用性:指软件系统易于被使用的程度。
    可伸缩性:指当用户数和数据量增加时,软件系统维持高服务质量的能力。例如,通过增加服务器来提高能力。
    互操作性:指本软件系统与其他系统交换数据和相互调用服务的难易程度。
    可靠性:软件系统在一定的时间内无故障运行的能力。
    持续可用性:指系统长时间无故障运行的能力。与可靠性相关联,常将其纳入可靠性中。
    鲁棒性:是指软件系统在一些非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力。也称健壮性或容错性。

    1.2开发期质量属性

    易理解性:指设计被开发人员理解的难易程度。
    可扩展性:软件因适应新需求或需求变化而增加新功能的能力。也称为灵活性。
    可重用性:指重用软件系统或某一部分的难易程度。
    可测试性:对软件测试以证明其满足需求规范的难易程度。
    可维护性:当需要修改缺陷、增加功能、提高质量属性时,定位修改点并实施修改的难易程度;
    可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

    1.3提高质量属性架构策略

    • 可用性:心跳,Ping/Echo,主动冗余、被动冗余、选举等架构策略。
    • 性能:增加计算资源、减少计算开销、引入并发机制、采用资源调度等架构策略。
    • 安全性:入侵检测、用户认证、用户授权、追踪审计等架构策略

    2.架构权衡分析方法

       ATAM(Architecture Tradeoff Analysis Method),主要包括场景和需求收集、架构视图和场景实现、属性模型构造和分析和属性模型折中四个阶段。

    3.质量属性效用树

      它是对质量属性进行分类、权衡、分析的架构分析工具,主要关注系统的性能、可用性、可修改性和安全性四个方面。

    4.可靠性

      系统可靠性是指系统在规定的时间内及规定的环境条件下,完成规定功能的能力,就是系统无故障运行的概率。4个主要子特性。

    • 成熟性:成熟性是指系统避免因错误的发生而导致失效的能力。
    • 容错性:容错性是指在系统发生故障或者违反指定接口的情况下,系统维持规定的性能级别的能力。
    • 易恢复性:易恢复性是指系统发生失效的情况下,重建规定的性能级别并恢复受直接影响的数据的能力。
    • 依从性:可靠性的依从性是指系统依附于与可靠性相关的标准、约定或规定的能力。

       提高可靠性的技术方法:冗余技术、软件容错技术、双机容错技术和集群技术。

      软件的可靠性设计主要包括恢复快和N版程序设计两种方法。
      主块–>验证测试–>正确结果–>异常处理

    展开全文
  • 为了维护大辽河口水生态系统的生态功能,实现区域的持续发展,建立了大辽河口水生态系统功能重要性评价指标体系。运用指标体系评价和专家打分的方法,将研究区划分为低、较低、一般、较高、高5个功能等级.首先对大...
  • 软件可维护性问题知识与分析

    万次阅读 2014-08-22 16:28:48
     很多包括自己在内的开发人员都会经常去借用(我们不用剽窃这个词了!呵呵)开源代码进行二次开发;或者在前辈的遗留代码下,继续修修补补。这种经历往往并像看起来那么简单——有时看懂,进而修改别人的少许代码...
  • 软件工程-软件维护/系统维护

    千次阅读 2019-11-06 20:49:51
    系统可维护性 评价指标 可理解性 可测试性 可修改性 系统维护类型 改正性维护 适应性维护 预防性维护 完善性维护 tip:完善性维护占半壁江山 系统文档 开发文档:技术员编写,与开发相关 产品文档:与用户有关...
  • 5、系统评价的灵活功能,根据不同的学校用户,系统可以预置不同的(学生,教师)评价指标体系和评价的权重分配,可以让学生, 教师进行多方面的客观的,真实的评价,提高教学质量。 6、评价系统的保密,为了提高...
  • 系统性能评价---性能指标

    万次阅读 2018-08-27 21:28:27
    它既包括硬件性能,也包括软件性能。随着计算机技术的不断发展,有关 能的描述也越来越细化,根据不同的应用需要产生了各种各样的性能指标,如整数运算性能、浮点运算性能、响应时间、网络带宽、稳定、I/O 吞吐...
  • 本规范规定了ERP软件测评的基本功能指标
  • 智慧社区考核评价系统 (2).docx智慧社区考核评价系统 (2).docx智慧社区考核评价系统 (2).docx智慧社区考核评价系统 (2).docx智慧社区考核评价系统 (2).docx智慧社区考核评价系统 (2).docx智慧社区考核评价系统 (2)....
  • 智慧社区考核评价系统 (2).pdf智慧社区考核评价系统 (2).pdf智慧社区考核评价系统 (2).pdf智慧社区考核评价系统 (2).pdf智慧社区考核评价系统 (2).pdf智慧社区考核评价系统 (2).pdf智慧社区考核评价系统 (2).pdf智慧...
  • Web应用技术的迅猛发展与日趋成熟,给信息资源的管理和应用者带来了全新的机遇与挑战,作为供应链管理(SCM)信息系统的子系统之一的供应商考核评价系统,应该充分利用信息技术发展的成果,将其作为有力的技术支撑,在...
  • 基于模糊评价与自适应修正模型的软件质量评价(全文).docx
  • 评价可维护性的五个指标: Decomposability(可分解性),将问题分解成各个可独立解决的子问题。 Composability(可组合性),可容易的将模块组合起来形成新的系统。 Understandability(可理解性),每个子模块...
  • 基于Web的供应商考核评价系统研究.doc
  • 软件测试和维护

    千次阅读 2021-03-12 17:53:50
    一、软件测试 1、测试的目的 软件测试是软件质量...1983年,BillHetzel在"CompleteGuideofSoftwareTesting"一书中指出:"测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量". Grenf
  • 区块链的可维护性主要考察印记管理、系统管理、策略管理、智能合约、易部署性五个方面。 (一)应急管理:商业区块链A应急管理体系完善,商业区块链B和Fabric无应急管理体系 应急管理主要测试一个指标:区块链网络...
  • 谁能告诉我这科的理论在哪可以实用呀?搞懂,只能收藏一下包挂科
  • 本文是为大家整理的可靠性评价主题相关的10篇毕业论文文献,包括5篇期刊论文和5篇学位论文,为可靠性评价选题相关人员撰写毕业论文提供参考。
  • 软件的高可用扩展和高性能 高可用 软件的高可用是指软件间断运行能力,它一方面要求软件所依赖的设备本身具有高可靠,另一方面必须从软件的设计...软件扩展表现为基础设置需要经常变更,应
  • 针对矿井通风系统安全评价体系存在相似之处可以相互借鉴的实际情况,提出了安全评价的内容和评价体系的构建原则,从理论角度对通风系统安全评价指标进行了分级,并分析了各安全评价指标的权重,结合某矿通风系统现状进行...
  • 应用本身对系统运行的可靠要求越来越高,在一些关键的应用领域,如航空、航天等,其可靠要求尤为重要,在银行等服务行业,其软件系统的可靠也直接关系到自身的声誉和生存发展竞争能力。  特别是软件可靠...
  • TCQAE 11006-2018 物联网信息数据库系统指标体系及检验方法
  • 软件工程产品评价》中这样定义的:“实体特性的综合,满足明确或隐含要求的能力”3.2测度与度量一个实体的质量好坏是需要测量的,而测试就需要首先建立质量指标体系或质量模型,然后使用特定测量方法才能实施测量...
  • 经典文摘:浅谈软件可维护性问题

    千次阅读 2014-11-26 23:29:19
    一、前言很多包括自己在内的开发人员都会经常去借用(我们不用剽窃这个词了!呵呵)开源代码进行二次开发;或者在前辈的遗留代码下,继续修修补补。这种经历往往并像看起来那么简单——有时看懂,进而修改别人的...
  • 在参考了大量的实践案例和文献的基础上,结合项目特征和实际制定本验收标准指导书,确立项目质量目标,规范软件的验收。...适用于公司所有IT类型项目(包括合同开发类、项目实施类以及系统集成类)的验收标准确定。
  • 软件项目运维内容 软件系统运维工作内容 ERP项目运维的内容包括哪些 企业资源管理ERP:在线ERP是针对物资资源管理(物流)、人力资源管理(人流)、财务资源管理(财流)、信息资源管理(信息流)集成一体化的...
  • 建立电子政务工程运行维护的绩效评估机制建立电子政务工程运行维护的绩效评估机制.docx建立电子政务工程运行维护的绩效评估机制建立电子政务工程运行维护的绩效评估机制.docx建立电子政务工程运行维护的绩效评估机制...
  • 软件科技项目验收测试依据软件需求说明书以及相关行业标准、国家标准、法律法规等对软件的功能适合性、易用性、可靠性、可维护性和可移植性进行检测,对软件成果的质量进行科学的评价,为软件类科技成果的检测鉴定...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,666
精华内容 6,666
关键字:

软件系统的可维护性评价指标不包括