Programming Projects
1. There are 'regular' programming projects and occasionally 'bonus' programming
projects.
2. Each student may do a maximum of four regular programming projects
during the semester. Many students only chose to do two or three.
(Remember there is a 200 point ceiling for this category)
3. After each student has done two programming projects and turned them
in, they are elgible to do the bonus programming projects (if any have
been set up). There is no limit on the number of bonus projects that may be turned in.
4. There is a limit of 200 points that can be earned via programming
projects. Points earned by doing bonus projects go into the
'bonus' category not the programming projects category.
5. Students should choose programming projects and bonus programming
projects from the prescribed list for Spring 2006. Occasionlly
students will have an idea for a project they would like to attempt.
In that particular case, you should talk to me first in order to
get my approval.
6. Due dates are strictly observed. See below.
7. Don't copy programs from anyone (and don't let anyone copy your code),
-- don't take whole projects from the web - that will earn you a failure
for the project.. You may take 'small' functions from the web or books
but be sure to cite these sources in your documentation. If you aren't
sure whether you can use something or not --ask me.
additional details below
I will give the class approximately five to eight different
projects concerning different aspects of cryptography.
These projects will be programming projects.
Any programs associated with each project can be
written in any language available on machines
accessible from your accounts. This semester no projects
should be written to run exclusively in a windows environment.
Occasionally I make exceptions to this rule but ask me first!
The programs will be graded in a manner similar to the way
that programs are evaluated in
beginning programming courses. Although you may talk about
these projects with your classmates, all programs must be
your own work. Copying someone else's code or allowing someone
else to copy your code will result in a 0 for the project
at the very least.
There is an emphasis on correctness,
style, readability and documentation
Turning in undocumented code is a sure way to
lose points. If the your program does not give correct
answers or has serious errors then no points will be
given.In some cases, (when your program is interactive),
I will ask you to demonstrate it to me and/or the teaching
assistant. Your completed project should be as close as
possible to a polished product.The number of points
assigned to a project depends on the project's difficulty
or in the case where the project is open-ended how much the
student has accomplished.
Consider the following requirements - they are important!!
1. At the very least each program needs a header comment which
explains what is being computed and with what algorithm.
This 'top header' also needs a simple directive for its useage.
You need to include instructions for compilation and execution.
Include comments on:
what platform(s) was this package developed and tested on? what platforms does this package run on?
What additional information is needed to run your project?
For example:
// "enciph.C" (Implementation of the Linear Feedback Shift Register)
// This program reads the input file (ciphertext) and enciphers it at the
// bit level using the linear feedback shift register method (8-stage).
// The taps used is: 1000 0001. This tapping is fixed and written into the
// code. The seed will be selected and entered in by the user by way of
// picking an integer between 0 and 127. User must record this seed (number)
// for deciphering (use the companion program: "deciph.C"). THE OUTPUT
// FILE WILL BE GENERATED AUTOMATICALLY AND WILL BE CALLED "cipher.out"
// Compile: CC enciph.C -o enciph
// Usage: enciph inputfilename
2. You must specify what type of input file is expected and
what type of output file will be produced. You can use
the following abbreviations --
A -- only alphabetic characters
AS -- alphabetic characters, spaces allowed
AU -- only alphabetic characters, upper case
AL -- only alphabetic characters, lower case
AUS, ALS above two with spaces
AN -- alpha numeric only, no other symbols allowed
ANS -- alpha numeric with spaces allowed, no other symbols
64 -- base sixty four input expected
T -- text file, any printing character allowed
B -- binary file, no restrictions
3. Included with your project should be a script (using the
unix script command or cut and paste) showing the compilation
and an execution of some of the sample input.
4. Projects are to be submitted by (1) email (use zip and/or tar
if you want) and (2) hard copy
Submission of Programming Projects
In order to turn in programming projects, students need to:
1. Send them to Dr. Stephens by email before 5:00 pm of the day of
the due date. Send as attachments. It's OK to zip and tar them.
2. Turn in a hard-copy version in class on or before the due date.
The hard-copy version should also include sample output.(see above)
3. Demo the program (if needed - if program highly interactive). In
order to demo your programs you will need to make an appointment.
These demos (which should last about 15-20 minutes) can be done
within two weeks after the due date.
For projects there are two due dates. Projects turned in
by the first due date receive no penalty. Projects turned in
between the first and second due dates receive an immediate
30% reduction in points. Projects are not accepted beyond
the second due date
even if they are near completion. These due dates will be
announced in class (and posted on the web page) for each project.
A little partial credit will be given to incomplete projects
turned in on the second due date. See
important dates.