Note: The Arcadia project ended in 1997. This web site is for archival purposes; we can no longer guarantee liveness of links.

The Arcadia Philosophy

The primary goal of the Arcadia project is to carry out validated research in the area of software engineering environments. In the course of this research, the Arcadia project has discovered a wide range of concepts and capabilities we believe to be key to success in building an effective environment. This research has focused on developing advanced prototypes to demonstrate feasibility of our concepts, and on demonstrating that these key capabilities can be successfully integrated into an operational whole. Our insistence on integrating the various Arcadia constituent components has served as a crucially important forcing function, compelling all of us to consider overall environment architecture issues and usage contexts in designing and developing individual components. Our experiences in building these components and in assembling them have confirmed and validated many of our research ideas. These experiences have also pointed up some unexpected problems, which has often led to new research and implementation insights.

The Arcadia project believes that an effective software engineering environment (SEE) is a collection of capabilities effectively integrated to support software developers and managers in their work. For an SEE to be effective it must be:

The tools and capabilities of an environment cannot stand in parallel isolation and ignorance of each other. Rather, they must be able to readily share data and results with each other. Their progress must affect, and be affected by, each other's activities.
The capabilities of an environment must constantly grow and expand. As software engineering matures as a discipline, and as the commercial marketplace of software tools expands, an effective SEE must be capable of absorbing new tools and ideas. It is a mistake to attempt to specify the functional requirements for an SEE in advance and then design it to meet only these prescribed requirements.
Incrementally Improvable:
The growth and maturation of the discipline and commercial marketplace also assures the steady improvement in the quality and capabilities of available tools. Thus an SEE must be capable of absorbing steadily improving technology.
The needs of software developers and managers are diverse, varying from project to project and from time to time, with differing and changing roles. An SEE must continue to support these individuals effectively throughout these changes. Thus, the SEE and its capabilities must be extremely flexible and adaptable.
As with all computer systems, performance is of great importance in an SEE. Users will expect rapid response to requests for services that they regard as straightforward, and can be expected to be impatient for response, even to requests for services that they know to entail considerable processing.
An SEE can be expected to be a voracious consumer of computer resources -- including processing time and storage space. Demands for resources to support the development and maintenance of large software strain the limits of contemporary hardware systems. Thus, an effective SEE must take care to utilize hardware resources efficiently, lest the cost of the SEE's support become unaffordable.
Able to Support Multiple Users and User Classes:
The engineering of large software systems requires the collaboration of many diverse users. An SEE must support effective interaction and communication among those users. As the raw number of users grows, the problems of effective coordination grow. The diversity of users poses the additional problem of assuring that the SEE provides a corresponding diversity of support.
Easy to Use:
If an SEE is to support users, then it must not itself become an obstacle. Users must find it easy to understand what capabilities the SEE offers, and how to use them effectively.
Able to support effective product and process visibility:
The essence of what makes software engineering difficult is that the software product being built is unexpectedly large and complex. This makes it hard for developers and managers to maintain complete and accurate models of the product in their minds. An effective SEE must help users to form and analyze accurate product models. Further, the way in which the product is developed is also unexpectedly complex, challenging developers and managers to maintain accurate product and project status models. The SEE must facilitate process visibility as well.
Able to support effective management control:
Managers must use visibility and insight into a project as the basis for making decisions that control project progress. An SEE must, therefore, provide support for more than just visibility. The SEE must also support managers in making changes and controlling the project. The SEE must help in controlling access to data, assigning people to tasks, forcing and halting progress from phase to phase, and establishing and terminating communications streams.
Over a period of years, the Arcadia project has evolved an environment architecture designed to effectively address all of the above goals simultaneously. One of the important lessons from the Arcadia project is that various of these design goals are not orthogonal, and in fact are often in conflict with each other. Many of the primary lessons of Arcadia have dealt with understanding the various tensions between these diverse desiderata. Much of the most challenging work of the Arcadia project has been concerned with devising strategies for supporting adjustable compromises between conflicting SEE goals.

The Arcadia Project <>
Last modified: Wed Nov 30 14:24:44 1994