在上一节课，我们提到计算机软件是由程序及其文档组成，关于软件的特点，我们可以总结如下：
软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己的定义。但具体总结起来就是几个关键点：
早期做软件是小作坊式的生产，后来随着硬件的提升，用户的需求。小作坊明显解决不了问题，就出现了软件危机
软件危机(Software Crisis) 是计算机软件在它的开发和维护过程中所遇到的一系列严重问题。
为了更好解决诸如此类的问题，软件规模化，工厂化的生产越发成为需要，软件工程便呼之欲出啦，需要解决以下问题：
软件测试工作与软件开发模型息息相关，在不同的软件开发模型中，测试的任务和作用也不相同，因此测试人员要充分了解软件开发模型，以便找准自己在其中的定位与任务。
软件开发模型规定了软件开发应遵循的步骤，是软件开发的导航图，它能够清晰、直观地表达软件开发的全过程，以及每个阶段要进行的活动和要完成的任务。
开发人员在选择开发模型时，要根据软件的特点、开发人员的参与方式选择稳定可靠的开发模型自有软件开发以来，软件开发模型也从最初的“边做边改”发展出了多个模型，下面以软件开发模型发展历史为顺序，介绍几个典型的开发模型。
在20世纪70年代，由温斯顿·罗伊斯（Winston Royce）提出，瀑布模型一直是惟一被广泛采用的软件过程模型，现在它仍然是软件工程中应用得非常广泛的过程模型。瀑布模型是一种线形的、顺序的软件开发模型，主要分为6个阶段:可行性计划研究→需求分析→软件设计→编码→测试→运行维护，其开发过程如图1-2所示。
在瀑布模型中，软件开发的各项活动严格按照这条线进行，只有当一个阶段任务完成之后才能开始下一个阶段。软件开发的每一个阶段都要有结果产出，结果经过审核验证之后作为下一个阶段的输入，下个阶段才可以顺利进行。如果结果审核验证不通过，则需要返回修改。
瀑布模型为整个项目划分了清晰的检查点，当一个阶段完成之后，只需要把全部精力放置在后面的开发上即可，它有利于大型软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。
但是瀑布模型是严格按照线性方式进行的，无法适应用户需求变更，用户只能等到最后才能看到开发成果，增加了开发风险。如果开发人员与客户对需求理解有偏差，到最后开发完成后，最终成果与客户需求可能会差之千里。使用瀑布模型开发软件时，如果早期犯的错误在项目完成后才发现，此时再修改原来的错误需要付出巨大的代价。瀑布模型要求每一个阶段必须有结果产出，这就势必增加了文档的数量，使软件开发的工作量变大。
V 模型最早是由Paul Rook 在20 世纪80 年代后期提出的，V 模型在英国国家计算中心文献中发布，目的是改进软件开发的效率和效果。它是软件测试最具代表性的测试模型之一。
在传统的开发模型中，如瀑布模型，通常把软件测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时软件测试工作会占整个项目周期一半的时间，但是仍然被认为软件测试只是一个收尾工作，而不是主要的工程。故对以前的测试模型进行了一定程度的改进，V 模型其实是软件开发瀑布模型的变种，反映了软件测试活动与软件开发过程(从分析到设计)的关系，如图1-3 所示
V 模型从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存在的不同级别以及测试阶段和开发过程各阶段的对应关系。图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程各阶段。
V 模型指出，单元和集成测试是验证程序设计，单元测试主要由白盒测试工程对代码进行测试，但目前国内真正做白盒测试的企业不多。这主要有两大原因：第一，白盒测试投入的成本很高，并且产出不明显，很多企业不希望投入更多的资源去做这项工作;第二，白盒测试对测试工程师的要求较高，在目前系统测试还没有完全成熟的情况下很难真正地开展白盒测试。而集成测试是介于白盒测试与系统测试之间的一种测试，也叫灰盒测试，由于它与白盒测试和系统测试之间没有明显的界限，所以在实际的测试过程中，即使开展集成测试也是由系统测试工程师来完成。
系统测试主要验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标，由测试人员和用户进行软件的确认测试和验收测试，以及对需求说明书进行测试，以确定软件的实现是否满足用户需求或合同要求。
V 模型存在一定的局限性，它把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。如果不做白盒测试，那么其实都是在系统完成集成后才开始系统测试的，这样需求分析阶段隐藏的问题一直到后期的验收测试才被发现，因此修改缺陷的成本就高了很多。
快速原型模型与瀑布模型正好相反，它在最初确定用户需求时快速构造岀一个可以运行的软件原型，这个软件原型向用户展示待开发软件的全部或部分功能和性能，客户对该原型进行审核评价，然后给出更具体的需求意见，这样逐步丰富细化需求，最后开发人员与客户达成最终共识，确定客户的真正需求。确定客户的真正需求之后，开始真正的软件开发。
快速原型模型类似于建造房子，确定客户对房子的需求之后快速地搭建一个房子模型，由客户对房子模型进行评价，房子的样式、功能、布局等是否满足需求，哪里需要改进等，最后确定了客户对房子的要求，就开始真正地建造房子。该模型的开发过程如图1-4所示。
与瀑布模型相比，快速原型模型克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。但快速原型模型关键在于快速构建软件原型，准确地设计出软件原型存在定的难度。此外，这种开发模型也不利于开发人员对产品进行扩展。
迭代模型又称为增量模型或演化模型，它将一个完整的软件拆分成不同的组件，然后逐个组件地开发测试，每完成一个组件就展现给客户，让客户确认这一部件功能和性能是否达到客户需求，最终确定无误，将组件集成到软件体系结构中。
整个开发工作被组织为一系列短期、简单的小项目，称为一系列迭代，每一个迭代都需要经过需求分析→软件设计→编码→测试的过程，其开发过程如图1-5所示。
在迭代模型中，第一个迭代(即第一个组件)往往是软件基本需求的核心部分，第一个组件完成之后，经过客户审核评价形成下一个组件的开发计划，包括对核心产品的修改和新功能的发布，这样重复迭代步骤直到实现最终完善的产品。
迭代模型可以很好地适应客户需求变更，它逐个组件地交付产品，客户可以经常看到产品，如果某个组件没有满足客户需求，则只需要更改这一个组件，降低了软件开发的成本与风险。但是选代模型需要将开发完成的组件集成到软件体系结构中，这样会有集成失败的风险，因此要求软件必须有开放式的体系结构。此外，迭代模型逐个组件地开发修改，很容易退化为“边做边改”的开发形式，从而失去对软件开发过程的整体控制。
螺旋模型由巴利·玻姆(Barry Boehm)于1988年提岀，该模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失。这种模型比较适合开发复杂的大型软件。
螺旋模型将整个项目开发过程划分为几个不同的阶段，每个阶段按部就班地执行，这种划分方式采用了瀑布模型。每个阶段在开始之前都要进行风险评估，如果能消除重大风险则可以开始该阶段任务。在每个阶段，首先构建软件原型，根据快速原型模型完成这个迭代过程，产出最终完善的产品，然后进入下一个阶段，同样下一个阶段开始之前也要进行风险评估，这样循环往复直到完成所有阶段的任务。螺旋模型的若干个阶段是沿着螺线所示。
图1-6有4个象限:制订计划、风险分析、实施工程、客户评估，各象限含义如下。
(1)制订计划:确定软件目标，制订实施方案，并且列出项目开发的限制条件。
在螺旋模型中，每一个选代都需要经过这4个步骤，直到最后得到完善的产品，可以进行提交。
螺旋模型强调了风险分析，这意味着对可选方案和限制条件都进行了评估，更有助于将软件质量作为特殊目标融入产品开发之中。它以小分段构建大型软件，使成本计算变得简单容易，而且客户始终参与每个阶段的开发，保证了项目不偏离正确方向，也保证了项目的可控制性。
软件和其他产品一样，都有一个从“出生”到“消亡”的过程，这个过程称为软件的生命周期。在软件的生命周期中，软件测试是非常重要的一个环节。
软件生命周期分为多个阶段，每个阶段有明确的任务，这样就使得结构复杂、管理复杂的软件开发变得容易控制和管理。通常，可将软件生命周期划分为6个阶段，如图1-1所示。
第1阶段:问题定义，该阶段由软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
第2阶段:需求分析，该阶段对软件需求进行更深入的分析，划分出软件需要实现的功能模块，并制作成文档。需求分析在软件的整个生命周期中起着非常重要的作用，它直接关系到后期软件开发的成功率。在后期开发中，需求可能会发生变化，因此，在进行需求分析时，应考虑到需求的变化，以保证整个项目的顺利进行。
第3阶段:软件设计，该阶段在需求分析结果的基础上，对整个软件系统进行设计，如系统框架设计、数据库设计等。
第4阶段:软件开发，该阶段在软件设计的基础上，选择一种编程语言进行开发。在开发过程中，必须要制订统一的、符合标准的程序编写规范，以保证程序的可读性、易维护性以及可移植性。
第5阶段:软件测试，该阶段是软件开发完成后对软件进行测试，以查找软件设计与软件开发过程中存在的问题并加以修正。软件测试过程包括单元测试、集成测试、系统测试、验收测试等4个阶段;测试的方法以黑盒测试、白盒测试或者两者结合的形式进行。在测试过程中，为减少测试的随意性，需要制订详细的测试计划并严格遵守;测试完成之后，要对测试结果进行分析并对测试结果以文档的形式汇总。
第6阶段:软件维护，软件完成测试并投入使用之后，面对庞大的用户群体，软件可能无法满足用户使用需求，此时就需要对软件进行维护升级以延续软件的使用寿命。软件的维护包括纠错性维护和改进性维护两个方面。软件维护是软件生命周期中持续时间最长的阶段。
项目经理：驱动整个项目的运转，负责制定计划，安排人力，管理进度，协调团队，进行重大决策。
架构师 / 系统工程师：技术专家，经验丰富，负责整个系统的体系架构的设计以及关键模块的设计。
配置管理员：负责管理程序员写的代码和资料工程师写的文档资料，并组合成一个软件包。
