下载本文的PDF版本 PDF

软件工程的本质:SEMAT 内核

一种可操作内核形式的思考框架


Ivar Jacobson,Pan-Wei Ng,Paul E. McMahon,Ian Spence,Svante Lidman


每个开发软件的人都知道这是一项复杂且有风险的业务,参与者总是在寻找能够带来更好软件的新想法。幸运的是,软件工程仍然是一个年轻且不断发展的专业,每年都会出现最佳实践的创新和改进。例如,看看精益和敏捷思维为软件开发团队带来的改进和好处。

成功的软件开发团队需要在快速交付可工作的软件系统、满足利益相关者、应对风险和改进工作方式之间取得平衡。为此,他们需要一个有效的思考框架,以弥合他们当前的工作方式与他们想要采用的任何新想法之间的差距。本文以可操作内核的形式提出了这样一个思考框架,它可以使任何希望平衡风险和改进工作方式的团队受益。

灵感

关于内核(软件工程的本质)的工作受到了 SEMAT(软件工程方法和理论)行动号召的启发,并且是对其的直接回应(见图 1)。它以其自身的方式,是朝着重新定义软件工程迈出的一小步。

SEMAT 由 Ivar Jacobson、Bertrand Meyer 和 Richard Soley 于 2009 年 9 月创立,他们认为从根本上改变人们使用软件开发方法的方式的时机已经到来。3,4,8 他们撰写了一份行动号召声明,该声明在几行中指出了许多关键问题,解释了为什么需要采取行动,并提出了需要做什么。行动号召是:

当今软件工程的某些领域存在不成熟的实践。具体问题包括:

• 赶时髦的现象盛行,这更像时尚界而不是工程学科。

• 缺乏健全、广泛接受的理论基础。

• 方法和方法变体数量庞大,差异鲜为人知且被人为地放大。

• 缺乏可信的实验评估和验证。

• 行业实践与学术研究之间的脱节。

SEMAT 行动号召断言软件行业容易赶时髦,这导致一些人认为 SEMAT 抵制新想法。这与事实相去甚远。正如您将在本文和即将出版的书籍(软件工程的本质——应用 SEMAT 内核6 中看到的那样,SEMAT 支持者非常热衷于新想法。他们反对的是非精益、非敏捷的行为,这种行为源于人们仅仅因为相信这些解决方案很时髦——或者因为同侪压力或政治正确性——而采用不合适的解决方案。

SEMAT 支持基于坚实的理论、经过验证的原则和最佳实践来重新定义软件工程的流程,这些流程:

• 包括广泛认可的要素内核,可针对特定用途进行扩展。

• 同时解决技术问题和人员问题。

• 得到行业、学术界、研究人员和用户的支持。

• 支持在面对不断变化的需求和技术时进行扩展。

SEMAT 行动号召获得了广泛的支持,包括越来越多的签署者和支持者列表 (http://www.semat.org)。2010 年 2 月,SEMAT 创始人将行动号召发展成为愿景声明。5 根据这一愿景,SEMAT 专注于两个主要目标:

• 找到一个广泛认可的要素内核

• 定义坚实的理论基础

在很大程度上,这两项任务彼此独立。寻找内核及其要素是一项务实的练习,需要经验丰富的软件开发人员,他们了解许多现有方法。定义理论基础是学术研究,可能需要多年才能取得成功的结果。

共同基础的力量

SEMAT 的第一步是确定软件工程的共同基础。这个共同基础体现为一个基本要素内核,这些要素对所有软件开发工作都是通用的,以及一种用于描述方法和实践的简单语言。内核最初在 SEMAT OMG(对象管理组)提交中发布。2,9 如图 1 和图 2 所示,内核包含少量“我们始终使用的东西”和“我们开发软件系统时始终做的事情”。定义“我们始终需要拥有的技能”的工作也在进行中,但这将不得不等到内核的未来版本。

内核不仅仅是一个概念模型,它还提供:

• 团队思考他们正在取得的进展以及他们的努力是否健康的思考框架。

• 用于讨论、改进、比较和共享软件工程方法和实践的共同基础。

• 一个框架,供团队通过组合单独定义和来源的实践来组装和持续改进其工作方式。

• 用于定义独立于实践的度量的基础,以评估所生产软件的质量和用于生产软件的方法。

• 最重要的是,帮助团队了解他们所处的位置、下一步应该做什么以及需要改进的地方的方法。

大创意

是什么让内核不仅仅是软件工程的概念模型?这里真正的新颖之处是什么?这可以概括在其基本原则中(见图 3),这些原则真正突出了内核的三个独特特征:它是可操作的;它是可扩展的;它是实用的。

内核是可操作的

内核的一个独特特征是它处理“要使用的东西”的方式。这些被捕获为阿尔法而不是工作产品(例如文档)。阿尔法是软件工程努力的基本要素——与评估其进展和健康状况相关。如图 1 所示,SEMAT 已经确定了七个阿尔法:机会、利益相关者、需求、软件系统、工作、工作方式和团队。

阿尔法的特征是一组简单的状态,这些状态代表它们的进展和健康状况。例如,软件系统经历以下状态:架构已选择:可演示、可用、就绪、可操作和已停用。每个状态都有一个清单,其中指定了达到该状态所需的标准。这些状态使内核可操作,并使其能够指导软件开发团队的行为。

内核将软件开发呈现为一个协作元素网络,而不是线性过程,这些元素需要平衡和维护,以便团队能够取得有效和高效的进展,消除浪费并开发出色的软件。内核中的阿尔法为驱动和推进软件开发工作提供了一个总体框架,而与应用的实践或遵循的理念无关。

随着实践被添加到内核中,阿尔法也将被添加以表示驱动或抑制内核阿尔法进展的事物。例如,需求阿尔法不会作为一个整体来处理,而是会逐项推进。单个需求项的进展将驱动或抑制需求阿尔法的进展和健康状况。需求项可以是多种不同类型:例如,功能、用户故事或用例切片,所有这些都可以表示为阿尔法并跟踪其状态。将这些较小的项目与更粗粒度的内核元素相关联的好处是,它可以跟踪整体工作的健康状况。这为较低级别的单个项目跟踪提供了必要的平衡,使团队能够理解和优化其工作方式。

内核是可扩展的

内核的另一个独特特征是它可以扩展以支持不同的项目(例如,新开发、遗留增强、内部开发、离岸开发、软件产品线等)。内核允许您添加实践,例如用户故事、用例、基于组件的开发、架构、结对编程、每日站立会议、自组织团队等,以构建您所需的方法。例如,可以为内部和外包开发或为安全关键的嵌入式系统和后台报表系统的开发组装不同的方法。

实践分离是这里的关键思想。虽然实践这个术语在行业中已经广泛使用了多年,但内核对实践的处理和共享有特定的方法。实践被呈现为不同的、独立的、模块化的单元,团队可以选择使用或不使用。这与传统的处理方法不同,传统方法将软件开发视为无法区分的实践的混合物,并导致团队在从一种方法转移到另一种方法时,将好的和坏的一起抛弃。

内核是实用的

内核最重要的特征也许是在实践中使用它的方式。传统的软件开发方法往往侧重于支持流程工程师或质量工程师。相比之下,内核是一个实践性的、有形的思考框架,专注于支持软件专业人员执行他们的工作。

例如,内核可以通过卡片来接触和使用(见图 4)。7,10 这些卡片为团队成员在进行日常任务时提供简洁的提醒和提示。通过提供实用的清单和提示,而不是概念性的讨论,内核成为团队每天使用的东西。这与传统方法存在根本差异,传统方法往往过分强调方法描述而不是方法使用,并且往往只供团队新成员咨询。

卡片提供简洁的描述,作为团队成员的提醒。他们可以将内核作为一小叠卡片放在口袋里,他们可以轻松地将其取出以讨论当前的开发状态以及团队成员之间的工作分配和协作。团队还可以通过参考卡片来讨论改进领域。因此,内核不仅仅是对团队需要做什么的繁重描述。相反,它构成了他们每天所做工作的重要组成部分。

内核在行动中

内核在软件专业人员的日常生活中有很多应用。它们包括:

• 运行迭代(或冲刺)。

• 运行从想法到产品的整个开发过程。

• 扩展到大型组织和复杂的软件开发工作。

第一个应用,规划迭代,在这里用作团队可以使用内核的一个例子。《软件工程的本质——应用 SEMAT 内核》6 全面介绍了其他应用。

这里提出的例子假设一家公司在正式流程方面很少。过去,它依赖于在经验丰富的团队中拥有熟练且有创造力的人员,但该公司现在正在发展壮大,并有许多新员工。这些新员工大多是刚从大学毕业的,他们拥有良好的技术技能——例如,在编程语言方面——但在软件开发的其他方面装备不足,例如与利益相关者合作以就需求达成一致。

这家公司有一个开发团队,负责开发一个移动社交网络应用程序,让用户可以分享和浏览想法、照片和评论。该团队最初只有两名开发人员,Smith(团队负责人)和 Tom,他们都熟悉内核。后来又有两名开发人员 Dick 和 Harriet 加入,他们是新入职的,并且以前不了解内核。对于团队负责人 Smith 来说,成功不仅仅意味着功能、进度和质量。这个团队以迭代方式进行开发。您可以将迭代计划视为如下:

1. 确定您所处的位置:确定当前工作的状态。

2. 确定要去哪里:决定接下来要强调什么以及下一个迭代的目标是什么。

3. 确定如何到达那里:就团队需要完成的任务以实现目标达成一致。

确定团队使用内核的位置

假设 Smith 和他的团队已经开发了六周。他们向利益相关者提供了系统的早期演示,利益相关者对此感到满意并提供了宝贵的反馈。但是,该系统尚未供最终用户使用。如果您正在使用阿尔法状态卡,那么您可以按如下方式进行演练:

1. 将每张阿尔法的卡片在一张桌子上排成一排,第一张状态在左侧,最后一张状态在右侧。

2. 遍历每个状态并询问您的团队是否已达到该状态。

3. 如果已达到该状态,请将该状态卡向左移动。继续下一张卡片,直到您到达您的团队尚未达到的状态。

4. 将此状态卡和其余待定状态卡向右移动。

图 5 显示了 Smith 团队已达到的状态在左侧,而尚未达到的状态在右侧。为简单起见,图 5 仅显示了三个内核阿尔法。

确定使用内核要去哪里

一旦团队就当前的阿尔法状态达成一致,成员们就会讨论下一个期望的“目标”状态是什么,以指导他们的计划。团队同意使用紧邻的下一个阿尔法状态来帮助确定下一个迭代的目标,如图 6 所示。



他们计划如何实现这些目标

α 工作方式

Dick 和 Harriet 都同意他们在应用自动化测试方面遇到了困难。他们需要帮助才能取得进展。Tom 同意他必须花时间教他们:

在迭代待办事项列表中添加了一项任务,让 Tom 为 Dick 和 Harriet 进行自动化测试培训。

任务 1. 进行自动化测试培训。

α 软件系统

此状态提醒我们,软件系统必须显示出具有足够的质量和功能,才能对用户有用。到目前为止,Smith 的团队一直在其开发环境中进行测试。现在,他们必须在验收测试环境中进行测试,而他们尚未准备好该环境。这导致了以下任务:

任务 2. 准备验收测试环境。

任务 3. 完成需求项 A:“在线和离线浏览”。

任务 4. 完成需求项 B:“发布评论(在线和离线)”。

任务 5. 完成需求项 C:“浏览相册”。

α 需求

此状态提醒我们需要与利益相关者合作,以确保他们对所生产的系统感到满意。在我们的故事中,Smith 必须与客户代表 Angela 合作,以确定需要实施哪些额外的需求项。这导致了额外的任务:

任务 6: 与 Angela 交谈并商定其他需求项,使其适合迭代,以使系统值得运行。

阿尔法状态的名称暗示了达到状态需要实现的目标。团队成员可以通过阅读和理解阿尔法状态清单来了解更多信息。通过逐个遍历每个阿尔法的状态,团队可以快速熟悉达到每个状态所需的内容。通过这种方式,团队在确定其当前的开发状态和下一个目标状态的同时,也了解了内核阿尔法。

确定如何使用内核到达那里

Smith 和他的团队查看下一个目标状态,并同意他们需要确定一些优先级。首先,他们需要拥有工作方式:良好工作;然后是软件系统:可用;最后是需求:已解决。原因很简单;没有工作方式:良好工作会阻碍他们获得软件系统:可用的尝试。此外,他们还就实现需求:已解决状态所需的缺失需求项的优先级达成一致。

接下来,Smith 和他的团队讨论了实现这些状态需要做什么,如表 1 所示。通过遍历目标阿尔法状态,Smith 能够确定下一个迭代的一组目标和任务。

内核如何在迭代计划中提供帮助

一个好的计划必须是包容性的,这意味着它包括所有基本项并涵盖整个团队。它还必须是具体的,以便团队可以采取行动。团队还必须有一种方法来监控其计划的进展情况。内核帮助您实现这一点,如下所示:

包容性。 内核阿尔法充当跨软件开发不同维度的提醒,帮助创建以平衡方式解决所有维度的计划。

具体。每个阿尔法状态的清单都暗示了您在迭代中需要做什么。相同的清单通过明确您已完成的工作并将此与您打算做的工作进行比较,来帮助确定您的进展。

现实世界中的内核

虽然这里提出的想法对你们中的许多人来说是新的,但它们已经在现实世界中被行业和学术界成功应用(见图 7)。在所有情况下,这些小组都使用了 Ivar Jacobson International 开发的内核和实践。1,10 内核理念的早期采用者包括:

• MunichRe,世界领先的再保险公司,在那里组装了一系列“协作模型”,以涵盖软件和应用工作的整个范围。四个协作模型——探索型、标准型、维护型和支持型——建立在来自同一组 12 个实践的同一内核之上。

• Fujitsu Services,Apt 工具包建立在早期版本的软件工程内核之上,包括敏捷和瀑布工作方式。1

• 一家主要的日本消费电子公司,其软件流程已在早期版本的内核之上定义,帮助团队应用新实践并管理离岸开发供应商。

• KPN,在向迭代开发过渡的过程中,基于内核的流程被 13 个项目中的 300 多个项目采用。内核还为新的以结果为中心的 QA 流程奠定了基础,该流程可以应用于所有项目,而与使用的方法或实践无关。

• 英国政府的一个主要部门,引入了基于内核的敏捷工具集,以实现规范的敏捷性,并以独立于实践的方式跟踪项目进展和健康状况。

内核已在瑞典皇家理工学院 KTH 的一年级和二年级软件工程课程中使用。在一年级课程的学生完成他们的项目后,他们在 Anders Sjögren 的指导下,经历了 SEMAT 阿尔法并将它们与他们的项目结果相匹配。学生有机会熟悉和评估阿尔法,并深入了解项目的进展和健康状况。在 Mira Kajko-Mattsson 运行的二年级课程中,要求学生在使用他们遵循的开发方法的同时,使用 SEMAT 内核运行他们的项目。Kajko-Mattsson 创建了一个软件开发场景,并针对每个阿尔法、其状态和状态清单项对其进行了评估。然后要求学生在进行和评估他们的项目时也这样做。

这些课程的经验提供了宝贵的教训。例如,内核确保在一个项目中考虑软件工程的所有基本方面。通过将项目结果与内核阿尔法进行匹配,学生可以轻松识别其开发方法的优点和缺点。内核还以最少的教学工作为学生未来的软件工程工作做好了准备。通过遵循所有内核阿尔法,学生可以了解软件工程工作的总体范围,从而了解他们在未来作为专业人员需要什么。

内核如何与敏捷和其他方法相关

内核可以与所有流行的管理和技术实践一起使用,包括 Scrum、看板、风险驱动的迭代、瀑布、用例驱动的开发、验收测试驱动的开发、持续集成和测试驱动的开发。它将帮助团队开始开发新的和创新的软件产品,以及增强和维护已建立的软件产品。它将帮助各种规模的团队,从单人团队到 1,000 人的强大软件工程项目。

例如,内核支持敏捷宣言的价值观。凭借其对清单和结果的关注,以及其固有的实践独立性,它重视个人和互动胜过流程和工具。凭借其对专业软件开发团队需求的关注,它重视工作方式和履行团队职责胜过方法。

内核绝不会与现有方法竞争,无论是敏捷方法还是任何其他方法。相反,内核对团队选择的方法持不可知态度。即使团队已经在使用特定方法,内核仍然可以提供帮助。正如 Robert Martin 在他为软件工程的本质所作的序言中指出的那样,无论使用何种方法,项目——甚至是敏捷项目——都可能失控,当它们失控时,团队需要了解更多信息。这才是内核的真正价值所在。它可以指导团队采取必要的行动以重回正轨,扩展其方法,或解决其工作方式中的关键差距。它专注于软件专业人员的需求,并重视“方法的使用”而不是“方法定义的描述”(过去的正常优先级)。

内核不仅支持现代最佳实践;它还认识到已经开发了大量软件并且需要维护。它将存在数十年,并且必须有效地维护。这意味着您使用此软件的方式必须随着软件本身的发展而发展。需要以与已使用的实践互补的方式引入新实践。内核提供了将遗留方法从单体瀑布方法迁移到更现代的敏捷方法以及更进一步的机制,以进化方式进行。它允许您逐个实践地更改您的遗留方法,同时保持和提高团队的交付能力。

内核将如何帮助您

使用内核对经验丰富或有抱负的软件专业人员以及他们所在的团队有很多好处。例如,它可以帮助您评估软件开发工作的进展和健康状况,评估当前的实践,并改进您的工作方式。它还可以帮助您改进沟通、更轻松地在团队之间转移以及采纳新想法。它将通过提高团队、供应商和开发组织之间的互操作性来帮助整个行业。

通过为软件方法的定义提供独立于实践的基础,内核还具有彻底改变方法定义和实践共享方式的力量。例如,通过允许团队混合和匹配来自不同来源的实践,以构建和改进其工作方式,内核解决了行业面临的两个关键方法论问题:

• 团队不再受其方法的束缚;他们可以在情况需要时通过添加或删除实践来不断改进其工作方式。

• 方法学家不再需要浪费时间描述完整的方法;他们可以以简洁且可重用的方式轻松描述他们的新想法。

最后,内核使学术界受益。内核为创建软件工程的基础课程奠定了基础,然后可以在初始教育课程中或在学生的职业生涯后期补充特定实践的附加课程。同样重要的是内核作为共享参考模型和进一步研究和实验的推动者的能力。

参考文献

1. Azoff, M. 2011. Apt 方法和工具,Fujitsu。Ovum 技术报告,参考代码 O100032-002(1 月)。

2. Fujitsu,Ivar Jacobson International AB,Model Driven Solutions。2012 年。本质——软件工程的内核和语言。初始提交,版本 1.0。

3. Jacobson I.,Meyer B. 2009 年。方法需要理论。Dr. Dobb's Journal

4. Jacobson I.,Meyer B.,Soley R. 2009 年。行动号召:SEMAT 倡议。Dr. Dobb's Journal

5. Jacobson I.,Meyer B.,Soley R. 2009 年。SEMAT 愿景声明。

6. Jacobson I.,Pan-Wei Ng,McMahon P.,Spence I.,Lidman S. 2013 年。软件工程的本质——应用 SEMAT 内核。 Addison-Wesley。(即将于 2013 年 1 月出版,但可在 safaribooksonline.com 上获得预出版版本。)

7. Jacobson I.,Pan-Wei Ng,Spence I. 2007 年。受够了流程——让我们做实践。Journal of Object Technology 6(6): 41-67。

8. Jacobson I.,Spence I. 2009 年。为什么我们需要软件工程理论。Dr. Dobb's Journal

9. OMG(对象管理组)。2012 年。提案请求书 (RFP)。敏捷创建和实施软件工程方法的基础。

10. Pan-Wei Ng,Magee M. 2010 年。使用状态卡的轻量级应用程序生命周期管理。Agile Journal(10 月)。

喜欢还是讨厌?请告诉我们

[email protected]

Ivar Jacobson 博士,Ivar Jacobson International 的主席,是组件和组件架构、用例、统一建模语言和 Rational 统一过程之父。他为现代业务建模和面向方面软件开发做出了贡献。他是北京大学国际荣誉顾问,并拥有秘鲁圣马丁德波雷斯大学的荣誉博士学位。

Pan-Wei Ng 博士 指导涉及数百万行代码和每个版本数百人的大型系统开发,帮助他们过渡到精益和敏捷的工作方式,同时不忘改进他们的代码和架构,并通过用例和方面进行测试。他是 Aspect-oriented Software Development with Use Cases(与 Ivar Jacobson 合著)的合著者。他相信使事物有形且实用,并且一直是内核背后思想的积极贡献者,包括状态卡的使用。

Paul McMahon ([email protected]) 是一位独立顾问,专注于在受限环境中指导项目经理、团队负责人和软件专业人员实际使用精益和敏捷技术。他是认证 ScrumMaster 和认证精益六西格玛黑带。自 SEMAT 倡议成立以来,他一直是该倡议的领导者。他发表了 40 多篇关于软件开发的文章,并且是两本书的作者。

Ian Spence 是 Ivar Jacobson International 的 CTO,也是 SEMAT 内核开发的团队负责人。作为一名经验丰富的教练,他已将数百个项目引入迭代和敏捷实践。他还领导了许多成功的大规模转型项目,与多达 5,000 人的开发组织合作。他目前的兴趣是大型项目的敏捷性、敏捷外包以及通过敏捷度量推动可持续变革。

Svante Lidman, 在行业内拥有 25 年的经验,在构建高性能企业软件开发团队方面拥有丰富的经验。他曾在 Hansoft AB、Ivar Jacobson International、Microsoft、Rational Software、Objectory 和其他公司担任过开发经理、项目经理、项目主管、顾问和培训师等职位。在过去的五年里,他专注于精益/敏捷的采用。从 2010 年年中开始,Lidman 成为斯堪的纳维亚半岛有史以来规模最大的精益/敏捷转型的主要变革推动者。

© 2012 1542-7730/11/1000 $10.00

acmqueue

最初发表于 Queue 杂志第 10 卷,第 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 年首次引入,并在后来普及,就是这些成熟的解决方案之一。





© 保留所有权利。

© . All rights reserved.