COINSE

CS350 Introduction to Software Engineering, Spring 2023

Lectures

  • Time: 13:00-14:15, Mondays and Wednesdays
  • Location: N1-117

Lecturer

TAs

Communication

All class announcements, as well as Q&A, will take place using a dedicated Slack workspace. You are required to join cs350spring2023kaist.slack.com if you want to continue this course. It is strongly recommended that you install either a desktop or a mobile client, to get notifications. Email the lecturer or one of the TAs to get the invitation link, if you do not have one. When you sign up, please set your username as your real full name in English, followed by “(your student id number)”. For example, “Shin Yoo (20201234)”.”

Syllabus

This course is concerned with a broad range of topics, concepts, techniques, and problems that are relevent to basic practices of software engineering. The topic will include, but are not limited to: software quality, process models, requirements and use cases, architecture and design, version control and CI/CD, software testing, etc. The expected learning outcome is:

  • to understand what software engineering is, and why it is needed
  • to understand the basic concetps in Software Development Lifecycle (SDLC)
  • to understand the fundamental concerns in software engineering
  • to know the widely used tools and techniques that are de-facto standard

Evaluation

The course evaluation breakdown is as follows:

  • Coursework: 40%
  • Project: 40%
  • Quiz: 20%

References

We do not have a textbook per se, and the course will be based on slides and other reading material that are deemed appropriate. However, if you want to get broader sense for some of the topics dealt by this course, I recommend the following books and publications.

  • Mythical Man Month by Fredrick Brooks Jr., Anniversary Edition, 1995
  • Software Engineering by Ian Sommerville, 10th Edition, 2015
  • Joel on Software by Joel Spolsky, 3rd Edition, 2004
  • Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright, 2020 (freely available)

Lecture Schedule

The following is tentative and can be updated: any chances will be announced via Slack.

Assignments

Assignment 1. Essay on “The Mythical Man Month”

Write an essay about “The Mythical Man Month” by Frederick Brooks Jr. - it can be about what you learnt from it, how you think it is correct/incorrect, how it relates to your own experience, etc. Minimum 500 words.

Due on 8th March. Submit via KLMS (PDF only!).

Assignment 2: “Find a Bug Day”

We will have “Find a Bug Day. Spot a software bug in your everyday life, and create a short presentation about it. You should describe the bug as well as how it affected your life, and suggest how it could have been avoided during the development. Maximum three pages of slides. I will invite some of the unique and best ones for presentation on 10th April.

This assignment has been inspired by the “one week of bugs” written by Dan Luu.

Due on 29th March. Submit via KLMS (PDF only!).

Assignment 3: “Git Challenge”

Improve your git skills by completing https://learngitbranching.js.org. Once you clear all the challenges, get a screenshot as a proof :) Subsequently, solve this quiz and submit the final status as instructed in the repository.

Due on 24th April. Submit via KLMS.

Assigment 4: “Future of Software Engineering”

Create an account for OpenAI playground. Pick an appropriate function from the project you are currently developing, and make GPT-3/Codex to write it instead by prompting it - if the language model gets it right, try making your requirement increasingly complex until the answer is wrong. Document this process in your report, along with what you think will happen to software engineer as a profession.

Due on 24th May. Submit via KLMS (PDF only!).

Project Aim

The aim of team project in CS350 is not just the end product, i.e., what you eventually make is not everything. It is about your experience of making it, i.e., how you eventually get there. Software engineering is much more than just programming, and I hope you experience this to the best extent possible within the confinements of a taught course.

Teams

We will have teams of five people. Register your team here.

Project Structure

Each team will propose a project, i.e., a (reasonably small) software system to be made. However, your project is not for your team to develop: it will be picked up by one of the other teams to be developed, and you will play the role of the client.

Proposal

You will write what is called Software Requirement Specification (SRS) document. It should specify the software you want to be developed. For the typical structure and information contained in an SRS, consult the Wikipedia entry for SRS as a starting point. There is no length requirement, but be as specific as possible. Submit via KLMS, one per team. Due 3rd April.

Matching Period

We will have a project proposal lightning talk day on 12th April - each team will be given 3 minutes to explain the project they are launching. Also, submitted SRS documents will be shared on KLMS. Then we will use a dedicated Slack channel to foster conversations between teams. Once you decide a specific proposal to develop, mark your choice on the Google Sheet.

Design

Once you choose a proposal, then as developers, your team needs to write the Software Design Document (SDD) - it should outline your planning, design, technical components, etc. There is no length requirement, but be as specific as possible. Submit via KLMS, one per team.

Development

During the development of the project, do you best to adopt the best practices that are introduced in CS350. Remember that there is no silver bullet, no absolutely “correct” way of building a project. But you should think hard about how to deliver the best quality project in time.

You should have at least one discussion with your client - either face to face, or via a virtual meeting. This is so that you can discuss the progress of the project.

Deliverable

At the end of the term, each team should submit a project team report (one per team). It should contain two parts about the following:

  • Your experience as the client (i.e., the project you came up with), detailing your interactions with the developer team. Provide a peer evaluation of your developer team.
  • Your experience as the developer (i.e., the project you delivered), detailing your development progress and the interactions with the clients (i.e., how the project changed due to the feedback, etc), how the knowledge from the course helped/did not help the project, etc.

Additionally, submit an individual report. It should contain:

  • What you individually contributed to the project, both client and developer roles
  • What you learnt from the project
  • Peer evaluation of your team mates

Submission details will be updated later.