About

Table of contents

1. TOC

Principles of Software Engineering

CSE 110 is a first course in software engineering. Relative to some other CSE courses, it is unusual:

• The course emphasizes group work: much of your grade will come from your contribution to your group, rather than individual work. You may do different work from other people in the class, and that’s okay! The goal is for you to serve your group as effectively as possible.

• The group work will be not be graded primarily on the basis of your technical accomplishments (although that will be a factor). Instead, the emphasis will be on using the techniques presented in class to further the creation of software that benefits users.

• In some classes, spending large amounts of extra time can benefit projects. However, software engineering is about predictability. A software team that works 12-hour days for a period of time can ship great software once — and then disband due to burnout, never to ship software again. More is not necessarily better. Of course, less is not better either!

Some students may have significant prior experience in software engineering. If this is the case for you, I invite you to both leverage your past experience and use the class as an opportunity to try out new methods.

Learning objectives

Upon completion of this course, students will be able to:

1. Work effectively in a team that uses an Agile development process.
2. Design and document software systems according to stakeholder needs.
3. Implement and debug complex software systems.

Online discussion

We will be using Slack for discussion and communication. We will invite you to a Slack workspace that you must join to collaborate with your team. We will not be using Piazza or Canvas for discussion so everyone can look in just one place.

Change Policy

I make significant changes to the course every time I teach it in response to changing student needs and a changing word context in which we write software. These changes mean that I may need to adapt the course as the quarter proceeds. Although I will try to stick to the plan as closely as possible, I reserve the right to make changes as needed.

Course Format and Schedule

• Class will be MWF 4:00-4:50 PM in Catalyst 125.
• Labs will be Thursdays 10:00 - 12:50 and 2:00 - 4:50 PM. If you occasionally need to attend the OTHER lab section (not the one you signed up for), that’s fine. You can attend any open lab spot, not necessarily the specific room you signed up for.
• Discussions will be Fridays 10:00 - 10:50 in Peterson Hall 110.
• The final exam will be Tuesday, December 8, 3:00 - 5:59 PM in Catalyst 125.

If you are sick, please do not come to class. No need for a doctor’s note; we’re all adults here.

Adding and dropping

Previous students in this course gave feedback that they wanted as much time as possible for the projects. In response to this feedback, I have moved the project start date very early: you will be working on the project by the first full week of class. You must fill out the team formation survey ON TIME at the end of week 1 to join a team. Without a team, you cannot pass the class. YOU HAVE BEEN WARNED.

If you think you might enroll in the class, but you are not sure, you must attend class and fill out the team matching survey. Indicate on the survey what your situation is. If you have had enrollment issues with SIS, for example, come to class and fill out the survey. Dropping the course after the first couple of weeks will impact your team’s ability to meet their goals and is strongly discouraged.

Labs

Labs provide key technical background that you will need for the project. In each lab, we will have activities for you to do; these usually require a partner. By the end of lab, you should get your work checked off by a TA or tutor. If lab takes longer than expected, you can get your lab checked off in any office hours before the next week’s lab. Extensions are available in case of illness and family emergency, but please contact us in advance. In these exceptional cases, you will need to do your assignment without a partner (but you can still receive help in office hours).

For full lab credit, you must show up in person. You may miss one in-person lab without penalty (it should be completed at home); otherwise, you will only get half credit for each lab. The penalty will be waived if you are sick or will be absent due to an exceptional situation, such as a religious observance. If these apply to you, email the instructor mcoblenz@ucsd.edu in advance.

Later in the course, lab may not occur to enable you to focus more on your project.

Discussion

We will use discussion section sporadically to enable interactive activities that do not fit in the lecture schedule. Two of these are required (see the schedule). Other discussion sections are optional. Most weeks, there will be no discussion so you can focus on your group project, but we will have a TA or tutor present for office hours.

Homework

Some tasks will only be done by some members of a team, but we want all students to learn key skills in this class. To address this potential gap, homework is designed to provide individual practice on key concepts in the course. These will typically be short.

Course Materials

This class does not require you to buy textbooks. You may find these sources useful for reference:

• Dan Pilone and Russ Miles. Head First Software Development, O’Reilly Media, Inc. 2007. Available free for UCSD students: UCSD library.

• Eric Freeman and Elisabeth Robson. Head First Design Patterns, 2nd Edition. O’Reilly Media, Inc. 2020. Available free for UCSD students: UCSD library

Class participation policy

Part of being a good team member is showing up. Since the group project is a major component of your class experience, it wouldn’t be fair for some team members to have to spend team time catching everyone else up on what happened in class. Therefore, this class has a participation policy as follows:

We will have interactive in-class activities on many (but not all) class days. These will be graded, although often the grades will be low-stakes (completing them with reasonable effort will earn 100% of the points). These are not merely attendance checks; off-topic answers will not be given credit. Your grade in this class will be no higher than the lower of (in-class activities grade + 15%) and (your grade on all other class components). In other words: you can miss up to 15% of the in-class activities with no impact on your grade. Below that, there may be an impact, and it is impossible to get a B-class grade (80% or above) if you complete less than 65% of the in-class activities.

Some activities may occur right at the beginning of class, so if you are late, you might miss them. You will need to be in class in person to participate.

A podcast of the lectures will be available for use if you miss class or you just want to review material later.

Please contact the instructor in case of extenuating, unexpected circumstances, such as extended illness.

Late work

Team work should be submitted on time. If you submit team work late, you will jeopardize your ability to receive timely feedback from us and risk lower scores on ongoing project quality.

If you submit individual work late, we will not directly penalize your grade. However, we only commit to promptly grading and returning work that is submitted on time. Other work will be graded (and awarded credit) as resources allow. We reserve the right to make this policy more restrictive if it is abused.

Teamwork

Learning to work effectively in a team is a learning goal of the class. Please discuss team-related challenges with course staff as soon as they arise if you are not able to resolve them quickly internally. We have an expert course staff with substantial real-world experience, and we have likely experienced (or at least heard of!) your problem before.

CSE 110 should be a positive experience for everyone. If any aspect of teamwork makes you uncomfortable or does not adhere to the UCSD Principles of Community, please discuss the matter with the instructor or a TA right away. In almost all cases, we will try to help the team work toward a solution that everyone is comfortable with. In exceptional situations, we can arrange for students to change teams and/or escalate to the Center for Student Accountability, Growth, and Education.

Discrimination and harassment are absolutely not tolerated in team settings or anywhere else in the course. Please be aware that course staff are required by UCSD policy to report student incidents of unlawful discrimination and harassment to OPHD. However, we hope that students will come forward with any concerns as soon as they are aware of them; sometimes, addressing a small problem can prevent it from becoming a large problem.

Crises

Students sometimes experience personal crises that affect their teams because they are suddenly unable to deliver work that they had promised. If you experience a crisis, please talk to your team and the course staff to work out a plan. If your teammate experiences a crisis, you are not expected or encouraged to do all of their work for them to “rescue” your project. Instead, work with your team and course staff to reduce project scope.

Every quarter, some students report that they “had to” work an unreasonable number of hours per week because their teammates did not deliver as promised. Do not do this; work hard, but you are not expected to be a hero. Talk to us if you are ever unsure how to proceed.

Grading

• 7%: your individual work on homework assignments.
• 12%: two skills checks.
• 10%: your work on labs.
• 26%: team process and deliverables (see below).

• 15%: your personal contributions to team success. Course staff will assign this grade based on a holistic assessment of your contributions during the quarter, considering the artifacts you delivered for your team project, your self-reflection, and your peer assessments. We will consider the following categories, but the weighting will be holistic:

  • Technical contributions: to what extent has your technical work (writing code, designing software, writing documentation, writing tests, maintaining CI/CD systems) helped your team deliver great software?
  • Teamwork: to what extent have you been a collaborative and effective team member? Have you delivered what you promised in a timely fashion, and communicated as needed when you were running late? Have you worked to foster a positive, collaborative, equitable atmosphere among your group members?
  • Independence: to what extent have you provided direction to your group or exercised individual discretion? This category could also be called leadership, but this is not a competition to be the group “leader.” Instead, our focus is on your ability to think critically about the team’s needs and propose directions – either technical or otherwise.

  Many students make “perfectly reasonable” contributions and earn a 13 or 14 out of 15. Some students make exceptional contributions and get a 15.

• 10%: your midterm exam.
• 20%: your final exam.

The standards for each final grade level are below.

• A: grade >= 90%
• B: grade >= 80%
• C: grade >= 70%
• D: grade >= 60%
• F: grade < 60%

The instructor has discretion to assign + and - grades within those ranges and to decrease the thresholds for grades if the overall grades are lower than expected. Discretion may be used to award small amounts of credit for exceptional contributions.

Individual assignments (total: 7%)

Note: reading assignments are still under revision. Do not rely on the posted readings yet.

Skills checks (total: 12%)

We will have two skills checks to evaluate whether you have used good engineering judgment and have contributed quality artifacts to your team project. Both skills checks correspond to Gradescope assignments; please see Gradescope for details.

1. The first skills check will evaluate your code. To complete this skills check, you must show that you have submitted a high-quality PR, passed peer review (by your team), and merged it into your team’s codebase. You should complete this skills check by the end of sprint 1.

2. For the second skills check, you have a choice. You can either (a) create architectural documentation for your team’s project, showing what the main components are and how they relate to each other; or (b) conduct a user study of your team’s project to assess its usability.

Grading of skills checks will include an oral component in which we will ask you to tell us about your work. Our goal here is to ensure that you were responsible for the intellectual content of the work (and not an AI). These oral evaluations will be graded on 0 to 5 scale. These scores represent the maximum score you will earn on the skills check. Scores of 5 have no impact on your grade. If you score a 4, for example, then your grade will be no more than 90%. A 2 warrants no more than 70%, etc.

Each skills check is due at the end of one of the first two sprints.

Team assignments (total: 26%)

Usually, all members of a team will receive the same grade on team assignments. However, if some team members are absent or otherwise do not contribute sufficiently to a deliverable, we reserve the right to award credit only to students who contributed meaningfully. Communication of absences prior to deadlines will be considered as a mitigating factor.

Labs (total: 10%)

You will need to have your lab checked off each week. Usually these labs will be done in pairs.

Personal contributions to team success (total: 15%)

TAs will assess these contributions every week on the basis of your peers’ input and their observations of your contributions.

Midterm exam (total: 10%)

The midterm will be held in class on Friday, October 23.

Final exam (total: 20%)

We will have a final exam in the assigned final exam slot (Tuesday, December 8, 3:00–5:59 PM).

Project quality

Each week, your TA will assess to what extent your team has made appropriate choices regarding:

• Process
• Testing, continuous integration, continuous deployment
• Code review
• Architecture
• Documentation

Each project will have its own needs, and no one process is best for all teams. Generally, we expect:

Process

Your team should adopt an Agile-style process. You should maintain a backlog in a place that is available to all team members, where the items are user stories described in appropriate format. Every sprint should start with a planning meeting in which the team (1) breaks down the highest-priority backlog items into tasks; and (2) assigns them to team members. Every sprint should end with a retrospective meeting in which you review the sprint and make changes to your process. Each sprint should have a scrum master and a project owner (and these roles should rotate each sprint). Each week, you should meet with your assigned TA for about 30 minutes to describe your progress and get feedback.

Effective TA meetings might look like:

1. Team members each take turns demoing the tasks they completed that week.
2. Discuss challenges that have come up during the week.
3. Share the team backlog and get feedback about priorities.

Testing, continuous integration, continuous deployment

Your team needs a continuous integration system that runs unit and integration tests of both the front end and back end. The expectations for this will increase as the quarter continues; at the end of Sprint 1, for example, it might suffice to have a test harness set up even though it only tests something trivial.

Code review

Every change should be reviewed by another member of the team. Most reviews should be substantive, showing evidence that the author was given an opportunity to improve, and that the author indeed improved the code as a result.

Architecture

Your team should make appropriate architectural choices, justifying each in the context of the project.

Documentation

Your team should maintain appropriate documentation. Public interfaces and key design choices and assumptions should be documented.

Pass/fail

If you take this class pass/fail, we will grade your work as usual. At the end of the course, we will map final grades of C- and above to “pass” and grades lower than C- to “fail” according to UCSD policy.

Academic Integrity

Teamwork and collaboration are critical to success in software engineering. In individual homework assignments, I ask students to follow a whiteboard policy: you may discuss the homework assignments with anyone you like in front of a whiteboard. However, after you are done, erase the whiteboard, and each student should write their own submissions. You must write the names of those you collaborated with in your submissions.

You may only use generative AI tools, such as Copilot, in your team programming project and labs unless otherwise specified. You may NOT use generative AI tools in other assignments because the point of the assignments is for you to think and express yourself clearly in English so that others can understand your views. Writing is a form of thinking; do not recruit AI agents to do your thinking for you.

If we detect violations of this academic integrity policy on a given assignment, you will receive a score of NEGATIVE 100% on that assignment. The idea is that it is worse to violate academic integrity than to not turn in the assignment in the first place. Keep in mind that we have successfully detected instances of unauthorized usage of generative AI in other software engineering courses.

In team projects, all forms of collaboration are permitted within teams. Work between teams should follow the whiteboard policy above. Teams may not use each other’s code or other artifacts.

Licensing

When writing software, you may make use of resources to which you have legitimate access. For example, you may leverage open source projects and libraries that are generally available. However, it is your responsibility to vet these tools to ensure the quality of the software you are delivering. Importantly, you must adhere to any licensing restrictions for any software you use. For example, if you use GPLv3 code in your project but do not give your code an appropriate copyleft license, you are stealing someone’s work and may be subject to an academic integrity violation report. Note that for this reason, GPL code can typically not be used in commercial projects, and you may want to choose a more permissive license. Licensing should be one of the earliest discussions you have with your team. If this policy seems harsh, keep in mind that licensing mistakes can lead to very expensive lawsuits.

The default license for a software project is that no one else can use artifacts from that project. If you use code from a project that does not have a license, or you use code without appropriate attribution, you are in violation of a software license’s terms and therefore violating this course’s academic integrity policy.

We recognize that you are not lawyers (neither are we!). Therefore, we will exercise reasonable judgment provided any problems are corrected immediately (typically by adding attribution or by removing the copied artifacts from your repositories). We reserve the right to report academic integrity violations for egregious cases (e.g. use of another team’s code or repeated violations).

Students hold copyright to their own work; see Supplement I, section C.

Technology policy

Using screen-based devices in class has been shown to be detrimental to nearby students, whose learning experience is diminished due to the distraction. However, we recognize the need to take notes. Please be aware of the impact that your screen can have on your neighbors, and use devices in class for note-taking purposes only.

Satisfactory Academic Progress

Satisfactory Academic Progress (SAP) refers to the academic standards students must maintain to remain eligible for federal, state, and institutional financial aid. If you are receiving financial aid, please ensure you review the SAP requirements and the appeals process.