软件工程方法

软件工程方法为目标计算机的软件开发提供了一种有组织和系统的方法。有许多方法可供选择，对于软件工程师来说，为手头的软件开发任务选择一种或几种合适的方法是很重要的;这种选择会对软件项目的成功产生巨大的影响。使用这些软件工程方法，加上具有适当技能集的人员和工具，使软件工程师能够可视化软件的细节，并最终将表示转换为代码和数据的工作集。

下面将讨论选定的软件工程方法。主题区域被组织成启发式方法、正式方法、原型方法和敏捷方法的讨论。

4.1启发式方法

启发式方法是那些基于经验的软件工程方法，它们已经在软件行业中得到了相当广泛的实践。本主题包含三个广泛的讨论类别:结构化分析和设计方法、数据建模方法和面向对象的分析和设计方法。

结构化分析和设计方法:软件模型主要从功能或行为的角度开发，从软件的高级视图(包括数据和控制要素)开始，然后通过越来越详细的设计逐步分解或细化模型组件。详细的设计最终集中于必须编码(手工、自动生成或两者同时生成)、构建、测试和验证的软件的非常具体的细节或规范。

数据建模方法:根据所使用的数据或信息的观点构建数据模型。数据表和关系定义了数据模型。这种数据建模方法主要用于定义和分析支持数据库设计或通常在业务软件中发现的数据存储库的数据需求，在业务软件中，数据作为业务系统资源或资产进行主动管理。

面向对象的分析和设计方法:面向对象模型表示为封装数据和关系的对象集合，并通过方法与其他对象交互。对象可以是真实世界的项目，也可以是虚拟的项目。软件模型是使用图来构成软件的选定视图来构建的。软件模型的逐步细化导致了详细的设计。然后，详细的设计要么通过连续的迭代进行演化，要么(使用某种机制)转换为模型的实现视图，其中表示最终软件产品发布和部署的代码和打包方法。

4.2正式的方法

形式方法是软件工程方法，通过应用严格的基于数学的符号和语言来指定、开发和验证软件。通过使用规范语言，可以以系统的、自动化的或半自动化的方式检查软件模型的一致性(换句话说，缺少模糊性)、完整性和正确性。这个主题与软件需求知识领域中的形式化分析部分有关。

本节讨论规范语言、程序细化和派生、形式验证和逻辑推理。

规范语言:规范语言为形式方法提供数学基础;规范语言是在软件规范、需求分析和/或设计阶段用于描述特定输入/输出行为的正式的、高级的计算机语言(换句话说，不是经典的第三代语言(3GL)编程语言)。规范语言不是直接可执行的语言;它们通常由表示法和语法、使用表示法的语义和一组允许的对象关系组成。

程序优化和派生:程序优化是使用一系列转换创建较低层面(或更详细)规范的过程。软件工程师是通过连续的转换来获得程序的可执行表示的。可以细化规范，添加细节，直到模型可以用3GL编程语言或所选规范语言的可执行部分来表述。通过定义具有精确语义属性的规范，可以实现规范的细化;规范不仅必须规定实体之间的关系，还必须规定这些关系和操作的确切运行时含义。

形式验证:模型检验是一种形式验证方法;它通常涉及执行状态空间探索或可达性分析，以证明所表示的软件设计具有或保留了某些感兴趣的模型属性。模型检查的一个例子是在所有可能的事件或消息到达交叉情况下验证正确的程序行为的分析。使用正式核证需要严格指定软件模型及其运作环境;这个模型通常采用有限状态机或其他正式定义的自动机的形式。

逻辑推理:逻辑推理是一种设计软件的方法，它包括在设计的每个重要部分周围指定前置条件和后置条件，并使用数学逻辑来证明这些前置条件和后置条件必须在所有输入下都存在。这为软件工程师在不执行软件的情况下预测软件行为提供了一种方法。一些集成开发环境(ide)包括在设计或代码的同时表示这些证明的方法。

4.3原型化方法

软件原型是一个活动,通常创建不完整或最低限度功能版本的软件应用程序,通常为特定的新特性,征求反馈软件需求或用户接口,进一步探索软件需求,软件设计,或实现选项,和/或获得其他一些有用的洞察软件。软件工程师首先选择一种原型方法来理解软件中最不被理解的方面或组件;这种方法与其他软件工程方法形成对比，后者通常首先从最容易理解的部分开始开发。通常，如果不进行大量的开发重做或重构，原型产品不会成为最终的软件产品。

本节简要讨论原型风格、目标和评估技术。原型风格:这解决了开发原型的各种方法。原型可以被开发为一次性代码或纸制品，作为工作设计的演变，或作为可执行的规范。每种风格通常使用不同的原型生命周期过程。选择的风格基于项目需要的结果类型、需要的结果的质量和结果的紧迫性。

原型目标:原型活动的目标是原型工作所服务的特定产品。原型化目标的例子包括需求规范、架构设计要素或组件、算法或人机用户接口。

原型评估技术:一个原型可以由软件工程师或其他项目利益攸关方以多种方式使用或评估，主要是由最初导致原型开发的潜在原因驱动的。原型可以根据实际实现的软件或一组目标需求(例如，一个需求原型)来评估或测试;原型还可以作为未来软件开发工作的模型(例如，在用户接口规范中)。

4.4敏捷方法

敏捷方法诞生于20世纪90年代，当时人们需要减少大型软件开发项目中使用的重量级的、基于计划的方法所带来的巨大开销。敏捷方法被认为是轻量级的方法，因为它们的特点是短的、迭代的开发周期、自组织的团队、更简单的设计、代码重构、测试驱动开发、频繁的客户参与，以及强调在每个开发周期中创建可演示的工作产品。

文献中有许多敏捷方法;这里简要讨论一些比较流行的方法，包括快速应用程序开发(RAD)、极限编程(XP)、SCRum和功能驱动开发(FDD)。

RAD:快速软件开发方法主要用于数据密集型的业务系统应用程序开发。RAD方法通过软件工程师使用的专用数据库开发工具来实现，这些工具用于快速开发、测试和部署新的或修改过的业务应用程序。

XP:这种方法使用需求的事例或场景，首先开发测试，让客户直接参与到团队中(通常定义验收测试)，使用成对编程，并提供持续的代码重构和集成。故事被分解为任务、划分优先级、评估、开发和测试。软件的每一个增量都通过自动化和手工测试进行测试;一个增量可能会被频繁地释放，比如每隔几周左右。

SCRum:这种敏捷方法比其他方法对项目管理更友好。SCRum管理员管理项目增量中的活动;每个增量称为冲刺，持续时间不超过30天。产品待办事项列表(PBI)是根据任务来确定、定义、排序和评估的。在每个增量中测试并发布软件的工作版本。每日SCRum会议确保工作按照计划进行。

FDD:这是一种模型驱动的、短的、迭代的软件开发方法，使用一个五阶段过程:

(1) 开发一个产品模型来扩大领域的范围，

(2) 创建需求或功能列表，

(3) 构建功能开发计划，

(4)开发针对特定于迭代的功能的设计，以及

(5)代码、测试、功能集成。

FDD类似于增量式软件开发方法;它也类似于XP，除了代码所有权被分配给个人而不是团队。FDD强调软件的整体架构方法，它促进在第一次就正确地构建特性，而不是强调持续的重构。

在文献和实践中还有许多敏捷方法的变体。请注意，重量级的、基于计划的软件工程方法和敏捷方法一样都有一席之地。有一些新方法是从敏捷方法和基于计划的方法的组合中产生的，从业者正在定义新的方法，这些方法主要基于当前的组织业务需求来平衡重量级和轻量级方法所需的特性。这些业务需求，通常由一些项目利益攸关方所代表，应该并且确实推动选择使用一种软件工程方法而不是另一种，或者从软件工程方法组合的最佳特性中构建一种新方法。