介绍
在软件工程中，软件开发方法（也称为系统开发方法，软件开发生命周期，软件开发过程，软件过程）是将软件开发工作划分为包含旨在更好的活动的不同阶段（或阶段）。规划和管理。它通常被认为是系统开发生命周期的一个子集。该方法可以包括由项目团队创建和完成以开发或维护应用程序的特定可交付物和工件的预定义。
常用方法包括瀑布式，原型设计，迭代和增量开发，螺旋式开发，快速应用程序开发，极限编程和各种类型的敏捷方法。有些人认为生命周期“模型”是一类方法论的更通用术语，而软件开发“过程”则是一个更具体的术语，指的是特定组织选择的特定过程。例如，有许多特定的软件开发过程适合螺旋生命周期模型。
420px-Three_software_development_patterns_mashed_together.svg.png
这三种基本方法适用于软件开发方法框架。
多年来，各种这样的框架都在不断发展，每个框架都有自己公认的优点和缺点。一个软件开发方法框架不一定适合所有项目使用。根据各种技术，组织，项目和团队考虑因素，每个可用的方法框架最适合特定类型的项目。
软件开发组织实施流程方法以简化开发过程。有时，承包商可能需要采用的方法，例如美国国防工业，需要基于流程模型的评级来获得合同。描述选择，实施和监控软件生命周期的方法的国际标准是ISO / IEC 12207。
长达数十年的目标是找到可重复，可预测的流程，以提高生产力和质量。有些人试图将看似不守规矩的软件设计系统化或形式化。其他人将项目管理技术应用于设计软件。如果没有有效的项目管理，软件项目可以很容易地延迟交付或超出预算。由于大量软件项目在功能，成本或交付时间表方面无法满足他们的期望，因此缺乏有效的项目管理。
组织可以创建软件工程过程组（SEPG），这是过程改进的焦点。由具有不同技能的线路从业者组成，该团队是组织中参与软件工程过程改进的每个人的协作努力的中心。
特定开发团队也可能同意编程环境细节，例如使用哪个集成开发环境，以及一个或多个主要编程范例，编程样式规则或特定软件库或软件框架的选择。这些细节通常不是由模型选择或一般方法决定的。
历史
软件开发方法（也称为SDM）框架直到20世纪60年代才出现。根据Elliott（2004），系统开发生命周期（SDLC）可被视为建筑信息系统最古老的形式化方法框架。SDLC的主要思想是“以非常慎重，有条理和有条理的方式开发信息系统，要求从概念开始到最终系统交付的生命周期的每个阶段，严格执行并且顺序地“在所应用的框架的范围内。该方法框架在20世纪60年代的主要目标是“在大型企业集团的时代发展大规模的功能性业务系统。
方法，流程和框架包括可由组织在日常工作中直接使用的特定禁止性步骤，以及组织用于生成根据特定项目的需求定制的自定义步骤的灵活框架。组。在某些情况下，“赞助商”或“维护”组织分发描述该过程的官方文档集。具体例子包括：
20世纪70年代
自1969年以来的结构化编程
Cap Gemini SDM，最初来自PANDATA，第一个英文译本于1974年出版.SDM代表系统开发方法论
20世纪80年代
结构系统分析和设计方法（SSADM）从1980年开始
信息需求分析/软系统方法
20世纪90年代
面向对象编程（OOP）是在20世纪60年代早期开发的，并在20世纪90年代中期成为一种主导的编程方法
快速应用程序开发（RAD），自1991年以来
动态系统开发方法（DSDM），自1994年以来
Scrum，自1995年以来
团队软件过程，自1998年以来
Rational Unified Process（RUP），自1998年以来由IBM维护
极限编程，自1999年以来
2000年
Agile Unified Process（AUP）自2005年起由Scott Ambler维护
途径
自信息技术的起源以来，已经使用了几种软件开发方法，分为两大类。通常，管理层或开发团队选择方法或方法的组合。
具有不同阶段的“传统”方法（例如瀑布）有时被称为软件开发生命周期（SDLC）方法，尽管该术语也可以更普遍地用于指代任何方法。具有不同阶段的“生命周期”方法与定义迭代过程的敏捷方法形成对比，但是不同部分的设计，构造和部署可以同时发生。
瀑布开发
220px-Waterfall_model.svg.png
瀑布模型中表示的软件开发过程的活动。还有其他几种模型来表示此过程。
瀑布模型是一种顺序开发方法，其中开发被视为通过几个阶段稳步向下流动（如瀑布），通常：
需求分析导致软件需求规范
软件设计
履行
测试
集成，如果有多个子系统
部署（或安装）
保养
该方法的第一个正式描述通常被引用为Winston W. Royce在1970年发表的一篇文章，尽管Royce在本文中没有使用术语“瀑布”。基本原则是：
项目分为连续阶段，阶段之间可以接受一些重叠和回弹。
重点是一次性规划，时间表，目标日期，预算和整个系统的实施。
通过广泛的书面文档，正式审核以及用户的批准/签收以及在开始下一阶段之前的大多数阶段结束时发生的信息技术管理，可以在项目的整个生命周期内保持严格的控制。
瀑布模型是一种应用于软件工程的传统工程方法。严格的瀑布式方法一旦完成，就不鼓励重新审视和修改任何先前阶段。纯瀑布模型中的这种“缺乏灵活性”一直是其他更“灵活”模型的支持者的批评来源。它被广泛归咎于几个大规模的政府项目超过预算，随着时间的推移，有时由于大设计前端方法而无法满足要求。除了合同要求之外，瀑布模型已经在很大程度上被专为软件开发开发的更灵活和通用的方法所取代。见瀑布模型的批评。
瀑布模型通常也会在每个星期一的黑暗中演奏助记“A Dance in the Dark”，分别代表分析，设计，实施，测试，文档和执行以及维护。
原型
软件原型设计是软件开发过程中活动的开发方法，原型的创建，即正在开发的软件程序的不完整版本。
基本原则是：
不是一个独立的，完整的开发方法，而是一种处理更大，更传统的开发方法（即增量，螺旋或快速应用程序开发（RAD））的选定部分的方法。
尝试通过将项目分成更小的部分来减少固有的项目风险，并在开发过程中提供更多的易于更改的能力。
用户参与整个开发过程，这增加了用户接受最终实现的可能性。
在迭代修改过程之后开发系统的小规模模型，直到原型发展以满足用户的要求。
虽然大多数原型是在期望它们被丢弃的情况下开发的，但在某些情况下可能会从原型系统发展到工作系统。
必须对基本业务问题有基本的了解，以避免解决错误的问题。
增量发展
可以采用各种方法来组合线性和迭代系统开发方法，每个方法的主要目的是通过将项目分成更小的部分来减少项目的固有风险，并在开发过程中提供更多的易于改变。
基本原则是：
执行一系列迷你瀑布，其中瀑布的所有阶段都在系统的一小部分完成，然后继续下一个增量，或者
在进行系统的单个增量的演化，迷你瀑布开发之前定义总体要求，或者
最初的软件概念，需求分析以及体系结构和系统核心的设计都是通过瀑布定义的，然后是迭代原型，最终安装最终原型，一个工作系统。
迭代和增量开发
迭代开发 规定构建软件项目最初较小但却越来越大的部分，以帮助所有相关人员在问题或错误假设可能导致灾难之前尽早发现重要问题。
螺旋发展
400px-Spiral_model_Boehm_1988.svg.png
螺旋模型（Boehm，1988）
1988年，Barry Boehm发布了正式的软件系统开发“螺旋模型”，它结合了瀑布模型的一些关键方面和快速原型方法，以结合自上而下和自下而上概念的优势。它强调了许多人认为被其他方法忽视的关键领域：有意识的迭代风险分析，特别适用于大规模复杂系统。
基本原则是：
重点是风险评估和通过将项目分成较小的部分来最小化项目风险，并在开发过程中提供更多的易变性，以及提供评估风险和在整个生命周期中考虑项目延续的机会。
“每个周期都涉及通过相同的步骤顺序，对于产品的每个部分以及每个层次的细化，从整体操作概念文档到每个单独程序的编码。”
围绕螺旋的每次行程都遍历四个基本象限：（1）确定迭代的目标，备选方案和约束; （2）评估替代方案; 识别并解决风险; （3）从迭代中开发和验证可交付成果; （4）计划下一次迭代。
开始每个周期，确定利益相关者及其“胜利条件”，并通过审查和承诺结束每个周期。
快速应用开发
220px-RADModel.JPG
快速应用程序开发（RAD）模型
快速应用程序开发（RAD）是一种软件开发方法，它有利于迭代开发和原型的快速构建，而不是大量的前期规划。使用RAD开发的软件的“规划”与编写软件本身是交错的。缺乏广泛的预先规划通常可以更快地编写软件，并且更容易更改需求。
快速开发过程始于使用结构化技术开发初步数据模型和业务流程模型。在下一阶段，使用原型设计验证需求，最终完善数据和流程模型。这些阶段反复重复; 进一步发展导致“用于构建新系统的综合业务要求和技术设计声明”。
该术语最初用于描述James Martin在1991年引入的软件开发过程。根据Whitten（2003）的说法，它将各种结构化技术（尤其是数据驱动的信息工程）与原型技术相结合，以加速软件系统的开发。
快速应用程序开发的基本原则是：
主要目标是以相对较低的投资成本快速开发和交付高质量系统。
尝试通过将项目分成更小的部分来减少固有的项目风险，并在开发过程中提供更多的易于更改的能力。
旨在快速生成高质量系统，主要通过迭代原型设计（在任何开发阶段），积极的用户参与和计算机化的开发工具。这些工具可能包括图形用户界面（GUI）构建器，计算机辅助软件工程（CASE）工具，数据库管理系统（DBMS），第四代编程语言，代码生成器和面向对象技术。
重点是满足业务需求，而技术或工程卓越则不太重要。
项目控制涉及优先开发和定义交付期限或“时间框”。如果项目开始下滑，重点是减少适应时间框的要求，而不是增加截止日期。
通常包括联合应用程序设计（JAD），用户通过在结构化研讨会中建立共识或以电子方式促进交互，积极参与系统设计。
积极的用户参与势在必行。
迭代生产生产软件，而不是一次性原型。
生成必要的文档，以促进未来的开发和维护。
标准系统分析和设计方法可以适用于该框架。
敏捷开发
“敏捷软件开发”是指一组基于迭代开发的软件开发方法，其中需求和解决方案通过自组织跨职能团队之间的协作发展。该术语是在2001年制定敏捷宣言时创造的。
敏捷软件开发使用迭代开发作为基础，但提倡比传统方法更轻松，更以人为中心的观点。敏捷流程从根本上结合了迭代和持续反馈，它提供了连续改进和交付软件系统。
有许多敏捷方法，包括：
动态系统开发方法（DSDM）
看板
争球
代码和修复
由于对软件开发人员的日程压力，“代码和修复”开发并不是一个深思熟虑的策略。 在没有太多设计的情况下，程序员立即开始生成代码。在某些时候，测试开始（通常在开发周期的后期），然后在产品发货之前修复不可避免的bug。没有计划外设计的编程也称为牛仔编码。
轻量级方法
轻量级方法具有少量规则。其中一些方法也被认为是“敏捷的”。
Jim Highsmith的自适应软件开发，在其1999年的自适应软件开发一书中有所描述
Alistair Cockburn的Crystal Clear系列方法，
极限编程（XP），由Kent Beck和Martin Fowler等人推动。在极端编程中，与较旧的“批量”过程相比，阶段以极小（或“连续”）步骤执行。（故意不完整）首次通过这些步骤可能需要一天或一周，而不是瀑布模型中每个完整步骤的月份或年份。首先，编写自动化测试，为开发提供具体目标。接下来是编码（由成对工作的程序员，称为“结对编程”的技术），当所有测试都通过时完成，程序员无法想到任何需要的测试。设计和体系结构来自重构，并在编码之后出现。进行编码的人也做设计。（只有最后一个功能 - 合并设计和代码 - 很常见所有其他敏捷过程。）为用户（某些子集）用户（至少其中一个用户在开发团队中）部署或演示了不完整但功能强大的系统。此时，从业者再次开始为系统的下一个最重要的部分编写测试。
由Jeff De Luca和Peter Coad开发的功能驱动开发（FDD）（1999）
基于ICONIX-UML的对象建模，使用案例，是Rational Unified Process的轻量级前身
其他
其他高级软件项目方法包括：
混沌模型 - 主要规则始终首先解决最重要的问题。
增量供资方法 - 一种迭代方法
结构化系统分析和设计方法 - 瀑布的特定版本
慢速编程作为较大的慢速运动的一部分，强调在没有（或极少）时间压力的情况下进行细致而渐进的工作。缓慢的编程旨在避免错误和过快的发布计划。
V-Model（软件开发） - 瀑布模型的扩展
Unified Process（UP）是一种基于统一建模语言（UML）的迭代软件开发方法框架。UP将软件开发分为四个阶段，每个阶段包括在开发阶段的一个或多个软件的可执行迭代：开始，详细说明，构建和指南。存在许多工具和产品以促进UP实施。UP的一个比较流行的版本是统一流程（RUP）。
处理元模型
一些“过程模型”是用于评估，比较和改进组织采用的特定过程的抽象描述。
ISO / IEC 12207是描述选择，实施和监控软件生命周期的方法的国际标准。
能力成熟度模型集成（CMMI）是领先的模型之一，并基于最佳实践。独立评估会对组织如何遵循其定义的流程进行评级，而不是根据这些流程的质量或所生成的软件进行评估。CMMI取代了CMM。
ISO 9000描述了正式组织的制造产品的过程的标准以及管理和监控进度的方法。虽然该标准最初是为制造业创建的，但ISO 9000标准也已应用于软件开发。与CMMI一样，ISO 9000认证并不能保证最终结果的质量，只能遵循正式的业务流程。
ISO / IEC 15504 信息技术 - 过程评估也称为软件过程改进能力确定（SPICE），是一种“评估软件过程的框架”。该标准旨在为过程比较设定一个清晰的模型。SPICE与CMMI非常相似。它模拟了管理，控制，指导和监控软件开发的流程。然后，该模型用于衡量开发组织或项目团队在软件开发过程中实际执行的操作。分析此信息以识别弱点并推动改进。它还确定了可以继续或整合到该组织或团队的通用实践中的优势。
软系统方法 - 改进管理过程的一般方法
方法工程 - 改进信息系统过程的一般方法
正式方法
形式方法是在需求，规范和设计级别解决软件（和硬件）问题的数学方法。正式方法最有可能应用于安全关键或安全关键型软件和系统，例如航空电子软件。软件安全保障标准，如DO-178B，DO-178C和通用标准，要求在最高级别的分类中采用正式方法。
对于顺序软件，形式方法的示例包括B方法，自动定理证明中使用的规范语言，RAISE和Z表示法。
随着对象约束语言（以及Java建模语言等专业化）的应用，特别是模型驱动的体系结构允许执行设计（如果不是规范），软件开发的形式化也在不断涌现。
对于并发软件和系统，Petri网，进程代数和有限状态机（基于自动机理论 - 参见虚拟有限状态机或事件驱动的有限状态机）允许可执行软件规范，可用于构建和验证应用行为。
软件开发的另一个新兴趋势是以某种形式的逻辑编写规范 - 通常是一阶逻辑（FOL）的变体 - 然后直接执行逻辑，就像它是一个程序一样。基于描述逻辑（DL）的OWL语言就是一个例子。还有一些工作可以将某些版本的英语（或其他自然语言）自动映射到逻辑和从逻辑中映射，并直接执行逻辑。例如Attempto Controlled English和Internet Business Logic，它们不寻求控制词汇或语法。支持双向英语逻辑映射和直接执行逻辑的系统的一个特征是，它们可以用英语在商业或科学层面解释它们的结果。
文章来源：http://www.kmyunruan.com
