IN4315 - Software Architecture

Getting Access to GitLab for Writing

All team members will get access to a dedicated GitLab organization.

To get access, you and your team members can form teams on bright space.

In line with How GitHub uses GitHub to Build GitHub, use issues, clear commit messages, and merge requests to share and discuss your work.

This GitLab organization will be used for writing the architectural descriptions and decision-making process in teams. We will set it up such that teams can see each other’s work, so that you can learn from each other.

Teams

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

  1. Required team size is 4
  2. Aim for diversity in your team. For example, aim at at a mixture of Embedded Systems / Software Technology / Data Science / Policy & Management expertise, different cultures, countries, etc.
  3. Form your group in Brightspace. Go to “Groups”.

If you are looking for partners, you can post a message on our Brightspace forum (there is a topic for “partners wanted”), and offer your expertise.

Picking a Project

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

  • The project should be sufficiently large and complex
  • 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).
  • The project should not have been used in previous courses (you can see them by checking previous versions of our books).

You can check these constraints by using GHTorrent data on BigQuery. An active project will have 1or more pull requests per week. To get you started, we hand-picked a [list of 41 projects] (/delftswa2019/activities/suggested-projects.html) which are large, actively developed, maintained by a vibrant community, and are not analyzed in the previous runs of this course.

To claim a project: Post on the Brightspace forum, 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 as well as your group number. Make sure to add their GitLab 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 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.

Project Journal

You will have considerable freedom in this course. Nevertheless, a steady heartbeat is required, and you are accountable for how you spend your time.

An architect is always eager to learn more. In this course, you have 5 EC available for software architecture in 8 weeks, giving a minimum effort of 5 * 28 / 8 = 17.5 hours per week that you should spend on this course.

Grading will be also based on the progress you made compared to your initial knowledge and skill level, not just based on a preset end-goal.

To make this possible, it is important that you and your team provide insight in what you do each week. To that end:

  1. Create a file journal.md in the root of your project repository
  2. For each week, write a couple of paragraphs what you did as a team

  3. Maintain a spreadsheet (see hours.xlsx for the format and example entries) keeping track of the hours each team member spent and on which tasks.

    Note that maintaining binary files in git is cumbersome, so it is probably easiest to maintain a google docs spreadsheet somewhere.

    When handing in a sub-deliverable, you must also hand in your hours: see below.

Your journal and hour declarations will be taken into account when grading each of the sub-assignments, as well as when grading the final book chapter.

Filling in correct hours is a group responsibility. All team members must agree on the hours any team member indicates that he or she has spent.

Handing in via a GitLab release.

For handing in the results, we’ll use GitLab releases which are based on git tags.

As tag names, use D1, D2, etc in your team-XYZ repository for the deliverables. Optionally, you can add additional info in the tag name, like D1.

As always, your work should be reviewed and merged via pull requests, and this holds in particular for (the final version of) the (sub)-deliverables.

With your release, you should upload a pdf file containing up to date hour declarations for all team members.

Grading will only start after the deadline. Therefore, as long as the deadline has not passed, you can always update your work, provided it is clear what the final tag name is.