常见的软件质量模型
常见的软件质量模型
关于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模型有McCall 模型、Boehm 模型、FURPS 模型、Dromey 模型和 ISO9126 模型。
?Jim McCall 软件质量模型（1977 年）
?Barry W. Boehm 软件质量模型（1978 年）
?FURPS/FURPS+ 软件质量模型
?R. Geoff Dromey 软件质量模型
?ISO/IEC 9126 软件质量模型（1993 年）
?ISO/IEC 25010 软件质量模型（2011 年）
Jim McCall 软件质量模型（1977 年）
Jim McCall 的软件质量模型，也被称为 GE 模型（General Electrics Model）。其最初起源于美国空军，主要面向的是系统开发人员和系统开发过程。McCall 试图通过一系列的软件质量属性指标来弥补开发人员与最终用户之间的沟壑。
McCall 质量模型使用 3 中视角来定义和识别软件产品的质量：
1.Product revision (ability to change).
2.Product transition (adaptability to new environments).
3.Product operations (basic operational characteristics).
McCall 模型通过层级的要素、标准和指标来详述这 3 个视角定义（产品修改、产品转移、产品运行）。
?11 Factors (To specify)：描述软件的外部视角，也就是客户或使用者的视角。
?23 Criterias (To build)：描述软件的内部视角，也就是开发人员的视角。
?Metrics (To control)：定义衡量指标和方法
下图中，左侧为 11 个质量要素，右侧为 23 个质量标准。
Barry W. Boehm 软件质量模型（1978 年）
Boehm 软件质量模型试图通过一系列的属性的指标来量化软件质量。Boehm 的质量模型包含了 McCall 模型中没有的硬件属性。Boehm 模型也类似于
McCall 的质量模型，采用层级的质量模型结构，包括高层属性、中层属性和原始属性。
高层属性主要关注 3 个问题：
?As-is utility
?Maintainability
?Portability
中层属性包含了 7 个质量要素：
?Portability (General utility characteristics)
?Reliability (As-is utility characteristics)
?Efficiency (As-is utility characteristics)
?Usability (As-is utility characteristics, Human Engineering)
?Testability (Maintainability characteristics)
?Understandability (Maintainability characteristics)
?Flexibility (Maintainability characteristics, Modifiability)
可以看出，Boehm 模型和 McCall 模型有些相似，区别在于McCall 模型主要关注于高层属性（"As-is utility"）的精确度量上，而Boehm 模型则基于更广泛的属性，并且对可维护性做了更多的关注。
FURPS/FURPS+ 软件质量模型
FURPS 模型最初由 Robert Grady 提出，后来由 Rational Software 进行扩展至 FURPS+。
FURPS 模型包括：
?Functionality
?Usability
?Reliability
?Performance
?Supportability
FURPS 包括两种不同的类型：功能性和非功能性。
R. Geoff Dromey 软件质量模型
Dromey 软件质量模型由 3 个主要元素组成:
1.Product properties that influence quality
2.High level quality attributes
3.Means of linking the product properties with the quality
attributes.
构建该质量模型包括以下 5 个步骤：
1.Chose a set of high-level quality attributes necessary for
the evaluation.
2.List components/modules in your system.
3.Identify quality-carrying properties for the
components/modules (qualities of the component that have the most
4.impact on the product properties from the list above).
5.Determine how each property effects the quality
attributes.
6.Evaluate the model and identify weaknesses.
ISO/IEC 9126 软件质量模型（1993 年）
ISO/IEC 9126: Software Product Evaluation: Quality Characteristics and Guidelines for their Use-standard
ISO/IEC 9126 模型是建立在 McCall 和 Boehm 模型之上的，同时加入了功能性要求，还包括识别软件产品的内部和外部质量属性。
软件的 6 个质量特征:
1.功能性(Functionality)：当软件在指定条件下使用时，软件产品提供满足明确和隐含需要的功能的能力；
2.可靠性(Reliability)：在指定条件下使用时，软件产品维持规定的性能级别的能力；
3.易用性(Usability)：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力；
4.效率(Efficiency)：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力；
5.可维护性(Maintainability)：软件产品可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规约变化的适应程度；
6.可移植性(Portability)：软件产品从一种环境迁移到另一种环境的能力。
ISO/IEC 9126-1 内部和外部质量特征：
ISO/IEC 9126-1 中的非技术因素：
下面是 ISO/IEC 9126 模型与McCall 模型和 Boehm 模型的对比：
ISO/IEC 25010 软件质量模型（2011 年）ISO/IEC 9126-1：2001 已被 ISO/IEC 25010：2011 代替并废止。
上图阐明了ISO/IEC 25000 SQuaRE系列标准的组织，其组成部分均称为分部。 SQuaRE系列国际标准内的分部有：
1.ISO/IEC 2500n 质量管理分部。构成这个分部的那些标准定义了
由SQuaRE系列标准中的所有其他标准引用的全部公共模型、术语和定义。
在针对特定应用情况使用适当标准方面的引用路径和高级的实用建议有
助于所有类型的用户。这一分部还提供了用于负责管理软件产品需求和评价的支持功能的要求和指南。
2.ISO/IEC 2501n 质量模型分部。构成这个分部的标准给出一个包
括软件内部质量、软件外部质量和软件使用质量的特性的详细质量模型。
此外, 内部和外部的软件质量特性被分解细化成一些子特性，并且还提供了使用该质量模型的实用指南。
3.ISO/IEC 2502n 质量测量分部。构成这个分部的标准包括软件产
品质量测量参考模型、质量测量的数学定义及其应用的实用指南。给出了
应用于软件内部质量、软件外部质量和使用质量的测量。定义并给出了构
成后续测量基础的质量测量元素。
4.ISO/IEC 2503n 质量要求分部。构成这个分部的标准帮助用户规
定质量要求。这些质量要求可用在要开发的软件产品的质量需求抽取过程中或用作评价过程的输入。需求定义过程可映射到ISO/IEC 15288 中定
义的技术过程。
5.ISO/IEC 2504n 质量评价分部。构成这个分部的标准给出了无论
由评价方、需方还是由开发方执行的软件产品评价的要求、建议和指南。
还给出了作为评价模块的测量文档编制支持。
6.ISO/IEC 25050到ISO/IEC 25099保留用于SQuaRE扩展的国际
标准和/或技术报告。
软件质量模型包含 8 个特征，并且被进一步分解为可以度量的内部和外部多个子特征。
ISO/IEC 25010 中新增了软件使用质量，其包含 5 个特征，并进一步被划分为可以被度量的多个子特征。
?使用质量：在特定的使用周境中，软件产品使得特定用户能达到有效性、生产率、安全性和满意度的特定目标的能力。
质量模型与目标系统的关系：
质量的生命周期：
几种常见的测试模型汇总
几种比较常见的测试模型汇总： V模型 V模型最早是由Paul Rook在２０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。Ｖ模型反映出了测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。 V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。 但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 W模型（也叫双V模型）
W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发 阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代 表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型 有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。 X模型 X模型是由Marick提出的，他的目标是弥补V模型的一些缺陷，例如：交接、经常性的集成等问题。 X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试， 此后将进行频繁的交接，通过集成最终合成为可执行的程序。右上半部分，这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。 但V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。而且由于X模型从没有被文档化，其内容一开始需要从V模型的相关内容中进行推断，因为它还没有完全从文字上成为V 模型的全面扩展。
顾客感知服务质量模型
顾客感知服务质量模型 编辑本段模型的提出 1982年，瑞典著名服务市场营销学专家克·格鲁诺斯提出“顾客感知服务质量模型”，认为顾客对服务质量的评价过程实际上就是将其在接受服务过程中的实际感觉与他接受服务之前的心理预期进行比较的结果：如果实际感受满足了顾客期望，那么顾客感知质量就是上乘的，如果顾客期望未能实现，即使实际质量以客观的标准衡量是不错的，顾客可感知质量仍然是不好的,如右图。 格鲁诺斯的“顾客感知服务质量模型”的核心是“质量是由顾客来评价的”，实际上是要求服务厂商从顾客的角度来评价和管理服务质量，顺应了“以客户为中心”的现代市场营销潮流。特别是在市场竞争越来越激烈的服务市场营销中有特别重要的指导意义。 编辑本段模型的要素
1.技术质量与功能质量 技术质量与服务的产出有关，是在服务生产过程中和买卖双方的接触过程结束之后顾客所得到的客观结果。功能质量与服务的过程有关，是在服务生产过程中，通过买卖双方的接触，顾客所经历和所感受的东西。服务的技术质量表示顾客得到的是什么(wHAT)，便于顾客客观的评估；而功能质量则表明顾客是如何得到这些服务结果的(HOW)，颇具主观色彩，一般很难客观地评定。 2.期望质量与经验质量 期望质量就是顾客在头脑中所想象的或期待的服务质量水平。它是一系列因素的综合作用的结果，包括：①营销宣传，如广告、邮寄、公共关系、推销等； ②顾客以往接受的相同或类似服务的经历，作为质量标杆，对顾客的期望产生影响； ③提供服务的企业形象越好，顾客对其服务的期望值就越高； ④其他顾客接受类似服务后所做的评价也会影响某个顾客的服务评价； ⑤顾客对服务的需求越强烈紧迫，对服务质量的期望值就越低。 顾客的经验质量是指顾客在接受服务的过程中，通过对服务的技术质量和功能质量的体验和评价而得到的印象。 编辑本段质量的定义 格罗鲁斯第一次提出了顾客感知服务质量概念。认为顾客感知服务质量是顾客对服务期望（expectation）与实际服务绩效（perceived performance）之间的比较。实际服务绩效大于服务期望，则顾客感知服务质量是良好的，反之亦然。顾客满意的感知服务质量至少是经验质量与期望质量相符，或比期望略高。追求过高的服务质量在经济上是不划算的，而太低的感知质量则会导致顾客不满意。因此，服务质量管理的主要目标就是要追求最佳(即性能／价格比最高)的顾客感知质量。 编辑本段维度划分
DCAM：数据管理能力评估模型(word)
DCAM 数据管理能力评估模型 本文介绍EDM 企业数据管理理事会"DCAM 数据管理能力评估模型" ?DCAM简介 ?DCAM主要内容 ?DCAM评估模型 ?DCAM评估报告（案例） DCAM 简介 DCAM 数据管理能力评估模型是EDM 企业数据管理理事会基于全球领先企业/组织的最佳实践，综合跨企业数据管理经验形成。DCAM 数据管理能力评估模型定义并发布了企业所需的数据管理能力，强调以数据战略和数据治理驱动开展数据管理在技术和规程最佳实践，基于业务价值和业务目标实现，开展数据管理的基本原则。 ?数据被企业作为融合业务和组织过程的核心要素之一； ?数据生命周期的管理和实现是企业利用数据获得降本增效、自动化运营、归并冗余系统、最优化协调增强客户服务的关键。 DCAM 考虑的主要问题 ?较多组织对于数据管理概念模糊，理解不清； ?组织中的数据已然是无处不在，缺乏良好的框架进行管理； ?大量的数据零散在各个业务应用系统中，或是凌乱堆放在数据仓库中需要管理； ?数据的归属、可信和可靠性难以确认，数据带来的业务冲突和阻断带来挑战； ?不良数据所形成的数据基础，难以获得组织的分析、洞察，影响业务协同和客户服务。
?数据的术语、命名、约定等，成为实现业务、数据、IT一致性的关键，诸多业务、IT的阻力屡见不鲜； 当前企业数据管控环境可体现为，如下5个方面： 1.遗留问题，缺乏统一的技术和操作环境； 2.过于简单，缺乏整体复杂度考虑； 3.业务一致性，缺乏对数据精准的理解； 4.数据质量，缺乏数据协同和转换环境下的数据质量管理； 5.技术实现，缺乏数据集成和平台管控。 DCAM 价值 ?DCAM 提供企业数据管理现状指导和建议； ?DCAM 提供企业数据管理未来目标规划建议
软件工程考试题库
软件工程概述 一单项选择 1．软件生命周期一般包括：软件开发期和软件运行期，下述（D）不是软件开发期所应包含的内容。 A需求分析B结构设计C程序编制D软件维护 2．软件是一种逻辑产品，它的开发主要是（A）。 A研制B拷贝C再生产D复制 3．以文档作为驱动，适合于软件需求很明确的软件项目的生存周期模型是（C）。 A喷泉模型B增量模型C瀑布模型D螺旋模型 4．在软件生存周期中，（B）阶段必须要回答的问题是“要解决的问题是做什么？”。 A详细设计B可行性分析和项目开发计划C概要设计D软件测试 5．软件产品与物质产品有很大区别，软件产品是一种（C）产品 A有形B消耗C逻辑D文档 6．（C）把瀑布模型和专家系统结合在一起，在开发的各个阶段上都利用相应的专家系统来帮助软件人员完成开发工作。 A原型模型B螺旋模型C基于知识的智能模型D喷泉模型 7．(B)阶段是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。 A概要设计B详细设计C编码D测试 8．下列软件开发模型中，适合于那些不能预先确切定义需求的软件系统的开发的模型是（A）。 A原型模型B瀑布模型C基于知识的智能模型D变换模型 9．下列软件开发模型中，以面向对象的软件开发方法为基础，以用户的需求为动力，以对象来驱动的模型是（C）。 A原型模型B瀑布模型C喷泉模型D螺旋模型 10．下列软件开发模型中，支持需求不明确，特别是大型软件系统的开发，并支持多种软件开发方法的模型是（D）。 A原型模型B瀑布模型C喷泉模型D螺旋模型 11．软件特性中，使软件在不同的系统约束条件下，使用户需求得到满足的难易程度称为（C）。 A可修改性B可靠性C可适应性D可重用性 12．软件特性中，一个软件能再次用于其他相关应用的程度称为（B）。 A可移植性B可重用性C容错性D可适应性 13．软件特性中，（A）是指系统具有清晰的结构，能直接反映问题的需求的程度。 A可理解性B可靠性C可适应性D可重用性 14．软件特性中，软件产品交付使用后，在实现改正潜伏的错误、改进性能、适应环境变化等方面工作的难易程度称为（B）。 A可理解性B可维护性C可适应性D可重用性 15．软件特性中，软件从一个计算机系统或环境移植到另一个上去的难易程度指的是（C）. A可理解性B可修改性C可移植性D可重用性 16．软件特性中，在给定的时间间隔内，程序成功运行的概率指的是（D）。 A有效性B可适应性C正确性D可靠性 17．软件特性中，允许对软件进行修改而不增加其复杂性指的是（A）。 A可修改性B可适应性C可维护性D可移植性 18．软件特性中，多个软件元素相互通讯并协同完成任务的能力指的是（B）。 A可理解性B可互操作性C可维护性D可追踪性 19．软件特性中，根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对软件需求进行逆向
几种常用软件开发工具比较
几种常用软件开发工具比较(2008-10-27 10:11:59) 标签：职场it [转]近日和公司的系统分析员探讨了几种开发工具的特性，由其总结了下面的内容。 文章客观评价了各种开发工具的优缺点，本人把文章拿来和大家一起讨论一下，欢迎专业人事补充和指正。 一、跨平台特性 VB：无★ PB：WINDOWS家族, Solaris,Macintosh ★★★ C++ Builder/Dephi：WINDOWS家族，Linux ★★★ VC：无★ JAVA：所有能够运行JAVA虚拟机的操作系统★★★★ 二、组件技术支持 VB：COM,ActiveX ★★★ PB：COM,JavaBean,Jaguar,UserObject使用：CORBA+Acti veX ★★★ C++ Builder/Dephi：COM, ActiveX CORBA（本身自带CORBA中间件VisiBroker，有丰富向导）★★★★★ VC：COM,ActiveX，CORBA(没有任何IDE支持，是所有C编译器的功能,需要CORBA中间件支持) ★★★ JAVA：JavaBean,CORBA;ActiveX ★★★★ 三、数据库支持级别 数据访问对象： VB：DAO,ADO,RDO功能相仿；★ PB：Transaction,DwControl，可绑定任何SQL语句和存储过程，数据访问具有无与比拟的灵活性★★★★ C++ Builder/Dephi：具有包括DataSource,Table,Query,Midas,ADO在内的二十多个组件和类完成数据访问★★★ VC：同VB，但有不少类库可供使用，但极不方便，开发效率很低★★ JAVA：JAVA JDBC API,不同的IDE具有不同的组件★★ 数据表现对象： VB：DBGriD，与数据库相关的数据表现控件只有此一种，只能表现简单表格数据，表现手段单一★ PB：DataWindow对象（功能异常强大，其资源描述语句构成类似HTML的另外一种语言，可在其中插入任何对象，具有包括DBGrid在内的数百种数据表现方法），只此一项功能就注定了PB在数据库的功能从诞生的那 一天起就远远超过了某些开发工具今天的水平★★★★★ C++ Builder/Dephi：具有包括DBGrid,DBNavigator,DBEdit,DBLookupListBox在内的15 个数据感知组件，DecisionCube,DecisionQuery在内的6个数据仓库组件和包括QRChart, QRExpr在内的20多个报表组建，可灵活表现数据★★★
软件工程——软件开发过程中用到的各种图
软件工程——软件开发过程中用到的各种图 一、宏观导图 导图说明：我们的软件开发中用到的各种图型工具都是为了辅助我们更好的理解开发的阶段或者过程。上图是根据软件过程中各个阶段所需要用到的各种图的一个小结。下面是各种图的简介和示例。 二、谈细节： 1、问题定义阶段（规划阶段）： UC图:（ Use Creat 图）它是 BSP（ business system planning ）法中常用的子系统划分工具。
2、可行性分析 2.1系统流程图：是描述系统物理模型的一种传统工具。它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
3、需求分析： 3.1 DFD图（Data Flow Diagram):从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程.建立系统的功能模型。 3.2 ERD（Entity-Relationship Diagram)图：当数据量很大并且数据间关系复杂时对于数据的分析就得用到它来刻画系统数据模型
3.3 IPO（input process output）图描述了输入数据、处理数据、输出数据之间的关系。 3.4 STD（State Transition Diagram）图：刻画系统响应外部事件的过程。为系统的行为建模。
面向数据结构的几个图形工具： 3.5 层次方框图：用来展示数据的层次结构 3.6 warnier图：和层次方框图一个意思，不过她能描述的手段比层次图更加丰富。
电子装备软件质量评估模型分析
总第２４３期 ２０１０年第１期 计算机与数字工程 Ｃｏｍｐｕｔｅｒ＆ＤｉｇｉｔａｌＥｎｇｉｎｅｅｒｉｎｇ Ｖ０１．３８Ｎｏ．１ ４４ 电子装备软件质量评估模型分析＋ 崔天意刘庆峰张芝龙 （９１４０４部队秦皇岛０６６００１） 摘要软件质量是软件的生命，软件测试和评价是保证软件质量的重要手段。没有完备的软件质量评价程序和评价方法，质量是很难保证的。文章提出了一种基于缺陷分布模型、专家知识和神经网络方法的电子装备软件专用的质量评估方法，该方法使用电子装备软件的可靠性评估值、功能分析评估值和作战效能评估指标等专用参数作为模型的输入，利用加权综合评判方法完善模型，最终输出软件质量评估值。经实装测试试验证明了该方法的可行性和有效性。 关键词电子装备软件；神经网络；作战效能；质量评估 中图分类号ＴＰ２７３＋．４ ＥｌｅｃｔｒｏｎＷｅａｐｏｎｒｙＳｏｆｔｗａｒｅＱｕａｌｉｔｙＥｖａｌｕａｔｉｏｎＭｅｔｈｏｄ ＣｕｉＴｉａｎｙｉＬｉｕＱｉｎｇｆｅｎｇＺｈａｎｇＺｈｉｌｏｎｇ （Ｎｏ９１４０４ＴｒｏｏｐｓｏｆＰＬＡ，Ｑｉｎｈｕａｎｇｄａｏ０６６００１） ＡｂｓｔｒａｃｔＴｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙｉｓｔｈｅｉｍｐｏｒｔａｎｃｅｏｆｔｈｅｓｏｆｔｗａｒｅ，ｓｏｆｔｗａｒｅｔｅｓｔａｎｄｅｖａｌｕａｔｉｏｎａｒｅｔｈｅｉｍｐｏｒｔａｎｔｍｅａｎｓｗｈｉｃｈｐｒｏｍｉｓｅｓｓｏｆｔｗａｒｅｑｕａｌｉｔＢＴｈｅｒｅａｒｅｎｏｃｏｍｐｌｅｔｅｅｖａｌｕａｔｉｏｎｐｒｏｃｅｄｕｒｅｏｆｔｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙａｎｄｅｖａｌｕａｔｉｏｎｍｅｔｈｏｄ，ｔｈｅｑｕａｌｉｔｙｉｓｖｅｒｙｄｉｆｆｉｃｕｌｔａｓｓｕｒｉｎｇ．ＴｈｅａｒｔｉｃｌｅｐｕｔｆｏｒｗａｒｄａｋｉｎｄｏｆｔｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙｖａｌｕａｔｉｏｎｍｅｔｈｏｄｆｏｒｔｈｅｅｌｅｃｔｒｏｎｂａｔｔｌｅｓｙｓｔｅｍａｃｃｏｒｄｉｎｇｔＯｂｕｇｄｉｓｔｒｉｂｕｔｉｎｇｅｘｐｅｒｆｓｋｎｏｗｌｅｄｇｅａｎｄｎｅｒｖｅｎｅｔｗｏｒｋＴｈｅｍｅｔｈｏｄｕｓａｇｅｅｌｅｃｔｒｏｎｗｅａｐｏｎｒｙｓｏｆｔ—ｗａｒｅｂａｔｔｌｅｅｆｆｅｃｔｅｔｃｐａｒａｍｅｔｅｒｂｅｔｈｅｉｍｐｏｒｔａｔｉｏｎｏｆｍｏｄｅｌ．ｔｈｅｅｘｐｌｏｉｔａｔｉｏｎａｄｄｓｐｏｗｅｒｃｏｍｐｒｅｈｅｎｓｉｖｅａｄｊｕｄｉｃａｔｅａｍｅｔｈｏｄｅｓｔａｂｌｉｓｈｍｅｎｔｍｏｄｅｌ．Ｏｕｔｐｕｔｓｏｆｔｗａｒｅｑｕａｌｉｔｙｖａｌｕａｔｉｏｎ．ＴｈｒｏｕｇｈａｃｔｕａｌｌｙｐａｃｋｅｄａｔｅｓｔｔＯｅｘｐｅｒｉｍｅｎｔｔＯｐｒｏｖｅｔｈｅｐｏｓｓｉｂｉｌｉ—ｔｙ ａｎｄｕｓｅｆｕｌｎｅｓｓｏｆｔｈａｔｍｅｔｈｏｄ． Ｋｅｙ Ｗｏｒｄｓｅｌｅｃｔｒｏｎｗｅａｐｏｎｒｙｓｏｆｔｗａｒｅ，ｎｅｔｗｏｒｋｎｅｕｒｏｎ，ｃａｍｐａｉｇｎｅｆｆｉｃｉｅｎｃｙ，ｑｕａｌｉｔｙｅｖａｌｕａｔｉｏｎＣｌａｓｓＮｕｍｂｅｒＴＰ２７３＋．４ １引言 在现代各种电子战装备系统中，以软件为核心的产品得到了广泛的应用，随着系统中软件成分的不断增加，使得系统对于软件的依赖程度越来越大，对软件质量尤其是可靠性、可维护性和功能性的要求也越来越高［１］。软件质量是软件的生命，软件测试和评价是保证软件质量的重要手段。没有完备的软件质量评价程序和评价方法，质量是很难保证的。 现役电子战装备软件在通过测试之后，各项技术指标可以达到预定要求，但不一定具有较高的作战效能。即软件技术测试合格的系统仍然不符合实际应用要求。因为软件测试只注重软件本身的故障特性，而忽略了对于装备软件至关重要的软硬件配置拟合度和战术合理性等非技术性指标。例如：软件设计的舰艇机动动作要求舰艇在短时间内转向；多种干扰样式组合导致干扰失败；电磁干扰使软件失效。因此作战效能评估对电子战装备软件质量起决定性作用。 从常规的角度来看，质量是一个无形的特性，可以对其进行讨论、感知和判断，不能进行测量。从专业的角度来看，为了提高质量，必须对其进行定义和测量，并将其描述为“与客户需求的一致 －收稿日期：２００９年９月１０日，修回日期：２００９年１０月１５日 作者简介：崔天意，男，硕士，工程师，研究方向：作战系统软件测试及软件测试质量研究。万方数据
数据质量评价模型的建立和实现
[摘要] 本文提出了数据质量评价模型、质量校验与评价方法，论述了“数据质量分析评价系统”的程序实现流程、总体结构及功能，介绍了系统的关键技术及进一步的研究方向。 [关键词] 质量模型质量检验质量评价 数据作为一种资源，是支撑信息化建设和应用的主体，根据“进去的是垃圾,出来的也是垃圾”这条原理,为了支持正确决策,就要求我们所管理的数据可靠,没有错误,能够准确地反映采油厂的实际情况。胜利采油厂数据中心存放了5千万条的数据，还在以每天2万条的速度加载，如何使这些海量数据在生产管理、科学研究、企业决策中发挥应有作用，使用户能用、敢用、愿用，使数据真正为企业服务，这是几乎所有信息化企业亟需迫切解决的问题。为解决数据质量问题，各种管理手段、技术手段和新的数据评价体系不断被应用在数据的采集和加工过程中。 一、数据质量评价模型的提出背景 采油厂的数据资源具有:横跨专业多，数据采集密度大、频度高，数据处理流程复杂等特点，为了保证数据的可用性，数据管理人员在客户端、服务器端均设置了数据质量审核规则，但是依然不可避免存在比例较高的数据质量问题，典型的有记录不全、数据遗漏、数据错误、多义字段、矛盾值、违背业务规则、无法关联等。产生数据问题的根本原因可以归结为以下几个方面: 1.没有从数据资源的战略高度对数据质量进行统一完整的定义，导致数据的分析评估没有统一可靠的标准； 2.数据质量还停留在定性评价,不能实现精确的量化评价，只是在业务需要某个数据时,才到库里去手动统计,无法动态记录某个单位、某个月的真实数据质量发生情况,导致数据质量考核缺乏可信的数据依据,大大影响考核力度; 3.没有一个能同时面对用户、专业部门、数据管理人员的可视化的数据质量监控评价平台,三方无法共享一个平台,共同实行数据管控一体化,导致业务规则的变更滞后,问题数据在库中的长期滞留; 4.也许有了N个业务模型,但是没有把它放到时间轴上去控制流程,导致实际生产中应该发生的活动的部分生产数据遗漏； 虽然影响采油厂数据质量的原因是多方面的，但主要的原因还是集中在管理、制度和数据采集加工规范化方面。对于如何通过管理、制度、标准和流程来控制数据质量,提高数据可信度,我们提出建立采油厂统一的数据质量分析评价模型，使用管理手段和技术手段相结合的办法,建立一套完善的数据定义、控制、评估流程，依托科学严谨的数据监督和质量控制体系持续地改进数据质量。 二、数据质量分析评价模型构成 构成数据质量分析评估模型的要素分别为:基础模型、数据质量辅助模型、数据质量定义模型、数据质量控制模型、数据质量评价模型。 1.基础模型。基础模型部分是整个模型框架的支撑核心部分，其他质量模型的定义和控制必须以基础模型中的计划和标准为依据。基础模型主要是映射、定义数据采集标准,上载分单位的采集计划,同时纳入了约束规则定义规范、控制规则定义规范、模板定义规范。 数据标准:分两部分,一部分是直接映射应用中的标准，例如源数据库标准;另一部分是针对新增应用库和项目库标准的定义规范,包括代码定义标准、数据项定义标准(例如是取英文还是汉语拼音,取几个字符）、值域定义标准等等新增表准的建立规范； 采集计划:采集单位的每月上载的日度、月度、年度的采集计划;
几种软件开发工具的区别
java、c、c++、vc、vc++、vb的区别和联系 java:分三大平台java se (j2se),java ee(j2ee),java me(j2me) java se是java ee和java me的基础 java ee是目前位置企业级开发平台中最牛的 java me是用来开发移动嵌入式程序的，例如手机游戏 java 的优点是非常适合用于开发大型企业级项目，我们曾为网通公司开发过的上千万级的项目，用的后台程序就是java ee。 java的主要领域还有开源技术，那要学的东西就太多了，比如(Spring,Ibatis,DWR,Hibernate，Tapestry等) 缺点是要学的技术太多，二是在底层开发中不行 C：经久不衰的语言 主要应用在嵌入式编程，硬件驱动程序设计中，说白了是计算机底层的编程设计 优点是可以嵌入汇编，可以直接与硬件打交道，做底层开发 缺点是在企业级开发中，几乎无用武之地 我朋友是做这个的，在长沙这种小地方，年薪也能达到10万以上 与北京的java程序员收入差不多 在北京的话，年薪20万不是大问题。 c++ ：我非常钦慕的语言，又AT&T的贝尔实验室研发 主要开发工具是微软的Visual C++和Borload的BCB（Borload C++ Builder） 优点在于含有大量的库，如MFC，可直接调用windows库函数干很多事情 其中的消息处理机制令我感觉尤为经典 缺点是，要想精通真不容易 主要领域一是做桌面程序，像QQ，迅雷这种桌面软件 领域二是做游戏后台开发，大部分游戏（包括魔兽等）后台语言就是使用C++ 精通的话，收入和C程序员差不多 vc ：刚说过了，vc全名是（Microsoft Visual C++） 是微软研发的一种开发C++的开发工具（IDE） vc++：同vc 注意c++是语言，vc++是工具，是一门使用c++语言的工具，记清楚，以后不要问这样肤浅的话。 以上几种，对比一下学java，学的不仅仅是技术，而是一种思想，架构项目的思想 所以java是培养架构师,培养System Designer，Project Manager的 c语言和c++只能培养技术专家，资深程序员 vb：曾经很流行的一种桌面程序开发技术 微软研发的（Visual Basic）是一种工具，用的语言是Basic Basic是比尔盖兹发家致富的一大工具
软件开发模型介绍与对比分析
常用的软件开发模型 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。 1. 瀑布模型-最早出现的软件开发模型 1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的软件过程如图所示）
大数据平台 数据质量评价维度
附录A （资料性附录） 数据质量评价维度 A.1 完整性 按照数据规则要求，数据元素被赋予数值的程度。即完整性指的是数据信息是否存在缺失的状况，数据缺失的情况可能是整个数据记录缺失，也可能是数据中某个字段信息的记录缺失。不完整的数据所能借鉴的价值会大大降低，完整性是数据质量评估标准的基础。 表A.1完整性评价指标 A.2 规范性 数据符合数据标准、数据模型、业务规则、元数据或权威参考数据的程度。 表A.1规范性评价指标
表A.2 （续） A.3 一致性 数据与其他特定上下文中使用的数据无矛盾的程度。即一致性是指数据是否遵循了统一的规范，数据集合是否保持了统一的格式。数据质量的一致性主要体现在数据记录的规范和数据是否符合逻辑。 表A.2 一致性评价指标 11
数据准确表示其所描述的真实实体（实际对象）真实值得程度。即准确性是指数据记录的信息是否存在异常或错误。 表A.3 准确性评价指标 A.5 唯一性 数据唯一不重复。即唯一性是指度量哪些数据是重复数据或者数据的哪些属性是重复的。 A.6 关联性 数据的关联不可缺失的。即关联性是度量哪些关联的数据缺失或者未建立索引。 关联性评价因素： a)查找到的信息和主题不完全一致，但确是其中某一方面的阐述； b)查找到的信息集合多数在用户需要的检索主题内； c)提供的信息主题与用户检索主题相匹配； d)查找到的信息多数与用户需要的信息无关； e)信息必须和用户需求有相关性。
数据在时间变化中的正确程度。即及时性是指数据从产生到可以查看的时间间歇，也叫做数据的延时时长，及时性对数据分析本身要求并不高，但如果数据分析周期加上数据建立的时间过长，就可能导致分析出的结论失去借鉴意义。 表A.4 时效性评价指标 A.8 可访问性 数据能被访问的程度。 表A.5 可访问性评价指标 13
软件开发模型介绍与对比分析
常用的软件开发模型 任务的结构框 架。软件开发包括需求、设 段。 软件开发 模型能清晰、直观地表达软 计、编码和测试等阶段，有 时也包括维护阶 件开发全过程，明确规定了 要完成的主要活 动和任务，用来作为软 件项目工作的基础。对于不同的软件 系统，可以采用不同的开 理方法和手段 等，以及允许采用不同的软件工 具和不同的软件工程环境。 1. 瀑布模型 -最早出现的软件开发模型 1970 年温斯顿 ?罗伊斯( Winston Royce )提出了著名的 “瀑布模型 ”，直到 80 年 代早期，它一 直是唯一被广泛采用的软件开发 模型。 瀑布模型 核心思想是按工序将问题化简 ，将功能的实现与设计分开 ，便于分工协 作，即采 用结构化的分析与设计方法将逻 辑实现与物理实现分开。将 软件生命周期划 分为制定计划 、需求分析、软件设计、程序编写、软件测试和运行维 护等六个基本活 动，并 且规定了它们自上而下 、相互衔接的固定次序 ，如同瀑布流水，逐级 下落。从 本质来讲，它是一个软 件开发架构，开发过程是通过一系列 阶段顺序展开的，从系统 需求分析开始 直到产品发布和维护，每个阶段都会产 生循环反馈，因此，如果有信息 未被覆盖或者 发现了问题， 那么 最好 “返回 ”上一个 阶段并进行适当的修改 ，开发进程 从一个阶段 “流动 ”到下一个阶段， 这也是瀑布开发名称的由来。 瀑布模型是最 早出现的软件开发模型，在软件工程中占有重要的地位 ，它提供了 软件开发的基 本框架。其过程是从上一项 活动接收该项活动的工作对象作 为输入，利 用这一输入实 施该项活动应完成的内容给出该 项活动的工作成果， 并 作为输出传给下 一项活动。同 时评审该项活动的实施，若确认 ，则继续下一项活动；否则返 回前面， 甚至更前面的 活动。对于经常变化的项目而 言，瀑布模型毫无价值。(采用瀑布模型 的软件过程如 图所示) 软件 开发模型 (Software Development Model) 是指软件开发 全部过程、活动和 发方法、使用不同的程序设计语言以及各 种不同技能的人员参与工作 、运用不同的管
常见的软件质量模型
常见的软件质量模型 关于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模 型有McCall模型、Boehm模型、FURPS模型、Dromey模型和ISO9126模型。 JimMcCall软件质量模型（1977年）?BarryW.Boehm软件质量模型（1978年）?FURPS/FURPS+软件质量模型?R.GeoffDromey软件质量模型?ISO/IEC9126软件质量模型（1993年）?ISO/IEC25010软件质量模型（2011年）? Jim McCall软件质量模型（1977年） Jim McCall的软件质量模型，也被称为GE模型（General Electrics Model）。其最初起源于美国空军，主要面向的是系统开发人员和系统开发过程。McCall试图通过一系列的软件质量属性指标来弥补开发人员与最终用户之间的沟壑。 McCall质量模型使用3中视角来定义和识别软件产品的质量： 1.Product revision(ability to change). 2.Product transition(adaptability to new environments). 3.characteristics).operational(basic operations Product
McCall模型通过层级的要素、标准和指标来详述这3个视角定义（产品 修改、产品转移、产品运行）。 11Factors(To specify)：描述软件的外部视角，也就是客户?或使用者的视角。：描述软件的内部视角，也就是开发build)Criterias(To23?人员的视角。：定义衡量指标和方法control)(ToMetrics? 个质量标准。23个质量要素，右侧为11下图中，左侧为
如何对软件质量进行评估
如何对软件质量进行评估 1 软件质量的有关概念软件质量是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。1.1 软件质量框架模型如图1所示，软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。 在这个框架模型中，上层是面向治理的质量特征，每一个质量特征是用以描述和评价软件质量的一组属性，代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定，而且必须从其内部所具有的特征来确定。 第二层的质量子特征是上层质量特征的细化，一个特定的子特征可以对应若干个质量特征。软件质量子特征是治理人员和技术人员关于软件质量问题的通讯渠道。 最下面一层是软件质量度量因子（包括各种参数），用来度量质量特征。定量化的度量因子可以直接测量或统计得到，为最终得到软件质量子特征值和特征值提供依据。如何对软件质量进行评估（图一） 图1 软件质量框架模型1.2 软件质量特征 按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价： a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。 b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。 c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属
性。 d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。 e.可维护特征：与进行指定的修改所需的努力有关的一组属性。 f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。 2 评估指标的选取原则 选择合适的指标体系并使其量化是软件测试与评估的要害。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。 在选取评估指标时，应该把握如下原则： a.针对性 即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。 b.可测性 即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。 c.简明性 即易于被各方理解和接受。 d.完备性 即选择的指标应覆盖分析目标所涉及的范围。 e.客观性 即客观反映软件本质特征，不能因人而异。 应该注重的是，选择的评估指标不是越多越好，要害在于指标在评估中所起的作用的大小。假如评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。 3 软件质量评估指标体系
常见的软件开发模型
常见的软件开发模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。 1.软件开发模型是对软件过程的建模，即用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，好比工厂的流水线。 2.软件开发模型能清晰、直观地表达软件开发全部过程，明确规定要完成的主要活动和任务，它用来作为软件项目工作的基础。 3.软件开发模型应该是稳定和普遍适用的 软件开发模型的选择应根据： 1.项目和应用的特点 2.采用的方法和工具 3.需要控制和交付的特点 软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.快速原型模型 4.增量模型 5.螺旋模型 6.喷泉模型 边做边改模型（Build-and-Fix Model） 国内许多软件公司都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改. 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； （2）忽略需求环节，给软件开发带来很大的风险； （3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
瀑布模型（Waterfall Model） 1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子. 快速原型模型（Rapid Prototype Model） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。 快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 增量模型（Incremental Model） 又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各
流行的软件开发工具有哪些
不同的领域需要不同的图软件开发工具，这需要根据大家的需求不懂来决定。下面来跟大家介绍一些流行的软件开发工具。 1. 桌面程序：Java、C++、C#、VB、C均可。 2. 网站服务器端开发：JSP(Java语法)、PHP、ASP(C#语法)、Web App 框架等 3. 网站客户端：HTML、CSS、Javascript、Flash等等 4. 智能手机程序：安卓使用Java，iPhone使用Objective-C 5. 底层、工具开发：C、C++ 6. 多功能脚本程序：Python、Perl、Ruby等等 7. 人工智能：Prolog、PDDL 8. 工业控制：C、PLC、汇编 9. 通用应用层数据交换处理技术：标记语言XML/XPATH/XSLT、JSON、YAML等等
软件开发平台包括基础开发平台和快速开发平台，基础开发平台是从0开始写代码，而快速开发平台一般是做好了一些现成中间件，节省一定代码量。也有完全不用写代码的，直接通过配置开发软件的快速开发平台。 1、.NET底层的：天纵开发平台 2、JAVA底层的：普元开发平台、起步开发平台 3、EXCEL表格类：勤哲、云表 黑帽科技是一家集软件定制开发、软件外包、智慧信息化建设的软件开发服务商，黑帽科技拥有成熟的APP定制开发、小程序定制开发、软件项目外包开发平台。是专业的互联网产品解决方案提供商，可提供互联网产品咨询、网站设计、网站开发、手机应用开发、移动应用开发。黑帽科技为政府、企业以及团体提供行业解决方案和产品工程解决方案以及相关软件产品、平台及服务。我们通过规范的软件服务管理流程、精确的需求响应、迅捷的软件交付能力，全面构造公司的核心竞争力，并打造一支专业的技术服务团队，成功服务于数百家用户，赢得了广大客户的尊重和认可。 想要了解更多详情内容请拨打联系电话或登录浙江黑帽科技有限公司官网
软件质量评估概念
软件质量评估 1 软件质量的有关概念 软件质量是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。 1.1 软件质量框架模型 如图1所示，软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。 在这个框架模型中，上层是面向管理的质量特征，每一个质量特征是用以描述和评价软件质量的一组属性，代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定，而且必须从其内部所具有的特征来确定。 第二层的质量子特征是上层质量特征的细化，一个特定的子特征可以对应若干个质量特征。软件质量子特征是管理人员和技术人员关于软件质量问题的通讯渠道。 最下面一层是软件质量度量因子（包括各种参数），用来度量质量特征。定量化的度量因子可以直接测量或统计得到，为最终得到软件质量子特征值和特征值提供依据。 1.2 软件质量特征 按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价： a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。 b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。 c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。 d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。 e.可维护特征：与进行指定的修改所需的努力有关的一组属性。 f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。
常用软件开发模型比较分析
常用软件开发模型比较分析 2007-09-26 20:21 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③ 以形式化开发方法为基础的变换模型（T ransformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在严重的缺陷。 ① 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。 ② 在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。 ③ 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。 1.2.2 螺旋模型螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这