Meta software engineering for information system...

Scientia Iranica B (2015) 22(4), 1616{1624

Sharif University of TechnologyScientia Iranica

Transactions B: Mechanical Engineeringwww.scientiairanica.com

Meta software engineering for information systemdevelopment projects

D. Samadhiya� and W.C. Chang

Department of Technology Management, Chung Hua University, 707, Sec2, Wufu Rd, Taiwan 30012.

Received 22 May 2014; received in revised form 27 October 2014; accepted 9 May 2015

KEYWORDSProcess engineering;Structural method;Process functionality.

Abstract. There is increasing demand for sophisticated software engineering processes intoday's software systems. In this regard, however, there is a multitude of di�erent processesand each has various advantages and disadvantages some of which relate to the problemdomain or in the context of development. Computer software development processes haveto pass through many scenarios to be completed. There are many ways to solve a singleproblem in software development. Sometimes, in structural engineering, the developeris not able to decide which process will suit a particular problem. It can be said thatselecting a suitable process is a big issue in structural process software engineering, andthe problem of selecting a good candidate method is a big issue in structural processengineering. The solution of such kinds of problem can be found in the work to bedone and the task to be performed by the operational process rather than by the processstructure. This paper introduces the notion of process operationality and proposes `processarchitecture' to represent this operationality. Thus, Structural Process Engineering (SPE)becomes Operational Process Engineering (OPE). Operationally close process architectureis selected, adapted, enhanced, and restricted as needed. The task of construction consistsof putting together process features and structuring the new process.© 2015 Sharif University of Technology. All rights reserved.

1. Introduction

Nowadays, information systems are the basis of manyactivities in the real world, and due to requirements,the complexity of these information system basedsystems is increasing. On the other hand, developmenttime is reducing and new processes are being intro-duced constantly. As a consequence, the traditionalrigid IS engineering processes are inadequate to providethe necessary support in new IS developments. Newmethods that are more exible and better adapted tothe situation of every IS development project must beconstructed. It is said that \Process engineering inthe �eld of information systems is the discipline to

*. Corresponding author.E-mail addresses: [email protected] (D.Samadhiya); [email protected] (W.C. Chang)

construct new processes from existing processes" [1].These focus on the design, construction and evaluationof processes, techniques and support tools for informa-tion system development [2]. Numerous developmentprocesses, based on a variety of paradigms, have beenproposed over the years. Of these, very few have beensuccessfully applied to the development of computerbased systems.

Since their introduction, various life cycle modelsand speci�c supporting techniques have played animportant role in building software systems [3]. Morerecently, the topic of software processes has receivedincreased attention from the software community. Asoftware design approach called \Evolution of SoftwareProcesses" is based on the emerging view that softwareprocesses - like software - also need to evolve, lest theybecome obsolete [4,5]. The aim of this evolution is toful�ll the needs of the people who perform the process,

D. Samadhiya and W.C. Chang/Scientia Iranica, Transactions B: Mechanical Engineering 22 (2015) 1616{1624 1617

and the developmental and organizational goals to beachieved. Another recent software design paradigmthat can be seen as a generalization of software processevolution is process engineering. While there is agreat overlapping of process engineering and processevolution activities, there are also some importantdivergences. Basically, process evolution is orientedmore towards the improvement of existing processesand process engineering more towards the constructionof new methods or processes.

Ralyte suggests that process engineering is facili-tated if the goal of the process can be determined. Inthis regard, the following questions have been raised [6]:

� How can assurances be provided that the processto be enhanced, extended, or restricted is a goodcandidate process?

� What are the chances that at the process engineeringintention stage, the process will have to be discardedbecause its adaptation is very di�cult?

� Should not further exploratory work be undertakenbefore committing to setting up process adaptationintentions?

The solution to these questions is in structural metasoftware engineering, but, the problem still arises thatno process is best in all the structures.

Figure 1 de�nes a process re-engineering processmodel that provides guidelines to re-engineer an ex-isting information system development process into areusable process. Figure 1 summarizes our process re-engineering approach. In this paper, Section 1 includesthe introduction of the theme. Sections 2 and 3 explainthe brief terminology of structural meta software en-gineering and operational meta software engineering.Section 4 illustrates the motivation and contributionof this paper, and Section 5 shows the preliminary

results of this contribution. The conclusions are foundin Section 6 of this paper.

2. Structural meta software engineering

Process Engineering (PE) and Structural Meta Soft-ware Engineering (SMSE) focus on formalizing the useof processes for systems development. The broaderterm, process engineering, is de�ned as an engineeringdiscipline that designs, constructs and adapts pro-cesses, techniques and tools for systems development; ade�nition analogous to the IEEE de�nition of softwareengineering [7]. In the real world, many informationsystems development processes exist, but no methodis best for all situations. Structural meta softwareengineering has been proposed for developing or tailor-ing information system developing processes for speci�cstructural projects [8]. Structural meta software engi-neering is \directed towards the controlled, formal andcomputer-assisted construction of structural processout of process fragments" [9]. A structural processis an information system engineering process tailoredand tuned to a particular structure. Structural pro-cesses are engineered in a formal and computer-assistedmanner out of standardized and proven building blocksstored in an electronic data base. These buildingblocks are called process storage and a process storageis a description of an information system engineeringprocess, or any coherent part thereof [10,11].

Figure 2 shows a structural meta software en-gineering process. In the introduction of processengineering, we discussed the development towardsstandardized information system engineering processes.Despite various attempts regarding the \uni�ed" or\universal" process, it is concluded that there is noprocess which is best in all situations [12-16]. Toanticipate this problem, various approaches have beenproposed, which are positioned in the so-called \Struc-

Figure 1. Process engineering approach.

1618 D. Samadhiya and W.C. Chang/Scientia Iranica, Transactions B: Mechanical Engineering 22 (2015) 1616{1624

Figure 2. Structural meta software engineering process.

tural Process Spectrum" [17]. Despite the large numberof proposals that exist, there is some dissatisfactionwith the notion of structure. Bucher is concerned aboutthe poor understanding of the notion of a structure [18],so, there is a need to �nd a way to reduce the numberof possible situations [19].

3. Motivation and contribution

As previously mentioned, Ralyte suggests that processengineering is facilitated if the intention of the processcan be determined. In this regard, the followingquestions have been raised [20]:

� How can assurances be provided that the process tobe enhanced, extended, or restricted is a good bestpossible process?

� What are the chances that at the process engineeringintention stage, the process will have to be discardedbecause its adaptation is very di�cult?

� Should not some further exploratory work be un-dertaken before committing to setting up processadaptation goals?

The solution of these questions can be found in thework to be undertaken, and the task to be per-formed rather than the structure of a process itself.Every computer software process having a full cycleconsisting of requirements, design and constructionengineering and current state of the art in struc-tural process engineering addresses the constructionengineering phase. The other two stages help usto undertake further `exploratory work' referred toby Ralyte. At the design stage, we introduce thenotion of process operationality and propose `processarchitecture' as an abstraction of this operationality.Thus, process engineering becomes Operational MetaSoftware Engineering (OMSE). Operationally close

process architecture is selected, adapted, enhanced,and restricted as needed. The task of constructionhandles the putting together of process features andof structuring the process. Thus, we see a di�erencebetween structural process engineering and operationalprocess engineering. Last, but not least, it is necessaryto explain requirement engineering, which is upstreamto design engineering. Here, we introduce the notionof a process goal. Once processes with similar goals tothose being engineered are found, a menu of processesto be adapted, enhanced, and restricted is determined.This is further re�ned in the design stage, wherearchitecture matching occurs. Again, a residue ofprocesses is found, and, at this stage, the architectureof the new process emerges as a set of connectedfunctions. Finally, this architecture is engineered frombuilding blocks taken from the residue.

It can be noted that progressive selection in therequirements and design stages include:

� The potential to assure that the method to beenhanced, extended, or restricted is a good possibleprocess;

� Rejection of inappropriate processes; those havingdissimilar goals and dissimilar architectures arerejected before the actual construction stage, which,therefore, reduces the possibility of rejection;

� Enough exploratory work is done before committingto process features.

Since project needs vary with projects, andprojects vary in their characteristics, the developmentof methods may require speci�c adaptations. There-fore, an engineering technique for this is required [21].We can now state the aim of the thesis. We wish tomove to goal process engineering in order to explorethe context of structural process engineering morefully. As a result, process selection for adaptation shall


be more appropriate and will assure that structuralprocess engineering is progressing purposefully. It willconsiderably reduce the chance of process rejection atlater stages. For this task, a 3-stage life cycle for goalprocess engineering is introduced.

In this life cycle, we introduce a process archi-tecture matching phase that corresponds to our viewof operational process engineering. Then, the notionof process architecture is explained through a meta-model, and a set of operations is de�ned that enablesarchitecture matching. The two layers; design and con-struction engineering, constitute the functional level ofprocess engineering. Once this is developed, we expectto put an intentional level on top of the operationallevel, which will further raise the abstraction in termsof which process requirements will be expressed.

4. Preliminary results

4.1. Process development life cycleAs shown in Figure 3, we have developed a processdevelopment life cycle for development. The require-ments for the engineering stage consist of intentionmatching. First, the goal of the process, To Be, iselicited. The goal matching process uses matchingsynonyms to identify intentionally similar processesthat reside in the process storage. These processesbecome possible methods for the second stage of thiscycle.

In the design engineering stage, the process engi-neer retrieves the architecture of each possible processfrom process storage. The subset of these componentsand inter-relationships that best meets the broad op-erational needs of the process To-Be is selected. Suchselections are made from all possible processes and aresynthesized together into the architecture of the desiredprocess. In the construction stage, the architecture ispopulated with instances of the process features neededin the process.

4.2. Process architectureWe have de�ned process architecture as an abstractionof the process that identi�es its components and inter-relationships to highlight the externally visible opera-tionality of the process. We use the class abstractionas a way of formally de�ning process architecture, asfollows:

Process architecture

= fprocessjprocess performs function Fg:The name, process architecture, re ects the operationperformed by the class of processes abstracted in thearchitecture.

The process architecture meta-model can be sum-marized as an architecture implemented as processorganization, and this organization shows the featuresof the process and their inter-relationships. An archi-tecture can be atomic or complex, and architecturescan be related to one another by links. These linksform a successor or predecessor relationship betweenarchitectures. Links are labeled by their executionproperties, Urgency and Necessity, respectively.

4.2.1. Process architecture matching processIn this design, the process engineer retrieves the processarchitecture of each possible process and these possibleprocesses are obtained from the goal level, as shownin Figure 3. The operational needs of this process arematched with the operational expressions of the can-didate processes and new desired process architectureis made. In this process, only those that are usefulfor the architecture should be selected and those thatare useless should be refused. The following operationshave been proposed to do this:

i) Given a named architecture, rename it;ii) Create a new architecture;

iii) Delete an existing architecture;

Figure 3. The process development life cycle.


iv) Nest, N architectures within another one;v) Un-nest architectures so that a nested architec-

ture becomes visible at a higher level of nesting;vi) Change a link type;

vii) Make a sequence of architectures by introducingan edge between them and de�ning their linktype. Link Type (LT) is used to elaborate thenature of the relationship between operationalprocesses. It consists of two properties, Urgencyand Necessity.

viii) Eliminate a sequence.

4.2.2. Process architecture meta-modelFor better understanding and to make the notion of aprocess framework more precise, we have developed ameta-model for it that identi�es the key concepts of aprocess framework and their inter relationships. It alsoforms a basis for deriving the graphical representationof a process framework in this model. One frameworkis related to other frameworks, and the relationshipbetween frameworks is de�ned in this meta-model. Thelink type is an attribute of this relationship, whichtakes on values from the set fIM, IC, DM, DCg that is:Ìmmediate Must', Ìmmediate Can', `Deferred Must',and `Deferred Can'. We have shown that a processframework can be implemented as one or more processorganizations. We found an 1:N relationship betweena process framework and process organisation. Table 1shows all types of link.

4.3. Operational process engineeringIt is now time to explain the di�erence betweenstructural meta software engineering and operationalmeta software engineering, as proposed. In thefragment based structural meta software engineeringproposal [22], there are two fundamental elements:

a) Products and their structures;b) Procedures and their execution order to develop the

products.

Products and their structure show that the in-terest is in the structure of the products. Similarly,since the structure of a process is largely determinedby the order of execution, the interest is in the processstructure. Therefore, we can conclude that structuralprocess engineering is centered round the structural

Table 1. Types of links.

Link type Urgency Necessity Abbreviation

1 Immediate Must IM2 Immediate Can IC3 Deferred Must DM4 Deferred Can DC

aspects of processes. This focus on engineering thestructure of processes de-emphasizes what the processdoes, and what task it is good for. In fact, determina-tion of whether or not the process structure can carryout the project task at hand is based on the experienceof the process engineer.

Operational process engineering puts the processstructure subordinate to process operationality. OMSEasks for an explicit determination and representa-tion of process operationality in the form of processarchitectures. It is only after the architecture hasbeen built that the issue of process structure is tobe considered. In this sense, SMSE occupies thedownstream, construction engineering stage of our lifecycle.

5. An example of draw an object chart schema

We aim to match the operational processes stored inthe process storage with the operational structure,To-Be. The core matching process is described inthis section. We start the operational meta softwareengineering process by (see Figure 4) creating a newoperational process using the operation, create (drawan object chart schema). At this moment, the op-eration consists of a rectangle with no other detailsavailable. The name of the created process is enteredin the rectangle. The values of the attributes andrelationships are as follows:

Name: Draw an object chart schemaEnvironment: Information systems, software devel-opmentInput: Application concepts, list of eventsOutput: Class, object, associationsConcepts used: Object model, statechartRelated to: NILImplemented as: SubprocessInteracts with: Application engineer/process engi-neerProcess type: Complex

The process engineer searches the process storageto retrieve the `Draw Object Model'. We look insidethe Ìdentify Class' and �nd two processes, ÌdentifyAttribute' and Ìdentify Service'. The process engineerfeels that the Ìdentify Class' is not useful but the

Figure 4. Create (draw) an object chart schema.


Figure 5. Partial operational process 1.

Ìdentify Attribute' and Ìdentify Service' are. Thefollowing sequence of matching operations is appliedand the results are shown in Figure 5.

- Un-nest (identify attribute, identify class);- Un-nest (identify service, identify class).

Now, other processes, i.e. Identify Object and IdentifyAssociation, are found to be irrelevant in building thedesired process. The process engineer now processes`Draw a Statechart Schema', as shown in Figure 4.The process engineer applies the following matchingoperations, one by one:

- Un-nest (identify state, draw statechart schema);- Un-nest (identify state change, draw statechart

schema);- Un-nest (identify triggers, draw statechart schema),- Un-nest (cluster states, draw statechart schema).

The result is shown in Figure 6.Links between operational process segments are

set up as follows:

- Sequence (identify state, identify attribute, im);- Sequence (identify attribute, identify state, dc);- Sequence (identify state, identify state change, DM);- Sequence (identify state change, identify state, DC).

At this moment, the operational process of the newprocess is as shown in Figure 7.

The process engineer now creates self loops toallow iteration. The result is shown in Figure 8.

- Sequence (identify state, identify state, DC);- Sequence (identify attribute, identify attribute, DC);- Sequence (identify state change, identify state

change, DC).

To identify triggers, we must use the Ìdentify Service'after the `Generate Event'. This is achieved as follows:

Eliminate (generate event, develop transaction,DM);

- Sequence (generate event, identify service, DM);- Sequence (identify service, develop transaction,

DM);- Sequence (identify state change, identify triggers,

DM).

The result is shown in Figure 9.To complete the integration of the Òbject Model'

and `Statechart' additional operational processes, ad-ditional links are de�ned, as follows:






Figure 10. The desired operational process: Draw an object chart schema.

- Sequence (identify triggers, cluster states, DM);- Create (annotate state);- Sequence (identify triggers, annotate state, DM);- Create (de�ne �ring post condn spec);- Sequence (de�ne �ring post condn spec, de�ne �ring

post condn spec, DC);- Sequence (identify triggers, de�ne �ring post condn

spec, DM).

In Figure 10, the shaded operational processes showthe new operational process needed for introduction toachieve the objective of `Objectchart'.

6. Conclusion and future work

A process organization represents process features andtheir interconnections. The interest here is in processconcepts, inter-relationships between concepts, con-straints, heuristics, guidelines and other such featuresof a process. It can be seen that process organizationrepresents the structural aspects of processes. Alterna-tively, it de�nes the input to be given to a computeraided method engineering tool to engineer/implementthe required process. We have selected the genericprocess model for representation of process organiza-tions.


For the future, in order to �nalize construction-design stage interaction, we are also developing a set ofoperations for performing organization matching. Thiswill allow us to adapt process organizations determinedby architecture matching our structural needs.

Thereafter, we propose to develop the goal level.The process goal refers to the goal that the processful�ls. We shall develop the process goal meta-modeland provide a precise de�nition of a goal. We aim toassociate a goal with each process and, as for archi-tecture matching, develop the process goal matchingoperations. Finally, the link between the goal andarchitecture levels will be de�ned. Thus, the entire lifecycle of Figure 3 will be covered. Once tool supportis available, we will experiment with our technique toestablish its usefulness.

References

1. Harmsen, F. and Saeki, M. \Comparison of fourmethod engineering languages", In Proceedings ofthe IFIP TC8, WG8.1/8.2 Working Conference onMethod Engineering on Method Engineering: Princi-ples of Method Construction and Tool Support, SjaakBrinkkemper et al., Eds., Atlanta, Georgia, UnitedStates, pp. 209-231 (Jan. 1996).

2. Brinkkemper, S. \Method engineering: Engineering ofinformation systems development methods and tools",Journal of Information & Software Technology, 38, pp.275-280 (1996).

3. Royce, W.W., Managing the Development of LargeSoftware Systems: Concepts and Techniques, Proceed-inas WESCON (1970).

4. Bandinelli, S., Fuggetta, A., Lavazza, L., et al. \Mod-eling and improving an industrial software process",IEEE Trans. Soft. Engg, pp. 440-454 (1995).

5. Bassili, V., Zelkowitz, M., McGarry, F., et al. \SEL'ssoftware process - improvement program", IEEE Soft-ware, 12, pp. 83-87 (1995).

6. Ralyt�e, J., Deneck�ere, R. and Rolland, C., Towardsa Generic Model for Situational Method Engineering,Proc. CAiSE 2003, J. Eder and M. Missiko�, Eds.,LNCS 2681, Springer, pp. 95-110 (2003).

7. Brinkkemper, S., Personal Email Communication toAuthors (29 Sept. 2006).

8. Brinkkemper, S. \Method engineering: Engineering ofinformation systems development methods and tools",Information and Software Technology, pp. 275-280(1996).

9. Harmsen, F., Situational Method Engineering, MoretErnst & Young (1997).

10. Heym, M. \Method engineering: Speci�cation andintegration of development methods for informationsystems", [in German: Methoden-Engineering: Spez-i�kation und Integration von Entwicklungsmethoden

f�ur Informationssysteme], Dissertation, Hochschule St.Gallen, Switzerland (1993).

11. Heym, M. and �Osterle, H. \Computer-aided method-ology engineering", In Information and Software Tech-nology, 35, pp. 345-354 (1993).

12. Malouin, J.L. and Landry, M. \The mirage of universalmethods in systems design", In Journal of AppliedSystems Analysis, 10, pp. 47-62 (1983).

13. Humphrey, W.S., Managing the Software Process,Addison-Wesley, Reading, MA (1990).

14. Olle, T.W., Hagelstein, J., MacDonald, I.G., Rolland,C., Sol, H.G., van Assche, F.J.M. and Verrijn-Stuart,A.A. Information Systems Methodologies - A Frame-work for Understanding, 2nd Edn., Addison-Wesley(1991);Vessey, I. and Glass, R.L. \Applications-basedmethodologies", In Information Systems Management,pp. 53-57 (Fall 1994).

15. Purba, S., Sawh, D. and Shah, B. How to Managea Successful Software Project - Methodologies, Tech-niques, Tools, John Wiley & Sons, New York (1995).

16. Parkinson, J., 60 Minute Software - Strategies forAccelerating the Information Systems Delivery Process,John Wiley & Sons, New York (1996).

17. Harmsen, F., Brinkkemper, S. and Oei, H. \Situ-ational method engineering for information systemprojects", In Methods and Associated Tools for theInformation Systems Life Cycle, T.W. Olle, and A.A.Verrijn Stuart, Eds., Proceedings of the IFIP WG8.1Working Conference CRIS'94, North-Holland, pp. 169-194, Amsterdam (1994).

18. Bucher, T., Klesse, M., Kurpjuweit, S. and Winter,R. \Situational method engineering - On the di�eren-tiation of \context" and \project type"", SituationalMethod Engineering 2007, pp. 33-48 (2007).

19. B�orner, R. \Applying situational method engineeringto the development of service identi�cation methods",16th Americas Conference on Information Systems,Lima, Peru, forthcoming, Paper 18, pp. 1-10 (2010).

20. Ralyt�e, J., Deneck�ere, R. and Rolland, C. \Towardsa generic model for situational method engineering",Proc. CAiSE 2003, J. Eder and M. Missiko�, Eds.,LNCS 2681, Springer, pp. 95-110 (2003).

21. Anat, A. and Iris, R.B. \Semi-automatic composi-tion of situational methods", Journal of DatabaseManagement, 22(4), pp. 1-29 (2011). doi:10.4018/jdm.2011100101

22. Brinkkemper, S., Saeki, M. and Harmsen, F., AssemblyTechniques for Method Engineering, Proc. CAiSE 98,B. Pernici and C. Hanos, Eds., LNCS 1413, Springer,pp. 381-400.

Biographies

Durgesh Samadhiya obtained a PhD degree from


Chung Hua University, Taiwan. He has publishedand presented a number of papers in internationaljournals and at conferences. He has made signi�-cant contributions to the area of software engineeringand networking, and completed many projects in this�eld.

Wen-Chih Chang is Associate Professor in the De-partment of Information Management at Chung HuaUniversity, Taiwan. His research interests include e-learning, game-based learning, social network, learningbehavior analysis, and institutional research and dataanalysis.

Meta software engineering for information system...

Documents

Transcript of Meta software engineering for information system...