Dependable software - PDF document

Dependable softwareBertrand Meyer, ETH ZurichABSTRACTAchievingsoftwarereliabilitytakesmanycomplementarytechniques,directedattheprocessorattheproducts.Thissurveysummarizessomeofthemost1OVERVIEWEveryonewhousessoftwareorreliesondevicesorprocessesthatusesoftwareÑinotherwords,everyoneÑhasanaturalinterestinguaranteesthatprogramswillperformproperly.Thefollowingpagesprovideareviewoftechniques to improve software quality.Therearemanysubculturesofsoftwarequalityresearch,oftenseeminglysealedofffromeachother;mentioningprocess-basedapproachessuchasCMMItoprogramminglanguagetechnologists,orteststopeopleworkingonproofs,canbeasincongruousasbringingupBalanchineamongbaseballfans.Thissurveydisregardssuchestablishedculturalfencesandinsteadattemptstoincludeasmanyaspossibleoftherelevantareas,ontheassumptionthatproducinggoodsoftwareishardenoughthatÒeverylittlebitcountsÓcountsÓ.Asa result we will encounter techniques of very diverse kinds.Anoteofwarningtothereaderseekingobjectivity:IhavenotshiedawayfromincludingreferencesÑeasytospotÑtomyownwork,withtheexpectation(ifajustiÞcationisneeded)thatitmakestheresultmorelivelythan a cold inspection limited to other peopleÕs products and publications.2SCOPEANDTERMINOLOGYTheÞrsttaskistodeÞnesomeofthefundamentalterms.EventheÞrstwordofthisarticleÕstitle,determinedbytheHaslerFoundationÕsÒDependableInthesoftwareengineeringliteraturethemorefamiliartermisnotÒdependableÓbutÒreliableÓ,asinÒsoftwarereliabilityÓ.Acheckthroughgeneral-purposeandtechnicaldictionariesconÞrmsthatthetwohavesimilarCiteasfollows:BertrandMeyer,Software,toappearinDependableSystems:Software,Computing,Networks,eds.JŸrgKohlas,BertrandMeyer,AndrŽSchiper,LectureNotesinComputer Science, Springer-Verlag, 2006. DEPENDABLE SOFTWARE TheredoesexistadeÞnitionofdependabilitydependabilityfromtheeponymousIFIPWorkingGroup10.410.4thattreatsreliabilityasonlyoneamongdependabilityattributes,alongwithavailability,safety,conÞdentiality,integrityandmaintainability.Whilepossiblyapplicabletoacomputingsystemasawhole,thisclassiÞcationdoesnotseemrightfortheirsoftwarepart,assomeattributessuchasavailabilityarenotpropertiesofthesoftwareperse,otherssuchasconÞdentialityareincludedinreliability(throughoneofitscomponents,security),andtheremainingonessuchasmaintainabilityareofdubiousmeaningforsoftware,beingbettercoveredbyotherqualityfactorssuch as extendibility and reusabilityxtendibility and reusability.Asaconsequenceoftheseobservationsthepresentsurveyinterpretsdependability as meaning the same thing, for software, as reliability.DeÞning reliabilityThetermÒsoftwarereliabilityÓitselflacksauniversallyaccepteddeÞnition.OnecouldarguefortakingittocoverallÒexternalqualityfactorsÓsuchaseaseofuse,efÞciencyandextendibility,andevenÒinternalqualityfactorsÓsuchasmodularity.(Thedistinction,detailedinin,isthatexternalfactorsaretheproperties,immediateorlong-term,thataffectcompaniesandpeoplepurchasingandusingthesoftware,whereasinternalfactorsareperceptibleonlytosoftwaredevelopersalthoughintheendtheydeterminetheattainmentof external factors.)Itisreasonabletoretainamorerestrictedviewinwhichreliabilityonlycoversthreeexternalfactors:correctnessrobustness.ThisdoesnÕtimplythatothersareirrelevant;forexampleeventhemostcorrect,robustandsecuresystemcanhardlybeconsidereddependableifinpracticeittakesagestoreacttoinputs,anefÞciencyproblem.Thesamegoesforeaseof:manysoftwaredisastersonrecordhappenedwithsystemsthatimplementedtherightfunctionsbutmadethemavailablethrougherror-proneuserinterfaces.Thereasonsforlimitingourselvestothethreefactorslistedare,Þrst,thatincludingallotherswouldturnthisdiscussionintoasurveyofessentiallythewholeofsoftwareengineering(see(see);second,thatthetechniquestoachievethesethreefactors,althoughalreadyverydiverse,haveacertainkindredspirit,notsharedbythoseforenhancingefÞciency(likeperformanceoptimizationtechniques),easeofuse(likeergonomicdesign)and other external and internal factors. 2SCOPE AND TERMINOLOGY Correctness, robustness, securityFor the three factors retained, we may rely on the following deÞnitions:¥CorrectnessisasystemÕsabilitytoperformaccordingtoitsspeciÞcation¥RobustnessisasystemÕsabilitytopreventdamageincasesoferroneous¥SecurityisasystemÕsabilitytopreventdamageincasesofhostileuseTheycorrespondtolevelsofincreasingdeparturefromthespeciÞcation.ThespeciÞcationofanyrealisticsystemmakesassumptions,explicitorimplicit,abouttheconditionsofitsuse:aCcompilerÕsspeciÞcationdoesnÕtdeÞneageneratedprogramiftheinputispayrolldata,anymorethanapayrollprogramdeÞnesapaycheckiftheinputisaCprogram;andabuildingÕsaccesscontrolsoftwarespeciÞcationcannotdeÞnewhathappensifthebuildinghasburned.Bynature,therequirementsdeÞnedbyrobustnessandsecurityaredifferentfromthoseofcorrectness:outsideofthespeciÞcation,wecannolongertalkofÒperformingÓaccordingtothatspeciÞcation,butonlyseekthemoremodestgoalofÒpreventingdamageÓ;notethatthisimpliestheSecuritydeservesaspecialmentionasinrecentyearsithasassumedahighlyvisibleplaceinsoftwareconcerns.Thisisaphenomenontobebothlamented,asitsignalstheendofagoldenageofsoftwaredevelopmentwhenwecouldconcentrateondevisingthebestpossiblefunctionalitywithouttoomuchconcernabouttheworldÕsnastiness,andatthesametimetakentoadvantage,sinceithasÞnallybroughthometocorporationstheseriousnessofsoftwarequalityissues,aresultthatdecadesofhectoringbyadvocatesofmodernsoftwareengineeringpracticeshadfailedtoachieve.OneofthemostvisiblesignsofthisphenomenonisBillGatesÕsedictfamouslyhaltingalldevelopmentinFebruaryof2001infavorofcodereviewsforhuntingdownsecurityßaws.Manyoftheseßaws,suchasthemostobnoxious,bufferoverßow,aresimplytheresultofpoorsoftwareengineeringpractices.Eveniffocusingonsecuritymeanslookingatthesymptomratherthanthecause,ÞxingsecurityimpliestakingacoherentlookatsoftwaretoolsandtechniquesProduct and processAnycomprehensivediscussionofsoftwareissuesmustconsidertwoproductprocessTheproductsarethesoftwareelementswhosereliabilitywearetryingtoassess;theprocessincludesthemechanismsandprocedureswherebypeopleand their organizations build these products. DEPENDABLE SOFTWARE The products of softwareTheproductsthemselvesarediverse.Intheendthemostimportantone,forwhichwemayassesscorrectness,robustnessandsecurity,iscode.Buteventhatsimpletermcoversseveralkindsofproduct:sourcecodeasprogrammersseeit,machinecodeasthecomputerexecutesit,andanyintermediateversionsas exist on modern platforms, such as the bytecode of virtual machines.Beyondcode,weshouldconsidermanyotherproducts,whichintheirownwaysareallÒsoftwareÓ:requirements,speciÞcations,designdiagramsandotherdesigndocuments,testdataÑbutalsotestplansÑ,userTorealizewhyitisimportantinthesearchforqualitytopayattentiontoproductsotherthancode,itsufÞcestoconsidertheresultsofnumerousstudies,somealreadydecadesoldold,showingthesteepprogressionofthecost of correcting an error the later it is identiÞed in the lifecycle.IntryingtoascertainthereliabilityofasoftwareproductorprocesswemustoftenÑlikeadetectiveoraÞrepreventionengineerÑadoptanegativemindsetandlookforsourcesofofreliabilityproperties.Theaccepted terminology here distinguishes three levels:failureisamalfunctionofthesoftware.Notethatthistermdoesnotdirectly apply to products other than executable code.isadepartureofthesoftwareproductfromthepropertiesitshouldhavesatisÞed.Afailurealwayscomesfromafault,althoughnotnecessarilyafaultinthecode:itcouldbeinthespeciÞcation,inthedocumentation,orinanon-softwareproductsuchasthehardwareon¥Anerrorisawronghumandecisionmadeduringtheconstructionofthesystem.ÒWrongÓisasubjectiveterm,butforthisdiscussionitÕsclearwhatitmeans:adecisioniswrongifitcanleadtoafault(whichcaninturn cause failures).Inadiscussionlimitedtosoftwarereliability,allfaultsandhenceallfailuresresultfromerrors,sincesoftwareisanintellectualproductnotsubjecttotheslings and arrows of the physical world.ThemorefamiliartermforÒerrorÓisbug.Theuppercrustofthesoftwareengineeringliteratureshunsitforitsanimistconnotations.ÒErrorÓhasthebeneÞtofadmittingthatourmistakesdonÕtcreepintooursoftware:weinsertthem ourselves. In practice, as may be expected, everyone says ÒbugÓ. 2SCOPE AND TERMINOLOGY VeriÞcation and validationEvenwithsubjectivityremovedfromthedeÞnitionofÒerrorÓ,deÞnitionsfortheothertwolevelsaboveremainsrelative:whatconstitutesaÒmalfunctionÓ(forthedeÞnitionoffailures)oraÒdepartureÓfromdesirableproperties(forfaults)canonlybeassessedwithrespecttosomedescriptionoftheexpectedWhilesuchreferencedescriptionsexistforsomecategoriesofsoftwareproductÑanelementofcodeisrelativetoadesign,thedesignisrelativetoaspeciÞcation,thespeciÞcationisrelativetoananalysisoftherequirementsÑthechainalwaysstopssomewhere;forexampleonecannotintheendcertifythattherequirementshavenofault,asthiswouldmeanassessingthemagainstsomehigher-leveldescription,andwouldonlypushtheproblemfurthertoassessing the value of the description itself. Turtles all the way up.Evenintheabsenceofanotherreference(anotherturtle)againstwhichtoassessaparticularproduct,wecanoftenobtainsomeevaluationofitsquality checks. For example:¥Aprogramthatdoesnotinitializeoneofitsvariablesalongaparticularpathissuspicious,independentlyofanyofitspropertiesvis-ˆ-visthe¥Apoorlywrittenusermanualmaynotexplicitlyviolatetheprescriptionsof another project document, but is problematic all the same.Thisobservationleadstodistinguishingtwocomplementarykindsofreliabilityassessment,,oftencombinedintheabbreviation ÒV&VÓ:¥VeriÞcationisassessmentoftheconsistencyoftheproduct,consideredjustbyitself.ThelasttwoexamplesillustratedpropertiesthataresubjecttoveriÞcation:forcode;fordocumentation.Typecheckingisanother example.¥Validationisrelativeassessmentofaproductvis-ˆ-visanotherthatdeÞnessomeofthepropertiesthatitshouldsatisfy:codeagainstdesign,designagainstspeciÞcation,speciÞcationagainstrequirements,documentationagainststandards,observedpracticesagainstcompanyrules,deliverydatesagainstprojectmilestones,observeddefectratesagainst deÞned goals, test suites against coverage metrics.ApopularversionofthisdistinctiondistinctionisthatveriÞcationisaboutascertainingthattheproductisÒdoingthingsrightÓandvalidationthatitisÒdoingtherightthingÓ.Itonlyappliestocode,however,sinceaspeciÞcation,a project plan or a test plan do not ÒdoÓ anything. DEPENDABLE SOFTWARE 3CLASSIFYINGAPPROACHESOneofthereasonsforthediversityofapproachestosoftwarequalityisthemultiplicityofproblemstheyaddress.ThefollowingtableshowsalistofTheÞrstdistinctionisculturalalmostasmuchasitistechnical.Withaprioritechniquestheemphasisismethodological:tellingdevelopmentteamstoapplycertainrulestoproduceabetterproduct.WithaposteriorithegoalistoexamineaproposedsoftwareproductorprocesselementforpossibledeÞciencies,withtheaimofcorrectingthem.WhileitisnaturaltostatethatthetwoarecomplementaryratherthancontradictoryÑadefenseoftenusedbyproponentsofÒaposterioriÓapproachessuchastestingwhencriticizedforacceptingsoftwaretechnologyasitisratherthanhelpingtoimproveitÑtheycorrespondtodifferentviewsofthesoftwareworld,onehopeful of prevention and the other willing to settle down for cure.Theseconddistinctioncorrespondstothetwodimensionsofsoftwareengineeringcitedabove:areweworkingontheproducts,orontheprocessesSomeapproachesareofamethodologicalnatureandjustrequireapplyingsomepractices;wemaycallthem,incontrastwithCriteria for classifying approaches to software reliabilitybuildassess and correctProcessProductManualTool-supportedTechnology-neutralTechnology-speciÞcProduct- and phase-neutralProduct- or phase-speciÞcStatic (uses software text)Dynamic (requires execution)InformalMathematicalComplete (guarantee)Partial (some progress)FreeCommercial 3CLASSIFYING APPROACHES Anideacanbeapplicableregardlessoftechnologychoices;forexampleprocess-basedtechniquessuchasCMMI,discussedbelow,explicitlystayawayfromprescribingspeciÞctechnologies.Attheotherextreme,certaintechniquesmaybeapplicableonlyifyouacceptacertainprogramminglanguage,speciÞcationmethod,toolorothertechnologychoice.Wemaytalktechnology-neutraltechnology-speciÞcapproaches;thisismoreaspectrumofpossibilitiesthanablack-and-whitedistinction,sincemanyapproachesassumeacertainclassoftechnologiesÑsuchasobject-orienteddevelopment Ñ encompassing many variants.SometechniquesapplytoaspeciÞcproductorphaseofthelifecycle:speciÞcation(aspeciÞcationlanguage),implementation(astaticanalyzerofTheyareproduct-speciÞc,or.Others,suchasconÞgurationmanagementtools,applytomanyorallproductkinds;theyareproduct-neutral.ÒProductÓisusedheretodenoteoneofthetypesofoutcomeof the software construction process.Fortechniquesdirectedatprogramquality,animportantdivisionexistsapproachessuchastesting,whichrelyonexecutingtheprogram,andpurelyones,suchasstaticanalysisandprogramproofs,whichonlyneedtoanalyzetheprogramtext.Heretoosomenuancesexist:asimulationtechniquerequiresexecutionandhencecanbeclassiÞedasdynamiceventhoughtheexecutiondoesnÕtusethenormalrun-timeenvironment;model-checkingisclassiÞedasstaticeventhoughinsomeSomemethodsarebasedontechniques;thisisobviouslythecasewithprogramproofsandformalspeciÞcationingeneral.ManyareAtechniqueintendedtoassessqualitypropertiescangiveyouaguaranteethattheyaresatisÞed,orÑmorecommonlyÑsomereassurance to this effect.TheÞnaldistinctioniseconomic:betweentechniquesinthepublicdomainÑusableforfree,intheordinarysenseofthetermÑandcommercialones. DEPENDABLE SOFTWARE 4PROCESS-BASEDAPPROACHESWestartwiththeleasttechnicalapproaches,emphasizingmanagementprocedures and organizational techniques.OneofthedeÞningactsofsoftwareengineeringwastherecognitionoftheseparateactivitiesinvolved,intheformofÒlifecyclemodelsÓthatprescribeacertainorderoftasks(seetheÞgureontheadjacentpage).Theinitialmodelistheso-calledÒwaterfallÓallÓ,stillusedasareferencefordiscussionsofthesoftwareprocessalthoughnolongerrecommendedforliteralapplication.Variants include:¥TheÒVmodelÓwhichretainsthesequentialapproachofthewaterfallbutdividestheprocessintotwoparts,thebranchesoftheÒVÓ;activitiesalongtheÞrstbrancharefordevelopment,thoseinthesecondbranchareforveriÞcationandvalidation,eachappliedtotheresultsofoneofthe¥TheÒSpiralmodelÓmodelÓwhichfocusesonreducingriskinprojectmanagement,inparticulartheriskcausedbytheall-or-nothingattitudeoftheWaterfallapproach.ThespiralmodelsuggestsisolatingsubsetsofthesystemÕsfunctionalitythataresmallenoughtobeimplementedquickly,andwhentheyhavebeenimplementedtakingadvantageoftheexperiencetoproceedtootherpartsofthesystem.Theideaisconnected¥TheÒRationalUniÞedProcessÓ,distinguishingfourphases,inception,elaboration,constructionandtransition,withaspiral-likeiterativestyleofdevelopmentandasetofrecommendedÒbestpracticesÓsuchas¥TheÒClustermodelÓ[51][57],emphasizingadifferentformofincrementalityÑbuildingasystembylayers,fromthemostfundamentaltothemostuser-orientedÑandaprocesstreatingsuccessiveactivities,fromanalysistodesign,implementationandmaintenance,asacontinuum.Thismodelalsointroduces,aspartoftheindividuallifecycleofeverycluster,ageneralizationsteptoprepareforfuture reuse of some of the developed elements.The Þgure shows pictorial representations of some of these models. 4PROCESS-BASED APPROACHES Lifecycle models, illustratedWaterfall V-shaped Cluster Spiral(from[11]) DEPENDABLE SOFTWARE Whatevertheireffectonhowpeopleactuallydevelopsoftware,thecontributionoflifecyclemodelshasbeenaclassiÞcationanddeÞnitionoftheactivitiesinvolvedinsoftwaredevelopment,evenwhentheseactivitiesarenotexecutedasinthepreciseordermandatedby,forexample,thewaterfall model. Software quality beneÞts in particular from:¥Adistinctionbetweenrequirements,therecordingofuserrequirements,,theirtranslationintoasystematicformsuitableforsoftware development, where rigor and precision are essential.¥Recognition of the importance of VeriÞcation and Validation tasks.¥Recognitionofpost-deliveryactivitiessuchasmaintenance,althoughtheystilldonotoccupyavisibleenoughplace.Manysoftwaretroublesresult from evolutions posterior to the initial release.¥IntheClustermodel,thepresence,foreachcluster,ofthegeneralization¥AlsointheClustermodel,theuseofaseamlessandreversibleapproachwhichunifiesthemethods,tools,techniquesandnotationsthathelpthroughoutthesoftwareprocess,ratherthanexaggeratethem.(Thetextbookcounter-example here is the use of UML for analysis and designxample here is the use of UML for analysis and design.)¥Thegrowingemphasisonincrementalityinthedevelopmentprocess,evenifthisconceptisunderstooddifferentlyin,forexample,thespiral,cluster and RUP models.Organizational standardsAnotherprocess-relatedsetofdevelopmentshashadamajoreffect,largelybeneÞcial,onsomesegmentsoftheindustry.Intheearly1990stheUSDepartmentofDefense,concernedwiththeneedtoassessitssuppliersÕsoftwarecapabilitiesandtoestablishconsistentstandards,entrustedtheSoftwareEngineeringInstitutewiththetaskofdevelopingaÒCapabilityMaturityModelÓ,whosecurrentincarnation,CMMICMMI(theIisforIntegration)providesacollectionofstandardsapplicabletovariousdisciplines,ratherthanasinglemodelforsoftware.Largelyindependently,theInternationalStandardOrganizationhasproducedasetofsoftware-orientedvariantsofits9000-seriesqualitystandards,whichshareanumberof 4PROCESS-BASED APPROACHES Beyonditsoriginaltargetcommunity,CMMandCMMIhavebeenthecatalystforoneofthemajorphenomenaoftheITindustrystartinginthemid-nineties:thedevelopmentofoffshoresoftwareproduction,especiallyinIndiaIndia.CMMIqualiÞcationprovidessuppliersofoutsourcingdevelopmentserviceswithqualitystandardsandtheassociatedpossibilityofindependentcertiÞcation,withoutwhichcustomerswouldnotbehaveknownhowtotrustdistant, initially unknown contractors.CMMIis(intheearlierclassiÞcation)product-neutral,phase-neutralandtechnology-neutral.InitsapplicationtosoftwareitisintendedonlytodeterminehowwellanorganizationcontrolsitsdevelopmentprocessbydeÞninganddocumentingit,recordingandassessinghowitisappliedinpractice,andworkingtoimproveit.ItdoesnÕtprescribewhattheprocessshouldbe,onlyhowmuchyouareontopofit.Youcouldpresumablybedeveloping in PL/I on IBM 370 and get CMMI qualiÞcation.CMMIassessesboththelevelofindividualÒprocessareasÓin(suchassoftware)inanorganization,andtheofanorganizationasawhole. It distinguishes Þve levels of increasing maturity:Performed:projectshappenandresultsgetproduced,butthereislittlecontrol and no reproducibility; the process is essentially reactive.Managed:processesareclearlydeÞnedforindividualprojects,butnotfor the organization as a whole. They remain largely reactive.: proactive process deÞned for the organization.Quantitativelymanaged:thecontrolmechanismsdonotlimitthemselvesto qualitative techniques, but add well-deÞned numerical measurements.:themechanismsforcontrollingprocessesaresufÞcientlywellestablishedthatthefocuscanshiftonimprovingtheorganizationThroughtheiremphasisontheprocessanditsrepeatability,CMMIandISOstandardshelpimprovethequalityofsoftwaredevelopment.Onemayexpectsuchimprovementsoftheprocesstohaveapositiveeffectontheresultingproductsaswell;buttheyareonlypartofthesolution.AfterasoftwareerrorÑonemoduleofthesoftwarewasexpectingmeasuresinthemetricsystem,anotherwasprovidingtheminEnglishunitsÑwasidentiÞedasthecauseofthefailureoftheNASAMarsOrbiterVehiclemissionmission,anengineerfromtheprojectnotedthattheorganizationwasheavilyintoISOandotherprocessstandards.Processmodelsandprocess-focusedpracticesarenotasubstituteforusingthebesttechnologicalsolutions.TailoredversionsofCMMIthatwouldnotshyawayfromintegratingspeciÞctechnologiessuchasobjecttechnologycouldbeextremelyuseful.Inthemeantime,thetechnology-neutralrequirementsofCMMIcanbeappliedbyorganizationstogetabetterhold on their software processes. DEPENDABLE SOFTWARE Extreme programmingTheExtremeProgrammingmovementementisareactionagainstpreciselythekindsoflifecyclemodelsandprocess-orientedapproachesjustreviewed.XP(asitisalsocalled)emphasizesinsteadtheprimacyofcode.Someofthe¥Short release cycles to get frequent feedback.¥Pair programming (two people at a keyboard and terminal).¥Test-driven development.¥AgeneraldistrustofspeciÞcationanddesign:isthepreferredguide of development.¥Emphasis on programmersÕ welfare.SomeofthesepracticesareclearlybeneÞcialtoqualitybutweredevelopedpriortoXP,inparticularshortreleasecycles(MicrosoftÕsÒdailybuildÓasdescribedin1995byCusumanoandShelbyShelby,seealsoalso)andtheuseoffrequenttestingaspartofdevelopment(seee.g.ÒqualityÞrstÓÞrstÓ).ThosereallyspeciÞctoXPareoflimitedinterest(whilesometimesagoodpractice,pairprogrammingcannotbeimposedindiscriminately,bothbecauseitdoesnÕtworkforsomepeopleandbecausethosewhoÞnditusefulmaynotÞnditusefulallthetime)or,inthecaseoftestsviewedasareplacementspeciÞcations,downrightdetrimental.SeeSeeand[64]forcritiquesoftheapproach.Along-establishedqualitypracticeistheinspection,alsoknownasreviewsessiondesignedtoexamineacertainsoftwareelementwiththeaimofÞndingßaws.Themostcommonformisinspection,buttheprocesscanbeapplied to any kind of software engineering product. Rules include:¥Smallmeeting:atmost8peopleorso,includingthedeveloperoftheelement under review.¥Theelementsunderreviewandanysupportingdocumentsmustbecirculatedinadvance;theparticipantsshouldhavereadthemandidentiÞedpossiblecriticismsbeforethemeeting.Theallottedtimeshouldbe bounded, for example 2 or 3 hours. 4PROCESS-BASED APPROACHES ¥Themeetingmusthaveamoderatortoguidediscussionsandasecretary¥ThemoderatorshouldnotbethedeveloperÕsmanager.Theintentistoevaluate products, not people.¥ThesolegoalistoidentifydeÞcienciesandconÞrmthattheyareindeeddeÞciencies;correctionisnotpartoftheprocessandshouldnotbeCodeinspectionscanhelpavoiderrors,buttoassesstheirusefulnessonemustcomparethecostswiththoseofrunningautomatedthatcancatchsomeofthesameproblemswithouthumanintervention;staticanalyzers,discussedbelow, are an example.Somecompanieshaveinstitutionalizedtherulethatnodevelopermaycheckincode(integrateitintotherepositoryforacurrentorfutureproduct)withoutapprovalbyoneotherdeveloper,alimitedformofcodeinspectionthathasaclearlybeneÞcialeffectbyforcingtheoriginaldevelopertoconvinceat least one other team member of the suitability of the contribution.Open-source processesAgeneralizationoftheideaofcodeinspectionisthefrequentassertion,bymembersoftheopen-sourcecommunity,thattheopen-sourceprocessdramaticallyimprovesqualitybyenablingmanypeopletotakeacriticallookatthesoftwaretext;somehavegonesofarastostatethatÒgivenenougheyes,all bugs are shallowe shallow.Aswithmanyoftheothertechniquesreviewed,wemayseeinthisideaabeneÞcialcontribution,butnotapanacea.JohnViegagivesestheexampleofawidelyusedsecurityprograminwhichÒinthepasttwoyears,severalverysubtlebufferoverßowproblemshavebeenfoundAlmostallhadbeeninthecodeforyears,eventhoughithadbeenexaminedmanytimesbybothhackersandsecurityauditorsOnetoolwasabletoidentifyoneoftheproblemsaspotentiallyexploitable,butresearchersexaminedthecodethoroughlyandcametotheconclusionthattherewasnowaytheproblemcouldbeexploited.(ThelastobservationisanecdotalevidencefortheaboveobservationthattoolsWhileisnoevidencethatopen-sourcesoftwareasawholeisbetter(orworse)thancommercialsoftware,andnoabsoluteruleshouldbeexpectedifonlybecauseofthewidevarietyofproductsandprocessesonbothsides,itisclear that more eyes potentially seemore bugs. DEPENDABLE SOFTWARE Requirements engineeringInareassuchasembeddedsystems,manyserioussoftwarefailureshavebeenbeentoinadequaterequirementsratherthantodeÞcienciesintroducedinlaterphases.Systematictechniquesforrequirementsanalysisareavailable[76][40]toimprovethiscriticaltaskofcollectingcustomerwishesandtranslating them into a form that can serve as a basis for a software project.Design patternsAprocess-relatedadvancethathashadastrongbeneÞcialeffectonsoftwaredevelopmentistheemergenceofdesignpatternspatterns.Apatternisanarchitecturalschemethathasbeenrecognizedasfruitfulthroughfrequentuseinapplications,andforwhichaprecisedescriptionexistsaccordingtoastandardformat.Patternsprovideacommonvocabularytodevelopers,hencesimplifyingdesigndiscussions,andenablethemtobeneÞtfromthecollectiveA(minority)viewofpatterns[62][65]understandsthemasaÞrststeptowardsthetechniquediscussednext,reusablecomponents.Patterns,inthisinterpretation,sufferfromthelimitationthateachdevelopermustmanuallyinsertthecorrespondingsolutionsintothearchitectureofeveryapplicablesystem.Ifinsteaditispossibletoturnthepatternintoareusablecomponent,developerscandirectlyreusethecorrespondingsolutionthroughanAPI(AbstractProgramInterface).Theobservationhereisthatitisbettertoreusethantoredo.InvestigationsestigationssuggestthatwiththehelpofappropriateprogramminglanguageconstructsuptotwothirdsofcommondesignpatternsTrusted componentsQualityimprovementtechniques,whethertheyemphasizetheprocessortheproduct,areonlyasgoodastheiractualapplicationbyprogrammers.Themagnitudeofthenecessaryeducationeffortisenoughtotemperanyhopeofmajorshort-termimprovements,especiallygiventhatmanyprogrammershave not had the beneÞt of a formal computer science education to start with. 4PROCESS-BASED APPROACHES Anotherpracticalimpedimenttocontinuedqualityimprovementcomesfrommarketforces.Theshort-termcommercialinterestofacompanyisgenerallytoreleasesoftwarethatisÒgoodenoughÓenoughÓ:softwarethathasbarelypassedthethresholdunderwhichthemarketwouldrejectitbecauseofbadquality;notexcellentsoftware.TheextratimeandexpensetogofromtheÞrsttothesecondstagemaymean,forthecompany,losingthemarkettoalessscrupulouscompetitor,andpossiblygoingoutofbusiness.Fortheindustryasawhole,softwarequalityhasindeedimprovedregularlyovertimebuttendsto peak below the optimum.Anapproachthatcanovercometheseobstaclesisincreasedrelianceonreusablecomponents,providingpre-builtsolutionstoproblemsthatariseinmanydifferentapplications,eitherregardlessofthetechnicaldomain(general-componentlibraries)orinparticularÞelds(Componentshavealreadychangedthenatureofsoftwaredevelopmentbyprovidingconvenientlypackagedimplementations,accessiblethroughabstractinterfaces,ofcommonaspectssuchasgraphicaluserinterfaces,databasemanipulation,basicnumericalalgorithms,fundamentaldatastructuresandothers,therebyelevatingthelevelatwhichprogrammerswritetheirapplications.Whenthecomponentsthemselvesareofgoodquality,suchreusehashighlybeneÞcialeffectssincedeveloperscandirecttheireffortstoExaminingmorecloselytherelationshipofcomponentstoqualityactuallyhighlightstwoseparateeffects:itiscomfortingtoknowthatthequalityofasystemwillbeneÞtfromthequalityofitscomponents;butwemustnotethatreusemagniÞesthebadaswellasthegood:beevenmoredamagingincomponentsthaninÒone-of-a-kindÓdevelopments,since they affect every application that relies on a component.Thenotionoftrustedcomponent[58][61]followsfromthisanalysisthatoneofthemostpressingandpromisingtasksforimprovingsoftwarequalityistheindustrialproductionofreusablecomponentsequippedwithaguaranteeofquality.Producingsuchtrustedcomponentsmayinvolvemostofthetechniquesdiscussedelsewhereinthisarticle.ForsomeofthemoredifÞcultones,suchasprogramproving,applicationtocomponentsmaybethebestwaytojustifythecostandeffortandrecouptheinvestmentthankstothescalingeffectofcomponentreuse:onceacomponenthasreachedthelevelofqualityatwhichitcanreallybetrusted,itwillbeneÞteveryapplicationthat DEPENDABLE SOFTWARE 5TOOLSANDENVIRONMENTSTransitioningnowtoproduct-orientedsolutions,weexaminesomeoftheprogressintoolsavailabletosoftwaredevelopersÑtotheextentthatitisrelevant for software quality.ConÞgurationmanagementisabothpractice(forthesoftwaredeveloper)andaservice(fromthesupportingtools),soitcouldinprinciplebeclassiÞedunderÒprocessÓaswellasunderÒproductÓ.ItbelongsmoreproperlytothelattercategorysinceitÕstoolsthatmakeconÞgurationmanagementrealistic;appliedasapureorganizationalpracticewithoutgoodtoolsupport,itquicklyConÞgurationmanagementmaybedeÞnedasthesystematiccollectingand registering of project elements, including in particular the ability to:¥Register a new version of any project element.¥Retrieve previously registered version of any project element.¥Registerdependencies,bothbetweenprojectelementsandbetweenregisteredversionsofprojectelements(e.g.relieson,andversion10 requires version 7, 8 or 9 of¥ConstructcompositeproductsfromtheirconstituentsÑforexample,buildanexecutableversionofaprogramfromitsmodulesÑorreconstructearlierversions,inaccordancewithregistereddependencies.AsigniÞcantnumberofsoftwaredisastersonrecordfollowedfromconÞgurationmanagementerrors,typicallyduetoreintroducinganobsoleteversionofamodulewhencompilinganewreleaseofaprogram,orusinganobsoleteversionofsomedataÞle.Excusesnolongerexistforsucherrors,asacceptableconÞgurationmanagementtools,bothcommercialandopen-source,arewidelyavailable.Thesetools,whilestillfarfromwhatonecouldhopefor,havemadeconÞgurationmanagementoneofthemostimportantpractices of modern software development.SourcecodeisnottheonlybeneÞciaryofconÞgurationmanagement.Anyproductthatevolves,hasdependenciesonotherelementsandmayneedrestoringtoanearlierstateshouldbeconsideredforinclusionintheconÞgurationmanagementrepository.Besidescodethismayincludeprojectplans,speciÞcationanddesigndocuments,usermanuals,trainingdocumentssuch as PowerPoint slides, test data Þles. 5TOOLS AND ENVIRONMENTS IfwebelieveLordKelvinÕs(approximate)maximthatallseriousstudyisquantitative,thensoftwareandsoftwaredevelopmentshouldbesusceptibletomeasurement,temperedofcoursebyEinsteinÕsequallyfamousquotethatnoteverythingmeasurableisworthmeasuring.Afewsoftwareproperties,processorproduct,areatthesametimemeasurable,worthmeasuringandrelevanttosoftware reliability.Ontheprocessside,initsvariousdimensionsisaprimeconcern.Whileitisimportanttorecordcosts,ifonlyforCMMI-styletraceability,whatmostprojectmanagerswantataparticulartimeisatoestimatethecostofafutureprojectoroftheremainderofacurrentproject.Suchmodelsdoexistandcanbeuseful,atleastifthedevelopmentprocessisstableandtheprojectiscomparabletopreviousones:thenbyestimatinganumberofprojectparametersandrelyingonhistoricaldataforcomparisononecanpredictcostsÑessentially,person-monthsÑwithinreasonableaverageaccuracy.Awell-knowncostmodel,forwhichfreeandcommercialtoolsareavailable,isCOCOMOIIII.Duringthedevelopmentofasystem,willbereported.InprincipletheyshouldnÕtbecomparabletothefaultsofamaterialproduct,sincesoftwareisanintellectualproductanddoesnÕterode,wearoutorcollapseunderattackfromtheweather.Inpractice,however,statisticalanalysisshowsthatfaultsinlargeprojectscanfollowpatternsthatresemblethoseofhardwaresystemsandaresusceptibletosimilarstatisticalpredictiontechniques.Thatsuchpatternscanexistisinfactconsistentwithintuition:ifthetestsonthelastfivebuildsofaproductunderdevelopmenthaveeachuncoveredonehundrednewbugseach,itisunlikelythatthenextiterationwillhavezerobugs,orathousand.Softwarereliabilityengineeringengineeringelaboratesontheseideastodevelopmodelsforassessingandpredictingfailures,faultsanderrors.Aswithcostmodels,arequirementformeaningfulpredictionsistheabilitytorelyonhistoricaldataforcalibration.Reliabilitymodelsarenotwidelyknown,butcouldhelpsoftwareprojects understand, predict and manage anomalies better.Moregenerally,numeroushavebeenproposedtoprovidequantitativeassessmentsofsoftwareproperties.Measuresofcomplexity,forexample,include:ÒsourcelinesofcodeÓ(SLOC),themostprimitive,butusefulallthesame;ÒfunctionpointsÓpointsÓ,whichcountthenumberofelementarymechanismsimplementedbythesoftware;measuresofthecomplexityofthecontrolgraph,suchasÒcyclomaticcomplexityÓxityÓ;andmeasuresspecificallyadaptedtoobject-orientedsoftwareare.TheEiffelStudioenvironmentvironmentmakesitpossibletocomputemanymetricsappliedtoaprojectunderdevelopment,includingmeasuresregardingtheuseofcontracts(section DEPENDABLE SOFTWARE ),andtocomparethemwithvaluesonrecord.Whilenotnecessarilymeaningfulinisolation,suchmeasureselementsareausefulcontroltoolforthemanager;theyareinlinewiththeCMMIÕsinsistencethatanorganizationcanonlyreachthehigherlevelsofprocessmaturity(4and5)bymovingfromthequalitativetothe quantitative, and should be part of the data collected for such an effort.Staticanalyzersareanotherimportantcategoryoftools,increasinglyintegratedindevelopmentenvironments,whosepurposeistoexaminethesoftwaretextfordeÞciencies.Theyliesomewherebetweentypecheckers(themselvesintegratedincompilers)andfullprogramprovers,andwillbestudied below (page Integrated development environmentsBeyondindividualtoolstheevolutionofsoftwaredevelopmenthasledtothewidespreadofintegratedtoolsuitesknownasIDEsforIntegrated(originally:Interactive)DevelopmentEnvironments.AmongthebestknownareMicrosoftÕsVisualStudioStudioandIBMÕsEclipseEclipse;EiffelStudiofelStudioisanotherexample.Theseenvironments,equippedwithincreasinglysophisticatedgraphicaluserinterfaces,provideunderasingleroofawholebatteryofmechanismstowritesoftware(editors),manageitsevolution(conÞgurationmanagement),compileit(compilers,interpreters,optimizers),examineiteffectively(browsers),runitandelucidatethesourcesoffaults(debuggers,testers),analyzeitforpossibleinconsistenciesanderrors(staticanalysis),generatecodefromdesignandanalysisdiagramsortheotherwayaround(diagramming,ÒComputer-AidedSoftwareEngineeringÓorCASE,reverseengineering),changearchitectureinasafewaythroughtool-controlledtransformations(refactoring),performmeasurementsasnotedabove (metric tools), and other tasks.Thisisoneofthemostactiveareasinsoftwareengineering;programmers,forwhomIDEsarethebasicdailytools,aredirectlyinterestedintheirquality,sothatopen-sourceprojectssuchasEclipseandEiffelStudiobeneÞtfromactivecommunityparticipation.Theeffectoftheseadvancedframeworksonsoftwarereliability,whilediffuse,isundeniable,astheirincreasingclevernesssupportsqualityinseveralways:Þndingbugsthroughstaticanddynamictechniques;avoidingnewbugsthroughmechanismssuchasrefactoring;generatingsomeofthecodewithoutmanualintervention;and,moregenerally,providingalevelofcomfortthatfreesprogrammersfromdistractionsandletsthem apply their best skills to the hardest issues of software construction. 6PROGRAMMING LANGUAGES 6PROGRAMMINGLANGUAGESTheevolutionofprogramminglanguagesplaysitspartinthesearchformorereliablesoftware.High-levellanguagescontributebothpositively,byprovidinghigherlevelsofexpressionthroughadvancedconstructsfreeingtheprogrammer(inthesamespiritasmodernIDEs)frommundane,repetitiveorirrelevanttasks,andnegatively,byrulingoutcertainpotentiallyunsafeconstructs and, as a result, eradicate entire classes of bugs at the source.Therealizationthatprogramminglanguageconstructscouldexertamajorinßuenceonsoftwarequalityboththroughwhattheyofferandwhattheyforbiddatesbacktostructured[22][20]which,intheearlyseventies,ledtorejectingtheasacontrolstructureinfavorofmoreexpressiveconstructsÑsequence,conditional,loop,recursion.Thenextmajorstepwasprogramming,introducingafullnewsetofabstractions,inparticularthenotionofclass,providingdecompositionbasedonobjecttypesratherthanindividualoperations,andtechniquesofinheritance and genericity.InbothcasesthebeneÞtcomeslargelyfrombeingabletoreasonoperationallyaboutsoftware.Asoftwaretextrepresentsmanypossibleexecutions,somanyinfactthatitishardtounderstandtheprogramÑandhencetogetitrightÑbythinkingintermsofwhathappensatexecutionecution.Bothstructuredandobject-orientedtechniquesmakeitpossibletolimitsuchoperationalthinkingandinsteadunderstandtheabstractpropertiesoffuturerun-time behaviors by applying the usual rules of logical reasoning.IndrawingthelistofprogramminglanguagesÕmostimportantcontributionstoquality,wemustindeedputatthetopallthemechanismsthathavetodowithstructure.Witheverlargerprogramsaddressingevermoreambitiousgoals,theproductionandmaintenanceofreliablesoftwarerequiressafeandpowerfulmodulardecompositionfacilities.Particularlynoteworthyare:¥Aspointedout,themechanism,whichprovidesageneralbasisforstable modules with a clear role in the overall architecture.¥Techniquesforinformationhiding,whichprotectmodulesagainstdetailsofothermodules,andpermitindependentevolutionofthevarious,allowingtheclassiÞcationandsystematicorganizationof, allowing the construction of type-parameterized modules. DEPENDABLE SOFTWARE AnotherbeneÞtofmodernlanguagesisstatictypingwhichrequiresprogrammerstodeclaretypesforallthevariablesandotherentitiesintheirprograms,thentakesadvantageofthisinformationtodetectpossibleinconsistenciesintheiruseandrejectprograms,atcompilationtime,untilalltypesÞt.Statictypingisparticularlyinterestinginobject-orientedlanguagessinceinheritancesupportsaßexibletypesysteminwhichtypescanbecompatibleeveniftheyarenotidentical,aslongasonedescribesaspecialization of the other.Anotherkeyadvanceisgarbagecollection,whichfreesprogrammersfromhavingtoworryaboutthedetailsofmemorymanagementandremovesanentireclassoferrorsÑsuchasattemptstoaccessapreviouslyfreedmemorycellÑwhichcanotherwisebeparticularlyhardtodetectandtocorrect,inparticularbecausetheresultingfailuresareoftenintermittentratherthandeterministic.Strictlyspeaking,garbagecollectionisapropertyofthelanguageimplementation,butitÕsthelanguagedeÞnitionthatmakesitpossible,aswithmodernobject-orientedlanguages,ornot,asinlanguagessuch as C that permit arbitrary pointer arithmetic and type conversions.Exceptionhandling,aspresentinmodernprogramminglanguages,helpsimprovesoftwarerobustnessbyallowingdeveloperstoincluderecoverycodeforrun-timefaultsthatwouldotherwisebefatal,suchasarithmeticoverßow or running out of memory.Amechanismthatisequallyfar-reachinginitsabstractionbeneÞtsistheÒclosureÓ,ÒdelegateÓorÒÒ.Suchconstructswrapoperationsinobjectsthatcanthenbepassedaroundanonymouslyacrossmodulesofasystem,makingitpossibletotreatroutinesasÞrst-classvalues.Theydrasticallysimplifycertainkindsofsoftwaresuchasnumericalapplications,GUI programming and other event-driven (or Òpublish-subscribeÓ) schemes.TheapplicationofprogramminglanguagetechniquestoimprovingsoftwarequalityislimitedbythecontinuedrelianceofsigniÞcantpartsofthesoftware industry on older languages. In particular:¥Operatingsystemsandlow-levelsystem-relatedtendtobewritteninC,whichretainsitsattractionsforsuchapplicationsinspiteofwidelyknown deÞciencies, such as the possibility of buffer overßow.¥Theembeddedandmission-criticalcommunitysometimespreferstouselow-levellanguages,includingassembly,forfearoftheriskspotentiallyTheÒVerifyingCompilerGrandChallengeÓ[38][77]isanattempttosupportthedevelopmentoftoolsthatÑevenwithsuchprogramminglanguagesÑwillguarantee,duringtheprocessofcompilingandthankstotechniquesdescribedinthefollowingsections,thereliabilityoftheprogramstheyprocess. 7STATIC VERIFICATION TECHNIQUES 7STATICVERIFICATIONTECHNIQUEStechniquesworksolelyfromtheanalysisofthesoftwaretext:unlikedynamictechniquessuchasteststheydonotrequireanyexecutiontoverifysoftware or report errors.ProofsPerhapstheprincipaldifferencebetweenmathematicsandengineeringisthatonlymathematicsallowsprovidingabsoluteguarantees.Giventheproperaxioms,IcanassertwithtotalconÞdencethattwoplustwoequalsfour.ButifIwanttodrivetoBernethebestassuranceIcangetthatmycarwillnotbreakdownisaprobability.IknowitÕshigherthanifIjustdriveittothesuburbs,andlowerthanifmygoalwerePrague,Alma-Ata,PekingorBombay;Icanmakeithigherbybuyinganew,bettercar;butitwillneverbeone.Evenwiththehighestattentiontoqualityandmaintenance,physicalproductswilloccasionally fail.Underappropriateassumptions,aprogramislikeamathematicalpropositionratherthanamaterialdevice:anygeneralpropertyoftheprogramÑstatingthatexecutionsoftheprogramwillachieveacertaingoal,orthatatleastonepossibleexecutionwillÑiseithertrueorfalse,andwhetheritistrueornotisentirelydeterminedbythetextoftheprogram,atleastifweassumecorrectfunctioningofthehardwareandofothersoftwareelementsneededtocarryoutprogramexecution(compiler,run-timesystem,operatingsystem).Anotherwayofexpressingthisobservationisthataprogramminglanguageissimilartoamathematicaltheory,inwhichcertainpropositionsaretrue and others false, as determined by the axioms and inference rules.Inprinciple,then,itshouldbepossibletoproveordisprovepropertiesofprograms,inparticularcorrectness,robustnessandsecurityproperties,usingthesamerigoroustechniquesasintheproofsofanymathematicaltheorem.This assumes overcoming a number of technical difÞculties:¥ProgramminglanguagesaregenerallydeÞnedasmathematicaltheoriesbutthroughnatural-languagedocumentspossessingavaryingdegreeofprecision.Tomakeformalreasoningpossiblerequiresdescribingtheminmathematicalform;thisisknownasprovidingamathematicalsemantics(orÒformalsemanticsÓ)toaprogramminglanguageandisahugetask,especiallywhenitcomestomodelingadvancedmechanismssuchasexceptionhandlingandconcurrency,aswellasthedetailsofcomputerarithmeticsincethecomputerÕsviewofintegers and reals strays from their standard mathematical properties. DEPENDABLE SOFTWARE ¥ThetheoremstobeprovedinvolvespeciÞcpropertiesofprograms,suchasthevalueofacertainvariablenotexceedingacertainthresholdatacertainstateoftheexecution.Anyproofprocessrequirestheabilitytoexpresssuchproperties;thismeansextendingtheprogramminglanguagewithboolean-valuedexpressions,called.CommonlanguagesotherthanEiffeldonotincludeanassertionmechanism;thismeansthatprogrammerswillhavetoresorttospecialextensionssuchasJMLforJavaa(seealsoSpec#,anextensionoftheC#languagelanguage)andannotateprogramswiththeappropriateassertions.SometoolssuchasDaikonhelpinthisprocessbyextractingtentativeassertionsfromthethe.¥InpracticethesoftwareÕsactualoperationdepends,asnoted,onthoseofasupportinghardwareandsoftwareenvironment;proofsofthesoftwaremust be complemented by guarantees about that environment.¥Notallpropertieslendthemselvestoeasyenunciation.Inparticular,Ònon-functionalÓpropertiessuchasperformance(responsetime,¥Moregenerally,aproofisonlyasusefulastheprogrampropertiesbeingproven.Whatisbeingprovedisnottheperfectionoftheprograminanyabsolutesense,norevenitsquality,butonlythatitsatisÞestheassertionsstated.Itisneverpossibletoknowthatpropertiesofinteresthavebeenincluded.Thisisnotjustatheoreticalproblem:securityattacksoftentakeadvantageofauxiliaryaspectsoftheprogramÕsbehavior,whichitsdesign and veriÞcation did not take into account.¥Evenifthelanguage,thecontextandthepropertiesofinterestarefullyspeciÞedsemanticallyandthepropertiesrelevant,theproofprocessremainsachallenge.Itcannotinanycasebeperformedmanually,sinceeventheproofofafewpropertiesofamoderatelysizedprogramsquicklyreachesintothethousandsofproofsteps.Fullyautomatedproofsare,ontheotherhand,generallynotpossible.Despiteconsiderableadvancesincomputer-assistedprooftechnology(forprogramsaswellasotherapplications)signiÞcantproofsstillrequireconsiderableuserinteractionand expert knowledge.Ofcoursetheeffortmaywellbeworthwhile,especiallyintwocases:life-criticalsystemsintransportationanddefensetowhich,indeed,muchproofworkhasbeendirected;andreusablecomponents,forwhichtheeffortisjustiÞedÑasexplainedinthediscussionofTrustedComponentsaboveÑbythe scaling-up effect of reuse. 7STATIC VERIFICATION TECHNIQUES Herearesomeofthebasicideasabouthowproofswork.Atypicalprogram element to prove would be, in Eiffel notationThishasaprogrambody,theclause,andtwoassertions,aÒpreconditionÓintroducedbyrequireandaÒpostconditionÓintroducedbyensureconsistingoftwosubclausesimplicitlyconnectedbyan.Assertionsareessentiallybooleanexpressionsofthelanguagewiththepossibility,inapostcondition,ofusingthenotationtorefertovaluesonentry:heretheÞrstsubclauseofthepostconditionstatesthatthevalueofwillhavebeen decreased by one after execution of theProgramproofsdealwithsuchannotatedprograms,alsocalledcontractedprograms(seesection below).Theannotationsremindusthatproofsandothersoftwarequalityassurancetechniquecannevergiveusabsoluteguaranteesofquality:wecanneversaythataprogramisÒcorrectÓ,onlyassessitÑwhetherthroughrigoroustechniqueslikeproofsorusingmorepartialonessuchasthosereviewednextÑrelativelytoexplicitlystatedproperties, expressed here through assertions integrated in the program text.FromaprogrammerÕsviewpointtheaboveextractissimplythetextofaroutinetobeexecuted,withsomeextraannotations,thepreconditionandpostcondition,expressingpropertiestobesatisÞedbeforeandafter.Butforproofpurposesthistextisatheorem,assertingthatwheneverthebody(theclausewithitsassignmentinstruction)isexecutedwiththepreconditionsatisÞed it will terminate in such a way that the postcondition is satisÞed.ThistheoremappearstoholdtriviallybutÑevenbeforeaddressingtheconcernnotedabovethatcomputerintegersarenotquitethesameasmathematicalintegersÑprovingitrequiresthepropermathematicalframework.Thebasicruleofaxiomaticsemantics(orÒHoaresemanticsÓsemanticsÓ)coveringsuchcasesistheassignmentaxiom,whichforanyvariableexpression states that the following holdsdecrementrequireensure DEPENDABLE SOFTWARE isanassertionwhichmaydependon;thenisthesameassertionwitheverymentionofreplacedby,exceptforoccurrencesofThisverygeneralaxiomcapturesthepropertiesofassignment(intheabsenceofsideeffectintheevaluationof);itsremarkablefeatureisthatitisapplicableevenifthesourceexpressioncontainsoccurrencesofthetargetvariable, as in the example (whereWemayindeedapplytheaxiomtoprovetheexampleÕscorrectness.Let,correspondingtotheÞrstsubclauseofthepostcondition,and�=0.Applyingtheruleto,we;thisgives,whichtriviallyholds.Applyingnowthesametransformationsto,weget�Ð1=0,whichisequivalenttotheprecondition.Thisprovesthecorrectnessofourlittleassertion-equipped example.Fromtherethetheorymovestomorecomplexconstructions.Aninference rule states that if you have proved(notethepostconditionoftheÞrstpartmatchingthepreconditionoftheandsoonformoreinstructions.Aruleinthesamestyleenablesyoutodeducepropertiesoffrompropertiesof.Moreadvanced is the case of loops: to prove the properties ofrequireensurerequireensurerequireensurerequireensurefrom 7STATIC VERIFICATION TECHNIQUES youneed,inthisgeneralapproach,tointroduceanewassertioncalledtheinvariantandanintegerexpressioncalledtheloopvariant.Theinvariantisaweakenedformofthedesiredpostcondition,whichservesasapproximationoftheÞnalgoal;forexampleifthegoalistocomputethemaximumofasetofvalues,theinvariantwillbeÒisthemaximumofthevaluesprocessedso farÓ. The advantage of the invariant is that it is possible both to:¥Ensuretheinvariantthroughinitialization(thefromclauseintheabovenotation);intheexampletheinvariantwillbetriviallytrueifwestartwithjust one value and set to that value.¥Preservetheinvariantthroughoneiterationoftheloopbody(theclause);intheexampleitsufÞcestoextendthesetofprocessedvaluesbyand executeIfindeedalooppossessessuchaninvariantanditsexecutionterminates,thenonexittheinvariantwillstillhold(sinceitwasensuredbytheinitializationandpreservedbyalltheloopiterations),togetherwiththecondition.Thecombinationofthesetwoassertionsgivesthepostconditionoftheloop.Seentheotherwayaround,ifwestartedfromadesiredpostconditionandweakenedittogetaninvariant,wewillobtainacorrectprogram.Intheexample,iftheexitconditionstatesthatwehaveprocessedallvaluesofinterest,combiningthispropertywiththeinvariantÒisthemaximumofthevaluesprocessed so farÓ tells us that is the maximum of all values.Suchreasoningisonlyinterestingiftheloopexecutionactuallyterminates;thisiswheretheloopvariantcomesin.Itisanintegerexpressionwhichmusthaveanon-negativevalueaftertheanddecrease,whileremainingnon-negative,whenevertheisexecutedwiththeconditionnotsatisÞed.Theexistenceofsuchanexpressionisenoughtoguaranteeterminationsinceanon-negativeintegervaluecannotdecreaseforever.Intheexampleavariantisisthetotalnumberofvaluesbeingconsideredforthemaximum(theproofassumesaÞniteset)andnumber of values processed.Axiomsandinferencerulessimilarlyexistforotherconstructsofprogramminglanguages,becoming,asnoted,moreintricateasonemovesonto more advanced mechanisms. DEPENDABLE SOFTWARE Forconcurrent,reactiveandreal-timesystems,booleanassertionsofthekindillustratedabovemaynotbesufÞcient;itisoftenconvenienttorelyonpropertiesoftemporallogiclogic,whichgivenasetofsuccessiveobservationsofaprogramÕsexecution,canexpress,forabooleanpropertyforever: from now on, will always hold.eventually:atsomepointinthefuture(whereÒfutureÓincludesnow),willholdatsomepointinthefuture,anduntilthenwillhold.Regardlessofthekindofprogramsandpropertiesbeingtargeted,therearetwoapproachestoproducingprogramproofs.Themethodtakesprogramsastheyexist,thenafterequippingthemwithassertions,eithermanuallyorwithsomeautomatedaidasnotedabove,attemptstheproof.Theconstructive[24][2][68]integratestheproofprocessinthesoftwareconstructionprocess,oftenusingsuccessivereÞnementstogofromspeciÞcationtoimplementationthroughasequenceoftransformations,eachprovedtopreservecorrectness,andintegratingmorepracticalconstraintsatevery step.Prooftechnologyhashadsomenotablesuccesses,includinginindustrialsystems(andinhardwaredesign),butuntilrecentlyhasremainedbeyondthereach of most software projects.Ifhopingforaproofcoveringallthecorrectness,reliabilityandsecuritypropertiesofpotentialinterestisoftentooambitious,theproblembecomesmoreapproachableifwesettleforasubsetofthesepropertiesÑasubsetthatmaybeverypartialbutveryinteresting.ForexamplebeingabletodeterminethatnobufferoverßowcaneverariseinacertainprogramÑinotherwords,toprovideaÞrmguarantee,throughanalysisoftheprogramtext,thateveryindexusedatruntimetoaccessaniteminanarrayoracharacterinastringwillbewithinthedeÞnedboundsÑisofgreatpracticalvaluesincethisrulesStaticanalysisisthetool-supportedanalysisofsoftwaretextsforthepurposeofassessingspeciÞcqualityproperties.BeingÒstaticÓ,itrequiresnoexecutionandhencecaninprinciplebeappliedtosoftwareproductsotherthancode.Proofsareaspecialcase,themostfar-reaching,butotherstaticanalysis techniques are available. 7STATIC VERIFICATION TECHNIQUES Attheotherextreme,awell-establishedformofelementarystaticanalysisistypechecking,whichbeneÞtsprogramswritteninastaticallytypedprogramminglanguage.Typechecking,usuallyperformedbythecompilerratherthanbyaseparatetool,ascertainsthetypeconsistencyofassignments,routinecallsandexpressions,andrejectsanyprogramthatcontainsatypeincompatibility.Moregenerally,techniquesusuallycharacterizedasstaticanalysisliesomewherebetweensuchbasiccompilerchecksandfullprogramproofs.Violations that can typically be detected by static analysis include:¥Variablesthat,onsomecontrolpaths,wouldbeaccessedbeforebeing¥Improper array and string access (buffer overßow).¥Memoryproperties:attempttoaccessafreedlocation,doublefreeing,¥Pointermanagement(againinlow-levellanguagessuchasC):attemptsto follow void or otherwise invalid pointers.¥Concurrency control: deadlocks, data races.¥Miscellaneous:certaincasesofarithmeticoverßoworunderßow,StaticanalysistoolssuchasPREÞxPREÞxhavebeenregularlyappliedforseveralyearstonewversionsoftheWindowscodebaseandhaveavoidedmany potential errors.Oneoftheissuesofstaticanalysisistheoccurrenceoffalsealarmsinconsistencyreportsthat,oninspection,donotrevealanyactualerror.Thiswastheweakpointofolderstaticanalyzers,suchasthewidelyknownwhichcomplementsthetypecheckingofCcompilers:foralargeprogramtheycaneasilyswamptheirusersunderthousandofmessages,mostofthemspurious,butrequiringamanualwalkthroughtosortoutthegoodfromthebad.(Inthesearchforerrors,ofcourse,theÒgoodÓiswhatotherwisewouldbeconsideredthebad:evidenceofwrongdoing.)Progressinstaticanalysishasbeen successful in considerably reducing the occurrence of false alarms.Thepopularityofstaticanalysisisgrowing;thecurrenttrendistoextendthereachofstaticanalysistoolseverfurthertowardsprogramproofs.Twoexamples are: DEPENDABLE SOFTWARE ¥TechniquesofabstractinterpretationetationwiththesupportingASTRƒEASTRƒE,whichhasbeenusedtoprovetheabsenceofrun-timeerrorsintheprimaryßightcontrolsoftware,writteninC,fortheAirbusA340ßy-¥ESC-Javaaand,morerecently,theBoogieanalyzeranalyzermakeprogramprovinglessobtrusivebyincrementallyextendingthekindofdiagnosticswithwhichprogrammersarefamiliar,forexampletypeerrors,tomoreadvancedcheckssuchastheimpossibilitytoguaranteethataninvariantis preserved.modelcheckingapproachtoveriÞcation[36][17][3]isstatic,likeproofsandstaticanalysis,butprovidesanaturallinktothedynamictechniques(testing)studiedbelow.Theinherentlimitationoftestsisthattheycanneverbeexhaustive;foranysigniÞcantsystemÑinfact,evenfortoyexamplesÑthenumberofpossiblecasesskyrocketsintothecombinatorialstratosphere,wheretheordersofmagnitudeinvitelyricalcomparisonswiththenumberofparticles in the universe.Theusefulmeasureisthenumberofpossibleofaprogram.Thenotionofstatewasimplicitintheearlierdiscussionofassertions.Astateissimplyasnapshotoftheprogramexecution,ascouldbeobserved,ifwestopthatexecution,bylookingupthecontentsoftheprogramÕsmemory,ormorerealisticallybyusingthedebuggertoexaminethevaluesoftheprogramÕsvariables.IndeeditisthecombinationofallthevariablesÕvaluesthatdeterminesthestate.Withevery64-bitintegervariablepotentiallyhaving2values, it is not surprising that the estimates quickly go galactic.Modelcheckingattemptsexhaustiveanalysisofprogramstatesanywaybyperformingpredicateabstraction.Theideaistosimplifytheprogrambyreplacingallexpressionsbybooleanexpressions(predicates),withonlytwopossiblevalues,sothatthesizeofthestatespacedecreasesdramatically;itwillstillbelarge,butthepowerofmoderncomputers,togetherwithsmartalgorithms,canmakeitsexplorationtractable.ThentodeterminethatadesiredpropertyholdsÑforexample,asecuritypropertysuchastheabsenceofbufferoverßows,oratimingpropertysuchastheabsenceofdeadlockÑitsufÞcestoevaluatethecorrespondingassertioninalloftheabstractstatesand,ifaviolationofthatassertion(orcounter-example)isfound,tocheckthatit 7STATIC VERIFICATION TECHNIQUES Forexample,predicateabstractionwillreduceaconditionalinstruction,whereisaboolean.Thisimmediatelycutsdownthenumberofcasesfrom2to2.Thedrawbackisthattheresultingprogramisonlyacaricatureoftheoriginal;itlosestherelationoftootherpredicatesinvolving.Butithasaninterestingproperty:iftheoriginalviolatestheassertion,thentheabstractedversionalsodoes.Sothenexttaskistolookforanysuchviolationintheabstractedversion.Thismaybepossiblethroughexhaustiveexaminationofitsreducedstatespace,andifsoisguaranteedÞndanyviolationintheoriginalprogram,butevensoisnottheendofthestory,sincethereversepropositiondoesnothold:acounter-exampleintheabstractedprogramdoesnotnecessarilysignalacounter-exampleintheoriginal.ItcouldresultfromtheartiÞcialmergingofseveralcases,forexampleifitoccursonapathÑimpossibleinanexecutionoftheoriginalprogramÑobtainedbyselectingbothastruewhereistheabstractionof.Thenexamining the state space of the abstracted program will either:¥NotÞndanyviolations,inwhichcaseitprovestherewasnoneinthe¥Reportviolations,eachofwhichmightbeanerrorintheoriginalorsimply a false alarm generated by the abstraction process.Sotheremainingtask,ifcounter-exampleshavebeenfound,istoascertainwhethertheyariseintheoriginal.ThisinvolvesdeÞningthepathpredicatethatleadstoeachcounter-example,expressingitintermsoftheoriginalprogramvariables(thatistosay,removingthepredicateabstraction,giving,intheexample,)anddeterminingifanycombinationofvaluesfortheprogramvariablescansatisfythepredicate:ifsuchacombination,orvariableassignment,exists,thenthecounter-exampleisarealone; if not, as in the case given, it is spurious.ThisproblemofpredicatesatisÞabilityiscomputationallyhard;ÞndingefÞcient algorithms is one of the central areas of research in model checking.Thefocusoncounter-examplesgivesmodelcheckingapracticaladvantageovertraditionalprooftechniques.Unlessasoftwareelementwasbuiltwithverificationinmind(throughaÒconstructivemethodÓasdefinedabove),thefirstattempttoverifyitwilloftenfail.Withproofs,thisfailuredoesnÕttellusthesourceoftheproblemÑandcouldactuallysignalalimitationoftheproofprocedureratherthananerrorintheprogram.Withmodelchecking,you get a counter-example which directly shows whatÕs wrong.Modelcheckinghascapturedconsiderableattentioninrecentyears,Þrstinhardwaredesignandtheninreactiveandreal-timesystems,forwhichtheassertions of interest are often expressed in temporal logic. DEPENDABLE SOFTWARE 8DESIGNBYCONTRACTThegoalofdevelopingsoftwaretosupportfullproofsofcorrectnesspropertiesis,asnoted,desirablebutstillunrealisticformostprojects.Evenashortbrushwithprogramprovingmethodssuggests,however,thatmorerigorcanbehighlybeneÞcialtosoftwarequality.ThetechniquesofDesignbyContractgointhisdirectionanddeliverpartofthecorrespondingbeneÞtswithout requiring the full formality of proof-directed development.The discussion of proofs introduced Eiffel notations such asrequireensureassociatedwithindividualroutines.Theyareexamplesofwhichspecifyabstractsemanticpropertiesofprogramconstructs.Contracts¥Individualroutines:precondition,statingtheconditionunderwhicharoutineisapplicable;,statingwhatconditionitwill¥Inobject-orientedprogramming,classes:classinvariant,statingconsistencyconditionsthatmustholdwheneveranobjectisinastablestate.Forexample,theinvariantforaÒparagraphÓclassinatextprocessingsystemmaystatethatthetotallengthoflettersandspacesisequaltotheparagraphwidth.Everyroutinethatcanmodifyaninstanceoftheclassmayassumetheclassinvariantonentry(inadditiontoitsprecondition)andmustrestoreitonexit(inadditiontoensuringitspostcondition).¥Loops:invariant and (integer)variant as discussed above.¥Individual instructions: ÒassertÓ or ÒcheckÓ constructs.ThedisciplineofDesignbyContract[53][57][67]givesacentralroletothesemechanismsinsoftwaredevelopment.ItviewstheoverallprocessofbuildingasystemasdeÞningamultitudeofrelationshipsbetweenÒclientÓandÒsupplierÓmodules,eachspeciÞedthroughacontractinthesamemannerasrelationships between companies in the commercial world.ThebeneÞtsofsuchamethod,ifcarriedsystematically,extendthroughoutthelifecycle,supportingthegoalofdiscussedearlier:¥Contractscanbeusedtoexpressrequirementsinapreciseyetunderstandableway,preferabletopureÒbubblesandarrowsÓnotations, although of course they can be displayed graphically too. 8DESIGN BY CONTRACT ¥Themethodisalsoapowerfulguidetohelpingdeveloperstounderstandbettertheprecisereasonandcontextforeverymoduletheyproduce,andasaconsequencetogetthemoduleright.¥Contractsserveasamechanism:theÒcontractviewÓofaclass,whichdiscardsimplementation-dependentelementsbutretainsexternallyrelevantelementsandinparticularpreconditions,postconditionsandclassinvariants,oftenprovidesjusttherightformofdocumentationforsoftwareelements,especiallyreusablecomponents:preciseenoughthankstothecontracts;abstractenoughthankstotheremovalofimplementationproperties;extractedfromtheprogramtext,andhencehavingabetterchanceofbeinguptodate(atleastonemajorsoftwaredisasterwastracedtracedtoasoftwareelementwhosespeciÞcationhadchanged,unbeknownsttothedeveloperswhoreusedit);cheaptoproduce,sincethisformofdocumentationcanbegeneratedbytoolsfromthesourcetext,ratherthanwrittenseparately;andmulti-purpose,sincetheoutputcanbetunedtoanyappropriateformatsuchasHTML.EiffelenvironmentssuchasEiffelStudioproducesuchviewsws, which serve as the basic form of software documentation.¥Contractsarealsousefulformanagerstounderstandthesoftwareatahigh level of abstraction, and as a tool to control¥Inobject-orientedprogramming,contractsprovideaframeworkfortheproperuseof,byallowingdeveloperstospecifythesemanticframeworkwithinwhichroutinesmaybefurtherreÞnedindescendantclasses.Thisisconnectedwiththeprecedingcommentaboutmanagement,sinceaconsequenceistoallowamanagertocheckthatreÞnementstoandesignareconsistentwithitsoriginalintent,whichmayhavebeendeÞnedbythetopdesignersintheorganizationandexpressed¥Mostvisibly,contractsareadebuggingmechanism.Sinceanexecutionthatviolatesanassertionalwayssignalsabug,turningoncontractmonitoringduringdevelopmentprovidesaremarkabletechniqueforidentifyingbugs.Thisideaispursuedfurtherbysomeofthe tools cited in the discussion of testing below.DesignbyContractmechanismsareintegratedinthedesignoftheEiffel[52][28]andakeypartofthepracticeoftheassociatedmethod.Dozensofcontractextensionshavebeenproposedforotherprogramminglanguages(aswellasUMLUML),includingmanydesignssuchasJMLJMLfor Java and the Spec# extension of C# DEPENDABLE SOFTWARE 9TESTINGTesting[70][8]isthemostwidelyusedformofprogramveriÞcation,andstillformanyteamsessentiallytheonlyone.Inacademiccirclestestinghaslongsufferedfromafamouscommentcommentthat(becauseoftheastronomicalnumberofpossiblestates)Òtestingcanonlyshowthepresenceofbugs,butnevertoshowtheirabsenceÓ.InretrospectitÕshardtoÞndarationalexplanationforwhythiscommenteverdetractedanyonefromtheimportanceoftests,sinceitinnowaydisprovestheusefulnessoftesting:Þndingbugsisaveryimportanttaskofsoftwaredevelopment.AllitindicatesisthatweshouldunderstandthatÞndingbugsisindeedthesolepurposeoftesting,andnotdeludeourselvesthattestresultsdirectlyreßectthelevelofqualityofaproduct under development.Successfultestingreliesonatestplan:astrategy,expressedinadocument,describing choices for the tasks of the testing process. These tasksinclude:¥Determining which parts to test.¥Finding the appropriate input values to exercise.¥Determiningtheexpectedpropertiesoftheresults(knownasoraclesInputvaluesandtheassociatedoraclestogethermakeuptestcases,the¥Instrumentingthesoftwaretorunthetests(ratherthanperformitsnormaloperation,orinadditiontoit);thisisknownasbuildingatestharnesswhichmayinvolvetestdriverstosolicitspeciÞcpartstobetested,andtostandforpartsofthesystemthatwillnotbetestedbutneeda¥Running the software on the selected inputs.¥Comparing the outputs and behavior to the oracles.¥Recordingthetestdata(testcases,oracles,outputs)forfuturere-testingofthesystem,inparticularregressiontesting,thetaskofverifyingthatpreviously corrected errors have not reappeared.Inadditiontherewillbeaphaseofcorrectionoftheerrorsuncoveredbythetest,butinlinewiththeaboveobservationsthisisnotpartoftestinginthe 9TESTING Onemayclassifytestswithrespecttotheir(thiswasusedintheearlierdescription of the V model of the lifecycle): covers a module of the software.Integration test covers a complete cluster or subsystem. covers the complete delivery.UserAcceptanceTestinginvolvestheparticipationoftherecipientsofthesystem(inadditiontothedevelopers,responsiblefortheprecedingvariants) to determine whether they are satisÞed with the delivery.BusinessConÞdenceTestingisfurthertestingwiththeusers,inconditions as close as possible to the real operating environment.testing:whetherthesystemfulÞllsthefunctionsdeÞnedinthespeciÞcation.PerformanceStresstesting:itsbehaviorunderextremeconditions,suchasheavyuserload.Yetanotherdimensionis:testingcanbefault-directedtoÞnddeÞcienciesbutalso(despitetheabovewarnings),conformance-directedestimatesatisfactionofdesiredproperties,oracceptancetestingforuserstodecidewhethertoapprovetheproduct.Regressiontesting,asnoted,re-runstestscorrespondingtopreviouslyidentiÞederrors;surprisinglytothelayman,errorshaveaknackforsurgingbackintothesoftware,sometimesrepeatedly,long after they were thought corrected.Thetestingtechnique,inparticulartheconstructionoftestsuites,canbe:Black-box: based on knowledge of the systemÕs speciÞcation only.:basedonknowledgeofthecode,whichmakesitpossibleforexample to try to exercise as much of that code as possible.Observingthestateoftheartinsoftwaretestingsuggeststhatfourissuesarecritical:managingthetestprocess;estimatingthequalityoftestsuites;devising oracles; and Ñ the toughest Ñ generating test cases automatically. DEPENDABLE SOFTWARE Managing the testing processTestmanagementhasbeenmadeeasierthroughtheappearanceofframeworkssuchasJUnitJUnitandGoboEiffelTestestwhichrecordtestharnessestoallowrunningthetestsautomatically.Thisremovesaconsiderablepart of the burden of testing and is important for regression testing.Anexampleofaframeworkforregressiontestingofacompiler,incorporatingeverybugeverfoundsince1991,isEiffelWeaseleasel.Suchautomatedtestingrequireasolidmulti-processinfrastructure,toensureforexamplethatifatestruncausesacrashthetestingprocessdoesnÕtalsocrashbut records the problem and moves on to the next test.Beingabletoestimatethequalityofatestsuiteisessentialinparticulartoknowwhentostoptesting.Thetechniquesaredifferentforwhite-boxandblack-boxtesting.Withwhite-boxtestingitispossibletodeÞnevariouslevelsofcoverageeachassumingtheprecedingones:coverage,ensuringthatthroughtheexecutionoftheselectedtestcaseseveryinstructionisexecutedatleastbranchcoverage,whereeverybooleanconditiontestsatleastoncetotrueandoncetofalse;coverage,wherethisisalsothecaseforbooleansub-expressions;coverage,forwhicheverypathhasbeentaken;coverage, where each loop body has been executed at leastAnothertechniqueformeasuringtestsuitequalityinwhite-boxapproachesismutationtestingtesting.Startingwithaprogramthatpassesitstestsuite,thisconsistsofmakingmodiÞcationsÑsimilar,ifpossible,tothekindoferrorsthatprogrammerswouldmakeÑtotheprogram,andrunningthetestsagain.IfaÒmutantÓprogramstillpassesthetests,thisindicates(onceyouhavemadesurethemutantisnottotheoriginal,inotherwords,thechangesaremeaningful)thatthetestswerenotsufÞcient.Mutationtestingisanactiveareaofresearchresearch;oneofthechallengesistouseappropriatemutation operators, to ensure diversity of the mutants.Withblack-boxtestingtheprevioustechniquesarenotavailablesincetheyassumeaccesstothesourcecodetosetupthetestplan.ItispossibletodeÞnenotionsofspeciÞcationcoveragetoestimatewhetherthetestshaveexercisedthevariouscaseslistedinthespeciÞcation;ifcontractsarepresent,thiswillmeananalyzingthevariouscaseslistedinthepreconditions.Partitionartitionisthegeneralnamefortechniques(black-orwhite-box)thatsplittheinputdomainintorepresentativesubsets,withtheimplicationthatanytestsuite must cover all the subsets. 9TESTING Anoracle,allowinginterpretationoftestingresults,providesadecisioncriterionforacceptingorrejectingtheresultofatest.Thepreparationoforaclescanbeasmuchworkastherestofthetestplan.Thebestsolutionthatcanberecommendedistorelyoncontracts:anyfunctionalpropertyofasoftwaresystem(withthepossibleexceptionofsomeuser-interfacepropertiesforwhichhumanassessmentmayberequired)canbeexpressedasaroutinepostconditionoraclassinvariant.Theseassertionscanbeincludedinthetestharness,butitisofcoursebest,asnotedinthediscussionofDesignbyContract,tomakethemanintegralpartofthesoftwaretobetestedasitisdeveloped;theywillthenprovidetheotherbeneÞtscited,suchasaidtodesignandbuilt-indocumentation, and will facilitate regression testing.Test case generationThelastofthefourcriticalissueslisted,testcasegeneration,isprobablythegenerationinparticular.EventhoughwecanÕtevergetclosetoexhaustivetesting,wewantthetestprocesstocoverasmanycasesaspossible,andespeciallytomakesuretheyarerepresentativeofthevariouspotentialprogramexecutionsÑascanbeassessedinwhite-boxtestingbycoveragemeasuresandmutation,butneedstobesoughtinanyformoftesting.Foranyrealisticprogram,manuallypreparedtestswillnevercoverenoughcases;inaddition,theyaretedioustoprepare.Hencetheworkonautomatictestcasegeneration,whichtriestoproduceasmanyrepresentativetestcasesaspossible,typicallyworkingfromspeciÞcationsonly(black-box).TwotoolsinthisareaareKoratforJMLJMLandAutoTestforEiffelfel(whichdrawsontheadvantagethatÑcontractsbeingnativetoEiffelÑexistingEiffelsoftwareistypicallyequippedwithlargenumbersofassertions,sothatAutoTestcanberunonsoftwareasis,andindeedhasalreadyuncovereda signiÞcant number of problems in existing programs and libraries).Manualtests,whichbenefitfromhumaninsight,remainindispensable.Thetwokindsarecomplementary:manualtestsaregoodatdepth,automaticallygeneratedtestsatbreadth.Inparticular,anyrunthateveruncoveredabug,whetherthroughmanualorautomatictechniques,shouldbecomepartoftheregressiontestsuite.AutoTestintegratesmanualtestsandregressiontestswithinthe automatic test case generation and execution frameworkork.Automatictestcasegenerationneedsastrategyforselectinginputs.Contrarytointuition,randomandom,whichselectstestdatarandomlyfromtheinputdomain,canbeaneffectivestrategyiftunedtoensureareasonablyevendistributionoverthatdomain,apolicyknownasrandomtestingtestingwhichhassofarbeenappliedtointegersandothersimplevalues(forwhichaclearnotionofdistanceexists,sothatÒevendistributionÓisimmediatelymeaningful).Recentworkorkextendstheideatoobject- DEPENDABLE SOFTWARE 10CONCLUSIONThissurveyhastakenabroadsweepacrossmanytechniquesthatallhavesomethingtocontributetotheaimofsoftwarereliability.Whileithasstayedawayfromthegloomypictureofthestateoftheindustrywhichseemstobederigueurindiscussionsofthistopic,andisnotjustiÞedgiventheconsiderableamountofquality-enhancingideas,techniquesandtoolsthatareavailabletodayandtheconsiderableamountofgoodworkcurrentlyinprogress,itcannotfailtonoteasaconclusionthattheindustrycoulddomuchmore to take advantage of all these efforts and results.Thereisnotenoughofareliabilitycultureinthesoftwareworld;toooften,theorderofconcernsiscost,thendeadlines,thenquality.ItistimetoAcknowledgmentsThematerialinthischapterderivesinpartfromtheslidesforanETHindustrycourseonTestingandSoftwareQualityAssurancepreparedwiththehelpofIlincaCiupa,AndreasLeitnerandBerndSchoeller.ThediscussionofCMMIbeneÞtedfromtheworkofPeterKolbinthepreparationofanotherETHcourse,ÒSoftwareEngineeringforOutsourcedandOffshoredDevelopmentÓ.Bernd Schoeller and Ilinca Ciupa provided important comments on the draft.ÒDesign by ContractÓ is a trademark of Eiffel Software.ThecontextforthissurveywasprovidedbytheHaslerFoundationÕsgrantforourSCOOPworkintheDICSproject.Weareverygratefulfortheopportunitiesthatthegrantandtheprojecthaveprovided,inparticularfortheexperience gained in the two DICS workshops in 2004 and 2005.: All URLs listed were active in April 2006.[1]AlgirdasAvizienis,Jean-ClaudeLaprieandBrianRandell:ConceptsofDependability,inProceedingsofThirdInformationSurvivability,October2000,pages7-12,availableamongotherplacesat .ist.psu.edu/article/a [2]RalphBack:ACalculusofReÞnementsforProgramDerivations,in,vol.25,1988,pages593-624,availableat i/publications/ public/1988/A CalculusOfRef inementsF orProgramDeri 10REFERENCES [3]ThomasBallandSriramK.Rajamani:AutomaticallyValidatingTemporalSafetyPropertiesofInterfaces,inSPIN2001,ProceedingsofWorkshoponModelCheckingofSoftware,LectureNotesinComputerScience2057,Springer-Verlag, May 2001, pages 103-122, available at [4]MikeBarnett,RobertDeLine,ManuelFŠhndrich,K.RustanM.Leino,WolframSchulte:VeriÞcationofobject-orientedprogramswithinvariants,inJournalofObjectTechnology,vol.3,no.6,Specialissue:ECOOP2003workshoponFormalTechniquesforJava-likePrograms,June2004,pages27-56, available at [5]MikeBarnett,K.RustanM.LeinoandWolframSchulte:TheSpec#ProgrammingSystem:AnOverview,inCASSIS2004:ConstructionandAnalysisofSafe,SecureInteroperableSmartdevices,LectureNotesinComputerScience3362,Springer-Verlag,2004,availableat ;seealsootherSpec# [6]KentBeckandCynthiaAndres:ExtremeProgrammingExplained:Embrace Change edition, Addison-Wesley, 2004.[7]ƒricBezault:GoboEiffelTest,onlinedocumentationat .gobosoft.com/eif fel/gobo/getest/inde [8]RobertBinder:TestingObject-OrientedSystems:Models,Patterns,andTools, Addison-Wesley, 1999.[9]BrunoBlanchet,PatrickCousot,RadhiaCousot,JŽr™meFeret,LaurentMauborgne,AntoineMinŽ,DavidMonniauxandXavierRival:ASTRƒE:AStaticAnalyzerforLargeSafety-CriticalSoftware,inAppliedDeductiveVeriÞcation,DagstuhlSeminar3451,November2003,availableat .di.ens.fr/~cousot/COUSO .Seealso [10]BarryW.Boehm:SoftwareEngineeringEconomics,PrenticeHall,1981.[11]BarryW.Boehm:ASpiralModelofSoftwareDevelopmentand, in Computer (IEEE), vol. 21, no. 5, May 1988, pages 61-72.[12]BarryW.Boehmetal.:SoftwareCostEstimationwithCOCOMOII[13]ChandrasekharBoyapati,SarfrazKhurshidandDarkoMarinov:Korat:AutomatedTestingBasedonJavaPredicates,inProceedingsofthe2002InternationalSymposiumonSoftwareTestingandAnalysis(ISSTA),Rome,July 22--24, 2002, available at yurl.com/qwwd3. DEPENDABLE SOFTWARE [14]T.Y.Chen,H.LeungandI.K.Mak:Adaptiverandomtesting,ininScience-ASIAN2004:Higher-LevelDecisionMaking,9thAsianComputingScienceConference,ed.MichaelJ.Maher,LectureNotesinComputerScience3321,Springer-Verlag,2004,availableat [15]IlincaCiupaandAndreasLeitner:AutomatedTestingBasedonDesignbyContract,inProceedingsofNet.ObjectsDays2005,6thAnnualConferenceonObject-OrientedandInternet-BasedTechnologies,ConceptsandApplicationsforaNetworkedWorld,2005,pages545-557,availableat .SeealsoAutoTestpageat [16]IlincaCiupa,AndreasLeitner,ManuelOriolandBertrandMeyer:DistanceanditsApplicationtoAdaptiveRandomtestingofObject-OrientedPrograms, submitted for publication, 2006, available at yer/ [17]EdmundM.ClarkeJr.,OrnaGrumbergandDoronA.Peled:Checking[18]PatrickCousot:VeriÞcationbyAbstractInterpretation,inSymposiumonVeriÞcationTheory&PracticeHonoringZoharMannaÕs64th,ed.NachumDershowitz,LectureNotesinComputerScience2772,Springer-Verlag, 2003, pages 243-268.[19]MichaelCusumanoandRichardSelby:MicrosoftSecrets,TheFree[20]Ole-JohanDahl,EdsgerW.DijkstraandC.A.R.Hoare:StructuredProgramming[21]DavidL.Detlefs,K.RustanM.Leino,GregNelson,andJamesB.Saxe:ExtendedStaticChecking,ResearchReport159,CompaqSystemsResearchCenter, December 1998, available at atek eeper .research.compaq.com/ [22]EdsgerW.Dijkstra:GoToStatementConsideredHarmful,inCommunicationsoftheACM,Vol.11,No.3,March1968,pages147-148,available at .acm.or [23]EdsgerW.Dijkstra:NotesonStructuredProgramming,inn;originaltypescriptavailableat .cs.ute xas.edu/users/EWD/e [24] Edsger W. Dijkstra:A Discipline of Programming[25] Brian J. Dreger:Function Point Analysis 10REFERENCES [26]PaulDubois,MarkHoward,BertrandMeyer,MichaelSchweitzerandEmmanuelStapf:FromCallstoAgents,inJournalofObject-OrientedProgramming(JOOP),vol.12,no.6,September1999,availableat yer/publications/joop/agent.pdf.[27] Eclipse pages at .eclipse.or [28]ECMA/ISO:Eiffel:Analysis,DesignandProgrammingLanguagestandardECMA367,acceptedinApril2006asISOstandard,availableat .ecma-international.or [29] Eiffel open-source development site at felsoftw are.origo.ethz.ch/ inde x.php/Main_P [30] Eiffel Software: EiffelStudio documentation, online at [31]MichaelD.Ernst,J.Cockrell,WilliamG.GriswoldandDavidNotkin:DynamicallyDiscoveringLikelyProgramInvariantstoSupportProgram,inIEEETransactionsonSoftwareEngineering,vol.27,no.2,February 2001, pages 1-25, available at in v [32]ErichGamma,RichardHelms,RalphJohnsonandJohnVlissides:Design Patterns, Addison-Wesley, 1994.[33]CarloGhezzi,MehdiJazayeri,DinoMandrioli,SoftwareEngineering[34]RichardHamlet:RandomTesting,inEncyclopediaofSoftwareEngineering, ed. J. J. Marciniak, 1994, available at [35]BrianHenderson-Sellers:Object-OrientedMetrics:MeasuresofComplexity[36]ThomasA.Henzinger,XavierNicollin,JosephSifakisandSergioYovine:SymbolicModelCheckingforReal-TimeSystems,inLogicinComputerScience,Proceedingsof7thSymposiuminLogicsforComputerScience,SantaCruz,California,1992,pages394-406,availableat [37]C.A.R.Hoare:Anaxiomaticbasisforcomputerprogramming,inCommunicationsoftheACM,Vol.12,no.10,October1969,pages576-580,available at [38]C.A.R.HoareandJayadevMisra:VeriÞedSoftware:Theories,Tools,Experiments,VisionofaGrandChallengeProject,October2005,foundationpaperfortheVSTTEconferenceconference,availableat [39]IFIPWorkingGroup10.4ondependablecomputingandfaulttolerance: .dependability .or g. DEPENDABLE SOFTWARE [40]MichaelJackson:ProblemFrames:AnalysingandStructuringSoftwareDevelopment Problems, Addison-Wesley, 2001.[41]Jean-MarcJŽzŽquelandBertrandMeyer:DesignbyContract:TheLessonsofAriane,in(IEEE),vol.30,no.1,January1997,pages129-130, available at v e.eif fel.com/doc/manuals/technology/contract/ [42] JUnit pages at SourceForge: [43]GaryT.LeavensandYoonsikCheon:DesignbyContractwithJML(Draft),at v ;seealsoother .cs.iastate.edu/~lea v [44]AndreasLeitner,IlincaCiupa,BertrandMeyerandMarkHoward:ReconcilingManualandAutomatedTesting:TheAutoTestExperience[45]NancyG.Leveson:SystemSafetyinComputer-ControlledAutomotive, SAE Congress, March 2000, available at yday .mit.edu/papers/ [46]MichaelR.Lyu(ed.):HandbookofSoftwareReliabilityEngineering,IEEEComputerSocietyPressandMcGraw-Hill,1995;alsoavailableonline [47]ZoharMannaandAmirPnueli:Thetemporallogicofreactiveandconcurrent systems, Springer-Verlag, 1992.[48]ThomasJ.McCabe:AComplexityMeasure,inIEEETransactionsonSoftware Engineering, vol. 2, no. 4, December 1976, pages 308-320.[49]ThomasJ.McCabeandCharlesW.Butler:DesignComplexityMeasurementandTesting,inCommunicationsoftheACM,vol.32,no.12,[50]BertrandMeyer:IntroductiontotheTheoryofProgrammingLanguages[51]BertrandMeyer,TheNewCultureofSoftwareDevelopment:ReßectionsonthePracticeofObject-OrientedDesign,inAdvancesinObject-OrientedSoftware Engineering, eds. D. Mandrioli, B. Meyer, Prentice Hall, 1991.[52]BertrandMeyer:Eiffel:TheLanguageprinting,PrenticeHall,1992.[53]BertrandMeyer:ApplyingÒDesignbyContract",in[54] Bertrand Meyer:[55]BertrandMeyer:PracticetoPerfect:TheQualityFirstModel,, May 1997, pages 102-106, available at yer/ publications/computer/quality_Þrst.pdf. 10REFERENCES [56]BertrandMeyer:UML:ThePositiveSpin,inAmericanProgrammer,1997,availableat [57]BertrandMeyer:Object-OrientedSoftwareConstruction[58]BertrandMeyer,ChristineMinginsandHeinzSchmidt:ProvidingTrustedComponentstotheIndustry,in(IEEE),vol.31,no.5,May1998, pages 104-105, available at yer/publications/computer/ [59]BertrandMeyer:TheRoleofObject-OrientedMetrics,inComputer(IEEE),vol.31,no.11,November1998,pages123-125,availableat [60]BertrandMeyer,EveryLittleBitCounts:TowardsReliableSoftware,in(IEEE_,vol.32,no.11,November1999,pages131-133,available [61]BertrandMeyer:TheGrandChallengeofTrustedComponents,in(InternationalConferenceonSoftwareEngineering,Portland,Oregon,[62]BertrandMeyer:ThePowerofAbstraction,ReuseandSimplicity:AnObject-OrientedLibraryforEvent-DrivenDesign,FromObject-OrientationtoFormalMethods:EssaysinMemoryofOle-JohanDahl,eds.OlafOwe,SteinKrogdahl,TomLyche,LectureNotesinComputerScience2635, Springer-Verlag, 2004, pages 236-271, available at yer/ publications/lncs/e v [63]BertrandMeyer:OffshoreDevelopment:TheUnspokenRevolutioninSoftwareEngineering,in(IEEE),January2006,pages122-124,available at [64]BertrandMeyer:WhatwillremainofExtremeProgramming?EiffelWorld, Vol. 5, no. 2, February 2006, available at .eif fel.com/ general/monthly_column/2006/February [65]BertrandMeyerandKarineArnout:Componentization:theVisitor,toappearin(IEEE),2006,draftavailableat yer/publications/computer/visitor [66] Microsoft: Visual Studio pages at [67]RichardMitchellandJimMcKim:DesignbyContractbyExampleAddison-Wesley, 2001.[68]CarrollMorgan:ProgrammingfromSpeciÞcationsedition,PrenticeHall, 1994, available at .comlab [69]JohnMusa:SoftwareReliabilityEngineeringedition,McGraw-Hill,1998. DEPENDABLE SOFTWARE [70]GlenfordJ.Myers,CoreySandler,TomBadgettandToddM.Thomas:The Art of Software Testing edition, Wiley, 2004.[71] Jeff Offutt: Mutation testing papers at .ise.gmu.edu/~ofut/rsrch/ [72]JohnPincus:presentations(mostlyPowerPointslides)onPREÞxandPREfast at [73]EricRaymond:TheCathedralandtheBazaar:MusingsonLinuxandOpenSourcebyanAccidentalRevolutionary,OÕReilly,1999;earlierversionavailable at .Þrstmonday .or [74]SoftwareEngineeringInstitute,CMMIsite,availableat [75]MattStephensandDougRosenberg:ExtremeProgrammingRefactored:[76]AxelvanLamsweerde:Goal-OrientedRequirementsEngineering:AGuidedTour,inProceedingsofthe5thIEEEInternationalSymposiumonRequirements Engineering, August 2001, available at [77]VeriÞedSoftware:Theories,Tools,Experiments:InternationalIFIPconference,ETHZurich,October2005,seeVSTTEconferencesiteat [78]JohnViega:TheMythofOpen-SourceSecurity,2000,availableat .de v eloper ;follow-uparticle,Open-SourceSecurity:StillatMyth,September2004,availableat [79]JeffreyM.VoasandGaryMcGraw:SoftwareFaultInjection:InoculatingPrograms Against Errors, Wiley, 1998.[80]JosWarmerandAnnekeKleppe:TheObjectConstraintLanguage:Getting Your Models Ready for MDA edition, Addison-Wesley, 2003.[81]ElaineJ.WeyukerandBingchiangJeng:AnalyzingPartitionTestingStrategies,inIEEETransactionsonSoftwareEngineering,vol.17,no.9,July[82]Wikipedia:entryÒMarsClimateOrbiterÓ,availableat [83]EdwardYourdon:WhenGoodEnoughSoftwareIsBest,inSoftware(IEEE), vol. 12, no. 3, May 1995, pages 79-81.