软件生命周期（SDLC）——第三季

简介

之前简单的介绍了三个时期颇有代表性的瀑布模型，螺旋模型与敏捷开发的优缺点，并对他们分别做了对比。第三季主要介绍从上个世纪50年代至今影响软件生命周期发展的因素，并大胆猜想未来。（以下内容纯属个人学习后的猜想与总结，如有错误或者歧义还请大神指出并改正。）

复杂性

通常软件项目会根据大小，技术难度，可行性等因素划分为不同程度的复杂性，所以不同的软件生命周期通常是根据软件的复杂度而设计的。例如，大型的企业级软件通常需要大量的人力资源参与开发过程，所以瀑布模型或者螺旋模型会比较合适。相反近代涌现出大量的小型软件公司，由于公司规模与人员不足，他们往往只开发小型项目，这也是敏捷开发在近代这么普遍的原因。

易变性

易变性通常指的是在软件生命周期中客户需求的稳定性，最原始的瀑布模型就没有考虑项目的易变性，直接导致瀑布模型存在较高的失败率。也就是易变性的原因，后期的软件生命周期引入了迭代的概念，起初是在瀑布模型中添加了原型（Prototype），并且产生了V模型等拥有少量迭代的生命周期，直到后来出现的拥有大量迭代周期的螺旋模型与敏捷开发，都是受到易变性的影响。有时客户并不清楚自己的准确需求，软件开发只能在有限的需求下进行，这时增量开发的概念开始引入了软件生命周期，比如螺旋模型和敏捷开发都是处理增量开发的典型方案。

扩展性

扩展性同时代表“产品”与“团队”的扩展，比如在软件生命周期发生团队成员的变动，新成员需要快速理解并适应开发的进度，但是有时候阅读别人代码比重新编写代码更加困难，所以一些有明显的里程碑和文档的软件生命周期可以将人员变动的问题简化。另一方便，项目的扩展性往往需要更多的设计与计划周期。

可行性

在早期的软件工业中，很多软件都因为软件生命周期有限的种类与缺陷导致开发失败，所以可行性也是推动软件生命周期发展的重要因素。比如螺旋模型引入的风险评估与分析，来提高软件开发的可行性，又或者在计划阶段引入了可行性分析来减少失败率，还有预算管理的引入都是来确保软件开发的可行性的。

可用性

可行性是用来评价软件是否可以完成标准，那可用性就是来评价软件是否正确完成的标准，确切的说可用性包括核实（verifacation）与批准（validation）的过程。早期的瀑布模型只使用核实来确保可用性，但是缺乏批准的过程，往往没有经过批准的项目都不是被客户所接受的。所以后期的软件生命周期引入了迭代来控制核实与批准，比如V模型在集成测试过程包括了集成测试的核实、系统核实与确认的过程来确保软件的可用性。

复用性

随着软件市场的竞争越来越激烈，快速的反应是占领市场的前提，所以管理者需要一个更加灵活快速的开发管理方案。复用性就可以引入到软件生命周期中，根据项目的需求来集成现有的模块来开发新软件可以大大缩短预算与时间。所以一些软件生命周期直接抛弃传统的设计阶段并结合敏捷开发来通过迭代与增量开发来进行快速的开发。

重复性

区别于复用性，重复性并不是简单的集合模块，往往是直接修改现有的软件或者开源软件。在这个信息爆炸的时代，大量的开源项目涌入市场，软件工程师可以轻易的找到与自己需求相似的资源并加以修改，这必将继续推动的软件生命周期的灵活性的进化。

安全性

网络与软件的安全性早就是一个不可忽视的问题，软件故障或者数据丢失都将造成不可估计的后果，所以安全性测试与安全性评估等过程往往也是软件生命周期必不可少的过程。

交流性

在传统的软件开发周期中，工程师与客户的交流往往是建立在文档的基础上，缺乏大量的交流往往会影响软件需求的准确性。慢慢的工程师开始意识到交流的重要性，并将交流性引入了软件生命周期，例如敏捷开发就引入了与客户之间大量面对面交流。

软件生命周期的未来

软件生命周期发展了将近大半个世纪，与之前的因素都密不可分，然而未来推进软件生命周期的发展将会是什么因素呢？
我相信复用性和重复性的作用还会继续推进软件生命周期的发展，例如在计划或者设计阶段中间，我们可以添加一个寻找开源资源的阶段。
还有随着全球化的发展，越来越多交流方式将引入软件开发过程，比如现有的XP的结对编程或者Scrum的站会都推进了交流的方式，未来的全球化会带来很多远程合作，所以远程会议，与多人实时在线编程等方式将是解决方案。
还有随着人工智能的发展，软件开发的过程将会引入更多的自动化，随着开发的过程的简化或者自动化测试的引入，软件生命周期也会随之改变。
总体来说，随着时间的推进与科技的发展，现有的软件生命周期一定不会满足未来的开发方式，就算可以满足也可能是浪费资源的。不同的软件周期都是设计来应对不同的情况的，方案是死的，但是人是活的，在人类的灵活运用下软件开发的过程必将大大简化。