COP 3503 - Computer Programming Fundamentals for CISE Students 2

General info on projects

• Submission formats and filenames:
  Submissions should be tar or rar file with source code and documentation. Your files should be named as follows (in all these, "name" must be your last name first initial):
  source header: COP3503su14_Proj1_name.h
  source implementation: COP3503su14_Proj1_class_name.cpp
  source application: COP3503su14_Proj1_main_name.cpp
  installation: COP3503su14_Proj1_README_name.txt
  user documentation: COP3503su14_Proj1_UserDoc_name.*
  programming documentation: COP3503su14_Proj1_Report_name.*

  You may have multiple header and/or implementation files (usually named for the class(es) they implement), but only one application (unless you want to include a test harness for your functions).
  example:my submission for project 2 would be
  COP3503su14_Proj2_multisetImpl_NewmanR.h - header file
  COP3503su14_Proj2_misc_NewmanR.cpp, COP3503su14_Proj2_multisetImpl_NewmanR.cpp - implementation files
  COP3503su14_Proj1_main_NewmanR.cpp - application file
  makefile - makefile with target compiling project 2 on thunder
  COP3503su14_Proj1_README_NewmanR.txt - README with directions on how to compile and run
  user documentation: COP3503su14_Proj1_UserDoc_NewmanR.pdf - A page or two on how to use the program and what it does
  programming documentation: COP3503su14_Proj1_Report_NewmanR.pdf - A few to several pages on what the program does, how it does it, how the code is organized, test cases and results, known bugs,comments on performance (time and space), discussion of trade-offs made.
  Programming documentation must also cover testing - how do you know your code works? Test cases, expected results, and actual results should be included. You may use the script command as noted elsewhere to show user interaction.

• Documentation clarification:
  There are three types of documentation that every project requires:
  • User documentation - what the system does and how to use it
  • Admin documentation - how to install the system and what resources it requires
  • Programmer documentation - how the system does what it does and how you know it
  On Unix/Linux/etc. systems, user documentation is done through man pages (type man man to see). I do NOT require you to learn enough nroff to write man pages, but something along those lines is appropriate for user documentation.
  For admin docs, the README.txt file suffices. It does not need to be very long (unless it does).
  The programmers documentation is usually in three forms: comments in the code, a makefile, and a separate report ("theory of operation"). In these, you explain how the code is organized (the code structure, including functions, objects, methods, etc., as well as any variables, user defined data types, etc.), and how it works, so that another programmer could maintain/extend/modify your code. This may be YOU a year or more later, so it is worth doing a good job on this. Most of the detailed explanation should be in the form of comments in the code, so the report just needs to give the big picture and highlights of anything special or unusual. The report should also include test cases with expected results, and info on what the actual results were, along with a list of known bugs (if any).
• Reading assignments made on Sakai as assignments are NOT graded and do not require a submission. However, if there are questions you have about that chapter or the lecturers, please DO email me with them.
• You may have noticed that the deduction for late submissions is smaller than you may be used to (e.g., no late submissions accepted, or 10% or more per day late). I am doing this so that you will be encouraged to complete a project rather than submit a broken one - I think you will learn more that way. HOWEVER, do NOT abuse this privilege! Repeated late submissions will result in revocation of this grace on an individual basis.
• Note that points deducted for late submission and otherwise failing to follow directions are independent of the points of the rubric - we expect you to follow directions and turn stuff in on time, and you will lose points if you don't.
• Your submitted files MUST follow the naming conventions noted in Project 1. We WILL deduct points for having the annoyance of renaming your files.
• Good programming style is required - this is one example, but your code must be readable and conform to general good coding standards
• You must submit source code (.cpp and .h files), README.TXT, and report (.txt, .rtf, .doc, .docx, .pdf) files. Do NOT submit .exe or .o files
• Rubrics for undergraduate software projects will be used generically. Specific rubrics for functionality and non-functional requirements will apply to particular assignments.
• Eclipse Tutorial may be helpful
• All projects will use the CISE Unix systems for testing unless otherwise noted.
• All projects are individual unless otherwise noted.
• You are encouraged to discuss the projects with each other and to dig up resources on the web; however, DO give credit to the sources that helped you and DO NOT copy code directly from any source.

Projects

Project 4 - Extensions - due Tuesday 8/5/14, no late submissions after 8/8/14.
This is a GROUP project, meaning you will get NO CREDIT if you do not participate in a group before submitting it.
• Project 3 - Dinner Plans - due Friday 7/18/14
• Project 2 - Multiset Class - due Tuesday 6/17/14
• For Project 1, do NOT use the library Set class - roll your own.
• Project 1 due date is moved back to Fri. 5/30/14.
• Project 1 is due Tues. 5/27/14. See Sakai assignments for details.
• If you do not have a CISE computer account, go to https://register.cise.ufl.edu/ to apply for one.

Homework Assignments

• Homework 3: Implement Towers of Hanoi. Due Friday 7/25/14.
  
• Homework 2: Implement mergesort. Due Tuesday 7/8/14.
  Your code read in a sequence of integers in random order from cin and print to cout the same numbers in sorted order, one per number per line.
  Work in groups for this assignment according to the groups I assign.

Homework general information

• Homeworks will only be accepted from teams.
• Teams must be between three and four students each, which I will assign.
• All students on each team should attempt to solve every problem on their own first.
• Everyone on the team will receive the same grade.
• Your homework papers must have on them:
  • the class prefix and number,
  • the date,
  • the assignment number,
  • the problem numbers,
  • your group number (which I will assign)
  • the printed names of each team member in last name alphabetical order, and
  • an indication of which members played the special roles below.
• Team roles include recorder and checker, with each team member required to rotate through the roles (i.e., no member should fill role X i+1 times until every team member has filled role X at least i times).
  Each team will decide which member will fill each role each time.
• Your papers should be typed and in PDF, doc, docx, txt, or rft format. Illegible writing will incur penalties at the discretion of the TA. This is the responsibility of the recorder.
• The checker is responsible for checking the completeness and correctness of the answers and conformance to format.
• Only turn in one version on-line; the Recorder is responsible for this duty.
• If you have a team member who is not performing, you should email a note to this member indicating the problem and cc it to the instructor and the TAs.

  If the member fails to meet obligations again, then you should indicate this on the assignment submission and you will be allowed to petition to reform the group.

Submissions