论文阅读————Architectural Assumptions and Their Management in Industry – An Exploratory Study

Architectural Assumptions and Their Management in Industry – An Exploratory Study

Abstract.

我们对24名架构师进行了探索性案例研究，以分析架构假设及其在行业中的管理。我们确认了之前关于架构假设的调查的某些发现(例如，架构假设的术语和概念在工业中都不是常用的，涉众可能对架构假设的概念有不同的理解)。我们还发现了五个新发现:(1)架构师经常在工作中进行架构假设;

(2)架构假设概念主观化;

(3)架构假设是上下文相关的，并且具有动态性质(例如，在其生命周期中被证明是无效的，或者反之亦然);

(4)架构假设和某些类型的软件工件(例如，需求和设计决策)之间存在联系;

(5)确定了12个架构假设、管理活动和管理架构假设的4个好处。

Introduction

软件工程文献中研究了各种类型的假设，例如需求假设

[1],架构的假设

[10],以及代码级假设[2]，每个都关注软件开发生命周期的不同方面。 Architectural assumptions (AA1)我们将AA定义为:被认为是理所当然的架构知识，或者在没有证据的情况下被认为是真实的。

Related Work

从架构师的角度来看，目前还没有关于AA及其在软件开发中的管理的探索性案例研究。上述研究主要集中于提出和评估AA管理的方法，而本研究旨在探讨架构师如何看待AA以及AA管理的现有活动、实践、工具、挑战和好处。

Case Study

Goal and Research Questions

案例研究的目标,制定使用Goal-Question-Metric方法[3],是分析AA及其管理为目的的特征对理解AA和活动,实践、工具、挑战,以及AA的好处从架构师的角度管理软件开发在星航工程科从事行业的上下文中。

RQ1:架构师如何看待AA?

本RQ旨在探讨架构师如何通过定义和示例理解AA的概念，以及AA的特征和AA与其他软件工件(例如需求)之间的潜在关系。

RQ2:活动、实践、工具、挑战对AA的好处是什么?

本RQ旨在帮助研究人员和实践者对软件开发中的AA管理有一个实际的理解。

Case and Units of Analysis

因此，我们将此研究视为一个多元的、整体的案例研究[8]:每个架构师都是一个案例和一个分析单元。

(1)在我们的调查中，我们只采用问卷调查的方式来收集数据来回答RQs，而在本案例研究中，我们采用了访谈和焦点小组的方式来收集数据(两种不同的数据源有助于提高研究的有效性)。(2)调查对象为软件开发从业人员，包括项目经理、设计人员等不同角色，本研究的对象为架构师;(3)调查对象填写调查问卷并发表意见，本研究对象接受AA及其管理的辅导，并在自己的项目中实践管理AA;(4)本研究的范围是广泛的,因为它不仅扩展了从AA识别和记录(即调查)AA管理一般而言(即本研究),但也包括一些新的方面,如特征的AA和AA和其他软件构件之间的关系(例如,需求)。

Data Collection and Analysis

我们举办了五个工作坊(每个工作坊半天，包括半小时的导论AA和他们的管理)在中国北京、深圳和瑞典哥德堡，与来自10家公司和不同领域(如互联网的24名架构师和汽车工业收集数据。

个案研究采用三种资料收集方法:问卷调查法、访谈法和焦点小组法。

我们使用描述性统计分析定量答案(即研究对象的背景信息)，不断比较[7]进行定性答案(即从收集到的数据中生成概念和类别来回答RQs)。

Data collection method	Data analysis method	RQs
调查表	描述性统计	背景知识
面谈	Constant comparison	RQ1, RQ2
小组座谈会	持续比较	RQ1, RQ2

Results

Subjects Experience and Projects Information

Results of RQ1 – Perception of AA

AA的术语和概念

最后，受试者一致认为AA不仅在架构设计中很重要，在软件开发中也至关重要，AA的影响贯穿于整个开发过程，而不仅仅是在架构或设计阶段。

AA的概念是主观的，AA是上下文相关的，AA的动态特性，两个AA之间的关系可能是零。

主题列出了几个与AA相关的工件，包括需求、设计决策、设计模式、设计模型、组件和风险。

(1)“AA”这个词和概念在工业上都不是常用的。

(2)学科(架构师)在他们的工作中经常得到AA。

(3)利益相关者对AA概念可能有不同的理解。

(4) AA在架构设计和软件开发中都很重要。

(5) AA跨越整个软件开发生命周期。

(6) AA的概念是主观的。

(7)架构是情境相关的，具有动态性质。

(8)在AA和某些类型的软件工件之间存在联系。

Results of RQ2 – AA Management

(1)确定了12项AA管理活动。AA制作，描述，评价，维护、跟踪、监控、沟通、理解、重用、恢复、搜索和组织。

(2)受试者未采用系统的研究方法AA管理。

(3)受试者在5项AA管理活动中采用了9项没有指导方针的实践。

(4)管理学科使用的所有工具在软件开发中都是通用的。

(5)管理AA有八个挑战及四个好处。

Discussion

Interpretation of RQs Results

AA不仅在架构设计中很重要，在软件开发中也至关重要;它的生命周期贯穿于整个软件开发生命周期。一个原因可能是AA与各种软件工件相关，例如需求、设计决策、组件和风险。另一个原因是AA管理是团队合作，涉及到不同的利益相关者，而不仅仅是架构师。

AA跟踪有助于提高软件开发中AA和其他软件工件之间的可跟踪性，但是建立跟踪所需的工作可能是禁止的。

Implications for Researchers

尤其是在实证研究中评估AA管理的相关方法或工具时，研究人员需要做出决定:允许他们的研究对象对AA有自己的理解，还是执行一致的定义。

关于将AA管理集成到现有软件开发方法(例如，以决策为中心的架构评估方法)的进一步研究是有可能的。

Implications for Practitioners

我们主张将AA视为软件架构和软件开发中的一流实体，并将AA管理与软件开发中的现有流程、方法、工具等相结合。

我们建议项目中的从业者至少应该就AA是什么以及如何管理它们达成一致。

我们鼓励具有不同角色的从业者(例如，项目经理)参与管理AA。

我们鼓励有不同经验的从业员就架构及其管理进行讨论，以减轻这个问题。

Threats to Validity

注意，内部效度没有讨论在这篇论文，因为这工作不研究因果关系。

Construct validity

一个潜在的威胁是收集的数据是否能回答

External validity

然而，这些结果可能并不适用于其他环境(例如，项目经理和程序员);复制这个案例研究是减少这种威胁的一种方法。

Reliability

重点是当其他研究人员进行复制时，该研究是否会产生同样的结果。

Conclusions and Future Work

我们下一步的工作是:

(1)开发AA管理的方法，特别是在软件开发中建立一个通用的AA局管理过程;

(2)为AA管理层制订实务及指引，以应付个案研究中所发现的挑战;

(3)开发专用的AA管理工具。注意，我们的意图不是开发一个独立的工具，而是开发一个与现有软件开发工具集成的工具(例如，现有工具的插件)。