Assignment

Basic Organization

Getting Access to github/delftswa2018

All team members should have access to the GitHub delftswa2018 organization. To get access, you and your co-members should fill in our web form to give us your student number, GitHub, and email for a Mattermost account. Due to privacy reasons, the link to the web form can be found only on Brightspace.

Teams

As software architecture is all about communication, the work must be done in teams:

1. The required team size is 4.
2. Aim for diversity in your team. For example, aim at at a mixture of SEPAM / Computer Science / Software Technology / Data Science expertise, different cultures, countries, etc.

If you are looking for partners, you can open an issue on the Course Information repository, and offer your expertise.

Picking a Project

In principle you are free to pick any open source project on GitHub. Take the following into account:

• The project should be sufficiently complicated
• The project should be under active development.
• The project should use GitHub as its main communication platform (and not merely as a mirror, as, e.g., Linux is doing).

You can check these constraints by looking at recent pull requests in the project. An active project would have around 1 pull request per day at least. Interesting projects chosen by us is available, and may be most interesting to choose from first.

To claim a project: Open a new issue on the course information repository, title Claiming project P, explain why you like this project in the issue, and indicate the 4 team members that will work on this project. Make sure to add their GitHub accounts in the issue so we can find them.

We will then look at the project, and create a private repo team-P for your team in the delftswa2018 organization to put your work in. The repositories are open to all students participating in the course, allowing every student to monitor the progress of other teams, learn from them, and give them feedback (e.g. via issues or comments on pull requests). You should, however, only push changes in your own repository.

Please do not pick projects already used in last year’s course. Please check the list of projects in earlier editions of the course.

We also create a public fork for your project P within delftswa2018. This is the version you should use to work together on your (public) contributions to P.

Deliverables

The result of your work consists of sub-deliverables D1-D6, and the final DESOSA book chapter. Make sure you understand our way-of-working.

D1: Stakeholders and Context View

The first assignment aims at putting the system under study into context. To that end, investigate any documentation available on the web (e.g., web site, blogs, StackOverflow) about your system.

Stakeholders

Identify key stakeholders for your system:

1. Look at the types of stakeholders in Chapter 9 of Rozanski and Woods. Explain how they apply to your system
2. Look beyond the Rozanski and Woods classification, and identify additional types of stakeholders
3. Analyze at least 10 relevant open or recently closed issues
4. Analyze at least 10 recent pull requests (open or closed)
5. From this, explain what sort of stakeholders are involved, what their interest in the system is, and how they are trying to influence the development of the system.
6. Based on your analysis, identify the integrators in your project (see the blog post by Georgios Gousios). Identify their challenges and merge decision strategies.
7. Identify relevant people you would like to contact.

Context View

Create a context view (Rozanski and Woods, Chapter 16) for your system.

Grading Criteria

Grading criteria include:

• A single, well structured document
• Well written document (including spelling and English grammar)
• Rich set of stakeholders
• Comprehensive context view
• Actual analysis of 10 pull requests and 10 issues
• Reflection on factors affecting decisions made by integrators
• Clear identification of sources used.

D2: Development View & Contribution

Contribution

To demonstrate your understanding of the project you study, and in order to gain the trust of the other stakeholders of the project, you are required to make a contribution to the project under study.

Getting a contribution accepted will take time, and you are dependent on external people (the project owners). So start as soon as possible with this!. For some projects, you will also have to sign a Contributor License Agreement (CLA).

Your contribution can be a small update to the documentation, or a fix to one of the open issues. Also feel free to raise an issue if you bump into one.

Your contribution should be in the form of a pull request. Make it clear that you did your best to get your pull request merged.

Describe the effort you made to get your pull request merged, including links to those pull requests, in a separate file contributions.md.

Development View

Create a development view (Rozanski and Woods, Chapter 20) for your system. Where appropriate include diagrams of the as-designed development views, and the as-implemented development views. Identify key architectural styles adopted.

Grading criteria

• A single, well structured and well written document
• Development view that makes it clear what principles, patterns, and guidelines govern the development of the system.
• There should be a clear contributions.md file.

Note: For D2, only the development view is graded. The pull request is graded together with all pull requests at D4.

D3: Technical Debt

Your contribution should aim to identify and possibly solve some technical debt in the system. It can take many forms:

• identifying technical debt: how’s the overall quality of the code? To that aim, you can run code quality tools (if available for your language), and/or perform a manual analysis on the system’s source code. While technical debt can take many forms, you might want to have a look at the SOLID violations.
• identifying testing debt: is your system tested well? You can measure code coverage, discuss well- and less tested modules, and even describe their testing procedures. Can you also identify what actions should be taken if the testing should be improved? Adding more tests is an obvious one, but are there any factors impeding the simple addition of (effective) tests?
• discussions about technical debt: do developers discuss about technical debt in GitHub issues? Or are there TODO’s and FIXME’s in the source code?
• evolution of technical debt: investigate how the system evolved in terms of technical debt.

Paying a technical debt can also be a nice pull request to the system. Make clear that you did your best to get your pull request merged. Some hints to make this happen more easily:

• Use the same source code style as the rest of the project (do they use automated static analysis tools, e.g., Checkstyle, to enforce this?)
• Make sure that you have tests that show that your solution is an improvement without bugs
• Perhaps most importantly, describe the improvement: how does it improve the system, what does it enable, what does it prevent, … In short: describe how your efforts are useful to the project (in the long term).

Describe the effort you made in the file contributions.md.

Grading criteria

Grading criteria includes:

• A single, well structured document evaluating the technical debt of the system
• Well written document (including spelling and English grammar)
• Comprehensive context overview that describes the instance(s) of technical debt: why is it technical debt, under which circumstances does it become worrisome, perhaps even relate to the historical perspective
• A clear description of the actions that you have taken. Describe in detail what you did and why you think this improves the software.
• If possible, present a clear before/after analysis, this can be in the form of a metrics overview, a design or architectural view, or if the aforementioned options do not capture your solution enough, a detailed textual description.

D4: Main Deliverable: DESOSA Book Chapter

The requirements for the book chapter are as follows:

1. Include a table of contents of your chapter
2. Apply all feedback received by the TAs on the deliverables. If you disagree with the feedback, you should explicit discuss it in your journal and explain your reasons.
3. Including at least one extra view and one extra perspective w.r.t. previous deliverables.
4. Delivered in single markdown file of at most 5000 words. Pictures are most welcome. This markdown file should adhere to the Gitbook markdown style guide.

There is no mandatory structure or layout for the content: Make it as appealing and insightful for a wider audience as you can.

You can develop your chapter within your group’s repository: The final version should be offered as a pull request to the shared desosa2018 repository.

Check some tips for your final chapter

Contributions

Ensure finalized contributions have been submitted as pull requests, and make sure you did what you could do to get them merged. Interact professionally with the developers, and start early.

Aim at a mixture of simple (documentation) contributions, working your way towards actual code contributions.

Update your contributions.md with the latest pull requests you submitted and the ones that got merged.

OPTIONAL: Dedicated chapter on your contributions

To give a chance to teams to talk (show off) about their contributions to the open source projects, a dedicated chapter will be published at the end of the book. Whenever you would like to write about your contributions to the project you have analyzed, you can do so in this dedicated chapter.

We will create a placeholder at the desosa2018 repository. Teams are free to write about their work in the way they see fit.

How to contribute to this chapter?

Fork the desosa2018 repository into your own account and edit the file. File a Pull Request to the DESOSA repository with your changes. Your fellow students will have the chance to provide feedback during the PR review. The process will be monitored by the TA’s.

Remark: Contributing to this chapter is completely voluntary. Participation to this chapter may grant you some individual bonus participation points!

Final Presentations

The final presentations will take place on one full day at the end of the lectures.

We’ll reserve 15m of presentation per team, followed by 5m of Q+A for the team.

The presentation and answers should make it clear that the work was a team effort. Hence all team member must be present, and all team members must be involved in answering questions.

This is an opportunity to learn about many architectures: Therefore, presence during all presentations is compulsory for everyone.

Final presentations schedule

See the schedule for the final presentations. ⚠️ Switching rooms is allowed during the breaks only (to avoid chaos).