a practical strategy for industrial reuse improvement

SOFTWARE PROCESS—Improvement and PracticeSoftw. Process Improve. Pract. 4, 173–182 (1998)

A Practical Strategy forIndustrial ReuseImprovement

Antony Powell1* and Duncan Brown2

1Rolls-Royce University Technology Centre, Department of ComputerScience, University of York, Heslington, York, YO1 5DD, U.K. Research Section2Rolls-Royce plc, PO Box 31, Derby, DE24 8BJ, U.K.

Rolls-Royce plc have first-hand experience of delivering systematic software reuse in theproduction of real-time embedded control systems for civil aeroengine applications. Reuselevels of 80% have been achieved between control system developments giving substantialeconomic savings, along with reduced cycle times and assured software quality. However,since these early savings were aided by intrinsic similarities between projects, there has beenno room for complacency. Faced with new and more diverse applications, the reuse processwill increasingly be a major determinant of business performance. A continuous search forreuse improvement has therefore become a strategic necessity. This paper presents someresults of the PRIME project in the form of a six-step reuse improvement strategy. It isnotable for the concept of improvement paths – the effective ‘policy levers’ that a projectmanager can use to control the reuse process. The improvement framework and lessonslearned will be of interest to practitioners interested or actively involved in reuse and toresearchers engaged in reuse technology transfer. Copyright 1998 John Wiley & Sons, Ltd.

KEY WORDS: continuous reuse improvement; metrics

INTRODUCTION

The last decade has seen a significant body ofresearch aimed at unlocking the economic potentialof systematic software reuse. However, the transferof research principles into industrial practice hasbeen more problematic than the seductive sim-plicity of reuse ideology has led us to believe.Pragmatists are acutely aware that successful reuse

Correspondence to: Antony Powell, Rolls-Royce UniversityTechnology Centre, Department of Computer Science, Universityof York, Heslington, York, YO1 5DD, U.K. E-mail: antony.powellKcs.york.ac.ukContract/grant sponsor: European Systems and Software Initiat-iveContract/grant number: 21670

CCC 1077-4866/98/03173-10$17.50Copyright 1998 John Wiley & Sons, Ltd.

depends on cultural and organizational issues asmuch as supporting technology.

The evidence that systematic reuse can have asignificant impact on business performance is nowcompelling. Hewlett-Packard divisions have usedreuse to double productivity, halve defects, anddramatically reduce time-to-market (Lim 1994).Motorola’s 86% reuse level provided a tenfoldincrease in productivity (Joos 1994) and RockwellInternational experienced benefits of lower projectbids and of responsiveness to customer needs(O’Connor et al. 1994). These and other publishedstudies stress that achieving successful reuserequires a large amount of foresight, investmentand, above all, commitment. However, for thoseinspired to embark on a reuse programme theroute to successful reuse is by no means clear;experience from a wide variety of domains and

Research Section A. Powell and D. Brown

development environments all suggests that thereis no one right way to perform software reuse.

The absence of an objective definition of ‘bestpractice’ means that companies must determine forthemselves the effectiveness of alternative reuseapproaches from the bewildering array of toolsand techniques available. A lack of comparativedata to establish ‘what-works-where’ means thateffort is being focused on techniques to support aquantitative understanding of reuse within anindividual organization. These quantitative tech-niques allow organizations to evaluate the effective-ness of their reuse processes, identify processimprovements, and, to a certain extent, share reuseexperiences at a common level of understanding.As reuse increasingly becomes a significant deter-minant of competitive performance, this capabilityfor continuous process improvement becomes vital.

The Rolls-Royce BR700 team began a formalprogramme of systematic software reuse in thedevelopment of a new generation of Full AuthorityDigital Engine Controllers for civil aeroengines in1992. A FADEC is a control system responsible formanaging engine thrust, temperature, pressure,communication and maintenance functions. Whilstthe embedded software is relatively small (typically200,000 lines of Ada code) the process requiredto produce flight-critical real-time software isinherently expensive. Hence, by viewing FADECdevelopment as a product-line with instantiationsof a ‘generic architecture’ the company hoped toexploit the potential benefits of formally reusingengineering products and processes. Software reusewas therefore considered key to producing themost cost effective, high quality systems in theshortest possible timescales.

During the introduction of the original reuseprogramme, management were keen to measurethe levels of reuse achieved and evaluate the impactof reuse on bottom-line business performance. Afirst-cut reuse measurement process was introducedwith the goal of demonstrating cost savings due toreuse. The calculation was based on the componentdevelopment cost, the additional cost of making acomponent reusable, the cost of reusing the item,and the percentage reuse level achieved. Themetrics collected demonstrated impressive results.The target project achieved a level of 82% sourcecode reuse and cost only 20% of its predecessor.

Whilst the baseline reuse metrics confirmed thesignificant benefits of systematic software reuse,Copyright 1998 John Wiley & Sons, Ltd. Softw. Process Improve. Pract. 4, 173–182 (1998)

174

there were still problems. The high reuse levelshad been aided by the intrinsic similarities betweenthe target project and its predecessor. Furthermore,the reuse measurement process itself was onerous,a considerable overhead on development, andinsufficient for meeting business goals. The metricsdemonstrated that the reuse process was successful(in cost terms) but failed to indicate exactly whereimprovements could be made, or how we mightaccurately estimate for future projects. There couldbe no room for complacency. Faced with newand more challenging applications, we needed ameasurement and improvement process by whichwe could ensure that our reuse processes areconsistently aligned with business objectives.

A STRATEGY FOR CONTINUOUS REUSEIMPROVEMENT

In partnership with the European Systems andSoftware Initiative, the Practical Reuse Improve-ment MEtrics (PRIME) project has sought to deliver‘best practice’ capability in reuse management andcontinuous improvement within Rolls-Royce. Theremainder of this paper describes some of theresults of this work captured as a six-step reuseimprovement strategy (Figure 1) which is used topresent our lessons learned as a set of practicalguidelines for improving a reuse process.

Step 1: Understand Reuse Business Goals

Identify Your Business GoalsThe continuous focus on business results had beena major factor in the success of the original reuseprogramme. Reuse provided a means to reduce

Figure 1. Six-step reuse improvement model

Research Section A Practical Strategy for Industrial Reuse Improvement

production costs and lead-times whilst meeting theexacting demands on software quality. Demandingbut realistic targets had been identified for thereuse programme based on engineer assessmentsof potential system reusability. A persistent focuson these targets made sure that participants wereaware of their responsibility in meeting them.

A major failing of the original reuse programme,however, was an assumption that meeting ourreuse targets implied that the reuse itself had beensuccessfully introduced into the organization. Astargets were met, the push for reuse declined andteam members settled back into old patterns ofworking that saw reuse levels falling well belowour full reuse potential. We realized that (to useMyers’ framework, Figure 2) the reuse process hadbeen adopted but we had failed to fully integrateor internalize reuse into the process. Faced with anew engine application that was significantlydifferent to its predecessor we needed to ensurethat our reuse programme was capable of meetingchallenging new business targets (Myers 1997).

The PRIME project was therefore established toensure that our reuse programme was measurablyin-line with business objectives and continuouslyimproving in the context of our changing environ-ment. This process had to start with a thoroughre-evaluation of our business goals. Reuse hadnow become a strategic necessity for producing themost cost effective, high quality systems in shortertimescales. Moreover, to meet our goal of internaliz-ing the reuse process we had to convince parti-cipants that the reuse problem had not yet beensolved. Reuse was not the end in itself, but anongoing means to achieve business goals.

Figure 2. Maturity of technology adoption [4]

Copyright 1998 John Wiley & Sons, Ltd. Softw. Process Improve. Pract. 4, 173–182 (1998)

175

Identify Your Reuse GoalsThe rationale for elaborating business goals wasan important part of the reuse improvementprocess, business objectives and constraints deter-mine viable reuse strategies that affect both thenature, and degree, of the reuse solution to beemployed. These goals were captured as a visionof the target process over the short, medium andlong term, expressed against a baseline assessmentof the current capability.

The short-term goal was to deliver incrementalprocess improvements in the reuse process. Theseimprovements would contribute to a reduced costof software development, increased product quality(by the use of mature trusted components), andfurther reductions in project timescales that wereessential for meeting delivery targets. Furthermore,reuse was to result in less tangible benefits by, forexample, providing a route for managing thegrowing complexity of the control system bystandardizing on well-documented existing compo-nents.

The medium-term goal was to achieve a shift inthe perception of our product-line by providingthe required incremental changes to our reuseprocesses. The aim was to capture requirementsin a reusable way and effectively turn the process‘on-its-head’. The focus on producing a stableproduct-line architecture would enable core enginefunctions to be provided ‘off-the-shelf’ with alterna-tive system configurations being costed as optionalextras. To our customers this would mean systemsof proven maturity for substantially lower costs.

The long-term goal was to develop the ‘genericengine controller’. A generic control system demandsmore revolutionary changes to product architecturethan possible with traditional methods of systemdevelopment. The high initial costs of the genericsystem would however be relatively small com-pared to bespoke development costs and thepotential benefits of an assured marketplace. Aprerequisite for such a radical departure fromcurrent approaches would have to be a permanentorganizational focus on reuse improvement.

Articulate Your GoalsThe clear articulation of these reuse goals in ourbusiness context helped secure the commitment ofall participants. Their clarity supported the reuseteam in enacting the necessary changes to businessand reuse processes.


Step 2: Understand Reuse Processes

The evaluation of business and reuse goals hadestablished the context for the reuse improvementprogramme and the criteria for an appropriatereuse process. Our next step was to identify thecurrent and desired reuse process in order tooptimize reuse within each development stage andacross the process as a whole.

Identify Reuse Products, Resources and ProcessesThe original reuse process had been derived froma combination of traditional reuse and domainengineering techniques (Lam 1997). However, wewere aware that the actual process had migratedsome way from that originally planned, for anumber of reasons. These included both changesin the underlying development process and ‘fixes’introduced to make the reuse process practicable.Moreover, we recognized that individual percep-tions of the reuse process were sometimes inconsist-ent between team members. We therefore soughtto model the processes, architecture, assets, toolsand roles, of the actual reuse process compared toour planned and perceived processes. Re-engineeringwould provide a defined reuse process that, onceunderstood, could be more effectively aligned withprocess goals and later quantitatively evaluated.

The planned reuse process itself was consideredto be best practice of its time (Hill et al. 1994).Software reuse was primarily achieved by thereuse of software requirements – each requirementbeing tagged as either generic or specific to aproject. This led to cascaded reuse of designs, codeand tests from previous applications along withthe development of new bespoke components asrequired. Reuse was also achieved at a low levelby the use of library functions specified in therequirements using specific symbols and coded asreusable functional blocks (Ada procedures). Thisprocess (Figure 3) proved to be a considerableadvance over the informal ‘cut-and-paste’ reuse ofearlier developments.

The modelling process revealed some character-istic features of the actual reuse process employed:

I Project concurrency. A distinct feature of theprocess was the co-evolving nature of products.Reuse occurs between two or more simul-taneous product developments ‘live’ from themore mature development into the followingproject. The result can be reduced project


176

timescales and benefits of dynamic design forreuse (i.e. information flow between the twoprojects to improve overall reuse levels). Adamaging side-effect of this concurrency, how-ever, was the potential to introduce genericproblems that could necessitate fixes to allaffected products.

I Process infrastructure. The reuse process washeavily dependent on the systems for configur-ation management and change control. Thereuse process had become an integral part ofthe development process itself. Thus improve-ments to the reuse process implied changes toquality management systems including appro-priate standards and procedures.

I Reuse communication. The manner by whichreuse is communicated in the developmentprocess was seen to have a major impacton reuse performance. Formal communicationroutes included product representations, pro-duct traceability, design meetings and theintranet-based reuse library. Equally importanthowever were the informal communicationroutes like conversation and the unwrittenassumptions about system architecture anddesign practices. Problems in both formal andinformal communication channels were seen tobe limiting achievement of our reuse potential.

I Architectural control. Fundamentally, the reuseprocess was being driven by limitations in thesystem architecture that had been inheritedfrom a history of bespoke development.Consequently, the product structure was highlysensitive to external change – with damagingconsequences for process cost and timescales.This change, however, was viewed to be largelyavoidable by producing a more appropriatearchitecture that used interface partitions toisolate the effects of change. The necessarytransition from legacy to generic architecturewould demand a higher degree of architecturalcontrol than currently supported by the presentreuse process.

Identify an Evolution PlanThe insights obtained from the modelling activitywere used to identify a more detailed evolutionplan for both the product and the reuse process.The coupling between business and reuse processwas a product-line strategy based on predictions


Figure 3. Cascade reuse process

of the number and type of future applications andanticipated changes in market and technology.

The actual reuse process experienced was typifiedby a small number of large projects of relativelylong duration. The high outright costs of producingflight-quality software meant that development ofreusable assets must be funded under the auspicesof commercial projects. Product evolution thereforerequired a planned gradual migration of current‘legacy’ products at all process stages towardsour target generic control system architecture tomaximize reusability. Hence, determining both thefocus and level of reuse investment to maximizereturns was a critical part of the reuse process.

Step 3: Understand Reuse Decisions

The analysis of current reuse processes simplifiedthe identification of reuse decisions; critically, itwas observed that the effectiveness of our reuseprocess depends on our ability to set realistic reusetargets and our ability to meet them. A quantitativeunderstanding of reuse was therefore prerequisiteto evaluating and improving reuse performance.

The problems of our original reuse measurementprogramme had taught us some important lessons.First, reuse measurement should preferably be viaa few simple and well-understood metrics appliedin anger. Second, the metrics must be purposefulwith clear objectives on how the data will be usedin process decision making. Third, both the metricsand their value should be clearly explained toCopyright 1998 John Wiley & Sons, Ltd. Softw. Process Improve. Pract. 4, 173–182 (1998)

177

their users. Fourth, metrics collection should beautomated where possible to minimize overheadsand improve data accuracy. Finally, the objectivesof the reuse programme must be expressed in ameasurable way.

Our next step was to understand reuse economicsat each stage in the development process. Weisolated three generic decision processes that affectreuse process performance, namely, reuse evalu-ation, reuse investment and reuse prediction(Figure 4).

Support Reuse EvaluationUnderstanding reuse economics in our environ-ment required evaluation of the effectiveness ofthe reuse process at each stage of developmentand across the process as a whole. This requiredaccurate measurement across four dimensions:

Figure 4. Reuse process economics


I Effort: the effort of developing and modifyingsystem components. This supports evaluationof the costs of development for reuse and theeventual return on reuse investment.

I Time: the elapsed duration of process activities.This supports evaluation of the contributionof reuse toward improvements in productlead-time.

I Quality: the number, type and root causes ofdefects in reused components along with theirintroduction/detection profiles. This supportsevaluation of the effect of reuse on process andproduct quality.

I Quantity: the level of reuse achieved acrossdevelopment projects and stability of systemcomponents. This supports evaluation of theimpact of product changes on reuse profiles.

This evaluation capability served two purposes.First, it was used to identify specific questions thatcould be used to make improvements in our reuseprocess, for example, ‘Does system level reuse mapdown to code and test level reuse?’, ‘What is theusage profile of components and how can it beimproved?’, ‘Does the architecture localize changeto a minimum of system components?’ and ‘Whatare the desirable size and quality characteristics ofreusable components?’ Second, it was used as abaseline of performance for reuse investment andprediction decisions.

Support Reuse InvestmentThe modelling of the existing reuse process hadhighlighted the importance of gradually migratingthe current legacy architecture toward the desiredgeneric control system. Hence, it was necessary toidentify areas of the legacy system architecture thatwould give optimum return from re-engineering.

The outcome was a team-based reuse investmentprocess that combines both qualitative and quanti-tative assessments to determine the most effectivelevel of reuse investment. The decision is basedon an evaluation of design quality and the demandsof future applications. For each functional area thisincluded: the expected number and type of futureapplications; component size; maintainability andtestability of the current design; the potential fora more reusable design, and the availability ofcurrent reuse modules to support the function.This capability for reuse evaluation was also usedto indicate the point at which partial reuse wasno longer economically viable. The result was aCopyright 1998 John Wiley & Sons, Ltd. Softw. Process Improve. Pract. 4, 173–182 (1998)

178

‘hit list’ of functions that could cost-effectively bere-engineered in the current project.

Support Reuse PredictionThe introduction of reuse had meant that businessperformance was now dependent on our ability tomake accurate predictions of reuse levels andresultant costs savings. It was necessary to intro-duce a reuse estimation process based on astructured analysis of system reusability usingevaluative data of past reuse performance.

The reuse prediction process uses a variant ofthe commonality analysis technique developed atLucent Bell Labs (Weiss 1996). Essentially, thisapproach formally divides a function into itsconstituent sub-functions that are then assignedweighings as a percentage of the overall function.This process uses the identification of likely changesin system components to predict a reuse level forthe function in the future application. The cost ofdeveloping the component afresh and the potentialcost of reusing are then used to identify an expectedeffort taking into account the expected benefit ofreuse investments. A prediction of overall reuselevels across for the system can then be madealong with the anticipated savings due to reuse.

As projects progress, the spend per function ismeasured against targets and used to monitor andcontrol the reuse process. The measured level ofestimate accuracy is factored into the predictionprocess to improve estimate quality next timearound.

Identify Goals, Questions, MetricsThe investigation into both business and reuseprocesses was distilled into a traditional set ofgoals, questions and metrics (Basili 1992) requiredboth to support the current reuse process andprovide feedback for continuous improvement. Webelieve, however, that the insights from our morewide-ranging investigation led us to a differentGQM set than would have been achieved fromdirect analysis. In particular it identified the criticalgap between perceived, current and desired reuseprocesses. As a result we were more equipped tomeasure those factors important to achieving thedesired reuse process.

Step 4: Plan Decision Infrastructure

The improvement of reuse decision-making mustbe accompanied by an appropriate infrastructureto support effective data collection and analysis.


Automate Metrics CollectionThe problems of our earlier metrics programmehad encouraged us to put a large emphasison automated collection of product and processmetrics. Automation would increase data accuracyand allow manual effort to be moved from datacollection and concentrated on the value-addedwork of identifying and implementing processimprovements. Three key in-house tools supportedthis metrication effort:

I PRIME Cost Booking System (PCBS). PCBS is apowerful cost booking system that enablescollection of effort information at a level ofdetail unachievable with systems. The techniquesupports collection of activity effort, timescaleand resource data, based on the concept of ageneric work-breakdown structure. The use ofa process engineering language allowsexpression of activity plans and results innatural language (Clark and Powell 1999). Thisallows users to query the information in amyriad of different ways, many of which maynot even have been anticipated at the projectoutset, for no additional overhead.

I Rolls-Royce Change Control System (RoCCS).RoCCS is an in-house change control systemthat supports the management of multipleprojects within concurrent phased-deliverylifecycles. It was adapted to collect informationon the number, type and root cause of in-processproblems and their introduction, detection andremoval profiles. The impact of reuse on productquality could then be tracked withoutadditional overhead.

I Automated Reuse Measurement Tool (ARMT). TheARMT tool was developed to provide analysisof low-level code reuse and modificationbetween software products and deliveries. Thetool captured various size and complexitycharacteristics of software modules as well asthe percentage black-box and white-box reuseof modules, subsystems and overall products.

The remaining metrics data was collected from theconfiguration management system and existingdevelopment and testing tools.

Support Decision AnalysisThe use of automated metric collection helped usto standardize our analysis to support specificreuse decisions. This analysis took the form ofCopyright 1998 John Wiley & Sons, Ltd. Softw. Process Improve. Pract. 4, 173–182 (1998)

179

decision-based spreadsheets that could be popu-lated from the collection tools. By configuring thesespreadsheets it is possible to capture decisionsthemselves to be improved along with the reuseprocess itself.

We have also experimented with more advancedmodels of the software process that are moresuited to incremental staged-delivery lifecycles ofthis type. Research work has investigated the useof system dynamics to model the impact of reuseand other improvements on process effectiveness(Powell et al. 1999). The preliminary results ofthis approach indicate its valuable potential inunderstanding the effects of reuse on process lead-times. The comprehensive metrics infrastructureintroduced by the PRIME toolset provides theprerequisite capability for these more advancedlong-term improvement models.

Step 5: Plan Improvement Paths

The main contribution of metrics in the improve-ment process comes from their use to either supportor contradict our perceptions of process behaviour.Only rarely, in our experience, do metrics point tounexpected process problems and their causes. Thetendency for metrics programmes to trust on thelatter may explain the common disillusionmentwith metrics processes and their frequent abandon-ment. Where metrics programmes have managedto collect meaningful data, the improvement pro-grammes are frequently derailed by the gapbetween analysis and improvement action.

A key feature of the PRIME six-step model wasits concentration on how analysis would lead toactual changes in both reuse decisions and ourmodus operandi. The mechanism was the creationof improvement paths – the effective policy leversthat decision-makers could use to affect changesin the target process. These included:

I Reuse education and training. Whilst reuse is stillan essentially human activity, few engineershave had any formal education or training inits principles. In particular, more inter-disciplineunderstanding is required of the effects ofdesigns at one process phase on the architecturalreusability at other stages. One such route toimproved understanding was the use of internalreuse seminars. The level of investment andtype of training on reuse principles has asignificant impact on reuse performance.


I Reuse team structure and communication. Prelimi-nary analysis of reuse metrics supported ourobservation that systems level reuse was notbeing mapped down to equivalent softwarelevel reuse. Such results suggested the use ofdynamic team structures to combine systemsand software engineers on a function-orientedprocess. Both formal and informal routes ofcommunication could also be given greatersupport; for example, by improved use ofthe departmental intranet and lessons learneddatabase to capture and share best practice.

I Reuse motivation. A successfully internalizedreuse process would make reuse the norm, withbespoke development occurring only whereabsolutely necessary or more cost-effective. Anumber of policy levers were available tomotivate higher levels of reuse, such as devolv-ing responsibility for reuse improvement furtherdown the team structure.

I Reuse investment and architecture. A major policylever is the level of investment applied to thereuse process. As explained earlier, analysiscould identify the stability of the system archi-tecture and point to areas that could cost-effectively benefit from redesign. The invest-ment process was supported by a measuredrelationship between level of reuse and projectsavings, to provide quantifiable justification forsanctioning future initiatives to improve thereuse process. This encouraged a long-termapproach to reuse investment since initiativesrarely pay back investment within the timescalesof a single project. If reuse is to succeed thenit must be properly funded.

I Reuse decisions. The decision-making processwas itself a determinant of reuse performance.The concept of continuous reuse requires resultsof analysis to be used to improve the reusedecision-making processes, thereby closing theimprovement loop.

I Reuse guidelines and procedures. Analysis is usedto affect changes in the technical performanceof reuse. The use of reuse guidelines providedone way to feedback experience as processimprovements. For example, analysis hadshown the desirability of black-box reuse dueto savings in re-testing of changed components(over £1000 per component). Evidence alsosupported the enforcement of basic designprinciples; the goal was to create small, simple,


180

cohesive and loosely coupled requirements,designs and code objects. These steps helpedto minimize the amount of change whilstmaking functions easier to understand andreuse. The reuse process is institutionalizedwhen it is stable enough to be incorporatedinto operating procedures. This creates a definedreuse process that itself is subject to reviewand improvement.

The major benefit of identifying improvementpaths was to make clear the link between reuseanalysis and organizational changes that mightresult. It also served to keep the measurementprocess focused on end-results in the minds ofall participants.

Step 6: Operate, Evaluate, Iterate

Whilst our description in this paper has beensequential, the improvement process is aninherently iterative model requiring gradualrefinement at each stage. It is necessary to operate,evaluate and iterate the process as inevitablechanges occur in the engineering process and thebusiness-operating environment. Hence, periodicreviews are a necessary part of managing a reuse-based process.

RESULTING IMPROVEMENTS

The initial reuse programme had highlighted thecommercial significance of systematic reuse in thisorganization. The reuse from project A to Bachieved a level of 82% code reuse with a corre-sponding 80% cost saving. For this application, a1% improvement in the level of reuse achievedmeant a saving in excess of £100,000. Reuse wastherefore capable of providing convincing returnson investment.

The target project for PRIME improvements wasknown to be significantly dissimilar to the earlierapplications. Our short-term goal, however, hadbeen to maximize reuse levels on this project(project C) whilst implementing the improvementsdescribed in this paper. The resulting profile ofpackage reuse levels achieved from project A toB, and from projects A and B to C, is shownin Figure 5.

A level of 42% system reuse had been achieved


Figure 5. Code reuse (%) by Ada package

on the new project – a considerable achievementwhen the changes were taken into account. Thesechanges included a new engine application, adifferent operational environment, and a mid-project shift to new controller hardware. This reuselevel and corresponding cost savings was assistedby incremental process improvements introducedduring the PRIME project.

The majority of improvements in reuse maturityintroduced by PRIME will mostly impact futureapplications, but early results are providing evi-dence for its expected effect on business perform-ance. The reuse-based process is now deliveringsome of the most rapid aeroengine FADEC develop-ments to date. The BR715 engine controller has beencertified after just over two years of developmentdespite a change in hardware standard and conse-quential software re-design. It is possible that suchtimescales could be improved beyond this levelbut controller development must ultimately comp-lement the engine and airframe programmes.Hence, improvement can now be focused onefficiency rather than overall timescale reduction.

The reuse-based process is also increasing thespeed at which systems achieve their requiredCopyright 1998 John Wiley & Sons, Ltd. Softw. Process Improve. Pract. 4, 173–182 (1998)

181

maturity, giving earlier confidence in productquality. Furthermore, measuring the actual levelsof reuse at the first build provides an early warningto project managers as to the final project costsgiving a valuable improvement in project manage-ability.

CONCLUSIONS

This paper has described some experiences andlessons learned from the introduction of a continu-ous reuse improvement process within Rolls-Royceplc. Contrary to belief, successful reuse is seen todepend as much on organizational and culturalissues than to those of technology. Nevertheless,a significant and continuous effort is required tomake reuse part of the organization’s culture andmaintain reuse momentum.

The outcome is a target-led reuse process inclear alignment with business objectives. The collec-tion and analysis of a small set of well-understoodmetrics supports our emphasis on practical sol-utions to reuse measurement, whilst the additionof ‘improvement paths’ keeps participants focusedon end results of this improvement process.


The improvements introduced by PRIME haveresulted in a significantly improved measurementand management capability for both the reuseprocess and the process incorporating reuse. More-over, they have provided a critical capability forfurther improvements in the future.

ACKNOWLEDGEMENTS

The PRIME Process Improvement Experiment wasfunded by the European Systems and SoftwareInitiative (ESSI) project 21670. The authors wouldalso like to thank the following people for theircontribution to the PRIME project: Andrew Nolan;Steve Kerr; Paul Essam; Stuart Hutchesson; KeithHarper, and Eddie Williams.

REFERENCES

Basili, V. R. 1992. Software modeling and measurement:the goal/question/metric paradigm. Technical ReportCS-TR-2956, Department of Computer Science, Universityof Maryland, College Park, MD, September.

Clark, G. D. and A. L. Powell. 1999. Collaborativesoftware process data collection: BAe and Rolls-Royce’sexperience of sharing a measurement philosophy. Inter-national Conference on Systems Engineering (INCOSE),Brighton, England, 7–10 June.

EDITORS’ COMMENT

For all who still believe software process improvement is still more or less an academic experiment thispaper not only describes how to improve the reuse process in a major company, namely Rolls-Royce,but also presents quantified results showing the extent to which the improvement is measurable. It isthus a perfect example of how to present a convincing case for both the justification and the necessityof process improvement. It should, in fact, be considered as a guide for those of you who have yet toestablish a systematic process improvement effort.

—WS/DP


182

Hill, J., K. Harper, R. Rimmer, J. A. McDermid, B. R.Whittle and M. Yates. 1994. Reuse of engine controllertechnology. Presented at the Avionics Conference ‘Sys-tems Integration is the Sky the Limit?’, Heathrow.

Joos, R. 1994. Software reuse at Motorola. IEEE Software,42–47.

Lam, W. 1997. Achieving requirements reuse: a domain-specific approach from avionics. Journal of Systems andSoftware, 38(3), 197–209.

Lim, W. C. 1994. Effects of reuse on quality, productivityand economics. IEEE Software, 23–31.

Myers, C. 1997. A framework for technology adoption.Software Engineering Symposium, Software EngineeringInstitute, Pittsburgh PA, June.

O’Connor, J., C. Mansour, J. Turner-Harris and G. H.Campbell. 1994. Reuse in command and control systems.IEEE Software, 70–79.

Powell, A. L., K. C. Mander and D. S. Brown. 1999.Strategies for lifecycle concurrency and iteration – asystem dynamics approach. Journal of Systems andSoftware, 46(2/3), 151.

Weiss, D. M. 1996. Family-oriented abstraction specifi-cation and translation: the FAST process. Proceedingsof the 11th Annual Conference on Computer Assurance,Gaithersburg, Maryland, IEEE Press, New Jersey, pp.14–22.

a practical strategy for industrial reuse improvement

Documents