1 / 17

The Other Face

The Other Face. Chapter 15. What documentation is required?. Different levels of documentation are required for the casual user of a program, for the user who must depend upon a program, and for the user who must adapt the program for changes in circumstance or purpose. 1) Purpose.

dior
Télécharger la présentation

The Other Face

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Other Face Chapter 15

  2. What documentation is required? • Different levels of documentation are required for the casual user of a program, for the user who must depend upon a program, and for the user who must adapt the program for changes in circumstance or purpose.

  3. 1) Purpose • What is the main function, the reason for the program? ( not int main() )

  4. 2) Environment • On what machines, hardware configurations, and operating system configurations will it run? Q: “does this work on mac?”A: “does anything work on mac?”

  5. 3) Domain and Range • What domain of input is valid? • What ranges of output can legitimately appear?“..it’s voice activated?”

  6. 4) Functions realized and algorithms used • What exactly does it do?

  7. 5) Input-output formats • Precise and complete“…so wait.. what do I type here again?”

  8. 6) Operating instructions • Including normal and abnormal ending behavior, as seen at the console and on the outputs. “…is it supposed to do that?”

  9. 7) Options • What choices does the user have about functions? • Exactly how are those choices specified?“…can we do that?”

  10. 8) Running time • How long does it take to do a problem of specified size on a specific configuration? “…shouldn’t it be done by now? ..I think I broke it…”

  11. 9) Accuracy and checking • How precise are the answers expected to be? • What means of checking accuracy are incorporated? “that’s what it says.. but it doesn’t look right”

  12. Test Cases • Test that the program’s main functions with commonly encountered data • Test barely legitimate input data • Test barely illegitimate input data

  13. Flow Chart • Is the flowchart outdated?

  14. Flow Chart (Continued) • Has OOP and the lack of GOTO statements in modern programming helped outdate the flow chart?

  15. Self Documenting • i.e. Comment the code to death

  16. And the most useful documentation techniques mentioned are… • Use a separate job name for each run, and maintain a run log showing what was tried, when, and the results. • Use a program name that is mnemonic but also contains version identifiers (ie. AIM 5.9.3828) • Show relationship to book algorithms (ie. “This is a modified version of Dijkstra’s shortest path algorithm for multiple users”) • Label sections of code (ie. Includes, initializations, etc.) • Use indenting (format it properly) • If the code’s printed, possibly add control flow arrows by hand (from one function to another) • Use line comments only for things that are not obvious • Group things together whenever possible

  17. Das Ende • Fraggen?

More Related