常见的软件质量模型
关于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模
型有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下图中，左侧为
Barry W.Boehm软件质量模型（1978年）
Boehm软件质量模型试图通过一系列的属性的指标来量化软件质量。Boehm
模型也类似于Boehm模型中没有的硬件属性。McCall的质量模型包含了．McCall的质量模型，采用层级的质量模型结构，包括高层属性、中层属性和原始属性。
高层属性主要关注3个问题：
As-is utility?Maintainability?Portability?
中层属性包含了7个质量要素：
Portability(General utility characteristics)?characteristics)
(As-is utilityReliability?characteristics)utility Efficiency(As-is
?Human characteristics,(As-is utility Usability?Engineering) characteristics)(Maintainability Testability?characteristics) Understandability(Maintainability
?characteristics,(MaintainabilityFlexibility?Modifiability)
可以看出，Boehm模型和McCall模型有些相似，区别在于McCall模型
主要关注于高层属性（As-is瑵汩瑩屹）的精确度量上，而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/IEC9126软件质量模型（1993年）QualityEvaluation:Software Product9126:ISO/IEC
Use-standard their forandCharacteristics Guidelines
ISO/IEC9126模型是建立在McCall和Boehm模型之上的，同时加入了功能性要求，还包括识别软件产品的内部和外部质量属性。
软件的6个质量特征:
1.功能性(Functionality)：当软件在指定条件下使用时，软件产
品提供满足明确和隐含需要的功能的能力；
2.可靠性(Reliability)：在指定条件下使用时，软件产品维持规
定的性能级别的能力；
3.易用性(Usability)：在指定条件下使用时，软件产品被理解、
学习、使用和吸引用户的能力；
4.效率(Efficiency)：在规定条件下，相对于所用资源的数量，
软件产品可提供适当性能的能力；
5.可维护性(Maintainability)：软件产品可被修改的能力。修改
可能包括纠正、改进或软件对环境、需求和功能规约变化的适应程度；
6.可移植性(Portability)：软件产品从一种环境迁移到另一种环
境的能力。．
内部和外部质量特征：9126-1ISO/IEC．
中的非技术因素：9126-1 ISO/IEC．
模型的对比：Boehm和模型McCall模型与9126ISO/IEC下面是
ISO/IEC25010软件质量模型（2011年）ISO/IEC9126-1：2001已被ISO/IEC25010：2011代替并废止。
上图阐明了ISO/IEC25000SQuaRE系列标准的组织，其组成部分均称为分部。SQuaRE系列国际标准内的分部有：
1.ISO/IEC2500n质量管理分部。构成这个分部的那些标准定义
了由SQuaRE系列标准中的所有其他标准引用的全部公共模型、术语和定义。在针对特定应用情况使用适当标准方面的引用路径和高级的实用建
议有助于所有类型的用户。这一分部还提供了用于负责管理软件产品需
求和评价的支持功能的要求和指南。
2.ISO/IEC2501n质量模型分部。构成这个分部的标准给出一个
包括软件内部质量、软件外部质量和软件使用质量的特性的详细质量模型。此外,内部和外部的软件质量特性被分解细化成一些子特性，并且
还提供了使用该质量模型的实用指南。
3.ISO/IEC2502n质量测量分部。构成这个分部的标准包括软件
产品质量测量参考模型、质量测量的数学定义及其应用的实用指南。给
出了应用于软件内部质量、软件外部质量和使用质量的测量。定义并给
出了构成后续测量基础的质量测量元素。
4.ISO/IEC2503n质量要求分部。构成这个分部的标准帮助用户
规定质量要求。这些质量要求可用在要开发的软件产品的质量需求抽取
过程中或用作评价过程的输入。需求定义过程可映射到ISO/IEC15288
中定义的技术过程。
5.ISO/IEC2504n质量评价分部。构成这个分部的标准给出了无
论由评价方、需方还是由开发方执行的软件产品评价的要求、建议和指南。还给出了作为评价模块的测量文档编制支持。
6.ISO/IEC25050到ISO/IEC25099保留用于SQuaRE扩展的国际
标准和/或技术报告。
软件质量模型包含8个特征，并且被进一步分解为可以度量的内部和外
部多个子特征。
ISO/IEC25010中新增了软件使用质量，其包含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 模型的全面扩展。
软件工程概述 一单项选择 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．软件特性中，根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对软件需求进行逆向
总第２４３期 ２０１０年第１期 计算机与数字工程 Ｃｏｍｐｕｔｅｒ＆ＤｉｇｉｔａｌＥｎｇｉｎｅｅｒｉｎｇ Ｖ０１．３８Ｎｏ．１ ４４ 电子装备软件质量评估模型分析＋ 崔天意刘庆峰张芝龙 （９１４０４部队秦皇岛０６６００１） 摘要软件质量是软件的生命，软件测试和评价是保证软件质量的重要手段。没有完备的软件质量评价程序和评价方法，质量是很难保证的。文章提出了一种基于缺陷分布模型、专家知识和神经网络方法的电子装备软件专用的质量评估方法，该方法使用电子装备软件的可靠性评估值、功能分析评估值和作战效能评估指标等专用参数作为模型的输入，利用加权综合评判方法完善模型，最终输出软件质量评估值。经实装测试试验证明了该方法的可行性和有效性。 关键词电子装备软件；神经网络；作战效能；质量评估 中图分类号ＴＰ２７３＋．４ ＥｌｅｃｔｒｏｎＷｅａｐｏｎｒｙＳｏｆｔｗａｒｅＱｕａｌｉｔｙＥｖａｌｕａｔｉｏｎＭｅｔｈｏｄ ＣｕｉＴｉａｎｙｉＬｉｕＱｉｎｇｆｅｎｇＺｈａｎｇＺｈｉｌｏｎｇ （Ｎｏ９１４０４ＴｒｏｏｐｓｏｆＰＬＡ，Ｑｉｎｈｕａｎｇｄａｏ０６６００１） ＡｂｓｔｒａｃｔＴｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙｉｓｔｈｅｉｍｐｏｒｔａｎｃｅｏｆｔｈｅｓｏｆｔｗａｒｅ，ｓｏｆｔｗａｒｅｔｅｓｔａｎｄｅｖａｌｕａｔｉｏｎａｒｅｔｈｅｉｍｐｏｒｔａｎｔｍｅａｎｓｗｈｉｃｈｐｒｏｍｉｓｅｓｓｏｆｔｗａｒｅｑｕａｌｉｔＢＴｈｅｒｅａｒｅｎｏｃｏｍｐｌｅｔｅｅｖａｌｕａｔｉｏｎｐｒｏｃｅｄｕｒｅｏｆｔｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙａｎｄｅｖａｌｕａｔｉｏｎｍｅｔｈｏｄ，ｔｈｅｑｕａｌｉｔｙｉｓｖｅｒｙｄｉｆｆｉｃｕｌｔａｓｓｕｒｉｎｇ．ＴｈｅａｒｔｉｃｌｅｐｕｔｆｏｒｗａｒｄａｋｉｎｄｏｆｔｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙｖａｌｕａｔｉｏｎｍｅｔｈｏｄｆｏｒｔｈｅｅｌｅｃｔｒｏｎｂａｔｔｌｅｓｙｓｔｅｍａｃｃｏｒｄｉｎｇｔＯｂｕｇｄｉｓｔｒｉｂｕｔｉｎｇｅｘｐｅｒｆｓｋｎｏｗｌｅｄｇｅａｎｄｎｅｒｖｅｎｅｔｗｏｒｋＴｈｅｍｅｔｈｏｄｕｓａｇｅｅｌｅｃｔｒｏｎｗｅａｐｏｎｒｙｓｏｆｔ—ｗａｒｅｂａｔｔｌｅｅｆｆｅｃｔｅｔｃｐａｒａｍｅｔｅｒｂｅｔｈｅｉｍｐｏｒｔａｔｉｏｎｏｆｍｏｄｅｌ．ｔｈｅｅｘｐｌｏｉｔａｔｉｏｎａｄｄｓｐｏｗｅｒｃｏｍｐｒｅｈｅｎｓｉｖｅａｄｊｕｄｉｃａｔｅａｍｅｔｈｏｄｅｓｔａｂｌｉｓｈｍｅｎｔｍｏｄｅｌ．Ｏｕｔｐｕｔｓｏｆｔｗａｒｅｑｕａｌｉｔｙｖａｌｕａｔｉｏｎ．ＴｈｒｏｕｇｈａｃｔｕａｌｌｙｐａｃｋｅｄａｔｅｓｔｔＯｅｘｐｅｒｉｍｅｎｔｔＯｐｒｏｖｅｔｈｅｐｏｓｓｉｂｉｌｉ—ｔｙ ａｎｄｕｓｅｆｕｌｎｅｓｓｏｆｔｈａｔｍｅｔｈｏｄ． Ｋｅｙ Ｗｏｒｄｓｅｌｅｃｔｒｏｎｗｅａｐｏｎｒｙｓｏｆｔｗａｒｅ，ｎｅｔｗｏｒｋｎｅｕｒｏｎ，ｃａｍｐａｉｇｎｅｆｆｉｃｉｅｎｃｙ，ｑｕａｌｉｔｙｅｖａｌｕａｔｉｏｎＣｌａｓｓＮｕｍｂｅｒＴＰ２７３＋．４ １引言 在现代各种电子战装备系统中，以软件为核心的产品得到了广泛的应用，随着系统中软件成分的不断增加，使得系统对于软件的依赖程度越来越大，对软件质量尤其是可靠性、可维护性和功能性的要求也越来越高［１］。软件质量是软件的生命，软件测试和评价是保证软件质量的重要手段。没有完备的软件质量评价程序和评价方法，质量是很难保证的。 现役电子战装备软件在通过测试之后，各项技术指标可以达到预定要求，但不一定具有较高的作战效能。即软件技术测试合格的系统仍然不符合实际应用要求。因为软件测试只注重软件本身的故障特性，而忽略了对于装备软件至关重要的软硬件配置拟合度和战术合理性等非技术性指标。例如：软件设计的舰艇机动动作要求舰艇在短时间内转向；多种干扰样式组合导致干扰失败；电磁干扰使软件失效。因此作战效能评估对电子战装备软件质量起决定性作用。 从常规的角度来看，质量是一个无形的特性，可以对其进行讨论、感知和判断，不能进行测量。从专业的角度来看，为了提高质量，必须对其进行定义和测量，并将其描述为“与客户需求的一致 －收稿日期：２００９年９月１０日，修回日期：２００９年１０月１５日 作者简介：崔天意，男，硕士，工程师，研究方向：作战系统软件测试及软件测试质量研究。万方数据
常用的软件开发模型 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。 1. 瀑布模型-最早出现的软件开发模型 1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的软件过程如图所示）
产品质量检验流程图 1．产品质量检验流程与风险控制图 产品质量检验流程与风险控制 业务风险 不相容责任部门/责任人的职责分工与审批权限划分 阶段 总经理 技术总监 质量管理部 各生产单位 D1 D2 D3 审核 如果没有规范的产品质量检验标准和操作规范，企业生产的产品质量就得不到有效保障 如果对产品质量检验的每个环节把关不 严，产品质量就会受到影响，企业形象和消费者利益也会受到损害 如果不对产品存在的 质量缺陷和问题进行反思总结，产品的质量就得不到有效改善，最终将不利于企 业的长远发展 制定质量检验标准 结束 1 审批 原材料检验 在制品检验 产成品检验 开始 进行生产 审核 审批 执行质量检验标准 配合工作 修订质量检验标准 及操作规范 3 4 5 制定《质量检验 操作规范》 2 编写《年度质检 总结报告》 6
2．产品质量检验流程控制表 产品质量检验流程控制 控制事项详细描述及说明 阶段控制D1 1．质量管理部会同相关部门及专业人员参考国家标准、行业标准、国外标准、客户需求及本身制造能力等，严格制定产品质量检验标准，并报技术总监审核、总经理审批2．质量管理部应制定《质量检验操作规范》，对原材料、在制品、产成品的检查项目、质量标准、检验频率、检验方法及使用仪器设备等进行详细说明 D2 3．原材料购入时，仓库管理部门应依据相关规定办理收料，并通知质量管理部人员进行检验，质量管理部检验人员应依照原材料质量标准及检验规范的规定完成检验，对不 符合质检要求的原材料进行相应的退换货处理 4．质量管理部检验人员对制造过程的在制品均应依照在制品质量标准及检验规范实施质量检验，以提早发现问题并迅速处理，确保在制品质量 5．质量管理部检验人员应依照产成品质量标准及检验规范实施质量检验，以提早发现问题并迅速处理，以确保产成品质量 D3 6．质量管理部应每年提交《年度质检总结报告》，对本年度产品质量检验的标准、规范及执行情况进行总结，并提出产品质量检验标准及检验规范的修订意见 相关规范应建 规范 《产品质量管理制度》 《产品质量检验操作规范》 参照 规范 《企业内部控制应用指引》 《中华人民共和国产品质量法》 文件资料 《产品质量操作规范》 《年度质检总结报告》 责任部门及责任人 质量管理部、相关部门 总经理、技术总监、质量管理部经理
常用的软件开发模型 任务的结构框 架。软件开发包括需求、设 段。 软件开发 模型能清晰、直观地表达软 计、编码和测试等阶段，有 时也包括维护阶 件开发全过程，明确规定了 要完成的主要活 动和任务，用来作为软 件项目工作的基础。对于不同的软件 系统，可以采用不同的开 理方法和手段 等，以及允许采用不同的软件工 具和不同的软件工程环境。 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.目的 对于公司生产过程有关的各项因素进行控制，确保各生产过程按规定方法在受控状态下进行，达到产品质量的持续改进，满足客户要求。 2.适用范围 适用于对公司整个生产过程的控制。 3.术语 过程：指使用资源，将输入转化为输出的一个或多个受控的活动。 关键工序：形成产品特殊特性的过程或工序。 作业标准书：描述为完成某一功能所进行工作的作业文件。 工作环境：围绕影响产品制造及质量的过程条件总和，通常指清洁、照明、噪音、保温、通风、安全等。 4.职责 4.1生产部： 4.1.1负责产品制造的归口管理，负责编制产品生产计划； 4.1.2组织人员、物料实施生产计划； 4.1.3确保设备处于完好状态； 4.1.4保持现场清洁。 4.2技术部： 4.2.1负责编制图纸和工艺； 4.2.2负责工程变更的实施与监控； 4.2.3负责按APQP要求编制试产、批量生产的控制计划。 4.3 生物管课： 4.3.1负责按生产计划要求组织物料供给。 4.4 品质课： 4.4.1负责过程检验和试验； 4.4.2编制检验指导书和产品检查基准书； 4.4.3反馈生产过程中产品质量信息；过程监控，绘制控制图。 5.工作流程及内容 序号流程工作说明责任 部门使用表单 5.1 5.1收到客户的订单经合同评审后，编制销售计划并发给相关部门。供销部 5.2 5.2生产部结合库存状况编制生产计划。生产部《生产计划表》 5.3 5.3根据生产计划和材料库存状况，准备生产物料。生物管课 5.4 5.4生产部制造课根据生产计划编制《加工命令流程卡》安排的生产任务。制造课《加工命令流程卡》
5.5.1各车间操作员在作业初次运行、材料更换、加工方法更改时进行作业准备验证，检查确认人、机、料、法、环是否符合作业标准书的要求。 5.5.2 操作者在生产前应对设备进行点检，确认设备是否处于正常状态，班组长负责按作业标准书调整和记录生产设备参数。 5.5.3每个工作班，产品转换后生产的首件产品，应进行首件检查，检查合格后才能进行后续生产。 5.5.4生产过程的所有人员都须经过对口岗位技能、工艺规程培训合格后上岗，其中所有质检员、特殊工序的操作人员必须考试合格后持证上岗。车间《作业准备验证记录表》《首检和巡检记录单》 序号流程工作说明责任 部门使用表单 5.6 5.6.1操作者按照作业标准书的要求进行自检，并作好工艺参数记录。 5.6.2巡检员按照作业标准书的要求进行巡检。 5.6.3生产过程中按《标识和可追溯性程序》对材料、半成品、产成品进行标识。 5.6.4 生产过程中，操作者或班组长发现原材料或半成品出现不合格时，应及时通知品质课，品质课负责组织协调处理。具体按《不合格品控制程序》进行。 5.6.5当生产过程中出现供应中断、劳动力短缺、关键设备故障、动力中断等紧急情况时，生产部按应急计划措施执行。 5.6.6顾客财产按附件1《顾客财产管理办法》控制。 5.6.7生产设备、工装、模具按《设备控制程序》和《工装控制程序》实施。 5.6.8产品防护按《产品防护控制程序》实施。 5.6.9 生产现场按5S要求控制。车间《5S检查表》 《工艺参数记录表》 5.7 5.7.1 用Xbar-R图进行控制，过程能力应达到Cpk≥1.33。 5.7.2公司的过程控制必须保持（或超出）批准PPAP时的过程能力，除非顾客另有要求。过程能力指数应符合：a)对于长期稳定的过程能力，Cpk值应大于1.33；b)对于短期过程能力研究，Ppk值应大于1.67；C)当顾客要求较高或较低的过程能力或性能时，控制计划必须作相应的注释（即在APQP控制计划中“产品/过程规范公差”栏中注出）。
如何对软件质量进行评估 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 软件质量评估指标体系
常用软件开发模型比较分析 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）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这
常见的软件开发模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。 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 软件质量的有关概念 软件质量是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。 1.1 软件质量框架模型 如图1所示，软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。 在这个框架模型中，上层是面向管理的质量特征，每一个质量特征是用以描述和评价软件质量的一组属性，代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定，而且必须从其内部所具有的特征来确定。 第二层的质量子特征是上层质量特征的细化，一个特定的子特征可以对应若干个质量特征。软件质量子特征是管理人员和技术人员关于软件质量问题的通讯渠道。 最下面一层是软件质量度量因子（包括各种参数），用来度量质量特征。定量化的度量因子可以直接测量或统计得到，为最终得到软件质量子特征值和特征值提供依据。 1.2 软件质量特征 按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价： a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。 b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。 c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。 d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。 e.可维护特征：与进行指定的修改所需的努力有关的一组属性。 f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。
第3章软件质量与评价（软件测试标准）作业 （2005年） ●在GB/T17544中，软件包质量要求包括三部分，即产品描述要求、_____(53)____、程序和数据要求。 （53）A．用户文档要求B．系统功能要求C．设计要求说明D．软件配置要求 ●软件内部/外部质量模型中，可移植性不包括_____(54)____子特性。 （54）A．适应性B．共存性C．兼容性D．易替换性 ●《GB/T18905 软件工程产品评价》中确定的通用评价过程包括：___(55)____。 （55）A．确立评价需求、设计评价、执行评价和评估结果 B．确立评价目的、规定评价、设计评价和执行评价 C．确立评价需求、规定评价、设计评价和执行评价 D．确立评价目的、设计评价、执行评价和评估结果 ●GB/T16260－2003将软件质量特性分为内部质量特性、外部质量特性和_____(56)____。（56）A．安全质量特性B．适用质量特性C．性能特性D．使用质量特性 （2006年） ●GB/T16260—2003《软件工程产品质量》规定的软件产品使用质量特性包括___(50)___。 (50)A．适应性、生产率、可靠性、满意度 B．有效性、生产率、安全性、满意度 C．有效性、可靠性、适应性、满意度 D．适应性、适用性、效率、满意度 ●软件可靠性是指在指定的条件下使用时，软件产品维持规定的性能级别的能力，其子特性___(51)___是指在软件发生故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力。 (51)A．成熟性B．易恢复性C．容错性D．可靠性依从性 ●GB/T18905—2002《软件工程产品评价》中确定的通用评价过程包括四个方面，即：确立评价需求，规定评价，设计评价和执行评价，其中有关“规定评价”部分包含的内容有___(52)___。 (52)A．选择度量、建立度量评定等级、确立评估准则： B．指定质量模型、选择度量、建立度量评定等级 C．选择度量、建立度量评定等级、制定评价计划 D．确定产品类型、选择度量、建立度量评定等级 ●GB/T18905-2002《软件工程产品评价》提供了软件产品评价的过程，其中GB/T18905—2002《软件工程产品评价》第五部分评价者用的过程_(53)___。 (53)A．计划获取或复用某个已有的软件产品的组织予以使用 B．对软件产品执行独立评估的评价者使用 C．计划开发新产品或增强现有的产品，以及打算利用他们自己的技术人员进行产品评价的组织使用 D．编制评价模块的文档提供指南 ●关于软件质量的描述，正确的是___(56)___。 (56)A．软件质量是指软件满足规定用户需求的能力 B．软件质量特性是指软件的功能性、可靠性、易用性、效率、可维护性、可移植性C．软件质量保证过程就是软件测试过程 D．以上描述都不对 （2007年）
第3章软件质量与评价（软件测试标准） 1、质量的定义 质量是多维的概念，包括：实体、实体的属性和对实体的观点。 GB/T6583-ISO8404（1994版）《质量管理与质量保证术语》对质量的定义是：反映实体满足明确的隐含的需要的能力的特性的总和。 GB/T18905-ISO14598（1999版）《软件工程产品评价》定义： 2、测度与度量 在软件质量中用于测量的一种量化的标度和方法即为“测度”，而名词的“度量”用来指测量的结果。 影响软件质量可分为：可直接测量、间接度量 3、软件质量模型 ○1、McCall（麦考尔）质量模型 三个重要方面：操作特性（产品运行）、承受可改变能力（产品修订）、新环境适应能力（产品变迁）。 McCall等认为，特性是软件质量的反映，软件属性可用做评价准则，定量化地度量软件属性可知软件质量的优劣。 ②Boehm(勃姆)质量模型 提出了分层结构的质量模型，除了用户的期望和需要的概念，与McCall（麦考尔）质量模型相同外，还包括McCall模型中没有的硬件特性。 Boehm(勃姆)质量模型反映了对软件质量的理解，即软件做了用户要它做的；有效地使用系统资源；易于用户学习和使用；易于软件测试与维护。 ③ISO9126质量模型 GB/T16260-1996：六个影响质量的特性：功能性、可靠性、易使用性、效率、可维护性、可移植性;各个子特性（及其定义）要求要背 GB/T16260-1996出发点是软件最大限度地满足用户的明确的和潜在的需求。 国标16260中，在描述外部（内部）效率度量时，给出了若干针对计算机系统时间消耗的定义如下： 响应时间是指从按动传送键到得到结果为止所需要的时间或响应时间包括处理时间和传输时间 处理时间是指从接受一个消息到送出它的结果之间计算机的历时时间 ③ 周转时间是指从提出要求到得到结果所需要的时间 4、标准的发展 GB/T 16260-1996（ISO9126-1991）《软件产品评价-质量特性及其使用指南》已被两个相关的由多部分组成的标准：GB/T 18905-2002《软件工程产品评价》和GB/T 16260-2003（ISO9126-2001）《软件工程产品质量》所取代。 5、GB/T 18905产品评价 （一、GB/T 18905基本组成（6个部分组成） GB/T 软件工程产品评价第1部分: 概述 GB/T 软件工程产品评价第2部分: 策划和管理 GB/T 软件工程产品评价第3部分: 开发者用的过程
常见软件开发模型 模型优点缺点 瀑布模型文档驱动系统可能不满足客户的需求 快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于 维护 增量模型开发早期反馈及时，易于维护需要开放式体系结构，可能会设计差、 效率低 螺旋模型风险驱动风险分析人员需要有经验且经过充分 训练 瀑布模型(Waterfall Model ) 1970年Winston Royce 提岀了著名的“瀑布模型“，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型中，如图所示，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、
软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如 同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，开发的风 从而增加了险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 快速原型模型（Rapid Prototype Model ） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么； 第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速 原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真 正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速 建立原型，随之迅速修改原型，以反映客户的需求。
一、选择题 1.软件是一种（）产品。 A．有形 B.逻辑C．物质 D.消耗 2.与计算机科学的理论研究不同，软件工程是一门（） A．理论性B．工程性C．原理性D．心理性 3.软件工程学科出现的主要原因是（） A．计算机的发展B．其他工程学科的影响力 C．软件危机的出现D．程序设计方法学的影响 4.软件生存周期模型有多种，下列选项中，（）不是软件生存周期的模型。 A．螺旋模型B．增量模型C．功能模型D．瀑布模型 5.软件开发模型是指软件开发的全部过程、活动和任务的结构框架。主要的开发模型有瀑布模型、 演化模型、螺旋模型和喷泉模型。螺旋模型将瀑布模型和演化模型相结合，并增加了[A ]，它建立在[B ]的基础上，沿着螺线自内向外每旋转一圈，就得到[B ]的一个版本。喷泉模型描述了[C ]的开发模型，它体现了这种开发方法创建软件的过程所固有的[D ]和 [E ]的特征。 供选择的答案： A：（1）系统工程（2）风险分析（3）设计评审（4）进度控制 B：（1）模块划分（2）子程序分解（3）设计（4）原型 C：（1）面向对象（2）面向数据流（3）面向数据结构（4）面向事件驱动 D：（1）归纳（2）推理（3）迭代（4）递归 E：（1）开发各阶段之间无“间隙”（2）开发各阶段分界明显（3）部分开发阶段分界明显（4）开发过程不分阶段 您的选择是: 【A 】【B 】【C 】【D 】【E 】 6.目前存在若干种软件生存周期模型，例如瀑布模型、增量模型、螺旋模型等。其中规定了由前至 后、相互衔接的固定次序的模型是（） A．瀑布模型B．增量模型C．螺旋模型D．喷泉模型 7.软件生命周期包括可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、（）维 护等活动。 A．应用B．测试C．检测D．以上都是 8.准确地解决“软件系统必须做什么”是（）阶段的任务。 A．分析阶段B．设计阶段C．编码阶段D．测试阶段 9.研究开发所需要的成本和资源是属于可行性研究中的（）研究的一方面。 A.技术可行性 B. 经济可行性 C. 社会可行性 D. 法律可行性 10.需求分析（）。【】 A．要回答“软件必须做什么”B．可概括为“理解、分析、表达”六个字 C．要求编写需求规格说明书D．以上都对 11.瀑布模型中软件生命周期划分为八个阶段：问题定义、可行性研究、需求分析、总体设计、详细 设计、编码、测试和运行、维护。这八个阶段又可归纳为三个大的阶段：计划阶段、开发阶段和（）阶段。