Academic Integrity and Grading Policy

  1. Policy Scope:

    This policy is used for both Core Courses for the Software Track, e.g., Software Modeling and Analysis and Object Oriented Design.

    For the other courses I teach, e.g., Internet Programming, Distributed Objects, and Design Patterns the grading policies are designed for each course's specific content and will be explained at the beginning of each class.

  2. Academic Integrity:

    All courses taught at Syracuse University are subject to it's Academic Integrity Policies.

    Spefically, for my courses you MAY:
    • Discuss our projects with me, with the TAs, and with your classmates and friends.
    • Use any of the code you find on this website as part of your projects.
    • You are encouraged to use code placed in the ProjectNHelpSxx folders, where xx is the current semester.
    • You may use documents placed in the presentation folders and BestProject folders in this website for ideas only.
    You may NOT:
    • Submit a modfication of another student's project work.
    • Work together on shared code you both submit.
    • Submit any code from the internet.
    • Use any document text taken from the web without full and complete attribution. That means that EVERY piece of text is enclosed in quotes and is given a footnote with the url of the original text.
    • If you use my code from the website as part of your project you MUST, if you have made any modifications - even one character - list yourself as the author and me as the source. If you have not made changes of any kind, you list me as the author. These citations are part of the code's prologue, at the beginning of the file. You will see several examples of that in class.
    • Do NOT place any project submission materials on GitHub or other public website until you have graduated from our Program of Study.
    • Should you and one or more other students submit the same code, other than my code from the website, you all will receive zero for that part of the code, and a grade no higher than C (equivalent to 2.0 gp).
    • If we detect that has happened more than one time, you will be cited to the SU Academic Integrity Board.
  3. Grading Policy:

    Grading is governed by gradesheets for both courses. These will be discussed at the beginning of each course.

    • CSE681: OCD grade sheet and Code grade sheet
    • CSE687: Code grade sheet
    • For all code projects you will get credit for functional requirements only if your project output demonstrates them clearly. You will get no credit for a functional requirement you have implemented, but not demonstrated, even if you show that to one of the TAs. For Project #2, CSE681, Fall 2013 the functional requirements are #2 - #6.
  4. Late Fees:

    You will be allowed to submit projects after the due date. However, for all but the last project you will lose one point per day late. Your project submissions are time-date stamped by the upload script. If the date stamp is N days after the due date you will lose N points, even if the submission time is at 12.01 am.

    The last project incurs a 5 point per day late fee since we have a very tight schedule to get grades to the registrar after the last class.

  5. How we Grade Projects with Code:

    1. TA will open student's project zip in an empty folder in some arbitrary position in a grading machine directory tree. Note that this implies that your code must use relative paths for any file manipulation and your test files must reside in a directory within your project structure.

      Do not ever write output into files on some absolute path. That may not work and if it does will clutter our grading machines with junk. You will lose 3 design points if your program does this.

    2. TA will type "compile" so student's compile.bat will build project. If that fails, 5 points are deducted and grading stops until student fixes and resubmits to TA.

      Please include your email in all prologue blocks at the beginning of each package. That will let the TAs contact you quickly about things like this.

    3. Type "run" so students run.bat will execute project, supplying whatever command line arguments are necessary to execute successfully. If that fails, 5 points are deducted and grading stops until student fixes and resubmits
    4. Scan the resulting output and deduct points for each functional requirement not demonstrated, marking the deduction on a project statement, included in the student's graded package. Students will not get a chance to fix any failures in this and the next parts. The TA will make a screen shot or redirect output to a file, and mark errors or omissions there as well as on the grade sheet.

      Note that this part implies the student has supplied a set of test files, if needed, and provided program instructions to process those files. Here, program instructions means statements in your program. We will ignore any readme files that ask us to do "special things" to get a submission to work. Your batch files and executive design should take of all those things.

    5. The TAs will, when appropriate, empty the student's test file folder and copy in a new set that may stress the application. The TAs will deduct points for each functional requirement not met in this test, but that will not exceed 10 points deducted. Note that this deduction is added to deductions from the previous item. The TAs will clearly indicate on the grading package which points were deducted for stress tests, if any.
    6. If one or more unhandled exceptions occurs while running the student's project 5 points will be deducted in addition to deductions for not demonstrating requirements. If an exception prevents demonstration of all requirements the student will be given one chance to fix and demonstrate to the TA to get points for the missing requirements. Note that TAs will not allow use of new code - the student will have to fix the submitted code in the prescence of the TA. This fixing will be allowed only to remove an exception so further output can be observed.
    7. TA will open project in Visual Studio 2015 and will inspect to see if all packages are structured properly (this will be discussed in class) and evaluate the style and design of the code.
    8. The first page of the grading package will be a gradesheet marked with deduction totals. The second page will be a copy of the project statement with points deducted on requirements that are not met so you can see exactly where you lost points. The third page will be a screenshot or redirected output which may have annotations showing where errors occur. The fourth page will be a summary of size and complexity analysis for your code.

      You can measure this yourself by running the VisualCodeAnalysis program on your code. That is also provided in a folder named "CodeAnalyzer" in the course folder. Note that you will need both CodeAnalysis.exe and VisualCodeAnalysis.exe on your path.

campus at night