CMSC 240: Systems Software Development

Spring 2023

Doug Szajda

    Course Syllabus

  • Instructor: Doug Szajda, dszajda@richmond.edu, 219 Jepson Hall, (804)-287-6671 (campus ext. 6671).
  • Meeting Times:
    • Lecture: TR 12:00 - 1:15 pm, Jepson 109.
    • Lab: T 3:00 - 3:50 pm, Jepson 109.
  • Office Hours
    • Tuesday, 4:00 - 5:00
    • Thursday, 10:30 - 11:45
    • Friday, 10:30 - noon
  • Recommended (but not required) Text:
    • Programming Principles and Practice Using C++ (2nd Edition) by Bjarne Stroustrup
  • Office Hours:Office hours are to be determined. Until they are set, if you need to see me, please email me or approach me after class, and we will set up a meeting time. You are also welcome to drop by my office any time (though there is no guarantee I will be there). If I am there, I am happy to meet with you. If you need to meet me at a time that I won't be in my office, then I'm happy to schedule a Zoom meeting. My UR zoom link is posted in a file on Blackboard. I don't put it on the web so that I don't get zoom bombed.
    Also, please be aware that though I usually keep my office door open when I am in my office, at times I may keep my door closed for either noise or climate control purposes. Either way, your visit is not an imposition, so please do knock (and don't assume I'm not there if the door is closed).
  • Course Summary: This is a 1 unit course on software systems development. It it intended to provide an introduction to the techniques necessary for the development of large-scale software systems. Primary among those techniques is a facility with the basic techniques of the "modern" C++ programming language. This language has been chosen as primary for this course because it introduces important features that you likely have not yet seen in any of your previous courses. Another principle goal is to intruduce you to the standard software tools used by system developers. Key topics include (but are not limited to)
    • Introduction to the modern C++ programming language, including
      • Classes, inheritance, and polymorphism
      • Pointers and dynamic memory allocation
      • The C++ Standard Template Library (STL)
      • Lambda Expressions
      • Copy and move semantics
      • Optional: Concurrent programming (threading and parallel computing support)
    • Introduction to Unix/Linux development environments and utilities
    • The development life cycle
    • Object-Oriented Programming and other design considerations
    • Patterns, reuse, and usability
    • Repository management
    • Testing, debugging, and static/dynamic analysis
    • Object-oriented design
    You will learn some of these tools via labs. Please understand that once we have had a lab covering a tool, it is assumed that you know how to use that tool!. So these labs are not just hoops to jump through. They introduce you to tools that you need to know how to use in subsequent assignments.
  • Additional Course Goals: The goals of this course, a foundational computer science major systems course, go beyond learning the material listed above. Additional goals include (but are not limited to):
    • Fundamental computer science principles: During the semester, we will see, in the context of software systems development, a number of principles used throughout computer science. I will emphasize these principles and you will be responsible for knowing them once presented.
    • Professionalism: In speaking with people who hire in industry and recruit grad students in academia, it has become clear that professionalism is one of their top concerns. Specifically, they are seeing graduates (from all institutions) who do not understand what professionalism entails. As such, it is an issue that needs to be addressed. In this context, professialism means considering questions such as (but not limited to) the following:
      • Does a person reliably and consistently show up to classes, appointments, and meetings, and do so on time (if you're one of those students who likes to wander in to class three minutes late, give that a thought)?
      • Does a person start projects and assignments in a timely manner?
      • Does a person work well in a group, performing their share of the work, considering the input of all group members, and respecting colleagues of all genders and demographics?
      • Does a person understand time management (e.g., a six week project requires six weeks of work, not a frantic couple of days prior to a deadline).
      • Does a person communicate well, and in a timely manner, with their supervisor(s)? This means, for example, that if a group project is falling behind, or a group member is not performing their share of the work, the supervisor is notified well before any deadlines, so that the issues can be sorted out and work reassigned sufficently early that deadlines can still be met.
      • Does a person meet deadlines? For example, a 5:00 submission deadline means just that. It does not mean 5:01 or 5:15. It means that if an important client is waiting to see a finished presentation at 9:00, the presentation is ready to go at 9:00 sharp (so, for example, the client is not waiting while people race around trying to set up the presentation).
      • Does a person do the appropriate background work (e.g., are specification documents read completely and thoroughly)?
    I will be explaining the level of professionalism I expect from my students, and the consequences (including grade penalties) for failing to meet those expectations. Attention to professionalism is required not only in this course, but in all subsequent computer science courses, so it would be best to develop these as regular habits.
  • Pre-requisites: CMSC 221 is a pre-requisite for this course.
  • Lectures: Notes for lectures are posted prior to class on the ``slides'' column of the course web page. I recommend that you make it a habit to download these notes before hand. Having the notes means less note taking on your part, which should allow you to better focus on the lectures (at least that is the theory). Please note that while the lecture notes are fairly comprehensive, their primary purposes are to free you from having to copy everything I write on the board, and to provide me with an outline of the topics I wish to cover. Thus what I write or say in lecture will not exactly mirror the content of the notes. Most important, there is a good deal of content not covered on slides. Often this "foundational CS material" arises naturally during lectures. You are responsible for this material, which is to say that in this course it is especially important to be listening carefully to everything I say in lecture!
  • Labs:

    This course has a formal laboratory component. You are expected to attend each lab for the entire 50 minute lab period. Some labs may require that students work in teams of two or more. Depending on number of students in the class and in each group, there may be times when there are groups of different sizes. Usually, you will be working alone (though you may discuss the lab with your classmates). If, however, there is a group lab and you must work alone (e.g., groups of size two, but an odd number of students in the class), then you will only be required to do this at most once.

    Labs are due at 5:00 pm on the night prior to the next lab (for this course, that means 5:00 pm Monday evening), unless I explictly provide a different deadline. Note that some labs are more like programming projects, so might require two weeks to complete. In that case I will explicitly inform you of this.

    For any group labs/projects, all members of groups receive the same grade, with the exception of the final programming project.
    One final note: almost all labs will require more than the 50 minute alloted time to complete, so please expect to have to spend significant extra time on the labs.

  • Reading: You are strongly encouraged to have read, prior to lecture, the material corresponding to the topic covered (should there be such material listed). Doing so allows you to raise question during lecture as the material is being presented. There are two advantages to this: 1) It allows your classmates to hear discussion of the issue, and 2) it potentially saves you a trip to my office during office hours. Most important, it's a better way to learn. Much of your learning in life will be accomplished via reading, so it's good to get in the habit now. Moreover, no lecture, no matter how good (or bad, as the case may be) will proceed at a pace that is perfect for every student (or any student, for that matter). Reading the material prior to lecture allows you to spend time on those concepts that you find confusing, and quickly pass over those concepts you find easy. And as said above, it allows you to ask questions about concepts that may remain confusing even after careful reading and consideration.
  • Attendance Policy: Regular attendance for the entire class time is expected! Over the past few years, CS faculty have observed a disturbing trend -- some students disappear for weeks on end. So that you are aware, CS program policy states that students who miss more than 4 total sessions (including lecture and lab) receive a grade of V for the course. I typically strictly adhere to this policy! I only mention this now because it shows how important we consider attendance to be in order for students to succeed in the course. (Please see some other reasons below.) Due to COVID, however, and the potential that some students may have to quarantine for an extended perioed, changes to attendance policies have been made. Regardless of these changes, however, be aware that you can still fail this course should you miss too many lectures and/or labs. To be clear, students who have to quarantine due to COVID or miss class for other legitimate reasons will not be penalized for their absence during those classes. Finally, if you should miss a class for any reason, you are responsible for obtaining class notes! (That is, I will not give you a private encore of the lecture).
  • Seating Policy: Though things are (at least for now) returning somewhat to normal, I am still required to impose assigned seating, and, per current university policy, to require that all students wear masks during lab and lecture. For this reason, I will allow you to choose seats during the first session, after which you will sit in those seats every day that you attend lecture (until university policy changes). There are no assigned seats in labs, because you will be working in different groups for each lab (and because university policy makes an exception for that situation).
  • Remote Attendance: I will not be streaming or recording lectures or labs this semester, so if you miss class, you are required to make up the material, get lecture notes, etc., on your own. For some lectures, there are lecture videos recorded from classes that occurred during the height of the COVID crisis. I will make those available on Blackboard as needed.
  • Laptop/Smart phone policy Please keep cell phones silenced and put away (not on the desk, or in your notebook, or in your lap (we can see you texting)). In the rare event that you need to be available for emergency phone calls, please talk to the instructor about it before class. If you take notes on your computer, please stick to course related work. Before class begins, please close all programs not related to the class including any email clients, Facebook, on-line shopping, ESPN, etc. You may think you are able to multitask, but the scientific evidence suggests otherwise. Also, multitasking on your computer is likely distracting to others behind or next to you (there is scientific evidence to support this too). For more information: href=http://www.sciencedirect.com/science/article/pii/S0360131512002254
  • COVID-related Policies:
    • We are facing a challenging situation in which all of us are called on to make a good faith effort to be flexible and to make decisions in the best interest of the community, including staying home when sick. Students who are sick should not attend class, will not be required to provide formal documentation from a health care provider, and, as mentioned above, will not be penalized for absences.

      However, students must:
      • Notify instructors in advance of the absence, if possible.
      • Contact the Student Health Center if sick.
      • Keep up with classwork if they are able to do so. If not, then immediately on return, work out a time-frame with me on when work will be submitted.

    • Masks: Current university policy does not require that students wear masks. Should this change during the semester, we will adjust our classroom rules as appropriate. If university policy changes so that masks are required, I will strictly enforce this! And I will require that all masks must be worn properly (as in, if I can see your nose, you're not wearing your mask) at all time in our class and lab spaces.

    • Be Flexible: University administrators, staff, and faculty have done our best to anticipate issues that may arise this semester. But the situation is, of course, fluid. For this reason, it is necessary that we all demonstrate some flexibility. Some of the policies in this syllabus may need to be changed to accomodate contingencies that arise. Please be aware of this, and prepared for what will likely be more change than required during a normal semester.

  • Grades:

    Grade Component Date Percent of Grade
    Midterm Exam Tuesday, February 28 15%
    Final Programming Project Due Thursday, April 20, 5:00 p.m (sharp!) 20%
    Labs N/A 45%
    Final Examination Tuesday, April 25, 2:00 - 5:00 pm 20%


    Final grades will be adjusted, if necessary, to reflect the following ideal as much as possible.
    • An ``A'' means that your knowledge of this material is exceptional. When you have to build on the material that you learned in this class in your future classes, then you will be able to do so easily.
    • A ``B'' means that you have a good understanding of most of the material, but may have some gaps in your understanding, or are not as comfortable with some aspects of it as you might be. As such you may want to review this material before taking more advanced classes. You will be able to apply the material in this class, but you may have difficulty doing so with some of it.
    • A ``C'' means that your knowledge of this material is average/mediocre. You will likely struggle to apply this material in your future classes, as you have struggled learning the material in this class.
    • A ``D'' means that you are not ready for future classes that builds on material from this class.
    • An ``F'' means that in addition to the conditions for a ``D'' grade, you also didn't try and/or failed to hand in work.
  • Exams: Both exams (one midterm, one final) will be in-class exams. The midterm will also have a "take-home" component. This may be in such a form that I ask you to write and submit C++ code, or, it may be in a form where I give you a short oral exam that requires you to write code. In the case of a written take-home portion, the exam will specify when the take-home code must be submitted (usually by 5:00 pm on the day after the in-class exam). The final exam will very likely have an oral examination portion. If you have to miss an exam because of an emergency, you should notify me prior to exam time for permission from me to take the exam at a different time. Of course, I am also a realist and human -- if there is an emergency situation that precludes your reasonably being able to notify me prior to the exam, there will be no penalty for that.
  • My ``exam discussion policy": Once a student has begun an exam, I will answer (for that student) only those questions that concern clarification of the intent of a problem. That is, I will not answer questions that seek to determine whether the problem was done correctly, or whether a particular approach is wise (or unwise).
  • Final Programming Project:This will be written in the C++ language, and must compile without warnings using the GNU g++ compiler and the -Wall flag on the department's linux machines (mathcs01 - mathcs06 and Turing). Programs should be submitted to me by sending an email to the appropriate submission email address with your single project tar file as an attachment, which will automatically load the submission to the appropriate Box folder. PROGRAMS NOT SUBMITTED TO THE CORRECT BOX FOLDER AND/OR PROGRAMS THAT FAILS TO COMPILE ON THE LINUX CLUSTER WILL RECEIVE A GRADE OF 0. Note that though you may write and test your code anywhere, when grading programs all that matters is how they compile and run ON THE LINUX CLUSTER , not on your laptop, tablet, etc.
  • Lab, Project, and Test Code Submission: If you have taken a course with me recently, then this procedure should be familiar. At the beginning of the semester I will put a file called ``submission_email_addresses.txt'' in the "content" section of the course Blackboard page (NOT the course web page, as I don't want the links to be public). All work should be submitted as a single tar or zip file. In order to submit work, you send an email, with your single submission file as an attachment, to the email address listed for that assignment. This has the effect of depositing your submission in the appropriate Box folder. Note that ALL submissions must include some indication, in the title of the submitted file, of who the submission is from. Such naming conventions will be made explicit in the assignment documents.
    SUBMISSIONS NOT PRESENT IN THE CORRECT BOX FOLDER AT THE SUBMISSION DEADLINE RECEIVE A GRADE OF 0. So, if you send email to my regular email, or submit your work using the wrong email address (so it ends up in the wrong Box folder), then it is treated as if you have not submitted the work.
  • Tar and Zip files: If you are not already familiar with these file types, you will be shortly. One note regarding submission of such files is that when I recieve one, all sumitted files must extract into the top level directory! There will be no exceptions to this. To be clear what I mean by this, let's assume you wish to submit a project that consists of three code files, foo.cpp, bar.cpp, and baz.cpp. When I unzip or untar your submission file, I should not have to navigate down six of seven levels of directories to get to your files. For example, I should not have to navigate down through User->JohnSmith->Desktop->c++->lab1->lab1 to find the three files. If you think I'm exxagerating, this is a real example of a submission I received (it's one of many, and not the longest example). To counteract this, if I receive something similar, I will divide your grade in half for each level directory that needs to be navigated through.
  • Moving files back and forth between your laptop and the department cluster: There are a number of ways of doing this (many students seem to find VSCode useful for both writing code and managing the different locations). The primary means of moving code and files back and forth, however, and something I require you to know, is via secure copy, abbreviated scp. SCP is a Linux command run on the command line. Instructions for using scp can be found on the "useful links" page off of the main course web page.
  • Two different kinds of Box folders! Know the difference! I use two different kinds of Box folders in this course (and in all of my courses). One class of folders is for work submission (in this course, that means labs, projects, and at times part of exams). Material is submitted to this class of folders by sending an email to a project specific address. Those addresses are contained in a file in the content on the course Blackboard page. Everyone in the class submits to the same project specific Box folder.
    The other class of folder are individual folders shared between myself and each student. The folder I share with you in this manner is visible only to you and myself (and possibly a grader, but we don't have one for this course). These individually shared folders are exclusively for grade forms! They are not to be used for submission of projects. If you accidentally place a project submission into your individual folder, I will not see it and will assume you have not submitted the project!
  • Extra Credit: There is none in this section of the course -- there is plenty of work to do without assigning extra stuff to push up your grade.
  • The Other Student Criteria: When grading tests and homework, I use the Other Student Criteria (OSC). All solutions must meet this. The Other Student Criteria states that a solution should provide enough written explanation so that another student in the class (who could not complete the assignment) could read the submitted material and, without asking questions, understand a correct answer.
  • The Myth of Grade Negotiation: I have noticed over the past few years a shift in the way a few students view grades on exams and assignments. A (somewhat vocal) minority of students view these grades as merely an initial offer in a process of negotation. That is a myth. The grade you recieve on assignments is final! The grades I assign are carefully considered. Attempting to earn an extra couple of points is a waste of your time and mine, as well as being orthogonal to the prime purpose of the course, which is to learn the material. I am very happy to meet to discuss assignments and exams so that you may better understand the material, but will not change your grade.
  • My "Managerial" Philosophy: I apologize for having to mention this, since almost all of you are adult enough to not need this clarification. Every once in a while, however, I encounter a student who tests the boundaries, and for that student, I like to have a few things in writing.

    My basic philosophy is this: You are adults. I treat you as if you are adults, and expect you to act as adults. For the 1 out of 100 students that does not understand what this means, here is a little clarification of some (though not all) of the ideals that this entails:
    • You begin assigned work in a timely manner (this includes reading).
    • You complete assigned work on time (this includes reading).
    • You complete assigned work and hand it in on time.
    • If an emergency arises (as they sometimes do) that precludes handing in work or taking an exam, you contact me before the work (or exam) is due.
    • You accept responsibility for your actions (and, as the case may be, your inactions).
    • Most important, just because some specific behavior is not mentioned here, that does not mean it's "OK" to engage in it. You know what reasonable expectations are for students, as do I. I treat you like adults and expect you'll act responsibly.
  • Incomplete Grade Options: There was a time a few years back when it was necessary for me to assign an incomplete grade only about once every two years, typically for a student who became ill late in the semester and needed to travel home to recover. It seems recently that there has been a rash of incompletes, to the point where no fewer than 25% of one of my CS 301 classes a few years ago required incompletes. So, I have had to revise my policy. There are only two reason why I will allow a student to receive an incomplete grade: they are ill and have to go home to recover (I expect verification from a doctor) or there is a death in the family late in the semester (I also expect to see verification, as unfortunately, there have been instances of students lying about this).
  • Collaborating on lab/programming assignments: Programming projects and labs may be discussed with others subject to the


    ``Empty Hands'' policy --- you may freely discuss ideas and approaches with other students subject to the restriction that each student must leave the discussion without any written or otherwise recorded material. In your lab/project write-up or source code, you must also document any person or source that you consulted for that project. Failure to comply with this policy will be treated as an Honor Code violation. Note that this policy does not apply to your lab/project group members, with which you are free to share materials.
    One final note: some of the programming assignments for this semester may have been assigned in previous semesters. While you may consult previous class members concerning projects, you are not permitted, under any circumstances, to receive or view either hard copies or electronic copies of all or parts of their project submissions! You can use your friends to get help, but they should not be providing you with their code (just as in an English class, you might discuss the works of Dickens with a friend, but should not use the paper that they submitted as the basis for your own submission).
  • Note: Many of the handouts, presentation slides, assignments, and exam problems used in this course use material borrowed from Professors Lawson and Denny. I am particularly grateful to them for generously allowing me to use their material as the basis for my material (including, in many cases, simply using their material word-for-word).
  • Letters of recommendation for graduate school: Since most students take this course well before their senior year (if they are CS majors), it is a bit early to discuss reference letters. But in case you might be considering graduate school in the future, and may want me to write a letter for you, you may want to take a look at my policies on this. They can be found here.
  • Additional University Resources: If you experience difficulties in this course, do not hesitate to consult with me. There are also other resources that can support you in your efforts to meet course requirements.

    • Academic Skills Center(http://asc.richmond.edu): Academic coaches assist students in assessing and developing their academic and life-skills (e.g., critical reading and thinking, information conceptualization, concentration, test preparation, time management, stress management, etc.). Peer tutors offer assistance in specific subject areas (e.g., calculus, chemistry, accounting, etc.) and will be available for appointments in-person and virtually. Peer tutors are listed on the ASC website. Email Roger Mancastroppa (rmancast@richmond.edu) and Hope Walton (hwalton@richmond.edu) for coaching appointments in academic and life skills.

    • Boatwright Library Research Librarians (http://library.richmond.edu/help/ask/ or 289-8876): Research librarians help students with all steps of their research, from identifying or narrowing a topic, to locating, accessing, evaluating, and citing information resources. Librarians support students in their classes across the curriculum and provide individual appointments, class library instruction, tutorials, and research guides (libguides.richmond.edu). Students can contact an individual librarian (library.richmond.edu/help/liaison-librarians.html) or ASK a librarian for help via email (library@richmond.edu), text (804-277-9ASK), or chat (library.richmond.edu/chat.html).

    • Career Services (http://careerservices.richmond.edu/ or 289-8547): Can assist you in exploring your interests and abilities, choosing a major or course of study, connecting with internships and jobs, and investigating graduate and professional school options. We encourage you to schedule an appointment with a career advisor early in your time at UR.

    • Counseling and Psychological Services (caps.richmond.edu or 289-8119): Assists currently enrolled, full-time, degree-seeking students in improving their mental health and well-being, and in handling challenges that may impede their growth and development. Services include brief consultations, short-term counseling and psychotherapy, skills-building classes, crisis intervention, psychiatric consultation, and related services.

    • Disability Support Services:(disability.richmond.edu): The Office of Disability Services works to ensure that qualified students with a disability (whether incoming or current) are provided with reasonable accommodations that enable students to participate fully in activities, programs, services and benefits provided to all students. Please let your professors know as soon as possible if you have an accommodation that requires academic coordination and planning.

    • Speech Center (speech.richmond.edu or 289-6409): Assists with preparation and practice in the pursuit of excellence in public expression. Recording, playback, coaching and critique sessions offered by teams of student consultants trained to assist in developing ideas, arranging key points for more effective organization, improving style and delivery, and handling multimedia aids for individual and group presentations. Remote practice sessions can be arranged; we look forward to meeting your public speaking needs.

    • Writing Center (writing.richmond.edu or 289-8263): Assists writers at all levels of experience, across all majors. Students can schedule appointments with trained writing consultants who offer friendly critiques of written work.
Last Modified: August 19, 2019 Contact: Doug Szajda