This is the 2016 page. For 2017, go to 15-313 F17.
Questions
- When is a program good enough to ship? Have you built what the customer wanted?
- Why (and how) does NetFlix deliberately and randomly take down its own servers?
- How did Twitter eradicate the Fail Whale? And what does it have to do with Ruby?
- How do you get a patch accepted into an open-source project?
- You can write code. Can you build software?
Overview
Successful software projects require more than just technical expertise. Figuring out what the client wants, collaborating in a team, managing complexity, mitigating risks, staying on time and budget, and determining under various constraints when a product is good enough to be shipped are at least equally important topics that often have a significant human component. 15-313 explores these issues broadly covering the fundamentals of modern software engineering.
Assuming a solid technical foundation of software construction from 15-214 or equivalent (solid programming skills, unit testing, and object-oriented analysis and design with UML, design patterns, and frameworks) we will explore the following topics:
- Process consideration for software development
(How do avoid problems early? When and how much to design? When and how much to test? When and how to involve the customers? Agile methods...) - Requirements elicitation, documentation, and evaluation
(How to figure out what the customer really wants? Who else has an interest? How can we measure success objectively? How can we reliably document expectations? ...) - Design for quality attributes
(How can we design a system to be able to scale to millions of users? How can we design security into a system? ...) - Strategies for quality assurance, including measurement, inspection, and static and dynamic analysis
(What quality assurance strategy is best for a given system? What can we automate and when should we keep humans in the loop? How much testing and what kind of testing should we do? What qualities are important to assure beyond functional correctness? Can we evaluate usability, scalability, reliability, performance? How can we statically guarantee the absence of certain security issues? ...) - Empirical methods in software engineering
(How can we measure quality attributes such as performance, security, and reliability? How can we measure how users interact with the system? How can we know whether the difference matters? ...) - Time and team management
(How to estimate the duration and costs of a project? How to monitor progress and risks to recognize issues early? How to coordinate developers in a team? How to form and develop teams? How to select and motivate team members? How to deal with team dynamics such as social loafing? ...) - Economics of software development
(business models, outsourcing, open source, ...)
This course has a strong technical focus, and includes assignments with and without programming. Assignments also include written components. Students will get experience with team management and modern software-engineering tools. The course puts students on a fast track toward project management positions.
Assignments (mostly done in groups) include:
-
A term project in which each team contributes to an open source project of their choice. This involves identifying an issue in the existing project, understanding the development process of that project and how to contribute, and actually making a contribution such as fixing a bug or adding a feature. Extra credit will be awarded if the contribution is merged into the project. - A requirements project in which each team will interview stakeholders to elicit and document requirements for a software system.
- A dynamic and static analysis project in which each student will extend FindBugs with a new bug pattern.
- An inspection task in which each team will inspect existing code for security issues and inspect code written by other students in the course.
Logistics and People
Lectures: Tue/Thu 3:00-4:20 p.m. in GHC 4215
Recitations: Wed 12:30-1:20 p.m. in PH 225B (Section A) and Wed 1:30-2:20 pm in PH 226C (Section B)
Staff contact email: staff-15313@lists.andrew.cmu...
Please
use piazza for
general discussion or questions, including clarifying questions, related to
the assignments, course content, etc. Use the email address above to
contact course staff about individual issues, such as extension requests or
individual grading queries. The address should accept emails from any
andrew or cmu email address by default. Do not be concerned if you receive
a notification that your message is being held for moderation; the list is
moderated rapidly. Please avoid emailing individual instructors about
course-related requests, unless you have a particularly sensitive situation
that you are only comfortable sharing with particular individuals.
Both instructors have an open door policy: If either of the instructors' office doors are open and no-one else is meeting with us, we are happy to answer any course-related questions. For appointments, email the instructors.
Course Syllabus and Policies
In this semester, the course uses Canvas for homework submission, grading, discussion, questions, announcements, and supplementary documents; slides will be posted here; github is used to coordinate group work. (Canvas is a blackboard alternative currently evaluated by CMU).
Waitlist: We believe the waitlist is cleared; if you disagree or are having trouble enrolling, please contact us.
Prerequisites: 15-214 or equivalent (Java programming, unit testing, and object-oriented analysis and design with UML, design patterns, frameworks, and exposure to small projects)
Communication: We make announcements through Canvas and use Canvas for discussion, including clarifying homework assignments and other interactions. The instructors and TAs hold weekly office hours and are reachable by email; see above for information on how to contact us. Email them for additional appointments. They also have an open-door policy: When our door is open and we are not currently meeting with somebody else, feel free to interrupt us for course-related issues.
Textbook: Various readings throughout the semester available online or through the library. As optional supplementary reading consider Ian Sommerville, Software Engineering, 7th or 8th edition. Note that we do not expect that the bookstore will carry the old edition; instead, many copies are available online, such as through Amazon.com (and many other booksellers and textbook reseller) for significantly less than 20USD. The 7th and 8th edition are interchangeable for our purposes. Let us know if you have trouble acquiring a suitable edition.
Grading: Evaluation will be based on the following distribution: 50% assignments, 15% midterm, 20% final, 10% participation, 5% reading quizzes.
Time management: This is a 12-unit course, and it is our intention to manage it so that you spend close to 12 hours a week on the course, on average. In general, 4 hours/week will be spent in class and 8 hours on reading and assignments. Please feel free to give the course staff feedback on how much time the course is taking for you.
Late work policy: Late work will receive feedback but no credit. Due to heavy reliance on teamwork in this course there are no late days. Exceptions to this policy will be made only in extraordinary circumstances, almost always involving a family or medical emergency with your academic advisor or the Dean of Student Affairs requesting the exception on your behalf. Accommodations for travel might be possible if requested at least 3 days in advance.
Teamwork: Teamwork is an essential part of this course. Most assignments are done in teams of 3-5 students. Typically, teams will be assigned by the instructor and stay together for multiple assignments. Guidance on teamwork, reflection, and conflict resolution will be provided throughout the semester. Most assignments have a component that is graded for the entire group and a component that is graded individually. The team policy posted on blackboard applies and describes roles and teams and how to deal with conflicts and imbalances.
Academic honesty and collaboration: The usual policies apply, especially the University Policy on Academic Integrity. Many of the assignments will be done in groups. We expect that group members collaborate with one another, but that groups work independently from one another, not exchanging results with other groups. Within groups, we expect that you are honest about your contribution to the group's work. This implies not taking credit for others' work and not covering for team members that have not contributed to the team. Otherwise, our expectations regarding academic honestly and collaboration for group work are the same as for individual work, substituting elevated to the level of "group."
The course includes both individual assignments and individual components of group assignments. Although your solutions for individual parts will be based on the content produced for the group component (e.g., written reflections on lessons learned), we treat individual component of group assignments as equivalent to individual assignments overall, and expect you to complete such components independently of your groupmates.
The rest of this academic honesty and collaboration content is taken from the policy used in 15-214, which we reuse almost directly (with minor modifications, and attribution).
"You may not copy any part of a solution to a problem that was written by another student, or was developed together with another student, or was copied from another unauthorized source such as the Internet. You may not look at another student's solution, even if you have completed your own, nor may you knowingly give your solution to another student or leave your solution where another student can see it.
Here are some examples of behavior that are inappropriate:
- Copying or retyping, or referring to, files or parts of files (such as source code, written text, or unit tests) from another person or source (whether in final or draft form, regardless of the permissions set on the associated files) while producing your own. This is true even if your version includes minor modifications such as style or variable name changes or minor logic modifications.
- Getting help that you do not fully understand, and from someone whom you do not acknowledge on your solution.
- Writing, using, or submitting a program that attempts to alter or erase grading information or otherwise compromise security of course resources.
- Lying to course staff.
- Giving copies of work to others, or allowing someone else to copy or refer to your code or written assignment to produce their own, either in draft or final form. This includes making your work publicly available in a way that other students (current or future) can access your solutions, even if others' access is accidental or incidental to your goals. Beware the privacy settings on your open source accounts!
- Coaching others step-by-step without them understanding your help.
If any of your work contains any statement that was not written by you, you must put it in quotes and cite the source. If you are paraphrasing an idea you read elsewhere, you must acknowledge the source. Using existing material without proper citation is plagiarism, a form of cheating. If there is any question about whether the material is permitted, you must get permission in advance. We will be using automated systems to detect software plagiarism.
It is not considered cheating to clarify vague points in the assignments, lectures, lecture notes; to give help or receive help in using the computer systems, compilers, debuggers, profilers, or other facilities; or to discuss ideas at a very high level, without referring to or producing code.
Any violation of this policy is cheating. The minimum penalty for cheating (including plagiarism) will be a zero grade for the whole assignment. Cheating incidents will also be reported through University channels, with possible additional disciplinary action (see the above-linked University Policy on Academic Integrity).
If you have any question about how this policy applies in a particular situation, ask the instructors or TAs for clarification."
Note that the instructors respect honesty in these (and indeed most!) situations.
A note on self care. Please take care of yourself. Do your best to maintain a healthy lifestyle this semester by eating well, exercising, avoiding drugs and alcohol, getting enough sleep and taking some time to relax. This will help you achieve your goals and cope with stress. All of us benefit from support during times of struggle. You are not alone. There are many helpful resources available on campus and an important part of the college experience is learning how to ask for help. Asking for support sooner rather than later is often helpful.
If you or anyone you know experiences any academic stress, difficult life events, or feelings like anxiety or depression, we strongly encourage you to seek support. Counseling and Psychological Services (CaPS) is here to help: call 412-268-2922 and visit their website at http://www.cmu.edu/counseling/. Consider reaching out to a friend, faculty or family member you trust for help getting connected to the support that can help.
Schedule
The following schedule describes the current planing status and the covered concepts. It is subject to change and will be updated as the semester progresses, especially to help focus on requested topics or support learning.
| Date | Topic | Reading assignments* | Assignments due* |
|---|---|---|---|
| 30-Aug | Intro & Overview (SE as a human activity and business concern; risk) | ||
| 31-Aug | rec 1 Git and GitHub | ||
| 1-Sep | Process (Lightweight introduction into process, scheduling, risk, and tracking progress) | Sommerville, Software Engineering, Chapter "Project management" | |
| 6-Sep | Case Study (healthcare.gov) | TIME Magazine 3/10/14, article "Code Red" & Wikipedia on healthcare.gov | |
| 7-Sep | rec 2 Measuring Software Characteristics | ||
| 8-Sep | Measurement | Buse, Zimmermann. Information Needs for Software Development Analytics. ICSE 2012 | hw1a Team work, time estimation, and implementation (Planning documents) |
| 13-Sep | Requirements (Too much terminology) | Lecture notes | |
| 14-Sep | rec 3 Software Requirements | ||
| 15-Sep | Requirements (Use cases, Internationalization) | Larman. Applying UML and Patterns. Chapter "Use Cases" | |
| 20-Sep | Requirements (How) | Sommerville, Software Engineering, Chapter "Safety Critical Systems" | hw1b Team work, time estimation, and implementation (Code artifacts) |
| 21-Sep | rec 4 Requirements Interviews | ||
| 22-Sep | Architecture (Intro, case studies, quality goals) | Twitter: "New Tweets per second record, and how!" | hw1cd Team work, time estimation, and implementation (Reflection) |
| 27-Sep | Requirements Interview and Architecture Documentation | Garlan. Software Architecture: A Travelogue. FOSE 2014 | |
| 28-Sep | rec 5 Architectural Assessment and Decisions | ||
| 29-Sep | Architecture (Patterns, tactics, evaluation) | Shaw, Garlan. Software Architecture: Perspectives on an Emerging Discipline, Chapter "A. Styles" and Bass et al. Software Architecture in Practice, Chapter "Understanding QA." | |
| 4-Oct | Architecture (Microservices case study) | Software Engineering Daily Podcast, Episode "Scaling Uber with Matt Ranney" | hw2 Requirements |
| 5-Oct | rec 6 Let's Create a Startup! | ||
| 6-Oct | Architecture (Design exercise and ROS) | Bass et al. Software Architecture in Practice, Chapter "The ATAM" | |
| 11-Oct | QA (Introduction to QA and testing) | Netflix blog on Simian Army | hw3a Architecture |
| 12-Oct | rec 7 Midterm review | ||
| 13-Oct | Midterm | ||
| 18-Oct | QA (Static analysis part 1) | Schwartzbach static analysis notes | |
| 19-Oct | rec 8 Static Analysis (FindBugs) | ||
| 20-Oct | QA (Static analysis part 2) | [no reading] | hw3bc Architecture |
| 25-Oct | QA (Dynamic analysis + profiling) | Zeller. Why Programs Fail. Chapter "Observing Facts" | |
| 26-Oct | rec 9 Dynamic Analysis (ASM) | ||
| 27-Oct | QA (Inspection and reviews) | Wieger. Peer Review in Software. Chapter "Peer Review Formality Spectrum" | hw4a Advanced testing |
| 1-Nov | Process + Teams (From sequential to iterative) | Pfleeger and Atlee. Software Engineering: Theory and Practice. Chapter 2, excerpts | hw4b Advanced testing |
| 2-Nov | rec 10 QA Plan | ||
| 3-Nov | QA (QA Process) | Jaspan et al. Understanding the value of program analysis tools. OOPSLA, 2007 | |
| 8-Nov | Process + Teams (Agile practices) | Fowler and Highsmith, The Agile Manifesto and Stephens and Rosenberg, Extreme Programming Refactored: The Case Against XP (Chapter 2) | |
| 9-Nov | rec 11 Agile Methods | ||
| 10-Nov | Process + Teams (Secure Development Lifecycle) | Hernan et al. Uncover Security Design Flaws Using The STRIDE Approach. MSDN 2006 | hw5 Static and dynamic analysis |
| 15-Nov | Process + Teams (Motivation) | - | |
| 16-Nov | rec 12 Process comparison | ||
| 17-Nov | Process + Teams (Hiring and Staffing) | - | hw6a OSE project description |
| 22-Nov | No class | ||
| 24-Nov | No class (Thanksgiving) | ||
| 29-Nov | Process + Teams (Team issues) | DeMarco and Lister. Peopleware. 2013 Ch. 22, 23, and 28 | |
| 30-Nov | rec 14 Team dysfunctions | ||
| 1-Dec | Business models (Open source) | Richard Stallman's TEDx Geneva 2014 talk | |
| 6-Dec | OSE Presentations | - | hw6b OSE report |
| 8-Dec | OSE Presentations & Summary | - | |
| 13-Dec | Final exam (8:30 am) |