Software evolutionary dynamics modelled as the activity of an actor-network

IETdoi:

www.ietdl.org

Published in IET SoftwareReceived on 30th July 2007Revised on 4th January 2008doi: 10.1049/iet-sen:20070093

In Special Section on Software Evolvability

ISSN 1751-8806

Software evolutionary dynamics modelledas the activity of an actor-networkP. Wernick1 T. Hall2 C.L. Nehaniv1

1School of Computer Science, University of Hertfordshire, College Lane, Hatfield, Hertfordshire AL10 9AB, UK2Department of Information Systems and Computing, Brunel University, Uxbridge UB8 3PH, UKE-mail: [email protected]

Abstract: The pressures which act on a software system over its life from inception to retirement are many andvaried. An important goal in researching software evolvability is to understand, and if possible to manage, theseinfluences. The authors’ previous simulations of software evolution processes have concentrated on capturing thehuman-related aspects of software evolution, while effectively treating technical entities as objects whichare acted on by humans and their organisations. Latour’s actor-network theory (ANT) suggests thatthe non-human entities – development tools, documents, the evolution process itself – are potentially activeparticipants in their own evolution. The authors describe Latour’s theory and present a model of a softwareevolution process in the form of a diagram which places technical and human aspects in a closer juxtapositionthan previous models. They present support for this model from an analysis of a published case study ofsoftware development and a proof-of-concept calibration. They believe that an ANT-based approach will resultin a more accurate representation of the long-term software evolution process and thus be a step towardsdynamic simulation models whose predictive power will help us to better understand and manage softwareevolution and evolvability.

1 The problem and a possiblesolutionFor some time, software researchers and practitioners havebeen attempting to understand the processes by whichsoftware systems are changed over time, usually with theintention of finding ways to manage and control them.Lehman and co-workers [1] have described the collectionsof people, artefacts and events which control the evolutionof industrial software-based systems as the ‘global softwareprocess’. They observe that this process includes ‘. . . theactivities of all involved, for example, developers, managers,marketers, support personnel and users’.

Lehman’s view of the global software process, supported byour earlier system dynamics simulation models [2–5], sees thisprocess as being primarily driven by feedback. This is madeexplicit in the VIIIth Law of Software Evolution. This lawstates: ‘E-type evolution processes constitute multi-level,multi-loop, multi-agent feedback systems and must betreated as such to achieve significant improvement over any

Softw., 2008, Vol. 2, No. 4, pp. 321–33610.1049/iet-sen:20070093

reasonable base’ [6], that is, the global software process isstated to be a feedback-driven system, in which the effects ofthe outer loops predominate over those of the inner loops.This Law is applied here to produce a model in which thebehaviour of the global process is controlled by theexplicitly-modelled actions and attitudes of developers,managers, marketers and others rather than by technicalaspects of the software production process. In our previoussimulation models, intended to represent the highest-levelcausal mechanisms producing observed patterns ofcommercial software evolution [2–5], these technicalmechanisms have been highly abstracted. This approach hasbeen carried over into the current work.

Our approach to the description presented here of thesoftware evolution process has been driven by our concernwith one aspect of past work of this type. Previousdescriptions of the global software process have tended tobe based on an explicit or implicit division of these agentsinto ‘active’ people and ‘passive’ technical elements. Theinfluence of this mind-set can be seen, for example, in [1],

321

& The Institution of Engineering and Technology 2008

322

& T

www.ietdl.org

in which Fig. 1 shows a program surrounded by people, whoare interacting with it but are very obviously seen by theauthors as different sorts of things from the program itself.This mode of thinking is also to be seen in our pastsimulation models [2–5].

In contrast, Latour’s actor-network theory (ANT) [7], atheory of the process by which technological change occursderived from a sociological standpoint, provides us with aviewpoint from which the effects of both human andtechnical participants on process content and behaviour canbe considered on a more equal footing. We believe thatlooking at the problem from a point of view which gives abetter balance between the effect of social and technologicalparticipants will result in a more accurate representation ofreal-world global software processes. Due to their numberand complexity (which we demonstrate below), the human/social influences in the global software process mayoutweigh technical issues in determining the long-termbehaviour of that process. In addition, newly-proposedtechnical solutions, often marketed as ‘solutions’ to issuesor problems raised by the need to evolve software systems,must be assessed on the basis of their effect on the combinedhuman–technical process rather than as purely technologicalfixes. It is therefore important to understand the socio-technical networks within which the technical work isundertaken, such as the social embedding of the technicalprocess and promotion of interaction between users anddevelopers explicit in extreme programming (XP) [8].

Our objectives in applying ANT to the global softwareprocess are both to understand better the conditions underwhich software is (or is not) evolved, and to explainbehaviours observed when a system evolves, such as the‘regeneration points’ in the growth in size over time ofsoftware systems when these systems show an increase inthe rate of size growth after a period of progressive declinein that rate [2].

In the final analysis, we are interested in finding out whatdetermines the ability or likelihood of the process evolving asoftware-based system to continue enhancing that system atany time (which we refer to below as the ‘health’ of theprocess), and whether future trends can be predicted byexamining the current state of the process evolving thatsystem. We believe that an important step towardsachieving this goal is the identification of the elementsmaking up the process, and an understanding of how theseelements interconnect and interact to produce thebehaviours we observe. Achieving this understanding is anecessary (but not sufficient) condition for controlling theprocesses by which software is evolved.

The remainder of this paper is structured as follows. ANTis described in outline in Section 2. Its relationship to thesoftware evolution processes and some initial thoughts onhow ANT can be used to describe that process are set outin Section 3. An ANT-based model of the process,

he Institution of Engineering and Technology 2008

including some of the issues which need to be consideredin building this model, is described in Section 4. Initialconclusions derived from the model-building process areset out in Section 5. In Section 6, the basic validity of themodel is established by reference to a description in theliterature of a software evolution process [9], and anabstracted calibration of the model is described togetherwith tentative conclusions drawn from this exercise. Section7 sets out an approach towards a real-world calibration ofthe model and final conclusions of our work to date aredrawn in Section 8.

2 Introduction to ANTThe following description of ANT is based on two works byBruno Latour: a formal description of ANT [7] and a moreplayful but nevertheless highly illuminating account of thefailure of a technological project [10].

ANT, the underlying basis of the work presented here, canbe summarised as a view of the social world which:

† sees the complex behaviours of that social world and ofsocio-technical situations in it as being caused to a greatextent by the inter-relationships between the variousentities forming it, and

† allows non-human entities to participate as entities ingenerating those complex behaviours in a way which givesthem equivalent weight to that commonly given to people;this is to Latour the major distinction between ANT and‘traditional’ sociology.

Latour claims that this view results in a major distinctionfrom ‘traditional’ sociology. He suggests that the latterdemands the addition to what can actually be seen in asituation of some intangible thing, the ‘social’ dimension,in order to explain it. He seems to see the ‘social’ asdescribed by other sociologists as some variety ofsociological phlogiston, and to regard this substance asbeing as useful in promoting understanding as the original.Latour himself sees no separate ‘social’ medium in whichpeople and technologies float; instead, a situation compriseshuman and non-human entities and the interconnectionsbetween them. He further suggests that social situations aredifferent from other, non-social situations due to thecomplexity of interactions between the entities which makethem up, rather than because of the presence of some‘social’ substance external to and separable from them.

Latour divides the entities in any social situation analysedusing ANT into three types, viz. actors, mediators andintermediaries. ‘Actors’ are active in the situation and aremost often people but can also be technological entities oranything else involved in the situation. Latour states thatactors are called this because not only do they act but alsobecause they are constrained by their situations in thechoices they are able to make, in the same way as an actor

IET Softw., 2008, Vol. 2, No. 4, pp. 321–336doi: 10.1049/iet-sen:20070093

IETdoi:

www.ietdl.org

on a stage is constrained by the lines given by the playwright[7, p. 46], and can only be creative within that limited scope.

‘Mediators’ receive and transmit messages from anotherparticipant in a network and translate them into a formwhich can be understood by another participant, but maychange the messages they receive in often-unexpected waysbefore passing them on. Mediators ‘. . .. transform,translate, distort and modify the meaning or the elementsthey are supposed to carry. . . . [their] input is never a goodpredictor of their output; their specificity has to be takeninto account every time.’ [7, p. 39]. Latour gives someexamples of mediators, including law, science, religion andeconomies [7, p. 240].

Like mediators, ‘intermediaries’ receive and transmitmessages, but without changing the content of themessages. An intermediary ‘. . . transports meaning or forcewithout translation: defining its inputs is enough to defineits outputs. For all practical purposes, an intermediary canbe taken . . . as a black box . . .’ [7, p. 39].

These entities are combined under ANT into an ‘actor-network’ which gives the theory its name. This is anidentifiable grouping of actors, mediators and intermediaries,linked together by communications channels. Suchgroupings, and their connecting channels, are ephemeral intheir composition, and coalesce or break up according to thepressures on them. Participants may join or leave a networkover time, creating a dynamic, ever-changing web ofrelationships. In joining a network an actor may also bringother network(s) of which it is a member. This is an exampleof the way in which ANT allows an actor-network to betreated as a single actor in a higher-level network, abstractingthe individual participants in the lower-level network andignoring the detail, in a manner familiar to software designerswhen they abstract detailed differences in creating classes,data types and similar artefacts.

In the same way as the composition of an actor-network,an actor’s degree of commitment to the goals of thenetwork may change over time. This may be due topressures from the actor’s own circumstances, the state ofthe system and its relationship to the actor, and influencesfrom other participants in the network.

Latour’s theories are not universally accepted. They arecontroversial in the world of sociology and elsewhere, atleast in part because they seem to give non-humanparticipants in process characteristics normally ascribed onlyto humans. (See, for example, the comments of Williams-Jones and Graham [11] when they apply ANT in adifferent area.) It is however for this very reason that webelieve that applying ANT as Latour has described it tolong-term software evolution may provide us with a basisfor an analysis of global software processes which canprovide useful insights not available from existing theoriesof software evolution.


3 The global software processand ANT: general correspondencesIn this section, we set out some general points which indicatethat ANT may be useful in analysing situations which resultin a software system being evolved with changingfunctionality over the long term of many years and manyreleases. The same arguments can also be adduced to helpexplain why some software products are not evolved, orwhy the evolutionary processes on many products weakenand eventually stop completely.

One feature common both to our previous accounts of theglobal software process and to ANT as a means of exploringsocial situations is the assumption in both of some measure ofcausality underlying the behaviour of social processes. Thisfits well with the same assumption made explicit in theneed to identify causal links in developing system dynamicssimulation models, including those which we have designed.

Another relevant observation is that current software systemsdo not of themselves ‘evolve’; rather, they are evolved by specificactions performed on their code, data and documentarycontent. At the same time, such a system cannot necessarilybe seen as a passive recipient of evolutionary actions andpressures; its adoption and subsequent changes to it ofthemselves cause evolutionary pressures as part of thefeedback system within which it is used and evolved.Adopting an ANT-based viewpoint enables us to considerthe software system as a participant in its own right, activelycontributing to the processes which lead to its own evolution.ANT provides us with a justification for considering theeffect of a software system on the world, causing as well asundergoing change, despite its not being human.

4 Modelling the global softwareprocess as an actor-networkIn this section, we describe our progress to date in developing anANT-based model presented here of a global software process.The work presented here forms a first step in the developmentof a simulation model of a global software process based onANT principles which can be calibrated against real-worlddata and executed to produce quantified results.

For this model, we have considered a typical, abstract,global large-scale software process evolving a bespokecommercial software system. This model would requirechanges to reflect the differences in processes for otherenvironments such as the evolution of package softwareproducts or for open-source software evolution processes.The participants and the connections forming the structureof our current model have been identified on the basis ofthe writings of Lehman and co-workers e.g. [1], our real-world experience as software developers, as users ofsoftware and in software systems user support, our previous

323


324

& T

www.ietdl.org

research e.g. [12–14], and general domain knowledge of howsoftware development ‘works’.

4.1 Identifying the entities in the globalsoftware process

The first task in building an ANT model of the global softwareprocess is to identify the entities – the actors, mediators andintermediaries – making up the social and technical situationwithin which that process happens and the connectionsbetween them. In this process the adoption of ANT as a basisencourages the consideration of a much wider range ofentities than has been the case in previous model-buildingexercises. An example of this advantage of the ANT approachis that we can consider non-technical aspects of the globalsoftware process within the same framework we use toexamine both technological innovation and changes insoftware development approaches and organisational structures.

Examples of entities directly involved in the evolution processof commercial software include the champions of a system inboth developer and customer organisations, customers for thesystem, development organisation salespeople, the developersof a system and its users, technologies such as integrateddevelopment environments (IDEs), various natural andartificial languages used in analysis, design and programming,computer and related hardware and the owners of bothdeveloper and user organisations.

In addition it is necessary to consider entities which do notform part of the developer/user complex but which are capableof affecting the behaviour of the software evolution process.These include the general public (included in the modelbelow as ‘wider society’). This represents the influences of,for example, the media, and of government and its agenciessuch as tax authorities, police and the security agencies. Weconsider that taking such wider influences into accountwhen considering software evolution as a phenomenon isessential to gaining an understanding of how and why thetechnical software processes which convert requirementsinto delivered systems operate as they do.

For example, a change in the taxation regime for investmentin software may contribute to a decision by softwaredevelopment organisation owners as to whether to invest inenhancing a particular product. Another recently-publicisedexample is the demand by government agencies forinformation on internet traffic [15], resulting in a need on thepart of internet service providers (ISPs) to retain additionaldata. This in turn requires actions within relevant softwareevolution processes by the suppliers of network monitoringand control equipment and software to ISPs, and potentiallythe addition to the existing actor-network of another actor-network of suppliers of such equipment/software beyondthose previously involved in evolving the system.

The effects of major corporations which can by their size orposition either directly or indirectly influence the evolution of


a software product also need to be considered. In particular,the influences of competing developer and userorganisations and the products they produce and use mustbe taken into account. An example of this is Microsoft’sinfluence on the PC operating system and web browsermarkets.

An additional issue which needs to be considered is thesituation in which different actors refer to the same projector product by the same name but are actually referring todifferent things [10]. This may require consideration of thenature of relevant products and processes and the processesby which a name is given to a process or product [16].

These examples show the potential difficulty in identifyingall significant participants in the global software process andevaluating their influences on the behaviour of that process,whether direct or indirect. In addition, we need todetermine whether each of these entities is performing asactor, mediator or intermediary. At this point we may beable to treat some groups of actors as actor-networks, thatis, individual complex entities not requiring furtherdecomposition, and identify others which cannot beabstracted in this way and must be broken down intoindividual participants.

In addition to identifying participants, the influences onindividual actors which may cause them to maintain orchange behaviours or make specific decisions must beidentified. For example, the model should be able topredict the effects of key development staff deciding toleave a project, or increasing difficulty over time in hiringpeople with the necessary expertise to evolve systemsdeveloped with older technologies. This has occurred in thepast when programming languages and tools in general usehave become obsolescent and thus less popular amongdevelopers, resulting in problems in meeting demand forthis knowledge, as evidenced by the effect of the Year 2000problem on employability of Cobol programmers.

4.2 Modelling the network

Having identified the entities which need to be representedin the model, the next step is to classify them into actors,intermediaries and mediators, and identify the relationshipsbetween them. We have been conservative in identifyingthe communication links between entities to reduce thecomplexity of the model structure.

At this stage we can take advantage of the ability in ANTwhich we referred to above to abstract what is represented byan actor. The human ‘actors’ we have identified are notnecessarily each intended to represent an individual person.Instead, each is a role taken by one or more people orimposed on a situation by societal, organisational or otherdemands. More than one role can be taken on by oneperson, or one role undertaken by one or many people. Someactors themselves represent (and abstract) more complex


IETdoi:

www.ietdl.org

actor-networks as single actors whose internal relationshipswe have chosen not to examine at this stage in our model-building. Examples of these are the system’s developers, forwhich all of the technical roles relating to the developmentand evolution of the software – analysts, designersprogrammers, testers and others – have been abstracted to asingle actor-network called ‘developers’, and the various typesof users of a system and its outputs. On the other hand itis extremely likely that in a smaller-scale global processthan that considered here one person will take on more thanone role.

A major change in the model presented here from thatdescribed previously [17] is the elimination from the modelof the system as an actor. This is due to a change ofemphasis in our view of the model itself. Previously we hadconsidered the system to be an active participant in its ownevolution, and its change in functionality over time as oneof the main evolutionary drivers. We have now revised themodel to replace this system-centric view by one in whichthe state of the actor-network actually reflects the rate atwhich it demands further change in the system. Thechange in size of the system over time is now seen as beinga result of this demand. This is the most important aspectof the network, since if this support fails and evolutionaryactivity is discontinued, the system will becomeprogressively less useful and potentially become useless.(Lehman’s VIth Law states: ‘The functional content ofE-type systems must be continually increased to maintainuser satisfaction over their lifetime’ [6].) The mostsignificant output of this network is therefore the currentdegree of support provided by the network for the ongoingdecision to continuing evolving the software system. In themodel and our description of it we refer to this actor as the‘Health of the system evolution process’.

As an initial approximation, we have identified ascandidate intermediaries in our model those participants inthe process which perform their work in a deterministicmanner, such as language compilers, operating systems andfile systems. As required by Latour, once the inputs of suchentities are described their outputs are deterministicallyderivable, even if those outputs go on to have differingeffects on actors in the process. This may be contrastedwith mediators in the global process, whose outputs are notuniquely defined and which may differ from occasion tooccasion. Mediators may therefore be identified with thoseparticipants in the process which are written andinterpreted by humans in possibly different ways. Thisinterpretation may produce more than one output from thesame input. For example, the readers of a document mayinterpret it in ways which differ from those intended by thewriters, depending for example on how the authors wordedthat document. Candidate mediators in the globalsoftware process, not all of which are represented inthe current model, therefore include requirements anddesign documents, the source code of the system (when ithas to be read to be modified by actors taking on the role


of ‘developers’ or similar), and the software system itself,whose actions and outputs are interpreted by its usersin the context both of their models of what is happeninginside it and of its interaction with the external world.

At the high level of abstraction we have adopted indeveloping our initial model, we feel that intermediariesneed not be modelled explicitly, since their only effect is tochange one notation or the equivalent into another in anentirely deterministic manner. They do not change thevalues they carry, but distribute information in the network.However, mediators, which may affect the values of theiroutputs, do need to be identified and reflected in themodel to help understand their effect on the behaviour ofthe global process.

5 Description of the currentmodelThe structure of our current ANT model of a large-scalecommercial global software process is shown in Fig. 1. Thismodel represents an actor-network formed of participantsin the evolution of an abstracted large-scale long-termcommercial software evolution process.

The diagram was drawn using the Vensim system dynamicsmodelling tool [18]. This is in part because its systemdynamics notation provides a simple toolset for drawingsuch directed graphs. In addition its analytical tools allowsome conclusions to be drawn concerning the nature andcomplexity of the interactions between the actors, and itscomputational facilities have enabled an initial calibration ofthe model to be undertaken. However, the main driver, theactor-network, of the model described here is not a systemdynamics model.

In Fig. 1, an actor is represented (arbitrarily) by a hexagonand a mediator by a circle. In each case, the entity’s name isinside the box. The ‘delayed’ variables are artefacts required tosupport the calibration of the model. Lines connecting theentities represent the existence of an information flowbetween the connected entities, with the direction of theflow shown by an arrowhead. Bidirectional flows are shownusing a separate arrow in each direction between, forexample, the System Development Owners and the SystemSalespeople.

One aspect of the model may need explanation; this is thedistinction made between mutable and immutable tools. Theformer are those processes, notations and tools used insoftware development and evolution activities (so ‘tools’ inthe widest sense for software engineering) which are at leastto some extent under the control of the people andorganisations directly involved in work on the system, andwhich can therefore be modified if required for a specificdevelopment or evolution project. For example, apredefined software process whose content is under the

325


326

& T

www.ietdl.org

Figure 1 Structure of ANT-based model of the global software process

control of the project manager may be modified if necessary,or a software tool developed for this project by the system’sown developers may be enhanced, to meet the needs of aparticular project. Such tools can be distinguished fromimmutable tools, which cannot be modified by thoseinvolved in the project. An example of this is the use of anISO 9000-certified process which senior management havedecreed must be followed in this project whatever theconsequences, or of a bought-in closed-source integratedsoftware development environment whose evolution cannotbe influenced or its toolset or embedded process modifiedby this system’s developers, however much they believe theyneed to change its properties.

Some actors or intermediaries included in earlier versions ofour model [17] have been removed as we have continued ourwork on the model since its initial publication, albeit atsome loss of detail. The most significant changes are theelimination of:

† the system as fielded; instead of taking the system itself asthe main entity of interest, we have modified the model toreflect the evolutionary aspects of the process byconcentrating on its propensity to continue evolving the


system. In addition to moving the model closer to ananalysis of social as well as technical issues, this change hasmade easier the initial quantitative calibration describedbelow. The system source code has also now been removed,since the latter can be considered to be a deterministictranslation of the system architecture and design. Here welose detail in our model, in that restrictions are placed onthe system design and its evolvability due to theprogramming language adopted, and the style of designand coding can significantly affect the evolvability of asoftware system. Again, as a simplification we haveabstracted this aspect in the current model, and

† the system specification; this is now combined in the modelinto the change input queue mediator, since the specificationwill itself only be modified to reflect those queued changes.This decision means that the model conflates thetranslation from the problem domain (the input queue) tothe technical computing domain (the effect of this ondevelopers, project managers and the system architectureand design) without reflecting the intervening step ofspecifying the changes in detail in technical terms.However, we currently feel that this loss is outweighed bythe gain in simplification in the model.


IETdoi:

www.ietdl.org

6 Some initial conclusionsThe most cursory examination of Fig. 1 reveals the complexityof the web of social and technical interactions which controlsthe software evolution process. The directional connectionsform a large number of complete cycles; as Lehman’sVIIIth Law suggests, the model comprises a feedbacksystem of great complexity. This in itself may help explainwhy it is so difficult either to theorise about the nature ofthis process, or to control and manage it in practice.

The impression of the complexity of the interactionsbetween actors is both exemplified and reinforced by ananalysis using the Vensim loop analysis tool, which countsand lists the participants in each complete loop in thedirected graph. In this case, the tool showed that there is atotal of 2034 feedback loops in the model. The longestloops in the model pass through 13 entities before turningto their starting points.

An example of a loop in the model, in this case involvingten entities, runs from the Health of the system evolutionprocess through the network, returning to affect its ownvalue at some later time. This loop can be followed throughthe model diagram in Fig. 1 as follows:

Health of the system evolution process

Users

Sponsor/owners

System salespeople

System change input queue

Developers

Project manager

System development owners

Mutable tools

System design/architecture

Health of the system evolution process

Such loops can be examined on the basis that each tells a‘story’ of one influence on how the actor-network operatesto evolve the system. Successfully telling the story bothprovides insight as to how the process might operate andgives some degree of comfort that the model structure isreasonable.

In the case of this example, the story of the feedback loopmight be as follows:

† the current state of the Health of the system evolutionprocess results in changes demanded by the users of thesystem either not being made in a timely fashion or not beingmade at all; this affects its users, perhaps frustrating them orpreventing them from doing their job, or alternativelysuggesting an opportunity to improve the user process byimplementing a software enhancement. The users thereforeraise these issues with the system’s sponsor/owners.


† The sponsor/owners then demand changes in the systemfrom the system salespeople, which results in new changedemands being added to the system change input queue.

† The developers examine these change requests and as aresult of their analysis they find that they need to ask theproject manager to get the system development owners toauthorise changes to the mutable tools.

† The modified tools enable (or make easier) a change to thesystem design/architecture.

† Finally, this architectural change is reflected in anincreased likelihood of the developers continuing to evolvethe system, the ‘Health of the system evolution process’,which results in changes seen by the users in the system asfielded in a subsequent release.

As the thinking underlying ANT suggests should be thecase, this example shows the closeness of interactions betweensocial and technical aspects, reflecting both the technicalsoftware process and the social interactions which surroundand control it. Examples of explanations such as this whichare provided by the model, when discussed with processexperts, will enable us to check the reasonableness of both themodel structure and the individual entities comprising it.

7 Testing the model for validityThe preceding sections describe a model developed on thebasis of theory; the calibration of the model against theparameters and outputs of one or more real-world softwareevolution processes is yet to be performed. In advance ofthat calibration it is possible to check it for ‘face validity’ byconsidering the participants identified in the current modeland their interconnections in the context of publishedreports of actual software development activities, and afeasibility study into its potential quantitative calibration.

An example of each of these approaches is described in thissection.

7.1 The ANT model and descriptions ofsoftware development activities

A sensible place to look for support for the ANT model andthe ideas which underlie its construction and content is in theform of published reports of software development andevolution projects.

An example of such a project is the application of theWinWin spiral model by students learning throughdeveloping a software system in a university setting [9].We feel that the clarity of explanation and the depth of theauthors’ explorations of motivations of the actors’ workoutweigh the fact that the development being examined ismedium-scale student work rather than the large-scale

327


328

& T

www.ietdl.org

commercial development for which our model has beendeveloped.

In [9], the authors’ careful analysis of causes, effects andoutcomes within the multi-threaded development of a suiteof software tools allows us to identify entities in the ANTmodel such as:

† identifiable actors, mediators and intermediaries andnetworks of these;

† the place of immutable tools in the process;

† evidence for the existence of feedback effects betweenactors such as that from system users to developers and

† a noticeable effect on the evolution of the system of actorsand their decisions not directly related to the technical aspectsof development.

Evidence for each of these points is set out below. Althoughthe ANT-based model does not reflect all of the entitiesidentified by Boehm et al., as is to be expected when the twoprocesses differ in aspects such as environment (academicagainst commercial), experience of developer participants(student developers against commercial developers) and someroles (developers are ‘managed’ by academics againstcommercial project and senior managers), there is a sufficientdegree of similarity in what we found to provide support forthe model.

It should first be noted that Boehm et al. refer to thedevelopment of a system. However, we believe that theprocess of multi-cycle software development which theydescribe can be seen as an exercise in the evolution of asoftware system over time.

The underlying idea of the ANT model, that is, the centralityof organisational and inter-participant aspects of a softwareevolution process, is supported by the necessity noted byBoehm et al. to ‘secure the management’s commitment toproceed as planned.’ [9, p. 34].

A number of candidate actors in the process described inthe paper can be identified. These include ‘Users,customers, developers, maintainers, interoperators, generalpublic, others’ [9, p. 36]. This demonstrates the need for abroad scope during the search for participants in the processwhen building the model. Some of the actors identified byBoehm et al. (developer, customer, user), together withtheir individual concerns, are described in more depth[9, p. 37]. The distinction found in practice betweencustomer and user is worth noting here, and is representedin the user against sponsor/owner split in the model.

The importance of the network of participants involved indeveloping a system, as against the individual participants orthe technical aspects, is reflected in the following: ‘We found


that, at least for this type of application, the most importantoutcome of product definition is not a rigorous specification,but a team of stakeholders with enough trust and sharedvision to adapt effectively to unexpected changes. In thebeginning, the library clients were considerably uncertainabout going forward with the projects. By the LCAmilestone, (which represents the completion of the detailedlife-cycle architecture [9, p. 34]), however, the uncertaintyand doubt about working with the student teams had beenreplaced with enthusiasm and considerable trust, althoughmany were still uncertain about the applications’ technicalparameters. This growth continued through thedevelopment period and led to a mutual commitment topursue additional projects in the following year.’ [9, p. 42;our emphasis].

This quotation shows that actors’ degree of support for thesystem can change over time, influenced at least in part by thehealth of the process, and thus by the continued relevance ofthe system. It also demonstrates that an actor within anetwork can affect the behaviour of another, in this casegenerating enthusiasm for the system and its development.

The interactions between actors and the effect on the healthof the process of one actor’s view of the current state of theproject are considered by Boehm and his colleagues. A delayin the development work, in this case a prototype not beingtestable at the expected time, ‘had the unfortunate effect ofdestabilising some of the WinWin agreements and productrequirements’ [9, p. 38]. This shows how non-availability ofchanges to the system can influence in a negative directionusers’ degree of support for the system. On the other hand,a positive effect from exposure to the system is also possible:‘The prototypes generally expanded the librarians’perceptions of what the teams could produce.’ [9, p. 38];‘Other library clients were also very satisfied with the valueadded relative to their time invested.’ [9, p. 39]. In addition,improvements in the health of the process can of itselfpromote user enthusiasm in a virtuous cycle: ‘There werefewer requirements breakdowns in the later stages of the lifecycle, which increased client participation and acceptance tothe point of client activism’ [9, p. 43].

Boehm et al. also provide evidence of the effects ofmanagers on development. On the user side, ‘At timeslibrarians could not provide input on critical decisions,which led to extra rework.’ [9, p. 39]. This negative impacton software development can be seen as the result of usermanagers not supporting the development process to theextent of providing sufficient resources for the users toparticipate in the process to the extent that the latter feel isnecessary. A conclusion of the authors [9, p. 43] is that itis important to ‘. . . make sure the clients are empowered tosupport the product not just with knowledge andenthusiasm, but also with resources for the product’soperation and maintenance.’ This justifies the recognitionin our model of the effect of user managers’ on-goingcommitment to the process as one of the factors affecting


IETdoi:

www.ietdl.org

the health of the evolution process, albeit indirectly via theinfluence of the system owners/sponsors.

The developers in Boehm et al.’s study were themselvesaffected by decisions which affected the availability ofdevelopment resource: ‘A major challenge for Cycle 3 wasthat many students involved in Cycles 1 and 2 duringthe fall 1996 Software Engineering I course, which was acore course for an MS in computer science, did not takeSoftware Engineering II in spring 1997 because it was not acore course.’ [9, p. 40].

Here we see a reason for a slowing down of developmentwhich is external to the actual developers themselves. Thedecisions of developer managers, or in this case the academicswho adopted a role equivalent to that of commercialmanagers, not to make a course core, resulted in a loss ofavailable effort. Here, development managers are makingdecisions on the basis of factors unrelated to the actualdevelopment process, in this case the need to educate theirstudents, rather than the needs of the users of the systemunder development, or indeed the desire of any user/customeractors. Decisions in industry to redeploy development staff toother projects will cause an equivalent slowing down ofdevelopment work, and again the influence of customer/useractors on these decisions will usually be at the most indirect.

The influence of infrastructure on the project can also beseen. The developers ‘. . . could not use the Integrated LibrarySystem’s test server for their prototypes because it was neededin transitioning from the old system to the new IntegratedLibrary System. There were also delays in arranging for asuitable alternative Web server.’ [9, p. 39]. This demonstratesthat infrastructure components can affect the effectiveness ofthe evolutionary process. In our model, this would be shownindirectly as reflecting a lack of commitment by the systemowners/sponsors evidenced by their not providing thenecessary resources to support the developers’ needs.

One aspect in which Boehm et al.’s description is notreflected in the ANT model is that of some of the routes bywhich the entities forming the network are connected.In particular, Boehm et al. describe direct interactions andcasual relationships between developers and users which affectthe behaviour of the development process. This reflects aprocess in which developers are allowed direct access to users,rather than the more hierarchical, formalised structure explicitin the ANT model. In the latter, communication betweenusers and developers, both motivational and with respect tospecific system requirements and other developer priorities, isindirect via system owners, software salespeople anddevelopment project managers.

This difference demonstrates the need to tailor the ANTmodel structure for specific types of developmentenvironment, and possibly for each individual application,if it is to be applied to software development practice.For example, as we can see here the networks of actors in


an ANT model of an XP-like process is likely to differconsiderably from that of a more hierarchical process.

Finally, Boehm et al.’s analysis shows the place of immutabletools in the process in an interesting light. The authors note that‘The guidelines we gave the students were from the coursetextbook, evolving commercial standards like J-STD-016-1995, and object-oriented methods, particularly the Boochmethod and Object Modelling Technology. . . . Each had itsvalue, but the overall set was both an overkill and weaklysupported by integrated tools. In the following year, we used amore concise and integrated set of views based on the RationalUnified Modelling Language and tool set.’ [9, p. 40].

Using the terms adopted for the ANT model, the toolsetsadopted were immutable, in the sense that it would bepedagogically unlikely for the tutors to modify them as thework proceeded and impossible for the students themselves torevise an industry standard, but it was possible to replace onetoolset with another. This suggests that the place ofimmutable tools may be more complex than is represented inthe current ANT model. Such tools axiomatically cannot bemodified, but one such tool can be completely replaced byanother. This possibility will need to be incorporated in themodel, together with the influences which might affect sucha decision.

7.2 Proof-of-concept calibration of theANT model

7.2.1 Introduction: In this section, we describe an initialcalibration of the ANT-based model. Although we have notyet quantified the necessary inputs and checked the outputsagainst real-world software evolution processes, the abilityto add a set of working equations to the model structureand to produce sensible outputs adds confidence to thereasonableness of the model.

This calibration is intended to test the feasibility ofthe approach by showing that the model can be calibratedat all. It has also increased our understanding of what data itwill be necessary to collect from a real-world processand its participants in order to calibrate the model for thatprocess.

As an initial trial, we have exploited the computationalmodel of System Dynamics in an attempt to capture theshifting degrees of support of actors for continuing theevolution of the system over time, culminating in the degreeof support of the entire network for those evolutionarychanges. This can be contrasted with the concentration oninputs (effort, time, money) and outputs (typically systemsize) of earlier software process simulation models.

Given the current lack of available real-world data to calibratethe model, the numerical values used in this simulation arecurrently set so as to reflect a neutral (neither positive nornegative) attitude on the part of any actor to the ongoing

329


330

& T

www.ietdl.org

health of the process and no change in these oversimulated time.

7.2.2 Model equations: In order to produce aquantitative calibration of the ANT model, it is firstnecessary to consider what we are trying to quantify for eachparticipant in the modelled process. Since our intention is toreflect the effects of changing degrees of support for anongoing software evolution process, it is sensible to quantifythe degree of such support for the ongoing process fromeach actor, and then to combine these in ways dictated bythe model structure into some quantification of the overalldegree of support for the continued evolution of the systemunder consideration.

In order to compute the degree of support for an actor atany stage in the evolution timeframe, we have exploited theability in SD to delay values for a period of time in orderto combine values remembered from previous time stepswith values newly calculated this time. The typical equationfor an actor recalculates each time step based on theweighted sum of its own value from the last time step andthe values of the inputs from actors which from the modeldiagram affect its behaviour.

A typical equation, that of the ‘Health of the system evolutionprocess’, is shown in (1). This shows how the actor recomputesits value at each time step based on the average of the values ofthose actors which influence it, weighted against its own valuefrom the immediate past; to ensure the stability of repeatedcomputations, the sum of the weightings is required to beunity. An ‘own weighting’ variable is associated with eachentity; these are omitted from Fig. 1 for clarity. The INTEGfunction and the ‘delayed health’ value are necessary only inorder to make the equations work in a system dynamicssimulation environment not intended for this form ofcomputation.

Health of system evolution process ¼ INTEG

(Health of system evolution process

� health own weighting)

þ (Developersþ Immutable tools

þMutable toolsþ Project manager

þ System change input queue

þ System design/architecture

þ System development owners)=7

� (1�Health own weighting)� delayed health)

(1)

The output most commonly observed in software evolutionprocesses, and therefore the most easily calibrated against andrelated to real-world software evolution, is the change incurrent physical system size over time. An examination of thebehaviour of this variable follows the practice in our earliersimulation models of software evolution processes [2–5],and is intended broadly to reflect the change in useful


functionality of the system over time. In our ANT model aninitial arbitrary value for the size of the system, representingthe size (measured in any appropriate way) at the start of thesimulated time, is driven to increase over simulated time usinga systems dynamics structure around the ‘System Size’ variableat the right of the diagram in Fig. 1. The computation isbased on an abstraction of previously-observed real-worldsoftware system growth trends – an inverse-cube size growthmodel – due to Turski [19]. This output is also affected bythe ‘Health of the system evolution process’ describedpreviously. The trend in system size growth follows Turski’smodel when ‘Health of the system evolution process’ has avalue which shows no positive or negative effect on theexpected evolutionary trend; this occurs when the value of theHealth variable is 1. Changes to this value, reflecting changesin the health of the process due to changes in the degree ofcommitment of the actors in the network to the ongoingevolution of the system, will result in the simulated growth insystem size being more or less than that predicted by Turski.Values for Health of ,1 result in lower than expectedgrowth, whereas those .1 result in more than expectedgrowth. The lower bound for Health is set to zero implyingno growth rather than a reduction in system size over time,since such reductions in size are comparatively rare.

One consequence of this calculation is that maximum rate ofsystem size growth is in theory unbounded, since themultiplicative effect on the nominal growth trend due tosystem health could be much greater than one. Indeed,if positive feedback operates repeatedly with sufficientstrength exponential growth is possible with this model. Thisis one possible explanation for the observations by Godfreyand Tu [20] of continued super-linear system size growth.

In addition to driving the growth in system size, the ‘Healthof the system evolution process’ also affects the attitudes to thecontinued evolution of those actors affected by the currentstate of an input to the system. The level of commitment ofan actor to the goal of the network may change over timeunder pressures from the actor’s own circumstances, theperceived state of the system and its relationship to theactor, and influences of other entities in the network. Inorder to represent this quantitatively in a model built using asystem dynamics tool, it is necessary to compute some valuerepresenting the degree of support for system evolution fromeach human and non-human actor at each time step,quantifying the viewpoints and opinions of the former andthe degree of support or obstructiveness of the latter.

7.2.3 Setting values for model parameters: Havingdetermined the model structure and added equations for thevariables, the next step in simulation building is to calibratemodel inputs and parameters to numerical values.

For each participant, ‘nominal’ (default) behaviour isrepresented by a value of 1 as is the case for the ‘Health ofthe system evolution process’, at which point the actor hasno effect on the behaviour of the rest of the process. A value


IETdoi:

www.ietdl.org

.1 represents a positive attitude towards the system and itsevolution process on the part of the actor, whereas a value of,1 shows a negative feeling. The inputs to each actor’scomputation are currently given equal weightings as adeliberate simplification to enable model outputs to becomputed in advance of actual values being available. Thisweighting (which is conceptually similar to the weightingcomputation underlying the belief system of a softwaredeveloper [13]), will tend to shift over time an actor’s degreeof support for continued system evolution towards that of itsinputs. Differences in the relative weightings of the inputsto an actor’s equation would enable the simulation builder totake into account the degree of influence of each input takenseparately on the actor’s behaviour, reflecting its personalbiases, power relationships within an organisation, orexternal factors. For example, the need to comply withlegislation is likely to be a stronger influence than thedemands of a minority of the user base.

One variable in the model operates in a manner differentfrom that of the others. The value of immutable toolsis currently fixed at one, representing no effect on nominalbehaviour, because it is axiomatically unchangeable byanything else in the model other than a completereplacement. Further research will be necessary to determinethe pressure necessary to force the managers of an evolutionprocess to change one toolset for another.

At this stage, our quantification has ignored some issues,particularly the actor/mediator distinction, subtleties oftimings such as different timescales for decision-making andrates of information transfer across links in network, and theability noted by Latour for actor-networks to be created andbroken up in a very dynamic fashion. One furthersimplification in the model is that the relative effect ofhistory on each participant has been deemed to be identicalfor all. The weighting of this history actually represents therelative degree to which outside influences affect the actor’sdecisions as compared with the inertia of the actorconcerned against sudden changes of mind.

7.2.4 Investigations and tentative conclusions:Since this calibration exercise has been undertaken withoutreference to any specific project, the values for all parametersand initial values for variables are arbitrary. However, even atthis early stage some potentially significant aspects haveemerged from the selection of calibration values. We presenthere the results of an investigation conducted using thecalibrated model. The simulation runs for an arbitrary 100time interval period and system size grows from a similarlyarbitrary 100 units.

One value which has turned out to have considerableimportance in determining the behaviour of the simulation isthe weighting given in each computation to the actor’s ownhistory. Early calibration investigations using this modelshowed that if this value is set too low then the degree ofsupport or otherwise from an actor can oscillate wildly


between strong support and equally strong opposition fromone time step to the next. This own weighting also representsthe effect of potential opinion-forming inputs on a keyindividual depending on how receptive that individual is toideas from and the opinions of others. The ability of themodel to represent aspects of the evolution process which,while they are subjective, are capable of affecting theevolutionary trend (many examples of this are found in [10]),demonstrates both the potential ability of this type ofsimulation to capture subtle effects on processes and thepotential difficulty of calibrating them in an objective manner.

Using values for the weightings which provide a more stabletrend in behaviour, the model has been used to compare processbehaviour in terms of system growth between a scenario inwhich all actors retain their nominal degree of support for theevolution of the software system, and one in which thesupport of the system sponsor is reduced by 40% for one timestep. This perturbation is intended to represent a reductionfor a limited time in the commitment of the sponsors of theongoing system evolution to its continuation. In the realworld, such temporary reductions in an individual’s supportcould be due to causes such as financial or political pressures.It was represented in a simulation run by a System DynamicsPULSE function with a value of 20.4 for one time step attime step 45, resulting in a reduction of that proportion inthe actor’s value at that time in the simulation run.

Outputs from this simulation run, on the same axes asnominal behaviour, are shown in Figs. 2, 3 and 4.

As can be seen from Fig. 2, as a result of this temporary loss ofsupport the system health value shows a pattern of increasingoscillations. This oscillating behaviour due to a singlestimulus is typical for heavily feedback-driven processes. Theresults of these oscillations on system size growth arecompared with the nominal case in Fig. 3, and the divergenceseen more clearly in a magnified view of the later part of thecomplete simulation run in Fig. 4.

The following conclusions can be drawn from this initialcalibration process. The ANT-based model can be calibratedquantitatively, at least in theory, although the problems whichwill arise when obtaining objective values from the real worldfor the necessary parameters are already apparent. Also, asingle one-time pulse reflecting a temporary change in thebehaviour of one entity generates complex feedback-generatedbehaviour in the support for the continued evolution of thesystem. From this we conclude that the ANT-basedsimulation supports Lehman’s VIIIth Law. Since the resultsobtained show long-term effects from a single pulse at onetime, the complexity of results which can be expected wheneach actor’s degree of commitment can change over time areapparent.

More tentatively, our initial results suggest that a certaindegree of inertia in human decision-making can help

331


332

& T

www.ietdl.org

Figure 2 Process health: sponsor support reduced by 40% at t ¼ 45 for one time step

reduce tendency to over-compensation and instability inhuman decision-based systems.

8 Towards a real-world simulationIn this section, we describe the steps necessary to turn ourcurrent tentatively-calibrated model into an executablesimulation of a real-world global software process.

8.1 Refining the model

One essential step towards making the model into a realisticrepresentation of actual software evolution environments willbe to check, and possibly, refine and enhance, the modelstructure to reflect more accurately the significant participantsin such processes in general, and the actual process under


consideration. This will involve identifying any additionalactors, mediators and intermediaries in a situation, anddetermining the ways in which of these each affects others.

Potential sources for this information include reports ofpractice from both successful and failed projects in softwaredevelopment, such as Yourdon’s Death March [21], interviewswith practitioners in general terms and for the specificprocess, experience reports from Software Engineeringconferences and other literature e.g. [22], and both formaland informal documents from the actual process. Inaddition, use will be made of other analyses of analogousprocesses outside software development, including, but notlimited to, Latour’s own work such as Aramis [10].Discussions with real-world process participants will also

Figure 3 System size growth: sponsor support reduced by 40% at t ¼ 45 for one time step


IETdoi:

www.ietdl.org

Figure 4 Expanded graph for system size growth late in run showing more clearly divergence due to reduce sponsor support

certainly prove to be a useful source of information about theprocess and act as a check on the validity of existing modelcontent.

Another issue yet to be addressed is the status of the dataheld in a software system, as against the programsmanipulating that data. Questions which might need to beconsidered when examining the evolution process of aspecific system include whether the data has its ownseparately-identifiable influence on the evolution process.This might arise, for example, when decisions concerningthe viability of major system enhancements are influencedby the consequent need for large, time-consuming, error-prone and expensive data restructuring exercises.

If the data held in a system is to be included as an entity inan ANT-based model, further questions arise. These includewhether it should be treated as actor, mediator or intermediaryand whether it might need to be subdivided into specific dataelements. As an alternative, data and software might beabstracted together into a single actor-network, but in theknowledge that these two aspects need both to be reflectedin the behaviour and effects of that network.

We currently consider that in ANT terms the data in asystem can be considered to be a parallel to a law code or areligious text, in that when it is made visible to a humanactor it can be read and interpreted in many ways,including some unguessed when the data structures wereoriginally defined. This is exemplified in data mining andother comparatively new techniques which use existingdata in novel ways. There is thus always a potential for datato have a more influential role than that of a passiveintermediary, and as a result the data in a system mayneed be considered at least to be a mediator and possibly asan actor.


8.2 Environments for a moresophisticated simulation

In order to represent the real world more accurately than iscurrently possible, we need to be able to represent actorsand mediators, and possibly influential intermediaries, inour simulation with more subtlety than the comparativelysimple SD environment-based model described here. Eachparticipant in the network will have to be treated as beingautonomous, with its own identity, a potentially complex,multi-variable state, and an arbitrary number of inward andoutward links representing its connections with othersparticipants in its actor-networks. To be useful indeveloping ANT-based simulation models, a simulationenvironment must support the calculation and storing ofcomplex data reflecting the state of a participant includingthe current network of connected associates, and thecomputation of updated state values based on state valuesof connected participants.

The state of each participant in an actor-network is inreality much more complex than the single value providedby an SD environment. Candidate actor state variablesinclude more than the goodness of fit of the actor’s currentstate to the system and its current direction of evolution asmodelled above. Other state variables might vary from oneparticipant to another and can include, for example, thetechnical and managerial competence of a project manager,or some measure of the relationship between the facilitiesprovided by the programming and other artificial languagesin use and the changing demands of the system’sdevelopers as they evolve it. Other factors affectingdecision-making may include economic pressures, thedesired and/or actual levels of satisfaction with a system byactors including its users and the system owners, thecurrent perception of ever-changing business needs on thepart of both developer and user organisations, the perceived

333


334& T

www.ietdl.org

risks arising from making changes to the system (or from notmaking them!), and the closeness of the system to its finalretirement. The influence of wider society on the systemmay need to reflect the effects of malware, viruses andpossibly even economic warfare.

Finally, the simulation environment must be able to copewith the frequent creation and dissolution of actor-networks noted by Latour. Short of using switch variablesto turn specific links on and off without actually creating ordestroying them, pure SD environments provide no supportfor such structural flexibility. We observe that a lack of thisflexibility is a weakness in our current model which needsto be resolved at an early stage of further development.

Given these requirements, one option under activeconsideration for modelling the networks of interactingactors, mediators and intermediaries is to employ an activeagent-based simulation environment such as Repast [23].

8.3 Challenges facing ANT simulationbuilders

We now consider some of the more theoretical challenges whichbuilding an ANT-based simulation will pose to its designers.

One problem which emerges in building a simulation of anactor-network is Latour’s claim that the outputs of a mediatorcannot be derived deterministically from an examination of itsinputs [7, p.58–9]. Latour refers here to the effects of thecomplexity which arises in considering a situation in whichmediators do not act deterministically but add richness oftheir own to the social process. He describes how puppeteersinteract with their puppets in a far richer way than issuggested by seeing them merely pulling the strings; thepuppets themselves suggest actions to their (alleged) controllers.

In order to build a simulation of such a situation whichfully reflects ANT, this aspect must be addressed. Anysimulation cannot be as rich as the real world it ismodelling. In this case, simulated mediators cannot be pre-programmed with all of the possible outcomes from allpossible inputs under all conceivable circumstances.However, it will be possible to take advantage of existingknowledge such as previously-observed software evolutionprocess behaviour, and that of other similar processes, totake advantage of the fact that in this social situation theactions of any entity, be it actor or mediator, are severelycircumscribed by both technical and social aspects. As anexample of the latter, the actions of the human actors whoare performing the low-level tasks involved in evolving thesystem are limited by the mindset engendered by theireducation and training, and by the norms of the disciplinewithin which they work [13].

Similarly, the actions of technology-based mediators arelimited to what that technology can actually do for (and to)those who use it, although Latour’s analogy of the puppeteer


suggests that the effect of feedback may be greater thanmight initially be expected.

Our initial proposal is that the simulated possible actions oftechnical mediators be limited to a small number of predefinedeffects, and that these be selected randomly with probabilitiesdepending in part on the situation in which the mediatorscurrently find themselves; the possible actions andparameter values will need to be determined for any specificprocess in discussion with domain experts. As a result of thedegree of randomness which now arises in the simulation,any particular model will need to be run a number of timeson a Monte Carlo basis, in the expectation that a pattern ofresults will emerge from a large set of repeated runs.

Having identified the properties of the entities in the model,if we wish to develop a quantified model with predictive powerwe will then need to quantify both their state attributes, and thepossibly complex messages transferred between them as thenetwork operates. Some of the variables and informationwill be ‘soft’, opinion/emotion-based and possibly difficultto quantify, rather than being directly and/or objectivelymeasurable. An example of this is the strength ofcommitment of an actor to the continued evolution of thesystem, currently represented in our initial model as a realnumber with a range intended to represent the possibledegrees of commitment to the ongoing development of thesystem rather than actual meaningful numeric values.

While this quantification and the reduction of humanemotional states to deterministic or probabilistic processesmight be seen as problematical, system dynamicistscommonly represent ‘soft’ values in quantified form, often inthe form of non-linear numeric scales whose values haverelative rather than absolute meanings. In order to obtainthe values required, experts’ views are more likely to beuseful in determining how the process in general and/or aspecific process works and obtaining the quantified valuesrequired rather than formalised metrics collectionprogrammes. We have previously calibrated models ofsoftware processes based on expert opinion during thedevelopment of successful simulation models [2–5].

Finally, a mechanism for connecting the entities comprisingthe model into a network will need to be developed. This mightbe achieved in an object-oriented simulation environment byhaving as one of the instance variables of the object whichrepresents a participant a collection of handles to thoseentities whose values influence its behaviour. Each entity inthis collection would identify both the relevant participantand the current weighting given by the list owner to theparticipant’s influence, paralleling the mechanism in thesimulation described here. This data structure would supportthe addition and removal of entities from the collectionrepresenting actor-networks being created and breakingup over time. This mechanism may need to be extendedfurther to allow for mistakes and misunderstandings incommunication between participants in the network.


IETdoi

www.ietdl.org

We intend to develop our current model into a more detailedsimulation with the properties we have described, and expectthat this simulation, when calibrated to values representingreal-world activities and actions, will be able to replicatebehaviours observed in real-world software evolutionprocesses. Such a calibrated model would undoubtedly assistin improving the understanding of the global software processand its behaviours.

9 Final conclusionsFrom the initial work presented here, we have been able todraw the following conclusions.

ANT provides a useful way of seeing the global softwareprocess and enables the development of a model of theglobal software process which reflects the socio-technicalcontext of that process. It also forms a basis for examiningthe relationship between social and technological influenceson the behaviour of the process.

On the basis of our proof-of-concept calibration, we believethat this model can be extended to provide quantitativepredictions of evolution process behaviour in the face ofchanging organisational and social circumstances. Even atthis early stage the ANT-based approach and the model wehave developed using it already show the promise of beingable to predict the behaviour of software evolution processestaking into account a much broader range of circumstances,particularly the softer non-technical aspects, than is possiblewith previous approaches. This has been demonstrated inthe example in Section 7.2, in which a temporary change inthe degree of commitment of a key person to the ongoingdevelopment of a software product was reflected simply by acorresponding change in the value of a model parameter.Predictions such as this would be of use to managers at alllevels of organisations which develop and use software-basedsystems, from strategists to line managers.

10 AcknowledgmentsWe are grateful to the referees of Software Evolvability 06 andto Martin Loomes and David Bowes for their valuablecomments. We are also grateful to the participants inSoftware Evolvability 06 who provided valuable feedback to apresentation of an earlier version of this model, and to manyof the participants in the 2006 International Conference onSoftware Maintenance for useful comments both duringformal presentations and in informal discussions. We alsothank the referees of this special issue for helpful commentsduring the revision of the original paper for publication.

11 References

[1] KAHEN G., LEHMAN M.M., RAMIL J.F.: ‘Empirical studies ofthe global software process – the impact of feedback’.Proc. Workshop on Empirical Studies of Software

Softw., 2008, Vol. 2, No. 4, pp. 321–336: 10.1049/iet-sen:20070093

Maintenance (WESS’99), Oxford, UK, 3–4 September 1999,(Keble College)

[2] CHATTERS B.W., LEHMAN M.M., RAMIL J.F., WERNICK P.: ‘Modellinga software evolution process’, Softw. Process Improv. Pract.,2000, 5, (2–3), pp. 91–102

[3] WERNICK P., HALL T.: ‘Simulating global softwareevolution processes by combining simple models: aninitial study’, Softw. Process Improv. Pract., 2002, 7,pp. 113–126

[4] WERNICK P., HALL T.: ‘The impact of using pairprogramming on system evolution: a simulation-based study’. Proc. IEEE Int. Conf. Software Maintenance,2004

[5] WERNICK P., LEHMAN M.M.: ‘Software process dynamicmodelling for FEAST/1’, J. Syst. Softw., 1999, 46, pp. 193–201

[6] LEHMAN M.M., RAMIL J.F., WERNICK P.: ‘Metrics of softwareevolution – the nineties view’. Proc. Metrics ‘97,Albuquerque, New Mexico , 1997

[7] LATOUR B.: ‘Reassembling the social’ (Oxford, 2005)

[8] BECK K.: ‘Extreme programming explained’ (AddisonWesley, 2000)

[9] BOEHM B., EGYED A., KWAN J., PORT D., SHAH A., MADACHY R.:‘Using the WinWin Spiral Model: A Case Study’. IEEEComputer, July 1998, pp. 33–44

[10] LATOUR B.: ‘Aramis, or the love of technology’, trans.Porter C, (Harvard, 1996)

[11] WILLIAMS-JONES B., GRAHAM J.E.: ‘Actor-network theory – atool to support ethical analysis of commercial genetictesting’, New Genet. Soc., 2003, 22, (3), pp. 271–296

[12] LOOMES M.J., NEHANIV C.L.: ‘Fact and artifact: reificationand drift in the history and growth of interactivesoftware systems’. Proc. 4th Int. Conf. CognitiveTechnology: Instruments of Mind, Lecture Notes inComputer Science, (Springer, 2001), vol. 2117, pp. 25–39

[13] WERNICK P.: ‘A belief system model for softwaredevelopment: a framework by analogy’, PhD Thesis,University College London, London, 1996

[14] WERNICK P., HALL T.: ‘Can Thomas Kuhn’s paradigms helpus understand software engineering?’, Eur. J. Inf. Syst.,2004, 13, (3), pp. 235–243

[15] Privacy International: ‘European commission beginsconsultation on data retention’, available at: http://www.privacyinternational.org/article.shtml?cmd%5B347%5D=x-347-64804, last accessed 3 January 2008

335


336

& T

www.ietdl.org

[16] LOOMES M.J., NEHANIV C.L., WERNICK P.: ‘The naming ofsystems and software evolvability’. Proc. SoftwareEvolvability 05, Budapest, 26 September 2005

[17] WERNICK P., HALL T., NEHANIV C.L.: ‘Software evolutionarydynamics modelled as the activity of an actor-network’.Proc. Software Evolvability 06, Philadelphia, PA , 24September 2006

[18] Ventana: ‘Vensim Software’, available at: http://www.vensim.com/software.html, last accessed 3 January 2008

[19] TURSKI W.L.: ‘The reference model for smooth growth ofsoftware systems revisited’, IEEE Trans. Softw. Eng., 2002,28, (8), pp. 814–815


[20] GODFREY M., TU Q.: ‘Evolution in open source software:a case study’. Proc. ICSM 2000, San Jose, CA , 11 – 20October 2000

[21] YOURDON E.: ‘Death March’ (Prentice Hall, 2003)

[22] DUNNING-LEWIS P.J., TOWNSON C.J.W.: ‘Using actor networktheory ideas in information systems research: a case studyof action research’, Working Paper 2004/025, LancasterUniversity Management School Report, 2004

[23] NORTH M.J., COLLIER N.T., VOS J.R.: ‘Experiences creatingthree implementations of the repast agent modelingtoolkit’, ACM Trans. Model. Comput. Simul., 2006, 16, (1),pp. 1–25


Date post:	20-Sep-2016
Category:	Documents
Upload:	cl
View:	215 times
Download:	0 times

Software evolutionary dynamics modelled as the activity of an actor-network

Documents