strategies for lifecycle concurrency and iteration – a system dynamics approach

Strategies for lifecycle concurrency and iteration± A system dynamics approach

Antony Powell a,*, Keith Mander a, Duncan Brown b

a Rolls-Royce University Technology Centre, Department of Computer Science, University of York, Heslington, York YO10 5DD, UKb Rolls-Royce plc, P.O. Box 32, Derby DE24 8BJ, UK

Received 10 November 1998; accepted 11 November 1998

Abstract

Increasingly ®erce commercial pressures necessitate the use of advanced software lifecycle techniques to meet growing demands

on both product time-to-market and business performance. Two signi®cant methods of achieving such improved cycle-time ca-

pability are concurrent software engineering and staged-delivery. Concurrent software engineering exploits the potential for simul-

taneous performance of development activities between projects, product deliveries, development phases, and individual tasks.

Staged-delivery enables lifecycle iteration to supply de®ned chunks of product functionality at pre-planned intervals. Used e�ec-

tively, these techniques provide a powerful route to reduced cycle-times, increased product quality and, potentially, lower devel-

opment costs. However, the degree and manner in which these techniques should be applied remains an area for active research.This

paper identi®es some of the issues and open problems of incremental lifecycle management by reference to the development of

aeroengine control systems within Rolls-Royce plc. We explain why system dynamics is a promising technique for evaluating

strategies for lifecycle concurrency and iteration. Ó 1999 Elsevier Science Inc. All rights reserved.

Keywords: Lifecycle concurrency; Iteration; System dynamics; Cycle-time acceleration; Incremental development

1. Introduction

Rolls-Royce plc is acutely aware of the signi®cance ofan advanced lifecycle capability. Few industries experi-ence such extreme commercial implications of cycle-timereduction than the ®ercely competitive civil aeroenginebusiness where time-to-market can mean the di�erencebetween winning and losing multi-million dollar supplycontracts. Consequently, lifecycle compression is now aprerequisite for competitive survival.

Within aeroengine developments, the production ofengine control systems has become a prime target forcycle-time improvement due to their natural proximityto the aeroengine project critical-path. The Full Au-thority Digital Engine Controller (FADEC) is a real-time embedded control system responsible for control ofengine thrust, performance monitoring and cockpitcommunication. Signi®cant cycle-time reduction inaeroengine development has resulted from the develop-ment of FADEC hardware and software simultaneous-ly, and in parallel with the development and testing of

engines themselves. This reduction is due to the com-bined application of development lifecycle concurrencyand iteration.

The development of aeroengine controllers is e�ec-tively a hierarchy of concurrent activities (Fig. 1). Taskconcurrency (within-stage overlap 1) reduces phasetimescales by simultaneously dividing work between theavailable resources. Increasing resource levels can have aproportional reduction in phase timescale if the units ofwork are self-contained independent subtasks. Phaseconcurrency (across-stage overlap) reduces deliverytimescales by releasing intermediate versions of stablework-products to enable a `¯ying-start' on subsequentdevelopment phases. Delivery concurrency (across-pro-cess overlap) reduces project timescales by supplying(for engine testing) successive increments of systemfunctionality to provide early feedback of problems.Project concurrency (across-project overlap) reduces

The Journal of Systems and Software 46 (1999) 151±161

* Corresponding author. Tel.: +44 1904 434728; fax: +44 1904

432708; e-mail: [email protected]

1 We use the overlap descriptors proposed by Blackburn et al. (1996)

in their concurrent software engineering methodology, with the

exception of `across-process overlap' which has been added by the

authors.

0164-1212/99/$ ± see front matter Ó 1999 Elsevier Science Inc. All rights reserved.

PII: S 0 1 6 4 - 1 2 1 2 ( 9 9 ) 0 0 0 0 8 - 4

time-to-market by exploiting the reuse potential ofproduct-line development.

Iteration uses multiple staged deliveries (each beingone cycle through a `waterfall' development process) tosupply de®ned chunks of product functionality atplanned intervals. In FADEC development ®ve maindeliveries are required: basic engine run, full-up func-tionality, engine test, ¯ight test and certi®cation. Inpractice, however, many more intermediate deliveriesare necessary to meet both technical and schedule de-mands.

Together the techniques of concurrency and iterationhave been a powerful route to:· Reduced timescales by accelerating development pro-

cesses, compressing critical-path times for both theFADEC and consequently whole-engine develop-ments.

· Reduced cost by early discovery and correction ofproblems in system components and their integra-tion.

· Increased quality by enabling earlier, longer, and thusmore comprehensive testing of the system in its com-plex operational environment.

However, as we intend to demonstrate, the applica-tion of concurrency and iteration are highly interrelatedand the degree and manner in which they should beapplied is still an area for active research.

2. Problems of incremental development

The problems of incremental development arise fromthe complex interdependencies between developmentactivities and their e�ect on process behaviour. Thesedependencies exist from their reliance on common re-source or shared work-products in time.· Common resource: Resource dependencies occur at

the level of task concurrency re¯ecting the competingnature of activities for a ®nite amount of resource. Atany time, a given phase resource (e.g. the code team)can be applied to any number of tasks, in di�erent de-liveries, for di�erent projects.

· Shared work-products: Work product dependenciesoccur at the level of phase concurrency through theavailability and quality of shared work-products.The outputs of earlier phases form the inputs to laterphases (e.g. requirements into design).The increased interaction between resource and

work-level dependencies make incremental lifecyclesdistinct from their sequential counterparts. In this re-spect, the FADEC process tends toward an extreme; thesigni®cant bene®ts of cycle-time reduction lead to ahighly concurrent and iterative lifecycle like that depic-ted in Fig. 2.

To optimise the performance of the process as awhole it is necessary to e�ectively balance the levels ofconcurrency and iteration. A failure to do so will havetwo main observable consequences on process behav-iour.· Resource loading: inconsistent work demands can

lead to peaks and troughs in resource usage.· Work instability: the unavailability and instability of

earlier work-products can lead to delays and reworkin later phases.The network of resource and work couplings within

incremental processes is therefore seen to exhibit sys-temic behaviour. This behaviour is driven by the relativestrength of internal relationships between developmentprocesses and their external relationships to the processoperating environment. The e�ects of software processesacting as multi-loop non-linear feedback systems (Ab-del-Hamid and Madnick, 1989) are particularly notice-able in the situation of process overloading. Anoverloaded process exceeds natural limits on perfor-mance, resulting in snap-points (places where one ormore constraints must be relaxed to cope with the excessdemands placed on the system). The consequent ripplee�ects can be visible as a `bow-wave' of work slippingthrough the process network causing increased pressure

Fig. 1. Hierarchy of process concurrency.

152 A. Powell et al. / The Journal of Systems and Software 46 (1999) 151±161

and risk toward the end of the project. Thus, a scheduledelay or a change in the quantity of work at any point inany lifecycle, has potential to cause dramatic over-allo-cations of team resource which, in turn, can delay orimpact on the quality or performance of later phases.

This dynamic behaviour of incremental lifecycles hasimplications for planning, control, and improvementactivities.

2.1. Implications for planning

Conventional planning methods fail to account forthe dynamic behaviour of software processes (Abdel-Hamid, 1993). In highly coupled processes, like incre-mental FADEC development, the relative scheduling ofactivities can have a large in¯uence on productivity andquality. However, techniques such as forward schedul-ing, reverse scheduling and network analysis (CPM) allassume a ®xed relationship between resource and du-ration (such that doubling the amount of resource willhalve the timescale and vice versa). These `static' plan-ning methods fail to support the planner's appreciationof dynamic process couplings and thus do little to pre-vent the creation of plans that, while seemingly realistic,lack adequate consideration of concurrent process dy-namics. The result can be unrealistic schedules causingbottlenecks, periods of chaos and calm and crisis man-agement.

The observation that software processes form feed-back systems also suggests that our traditional relianceon point-estimates of software cost is inherently ¯awed.As Abdel-Hamid and Madnick succinctly observe `Adi�erent estimate creates a di�erent project' (Abdel-

Hamid and Madnick, 1991). In other words, the way aprocess is planned can have a signi®cant e�ect on itsoutcome 2. Lifecycle cost estimates must therefore bebased on a proposed project plan that is progressivelyre®ned in consideration of all levels of concurrency.Thus, an understanding of process dynamics is requiredto determine: (i) the degree of concurrency required todistribute resource e�ectively, and to provide realisticoverlap periods for earlier work-products to stabilise,and (ii) the level of iteration necessary to e�ectively meetthe technical objectives whilst leaving the opportunityfor resultant rework. For a given set of plans it is nec-essary to compare expected demands against the orga-nisation's known process capability. Any signi®cantdeviation (or risk) must then be mitigated by eithermodifying the plans, changing the process itself, or byre-negotiation of constraints with other stakeholders.

2.2. Implications for control

Control is exercised to maintain adherence to projectplans and to ensure that work delivered under the plan isof the required quality. In incremental projects progresscan be di�cult to gauge ± making conventional controlmethods like `earned value' di�cult to apply. For ex-ample, rapid growth in visible functionality may maskrising levels of undetected rework that cause excessivee�ort much later in the programme. Furthermore, whilsta critical feature of incremental development is its re-sponsiveness to changes during the development pro-

Fig. 2. FADEC process concurrency.

2 The implication being that estimates must be made in consideration

of the estimate itself!

A. Powell et al. / The Journal of Systems and Software 46 (1999) 151±161 153

cess, it can make these processes prone to less acceptablepatterns of change. The added capacity for changemakes projects susceptible to requirements shift or`creeping speci®cation' with each iteration becoming anopportunity to add or change functionality beyond theoriginally intended (and priced) product scope. Tocounter this, control limits must be de®ned and moni-tored on the basis of acceptable levels of each of threetypes of change: (i) external change due to instability inhigher-level requirements, (ii) internal change due tofailures or instability within development processes, and(iii) emergent change discovered by the testing of theproduct in its target environment. When change occursprocess couplings suggest that control decisions need tobe taken in the context of the process as a whole.Moreover, any change in resource, timescale or work-load will have ripple e�ects to other activities ± therebylimiting the number of e�ective control actions at theprocess manager's disposal.

2.3. Implications for improvement

Incremental lifecycle management e�ectively tradeswork and e�ort in time. This balance between `now' or`later' is observed to have a large impact on processoutcome but can also cause di�culty when trying toevaluate process performance and identify areas forimprovement. For instance, the historical view of theeconomics of Quality Assurance (QA) justi®es the levelof QA investment on the observation that the cost ofdefects increases as they slip later in the process. In in-cremental lifecycles, process-time is balanced againstschedule (elapsed) time so that concurrent qualityassurance activities enable early defect detection andimplemented ®xes on the next iteration. Therefore, top-down assurance (i.e. getting the product right ®rst time)is traded against bottom-up quality assurance (i.e. ear-lier and longer system validation and veri®cation). Toget the balance right we need an understanding of boththe limits of lifecycle compression and the trade-o�s ofconcurrency and iteration in lifecycle strategy. Thus, tomake sense of historical data in order to optimise suchprocesses, we require a good understanding of processcauses and e�ects in time or `systems thinking' (Senge,1990).

3. The dynamics of incremental development

System dynamics uses causal loop structures to rep-resent dynamic relationships between system parametersand simulate the e�ect of system structure over time onprocess behaviour. The application of system dynamicsto the ®eld of software development is based on thepremise that these processes form multi-loop non-linearfeedback systems (Abdel-Hamid and Madnick, 1991).

By using resource to couple concurrent projects, Abdel-Hamid has shown that `scheduling and workforce allo-cation decisions in one project can signi®cantly in¯uencethe cost and duration of the other' (Abdel-Hamid,1993). This work also highlighted both the fundamentalde®ciency of current estimation tools and the problemsof decision-making in multi-project environments.

The work presented here is distinguished by the de-gree of concurrency applied at all process levels (in-cluding project, delivery, and phase concurrency) and bythe balancing of concurrency and iteration within thedevelopment lifecycle. In our FADEC case study envi-ronment, this balance has led to some distinctive pat-terns of lifecycle management. In particular, we observea relatively constant resource level that is allocated be-tween parallel activities according to the relative de-mand of delivery deadlines that are largely outside of thecontrol of the development team. The nature of theprocess constraints is such that process performance isheavily in¯uenced by decisions made at the planningstage. Hence, this work aims to provide models tosupport the optimal scheduling of the development ac-tivities and to develop decision-maker awareness of theessential process dynamics in their part of the environ-ment.

As delivery timescales and resource levels are highlyconstrained, proposed schedules can be evaluated byencapsulating a notion of productivity, and modellingthe deviation of the required productivity of the planfrom the organisation's measured productivity capabili-ty. By simulating the inter-coupling of work and re-source over time, the allocation of work and resourcewithin a planned schedule can be levelled such thatphase productivity is within an `achievable' level ofknown organisational capability. In this manner it ispossible to generate `robust' processes (i.e. ones that areless exposed to variation) that can be tracked againstcontinuous project plans to a successful outcome.

3.1. A model of incremental FADEC development

We use four basic elements of structure common tosystem dynamics models of production process struc-ture, namely resource, time, e�ort, and work. The ele-ments are related: resource (people) applied for a periodof time (days) expended e�ort (person-days) in theproduction of an output quantity of work (units). Weintroduce the abstraction of the `process triangle'(Fig. 3) to represent this structure and simplify expla-nation of basic model principles.

A network of process triangles can be instantiated atthe levels of task, phase, delivery, project, and organi-sation to represent the hierarchy of process concurrency(Fig. 4). Bottom-up each level is an aggregated perfor-mance of the one below. For instance, total project ef-fort is the sum of the e�orts of its deliveries, and delivery


time is the earliest start date and latest ®nish date of itsconstituent phases. Top-down each level inherits con-straints from the level above, formed both by the op-erating environment and management strategy(planning). Four planning constraints are observed:planned resource (i.e. available sta�), planned time (i.e.available schedule time), planned e�ort (i.e. total cost),and planned work (i.e. the quantity of work required to

deliver the output of required quality). Within each levelare both work and resource couplings that determine theimpact of relative activity scheduling on process per-formance. Process management is e�ectively the trade-o� between the relative process constraints and theprocess capability.

Two further structural elements of critical interest inprocess dynamics are productivity and quality. Pro-ductivity (person-days/unit) or work rate (units/person-day) is the relationship between e�ort and work. Qualityis represented as a breakage function that returns a levelof rework to the total level of work to be performed. Thesix elements (resource, time, e�ort, work, productivity,and quality) and the constraints and relationships be-tween them are seen to drive process behaviour andperformance.

A simulation model of FADEC development pro-cesses has been constructed using the Ventana Simula-tion environment (Vensim, 1995). The subscriptingfacilities of the Vensim tool are used to instantiate therepeating structure of the process triangle in the con-currency hierarchy, at the levels of (Project, Delivery,

Fig. 3. Process triangle.

Fig. 4. Hierarchy of concurrency.


Phase). For example, project e�ort is the sum of itsdelivery e�orts 3:

Effort�P1� � Effort�P1; D1� � Effort�P1; D2� � � � �� Effort�P1; Dn�� SUM�Effort�P1; D!��

The use of this generic structure provides a frameworkon which to develop our local models of behaviour. Thishas two distinct advantages. First, new elements ofstructure can be incorporated as more empirical re-search is done to understand low-level `micro' processrelationships. Second, it allows models to be tailored todi�erent environments and circumstances using o�-the-shelf components that can be `bolted-in' as required.Subscripts e�ectively replicate the elements of processstructure and make it easy to add or remove deliveries tosimulate alternative process con®gurations. Acting as aframework for the study of concurrent process dynam-ics, this generic approach can be used to describe com-mon determinants of process behaviour.

The main factors of interest in the study of concur-rency and iteration are resource and work coupling andtheir e�ects on productivity and quality. Since the FA-DEC model is more complex than can be described inthe present paper, the following sections describe thoseparts of the model that relate to these couplings.

3.2. Modelling resource coupling

The modelling of resource coupling aims to simulatethe allocation of limited available resource betweenconcurrent deliveries according to some decision crite-

ria. A feature of FADEC development is the stability ofoverall team size; sustaining a consistent developmentteam avoids the di�culties (high cost and long time-delays) of recruiting and training systems and softwareengineers. Since resource levels are relatively constant,attention shifts to the relative allocation of resource ef-fort between current activities. There are two main in-puts to this part of the model: available resource andrequired work rate. By considering the required workrate to achieve all concurrent activities, and the resourceavailable for those activities, an allocation of resource towork can be computed. This e�ectively simulates themanager's resource scheduling decision according todemands on a given phase team. The resource allocationproduces a level of applied resource to each parallelphase that, over a planned time, yields an applied e�ort.The e�ective applied work rate is then calculated bymodelling the productivity of the resource team (de-scribed later) and is then used to determine the workrequired in the next cycle of activities. In practice, theactual work done will be monitored against the plannedwork required to determine work required in the nextcycle.

The above is illustrated in Fig. 5, in a simpli®ed form,for two overlapping deliveries of one project beingworked by the code team. The structure is logically re-peated by the instantiation of further phases and deliv-eries to model the planned development processes.

In this model, the levels of applied resource are al-located proportionately according to the work rates re-quired to complete the concurrent activities in theplanned timescale. In practice, however, the dynamicallocation of resource is subject to a number of distor-tions and additional in¯uences. First, the monitoring ofwork done re¯ects perceived progress rather than actualprogress hence introducing distortions in estimates of

3 The exclamation mark is used by Vensim as a wildcard, in this

example representing `for all' deliveries.

Fig. 5. Resource coupling.


required work rate. Second, the assessment of the rela-tive importance of concurrent activities (determined byproject priorities and technical demands) can overridework rate considerations, and will therefore bias theallocation decision. Finally, step-change e�ects are in-troduced because resource is only allocated in ®xed in-crements of person-time. The signi®cance of theseadditional factors must be taken into account for aparticular development environment.

A major determinant of applied work rate is appliedproductivity. In the majority of software estimationmodels, productivity is treated as a static scaling valueof a cost estimate based on cost drivers such as sta�experience and product complexity. In FADEC devel-opment, however, these factors are observed to remainrelatively stable over planning time. In incrementallifecycles, we are more concerned with how appliedproductivity is a�ected by the pressure on each resourceteam. Two main dynamic drivers of productivity areschedule pressure and e�ort (or cost) pressure. Schedulepressure re¯ects the relationship between required pro-ductivity and the applied productivity. We observe thatit is possible to increase pressure on the developmentteam (by requiring additional productivity) but only upto a certain point, after which productivity rapidly de-clines. Thus, schedule pressure is an important factor indetermining schedules, since required productivity mustnot be allowed to go outside feasible bounds for theparticular development team. E�ort (or cost) pressurerelates current e�ort with planned e�ort and can be usedfor evaluating and levelling the cost pro®le of a plan, or,as a secondary driver of applied productivity.

Modelling resource coupling helps us to explore howavailable resource might be allocated for a proposedplan. For example, compressing development schedulesrequires increased productivity from the available re-source without reaching the point where productivitydeclines owing to over-work. Similarly, we can simulatethe peaks and troughs in resource usage and their ef-fects on required productivity; by modelling the devi-ations of required productivity from known `nominal'

productivity levels we can evaluate the risks associatedwith a proposed schedule. Changing the schedule timeof a particular process phase therefore has a direct ef-fect on the performance and resourcing of concurrentphases. It also has a corresponding e�ect on workcoupling.

3.3. Modelling work coupling

The production of work is modelled by a level ofrequired work moving to achieved work at an appliedwork rate as determined by the resourcing and pro-ductivity model. This basic production function is acommon feature of most dynamic models of softwareprocesses. Work dependencies couple the phases of aprocess by their reliance on common work-products, theoutputs of one phase forming the inputs to the next, e.g.requirements to design to implementation (Fig. 6).

Work coupling introduces two new areas for model-ling ± rework and transition ± with their consequent ef-fects on process performance. Work consists of bothnew work and rework. Rework arises as a result of ac-tivities taking place within a phase (internal rework) oras a response to problems caused in earlier phases butnot discovered until later phases (external rework). Therework cycle is a common feature of other models ofsoftware process dynamics (Cooper and Mullen, 1993).In a concurrent development, however, it is particularlycomplex since such cycles o�er the opportunity fordealing with internal rework by passing it (as externalrework) to the corresponding phase of a later delivery(Fig. 7).

Transitions occur when the maturity of phase outputreaches a level suitable for a subsequent phase to start.In practice, the selection of phase transition criteriadepends on the relationship between the developmentphases. Several handover strategies are possible: bysystem (e�ectively no process overlap), by milestone (inone or more prede®ned increments), or unit-by-unit(where completed work feeds directly into later phases).In FADEC development, the milestone strategy is

Fig. 6. Work coupling.


extensively used to allow downstream phases to startbased on a preliminary product. For example, as thedesign reaches a stable level of maturity it is con®guredand issued in draft form. Early receipt of the designenables a ¯ying-start on implementation whilst givingrapid identi®cation and feedback of design improve-ments for inclusion in the ®nal design document.

In the study of concurrency and iteration we are in-terested in maximising the degree of overlap betweenlifecycle phases. However, as the degree of overlap in-creases, the evolving product is more prone to changeand naturally raises the amount of rework required. Wetherefore seek to identify optimum levels of overlapbetween phases to reduce schedule and rework levels. Inthe FADEC model this is done in two ways. First, bymodelling the growth in achieved work to give an indi-cation of the expected level of overlap between theplanned phases. Second, by indicating the impact ofinternal and external rework resulting from the insta-bility of phase inputs. The overlap level and rework ef-fects are then used to adjust the schedule until anacceptable balance is achieved.

The models of work- and resource-couplings in timeform the basis for our dynamic simulation of incre-mental development. The relative scheduling of projects,deliveries, and phases, has an impact on both produc-tivity and quality. Moreover, any process change willhave ripple e�ects on the behaviour of other parts of theprocess. The resultant model is therefore capable ofproviding valuable insights into strategies for incre-mental development.

4. Strategies for incremental development

Our goal is to develop understanding of process dy-namics with incremental development lifecycles. Inparticular, to aid planning of `robust' processes for it-

erative development, to support control decision-makingin the context of the dynamic process as a whole, and todeliver improvement by aiding the evaluation of alter-native strategies for concurrency and iteration. To thisend, system dynamics can provide a means to representand communicate process understanding, supportquantitative evaluation of the software process, and aidreasoning about the behaviour and e�ects of changes toprocess structure.

4.1. Planning strategies

Any strategy for incremental lifecycle planning mustestablish a balance between the level of concurrency andthe number of process iterations. Since the constraintsintroduced during this planning stage have a signi®cante�ect on process behaviour it is necessary to assess theirlikely impact on process outcome. The use of systemdynamics models can allow planners to evaluate di�er-ent process con®gurations in order to generate plansthat meet programme objectives within acceptablemargins of risk. In this manner, the model of incre-mental lifecycles can be used to support robust processplanning as outlined in the following stages.1. Critical delivery milestones are identi®ed from the

Engine Development Programme to form a planneddelivery template that identi®es the size (work con-tent) and frequency (number) of iterations necessaryto meet the technical objectives.

2. For each planned delivery the levels of phase concur-rency are established by identifying the relative startand end dates of each phase, and their required workcontent, in order to meet delivery objectives.

3. Resource levels for each phase team are establishedbased on the assessment of current resource levelsand future requirements.

4. The model is simulated using an instantiation of theplanned process in conjunction with other planned

Fig. 7. Rework ¯ows.


or ongoing projects. The plan is then re®ned by iter-ation of the following steps.

5. Relative phase schedules (i.e. level of concurrency)are evaluated and adjusted to ensure that achievedwork levels are suitably mature for subsequent phasesto begin, whilst keeping total duration a minimum.

6. Resource levels are evaluated and adjusted to maxi-mise throughput whilst keeping productivity betweenacceptable bounds.

7. Alternative process con®gurations may be explored,for instance to introduce further deliveries to provideearlier feedback of product quality.

8. As the plan stabilises, it can be evaluated for its sen-sitivity to process slippages or additional unexpectedwork to assess the level of perceived process risk (asmeasured by the deviations from known perfor-

mance). If necessary, suitable local and global contin-gencies can be introduced to limit the e�ects ofprocess variation on ®nal performance.The planning process is therefore a progressive re-

®nement of these steps in consideration of incrementalprocess dynamics. The result is a plan of concurrencyand iteration for the FADEC development programme.The actual level of lifecycle iteration in a typical FA-DEC development is indicated by the GANNTGANNT chart inFig. 8, which shows the relative overlap between mul-tiple deliveries in two simultaneous engine projects.

Within each delivery of these is a software develop-ment lifecycle with high levels of concurrency Fig. 9. Asthe product undergoes successive deliveries, the balanceof phase e�ort shifts from requirements, through designand implementation, to testing and certi®cation. The

Fig. 8. Delivery concurrency.

Fig. 9. Phase concurrency.


resulting complexity of interactions between the levels ofproject, delivery, and phase concurrency means thatdynamic planning is an important capability for processmanagers.

4.2. Control strategies

A signi®cant bene®t of dynamic planning is theability to generate a continuous baseline plan againstwhich a process can be monitored and controlled. Thisplan makes progress more tangible and gives early in-dication of process variation. Furthermore, trackingprocess performance using the model itself allows con-trol decisions to be made in the context of the process asa whole. Hence, a process manager has only a limitednumber of control levers available to in¯uence projectbehaviour at speci®c control points in the process. It ispossible to apply (i) work control: to alter the relativeallocation of work between process phases and deliver-ies, (ii) e�ort control: to change working time (e.g. theuse of overtime), (iii) resource control: to increase ordecrease the level of resource applied, and (iv) schedulecontrol: to increase or decrease the available scheduletime for an activity, change the relative ordering and/orpriority of activities. These control actions are recordedas a set of available operations on the model to supportthe simulation of the alternative control actions onproject outcome.

The ripple e�ects of alternative control decisions alsoform characteristic patterns of process behaviour. Onesuch pattern is identi®ed in the feedback loop of Fig. 10.The continuous pressure to reduce cycle-time can lead toincreases in process compression requiring higher levelsof concurrency. Beyond some limit, this compressionleads to increases in product instability, and consequentchange, that in-turn causes pressure to further compresslater activities. The demands on concurrency from evermore ambitious cycle-time targets can therefore have anegative overall impact on project performance.

The use of dynamic modelling to simulate alternativecontrol strategies can help avoid the bow-waves andsnap-points associated with incremental development.In practice, the capability to evaluate the impact of `outof scope' variations on such projects is viewed as in-valuable by process managers.

4.3. Improvement strategies

The system dynamics approach provides a means toboth identify and evaluate process improvements. Forexample, dynamic modelling can aid:· Experimentation: Alternative process scenarios can be

simulated and the results of real-world process exper-iments be `scaled-up' to judge their potential e�ect ifapplied process-wide (e.g. to evaluate the cost andtime savings of software reuse).

· Global optimisation: In situations where the lifecyclehas multiple project teams, a persistent focus on localoptimisation can actually degrade global perfor-mance. The model can be used to support cross-boun-dary decision-making and negotiation to overcome,for instance, `tug-of-war' situations on shared mile-stones within an organisation (i.e. where one teambene®ts from delayed delivery, another team loses).

· Temporal awareness: The model aids appreciation ofthe implications of time-delays on ®nding and ®xingdefects. This understanding can be used to dampenprocess oscillation, for example, by de-coupling activ-ities to make them less inter-dependent, or by addingintermediate deliveries to absorb change. Critically, itacknowledges that rework has costs both in direct ef-fort to perform the rework, and in the delays to lateractivities caused by the need to switch resource toperform rework rather than planned new work.

· Lead-time compression: The model can support theidenti®cation and evaluation of opportunities forlead-time compression, indicating where processesmight reasonably be compressed and where contin-

Fig. 10. Pressures of process acceleration.


gencies might be applied. It therefore contributes tothe objective that necessitated the adoption of incre-mental lifecycles in the ®rst place.The realisation of such strategies can only occur by

the development of more realistic models of incrementallifecycle processes. The model concepts presented in thispaper are only the ®rst steps toward this long-term goal.

5. Current status and future work

The immediate contribution of this work is to high-light the trade-o�s within concurrent and iterative life-cycles. To which we have developed a generic structureon which our models of behaviour can be developed.The proposed model of incremental FADEC develop-ment focuses on the predicted deviation of a processfrom the measured process capability. This evaluation isused as a basis for the formulation of robust plans,de®nition of acceptable limits on control, and identi®-cation and evaluation of improvements.

The model of incremental development described inthis paper is still undergoing re®nement, calibration, andtesting. To date, our investigation has led to anecdotalevidence of the bene®ts of the technique in this envi-ronment. We believe that the developing understandingand insights into second-order process behaviour areleading to improved decision-making of this environ-ment. Moreover, since the e�ectiveness of alternativestrategies are dependent on the process context, thetechnique of system dynamics has proven its generalutility as an aid to understanding incremental processdynamics in any environment.

Considerable research work remains before we canstart to fully appreciate the generic dynamics of processconcurrency and iteration. Even then we are bound byboth pragmatic and natural limits to the level of processunderstanding possible in these `complex, non-linearadaptive systems' (Kitchenham, 1998). In the meantime, the problem of incremental lifecycle managementremains of critical commercial signi®cance to projectmanagers.

Acknowledgements

This work has been funded by UK Engineering andPhysical Sciences Research Council Grant 95594911 and

Rolls-Royce plc. The introduction of tools and tech-niques has been supported by the European Systems andSoftware Initiative (ESSI) PRIME project (21670).

The authors would also like to thank Prof. JohnMcDermid, Keith Harper, Brian Cooke and EddieWilliams for their contribution to this work.

References

Abdel-Hamid, T.K., Madnick, S.E., 1989. Lessons learned from

modeling the dynamics of software development, Communica-

tions of the ACM 32 (12).

Abdel-Hamid, T.K., Madnick, S.E., 1991. Software Project Dynam-

ics ± An Integrated Approach, Prentice-Hall, Englewood Cli�s,

NJ.

Abdel-Hamid, T.K., 1993. A multi-project perspective of single-project

dynamics. Journal of Systems and Software 22 (3), 151±165.

Blackburn, J.D., Hoedemaker, G., Van Wassenhove, L.K., 1996.

Concurrent software engineering: prospects and pitfalls, IEEE

Transactions on Engineering Management 43 (2).

Cooper, K.G., Mullen, T.W., 1993. Swords and ploughshares: the

rework cycles of defense and commercial software development

projects, American Programmer.

Kitchenham, B.A., 1998. The certainty of uncertainty, The European

Software Measurement Conference FESMA 98, Antwerp, Bel-

gium, May 6±8.

Senge, P.M., 1990. The Fifth Discipline: The Art and Practice of the

Learning Organisation, Doubleday, New York.

Vensim, 1995. Vensim reference manual, Version 1.62, Ventana

Systems Inc., Belmont, MA.

Antony Powell is a research fellow in the Rolls-Royce UniversityTechnology Centre at the University of York, UK. Antony special-ises in the measurement and management of advanced software en-gineering processes. He maintains responsibility for a number ofprocess improvement initiatives across the Rolls-Royce group ofcompanies.

Keith Mander took an undergraduate degree in Mathematics at theUniversity of Nottingham before completing a Ph.D. there in Com-puter Science. For four years he was a Lecturer in the Department ofComputational and Statistical Science at the University of Liverpoolbefore joining the Department of Computer Science at the Universityof York in 1981. Since April 1992 he has been Head of Department,responsible for the research and teaching activities of the Departmentof Computer Science at the University of York (a department of over100 sta� and over 400 students). From July 1999 Keith Mander will beHead of the Computing Laboratory at the University of Kent, Can-terbury.

Duncan Brown graduated in 1987 from Queen Mary College, Univer-sity of London, in computing systems and microelectronics. He spenttwo years at British Aerospace Military Aircraft Division working onreal-time avionics systems for both data acquisition and stimulation,and manufacturing control. Since June 1989 he has worked on ¯ight-control software within Rolls-Royce plc and is currently softwaremanager for Rolls-Royce Control Systems.


strategies for lifecycle concurrency and iteration – a system dynamics approach

Documents