ideas for the next generation process authoring toolusers.abo.fi/peholmst/thesis.pdf · master’s...

Master’s Thesis

Ideas For the Next GenerationProcess Authoring Tool

Petter Holmström

May 6, 2009

Åbo Akademi UniversityFaculty of Technology

Department of Information Technologies

Copyright © 2008, 2009 Petter Holmström.E-mail address: [email protected] no: 29786Supervisor: Prof. Ivan PorresInstructor: Jeanette Heidenberg

This thesis has been written using Aquamacs on a MacBook Pro and type-set in X ETEX using the KOMA-script report document class. The figures havebeen created using Inkscape.

Abstract

An engineering tool that is growing more and more important every day is thesoftware process. Processes as an engineering tool are nothing new and havebeen around for other engineering disciplines for some time already. However,the unique characteristics of software engineering impose special requirementson the processes used to engineer software.

The people who have the best understanding of what parts of the processwork and what parts do not are the software developers. Therefore, it is im-portant that the experiences of and lessons learned by the developers are fedback into the process description in order to improve the process and preventfuture projects from repeating mistakes. In other words, the process descrip-tion should actually act as a knowledge repository.

The problem with this approach is that many process authoring tools are cur-rently designed around the traditional process engineering principle, where adedicated team of process developers develop the process and then release itto the software engineering teams for adoption. In order to fully support acollaborative approach to process authoring, the tools need to change.

This thesis will discuss software processes, software process descriptions andthe requirements imposed on them. It will evaluate a set of existing processauthoring tools with regard to the requirements and provide some ideas onhow the tools could be improved.

Acknowledgements

I would like to thank Jeanette Heidenberg, my instructor at EB, and profes-sor Ivan Porres, my supervisor at Åbo Akademi University, for their help andsupport during the writing of this thesis. I would also like to thank the peopleat EB, especially Martin Dusch, for their co-operation during the requirementscollection and tool evaluation.

v

Contents

1 Introduction 11.1 Software Engineering History . . . . . . . . . . . . . . . . . . . . 11.2 The Software Crisis . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Why Software Engineering is Difficult . . . . . . . . . . . . . . . 51.4 The Background and Structure of This Thesis . . . . . . . . . . . 7

2 Introducing Software Processes 92.1 The Software Life-Cycle . . . . . . . . . . . . . . . . . . . . . . . 92.2 The Software Process . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Process Model Examples . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 The Code-and-Fix Model . . . . . . . . . . . . . . . . . . 122.4.2 The Waterfall Model . . . . . . . . . . . . . . . . . . . . . 132.4.3 The Spiral Model . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Software Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6 The Advantages of a Predefined Process . . . . . . . . . . . . . . 222.7 Process Frameworks and Tailoring . . . . . . . . . . . . . . . . . 222.8 A Software Process Example: Extreme Programming . . . . . . 23

3 Process Description Requirements 273.1 What is a Process Description? . . . . . . . . . . . . . . . . . . . 273.2 The Human Factor . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3 The Requirements Collection Procedure . . . . . . . . . . . . . . 293.4 Process Documentation Perspectives . . . . . . . . . . . . . . . . 30

3.4.1 The User Perspective . . . . . . . . . . . . . . . . . . . . . 303.4.2 The Project Manager Perspective . . . . . . . . . . . . . . 333.4.3 The Author Perspective . . . . . . . . . . . . . . . . . . . 333.4.4 The Customer Perspective . . . . . . . . . . . . . . . . . . 353.4.5 The Machine Perspective . . . . . . . . . . . . . . . . . . 35

4 Evaluation of Existing Process Authoring Tools 374.1 Introducing the Contestants . . . . . . . . . . . . . . . . . . . . . 37

vii

Contents

4.1.1 The In-house Tool . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 EPF Composer . . . . . . . . . . . . . . . . . . . . . . . . 384.1.3 Rational Method Composer . . . . . . . . . . . . . . . . . 394.1.4 IRIS Process Author . . . . . . . . . . . . . . . . . . . . . 40

4.2 The Tool Evaluation Procedure . . . . . . . . . . . . . . . . . . . 424.3 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.1 Collaboration Issues . . . . . . . . . . . . . . . . . . . . . 444.3.2 Synchronization and Version Handling Issues . . . . . . 444.3.3 Meta-Model and User Interface Issues . . . . . . . . . . . 464.3.4 Integration Issues . . . . . . . . . . . . . . . . . . . . . . . 47

5 Improving the State of the Practice 495.1 Wiki-Based Process Authoring . . . . . . . . . . . . . . . . . . . 495.2 Model Aware Diff-and-Merge . . . . . . . . . . . . . . . . . . . . 505.3 Extendable Meta-Model . . . . . . . . . . . . . . . . . . . . . . . 515.4 Scalable User Interface . . . . . . . . . . . . . . . . . . . . . . . . 515.5 Extendable Import/Export Engine . . . . . . . . . . . . . . . . . 535.6 A Proposal for a New Process Authoring Tool . . . . . . . . . . . 54

5.6.1 Overall Architecture . . . . . . . . . . . . . . . . . . . . . 545.6.2 The Process Repository . . . . . . . . . . . . . . . . . . . 555.6.3 A Dynamic and Filterable User Interface . . . . . . . . . 575.6.4 Front-end Implementation Approaches . . . . . . . . . . 60

6 Conclusion 636.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

viii

List of Figures

2.1 The high-level software life-cycle . . . . . . . . . . . . . . . . . . 92.2 Process model types . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 The code-and-fix model . . . . . . . . . . . . . . . . . . . . . . . 122.4 The original waterfall model [19, p330] . . . . . . . . . . . . . . . 142.5 The modified waterfall model [19, p338] . . . . . . . . . . . . . . 162.6 The spiral model [7, p64] . . . . . . . . . . . . . . . . . . . . . . . 172.7 A spiral cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8 The relations between roles, tasks and artifacts . . . . . . . . . . 212.9 The “Develop Solution Increment” activity of OpenUP . . . . . 212.10 A process framework with two tailored process instances . . . . 232.11 XP compared to the Waterfall model and iterative development

[4, p70] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 The relations between normative, collaborative and customized(tailored) process descriptions . . . . . . . . . . . . . . . . . . . . 34

4.1 The delivery process editor of EPF Composer . . . . . . . . . . . 404.2 The process tailoring perspective of Rational Method Composer 414.3 A library package diagram in IRIS Process Author . . . . . . . . 42

5.1 Scaling and filtering of the user interface . . . . . . . . . . . . . . 525.2 A schematic figure of an export/import engine with three export

plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.3 The high-level architecture of a new process authoring tool . . . 545.4 The high-level architecture of a process repository . . . . . . . . 555.5 The high-level design of a configurable UI builder . . . . . . . . 585.6 A mock-up of the generated user interface . . . . . . . . . . . . . 595.7 Schematic overview of the rich client approach . . . . . . . . . . 615.8 Schematic overview of the wiki approach . . . . . . . . . . . . . 62

ix

List of Figures

x

List of Tables

3.1 Overview of the process description requirements . . . . . . . . 313.2 Mapping to Kellner’s requirements . . . . . . . . . . . . . . . . . 36

4.1 Tool evaluation results . . . . . . . . . . . . . . . . . . . . . . . . 43

xi

List of Tables

xii

Terminology

Adobe Air A platform for building rich Internet applications that run outsidethe browser on multiple operating systems. See http://www.adobe.com/products/air.

Artifact A tangible (or sometimes intangible) thing used, modified or producedby a task. See Section 2.5 on page 20.

BIRT Eclipse Business Intelligence and Reporting Tools, a reporting frame-work. See http://www.eclipse.org/birt.

CDO Connected Data Objects, a three-tiered solution for distributed sharedEMF models . See http://wiki.eclipse.org/CDO.

Collaborative process framework A version of a process framework that isupdated by both the process authors and the process users. See Sec-tion 3.4.1 on page 30.

EMF Eclipse Modeling Framework, a framework for designing, storing andaccessing models. See http://www.eclipse.org/modeling/emf.

EPC EPF Composer, a software process authoring tool based on EPF. See Sec-tion 4.1.2 on page 38.

EPF Eclipse Process Framework, a software process engineering framework.See Section 4.1.2 on page 38.

Golden hammer A tool or technology that is considered to be the perfect so-lution to any problem and hence is forced onto every possible project byits users. Another term describing the same phenomenon is silver bullet.See Section 1.3 on page 5.

IPA IRIS Process Author, a commercial web-based process authoring tool.See Section 4.1.4 on page 40.

IPC IRIS Process Central, a process repository for IPA. See Section 4.1.4 onpage 40.

xiii

Terminology

JavaFX A platform for building and delivering rich Internet applications, amongother things. See http://www.sun.com/software/javafx.

JEE Java Enterprise Edition, a framework for developing service oriented ap-plications and web applications in Java. See http://java.sun.com/javaee.

Normative process framework An officially approved process framework thatis used as the basis for new software projects. See Section 3.4.3 on page 33.

OSGi A dynamic module system for Java. See http://www.osgi.org.

Predefined process A software process that follows a predefined plan insteadof being ad libbed. Process instances and process frameworks are bothpredefined processes. See Section 2.6 on page 22.

Process activity A sequence of related tasks, performed to achieve a greaterpurpose. See Section 2.5 on page 20.

Process authoring The activity of creating and refining a software process de-scription. See Section 3.1 on page 27.

Process authoring tool A tool used to create, publish and maintain process de-scriptions. See Section 3.4.3 on page 33.

Process description A concrete representation of a process. See Section 3.1 onpage 27.

Process framework A set of ready-made process models and software meth-ods that can be used to create customized process instances. See Sec-tion 2.7 on page 22.

Process instance A process that is based on a process framework and has beentailored to fit the needs of a specific project. See Section 2.7 on page 22.

Process meta-model A process meta-model describes the structure of the repos-itory used by a process authoring tool to store process descriptions. SeeSection 3.4.5 on page 35.

Process model An abstract representation of a software process that specifiesthe order of the activities involved in the process and the transition cri-teria for progressing from one activity to the next. See Section 2.3 onpage 11.

xiv

Terminology

Process repository A knowledge base containing process models, methods de-scriptions, best practices, previous experiences, etc. See Section 3.4.1 onpage 30.

RMC Rational Method Composer, a commercial version of EPC. See Section 4.1.3on page 39.

Role A set of related skills, competences and responsibilities. Roles performtasks and are responsible for artifacts. See Section 2.5 on page 20.

Software life-cycle The path of stages that a software system traverses duringits lifetime. See Section 2.1 on page 9.

Software method A set of tasks, roles and artifacts required to solve a specificproblem. See Section 2.5 on page 20.

Software process The ordered set of activities and associated results that areperformed by humans or machines throughout the software life-cycle inorder to transform the system from one state to another. See Section 2.2on page 10.

SPEM Software and Systems Process Engineering Meta-Model, a meta-modelfor modeling process models and software methods. See Section 2.5 onpage 20.

Task An assignable unit of work with a clear goal and step-by-step directionson how to achieve it. See Section 2.5 on page 20.

xv

Terminology

xvi

1 Introduction

This chapter begins with a discussion of the history of softwareengineering1 in general and the software crisis in particular, as thisevent gave birth to software engineering as an independentengineering discipline. Then follows a discussion of the challenges thatsoftware engineers are faced with today. Finally, the background andstructure of this thesis are presented.

1.1 Software Engineering History

In the early years of the “computer age”, around the times of World War II, thecomputers were mainly used for ballistics tables, troop deployment data andsecret codes. There was no real software in the sense of today; the comput-ers were programmed externally using wires, connectors and plug-boards. Asthere were no high-level programming languages, all instructions had to be en-tered in pure machine code. Although the computers had memories, they wereonly used to store data. Consequently, every time the computer was needed tosolve a different problem, the users had to rewire the entire machine by hand,involving the resetting of thousands of separate switches.

Software in its contemporary meaning emerged through the stored-programcomputer model, invented in 1946 by John Von Neumann. Von Neumann pro-posed a design in which the operation instructions would be encoded in binaryand stored in the memory together with the data. When the computer neededto be reprogrammed, a different set of instructions would be read into the mem-ory and executed, without any external rewiring. This design would later bereferred to as the Von Neumann architecture and is still used in virtually all mod-ern computers. Shortly thereafter, in 1949, the first pseudo-code language2 wasinvented by John Mauchly. It was called Short Code and was developed for theBINAC, one of the first successful stored-program computers.

1Unless stated otherwise, this summary is based on Section 1.4 in [20] and Chapter 2 in [21],respectively.

2At the time, these languages were called pseudo-codes; they are not to be confused with thecontemporary meaning of the word.

1

1 Introduction

Although Short Code and other pseudo-code languages clearly simplifiedthe programming process, they were often implemented with pure interpretersand hence ran much slower than pure machine code. However, this sacrificeof execution time was tolerated mainly due to the lack of floating-point hard-ware in the available computers; all floating-point operations had to be sim-ulated in software. This process required a significant amount of executiontime, making the interpretation overhead relatively insignificant in compari-son3. All this changed with the introduction of the IBM 704 computer in 1954,which had hardware support for floating-point processing. Consequently, anew programming language was needed.

The development of Fortran, the first widely accepted compiled high-levelprogramming language, commenced before the announcement of the IBM 704.Implementation began in 1955 and in April 1957, the first compiler was re-leased. Soon other high-level languages followed, such as LISP and ALGOL 58in 1958 and COBOL in 1960. Around this time, the hardware costs had beenreduced to a level where small and medium-sized businesses, colleges and gov-ernment agencies suddenly could afford to purchase a computer. In addition,the introduction of high-level languages made it possible for ordinary users tosolve problems on a computer. Detailed knowledge in electrical engineeringwas no longer required and hence the programmer-occupation was born.

In the mid-1960s, the first minicomputers4 arrived. They were built from in-tegrated circuits and were much smaller and cheaper than their predecessors.Consequently, about a decade later, computers were no longer a rarity. Thisperiod in time also saw the appearance of time-shared operating systems, thebirth of the software industry and the development of the popular program-ming languages Pascal and C.

As computing power kept increasing, so did the domain of problems solv-able by a computer. This resulted in software being far more complex thanthe programmers and programming methods could handle. Projects exceededtheir schedules and budgets, the resulting software was unreliable and verydifficult to maintain. In 1968, the situation had become so serious that a con-ference was held in Garmisch, Germany, to discuss what was then called the‘software crisis’ or ‘software gap’. It was at the same conference that the termsoftware engineering was coined [23, 17]. This subject is discussed later in thischapter.

Although the computers had indeed shrunk in size, they were still around

3In spite of this, many programmers still preferred the efficiency of pure machine code.4For example, the PDP-1 manufactured by the Digital Equipment Corporation in 1963.

2

1.2 The Software Crisis

the size of a desk. About ten years after the birth of minicomputers, in January1975, the world’s first microcomputer appeared — the Altair 8800. The desk-sized computers now became desktop computers and started to appear on thedesks of office workers.

During the following ten years, many advances were made in both the hard-ware and the software industry. In addition to the microcomputer, the firstcomputer networks and embedded systems appeared during this period intime. Previously dominated by accounting and statistical packages, the soft-ware industry began to produce a large variety of packages, including spread-sheets, databases, electronic mail programs and drawing programs. The in-troduction of graphical user interfaces and the concept of user-friendly sys-tems further increased the user population. This period also saw the appear-ance of the first object-oriented programming languages, such as Smalltalk andC with Classes.

Starting in the mid-1980s, constant change and rapid evolvement became anatural part of the computer industry. This is the era we are currently livingin and it has seen countless advances in technology on all levels, such as su-percomputers and parallel processors, laptops and handheld computers, wire-less computing, world-wide networks, distributed systems, multimedia user-interfaces, massive external data storage devices, high-resolution graphics, vi-sualization, virtual reality, etc.

In only 60 years, computers have evolved from unreliable, slow, building-size machines to what we have today, with new technologies emerging all thetime. Information technology is now a natural part of virtually all trades andplay an important part in people’s everyday lives. With the introduction ofnew technologies and the constant demand for new solutions, the systems keepgetting bigger and more complicated all the time. This in turn imposes heavyrequirements on the software developers and the software engineering pro-cesses.

1.2 The Software Crisis

The 1960s saw a large increase in the number of installed computers in manydifferent areas of society. In 1968, there were over 10,000 installed computersin Europe alone, with the number increasing at a rate of 25 to 50 per cent peryear [17, p15]. This may not seem much by today’s standards, but consideringthat computers were mainly used for solving scientific problems only a decadeearlier, it is a significant change.

3

1 Introduction

As the number of computers increased, so did the demands on the softwarerunning on the computers. For example, when a European general purposecomputer manufacturer often had less than 50 software programmers in 1958,a decade later the number was around 1,000-2,000 people [17, p15]. However,as the demands grew, so did the gap between what was expected from thesecomplex systems and what was normally achieved. This ‘software gap’ — or‘software crisis’ as some chose to call it — was one of the subjects of a softwareengineering conference held in Garmisch, Germany, on October 7 - 11, 1968.

Before beginning, it is worth mentioning that certainly not all systems wereexperiencing problems, as this quote by Buxton [17, p119] states:

“… 99 percent of computers work tolerably satisfactorily. … There arethousands of respectable Fortran-oriented installations using many differ-ent machines and lots of good data processing applications running quitesteadily. … The matter that concerns us is the sensitive edge, which issocially desperately significant.”

Another quote, made by Kolence [17, p121], also clarifies this point:

“The basic problem is that certain classes of systems are placing demandson us which are beyond our capabilities and our theories and methods ofdesign and production at this time. There are many areas where there is nosuch thing as a crisis — sort routines, payroll applications, for example.It is large systems that are encountering great difficulties. We should notexpect the production of such systems to be easy.”

As Kolence stated, the software crisis mainly affected large projects on manydifferent levels. Projects were running seriously behind schedule and the pro-duced code was error-prone, difficult to maintain and performed poorly. In ad-dition, the software costs kept rising whereas the hardware costs kept dropping[23]. As Edsger W. Dijkstra put it in his speech “The Humble Programmer” in1972 [10, p863]:

“As long as machines were the largest item on the budget, the program-ming profession could get away with its clumsy techniques, but that um-brella will fold very rapidly.”

Some possible causes behind the software crisis were discussed during theconference. Interestingly, many of these causes still apply to the software engi-neering industry today. This rather apt analogy coined by Kinslow [17, p122]summarizes the key causes:

4

1.3 Why Software Engineering is Difficult

“I have never seen an engineer build a bridge of unprecedented span, withbrand new materials, for a kind of traffic never seen before — but that’sexactly what has happened on OS/360 and TSS/3605.”

Unlike today, there were no standards or production-ready development plat-forms to conform to. Software manufacturers kept inventing new, complexsystems, utilizing the latest hardware technologies instead of improving theexisting systems and making them work properly. One could say that thesystems were being developed for research instead of practical use. In prac-tice, this meant that the software manufactures continually concentrated onresearch when they should have concentrated on producing working softwarefor the waiting customer. According to David and Fraser [17, p122], this mix-ing of research, development and production was a root cause of the softwaregap.

Engineering is about making things work by applying theories, methods andtools where appropriate, in a systematic and organized manner. Looking at thecauses of the software gap in retrospect, they could be summed up into one keycause: there was no real software engineering discipline.

Much has happened in the past 40 years and the software industry is not ex-periencing a crisis any more. There is a better understanding of both softwareitself and the activities involved in software development. There are bettertools and methods for solving common problems. There are software processesthat take the entire software life-cycle into account, from requirements analy-sis to post-release maintenance. High-risk research is conducted in softwarelaboratories, separate from any production projects. In short, software devel-opment has become an engineering discipline in itself.

1.3 Why Software Engineering is Difficult

People who have even a modest experience in software programming knowhow easy it is to get it wrong. Many are the programmers who have spentcountless hours struggling with bugs under the weight of a rapidly approach-ing deadline, wishing either that they had designed the system in some otherway or that they had a less complicated occupation such as a clerk in a smallgrocery store.

Software engineering as an independent engineering discipline is rather young.However, in spite of the advances, many software projects still struggle with

5OS/360 and TSS/360 were two operating systems developed by IBM in the 1960s.

5

1 Introduction

problems not too different from those experienced during the software crisis.There are several reasons for this, of which the following six are the most re-markable:

First of all, there is the very nature of software itself. It is abstract and intan-gible, not constrained by materials nor governed by physical laws. This is bothan advantage and a disadvantage: On one hand, there are no physical limita-tions on the potential of software. On the other hand, the lack of constraintsmakes it too easy to write extremely complex software that is very difficult tounderstand [23].

Secondly, there is no such thing as a steady-state in software engineering.New technologies evolve constantly, rapidly pushing the bleeding edge furtherand further. What Dijkstra said in 1972 [10, p865] still applies today, over 30years later:

“Programming will remain very difficult, because once we have freed our-selves from the circumstantial cumbersomeness, we will find ourselves freeto tackle the problems that are now well beyond our programming capac-ity.”

Thirdly, every software project is unique. In spite of fancy frameworks anddesign patterns, there are always some parts of the system that have never beendone before. These parts provide the greatest risks to the project, but also thegreatest value if implemented successfully.

Fourthly, systems are increasingly required to operate as distributed systemsacross very heterogeneous networks, in close integration with existing legacysystems written in different programming languages [23]. Thus, the softwaremust be made flexible enough to cope with this heterogeneity, taking into ac-count that the systems developed today will be the legacy systems with whichthe systems of tomorrow will be integrated.

Fifthly, we live in a very dynamic world that is constantly changing. Re-sponding rapidly to change is crucial for many businesses. Consequently, theirsupporting software systems must change equally rapidly [23].

Finally, there are no “golden hammers”6. There will always be fanatics whotry to force their favorite technology or process or tool onto every project theyundertake. Although sometimes successful, projects using golden hammershave a high risk of failing. For example, it is possible to use a hammer for in-serting a screw into a wall, although it would have been much easier to use a

6For a person with a golden hammer, every problem looks like a nail.

6

1.4 The Background and Structure of This Thesis

screwdriver (the results would have been better, too). The importance of select-ing the right tools for the job should be an undoubted part of any engineeringdiscipline.

1.4 The Background and Structure of This Thesis

An engineering tool that is growing more and more important every day is thesoftware process. Processes as an engineering tool are nothing new and havebeen around for other engineering disciplines for some time already. However,the unique characteristics of software engineering impose special requirementson the processes used to engineer software.

The time of traditional process engineering, where a dedicated team of pro-cess developers decide how the process should evolve, is coming to an end.The software process of the future is the result of a collaborative effort involv-ing process developers, software engineers, customers or any other person orteam that is affected by the process.

In the summer of 2008, the Finnish-based, multi-national, automotive andwireless technology company EB7 requested an evaluation of different processauthoring tools on the market, with the intention of selecting a new authoringtool for their internal software engineering and project management processes.One open-source, two commercial and one in-house tool were included in theevaluation. The result of this evaluation was an internal company report, onwhich this thesis is based. In the text, this evaluation is referred to as the “com-pany case study”.

The structure of this thesis is as follows. It begins with a discussion of whatsoftware processes actually are, how they can be represented and what ad-vantages they provide. It then introduces the process description concept andpresents some requirements imposed on both the content of the process de-scription and on the tools used to author the description. Based on these re-quirements, four different process authoring tools are evaluated and the en-countered issues described. Finally, it discusses some possible solutions to theissues and concludes with a summary and some pointers to related work.

7http://www.elektrobit.com

7

1 Introduction

8

2 Introducing Software Processes

This chapter introduces the software process and its related concepts:process models, software methods, predefined software processes,process frameworks and tailoring. Some examples of commonsoftware processes and process models are also included.

2.1 The Software Life-Cycle

Before beginning the discussion of software processes, the software life-cycle hasto be considered. Note, however, that the software life-cycle is quite a vagueconcept and many authors use it to refer to quite different things. For example,the life-cycle referred to by McCracken and Jackson in their article “Life-CycleConcept Considered Harmful” [16] is actually the waterfall model, which isdiscussed in Section 2.4.2. In this thesis, the software life-cycle consists of thegeneral stages or phases that a software system passes through during its wayfrom specification (“the cradle”) to legacy (“the grave”), as seen from a veryhigh-level perspective (see Figure 2.1).

A software system always begins with an idea, a purpose for the system. Ifdeemed profitable or realistic, this idea is then further developed and definedinto a specification. Based on the specification, the software system is devel-oped (i.e. designed and implemented). Before it is released to production use,it is tested and verified in order to make sure that the software in fact works

Figure 2.1: The high-level software life-cycle

9


according to its specification. Please note, that these activities need not be car-ried out in this particular order — they can be carried out in parallel, repeatedor even left out completely.

After the system has been released and has left the development phase, it en-ters the maintenance phase. During this phase, the software evolves togetherwith the world around it (as mentioned in Chapter 1). Sometimes, the bor-der between the development phase and the maintenance phase can be quitediffuse.

The length of the maintenance phase could be everything from a few days toseveral decades, depending on the scope of the software. However, eventuallythe system reaches its end-of-life and enters its last phase, namely the legacyphase. From here on, the system is no longer supported nor is it in productionuse.

2.2 The Software Process

A software system does not evolve on its own. A software system always con-sists of the result of activities performed by people or machines. The output ofone of the activities is normally used as input for another, further refining theresult in some way. Consider this short example:

• A programmer writes some source code.

• The source code is passed to a compiler, that translates it into binary code.

• The binary code is passed to a tester, who runs the program on a computerand discovers a bug.

• The bug is reported to the programmer, who improves the source code,etc.

These activities might follow a predefined plan, or they might be made upas the development progresses. In either case, this ordered set of activities andassociated results that are performed throughout the software life-cycle in or-der to carry the system from one phase to another is called a software process1.

In the previous example, the human activity “write code” produces the re-sult “source code”. The machine activity “compile” in turn takes the sourcecode as input and produces the result “binary code”. Every completed activity

1Also called a software engineering process or a software development process.

10

2.3 Process Models

and produced result causes the system to evolve in some way. However, it isimportant to remember that the evolution need not only go forward (e.g. fromgood to better) — it might just as well go backward (e.g. from good to worse).

Basically, there are as many software processes as there are software systems.Every software process starts when the life-cycle starts and ends when the life-cycle ends. A single software process might even span several different soft-ware projects that involve the same system (e.g. initial development, addingnew features after the initial release, etc).

2.3 Process Models

In order to make it easier to analyze and compare different software processesto one another, the concept of software process model has been introduced. Thereare some inconsistencies concerning the use of software process terminologyin literature. For example, Boehm [7] and Sommerville [23] define the processmodel concept in different ways. Therefore, the definitions by Boehm are usedin this thesis unless stated otherwise.

A software process model is an abstract representation of a software processfrom a certain perspective. More specifically, a software process model speci-fies the order of the activities involved in the development process and the tran-sition criteria for progressing from one activity to the next. That is, it containscompletion criteria for the current activity and choice and entrance criteria forthe next. Casually put, a process model addresses the questions What shall wedo next? and How long shall we continue to do it? [7].

Even though all software processes are unique, most of them share some basicsimilarities. Generally, it is possible to model a software process using eithera sequential process model, an iterative process model, or a combination ofboth. Sommerville [23] refers to these process model types as process paradigmsand also includes a third paradigm, namely component-based software engineering(CBSE). However, as CBSE-processes can be modeled using the two previouslymentioned model types, CBSE will not be discussed in this thesis.

In a sequential process model, every activity is performed in a clearly spec-ified order and only once. Thus, when an activity is completed there is nomoving back. When all activities have been completed, the system is finished.

An iterative process model resembles the iterative methods in numerical anal-ysis. Instead of creating the entire system at once, the activities are divided intoiterations that gradually refine the system. This makes it possible to start thedevelopment in an early stage when only an abstract specification of the system

11


(a) A sequential model (b) An iterative model

Figure 2.2: Process model types

Figure 2.3: The code-and-fix model

is available. The result of an iteration is normally a working product that canbe demonstrated to the customer. The customer feedback is then used as inputfor the next iteration, etc. Sometimes, iterative process models are referred toas incremental process models, as the system grows (“is incremented”) aftereach iteration.

The difference between sequential and iterative process models is depictedin Figure 2.2. Three different process model examples are presented in Sec-tion 2.4. The waterfall process model is a good example of a sequential processmodel. The spiral process model is a good example of a combination of an it-erative and a sequential model. The code-and-fix model is an example of a bad— but nonetheless iterative — process model. Finally, Extreme Programming,presented in Section 2.8, is a good example of an iterative process model.

2.4 Process Model Examples

This section presents some examples of process models that are — or have been— commonly used in software development. Although there are several tochoose from only three of them have been included, as they are all quite differ-ent from each other.

2.4.1 The Code-and-Fix Model

The oldest process model used in the early days of software development —and by too many software developers today as well — is the code-and-fix model.It is also one of the simplest process models, as it only consists of two steps (seeFigure 2.3):

12


1. Write some code

2. Fix the problems in the code and repeat

Seen in the context of the software life-cycle presented in Section 2.1, devel-opers using this model would begin by doing some coding and then worryabout the other matters, such as specification, design, verification and mainte-nance. Boehm [7] lists three primary difficulties with this model that have beendiscovered.

First of all, the code became poorly structured. After a few fixes the codewas so bloated2 that subsequent fixes became very expensive, mainly due tothe complete lack of design activities prior to coding.

Secondly, the software seldom matched the needs of its users. Frequently, thesoftware was either rejected all together or expensively redeveloped — regard-less of whether it was well-designed or not. Clearly, some kind of specificationand requirements collection activities would have been needed.

Finally, it became expensive to fix bugs and introduce new functionality tothe software. Poor preparation for testing and modification is to be blamed forthis problem.

However, this model is not completely useless. For prototyping small pro-grams with well understood requirements, it could be considered an alterna-tive.

2.4.2 The Waterfall Model

One of the earliest process models that tried to address the difficulties encoun-tered with the code-and-fix model is the waterfall model. It was first describedin publication by Royce in 1970 [19], although the term “waterfall” was intro-duced later. Royce based his model on experience from different projects inthe space industry. Consequently, the waterfall model resembles general sys-tems engineering processes in many ways. As a curiosity, there are also manysimilarities between the waterfall model and the model for developing largecomputer programs, described by Benington in 1956 [6].

The basic principles behind the waterfall model are rather simple: The modelconsists of an ordered list of activities or phases, where progress flows from thetop to the bottom, like in a waterfall (see Figure 2.4). If iterations are allowed,they are usually confined to successive process phases. The waterfall model

2In popular talk, this phenomenon is often referred to as “spaghetti code”.

13


Figure 2.4: The original waterfall model [19, p330]

heavily emphasizes documentation; normally, each phase defines a set of doc-uments to be produced and approved before moving on to the next. However,as the iterations are quite costly due to the extensive production and approvalof documents, the number of iterations is normally very limited. It is not un-common to freeze the documents after only a few iterations and move on to thenext phase [23], thus successfully preventing any future changes.

Although this process model works for other engineering disciplines, it isnot suitable for software engineering. The biggest problem is that the processforces important decisions to be made very early in the project. In addition,the results of these decisions may very well show up in the final stages of theproject, when it is impossible to correct them without seriously overshootingboth the schedule and the budget. Here is a short example to further illustratethe drawbacks of the waterfall process when iterations are not allowed:

Example 1 During the coding phase, a serious design flaw is discovered. Even thoughit is discovered early, it cannot be corrected as the design documents have already beenapproved and frozen. Additionally, there are other teams that work on other parts of thesystem and changing the design would break compatibility between the different partsonce finished. The programmers have no choice but to implement around the designflaws, resulting in a badly structured system. However, the coding is completed andsigned off and the project moves into the testing phase.

14


During testing, some serious performance problems arise. In addition, it does notintegrate as well with the existing legacy systems as it should. With the project deadlinerapidly approaching, there are now two alternatives: either the customer has to acceptthat the delivered system does not meet all of the requirements, or the previous processstages must be repeated — in order.

Allowing iterations between successive process stages slightly improves thesituation. For example, it becomes possible to correct requirements problemsduring design and design problems during coding, etc. However, the processstill makes it difficult to respond to changes.

Another problem with the waterfall approach is its Big Design Up Front (BDUF)strategy. Ambler [2] lists several shortcomings of this strategy, of which themost obvious one is that it is virtually impossible to think everything throughat the start. Unless the system is either very small or very simple, it is highlyunlikely that the designers will come up with a perfect solution that covers allscenarios before writing a single line of code.

The reason why this problem mainly affects software engineering is that thereare no physical constraints on software. Where the classical engineers use math-ematical models, calculus and simulation to make accurate estimations of howthe finished product is going to behave before it is even built, software en-gineers have to rely mainly on experience from similar projects and instinct.Interestingly, Royce used the model described here as an example of a flawedsoftware process. He proposed several improvements to make it more efficientand safer to use, such as early development of a prototype before designing thefinal version of the program (see Figure 2.5). However, for some reason, theoriginal model is still in use by the software industry — including its flaws3.

The waterfall process is not completely useless, it has a few advantages aswell. First of all, projects following a waterfall process are well documentedand the documentation is always up-to-date. Secondly, it works quite well forprojects where the requirements are well understood by everybody in the teamand are very unlikely to change during the course of the project. Thirdly, as thesystem is completely designed before the implementation begins, it is possiblefor different teams to work on different parts of the system simultaneously.Finally, the waterfall models works well with other engineering processes andmight be a suitable choice when the software development is a part of a largersystems engineering project.

3Boehm [7] refers to the original waterfall model as the stage-wise model and to Royce’s im-proved model as the waterfall model.

15


Figure 2.5: The modified waterfall model [19, p338]

2.4.3 The Spiral Model

Due to the problems with the waterfall model, many alternative models weresuggested. However, although many of them had several advantages, they allsuffered from serious problems when the size of the software increased. An at-tempt to combine the best of all worlds is the spiral model, introduced by Boehmin 1988 [7]. In fact, Boehm states that

“… [his] spiral model can accommodate most previous models as specialcases and further provides guidance as to which combination of previousmodels best fits a given software situation.”

Consider Figure 2.6. The first thing to note is that the spiral model is iterative,whereas the waterfall model is sequential. The process begins in the center andthe iterates outwards clockwise, one cycle at a time. There are two interestingdetails to note here: First, in any given point of the process, the radial dimen-sion represents the cumulative cost of the steps accomplished to date. That is,the total project cost grows for each cycle of the spiral (see the positive Y-axisin Figure 2.6). Second, in any given point of a cycle, the angular dimension isa measurement of the progress of that particular cycle.

The spiral process model is a risk-driven process model. That is, one of itsprimary goals is to minimize the risks involved in the software project. In orderto accomplish this, each iteration goes through four major phases (representedas quadrants in Figure 2.6):

16


Figure 2.6: The spiral model [7, p64]

1. Determine objectives, alternatives and constraints

2. Evaluate alternatives, identify and resolve risks

3. Develop and verify next-level product

4. Plan next cycles

These phases are the same for all iterations and are also conducted in the sameway, with the exception of phase three. Phase three, the actual developmentphase, is determined by the results of phase two, i.e. the risk analysis. High-risk issues are always addressed before low-risk issues. For example, high-risksoftware elements are more likely to change during development than low-riskelements. It is also likely that changes made to high-risk software elementsaffect other parts of the system as well. Consequently, it is not a good idea tospend too much time designing and implementing low-risk elements beforethe high-risk elements have been stabilized.

One option for risk reduction that is encouraged by the spiral model is pro-totyping. Prototyping and software reuse may be utilized at any stage in theprocess if the risk analysis so demands.

17


Figure 2.7: A spiral cycle

In extreme cases, the spiral might even be terminated and the project abortedif the risks are deemed to too high. Finally, in order to check that the objectiveshave been met, phase three is always concluded with a verification step.

Note, that one cycle of the spiral model resembles the modified waterfallmodel introduced in Section 2.4.2. This is, however, a special case. Dependingon the results of the risk analysis, a completely different process model mightbe chosen for completing the cycle (see Figure 2.7). If the risks are small and theproblem domain well understood, the original waterfall model might be suffi-cient. In another case, the best approach might be to use formal methods or anevolutionary approach (see e.g. [2] for more information about evolutionarydevelopment).

The spiral model has one more notable feature; it allows the users to go backto earlier stages or even redo some of the completed work if a better alternativeemerges, or if it is required in order to resolve new risk issues. This is illustratedin the following example:

Example 2 During the first cycle of a software project, three different alternativesare considered for the system architecture. Based on the knowledge at hand, the teamdecides to implement the one that implies the smallest risks and yet is able to fulfill therequirements of the system.

However, during the next cycle, it turns out that there is a high risk in adapting themain system functionality to the architecture. One of the other alternatives would havebeen a better choice. The risk analysis states that there is a higher risk in keeping the

18


implemented architecture and trying to implement the main system on top of that, thanin replacing the architecture with the better alternative. Consequently, the existingarchitecture is scrapped and the better alternative is implemented instead.

To summarize, the spiral model has many advantages compared to the wa-terfall model. The most significant advantages are that firstly, the spiral modeldoes not force the usage of one single process model but rather allows the de-velopers to choose the model that best fits the needs at the time and secondly,that the spiral model takes software evolution and changes into account.

However, care must be taken not to upraise the spiral model to “golden ham-mer” status. Despite its attempt to combine the best parts of the other processmodels, it still suffers from some difficulties. The biggest of these is the heavyreliance on risk-assessment.

The requirements specification in the spiral model is completely risk driven.That is, the high-risk elements are elaborated in detail whereas the low-riskelements are postponed to later cycles. However, this presumes that the devel-opers have expertise in risk assessment and manage to identify and resolve thehigh-risk elements. Otherwise, there is a risk that the well understood (low-risk) elements are the ones that are elaborated in detail, whereas the poorly un-derstood (high-risk) elements are postponed. This in turn would give a falseindication of positive progress, while in fact, the project is heading in the oppo-site direction. Consequently, incorporating well-trained and experienced soft-ware developers in all stages of the process is vital to the success of the spiralmodel.

Another issue that needs to be addressed is the importance of communica-tion. A waterfall project is heavily documented, which means that it is quiteeasy to replace programmers when required. As everything is specified in de-tail, the risk of misunderstanding the design and specification is quite small —in the coding phase, that is. A spiral project, on the other hand, does not pro-duce the same amount of documentation. This speeds up the development, butalso requires better communication between the developers in order to avoidcostly misunderstandings. For example, it is possible that the software hasbeen designed by an expert and will be implemented by junior programmers.There is a risk that the expert leaves out certain important details that he orshe considers to be trivial, but that that the programmers have not yet learned.Extreme Programming, presented in Section 2.8, tries to address this risk.

19


2.5 Software Methods

Whereas process models mainly focus on the timing of the different phases,software methods4 focus on how to navigate through each activity and how to repre-sent activity products. Casually put, a software method addresses the questionsHow are we going to do this? and Why are we doing it this way? [7]

It is important to note that, although often used together, process models andsoftware methods are independent. That is, two projects might very well utilizedifferent software methods even though they use the same process model andvice versa; two projects might utilize the same software methods even thoughthey use different process models. Finally, there are cases when the processmodel and the software method are so tightly coupled to each other that it isimpossible to say which is which. Although there is a clear distinction betweenthe concepts, the general term ’software process’ often refers to the combinationof a process model and one or more methods.

Normally, a software method can be defined in terms of roles, tasks and arti-facts, as depicted in Figure 2.8. For example, this is the definition used by theObject Management Group in their Software and Systems Process EngineeringMeta-Model specification (SPEM) [18].

A role is a set of related skills, competences and responsibilities. A role canbe held by either an individual or a group of individuals (such as a team). Forexample, the role “Software Architect” could be held by one person whereasthe role “Software Tester” could be held by a separate testing team. Roles per-form tasks and are responsible for artifacts. Casually put, the role addressesthe question who?

A task is an assignable unit of work with a clear goal and step-by-step direc-tions on how to achieve it. Although a task may depend on other tasks, it isnot concerned with when or how many times it is performed. The result of atask is normally one or more artifacts. Likewise, a task may require a certainartifact as input. For example, the task “Build software” is dependent on thetask “Write code” and may need the “source code” and “build plan” artifactsas input. As output it produces the artifacts “binary code” and “build report”.

An artifact is a thing used, modified or produced by a task. Normally, anartifact is tangible (e.g. a document or a source code file), but sometimes it canalso be intangible (e.g. a decision).

Finally, methods are linked to the process model through the previously men-4Also called software methodologies.

20

2.5 Software Methods

Figure 2.8: The relations between roles, tasks and artifacts

Figure 2.9: The “Develop Solution Increment” activity of OpenUP

tioned process activities, which are basically sequences of related tasks per-formed to achieve a greater purpose. The process activity concept can be illus-trated with a small example from the OpenUP5 process framework.

Consider Figure 2.9. During each iteration in the elaboration phase of OpenUP,there is an activity named “Develop Solution Increment” that is to be per-formed by the “Developer” role. However, this activity actually consists offive separate tasks: “Design the Solution”, “Implement Developer Tests”, “Im-plement Solution”, “Run Developer Tests” and “Integrate and Build”. Alsonote that all of the tasks require certain artifacts as input and produces otherartifacts as output.

5http://epf.eclipse.org/wikis/openup

21


2.6 The Advantages of a Predefined Process

In Section 1.3, several conditions that make software engineering a demandingtask were noted. The systems are becoming more and more complex, the conse-quences of system failures are becoming more serious, changing requirementsis becoming more of a rule than an exception, etc. There are many things thatcan go wrong in many different ways6. Working in a careful and systematicmanner is a must for any nontrivial software project.

As noted in Section 2.2, the software process controls how a system is de-veloped. However, unless the software process itself is controlled, there areno guarantees whatsoever that the development will in fact proceed in a care-ful and systematic manner. Therefore, it is strongly recommended to follow apredefined process, with clearly stated goals, responsibilities and methods.

The choice of process can have a decisive influence on the outcome of theproject. For example, the development of a website for a small company andthe development of a control system for a nuclear power plant require verydifferent processes. Swap the processes for these projects and disaster will fol-low. A well chosen process, on the other hand, will make it easier to plan andschedule the project, handle the scope of the project, improve quality, identifyand handle risks and thereby reduce the overall risk of project failure [8].

There are several predefined processes of varying scope and complexity read-ily available for use, from lightweight agile processes such as SCRUM7 and Ex-treme Programming (XP)8 to heavyweight process frameworks such as the Ra-tional Unified Process (see Section 2.7). Some companies also choose to developtheir own processes, which may be either completely designed from scratch orbased on existing processes.

2.7 Process Frameworks and Tailoring

Recall from Section 2.2 that every software project is unique and hence requirea unique software process. However, as the differences in the long run arefewer than the similarities, it would not be efficient to start the process designfrom scratch every time a new project is planned. Therefore, it is common tostart with a ready made process framework and then tailor it to fit the needs of aparticular project.

6Some good examples can be found at http://en.wikipedia.org/wiki/Anti-pattern.

7http://www.scrumalliance.org8Extreme Programming is presented in more detail in Section 2.8.

22

2.8 A Software Process Example: Extreme Programming

Figure 2.10: A process framework with two tailored process instances

A process framework is a set of ready-made production-ready process mod-els and software methods that have been designed to fit well with each other.During tailoring, only the parts of the framework that are relevant to the projectin question are selected and combined into a process instance that is to be fol-lowed throughout the project (see Figure 2.10).

A good example of a process framework is the Rational Unified Process9 byIBM. It consists of a large set of methods and process models based on bestpractices from the software industry, as well as production-ready out-of-the-box processes that can be used as a starting point for planning and initiating aproject.

In everyday talk, process frameworks are normally referred to simply as ’pro-cesses’, as are process instances, predefined processes, etc. The intended termcan often be deduced from the context.

2.8 A Software Process Example: Extreme

Programming

Recall from Section 1.3 that responding rapidly to change is vital to the softwaredevelopment of today. However, of the previously presented process modelsonly the spiral model tries to actively accommodate this requirement. Takingthis principle into the extreme is Extreme Programming (XP), first presented byBeck in 1999 [4] — an ample decade after the spiral model.

XP is a good example of an agile process. Agile processes emphasize “indi-viduals and interactions over processes and tools, working software over com-prehensive documentation, customer collaboration over contract negotiation(and) responding to change over following a plan” [1]. Close co-operation bothwithin the team and between the team and the customer10 is a must if an agile

9http://www-01.ibm.com/software/awdtools/rup10In the perfect case, the customer is a member of the team.

23


Figure 2.11: XP compared to the Waterfall model and iterative development [4,p70]

process is to be successful. More information about agile software developmentcan be found on the Agile modeling website http://www.agilemodeling.com or in [2, 15, 14].

Compared to e.g. the waterfall process where all the necessary informationcan be found in the project documentation, the information of an agile projectcan be found mostly in the source code, the automatic unit tests and in theminds of the other programmers. Consequently, in order to learn how the sys-tem works (or is supposed to work), a new team member works closely to-gether with the more experienced developers, who thereby act as mentors forthe newcomer. Openness and collective ownership of the code are used to dis-tribute the knowledge over all developers, thereby reducing the risk of a keyplayer suddenly leaving the project.

Figure 2.11 illustrates XP compared to the waterfall model and to a traditionaliterative model (such as the spiral model). Where both the waterfall model andconventional iterative models carry out the activities sequentially one at a time,XP turns the software process sideways and performs all the activities little ata time, throughout the entire project. Please note, however, that XP also usesan iterative process model.

The project starts with a planning game, where the customers and program-mers write a collection of user stories. A user story is basically a use case com-pressed onto an index card and must be business-oriented, testable and es-timable. After the user stories have been written, the programmers estimatehow long it will take to implement each user story. Based on these estimates,the customers then choose the most important user stories to be implemented

24

2.8 A Software Process Example: Extreme Programming

first.Once the most important user stories have been implemented, the system is

released into production. After this, the development continues in the formof short, time-boxed iterations. It is up to the customers to decide which userstories are to be implemented in the next iteration. If the need for a new userstory arises (i.e. a new requirement is discovered) it is placed on the pile ofunimplemented user stories. If it is important, the customers may select it forimplementation during the next iteration. As new releases are made frequentlyand a customer sits with the team full-time, the length of the feedback loop isshortened significantly — misunderstood requirements can be detected andfixed early and missing requirements can be added. If a user story turns out tobe more complicated than estimated, it is either postponed to the next iterationor split up into smaller stories.

Some common software methods used in XP are pair-programming, test-driven development and refactoring. They will only be briefly defined anddescribed here; more extensive information can be found in e.g. [15, 2, 4].

Pair-programming means that all production code is written by two peopleat one workstation. Thus, every line of code entered into the system has beenseen by at least two people. Consequently, if one of the team members leavesthe project before it is finished, there is at least another person in the team whoknows how the system works.

Test-driven development is sometimes called Test-first development. The ba-sic principle behind this method is that for every unit of code in the system,there is an automatic unit test that tests the code. Furthermore, the test has tobe written before the actual code. That is, the test defines the requirements andinterface for a specific unit or component and then code is written to make thetest pass. As the unit tests are small programs themselves, they form a regres-sion testing suite for the system that can be run at any time. If a bug is detectedin the code, the test cases are enhanced until they also detect the bug. Afterthis, the code is fixed so that the tests pass again. In XP, a programmer is notallowed to commit code that fails the regression test suite.

Refactoring is a method for evolving the design of a system by making smalltransformation to the existing design in such a way that the regression testspass in spite of the changes. In XP, all opportunities of refactoring the system,in order to make it cleaner or better, have to be exploited.

In short, the principles of short iterations, user stories and software methodslike pair-programming, refactoring and test-driven development, make XP asuitable process for changing requirements.

25


However, as with all processes, some words of caution are in order. First ofall, XP requires a different way of thinking from both the developers and thecustomers. A customer cannot just hand over a list of requirements and a sumof money and then wait until the software is finished — full-time customerparticipation is required for the project to be successful. From the developers’point of view, there is no room for individualism or high-status programmers.XP is a social activity that requires close co-operation and sharing of informa-tion with others.

Secondly, XP is less suitable for large projects where the development is splitup over different teams. As the system architecture and design evolves to-gether with the code from day one and very little documentation is produced,it is difficult — although not impossible — to guarantee that the code producedby one team integrates with the code produced by another team.

Thirdly, it is hard to make long-term estimations concerning the size and costof the project. On the other hand, if an XP-project runs out of money in themiddle, the most important features have already been implemented and arein production use. If the waterfall model had been used instead, chances arethe project would have been cancelled before a single line of code was written.

26

3 Process DescriptionRequirements

This chapter discusses process descriptions and the differentrequirements imposed on them. It begins by explaining what a processdescription is and continues with a short side-trip into the human mind.Finally, the requirements are discussed from different perspectives. Thischapter is mainly based on results and experiences from the companycase study.

3.1 What is a Process Description?

The previous chapter discussed the importance of using a good software en-gineering process for any software development project of today. However,in the end it always comes down to the people writing the software, regard-less of any fancy tools or clever software methods that might be available. Ifthe software developers do not understand the process or find it unnecessarilydifficult, they will either use it in the wrong way, or not use it at all. If this situ-ation arises, we are back at square one again, as having a process that nobodyfollows is equal to not having any process at all — or even worse: manage-ment’s understanding of the state of the project might be very different fromreality.

The previous chapter also discussed that the software process itself is a veryabstract concept and that it can be concretized using process models and soft-ware methods. The concrete representation of the process is called the processdescription and it has four primary objectives [13]: to communicate the processto others, facilitate reuse (see Section 2.7), support evolution of the process andfacilitate management of the process. These objectives are discussed from dif-ferent perspectives in Section 3.4.

The process description is often the result of an activity called process author-ing. There are many different approaches to process authoring, depending onthe organization in question. In an organization that is in the early stages of

27

3 Process Description Requirements

moving to a process oriented way of working, the process engineers might beconcerned primarily with mapping out and documenting the organization’sexisting processes. In organizations where the processes have already beendocumented, the primary focus of the process authoring team might be to fur-ther develop, improve and adapt the processes, as new requirements are im-posed on software engineering in general.

As previously mentioned, the first objective of the process description is tocommunicate the process to other people. The largest target group of the pro-cess description is not the engineers that authored the process, but the peoplewho will use the process in actual software development projects. In addition,the process imposes restrictions on how the people should do their work, whichcan have rather interesting and unexpected consequences. Why it is importantto take the human factor into account when creating a process description isthe subject of the next section.

3.2 The Human Factor

In his book “Agile Software Development” [9], Cockburn writes about the threedifferent stages of learning: following, detaching and fluent1. People who arelearning new skills pass through these stages and, depending on their currentstage, may behave in quite different ways.

People in the following stage (Level 1) look for a single procedure that worksand that they can learn to master. To feel secure, they need detailed, explicit,step-by-step instructions on how to accomplish a specific task. Even thoughthere may be several alternative procedures to choose from, they are only in-terested in learning one.

People in the detaching stage (Level 2) begin to identify the shortcomings andlimitations of the procedure they have just learnt. They learn to adapt it in dif-ferent situations and are interested in learning the alternative procedures andwhen to use them. Even though people at Level 2 can master many differentprocedures, they still need clearly defined rules when to use each procedure.

People in the fluent stage (Level 3) no longer care about procedures. Duringtheir transitions from the previous stages their knowledge has become com-pletely integrated. When they are faced with a problem, they simply “do whatit takes” to solve it, regardless of whether they are following, adapting or evenmaking a new procedure.

1The stages are sometimes referred to with the names of their Aikido counterparts shu, ha andri.

28

3.3 The Requirements Collection Procedure

It is important to be aware of these stages when creating a process description,as these stages apply not only to learning, but to listening, reading, coaching,etc. as well. Level 1 developers will need more detailed and disciplined in-structions on how they should do their job, whereas Level 3 developers wantmore freedom. For example, a Level 1 developer getting a Level 3 descriptionmight feel lost and confused, whereas a Level 3 developer getting a Level 1description might feel offended because somebody is trying to tell him or herhow to do his or her job. In either case, the motivation suffers, which in turnincreases the risk of project failure.

An even more problematic situation occurs when people think that they areon a higher level than they actually are. For example, many of the golden ham-mer fanatics think that they are at the highest level, when they are in fact atthe lowest level. Such individuals exist in virtually every organization and aremostly harmless as long as they do not have any power. For example, a juniorknow-it-all developer is probably going to be rebuked by the senior colleaguesrather quickly. However, if or when some of these individuals reach the man-agement level, some serious problems are likely to arise that affect the entireorganization. How to handle problems like these is out of the scope of thisthesis.

3.3 The Requirements Collection Procedure

Before going on to the actual requirements, some notes on how they were col-lected are in order. The company case study was supported by two differentgroups, a user group and an interest group.

The user group consisted of people who had experience in software processauthoring and were willing and able to contribute with opinions on featuresand functionality of a software process authoring tool. They were also familiarwith the in-house process authoring tool used by the company to author theinternal software engineering process. This group actively participated in therequirements collection.

The interest group consisted of people who needed to know the outcome ofthe study for different purposes (such as decision making), but for differentreasons could not actively participate in the study. Regular status reports weresent to the members of this group, who were expected to have opinions on theoutcome of the study and to provide feedback on the final report.

The primary inputs for the requirements collection were the process descrip-tions for the company’s internal software engineering and project management

29


processes, the user group and a project page on the internal company wiki.In the beginning of the project, a questionnaire was sent out to the user group

and the answers were published on the wiki page. Based on this informa-tion, an initial set of requirements was created and published on the wiki aswell, allowing members of both the user group and the interest group to givetheir comments. The requirements were prioritized according to the followingscheme: Must have (high priority), Should have (medium priority) and Niceto have (low priority).

Originally, the requirements were categorized as general requirements, struc-tural requirements, integration requirements, process authoring requirementsand process utilization requirements. In this thesis, however, a different cat-egorization will be used. Also, the requirements presented in this thesis aregeneralizations derived from the more specific and technical requirements col-lected during the original case study.

3.4 Process Documentation Perspectives

Recall from Section 3.1 that a process description has four primary objectives.These objectives in turn impose requirements on the process description. How-ever, instead of approaching these requirements from the objective point ofview, they will be approached from the user point of view.

Originally, Kellner [13] derived eleven requirements from these objectives.The requirements in this section are, however, not directly based on Kellner, butderived from the results of the company case study (as described in Section 3.3)and the discussion in Section 3.2. Similarities between these requirements andKellner’s requirements have been pointed out in the text.

An overview of the requirements is presented in Table 3.1. The Scope col-umn specifies whether the requirement applies to the content of the process de-scription, the tool used to author the description, or both. Table 3.2 on page 36presents a mapping between the requirements listed in this thesis and Kellner’srequirements.

3.4.1 The User Perspective

The largest target group of a process description is the people who will actuallyuse the process in their daily work, i.e. the software developers. For this groupof people, the purpose of the process description is to explain to them whatthey are supposed to do, why they are supposed to do it and how, taking into

30


Req. Key Point Objective ScopeThe User Perspective

1 Short and concise Communication Content2 Easy to read Communication Content, Tool3 Accessible Communication Content, Tool4 Rationales, general idea Communication Content5 Knowledge repository Communication, Content, Tool

EvolutionThe Project Manager Perspective

6 Tailorable Reuse Tool7 PM tool integration Reuse Tool

The Author Perspective8 Manageable Management, Reuse Tool9 Synchronization, Management, Reuse Tool

version handlingThe Customer Perspective

10 Reference manual Communication ToolThe Machine Perspective

11 Meta-model Management Tool

Table 3.1: Overview of the process description requirements

account the human factor presented in Section 3.2. Based on this, the followingrequirements can be derived. Note, that most of them are concerned with thefirst objective, communication.

Requirement 1: The description should be short and concise. The pri-mary interest of the users is to write software — not to read lengthy and boringprocess specifications. Very few users will be bothered to read a 200-page docu-ment of which only a small part is of relevance to them (see also Requirement 3).This requirement is similar to Kellner’s fifth requirement [13, p94].

Requirement 2: The description should be easy to read. Visual represen-tation of information in the form of diagrams and tables should be used whenappropriate and the written text should be well formatted. A well chosen fig-ure can provide more information than a page of written text. This requirementis similar to Kellner’s first requirement [13, p94].

Requirement 3: The description should be easily accessible. Most userswill only use the process description to check what they are expected to do (andwhen), based on their particular role or roles in the project. Even though theyshould understand the big picture of the process, very few users will actuallyneed to know all the details. Consequently, if the users cannot easily find the

31


information that they need, they will not be bothered to even try. This require-ment has no clear counterpart in Kellner’s requirements, but it includes ideasfrom Kellner’s second and third requirements [13, p94].

Requirement 4: The description should explain the rationales behind andthe general idea of the process. This is important for two reasons: First, itassures that the process does not contain any unnecessary elements, as everyrole, task and artifact exists for a reason. It is very easy to specify that a certaindocument should be produced only because it looks good or for historical rea-sons. Second, it helps the users to grasp the big picture and understand whythey are expected to work in a certain way. As stated earlier, a user who doesnot understand the process will either use it the wrong way, or not use it at all.

Requirement 5: The description should act as a knowledge repository.The users of a process (e.g. software engineers) are presumably experts in theirfields of procession. Consequently, they have a clear picture of what worksand what does not. Therefore, as a process imposes restrictions on how theyare supposed to do their work, there is a risk that they begin to feel like they arelosing control over what they do and consider the process more as an obstaclethan a tool. They might even start to look at the process authors as some kindof authoritative know-it-alls. This can be avoided by making it easy for theprocess users to give feedback and comments as to how the process could beimproved, etc.

Also, recall the scenario presented in the beginning of Section 1.3. Normally,the programmers have a pretty good idea of what they should have done dif-ferently, i.e. they have learned something. To prevent the mistakes from hap-pening again, these learnings should be stored somewhere and made availableto the rest of the programmers.

This requirement can be elaborated by introducing two new terms: processrepository and collaborative process framework.

A process repository is a knowledge base that contains not only process mod-els and method descriptions, but also best practices, previous experiences, etc.One could think of it as a collection of process frameworks (see Section 2.7). Asimilar idea has been presented by Jacobson et al. [11] (see also Section 6.2).

A collaborative process framework is a special version of a process frame-work that both process users and process authors are allowed to edit and refine.In other words, the collaborative version of a framework is always the mostup-to-date version and contains the latest experiences and practices. Another

32


framework version, the normative process framework, is discussed in Section 3.4.3(Requirement 8).

Unlike the previously mentioned requirements, this one is also concernedwith the third objective, evolution. It does not, however, have any clear coun-terpart in Kellner’s list of requirements, although the tenth requirement toucheson the subject [13, p95].

3.4.2 The Project Manager Perspective

Although the project managers are also users of the process, they have beengiven a separate section as they have some requirements that do not apply tothe software developers. For this group of people, the purpose of the processdescription is to guide them in planning and managing the project. Based onthis, the following requirements can be derived, in addition to the user require-ments in Section 3.4.1. They are all concerned with the second objective, reuse.

Requirement 6: The description should be tailorable. Section 2.7 discussedthe advantages of process frameworks and tailoring. All software projects areunique and require customized software processes. Instead of designing theprocess from scratch every time, the project manager begins with a ready-madeprocess framework and tailors it to fit the needs of the project.

Requirement 7: The description should be integrable with project man-agement tools. Unless the project is extremely small, the project manageruses some kind of project management tool to plan and manage the project.As the process description contains relevant information about resources andtasks, it should be possible to automatically import this information into theproject management tool and, preferably, the other way around as well. Thisrequirement is related to Kellner’s eighth requirement [13, p95].

3.4.3 The Author Perspective

The third target group is the process authors, i.e. the people who maintainand develop the process. For this group of people, the purpose of the pro-cess description is to act as a concrete representation of the process that can beused as a basis for process development and improvement. Therefore, the re-quirements are of a more technical nature compared to the user requirements inSection 3.4.1 and mainly apply to the tool used to author the process descrip-tion instead of the process description itself. Note, that the requirements areconcerned with the reuse and management objectives.

33


C

NormativeReleased

CollaborativeEvolving

B

A

A1

CustomizedProject-specific

Figure 3.1: The relations between normative, collaborative and customized(tailored) process descriptions

Requirement 8: The description should be open for feedback, but re-main manageable. This is basically a consequence of Requirement 5. Aswith software products, it is not wise to use the latest bleeding-edge versionof the process for new projects. This is especially true if the process descrip-tion evolves on a day to day basis. Consequently, the process authors shouldcompile and publish a normative process framework that can be used by projectmanagers when they plan their new projects. The normative process frame-work should be based on the collaborative process framework presented inRequirement 5 and the experiences gained from using the normative frame-work should also be fed back into the collaborative framework. This principleis illustrated in Figure 3.1.

Requirement 9: Synchronization and version handling should be sup-ported. The final authoring requirement is a consequence of Requirements 5,6, 8 and 10. In order to maintain all the different versions of the process de-scriptions (see Figure 3.1), trace the changes from one version to another andmanage simultaneous user edits, the process authoring system should havesolid support for synchronization and version handling. This requirement issimilar to Kellner’s ninth requirement [13, p95].

34


3.4.4 The Customer Perspective

A different, but nonetheless important, target group of a process description isthe customers who provide the funding for the software engineering projects.For this group of people, the process description might be used as a basis forevaluating the maturity of the company, or as a part of the documentation de-liverables. For example, if the customer is a nuclear power plant, it is of vitalimportance that the selected software vendor is able to conform to the tightquality and safety constraints imposed on the system. Also, when the systemis completed and delivered, it should be possible to check how e.g. the testingof the system was conducted.

Requirement 10: It should be possible to create a static, printable de-scription of the process. This requirement is best illustrated with an exam-ple. During contract negotiations, a software vendor has to prove its prepared-ness for handling a project of such complexity to the customer. In addition toreferences to previously, successfully completed projects, the normative soft-ware process description is a good candidate for proving this. The customerreviews the vendor’s process (under the terms of a nondisclosure agreement,of course) and decides to give the contract to the vendor.

Once the project planning begins, the process is tailored. However, one of theproject deliverables is a description of the process used during development.The customer requests the process description in the form of a printed referencemanual, as they are not interested in following the process step by step in realtime.

3.4.5 The Machine Perspective

The process description requirements have now been discussed from three dif-ferent perspectives. Common to these perspectives is that they are all perspec-tives of human beings. However, as we are living in the information age andmany of the requirements require that the process description is stored in adigital format, a final perspective has to be taken into account — the one of themachine.

Requirement 11: The process description should have a clearly definedmeta-model. Computers can only do exactly what they are told — no more,no less. A process description written in natural language only is too abstractfor a computer to grasp. Consequently, for a computer to be able to process it,the information needs to be well-structured in a clearly defined meta-model,

35


such as SPEM [18]. A meta-model describes the structure of the repository usedby a process authoring tool to store process descriptions. Using a standardizedmeta-model provides additional advantages, as it prevents vendor lock-in andimproves integrability. For example, a process description stored according toSPEM can be opened with any SPEM-compliant process authoring tool and anySPEM-compliant project management tool will be able to import the informa-tion necessary to create a preliminary project plan. This requirement is similarto Kellner’s fourth requirement [13, p94].

Req. Kellner Req.1 52 13 (2, 3)4 -5 (10)6 -7 (8)8 -9 9

10 -11 4

Table 3.2: Mapping to Kellner’s requirements

36

4 Evaluation of Existing ProcessAuthoring Tools

This chapter contains an evaluation of how four different processauthoring tools manage to meet the requirements in Chapter 3. Itbegins with a short presentation of the tools and continues with theevaluation results, with emphasis on the issues encountered.

4.1 Introducing the Contestants

With the requirements outlined in Chapter 3 in mind, some of the most pop-ular open source and commercial process authoring tools available today havebeen evaluated. As this evaluation was originally conducted in the context ofthe company case study, an in-house process authoring tool has been includedas well.

The purpose of the evaluation was to select a company-wide process author-ing tool. Consequently, it was very important that the tool had a long life ex-pectancy. Therefore, only tools with world-class support were included in theevaluation. Research tools or tools backed by a simple user community or asmall company were not considered.

4.1.1 The In-house Tool

Due to the company confidentiality policy, the in-house tool is not going to bepresented in detail in this thesis. The tool in question is the result of severalyears of internal development and is written in Java. It is document-based andthus integrates well with most common revision control systems. Although itis not SPEM-compliant, it includes several ideas from SPEM.

A process author uses the tool to create, edit or publish processes. The pro-cess itself is edited by creating entities and filling in their attributes. Once the

37

4 Evaluation of Existing Process Authoring Tools

process is ready, it is exported to different formats (HTML, DOC, PDF) for pub-lication.

A process user would begin by looking up the process description publishedby the process author. The user would then look up the appropriate role, activ-ity or artifact and start working according to the given instructions. In order tosupport collaborative process authoring, the process description links to pagesin the company wiki.

4.1.2 EPF Composer

The Eclipse Process Framework (EPF)1 is an open-source project within theEclipse Foundation. It is a customizable software process engineering frame-work with support for different project types and development styles. The EPFhas a process authoring tool named EPF Composer (EPC), which is built on theEclipse platform and runs on both Windows-based and Linux-based platforms.It is freely available on the Internet and comes complete with documentationand example process content. EPC is a document-based system and thus in-tegrates well with most common revision control systems. EPF aims to fullysupport SPEM.

A process author typically uses EPC to do one of the following: configureand publish an existing process, tailor or extend an existing process, or createa completely new process. Assuming this is the first time EPC is being usedfor a project, the process author would have to begin by creating method con-tent and capability patterns for the process to be used. After that, the processauthor would have to create a delivery process suitable for the project in ques-tion, create a method configuration and publish it in HTML-format on a sharednetwork resource.

A process user would begin by looking up the method configuration pub-lished by the process author. The user would then look up the appropriate role(or roles) and start working according to the given instructions. As EPC sup-ports many different kinds of structured content and rich text editing, all theinformation is available in one place only and the user does not have to lookup any external legacy documents.

For readers not familiar with SPEM in general or EPC in particular, the twomost important concepts to understand are the concepts of method content andprocess content (see also Chapter 2 on page 9).

1http://www.eclipse.org/epf

38


Method content consists of highly reusable information such as definitions ofroles, tasks, work products (also called artifacts) and relationships between them.It is discussed in Section 2.5 on page 20, with the exception of guidance andcategories.

Guidance may be associated with roles, tasks and work products. Guidanceis used to provide detailed supporting information such as checklists, exam-ples, guidelines, best practices, etc. Categories, on the other hand, are used togroup related method elements together. There are five standard categories:disciplines, domains, work product kinds, role sets and tools. In addition, it is alsopossible to define custom categories.

Process content reuses the method content to create end-to-end processes(called delivery processes) or reusable process components (called capability pat-terns). Capability patterns define the sequence of related tasks, performed toachieve a greater purpose. An instance of a capability pattern is called an ac-tivity (see Section 2.5 on page 20). Delivery processes are the process instancesof SPEM and define end-to-end full life-cycle processes that include differenttypes of activities such as iterations, phases and milestones.

In addition to specifying how processes are to be defined, SPEM also specifieshow to manage the process definitions. The basic elements are method libraries,method plug-ins and method configurations. A method library is a collection ofmethod plug-ins and method configurations. A method plug-in is a containerfor method packages (containing method content) and process packages (contain-ing process content). A method configuration is a logical subset of a methodlibrary. In short, it defines which parts of the library that will be published orexported for use by process users.

A screen-shot of EPC is presented in Figure 4.1. In this evaluation, EPC ver-sion 1.2 was used.

4.1.3 Rational Method Composer

Rational Method Composer (RMC)2 is a commercial version of EPF (see Sec-tion 4.1.2) and is a part of the Rational suite provided by IBM. Thus, all featuresavailable in EPF are also available in RMC. In addition, RMC provides someadvanced features such as integration of Eclipse Business Intelligence and Re-porting Tools (BIRT) and the tools in the Rational suite, proprietary processcontent and functions for estimation and tailoring, among other things.

2http://www.ibm.com/software/awdtools/rmc

39


Figure 4.1: The delivery process editor of EPF Composer

A screen-shot of RMC is presented in Figure 4.2. In this evaluation, RMCversion 7.2 was used.

4.1.4 IRIS Process Author

IRIS Process Author (IPA)3 is a commercial process authoring tool by the Cana-dian company Osellus. Unlike the other tools included in this evaluation, IPAis completely web-based. Consequently, it should be possible to use IPA withany modern web browser that supports Web 2.0 technologies. However, dur-ing the evaluation, only Internet Explorer seemed to work properly. Bundledwith IPA is another product, IRIS Process Central (IPC), that basically acts asa repository for processes. A process in IPC can be exported into many dif-ferent formats, including — but not limited to — HTML, Microsoft Word andMicrosoft Project.

IPA is SPEM-compliant and hence everything that can be modeled in e.g.EPF/RMC can also be modeled in IPA. However, compared to EPF/RMC, IPAis much more customizable — for example, it is possible to define custom at-tributes for different process elements. The terminology used in IPA is alsosomewhat different from the one used in EPF/RMC. Content is stored in pack-ages, which in turn are stored in libraries. Packages can import process ele-

3http://www.osellus.com/IRIS-PA

40


Figure 4.2: The process tailoring perspective of Rational Method Composer

ments from other packages, making it possible to create customized processes.

A process author uses IPA to create, edit or publish processes. The authorwould begin by creating process libraries for the different processes and thenenter all the method content (roles, work products, tasks, guidance, etc.) intoIPA and organize it into packages. Finally, the author would create processpackages that import method content from other packages and reuse it to formprocesses that are suitable for the project in question. Once a process is finished,it can be exported or published to different formats, such as HTML, MicrosoftWord, Microsoft Project and PDF.

Process users never have to access IPA directly. Rather, they use the publishedversion of the process. If the process has been published to IRIS Process Central,they can choose from a variety of formats. For example, in addition to theplain-HTML-version of the process, there is also a wiki-version that allows theprocess users to provide feedback and suggest improvements by modifying thepublished version. However, these changes are not automatically propagatedback into IPA — they have to be imported manually by the process authors.There are also other ways of giving feedback, such as blogs.

A screen-shot of IPA is presented in Figure 4.3. The version included in thisevaluation was the one running on Osellus evaluation servers in August 2008(no exact version number is available).

41


Figure 4.3: A library package diagram in IRIS Process Author

4.2 The Tool Evaluation Procedure

In the company case study, two process subsets were selected before the toolswere evaluated. The purpose of these subsets — taken from the in-house soft-ware engineering process and the in-house project management process — wasto test whether the meta-models of the tools contained enough structural ele-ments to model the processes. References to requirements covered by a partic-ular subset were also identified. The subsets were selected in cooperation withmembers of the teams responsible for developing both processes.

Once the process subsets were selected, four different usage scenarios weredefined. The purpose of these usage scenarios was to test how well the toolsperformed in typical real-world usage situations. The scenarios dealt with tai-loring and publishing, collaboration, usage and integration with project man-agement tool-sets. References to requirements covered by a particular scenariowere also identified.

The evaluation of the tools was conducted in the following way:

1. The process model subsets were implemented using the tool.

2. Using the implemented model subsets, the usage scenarios were exe-cuted.

3. The remaining uncovered requirements were checked manually.

For each requirement, each tool was rated as either compliant, compliant withadditional configuration, partially compliant or not compliant. These results and

42

4.3 Evaluation Results

Req. In-house EPC RMC IPA1 N/A N/A N/A N/A2 2 1 1 13 1 3 3 24 N/A N/A N/A N/A5 2 3 3 16 2 1 1 17 2 1 1 18 2 3 3 19 2 2 2 1

10 1 3 2 111 1 3 3 2

Total: 15 20 19 11Rank: 2 4 3 1

Table 4.1: Tool evaluation results

an overview of license and support costs were used as a basis for making arecommendation of which tool or tools would be best suited for the company.

However, as has been noted in Section 3.3, the requirements presented in thisthesis are not the same requirements used in the company case study. Conse-quently, the evaluation results presented here have not been obtained directlyusing the procedure described above. Rather, the results are based on resultsand experiences gained during the company case study and the focus has beenshifted to a more general point of view.


As the requirements are written on a very general level, it is not possible toharshly rate a tool as either compliant or noncompliant. Therefore, the toolshave been compared to each other in how well they manage to comply witha certain requirement. An overview of how they performed is presented inTable 4.1, with 1 indicating the best tool, 2 the second best, etc. N/A indicatesthat the requirement does not apply to the tool but to the content of the processdescription. If several tools have the same number, they are considered equallygood (or bad). Consequently, the tool with the lowest total is considered thebest — IPA in this case.

In general, none of the tools was particularly bad — they all had their strengthsand weaknesses. Important features such as process tailoring, project manage-ment integration and rich text editing are well implemented in most tools.

All tools have clearly defined meta-models. However, in spite of this, the

43


tools have received different grades for this requirement. Furthermore, alltools except the in-house tool use the standardized SPEM as their meta-model.Still, the in-house tool, with its non-standard meta-model, has received the bestgrade. The reason behind this is discussed in more detail in Section 4.3.3, butin short it has to do with customization support. The in-house tool can be cus-tomized to model almost anything, whereas the other tools have much morestatic meta-models.

From a developmental perspective, it is more interesting to discuss the fea-tures that do not work than the features that work. Therefore, the rest of thischapter will concentrate on the issues encountered during the evaluation.

4.3.1 Collaboration Issues

The first problem is poor support for collaboration between process authorsand process users (Requirements 5 and 8). Many tools are still designed aroundthe traditional process engineering principle, where the processes are designedby a dedicated process engineering team and then exported to the software en-gineering teams for adoption. It is a single-directional form of communication,where the process engineers tell the software engineers — who presumably areexperts at what they do — how they should do their work.

Recall from Requirement 5, that the process repository should not only con-tain process models and method descriptions, but also best practices and pre-vious experiences etc. This knowledge is not held by the process engineers butby the software engineers — who utilize the process in real-world projects —and is of little use if it cannot be fed back to the process repository.

Of the evaluated tools, IPA has the best support for collaboration through itsProcess Central and Wiki features. Close behind follows the in-house tool thatgenerates links to the company wiki from every process entity. Thus, anyonewith access to the company wiki can contribute to the process. However, thechanges are not automatically propagated from the wiki to the process author-ing tool — they have to be imported manually (as is the case with IPA as well).EPC/RMC can be configured to provide a single link for collecting user feed-back. It is not possible to specify different feedback links for different entitieswithin the process.

4.3.2 Synchronization and Version Handling Issues

The second problem is poor support for version handling (Requirement 9).When it comes to authoring process descriptions, a good version control sys-

44


tem is important for two reasons: synchronization and version tracing.Synchronization becomes an issue in all situations where several actors com-

pete for a limited number of resources. In this case, several users must be ableto work on the process simultaneously without having to worry about over-writing each other’s changes. This issue is normally resolved by using a lock-ing mechanism. Two popular locking mechanisms are “Lock-Modify-Unlock”and “Copy-Modify-Merge” (examples of both mechanisms are presented in thefirst chapter of [5]).

Lock-Modify-Unlock prevents other users from editing a locked entity untilthe lock is released. This is acceptable if the size of the lock area is small enough.However, if the lock spans large areas of the process description, it effectivelyblocks collaboration, as only one user can work on the process description at atime.

Copy-Modify-Merge detects conflicts instead of preventing them. When aconflict is detected, the slower author has to merge his or her version with theone currently in the repository before it can be committed. However, if a gen-eral revision control system such as Subversion, CVS or ClearCase is used, thisbecomes a problem as these systems work with ordinary files. The slower au-thor either has to revert his or her changes, update the working copy and re-addthe modifications manually, or exit the tool and merge the changes on a rawcode level (e.g. if the tool stores its data in XML-files). In either case, it is a timeconsuming and error prone process.

When a new project is planned, a process is selected and tailored for that par-ticular project. During the course of the project, the process may evolve as newexperiences are gained, but otherwise it remains more or less static throughoutthe project. However, in large companies there may be several projects go-ing on in parallel that are based on the same core process and contribute newinformation to the process repository simultaneously. In addition, there maybe a separate process engineering team that works with the core process itself(Requirement 8). Consequently, the version control system must be able tomanage tracing, branching and merging of different versions of both the coreprocess and the project-specific tailored processes (see Figure 3.1 on page 34).

IPA has tried to address the synchronization issue by using a built-in Lock-Modify-Unlock mechanism that works on the process library level. Thus, it isimpossible for two users to work on the same process library simultaneously,causing a possible block to collaboration. This problem can be worked aroundby making sure the libraries are small enough, which is a good idea in any caseas it also makes reuse easier as well. IPA handles version tracing by dumping

45


the process descriptions to XML and storing them in external revision controlsystems. The XML dumps can then be reimported into IPA as necessary.

The other evaluated tools all rely on external revision control systems for bothsynchronization and version tracing. Thus, they all suffer from the problemsmentioned previously in this section.

4.3.3 Meta-Model and User Interface Issues

The third problem can be divided into two closely related subproblems: meta-model limitations and user interface issues.

Most tools use a standardized meta-model such as SPEM [18]. This has thebenefits of reducing vendor lock-in and increasing portability between differ-ent process authoring tools. However, it has also led to vendors including allpossible concepts that might be needed to model a process in their tools. Thisin turn has resulted in overly detailed process descriptions and complex userinterfaces, which is in conflict with Requirements 2 and 3. It is also in conflictwith the current trend [3] of moving from complex processes to simple ones.Few users will actually need all the functionality, which forces companies to in-troduce usage guidelines, making the tools harder to use and scaring off casualusers whose feedback and opinions would otherwise have been very valuable.The tools should be scalable to different process sizes, just as processes shouldbe scalable to different project sizes.

At the same time, the meta-model in most tools is fixed, i.e. the users cannotdefine custom entities, attributes or relations. Even in cases where the meta-model allows customization in principle, the user interface does not supportthis in practice. Consequently, the users are forced to model their processesusing the predefined process elements, which might not always be appropri-ate. For example, the software engineering process mentioned in Section 4.2contained an entity that could not be successfully modeled in any of the tools,except the in-house tool.

Of the evaluated tools, the in-house tool had the best support for customiza-tion of both the meta-model and the user interface. IPA comes second withsupport for user-defined attributes. EPC/RMC support customization of nei-ther the meta-model nor the user interface. However, according to IBM, RMC7.5 will include support for tagging process elements with untyped values.

46


4.3.4 Integration Issues

The final problem is integration. Except for very small projects, there are sev-eral tools and systems that need to access the information in the process repos-itory. The developers want a browsable view of the process, the customerswant a printed copy for documentation purposes, the project manager wantscheduling and resource information for the project management tool (Require-ment 7), the webmaster wants some information for the corporate intranet, thequality management team wants to extract information for the audit checklist,the customer wants a description of the process for the project documentation(Requirement 10), etc. Many tools are only able to export to HTML, XML andsometimes Microsoft Word or PDF. However, to fully integrate with other toolsit is important that a process authoring tool supports advanced user-definablequeries and exports. Preferably, it should be possible to define advanced im-ports as well in order to aid data synchronization. Information that cannot beproperly accessed is almost as bad as having no information at all.

Of the evaluated tools, IPA and the in-house tool have the fastest and mostflexible export solutions. IPA has built-in support for several different exportformats and supports customized exports through its Process Central feature.The in-house tool use a template-based export engine. EMF only supports ex-porting to XML and HTML and the results cannot really be customized. RMCadds support for Word and PDF, but the publication process is extremely slow.However, RMC has recently included the BIRT reporting engine, which shouldmake it easier to create customized exports.

47


48

5 Improving the State of thePractice

This chapter presents some ideas of solutions to the problemsdescribed in Chapter 4. The purpose is not to solve the problems, but togive the product vendors some ideas of how their products could beimproved. A proposal for a new process authoring tool is also included.

5.1 Wiki-Based Process Authoring

Recall from Section 4.3.1 that many tools have issues with collaboration andcollecting feedback from the users. A popular tool for collaboration that is be-coming more and more common in organizations today is the wiki [12]. A wikiallows the users to easily create, edit and link pages and normally, all users areallowed to edit everything.

However, requirements 5, 8 and 11 from Chapter 3 pose a problem if a purewiki is used for process authoring. Although user contribution must be al-lowed, the process description must still be kept under control and the contentmust remain clearly structured. An attempt to solve this problem has beenmade by Wongboonsin and Limpiyakorn [24] who modified MediaWiki1 to actas a process repository. They introduced page templates to keep the contentstructured and user roles to control who had access to the description. Userswere not allowed to edit the process description itself, but could provide feed-back on a separate discussion page attached to each process entity. This isclearly a step in the right direction, but the idea can be developed even fur-ther.

Consider the following: A wiki system keeps a complete history of all thechanges that have been made to its contents. Consequently, it is possible tobrowse backward in time to any state the wiki has been in throughout its lifetime. A revision control system, such as CVS or Subversion, support tagging

1The open source wiki software that is used by Wikipedia, see http://www.mediawiki.org.

49

5 Improving the State of the Practice

of specific versions and branching of versions into two different versions thatevolve in parallel. A meta-model makes sure that the content remains clearlystructured. Why not combine these systems into one single system?

The system would be accessed as a wiki, but instead of editing pages of text,the users would edit entities in the meta-model (e.g. SPEM). Tags would beused to label official versions of the process, such as released normative pro-cesses or tailored project-specific process instances. Branches would be used tokeep the normative and collaborative process versions separated and a featurefor easy migration of meta-model elements between the two versions wouldbe developed.

The development of such a system is non-trivial and there are many detailsthat need to be sorted out on the way. However, it would certainly move pro-cess engineering to a new level and open new possibilities for collaboration.Some ideas on how to implement such a tool is presented in Section 5.6.

5.2 Model Aware Diff-and-Merge

In online systems such as the one presented in Section 5.1, the need for diff-and-merge (see Section 4.3.2) is not as critical as in document-based systems.However, there are occasions where document-based systems are better suit-able than web-based online systems (e.g. when network connectivity is lim-ited) and they will still be around for some time.

Therefore, in response to the issues presented in Section 4.3.2, a model awarediff-and-merge component could be added between the process authoring tooland the revision control system. This component would allow a user to com-pare the differences between two versions of the process description at themodel level rather than the file level. The component would also allow a userto merge the two versions using a graphical user interface.

For example, a generic component for differencing and merging any modeldefined using the Eclipse Modeling Framework (EMF) is being developed. Asboth EPC and RMC use EMF to implement SPEM, it is by assumption only aquestion of time before this functionality is available to the customers. Pleasesee the EMF Compare project web site2 for more information.

2http://www.eclipse.org/emft/projects/compare

50

5.3 Extendable Meta-Model

5.3 Extendable Meta-Model

Recall from Section 4.3.3 that there are process elements that currently cannotbe successfully modeled with the static meta-models used by many processauthoring tools. Also recall from Section 4.1 that three of the evaluated toolsuse SPEM as their meta-model. However, SPEM 2.0 is not a static meta-model.In fact, it is stated in its specification [18, p69] that:

“SPEM 2.0 does not aim to be a generic process modeling language, nordoes it even provide its own behavior modeling concepts. SPEM 2.0 ratherdefines the ability for the implementer to choose the generic behavior mod-eling approach that best fits their needs.”

SPEM 2.0 is designed in such a way that it can easily be extended with user-defined elements. Chapter 10 of the specification [18] even defines how to linkthird-party process models to the SPEM process elements.

Both IPA and EPC/RMC are moving towards this kind of extensibility, al-though they are not there yet. For example, in the original EPF project pro-posal3, it is stated that:

“The meta-model will be extensible through the usage of custom attributesand custom process elements as well as normal EMF extensibility mecha-nisms”.

Therefore, by assumption it is only a question of time before this kind of func-tionality is available to the customers.

5.4 Scalable User Interface

In response to the user interface issues presented in Section 4.3.3, every processcould come bundled with an embedded user interface configuration for thetool. The configuration would contain information about the attributes andentities that are to be used for the process, as well as optional element specificusage guidelines. That is, instead of having a complex user interface and aseparate usage guideline document that instructs the users what to fill in andwhat to leave blank, the tool would only display the fields that are to be filledin and provide optional corresponding instructions inside the tool, as the usernavigates the user interface.

3http://www.eclipse.org/proposals/beacon

51


UIConfig

UIGuide

User Type

UI Scaling UI Filtering

Figure 5.1: Scaling and filtering of the user interface

In addition, the user interface could be filterable depending on the needs ofthe user. A software engineer and a process engineer do not need access tothe same information and, taking the human factor in Section 3.2 in account,a junior developer do not need the same level of detail as a senior developer.This feature is already available in many of the tools4, but only in the exportedprocess description.

As an example, consider Figure 5.1. The left-most form is the complete meta-model. Then the UI scaling layer is added by providing a user interface con-figuration and a user interface guide. The user interface configuration speci-fies which elements are to be included in this particular process description.The user interface guide provides information about how the remaining ele-ments are to be used. The result is a downscaled version of the meta-modelwith built-in usage guidelines that is still compatible with the full-scale meta-model. Next, an optional, role-specific user interface filtering layer is added.Depending on the needs of a particular role (or set of roles), unnecessary infor-mation is filtered out. It should, however, be possible to turn the filtering offand access all the information if the need arises.

The tool could come with a set of predefined user interface configurationsfor different types and sizes of projects. However, it should also be possibleto customize these configurations in an easy way, e.g. similar to the contentvariability mechanisms of SPEM (see Section 6.3.4 in [18]).

4It is called Views in EPC/RMC.

52

5.5 Extendable Import/Export Engine

PDF

HTMLHTMLHTML

TXT

TMPL

Figure 5.2: A schematic figure of an export/import engine with three exportplugins

5.5 Extendable Import/Export Engine

In response to the issues presented in Section 4.3.4, an extendable, configurableimport/export engine could be used as a two-way bridge between the processrepository and other formats. The engine would act as a container for importand export plugins that transform the data in either direction. In addition, theengine should make sure that any imported data are valid and do not causeinconsistencies in the process repository.

As an example, consider the export/import engine in Figure 5.2. It has beenconfigured with three export plugins, one that generates a single PDF-file fromthe process content, another that generates a collection of HTML-documentsand a third that takes a separate template file as an additional input and gener-ates a text file based on the template. In the figure, no import plugins have beenincluded but the principle would be the same — the plugin reads informationfrom an external source, e.g. a text file, transforms the information into a formthat fits into the process repository, validates the information and stores it.

The tool could come with a set of predefined plugins for exporting the processdescription to HTML, PDF, Microsoft Word, etc. It should also provide a pluginfor template-based plain text exports, where the user can customize the outputby creating a template file, as explained in the example above. Finally, the toolshould provide an API to allow the users to create their own export or importplugins. To make plugin development easier, the plugins could be written in adynamic scripting language such as Python5 or Ruby6.

This feature is of such a nature, that only a small group of trained peoplewill actually need to define the templates and write the plugins. Therefore, thetemplate definition and plugin development could be done in a separate tool,

5http://www.python.org6http://www.ruby-lang.org

53


Figure 5.3: The high-level architecture of a new process authoring tool

e.g. Eclipse IDE.Technically, it is possible to write both import and export plugins in Java for

EPC/RMC, but a dedicated export/import engine would definitely make thework easier and more cost effective. The inclusion of BIRT in RMC is a step inthe right direction.

5.6 A Proposal for a New Process Authoring Tool

This section presents a proposal for a new process authoring tool that meets therequirements laid out in this thesis. As implementing such a tool is a nontrivialtask, this section only contains a description of the overall system architectureand some design and implementation approaches. The level of detail has in-tensionally been kept rather abstract in order to avoid a Big Design Up-Front7

that most certainly would turn out to be inadequate when implemented.

5.6.1 Overall Architecture

The high-level architecture of the new tool is presented in Figure 5.3, where thearrows indicate dependencies. The tool consists of three essential subsystems:a process repository for storing the data, an import/export engine for reportgeneration and integration with other tools and a front-end for user access.

However, this section is only going to concentrate on the process repositorysubsystem and the front-end, as the import/export engine has already beencovered rather thoroughly in Section 5.5.

7See Section 2.4.2 on page 13.

54


Figure 5.4: The high-level architecture of a process repository

5.6.2 The Process Repository

The high-level architecture of the process repository subsystem is presentedin Figure 5.4. The subsystem consists of two central components: the meta-model component and the data storage component. In addition, it containssome supporting components such as security and transaction management.

In the following, it is assumed that the process repository is developed inJava and runs in either a JEE-container, an OSGi-container or a combination ofboth technologies.

The meta-model component consists of vendor provided core elements(i.e. standard SPEM) and user defined custom elements that extend the func-tionality of the core elements. This makes it technically possible to both ex-tend SPEM according to its specification and build a new meta-model basedon SPEM. The latter approach is more flexible, but also breaks compatibilitywith other SPEM tools.

The meta-model could be implemented using EMF, i.e. the same technologyused to implement SPEM in EPC. This has a number of advantages:

• The meta-model code base from EPC can be reused.

• EMF supports extending existing models, which makes it easy to createuser defined elements.

55


• There are production ready, open-source tools for EMF model authoringand automatic code generation of implementation classes.

• Possible to use CDO in the data storage component (see below).

Thus, a company needing a customized meta-model would only have to down-load Eclipse and EMF, import the proper API plugins and start developingtheir own meta-model elements. Once finished, they would package the meta-model elements into a plugin suitable for the container and deploy it on theprocess repository server.

The data storage component is responsible for storing instances of themodel elements, i.e. the actual process and method content. This componentis also responsible for version handling and managing of normative and col-laborative process versions, respectively.

First of all, the component should support storage and indexing of the user-defined data. That is, no matter how complicated a customized meta-modelis, the data storage component should be able to store and index it as long asit has been written in a proper way. There are different ways of achieving thisdepending on the physical data storage system used. If a relational database isused, one approach could be to generate separate tables for every user definedmodel element upon deployment. Another approach could be to use an XML-database or a specialized solution for storing EMF models.

Secondly, the component should support recording of version history for thedata. That is, it should be possible to go back to any moment in time and geta snapshot of the contents of the repository at that particular instant. This issimilar to ordinary revision control systems, with the only difference being thatinstead of working with files, the component would work with models.

Thirdly, the component should support tagging and branching of data, ar-guably on the method library level. The tagging and branching mechanismwould be used to differ collaborative content from normative content. Likewith version history recording, this is no different from ordinary revision con-trol systems.

Finally, the component should support some kind of synchronization andconflict handling. There are basically two alternatives here: Copy-Modify-Merge (see Section 4.3.2) and what could be called the “wiki approach”.

The wiki approach does not have any conflict detection mechanism. Rather,any changes made between checkout and commit are harshly overwritten when

56


the data is saved. However, this is not as bad as it may sound as all changesmade to a wiki are recorded and undoable.

The choice of approach depends on how the repository is going to be ac-cessed — the wiki approach would be more appropriate if a wiki-based userinterface was used, whereas Copy-Modify-Merge would be a better alternativeif a rich client was used. These two user interface alternatives are discussed inSection 5.6.4.

As mentioned earlier, the data storage component can be implemented usingConnected Data Objects (CDO). CDO is a three-tiered solution for distributedshared models, a complete model repository server and a part of EMF.

CDO currently uses optimistic locking, i.e. conflicts are detected and the userhas to decide how to deal with them. Also, CDO requires a network connec-tion to the repository in order to operate, i.e. offline operation is not supported.However, according to the CDO FAQ page8, there already is a diff-and-mergecomponent for CDO and support for Copy-Modify-Merge and offline opera-tion will be added in the near future.

Thus, in theory, CDO supports all the features of the data storage componentout of the box, except tagging and branching. Tagging and branching could beimplemented as multiple copies of the model where each copy corresponds toa tag (read-only copy) or branch (writable copy).

A full list of features can be found on the CDO wiki page9. Unfortunately,the documentation of CDO is rather scarce at the time of writing, resulting inan unnecessarily steep learning curve and a high risk of misunderstandings.Furthermore, as it is likely that needs for further extensions of CDO will revealthemselves on the way, the lack of documentation may lead to unnecessarydelays in the development. However, hopefully this shortcoming will be ad-dressed in the future as the CDO project matures.

5.6.3 A Dynamic and Filterable User Interface

The user interface must support both the core elements and the user definedelements of the meta-model. In addition, it should support the filtering mecha-nism suggested in Section 5.4. Consequently, like the data storage component,it cannot be statically hard-coded — a configurable solution is required. A pro-posed design is presented in Figure 5.5.

8http://wiki.eclipse.org/FAQ_for_CDO_and_Net4j9http://wiki.eclipse.org/CDO

57


Figure 5.5: The high-level design of a configurable UI builder

The UI builder component takes two configuration files as input, a UI con-figuration file that maps the meta-model into a user interface and a UI guidancefile that provides guidance to the users how to use the UI. Based on this infor-mation, the UI builder generates a form that can be used to edit or view user-defined content. If the meta-model is implemented using EMF, this is rathereasy to implement as EMF supports generic access to data.

The following example illustrates this design. Consider the following userdefined meta-model element:public interface MyMetaModelExtension extends CDOObject {

// Setter methods omitted for simplicity.

public Role getResponsibleRole();

public String getName();

public String getShortDescription();

public String getLongDescription();

public WorkProduct getInput();

public WorkProduct getOutput();

}

According to the customer’s specification, the user interface for this elementshould have two pages, one with general information (name and descriptions)and another with detailed information (responsible role, input and output).This could be achieved with a UI configuration file that looks something likethis:<ui-config class=”MyMetaModelExtension”>

<page id=”general” title=”General␣Information”><field name=”name” label=”Name:”/>

<field name=”shortDescription” label=”Short␣Description:”/><field name=”longDescription” label=”Long␣Description:” rows=”5”

/>

</page>

<page id=”details” title=”Detailed␣Information”><field name=”responsibleRole” label=”Responsible␣Role:”/>

58

(a) The General Information page (b) The Detailed Information page

Figure 5.6: A mock-up of the generated user interface

<field name=”input” label=”Input:”/>

<field name=”output” label=”Output:”/>

</page>

</ui-config>

A mock-up of what the generated user interface might look like is presentedin Figure 5.6. Note, that the text attributes have ordinary text fields, whereasthe references (Role, WorkProduct) have a button for looking up existing ob-jects. Finally, some usage guidelines are specified in a guidance file that lookssomething like this:<ui-guidance class=”MyMetaModelExtension”>

<field name=”name”>

Provide a name for the element.

</field>

<field name=”shortDescription”>

Provide a short description of the element. It should contain

....

</field>



</ui-guidance>

The UI filter component also take a configuration file as input that specifieswhich parts of the UI are to be visible in different contexts. The idea behind thiscomponent is explained in Section 5.4. Continuing on the previous example,the filter configuration file could look something like this:<ui-filter class=”MyMetaModelExtension”>

<context name=”simple-browsing”>

<include name=”name”/>

<include name=”shortDescription”/>

</context>

<context name=”everything-except-role”>

59


<exclude name=”responsibleRole”/>

</context>

</ui-filter>

In this case, there are two contexts to choose from. In the “simple-browsing”context, only the name and short description fields are visible. In the “everything-except-role” context, everything except the responsible role field is visible. Theactive context could for example be selected manually or deduced from the roleof the user.

5.6.4 Front-end Implementation Approaches

The previous section discussed how to make the user interface dynamic andfilterable. However, there is more to the front-end than this. From the user’spoint of view, the front-end is the most important part of the authoring tooland has a significant impact on how well the tool is adopted by the users.

The primary responsibilities of the front-end is to support authoring andbrowsing of the process content, to determine and merge differences betweennormative and collaborative process versions and to control the parts of the im-port/export engine that deal with reports and integration with external toolssuch as diagram editors or project management tools.

As promised in Section 5.6.2, two approaches to implementing the front-endwill now be discussed: the wiki approach and the rich client approach.

The Rich Client Approach is basically what EPC/RMC uses today, i.e. thefront-end runs on the user’s desktop. Thus, one advantage of using this ap-proach is that parts of the existing EPC/RMC code base can be reused. How-ever, the current file-based storage system would have to be replaced with CDOand support for the customizable meta-model and user interface would haveto be added.

A schematic overview of this approach is presented in Figure 5.7. The repos-itory runs in a separate OSGi-container on a server, the rest of the features areclient-side. This has the advantage of reducing the load on the server and dis-tributing it over the clients instead, thus making the system faster.

The disadvantage with this approach is that it makes collaboration harder asall users would have to download and install the tool on their local desktopsin order to work on the collaborative process versions (i.e. the situation wehave today). Another disadvantage is that the distribution of updates becomesmore difficult. Also, given the current state of CDO, the TCP/IP-link betweenthe server and the client must not be broken while the users work on the data

60


Figure 5.7: Schematic overview of the rich client approach

in the repository. Thus, the advantage of offline operation currently availablein revision control systems such as CSV and Subversion is also lost.

The Wiki Approach is the approach advocated in Section 5.1 and is basi-cally a continuation of the concepts used in IPA. A schematic overview of thisapproach is presented in Figure 5.8. Unlike the rich client approach, all the fea-tures are server-side and run in a JEE web container. The repository runs in anembedded OSGi-container.

The wiki front-end supports both traditional free-form page editing and struc-tured editing as defined by the meta-model. The former is used for discussionand feedback, whereas the latter is for editing of the actual process content. Thestructured edit forms are generated by the user interface builder described inSection 5.6.3.

There are many advantages with this approach, some of which have alreadybeen discussed in Section 5.1. The accessibility and the maintainability of thesystem are increased. The latest version of the tool is always used and all a userneeds in order to view and edit process content is a web-browser and a set ofcredentials.

The disadvantages with this approach are reduced user interface flexibility(e.g. graphical diagram editors) and no support for offline operation. How-ever, by using technologies such as JavaFX or Adobe Air, the former can be

61


Figure 5.8: Schematic overview of the wiki approach

overcome. It is also technically possible to overcome the latter, but it is ques-tionable whether the value added corresponds to the work effort required todo it.

62

6 Conclusion

This chapter summarizes the key points of this thesis and provides somepointers to related work.

6.1 Summary

A software process is the ordered set of activities and associated results that areperformed throughout the software life-cycle in order to transform the systemfrom one state to another. The process can be either ad libbed or predefined,but in either case it controls how a system is being developed. By using a pre-defined process, it becomes easier to plan and schedule the project, handle thescope of the project, manage risks, etc. It does not, however, completely elim-inate the risk of project failure — a wrongly chosen software process might bedevastating to the project.

A software process can normally be defined in terms of a process model andsome process methods. The process model addresses the questions What shallwe do next? and How long shall we continue to do it? A process method addressesthe questions How are we going to do this? and Why are we doing it this way?

All software projects are unique and therefore require unique software pro-cesses. However, the similarities between projects are often larger than thedifferences. Therefore, it is common to collect general software methods andprocess models into a process framework, that is tailored to fit the needs of aparticular project.

A predefined software process is of no use if it cannot be successfully com-municated to the developers of the software. For this purpose, a process de-scription is used.

The people who have the best understanding of what parts of the processwork and what parts do not are the software developers. Therefore, it is im-portant that the experiences of and lessons learned by the developers are fedback into the process description in order to improve the process and preventfuture projects from repeating mistakes. In other words, the process descrip-tion should actually act as a knowledge repository.

63

6 Conclusion

The problem with this approach is that many process authoring tools are cur-rently designed around the traditional process engineering principle, where adedicated team of process developers develop the process and then release itto the software engineering teams for adoption. In order to fully support acollaborative approach to process authoring, the tools need to change.

Another problem that the tools are struggling with is that their vendors havetried to squeeze all possible process modeling concepts into them without properfiltering and scaling capabilities, making them difficult and clumsy for smallerprocesses.

The tool vendors should shift focus and concentrate on making their toolsmore collaborative, customizable and scalable to different process sizes. In thisthesis, some ideas of how this could be achieved have been presented, of whichone of the more interesting ones is a wiki-based process authoring tool.

6.2 Related Work

Si-zhu Zhou et al. [22] have developed a system for co-operative process de-sign. Their Computer Aided Process Planning (CAPP) system is not designedfor software engineering processes in particular, but for processes in general.Although CAPP includes several of the ideas presented in this thesis, it stillseems to focus on the traditional process engineering paradigm where pro-cesses are developed by a dedicated team of professional process engineers.Nonetheless, CAPP is yet another indication of the direction in which processengineering is going today.

In their article “Enough Process - Let’s do Practices” [11], Jacobson et al.present process concerns similar to those presented in this thesis. For exam-ple, the idea of a knowledge repository is also presented in their article, al-though they use a slightly different vocabulary. They also write about some ofthe problems that software engineering projects are dealing with today, suchas the problem of adopting a complete process and the problem of acquiringknowledge.

Jacobson et. al present an interesting approach to solving the problems: prac-tices over processes. In short, a practice can be defined in the following way[11, p47]:

“[It] is a proven way of approaching or addressing a problem. It is some-thing that has been done before, can be successfully communicated to oth-ers, and can be applied repeatedly producing consistent results.”

64

6.2 Related Work

The practices can address many different areas of software development,such as software engineering (developing components, designing user inter-faces, etc.), social engineering (teamwork, collaboration, etc.) and organization(project milestones, financial controls, etc.).

Jacobson et al. suggest that a process should be considered as a collection ofpractices. The developers would pick out the practices they need for the projectin question and adopt them in whatever combination and at whatever speedsuits them. If they come up with a new practice during development, it is alsoadded to the collection.

Jacobson et al. have developed a smart framework named EssWork for im-plementing practice based approaches. The framework is freely available onthe Internet1 and is to be donated to the Eclipse Process Framework [11, p64].

1http://www.ivarjacobson.com

65

6 Conclusion

66

Svensk sammanfattning:Framtidensprocessredigeringsverktyg

Inledning

Inom programvaruindustrin har användningen av programvaruprocesser bli-vit allt viktigare under de senaste årtiondena. På grund av mjukvarans uni-ka karakteristika är dock traditionella tillverkningsprocesser inte lämpliga förprogramvaruutveckling. Detsamma gäller även utvecklingen av själva proces-serna — framtidens programvaruprocesser kommer att utvecklas inte bara avtraditionella processingenjörer (som ofta är fallet idag) utan även av alla depersoner som aktivt tillämpar processerna i riktiga projekt.

Under sommaren 2008 begärde det finska IT-företaget EB2 en utvärdering avde största processutvecklingsverktygen på marknaden. Syftet var att hitta ettnytt verktyg för dokumentering och utveckling av företagets interna program-varuutvecklings- och projektledningsprocesser. Resultatet av denna utvärde-ring var en intern rapport, på vilken detta diplomarbete är baserat.

Programvaruprocesser

Alla programvarusystem genomgår en s.k. programvarulivscykel som består avtvå huvudsakliga faser: utvecklingsfasen och underhållsfasen.

Under utvecklingsfasen utvecklas själva systemet. Alla system börjar med enidé eller ett behov. Ifall idén bedöms vara realistisk eller lönsam utvecklas denvidare till en specifikation. Specifikationen ligger sedan som grund då systemetutvecklas (dvs. planeras och implementeras). Innan systemet tas i bruk måstedet dessutom testas så att man kan vara säker på att det fungerar i enlighet medspecifikationerna.

2http://www.elektrobit.com

67

Svensk sammanfattning

Underhållsfasen tar vid efter att systemet tagits ibruk och tyngdpunkten härligger på att hålla systemet fungerande och användbart. De flesta programva-rusystem innehåller någon form av förenklad modell av omvärlden. Som tidi-gare nämnts förändras dagens värld mycket snabbt och därför är det viktigt attäven programvarusystemen uppdateras i samma takt.

Slutligen kommer så den dag då systemet inte längre klarar av att fylla om-världens behov. Kanske klarar det inte längre av att uppfylla alla krav somställs på det, kanske har behovet av systemet försvunnit av någon anledningeller kanske har det helt enkelt ersatts av ett nyare, bättre system. Systemet tasur bruk och underhållsfasen avslutas.

Ett programvarusystem utvecklas dock inte av sig självt. Varje förändringsom ett system genomgår under sin livscykel är ett resultat av en eller fleraaktiviteter utförda av människor eller maskiner. Dessa aktiviteter, med tillhö-rande resultat, kallas för en programvaruprocess. Nämnvärt är dessutom att ak-tiviteterna kan vara antingen improviserade eller utförda enligt en på förhandbestämd plan.

Det finns i praktiken lika många programvaruprocesser som det finns pro-gramvarusystem. För att göra det lättare att analysera och jämföra olika pro-cesser använder man sig av processmodeller.

En processmodell är en abstrakt, förenklad representation av en programva-ruprocess. Modellen innehåller information om i vilken ordning de olika akti-viteterna skall utföras och kriterier för när en aktivitet kan avslutas respektivepåbörjas. Med andra ord kan man säga att modellen besvarar frågorna Vad skallvi göra efter detta? och Hur länge skall vi hålla på?

Även om alla processer är unika är likheterna mellan dem ofta flera än skill-naderna. Vanligen är det möjligt att modellera en programvaruprocess medhjälp av en sekventiell processmodell, en iterativ processmodell eller en kom-bination av båda.

I en sekventiell processmodell utförs alla aktiviteter endast en gång och i enpå förhand bestämd ordning. När en aktivitet väl är avslutad är det såledesför sent att gå tillbaka och ändra på någonting och när alla aktiviteter har av-slutats är systemet färdigt. Ett typexempel på en sekventiell processmodell ärvattenfallsmodellen. Denna kommer dock inte att diskuteras i denna samman-fattning.

En iterativ processmodell liknar de iterativa lösningsmetoderna som användsinom numerisk analys. I stället för att utveckla hela systemet på en gång delasaktiviteterna in i iterationer som gradvis utvecklar systemet. Detta gör det möj-ligt att börja utvecklingen i ett tidigt skede, t.o.m. före alla krav har identifierats.

68


Resultatet av en iteration är oftast ett fungerande system som kan demonstrerasför kunden eller t.o.m. tas i produktionsbruk. Kundens kommentarer användssedan som indata för nästa iteration, som ytterligare utvecklar systemet, osv.Man kan säga att systemet växer för varje iteration. Två typexempel på iterativaprocessmodeller är spiralmodellen och Extreme Programming. Dessa kommerdock inte att diskuteras i denna sammanfattning.

Krav på processbeskrivningar

Den konkreta representationen av en process kallas för processbeskrivning. Pro-cessbeskrivningen har fyra huvudsyften: att kommunicera processen till andra,att främja återanvändning av existerande processelement, stödja utvecklingen avprocessen samt underlätta hanteringen av processen.

Det första delmomentet av EB-utredningen var att samla in krav på process-beskrivningar. Kravinsamlingen understöddes av två grupper, en användar-grupp och en intressegrupp. Användargruppen bestod av erfarna processut-vecklare inom företaget som förväntades aktivt delta i kravinsamlingen. Intres-segruppen bestod av personer inom företaget som av olika orsaker inte kundedelta aktivt i själva kravinsamlingen, men som ändå hade intresse av att följamed utredningen.

I början av kravinsamlingen skickades en enkät till alla medlemmar i an-vändargruppen. På basis av enkätsvaren och de existerande processbeskriv-ningarna sammanställdes en första uppsättning krav som publicerades på fö-retagets interna wiki-sidor. Efter en kommenteringsrunda hos såväl användar-gruppen som intressegruppen sammanställdes sedan den slutgiltiga uppsätt-ningen krav.

Ett centralt tema som gång på gång dök upp under kravinsamlingen var sam-arbete. Processanvändarna (dvs. programutvecklarna) kan antas vara experterinom sin bransch. De har en god uppfattning om vad som fungerar och vad sominte gör det. Ur processutvecklingssynvinkel är det mycket viktigt att dennakunskap enkelt och effektivt kan återkopplas till processen, så att t.ex. misstaginte upprepas i onödan.

Återkopplingen är även viktig ur en psykologisk synvinkel. Eftersom en pro-cess inför begräsningar på hur de förväntas arbeta finns det en risk att utveck-larna börjar se processen mera som ett hinder än ett hjälpmedel. Detta kan und-vikas genom att låta användarna själva delta i processutvecklingen.

69


Verktygsutvärdering

Det andra delmomentet i EB-utredningen var att på basis av kraven i föregåen-de sektion utvärdera olika processredigeringsverktyg. Endast välstödda verk-tyg med lång livslängd togs i beaktande, eftersom syftet med utvärderingenvar att välja ett nytt verktyg för hela EB.

Utvärderingen gjordes i tre steg. Först modellerades utvalda delar av företa-gets interna processer med verktyget. Syftet med detta steg var att kontrolleraatt processerna kunde modelleras strukturmässigt. Sedan utfördes fyra på för-hand definierade användarscenarier, vilkas syfte var att kontrollera att verk-tyget fungerade i typiska användningssituationer. Till sist kontrollerades deåterstående kraven manuellt.

Fyra olika verktyg ingick i utvärderingen: ett internt verktyg, EPF Composer,Rational Method Composer och IRIS Process Author.

Det interna verktyget har utvecklats inom EB under flera år och var det verk-tyg som användes för processutveckling inom företaget då utvärderingen gjor-des. Verktyget är implementerat i Java och är dokumentbaserat, vilket innebäratt det fungerar med de vanligaste versionskontrollsystemen. Meta-modellenär flexibel och konfigurerbar, men inte SPEM3-kompatibel. Verktyget har enflexibel exportfunktion och kan exportera processbeskrivningen till bl.a. Word,HTML och PDF.

EPF Composer (EPC) är ett processredigeringsverktyg som utvecklas inomEclipse Process Framework (EPF)-projektet. EPC har öppen källkod och byggerpå Eclipse- plattformen. EPC är liksom det interna verktyget dokumentbaseratoch fungerar därför med de vanligaste versionskontrollsystemen. Ett av målenmed projektet är att verktyget skall vara fullständigt SPEM-kompatibelt, mendetta mål har inte ännu uppnåtts.

Rational Method Composer (RMC) är en kommersiell version av EPC och endel av IBMs Rational-programsvit. Alla egenskaper hos EPC finns således ävenhos RMC. Utöver detta har RMC några mer avancerade funktioner, bl.a. föratt skräddarsy processer. Även rapporteringssystemet BIRT (Eclipse BusinessIntelligence and Reporting Tools) har integrerats.

IRIS Process Author (IPA) är ett kommersiellt verktyg som utvecklats avdet kanadensiska företaget Osellus. IPA är helt och hållet webb-baserat ochborde därför fungera med vilken modern webbläsare som helst. I praktikenverkar det dock som om endast Internet Explorer skulle fungera ordentligt.Tillsammans med IPA kommer en annan produkt, IRIS Process Central (IPC)

3SPEM är en metamodell för representation av processbeskrivningar.

70


som fungerar som ett förråd för processbeskrivningar. Från IPC är det möjligtatt ladda ner processbeskrivningar i olika format (bl.a. HTML, PDF, Word ochMicrosoft Project). IPC har även funktioner för insamling av kommentarer frånanvändarna, bl.a. genom wiki- och bloggfunktioner. Meta-modellen är SPEM-kompatibel.

I samband med utvärderingen upptäcktes flera brister i verktygen. I dennasammanfattning kommer dock enbart de brister som har med samarbete mel-lan processutvecklare och -användare att diskuteras.

De tekniska möjligheterna för processanvändarna att bidra med kommenta-rer och erfarenheter var obetydliga i både EPC och RMC. Det interna verktygetutnyttjar företagets interna wiki-sidor för kollaborativ processutveckling, me-dan IPA har inbyggda funktioner för ändamålet i form av wikisidor och blog-gar.

Alla verktyg utom IPA använder sig av externa versionshanteringssystemsom CVS eller Subversion. Problemet med dessa är att de fungerar på filnivå.Om konflikter upptäcks måste den långsammare användaren antingen skrivaöver sina ändringar med de nya och börja om från början, eller försöka sam-manfoga sina ändringar med den uppdaterade versionen. Detta kan vara lät-tare sagt än gjort, eftersom detta kan innebära att användaren måste öppna fi-lerna med t.ex. en XML-editor och utföra ändringarna där. Eftersom flera filerkan behöva ändras och allt arbete görs på kodnivå är risken stor att någontinggår fel.

IPA har försökt lösa problemet genom att använda en låsningsmetod somförsäkrar att endast en användare åt gången kan arbeta på ett processbiblio-tek. Nackdelen med detta är att det potentiellt försvårar samarbete, då endasten användare åt gången kan arbeta på processen. Om processbiblioteken hållstillräckligt små, vilket rekommenderas eftersom det förbättrar möjligheter tillåteranvändning, är detta dock inget problem.

Ett lösningsförslag: Wiki-baserad

processredigering

I diplomarbetet presenteras flera förslag till lösningar på de problem som upp-dagats under verktygsutvärderingen. I denna sammanfattning kommer dockendast ett av förslagen att diskuteras, nämligen utvecklingen av ett wiki-baseratverktyg för processredigering.

Under de senaste åren har wikin blivit ett allt populärare samarbetsverktyg

71


inom olika organisationer. I ett wikisystem är det enkelt att skapa, redigera ochsammanlänka sidor och normalt kan allt innehåll redigeras av alla användare.Alla revisioner lagras, vilket innebär att det är möjligt att när som helst gå till-baka till en viss tidpunkt och se hur wikin såg ut just då.

Genom att tillämpa wiki-modellen på processredigering skulle både proble-met med bristande påverkningsmöjligheter bland processanvändarna och pro-blemet med versionshantering lösas.

Samma gränssnitt skulle användas för såväl läsning som redigering. Dettaskulle innebära att en processanvändare inte behövde installera något verktygeller söka upp en separat sida för att ge kommentarer.

Versionshanteringen skulle även underlättas av att alla revisioner lagras. Ifalltvå användare av misstag skrev över varandras ändringar skulle båda versio-nerna finnas kvar. Några extrafunktioner, som t.ex. hantering av olika versio-ner av samma process och överflyttning av data mellan processversioner, skul-le dock krävas för att göra systemet användbart för fullskalig användning.

Utvecklingen av ett dylikt processredigeringsverktyg är inget trivialt projekt.Det är dock fullt möjligt att genomföra — IPA är redan på väg i rätt riktning.

Avslutning

Även om diplomarbetet har behandlat flera olika aspekter av processredige-ring har tyngdpunkten i denna sammanfattning varit samarbetet mellan pro-cessutvecklare och processanvändare. Orsaken bakom detta är att just dennaaspekt blir allt viktigare hela tiden. Under det senaste decenniet har samarbeteblivit allt viktigare inom programvaruutvecklingen, främst tack vare de agilaprogramvaruprocesserna. Därför är det naturligt att även övergå till ett agiltsynsätt inom processutvecklingen.

Tiden då processer i huvudsak utvecklades av en liten grupp experter är för-bi. Tillverkarna av processredigeringsverktyg borde under de kommande årenkoncentrera sig på att göra sina verktyg mera samarbetsvänliga och ta såvälprocessutvecklarnas som processanvändarnas behov i beaktande.

72

Bibliography

[1] Manifesto for Agile Software Development. http://

agilemanifesto.org/ (last accessed on April 2, 2009).

[2] Scott W. Ambler. Agile Database Techniques. Wiley Publishing, 2003.

[3] Scott W. Ambler. Has Agile Peaked? Dr. Dobb’s Journal: The World ofSoftware Development, 33(6):52–54, June 2008.

[4] Kent Beck. Embracing Change with Extreme Programming. IEEE Com-puter, 32(10):70–77, October 1999.

[5] Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pi-lato. Version Control with Subversion. Published online,http://chestofbooks.com/computers/revision-control/

subversion-svn/index.html (last accessed on March 12, 2009),2008.

[6] Herbert D. Benington. Production of Large Computer Programs. In Pro-ceedings of ONR Symposium on Advanced Programming Methods for DigitalComputers, June 1956.

[7] Barry W. Boehm. A Spiral Model of Software Development and Enhance-ment. IEEE Computer, 5(21):61–72, May 1988.

[8] Robert N. Charette. Why Software FAILS. IEEE Spectrum, 42(9):42–49,September 2005.

[9] Alistair Cockburn. Agile Software Development. Addison-Wesley, 1stedition, 2001. The excerpt used in this thesis is available from http:

//alistair.cockburn.us/Shu+Ha+Ri (last accessed on March 12,2009).

[10] Edsger W. Dijkstra. The Humble Programmer. Communications of the ACM,15(10):859–866, October 1972.

73

Bibliography

[11] Ivar Jacobson, Pan Wei Ng and Ian Spence. Enough Process - Let’s DoPractices. Journal of Object Technology, 6(6):41–66, July-August 2007.

[12] Dorthe R. Jespersen and Janus Boye. UNtangling ENTERPRISE WIKIS.EContent, 31(9):30–34, November 2008.

[13] Marc I. Kellner. Representation Formalisms for Software Process Mod-elling. In Proceedings of the 4th international Software Process Workshop onRepresenting and Enacting the Software Process, pages 93–96, Devon, UnitedKingdom, 1988.

[14] Craig Larman. Applying UML and Patterns. Prentice Hall, 3rd edition, 2005.

[15] Robert C. Martin. Agile Software Development: Principles, Patterns and Prac-tices. Prentice Hall, 2003.

[16] Daniel D. McCracken and Michael A. Jackson. Life-Cycle Concept Con-sidered Harmful. SIGSOFT Software Engineering Notes, 7(2):29–32, April1982.

[17] Peter Naur and Brian Randell, editors. Software Engineering: Report of a con-ference sponsored by the NATO Science Committee, October 1968. The reportis freely available from http://homepages.cs.ncl.ac.uk/brian.

randell/NATO/index.html (last accessed on March 12, 2009).

[18] OMG. Software & Systems Process Engineering Meta-Model SpecificationVersion 2.0. Specification, Object Management Group, Inc., April 2008.OMG Document Number formal/2008-04-01.

[19] Winston W. Royce. Managing the Development of Large Software Sys-tems. In Proceedings of IEEE WESCON, pages 1–9, August 1970.

[20] G. Michael Schneider and Judith L. Gersting. Invitation to Computer ScienceC++ Version. Thomson Course Technology, 3rd edition, 2004.

[21] Robert W. Sebesta. Concepts of Programming Languages. Addison-Wesley,8th edition, 2008.

[22] Si-zhu Zhou, Yan Liao, Yong Li and Ning Li. Research of multi-modelcooperative process design system. pages 667–671, April 2008.

[23] Ian Sommerville. Software Engineering. Addison-Wesley, 8th edition, 2007.

74

Bibliography

[24] Jenjira Wongboonsin and Yachai Limpiyakorn. Wikipedia Customizationfor Organization’s Process Asset Management. International Conference onAdvanced Computer Theory and Engineering, pages 467–471, 2008.

75

ideas for the next generation process authoring toolusers.abo.fi/peholmst/thesis.pdf · master’s...

Documents