Unformatted text preview:

1CS 350, slide set 5M. OverstreetOld Dominion UniversitySpring 2005Reading PSP text, ch. 11, 12, 13, 14Topics A software development process Measuring software quality Finding defects A code review checklist2Process A sequence of steps to complete a task Provides guidance Can provide a record of what has been accomplished Can provide an indication of percent of project which has been completed•After we’ve used 50% of time allocated, have we finished 50% of the work?Some basic definitions Recall defn’s from Ch. 5 Product: something you produce, usually for someone else Project: produces a product Task: an element of work Process: the steps to produce a product Plans: the way a specific project is to be done; how, when, at what costs Job: something you do; either a project or a task More Processes can have various phases Each phase can consist of several activitiesPSP processPost MortemTestCompileCodeTest DesignCode DesignPlanningRequirementsFinished productScriptsProjectplansummaryLogsPlan and actualproject and processdataTime anddefect dataGuidancePlan dataActualdata3PSP process script - 1Prepare test plans and dataEnter test design time in Time Recording logTest design3Design the programRecord design in specified formatEnter code design time in Time Recording LogCode design2Identify program functionsIdentify test objectivesEstimate max, min, and total LOCDetermine minutes/LOCCalculate max, min, and total timeEnter data in Project Plan Summary FormRecord planning time in Time Recording LogPlanning1Problem statementPSP Project Plan Summary formActual size and time data from old projectsTime Recording LogEntryCriteriaTo guide you in developing programsPurposePSP Process Script - 2A thoroughly tested programA properly documented designComplete source codeDocumented and corrected test dataA MakefileA completed set of test reportsA completed Project Plan SummaryCompleted Time Logs; All required submitted.Exit criteriaComplete the Project Plans Summary with actual time and size dataRecord postmortem time in Time Recording LogPostmortem6 Test the programFix defects as discoveredComplete test reportsRecord time in Time Recording LogTest5Compile the codeFix defects as discoveredRecord time in Time Recording LogCompile4Implement the designComplete a MakefileUse a standard format for entering codeRecord coding time in Time Recording LogCode3Software Quality Complex topic How do customers measure the quality of a product? How do developers measure the quality of a product? Includes, among many possibilities: How many problems does a typical user encounter when using the product? Does the product provide key functionalities to the user? How do features of this product compare with competing products? How easy is it to enhance/modify/extend/revise/tailor the product? How easily can components from this product be used in other products? We’re going to keep it simple: defects/KLOC4What’s a defect in PSP? Anything wrong with a program: Misspelling in comment Bad punctuation, poor formatting Incorrect logic Missing functionality Documentation, format does not conform to organizational standard In short, any change you make to code after you type it in and proofread it. Errors are mistakes people make. Some result in defects in code.Why record defect types? To have real data on what is causing problems To help direct possible changes to software processes Pointless unless defect types, frequencies, and times-to-fix are periodically analyzed and acted uponGoals of defect form Improve your programming Reduce number of defects in your code Save you time To do you job responsibly: you find your own mistakes rather than someone else finding them5Fixing defects Recognize defect symptoms From symptoms, deduce likely locations of defects Sometimes hard to do, sometimes not Identify source Fix it Verify that the fix: Resolved the problem Did not introduce new problemsWays to find code defects Let others find them (not recommended) This approach has some disadvantages Use testing to locate defects Widely used; very expensive; misses many Use mathematical methods (proofs of correctness) to locate defects Rarely used; very expensive, maybe infeasible in most cases Use Code Reviews Use Code Inspections (will discuss later)Why Code Reviews? Compilers miss lots of typo/syntax errors (probably 10% -- depends on language) Testing misses lots of defects (some assert 50%) No matter how many defects are in the code to begin with! Testing and code reviews are probably complimentary activities Code reviews can find some defects not easily found in testing Testing finds can some defects not easily found by code reviews6Review before compiling! Takes as long to do review before as after Saves some compile time Typically 10% to 15% if done without review Typically ~3% if done with review Compiles finds errors equally well with or without review Reviewers don’t find errors as effectively if they know the code has compiled cleanly. Probably human nature:• if we don’t really expect to find things, we don’t look as hard.• if we expect to find things and don’t, we probably look again.Additional comments In PSP, you do your own reviews. Goal is to save you time, improve your code quality In TSP (remember the next textbook?), this is supplemented by inspections. Since fixing code is so expensive, we have much industrial data that shows reviews pay!Code review script - 1Verify that the program design fulfills all of the functionalitydescribed in the requirementsVerify that the source code implements the designReview for coverage3Fix all defects foundCheck the fixes to ensure they are correctRecord the defects in the Defect Recording LogFix the defects2First produce the finished program source code.Before compiling, print a source listingNext, do the code reviewDuring the code review, carefully check every line of source code to find and fix as many defects as possibleReview procedure1Check that the following are on hand:1. The requirements statement2. The program design3. The program source code4. The coding standards5. A Defect Recording LogEntry criteria7Code Review Script - 2At completion you must have:1 The completed and corrected source code2. Completed Time Recording


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?