我今年正在学习软件工程，我对标题中的问题有点困惑。
我的教授和参考文献（“软件工程从业者方法”）都将这三个标题区分为不同的模型。但是，我看不到明显的差异，因为它们的方法对我来说看起来相同，但使用不同的语句来定义它们。
我觉得实际上它们都代表相同的流程模型。
有人可以更好地解释不同的模型吗？
I am studying Software Engineering this year and I am little confused about the question in the title.
Both of my professor and the reference ("Software Engineering A Practitioner Approach") differentiates the three titles as different models. However, I can't see obvious difference as their methodologies look the same to me but using different statements to define them.
I feel that practically they all represent the same process model.
Can anybody explain the different models better?
发布评论
评论（3）
Craig Larman 在这个主题上写了大量文章，我推荐他的著名论文 迭代和增量开发：简史 (PDF) 和他的书 敏捷迭代开发：经理指南。
我的总结如下：
增量开发
增量开发是一种将系统功能分割成增量（小部分）的实践。在每个增量中，通过完成软件开发过程的所有活动（从需求到部署）来交付垂直功能。
在软件开发中，增量开发（添加）经常与迭代开发（重做）一起使用。这称为迭代增量开发 (IID)。
进化方法
汤姆·吉尔布 (Tom Gilb) 在 1976 年出版的《软件度量》一书中引入了术语“进化”和“进化”，他在书中介绍了他的实践 EVO IID（也许是最古老的）。渐进式开发的重点是尽早向利益相关者提供高价值，并获取和利用利益相关者的反馈。
在软件开发：迭代与迭代进化论，克雷格·拉曼 (Craig Larman) 是这样说的：
然后进一步讨论进化需求、进化和适应性规划、进化交付。检查链接。
螺旋模型
螺旋模型是另一种 IID 方法，由 Barry Boehm 在
20 世纪 80 年代中期作为瀑布的延伸，以更好地支持迭代开发，并特别强调风险管理（通过迭代风险分析）。
引用 迭代和增量开发：简史：
现在怎么办？
敏捷方法是 IID 和进化方法的子集，并且是当今的首选方法。
参考文献
Craig Larman wrote extensively on this topic and I suggest his famous paper Iterative and Incremental Development: A Brief History (PDF) and his book Agile and Iterative Development: A Manager's Guide.
Here is how I would summarize things:
Incremental Development
Incremental Development is a practice where the system functionalities are sliced into increments (small portions). In each increment, a vertical slice of functionality is delivered by going through all the activities of the software development process, from the requirements to the deployment.
Incremental Development (adding) is often used together with Iterative Development (redo) in software development. This is referred to as Iterative and Incremental Development (IID).
Evolutionary method
The terms evolution and evolutionary have been introduced by Tom Gilb in his book Software Metrics published in 1976 where he wrote about EVO, his practice of IID (perhaps the oldest). Evolutionary development focuses on early delivery of high value to stakeholders and on obtaining and utilizing feedback from stakeholders.
In Software Development: Iterative & Evolutionary, Craig Larman puts it like this:
And then discusses further evolutionary requirements, evolutionary and adaptive planning, evolutionary delivery. Check the link.
Spiral model
The Spiral Model is another IID approach that has been formalized by Barry Boehm in the
mid-1980s as an extension of the Waterfall to better support iterative development and puts a special emphasis on risk management (through iterative risk analysis).
Quoting Iterative and Incremental Development: A Brief History:
What now?
Agile Methods are a subset of IID and evolutionary methods and are preferred nowadays.
References
这些概念通常很难解释。
增量是工作产品（文档、模型、源代码等）的属性，这意味着它们是一点一点地创建的，而不是一次创建的。例如，您在需求分析期间创建类模型的第一个版本，然后在 UI 建模之后对其进行扩充，然后甚至在详细设计期间对其进行更多扩展。
进化是可交付成果的属性，即交付给用户的工作产品，就这一点而言，它是一种特殊的“增量”。这意味着无论交付什么，它都会尽早以初始形式交付，而不是完全功能化，然后每隔一段时间重新交付一次，每次都具有越来越多的功能。这通常意味着一个迭代生命周期。
[迭代生命周期，但方式，是指您执行的任务（与“增量”相对，“增量”指的是产品；这是 SEMAT），这意味着您一遍又一遍地执行相同类型的任务。例如，在迭代生命周期中，您会发现自己一遍又一遍地进行设计，然后编码，然后单元测试，然后发布，然后再次进行相同的事情。请注意，迭代和增量并不相互暗示；两者的任意组合都是可能的。]
生命周期的螺旋模型是由提出的模型Barry Boehm 将瀑布式的各个方面与迭代方法和内置质量控制等创新进步相结合。
有关“工作产品”、“任务”、“生命周期”等概念，请参见ISO/IEC 24744。
希望这有帮助。
These concepts are usually poorly explained.
Incremental is a property of the work products (documents, models, source code, etc.), and it means that they are created little by little rather than in a single go. For example, you create a first version of your class model during requirements analysis, then augment it after UI modelling, and then you even extend it more during detailed design.
Evolutionary is a property of deliverables, i.e. work products that are delivered to the users, and in this regard it is a particular kind of "incremental". It means that whatever is delivered it is delivered as early as possible in a initial form, not fully functional, and then re-delivered every so often, each time with more and more functionality. This often implies an iterative lifecycle.
[An iterative lifecycle, but the way, refers to the tasks that you carry out (as opposed to "incremental", which refers to the products; this is the view adopted by SEMAT), and it means that you perform tasks of the same type over and over. For example, in an iterative lifecycle you would find yourself doing design, then coding, then unit testing, then release, and then again the same things, over and over. Please note that iterative and incremental do not imply each other; any combination of both is possible.]
The spiral model for lifecycles is a model proposed by Barry Boehm that combines aspects of waterfall with innovative advances such as an iterative approach and built-in quality control.
For the concepts of "work product", "task", "lifecycle", etc. please see ISO/IEC 24744.
Hope this helps.
这是 ISO 24748-1:2016（系统和软件工程生命周期管理）中的 ipsis litteris 定义：
有许多不同的开发策略可以应用于系统和软件项目。其中三种策略总结如下：
a) 一次性。 “一次性”策略也称为“瀑布”，包括执行一次开发过程。简单地说：确定用户需求、定义需求、设计系统、实施系统、测试、修复和交付。
b) 增量式。 “增量”策略确定用户需求并定义系统要求，然后按构建顺序执行其余的开发。第一个构建包含部分计划功能，下一个构建添加更多功能，依此类推，直到系统完成。
c) 进化的。 “进化”策略也在构建中开发系统，但与增量策略的不同之处在于，它承认用户需求尚未完全理解，并且无法预先定义所有需求。在此策略中，用户需求和系统要求是预先部分定义的，然后在每个后续构建中进行细化。
希望这有帮助。塔蒂
This is the ipsis litteris definition from ISO 24748-1:2016 (Systems and Software Engineering Life Cycle Management):
There are many different development strategies that can be applied to system and software projects. Three of these strategies are summarized below:
a) Once-through. The “once-through” strategy, also called “waterfall,” consists of performing the development process a single time. Simplistically: determine user needs, define requirements, design the system, implement the system, test, fix and deliver.
b) Incremental. The “incremental” strategy determines user needs and defines the system requirements, then performs the rest of the development in a sequence of builds. The first build incorporates part of the planned capabilities, the next build adds more capabilities, and so on, until the system is complete.
c) Evolutionary. The “evolutionary” strategy also develops a system in builds but differs from the incremental strategy in acknowledging that the user need is not fully understood and all requirements cannot be defined up front. In this strategy, user needs and system requirements are partially defined up front, and then are refined in each succeeding build.
Hope this helps. Tati