software process technology, workflow management, FUNSOFT nets, problem tracking

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 non-language 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 L. 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 feedbacks and thereby process model modifications. Another trend 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 activties.

Concurrent to these shifts in software process research, many research groups worldwide have been building prototypes of toolsets supporting software process modeling, software process model analysis and software process enactment. Examples of these environments are ALF [8], Arcadia [17], Marvel and its successor Oz [18], MELMAC [6], HFSP [26] and SPADE [2].

Summing this up, much effort has been spent on software process research and there is some progress. Despite this multitude of prototypes and research groups, the software 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 software process enaction relates to small and somewhat isolated software process experiments, but not to the real-world of industrial software development [10, 15].

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 technolgy 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, 10].

After building a prototype (the MELMAC system mentioned above) we felt that we knew enough about software processes to improve the real-world. 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 a company. There was little doubt that real real-world software processes would urgently demand for formal process modeling and process enactment.

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 80ies (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 developers, customers and sales people, from systematic test approaches and from 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 workflow-engine-understandable, 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-compile-test cycles could be expressed and had a formal semantics definition.

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 [19]. Thus, they were unclear for important parts, interactions between process participants were not explicitly defined. In other words: there was hardly a process idea.

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 process modeling at that time.

Once we recognized that there was little benefit in software process modeling and enactment, we had the opportunity to investigate business process 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 from the area of housing construction and administration (contract management, accounting, real estate management, repairs, etc.). It was decided to develop 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 prototype before), by extended entity-relationship diagrams and by organizational diagrams showing who is responsible for what. The experience in the WIS development is described in [15] in more detail. Since MELMAC suffered from being a prototype, but not a product, a reimplementation was done first. The result, called LEU, is a toolset for process modeling, process model analysis and workflow management [9].

In the meantime, the WIS 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 workflow-manage their everyday administration processes.

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 what is described in [27]. Here it is described that software developers first tend to automate the problem tracking process. Since the deviation to business processes and back to certain parts of software processes eventually means, that software process technology is applied to (parts of) software processes, we describe the support for the problem tracking process in more detail in the following.

The implementation and maintenance of the software system WIS must be supported by appropriate software. Most important are a Helpdesk system and a large error data base. Above all the systems main objectives are support and enactment of the processes problem tracking, software configuration management and requirements management. These processes are strongly cooperative and show an extreme repetitiveness. Furthermore all internal business processes (BP) have been examined and described due to the introduction of a quality management system (QMS) for attaining ISO-9000 certification. Therefore they are well defined and documented thoroughly. As a consequence we decided to develop a business process based Problem Tracking System (PTS) using the available LEU environment.

The main requirements for the new system are as follows:

• All incoming problem messages 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 and editor of a problem report can be inquired at any time.
• Problem solutions can be put together to new software configurations.
• The procedures described by the QMS are supported.
• Customers and consultants can log on to the system via Internet or Intranet.

By introducing the new software-based and business-process-oriented problem tracking system we intend to make the life cycle of the problem reports visible and understandable. Information on the problem reports currently processed must be available for everyone at any time. This would make it easy to decide whether a problem has already been registered or even been solved lately. Inquiries of customers concerning the state of the problem solving process and concerning the duration could be answered faster. The effort for registering an error shall be essentially decreased and the process made much less error-prone. The latter will be achieved by consistency checking functions, that are located in the dialogs and prevent bad data 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 context of LEU a project consists of object model, organization model and workflow model. These parts of the PTS are described in the following.

LEU uses an extended entity-relationship-representation for its object model. The main object types of the PTS are Problem Report (PR), Configuration Unit (CU) and Patch. They are connected by n:m-relations (compare picture 1).

Incoming problem messages are stored in instances (objects) of the object type Problem Report. The boolean attribute Internal differentiates between:

• internal Problem Reports that are created by the quality assurance during the acceptance phase and
• external Problem Reports which are announced by customers to the support and which refer to releases already in production (maintenance phase)

Every single problem report is identified by one unique key, which is stored in the attribute Problem Number. The contents of the problem message 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 State 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 messages are rather new requirements than errors. This can be documented by setting the Boolean attribute Request to 'True'. Thus, requirements can be managed by the PTS as well.

As shown in the entity-relationship-diagram 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 come into being as during the work on a problem report the developers have to make changes to the existing software system. 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.

There are five groups participating in the processes connected with the PTS:

• The Support represents the interface to the customer. Problem messages 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 made up by the project managers (PM) of the concerned development projects. They group the incoming error messages into certain priority levels and if necessary hand them over to the support for analysis or to the developers for resolution.
• The quality assurance measures are carried out by the Quality Management (QM). This measures include tests and reviews 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 works on the new software systems and removes errors in the versions already released. They also participate in quality assurance measures 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 the configuration units to be released in the test environment and is responsible for shipping patches and releases.

Every activity of the business process models can be related to only one of these groups. The PTS presents only those actions to the individual users which are part of their tasks in accordance to their membership in one of the groups.

The business process model governs the possible pathways of a problem report through the work flow. Which path is actually chosen depends on the problem report's attribute State. In relation to the current value of the attribute State only certain changes are allowed (compare picture 2). Basically two business processes are supported by the PTS: Acceptance and Maintenance. In addition, there is an email demon process which translates incoming emails into problem reports.

The process model Acceptance (compare picture 3) describes the process of inspecting a new software system for acceptance. When the QM finds errors or deviations from the requirements description, this results in an problem report that is passed to the developers. After removing the error the problem report is handed to the QM again, which have to verify the correctness. This cycle may be repeated as often as necessary to achieve the acceptance of the product.

The process 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 employees 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.

Business process models are described with FUNSOFT nets [6]. They consist of instances and channels. Channels represent activities. Some activities are manual, they 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). Instances are shown graphically by using 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 process 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 instances that write just in one of many output channels. The other modeling constructs of FUNSOFT nets similarly serve for the intuitively accessible description of process models. Their semantics can be described by a mapping to Predicate/Transaction nets [13].

This process model contains six activities four of which can be repeated in a cycle. There is just one channel with problem report type between any two activities. All activities are dialog activities, which means they have to be started by the user from his agenda and open a dialog window when started. In this business process the QM always must be able to create a new problem report. Therefore the activity Create PR has to be in the agenda all the time. Technically speaking, this is achieved by using a control channel in the preset and a copy edge leading from the control channel to the activity. The same technique is utilized to model the activities View PR and Edit PR, which have to be always in the agenda, too. The other instances can only be started 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 (or a PR with an error in the solution) can be directed back to the development group. The activity View PR may be carried out by every user. This dialog activity enables the user to search for and to view every PR, that was created in this business process, in read only mode. The activity Edit PR may only be started by special users like the system administrator. The authorization system of LEU can be used to 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 QS 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.

The Maintenance process deals with external problem reports, which are mainly announced by the customer. The process of treating these problem reports results in the creation of patches. Only the activity Inform Customer is automatic. There are six cycles which make it possible to repeat certain parts of the process as often as needed. Depending on the state of the PR the activities Analyze PR, Handle PR and Establish PR Priority can choose to write back a token back into the preset channel. This enables us to execute them repeatedly with one and the same document. The channel Analyze PR is a system channel. LEU uses system channels to exchange data between business processes. In this case the channel is needed in order to import problem reports which arrive via email directly into the maintenance process. Thus, the system channel can as well be filled by the activity Create PR and by an automatic activity in the email batch.

Moreover an HTML interface is included. The HTML page shown in picture 5 is available internally and externally. It offers an input form for all relevant attributes, that are necessary to create a new PR. 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 created email contains the correct key words for the batch which reads the email. If the data found in the HTML 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.

The first level support receives problem messages 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 date, time and state. Subsequently the problem report is inserted into the data base. There is no possible 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 from the process and cannot be edited anymore. The creation of the PR fails, if values for mandatory fields like the problem description are missing. In this case the status line displays an error message showing which information is missing.

If you want to pass a problem report on, 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 fields 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, its last person responsible and the priority.

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.

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 (compare picture 6).

This showed that the STD gave a very straight forward 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 in favor of an constraint-based specification. We believe that modeling with STDs is suitable for:

• 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).

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, don't 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 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.

All in all 91 employees work with the PTS to date. On the average one third of the possible users have an active 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. Especially employees who don't announce problems regularly are now able to register problem reports easier during their normal work.

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 allow software process enactment. In order to achieve a better understanding, it is above all important to find modeling languages which lead 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 need a low deal of detail, in order to get to models which can be enacted.
• 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 processses 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 FUNSOFT 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.

1. Bandinelli, A. Fugetta, and S. Grigolli. Process Modelling In-the-Large with SLANG. In Proceedings of the 2^nd International Conference on the Software Process - Continuous Software Process Improvement, pages 75-83, Berlin, Germany, February 1993.
2. 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 Software Engineering, 19(12):1128-1144, 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^th International Conference on the Software Process - Improvement and Practice, Brighton, UK, December 1996. To appear at ICSP4.
5. Conradi, C. Fernström, 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 Modeling Workshop, pages 9-31, 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 Software Development Environments, pages 193-205, Irvine, California, USA, December 1990.
7. W. Deiters and V. Gruhn. The FUNSOFT 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 Process-Centered 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 Modeling in the Workflow Management Environment LEU. In P. Loucopoulos, editor, Proceedings of the 13^th International Conference on the Entity-Relationship Approach, pages 46-63, Manchester, UK, December 1994. Springer. Appeared as Lecture Notes in Computer Science no. 881.
10. Emmerich, S. Bandinelli, and L. Lavazza. Fine-grained process modeling: an experiment at British Airways. In Proceedings of the 4^th 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 Coordinated and Cooperative Activities. In A. Finkelstein, J. Kramer, and B. Nuseibeh, editors, Software Process Technology - Proceedings of the 2nd European Software Process Modeling Workshop, pages 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 Conference on Software Engineering, Melbourne, Australia, May 1992.
13. H.J. Genrich. Predicate/Transition 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 9^th 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. Schäfer, and S. Wolf. MERLIN: Supporting Cooperation in Software Development Through a Knowledge-Based 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 5^th 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 Bi-Level 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 9^th International Conference on Software Engineering, pages 14-16, Monterey, California, 19987
21. M.M. Lehman and L.A. Belady. Program evolution: processes of software change. Academic Press, 1985.
22. C. Montangero, editor. Software Process Technology - Proceedings of the 5^th 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-151, Somerset, England, 1994. John Wiley and Sons.
24. O’Conner, editor. Proceedings of the 2^nd 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^th International Conference on Software Engineering, pages 2-13, Monterey, California, 1987.
26. M. Suzuki and T. Katayama. Meta-Operations in the Process Model HFSP for the Dynamics and Flexibility of Software Processes. In A. Fugetta, R. 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 (10): 2-7, October 1996.