A Conceptual Model for Compliance Checking Support of Enterprise Architecture Decisions

Plataniotis, Georgios; Kinderen, Sybren de; Ma, Qin; Proper, Henderik A.

doi:10.1109/cbi.2015.46

Cited by 40 publications

(5 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Artificial Intelligence [35], [26], [33], [18], [8], [27], [25], [28], [11], [17], [30], [3] 12 35.29% Documentation Model [42], [38], [13], [21], [37], [45] 6 17.65%…”

Section: Papers Count Percentagementioning

confidence: 99%

See 1 more Smart Citation

Traceability of Architectural Design Decisions and Software Artifacts: A Systematic Mapping Study

Hyun,

Hurtado

2023

Foundations of Computing and Decision Sciences

View full text Add to dashboard Cite

The definition of architecture is a crucial task in software development, where the architect is responsible for making the right decisions to meet specific functional and quality requirements. These architectural design decisions form the foundation that shapes the arrangement of elements within a system. Unfortunately, these decisions are often poorly documented, implicit in various artifacts, or inadequately updated, leading to negative consequences on the maintainability of a system and resulting in rework and cost overruns. The objective of this systematic mapping study is to comprehend the current state regarding approaches for traceability of architectural design decisions and how these decisions are linked with the different artifacts used in software development. To achieve this, an information extraction protocol is followed, utilizing databases with search strings, inclusion, and exclusion criteria. The findings demonstrate that this knowledge is highly relevant; however, it is rarely explicitly documented. As a result, most works propose diverse approaches to extract this knowledge from existing technical documentation, commonly used tools, and other sources of product and process information. In contrast, it is evident that there is no standard for documenting design decisions, leading each author to present a subjective version of what is important and where to trace these decisions. This suggests that there is still a significant amount of research to be conducted regarding the traceability of these architectural design decisions and their connection with software artifacts. Such research could lead to intriguing new proposals for investigation.

show abstract

“…Artificial Intelligence [35], [26], [33], [18], [8], [27], [25], [28], [11], [17], [30], [3] 12 35.29% Documentation Model [42], [38], [13], [21], [37], [45] 6 17.65%…”

Section: Papers Count Percentagementioning

confidence: 99%

“…Papers Count Percentage Source code [35], [26], [33], [22], [24] 5 14.71% Requirements [18], [42], [38] 3 8.82%…”

Section: Artifactmentioning

confidence: 99%

Traceability of Architectural Design Decisions and Software Artifacts: A Systematic Mapping Study

Hyun,

Hurtado

2023

Foundations of Computing and Decision Sciences

View full text Add to dashboard Cite

show abstract

“…Regarding conceptual bases for NFRs and FRs linked to organizational goals we can consider [20], in which the goals are classified into business, enterprise architecture, or IT goals. The scope of the proposed vocabulary aims at designing decisionmaking strategies.…”

Section: Related Workmentioning

confidence: 99%

Applying an Improving Strategy that embeds Functional and Non-Functional Requirements Concepts

Becker

Tebes

Peppino

et al. 2019

JC&ST

View full text Add to dashboard Cite

Organizations should set and reach business goals for varied purposes using the suitable strategies. Basically, a strategy specifies the activities, methods and another related resources that should be considered in order to achieve a given goal purpose. Goal purposes and their associated strategies can aim at evaluating, testing, developing, or maintaining some entity. Some concrete evaluation purposes such as to understand or monitor can be achieved by strategies embracing non-functional requirements definition, measurement, evaluation and analysis activities. Other specific evaluation purposes such as to improve or control also imply changing the target entity; therefore, strategies should embrace functional requirements definition activities as well. Moreover, specific development and maintenance purposes always involve functional requirements. In this work, we relate business and information need goals with functional and nonfunctional requirements concepts, which are paramount for well-defined strategies. Therefore, we specify vocabularies for them, and illustrate the applicability of an improving strategy -which embeds these concepts-in the context of a running example. Having well-structured vocabularies serving as common ground for diverse strategies may promote a more effective operationalization of projects dealing with evaluation, testing, development and maintenance goal purposes.Objective: Determine the support level (user errors prevention) for mandatory entries in a given field. Author: Peppino -TebesVersion: 1.0Measurement Procedure: Type: Objective Specification:The expert inspects the screen (or window, or dialog) where is the given field to determine the rating (0, 1 or 2). Where 0 means that the mandatory data field has not any kind of visual indicator w.r.t. its mandatory nature; 1 means that the mandatory data field has some kind of indicator w.r.t. its mandatory nature, but it is not explicitly informed; and 2 means that the mandatory data field has a clear visual indicator of its mandatory nature and it is explicitly informed.

show abstract

“…Therefore this formalism does not support the impact analysis. Platianiotis et al [23] proposed a conceptual framework for tracing the EA design decisions to their rationals, however the method does not provide any formalism for the EA principles. Additionally, the framework proposed by van Zee et al [29] contains logic-based rules for verifying the integrity of EA decisions, but does not consider EA principles.…”

Section: Related Workmentioning

confidence: 99%

Formalizing and Modeling Enterprise Architecture (EA) Principles with Goal-Oriented Requirements Language (GRL)

Marosin

Zee

Ghanavati

2016

Advanced Information Systems Engineering

View full text Add to dashboard Cite

Abstract. Enterprise Architecture (EA) principles are normally written in natural language which makes them informal, hard to evaluate and complicates tracing them to the actual goals of the organization. In this paper, we present a set of requirements for improving the clarity of definitions and develop a framework to formalize EA principles with a semi-formal language, namely the Goal-oriented Requirements Language (GRL). We introduce an extension of the language with the required constructs and establish modeling rules and constraints. This allows us to automatically reason about the soundness, completeness and consistency of a set of EA principles. We demonstrate our methodology with a case study from a governmental organization. Moreover, we extend an Eclipse-based tool.

show abstract

A Conceptual Model for Compliance Checking Support of Enterprise Architecture Decisions

Cited by 40 publications

References 17 publications

Traceability of Architectural Design Decisions and Software Artifacts: A Systematic Mapping Study

Traceability of Architectural Design Decisions and Software Artifacts: A Systematic Mapping Study

Applying an Improving Strategy that embeds Functional and Non-Functional Requirements Concepts

Formalizing and Modeling Enterprise Architecture (EA) Principles with Goal-Oriented Requirements Language (GRL)

Contact Info

Product

Resources

About