CS427: Software Engineering IAdministrative infoTopicsExample ADTINSIntentional namesDatabases in INSSlide 8Slide 9ADT for databaseOperationsAxiomsDesign vs. implementationSoftware quality assurancePerspective on qualitySQATotal quality management“Quality is free”Cost of fixing an errorError: Terminology?Failure vs. flawFailure costsPrevention costsJohnson’s lawWays not to improve qualityHow to improve qualityMetricsHow to appraise qualityBug trackingSlide 30Use quality information to make decisionsSlide 32Technical reviewsMain goal: Evaluate qualitySecondary goal: Improve qualityThe review teamLeaderRecorderReviewersResult of reviewWalkthroughInspectionReviewing productsChecklist: Smalltalk codeSummaryNext: Continuing on SQA1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 20-2Administrative infoHW2 graded, get hard copies from GaneshGrades posted on WikiNew Wiki serverhttp://pixie.cs.uiuc.edu:8080/SEcourseConsider switching to another Wiki (for CS428)HW3 postponed for Thursday, Nov. 9State machines and ADTsProject groups start/keep meeting with TAsGet feedback on projects from TAsCS427 20-3TopicsCovered designComponent-level designModularity and abstraction, refinementXP example (for analysis and design)OO design (and some RUP reminders) TodayADTs: one more example (others in Lecture 17)Software Quality AssuranceCS427 20-4Example ADTIntentional Naming System (INS)We’ll look at this onePhone bookYou can see it with more details elsewherehttp://www.mit.edu/~6.170/lectures/adts.pdfSomething from your projectsIf you have questions, you can ask now or through emails/newsgroupCS427 20-5INS[Adjie-Winoto et al., SOSP 1999]Resource discovery in dynamic networksNames in INS mean what not whereTraditional: ‘128.174.252.214’ or ‘ds3203.cs.uiuc.edu’Intentional: ‘color printer for transparencies’Intentional namesHierarchy of attributes and valuesIntentional namesR0SCbuilding servicecameraR1printerSCbuilding serviceCS427 20-7Databases in INSCollect information about resourcesRespond to queriesAdd to databaseR0SCbuilding servicecameraR1printerSCbuilding servicebuilding serviceSC camera printerdatabaseR0R1lookup(query, database) = {R0}R0SCbuilding servicecameraR1printerSCbuilding servicebuilding serviceSC camera printerdatabaseR0R1querySCservicecamerabuildingLookup into databaseCS427 20-10ADT for databaseSuppose that we’ve already designedIntentional Name (this is not that easy)Resource (this is trivial)We want to design databaseValues?Operations?Properties?CS427 20-11OperationsConstructors (types?)empty:add:Observers (types?)lookup:get:CS427 20-12AxiomsNotation: OO (receiver) or math (functions)Basic axioms for collections (preconditions?)Main property: subtree matching in lookupCS427 20-13Design vs. implementationImplementation for INS had a few hundreds lines of Java codeHard to understand high-level pictureHad bugsCannot fit in one slideAxioms can fit into one slideEasier(?) to understandCan analyze automatically (found some bugs)CS427 20-14Software quality assuranceSQA: not just testingHow can you tell if software has high quality?How can we measure the quality of software?How can we make sure software has high quality?CS427 20-15Perspective on qualityCustomerSystem not crashesSystem follows documentationSystem is logical and easy to useDeveloperSystem is easy to changeSystem is easy to understandSystem is pleasant to work onCS427 20-16SQAPotential mistakesQuality is conformance to requirements and standardsVariation control is the heart of quality control (mass production unlike software)Iterative viewFeedback and continual improvement is the real heart of quality softwareCS427 20-17Total quality managementFactoriesGoal is for every item coming off the assembly line to be perfect Management, production, engineering, QAEveryone is involved in qualityDevelop a reliable, repeatable processContinuously improve the processCS427 20-18“Quality is free”QualityEffortCS427 20-19Cost of fixing an errorDesign Code Dev.TestSystemTestFieldoperation3-6timesReq.10times15-40times30-70times40-1000times101time10010001CS427 20-20Error: Terminology?AnomalyBugCrashDefectErrorFailure/fault…CS427 20-21Failure vs. flawFailure - program didn’t work rightFlaw - mistake in the text of the programFailure analysis (debugging) - what flaw caused this failure?Flaw analysis - what is wrong with our process that allowed this flaw to be created and not detected?CS427 20-22Failure costsInternalReworkRepairFailure analysis ExternalResolving complaintsReturning and replacing productHelp lineCS427 20-23Prevention costsPreventionPlanningManaging and collecting informationReviewsAppraisalInspectionTestingCS427 20-24Johnson’s law“If you don’t test for it, your system doesn’t have it.”Is it easy to use? Easy to maintain? Does it crash?Does it match the documentation?Does it make customers happy?CS427 20-25Ways not to improve qualitySay “Be more careful!”Say “Quality is important.”Find out whose fault it is and fire himCS427 20-26How to improve qualityMeasure and compareDetermine root cause of problemsCreate ways to eliminate problemsCS427 20-27MetricsIf you don’t see it, it doesn’t existMeasure quality over time (metrics)Display in a public placeMake quality goals, then check to see if you meet themCS427 20-28How to appraise qualityRequirementsReviews by customersPrototypingAnalysis and design modelsFormal reviews, inspectionsCurrent systemBug reportsUser testsSurveysCS427 20-29Bug trackingKeep track ofWho reported the bug (the failure)Description of the failureSeverityThe flaw that caused this failureWho is repairing itThe repairCS427 20-30Bug trackingUse information about failures to estimate reliabilityCompareCritical nature of failureIteration failure discoveredModule that had the flawCS427 20-31Use quality information to make decisions“Must repair all level 1 failures before shipping”“Half of all level 1 and 2 failures in the alpha release were in the Call Processing module; we should rewrite it.”“Half of all level 1 and 2
View Full Document