Home CS439



CS439 Virtual Memory Project Rubric



For longer explanations of the categories and more detailed information about the grading criteria, please visit the Grading Criteria page of this website.

Virtual Memory Project Detailed Rubric

Project Component
Level 5
Level 4
Level 3
Level 2
Data Structures, Design, and Design Communication
  • Proposed use of synchronization constructs demonstrates an understanding of their intended purpose and use.
  • No race conditions or concurrency errors revealed when design is considered.
  • Parallelism is not unnecessarily limited in proposal.
  • Data structures and memory accesses are designed to be correct and efficient.
  • Proposed eviction and page replacement algorithms will manage the frames and swap space correctly and efficiently.
  • Proposed page allocation to the process via demand paging and stack growth is correct and efficient.
  • Data Structures and Design document clearly and succinctly describes proposed code function and answers the given questions clearly and succinctly.
  • Proposed use of synchronization constructs demonstrates a satisfactory understanding of their intended purpose and use.
  • Two or fewer race conditions or concurrency errors revealed when design is considered.
  • Parallelism is sometimes unnecessarily limited in proposal.
  • Data structures and memory accesses are sometimes not designed to be correct and efficient.
  • Proposed eviction and page replacement algorithms usually manage the frames and swap space correctly and efficiently.
  • Proposed page allocation to the process via demand paging and stack growth is usually correct and efficient.
  • Data Structures and Design document satisfactorily describes proposed code function and answers the given questions clearly and succinctly.
  • Proposed use of synchronization constructs demonstrates an unsatisfactory understanding of their intended purpose and use.
  • Five or fewer race conditions or concurrency errors revealed when design is considered.
  • Parallelism is often unnecessarily limited in proposal.
  • Data structures and memory accesses are often not designed to be correct and efficient.
  • Proposed eviction and page replacement algorithms sometimes manage the frames and swap space correctly and efficiently.
  • Proposed page allocation to the process via demand paging and stack growth is sometimes correct and efficient.
  • Data Structure and Design document unsatisfactorily describes proposed code function and answers the given questions clearly and succinctly.
  • Proposed use of synchronization constructs reveals a lack of understanding of their intended purpose and use.
  • Many race conditions, concurrency errors, or a failure to use synchronization at all revealed when design is considered.
  • Parallelism is unnecessarily limited in proposal.
  • Data structures and memory accesses are not designed to be correct and efficient.
  • Proposed eviction and page replacement algorithms rarely manage the frames and swap space correctly and efficiently.
  • Proposed page allocation to the process via demand paging and stack growth is rarely correct and efficient.
  • Data Structure and Design document incorrectly or fails to describe proposed code function and answer the given questions clearly and succinctly.
Design and Documentation
  • Use of synchronization constructs demonstrates an understanding of their intended purpose and use.
  • No race conditions or concurrency errors revealed when visually inspected.
  • Parallelism is not unnecessarily limited.
  • Data structures and memory accesses are always created and/or managed correctly and efficiently.
  • Eviction and page replacement algorithms manage the frames and swap space correctly and efficiently.
  • Page allocation to the process via demand paging and stack growth is correct and efficient.
  • Code follows all structure and formatting guidelines, including those provided for the design document.
  • Use of synchronization constructs demonstrates a satisfactory understanding of their intended purpose and use.
  • When visually inspected, reveals two or fewer race conditions or concurrency errors
  • Parallelism is sometimes unnecessarily limited.
  • Data structures and memory accesses are sometimes not created and/or managed correctly and efficiently.
  • Eviction and page replacement algorithms usually manage the frames and swap space correctly and efficiently.
  • Page allocation to the process via demand paging and stack growth is usually correct and efficient.
  • Code follows most structure and formatting guidelines, including those provided for the design document.
  • Use of synchronization constructs demonstrates an unsatisfactory understanding of their intended purpose and use.
  • When visually inspected, reveals five or fewer race conditions or concurrency errors
  • Parallelism is often unnecessarily limited.
  • Data structures and memory accesses are often not created and/or managed correctly and efficiently.
  • Eviction and page replacement algorithms sometimes manage the frames and swap space correctly and efficiently.
  • Page allocation to the process via demand paging and stack growth is sometimes correct and efficient.
  • Part of the project is unimplemented.
  • Code follows few structure and formatting guidelines, including those provided for the design document.
  • Use of synchronization constructs reveals a lack of understanding of their intended purpose and use.
  • When visually inspected, reveals many race conditions, concurrency errors, or a failure to use synchronization at all.
  • Parallelism is unnecessarily limited.
  • Data structures and memory accesses are not created and/or managed correctly and efficiently.
  • Eviction and page replacement algorithms rarely manage the frames and swap space correctly and efficiently.
  • Page allocation to the process via demand paging and stack growth is rarely correct and efficient.
  • Parts of the project are unimplemented.
  • Code follows few structure and formatting guidelines, including those provided for the design document.
Test Cases
  • Code submission passes all of the test cases.
  • Code submission passes 91 or more of the test cases.
  • Code submission passes 71 or more of the test cases.
  • Code submission fails more than 28 of the test cases or doesn't execute.
Notes
  • Completing the a) planning and reflections and b) evaluation documents for this project will add 6/10ths to your design score, or the pro-rated equivalent. However, a grade higher than a 5 may not be awarded. Conversely, students who do not complete all documents may earn a maximum of a 4 on the design.
  • Failure to correctly submit a README will drop your test cases grade by a category.
  • Data Structure and Design documents that are over the character limit will earn at most a 3, and they may earn a 2, depending on how far over the character limit.
  • Turning in the skeleton code or your Project 2 code base earns a design document score of 1.
  • Be certain to review the General Grading Criteria that applies to all projects.
  • You may report a grade discrepancy if you feel that we overlooked information and thus made a mistake in evaluating your submission.