Development world

The aspects of the development world are detailed with the three following facets: Evolution methods, Risks identification methods and tools.

2.5.1. Evolution methods

Here we identify three families of approaches of evolution methods: scenario-based, model-based, and dependency-based.

2.5.1.1. Scenario-based evolution methods

With scenario-based methods, scenarios are built describing not only one, but several possible future situations. These methods are particularly suitable in a turbulent environment where frequent changes occur, but also in complex environments [Nurcan et al. 1999]. The framework TOGAF [Open Group 2012] recommends building scenarios for expected as well as for unexpected changes.

[Jarke et al. 1999], who advocates for scenarios as change enablers, proposes a basic framework for scenario-supported change processes with current-state and future-state scenarios placed as intermediate abstractions between systems and models (Figure 30).

Figure 30 - Framework for scenario-supported change processes [Jarke et al. 1999]

The authors identify three categories of scenarios according to their content scope: the system internal scenarios, the interaction scenarios and the environmental scenarios. The system internal scenarios don't consider the external context of the system, but only the interplay of the system components. The interaction scenarios focus on the direct system interactions between the system and other systems and between the system and its stakeholders: it is the most frequently used category of scenarios. Finally, the environmental scenarios address the organisational work context without considering the system to be designed.

In order to define and classify scenario-based approaches [Rolland et al. 1998] builds a four-dimension framework. Its multi-faceted analysis four-dimensions are: the form (with the facets description and presentation), the content (with the facets: abstraction, context,

argumentation and coverage), the purpose (descriptive, exploratory or explanatory) and the life cycle (with the facets lifespan and operation).

2.5.1.2. The model-based methods

In model-based evolution methods, models are key concepts. With these methods, there is a separation between the platform dependent aspects (or application dependent aspects) and the platform independent aspects. The Model Driven Architecture (MDA) was launched by the Object Management Group (OMG) in 2001. It relies on the Model Object Facility (MOF) standard²⁷ with a four-layer modelling stack.

MDA intent is to integrate the full lifecycle of enterprise systems which comprises software, hardware, humans and business practices. It provides a framework to understand, design, operate and evolve all aspects of the enterprise systems [DSouza 2001]. The evolution of one model to another is supported by transformations. [Mens et al. 2005] presents a taxonomy of model transformations with two orthogonal dimensions: a) vertical versus b) horizontal and c) endogenous versus d) exogenous (Figure 31). With a vertical transformation, the source and the target models reside at different abstraction levels, whereas with a horizontal transformation, the source and target models reside at the same abstraction level. With an endogenous transformation, the transformations between models are expressed in the same language, whereas with an exogenous transformation, the transformations between models are expressed in different languages.

Figure 31 – Taxonomy of models transformation [Mens et al. 2005]

27 Model Object Facility (MOF) standard: http://www.omg.org/spec/MOF/ - [last accessed: 15 dec.

2013]

2.5.1.3. The dependency-based methods

In the context of co-evolution, where the reciprocal evolution of two entities (such as the organisation and its system) is analysed, [Etien and Salinesi 2005] presents four approaches:

a) independence, b) dependence, c) interdependence and d) double dependence (Figure 32).

With the independence approach, there is no dependency between the engineering processes of each evolving entity. With the dependence approach, the evolution of one entity (here "Entity 2") is deduced from the other evolution (here "Entity 1"). With the interdependence approach, there is a shared model which specifies the evolution requirements of both entities as a single collection. Finally, with the double dependence approach, each entity evolution can be deduced from the other. This last approach combines two simple dependence approaches [Etien and Salinesi 2005].

Figure 32 - Dependency-based methods typology [Etien and Salinesi 2005]

The "Evolution Methods" Facet can be summarised with the following values:

Facet name Type Values Evolution

methods

Set scenario-based, model-based, dependency-based

2.5.2. Risks identification methods

Generally, there are two, complementary approaches for risks management [Bassetti 2002]:

the downstream and the upstream approaches. With a downstream approach, the risks

project design, but also includes a reaction to the evolution projects effects: its focus is more on the preventive reduction of the causes.

[Fallet-Fidry 2012] reminds us that the risk management was firstly related to a discipline (technological, human, organisational and environmental). However, this discipline-related risk management has shown its limits in the context of complex systems. Therefore, a new type of risk management has been developed which is multidisciplinary.

In order to identify risks, several approaches are proposed. For [Boehm 1991], typical risk identification techniques in the software development include checklists, decomposition, comparison with experience, and examination of decision drivers. In the context of IS development, [Powell and Klein 1996] presents the following risk identification techniques:

checklists, deconstruction and dissemination, generic/prototype activities, fuzzy simulation analysis, case-based reasoning and causal modelling.

After [Bohner and Arnold 1996] (cited by [Zamfiroiu and Prat 2001] and [Lehnert 2011], the impact analysis of a software change can rely either on the analysis of the dependency links or on the analysis of the traceability links. The impact analysis based on the dependency links uses the linkages between code entities (parts, variables, methods, modules, etc.) in order to determine the consequences of a change. The dependency impact analysis can be static, dynamic, or a hybrid of the two. The impact analysis based on traceability uses the relationships between all work products (including design, program source code or documents) created during the software development in both forward and backward direction.

A classical technique for calculating impacted entities is the transitive closure which is operated either on graphs or on matrixes, but the drawback of this technique is its greediness. Therefore, other techniques exist whose goal is to reduce the search space of the impact analysis, i.e. to reduce the transitive closure. [Bohner 2002] identifies the following methods: semantically guided (by predefined semantics of objects and relationships), heuristically guided (by predefined rules or heuristics to suggest possible paths to examine or dubious ones to avoid), stochastically guided (by probabilities for a specific situation) and hybrid guided (by a combination of the preceding methods).

Other approaches rely on IS components dependencies. The Prism model of changes [Madhavji 1992] incorporates a "Dependency structure" element which allows representing various item types (e.g. people, policies, laws, processes, resources, etc.), and their interdependencies as well as simplifying the identification of the items affected by a change.

[Ernst and Schneider 2010] describes a method for identifying such dependencies exemplified along the following three types of dependencies: 1) organisational dependencies which result from multiple projects targeting the same part of the organisation at the same time, 2) interface dependencies, which result from the need to migrate applications interfaces simultaneously with changing the related applications, and 3) technical dependencies which result from infrastructure dependencies of applications, e.g. the compatibility with only distinct operating systems.

The "Risks Identification Methods" Facet can be summarised with the following values:

Facet name Type Attribute Value domain

Risks

Identification Methods

Set

Method directions Enum {upstream, downstream}

Risk relation Enum {disciplinary, multidisciplinary}

Approaches

Enum {checklists, decomposition,

comparison with experience, examination of decision drivers, dependencies,

simulation}

2.5.3. Tools

The categories of existing tools which we have identified as the most relevant (yet only partially toward our research questions) to support the IS evolution steering are: intention-based guidance and Enterprise Architecture Management.

2.5.3.1. Intention-based guidance

In order to guide the stakeholders involved in a change process management, [Nurcan et al.

1999] proposes a web-based electronic guide book²⁸. In this book, the EKD-CMM²⁹ guidelines are organised as a hierarchy from large-grained into finer guidelines with executables ones as leaves. A step by step navigation is presented to the user with several alternative ways to solve an issue which he/she has to select as most appropriate. Each guideline is described with: a name (process intention), a description (summary of the content of the guideline), a body (how to achieve the intention by providing steps, choices, activities to be performed and the related concepts to be used), a situation (when the guideline can be applied) and a product (one of the EKD-CMM models). The three upper intentions are: "Understand the use of the EKD-CMM Electronic Guide Book", "Understand EKD-CMM Change Management Framework" and "Apply EKD-CMM."

2.5.3.2. Enterprise Architecture Management

The 2008 survey of EAM (Enterprise Architecture Management) tools conducted by [Matthes et al. 2008], evaluates the solutions of the major players in the market of EAM tools. In the nine tools evaluated in details, their ability to perform calculations and impact analysis based on the data contained in the repository are reported.

28 The EKD-CMM electronic guide book is accessible:

http://crinfo.univ-paris1.fr/EKD-With Adaptive Adaptive EAM 5.0³⁰

It is possible to access the information stored in the repository through the use of a search form, a query builder or in a relational format (i.e. as views in a DB system). Complex queries can be stored and assigned to roles. Finally, a predefined set of analysis is available for visualisation.

With alfabet AG planningIT 3.1³¹

It is possible to display a set of predefined reports such as affected architecture elements by a given demand or project proposal. Custom reports for impact analysis can also be defined based on the information stored in the repository.

With BOC ADOit 3.0³²

It is possible to visualize (predefined, newly created or adapted) impact analyses with flexibility of the data contained in the repository.

With Embarcadero EA/Studiob 1.1³³

It is possible either to use the impact analysis diagram or the impact analysis report. In both functionalities, only direct navigation from an object to another is supported. With the impact analysis report, two kinds of filters can be applied: on the type of relationship or on the class of the related elements. An impact analysis diagram can be created automatically from a report.

With IDS Scheer AG ARIS IT Architect 7.0.2³⁴

It is possible to compute impact analysis in different ways. The relationship tab in the property dialog enables to evaluate which objects are directly impacted (while related) by a given one. A graphical analysis of related objects can be displayed. With the use of a query wizard, the user can perform impact analysis. A predefined type of queries allows joining two queries in a way that the result of the first query is used as input to the second one.

Finally, there is the possibility to store a created query.

30 Adaptive Adaptive EAM 5.0: http://www.adaptive.com/solutions/ - [last accessed: 15 dec. 2013]

31alfabet AG planningIT 3.1 http://www.alfabet.com/en - [last accessed: 15 dec. 2013]

32 With BOC ADOit 3.0 http://www.boc-group.com/fr/products/adoit/ - [last accessed: 15 dec. 2013]

33 With Embarcadero EA/Studiob 1.1 http://www.embarcadero.com/products/er-studio - [last accessed: 15 dec. 2013]

34 IDS Scheer AG ARIS IT Architect 7.0.2 http://www.softwareag.com/corporate/service/ - [last accessed: 15 dec. 2013]

With MEGA International SA MEGA Modelling Suite 2007 (MEGA Simulation)³⁵

It is possible to rely on dialog in order to select the class of objects to be analyzed as well as define conditions on the attributes of the object. Relationships between objects can be navigated in querying. Finally, stored queries can be defined.

With Metastorm ProVision 6.0³⁶

It is possible to create navigation report, property grid, association grid or navigation grid.

Creating own reports or queries is not directly possible, but through Cristal Reports. With the navigation report, the user can select a class base object and specify which relations should be traversed to the target object.

With Telelogic AB Telelogic System Architect 11.0³⁷

It is possible to perform impact analysis via predefined reports, customized reports or explorer diagram on the data contained in the repository. The customized reports use the report generator which provides a graphical interface to define SQL-like queries. The explorer diagram automatically shows immediate relatives of a selected symbol.

With Troux Technologies Inc. Troux³⁸

It is possible to realize impact analysis by manually created visualizations or by Troux Explorer. With the former, related objects can be dragged to a diagram and existing relationships can be displayed. With the latter, the user can access updated reports and diagrams for predefined queries.

The "Tools" Facet can be summarised with the following values:

Facet name Type Values

Tools Enum Guidance, EAM tools