Abstract
The development of software applications generally requires the following: hardware resources (computers, networks, peripherals, etc.), software resources (data, tools, etc.), human resources (individuals with various qualifications), and working methods. These resources are distributed in different autonomous software development environments. A single environment does not always have all the necessary resources to realize some large and/or complex projects. Therefore, collaboration between the environment in charge of the project (coordinator) and others (contractors) will be required to do the job. While several research projects have contributed to various aspects of collaboration among software development environments during the past decade, little has been done on explicitly defining and modeling processes and environment artifacts involved in such partnerships. That is what this chapter is about. In the context of this study, environments work together by assigning tasks and sharing working methods. Tasks and working methods can be defined explicitly using process models. Process models, already the main focus in monolithic software development, will still be an important factor in our approach of collaborative software development. Because they are process-based, all software development environments considered here will be qualified in the continuation of Process-sensitive Software Engineering Environments (PSEEs).
TopBackground
The objective of developing large software projects can be reached more easily when the work to be done is divided into tasks (Smith, Hale & Parish, 2001) and assigned to various PSEEs. Tasks and working methods can be explicitly defined using process models. Figure 1 proposes a brief history of process modeling and its limits.
Figure 1. Brief process modeling history and limits
Software processes are modeled before being assigned to PSEEs for performance. Collaborations to deal with these issues have also been discussed in information systems (Hahn, Jarke & Rose, 1991; Mookerjee & Chiang, 2002).
A simple solution toward this goal is to provide PSEEs with protocols that allow them to communicate in order to import or export process components as well as other PSEE artifacts. First investigations presented hereafter have been made in the subject by Oz (Ben-Shaul & Kaiser, 1995, 1998) and Federated PSEE (Basile, Calanna, Nitto, Fuggetta & Gemo, 1996) approaches.
Oz proposes to compose different instances of PSEEs where each of them is devoted to supporting the development process executed by a single organization. All these PSEEs run autonomously according to their own processes, but they can interact to accomplish common activities such as the integration test of software components that have been independently developed by various organizations. In Oz, the strategy through which a common activity is executed is called a summit. In a summit, one site acts as a coordinator. It receives from the other sites all data needed to execute the common activity, executes the activity, and sends the results back to the other sites. This behavior is obtained by directly implementing the summit protocol and procedures as a basic mechanism of the PSEEs.
Federated PSEEs takes Oz as a starting point and allows several interorganization policies to be implemented and combined. The solution of this issue is to provide a set of basic operations to specify any interorganization policy. Examples of operations are a search for the physical location of a site and a request for the execution of one service at some physical location. Basic operations should be powerful enough to make the specification of any reasonable interorganization policy as simple as possible. The enactment of an interorganization process requires that sites can be located over the network, communication is enabled among sites, data can be safely exchanged, and some access control policies are executed.
These two approaches, original and complementary, are important contributions to address the federation problem. Both have in common to define a priori some interorganization policies. They limit the various types of interorganization policies that could be defined, established, and performed among PSEEs working together.
Key Terms in this Chapter
Agent: A model entity that is able to perform roles and hence to carry out activities. An agent may be human, automated, or some combination of both.
Mobile Process Component: Process component likely to be routed on the network. It can thus be exported or imported for reuse or performance.
Activity: Any piece of work that must be done; an instance composed of an activity name and its relationships with product, direction, tool, role, and its subactivities. The activity must have been assigned to precisely one role. There must exist at least one agent that can perform this role.
Product: Can form an input to an activity, an output from an activity, or an intermediate result of an activity. In the latter case, it is accessible from the tools of the activity, from its subs, but not from outside.
Role: A model entity that identifies a skill requirement that an agent must satisfy in order to perform the role. During process definition, a number of activities can be assigned to a role, and a number of agents can be identified to be able to perform a role.
Tool: A model entity that is a piece of software. It can be employed in carrying out an activity. Any activity may employ an arbitrary number of tools.
Federation Processes: Processes that allow modeling collaboration among distributed software development environments. Such processes allow dynamically building various contract types that can be established among environments.
Direction: A model entity that defines the objectives of the associated activities, defines any constraints to be respected, and may provide advisory guidance on carrying out the activities. Direction must provide instructions sufficient to complete the activity as required.
Process Component Delegation: Act that allows exporting a process component remotely for its performance and/or control.