Software architecture evaluation has been proposed as a means to achieve quality attributes such as maintainability and reliability in a system. The objective of the evaluation is to assess whether or not the architecture will lead to the desired quality attributes. Recently, there have been a number of evaluation methods proposed. There is, however, little consensus on the technical and non-technical issues that a method should comprehensively address and which of the existing methods is most suitable for a particular issue. This paper presents a set of commonly known but informally described features of an evaluation method and organizes them within a framework that should offer guidance on the choice of the most appropriate method for an evaluation exercise. In this paper, we use this framework to characterise eight SA evaluation methods.

Software engineering research and programming language design have enjoyed a symbiotic relationship, with traceable impacts since the 1970s, when these areas were first distinguished from one another. This report documents this relationship by focusing on several major features of current programming languages: data and procedural abstraction, types, concurrency, exceptions, and visual programming mechanisms. The influences are determined by tracing references in publications in both fields, obtaining oral histories from language designers delineating influences on them, and tracking cotemporal research trends and ideas as demonstrated by workshop topics, special issue publications, and invited talks in the two fields. In some cases there is conclusive This article has been developed under the auspices of the Impact Project. The aim of the project is to provide a scholarly study of the impact that software engineering research—both academic and industrial—has had upon practice. The principal output of the project is a series of individual papers covering the impact upon practice of research in several selected major areas of software

Abstract—It has long been accepted that requirements analysis should precede architectural design and implementation, but in software evolution and reverse engineering this concern with black-box analysis of function has necessarily been de-emphasized in favor of code-based analysis and designer-oriented interpretation. In this paper, we redress this balance by describing “functional paleontology, ” an approach to analyzing the evolution of user-visible features or services independent of architecture and design intent. We classify the benefits and burdens of interpersonal communication services into core and peripheral categories and investigate the telephony services available to domestic subscribers over a 50-year period. We report that services were introduced in discrete bursts, each of which emphasized different benefits and burdens. We discuss the general patterns of functional evolution that this “fossil record ” illustrates and conclude by discussing their implications for forward engineering of software products.

Software engineering community has proposed several methods to evaluate software architectures with respect to desired quality attributes such as maintainability, performance, and so on. There is, however, little effort on systematically comparing such methods to discover similarities and differences between existing approaches. In this paper, we compare four well known scenario-based SA evaluation methods using an evaluation framework. The framework considers each method from the point of view of method context, stakeholders, structure, and reliability. The comparison reveals that most of the studied methods are structurally similar but there are a number of differences among their activities and techniques. Therefore, some methods overlap, which guides us to identify five common activities that can form a generic process model.

Abstract not found

Access control is a mechanism for achieving confidentiality and integrity in software systems. Access control policies (ACPs) define how access is managed and the high-level rules of who can access what information under certain conditions. Traditionally, access control policies have been specified in an ad-hoc manner, leaving systems vulnerable to security breaches. ACP specification is often isolated from requirements analysis, resulting in policies that are not in compliance with system requirements. This dissertation introduces the Requirements-based Access Control Analysis and Policy Specification (ReCAPS) method for deriving access control policies from various sources, including software requirements specifications (SRS), software designs, and high-level security/privacy policies. The ReCAPS method is essentially an analysis method supported by a set of heuristics and a software tool: the Security and Privacy Requirements Analysis Tool (SPRAT). The method was developed in two formative case studies and validated in two summative case studies. All four case studies involved operational systems, and ReCAPS evolved as a result of the lessons learned from applying the method to these case studies. Further validation of the method was performed via an empirical study to evaluate the usefulness and effectiveness of the approach. Results from these evaluations indicate that the

The maintenance of a software system still represents the most costly part in its development lifecycle. To reduce cost while doing maintenance, developers must be able to understand the architecture of the existing code base. However, applying detailed software architecture recovery to a large software system is expensive and time consuming. It is instead usually advantageous to perform domain-specific software architecture recovery --- with a focus and a directed set of goals for a particular application domain, which encompasses the knowledge used to build a family of software systems.

This retrospective on nearly two decades of software architecture research examines the maturation of the software architecture research area by tracing the evolution of research questions and results through their maturation cycle. We show how early qualitative results set the stage for later precision, formality, and automation, how results have built up over time, and how the research results have moved into practice.

To my family… for their seemingly infinite patience. Dedication especially my wife Melanie, for holding things together through my periods of distraction. to my children: Leslie, Patrick and Heather who have trouble remembering a time when I was not a student. To my parents… who first instilled the belief that I could accomplish whatever I set my mind to. to my father, who will always be the original Dr. Buhler – your battle with cancer has taught me more about perseverance and strength than you know. i Acknowledgements I would like to thank each of the members of my dissertation committee for their time, commitment and steady encouragement over the years.

In recent years, the size and complexity of information systems has grown almost without bound by hardware or software, with a resulting increased emphasis on using a software development methodology in the belief that by doing so, the experience of other, perhaps more experienced, developers can be re-used. Recent studies however, have found that developers do not adhere rigidly to a methodology, but usually adapt it to their specific needs. However, the extent to which individual software architects apply a specific software architecture development method in practice is largely unexplored. This paper reports on the in practice use of a proprietary software architecture development method, the IBM Custom Application Design. It describes the current state of understanding of application of software architecture methods, explains the research approach applied, reports on the results of the survey and workshops, and describes possible future work. We found that software architects, like software and requirements engineers, do not adhere rigidly to a method. Furthermore, we have identified that there are multiple levels at which the modification to a method can be undertaken. These are ”Tailoring”, “Adapting ” and “Customizing. We also found that a unique version of a method is created for each project. We also found that IBM IT architects rely extensively on tools and techniques for visual communication as one of the key ways in which they work. These are important findings for commercial organizations which develop and/or use methods, and for academic institutions which teach software architecture. 1.