CS439 Project Information

Spring 2023

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:

counter-intuitively two programmers working together at one keyboard produce about as much functionality as two programmers working apart at two keyboards,
the code produced in this manner is of higher quality than individually programmed code, and
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:

Design, Design Communication, and Documentation
Test Cases

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 report a grade discrepancy, you must do so within 48 hours 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:

Nothing yet! Please check back.

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	Jan 27	Feb 8
Project 1: Threads	Understanding interrupts, thread state, and thread scheduling Detailed Rubric	2-3	Jan 30	Feb 10	Mar 1
Project 2: User Programs	Understanding how user programs interact with the OS Detailed Rubric	2-4	Feb 13	Feb 20 (stack)/Mar 3 (code)/Mar 6 (code reviews begin)	Feb 23 (stack)/Mar 11 (project)
Project 3: Virtual Memory	Understanding paging, page replacement, and other virtual memory concepts Detailed Rubric	2-4	Mar 6	Mar 10 (data structures)/Mar 31 (project)	Mar 20 (data structures)/Apr 19 (project)
Project 4: File Systems	Understanding file systems, including directory structure, file growth, and multithreading Detailed Rubric	2-4	Apr 3	Apr 21 Note that slip days are not allowed on this project.	May 2

*For Project 0, we will assign partners. Please watch for further details about that process.