PDF一种新的软件工程
对于软件开发，严谨、规范、专业的实践承诺发生了什么变化？
Ivar Jacobson 和 Ed Seidewitz，Ivar Jacobson International
软件工程怎么了？对于软件开发，像其他工程学科中观察到的那样，严谨、规范、专业的实践承诺发生了什么变化？
在“软件工程”的名义下被采用的是一套主要从其他工程学科改编而来的实践：项目管理、设计和蓝图、过程控制等等。基本的类比是将软件视为一种制造产品，所有真正的“工程”都在上游进行——在需求分析、设计、建模等等中。
在其他工程学科中以这种方式工作是有道理的，因为前期工作是基于坚实的基础理解，因此结果可以信任。软件工程没有这样的基础，因此“大型前期设计”往往没有回报。实际上，软件工程的精神倾向于贬低程序员（如果不是明确地，那么也是通过控制实践隐含地）。然而，程序员是那些实际上必须使软件工作的人——他们确实做到了，无论设计“蓝图”说应该做什么。
毫不奇怪，这导致了很多不满。
今天的软件工艺运动是对工程方法的一种直接反应。这场运动专注于软件开发的工艺，质疑对软件进行工程是否真的有意义。这是否是更明智的观点？
由于最终必须使代码工作，因此从一开始就专注于制作高质量的代码似乎是明智的。编码作为一种工艺学科，可以建立在软件“大师”的经验之上，引导社区构建更好、更好的代码。此外，敏捷开发的许多技术实践使得使用工艺方法创建大型高质量软件系统成为可能——否定了最初软件工程所有前期活动的主要动力。
然而，最终，工艺学科只能带你走这么远。从古代到中世纪，熟练的工匠和技工创造了许多奇妙的结构，从金字塔到哥特式大教堂。不幸的是，这些结构的建造非常昂贵且耗时——而且有时会因原因不明的原因而灾难性地倒塌。
现代结构，如摩天大楼，只有在真正工程方法发展起来后才成为可能。现代建筑工程在材料科学和结构理论方面有着坚实的基础，建筑工程师使用这个理论基础作为仔细、规范的方法的基础，来设计他们要建造的结构。
当然，这样的结构有时仍然会失败。然而，当它们失败时，会再次进行彻底的分析，以确定故障是由渎职行为还是原始设计中使用的基础理论的缺陷造成的。然后，在后一种情况下，新的理解可以被纳入基础实践和未来的理论中。
建筑工程是真正的工程学科如何将工艺与应用理论基础相结合的一个例子。这种公认的基础中捕获的理解被用来教育该学科的入门者。然后，它为他们提供了方法论地分析和解决工程问题的基础，即使这些问题超出了工程师的经验范围。
从这个角度来看，今天的软件工程根本不是真正的工程学科。
相反，需要的是一种建立在软件工匠经验之上的新软件工程，将他们的理解捕捉到一个基础中，然后可以用来教育和支持新一代的从业者。因为工艺实际上完全是关于从业者的，而工程理论的全部意义在于支持从业者，这本质上是以前的软件工程化身所缺少的。
软件社区如何着手“重建”软件工程的任务？
SEMAT（软件工程方法和理论）倡议是一项致力于回答这个问题的国际努力 (http://www.semat.org)。顾名思义，SEMAT 既关注于支持工艺（方法），也关注于构建基础理解（理论）。
这仍然是一项正在进行的工作，但一种新的软件工程的本质正在变得清晰。本文的其余部分探讨了这种本质是什么，以及它对该学科未来的意义。
工程是由理论支撑的工艺
方法（等同于方法论或过程）是对开展某项事业（如开发软件）的工作方式的描述。最终，所有方法都源于在开展主题事业中哪些有效和哪些无效的经验。这种经验首先被提炼成经验法则，然后是指导方针，当达成共识时，最终成为标准。
在工艺学科中，方法主要由拥有必要长期经验的大师开发。在古代，大师的方法被严密保守，只传给值得信赖的学徒。然而，在今天的世界中，基于工艺大师工作的各种方法通常被广泛发布和推广。
当工艺发展成为工程学科时，重要的是要认识到各种大师的方法之间的共性，这种共性基于正在开展的事业的共同基础经验。这种共同的理解随后被捕捉到一个理论中，该理论可以用作应用于该事业的所有不同方法的基础。
从这个意义上讲，理论并不是在我们文化中有时被视为的坏词（“哦，那只是一个理论”）。正如前面提到的，事实上，拥有理论基础是允许进行规范工程分析的关键。材料科学对于建筑工程、电磁理论对于电气工程、空气动力学对于航空工程等等都是如此。
当然，工程学科的历史发展与其相关理论之间的相互作用通常比这个简单的解释所暗示的更复杂。工程经验被提炼成理论，然后理论促进更好的工程，然后又反过来。然而，这里要意识到的重要一点是：传统的软件工程没有这样的基础理论。
有人可能会建议，计算机科学为软件工程提供了基础理论——这也许是软件工程最初构想时的期望。然而，实际上，计算机科学仍然是一个主要以学术为主的学科，专注于一般的计算科学，但主要与工业界软件工程方法的创建分离。虽然来自计算机科学的“形式化方法”承诺对软件进行一些有用的理论分析，但从业者在很大程度上避开了这些方法（除了少数专业领域，如精确数值计算方法）。
因此，软件“工程”经常出现决斗方法论的循环，而没有真正的基础理论将它们统一起来。最终，许多这些方法甚至没有解决行业中熟练的工艺从业者的真正需求。
那么，如何进行呢？
创建一个完整的新软件工程理论需要一些时间。正如已经提到的，我们可以从捕捉已证明在软件开发工艺中成功的方法之间的共性开始，而不是从学术方法开始。反过来，这需要一种通用的方式来描述、理解和组合各种软件开发技术，而不是将它们设置为彼此竞争。
为了了解如何实现这一点，让我们仔细看看方法和真正使用这些方法的从业者团队。
敏捷性适用于方法，而不仅仅是软件
当前在软件开发中推广敏捷性的运动补充了对软件工艺的认可。顾名思义，敏捷软件开发是关于在面对不可避免变化的需求时促进灵活性和适应性。这是通过小增量地生产软件、在快速迭代中获得反馈以及根据需要不断调整来实现的。
敏捷软件开发团队负责自己的工作方式。这样的团队根据手头项目的需要应用它认为需要的方法，并在整个项目中调整开发过程。实际上，敏捷团队需要以开发软件的敏捷方式来发展和改进其方法。
方法缺乏敏捷性是传统软件工程的一个核心失败。
软件本质上是可塑的，并且（物理上）易于更改。然而，一个复杂的软件系统可能会表现出一种智力上的僵化，在这种僵化中，很难正确地进行更改，每次更改都会引入与它解决的错误一样多或更多的错误。面对这种情况，传统软件工程的反应是采用过程控制和项目管理技术，例如用于处理复杂硬件系统的类似问题的技术。
然而，从敏捷的角度来看，应用硬件工程技术是一个错误。相反，敏捷技术利用了软件的可变性，使用持续集成和集成测试允许的快速反馈循环来管理复杂性，而不是过程控制。因此，敏捷开发侧重于支持从业者构建高质量的软件，而不是要求从业者支持过程。
那么，如何将敏捷性引入软件工程方法？通过查看从业者实际做的基本事情——他们的实践。
方法是由实践构成的
一种方法可能看起来是整体的，但任何方法都可以分析为由许多实践组成。实践是为达到特定目的而做某事的可重复方法。实践是从业者实际做的事情。
例如，敏捷方法极限编程被描述为具有 12 种实践，包括结对编程、测试驱动开发和持续集成。另一方面，敏捷框架 Scrum 引入了诸如维护积压工作、每日站会和冲刺等实践。Scrum 实际上不是一种完整的方法，而是一种由许多其他旨在协同工作的实践组成的综合实践。然而，Scrum 可以用作过程框架，并与来自极限编程等实践相结合，形成敏捷团队使用的方法。
这体现了明确考虑方法如何由实践构成的重要性。团队可以将最适合手头开发任务和团队成员技能的实践组合在一起。此外，在必要时，团队不仅可以小步发展其方法，还可以进行更激进和更大的步骤，例如用更好的实践替换旧实践（而无需更改任何其他实践）。
请注意，重点是如何放在团队和团队中的从业者身上，而不是“方法工程师”身上，后者为其他人创建方法来执行。然而，创建自己的工作方式是许多团队的新责任，并且还需要支持团队跨项目执行此操作的能力。因此，为有兴趣在任何特定项目之外创建和扩展实践的团体提供支持也很有用，以便他们可以根据项目团队的需要酌情使用这些实践。
这可以被看作是关注点的分离：实践可以在组织内部甚至跨组织行业团体（例如，极限编程和 Scrum 的情况）中创建和发展；项目团队的从业者可以根据需要采用、调整和应用这些实践。
项目团队有什么保证可以顺利地组合不同创建的实践以产生有效的方法？这就是需要新的软件工程基础的地方，它独立于实践和方法，但能够为它们提供共同的基础。
内核是实践和方法的基础
SEMAT 倡议的第一个切实成果是所谓的软件工程内核。这个内核可以被认为是所有软件开发事业通用的最小集合。内核由三部分组成
* 一种衡量事业进展和健康状况的方法。
* 对推进事业进展所必需的活动的分类。
* 一组执行此类活动所必需的能力。
特别重要的是拥有一种通用的方法来理解事业的进展情况。SEMAT 内核定义了七个维度来衡量这种进展，称为 alphas。（术语 alpha 最初是抽象级别进展健康属性的首字母缩写，但现在只是用作内核中定义的进展和健康维度的词。考虑了许多其他现有术语，但所有术语都与为内核引入的本质上新概念相冲突的内涵。最终，采用了一个新术语，没有任何旧的包袱。）七个维度是：机会、利益相关者、需求、软件系统、工作、团队和工作方式。这些 alpha 相互关联，如图 1 所示。
每个 alpha 都有一组特定的状态，这些状态对 alpha 所代表的进展维度上的点进行编纂。每个状态都有一个清单，以帮助从业者监控其事业在某个 alpha 上的当前状态，并了解他们需要朝着哪个状态前进。其想法是为从业者提供一个直观的工具，以一种通用的、独立于方法的方式来推理其事业的进展和健康状况。
可视化 alpha 七维空间的一种方法是使用蜘蛛图1，如图 2 所示。在该图中，阴影区域表示事业已取得的进展，而白色区域表示在事业完成之前仍需要完成的内容。快速浏览一下这样的图表，就可以很好地了解项目在任何时间点的状态。
通过将每个 alpha 状态放在卡片上，并在缩写形式的状态清单一起放在卡片上（见图 3），可以使 alpha 更加具体。所有此类卡片的牌组可以很容易地放入一个人的口袋里。虽然有更详细的指南，但这些卡片包含关键的提醒，开发团队可以在日常工作中使用这些提醒，就像其他学科的工程师手册一样。
先前的工作中提供了对内核及其应用的更完整讨论。2,3 内核本身被正式定义为 Essence 规范的一部分，该规范已通过对象管理组标准化。6 除了完整的内核外，Essence 标准还定义了一种语言，该语言既可以用于表示内核，也可以用于根据内核描述实践和方法。重要的是，这种语言旨在供从业者使用，而不仅仅是方法工程师；对于基本用途，它可以在几个小时内学会（alpha 状态卡片就是这方面的一个简单示例）。
当然，这种使用内核来描述实践的能力正是作为真正的软件工程方法的基础所需要的。
建立在内核之上的实践支持敏捷方法
实践可以用内核来表达，通过
• 识别其推进事业的领域。
• 描述用于实现此进展的活动和产生的工作产品。
• 描述执行这些活动所需的特定能力。
实践还可以使用附加状态、清单甚至新的 alpha 来扩展内核。
关键点在于，内核提供了一个通用框架来描述所有实践，并允许将它们组合成方法。将一组实践引入这个通用系统，可以更容易地识别差距和重叠。然后可以用额外的实践来填补差距，并通过适当地连接重叠的实践来解决重叠。
例如，考虑两个实践：一个关于使用积压工作来管理团队要执行的工作（推进工作 alpha），另一个关于使用用户故事定义需求（推进需求 alpha）。积压工作实践没有规定积压工作项必须是什么，而用户故事实践没有规定团队应如何管理这些故事的实现。因此，这两个实践是互补的，可以一起使用——但是，当这样组合时，它们会重叠。通过从一个中识别积压工作项，从另一个中识别用户故事，可以在整体方法中以平滑且直观的方式连接这两个实践，以便用户故事成为在积压工作中管理的项目。
请特别注意，内核的通用框架如何提供预测能力。建筑工程师可以使用材料科学和结构理论来尽早了解拟议的建筑物是可能站立还是倒塌。同样，使用内核，软件开发人员可以了解拟议的方法是否结构良好，以及其实践中是否存在差距或重叠，以及如何解决这些差距或重叠。
此外，通过前面讨论的关注点分离，组织或社区可以建立一个实践库，甚至基本方法库，新项目团队可以从中汲取灵感，形成其初始工作方式。然后，每个团队都可以在通用 Essence 框架内继续敏捷地调整和发展自己的方法。4
最终，行业的目标将是提供特别有用和成功的实践的标准化，同时增强而不是限制团队在应用和调整这些实践以及在必要时构建新实践方面的敏捷性。而这最终才是通往真正的软件工程学科的道路。
结论
术语范式转变现在可能有点被滥用了；尽管如此，基于内核的 Essence 软件工程方法可以相当合理地被认为是这样一种转变。它真正代表了软件工程界观点的深刻变化。
当托马斯·库恩在他的有影响力的著作《科学革命的结构》5中引入范式转变的概念时，他强调了将一种范式的语言和理论翻译成另一种范式的困难（库恩甚至声称是不可能的）。软件开发界实际上以前也见过这样的转变，在这种转变中，那些沉浸在旧范式中的人甚至难以理解新范式是怎么回事。转向面向对象是这样一种转变，在许多方面，当前转向敏捷方法也是如此。
在这方面，Essence 确实可以被认为是两个方面的范式转变。首先，那些沉浸在软件工程“旧学派”中的人必须开始专门考虑软件的真正工程，而不仅仅是应用主要从其他工程学科改编而来的实践。其次，软件工艺和敏捷社区需要将真正的工程学科的发展视为从他们（刚刚来之不易！）的工艺学科到必要演变。
关于第二点，在罗伯特·马丁（SEMAT 签署人之一）为《软件工程的本质：应用 SEMAT 内核》3所作的序言中，他描述了从软件工程转向软件工艺的经典钟摆摆动。马丁的评估是正确的，但重要的是要注意，这个谚语中的钟摆不应简单地向它来的方向摆动回去。相反，虽然它必须摆动，但它现在需要以几乎与它来的方向不同的 90 度方向摆动，以便朝着新的真正软件工程学科迈进。
对于范式转变来说，也许几乎没有比这更好的形象了。最终，新的软件工程范式在建立在当前的软件工艺范式之上的同时，必须超越它，但它也将是从传统的软件工程旧范式的转变。而且，像之前的所有范式转变一样，这一次将需要相当长的时间和努力才能完成——到那时，作为新范式，每个人都会认为它的好处是显而易见的。
即使在今天，使用 Essence 也可以为团队提供一些关键好处。Essence 帮助团队在处理方法时保持敏捷性，并根据利益相关者感兴趣的实际成果和结果来衡量进展。这些进展衡量标准不仅在一个维度上，而且沿着内核 alpha 的七个维度进行，所有这些维度都需要以一定的速度前进，以降低风险并取得成果。
此外，Essence 可以允许组织简化方法治理，使用项目团队可以采用和调整的实践池。将 Essence 作为共同基础也允许从业者更容易地相互学习。
然而，真正的转变只有在团队真正意识到今天 Essence 的好处，并且 SEMAT 在 Essence 的基础上完成新的软件工程范式时才会到来。一个从业者社区现在正在贡献他们的经验，并成为软件工程“重建”的一部分——或者，也许真的是第一次建立它。
参考文献
1. Graziotin, D., Abrahamsson, P. 2013。用于 SEMAT Essence 软件工程理论的基于 Web 的建模工具。《开放研究软件杂志》1(1): e4; http://dx.doi.org/10.5334/jors.ad.
2. Jacobson, I., Ng, P-W., McMahon, P., Spence, I., Lidman, S. 2012。软件工程的本质：SEMAT 内核。《》10(10); https://queue.org.cn/detail.cfm?id=2389616。
3. Jacobson, I., Ng, P.-W., McMahon, P. E., Spence, I., Lidman, S. 2013。《软件工程的本质：应用 SEMAT 内核》。Addison-Wesley。
4. Jacobson, I., Spence, I., Ng, P.-W. 2013。敏捷和 SEMAT—完美的合作伙伴。《 通讯》6(11); http://cacm.acm.org/magazines/2013/11/169027-agile-and-semat/abstract。
5. Kuhn, T. 1962。《科学革命的结构》。芝加哥大学出版社。
6. 对象管理组。2014。Essence—软件工程方法的内核和语言; http://www.omg.org/spec/Essence。
喜欢它，讨厌它？请告诉我们
Ivar Jacobson 是 Ivar Jacobson International 的创始人兼董事长。他是组件和组件架构、用例、面向方面的软件开发、现代商业工程、统一建模语言和 Rational 统一过程之父。
Ed Seidewitz 是 Ivar Jacobson International 美洲区前任首席技术官，目前是正在进行的 Essence 修订任务组主席。在 Ivar Jacobson International，他领导了商业和政府部门的敏捷系统架构和开发项目，并参与了实践开发。
© 2014 1542-7730/14/1000 $10.00
最初发表于 Queue 第 12 卷，第 10 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
虽然密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全需求驱动的密码哈希标准，但在非密码方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例是必不可少的
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的反复无常的影响，并且可能会忘记或忽略一些它面临的永恒问题的成熟解决方案。用例于 1986 年首次引入，后来普及，是这些成熟的解决方案之一。
© 保留所有权利。