This study presents an initial set of findings from an empirical study of social processes, technical system configurations, organizational contexts, and interrelationships that give rise to open software. The focus is directed at understanding the requirements for open software development efforts, and how the development of these requirements differs from those traditional to software engineering and requirements engineering. Four open software development communities are described, examined, and compared to help discover what these differences may be. Eight kinds of software informalisms are found to play a critical role in the elicitation, analysis, specification, validation, and management of requirements for developing open software systems. Subsequently, understanding the roles these software informalisms take in a new formulation of the requirements development process for open source software is the focus of this study. This focus enables considering a reformulation of the requirements engineering process and its associated artifacts or (in)formalisms to better account for the requirements for developing open source software systems.

Little guidance and few methods are available for the refinement of software requirements into an architecture satisfying those requirements. Part of the challenge stems from the fact that requirements and architectures use di#erent terms and concepts to capture the model elements relevant to each. In this paper we will present CBSP, a lightweight approach intended to provide a systematic way of reconciling requirements and architectures using intermediate models. CBSP leverages a simple set of architectural concepts (components, connectors, overall systems, and their properties) to recast and refine the requirements into an intermediate model facilitating their mapping to architectures. Furthermore, the intermediate CBSP model eases capturing and maintaining arbitrarily complex relationships between requirements and architectural model elements, as well as among CBSP model elements. We have applied CBSP within the context of di#erent requirements and architecture definition techniques. We leverage that experience in this paper to demonstrate the CBSP method and tool support using a large-scale example.

Requirements traceability (RT) aims at defining relationships between stakeholder requirements and artifacts produced during the software development life-cycle. Although techniques for generating and validating RT are available, RT in practice often suffers from the enormous effort and complexity of creating and maintaining traces or from incomplete trace information that cannot assist engineers in real-world problems. In this paper we will present a tool-supported technique easing trace acquisition by generating trace information automatically. We will explain the approach using a video-on-demand system and show that the generated traces can be used in various engineering scenarios to solve RT-related problems.

The fundamental goal of all good design and engineering is to create maximal value added for any given investment. There are many dimensions in which value can be assessed, from monetary profit to the solution of social problems. The benefits sought are often domain-specific, yet the logic is the same: design is an investment activity. Software economics is the field that seeks to enable significant improvements in software design and engineering through economic reasoning about product, process, program, and portfolio and policy issues. We summarize the state of the art and identify shortfalls in existing knowledge. Past work focuses largely on costs, not on benefits, thus not on value added; nor are current technical software design criteria linked clearly to value creation. We present a roadmap for research emphasizing the need for a strategic investment approach to software engineering. We discuss how software economics can lead to fundamental improvements in software design and engineering, in theory and practice. 1

“No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits... Large system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it... “Everyone seems to have been surprised by the stickiness of the problem, and it is

Rational Rose is a graphical software modeling tool, using the Unified Modeling Language (UML) as its primary notation. It offers an open API that allows the development of additional functionality ("add-ins"). In this paper, we describe Rose/Architect, a Rose^TM "add-in" used to visualize architecturally-significant elements in a system's design, developed jointly by University of Southern California (USC) and Rational Software. Rose/Architect can be used in forward engineering, marking architecturally significant elements as they are designed and extracting architectural views as necessary. But it can be even more valuable in reverse engineering, i.e., extracting missing key architectural information from a complex model. This model may have been reverseengineered from source code using the Rose reverse engineering capability.

Communication and collaboration is difficult in geographically distributed settings. As a result of globalization, merges and acquisition, and scarce skills, software development projects are increasingly more distributed. Hence, teaching software engineering students how to cope with distribution becomes a critical issue. This paper describes our experience with teaching three

Metaheuristic techniques such as genetic algorithms, simulated annealing and tabu search have found wide application in most areas of engineering. These techniques have also been applied in business, financial and economic modelling. Metaheuristics have been applied to three areas of software engineering: test data generation, module clustering and cost/effort prediction, yet there remain many software engineering problems which have yet to be tackled using metaheuristics. It is surprising that metaheuristics have not been more widely applied to software engineering

Introduction Software systems come and go through a series of passages that account for their inception, initial development, productive operation, upkeep, and retirement from one generation to another. This article categorizes and examines a number of methods for describing or modeling how software systems are developed. It begins with background and definitions of traditional software life cycle models that dominate most textbook discussions and current software development practices. This is followed by a more comprehensive review of the alternative models of software evolution that are of current use as the basis for organizing software engineering projects and technologies. Background Explicit models of software evolution date back to the earliest projects developing large software systems in the 1950's and 1960's (Hosier 1961, Royce 1970). Overall, the apparent purpose of these early software life cycle models was to provide a conceptual scheme for rati

Metrics, whether collected statically or dynamically, and whether constructed from source code, systems or processes, are largely regarded as a means of evaluating some property of interest. This viewpoint has been very successful in developing a body of knowledge, theory and experience in the application of metrics to estimation, predication, assessment, diagnosis, analysis and improvement. This paper shows that there is an alternative, complementary, view of a metric: as a fitness function, used to guide a search for optimal or near optimal individuals in a search space of possible solutions. This ‘Metrics as Fitness Functions ’ (MAFF) approach offers a number of additional benefits to metrics research and practice because it allows metrics to be used to improve software as well as to assess it and because it provides an additional mechanism of metric analysis and validation. This paper presents a brief survey of search-based approaches and shows how metrics have been combined with the search based techniques to improve software systems. It describes the properties of a metric which make it a good fitness function and explains the benefits for metric analysis and validation which accrue from the MAFF approach. 1.