CS427: Software Engineering IAdministrative infoSoftware 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 19Use quality information to make decisionsSlide 21Technical reviewsMain goal: Evaluate qualitySecondary goal: Improve qualityThe review teamLeaderRecorderReviewersResult of reviewWalkthroughInspectionReviewing productsHomework 4To be reviewedTo reviewIn real lifeExample checklist: Smalltalk codeSummaryNext: DFD or UI design?1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 20-2Administrative infoHW2 graded, get hard copies from GaneshGrades posted on WikiHW3 due todayWill grade it before the Thanksgiving breakHW4 posted, due next Thursday, Nov. 16Reviews done in pairs across different groupsCreate “pairs” of “pairs” as soon as possible Project groups start/keep meeting with TAsGet feedback on projects from TAsCS427 20-3Software quality assuranceSQA: not just testingHow can you tell if software has high quality?How can we measure the quality of software?How can we increase the quality of software?CS427 20-4Perspective 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-5SQAPotential 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-6Total 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-7“Quality is free”QualityEffortCS427 20-8Cost of fixing an errorDesign Code Dev.TestSystemTestFieldoperation3-6timesReq.10times15-40times30-70times40-1000times101time10010001CS427 20-9Error: Terminology?AnomalyBugCrashDefectErrorFailure/fault/flaw/“feature”…CS427 20-10Failure 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-11Failure costsInternalReworkRepairFailure analysis ExternalResolving complaintsReturning and replacing productHelp lineCS427 20-12Prevention costsPreventionPlanningManaging and collecting informationReviewsAppraisalInspectionTestingCS427 20-13Johnson’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-14Ways not to improve qualitySay “Be more careful!”Say “Quality is important.”Find out whose fault it is and fire himCS427 20-15How to improve qualityMeasure and compareDetermine root cause of problemsCreate ways to eliminate problemsCS427 20-16MetricsIf 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-17How to appraise qualityRequirementsReviews by customersPrototypingAnalysis and design modelsFormal reviews, inspectionsCurrent systemBug reportsUser testsSurveysCS427 20-18Bug trackingKeep track ofWho reported the bug (the failure)Description of the failureSeverityThe flaw that caused this failureWho is repairing itThe repairCS427 20-19Bug trackingUse information about failures to estimate reliabilityCompareCritical nature of failureIteration failure discoveredModule that had the flawCS427 20-20Use 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 defects found in the design reviews were in Call Processing; we should rewrite it.”CS427 20-21Bug trackingDiscover the flaw (defect) that caused each bugCategorize flawsLook at categories with the most flaws and improve your process to eliminate themCS427 20-22Technical reviewsA way to evaluate the quality of requirements, designs, and softwareA way to improve the quality of requirements, designs, and softwareA way to educate new developers and ensure that developers are consistentProven to be cost-effective!CS427 20-23Main goal: Evaluate qualityProduce a report describing Potential problemsSummary of overall qualityPass/failEvaluated by expert outsidersMust know enoughShouldn’t know too muchCS427 20-24Secondary goal:Improve qualityFind flawsEnforce standardsImprove standardsProvide feedback to managementCS427 20-25The review teamLeader (moderator)RecorderReviewersCS427 20-26LeaderResponsible for obtaining a good review - or reporting why a good review wasn’t possibleGood review - one that accurately describes the quality of the productMake sure that reviewers have all the material they need for the reviewGet a time and place for the reviewCS427 20-27RecorderResponsible to provide information for an accurate report of the reviewTypically writes notes on a “flip chart” or other public mediumAt end of review, recorder gives summary and makes sure the team agreesRecorder helps leader make final reportCS427 20-28ReviewersStudy product in advance and take notesHave a check-list of review criteriaGive both positive and negative commentsRaise issues, don’t resolve themMust be technically competentStick to standards - or stick the standardsCS427 20-29Result of reviewReview summaryWho, what, when and the conclusionIssues listCan result in more detailed reportsGive priority to issuesCan be disagreement on issuesMost issues are about product, but can also be about process or standardsCS427
View Full Document