软件开发 迭代-迭代开发管理

软件测试工作与软件开发模型密切相关。 在不同的软件开发模型中，测试的任务和功能是不同的。 因此，测试人员必须充分了解软件开发模型，才能在其中找到自己的定位和任务。 软件开发模型规定了软件开发应遵循的步骤。 它是软件开发的导航图。 它能清晰、直观地表达软件开发的全过程，以及每个阶段要进行的活动和任务。 开发者在选择开发模式时，应根据软件的特点和开发者参与的方式，选择稳定可靠的开发模式。 软件开发以来，软件开发模式从最初的“边做边修改”发展为多种模式。 下面按照软件开发模型的发展历史顺序介绍几种典型的开发模型。

1.瀑布模型

瀑布模型是WW Royce在1970年提出的一种软件开发模型软件开发 迭代，从模型的名称可以看出，该模型遵循的是一次从上到下完成整个软件产品的开发方法。 瀑布模型将软件开发过程分为六个阶段。 ：规划→需求分析→软件设计→编码→测试→运维，开发流程如图1-1所示。

图 1-1 瀑布模型

在瀑布模型中，软件开发的活动严格按照这条线进行，只有完成一个阶段的任务才能开始下一阶段。 软件开发的每个阶段都必须产生结果。 结果审核通过后，将作为下一阶段的输入，以便下一阶段顺利进行。 如果结果审核验证不通过，需要返回修改。

瀑布模型为整个项目划分了一个明确的检查点。 当一个阶段完成后，你只需要将所有的精力放在后续的开发上。 有利于大型软件开发人员的组织管理和工具的使用和研究。 提高开发效率。

但是瀑布模型是严格按照线性方式进行的，不能适应用户需求的变化。 用户只能看到最后的开发成果，增加了开发风险。 如果开发人员与客户之间对需求的理解存在偏差，最终开发完成后，最终的结果可能与客户的需求相去甚远。 在使用瀑布模型开发软件时，如果在项目完成后才发现早期犯下的错误，这时纠正原来的错误成本会很高。 瀑布模型要求每个阶段都要有一个结果输出，这样必然会增加文档的数量，增加软件开发的工作量。

另外，对于现代软件来说，软件开发阶段之间的关系大多不会是线性的，很难用瀑布模型来开发软件。 因此，瀑布模型已经不适合现代软件开发，逐渐被抛弃。

2.快速成型模型

快速原型模型与瀑布模型正好相反。 它在初步确定用户需求时，快速构建可操作的软件原型。 该软件原型向用户展示了将要开发的软件的全部或部分功能和性能，并由客户对原型进行评审和评价。 ，然后给出更具体的需求意见，让需求逐渐丰富和细化，最终开发者和客户达成最终共识，确定客户真正的需求。 在确定了客户的真正需求之后，实际的软件开发就开始了。

快速成型模型类似于盖房子。 确定客户对房屋的需求后，快速搭建房屋模型，客户对房屋模型进行评价。 房子的风格、功能、布局等是否符合需求，还有哪些地方需要改进等，最终确定客户对房子的要求，开始实际建造房子。 模型的开发过程如图1-2所示。

图 1-2 快速原型模型

与瀑布模型相比，快速原型模型克服了需求不明确带来的风险，适用于无法事先确定需求的软件项目。 然而，快速原型模型的关键在于快速构建软件原型，而准确设计软件原型难度较大。 另外，这种开发模式也不利于开发者对产品进行扩展。

4.迭代模型

迭代模型也称为增量模型或进化模型。 它将一个完整的软件拆分成不同的组件，然后对各个组件进行开发和测试。 每完成一个组件软件开发 迭代，就呈现给客户，让客户确认组件的功能和性能。 是否满足客户的要求，最终确认无误，将组件集成到软件架构中。 整个开发工作被组织成一系列短期的、简单的小项目，称为一系列迭代，每次迭代都需要经历需求分析→软件设计→编码→测试的过程。 开发流程如图1-3所示。

图 1-3 迭代模型

在迭代模型中，第一次迭代（即第一个组件）往往是基本软件需求的核心部分。 第一个组件完成后，经过客户评审和评估，形成下一个组件的开发计划，包括核心产品的修改。 以及新功能的发布，不断重复迭代的步骤，直到实现最终的完美产品。

迭代模型可以很好地适应客户需求的变化。 它逐个组件地交付产品。 客户经常可以看到产品。 如果一个组件不满足客户需求，只需要改变这个组件，降低软件开发的成本和风险。 . 但生成模型需要将开发的组件集成到软件架构中，这可能会带来集成失败的风险，因此软件必须具有开放的架构。 此外，迭代模型逐个组件地开发和修改，很容易退化为“边做边修改”的开发形式，从而失去对软件开发过程的整体控制。

4.螺旋模型

螺旋模型由Barry Boehm于1988年提出，该模型结合了瀑布模型和快速原型模型。 它最大的特点是引入了其他模型忽略的风险分析。 如果项目不能排除重大风险，则停止项目以减少损失。 这种模式更适合开发复杂的大型软件。

螺旋模型将整个项目开发过程分为几个不同的阶段，每个阶段都按部就班地执行。 这种划分方法采用瀑布模型。 在每个阶段开始之前，必须进行风险评估。 如能消除重大风险，即可启动本阶段任务。 在每个阶段，首先构建一个软件原型，按照快速原型模型完成这个迭代过程，生产出最终完美的产品，然后进入下一阶段，同样在下一阶段之前进行风险评估，以此类推，直到都完成了。 阶段任务。 螺旋模型的几个阶段是沿着螺旋的方式进行的，如图1-4所示。

图 1-4 螺旋模型

图 1-4 有四个象限：计划、风险分析、项目实施和客户评估。 各象限的含义如下。

(1)制定计划：确定软件目标，制定实施计划，列出项目开发的约束条件。

（2）风险分析：对制定的实施方案进行评价，识别风险，消除风险。

(3) 实施工程：开发产品并验证

(4)客户评价：客户对产品进行审查评价，提出整改建议，制定下一步计划。

在螺旋模型中，每一代都需要经过这4个步骤，直到最终得到一个完美的产品，可以提交。

螺旋模型强调风险分析，即评估选项和约束条件，更有利于将软件质量作为一个特殊目标纳入产品开发。 将大型软件分小段构建，成本计算简单易行，客户始终参与每个阶段的开发，保证项目不偏离正确的方向，也保证了项目的可控性。

5.敏捷模型

敏捷模型是 20 世纪 90 年代出现的一种软件开发模型。 现代社会，科技发展非常迅速，软件开发是在快节奏的环境中进行的。 在业务瞬息万变的环境中，往往无法在软件开发前收集到完整详细的软件需求。 没有完整的软件需求，传统的软件开发模式就难以奏效。

为了解决这个问题，人们提出了敏捷开发模型。 敏捷模型以用户的需求演进为核心，采用迭代的、循序渐进的方法进行软件开发。 在敏捷模型中，软件项目在构建初期被拆分成多个相互关联又相互独立的子项目，然后迭代完成各个子项目。 在开发过程中，每个子项目都要经过开发和测试。 当客户的需求发生变化时，敏捷模型可以快速修改子项目以满足客户的需求。 在此过程中，软件一直处于可用状态。

除了响应需求，敏捷模型还有一个重要的概念——迭代，就是对产品不断地进行细微的、渐进的改进，每次改进一小部分，在可行的情况下逐步扩大改进的范围。 在敏捷模型中，软件开发不再是线性的。 开发过程中也会进行测试，甚至可以提前编写测试代码。 因此，敏捷模型中有“开发未做，测试先行”的说法。

此外，与传统的软件开发模式相比，敏捷模式更注重“人”在软件开发中的作用。 项目各部门应密切合作，快速有效地沟通（如面对面沟通）。 提出需求的客户可以全程参与到开发过程中，以适应频繁的软件需求变更。 为此，敏捷模型描述了一套软件开发的价值观和原则，如下。

(1) 个体和交互比过程和工具更重要。

(2) 可用的软件比完整的文档更重要。

(3)客户协作比合同谈判更重要。

(4) 响应变化比遵循计划更重要。

对于敏捷模式来说，并不是工具和文档不重要，而是更注重人与人之间的沟通。

敏捷模式可以及时响应客户需求的变化，不断适应新的趋势，但在灵活发展的同时也带来了一定的困惑。 例如，缺少文档； 软件先前版本的可再现性和可追溯性低； 对于更大的项目，人越多，面对面的有效沟通就越困难。 因此，敏捷模式更适合小项目的开发，而不适合大项目。