软件危机与软件工程化

软件（Software）是一系列按照特定顺序组织的计算机数据和指令的集合。软件一般被划分为系统软件、应用软件和介于这两者之间的中间件软件。软件并不是只包括可以在计算机（这里的计算机是指广义的计算机）上运行的程序，与这些程序相关的文档、数据等元素一般也被认为是软件的一部分。

随着计算机技术的迅速发展和广泛应用，软件从最初的计算机硬件的附属品，仅仅作为计算机硬件的运行和做一些简单的计算与数据处理的程序，发展到今天大规模的封闭或开放式的系统软件和应用软件。有的软件的源代码甚至超过千万行。例如，美国阿波罗计划的软件长达1000万行，航天飞机计划的软件更是长达4000万行，桌面操作系统为千万级量级规模。

软件是抽象的，是人类逻辑思维的产物，它不受物质材料的限制，也不受物理定律或加工过程的制约，这一特性使软件工程得以简化，因为软件的潜能不受物理因素的限制；另外一方面，由于缺乏自然约束，软件系统的实现在实施过程中，容易变得极为复杂，理解它会很困难、改变它付出的代价更加高昂。软件规模的增长，使其复杂度也随之大大增加，而高复杂度和高可靠性的不相容性，使得软件可靠性随着其规模的增长而降低，质量难以保证，维护愈加困难，投资预算很难控制，传统的软件研制开发方法已无法适应大规模软件的开发需求。

为了解决在软件开发和维护过程中遇到的一系列软件危机的严重问题，1968年，北大西洋公约组织（NATO）的科学家和官员们在原德意志联邦共和国召开的国际会议上讨论并首次提出了软件开发要工程化。当时，单个的程序开发技术已经不能扩展并应用到大型的、复杂的软件系统中。软件项目有时甚至要推迟几年才能完成，不仅比预计的费用高且难以维护。软件工作者开始认真研究消除软件危机的途径，从而逐渐形成了一门新兴的工程学科——计算机软件工程学（Software Engineering），简称软件工程。软件工程是一门工程学科，涉及软件生产过程中的各个方面，从最初的问题提出一直到投入使用后的系统维护，都属于其学科研究范畴。

一、软件危机

1.摩尔定律和超越摩尔

1965年，Intel联合创始人戈登·摩尔提出了著名的理论：半导体芯片上可集成的元器件的数目每18个月便会增加一倍。也就是说，同样规格的芯片的成本，每18个月便会降低一半。1965年每个芯片可以容纳50个晶体管，摩尔预测到1970年，每个芯片将能够容纳1000个元器件，每个晶体管的价格会降低90％。

经过简化，这个发现被归纳为“摩尔定律”：每个芯片上晶体管的数目每12个月将会增加一倍。戈登·摩尔的发现不基于任何特定的科学或工程理论，只是真实情况的映射总结。硅芯片行业注意到了这个定律，没有简单地把它当作一个描述的、预言性质的观察，而是作为一个说明性的、重要的规则、整个行业努力的目标。

除此之外，还有一个与摩尔定律相对的洛克定律（Rock's law），强调了生产中的成本因素。通过观察可知，芯片制造厂商的成本每4年便会增加一倍。技术的进步以不断为芯片上晶体管数量的增加铺平道路，但是芯片生产设施的建造会十分昂贵，而更小、更便宜的处理器的使用还在不断增加。

硬件技术在不断发展，但现在，这种发展轨迹要告一段落了。由于同样小的空间里集成越来越多的硅电路，产生的热量也越来越大，这种原本两年处理能力加倍的速度已经慢慢下滑，原本的摩尔定律在逐步失效。目前，行业研究规划蓝图新的战略是“超越摩尔”（More than Moore）：与以往首先改善芯片、软件随后跟上的发展趋势不同，以后半导体行业的发展将首先看软件——从手机到超级计算机再到云端的数据中心——然后反过来看要支持软件和应用的运行需要什么处理能力的芯片来支持。

这种局势的转变使得人们更加强调软件的重要性。计算机的应用日益广泛、深入，然而硬件的进步只是为计算机系统提供了潜在的能力，如果没有软件来驾驭和开发这种能力，人类并不能有效地使用计算机，因此，软件已成为限制计算机系统发展的关键因素。

计算机软件是一个逻辑的而非物理的系统，它具有与硬件显著的不同特点。它的主要工作集中在定义、开发、维护等纯智力活动方面。随着软件需求的剧增，软件规模不断增大，软件数量急剧膨胀。在程序运行时发现的错误必须设法改正；用户有了新的需求时必须相应地修改程序；硬件或操作系统更新时，通常需要修改程序以适应新的环境。上述种种软件维护工作，以令人吃惊的比例耗费资源。更严重的是，许多程序的个体化特性使得它们最终成为不可维护的。软件危机就这样开始出现。

2.软件危机的概念

软件危机（Software Crisis）是指在计算机软件的开发和维护过程中所遇到的一系列严重的问题，也可以指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

广义上讲，所谓软件危机包含两方面问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。

狭义上讲，所谓软件危机主要有以下一些典型表现：

（1）对软件开发成本和进度的估计常常很不准确。实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往降低了软件产品的质量，从而不可避免地会引起用户的不满。

（2）开发人员和用户之间很难沟通，矛盾很难统一。往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和描述。在双方互不充分了解的情况下，就仓促上阵设计系统、匆忙着手编写程序，这种“闭门造车”的开发方式必然导致最终的产品不符合用户的实际需要。

（3）大型软件项目需要组织一定的研发人力共同完成。软件项目管理人员缺乏开发大型软件系统的经验及软件开发各类人员的信息交流不及时、不准确，有时还会产生误解，这些都会导致软件质量无法得到保证。

（4）软件系统中的错误难以消除。软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制困难。软件产品并不是没有错误，而是盲目检测很难发现错误，而隐藏下来的错误往往是造成重大事故的隐患，这些都会导致软件产品出现质量问题。

（5）软件常常是不可维护的。很多程序中的错误是非常难改正的，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需求在原有程序中增加一些新的功能。“可重用的软件”还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件。

（6）软件通常没有适当的文档资料。错误的观点经常认为：软件就是程序。程序代码写完软件也就设计完了。实际上软件不仅仅是程序，还应该有一整套文档资料。这些文档资料应该是软件开发过程中产生出来的，而且应该是和程序代码完全一致的。软件开发过程中，基线是软件文档和源代码的一个稳定版本，它是进一步开发的基础。软件开发组织的管理人员可以使用这些文档资料作为“里程碑”，来管理和评价软件开发工程的进展状况；软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息；对于软件维护人员而言，这些文档资料更是必不可少的。缺乏必要的文档资料或者文档资料不合格，必然给软件开发和维护带来许多严重的困难和问题。

（7）软件成本在计算机系统成本中所占的比例逐年上升。随着互联网时代的到来，电子商务、移动互联网兴起，软件经济已经影响到社会经济生活中的方方面面。硬件成本逐年下降，然而软件开发需要大量人力，软件成本随着软件规模和数量的不断扩大而持续上升。

（8）软件开发生产率跟不上计算机应用系统迅速普及深入的速度。软件开发是一种高强度的脑力劳动，理论性和实践性都很强，软件开发人员的生产效率也对开发的周期和质量有很大影响。特别是软件工程，对软件开发的成功（按质按量，按期完成）有决定性作用。

（9）软件产品的特殊性和人类智力的局限性，导致人类无力处理“复杂问题”。“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前，所以“复杂问题”的解决需要诸多学科知识及技术的协同发展。

以上举例的仅仅是软件危机的一些典型表现，与软件开发和维护有关的问题远不止这些。

3.产生软件危机的原因

开发软件系统需要投入大量的人力和物力，但软件系统的质量却难以保证，也就是说，开发软件所需的高成本同产品的低质量之间有着尖锐的矛盾，这种现象就是所谓的“软件危机”。在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，而另一方面的主要原因是软件开发和维护的方法不正确有关。

软件开发不同于一般的加工制造业、机械工业以及一般的加工业，这些行业都已经有了上百年的历史，产品的生产流程及工厂、车间、工种等的机构设置和角色分工都有了成熟的模式。但是，软件企业及软件产品的生产，历史不长，加之软件本身的智力劳动的特性，软件作为产品的生产流程及其相应的管理活动，还远远没有一个成熟的模式。此外，软件不同于一般程序，它的一个显著特点是规模庞大，而程序复杂性将随着程序规模的增加而呈指数上升。为了在预定时间内开发出规模庞大的软件，必须由许多人分工合作。然而，如何保证每个人完成的工作合在一起确实能够成一个高质量的大型软件系统，更是一个极端复杂困难的问题，这不仅涉及许多技术问题，如分析方法、设计方法、形式说明方法、版本控制等，更重要的是必须有严格而科学的管理。

与软件开发和维护有关的许多错误认识和做法的形成，可归因于在计算机系统发展的早期阶段软件开发的个体化特点。错误的认识和做法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。另外，软件开发过程中如果缺乏有力的方法学和工具方面的支持会产生软件危机。由于软件开发不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件开发产品的个性化，也是发生软件开发危机的一个重要原因。

软件项目管理（Software Project Management）的对象是软件工程项目。它所涉及的范围覆盖了整个软件工程过程。为使软件项目开发获得成功，关键问题是必须对软件项目的工作范围、可能风险、需要资源（人、硬件、软件）、要实现的任务、经历的里程碑、花费工作量（成本）、进度安排等做到心中有数。这种管理在技术工作开始之前就应开始，在软件从概念到实现的过程中继续进行，当软件工程过程最后结束时才终止。

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理的活动。软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析、设计、编码到测试、维护全过程）都能在管理者的控制之下，以预定成本按期、按质地完成软件交付用户使用。研究软件项目管理要从已有的成功或失败的案例中总结出能够指导今后开发的通用原则、方法，同时避免前人的失误。软件工程学的一个重要目标就是结合软件开发技术和先进管理技术，以提高软件的可维护性，减少软件维护的代价。

4.消除软件危机的途径

软件工程作为一个新兴的工程学科，主要研究软件生产的客观规律性，建立与系统化软件生产有关的概念、原则、方法、技术和工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本、改进软件产品质量、提高软件生产率水平的目标。软件工程学从硬件工程和其他人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展了许多软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取得了良好的效果。

为了消除软件危机，首先应该对计算机软件有一个正确的认识。软件设计者应该彻底消除在计算机系统早期发展阶段形成的“软件就是程序”的错误观念。一个软件必须由一个完整的配置组成，事实上，软件是程序、数据及相关文档的完整集合。其中，程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当处理信息的数据结构；文档是开发、使用和维护程序所需要的图文资料。1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。

更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严格、各类人员协同配合、共同完成的工程项目。必须充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。

在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支持环境，以期从管理和技术两方面解决软件危机问题。应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。

应该开发和使用更好的软件工具，在软件开发的每个阶段都有许多烦琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。如果把各个阶段使用的软件工具有机地结合成一个整体，支持软件开发的全过程，则称为软件工程支撑环境。

此外，人工智能与软件工程的结合成为20世纪80年代末期活跃的研究领域。基于程序变换、自动生成和可重用软件等软件新技术研究也已取得一定的进展，把程序设计自动化的进程向前推进一步。软件标准化与可重用性得到了工业界的高度重视，在避免重用劳动、缓解软件危机方面起到了重要作用。

软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的共同努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。

软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识、可以科学地描述的。还可以通过一些方法和人类活动，来改进质量。针对以上问题，可以在软件开发过程中实施能力成熟度模型来改进软件质量、控制软件生产过程、提高软件生产者组织性和软件生产者个人能力和开发效率。

能力成熟度模型（Capability Maturity Model，CMM）是一种开发模型。CMM是国际公认的对软件公司进行成熟度等级认证的重要标准。CMM的目标是改善现有软件开发过程，也可用于其他过程。CMM的基本思想是，因为软件危机问题是管理软件过程的方法引起的，所以新软件技术的运用不会自动提高生产率和利润率。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好的软件，使更多的软件项目免受时间和费用的超支之苦。软件过程包括各种活动、技术和用来生产软件的工具。因此，它实际上包括了软件生产的技术方面和管理方面。CMM策略力图改进软件过程的管理，而在技术上的改进是其必然的结果。CMM致力于软件开发过程的管理和工程能力的提高与评估。该模型在美国和北美地区已得到广泛应用，同时越来越多的欧洲和亚洲等国家的软件公司正积极采纳CMM，CMM实际上已成为软件开发过程改进与评估事实上的工业标准。

总之，为了解决软件危机，既要有技术措施（方法和工具），又要有先进的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

二、软件开发工程化

软件作为人类纯智力的劳动成果，和其他科学、技术、文学、艺术一样是人类共享的社会财富。但与文学艺术这类纯精神产品不同的是，它要面向社会发展的方方面面，它的研制开发工作就必须从用户的要求和市场的需求出发。能否得到用户的欢迎，能否取得一定的市场份额，将取决于软件本身的功能、性能、可靠性、价格以及扩充能力等。软件产品的商品化是实现上述目标的必由之路。传统的“艺术创作”式的方式，极不适应提供低价格高品质软件产品的商品化需求。为此，人们将借鉴其他科技产品商品化的路子，提出软件产品的研制开发与生产必须工程化、标准化。

1.软件工程的定义

1968年“软件工程”这一名称被首次提出。软件工程的目标简而言之就是要使开发的软件产品具有可靠性、有效性、易维护性和可理解性。实现这一目标的软件工程原理就是：必须采用一种有效的方法和技术来降低开发活动的复杂性。

软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构分别给出了自己认可的定义：

BarryBoehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

IEEE在软件工程术语汇编中的定义：①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；②在①中所述方法的研究。

FritzBauer在NATO会议上给出的定义：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

此外，《计算机科学技术百科全书》中，软件工程是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本和改进算法。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。

ISO 9000对软件工程过程的定义是：软件工程过程是输入转化为输出的一组彼此相关的资源和活动。

其他定义：①运行时，能够提供所要求功能和性能的指令或计算机程序集合；②程序能够满意地处理信息的数据结构；③描述程序功能需求以及程序如何操作和使用所要求的文档。以开发语言作为描述语言，可认为软件=程序+数据+文档。

综上，软件工程可以概括为：软件工程采用工程学的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，研究和应用如何以系统性的、规范化的、可定量的过程化方法开发和维护软件的学科。

软件工程的目标是：在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。

2.软件工程的基本原理

自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。美国著名的软件工程专家巴利·玻姆（Barry Boehm）综合这些专家的意见，并总结了美国天合公司（TRW）多年的开发软件的经验，于1983年提出了软件工程的七条基本原理。

玻姆认为，这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。人们当然不能用数学方法严格证明它们是一个完备的集合，但是可以证明，在此之前已经提出的100多条软件工程准则都可以由这七条原理的任意组合蕴含或派生。

下面是软件工程的七条原理：

1)用分阶段的生命周期计划严格管理

这一条是吸取前人的教训而提出来的。统计表明，50％以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。

玻姆认为，在整个软件生命周期中应指定并严格执行六类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

2)坚持进行阶段评审

统计结果显示：大部分错误是在编码之前造成的，大约占63％，错误发现得越晚，改正它要付出的代价就越大，要差2到3个数量级。因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。

3)实行严格的产品控制

开发人员最头疼的事情之一是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又称基准配置管理。当需求变动时，其他各个阶段的文档或代码随之相应变动，以保证软件的一致性。

4)采纳现代程序设计技术

从20世纪六七十年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大于气力。采用先进的技术既可以提高软件开发的效率，又可以减少软件维护的成本。

5)结果应能清楚地审查

软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。

6)开发小组的人员应少而精

开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少得多；当开发小组为N人时，可能的通信信道为N（N-1）/2，可见随着人数N的增大，通信开销将急剧增大。

7)承认不断改进软件工程实践的必要性

遵从上述六条基本原理，就能较好地实现软件的工程化生产。但是，它们只是对现有经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，玻姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

3.软件开发的发展过程

软件是由计算机程序和程序设计的概念发展演化而来的，是在程序和程序设计发展到一定规模并且逐步商品化的过程中形成的。软件开发经历了程序设计阶段、软件设计阶段和软件工程阶段的演变过程。

1)程序设计阶段

程序设计阶段出现在1946年至1955年。此阶段的特点是：尚无软件的概念，程序设计主要围绕硬件进行开发，规模很小，工具简单，无明确分工（开发者和用户），程序设计追求节省空间和编程技巧，无文档资料（除程序清单外），主要用于科学计算。

2)软件设计阶段

软件设计阶段出现在1956年至1970年。此阶段的特点是：硬件环境相对稳定，出现了“软件作坊”的开发组织形式。开始广泛使用产品软件（可购买），从而建立了软件的概念。随着计算机技术的发展和计算机应用的日益普及，软件系统的规模越来越庞大，高级编程语言层出不穷，应用领域不断拓宽，开发者和用户有了明确的分工，社会对软件的需求量剧增。但软件开发技术没有重大突破，软件产品的质量不高，生产效率低下，从而导致了“软件危机”的产生。

3)软件工程阶段

自1970年起，软件开发进入了软件工程阶段。由于“软件危机”的产生，迫使人们不得不研究、改变软件开发的技术手段和管理方法。从此软件开发进入了软件工程时代。此阶段的特点是：硬件已向巨型化、微型化、网络化和智能化四个方向发展，数据库技术已成熟并广泛应用，第三代、第四代语言出现；第一代软件技术——结构化程序设计在数值计算领域取得优异成绩；第二代软件技术——软件测试技术、方法、原理用于软件生产过程；第三代软件技术——处理需求定义技术用于软件需求分析和描述。

4)未来

在Internet平台上进一步整合资源，形成巨型的、高效的、可信的虚拟环境，使所有资源能够高效、可信地为所有用户服务，成为软件技术的研究热点之一。软件工程领域的主要研究热点是软件复用和软件构件技术，它们被视为是解决“软件危机”的一条现实可行的途径，是软件工业化生产的必由之路。而且软件工程会朝着开放性计算的方向发展，朝着可以确定行业基础框架、指导行业发展和技术融合的“开放计算”。

最近几年产生了一种观点——“软件即是一种服务”，软件不再在本地计算机上运行，而是将它放在所谓的“计算云”中。云计算（Cloud Computing）是基于互联网的相关服务的增加、使用和交付模式。云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络、服务器、存储、应用软件、服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。云计算是继1980年代大型计算机到客户端—服务器的大转变之后的又一种巨变。云计算是分布式计算（Distributed Computing）、并行计算（Parallel Computing）、效用计算（Utility Computing）、网络存储（Network Storage Technologies）、虚拟化（Virtualization）、负载均衡（Load Balance）、热备份冗余（High Available）等传统计算机和网络技术发展融合的产物。云计算是通过使计算分布在大量的分布式计算机上，而非本地计算机或远程服务器中，企业数据中心的运行将与互联网更相似。这使得企业能够将资源切换到需要的应用上，根据需求访问计算机和存储系统。

云计算背景下，传统软件工程也需要不断创新发展。在传统的软件开发过程中，软件使用者对软件的需求确定后则按照传统软件工程开发模型进行软件设计，需求的改变则可能会导致软件架构的改变，这种改变会对软件设计影响巨大。而在云计算背景下，需求可能是在不断地变化，比如刚开始预期的使用人数只有一万人，但是当软件上线之后发现该软件很受欢迎，使用人数达到了百万级，大大超过了之前软件设计容量，于是通过云计算，可以对软件的运行环境进行动态扩充，只要对软件稍作修改便可使软件继续顺利运行。运用云计算的动态性，可以动态改变软件的运行环境，尽量减少整个软件结构所需要的改动。同时对于在开发过程中选择更改架构的程序，也只需要改变本地代码即可，对于云端服务器，只要进行简单的设置就可顺利地让程序运行。此外，传统的软件工程开发更多的是软件工程师采用集中开发方式，以求最大的开发效率，开发组织大部分都局限在某一个具体公司里，组织之外的人想要参与项目是很困难的，而在云计算的时代，由于服务器在云端，只需要通过远程操作云服务器就能完成软件的开发部署工作，所以软件工程师可以身处世界各地而共同完成同一个工程，这使得开发变得更加包容与开放，只要互相之间进行约定，每个人按时完成自己所负责的工作即可，这使得开发组织可以变得更加多元化。

现在，越来越多的人开始意识到云计算的好处，并且已经开始接受并采用云计算，因为它可以改变人们的工作生活方式，对于软件工程行业也是如此。云计算服务器为开发人员提供了更加宽广的开发平台，它使得开发人员可以专注于业务的实现而从复杂的运行环境中抽身出来，使得软件变得更加可靠。

此外，云计算、移动互联网、大数据时代的到来，使传统的软件工程面临新的机遇与挑战。传统软件工程也正处于一个软件工业大变革的过程中，随着软件资源的大量积累与有效利用，软件生产的集约化与自动化程度都将迅速提高，软件生产质量与效率的大幅度改进将成为可能。

长按二维码识别关注我们