The Other Face Chapter 15. What documentation is required? ► Different levels of documentation are required for the casual user of a program, for the.

Slides:



Advertisements
Similar presentations
Credit hours: 4 Contact hours: 50 (30 Theory, 20 Lab) Prerequisite: TB143 Introduction to Personal Computers.
Advertisements

The INFILE Statement Reading files into SAS from an outside source: A Very Useful Tool!
CS0007: Introduction to Computer Programming Console Output, Variables, Literals, and Introduction to Type.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Chapter 2: Problem Solving
Software Failure: Reasons Incorrect, missing, impossible requirements * Requirement validation. Incorrect specification * Specification verification. Faulty.
PSEUDOCODE & FLOW CHART
Chapter 2: Problem Solving
Documentation Letts Study Guide Information Systems - IT Chapter 19.
FIT FIT1002 Computer Programming Unit 19 Testing and Debugging.
Adapted from John Zelle’s Book Slides
Programing Concept Ken Youssefi/Ping HsuIntroduction to Engineering – E10 1 ENGR 10 Introduction to Engineering (Part A)
Good modeling practices AGEC 641 Lab, Fall 2011 Mario Andres Fernandez Based on material written by Gillig and McCarl. Improved upon by many previous lab.
1 CSE1301 Computer Programming: Lecture 15 Flowcharts and Debugging.
Copyright © 1998 Wanda Kunkle Computer Organization 1 Chapter 2.1 Introduction.
Program design example Task: Develop an algorithm expressed in pseudocode for a specified problem specified problem.
1 CSE1301 Computer Programming: Lecture 15 Flowcharts, Testing and Debugging.
Bret Juliano. Introduction What Documentation is Required? – To use a program – To believe a program – To modify a program The Flow-Chart Curse Self-Documenting.
CSEB114: PRINCIPLE OF PROGRAMMING Chapter 2: Problem Solving.
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
Using Dijkstra’s Algorithm to Find a Shortest Path from a to z 1.
Simple Program Design Third Edition A Step-by-Step Approach
Process Design (Requirements). Recall the Four Steps of Problem Solving * Orient Plan Execute Test These apply to any kind of problem, not just spreadsheet.
Instructor: Tina Tian. About me Office: RLC 203A Office Hours: Wednesday 1:30 - 4:30 PM or .
Systems Development Lifecycle Testing and Documentation.
Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also:
Python From the book “Think Python”
Exceptions Handling Exceptionally Sticky Problems.
Software Development Process.  You should already know that any computer system is made up of hardware and software.  The term hardware is fairly easy.
INTRODUCTION TO COMPUTING CHAPTER NO. 04. Programming Languages Program Algorithms and Pseudo Code Properties and Advantages of Algorithms Flowchart (Symbols.
Intermediate 2 Software Development Process. Software You should already know that any computer system is made up of hardware and software. The term hardware.
Introduction to Programming with RAPTOR
C++ Basics C++ is a high-level, general purpose, object-oriented programming language.
Algorithms & Flowchart
Lecture 2: Introduction to C Programming. OBJECTIVES In this lecture you will learn:  To use simple input and output statements.  The fundamental data.
Program #2 Cell Phone Usage ….Let’s start with understanding the problem!
Chapter 0 Getting Started. Objectives Understand the basic structure of a C++ program including: – Comments – Preprocessor instructions – Main function.
ME 142 Engineering Computation I Exam 2 Review VBA.
BMTRY 789 Lecture 11: Debugging Readings – Chapter 10 (3 rd Ed) from “The Little SAS Book” Lab Problems – None Homework Due – None Final Project Presentations.
The Other Face Or Why Document? By Chris Bradney Or Why Document? By Chris Bradney.
PROGRAM DEVELOPMENT CYCLE. Problem Statement: Problem Statement help diagnose the situation so that your focus is on the problem, helpful tools at this.
Structured COBOL Programming, Stern & Stern, 9th Edition CHAPTER 2 Cobol Language Fundamentals.
Submitted To: Rutvi sarang Submitted By: Kushal Bhagat.
Gold – Crystal Reports Introductory Course Cortex User Group Meeting New Orleans – 2011.
The Hashemite University Computer Engineering Department
Decision Maths 1 Shortest path algorithm Dijkstra’s Algorithm A V Ali :
GCSE ICT 3 rd Edition The system life cycle 18 The system life cycle is a series of stages that are worked through during the development of a new information.
1 The System life cycle 16 The system life cycle is a series of stages that are worked through during the development of a new information system. A lot.
CISC105 – General Computer Science Class 4 – 06/14/2006.
1 CSE1301 Computer Programming: Lecture 16 Flow Diagrams and Debugging.
Learning Objectives Today we will Learn: The different types of test data.
CS 115 Lecture 5 Math library; building a project Taken from notes by Dr. Neil Moore.
Unit 2 Technology Systems
INTRODUCTION TO PROBLEM SOLVING
How To Fix Lexmark Printer That Doesn’t Print?
PROGRAM CONTROL STRUCTURE
Introduction To Flowcharting
Numbering System TODAY AND TOMORROW 11th Edition
Repetition-Counter control Loop
An Introduction to Visual Basic .NET and Program Design
PRG 410 Competitive Success-- snaptutorial.com
PRG 410 Education for Service-- snaptutorial.com
PRG 410 Teaching Effectively-- snaptutorial.com
Unit# 9: Computer Program Development
VISUAL BASIC – CHAPTER ONE NOTES An Introduction to Visual Basic
Chapter 3 Classes and Objects
Structured Program Design
Multiple Selections (ELIF Statements)
Faculty of Computer Science & Information System
Suppose I want to add all the even integers from 1 to 100 (inclusive)
Presentation transcript:

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 ► What is the main function, the reason for the program? ( not int main() )

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?”

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

4) Functions realized and algorithms used ► What exactly does it do?

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

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

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

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…”

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”

Test Cases 1. Test that the program’s main functions with commonly encountered data 2. Test barely legitimate input data 3. Test barely illegitimate input data

Flow Chart ► Is the flowchart outdated?

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

Self Documenting ► i.e. Comment the code to death

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 ) ► 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

Das Ende ► Fraggen?