scispace - formally typeset

Proceedings ArticleDOI

QuOnt: an ontology for the reuse of quality criteria

16 May 2009-pp 57-64

TL;DR: This work presents an ontology that supports the reuse of quality criteria in the input stage of software product audits and shows that the same quality criteria can be applied to different software products.

AbstractSoftware product audits are knowledge-intensive tasks in which architectural knowledge plays a pivotal role. In the input stage of a software product audit, quality criteria are selected to which the software product should conform. These quality criteria resemble architectural tactics and can be viewed as a definition of the Soll-architecture of the product. Like tactics, the same quality criteria can be applied to different software products. However, there are currently no models that support the codification of quality criteria as reusable assets. In this work, we present an ontology that supports the reuse of quality criteria in the input stage of software product audits.

...read more

Content maybe subject to copyright    Report

Citations
More filters

Dissertation
05 Oct 2009
TL;DR: To illustrate the effect of LSA on the document vector-space model, LSA was applied to the 8 documents from the audit that were still available, and both auditors seem to agree that there are two large document clusters.
Abstract: 2 1 1 2 4 5 5 5 5 5 concrete content 1 1 1 1 3 5 5 5 4 4 packing input for development 1 1 1 1 3 4 5 5 4 4 output of development descriptive / static 1 1 1 1 3 3 5 5 4 4 use / time dimension app. functionality 1 1 1 1 3 3 3 4 5 5 system administration design 1 1 1 1 3 4 3 5 5 5 deployment conceptual 1 1 1 2 2 4 3 4 5 5 concrete/instance high level 5 3 1 1 2 5 3 4 4 4 detailed absolute 1 1 1 1 3 5 2 2 2 2 relative (wrt prev. version) application 1 1 1 1 5 2 2 2 2 2 organisation used by me 4 2 1 2 5 2 1 1 3 3 not used by me analyzed, for instance to determine clusters of documents that contain similar documents. Figs. 16.6 and 16.7 depict the document clusters according to auditor 1 and 2 respectively. The clusters have been determined with the single linkage hierarchical clustering method (Johnson, 1967). The axis denotes the difference between the documents, calculated as 1 minus the similarity. For instance, for auditor 1 the similarity between documents FD and FM has been calculated as 0.87, therefore the difference between the two equals 0.13, as shown in Fig. 16.6. Although there are some differences between the two cluster configurations, both auditors seem to agree that there are two large document clusters. One cluster contains documents FD, FM, PD, and XX. The other documents are grouped in the second cluster. Note that we left AS and DB out of the figures to allow for a fair comparison with the effect of LSA. Recall that those two documents were no longer available, due to which LSA was unable to process them. Had we included them in the cluster figures, they would have shown as a small sub-cluster of two very similar documents (similarity according to auditor 1: 0.96; auditor 2: 1.00). For both auditors this sub-cluster is most similar to document IM (auditor 1: 0.79, auditor 2: 0.84). To illustrate the effect of LSA on the document vector-space model, we applied LSA to the 8 documents from the audit that were still available. We determined the

58 citations


Proceedings ArticleDOI
23 Oct 2009
TL;DR: This paper presents how ontology-driven visualization of architectural design decisions can be used to assist software product audits, in which independent auditors perform an assessment of a product's quality.
Abstract: There is a gradual increase of interest to use ontologies to capture architectural knowledge, in particular architectural design decisions. While ontologies seem a viable approach to codification, the application of such codified knowledge to everyday practice may be non-trivial. In particular, browsing and searching an architectural knowledge repository for effective reuse can be cumbersome. In this paper, we present how ontology-driven visualization of architectural design decisions can be used to assist software product audits, in which independent auditors perform an assessment of a product's quality. Our visualization combines the simplicity of tabular information representation with the power of on-the-fly ontological inference of decision attributes typically used by auditors. In this way, we are able to support the auditors in effectively reusing their know-how, and to actively assist the core aspects of their decision making process, namely trade-off analysis, impact analysis, and if-then scenarios. We demonstrate our visualization with examples from a real-world application.

37 citations


Book ChapterDOI
08 Aug 2014
TL;DR: System Quality and Software Architecture collects state-of-the-art knowledge on how to intertwine software quality requirements with software architecture and how quality attributes are exhibited by the architecture of the system.
Abstract: System Quality and Software Architecture collects state-of-the-art knowledge on how to intertwine software quality requirements with software architecture and how quality attributes are exhibited by the architecture of the system. Contributions from leading researchers and industry evangelists detail the techniques required to achieve quality management in software architecting, and the best way to apply these techniques effectively in various application domains (especially in cloud, mobile and ultra-large-scale/internet-scale architecture) Taken together, these approaches show how to assess the value of total quality management in a software development process, with an emphasis on architecture. The book explains how to improve system quality with focus on attributes such as usability, maintainability, flexibility, reliability, reusability, agility, interoperability, performance, and more. It discusses the importance of clear requirements, describes patterns and tradeoffs that can influence quality, and metrics for quality assessment and overall system analysis. The last section of the book leverages practical experience and evidence to look ahead at the challenges faced by organizations in capturing and realizing quality requirements, and explores the basis of future work in this area.Explains how design decisions and method selection influence overall system quality, and lessons learned from theories and frameworks on architectural qualityShows how to align enterprise, system, and software architecture for total qualityIncludes case studies, experiments, empirical validation, and systematic comparisons with other approaches already in practice.

21 citations


BookDOI
02 Nov 2015
TL;DR: This edited volume presents state of the art techniques, methodologies, tools, best practices and guidelines for software quality assurance and offers guidance for future software engineering research and practice.
Abstract: Software Quality Assurance in Large Scale and Complex Software-intensive Systems presents novel and high-quality research related approaches that relate the quality of software architecture to system requirements, system architecture and enterprise-architecture, or software testing. Modern software has become complex and adaptable due to the emergence of globalization and new software technologies, devices and networks. These changes challenge both traditional software quality assurance techniques and software engineers to ensure software quality when building today (and tomorrows) adaptive, context-sensitive, and highly diverse applications. This edited volume presents state of the art techniques, methodologies, tools, best practices and guidelines for software quality assurance and offers guidance for future software engineering research and practice. Each contributed chapter considers the practical application of the topic through case studies, experiments, empirical validation, or systematic comparisons with other approaches already in practice. Topics of interest include, but are not limited, to: quality attributes of system/software architectures; aligning enterprise, system, and software architecture from the point of view of total quality; design decisions and their influence on the quality of system/software architecture; methods and processes for evaluating architecture quality; quality assessment of legacy systems and third party applications; lessons learned and empirical validation of theories and frameworks on architectural quality; empirical validation and testing for assessing architecture quality.Focused on quality assurance at all levels of software design and developmentCovers domain-specific software quality assurance issues e.g. for cloud, mobile, security, context-sensitive, mash-up and autonomic systemsExplains likely trade-offs from design decisions in the context of complex software system engineering and quality assuranceIncludes practical case studies of software quality assurance for complex, adaptive and context-critical systems

14 citations


Book ChapterDOI
01 Jan 2011
TL;DR: This work investigates the notion of software product quality from the point of view of its integration into the modeling activities on the same level of abstraction as traditional functional models (a conceptualization of quality).
Abstract: We investigate the notion of software product quality from the point of view of its integration into the modeling activities on the same level of abstraction as traditional functional models (a conceptualization of quality) We pay special attention to the evolution of the approaches for obtaining this conceptualization through the history of conceptual modeling, propose their classification according to common attributes and outline their distinguishing features Based on the proposed classification, we outline a way of establishing an evaluation framework for quality conceptualizations aiming at supporting the choice of a conceptualization solution best suited for the problem at hand

10 citations


References
More filters

Book
01 Jan 1997
TL;DR: This second edition of this book reflects the new developments in the field and new understanding of the important underpinnings of software architecture with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters.
Abstract: From the Book: Our goals for the first edition were threefold. First, we wanted to show through authentic case studies actual examples of software architectures solving real-world problems. Second, we wanted to establish and show the strong connection between an architecture and an organization's business goals. And third, we wanted to explain the importance of software architecture in achieving the quality goals for a system. Our goals for this second edition are the same, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters. Architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition. Architecture analysis has developed into a mature field with industrial-strength methods. This is reflected by a new chapter about the architecture tradeoff analysis method (ATAM). The ATAM has been adopted by industrial organizations as a technique for evaluating their software architectures. Architecture design has also had major developments since the first edition. The capturing of quality requirements, the achievement of those requirements through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve qualities are all captured in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and theattribute driven design (ADD) method, respectively. Architecture reconstruction or reverse engineering is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project, an analysis project, or to provide input into a decision process to determine what to use as a basis for reconstructing an existing system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context; in in this edition the topic merits its own chapter. Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected by all-new diagrams. But more important, an understanding of what kind of information to capture about an architecture, beyond what notation to use, has emerged. A new chapter covers architecture documentation. The understanding of the application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. The chapter reinforces the link between architecture and an organization's business goals, as product lines, based around a software architecture, can enable order-of-magnitude improvements in cost, quality, and time to market. In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend by updating the World Wide Web chapter, by using Web-based examples for the ATAM chapter and the chapter on building systems from components, by replacing the CORBA case study with one on Enterprise JavaBeans (EJB), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians. Finally, we have added a chapter that looks more closely at the financial aspects of architectures. There we introduce a method--the CBAM--for basing architectural decisions on economic criteria, in addition to the technical criteria that we had focused on previously. As in the first edition, we use the architecture business cycle as a unifying motif and all of the case studies are described in terms of the quality goals that motivated the system design and how the architecture for the system achieves those quality goals. In this edition, as in the first, we were very aware that our primary audience is practitioners, so we focus on presenting material that has been found useful in many industrial applications, as well as what we expect practice to be in the near future. We hope that you enjoy reading it at least as much as we enjoyed writing it. 0321154959P12162002

4,872 citations


Additional excerpts

  • ...call ‘tactics’ [2]....

    [...]


01 Jan 2004
TL;DR: A possible ontology of architectural design decisions, their attributes and relationships, for complex, software-intensive systems, is presented.
Abstract: Architectural design decisions deserve to be first class entities in the process of developing complex software-intensive systems. Preserving the graphs of decisions and all their interdependencies will support the evolution and maintenance of such systems. In this paper we present a possible ontology of architectural design decisions, their attributes and relationships, for complex, software-intensive systems.

281 citations


ReportDOI
01 Mar 2003
TL;DR: Initial evidence is provided that there is, in fact, a systematic relationship between general scenarios, concrete scenarios, architectural tactics, and design fragments that satisfy the scenario.
Abstract: : This is one of several reports that provide the current status on the work being done by the Software Engineering Institute (SEIsm) to understand the relationship between quality requirements and architectural design. The ultimate objective of this work is to provide analysis-based guidance to designers so that the quality attributes of generated designs are more predictable and better understood. Currently, four distinct problems must be solved to achieve that objective: (1) the precise specification of quality attribute requirements, (2) the enumeration of architectural decisions that can be used to achieve desired quality attribute requirements, (3) a means of coupling one quality attribute requirement to the relevant architectural decisions, and (4) a means of composing the relevant architectural decisions into a design. Embodying the solutions to these four problems into a design method that is sensitive to business priorities is an additional problem. This report deals with the third problem-coupling one quality attribute requirement to architectural decisions that achieve it. This report provides initial evidence that there is, in fact, a systematic relationship between general scenarios, concrete scenarios, architectural tactics, and design fragments. It examines, in detail, two concrete scenarios for performance and one for modifiability-and describes how to move from each scenario, through tactics, to design fragments that satisfy the scenario.

141 citations


Book ChapterDOI
11 Jul 2007
Abstract: Different organizations or organizational units are likely to store and maintain different types of information about their software architectures. This inhibits effective management of architectural knowledge. We experimented with a model of architectural knowledge to characterize the use of architectural knowledge in four different organizations. Based on this experimentation we identified four perspectives on architectural knowledge management, and additionally adjusted the model to better align theory with practice. The refined model defines a minimal set of concepts with supposedly complete coverage of the architectural knowledge domain. Because of the minimalistic aspect of the model, we refer to it as a 'core model' of architectural knowledge. Supporting evidence for the validity of our model, i.e. the supposed complete coverage, has been obtained by an attempt to falsify this claim through a comparison with selected literature. Application of the core model to characterize the use of architectural knowledge indicates possible areas of improvement for architectural knowledge management in the four organizations.

94 citations


Journal ArticleDOI
TL;DR: It is argued that there is no fundamental distinction between architectural decisions and architecturally significant requirements and this new view on the intrinsic relation between architecture and requirements allows us to identify areas in which closer cooperation between the Architecture and requirements engineering communities would bring advantages for both.
Abstract: Many would agree that there is a relationship between requirements engineering and software architecture. However, there have always been different opinions about the exact nature of this relationship. Nevertheless, all arguments have been based on one overarching notion: that of requirements as problem description and software architecture as the structure of a software system that solves that problem, with components and connectors as the main elements. Recent developments in the software architecture field show a change in how software architecture is perceived. There is a shift from viewing architecture as only structure to a broader view of 'architectural knowledge' that emphasizes the treatment of architectural design decisions as first-class entities. From this emerging perspective we argue that there is no fundamental distinction between architectural decisions and architecturally significant requirements. This new view on the intrinsic relation between architecture and requirements allows us to identify areas in which closer cooperation between the architecture and requirements engineering communities would bring advantages for both.

65 citations