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 Piazza for discussion.

Change Policy

This is my second time teaching this course. I have made significant changes relative to last year, which means there are significant parts of the course that are brand new. 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 10:00 - 10:50 AM 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 Mondays 5:00 - 5:50 in Catalyst 125.
• The final exam will be Friday, December 12, 8:00 - 10:59 AM.

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. This makes adding the class late very problematic. If you join the course late, you will need to join a team that has already made some decisions without your input. If you drop the class, you will leave your teammates to finish the project on their own, even though they chose a project scope that relied on your help.

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. 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 lab without penalty; 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 holiday. 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 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

In-class activities

We will have interactive in-class activities on many (but not all) class days. Together, these will be worth 10% of your grade. We will drop the lowest 10% of the activities, so if you miss a small number of them, your grade will not be impacted. These may take a variety of forms: WebClicker, paper-based, and online (e.g. Google Forms). Some of these 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.

If you do not get the full 10% from these in-class activities, the missing points will be reallocated to your final exam, allowing you one final opportunity to make up the credit. For example, if you only complete half of 90% of the in-class activities, then you’ll be missing 5% from your grade, so your final exam will be worth 25% rather than 20%.

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

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

• 11%: your individual work on homework assignments.
• 10%: your work on labs.
• 12%: your team’s ongoing work. This is NOT a measure of the final number or quality of features. Instead, it is a measure of the extent to which you are using techniques from class correctly and effectively to promote creation of high-quality software.
• 12%: team deliverables: design documents, etc.

• 15%: your personal contributions to team success. You will report weekly on your own contributions as well as your teammates’ contributions. Your contribution will be assessed in the following categories:

  • 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.
• 10%: your midterm exam.
• 20%: your final exam.
• 10%: in-class activities (dropping lowest 10%, and any remaining missing points will be reallocated to the final exam).

The standards for each final grade level are below.

• A: grade >= 90% AND oral exam score of 4
• B: grade >= 80% AND oral exam score of >= 3
• C: grade >= 70% AND oral exam score of >= 2
• D: grade >= 60% AND oral exam score of >= 1
• 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. This discretion may be used to award small amounts of credit for exceptional contributions to in-class discussion.

Individual assignments (total: 11%)

Team assignments (total: 24%)

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 24.

Final exam (total: 20%)

We will have a final exam in the assigned final exam slot (Friday, December 12, 8:00 - 10:59 AM)

Oral exam

During the last two weeks of class, you will meet with a TA for a 15-minute oral exam. In the exam, you will need to show that you understand the code you were responsible for in terms of high-level and low-level design. Your oral exam will be graded on a coarse scale (0-4). You may retry your oral exam once with the instructor if you like.

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, labs, and in the testing assignment. 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.