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; we will enroll students from the waiting list as well.

Change Policy

This is my first time teaching this course. I have made significant changes relative to other offerings. In particular, the project is much more open-ended: groups will decide what to build. You will not receive specifications from the course staff regarding what you are supposed to create. However, 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 in Center Hall 115. You will need a clicker.
• Labs will be Mondays 1:00 - 3:50 in the basement of the CSE building.
• Discussion will be Mondays 7:00 - 7:50 PM.
• The final exam will be Tuesday, December 10, 3:00 - 5:59 PM.

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

Students in the graduate version of this course provided 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 (perhaps because you are on the wait list), you must attend class and fill out the team matching survey. Indicate on the survey what your situation is. We may oversize some teams to compensate for a small number of drops within the first couple of weeks. 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 in pairs. 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 the same week, but it must be done by the end of Friday. 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).

Credit for labs is binary; if you get checked off, you will receive 100% of the credit for that lab.

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

Discussion

Most weeks, there will be a discussion section that is an integral part of the course. You should come to every discussion that is offered, and the first two meetings will be required. The other discussion sections will generally serve to reinforce material and help you prepare for exams. Some weeks, there will be no discussion section; you would do well to use that time to meet with your team.

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 (though the architecture assignment may be more complex).

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

Insurance

You wouldn’t want to miss a question on the final exam, would you? You may choose to buy insurance against this unfortunate outcome. In each lecture, some clicker questions will be designated as insurance questions. By getting these questions right, you can insure yourself against up to 50% of the loss due to incorrect exam answers on the same topic. For example, suppose you attend the lecture on requirements analysis and answer all of the insurance questions correctly. If you score 0% on the exam section pertaining to requirements analysis, we will award 50% on that exam section because you were insured!

The context for this mechanism is that I want to encourage attendance (because it aids learning) but I only want to award grades on the basis of demonstrated knowledge. Answering clicker questions correctly is a way to show that you have acquired relevant knowledge. Of course, the exam is an even stronger signal, so the clicker questions are only worth 50% as much as the exam.

Insurance will be pro-rated according to the fraction of clicker questions you got right. For example, if you get 50% of the clicker questions about requirements right, and you score 0% on the corresponding exam section, we will award 50% * 50% = 25% on that exam question.

The benefits of insurance apply to partial credit. If you score 80% on an exam question for which you have full insurance, then the insurance will cover 50% of the 20% you missed, so you will receive 90% credit on that question rather than 80%.

We will generally calibrate clicker questions to be of “medium” difficulty: they may not quite follow immediately from the lecture, but most students should be able to answer most of them correctly. Some lectures may also include clicker questions that are NOT for insurance because we think they are too easy or too hard. Clicker questions that are for insurance will be marked with the 🌪️ emoji.

While in class, these clicker questions should be treated as quizzes: there is no discussion about the answers before you submit your response. Clicker questions must be answered in class, since we will often announce correct answers immediately afterward.

If you miss class, you cannot get credit for answering the clicker questions. However, you may obtain insurance coverage for a lecture by watching the recorded lecture and writing a one-paragraph analysis of the implications of the content on your project work. It should be specific to you and your project; no two people should have the same analysis! We will award insurance if we are convinced that your paragraph shows that you have absorbed the key messages of the lecture. You may use this privilege up to twice during the quarter with no explanation or excuse necessary. In extenuating circumstances, such as serious illness or family emergency, we may extend this privilege to more than twice. Note that this is more work than just showing up to class.

We reserve the right to stop offering new insurance questions at any time if we feel that the insurance system is being abused or is not meeting its goals.

Insurance applies only to the final exam, not to the midterm.

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.

Grading

• 18% of your grade will be determined by your individual work on homework assignments.
• 4% of your grade will be determined by your work on labs.
• 23% of your grade will be determined by 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.

• 25% of your grade will be determined by 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% of your grade will be determined by your midterm exam.
• 20% of your grade will be determined by your final exam.

Letter grades will be given according to the following scale:

• A: grade >= 90%
• B: 80% <= grade < 90%
• C: 70% <= grade < 80%
• D: 60% <= grade < 70%
• 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: 25%)

Team assignments (total: 23%)

Labs (total: 4%)

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: 18%)

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, November 1.

Final exam (total: 20%)

We will have a final exam in the assigned final exam slot (Tuesday, December 10, 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 weekly 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 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.