Highly focused on metrics, code organization and project stakeholders, with little discussion of actual architectural choices.
I particularly hate the "lets run static analyzer on this project, and use that to make a judgement" step they all seem to do.
For actual introductions to very specific architectures adopted by open-source software and the reasoning behind, see [1].
I have taken part to this course as a student, can confirm.
We were on a very tight schedule of 8 weeks and we had pressure to deliver content each week. Focus of the grading was on quantity vs quality. We had to take a book (Rozanski and Woods) as the bible and follow its guidelines for the analysis, even if many times they were not really applicable to the chosen project. Apparently the teachers think that every software project can be thoroughly analysed in eight weeks using a bunch of automated tools and predefined guidelines.
They ask you to create a "Module Structure Diagram" but your project has a complex set of dependencies and not-really-well-defined modules? Just make a fancy diagram with a lot of colours and it will be fine, nobody will check if that shit makes sense.
I have spent a considerable amount of time in writing my team's chapter, and I'm not proud of the fact that it's been published.
Which really is a shame. When I read the headline, I thought "Oh, like AOSA, great idea to let students do it". Then I clicked through the chapters, and was continually disappointed. I mean the selection of projects is quite promising... I'd love to read about each of them, but the content is an astonishingly accurate description of the aspects of "Software Engineering" as a university discipline that I passionately hate.
On the other hand, I don't really have found a good solution how to teach Software Architecture to students. I feel like it's one of these things that come primarily with experience.
It really is no wonder that the project turned out this way if it follows the "deliverable each week" scheme, it's a terrible way to do a university project. You absolutely have my sympathy.
It would be awesome if students get to collaborate with original author of each tool/technology to get the reasoning behind it. Good effort and good selections.
For actual introductions to very specific architectures adopted by open-source software and the reasoning behind, see [1].
1: http://aosabook.org/en/index.html