Home CS439


CS439 Project Information

Spring 2022

Overview

There will be five projects for this class, each emphasizing a different set of important skills. You will begin by writing a shell. Your other projects will exercise your knowledge of threads, user programs, virtual memory, and file systems.

The projects will be challenging. We hope they will also be very satisfying. The instructor and TAs will work to help you succeed. Although the scope of the projects is ambitious, we will provide a framework to guide your efforts and to ensure that you don't have to spend a lot of time building uninteresting "glue" code. Our hope and expectation is that everyone that works hard on these projects will succeed.

Group Programming Requirements

You will work on all of these projects in groups of two or more---the number of group members will be specified per project.

For most projects, you will be welcome to form your own group with someone(s) with whom you will work well. Your group must follow a pair programming methodology. In particular, all members of the team should work together to understand the problem, design the solution, enter code, and test the solution. For code entry, one member should type while the other(s) observes, detects tactical coding defects, and thinks strategically about the overall design. These roles must be frequently swapped.

We follow this methodology because studies [1, 2] suggest that pair programming works well. For instance:

  1. counter-intuitively two programmers working together at one keyboard produce about as much functionality as two programmers working apart at two keyboards,
  2. the code produced in this manner is of higher quality than individually programmed code, and
  3. in an educational setting both team members learn more than they would separately.
Note that for these projects, these advantages of group programming over disjoint work are especially likely to apply: the largest difficulty is in designing a solution. Please note that it is vital that all team members understand all aspects of the implementation. Also be aware that the exams will have questions that required intimate knowledge of the projects.

To facilitate group programming, you will be asked to submit a group reflection document at the end of each week a project is assigned, and a individual reflection document at the end of each project. These documents will help you evaluate the process of project creation, including what your group is doing well and what it is not. We hope that your group will be able to successfully navigate group dynamics even under deadline pressure. However, when problems arise, we encourage you to first try to reach a resolution through a group discussion, but we are here to assist should that fail.

For more information about pair and group programming in this class, please see the Pair and Group Programming Standards and Requirements page of this website.

Project Evaluation

The grade for project grade reflects the design of that project, the documentation and formatting of the code, whether the project successfully runs our test cases, and whether your group is able to clearly and succinctly communicate about the design of the project.

We will evaluate your project on two equally-weighted categories:

Projects will be evaluated on our EADB scale. Exact rubrics for each project will be posted with the project. Grades will be reported in two columns on Canvas: 1) Test Cases and 2) Design and Documentation. Test Cases grades are calculated by script and will often be released during the week following the project. Your design, however, is graded painstakingly by hand, as we work to evaluate your design and understand both your design document answers and how your answers reflect your code. Grading each group's design and the related documents takes approximately an hour and so, given the size of the class, design grades are released later. On this page, I've included an estimated date for us to have released your complete project grade. We will do everything we can to meet that time line, but unexpected situations do occur. We ask for your patience as we do our best to grade your projects fairly and accurately the first time.

Once the grades are released, if you have questions about your grade, you should consult the Piazza post for instructions about which of us to contact. If you would like to request a regrade, you must do so within one week of the grades being released.

For more detailed information about the grading criteria, please visit the Grading Criteria page of this website. For more detailed information about formatting expectations, please see the C Style Guide page of this website.

For additional project resources, including C, Linux, remote collaboration, and debugging guides, please see our resources page.

Have fun!

Announcements:

Turning in your code? Please look over the Turnin Checklist!

Schedule

Projects
 Objectives
 Required Group Size
 Group Registration Deadline
 Due
Grades Released (Estimate)
Project 0: UTCS Shell
 Become familiar with shells, fork(), exec(), and other systems concepts
Detailed Rubric 		2* N/A Feb 10 (code)/Feb 11 (design) Feb 21
Project 1: Threads
 Understanding interrupts, thread state, and thread scheduling
Detailed Rubric 		2-3 Feb 14 Feb 24 (code)/Feb 25 (design) Mar 10
Project 2: User Programs
 Understanding how user programs interact with the OS
Detailed Rubric 		2-4 Feb 28 Mar 7 (stack)/Mar 24 (code)/Mar 28 (code reviews begin) Mar 10 (stack)/Apr 5 (project)
Project 3: Virtual Memory
 Understanding paging, page replacement, and other virtual memory concepts
Detailed Rubric 		2-4 Mar 28 Apr 1 (data structures)/Apr 14 (code)/Apr 15 (design) Apr 4 (data structures)/May 2 (project)
Project 4: File Systems
 Understanding file systems, including directory structure, file growth, and multithreading
Detailed Rubric 		2-4 Apr 18 May 5 (code)/May 6 (design)
Note that slip days are not allowed on this project. 		May 16
*For Project 0, we will assign partners. Please watch for further details about that process.