Deliverables

No folders, cover sheets, plastic containers. Just assemble the pieces of paper and staple them together and put it on the desk at the front of class room before class starts.

Do not worry about nice fonts, heading, decoration, or dingbats. I'm only interested in the text plus occasional diagrams.

Emergency delivery: use EMail and copy/paste your work into your message.

Style

Keep it simple. Aim for these properties
• Clear
• Reliable
• Economical
• Amendable
• Testable
• Elegant
Note: these qualities spell: CREATE.

Dead Lines

The deadline in the [ schedule.html ] are hard time boxed deadlines. You stop and hand in what ever you've got at the deadline even if you did not achieve every thing you wanted to in the iteration. Late work is worth zero.

Documentation

You should document who you are, what you are doing, and any help you get. Documentation should be included in the source code as far as you can. At the minimum each program must contain comments that identify who did the work and which project the program is tackling. Initially you can hand in informal documents but you will soon be handing in source code. Use the template [ project.cpp ] to get started.

You don't have to hand in perfect work ... but you must document any errors (compilation, run-time, etc) so that I can help you fix them.


(P1): Vision. What do you want the computer to do? Who would it help? How would it help them? Use the following template to get started:

 	To help <user> by <doing something> ....

This deliverable can be hand written or prepared using a computer.


(P2): First Use Cases and tests. Review your vision and my comments on it. Make a list of things that the user might want to do with your software. These are use cases. Pick one and write a simple scenario describing step by step how the user gets what they want in terms the user can understand.

Map this scenario into a main() C++ test program that simulates this interaction using std::cin and std::cout. Make it work or document the error.
(P3): First Detailed plan Review my comments and fix the program.

Write scenarios for some other use cases.

Hand in both. While waiting think about the kinds of objects your program will need to fulfill the scenarios.
(P4): First Program: input, compiled, ... Hand in a test main() program that exercises


(P5): First fixed program. Use my comments to fix the errors and bugs.
(P6): Add a feature.


(P7): TBA


(P8): TBA


(P9): TBA


(P10): TBA

How to get a bad grade

Rushing to print out the work at the last minute and arriving late is likely to cost you all the points.

Deliverables

Hand in a print out of the source code of the programs. Print, staple the pages, and hand in. No cover sheets or folders. Note: all source code should start with the identifying information. In an emergency you could send the code (ASCII/.txt) with a subject like these

 	cs201/P1

to my college EMail address.

Start Early!

Look for this file on the CS201 web site: [ project.cpp ] as a starting point. Download and/or save it. Edit in your name. Use it to get started on each project. All the projects in this class can start form this file.

Grading

There is absolutely no extra credit given for choosing a difficult project. Good programmers don't let their ego make things difficult for themselves: always do the simplest thing that can possibly work.

Advice for Project Work

Compiling and running projects

Compiling project code can be done by hand in a terminal window as shown in the classes or using the techniques demonstrated in the labs. Avoid using any software that costs you money.

In a terminal window

---

Simple programs can be compiled run and tested with a single command on our computers:

 		Q p1.cpp

if the code is in file p1.cpp in your current working directory.

On other systems you may have to do the steps in 'Q' by hand:

 		g++ -o p1 p1.cpp

will compile it and

 		./p1

will run it. You can repeat the last compilation by typing

 		!g++

into a terminal or use the arrow keys.

Or, for more complex projects with code in many files, you can create a Makefile by using any UNIX editor that contains lines like this

 test: p1

 	./p1

 p1 : p1.cpp

 	g++ -o p1 p1.cpp

(be careful to use the <Tab> key to indent the commands.

---

Then the command

 		make test

will update p1 and then execute it for you.

Warning -- Do It Yourself

You can ask the teachers for help. Anything that looks like another student's work or a file downloaded from the Internet is likely to get a score of zero (0) for plagiarism. We have several tools that spot files copied from the Internet.

Each project is matched with an examination. In the examination you may have to answer questions about your latest project.

Recently, in CS201, someone desperately downloaded code from the internet that sounded like it might solve the problem. It didn't. It got zero.

Again, in a recent Comp. Sci. course, one student got some code from his brother at another university and then let six friends copy it and make small changes. Six students handed in six variations of the code. It was a solution to a different problem. They all got zero.

University Policy on Plagiarism

Please read page 52 of the catalog.

Do's and Don't's for Projects.



1. Put your name and the project vision as a comment in the code.
2. Download this file [ project.cpp ] as the starting point for a project.
3. Do the simplest thing that can possibly work.
4. Look out and take note of any productivity and quality tips I mention in class or that are in the book.
5. Put most of the documentation as comments in the code.
6. Explain how a user uses the program -- what do they do and what do the get out of it.
7. For complicated steps: write an algorithm (as a comment) first and then code it.
8. Use variable and function names that say what their purpose is.
   No spelling errors in variable names, outputs, or comments. Kate can check spelling for you. The command ispell filename.cpp will help if you use vi or emacs.

9. When you get to classes: use [ class.cpp ] as a model and outline.

10. When you get to functions: use [ function.cpp ] as an outline with comments defining the function.



THINK. If you rush into code and patch it until it works you may score less than someone who takes time to think about the problem and possible solutions before writing the code. You can make notes using an editor. Start with: What are inputs and outputs? and/or the givens and goals? and/or the before and after conditions? How are these connected? Make notes on this analysis of the problem. What are some possible ways of solving it (designs or algorithms)? Choose one. Turn your notes into comments at the top of a program.

Make it Meaningful. It is up to you to use meaningful identifiers and comments that make it clear why the code is going to work. Don't hand in a separate algorithm or structure chart. Instead your file should include comments that show the design. A function definition should start with a comment saying (1) what it assumes and needs, (2) what it produces or guarantees, plus (3) a very brief algorithm. Make it clear and correct before you make it fast. Check all code before I grade it. If you have a bug: Add comments about the symptoms... remove the comments when fixed. If I find uncommented errors you will loose points. If I find things that I can't understand then you will also loose points.

Most Errors occur when people (1) misunderstand the problem, (2) think of efficiency before correctness. Real problems are not obvious and are not clearly specified. The descriptions of the programs in the book are like this. There are several different programs that will fit what the book asks you to do. I leave the interpretation of them to you yet: (1) K.I.S.S. (= Keep It Simple!). (2) Demonstrate the features and topics described in the book and course at that time. (3) If in doubt A.S.K. (= Always Seek Knowledge). (4) Document (in comments) how you interpret the problem(Analysis)

Always Seek Knowledge (ASK)

I expect you to come and talk to me or other teachers about projects. You should be careful about talking to other students, however. They do not know enough to give you good advice. Also beware searching the Internet -- you'll probably find a solution to a different problem.

Document It As You Go

Real problems don't have obvious solutions. Whether you know what the code will look like or not add a comment that says what the program must do -- you can copy the description in the book. This may give you an idea. If not think up a special case that you can see how to solve. Use comments to describe the special case and how it case is solved. Make it compile! Add a simple output to see if the algorithm will work -- nothing else. It will probably have errors. This is normal. Declare variables and recompile and test. Add initial values. Test until it runs. Add comments describing an algorithm. Write code implementing the algorithm. Test.

Divide and conquer

Develop code in small iterations. Tackle one complication at a time. Test and retest. Rerun the previous tests.

Don't let the sun rise on bad code!

When the current version passes all tests, look for ways to re-factor code. For example use the DRY ( Don't Repeat Yourself ) rule to spot code that can be put in a loop or functions, etc.

Stop!

Stop before you are about to run out of time or when it does every thing that the book asked for.

How to Fail a Programming Assignment

Carol Edmondson at the University of Tasmania has documented the following techniques students have used to fail her courses:

1. Don't submit the assigned work.
2. Submit the work late.
3. Submit the same document as your friend.
4. Submit something you found on the web.
5. Use Email/News/etc to invite someone else to do the work for you.
6. Collect random pieces of code and put them in a file.
7. Submit a program that doesn't compile without comment.
8. Submit a program that produces a run-time error without comment.
9. Submit a program that only works on the given tests.
10. Submit a program that does not meet the specification without comment.

Any of the above can loose you points.

Working at home with SSH access

You can work at home but do not spend money on a C++ system. (1) We require work to be work with the free and standard Gnu C++ system. (2) The expensive stuff adds complications to your code for no added value. The department and the Computer Science Club can provide you with software if you ask.

You can access our system by using the same system that I have in the class room and office. This is the free Windows SSH client at: TBA Download and install the latest SSHWinClient-3.x.x.exe file. Connect it to

        jbh3-1.csci.csusb.edu

and log in. You then will need to login to a lab computer like this

 		ssh jb358-10

(you can use any of these machines from JBH3-1).

You won't be able to do graphic programs or use KDE to make things easier. A key rule:

---

1. Tap Enter to end each command!

---

The following UNIX commands work well:
Table

Command	Purpose
cat >f	Upload or input a file called f. You can type in the code or copy/paste it from your machine. End with Enter and Control/D
cat f	List the file f on your screen.
g++ -o p p.cpp	Compile a program called p
./p	Execute/run a program called p in this directory(.)
make t	Follow a recipe in Makefile to make t
cd d	change working directory(folder) to d
pwd	Print working directory
ls	List the file names in this directory
file *	List the files
mkdir d	Make a directory called d
more f	Display a file f one screen at a time
rm f	Remove a file (dangerous....)
mv f n	Change f's name to n, or move it to a directory
cp f n	Copy f to file n
pico f	Edit a file called f (easy to use but not powerful)
vi f	Edit a file called f (powerful but not easy to use)
emacs f	Edit a file called f (powerful and I can't use it)
lynx u	View a web page with URL u while on JBH3-1.
links u	View a web page with URL u.
w3m u	View a web page with URL u.


(Close Table)

. . . . . . . . . ( end of section Notes on Projects for CS201) <<Contents | End>>

Abbreviations