1. 1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

2. CS42720-2 Administrative info zHW2 graded, get hard copies from Ganesh yGrades posted on Wiki zNew Wiki server yhttp://pixie.cs.uiuc.edu:8080/SEcoursehttp://pixie.cs.uiuc.edu:8080/SEcourse yConsider switching to another Wiki (for CS428) zHW3 postponed for Thursday, Nov. 9 yState machines and ADTs zProject groups start/keep meeting with TAs yGet feedback on projects from TAs

3. CS42720-3 Topics zCovered design yComponent-level design yModularity and abstraction, refinement yXP example (for analysis and design) yOO design (and some RUP reminders) zToday yADTs: one more example (others in Lecture 17) ySoftware Quality Assurance

4. CS42720-4 Example ADT zIntentional Naming System (INS) yWe’ll look at this one zPhone book yYou can see it with more details elsewhere yhttp://www.mit.edu/~6.170/lectures/adts.pdfhttp://www.mit.edu/~6.170/lectures/adts.pdf zSomething from your projects yIf you have questions, you can ask now or through emails/newsgroup

5. CS42720-5 INS z[Adjie-Winoto et al., SOSP 1999] zResource discovery in dynamic networks zNames in INS mean what not where yTraditional: ‘128.174.252.214’ or ‘ds3203.cs.uiuc.edu’ yIntentional: ‘color printer for transparencies’ zIntentional names yHierarchy of attributes and values

6. Intentional names R0R0 SC buildingservice camera R1R1 printerSC buildingservice

7. CS42720-7 Databases in INS zCollect information about resources zRespond to queries

8. Add to database R0R0 SC buildingservice camera R1R1 printerSC buildingservice buildingservice SCcameraprinter database R0R0 R1R1

9. lookup(query, database) = {R 0 } R0R0 SC buildingservice camera R1R1 printerSC buildingservice buildingservice SCcameraprinter database R0R0 R1R1 query SC service camera building Lookup into database

10. CS42720-10 ADT for database zSuppose that we’ve already designed yIntentional Name (this is not that easy) yResource (this is trivial) zWe want to design database yValues? yOperations? yProperties?

11. CS42720-11 Operations zConstructors (types?) yempty: yadd: zObservers (types?) ylookup: yget:

12. CS42720-12 Axioms zNotation: OO (receiver) or math (functions) zBasic axioms for collections (preconditions?) zMain property: subtree matching in lookup

13. CS42720-13 Design vs. implementation zImplementation for INS had a few hundreds lines of Java code yHard to understand high-level picture yHad bugs yCannot fit in one slide zAxioms can fit into one slide yEasier(?) to understand yCan analyze automatically (found some bugs)

14. CS42720-14 Software quality assurance zSQA: not just testing zHow can you tell if software has high quality? zHow can we measure the quality of software? zHow can we make sure software has high quality?

15. CS42720-15 Perspective on quality zCustomer ySystem not crashes ySystem follows documentation ySystem is logical and easy to use zDeveloper ySystem is easy to change ySystem is easy to understand ySystem is pleasant to work on

16. CS42720-16 SQA zPotential mistakes yQuality is conformance to requirements and standards yVariation control is the heart of quality control (mass production unlike software) zIterative view yFeedback and continual improvement is the real heart of quality software

17. CS42720-17 Total quality management zFactories zGoal is for every item coming off the assembly line to be perfect zManagement, production, engineering, QA zEveryone is involved in quality zDevelop a reliable, repeatable process zContinuously improve the process

18. CS42720-18 “Quality is free” Quality Effort

19. CS42720-19 Cost of fixing an error DesignCodeDev. Test System Test Field operation 3-6 times Req. 10 times 15-40 times 30-70 times 40-1000 times 10 1 time 100 1000 1

20. CS42720-20 Error: Terminology? zAnomaly zBug zCrash zDefect zError zFailure/fault z…

21. CS42720-21 Failure vs. flaw zFailure - program didn’t work right zFlaw - mistake in the text of the program zFailure analysis (debugging) - what flaw caused this failure? zFlaw analysis - what is wrong with our process that allowed this flaw to be created and not detected?

22. CS42720-22 Failure costs zInternal yRework yRepair yFailure analysis zExternal yResolving complaints yReturning and replacing product yHelp line

23. CS42720-23 Prevention costs zPrevention yPlanning yManaging and collecting information yReviews zAppraisal yInspection yTesting

24. CS42720-24 Johnson’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?

25. CS42720-25 Ways not to improve quality zSay “Be more careful!” zSay “Quality is important.” zFind out whose fault it is and fire him

26. CS42720-26 How to improve quality zMeasure and compare zDetermine root cause of problems zCreate ways to eliminate problems

27. CS42720-27 Metrics zIf you don’t see it, it doesn’t exist zMeasure quality over time (metrics) zDisplay in a public place zMake quality goals, then check to see if you meet them

28. CS42720-28 How to appraise quality zRequirements yReviews by customers yPrototyping zAnalysis and design models yFormal reviews, inspections zCurrent system yBug reports yUser tests ySurveys

29. CS42720-29 Bug tracking zKeep track of yWho reported the bug (the failure) yDescription of the failure ySeverity yThe flaw that caused this failure yWho is repairing it yThe repair

30. CS42720-30 Bug tracking zUse information about failures to estimate reliability zCompare yCritical nature of failure yIteration failure discovered yModule that had the flaw

31. CS42720-31 Use quality information to make decisions z“Must repair all level 1 failures before shipping” z“Half of all level 1 and 2 failures in the alpha release were in the Call Processing module; we should rewrite it.” z“Half of all level 1 and 2 defects found in the design reviews were in Call Processing; we should rewrite it.”

32. CS42720-32 Bug tracking zDiscover the flaw (defect) that caused each bug zCategorize flaws zLook at categories with the most flaws and improve your process to eliminate them

33. CS42720-33 Technical reviews zA way to evaluate the quality of requirements, designs, and software zA way to improve the quality of requirements, designs, and software zA way to educate new developers and ensure that developers are consistent zProven to be cost-effective!

34. CS42720-34 Main goal: Evaluate quality zProduce a report describing yPotential problems ySummary of overall quality yPass/fail zEvaluated by expert outsiders yMust know enough yShouldn’t know too much

35. CS42720-35 Secondary goal: Improve quality zFind flaws zEnforce standards zImprove standards zProvide feedback to management

36. CS42720-36 The review team zLeader (moderator) zRecorder zReviewers

37. CS42720-37 Leader zResponsible for obtaining a good review - or reporting why a good review wasn’t possible zGood review - one that accurately describes the quality of the product zMake sure that reviewers have all the material they need for the review zGet a time and place for the review

38. CS42720-38 Recorder zResponsible to provide information for an accurate report of the review zTypically writes notes on a “flip chart” or other public medium zAt end of review, recorder gives summary and makes sure the team agrees zRecorder helps leader make final report

39. CS42720-39 Reviewers zStudy product in advance and take notes zHave a check-list of review criteria zGive both positive and negative comments zRaise issues, don’t resolve them zMust be technically competent zStick to standards - or stick the standards

40. CS42720-40 Result of review zReview summary yWho, what, when and the conclusion zIssues list yCan result in more detailed reports yGive priority to issues yCan be disagreement on issues yMost issues are about product, but can also be about process or standards

41. CS42720-41 Walkthrough zProducer guides reviewers through the product zEasier on reviewers yCan cover more material yMore reviewers can participate zGood for training the reviewers zNot as good for evaluating and improving the product

42. CS42720-42 Inspection zConfine attention to a few aspects of the product, one at a time zLess preparation by reviewers than for review zMore preparation by leader - must give detailed instructions to reviewers

43. CS42720-43 Reviewing products zMust compare each product with the products that it is based on yClass diagram based on use cases yCode in RUP based on design yCode in XP based on tests zSome products not based on any other products yUser stories? yVision statement?

44. CS42720-44 Checklist: Smalltalk code zClass names make sense zThere is a good class comment that defines variables zClasses not too big (less than 20 methods) zClasses have behavior zMethod names ySpelled out in full yAccessors are “attribute” and “attribute:” yMethods with side effects are commands yMethods without side effects are adjectives or noun phrases zMethods not too big (less than 15 lines)

45. CS42720-45 Summary zReviews are an important quality control technique zPair-programming is a kind of informal review zUse reviews to improve your process, not just your product

46. CS42720-46 Next: Continuing on SQA zHamlet and Maybee, Chapter 19 on Testing (not 17 or 18)