Abstract: Data obtained during a 1968 study of the software process [8] led to an investigation of the evolution of OS/360 [13] and and, over a period of twenty years, to formulation of eight Laws of Software Evolution. The FEAST project recently initiated (see sections 4–6 below) is expected to throw additional light on the phenomenology underlying these laws, to increase understanding of them, to explore their finer detail, to expose their wider relevance and implications and to develop means for their beneficial exploitation. This paper is intended to trigger wider interest in the laws and in the FEAST study of feedback and feedback control in the context of the software process and its improvement to ensure beneficial exploitation of their potential.

Abstract: The invisible nature of software hides system complexity, particularly for large team-oriented projects. The authors have evolved four innovative visual representations of code to help solve this problem: line representation; pixel representation; file summary representation; and hierarchical representation. We first describe these four visual code representations and then discuss the interaction techniques for manipulating them. We illustrate our software visualization techniques through five case studies. The first three focus on software history and static software characteristics; the last two discuss execution behavior. The software library and its implementation are then described. Finally, we briefly review some related work and compare and contrast our different techniques for visualizing software.

Abstract: Critical business applications require reliable software, but developing reliable software is one of the most difficult problems facing the software industry After the software is shipped, software vendors receive customer feedback about software reliability However, by then it is too late; software vendors need to know whether their products are reliable before they are delivered to customers Software reliability growth models help provide that information Unfortunately, very little real data and models from commercial applications have been published, possibly because of the proprietary nature of the data Over the past few years, the author and his colleagues at Tandem have experimented with software reliability growth models At Tandem, a major software release consists of substantial modifications to many products and may contain several million lines of code Major software releases follow a well defined development process and involve a coordinated quality assurance effort We applied software reliability modeling to a subset of products for four major releases The article reports on what was learned

Abstract: From the Publisher: Classical and Object-Oriented Software Engineering is designed for an introductory software engineering course. This book provides an excellent introduction to software engineering fundamentals,covering both traditional and object-oriented techniques. Schach's unique organization and style makes it excellent for use in a classroom setting. It presents the underlying software engineering theory in Part I and follows it up with the more practical life-cycle material in Part II. Many software engineering books are more like reference books,which do not provide the appropriate fundamentals before inundating students with implementation details. In this edition,more practical material has been added to help students understand how to use what they are learning. This has been done through the use of "How To" boxes and greater implementation detail in the case study. Additionally,the new edition contains the references to the most current literature and includes an overview of extreme programmming. The website in this edition will be more extensive. It will include Solutions,PowerPoints that incorporate lecture notes,newly developed self-quiz questions,and source code for the term project and case study.

Abstract: Without a well-defined set of quality-attribute requirements, software projects are vulnerable to failure. The authors have developed QARCC, a knowledge-based tool that helps users, developers, and customers analyze requirements and identify conflicts among them.

Abstract: The object-oriented design community has recently begun to collect so-called design patterns: cliches plus hints to their recommended use in software construction. The structural design patterns Adapter, Bridge, Composite, Decorator, and Proxy represent packaged problem/context/solution/properties descriptions to common problems in object-oriented design. Localizing instances of these patterns in existing software produced without explicit use of patterns can improve the maintainability of software. In the authors' approach, called the Pat system, design information is extracted directly from C++ header files and stored in a repository. The patterns are expressed as PROLOG rules and the design information is translated into facts. A single PROLOG query is then used to search for all patterns. They examined four applications, including the popular class libraries zApp and LEDA, with Pat. With some restrictions all pattern instances are found; the precision is about 40 percent. Since manual filtering of the output is relatively easy, they consider Pat a useful tool for discovering or recovering design information.

Abstract: The usual way of installing a new version of a software system is to shut down the running program and then install the new version. This necessitates a sometimes unacceptable delay during which service is denied to the users of the software. An online software replacement system replaces parts of the software while it is in execution, thus eliminating the shutdown. While a number of implementations of online version change systems have been described in the literature, little investigation has been done on its theoretical aspects. We describe a formal framework for studying online software version change. We give a general definition of validity of an online change, show that it is in general undecidable and then develop sufficient conditions for ensuring validity for a procedural language.

Abstract: Patterns have shown to be an effective means of capturing and communicating software design experience. However, there is more to patterns than software design patterns: We believe that patterns work for software development on several levels. In this paper we explore what we have come to understand as crucial aspects of the pattern concept, relate patterns to the different models built during software design, discuss pattern forms and how we think that patterns can form larger wholes like pattern handbooks.

Abstract: The field of knowledge-based software engineering has been undergoing a shift in emphasis from automatic programming to human augmentation and empowerment. In our research work, we support this shift with an approach that embedshuman-computer cooperative problem-solving tools intodomain-oriented, knowledge-based design environments. Domain orientation reduces the large conceptual distance between problem-domain semantics and software artifacts. Integrated environments support the coevolution of specification and construction while allowing designers to access relevant knowledge at each stage within the software development process.

Abstract: Improved software processes lead to improved product quality. The Personal Software Process (PSP) is a framework of techniques to help engineers improve their performance-and that of their organizations-through a step-by-step, disciplined approach to measuring and analyzing their work. This article explains how the PSP is taught and how it applies to different software engineering tasks. The author reports some promising early results.

Abstract: : Software architecture is an area of growing importance to practitioners and researchers in government, industry, and academia. Journals and international workshops are devoted to it. Working groups are formed to study it. Textbooks are emerging about it. The government is investing in the development of software architectures as core products in their own right. Industry is marketing architectural frameworks such as CORBA. Why all the interest and investment? What is software architecture, and why is it perceived as providing a solution to the inherent difficulty in designing and developing large, complex systems? This report will attempt to summarize the concept of software architecture for an intended audience of mid to senior level management. The reader is presumed to have some familiarity with common software engineering terms and concepts, but not to have a deep background in the field. This report is not intended to be overly-scholarly, nor is it intended to provide the technical depth necessary for practitioners and technologists. The intent is to distill some of the technical detail and provide a high level overview.

Abstract: This study is one in a series of investigations into software and hardware engineering based mainly upon the observation of four projects developing photocopying technology. '~ Our general interest in this paper is in the work of software engineering, with how software engineers organise their work in order to be get it done.~ Our particular interest is in one common form the organisation of the work takes which is that of the pro jec t , and consequently we are concerned with the organisation of engineering work as project work. The project provides a formatted organisational arrangement within which engineers co-ordinate their day-to-day design and development work, and is thus a form of social organisation through which they make their work mutually and organisationally accountable. We are concerned to identify some of the methods through which the engineers build in the formatted arrangements of the project into their work, and with how they dis-

Abstract: (1) Specification. The functionality of the software and its operating constraints are specified in detail. (2) Design and implementation. The overall structure of the software is designed and specific software components identified. These are implemented using some programming language, often by separate individuals or teams. (3) Integration and testing. Individually developed modules are integrated into a complete system and tested. (4) Operation and maintenance. The software is delivered to the customer and modified to meet changing requirements and to repair errors discovered in use. The problem with this model is the lack of feedback from one stage to another. Specification, design, and implementation problems are often discovered only after implementation when the system has been integrated. Once a specification has been frozen, it is difficult to change in response to changing user needs. However, stakeholders in the system (end-users, managers, and so on) find it difficult to anticipate their real needs for software support, and both organizational and end-user requirements change during the development process. There is therefore a constant pressure for specification change. This means that, in practice, there is always some iteration between the phases of the model, but this is invariably fairly limited and the delivered software may not meet the real needs of the customer. This led to widespread criticism of the waterfall model [Gladden 1982; McCracken and Jackson 1982] and the development of alternative software processes. Incremental models [Mills et al. 1980] are a development of the waterfall model that attempt to provide some development stability while allowing users some opportunity for specification change. In this approach, the system functionality is partitioned into a series of increments and these are developed and delivered one by one. While one increment is being developed, its specification is frozen, but the specification of other increments may change. A version of the system is delivered early to users and they may experiment with it to help clarify their needs for later system increments.

Abstract: Reusing frameworks instead of libraries can cause subtle architectural changes in an application, calling for innovative management solutions. We relate our experience in managing the Knowledge-Based Software Assistant project and offer tips for buying, building and using frameworks. One of the promises of object-oriented software development is that organizations can get a significant return on development investment because the code is easier to reuse. Software project managers are often eager to take the OO plunge for that reason, but are uncertain about the management issues they will face. There is also the problem of choosing the best form of reuse. Library-based reuse, the traditional reuse form, is more popular than framework-based reuse, but we have found that framework-based reuse offers many more benefits with the right management approach. We describe the lessons we learned when building the Knowledge-Based Software Assistant/Advanced Development Model.

Abstract: The use of geographically separated software development groups is proposed as a method for enabling 24-hour software development, or software shift work. The advantages of such an approach are explained, and potential organizational models for such virtual teams are described. Virtual team co-operation, information requirements and communication channels are explored. Activities in the software development life-cycle in which virtual teams can be advantageously utilized are explained, and examples of the successful use of virtual teams are cited. Finally a measure of the effectiveness of virtual teams known as the distributed working overhead is defined, which will enable project managers to clearly see the benefits and associated costs of employing virtual teams on a project.

Abstract: A method of determining the functionality of a software system includes inputting a test plan to the software system via a software testing interface program, and logging an indication of one or more resulting outputs of the software system compared to expected output(s). The test plan invokes a sequence of test scripts and includes associated parameter inputs for the test scripts, and an expected output of the function or transaction of each test script. The test scripts are selected from a set of test scripts each able, when input to the software system via a software testing interface program, to prompt performance of a transaction or function for which the software system is designed.

Abstract: Machine Model. IEEE Transactions on Software Engineering, 21(4):373-386, April 1995. [9] D.C. Luckham and J. Vera. An Event-based Architecture Definition Language. IEEE Transactions on Software Engineering, 21(9):717-734, September 1995. [lo] L.J. Morels. A Theory of Fault-based Testing. IEEE Transactions on Sofiware Engineering, 16(8):844-857, August 1990. [ll] 0. O’MaIIey, D.J. Richardson, and L.K. Dillon. Efficient Specification-based Oracles for Critical Systems. In Proceedings of the California Software Symposium. Irvine Research Unit in Software, April 1996. [12] D.E. Perry and A.L. Wolf. Foundations for the Study of Software Architecture. SIGSOFT Software Engineering Notes, 17(4):40-52, October 1992. [13] A. Podgurski and L.A. Clarke. A Formal Model of Program Dependencies and its Implications for Software Testing, Debugging, and Maintenance. IEEE Transactions on Software Engineering, 16(9):965-979, September 1990. [14] D.J. Richardson and M.C. Thompson. The RELAY Model of Error Detection and its Application. In Proceedings of the Second Workshop on Software Testing, Analysis, and Verification (TAV??), pages 223-230. ACM SIGSOFT, July 1988.

Abstract: The performance estimation of a target system at a higher level of abstraction is very important in hardware/software codesign. We focus on software performance estimation, including both the execution time and the code size. We present two estimation methods at different levels of abstraction for use in the POLIS hardware/software codesign system. The experimental results show that the accuracy of our methods is usually within /spl plusmn/20%.

Abstract: This paper outlines the problems of specifying requirements and deploying these requirements in the procurement of software packages. Despite the fact that software construction de novo is the exception rather than the rule, little or no support for the task of formulating requirements to support assessment and selection among existing software packages has been developed. We analyse the problems arising in this process and review related work. We outline the key components of a programme of research in this area.

Abstract: The paper presents a failure modes model of parts-based software reuse, and shows how this model can be used to evaluate and improve software reuse processes. The model and the technique are illustrated using survey data about software reuse gathered from 113 people from 29 organizations.

Abstract: Evidence suggests that information centers (ICs) have significantly more interest in evaluating software packages and assisting in the selection of software packages than end users have. However, the selection of software packages by the information center product specialists (ICPSs) can compromise their usage. Ease of use and usefulness are believed to be fundamental predictors of usage. The question of whether ICPSs are able to correctly evaluate ease of use and usefulness of software packages for end users is posed. An insight into this issue could enhance end-user computing (EUC) policy and lead to a more effective partnership between end users and information systems (IS) professionals. A search for this insight provided the motivation for our empirical investigation of the perception of ICPSs and end users in assessing the ease of use and usefulness of thirty different software packages. Our investigation was performed in an organization with an IC that had evolved to the formalization stage. The findings show that the perceptions of the end users and ICPSs were similar in terms of assessing the ease of use of software packages. However, end users found the software packages less useful than did IC product specialists. Therefore, in sophisticated environments, end users should be empowered to develop their own user groups and suggest to IC personnel which useful software packages to acquire. Otherwise, selection of software packages without end-user participation could have an adverse effect on their usage.

Abstract: From the Publisher: Software Metrics explains how software measurement can be used to support software process improvement by providing objective methods of characterizing process capability and evaluating the effect of process changes. The author explains what is meant by software measurement and how to decide what to measure; how to use measurement to support different aspects of a process improvement programme; how to set quantitative goals using a pragmatic approach to the Goal-Question-Metric paradigm; how to set up a metrication programme and design a data collection system; and how to analyse the software data collected. Further, the author provides insight into how software measurement can act as a process improvement agent for quality control and software estimating. This book sets out an approach to the formal validation of measures and the theory of statistical data analysis for students. It also contains, for practitioners, many examples of the use of real data in real projects.

Abstract: ccurate software estimating is too difficult for simple rules of thumb. Yet in spite of their inadequacy and the availability of more than 50 commercial software-estimating tools-simple rules of thumb remain the most common estimating approach. Many companies develop and market software cost and quality estimating tools. Including my own firm's two proprietary tools, there are at least 50 commercial software-estimating tools on the market in the United States, and the worldwide total exceeds 75. Most of these tools are far superior to manual estimating methods in both ease of use and repeatability, and many are also more accurate.

Abstract: Business rules are operational rules that business organizations follow to perform various activities. Over time, business rules evolve and the software that implemented them are also changed. As the encompassing software becomes large and aged the business rules embedded are difficult to extract and understand. Furthermore, the encompassing software is changed without changing the corresponding documents, so the business organization often trusts the code more than any other documents. It is possible to use a generic tool to extract business rules, but this can be an expensive exercise. The paper proposes a tailored solution approach to the business rule extraction problem, which combines variable classifications, program slicing, and hierarchical abstraction among other maintenance techniques. The proposed approach has been implemented as a system and successfully experimented with a number of industrial programs. The prototype has been demonstrated at several industrial software maintenance sites since June 1995.

Abstract: Rarely in history has a field of endeavor evolved as rapidly as software development is right now. The struggle to stay abreast of new technology, deal with accumulated development backlogs, and cope with people issues has become a treadmill race, as software groups work as hard as they can just to stay in place. The Software Engineering Institute (SEI) and hordes of gurus exhort us to improve our development process, but how can we afford the time? Not every member of an organization feels the need to change. It is too easy to dismiss process improvement efforts as just the latest management blathering. Therein lies the seeds of conflict, as some members of a team embrace new ways of working, while others mutter "over my dead body."