软件工程概述易错知识点汇总

软件工程概述易错知识点汇总

• 可靠性、可用性和可维护性是软件的质量属性，软件工程中，用0-1之间的数来度量。 可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运作的概率。可以用MTTF/（1+MTTF）来度量，其中MTTF为平均无故障时间。 可用性是在给定的时间点上，一个系统能够按照规格说明正确运作的概率。可以用MTBF/（1+MTBF）来度量，其中MTBF为平均失效间隔时间。 可维护性是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。可以用1/（1+MTTR）来度量，其中MTTR为平均修复时间。

• 敏捷开发方法XP是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法，其特性包含在12个最佳实践中。 1.计划游戏：快速制定计划、随着细节的不断变化而完善； 2.小型发布：系统的设计要能够尽可能早地交付； 3.隐喻：找到合适的比喻传达信息； 4.简单设计：只处理当前的需求使设计保持简单； 5.测试先行：先写测试代码再编写程序； 6.重构：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求; 7.结队编程； 8.集体代码所有制； 9.持续集成：可以按日甚至按小时为客户提供可运行的版本； 10.每周工作40个小时； 11.现场客户； 12.编码标准。

• 敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。敏捷过程的典型方法很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念，即敏捷宣言。其中，极限编程XP是一种轻量级的软件开发方式，由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。水晶法Crystal认为每一个不同的项目都需要一套不同的策略、约定和方法论。并列争球法Scrum使用迭代的方法，并按需求的优先级来实现产品。自适应软件开发 ASD有6个基本原则。

• 敏捷开发方法是一个强调灵活性和快速开发的一种开发方法，有多种具体的方法，其中极限编程是敏捷方法中最普遍的—种方法。极限编程包含12个实践操作。其中，集体所有权表示任何开发人员可以对系统任何部分进行改变，结对编程实际上存在一个非正式的代码审查过程，可以获得更高的代码质量。据统计，结对编程的编码速度与传统的单人编程相当。

• 极限编程是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。

  • 4大价值观： 沟通、简单性、反馈和勇气。
  • 5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
  • 12个最佳实践：计划游戏（快速制定计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40个小时、现场客户和编码标准。

• CMM（Capability Maturity Model）是能力成熟度模型的缩写，CMM是国际公认的对软件公司进行成熟度等级认证的重要标准。CMM共分五级。在每一级中，定义了达到该级过程管理水平所应解决的关键问题和关键过程。每一较低级别是达到较高级别的基础。其中五级是最高级，即优化级，达到该级的软件公司过程可自发地不断改进，防止同类问题二次出现；四级称为已管理级，达到该级的软件公司已实现过程的定量化；三级为已定义级，即过程实现标准化；二级为可重复级，达到该级的软件公司过程已制度化，有纪律，可重复；一级为初始级，过程无序，进度、预算、功能和质量等方面不可预测。

• CMM 的分级结构及其过程描述：

  （1）初始级：软件过程的特点是无秩序或说无定规的，有时甚至是混乱的。软件过程定义几乎处于无章法、无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。

  （2）可重复级：已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。

  （3）已定义级：用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。

  （4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。

  （5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地对促进过程进行改进。 除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，自然可以向上一更为成熟的高一级别迈进。CMM 体系不主张跨级别的进化，因为从第二级开始，每一个低级别的实现均是更高级别实现的基础。

• 软件成熟度模型CMM是对软件组织进化阶段的描述，该模型在解决软件过程存在问题方面取得了很大的成功，因此在软件界产生了巨大影响，促使软件界重视并认真对待过程改进工作。过程能力成熟度模型基于这样的理念：改进过程将改进产品，尤其是软件产品。软件组织为提高自身的过程能力，把不够成熟的过程提升到较成熟的过程涉及4个方面，这4个方面构成了软件过程改进的框架，即过程改进基础设施、过程改进线路图、软件过程评估方法和软件过程改进计划。在进行评估后需要把发现的问题转化为软件过程改进计划。而过程改进通常不可能是一次性的，需要反复进行。每一次改进要经历4个步骤：评估、计划、改进和监控。

• 能力成熟度模型集成（CMMI）是若干过程模型的综合和改进。

  • CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标。
  • CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
  • CL2（已管理的）：其共性目标是集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制、和评审。
  • CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程中裁剪得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。
  • CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的质量目标作为管理准则。
  • CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户的改变和持续改进计划中的过程域的功效。

• COCOMO用3个不同层次的模型来反映不同程度的复杂性，它们分别为：基本模型（Basic Model）：是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的函数来计算软件开发工作量。中级模型（Intermediate Model）：则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细模型（Detailed Model）：包括中级COCOMO型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。

• COCOMOII模型也需要使用规模估算信息，在模型层次结构中有3种不同规模估算选择，即：对象点、功能点和代码行。

• UP （统一过程）模型是一种以用例和风险为驱动、以架构为中心、迭代并且增量的开发过程，由UML方法和工具支持。UP过程定义了五个阶段，起始阶段、精化阶段、构建阶段、移交阶段和产生阶段。起始阶段专注于项目的初创活动。精化阶段理解了最初的领域范围之后，进行需求分析和架构演进。构建阶段关注系统的构建，产生实现模型。移交阶段关注于软件提交方面的工作，产生软件增量。产生阶段运行软件并监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请求。开发过程中有多次迭代，每次迭代都包含计划、分析、 设计、构造、集成和测试，以及内部和外部发布。每个迭代有五个核心工作流，捕获系统应该做什么的需求工作流、精化和结构化需求的分析工作流、在系统结构内实现需求的设计工作流、构造软件的实现工作流和验证是否如期望那样工作的测试工作流。

• RUP在每个阶段都有目标，并在结束时产生一些制品：

  • 初启阶段结束时产生一个构想文档、一个有关用例模型的调查、一个初始的业务用例、一个早期的风险评估和一个可以显示阶段和迭代的项目计划等制品；
  • 精化阶段结束时产生一个补充需求分析、一个软件架构描述和一个可执行的架构原型等制品；
  • 构建阶段结束时的成果是一个准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述；
  • 移交阶段结束时产生移交给用户产品发布版本。
  • 统一过程（UP）定义了初启阶段、精化阶段、构建阶段、移交阶段和产生阶段，每阶段达到某个里程碑时结束。其中初启阶段的里程碑是生命周期目标，精化阶段的里程碑是生命周期架构，构建阶段的里程碑是初始运作功能，移交阶段的里程碑是产品发布。

• 软件项目计划的一个重要内容是安排进度，常用的方法有Gantt图和PERT图。Gantt 图用水平条状图描述，它以日历为基准描述项目任务，可以清楚地表示任务的持续时间和任务之间的并行，但是不能清晰地描述各个任务之间的依赖关系。PERT图是一种网络模型，描述一个项目的各任务之间的关系。可以明确表达任务之间的依赖关系，即哪些任务完成后才能开始另一些任务，以及如期完成整个工程的关键路径，但是不能清晰地描述各个任务之间的并行关系。

• Gantt图是一种简单的水平条形图，以日历为基准描述项目任务。水平轴表示日历时间线，如日、周和月等，每个条形表示一个任务，任务名称垂直的列在左边的列中，图中水平条的起点和终点对应水平轴上的时间，分别表示该任务的开始时间和结束时间，水平条的长度表示完成该任务所持续的时间。当日历中同一时段存在多个水平条时，表示任务之间的并发。 Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。

• 软件设计的任务是基于需求分析的结果建立各种设计模型，给出问题的解决方案。从工程管理的角度，可以将软件设计分为两个阶段：概要设计阶段和详细设计阶段。结构化设计方法中，概要设计阶段进行软件体系结构的设计、数据设计和接口设计；详细设计阶段进行数据结构和算法的设计。面向对象设计方法中，概要设计阶段进行体系结构设计、初步的类设计/数据设计、结构设计；详细设计阶段进行构件设计。 结构化设计和面向对象设计是两种不同的设计方法，结构化设计根据系统的数据流图进行设计，模块体现为函数、过程及子程序；面向对象设计基于面向对象的基本概念进行，模块体现为类、对象和构件等。

• 极限编程XP是激发开发人员创造性、使得管理负担最小的一组技术；水晶法Crystal认为每一个不同的项目都需要一套不同的策略、约定和方法论；并列争球法（Scrum）使用迭代的方法，其中把每30天一次的迭代成为一个冲刺，并按需求的优先级来实现产品。多个自组织和自治小组并行地递增实现产品，并通过简短的日常情况会议进行协调。

• 基于构件的软件开发，主要强调在构建软件系统时复用已有的软件“构件”，在检索到可以使用的构件后，需要针对新系统的需求对构件进行合格性检验、适应性修改，然后集成到新系统中。

• 项目经理需要尽早预测项目中的风险，这样就可以制订有效的风险管理计划以减少风险的影响，所以，早期的风险识别是非常重要的，一般来说，影响软件项目的风险主要有三种类别：项目风险涉及到各种形式的预算、进度、人员、资源以及和客户相关的问题；技术风险涉及到潜在的设计、实现、对接、测试即维护问题；业务风险组括建立一个无人想要的优秀产品的风险、失去预算或人员承诺的风险等：商业风险包括如市场风险、策略风险、管理风险和预算风险等。

• I/O软件隐藏了I/O操作实现的细节。I/O软件向用户提供的是逻辑接口。I/O软件将硬件与较高层次的软件隔离开来，而最高层软件向应用提供一个友好的、清晰且统一的接口，方便用户使用。

• 测试过程基本上与开发过程平行进行，在需求分析阶段，就需要对验收测试、系统测试设计相关测试，撰写相关测试设计文档。

• 软件复杂性度量是软件度量的一个重要分支。对于软件复杂性度量的主要参数有：

  • 规模，即总共的指令数，或源程序行数(即代码行数)。

  • 难度，通常由程序中出现的操作数的数目所决定的量来表示。

  • 结构，通常用与程序结构有关的度量来表示。

  • 智能度，即算法的难易程度。

    软件复杂性主要表现在程序的复杂性。程序的复杂性主要指模块内程序的复杂性。McCabe度量法是一种基于程序控制流的复杂性度量方法。McCabe复杂性度量又称为环路度量，它认为程序的复杂性很大程度上取决于控制的复杂性。单一的顺序程序结构最为简单，循环和选择所构成的环路越多，程序就越复杂。这种方法以图论为工具，先画出程序图，然后用该图的环路数作为程序复杂性的度量值。程序图是退化的程序流程图，也就是说，把程序流程图中每个处理符号都退化成一个结点，原来连接不同处理符号的流线变成连接不同点的有向弧，这样得到的有向图就叫做程序图。程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作以及分支和循环的具体条件。

    根据图论，在一个强连通的有向图G中，环的个数V（G）由以下公式给出： V（G） = m - n + 2p 其中，V（G）是有向图G中的环路数，m是图G中弧的个数，n是图G中的结点数， P是G中的强连通分量个数。在一个程序中，从程序图的入口点总能到达图中的任何一个结点，因此，程序总是连通的，但不是强连通的。为了使程序图成为强连通图，从图的入口点到出口点加一条用虚线表示的有向边，使图成为强连通图，这样就可以使用上式计算环路复杂性了。

• ISO/IEC 9126软件质量模型中可靠性质量特性是指在规定的一段时间内和规定的条件下，软件维护其性能水平有关的能力。包括的子特性有成熟性、容错性和易恢复性。其中易恢复性是与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及与为达到此目的所需的时间和工作有关的软件属性。软件故障发生后，要在90秒内恢复其性能和受影响的数据，达到这一目的有关的属性即为易恢复性子特性。

• 模块结构评审时，主要包括以下方面的评审：1.控制流结构：规定了处理模块与处理模块之间的流程关系。检查处理模块之间的控制转移关系与控制转移形式（调用方式）。2.数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。检查处理模块与数据模块之间的对应关系；处理模块与数据模块之间的存取关系，如建立、删除、查询、修改等。3.模块结构与功能结构之间的对应关系：包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系；每个模块的定义（包括功能、输入与输出数据）。

• 容错技术是对某些无法避开的差错，使其影响减至最小的技术。通常冗余技术分为四类，结构冗余、信息冗余、时间冗余和冗余附加技术。其中冗余附加技术是指为实现其他类型冗余技术所需要的资源和技术，包括程序指令、数据、存放和调动它们的空间和通道等。在屏蔽硬件错误的容错技术中，冗余附加技术包括：关键程序和数据的冗余存储及调用：检测、表决、切换、重构、纠错和复算的实现。在屏蔽软件错误的容错技术中，冗余附加技术包括：冗余备份程序的存储及调用；实现错误检测和错误恢复的程序；实现容错软件所需的固化程序。

• 软件配置管理SCM用于整个软件工程过程，其主要目标是标识变更、控制变更、确保变更正确的实现，报告变更。其主要内容包括版本管理、配置支持、变更支持、过程支持、团队支持、变化报告和审计支持等。

• 三层C/S体系结构由逻辑上相互分离的表示层、业务层和数据层构成。其中表示层向客户提供数据，业务层实施业务相数据规则，数据层定义数据访问标准。该体系结构具有许多优点，如逻辑上相对独立，不同层可以用不同的平台、软件和开发语言，而系统的安装、修改和维护在各层都可能进行。

• 为了使用户满意，软件应该满足两个必要条件：设计的规格说明书符合用户的要求，这称为设计质量；程序按照设计规格说明所规定的情况正确执行，这称为程序质量。 设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明、在软件概要设计阶段产生的软件概要设计说明书等。主要从以下方面进行评审：软件的规格说明是否合乎用户的要求；可靠性；保密措施实现情况等；操作特性实施情况等；性能实现情况；可修改性、可扩充性、可互换性和可移植性；可测试性；可复用性。

• 系统开发人员与项目管理人员在项目期内进行沟通的文档主要有系统开发计划、系统开发月报以及系统开发总结报告等项目管理文件。

• 用于系统开发人员与项目管理人员在项目期内进行沟通的文档主要有系统开发计划，包括工作任务分解表、PERT图、甘特图和预算分配表等。总体规划和开发合同用于与系统分析人员在系统规划和系统分析阶段的沟通。测试计划用于系统测试人员与系统开发人员之间的沟通。

• 文档是指某种数据媒体和其中所记录的数据。在软件开发过程中，有大量的信息要记录和使用，因此文档具有重要的作用，如可以提高软件开发过程的能见度、提髙开发效率、作为开发人员在一定阶段的工作成果和结束标志、记录开发过程中的有关信息、提高对软件运行维护和培训的有关信息、便于用户了解软件功能和性能等各项指标。 髙质量的文档应该体现在几个方面：针对性，文档编制应考虑读者。按不同的类型、不同层次的读者，决定怎样适应他们的需要；精确性，文档的行文应该十分确切，不能出现多义性的描述。同一项目几个文档的内容应该是协调一致，没有矛盾的；清晰性， 文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性；完整性，任何文 档都应当是完整的、独立的，应该自成体系；灵活性，各个不同软件项目，其规模和复 杂程度有着许多实际差别，不能一律看待；可追溯性，由于各开发阶段编制的文档与各个阶段完成的工作有密切的关系，前后两个阶段生成的文档，随着开发工作的逐步延伸， 具有一定的继承关系，在一个项目各开发阶段之间提供的文档必定存在着可追溯的关系。

• 文档是系统建设过程的“痕迹”，是系统维护人员的指南，是开发人员与用户交流的工具。文档不仅仅描述和规定软件的适用范围及相关的操作命令。软件包括程序和文档，因此没有文档的软件不能称之为软件产品。软件文档的编制在软件开发中是相当重要的，高质量的文档对于发挥软件产品的效益有着重要的意义。

• 软件由程序、数据和相关文档构成，因此文档是软件不可或缺的重要组成部分。软件开发各个阶段都需要撰写相关文档，如开发计划、需求分析文档、设计文档等，这些文档是开发人员之间以及和其他人员之间进行沟通的重要依据，高质量的文档对于提高软件开发质量具有重要的意义。尽管在开发过程中编写文档需要占用开发时间，但是相对于没有文档而言，编写文档使得开发人员对各个阶段的工作都进行周密思考，全盘权衡，从而减少返工。并且可以在开发早期发现错误和不一致性，便于及时加以纠正，因此可以提高软件开发效率。

• 一般来讲，概要设计的内容可以包含系统构架、模块划分、系统接口、数据设计4个主要方面的内容，不包括模块内算法设计。

• 可维护性是所有软件都应具有的基本特点，必须在开发阶段保证软件具有可维护的特点，在系统分析阶段的复审过程中，应该指出软件的可移植性问题以及可能影响软件维护的系统界面；在系统设计阶段的复审期间，应该从容易修改、模块化和功能独立的目的出发，评价软件的结构和过程；在系统实施阶段的复审期间，代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。可测试性是可维护性的一个评价指标。

• 在对软件系统进行评价时，需要从信息系统的组成部分、评价对象和经济学角度出发进行综合考虑，以建立起一套指标体系理论架构。 从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需求（人）、系统质量和技术条件（机）这两条线索构造指标。 从信息系统评价对象出发，对于用户方来说，他们所关心的是用户需求和运行质量； 对开发方而言，他们所关心的是系统质量和技术水平。系统外部环境则主要通过社会效益指标来反映。 从经济学角度出发，分别按系统成本、系统效益和财务指标等3条线索建立指标。

• 逆向工程从源代码得到软件系统的规格说明和设计信息，属于软件维护阶段行为，因此逆向工程工具属于软件维护工具。

• 极限编程（XP）是敏捷开发的典型方法之一，是一种轻量级（敏捷）、高效、低风 险、柔性、可预测的、科学的软件开发方法，它由价值观、原则、实践和行为4个部分组成。其中4大价值观为沟通、简单性、反馈和勇气。

• 可维护性质量特性是指与软件维护的难易程度相关的一组软件属性，它包含了易分析性、稳定性、易测试性和易改变性4个子特性。其中：易分析性是描述诊断缺陷或失效原因、判定待修改程度的难易程度的特性。稳定性是描述修改造成难以预料的后果的风险程度，风险程度越低，稳定性越好。易测试性是描述测试已修改软件的难易程度的特性。易改变性是描述修改、排错或适应环境变化的难易程度。

  项目模型

• 常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型，适合于软件需求很明确的软件项目。V模型是瀑布模型的一种演变模型，将测试和分析与设计关联进行，加强分析与设计的验证。原型模型是一种演化模型，通过快速构建可运行的原型系统，然后根据运行过程中获取的用户反馈进行改进。演化模型特别适用于对软件需求缺乏准确认识的情况。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析。 若项目组具备了所开发系统的相关领域及类似规模系统的开发经验，即需求明确，瀑布模型最适合开发此项目。

• 喷泉模型是典型的面向对象生命周期模型，是一种以用户需求为动力，以对象作为驱动的模型。该模型克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。“喷泉” 一词本身体现了迭代和无间隙特性。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统；无间隙是指在开发活动之间不存在明显的边界。

• 瀑布模型将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段的过程。 原型模型中，开发人员快速地构造整个系统或者系统的一部分以理解或澄清问题。螺旋模型将开发活动和风险管理结合起来，以减小风险。 喷泉模型开发过程模型以用户需求为动力，以对象为驱动，适合于面向对象的开发方法。 在这几种开发过程模型中，原型模型不适宜大规模软件的开发。

• 瀑布模型是一种经典的开发模型，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。瀑布模型的突出缺点是不适应用户需求的变化。

• 项目规模大、开发小组对项目需求理解并了解相关领域，因此可以采用瀑布开发模型。演化模式适用于对软件需求缺乏准确认识的情况。螺旋模型在开发过程中加入风险分析。喷泉模型适合于面向对象的开发方法。

• 增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

• 螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。

  1.原型方法适用于用户需求不清、需求经常变化的情况，可以帮助导出系统需求并验证需求的有效性；

  2.探索型原型的目的是弄清目标的要求，确定所希望的特性，并探讨多种方案的可行性，可以用来探索特殊的软件解决方案；

  3.原型法能够迅速地开发出一个让用户看得见的系统框架，可以用来支持用户界面设计。 原型法不能用来指导代码优化。

• 瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型，它为软件的开发和维护提供了一种有效的管理模式，适合于软件需求很明确的软件项目的模型。本题中开发的大学记账系统是基于原有系统开发的，要求采用新技术，而需求是明确的。 演化模型在获取一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，然后逐步演化成为最终软件产品。原型模型快速构造软件的原型，在此基础上开发最终软件产品。这两类模型主要是针对需求不确定或者不清楚的情况下，进行项目开发建议采用的。而螺旋模型增加了风险分析。

• 增量模型又称为渐增模型，也称为有计划的产品改进模型，它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。增量模型是瀑布模型和原型进化模型的综合，它对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中，则将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用。比较瀑布模型、原型进化模型，增量模型具有非常显著的优越性。但增量模型对软件设计有更高的技术要求，特别是对软件体系结构，要求它具有很好的开放性与稳定性，能够顺利地实现构件的集成。

• 增量式开发的主要优点包括：

  1.由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。

  2.由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。

  3.对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统。

  主要缺点包括：

  1.由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

  2.在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
  3. 在利用增量模型进行开发时，如何进行模块的划分往往是难点所在。

• McCall软件质量模型从软件产品的运行、修正和转移三个方面确定了11个质量特性，其中运行方面包含了正确性、可靠性、效率、完整性、使用性这些质量特性。修正方面包含了维护性、测试性、灵活性这3个质量特性。转移方面包含了维护性移植性、复用性、共运行性这3个质量特性。

• 通常从以下几个方面进行评审： ①评价软件的规格说明是否合乎用户的要求，即总体设计思想和设计方针是否明确；需求规格说明是否得到了用户或单位上级机关的批准；需求规格说明与软件的概要设计规格说明是否一致等。 ②评审可靠性，即是否能避免输入异常（错误或超载等）、硬件失效及软件失效所产生的失效，一旦发生应能及时采取代替手段或恢复手段。 ③评审保密措施实现情况，即是否对系统使用资格进行检查；是否对特定数据、特定功能的使用资格进行检查；在检查出有违反使用资格的情况后，能否向系统管理人员报告有关信息；是否提供对系统内重要数据加密的功能等。 ④评审操作特性实施情况，即操作命令和操作信息的恰当性，输入数据与输入控制语句的恰当性；输出数据的恰当性；应答时间的恰当性等。 ⑤评审性能实现情况，即是否达到所规定性能的目标值。 ⑥评审软件是否具有可修改性，可扩充性、可互换性和可移植性。 ⑦评审软件是否具有可测试性。 ⑧评审软件是否具有复用性。

  项目风险

• 风险是一种具有负面后果的、人们不希望发生的事件。项目经理必须进行风险管理， 以了解和控制项目中的风险。 风险可能会发生，因此具有一定的概率；风险产生的后果严重程度不一样，因此需要区分。在对风险进行优先级排序时，需要根据风险概率和后果来进行排序。在确定了风险之后，根据实际情况，可以通过改变系统的性能或功能需求来避免某些风险。在项目开发过程中，不可能去除所有风险，但是可以通过采取行动来降低或者减轻风险。而且风险需要定期地评估和管理。

• 风险分析实际上是4个不同的活动：风险识别、风险预测、风险评估和风险控制。 风险识别是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。风险预测又称为风险估算，它从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生时所产生的后果。风险评估根据风险及其发生的概率和产生的影响预测是否影响 参考水平值。风险控制的目的是辅助项目组建立处理风险的策略，有效的策略应考虑风 险避免、风险监控、风险管理及意外事件计划。

• 通常认为风险具有以下特点： 风险是可能发生的事件，其发生的可能性用风险概率来描述；风险是会给项目带来损失的事件；可能对风险进行干预，以期减少损失。针对每一种风险，应弄清可能减少造成损失或避免损失的程度。对风险加以控制，采取一些有效的措施来降低风险或是消除风险。

• 风险避免即放弃或不进行可能带来损失的活动或工作。例如，为了避免洪水风险，可以把工厂建在地势较高、排水方便的地方，这是一种主动的风险控制方法。风险监控是指在决策主体的运行过程中，对风险的发展与变化情况进行全程监督，并根据需要进行应对策略的调整。风险管理是指在一个肯定有风险的环境里把风险减至最低的管理过程。对于风险我们可以转移，可以规避，但不能消除。

• 风险管理是软件项目管理的一项重要任务。在进行风险管理时，根据风险的优先级来确定风险控制策略，而优先级是根据风险暴露来确定的。风险暴露是一种量化风险影响的指标，等于风险影响乘以风险概率，风险影响是当风险发生时造成的损失。风险概率是风险发生的可能性。风险控制是风险管理的一个重要活动。

• 一般而言，风险与不确定性有关，若某一事件的发生存在着两种或两种以上的可能性，即可认为该事件存在风险。但是选项B已经确定客户不清楚需求，所以是确定事情。所以不存在风险。

• 敏捷开发方法scrum的步骤包括：

  • Product Backlog 产品待办事项清单

  • Sprint Backlog待办事项清单

  • Sprint，冲刺迭代

  Refactoring 重构，不属于scrum的步骤；