Copyright © J FAC Experience with theManagement of Software Projects,Heidelberg. FRG. J 986

SOFTWARE DEVELOPMENT: THE STAIRCASEAPPROACH

K. Frühauf and K. J. JeppesenBrouni, Boueri & Cie, Baden, Suutzerland

Abstract. Modelling of the software development process for largesoftware systems provides a means for controlling software projects.This paper presents a new model the Staircase Approach, which takesinto account the merits. applicability, and limits of the well-known~aterfall, Evolutionary Development, and Fast Prototyping models. Ina nutshell, this approach utilises the ideas of EvolutionaryDevelopment for system level activities, the principles of theWaterfall Model for the lower level activities, and is suitedextremely well for practising Fast Prototyping. Experiences gained inapplying it indicate that the Staircase Approach is more suited thanconventional models in achieving the objective of better softwareproject control.

Keywords. Computer software; softwaremanagement; software quality assurance.

engineering; software

I NTRODUCT I ON software product is resoldto a hund red times

ten

Three dominating models, describing thesoftware development, can be currentlyidentified. The best known is theSoftware Life Cycle or Waterfall Model(e.g. Boehm, 1981). The work of Beladyand Lehman (1976) on EvolutionarySoftware Development started back in themiddle of the seventies. ~e are notaware of any reports, except Gilb(1983), about experiences applying theirideas. In recent years many softwareengineers can remember that Rapid orFast Prototyping is an efficient way tocheck the feasibility of solutions.Prototyping can support or even replacethe first phases in the Software LifeCycle, but it can not be used todescribe the entire software developmentprocess. An example of fitting FastPrototyping into the Software Life Cyclecan be found in Matsumoto (1986).

The software product - a systemof the BECOS family (Goudie,Davis, and Spatz 1984) - isresold, but in relatively smallquantities compared with e.g.compilers. It must, however,be adapted every time to theneeds of the actual customer.Thus it is neither a singleshot "customer tailored" nor amass produced (by copying) "offthe shelf" product.

data arespecific

always customer

software is embedded

Even if the algorithms could bereused without change, the data- which is considerable for apower system - are by naturecustomer specific. The test onthe actual hardwareconfiguration and with theactual customer data requires acertain amount of time: thefreeze of the software and acontrolled transfer from theproduct development to theproject is a necessity.

In order to enable the readers to judgethe applicability of our approach intheir environment, we list he repreconditions which have had a majorimpact on the selection of our approach:

The software productthe del iverycomputer andequipment.

is part ofcomprisingtelemetry

delivery times last from 636 months

to

The delivery time depends on

115

116

WATERFALL MODEL :MERITS AND DEFICIENCIES

K. Frühauf and K. J. Jeppesen

the size of the system. Theproduct release, on which thedelivery is based, must beknown around 6 to 12 monthsahead, at the tendering stage.With the biggest systems,customisation is carried out onmore than one release. Thisputs some constraints on thecharacteristics of theconsecutive releases, e.g.upwards compatibility.

number of products have alreadybeen developed

Feasible patterns for solutionsare available. The developmentof a new product can start withreusing big lumps of availablesoftware.

requirements are unstable

For products of a certain sizeand complexity, neither thesupplier nor the customercompletely understand theproblems of the particularapplication and, therefore,cannot specify exactly allrequirements. The long projectlifetimes - from·the customer'sinitial idea until finalacceptance of the system canlast as long as ten years -accentuate this problem evenmore.

Developers want to describe thedevelopment process in terms of itsdifferent phases and tasks. Managementwants to establish a strategy forproduct development and deliveryprojects, i .e. taking the entire systemand its total lifetime into account. Itis difficult to achieve these two aimswith a single model.

In the following section we discuss howthe Waterfall Model can be used todescribe software development. Thebasic principles of the Waterfall Model- phases and milestones - turn out to bea kind of "natural law". We will alsodemonstrate, however, that the model isinadequate for establishing adevelopment strategy on a system level.The list of objections to the WaterfallModel provides the justification for theStaircase Approach.

Staircase Approach takes into accountbasic principles of the Waterfall Model,but avoids its system levelinapplicability by using ideas from theEvolutionary Software Developmentapproach. System level is that level ofabstraction, where the internaltechnical details are of no relevance.The main objective is to enablemanagement to control large softwaredevelopments.

As the Waterfall Model is the onlytheory which is not applicable "as isoin our environment, we will consider itsadvantages and drawbacks in thefollowing section.

In the Waterfall Modeldevelopment process

the software

is sequential

The development process issubdivided into logicallysequential phases. Theyreflect the natural sequence oftasks (e.g. specification,design, coding, test) toproduce an item of software.This logical sequence is, inmany cases, mapped on a timescale so that it leads to astrict, chronological sequenceof these tasks.

i s iterative

Mistakes detected in laterphases reinitiate the processat some earlier phase. Thisiteration attempts to cover thefact that a task, e.g. design,is not finished "for ever" at acertain milestone. Theco n s-equ e n c e isthat all phasesare finished only when the lastmilestone is reached.

F i g • Waterfall, by M.C. Escher(lithograph, 1961).

The Staircase Approach

This contradiction - strictly sequentialphases vs. iterations - is one of thereasons for the difficulties regardingsoftware projects. Another reason isthe confusion caused by the oftenneglected fact that the objects of thetasks in the different phases are notidentical (e.g. specification of thesystem, design of subsystems, coding andtesting of different modules).

While we can identify a single task, forexample, "system specification", we haveto cope with a number of "subsystemdesign" and even a larger number of"module coding" tasks. To force, e.g.that the coding of all modules be in onetime slot (phase) of a large project,would be from a managerial (e.g.resource demand) and technical point ofview (e.g. kernel facilities neededfirst to ease test of applications),often foolish.Therefore, we have refined theinterpretation of a phase in theWaterfall Model. Example of ourinterpretation for, e.g. coding: "Amodule can only be coded when theenclosing subsystem is designed butirrespective of whether the othersubsystems are designed or not" insteadof the usual "all design must be donebefore coding". For thisinterpretation, we use the termactivity, e.g. module coding activity.By this interpretaion we are free toassign these activities to the adequatetime slots in the project, i .e. to ourphases.

The phases thus serve a well definedmanagerial purpose. Strictly sequentialphases, delimited by milestones, are atool for management in budget allocationand progress control. To enable adefinitive closing of phases, activitieson different elements of the softwarestructure must be each assigned uniquelyto a phase: when all activitiesassigned to a particular phase arefinished, the phase itself is finished.Thus iteration is replaced bysubdivision of tasks into "try it", "doit", and "modify it" types of activitiesand by the assignment of these topossibly different - phases.

Although the Waterfall Model is notsuited for the overall project, it isperfectly adequate for the developmentof a single function or block of relatedfunctions. It describes all necessaryactivities for development of a softwareitem by a limited number of people.Lower level management has the means to:

control theindividualstatus ofvi s ib le ,

progress ofgroups since

activities

thethei s

assign the different activities(e.g. specification, design,coding) in certain areas (e.g.human-computer interaction,telemetry) to different groupsin the organisation based on

their skillsavailability,

and resource

continuously improve effortestimates as every currentactivity completely defines thefollowing activity, includingestimates.

As soon as the work-breakdown results inelements requiring less than threeperson-years effort, the Waterfall Modelis the way to run the development.

Our concern is for software products ofa much bigger size and thus of a highercomplexity, where activities must becarried out by different groups. Here,the Waterfall Model does not adequatelydescribe the development process. Itsapplication to large projects could beeven dangerous. One of the dangers isthat large amounts of effort might beput into the first phases with nofeedback on usabi lity. Additionally,the tendency for "overperfecting", e.g.the design, without real progress on theproject, could result. Specification isanother example: engineers can alwaysargue that having an unsoundspecification bears a very high risk forthe project. The manager knows that andhas therefore no weapons to fight thisargument. Project termination couldremain as the only way to es cape fromthe endless loop of refining thespecification.

Another danger of the stringentapplication of the Waterfall Model tothe overall project is the frustrationof the developers. It might be verydemotivating to see the product foryears onLy on paper, but not "alive".The deveLopers could start to doubtwhether it wiLL ever work.

THE STAIRCASE APPROACH

Definitions

The above discussion indicated that wehave specific interpretation for somewidely used terms. We summarise hereour definition of the terms necessaryfor the understanding of the furthersections of the paper.

Project. The planned pattern of allactions necessary to produce a softwaresystem.

Phase. Aperiod of time within whichcertain results - a defined milestone -must be achieved. The chosen phase nameis, usuaLLy, the name of the dominantactivity in that period. Note the phasedefinition is in terms of time.

Mi lestone.ex istencesoftwareapproval.

Point in time defined by theof the predefined set ofitems, including their

117

118 K. Frühauf aud K. J. Jeppesen

Activity. Work unit carried out on anelement of the system structure at acertain level, e.g. systemspecification, subsystem design, modulecoding. Note that this definition isactually a type definition: module Acoding and module B coding are differentactivities of the same type (modulecoding). An activity must be uniquelyassigned to a phase.

Product. The result of a softwaredevelopment project, having a specificset of identified constituents, andhaving, at each stage of development, adefined functionality.

Release. The software items constitute apredefined functionality of the productbeing developed.

Variant. A variant is the basis foroperational software. lt is a subset ofarelease tailored to the needs of aparticular user and supplemented by thestatic data of the process to becontrolled. A variant may includesoftware items developed for customerspecific requirements.

Objectives

The objectivesApproach were:

fo r the Stai rcase

Define the development instages so that the product canbe, at every stage, describedand marketed as a completeproduct.

Provide a framework for thesystem level activities inaddition to the low-levelactivities according to theWaterfall Model.

Enable a bringing upversion of thequickly as possibleto:

an initialsystem as

in order

prove thethe idea,

feasibility of

demonstrate the system toprospective customers,

expose the systemmarket for earlyon the commercialthe product,

to thefeedback

value of

provide motivation todevelopers.

Establish regularly runningvers ions of the system to

allow managementdevelopment onl ev e l ,

to controla system

make sure that the systemis in a consistent state,

allow quality andfunctionality to beregularly verified.

Elements of the Staircase Approach

The Staircase Approachmain elements (see Fig.

threecomprises2) :

1. Release concept

Step-by-step enhancement of thesoftware product reaching, atregular intervals "anotherfloor with doors to theprospective customers", i.e.releases as basis for variants

hence the name "StaircaseApproach".

2. Release development

with assignedand defined

The schedule isthe release period.

Four phasesa c t i v i t i e smilestones.dictated by

3. Customisation in variants

Six phases with definedmilestones requiring customerapproval. Product tailoring tothe customer requirements doesnot allow as high astandardisation of activityassignments as does releasedevelopment.

Release Development

The heart of the Staircase Approach isthe development of the system in anumber of regularly issued releases. Arelease is defined by a set offunctional and quality requirements.The frequency of releases depends on thesize of the product and on the number ofpersons involved in the development.For power system control applicationsthe period shall be between four andtwelve months. The development of everyrelease can be considered as aseparateproject composed of the followingphases:

Release Planning

Specification of requirements,overall design, costestimation, personpowerplanning, and feasibilitystudies (including fastprototyping) are the mainactivities in this phase.Sales of variants based on agiven release will be launchedonly after this phase isfinished. The milestone is

The Staircase Approach

PRO~ECT: CUSTOMISATION VARIANT x[i]Tancerlng

;)\Realisation

OEVELOPMENT:

PROOUKTRELEASE 1

AII80mbly "foet

,1\Werranty

Plannlng

Implementetlon

Packeglng

Malntcnance

______________ :>~tlml!l

F i g. 2 The Staircase Approach.

Hsales launchingH and isachieved when the entire systemlevel documentation of therelease is available andapproved.

phase. The configurationprovides a comprehensive listof items forming the release(comprehensive means that dataand documents are included).The formal acceptance test,carried out by an independentgroup, confirms the consistencyof the items and theperformance according to thespecified requirements. Theproject and product auditprovide additional confidencefor the quality of thedevelopment process and of theproduct.

Release Implementation

The main activities are thedetailed specification offunctions and design of themodifications to the currentrelease (including reviews),test design, coding and test ofthe modifications, integrationof the modifications and systemt es t.

Release MaintenanceThe main difficulty in thisphase is the work break-down.More than one function canrequire a modification to aparticular module. The workmust thus be sequenced eitherfunction-by- function (so thatat no point in time do twodevelopers have to modify thesame module) ormodule-by-module (so that allmodifications of a particuLarmodule for all the functionsare done as a work unit). Theformer is much easier to managebut the danger of Hslippinginto corrupted designH must berecognised and avoided.

One of the merits of theapproach is that this phasecomprises only correctivemaintenance. All requiredenhancements must be consideredin release planning. Providingthat development is directedtoward upwards compatibilityand that site updates areenforced, the releasemaintenance can be abandoned assoon as the next release isavailable. This requires someof the errors to be correctedtwice: First in the release itwas reported for andadditionally in the subsequentrelease.

Release Packaging

Configuration of the release,formal acceptance test, projectaudit, and product audit arethe dominant activities in this

The concern of all activities in therelease planning and packaging phases isthe entire system. Only a small team isinvolved at these stages.

119

120 K. Frühauf and K. J. Jeppesen

During release implementation, thefunctions are the main concern. Theirimplementation can strictly follow the"natural law" which is the middle partof the Waterfall Model: DetailedSpecification, Detailed Design, Codingand Unit Test, Integration. The size ofthe team depends on the functionalityincrement and can vary from release torelease. Many developers or even groupsof deveLopers can impLement functions inparaLLeL, each working strictlyaccording to the "natural law".

is the contract signature byboth the supplier and customer.

System Specification

ReLease maintenance is concerned withthe errors reported by the users of therelease. The entire system wilL bebrought to a consistent state in theform of release upgrade with some of theerrors removed. Between two releases upto four upgrades couLd be provided forthe users.

All uncertainties between thesupplier and customer which thecontract negotiations did nottake into account must besettLed in this phase. Thecontract must be reviewed andthe requirement specificationsrefined to the necessary Levelof detaiL. That LeveL isreached when the hardware itemscan be ordered and the variantcan be taiLored. The customershares here the work andresponsibility: He mustprovide aLL data correctlyand on time - describing hisapplication process.

Customisation in Variants Providing verificationprocedures for factoryacceptance tests at this stageand their approvaL by thecustomer will help a great deaLin clarifying requirements.Because the verificationprocedures are the mostuser-friendLy description ofthe product, their inclusion inthe contract is actuaLLy ourgoaL. However, the customersare not ready yet to acceptthis idea.

Product development is directed by themarket or, more precisely, by ourperception of what the market requiresand what the technology provides. Inthe delivery projects, i .e. projectsresulting in a variant, the target tomeet is the satisfaction of a particularcustomer.

The variant is derived from a specificproduct reLease. The customisation isbasicaLLy the specification of thecustomer's requirements and theconfiguration of the correspondingrelease subset supplemented by thecustomer specific data. Most of thecustomers, at least in our appLicationarea, will have requirements notconsidered in the planned productreleases. These customer specifics wiLLbe implemented within the framework ofthe delivery project and, unfortunatelyfor the customers, wilL be fully chargedfor. The advantage of having standardrequirements <of a given productreLease) is that their development costsare shared by all buyers of the product.

The miLestone of this phase isthe approval of the detailedspecification <and, hopefully,of the verification procedures)by the customer.

Realisation

Tendering

The product reLease is tailoredand the variant bui lt andloaded with all data needed tomodel the process to becontrolled. If customerspecifics are required, it isduring this phase in which therequired functions areimplemented, i .e. the variantis supplemented by the customerspecific software items. Thedevelopment of these functionsfollows exactly the same pathas for release implementation.The system test is accomplishedaccording to the verificationprocedures prepared for thefactory acceptance test. Thetests should include the usermanuals. The quality assuranceengineer will certify theachievement of the milestone"system test passed".

The delivery projects arechronologically subdivided into thefollowing phases: tendering, systemspecification, realisation, assemblytest, installation, warranty, andmaintenance. The following sectionsdescribe which activities are carriedout in these phases, with specialemphasis on what is available with eachparticular milestone. Note that theconcern of all activities is thevariant.

The most important activity isto find the best matchingproduct release and to identifythe deviations between theexpectations of the prospectivecustomer and the requirementspecifications of the chosenrelease. These deviations arethe main topics of thecontractual negotiations. Themilestone delimiting this phase

Assembly test

The independently testedsoftware system is brought tothe independently tested actualhardware. The purpose of thephase is to test, priordelivery, the hardware-softwarecombination in supplier's test

The Staircase Approach

field. Corrective maintenancewill be made. Latest by thestart of the factory acceptancetest all user manuals must beready. The succesfulcompletion of the factoryacceptance test will becertified by the customer andthe variant version archived.The approval of theverification procedures for thecustomer site acceptance testsat this stage is highlyrecommended.

Installation

The hardware and software areinstalled and tested at thecustomer site. Softwareproblems are either reportedback home or corrected on site.The valid version of thevariant is always the one onthe customer site. Themilestone is the successfulsite acceptance test certifiedby the customer. The softwareengineer must not forget totake home the last version forarchiving. This is aprerequisite for any chance toreproduce and correct errorsreported by the end user.

Warranty

Corrective maintenance based onproblem reports from end users.The end of the phase iscertified by the customer withthe certificate of finalacceptance. The completeversion of the variant will bearchived as well as the projectfolder containing the historyof the project. A nice projectleader will even write aproject closing report withsome figures and remarks usefulfor his or her colleagues.

Maintenance

Maintenance as generallyunderstood. Biggerenhancements will be carriedout as a new project or, if weare lucky, the next productrelease will do it. The luckis dependent on thecompatibility of the customerspecifics in the variant withthe new release. Everymaintenance lump is finishedwith the archiving of the newversion of the variant and ofthe updated project folder.

EXPERIENCE GAINEO

The main advantage in applying theStaircase Approach is the frequency of"deliveries" with stringent control of

quality, value, cost, and schedule. Thechoice of the release period is atrade-off between the cost of releasepackaging and the prospective benefit ofrisk reduction. It is mainly dependenton the product size. The best approachis to limit the fund for arelease andinsist on provision of areleasespecification which can be implementedwith that money.

The time between initial tendering andorder is, in our business, roughlytwelve months. Assuming areleaseperiod of six months, management mustalways have at hand plans for at leasttwo releases ahead.

The application of the StaircaseApproach to a two hund red person-yearsdevelopment effort of a product with thelife-time of ten years results in ten totwenty small and thus manageableprojects. With arelease period of sixmonths, they will last - from start ofthe release planning until the end ofrelease maintenance - at most two yearsand consume ten to twenty person-yearsdevelopment effort. Note that the maincause of the two years time interval isthe long tendering phase. The twophases of realisation and packagingtogether last the release period (e.g.six months); the maintenance phase lastsan equal period of time. Half of therelease lifetime is used for theplanning phase - enough room toextensively practise Fast Prototyping.

Fast Prototyping is used for threepurposes. First, it is used forfeasibility studies whi le specifyingreleases. The simulation of interfacesto existing software packages is anotherpurpose. Before deciding to incorporatean application software package, theinterface is prototyped. In addition tothe feasibility demonstration, the knownprototyping effort enables a moreaccurate cost estimate for the actualincorporation. Finally, the earlypresentability of the future product"surface" provides a higher confidencelevel by management as well as by theprospective customers. Both managementand prospective customers can see whatthey wi~l get for their money.

The release implementation, packaging,and maintenance phases are at any timein progress tor a single release.Necessitated by its length, releaseplanning of two consecutive releaseswill overlap. This enables highflexibility in allocating requirementsto the releases depending on the currentset of variant tenders and orders. Astrong discipline in documenting andcommunicating the decisions within theteam is a necessity, otherwise confusionabout the final appearance of theconcerned releases is the unavoidableconsequence.

We encounteredwhen applyingdevelopers focusrelease. Theythat funding may

an interesting problemthis approach. Theonly on the next

are naturally concerneddry up, and thus there

121

122 K. Frunauf and K. J. Jeppesen

a standardwiLL be no money for cLimbing the nextsteps on the staircase. They havedifficuLty recognising that the systemdeveLopment is not according to theWaterfaLL ModeL (which appears to be amore finite process). The consequenceis that they tend to put the fuLLfunctionaLity into the next reLease,aLthough onLy part of the functionaLitywas specified for. Providing thedeadLines are met and the costs does notexceed the budget. this can Lead tomore-than-mature reLeases. The managermust, thus, carefuLLy untangLe thereasons of deadLine slippage.

F ig. 3 ReLativity, by M.C. Escher(Lithograh, 1953).

With the product reLeases pLannedsufficientLy ahead it is much easier tonegotiate with a prospective customer:onLy the requirements not met by thecorresponding reLease must benegotiated. The deLivery time of thebest-matching reLease couLd be too Latefor the purchaser. Assuming upwardscompatibiLity of the releases, thisproblem can be resolved by phaseddelivery: the customer will obtainsuccessive releases until his ultimaterequirements are satisfied. The crucialmatter is to have a well-designedproduct so that upwards compatibilitycan be guaranteed. Everyone who hasbeen told by an operating systemsupplier that the releases of hisoperating system are completely upwardscompatible wiLL soon realise that forprocess control applications this is avery difficult task !

Delivery time for a variant can beshortened significantly. If the variantdoes not contain any customer specificsthe delivery time is dictated by thehardware delivery. Buying releasefunctionality thus provides the customerwith the advantage of lower price andshorter deLivery. An additionaladvantage is provided by having a largernumber of end users: all of them willcontribute to error discovery.Remaining errors in customer specificscan, by nature, occur only on one site.In summary, the customer has less risk

in purchasingrelease.

product

In Paige (1985), a distinction is madebetween software development for noveland sustaining products. Theapplication of the Staircase Approachfor development of sustaining productsis straight forward. They have stablerequirements so it is easy to reuseavailable solutions: the step to thefirst release, which should already beof vaLue to end users, can be madewithin the expected time frame.

It is much more difficult to apply theapproach for the development of novelproducts. The critical matter is thesize of the product. The systemarchitect's challenge is to identify thekernel part of the system which thenbecomes release one. This first releasewiLL usually take more than the intendedrelease period, but it should not takelonger than two periods. The secondrelease will most likely be the firstrelease of any vaLue to an end user.

In both cases, the consistentapplication of the Staircase Approachencourages the reuse of software. Withstrictly limited funds allocated and therequest for releases usable by end usersthe "must be invented here" syndrome canbe very effectively fought.

CONCLUSIONS

The Staircase Approach is the synthesisof the weLL-known software developmentmodels. It is an attempt to use theirmerits and avoid their drawbacks. Theevolution of a product is forced intoregular, timely steps, and thedevelopers are forced to let the product"out of their hands" for customisation.This. frequent exposure of their resultsto other internal groups and tocustomers stimulates "craftsman pride"of the developers. The successfulpassing of all acceptance tests andaudits provides job satisfaction andcontinued motivation.

But it is not easy to convincedevelopers that every six months acomplete product must be turned outwithout aLL their briLLiant ideas beingimpLemented. It i s even more difficultto convince the salesmen that sellingvariants strictly adhering to therelease functionality will createcustomer satisfaction and tip thebalance sheet in their favour.

Customers in the area of power systemcontrol will soon accept this newsituation. They will observe happyneighbours operating reliable systemsand having forgotten all their extrawishes - partly because the next releasewill include their w;shes for the priceof a software update contract, andpartly because they have learned, byusing the system, that the benefit could

The Staircase Approach 123

never outweighextras.

the cost of t h ei r

The prerequisite for the approach is asystem architecture designed for easyextensions and a provision of allessential functions in the initialrelease. Thus, knowledge of the marketand software engineering know-how arenecessary.

ACKNOWLEOGHENTThe authors would like to express theirappreciation to F. Merola for improvingthe language of the paper.

REFERENCESBelady L.A., Lehman, M.M. (1976). AModel of Large Program Development. IBMSystems Journal, No. 3, 1976, ~225-252.

Boehm B.W. (1981). SoftwareEngineering Economics. Prentice Hall,1981.

Frahauf K., and Sandmayr H. (1983).Quality of the Software DevelopmentProcess. IFAC Safecomp 83, CambridgeUniversity-press 1983, pp.--145-152.

Gilb T.Technoscopes.manuscript, 1983.

(1983). ManagementUnpublished book

Locher J.L. ed. (1971).De werelden vanMeulenhOff

1971. Sourcelithographs by

M. C. Escher.International Amsterdam,for photocopies of theM.C. Escher.

Matsumoto Y. (1986). RequirementsEngineering and Software Development :A Study Toward Another Life Cycle ModelProceedings of the Symposium ComputerSystems for -Process Control. PlenumPublishing-corporation, 1986.

Paige M.P. (1985).Assurance Strategy.Eighteenth AsilomarCircuits, Systems andComputer Society. 1985:

On Software QualityConference RecordConference-----o--nCompute rs. IEU

pp. 257-261.