常见的软件质量模型
常见的软件质量模型
关于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模型有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 模型之上的，同时加入了功能性要求，还包括识别软件产品的内部和外部质量属性。
几种比较常见的测试模型汇总： 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 模型的全面扩展。
常用的软件开发模型 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。 1. 瀑布模型-最早出现的软件开发模型 1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的软件过程如图所示）
数学建模常用软件有哪些哈 MatlabMathematicalingoSAS详细介绍：数学建模软件介绍一般来说学习数学建模，常用的软件有四种，分别是：matlab、lingo、Mathematica和SAS下面简单介绍一下这四种。 1.MA TLAB的概况MA TLAB是矩阵实验室（Matrix Laboratory）之意。除具备卓越的数值计算能力外，它还提供了专业水平的符号计算，文字处理，可视化建模仿真和实时控制等功能。MATLAB的基本数据单位是矩阵，它的指令表达式与数学,工程中常用的形式十分相似,故用MATLAB来解算问题要比用C,FORTRAN等语言完相同的事情简捷得多. 当前流行的MA TLAB 5.3/Simulink 3.0包括拥有数百个内部函数的主包和三十几种工具包(Toolbox).工具包又可以分为功能性工具包和学科工具包.功能工具包用来扩充MATLAB的符号计算,可视化建模仿真,文字处理及实时控制等功能.学科工具包是专业性比较强的工具包,控制工具包,信号处理工具包,通信工具包等都属于此类. 开放性使MATLAB广受用户欢迎.除内部函数外,所有MA TLAB主包文件和各种工具包都是可读可修改的文件,用户通过对源程序的修改或加入自己编写程序构造新的专用工具包. 2.Mathematica的概况Wolfram Research 是高科技计算机运算( Technical computing )的先趋，由复杂理论的发明者Stephen Wolfram 成立于1987年，在1988年推出高科技计算机运算软件Mathematica，是一个足以媲美诺贝尔奖的天才产品。Mathematica 是一套整合数字以及符号运算的数学工具软件，提供了全球超过百万的研究人员，工程师，物理学家，分析师以及其它技术专业人员容易使用的顶级科学运算环境。目前已在学术界、电机、机械、化学、土木、信息工程、财务金融、医学、物理、统计、教育出版、OEM 等领域广泛使用。Mathematica 的特色·具有高阶的演算方法和丰富的数学函数库和庞大的数学知识库，让Mathematica 5 在线性代数方面的数值运算，例如特征向量、反矩阵等，皆比Matlab R13做得更快更好，提供业界最精确的数值运算结果。·Mathematica不但可以做数值计算，还提供最优秀的可设计的符号运算。·丰富的数学函数库，可以快速的解答微积分、线性代数、微分方程、复变函数、数值分析、机率统计等等问题。·Mathematica可以绘制各专业领域专业函数图形，提供丰富的图形表示方法，结果呈现可视化。·Mathematica可编排专业的科学论文期刊，让运算与排版在同一环境下完成，提供高品质可编辑的排版公式与表格，屏幕与打印的自动最佳化排版，组织由初始概念到最后报告的计划，并且对txt、html、pdf 等格式的输出提供了最好的兼容性。·可与C、C++ 、Fortran、Perl、Visual Basic、以及Java 结合，提供强大高级语言接口功能，使得程序开发更方便。·Mathematica本身就是一个方便学习的程序语言。Mathematica提供互动且丰富的帮助功能，让使用者现学现卖。强大的功能，简单的操作，非常容易学习特点，可以最有效的缩短研发时间。 3.lingo的概况LINGO则用于求解非线性规划（NLP—NON—LINEAR PROGRAMMING）和二次规则（QP—QUARATIC PROGRAMING）其中LINGO 6.0学生版最多可版最多达300个变量和150个约束的规则问题，其标准版的求解能力亦再10^4量级以上。虽然LINDO和LINGO不能直接求解目标规划问题,但用序贯式算法可分解成一个个LINDO和LINGO能解决的规划问题。模型建立语言和求解引擎的整合LINGO是使建立和求解线性、非线性和整数最佳化模型更快更简单更有效率的综合工具。LINGO提供强大的语言和快速的求解引擎来阐述和求解最佳化模型。■简单的模型表示LINGO可以将线性、非线性和整数问题迅速得予以公式表示，并且容易阅读、了解和修改。■方便的数据输入和输出选择LINGO建立的模型可以直接从数据库或工作表获取资料。同样地，LINGO可以将求解结果直接输出到数据库或工作表。■强大的求解引擎LINGO内建的求解引擎有线性、非线性(convex and nonconvex)、二次、二次
软件工程概述 一单项选择 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．软件特性中，根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对软件需求进行逆向
软件工程——软件开发过程中用到的各种图 一、宏观导图 导图说明：我们的软件开发中用到的各种图型工具都是为了辅助我们更好的理解开发的阶段或者过程。上图是根据软件过程中各个阶段所需要用到的各种图的一个小结。下面是各种图的简介和示例。 二、谈细节： 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图：和层次方框图一个意思，不过她能描述的手段比层次图更加丰富。
常见的软件质量模型 关于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模型有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 个质量标准。
2006-2007-2软件工程复习 一、单项选择题（20选10） 1. 结构化分析的主要描述手段有( B )。 A. 系统流程图和模块图 B. ＤＦＤ图、数据词典、加工说明 C. 软件结构图、加工说明 D. 功能结构图、加工说明 2. 用于表示模块间的调用关系的图叫（ D ）。 A．PAD B．SC C．N-S D．HIPO 3. 在（ B ）模型中是采用用例驱动和架构优先的策略，使用迭代增量建造方法，软件“逐渐”被开发出来的。 A．快速原型 B. 统一过程 C．瀑布模型 D. 螺旋模型 4. 常用的软件开发方法有面向对象方法、面向( A )方法和面向数据方法。 A. 过程 B. 内容 C. 用户 D. 流程 5 从工程管理的角度来看，软件设计分两步完成( D )。 A. ①系统分析②模块设计 B. ①详细设计②概要设计 C. ①模块设计②详细设计 D. ①概要设计②详细设计 6. 程序的三种基本结构是（ B ）。 A. 过程、子程序、分程序 B．顺序、条件、循环 C．递归、堆栈、队列 D．调用、返回、转移 7. 程序的三种基本结构是（ B ）。 A. 过程、子程序、分程序 B．顺序、条件、循环 C．递归、堆栈、队列 D．调用、返回、转移 8. SD方法衡量模块结构质量的目标是（ C ）。 A. 模块间联系紧密，模块内联系紧密 B. 模块间联系紧密，模块内联系松散 C. 模块间联系松散，模块内联系紧密 D. 模块间联系松散，模块内联系松散 9．为提高软件测试的效率，应该（ C ）。 A．随机地选取测试数据 B．取一切可能的输入数据作为测试数据 C．在完成编码后制定软件测试计划 D．选择发现错误可能性大的数据作为测试数据 10．( D )测试用例发现错误的能力较大。 A.路径覆盖 B.条件覆盖 C.判断覆盖 D.条件组合覆盖 11．软件需求分析应确定的是用户对软件的( A )。 A. 功能需求和非功能需求 B. 性能需求 C. 非功能需求 D. 功能需求 12．下列各种图可用于动态建模的有（ C ）。 A．用例图 B. 类图 C. 序列图 D. 包图 13．软件过程模型有瀑布模型、( B )、增量模型等。 A. 概念模型 B. 原型模型 C. 逻辑模型 D. 物理模型 14．面向对象的分析方法主要是建立三类模型，即( D )。 A. 系统模型、ER模型、应用模型 B. 对象模型、动态模型、应用模型 C. Ｅ-Ｒ模型、对象模型、功能模型 D. 对象模型、动态模型、功能模型 15．测试的分析方法是通过分析程序（ B ）来设计测试用例的方法。 A．应用范围 B.内部逻辑 C.功能 D.输入数据 16. 软件工程是研究软件( B )的一门工程学科。 A. 数学 B. 开发与管理 C. 运筹学 D. 工具 17. 需求分析可以使用许多工具，但（ C ）是不适合使用的。 A．数据流图 B.判定表 C.PAD图 D.数据字典 18．划分模块时，一个模块内聚性最好的是( A )。 A. 功能内聚 B. 过程内聚 C. 信息内聚 D. 逻辑内聚 19．软件可移植性是用来衡量软件的（ D ）的重要尺度之一。 A．效率 B. 质量 C. 人机关系 D. 通用性 20．软件配置管理是在软件的整个生存周期内管理（ D ）的一组活动。 A．程序 B.文档 C.变更 D.数据 二、判定题（20选10） 1统一过程是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。（×） 2当模块中所有成分结合起来完成一项任务，该模块的内聚是偶然内聚。（×） 3SD方法衡量模块结构质量的目标是模块间联系松散，模块内联系紧密（√） 4当模块中所有成分结合起来完成一项任务，该模块的内聚是功能内聚。（√） 5在进行需求分析时，就应该同时考虑软件的可维护性问题。（√） 6需求分析可以使用许多工具，但数据流图是不适合使用的。（×）
常用的软件开发模型 任务的结构框 架。软件开发包括需求、设 段。 软件开发 模型能清晰、直观地表达软 计、编码和测试等阶段，有 时也包括维护阶 件开发全过程，明确规定了 要完成的主要活 动和任务，用来作为软 件项目工作的基础。对于不同的软件 系统，可以采用不同的开 理方法和手段 等，以及允许采用不同的软件工 具和不同的软件工程环境。 1. 瀑布模型 -最早出现的软件开发模型 1970 年温斯顿 ?罗伊斯( Winston Royce )提出了著名的 “瀑布模型 ”，直到 80 年 代早期，它一 直是唯一被广泛采用的软件开发 模型。 瀑布模型 核心思想是按工序将问题化简 ，将功能的实现与设计分开 ，便于分工协 作，即采 用结构化的分析与设计方法将逻 辑实现与物理实现分开。将 软件生命周期划 分为制定计划 、需求分析、软件设计、程序编写、软件测试和运行维 护等六个基本活 动，并 且规定了它们自上而下 、相互衔接的固定次序 ，如同瀑布流水，逐级 下落。从 本质来讲，它是一个软 件开发架构，开发过程是通过一系列 阶段顺序展开的，从系统 需求分析开始 直到产品发布和维护，每个阶段都会产 生循环反馈，因此，如果有信息 未被覆盖或者 发现了问题， 那么 最好 “返回 ”上一个 阶段并进行适当的修改 ，开发进程 从一个阶段 “流动 ”到下一个阶段， 这也是瀑布开发名称的由来。 瀑布模型是最 早出现的软件开发模型，在软件工程中占有重要的地位 ，它提供了 软件开发的基 本框架。其过程是从上一项 活动接收该项活动的工作对象作 为输入，利 用这一输入实 施该项活动应完成的内容给出该 项活动的工作成果， 并 作为输出传给下 一项活动。同 时评审该项活动的实施，若确认 ，则继续下一项活动；否则返 回前面， 甚至更前面的 活动。对于经常变化的项目而 言，瀑布模型毫无价值。(采用瀑布模型 的软件过程如 图所示) 软件 开发模型 (Software Development 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） 又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各
常见软件质量模型的对比 J. A. McCall等人将质量模型分为三层:因素、衡量准则、度量,并对软件质量因素进行了研究,认为软件质量是正确性、可靠性、效率等构成的函数,而正确性、可靠性、效率等被称为软件质量因素,或软件质量特征,它表现了系统可见的行为化特征。每一因素又由一些准则来衡量,而准则是跟软件产品和设计相关的质量特征的属性。例如,正确性由可跟踪性、完全性、相容性来判断;每一准则又有一些定量化指标来计量,指标是捕获质量准则属性的度量。McCall认为软件质量可从两个层次去分析,其上层是外部观察的特性,下层是软件内在的特性。McCall定义了11个软件外部质量特性,称为软件的质量要素,它们是正确性、可靠性、效率、完整性、可使用性、可维护性、可测试性、灵活性、可移植性、重复使用性和连接性。同时,还定义了23个软件的内部质量特征,称之为软件的质量属性,它们是完备性、一致性、准确性、容错性、简单性、模块性、通用性、可扩充性、工具性、自描述性、执行效率、存储效率、存取控制、存取审查、可操作性、培训性、通信性、软件系统独立性、机独立性、通信通用性、数据通用性和简明性,软件的内部质量属性通过外部的质量要素反映出来。然而,实践证明以这种方式获得的结果会有一些问题。例如,本质上并不相同的一些问题有可能会被当成同样的问题来对待,导致通过模型获得的反馈也基本相同。这就使得指标的制定及其定量的结果变得难以评价。 Boehm模型是由Boehm等在1978年提出来的质量模型,在表达质量特征的层次性上它与McCall模型是非常类似的。不过,它是基于更为广泛的一系列质量特征,它将这些特征最终合并成19个标准。Boehm提出的概念的成功之处在于它包含了硬件性能的特征,这在McCall模型中是没有的。但是,其中与McCall模型类似的问题依然存在。 ISO9126质量模型主要从三个层次来分析即内部质量，外部质量和使用质量，这三者之间都是互相影响互相依赖。其中内在质量和外在质量的六个特征,它们还可以再继续分成更多的子特征。这些
常用软件开发模型比较分析 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）客户始终参与每个阶段的开发,保证了项目不偏离正确方向及项目的可控性。 4）随着项目推进，客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。 5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
常见软件开发模型 模型优点缺点 瀑布模型文档驱动系统可能不满足客户的需求 快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于 维护 增量模型开发早期反馈及时，易于维护需要开放式体系结构，可能会设计差、 效率低 螺旋模型风险驱动风险分析人员需要有经验且经过充分 训练 瀑布模型(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.瀑布模型中软件生命周期划分为八个阶段：问题定义、可行性研究、需求分析、总体设计、详细 设计、编码、测试和运行、维护。这八个阶段又可归纳为三个大的阶段：计划阶段、开发阶段和（）阶段。
常用软件开发模型比较分析 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ①以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ②在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③以形式化开发方法为基础的变换模型（Transformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。 图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，
1.2 常用软件开发模型比较分析 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（S piral Model）。 ③ 以形式化开发方法为基础的变换模型（Transformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
空间维： 把MIS的实体（系统）划分为若干个子系统。按垂直方向如分解为战略决策与计划，管理控制和执行处理三个层次；再按水平方向分解，如划分为：生产管理，材料管理，财会管理等子系统。 常用方法： 把系统按空间维分成若干个子系统，分期开发子系统，子系统的开发再遵循时间维的分解，按开发工程分步骤开发。 1.2.2 螺旋模型 螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如图1-4所示。 图1-4 采用螺旋模型的软件过程 螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，
第一章软件工程介绍 软件工程的概念 IEEE对软件工程的定义: （1）将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。 （2）在（1）中所述方法的研究。 过程、方法和工具 过程：为了获取高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 方法：各项任务的技术方法，回答“怎么做”的问题。 工具：为运用方法而提供的自动或半自动的软件工程支撑环境 软件工程层次图 软件危机与软件工程的关系、产生的原因及其表现 软件工程的提出： 软件工程主要是针对20世纪60年代的软件危机而提出的 软件危机定义：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 产生软件危机的原因： 客观原因： 软件缺乏“可见性”，管理和控制其开发过程相对困难 软件大多规模庞大，而复杂性随规模以指数速度上升 主观原因： 错误的认识和做法 忽视软件需求分析的重要性—急于求成，仓促上阵 认为软件开发就是写程序—编程只占全部工作量的10%--20%，软件配置主要包括程序、文档和数据 轻视软件维护—维护费用占总费用的55%--70%
软件神话一些错误认识 管理神话： 我们已经有了一本写满软件开发标准和规程的宝典。它无所不包，囊括了我们可能问到的所有问题 如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度 如果将一个软件外包给另一家公司，则我们可以完全放手不管。 用户神话： 有了对项目目标的大概了解，便足以开始编写程序，我们可以在之后的项目开发过程中逐步了解细节。 虽然项目需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变化从业者神话： 当我们完成程序并将其交付使用之后，我们的任务就完成了。 直到程序开始运行，才能评估其质量 对于一个成功的软件项目，可执行程序是惟一可交付的成果。 软件工程将导致我们产生大量无用文档，并因此降低工作效率。 第二章过程模型 掌握五个最基本的框架活动： 将整个软件过程再进一步细分为各个相对独立的功能块，即过程框架。（以工作开展的时间为线索）。 五个最基本的框架活动： 沟通：与客户之间的交流与写作 策划：为后续的软件工程工作制定计划 建模：包括分析和设计 构建：编码和测试 部署：软件交付用户，用户对其进行评估并反馈意见。 了解典型的普适性活动 适用于任何一个框架活动： 软件项目跟踪和控制；风险管理；软件质量保证；正式技术评审；测量；软件配置管理；可复用管理；工作产品的准备和生产