![[field:title /]](/style/images/star.png)
软件是有生命周期的，一个软件的开发如同任何事物的发展，都有完整的且科学的过程。
一般来说，软件的生命周期分为几个阶段：
计划（Planning）
在这个阶段，公司或者项目组会确定软件开发的总目标，给出软件的功能、性能、可靠性以及接口等方面的设想，并研究完成项目的可行性，同时，对各项资源、成本、可预期的效益进行评估讨论，制定完成开发任务的对应实施计划。
这是属于非常早期的工作，在制定计划时，开发测试人员还没有招聘也是有可能的。
需求分析（Requirement Analysis）
这个阶段很好理解，因为最原始的需求一定是用户提供的，我作为用户，希望能用到什么功能，肯定是我最真切的需求，许多的“我”的需求加起来，公司就有了动力来制作一款软件满足“我们”，所以这个阶段，就是确定哪些是可以实现的，哪些是忽略掉或者推出后看情况后期再加入。
需求分析需要做的工作，主要是对开发的软件进行详细的定义，是由需求分析人员用户共同讨论决定的，这个时候会对需求给出确切的描述，写出软件需求说明书（SRS，Software Requirement Specification）。
（图片来自网络）
设计（Design）
顾名思义，肯定是要将具体的需求所需要用到的技术、架构等内容进行“约定”，形成书面的文档，因为一个软件不会是只有一个开发人员，并且除了开发意外，还有诸如测试、质量、各层面管理人员，怎样让大家协调同步进行工作呢？文档！事前约定好了工作文档，在遇到问题及不能达成一致意见时就可以依据文档来定夺。
这个阶段会输出两种文档：
概要设计，在设计阶段把各项需求转换成相应的体系结构，每一部分都是功能明确的模块；
详细设计，在概要设计的基础上，从技术层面上对各个模块的具体工作进行详细的描述；
程序编码（Coding）
加班！
加班！
加班！
（图片来自网络）
测试（Testing）
这个时候，是测试对已经完成的或部分完成的软件模块进行测试的阶段，一般的会由独立的小组进行，工作分为单元测试、集成测试、系统测试。
其实测试的介入时间早在这个阶段之前，但是本文主要为了说明一般软件的生命周期，所以具体的此处不表。
运行和维护（Run and Maintenance）
此时的软件已经正式交付投入使用，为什么要维护呢？原因可能由多种，比如软件发生了错误，系统软件要升级，或者用户想要更多的功能，都是需要进行维护工作的。
小故事：
世界上第一个程序是1842年写的，恰好在第一个能被称为计算机的真正机器。这段代码的作者是Ada Augusta，被封为Lovelace女伯爵，就是大家所知道的Ada Lovelace（奥古斯塔·阿达·金）。作为世界上第一个计算机程序的作者，她被广泛地认为是有史以来第一位程序员。
上边的介绍，只是一般意义上软件开发周期所经历的阶段，这些阶段根据不同体量、不同规格、不同用途的软件需求，可以分成几大类开发模型，下面介绍一下几种主要的模型。
瀑布模型（Waterfall Model）
（图片来自网络）
（画图太累了，就网上“盗”了，嘿嘿）
瀑布模型是最基本的开发模型，这名字的来源如同图示一般，按部就班，分工明确，最重要的核心思想就是按照工序将问题极大的简化，这样功能的实现与设计完全分开，对分工协作比较便利。
采用结构化的分析与设计方法将逻辑实现与物理实现分开，将软件生存周期的各项活动规定为按固定的顺序连接的若干阶段的工作，就像瀑布的流水一样。
这种模型的优点，在于为项目提供了按阶段划分的检查点，发生问题便于分析处在哪里，而当前一个阶段完成时，只需要执行之后的阶段工作即可。当项目计划以此制定下来，就像有一个模板一样，整个项目的运作就有一个共同的指导了。
当然了，没有什么时完美的，优缺点总是并存的。
它的缺点其实也很容易看出来，太固定的阶段划分，必然要上下之间作出大量的文档约束，这样的工作量并不适合大型项目，另一方面，这种一条线的线性模式，只有出来成品，才知道到底怎么样，万一中途跑偏儿了，那就尴尬了。而且如果用户中途发生了变化，本来想要个凳子，现在想要桌子，怎么办，只能从头再来，没有什么变通性。
瀑布模型比较适用于小型化的、基本无中途变更需求的项目，且大型项目的各个模块开发也会用到这个方法。
螺旋模型（Spiral Model）
（图片来自网络）
这是一种采用周期性的方法来进行系统开发的模型。相对于瀑布模型，螺旋模型主要是强调风险的分析与管控。采用该方法的项目，在开发过程中会出现很多个中间版本，而每一个版本都会经历一个周期，包括了需求分析、风险分析、工程实现和评审4个阶段，可以让开发人员和客户对每个中间版本出现的风险有所了解，继而做出应有的对策，这种方法比较适合庞大、复杂并具有高风险的系统。
RAD（Rap Application Development）
快速应用开发模型，是种重要的模型，由于模型结构比较类似于字母V，所以也叫做V模型。
该模型通过开发和测试同时进行工作的方式，可以极大的缩短开发周期，提升开发效率。
（图片来自网络）
之所以称之为重要模型，是因为这种模型的出现，是一个里程碑式的进步，它允许测试人员更早的介入到软件开发的流程当中，对于软件开发中出现的问题可以更早的发现并提出，通过让问题更早的暴露的方法，降低了许多的无效工作，提高了软件开发进度，对于效率的提升时决定性的。
V模型的软件测试策略既包括底层测试，也包括了高层测试，底层是为了源代码的正确性，高层是为了整个系统满足用户的需求。
V模型指出，单元和集成测试是验证程序的设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应该验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认和验收测试，追溯软件需求说明进行测试，以确定软件的实现是否满足用户需求或合同的要求。
但是，这个最早由Paul Rook在20世纪80年代后期提出的V模型同样具有一定的局限性，仅仅把测试过程作为在需求分析、概要设计以及详细设计并编码过后的一个阶段，容易使人理解为测试只是软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而忽略掉在需求分析时所隐藏的问题，这种问题只有在最终验收时才能暴露出来。
V&V模型（双V模型或者W模型）
由于没有明确的确定在其的测试，没有体现出“尽早地和不断地进行测试”的原则，V模型被加以改进，在其中增加软件各个开发阶段同步进行的测试活动。
如上图所示，上世纪末由Evolutif公司所提出的Ｖ＆Ｖ模型，相对于V模型，更加的科学。
它所强调的时，测试伴随整个软件的开发周期，而且测试的对象不光光是程序，是代码，而是包括了需求、功能、设计、文档等等所有可能的前中后期产物。应该说，W模型是V模型自然而然发展出来的，在该模型下，只要相应的开发活动完成，我们就可以开始执行测试工作，可以说，测试和开发才是真正的同步工作，从而可以更早的发现问题。就好比需求，一般的流程，可能用户需要的知道软件开发完毕，才能看到对应的产物，如果需求是由问题的，是可以技术实现但是生活中不存在或不合理的，那么在需求文档测试阶段就可以发现这样的问题。这对于人员成本及时间成本的节约起到了非常大的作用。
敏捷模型
现代软件开发企业，竞争异常的激烈，随着开发时间越来越少，成本控制越来越严格，软件的开发周期越来越紧张，急需一种可以缩短项目周期，又不降低项目工程质量的新方法来进行管理，敏捷模型便应运而生。
敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期会被切分成多个子项目，各个子项目的成果都经过严格测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
这种高度并行开发及低耦合的模块化，更适合跟进用户需求的演变，更能满足迭代改进以及维护的需要，越来越多的企业在使用这种方法进行项目的管理工作，保持了企业自身的竞争力。
