软件方法学是以软件开发方法为研究对象的学科。从开发风范上看，软件方法学可分为自顶向下开发方法和自底向上开发方法。自顶向下开发方法强调开发过程是由问题到解答、由总体到局部、由一般到具体，自底向上开发方法从系统实现的最基础部分着手，由简单到复杂，逐层向上构造，直至得到所需的软件。
从性质上看，软件方法学可分为形式化方法与非形式化方法。形式化方法是建立在严格数学基础上的软件开发方法。在软件开发的各个阶段中，凡是采用严格的数学语言具有精确的数学语义的方法，称为形式化方法。采用形式化方法可避免系统中的歧义性不完全性和不一致性。而非形式化方法则不把严格作为其主要着眼点。
从适用范围上看，软件方法学可分为整体性方法和局部性方法。整体性方法适用于软件开发的全过程，如自顶向下方法、自底向上方法和软件自动化方法等，局部性方法适用于软件开发过程的某个具体阶段，如各种需求分析方法、设计方法等。软件自动化方法是尽可能借助计算机系统实现软件开发的方法。也可狭义地理解为从形式的软件功能规约到可执行的程序代码这一过程的自动化，其实现途径主要有过程途径(过程实现)、演绎途径(演绎综合)、转换途径(程序转换)和归纳途径(归纳综合)等。
净室方法
净室软件工程(净室方法)是软件开发的一种形式化方法，它可以生成高质量的软件。它使用盒结构规约进行分析和设计建模，并且强调将正确性验证(而不是测试)作为发现和消除错误的主要机制，使用统计的测试来获取认证被交付的软件的可靠性所必需的出错率信息。
净室方法从使用盒结构表示的分析和设计模型入手，一个“盒”在某特定的抽象层次上封装系统(或系统的某些方面)。通过逐步求精的过程，盒被精化为层次，其中每个盒具有引用透明性:每个盒规约的信息内容对定义其精华是足够的，不需要信赖于任何其他盒的实现。这使得分析人员能够层次地划分一个系统，从在顶层的本质表示转移向在底层的实现特定的细节。净室方法主要使用如下三种盒类型。
(1)黑盒。这种盒刻划系统或系统的某部分行为。通过运用由激发得到反应的一组变迁规则，系统(或部分) 对特定的激发(事件) 作出反应。
(2)状态盒。这种盒以类似于对象的方式封装状态数据和服务(操作)。在这个规约视图中，表示出状态盒的输入(激发)和输出(反应)。状态盒也表示黑盒“激活历史”即封装在状态盒中的，必须在蕴含的变迁间保留的数据。
(3)清晰盒。在清晰盒中定义状态盒所蕴含的变迁功能，简单地说，清晰盒包含了对状态盒的过程设计。
一旦完成了盒结构设计，则运用正确性验证。软件构件的过程设计被划分为一系列子函数，为了证明每个子函数的正确性，要为每个函数定义出口条件并实施一组子证明。如果每个出口条件均被满足，则设计一定是正确的。
一旦完成了正确性验证，便开始统计的使用测试。和传统测试不同，净室软件工程并不强调单元测试或集成测试，而是通过定义一组使用场景、确定对每个场景的使用概率及定义符合概率的随机测试来进行软件测试(这种活动称为正确性验证)将产生的错误记录和取样、构件和认证模型相结合使得可以数学地计算软件构件的可靠性(这种活动称为基于统计的测试)。
净室方法是一种严格的软件工程方法，它是一种强调正确性的数学验证和软件可靠性认证的软件过程模型，其目标和结果是非常低的出错率，这是使用非形式化方法难于或不可能达到的。
结构化方法
结构化方法属于自顶向下的开发方法，其基本思想是“自顶向下，逐步求精”，强调开发方法的结构合理性及所开发软件的结构合理性。结构是指系统内各个组成要素之间相互联系、相互作用的框架。结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。针对软件生存周期各个不同的阶段，它包括了结构化分析(Structured Analysis，SA)、结构化设计(Structured Design，SD)和结构化程序设计(Structured Programing，SP)等方法。本章后续介绍的分析、设计和测试等内容，都是以结构化方法为基础的。
- 结构化方法的基本原则
为保证系统开发的顺利进行，结构化方法强调遵循以下几个基本原则。
(1)面向用户的观点。在开发过程中，开发人员应该始终与用户保持联系，从调查研究入手，充分理解用户的信息需求和业务活动，不断地让用户了解工作的进展情况，校准工作方向。
(2)严格区分工作阶段，每个阶段有明确的任务和应得的成果
(3)按照系统的观点，自顶向下地完成系统的开发工作。
(4)充分考虑变化的情况。在系统设计中，把系统的可变更性放在首位
(5)工作成果文献化、文档化。
- 结构化分析
SA方法使用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下、逐层分解，直至找到满足功能要求的所有可实现的软件为止。SA方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表及判定树等。
SA方法的步骤如下。
(1)分析当前的情况，做出反映当前物理模型的数据流图(Data Flow Diagram，DFD)。
(2)推导出等价的逻辑模型的 DFD。
(3)设计新的逻辑系统，生成数据字典和基元描述。
(4)建立人机接口，提出可供选择的目标系统物理模型的 DFD。
(5)确定各种方案的成本和风险等级，据此对各种方案进行分析。
(6)选择一种方案。
(7)建立完整的需求规约。
- 结构化设计
SD方法给出一组帮助设计人员在模块层次上区分设计质量的原理与技术。它通常与SA 方法衔接起来使用，以数据流图为基础得到软件的模块结构。SD方法尤其适用于变换型结构和事务型结构的目标系统。在设计过程中，它从整个程序的结构出发，利用模块结构图表述程序模块之间的关系
SD方法的步骤如下。
(1)评审和细化数据流图
(2)确定数据流图的类型
(3)把数据流图映射到软件模块结构，设计出模块结构的上层
(4)基于数据流图逐步分解高层模块，设计中下层模块。
(5)对模块结构进行优化，得到更为合理的软件结构。
(6)描述模块接口。
SD 方法的设计原则如下。
(1)使每个模块执行一个功能(坚持功能性内聚)。
(2)每个模块使用过程语句(或函数方式等)调用其他模块
(3)模块间传送的参数作为数据使用。
(4)模块间共用的信息 (如参数等) 尽量少
- 结构化方法的缺点
结构化方法是目前最成熟、应用较广泛的一种工程化方法。当然，这种方法也有不足和局限性。
(1)开发周期长。一方面使用户在较长的时间内不能得到一个可实际运行的物理系统，另一方面难以适应环境变化。
(2)早期的结构化方法注重系统功能，兼顾数据结构方面不多
(3)结构化程度较低的系统，在开发初期难于锁定功能要求。
这些问题在应用中有的已经解决，同时也产生了其他一些方法，例如原型法、面向对象方法等。
面向对象方法
面向对象方法是当前的主流开发方法,拥有大量不同的方法，主要包括OMT(Obiect Model Technology，对象建模技术)方法、Coad/Yourdon 方法、OOSE (Object-Oriented Software Engineering，面向对象的软件工程)及 Booch 方法等，而OMT、OOSE及Booch最后可统一成为UML(United ModelLanguage，统一建模语言)。
1.Coad/Yourdon 方法
Coad/Yourdon 方法主要由面向对象的分析(Obiect-Oriented Analysis，OOA)和面向对象的设计(Object-Oriented Design，OOD)构成，特别强调OOA和OOD 采用完全一致的概念和表示法，使分析和设计之间不需要表示法的转换。该方法的特点是表示简练、易学，对于对象、结构、服务的认定较系统、完整，可操作性强。
在Coda/Yourdon方法中，00A 的任务主要是建立问题域的分析模型。分析过程和构造 OOA 概念模型的顺序由 5 个层次组成，分别是类与对象层、属性层、服务层、结构层和主题层,它们表示分析的不同侧面。0OA 需要经过5个步骤来完成整个分析工作即标识对象类、标识结构与关联(包括继承、聚合、组合及实例化等)、划分主题、定义属性和定义服务。
OOD中将继续贯穿OOA中的5个层次和5个活动，它由4个部分组成，分别是人机交互部件、问题域部件、任务管理部件和数据管理部件，其主要的活动就是这4个部件的设计工作。
2.Booch 方法
Booch 认为软件开发是一个螺旋上升的过程，每个周期包括4 个步骤，分别是标识类和对象、确定类和对象的含义、标识关系、说明每个类的接口和实现。Booch 方法的开发模型包括静态模型和动态模型，静态模型分为逻辑模型(类图、对象图)和物理模型(模块图、进程图)，描述了系统的构成和结构。动态模型包括状态图和时序图。该方法对每一步都做了详细的描述，描述手段丰富而灵活。
Booch 不仅建立了开发方法，还提出了设计人员的技术要求以及不同开发阶段的人力资源配置。Booch 方法的基本模型包括类图与对象图，主张在分析和设计中既使用类图，也使用对象图。
- OMT 方法
OMT作为一种软件工程方法学，支持整个软件生存周期，覆盖了问题构成、分析设计和实现等阶段。OMT 方法使用了建模的思想，讨论如何建立一个实际的应用模型从三个不同而又相关的角度建立了三类模型，分别是对象模型、动态模型和函数模型。OMT为每一个模型提供了图形表示。
(1)对象模型。描述系统中对象的静态结构、对象之间的关系、属性和操作。它表示静态的、结构上的、系统的“数据”特征。主要用对象图来实现对象模型。
(2)动态模型。描述与时间和操作顺序有关的系统特征，如激发事件、事件序列、确定事件先后关系的状态。它表示瞬时、行为上的和系统的“控制”特征。主要用状态图来实现动态模型
(3)功能模型。描述与值的变换有关的系统特征，包括功能、映射、约束和函数依赖。主要用数据流图来实现。
功能模型在进行 OMT 建模时，通常包括 4 个活动，分别是分析、系统设计、对象设计和实现。
(1)分析。建立可理解的现实世界模型。通常从问题陈述入手，通过与客户的不断交互及对现实世界背景知识的了解，对能够反映系统的三个本质特征 (对象类及它们之间的关系，动态的控制流，受约束的数据的函数变换) 进行分析，构造出现实世界的模型。
(2)系统设计。确定整个系统的架构，形成求解问题和建立解答的高层策略
(3)对象设计。在分析的基础上，建立基于分析模型的设计模型，并考虑实现细节其焦点是实现每个类的数据结构及所需的算法。
(4)实现。将对象设计阶段开发的对象类及其关系转换为程序设计语言、数据库或硬件的实现。
4.OOSE
OOSE在OMT的基础上对功能模型进行了补充，提出了用例(use case)的概念，最终取代了数据流图来进行需求分析和建立功能模型。OOSE 方法采用5类模型来建立目标系统。
(1)需求模型。获取用户的需求，识别对象，主要的描述手段有用例图、问题域对象模型及用户界面
(2)分析模型。定义系统的基本结构。将分析模型中的对象分别识别到分析模型中的实体对象、界面对象和控制对象三类对象中。每类对象都有自己的任务、目标并模拟系统的某个方面。实体对象模拟那些在系统中需要长期保存并加以处理的信息。实体对象由使用事件确定，通常与现实生活中的一些概念相符合。界面对象的任务是提供用户与系统之间的双向通信，在使用事件中所指定的所有功能都直接依赖于系统环境，它们都放在界面对象中。控制对象的典型作用是将另外一些对象组合形成一个事件。
(3)设计模型。分析模型只注重系统的逻辑构造，而设计模型需要考虑具体的运行环境，即将分析模型中的对象定义为模块。
(4)实现模型。用面向对象的语言来实现。
(5)测试模型。测试的重要依据是需求模型和分析模型，测试模型实际上是一个测试报告。OOSE 的开发活动主要分为三类，分别是分析、构造和测试。其中分析过程分为需求分析和健壮性分析两个子过程，分析活动分别产生需求模型和分析模型。构造活动包括设计和实现两个子过程，分别产生设计模型和实现模型。测试过程包括单元测试、集成测试和系统测试三个过程，共同产生测试模型。
用例是OOSE 中的重要概念，在开发各种模型时，它是贯穿OOSE 活动的核心，描述了系统的需求及功能。用例实际上是描述系统用户(使用者、执行者)对于系统的使用情况，是从使用者的角度来确定系统的功能。因此，首先必须分析确定系统的使用者然后进一步考虑使用者的主要任务、使用的方式、识别所使用的事件，即用例。
原型法
结构化方法和面向对象方法有一个共同点:在系统开发初期必须明确系统的功能要确定系统边界。从工程学角度来看，这是十分自然的:解决问题之前必须明确系统功能的要解决的问题是什么，然而对于信息系统建设而言，明确问题本身不是一件轻松的事情。通常，原型是指模拟某种产品的原始模型。在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求，使得用户可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价，然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。
- 原型的分类
软件原型是所提出的新产品的部分实现，建立原型的主要目的是为了解决在产品开发早期阶段需求不确定的问题，明确并完善需求、探索设计选择方案、发展为最终的产品。
原型有很多种方法。从原型是否实现功能来分，软件原型可分为水平原型和垂直原型两种。水平原型也称为行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能的导航，但并未真实实现功能。水平原型主要用在界面上。垂直原型也称为结构化原型，实现了一部分功能。垂直原型主要用在复杂的算法实现上。从原型的最终结果来分，软件原型可分为抛弃型原型和演化型原型。抛弃型原型也称为探索型原型，是指达到预期目的后，原型本身被抛弃。抛弃型原型主要用于解决需求不确定性、二义性、不完整性和含糊性等。演化型原型为开发增量式产品提供基础，是螺旋模型的一部分，也是面向对象软件开发过程的一部分。演化型原型主要用于必须易于升级和优化，适用于 Web 的项目。
有些文献把原型分为实验型、探索型和演化型。探索型原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性，实验型原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠;进化型原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
还有些文献也把原型分为抛弃式原型、演化式原型和递增式原型。
2.原型类型的选择
如果是在需求分析阶段要使用原型化方法，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型化方法。
(1)系统结构。联机事务处理系统，相互关联的应用系统适合于用原型化方法，而批处理、批修改等结构不适宜用原型化方法。
(2)逻辑结构。有结构的系统，如操作支持系统、管理信息系统和记录管理系统等适于用原型化方法，而基于大量算法的系统不适宜用原型化方法。
(3)用户特征。不满足于预先做系统定义说明，愿意为定义和修改原型投资，不易肯定详细需求，愿意承担决策的责任，准备积极参与的用户是适合使用原型的用户。
(4) 应用约束。对已经运行系统的补充，不能用原型化方法。
(5)项目管理。只有项目负责人愿意使用原型化方法，才适于用原型化的方法
(6)项目环境。需求说明技术应当根据每个项目的实际环境来选择。
当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。特别是当性能要求比较高时，在系统原型上先做一些试验也是很必要的。
- 原型生存期
原型的开发和使用过程叫做原型生存期。图a是原型生存期的模型，图 b型的细化。
(1)快速分析。在分析者和用户的紧密配合下，快速确定软件系统的基本要求。(2)构造原型。在快速分析基础上，根据基本需求尽快实现一个可运行的系统。构造原型时要注意两个基本原则，即集成原则(尽可能用现有软件和模型来构成，这需要相应的原型工具)和最小系统原则(耗资一般不超过总投资的 10%)。
(3)运行和评价原型。用户在开发者指导下试用原型，在试用的过程中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明描述是否满足用户愿望。
(4)修正和改进。根据修改意见进行修改。如果用修改原型的过程代替快速分析就形成了原型开发的迭代过程。开发者和用户在一次次的迭代过程中不断将原型完善以接近系统的最终要求。
(5)判定原型完成。如果经过修改或改进的原型，达到参与者一致认可，则原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，迭代周期是否可以结束等。判定的结果有两个不同的转向，一是继续迭代验证，二是进行详细说明。
(6)判断原型细部是否说明。判断组成原型的细部是否需要严格地加以说明。原型化方法允许对系统必要成分或不能通过模型进行说明的成分进行严格的和详细的说明。
(7)原型细部的说明。对于那些不能通过原型说明的所有项目，仍需通过文件加以说明。严格说明的成分要作为原型化方法的模型编入词典。
(8)判定原型效果。考查用户新加入的需求信息和细部说明信息，看其对模型效果有什么影响?是否会影响模块的有效性?如果模型效果受到影响，甚至导致模型失效则要进行修正和改进
(9)整理原型和提供文档。
总之，利用原型化技术，可为软件的开发提供一种完整的、灵活的、近似动态的规格说明方法。
4.原型开发技术
通常用于构造原型的技术包括可执行规格说明、基于场景的设计、自动程序设计、专用语言、可复用的软件构件、简化假设和面向对象技术等。其中前三种还适用于用户界面的设计。
(1)可执行规格说明。可执行规格说明是用于需求规格说明的一种自动化技术。可执行规格说明语言可描述系统要“做什么”，但它并不描述系统要“怎样做”。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。可执行规格说明包括形式化规格说明、有限状态模型和可执行的数据流图。
(2)基于场景的设计。一个场景可模拟在系统运行期间用户经历的事件。由于它提供了输入一处理一输出的屏幕格式和有关对话的模型，因此，场景能够为用户显示系统的逼真视图，使用户得以判断是否符合他的意图。
(3)自动程序设计。自动程序设计是可执行规格说明的替身，主要是指在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程性问题规格说明转换为某种高级语言程序。
(4)专用语言。专用语言是应用领域的模型化语言。在原型开发中使用专用语言可方便用户和软件开发者在计划中的系统特性方面的交流。
(5)软件复用技术。软件复用技术可分为两大类:合成技术和生成技术。
①合成技术。可复用的软件构件可以是对某一函数、过程、子程序、数据类型算法等可复用软件成分的抽象，利用这些构件来构造软件系统。用构件合成较大的构件有三种方式:连接;消息传递和继承;管道机制。
② 生成技术。利用可复用的模式，通过生成程序产生一个新的程序或程序段，产生的程序可以看做是模式的实例。可复用的模式有两种不同的形式:代码模式和规则模式。前者的例子是应用生成器，可复用的代码模式就存在于生成器自身。通过特定的参数替换，生成抽象软件模块的具体实体。后者的例子是变换系统，它通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，利用程序变换系统(有时要经过一系列的变换)，把用超高级规格说明语言编写的程序转化成某种可执行语言的程序。
(6)简化假设。简化假设是在开发过程中使设计者迅速得到一个简化的系统所做的假设。尽管这些假设可能实际上并不能成立，但它们在原型开发过程中可以使开发者的注意力集中在一些主要的方面。
(7)面向对象技术。通常是指 OO程序设计语言和面向对象的数据库等有关分析与设计技术的综合。使用 OO技术，可以把现实世界中已存在的问题与实体，都采用对象去构成，能更好地体现出自然性、模块化、共享特性、并发特性、继承性、封装隐蔽性与可重用性等一系列功能化要求。如果能把 OO数据库和OO 程序设计语言等技术用于可重用的构件与原型语言，并且在其中体现出一致的“对象模型”本质，那么就会有可能去统一“重用构件库”语言与原型化语言等。
原型法适合于用户需求不明确的场合。它是先根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型。在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，缩短了开发周期，降低了开发风险，最终的结果是更适合用户的要求。原型法成败的关键及效率的高低，在于模型的建立及建模的速度。
逆向工程
随着维护次数的增加，可能会造成软件结构的混乱，使软件的可维护性降低，束缚了新软件的开发。同时，那些待维护的软件又常是业务的关键，不可能废弃或重新开发。于是引出了软件再工程(reengineering)，即需要对旧的软件进行重新处理、调整，提高其可维护性。
- 再工程
再工程是对现有软件系统的重新开发过程，包括逆向工程(ReverseEngineering，反向工程)、新需求的考虑(软件重构)和正向工程三个步骤。再工程不仅能从已有的程序中重新获得设计信息，而且还能使用这些信息改建或重构现有的系统，以改进它的综合质量。一般，软件人员利用再工程重新实现已存在的程序，同时加进新的功能或改善它的性能。
软件再工程旨在对现存的大量软件系统进行挖掘、整理以得到有用的软件构件，或对已有软件构件进行维护以延长其生存期。它是一个工程过程，能够将逆向工程、重构和正向工程组合起来，将现存系统重新构造为新的形式。
再工程的基础是系统理解，包括对运行系统、源代码、设计、分析和文档等的全面理解。但在很多情况下，由于各类文档的丢失，只能对源代码进行理解，即程序理解。
2.软件重构
软件重构是对源代码、数据进行修改，使其易于修改和维护，以适应将来的变更通常软件重构并不修改软件体系结构，而是关注模块的细节。
(1)代码重构。代码重构的目标是生成可提供功能相同，而质量更高的程序。由于需要重构的模块通常难以理解、测试和维护，因此，首先用重构工具分析代码，标注出需要重构的部分，然后进行重构，复审和测试重构后的代码，更新代码的内部文档。
(2)数据重构。发生在较低的抽象层次上，是一种全局的再工程活动。数据重构通常以逆向工程活动开始，理解现存的数据结构，又称数据分析，再重新设计数据，包括数据标准化、数据命名合理、文件格式转换和数据库格式转换等。
软件重构的意义在于提高软件质量和生产率，减少维护工作量，提高软件可维护性
- 逆向工程
逆向工程是分析程序，力图在比源代码更高的抽象层次上建立程序表示的过程。逆向工程是一个设计恢复的过程，其工具可以从已有的程序中抽取数据结构、体系结构和程序设计信息。
逆向工程过程及用于实现该过程的工具的抽象层次是指可从源代码中抽取出来的设计信息的精密程度。理想地，抽象层次应该尽可能高，即逆向工程过程应该能够导出过程的设计表示(一种低层的抽象)、序和数据结构信息(稍高一点层次的抽象)、数据和控制流模型(一种相对高层的抽象)，以及实体关系模型(一种高层抽象)。随着抽象层次增高，软件工程师获得更有助于理解程序的信息。
逆向工程过程的完整性是指在某抽象层次提供的细节程度。在大多数情况，随着抽象层次增高，完整性就降低。例如，给定源代码列表，得到一个完整的过程设计表示是相对容易的，简单的数据流表示也可被导出，但是，要得到数据流图或状态一变迁图的完整集合却困难得多。