John Wiley and Sons. 17.R. Kadia. Issues Encounters in Building a Flexible ... Hefley, D. Kitson, and M. Paulk. Capability Maturity. Modeling at the SEI. Software ...
Software Process Modeling and Eriactmient:
An Experience Report related to Problem Tracking in an Industrial Project Volker Gruhn University of Dortmund Computer Science 4422 1 Dortmund Germany ++ 49 (0) 23 1 755 2782 gruhn @ 1s1O.informatik.uni-dortmund.de
Juri Urbaiinczyk Open Software ,4ssociates Mainzer Landstrasse 82-84 60489 Frartkfurt Germany ++49 (0) 69 7896 0145 juri.urbainczyk:@osa.de they could be managed as programs [20], the early 90s basically focused on the question what a suitable software process modeling language should look like. A number of languages following different language paradigms were proposed. The most prominant representatives of such languages include rule-based [ 12,18,23], Petri-net-based [ 1,7] and object-oriented 1anguaLges [ 11,161.
ABSTRACT The paper provides an overview of process research and the application of research results to practice and then describes process models using FUNSOFT nets and a workflow management system LEU. The example from which the experience is drawn is that of a problem tracking system and the components of the model are described and illustrated. The experience reported comes in three flavors: the appropriateness of FUNSOFT nets as a modeling mechanisms and the alternative use of state transition diagrams; the benefits of the model and its support on the business process; and finally some implications for process research.
The most recent years show another trend: the software process community is ready to accept that there is room for many process modeling languages and there is an emerging consensus that graphical process modeling would help to alleviate process modeling for nonlanguage experts. At the same time, we recognize a research emphasis on software process evolution issues. While the need for software process evolution has been recognized early [3,5] the community seems now ready to accept what M. Lehman and IL. Belady have proposed already in 1985 [21]: software processes are complex entities which are inherently evolution based. This means, evolution of process models is not due to planning errors or unexpected technology shifts, but due to the fact that software processes have an impact on their surrounding and that this impact evokes feedback and thereby process model modifications. Another tirend is to focus on certain activities of the lifecycle for software process models and to point out how these activities are related to the corresponding software engineering activities.
Keywords software process technology, workflow management, FUNSOFT nets, problem tracking
1 STATE OF SOFTWARE PROCESS RESEARCH A lot of attention is paid to software process modeling and enactment in software process research community. There are regular European Process Technology Workshops [22], there are International Software Process Workshops [ 141, there is a series of International Conferences on the Software Process [24], and most conferences on software engineering spend one or several sessions on software process issues. The focus of the mainly academic research work on software processes has changed over time. While the late 80s were determined by the question whether or not software process models should be considered programs 1251 or if they are too much dependent on human interaction and creativity as if
Concurrent to these shifts in software process research, many research groups worldwide have been building prototypes of toolsets supp'orting software process modeling, software process model analysis and software process enactment. Examples of these environments are ALF [SI, Arcadia [ 171, Marvel and its successor Oz [ 181, MELMAC [6], HFSP [26] and !SPADE [21. Summing this up, much effort hias been spent on software process research and there is some progress. Despite the multitude of prototypes and research groups, the software
0-8186-8368-6/98 $10.00 0 1998 IEEE
13
process research has not had as much impact onto industrial software processes as expected a decade ago (at least as far as actual enaction of industrial software processes based on software process models is concerned). Actually most experience in softwarc proccss enaction relates to small and somewhat isolated software process experiments, but not to the real world of industrial software development [IO, 151.
developers, customers and sales people, from insufficient test approaches and from missing change management mechanisms. Looking at these problems, software process enactment was not the most urgent problem. An overall and explicit model of the software process was much more important. Thus, the benefits of software process modeling were obvious. Unfortunately, the requirements for this kind of software process modeling were not fulfilled by most of the process modeling tools available at that time. MELMAC, as a typical representative of this class of tools focused very much on an integrated modeling and enactment. Accordingly, the representations of process models were appropriate for interpretation by a workflow engine, but not very intuitive for human users. Instead of representing the different aspects of software processes (organizational context, structure of object types and documents, involved roles and their permissions) in an intuitive way, all facets of edit-(;ompile-test cycles could be expressed in one language and all of them were formally defined.
2 APPLYING SOFTWARE PROCESS MODELING AND ENACTMENT IN INDUSTRY In this section we describe our experience of putting an academic prototype of a toolset for software process modeling into practice. Even though this experience is based on only one prototype we assume that our experience in software process technology transfer reveals some aspects that are symptomatic for the gap between software process research and industrial software engineering. This assumption is underpinned by the experience made in similar experiments [4, IO]. 2.1 Enthusiam (1987-1990) After building a prototypc (the MELMAC system mentioned above) we felt that we knew enough about software processes to improve real world processes. Of course, the prototype was neither stable, nor documented, nor used by anybody else, but there was a deep conviction that the ideas and concepts were great. At that time, most developers and enthusiasts of MELMAC left to form a company. There was little doubt that real real world software processes would urgently demand for formal process modeling and process enactment.
Besides of this mismatch of requirements and tool support, the multitude of exceptions in industrial software processes turned out to be a major obstacle in process modeling. Most of the processes to be modeled were on level 1 or between level 1 and 2 of the CMM [ 191. Thus. certain parts of these processes were unclear and interactions between process participants were not explicitly defined. In other words: there was hardly a process idea.
-
2.2 Frustration (1990 1993) The attempt to model real world software processes and to even enact them in an industrial setting (a software house with about 400 employees) showed one thing very clearly: MELMAC was in principle powerful enough to model the core of software processes, but it lacked documentation, robustness and other product features. which are usually not implemented in prototypes. Another issue in this phase was that the terminology of software process researchers and software practitioners did hardly overlap. While the software process researchers were used to a terminology built of process, object models, process modeling language, prescriptive and descriptive style of modeling processes, the industrial software developers were communicating in terms of budget overruns, patches for bug fixes and transaction monitors. Thus, it took lengthy discussions and many meetings to agree on some experiments in software process modeling. These experiments essentially showed one thing: the typical software process toy problems discussed in the late 80s (like the simplified edit/compile/test examples and like the change request examples as discussed at the 6th and the 9th International Software Process Workshop) oversimplified the real world problems dramatically. Software process support in an industrial setting turned out to suffer most from inappropriate configuration management, from communication problems between
Summing this up, the low maturity of industrial processes and the mismatch between this situation and the enactment focus of software process tools both did not promise a fast return on investment for software proccss modeling at that time.
2.3 Consolation (1992 - 1996) Once we recognized that there was little benefit in software process modeling andl enactment, we had the opportunity to investigate business processes which were to be supported by a new software system. The development of this software system started in 1992. The system to be developed, called WIS, was supposed to support all business processes ifrom the area of housing construction and administration (contract management, accounting, real estate management, repairs, etc.). It was decided to dcvelop this system in a process-oriented way. This means, business processes were modeled, dialogs. reports and other functions were plugged into these models, and the runtime support was created by workflow management on the basis of the business process models. Business process models were described with FUNSOFT nets (as they were implemented in the MELMAC prototypc before), by cxtended entity-relationship diagrams and by organizational diagrams showing who is responsible for what. The budget allocated for the development of WIS was about 18 million US $. The experience in the WIS development is described in [151
14
in more detail. Since MELMAC suffered from being a prototype, but not a product, MELMAC had to be reimplemented at first. The result, called LEU, is a toolset for process modeling, process model analysis and workflow management [9].
Customers and consultants can log on to the system via an Internet or Intranet interface. By introducing the new business process oriented problem tracking system we made the life cycIe of the problem reports transparent. Information on the problem reports currently processed became available for everyone at any time. This hellped to decide whether a problem had already been registered or even been solved. Inquiries of customers concerning the state of their problem reports could be answered immediately. The effort for registering a problem report was decreased substantially. The complete process of managing problem reports became less error-prone. The latter was achieved by consistency checking functions, that were attached to the dialogs of the PTS and which check problem reports for consistency. from being inserted. Some activities could even be made automatic, like the printing of customer letters. Therefore the duration of the problem solving process should decrease.
In the meantime, the WIS system is used at several large customers from the housing construction and administration areas. The largest of these customers uses WIS to administrate about 40.000 apartments. LEU as basis of WIS is used at these customers to workflowmanage their everyday administration processes.
2.4 Late Finding (1996 - 1997) After building and deploying the WIS system in a business process oriented way, we came across one problem: the tracking of errors in WIS and the change request mechanisms for WIS were basically manual processes. Since more and more customers were issuing change requests (at the very beginning of the introduction up to 50 per day and customer), we decided to implement this part of the overall WIS software process in a workflow style based on LEU. This perfectly fits to the finding that software developers tend to automate problem tracking processes first [27]. Since the deviation to business processes and back to certain parts of software processes eventually means, that software process technology is applied to (parts 00 software processes, we describe the support for the problem tracking process in more detail in the following.
In the context of LEU a business process model consists of an object model, an organization model and an activity model. These parts of the PTS are described in the following.
3.1 The object model of the PT'S The main object types of the PTS object model are Problem Report (PR), Configuration Unit (CU) and Patch. They are connected by n:m-relations (compare picture 1).
3 THE PROBEM TRACKING SYSTEM EXAMPLE The implementation and maintenance of the software system WIS must be supported by appropriate software. The main objectives are support and enactment of the processes problem tracking, 'software configuration management and requirements management. These processes are strongly cooperative and highly repetitive. Moreover, these processes were well-defined, since all internal business processes (BP) had been examined and described due to the introduction of a quality management system (QMS) for attaining EO-9000 certification. As a consequence we decided to develop a business process based Problem Tracking System (PTS) using the available LEU environment.
The boolean attribute Internal of the object type PR differentiates between:
internal Problem Reports that are created by the quality assurance during the ;acceptance phase and external Problem Reports which are created by customers and which refer to releases already in production. Every single problem report is identified by a unique key, which is stored in the attribute Problem Number. The contents of the problem report is stored in the attributes Problem Description, Error Code and Effect of Error. At any time, every problem report has a Person Responsible who is in charge to handle the PR. The name of this employee as well as time and state of the PR are recorded. This means that they are stored in a list, which represents the whole lifetime history of the problem report and can be recalled at any time in order to initiate escalation mechanisms. The attributes Slate and Result describe the current condition of a Problem Report. State shows the position of the problem report in the business process. Some of the registered problem reports are rather new requirements than errors. This can be documented by setting the Boolean attribute Request to 'True'. Thus, new requirements can be managed by the PTS as well.
The main requirements for the new system are as follows: All incoming problem reports are registered and stored in an company-wide problem data base. The activities of all involved groups of personnel have to be coordinated. The system performs consistency checks. The current state of a problem report can be retrieved at any time. Solutions of several problem reports can be composed to form new software configurations. The processes defined by the QMS are supported.
\
15
/ '
the configuration units to be released in the test environment and is responsible for shipping patches and releases.
I
belongs to
,
Every activity of the activity rnodels can be related to only one of these groups. The PTS presents only those activities to the individual users which are part of their tasks in accordance to their membership in one of the groups.
I
own,
Picture 1: PTS Object Model As shown in the entity-relationship diagram (compare picture 1) problem reports can be connected to one or more configuration units. Vice versa one configuration unit may be related to a group of problem reports, but it has to belong to one problem report at least. Configuration units are created when developers have to modify existing software components due to a problem report. Problem Reports can be grouped together to Patches as described by the n:m-relationship. Each patch must have at least one connection to a problem report. Since there is also a relationship between Problem Report and Configuration Unit, every patch can be traced back to its configuration units.
3.3 Activity models of the PTS The activity models of the business processes supported by the PTS describe how problem reports are handled. The concrete path a particular problem report takes depends on the problem report's attribute Stute. In relation to the current value of the attribute State only certain state transitions are allowed. Picture 2 sums up what the allowed state transitions look like. Exactly these transitions are supported by the activity models (compare picture 3 and 4). Basically two business processes are supported by the PTS: Acceptance and Maintenance. In addition, there is an email demoin process which translates incoming emails into problem reports.
3.2 Organizational model of the PTS There are five groups participating in the processes implemented by the PTS:
The Support represents the interface to the customer. Problem reports are received, from the customer and releases of patches are announced in return. In addition the defects are analyzed before they are handed over to the developers. Some problems can be eliminated on the customer's installations in advance. The Patchboard is consists of the project managers (PM) of the concerned development projects. They group the incoming problem reports into certain priority levels and - if necessary - hand them over to the support for analysis or to the developers for resolution. The quality assurance activities are carried out by the Quality Management (QM). These activities include tests and reviews of configuration units and of a new software release which may lead to new problem reports. The QM verifies that the defects have been removed and controls the release of patches. The Development Group builds new software versions and removes errors from versions already released. They also participate in quality assurance activities and analyze the requirements. It is the task of the Configuration Manager (CM) to define and to generate patches using the Configuration units created by the developers. Moreover he installs
Picture 2: State transition chiart for problem reports The activity model Acceptance (compare picture 3) describes the process of inspecting a new software system for acceptance. When the QM detects errors or unfulfilled requirements, a problem report is created and passed to the developers. After removing the error the problem report is handed to the QM again, which has to verify that the problem is removed. This (cycle may be repeated as often as necessary to achieve the acceptance of the product. The activity model Maintenance (compare picture 4) describes the process of discovering and resolving an error in an existing and already shipped software system. Customers as well as employeeis can announce a problem to the support group. Eventually the problem reports lead to Patches for the software system which have to be documented and distributed. The QM again tests the patches for acceptance.
'
user. This dialog activity enables the user to search for and to view every PR, that was created in this business process. The activity Edit PR may only be started by authorized users like the system administrator. The authorization system of LEU can be used Ito define roles and to bind these roles to certain users. The role RoleEditPR which contains the permission to start the activity Edit PR should only be assigned to some dedicated users. Only users having the role QM are allowed to execute the activities Create PR or Accept PR. The activity Handle PR only appears in the agendas of developers. Install PR is reserved for people with the CM role.
\
-
Picture 3: Activity Model 'Acceptance'
Activity models are described with FUNSOFT nets [6]. _ _ _ _ _ ~ They consist of agencies and channels. Agencies represent activities. Some activities are manual, they I I require human interaction. These activities are dialog activities. Other activities can be executed automatically, they are called batch activities, Channels represent information storage devices. They can contain objects (speaking in Petri net vocabulary: they are marked). Agencies are represented graphically by different rectangular symbols. The various types of symbols only serve for visualization and are free of semantic value. Channels are represented by circles. If there is an edge from a channel to an instance, it means, that the instance reads from this channel before it starts. An edge leading from an instance to a channel means, that the instance writes an object into the channel after terminating execution. FUNSOFT nets contain ways of modeling that allow a very dense description of activity models. E.g. there are several predefined firing behaviors. One of this is the either-or firing behavior, which gives us the possibility to describe agencies that write just in one of many output channels. The other modeling constructs of Picture 4: Activity Model 'Maintenance' FUNSOFT nets similarly serve for the intuitively \ accessible description of process models. Their sa"tiCS -Activi@ model ' Maintenance ' can be described by a mapping to Predicateflransaction The Maintenance process deals with extemal problem nets [13]. reports, which are mainly announced by the customer. The process of dealing with these problem reports results Activity model 'Acceptance' in the creation of patches. Only the ajctivity Inform This activity model contains six activities, four of which Customer is automatic. There are six cycles which allow can be repeated in a cycle. There is just one channel to repeat certain parts of the process. Depending on the typed with the object type PR between any two activities. state of the PR the activities Analyze PR, Handle PR and All activities are dialog activities. Thus, they have to be Establish PR PrioriQ can choose to return a token to the started by the user from his agenda and the a dialog preset channel. This enables us to execute them window is started at the user's workstation. In this repeatedly with one and the same document. The channel business process the QM always must be able to create a Analyze PR is a system channel. LEU uses system new problem report. Therefore the activity Create PR has channels to exchange data between business processes. In to be in the agenda all the time. Technically speaking, this this case the channel is needed in order to import problem is achieved by using a control channel in the preset and a reports which arrive via email directly into the copy edge leading from the control channel to the maintenance process. Thus, the system channel can be activity. The same technique is utilized to model the filled by the activity Create PR and by an automatic activities View PR and Edit PR, which have to be always activity in the email batch. in the agenda, too. The other agencies can only be started R
~
--
I
and they only appear in the agenda if there are problem report tokens in the channel of their preset. An OUT-edge connects the last activity Accept PR with the channel in the preset of the activity Handle PR. Thus,
an unsolved problem can be returned to the development group. The activity View PR may be carried out by every ________
. 17
\,.
created email contains the correct key words for the batch which reads the email. If the data found in the HTlML form is not sufficient, the email is not submitted and an error message is shown. Normally the email, is sent to the address which is read by the email batch process. This mechanism offers two new media for problem report input by using just one interface of the PTS.
4 WORKING WITH THE PTS The first level support receives problem reports by telephone call, facsimile or email. If the problem is new or unknown to the person responsible, he starts the activity Create PR from his agenda. The dialog mask for filling in a new PR (compare picture 7) appears and the fields for date and time as well as the current person responsible are already set. The system knows who is in charge from the name of the UNIX user who started the activity. Since this activity belongs to the maintenance process, the PR is already marked external, too. When the Create button is pressed, a new unique problem number is generated. Furthermore the name of the person currently in charge is appended to the history of the problem report together with the current dlate, time and state. Subsequently the problem report is inserted into the data base. There is no mechanism in the PTS to delete a PR from the data base. If the state attribute is set. to Archived, the problem report is removed frommthe process and cannot be edited anymore. The creation of the PR fails, if values for mandatory attributes like the problem description are missing. In this case th.e status h e displays an error message showing which iinformation is missing.
I The email process model automatically registers problem reports that arrive via email. It is started once and runs until the PTS is shut down. It reads the email file of one special UNIX user and scans the emails for predefined keywords like #DESCRIPTION.The batch generates a problem report from the data found in the email. The state attribute of the PR is set to In Analysis and the support group is set to be in charge of the PR. Then the problem report token is written into the system channel of the postset of the activity. The same system channel can be found in the preset of the activity Analyze PR in thc maintenance process. Thus, the incoming PR can be imported into the PTS directly. Since emails are received even when the PTS is off line, there is no danger of losing problem reports. This mechanism offers an ideal interface to customers or consultants, who are not able to lor! on to the PTS. Moreover an HTML interface is included. The HTML page shown in picture 5 is available internally and externally. It allows to insert all relevant attributes of problem reports. Based on this interface customers can create problem reports from their sites. The created problem reports are automatically forwarded to the PTS processes. Some attributes are accessible per selection box only, in order to minimize mistakes during conversion. When the Send button is pressed a CGI script generates an email from the data read from the form. The I
/
-
-
U
State-B ~
State-C ~~
~
-
Picture 6: Projection from FUNSOFT nets to STDs If somebody wants to forward a problem rieport, its state or the person responsible must be changed. The state attribute of a new PR has the value Created. The state can remain unchanged as long as there are still some attributes to be filled or necessary data to be acquired. Once the state is changed to In Analysis the problem report appears in the preset of the corresponding activity. If the name of the employee changes from the start of a dialog to its end, the new person responsible is informed by email. Thus, the recipient of the email can decide just by looking at the subject, which PR he has to work on and which activity he has to start. Additionally, the body of the email
/
contains the problem description, responsible and the priority.
its last person
If there is the possibility to write the PR in different postset channels, the state attribute decides which channel is actually chosen (compare picture 2 ) . State and name may only be changed in accordance with the consistency mechanisms of the PTS. E.g. in the activity Handle PR the state mustn't be changed to Created, In Analysis or to Archived.
still true that some problems are reported twice or even more. But now it is easier to determine that this is the case. This clearly shows that our decision concerning strict enactment of the PTS was right. These processes are not creative and self-organized but rather repetitive and simple. Thus, the strict enactment is the best way of enactment support. -
5 EXPERIENCE 5.1 Modeling the PTS While implementing the first process models of the new PTS, we realized that we needed some kind of state transition diagram (STD) for problem reports in order to get an overview of their behavior throughout the system. We also found a strong connection between the channels in the FUNSOFT nets and the possible states of the problem reports as shown in the STD (compare picture 2). Every channel should contain objects of one state only. As a consequence we analyzed how our process models could be described by a STD. Sequential and optional activities in FUNSOFT nets can be translated into state transition diagrams in a very straighforward way (compare picture 6).
This showed that the STD gave a very straightforward representation of the main characteristics of some parts of our process models. E.g. cycles can be seen very intuitively. Furthermore the development of the main object type and the direction of the process can be illustrated easily. Although we went very well with the prescriptive style of description as used in FUNSOFT nets, STD modeling shows advantages when dealing with certain kinds of processes, namely those processes which describe how objects of one type are created and manipulated. It is important to note, that the STD way of modeling tends to lose the process view onto the problem. Instead, a constraint-based perspective is supported. We believe that modeling with STDs is suitable for:
All in all 91 employees work with the PTS today. On the average one third of the possible users have an aclive agenda and again half of them are working actually on one activity. Currently between 20 and 30 problem reports are created every day. The registration of a new PR is remarkably easier with the new system than with the old paper form. This is the explanation why the number of new problem reports per day increased by 25% since the PTS has been introduced. Especiallly employees who don't announce problems regularly are now able to register problem reports easier during their normal work.
simple processes that are clearly structured, processes which focus on objects of one type (otherwise the STD method has to be extended for many-object-type processes). 5.2 Using the PTS Apparently one of the objectives of the PTS development has been achieved: once a problem report is in the system, it can be requested very fast and comfortably. Furthermore the various enumeration types of the PTS have proven very helpful: type writing errors, which make searching a very difficult task, do not occur anymore. The pathway of the PR through the process can be recalled anytime just by examining the history of its employee in charge, its date and its time. This offers possibilities for analyzing and improving the process. Also problem reports cannot get lost anymore. Formerly every ninth document vanished on the desks of the employees. It is /
6 THE IMPACT ON SOFTWARE PROCESS RESEARCH The application of software process technology to industrial software processes as described in this article and as partially also reported in other experiments may lead to a refocusing of software process research. In more detail, this means: Substantial parts of the software process are not understood well enough to describe them in a degree of detail which allows software process enactment. In order to achieve a better understanding, it is above all important to find modeling languages which lead 1
19
to an intuitive description. Those intuitive models should be refined step by step concerning the parts of the process that are well known and that demand for a low level description, in order to arrive at enactable models. Software process modeling languages and tools for process modeling and enactment must be thoroughly validated previous to their application. By dealing with toy problems many difficulties of software process modeling and enactment cannot be discovered. They arise only if a lot of related software processes are modeled, if different versions of process models have to be managed and if many people participate in software processes. Process enactment must provide different levels of rigour for different parts of software processes. Parts which mainly consist of creative work (e.g. the requirements analysis) need non-obstrusive support. Tools must be made available, but the developers should decide on their own how and when to call these tools. Other processes, like, for example, design processes may be appropriate for a higher level of enforcement. Designers should be told which conditions have to be fulfilled, before a process may be terminated, but they should be free in their way to fulfil these conditions. These kinds of processes have to be monitored. in order to find out what has happened and what could be improved for future processes. Other process parts, like configuration management and problem tracking and tracing have to be controlled very tightly. A strict and rigorous workflow approach is appropriate for them. Our experience clearly shows, that it is reasonable to have a mixture between models, which are defined in detail, and others, which only describe the frameworks for the process to happen. As mentioned above, processes which focus on the creation and manipulation of objects of one type can be illustrated by state transition diagrams. It may be useful to specify parts of processes in this way and thus, to specify constraints which should not be violated in process enactment. For other processes it has to be predefined in detail what has to happen and when. For processes of this type, a FLJNSOFT net description is appropriate. Thus, it may be useful to model some parts in a prescriptive style (e.g. with FUNSOFT nets) and to describe the frameworks of other processes ,with state transition diagrams, without specifying in detail when every state transition can occur.
REFERENCES Bandinelli, A. Fugetta, and S. Grigolli. Process Modelling In-the-Large with SLANG. In Proceedings of the 2"" International Conference on the Software Process - Continuous Software Process Improvement, pages 75-83, Berlin, Germany, February 1993. S. Bandinelli, E. Di Nitto, and A. Fuggetta. Supporting Cooperation in the SPADE-1 Environment. In Proceedings of the 2nd International
Conference on the Software Process - Continuous Software Process Improvement, pages 75-83, Berlin, Germany, February 1993. 3. S.C. Bandinelli, A.-Fuggetta, and C.-Ghezzi. Software Process Model .Evolution in the SPADE Environment. IEE Transactions on Sofnyare Engineering, 19(12): 1128-1 144, December 1993. 4. Bunje, G. Engels, L. Gronewegen, A. Matsinger, and M. Rijnbeek. Industrial maintenance modelled in SOCCA: an Experience Report. In Proceedings of the 4" International Conference on the Software Process - Improvement and Practice, ]Brighton, UK, December 1996. To appear at ICSP4.
5 . Conradi, C. Fernstrom, A. Fugetta. Concepts for Evolving Software Processes. In A. Finkelstein, J.. Kramer, and B. Nuseibeh, editors, Software pocess Technology - Proceedings of the 2nd European Software Process Modelin,g Workshop, pages 9-3 1, Somerset, England, 1994. Research Studies Press Ltd. 6. Deiters and V. Gruhn. Managing Software Process in MELMAC. In Proceedings of the Fourth ACM SIGSOFT Symposium on Sofbvarc Developmenr Environments, pages 193-205, Irvine. California, USA, December 1990. 7. W. Deiters and V. Gruhn. The IWNSOFI' Net Approach to Software Process Management. International Journal of Software Engineering and Knowledge Engineering, 4(:2):229-256, 1994. 8. Derniame and V. Gruhn. Development of ProcessCentered IPSEs in the ALF Project. Journal of Systems Integration, 4 (2): 127-150, 1994. 9. Dinkhoff, V. Gruhn, A. Saalmann, and M. Zielonka. Business Process Modelling in the Workflow Management Environment LEU. In P. Loucopoulos, editor, Proceedings of the 131h International Conference on the Entit]p-Relationship Approach, pages 46-63, Manchester, UK, December 1994. Springer. Appeared as Lecture Notes in Computer Science no. 88 1. 10. Emmerich, S. Bandinelli, and L. Lavazza. Finegrained process modeling: an experiment at British Airways. In Proceedings of the 4'* International Conference on the Software Process - Improvement and Practice, Brighton, UK, December 1996. IEEE Computer Society Press. 11.G. Engels and L. Groenewegen. SOCCA: Specifications of Coordiinated and Cooperative Activities. In A. Finkelstein, J. Kramer, and B. Nuseibeh, editors, Sofhyare Process Technology . Proceedings of the 2nd European Software Process Modeling Workshop, paiges 71-100, Somerset, England, 1994. Research Studies Press Ltd. 12.P. K. Garg and S. Bhansali. Process Programming by Hindsight. In Proceedings of the 14th International
Corlference on Software Engineering, Melbourne, Australia, May 1992. 13. H.J. Genrich. PredicateiTransition Nets. In W. Brauer, W. Reisig, and G. Rozenberg, editors, Petri Nets: Central Models and Their Properties, pages 208-247, Berlin, FRG, 1987. Springer. Appeared in Lecture Notes on Computer Science 254. 14. Ghezzi, editor. Proceedings of the YIh International Software Process Workshop, Airlie, VA, US, October 1994.. 15.V. Gruhn and S. Wolf. Software Process Improvement by Business Process Orientation. Software Process Improvement and Practice, 1:49-56, August 1995. Pilot Issue. 16.Junkermann, B. Peuschel, W. Schafer, and S. Wolf. MERLIN: Supporting Cooperation in Software a Knowledge-Based Development Through Environment. In B. Nuseibeh, A. Finkelstein, J. Kramer, editor, Software Process Modelling and Technology, pages 103- 129, Somerset, England, 1994. John Wiley and Sons. 17.R. Kadia. Issues Encounters in Building a Flexible Software Development Environment In H. Weber, editor, Proceedings of the 5Ih ACM SIGSOFT Symposium on Software Development Environments, Tyson's Corner, Virginia, USA, December 1992. ACM Press. 18.G.E. Kaiser, S.S. Popovich, and I.Z. Ben-Shaul. A BiLevel Language for Software Process Modeling. In Proceedings of the 15th International Conference on Software Engineering, Baltimore, Maryland, US, May 1993. 19. Konrad, M.B. Chrissis, J. Ferguson, S. Garcia, B. Hefley, D. Kitson, and M. Paulk. Capability Maturity Modeling at the SEI. Software Process Improvement and Practice, 2 (1):21-34, March 1996. 20. M. Lehmann. Process Models, Process Programs, Programming Support - Invited Response To A Keynote Address By Lee Osterweil. In Proceedings of the Yfh International Conference on Sofhyare Engineering, pages 14- 16, Monterey, California, 19987 21. M.M. Lehman and L.& Belady. Program evolution: processes of software change. Academic Press, 1985. 22. C. Montangero, editor. Software Process Technology - Proceedings of the 5"' European Workshop on Software Process Modelling, Nancy, France, October 1996. Springer. Appeared as Lecture Notes in Computer Science 1149. 23.C. Montangero and V. Ambriola. OIKOS: Constructing Process-Centred SDEs. In B. Nuseibeh A. Finkelstein, J. Kramer, editor, Software Process Modelling and Technology, pages 131- 15 1, Somerset.
England, 1994. John Wiley and Sons. 24. O'Conner, editor. Proceedings of the Znd International Conference on the Software Process - Continuous Software Process Improvement, Berlin, Germany, February 1993. 25. L. Osterweil. Software Processes are Software Too. In Proceedings of the 9"' International Conference on Software Engineering, pages 2- 13, Monterey, California, 1987. 26.M. Suzuki and T. Katayama. Meta-Operatlons in the Process Model HFSP for the Dynamics and Flexibility of Software Processes. In A. Fugetta, K. Conradi, and V. Ambriola, editors, Proceedings of the European Software Process Modeling Workshop, Milan, Italy, May 1991. AICA Press. 27. Yourdon. Current Issues in Software Development. American Programmer, 9 (IO): 2-7, October 1996.
