Towards Method Component Contextualization

(1)

Towards Method Component Contextualization

Elena Kornyshova, Rebecca Deneckere, Bruno Claudepierre

To cite this version:

Elena Kornyshova, Rebecca Deneckere, Bruno Claudepierre. Towards Method Component Contextualization. International Journal of Information System Modeling and Design, IGI Global, 2011, 2 (4), pp.49-81. <10.4018/jismd.2011100103>. <hal-00662127>

HAL Id: hal-00662127

https://hal-paris1.archives-ouvertes.fr/hal-00662127

Submitted on 24 May 2012

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche fran¸cais ou étrangers, des laboratoires publics ou privés.

(2)

Towards Method Component

Contextualization

Elena Kornyshova, Rébecca Deneckère, Bruno Claudepierre Centre de Recherche en Informatique,

Université Paris I – Panthéon Sorbonne, Paris, France

ABSTRACT

Method Engineering (ME) is a discipline which aims to bring effective solutions to the construction, improvement and modification of the methods used to develop Information Systems (IS). Situational Method Engineering (SME) promotes the idea of retrieving, adapting and tailoring components, rather than complete methodologies, to the specific context. Existing SME approaches use the notion of context for characterizing situations of IS development projects and for guiding the method components selection from a repository. However, in the reviewed literature, there is no proposed approach to specify the specific context of method components. This paper provides a detailed vision of context and a process for contextualizing methods in the IS domain. Our proposal is illustrated with three case studies: scenario

conceptualization, project portfolio management and decision-making. Keywords: Method engineering; Method component; Contextualization.

1. INTRODUCTION

An IS development methodology (ISDM) is a set of ideas, approaches, techniques and tools which system analysts use to help them transforming organizational needs into an appropriate Information System. The application areas of these methodologies are various. Because of this diversity, it is now apparent that a universal method that could be applied to deal with any IS development project does not exist. Method engineering (ME) represents the effort to improve the usefulness of ISDM by creating an adaptation framework whereby methods are created to match specific organizational situations. ME aims to find solutions to the construction,

improvement and modification of the methods used to develop information systems. One of the ME fundamentals for optimizing, reusing, and ensuring flexibility and adaptability of these methods is their decomposition into modular parts (Harmsen, Brinkkemper & Han Oei 1994) (Rolland 2005). This purpose is the object of Situational Method Engineering (SME) which promotes the idea of retrieving, adapting and tailoring components, rather than complete methodologies, to the specific context.

Existing SME approaches consider the notion of context in order to guide the selection of a method component from a repository according to a given situation. They also deal with different kinds of context factors characterizing situations of IS development projects and offer various methodologies for using context. For instance, the method component context is studied in different approaches and is represented as: reuse frame (Mirbel 2008); interface (Ralyté & Rolland 2001b); method service context (Guzélian & Cauvet 2007); contingency factors (Van Slooten & Hodes 1996), (Harmsen 1997); development situation (Karlsson & Agerfalk 2004).

(3)

These approaches foresee different context elements which are the characteristics of method components.

However, the reviewed literature shows that, firstly, there is no approach considering all of the possible characteristics and, secondly, these approaches do not suggest a methodology allowing to define a set of concrete context characteristics for a given method.

In our view, the context is a set of characteristics which describes situations of a method application. The context is defined for an IS development method and its components. Each method component is then described by concrete values of these characteristics. In this paper, we focus on the contextualization of method components. Our goal is to propose (i) a generic model of context based on the state-of-the-art and (ii) an IS development methods contextualization process. We introduce the frame of contextualization, we present the context model, the context typology and the process to construct the context characteristics set for a given method. We illustrate our proposal with three case studies: scenario conceptualization, project portfolio management and decision-making.

All processes in this work are formalized with the MAP model which is commonly used in the ME field (Rolland, Prakah & Benjamen 1999). In our proposal, this formalism is used to represent the contextualization process in an intentional way. In the case studies, it is used to represent the organization of the method components (the links between them).

The paper is organized as follows. The notion of method component is described in the second section. Third section surveys a state-of-the-art on the notion of context. The fourth section proposes a context model and a process for the contextualization of method components. We illustrate our proposal with examples in the fifth section. Related works are given in the sixth section. A conclusion and future works are given in the last section.

2. CONTEXT AND ITS APPLICATION IN METHOD ENGINEERING

2.1. Cross domains application of Context-awareness

(Bouquet, Ghidini, Giunchiglia & Blanzieri 2003) states that the study of context was started in the 70’s. Since then, many different domains in relation with information systems use the notion of context and give various interpretations of it. For instance, (Dey, Abowd & Salber 2001) defines the notion of context by the information that could be used for characterizing the

situation of an entity (person, object or computer), and, more generally, by any element that can influence the IS behavior. (Rey & Coutaz 2002) foresees the context from four points of view:

• The context must be defined in terms of an object. It means that “there is no context without context”.

• The capture of context is not the goal in itself but the captured data must serve a purpose.

• The context is an information space shared by multiple actors (users and systems). • The context is infinite and varies with the passing of time.

Context models are multidisciplinary and have been proposed in several areas (Bradley & Dunlop 2005). The linguistic research is concerned with analyzing the usage context of signs (or words) within a language. Bunt (Bunt 1997) defines five types of context for communication aspects which are respectively:

• Linguistic: refers to linguistic material;

(4)

• Physical: refers to the environment description in which action or interaction occurs; • Social: refers to the interactive situation which occurs between actors;

• Cognitive: refers to the participants’ intentions, their evolution relating to perception, production, evaluation and execution.

Context is also formalized using mathematical models. For instance, (Coutaz & Rey 2002) proposes a cumulative model where the context (Ctx) is a timely aggregation of situations. A situation is a state descriptor for a user (U) performing a task (T) at a specific time (t). The model is depicted by the following formula:

Related to the Information technologies field, the context is represented as a model or an ontology. For instance, (Gu, Wang, Pung & Zhang, 2004) suggests a more detailed vision of context. It describes a formal context model based on ontology for intelligent environments. This context ontology defines a vocabulary for representing knowledge about context in this field. It includes two levels: upper ontology (capturing general context knowledge) and domain-specific ontologies (detailing basic concepts in application to a given domain). (Gu, Wang, Pung & Zhang, 2004) also specifies a way for modeling context classification, dependency between context elements, and quality of context.

In the field of Knowledge Representation and Reasoning (KRR), which is an area of Artificial Intelligence, two types of the context theory have been proposed: (i) divide-and-conquer, which sees context as a way of partitioning a global model of the world into smaller and simpler pieces and (ii) compose-and-conquer, which sees context as a local theory of the world in a network of relations with other local theories (Bouquet, Ghidini, Giunchiglia & Blanzieri 2003).

Another term, closely related to the context one, is context-awareness. Context awareness is a term originating from pervasive computing, or ubiquitous computing (Schilit, Adams & Want 1994). These systems deal with linking changes in the environment with computer systems, which are otherwise static. Although it is a computer science term, it has also been applied to business theory in relation to business process management issues (Rosemann & Recker 2006).

There are numerous context-awareness applications when human interactions occur. More related to our study, context models are also proposed for business process reengineering (Bessai, Claudepierre, Saidani & Nurcan 2008), computer science (Bradley & Dunlop 2005), service selection (Kirsch Pinheiro, Vanrompay & Berbers 2008) and decision-making within a military situation (Rosen, Fiore, Salas, Letsky & Warner 2008), (Drury & Scott 2008). In latter cases, the context model is seen as a way to analyze a given situation to guide the way of

processing. Thus, context models are mainly used to solve the problem of lacking flexibility and adaptability within processes.

2.2. Method Engineering and Method Components

Method Engineering is a discipline which aims to bring effective solutions to the construction, improvement and modification of the methods used to develop information and software systems. Several authors tried to design methods that would be as effective and as adapted as possible to the development needs of information systems (Firesmith & Henderson-Sellers 2001) (Rolland & Cauvet 1992). This goal was not always reached, especially because the methods were not always well adapted to projects specificities. The situational methods were designed to correct this weakness. The situational approach finds its justification in the practical field

(5)

analysis which shows that a method is never followed literally (Ralyte 2001) (Mirbel & de Rivieres 2002). Situational Method Engineering promotes the idea of using components, instead of complete methodologies, to specific situations (Ralyté & Rolland 2001a). In order to succeed in creating good methodologies that best suit given situations, components (building blocks of methodologies) representation and cataloguing are very important activities. In particular, the components have to be represented in a uniform way that includes all the necessary information that may influence their retrieval and assembling.

The notion of method component is central of SME as it promotes the idea of retrieving, adapting and tailoring modular parts, rather than complete methodologies, to specific situations. There are various representations of modular parts: fragments (Brinkkemper 1996), chunks (Rolland, Plihon & Ralyté 1998), components (Wistrand & Karlsson 2004), OPF fragments (Henderson-Sellers 2002) and method services (Deneckère, Iacovelli, Kornyshova & Souveyet 2008) (Guzélian & Cauvet 2007) (Iacovelli, Souveyet & Rolland 2008).

Method fragment approach (Brinkkemper 1996). Fragments are standardized building

blocks based on a coherent part of method. A fragment is either a Product or a Process fragment and is stored on a method base from which they can be retrieved to construct a new method following assembly rules (Bunt 1997). The method component definition consists in encouraging a global analysis of the project while basing itself on contingency criteria. Projects and situations are characterized by means of factors associated with the methods.

Method chunk approach (Ralyté, Deneckère & Rolland 2003). A chunk is described as a

way to capture more of the situational aspects in ME and to appropriately support the retrieval process. A chunk based method aims at associating the reusable components to their description in order to facilitate component research and extraction according to the user's needs. The chunk approach expresses projects requirements (the context) as a requirements map, which is used to test the similarity between requirements and existing components.

Method component (Wistrand & Karlsson 2004). Components allow viewing methods as

constituted by exchangeable and reusable components. Each component consists of descriptions for process (rules and recommendations), notations (semantic, syntactic and symbolic rules for documentation), and concepts. This approach introduces the notion of method rationale which is the systematic treatment of the arguments and reasons behind a particular method. In the same way, the component description contains its rationale. Its matching with the context is performed by goal analysis.

OPF fragment (Henderson-Sellers 2002). In the OPEN Process Framework (OPF), the

fragment is generated from an element in a prescribed underpinning model. This meta-model has been upgraded with the availability of the international standard ISO/IEC 24744.

Method service (Guzélian & Cauvet 2007). This approach offers a repository with a large

variety of method fragments, called method services, together with a service composition process. During composition, the process guides developer’s choices; it selects method services and delivers a method fragment that achieves developer’s requirements. The SO2M meta-model is based on three main principles: service orientation, task ontology for reuse of knowledge on development problems and dynamic construction of method services for generating tailored methods. The method service approach uses an identification part that defines the purpose of the service. The component retrieval is thus done by using goal, actor, process, and product

ontologies.

(Deneckère, Iacovelli, Kornyshova & Souveyet 2008) structures the process of SME according to three steps of manipulating method components:

(6)

(a) the decomposition of methods into components which are stored in a method repository, (b) the retrieval of components that better match the project specificities and

(c) the construction of a new method with these selected components.

According to these steps, different method components could be compared according to the four following criteria: decomposition principle, retrieval/selection principle, matching with situation, and construction technique (See Table 1).

First, the methods are decomposed into methods components which are stored in method base (or repository). Thus, we define the criterion “decomposition principle” which deals with

different ways to decompose methods into components. This principle predefines the components’ description used for their identification during project fulfilment.

Once the methods are decomposed and stored in the base, they could be used in the projects. On the first step, the engineer must find in the method base the components that better match the project specificities. On this basis, we identify two criteria: retrieval/selection principle and matching with situation. The retrieval/selection principle defines steps to carry out for

identifying an appropriate component. In ME, all approaches are situational, which means they take into account the specific project situation by different manners. This aspect is considered within the matching with situation attribute.

The next step is to build a new method from the selected components. Based on (Nehan & Deneckère 2007), we distinguish the following main manners to use components for

constructing a new method according to project specificities: assembly, extension, and reduction. By assembly, separate fragments are grouped with regard to the studied specific project to form a unique method (Ralyté, Deneckere & Rolland 2003). By applying extension, a basic method is transformed into a new one by addition of new components (Ralyté, Deneckere & Rolland 2003). By reduction, some components are removed from the basic method in order to transform it to match the engineer's needs (Wistrand & Karlsson 2004).

Table 1. Method Components Comparison.

Criteria Fragment Chunk Component OPF Fragment Method Service Decomposition

principle

by intentions by goal inheritance, instantiation Not specified Retrieval/selecti on principle Request similarity measure

request by goal request by goal semantic similarity

Matching with situation project characterisati on requirements map by goal and actor

by goal, actor, process, and product ontologies

Construction technique assembly assembly, extension assembly, extension, reduction

agile assembly without overlapping

Decomposition Principle. The decomposition principle is quite different following the

component type. Method fragment uses a tree decomposition to link all coherent method parts. Chunks are obtained by intentional decomposition of methods (Ralyté, Deneckere & Rolland 2003). The OPF fragment is a clabject, which is a result of both instantiation and inheritance (Gonzales-Perez 2007). Components are decomposed by goals (Wistrand & Karlsson 2004). The method service approach does not specify this attribute value.

(7)

Retrieval/Selection Principle. The retrieval and selection of a method fragment are made by

different types of queries. Chunks are selected with the application of similarity measures of their descriptors and interfaces. This helps to evaluate the degree of matching between them and the requirements (Ralyté, Deneckere & Rolland 2003). On the same way, the method service selection is made by a comparison of the requirements (expressed by intentions) with the service intentional descriptors by ontologies, which allow comparing the semantic similarity (Guzélian & Cauvet 2007). Differently, OPF fragments, stored on a ‘work product tool’, are selected with queries on their endeavour (Gonzales-Perez 2007). Method fragments are selected by application of request on the goal (Harmsen, Brinkkemper & Oei 1994).

Matching with situation. Approaches don’t match the situation with the same techniques.

The method fragment definition consists in encouraging a global analysis of the project while basing itself on contingency criteria. Projects and situations are characterized by means of factors associated with the methods. The chunk approach includes projects requirements expressed as a requirements map (Ralyté, Deneckere & Rolland 2003), which is used to test the similarity between requirements and existing fragments. In component containing its "rational", the matching is performed by goal analysis (Wistrand & Karlsson 2004). The Method service approach uses an identification part that defines the purpose of the service. The matching is thus done by using goal, actor, process, and product ontologies (Guzélian & Cauvet 2007).

Construction technique. The method fragments are assembled for creating a new method.

The chunk approach uses assembly (allowing overlapping between different chunks) and extension. In addition to the assembling and extending, the component approach suggests method reduction. The method service construction is based on a composition process that supports the aggregation of services in sequence or in parallel (Guzélian & Cauvet 2007). In the OPF approach, a new method is constructed by dynamic instantiation of fragments during the project. Hence, the OPF approach suggests an agile construction of methods.

A more detailed comparison of these different kinds of modular parts may be found in (Deneckère, Iacovelli, Kornyshova & Souveyet 2008).

Figure 1. Method Component Meta-model.

Our view of a component has been described in (Deneckère, Iacovelli, Kornyshova & Souveyet 2008). We based our method component on the method chunk for its intrinsic

intentionality as we decompose the methods into method components according to an intentional MethodComponent ID name * ProcessPart ProductPart SourceProductPart TargetProductPart Intention

(8)

principle. This part will then be used for retrieving and selecting method components from the method base. We suggest modelling method components as shown at Fig. 1.

Method components are expressed at different granularity, at various levels of abstraction. For instance, a component may be an entire method that can be decomposed into other less complex components (which, in turn, may also be decomposed into other more simple components, and so on). They are a representation of the components composition.

The intention describes the general purpose of the component. The product part corresponds to the description of the component input and output product models. The source product part defines the product required for applying the component. The target product part defines the result, which must be obtained by the component application. The process part contains guidelines which explain how to apply the component in order to obtain the product part.

For instance, a method component Weighting is given at Fig. 2. for illustrating this model. This component is part of decision-making methods. It allows defining weights to criteria in a given decision-making situation. The Weighting component is described by its ID ant its name. Its intention is to Define relative importance of criteria. The source product part is composed of criteria organized into a set. The target product part includes also a weight class. The process part describes the main steps to follow for defining weights, namely: scale criteria according to their importance, attribute values from 1 to 100 to each criterion, and calculate relative importance. Finally, it shows how to create the corresponding class if necessary.

Figure 2. Decision-making Method Component Weighting.

Method Component Intention

Define relative importance of criteria Process Part () Scale criteria according to their importance () Attribute values from 1 to 100 to each criterion () Calculate relative importance () Create corresponding class: MethodComponent.ID=M.cc3 MethodComponent.name=Weighting AddClass ‘Weight’ AddAttribute ‘value’ SetValue ‘value’ Add Association ‘is_defined_for’

Source Product Part Target Product Part Criterion CriteriaSet * Criterion Weight value: Real is_defined_for 1 0..1 CriteriaSet * Product Part

(9)

2.3. Method Components Context

Based on the study of different SME approaches dealing with method components, we have identified five main approaches dealing with context in the method engineering field.

Reuse frame. The reuse frame (Mirbel 2008) is a framework representing different factors

which affect IS development projects. These factors are called criteria. Reuse frame allows specifying a context of method fragments reuse, searching method fragments and comparing between them in order to find an alternative fragment to a used one. The reuse frame model includes a reuse situation (which is a set of criteria classified into three dimensions:

organizational, technique and human) and reuse intention.

Interface. In (Ralyté & Rolland 2001b) the method fragment context is defined by its

interface which includes a situation and an intention. The situation represents the conditions in which the method fragment can be applied in terms of required inputs product(s). The intention is a goal that the method fragment helps to achieve. Therefore, the interface model includes two elements: the situation and the intention. These two first approaches have been unified in (Mirbel & Ralyté 2006).

Method service context. The method service context (Guzélian & Cauvet 2007) aims at

describing the situation in project development for which the method service is suitable and defining the purpose of the service. Its model includes domain characteristics (project nature, project domain) and human (actor), process and product ontologies.

Contingency factors. Situations (the context) are described by a set of characteristics called

contingency factors (Van Slooten & Hodes 1996) or project factors (Harmsen 1997; Harmsen, Brinkkemper & Oei 1994). These factors are used to define the project situation by assigning values to them. In (Van Slooten & Hodes 1996), four categories are given: domain

characteristics (describing the content of the system), external factors (laws and norms), technical factors (related to the development platform) and human factors (representing the development expertise of people).

Development situation. (Karlsson & Agerfalk 2004) defines the development situation as an

abstraction of one or more existing/future software development projects with common characteristics. This situation is used to characterize the specific projects and to select configuration packages (method fragments). The development situation model includes a characteristics set.

Based on the review of these five approaches, we have identified height characteristics (context elements) which allow us to compare existing context approaches (See Table 2). This comparison highlights that there is no approach which consider all possible characteristics. Moreover, the analysis of these context approaches shows that they do not suggest a way to specify context characteristics. For instance, the context of the DM method component illustrated at Fig. 2 must be defined in order to state in what kind of situation this component is useful. However, the existing literature does not provide means for defining its context.

(10)

Table 2. Comparative analysis of approaches dealing with context in ME field: context elements. Approach Characteristics Goal/ Intention

Organiza-tional Technical Human Domain External Process Product

Reuse Frame X X X X Interface X X Method service context X X X X Contingency factors X X X X Development

situation Not specified

3. CONTEXTUALIZATION OF METHOD COMPONENTS 3.1. Our proposal

In SME, all approaches are situational, which means they take into account the specific project situation (or Context). However, the definition or description of this context is often just superficially addressed.

Our proposal uses the context expressiveness to describe the situation in which a component may be applied. It is then based on the semantic type of context previously presented. Moreover, our view of a component includes an intention oriented approach which allows representing the cognitive aspect of the context.

The preceding comparative analysis of context approaches shows that they address several aspects of context. However, they do not cover all of them and do not help in the context characteristics specification. Our goal is to enhance the definition of the context of IS

development method for the further selection of components from a repository according to a given situation. In the following we present our vision of context and a process to define the context for a given method.

3.2. Enhanced definition of method context

We propose to consider the context granularity at two levels: the method and method component ones (See Fig. 3. for the proposal overview). Each method is available in a given context. As a method is composed of some components, each of them can be also described by specifying its context. Therefore, the method context is an aggregation of contexts associated to its components.

Figure 3. Proposal Overview.

Method MethodContext MethodComponent MethodComponentContext * is_associated_to is associated to is_applied_to *

(11)

In our proposal, we describe the context as a set of characteristics. These characteristics describe situations of a method application. The detailed context model is presented at Fig. 4.

Figure 4. Context Model.

The central element of this model is characteristic. A set of characteristics constitute the context. Context characteristics indicate specific conditions to use the component.

Characteristics are organized into facets for better representation and comprehension. We distinguish two types of characteristics (and consequently two types of facets): generic and specific. The first ones are common for most IS engineering projects; the latter ones vary from one project to another. To distinguish between them is important because of their different identification approaches. The context characteristics set is defined for a method component. Therefore, each method component is described by the valuations of these characteristics (value).

In the following, we describe different context characteristics by facets.

Generic characteristics. In order to establish the typology of generic characteristics we have

used IS development project characteristics (Kornyshova, Deneckère & Salinesi 2007). In this work, a project characteristics typology is proposed in order to guide method components retrieval and to prioritize the selected components.

The suggested typology of context characteristics covers essential aspects of IS engineering projects. Based on (Mirbel & Ralyté 2006), (Van slooten & Hodes 1996) and (Kornyshova, Deneckère & Salinesi 2007), it includes four facets: organizational, human, application domain, and development strategy.

The organizational facet (Table 3) highlights organizational aspects of IS project development. For instance, the Management Commitment characteristic represents the management team involvement in the project. Possible values for this characteristic are Low, Normal and High (i.e. a High value means a high involvement and so on).

MethodComponent ID name * Facet Characteristic * Value Context Generic * Specific Organizational Human ApplicationDomain DevelopmentStrategy Intentional Satisfactional Decisional Internal

(12)

Table 3. Organizational Facet Characteristics.

Characterisitc Type Value domain

Management commitment degree Quantative 3-grade scale

Qualitative ENUM:{low, normal, high}

Importance degree Quantative 3-grade scale

Impact degree Quantative 3-grade scale

Time pressure degree Quantative 3-grade scale

Shortage of resources degree Quantative 3-grade scale

Level of innovation degree Quantative 3-grade scale

Size Quantative 3-grade scale

Cost Quantative REAL

Nature of limited resources Qualitative ENUM:{financial, human, temporal, informational }

Innovation nature Qualitative ENUM:{business innovation, technology innovation}

Duration Quantative REAL

The human facet (Table 4) describes the qualities of persons involved in IS project development. For example, the User involvement characteristic represents the kind of participation of the users in the project. Its values may be real or virtual.

Table 4. Human Facet Characteristics.

Resistance degree Quantative 3-grade scale

Conflict degree Quantative 3-grade scale

Expertise degree Quantative 3-grade scale

Clarity degree Quantative 3-grade scale

Stability degree Quantative 3-grade scale

Expert role Qualitative ENUM:{tester, developer, designer, analyst}

User involvement Qualitative ENUM:{real, virtual}

Stakeholder number Quantative NUMBER

The application domain facet (Table 5) includes indicators characterizing the domain of IS project. For instance, the Application type characteristic deals with the different kinds of projects according to the organization structure and can have the following values: intra-organization application, inter-organization application, organization-customer application.

(13)

Table 5. Application Domain Facet Characteristics.

Formality degree Quantative 3-grade scale

Relationships degree Quantative 3-grade scale

Dependency degree Quantative 3-grade scale

Complexity degree Quantative 3-grade scale

Repetitiveness degree Quantative 3-grade scale

Variability degree Quantative 3-grade scale

Application type Qualitative ENUM:{intra-organization, inter-organization, organization-customer }

Application technology Qualitative ENUM:{application to develop includes a database, application to develop is distributed, application to develop includes a GUI}

Dividing project Qualitative ENUM:{one single system, establishing system-oriented subprojects, establishing process-oriented subprojects, establishing hybrid subprojects}

Variable artefacts Qualitative ENUM:{organisational, human, application domain, and development strategy}

The development strategy facet (Table 6) gathers indicators about different characteristics of development strategy. For instance, the Source system characteristic represents the origin of the reused elements that may be code, functional domain or interface.

Table 6. Development Strategy Facet Characteristics.

Source system Qualitative ENUM:{code reuse, functional domain reuse, interface reuse}

Project organization Qualitative ENUM:{standard, adapted}

Development strategy Qualitative ENUM:{outsourcing, iterative, prototyping, phase-wise, tile-wise}

Realization strategy Qualitative ENUM:{at once, incremental, concurrent, overlapping}

Delivery strategy Qualitative ENUM:{at once, incremental, evolutionary}

Tracing project Qualitative ENUM:{weak, strong}

Goal number Quantative NUMBER

Qualitative ENUM:{one goal, multi-goals}

Specific characteristics. Their identification is based on the method description. The method

engineer defines them by analyzing different aspects which are organized into four facets: intentional, satisfaction, decisional and internal, like in (Harmsen 1997).

(14)

The intentional facet concerns the method intentions. The satisfaction facet indicates the satisfaction degree that the engineer has about the method application results. The decisional facet arises from a decision-making process in the method. The internal facet concerns the known criteria associated with the specific project management. For the specific map characteristics see Table 7.

Table 7. Specific Map Characteristics.

Goal satisfaction degree Quantative 3-grade scale.

Goal achievement degree Quantative 3-grade scale

Section satisfaction degree Quantative 3-grade scale

Section completeness degree Quantative 3-grade scale

Table 8 shows the correspondence between the proposed typology and the existing context elements (analyzed in the previous section). We can make some remarks to compare them:

• Our typology covers all existing elements.

• We propose to identify more precisely process and product characteristics using our approach instead of using product and process as context characteristics directly. • We add decisional characteristics which are not presented in the existing typologies. Table 8. Correspondence between the proposed typology and existing context elements.

Proposed Typology Context Elements (cf. Table 2)

Organizational Organizational

Human Human

Application domain Domain Development strategy Technical Intentional Goal/ Intention

Satisfaction External, Process, Product Decisional Process, Product

Internal Technical, Process, Product

Our typology indicates the main characteristics that can be defined in function of a given situation. It can be completed if new characteristics arise. Fig. 5 illustrates the obtained characteristics typology as an ontology, like in (Gu, Wang, Pung & Zhang, 2004).

(15)

Figure 5. Characteristics ontology. 3.3. Contextualization methodology

In order to define the context for a given method and its components, we propose an approach based on the contextualization process modeled with the MAP formalism.

3.3.1. Map Formalism

A MAP illustrates a given process of IS engineering. The MAP model (Rolland, Prakash & Benjamen 1999) is a representation of process models expressed in intentional terms. It allows specifying process models in a flexible way by focusing on the process intentions, and on the various ways to achieve each of these intentions.

The meta-model of MAP (Rolland & Prakash 2001) is represented as a UML class diagram (See Fig. 6).

Figure 6. Map Meta-model.

Characteristic Generic Specific Organizational Development strategy Application domain Human Intentional Satisfaction Decisional Internal Management commitment Importance Expertise degree User involvement … … Formality Complexity … Project organization Delivery strategy … Situation … Intention … Strategy … Section code description Map code description Intention Start Stop Strategy 2..* Refinement 1..* 0..1 Path 1..* 1..* Thread 1..* 1..* Bundle 1..* 1..* 1..* Source 1..* Target 1..*

(16)

A Map is a combination of at least two sections. Each Map has a code and a description which allow identifying it. The Map code depends on the Map position according to the refinement levels. The Map description gives a main purpose of the Map, or in other words, its main intention.

The Map model enables to represent non-deterministic sequences of activities. It is expressed through the combination of different intentions and strategies used for achieving these intentions. Actually, an engineer has several intentions or goals that he(she) wants to achieve. Furthermore, there are several ways of achieving these intentions. The Map model allows considering

intentions and strategies in ISE processes in order to perform them in a flexible manner. An Intention is a goal that can be achieved by the performance of an activity. Each map has two special intentions, Start and Stop, to begin and to end the map respectively (Rolland & Prakash 2001). (Prat 1997) suggest a model to describe the intention in details. This model has already been applied to the method engineering field in order to represent the intention of the method chunks (Ralyte 2001). Following this model, the intention is expressed in natural language and is composed of a verb and at least one parameter. Each parameter has a particular role with regard to the verb. An example is the Identify DM Requirements intention. The detailed description of the intention elements could be found in (Prat 1997) (Ralyte 2001).

A Strategy is an approach, a manner to achieve an intention (Rolland & Prakash 2001). Each strategy relates two intentions. The strategy concept allows, firstly, separating the goal and the manner to achieve this goal and, secondly, expressing alternative approaches for the goals achievement. An example is the By problem exploring strategy.

A Section is the main element of the Map model. It represents a combination of two intentions and a strategy relating these intentions. In other words, a section encapsulates knowledge about an activity in a triplet <Source intention; Strategy; Target intention>, in other terms, knowledge corresponding to a particular process step to achieve an intention (the target intention) from a specific situation (the source intention) following a particular technique (the strategy). A section is characterized by a code and a description. The Sections code depends on its position on the Map. The Section description embodies the triplet <Source intention; Strategy; Target intention>. An example can be mentioned: <Start; By problem exploring; Identify DM Requirements>.

A section of a map can be refined by another map. This is shown through the refinement relationship between the section and the map. Refinement is an abstraction mechanism by which a complex assembly of sections at level i+1 is viewed as a unique section at level i. This

relationship introduces levels in the process representation as each map may be represented as a hierarchy of maps.

Sections in a map are related to each other by three kinds of relationships namely thread, path and bundle.

• A thread relationship shows the possibility for a target intention to be achieved in several ways from the same source intention. Each of these ways is expressed as a section in the map.

• A path relationship establishes a precedence relationship between sections. For a section to succeed another, its source intention must be the target intention of the preceding one. • A bundle relationship shows the possibility for several sections having the same source

and target intentions to be mutually exclusive.

A Map is graphically presented as a directed diagram, where intentions are nodes and

strategies are edges, and each section corresponds to two nodes related to each other by an edge (See Fig. 7). The directed nature of this diagram shows the precedence links between intentions.

(17)

An edge enters a node if its associated strategy can be used to achieve the target intention (the given node).

Figure 7. Map Model Graphical Representation. An example of a map is given at Fig. 8.

Figure 8. Map Example.

This map contains three intentions, namely: Start, Identify DM Requirement, and Stop. There are four strategies: By problem exploring, By variability exploring, Tool-based strategy, and By expertise which correspond to the four sections:

• <Start; By problem exploring; Identify DM Requirements>; • <Start; By variability exploring; Identify DM Requirements>; • <Identify DM Requirements; Tool-based strategy; Stop>; • <Identify DM Requirements; By expertise; Stop>.

Each map is completed by a set of guidelines that help engineers in navigating through the map. There are three types of guidelines: simple, tactical and strategic. A simple guideline may give informal content advice on how to proceed in handling the situation in a narrative form. A tactical guideline is a complex guideline, which uses a tree structure to link its sub-guidelines. A strategic guideline is a complex guideline which shows that a section of a map can be refined by another map. This relationship implies that each map may be represented as a hierarchy of maps.

The MAP model defines the process through the combination of observable situations in which a certain number of specific intentions can be achieved. The work to be made is described in the process as depending on both situation and intention. In other words, it depends on the context in which a method engineer must act at a given point in time. By modelling intentions and the ways (strategies) to reach them, the process has the ability to represent the cognitive

Intention Strategy Section Identify DM Requirements By problem exploring Start Identify DM Requirements By problem exploring By variability exploring By problem exploring Tool‐based strategy By expertise Stop Start Identify DM Requirements

(18)

context as defined by Bunt. Moreover, by relating method service (Rolland 2008) (or method component (Ralyté, Deneckère & Rolland 2003)) to a section, Rolland extends the context expressiveness of the MAP to the semantic context of Bunt. This approach allows identifying several context aspects. More precisely, this model includes a set of guidelines which help an engineer navigate through the process model. The navigation is carried out by arguments that allow the engineer to choose the adapted variant within the process model. These arguments express the context of a given process model.

3.3.2. Contextualization Map

The Map model is used in our approach for modeling the contextualization process (See Fig. 9). This process includes two possible ways to define the context: top-down or bottom-up. By the top-down approach, the engineer defines the method context and then instantiate it for each method component. By the bottom-up approach, the engineer specifies the contexts of all method components and assemblies them into the method context.

Both method and method component contexts can be defined following two strategies: By deduction and By generation. It depends on the characteristic type. The generic characteristics are deduced from the generic context typology and the specific ones are generated from method description. These strategies could be applied as many times as possible characteristics exist.

Figure 9. Contextualization Map.

This MAP has two main intentions: Define method context and Define method component context. The achievement of these intentions implies the definition of the context characteristics set for method or for method components respectively. The definition of method components contexts includes also the attribution of values to the defined characteristics.

The contextualization Map includes eight sections, as shown in Table 9.

Start Stop Define method context Define method component context By assembly By instantiation By generation By deduction By generation By deduction By completeness By completeness S1 S2 S3 S4 S5 S6 S7 S8

(19)

Table 9. Contextualization Map Sections.

Section <Source intention, Strategy, Target intention > S1 <Start, By deduction, Define method context>

S2 <Start, By deduction, Define method component context>

S3 <Start, By generation, Define method context>

S4 <Start, By generation, Define method component context>

S5 <Define method context, By instantiation, Define method component context>

S6 <Define method component context, By assembly, Define method context>

S7 <Define method context, By completeness, Stop>

S8 <Define method component context, By completeness, Stop>

All these sections are explained below. Operators are defined for each section in order to indicate how to proceed for carrying out its execution.

<Start, By deduction, Define method context>. The generic characteristics deduction is

based on the context typology. This section gives a selection of characteristics carried out by the IS method engineer. The result of this strategy is a sub-set of generic characteristics available for a given project. The corresponding operator is:

Select Context Characteristic ()

<Start, By deduction, Define method component context>. This section includes the

selection of characteristics form generic typology like the previous one and includes furthermore the attribution of values to these characteristics. The result of this strategy is a sub-set of generic characteristics available for a given project with corresponding values. Two following operators are applied consecutively:

Select Context Characteristic ()

Attribute a Value to Context Characteristic ()

<Start, By generation, Define method context>. The specific characteristics generation is

based on the method description. The method engineer defines them by analyzing different aspects which are organized into four facets: intentional, satisfaction, decisional and internal. This section includes four operators. Each of the following operators is applied depending on the corresponding characteristic’s facet:

Analyze Method Goal ()

Measure Method Satisfaction () Analyze Method Argumentation () Measure Method Characteristics ()

<Start, By generation, Define method component context>. The definition of specific

characteristics for method components context is the same as for method context (the previous section) but also requires the attribution of characteristics values. This section uses the same four operators and adds another one that deals with the attribution of values to the characteristics. This last one is applied after each of the first four operators for defining concrete values of the identified specific characteristics.

(20)

Measure Method Satisfaction () [for satisfaction facet] Analyze Method Argumentation () [for decisional facet] Measure Method Characteristics () [for internal facet] Attribute a Value to Context Characteristic () [for all facets]

<Define method context, By instantiation, Define method component context>. The

context characteristics instantiation is common for both characteristics types and is applied in the top-down approach. This section allows defining a sub-set of generic and specific method

characteristics with an associated value for each method component separately. Several functions may be applied (sum, maximum, minimum, average, weighted sum, and so on) for attributing values to the method context. This section contains two operators applied consecutively:

Retain Context Characteristic ()

<Define method component context, By assembly, Define method context>. In the case of

the bottom-up approach, the strategy By assembly follows the definition of the method component context By deduction or By generation. The method engineer groups method components characteristics together. As a result, the method context includes all characteristics of its components contexts. The application of this strategy allows also defining characteristics’ values for the method context. This section is carried out by the following operator:

Group Characteristics ()

<Define method context, By completeness, Stop> and <Define method component

context, By completeness, Stop>. These sections are the same in both top-down and bottom-up

approaches and include verification of completeness and coherence of the described context. The associated operator is:

Verify Context Completeness ()

All these operators are resumed in the Table 10. Table 10. Operators’ Description.

Operators Description

Select Context Characteristic ()

Helps to select each of the pertinent characteristics of the context.

Attribute a Value to Context Characteristic ()

For each characteristic selected, a value corresponding to the project context has to be defined.

Analyze Method Goal () Helps to define the characteristics of the intentional facet which concerns the method intentions (the method goals).

Measure Method Satisfaction ()

Helps to measure the satisfaction degree on the results obtained by the engineer and concerns the satisfaction facet.

Analyze Method Argumentation ()

The decisional facet needs this operator in order to describe a decision-making situation with the definition of the arguments to take into account in the DM process.

(21)

Characteristics () the specific project management.

Retain Context Characteristic ()

Helps to define a subset of characteristics (generic or specific characteristics) and to give them values adapted to the project.

Group Characteristics () This operator allows to group all the characteristics together in the same set which corresponds to the context.

Verify Context Completeness ()

Helps to study the completeness and the coherency of the context set of characteristics.

4. APPLICATION: THREE CASES STUDIES

In this section, we illustrate our proposal by applying the contextualization methodology to three cases: scenario conceptualization, project portfolio management and decision-making.

We use the Map model for representing methods and for organizing method components into methods in our examples. The key concept of a Map is the notion of Section. When dealing with methods modeled by maps, each method component is represented by a map section. Thus, each Map section is linked to a particular method component, as shown in Fig. 10.

Figure 10. Section and Method Component Correspondence.

Each case study describes a particular map organizing method components. We then show how the engineer may use the contextualization map in order to create the context of the method/ components.

4.1. Case Study #1: Scenario Conceptualization

4.1.1. Case Study Description

The first example is based on the map defined in the Crews-L’écritoire approach (Ralyté, Rolland, Plihon &Ralyté 1999). This map is given at Fig. 11.

Method MethodComponent Map Section 1..* * refines 1 0..1 is_represented_by

(22)

Figure11. Crews-L’écritoire Approach Map (CL Map).

This map was created to support the elicitation of functional system requirements in a goal-driven manner and to conceptualize them using textual devices such as scenarios or use cases. It provides guidelines to discover functional system requirements expressed as goals and to conceptualize these requirements as scenarios describing how the system satisfies the

achievement of these goals. This map contains three main intentions, namely ‘Elicit a Goal’, ‘Write a Scenario’ and ‘Conceptualize a Scenario’. There are twelve separate sections which allow the engineer to navigate through the map. Each of these sections is expressed as a specific component which is saved into a repository.

4.1.2. Contextualization Process

The engineer executes the contextualization map. He decided to select the top-down approach of the contextualization process. This specific way to navigate through the map will guide the engineer first through the definition of the method characteristics and then through the definition of the components ones. Fig. 12 shows the path used in the navigation through the map in order to define the method components contexts.

Figure 12. Path used in the Contextualization Map for the CL Map Case Study.

Start Elicit a Goal Write a Scenario Conceptualize a Scenario Stop Initial goal identification strategy Linguistic strategy Template driven strategy Goal structure driven strategy Refinement discovery strategy Composition Discovery strategy Alternative Dicovery strategy Template driven strategy Free prose strategy Manual strategy Computer supported strategy Completness strategy S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 Start Stop Define method context Define method component context By instantiation By deduction By completeness S1 S5 S8

(23)

This selected path contains three sections of the Contextualization Map and may be resumed on the three following steps:

1. Definition of the method Context (S1),

2. Definition of the method components contexts (S5), and

3. Verification of the context completeness (S8).

First step (S1: Definition of the method context). The engineer had studied the set of possible

generic characteristics to specify the context of its method. He has applied the operator Select Context Characteristic () in order to define a sub-set of generic context characteristics according to the given project. In this example, he has selected three indicators: Expertise degree,

Formality degree and Duration (See Table 11). Table 11. Generic facet values.

Characteristic Value domain

Human facet

Expertise degree 3-grade scale

Application domain facet

Formality degree 3-grade scale

Organisational facet

Duration REAL

Second step (S5: Definition of the method components context). The method context defined previously is instantiated in this step for each component (each section of the CL map). It means that a value has to be affected to each characteristic. The following operators are applied to each method characteristic: Retain Context Characteristic () and Attribute a Value to Context

Characteristic (). Table 12 shows the values of these criteria applied to each section of the CL map.

Table 12. CL map indicators

Section Expertise

degree

Formality

degree Duration

S1 <Start; Initial goal identification strategy; Elicit a goal> 1 1 10 mn

S2 <Elicit a goal; Goal structure driven strategy; elicit a goal> 1 2 15 mn

S3 <Elicit a goal; Template driven strategy; elicit a goal> 1 3 15 mn

S4 <Elicit a goal; Linguistic strategy; elicit a goal> 1 1 15 mn

S5 <Elicit a goal; Template strategy; write a scenario> 2 3 10 mn

S6 <Elicit a goal; Free prose strategy; write a scenario> 1 1 15 mn

S7 <Write a scenario; Manual strategy; conceptualize a scenario>

2 1 15 mn

S8 <Write a scenario; Computer supported strategy; conceptualize a scenario>

1 3 5 mn

(24)

Elicit a Goal>

S10 <Conceptualize a scenario; Composition discovery strategy;

Elicit a Goal>

2 2 20 mn

S11 <Conceptualize a scenario; Refinement discovery strategy;

Elicit a Goal>

2 2 20 mn

S12 <Conceptualize a scenario; Completeness strategy; Stop> 1 1 5 mn

Third step (S8: Verification of the context completeness). The engineer has decided that the identified context characteristics are sufficient by applying the operator Verify Context

Completeness ().

4.2. Case study #2: Project Portfolio Management

The second example deals with Information Technology Project Portfolio Management (IT-PPM). The Fig. 13 shows the IT-PPM intentional map which describes the ways to manage a project within a portfolio.

Figure 13. IT-PPM Map.

This Map is a refinement of the section < Define Risks, By Project Planning, Align IT and Business Process > of the map dealing with IT governance presented in (Claudepierre & Nurcan 2009). This map contains three main intentions: ‘Identify project’, ‘Evaluate project’, and ‘Prioritize project’ and ten associated sections. The related components are saved into a method base which includes their description and methodological guidelines for their application.

4.2.2. Contextualization Process Start Stop Identify project Evaluate project Prioritize project By project portfolio completion By applying function over criteria By ad‐hoc classification By controlling goal achievement By modulating project development By requirement consideration By canceling project portfolio By goals‐oriented criteria identification By lack of goals‐ coverage By project completeness 7 9 1 2 3 4 5 6 8 10

(25)

The engineer has selected the top-down approach of the contextualization process. It guides the engineer through the definition of the method characteristics before the definition of method component characteristics. Fig. 14 shows the path used in the navigation through the

contextualization map in this particular case study.

Figure 14. Path used in the Contextualization Map for the IT-PPM Case Study.

This path contains four sections of the Contextualization Map that we represent within the three following steps:

1. Definition of the method Context (S1 and S3),

2. Definition of the method components contexts (S5), and

3. Verification of the process completeness (S8).

First step (S1, S3: Definition of Method Context). This step contains the execution of two

sections of the Contextualization Map: S1 and S3.

Definition of the generic characteristics (S1). The engineer uses the characteristics

presented in Table 4 and Table 5 as generic characteristics to specify the context of the method. The engineer has applied the operator Select Context Characteristic () in order to define a sub-set of generic context characteristics according to the given project. He has selected three generic characteristics for this example: Expertise degree, Expert role and Application type (Table 13). Table 13. Generic Characteristics.

Human facet

Expertise degree {low, normal, high}

Expert role {tester, developer, designer, analyst} Application domain facet

Application type {intra-organization application, inter-organization application, organization-customer application}

Definition of the specific characteristics (S3). The engineer also uses specific context

characteristics (cf. Table 14). This specific context is depicted by the constraints of the business environment (the design situation), the intention of the designer and the strategy for reaching the intention. So, the three operators were applied to identify the specific characteristics. Analyze Method Goal () is used to identify the Intention which is related to the intentional type of specific characteristic. Measure Method Satisfaction () allows defining the Situation in the Satisfactional

Start Stop Define method context Define method component context By instantiation By deduction By completeness S1 S5 S8 By generation S3

(26)

facet (as it describes the satisfaction degree of the previous intention). Finally, Analyze Method Argumentation () defines the Strategy in the decisional facet of the specific characteristic. Table 14. Specific Characteristics.

Intentional facet Intention TEXT Satisfactional facet Situation TEXT Decisional facet Strategy TEXT

Second step (S5: Definition of Method Components Context). The method context defined at the previous step is now instantiated for each component. A value is affected to each

characteristic in order to help the case process execution guidance. The following operators are applied to each method characteristic: Retain Context Characteristic () and Attribute a Value to Context Characteristic (). The results are presented in Table 15.

Table 15. Specific Characteristics Instantiation.

Section Expertise degree Expert role Appli. Type

Situation Intention Strategy

S1 <Start; By goals-oriented criteria identification; Identify project>

Normal Analyst designer Intra-Org. Problem statement Identify project By requirement consideration S2 <Identify project; By ad-hoc

classification; Prioritize project>

Low Analyst designer Intra-Org. Project identified Prioritize project By ad-hoc classification S3 <Identify project; By goals-oriented

criteria identification; Evaluate project>

High Analyst designer Intra-Org. Project identified Evaluate project By goals-oriented criteria identification S4 <Prioritize project; By modulating

project development; Prioritize project>

High Designer Intra-Org. Project prioritized Prioritize project By modulating project development S5 <Prioritize project; By cancelling

project portfolio; Stop>

Low Designer Intra-Org.

Project prioritized

Stop By canceling project portfolio S6 <Prioritize project; By project portfolio

completion; Stop>

Low Designer Intra-Org. Project prioritized Stop By project portfolio completion S7 <Prioritize project; By controlling goal

achievement; Evaluate project>

Low Designer Intra-Org. Project prioritized Evaluate project By controling goal achievement S8 <Evaluate project; By applying function

over criteria; Prioritize project>

Normal Analyst Intra-Org. Project evaluated Prioritize project By applying function over criteria S9 <Evaluate project; By project

completeness; Stop>

Low Designer Intra-Org.

Project evaluated

Stop By project completeness S10 <Evaluate project; By lack of

goals-coverage; Identify project>

Normal Analyst Intra-Org. Project evaluated Identify project By lack of goal coverage

(27)

Third step (S8:Verification of the process completeness). The engineer has decided that the identified context characteristics are sufficient to allow a satisfying guidance through the

portfolio project management by the operator Verify Context Completeness () application.

4.3. Case Study #3: Decision-Making

The third example allows defining context for the Decision-making (DM) generic process. The map model of the DM generic process (Kornyshova 2010) is given at Fig. 15.

Figure 15. DM Generic Process Map (DM Map).

The DM Method Family describes the generic DM process including the main activities used for DM. It can be used each time an IS engineer meets a DM situation. The DM map is a

collection of DM method components organized into a generic process (a kind of multi-method) for their easier usage in practice. DM components represent detailed guidelines for DM activities associated to the specific context of their use. The DM map contains four main intentions: ‘Define Alternatives’, ‘Define Criteria’, ‘Evaluate Alternatives’, and ‘Make Decision’ and twenty six sections, or DM method components.

By process exploring By product exploring By consequences analysis _{By alternatives} description analysis Make Decision By expertise By ‘’From scrach’’ strategy Stop By method‐ based approach By prescription By preference analysis By measuring By estimation By goal analysis By validation Start By elimination By elimination By weighting By domination analysis By preference analysis By quantifying By normalizing By fuzzy values Evaluate Alternatives By using arguments By addition Define Alternatives By addition By preferences analysis Define Criteria S1 S2 S3 S4 S26 S22 S21 S20 S19 S6 S5 S7 S12 S10 S9 S11 S13 S15 S14 S17 S16 S23 S24 S18 S25 By predefined list exploring S8

(28)

4.3.2. Contextualization Process

The engineer executes the contextualization map and selects the bottom-up approach of the contextualization process as he is able to qualify each DM component. In this case, the engineer specifies the contexts of all method components and assemblies them into the method context. The used path in the Contextualization Map is shown at Fig. 16.

Figure 16. Path used in the Contextualization Map for the DM Map Case Study.

This selected path contains four sections of the Contextualization Map and may be resumed on the three following steps:

1. Definition of the method components contexts (S2 and S4),

2. Definition of the method Context (S6), and

3. Verification of the context completeness (S7).

First step (S2, S4: Definition of Method Component Context). This step contains the

execution of two sections of the Contextualization Map: S2 and S4.

Definition of the generic characteristics (S2). The engineer uses the characteristics

presented in Table 4 and Table 5 as generic characteristics to specify the context of the DM components. He has applied the operator Select Context Characteristic () in order to define a sub-set of generic context characteristics according to the given project. The engineer has selected two generic characteristics: Expertise degree, and Complexity degree (See Table 16). Table 16. Generic characteristics.

Application domain facet

Complexity degree 3-grade scale

Human facet

Expertise degree 3-grade scale

Then, the engineer attributes values to each DM method components using the Attribute a Value to Context Characteristic () operator (See Table 18).

Start Stop Define method context Define method component context By assembly By generation By deduction By completeness S2 S4 S6 S7