DOC PREVIEW
ODU CS 350 - Lecture Notes

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1CS 350, slide set 9M. OverstreetOld Dominion UniversitySpring 2005Reading Appendix C: Software InspectionsOutline What are inspections? What makes inspections effective? Inspection methods Inspection data The inspection report: from INS2What are inspections? Two or more programmers review someone else's work to identify: defects problems The purpose is NOT to fix, just to identify. Fixing too often becomes a distraction from inspecting. Can be used for almost any items produced in software development Requirements, test designs, HLD, DLD, test data, user manuals, ... .Inspection phases Briefing Often developer of item brings inspectors up to speed Review Must be done before meeting, so inspectors are prepared Meeting The formal review process Repair Done after meeting More effective if done with a scriptWhy are inspections effective? - 1 Reviewing decisions so you can be ready to explain them helps you improve your decisions Figuring out how to explain your work to someone else often helps you discovers problems in it.3Effective? - 2 Use collective knowledge The group often has a broader experience base than the developer alone; some may know what the common problems are Helps if inspectors can look at product from points of view:• Use, tester, coder, designer, ... . Can give opportunity to look at entire item at once Testing (the alternative) tends to looks only at details – one test case at a timeOther observations Testing is still needed even when inspections are conducted effectively Only inspect reviewed products Respect time of other people Trivial errors can distract from serious, perhaps subtle, flaws Saves embarrassmentChecklists For this kind of detailed activities, most of us work better from checklists. Checklists should be developed over time Most of use tend to make the same kinds of errors repeatedly Should be personal checklists4Inspection rates for preparation: guidelines only Requirements: fewer than 2 pages/hr. High level design: fewer that 5 pages/hr. Detailed design: fewer than 100 pseudocode lines/hr Code: fewer than 200 loc/hr All of these are probably optimisticAssumes you're shooting for an A rather than a CMore rates: These things vary a lot; Depends on complexity of product Experience of developers and inspectors Plan to spend about 50% of design time in inspectionInspection yield High inspection yield saves time Humphrey reports on Air Force project where with the use of inspections, testing time went from 22% of development schedule to 2.7%5Announcements Group assignments made Sent to UNIX accounts Let me know of problems, particularly contacting ALL members What’s due from groups: Group suggestion of what modules to implement• E-mail to cmo. Sent by Team Leader• Due by midnight Saturday. Goals (individual, group)•Due Tuesday midnight Weekly Reports.• Submitted once per week, starting this week• First due Monday by midnightTesting Concepts Review - 1 It a lot of work and can easily take more time, creativity than coding! NASA build a simulator to plug the code into Concept (other approaches are sometimes better): Each module uses inputs to produce outputs The tester makes up inputs and determines the outputs a correct program should produce from them.• This can be very difficult! The tester prepares a file of inputs and expected outputsTesting Concepts - 2 A test driver feeds the file inputs to a module, then compares the module’s output with those in the file. The test driver produces a report Note: code to be tested can fail in lots of ways besides getting wrong answers!• May not compile, may not like, may loop, may abort so that no run report is produced by the test driver. So after you’ve completed testing, you have:1. Files of test cases, perhaps many2. Code for a test driver3. A collection of reports, one report for each test case• Some generated by the test driver, some written by the tester6Test Concepts - 3 Problems: How do you know what to test?•Requirements coverage•Programming experience• Special cases• Extremes•Critical functionality How do you create expected outputs?Consider building a testing tool For cp, a correct version packs data into a packet on byte boundaries You give cp data, then check to see if cp puts the right stuff in the right place. Checking isn’t easy because of the packing. Consider using a version testalias.cpp to help build test data For example, give it a double, then let it print the corresponding 4 shorts.• Sometimes the corresponding 6 shorts! Depends on byte boundaries used by the double. How could this help build test data? Point:• Does this save you time?• Does this improve your testing?Traditional inspection roles Developer of item (code, test plan, requirements, user doc) – present to answer questions Presenter – present items being inspected, line by line Inspectors, usually at least two – the come prepared with a list of defects that they identify when presenter gets there Recording – takes notes, follows up Moderator – decides of inspectors are prepared, runs meeting, controls behavior7Typical Time script 1 week before inspection, developer briefs inspectors, providing them a complete set of items to be inspected Inspection should go no longer than 2 hours Moderator must stop inspection if inspectors are not prepared Follow-up options: If simple, left to recorder to sign off that all defects have be removed If not, may need to schedule a follow-up meetingFor TSP Follow inspection script in text (outline below) Use forms provided Use smaller group, maybe only 3 or 4 people with moderator covering role of presenter and recorder alsoEstimating yield with 2 inspectors A: number of defects found by ins. 1 B: number of defects found by ins. 2 C: number of defects found by both Estimated defects: A×B/C Found defects: A+B-C Est. remaining: A×B/C-(A+B-C) Yield: [100(A+B-C)×C]/(A×B)82 inspector report - 175.0760 153 29812 741.7380 68 3355 4 Sue58.3380 85 268 7 3GeorgeEst. YieldPrep TimeSize Time RateDefects Major MinorNameSent to moderator; prepared before inspectionInspection form - 24 2Unique


View Full Document

ODU CS 350 - Lecture Notes

Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?