ACM通信

实践

一种新的软件工程

伊瓦尔·雅各布森、艾德·塞德维茨著
ACM通信，2014年12月，第57卷第12期，49-54页
10.1145 / 2677034
评论(2)

软件工程怎么了?像在其他工程学科中观察到的那样，软件开发的严格的、有纪律的、专业的实践的承诺发生了什么?

在“软件工程”的标题下采用的是一套很大程度上改编自其他工程学科的实践:项目管理、设计和蓝图、过程控制，等等。基本的类比是把软件当作一个制造出来的产品，所有真正的“工程”都在其上游进行，包括需求分析、设计和建模等等。

在其他工程学科中以这种方式进行工作是有意义的，因为前期工作是基于强大的基础理解，所以结果是可以信任的。软件工程没有这样的基础，所以“大型预先设计”经常没有回报。实际上，软件工程的风气倾向于贬低程序员的价值(如果不是明确地，那么通过控制实践就会隐式地贬低)。然而，程序员是真正让软件工作的人做不管设计“蓝图”说应该做什么。

毫不奇怪，这导致了许多不满。

今天的软件工艺运动是对工程方法的直接反应。专注于工艺对于软件开发，这一运动甚至质疑它是否有意义工程师软件这是更明智的观点吗?

因为最终必须让代码发挥作用，所以从一开始就专注于编写高质量的代码似乎是明智的。编码，作为一门技术学科，可以建立在软件“大师”的经验之上，领导社区构建越来越好的代码。此外，许多敏捷开发的技术实践已经使得使用工艺方法创建高质量的软件系统成为可能，这种方法从一开始就否定了软件工程所有前期活动的主要动力。

然而，最后，一门手艺训练只能带你走到这一步。从古代到中世纪，熟练的工匠和手工艺人创造了许多奇妙的建筑，从金字塔到哥特式大教堂。不幸的是，这些建筑的建造非常昂贵和耗时，有时它们会以灾难性的方式倒塌，原因往往不为人所知。

像摩天大楼这样的现代建筑只有在真正的发展中才成为可能工程的方法。现代建筑工程在材料科学和结构理论方面有坚实的基础，而建筑工程师将这一理论基础作为设计他们要建造的结构的仔细的、有纪律的方法的基础。

当然，这种结构有时还是会失败。然而，当他们这样做的时候，会再次进行彻底的分析，以确定失败是由渎职或原始设计中使用的基础理论的缺陷造成的。然后，在后一种情况下，新的理解可以纳入基础实践和未来的理论。

建筑工程是一个真正的工程学科如何结合工艺和应用理论基础的例子。在这样一个公认的基础中所捕获的理解被用来教育进入该学科的人。然后，它为他们提供了系统分析和解决工程问题的基础，即使这些问题超出了工程师的经验范围。

从这个角度来看，今天的软件工程是这根本不是一个工程学科．

相反，我们需要的是建立在软件工匠经验基础上的新的软件工程，在基础上捕获他们的理解，然后用来教育和支持新一代的从业者。因为工艺实际上都是关于实践者的，而工程理论的全部要点是支持实践者，这本质上是软件工程以前的化身所缺少的。

---

今天的软件工艺运动是对工程方法的直接反应。这个运动关注的是软件开发的工艺，它甚至质疑软件工程是否有意义。这是更明智的观点吗?

---

软件社区如何着手这项“重建”软件工程的任务?

SEMAT(软件工程方法和理论)倡议是致力于回答这个问题的国际努力(http://www.semat.org)．顾名思义，SEMAT专注于支持航天器(方法)和建立基本的认识(理论)．

这项工作仍在进行中，但新的软件工程的本质正在变得清晰起来。本文的其余部分将探讨这个本质是什么，以及它对该学科的未来有什么影响。

回到顶部

工程是有理论支撑的工艺

一个方法(同样,方法或过程)是对完成一项工作的工作方式的描述，例如开发软件。最终，所有的方法都来自于在进行这个主题努力时什么是有效的，什么是无效的经验。这些经验被提炼出来，首先变成经验法则，然后变成指导方针，当达成共识时，最后变成标准。

在一个工艺学科中，具有必要的长期经验的大师主要开发方法。在古代，大师的方法受到严密保护，只传给值得信赖的徒弟。然而，在当今世界，基于大师工匠作品的各种方法经常被广泛发表和推广。

当一门工艺发展成为一门工程学科时，基于正在进行的努力的潜在共享经验，认识到不同大师的方法之间的共性是很重要的。这种共同的理解被捕捉在一个理论这可以作为应用于努力的所有不同方法的基础。

从这个意义上说,理论在我们的文化中，它有时被视为一个坏词(“哦，那只是一个理论”)。正如前面提到的，拥有理论基础实际上是允许有纪律的工程分析的关键。建筑工程的材料科学，电气工程的电磁理论，航空工程的空气动力学等等都是如此。

当然，工程学科的历史发展及其相关理论之间的相互作用通常比这个简单的解释所暗示的要复杂得多。工程经验被提炼成理论，然后理论促进更好的工程，然后再回来。然而，这里要认识到的重要一点是:传统的软件工程并没有这样一个潜在的理论。

有人可能会说，计算机科学为软件工程提供了基础理论，这也许是软件工程最初构思时的最初期望。然而，在现实中，计算机科学在很大程度上仍然是一门学术学科，主要关注一般的计算科学，但大多与工业中软件工程方法的创造分离开来。虽然来自计算机科学的“形式方法”提供了对软件进行一些有用的理论分析的希望，但实践者在很大程度上回避了这种方法(除了在一些专门领域，如精确数值计算的方法)。

因此，对于软件“工程”，经常存在着对立的方法论的循环，而没有一个真正的基础理论来统一它们。最后，这些方法中的许多甚至没有解决行业中熟练工艺从业者的真正需求。

那么，该如何进行呢?

创建一个完整的、新的软件工程理论将需要一些时间。正如前面所提到的，我们可以从捕获在软件开发过程中已被证明成功的方法之间的共性开始，而不是从学术方法开始。反过来，这又需要一种描述、理解和组合各种软件开发技术的通用方法，而不是使它们相互竞争。

要了解如何实现这一点，让我们进一步了解一下真正使用这些方法的方法和实践团队。

回到顶部

敏捷是方法，而不仅仅是软件

目前在软件开发中促进敏捷性的运动补充了对软件工艺的认可。顾名思义，敏捷软件开发是关于在面对不可避免的需求变化时提高灵活性和适应性。这是通过生产小增量的软件，在快速迭代中获得反馈，并在必要时不断调整来实现的。

敏捷软件开发团队负责他们自己的工作方式。这样的团队在需要的时候应用手头项目所需的方法，在整个项目中调整开发过程。实际上，敏捷团队需要像开发软件一样，以敏捷的方式发展和改进其方法。

方法缺乏敏捷性是传统软件工程的主要失败。

就其本质而言，软件具有延展性，并且(在物理上)易于更改。然而，复杂的软件系统可能表现出一种智力刚性，在这种情况下，很难正确地进行更改，因为每次更改都会引入与它所解决的相同多或更多的错误。面对这种情况，传统软件工程的反应是采用过程控制和项目管理技术，就像那些用于处理复杂硬件系统中类似问题的技术一样。

然而，从敏捷的角度来看，硬件工程技术的应用是一个错误。相反，敏捷技术利用了软件多变的特性，使用持续集成和集成测试允许的快速反馈周期来管理复杂性，而不是过程控制。因此，敏捷开发关注于支持从业者构建高质量的软件，而不是要求从业者支持整个过程。

那么，如何在软件工程方法中引入敏捷性呢?通过观察实践者实际做的基本事情。

回到顶部

方法来自实践

一个方法可能看起来是整体的，但是任何方法都可以被分析为由许多实践．实践是一种可重复的方法，在头脑中有一个特定的目的去做某事。实践是实践者实际做的事情做．

例如，极限编程的敏捷方法被描述为有12种实践，包括结对编程、测试驱动开发和持续集成。另一方面，敏捷框架Scrum引入了诸如维护backlog、每日Scrum和sprint等实践。Scrum并不是一个真正完整的方法，而是一个复合实践，由许多其他旨在协同工作的实践构建而成。然而，Scrum可以作为一个过程框架，结合极限编程的实践，形成敏捷团队所使用的方法。

这证明了明确考虑方法是如何由实践组成的力量。团队可以将最适合手头开发任务和所涉及的团队成员的技能的实践结合在一起。此外，在必要时，团队不仅可以在小步骤中改进方法，还可以在更激进和更大的步骤中改进方法，例如用更好的实践替换旧的实践(而不必更改任何其他实践)。

注意焦点是如何集中在团队和团队中的实践者，而不是“方法工程师”，他们创建方法供其他人执行。然而，对于许多团队来说，创造自己的工作方式是一种新的责任，而且也有必要支持团队在跨项目中这样做的能力。因此，在任何特定项目之外，为对创建和扩展实践感兴趣的小组提供实践也是有用的，这样它们就可以被项目团队适当地使用。

这可以看作是关注点的分离:实践可以在组织内部创建和发展，甚至可以由跨组织的行业组创建和发展(例如极限编程和Scrum就是有效的例子);然后，项目团队中的从业者可以适当地采用、适应并应用这些实践。

项目团队如何保证不同创建的实践实际上可以顺利地结合起来产生有效的方法?这就是需要一个新的软件工程基础的地方，它独立于实践和方法，但能够为它们提供一个共同的基础。

回到顶部

核心是实践和方法的基础

SEMAT计划的第一个切实的成果就是所谓的软件工程内核。这个内核可以被认为是对所有软件开发工作都通用的最小集合。内核由三个部分组成:

• 衡量一项努力的进展和成效的一种方法。
• 为推进一项努力的进展所必需的活动的分类。
• 执行这些活动所需的一套能力。

特别重要的是有一个共同的方法来理解一个努力是如何进展的。SEMAT内核定义了七个维度来度量这个进程，称为alpha。(这个词α最初是抽象级别进度运行状况属性的首字母缩写，但现在只是用来表示内核中定义的进度和运行状况维度。考虑了许多其他现有术语，但所有术语的含义都与为内核引入的新概念相冲突。最后，一个没有任何旧包袱的新术语被采用了。这七个维度是:机会、利益相关者、需求、软件系统、工作、团队和工作方式。这些之间的关系如图所示图1．

每个alpha都有一组特定的状态，这些状态将alpha所代表的进度维度上的点进行编码。每个状态都有一个检查表，以帮助执行者监视他们工作的当前状态，并了解他们下一步需要走向的状态。这个想法是为从业者提供一个直观的工具，以一种通用的、方法独立的方式来推断他们工作的进展和健康状况。

将阿尔法的七维空间可视化的一种方法是使用蜘蛛图¹所示图2．在这个图表中，灰色区域表示努力已经进行了多远，而白色区域表示在努力完成之前还需要完成什么。快速查看这样的图表可以很好地了解项目在任何时间点的位置。

通过将每个alpha状态放在一张卡片上，以及以缩写形式列出的状态清单(参见图3)．这样一来，所有这些扑克牌就可以很容易地放进一个人的口袋里。尽管还有更详细的指导方针，但是这些卡片包含了开发团队在日常工作中可以使用的关键提醒，就像其他学科的工程师手册一样。

关于内核及其应用的更完整的讨论可以在前面的文章中找到。^2，3.内核本身被正式定义为通过对象管理组标准化的本质规范的一部分。⁶除了完整的内核之外，Essence标准还定义了一种语言，它既可以用来表示内核，也可以用来描述内核方面的实践和方法。重要的是，这种语言旨在为实践者使用，而不仅仅是方法工程师;对于基本的使用，只需几个小时就可以学会(alpha状态卡就是一个例子)。

当然，这种使用内核描述实践的能力正是真正软件工程方法所需要的基础。

回到顶部

建立在内核之上的实践支持敏捷方法

实践可以用内核来表示:

• 确定推进努力的领域。
• 描述用于实现这一进展的活动和所产生的工作产品。
• 描述执行这些活动所需的具体能力。

实践还可以使用附加的状态、检查列表甚至新的alpha来扩展内核。

关键的一点是，内核为描述所有实践提供了一个公共框架，并允许将它们组合成方法。在这个公共系统中引入一组实践，可以更容易地识别差异和重叠。然后可以用额外的实践来填补空白，并通过适当地将重叠的实践连接在一起来解决重叠。

例如，考虑两个实践:一个是使用待办事项安排来管理要由团队执行的工作(推进工作alpha);另一个是使用用户描述定义需求(推进需求alpha)。待办事项安排实践没有规定待办事项安排中的项目必须是什么，而用户故事实践没有规定团队应该如何管理这些故事的实现。因此，这两种做法是互补的，可以一起使用，但当这样结合时，它们会重叠。这两个实践可以在一个整体的方法中以一种流畅而直观的方式连接起来，方法是将待办事项列表中的项目与另一个的用户故事标识出来，这样用户故事就成为待办事项列表中管理的项目。

特别要注意，内核的公共框架如何提供一个预测能力。建筑工程师可以利用材料科学和结构理论，在早期阶段就了解一座拟建的建筑是否有可能屹立或倒塌。类似地，使用内核，软件开发人员可以了解所提议的方法是否构造良好，以及，如果在实践中存在差距或重叠，如何解决这些问题。

此外，通过前面讨论的关注点分离，组织或社区可以建立一个实践库，甚至是一个新的项目团队可以利用的基本方法，以形成其最初的工作方式。然后，每个团队可以在公共的Essence框架中继续敏捷地适应和发展自己的方法。⁴

最终，作为一个行业，目标将是提供特别有用和成功的实践的标准化，同时增强(而不是限制)团队在应用和适应这些实践方面的敏捷性，以及在必要时构建新的实践。最后，这是通向软件工程真正学科的道路。

回到顶部

结论

这个词思考模式的转移现在可能有点用过头了;然而，基于内核的软件工程的本质方法可以相当合理地被认为是这样一种转变。它确实代表了软件工程社区观点的深刻改变。

当托马斯·库恩在他颇具影响力的书中引入范式转变的概念时，科学革命的结构，⁵他强调了将一种范式的语言和理论翻译成另一种范式的困难(库恩甚至声称不可能)。软件开发社区实际上已经看到了这样的转变，那些沉浸在旧范式中的人甚至很难理解新范式是关于什么的。向面向对象的转变就是这样一种转变，就像当前向敏捷方法的转变一样。

在这方面，《本质》确实可以从两个方面被认为是范式的转变。首先，那些沉浸在软件工程“老派”的人必须开始思考真正的软件工程，而不是仅仅应用从其他工程学科改编的实践。其次，那些在软件工艺和敏捷社区中的人需要将真正的工程规程的开发看作是他们的(刚刚来之不易的)工艺规程的必要演变。

关于第二点，在他的前言中软件工程的本质:应用SEMAT内核，^3.Robert Martin是SEMAT的签署人之一，他描述了从软件工程向软件工艺的典型摆动。马丁的评价是正确的，但重要的是要注意到，这个众所周知的钟摆不应该简单地朝它来的方向摆动。相反，虽然它必须摆动，但它现在几乎需要摆动90度不同的方向它就是从那里来的，为了走向一门真正的软件工程的新学科。

也许，几乎没有比这更好的典范转变的形象了。最后，软件工程的新范式，虽然建立在软件工艺的当前范式之上，但必须超越它，但它也将是对传统软件工程的旧范式的转变。而且，就像以前所有的范式转变一样，这一转变在完成之前将需要相当多的时间和努力，到那时，作为新的范式，每个人都会认为它的好处是显而易见的。

尽管如此，使用Essence仍然可以为团队提供一些关键的好处。Essence帮助团队在使用方法时保持敏捷，并根据涉众感兴趣的实际结果和结果来度量进展。这些进度度量不只是在一个维度上进行的，而是沿着内核alpha的七个维度进行的，所有这些都需要以一定的速度进行，以减少风险并实现结果。

此外，Essence可以允许组织使用项目团队可以采用和调整的实践池来简化方法的治理。将“本质”作为一个共同的基础，也允许从业者更容易地相互学习。

然而，真正的转变只有当团队真正意识到Essence的好处，以及SEMAT在Essence上构建以完成新的软件工程范式时才会出现。一个从业者社区现在正在贡献他们的经验，成为软件工程“重建”的一部分，或者，也许是真正的第一次建立它。

相关文章
在queue.acm.org

软件工程的本质:SEMAT内核
Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence和Svante Lidman
http://queue.acm.org/detail.cfm?id=2389616

首先，不伤害:软件开发人员的希波克拉底誓言
菲利普·a·Laplante
http://queue.acm.org/detail.cfm?id=1016991

使用代码映射进行软件开发
罗伯特·德琳，吉娜·维诺莉娅和凯尔·罗文
http://queue.acm.org/detail.cfm?id=1831329

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2014 ACM, Inc.