软件开发方法是指软件开发过程所遵循的办法和步骤，从不同的角度可以对软件开发方法进行不同的分类。

形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。形式化方法的主要优越性在于它能够数学地表述和研究应用问题及软件实现。但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难于为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。

净室软件工程（Cleanroom Software Engineering, CSE)是软件开发的一种形式化方法，可以开发较高质量的软件。它使用盒结构规约进行分析和建模，并且将正确性验证作为发现和排除错误的主要机制，使用统计测试来获取认证软件可靠性所需要的信息。CSE强调在规约和设计上的严格性，还强调统计质量控制技术，包括基于客户对软件的预期使用测试。

结构化方法也称为生命周期法，是一种传统的信息系统开发方法，由结构化分析、 结构化设计和结构化程序设计三部分组成，其精髓是自顶向下、逐步求精和模块化设计。结构化方法的主要特点是：开发目标清晰化、开发工作阶段化、开发文档规范化和设计方法结构化。结构化方法特别适合于数据处理领域的问题，但是不适应于规模较大、比较复杂的系统开发。结构化方法的缺点是开发周期长、难以适应需求的变化、很少考虑数据结构。

面向对象方法是目前比较主流的开发方法。面向对象方法是系统的描述及信息模型的表示与客观实体相对应，符合人们的思维习惯，有利于系统开发过程中用户与开发人员的交流和沟通，缩短开发周期，提高系统开发的正确性和效率。可以把结构化方法和面向对象方法结合起来进行系统开发。首先使用结构化方法进行自顶向下的整体划分；然后再自底向上地采用面向对象方法开发系统。

敏捷方法是从20世纪90年代开始逐渐引起广泛关注的一种新型软件开发方法，以应对快速变化的需求。敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调，让客户满意和软件尽早增量发布：小而高度自主的项目团队；非正式的方法：最小化软件工程工作产品以及整体精简开发。与传统方法相比，敏捷开发方法比较适合需求变化较大或者开发前期需求不是很清晰的项目，以它的灵活性来适应需求的变化。

敏捷方法的核心思想主要有以下三点
①敏捷方法是“适应性”而非“预设性”的。传统方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷方法则欢迎变化，其实它的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

②敏捷方法是以人为本，而不是以过程为本。传统方法以过程为本，强调充分发挥人的特性，不去限制它，并且软件开发在无过程控制和过于严格烦琐的过程控制中取得一种平衡，以保证软件的质量。

③迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。

与RUP相比，敏捷方法的周期可能更短。敏捷方法在几周或者几个月的时间内完成相对较小的功能，强调的是能尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强，并且更加强调团队中的高度协作。相对而言，敏捷方法主要适合于以下场合：

①项目团队的人数不能太多，适合于规模较小的项目。
②项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合。
③尚风险项目的实施。
④从组织结构的角度看，组织结构的文化、人员、沟通性决定了敏捷方法是否使用。

面向服务的方法以粗粒度、松散耦合和基于标准的服务为基础，增强了系统的灵活性、可复用性和可演化性。RUP软件开发生命周期是一个二维的软件开发模型，其中有9个核心工作流，分别为：业务建模、需求、分析与设计、实现、测试部署、配置与变更管理、项目管理以及环境。

RUP把软件开发生存周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段分别为：

初始阶段：定义最终产品视图和业务模型，并确定系统范围。

细化阶段：设计及确定系统的体系结构，制定工作计划及资源要求。
构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
移交阶段：把产品提交给用户使用。

每个阶段都有一个或多个连续的迭代组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对工作流中的行为进行裁剪。在每个阶段结束前有一个里程碑评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续该阶段的工作。

与其他软件开发过程相比，RUP具有自己的特点，即RUP是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。在RUP中采用“4+1”视图模型来描述软件系统的体系结构。“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。

分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；最终用户关心的是系统的功能，因此会侧重于逻辑视图：程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图：系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图；系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。

RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。
1、商业建模(Business Modeling)：商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
2、需求(Requirements)：需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
3、 分析和设计(Analysis & Design)：分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。

4、实现(Implementation)：实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
5、测试(Test)：测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确认缺陷在软件部署之前被提出并处理。
6、 部署(Deployment)：部署工作流的目的是成功的生成版本并将软件分发给最终用户。
7、配置和变更管理(Configuration & Change Management)：配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。
8、项目管理(Project Management)：软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9、环境(Environment)：环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。

原型模型又称快速原型。原型模型主要有两个阶段：

①原型开发阶段。软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。

②目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统。

瀑布模型是最早使用的软件生存周期模型之一。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。或者说，每一个阶段都是建立在前一个阶段的正确结果之上，前一个阶段的错误和疏漏会隐蔽地带入后一个阶段。这种错误有时甚至可能是灾难性的，因此每一个阶段工作完成后，都要进行审查和确认。

螺旋模型是在快速原型的基础上扩展而成的。这个模型把整个软件开发流程分成多个阶段，每个阶段都由4部分组成，它们是：

①目标设定。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划。

②风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避 免这些风险。

③开发和有效性验证。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。

④评审。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。

螺旋模型的软件开发过程实际是上述4个部分的迭代过程，每迭代一次，螺旋线就增加一周，软件系统就生成一个新版本，这个新版本实际上是对目标系统的一个逼近。经过若干次的迭代后，系统应该尽快地收敛到用户允许或可以接受的目标范围内，否则也可能中途夭折。

V模型是一种典型的测试模型。在V模型中测试过程被加在开发过程的后半部分，分别包括单元测试、集成测试、系统测试和验收测试。

演化模型主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。演化模型的主要优点是，任何功能一经开发就能进入测试，以便验证是否符合产品需求，可以帮助引导出高质量的产品要求。其主要缺点是，如果不控制地让用户接触开发中尚未稳定的功能，可能对开发人员及永固都会产生负面的影响。

软件生存周期模型又称软件开发模型（software develop model)或软件过程模型 (software process model),它是从某个特定角度提出的软件过程的简化描述。软件生存周期模型主要有瀑布模型、演化模型、原型模型、螺旋模型喷泉模型和基于可重用构件的模型等。

基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。

原型是软件系统的初始版本，用来演示概念并尝试设计选择，通常用来发现更多的问题和可能的解决方案。快速迭代式的原型开发能够有效控制成本，根据原型与最终产品之间的关系，原型开发分为三类：抛弃式原型开发利用原型验证和澄清系统的需求描述，重新构造系统：演化式原型开发逐步改进和细化原型，将原型进化直至产生出目标系统；增量式原型开发在建立软件总体设计的基础上，采用增量开发方法，使原型成为最终系统。

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程成为软件生存周期。一个完整的软件生存周期是以需求为出发点，从提出软件开发计划的那一刻开始，直到软件在实际应用中完全报废为止。软件生存周期的提出了是为了更好地管理、维护和升级软件，其中更大的意义在于管理软件开发的步骤和方法。

按照传统的软件生命周期方法学，可以把软件生命期划分为软件定义、软件开发、软件运行与维护3个阶段。

软件过程（Software Procedure）是指软件生存周期所涉及的一系列相关过程。过程是活动的集合；活动是任务的集合；任务起着把输入进行加工然后输出的作用。活动的执行可以是顺序的、重复的、并行的、嵌套的或者是有条件地引发的。软件过程是指软件整个生命周期，包括需求获取、需求分析、设计、实现、测试、发布和维护的一个过程模型。一个软件过程定义了软件开发中采用的方法，但软件过程还包含该过程中应用的技术方法和自动化工具。过程定义一个框架，为有效交付软件，这个框架必须创建。软件过程构成了软件项管理控制的基础，并且创建了一个环境以便于技术方法的采用、工作产品（模型、文档、报告、表格等）的产生、里程碑的创建、质量的保证、正常变更的正确管理。

软件过程中的活动主要由软件人员来完成，软件活动主要包括软件描述、软件开发、软件有效性验证和软件演化。其中，软件描述定义了软件功能以及使用的限制。

开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处，就是程序开发人员在地域上分布很广。这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。

功用驱动开发方法（Feature Driven Development，FDD）致力于短时的迭代，阶段和可见可用的功能。在FDD中，编程开发人员分成首席程序员和“类”程序员（class owner）两类。

逆向工程与重构工程是目前预防性维护采用的主要技术。所谓软件的逆向工程就是分析已有的程序，寻求比源代码更高级的抽象表现形式。一般认为，凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。逆向工程导出的信息可以分为如下4个抽象层次。

①实现级：包括程序的抽象语法树、符号表等信息。
②结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图等。
③功能级：包括反映程序段功能及程序段之间关系的信息。
④领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。显然，上述信息的抽象级别越高，它与代码的距离就越远，通过逆向工程恢复的难度亦越大，而自动工具支持的可能性相对变小，要求人参与判断和推理的工作增多。

在系统运行过程中，软件需要维护的原因是多样的。根据维护的原因不同，可以将软件维护分为以下4种：
①改正性维护。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程称为改正性维护。
②适应性维护。在使用过程中，外部环境（新的硬、软件配置)、数据环境（数据库、数据格式、数据输入/输出方法、数据存储介质）可能发生变化。为使软件适应这种变化而修改软件的过程称为适用性维护。
③完善性维护。在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动称为完善性维护。
④预防性维护。指预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新)进行设计、编码和测试。

自顶向下方法是一种决策策略。软件开发涉及作什么决策、如何决策和决策顺序等决策问题。

自顶向下方法在任何时刻所作的决定都是当时对整个设计影响最大的那些决定。如果把所有决定分组或者分级，那么决策顺序是首先作最高级的决定，然后依次地作较低级的决定。同级的决定则按照随机的顺序或者按别的方法。一个决策的级别是看它距离要达到的最终目的（因此是软件的实际实现）的远近程度。从问题本身来看，或是由外(用户所见的）向内（系统的实现）看，以距离实现近的决定为低级决定，远的为高级决定。

在这个自顶向下的过程中，一个复杂的问题（任务）被分解成若干个较小较简单的问题（子任务），并且一直继续下去，直到每个小问题（子任务）都简单到能够解决（实现）为止。

自顶向下方法的优点是：
•可为企业或机构的重要决策和任务实现提供信息。
•支持企业信息系统的整体性规划，并对系统的各子系统的协调和通信提供保证。
•方法的实践有利于提高企业人员整体观察问题的能力，从而有利于寻找到改进企业组织的途径。

自顶向下方法的缺点是：
•对系统分析和设计人员的要求较高。
•开发周期长，系统复杂，一般属于一种高成本、大投资的工程。
•对于大系统而言，自上而下的规划对于下层系统的实施往往缺乏约束力，
•从经济角度来看，很难说自顶向下的做法在经济上是合算的。