IN4315 - Software Architecture

Teaching TeamContactScheduleFinal presentationsMaterialProjectGradingFAQ

The goal of this course is to learn what it means to be an architect, and to acquire the necessary skills for becoming a successful architect. To that end, we will study available literature, and apply it to actual open source projects.

The main outcome of your team work will be a chapter of around 5000 words providing a new architectural description of the system you are studying. All chapters will be combined into a joint book, titled Delft Students on Software Architecture (DESOSA). The book will contain a selection of chapters, each contributed by one team – see the DESOSA 2016, DESOSA 2017, and DESOSA 2018 books. The DESOSA book is directly inspired by the Architecture of Open Source Applications book series.

A course description is provided in our blog post covering the course in the academic year 2012/2013 and our SIGCSE paper that describes our 2015/2016 edition. Changes since then include the extensive coverage of technical debt and re-design (new in this course).

The course is organized as follows:

  1. You will work in teams of 4 on an existing GitHub project of choice
  2. You will contribute to this project by means of architectural documentation for concerns your project is struggling with.
  3. You will describe the existing architecture of the system using all the tools and technique we provide.

Teaching team

Arie van Deursen
Responsible Teacher
Maurício Aniche
Responsible Teacher
Andy Zaidman
Responsible Teacher
Anand Kanav
TA
Bernd Kreynen
TA

Contact

  • All students participating will get access to a dedicated Mattermost instance. This can be used to interact with all students, the TAs and the teachers.
  • For personal questions, email teachers Arie van Deursen and Maurício Aniche.
  • TA availability: mail all TAs, asking for an appointment.

Schedule

Lecture 1. Introduction to Software Architecture, Arie van Deursen 12/February, 3.45pm
Lecture:
Lecture 2. Views and Perspectives, Arie van Deursen 13/February, 3.45pm
Lecture:
  • Stakeholders
  • Context view
  • Development view
  • Architectural patterns
Lecture 3. Cloud architecture, Mike Ciavarella, Coolblue 19/February, 3.45pm
Details will come.
Lecture 4. From 0 — $100 billion: Scaling infrastructure and workflow at Adyen, Bert Wolters 20/February, 3.45pm
Bert Wolters is a TU Delft alumnus and SVP Innovation at Adyen, Amsterdam. He will explain how Adyen changed its architecture to support thousands of payments per second.
Lecture 5. Social Aspects of Software Architecture, Ayushi Rastogi 26/February, 3.45pm
Ayushi Rastogi is a postdoctoral researcher at TU Delft. She will cover the social aspects of architectural decision making in an open source context.
Lecture 6. Software Product Lines, Xavier Devroey 27/February, 3.45pm
Xavier Devroey is a postdoctoral researcher at TU Delft. He will discuss techniques to manage and implement variability in software systems.
(Deadline) February 28th: Stakeholder and Context-View
  • Formative assessment of your stakeholder and context-view.
  • Deadline: February 28th, 6pm
Lecture 7. Guest lecture: Eric Greuter, ING. Data Analytics Platform Architectures 5/March, 3.45pm
Eric Greuter is Product owner of the IT Infrastructure Data & Analytics platform at ING Bank, which he will present and discuss in his guest lecture.
Lecture 8. Code metrics, Marco Di Biase 6/March, 3.45pm
Marco di Biase is a PhD student at Delft University of Technology, working closely with the Software Improvement Group in Amsterdam. He will cover the role of software quality metrics, both at the level of both the system and individual changes.
Lecture 9. Technical Debt, Andy Zaidman 12/March, 3.45pm
Lectures on the gap between making a change perfectly and making a change work.
  • Technical Debt Indicators
  • Technical Debt Metaphor
  • Types of Technical Debt
  • Evolution Patterns
  • The role of Testing
Lecture 10. Technical Debt, Andy Zaidman 13/March, 3.45pm
Part II of the lectures on Technical Debt.
Lecture 11. Domain-Driven Design, Maurício Aniche 19/March, 3.45pm
Lectures on OOP design and domain modeling:
  • What are the real challenges in OOP design?
  • What's domain driven design?
  • DDD patterns
(Deadline) March 21th: Development View & Technical Debt
  • Formative assessment of your development view and technical debt analysis.
  • Deadline: March 21th, 6pm
Lecture 12. Domain-Driven Design, Maurício Aniche 20/March, 3.45pm
Part II of the lectures on DDD.
Lecture 13. No lecture 26/March, 3.45pm
Focus on your project!
Lecture 14. DDD from the trenches, Matthias Noback 27/March, 3.45pm
How is it like to do DDD in practice? Matthias Noback is a professional developer who discusses a lot about clean code, unit testing, dependency injection, and design principles & patterns. Read more about him in his website.
Lecture 15. No lecture 2/April, 3.45pm
Focus on your project!
Lecture 16. No lecture 03/April, 3.45pm
Focus on your project!
April 5th, Presentation day!
(Deadline) April 12th: Final report

Grading

The grades for this course are based on a group grade for the deliverables, contributions, presentations, and chapter, as well as an individual points for the review and participation.

Participations points are bonus points that can be earned by being proactive in helping other team members, for example during class, or on line in GitHub or on Mattermost.

The grade is composed of the following partial grades:

  • V1 = Team grade for stakeholders and context view [1..10]
  • V2 = Team grade for development view [1..10]
  • V3 = Team grade for technical debt [1..10]
  • V4 = Team grade for extra perspective [1..10]
  • T = Team work [1..10]
  • O = Contributions to the project [1..10]
  • P = Team grade for the final presentation [1..10]
  • I = Individual participation points

The final grade is then calculated via:

F = (3*V1 + 3*V2 + 3*V3 + 3*V4 + T + O + 2*P)/16 + I

FAQ

  • Do I have to deliver different documents at each deadline? No. You should work on a single document, which will be your final report at the end of the course. It does not matter if, by the time of the deadline, your document contains more information (e.g., you started your development view even before D1). Make sure, though, that the sections we’ll give you feedback are in good shape.

  • _How should I write my document? Your report should be written in Markdown and stored in your GitLab repository.

  • _Can I use Google Drive instead of GitLab? We strongly suggest you to use GitLab. This way we can actually see the individual contributions of each student.

  • I missed the deadline for the final report. What can I do? You can deliver after the deadline. However, you will penalized by 1 point for each day you are late.

  • I missed one of the soft deadlines. What can I do? We do not accept late deliveries in the soft deadlines. Please, message us with an explanation.

  • Do I need to spend precisely 140 hours in this course? This is a 5 ECTS course, which requires 140 hours of dedication from each of you. However, we are not strict about it. If you spend a bit less, e.g., 10% less, that is fine. On the other hand, if you spend a very small number of hours, e.g., 30 hours, we will discuss your case in person. Remember that any hour that you spend in the course counts, so do not forget to add the hours you spent watching our lectures and watching your colleagues in their final presentations.

  • How do I get individual points? In the final presentation day, we’ll ask you to provide constructive feedback to your colleagues. We will give you participation points based on the number of different groups you provide feedback + the quality of your feedback.

  • My project insists on a CLA. Should I sign the individual or the organizational CLA? If the projects uses a CLA, you typically should sign the ​individual​ CLA. (As a student you own the copyright on what you do, so you can transfer it as an individual).

  • I do not know much about Git. What should I do? Read our Git and GitHub tips.

  • What I use my devices in class? Educational research clearly shows that using devices on non-class related activities can harm your learning. Moreover, it can also harm your colleague’s learning. Therefore, you are not allowed to use any devices during the lecture. Exception: activities that require devices. I will help you by making announcements during the lecture about the times you should use your device.

  • How did you do this website? This website is done with Jekyll and some straightforward HTML. I was highly influenced by Andy Ko’s Cooperative Software Design website. The main picture was taken by Viktor Jakovlev.

  • Can I use your material? Attribution-NonCommercial-ShareAlike CC BY-NC-SA This website as well as all the content created by me are licensed through Attribution-NonCommercial-ShareAlike CC BY-NC-SA. This license lets others remix, tweak, and build upon your work non-commercially, as long as they credit you and license their new creations under the identical terms. The content from others that I link are subject the own authors’ licenses.