A Systematic, View-based Approach to. Eliciting Process Models. has shown, time and again, that such models require process information

Transcription

1 A Systematic, View-based Approach to Eliciting Process Models Josee Turgeon and Nazim H. Madhavji School of Computer Science, McGill University 3480 University Street, Montreal, Quebec, Canada H3A 2A7 Abstract. Building a high quality descriptive process model of a software process is recognized to be important for a number of reasons, such as certication, assessment, improvement and tool insertion. Experience has shown, time and again, that such models require process information to be elicited from multiple sources. However, a problem noted with multiple sources is that, amongst other things, process information can be inconsistent in various ways. In this position paper, we describe some mechanisms for resolving this problem. In particular, the mechanisms help in: (i) drawing out information pertaining to a specic role in the process, yielding a process view; (ii) ensuring consistency within a given view; (iii) merging various views; and (iv) ensuring global coherence of the elicited process model. These mechanisms are an integral part of V-elicit, a prototype system for eliciting process models. 1 Introduction In order to improve a software process, one should have visibility into that process. Having a quality descriptive model of that process helps provide this visibility. Several eorts have been made on modelling software processes in industry, for example, Frailey's work at Texas Instruments on building a corporate-wide model [7], Carr et. al.'s work at AT&T on process interfaces [3], and Drew's work at Paramax on process denition [5]. The main thrust of the industry-oriented work has been to produce process models so as to meet their business needs. Emphasis on building rigorous techniques for elicitation, understandably, has been of a low priority. Thus, one can categorize these elicitation approaches to building process models as generally informal. Several researchers have also attempted to elicit realistic process models, for example, Kellner [8], Rombach [11], Barghouti [2], Scacchi & Mi [12], and Bandinelli et.al. [1]. While these researchers have used more rigorous approaches, using specic notations and tools to represent process models, the general paradigm for elicitation is that of iterating until the elicited model is satisfactory. The base criteria for completeness is often ensuring that the various process attributes (such as inputs, outputs, resources, entry/exit criteria, etc.) are lled with appropriate values from the process being modelled.

2 A slightly more systematic approach is the Elicit approach [10], where there is an elicitation method supported by entity-oriented (or domain-free) views into a process, such as activity view, artifact view, resource view, etc. While this approach has been used to model realistic processes in several organizations, it too suers from the fact that the entity-oriented views are rather statically dened, without consideration of the roles of the people in a project. Thus, an identied weakness in the Elicit approach is the lack of computational support for role-based (or domain-specic) view analysis, and merging of such views, in order to build a coherent model. Currently, such merging is carried out manually in Elicit, rendering it error-prone and time consuming. Extending the Elicit work, and considering the emerging concern for supporting role-driven views in process modelling (Dieter [4], Rombach [11], Finkelstein et.al. [6], Sommerville et.al. [13], and Verlage [14]), our position is that there is a need for a systematic approach that deals with role-driven views during the elicitation process. Specically, our stand is that, in addition to a system (such as Elicit) to \draw out" process information, we need: (i) mechanisms for drawing out such information pertaining to specic roles in the process; (ii) mechanisms to ensure intra-view consistency; (iii) mechanisms to merge various views; and (iv) mechanisms to ensure global coherence of the elicited process model. The rationale behind this stand is that, collectively, these mechanisms would help systematize the elicitation approach. In turn, this would help in building comprehensive models of high quality. The elicitation process should then be less error-prone because it would rely less on people when dealing with tedious technical details of a process model. 2 Proposed Mechanisms We have implemented a prototype for view-based elicitation of process models, called V-elicit. Below, we discuss the key features of V-elicit pertaining to views (e.g., domain-specic elicitation, detection of inconsistencies, detection of overlap amongst elicited views, and conict resolution). Due to the lack of space in this position paper, we do not give demonstrations of system operations; this would be the subject of a more detailed paper. The key features are that: 1. It can elicit domain-specic process information that is dened by (i) the role of an agent in the process and (ii) the aspects of interest associated with the role. Example roles are requirement engineer, designer, coder, inspector, project manager, etc. Example aspects are data-ow, control-ow, task decomposition, costs associated with activities, duration, responsibilities, etc. It is the set of aspects that an agent is involved with in performing his or her task that make up a view. The V-elicit system, (after identifying the desired process components and views for elicitation using the Elicit method [10]) drives the X-elicit tool (an advanced version of the older Elicit tool [10]) to obtain pertinent process information related to the desired view. Each view is stored separately, using the same underlying schema as an entire model.

3 2. It can detect inconsistencies within a given view. For example, if two activities are not linked together in the elicited control ow aspect, but that the output of one activity is identied as input to the other, then this is agged as inconsistent. The mechanism used for consistency analysis is constraint verication. Constraints are logical expressions written in extended rst-order logic. In our example, the constraint would be 8r(A; D; activity produces artifact) 2 R 8r2(D; B; artifact is-consumed-by activity) 2 R ThereIsPath(A; B; activity precedes activity) which means that for each pair of activities (A and B) related via an artifact (D) through produce/consume relationships, there should be a path of precedence relationship between the two activities. The V-elicit system can read such a constraint, and evaluate it on a given view. The result of such an analysis is the set of elements (entity or relationship) in the \for all" clause that did not satisfy the constraint. The elicitor, or agent, can enter new constraints related to the software development domain in which the elicitation is performed, or select from the ones already entered. Depending on the type of information an agent would provide (or the elicitor would obtain from process documents), the set of constraints used would dier. Such constraints can also vary from one process to another, depending on the specics of the projects concerned. 3. It can detect overlap between two elicited views of the same process. This is determined by checking whether there are the same process components in both the views. For example, if two views of the same requirement engineering process contain a review activity, then the V-elicit system will be able to detect that these two review activities are in fact one and the same, even if the detailed descriptions of them are slightly dierent, or the terminology used is dierent (as described below). Any two same activities are said to be \matched" together, and thus they will form only one activity in the nal (merged) model. This component matching is achieved by computing similarity scores ([0..1]) between entities (such as activity, artifacts, roles, etc.), using not only names, but also attributes of these (e.g., cost, timing, and eort), and relationships with other entities (e.g., artifact produced by an activity). This score is computed between an entity in one view, and all entities in the second view. The goal is to nd the entity in the second view with the highest similarity score with the given entity in the rst view. For example, two activities producing the same output are \more similar" than two activities producing dierent outputs, but \less similar" than two activities performed by the same agents and are producing the same output. If an entity A in the rst view has its highest similarity score with entity B in the second view, and vice versa, than these two entities are considered the same, and they are thus matched together. Of course, if the similarity score between the two entities

4 is low, then the match is rejected. This lower bound on similarity score is given by the elicitor or the agent. The component matching technique in V-elicit is derived from Leite and Freeman's work on merging requirements elicited from dierent people [9]. 4. It has been designed to detect inconsistencies between two dierent views of the same process or adjacent processes. For example, if two activities are in fact the same, but they do not have same name; or the inputs or outputs do not match in the two descriptions of the same activity; or if two same high level activities do not contain the same set of sub-activities; then such cases are agged as inconsistent. Inconsistencies are categorized into four types in V-elicit: (i) those related to the decomposition of entities such as dierent grouping of entities; (ii) those related to the name of common entities; (iii) those related to the relationships between process entities such as missing input/output in one or more views; and (iv) those related to the attributes (e.g., cost) of the common entities. Each of these types of inconsistencies will then be further decomposed into basic inconsistency types, which will be characterized by a set of boolean characteristics such as \the current element is matched", \the current element has descendants which are matched", \the current element is a leaf", etc. These boolean characteristics help in identifying the basic types of inconsistencies concerning one entity at a time in one view, in conjunction with another view. They can also describe situations where there is no inconsistency. The detection of inconsistencies is achieved by examining each pair of matched entities in the two views, and by examining their characteristics to nd out whether they have inconsistencies, and if so, of which type. This includes also determining if one description is more detailed than the other. This situation often occurs in descriptions of adjacent processes. In this case, we assume that there is at least one common (matched) entity in the two views, the ones that make up the interface (communication) between the processes. If these interface entities are missing, the merged model will not be all connected. This can be detected by checking the merged model for inconsistencies using the same technique (constraints) as that used for intraview checking. 5. It has been designed to help resolve inconsistencies detected between two views. Detection of inconsistencies is achieved on two views at a time, but resolution of these uses the information given in all other related views. For example, the system might detect that an output of one activity is missing, but by examining other related descriptions, we can determine whether or not to include the new output. By categorizing the inconsistencies while detecting them, the system will help focus on one basic inconsistency at a time, and thereby avoid the diculty of having to resolve complex inconsistencies (mixture of basic inconsistencies) in one attempt. Complex inconsistencies can be unbounded

5 because the inconsistencies related to the same process entity can be of different types in dierent pairs of views, and involving dierent other entities. These other entities can in turn be involved in other basic inconsistencies, that are included in the same complex inconsistency, making it dicult to resolve because many entities are involved. Thus, when focussing on one basic inconsistency at a time, the system would focus on just a subset of the process information necessary for resolving the inconsistency, presented in a way that would facilitate the elicitor in making an appropriate choice of solution. For example, the system can group views according to the inconsistency issue being examined and provide statistical information. The type of an inconsistency determines the subset of process information to examine in each view in order to resolve the inconsistency. The V-elicit tool has also been designed to resolve some inconsistencies automatically, based on the criteria selected by the elicitor or agent. The kind of inconsistencies resolved in this way are the ones where the solution is obvious for the elicitor. For example, the agent or elicitor could specify that if one solution was given by more than 70% of the views, than this solution would be the one chosen. Another criteria could be that the agent involved directly with the process element under contention would know better than other agents what the actual process is, and so his/her solution should have priority. Of course, these decisions should be recorded for later analysis. Such criteria can be dierent for each inconsistency type. In the case where the tool cannot resolve an inconsistency, then the elicitor has to specify his/her own solution. The tool is then responsible for modifying all views according to the selected solution, such that the next decisions would use the previous resolutions. For example, if we decide to eliminate one process entity, then all other inconsistencies related to this entity would be eliminated with it. The tool can in fact work on a copy of the views, in order to keep the initial views for later analysis, or for returning to the previous decisions. The described features, however, are not sucient for elicitation; they should be used in a systematic way, as part of the elicitation process. 3 Coordinating the Mechanisms The systematic approach to elicitation implies that the information pertaining to the desired views is rst elicited using X-elicit and V-elicit systems. Note that the X-elicit and V-elicit systems can be used by concurrent elicitors to elicit views in parallel from multiple sources. Following this, intra- and then interview analysis is performed in V-elicit. Inconsistencies are identied and resolved incrementally; this may require human intervention, as described earlier. As the inconsistencies are resolved, a merged process model is built in tandem in the V-elicit system. A nal analysis, similar to intra-view analysis, is then performed to check that the entire process model is consistent.

6 4 Summary Re-examining the problem of eliciting process models, what we want from V-elicit is to help us manage the tedious details and inconsistencies amongst various views. Human beings are good at making \intelligent" and \knowledge-based" decisions; whereas the system is good at making \technical analysis", in volume and rapidly. Thus, together, the human and machine can perform high quality elicitation upon which other business decisions can be based, such as process improvement, assessment, certication, and automation. This is thus considered as a denite step forward from the currently used approaches to the elicitation of process models. The V-elicit system is a research prototype of approximately 50K lines of C++ code, undergoing enhancements, detailed clean up, and tests. We are carrying out in-house trials of the system on signicant, but small, processes at this stage of our work. The vehicles used for this include undergraduate and graduate courses in software engineering at McGill. Subsequently, we intend to use V-elicit in industrial-scale projects. This, incremental and increasingly sophisticated, validation is in line with the approach taken with other process tools that we are developing. References 1. Sergio Bandinelli, Alfonso Fuggetta, Luigi Lavazza, Maurizio Loi, Gian Pietro Picco, \Modeling and Improving an Industrial Software Process", IEEE Trans. on Software Engineering, vol. 21, no. 5, May 1995, pp. 440{ N.S. Barghouti, D.S. Rosenblum, D.G. Belanger, C. Alliegro, \Two Case Studies in Modeling Real, Corporate Processes", Software Process: Improvement and Practice, Wiley/Gauthier-Villars, Pilot Issue, vol. 1, August 1995, pp. 17{ David C. Carr, Ashok Dandekar, Dewayne E. Perry, \Experiments in Process Interface Descriptions, Visualizations and Analyses", Fourth European Workshop on Software Process Technology, 1995, pp. 119{ Wolfgang Deiters, \A View Based Software Process Modeling Language", Ph.D. Thesis, December Daniel W. Drew, \Developing Formal Software Process Denitions", Conference on Software Maintenance, 1993, pp. 12{ A. Finkelstein, J. Kramer, B. Nuseibeh, I. Finkelstein, M. Goedicke, \Viewpoints: A Framework for Integrating Multiple Perspectives in System Development", Int. Journal of Software Engineering and Knowledge Engineering, vol.2 no.1, 1992, pp. 31{ Dennis J. Frailey, \Dening a Corporate-wide Software Process", First Int. Conf. on Software Process, 1991, pp. 113{ Mark I. Kellner, \Software Process Modeling: Value and Experience", Technical Review, Software Engineering Institute, Carnegie Mellon University, 1989, pp. 23{ J. C. Leite, P. A. Freeman, \Requirements Validation Through Viewpoint Resolution", IEEE Trans. on Software Engineering, vol.17 no.12, December 1991, pp. 1253{1269.

7 10. Nazim H. Madhavji, Dirk Holtje, WonKook Hong, Tilmann Bruckhaus, \Elicit: A Method for Eliciting Process Models", Proc. of third Int. Conf. on the Software Process, October 1994, pp. 111{ Dieter Rombach, \Practical Use of Formal Process Models: First Experiences", Proc. of eight Int. Software Process Workshop, Dagstuhl, Germany, March 1993, pp. 132{ Walt Scacchi, Peiwei Mi, \Experiences in the Modeling, Analysis, and Simulation of Formalized Software Processes", Proc. of eight Int. Software Process Workshop, Dagstuhl, Germany, March 1993, pp. 135{ I. Sommerville, G. Kotonya, S. Viller, P. Sawyer, \Process Viewpoints", Fourth European Workshop on Software Process Technology, 1995, pp.2{ Martin Verlage, \Multi-View Modeling of Software Processes", Third European Workshop on Software Process Technology, 1994, pp.123{127. This article was processed using the LaT E X macro package with LLNCS style