软件设计师教程(第5版全国计算机技术与软件专业技术资格水平考试指定用书)

作者简介

无

内容简介

第5章 软件工程基础知识 　　本章介绍软件工程的相关基础知识，主要内容包括软件过程与过程模型、需求分析、软件设计、软件测试、软件运行与维护、软件项目管理、软件质量、软件度量、软件工具与软件开发环境等相关知识。 5.1 软件工程概述 　　早期的软件主要指程序，程序的开发采用个体工作方式，开发工作主要依赖于开发人员的个人技能和程序设计技巧。当时的软件通常缺少与程序有关的文档，软件开发的实际成本和进度往往与预计的相差甚远，软件的质量得不到保证，开发出来的软件常常不能使用户满意。随着计算机应用需求的不断增长，软件的规模也越来越大，然而软件开发的生产率远远跟不上计算机应用的迅速增长。此外，由于软件开发时缺少好的方法指导和工具辅助，同时又缺少相关文档，使得大量已有的软件难以维护。上述这些问题严重地阻碍了软件的发展，20世纪60年代中期，人们把上述软件开发和维护过程中所遇到的各种问题称为“软件危机”。 　　1968年，在德国召开的NATO（North Atlantic Treaty Organization，北大西洋公约组织）会议上**提出了“软件工程”这个名词，希望用工程化的原则和方法来克服软件危机。在此以后，人们开展了软件开发模型、开发方法、工具与环境的研究，提出了瀑布模型、演化模型、螺旋模型和喷泉模型等开发模型，出现了面向数据流方法、面向数据结构的方法、面向对象方法等开发方法，以及一批CASE（Computer Aided Software Engineering，计算机辅助的软件工程）工具和环境。现在，软件工程已经成为计算机软件的一个重要分支和研究方向。 　　软件工程是指应用计算机科学、数学及管理科学等原理（如图5-1所示），以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。软件工程涉及软件开发、维护、管理等多方面的原理、方法、工具与环境，限于篇幅，本章不能对软件工程做全面的介绍。根据软件设计考试大纲的要求，本章着重介绍软件开发过程中的原理，其他内容只做简单的介绍。 图5-1 软件工程学的范畴 5.1.1 计算机软件 　　计算机软件是指计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述。任何以计算机为处理工具的任务都是计算任务。处理对象是数据（如数字、文字、图形、图像、声音等，它们只是表示，而无含义）或信息（数据及有关的含义）。处理规则一般指处理的动作和步骤。文档是为了便于了解程序所需的阐述性资料。 　　按照软件的应用领域，可以将计算机软件分为十大类。 　　1. 系统软件 　　系统软件是一整套服务于其他程序的程序。某些系统软件处理复杂但是确定的信息结构。另一些系统应用程序（如操作系统构件、驱动程序、网络软件、远程通信处理器）主要处理的是不确定的数据。无论何种情况，系统软件多具有以下特点：和计算机硬件大量交互；多用户大量使用；需要调度、资源共享和复杂进程管理的同步操作；复杂的数据结构以及多种外部 接口。 　　2. 应用软件 　　应用软件是解决特定业务需要的独立应用程序。这类应用软件处理商务或技术数据，以协助业务操作和管理或技术决策。除了传统数据处理的应用程序，应用软件也被用于业务功能的实时控制（例如销售点的交易处理、实时制造过程控制等）。 　　3. 工程/科学软件 　　这类软件通常带有“数值计算”算法的特征。工程/科学软件涵盖了广泛的应用领域，从天文学到火山学，从自动应力分析到航天飞机轨道动力学，从分子生物学到自动制造业。不过，当今科学工程领域的应用软件已经不仅仅局限于传统的数值算法，计算机辅助设计、系统仿真和其他的交互性应用程序已经呈现出实时性甚至具有系统软件的特性。 　　4. 嵌入式软件 　　嵌入式软件存在于某个产品或系统中，可实现和控制面向*终使用者和系统本身的特性和功能。嵌入式软件可以执行有限但难于实现的功能（例如，微波炉的按键控制）或者提供重要的功能和控制能力（例如，汽车中的燃油控制、仪表板显示、刹车系统等汽车电子功能）。 　　5. 产品线软件 　　产品为多个不同用户的使用提供特定功能。产品线软件关注有限的特定专业市场（例如库存控制产品）或大众消费品市场（例如，文字处理、多媒体、娱乐、数据库管理等）。 　　6. Web应用 　　Web应用（WebApp）是一类以网络为中心的软件，其概念涵盖了宽泛的应用程序产品。*简单可以是一组超文本链接文件，仅仅用文本和有限的图形表达信息。然而，随着Web 2.0的出现，网络应用正在发展为复杂的计算环境，不仅为*终用户提供独立的特性、计算功能和内容信息，还与企业数据库和商务应用程序相结合。*大多数WebApp具备网络密集性、并发性、无法预知的负载量、性能、可用性和数据驱动属性。 　　7. 人工智能软件 　　人工智能软件利用非数值算法解决计算和直接分析无法解决的复杂问题。这个领域的应用包括机器人、专家系统、模式识别、人工神经网络、定理证明和博弈等。 　　8. 开放计算 　　无线网络的快速发展将促成真正的普适计算、分布式计算的实现。软件工程师所面临的挑战是如何开发系统和应用软件，以使移动设备、个人电脑和企业应用可以通过大量的网络设施进行通信。 　　9. 网络资源 　　现在，万维网已经快速发展为一个计算引擎和内容提供平台。软件工程师面临的新任务是构建一个简单而智能的应用程序，为全世界的*终用户市场提供服务。 　　10. 开源软件 　　开源软件就是开放系统应用程序的代码，使得很多人能够为软件开发做贡献，这种方式正在逐步成为一种趋势。软件工程师面临的挑战是开发可以自我描述的代码，*重要的是开发某种技术，以便于用户和开发人员都能够了解已经发生的改动，并且知道这些改动如何在软件中体现出来。 5.1.2 软件工程基本原理 　　美国**的软件工程专家B.W.Boehm于1983年提出了软件工程的7条基本原理。Boehm认为这7条原理是确保软件产品质量和开发效率的原理的*小集合。 　　1. 用分阶段的生命周期计划严格管理 　　有统计表明，50%以上的失败项目是由于计划不周造成的。在软件开发与维护的漫长生命周期中，需要完成许多各种各样的工作。这条基本原理意味着应该把软件生命周期划分成若干个阶段，并相应地制订出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。Boehm认为，在软件的整个生存周期中应该制定并严格执行六类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运行维护计划。 　　2. 坚持进行阶段评审 　　据统计结果显示，大部分错误是在编码之前造成的。根据Boehm等人的统计，设计错误占软件错误的63%，编码错误仅占37%，而且错误发现与改正得越晚，所需付出的代价越高。因此，在每个阶段都应进行严格的评审，以便尽早发现在软件开发过程中所犯的错误。 　　3. 实现严格的产品控制 　　在软件开发过程中不应随意改变需求，因为改变一项需求需要付出较高的代价。但是，在软件开发过程中改变需求又是难免的，由于外部环境的变化，相应地改变用户需求是一种客观需要，这就要采用科学的产品控制技术来顺应这种要求。在改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。基准配置又称为基线配置，它是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。基准配置管理也称为变动控制，一切有关修改软件的建议，特别是涉及基准配置的修改建议，都必须按照严格的规程进行评审，在获得批准以后才能实施修改。 　　4. 采用现代程序设计技术 　　从20世纪60年代和70年代的结构化软件开发技术到面向对象技术，从**代、第二代语言到第四代语言，人们已经充分认识到：方法大于力气。采用**的技术既可以提高软件开发的效率，又可以降低软件维护的成本。 　　5. 结果应能清楚地审查 　　软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难以评价和管理。为了*好地进行管理，应根据软件开发的总目标及完成期限尽量明确地规定开发小组的责任和产品标准，从而使所得到的结果能够清楚地审查。 　　6. 开发小组的人员应少而精 　　开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少得多；当开发小组为N人时，可能的通信信道为N(N?1)/2。可见，随着人数N的增大，通信开销将急剧增大。 　　7. 承认不断改进软件工程实践的必要性 　　遵循上述6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产。但是它们只是对现有经验的总结和归纳，并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，Boehm提出应把“承认不断改进软件工程实践的必要性”作为软件工程的第7条原理。根据这条原理，用户不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些，每个需求被赋予**的标识符，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需求与其他需求或设计文档、代码、测**例的不同版本间的关系。例如，特征跟踪表，记录需求如何与产品或系统特征相关联；来源跟踪表，记录每个需求的来源；依赖跟踪表，描述需求间如何关联等。 　　这些跟踪表可以用于需求跟踪。在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性，确保所有的实现是以用户需求为基础，所有的输出符合用户需求，并且全面覆盖了用户需求。需求跟踪有两种方式：正向跟踪和逆向跟踪。其中，正向跟踪以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点；逆向跟踪检查设计文档、代码、测**例等工作产品是否都能在《需求规约》中找到出处。 5.4 系统设计 　　在系统分析阶段，我们已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。进入设计阶段，要把软件“做什么”的逻辑模型转换成“怎么做”的物理模型，即着手实现软件系统的需求。 　　系统设计的主要目的就是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，*终勾画出新系统的详细设计方案。 　　系统设计的主要内容包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。 　　目前，已存在的多种系统设计方法，常用的设计方法有以下两种。 　　（1）面向数据流的结构化设计方法（SD）。 　　（2）面向对象的分析方法（OOD）。 　　系统设计的基本任务大体上可以分为概要设计和详细设计两个步骤。数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优**行研究的工具和技术。 5.1.3 软件生存周期 　　与其他事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡的许多阶段，一般称为软件生存周期。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件的开发变得容易控制和管理。通常，软件生存周期包括可行性分析与项目开发计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动，可以将这些活动以适当的方式分配到不同的阶段去完成。 　　1. 可行性分析与项目开发计划 　　这个阶段主要确定软件的开发目标及其可行性。必须要回答的问题是：要解决的问题是什么？该问题有可行的解决办法吗？若有解决的办法，则需要多少费用？需要多少资源？需要多少时间？要回答这些问题，就要进行问题定义、可行性分析，制订项目开发计划。 　　可行性分析与项目计划阶段的参加人员有用户、项目负责人和系统分析师。该阶段产生的主要文档有可行性分析报告和项目开发计划。 　　2. 需求分析 　　需求分析阶段的任务不是具体地解决问题，而是准确地确定软件系统必须做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。该阶段的参加人员有用户、项目负责人和系统分析师。该阶段产生的主要文档有软件需求说明书。 　　3. 概要设计 　　在概要设计阶段，开发人员要把确定的各项功能需求转换成需要的体系结构。在该体系结构中，每个成分都是意义明确的模块，即每个模块都和某些功能需求相对应，因此，概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块的层次结构是怎样的，这些模块的调用关系是怎样的，每个模块的功能是什么。同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么 关系。 　　概要设计阶段的参加人员有系统分析师和软件设计师。该阶段产生的主要文档有概要设计说明书。 　　4. 详细设计 　　详细设计阶段的主要任务是对每个模块完成的功能进行具体描述，要把功能描述转变为**的、结构化的过程描述。即该模块的控制结构是怎样的，先做什么，后做什么，有什么样的条件判定，有些什么重复处理等，并用相应的表示工具把这些控制结构表示出来。 　　详细设计阶段的参加人员有软件设计师和程序员。该阶段产生的主要文档有详细设计文档。 　　5. 编码 　　编码阶段就是把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。 　　6. 测试 　　测试是保证软件质量的重要手段，其主要方式是在设计测**例的基础上检查软件的各个组成部分。测试阶段的参加人员通常是另一部门（或单位）的软件设计师或系统分析师。该阶段产生的主要文档有软件测试计划、测**例和软件测试报告。 　　7. 维护 　　软件维护是软件生存周期中时间*长的阶段。已交付的软件投入正式使用后，便进入软件维护阶段，它可以持续几年甚至几十年。在软件运行过程中可能由于各方面的原因需要对它进行修改，其原因可能是运行中发现了软件隐含的错误而需要修改；也可能是为了适应变化了的软件工作环境而需要做适当变*；也可能是因为用户业务发生变化而需要扩充和增强软件的功能；还可能是为将来的软件维护活动做预先准备等。 5.1.4 软件过程 　　在开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是**重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图称为“软件过程”。过程是活动的集合，活动是任务的集合。软件过程有3层含义：一个是个体含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程、软件管理过程等；二是整体含义，即指软件产品或系统在所有上述含义下的软件过程的总体；三是工程含义，即指解决软件过程的工程，应用软件的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件的生产率，降低成本。 　　1. 能力成熟度模型（CMM） 　　自从软件工程概念提出以后，出现了许多开发、维护软件的模型、方法、工具和环境，它们对提高软件的开发、维护效率和质量起到了很大的作用。尽管如此，人们开发和维护软件的能力仍然跟不上软件所涉及问题的复杂程度的增长，软件组织面临的主要问题仍然是无法开发出符合预算和进度要求的高可靠性和高可用性的软件。人们开始意识到问题的实质是缺乏管理软件过程的能力。 　　在美国***的支持下，1987年，卡内基·梅隆大学软件工程研究所率先推出了软件工程评估项目的研究成果——软件过程能力成熟度模型（Capability Maturity Model of Software，CMM），其研究目的是提供一种评价软件承接方能力的方法，同时它可帮助软件组织改进其软件过程。 　　CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。该能力成熟度模型使软件组织能够较容易地确定其当前过程的成熟度并识别其软件过程执行中的薄弱环节，确定对软件质量和过程改进*为关键的几个问题，从而形成对其过程的改进策略。软件组织只要关注并认真实施一组有限的关键实践活动，就能稳步地改善其全组织的软件过程，使全组织的软件过程能力持续增长。 　　CMM将软件过程改进分为以下5个成熟度级别。 　　1）初始级（Initial） 　　软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功**依赖个人的努力和英雄式核心人物的作用。 　　2）可重复级（Repeatable） 　　建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。 　　3）已定义级（Defined） 　　管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。 　　4）已管理级（Managed） 　　制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。 　　5）优化级（Optimized） 　　加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。 　　CMM模型提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级，为过程不断改进奠定了循序渐进的基础。这5个成熟度等级定义了一个有序的尺度，用来测量一个组织的软件过程成熟度和评价其软件过程能力。成熟度等级是已得到确切定义的，也是在向成熟软件组织前进途中的平台。每一个成熟度等级为继续改进过程提供一个基础。每一个等级包含一组过程目标，通过实施相应的一组关键过程域达到这一组过程目标，当目标满足时，能使软件过程的一个重要成分稳定。每达到成熟度框架的一个等级，就建立起软件过程的一个相应成分，使得组织过程能力有一定程度的增长。 　　基于CMM模型的产品包括一些诊断工具，可应用于软件过程评价和软件能力评估小组，以确定一个机构的软件过程实力、弱点和风险。***的是成熟度调查表。软件过程评价及软件能力评估的方法及培训也依赖于CMM模型。 　　2. 能力成熟度模型集成（CMMI） 　　CMM的成功导致了适用不同学科领域的模型的衍生，如系统工程的能力成熟度模型，适用于集成化产品开发的能力成熟度模型等。而一个工程项目又往往涉及多个交叉的学科，因此有必要将各种过程改进的工作集成起来。1998年，由美国产业界、政府和卡内基·梅隆大学软件工程研究所共同主持CMMI项目。CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。2000年发布了CMMI-SE/SW/IPPD，集成了适用于软件开发的SW-CMM（草案版本2（C））、适用于系统工程的EIA/IS731以及适用于集成化产品和过程开发的IPD CMM（0.98版）。2002年1月发布了CMMI-SE/SW/IPPD 1.1版。 　　CMMI提供了两种表示方法：阶段式模型和连续式模型。 　　1）阶段式模型 　　阶段式模型的结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版中有5个成熟度等级。 * 初始的：过程不可预测且缺乏控制。 * 已管理的：过程为项目服务。 * 已定义的：过程为组织服务。 * 定量管理的：过程已度量和控制。 * 优化的：集中于过程改进。 　　2）连续式模型 　　连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（Capability Level，CL）。CMMI中包括6个过程域能力等级，等级号为0～5。能力等级包括共性目标及相关的共性实践，这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时，就说该组织达到了那个过程域的能力等级。 　　能力等级可以独立地应用于任何单独的过程域，任何一个能力等级都必须满足比它等级低的能力等级的所有准则。对各能力等级的含义简述如下。 * CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标。 * CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。 * CL2（已管理的）：其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审。 * CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。 * CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理 准则。 * CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。 5.2 软件过程模型 　　软件过程模型习惯上也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。 5.2.1 瀑布模型（Waterfall Model） 　　瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落，如图5-2所示。 　　瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。 　　瀑布模型假设，一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现完成之前产生。 　　瀑布模型的一个变体是V模型，如图5-3所示。V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。 图5-3 V模型 　　瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或3个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统的能力。在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。 5.2.2 增量模型（Incremental Model） 　　增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如图5-4所示。当使用增量模型时，**个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了*终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。 　　 　　 　　 　　 　　 　　 　　 　　 　　 　　增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：**个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了**个版本，因此可以减少用户需求的变*；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。 　　增量模型有以下不足之处：如果没有对用户的变*要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和置的复杂性可能会超出组织的能力。 5.2.3 演化模型（Evolutionary Model） 　　软件类似于其他复杂的系统，会随着时间的推移而演化。在开发过程中，常常会面临以下情形：商业和产品需求经常发生变化，直接导致*终产品难以实现；严格的交付时间使得开发团队不可能圆满地完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。在上述情况和类似情况下，软件开发人员需要一种专门应对不断演变的软件产品的过程模型。 　　演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出*完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。 　　1. 原型模型（Prototype Model） 　　并非所有的需求都能够预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变*。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型（Rapid Prototype）这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。 　　原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型。原型模型如图5-5所示。 　　原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制订原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。 　　根据使用原型的目的不同，原型可以分为探索型原型、实验型原型和演化型原型3种。探索型原型的目的是要弄清目标的要求，确定所希望的特性，并探讨多种方案的可行性。实验型原型的目的是验证方案或算法的合理性，是在大规模开发和实现前，用于考查方案是否合适、规格说明是否可靠等。演化型原型的目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成*终的目标系统。 　　2. 螺旋模型（Spiral Model） 　　对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。 　　螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，如图5-6所示。每个螺旋周期分为如下4个工作步骤。 　　（1）制订计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。 　　（2）风险分析。分析所选的方案，识别风险，消除风险。 　　（3）实施工程。实施软件开发，验证阶段性产品。 　　（4）用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。 图5-6 螺旋模型 　　螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应。因此，该模型特别适用于庞大、复杂并且具有高风险的系统。 　　与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。 5.2.4 喷泉模型（Water Fountain Model） 　　喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性，如图5-7所示。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，在需求分析活动结束后才开始设计活动，在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。 　　喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。其优点是可以提高软件项目的开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外，这种模型要求严格管理文档，使得审核的难度加大。 5.2.5 基于构件的开发模型（Component-based Development Model） 　　基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品（Commercial Off-The-Shelf，COTS）软件构件。基于构件的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建软件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。 　　一种基于构建的开发模型如图5-8所示，包括领域工程和应用系统工程两部分。 　　领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。为达到此目的，首先要进行领域分析，分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构，表示领域的候选构件，对候选构件进行可变性分析，以适应多个应用系统的需要，*后构建可复用构件，经严格测试和包装后存入可复用构件库。 　　应用系统工程的目的是使用可复用构件组装应用系统。首**行应用系统分析，设计应用系统的体系结构，标识应用系统所需的构件，然后在可复用构件库中查找合适的构件（也可以购买第三方构件），这些选取的构件需进行特化，必要时做适当的修改，以适应该应用系统的需要。对于那些未找到合适构件的应用部分，仍需单独开发，并将其与特化修改后的构件组装成应用系统。在此过程中，还需要对可复用构件的复用情况进行评价，以改进可复用构件，同时对新开发的部分进行评价，并向领域工程**候选构件。 图5-8 基于构件的开发模型 5.2.6 形式化方法模型（Formal Methods Model） 　　形式化方法是建立在严格数学基础上的一种软件开发方法，其主要活动是生成计算机软件形式化的数学规格说明。 　　形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。这种方法的一个变形是净室软件工程。 5.2.7 统一过程（UP）模型 　　统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。迭代的意思是将整个软件开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。 　　统一过程定义了4个技术阶段及其制品。 　　1）起始阶段（Inception Phase） 　　起始阶段专注于项目的初创活动，产生的主要工作产品有构想文档（Vision Document）、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划（阶段及迭代）、业务模型以及一个或多个原型（需要时）。 　　2）精化阶段（Elaboration Phase） 　　精华阶段在理解了*初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求（包括非功能需求）、分析模型、软件体系结构描述、可执行的软件体系结构原型、初步的设计模型、修订的风险列表、项目计划（包括迭代计划、调整的工作流、里程碑和技术工作产品）以及初始用户手册。 　　3）构建阶段（Construction Phase） 　　构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、软件构件、集成的软件增量、测试计划及步骤、测**例以及支持文档（用户手册、安装手册和对于并发增量的描述）。 　　4）移交阶段（Transition Phase） 　　移交阶段关注于软件提交方面的工作，产生软件增量，产生的主要工作产品有提交的软件增量、β测试报告和综合用户反馈。 　　每次迭代产生包括*终系统的部分完成的版本和任何相关的项目文档的基线，通过逐步迭代基线之间相互构建，直到完成*终系统。在每个迭代中有个核心工作流：捕获系统应该做什么的需求工作流，精化和结构化需求的分析工作流，在系统构架内实现需求的设计工作流，构造软件的实现工作流，验证实现是否如期望那样工作的测试工作流。随着UP的阶段进展，每个核心工作流的工作量发生了变化。4个技术阶段由主要里程碑所终止。 * 初始阶段：生命周期目标。 * 精化阶段：生命周期架构。 * 构建阶段：初始运作功能。 * 移交阶段：产品发布。 　　统一过程的典型代表是RUP（Rational Unified Process）。RUP是UP的商业扩展，**兼容UP，但比UP*完整、*详细。 5.2.8 敏捷方法（Agile Development） 　　敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变 需求。 　　敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。 　　1. 极限编程（XP） 　　XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。 * 4大价值观：沟通、简单性、反馈和勇气。 * 5个原则：快速反馈、简单性假设、逐步修改、提倡*改和优质工作。 * 12个*佳实践：计划游戏（快速制定计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40个小时、现场客户和编码标准。 　　2. 水晶法（Crystal） 　　水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过*好地交流和经常性的交付，软件生产力得到提高。 　　3. 并列争求法（Scrum） 　　并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。 　　4. 自适应软件开发（ASD） 　　ASD有6个基本的原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。 　　5. 敏捷统一过程（AUP） 　　敏捷统一过程（Agile Unified Process，AUP）采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。采用经典的UP阶段性活动（初始、精化、构建和转换），提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给*终用户。每个AUP迭代执行以下活动： * 建模。建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续 前进。 * 实现。将模型翻译成源代码。 * 测试。像XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。 * 部署。对软件增量的交付以及获取*终用户的反馈。 * 配置及项目管理。着眼于变*管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。 * 环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施。 5.3 需求分析 5.3.1 软件需求 　　在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。 　　（1）功能需求。考虑系统要做什么，在何时做，在何时以及如何修改或升级。 　　（2）性能需求。考虑软件开发的技术性指标。例如，存储容量限制、执行速度、响应时间及吞吐量。 　　（3）用户或人的因素。考虑用户的类型。例如，各种用户对使用计算机的熟练程度，需要接受的训练，用户理解、使用系统的难度，用户错误操作系统的可能性等。 　　（4）环境需求。考虑未来软件应用的环境，包括硬件和软件。对硬件设备的需求包括机型、外设、接口、地点、分布、湿度、磁场干扰等；对软件的需求包括操作系统、网络、数据库等。 　　（5）界面需求。考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。 　　（6）文档需求。考虑需要哪些文档，文档针对哪些读者。 　　（7）数据需求。考虑输入、输出数据的格式，接收、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。 　　（8）资源使用需求。考虑软件运行时所需要的数据、其他软件、内存空间等资源；软件开发、维护所需的人力、支撑软件、开发设备等。 　　（9）安全保密要求。考虑是否需要对访问系统或系统信息加以控制，隔离用户数据的方法，用户程序如何与其他程序和操作系统隔离以及系统备份要求等。 　　（10）可靠性要求。考虑系统的可靠性要求，系统是否必须检测和隔离错误；出错后，重启系统允许的时间等。 　　（11）软件成本消耗与开发进度需求。考虑开发是否有规定的时间表，软/硬件投资有无限制等。 　　（12）其他非功能性要求。如采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的要求。 　　这些需求可以来自于用户（实际的和潜在的）、用户的规约、应用领域的专家、相关的技术标准和法规；也可以来自于原有的系统、原有系统的用户、新系统的潜在用户；甚至还可以来自于竞争对手的产品。 5.3.2 需求分析原则 　　需求分析过程的具体实现有不同的分析方法，这些方法有自己独特的特点。然而，这些分析方法都遵循一组操作原则。 　　（1）必须能够表示和理解问题的信息域。 　　（2）必须能够定义软件将完成的任务。 　　（3）必须能够表示软件的行为（作为外部事件的结束）。 　　（4）必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。 　　（5）分析过程应该从要素信息移向细节信息。 　　通过应用这些原则，分析人员将能系统地处理问题。检查信息域可以*完整地理解功能，通过模型可以*简洁地交流功能和行为的特征，应用抽象与分解可减少问题的复杂度。 5.3.3 需求工程 　　需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并*终在验证的基础上冻结需求。需求工程可以细分为需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理6个阶段。 　　1. 需求获取 　　在需求获取阶段，系统分析人员通过与用户的交流、对现有系统的观察以及对任务进行分析确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为*好地定义需求而开发的原型。需求获取的工作产品为进行需求分析提供了基础。 　　2. 需求分析与协商 　　需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其他需求的关系，以检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。在需求获取阶段，经常出现以下问题：用户提出的要求超出软件系统可以实现的范围或实现能力；不同的用户提出了相互冲突的需求；每个用户在提出自己的需求时都会说“这是至关重要的”，所以系统分析人员需要通过一个谈判过程来调解这些冲突。 　　3. 系统建模 　　建模技术可以通过合适的工具和符号系统地描述需求。建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的“桥梁”，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象方法。 　　在观察和研究某一事物或某一系统时，常常把它抽象为一个模型。创建模型是需求分析阶段的重要活动。模型以一种简洁、准确、结构清晰的方式系统地描述了软件需求，从而帮助分析员理解系统的信息、功能和行为，使得需求分析任务*容易实现，结果*系统化，同时易于发现用户描述中的模糊性和不一致性；模型将成为软件设计的基础，为设计者提供软件要素的表示视图，这些表示可被转化到实现的语境中去；*重要的是，模型还可以在分析人员和用户之间建立*快捷的沟通方式，使两者可以用相同的工具分析和理解问题。 　　在软件需求分析阶段所创建的模型，要着重于描述系统要做什么，而不是如何去做，目标软件的模型不应涉及软件的实现细节。通常情况下，分析人员使用图形符号来创建模型，将信息、处理、系统行为和其他相关特征描述为各种可识别的符号，同时与符号图形相配套，并辅以文字描述，可使用自然语言或某种特殊的专门用于描述需求的语言来提供辅助的信息描述。 　　目前，已存在的多种需求分析方法引用了不同的分析策略，常用的分析方法有以下两种： 　　（1）面向数据流的结构化分析方法（SA）。 　　（2）面向对象的分析方法（OOA）。 　　4. 需求规约 　　软件需求规约是分析任务的*终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求规约作为用户和开发者之间的一个协议，在之后的软件工程各阶段发挥重要的作用。软件需求规约中通常包含以下内容。 　　（1）引言。引言陈述软件目标，在基于计算机的系统语境内进行描述。 　　（2）信息描述。信息描述给出软件必须解决的问题的详细描述，记录信息内容、信息流和信息结构。 　　（3）功能描述。功能描述用来描述解决问题所需要的每个功能。其中包括为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。 　　（4）行为描述。行为描述用于描述作为外部事件和内部产生的控制特征的软件操作。 　　（5）检验标准。检验标准描述检验系统成功的标志，即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。检验标准是“确认测试”的基础。 　　（6）参考书目。参考书目包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献和标准。 　　（7）附录。附录包含了规约的补充信息，表格数据、算法的详细描述、图表和其他资料。 　　5. 需求验证 　　需求验证作为需求开发阶段工作的复查手段，其目的是要检验需求功能的正确性、完整性和清晰性，是否能够反映用户的意愿，由于需求的变化往往使系统的设计和实现也跟着改变，所以由需求问题引起系统变*的成本比修改设计或代码错误的成本高得多。因此，为保证软件需求定义的质量，评审应**专门的人员负责，并按规程严格进行。 　　需求验证需要对需求文档中定义的需求执行多种检查。开发团队要对用户需求进行“遍访”，逐条解释需求含义；评审团队应该检查需求的有效性、一致性和作为一个整体的完备性。评审人员评审时往往需要检查以下内容： 　　（1）系统定义的目标是否与用户的要求一致。 　　（2）系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求。 　　（3）被开发项目的数据流与数据结构是否确定且充足。 　　（4）主要功能是否已包括在规定的软件范围之内，是否都已充分说明。 　　（5）设计的约束条件或限制条件是否符合实际。 　　（6）开发的技术风险是什么。 　　（7）是否详细地制定了检验标准，它们能否对系统定义进行确认。 　　为了保证软件需求定义的质量，验证应该由专门的人员来负责，按照规定严格进行。除分析人员之外，还要有用户，开发部门的管理者，软件设计、实现、测试的人员参加。评审结束应有负责人的结论意见和签字。 　　想要判断一组需求是否符合用户的需要是很困难的。用户需要描述出系统的操作过程，构想出如何让系统加入到他们的工作中去，这种抽象对于一个普通用户来说比较困难。所以，需求验证也不可能发现所有的需求问题。在需求验证之后，对遗漏的补充以及对错误理解的*正是不可避免的，因此需要进行需求管理。 　　6. 需求管理 　　在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动通常是交叉、递增和反复地进行。而且，软件系统的需求会变*，这些变*不仅会存在于项目开发过程，而且会出现在项目已经付诸应用之后。软件需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动，对需求工程所有相关活动的规划和控制。换句话说，需求管理就是一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变*的系统需求达成并保持一致的过程。 　　在需求管理中 软件设计师教程（第5版）依据2018年审定通过的软件设计师考试大纲大纲编写，涵盖软件设计师（中级）岗位所要求的主要知识及应用技术。 通过软件设计师考试的考生可以获得由人力资源和社会保障部、***认可的职业资格证书，本考试为中级资格认证。