There aren't any silver bullets in software development, and there probably never will be. However, Extreme Programming is a simple set of common-sense practices that, when used together, really can give you much of what you just read in the paragraph above. In this book, we tell you what the XP practices are, and how to install them in your project.

This paper describes the main components of the environment and outlines how they support maintenance of large software systems. CAPITL was designed with four principles in mind.

We present a technique for restructuring functions with low cohesion into functions with high cohesion. Such restructuring is desirable when re-architecting a legacy system into an object-oriented architecture. The restructured system has functions with higher cohesion and hence lower coupling. This enables finer-grained grouping of functions into objects.

Software architectures have received considerable attention in both research and practice for representing system stakeholder concerns during the software development process. While a number of architecture representations have been proposed to facilitate analysis at different levels of abstraction, tool support for deriving and evaluating these architectures is only just beginning to appear. This paper describes a research tool under development, Reference Architecture Representation Environment (RARE), designed to systematically guide the architect through derivation by applying object-oriented and software architecture heuristics associated with quality goals and evaluate the resulting architecture based on relevant static metrics. As a member of the Systems Engineering Process Activities (SEPA) tool suite, RARE helps address a number of challenges typically faced during the derivation process, including (1) developing an architecture that reflects quality goals identified by the ar...

A major problem affecting software quality and software development productivity is the use of incorrect and inconsistent models of the problem domain, and of the proposed problem solution, during the software development process. Most methods used in the early phases of the SDLC, and the models that they produce, are semantically imprecise. In addition, many different models, representing different aspects of the problem or proposed solution, are used. These models often describe the same concept from different viewpoints, resulting in alias components in the models. These factors combine to produce an inconsistent description that will cause problems in the later phases of the SDLC. Our solution is firstly to make the methods and models more precise by defining their semantics, and secondly to ensure that partially overlapping models are semantically, as well as syntactically, consistent. The approach we have taken is to embed a method, and its model, inside a tool and expose the operations it performs on the model to other tools via semantic events. We maintain tool independence by using a co-ordinator to translate semantic events in one model into appropriate semantic events on alias components in other models.

Our main aim is to propose a new characterization for the software development process. We suggest that software development methodology has some limits. These limits are a clue that software development process is more subjective and empirical than objective and formal. We use Kolmogorov complexity to develop the formal argument and to outline the informal conclusions. Kolmogorov complexity is based on the size in bits of the smallest e ective description of an object and is a suitable quantitative measure of the object's information content.

Over time, due to repeated modifications, the structure of a software deteriorates, causing its logical threads to get intertwined, like noodles in a bowl of spaghetti. The threads become entangled to a point where the program can hardly be understood or modified. We have developed a transformation that restructures a software - disentangles its logical threads - to reduce its complexity. Our transformation is intuitive in that it mimics the activities a programmer may perform during manual restructuring. Our transformation is also general in that it is applicable to any re-engineering need. We have proven that the transformation does not alter the semantics of the restructured program. Our transformation is a composition of two primitive transformations: TUCK and SPILT. Given a set of statements specified by a programmer, TUCK identifies the computational thread related to these statements, and SPLIT separates this thread from the rest of the entangled computations. A restructuring transformation such has that presented has not been studied before. Previous transformations for restructuring programs were either not intuitive, or not general, or did not preserve the semantics of programs. Thus, our transformation is better amenable for use in a re-engineering environment. Biography

ion is a significant tool in managing the software development process. This has long been recognized by the real-time community, as evidenced by the number of real-time kernels available. The kernel allows the programmer to ignore the processor-specific details of task management: allocation, switching, synchronization, scheduling, etc. These kernels have varying features, depending upon the goals of the project. A major distinction between kernels can be drawn in the support for single vs. multiple processor designs. Uniprocessor support is by far the most common. These kernels are acceptable where the processing demands are modest enough to be handled comfortably by a single processor. This technology is well developed, and has been used in the commercial sector for many years. Multiprocessor kernels, such as Spring [37], MARS [36], and Chimera II [38] are at a much more primitive level. These kernels begin to examine the issues of integrating parallel processors into real-time sy...

The areas of domain engineering, vertical application frameworks, and business objects have generated considerable interest in industry and the research community during the last few years. In order for systems to be successfully implemented from such application frameworks, there are two major concerns that must be addressed: how do we maintain non-interfering applications and how do we minimize bias towards any individual application in developing the domain model? In other words, as we add new applications, we need to ensure that they are not destructive to each other. We also need to make certain that as we expand the domain model to accommodate new applications, that these future applications are not unnecessarily constrained or complex. Most of the related work to date has focused on defining the architectural structure of application frameworks or on maintaining structural and behavioral consistency. For my Ph.D. thesis, I propose to develop a conceptual framework for integrating various techniques to facilitate managing the evolution of a business domain architecture. As part of this conceptual framework, I distinguish between a ‘good design ’ and a ‘legal design’. In order to demonstrate the

The area of method engineering has emerged in response to an increasing feeling that methods are not well suited to the needs of their users, the application engineers. Method engineering aims at developing methods. The paper uses the four worlds framework to investigate the subject of method engineering. It presents a state-of-art survey with a view to identifying the important problems and research directions being followed to solve these. The major problems not yet addressed or which have newly emerged are highlighted Key-words Method engineering, process engineering, fragment method, situational method 1.