CS 350, slide set 9

1
CS 350, slide set 9

• M. Overstreet
• Old Dominion University
• Fall 2005

2
Simplified Task Planning Template (p. 82)

• Rows include only
• Launch strategy
• Plan-tasks and schedule
• System test plan
• Only one line per module (but see next slide)
• Postmortem
• Totals
• Columns include only
• Task Name Planned Value
• Plan hours by person Cumulative PV
• Total team hours Actual hours
• Cumulative hours Cumulative hours
• Size Actual Week
• Planned Week

3
Task Plan/Report per Module
4
Another omission

• Given the limited time
• Log where errors are found only
• Omit noting where errors are inserted
• You must report errors found for each task
• Some tasks may be unlikely to discover errors,
  but also include them in your error report.

5
Reading

• TSP text, omit Ch. 6 central part of CS 410
• TSP text Ch. 7, 8, 9, 10, App. B (config.
  mgmt) will be discussed in class
• TSP text Read Ch. 16 (Managing yourself), Ch. 17
  (Being on a team), Ch. 18 (Teamwork)

6
Whats due when?

• See class web site, link under checklists,
  Required forms checklist, due dates
• Submit completed components to userid cs350
• The grader will check for them there

7
Comments

• Make sure you know what data you will need to
  report so it will take less time to provide it!
• Look over the forms NOW!
• You set your own schedules
• But we will be checking on what you submit
  prompting for things!
• Project is about TSPi, not coding
• Eval. biased on determining if you followed TSPi!
• Did you make reasonable plans (time, sizes, req.
  tasks)?
• Were you able to handle the inevitable surprises?
• Did you set goals, design, inspect, test, record
  errors, log time, etc.?
• Did you measure your performance against your
  goals?
• Did you support your team?

8
Term Project Requirements - 1

• Overview
• Loop M times
• Generate test data N numeric values
• Store N values in a file
• Run P programs
• Each read test data
• Executes
• Store output in a file
• Read output files to compare output from M
  programs
• Report differences
• Count differences
• Compute simple estimate off reliability of each
  program

9
Requirements - simplifying assumptions

• All programs to be tested read from standard
  input
• Test programs have a fixed set of names pgm01,
  pgm02, pgm03, etc.
• Not desirable, but simplifies coding.
• All input is numeric.
• All programs read their input until EOF.
• All output is numeric.
• But you dont know how much!
• These programs may be buggy, but are all supposed
  to do the same thing.

10
Requirements - 3

• Your program reads 3 values from standard input
• M, the outer loop parameter the number of test
  cases
• N, the number data values per test case
• P, the number of programs. Assume P is at least
  2.

11
Requirements - Random values

• Use an existing random number generator
• do man random on a UNIX box
• You should generate values between 0 and 10.
• For debugging, you want to be able to generate
  exactly the same set of random numbers on
  different runs.
• Set the seed explicitly to a constant.

12
Requirements - computing reliability - 1

• We will compute only an estimate of reliability.
• If one program produces an output that disagrees
  with all other programs and they agree, count
  this as an error for that one program.
• If more than one program produces a different
  value, assume all programs are in error. See
  example next slide
• Two programs is a special case. You can count
  either way, but be sure you can handle this.

13
Requirements - Reliability - 2

• If were testing five programs

14
Requirements Comparing Floats

• For coding simplicity, assume all data to be
  compared are floats
• would be better to treat integer values
  differently from float (or double) values
• Assume two floats are equal if they differ by
  less than 0.01.
• Use pgm01 output as the basis for the percentage
  comparison.

15
Hints use system OS call

• Do man system on a UNIX box for documentation.
• Example to run program abc from a C program
  and have it read from file Input (as standard
  input) and write to file Output as standard
  output, use
• system( ./abc Output )
• System is an OS call to the operating fork a new
  shell and run the parameter in that shell as if
  you had typed that command.

16
Use of files

• Data generator module generates one file
• That file is read repeatedly, once by each
  program being tested.
• Testing generates several output files, one per
  test program
• The comparison module
• Reads one value from each output file
• Loop using array of files.
• Compare values, reports and counts
• Loops until end-of-file

17
Whats hard to code? - 1

• Example assume you have five versions of a
  program that read numeric data and compute the
  mean and standard deviation of input data.
• A possible defect some version only produces the
  mean but not the standard deviation
• So, in general, your program does not know how
  much output to expect and different versions may
  produce different size output.

18
Whats hard to code? - 2

• What happens if one version fails and produces no
  output?
• What happens if one version loops?
• What happens if one version incorrectly produces
  nonnumeric output?
• Answer ignore problems 2 and 3 handle 1.

19
Whats hard to code? - 3

• Use of UNIX /tmp directory for random data files
• Advantage cleaned out by OS
• Youre not required to do this, but its the
  right way
• If you do this, must generate a unique file name.
• Good news you dont need to do this.

20
Whats hard to code? - 4

• Unexpected end-of-file
• What if the different output files have different
  numbers of values?
• Then hit end-of-file on some but not all
• Suggestion get a version running that handles
  the case where all files have the same number of
  values and make sure that works.
• Then add functionality. But dont break anything.

21
Testing term project - 1

• No test data will be provided its up to you!
• Unit testing is required. So you must provide a
  driver and test data for each unit.
• Are any stubs required?
• To test your program, you will need to have
  several programs for it to run.
• Consider using existing programs.
• If you write them, make them as simple as
  possible as long as you can use them to test your
  code thoroughly.

22
Testing - 2

• Consider programs, each consisting of one line
• pgm1 cout
• pgm2 cout
• pgm3 cout
• pgm4 cout
• etc. as useful
• How many requirements can you test using programs
  like these?

23
Announcements

• Be sure you look at code examples on class web
  site
• Exam 2 is scheduled for Dec. 1
• Will have short take-home part and in-class parts
• Will discuss in class Nov. 29.

24
Topics

• Designing in teams
• Design script
• Implementation
• Implementation script

25
Comments on team design

• Not easily done by large group
• Some believe all good designs are done either by
  one individual or at most by a very small team
• Design can start with brain-storming session
• All team members have input and contribute ideals
• Then 1 or 2 people create the design

26
Design completion details

• Goal Inspection team can determine correctness
  of design
• Programmers can produce the intended
  implementation directly from the design and their
  background knowledge
• Sometimes reference materials may be needed
• And domain knowledge

27
Design standards

• Naming conventions
• Interface formats
• System and error messages
• Design representation notations

28
Levels of design

• Common levels
• System
• Subsystem
• Product
• Component
• Module
• For term project, you only need
• System (mostly done)
• Module (for each selected module)

29
Design goals

• Reuse
• Depends in part on standard documentation
• Usability
• Need to review design from perspective of all
  people who will use the software
• Testability
• May choose one design over another

30
Design script - 1
31
Design script - 2
32
Design script - 3
33
Standards

• Design standards
• Let's assume pseudocode is good enough
• Use another if you prefer
• Coding standards
• What we have is good enough
• Size standards
• Max size of a single component?
• Defect standards
• What we have is good enough
• Standards need to be reviewed and changed if they
  don't work
• But not this semester

34
IMP script - 1
35
IMP script - 2
36
IMP script - 3
37
Some goals/guidelines

• Design time coding time
• Design review time 50 of design time
• Code review time 50 coding time, preferable
  75
• You should find twice as many defects in code
  review as compile
• You should find 3 defects / review hr.
• Review rate