Process-Centered Software Engineering Environments ... - Springer Link

Annals of Software Engineering 14, 363–382, 2002  2002 Kluwer Academic Publishers. Manufactured in The Netherlands.

Process-Centered Software Engineering Environments A Brief History and Future Challenges VOLKER GRUHN [email protected] Software Engineering, Department for Computer Science, University of Dortmund, D-44221 Dortmund, Germany

Abstract. Software engineering environments have a history of about two decades. Early environments provided support for small fragments of the software process (usually focusing on programming-in-the small). Then there was a trend towards support for more complete software processes (from early phases like requirements analysis and design down to testing and configuration management). Ten years ago the notion of process-centered software engineering environments initiated a new field in software engineering: software process research. The key idea is to use a model of a software process as input parameter for a software engineering environment. The environment is supposed to “behave” in accordance to the process model. Some aspects of this vision became true, others turned out to be of little practicability. In this article, we discuss the history of software engineering environments with a particular focus on process-centered software engineering environments (PCSEEs). We discuss the notion of distributed software processes (as one of the most substantial current trends in software process research) and we motivate the notion of a software process middleware which serves as basis of real-world software processes spread over various sites. In addition, we discuss some other trends in the software process research arena. Keywords: software process, process-centered software engineering environment, software process middleware

1.

Introduction

A software process denotes the set of all activities which are carried out in the context of a concrete software development project. It usually covers aspects of software development, quality management, configuration management and project management. The description of a software process is called a software process model. A software process model does not only describe the activities which have to be executed, but also the tools to be used, the types of objects and documents to be created/manipulated and the roles of persons involved in software development. One of the key questions for supporting software processes is how software process models and software engineering environments are related or – in other words – how a supporting infrastructure can be derived from the information given in a software process model. In this section we discuss two basic ideas which have had a strong influence on the support for software processes by means of software engineering environments: the idea of process-centered software engineering environments and the idea of software process management. In section 2 we give a brief overview about the history of software engineering environments. In section 3 we discuss the current mega trend in the field

364

GRUHN

of software process support: the trend towards distributed software processes and towards non-intrusive software process middleware. Section 4 discusses some additional developments in this field (autonomous processes and process parts, mobile processes, federated processes). Finally, section 5 concludes this article with pointing out which research challenges have to be tackled next. 1.1. Basic idea of process-centered software engineering environments Software engineering environments (SEEs) are meant to support software development. Most of them are focused on a certain type of software processes. In other words: most SEEs are based on a hard-wired (or predefined) software process model. That means, they support exactly that type of software process and no other processes. Either a user accepts that process or he cannot use the SEE. A few SEEs are more flexible: they allow to customize the hard-wired software process model. Nonetheless their support is restricted to a small family of similar processes. The reason for this is that different types of processes require different tools (an object oriented software process, for example, may require support by a UML specification tool, while a procedural software process may need a tool for functional specification). Process-centered software engineering environments (PCSEEs) give up the notion of a predefined process model. They support a wider variety of processes. Sometimes this wider variety is based on parameterization of the PCSEE (in extremely simple cases by defining the tools to be used). Other PCSEEs enable flexible software process models by considering the process model as parameter. Process models used in this way should define, which software development activities are to be executed when and by whom, they should identify tools to be used and the format of documents to be created and/or manipulated. Then, the process model is interpreted at runtime to identify which process behavior has to be supported. In concrete this means, that software developers are reminded of activities which have to be carried out, automatic activities are executed without human interaction and consistency between documents is enforced up to a certain level. This idea of a PCSEE is illustrated in figure 1. A process model is plugged into an infrastructure for a PCSEE. Both together build a PCSEE. In the academic arena many prototypes have been built to illustrate the concepts of flexible PCSEEs. Examples of very early prototypes of this kind are ALF [Derniame

Figure 1. Scheme of a PCSEE.

PROCESS-CENTERED SOFTWARE ENGINEERING ENVIRONMENTS

365

and Gruhn 1994], Merlin [Peuschel and Schäfers 1992], MELMAC [Deiters and Gruhn 1998], and SPADE [Bandinelli et al. 1994]. The notion of flexible process support costs an extra price. The more flexible and adaptable the PCSEE is (in other words, the wider the variety of processes which can be supported), the weaker is the support for a concrete process. If, for example, arbitrary tools can be integrated into a PCSEE infrastructure, then the PCSEE cannot do much more than just call the tools in the right order. It can very obviously not enforce more detailed consistency conditions. A compromise is to let a PCSEE support a certain range of processes. This range may be defined in terms of a meta-model which has to be respected by concrete software process models. In this case, a process model has to be expressed in terms of predefined object types, relationships, etc. which are defined in the meta-model. The PCSEE is then capable of supporting all process models which can be expressed in terms of the meta-model. 1.2. Basic idea of software process management The basic idea of software process management is to support software processes throughout their entire lifecycle. The seminal work in this field is that of Osterweil [1987], whose claim is that software processes are software, too. His conclusion is that software process models should be handled like ordinary software. That means that requirements for software process models should be analyzed, that they should be specified, designed, implemented etc. The attractive controversy around this hypothesis is also due to the article of Lehman [1987] who points out that software systems are feedback systems and that software processes, therefore, are affected by some uncertainty principles [Lehman 1989]. His conclusion is that software processes necessarily have to deal with late and changing requirements and that it is software process inherent that users know what they want only after getting in contact with first software versions and, thereby, learning what software can be used for. Influenced by these two positions of Osterweil and Lehman, the question how to manage development, analysis, deployment and evolution of software process models obtained a central position in the software process community [Derniame et al. 1998]. The key activities of software process management and their relationships are shown in figure 2. Modeling of software processes results in first versions of software process models. These models typically describe which activities have to be carried out when, objects of which types have to be created, who is responsible for which activities and which tools have to be used. These models are used for various purposes: process model analysis, process support and continuous model improvement. Processes are modelled for different purposes. These purposes have a substantial impact on the level of detail a process model should have. The main purposes are: • Documentation of software processes. One purpose of software process modelling is to document processes. Process models are used to tell new team members how to

366

GRUHN

Figure 2. Activities of software process management.

participate in the overall process and to make the process transparent to everybody involved. Process models are used as the basis of training new developers. If process models are used for training purposes, they usually have to illustrate how activities are related and which documents have to be produced and exchanged, but they do not necessarily have to describe control and data flow details. • Analysis of software process models. If the goal of process modelling is to improve software processes systematically and if shortcomings shall be eliminated profoundly, the process models should be subject to analysis. Process model analysis usually is based on process simulation [Schöf et al. 1995], animation of simulated processes and on statistical evaluation of simulation traces. If process models are formally described, then process model properties can be proven. These properties apply to all processes which are executed based on the model [Bandinelli et al. 1994]. Results of process model analysis are a valuable input to software process improvement. • Software process improvement. Usually process documentation is closely related to the purpose of software process improvement. The findings gathered during process modelling and the results of process model analysis usually indicate how actual processes can be improved in order to contribute to improved process productivity and product quality [Avrilionis et al. 1996; Sakamoto et al. 1998]. Improvements of software processes can be organised according to defined process improvement guidelines, like SPICE [SPICE 1997], ami [AMI 1995] or CMM [Konrad et al. 1996]. They can also be based on the removal of deficiencies which are considered most harmful. • Workflow management. For routine based and stable business processes (as, for example, known in insurances or banks), workflow management [Alonso et al. 1996; Grefen et al. 1999] is an important goal of process modelling. The idea of workflow management is that process models are used as basis of real processes, i.e. real processes are governed on the basis of the underlying process models. A workflow


367

engine checks process models and the actual process state in order to identify which activities can be executed and lets potential participants know about it [Georgakopoulos et al. 1994; Heinl et al. 1999]. This paradigm can be applied to certain parts of software processes. But only to those who fulfil the two requirements mentioned above: they should be routine based and stable. If processes are too much determined by exceptions and variants, then usually not all potential variants can be described in advance (and accordingly the level of detail needed for a workflow style execution cannot be reached). Parts of software processes which shall be supported in a workflow style, have to be described in detail. All pre- and post-conditions of activities have to be defined, all object types have to be specified and it has to be defined which tools are to be used under which conditions. • Automation. The process modelling purpose of automation is closely related to the purpose of workflow management. While workflow management tries to automate the coordination between activities (by transferring the task to identify what can be done next to the workflow engine), the immediate automation of single activities is another purpose of process modelling. In the context of software processes, activities like checking in and out of configuration units, building releases, evaluating test set coverage etc. usually can be automated. If automation is a major goal, then at least the preconditions for activities to be automated have to be described in detail. • Monitoring. Another purpose of process modelling is to measure the deviation between what processes are supposed to look like and how they actually behave. In this case, process models do not have to encompass all details as, for example, needed for workflow management, but they should clearly express what activities should be executed and in which order. Then, traces of real world processes can be used to identify what the deviations are. Usually, process monitoring is not a self-contained purpose, but only a first step towards software process improvement or process automation. • Deriving support for tool integration. Based on the assumption that not all parts of software processes are suited for workflow management support and that different parts of software processes deserve different kinds of support and based on the experience that different software processes require different tools, the integration of which results in process specific challenges, a modest – even though worthwhile – purpose of process modelling is to identify the requirements for tool integration in the context of a concrete process model. These requirements concern the middleware and its services to be used and the way tools should be integrated (for example, by data integration, process integration, user interface integration). 2.

A view onto the history of SEEs

The first generation of tools supporting software processes was built in the 1970s. These tools provided isolated support for single activities like programming, debugging etc. rather than supporting the software process as such [Harrison et al. 2000]. The more of these isolated tools were built and used, the more urgent it became to integrate them

368

GRUHN

somehow. Results produced with the support of one tool had to be processed by another tool. Thus, at least some sort of data flow integration was necessary. The more tools were integrated in this way, the more obvious it was that some sort of user interface integration and data integration would alleviate the usage of such tool sets. Roughly speaking, tool integration of this type followed a waterfall lifecycle notion of software development. The result of requirements analysis was input for a specification tool, the outcome of the specification tool was input for a design tool, etc. Based on this straightforward integration of originally isolated tools, the first notion of the software process came to the consciousness of the software engineering community. This kind of integration, however, suffers from two main drawbacks: 1. Early results of development become invalid by each modification of a later result, simply because they are not updated. If, for example, a late requirement occurs after releasing a software version, then there are only two choices: • either all documents (requirements document, specification, design) are modified in order to reflect the new requirement, • or only the software code is updated, which is obviously a quicker even though consistency endangering situation, because earlier documents and software code do not match any more. 2. Consistency conditions covering more than one document (for example, two requirements should always be tested in conjunction) are hard to express and cannot be handled by means of isolated tools focusing on individual activities. As a result of these drawbacks, first generation SEEs do not support any notion of software process, but only single activities. Process progress is neither enforced nor endorsed. If at all, then the process notion has to be established in organizational guidelines. As reaction to these drawbacks, the 1980s were determined by integrated tool sets which more and more focused on the software process as an entity to be supported as such. Tool sets of this type are called second generation SEEs. Since their origin is also due to the consistency problems raised by first generation SEEs, many second generation SEEs tend to over-compensate consistency problems of first generation SEEs. In other words: they pay strict attention to consistency enforcement. The consistency notions of these SEEs usually are rather strict, they cover different types of documents. In some cases, consistency within and between documents turns out to be the major driving force for the software processes to be supported. Second generation SEEs support exactly one kind of software process (and usually prescribe the use of a particular set of tools). They have a few important advantages: • • • •

they can enforce a high level of consistency between documents produced, they can guide software developers through the supported process, they always know in detail the state of the software process, and they can automate parts of the process (e.g., in configuration assembly, testing).


369

These SEEs also have two major drawbacks: 1. Developers are strictly governed by consistency conditions. They have to do many activities just in order to create consistent software process and document states. Real development progress sometimes is burdened by consistency-preserving activities. 2. Even worse as for first generation SEEs, second generation SEEs support exactly one type of software process. Due to the strict notion of consistency, documents have to be manipulated in a certain order. Thus, even the mere change of the order of activities (or tool usage) is not possible. The replacement of a tool by another one requires enormous efforts. Typical examples of this generation are SEEs like PRADOS and Maestro, which – even though successful from a SEE vendor perspective – do not at all keep the promises of improved software development productivity, better transparency of the software process or improved usability. Due to the drawbacks mentioned, second generation SEEs are hardly accepted by software developers. They do not want to use highly integrated and process enforcing environments. Most developers do at least object to guidance and governance in the early activities of software development. In these activities human problem solving is needed most urgently and most supporting tools tend to overburden these activities with guidelines, rules and “syntactical” support. Instead of using such tools, software developers are used to their favorite tools, to certain processes (often only to fragments of overall software processes), and to certain ways of communication with each other and with the supporting infrastructure. Even though second generation SEEs were not the silver bullet to software process problems, their valuable impact on the software process field has to be mentioned. Firstly, they started the discussion on software processes. As one of the beneficial results of this discussion, the Capability Maturity Model transferred the academic process discussion into industrial practice and, thereby, helped substantially to improve real world software processes. In a second step this trend resulted into a set of process models which incorporate current best practices and which can easily be adapted for industrial software development. Examples are the Unified Process (built around UML) and process elements known from Extreme Programming. 1. The first wave of PCSEEs originated from the discussed disadvantages of second generation SEEs. Their aim is to allow a SEE to support different kinds of software processes and to parameterize a PCSEE by a process model, which actually determines how the PCSEE behaves. A key requirement for a PCSEE is that it should support the modeling of processes (simply because the plug in parameter has to be described somehow). Despite the obvious improvement of PCSEEs (compared to second generation SEEs), there are also some disadvantages. These are: software process models have to be built from scratch. The process modeling languages used today are cumbersome and error-prone. Thus, the process of deploying a PCSEE is tedious and lengthy.

370

GRUHN

2. Integration of tools to be used in software processes is still expensive, sometimes even hardly possible. This is due to incompatibilities between PCSEE infrastructure and concrete tools needed for the support of particular software processes. 3. PCSEEs are meant to drive processes forward (according to the software process model plugged in). The mechanisms for driving processes are usually too much workflow-style. That means, software developers are told to do what in which order and by usage of which tools. Certain parts of software processes are not suited for such strict governance. Besides of these technical hindrances it has to be mentioned, that PCSEEs did not have a strong impact onto industrial software development by now. They helped to establish a process notion in many companies, but commercially available PCSEEs (such as Process Weaver) are rare and not very successful. From mid 1990s on, the trend is to keep SEEs simple. The result looks familiar, some people’s assessment is that the software engineering community deliberately return to our roots. Full-fledged process support is considered too restrictive, too expensive and too clumsy. Instead, best-of-breed approaches are taken. That means, one takes the “best” UML specification tool, the most suited Java programming environment, etc. and integrates them loosely. The advantages are obvious: it is easy to get started, decisions for a particular tool do not have to be over-burdened by company-wide strategic decisions (and other excuses for doing nothing). The disadvantages are also obvious: the chosen tools are not integrated, they do not support a coherent notion of software process. In many companies we recognize the trend to integrate the chosen tools individually and proprietary. Generators which, for example, accept UML class diagrams as input and generate code frames to be used by a programming environment and GUI frameworks which are meant to offer libraries of graphical user interface elements are typical solutions to these problems. These home-grown solutions ensure, that software processes become hard-wired for the rest of a company’s software system lifetime. Even worse, the glue needed to link tools is proprietary and dependent on tool releases. This can easily be identified as the worst situation SEE users ever haven been stuck to. In other words: we are at the edge of a SEE period which reasonably could be called “back to the 1970s,” but which, unfortunately, is dependent much more than ever before on a functioning SEE infrastructure. Our conclusion is that there are so many software processes, tools, and different levels of rigidity for enforcing software processes, that next generation SEEs have to available, flexible, and non-intrusive. They should ensure place and name transparency and they should allow distributed access to tools and object. A SEE fulfilling these requirements could also be called a Software Process Middleware. 3.

Distributed processes and software process middleware

Software processes tend to be more and more dispersed over various sites. This is due to general trends towards global markets and towards cost-optimized software processes.


371

This, for example, may mean that certain parts of processes are outsourced to partners with lower cost levels or that local teams are responsible for certain process parts. Generally speaking, the assumption that software processes can be described as if they were central is a costly over-abstraction. Our approach is to model software processes including their distribution to different sites and to use an application domain specific middleware to support them. Both aspects are discussed in the following sections. 3.1. Modeling of distributed software processes – Process Landscaping Traditional development and management of software processes is based on the idea of centralized real world processes carried out at one location. Reasons for modelling these processes, their chronological and hierarchical order, their interrelations and their deliverables at different levels of detail is to better understand their tasks and dependencies [Tully 1995]. We call a set of hierarchically structured process models, related via interfaces, a process landscape. Each activity of a process model belongs to the process landscape, but can also be refined by a landscape again. We develop such a landscape by applying the Process Landscaping method [Gruhn and Wellen 2000] (also called Process Landscaping in the following). The globalization of companies leads to an increasing set of processes related within a process landscape. Different partners carrying out parts of the processes have varying degrees of autonomy and are distributed among different locations [Graw and Gruhn 1995]. In order to understand how process landscapes are supposed to work, we have to recognize, how processes are spread over sites. Process Landscaping supports a so-called locational view, which clearly show, what activities of which processes are supposed to take place at a concrete location. Derniame et al. define a view as the particular approach to a software process conveyed by a (sub) model [Derniame et al. 1998]. They distinguish between models describing activities, organizational structures, products, resources or roles. This means different models representing different aspects of the same process landscape. Finkelstein and Sommerville define the term in a similar way. For them “the construction of a complex description . . . involves many agents,” each with “different perspectives or views of the artefact or system” where the views are “partial or incomplete descriptions . . .” [Finkelstein and Sommerville 1996]. The viewpoints framework has been used and documented, e.g., in [Goedecke et al. 1999]. In the context of Process Landscaping the term view is used for describing a certain perspective of the entire process landscape, just by emphasizing different properties. In order to analyze and simulate the example process landscape, we also have to consider its formal basis. First experiences with the Petri net notation [Genrich 1987] showed that this notation is suitable for a lot of analysis requirements. Unfortunately, the notation is too complex, when a modeler does, e.g., not want to depict concrete order of events and detailed types of information exchange from the beginning of a modeling project [Gruhn and Urbainczyk 1998]. For the upper levels of a process landscape it is sufficient to model only key activities and the most important information needed

372

GRUHN

Figure 3. Scheme of a process landscape.

or produced. Following these considerations, we developed a simplified language less complex than Petri nets, called Process Landscaping Language (PLL). Starting with a lean language core of PLL, we are able to model the upper levels of a process landscape in a fast and simple way. With this notation we can analyze features of the landscape like data persistency and communication infrastructure. PLL can be easily extended to the more complex notation of Petri nets, if there is the need to analyze dynamic aspects of a process landscape like amount of data, parallelism of activity execution, or communication types for distributed processes like push/pull communication and ping-pong communication [Gruhn and Wellen 1999]. Figure 3 shows a scheme of a software process landscape. It starts with a high level description, which just shows very general process clusters. These can be subject to different types of refinements: either by other process landscapes or by concrete process models. Interfaces between processes are first order entities, they also can be refined. For more details we refer to [Gruhn and Wellen 2001a], where the process landscaping method is described in detail. If processes are distributed and if the communication between process parts contributes to process efficiency and process costs substantially, then it is important to support software processes and their distribution to various sites. This context is discussed in the following section. 3.2. Software process middleware As mentioned above, software processes tend to be distributed. Another trend for PSEEs is that software processes become more and more mobile and federated (compare section 4). Thus, PSEEs should not assume that software processes are central processes


373

to be carried out by a single team at a single site. Instead they have to offer infrastructure for processes which take place at many sites, for software developers who are not statically allocated to a single site and for different ways to carry out processes in a federated way. PSEEs, therefore, have to provide typical middleware services in addition to software process specific services. In academic research we find various contributions which propose solutions to these challenges. The middleware infrastructure developed in the PIE project [Cunin et al. 2001], services provided by the APEL platform [Estublier et al. 1999; Estublier and Belkhatir 1995], and mechanisms identified in the scope of JIL [Staudt Lerner et al. 1998] explicitly deal with problems addressed above. In order to illustrate what a process-supporting infrastructure is supposed to do, we discuss some of the key requirements for such an infrastructure in the following. If a process is distributed, then the software process repository usually is distributed, too. Consistency of a distributed software process repository is difficult to maintain and requires organizational and technical regulations. Even though processes may differ substantially, the basic mechanisms for repository consolidation and consistency preserving are more or less the same. It has to be defined, which kinds of objects can be duplicated and for which it is crucial that unique master versions are available and accessible from all sites, which intervals of inconsistency between duplicated objects are acceptable, whether or not independent updates of duplicated objects (and the entailed problem of modifications which cannot be merged) can be accepted etc. Another key requirement is that certain types of software process objects should be predefined. This is true for all process aspects (development, quality management, project management, configuration management). Typically, object types like component, component interfaces, test case, quality report, project plan, configuration unit, release build plan are defined again and again in each software process model, but they usually do not differ very much. They are also accessed by very typical methods and their update frequency usually follows some general patterns. Examples are: • project plans are updated in regular intervals, • for project plans there should be a master copy which must be readable by everybody, but which can only be updated centrally, • component interfaces are updated frequently until end of design, they are updated from time to time during implementation and they are seldom modified during testing. From a software process modeling and support point of view, it would be convenient to start with a definition of these standard object types and – even more important – with mechanisms for the access to objects of these types. As already mentioned in section 1, parts of software processes are suited for a workflow-based style of execution, others only can be monitored. A software process middleware should provide different kinds of software process execution support for different parts of software processes (compare section 4.1 for more details). A software process middleware should provide support predefined software process fragments. Examples are “discussion of priorities of late requirements,” “up-

374

GRUHN

dating a document on the basis of a quality report,” “bug report management.” All these situations have to be handled in the same way for almost all processes. Thus, it is not necessary to model these process fragments from the scratch again and again and it is neither necessary to develop or choose tools for supporting them (e.g., tools for joint editing of documents, tools for managing and distribution of bugs) again and again. These tools – in contrast to core development tools – usually are not subject to excessive selection procedures. They even do not have to be used company-wide. Thus, a software process middleware can offer tools of this kind without being incompatible with tools being in place already. Considering these requirements, existing general-purpose middleware systems seem to be candidates for such a software process infrastructure. In general, the term “middleware” denotes software, which supports communication between client and server software. It relieves both of them from knowing where the other resides. Typical functionality of middleware systems are support for the exchange of information, data transfer, management of synchronous and asynchronous call of remote services, avoidance of deadlocks, management of communication channels, management of resources (localization services, naming services), security services and performance services. Middleware systems range from simple systems like ftp or email software to full-fledges general purpose middleware systems like CORBA-compliant ORBs, transaction monitor or EJB application servers. Other middleware solutions are also special purpose middleware solutions like groupware systems and workflow systems. They also support communication between remote software systems on the basis of functionality mentioned above, but their focus is on supporting certain types of applications. In the area of middleware systems there are two trends: 1. Middleware solutions tend to provide more and more powerful services. Current services of application servers, for example, offer different kinds of transaction protocols (from simple transaction logic to two-phase commit protocols) and predefined security mechanisms (encryption, public key infrastructures, etc.). 2. Middleware solutions tend to provide services which are close to concrete application domains. In CORBA, for example, services for health care and financial applications are specified. The idea is that certain object types and the related functionality is predefined. In the context of financial applications this could mean that a predefined object type “account” is available and that services for exchanging account information between remotes software systems are available. In contrast to the pure object exchange, such a service would check consistency conditions for account objects. Other middleware solutions like Twister from Brokat and bizware from emagine focus on support for the financial domain. The lower level middleware services are interfaced with application-specific services. The same is true for many application servers, which are extended by services for customer relationship management, for content management, and for personalization of web services. This usually means that object types like customer and customer profile are predefined and that services for exchanging object of these types are available. Beyond object exchange, appli-


375

cation specific services usually also enforce consistency between copies of objects, application specific communication protocols (like HBCI in the financial domain or HL7 in the health care domain). In continuation of these trends, our demand is to use a software process middleware as backbone of a truly process-centered SEE. Some of these services – even though not on the product level – are implemented in ProcessWeb [ProcessWeb 2001], which supports distributed cooperation and in PIE which support on-the-fly changes of running software processes as well as risk analysis of such changes and replanning support [Cunin et al. 2001]. Our approach to define a software process middleware which is domain specific and which clearly focuses on fulfilling the mentioned requirements, has resulted in a system called “Piazza Palermo” [Gruhn and Wellen 2001b], which allows to model, to analyze and to execute distributed software processes. Several processes (in particular for the development of distributed and component-based systems [Book et al. 2000]) have been carried out using this system. The most important benefit is that domain specific abstractions are predefined and that users can choose the level of modeling detail. 4.

Current trends in software process management

The mentioned trend towards middleware solutions which are adapted to the concrete requirements of software process support is also fostered by a few additional observations about the nature of software processes. These observations are discussed below. 4.1. Strictness of process support Software processes encompass parts which are similar to production processes. Other parts are engineering like processes and some parts are so closely depending on human creativity that they could be considered as essentially creative processes. The nature of the overall process is that different process parts demand for different kinds of support. In accordance to this finding, PSEEs have to provide flexible support mechanisms: • Early software development activities should not be prescribed in detail. Experience from earlier processes should be made accessible. Cooperation between teams should be enabled, but it should not be enforced. The software process middleware should monitor what is going one, but it should be completely non-intrusive. In other words, early activities should be monitored and recorded, but not proactively guided. • Specification, design and implementation activities should be handled as engineering processes. Software developers should use proven tools and they should follow abstractions which have proven useful. Good software engineering principles should be applied wherever possible. Well-proven analysis and design patterns should be offered proactively by the software process middleware. The middleware should offer guidance and support when requested or when considered useful.

376

GRUHN

• Other parts, like many configuration management and quality management activities should be described in detail, they should be followed in detail and the PSEE should even enforce them. For such processes the software process middleware should behave like a workflow engine. This is the area where much can be gained from using classical workflow support tools and mechanisms. If we want to follow the idea to consider process models as parameters for PSEEs, then it has not only to be defined which activities have to be executed, but also which process parts are of which type (creative, engineering production). 4.2. Mobile software processes Software processes do not only tend to be distributed over various sites, but they also tend to encompass mobile parts. That means, for certain process participants it is not defined in advance where they are going to do their work. It may not even be clear which activities are executed where and which tools have to be available where before a software process starts. Even worse, it may be subject to ongoing process organization which objects and documents are stored where. In other words, process parts, tools, participants tend to change their site allocation during the process. Mobility of process participants demands that process contexts must be available anywhere anytime (also called nomadic computing). For the software process middleware this means, that mobile access must be supported, that information must be prepared for usage on mobile devices and the notion of process context must be made available anywhere and always. More general, a software process middleware has to abstract site allocations. People do not have to know where documents are stored, where tools are running and where their co-workers reside. 4.3. Federated software processes / Collaborative software processes We already have motivated that many software processes are distributed over different sites. One reason for distribution is that certain parts of software processes are carried out by suppliers/partners/customers and that these process participants are located at different sites. In such situations, distribution of processes comes along with partners having different levels of autonomy with respect to “their” process parts. Figure 4 sketches a simple software process model. It shows that different parts of the overall process can easily be spread over various sites and that partners responsible for these parts tend to claim certain levels of autonomy. The process model describes that a requirements analysis process is followed by an application design process. The result is a set of component specifications, which are input to either external development processes or internal processes which are defined in more detail. This simple example shows that different parts of the overall process are determined by different levels of autonomy: • The requirements analysis part of the process is a highly autonomous one. It is not prescribed what to do in detail. Only the type of the result is fixed. Internal documents


377

Figure 4. Process model with different degrees of autonomy.

produced remain under control of the process and are not made accessible to other process parts. • The application design part of the overall process is also not prescribed in detail, but there may exist certain constraints which demand that certain documents are produced (e.g., gross design document, rationale for component cut, documentation of alternative component cut, etc.). • For the component development part of the process we distinguish two alternatives: either components are developed in-house. Then the process is fix and has to be followed in detail. Or an external partner is responsible for the component development. Then this partner is responsible for his process, he only has to deliver a correct implementation, but everything else is under his control. In the research area of database management systems (dbms) the term “federated dbms” is an established description for a “collection of cooperating but autonomous component database systems” [Sheth and Larson 1990]. The participating databases, possibly heterogeneous, are distributed and integrated to various degrees. We apply the term “federated” to a software process landscape: it consists of a set of (distributed) process models describing processes necessary for the development of software applications. They cooperate with each other via interfaces in order to produce a certain software system. The modelled processes are often also distributed, heterogeneous and integrated to various degrees. These are all properties well known in software process modelling research: for example, in [Alloui et al. 1996], cooperative (and distributed) software processes are discussed, especially requirements for cooperation support through process centered environments. Greenwood considers coordination as a fundamental

378

GRUHN

feature of software process technology [Greenwood 1995]. He criticizes that coordination in software engineering is only achieved by low level details and suggests research results from coordination theory to improve coordination in the area of software process technology. Obbink argues about differentiation and integration of key development processes [Obbink 1995]. Similar to data base management systems he demands a federated organization of different processes like hardware and software engineering (co-engineering) and management activities in order to fulfil market requirements like low costs, short development time and high quality. Cugola et al. and Graw et al. focus on distribution aspects [Cugola et al. 1998; Graw et al. 1996]. Whereas the first authors present a Java event-based distributed infrastructure (JEDI) to support the implementation of reconfigurable distributed software components, Graw et al. discuss coordination issues of distributed modelling and an architecture to support distributed process enaction. The different processes represented as a software process landscape are also autonomous to various degrees. Until now, this property has been analyzed for agents [Decugis and Ferber 1998], robotic systems [Cox and Wilfong 1990] and of course for federated and distributed database systems, but not yet explicitly for cooperating software processes. In database systems research, Veijalainen and Popescu-Zeletin distinguish between three types of autonomy [Veijalainen and Popescu-Zeletin 1986], namely design autonomy, communication autonomy and execution autonomy. Subsets of these types also have been identified. Alloui et al. discuss these and additional types in [Alloui et al. 1996]. Other authors classify autonomy in dependency of their relevance to operating systems and transaction management issues [Garcia-Molina and Kogan 1988]. The approach of Birk to discuss autonomous systems from a more general point of view, also does not consider software processes [Birk 1999]. He summarizes the research issues in autonomous systems as physical devices, distributed, embedded and cooperating autonomously. Autonomy has not been discussed as property of software processes. We conceive that the increasing complexity of software development activities and the increasing difficulty of its management requires discussion of the property of autonomy for software processes. A certain degree of process autonomy supports the management of software projects and can improve the quality of software processes’ cooperation. In this paper we define different types of software process autonomies and discuss their semantics at different levels of degree and granularity. We distinguish three types of autonomy relevant for software process parts: • If a process part retains the control for a certain set of data, it is responsible for updates and other maintenance tasks. But it is also the only one entitled to make changes and to inform other activities about these changes. If this activity also keeps the data persistent, we talk about data autonomy. • We call a process part operation autonomous, if it decides on its own how to produce a requested result and if the internal organization of this process part is not visible to other process parts.


379

• Communication autonomy of a software process part means that the owner of that process part decides on his own if his/her process communicates with other process parts and how information is exchanged. In the extreme case, this may even mean that he/she decides to withdraw the process parts. A software process middleware has to support all kinds of autonomy mentioned. It should allow defining who is owner of which process parts, to define what kind of autonomy has to be applied. During process execution it should ensure the levels of autonomy defined. 5.

Conclusion

SEEs have a history of two decades, isolated tools and their individual integration exist even longer. Each new generation of SEEs was accompanied by promises of productivity gains and shorter and more reliable development cycles. In most cases, some progress was realized, but in the end there does not seem to be a satisfying solution to the problem of flexible support for different kinds of software processes. One result, however, is clear: neither isolated support for single activities (and their adhoc integration) nor sophisticated support for just one kind of software process are acceptable for nowadays multitude of software processes. Thus, PCSEEs have to play important role. This role, however, can only be played convincingly, if the failures of earlier SEE concepts are avoided. We believe that this urgently demands for software process middleware solutions. The development of such a middleware solution can only be successful if we keep in mind: • that software processes are still not completely understood, • that software processes are not production like processes, and • that feedbacks, late requirements and after release modifications are not due to mistakes but to the nature of software processes. If we keep that in mind and if we want to provide support for distributed, mobile and federated software processes, then the – on the first glance very modest – goal to provide middleware support for software processes is a major challenge for the next generation of SEEs. References Alloui, I., S. Latrous, and F. Oquendo (1996), “A Multi-Agent Approach for Modelling, Enacting and Evolving Distributed Cooperative Software Processes,” In Proceedings of the 5th European Workshop on Software Process Technology EWSPT’96, Nancy, France, C. Montangero, Ed., Lecture Notes in Computer Science, Vol. 1149, pp. 225–235. Alonso, G., D. Agrawal, A. Abbadi, and C. Mohan (1996), “Functionality and Limitations of Current Workflow Management Systems,” IEEE Expert Journal.

380

GRUHN

Avrilionis, D., N. Belkhatir, and P.-Y. Cunin (1996), “Improving Software Process Modelling and Enactment Techniques,” In Software Process Technology – Proceedings of the 5th European Workshop, Nancy, France, C. Montangero, Ed., Lecture Notes in Computer Science, Vol. 1149, pp. 65–74. Bandinelli, S., A. Fuggetta, C. Ghezzi, and L. Lavazzy, “SPADE: An Environment for Software Process Analysis, Design and Enactment,” In Software Process Modelling and Technology, A. Finkelstein, J. Kramer, and B. Nuseibeh, Eds., Wiley, London, 1994, pp. 223–244. Birk, A. (1999), “Autonomous Systems as Distributed Embedded Devices,” http://arti.vub.ac. be/∼cyrano/AUTOSYS/index.html Book M., V. Gruhn, and L. Schoepe (2000), “Realizing an Integrated Electronic Commerce Portal System,” In Proceedings of the Americas Conference on Information Systems, K. Siau, Ed., Long Beach, CA. Cox, I.J. and G.T. Wilfong (1990), Autonomous Robot Vehicles, Springer. Cugola, G., E. Di Nitto, and A. Fuggetta (1998), “Exploiting an Event-Based Infrastructure to Develop Complex Distributed Systems,” In Proceedings of the 20th International Conference on Software Engineering, Kyoto, Japan, pp. 261–270. Cunin, P., R. Greenwood, L. Francou, I. Robertson, and B. Warboys (2001), “The PIE Methodology – Concept and Application,” In 8th European Workshop on Software Process Technology, Lecture Notes in Computer Science, Vol. 2077, pp. 3–26. Decugis, V. and J. Ferber (1998), “Action selection in an autonomous agent with a hierarchical distributed reactive planning architecture,” In Proceedings of the Second International Conference on Autonomous Agents (Agents’98), K.P. Sycara, T. Finin, and M. Woolridge, Eds., ACM Press. Deiters, W. and V. Gruhn (1998), “Process Management in Practice – Applying the FUNSOFT Net Approach to Large Scale Processes,” In Automated Software Engineering 5, Special Issue on Process Technology, 7–25. Derniame, J.-C., B.A. Kaba and D. Wastell (1998), “The Software Process: Modelling and Technology,” In Software Process: Principles, Methodology and Technology, J.-C. Derniame, B.A. Kaba, and D. Wastell, Eds., Lecture Notes in Computer Science, Vol. 1500, Springer Verlag, pp. 1–12. Derniame, J.-C. and V. Gruhn (1994), “Development of Process-Centered IPSEs in the ALF Project,” Journal of Systems Integration 4, 2. Estublier, J., M. Amiour, and S. Dami (1999), “Building a Federation of Process Support Systems,” In Proceedings of the International Joint Conference on Work Activities and Collaboration, WACC’99, San Francisco, CA, pp. 197–206. Estublier, J. and N. Belkhatir (1995), “A Generalized Multi-View Approach,” In 4th European Workshop, EWSPT’95, Noordwijkerhout, The Netherlands, W. Schäfer, Ed., Lecture Notes in Computer Science, Vol. 913, Springer Verlag, pp. 179–184. Finkelstein, A. and I. Sommerville (1996), “The Viewpoints FAQ,” IEE Software Engineering Journal 11, 1, 2–4. Garcia-Molina, H. and B. Kogan (1988), “Node autonomy in distributed systems,” In Proceedings of the International Symposium on Databases in Parallel and Distributed Systems, Austin, TX, pp. 158–166. Genrich, H.J. (1987), “Predicate/Transition Nets,” In Petri Nets: Central Models and Their Properties, W. Brauer, W. Reisig, and G. Rozenberg, Eds., Springer, Berlin, pp. 208–247. Georgakopoulos, D., M.F. Hornick, and A. Sheth (1995), “An Overview of Workflow Management: From Process Modelling to Workflow Automation Infrastructure,” Journal of Distributed and Parallel Databases 3, 2. Goedecke, M., T. Meyer, and G. Taentzer (1999), “ViewPoint-oriented Software Development by Distributed Graph Transformation: Towards a Basis for Living with Inconsistencies,” In Proceedings of the 4th IEEE International Symposium on Requirements Engineering, Limerick, Ireland. Graw, G., V. Gruhn, and H. Krumm (1996), “Support for Cooperating and Distributed Business Processes,” In Proceedings of the International Conference on Parallel and Distributed Systems (ICPADS’96), Los Alamitos, CA, IEEE Computer Society Press, pp. 22–31.


381

Graw, G. and V. Gruhn (1995), “Process Management In-the-Many,” In 4th European Workshop on Software Process Technology, EWSPT’95, Noordwijkerhout, The Netherlands, April, W. Schäfer, Ed., Lecture Notes in Computer Science, Vol. 913, Springer Verlag, pp. 163–178. Greenwood, M. (1995), “Coordination Theory and Software Process Technology,” In Software Process Technology, Proceedings of the 4th European Workshop on Software Process Technology, EWSPT’95, Noordwijkerhout, The Netherlands, W. Schäfer, Ed., Lecture Notes in Computer Science, Vol. 913, pp. 209–213. Grefen, P., B. Pernici, and G. Sanchez, Eds. (1999), Database Support for Workflow Management – The WIDE Project, Kluwer Academic. Gruhn, V. and J. Urbainczyk (1998), “Software Process Modelling and Enactment: An Experience Report,” In Proceedings of the 20th International Conference on Software Engineering, Kyoto, Japan, pp. 13–21. Gruhn, V. and U. Wellen (1999), “Software Support for Distributed Business Processes,” In Proceedings of the Asia–Pacific Software Engineering Conference, IEEE Computer Society Press, Takamatsu, Japan. Gruhn, V. and U. Wellen (2000), “Structuring Complex Software Processes by “Process Landscaping,” In 7th European Workshop on Software Process Technology, EWSPT 2000, Kaprun, Austria, R. Conradi, Ed., Lecture Notes in Computer Science, Vol. 1780, Springer Verlag, pp. 138–149. Gruhn, V. and U. Wellen (2001a), “Analyzing a Process Landscape by Simulation,” Journal of Systems and Software 59, 3. Gruhn, V. and U. Wellen (2001b), “Process Landscaping: Modelling Distributed Processes and Proving Properties of Distributed Process Models,” In Unifying Petri Nets – Advance in Petri Nets, H. Ehrig, G. Juhas, J. Padberg, and G. Rozenberg, Eds., Lecture Notes in Computer Science, Vol. 2128, Springer. Harrison, W., H. Ossher, and P. Tarr (2000), “Software Engineering Tools and Environments,” In Proceedings of 22nd International Conference on Software Engineering, pp. 263–277. Heinl, P., S. Horn, S. Jablonski, J. Neeb, K. Stein, and M. Teschke (1999), “A Comprehensive Approach to Flexibility in Workflow Management Systems,” In Proceedings of the International Joint Conference on Work Activities Coordination and Collaboration, WACC’99, San Francisco, D. Georgakopoulos, W. Prinz, and A.L. Wolf, Eds., ACM, pp. 79–89. Konrad, M., M. Chrissies, J, Ferguson, S. Garcia, B. Hefley, D. Kitson, and M. Paulk (1996), “Capability Maturity Modeling at the SEI,” Software Process Improvement and Practice 2, 1. Lehman, M.M. (1987), “Process Models, Process Programs, Programming Support,” In: Proceedings of the 9th International Conference on Software Engineering, Monterey, CA. Lehman, M.M. (1989), “Uncertainty in Computer Applications and Its Control Through the Engineering of Software,” Journal of Software Maintenance 1, 1, 3–27. Obbink, J.H. (1995), “Process Differentiation and Integration: The Key to Just-in-Time in Product Development,” In Proceedings of the 4th European Workshop on Software Process Technology, EWSPT’95, Noordwijkerhout, The Netherlands, W. Schäfer, Ed., Lecture Notes in Computer Science, Vol. 913, pp. 79–92. Osterweil, L. (1987), “Software Processes are Software Too,” In Proceedings of the 9th International Conference on Software Engineering, Monterey, CA. Peuschel, B. and W. Schäfers (1992), “Concepts and Implementation of a Rule-Based Process Engine,” In Proceedings of the 14th International Conference on Software Engineering, Melbourne, Australia. ProcessWeb Documentation (2001), http://processweb.cs.man.ac.uk/ Sakamoto, K., K. Najakoji, Y. Takagi, and N. Niihara (1998), “Toward Computational Support for Software Process Improvement Activities,” In Proceedings of the 20th International Conference on Software Engineering, Kyoto, Japan, pp. 22–32. Schöf, S., M. Sonnenschein, and R. Wieting (1995), “Efficient Simulation of THOR Nets,” In Proceedings of the 16th International Conference on Application and Theory of Petri Nets, Torino, Italy, G. de Michelis and M. Diaz, Eds., Lecture Notes in Computer Science, Vol. 935, Springer Verlag, pp. 412–431.

382

GRUHN

Sheth, S.P. and J.A. Larson (1990), “Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases,” ACM Computing Surveys 22, 3. SPICE (1997), “Software Process Assessment – Part 1: Concepts and Introductory Guide, Version 1.00.” Staudt Lerner, B., L.J. Osterweil, S.M. Sutton Jr., and A. Wise (1998), “Programming Process Coordination in Little-JIL,” In 6th European Workshop on Process Technology, Weybridge, UK, V. Gruhn, Ed., Lecture Notes in Computer Science, Vol. 1487, Springer, Heidelberg, Germany, pp. 127–131. The ami User Group (1995), “ami – Applications of Metrics in Industry – A Quantitative Approach to Software Management.” Tully, C. (1995), “The Software Process and the Modelling of Complex Systems,” In 4th European Workshop on Software Process Technology, EWSPT’95, Noordwijkerhout, The Netherlands, W. Schäfer, Ed., Lecture Notes in Computer Science, Vol. 913, Springer Verlag, pp. 138–143. Veijalainen, J. and R. Popescu-Zeletin (1986), “On Multi-Database Transactions in Cooperative, Autonomous Environment,” Technical Report, Hahn-Meitner Institut, Berlin, Germany.